From brad@laronde.org Mon May 3 22:25:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 May 2004 22:25:22 +0100 (BST) Received: from ispmxmta06-srv.alltel.net ([IPv6:::ffff:166.102.165.167]:49587 "EHLO ispmxmta06-srv.alltel.net") by linux-mips.org with ESMTP id ; Mon, 3 May 2004 22:25:20 +0100 Received: from lahoo.priv ([69.40.150.122]) by ispmxmta06-srv.alltel.net with ESMTP id <20040503212510.JQKT438.ispmxmta06-srv.alltel.net@lahoo.priv>; Mon, 3 May 2004 16:25:10 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect ident=ambassador) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BKkrX-0003Kq-00; Mon, 03 May 2004 17:20:31 -0400 Message-ID: <045b01c43155$1e06cd80$8d01010a@prefect> From: "Bradley D. LaRonde" To: , Subject: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Date: Mon, 3 May 2004 17:25:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips I would like ld.so in uClibc CVS HEAD (last week or so) to pass the test/dlopen/ tests on mips(el). I'm currently focusing on dltest. As-is dltest seg faults soon after ld.so hands control over to the application. Some background: I'm using the uClibc "buildroot" environment, that first builds a mipsel cross-toolchain and then cross-builds a mipsel uClibc root file system image with Busybox. I configure busybox to build statically. I'm using buildroot's stock gcc 3.3.3 configuration and I have upgraded my local buildroot to binutils 2.15.90.0.1.1. When dltest runs, it ends up segfaulting inside ld.so. I tracked down the crash to what appears to me to be a bogus pointer to the malloc function. This only happens if I specify -lpthread in the build of dltest. uClibc libc.so contains weak symbols shadowing libpthread symbols so dltest will build without -lpthread. dltest doesn't actually use any libpthread functionality AFAICT. The apparently bogus pointer-to-malloc get's assigned to pointer-to-function global variable _dl_malloc_function in libdl's dlopen.c, line 164. The pointer that gets assigned falls in libpthread's address space. Interestingly in points to what appears to be a procedure stub to malloc. readelf on libpthread.so shows: 312: 00003680 0 FUNC GLOBAL DEFAULT UND malloc and that's right where the apparently bogus pointer points... libpthread's base virtual address + 0x3680. ld.so crashes shortly afterward when it calls _dl_malloc (which calls _dl_malloc_function) from uClibc/ldso/ldso/dl-hash.c::_dl_add_elf_hash_table. At least I think that's the function; I tracked it exactly but didn't make a note. :-( I suppose that binutils is pointing out a stub based on this MIPS PS ABI paragraph: If an executable or shared object contains a reference to a function defined in one of its associated shared objects, the symbol table section for that file will contain an entry for that symbol. The st_shndx member of that symbol table entry contains SHN_UNDEF. This signals to the dynamic linker that the symbol definition for that function is not contained in the executable file. If there is a stub for that symbol in the executable file and the st_value member for the symbol table entry is nonzero, the value will contain the virtual address of the first instruction of that procedure's stub. Otherwise, the st_value member contains zero. This stub calls the dynamic linker at runtime for lazy text evaluation. See "Function Addresses" in Chapter 5 for details. I guess that the point of these procedure stubs is to keep pointer-to-function values consistent between executables and share libraries. Is that what binutils is trying to accomplish here? But should stubs really be getting involved here? As Thiemo Seufer pointed out to me, readelf shows me that every undefined symbol in every shared library in /lib on my x86 debian box has the st_value member for the symbol table entry set to zero. I think Thiemo verified the same on some mips linux box. Does that mean no stubs in shared libraries? This stuff is way off the map for me. I would appreciate any help you have to offer. Thanks. Regards, Brad From ralf@linux-mips.org Mon May 3 22:40:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 03 May 2004 22:43:05 +0100 (BST) Received: from p508B7D01.dip.t-dialin.net ([IPv6:::ffff:80.139.125.1]:32362 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 3 May 2004 22:40:23 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i43LeJxT030864; Mon, 3 May 2004 23:40:19 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i43LeIAD030863; Mon, 3 May 2004 23:40:18 +0200 Date: Mon, 3 May 2004 23:40:18 +0200 From: Ralf Baechle To: admin@nectarine.info Cc: linux-mips@linux-mips.org Subject: Re: Info on nec vr4181a Message-ID: <20040503214018.GA24781@linux-mips.org> References: <1083338187.40926dcb610a4@www.nectarine.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1083338187.40926dcb610a4@www.nectarine.it> User-Agent: Mutt/1.4.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: 4934 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Apr 30, 2004 at 05:16:27PM +0200, admin@nectarine.info wrote: > i'am thinking to start development on this Nec starter kit, > which seems to be based on Acer pica cpu which is supported by linux-mips, > one of the most important things that i need on this system is the X server > or some type of gui apart from ncurses which are probably nice but not enough > for what i need to do. According to linux-mips website X for pica is not > supported, there is any news about it ? I've seen that NetBSD and OpenBSD have > support for X11 on acer pica so its port to linux wouldnt be too hard, starting > a port is an option...but first i've to understand whats the situation around X > and Acer pica... There is no relation between the PICA chipset which was built by Acer around 94/95 based on the original MIPS R4030 chipset which was also being fabbed by Toshiba and the NEC VR4xxx stuff. The Video used with the typical PICA system was an S3 968 in a proprietary 64-bit slot btw. Ralf From support@clownfishltd.com Tue May 4 21:17:50 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 May 2004 21:17:52 +0100 (BST) Received: from host-212-158-214-243.bulldogdsl.com ([IPv6:::ffff:212.158.214.243]:45696 "EHLO megablaster5.clown-smart.co.uk") by linux-mips.org with ESMTP id ; Tue, 4 May 2004 21:17:49 +0100 Received: from [127.0.0.1] (host-212-158-214-244.bulldogdsl.com [212.158.214.244]) by megablaster5.clown-smart.co.uk (Postfix) with ESMTP id 4F7414FB06; Tue, 4 May 2004 21:32:03 +0100 (BST) Message-ID: <4097FADE.5080609@clownfishltd.com> Date: Tue, 04 May 2004 21:19:42 +0100 From: Clownfish Internet User-Agent: Mozilla Thunderbird 0.5 (Windows/20040426) X-Accept-Language: en MIME-Version: 1.0 To: "Ilya A. Volynets-Evenbakh" Cc: Damian Presswell , linux-mips@linux-mips.org Subject: Re: Linux Mips SGI O2 R5000 IP32 INSTALL References: <408D6BFC.6030902@clown-fish.com> <20040426222441.GC1276@gateway.total-knowledge.com> <408FA3C3.3060304@clown-fish.com> <408FFE1E.5080605@theilya.com> In-Reply-To: <408FFE1E.5080605@theilya.com> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: 4935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: support@clownfishltd.com Precedence: bulk X-list: linux-mips Ilya - do you have a working version of arcboot - I am unable to get any versions that I have found to install and be able to read my primary HD volume header (50meg) - I have found the following gentoo ebuild file: http://dev.gentoo.org/~kumba/mips/misc/arcboot-0.3.8.1.ebuild is there anyway I may use this to pull the package into my system ? - i havent managed it yet - thanks Ilya A. Volynets-Evenbakh wrote: > Well, you are not the only one ;-) > Currently you cannot use volume header for loading linux kernel due to > some > very strange bug. I spent two weeks chsing it, and then decided that > my time > is better spent elsewhere. Also, dents in my walls resulting from > contact between > my head and walls' surface do not look nice. For now, you should > either use > dhcp/bootp or arcboot. Latest version of arcboot (0.3.8.-something, > afair) should work out > of the box with O2. If it doesn't, let me know - I'll dig out my > highly-hacked binary. > > Ilya. > > Damian Presswell wrote: > >> Hi Ilya - >> >> thanks for coming back to me - >> >> I have managed to build a root filesystem using the gentoo sources >> that you suggested - however - >> I am unable to boot off the hardisk - >> I have fdisked the first scsi disk, created a 50 meg vlhdr, where I >> have copied my pre-compiled vmlinux binaries - >> it appears to load and provide an entry point but then just hangs >> and goes no further - >> I have also added the original netboot vmlinux binary that I use to >> boot via tftpboot to the HD's volume header but it does the same >> thing - just hangs after the entry point - >> >> I can boot the system using bootp(): and the kernel binary located >> in the tftpboot using root=dev/sda3 - but cannot figure why it >> doesnt seem to work off the volume header of the HD - >> >> once again - >> >> any help would be appreciated - >> >> thanks >> >> >> >> ilya@theIlya.com wrote: >> >>> Use Gentoo. >>> Also, Glaurung's kernels are bit out-od-date. Use self-built >>> kernel from recent linux-mips.org CVS. In worst case, use >>> one of Gentoo's kernel binaries. >>> >>> Ilya. >>> >>> On Mon, Apr 26, 2004 at 09:07:24PM +0100, Damian Presswell wrote: >>> >>> >>>> My apologies if this is the wrong mailing list for this question - >>>> >>>> I have recently aquired an SGI O2 ip32 R5k box that I am trying to >>>> install linux onto - >>>> >>>> I have managed to get a binary 64bit kernel to boot vis nfs and >>>> bootp() that I downloaded from Glaurungs website: >>>> >>>> http://www.linux-mips.org/~glaurung/ >>>> >>>> however I am unsure as to the correct rootfs that I am suposed to >>>> use - I pulled down the redhat 7.1 rootfs from somewhere but it >>>> hangs when trying to start the 'local' service - and wont boot if >>>> this service is switched off - >>>> >>>> I would be grateful if you could suggest where I may download a >>>> suitable rootfs and ecoff boot image that will work together on my >>>> O2 box - would hate to give in at this stage - and indeed any other >>>> help you may be able to give me as a linux mips O2 user - I will >>>> put together an updated HOWTO once I am sure exactly what I am >>>> supposed to be doing - the information and resources on this >>>> subject do seem to be a little vague - >>>> >>>> thanks for your time >>>> >>>> Damian >>> >>> > -- -------------------------------------------------------------------------------------------------------------- support@clownfishltd.com Damian Presswell (M) +44 07986 494824 (T) +44 0845 1259523 From yshitoot@stellartec.com Thu May 6 18:19:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 May 2004 18:19:56 +0100 (BST) Received: from mail.stellartec.com ([IPv6:::ffff:65.107.16.99]:24589 "EHLO gateway.stellartec.com") by linux-mips.org with ESMTP id ; Thu, 6 May 2004 18:19:55 +0100 Received: from Exchange.stellartec.com ([192.168.1.7]) by gateway.stellartec.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 10:19:44 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4338E.53011F38" Subject: Strange Behavior - help Date: Thu, 6 May 2004 10:19:43 -0700 Message-ID: <7F5F67B895426C40AC75B8290421C23915CE57@Exchange.stellartec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Strange Behavior - help Thread-Index: AcQzjlK5D+RXyiEsR4KMtsdJR31r+g== From: "Yashwant Shitoot" To: X-OriginalArrivalTime: 06 May 2004 17:19:44.0455 (UTC) FILETIME=[5306E570:01C4338E] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yshitoot@stellartec.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C4338E.53011F38 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Friends, =20 My root file system and linux is in rom (flash). The linux itself runs out of ram. When I reprogram the rom, I erase and write a new image of the rom from a compact flash card. After the new image is programmed in the function fclose() hangs up, implying that fclose() is rom resident and loaded as needed. Does this make sense ? Remember even after erasing the rom fopen() works fine. =20 Thanks=20 =20 Yash ------_=_NextPart_001_01C4338E.53011F38 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello Friends,

 

My root file system and linux is in rom (flash). The = linux itself runs out of ram. When I reprogram the rom, I erase and write a = new image of the rom from a compact flash card. After the new image is programmed = in the function fclose() hangs up, implying that fclose() is rom resident and = loaded as needed. Does this make sense ? Remember even after erasing the rom = fopen() works fine.

 

Thanks

 

Yash

------_=_NextPart_001_01C4338E.53011F38-- From ralf@linux-mips.org Thu May 6 18:33:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 06 May 2004 18:33:45 +0100 (BST) Received: from p508B5B3D.dip.t-dialin.net ([IPv6:::ffff:80.139.91.61]:42273 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 6 May 2004 18:33:43 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i46HXgxT013581; Thu, 6 May 2004 19:33:42 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i46HXfli013580; Thu, 6 May 2004 19:33:41 +0200 Date: Thu, 6 May 2004 19:33:41 +0200 From: Ralf Baechle To: Yashwant Shitoot Cc: linux-mips@linux-mips.org Subject: Re: Strange Behavior - help Message-ID: <20040506173341.GA23488@linux-mips.org> References: <7F5F67B895426C40AC75B8290421C23915CE57@Exchange.stellartec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F5F67B895426C40AC75B8290421C23915CE57@Exchange.stellartec.com> User-Agent: Mutt/1.4.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: 4937 X-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, May 06, 2004 at 10:19:43AM -0700, Yashwant Shitoot wrote: > Hello Friends, Allright, dinner on you ;-) > My root file system and linux is in rom (flash). The linux itself runs > out of ram. When I reprogram the rom, I erase and write a new image of > the rom from a compact flash card. After the new image is programmed in > the function fclose() hangs up, implying that fclose() is rom resident > and loaded as needed. Does this make sense ? Demand loading that is the binary will be paged in from backing store (which is your ROM) as needed. > Remember even after erasing the rom fopen() works fine. Linux may at any time deciede to discard a page of memory. It does so when it think it has a better use for that memory. Rewriting the underlying device of any filesystem is not a safe thing to do. A possible safe approach would be running from a ramdisk, for example. Ralf From hch@lst.de Fri May 7 11:40:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 May 2004 11:40:58 +0100 (BST) Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:42702 "EHLO mail.lst.de") by linux-mips.org with ESMTP id ; Fri, 7 May 2004 11:40:57 +0100 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i47AetQc010815 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 May 2004 12:40:55 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i47AetWZ010813; Fri, 7 May 2004 12:40:55 +0200 Date: Fri, 7 May 2004 12:40:55 +0200 From: Christoph Hellwig To: ppopov@mvista.com Cc: linux-mips@linux-mips.org Subject: drivers/pcmcia/au1000_generic.c Message-ID: <20040507104055.GA10779@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: -4.901 () BAYES_00 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hch@lst.de Precedence: bulk X-list: linux-mips Does someone care for that file in 2.6? It doesn't compile at all in 2.4, in fact it looks like someone just dropped that file into the tree after all 2.5 pcmcia changes were over.. From ppopov@mvista.com Fri May 7 16:22:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 May 2004 16:22:32 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:2296 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Fri, 7 May 2004 16:22:31 +0100 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id IAA21597; Fri, 7 May 2004 08:22:24 -0700 Message-ID: <409BA9AE.3080800@mvista.com> Date: Fri, 07 May 2004 08:22:22 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-mips@linux-mips.org Subject: Re: drivers/pcmcia/au1000_generic.c References: <20040507104055.GA10779@lst.de> In-Reply-To: <20040507104055.GA10779@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips Christoph Hellwig wrote: >Does someone care for that file in 2.6? It doesn't compile at all in >2.4, in fact it looks like someone just dropped that file into the tree >after all 2.5 pcmcia changes were over.. > > > Of course I care. It compiles in 2.4, unless the recent 2.4.26 merge broke it, but I doubt it. And in 2.6, I basically rewrote the driver so it's up to date for the db1x00 boards but not the rest of the au1x boards. I'll get to those soon. Pete From tim.bird@am.sony.com Fri May 7 23:00:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 May 2004 23:00:44 +0100 (BST) Received: from mail1.fw-sj.sony.com ([IPv6:::ffff:160.33.82.68]:30188 "EHLO mail1.fw-sj.sony.com") by linux-mips.org with ESMTP id ; Fri, 7 May 2004 23:00:43 +0100 Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail1.fw-sj.sony.com (8.12.11/8.12.11) with ESMTP id i47M0KvG019469 for ; Fri, 7 May 2004 22:00:25 GMT Received: from am.sony.com ([43.134.85.171]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id i47M05sA028322 for ; Fri, 7 May 2004 22:00:05 GMT Message-ID: <409C0960.3080604@am.sony.com> Date: Fri, 07 May 2004 15:10:40 -0700 From: Tim Bird User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: MIPS status in 2.6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tim.bird@am.sony.com Precedence: bulk X-list: linux-mips Anyone know what the status is of MIPS support in 2.6? ============================= Tim Bird Architecture Group Co-Chair CE Linux Forum Senior Staff Engineer Sony Electronics E-mail: Tim.Bird@am.sony.com ============================= From jsun@orion.mvista.com Fri May 7 23:58:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 07 May 2004 23:58:16 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:49652 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 7 May 2004 23:58:15 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i47MwCx6014472; Fri, 7 May 2004 15:58:12 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i47MwBZL014470; Fri, 7 May 2004 15:58:11 -0700 Date: Fri, 7 May 2004 15:58:11 -0700 From: Jun Sun To: Tim Bird Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: MIPS status in 2.6 Message-ID: <20040507155811.B9702@mvista.com> References: <409C0960.3080604@am.sony.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <409C0960.3080604@am.sony.com>; from tim.bird@am.sony.com on Fri, May 07, 2004 at 03:10:40PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Fri, May 07, 2004 at 03:10:40PM -0700, Tim Bird wrote: > Anyone know what the status is of MIPS support in 2.6? > 32bit has been working pretty well, including preemption, kgdb, SMP, etc. IO subsystems have not been thoroughly tested. Board support varies. 64bit needs some work. Jun From ppopov@mvista.com Sat May 8 00:04:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 May 2004 00:04:24 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:43255 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Sat, 8 May 2004 00:04:23 +0100 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA15331; Fri, 7 May 2004 16:04:19 -0700 Message-ID: <409C15F1.5080702@mvista.com> Date: Fri, 07 May 2004 16:04:17 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bird CC: Jun Sun , linux-mips@linux-mips.org Subject: Re: MIPS status in 2.6 References: <409C0960.3080604@am.sony.com> <20040507155811.B9702@mvista.com> In-Reply-To: <20040507155811.B9702@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips Jun Sun wrote: >On Fri, May 07, 2004 at 03:10:40PM -0700, Tim Bird wrote: > > >>Anyone know what the status is of MIPS support in 2.6? >> >> >> > >32bit has been working pretty well, including preemption, kgdb, >SMP, etc. IO subsystems have not been thoroughly tested. Board support >varies. > >64bit needs some work. > > AMD Alchemy boards: - serial driver was updated - ethernet driver works, but seens some minor updates - kind of a beta version of the 36bit address support was sent to Ralf - pcmcia driver was rewritten for 2.6, but only for db1x00 right now. The rest of the boards need to be updated. - usb host needs work - pci bus seems to work (with the 36bit patch) - sound driver needs update from OSS to ALSA - Au1100 FB driver needs to be updated to 2.6 - Epson FB driver too (I won't work on that one) - usb gadget support is needed I may be forgetting something. I'm working on it part time. Pete From jsun@orion.mvista.com Sat May 8 02:10:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 May 2004 02:10:37 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:49148 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Sat, 8 May 2004 02:10:33 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i481AWx6021181; Fri, 7 May 2004 18:10:32 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i481AVSU021179; Fri, 7 May 2004 18:10:31 -0700 Date: Fri, 7 May 2004 18:10:31 -0700 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: semaphore woes in 2.6, 32bit Message-ID: <20040507181031.F9702@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips I got a bunch of segfaults which are due to HAS_LLSCD cpu operating on a semaphore which is aligned along 4-byte boundary instead of the desired 8-byte boundary. I traced down one such place at serial/serial_core.c: int uart_register_driver(struct uart_driver *drv) { struct tty_driver *normal = NULL; int i, retval; BUG_ON(drv->state); /* * Maybe we should be using a slab cache for this, especially if * we have a large number of ports to handle. */ drv->state = kmalloc(sizeof(struct uart_state) * drv->nr, GFP_KERNEL); ... where drv->state contains a semaphore variable, but apparently kmalloc() only give 4-byte boundary alignment. There are many other faults, which I did not bother to trace down. Simply removing CPU_HAS_LLSCD makes the problem go away, which probably indicates they are all of the same nature. I wonder why this problem only shows up now while it did not show up earlier when we introduced the new up(). Perhaps kmalloc() always returns 8-byte aligned blocks? I can't think of an immediate and good fix. Hopefully someone else smarter than me can find a solution before I come back to it on Monday. :) Jun From ralf@linux-mips.org Sat May 8 08:18:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 May 2004 08:18:28 +0100 (BST) Received: from p508B5C6F.dip.t-dialin.net ([IPv6:::ffff:80.139.92.111]:51254 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 8 May 2004 08:18:27 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i487IPxT029710; Sat, 8 May 2004 09:18:26 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i487IMjm029709; Sat, 8 May 2004 09:18:22 +0200 Date: Sat, 8 May 2004 09:18:22 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit Message-ID: <20040508071822.GA29554@linux-mips.org> References: <20040507181031.F9702@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040507181031.F9702@mvista.com> User-Agent: Mutt/1.4.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: 4944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 07, 2004 at 06:10:31PM -0700, Jun Sun wrote: > I got a bunch of segfaults which are due to HAS_LLSCD cpu operating > on a semaphore which is aligned along 4-byte boundary instead of the > desired 8-byte boundary. Dare to give a complete version number? I've dumped 2.4 on all my systems months ago and never have seen this problem except with slab debugging enabled - but that side effect of slab debugging is known since years. Ralf From fc6v-49qr-9ddd@nerim.net Sat May 8 18:34:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 08 May 2004 18:34:49 +0100 (BST) Received: from smtp-106-saturday.noc.nerim.net ([IPv6:::ffff:62.4.17.106]:60172 "EHLO mallaury.noc.nerim.net") by linux-mips.org with ESMTP id ; Sat, 8 May 2004 18:34:48 +0100 Received: from atc5.vermine.org (aym.net1.nerim.net [213.41.148.182]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 9A74462D59 for ; Sat, 8 May 2004 19:34:45 +0200 (CEST) Received: from aym by atc5.vermine.org with local (Exim 3.36 #1 (Debian)) id 1BMVip-00071y-00 for ; Sat, 08 May 2004 19:34:47 +0200 Date: Sat, 8 May 2004 19:34:47 +0200 From: Andre Majorel To: linux-mips@linux-mips.org Subject: Newsgroups or mailing lists for Siemens hardware Message-ID: <20040508173446.GA27010@teaser.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fc6v-49qr-9ddd@nerim.net Precedence: bulk X-list: linux-mips Since the deletion of de.comp.os.unix.sinix, I'm not sure where to go for Siemens hardware information. comp.sys.mips seems comatose. The de.comp.os.unix.sinix folks talked of relocating somewhere in alt but I can't find them. Are there any mailing lists or newsgroups where I'm likely to get answers on Siemens MIPS machines (RM200C) ? -- André Majorel Do not use this account for regular correspondance. See the URL above for contact information. From jsun@orion.mvista.com Sun May 9 06:48:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 06:48:11 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:22259 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sun, 9 May 2004 06:48:09 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i495m7x6024794; Sat, 8 May 2004 22:48:07 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i495m6IF024792; Sat, 8 May 2004 22:48:06 -0700 Date: Sat, 8 May 2004 22:48:06 -0700 From: Jun Sun To: Ralf Baechle Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: semaphore woes in 2.6, 32bit Message-ID: <20040508224806.A24682@mvista.com> References: <20040507181031.F9702@mvista.com> <20040508071822.GA29554@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT User-Agent: Mutt/1.2.5i In-Reply-To: <20040508071822.GA29554@linux-mips.org>; from ralf@linux-mips.org on Sat, May 08, 2004 at 09:18:22AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Sat, May 08, 2004 at 09:18:22AM +0200, Ralf Baechle wrote: > On Fri, May 07, 2004 at 06:10:31PM -0700, Jun Sun wrote: > > > I got a bunch of segfaults which are due to HAS_LLSCD cpu operating > > on a semaphore which is aligned along 4-byte boundary instead of the > > desired 8-byte boundary. > > Dare to give a complete version number? I've dumped 2.4 on all my systems > months ago and never have seen this problem except with slab debugging > enabled - but that side effect of slab debugging is known since years. > Kernel is yesterday's CVS. gcc is 3.3.1. config is ddb5477. No additional patch. See below. In any case if you look at the uart code you should see there is a problem already. 'state' is allocated through kmalloc() which only gives 4-byte alignement. The only puzzling thing is that why this did not show up before. Maybe kmalloc() was giving 8-byte aligned block? VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 6 EXTRAVERSION =-rc3 NAME=Zonked Quokka [jsun@orion linux]$ mipsel-linux-gcc -v Reading specs from /opt/mvl-installs/pe040201/montavista/pro/devkit/mips/fp_le/bin/../lib/gcc-lib/mipsel-hardhat-linux/3.3.1/specs Configured with: ../configure --host=i686-pc-linux-gnu --target=mipsel-hardhat-linux --prefix=/opt/montavista/devkit/mips/fp_le --exec-prefix=/opt/montavista/devkit/mips/fp_le --bindir=/opt/montavista/devkit/mips/fp_le/bin --sbindir=/opt/montavista/devkit/mips/fp_le/sbin --sysconfdir=/opt/montavista/devkit/mips/fp_le/etc --datadir=/opt/montavista/devkit/mips/fp_le/share --includedir=/opt/montavista/devkit/mips/fp_le/include --libdir=/opt/montavista/devkit/mips/fp_le/lib --libexecdir=/opt/montavista/devkit/mips/fp_le/libexec --localstatedir=/opt/montavista/devkit/mips/fp_le/var --sharedstatedir=/opt/montavista/devkit/mips/fp_le/share --mandir=/opt/montavista/devkit/mips/fp_le/man --infodir=/opt/montavista/devkit/mips/fp_le/info --program-transform-name=s,^,mips_fp_le-, --enable-cross --with-sysroot=/opt/montavista/devkit/mips/fp_le/target --enable-shared --enable-languages=c,c++ --enable-__cxa_atexit --enable-threads=posix --disable-multilib --with-gxx-include-dir='$'{gcc_tooldir}/../target/usr/include/c++/3.3.1 Thread model: posix gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24) Jun From geert@linux-m68k.org Sun May 9 10:09:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 10:09:33 +0100 (BST) Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:7868 "EHLO witte.sonytel.be") by linux-mips.org with ESMTP id ; Sun, 9 May 2004 10:09:32 +0100 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i4999Uwc029668; Sun, 9 May 2004 11:09:30 +0200 (MEST) Date: Sun, 9 May 2004 11:09:29 +0200 (MEST) From: Geert Uytterhoeven To: Jun Sun cc: Ralf Baechle , Linux/MIPS Development Subject: Re: semaphore woes in 2.6, 32bit In-Reply-To: <20040508224806.A24682@mvista.com> Message-ID: References: <20040507181031.F9702@mvista.com> <20040508071822.GA29554@linux-mips.org> <20040508224806.A24682@mvista.com> 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: 4947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Sat, 8 May 2004, Jun Sun wrote: > On Sat, May 08, 2004 at 09:18:22AM +0200, Ralf Baechle wrote: > > On Fri, May 07, 2004 at 06:10:31PM -0700, Jun Sun wrote: > > > > > I got a bunch of segfaults which are due to HAS_LLSCD cpu operating > > > on a semaphore which is aligned along 4-byte boundary instead of the > > > desired 8-byte boundary. > > > > Dare to give a complete version number? I've dumped 2.4 on all my systems > > months ago and never have seen this problem except with slab debugging > > enabled - but that side effect of slab debugging is known since years. > > > > Kernel is yesterday's CVS. gcc is 3.3.1. config is ddb5477. No > additional patch. See below. > > In any case if you look at the uart code you should see there > is a problem already. 'state' is allocated through kmalloc() which only > gives 4-byte alignement. The only puzzling thing is that why this > did not show up before. Maybe kmalloc() was giving 8-byte aligned block? AFAIK, kmaloc() always[*] returns 8-byte (or higher, for archs that need it) aligned blocks. [*] But I did see reports of this being false if slab debugging was enabled. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Sun May 9 13:57:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 13:57:56 +0100 (BST) Received: from p508B632F.dip.t-dialin.net ([IPv6:::ffff:80.139.99.47]:26182 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 9 May 2004 13:57:55 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i49CvqxT024041; Sun, 9 May 2004 14:57:52 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i49Cvof9024040; Sun, 9 May 2004 14:57:50 +0200 Date: Sun, 9 May 2004 14:57:50 +0200 From: Ralf Baechle To: Geert Uytterhoeven Cc: Jun Sun , Linux/MIPS Development Subject: Re: semaphore woes in 2.6, 32bit Message-ID: <20040509125750.GA19225@linux-mips.org> References: <20040507181031.F9702@mvista.com> <20040508071822.GA29554@linux-mips.org> <20040508224806.A24682@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.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: 4948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, May 09, 2004 at 11:09:29AM +0200, Geert Uytterhoeven wrote: > > Kernel is yesterday's CVS. gcc is 3.3.1. config is ddb5477. No > > additional patch. See below. > > > > In any case if you look at the uart code you should see there > > is a problem already. 'state' is allocated through kmalloc() which only > > gives 4-byte alignement. The only puzzling thing is that why this > > did not show up before. Maybe kmalloc() was giving 8-byte aligned block? > > AFAIK, kmaloc() always[*] returns 8-byte (or higher, for archs that need it) > aligned blocks. We got tripped by a change in 2.6.6-rc2. Before that change the kmalloc slab caches were being created with SLAB_HWCACHE_ALIGN which results in L1_CACHE_SHIFT alignment for allocations of L1_CACHE_SHIFT for slab caches that are at least that size. For the sake of S390 this behaviour was changed; new it defaults to BYTES_PER_WORD alignment which is four bytes. Fixed by defining ARCH_KMALLOC_MINALIGN as 8. Ralf Index: include/asm-mips/cache.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/cache.h,v retrieving revision 1.16 diff -u -r1.16 cache.h --- include/asm-mips/cache.h 10 Oct 2003 20:37:35 -0000 1.16 +++ include/asm-mips/cache.h 9 May 2004 12:57:38 -0000 @@ -18,4 +18,6 @@ #define SMP_CACHE_SHIFT L1_CACHE_SHIFT #define SMP_CACHE_BYTES L1_CACHE_BYTES +#define ARCH_KMALLOC_MINALIGN 8 + #endif /* _ASM_CACHE_H */ From rsandifo@redhat.com Sun May 9 14:14:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 14:14:39 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:62608 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Sun, 9 May 2004 14:14:38 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i49DEZ0m008461; Sun, 9 May 2004 09:14:35 -0400 Received: from localhost (mail@vpnuser2.surrey.redhat.com [172.16.9.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i49DEYv22462; Sun, 9 May 2004 09:14:35 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BMo8X-0006fb-00; Sun, 09 May 2004 14:14:33 +0100 To: "Bradley D. LaRonde" Cc: , Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value References: <045b01c43155$1e06cd80$8d01010a@prefect> From: Richard Sandiford Date: Sun, 09 May 2004 14:14:33 +0100 In-Reply-To: <045b01c43155$1e06cd80$8d01010a@prefect> (Bradley D. LaRonde's message of "Mon, 3 May 2004 17:25:11 -0400") Message-ID: <874qqpg2ti.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: 4949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@redhat.com Precedence: bulk X-list: linux-mips "Bradley D. LaRonde" writes: > I guess that the point of these procedure stubs is to keep > pointer-to-function values consistent between executables and share > libraries. Is that what binutils is trying to accomplish here? No, it's to enable lazy binding. The idea is that when the dynamic loader loads libpthread.so, it doesn't need to resolve malloc() immediately, it can just leave the GOT entry pointing to the stub. Then, when the stub is called, it will ask the dynamic linker to find the true address of malloc() and update the GOT accordingly. This is supposed to reduce start-up time. An object should never use stubs if takes the address of the function. It should only use a stub for some symbol foo if every use of foo is for a direct call. If the dynamic loader is choosing libpthread's stub over the real definition in libc.so, that sounds on the face of it like a dynamic loader bug. > But should stubs really be getting involved here? As Thiemo Seufer pointed > out to me, readelf shows me that every undefined symbol in every shared > library in /lib on my x86 debian box has the st_value member for the symbol > table entry set to zero. The x86 and MIPS ABIs are very different though. Richard From anemo@mba.ocn.ne.jp Sun May 9 14:54:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 14:54:33 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:31451 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Sun, 9 May 2004 14:54:32 +0100 Received: from localhost (p7141-ipad202funabasi.chiba.ocn.ne.jp [222.146.78.141]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 3F7606165; Sun, 9 May 2004 22:54:29 +0900 (JST) Date: Sun, 09 May 2004 22:56:37 +0900 (JST) Message-Id: <20040509.225637.92590265.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: geert@linux-m68k.org, jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit From: Atsushi Nemoto In-Reply-To: <20040509125750.GA19225@linux-mips.org> References: <20040508224806.A24682@mvista.com> <20040509125750.GA19225@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 4950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Sun, 9 May 2004 14:57:50 +0200, Ralf Baechle said: ralf> We got tripped by a change in 2.6.6-rc2. Before that change the ralf> kmalloc slab caches were being created with SLAB_HWCACHE_ALIGN ralf> which results in L1_CACHE_SHIFT alignment for allocations of ralf> L1_CACHE_SHIFT for slab caches that are at least that size. For ralf> the sake of S390 this behaviour was changed; new it defaults to ralf> BYTES_PER_WORD alignment which is four bytes. ralf> Fixed by defining ARCH_KMALLOC_MINALIGN as 8. Hmm, many drivers use kmalloc and pci_map_single for DMA buffer. So ARCH_KMALLOC_MINALIGN should be L1_CACHE_BYTES for non-coherent system? --- Atsushi Nemoto From ralf@linux-mips.org Sun May 9 17:48:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 17:48:41 +0100 (BST) Received: from p508B632F.dip.t-dialin.net ([IPv6:::ffff:80.139.99.47]:25160 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 9 May 2004 17:48:40 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i49GmbxT028270; Sun, 9 May 2004 18:48:37 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i49GmZRe028269; Sun, 9 May 2004 18:48:35 +0200 Date: Sun, 9 May 2004 18:48:35 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: geert@linux-m68k.org, jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit Message-ID: <20040509164835.GA28011@linux-mips.org> References: <20040508224806.A24682@mvista.com> <20040509125750.GA19225@linux-mips.org> <20040509.225637.92590265.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040509.225637.92590265.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.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: 4951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, May 09, 2004 at 10:56:37PM +0900, Atsushi Nemoto wrote: > ralf> We got tripped by a change in 2.6.6-rc2. Before that change the > ralf> kmalloc slab caches were being created with SLAB_HWCACHE_ALIGN > ralf> which results in L1_CACHE_SHIFT alignment for allocations of > ralf> L1_CACHE_SHIFT for slab caches that are at least that size. For > ralf> the sake of S390 this behaviour was changed; new it defaults to > ralf> BYTES_PER_WORD alignment which is four bytes. > > ralf> Fixed by defining ARCH_KMALLOC_MINALIGN as 8. > > Hmm, many drivers use kmalloc and pci_map_single for DMA buffer. So > ARCH_KMALLOC_MINALIGN should be L1_CACHE_BYTES for non-coherent > system? No, those drivers are simply broken. dma_get_cache_alignment() gives the mimimum alignment and width for DMA mappings and that value is larger than kmalloc alignment in almost all cases. Ralf From ralf@linux-mips.org Sun May 9 17:59:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 17:59:54 +0100 (BST) Received: from p508B632F.dip.t-dialin.net ([IPv6:::ffff:80.139.99.47]:33352 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 9 May 2004 17:59:53 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i49GxqxT028494; Sun, 9 May 2004 18:59:52 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i49GxqLp028493; Sun, 9 May 2004 18:59:52 +0200 Date: Sun, 9 May 2004 18:59:52 +0200 From: Ralf Baechle To: Andre Majorel Cc: linux-mips@linux-mips.org Subject: Re: Newsgroups or mailing lists for Siemens hardware Message-ID: <20040509165952.GB28011@linux-mips.org> References: <20040508173446.GA27010@teaser.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040508173446.GA27010@teaser.fr> User-Agent: Mutt/1.4.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: 4952 X-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, May 08, 2004 at 07:34:47PM +0200, Andre Majorel wrote: > Since the deletion of de.comp.os.unix.sinix, I'm not sure where > to go for Siemens hardware information. comp.sys.mips seems > comatose. The de.comp.os.unix.sinix folks talked of relocating > somewhere in alt but I can't find them. > > Are there any mailing lists or newsgroups where I'm likely to > get answers on Siemens MIPS machines (RM200C) ? Very little RM200C traffic here. I fear right now I'm the only person in the universe using an RM200C. Talking about it, my RM200C hw is showing signs of aging and upcoming death and anyway, 32MB aren't alot so I could use a memory upgrade ... Ralf From brad@laronde.org Sun May 9 21:54:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 09 May 2004 21:54:31 +0100 (BST) Received: from ispmxmta05-srv.alltel.net ([IPv6:::ffff:166.102.165.166]:9903 "EHLO ispmxmta05-srv.alltel.net") by linux-mips.org with ESMTP id ; Sun, 9 May 2004 21:54:30 +0100 Received: from lahoo.priv ([69.40.150.122]) by ispmxmta05-srv.alltel.net with ESMTP id <20040509205420.OXDL6615.ispmxmta05-srv.alltel.net@lahoo.priv>; Sun, 9 May 2004 15:54:20 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BMvE7-0004l5-00; Sun, 09 May 2004 16:48:47 -0400 Message-ID: <012701c43607$83aa65f0$8d01010a@prefect> From: "Bradley D. LaRonde" To: "Richard Sandiford" Cc: , References: <045b01c43155$1e06cd80$8d01010a@prefect> <874qqpg2ti.fsf@redhat.com> Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Date: Sun, 9 May 2004 16:52:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Richard Sandiford" To: "Bradley D. LaRonde" Cc: ; Sent: Sunday, May 09, 2004 9:14 AM Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value > "Bradley D. LaRonde" writes: > > I guess that the point of these procedure stubs is to keep > > pointer-to-function values consistent between executables and share > > libraries. Is that what binutils is trying to accomplish here? > > No, it's to enable lazy binding. The idea is that when the dynamic > loader loads libpthread.so, it doesn't need to resolve malloc() > immediately, it can just leave the GOT entry pointing to the stub. > Then, when the stub is called, it will ask the dynamic linker to > find the true address of malloc() and update the GOT accordingly. > This is supposed to reduce start-up time. > > An object should never use stubs if takes the address of the function. > It should only use a stub for some symbol foo if every use of foo is > for a direct call. OK. So in a case where an object does take a pointer, does that mean that ld.so must fix the GOT entry for that symbol before handing control to the app (i.e. no lazy binding for that symbol)? > If the dynamic loader is choosing libpthread's stub over the real > definition in libc.so, that sounds on the face of it like a dynamic > loader bug. OK. > > But should stubs really be getting involved here? As Thiemo Seufer pointed > > out to me, readelf shows me that every undefined symbol in every shared > > library in /lib on my x86 debian box has the st_value member for the symbol > > table entry set to zero. > > The x86 and MIPS ABIs are very different though. I notice that the debian mipsel libpthread.so.0 in http://ftp.debian.org/pool/main/g/glibc/libc6_2.2.5-11.5_mipsel.deb has st_value == 0 for every UND FUNC, just like my x86 debian libraries. This is very different than the uClibc libpthread.so where every UND FUNC has st_value != 0. Interestingly if I link glibc's libpthread with uClibc's libc.so I see that most UND FUNCs then have st_value != 0. I would like to see how uClibc ld.so behaves I could somehow get ld to not generate any stubs in libpthread. Any idea why libpthread gets full stubs when linked with uClibc libc.so but no stubs when linked with glibc libc.so? Regards, Brad From rsandifo@redhat.com Mon May 10 08:40:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 08:40:43 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:64395 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 08:40:42 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4A7ee0m020104; Mon, 10 May 2004 03:40:40 -0400 Received: from localhost (mail@vpnuser4.surrey.redhat.com [172.16.9.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4A7ecv20487; Mon, 10 May 2004 03:40:38 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BN5Ov-0002Io-00; Mon, 10 May 2004 08:40:37 +0100 To: "Bradley D. LaRonde" Cc: , Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value References: <045b01c43155$1e06cd80$8d01010a@prefect> <874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect> From: Richard Sandiford Date: Mon, 10 May 2004 08:40:37 +0100 In-Reply-To: <012701c43607$83aa65f0$8d01010a@prefect> (Bradley D. LaRonde's message of "Sun, 9 May 2004 16:52:17 -0400") Message-ID: <87pt9cwwzu.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: 4954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@redhat.com Precedence: bulk X-list: linux-mips "Bradley D. LaRonde" writes: >> An object should never use stubs if takes the address of the function. >> It should only use a stub for some symbol foo if every use of foo is >> for a direct call. > > OK. So in a case where an object does take a pointer, does that mean that > ld.so must fix the GOT entry for that symbol before handing control to the > app (i.e. no lazy binding for that symbol)? Right. Such objects won't use a stub, they'll just have a normal reference to an undefined symbol. The dynamic loader must resolve it in the usual way. > I notice that the debian mipsel libpthread.so.0 in > http://ftp.debian.org/pool/main/g/glibc/libc6_2.2.5-11.5_mipsel.deb has > st_value == 0 for every UND FUNC, just like my x86 debian libraries. This > is very different than the uClibc libpthread.so where every UND FUNC has > st_value != 0. Interestingly if I link glibc's libpthread with uClibc's > libc.so I see that most UND FUNCs then have st_value != 0. You said in your original message that you'd recently upgraded to binutils 2.15-based tools. Was your libpthread.so built with them? If so, that would explain it. I think earlier versions of ld were overly pessimistic about when stubs could be used. FWIW, I have a glibc-based sysroot built with gcc 3.4 and binutils 2.15. Its libpthread uses plenty of stubs. Richard From joakim.tjernlund@lumentis.se Mon May 10 13:21:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 13:21:30 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:27586 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 13:21:29 +0100 Received: from jockewin (fw [172.31.1.1]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4ACLIvC029180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 10 May 2004 14:21:19 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Richard Sandiford" Cc: , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Mon, 10 May 2004 14:21:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <012701c43607$83aa65f0$8d01010a@prefect> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 4955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joakim.tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > > The x86 and MIPS ABIs are very different though. > > I notice that the debian mipsel libpthread.so.0 in > http://ftp.debian.org/pool/main/g/glibc/libc6_2.2.5-11.5_mipsel.deb has > st_value == 0 for every UND FUNC, just like my x86 debian libraries. This > is very different than the uClibc libpthread.so where every UND FUNC has > st_value != 0. Interestingly if I link glibc's libpthread with uClibc's > libc.so I see that most UND FUNCs then have st_value != 0. > > I would like to see how uClibc ld.so behaves I could somehow get ld to not > generate any stubs in libpthread. Any idea why libpthread gets full stubs > when linked with uClibc libc.so but no stubs when linked with glibc libc.so? This looks like the problem we had with dlopen() and friends when introducing the new WEAK symbol handling. in libc/misc/pthread/weaks.c you have stuff like: weak_alias(__phtread_return_0, __phtread_once); where __phtread_return_0 is non NULL: int __phtread_return_0(void) { return 0; } From joakim.tjernlund@lumentis.se Mon May 10 13:36:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 13:36:34 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:22984 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 13:36:33 +0100 Received: from jockewin (fw [172.31.1.1]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4ACaPvC029223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 10 May 2004 14:36:25 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Richard Sandiford" Cc: , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Mon, 10 May 2004 14:36:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 4956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joakim.tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > > This looks like the problem we had with dlopen() and friends when introducing > the new WEAK symbol handling. > > in libc/misc/pthread/weaks.c you have stuff like: > weak_alias(__phtread_return_0, __phtread_once); > > where __phtread_return_0 is non NULL: > int __phtread_return_0(void) > { > return 0; > } > Changing the alias for __phtread_once to extern int __phtread_once(void) __attribute__ ((weak)); makes st_value=0 in libc, making the entry look the same as in glibc. Jocke From anemo@mba.ocn.ne.jp Mon May 10 14:26:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 14:26:43 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:13545 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Mon, 10 May 2004 14:26:41 +0100 Received: from localhost (p4173-ipad29funabasi.chiba.ocn.ne.jp [221.184.71.173]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id BAFA266D6; Mon, 10 May 2004 22:26:34 +0900 (JST) Date: Mon, 10 May 2004 22:28:45 +0900 (JST) Message-Id: <20040510.222845.78701815.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: geert@linux-m68k.org, jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit From: Atsushi Nemoto In-Reply-To: <20040509164835.GA28011@linux-mips.org> References: <20040509125750.GA19225@linux-mips.org> <20040509.225637.92590265.anemo@mba.ocn.ne.jp> <20040509164835.GA28011@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 4957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Sun, 9 May 2004 18:48:35 +0200, Ralf Baechle said: >> Hmm, many drivers use kmalloc and pci_map_single for DMA buffer. >> So ARCH_KMALLOC_MINALIGN should be L1_CACHE_BYTES for non-coherent >> system? ralf> No, those drivers are simply broken. dma_get_cache_alignment() ralf> gives the mimimum alignment and width for DMA mappings and that ralf> value is larger than kmalloc alignment in almost all cases. I see. Thank you for pointing out it. I must learn 2.6 DMA API quickly ... --- Atsushi Nemoto From ralf@linux-mips.org Mon May 10 15:06:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 15:06:11 +0100 (BST) Received: from p508B5AFA.dip.t-dialin.net ([IPv6:::ffff:80.139.90.250]:53075 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 15:06:10 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4AE68xT026864; Mon, 10 May 2004 16:06:08 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4AE66sq026863; Mon, 10 May 2004 16:06:06 +0200 Date: Mon, 10 May 2004 16:06:06 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: geert@linux-m68k.org, jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit Message-ID: <20040510140606.GA9312@linux-mips.org> References: <20040509125750.GA19225@linux-mips.org> <20040509.225637.92590265.anemo@mba.ocn.ne.jp> <20040509164835.GA28011@linux-mips.org> <20040510.222845.78701815.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040510.222845.78701815.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.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: 4958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 10, 2004 at 10:28:45PM +0900, Atsushi Nemoto wrote: > >> Hmm, many drivers use kmalloc and pci_map_single for DMA buffer. > >> So ARCH_KMALLOC_MINALIGN should be L1_CACHE_BYTES for non-coherent > >> system? > > ralf> No, those drivers are simply broken. dma_get_cache_alignment() > ralf> gives the mimimum alignment and width for DMA mappings and that > ralf> value is larger than kmalloc alignment in almost all cases. > > I see. Thank you for pointing out it. I must learn 2.6 DMA API > quickly ... This also applies to the 2.4 PCI DMA API. Ralf From joakim.tjernlund@lumentis.se Mon May 10 15:23:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 15:23:57 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:5352 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 15:23:33 +0100 Received: from jockewin (fw [172.31.1.1]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4AENNvC029493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 10 May 2004 16:23:23 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Richard Sandiford" Cc: , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Mon, 10 May 2004 16:23:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 4959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joakim.tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > Changing the alias for __phtread_once to > extern int __phtread_once(void) __attribute__ ((weak)); > makes st_value=0 in libc, making the entry > look the same as in glibc. hmm, this is not quite true. The binding in glibc is WEAK, but the above trick makes the binding GLOBAL in uClibc. Jocke PS I am on PPC, so I may be way off here w.r.t MIPS:( From em@realmagic.fr Mon May 10 15:24:54 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 15:24:55 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:13976 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 15:24:54 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4AEOq1q009711 for ; Mon, 10 May 2004 16:24:52 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4AEOpDo009709 for linux-mips@linux-mips.org; Mon, 10 May 2004 16:24:51 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: new platform From: Emmanuel Michon To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1084199090.12536.1314.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 May 2004 16:24:51 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips Hi, I plan to port linux-mips to a a 32bit 4KEc based (little endian) hardware design. I have three questions: Q1- The nice book `see mips run' states that it's better that the physical address map fits entirely in kseg1 (in 0x0-0x2000_0000). I would not be the first to plan for a lot of RAM and I understand HIGHMEM patch is ok if an extra RAM area is out of reach of kseg1. But what if my PCI devices I/O do not lie in kseg1? I may program the TLB to see them thru kseg2 (but kseg2 seems to be the place where page tables are stored...) Q2- Most hardware platforms have their SDRAM chips mapped at physical address 0x0. Mine does not. Am I going ahead of problems? It seems to be assumed at a lot of places (I have already ported YAMON). Q3- I'd rather stick to a 2.4.x linux port. But... should I use: a- the latest official 2.4.x kernel b- the latest 2.4.x-preY kernel c- the latest linux-mips.org 2.4.x kernel d- cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 ? Thanks for any useful advise. Sincerely yours, -- E.M. key A1A84D4C From sskowron@ET.PUT.Poznan.PL Mon May 10 15:53:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 15:53:32 +0100 (BST) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:21466 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 15:53:29 +0100 Received: from athena (athena [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4AErOg06489; Mon, 10 May 2004 16:53:24 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena (MailMonitor for SMTP v1.2.2 ) ; Mon, 10 May 2004 16:53:24 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4AErN922358; Mon, 10 May 2004 16:53:23 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Mon, 10 May 2004 16:53:23 +0200 (MET DST) From: Stanislaw Skowronek To: Emmanuel Michon cc: linux-mips@linux-mips.org Subject: Re: new platform In-Reply-To: <1084199090.12536.1314.camel@avalon.france.sdesigns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips > Q2- Most hardware platforms have their SDRAM chips mapped at > physical address 0x0. Mine does not. Am I going ahead of problems? > It seems to be assumed at a lot of places (I have already ported YAMON). I have run into very few problems of the sort on the Octane, which has all its memory just over CKSEG0. Most, if not all, of them would be gone if the Octane had anything at all in CKSEG0, not counting exception vectors (that reminds me, how do you handle exceptions? Linux assumes you *DO* have some writeable space at CKSEG0, at least a kilobyte - all exception handlers are copied there at runtime). You will have to change the kernel link address to the beginning of your physical RAM (or any other place you like, as long as it is under 512MB). It is easily done and I don't think it will cause any problems. Stanislaw Skowronek From em@realmagic.fr Mon May 10 16:02:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 16:02:09 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:42905 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 16:02:07 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4AF251q010161 for ; Mon, 10 May 2004 17:02:05 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4AF25BN010159 for linux-mips@linux-mips.org; Mon, 10 May 2004 17:02:05 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: Re: new platform From: Emmanuel Michon To: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1084201325.2219.1325.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 10 May 2004 17:02:05 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips On Mon, 2004-05-10 at 16:53, Stanislaw Skowronek wrote: > > Q2- Most hardware platforms have their SDRAM chips mapped at > > physical address 0x0. Mine does not. Am I going ahead of problems? > > It seems to be assumed at a lot of places (I have already ported YAMON). > > I have run into very few problems of the sort on the Octane, which has all > its memory just over CKSEG0. Most, if not all, of them would be gone if > the Octane had anything at all in CKSEG0, not counting exception vectors > (that reminds me, how do you handle exceptions? Linux assumes you *DO* > have some writeable space at CKSEG0, at least a kilobyte - all exception > handlers are copied there at runtime). It seems not all MIPS CPUs have the CP0 register EBase but mine does This one allows to use any value as exception base instead of 0x8000_0000 (that saves me: I will just point it at the base of my RAM). Sincerely yours, E.M. > > You will have to change the kernel link address to the beginning of your > physical RAM (or any other place you like, as long as it is under 512MB). > It is easily done and I don't think it will cause any problems. > > Stanislaw Skowronek > > > > From brad@laronde.org Mon May 10 19:05:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 19:05:36 +0100 (BST) Received: from ispmxmta05-srv.alltel.net ([IPv6:::ffff:166.102.165.166]:48055 "EHLO ispmxmta05-srv.alltel.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 19:05:35 +0100 Received: from lahoo.priv ([69.40.149.10]) by ispmxmta05-srv.alltel.net with ESMTP id <20040510180527.JJO6615.ispmxmta05-srv.alltel.net@lahoo.priv>; Mon, 10 May 2004 13:05:27 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect ident=ambassador) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BNF65-0000tL-00; Mon, 10 May 2004 14:01:49 -0400 Message-ID: <00e201c436b9$5fa0f450$8d01010a@prefect> From: "Bradley D. LaRonde" To: "Richard Sandiford" Cc: , References: <045b01c43155$1e06cd80$8d01010a@prefect><874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect> <87pt9cwwzu.fsf@redhat.com> Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Date: Mon, 10 May 2004 14:05:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4963 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Richard Sandiford" To: "Bradley D. LaRonde" Cc: ; Sent: Monday, May 10, 2004 3:40 AM Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value > "Bradley D. LaRonde" writes: > >> An object should never use stubs if takes the address of the function. > >> It should only use a stub for some symbol foo if every use of foo is > >> for a direct call. > > > > OK. So in a case where an object does take a pointer, does that mean that > > ld.so must fix the GOT entry for that symbol before handing control to the > > app (i.e. no lazy binding for that symbol)? > > Right. Such objects won't use a stub, they'll just have a normal > reference to an undefined symbol. The dynamic loader must resolve > it in the usual way. > > > I notice that the debian mipsel libpthread.so.0 in > > http://ftp.debian.org/pool/main/g/glibc/libc6_2.2.5-11.5_mipsel.deb has > > st_value == 0 for every UND FUNC, just like my x86 debian libraries. This > > is very different than the uClibc libpthread.so where every UND FUNC has > > st_value != 0. Interestingly if I link glibc's libpthread with uClibc's > > libc.so I see that most UND FUNCs then have st_value != 0. > > You said in your original message that you'd recently upgraded to binutils > 2.15-based tools. Was your libpthread.so built with them? If so, that would > explain it. I think earlier versions of ld were overly pessimistic about when > stubs could be used. Actually I did this round of testing with 2.14.90.0.7 to try and match debian. > FWIW, I have a glibc-based sysroot built with gcc 3.4 and binutils 2.15. > Its libpthread uses plenty of stubs. That's encouraging. I'll switch back to 2.15 and see if I can find why uClibc ld.so chooses the libpthread stub for libdl's malloc pointer. Even though it is pointing libdl to the libpthread stub for malloc, should it crash? The first call of the stub should cause the libdl GOT entry to be adjusted to point to the libc malloc? Should a subsequent call of the stub cause a crash? Regards, Brad From rsandifo@redhat.com Mon May 10 19:21:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 19:21:10 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:24742 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 19:21:09 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4AIL70m019758; Mon, 10 May 2004 14:21:07 -0400 Received: from localhost (mail@vpnuser4.surrey.redhat.com [172.16.9.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4AIL6v08276; Mon, 10 May 2004 14:21:06 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BNFOj-0006Fy-00; Mon, 10 May 2004 19:21:05 +0100 To: "Bradley D. LaRonde" Cc: , Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value References: <045b01c43155$1e06cd80$8d01010a@prefect> <874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect> <87pt9cwwzu.fsf@redhat.com> <00e201c436b9$5fa0f450$8d01010a@prefect> From: Richard Sandiford Date: Mon, 10 May 2004 19:21:04 +0100 In-Reply-To: <00e201c436b9$5fa0f450$8d01010a@prefect> (Bradley D. LaRonde's message of "Mon, 10 May 2004 14:05:27 -0400") Message-ID: <878yg0m9db.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: 4964 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@redhat.com Precedence: bulk X-list: linux-mips "Bradley D. LaRonde" writes: > Even though it is pointing libdl to the libpthread stub for malloc, should > it crash? Yeah. When you call a stub, $gp must already be set to the owning object's _gp. That's how the dynamic loader knows which GOT to change. In your case, libdl will be calling libpthread's stub with $gp set to libdl's _gp. The dynamic loader will therefore end up trying to change libdl's GOT, not libpthread's. Richard From sskowron@ET.PUT.Poznan.PL Mon May 10 20:22:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 20:22:06 +0100 (BST) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:28670 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 20:22:05 +0100 Received: from athena (athena [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4AJM3g09192 for ; Mon, 10 May 2004 21:22:03 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena (MailMonitor for SMTP v1.2.2 ) ; Mon, 10 May 2004 21:22:02 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4AJM2305583 for ; Mon, 10 May 2004 21:22:02 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Mon, 10 May 2004 21:22:02 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: Octane port - discoveries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4965 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips Well, I've just noticed that get_saved_sp (in asm.h) is purely 32-bit. After making a 64-bit-clean version (well, the Octane has its kernel_sp in xkphys, not in ckseg0) the system boots a little farther. Still, it gets a flagrant SIGSEGV, but at least it does not disappear without trace after going usermode. In fact it gets _infinite_ SIGSEGVs in mm/fault.c. Time to get back to work. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." From brad@laronde.org Mon May 10 21:36:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 21:36:27 +0100 (BST) Received: from ispmxmta06-srv.alltel.net ([IPv6:::ffff:166.102.165.167]:901 "EHLO ispmxmta06-srv.alltel.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 21:36:25 +0100 Received: from lahoo.priv ([69.40.149.10]) by ispmxmta06-srv.alltel.net with ESMTP id <20040510203614.FFKH5465.ispmxmta06-srv.alltel.net@lahoo.priv>; Mon, 10 May 2004 15:36:14 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BNHRz-0001IY-00; Mon, 10 May 2004 16:32:35 -0400 Message-ID: <01a901c436ce$7029d890$8d01010a@prefect> From: "Bradley D. LaRonde" To: "Richard Sandiford" Cc: , References: <045b01c43155$1e06cd80$8d01010a@prefect><874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect><87pt9cwwzu.fsf@redhat.com> <00e201c436b9$5fa0f450$8d01010a@prefect> <878yg0m9db.fsf@redhat.com> Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Date: Mon, 10 May 2004 16:36:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4966 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Richard Sandiford" To: "Bradley D. LaRonde" Cc: ; Sent: Monday, May 10, 2004 2:21 PM Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value > "Bradley D. LaRonde" writes: > > Even though it is pointing libdl to the libpthread stub for malloc, should > > it crash? > > Yeah. When you call a stub, $gp must already be set to the owning > object's _gp. That's how the dynamic loader knows which GOT to change. > > In your case, libdl will be calling libpthread's stub with $gp set to > libdl's _gp. The dynamic loader will therefore end up trying to change > libdl's GOT, not libpthread's. I read this in the spec: All externally visible symbols, both defined and undefined, must be hashed into the hash table. Should libpthread's malloc stub be added to the hash table? I guess not, but I think that might be happening (haven't verified), and libdl finding it in there and thinking it is the real deal, not realizing it is just a stub. Regards, Brad From rsandifo@redhat.com Mon May 10 21:41:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 21:41:57 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:11908 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 21:41:56 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4AKfs0m022436; Mon, 10 May 2004 16:41:54 -0400 Received: from localhost (mail@vpnuser4.surrey.redhat.com [172.16.9.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4AKfrv23584; Mon, 10 May 2004 16:41:53 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BNHaz-0003Ep-00; Mon, 10 May 2004 21:41:53 +0100 To: "Bradley D. LaRonde" Cc: , Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value References: <045b01c43155$1e06cd80$8d01010a@prefect> <874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect> <87pt9cwwzu.fsf@redhat.com> <00e201c436b9$5fa0f450$8d01010a@prefect> <878yg0m9db.fsf@redhat.com> <01a901c436ce$7029d890$8d01010a@prefect> From: Richard Sandiford Date: Mon, 10 May 2004 21:41:53 +0100 In-Reply-To: <01a901c436ce$7029d890$8d01010a@prefect> (Bradley D. LaRonde's message of "Mon, 10 May 2004 16:36:14 -0400") Message-ID: <87oeowkoa6.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: 4967 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@redhat.com Precedence: bulk X-list: linux-mips "Bradley D. LaRonde" writes: > I read this in the spec: > > All externally visible symbols, both defined and undefined, > must be hashed into the hash table. > > Should libpthread's malloc stub be added to the hash table? Yes. > I guess not, but I think that might be happening (haven't verified), > and libdl finding it in there and thinking it is the real deal, not > realizing it is just a stub. If you have an undefined function symbol with st_value != 0, then that st_value must be for a stub. That's how the loader can (and is supposed to) tell the difference. It's probably a good idea to look at how glibc handles this. Richard From rsandifo@redhat.com Mon May 10 21:44:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 21:44:11 +0100 (BST) Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:16005 "EHLO mx1.redhat.com") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 21:44:10 +0100 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i4AKi90m022851; Mon, 10 May 2004 16:44:09 -0400 Received: from localhost (mail@vpnuser4.surrey.redhat.com [172.16.9.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i4AKi8v24232; Mon, 10 May 2004 16:44:08 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1BNHdA-0003Ez-00; Mon, 10 May 2004 21:44:08 +0100 To: "Bradley D. LaRonde" Cc: , Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value References: <045b01c43155$1e06cd80$8d01010a@prefect> <874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect> <87pt9cwwzu.fsf@redhat.com> <00e201c436b9$5fa0f450$8d01010a@prefect> <878yg0m9db.fsf@redhat.com> <01a901c436ce$7029d890$8d01010a@prefect> <87oeowkoa6.fsf@redhat.com> From: Richard Sandiford Date: Mon, 10 May 2004 21:44:08 +0100 In-Reply-To: <87oeowkoa6.fsf@redhat.com> (Richard Sandiford's message of "Mon, 10 May 2004 21:41:53 +0100") Message-ID: <87k6zkko6f.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) 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: 4968 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rsandifo@redhat.com Precedence: bulk X-list: linux-mips Richard Sandiford writes: > "Bradley D. LaRonde" writes: >> I read this in the spec: >> >> All externally visible symbols, both defined and undefined, >> must be hashed into the hash table. >> >> Should libpthread's malloc stub be added to the hash table? > > Yes. Or, to be more precise, the symbol should be added to the hash table. The fact that the symbol is lazily bound doesn't matter. Richard From sskowron@ET.PUT.Poznan.PL Mon May 10 21:54:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 21:54:10 +0100 (BST) Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:11725 "EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 21:54:06 +0100 Received: from europa (europa.et.put.poznan.pl [150.254.29.138]) by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4AKs4b14442 for ; Mon, 10 May 2004 22:54:05 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ; Mon, 10 May 2004 22:54:04 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4AKs3N10134 for ; Mon, 10 May 2004 22:54:03 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Mon, 10 May 2004 22:54:03 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: Octane - first light! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips Well, we've got usermode now. There is no keyboard driver so I can't comment on interactive work (and I am too lazy to set up a complete telnet server :), but all interesting scripts I gave it worked. Network is OK, the QLogic SCSI driver does not work for some reason or another (it can't communicate with hardware - why?), the console driver is nice and seems to work rock-solid, high IRQ load (ping -f) does not break anything. I found another 32-bit infelicity in kernel/scall64-o32.S in stackargs: using subu instead of dsubu for jump address calculation... Any more of these and I will have an overflow exception on anger. Tomorrow, or somewhere in the next week I'm doing keyboard support. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." From ralf@linux-mips.org Mon May 10 22:49:29 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 10 May 2004 22:49:30 +0100 (BST) Received: from p508B5AFA.dip.t-dialin.net ([IPv6:::ffff:80.139.90.250]:64600 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 10 May 2004 22:49:29 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4ALnRxT012350; Mon, 10 May 2004 23:49:27 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4ALnR38012349; Mon, 10 May 2004 23:49:27 +0200 Date: Mon, 10 May 2004 23:49:27 +0200 From: Ralf Baechle To: Emmanuel Michon Cc: linux-mips@linux-mips.org Subject: Re: new platform Message-ID: <20040510214927.GB22442@linux-mips.org> References: <1084199090.12536.1314.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1084199090.12536.1314.camel@avalon.france.sdesigns.com> User-Agent: Mutt/1.4.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: 4970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 10, 2004 at 04:24:51PM +0200, Emmanuel Michon wrote: > I plan to port linux-mips to a a 32bit 4KEc based (little endian) > hardware design. > > I have three questions: > > Q1- The nice book `see mips run' states that it's better that the > physical address map fits entirely in kseg1 (in 0x0-0x2000_0000). > > I would not be the first to plan for a lot of RAM and I understand > HIGHMEM patch is ok if an extra RAM area is out of reach of kseg1. Using highmem in general is a baaad idea. The option only exists at all for MIPS because of a user who didn't want to try something as unorthodox as 64-bit kernels ... Highmem implies significant extra overhead and complexity for software that runs in kernel space. Avoid like the plague if you can. > But what if my PCI devices I/O do not lie in kseg1? I may program the > TLB to see them thru kseg2 (but kseg2 seems to be the place where page > tables are stored...) Doesn't really matter. It's nice to have devices in the lower 512MB of physical address space because that means the TLB will not be used - a nice performance bonus. Whatever - the driver API to use is ioremap. > Q2- Most hardware platforms have their SDRAM chips mapped at > physical address 0x0. Mine does not. Am I going ahead of problems? It won't work ;-) You at least need some memory at physical address zero because exception vectors are located in the first few k of physical address space. Of course you could avoid that by having the BEV bit set in the status register so exceptions would go via 0xbfc00000 - but that's an uncached address, likely even in a flash so performance would go down the drain ... > It seems to be assumed at a lot of places (I have already ported YAMON). > > Q3- I'd rather stick to a 2.4.x linux port. But... should I use: Depending on what exactly you want to do you should take a look at 2.6. > a- the latest official 2.4.x kernel > b- the latest 2.4.x-preY kernel kernel.org kernels won't work out of the box or at least your chances are worse due to the lag in merging MIPS code from to kernel.org. > c- the latest linux-mips.org 2.4.x kernel > d- cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 D - where C and D are the basically the same anyway - I've stopped making snapshot tarballs years ago, so you'll have to fetch from cvs. Ralf From brad@laronde.org Tue May 11 04:39:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 04:39:53 +0100 (BST) Received: from ispmxmta09-srv.alltel.net ([IPv6:::ffff:166.102.165.170]:18606 "EHLO ispmxmta09-srv.alltel.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 04:39:52 +0100 Received: from lahoo.priv ([69.40.149.10]) by ispmxmta09-srv.alltel.net with ESMTP id <20040511033942.OZXT13302.ispmxmta09-srv.alltel.net@lahoo.priv>; Mon, 10 May 2004 22:39:42 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BNO3k-0002P8-00; Mon, 10 May 2004 23:36:00 -0400 Message-ID: <02fd01c43709$981a24a0$8d01010a@prefect> From: "Bradley D. LaRonde" To: "Richard Sandiford" Cc: , References: <045b01c43155$1e06cd80$8d01010a@prefect><874qqpg2ti.fsf@redhat.com> <012701c43607$83aa65f0$8d01010a@prefect><87pt9cwwzu.fsf@redhat.com> <00e201c436b9$5fa0f450$8d01010a@prefect><878yg0m9db.fsf@redhat.com> <01a901c436ce$7029d890$8d01010a@prefect> <87oeowkoa6.fsf@redhat.com> Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Date: Mon, 10 May 2004 23:39:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Richard Sandiford" To: "Bradley D. LaRonde" Cc: ; Sent: Monday, May 10, 2004 4:41 PM Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value > "Bradley D. LaRonde" writes: > > I read this in the spec: > > > > All externally visible symbols, both defined and undefined, > > must be hashed into the hash table. > > > > Should libpthread's malloc stub be added to the hash table? > > Yes. > > > I guess not, but I think that might be happening (haven't verified), > > and libdl finding it in there and thinking it is the real deal, not > > realizing it is just a stub. > > If you have an undefined function symbol with st_value != 0, then > that st_value must be for a stub. That's how the loader can (and is > supposed to) tell the difference. > > It's probably a good idea to look at how glibc handles this. uClibc/ldso/ldso/mips/elfinterp.c around line 288 looks like this: /* Relocate the global GOT entries for the object */ while(i--) { if (sym->st_shndx == SHN_UNDEF) { if (ELF32_ST_TYPE(sym->st_info) == STT_FUNC && sym->st_value) *got_entry = sym->st_value + (unsigned long) tpnt->loadaddr; else { *got_entry = (unsigned long) _dl_find_hash(strtab + sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); } } If I change that ELF_RTYPE_CLASS_COPY to ELF_RTYPE_CLASS_PLT to tell _dl_find_hash to ignore stubs when resolving undefined functions without stubs, the dlopen tests all pass. dlopen gets a pointer to the libc.so malloc instead of a pointer to the libpthread malloc stub. Yay! :-) Does that look like the correct fix? Regards, Brad From Joakim.Tjernlund@lumentis.se Tue May 11 06:48:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 06:48:40 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:50759 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 06:48:39 +0100 Received: from Jocke (h248n1fls32o899.telia.com [213.67.177.248]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4B5mSvC030830 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 May 2004 07:48:29 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Richard Sandiford" Cc: , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Tue, 11 May 2004 07:48:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <02fd01c43709$981a24a0$8d01010a@prefect> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 4972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joakim.Tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > > uClibc/ldso/ldso/mips/elfinterp.c around line 288 looks like this: > > > /* Relocate the global GOT entries for the object */ > while(i--) { > if (sym->st_shndx == SHN_UNDEF) { > if (ELF32_ST_TYPE(sym->st_info) == STT_FUNC && sym->st_value) > *got_entry = sym->st_value + (unsigned long) tpnt->loadaddr; > else { > *got_entry = (unsigned long) _dl_find_hash(strtab + > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > } > } > > > If I change that ELF_RTYPE_CLASS_COPY to ELF_RTYPE_CLASS_PLT to tell > _dl_find_hash to ignore stubs when resolving undefined functions without > stubs, the dlopen tests all pass. dlopen gets a pointer to the libc.so > malloc instead of a pointer to the libpthread malloc stub. Yay! :-) > > Does that look like the correct fix? Hopefully, when I added ELF_RTYPE_CLASS_COPY/ELF_RTYPE_CLASS_PLT stuff I had to guess what to do with MIPS. After that several minor error has been fixed by changing these bits. Jocke From joakim.tjernlund@lumentis.se Tue May 11 08:28:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 08:28:08 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:27229 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 08:28:05 +0100 Received: from jockewin (fw [172.31.1.1]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4B7RmvC031005 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 May 2004 09:27:48 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Richard Sandiford" Cc: , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols withnonzerosymbol table entry st_value Date: Tue, 11 May 2004 09:27:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 4973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joakim.tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > > Changing the alias for __phtread_once to > > extern int __phtread_once(void) __attribute__ ((weak)); > > makes st_value=0 in libc, making the entry > > look the same as in glibc. > > hmm, this is not quite true. The binding in glibc is WEAK, but > the above trick makes the binding GLOBAL in uClibc. __phtread_once becoms WEAK if add "weak_function" to the declaration in libc/inet/rpc/rpc_thread.c: extern weak_function int __pthread_once (pthread_once_t *__once_control, void (*__init_routine) (void)); and remove the it compleatly from libc/misc/pthread/weaks.c Now __phtread_once matches glibc, execpt for the reloc type. In glibc you get a R_PPC_GLOB_DAT and in uClibc a R_PPC_ADDR32. Don't think that matters. Is it desirable to match the pthread_ functions with glibc? I havn't tried to run any code with these changes, so I have no idea if it actually works. Jocke From em@realmagic.fr Tue May 11 10:22:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 10:22:31 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:42920 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 10:22:28 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4B9MQ1q004741 for ; Tue, 11 May 2004 11:22:26 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4B9MMJE004739 for linux-mips@linux-mips.org; Tue, 11 May 2004 11:22:22 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: Re: new platform From: Emmanuel Michon To: linux-mips@linux-mips.org In-Reply-To: <20040510214927.GB22442@linux-mips.org> References: <1084199090.12536.1314.camel@avalon.france.sdesigns.com> <20040510214927.GB22442@linux-mips.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1084267342.2222.1348.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 May 2004 11:22:22 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips On Mon, 2004-05-10 at 23:49, Ralf Baechle wrote: > On Mon, May 10, 2004 at 04:24:51PM +0200, Emmanuel Michon wrote: > > > I plan to port linux-mips to a a 32bit 4KEc based (little endian) > > hardware design. > > > > I have three questions: > > > > Q1- The nice book `see mips run' states that it's better that the > > physical address map fits entirely in kseg1 (in 0x0-0x2000_0000). > > > > I would not be the first to plan for a lot of RAM and I understand > > HIGHMEM patch is ok if an extra RAM area is out of reach of kseg1. > > Using highmem in general is a baaad idea. The option only exists at all > for MIPS because of a user who didn't want to try something as unorthodox > as 64-bit kernels ... > > Highmem implies significant extra overhead and complexity for software > that runs in kernel space. Avoid like the plague if you can. > > > But what if my PCI devices I/O do not lie in kseg1? I may program the > > TLB to see them thru kseg2 (but kseg2 seems to be the place where page > > tables are stored...) > > Doesn't really matter. It's nice to have devices in the lower 512MB of > physical address space because that means the TLB will not be used - a > nice performance bonus. > > Whatever - the driver API to use is ioremap. You mean that after basic probing you always access PCI devices thru the TLB? > > > Q2- Most hardware platforms have their SDRAM chips mapped at > > physical address 0x0. Mine does not. Am I going ahead of problems? > > It won't work ;-) > > You at least need some memory at physical address zero because exception > vectors are located in the first few k of physical address space. Of > course you could avoid that by having the BEV bit set in the status > register so exceptions would go via 0xbfc00000 - but that's an uncached > address, likely even in a flash so performance would go down the drain ... Well my 4KEc core has a CP0 register called EBase (15 select 1) that allows to put the vectors anywhere (excepted reset/softreset/nmi/ejtag). > > > It seems to be assumed at a lot of places (I have already ported YAMON). > > > > Q3- I'd rather stick to a 2.4.x linux port. But... should I use: > > Depending on what exactly you want to do you should take a look at 2.6. > > > a- the latest official 2.4.x kernel > > b- the latest 2.4.x-preY kernel > > kernel.org kernels won't work out of the box or at least your chances > are worse due to the lag in merging MIPS code from to kernel.org. > > > c- the latest linux-mips.org 2.4.x kernel > > d- cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4 > > D - where C and D are the basically the same anyway - I've stopped making > snapshot tarballs years ago, so you'll have to fetch from cvs. Thanks Sincerely yours, E.M. > > Ralf > > From ralf@linux-mips.org Tue May 11 11:52:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 11:52:57 +0100 (BST) Received: from p508B5C3F.dip.t-dialin.net ([IPv6:::ffff:80.139.92.63]:43104 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 11:52:56 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4BAqtxT023625; Tue, 11 May 2004 12:52:55 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4BAqtcR023624; Tue, 11 May 2004 12:52:55 +0200 Date: Tue, 11 May 2004 12:52:54 +0200 From: Ralf Baechle To: Emmanuel Michon Cc: linux-mips@linux-mips.org Subject: Re: new platform Message-ID: <20040511105254.GA10172@linux-mips.org> References: <1084199090.12536.1314.camel@avalon.france.sdesigns.com> <20040510214927.GB22442@linux-mips.org> <1084267342.2222.1348.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1084267342.2222.1348.camel@avalon.france.sdesigns.com> User-Agent: Mutt/1.4.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: 4975 X-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, May 11, 2004 at 11:22:22AM +0200, Emmanuel Michon wrote: > > Whatever - the driver API to use is ioremap. > > You mean that after basic probing you always access PCI devices thru the > TLB? No. ioremap knows how to optimize this for physical addresses that are mapped via KSEG1. So this just doesn't matter to driver writers. Ralf From anemo@mba.ocn.ne.jp Tue May 11 14:50:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 14:50:57 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:62186 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Tue, 11 May 2004 14:50:56 +0100 Received: from localhost (p6029-ipad29funabasi.chiba.ocn.ne.jp [221.184.73.29]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 12023555B; Tue, 11 May 2004 22:50:52 +0900 (JST) Date: Tue, 11 May 2004 22:53:05 +0900 (JST) Message-Id: <20040511.225305.55510293.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: geert@linux-m68k.org, jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit From: Atsushi Nemoto In-Reply-To: <20040510140606.GA9312@linux-mips.org> References: <20040509164835.GA28011@linux-mips.org> <20040510.222845.78701815.anemo@mba.ocn.ne.jp> <20040510140606.GA9312@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 4976 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Mon, 10 May 2004 16:06:06 +0200, Ralf Baechle said: >> I see. Thank you for pointing out it. I must learn 2.6 DMA API >> quickly ... ralf> This also applies to the 2.4 PCI DMA API. But 2.4 PCI DMA API does not have dma_get_cache_alignment() (or equivalent), or am I missing something? --- Atsushi Nemoto From drow@crack.them.org Tue May 11 15:04:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 15:04:02 +0100 (BST) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:23953 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 15:04:01 +0100 Received: from drow by nevyn.them.org with local (Exim 4.33 #1 (Debian)) id 1BNXrL-0003U6-IY; Tue, 11 May 2004 10:03:51 -0400 Date: Tue, 11 May 2004 10:03:51 -0400 From: Daniel Jacobowitz To: "Bradley D. LaRonde" Cc: Richard Sandiford , uclibc@uclibc.org, linux-mips@linux-mips.org Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Message-ID: <20040511140351.GA13367@nevyn.them.org> References: <01a901c436ce$7029d890$8d01010a@prefect> <87oeowkoa6.fsf@redhat.com> <02fd01c43709$981a24a0$8d01010a@prefect> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02fd01c43709$981a24a0$8d01010a@prefect> User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Mon, May 10, 2004 at 11:39:41PM -0400, Bradley D. LaRonde wrote: > ----- Original Message ----- > From: "Richard Sandiford" > To: "Bradley D. LaRonde" > Cc: ; > Sent: Monday, May 10, 2004 4:41 PM > Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol > table entry st_value > > > > "Bradley D. LaRonde" writes: > > > I read this in the spec: > > > > > > All externally visible symbols, both defined and undefined, > > > must be hashed into the hash table. > > > > > > Should libpthread's malloc stub be added to the hash table? > > > > Yes. > > > > > I guess not, but I think that might be happening (haven't verified), > > > and libdl finding it in there and thinking it is the real deal, not > > > realizing it is just a stub. > > > > If you have an undefined function symbol with st_value != 0, then > > that st_value must be for a stub. That's how the loader can (and is > > supposed to) tell the difference. > > > > It's probably a good idea to look at how glibc handles this. > > uClibc/ldso/ldso/mips/elfinterp.c around line 288 looks like this: > > > /* Relocate the global GOT entries for the object */ > while(i--) { > if (sym->st_shndx == SHN_UNDEF) { > if (ELF32_ST_TYPE(sym->st_info) == STT_FUNC && sym->st_value) > *got_entry = sym->st_value + (unsigned long) tpnt->loadaddr; > else { > *got_entry = (unsigned long) _dl_find_hash(strtab + > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > } > } > > > If I change that ELF_RTYPE_CLASS_COPY to ELF_RTYPE_CLASS_PLT to tell > _dl_find_hash to ignore stubs when resolving undefined functions without > stubs, the dlopen tests all pass. dlopen gets a pointer to the libc.so > malloc instead of a pointer to the libpthread malloc stub. Yay! :-) > > Does that look like the correct fix? Probably, since MIPS doesn't have a copy reloc. -- Daniel Jacobowitz From ralf@linux-mips.org Tue May 11 15:05:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 15:05:15 +0100 (BST) Received: from p508B5C3F.dip.t-dialin.net ([IPv6:::ffff:80.139.92.63]:38498 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 15:05:15 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4BE59xT006683; Tue, 11 May 2004 16:05:09 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4BE57ki006682; Tue, 11 May 2004 16:05:07 +0200 Date: Tue, 11 May 2004 16:05:07 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: geert@linux-m68k.org, jsun@mvista.com, linux-mips@linux-mips.org Subject: Re: semaphore woes in 2.6, 32bit Message-ID: <20040511140507.GA32577@linux-mips.org> References: <20040509164835.GA28011@linux-mips.org> <20040510.222845.78701815.anemo@mba.ocn.ne.jp> <20040510140606.GA9312@linux-mips.org> <20040511.225305.55510293.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040511.225305.55510293.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.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: 4978 X-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, May 11, 2004 at 10:53:05PM +0900, Atsushi Nemoto wrote: > >> I see. Thank you for pointing out it. I must learn 2.6 DMA API > >> quickly ... > > ralf> This also applies to the 2.4 PCI DMA API. > > But 2.4 PCI DMA API does not have dma_get_cache_alignment() (or > equivalent), or am I missing something? No, you don't; that was a problem in the 2.4 DMA API which got fixed in 2.5. For 2.4 using L1_CACHE_BYTES from is a reasonable alternative. Ralf From brad@laronde.org Tue May 11 15:21:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 15:21:48 +0100 (BST) Received: from ispmxmta05-srv.alltel.net ([IPv6:::ffff:166.102.165.166]:32432 "EHLO ispmxmta05-srv.alltel.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 15:21:47 +0100 Received: from lahoo.priv ([69.40.149.10]) by ispmxmta05-srv.alltel.net with ESMTP id <20040511142133.BLVU6615.ispmxmta05-srv.alltel.net@lahoo.priv>; Tue, 11 May 2004 09:21:33 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BNY4q-00044Z-00; Tue, 11 May 2004 10:17:48 -0400 Message-ID: <046a01c43763$42feeeb0$8d01010a@prefect> From: "Bradley D. LaRonde" To: "Daniel Jacobowitz" Cc: "Richard Sandiford" , , References: <01a901c436ce$7029d890$8d01010a@prefect> <87oeowkoa6.fsf@redhat.com> <02fd01c43709$981a24a0$8d01010a@prefect> <20040511140351.GA13367@nevyn.them.org> Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Date: Tue, 11 May 2004 10:21:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4979 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Daniel Jacobowitz" To: "Bradley D. LaRonde" Cc: "Richard Sandiford" ; ; Sent: Tuesday, May 11, 2004 10:03 AM Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value > On Mon, May 10, 2004 at 11:39:41PM -0400, Bradley D. LaRonde wrote: > > ----- Original Message ----- > > From: "Richard Sandiford" > > To: "Bradley D. LaRonde" > > Cc: ; > > Sent: Monday, May 10, 2004 4:41 PM > > Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol > > table entry st_value > > > > > > > "Bradley D. LaRonde" writes: > > > > I read this in the spec: > > > > > > > > All externally visible symbols, both defined and undefined, > > > > must be hashed into the hash table. > > > > > > > > Should libpthread's malloc stub be added to the hash table? > > > > > > Yes. > > > > > > > I guess not, but I think that might be happening (haven't verified), > > > > and libdl finding it in there and thinking it is the real deal, not > > > > realizing it is just a stub. > > > > > > If you have an undefined function symbol with st_value != 0, then > > > that st_value must be for a stub. That's how the loader can (and is > > > supposed to) tell the difference. > > > > > > It's probably a good idea to look at how glibc handles this. > > > > uClibc/ldso/ldso/mips/elfinterp.c around line 288 looks like this: > > > > > > /* Relocate the global GOT entries for the object */ > > while(i--) { > > if (sym->st_shndx == SHN_UNDEF) { > > if (ELF32_ST_TYPE(sym->st_info) == STT_FUNC && sym->st_value) > > *got_entry = sym->st_value + (unsigned long) tpnt->loadaddr; > > else { > > *got_entry = (unsigned long) _dl_find_hash(strtab + > > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > > } > > } > > > > > > If I change that ELF_RTYPE_CLASS_COPY to ELF_RTYPE_CLASS_PLT to tell > > _dl_find_hash to ignore stubs when resolving undefined functions without > > stubs, the dlopen tests all pass. dlopen gets a pointer to the libc.so > > malloc instead of a pointer to the libpthread malloc stub. Yay! :-) > > > > Does that look like the correct fix? > > Probably, since MIPS doesn't have a copy reloc. How about the other copy reloc right below there: else if (sym->st_shndx == SHN_COMMON) { *got_entry = (unsigned long) _dl_find_hash(strtab + sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); } ? Regards, Brad From drow@crack.them.org Tue May 11 15:23:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 15:23:07 +0100 (BST) Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:37521 "EHLO nevyn.them.org") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 15:23:06 +0100 Received: from drow by nevyn.them.org with local (Exim 4.33 #1 (Debian)) id 1BNY9s-0003iB-6I; Tue, 11 May 2004 10:23:00 -0400 Date: Tue, 11 May 2004 10:23:00 -0400 From: Daniel Jacobowitz To: "Bradley D. LaRonde" Cc: Richard Sandiford , uclibc@uclibc.org, linux-mips@linux-mips.org Subject: Re: uclibc mips ld.so and undefined symbols with nonzero symbol table entry st_value Message-ID: <20040511142300.GA14242@nevyn.them.org> References: <01a901c436ce$7029d890$8d01010a@prefect> <87oeowkoa6.fsf@redhat.com> <02fd01c43709$981a24a0$8d01010a@prefect> <20040511140351.GA13367@nevyn.them.org> <046a01c43763$42feeeb0$8d01010a@prefect> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046a01c43763$42feeeb0$8d01010a@prefect> User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Tue, May 11, 2004 at 10:21:33AM -0400, Bradley D. LaRonde wrote: > How about the other copy reloc right below there: > > else if (sym->st_shndx == SHN_COMMON) { > *got_entry = (unsigned long) _dl_find_hash(strtab + > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > } I don't know anything about the uclibc linker code, so I'm not sure. That's probably OK as future proofing against a copy reloc someday. -- Daniel Jacobowitz From joakim.tjernlund@lumentis.se Tue May 11 17:34:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 17:34:03 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:50128 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 17:34:02 +0100 Received: from jockewin (fw [172.31.1.1]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4BGXnvC031779 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 May 2004 18:33:49 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Daniel Jacobowitz" Cc: , "Richard Sandiford" , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Tue, 11 May 2004 18:33:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <046a01c43763$42feeeb0$8d01010a@prefect> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: 4981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joakim.tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > > > > Probably, since MIPS doesn't have a copy reloc. > > How about the other copy reloc right below there: > > else if (sym->st_shndx == SHN_COMMON) { > *got_entry = (unsigned long) _dl_find_hash(strtab + > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > } > > ? Perhaps DL_NO_COPY_RELOCS should be defined for MIPS then? see ldso/include/dl-elf.h. Jocke From brad@laronde.org Tue May 11 17:55:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 17:55:38 +0100 (BST) Received: from ispmxmta06-srv.alltel.net ([IPv6:::ffff:166.102.165.167]:10965 "EHLO ispmxmta06-srv.alltel.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 17:55:37 +0100 Received: from lahoo.priv ([69.40.149.10]) by ispmxmta06-srv.alltel.net with ESMTP id <20040511165527.EIAK5465.ispmxmta06-srv.alltel.net@lahoo.priv>; Tue, 11 May 2004 11:55:27 -0500 Received: from prefect.priv ([10.1.1.141] helo=prefect) by lahoo.priv with smtp (Exim 3.36 #1 (Debian)) id 1BNaTk-0004Tn-00; Tue, 11 May 2004 12:51:40 -0400 Message-ID: <053f01c43778$c2903390$8d01010a@prefect> From: "Bradley D. LaRonde" To: "Joakim Tjernlund" , "Daniel Jacobowitz" Cc: , "Richard Sandiford" , References: Subject: Re: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Tue, 11 May 2004 12:55:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4982 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@laronde.org Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Joakim Tjernlund" To: "Bradley D. LaRonde" ; "Daniel Jacobowitz" Cc: ; "Richard Sandiford" ; Sent: Tuesday, May 11, 2004 12:33 PM Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value > > > > > > Probably, since MIPS doesn't have a copy reloc. > > > > How about the other copy reloc right below there: > > > > else if (sym->st_shndx == SHN_COMMON) { > > *got_entry = (unsigned long) _dl_find_hash(strtab + > > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > > } > > > > ? > > Perhaps DL_NO_COPY_RELOCS should be defined for MIPS then? > see ldso/include/dl-elf.h. For mips glibc 2.3.3 does: #define elf_machine_type_class(type) ELF_RTYPE_CLASS_PLT and never uses ELF_RTYPE_CLASS_COPY directly (though it does use ELF_RTYPE_CLASS_PLT directly). Regards, Brad From jbglaw@dvmwest.gt.owl.de Tue May 11 18:07:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 18:07:23 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:44773 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 18:07:22 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id B247A4B6A1; Tue, 11 May 2004 19:07:20 +0200 (CEST) Date: Tue, 11 May 2004 19:07:20 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: [Semi-OT] Example on how to use crosstool.sh Message-ID: <20040511170720.GV1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q/AGl/UrDvkbRExF" Content-Disposition: inline X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --Q/AGl/UrDvkbRExF Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Here's an example on how I use Dan Kegel's crosstool.sh script: ----------------------------------------------------------- #!/bin/sh PREFIX=3D/home/jbglaw/cross_jb/install \ BUILD_DIR=3Dxx_build \ SRC_DIR=3D. \ BINUTILS_DIR=3Dbinutils-2.15.91 \ GCC_DIR=3Dgcc-HEAD-20040509 \ GLIBC_DIR=3Dglibc-2.3.2 \ LINUX_DIR=3Dlinux-2.6.x \ TARGET=3Dalpha-linux \ TARGET_CFLAGS=3D"-O -g" \ BUILD=3D`/usr/share/misc/config.guess` \ USE_SYSROOT=3Dyes \ PARALLELMFLAGS=3D"-j2" \ KERNEL_CONFIG=3Dconfig-alpha ./crosstool.sh ----------------------------------------------------------- PREFIX is where all your crosscompiler tools will be installed into BUILD_DIR is where some subdirs will be created to build all the parts. You need some MBs free there:) SRC_DIR This is where all the source sub-directories (GCC_DIR, GLIBC_DIR, LINUX_DIR, BINUTILS_DIR) are in GCC_DIR, GLIBC_DIR, LINUX_DIR, BINUTILS_DIR Subdirs within SRC_DIR that contain the actual sources TARGET Guess it:) TARGET_CFLAGS CFLAGS used to for the toolchain to be created. "-O -g" to have them optimized, as well as keep debug infos (in case the compilers crash, you may want to help toolchain people to debug the problem). USE_SYSROOT Internal flag, which changes the destination directory for some target-relevant files. I admit I haven't yet understood that throughoutly:) PARALLELMFLAGS Have a SMP machine? KERNEL_CONFIG A ./linux/.config file for the kernel in LINUX_DIR. Used to get proper kernel header files. BUILD This machine's GNU quadrupel. Call config.guess to get it; if you don't supply it, crosstool.sh will try to call ./config.guess, which doesn't exist if you copy crosstool.sh out of Dan Kegel's distribution:) MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --Q/AGl/UrDvkbRExF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAoQhIHb1edYOZ4bsRAmQMAJ9wRMpdaix6ZNhfrAZ2nbI/GXIs5ACfflB5 uYMRA0A1lET1kn2z/QSU86Y= =XUpE -----END PGP SIGNATURE----- --Q/AGl/UrDvkbRExF-- From sskowron@ET.PUT.Poznan.PL Tue May 11 18:56:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 18:56:52 +0100 (BST) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:15355 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 18:56:51 +0100 Received: from athena (athena [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4BHufg23154 for ; Tue, 11 May 2004 19:56:41 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena (MailMonitor for SMTP v1.2.2 ) ; Tue, 11 May 2004 19:56:40 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4BHue408450 for ; Tue, 11 May 2004 19:56:40 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Tue, 11 May 2004 19:56:40 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: IOC3 interrupt management Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips Well, there is a problem _again_. This time it's a purely conceptual one. The IOC3 on Octanes (maybe on Onyx2es, too) controls the Ethernet, keyboard, mouse, serial and parallel ports and SGI alone knows what else. It is also tied to (at least) two bridge interrupts. One is used solely for Ethernet, and the other one is used for all the SuperIO stuff. Well, I'm an educated man (when it comes to Octane internals, that is) and I know that the first interrupt is 2 and the other is 4, and that they map to IRQ10 and IRQ12, respectively. But how should the poor kernel know about such arcanes? There is not a word in the IOC3 registers about this weird connection so the PCI drivers don't know about it at all. Now this is not a problem - I could simply assume that all IOC3s will have another IRQ at irq_num+2. But, MENET of course is build of four IOC3s and is definitely arranged in some other way. And what about the single IOC3 cards? Do they have the other IRQ at all, or don't they allow using SuperIO? This will all end in a kludge. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." From Joakim.Tjernlund@lumentis.se Tue May 11 22:51:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 May 2004 22:51:27 +0100 (BST) Received: from [IPv6:::ffff:212.105.56.244] ([IPv6:::ffff:212.105.56.244]:40667 "EHLO dmz.lumentis.net") by linux-mips.org with ESMTP id ; Tue, 11 May 2004 22:51:04 +0100 Received: from Jocke (h248n1fls32o899.telia.com [213.67.177.248]) (authenticated bits=0) by dmz.lumentis.net (8.12.8/8.12.8) with ESMTP id i4BLojvC032079 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 11 May 2004 23:50:46 +0200 From: "Joakim Tjernlund" To: "Bradley D. LaRonde" , "Daniel Jacobowitz" Cc: , "Richard Sandiford" , Subject: RE: [uClibc] Re: uclibc mips ld.so and undefined symbols with nonzerosymbol table entry st_value Date: Tue, 11 May 2004 23:50:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <053f01c43778$c2903390$8d01010a@prefect> 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: 4985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Joakim.Tjernlund@lumentis.se Precedence: bulk X-list: linux-mips > > > > > > > > Probably, since MIPS doesn't have a copy reloc. > > > > > > How about the other copy reloc right below there: > > > > > > else if (sym->st_shndx == SHN_COMMON) { > > > *got_entry = (unsigned long) _dl_find_hash(strtab + > > > sym->st_name, tpnt->symbol_scope, ELF_RTYPE_CLASS_COPY); > > > } > > > > > > ? > > > > Perhaps DL_NO_COPY_RELOCS should be defined for MIPS then? > > see ldso/include/dl-elf.h. > > For mips glibc 2.3.3 does: > > #define elf_machine_type_class(type) ELF_RTYPE_CLASS_PLT > > and never uses ELF_RTYPE_CLASS_COPY directly (though it does use > ELF_RTYPE_CLASS_PLT directly). > > Regards, > Brad > Good, try replacing all ELF_RTYPE_CLASS_COPY with ELF_RTYPE_CLASS_PLT in mips/elfinterp.c and define DL_NO_COPY_RELOCS in mips/dl-sysdep.h Jocke From ralf@linux-mips.org Thu May 13 01:14:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 01:14:10 +0100 (BST) Received: from p508B59C7.dip.t-dialin.net ([IPv6:::ffff:80.139.89.199]:6520 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 01:14:08 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4D0E5xT020385; Thu, 13 May 2004 02:14:05 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4D0E5fT020384; Thu, 13 May 2004 02:14:05 +0200 Date: Thu, 13 May 2004 02:14:05 +0200 From: Ralf Baechle To: Stanislaw Skowronek Cc: linux-mips@linux-mips.org Subject: Re: IOC3 interrupt management Message-ID: <20040513001405.GC18513@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.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: 4986 X-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, May 11, 2004 at 07:56:40PM +0200, Stanislaw Skowronek wrote: > Well, there is a problem _again_. This time it's a purely conceptual one. > > The IOC3 on Octanes (maybe on Onyx2es, too) controls the Ethernet, > keyboard, mouse, serial and parallel ports and SGI alone knows what else. > > It is also tied to (at least) two bridge interrupts. One is used solely > for Ethernet, and the other one is used for all the SuperIO stuff. > > Well, I'm an educated man (when it comes to Octane internals, that is) > and I know that the first interrupt is 2 and the other is 4, and that they > map to IRQ10 and IRQ12, respectively. But how should the poor kernel know > about such arcanes? There is not a word in the IOC3 registers about this > weird connection so the PCI drivers don't know about it at all. > > Now this is not a problem - I could simply assume that all IOC3s will have > another IRQ at irq_num+2. But, MENET of course is build of four IOC3s and > is definitely arranged in some other way. And what about the single IOC3 > cards? Do they have the other IRQ at all, or don't they allow using > SuperIO? PCI only permits INTA that is a single interrupt for normal devices. In good old tradition of violating the PCI spec the IOC3 has two interrupt pins. IP27 and IOC3 cards INTA and INTB are wired together, so we're back to PCI compliance, no problem ... So, Octane is different ... I suggest you treat ethernet as a normal PCI device - the Linux PCI code doesn't know how to handle anything else. Then in ioc3-eth.c itself you can register the serial interface with 8250.c and using the appropriate interrupt number. Everything along the lines of MENET - but of course different ;-) Ralf From wuming@ict.ac.cn Thu May 13 07:28:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 07:28:21 +0100 (BST) Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:59282 "HELO mail.ict.ac.cn") by linux-mips.org with SMTP id ; Thu, 13 May 2004 07:28:20 +0100 Received: (qmail 24189 invoked from network); 13 May 2004 06:16:30 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.188) by mail.ict.ac.cn with SMTP; 13 May 2004 06:16:30 -0000 Message-ID: <40A31578.2080400@ict.ac.cn> Date: Thu, 13 May 2004 14:28:08 +0800 From: wuming User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.2.1) Gecko/20030225 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: sorry, test whether I have subscribed 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: 4987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wuming@ict.ac.cn Precedence: bulk X-list: linux-mips after I have subscribed, I have never received any mail for a long time! please forgive me! From wuming@ict.ac.cn Thu May 13 07:53:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 07:53:07 +0100 (BST) Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:48788 "HELO mail.ict.ac.cn") by linux-mips.org with SMTP id ; Thu, 13 May 2004 07:53:05 +0100 Received: (qmail 30892 invoked from network); 13 May 2004 06:41:15 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.188) by mail.ict.ac.cn with SMTP; 13 May 2004 06:41:15 -0000 Message-ID: <40A31B45.7060204@ict.ac.cn> Date: Thu, 13 May 2004 14:52:53 +0800 From: wuming User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.2.1) Gecko/20030225 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: problems on D-cache alias in 2.4.22 Content-Type: text/plain; charset=gb2312 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: 4988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wuming@ict.ac.cn Precedence: bulk X-list: linux-mips I am developing in linux-2.4.22 on the machine with virtual address indexed and physical address tagged. But when I compile some application programs, I met the following error: cc1: internal compiler error: Segmentation fault I have searched about this error from internet, it's due to some hardware fault or a wrong pte fault handler. Because my machine have D-cache aliasing, so I think this error should be due to a wrong pte fault handler. After my painful kernel hacking, I found some strange problems and it's in function __update_cache( ): void __update_cache(struct vm_area_struct *vma, unsigned long address, pte_t pte) { unsigned long addr; struct page *page; if (!cpu_has_dc_aliases) return; page = pte_page(pte); /*This printk is added by myself*/ printk("<1>valid page:%d\tpage mapping:0x%p\tpage flags:%d\n",\ VALID_PAGE(page), page->mapping, (page->flags & (1UL << PG_dcache_dirty))); if (VALID_PAGE(page) && page->mapping && (page->flags & (1UL << PG_dcache_dirty))) { if (pages_do_alias((unsigned long) page_address(page), address & PAGE_MASK)) { addr = (unsigned long) page_address(page); flush_data_cache_page(addr); } ClearPageDcacheDirty(page); } } When my kernel is running, I found the condition "page->mapping" and "(page->flags & (1UL << PG_dcache_dirty))" will never be true at the same time. so the function flush_data_cache_page( ) will never be called. Then I commented the two condition, the compiler error disappeared. I do not understand the phenomenon very clearly, so I need some help. From jbglaw@dvmwest.gt.owl.de Thu May 13 14:25:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 14:25:04 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:50346 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 14:25:03 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 8980F4B5B5; Thu, 13 May 2004 15:25:01 +0200 (CEST) Date: Thu, 13 May 2004 15:25:01 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: IOC3 interrupt management Message-ID: <20040513132501.GC1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <20040513001405.GC18513@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="92jpbWK/k6ZbIj2k" Content-Disposition: inline In-Reply-To: <20040513001405.GC18513@linux-mips.org> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --92jpbWK/k6ZbIj2k Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2004-05-13 02:14:05 +0200, Ralf Baechle wrote in message <20040513001405.GC18513@linux-mips.org>: > On Tue, May 11, 2004 at 07:56:40PM +0200, Stanislaw Skowronek wrote: > So, Octane is different ... I suggest you treat ethernet as a normal PCI > device - the Linux PCI code doesn't know how to handle anything else. Th= en > in ioc3-eth.c itself you can register the serial interface with 8250.c Sig'ed. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --92jpbWK/k6ZbIj2k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAo3ctHb1edYOZ4bsRAiKJAJ9mKHTJ4SGv4f1GHggXTTVHELRuCACcCQJQ P7aEPtoT0z7ic0A7SyzVajY= =sfsr -----END PGP SIGNATURE----- --92jpbWK/k6ZbIj2k-- From thomas.koeller@baslerweb.com Thu May 13 15:41:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 15:41:54 +0100 (BST) Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:15376 "EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 15:41:53 +0100 Received: from comm1.baslerweb.com ([172.16.13.2]) by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 13 May 2004 16:41:26 +0200 Received: from [172.16.13.253] (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHN38QLP; Thu, 13 May 2004 16:41:50 +0200 From: Thomas Koeller Organization: Basler AG To: linux-mips@linux-mips.org Subject: Re: titan ethernet driver Date: Thu, 13 May 2004 16:44:26 +0200 User-Agent: KMail/1.6.1 Cc: Ralf Baechle , lachwani@pmc-sierra.com References: <200403261512.06502.thomas.koeller@baslerweb.com> <20040326212001.GA4927@linux-mips.org> In-Reply-To: <20040326212001.GA4927@linux-mips.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405131644.26009.thomas.koeller@baslerweb.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: 4990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips On Friday, March 26th, 2004 Ralf Baechle wrote: > On Fri, Mar 26, 2004 at 03:12:06PM +0100, Thomas Koeller wrote: > > I am trying to use your titan ethernet driver. I > > found that I could not compile it for a 2.6.4 > > kernel, because it uses 2.4 kernel APIs. When > > fixing that I found that the code contains > > obvious errors; it does not even compile unchanged. > > This makes me a bit uneasy. Would you mind > > commenting on the state of this driver? Are there > > any newer sources than those contained in CVS at > > linux-mips.org? > > I'm going to fix Yosemite / Titan support in 2.6 asap - as soon as I get > the board which should be somewhen next week. > > Ralf I see work going on for the titan ge driver, but AFAIK the only platform supporting this hardware is the yosemite board, and the board support has not been updated for months and is still non-functional. So I wonder how these changes are tested - or am I missing something? tk -- -------------------------------------------------- Thomas Koeller, Software Development Basler Vision Technologies thomas dot koeller at baslerweb dot com http://www.baslerweb.com ============================== From Manish_Lachwani@pmc-sierra.com Thu May 13 17:35:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 17:35:19 +0100 (BST) Received: from father.pmc-sierra.com ([IPv6:::ffff:216.241.224.13]:46546 "HELO father.pmc-sierra.bc.ca") by linux-mips.org with SMTP id ; Thu, 13 May 2004 17:35:17 +0100 Received: (qmail 27608 invoked from network); 13 May 2004 16:35:06 -0000 Received: from unknown (HELO ogyruan.pmc-sierra.bc.ca) (216.241.226.236) by father.pmc-sierra.com with SMTP; 13 May 2004 16:35:06 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogyruan.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id i4DGZ0Kr029978; Thu, 13 May 2004 09:35:00 -0700 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Thu, 13 May 2004 09:35:00 -0700 Message-ID: <9DFF23E1E33391449FDC324526D1F259022536FB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> From: Manish Lachwani To: "'Thomas Koeller'" , linux-mips@linux-mips.org Cc: Ralf Baechle Subject: RE: titan ethernet driver Date: Thu, 13 May 2004 09:26:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Manish_Lachwani@pmc-sierra.com Precedence: bulk X-list: linux-mips Are you referring to 2.4 or 2.6? You have already downloaded 2.4.26 and 2.4.21 versions (with source code) from the PMC-Sierra ftp site. These are fully functional and several customers are using it from the last 3-4 months now. The patches for 2.4 have been sent out to Ralf. As far as 2.6 goes, when it is ready, we will let you know -----Original Message----- From: Thomas Koeller [mailto:thomas.koeller@baslerweb.com] Sent: Thursday, May 13, 2004 7:44 AM To: linux-mips@linux-mips.org Cc: Ralf Baechle; Manish Lachwani Subject: Re: titan ethernet driver On Friday, March 26th, 2004 Ralf Baechle wrote: > On Fri, Mar 26, 2004 at 03:12:06PM +0100, Thomas Koeller wrote: > > I am trying to use your titan ethernet driver. I > > found that I could not compile it for a 2.6.4 > > kernel, because it uses 2.4 kernel APIs. When > > fixing that I found that the code contains > > obvious errors; it does not even compile unchanged. > > This makes me a bit uneasy. Would you mind > > commenting on the state of this driver? Are there > > any newer sources than those contained in CVS at > > linux-mips.org? > > I'm going to fix Yosemite / Titan support in 2.6 asap - as soon as I get > the board which should be somewhen next week. > > Ralf I see work going on for the titan ge driver, but AFAIK the only platform supporting this hardware is the yosemite board, and the board support has not been updated for months and is still non-functional. So I wonder how these changes are tested - or am I missing something? tk -- -------------------------------------------------- Thomas Koeller, Software Development Basler Vision Technologies thomas dot koeller at baslerweb dot com http://www.baslerweb.com ============================== From joerg@factorlocal.de Thu May 13 18:31:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 18:31:10 +0100 (BST) Received: from h-213.61.96.13.host.de.colt.net ([IPv6:::ffff:213.61.96.13]:20713 "EHLO aurora.factorlocal.de") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 18:31:09 +0100 Received: from dev7.factorlocal.de ([192.168.168.7] helo=[192.168.168.221]) by aurora.factorlocal.de with asmtp (Exim 4.20) id 1BOK31-0008Pp-68 for linux-mips@linux-mips.org; Thu, 13 May 2004 19:31:07 +0200 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> Content-Type: text/plain; charset=US-ASCII; format=flowed To: linux-mips@linux-mips.org From: Joerg Rossdeutscher Subject: RaQ2: Installation stops at "loading debian installer" Date: Thu, 13 May 2004 19:31:05 +0200 X-Mailer: Apple Mail (2.613) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joerg@factorlocal.de Precedence: bulk X-list: linux-mips Hi, step by step... :-) The RaQ2 boots the debian-installer-b4 via tftp and nfs until the display shows "Loading debian installer". Then it stops. I now have found an old Laptop that still has a serial port. The last lines say: >execute initrd={initrd-size}@{initrd-start} console=ttyS0,{console-speed} elf: 80080000 <-- 00001000 1916928t+176112t elf: entry 801fc040 net: interface down (I type this by hand, so excuse possibly errors) That's it. Ethereal shows no more net traffic and no remarkable errors before the installation stops. Nothings happens. And nothing at google for this message. Hm. Any ideas someone? Bye, Ratti -- _____________________________ Joerg Rossdeutscher Factor Design AG Schulterblatt 58 20357 Hamburg Germany T +49.40.432 571-43 F +49.40.432 571-99 E-mail: joerg@factordesign.com http://www.factordesign.com From kieran@pawsoff.org Thu May 13 19:31:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 19:31:06 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:39430 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 19:31:04 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 079A4387CF1; Thu, 13 May 2004 19:30:59 +0100 (BST) Date: Thu, 13 May 2004 19:30:59 +0100 To: linux-mips@linux-mips.org Subject: IRQ problem on cobalt / 2.6.6 Message-ID: <20040513183059.GA25743@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi folks,=20 getting the below when loading the dvb budget_ci module. it disables IRQ=20 #23 which is attached to the card, rendering it useless. i asked the=20 same question over there and none of them suspect it to be a DVB=20 problem. some esoteric pci bug perhaps? lspci -vv 0000:00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev=20 01) Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1011 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-=20 ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=3Dmedium >TAbort-= =20 SERR- ] [<8008461c>] [<80084720>] [<800b179c>] =20 [<800b1788>] [<80084a78>] [<800b1af8>] [<800826d0>] [<800ac718>] =20 [<80082ec0>] [<801593c0>] [<800ac7f4>] [<80084b18>] [<800ac6f8>] =20 [<80084578>] [<80084578>] [<800ac7f4>] [<80084b18>] [<80082ec0>] =20 [<800826d0>] [<80082ec0>] [<801594a4>] [<801593c0>] [<80085468>] =20 [<80085480>] [<8019c624>] [<8019c610>] [] [<80084bec>] =20 [<8015bff8>] [<800ce3ec>] [<800ce3ec>] [] [<80126eb8>] =20 [<8015d338>] [] [<801780e0>] [<8015d3a0>] [<8015d7b4>] =20 [<8015d408>] [<80153bf4>] [<80178eb0>] [<80154140>] [<80154018>] =20 [<80154258>] [<80178fec>] [<80179284>] [<80179608>] [<800a83e4>] =20 [<800a8264>] [<8015d684>] [<800a81d4>] [] [] =20 [] [<800c2b98>] [<800c2b40>] [<800e7ef0>] [<8008be88>] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; 80084624 <__report_bad_irq+48/8c> Trace; 8008461c <__report_bad_irq+40/8c> Trace; 80084720 Trace; 800b179c Trace; 800b1788 Trace; 80084a78 Trace; 800b1af8 Trace; 800826d0 Trace; 800ac718 <__do_softirq+68/ec> Trace; 80082ec0 Trace; 801593c0 Trace; 800ac7f4 Trace; 80084b18 Trace; 800ac6f8 <__do_softirq+48/ec> Trace; 80084578 Trace; 80084578 Trace; 800ac7f4 Trace; 80084b18 Trace; 80082ec0 Trace; 800826d0 Trace; 80082ec0 Trace; 801594a4 Trace; 801593c0 Trace; 80085468 Trace; 80085480 Trace; 8019c624 Trace; 8019c610 Trace; c001b570 <__crc_bio_map_user+64b64/130ac7> Trace; 80084bec Trace; 8015bff8 Trace; 800ce3ec Trace; 800ce3ec Trace; c001bc24 <__crc_bio_map_user+65218/130ac7> Trace; 80126eb8 Trace; 8015d338 Trace; c001b544 <__crc_bio_map_user+64b38/130ac7> Trace; 801780e0 Trace; 8015d3a0 <__pci_device_probe+38/70> Trace; 8015d7b4 Trace; 8015d408 Trace; 80153bf4 Trace; 80178eb0 Trace; 80154140 Trace; 80154018 Trace; 80154258 Trace; 80178fec Trace; 80179284 Trace; 80179608 Trace; 800a83e4 Trace; 800a8264 Trace; 8015d684 Trace; 800a81d4 Trace; c001c298 <__crc_bio_map_user+6588c/130ac7> Trace; c001c288 <__crc_bio_map_user+6587c/130ac7> Trace; c002a020 <__crc_bio_map_user+73614/130ac7> Trace; 800c2b98 Trace; 800c2b40 Trace; 800e7ef0 Trace; 8008be88 Trace; c001b570 <__crc_bio_map_user+64b64/130ac7> 2 warnings and 1 error issued. Results may not be reliable. cheers, Kieran. --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAo77jOWPbH1PXZ18RAliUAKCf7R6z2KQJlCwvjaM6xG7xdvGwKgCfcTdz qGwaNbSb/g4YqBi+6RUTNb0= =Bxg6 -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From deltha@analog.ro Thu May 13 19:44:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 19:44:01 +0100 (BST) Received: from main.analog.ro ([IPv6:::ffff:81.196.32.141]:1689 "EHLO main.analog.ro") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 19:44:00 +0100 Received: from 5COM (networkadministrator.analog.ro [192.168.6.2]) by main.analog.ro (8.12.10/8.12.9) with ESMTP id i4DIl0Uh005426; Thu, 13 May 2004 21:47:02 +0300 Date: Thu, 13 May 2004 21:44:03 +0300 From: Rujinschi Remus Reply-To: Rujinschi Remus Organization: Rujinschi Remus X-Priority: 3 (Normal) Message-ID: <1972157758.20040513214403@analog.ro> To: uclinux-dev@uclinux.org CC: linux-mips@linux-mips.org Subject: MSP2000-CB-A1 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: 4994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: deltha@analog.ro Precedence: bulk X-list: linux-mips Hello, Is there any attempt to port linux to Brecis MSP2000 MIPS32 4km based SoC? Does anyone wanna provide any hint using uClinux on it binutils gcc gdb, bootloader, drivers? Is it a success using target=mipsisa32-elf as crosscompile option? Template? Anything which not implies BRECIS proprietary licence? -- Thanx in advance, Rujinschi Remus mailto:deltha@analog.ro From tbm@cyrius.com Thu May 13 19:48:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 19:48:34 +0100 (BST) Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:55301 "EHLO sorrow.cyrius.com") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 19:48:33 +0100 Received: by sorrow.cyrius.com (Postfix, from userid 10) id C645064D3B; Thu, 13 May 2004 18:48:28 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id AB9AAFF6F; Thu, 13 May 2004 19:47:24 +0100 (BST) Date: Thu, 13 May 2004 19:47:24 +0100 From: Martin Michlmayr To: Joerg Rossdeutscher Cc: linux-mips@linux-mips.org Subject: Re: RaQ2: Installation stops at "loading debian installer" Message-ID: <20040513184724.GA12261@deprecation.cyrius.com> References: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> User-Agent: Mutt/1.5.6i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Joerg Rossdeutscher [2004-05-13 19:31]: > The last lines say: > > >execute initrd={initrd-size}@{initrd-start} > console=ttyS0,{console-speed} > elf: 80080000 <-- 00001000 1916928t+176112t > elf: entry 801fc040 > net: interface down That's the same as I get: > -script > lcd 'Loading' 'debian-installer' > tftp {dhcp-next-server} vmlinux-2.4.25-r5k-cobalt initrd.gz arp: request from 192.168.1.1 ... > execute initrd={initrd-size}@{initrd-start} console=ttyS0,{console-speed} elf: 80080000 <-- 00001000 1916928t + 176112t elf: entry 801fc040 net: interface down CPU revision is: 000028a0 FPU revision is: 000028a0 Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes. Primary data cache 32kB 2-way, linesize 32 bytes. Linux version 2.4.25-r5k-cobalt (root@solitude.cyrius.com) (gcc version 3.3.3 (Debian 20040321)) #1 Thu Apr 15 15:17:00 BST 2004 Well, immediately after the message you saw, control should be passed to the kernel and you should see kernel message. I don't really know why that wouldn't work in your case. -- Martin Michlmayr tbm@cyrius.com From pdh@colonel-panic.org Thu May 13 20:38:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 20:38:28 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:28800 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Thu, 13 May 2004 20:38:16 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BOM1P-0000p7-00; Thu, 13 May 2004 20:37:35 +0100 Date: Thu, 13 May 2004 20:37:35 +0100 To: Joerg Rossdeutscher Cc: linux-mips@linux-mips.org Subject: Re: RaQ2: Installation stops at "loading debian installer" Message-ID: <20040513193735.GA2793@skeleton-jack> References: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips On Thu, May 13, 2004 at 07:31:05PM +0200, Joerg Rossdeutscher wrote: > > The RaQ2 boots the debian-installer-b4 via tftp and nfs until the > display shows "Loading debian installer". Then it stops. > I now have found an old Laptop that still has a serial port. > > > The last lines say: > > >execute initrd={initrd-size}@{initrd-start} > console=ttyS0,{console-speed} > elf: 80080000 <-- 00001000 1916928t+176112t > elf: entry 801fc040 > net: interface down > > (I type this by hand, so excuse possibly errors) > > That's it. Ethereal shows no more net traffic and no remarkable errors > before the installation stops. Nothings happens. And nothing at google > for this message. Hm. > > Any ideas someone? > The messages are just debugging output, nothing wrong there. The next thing to be displayed should be kernel messages :-( Can you post all the boot messages (off list). P. From bbreuer@righthandtech.com Thu May 13 23:05:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 13 May 2004 23:05:59 +0100 (BST) Received: from ux1.dataflo.net ([IPv6:::ffff:207.252.248.16]:24325 "EHLO ux1.dataflo.net") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Thu, 13 May 2004 23:05:57 +0100 Received: from server1.RightHand.righthandtech.com ([207.252.250.187]) by ux1.dataflo.net (8.12.11/8.12.11) with ESMTP id i4DM5r5K079575 for ; Thu, 13 May 2004 17:05:55 -0500 (CDT) content-class: urn:content-classes:message Subject: RE: problems on D-cache alias in 2.4.22 Date: Thu, 13 May 2004 17:05:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: problems on D-cache alias in 2.4.22 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Index: AcQ5NnTrK9jtHiAwTiu//MgHM8HyDA== From: "Bob Breuer" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4997 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bbreuer@righthandtech.com Precedence: bulk X-list: linux-mips > -----Original Message----- > Date: Thu, 13 May 2004 14:52:53 +0800 > From: wuming > Subject: problems on D-cache alias in 2.4.22 > > I am developing in linux-2.4.22 on the machine with virtual address > indexed and physical > address tagged. But when I compile some application programs, > I met the > following error: > > cc1: internal compiler error: Segmentation fault > > I have searched about this error from internet, it's due to some > hardware fault or > a wrong pte fault handler. Because my machine have D-cache > aliasing, so > I think > this error should be due to a wrong pte fault handler. After > my painful > kernel hacking, > I found some strange problems and it's in function __update_cache( ): > > void __update_cache(struct vm_area_struct *vma, unsigned long address, > pte_t pte) > { > unsigned long addr; > struct page *page; > > if (!cpu_has_dc_aliases) > return; > > page = pte_page(pte); > > /*This printk is added by myself*/ > printk("<1>valid page:%d\tpage mapping:0x%p\tpage flags:%d\n",\ > VALID_PAGE(page), page->mapping, (page->flags & (1UL << > PG_dcache_dirty))); > > if (VALID_PAGE(page) && page->mapping && > (page->flags & (1UL << PG_dcache_dirty))) { > if (pages_do_alias((unsigned long) page_address(page), address & > PAGE_MASK)) { > addr = (unsigned long) page_address(page); > flush_data_cache_page(addr); > } > ClearPageDcacheDirty(page); > } > } > > When my kernel is running, I found the condition "page->mapping" and > "(page->flags & (1UL << PG_dcache_dirty))" > will never be true at the same time. so the function > flush_data_cache_page( ) will never be called. > Then I commented the two condition, the compiler error disappeared. > I do not understand the phenomenon very clearly, so I need some help. > > I am having a similar problem with 2.4.26 on an NEC VR5500 with a 32k 2-way cache. This is with a 32 bit little-endian kernel, and an ext2 filesystem on an ide hard drive in pio mode. Removing just the check for PG_dcache_dirty fixes the problem for me. Along the way, I found a bogus check for cache aliases in c-r4k.c. In the ld_mmu_r4xx0 function, it has the check: if (c->dcache.sets * c->dcache.ways > PAGE_SIZE) which will never work for a 32k cache. Bob Breuer From ralf@linux-mips.org Fri May 14 00:34:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 00:34:59 +0100 (BST) Received: from p508B6CA9.dip.t-dialin.net ([IPv6:::ffff:80.139.108.169]:44053 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 00:34:58 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4DNYJxT028314; Fri, 14 May 2004 01:34:19 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4DNXwuD028312; Fri, 14 May 2004 01:33:58 +0200 Date: Fri, 14 May 2004 01:33:58 +0200 From: Ralf Baechle To: Rujinschi Remus Cc: uclinux-dev@uclinux.org, linux-mips@linux-mips.org Subject: Re: MSP2000-CB-A1 Message-ID: <20040513233358.GA26740@linux-mips.org> References: <1972157758.20040513214403@analog.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1972157758.20040513214403@analog.ro> User-Agent: Mutt/1.4.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: 4998 X-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, May 13, 2004 at 09:44:03PM +0300, Rujinschi Remus wrote: > Is there any attempt to port linux to Brecis MSP2000 MIPS32 4km > based SoC? Does anyone wanna provide any hint using > uClinux on it binutils gcc gdb, bootloader, drivers? > Is it a success using target=mipsisa32-elf as crosscompile > option? No. You'll need a mips-linux compiler configuration. > Template? Anything which not implies BRECIS proprietary licence? Ralf From wuming@ict.ac.cn Fri May 14 03:59:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 03:59:29 +0100 (BST) Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:43244 "HELO mail.ict.ac.cn") by linux-mips.org with SMTP id ; Fri, 14 May 2004 03:59:27 +0100 Received: (qmail 15098 invoked from network); 14 May 2004 02:47:25 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.188) by mail.ict.ac.cn with SMTP; 14 May 2004 02:47:25 -0000 Message-ID: <40A43601.70307@ict.ac.cn> Date: Fri, 14 May 2004 10:59:13 +0800 From: wuming User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.2.1) Gecko/20030225 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 References: In-Reply-To: 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: 4999 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wuming@ict.ac.cn Precedence: bulk X-list: linux-mips > > >I am having a similar problem with 2.4.26 on an NEC VR5500 with a 32k >2-way cache. This is with a 32 bit little-endian kernel, and an ext2 >filesystem on an ide hard drive in pio mode. > >Removing just the check for PG_dcache_dirty fixes the problem for me. > >Along the way, I found a bogus check for cache aliases in c-r4k.c. In >the ld_mmu_r4xx0 function, it has the check: > if (c->dcache.sets * c->dcache.ways > PAGE_SIZE) >which will never work for a 32k cache. > >Bob Breuer > > > > > I have understood the phenomenon, and I think this is a kernel's bug. The real wrong place is not the judgement for condition "PG_dcache_dirty" in function __update_cache( ). in file mm/filemap.c and function filemap_nopage( ): ...... success: /* * Try read-ahead for sequential areas. */ if (VM_SequentialReadHint(area)) nopage_sequential_readahead(area, pgoff, size); /* * Found the page and have a reference on it, need to check sharing * and possibly copy it over to another page.. */ mark_page_accessed(page); flush_page_to_ram(page); return page; ...... flush_page_to_ram( ) has not been used for a long time, and in kernel 2.4.22 "include/asm-mips/cacheflush.h" #define flush_page_to_ram(page) do { } while (0) so the mapped page has not been flushed to ram, and the user space will not know the latest data in the page. the flush_page_to_ram( ) should be replaced by flush_dcache_page( ), and if the flush_dcache_page( ) does not really flush the cache, it will set the PG_dcache_dirty, and the real flush will be postponed to __update_cache( ). and if there is not the flush_dcache_page( ) here, no one will set the PG_dcache_dirty, and __update_cache( ) will not flush the page too, so the D-cache aliasing happens. at last, when I replaced flush_page_to_ram( ) with flush_dcache_page( ), the internal compiler error disappeared. I hope your problem will be solved by this way too. God bless you! :-) From ibrahim@schenk.isar.de Fri May 14 08:39:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 08:39:54 +0100 (BST) Received: from schenk.ISAR.de ([IPv6:::ffff:212.14.78.13]:17181 "EHLO schenk.isar.de") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 08:39:51 +0100 Received: from gwhaus.rt.schenk (gwhaus.rt.schenk [172.22.0.4]) by schenk.isar.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id i4E7dRD28060 for ; Fri, 14 May 2004 09:39:28 +0200 Received: from schenk.isar.de (pcimr4.rt.schenk [172.22.10.24]) by gwhaus.rt.schenk (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id i4E7dRi28606 for ; Fri, 14 May 2004 09:39:27 +0200 Message-ID: <40A477AF.903@schenk.isar.de> Date: Fri, 14 May 2004 09:39:27 +0200 From: Rojhalat Ibrahim User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Invalid kernel address Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5000 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ibrahim@schenk.isar.de Precedence: bulk X-list: linux-mips Hi, I'm trying to run Linux 2.4.26 from current CVS on a Jaguar-ATX board. What can I do about this message: "Kernel panic: Invalid kernel address"? Here is the complete console output: Mips64 Jaguar-ATX cpu_clock set to 1000000000 mv64340_base set to 0xfffffffff4000000 arcs_cmdline: tftp://172.22.10.24/vmlinux console=ttyS0,38400 nfsroot=172.22.10. 24:/home/mipsroot ip=172.22.110.5 CPU revision is: 00003430 FPU revision is: 00003420 Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes. Primary data cache 16kB 4-way, linesize 32 bytes. Secondary cache size 256K, linesize 32 bytes. Enabling secondary cache...Linux version 2.4.26 (imr@pcimr4) (gcc version 3.3.3) #102 Fri May 14 09:17:06 CEST 2004 PMON_v2_setup Momentum Jaguar-ATX: Board Assembly Rev. B FPGA Rev: 2.0 Reset reason: 0x1 - Power-up reset Board Status register: 0x00 - User jumper: absent - Boot flash write jumper: absent Jaguar ATX DMA-low mode set Determined physical RAM map: memory: 0000000008000000 @ 0000000000000000 (usable) memory: 0000000010000000 @ 0000000008000000 (usable) On node 0 totalpages: 98304 zone(0): 98304 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: tftp://172.22.10.24/vmlinux console=ttyS0,38400 nfsroot=172 .22.10.24:/home/mipsroot ip=172.22.110.5 Using 500.000 MHz high precision timer. Calibrating delay loop... 999.42 BogoMIPS Memory: 251776k/393216k available (1399k kernel code, 141440k reserved, 128k dat a, 80k init) Dentry cache hash table entries: 65536 (order: 8, 1048576 bytes) Inode cache hash table entries: 32768 (order: 7, 524288 bytes) Mount cache hash table entries: 256 (order: 0, 4096 bytes) Buffer cache hash table entries: 32768 (order: 6, 262144 bytes) Page-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking for 'wait' instruction... unavailable. Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with SHARE_IRQ enabled ttyS00 at 0xfffffffffd000020 (irq = 7) is a 16550A rtc: IRQ 8 is not free. Generic MIPS RTC Driver v1.0 loop: loaded (max 8 devices) MV-64340 10/100/1000 Ethernet Driver eth0: port 0 with MAC address 00:03:cc:1d:00:98 RX TCP/UDP Checksum Offload ON, TX and RX Interrupt Coalescing ON RX NAPI Enabled NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) IP-Config: Guessing netmask 255.255.0.0 IP-Config: Complete: device=eth0, addr=172.22.110.5, mask=255.255.0.0, gw=255.255.255.255, host=172.22.110.5, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=172.22.10.24, rootpath= NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 172.22.10.24 Looking up port of RPC 100005/1 on 172.22.10.24 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 80k freed Kernel panic: Invalid kernel address In interrupt handler - not syncing Is there any way I can fix this? Thanks for your help Rojhalat Ibrahim From phorton@bitbox.co.uk Fri May 14 08:43:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 08:43:56 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:19603 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 08:43:55 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BOXMB-0000EJ-00; Fri, 14 May 2004 08:43:47 +0100 Message-ID: <40A478B0.3070005@bitbox.co.uk> Date: Fri, 14 May 2004 08:43:44 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kieran Fulke CC: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> In-Reply-To: <20040513183059.GA25743@getyour.pawsoff.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips Kieran Fulke wrote: >hi folks, > >getting the below when loading the dvb budget_ci module. it disables IRQ >#23 which is attached to the card, rendering it useless. i asked the >same question over there and none of them suspect it to be a DVB >problem. some esoteric pci bug perhaps? > > > Have you tried any other hardware in the slot, PCI network card perhaps ? P. From phorton@bitbox.co.uk Fri May 14 08:45:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 08:45:57 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:21139 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 08:45:56 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BOXO7-0000EZ-00; Fri, 14 May 2004 08:45:47 +0100 Message-ID: <40A47926.30103@bitbox.co.uk> Date: Fri, 14 May 2004 08:45:42 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wuming CC: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 References: <40A31B45.7060204@ict.ac.cn> In-Reply-To: <40A31B45.7060204@ict.ac.cn> 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: 5002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips wuming wrote: > I am developing in linux-2.4.22 on the machine with virtual address >indexed and physical >address tagged. But when I compile some application programs, I met the >following error: > >cc1: internal compiler error: Segmentation fault > > > Is this on an IDE drive ? PIO or DMA ? P. From zhmtan@sjtu.edu.cn Fri May 14 08:46:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 08:46:19 +0100 (BST) Received: from [IPv6:::ffff:202.112.26.54] ([IPv6:::ffff:202.112.26.54]:51332 "EHLO sjtu.edu.cn") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 08:46:12 +0100 Received: by sjtu.edu.cn (WorldPost, from userid 12345) id 2A847110D99F; Fri, 14 May 2004 15:45:49 +0800 (BEIST) From: Reply-To: zhmtan@sjtu.edu.cn To: linux-mips@linux-mips.org Subject: problems on compiling 2.4.3 kernel for sead-2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_SkyMiracle_WorldPost_1084520748_=" X-Priority: 3 X-Mailer: SkyMiracle WorldPost 8.0.1 X-SM-Mtrack-ID: 1084520748.2269206 Message-Id: <20040514074549.2A847110D99F@sjtu.edu.cn> Date: Fri, 14 May 2004 15:45:49 +0800 (BEIST) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5003 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zhmtan@sjtu.edu.cn Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ----=_SkyMiracle_WorldPost_1084520748_= Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sIGV2ZXJ5b25lDQoNClVzaW5nIExpbnV4LTIuNC4zLCBjaG9vc2luZyBzZWFkIG1h Y2hpbmUgc3VwcG9ydCBhbmQgbWlwczMyIENQVSwgSSBjb21waWxlIHRoZSBrZXJuZWwsIGFu ZCBnZXQgdGhlIGZvbGxvd2luZyBlcnJvciBtZXNzYWdlIHdoZW4gbGlua2luZzogDQoobXkg ZW52aXJvbm1lbnQgaXM6IG1pcHNlbC1saW51eC1nY2MgdmVyc2lvbiAyLjk1LjQgMjAwMTAz MTkgKHByZXJlbGVhc2UpOyANCiAgICAgICAgICAgICAgICAgIG1pcHNlbC1saW51eC1sZCBH TlUgbGQgdmVyc2lvbiAyLjE0IDIwMDMwNjEyKQ0KDQouLi4uLi4NCnNlZCAtZSBcJ3MvQEBP VVRQVVRfRk9STUFUQEAvZWxmMzItdHJhZGxpdHRsZW1pcHMvXCcgXFwNCiAgICAtZSBcJ3Mv QEBMT0FEQUREUkBALzB4ODAxMDAwMDAvXCcgPGFyY2gvbWlwcy9sZC5zY3JpcHQuaW4gPmFy Y2gvbWlwcy9sZC5zY3JpcHQNCm1pcHNlbC1saW51eC1sZCAtc3RhdGljIC1HIDAgLVQgYXJj aC9taXBzL2xkLnNjcmlwdCBhcmNoL21pcHMva2VybmVsL2hlYWQubyBhcmNoL21pcHMva2Vy bmVsL2luaXRfdGFzay5vIGluaXQvbWFpbi5vIGluaXQvdmVyc2lvbi5vIFxcDQogICAgICAg IC0tc3RhcnQtZ3JvdXAgXFwNCiAgICAgICAgYXJjaC9taXBzL2tlcm5lbC9rZXJuZWwubyBh cmNoL21pcHMvbW0vbW0ubyBrZXJuZWwva2VybmVsLm8gbW0vbW0ubyBmcy9mcy5vIGlwYy9p cGMubyBhcmNoL21pcHMvbWF0aC1lbXUvZnB1X2VtdWxhdG9yLm8gXFwNCiAgICAgICAgZHJp dmVycy9ibG9jay9ibG9jay5vIGRyaXZlcnMvY2hhci9jaGFyLm8gZHJpdmVycy9taXNjL21p c2MubyBkcml2ZXJzL25ldC9uZXQubyBkcml2ZXJzL21lZGlhL21lZGlhLm8gIGRyaXZlcnMv c2NzaS9zY3NpZHJ2Lm8gZHJpdmVycy9jZHJvbS9kcml2ZXIubyBcXA0KICAgICAgICBuZXQv bmV0d29yay5vIFxcDQogICAgICAgIGFyY2gvbWlwcy9saWIvbGliLmEgL2hvbWUvbGYvemht dGFuL2xpbnV4LTIuNC4zL2xpYi9saWIuYSBhcmNoL21pcHMvbWlwcy1ib2FyZHMvc2VhZC9z ZWFkLm8gYXJjaC9taXBzL21pcHMtYm9hcmRzL2dlbmVyaWMvbWlwc2JvYXJkcy5vIFxcDQog ICAgICAgIC0tZW5kLWdyb3VwIFxcDQogICAgICAgIC1vIHZtbGludXgNCmFyY2gvbWlwcy9r ZXJuZWwva2VybmVsLm8oX19rc3ltdGFiKzB4ODApOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRv IGBlbmFibGVfaXJxXCcNCmFyY2gvbWlwcy9rZXJuZWwva2VybmVsLm8oX19rc3ltdGFiKzB4 ODgpOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBkaXNhYmxlX2lycVwnDQphcmNoL21pcHMv bW0vbW0ubygudGV4dC5pbml0KzB4ODRjKTogSW4gZnVuY3Rpb24gYHNldHVwX25vc2NhY2hl X2Z1bmNzXCc6DQo6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNvaGVyZW5jeVwnDQphcmNo L21pcHMvbW0vbW0ubygudGV4dC5pbml0KzB4ODUwKTogSW4gZnVuY3Rpb24gYHNldHVwX25v c2NhY2hlX2Z1bmNzXCc6DQo6IHVuZGVmaW5lZCByZWZlcmVuY2UgdG8gYGNvaGVyZW5jeVwn DQphcmNoL21pcHMvbW0vbW0ubygudGV4dC5pbml0KzB4OTM4KTogSW4gZnVuY3Rpb24gYHNl dHVwX3NjYWNoZV9mdW5jc1wnOg0KOiB1bmRlZmluZWQgcmVmZXJlbmNlIHRvIGBjb2hlcmVu Y3lcJw0KYXJjaC9taXBzL21tL21tLm8oLnRleHQuaW5pdCsweDkzYyk6IEluIGZ1bmN0aW9u IGBzZXR1cF9zY2FjaGVfZnVuY3NcJzoNCjogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgY29o ZXJlbmN5XCcNCmFyY2gvbWlwcy9taXBzLWJvYXJkcy9nZW5lcmljL21pcHNib2FyZHMubygu dGV4dCsweDE0MCk6IEluIGZ1bmN0aW9uIGBtaXBzSVJRXCc6DQo6IHVuZGVmaW5lZCByZWZl cmVuY2UgdG8gYGNvcmVoaV9pcnFkaXNwYXRjaFwnDQptYWtlOiAqKiogW3ZtbGludXhdIEVy cm9yIDENCg0KSSB3aXNoIHRoZSBoZWxwIGZyb20geW91Lg0KDQpCeSB0aGUgd2F5LCBjYW4g SSBkb3dubG9hZCBrZXJuZWwgaW1hZ2UgdG8gdGhlIHRhcmdldCBib2FyZCB0aHJvdWdoIHNl cmlhbCBwb3J0LCB2aWEgbWluaWNvbSBhbmQgeWFtb24/DQoNCnRoYW5rcyBhIGxvdCENCiA= ----=_SkyMiracle_WorldPost_1084520748_=-- From phorton@bitbox.co.uk Fri May 14 08:52:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 08:52:52 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:23443 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 08:52:51 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BOXUp-0000Ex-00; Fri, 14 May 2004 08:52:43 +0100 Message-ID: <40A47ACA.1040101@bitbox.co.uk> Date: Fri, 14 May 2004 08:52:42 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: wuming CC: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 References: <40A43601.70307@ict.ac.cn> In-Reply-To: <40A43601.70307@ict.ac.cn> 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: 5004 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips wuming wrote: > I have understood the phenomenon, and I think this is a kernel's bug. > The real wrong place is not the judgement for condition "PG_dcache_dirty" > in function __update_cache( ). > in file mm/filemap.c and function filemap_nopage( ): > ...... > success: > /* > * Try read-ahead for sequential areas. > */ > if (VM_SequentialReadHint(area)) > nopage_sequential_readahead(area, pgoff, size); > > /* > * Found the page and have a reference on it, need to check > sharing > * and possibly copy it over to another page.. > */ > mark_page_accessed(page); > flush_page_to_ram(page); > return page; > ...... > > flush_page_to_ram( ) has not been used for a long time, and in kernel > 2.4.22 > "include/asm-mips/cacheflush.h" > #define flush_page_to_ram(page) do { } while (0) > > so the mapped page has not been flushed to ram, and the user space > will not > know the latest data in the page. > the flush_page_to_ram( ) should be replaced by flush_dcache_page( ), > and if the flush_dcache_page( ) does not really flush the cache, it > will set > the PG_dcache_dirty, and the real flush will be postponed to > __update_cache( ). > and if there is not the flush_dcache_page( ) here, no one will set the > PG_dcache_dirty, > and __update_cache( ) will not flush the page too, so the D-cache > aliasing happens. > > at last, when I replaced flush_page_to_ram( ) with flush_dcache_page( ), > the internal compiler error disappeared. > > I hope your problem will be solved by this way too. God bless you! :-) > This is probably just hiding your problem. flush_page_to_ram() is not used anymore. P. From shiraz.ta@philips.com Fri May 14 09:56:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 09:56:49 +0100 (BST) Received: from gw-eur4.philips.com ([IPv6:::ffff:161.85.125.10]:37863 "EHLO gw-eur4.philips.com") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 09:56:48 +0100 Received: from smtpscan-eur4.philips.com (smtpscan-eur4.mail.philips.com [130.144.57.167]) by gw-eur4.philips.com (Postfix) with ESMTP id 5E23649FA7 for ; Fri, 14 May 2004 08:56:39 +0000 (UTC) Received: from smtpscan-eur4.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 32307CC for ; Fri, 14 May 2004 08:56:39 +0000 (GMT) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-eur4.philips.com (Postfix) with ESMTP id 165BFB7 for ; Fri, 14 May 2004 08:56:39 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id KAA04833 for ; Fri, 14 May 2004 10:56:38 +0200 (MEST) From: shiraz.ta@philips.com Subject: Porting of Linux on to a MIPS16 Processor. Help required To: linux-mips@linux-mips.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Fri, 14 May 2004 14:24:50 +0530 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.0.2CF1HF634 | May 5, 2004) at 14/05/2004 10:54:55 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: 5005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: shiraz.ta@philips.com Precedence: bulk X-list: linux-mips Hi, I am new to linux. I am in need of porting linux to a MIPS16 based processor. I need some information regarding the porting. It will be a great help if somebody could answer me. 1) Is there any port available already for this? If available how do i get it along with the development environment. 2) If the port is not available then how much complex (How much effort ?) is it to port it to MIPS 16. 3) Where can I get the tool chain on windows and linux kernel source code which can be used . 4)curently the board uses EJTAG for download and execute. We have a uart(serial port) on the board which we use as console connected to the hyperterminal on a windows pc.. There is no shell supported. We can compile and run applications on the target. 5) We have the existing BSP and custom drivers ported over a OS abstraction layer. Once the kernel is ported we have to get the custom drivers ported. 6) I would like to know how much would be the code size for the kernel alone with out any shell and with the console driver. (Source code and Binary) Thanks in advance. Warm Regards Shiraz From ralf@linux-mips.org Fri May 14 13:12:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 13:12:05 +0100 (BST) Received: from p508B62CE.dip.t-dialin.net ([IPv6:::ffff:80.139.98.206]:51744 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 13:12:04 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4ECBxxT008541; Fri, 14 May 2004 14:11:59 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4ECBxpj008540; Fri, 14 May 2004 14:11:59 +0200 Date: Fri, 14 May 2004 14:11:58 +0200 From: Ralf Baechle To: shiraz.ta@philips.com Cc: linux-mips@linux-mips.org Subject: Re: Porting of Linux on to a MIPS16 Processor. Help required Message-ID: <20040514121158.GA5466@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.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: 5006 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 14, 2004 at 02:24:50PM +0530, shiraz.ta@philips.com wrote: > I am new to linux. I am in need of porting linux to a MIPS16 based > processor. I need some information regarding the porting. It will be a > great help if somebody could answer me. > > 1) Is there any port available already for this? If available how do i get > it along with the development environment. > > 2) If the port is not available then how much complex (How much effort ?) > is it to port it to MIPS 16. > > 3) Where can I get the tool chain on windows and linux kernel source code > which can be used . You forgot to mention the exact processor type but anyway, MIPS16 is really just an extension. As such Linux can run on a system without actually knowing anything about MIPS16. Which is nice, if you intend to actually exploit MIPS16 you don't have to have that working right away but can introduce support later, as optimization for size. Windows? Good luck. I've seen success reports with Cygwin but if you want to keep things sane, use a Linux box for development. > 6) I would like to know how much would be the code size for the kernel > alone with out any shell and with the console driver. (Source code and > Binary) To my knowledge nobody has used MIPS16 for Linux so far. There seems little point in that because MIPS16 primarily targets very small systems - a class of systems that Linux doesn't tend to run on well. Ralf From thomas.koeller@baslerweb.com Fri May 14 13:55:27 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 13:55:28 +0100 (BST) Received: from [IPv6:::ffff:145.253.187.130] ([IPv6:::ffff:145.253.187.130]:1286 "EHLO proxy.baslerweb.com") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 13:55:27 +0100 Received: from comm1.baslerweb.com ([172.16.13.2]) by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Fri, 14 May 2004 14:54:59 +0200 Received: from [172.16.13.253] (localhost [172.16.13.253]) by comm1.baslerweb.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JHN38ZDG; Fri, 14 May 2004 14:55:24 +0200 From: Thomas Koeller Organization: Basler AG To: linux-mips@linux-mips.org Subject: Re: titan ethernet driver Date: Fri, 14 May 2004 14:58:01 +0200 User-Agent: KMail/1.6.1 Cc: Manish Lachwani , Ralf Baechle References: <9DFF23E1E33391449FDC324526D1F259022536FB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <9DFF23E1E33391449FDC324526D1F259022536FB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405141458.01277.thomas.koeller@baslerweb.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: 5007 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips Manish Lachwani wrote: > Are you referring to 2.4 or 2.6? You have already downloaded 2.4.26 and > 2.4.21 versions (with source code) from the PMC-Sierra ftp site. These are > fully functional and several customers are using it from the last 3-4 > months now. The patches for 2.4 have been sent out to Ralf. This is all about 2.6. From the CVS change logs I see that Ralf is applying 2.6-specific changes to the driver. Now that there is no working support for 2.6 on the yosemite, the only platform I know of that has this H/W, I just wondered how these changes are tested. tk -- -------------------------------------------------- Thomas Koeller, Software Development Basler Vision Technologies An der Strusbek 60-62 22926 Ahrensburg Germany Tel +49 (4102) 463-390 Fax +49 (4102) 463-46390 mailto:thomas.koeller@baslerweb.com http://www.baslerweb.com ============================== From ralf@linux-mips.org Fri May 14 15:07:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 15:07:29 +0100 (BST) Received: from p508B62CE.dip.t-dialin.net ([IPv6:::ffff:80.139.98.206]:61729 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 15:07:28 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4EE7LxT015759; Fri, 14 May 2004 16:07:21 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4EE7Kns015758; Fri, 14 May 2004 16:07:20 +0200 Date: Fri, 14 May 2004 16:07:20 +0200 From: Ralf Baechle To: Thomas Koeller Cc: linux-mips@linux-mips.org, Manish Lachwani Subject: Re: titan ethernet driver Message-ID: <20040514140720.GC24402@linux-mips.org> References: <9DFF23E1E33391449FDC324526D1F259022536FB@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> <200405141458.01277.thomas.koeller@baslerweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405141458.01277.thomas.koeller@baslerweb.com> User-Agent: Mutt/1.4.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: 5008 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 14, 2004 at 02:58:01PM +0200, Thomas Koeller wrote: > This is all about 2.6. From the CVS change logs I see that Ralf is > applying 2.6-specific changes to the driver. Now that there is no > working support for 2.6 on the yosemite, the only platform I know of > that has this H/W, I just wondered how these changes are tested. On Yosemite, of course :-) The reason why I put this driver already into CVS before the remainder of the Yosemite port is to make it accessible for outside review by one of the Linux networking gods. Ralf From Rakesh.Tiwari@idt.com Fri May 14 18:06:28 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 18:06:29 +0100 (BST) Received: from noc.mainstreet.net ([IPv6:::ffff:207.5.0.45]:24592 "EHLO noc.mainstreet.net") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 18:06:28 +0100 Received: from mail.idt.com (mail.idt.com [157.165.5.20]) by noc.mainstreet.net (8.12.10/8.12.10) with ESMTP id i4EH6POr038856; Fri, 14 May 2004 10:06:25 -0700 (PDT) Received: from corpml2.corp.idt.com (firewall-user@supercop4.idt.com [157.165.5.10]) by mail.idt.com (8.9.3/8.9.3) with ESMTP id KAA23012; Fri, 14 May 2004 10:06:36 -0700 (PDT) Received: from CORPBRIDGE.corp.idt.com (corpexchange1.corp.idt.com [157.165.140.83]) by corpml2.corp.idt.com (8.11.7p1+Sun/8.11.7) with ESMTP id i4EH6Ov17857; Fri, 14 May 2004 10:06:24 -0700 (PDT) Received: by corpbridge.corp.idt.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 May 2004 10:06:24 -0700 Message-ID: <73943A6B3BEAA1468EE1A4A090129F43742771@corpbridge.corp.idt.com> From: "Tiwari, Rakesh" To: linux-mips@linux-mips.org Cc: "'Ralf Baechle'" Subject: Adding support for new BSP Date: Fri, 14 May 2004 10:06:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C439D5.29E9FA6D" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5009 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rakesh.Tiwari@idt.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C439D5.29E9FA6D Content-Type: text/plain Hi, We plan to add our (IDT) BSP (board support package) for evaluation boards based on IDT 32 bit MIPS processors to the main mips-linux 2.6.x kernel. Can somebody please tell me the procedure/requirements to check-in the new BSP files into the main kernel tree. Any suggestions/pointers would be appreciated. Thanks Rakesh ------_=_NextPart_001_01C439D5.29E9FA6D Content-Type: text/html Content-Transfer-Encoding: quoted-printable Adding support for new BSP

Hi,

We plan to add our (IDT) BSP = (board support package) for evaluation boards based on IDT 32 bit MIPS = processors to the main mips-linux 2.6.x kernel.

Can somebody please tell me the = procedure/requirements to check-in the new
BSP files into the main kernel = tree.

Any suggestions/pointers would = be appreciated.

Thanks
Rakesh

------_=_NextPart_001_01C439D5.29E9FA6D-- From ralf@linux-mips.org Fri May 14 18:32:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 18:32:47 +0100 (BST) Received: from p508B62CE.dip.t-dialin.net ([IPv6:::ffff:80.139.98.206]:2340 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 18:32:46 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4EHWcxT026763; Fri, 14 May 2004 19:32:38 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4EHWbDZ026762; Fri, 14 May 2004 19:32:37 +0200 Date: Fri, 14 May 2004 19:32:37 +0200 From: Ralf Baechle To: "Tiwari, Rakesh" Cc: linux-mips@linux-mips.org Subject: Re: Adding support for new BSP Message-ID: <20040514173237.GA23561@linux-mips.org> References: <73943A6B3BEAA1468EE1A4A090129F43742771@corpbridge.corp.idt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73943A6B3BEAA1468EE1A4A090129F43742771@corpbridge.corp.idt.com> User-Agent: Mutt/1.4.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: 5010 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 14, 2004 at 10:06:16AM -0700, Tiwari, Rakesh wrote: > We plan to add our (IDT) BSP (board support package) for evaluation boards > based on IDT 32 bit MIPS processors to the main mips-linux 2.6.x kernel. > > Can somebody please tell me the procedure/requirements to check-in the new > BSP files into the main kernel tree. Send me a patch; cc'ing linux-mips can't harm. I'll either apply or comment the patch. Ralf From ppopov@mvista.com Fri May 14 18:36:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 18:36:09 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:2805 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 18:36:08 +0100 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA19476; Fri, 14 May 2004 10:35:57 -0700 Message-ID: <40A5037E.907@mvista.com> Date: Fri, 14 May 2004 10:35:58 -0700 From: Pete Popov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tiwari, Rakesh" CC: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Adding support for new BSP References: <73943A6B3BEAA1468EE1A4A090129F43742771@corpbridge.corp.idt.com> <20040514173237.GA23561@linux-mips.org> In-Reply-To: <20040514173237.GA23561@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5011 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: >On Fri, May 14, 2004 at 10:06:16AM -0700, Tiwari, Rakesh wrote: > > > >>We plan to add our (IDT) BSP (board support package) for evaluation boards >>based on IDT 32 bit MIPS processors to the main mips-linux 2.6.x kernel. >> >>Can somebody please tell me the procedure/requirements to check-in the new >>BSP files into the main kernel tree. >> >> > >Send me a patch; cc'ing linux-mips can't harm. I'll either apply or >comment the patch. > > Take a look at the CodingStyle doc in the Documentation directory first. That will save you and Ralf sometime. Pete From sskowron@ET.PUT.Poznan.PL Fri May 14 21:14:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 21:14:48 +0100 (BST) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:39625 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 21:14:47 +0100 Received: from athena (athena [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4EKEjg10991 for ; Fri, 14 May 2004 22:14:45 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena (MailMonitor for SMTP v1.2.2 ) ; Fri, 14 May 2004 22:14:45 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4EKEic15520 for ; Fri, 14 May 2004 22:14:44 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Fri, 14 May 2004 22:14:44 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: Octane: the saga continues... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5012 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips After moving to the CVS kernel tree and tracking down (with Ralf) an interesting bug in IRQ handling we have reached a next release: http://www.et.put.poznan.pl/~sskowron/ip30/ The patch applied cleanly to yesterday CVS and I would like some people to try using it. This will help us debug the XKPHYS kernel support which will be spun off in a separate patch soon. The command line is currently fixed in arch/mips/kernel/setup.c - feel free to comment out this line and use ARCS variables or just change it. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." From Rakesh.Tiwari@idt.com Fri May 14 21:49:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 14 May 2004 21:50:01 +0100 (BST) Received: from noc.mainstreet.net ([IPv6:::ffff:207.5.0.45]:56078 "EHLO noc.mainstreet.net") by linux-mips.org with ESMTP id ; Fri, 14 May 2004 21:49:59 +0100 Received: from mail.idt.com (mail.idt.com [157.165.5.20]) by noc.mainstreet.net (8.12.10/8.12.10) with ESMTP id i4EKnuOr018450; Fri, 14 May 2004 13:49:56 -0700 (PDT) Received: from corpml2.corp.idt.com (firewall-user@supercop4.idt.com [157.165.5.10]) by mail.idt.com (8.9.3/8.9.3) with ESMTP id NAA08430; Fri, 14 May 2004 13:50:06 -0700 (PDT) Received: from CORPBRIDGE.corp.idt.com (corpexchange1.corp.idt.com [157.165.140.83]) by corpml2.corp.idt.com (8.11.7p1+Sun/8.11.7) with ESMTP id i4EKnrv04087; Fri, 14 May 2004 13:49:53 -0700 (PDT) Received: by corpbridge.corp.idt.com with Internet Mail Service (5.5.2655.55) id ; Fri, 14 May 2004 13:49:53 -0700 Message-ID: <73943A6B3BEAA1468EE1A4A090129F43742773@corpbridge.corp.idt.com> From: "Tiwari, Rakesh" To: "'Pete Popov'" , "Tiwari, Rakesh" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: RE: Adding support for new BSP Date: Fri, 14 May 2004 13:49:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Rakesh.Tiwari@idt.com Precedence: bulk X-list: linux-mips Thanks Ralf and Pete. I will check for the Coding Style compliance and mail you the patch sometime next week. Thanks Rakesh -----Original Message----- From: Pete Popov [mailto:ppopov@mvista.com] Sent: Friday, May 14, 2004 10:36 AM To: Tiwari, Rakesh Cc: Ralf Baechle; linux-mips@linux-mips.org Subject: Re: Adding support for new BSP Ralf Baechle wrote: >On Fri, May 14, 2004 at 10:06:16AM -0700, Tiwari, Rakesh wrote: > > > >>We plan to add our (IDT) BSP (board support package) for evaluation >>boards based on IDT 32 bit MIPS processors to the main mips-linux >>2.6.x kernel. >> >>Can somebody please tell me the procedure/requirements to check-in the >>new BSP files into the main kernel tree. >> >> > >Send me a patch; cc'ing linux-mips can't harm. I'll either apply or >comment the patch. > > Take a look at the CodingStyle doc in the Documentation directory first. That will save you and Ralf sometime. Pete From timr@valuepointnet.com Sat May 15 00:03:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 00:03:56 +0100 (BST) Received: from pimout3-ext.prodigy.net ([IPv6:::ffff:207.115.63.102]:43424 "EHLO pimout3-ext.prodigy.net") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sat, 15 May 2004 00:03:52 +0100 Received: from adsl-69-106-45-43.dsl.pltn13.pacbell.net (adsl-69-106-45-43.dsl.pltn13.pacbell.net [69.106.45.43]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4EN3mTT216806; Fri, 14 May 2004 19:03:48 -0400 Content-Type: text/plain; charset="us-ascii" From: timr Reply-To: timr@valuepointnet.com Organization: ValuePoint Net To: linux-mips@linux-mips.org Subject: gdb gives Don't know how to run , gdbserver says Killing inferior Date: Fri, 14 May 2004 16:02:09 -0700 User-Agent: KMail/1.4.3 Cc: timr MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Message-Id: <200405141602.09876.timr@valuepointnet.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: 5014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: timr@valuepointnet.com Precedence: bulk X-list: linux-mips Hi, I am attempting to do my first remote debug. Every time I attempt to run from gdb, gdb says target is already running. But when I try to connect to the target app (mini_http) via my browser, I see its not running. (NOTE: mini_httpd does run when I'm not using gdbserver) when I answer gdb "start from the beginning" with y gdbserver bails with "Killing inferior"! What am I doing wrong - please help? Where do I supply the app arguments, on the target when I start gdbserver or on the host? how does this effect a "re-start"? Is it gdbserver that starts the app or is it started from gdb? I can do (gdb) list and (gdb) break 1200, not sure if that helps. See below for detail. Thanks, Tim target is mipsel with 2.4.18 host 686, running Redhat 8.0 gdb-5.2.1 I first tried gdb-6.0.tar.gz but I kept getting errors: warnings because libtread_db wasn't found and then linux-low would not compile because of __SIGRTMIN (see output below) Any way I bailed on 6.0 and went to 5.2.1 I had problems on the target with 5.2.1 I used "file" and found both gdbserver and my app (mini_httpd) were both dynamicall linked, so I compiled with LDFLAGS=-static got the new builds loaded on the target and issued: gdbserver 192.168.0.2:2345 /sbin/whg/mini_httpd -d /www/whg -u root -c "/cgi-bin/\*" -i /var/state/mini_httpd.pid Process /sbin/whg/mini_httpd created; pid = 27373 <<>> (on the host ) >mipsel-linux-gdb /path-to-binary/mini_httpd GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=mipsel-linux"... (gdb) target remote 192.168.0.1:2345 Remote debugging using 192.168.0.1:2345 0x004000b0 in _ftext () <<< TARGET shows >>> Remote debugging from host 192.168.0.2 <<< Host >>> (gdb) dir /path-to-src/src/MINI_HTTPD Source directories searched: /path-to-src/src/MINI_HTTPD:$cdir:$cwd (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /path-to-app/mini_httpd Don't know how to run. Try "help target". <<< TARGET shows >>> Killing inferior <<< bad build output for gdbserver 6.0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> export PROJECT=VPT echo $PROJECT export PRJROOT=/root export TARGET=mipsel-linux export PREFIX=/usr/local export TARGET_PREFIX=${PREFIX}/${TARGET} export PATH=${PREFIX}/bin:${PATH} >CC=mipsel-linux-gcc ../gdb-6.0/gdb/gdbserver/configure --host=$TARGET --prefix=${TARGET_PREFIX} 2>&1 | tee gdbserver.6.0.config.out creating cache ./config.cache checking for gcc... mipsel-linux-gcc checking whether the C compiler (mipsel-linux-gcc ) works... yes checking whether the C compiler (mipsel-linux-gcc ) is a cross-compiler... yes checking whether we are using GNU C... yes checking whether mipsel-linux-gcc accepts -g... yes checking host system type... mipsel-unknown-linux-gnu checking target system type... mipsel-unknown-linux-gnu checking build system type... mipsel-unknown-linux-gnu checking for a BSD compatible install... /usr/bin/install -c checking how to run the C preprocessor... mipsel-linux-gcc -E checking for ANSI C header files... yes checking for sgtty.h... yes checking for termio.h... yes checking for termios.h... yes checking for sys/reg.h... no checking for string.h... yes checking for proc_service.h... no checking for sys/procfs.h... yes checking for thread_db.h... no checking for linux/elf.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking whether strerror must be declared... no checking for lwpid_t in sys/procfs.h... no checking for psaddr_t in sys/procfs.h... no checking for prgregset_t in sys/procfs.h... no checking for prfpregset_t in sys/procfs.h... no checking for elf_fpregset_t in sys/procfs.h... yes checking for libthread_db... no configure: warning: Could not find libthread_db. configure: warning: Disabling thread support in gdbserver. updating cache ./config.cache creating ./config.status creating Makefile creating config.h >make 2>&1 | tee gdbserver.6.0.make.out mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/inferiors.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/regcache.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/remote-utils.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/server.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/../signals/signals.c -DGDBSERVER ../gdb-6.0/gdb/signals/signals.c: In function `do_target_signal_to_host': ../gdb-6.0/gdb/signals/signals.c:521: warning: unused variable `retsig' mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/target.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/utils.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/mem-break.c sh ../gdb-6.0/gdb/gdbserver/../regformats/regdat.sh ../gdb-6.0/gdb/gdbserver/../regformats/reg-mips.dat reg-mips.c reg-mips.c updated. mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd reg-mips.c mipsel-linux-gcc -c -Wall -g -O2 -I. -I../gdb-6.0/gdb/gdbserver -I../gdb-6.0/gdb/gdbserver/../regformats -I../gdb-6.0/gdb/gdbserver/../../include -I../../bfd -I../gdb-6.0/gdb/gdbserver/../../bfd ../gdb-6.0/gdb/gdbserver/linux-low.c ../gdb-6.0/gdb/gdbserver/linux-low.c: In function `linux_create_inferior': ../gdb-6.0/gdb/gdbserver/linux-low.c:150: `__SIGRTMIN' undeclared (first use in this function) ../gdb-6.0/gdb/gdbserver/linux-low.c:150: (Each undeclared identifier is reported only once ../gdb-6.0/gdb/gdbserver/linux-low.c:150: for each function it appears in.) ../gdb-6.0/gdb/gdbserver/linux-low.c: In function `linux_wait_for_event': ../gdb-6.0/gdb/gdbserver/linux-low.c:511: `__SIGRTMIN' undeclared (first use in this function) ../gdb-6.0/gdb/gdbserver/linux-low.c: In function `linux_init_signals': ../gdb-6.0/gdb/gdbserver/linux-low.c:1283: `__SIGRTMIN' undeclared (first use in this function) From ralf@linux-mips.org Sat May 15 01:13:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 01:13:07 +0100 (BST) Received: from p508B62CE.dip.t-dialin.net ([IPv6:::ffff:80.139.98.206]:44328 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 01:13:07 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4F0CvxT021038; Sat, 15 May 2004 02:12:57 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4F0Cte4021037; Sat, 15 May 2004 02:12:55 +0200 Date: Sat, 15 May 2004 02:12:55 +0200 From: Ralf Baechle To: wuming Cc: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040515001255.GA20773@linux-mips.org> References: <40A43601.70307@ict.ac.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A43601.70307@ict.ac.cn> User-Agent: Mutt/1.4.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: 5015 X-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 Wuming, what kind of filesystem or storage are you using? Ralf From fxzhang@ict.ac.cn Sat May 15 01:34:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 01:34:15 +0100 (BST) Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:44263 "HELO mail.ict.ac.cn") by linux-mips.org with SMTP id ; Sat, 15 May 2004 01:34:13 +0100 Received: (qmail 23280 invoked from network); 15 May 2004 00:21:59 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.187) by mail.ict.ac.cn with SMTP; 15 May 2004 00:21:59 -0000 Message-ID: <40A60DA7.1080405@ict.ac.cn> Date: Sat, 15 May 2004 08:31:35 -0400 From: Fuxin Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: Ralf Baechle CC: wuming , linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 References: <40A43601.70307@ict.ac.cn> <20040515001255.GA20773@linux-mips.org> In-Reply-To: <20040515001255.GA20773@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5016 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fxzhang@ict.ac.cn Precedence: bulk X-list: linux-mips We are using ide disk with ext3 filesystem, DMA is on( PIIX4 chip),but it seems PIO/DMA does not affect the failures. Ralf Baechle wrote: >Wuming, > >what kind of filesystem or storage are you using? > > Ralf > > > > > From sskowron@ET.PUT.Poznan.PL Sat May 15 05:25:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 05:25:19 +0100 (BST) Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:9926 "EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 05:25:17 +0100 Received: from europa (europa.et.put.poznan.pl [150.254.29.138]) by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4F4PFb18263 for ; Sat, 15 May 2004 06:25:15 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ; Sat, 15 May 2004 06:25:14 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4F4PDN02960 for ; Sat, 15 May 2004 06:25:13 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sat, 15 May 2004 06:25:13 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: CONFIG_MDULES (?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5017 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips Hello, long-standing bug: in arch/mips/kernel/traps.c we've got an '#ifdef CONFIG_MDULES". As there is no config by this name, the dbe handling code for modules will never get compiled. As it is, it won't compile anyway, because some necessary variables are static in kernel/module.c (modlist_lock and modules). After making them non-static and making correct 'extern's in traps.c it's OK. A small change to include/asm-mips/module.h was needed (add num_dbeentries field). All these will be included in my XKPHYS_KERNEL patch in a few days. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." From michaelanburaj@hotmail.com Sat May 15 07:24:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 07:24:40 +0100 (BST) Received: from bay1-f120.bay1.hotmail.com ([IPv6:::ffff:65.54.245.120]:9491 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 07:24:39 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 May 2004 23:24:30 -0700 Received: from 165.247.221.201 by by1fd.bay1.hotmail.msn.com with HTTP; Sat, 15 May 2004 06:24:30 GMT X-Originating-IP: [165.247.221.201] X-Originating-Email: [michaelanburaj@hotmail.com] X-Sender: michaelanburaj@hotmail.com From: "Michael Anburaj" To: linux-mips@linux-mips.org Subject: Re: Linux for MIPS Atlas 4Kc board -problems :( Date: Fri, 14 May 2004 23:24:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 May 2004 06:24:30.0720 (UTC) FILETIME=[47EEC000:01C43A45] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5018 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: michaelanburaj@hotmail.com Precedence: bulk X-list: linux-mips Hi, I have requirement in my project where I have to specify an object file contained in a library file in my linker script. Something like this: MySection 0x1000 : { myobj.o of mylib.a (.bss, COMMON) } In ADS scatter map its enough to specify just the object files name. And the linker would pull it from the linked-in libraries. I tried the same with GCC (with it,s linker script), something like this, ZeroISection 0x1000 : { myobj.o (.bss, COMMON) } Does not work. Even thought the linker was supplied with mylib.a, which contains myobj.o; it still gives errors “myobj.o not found”. Please help me with this. Thanks a lot, -Mike. From pf@net.alphadv.de Sat May 15 07:51:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 07:51:35 +0100 (BST) Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:22540 "EHLO mail.alphastar.de") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 07:51:34 +0100 Received: from SNaIlmail.Peter (62.158.198.178) by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==) for ; Sat, 15 May 2004 08:50:35 +0200 Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id i4F6mAOn004335 for ; Sat, 15 May 2004 08:48:11 +0200 Received: from localhost (pf@localhost) by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id IAA00758 for ; Sat, 15 May 2004 08:36:35 +0200 Date: Sat, 15 May 2004 08:36:35 +0200 (CEST) From: Peter Fuerst To: linux-mips@linux-mips.org Subject: IP28 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-1091800722-1084602995=:747" Reply-To: pf@net.alphadv.de Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5019 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pf@net.alphadv.de Precedence: bulk X-list: linux-mips This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811839-1091800722-1084602995=:747 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE How many Linux logins took place on a IP28-machine before ... ? with kind regards peter f=FCrst attached: dmesg ---1463811839-1091800722-1084602995=:747 Content-Type: APPLICATION/octet-stream; name="i2r10k.dmesg.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="i2r10k.dmesg.gz" H4sICORrpUACA2kycjEway5kbWVzZwDtO/1z2kiyP76y/oq+3Vd1UGtg9IVB 9diLjZMXduPYZUh23927SglpAB2SRquRbJO//nWPJBAYcJxN7uWHkIoLTff0 9PT3jJqhiGPuZUE8h0xAx+d3nSxbjdkpyIRzH/pdxtraZMGBS89NOHgLN3W9 jKcQSBhmadj6X2icj4ejERi9U3g1bmqTFeJl+6bMRBiKeyQ7XcGQFpzzDKau tzzVxDb0bwSVnINAQimIJAtELNuapsHhzzhzU7WVPFHry5XMeNRutx/NmghI eDoTaVQiQeQGccZjN/Y4BDEOuf4pJCmXEv7rpfR+xpXHBeZVDfOKx7mm6c1i aSgwNKMJIyThhmE5AmMxy+7dlGtmE27zGC4Ddx4LmQWe1Cwc4p64w22W8+0m vIxJXkMRRW7sw5WIg0ykmnat5PA3sLUdUBv3RGL/gT8E2Q8kvJRneRrTNxJF hIy2tZ9/hjyWHLm/g2v5Rrj+DUmMaBJsC1IsJeGHVIhsoCwjnknA/2pA7xtt vdtr623d6dy5aed9JwoSyacQJDWg0XMcx7DtdvWfOQ7PFsz5gRZMUiXKu1K0 a2YGU1wiaTQd7XpMvPB0cBeFQZw/lAOvghA1EPH18HmeCQIM/odLbRJE/O8i 5oOb8aR3cznRPNyICPnA1zU/kMsQtTpgmj91c39AFq7diTBHaj2myXkQirkY rDQXSSZojyl+j3nm+n66tTGNqyHWcxhzun2HTR1dd7ihEfNZjssz1JJa+DrP BpKngRs2WLMaHMW1MS/JZyn/Y6CfWeUWS/kPvo74SfrEpzbmmXKZ/yy3SAZT nw+NWSrQS3hKBnqduGH7Bs0kbWrX0ww9geZ2Si3AflTNYLZp6N2fzP6ZqRs/ 6bZt6wbwOEtXDrAHt8fUx8B/9NGQavbBTb1F4+y0zyrgbMZNxrYG/NkZO92d 3jzVhjfMAXTALJdgWoxZvR5GNM/NJQdC6THdw2cRz4I5dD1ddz1mAgWK89vh awfG/z1qjW5QxTe311dvRhcO4DjMgjQiJ4b3PJWoG+ha6Ll3gfqOur55h05X PgbSUSuxvmFrr/ZDcKchKvpDFOUO3Oq/4xg0DNZUjNykQeSmKxWL0twjW8AN eOjKprG8wNC0WMnAwxCzgsydzzlGK6N1765OAVXBZfCRE3vTVcblhpjvZm6N yqMZplHNeBcHswBDscTIFPs0t5imM8PaM1FHQylnrpWnNJBmH5Y8jXnYKLb1 RtnJXSlAo221DQMayexFzbKgMfe8Gk7fbluAutWZqfcROeUpD7krebMJP+pd E8ZuhlF5BboNzHAMw7H7MHw5ntAkS1OhlMwUw1ueFHbVJF6uhkrTGBsjQRsU aJCYgtB211q1FdKFcFMfFdgGtKLhIkjUd91UwJtUTIn6hgoaVZ66pDFHw+wW L9EYURlX8AJTZGGrxbi+Gffq44ZDAlXjpbFrlySZCMXtrzUPt+dXmLYSXKRY u7QrRpIqPkiBrd2lHGrk0p2GHP03hlj46BDo8pirEnfO0TT1frfLetpHDJ8Y l6pnUNB2MazjMNsaMeojb7h790jc2q/KClA8Rdoiy3HgK8W2oRsGU9IAcVEk 4AxTQopKh96ZTVL4h36GE+jb1euPgK77T+2dJPzeWdsuRxfBfEElgFfYQkGi it4ObiUUeQp+HkXoWWgxWA/02AP6+0fJCKzw0IGTPNvMUtUVNP5OWaZnmxit VI0FlIu2GPd5iCYdCpEQ25gX2lYPLXEurkY3Y+2q1LhhGV29u+wYXUO3rCW4 d24Qkn4pkjB7CctK7j4/RWXaRm+JsUjFaAoZXbZUUQFhDL+S8zbR2Cg0lx6/ cOUCQwyRpOFAGYmpszP0W5Fianagj4RY/0y3y/DR1EbKsg4T6Nq22V3P79Hq Vs8+61bzr0QeZ0fmG/ZmNvqkxfrrqRc5Jor0k9c+OwUbhdjrVfNv0IpbR1ZW gj6y9eGCe0tSIFaX8Nd7N8j+Wg/ipEwswtZ6am9PULVaHmZBEq46chHMsD7O 5zQpFntQfUzZwdMYeR3l5no8+l3FKSx/VRWLfCuTw7r73dvRq9HvZZh++3Ji tZkiVQxgvNYuMPD6WGGjR4zvXawmXcBkoaJ1tqKKFc2dSlnhBRwHkIbZZmYf TQJLO7Tvj7TS7QSw3sAgsAQpvCXHOqSq3Zfy3k187Rf0rRjTG651ESIKXBYe 5qe0FlDi5L5WltlqHoYPHxqeSFYpOm4GjWETDR4NQyyD9EUkYtdvy/tp2+cY jpJsVVgR8v7Qx/iWreQ6diPhyzFG4C4mAoyzVE7CsGCiWP1ObzONUsfajaEo 5Sr2quSFeExDl0cHxxzFHqazqd/vIXojSP+AAVhY6uM5yt0QUtj6FnbvCPZr zEyqJvnNzbyFL+aK21TpjBjEKgazCWsbVNjieeqPtufAJQZoH8ZtuApUumv4 0Qsez9M24rQxQjc1FUcVgTHOwaRlwuM6dzwcj0Dm0zLElluvcqdTbP7eN02v b7YoImLmHPx2qZ4vOrqJ1vhBrmJvwB5mM3rwI3fAMPChsX6Yhe4ci/QHyomb T5VTEHRaferw92u5Gza0gPU7v+RhB60A3ZxMMyB7UqWCqYoDkrPBHNtybH3N qv7tsyo9GTAoNPTbZd9UA3p9ANePffKL8eXkFqh2Yro5Yx7t4sMDRsiB4WnE RewLjGOv3v0ymozfIV9XGLlDB66Mvm2NW1Solx9ULFqSbhlacdbE4gXPsZge s9a559FBee/n/C1aiTKVdG0ZzNjhr3X78pdWjZ3J9fj16OJ8w87wsoWlOPx+ 1bItpk/OK3Yss1tjp8Q69jnAznmWUcjHghcFCXRIBOm7JHMl6lO6xIgpkeJX 9B0da9+cin5FqUz+OAFzmdXv2awLKLgWZQRY+PcpldF4SJfQsExbh6sLSjPl WRcpY8jGIk5Nxz86/THoj0l/rB3eyj3KlB3kzqy4QyRHobT0wj1VXU+3HiWV Rz5rtnVDRbbX52+MzaGFtSniUT5wylQwGd50Rjfk4yrWFKlCG91QUZerQP4o h4pZmahzivjyFGvfX1XS1JCYA6/XmPVIDA1MTjgYSJJAWXhgwe0XeRxLjZvW UGE7ym1CLJSd0s8KvQwomJ3Co/P7KRbPcjnYqiBPYX6/NYL/S69dCJntzPcF 3RoNTiEOZKt8aMRYEDfLOXTCLo7Dj4iq2reE1QreYjxxs8WgFDclqHKlMldK knpnfHVTy8yF/LH4FmJZ3oAlIs1I5rc3Q1AHArNjAAWczWpH0e2Ovov+/tUY IwPVZqgLYhQaVLjPMFYVSQAz66uUc0UyzqlQKOvP6oSiqswZoviaLz7wB+7d 8UZHokI7qvakc9no7Wji1M5/Z5YSJBKtz+GZ10m9tk9/cPH17HMss+7K2v9+ dw2qLUSs8FzccuWDsk6Y8EjZdL+kMI/BqgcHazw/mO+gFmpbIwtjl1ZEsty3 yDzliRq/5QoHqR+aOS80sVECsoKe6/qt+zTAABRhBG1/8sJptG/Uc49z+bXH N2Xtepey/ciCZtJbKnQMrlQ6lsUmDaM5HZRAlYd1un6xWudJ2uqf1Qp5usel dWG9cOvJT3GCodlYN7rhcb6xVEDYTDxHI19rFA+DhbHWLlWw3LOOeBJzEKd+ 30LhWrkf+phMXI9/ssKfaWd+xOV8F7AODBQSKD646DvFXrfOIDR+YHkRQZxH U8yMcx5zPJCLdB+zC3StvWztHc1E7i1qAW59L5XmccjvqMoxDwS4XXJKA9W0 g/tPPRP/jnWGR617kS73MRXKfaP8kMAPAjDUf5o+251glidPxtUvBJviYfUQ 7ADLx6Y8c/cHhvdRKTLgrKh7njUJbTBJxbTgd4lPDsxcdXjIBBAmbONBS0Jr ScfvVjJrWafA0zQWeLo0vjBp8+uRto+RPiTF79LaR5qqdb4vhGBGKuTYKcNH S3ppkGRSOXArQa/77sXPl5uS996gq16h0dTPoIo5DTf8PLJ7a4Dv4fl7eP4e nr/x8Pw9cH8P3NHxI8ax84Adz+SsWHJ9Sk0PH48jkfGt8+vBRY+tajKcHorC 7dcve3DsmP7pMgPnzHkqHdh1gCTwxV7ZJHvF6d4XB6CCDR92wHHg7fezEn8X lsv0KPyYLf8Z9pfPYn55lPUN9LMMyWJu5m/r083gqAxcHtEt8xeSBS7/KZJY 77di9zN366Ui3tkvDYF/bMtfdseKhU/W/obhfdLYQD9LHjYLMKJti2P09uXk mDBUbxhy++W8mXj4dIEo7IMC2UA/SyBdFib+U0hn9pKv1EuOpzB7jN6QRVhH 7ITMctSBf0O0qRZ7lptt8f1ZouzZ8yTa3jYOAOYkyeHoPIlpyy9Zr0ytgbVV MTWov1lq1mRKsw4yutPTVWAfY7/fV5e+z7jgzA+VPM8HeAfOIbhPnmWrvcA8 WV/7qo4CeI2BvHixtH4se+7AbuvQGIqExwt3zuNm1dlV9vJhPHSB2rW6lqap dyLCoBwexEW716Mqh0Bq5TeuzCrM7ctnw3hs6oVqHNOiFVVT1a4tKpfe6+1f DnKsAK5mre+o/0H7f1HJpENP//wRQgmdA7ey+PWkePUY8ZMokJ56onknSFzz +Z0aCIPpyUkUZ+qB9Hly56YaGmUBRfZ+mpHJnuDhoxjLouQAN2if0CE8tKM8 iGfikAFXfXWrhJ+cFH0Ho4KWRtO5lCIlAKPWZvUOKqTHW/VqEd4bbRuA+mLf szbTqrY2wig63TRqnKr3TSEkFloUYNYqelKLfjyJ4ysutSycfih7tIgIGh9/ yFIXqL88TfMkgzv1Cr4gs6i6Zu6payYRiFXSeT98eYlHNo8X3dcnCj/btNUR wugowlNyjXh0TK5Vn4LqyaSeBqDXqOoLvTbFLxK5p5GpanTD+Fa8afcdagrE J8Pq2Zau9yzQez3zzGYWGEb/jJndHquo17/YXfx31tXG927i7EMovxD5yZor oIWMM70LywuCvCqYKyGGZRqshIxLfjcfBblYs78LGRbbqQ3btmERhFh8BFVz 1FtfXp9joqURZBS7OzDTthTkdTBfbG1oTY0gWxtaQ96I+wMyQMgBGRDX+9ch yP51nrKiw6+uK0OK3H+JFCNxjH/hxym1r0kAClTq1zC9jXYtw+obtmo22UB0 JSncnW33VFfKBlR0BPX0voESpl6VDchci6VvqQ6WDcjaWco6sEe5yDNf3MfQ WqBn3T8+j5XwAwVe2QXwH9pFKlzfo5yCAVhiqip+nVB0LaiE0dxJM5bh2KrR 3FKJcLL+BRHVDXOhmnKJMeq6KAELN8zg7fVv8Je/7NnOl32Zx/Dvr3qtwhmX fdY0AN6hV5lbpcufeB//Z266FIstPCdnLfYVLtJK8kXB12Kt7oE1ahcnx2o4 JWhzp/xGq8vWFvDsGryqBRbc9Y8W1rkM+X6dHC/UP1Gx5e6fvk3aFcfWaU8k SXXa23+ie5Yo9h7hvlU5dGt3HqUY6M7j8Sn/a53IvtxG6tcZ5VaK64znXeA8 0ufeO4pvVZ9nW9eSW05+TA5l+N93N/nY1fdfOP57JPK5Trn8f2B5Q30ZhBhb G3p//6Z6TWjBWwEST+iAfvQZeu+xWltQmUiLEfrVsf+pd+uf0Qb0NG/92gX9 uzhaX9HvamNzRc+fuqPf4x87q44Zo2Jmb6haAyZ5qn7wKWazQ82Vs1nZXamN ywZvap9LDqq6OCtyqX6sMnl5ewUymMduuOmTUrc3eFZL1qghn9HZEKdgYVZV TtvrbZH9dfTmDRx8v1GtV5d1vd1POyAqBwoNOOsftdFBUJ20N12b84PLQsqj 8vezNcVBI5iBG6+aqoNTxOHqkFPVytOD+kLx0HfuV79dL57a39aP2bXGhest KY/Wf178h/Z/X/x8WJxAAAA= ---1463811839-1091800722-1084602995=:747-- From kumba@gentoo.org Sat May 15 08:12:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 08:12:42 +0100 (BST) Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:60365 "EHLO sccrmhc12.comcast.net") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 08:12:41 +0100 Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58]) by comcast.net (sccrmhc12) with ESMTP id <2004051507123201200l0qo0e> (Authid: kumba12345); Sat, 15 May 2004 07:12:32 +0000 Message-ID: <40A5C355.3060206@gentoo.org> Date: Sat, 15 May 2004 03:14:29 -0400 From: Kumba Reply-To: kumba@gentoo.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: IP28 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 5020 X-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 Peter Fuerst wrote: > > > How many Linux logins took place on a IP28-machine before ... ? > > > with kind regards > > peter fürst > > > > attached: dmesg Did you port linux to the IP28 I2, and if so, you got patches around by chance? (kinda curious that it's a 2.4.22 kernel) --Kumba -- "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 ladis@linux-mips.org Sat May 15 11:40:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 11:40:11 +0100 (BST) Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:20201 "HELO smtp.seznam.cz") by linux-mips.org with SMTP id ; Sat, 15 May 2004 11:40:10 +0100 Received: (qmail 21532 invoked from network); 15 May 2004 10:40:02 -0000 Received: from unknown (HELO umax645sx) (Ladislav.Michl@160.218.40.13) by smtp.seznam.cz with SMTP; 15 May 2004 10:40:02 -0000 Received: from ladis by umax645sx with local (Exim 3.36 #1 (Debian)) id 1BOwaR-0000gV-00; Sat, 15 May 2004 12:40:11 +0200 Date: Sat, 15 May 2004 12:40:07 +0200 To: Peter Fuerst Cc: linux-mips@linux-mips.org Subject: Re: IP28 Message-ID: <20040515104007.GA2604@umax645sx> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i From: Ladislav Michl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5021 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ladis@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, May 15, 2004 at 08:36:35AM +0200, Peter Fuerst wrote: > How many Linux logins took place on a IP28-machine before ... ? Let me answer with question? ;-) Where is the patch? ladis From sskowron@ET.PUT.Poznan.PL Sat May 15 15:19:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 15:19:51 +0100 (BST) Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:53728 "EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 15:19:47 +0100 Received: from europa (europa.et.put.poznan.pl [150.254.29.138]) by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4FEJjb22587 for ; Sat, 15 May 2004 16:19:45 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ; Sat, 15 May 2004 16:19:44 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4FEJhn27047 for ; Sat, 15 May 2004 16:19:43 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sat, 15 May 2004 16:19:43 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: CONFIG_MDULES patch Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1084630783=:26862" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5022 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-1084630783=:26862 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a patch for the (insignificant) bug I found some time ago and posted this morning. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." ---559023410-851401618-1084630783=:26862 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-cvs-mdules.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-cvs-mdules.patch" ZGlmZiAtdXJOIGxpbnV4LW1pcHMtY3ZzLW9yaWcvYXJjaC9taXBzL2tlcm5l bC90cmFwcy5jIGxpbnV4LW1pcHMteGtwaHlzL2FyY2gvbWlwcy9rZXJuZWwv dHJhcHMuYw0KLS0tIGxpbnV4LW1pcHMtY3ZzLW9yaWcvYXJjaC9taXBzL2tl cm5lbC90cmFwcy5jCVdlZCBBcHIgMjggMTU6NTQ6NTMgMjAwNA0KKysrIGxp bnV4LW1pcHMteGtwaHlzL2FyY2gvbWlwcy9rZXJuZWwvdHJhcHMuYwlTYXQg TWF5IDE1IDE2OjA5OjQyIDIwMDQNCkBAIC0yNzgsNyArMjc4LDEwIEBADQog CSk7DQogfQ0KIA0KLSNpZmRlZiBDT05GSUdfTURVTEVTDQorI2lmZGVmIENP TkZJR19NT0RVTEVTDQorDQorZXh0ZXJuIHNwaW5sb2NrX3QgbW9kbGlzdF9s b2NrOw0KK2V4dGVybiBzdHJ1Y3QgbGlzdF9oZWFkIG1vZHVsZXM7DQogDQog LyogR2l2ZW4gYW4gYWRkcmVzcywgbG9vayBmb3IgaXQgaW4gdGhlIG1vZHVs ZSBleGNlcHRpb24gdGFibGVzLiAqLw0KIGNvbnN0IHN0cnVjdCBleGNlcHRp b25fdGFibGVfZW50cnkgKnNlYXJjaF9tb2R1bGVfZGJldGFibGVzKHVuc2ln bmVkIGxvbmcgYWRkcikNCmRpZmYgLXVyTiBsaW51eC1taXBzLWN2cy1vcmln L2luY2x1ZGUvYXNtLW1pcHMvbW9kdWxlLmggbGludXgtbWlwcy14a3BoeXMv aW5jbHVkZS9hc20tbWlwcy9tb2R1bGUuaA0KLS0tIGxpbnV4LW1pcHMtY3Zz LW9yaWcvaW5jbHVkZS9hc20tbWlwcy9tb2R1bGUuaAlUdWUgQXByICA2IDA1 OjEzOjQ0IDIwMDQNCisrKyBsaW51eC1taXBzLXhrcGh5cy9pbmNsdWRlL2Fz bS1taXBzL21vZHVsZS5oCVNhdCBNYXkgMTUgMTY6MDk6NDIgMjAwNA0KQEAg LTcsNiArNyw3IEBADQogCS8qIERhdGEgQnVzIEVycm9yIGV4Y2VwdGlvbiB0 YWJsZXMgKi8NCiAJY29uc3Qgc3RydWN0IGV4Y2VwdGlvbl90YWJsZV9lbnRy eSAqZGJlX3RhYmxlX3N0YXJ0Ow0KIAljb25zdCBzdHJ1Y3QgZXhjZXB0aW9u X3RhYmxlX2VudHJ5ICpkYmVfdGFibGVfZW5kOw0KKwl1bnNpZ25lZCBpbnQg bnVtX2RiZWVudHJpZXM7DQogfTsNCiANCiB0eXBlZGVmIHVpbnQ4X3QgRWxm NjRfQnl0ZTsJCS8qIFR5cGUgZm9yIGEgOC1iaXQgcXVhbnRpdHkuICAqLw0K ZGlmZiAtdXJOIGxpbnV4LW1pcHMtY3ZzLW9yaWcva2VybmVsL21vZHVsZS5j IGxpbnV4LW1pcHMteGtwaHlzL2tlcm5lbC9tb2R1bGUuYw0KLS0tIGxpbnV4 LW1pcHMtY3ZzLW9yaWcva2VybmVsL21vZHVsZS5jCUZyaSBBcHIgMjMgMTc6 NTQ6MjIgMjAwNA0KKysrIGxpbnV4LW1pcHMteGtwaHlzL2tlcm5lbC9tb2R1 bGUuYwlTYXQgTWF5IDE1IDE2OjA5OjQyIDIwMDQNCkBAIC01NiwxMSArNTYs MTEgQEANCiAJKHN0cmNtcChNT0RVTEVfU1lNQk9MX1BSRUZJWCBsaXRlcmFs LCAoc3RyaW5nKSkgPT0gMCkNCiANCiAvKiBQcm90ZWN0cyBtb2R1bGUgbGlz dCAqLw0KLXN0YXRpYyBzcGlubG9ja190IG1vZGxpc3RfbG9jayA9IFNQSU5f TE9DS19VTkxPQ0tFRDsNCitzcGlubG9ja190IG1vZGxpc3RfbG9jayA9IFNQ SU5fTE9DS19VTkxPQ0tFRDsNCiANCiAvKiBMaXN0IG9mIG1vZHVsZXMsIHBy b3RlY3RlZCBieSBtb2R1bGVfbXV0ZXggQU5EIG1vZGxpc3RfbG9jayAqLw0K IHN0YXRpYyBERUNMQVJFX01VVEVYKG1vZHVsZV9tdXRleCk7DQotc3RhdGlj IExJU1RfSEVBRChtb2R1bGVzKTsNCitMSVNUX0hFQUQobW9kdWxlcyk7DQog DQogc3RhdGljIERFQ0xBUkVfTVVURVgobm90aWZ5X211dGV4KTsNCiBzdGF0 aWMgc3RydWN0IG5vdGlmaWVyX2Jsb2NrICogbW9kdWxlX25vdGlmeV9saXN0 Ow0K ---559023410-851401618-1084630783=:26862-- From sskowron@ET.PUT.Poznan.PL Sat May 15 15:29:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 15:29:22 +0100 (BST) Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:40929 "EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 15:29:21 +0100 Received: from europa (europa.et.put.poznan.pl [150.254.29.138]) by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4FETJb22707 for ; Sat, 15 May 2004 16:29:19 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ; Sat, 15 May 2004 16:29:18 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4FETHF27735 for ; Sat, 15 May 2004 16:29:17 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sat, 15 May 2004 16:29:16 +0200 (MET DST) From: Stanislaw Skowronek To: linux-mips@linux-mips.org Subject: XKPHYS_KERNEL patch - kernel in 64-bit space Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1084631356=:27563" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5023 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-1084631356=:27563 Content-Type: TEXT/PLAIN; charset=US-ASCII This patch allows the kernel to run from any place in the whole physical address space, not only the lowest 512 MB. It is REQUIRED for operation on IP30 (Octane) and for R8000 support. R8000 support would require changing the remaining compatibility segment accesses, which - from what I know - are limited to loading exception handlers. As I don't have an R8000 machine, I didn't introduce this here. Stanislaw Skowronek --<=>-- "You're not as old as the trees, not as young as the leaves. Not as free as the breeze, not as open as the seas." ---559023410-851401618-1084631356=:27563 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-cvs-xkphys.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-cvs-xkphys.patch" ZGlmZiAtdXJOIGxpbnV4LW1pcHMtY3ZzLW1kdWxlcy9hcmNoL21pcHMvS2Nv bmZpZyBsaW51eC1taXBzLXhrcGh5cy9hcmNoL21pcHMvS2NvbmZpZw0KLS0t IGxpbnV4LW1pcHMtY3ZzLW1kdWxlcy9hcmNoL21pcHMvS2NvbmZpZwlXZWQg QXByIDI4IDE4OjA1OjU0IDIwMDQNCisrKyBsaW51eC1taXBzLXhrcGh5cy9h cmNoL21pcHMvS2NvbmZpZwlTYXQgTWF5IDE1IDE2OjA5OjQyIDIwMDQNCkBA IC0xMjQxLDYgKzEyNDEsMTQgQEANCiAJYm9vbCAiU3VwcG9ydCBmb3IgNjQt Yml0IHBoeXNpY2FsIGFkZHJlc3Mgc3BhY2UiDQogCWRlcGVuZHMgb24gKENQ VV9SNFgwMCB8fCBDUFVfUjUwMDAgfHwgQ1BVX1JNNzAwMCB8fCBDUFVfUk05 MDAwIHx8IENQVV9SMTAwMDAgfHwgQ1BVX1NCMSB8fCBDUFVfTUlQUzMyIHx8 IENQVV9NSVBTNjQpICYmIE1JUFMzMg0KIA0KK2NvbmZpZyBYS1BIWVNfS0VS TkVMDQorCWJvb2wgIkFsbG93IGtlcm5lbCB0byBydW4gZnJvbSA2NC1iaXQg c2VnbWVudHMiDQorCWRlcGVuZHMgb24gTUlQUzY0DQorCWRlZmF1bHQgeSBp ZiBTR0lfSVAzMA0KKwloZWxwDQorCSAgVGhpcyBvcHRpb24gYWxsb3dzIHRv IGxvY2F0ZSB0aGUga2VybmVsIGluIDY0LWJpdCB1bm1hcHBlZCBtZW1vcnkN CisJICBzcGFjZSAoeGtwaHlzKS4gVGhpcyBpcyByZXF1aXJlZCBmb3IgT2N0 YW5lIChJUDMwKSBtYWNoaW5lcy4NCisNCiBjb25maWcgQ1BVX0FEVkFOQ0VE DQogCWJvb2wgIk92ZXJyaWRlIENQVSBPcHRpb25zIg0KIAlkZXBlbmRzIG9u IE1JUFMzMg0KZGlmZiAtdXJOIGxpbnV4LW1pcHMtY3ZzLW1kdWxlcy9hcmNo L21pcHMvTWFrZWZpbGUgbGludXgtbWlwcy14a3BoeXMvYXJjaC9taXBzL01h a2VmaWxlDQotLS0gbGludXgtbWlwcy1jdnMtbWR1bGVzL2FyY2gvbWlwcy9N YWtlZmlsZQlUdWUgQXByIDEzIDIzOjMwOjE2IDIwMDQNCisrKyBsaW51eC1t aXBzLXhrcGh5cy9hcmNoL21pcHMvTWFrZWZpbGUJU2F0IE1heSAxNSAxNjox MzoyNSAyMDA0DQpAQCAtMzUsNyArMzUsMTEgQEANCiBlbmRpZg0KIGlmZGVm IENPTkZJR19NSVBTNjQNCiBnY2MtYWJpCQkJPSA2NA0KK2lmZGVmIENPTkZJ R19YS1BIWVNfS0VSTkVMDQorZ2FzLWFiaQkJCT0gNjQNCitlbHNlDQogZ2Fz LWFiaQkJCT0gMzINCitlbmRpZg0KIHRvb2wtcHJlZml4CQk9ICQoNjRiaXQt dG9vbC1wcmVmaXgpDQogVVRTX01BQ0hJTkUJCTo9IG1pcHM2NA0KIGVuZGlm DQpAQCAtNjA4LDkgKzYxMiwxNSBAQA0KIA0KIGlmZGVmIENPTkZJR19NSVBT MzINCiBidWlsZC1iZmQJCT0gJCgzMmJpdC1iZmQpDQorb3V0cHV0LWJmZAkJ PSAkKDMyYml0LWJmZCkNCiBjZmxhZ3MteQkJKz0gJCgzMmJpdC1pc2EteSkN CiBlbmRpZg0KIGlmZGVmIENPTkZJR19NSVBTNjQNCitpZmRlZiBDT05GSUdf WEtQSFlTX0tFUk5FTA0KK291dHB1dC1iZmQJCT0gJCg2NGJpdC1iZmQpDQor ZWxzZQ0KK291dHB1dC1iZmQJCT0gJCgzMmJpdC1iZmQpDQorZW5kaWYNCiBi dWlsZC1iZmQJCT0gJCg2NGJpdC1iZmQpDQogY2ZsYWdzLXkJCSs9ICQoNjRi aXQtaXNhLXkpDQogZW5kaWYNCkBAIC02NTAsNyArNjYwLDcgQEANCiBBRkxB R1MJCSs9ICQoY2ZsYWdzLXkpDQogQ0ZMQUdTCQkrPSAkKGNmbGFncy15KQ0K IA0KLUxERkxBR1MJCQkrPSAtLW9mb3JtYXQgJCgzMmJpdC1iZmQpDQorTERG TEFHUwkJCSs9IC0tb2Zvcm1hdCAkKG91dHB1dC1iZmQpDQogDQogaGVhZC15 IDo9IGFyY2gvbWlwcy9rZXJuZWwvaGVhZC5vIGFyY2gvbWlwcy9rZXJuZWwv aW5pdF90YXNrLm8NCiANCmRpZmYgLXVyTiBsaW51eC1taXBzLWN2cy1tZHVs ZXMvYXJjaC9taXBzL2tlcm5lbC9zY2FsbDY0LW8zMi5TIGxpbnV4LW1pcHMt eGtwaHlzL2FyY2gvbWlwcy9rZXJuZWwvc2NhbGw2NC1vMzIuUw0KLS0tIGxp bnV4LW1pcHMtY3ZzLW1kdWxlcy9hcmNoL21pcHMva2VybmVsL3NjYWxsNjQt bzMyLlMJTW9uIEFwciAyNiAxNzowNjoxMCAyMDA0DQorKysgbGludXgtbWlw cy14a3BoeXMvYXJjaC9taXBzL2tlcm5lbC9zY2FsbDY0LW8zMi5TCVNhdCBN YXkgMTUgMTY6MDk6NDIgMjAwNA0KQEAgLTE0Miw3ICsxNDIsNyBAQA0KIAls ZAl0MCwgUFRfUjI5KHNwKQkJIyBnZXQgb2xkIHVzZXIgc3RhY2sgcG9pbnRl cg0KIAlQVFJfTEEJdDEsIDNmCQkJIyBjb3B5IDEgdG8gMiBhcmd1bWVudHMN CiAJc2xsCXQzLCB0MywgMg0KLQlzdWJ1CXQxLCB0Mw0KKwlkc3VidQl0MSwg dDMNCiAJanIJdDENCiANCiAJLyogT2ssIGNvcHkgdGhlIGFyZ3MgZnJvbSB0 aGUgbHVzZXIgc3RhY2sgdG8gdGhlIGtlcm5lbCBzdGFjayAqLw0KZGlmZiAt dXJOIGxpbnV4LW1pcHMtY3ZzLW1kdWxlcy9hcmNoL21pcHMva2VybmVsL3Nl dHVwLmMgbGludXgtbWlwcy14a3BoeXMvYXJjaC9taXBzL2tlcm5lbC9zZXR1 cC5jDQotLS0gbGludXgtbWlwcy1jdnMtbWR1bGVzL2FyY2gvbWlwcy9rZXJu ZWwvc2V0dXAuYwlTdW4gRmViICA4IDE1OjU3OjA0IDIwMDQNCisrKyBsaW51 eC1taXBzLXhrcGh5cy9hcmNoL21pcHMva2VybmVsL3NldHVwLmMJU2F0IE1h eSAxNSAxNjowOTo0MiAyMDA0DQpAQCAtMjIxLDEzICsyMjEsMTMgQEANCiAJ CWluaXRyZF9zdGFydCA9ICh1bnNpZ25lZCBsb25nKSZpbml0cmRfaGVhZGVy WzJdOw0KIAkJaW5pdHJkX2VuZCA9IGluaXRyZF9zdGFydCArIGluaXRyZF9o ZWFkZXJbMV07DQogCX0NCi0Jc3RhcnRfcGZuID0gUEZOX1VQKENQSFlTQURE UigoJl9lbmQpKyhpbml0cmRfZW5kIC0gaW5pdHJkX3N0YXJ0KSArIFBBR0Vf U0laRSkpOw0KKwlzdGFydF9wZm4gPSBQRk5fVVAoS1BIWVNBRERSKCgmX2Vu ZCkrKGluaXRyZF9lbmQgLSBpbml0cmRfc3RhcnQpICsgUEFHRV9TSVpFKSk7 DQogI2Vsc2UNCiAJLyoNCiAJICogUGFydGlhbGx5IHVzZWQgcGFnZXMgYXJl IG5vdCB1c2FibGUgLSB0aHVzDQogCSAqIHdlIGFyZSByb3VuZGluZyB1cHdh cmRzLg0KIAkgKi8NCi0Jc3RhcnRfcGZuID0gUEZOX1VQKENQSFlTQUREUigm X2VuZCkpOw0KKwlzdGFydF9wZm4gPSBQRk5fVVAoS1BIWVNBRERSKCZfZW5k KSk7DQogI2VuZGlmCS8qIENPTkZJR19CTEtfREVWX0lOSVRSRCAqLw0KIA0K ICNpZm5kZWYgQ09ORklHX1NHSV9JUDI3DQpAQCAtMzU3LDEwICszNTcsMTAg QEANCiAJCSAgICAgICAodm9pZCAqKWluaXRyZF9zdGFydCwNCiAJCSAgICAg ICBpbml0cmRfc2l6ZSk7DQogDQotCQlpZiAoQ1BIWVNBRERSKGluaXRyZF9l bmQpID4gUEZOX1BIWVMobWF4X2xvd19wZm4pKSB7DQorCQlpZiAoS1BIWVNB RERSKGluaXRyZF9lbmQpID4gUEZOX1BIWVMobWF4X2xvd19wZm4pKSB7DQog CQkJcHJpbnRrKCJpbml0cmQgZXh0ZW5kcyBiZXlvbmQgZW5kIG9mIG1lbW9y eSAiDQogCQkJICAgICAgICIoMHglMCpMeCA+IDB4JTAqTHgpXG5kaXNhYmxp bmcgaW5pdHJkXG4iLA0KLQkJCSAgICAgICBzaXplb2YobG9uZykgKiAyLCBD UEhZU0FERFIoaW5pdHJkX2VuZCksDQorCQkJICAgICAgIHNpemVvZihsb25n KSAqIDIsIEtQSFlTQUREUihpbml0cmRfZW5kKSwNCiAJCQkgICAgICAgc2l6 ZW9mKGxvbmcpICogMiwgUEZOX1BIWVMobWF4X2xvd19wZm4pKTsNCiAJCQlp bml0cmRfc3RhcnQgPSBpbml0cmRfZW5kID0gMDsNCiAJCX0NCmRpZmYgLXVy TiBsaW51eC1taXBzLWN2cy1tZHVsZXMvYXJjaC9taXBzL21tL2luaXQuYyBs aW51eC1taXBzLXhrcGh5cy9hcmNoL21pcHMvbW0vaW5pdC5jDQotLS0gbGlu dXgtbWlwcy1jdnMtbWR1bGVzL2FyY2gvbWlwcy9tbS9pbml0LmMJTW9uIEFw ciAxOSAxODozNjozNSAyMDA0DQorKysgbGludXgtbWlwcy14a3BoeXMvYXJj aC9taXBzL21tL2luaXQuYwlTYXQgTWF5IDE1IDE2OjA5OjQyIDIwMDQNCkBA IC0yNjYsOCArMjY2LDggQEANCiB7DQogI2lmZGVmIENPTkZJR19NSVBTNjQN CiAJLyogU3dpdGNoIGZyb20gS1NFRzAgdG8gWEtQSFlTIGFkZHJlc3NlcyAq Lw0KLQlzdGFydCA9ICh1bnNpZ25lZCBsb25nKXBoeXNfdG9fdmlydChDUEhZ U0FERFIoc3RhcnQpKTsNCi0JZW5kID0gKHVuc2lnbmVkIGxvbmcpcGh5c190 b192aXJ0KENQSFlTQUREUihlbmQpKTsNCisJc3RhcnQgPSAodW5zaWduZWQg bG9uZylwaHlzX3RvX3ZpcnQoS1BIWVNBRERSKHN0YXJ0KSk7DQorCWVuZCA9 ICh1bnNpZ25lZCBsb25nKXBoeXNfdG9fdmlydChLUEhZU0FERFIoZW5kKSk7 DQogI2VuZGlmDQogCWlmIChzdGFydCA8IGVuZCkNCiAJCXByaW50ayhLRVJO X0lORk8gIkZyZWVpbmcgaW5pdHJkIG1lbW9yeTogJWxkayBmcmVlZFxuIiwN CkBAIC0yOTMsNyArMjkzLDcgQEANCiAJYWRkciA9ICh1bnNpZ25lZCBsb25n KSAmX19pbml0X2JlZ2luOw0KIAl3aGlsZSAoYWRkciA8ICh1bnNpZ25lZCBs b25nKSAmX19pbml0X2VuZCkgew0KICNpZmRlZiBDT05GSUdfTUlQUzY0DQot CQlwYWdlID0gUEFHRV9PRkZTRVQgfCBDUEhZU0FERFIoYWRkcik7DQorCQlw YWdlID0gUEFHRV9PRkZTRVQgfCBLUEhZU0FERFIoYWRkcik7DQogI2Vsc2UN CiAJCXBhZ2UgPSBhZGRyOw0KICNlbmRpZg0KZGlmZiAtdXJOIGxpbnV4LW1p cHMtY3ZzLW1kdWxlcy9hcmNoL21pcHMvbW0vdGxiLWFuZGVzLmMgbGludXgt bWlwcy14a3BoeXMvYXJjaC9taXBzL21tL3RsYi1hbmRlcy5jDQotLS0gbGlu dXgtbWlwcy1jdnMtbWR1bGVzL2FyY2gvbWlwcy9tbS90bGItYW5kZXMuYwlX ZWQgTWFyIDE3IDIyOjI2OjQ0IDIwMDQNCisrKyBsaW51eC1taXBzLXhrcGh5 cy9hcmNoL21pcHMvbW0vdGxiLWFuZGVzLmMJU2F0IE1heSAxNSAxNjowOTo0 MiAyMDA0DQpAQCAtMjY0LDcgKzI2NCw3IEBADQogI2VuZGlmDQogI2lmZGVm IENPTkZJR19NSVBTNjQNCiAJbWVtY3B5KCh2b2lkICopKENLU0VHMCArIDB4 MDAwKSwgJmV4Y2VwdF92ZWMwX2dlbmVyaWMsIDB4ODApOw0KLQltZW1jcHko KHZvaWQgKikoQ0tTRUcwICsgMHgwODApLCBleGNlcHRfdmVjMV9yMTBrLCAw eDgwKTsNCisJbWVtY3B5KCh2b2lkICopKENLU0VHMCArIDB4MDgwKSwgJmV4 Y2VwdF92ZWMxX3IxMGssIDB4ODApOw0KIAlmbHVzaF9pY2FjaGVfcmFuZ2Uo Q0tTRUcwICsgMHg4MCwgQ0tTRUcwICsgMHgxMDApOw0KICNlbmRpZg0KIH0N CmRpZmYgLXVyTiBsaW51eC1taXBzLWN2cy1tZHVsZXMvaW5jbHVkZS9hc20t bWlwcy9hZGRyc3BhY2UuaCBsaW51eC1taXBzLXhrcGh5cy9pbmNsdWRlL2Fz bS1taXBzL2FkZHJzcGFjZS5oDQotLS0gbGludXgtbWlwcy1jdnMtbWR1bGVz L2luY2x1ZGUvYXNtLW1pcHMvYWRkcnNwYWNlLmgJU3VuIE5vdiAzMCAwMjo1 MjoyNSAyMDAzDQorKysgbGludXgtbWlwcy14a3BoeXMvaW5jbHVkZS9hc20t bWlwcy9hZGRyc3BhY2UuaAlTYXQgTWF5IDE1IDE2OjA5OjQyIDIwMDQNCkBA IC0zLDYgKzMsNyBAQA0KICAqIExpY2Vuc2UuICBTZWUgdGhlIGZpbGUgIkNP UFlJTkciIGluIHRoZSBtYWluIGRpcmVjdG9yeSBvZiB0aGlzIGFyY2hpdmUN CiAgKiBmb3IgbW9yZSBkZXRhaWxzLg0KICAqDQorICogQ29weXJpZ2h0IChD KSAyMDA0IFN0YW5pc2xhdyBTa293cm9uZWsNCiAgKiBDb3B5cmlnaHQgKEMp IDE5OTYsIDk5IFJhbGYgQmFlY2hsZQ0KICAqIENvcHlyaWdodCAoQykgMjAw MCwgMjAwMiAgTWFjaWVqIFcuIFJvenlja2kNCiAgKiBDb3B5cmlnaHQgKEMp IDE5OTAsIDE5OTkgYnkgU2lsaWNvbiBHcmFwaGljcywgSW5jLg0KQEAgLTM4 LDE0ICszOSw0MCBAQA0KICNlbmRpZg0KIA0KIC8qDQorICogTWVtb3J5IHNl Z21lbnRzICg2NGJpdCBrZXJuZWwgbW9kZSBhZGRyZXNzZXMpDQorICogVGhl IGNvbXBhdGliaWxpdHkgc2VnbWVudHMgdXNlIHRoZSBmdWxsIDY0LWJpdCBz aWduIGV4dGVuZGVkIHZhbHVlLiAgTm90ZQ0KKyAqIHRoZSBSODAwMCBkb2Vz bid0IGhhdmUgdGhlbSBzbyBkb24ndCByZWZlcmVuY2UgdGhlc2UgaW4gZ2Vu ZXJpYyBNSVBTIGNvZGUuDQorICovDQorI2RlZmluZSBYS1VTRUcJCQkweDAw MDAwMDAwMDAwMDAwMDANCisjZGVmaW5lIFhLU1NFRwkJCTB4NDAwMDAwMDAw MDAwMDAwMA0KKyNkZWZpbmUgWEtQSFlTCQkJMHg4MDAwMDAwMDAwMDAwMDAw DQorI2RlZmluZSBYS1NFRwkJCTB4YzAwMDAwMDAwMDAwMDAwMA0KKyNkZWZp bmUgQ0tTRUcwCQkJMHhmZmZmZmZmZjgwMDAwMDAwDQorI2RlZmluZSBDS1NF RzEJCQkweGZmZmZmZmZmYTAwMDAwMDANCisjZGVmaW5lIENLU1NFRwkJCTB4 ZmZmZmZmZmZjMDAwMDAwMA0KKyNkZWZpbmUgQ0tTRUczCQkJMHhmZmZmZmZm ZmUwMDAwMDAwDQorDQorDQorLyoNCiAgKiBNZW1vcnkgc2VnbWVudHMgKDMy Yml0IGtlcm5lbCBtb2RlIGFkZHJlc3NlcykNCiAgKiBUaGVzZSBhcmUgdGhl IHRyYWRpdGlvbmFsIG5hbWVzIHVzZWQgaW4gdGhlIDMyLWJpdCB1bml2ZXJz ZS4NCi0gKi8NCisgKiBPbiBNSVBTNjQgdGhleSBhcmUgNjQtYml0IGxvbmcg Y29uc3RhbnRzIGJlY2F1c2U6DQorICogIDEpIGRyaXZlcnMgd2hpY2ggdXNl IHRoZW0gZm9yIGxvbmdzIG9yIHBvaW50ZXJzIHdpbGwgd29yayBjb3JyZWN0 bHkNCisgKiAgMikgZHJpdmVycyB3aGljaCB1c2UgdGhlbSBmcm9tIGludHMg d2lsbCBvbmx5IHRydW5jYXRlIHRoZW0NCisgKi8NCisjaWZkZWYgQ09ORklH X01JUFM2NA0KKyNkZWZpbmUgS1VTRUcJCQlYS1VTRUcNCisjZGVmaW5lIEtT RUcwCQkJQ0tTRUcwDQorI2RlZmluZSBLU0VHMQkJCUNLU0VHMQ0KKyNkZWZp bmUgS1NFRzIJCQlDS1NFRzINCisjZGVmaW5lIEtTRUczCQkJQ0tTRUczDQor I2Vsc2UNCiAjZGVmaW5lIEtVU0VHCQkJMHgwMDAwMDAwMA0KICNkZWZpbmUg S1NFRzAJCQkweDgwMDAwMDAwDQogI2RlZmluZSBLU0VHMQkJCTB4YTAwMDAw MDANCiAjZGVmaW5lIEtTRUcyCQkJMHhjMDAwMDAwMA0KICNkZWZpbmUgS1NF RzMJCQkweGUwMDAwMDAwDQorI2VuZGlmDQogDQogLyoNCiAgKiBSZXR1cm5z IHRoZSBrZXJuZWwgc2VnbWVudCBiYXNlIG9mIGEgZ2l2ZW4gYWRkcmVzcw0K QEAgLTcxLDE5ICs5OCwyMCBAQA0KICNkZWZpbmUgQ0tTRUcyQUREUihhKQkJ KENQSFlTQUREUihhKSB8IENLU0VHMikNCiAjZGVmaW5lIENLU0VHM0FERFIo YSkJCShDUEhZU0FERFIoYSkgfCBDS1NFRzMpDQogDQotLyoNCi0gKiBNZW1v cnkgc2VnbWVudHMgKDY0Yml0IGtlcm5lbCBtb2RlIGFkZHJlc3NlcykNCi0g KiBUaGUgY29tcGF0aWJpbGl0eSBzZWdtZW50cyB1c2UgdGhlIGZ1bGwgNjQt Yml0IHNpZ24gZXh0ZW5kZWQgdmFsdWUuICBOb3RlDQotICogdGhlIFI4MDAw IGRvZXNuJ3QgaGF2ZSB0aGVtIHNvIGRvbid0IHJlZmVyZW5jZSB0aGVzZSBp biBnZW5lcmljIE1JUFMgY29kZS4NCi0gKi8NCi0jZGVmaW5lIFhLVVNFRwkJ CTB4MDAwMDAwMDAwMDAwMDAwMA0KLSNkZWZpbmUgWEtTU0VHCQkJMHg0MDAw MDAwMDAwMDAwMDAwDQotI2RlZmluZSBYS1BIWVMJCQkweDgwMDAwMDAwMDAw MDAwMDANCi0jZGVmaW5lIFhLU0VHCQkJMHhjMDAwMDAwMDAwMDAwMDAwDQot I2RlZmluZSBDS1NFRzAJCQkweGZmZmZmZmZmODAwMDAwMDANCi0jZGVmaW5l IENLU0VHMQkJCTB4ZmZmZmZmZmZhMDAwMDAwMA0KLSNkZWZpbmUgQ0tTU0VH CQkJMHhmZmZmZmZmZmMwMDAwMDAwDQotI2RlZmluZSBDS1NFRzMJCQkweGZm ZmZmZmZmZTAwMDAwMDANCisNCisjaWZkZWYgQ09ORklHX01JUFM2NA0KKyNk ZWZpbmUgSzBCQVNFCQkJMHhhODAwMDAwMDAwMDAwMDAwDQorI2Vsc2UNCisj ZGVmaW5lIEswQkFTRQkJCUtTRUcwDQorI2VuZGlmDQorDQorI2lmZGVmIENP TkZJR19YS1BIWVNfS0VSTkVMDQorI2RlZmluZSBLMFJBTUJBU0UJCTB4YTgw MDAwMDAyMDAwMDAwMA0KKyNkZWZpbmUgS1BIWVNBRERSCQlYUEhZU0FERFIN CisjZWxzZQ0KKyNkZWZpbmUgSzBSQU1CQVNFCQlLMEJBU0UNCisjZGVmaW5l IEtQSFlTQUREUgkJQ1BIWVNBRERSDQorI2VuZGlmDQogDQogLyoNCiAgKiBD YWNoZSBtb2RlcyBmb3IgWEtQSFlTIGFkZHJlc3MgY29udmVyc2lvbiBtYWNy b3MNCg== ---559023410-851401618-1084631356=:27563-- From ica2_ts@csv.ica.uni-stuttgart.de Sat May 15 15:51:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 15:51:01 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:52323 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 15:51:00 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BP0V6-0001DM-00; Sat, 15 May 2004 16:50:56 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BP0V6-0008Ax-00; Sat, 15 May 2004 16:50:56 +0200 Date: Sat, 15 May 2004 16:50:56 +0200 To: Stanislaw Skowronek Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: XKPHYS_KERNEL patch - kernel in 64-bit space Message-ID: <20040515145056.GC14219@rembrandt.csv.ica.uni-stuttgart.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5024 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Stanislaw Skowronek wrote: [snip] > diff -urN linux-mips-cvs-mdules/arch/mips/mm/tlb-andes.c linux-mips-xkphys/arch/mips/mm/tlb-andes.c > --- linux-mips-cvs-mdules/arch/mips/mm/tlb-andes.c Wed Mar 17 22:26:44 2004 > +++ linux-mips-xkphys/arch/mips/mm/tlb-andes.c Sat May 15 16:09:42 2004 > @@ -264,7 +264,7 @@ > #endif > #ifdef CONFIG_MIPS64 > memcpy((void *)(CKSEG0 + 0x000), &except_vec0_generic, 0x80); > - memcpy((void *)(CKSEG0 + 0x080), except_vec1_r10k, 0x80); > + memcpy((void *)(CKSEG0 + 0x080), &except_vec1_r10k, 0x80); > flush_icache_range(CKSEG0 + 0x80, CKSEG0 + 0x100); This flush_icache_range should start from CKSEG0, not (CKSEG0 + 80). Thiemo From sskowron@ET.PUT.Poznan.PL Sat May 15 15:54:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 15 May 2004 15:54:41 +0100 (BST) Received: from athena.et.put.poznan.pl ([IPv6:::ffff:150.254.29.137]:36585 "EHLO athena.et.put.poznan.pl") by linux-mips.org with ESMTP id ; Sat, 15 May 2004 15:54:38 +0100 Received: from athena (athena [150.254.29.137]) by athena.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4FEsWg17617; Sat, 15 May 2004 16:54:32 +0200 (MET DST) Received: from helios.et.put.poznan.pl ([150.254.29.65]) by athena (MailMonitor for SMTP v1.2.2 ) ; Sat, 15 May 2004 16:54:32 +0200 (MET DST) Received: from localhost (sskowron@localhost) by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i4FEsVX29452; Sat, 15 May 2004 16:54:31 +0200 (MET DST) X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs Date: Sat, 15 May 2004 16:54:31 +0200 (MET DST) From: Stanislaw Skowronek To: Thiemo Seufer cc: linux-mips@linux-mips.org Subject: Re: XKPHYS_KERNEL patch - kernel in 64-bit space In-Reply-To: <20040515145056.GC14219@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sskowron@ET.PUT.Poznan.PL Precedence: bulk X-list: linux-mips > This flush_icache_range should start from CKSEG0, not (CKSEG0 + 80). Ahh, yeah - not important as we can't get the first exception anyway. But would be nice to fix. Stanislaw Skowronek From mchouque@mcs.bigip.mine.nu Sun May 16 02:22:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 02:22:56 +0100 (BST) Received: from mta2.srv.hcvlny.cv.net ([IPv6:::ffff:167.206.5.68]:41526 "EHLO mta2.srv.hcvlny.cv.net") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 02:22:55 +0100 Received: from mcs.bigip.mine.nu (ool-4353cae3.dyn.optonline.net [67.83.202.227]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0HXS00IHF95ZQF@mta2.srv.hcvlny.cv.net> for linux-mips@linux-mips.org; Sat, 15 May 2004 21:22:49 -0400 (EDT) Received: from mcs.bigip.mine.nu (localhost.localdomain [127.0.0.1]) by mcs.bigip.mine.nu (8.12.11/8.12.11) with ESMTP id i4G1MnK8012278; Sat, 15 May 2004 21:22:49 -0400 Received: (from mchouque@localhost) by mcs.bigip.mine.nu (8.12.11/8.12.11/Submit) id i4G1MjfH012276; Sat, 15 May 2004 21:22:45 -0400 Date: Sat, 15 May 2004 21:22:45 -0400 From: Mathieu Chouquet-Stringer X-Face: %JOeya=Dg!}[/#Go&*&cQ+)){p1c8}u\Fg2Q3&)kothIq|JnWoVzJtCFo~4X, linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com Message-id: <20040516012245.GA11733@localhost> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.4.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: 5026 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mchouque@online.fr Precedence: bulk X-list: linux-mips Hi, if you use O=/someotherdir or KBUILD_OUTPUT=/someotherdir on the following architectures: alpha, mips, sh and cris, the build process is probably going to fail at one point or another, depending on the target you used, because make can't find scripts/Makefile.build or scripts/Makefile.clean. The following patch (which should apply cleanly to the latest 2.6.6 bk tree) fixes this, I greped the whole tree and these four were the only "offenders" I found. PS: Andrew I mailed you because I couldn't find the maintainer for the sh port and you're the last who touched arch/sh/Makefile --- arch/alpha/Makefile.orig 2004-05-15 20:46:06.000000000 -0400 +++ arch/alpha/Makefile 2004-05-15 20:47:52.000000000 -0400 @@ -106,10 +106,10 @@ boot := arch/alpha/boot all boot: $(boot)/vmlinux.gz $(boot)/vmlinux.gz: vmlinux - $(Q)$(MAKE) -f scripts/Makefile.build obj=$(boot) $@ + $(Q)$(MAKE) $(build)=$(boot) $@ bootimage bootpfile bootpzfile: vmlinux - $(Q)$(MAKE) -f scripts/Makefile.build obj=$(boot) $(boot)/$@ + $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ prepare: include/asm-$(ARCH)/asm_offsets.h @@ -121,7 +121,7 @@ include/asm-$(ARCH)/asm_offsets.h: arch/ $(call filechk,gen-asm-offsets) archclean: - $(Q)$(MAKE) -f scripts/Makefile.clean obj=$(boot) + $(Q)$(MAKE) $(clean)=$(boot) CLEAN_FILES += include/asm-$(ARCH)/asm_offsets.h --- arch/mips/Makefile.orig 2004-05-15 20:48:52.000000000 -0400 +++ arch/mips/Makefile 2004-05-15 20:49:58.000000000 -0400 @@ -686,7 +686,7 @@ vmlinux.64: vmlinux --change-addresses=0xa800000080000000 $< $@ endif -makeboot =$(Q)$(MAKE) -f scripts/Makefile.build obj=arch/mips/boot $(1) +makeboot =$(Q)$(MAKE) $(build)=arch/mips/boot $(1) ifdef CONFIG_SGI_IP27 all: vmlinux.64 @@ -708,9 +708,9 @@ CLEAN_FILES += vmlinux.ecoff \ vmlinux.rm200 archclean: - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/boot - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/baget - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/lasat + @$(MAKE) $(clean)=arch/mips/boot + @$(MAKE) $(clean)=arch/mips/baget + @$(MAKE) $(clean)=arch/mips/lasat # Generate ; Sun, 16 May 2004 02:36:25 +0100 Received: from [192.168.1.1] (dsl-203-113-219-176.VIC.netspace.net.au [203.113.219.176]) by mail.netspace.net.au (Postfix) with ESMTP id EE4DD4213B for ; Sun, 16 May 2004 11:36:18 +1000 (EST) From: Jason Hecker Reply-To: jhecker@wireless.org.au Organization: Melbourne Wireless To: linux-mips@linux-mips.org Subject: EJTAG and RTL8181 Date: Sun, 16 May 2004 11:36:16 +1000 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200405161136.16071.jhecker@wireless.org.au> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5027 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jhecker@wireless.org.au Precedence: bulk X-list: linux-mips I am trying to get JTAG working with Realtek's RTL8181 part. It uses a Lexra LX5280 core which is mostly MIPS R3000 compatible (bar the unaligned load and save instructions). A chronicle of my efforts can be seen here: http://www.wireless.org.au/~jhecker/rtljtag Realtek can't offer me a BSDL file as they claim they use some 3rd party tool to talk to it with JTAG. My lack of luck with Macraigor's Wiggler and a demo of their OCD debugger (in Windows) in EJTAG mode just yielded a screenful of errors. Has anyone had much experience with Wigglers and MIPS based parts that don't support EJTAG? Any ideas on trying to reverse engineer the boundary scan chain? From dan@embeddededge.com Sun May 16 04:26:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 04:26:08 +0100 (BST) Received: from embeddededge.com ([IPv6:::ffff:209.113.146.155]:32007 "EHLO penguin.netx4.com") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 04:26:07 +0100 Received: from [192.168.2.27] (x1000-57.tellink.net [63.161.110.249]) by penguin.netx4.com (8.12.8/8.12.9) with ESMTP id i4G3AMIm030418; Sat, 15 May 2004 23:10:23 -0400 In-Reply-To: <200405161136.16071.jhecker@wireless.org.au> References: <200405161136.16071.jhecker@wireless.org.au> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: linux-mips@linux-mips.org From: Dan Malek Subject: Re: EJTAG and RTL8181 Date: Sat, 15 May 2004 23:26:21 -0400 To: jhecker@wireless.org.au X-Mailer: Apple Mail (2.613) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5028 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@embeddededge.com Precedence: bulk X-list: linux-mips On May 15, 2004, at 9:36 PM, Jason Hecker wrote: > Has anyone had much experience with Wigglers and MIPS based parts that > don't > support EJTAG? Any ideas on trying to reverse engineer the boundary > scan > chain? Have you contacted Abatron? I've used their BDI2000 on quite a few MIPS processors. Anything that supported some form of E/JTAG worked well. They are awesome folks to work with, and are likely to be able to provide some form of assistance or information. -- Dan From kieran@pawsoff.org Sun May 16 12:36:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 12:36:26 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:61712 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 12:36:25 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id D421438212C; Sun, 16 May 2004 12:36:22 +0100 (BST) Date: Sun, 16 May 2004 12:36:22 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516113622.GA14049@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> 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: <40A478B0.3070005@bitbox.co.uk> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5029 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 14, 2004 at 08:43:44AM +0100, Peter Horton wrote: > Have you tried any other hardware in the slot, PCI network card perhaps ? >=20 > P. yeah. adding cards like a tulip network card, linksys wmp11 wireless card. = even a=20 wintv pci (analogue) card all work ; 0000:00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 211= 42/43=20 (rev 41) Subsystem: Kingston Technologies: Unknown device 0001 Flags: bus master, medium devsel, latency 64, IRQ 23 I/O ports at 1080 [size=3D288M] Memory at 120c0400 (32-bit, non-prefetchable) [size=3D1K] Expansion ROM at 00040000 [disabled] cat /proc/interrupts CPU0 2: 0 XT-PIC cascade 14: 27636 XT-PIC ide0 18: 435142 MIPS timer 19: 696 MIPS eth0 20: 7 MIPS eth2 21: 302 MIPS serial 22: 0 MIPS cascade 23: 100002 MIPS eth1 it just seems to be the DVB card that the pci code doesnt like, for some re= ason .. all ideas warmly received ;) Kieran. --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAp1I2OWPbH1PXZ18RAk8PAJ0UExFzPf6YSRYvktmYwgsGyzEHcACdHAZ8 U4BKT14OoxQeoKyOz0kgIpc= =g40R -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From js@convergence.de Sun May 16 16:20:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 16:20:46 +0100 (BST) Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:53459 "EHLO mail.convergence.de") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 16:20:45 +0100 Received: from pd9e7244d.dip.t-dialin.net ([217.231.36.77] helo=abc.local) by mail.convergence.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BPNOx-0001Xm-7j; Sun, 16 May 2004 17:18:12 +0200 Received: from js by abc.local with local (Exim 3.35 #1 (Debian)) id 1BPNRx-0002Vs-00; Sun, 16 May 2004 17:21:13 +0200 Date: Sun, 16 May 2004 17:21:13 +0200 From: Johannes Stezenbach To: Kieran Fulke Cc: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516152113.GA9390@convergence.de> Mail-Followup-To: Johannes Stezenbach , Kieran Fulke , linux-mips@linux-mips.org References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040516113622.GA14049@getyour.pawsoff.org> User-Agent: Mutt/1.5.6i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5030 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips On Sun, May 16, 2004 at 12:36:22PM +0100, Kieran Fulke wrote: > On Fri, May 14, 2004 at 08:43:44AM +0100, Peter Horton wrote: > > > Have you tried any other hardware in the slot, PCI network card perhaps ? > > > > P. > > yeah. adding cards like a tulip network card, linksys wmp11 wireless card. even a > wintv pci (analogue) card all work ; ... > it just seems to be the DVB card that the pci code doesnt like, for some reason .. > > all ideas warmly received ;) Let me add some information from your posts to linux-dvb and from the driver source. I would appreciate it if someone could look it over (full source is in linux/drivers/media/common/saa7146_core.c). The driver is known to work on a variety of platforms, including one TX49 based development system (last tested a few months back, though). From your first posting: PCI: Setting latency timer of device 0000:00:0a.0 to 64 irq 23: nobody cared! Call Trace: [snipped] handlers: [] Disabling IRQ #23 saa7146: found saa7146 @ mem b2080800 (revision 1, irq 23) (0x13c2,0x1011). Second try with debug enabled: saa7146: saa7146_register_extension(): ext:c001efb0 saa7146: register extension 'budget_ci dvb'. saa7146: saa7146_init_one(): pci:83fdac00 irq 23: nobody cared! saa7146_init_one() does the following: /* disable all irqs */ saa7146_write(dev, IER, 0); ... if (request_irq(dev->pci->irq, interrupt_hw, SA_SHIRQ | SA_INTERRUPT, dev->name, dev)) {error...} ... INFO(("found saa7146 @ mem %p (revision %d, irq %d) (0x%04x,0x%04x).\n", ...)); interrupt_hw() does: /* read out the interrupt status register */ isr = saa7146_read(dev, ISR); /* is this our interrupt? */ if ( 0 == isr ) { /* nope, some other device */ return IRQ_NONE; } ... return IRQ_HANDLED; In essence, I believe something other than the saa7146 must be asserting irq 23. Or is it possible that a bug in the PCI init stuff in saa7146_core.c can cause this? Any hints how we could debug this would be welcome. Johannes From ralf@linux-mips.org Sun May 16 18:05:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 18:05:02 +0100 (BST) Received: from p508B60BE.dip.t-dialin.net ([IPv6:::ffff:80.139.96.190]:27454 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 18:05:01 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4GH4oxT004901; Sun, 16 May 2004 19:04:51 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4GH4jpv004900; Sun, 16 May 2004 19:04:45 +0200 Date: Sun, 16 May 2004 19:04:45 +0200 From: Ralf Baechle To: Johannes Stezenbach , Kieran Fulke , linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516170445.GA4793@linux-mips.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040516152113.GA9390@convergence.de> User-Agent: Mutt/1.4.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: 5031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote: > In essence, I believe something other than the saa7146 must be asserting > irq 23. Or is it possible that a bug in the PCI init stuff in > saa7146_core.c can > cause this? Any hints how we could debug this would be welcome. arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect. It connects CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare interrupt already uses this bit. Sharing the timer interrupt with something else isn't impossible but seems a less than bright thing to do. Somebody with production hw to test should compare this interrupt dispatch function with old working code from 2.2 or 2.4 ... Ralf From kieran@pawsoff.org Sun May 16 18:11:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 18:11:34 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:53265 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 18:11:33 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 87C3338212C; Sun, 16 May 2004 18:11:30 +0100 (BST) Date: Sun, 16 May 2004 18:11:30 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516171130.GA14878@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20040516170445.GA4793@linux-mips.org> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5032 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --UugvWAfsgieZRqgk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 16, 2004 at 07:04:45PM +0200, Ralf Baechle wrote: >=20 > Sharing the timer interrupt with something else isn't impossible but seems > a less than bright thing to do. Somebody with production hw to test > should compare this interrupt dispatch function with old working code > from 2.2 or 2.4 ... >=20 what exactly do you mean by test? as far as the dvb drivers go, they=20 work without any problem (with in the same box / hardware) under 2.4. if=20 you can suggest some test cases / methods, i'll happily run them ... regards, Kieran. --UugvWAfsgieZRqgk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAp6DCOWPbH1PXZ18RAoBSAJ96Z2v/4OUmb4z9V1uaQmAgiknYwACgjB96 UbdrkIuXbI0oVwqdFkSzmds= =wHvt -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From js@convergence.de Sun May 16 18:21:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 18:21:01 +0100 (BST) Received: from mail.convergence.de ([IPv6:::ffff:212.84.236.4]:10967 "EHLO mail.convergence.de") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 18:21:00 +0100 Received: from pd9e7244d.dip.t-dialin.net ([217.231.36.77] helo=abc.local) by mail.convergence.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BPPHO-0005RF-UT; Sun, 16 May 2004 19:18:29 +0200 Received: from js by abc.local with local (Exim 3.35 #1 (Debian)) id 1BPPKZ-0002ZC-00; Sun, 16 May 2004 19:21:43 +0200 Date: Sun, 16 May 2004 19:21:43 +0200 From: Johannes Stezenbach To: Ralf Baechle Cc: Kieran Fulke , linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516172143.GA9753@convergence.de> Mail-Followup-To: Johannes Stezenbach , Ralf Baechle , Kieran Fulke , linux-mips@linux-mips.org References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040516170445.GA4793@linux-mips.org> User-Agent: Mutt/1.5.6i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5033 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips On Sun, May 16, 2004 at 07:04:45PM +0200, Ralf Baechle wrote: > On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote: > > > In essence, I believe something other than the saa7146 must be asserting > > irq 23. Or is it possible that a bug in the PCI init stuff in > > saa7146_core.c can > > cause this? Any hints how we could debug this would be welcome. > > arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect. It connects > CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare > interrupt already uses this bit. > > Sharing the timer interrupt with something else isn't impossible but seems > a less than bright thing to do. Somebody with production hw to test > should compare this interrupt dispatch function with old working code > from 2.2 or 2.4 ... Sorry if I snipped too much from Kieran's mail. He reported a tulip network card works in the same PCI slot, and it uses irq 23, too. But this one from Kieran's mail looks dubious: > > cat /proc/interrupts > > CPU0 > > 2: 0 XT-PIC cascade > > 14: 27636 XT-PIC ide0 > > 18: 435142 MIPS timer > > 19: 696 MIPS eth0 > > 20: 7 MIPS eth2 > > 21: 302 MIPS serial > > 22: 0 MIPS cascade > > 23: 100002 MIPS eth1 100002 is just where note_interrupt() disables an unhandled irq, so maybe Kieran's report that the tulip card works was wrong? Johannes From kieran@pawsoff.org Sun May 16 18:37:07 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 18:37:08 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:58897 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 18:37:07 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 40A9338212C; Sun, 16 May 2004 18:37:06 +0100 (BST) Date: Sun, 16 May 2004 18:37:06 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516173706.GA14977@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5034 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 16, 2004 at 07:21:43PM +0200, Johannes Stezenbach wrote: >=20 > 100002 is just where note_interrupt() disables an unhandled irq, so > maybe Kieran's report that the tulip card works was wrong? >=20 interesting. the card pulled an ip address from dhcp happily enough, but i'= ll see if it'll=20 pull data back and forth.=20 Kieran. --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAp6bBOWPbH1PXZ18RAjDwAJ4l+ksP1E0CP4BcNy1BcKaTPeqtTACbBPzv qHFLN1yM7vTdwJEUWTtI/Ys= =sCtL -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From kieran@pawsoff.org Sun May 16 19:04:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 19:04:16 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:64273 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 19:04:15 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 5A6AF38212C; Sun, 16 May 2004 19:04:14 +0100 (BST) Date: Sun, 16 May 2004 19:04:14 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040516180414.GA15001@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> <20040516172143.GA9753@convergence.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <20040516172143.GA9753@convergence.de> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5035 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 16, 2004 at 07:21:43PM +0200, Johannes Stezenbach wrote: > > > 23: 100002 MIPS eth1 >=20 > 100002 is just where note_interrupt() disables an unhandled irq, so > maybe Kieran's report that the tulip card works was wrong? >=20 yup. please excuse me, i was obviously typing out of my arse (or not=20 testing 'thoroughly' enough ...). anyway, the following turns up on=20 running 'dhcpcd eth1' (tulip card in pci slot); ksymoops 2.4.9 on mips 2.6.6-mipscvs-20040510. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.6-mipscvs-20040510/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod Call Trace: [<80084624>] [<8008461c>] [<80084720>] [<800826d0>] =20 [<80084a78>] [<80082ec0>] [<800826d0>] [<80082ec0>] [<800ec230>] =20 [<800ac7f4>] [<800ac6f8>] [<80084578>] [<800ac7f4>] [<80084b18>] =20 [<800826d0>] [<8012ea48>] [<80082ec0>] [<800b179c>] [<800b1788>] =20 [<800ac7f4>] [<80085468>] [<80085480>] [] [<80084bec>] =20 [<80082ec0>] [] [<800dcf4c>] [<801a684c>] [<801ac4e4>] =20 [<800d7924>] [<801a85fc>] [<801a66c0>] [<801e9ae0>] [<801e9958>] =20 [<800d7c44>] [<80091b50>] [<801ec8c4>] [<801fd878>] [<801fd888>] =20 [<8019e27c>] [<8019e1c4>] [<8019dc9c>] [<800ff3bc>] [<800ff194>] =20 [<8019e4bc>] [<8008be88>] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; 80084624 <__report_bad_irq+48/8c> Trace; 8008461c <__report_bad_irq+40/8c> Trace; 80084720 Trace; 800826d0 Trace; 80084a78 Trace; 80082ec0 Trace; 800826d0 Trace; 80082ec0 Trace; 800ec230 Trace; 800ac7f4 Trace; 800ac6f8 <__do_softirq+48/ec> Trace; 80084578 Trace; 800ac7f4 Trace; 80084b18 Trace; 800826d0 Trace; 8012ea48 Trace; 80082ec0 Trace; 800b179c Trace; 800b1788 Trace; 800ac7f4 Trace; 80085468 Trace; 80085480 Trace; c0051270 <__crc_bio_map_user+9a864/130ac7> Trace; 80084bec Trace; 80082ec0 Trace; c0053db8 <__crc_bio_map_user+9d3ac/130ac7> Trace; 800dcf4c Trace; 801a684c Trace; 801ac4e4 Trace; 800d7924 Trace; 801a85fc Trace; 801a66c0 Trace; 801e9ae0 Trace; 801e9958 Trace; 800d7c44 Trace; 80091b50 Trace; 801ec8c4 Trace; 801fd878 Trace; 801fd888 Trace; 8019e27c <__sock_create+1a4/384> Trace; 8019e1c4 <__sock_create+ec/384> Trace; 8019dc9c Trace; 800ff3bc Trace; 800ff194 Trace; 8019e4bc Trace; 8008be88 Trace; c0051270 <__crc_bio_map_user+9a864/130ac7> 2 warnings and 1 error issued. Results may not be reliable. regards, kieran. --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAp60eOWPbH1PXZ18RAgqNAJ4nbY4SuTLcBdw8C50OO9qyG3O6sgCdEYXa b31qq1tTUKsmjRiZ0Qzph8U= =NK/3 -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From sam@ravnborg.org Sun May 16 21:23:14 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 16 May 2004 21:23:15 +0100 (BST) Received: from pfepc.post.tele.dk ([IPv6:::ffff:195.41.46.237]:3677 "EHLO pfepc.post.tele.dk") by linux-mips.org with ESMTP id ; Sun, 16 May 2004 21:23:14 +0100 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepc.post.tele.dk (Postfix) with ESMTP id 1C30726280A; Sun, 16 May 2004 22:23:09 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 500) id B2957F550C; Sun, 16 May 2004 22:33:22 +0200 (CEST) Date: Sun, 16 May 2004 22:33:22 +0200 From: Sam Ravnborg To: Mathieu Chouquet-Stringer , linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com, mikael.starvik@axis.com Subject: Re: [PATCH] Fix for 2.6.6 Makefiles to get KBUILD_OUTPUT working Message-ID: <20040516203322.GA4784@mars.ravnborg.org> Mail-Followup-To: Mathieu Chouquet-Stringer , linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com, mikael.starvik@axis.com References: <20040516012245.GA11733@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040516012245.GA11733@localhost> User-Agent: Mutt/1.4.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: 5036 X-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 Sat, May 15, 2004 at 09:22:45PM -0400, Mathieu Chouquet-Stringer wrote: > Hi, > > if you use O=/someotherdir or KBUILD_OUTPUT=/someotherdir on the following > architectures: alpha, mips, sh and cris, the build process is probably > going to fail at one point or another, depending on the target you used, > because make can't find scripts/Makefile.build or scripts/Makefile.clean. > > The following patch (which should apply cleanly to the latest 2.6.6 bk > tree) fixes this, I greped the whole tree and these four were the only > "offenders" I found. Thanks, it has been on my todo for a while. A few comments though. > --- arch/mips/Makefile.orig 2004-05-15 20:48:52.000000000 -0400 > +++ arch/mips/Makefile 2004-05-15 20:49:58.000000000 -0400 > > -makeboot =$(Q)$(MAKE) -f scripts/Makefile.build obj=arch/mips/boot $(1) > +makeboot =$(Q)$(MAKE) $(build)=arch/mips/boot $(1) Please get rid of makeboot. Use $(Q)$(MAKE) ... instead. Hereby the '+' sign is no longer needed (used today where makeboot is used. > archclean: > - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/boot > - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/baget > - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/lasat > + @$(MAKE) $(clean)=arch/mips/boot > + @$(MAKE) $(clean)=arch/mips/baget > + @$(MAKE) $(clean)=arch/mips/lasat Please use $(Q)$(MAKE), so command is expanded with make V=1, and to make it look like all other usages. > --- arch/cris/Makefile.orig 2004-05-15 20:59:49.000000000 -0400 > +++ arch/cris/Makefile 2004-05-15 21:00:36.000000000 -0400 OK. But this file in general looks strange. There seems to be no way to descend into arch-v10? Mikael - any pending patches for this file / architecture? Mathieu, could you please update the patch and send onwards to Andrew. Do not touch the cris Makefile more than you did, the maintainer needs to clean it up. Thanks, Sam From Nitin@soc-soft.com Mon May 17 07:38:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 07:38:07 +0100 (BST) Received: from [IPv6:::ffff:202.56.254.199] ([IPv6:::ffff:202.56.254.199]:14603 "EHLO virus-gw.soc-soft.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Mon, 17 May 2004 07:38:06 +0100 Received: from keys.soc-soft.com ([192.168.4.37]) by 192.168.4.15 with trend_isnt_name_B; Mon, 17 May 2004 12:08:02 +0530 Received: from mail.soc-soft.com ([192.168.4.25]) by keys.soc-soft.com (PGP Universal service); Mon, 17 May 2004 12:07:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: Date: Mon, 17 May 2004 12:07:56 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcQ72X0TvoLyREtsT/mTmkPxvuYAbA== From: "Nitin P Mahajan" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5037 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Nitin@soc-soft.com Precedence: bulk X-list: linux-mips help From phorton@bitbox.co.uk Mon May 17 09:40:43 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 09:40:44 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:58011 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 09:40:43 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BPdfp-0002be-00; Mon, 17 May 2004 09:40:37 +0100 Message-ID: <40A87A81.5070100@bitbox.co.uk> Date: Mon, 17 May 2004 09:40:33 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Kieran Fulke , linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> In-Reply-To: <20040516170445.GA4793@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5038 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips Ralf Baechle wrote: >On Sun, May 16, 2004 at 05:21:13PM +0200, Johannes Stezenbach wrote: > > > >>In essence, I believe something other than the saa7146 must be asserting >>irq 23. Or is it possible that a bug in the PCI init stuff in >>saa7146_core.c can >>cause this? Any hints how we could debug this would be welcome. >> >> > >arch/mips/cobalt/irq.c:cobalt_irq() looks pretty suspect. It connects >CAUSEF_IP7 and interrupt 23 - but the CPU's builtin count / compare >interrupt already uses this bit. > >Sharing the timer interrupt with something else isn't impossible but seems >a less than bright thing to do. Somebody with production hw to test >should compare this interrupt dispatch function with old working code >from 2.2 or 2.4 ... > > > I've got no hardware here but the code looks roughly similiar As the Cobalt's use Galileo timer 0 for clock interrupts we could use Galileo rather than count/compare for the HPT. Precision would be 50MHz rather than 125MHz but that shouldn't be a problem :-) P. From joerg@factorlocal.de Mon May 17 11:27:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 11:27:44 +0100 (BST) Received: from h-213.61.96.13.host.de.colt.net ([IPv6:::ffff:213.61.96.13]:42646 "EHLO aurora.factorlocal.de") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 11:27:40 +0100 Received: from dev7.factorlocal.de ([192.168.168.7] helo=[192.168.168.221]) by aurora.factorlocal.de with asmtp (Exim 4.20) id 1BPfLO-0007ev-Vw for linux-mips@linux-mips.org; Mon, 17 May 2004 12:27:38 +0200 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> References: <5055A94A-A503-11D8-B16C-000A956A056E@aurora.factorlocal.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joerg Rossdeutscher Subject: Re: RaQ2: Installation stops at "loading debian installer" [SOLVED] Date: Mon, 17 May 2004 12:27:38 +0200 To: linux-mips@linux-mips.org X-Mailer: Apple Mail (2.613) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5039 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joerg@factorlocal.de Precedence: bulk X-list: linux-mips Hi, Am 13. Mai 2004 um 19:31 Uhr schrieb Joerg Rossdeutscher: > The RaQ2 boots the debian-installer-b4 via tftp and nfs until the > display shows "Loading debian installer". Then it stops. > I now have found an old Laptop that still has a serial port. > > > The last lines say: > > >execute initrd={initrd-size}@{initrd-start} > console=ttyS0,{console-speed} > elf: 80080000 <-- 00001000 1916928t+176112t > elf: entry 801fc040 > net: interface down > > (I type this by hand, so excuse possibly errors) > > That's it. Ethereal shows no more net traffic and no remarkable errors > before the installation stops. Nothings happens. And nothing at google > for this message. Hm. Thanks to everyone who tried to help. Peter Horton guided me to the solution. The kernel was broken, the md5sum did not match. I quote his PM how to find out: >It's possible the kernel is not booting because of a problem with the >initrd code. What happens if you type the following at the boot shell >prompt :- > > net > tftp {dhcp-next-server} vmlinux-2.4.25-r5k-cobalt > md5sum > execute console=ttyS0,{console-speed} > >You can also check that the MD5 sum displayed matches that of the kernel >file on the TFTP server. That md5 differed fronm the one on the debian server. Re-downloaded, now installing. :-) Yipiiie! Bye, Ratti -- _____________________________ Joerg Rossdeutscher Factor Design AG Schulterblatt 58 20357 Hamburg Germany T +49.40.432 571-43 F +49.40.432 571-99 E-mail: joerg@factordesign.com http://www.factordesign.com From kieran@pawsoff.org Mon May 17 12:47:01 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 12:47:02 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:19461 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 12:47:01 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 8189038212C; Mon, 17 May 2004 12:46:58 +0100 (BST) Date: Mon, 17 May 2004 12:46:58 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040517114658.GA20884@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> <40A87A81.5070100@bitbox.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <40A87A81.5070100@bitbox.co.uk> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5040 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 17, 2004 at 09:40:33AM +0100, Peter Horton wrote: >=20 > I've got no hardware here but the code looks roughly similiar >=20 > As the Cobalt's use Galileo timer 0 for clock interrupts we could use=20 > Galileo rather than count/compare for the HPT. >=20 > Precision would be 50MHz rather than 125MHz but that shouldn't be a=20 > problem :-) >=20 is there any (uncomplicated) way of forcing the machine to assign a=20 different IRQ to its single pci slot? Kieran. --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqKYyOWPbH1PXZ18RAi24AJ0ff6I1Pwin1ca4o9eIlju/6EgEdgCeLIIg w53K2bxYmpmZWbuR7DIZAsE= =GScd -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From phorton@bitbox.co.uk Mon May 17 12:58:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 12:58:07 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:53148 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 12:58:06 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BPgkp-0002yj-00; Mon, 17 May 2004 12:57:59 +0100 Message-ID: <40A8A8C5.1030908@bitbox.co.uk> Date: Mon, 17 May 2004 12:57:57 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kieran Fulke CC: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> <40A87A81.5070100@bitbox.co.uk> <20040517114658.GA20884@getyour.pawsoff.org> In-Reply-To: <20040517114658.GA20884@getyour.pawsoff.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips Kieran Fulke wrote: >On Mon, May 17, 2004 at 09:40:33AM +0100, Peter Horton wrote: > > > >>I've got no hardware here but the code looks roughly similiar >> >>As the Cobalt's use Galileo timer 0 for clock interrupts we could use >>Galileo rather than count/compare for the HPT. >> >>Precision would be 50MHz rather than 125MHz but that shouldn't be a >>problem :-) >> >> >> > >is there any (uncomplicated) way of forcing the machine to assign a >different IRQ to its single pci slot? > > > It's hard wired. P. From kieran@pawsoff.org Mon May 17 13:04:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 13:04:07 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:22277 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 13:04:06 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 5090638212C; Mon, 17 May 2004 13:04:05 +0100 (BST) Date: Mon, 17 May 2004 13:04:05 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040517120405.GA20945@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> <40A87A81.5070100@bitbox.co.uk> <20040517114658.GA20884@getyour.pawsoff.org> <40A8A8C5.1030908@bitbox.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <40A8A8C5.1030908@bitbox.co.uk> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5042 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 17, 2004 at 12:57:57PM +0100, Peter Horton wrote: > > > It's hard wired. >=20 that is quite inconvenient.=20 so has that timer code changed a lot from 2.4 -> 2.6 ? i've gone back to=20 2.4 in the meantime, which has its own issues but works for me ..... Kieran. --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqKo1OWPbH1PXZ18RAo2QAJ4rTlXVc69EHZZCLJ4WvHYBIOY+1wCgpU7e eSNlHTWN4SyY2OSrUlzeZaU= =ksVi -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From phorton@bitbox.co.uk Mon May 17 13:20:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 13:20:41 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:57500 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 13:20:40 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BPh6g-0002ze-00; Mon, 17 May 2004 13:20:34 +0100 Message-ID: <40A8AE11.1040300@bitbox.co.uk> Date: Mon, 17 May 2004 13:20:33 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kieran Fulke CC: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> <40A478B0.3070005@bitbox.co.uk> <20040516113622.GA14049@getyour.pawsoff.org> <20040516152113.GA9390@convergence.de> <20040516170445.GA4793@linux-mips.org> <40A87A81.5070100@bitbox.co.uk> <20040517114658.GA20884@getyour.pawsoff.org> <40A8A8C5.1030908@bitbox.co.uk> <20040517120405.GA20945@getyour.pawsoff.org> In-Reply-To: <20040517120405.GA20945@getyour.pawsoff.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5043 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips Kieran Fulke wrote: >On Mon, May 17, 2004 at 12:57:57PM +0100, Peter Horton wrote: > > > >>It's hard wired. >> >> >> > >that is quite inconvenient. >so has that timer code changed a lot from 2.4 -> 2.6 ? i've gone back to >2.4 in the meantime, which has its own issues but works for me ..... > > > I'll have a look when I get home. P. From manwithastinkydog@yahoo.com Mon May 17 16:06:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 16:06:39 +0100 (BST) Received: from web13301.mail.yahoo.com ([IPv6:::ffff:216.136.175.37]:52034 "HELO web13301.mail.yahoo.com") by linux-mips.org with SMTP id ; Mon, 17 May 2004 16:06:36 +0100 Message-ID: <20040517150631.13795.qmail@web13301.mail.yahoo.com> Received: from [12.33.232.234] by web13301.mail.yahoo.com via HTTP; Mon, 17 May 2004 08:06:31 PDT Date: Mon, 17 May 2004 08:06:31 -0700 (PDT) From: Ken Giusti Subject: running 2.6 on swarm pass1 To: linux-mips@linux-mips.org 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: 5044 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: manwithastinkydog@yahoo.com Precedence: bulk X-list: linux-mips Hi, I've got a swarm board with a pass1 sibyte sb1250. Here's the relevant system info from the boot up console: CFE version 1.0.36 for SWARM (64bit,MP,BE) Build Date: Tue Jan 28 17:17:30 PST 2003 (mpl@lc-sj1-092) Copyright (C) 2000,2001,2002,2003 Broadcom Corporation. Initializing Arena. Initializing Devices. SWARM board revision 1 Config switch: 0 CPU: BCM1250 Pass 1 L2 Cache Status: OK Wafer ID: Not set SysCfg: 0000000000DB0400 [PLL_DIV: 8, IOB0_DIV: CPUCLK/4, IOB1_DIV: CPUCLK/3] CPU type 0x1040101: 400MHz Total memory: 0x80000000 bytes (2048MB) Total memory used by CFE: 0x8FE83A00 - 0x90000000 (1558016) Initialized Data: 0x8FE83A00 - 0x8FE8D940 (40768) BSS Area: 0x8FE8D940 - 0x8FE8E000 (1728) Local Heap: 0x8FE8E000 - 0x8FF8E000 (1048576) Stack Area: 0x8FF8E000 - 0x8FF90000 (8192) Text (code) segment: 0x8FF90000 - 0x8FFFFFB4 (458676) Boot area (physical): 0x0FE42000 - 0x0FE82000 Relocation Factor: I:F0390000 - D:0FE82A00 I've been running 2.4.26 taken directly from kernel.org, using 3.0.3 gcc toolset. Runs great, once I applied a set of pass1 patches, and some fixes from linux-mips.org code. Now I'm trying to get 2.6 running, but I'm having no luck. I've pulled both the 2.6.6 release from kernel.org, and the 2.6.5 release from linux-mip cvs. In both cases, I've used the default swarm config that shipped with the release, unmodified. Gcc 3.0.3 - same as 2.4. 2.6.6 from kernel.org doesn't appear to run at all. Once I load the image via CFE and type "go" I get absolutely no console output - the system just hangs. 2.6.5 from linux-mips is a bit better - I get bootup console output, then an immediate crash (included below). Has anyone had any luck getting 2.6 running on swarm with pass1? Thanks for any help you can provide, -Ken. Algorithmics/MIPS FPU Emulator v1.5 Kernel unaligned instruction access in arch/mips/kernel/unaligned.c::do_ade, lin e 544[#1]: Cpu 1 $ 0 : 00000000 801357e0 00000071 8f9fceb8 $ 4 : 00000012 00000000 8f9a7d00 00000000 $ 8 : 00000000 00000002 801359f8 00000002 $12 : 0047e048 00000000 803b77a8 803b7788 $16 : 00000000 80134350 00000000 80143000 $20 : 00800020 fffffffd 8ffb7d40 ffffffe0 $24 : 00000000 00000002 $28 : ffffffff 8f9a7ce8 8ffaad10 8f9a7cf8 Hi : 80134350 Lo : 80143000 epc : 00000002 0x2 Not tainted ra : 8f9a7cf8 0x8f9a7cf8 Status: 10001f03 KERNEL EXL IE Cause : 00800010 BadVA : 00000002 PrId : 03040101 Process events/1 (pid: 112, threadinfo=8f9a6000, task=8f9fceb8) Stack : 0fbcdbc0 00001fe0 00000001 00000020 24021017 0000000c 2ab07e30 10001f03 00000000 80109bdc 00000000 00000000 00000000 801357e0 00000000 00000071 00000000 8f9fceb8 00000000 00800112 00000000 8f985cf8 00000000 8f9a7f80 00000000 00000000 00000000 00000000 00000000 00000002 00000000 801359f8 00000000 00000002 00000000 0047e048 00000000 7fff7f82 00000000 803b77a8 ... Call Trace: [<80109bdc>] kernel_thread+0x3c/0x80 [<801357e0>] do_exit+0x350/0x528 [<801359f8>] next_thread+0x0/0x78 [<80146b20>] ____call_usermodehelper+0x0/0x110 [<8010bb78>] do_signal+0x720/0xe68 [<80146c98>] wait_for_helper+0x68/0xb0 [<80146b20>] ____call_usermodehelper+0x0/0x110 [<80131828>] do_fork+0x198/0x240 [<80146b20>] ____call_usermodehelper+0x0/0x110 [<8010c2e8>] do_notify_resume+0x28/0x38 [<80106c10>] work_notifysig+0xc/0x14 [<80106bcc>] work_resched+0x8/0x40 [<801357e0>] do_exit+0x350/0x528 [<801359f8>] next_thread+0x0/0x78 [<80134350>] allow_signal+0xb0/0xf8 [<80143000>] do_sigaction+0x2d8/0x338 [<80143000>] do_sigaction+0x2d8/0x338 [<80134350>] allow_signal+0xb0/0xf8 [<80146c30>] wait_for_helper+0x0/0xb0 [<80146c98>] wait_for_helper+0x68/0xb0 [<80146c30>] wait_for_helper+0x0/0xb0 [<80109bf0>] kernel_thread+0x50/0x80 [<80146d10>] __call_usermodehelper+0x30/0xa0 [<80109bdc>] kernel_thread+0x3c/0x80 Code: (Bad address in epc) __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ From stuartl@longlandclan.hopto.org Mon May 17 16:07:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 16:07:48 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:13696 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 16:07:45 +0100 Received: (qmail 31959 invoked by uid 204); 18 May 2004 01:07:33 +1000 Received: from stuartl@longlandclan.hopto.org by www by uid 201 with qmail-scanner-1.16 (spamassassin: 2.63. Clear:. Processed in 0.035041 secs); 17 May 2004 15:07:33 -0000 Received: from unknown (HELO longlandclan.hopto.org) (10.0.0.251) by 192.168.5.1 with SMTP; 18 May 2004 01:07:32 +1000 Message-ID: <40A8D534.6010706@longlandclan.hopto.org> Date: Tue, 18 May 2004 01:07:32 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kieran Fulke CC: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> In-Reply-To: <20040513183059.GA25743@getyour.pawsoff.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5045 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Kieran Fulke wrote: > hi folks, > > getting the below when loading the dvb budget_ci module. it disables IRQ > #23 which is attached to the card, rendering it useless. i asked the > same question over there and none of them suspect it to be a DVB > problem. some esoteric pci bug perhaps? > If it's any help... I've had similar issues trying to use an Adaptec AHA-2940AU PCI SCSI card in a Gateway Microserver running Linux 2.6.[56] (not sure which one exactly...). I'm now running Linux 2.4.26 quite happily (the box is being used as a fileserver for LANs), but I can put 2.6.6 back on if the debugging info would be of any use. -- +-------------------------------------------------------------+ | Stuart Longland stuartl at longlandclan.hopto.org | | Brisbane Mesh Node: 719 http://stuartl.cjb.net/ | | I haven't lost my mind - it's backed up on a tape somewhere | | Atomic Linux Project <---> http://atomicl.berlios.de/ | +-------------------------------------------------------------+ From mchouque@mcs.bigip.mine.nu Mon May 17 16:23:49 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 16:23:50 +0100 (BST) Received: from mta9.srv.hcvlny.cv.net ([IPv6:::ffff:167.206.5.42]:2357 "EHLO mta9.srv.hcvlny.cv.net") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 16:23:49 +0100 Received: from mcs.bigip.mine.nu (ool-4353cae3.dyn.optonline.net [67.83.202.227]) by mta9.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0HXV004LX6QAP6@mta9.srv.hcvlny.cv.net> for linux-mips@linux-mips.org; Mon, 17 May 2004 11:23:01 -0400 (EDT) Received: from mcs.bigip.mine.nu (localhost.localdomain [127.0.0.1]) by mcs.bigip.mine.nu (8.12.11/8.12.11) with ESMTP id i4HFNDlZ030435; Mon, 17 May 2004 11:23:13 -0400 Received: (from mchouque@localhost) by mcs.bigip.mine.nu (8.12.11/8.12.11/Submit) id i4HFNBaw030433; Mon, 17 May 2004 11:23:11 -0400 Date: Mon, 17 May 2004 11:23:11 -0400 From: Mathieu Chouquet-Stringer X-Face: %JOeya=Dg!}[/#Go&*&cQ+)){p1c8}u\Fg2Q3&)kothIq|JnWoVzJtCFo~4X To: linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com, mikael.starvik@axis.com, sam@ravnborg.org Mail-followup-to: Mathieu Chouquet-Stringer , linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com, mikael.starvik@axis.com, sam@ravnborg.org Message-id: <20040517152311.GA29999@localhost> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.4.1i References: <20040516012245.GA11733@localhost> <20040516203322.GA4784@mars.ravnborg.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mchouque@online.fr Precedence: bulk X-list: linux-mips On Sun, May 16, 2004 at 10:33:22PM +0200, Sam Ravnborg wrote: > > --- arch/mips/Makefile.orig 2004-05-15 20:48:52.000000000 -0400 > > +++ arch/mips/Makefile 2004-05-15 20:49:58.000000000 -0400 > > > > -makeboot =$(Q)$(MAKE) -f scripts/Makefile.build obj=arch/mips/boot $(1) > > +makeboot =$(Q)$(MAKE) $(build)=arch/mips/boot $(1) > > Please get rid of makeboot. Use $(Q)$(MAKE) ... instead. > Hereby the '+' sign is no longer needed (used today where makeboot is used. Ok, I applied the changes you requested, please check the diff for mips as I had to modify some other lines too. --- arch/alpha/Makefile.orig 2004-05-15 20:46:06.000000000 -0400 +++ arch/alpha/Makefile 2004-05-15 20:47:52.000000000 -0400 @@ -106,10 +106,10 @@ boot := arch/alpha/boot all boot: $(boot)/vmlinux.gz $(boot)/vmlinux.gz: vmlinux - $(Q)$(MAKE) -f scripts/Makefile.build obj=$(boot) $@ + $(Q)$(MAKE) $(build)=$(boot) $@ bootimage bootpfile bootpzfile: vmlinux - $(Q)$(MAKE) -f scripts/Makefile.build obj=$(boot) $(boot)/$@ + $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ prepare: include/asm-$(ARCH)/asm_offsets.h @@ -121,8 +121,8 @@ include/asm-$(ARCH)/asm_offsets.h: arch/ $(call filechk,gen-asm-offsets) archclean: - $(Q)$(MAKE) -f scripts/Makefile.clean obj=$(boot) + $(Q)$(MAKE) $(clean)=$(boot) CLEAN_FILES += include/asm-$(ARCH)/asm_offsets.h --- arch/mips/Makefile.orig 2004-05-15 20:48:52.000000000 -0400 +++ arch/mips/Makefile 2004-05-17 11:11:57.000000000 -0400 @@ -686,8 +686,6 @@ vmlinux.64: vmlinux --change-addresses=0xa800000080000000 $< $@ endif -makeboot =$(Q)$(MAKE) -f scripts/Makefile.build obj=arch/mips/boot $(1) - ifdef CONFIG_SGI_IP27 all: vmlinux.64 endif @@ -697,10 +695,10 @@ all: vmlinux.ecoff endif vmlinux.ecoff vmlinux.rm200: vmlinux - +@$(call makeboot,$@) + $(Q)$(MAKE) $(build)=arch/mips/boot $@ vmlinux.srec: vmlinux - +@$(call makeboot,$@) + $(Q)$(MAKE) $(build)=arch/mips/boot $@ CLEAN_FILES += vmlinux.ecoff \ vmlinux.srec \ @@ -708,10 +706,10 @@ CLEAN_FILES += vmlinux.ecoff \ vmlinux.rm200 archclean: - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/boot - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/baget - @$(MAKE) -f scripts/Makefile.clean obj=arch/mips/lasat + $(Q)$(MAKE) $(clean)=arch/mips/boot + $(Q)$(MAKE) $(clean)=arch/mips/baget + $(Q)$(MAKE) $(clean)=arch/mips/lasat # Generate ; Mon, 17 May 2004 16:56:00 +0100 Received: from egate-co2.uswc.uswest.com (egate-co2.uswc.uswest.com [151.119.214.10]) by uswgco35.uswest.com (8/8) with ESMTP id i4HFtvfB009879 for ; Mon, 17 May 2004 09:55:58 -0600 (MDT) Received: from wopr.qwest.net (localhost [127.0.0.1]) by egate-co2.uswc.uswest.com (8.12.10/8.12.10) with ESMTP id i4HFtuOR025432 for ; Mon, 17 May 2004 09:55:56 -0600 (MDT) Received: from cyberMalex.com (igate.qwest.net [10.8.16.41]) by wopr.qwest.net (8.11.2/8.8.7) with ESMTP id i4HFttH22496 for ; Mon, 17 May 2004 11:55:56 -0400 Message-ID: <40A8E08B.7070203@cyberMalex.com> Date: Mon, 17 May 2004 11:55:55 -0400 From: Alexander Markley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: SGI O2 MIPS R5000 bootp problems Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5047 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alex@cyberMalex.com Precedence: bulk X-list: linux-mips Hi. I just get an SGI O2 with a MIPS R5000 chip in it, and I'd love to run linux on it. The machine seems to be in working order, and has been known to boot into IRIX in the recent past. I have gotten the debian tftp boot images and things, and have properly set up dhcp and tftp, but I cannot make this machine boot! ... > boot f bootp():r5000_boot.img Setting $netaddr to 192.168.1.235 (from server ) Obtaining r5000_boot.img from server 7536 Cannot load bootp():r5000_boot.img. Range check failure: text start 0x88802000, size 0x1d70. Text section would overwrite an already loaded program.Unable to execute bootp():r5000_boot.img: not enough space Unable to load bootp():r5000_boot.img: not enough space > ... I'm not sure why this doesn't work for me when it works for everyone else... Is it because my machine only has 64 MB of ram? Another strange bit is that this kernel does load and boot fine: http://www.linux-mips.org/~glaurung/O2/linux-2.6.1/kernel/vmlinux64 Of course, it can't finish booting since I didn't provide a root FS, but I wonder why the PROM doesn't want to jump to the debian image? I'll keep trying different things, and keep you guys posted. In the meantime, and input would be much appriciated. Also, I haven't joined the list, so CCing me would also be appriciated. ttyl --Alex From ladis@linux-mips.org Mon May 17 17:16:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 17:16:24 +0100 (BST) Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:59035 "HELO smtp.seznam.cz") by linux-mips.org with SMTP id ; Mon, 17 May 2004 17:16:23 +0100 Received: (qmail 1036 invoked from network); 17 May 2004 16:16:08 -0000 Received: from unknown (HELO umax645sx) (Ladislav.Michl@160.218.40.10) by smtp.seznam.cz with SMTP; 17 May 2004 16:16:08 -0000 Received: from ladis by umax645sx with local (Exim 3.36 #1 (Debian)) id 1BPkm6-0001Ue-00; Mon, 17 May 2004 18:15:34 +0200 Date: Mon, 17 May 2004 18:15:16 +0200 To: Alexander Markley Cc: linux-mips@linux-mips.org Subject: Re: SGI O2 MIPS R5000 bootp problems Message-ID: <20040517161515.GA5706@umax645sx> References: <40A8E08B.7070203@cyberMalex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A8E08B.7070203@cyberMalex.com> User-Agent: Mutt/1.5.6i From: Ladislav Michl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5048 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ladis@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 17, 2004 at 11:55:55AM -0400, Alexander Markley wrote: > Hi. I just get an SGI O2 with a MIPS R5000 chip in it, and I'd love to > run linux on it. The machine seems to be in working order, and has been > known to boot into IRIX in the recent past. > > I have gotten the debian tftp boot images and things, and have properly > set up dhcp and tftp, but I cannot make this machine boot! > > ... > > boot f bootp():r5000_boot.img > Setting $netaddr to 192.168.1.235 (from server ) > Obtaining r5000_boot.img from server > 7536 > Cannot load bootp():r5000_boot.img. > Range check failure: text start 0x88802000, size 0x1d70. ^^^^^^^^^^ What kernel version are you running? This bug was fixed quite long ago. I'd recommend using recent cvs and patch by Ilya http://www.total-knowledge.com/progs/mips/patches > Text section would overwrite an already loaded program.Unable to execute > bootp():r5000_boot.img: not enough space > Unable to load bootp():r5000_boot.img: not enough space [snip] ladis From ralf@linux-mips.org Mon May 17 17:37:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 17:37:30 +0100 (BST) Received: from p508B6C63.dip.t-dialin.net ([IPv6:::ffff:80.139.108.99]:37451 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 17:37:30 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4HGaexT032761; Mon, 17 May 2004 18:36:40 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4HGadPm032760; Mon, 17 May 2004 18:36:39 +0200 Date: Mon, 17 May 2004 18:36:39 +0200 From: Ralf Baechle To: Ladislav Michl Cc: Alexander Markley , linux-mips@linux-mips.org Subject: Re: SGI O2 MIPS R5000 bootp problems Message-ID: <20040517163639.GA32507@linux-mips.org> References: <40A8E08B.7070203@cyberMalex.com> <20040517161515.GA5706@umax645sx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040517161515.GA5706@umax645sx> User-Agent: Mutt/1.4.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: 5049 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 17, 2004 at 06:15:16PM +0200, Ladislav Michl wrote: > > 7536 > > Cannot load bootp():r5000_boot.img. > > Range check failure: text start 0x88802000, size 0x1d70. > ^^^^^^^^^^ > What kernel version are you running? This bug was fixed quite long ago. > I'd recommend using recent cvs and patch by Ilya > http://www.total-knowledge.com/progs/mips/patches Looks like an attempt to load an IP22 kernel into an IP32. Ralf From karsten@excalibur.cologne.de Mon May 17 19:09:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 19:09:57 +0100 (BST) Received: from natsmtp00.rzone.de ([IPv6:::ffff:81.169.145.165]:5335 "EHLO natsmtp00.rzone.de") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 19:09:56 +0100 Received: from excalibur.cologne.de (pD9E40BB3.dip.t-dialin.net [217.228.11.179]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i4HI9dMQ013804 for ; Mon, 17 May 2004 20:09:39 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian)) id 1BPmXg-0000Q0-00 for ; Mon, 17 May 2004 20:08:48 +0200 Date: Mon, 17 May 2004 20:08:48 +0200 From: Karsten Merker To: linux-mips@linux-mips.org Subject: Re: SGI O2 MIPS R5000 bootp problems Message-ID: <20040517180848.GA1551@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@linux-mips.org References: <40A8E08B.7070203@cyberMalex.com> <20040517161515.GA5706@umax645sx> <20040517163639.GA32507@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040517163639.GA32507@linux-mips.org> User-Agent: Mutt/1.3.28i X-No-Archive: yes Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips On Mon, May 17, 2004 at 06:36:39PM +0200, Ralf Baechle wrote: > On Mon, May 17, 2004 at 06:15:16PM +0200, Ladislav Michl wrote: > > > > 7536 > > > Cannot load bootp():r5000_boot.img. > > > Range check failure: text start 0x88802000, size 0x1d70. > > ^^^^^^^^^^ > > What kernel version are you running? This bug was fixed quite long ago. > > I'd recommend using recent cvs and patch by Ilya > > http://www.total-knowledge.com/progs/mips/patches > > Looks like an attempt to load an IP22 kernel into an IP32. Definitely - Debian does not yet provide IP32 images, only IP22. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From ilya@theilya.com Mon May 17 19:13:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 19:13:04 +0100 (BST) Received: from [IPv6:::ffff:66.151.148.199] ([IPv6:::ffff:66.151.148.199]:39686 "EHLO eagle.qarbon.com") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 19:13:04 +0100 Received: (qmail 24278 invoked from network); 17 May 2004 11:12:55 -0700 Received: from unknown (HELO theilya.com) (ilya@192.168.2.42) by 192.168.2.15 with AES256-SHA encrypted SMTP; 17 May 2004 11:12:55 -0700 Message-ID: <40A900A1.2070603@theilya.com> Date: Mon, 17 May 2004 11:12:49 -0700 From: "Ilya A. Volynets-Evenbakh" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040317 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: SGI O2 MIPS R5000 bootp problems References: <40A8E08B.7070203@cyberMalex.com> <20040517161515.GA5706@umax645sx> <20040517163639.GA32507@linux-mips.org> <20040517180848.GA1551@excalibur.cologne.de> In-Reply-To: <20040517180848.GA1551@excalibur.cologne.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5051 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@theilya.com Precedence: bulk X-list: linux-mips And that is why you should use Gentoo! Karsten Merker wrote: >On Mon, May 17, 2004 at 06:36:39PM +0200, Ralf Baechle wrote: > > >>On Mon, May 17, 2004 at 06:15:16PM +0200, Ladislav Michl wrote: >> >> >> >>>>7536 >>>>Cannot load bootp():r5000_boot.img. >>>>Range check failure: text start 0x88802000, size 0x1d70. >>>> >>>> >>> ^^^^^^^^^^ >>>What kernel version are you running? This bug was fixed quite long ago. >>>I'd recommend using recent cvs and patch by Ilya >>>http://www.total-knowledge.com/progs/mips/patches >>> >>> >>Looks like an attempt to load an IP22 kernel into an IP32. >> >> > >Definitely - Debian does not yet provide IP32 images, only IP22. > >Regards, >Karsten > > From mpl@broadcom.com Mon May 17 19:22:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 19:22:49 +0100 (BST) Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:57863 "EHLO mms1.broadcom.com") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 19:22:48 +0100 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 17 May 2004 11:20:40 -0700 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA14837; Mon, 17 May 2004 11:20:04 -0700 (PDT) Received: from broadcom.com ([10.21.2.22]) by mail-sj1-1.sj.broadcom.com (8.12.9/8.12.4/SSM) with ESMTP id i4HIKcLn005472; Mon, 17 May 2004 11: 20:38 -0700 (PDT) Message-ID: <40A901DD.80308@broadcom.com> Date: Mon, 17 May 2004 11:18:05 -0700 From: "Mitch Lichtenberg" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ken Giusti" cc: linux-mips@linux-mips.org Subject: Re: running 2.6 on swarm pass1 References: <20040517150631.13795.qmail@web13301.mail.yahoo.com> In-Reply-To: <20040517150631.13795.qmail@web13301.mail.yahoo.com> X-WSS-ID: 6CB7DDF21NG7203616-01-01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5052 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mpl@broadcom.com Precedence: bulk X-list: linux-mips Ken, Pass1 BCM1250's have enough problems that it's no surprise that things don't work anymore. Most of the workarounds to CPU core issues are deliberately not checked into the external (linux-mips) tree, and some require some nasty toolchain hacks (for example, taking exceptions on the instruction in a branch delay slot is perilous). I don't know how you got your SWARM, but you might want to press for getting a new one. No pass1's were ever shipped in volume, so it would be best to NOT support it. /Mitch. Ken Giusti wrote: > Hi, > > I've got a swarm board with a pass1 sibyte sb1250. > Here's the relevant system info from the boot up > console: > <> From alex@cyberMalex.com Mon May 17 23:34:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 17 May 2004 23:34:11 +0100 (BST) Received: from uswgne22.uswest.com ([IPv6:::ffff:204.26.87.76]:31619 "EHLO uswgne22.uswest.com") by linux-mips.org with ESMTP id ; Mon, 17 May 2004 23:34:10 +0100 Received: from egate-ne7.uswc.uswest.com (egate-ne7.uswc.uswest.com [151.117.69.18]) by uswgne22.uswest.com (8/8) with ESMTP id i4HMY43w008532 for ; Mon, 17 May 2004 17:34:05 -0500 (CDT) Received: from wopr.qwest.net (localhost [127.0.0.1]) by egate-ne7.uswc.uswest.com (8.12.10/8.12.10) with ESMTP id i4HMY4Tx027721 for ; Mon, 17 May 2004 17:34:04 -0500 (CDT) Received: from cyberMalex.com (igate.qwest.net [10.8.16.41]) by wopr.qwest.net (8.11.2/8.8.7) with ESMTP id i4HMY2H29732 for ; Mon, 17 May 2004 18:34:03 -0400 Message-ID: <40A93DD8.6030205@cyberMalex.com> Date: Mon, 17 May 2004 18:34:00 -0400 From: Alexander Markley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: SGI O2 MIPS R5000 bootp problems References: <40A8E08B.7070203@cyberMalex.com> <20040517161515.GA5706@umax645sx> <20040517163639.GA32507@linux-mips.org> In-Reply-To: <20040517163639.GA32507@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5053 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alex@cyberMalex.com Precedence: bulk X-list: linux-mips > Looks like an attempt to load an IP22 kernel into an IP32. Yeah, that's probably it... I've learned a lot since I started this thread, and I'm not having any real trouble netbooting now. Thanks all. ttyl --Alex Ralf Baechle wrote: > On Mon, May 17, 2004 at 06:15:16PM +0200, Ladislav Michl wrote: > > >>>7536 >>>Cannot load bootp():r5000_boot.img. >>>Range check failure: text start 0x88802000, size 0x1d70. >> >> ^^^^^^^^^^ >>What kernel version are you running? This bug was fixed quite long ago. >>I'd recommend using recent cvs and patch by Ilya >>http://www.total-knowledge.com/progs/mips/patches > > > Looks like an attempt to load an IP22 kernel into an IP32. > > Ralf From ratin@koperasw.com Tue May 18 01:01:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 01:01:17 +0100 (BST) Received: from host73.ipowerweb.com ([IPv6:::ffff:12.129.211.254]:30772 "EHLO host73.ipowerweb.com") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 01:01:16 +0100 Received: from c-67-170-233-233.client.comcast.net ([67.170.233.233] helo=ratwin1) by host73.ipowerweb.com with asmtp (Exim 3.36 #1) id 1BPs1i-0007NM-00 for linux-mips@linux-mips.org; Mon, 17 May 2004 17:00:10 -0700 Reply-To: From: "Ratin Kumar" To: Subject: setup X11 on MIPS64/MALTA Date: Mon, 17 May 2004 17:00:53 -0700 Organization: Kopera Software Inc. Message-ID: <005401c43c6b$35b750f0$6901a8c0@ratwin1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C43C30.895878F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host73.ipowerweb.com X-AntiAbuse: Original Domain - linux-mips.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - koperasw.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: 5054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ratin@koperasw.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C43C30.895878F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I am trying to get X11 up on my MALTA (MIPS 64, little endian board). I = have the frame buffer working (using Matrox Mill - II PCI card). I also have = the Red Hat 7.3 installation going but I am not able to get X to work. Has = any one tried this combination OR if there is any advice on this ?? =20 Thanks in advance. =20 -Ratin. ------=_NextPart_000_0055_01C43C30.895878F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am trying to get X11 up on my MALTA (MIPS 64, little endian board). I have the frame buffer working (using Matrox Mill = – II PCI card). I also have the Red Hat 7.3 installation going but I am = not able to get X to work. Has any one tried this combination OR if there is any = advice on this ??

 

Thanks in advance.

 

-Ratin.

------=_NextPart_000_0055_01C43C30.895878F0-- From ralf@linux-mips.org Tue May 18 01:16:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 01:16:40 +0100 (BST) Received: from p508B6C63.dip.t-dialin.net ([IPv6:::ffff:80.139.108.99]:18256 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 01:16:39 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4I0GcxT011227; Tue, 18 May 2004 02:16:38 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4I0GcH8011226; Tue, 18 May 2004 02:16:38 +0200 Date: Tue, 18 May 2004 02:16:38 +0200 From: Ralf Baechle To: Ken Giusti Cc: linux-mips@linux-mips.org Subject: Re: running 2.6 on swarm pass1 Message-ID: <20040518001638.GA10423@linux-mips.org> References: <20040517150631.13795.qmail@web13301.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040517150631.13795.qmail@web13301.mail.yahoo.com> User-Agent: Mutt/1.4.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: 5055 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, May 17, 2004 at 08:06:31AM -0700, Ken Giusti wrote: > 2.6.6 from kernel.org doesn't appear to run at all. > Once I load the image via CFE and type "go" I get > absolutely no console output - the system just hangs. There is still plenty of code that needs to be merged into the kernel.org tree before this will have a chance of working. For any MIPS system. > 2.6.5 from linux-mips is a bit better - I get bootup > console output, then an immediate crash (included > below). > > Has anyone had any luck getting 2.6 running on swarm > with pass1? I still do have a pass1 board he so I'll eventually look at it. However this doesn't look like the fingerprint of the usual pass1 crashes so it's probably simply a genuine kernel bug. Ralf From stuartl@longlandclan.hopto.org Tue May 18 04:13:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 04:13:17 +0100 (BST) Received: from 202-47-55-78.adsl.gil.com.au ([IPv6:::ffff:202.47.55.78]:8576 "EHLO longlandclan.hopto.org") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 04:13:16 +0100 Received: (qmail 9193 invoked by uid 204); 18 May 2004 13:13:05 +1000 Received: from stuartl@longlandclan.hopto.org by www by uid 201 with qmail-scanner-1.16 (spamassassin: 2.63. Clear:. Processed in 0.034629 secs); 18 May 2004 03:13:05 -0000 Received: from unknown (HELO longlandclan.hopto.org) (10.0.0.251) by 192.168.5.1 with SMTP; 18 May 2004 13:13:05 +1000 Message-ID: <40A97F41.3030605@longlandclan.hopto.org> Date: Tue, 18 May 2004 13:13:05 +1000 From: Stuart Longland User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ratin@koperasw.com CC: linux-mips@linux-mips.org Subject: Re: setup X11 on MIPS64/MALTA References: <005401c43c6b$35b750f0$6901a8c0@ratwin1> In-Reply-To: <005401c43c6b$35b750f0$6901a8c0@ratwin1> Content-Type: text/plain; charset=windows-1252; format=flowed 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: 5056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stuartl@longlandclan.hopto.org Precedence: bulk X-list: linux-mips Ratin Kumar wrote: > I am trying to get X11 up on my MALTA (MIPS 64, little endian board). I > have the frame buffer working (using Matrox Mill – II PCI card). I also > have the Red Hat 7.3 installation going but I am not able to get X to > work. Has any one tried this combination OR if there is any advice on > this ?? How have you tried configuring XFree86? Did you use the matrox driver or fbdev? If the framebuffer works, then I'd suggest trying fbdev. Beyond that, I wouldn't have a clue. -- +-------------------------------------------------------------+ | Stuart Longland stuartl at longlandclan.hopto.org | | Brisbane Mesh Node: 719 http://stuartl.cjb.net/ | | I haven't lost my mind - it's backed up on a tape somewhere | | Atomic Linux Project <---> http://atomicl.berlios.de/ | +-------------------------------------------------------------+ From kevink@mips.com Tue May 18 07:36:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 07:36:24 +0100 (BST) Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:60815 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 07:36:23 +0100 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.11/8.12.11) with ESMTP id i4I6OeVh009562; Mon, 17 May 2004 23:24:41 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i4I6a6Md024372; Mon, 17 May 2004 23:36:07 -0700 (PDT) Message-ID: <008c01c43ca2$d09264c0$10eca8c0@grendel> From: "Kevin D. Kissell" To: , References: <005401c43c6b$35b750f0$6901a8c0@ratwin1> Subject: Re: setup X11 on MIPS64/MALTA Date: Tue, 18 May 2004 08:39:03 +0200 Organization: MIPS Technologies Inc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01C43CB3.92C65320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5057 X-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 This is a multi-part message in MIME format. ------=_NextPart_000_0089_01C43CB3.92C65320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I managed to make X11 work on a 5Kc/Malta configuration by overlaying = part of the MIPS port of RH 7.1 with the "zhang tarball" = (ftp://ftp.paralogos.com/pub/linux/mips/tarballs/X11R6.mipsel.tar.gz )=20 and overlaying part of the linux-mips.org source tree with Matrox fixes = from kernel.org. Earl Mitchell of MIPS went through this exercise last year and came up = with a revised procdeure which I've bundled into a 33MB tarball and put up at=20 ftp://ftp.paralogos.com/pub/linux/mips/tarballs/earlm_xfree86_malta.tgz=20 I haven't actually used it yet, but it contains a revised X11 subtree, = sample configuration files, and a README. ----- Original Message -----=20 From: Ratin Kumar=20 To: linux-mips@linux-mips.org=20 Sent: Tuesday, May 18, 2004 2:00 Subject: setup X11 on MIPS64/MALTA Hi, I am trying to get X11 up on my MALTA (MIPS 64, little endian board). = I have the frame buffer working (using Matrox Mill - II PCI card). I = also have the Red Hat 7.3 installation going but I am not able to get X = to work. Has any one tried this combination OR if there is any advice on = this ?? Thanks in advance. -Ratin. ------=_NextPart_000_0089_01C43CB3.92C65320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I managed to make X11 work on a = 5Kc/Malta=20 configuration by overlaying part of the MIPS port
of RH 7.1 with the "zhang tarball" (ftp://ftp.paralogos.com/pub/linux/mips/tarballs/X11R6.mipsel.tar.gz )
and overlaying part of the = linux-mips.org source=20 tree with Matrox fixes from=20 kernel.org.
 
Earl Mitchell of MIPS went through this = exercise=20 last year and came up with a revised procdeure
which I've bundled into a 33MB tarball = and put up=20 at
ftp://ftp.paralogos.com/pub/linux/mips/tarballs/earlm_xfree86_mal= ta.tgz=20
I haven't actually used it yet, but it = contains a=20 revised X11 subtree, sample configuration files, and
a README.
----- Original Message -----
From:=20 Ratin = Kumar=20
Sent: Tuesday, May 18, 2004 = 2:00
Subject: setup X11 on = MIPS64/MALTA

Hi,

 

I am trying to get X11 = up on my=20 MALTA (MIPS 64,=20 little endian board). I have the frame buffer working (using Matrox = Mill =96 II=20 PCI card). I also have the Red Hat 7.3 installation going but I am not = able to=20 get X to work. Has any one tried this combination OR if there is any = advice on=20 this ??

 

Thanks in=20 advance.

 

-Ratin.

------=_NextPart_000_0089_01C43CB3.92C65320-- From pdh@colonel-panic.org Tue May 18 08:34:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 08:34:54 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:7296 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 08:34:53 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BPz7X-0001mF-00; Tue, 18 May 2004 08:34:39 +0100 Date: Tue, 18 May 2004 08:34:39 +0100 To: Kieran Fulke Cc: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518073439.GA6818@skeleton-jack> References: <20040513183059.GA25743@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040513183059.GA25743@getyour.pawsoff.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5058 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips On Thu, May 13, 2004 at 07:30:59PM +0100, Kieran Fulke wrote: > > getting the below when loading the dvb budget_ci module. it disables IRQ > #23 which is attached to the card, rendering it useless. i asked the > same question over there and none of them suspect it to be a DVB > problem. some esoteric pci bug perhaps? > Not quite so esoteric :-) Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in include/asm/cobalt/cobalt.h. P. From sam@ravnborg.org Tue May 18 16:17:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 16:17:48 +0100 (BST) Received: from pfepb.post.tele.dk ([IPv6:::ffff:195.41.46.236]:56932 "EHLO pfepb.post.tele.dk") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 16:17:47 +0100 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pfepb.post.tele.dk (Postfix) with ESMTP id C26B15EE096; Tue, 18 May 2004 17:17:39 +0200 (CEST) Received: by mars.ravnborg.org (Postfix, from userid 500) id D6A5FDF4A8; Tue, 18 May 2004 17:28:34 +0200 (CEST) Date: Tue, 18 May 2004 17:28:34 +0200 From: Sam Ravnborg To: Mathieu Chouquet-Stringer , linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com, mikael.starvik@axis.com, sam@ravnborg.org Subject: Re: [PATCH] Fix for 2.6.6 Makefiles to get KBUILD_OUTPUT working Message-ID: <20040518152834.GA2635@mars.ravnborg.org> Mail-Followup-To: Mathieu Chouquet-Stringer , linux-kernel@vger.kernel.org, rth@twiddle.net, linux-alpha@vger.kernel.org, ralf@gnu.org, linux-mips@linux-mips.org, akpm@osdl.org, bjornw@axis.com, dev-etrax@axis.com, mikael.starvik@axis.com, sam@ravnborg.org References: <20040516012245.GA11733@localhost> <20040516203322.GA4784@mars.ravnborg.org> <20040517152311.GA29999@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040517152311.GA29999@localhost> User-Agent: Mutt/1.4.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: 5059 X-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 > > Hereby the '+' sign is no longer needed (used today where makeboot is used. > > Ok, I applied the changes you requested, please check the diff for mips as > I had to modify some other lines too. Looks goood, but the cris part is missing? Please pass on current patch to Andrew with a nice changelog entry. The cris part we can take later if Mikael does not surface. Sam From r.zilli@ingredium.it Tue May 18 16:42:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 16:42:44 +0100 (BST) Received: from host195-84.pool217141.interbusiness.it ([IPv6:::ffff:217.141.84.195]:59148 "EHLO pop.ingredium.it") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 16:42:42 +0100 Received: (qmail 40383 invoked by uid 1002); 18 May 2004 15:42:40 -0000 Received: from r.zilli@ingredium.it by ingredium.it by uid 89 with qmail-scanner-1.21 (clamscan: 0.70. spamassassin: 2.63. Clear:RC:1(82.48.123.17):. Processed in 2.341815 secs); 18 May 2004 15:42:40 -0000 Received: from unknown (HELO ingredium.it) (r.zilli@ingredium.it@82.48.123.17) by host195-84.pool217141.interbusiness.it with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 May 2004 15:42:37 -0000 Message-ID: <40AA2EE6.1030509@ingredium.it> Date: Tue, 18 May 2004 17:42:30 +0200 From: Roberto Zilli User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.4.1) Gecko/20031114 X-Accept-Language: it, en, en-us MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: epson1356fb.c Video driver obsolete Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5060 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: r.zilli@ingredium.it Precedence: bulk X-list: linux-mips Hi guys, the epson1356fb.c on 2.6.6 is broken, it don't work! Any clues? From ppopov@mvista.com Tue May 18 17:57:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 17:57:13 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:34044 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 17:57:10 +0100 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA22287; Tue, 18 May 2004 09:56:57 -0700 Subject: Re: epson1356fb.c Video driver obsolete From: Pete Popov To: Roberto Zilli Cc: Linux MIPS mailing list In-Reply-To: <40AA2EE6.1030509@ingredium.it> References: <40AA2EE6.1030509@ingredium.it> Content-Type: text/plain Organization: MontaVista Software Message-Id: <1084899487.29782.10.camel@zeus.mvista.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 18 May 2004 09:58:07 -0700 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: 5061 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ppopov@mvista.com Precedence: bulk X-list: linux-mips On Tue, 2004-05-18 at 08:42, Roberto Zilli wrote: > Hi guys, > > the epson1356fb.c on 2.6.6 is broken, it don't work! Which board did you test it on? ... not that it makes much of a difference in this case. > Any clues? Yes. The 2.6 FB API is different from the 2.4 API. I don't know how many FB drivers have been updated to the 2.6 API, but I do know that the epson1356fb driver is not one of the updated ones. I don't have plans for updating that driver myself, unless there's a compelling reason to do so, or someone else updates it. Pete From manwithastinkydog@yahoo.com Tue May 18 17:57:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 17:57:38 +0100 (BST) Received: from web13305.mail.yahoo.com ([IPv6:::ffff:216.136.175.41]:63503 "HELO web13305.mail.yahoo.com") by linux-mips.org with SMTP id ; Tue, 18 May 2004 17:57:26 +0100 Message-ID: <20040518165723.31435.qmail@web13305.mail.yahoo.com> Received: from [12.33.232.234] by web13305.mail.yahoo.com via HTTP; Tue, 18 May 2004 09:57:23 PDT Date: Tue, 18 May 2004 09:57:23 -0700 (PDT) From: Ken Giusti Subject: Re: running 2.6 on swarm pass1 To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20040518001638.GA10423@linux-mips.org> 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: 5062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: manwithastinkydog@yahoo.com Precedence: bulk X-list: linux-mips Thanks for the info. I'll try to free up some time to dig into that crash, if possible. My debug skills are nothing to brag about.... -K --- Ralf Baechle wrote: > On Mon, May 17, 2004 at 08:06:31AM -0700, Ken Giusti > wrote: > > > 2.6.6 from kernel.org doesn't appear to run at > all. > > Once I load the image via CFE and type "go" I get > > absolutely no console output - the system just > hangs. > > There is still plenty of code that needs to be > merged into the kernel.org > tree before this will have a chance of working. For > any MIPS system. > > > 2.6.5 from linux-mips is a bit better - I get > bootup > > console output, then an immediate crash (included > > below). > > > > Has anyone had any luck getting 2.6 running on > swarm > > with pass1? > > I still do have a pass1 board he so I'll eventually > look at it. However > this doesn't look like the fingerprint of the usual > pass1 crashes so it's > probably simply a genuine kernel bug. > > Ralf __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ From kieran@pawsoff.org Tue May 18 18:39:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 18:39:20 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:7434 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 18:39:19 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id B948E38212C; Tue, 18 May 2004 18:39:16 +0100 (BST) Date: Tue, 18 May 2004 18:39:16 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518173916.GA29006@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20040518073439.GA6818@skeleton-jack> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 08:34:39AM +0100, Peter Horton wrote: >=20 > Not quite so esoteric :-) >=20 > Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in > include/asm/cobalt/cobalt.h. >=20 that looks embarrassingly simple. building a new kernel now. if only=20 these things were a bit zippier ... Kieran. --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqkpEOWPbH1PXZ18RAmxxAJ9I6YT2p0mNRW5KAuvy+iDQAKU1VACfTskr 12C2w857ak6+lDM6Nq6k3D8= =h7S1 -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From bbreuer@righthandtech.com Tue May 18 19:17:41 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 19:17:43 +0100 (BST) Received: from ux1.dataflo.net ([IPv6:::ffff:207.252.248.16]:9745 "EHLO ux1.dataflo.net") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 19:17:41 +0100 Received: from server1.RightHand.righthandtech.com ([207.252.250.187]) by ux1.dataflo.net (8.12.11/8.12.11) with ESMTP id i4IIHcAk042243 for ; Tue, 18 May 2004 13:17:39 -0500 (CDT) content-class: urn:content-classes:message Subject: RE: problems on D-cache alias in 2.4.22 Date: Tue, 18 May 2004 13:17:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C43D04.66A62BCA" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIMEOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: problems on D-cache alias in 2.4.22 Thread-Index: AcQ9BGaYIz1eHbaQSIaIN7eaTSarbA== From: "Bob Breuer" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: bbreuer@righthandtech.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C43D04.66A62BCA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Peter Horton > Sent: Friday, May 14, 2004 2:53 AM > To: wuming > Cc: linux-mips@linux-mips.org > Subject: Re: problems on D-cache alias in 2.4.22 >=20 >=20 > wuming wrote: >=20 ... > > at last, when I replaced flush_page_to_ram( ) with=20 > flush_dcache_page( ), > > the internal compiler error disappeared. > > ... >=20 > This is probably just hiding your problem. flush_page_to_ram() is not=20 > used anymore. >=20 > P. >=20 >=20 Changing that same place also fixes my problem. However, I came across the mips cobalt patches and after applying a variation of the IDE cache fix from there, that also fixes the problem. So it would seem that this is the same problem as already fixed in the cobalt patch, but showing up on non-cobalt hardware. flush_page_to_ram() was made useless around the release of 2.4.21. I suspect that this was broken at that time, seeing how it is broken in 2.4.22 and 2.4.26. From browsing the debian-mips mailing list archives, it appears that they have not had a stable mips kernel since 2.4.19, could this bug be the cause? Are the recent Debian mips kernels still unstable? Would anyone with an unstable 2.4.2x kernel be willing to try one of the attached patches to see if the situation improves? Bob ------_=_NextPart_001_01C43D04.66A62BCA Content-Type: application/octet-stream; name="cache_alias_fix1.diff" Content-Transfer-Encoding: base64 Content-Description: cache_alias_fix1.diff Content-Disposition: attachment; filename="cache_alias_fix1.diff" SW5kZXg6IG1tL2ZpbGVtYXAuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9jdnMvbGludXgv bW0vZmlsZW1hcC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjc0LjIuMTQKZGlmZiAtdSAtcjEu NzQuMi4xNCBmaWxlbWFwLmMKLS0tIG1tL2ZpbGVtYXAuYwkyMCBGZWIgMjAwNCAwMToyMjoyMSAt MDAwMAkxLjc0LjIuMTQKKysrIG1tL2ZpbGVtYXAuYwkxOCBNYXkgMjAwNCAxNzoxODoyNiAtMDAw MApAQCAtMjExMSw3ICsyMTExLDcgQEAKIAkgKiBhbmQgcG9zc2libHkgY29weSBpdCBvdmVyIHRv IGFub3RoZXIgcGFnZS4uCiAJICovCiAJbWFya19wYWdlX2FjY2Vzc2VkKHBhZ2UpOwotCWZsdXNo X3BhZ2VfdG9fcmFtKHBhZ2UpOworCWZsdXNoX2RjYWNoZV9wYWdlKHBhZ2UpOwogCXJldHVybiBw YWdlOwogCiBub19jYWNoZWRfcGFnZToK ------_=_NextPart_001_01C43D04.66A62BCA Content-Type: application/octet-stream; name="cache_alias_fix2.diff" Content-Transfer-Encoding: base64 Content-Description: cache_alias_fix2.diff Content-Disposition: attachment; filename="cache_alias_fix2.diff" SW5kZXg6IGluY2x1ZGUvYXNtLW1pcHMvaWRlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUv Y3ZzL2xpbnV4L2luY2x1ZGUvYXNtLW1pcHMvaWRlLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEu MTEuMi43CmRpZmYgLXUgLXIxLjExLjIuNyBpZGUuaAotLS0gaW5jbHVkZS9hc20tbWlwcy9pZGUu aAkxNSBKdWwgMjAwMyAxNTowODozMyAtMDAwMAkxLjExLjIuNworKysgaW5jbHVkZS9hc20tbWlw cy9pZGUuaAkxOCBNYXkgMjAwNCAxNzo1Nzo0NCAtMDAwMApAQCAtNjksNiArNjksNDkgQEAKICNl bmRpZgogCiAjaW5jbHVkZSA8YXNtLWdlbmVyaWMvaWRlX2lvcHMuaD4KKyNpbmNsdWRlIDxhc20v cjRrY2FjaGUuaD4KKworc3RhdGljIGlubGluZSB2b2lkIF9fZmx1c2hfZGNhY2hlX3JhbmdlKHVu c2lnbmVkIGxvbmcgc3RhcnQsIHVuc2lnbmVkIGxvbmcgZW5kKQoreworCXVuc2lnbmVkIGxvbmcg ZGNfc2l6ZSwgZGNfbGluZSwgYWRkcjsKKworCWRjX3NpemUgPSBjdXJyZW50X2NwdV9kYXRhLmRj YWNoZS53YXlzaXplOworCWRjX2xpbmUgPSBjdXJyZW50X2NwdV9kYXRhLmRjYWNoZS5saW5lc3o7 CisKKwlhZGRyID0gc3RhcnQgJiB+KGRjX2xpbmUgLSAxKTsKKwllbmQgKz0gZGNfbGluZSAtIDE7 CisKKwlpZiAoZW5kIC0gYWRkciA8IGRjX3NpemUpCisJCWZvciAoOyBhZGRyIDwgZW5kOyBhZGRy ICs9IGRjX2xpbmUpCisJCQlmbHVzaF9kY2FjaGVfbGluZShhZGRyKTsKKwllbHNlIHsKKwkJLyog Zmx1c2ggYWxsIG9mIGRjYWNoZSAqLworCQlhZGRyID0gS1NFRzA7CisJCWVuZCA9IGFkZHIgKyBk Y19zaXplOworCQlmb3IgKDsgYWRkciA8IGVuZDsgYWRkciArPSBkY19saW5lKQorCQkJZmx1c2hf ZGNhY2hlX2xpbmVfaW5kZXhlZChhZGRyKTsKKwl9Cit9CisKKyN1bmRlZiBpbnN3CisjdW5kZWYg aW5zbAorI3VuZGVmIF9faWRlX2luc3cKKyN1bmRlZiBfX2lkZV9pbnNsCisKK3N0YXRpYyBpbmxp bmUgdm9pZCBfX2lkZV9pbnN3KHVuc2lnbmVkIGxvbmcgcG9ydCwgdm9pZCAqYWRkciwgdTMyIGNv dW50KQoreworCV9faW5zdyhwb3J0LCBhZGRyLCBjb3VudCk7CisJX19mbHVzaF9kY2FjaGVfcmFu Z2UoKHVuc2lnbmVkIGxvbmcpYWRkciwgKHVuc2lnbmVkIGxvbmcpYWRkciArIGNvdW50KjIpOwor fQorCitzdGF0aWMgaW5saW5lIHZvaWQgX19pZGVfaW5zbCh1bnNpZ25lZCBsb25nIHBvcnQsIHZv aWQgKmFkZHIsIHUzMiBjb3VudCkKK3sKKwlfX2luc2wocG9ydCwgYWRkciwgY291bnQpOworCV9f Zmx1c2hfZGNhY2hlX3JhbmdlKCh1bnNpZ25lZCBsb25nKWFkZHIsICh1bnNpZ25lZCBsb25nKWFk ZHIgKyBjb3VudCo0KTsKK30KKworI2RlZmluZSBpbnN3KHBvcnQsIGFkZHIsIGNvdW50KSBfX2lk ZV9pbnN3KHBvcnQsIGFkZHIsIGNvdW50KQorI2RlZmluZSBpbnNsKHBvcnQsIGFkZHIsIGNvdW50 KSBfX2lkZV9pbnNsKHBvcnQsIGFkZHIsIGNvdW50KQogCiAjZW5kaWYgLyogX19LRVJORUxfXyAq LwogCg== ------_=_NextPart_001_01C43D04.66A62BCA-- From jsun@orion.mvista.com Tue May 18 19:45:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 19:45:22 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56312 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 19:45:21 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i4IIjJx6013363; Tue, 18 May 2004 11:45:19 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i4IIjJTW013361; Tue, 18 May 2004 11:45:19 -0700 Date: Tue, 18 May 2004 11:45:19 -0700 From: Jun Sun To: Bob Breuer Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518114519.C5390@mvista.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bbreuer@righthandtech.com on Tue, May 18, 2004 at 01:17:38PM -0500 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5065 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Tue, May 18, 2004 at 01:17:38PM -0500, Bob Breuer wrote: > > > -----Original Message----- > > From: linux-mips-bounce@linux-mips.org > > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Peter Horton > > Sent: Friday, May 14, 2004 2:53 AM > > To: wuming > > Cc: linux-mips@linux-mips.org > > Subject: Re: problems on D-cache alias in 2.4.22 > > > > > > wuming wrote: > > > ... > > > at last, when I replaced flush_page_to_ram( ) with > > flush_dcache_page( ), > > > the internal compiler error disappeared. > > > > ... > > > > This is probably just hiding your problem. flush_page_to_ram() is not > > used anymore. > > > > P. > > > > > > Changing that same place also fixes my problem. Like others suggested, this is not the right fix. flush_page_to_ram() is correctly nullified. Its job should be done somewhere else by other routines. Here are a couple of random ideas for finding the true root cause: . If a page is shared by multiple user processes, make sure either the CPU does not have d-cache alaising problem (i.e., cache way size is 4KB or less) or their virtual addresses lie on the "same color strip" of the d-cache. In other words, they would be cached in the same cache way. . If a page is modified by kernel and accessed by user land, make sure a flush_dcache_page() is called right after the modifying. . If a page is modified by userland and accessed by kernel, I _think_ currently kernel would still do a flush_dcache_page() call. However, this won't work on MIPS because the cache at user virtual addresses are not flushed. Either try to flush with user virtual address, or do a flush_cache_all(). *ick* BTW, I _think_ the last problem stilled exists in 2.6. We probably need to use the reverse maping info to fix it. Jun From pdh@colonel-panic.org Tue May 18 20:10:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 20:10:56 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:25216 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 20:10:55 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BQ9yl-0002tZ-00; Tue, 18 May 2004 20:10:19 +0100 Date: Tue, 18 May 2004 20:10:19 +0100 To: Jun Sun Cc: Bob Breuer , linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518191019.GA11007@skeleton-jack> References: <20040518114519.C5390@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518114519.C5390@mvista.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips On Tue, May 18, 2004 at 11:45:19AM -0700, Jun Sun wrote: > > Like others suggested, this is not the right fix. flush_page_to_ram() > is correctly nullified. Its job should be done somewhere else > by other routines. > > Here are a couple of random ideas for finding the true root cause: > We know what the true root cause is :-) IDE PIO fills the D-cache with the read data (write allocate) as it copies it to the page cache. The kernel maps the page cache page into user space ... BANG! possible D-cache alias. The kernel doesn't bother flushing the page cache page from the D-cache as it's never accessed at it's page cache address. The current fix in the Cobalt patches (2.4 & 2.6) just flushes the read data out of the D-cache after every IDE insw()/insl(). This is the least intrusive fix. Some Sparc machines also see this problem. P. From ralf@linux-mips.org Tue May 18 20:51:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 20:51:09 +0100 (BST) Received: from p508B6E75.dip.t-dialin.net ([IPv6:::ffff:80.139.110.117]:57178 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 20:51:08 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4IJovxT005499; Tue, 18 May 2004 21:50:57 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4IJotiO005498; Tue, 18 May 2004 21:50:55 +0200 Date: Tue, 18 May 2004 21:50:55 +0200 From: Ralf Baechle To: Peter Horton Cc: Jun Sun , Bob Breuer , linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518195055.GB2454@linux-mips.org> References: <20040518114519.C5390@mvista.com> <20040518191019.GA11007@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518191019.GA11007@skeleton-jack> User-Agent: Mutt/1.4.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: 5067 X-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, May 18, 2004 at 08:10:19PM +0100, Peter Horton wrote: > The kernel maps the page cache page into user space ... BANG! possible > D-cache alias. > > The kernel doesn't bother flushing the page cache page from the D-cache > as it's never accessed at it's page cache address. It is - after all the driver is copying the data to there. The same problem also exists in the ramdisk driver and there it has been fixed properly, it seems. > The current fix in the Cobalt patches (2.4 & 2.6) just flushes the read > data out of the D-cache after every IDE insw()/insl(). This is the least > intrusive fix. > > Some Sparc machines also see this problem. Carelessly written PIO drivers on any architecture would suffer from this kind of problem. Ralf From ralf@linux-mips.org Tue May 18 21:02:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 21:02:07 +0100 (BST) Received: from p508B6E75.dip.t-dialin.net ([IPv6:::ffff:80.139.110.117]:2139 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 21:02:06 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i4IK25xT005778; Tue, 18 May 2004 22:02:05 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i4IK25IV005777; Tue, 18 May 2004 22:02:05 +0200 Date: Tue, 18 May 2004 22:02:05 +0200 From: Ralf Baechle To: Bob Breuer Cc: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518200205.GC2454@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.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: 5068 X-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, May 18, 2004 at 01:17:38PM -0500, Bob Breuer wrote: > Changing that same place also fixes my problem. However, I came across > the mips cobalt patches and after applying a variation of the IDE cache > fix from there, that also fixes the problem. So it would seem that this > is the same problem as already fixed in the cobalt patch, but showing up > on non-cobalt hardware. > > flush_page_to_ram() was made useless around the release of 2.4.21. I > suspect that this was broken at that time, seeing how it is broken in > 2.4.22 and 2.4.26. From browsing the debian-mips mailing list archives, > it appears that they have not had a stable mips kernel since 2.4.19, > could this bug be the cause? Are the recent Debian mips kernels still > unstable? > > Would anyone with an unstable 2.4.2x kernel be willing to try one of the > attached patches to see if the situation improves? flush_page_to_ram has been deprecated since a long, long time and so it's use in memory managment was no longer correct for all cases - MIPS was basically the last major Linux architecture left using it. Replacing it with flush_dcache_page fixed those correctness problem and delivered a major speedup. So no sense in whining - flush_page_to_ram won't return. Ralf From ica2_ts@csv.ica.uni-stuttgart.de Tue May 18 21:10:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 21:10:25 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:43546 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 21:10:20 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BQAug-0003Hw-00 for ; Tue, 18 May 2004 22:10:10 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BQAug-0005rT-00 for ; Tue, 18 May 2004 22:10:10 +0200 Date: Tue, 18 May 2004 22:10:10 +0200 To: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518201010.GD31535@rembrandt.csv.ica.uni-stuttgart.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5070 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Content-Length: 416 Lines: 13 Bob Breuer wrote: [snip] > From browsing the debian-mips mailing list archives, > it appears that they have not had a stable mips kernel since 2.4.19, > could this bug be the cause? Are the recent Debian mips kernels still > unstable? The latest 2.4.25/2.4.26 (Debian-)Kernels seem to work well on all Debian-supported machines. They include some cobalt patch which isn't in the linux-mips.org CVS (yet). Thiemo From kieran@pawsoff.org Tue May 18 21:59:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 21:59:18 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:40458 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 21:59:17 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 57B6038212C; Tue, 18 May 2004 21:59:14 +0100 (BST) Date: Tue, 18 May 2004 21:59:14 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518205914.GA29574@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <20040518073439.GA6818@skeleton-jack> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5071 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips Content-Length: 1232 Lines: 47 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 08:34:39AM +0100, Peter Horton wrote: >=20 > Not quite so esoteric :-) >=20 > Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in > include/asm/cobalt/cobalt.h. >=20 alas, no joy. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with=20 idebus=3Dxx VP_IDE: IDE controller at PCI slot 0000:00:09.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1 ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio spurious 8259A interrupt: IRQ9. cheers, Kieran. --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqnkiOWPbH1PXZ18RAoOiAKCKMQaoYtsw65TbrOWg5x4j6c0+rgCfW0SQ 828gi0rXy2rXtnz1QLQMqg4= =m4za -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From kieran@pawsoff.org Tue May 18 22:09:53 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 22:09:54 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:43274 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 22:09:53 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 9E8E638212C; Tue, 18 May 2004 22:09:52 +0100 (BST) Date: Tue, 18 May 2004 22:09:52 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518210952.GA29618@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20040518205914.GA29574@getyour.pawsoff.org> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips Content-Length: 1176 Lines: 40 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 09:59:14PM +0100, Kieran Fulke wrote: >=20 > >=20 > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with=20 > idebus=3Dxx > VP_IDE: IDE controller at PCI slot 0000:00:09.1 > VP_IDE: chipset revision 6 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1 > ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio > spurious 8259A interrupt: IRQ9. >=20 i should also mention that the boot process stops at this point. --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqnugOWPbH1PXZ18RAs0nAJ9QSID6I7pWIW9alG2X+y8BV5ZQoQCeKvVt y0kM5ubcju1YZBRwRrgMibg= =mKvX -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From pdh@colonel-panic.org Tue May 18 22:12:59 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 22:13:00 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:46464 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 22:12:59 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BQBtG-00033R-00; Tue, 18 May 2004 22:12:46 +0100 Date: Tue, 18 May 2004 22:12:46 +0100 To: Kieran Fulke Cc: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518211246.GA11722@skeleton-jack> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518205914.GA29574@getyour.pawsoff.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5073 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Content-Length: 884 Lines: 31 On Tue, May 18, 2004 at 09:59:14PM +0100, Kieran Fulke wrote: > On Tue, May 18, 2004 at 08:34:39AM +0100, Peter Horton wrote: > > > > > Not quite so esoteric :-) > > > > Try changing COBALT_QUBE_SLOT_IRQ from 23 to 9 in > > include/asm/cobalt/cobalt.h. > > > > alas, no joy. > > > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > VP_IDE: IDE controller at PCI slot 0000:00:09.1 > VP_IDE: chipset revision 6 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1 > ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio > spurious 8259A interrupt: IRQ9. > That's strange, it worked here. Did you a clean build ? P. From kieran@pawsoff.org Tue May 18 22:19:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 22:19:35 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:46346 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 22:19:34 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id DC84B38212C; Tue, 18 May 2004 22:19:32 +0100 (BST) Date: Tue, 18 May 2004 22:19:32 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518211932.GB29636@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> <20040518211246.GA11722@skeleton-jack> <20040518211810.GA29636@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: <20040518211810.GA29636@getyour.pawsoff.org> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5074 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips Content-Length: 6986 Lines: 132 --yudcn1FV7Hsu/q59 Content-Type: multipart/mixed; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 10:12:46PM +0100, Peter Horton wrote: >=20 > That's strange, it worked here. >=20 > Did you a clean build ? >=20 yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made=20 the change to include/asm/cobalt/cobalt.h you suggested. kernel=20 =2Econfig attached .. Kieran. --Sr1nOIr3CvdE5hEN Content-Type: application/octet-stream Content-Disposition: attachment; filename=".config.gz" Content-Transfer-Encoding: base64 H4sICGZ9qkAAAy5jb25maWcAjVtLc9s4Er7Pr2BlDptUzaxFvbVVPoAgJCHiKwQoy7mwGIu2 tZFFrx7Z+N9vgxQtUmzQe5iMha/RaAD9BMA///jTIKdj9pIcNw/JdvtmPKW7dJ8c07XxkvxM jYds97h5+pexznb/OBrpenP8488/qO9N+Sx2eSBu34BD5fewb2wOxi47Gof0eIGGfYvLKlLp 0usCE+AKxNk6hWGPp/3m+GZs01/p1shej5tsd7iMylYBC7nLPEmc6ujUYcSLqe8G3GGoEEIS zyaO7zFEEiv0F8wDhrXfse/Fwg1KAWf54mxVv9PrRSRxR4JLT3Evljygl4bAF3wVu98iFrGq xJaw4yD0KRMiJpRi6wO8qKxNk0Q2upKODwyjaSzmfCpvzX7ZPvdl4ESzKgu+KP5AuDDXYrbN 7Cr5gjiOuHcFQj6NJFtdJsoC36kJy31B58yOPd8PkO4lTATWyWbEdriH72VJRKffEMaUxn4g ucu/s3jqh7GAP8o9dLJknfzYgqJl6xP873B6fc32VbX27chh4jKtoiGOPMcntZU5AzACLWFE GN8SvsMkU+QBCd0a4yULBfe9ymgLaC1ldZOH580OZEy36YOyg8JMzr0Jncdfyffv6AJZZMZk bl8onHdehn1ztUJx6YMiWST+6oa9SXekMV0wN4s4srYmirHNKBibhInhg6uubDnsm91OG8Fk aHZaCPgyREGHCCJRZB4okIVfGY4XbCUbm6OunoBIYKKHXVgRoocFq2tJRZvAqVE/Bofg+Br5 aiTx7P8hoq1EX8ksIiFMCVeDwKXxvS+YC4uCEti2NeiMcKevsP5o2IKNUMxjYL4iCNk97sZn POZBF9+gAuxpQJ+C/zRXGqUS3LoHMxWW+fv3b0WMU3k8Dt1upxMHlLfaTmjJVR83nvAO1jSe MQ9CGY1FwMF50MXFCczJkikriuvNtkvAl8K+zVkIAfAC8HF3MLn8pEEUO1xKcE7MszmpxDUe flNwxQkppZxJMEbTrHDIDTt2qH1F6ZgxBRNn50AzuEx7alUnWniqIMJ9lxKwiP3oCpawJptQ cNjraLZRoXLVm2g8m4JbHF/Ou99r4R32dQpUjNxvGzkctIkdDvotKxIOr/pWMI8tiU1q+ZDq MW4dDbxrG+yO2uFJGwxWhIgaQFTKo3HcX1hVaS+AOVxYuC96Jxn2NSRqYGIviUcZFokVPCeg w46gdWMpWm1RVfeyXdx71WQuZMwNaiHPZlY0ezfiWDiMBQ1TsE6HMpc1PoPn+MsIqEs5+ctg XMC/+T+SfrnkIUBUWyHKY4fNCL3Pk0Z8iYDGIy7DcjXXjcq0ohj5hib7tRLrkgFVGCmKxiSU x5tnx9ft6ckQzV7nXPPaMeYk7Hf6cDrmidfjRv2T7SHTr+T1FvemroyZM60k4UWby2G/XspG GRIb9GDmEUeUM7LTX5uH1LD3m1/pXjG9pOubh3Oz4V+XEtO7WOVsLATmRb6VvmT7N0OmD8+7 bJs9vZ0Zw5a50v5Sy76k3VyeBIqDLRQtamHQZSVh4Iey2VEtaLJbwx/JW6VjoTnb7OGnsS4E qXKznAXo3jKe4vmEgmnwLbbxZKSEKYfyo4VGjWATOhnitl6SRC5zsbLqDDtQAcAqN7rR8D6Q vnNVHzTIPEs/x5wN5NXMaSUJiYvijtXcSCLJDfwX8Bt36t6EjtOsErjNKnp6HqNoPG9pmhxU 5g5amT2cXtLdMVHqd7NZp/88/j4qAzCe0+3rzWb3mBnZzoDOxlppatUoLoxtLha1Mqloit3I kVyVEppC6UwmpCpoW1cISGn7MgMFrMqHXKaOHwT3iDYAFksC0nC/KGuv2qdQugNWrqFaESiA XoFDuQE3P05Pj5vfdUNQ3c+5VIsKAtWVSy1aIJMhIVOJUeu8/OnU8knYvkCIFE1GUJkOu1h0 rO42ZHpX0l6hedWJS3PpD+mu9FtGIkCHjUEYHXY1acw7jcPNwarXTuPao/4HfKhrD/vtJDLk U4d9wOZ+3KXDSbs8VAwGmpqzStJrJ5kHsveBxIpkiJc+JYmgUP62DxRw3j6MJ8ajvjloZ2LT bgc2M/adduV9J/TYXbvky7sFXgC/U3DuQrrWTuPQSYd9sEgSSq0JlvSWBEtOYN9XqxXqja/U +2wYfImnj2f42maam9uMGIIKfo7RWODP4es+7ml73Pxd72R8Dgm381zAWbr1jKM56vR0gJBi QD7aMvY0ElcHMYVzZYwZZm/SNz5PN/v0Dv77gnVXdDlZg0HXbxlVodc9vPT432z/c7N7asZT j8nS7VfIGqe/AaELVil8i9+Q3FZPYIGXw718ry6NkcdXVV0AonjB0CjlVUfgQRFiKRG1rB/a y1IjDv1IMvwwCsgCD09ulAQ84G3gLNREdRAqHxRFIcvELR1KGajs/QVnuPmqmcdkrseYwKXl hbjq9B1b0GA5rCZ/6jcUMXwJxYyW3bBNkGGrJENElPrgMvI8Tb4I/SENudrOs43LwKD5hchp nydzxufqbUTNWmGHcnp0fySeilohtzVOc+kQLx53uiaepEDm5mnONB2H4kcKPMBjCyS+zgJF Vl080jgkwB2q0gqbL1mIi8bg/xqp72C6LValGE+Jyml1NqAo5ncxpKJ30AKETmM/v2VCOdob SMQfk83e+M8pPaXgdarbqNjkNw06Z2Yc08MR6RQsJCSDOtHURYlWbAXGZ6EdzQLMiQtlMMfj FA919Rx2cwRDgqPklNVuYezIdTHnaPmezb1Z1ZzZtwhywe8aScHU8M2Xc9AL0jwpISHdQcKP FLyAXOlLcbRwfE73qstns2PAZpqdjvtjc/xSCy7FeDXP7nJencacQNHiMoJvjIi8GcPNVnFf Ms/2w7gHbqchnzxtN6+gYi+b7ZuxO6tNI3JWmMnI4UH9hKlrduoZ5/vqKtKX2s/YveOXWZ6b 3LysqrV5UOBibcpuXC75LL/BqcvRX+Eu4I57SjPicR/PaG13YnZwPzQPdLc8uTFgZ0mVDYeu 5WZf9IQyT1OE2U4X923M1J1mQo7dG2uKBjBDQuf4NcA9c8D5TDmu/uHYHE5wTVtMxo6mF2yK 7/U+WBBkRfhqhnto0eXNPE1mP9OdEaoEDLFC2YyMKnncpoeDAVHK+LzLdn8/Jy/7ZL3Jvlz7 xYbXKhgkO2OzO6b7x+RqNAgEqOBT28aXfc6DAEeCAA/HwtHkYCHVXfEIcBb60AR/qSvfZsYs bA8s/sfh7XBMX2r7o5DGNsCavj5nuzfsrDWYX71jKEbYvZ6OWt/CvSCS5VlndEj3W1Vn4Oue 08auHwkG0UGTaimSr/59O4EUV3gNZUuVpb9cd2JLK5pppsdv/OKgbF+TeEZcdn26Wm6XH4Fv KgmqHk1A9oYH0RyJ+bjT72rkaBw6X80Bqgv9iVFlfdsXV0Dpgbus8/L6EZ0LGjJNtnEeiAva mAZ9TvbJA+w+ZuZLPDFTy0IcdQtZPKcJkVo43W+SbWWL6l3H3UGn8lrm0hif7QYHvTCOSCjF bb8hTI6zlYQYjCVq4I4UBbTkcl0dztdZUT9sjq8am8KpgnIyjgN5X0ucyjsaaEYX8BunnW58 fYxaqFXg8noN4UIwhlV2kGrkLjk+PK+zJ0Nd41RW+Y5IOrf92oufsg227Y7cQ86s56ZXauFP 5TunBgPwlH//SA7puinYxWdRqMswDhdBbalzuaHEIzpk2VrMlppKJuxNNHfLkAQ6HMvipsfk Nf3LgEhrPG6z19c3QzWUvrZQ9tqxi/aknMzwcGOHeH4ZkjvAVBmFnMFQxM13ac2hdmlM52Co dS/83p9sn7L95vj8Undh0Is4M//q3V4DD+i0FVcvMtBh56Ad/032qaG5giwYcHPQwzPOd3yI H/m+45oj6hx37dEAP4A8w2PTNLU4BIc20MRzxhwUeIGmMC8/2dfU7ICfLxFjh8/m+r1RR8e4 hudo6Auy1J3QKooCxjkI+lu9fyFUc4yqunMxGEz0Owf4UHPKfoYnQ/x4QsFLrl8+wGB2etj3 bd9vptDv6ijS3SHbHyA4QtGm0UvBIBbg6V8BCXWzAgUPrh7vNMLSlT4liS3M4Qdcpup8ol2Y mTMwxwL3LiUNl2P8OVZJ4LgjfD8rBOMPCMbtswUC3FgrBB/JMGkfAtRjOB7i6lPS3I17o7Gp OUK90Dij8UDiQb5CNeyO5tOGuvmqYsv9oE7PShaMgTq3bx344PFA8wivRjPRu6viEYvKdD4g UU79AxIr0hwvX8aZ8+bBj7s5PFQy0csdyUu63iRojspt5sdYYLM3T5sjJHvLzTrNDGufJeuH JD+oK590XOKlvbQqT+yWVpEEnsukc+kFec10n0GlBAWTmz8crgmiegm57HQneE2f48F4PMJ9 moKJE4hY2o6FW2GFxG0jkS5z4N/RkA4H+G7nM1x1+6YmPil8FkLBBH93J4NOP+5r9Aah1ARE RenKnolHNYUumTB1pywlvqrf7lZQaRPwpP3V5SSs2hpPeejeEUji1QOD2083p8P+Zrv5cfNc vGW6edzsX5TzvzmuE9Xj9z9/bHaf6gJ4K3n9/u5KQQQhI7M/NIo0WOWxZJ28Hq/S6HyXlqO2 1bcie8awOvYCxrR2dlkBSNMYKjq8TX/T7JVz47PVpd0vWgkVGosFVJ8EuQh552dB0BhXmdQM 87wgpSnN9snr8+bhcP3ASWSn3bpeaYBONUaNhIX5SdWMkc6S9VN6xI5OAI1n5HqJiyRfPU0r jmdqn5zILoTZi3KdG+IVkTKsfP9wbi4++CC09i1ECQpGo5BL7GwdSHpqnLerBmScXts4vQ/G +WrVPmOAn4VbRkiBkWvlD36rPULGoTSeqtwDVeKvDejCDhV6peflcqizdSBERn3Pb5GveYiv bvj1/Qq0fwUXGmT/DUPe2Es7V5WLplRO8vzJcNjR8Y7sKcbX9sXNlMgbT+r4Aqrj6cnGXIqS /JCe1ln+3LKh0uoJaU3V8obF1fHHvaiSQJzNB7puccFcrx7EqmadSgEaSFFV62rHM9SivdIN prUTl3kEpuxYmtU5o/nzYYRbSNzp+zNSlYGk222ySzMoSh/xnSB2i+pM9di8FQqcSAtbTN/V 0kMtvWg+bRRattjiPGixNm/V16PqozitTeDqW16w5j5ZNPfB048GEJ69s5UqnXUyupZ2vbhu JBpo+/g20WHckyx02ffvvl6TcJtO9sdN/vRAvr2mtYcxoeTqvu79VUrtq0EwbO9Cg47oi+kH FMTlM/IRDSQM/AMal1CcosQF+MMLxfU3k+o9q0MszfuNIl6IyGqXQfgOCAo+aDz8QFp1zpsn j+3jOrb7ASOPUXVe3DJx9fUSOu3IkSHM6oMpRR9tMZtqtqYwuOS4+ZUaTrJ7OiVPaSV1Kifg VHIg+AH+ekpAtNtPkZyOP1URUH6Wf7DR743qfd6RkR4ZDTTIeNDRIl0touemk2A81I4zNLWI VoJhT4v0tYhW6uFQi0w0yKSn6zPRruikp5vPpK8bZzy6mg+kQ+PxYBKPNR3MrnZ8gEycmaa5 izf38GaNoAO8eYg3j/DmiUZujSimRhbzSpiFz8dxiLRF9TZljWXRtVAPA7bGc/Lw8+qVEg19 IZDv5UvYzb++vv30kO0O2Ta9PR7fROcv0xyoV8v7LDve3qzTXzfP66SX/3zcJk+H23VyTG7/ nZ32u2RrbNapebvLXvfZj7RaTudnQAv1HKf5KkukD8X3/5e3n5XDrGZWWOD7t9dj9lQUmFjP 4juTRj9n82Of7N9A/tNxs6vGUxrSqv473Mpb1M3K/wDOydxwNUEAAA== --Sr1nOIr3CvdE5hEN-- --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqn3kOWPbH1PXZ18RAim1AKCMSC7BPX4lQT6GdfYSN8NTzSKA+ACeOwlN ZpwA8XOjbgUikWBeBP5RWAI= =OjdU -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- From pdh@colonel-panic.org Tue May 18 22:21:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 22:21:59 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:48768 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 22:21:58 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BQC25-00034i-00; Tue, 18 May 2004 22:21:53 +0100 Date: Tue, 18 May 2004 22:21:53 +0100 To: Ralf Baechle Cc: Peter Horton , Jun Sun , Bob Breuer , linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518212153.GA11783@skeleton-jack> References: <20040518114519.C5390@mvista.com> <20040518191019.GA11007@skeleton-jack> <20040518195055.GB2454@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518195055.GB2454@linux-mips.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5075 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Content-Length: 976 Lines: 29 On Tue, May 18, 2004 at 09:50:55PM +0200, Ralf Baechle wrote: > On Tue, May 18, 2004 at 08:10:19PM +0100, Peter Horton wrote: > > > The kernel maps the page cache page into user space ... BANG! possible > > D-cache alias. > > > > The kernel doesn't bother flushing the page cache page from the D-cache > > as it's never accessed at it's page cache address. > > It is - after all the driver is copying the data to there. The same > problem also exists in the ramdisk driver and there it has been fixed > properly, it seems. > I had a dig around but couldn't decide where the proper fix should go. > > The current fix in the Cobalt patches (2.4 & 2.6) just flushes the read > > data out of the D-cache after every IDE insw()/insl(). This is the least > > intrusive fix. > > > > Some Sparc machines also see this problem. > > Carelessly written PIO drivers on any architecture would suffer from this > kind of problem. > Are you saying it's a driver problem ? :-) P. From pdh@colonel-panic.org Tue May 18 22:38:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 22:38:17 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:53376 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 22:38:16 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BQCHq-00037D-00; Tue, 18 May 2004 22:38:10 +0100 Date: Tue, 18 May 2004 22:38:10 +0100 To: Kieran Fulke Cc: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518213810.GA11885@skeleton-jack> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> <20040518211246.GA11722@skeleton-jack> <20040518211810.GA29636@getyour.pawsoff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518211810.GA29636@getyour.pawsoff.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5076 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Content-Length: 704 Lines: 29 On Tue, May 18, 2004 at 10:18:10PM +0100, Kieran Fulke wrote: > On Tue, May 18, 2004 at 10:12:46PM +0100, Peter Horton wrote: > > > > > That's strange, it worked here. > > > > Did you a clean build ? > > > > yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made > the change to include/asm/cobalt/cobalt.h you suggested. kernel > .config attached .. > Does this patch fix it ? P. --- linux.cvs/arch/mips/cobalt/irq.c 2003-11-13 14:30:45.000000000 +0000 +++ linux.pdh/arch/mips/cobalt/irq.c 2004-05-18 22:35:32.000000000 +0100 @@ -82,11 +83,15 @@ } if (pending & CAUSEF_IP7) { /* int 23 */ - do_IRQ(COBALT_QUBE_SLOT_IRQ, regs); + do_IRQ(23, regs); return; } } From kumba@gentoo.org Tue May 18 22:44:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 22:44:22 +0100 (BST) Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:11452 "EHLO rwcrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 22:44:21 +0100 Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58]) by comcast.net (rwcrmhc13) with ESMTP id <20040518214412015008jegte> (Authid: kumba12345); Tue, 18 May 2004 21:44:13 +0000 Message-ID: <40AA842D.9080603@gentoo.org> Date: Tue, 18 May 2004 17:46:21 -0400 From: Kumba Reply-To: kumba@gentoo.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> <20040518211246.GA11722@skeleton-jack> <20040518211810.GA29636@getyour.pawsoff.org> <20040518211932.GB29636@getyour.pawsoff.org> In-Reply-To: <20040518211932.GB29636@getyour.pawsoff.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5077 X-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 Content-Length: 1227 Lines: 38 Kieran Fulke wrote: > yeah. cleared out /usr/src and re-emerged mips-sources-2.6.6, then made > the change to include/asm/cobalt/cobalt.h you suggested. kernel > .config attached .. > > Kieran. Just to rule out a few things, try disabling the following options in your .config: CONFIG_IDE_TASK_IOCTL (IDE Taskfile Access) CONFIG_IDE_TASKFILE_IO (IDE Taskfile IO) CONFIG_TULIP_MWI (New bus configuration) CONFIG_TULIP_MMIO (Use PCI shared mem for NIC registers) CONFIG_TULIP_NAPI (Use NAPI RX polling) CONFIG_TULIP_NAPI_HW_MITIGATION (Use Interrupt Mitigation) Taskfile access is, afaict, needed only if you're doing disk forensics or such. The new taskfile IO code hung up on me a few times on Cobalt when I was initially testing some of Peter's 2.6.x patches, and as such, I haven't cut it on since then. Tulip, I don't recall which, but I *think* one of them also caused me some kind of an issue, I'm unsure if it was a hang or something else. In either case, I left them as is. See if turning those off does anything different. --Kumba -- "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 kieran@pawsoff.org Tue May 18 23:02:16 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 23:02:18 +0100 (BST) Received: from [IPv6:::ffff:81.187.251.134] ([IPv6:::ffff:81.187.251.134]:54794 "EHLO getyour.pawsoff.org") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 23:02:16 +0100 Received: by getyour.pawsoff.org (Postfix, from userid 1000) id 145CA38212C; Tue, 18 May 2004 23:02:14 +0100 (BST) Date: Tue, 18 May 2004 23:02:14 +0100 To: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 Message-ID: <20040518220214.GA29793@getyour.pawsoff.org> References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> <20040518211246.GA11722@skeleton-jack> <20040518211810.GA29636@getyour.pawsoff.org> <20040518213810.GA11885@skeleton-jack> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20040518213810.GA11885@skeleton-jack> User-Agent: Mutt/1.5.6i From: kieran@pawsoff.org (Kieran Fulke) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5078 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kieran@pawsoff.org Precedence: bulk X-list: linux-mips Content-Length: 1645 Lines: 62 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 10:38:10PM +0100, Peter Horton wrote: >=20 > Does this patch fix it ? >=20 > P. >=20 > --- linux.cvs/arch/mips/cobalt/irq.c 2003-11-13 14:30:45.000000000 +0000 > +++ linux.pdh/arch/mips/cobalt/irq.c 2004-05-18 22:35:32.000000000 +0100 > @@ -82,11 +83,15 @@ > } > =20 > if (pending & CAUSEF_IP7) { /* int 23 */ > - do_IRQ(COBALT_QUBE_SLOT_IRQ, regs); > + do_IRQ(23, regs); > return; > } > } Aha. that seems to work now. i can certainly now tune the card in and do=20 stuff [tm] with it. thanks for the help. cat /proc/interrupts CPU0 2: 0 XT-PIC cascade 9: 4134 XT-PIC saa7146 (0) 14: 27964 XT-PIC ide0 18: 711618 MIPS timer 19: 11311 MIPS eth0 21: 288 MIPS serial 22: 0 MIPS cascade 0000:00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev=20 01) Subsystem: Technotrend Systemtechnik GmbH: Unknown device 1011 Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at 12080800 (32-bit, non-prefetchable) cheers, Kieran. --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqofmOWPbH1PXZ18RAhNIAJ0TE5dq44ZsL3cMOqHuREkIxSWbyQCgnEZU blkZfeAo9KIofitnIPvpXgM= =NPM5 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From alan@lxorguk.ukuu.org.uk Tue May 18 23:07:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 23:07:22 +0100 (BST) Received: from the-village.bc.nu ([IPv6:::ffff:81.2.110.252]:4226 "EHLO localhost.localdomain") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 23:07:21 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i4IIOoFt010581; Tue, 18 May 2004 19:24:56 +0100 Received: (from alan@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id i4IIOaRt010580; Tue, 18 May 2004 19:24:37 +0100 X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: problems on D-cache alias in 2.4.22 From: Alan Cox To: Ralf Baechle Cc: Peter Horton , Jun Sun , Bob Breuer , linux-mips@linux-mips.org In-Reply-To: <20040518195055.GB2454@linux-mips.org> References: <20040518114519.C5390@mvista.com> <20040518191019.GA11007@skeleton-jack> <20040518195055.GB2454@linux-mips.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084904673.10535.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 18 May 2004 19:24:34 +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5079 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips Content-Length: 295 Lines: 8 On Maw, 2004-05-18 at 20:50, Ralf Baechle wrote: > Carelessly written PIO drivers on any architecture would suffer from this > kind of problem. It isnt a driver problem. (Ramdisk is a bit special as you get aliases in funny ways). The block and page cache is responsible for sorting this out. From jsun@orion.mvista.com Tue May 18 23:25:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 18 May 2004 23:25:51 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:31987 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 18 May 2004 23:25:47 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i4IMPdx6005009; Tue, 18 May 2004 15:25:39 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i4IMPd6W005007; Tue, 18 May 2004 15:25:39 -0700 Date: Tue, 18 May 2004 15:25:39 -0700 From: Jun Sun To: Peter Horton Cc: Bob Breuer , linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518152539.D5390@mvista.com> References: <20040518114519.C5390@mvista.com> <20040518191019.GA11007@skeleton-jack> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040518191019.GA11007@skeleton-jack>; from pdh@colonel-panic.org on Tue, May 18, 2004 at 08:10:19PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5080 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 1189 Lines: 37 On Tue, May 18, 2004 at 08:10:19PM +0100, Peter Horton wrote: > On Tue, May 18, 2004 at 11:45:19AM -0700, Jun Sun wrote: > > > > Like others suggested, this is not the right fix. flush_page_to_ram() > > is correctly nullified. Its job should be done somewhere else > > by other routines. > > > > Here are a couple of random ideas for finding the true root cause: > > > > We know what the true root cause is :-) > > IDE PIO fills the D-cache with the read data (write allocate) as it > copies it to the page cache. > > The kernel maps the page cache page into user space ... BANG! possible > D-cache alias. > > The kernel doesn't bother flushing the page cache page from the D-cache > as it's never accessed at it's page cache address. > The kernel (or driver) should flush the page if it is mapped to user space and the content is modified. > The current fix in the Cobalt patches (2.4 & 2.6) just flushes the read > data out of the D-cache after every IDE insw()/insl(). This is the least > intrusive fix. > It should be fixed at a higher layer before we return back to userland. If you can illustrate the call stack, I can probably take a look and give my opinion. Jun From pdh@colonel-panic.org Wed May 19 00:29:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 May 2004 00:29:42 +0100 (BST) Received: from purplechoc.demon.co.uk ([IPv6:::ffff:80.176.224.106]:10113 "EHLO skeleton-jack.localnet") by linux-mips.org with ESMTP id ; Wed, 19 May 2004 00:29:40 +0100 Received: from pdh by skeleton-jack.localnet with local (Exim 3.36 #1 (Debian)) id 1BQE1R-0003UQ-00; Wed, 19 May 2004 00:29:21 +0100 Date: Wed, 19 May 2004 00:29:21 +0100 To: Jun Sun Cc: linux-mips@linux-mips.org Subject: Re: problems on D-cache alias in 2.4.22 Message-ID: <20040518232921.GA13365@skeleton-jack> References: <20040518114519.C5390@mvista.com> <20040518191019.GA11007@skeleton-jack> <20040518152539.D5390@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518152539.D5390@mvista.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Peter Horton Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pdh@colonel-panic.org Precedence: bulk X-list: linux-mips Content-Length: 1138 Lines: 36 On Tue, May 18, 2004 at 03:25:39PM -0700, Jun Sun wrote: > > > > IDE PIO fills the D-cache with the read data (write allocate) as it > > copies it to the page cache. > > > > The kernel maps the page cache page into user space ... BANG! possible > > D-cache alias. > > > > The kernel doesn't bother flushing the page cache page from the D-cache > > as it's never accessed at it's page cache address. > > > > The kernel (or driver) should flush the page if it is mapped to user space > and the content is modified. > We just need a hook so that we can flush a page from the D-cache once it's read from a block device into the page cache. > > The current fix in the Cobalt patches (2.4 & 2.6) just flushes the read > > data out of the D-cache after every IDE insw()/insl(). This is the least > > intrusive fix. > > > > It should be fixed at a higher layer before we return back to userland. > > If you can illustrate the call stack, I can probably take a look and > give my opinion. > No call stack, sorry. It was months ago that I debugged this. IIRC I picked up the aliases with memcmp() in do_no_page() in mm/memory.c. P. From macro@ds2.pg.gda.pl Wed May 19 12:23:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 May 2004 12:23:40 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:7328 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 19 May 2004 12:23:39 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id B63644A074; Wed, 19 May 2004 13:23:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 979C9474C5; Wed, 19 May 2004 13:23:28 +0200 (CEST) Date: Wed, 19 May 2004 13:23:28 +0200 (CEST) From: "Maciej W. Rozycki" To: Kieran Fulke Cc: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 In-Reply-To: <20040518205914.GA29574@getyour.pawsoff.org> Message-ID: References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5083 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 699 Lines: 17 On Tue, 18 May 2004, Kieran Fulke wrote: > alas, no joy. [...] > VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1 > ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio > spurious 8259A interrupt: IRQ9. Hmm, interesting. As the 8259A can only signal IRQ7 and possibly IRQ15 as spurious interrupts, this smells like a bug in 8259A handlers, regardless of system-specific problems you have. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From phorton@bitbox.co.uk Wed May 19 13:57:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 May 2004 13:57:52 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:80.176.203.50]:8099 "EHLO pangolin.localnet") by linux-mips.org with ESMTP id ; Wed, 19 May 2004 13:57:51 +0100 Received: from sprocket.localnet ([192.168.1.27]) by pangolin.localnet with esmtp (Exim 3.35 #1 (Debian)) id 1BQQdQ-0004un-00; Wed, 19 May 2004 13:57:24 +0100 Message-ID: <40AB59B2.5090005@bitbox.co.uk> Date: Wed, 19 May 2004 13:57:22 +0100 From: Peter Horton User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@linux-mips.org Subject: Re: IRQ problem on cobalt / 2.6.6 References: <20040513183059.GA25743@getyour.pawsoff.org> <20040518073439.GA6818@skeleton-jack> <20040518205914.GA29574@getyour.pawsoff.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5084 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: phorton@bitbox.co.uk Precedence: bulk X-list: linux-mips Content-Length: 738 Lines: 32 Maciej W. Rozycki wrote: >On Tue, 18 May 2004, Kieran Fulke wrote: > > > >>alas, no joy. >> >> >[...] > > >>VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1 >> ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:pio, hdb:pio >> ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio >>spurious 8259A interrupt: IRQ9. >> >> > > Hmm, interesting. As the 8259A can only signal IRQ7 and possibly IRQ15 >as spurious interrupts, this smells like a bug in 8259A handlers, >regardless of system-specific problems you have. > > > We were getting interrupt 23 and calling do_IRQ() with a value of 9 (a bug, obviously). Interrupt 9 is masked so we get a "spurious 8259A interrupt" message. P. From macro@ds2.pg.gda.pl Wed May 19 17:43:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 May 2004 17:43:34 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:61408 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 19 May 2004 17:43:31 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id EA835474EF; Wed, 19 May 2004 18:43:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id D6F95474C5 for ; Wed, 19 May 2004 18:43:21 +0200 (CEST) Date: Wed, 19 May 2004 18:43:21 +0200 (CEST) From: "Maciej W. Rozycki" To: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux In-Reply-To: <20040519162924Z8225564-1530+2150@linux-mips.org> Message-ID: References: <20040519162924Z8225564-1530+2150@linux-mips.org> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5085 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 527 Lines: 15 On Wed, 19 May 2004 ralf@linux-mips.org wrote: > Modified files: > drivers/pci : pci.ids > > Log message: > Alpha processor Inc is dead; vendor ID 0x14d9 is now SiPackets. How about importing correct data from the official source? SiPackets is dead -- vendor ID 0x14d9 is now Alliance Semiconductor Corporation. ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From Manish_Lachwani@pmc-sierra.com Wed May 19 18:11:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 May 2004 18:11:41 +0100 (BST) Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:53731 "HELO mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP id ; Wed, 19 May 2004 18:11:39 +0100 Received: (qmail 5914 invoked from network); 19 May 2004 17:11:31 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 19 May 2004 17:11:31 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id i4JHBUap017141; Wed, 19 May 2004 10:11:31 -0700 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Wed, 19 May 2004 10:11:30 -0700 Message-ID: <9DFF23E1E33391449FDC324526D1F25902253755@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> From: Manish Lachwani To: "'Maciej W. Rozycki'" , linux-mips@linux-mips.org Subject: RE: CVS Update@-mips.org: linux Date: Wed, 19 May 2004 10:03:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5086 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Manish_Lachwani@pmc-sierra.com Precedence: bulk X-list: linux-mips Content-Length: 791 Lines: 27 AFAIK, Alliance Semiconductor got the IP of Sipackets. Thanks Manish -----Original Message----- From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl] Sent: Wednesday, May 19, 2004 9:43 AM To: linux-mips@linux-mips.org Subject: Re: CVS Update@-mips.org: linux On Wed, 19 May 2004 ralf@linux-mips.org wrote: > Modified files: > drivers/pci : pci.ids > > Log message: > Alpha processor Inc is dead; vendor ID 0x14d9 is now SiPackets. How about importing correct data from the official source? SiPackets is dead -- vendor ID 0x14d9 is now Alliance Semiconductor Corporation. ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From mpruznick@mvista.com Wed May 19 21:34:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 19 May 2004 21:34:22 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:11005 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 19 May 2004 21:34:21 +0100 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA02714; Wed, 19 May 2004 13:34:17 -0700 Message-ID: <40ABC4C8.4000006@mvista.com> Date: Wed, 19 May 2004 14:34:16 -0600 From: Michael Pruznick Reply-To: mpruznick@mvista.com Organization: MontaVista User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: BE pci/ide/harddisk vs localbus/pcmcia/ide/cf byteswap issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5087 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mpruznick@mvista.com Precedence: bulk X-list: linux-mips Content-Length: 4294 Lines: 108 Is this problem below solved in a better way for other boards that I can use as a template for the dbau1500be? With the dbau1500be I'm currently using the ugly patch below so that both pci/ide/harddisk and localbus/pcmcia/ide/cf work at the same time. Looks like the problem I'm running into is that pci is LE and pcmcia is BE. Since the ide code is common it will do software swap for both cases or neither case. Since one is LE and the other BE, one is always in correct byte order and the other is the wrong byte order. What I need is to be able to swap in one case but not the other. The patch below modifies the common code so that it knows the pcmcia i/o range and corrects the byte order in that case. The only BE bit I found for the dbau1500be pcmcia is read-only and the manual say not to be used with pcmcia. I verified this bit is not set and attempting to set this bit doesn't have any effect. I'm familiar with the rbhma4300 which has a similar setup, but does have a pcmcia BE bit, and does not have this problem. =================================================================== --- drivers/pcmcia/au1000_generic.c +++ drivers/pcmcia/au1000_generic.c @@ -59,11 +59,17 @@ static int pc_debug; #endif +#ifndef CONFIG_CPU_LITTLE_ENDIAN +u32 dbau1500be_pcmcia_base; +u32 dbau1500be_pcmcia_stop; +#endif + MODULE_LICENSE("GPL"); MODULE_AUTHOR("Pete Popov, MontaVista Software "); MODULE_DESCRIPTION("Linux PCMCIA Card Services: Au1x00 Socket Controller"); @@ -225,6 +231,12 @@ } #endif } + #ifndef CONFIG_CPU_LITTLE_ENDIAN + dbau1500be_pcmcia_base = pcmcia_socket[0].virt_io; + dbau1500be_pcmcia_stop = pcmcia_socket[socket_count-1].virt_io + 0x1000; + #endif /* Only advertise as many sockets as we can detect: */ if(register_ss_entry(socket_count, &au1000_pcmcia_operations)<0){ =================================================================== --- include/asm-mips/ide.h +++ include/asm-mips/ide.h @@ -163,9 +163,19 @@ #define outsw(port, addr, count) ide_outsw(port, addr, count) #define outsl(port, addr, count) ide_outsl(port, addr, count) +#ifdef CONFIG_MIPS_DB1500 +extern u32 dbau1500be_pcmcia_base; +extern u32 dbau1500be_pcmcia_stop; +#endif + static inline void ide_insw(unsigned long port, void *addr, unsigned int count) { while (count--) { + #ifdef CONFIG_MIPS_DB1500 + if ( ( port >= dbau1500be_pcmcia_base ) && ( port < dbau1500be_pcmcia_stop ) ) + *(u16 *)addr = le16_to_cpu(*(volatile u16 *)(mips_io_port_base + port)); + else + #endif *(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port); addr += 2; } @@ -174,6 +184,11 @@ static inline void ide_outsw(unsigned long port, void *addr, unsigned int count) { while (count--) { + #ifdef CONFIG_MIPS_DB1500 + if ( ( port >= dbau1500be_pcmcia_base ) && ( port < dbau1500be_pcmcia_stop ) ) + *(volatile u16 *)(mips_io_port_base + (port)) = cpu_to_le16(*(u16 *)addr); + else + #endif *(volatile u16 *)(mips_io_port_base + (port)) = *(u16 *)addr; addr += 2; } @@ -182,6 +197,11 @@ static inline void ide_insl(unsigned long port, void *addr, unsigned int count) { while (count--) { + #ifdef CONFIG_MIPS_DB1500 + if ( ( port >= dbau1500be_pcmcia_base ) && ( port < dbau1500be_pcmcia_stop ) ) + *(u32 *)addr = le32_to_cpu(*(volatile u32 *)(mips_io_port_base + port)); + else + #endif *(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port); addr += 4; } @@ -190,6 +210,11 @@ static inline void ide_outsl(unsigned long port, void *addr, unsigned int count) { while (count--) { + #ifdef CONFIG_MIPS_DB1500 + if ( ( port >= dbau1500be_pcmcia_base ) && ( port < dbau1500be_pcmcia_stop ) ) + *(volatile u32 *)(mips_io_port_base + (port)) = cpu_to_le32(*(u32 *)addr); + else + #endif *(volatile u32 *)(mips_io_port_base + (port)) = *(u32 *)addr; addr += 4; } =================================================================== From anemo@mba.ocn.ne.jp Thu May 20 06:16:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 May 2004 06:16:47 +0100 (BST) Received: from [IPv6:::ffff:202.230.225.5] ([IPv6:::ffff:202.230.225.5]:54814 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Thu, 20 May 2004 06:16:46 +0100 Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 20 May 2004 05:16:44 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (Postfix) with ESMTP id 57DF0239E2C; Thu, 20 May 2004 14:18:21 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i4K5GZwB016163; Thu, 20 May 2004 14:16:35 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 20 May 2004 14:17:32 +0900 (JST) Message-Id: <20040520.141732.74755661.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: fix 2.4 mips64 build (CONFIG_NEW_TIME_C) From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5088 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 834 Lines: 22 CONFIG_NEW_TIME_C no longer exists. Please apply this to 2.4 tree. diff -u linux-mips/arch/mips64/kernel/Makefile linux/arch/mips64/kernel/Makefile --- linux-mips/arch/mips64/kernel/Makefile Thu Mar 11 10:13:45 2004 +++ linux/arch/mips64/kernel/Makefile Thu May 20 13:41:46 2004 @@ -17,12 +17,11 @@ obj-y := branch.o cpu-probe.o entry.o irq.o proc.o process.o \ ptrace.o r4k_cache.o r4k_fpu.o r4k_genex.o r4k_switch.o \ reset.o scall_64.o semaphore.o setup.o signal.o syscall.o \ - traps.o unaligned.o + time.o traps.o unaligned.o obj-$(CONFIG_I8259) += i8259.o obj-$(CONFIG_IRQ_CPU) += irq_cpu.o obj-$(CONFIG_IRQ_CPU_RM7K) += irq-rm7000.o -obj-$(CONFIG_NEW_TIME_C) += time.o obj-$(CONFIG_MODULES) += mips64_ksyms.o obj-$(CONFIG_MIPS32_COMPAT) += linux32.o signal32.o ioctl32.o --- Atsushi Nemoto From dwalton@ddtsm.com Thu May 20 21:27:17 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 20 May 2004 21:27:18 +0100 (BST) Received: from [IPv6:::ffff:68.118.232.104] ([IPv6:::ffff:68.118.232.104]:12735 "EHLO gallardo") by linux-mips.org with ESMTP id ; Thu, 20 May 2004 21:27:17 +0100 Received: by gallardo (Postfix, from userid 1000) id 0C6C6AC2084; Thu, 20 May 2004 16:27:04 -0400 (EDT) Date: Thu, 20 May 2004 16:27:04 -0400 From: Daniel Walton To: linux-mips@linux-mips.org Subject: Re: Using more than 256 MB of memory on SB1250 in 32-bit mode Message-ID: <20040520202703.GA24477@ddtsm.com> Reply-To: Daniel Walton References: <3F4FCCD5.1000604@tadpole.com> <20030831133434.GA23189@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030831133434.GA23189@linux-mips.org> User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dwalton+mips@ddtsm.com Precedence: bulk X-list: linux-mips Content-Length: 734 Lines: 18 On Sun, Aug 31, 2003 at 03:34:34PM +0200, Ralf Baechle wrote: > The explanation you gave isn't exactly right. A 2GB/2GB split would normally > support 2GB of low memory. We don't on MIPS due to the very inconvenient and > unchangable mappings of KSEG0/KSEG1 - something that may have been sweet > in '85 when the address map was designed but not today when 32-bit address > spaces are beginning to be fairly tight. > > Highmem works ok in 2.4 as long as you have a reasonably low ratio of > highmem to lowmem. For typical loads that means going beyond 4:1 isn't > sensible but the actual number may vary much based on exact system > configuration or workload. > > Ralf > So what is a practical limit to total memory. Daniel From jbglaw@dvmwest.gt.owl.de Fri May 21 07:32:36 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 21 May 2004 07:32:47 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:41671 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Fri, 21 May 2004 07:32:36 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id E90D74B69E; Fri, 21 May 2004 08:32:32 +0200 (CEST) Date: Fri, 21 May 2004 08:32:32 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: [zli4@cs.uiuc.edu: [OPERA] Another potential bug in /arch/mips/kernel/sysirix.c] Message-ID: <20040521063232.GL1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1KBBbqQMyIFUBNXy" Content-Disposition: inline X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5090 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 4620 Lines: 143 --1KBBbqQMyIFUBNXy Content-Type: multipart/mixed; boundary="EIfQsdwoOfRLryR6" Content-Disposition: inline --EIfQsdwoOfRLryR6 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! This just came in by lkml. Forwarded in the hope of catching Ralf's eyes:) MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --EIfQsdwoOfRLryR6 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: jbglaw@lug-owl.de Delivered-To: jbglaw@lug-owl.de Received: from vger.kernel.org (vger.kernel.org [12.107.209.244]) by dvmwest.gt.owl.de (Postfix) with ESMTP id 20E164B6D1 for ; Fri, 21 May 2004 00:32:34 +0200 (CEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265184AbUETW20 (ORCPT ); Thu, 20 May 2004 18:28:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265267AbUETW20 (ORCPT ); Thu, 20 May 2004 18:28:26 -0400 Received: from dcs-server2.cs.uiuc.edu ([128.174.252.3]:47330 "EHLO dcs-server2.cs.uiuc.edu") by vger.kernel.org with ESMTP id S265184AbUETW2X (ORCPT ); Thu, 20 May 2004 18:28:23 -0400 Received: from Turandot (turandot.cs.uiuc.edu [128.174.246.118]) (authenticated bits=0) by dcs-server2.cs.uiuc.edu (8.12.10/8.12.10) with ESMTP id i4KMSMgn020818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 May 2004 17:28:22 -0500 (CDT) From: "Zhenmin Li" To: Subject: [OPERA] Another potential bug in /arch/mips/kernel/sysirix.c Date: Thu, 20 May 2004 17:26:36 -0500 Message-ID: <001801c43eb9$835b09f0$76f6ae80@Turandot> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] We ran our bug detection tool upon Linux 2.6.6, and found some potential errors. We would sincerely appreciate your help if anyone can confirm whether they are bugs or not. Linux 2.6.6, /arch/mips/kernel/sysirix.c, Line 1642 1634 asmlinkage int irix_statvfs64(char *fname, struct irix_statvfs64 *buf) 1635 { 1636 struct nameidata nd; 1637 struct kstatfs kbuf; 1638 int error, i; 1639 1640 printk("[%s:%d] Wheee.. irix_statvfs(%s,%p)\n", 1641 current->comm, current->pid, fname, buf); !1642 error = verify_area(VERIFY_WRITE, buf, sizeof(struct irix_statvfs)); 1643 if(error) 1644 goto out; May be changed to: 1634 asmlinkage int irix_statvfs64(char *fname, struct irix_statvfs64 *buf) 1635 { 1636 struct nameidata nd; 1637 struct kstatfs kbuf; 1638 int error, i; 1639 1640 printk("[%s:%d] Wheee.. irix_statvfs(%s,%p)\n", 1641 current->comm, current->pid, fname, buf); !1642 error = verify_area(VERIFY_WRITE, buf, sizeof(struct irix_statvfs64)); 1643 if(error) 1644 goto out; Thanks a lot, OPERA Research Group University of Illinois at Urbana-Champaign - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ --EIfQsdwoOfRLryR6-- --1KBBbqQMyIFUBNXy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAraKAHb1edYOZ4bsRAgS7AKCMMtcG7IH9W8lS21CyoH5a4bRMDgCcDhzi F+Q4Q8Rm/5vydS/wz5m+p9M= =Qr+x -----END PGP SIGNATURE----- --1KBBbqQMyIFUBNXy-- From gill.robles@exterity.co.uk Sat May 22 08:59:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 May 2004 08:59:24 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:25782 "EHLO exterity-serv1.exterity.co.uk") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Sat, 22 May 2004 08:59:23 +0100 Received: from gillpc ([192.168.0.32]) by exterity-serv1.exterity.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sat, 22 May 2004 09:01:25 +0100 From: "Gill" To: Subject: Socket problem? Date: Sat, 22 May 2004 09:02:48 +0100 Organization: Exterity Message-ID: <000001c43fd3$2c25a350$2000a8c0@gillpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 22 May 2004 08:01:25.0984 (UTC) FILETIME=[FAFDDE00:01C43FD2] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gill.robles@exterity.co.uk Precedence: bulk X-list: linux-mips Content-Length: 569 Lines: 19 Hi - Has anyone come across a socket problem where the user app calls select() on a set of sockets, which returns, indicating that data is waiting...then subsequent recvfrom() call returns -1 indicating that there's nothing there?? I'm using linux v2.4.2, IPv4, and the ethernet driver is pcnet32. We're receiving a UDP stream. I'm trying to check for dropped packets. /proc/net/snmp indicates a number of UDP InErrors (~1 per second). However, not yet sure whether this is a consequence of the problem above, or cause of it. Any help much appreciated! /Gill From jbglaw@dvmwest.gt.owl.de Sat May 22 17:06:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 22 May 2004 17:11:52 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:3818 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Sat, 22 May 2004 17:06:38 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 0A3FA4B662; Sat, 22 May 2004 18:06:36 +0200 (CEST) Date: Sat, 22 May 2004 18:06:35 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Socket problem? Message-ID: <20040522160635.GV1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <000001c43fd3$2c25a350$2000a8c0@gillpc> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r6hKzN7r4zkbhieJ" Content-Disposition: inline In-Reply-To: <000001c43fd3$2c25a350$2000a8c0@gillpc> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 2014 Lines: 59 --r6hKzN7r4zkbhieJ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2004-05-22 09:02:48 +0100, Gill wrote in message <000001c43fd3$2c25a350$2000a8c0@gillpc>: > Hi - >=20 > Has anyone come across a socket problem where the user app calls select()= on > a set of sockets, which returns, indicating that data is waiting...then > subsequent recvfrom() call returns -1 indicating that there's nothing > there?? Read the select() manpage again. Upon successful return, it's guaranteed that the very next read() on a file descriptor contained in the result set won't block. Typically, it's the case after data arrived, but returning -1 *immediately* (with no blocking) is okay, too. > I'm using linux v2.4.2, IPv4, and the ethernet driver is pcnet32. We're > receiving a UDP stream. Quite aged version, though perfectly correct on select() behaviour. > I'm trying to check for dropped packets. /proc/net/snmp indicates a numb= er > of UDP InErrors (~1 per second). However, not yet sure whether this is a > consequence of the problem above, or cause of it. Neither - nor. You've got a small thinko in your application. Albeit that: update your kernel version... It most probably contains a number of known root exploits. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --r6hKzN7r4zkbhieJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAr3qLHb1edYOZ4bsRAgUjAJ0dckbFgNuYl3Ve3R6as3N89e06RwCeOFpl Mx5LFma3X21zwHgkwgNLPNA= =/QbY -----END PGP SIGNATURE----- --r6hKzN7r4zkbhieJ-- From gill.robles@exterity.co.uk Mon May 24 09:22:05 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 May 2004 09:22:08 +0100 (BST) Received: from no-dns-yet.demon.co.uk ([IPv6:::ffff:83.104.11.251]:32269 "EHLO exterity-serv1.exterity.co.uk") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Mon, 24 May 2004 09:22:05 +0100 Received: from gillpc ([192.168.0.32]) by exterity-serv1.exterity.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 May 2004 09:24:03 +0100 From: "Gill" To: "'Jan-Benedict Glaw'" , Subject: RE: Socket problem? Date: Mon, 24 May 2004 09:25:43 +0100 Organization: Exterity Message-ID: <000501c44168$b4718800$2000a8c0@gillpc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040522160635.GV1912@lug-owl.de> X-OriginalArrivalTime: 24 May 2004 08:24:03.0140 (UTC) FILETIME=[78BEF040:01C44168] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gill.robles@exterity.co.uk Precedence: bulk X-list: linux-mips Content-Length: 2074 Lines: 56 Hi - To clarify, more specifically select() returns a positive value, and a subsequent call to FD_ISSET() returns TRUE for one of the sockets the app is listening on. Then, app calls recvfrom() which returns (sometimes) -1. Problem occurs sporadically...I'm seeing it every hundred or so packets at the moment, but it varies. Thanks, Gill -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Jan-Benedict Glaw Sent: 22 May 2004 17:07 To: linux-mips@linux-mips.org Subject: Re: Socket problem? On Sat, 2004-05-22 09:02:48 +0100, Gill wrote in message <000001c43fd3$2c25a350$2000a8c0@gillpc>: > Hi - > > Has anyone come across a socket problem where the user app calls > select() on a set of sockets, which returns, indicating that data is > waiting...then subsequent recvfrom() call returns -1 indicating that > there's nothing there?? Read the select() manpage again. Upon successful return, it's guaranteed that the very next read() on a file descriptor contained in the result set won't block. Typically, it's the case after data arrived, but returning -1 *immediately* (with no blocking) is okay, too. > I'm using linux v2.4.2, IPv4, and the ethernet driver is pcnet32. > We're receiving a UDP stream. Quite aged version, though perfectly correct on select() behaviour. > I'm trying to check for dropped packets. /proc/net/snmp indicates a > number of UDP InErrors (~1 per second). However, not yet sure whether > this is a consequence of the problem above, or cause of it. Neither - nor. You've got a small thinko in your application. Albeit that: update your kernel version... It most probably contains a number of known root exploits. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); From jbglaw@dvmwest.gt.owl.de Mon May 24 10:13:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 May 2004 10:13:41 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:58283 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Mon, 24 May 2004 10:13:38 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id D03204B6FF; Mon, 24 May 2004 11:13:35 +0200 (CEST) Date: Mon, 24 May 2004 11:13:35 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: Socket problem? Message-ID: <20040524091335.GD1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <20040522160635.GV1912@lug-owl.de> <000501c44168$b4718800$2000a8c0@gillpc> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ieuopS9JtHMyIYxU" Content-Disposition: inline In-Reply-To: <000501c44168$b4718800$2000a8c0@gillpc> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 2000 Lines: 56 --ieuopS9JtHMyIYxU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2004-05-24 09:25:43 +0100, Gill wrote in message <000501c44168$b4718800$2000a8c0@gillpc>: > Hi - >=20 > To clarify, more specifically select() returns a positive value, and a > subsequent call to FD_ISSET() returns TRUE for one of the sockets the app= is > listening on. Then, app calls recvfrom() which returns (sometimes) -1. > Problem occurs sporadically...I'm seeing it every hundred or so packets at > the moment, but it varies. That sounds perfectly okay. >From SuS V3: ------------------------------------------------------------------- A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. (The function might return data, an end-of-file indication, or an error other than one indicating that it is blocked, and in each of these cases the descriptor shall be considered ready for reading.) ------------------------------------------------------------------- So everything is perfectly okay, and because you have to do proper error checking anyways, that shouldn't disturb your application at all. MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --ieuopS9JtHMyIYxU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAsby/Hb1edYOZ4bsRAkJ2AJ440la+6H1v814nFOv9iMTGK+y+QACfeKj7 Qlgrmv4WxI9UiVQE5V+DZhU= =8ZvA -----END PGP SIGNATURE----- --ieuopS9JtHMyIYxU-- From jbglaw@dvmwest.gt.owl.de Mon May 24 10:14:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 May 2004 10:14:21 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:62123 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Mon, 24 May 2004 10:14:18 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id CBDFB4B700; Mon, 24 May 2004 11:14:17 +0200 (CEST) Date: Mon, 24 May 2004 11:14:17 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: OT: Mail viruses Message-ID: <20040524091417.GE1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <40B15D5D.6040605@ispworkshop.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/G8HP5VWPly0CIzN" Content-Disposition: inline In-Reply-To: <40B15D5D.6040605@ispworkshop.com> X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 1129 Lines: 38 --/G8HP5VWPly0CIzN Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2004-05-24 10:26:37 +0800, Ong Beng Hui wrote in message <40B15D5D.6040605@ispworkshop.com>: > Did anyone noticed a significant amount of mail viruses from this > mailing list ? No. Most virii are sorted out before they get delivered into my mailing-list specific MBOXes :) MfG, JBG --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --/G8HP5VWPly0CIzN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAsbzpHb1edYOZ4bsRAqfAAJ92EVdRmvbTRAoFhN22g4YqT2SIzgCgg6bv FLww39S0Fl57++OcIBGaxkY= =jtl8 -----END PGP SIGNATURE----- --/G8HP5VWPly0CIzN-- From herbert@13thfloor.at Mon May 24 19:29:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 May 2004 19:29:22 +0100 (BST) Received: from MAIL.13thfloor.at ([IPv6:::ffff:212.16.62.51]:20901 "EHLO mail.13thfloor.at") by linux-mips.org with ESMTP id ; Mon, 24 May 2004 19:29:19 +0100 Received: by mail.13thfloor.at (Postfix, from userid 1001) id 3959A510173; Mon, 24 May 2004 20:29:15 +0200 (CEST) Date: Mon, 24 May 2004 20:29:15 +0200 From: Herbert Poetzl To: ralf@gnu.org Cc: linux-mips@linux-mips.org Subject: linux-vserver syscall ... Message-ID: <20040524182915.GA27481@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.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: 5140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: linux-mips Content-Length: 842 Lines: 28 Hi Ralf! obviously I forgot to ask you to reserve a syscall for linux-vserver, and I just discovered this as the currently used number (273) was used up by some other syscall (in 2.6.7-rc1) ... so I'm asking you now, could you please reserve a syscall for this project, so that we do not need to change it on every new kernel release? here is a list of currently reserved syscalls (for other archs) and some links to the project (in case you care) arch number maintainer -------------------------------------------- x86_64 236 [Andi Kleen] s390 263 [Martin Schwidefsky] sparc/64 267 [David S.Miller] i386 273 [Rik/Linus/Andrew] sh3/sh4 273 [Kazumoto Kojima] ppc/64 257 [Benjamin Herrenschmidt] thanks in advance, Herbert From herbert@13thfloor.at Mon May 24 20:05:11 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 24 May 2004 20:05:14 +0100 (BST) Received: from MAIL.13thfloor.at ([IPv6:::ffff:212.16.62.51]:25253 "EHLO mail.13thfloor.at") by linux-mips.org with ESMTP id ; Mon, 24 May 2004 20:05:11 +0100 Received: by mail.13thfloor.at (Postfix, from userid 1001) id 7C6D3510173; Mon, 24 May 2004 21:05:08 +0200 (CEST) Date: Mon, 24 May 2004 21:05:08 +0200 From: Herbert Poetzl To: ralf@gnu.org Cc: linux-mips@linux-mips.org Subject: Re: linux-vserver syscall ... Message-ID: <20040524190508.GC27481@MAIL.13thfloor.at> References: <20040524182915.GA27481@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040524182915.GA27481@MAIL.13thfloor.at> User-Agent: Mutt/1.4.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: 5142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: linux-mips Content-Length: 1144 Lines: 39 On Mon, May 24, 2004 at 08:29:15PM +0200, Herbert Poetzl wrote: > > Hi Ralf! > > obviously I forgot to ask you to reserve a > syscall for linux-vserver, and I just discovered > this as the currently used number (273) was used > up by some other syscall (in 2.6.7-rc1) ... > > so I'm asking you now, could you please reserve > a syscall for this project, so that we do not > need to change it on every new kernel release? > > here is a list of currently reserved syscalls > (for other archs) and some links to the project > (in case you care) hmm, "a brain, I need a brain for my master" ... okay here are the promised links: http://www.linux-vserver.org/ http://vserver.13thfloor.at/Stuff/PAPER-05.4.txt best, Herbert > arch number maintainer > -------------------------------------------- > x86_64 236 [Andi Kleen] > s390 263 [Martin Schwidefsky] > sparc/64 267 [David S.Miller] > i386 273 [Rik/Linus/Andrew] > sh3/sh4 273 [Kazumoto Kojima] > ppc/64 257 [Benjamin Herrenschmidt] > > thanks in advance, > Herbert > From brad1972_10@hotmail.com Tue May 25 03:36:21 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 May 2004 03:36:24 +0100 (BST) Received: from sea2-f52.sea2.hotmail.com ([IPv6:::ffff:207.68.165.52]:13327 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 25 May 2004 03:36:21 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 May 2004 19:36:13 -0700 Received: from 61.230.216.210 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 25 May 2004 02:36:13 GMT X-Originating-IP: [61.230.216.210] X-Originating-Email: [brad1972_10@hotmail.com] X-Sender: brad1972_10@hotmail.com From: =?big5?B?tsAgtmmlwQ==?= To: linux-mips@linux-mips.org, raiko@niisi.msk.ru, Harald.Koerfgen@home.ivm.de Cc: ralf@gnu.org Subject: A question about memory allocation of linux kernel!! Date: Tue, 25 May 2004 10:36:13 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=big5; format=flowed Message-ID: X-OriginalArrivalTime: 25 May 2004 02:36:13.0995 (UTC) FILETIME=[0C2DDFB0:01C44201] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad1972_10@hotmail.com Precedence: bulk X-list: linux-mips Content-Length: 2349 Lines: 74 Hi, Sir, I have a question about memory allocation when linux OS is booting. We use linux as embedded OS for internet access device(ADSL router). Our system is MIPS-like CPU (R3000) with 2M flash and 8M SDRAM(MMU less). Due to use small memory footprint, we can not run many application on ADSL router. But we confuse about the memory for kernel "reserved". We can see the message that printed by booting procedure. Listed below: Loading R[23]000 MMU routines. CPU revision is: 136451c3 Primary instruction cache 4kb, linesize 16 bytes Primary data cache 1kb, linesize 16 bytes Linux version 2.4.17-uc0 (brad@localhost) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 rel4Determined physical RAM map: boot_mem_map.nr_map==1 memory: 00800000 @ 00000000 (usable) PAGE_SIZE(1000) the address of _end==80279d70 start_pfn(27a) boot_mem_map.map[0].size==8388608 max_pfn==0 start PFN 0 end PFN 2048 start < first_usable_pfn first_usable_pfn==-1 start==0 end=2048 before init bootmem first_usable_pfn=0000027a max_pfn=00000800 max_low_pfn(800),min_low_pfn(27a) bootmap_size = 0x100 before reserve bootmem first_usable_pfn address=0027a000,bootmap_size=00000100 reserve_bootmem_core: start(0),addr(27a000),size(100) sidx(27a), eidx(27b), end(27b) Initial ramdisk at: 0x8015b000 (666765 bytes) On node 0 totalpages: 2048 size(20040). zone(0): 2048 pages. size(80). size(40). size(20). size(10). size(8). size(4). size(4). size(4). size(4). size(4). zone(1): 0 pages. zone(2): 0 pages. size(1c). Kernel command line: root=/dev/ram0 ip=199.190.143.254::199.190.143.1:255.255.255.0:tc3160:eth0:onoCalibrating delay loop... 199.47 BogoMIPS Brad Add: init mem_init totalram_pages==1381 reservedpages==667 Memory: 5524k/8192k available (1168k kernel code, 2668k reserved, 745k data, 52k init) : : : We can see the memory usage by linux kernel from booting message. The total memory size we can use is 5524K bytes. Because there are 2668K are reserved. Can we reduce the "reserved" memory size? Or where we can set the size of memory for reserved? Please provide comment! Thanks!! Best Regards Brad. _________________________________________________________________ Ąß§YĄÓ˝Đ MSN Mobile ŞA°ČˇG¦b±zŞş¤âľ÷¤W¦¬µo MSN Hotmail http://msn.com.tw/msnmobile From brad1972_10@hotmail.com Tue May 25 03:50:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 May 2004 03:50:22 +0100 (BST) Received: from sea2-f19.sea2.hotmail.com ([IPv6:::ffff:207.68.165.19]:47368 "EHLO hotmail.com") by linux-mips.org with ESMTP id ; Tue, 25 May 2004 03:50:19 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 24 May 2004 19:50:11 -0700 Received: from 61.230.216.210 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 25 May 2004 02:50:11 GMT X-Originating-IP: [61.230.216.210] X-Originating-Email: [brad1972_10@hotmail.com] X-Sender: brad1972_10@hotmail.com From: =?big5?B?tsAgtmmlwQ==?= To: linux-mips@linux-mips.org, raiko@niisi.msk.ru Cc: ralf@gnu.org, info@uclinux.com Subject: A question about memory allocation of linux kernel!! Date: Tue, 25 May 2004 10:50:11 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=big5; format=flowed Message-ID: X-OriginalArrivalTime: 25 May 2004 02:50:11.0856 (UTC) FILETIME=[FF955100:01C44202] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad1972_10@hotmail.com Precedence: bulk X-list: linux-mips Content-Length: 2364 Lines: 74 Hi, Sir, I have a question about memory allocation when linux OS is booting. We use linux as embedded OS for internet access device(ADSL router). Our system is MIPS-like CPU (R3000) with 2M flash and 8M SDRAM(MMU less). Due to use small memory footprint, we can not run many application on ADSL router. But we confuse about the memory for kernel "reserved". We can see the message that printed by booting procedure. Listed below: Loading R[23]000 MMU routines. CPU revision is: 136451c3 Primary instruction cache 4kb, linesize 16 bytes Primary data cache 1kb, linesize 16 bytes Linux version 2.4.17-uc0 (brad@localhost) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 rel4Determined physical RAM map: boot_mem_map.nr_map==1 memory: 00800000 @ 00000000 (usable) PAGE_SIZE(1000) the address of _end==80279d70 start_pfn(27a) boot_mem_map.map[0].size==8388608 max_pfn==0 start PFN 0 end PFN 2048 start < first_usable_pfn first_usable_pfn==-1 start==0 end=2048 before init bootmem first_usable_pfn=0000027a max_pfn=00000800 max_low_pfn(800),min_low_pfn(27a) bootmap_size = 0x100 before reserve bootmem first_usable_pfn address=0027a000,bootmap_size=00000100 reserve_bootmem_core: start(0),addr(27a000),size(100) sidx(27a), eidx(27b), end(27b) Initial ramdisk at: 0x8015b000 (666765 bytes) On node 0 totalpages: 2048 size(20040). zone(0): 2048 pages. size(80). size(40). size(20). size(10). size(8). size(4). size(4). size(4). size(4). size(4). zone(1): 0 pages. zone(2): 0 pages. size(1c). Kernel command line: root=/dev/ram0 ip=199.190.143.254::199.190.143.1:255.255.255.0:tc3160:eth0:onoCalibrating delay loop... 199.47 BogoMIPS Brad Add: init mem_init totalram_pages==1381 reservedpages==667 Memory: 5524k/8192k available (1168k kernel code, 2668k reserved, 745k data, 52k init) : : : We can see the memory usage by linux kernel from booting message. The total memory size we can use is 5524K bytes. Because there are 2668K are reserved. Can we reduce the "reserved" memory size? Or where we can set the size of memory for reserved? Please provide comment! Thanks!! Best Regards Brad. _________________________________________________________________ ˛{¦b´N¤W MSN ·|­űĄŘżýˇG¦b˝u¤Wµ˛Ąć·sŞB¤ÍˇA§ä¨ěżł˝ě¬Ű§ëŞşąŮ¦ń http://members.msn.com?pgmarket=zh-tw From ratin@koperasw.com Tue May 25 19:49:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 May 2004 19:50:00 +0100 (BST) Received: from host73.ipowerweb.com ([IPv6:::ffff:12.129.211.254]:12585 "EHLO host73.ipowerweb.com") by linux-mips.org with ESMTP id ; Tue, 25 May 2004 19:49:57 +0100 Received: from c-67-170-233-233.client.comcast.net ([67.170.233.233] helo=ratwin1) by host73.ipowerweb.com with asmtp (Exim 3.36 #1) id 1BSgyD-0002aX-00 for linux-mips@linux-mips.org; Tue, 25 May 2004 11:48:13 -0700 Reply-To: From: "Ratin Kumar" To: Subject: Gnome/Mozilla on Malta Date: Tue, 25 May 2004 11:49:36 -0700 Organization: Kopera Software Inc. Message-ID: <00b601c44289$09cfc2a0$6901a8c0@ratwin1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01C4424E.5D70EAA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host73.ipowerweb.com X-AntiAbuse: Original Domain - linux-mips.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - koperasw.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: 5164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ratin@koperasw.com Precedence: bulk X-list: linux-mips Content-Length: 4932 Lines: 196 This is a multi-part message in MIME format. ------=_NextPart_000_00B7_01C4424E.5D70EAA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Has anyone tried building gnome and/or mozilla for Malta? My target is RH7.3 port for mipsel with a matrox mill II PCI card in frame buffer mode. I have tried native build of gnome and got quiet a few components going. I have also tried garnome with some success in getting a few components to build but it failed with Nautilus. I have also tried KDE but for some odd reason it does not pick up my QT installation during configure stage, even after I have set the LD_LIBRARY_PATH... Basically I want to have a browser running on RH installation. Any ideas??? Thanks in advance. -Ratin. ------=_NextPart_000_00B7_01C4424E.5D70EAA0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

Has anyone tried building gnome and/or mozilla for = Malta?

 

My target is RH7.3 port for mipsel with a matrox mill = II PCI card in frame buffer mode.

 

I have tried native build of gnome and got quiet a = few components going.

 

I have also tried garnome with some success in = getting a few components to build but it failed with Nautilus.

 

I have also tried KDE but for some odd reason it does = not pick up my QT installation during configure stage, even after I have set = the LD_LIBRARY_PATH…..

 

Basically I want to have a browser running on RH installation.

 

Any ideas???

 

Thanks in advance…

 

-Ratin.

------=_NextPart_000_00B7_01C4424E.5D70EAA0-- From ralf@linux-mips.org Tue May 25 20:26:23 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 25 May 2004 20:26:26 +0100 (BST) Received: from p508B675A.dip.t-dialin.net ([IPv6:::ffff:80.139.103.90]:54806 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 25 May 2004 20:26:23 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4PJQJ1v022490; Tue, 25 May 2004 21:26:19 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4PJQIeN022489; Tue, 25 May 2004 21:26:18 +0200 Date: Tue, 25 May 2004 21:26:18 +0200 From: Ralf Baechle To: Ratin Kumar Cc: linux-mips@linux-mips.org Subject: Re: Gnome/Mozilla on Malta Message-ID: <20040525192618.GB21912@linux-mips.org> References: <00b601c44289$09cfc2a0$6901a8c0@ratwin1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b601c44289$09cfc2a0$6901a8c0@ratwin1> User-Agent: Mutt/1.4.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: 5165 X-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 Content-Length: 1348 Lines: 40 On Tue, May 25, 2004 at 11:49:36AM -0700, Ratin Kumar wrote: > Has anyone tried building gnome and/or mozilla for Malta? Really, there's nothing Malta-specific in Gnome or Mozilla. > My target is RH7.3 port for mipsel with a matrox mill II PCI card in frame > buffer mode. > > > > I have tried native build of gnome and got quiet a few components going. > > > > I have also tried garnome with some success in getting a few components to > build but it failed with Nautilus. > > > > I have also tried KDE but for some odd reason it does not pick up my QT > installation during configure stage, even after I have set the > LD_LIBRARY_PATH... Take a look at what the configure script really does. Typically when something like this happens the config script is trying to link a library which fails because the library doesn't have the necessary DT_NEEDED entries due to yet other bugs or the symbol it is tested for doesn't exist in that particular version. Having the right compiler version is very important to get some gnome code to work. Even more so if it's written in C++ and for KDE code. You may want to check you're using the same versions as i.e. i386 was using for the same distribution. > Basically I want to have a browser running on RH installation. How about cheating, the Debian people got it working ;-) Ralf From yuasa@hh.iij4u.or.jp Wed May 26 16:50:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:50:37 +0100 (BST) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:39105 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:50:32 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA14192; Thu, 27 May 2004 00:50:28 +0900 (JST) Received: 4UMDO01 id i4QFoRu08866; Thu, 27 May 2004 00:50:27 +0900 (JST) Received: 4UMRO00 id i4QFoOV28687; Thu, 27 May 2004 00:50:25 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:50:22 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][1/14] vr41xx: change to early_initcall Message-Id: <20040527005022.53033dd4.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, The some functions change to early_initcall from the call from prom_init(). Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c --- linux-orig/arch/mips/vr41xx/common/bcu.c Tue Jan 13 08:21:05 2004 +++ linux/arch/mips/vr41xx/common/bcu.c Tue May 18 02:30:13 2004 @@ -1,34 +1,23 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/bcu.c + * bcu.c, Bus Control Unit routines for the NEC VR4100 series. * - * BRIEF MODULE DESCRIPTION - * Bus Control Unit routines for the NEC VR4100 series. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * Copyright (C) 2002 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2003-2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* * Changes: @@ -40,12 +29,16 @@ * - Added support for NEC VR4133. */ #include +#include #include #include #include #include +#define IO_MEM_RESOURCE_START 0UL +#define IO_MEM_RESOURCE_END 0x1fffffffUL + #define CLKSPEEDREG_TYPE1 KSEG1ADDR(0x0b000014) #define CLKSPEEDREG_TYPE2 KSEG1ADDR(0x0f000014) #define CLKSP(x) ((x) & 0x001f) @@ -213,7 +206,7 @@ return tclock; } -void __init vr41xx_bcu_init(void) +static int __init vr41xx_bcu_init(void) { unsigned long pclock; uint16_t clkspeed; @@ -223,4 +216,11 @@ pclock = calculate_pclock(clkspeed); vr41xx_vtclock = calculate_vtclock(clkspeed, pclock); vr41xx_tclock = calculate_tclock(clkspeed, pclock, vr41xx_vtclock); + + iomem_resource.start = IO_MEM_RESOURCE_START; + iomem_resource.end = IO_MEM_RESOURCE_END; + + return 0; } + +early_initcall(vr41xx_bcu_init); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c --- linux-orig/arch/mips/vr41xx/common/cmu.c Thu Feb 26 00:23:50 2004 +++ linux/arch/mips/vr41xx/common/cmu.c Tue May 18 02:30:13 2004 @@ -200,7 +200,7 @@ spin_unlock_irq(&cmu_lock); } -void __init vr41xx_cmu_init(void) +static int __init vr41xx_cmu_init(void) { switch (current_cpu_data.cputype) { case CPU_VR4111: @@ -223,4 +223,8 @@ cmuclkmsk = read_cmuclkmsk(); spin_lock_init(&cmu_lock); + + return 0; } + +early_initcall(vr41xx_cmu_init); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/init.c linux/arch/mips/vr41xx/common/init.c --- linux-orig/arch/mips/vr41xx/common/init.c Wed Feb 25 11:15:36 2004 +++ linux/arch/mips/vr41xx/common/init.c Tue May 18 02:30:13 2004 @@ -18,16 +18,9 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include #include #include -#include - -extern void vr41xx_bcu_init(void); -extern void vr41xx_cmu_init(void); -extern void vr41xx_pmu_init(void); -extern void vr41xx_rtc_init(void); void __init prom_init(void) { @@ -42,14 +35,6 @@ if (i < (argc - 1)) strcat(arcs_cmdline, " "); } - - iomem_resource.start = IO_MEM_RESOURCE_START; - iomem_resource.end = IO_MEM_RESOURCE_END; - - vr41xx_bcu_init(); - vr41xx_cmu_init(); - vr41xx_pmu_init(); - vr41xx_rtc_init(); } unsigned long __init prom_free_prom_memory (void) diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/pmu.c linux/arch/mips/vr41xx/common/pmu.c --- linux-orig/arch/mips/vr41xx/common/pmu.c Fri Feb 20 00:49:46 2004 +++ linux/arch/mips/vr41xx/common/pmu.c Tue May 18 02:30:13 2004 @@ -1,7 +1,7 @@ /* * pmu.c, Power Management Unit routines for NEC VR4100 series. * - * Copyright (C) 2003 Yoichi Yuasa + * Copyright (C) 2003-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -68,9 +68,13 @@ while (1) ; } -void __init vr41xx_pmu_init(void) +static int __init vr41xx_pmu_init(void) { _machine_restart = vr41xx_restart; _machine_halt = vr41xx_halt; _machine_power_off = vr41xx_power_off; + + return 0; } + +early_initcall(vr41xx_pmu_init); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/rtc.c linux/arch/mips/vr41xx/common/rtc.c --- linux-orig/arch/mips/vr41xx/common/rtc.c Thu Feb 26 00:23:50 2004 +++ linux/arch/mips/vr41xx/common/rtc.c Tue May 18 02:30:13 2004 @@ -1,7 +1,7 @@ /* * rtc.c, RTC(has only timer function) routines for NEC VR4100 series. * - * Copyright (C) 2003 Yoichi Yuasa + * Copyright (C) 2003-2004 Yoichi Yuasa * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by @@ -310,8 +310,12 @@ setup_irq(ELAPSEDTIME_IRQ, irq); } -void __init vr41xx_rtc_init(void) +static int __init vr41xx_rtc_init(void) { board_time_init = vr41xx_time_init; board_timer_setup = vr41xx_timer_setup; + + return 0; } + +early_initcall(vr41xx_rtc_init); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Tue May 18 02:28:47 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Tue May 18 02:30:13 2004 @@ -43,12 +43,6 @@ #define PRID_VR4133 0x00000c84 /* - * Memory resource - */ -#define IO_MEM_RESOURCE_START 0UL -#define IO_MEM_RESOURCE_END 0x1fffffffUL - -/* * Bus Control Uint */ extern unsigned long vr41xx_get_vtclock_frequency(void); From yuasa@hh.iij4u.or.jp Wed May 26 16:50:57 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:51:07 +0100 (BST) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:42945 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:50:42 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA14244; Thu, 27 May 2004 00:50:38 +0900 (JST) Received: 4UMDO00 id i4QFocQ29762; Thu, 27 May 2004 00:50:38 +0900 (JST) Received: 4UMRO00 id i4QFobV28700; Thu, 27 May 2004 00:50:37 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:50:35 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][2/14] vr41xx: GIUINT routines renewal Message-Id: <20040527005035.4ded334f.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, The GIUINT routine and ICU routines was renewed. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c --- linux-orig/arch/mips/vr41xx/common/giu.c Thu Feb 26 07:05:00 2004 +++ linux/arch/mips/vr41xx/common/giu.c Wed May 26 23:12:23 2004 @@ -28,10 +28,12 @@ * - Added support for NEC VR4133. * - Removed board_irq_init. */ +#include #include #include #include #include +#include #include #include @@ -64,6 +66,8 @@ #define read_giuint(offset) readw(giu_base + (offset)) #define write_giuint(val, offset) writew((val), giu_base + (offset)) +#define GIUINT_HIGH_OFFSET 16 + static inline uint16_t set_giuint(uint8_t offset, uint16_t set) { uint16_t res; @@ -86,35 +90,123 @@ return res; } -void vr41xx_enable_giuint(int pin) +static unsigned int startup_giuint_low_irq(unsigned int irq) { - if (pin < 16) - set_giuint(GIUINTENL, (uint16_t)1 << pin); - else - set_giuint(GIUINTENH, (uint16_t)1 << (pin - 16)); + unsigned int pin; + + pin = GIU_IRQ_TO_PIN(irq); + write_giuint((uint16_t)1 << pin, GIUINTSTATL); + set_giuint(GIUINTENL, (uint16_t)1 << pin); + + return 0; } -void vr41xx_disable_giuint(int pin) +static void shutdown_giuint_low_irq(unsigned int irq) { - if (pin < 16) - clear_giuint(GIUINTENL, (uint16_t)1 << pin); - else - clear_giuint(GIUINTENH, (uint16_t)1 << (pin - 16)); + clear_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq)); } -void vr41xx_clear_giuint(int pin) +static void enable_giuint_low_irq(unsigned int irq) { - if (pin < 16) - write_giuint((uint16_t)1 << pin, GIUINTSTATL); - else - write_giuint((uint16_t)1 << (pin - 16), GIUINTSTATH); + set_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq)); +} + +#define disable_giuint_low_irq shutdown_giuint_low_irq + +static void ack_giuint_low_irq(unsigned int irq) +{ + unsigned int pin; + + pin = GIU_IRQ_TO_PIN(irq); + clear_giuint(GIUINTENL, (uint16_t)1 << pin); + write_giuint((uint16_t)1 << pin, GIUINTSTATL); +} + +static void end_giuint_low_irq(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + set_giuint(GIUINTENL, (uint16_t)1 << GIU_IRQ_TO_PIN(irq)); +} + +static struct hw_interrupt_type giuint_low_irq_type = { + .typename = "GIUINTL", + .startup = startup_giuint_low_irq, + .shutdown = shutdown_giuint_low_irq, + .enable = enable_giuint_low_irq, + .disable = disable_giuint_low_irq, + .ack = ack_giuint_low_irq, + .end = end_giuint_low_irq, +}; + +static unsigned int startup_giuint_high_irq(unsigned int irq) +{ + unsigned int pin; + + pin = GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET); + write_giuint((uint16_t)1 << pin, GIUINTSTATH); + set_giuint(GIUINTENH, (uint16_t)1 << pin); + + return 0; +} + +static void shutdown_giuint_high_irq(unsigned int irq) +{ + clear_giuint(GIUINTENH, (uint16_t)1 << GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET)); +} + +static void enable_giuint_high_irq(unsigned int irq) +{ + set_giuint(GIUINTENH, (uint16_t)1 << GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET)); +} + +#define disable_giuint_high_irq shutdown_giuint_high_irq + +static void ack_giuint_high_irq(unsigned int irq) +{ + unsigned int pin; + + pin = GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET); + clear_giuint(GIUINTENH, (uint16_t)1 << pin); + write_giuint((uint16_t)1 << pin, GIUINTSTATH); +} + +static void end_giuint_high_irq(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + set_giuint(GIUINTENH, (uint16_t)1 << GIU_IRQ_TO_PIN(irq - GIUINT_HIGH_OFFSET)); +} + +static struct hw_interrupt_type giuint_high_irq_type = { + .typename = "GIUINTH", + .startup = startup_giuint_high_irq, + .shutdown = shutdown_giuint_high_irq, + .enable = enable_giuint_high_irq, + .disable = disable_giuint_high_irq, + .ack = ack_giuint_high_irq, + .end = end_giuint_high_irq, +}; + +static struct irqaction giu_cascade = {no_action, 0, 0, "cascade", NULL, NULL}; + +void __init init_vr41xx_giuint_irq(void) +{ + int i; + + for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) { + if (i < (GIU_IRQ_BASE + GIUINT_HIGH_OFFSET)) + irq_desc[i].handler = &giuint_low_irq_type; + else + irq_desc[i].handler = &giuint_high_irq_type; + } + + setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade); } void vr41xx_set_irq_trigger(int pin, int trigger, int hold) { uint16_t mask; - if (pin < 16) { + if (pin < GIUINT_HIGH_OFFSET) { mask = (uint16_t)1 << pin; if (trigger != TRIGGER_LEVEL) { set_giuint(GIUINTTYPL, mask); @@ -142,8 +234,9 @@ clear_giuint(GIUINTTYPL, mask); clear_giuint(GIUINTHTSELL, mask); } + write_giuint(mask, GIUINTSTATL); } else { - mask = (uint16_t)1 << (pin - 16); + mask = (uint16_t)1 << (pin - GIUINT_HIGH_OFFSET); if (trigger != TRIGGER_LEVEL) { set_giuint(GIUINTTYPH, mask); if (hold == SIGNAL_HOLD) @@ -170,32 +263,35 @@ clear_giuint(GIUINTTYPH, mask); clear_giuint(GIUINTHTSELH, mask); } + write_giuint(mask, GIUINTSTATH); } - - vr41xx_clear_giuint(pin); } +EXPORT_SYMBOL(vr41xx_set_irq_trigger); + void vr41xx_set_irq_level(int pin, int level) { uint16_t mask; - if (pin < 16) { + if (pin < GIUINT_HIGH_OFFSET) { mask = (uint16_t)1 << pin; if (level == LEVEL_HIGH) set_giuint(GIUINTALSELL, mask); else clear_giuint(GIUINTALSELL, mask); + write_giuint(mask, GIUINTSTATL); } else { - mask = (uint16_t)1 << (pin - 16); + mask = (uint16_t)1 << (pin - GIUINT_HIGH_OFFSET); if (level == LEVEL_HIGH) set_giuint(GIUINTALSELH, mask); else clear_giuint(GIUINTALSELH, mask); + write_giuint(mask, GIUINTSTATH); } - - vr41xx_clear_giuint(pin); } +EXPORT_SYMBOL(vr41xx_set_irq_level); + #define GIUINT_NR_IRQS 32 enum { @@ -209,7 +305,6 @@ }; static struct vr41xx_giuint_cascade giuint_cascade[GIUINT_NR_IRQS]; -static struct irqaction giu_cascade = {no_action, 0, 0, "cascade", NULL, NULL}; static int no_irq_number(int irq) { @@ -232,7 +327,7 @@ giuint_cascade[pin].get_irq_number = get_irq_number; retval = setup_irq(irq, &giu_cascade); - if (retval) { + if (retval != 0) { giuint_cascade[pin].flag = GIUINT_NO_CASCADE; giuint_cascade[pin].get_irq_number = no_irq_number; } @@ -240,29 +335,89 @@ return retval; } -unsigned int giuint_do_IRQ(int pin, struct pt_regs *regs) +EXPORT_SYMBOL(vr41xx_cascade_irq); + +static inline int get_irq_pin_number(void) +{ + uint16_t pendl, pendh, maskl, maskh; + int i; + + pendl = read_giuint(GIUINTSTATL); + pendh = read_giuint(GIUINTSTATH); + maskl = read_giuint(GIUINTENL); + maskh = read_giuint(GIUINTENH); + + maskl &= pendl; + maskh &= pendh; + + if (maskl) { + for (i = 0; i < 16; i++) { + if (maskl & ((uint16_t)1 << i)) + return i; + } + } else if (maskh) { + for (i = 0; i < 16; i++) { + if (maskh & ((uint16_t)1 << i)) + return i + GIUINT_HIGH_OFFSET; + } + } + + printk(KERN_ERR "spurious GIU interrupt: %04x(%04x),%04x(%04x)\n", + maskl, pendl, maskh, pendh); + + atomic_inc(&irq_err_count); + + return -1; +} + +static inline void ack_giuint_irq(int pin) +{ + if (pin < GIUINT_HIGH_OFFSET) { + clear_giuint(GIUINTENL, (uint16_t)1 << pin); + write_giuint((uint16_t)1 << pin, GIUINTSTATL); + } else { + pin -= GIUINT_HIGH_OFFSET; + clear_giuint(GIUINTENH, (uint16_t)1 << pin); + write_giuint((uint16_t)1 << pin, GIUINTSTATH); + } +} + +static inline void end_giuint_irq(int pin) +{ + if (pin < GIUINT_HIGH_OFFSET) + set_giuint(GIUINTENL, (uint16_t)1 << pin); + else + set_giuint(GIUINTENH, (uint16_t)1 << (pin - GIUINT_HIGH_OFFSET)); +} + +void giuint_irq_dispatch(struct pt_regs *regs) { struct vr41xx_giuint_cascade *cascade; - unsigned int retval = 0; - int giuint_irq, cascade_irq; + unsigned int giuint_irq; + int pin; + + pin = get_irq_pin_number(); + if (pin < 0) + return; disable_irq(GIUINT_CASCADE_IRQ); + cascade = &giuint_cascade[pin]; giuint_irq = GIU_IRQ(pin); if (cascade->flag == GIUINT_CASCADE) { - cascade_irq = cascade->get_irq_number(giuint_irq); - disable_irq(giuint_irq); - if (cascade_irq > 0) - retval = do_IRQ(cascade_irq, regs); - enable_irq(giuint_irq); - } else - retval = do_IRQ(giuint_irq, regs); - enable_irq(GIUINT_CASCADE_IRQ); + int irq = cascade->get_irq_number(giuint_irq); + ack_giuint_irq(pin); + if (irq >= 0) + do_IRQ(irq, regs); + end_giuint_irq(pin); + } else { + do_IRQ(giuint_irq, regs); + } - return retval; + enable_irq(GIUINT_CASCADE_IRQ); } -void __init vr41xx_giuint_init(void) +static int __init vr41xx_giu_init(void) { int i; @@ -277,16 +432,20 @@ giu_base = GIUIOSELL_TYPE2; break; default: - panic("GIU: Unexpected CPU of NEC VR4100 series"); - break; + printk(KERN_ERR "GIU: Unexpected CPU of NEC VR4100 series\n"); + return -EINVAL; } for (i = 0; i < GIUINT_NR_IRQS; i++) { - vr41xx_disable_giuint(i); + if (i < GIUINT_HIGH_OFFSET) + clear_giuint(GIUINTENL, (uint16_t)1 << i); + else + clear_giuint(GIUINTENH, (uint16_t)1 << (i - GIUINT_HIGH_OFFSET)); giuint_cascade[i].flag = GIUINT_NO_CASCADE; giuint_cascade[i].get_irq_number = no_irq_number; } - if (setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade)) - printk("GIUINT: Can not cascade IRQ %d.\n", GIUINT_CASCADE_IRQ); + return 0; } + +early_initcall(vr41xx_giu_init); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c --- linux-orig/arch/mips/vr41xx/common/icu.c Thu Apr 29 10:42:48 2004 +++ linux/arch/mips/vr41xx/common/icu.c Wed May 26 23:12:23 2004 @@ -28,10 +28,12 @@ * Yoichi Yuasa * - Coped with INTASSIGN of NEC VR4133. */ +#include #include #include #include #include +#include #include #include @@ -43,11 +45,8 @@ extern asmlinkage void vr41xx_handle_interrupt(void); -extern void vr41xx_giuint_init(void); -extern void vr41xx_enable_giuint(int pin); -extern void vr41xx_disable_giuint(int pin); -extern void vr41xx_clear_giuint(int pin); -extern unsigned int giuint_do_IRQ(int pin, struct pt_regs *regs); +extern void init_vr41xx_giuint_irq(void); +extern void giuint_irq_dispatch(struct pt_regs *regs); static uint32_t icu1_base; static uint32_t icu2_base; @@ -64,11 +63,17 @@ #define SYSINT2REG_TYPE2 KSEG1ADDR(0x0f0000a0) #define SYSINT1REG 0x00 +#define PIUINTREG 0x02 #define INTASSIGN0 0x04 #define INTASSIGN1 0x06 #define GIUINTLREG 0x08 +#define DSIUINTREG 0x0a #define MSYSINT1REG 0x0c +#define MPIUINTREG 0x0e +#define MAIUINTREG 0x10 +#define MKIUINTREG 0x12 #define MGIUINTLREG 0x14 +#define MDSIUINTREG 0x16 #define NMIREG 0x18 #define SOFTREG 0x1a #define INTASSIGN2 0x1c @@ -76,11 +81,21 @@ #define SYSINT2REG 0x00 #define GIUINTHREG 0x02 +#define FIRINTREG 0x04 #define MSYSINT2REG 0x06 #define MGIUINTHREG 0x08 - -#define MDSIUINTREG KSEG1ADDR(0x0f000096) - #define INTDSIU 0x0800 +#define MFIRINTREG 0x0a +#define PCIINTREG 0x0c + #define PCIINT0 0x0001 +#define SCUINTREG 0x0e + #define SCUINT0 0x0001 +#define CSIINTREG 0x10 +#define MPCIINTREG 0x12 +#define MSCUINTREG 0x14 +#define MCSIINTREG 0x16 +#define BCUINTREG 0x18 + #define BCUINTR 0x0001 +#define MBCUINTREG 0x1a #define SYSINT1_IRQ_TO_PIN(x) ((x) - SYSINT1_IRQ_BASE) /* Pin 0-15 */ #define SYSINT2_IRQ_TO_PIN(x) ((x) - SYSINT2_IRQ_BASE) /* Pin 0-15 */ @@ -140,212 +155,298 @@ /*=======================================================================*/ -void vr41xx_enable_dsiuint(void) +void vr41xx_enable_piuint(uint16_t mask) { - writew(INTDSIU, MDSIUINTREG); + irq_desc_t *desc = irq_desc + PIU_IRQ; + unsigned long flags; + uint16_t val; + + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MPIUINTREG); + val |= mask; + write_icu1(val, MPIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -void vr41xx_disable_dsiuint(void) +void vr41xx_disable_piuint(uint16_t mask) { - writew(0, MDSIUINTREG); + irq_desc_t *desc = irq_desc + PIU_IRQ; + unsigned long flags; + uint16_t val; + + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MPIUINTREG); + val &= ~mask; + write_icu1(val, MPIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -/*=======================================================================*/ +void vr41xx_enable_aiuint(uint16_t mask) +{ + irq_desc_t *desc = irq_desc + AIU_IRQ; + unsigned long flags; + uint16_t val; -static void enable_sysint1_irq(unsigned int irq) + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MAIUINTREG); + val |= mask; + write_icu1(val, MAIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); +} + +void vr41xx_disable_aiuint(uint16_t mask) { - set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + AIU_IRQ; + unsigned long flags; + uint16_t val; + + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MAIUINTREG); + val &= ~mask; + write_icu1(val, MAIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static void disable_sysint1_irq(unsigned int irq) +void vr41xx_enable_kiuint(uint16_t mask) { - clear_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + KIU_IRQ; + unsigned long flags; + uint16_t val; + + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MKIUINTREG); + val |= mask; + write_icu1(val, MKIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static unsigned int startup_sysint1_irq(unsigned int irq) +void vr41xx_disable_kiuint(uint16_t mask) { - set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + KIU_IRQ; + unsigned long flags; + uint16_t val; - return 0; /* never anything pending */ + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MKIUINTREG); + val &= ~mask; + write_icu1(val, MKIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -#define shutdown_sysint1_irq disable_sysint1_irq -#define ack_sysint1_irq disable_sysint1_irq +void vr41xx_enable_dsiuint(uint16_t mask) +{ + irq_desc_t *desc = irq_desc + DSIU_IRQ; + unsigned long flags; + uint16_t val; -static void end_sysint1_irq(unsigned int irq) + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MDSIUINTREG); + val |= mask; + write_icu1(val, MDSIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); +} + +void vr41xx_disable_dsiuint(uint16_t mask) { - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + DSIU_IRQ; + unsigned long flags; + uint16_t val; + + spin_lock_irqsave(&desc->lock, flags); + val = read_icu1(MDSIUINTREG); + val &= ~mask; + write_icu1(val, MDSIUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static struct hw_interrupt_type sysint1_irq_type = { - .typename = "SYSINT1", - .startup = startup_sysint1_irq, - .shutdown = shutdown_sysint1_irq, - .enable = enable_sysint1_irq, - .disable = disable_sysint1_irq, - .ack = ack_sysint1_irq, - .end = end_sysint1_irq, -}; +void vr41xx_enable_firint(uint16_t mask) +{ + irq_desc_t *desc = irq_desc + FIR_IRQ; + unsigned long flags; + uint16_t val; -/*=======================================================================*/ + spin_lock_irqsave(&desc->lock, flags); + val = read_icu2(MFIRINTREG); + val |= mask; + write_icu2(val, MFIRINTREG); + spin_unlock_irqrestore(&desc->lock, flags); +} -static void enable_sysint2_irq(unsigned int irq) +void vr41xx_disable_firint(uint16_t mask) { - set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + FIR_IRQ; + unsigned long flags; + uint16_t val; + + spin_lock_irqsave(&desc->lock, flags); + val = read_icu2(MFIRINTREG); + val &= ~mask; + write_icu2(val, MFIRINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static void disable_sysint2_irq(unsigned int irq) +void vr41xx_enable_pciint(void) { - clear_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + PCI_IRQ; + unsigned long flags; + + spin_lock_irqsave(&desc->lock, flags); + write_icu2(PCIINT0, MPCIINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static unsigned int startup_sysint2_irq(unsigned int irq) +void vr41xx_disable_pciint(void) { - set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + PCI_IRQ; + unsigned long flags; - return 0; /* never anything pending */ + spin_lock_irqsave(&desc->lock, flags); + write_icu2(0, MPCIINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -#define shutdown_sysint2_irq disable_sysint2_irq -#define ack_sysint2_irq disable_sysint2_irq +void vr41xx_enable_scuint(void) +{ + irq_desc_t *desc = irq_desc + SCU_IRQ; + unsigned long flags; -static void end_sysint2_irq(unsigned int irq) + spin_lock_irqsave(&desc->lock, flags); + write_icu2(SCUINT0, MSCUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); +} + +void vr41xx_disable_scuint(void) { - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + SCU_IRQ; + unsigned long flags; + + spin_lock_irqsave(&desc->lock, flags); + write_icu2(0, MSCUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static struct hw_interrupt_type sysint2_irq_type = { - .typename = "SYSINT2", - .startup = startup_sysint2_irq, - .shutdown = shutdown_sysint2_irq, - .enable = enable_sysint2_irq, - .disable = disable_sysint2_irq, - .ack = ack_sysint2_irq, - .end = end_sysint2_irq, -}; +void vr41xx_enable_csiint(uint16_t mask) +{ + irq_desc_t *desc = irq_desc + CSI_IRQ; + unsigned long flags; + uint16_t val; -/*=======================================================================*/ + spin_lock_irqsave(&desc->lock, flags); + val = read_icu2(MCSIINTREG); + val |= mask; + write_icu2(val, MCSIINTREG); + spin_unlock_irqrestore(&desc->lock, flags); +} -static void enable_giuint_irq(unsigned int irq) +void vr41xx_disable_csiint(uint16_t mask) { - int pin; + irq_desc_t *desc = irq_desc + CSI_IRQ; + unsigned long flags; + uint16_t val; - pin = GIU_IRQ_TO_PIN(irq); - if (pin < 16) - set_icu1(MGIUINTLREG, (uint16_t)1 << pin); - else - set_icu2(MGIUINTHREG, (uint16_t)1 << (pin - 16)); - vr41xx_enable_giuint(pin); + spin_lock_irqsave(&desc->lock, flags); + val = read_icu2(MCSIINTREG); + val &= ~mask; + write_icu2(val, MCSIINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static void disable_giuint_irq(unsigned int irq) +void vr41xx_enable_bcuint(void) { - int pin; + irq_desc_t *desc = irq_desc + BCU_IRQ; + unsigned long flags; - pin = GIU_IRQ_TO_PIN(irq); - vr41xx_disable_giuint(pin); - if (pin < 16) - clear_icu1(MGIUINTLREG, (uint16_t)1 << pin); - else - clear_icu2(MGIUINTHREG, (uint16_t)1 << (pin - 16)); + spin_lock_irqsave(&desc->lock, flags); + write_icu2(BCUINTR, MBCUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); } -static unsigned int startup_giuint_irq(unsigned int irq) +void vr41xx_disable_bcuint(void) { - vr41xx_clear_giuint(GIU_IRQ_TO_PIN(irq)); + irq_desc_t *desc = irq_desc + BCU_IRQ; + unsigned long flags; - enable_giuint_irq(irq); + spin_lock_irqsave(&desc->lock, flags); + write_icu2(0, MBCUINTREG); + spin_unlock_irqrestore(&desc->lock, flags); +} + +/*=======================================================================*/ + +static unsigned int startup_sysint1_irq(unsigned int irq) +{ + set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); return 0; /* never anything pending */ } -#define shutdown_giuint_irq disable_giuint_irq - -static void ack_giuint_irq(unsigned int irq) +static void shutdown_sysint1_irq(unsigned int irq) { - disable_giuint_irq(irq); + clear_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); +} - vr41xx_clear_giuint(GIU_IRQ_TO_PIN(irq)); +static void enable_sysint1_irq(unsigned int irq) +{ + set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); } -static void end_giuint_irq(unsigned int irq) +#define disable_sysint1_irq shutdown_sysint1_irq +#define ack_sysint1_irq shutdown_sysint1_irq + +static void end_sysint1_irq(unsigned int irq) { if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - enable_giuint_irq(irq); + set_icu1(MSYSINT1REG, (uint16_t)1 << SYSINT1_IRQ_TO_PIN(irq)); } -static struct hw_interrupt_type giuint_irq_type = { - .typename = "GIUINT", - .startup = startup_giuint_irq, - .shutdown = shutdown_giuint_irq, - .enable = enable_giuint_irq, - .disable = disable_giuint_irq, - .ack = ack_giuint_irq, - .end = end_giuint_irq, +static struct hw_interrupt_type sysint1_irq_type = { + .typename = "SYSINT1", + .startup = startup_sysint1_irq, + .shutdown = shutdown_sysint1_irq, + .enable = enable_sysint1_irq, + .disable = disable_sysint1_irq, + .ack = ack_sysint1_irq, + .end = end_sysint1_irq, }; /*=======================================================================*/ -static struct irqaction icu_cascade = {no_action, 0, 0, "cascade", NULL, NULL}; - -static void __init vr41xx_icu_init(void) +static unsigned int startup_sysint2_irq(unsigned int irq) { - int i; - - switch (current_cpu_data.cputype) { - case CPU_VR4111: - case CPU_VR4121: - icu1_base = SYSINT1REG_TYPE1; - icu2_base = SYSINT2REG_TYPE1; - break; - case CPU_VR4122: - case CPU_VR4131: - case CPU_VR4133: - icu1_base = SYSINT1REG_TYPE2; - icu2_base = SYSINT2REG_TYPE2; - break; - default: - panic("Unexpected CPU of NEC VR4100 series"); - break; - } - - write_icu1(0, MSYSINT1REG); - write_icu1(0, MGIUINTLREG); - - write_icu2(0, MSYSINT2REG); - write_icu2(0, MGIUINTHREG); - - for (i = SYSINT1_IRQ_BASE; i <= GIU_IRQ_LAST; i++) { - if (i >= SYSINT1_IRQ_BASE && i <= SYSINT1_IRQ_LAST) - irq_desc[i].handler = &sysint1_irq_type; - else if (i >= SYSINT2_IRQ_BASE && i <= SYSINT2_IRQ_LAST) - irq_desc[i].handler = &sysint2_irq_type; - else if (i >= GIU_IRQ_BASE && i <= GIU_IRQ_LAST) - irq_desc[i].handler = &giuint_irq_type; - } + set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); - setup_irq(INT0_CASCADE_IRQ, &icu_cascade); - setup_irq(INT1_CASCADE_IRQ, &icu_cascade); - setup_irq(INT2_CASCADE_IRQ, &icu_cascade); - setup_irq(INT3_CASCADE_IRQ, &icu_cascade); - setup_irq(INT4_CASCADE_IRQ, &icu_cascade); + return 0; /* never anything pending */ } -void __init init_IRQ(void) +static void shutdown_sysint2_irq(unsigned int irq) { - memset(irq_desc, 0, sizeof(irq_desc)); + clear_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); +} - init_generic_irq(); - mips_cpu_irq_init(MIPS_CPU_IRQ_BASE); - vr41xx_icu_init(); +static void enable_sysint2_irq(unsigned int irq) +{ + set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); +} - vr41xx_giuint_init(); +#define disable_sysint2_irq shutdown_sysint2_irq +#define ack_sysint2_irq shutdown_sysint2_irq - set_except_vector(0, vr41xx_handle_interrupt); +static void end_sysint2_irq(unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) + set_icu2(MSYSINT2REG, (uint16_t)1 << SYSINT2_IRQ_TO_PIN(irq)); } +static struct hw_interrupt_type sysint2_irq_type = { + .typename = "SYSINT2", + .startup = startup_sysint2_irq, + .shutdown = shutdown_sysint2_irq, + .enable = enable_sysint2_irq, + .disable = disable_sysint2_irq, + .ack = ack_sysint2_irq, + .end = end_sysint2_irq, +}; + /*=======================================================================*/ static inline int set_sysint1_assign(unsigned int irq, unsigned char assign) @@ -492,34 +593,14 @@ return retval; } -/*=======================================================================*/ +EXPORT_SYMBOL(vr41xx_set_intassign); -static inline void giuint_irq_dispatch(uint16_t pendl, uint16_t pendh, - struct pt_regs *regs) -{ - int i; - - if (pendl) { - for (i = 0; i < 16; i++) { - if (pendl & ((uint16_t)1 << i)) { - giuint_do_IRQ(i, regs); - return; - } - } - } else { - for (i = 0; i < 16; i++) { - if (pendh & ((uint16_t)1 << i)) { - giuint_do_IRQ(i + 16, regs); - return; - } - } - } -} +/*=======================================================================*/ asmlinkage void irq_dispatch(unsigned char intnum, struct pt_regs *regs) { - uint16_t pend1, pend2, pendl, pendh; - uint16_t mask1, mask2, maskl, maskh; + uint16_t pend1, pend2; + uint16_t mask1, mask2; int i; pend1 = read_icu1(SYSINT1REG); @@ -528,28 +609,18 @@ pend2 = read_icu2(SYSINT2REG); mask2 = read_icu2(MSYSINT2REG); - pendl = read_icu1(GIUINTLREG); - maskl = read_icu1(MGIUINTLREG); - - pendh = read_icu2(GIUINTHREG); - maskh = read_icu2(MGIUINTHREG); - mask1 &= pend1; mask2 &= pend2; - maskl &= pendl; - maskh &= pendh; if (mask1) { for (i = 0; i < 16; i++) { if (intnum == sysint1_assign[i] && (mask1 & ((uint16_t)1 << i))) { - if (i == 8 && (maskl | maskh)) { - giuint_irq_dispatch(maskl, maskh, regs); - return; - } else { + if (i == 8) + giuint_irq_dispatch(regs); + else do_IRQ(SYSINT1_IRQ(i), regs); - return; - } + return; } } } @@ -564,6 +635,72 @@ } } - printk(KERN_ERR "spurious interrupt: %04x,%04x,%04x,%04x\n", pend1, pend2, pendl, pendh); + printk(KERN_ERR "spurious ICU interrupt: %04x,%04x\n", pend1, pend2); + atomic_inc(&irq_err_count); +} + +/*=======================================================================*/ + +static int __init vr41xx_icu_init(void) +{ + switch (current_cpu_data.cputype) { + case CPU_VR4111: + case CPU_VR4121: + icu1_base = SYSINT1REG_TYPE1; + icu2_base = SYSINT2REG_TYPE1; + break; + case CPU_VR4122: + case CPU_VR4131: + case CPU_VR4133: + icu1_base = SYSINT1REG_TYPE2; + icu2_base = SYSINT2REG_TYPE2; + break; + default: + printk(KERN_ERR "ICU: Unexpected CPU of NEC VR4100 series\n"); + return -EINVAL; + } + + write_icu1(0, MSYSINT1REG); + write_icu1(0xffff, MGIUINTLREG); + + write_icu2(0, MSYSINT2REG); + write_icu2(0xffff, MGIUINTHREG); + + return 0; +} + +early_initcall(vr41xx_icu_init); + +/*=======================================================================*/ + +static struct irqaction icu_cascade = {no_action, 0, 0, "cascade", NULL, NULL}; + +static inline void init_vr41xx_icu_irq(void) +{ + int i; + + for (i = SYSINT1_IRQ_BASE; i <= SYSINT1_IRQ_LAST; i++) + irq_desc[i].handler = &sysint1_irq_type; + + for (i = SYSINT2_IRQ_BASE; i <= SYSINT2_IRQ_LAST; i++) + irq_desc[i].handler = &sysint2_irq_type; + + setup_irq(INT0_CASCADE_IRQ, &icu_cascade); + setup_irq(INT1_CASCADE_IRQ, &icu_cascade); + setup_irq(INT2_CASCADE_IRQ, &icu_cascade); + setup_irq(INT3_CASCADE_IRQ, &icu_cascade); + setup_irq(INT4_CASCADE_IRQ, &icu_cascade); +} + +void __init init_IRQ(void) +{ + memset(irq_desc, 0, sizeof(irq_desc)); + + init_generic_irq(); + mips_cpu_irq_init(MIPS_CPU_IRQ_BASE); + init_vr41xx_icu_irq(); + init_vr41xx_giuint_irq(); + + set_except_vector(0, vr41xx_handle_interrupt); } diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/ksyms.c linux/arch/mips/vr41xx/common/ksyms.c --- linux-orig/arch/mips/vr41xx/common/ksyms.c Thu Dec 18 01:02:24 2003 +++ linux/arch/mips/vr41xx/common/ksyms.c Wed May 26 23:12:23 2004 @@ -25,8 +25,6 @@ EXPORT_SYMBOL(vr41xx_get_vtclock_frequency); EXPORT_SYMBOL(vr41xx_get_tclock_frequency); -EXPORT_SYMBOL(vr41xx_set_intassign); - EXPORT_SYMBOL(vr41xx_set_rtclong1_cycle); EXPORT_SYMBOL(vr41xx_read_rtclong1_counter); EXPORT_SYMBOL(vr41xx_set_rtclong2_cycle); diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c --- linux-orig/arch/mips/vr41xx/common/serial.c Thu Apr 29 10:42:48 2004 +++ linux/arch/mips/vr41xx/common/serial.c Wed May 26 23:12:23 2004 @@ -168,7 +168,7 @@ if (port.membase != NULL) { if (early_serial_setup(&port) == 0) { vr41xx_supply_clock(DSIU_CLOCK); - vr41xx_enable_dsiuint(); + vr41xx_enable_dsiuint(DSIUINT_ALL); vr41xx_serial_ports++; return; } diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h Wed May 26 23:22:41 2004 +++ linux/include/asm-mips/vr41xx/vr41xx.h Wed May 26 23:12:23 2004 @@ -130,8 +130,71 @@ extern int vr41xx_set_intassign(unsigned int irq, unsigned char intassign); extern int vr41xx_cascade_irq(unsigned int irq, int (*get_irq_number)(int irq)); -extern void vr41xx_enable_dsiuint(void); -extern void vr41xx_disable_dsiuint(void); +#define PIUINT_COMMAND 0x0040 +#define PIUINT_DATA 0x0020 +#define PIUINT_PAGE1 0x0010 +#define PIUINT_PAGE0 0x0008 +#define PIUINT_DATALOST 0x0004 +#define PIUINT_STATUSCHANGE 0x0001 + +extern void vr41xx_enable_piuint(uint16_t mask); +extern void vr41xx_disable_piuint(uint16_t mask); + +#define AIUINT_INPUT_DMAEND 0x0800 +#define AIUINT_INPUT_DMAHALT 0x0400 +#define AIUINT_INPUT_DATALOST 0x0200 +#define AIUINT_INPUT_DATA 0x0100 +#define AIUINT_OUTPUT_DMAEND 0x0008 +#define AIUINT_OUTPUT_DMAHALT 0x0004 +#define AIUINT_OUTPUT_NODATA 0x0002 + +extern void vr41xx_enable_aiuint(uint16_t mask); +extern void vr41xx_disable_aiuint(uint16_t mask); + +#define KIUINT_DATALOST 0x0004 +#define KIUINT_DATAREADY 0x0002 +#define KIUINT_SCAN 0x0001 + +extern void vr41xx_enable_kiuint(uint16_t mask); +extern void vr41xx_disable_kiuint(uint16_t mask); + +#define DSIUINT_CTS 0x0800 +#define DSIUINT_RXERR 0x0400 +#define DSIUINT_RX 0x0200 +#define DSIUINT_TX 0x0100 +#define DSIUINT_ALL 0x0f00 + +extern void vr41xx_enable_dsiuint(uint16_t mask); +extern void vr41xx_disable_dsiuint(uint16_t mask); + +#define FIRINT_UNIT 0x0010 +#define FIRINT_RX_DMAEND 0x0008 +#define FIRINT_RX_DMAHALT 0x0004 +#define FIRINT_TX_DMAEND 0x0002 +#define FIRINT_TX_DMAHALT 0x0001 + +extern void vr41xx_enable_firint(uint16_t mask); +extern void vr41xx_disable_firint(uint16_t mask); + +extern void vr41xx_enable_pciint(void); +extern void vr41xx_disable_pciint(void); + +extern void vr41xx_enable_scuint(void); +extern void vr41xx_disable_scuint(void); + +#define CSIINT_TX_DMAEND 0x0040 +#define CSIINT_TX_DMAHALT 0x0020 +#define CSIINT_TX_DATA 0x0010 +#define CSIINT_TX_FIFOEMPTY 0x0008 +#define CSIINT_RX_DMAEND 0x0004 +#define CSIINT_RX_DMAHALT 0x0002 +#define CSIINT_RX_FIFOEMPTY 0x0001 + +extern void vr41xx_enable_csiint(uint16_t mask); +extern void vr41xx_disable_csiint(uint16_t mask); + +extern void vr41xx_enable_bcuint(void); +extern void vr41xx_disable_bcuint(void); /* * Power Management Unit From yuasa@hh.iij4u.or.jp Wed May 26 16:51:26 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:51:39 +0100 (BST) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:46273 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:50:50 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA14287; Thu, 27 May 2004 00:50:47 +0900 (JST) Received: 4UMDO01 id i4QFolu08918; Thu, 27 May 2004 00:50:47 +0900 (JST) Received: 4UMRO00 id i4QFokV28708; Thu, 27 May 2004 00:50:46 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:50:44 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] [3/14] vr41xx: update fixup-eagle.c Message-Id: <20040527005044.19dedf25.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, fixup-eagle.c was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile --- linux-orig/arch/mips/pci/Makefile Tue May 11 00:48:23 2004 +++ linux/arch/mips/pci/Makefile Wed May 12 22:06:52 2004 @@ -38,7 +38,7 @@ obj-$(CONFIG_MOMENCO_OCELOT) += fixup-ocelot.o pci-ocelot.o obj-$(CONFIG_MOMENCO_OCELOT_C) += fixup-ocelot-c.o pci-ocelot-c.o obj-$(CONFIG_MOMENCO_OCELOT_G) += fixup-ocelot-g.o ops-gt64240.o pci-ocelot-g.o -obj-$(CONFIG_NEC_EAGLE) += fixup-eagle.o ops-vrc4173.o +obj-$(CONFIG_NEC_EAGLE) += fixup-eagle.o obj-$(CONFIG_PMC_YOSEMITE) += fixup-yosemite.o ops-titan.o ops-titan-ht.o obj-$(CONFIG_SGI_IP27) += pci-ip27.o obj-$(CONFIG_SGI_IP32) += fixup-ip32.o ops-mace.o pci-ip32.o diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-eagle.c linux/arch/mips/pci/fixup-eagle.c --- linux-orig/arch/mips/pci/fixup-eagle.c Fri Feb 20 00:49:46 2004 +++ linux/arch/mips/pci/fixup-eagle.c Wed May 12 22:06:52 2004 @@ -1,15 +1,25 @@ /* - * arch/mips/vr41xx/nec-eagle/pci_fixup.c + * fixup-eagle.c, The NEC Eagle/Hawk Board specific PCI fixups. * - * The NEC Eagle/Hawk Board specific PCI fixups. + * Copyright (C) 2001-2002,2004 MontaVista Software, Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa * - * Author: Yoichi Yuasa + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * 2001-2002,2004 (c) MontaVista, Software, Inc. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include #include #include @@ -29,13 +39,13 @@ #define SLOT PCISLOT_IRQ static char irq_tab_eagle[][5] __initdata = { - [ 8] = { 0, INTA, INTB, INTC, INTD }, - [ 9] = { 0, INTD, INTA, INTB, INTC }, - [10] = { 0, INTC, INTD, INTA, INTB }, - [12] = { 0, PCMCIA1, 0, 0, 0 }, - [13] = { 0, PCMCIA2, 0, 0, 0 }, - [28] = { 0, LAN, 0, 0, 0 }, - [29] = { 0, SLOT, INTB, INTC, INTD }, + [ 8] = { -1, INTA, INTB, INTC, INTD }, + [ 9] = { -1, INTD, INTA, INTB, INTC }, + [10] = { -1, INTC, INTD, INTA, INTB }, + [12] = { -1, PCMCIA1, -1, -1, -1 }, + [13] = { -1, PCMCIA2, -1, -1, -1 }, + [28] = { -1, LAN, LAN, LAN, LAN }, + [29] = { -1, SLOT, INTB, INTC, INTD }, }; /* @@ -58,3 +68,97 @@ struct pci_fixup pcibios_fixups[] __initdata = { { .pass = 0, }, }; + +#ifdef CONFIG_VRC4173 +/* + * PCI configuration registers + */ +#define PCICONFAREG KSEG1ADDR(0x0f000c18) +#define PCICONFDREG KSEG1ADDR(0x0f000c14) + +static inline void pci_config_write_byte(u8 reg, u8 val) +{ + u32 data; + int shift; + + writel((1UL << 0x1e) | (reg & 0xfc), PCICONFAREG); + data = readl(PCICONFDREG); + + shift = (reg & 3) << 3; + data &= ~(0xff << shift); + data |= (((u32) val) << shift); + + writel(data, PCICONFDREG); +} + +static inline u16 pci_config_read_halfword(u8 reg) +{ + u32 data; + + writel(((1UL << 30) | (reg & 0xfc)), PCICONFAREG); + data = readl(PCICONFDREG); + + return (u16) (data >> ((reg & 2) << 3)); +} + +static inline u32 pci_config_read_word(u8 reg) +{ + writel(((1UL << 30) | (reg & 0xfc)), PCICONFAREG); + + return readl(PCICONFDREG); +} + +static inline void pci_config_write_word(u8 reg, u32 val) +{ + writel((1UL << 0x1e) | (reg & 0xfc), PCICONFAREG); + writel(val, PCICONFDREG); +} + +/* + * Pre-fixup for AC97U/CARDU/USBU of VRC4173 + */ +static int __init vrc4173_prefixup(void) +{ + u32 cmdsts, base; + u16 cmu_mask; + + + if ((pci_config_read_halfword(PCI_VENDOR_ID) == PCI_VENDOR_ID_NEC) && + (pci_config_read_halfword(PCI_DEVICE_ID) == PCI_DEVICE_ID_NEC_VRC4173)) { + /* + * Initialized NEC VRC4173 Bus Control Unit + */ + cmdsts = pci_config_read_word(PCI_COMMAND); + pci_config_write_word(PCI_COMMAND, + cmdsts | PCI_COMMAND_IO | + PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); + + pci_config_write_byte(PCI_LATENCY_TIMER, 0x80); + + pci_config_write_word(PCI_BASE_ADDRESS_0, VR41XX_PCI_IO_START); + base = pci_config_read_word(PCI_BASE_ADDRESS_0); + base &= PCI_BASE_ADDRESS_IO_MASK; + pci_config_write_byte(0x40, 0x01); + + /* CARDU1 IDSEL = AD12, CARDU2 IDSEL = AD13 */ + pci_config_write_byte(0x41, 0); + + cmu_mask = 0x1000; + outw(cmu_mask, base + 0x040); + cmu_mask |= 0x0800; + outw(cmu_mask, base + 0x040); + + outw(0x000f, base + 0x042); /* Soft reset of CMU */ + cmu_mask |= 0x05e0; + outw(cmu_mask, base + 0x040); + cmu_mask = inw(base + 0x040); /* dummy read */ + outw(0x0000, base + 0x042); + + return 0; + } + + return -ENODEV; +} + +early_initcall(vrc4173_prefixup); +#endif diff -urN -X dontdiff linux-orig/arch/mips/pci/ops-vrc4173.c linux/arch/mips/pci/ops-vrc4173.c --- linux-orig/arch/mips/pci/ops-vrc4173.c Fri Jun 13 23:19:56 2003 +++ linux/arch/mips/pci/ops-vrc4173.c Thu Jan 1 09:00:00 1970 @@ -1,120 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/nec-eagle/vrc4173.c - * - * BRIEF MODULE DESCRIPTION - * Pre-setup for NEC VRC4173. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2001,2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ -#include -#include -#include - -#include -#include -#include - -#define PCI_CONFIG_ADDR KSEG1ADDR(0x0f000c18) -#define PCI_CONFIG_DATA KSEG1ADDR(0x0f000c14) - -static inline void config_writeb(u8 reg, u8 val) -{ - u32 data; - int shift; - - writel((1UL << 0x1e) | (reg & 0xfc), PCI_CONFIG_ADDR); - data = readl(PCI_CONFIG_DATA); - - shift = (reg & 3) << 3; - data &= ~(0xff << shift); - data |= (((u32) val) << shift); - - writel(data, PCI_CONFIG_DATA); -} - -static inline u16 config_readw(u8 reg) -{ - u32 data; - - writel(((1UL << 30) | (reg & 0xfc)), PCI_CONFIG_ADDR); - data = readl(PCI_CONFIG_DATA); - - return (u16) (data >> ((reg & 2) << 3)); -} - -static inline u32 config_readl(u8 reg) -{ - writel(((1UL << 30) | (reg & 0xfc)), PCI_CONFIG_ADDR); - - return readl(PCI_CONFIG_DATA); -} - -static inline void config_writel(u8 reg, u32 val) -{ - writel((1UL << 0x1e) | (reg & 0xfc), PCI_CONFIG_ADDR); - writel(val, PCI_CONFIG_DATA); -} - -void __init vrc4173_preinit(void) -{ - u32 cmdsts, base; - u16 cmu_mask; - - - if ((config_readw(PCI_VENDOR_ID) == PCI_VENDOR_ID_NEC) && - (config_readw(PCI_DEVICE_ID) == PCI_DEVICE_ID_NEC_VRC4173)) { - /* - * Initialized NEC VRC4173 Bus Control Unit - */ - cmdsts = config_readl(PCI_COMMAND); - config_writel(PCI_COMMAND, - cmdsts | - PCI_COMMAND_IO | - PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - - config_writeb(PCI_LATENCY_TIMER, 0x80); - - config_writel(PCI_BASE_ADDRESS_0, VR41XX_PCI_IO_START); - base = config_readl(PCI_BASE_ADDRESS_0); - base &= PCI_BASE_ADDRESS_IO_MASK; - config_writeb(0x40, 0x01); - - /* CARDU1 IDSEL = AD12, CARDU2 IDSEL = AD13 */ - config_writeb(0x41, 0); - - cmu_mask = 0x1000; - outw(cmu_mask, base + 0x040); - cmu_mask |= 0x0800; - outw(cmu_mask, base + 0x040); - - outw(0x000f, base + 0x042); /* Soft reset of CMU */ - cmu_mask |= 0x05e0; - outw(cmu_mask, base + 0x040); - cmu_mask = inw(base + 0x040); /* dummy read */ - outw(0x0000, base + 0x042); - } -} diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Thu Apr 29 10:42:49 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Wed May 12 22:06:52 2004 @@ -87,8 +87,6 @@ #ifdef CONFIG_PCI vr41xx_pciu_init(&pci_address_map); - - vrc4173_preinit(); #endif return 0; From yuasa@hh.iij4u.or.jp Wed May 26 16:51:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:52:06 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:27116 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:51:10 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02200; Thu, 27 May 2004 00:51:07 +0900 (JST) Received: 4UMDO01 id i4QFp6u08963; Thu, 27 May 2004 00:51:06 +0900 (JST) Received: 4UMRO00 id i4QFp6V28728; Thu, 27 May 2004 00:51:06 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:04 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][4/14] vr41xx: add fixup-tb0219.c Message-Id: <20040527005104.40832d5f.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, fixup-tb0219.c was added. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile --- linux-orig/arch/mips/pci/Makefile Thu Apr 22 00:48:10 2004 +++ linux/arch/mips/pci/Makefile Thu Apr 22 00:49:05 2004 @@ -44,8 +44,8 @@ obj-$(CONFIG_SGI_IP32) += fixup-ip32.o ops-mace.o pci-ip32.o obj-$(CONFIG_SIBYTE_SB1250) += pci-sb1250.o obj-$(CONFIG_SNI_RM200_PCI) += fixup-sni.o ops-sni.o +obj-$(CONFIG_TANBAC_TB0219) += fixup-tb0219.o obj-$(CONFIG_TANBAC_TB0226) += fixup-tb0226.o -obj-$(CONFIG_TANBAC_TB0229) += fixup-tb0229.o obj-$(CONFIG_TOSHIBA_JMR3927) += fixup-jmr3927.o pci-jmr3927.o obj-$(CONFIG_TOSHIBA_RBTX4927) += fixup-rbtx4927.o ops-tx4927.o obj-$(CONFIG_VICTOR_MPC30X) += fixup-capcella.o diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-tb0219.c linux/arch/mips/pci/fixup-tb0219.c --- linux-orig/arch/mips/pci/fixup-tb0219.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/pci/fixup-tb0219.c Thu Apr 22 00:49:05 2004 @@ -0,0 +1,64 @@ +/* + * fixup-tb0219.c, The TANBAC TB0219 specific PCI fixups. + * + * Copyright (C) 2003 Megasolution Inc. + * Copyright (C) 2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include + +#include + +int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) +{ + int irq = -1; + + switch (slot) { + case 12: + vr41xx_set_irq_trigger(TB0219_PCI_SLOT1_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(TB0219_PCI_SLOT1_PIN, + LEVEL_LOW); + irq = TB0219_PCI_SLOT1_IRQ; + break; + case 13: + vr41xx_set_irq_trigger(TB0219_PCI_SLOT2_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(TB0219_PCI_SLOT2_PIN, + LEVEL_LOW); + irq = TB0219_PCI_SLOT2_IRQ; + break; + case 14: + vr41xx_set_irq_trigger(TB0219_PCI_SLOT3_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(TB0219_PCI_SLOT3_PIN, + LEVEL_LOW); + irq = TB0219_PCI_SLOT3_IRQ; + break; + default: + break; + } + + return irq; +} + +struct pci_fixup pcibios_fixups[] __initdata = { + { .pass = 0, }, +}; diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-tb0229.c linux/arch/mips/pci/fixup-tb0229.c --- linux-orig/arch/mips/pci/fixup-tb0229.c Thu Nov 13 00:24:37 2003 +++ linux/arch/mips/pci/fixup-tb0229.c Thu Jan 1 09:00:00 1970 @@ -1,64 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/tanbac-tb0229/pci_fixup.c - * - * BRIEF MODULE DESCRIPTION - * The TANBAC TB0229(VR4131DIMM) specific PCI fixups. - * - * Copyright 2003 Megasolution Inc. - * matsu@megasolution.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include -#include - -#include - -void __init pcibios_fixup_irqs(void) -{ -#ifdef CONFIG_TANBAC_TB0219 - struct pci_dev *dev = NULL; - u8 slot; - - while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) { - slot = PCI_SLOT(dev->devfn); - dev->irq = 0; - - switch (slot) { - case 12: - vr41xx_set_irq_trigger(TB0219_PCI_SLOT1_PIN, - TRIGGER_LEVEL, - SIGNAL_THROUGH); - vr41xx_set_irq_level(TB0219_PCI_SLOT1_PIN, - LEVEL_LOW); - dev->irq = TB0219_PCI_SLOT1_IRQ; - break; - case 13: - vr41xx_set_irq_trigger(TB0219_PCI_SLOT2_PIN, - TRIGGER_LEVEL, - SIGNAL_THROUGH); - vr41xx_set_irq_level(TB0219_PCI_SLOT2_PIN, - LEVEL_LOW); - dev->irq = TB0219_PCI_SLOT2_IRQ; - break; - case 14: - vr41xx_set_irq_trigger(TB0219_PCI_SLOT3_PIN, - TRIGGER_LEVEL, - SIGNAL_THROUGH); - vr41xx_set_irq_level(TB0219_PCI_SLOT3_PIN, - LEVEL_LOW); - dev->irq = TB0219_PCI_SLOT3_IRQ; - break; - default: - break; - } - - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq); - } -#endif -} From yuasa@hh.iij4u.or.jp Wed May 26 16:52:26 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:52:33 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:31980 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:51:19 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02271; Thu, 27 May 2004 00:51:16 +0900 (JST) Received: 4UMDO01 id i4QFpGu08976; Thu, 27 May 2004 00:51:16 +0900 (JST) Received: 4UMRO00 id i4QFpEV28744; Thu, 27 May 2004 00:51:14 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:12 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][5/14] vr41xx: update fixup-capcella.c Message-Id: <20040527005112.7dc0ae6c.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5170 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, fixup-capcella.c was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile --- linux-orig/arch/mips/pci/Makefile Thu Apr 22 01:13:41 2004 +++ linux/arch/mips/pci/Makefile Thu Apr 22 01:13:55 2004 @@ -50,4 +50,4 @@ obj-$(CONFIG_TOSHIBA_RBTX4927) += fixup-rbtx4927.o ops-tx4927.o obj-$(CONFIG_VICTOR_MPC30X) += fixup-capcella.o obj-$(CONFIG_MACH_VR41XX) += pci-vr41xx.o -obj-$(CONFIG_ZAO_CAPCELLA) += fixup-victor-mpc30x.o +obj-$(CONFIG_ZAO_CAPCELLA) += fixup-capcella.o diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-capcella.c linux/arch/mips/pci/fixup-capcella.c --- linux-orig/arch/mips/pci/fixup-capcella.c Thu Nov 13 10:53:36 2003 +++ linux/arch/mips/pci/fixup-capcella.c Thu Apr 22 01:13:55 2004 @@ -1,17 +1,21 @@ /* - * FILE NAME - * arch/mips/vr41xx/zao-capcella/pci_fixup.c + * fixup-cappcela.c, The ZAO Networks Capcella specific PCI fixups. * - * BRIEF MODULE DESCRIPTION - * The ZAO Networks Capcella specific PCI fixups. + * Copyright (C) 2002,2004 Yoichi Yuasa * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include #include @@ -38,3 +42,7 @@ { return irq_tab_capcella[slot][pin]; } + +struct pci_fixup pcibios_fixups[] __initdata = { + { .pass = 0, }, +}; From yuasa@hh.iij4u.or.jp Wed May 26 16:52:52 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:53:00 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:35052 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:51:27 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02308; Thu, 27 May 2004 00:51:24 +0900 (JST) Received: 4UMDO00 id i4QFpNQ29874; Thu, 27 May 2004 00:51:23 +0900 (JST) Received: 4UMRO00 id i4QFpNV28756; Thu, 27 May 2004 00:51:23 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:21 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][6/14] vr41xx: update fixup-tb0226.c Message-Id: <20040527005121.5cfa0d93.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, fixup-tb0226.c was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-tb0226.c linux/arch/mips/pci/fixup-tb0226.c --- linux-orig/arch/mips/pci/fixup-tb0226.c Thu Nov 13 00:24:37 2003 +++ linux/arch/mips/pci/fixup-tb0226.c Thu Apr 22 01:32:44 2004 @@ -1,78 +1,83 @@ /* - * FILE NAME - * arch/mips/vr41xx/tanbac-tb0226/pci_fixup.c + * fixup-tb0226.c, The TANBAC TB0226 specific PCI fixups. * - * BRIEF MODULE DESCRIPTION - * The TANBAC TB0226 specific PCI fixups. + * Copyright (C) 2002-2004 Yoichi Yuasa * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include #include #include -void __init pcibios_fixup_irqs(void) +int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { - struct pci_dev *dev = NULL; - u8 slot, pin; - - while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) { - slot = PCI_SLOT(dev->devfn); - dev->irq = 0; + int irq = -1; - switch (slot) { - case 12: - vr41xx_set_irq_trigger(GD82559_1_PIN, + switch (slot) { + case 12: + vr41xx_set_irq_trigger(GD82559_1_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(GD82559_1_PIN, LEVEL_LOW); + irq = GD82559_1_IRQ; + break; + case 13: + vr41xx_set_irq_trigger(GD82559_2_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(GD82559_2_PIN, LEVEL_LOW); + irq = GD82559_2_IRQ; + break; + case 14: + switch (pin) { + case 1: + vr41xx_set_irq_trigger(UPD720100_INTA_PIN, + TRIGGER_LEVEL, + SIGNAL_THROUGH); + vr41xx_set_irq_level(UPD720100_INTA_PIN, + LEVEL_LOW); + irq = UPD720100_INTA_IRQ; + break; + case 2: + vr41xx_set_irq_trigger(UPD720100_INTB_PIN, TRIGGER_LEVEL, SIGNAL_THROUGH); - vr41xx_set_irq_level(GD82559_1_PIN, LEVEL_LOW); - dev->irq = GD82559_1_IRQ; + vr41xx_set_irq_level(UPD720100_INTB_PIN, + LEVEL_LOW); + irq = UPD720100_INTB_IRQ; break; - case 13: - vr41xx_set_irq_trigger(GD82559_2_PIN, + case 3: + vr41xx_set_irq_trigger(UPD720100_INTC_PIN, TRIGGER_LEVEL, SIGNAL_THROUGH); - vr41xx_set_irq_level(GD82559_2_PIN, LEVEL_LOW); - dev->irq = GD82559_2_IRQ; + vr41xx_set_irq_level(UPD720100_INTC_PIN, + LEVEL_LOW); + irq = UPD720100_INTC_IRQ; break; - case 14: - pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); - switch (pin) { - case 1: - vr41xx_set_irq_trigger(UPD720100_INTA_PIN, - TRIGGER_LEVEL, - SIGNAL_THROUGH); - vr41xx_set_irq_level(UPD720100_INTA_PIN, - LEVEL_LOW); - dev->irq = UPD720100_INTA_IRQ; - break; - case 2: - vr41xx_set_irq_trigger(UPD720100_INTB_PIN, - TRIGGER_LEVEL, - SIGNAL_THROUGH); - vr41xx_set_irq_level(UPD720100_INTB_PIN, - LEVEL_LOW); - dev->irq = UPD720100_INTB_IRQ; - break; - case 3: - vr41xx_set_irq_trigger(UPD720100_INTC_PIN, - TRIGGER_LEVEL, - SIGNAL_THROUGH); - vr41xx_set_irq_level(UPD720100_INTC_PIN, - LEVEL_LOW); - dev->irq = UPD720100_INTC_IRQ; - break; - } + default: break; } - - pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq); + break; + default: + break; } + + return irq; } + +struct pci_fixup pcibios_fixups[] __initdata = { + { .pass = 0, }, +}; From yuasa@hh.iij4u.or.jp Wed May 26 16:53:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:53:27 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:37356 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:51:37 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02340; Thu, 27 May 2004 00:51:31 +0900 (JST) Received: 4UMDO01 id i4QFpVu09006; Thu, 27 May 2004 00:51:31 +0900 (JST) Received: 4UMRO00 id i4QFpUV28772; Thu, 27 May 2004 00:51:30 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:28 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][7/14] vr41xx: update fixup-mpc30x.c Message-Id: <20040527005128.020b08a9.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, fixup-mpc30x.c was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile --- linux-orig/arch/mips/pci/Makefile Thu Apr 22 01:32:19 2004 +++ linux/arch/mips/pci/Makefile Thu Apr 22 01:43:03 2004 @@ -48,6 +48,6 @@ obj-$(CONFIG_TANBAC_TB0226) += fixup-tb0226.o obj-$(CONFIG_TOSHIBA_JMR3927) += fixup-jmr3927.o pci-jmr3927.o obj-$(CONFIG_TOSHIBA_RBTX4927) += fixup-rbtx4927.o ops-tx4927.o -obj-$(CONFIG_VICTOR_MPC30X) += fixup-capcella.o +obj-$(CONFIG_VICTOR_MPC30X) += fixup-mpc30x.o obj-$(CONFIG_MACH_VR41XX) += pci-vr41xx.o obj-$(CONFIG_ZAO_CAPCELLA) += fixup-capcella.o diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-mpc30x.c linux/arch/mips/pci/fixup-mpc30x.c --- linux-orig/arch/mips/pci/fixup-mpc30x.c Thu Jan 1 09:00:00 1970 +++ linux/arch/mips/pci/fixup-mpc30x.c Thu Apr 22 01:43:03 2004 @@ -0,0 +1,48 @@ +/* + * fixup-mpc30x.c, The Victor MP-C303/304 specific PCI fixups. + * + * Copyright (C) 2002,2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include +#include + +#include +#include + +static const int internal_func_irqs[] __initdata = { + VRC4173_CASCADE_IRQ, + VRC4173_AC97_IRQ, + VRC4173_USB_IRQ, +}; + +static char irq_tab_mpc30x[] __initdata = { + [12] = VRC4173_PCMCIA1_IRQ, + [13] = VRC4173_PCMCIA2_IRQ, + [29] = MQ200_IRQ, +}; + +int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) +{ + if (slot == 30) + return internal_func_irqs[PCI_FUNC(dev->devfn)]; + + return irq_tab_mpc30x[slot]; +} + +struct pci_fixup pcibios_fixups[] __initdata = { + { .pass = 0, }, +}; diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-victor-mpc30x.c linux/arch/mips/pci/fixup-victor-mpc30x.c --- linux-orig/arch/mips/pci/fixup-victor-mpc30x.c Thu Nov 13 10:53:37 2003 +++ linux/arch/mips/pci/fixup-victor-mpc30x.c Thu Jan 1 09:00:00 1970 @@ -1,48 +0,0 @@ -/* - * FILE NAME - * arch/mips/vr41xx/victor-mpc30x/pci_fixup.c - * - * BRIEF MODULE DESCRIPTION - * The Victor MP-C303/304 specific PCI fixups. - * - * Copyright 2002 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ -#include -#include - -#include -#include - -/* - * Shortcuts - */ -#define PCMCIA1 VRC4173_PCMCIA1_IRQ -#define PCMCIA2 VRC4173_PCMCIA2_IRQ -#define MQ MQ200_IRQ - -static const int internal_func_irqs[8] __initdata = { - VRC4173_CASCADE_IRQ, - VRC4173_AC97_IRQ, - VRC4173_USB_IRQ, - -}; - -static char irq_tab_mpc30x[][5] __initdata = { - [12] = { PCMCIA1, PCMCIA1, 0, 0 }, - [13] = { PCMCIA2, PCMCIA2, 0, 0 }, - [29] = { MQ, MQ, 0, 0 }, /* mediaQ MQ-200 */ -}; - -int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin) -{ - if (slot == 30) - return internal_func_irqs[PCI_FUNC(dev->devfn)]; - - return irq_tab_mpc30x[slot][pin]; -} From yuasa@hh.iij4u.or.jp Wed May 26 16:53:47 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:53:59 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:41964 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:51:47 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02404; Thu, 27 May 2004 00:51:42 +0900 (JST) Received: 4UMDO01 id i4QFpgu09045; Thu, 27 May 2004 00:51:42 +0900 (JST) Received: 4UMRO00 id i4QFpfV28781; Thu, 27 May 2004 00:51:41 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:39 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][8/14] vr41xx: update PCIU initialization function Message-Id: <20040527005139.63740a65.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, The PCIU initialization function was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/Kconfig linux/arch/mips/Kconfig --- linux-orig/arch/mips/Kconfig 2004-05-24 10:40:22.000000000 +0900 +++ linux/arch/mips/Kconfig 2004-05-24 18:37:36.000000000 +0900 @@ -127,6 +127,10 @@ select DMA_NONCOHERENT select IRQ_CPU +config PCI_VR41XX + bool "add PCI control unit support of NEC VR4100 series" + depends on MACH_VR41XX && PCI + config VRC4171 tristate "add NEC VRC4171 companion chip support" depends on MACH_VR41XX && ISA @@ -135,7 +139,7 @@ config VRC4173 tristate "add NEC VRC4173 companion chip support" - depends on MACH_VR41XX && PCI + depends on MACH_VR41XX && PCI_VR41XX ---help--- The NEC VRC4173 is a companion chip for NEC VR4122/VR4131. diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile --- linux-orig/arch/mips/pci/Makefile 2004-05-24 18:43:12.000000000 +0900 +++ linux/arch/mips/pci/Makefile 2004-05-24 18:37:36.000000000 +0900 @@ -16,6 +16,7 @@ obj-$(CONFIG_MIPS_MSC) += ops-msc.o obj-$(CONFIG_MIPS_NILE4) += ops-nile4.o obj-$(CONFIG_MIPS_TX3927) += ops-jmr3927.o +obj-$(CONFIG_PCI_VR41XX) += ops-vr41xx.o pci-vr41xx.o # # These are still pretty much in the old state, watch, go blind. @@ -49,5 +50,4 @@ obj-$(CONFIG_TOSHIBA_JMR3927) += fixup-jmr3927.o pci-jmr3927.o obj-$(CONFIG_TOSHIBA_RBTX4927) += fixup-rbtx4927.o ops-tx4927.o obj-$(CONFIG_VICTOR_MPC30X) += fixup-mpc30x.o -obj-$(CONFIG_MACH_VR41XX) += pci-vr41xx.o obj-$(CONFIG_ZAO_CAPCELLA) += fixup-capcella.o diff -urN -X dontdiff linux-orig/arch/mips/pci/ops-vr41xx.c linux/arch/mips/pci/ops-vr41xx.c --- linux-orig/arch/mips/pci/ops-vr41xx.c 1970-01-01 09:00:00.000000000 +0900 +++ linux/arch/mips/pci/ops-vr41xx.c 2004-05-24 18:37:36.000000000 +0900 @@ -0,0 +1,126 @@ +/* + * ops-vr41xx.c, PCI configuration routines for the PCIU of NEC VR4100 series. + * + * Copyright (C) 2001-2003 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +/* + * Changes: + * MontaVista Software Inc. or + * - New creation, NEC VR4122 and VR4131 are supported. + */ +#include +#include + +#include + +#define PCICONFDREG KSEG1ADDR(0x0f000c14) +#define PCICONFAREG KSEG1ADDR(0x0f000c18) + +static inline int set_pci_configuration_address(unsigned char number, + unsigned int devfn, int where) +{ + if (number == 0) { + /* + * Type 0 configuration + */ + if (PCI_SLOT(devfn) < 11 || where > 0xff) + return -EINVAL; + + writel((1U << PCI_SLOT(devfn)) | (PCI_FUNC(devfn) << 8) | + (where & 0xfc), PCICONFAREG); + } else { + /* + * Type 1 configuration + */ + if (where > 0xff) + return -EINVAL; + + writel(((uint32_t)number << 16) | ((devfn & 0xff) << 8) | + (where & 0xfc) | 1U, PCICONFAREG); + } + + return 0; +} + +static int pci_config_read(struct pci_bus *bus, unsigned int devfn, int where, + int size, uint32_t *val) +{ + uint32_t data; + + *val = 0xffffffffU; + if (set_pci_configuration_address(bus->number, devfn, where) < 0) + return PCIBIOS_DEVICE_NOT_FOUND; + + data = readl(PCICONFDREG); + + switch (size) { + case 1: + *val = (data >> ((where & 3) << 3)) & 0xffU; + break; + case 2: + *val = (data >> ((where & 2) << 3)) & 0xffffU; + break; + case 4: + *val = data; + break; + default: + return PCIBIOS_FUNC_NOT_SUPPORTED; + } + + return PCIBIOS_SUCCESSFUL; +} + +static int pci_config_write(struct pci_bus *bus, unsigned int devfn, int where, + int size, uint32_t val) +{ + uint32_t data; + int shift; + + if (set_pci_configuration_address(bus->number, devfn, where) < 0) + return PCIBIOS_DEVICE_NOT_FOUND; + + data = readl(PCICONFDREG); + + switch (size) { + case 1: + shift = (where & 3) << 3; + data &= ~(0xffU << shift); + data |= ((val & 0xffU) << shift); + break; + case 2: + shift = (where & 2) << 3; + data &= ~(0xffffU << shift); + data |= ((val & 0xffffU) << shift); + break; + case 4: + data = val; + break; + default: + return PCIBIOS_FUNC_NOT_SUPPORTED; + } + + writel(data, PCICONFDREG); + + return PCIBIOS_SUCCESSFUL; +} + +struct pci_ops vr41xx_pci_ops = { + .read = pci_config_read, + .write = pci_config_write, +}; diff -urN -X dontdiff linux-orig/arch/mips/pci/pci-vr41xx.c linux/arch/mips/pci/pci-vr41xx.c --- linux-orig/arch/mips/pci/pci-vr41xx.c 2004-02-25 12:12:07.000000000 +0900 +++ linux/arch/mips/pci/pci-vr41xx.c 2004-05-24 18:37:36.000000000 +0900 @@ -1,48 +1,32 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/pciu.c + * pci-vr41xx.c, PCI Control Unit routines for the NEC VR4100 series. * - * BRIEF MODULE DESCRIPTION - * PCI Control Unit routines for the NEC VR4100 series. + * Copyright (C) 2001-2003 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * Copyright 2001-2003 MontaVista Software Inc. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* * Changes: - * Paul Mundt - * - Fix deadlock-causing PCIU access race for VR4131. - * * MontaVista Software Inc. or * - New creation, NEC VR4122 and VR4131 are supported. */ -#include #include #include #include -#include #include #include @@ -51,183 +35,257 @@ #include "pci-vr41xx.h" -static inline int vr41xx_pci_config_access(unsigned char bus, - unsigned int devfn, int where) -{ - if (bus == 0) { - /* - * Type 0 configuration - */ - if (PCI_SLOT(devfn) < 11 || where > 255) - return -1; - - writel((1UL << PCI_SLOT(devfn)) | - (PCI_FUNC(devfn) << 8) | - (where & 0xfc), PCICONFAREG); - } else { - /* - * Type 1 configuration - */ - if (where > 255) - return -1; - - writel((bus << 16) | - (devfn << 8) | (where & 0xfc) | 1UL, PCICONFAREG); - } - - return 0; -} - -static int vr41xx_pci_config_read(struct pci_bus *bus, unsigned int devfn, - int where, int size, u32 * val) -{ - u32 data; +extern struct pci_ops vr41xx_pci_ops; - *val = 0xffffffffUL; - if (vr41xx_pci_config_access(bus->number, devfn, where) < 0) - return PCIBIOS_DEVICE_NOT_FOUND; +static struct pci_master_address_conversion pci_master_memory1 = { + .bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS, + .address_mask = PCI_MASTER_MEM1_ADDRESS_MASK, + .pci_base_address = PCI_MASTER_MEM1_PCI_BASE_ADDRESS, +}; - data = readl(PCICONFDREG); +static struct pci_target_address_conversion pci_target_memory1 = { + .address_mask = PCI_TARGET_MEM1_ADDRESS_MASK, + .bus_base_address = PCI_TARGET_MEM1_BUS_BASE_ADDRESS, +}; - switch (size) { - case 1: - *val = (data >> ((where & 3) << 3)) & 0xffUL; - break; - case 2: - *val = (data >> ((where & 2) << 3)) & 0xffffUL; - break; - case 4: - *val = data; - break; - default: - return PCIBIOS_FUNC_NOT_SUPPORTED; - } +static struct pci_master_address_conversion pci_master_io = { + .bus_base_address = PCI_MASTER_IO_BUS_BASE_ADDRESS, + .address_mask = PCI_MASTER_IO_ADDRESS_MASK, + .pci_base_address = PCI_MASTER_IO_PCI_BASE_ADDRESS, +}; - return PCIBIOS_SUCCESSFUL; -} +static struct pci_mailbox_address pci_mailbox = { + .base_address = PCI_MAILBOX_BASE_ADDRESS, +}; -static int vr41xx_pci_config_write(struct pci_bus *bus, unsigned int devfn, - int where, int size, u32 val) -{ - u32 data; - int shift; +static struct pci_target_address_window pci_target_window1 = { + .base_address = PCI_TARGET_WINDOW1_BASE_ADDRESS, +}; - if (vr41xx_pci_config_access(bus->number, devfn, where) < 0) - return PCIBIOS_DEVICE_NOT_FOUND; +static struct resource pci_mem_resource = { + .name = "PCI Memory resources", + .start = PCI_MEM_RESOURCE_START, + .end = PCI_MEM_RESOURCE_END, + .flags = IORESOURCE_MEM, +}; - data = readl(PCICONFDREG); +static struct resource pci_io_resource = { + .name = "PCI I/O resources", + .start = PCI_IO_RESOURCE_START, + .end = PCI_IO_RESOURCE_END, + .flags = IORESOURCE_IO, +}; - switch (size) { - case 1: - shift = (where & 3) << 3; - data &= ~(0xff << shift); - data |= ((val & 0xff) << shift); - break; - case 2: - shift = (where & 2) << 3; - data &= ~(0xffff << shift); - data |= ((val & 0xffff) << shift); - break; - case 4: - data = val; - break; - default: - return PCIBIOS_FUNC_NOT_SUPPORTED; - } +static struct pci_controller_unit_setup vr41xx_pci_controller_unit_setup = { + .master_memory1 = &pci_master_memory1, + .target_memory1 = &pci_target_memory1, + .master_io = &pci_master_io, + .exclusive_access = CANNOT_LOCK_FROM_DEVICE, + .wait_time_limit_from_irdy_to_trdy = 0, + .mailbox = &pci_mailbox, + .target_window1 = &pci_target_window1, + .master_latency_timer = 0x80, + .retry_limit = 0, + .arbiter_priority_control = PCI_ARBITRATION_MODE_FAIR, + .take_away_gnt_mode = PCI_TAKE_AWAY_GNT_DISABLE, +}; - writel(data, PCICONFDREG); +static struct pci_controller vr41xx_pci_controller = { + .pci_ops = &vr41xx_pci_ops, + .mem_resource = &pci_mem_resource, + .io_resource = &pci_io_resource, +}; - return PCIBIOS_SUCCESSFUL; +void __init vr41xx_pciu_setup(struct pci_controller_unit_setup *setup) +{ + vr41xx_pci_controller_unit_setup = *setup; } -struct pci_ops vr41xx_pci_ops = { - .read = vr41xx_pci_config_read, - .write = vr41xx_pci_config_write, -}; - -void __init vr41xx_pciu_init(struct vr41xx_pci_address_map *map) +static int __init vr41xx_pciu_init(void) { - struct vr41xx_pci_address_space *s; - unsigned long vtclock; - u32 config; - int n; + struct pci_controller_unit_setup *setup; + struct pci_master_address_conversion *master; + struct pci_target_address_conversion *target; + struct pci_mailbox_address *mailbox; + struct pci_target_address_window *window; + unsigned long vtclock, pci_clock_max; + uint32_t val; - if (!map) - return; + setup = &vr41xx_pci_controller_unit_setup; /* Disable PCI interrupt */ - writew(0, MPCIINTREG); + vr41xx_disable_pciint(); /* Supply VTClock to PCIU */ vr41xx_supply_clock(PCIU_CLOCK); - /* - * Sleep for 1us after setting MSKPPCIU bit in CMUCLKMSK - * before doing any PCIU access to avoid deadlock on VR4131. - */ - udelay(1); + /* Dummy write, waiting for supply of VTClock. */ + vr41xx_disable_pciint(); /* Select PCI clock */ + if (setup->pci_clock_max != 0) + pci_clock_max = setup->pci_clock_max; + else + pci_clock_max = PCI_CLOCK_MAX; vtclock = vr41xx_get_vtclock_frequency(); - if (vtclock < MAX_PCI_CLOCK) + if (vtclock < pci_clock_max) writel(EQUAL_VTCLOCK, PCICLKSELREG); - else if ((vtclock / 2) < MAX_PCI_CLOCK) + else if ((vtclock / 2) < pci_clock_max) writel(HALF_VTCLOCK, PCICLKSELREG); - else if ((vtclock / 4) < MAX_PCI_CLOCK) + else if (current_cpu_data.processor_id >= PRID_VR4131_REV2_1 && + (vtclock / 3) < pci_clock_max) + writel(ONE_THIRD_VTCLOCK, PCICLKSELREG); + else if ((vtclock / 4) < pci_clock_max) writel(QUARTER_VTCLOCK, PCICLKSELREG); - else - printk(KERN_INFO "Warning: PCI Clock is over 33MHz.\n"); + else { + printk(KERN_ERR "PCI Clock is over 33MHz.\n"); + return -EINVAL; + } /* Supply PCI clock by PCI bus */ vr41xx_supply_clock(PCI_CLOCK); - /* - * Set PCI memory & I/O space address conversion registers - * for master transaction. - */ - if (map->mem1 != NULL) { - s = map->mem1; - config = (s->internal_base & 0xff000000) | - ((s->address_mask & 0x7f000000) >> 11) | (1UL << 12) | - ((s->pci_base & 0xff000000) >> 24); - writel(config, PCIMMAW1REG); - } - if (map->mem2 != NULL) { - s = map->mem2; - config = (s->internal_base & 0xff000000) | - ((s->address_mask & 0x7f000000) >> 11) | (1UL << 12) | - ((s->pci_base & 0xff000000) >> 24); - writel(config, PCIMMAW2REG); - } - if (map->io != NULL) { - s = map->io; - config = (s->internal_base & 0xff000000) | - ((s->address_mask & 0x7f000000) >> 11) | (1UL << 12) | - ((s->pci_base & 0xff000000) >> 24); - writel(config, PCIMIOAWREG); - } - - /* Set target memory windows */ - writel(0x00081000, PCITAW1REG); - writel(0UL, PCITAW2REG); - pciu_write_config_dword(PCI_BASE_ADDRESS_0, 0UL); - pciu_write_config_dword(PCI_BASE_ADDRESS_1, 0UL); + if (setup->master_memory1 != NULL) { + master = setup->master_memory1; + val = IBA(master->bus_base_address) | + MASTER_MSK(master->address_mask) | + WINEN | + PCIA(master->pci_base_address); + writel(val, PCIMMAW1REG); + } else { + val = readl(PCIMMAW1REG); + val &= ~WINEN; + writel(val, PCIMMAW1REG); + } + + if (setup->master_memory2 != NULL) { + master = setup->master_memory2; + val = IBA(master->bus_base_address) | + MASTER_MSK(master->address_mask) | + WINEN | + PCIA(master->pci_base_address); + writel(val, PCIMMAW2REG); + } else { + val = readl(PCIMMAW2REG); + val &= ~WINEN; + writel(val, PCIMMAW2REG); + } - /* Clear bus error */ - n = readl(BUSERRADREG); + if (setup->target_memory1 != NULL) { + target = setup->target_memory1; + val = TARGET_MSK(target->address_mask) | + WINEN | + ITA(target->bus_base_address); + writel(val, PCITAW1REG); + } else { + val = readl(PCITAW1REG); + val &= ~WINEN; + writel(val, PCITAW1REG); + } + + if (setup->target_memory2 != NULL) { + target = setup->target_memory2; + val = TARGET_MSK(target->address_mask) | + WINEN | + ITA(target->bus_base_address); + writel(val, PCITAW2REG); + } else { + val = readl(PCITAW2REG); + val &= ~WINEN; + writel(val, PCITAW2REG); + } - if (current_cpu_data.cputype == CPU_VR4122) { - writel(0UL, PCITRDYVREG); - pciu_write_config_dword(PCI_CACHE_LINE_SIZE, 0x0000f804); + if (setup->master_io != NULL) { + master = setup->master_io; + val = IBA(master->bus_base_address) | + MASTER_MSK(master->address_mask) | + WINEN | + PCIIA(master->pci_base_address); + writel(val, PCIMIOAWREG); } else { - writel(100UL, PCITRDYVREG); - pciu_write_config_dword(PCI_CACHE_LINE_SIZE, 0x00008004); + val = readl(PCIMIOAWREG); + val &= ~WINEN; + writel(val, PCIMIOAWREG); + } + + if (setup->exclusive_access == CANNOT_LOCK_FROM_DEVICE) + writel(UNLOCK, PCIEXACCREG); + else + writel(0, PCIEXACCREG); + + if (current_cpu_data.cputype == CPU_VR4122) + writel(TRDYV(setup->wait_time_limit_from_irdy_to_trdy), PCITRDYVREG); + + writel(MLTIM(setup->master_latency_timer), LATTIMEREG); + + if (setup->mailbox != NULL) { + mailbox = setup->mailbox; + val = MBADD(mailbox->base_address) | TYPE_32BITSPACE | + MSI_MEMORY | PREF_APPROVAL; + writel(val, MAILBAREG); + } + + if (setup->target_window1) { + window = setup->target_window1; + val = PMBA(window->base_address) | TYPE_32BITSPACE | + MSI_MEMORY | PREF_APPROVAL; + writel(val, PCIMBA1REG); + } + + if (setup->target_window2) { + window = setup->target_window2; + val = PMBA(window->base_address) | TYPE_32BITSPACE | + MSI_MEMORY | PREF_APPROVAL; + writel(val, PCIMBA2REG); } + val = readl(RETVALREG); + val &= ~RTYVAL_MASK; + val |= RTYVAL(setup->retry_limit); + writel(val, RETVALREG); + + val = readl(PCIAPCNTREG); + val &= ~(TKYGNT | PAPC); + + switch (setup->arbiter_priority_control) { + case PCI_ARBITRATION_MODE_ALTERNATE_0: + val |= PAPC_ALTERNATE_0; + break; + case PCI_ARBITRATION_MODE_ALTERNATE_B: + val |= PAPC_ALTERNATE_B; + break; + default: + val |= PAPC_FAIR; + break; + } + + if (setup->take_away_gnt_mode == PCI_TAKE_AWAY_GNT_ENABLE) + val |= TKYGNT_ENABLE; + + writel(val, PCIAPCNTREG); + + writel(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER | + PCI_COMMAND_PARITY | PCI_COMMAND_SERR, COMMANDREG); + + /* Clear bus error */ + readl(BUSERRADREG); + writel(CONFIG_DONE, PCIENREG); - pciu_write_config_dword(PCI_COMMAND, - PCI_COMMAND_IO | - PCI_COMMAND_MEMORY | - PCI_COMMAND_MASTER | - PCI_COMMAND_PARITY | PCI_COMMAND_SERR); + + if (setup->mem_resource != NULL) + vr41xx_pci_controller.mem_resource = setup->mem_resource; + + if (setup->io_resource != NULL) { + vr41xx_pci_controller.io_resource = setup->io_resource; + } else { + set_io_port_base(IO_PORT_BASE); + ioport_resource.start = IO_PORT_RESOURCE_START; + ioport_resource.end = IO_PORT_RESOURCE_END; + } + + register_pci_controller(&vr41xx_pci_controller); + + return 0; } + +early_initcall(vr41xx_pciu_init); diff -urN -X dontdiff linux-orig/arch/mips/pci/pci-vr41xx.h linux/arch/mips/pci/pci-vr41xx.h --- linux-orig/arch/mips/pci/pci-vr41xx.h 2003-10-31 11:29:18.000000000 +0900 +++ linux/arch/mips/pci/pci-vr41xx.h 2004-05-24 18:37:36.000000000 +0900 @@ -1,164 +1,151 @@ /* - * FILE NAME - * arch/mips/vr41xx/common/pciu.h + * pci-vr41xx.h, Include file for PCI Control Unit of the NEC VR4100 series. * - * BRIEF MODULE DESCRIPTION - * Include file for PCI Control Unit of the NEC VR4100 series. - * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2002 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ -/* - * Changes: - * MontaVista Software Inc. or - * - New creation, NEC VR4122 and VR4131 are supported. + * Copyright (C) 2002 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifndef __VR41XX_PCIU_H -#define __VR41XX_PCIU_H - -#include -#include - -#define BIT(x) (1 << (x)) - -#define PCIMMAW1REG KSEG1ADDR(0x0f000c00) -#define PCIMMAW2REG KSEG1ADDR(0x0f000c04) -#define PCITAW1REG KSEG1ADDR(0x0f000c08) -#define PCITAW2REG KSEG1ADDR(0x0f000c0c) -#define PCIMIOAWREG KSEG1ADDR(0x0f000c10) -#define INTERNAL_BUS_BASE_ADDRESS 0xff000000 -#define ADDRESS_MASK 0x000fe000 -#define PCI_ACCESS_ENABLE BIT(12) -#define PCI_ADDRESS_SETTING 0x000000ff - -#define PCICONFDREG KSEG1ADDR(0x0f000c14) -#define PCICONFAREG KSEG1ADDR(0x0f000c18) -#define PCIMAILREG KSEG1ADDR(0x0f000c1c) - -#define BUSERRADREG KSEG1ADDR(0x0f000c24) -#define ERROR_ADDRESS 0xfffffffc - -#define INTCNTSTAREG KSEG1ADDR(0x0f000c28) -#define MABTCLR BIT(31) -#define TRDYCLR BIT(30) -#define PARCLR BIT(29) -#define MBCLR BIT(28) -#define SERRCLR BIT(27) - -#define PCIEXACCREG KSEG1ADDR(0x0f000c2c) -#define UNLOCK BIT(1) -#define EAREQ BIT(0) - -#define PCIRECONTREG KSEG1ADDR(0x0f000c30) -#define RTRYCNT 0x000000ff +#ifndef __PCI_VR41XX_H +#define __PCI_VR41XX_H -#define PCIENREG KSEG1ADDR(0x0f000c34) -#define CONFIG_DONE BIT(2) +#define PCIMMAW1REG KSEG1ADDR(0x0f000c00) +#define PCIMMAW2REG KSEG1ADDR(0x0f000c04) +#define PCITAW1REG KSEG1ADDR(0x0f000c08) +#define PCITAW2REG KSEG1ADDR(0x0f000c0c) +#define PCIMIOAWREG KSEG1ADDR(0x0f000c10) + #define IBA(addr) ((addr) & 0xff000000U) + #define MASTER_MSK(mask) (((mask) >> 11) & 0x000fe000U) + #define PCIA(addr) (((addr) >> 24) & 0x000000ffU) + #define TARGET_MSK(mask) (((mask) >> 8) & 0x000fe000U) + #define ITA(addr) (((addr) >> 24) & 0x000000ffU) + #define PCIIA(addr) (((addr) >> 24) & 0x000000ffU) + #define WINEN 0x1000U +#define PCICONFDREG KSEG1ADDR(0x0f000c14) +#define PCICONFAREG KSEG1ADDR(0x0f000c18) +#define PCIMAILREG KSEG1ADDR(0x0f000c1c) +#define BUSERRADREG KSEG1ADDR(0x0f000c24) + #define EA(reg) ((reg) &0xfffffffc) + +#define INTCNTSTAREG KSEG1ADDR(0x0f000c28) + #define MABTCLR 0x80000000U + #define TRDYCLR 0x40000000U + #define PARCLR 0x20000000U + #define MBCLR 0x10000000U + #define SERRCLR 0x08000000U + #define RTYCLR 0x04000000U + #define MABCLR 0x02000000U + #define TABCLR 0x01000000U + /* RFU */ + #define MABTMSK 0x00008000U + #define TRDYMSK 0x00004000U + #define PARMSK 0x00002000U + #define MBMSK 0x00001000U + #define SERRMSK 0x00000800U + #define RTYMSK 0x00000400U + #define MABMSK 0x00000200U + #define TABMSK 0x00000100U + #define IBAMABT 0x00000080U + #define TRDYRCH 0x00000040U + #define PAR 0x00000020U + #define MB 0x00000010U + #define PCISERR 0x00000008U + #define RTYRCH 0x00000004U + #define MABORT 0x00000002U + #define TABORT 0x00000001U + +#define PCIEXACCREG KSEG1ADDR(0x0f000c2c) + #define UNLOCK 0x2U + #define EAREQ 0x1U +#define PCIRECONTREG KSEG1ADDR(0x0f000c30) + #define RTRYCNT(reg) ((reg) & 0x000000ffU) +#define PCIENREG KSEG1ADDR(0x0f000c34) + #define CONFIG_DONE 0x4U +#define PCICLKSELREG KSEG1ADDR(0x0f000c38) + #define EQUAL_VTCLOCK 0x2U + #define HALF_VTCLOCK 0x0U + #define ONE_THIRD_VTCLOCK 0x3U + #define QUARTER_VTCLOCK 0x1U +#define PCITRDYVREG KSEG1ADDR(0x0f000c3c) + #define TRDYV(val) ((uint32_t)(val) & 0xffU) +#define PCICLKRUNREG KSEG1ADDR(0x0f000c60) + +#define VENDORIDREG KSEG1ADDR(0x0f000d00) +#define DEVICEIDREG KSEG1ADDR(0x0f000d00) +#define COMMANDREG KSEG1ADDR(0x0f000d04) +#define STATUSREG KSEG1ADDR(0x0f000d04) +#define REVIDREG KSEG1ADDR(0x0f000d08) +#define CLASSREG KSEG1ADDR(0x0f000d08) +#define CACHELSREG KSEG1ADDR(0x0f000d0c) +#define LATTIMEREG KSEG1ADDR(0x0f000d0c) + #define MLTIM(val) (((uint32_t)(val) << 7) & 0xff00U) +#define MAILBAREG KSEG1ADDR(0x0f000d10) +#define PCIMBA1REG KSEG1ADDR(0x0f000d14) +#define PCIMBA2REG KSEG1ADDR(0x0f000d18) + #define MBADD(base) ((base) & 0xfffff800U) + #define PMBA(base) ((base) & 0xffe00000U) + #define PREF 0x8U + #define PREF_APPROVAL 0x8U + #define PREF_DISAPPROVAL 0x0U + #define TYPE 0x6U + #define TYPE_32BITSPACE 0x0U + #define MSI 0x1U + #define MSI_MEMORY 0x0U +#define INTLINEREG KSEG1ADDR(0x0f000d3c) +#define INTPINREG KSEG1ADDR(0x0f000d3c) +#define RETVALREG KSEG1ADDR(0x0f000d40) +#define PCIAPCNTREG KSEG1ADDR(0x0f000d40) + #define TKYGNT 0x04000000U + #define TKYGNT_ENABLE 0x04000000U + #define TKYGNT_DISABLE 0x00000000U + #define PAPC 0x03000000U + #define PAPC_ALTERNATE_B 0x02000000U + #define PAPC_ALTERNATE_0 0x01000000U + #define PAPC_FAIR 0x00000000U + #define RTYVAL(val) (((uint32_t)(val) << 7) & 0xff00U) + #define RTYVAL_MASK 0xff00U -#define PCICLKSELREG KSEG1ADDR(0x0f000c38) -#define EQUAL_VTCLOCK 0x00000002 -#define HALF_VTCLOCK 0x00000000 -#define QUARTER_VTCLOCK 0x00000001 +#define PCI_CLOCK_MAX 33333333U -#define PCITRDYVREG KSEG1ADDR(0x0f000c3c) - -#define PCICLKRUNREG KSEG1ADDR(0x0f000c60) - -#define PCIU_CONFIGREGS_BASE KSEG1ADDR(0x0f000d00) -#define VENDORIDREG KSEG1ADDR(0x0f000d00) -#define DEVICEIDREG KSEG1ADDR(0x0f000d00) -#define COMMANDREG KSEG1ADDR(0x0f000d04) -#define STATUSREG KSEG1ADDR(0x0f000d04) -#define REVIDREG KSEG1ADDR(0x0f000d08) -#define CLASSREG KSEG1ADDR(0x0f000d08) -#define CACHELSREG KSEG1ADDR(0x0f000d0c) -#define LATTIMEREG KSEG1ADDR(0x0f000d0c) -#define MAILBAREG KSEG1ADDR(0x0f000d10) -#define PCIMBA1REG KSEG1ADDR(0x0f000d14) -#define PCIMBA2REG KSEG1ADDR(0x0f000d18) -#define INTLINEREG KSEG1ADDR(0x0f000d3c) -#define INTPINREG KSEG1ADDR(0x0f000d3c) -#define RETVALREG KSEG1ADDR(0x0f000d40) -#define PCIAPCNTREG KSEG1ADDR(0x0f000d40) - -#define MPCIINTREG KSEG1ADDR(0x0f0000b2) - -#define MAX_PCI_CLOCK 33333333 - -static inline int pciu_read_config_byte(int where, u8 * val) -{ - u32 data; - - data = readl(PCIU_CONFIGREGS_BASE + where); - *val = (u8) (data >> ((where & 3) << 3)); - - return PCIBIOS_SUCCESSFUL; -} - -static inline int pciu_read_config_word(int where, u16 * val) -{ - u32 data; - - if (where & 1) - return PCIBIOS_BAD_REGISTER_NUMBER; - - data = readl(PCIU_CONFIGREGS_BASE + where); - *val = (u16) (data >> ((where & 2) << 3)); - - return PCIBIOS_SUCCESSFUL; -} - -static inline int pciu_read_config_dword(int where, u32 * val) -{ - if (where & 3) - return PCIBIOS_BAD_REGISTER_NUMBER; - - *val = readl(PCIU_CONFIGREGS_BASE + where); +/* + * Default setup + */ +#define PCI_MASTER_MEM1_BUS_BASE_ADDRESS 0x10000000U +#define PCI_MASTER_MEM1_ADDRESS_MASK 0x7c000000U +#define PCI_MASTER_MEM1_PCI_BASE_ADDRESS 0x10000000U - return PCIBIOS_SUCCESSFUL; -} +#define PCI_TARGET_MEM1_ADDRESS_MASK 0x08000000U +#define PCI_TARGET_MEM1_BUS_BASE_ADDRESS 0x00000000U -static inline int pciu_write_config_byte(int where, u8 val) -{ - writel(val, PCIU_CONFIGREGS_BASE + where); +#define PCI_MASTER_IO_BUS_BASE_ADDRESS 0x16000000U +#define PCI_MASTER_IO_ADDRESS_MASK 0x7e000000U +#define PCI_MASTER_IO_PCI_BASE_ADDRESS 0x00000000U - return 0; -} +#define PCI_MAILBOX_BASE_ADDRESS 0x00000000U -static inline int pciu_write_config_word(int where, u16 val) -{ - writel(val, PCIU_CONFIGREGS_BASE + where); +#define PCI_TARGET_WINDOW1_BASE_ADDRESS 0x00000000U - return 0; -} +#define IO_PORT_BASE KSEG1ADDR(PCI_MASTER_IO_BUS_BASE_ADDRESS) +#define IO_PORT_RESOURCE_START PCI_MASTER_IO_PCI_BASE_ADDRESS +#define IO_PORT_RESOURCE_END (~PCI_MASTER_IO_ADDRESS_MASK & PCI_MASTER_ADDRESS_MASK) -static inline int pciu_write_config_dword(int where, u32 val) -{ - writel(val, PCIU_CONFIGREGS_BASE + where); +#define PCI_IO_RESOURCE_START 0x01000000UL +#define PCI_IO_RESOURCE_END 0x01ffffffUL - return 0; -} +#define PCI_MEM_RESOURCE_START 0x11000000UL +#define PCI_MEM_RESOURCE_END 0x13ffffffUL -#endif /* __VR41XX_PCIU_H */ +#endif /* __PCI_VR41XX_H */ diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vr41xx.h linux/include/asm-mips/vr41xx/vr41xx.h --- linux-orig/include/asm-mips/vr41xx/vr41xx.h 2004-05-24 18:42:52.000000000 +0900 +++ linux/include/asm-mips/vr41xx/vr41xx.h 2004-05-24 18:37:36.000000000 +0900 @@ -277,18 +277,71 @@ /* * PCI Control Unit */ -struct vr41xx_pci_address_space { - u32 internal_base; - u32 address_mask; - u32 pci_base; +#define PCI_MASTER_ADDRESS_MASK 0x7fffffffU + +struct pci_master_address_conversion { + uint32_t bus_base_address; + uint32_t address_mask; + uint32_t pci_base_address; +}; + +struct pci_target_address_conversion { + uint32_t address_mask; + uint32_t bus_base_address; }; -struct vr41xx_pci_address_map { - struct vr41xx_pci_address_space *mem1; - struct vr41xx_pci_address_space *mem2; - struct vr41xx_pci_address_space *io; +typedef enum { + CANNOT_LOCK_FROM_DEVICE, + CAN_LOCK_FROM_DEVICE, +} pci_exclusive_access_t; + +struct pci_mailbox_address { + uint32_t base_address; +}; + +struct pci_target_address_window { + uint32_t base_address; +}; + +typedef enum { + PCI_ARBITRATION_MODE_FAIR, + PCI_ARBITRATION_MODE_ALTERNATE_0, + PCI_ARBITRATION_MODE_ALTERNATE_B, +} pci_arbiter_priority_control_t; + +typedef enum { + PCI_TAKE_AWAY_GNT_DISABLE, + PCI_TAKE_AWAY_GNT_ENABLE, +} pci_take_away_gnt_mode_t; + +struct pci_controller_unit_setup { + struct pci_master_address_conversion *master_memory1; + struct pci_master_address_conversion *master_memory2; + + struct pci_target_address_conversion *target_memory1; + struct pci_target_address_conversion *target_memory2; + + struct pci_master_address_conversion *master_io; + + pci_exclusive_access_t exclusive_access; + + uint32_t pci_clock_max; + uint8_t wait_time_limit_from_irdy_to_trdy; /* Only VR4122 is supported */ + + struct pci_mailbox_address *mailbox; + struct pci_target_address_window *target_window1; + struct pci_target_address_window *target_window2; + + uint8_t master_latency_timer; + uint8_t retry_limit; + + pci_arbiter_priority_control_t arbiter_priority_control; + pci_take_away_gnt_mode_t take_away_gnt_mode; + + struct resource *mem_resource; + struct resource *io_resource; }; -extern void vr41xx_pciu_init(struct vr41xx_pci_address_map *map); +extern void vr41xx_pciu_setup(struct pci_controller_unit_setup *setup); #endif /* __NEC_VR41XX_H */ From yuasa@hh.iij4u.or.jp Wed May 26 16:54:18 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:54:25 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:45548 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:51:55 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02456; Thu, 27 May 2004 00:51:52 +0900 (JST) Received: 4UMDO01 id i4QFpqu09064; Thu, 27 May 2004 00:51:52 +0900 (JST) Received: 4UMRO00 id i4QFppV28789; Thu, 27 May 2004 00:51:51 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:49 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][9/14] vr41xx: update setup.c for TANBAC TB0229 Message-Id: <20040527005149.3b13c972.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, setup.c for TANBAC TB0229 was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c linux/arch/mips/vr41xx/tanbac-tb0229/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/setup.c Thu Apr 29 10:42:49 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/setup.c Thu May 13 23:45:46 2004 @@ -21,59 +21,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include -#include -#include -#include - -#ifdef CONFIG_PCI -static struct resource vr41xx_pci_io_resource = { - .name = "PCI I/O space", - .start = VR41XX_PCI_IO_START, - .end = VR41XX_PCI_IO_END, - .flags = IORESOURCE_IO, -}; - -static struct resource vr41xx_pci_mem_resource = { - .name = "PCI memory space", - .start = VR41XX_PCI_MEM_START, - .end = VR41XX_PCI_MEM_END, - .flags = IORESOURCE_MEM, -}; - -extern struct pci_ops vr41xx_pci_ops; - -struct pci_controller vr41xx_controller = { - .pci_ops = &vr41xx_pci_ops, - .io_resource = &vr41xx_pci_io_resource, - .mem_resource = &vr41xx_pci_mem_resource, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem1 = { - .internal_base = VR41XX_PCI_MEM1_BASE, - .address_mask = VR41XX_PCI_MEM1_MASK, - .pci_base = IO_MEM1_RESOURCE_START, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem2 = { - .internal_base = VR41XX_PCI_MEM2_BASE, - .address_mask = VR41XX_PCI_MEM2_MASK, - .pci_base = IO_MEM2_RESOURCE_START, -}; - -struct vr41xx_pci_address_space vr41xx_pci_io = { - .internal_base = VR41XX_PCI_IO_BASE, - .address_mask = VR41XX_PCI_IO_MASK, - .pci_base = IO_PORT_RESOURCE_START -}; - -static struct vr41xx_pci_address_map pci_address_map = { - .mem1 = &vr41xx_pci_mem1, - .mem2 = &vr41xx_pci_mem2, - .io = &vr41xx_pci_io, -}; -#endif +#include const char *get_system_type(void) { @@ -82,18 +31,10 @@ static int tanbac_tb0229_setup(void) { - set_io_port_base(IO_PORT_BASE); - ioport_resource.start = IO_PORT_RESOURCE_START; - ioport_resource.end = IO_PORT_RESOURCE_END; - #ifdef CONFIG_SERIAL_8250 vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE); vr41xx_siu_init(); vr41xx_dsiu_init(); -#endif - -#ifdef CONFIG_PCI - vr41xx_pciu_init(&pci_address_map); #endif return 0; diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c linux/arch/mips/vr41xx/tanbac-tb0229/tb0219.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0229/tb0219.c Thu Apr 29 10:01:41 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0229/tb0219.c Thu May 13 23:45:46 2004 @@ -22,13 +22,12 @@ #include #include -#include #define TB0219_RESET_REGS KSEG1ADDR(0x0a00000e) #define tb0219_hard_reset() writew(0, TB0219_RESET_REGS) -void tanbac_tb0219_restart(char *command) +static void tanbac_tb0219_restart(char *command) { local_irq_disable(); tb0219_hard_reset(); diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0229.h linux/include/asm-mips/vr41xx/tb0229.h --- linux-orig/include/asm-mips/vr41xx/tb0229.h Thu Apr 29 10:42:52 2004 +++ linux/include/asm-mips/vr41xx/tb0229.h Thu Jan 1 09:00:00 1970 @@ -1,57 +0,0 @@ -/* - * tb0229.h, Include file for TANBAC TB0229. - * - * Copyright (C) 2002-2004 Yoichi Yuasa - * - * Modified for TANBAC TB0229: - * Copyright (C) 2003 Megasolution Inc. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - */ -#ifndef __TANBAC_TB0229_H -#define __TANBAC_TB0229_H - -#include - -/* - * Board specific address mapping - */ -#define VR41XX_PCI_MEM1_BASE 0x10000000 -#define VR41XX_PCI_MEM1_SIZE 0x04000000 -#define VR41XX_PCI_MEM1_MASK 0x7c000000 - -#define VR41XX_PCI_MEM2_BASE 0x14000000 -#define VR41XX_PCI_MEM2_SIZE 0x02000000 -#define VR41XX_PCI_MEM2_MASK 0x7e000000 - -#define VR41XX_PCI_IO_BASE 0x16000000 -#define VR41XX_PCI_IO_SIZE 0x02000000 -#define VR41XX_PCI_IO_MASK 0x7e000000 - -#define VR41XX_PCI_IO_START 0x01000000 -#define VR41XX_PCI_IO_END 0x01ffffff - -#define VR41XX_PCI_MEM_START 0x12000000 -#define VR41XX_PCI_MEM_END 0x15ffffff - -#define IO_PORT_BASE KSEG1ADDR(VR41XX_PCI_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_PCI_IO_SIZE -#define IO_MEM1_RESOURCE_START VR41XX_PCI_MEM1_BASE -#define IO_MEM1_RESOURCE_END (VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE) -#define IO_MEM2_RESOURCE_START VR41XX_PCI_MEM2_BASE -#define IO_MEM2_RESOURCE_END (VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE) - -#endif /* __TANBAC_TB0229_H */ From yuasa@hh.iij4u.or.jp Wed May 26 16:54:45 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:54:53 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:48620 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:52:03 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02501; Thu, 27 May 2004 00:51:59 +0900 (JST) Received: 4UMDO01 id i4QFpxu09095; Thu, 27 May 2004 00:51:59 +0900 (JST) Received: 4UMRO00 id i4QFpwV28797; Thu, 27 May 2004 00:51:58 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:51:56 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][10/14] vr41xx: update setup.c for TANBAC TB0226 Message-Id: <20040527005156.7d3073a5.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, setup.c for TANBAC TB0226 was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c linux/arch/mips/vr41xx/tanbac-tb0226/setup.c --- linux-orig/arch/mips/vr41xx/tanbac-tb0226/setup.c Thu Apr 29 10:42:49 2004 +++ linux/arch/mips/vr41xx/tanbac-tb0226/setup.c Thu May 13 23:57:41 2004 @@ -18,59 +18,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include -#include -#include -#include - -#ifdef CONFIG_PCI -static struct resource vr41xx_pci_io_resource = { - .name = "PCI I/O space", - .start = VR41XX_PCI_IO_START, - .end = VR41XX_PCI_IO_END, - .flags = IORESOURCE_IO, -}; - -static struct resource vr41xx_pci_mem_resource = { - .name = "PCI memory space", - .start = VR41XX_PCI_MEM_START, - .end = VR41XX_PCI_MEM_END, - .flags = IORESOURCE_MEM, -}; - -extern struct pci_ops vr41xx_pci_ops; - -struct pci_controller vr41xx_controller[] = { - .pci_ops = &vr41xx_pci_ops, - .io_resource = &vr41xx_pci_io_resource, - .mem_resource = &vr41xx_pci_mem_resource, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem1 = { - .internal_base = VR41XX_PCI_MEM1_BASE, - .address_mask = VR41XX_PCI_MEM1_MASK, - .pci_base = IO_MEM1_RESOURCE_START, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem2 = { - .internal_base = VR41XX_PCI_MEM2_BASE, - .address_mask = VR41XX_PCI_MEM2_MASK, - .pci_base = IO_MEM2_RESOURCE_START, -}; - -struct vr41xx_pci_address_space vr41xx_pci_io = { - .internal_base = VR41XX_PCI_IO_BASE, - .address_mask = VR41XX_PCI_IO_MASK, - .pci_base = IO_PORT_RESOURCE_START, -}; - -static struct vr41xx_pci_address_map pci_address_map = { - .mem1 = &vr41xx_pci_mem1, - .mem2 = &vr41xx_pci_mem2, - .io = &vr41xx_pci_io, -}; -#endif +#include const char *get_system_type(void) { @@ -79,17 +28,9 @@ static int tanbac_tb0226_setup(void) { - set_io_port_base(IO_PORT_BASE); - ioport_resource.start = IO_PORT_RESOURCE_START; - ioport_resource.end = IO_PORT_RESOURCE_END; - #ifdef CONFIG_SERIAL_8250 vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE); vr41xx_siu_init(); -#endif - -#ifdef CONFIG_PCI - vr41xx_pciu_init(&pci_address_map); #endif return 0; diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/tb0226.h linux/include/asm-mips/vr41xx/tb0226.h --- linux-orig/include/asm-mips/vr41xx/tb0226.h Thu Apr 24 00:27:49 2003 +++ linux/include/asm-mips/vr41xx/tb0226.h Thu May 13 23:57:41 2004 @@ -1,52 +1,26 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/tb0226.h + * tb0226.h, Include file for TANBAC TB0226. * - * BRIEF MODULE DESCRIPTION - * Include file for TANBAC TB0226. + * Copyright (C) 2002-2004 Yoichi Yuasa * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __TANBAC_TB0226_H #define __TANBAC_TB0226_H -#include #include - -/* - * Board specific address mapping - */ -#define VR41XX_PCI_MEM1_BASE 0x10000000 -#define VR41XX_PCI_MEM1_SIZE 0x04000000 -#define VR41XX_PCI_MEM1_MASK 0x7c000000 - -#define VR41XX_PCI_MEM2_BASE 0x14000000 -#define VR41XX_PCI_MEM2_SIZE 0x02000000 -#define VR41XX_PCI_MEM2_MASK 0x7e000000 - -#define VR41XX_PCI_IO_BASE 0x16000000 -#define VR41XX_PCI_IO_SIZE 0x02000000 -#define VR41XX_PCI_IO_MASK 0x7e000000 - -#define VR41XX_PCI_IO_START 0x01000000 -#define VR41XX_PCI_IO_END 0x01ffffff - -#define VR41XX_PCI_MEM_START 0x12000000 -#define VR41XX_PCI_MEM_END 0x15ffffff - -#define IO_PORT_BASE KSEG1ADDR(VR41XX_PCI_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_PCI_IO_SIZE -#define IO_MEM1_RESOURCE_START VR41XX_PCI_MEM1_BASE -#define IO_MEM1_RESOURCE_END (VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE) -#define IO_MEM2_RESOURCE_START VR41XX_PCI_MEM2_BASE -#define IO_MEM2_RESOURCE_END (VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE) /* * General-Purpose I/O Pin Number From yuasa@hh.iij4u.or.jp Wed May 26 16:55:12 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:55:20 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:52716 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:52:12 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02549; Thu, 27 May 2004 00:52:09 +0900 (JST) Received: 4UMDO01 id i4QFq9u09123; Thu, 27 May 2004 00:52:09 +0900 (JST) Received: 4UMRO00 id i4QFq8V28817; Thu, 27 May 2004 00:52:08 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:52:06 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][11/14] vr41xx: update setup.c for ZAO Networks Capcella Message-Id: <20040527005206.6e8ecb18.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, setup.c for ZAO Networks Capcella was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/setup.c linux/arch/mips/vr41xx/zao-capcella/setup.c --- linux-orig/arch/mips/vr41xx/zao-capcella/setup.c Thu Apr 29 10:42:49 2004 +++ linux/arch/mips/vr41xx/zao-capcella/setup.c Fri May 14 00:08:36 2004 @@ -18,59 +18,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include -#include -#include -#include - -#ifdef CONFIG_PCI -static struct resource vr41xx_pci_io_resource = { - "PCI I/O space", - VR41XX_PCI_IO_START, - VR41XX_PCI_IO_END, - IORESOURCE_IO -}; - -static struct resource vr41xx_pci_mem_resource = { - "PCI memory space", - VR41XX_PCI_MEM_START, - VR41XX_PCI_MEM_END, - IORESOURCE_MEM -}; - -extern struct pci_ops vr41xx_pci_ops; - -struct pci_controller vr41xx_controller = { - .pci_ops = &vr41xx_pci_ops, - .io_resource = &vr41xx_pci_io_resource, - .mem_resource = &vr41xx_pci_mem_resource, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem1 = { - VR41XX_PCI_MEM1_BASE, - VR41XX_PCI_MEM1_MASK, - IO_MEM1_RESOURCE_START -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem2 = { - VR41XX_PCI_MEM2_BASE, - VR41XX_PCI_MEM2_MASK, - IO_MEM2_RESOURCE_START -}; - -struct vr41xx_pci_address_space vr41xx_pci_io = { - VR41XX_PCI_IO_BASE, - VR41XX_PCI_IO_MASK, - IO_PORT_RESOURCE_START -}; - -static struct vr41xx_pci_address_map pci_address_map = { - &vr41xx_pci_mem1, - &vr41xx_pci_mem2, - &vr41xx_pci_io -}; -#endif +#include const char *get_system_type(void) { @@ -79,18 +28,10 @@ static int zao_capcella_setup(void) { - set_io_port_base(IO_PORT_BASE); - ioport_resource.start = IO_PORT_RESOURCE_START; - ioport_resource.end = IO_PORT_RESOURCE_END; - #ifdef CONFIG_SERIAL_8250 vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE); vr41xx_siu_init(); vr41xx_dsiu_init(); -#endif - -#ifdef CONFIG_PCI - vr41xx_pciu_init(&pci_address_map); #endif return 0; diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/capcella.h linux/include/asm-mips/vr41xx/capcella.h --- linux-orig/include/asm-mips/vr41xx/capcella.h Mon Mar 24 00:01:42 2003 +++ linux/include/asm-mips/vr41xx/capcella.h Fri May 14 00:08:36 2004 @@ -1,52 +1,26 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/capcella.h + * capcella.h, Include file for ZAO Networks Capcella. * - * BRIEF MODULE DESCRIPTION - * Include file for ZAO Networks Capcella. + * Copyright (C) 2002-2004 Yoichi Yuasa * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __ZAO_CAPCELLA_H #define __ZAO_CAPCELLA_H -#include #include - -/* - * Board specific address mapping - */ -#define VR41XX_PCI_MEM1_BASE 0x10000000 -#define VR41XX_PCI_MEM1_SIZE 0x04000000 -#define VR41XX_PCI_MEM1_MASK 0x7c000000 - -#define VR41XX_PCI_MEM2_BASE 0x14000000 -#define VR41XX_PCI_MEM2_SIZE 0x02000000 -#define VR41XX_PCI_MEM2_MASK 0x7e000000 - -#define VR41XX_PCI_IO_BASE 0x16000000 -#define VR41XX_PCI_IO_SIZE 0x02000000 -#define VR41XX_PCI_IO_MASK 0x7e000000 - -#define VR41XX_PCI_IO_START 0x01000000 -#define VR41XX_PCI_IO_END 0x01ffffff - -#define VR41XX_PCI_MEM_START 0x12000000 -#define VR41XX_PCI_MEM_END 0x15ffffff - -#define IO_PORT_BASE KSEG1ADDR(VR41XX_PCI_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_PCI_IO_SIZE -#define IO_MEM1_RESOURCE_START VR41XX_PCI_MEM1_BASE -#define IO_MEM1_RESOURCE_END (VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE) -#define IO_MEM2_RESOURCE_START VR41XX_PCI_MEM2_BASE -#define IO_MEM2_RESOURCE_END (VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE) /* * General-Purpose I/O Pin Number From yuasa@hh.iij4u.or.jp Wed May 26 16:55:39 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:55:47 +0100 (BST) Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:5826 "EHLO mo03.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:52:20 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA14660; Thu, 27 May 2004 00:52:17 +0900 (JST) Received: 4UMDO00 id i4QFqHQ29971; Thu, 27 May 2004 00:52:17 +0900 (JST) Received: 4UMRO00 id i4QFqGV28830; Thu, 27 May 2004 00:52:16 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:52:14 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][12/14] vr41xx: update setup.c for Victor MP-C30x Message-Id: <20040527005214.64ddfa46.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, setup.c for Victor MP-C30x was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c linux/arch/mips/vr41xx/victor-mpc30x/setup.c --- linux-orig/arch/mips/vr41xx/victor-mpc30x/setup.c Thu Apr 29 10:42:49 2004 +++ linux/arch/mips/vr41xx/victor-mpc30x/setup.c Fri May 14 00:16:15 2004 @@ -18,59 +18,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include -#include -#include -#include - -#ifdef CONFIG_PCI -static struct resource vr41xx_pci_io_resource = { - "PCI I/O space", - VR41XX_PCI_IO_START, - VR41XX_PCI_IO_END, - IORESOURCE_IO -}; - -static struct resource vr41xx_pci_mem_resource = { - "PCI memory space", - VR41XX_PCI_MEM_START, - VR41XX_PCI_MEM_END, - IORESOURCE_MEM -}; - -extern struct pci_ops vr41xx_pci_ops; - -struct pci_controller vr41xx_controller[] = { - .pci_ops = &vr41xx_pci_ops, - .io_resource = &vr41xx_pci_io_resource, - .mem_resource = &vr41xx_pci_mem_resource, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem1 = { - VR41XX_PCI_MEM1_BASE, - VR41XX_PCI_MEM1_MASK, - IO_MEM1_RESOURCE_START -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem2 = { - VR41XX_PCI_MEM2_BASE, - VR41XX_PCI_MEM2_MASK, - IO_MEM2_RESOURCE_START -}; - -struct vr41xx_pci_address_space vr41xx_pci_io = { - VR41XX_PCI_IO_BASE, - VR41XX_PCI_IO_MASK, - IO_PORT_RESOURCE_START -}; - -static struct vr41xx_pci_address_map pci_address_map = { - &vr41xx_pci_mem1, - &vr41xx_pci_mem2, - &vr41xx_pci_io -}; -#endif +#include const char *get_system_type(void) { @@ -79,17 +28,9 @@ static int victor_mpc30x_setup(void) { - set_io_port_base(IO_PORT_BASE); - ioport_resource.start = IO_PORT_RESOURCE_START; - ioport_resource.end = IO_PORT_RESOURCE_END; - #ifdef CONFIG_SERIAL_8250 vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE); vr41xx_siu_init(); -#endif - -#ifdef CONFIG_PCI - vr41xx_pciu_init(&pci_address_map); #endif return 0; diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/mpc30x.h linux/include/asm-mips/vr41xx/mpc30x.h --- linux-orig/include/asm-mips/vr41xx/mpc30x.h Tue Nov 18 12:34:50 2003 +++ linux/include/asm-mips/vr41xx/mpc30x.h Fri May 14 00:16:15 2004 @@ -1,52 +1,26 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/mpc30x.h + * mpc30x.h, Include file for Victor MP-C303/304. * - * BRIEF MODULE DESCRIPTION - * Include file for Victor MP-C303/304. + * Copyright (C) 2002-2004 Yoichi Yuasa * - * Copyright 2002,2003 Yoichi Yuasa - * yuasa@hh.iij4u.or.jp + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __VICTOR_MPC30X_H #define __VICTOR_MPC30X_H -#include #include - -/* - * Board specific address mapping - */ -#define VR41XX_PCI_MEM1_BASE 0x10000000 -#define VR41XX_PCI_MEM1_SIZE 0x04000000 -#define VR41XX_PCI_MEM1_MASK 0x7c000000 - -#define VR41XX_PCI_MEM2_BASE 0x14000000 -#define VR41XX_PCI_MEM2_SIZE 0x02000000 -#define VR41XX_PCI_MEM2_MASK 0x7e000000 - -#define VR41XX_PCI_IO_BASE 0x16000000 -#define VR41XX_PCI_IO_SIZE 0x02000000 -#define VR41XX_PCI_IO_MASK 0x7e000000 - -#define VR41XX_PCI_IO_START 0x01000000 -#define VR41XX_PCI_IO_END 0x01ffffff - -#define VR41XX_PCI_MEM_START 0x12000000 -#define VR41XX_PCI_MEM_END 0x15ffffff - -#define IO_PORT_BASE KSEG1ADDR(VR41XX_PCI_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_PCI_IO_SIZE -#define IO_MEM1_RESOURCE_START VR41XX_PCI_MEM1_BASE -#define IO_MEM1_RESOURCE_END (VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE) -#define IO_MEM2_RESOURCE_START VR41XX_PCI_MEM2_BASE -#define IO_MEM2_RESOURCE_END (VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE) /* * General-Purpose I/O Pin Number From yuasa@hh.iij4u.or.jp Wed May 26 16:56:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:56:15 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:56812 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:52:31 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02606; Thu, 27 May 2004 00:52:27 +0900 (JST) Received: 4UMDO00 id i4QFqRQ00102; Thu, 27 May 2004 00:52:27 +0900 (JST) Received: 4UMRO00 id i4QFqQV28848; Thu, 27 May 2004 00:52:26 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:52:24 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][13/14] vr41xx: update setup.c for NEC Eagle Message-Id: <20040527005224.542a5087.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, setup.c for NEC Eagle was updated. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c --- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c Thu May 13 23:33:00 2004 +++ linux/arch/mips/vr41xx/nec-eagle/setup.c Fri May 14 00:23:19 2004 @@ -1,72 +1,26 @@ /* - * arch/mips/vr41xx/nec-eagle/setup.c + * setup.c, Setup for the NEC Eagle/Hawk board. * - * Setup for the NEC Eagle/Hawk board. + * Copyright (C) 2001-2004 MontaVista Software Inc. + * Author: Yoichi Yuasa * - * Author: Yoichi Yuasa + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * 2001-2004 (c) MontaVista, Software, Inc. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include -#include - -#include -#include -#include - -#ifdef CONFIG_PCI - -extern void vrc4173_preinit(void); - -static struct resource vr41xx_pci_io_resource = { - "PCI I/O space", - VR41XX_PCI_IO_START, - VR41XX_PCI_IO_END, - IORESOURCE_IO -}; - -static struct resource vr41xx_pci_mem_resource = { - "PCI memory space", - VR41XX_PCI_MEM_START, - VR41XX_PCI_MEM_END, - IORESOURCE_MEM -}; - -extern struct pci_ops vr41xx_pci_ops; -struct pci_controller vr41xx_controller = { - .pci_ops = &vr41xx_pci_ops, - .io_resource = &vr41xx_pci_io_resource, - .mem_resource = &vr41xx_pci_mem_resource, -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem1 = { - VR41XX_PCI_MEM1_BASE, - VR41XX_PCI_MEM1_MASK, - IO_MEM1_RESOURCE_START -}; - -struct vr41xx_pci_address_space vr41xx_pci_mem2 = { - VR41XX_PCI_MEM2_BASE, - VR41XX_PCI_MEM2_MASK, - IO_MEM2_RESOURCE_START -}; - -struct vr41xx_pci_address_space vr41xx_pci_io = { - VR41XX_PCI_IO_BASE, - VR41XX_PCI_IO_MASK, - IO_PORT_RESOURCE_START -}; - -static struct vr41xx_pci_address_map pci_address_map = { - &vr41xx_pci_mem1, - &vr41xx_pci_mem2, - &vr41xx_pci_io -}; -#endif +#include const char *get_system_type(void) { @@ -75,18 +29,10 @@ static int nec_eagle_setup(void) { - set_io_port_base(IO_PORT_BASE); - ioport_resource.start = IO_PORT_RESOURCE_START; - ioport_resource.end = IO_PORT_RESOURCE_END; - #ifdef CONFIG_SERIAL_8250 vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE); vr41xx_siu_init(); vr41xx_dsiu_init(); -#endif - -#ifdef CONFIG_PCI - vr41xx_pciu_init(&pci_address_map); #endif return 0; diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/eagle.h linux/include/asm-mips/vr41xx/eagle.h --- linux-orig/include/asm-mips/vr41xx/eagle.h Mon Mar 24 00:01:42 2003 +++ linux/include/asm-mips/vr41xx/eagle.h Fri May 14 00:23:19 2004 @@ -1,71 +1,29 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/eagle.h + * eagle.h, Include file for NEC Eagle board. * - * BRIEF MODULE DESCRIPTION - * Include file for NEC Eagle board. + * Copyright (C) 2001-2003 MontaVista Software Inc. + * Author: Yoichi Yuasa * - * Author: MontaVista Software, Inc. - * yyuasa@mvista.com or source@mvista.com - * - * Copyright 2001-2003 MontaVista Software Inc. - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __NEC_EAGLE_H #define __NEC_EAGLE_H -#include #include /* - * Board specific address mapping - */ -#define VR41XX_PCI_MEM1_BASE 0x10000000 -#define VR41XX_PCI_MEM1_SIZE 0x04000000 -#define VR41XX_PCI_MEM1_MASK 0x7c000000 - -#define VR41XX_PCI_MEM2_BASE 0x14000000 -#define VR41XX_PCI_MEM2_SIZE 0x02000000 -#define VR41XX_PCI_MEM2_MASK 0x7e000000 - -#define VR41XX_PCI_IO_BASE 0x16000000 -#define VR41XX_PCI_IO_SIZE 0x02000000 -#define VR41XX_PCI_IO_MASK 0x7e000000 - -#define VR41XX_PCI_IO_START 0x01000000 -#define VR41XX_PCI_IO_END 0x01ffffff - -#define VR41XX_PCI_MEM_START 0x12000000 -#define VR41XX_PCI_MEM_END 0x15ffffff - -#define IO_PORT_BASE KSEG1ADDR(VR41XX_PCI_IO_BASE) -#define IO_PORT_RESOURCE_START 0 -#define IO_PORT_RESOURCE_END VR41XX_PCI_IO_SIZE -#define IO_MEM1_RESOURCE_START VR41XX_PCI_MEM1_BASE -#define IO_MEM1_RESOURCE_END (VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE) -#define IO_MEM2_RESOURCE_START VR41XX_PCI_MEM2_BASE -#define IO_MEM2_RESOURCE_END (VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE) - -/* * General-Purpose I/O Pin Number */ #define VRC4173_PIN 1 @@ -99,167 +57,5 @@ #define CP_INTD_IRQ PCIINT_IRQ(3) #define LANINTA_IRQ PCIINT_IRQ(4) #define PCIINT_IRQ_LAST LANINTA_IRQ - -/* - * On board Devices I/O Mapping - */ -#define NEC_EAGLE_SIO1RB KSEG1ADDR(0x0DFFFEC0) -#define NEC_EAGLE_SIO1TH KSEG1ADDR(0x0DFFFEC0) -#define NEC_EAGLE_SIO1IE KSEG1ADDR(0x0DFFFEC2) -#define NEC_EAGLE_SIO1IID KSEG1ADDR(0x0DFFFEC4) -#define NEC_EAGLE_SIO1FC KSEG1ADDR(0x0DFFFEC4) -#define NEC_EAGLE_SIO1LC KSEG1ADDR(0x0DFFFEC6) -#define NEC_EAGLE_SIO1MC KSEG1ADDR(0x0DFFFEC8) -#define NEC_EAGLE_SIO1LS KSEG1ADDR(0x0DFFFECA) -#define NEC_EAGLE_SIO1MS KSEG1ADDR(0x0DFFFECC) -#define NEC_EAGLE_SIO1SC KSEG1ADDR(0x0DFFFECE) - -#define NEC_EAGLE_SIO2TH KSEG1ADDR(0x0DFFFED0) -#define NEC_EAGLE_SIO2IE KSEG1ADDR(0x0DFFFED2) -#define NEC_EAGLE_SIO2IID KSEG1ADDR(0x0DFFFED4) -#define NEC_EAGLE_SIO2FC KSEG1ADDR(0x0DFFFED4) -#define NEC_EAGLE_SIO2LC KSEG1ADDR(0x0DFFFED6) -#define NEC_EAGLE_SIO2MC KSEG1ADDR(0x0DFFFED8) -#define NEC_EAGLE_SIO2LS KSEG1ADDR(0x0DFFFEDA) -#define NEC_EAGLE_SIO2MS KSEG1ADDR(0x0DFFFEDC) -#define NEC_EAGLE_SIO2SC KSEG1ADDR(0x0DFFFEDE) - -#define NEC_EAGLE_PIOPP_DATA KSEG1ADDR(0x0DFFFEE0) -#define NEC_EAGLE_PIOPP_STATUS KSEG1ADDR(0x0DFFFEE2) -#define NEC_EAGLE_PIOPP_CNT KSEG1ADDR(0x0DFFFEE4) -#define NEC_EAGLE_PIOPP_EPPADDR KSEG1ADDR(0x0DFFFEE6) -#define NEC_EAGLE_PIOPP_EPPDATA0 KSEG1ADDR(0x0DFFFEE8) -#define NEC_EAGLE_PIOPP_EPPDATA1 KSEG1ADDR(0x0DFFFEEA) -#define NEC_EAGLE_PIOPP_EPPDATA2 KSEG1ADDR(0x0DFFFEEC) - -#define NEC_EAGLE_PIOECP_DATA KSEG1ADDR(0x0DFFFEF0) -#define NEC_EAGLE_PIOECP_CONFIG KSEG1ADDR(0x0DFFFEF2) -#define NEC_EAGLE_PIOECP_EXTCNT KSEG1ADDR(0x0DFFFEF4) - -/* - * FLSHCNT Register - */ -#define NEC_EAGLE_FLSHCNT KSEG1ADDR(0x0DFFFFA0) -#define NEC_EAGLE_FLSHCNT_FRDY 0x80 -#define NEC_EAGLE_FLSHCNT_VPPE 0x40 -#define NEC_EAGLE_FLSHCNT_WP2 0x01 - -/* - * FLSHBANK Register - */ -#define NEC_EAGLE_FLSHBANK KSEG1ADDR(0x0DFFFFA4) -#define NEC_EAGLE_FLSHBANK_S_BANK2 0x40 -#define NEC_EAGLE_FLSHBANK_S_BANK1 0x20 -#define NEC_EAGLE_FLSHBANK_BNKQ4 0x10 -#define NEC_EAGLE_FLSHBANK_BNKQ3 0x08 -#define NEC_EAGLE_FLSHBANK_BNKQ2 0x04 -#define NEC_EAGLE_FLSHBANK_BNKQ1 0x02 -#define NEC_EAGLE_FLSHBANK_BNKQ0 0x01 - -/* - * SWITCH Setting Register - */ -#define NEC_EAGLE_SWTCHSET KSEG1ADDR(0x0DFFFFA8) -#define NEC_EAGLE_SWTCHSET_DP2SW4 0x80 -#define NEC_EAGLE_SWTCHSET_DP2SW3 0x40 -#define NEC_EAGLE_SWTCHSET_DP2SW2 0x20 -#define NEC_EAGLE_SWTCHSET_DP2SW1 0x10 -#define NEC_EAGLE_SWTCHSET_DP1SW4 0x08 -#define NEC_EAGLE_SWTCHSET_DP1SW3 0x04 -#define NEC_EAGLE_SWTCHSET_DP1SW2 0x02 -#define NEC_EAGLE_SWTCHSET_DP1SW1 0x01 - -/* - * PPT Parallel Port Device Controller - */ -#define NEC_EAGLE_PPT_WRITE_DATA KSEG1ADDR(0x0DFFFFB0) -#define NEC_EAGLE_PPT_READ_DATA KSEG1ADDR(0x0DFFFFB2) -#define NEC_EAGLE_PPT_CNT KSEG1ADDR(0x0DFFFFB4) -#define NEC_EAGLE_PPT_CNT2 KSEG1ADDR(0x0DFFFFB4) - -/* Control Register */ -#define NEC_EAGLE_PPT_INTMSK 0x20 -#define NEC_EAGLE_PPT_PARIINT 0x10 -#define NEC_EAGLE_PPT_SELECTIN 0x08 -#define NEC_EAGLE_PPT_INIT 0x04 -#define NEC_EAGLE_PPT_AUTOFD 0x02 -#define NEC_EAGLE_PPT_STROBE 0x01 - -/* Control Rgister 2 */ -#define NEC_EAGLE_PPT_PAREN 0x80 -#define NEC_EAGLE_PPT_AUTOEN 0x20 -#define NEC_EAGLE_PPT_BUSY 0x10 -#define NEC_EAGLE_PPT_ACK 0x08 -#define NEC_EAGLE_PPT_PE 0x04 -#define NEC_EAGLE_PPT_SELECT 0x02 -#define NEC_EAGLE_PPT_FAULT 0x01 - -/* - * LEDWR Register - */ -#define NEC_EAGLE_LEDWR1 KSEG1ADDR(0x0DFFFFC0) -#define NEC_EAGLE_LEDWR2 KSEG1ADDR(0x0DFFFFC4) - -/* - * SDBINT Register - */ -#define NEC_EAGLE_SDBINT KSEG1ADDR(0x0DFFFFD0) -#define NEC_EAGLE_SDBINT_PARINT 0x20 -#define NEC_EAGLE_SDBINT_SIO2INT 0x10 -#define NEC_EAGLE_SDBINT_SIO1INT 0x08 -#define NEC_EAGLE_SDBINT_ENUM 0x04 -#define NEC_EAGLE_SDBINT_DEG 0x02 - -/* - * SDB INTMSK Register - */ -#define NEC_EAGLE_SDBINTMSK KSEG1ADDR(0x0DFFFFD4) -#define NEC_EAGLE_SDBINTMSK_MSKPAR 0x20 -#define NEC_EAGLE_SDBINTMSK_MSKSIO2 0x10 -#define NEC_EAGLE_SDBINTMSK_MSKSIO1 0x08 -#define NEC_EAGLE_SDBINTMSK_MSKENUM 0x04 -#define NEC_EAGLE_SDBINTMSK_MSKDEG 0x02 - -/* - * RSTREG Register - */ -#define NEC_EAGLE_RSTREG KSEG1ADDR(0x0DFFFFD8) -#define NEC_EAGLE_RST_RSTSW 0x02 -#define NEC_EAGLE_RST_LEDOFF 0x01 - -/* - * PCI INT Rgister - */ -#define NEC_EAGLE_PCIINTREG KSEG1ADDR(0x0DFFFFDC) -#define NEC_EAGLE_PCIINT_LANINT 0x10 -#define NEC_EAGLE_PCIINT_CP_INTD 0x08 -#define NEC_EAGLE_PCIINT_CP_INTC 0x04 -#define NEC_EAGLE_PCIINT_CP_INTB 0x02 -#define NEC_EAGLE_PCIINT_CP_INTA 0x01 - -/* - * PCI INT Mask Register - */ -#define NEC_EAGLE_PCIINTMSKREG KSEG1ADDR(0x0DFFFFE0) -#define NEC_EAGLE_PCIINTMSK_MSKLANINT 0x10 -#define NEC_EAGLE_PCIINTMSK_MSKCP_INTD 0x08 -#define NEC_EAGLE_PCIINTMSK_MSKCP_INTC 0x04 -#define NEC_EAGLE_PCIINTMSK_MSKCP_INTB 0x02 -#define NEC_EAGLE_PCIINTMSK_MSKCP_INTA 0x01 - -/* - * CLK Division Register - */ -#define NEC_EAGLE_CLKDIV KSEG1ADDR(0x0DFFFFE4) -#define NEC_EAGLE_CLKDIV_PCIDIV1 0x10 -#define NEC_EAGLE_CLKDIV_PCIDIV0 0x08 -#define NEC_EAGLE_CLKDIV_VTDIV2 0x04 -#define NEC_EAGLE_CLKDIV_VTDIV1 0x02 -#define NEC_EAGLE_CLKDIV_VTDIV0 0x01 - -/* - * Source Revision Register - */ -#define NEC_EAGLE_REVISION KSEG1ADDR(0x0DFFFFE8) #endif /* __NEC_EAGLE_H */ From yuasa@hh.iij4u.or.jp Wed May 26 16:56:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 16:56:44 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:58604 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 16:52:38 +0100 Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA02630; Thu, 27 May 2004 00:52:34 +0900 (JST) Received: 4UMDO00 id i4QFqXQ00117; Thu, 27 May 2004 00:52:33 +0900 (JST) Received: 4UMRO00 id i4QFqXV28859; Thu, 27 May 2004 00:52:33 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Thu, 27 May 2004 00:52:31 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH][14/14] vr41xx: vrc4173.c synchronizes with latest Message-Id: <20040527005231.0d0c03b1.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, vrc4173.c synchronizes with latest. Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/vrc4173.c linux/arch/mips/vr41xx/common/vrc4173.c --- linux-orig/arch/mips/vr41xx/common/vrc4173.c Thu Dec 18 01:02:24 2003 +++ linux/arch/mips/vr41xx/common/vrc4173.c Fri May 14 00:32:07 2004 @@ -1,143 +1,336 @@ /* - * FILE NAME - * drivers/char/vrc4173.c - * - * BRIEF MODULE DESCRIPTION - * NEC VRC4173 driver for NEC VR4122/VR4131. + * vrc4173.c, NEC VRC4173 base driver for NEC VR4122/VR4131. * - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * Copyright (C) 2001-2003 MontaVista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa * - * Copyright 2001,2002 MontaVista Software Inc. + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, - * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS - * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR - * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE - * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include #include #include #include #include #include +#include #include #include #include -MODULE_DESCRIPTION("NEC VRC4173 driver for NEC VR4122/4131"); +MODULE_DESCRIPTION("NEC VRC4173 base driver for NEC VR4122/4131"); MODULE_AUTHOR("Yoichi Yuasa "); MODULE_LICENSE("GPL"); #define VRC4173_CMUCLKMSK 0x040 + #define MSKPIU 0x0001 + #define MSKKIU 0x0002 + #define MSKAIU 0x0004 + #define MSKPS2CH1 0x0008 + #define MSKPS2CH2 0x0010 + #define MSKUSB 0x0020 + #define MSKCARD1 0x0040 + #define MSKCARD2 0x0080 + #define MSKAC97 0x0100 + #define MSK48MUSB 0x0400 + #define MSK48MPIN 0x0800 + #define MSK48MOSC 0x1000 #define VRC4173_CMUSRST 0x042 - -#define VRC4173_SELECTREG 0x09e + #define USBRST 0x0001 + #define CARD1RST 0x0002 + #define CARD2RST 0x0004 + #define AC97RST 0x0008 #define VRC4173_SYSINT1REG 0x060 #define VRC4173_MSYSINT1REG 0x06c -static struct pci_device_id vrc4173_table[] = { - {PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_VRC4173, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - {0, } +#define VRC4173_SELECTREG 0x09e + #define SEL3 0x0008 + #define SEL2 0x0004 + #define SEL1 0x0002 + #define SEL0 0x0001 + +static struct pci_device_id vrc4173_id_table[] __devinitdata = { + { .vendor = PCI_VENDOR_ID_NEC, + .device = PCI_DEVICE_ID_NEC_VRC4173, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, }, + { .vendor = 0, }, }; unsigned long vrc4173_io_offset = 0; EXPORT_SYMBOL(vrc4173_io_offset); -static u16 vrc4173_cmuclkmsk; static int vrc4173_initialized; +static uint16_t vrc4173_cmuclkmsk; +static uint16_t vrc4173_selectreg; +static spinlock_t vrc4173_cmu_lock; +static spinlock_t vrc4173_giu_lock; -void vrc4173_clock_supply(u16 mask) +static inline void set_cmusrst(uint16_t val) +{ + uint16_t cmusrst; + + cmusrst = vrc4173_inw(VRC4173_CMUSRST); + cmusrst |= val; + vrc4173_outw(cmusrst, VRC4173_CMUSRST); +} + +static inline void clear_cmusrst(uint16_t val) +{ + uint16_t cmusrst; + + cmusrst = vrc4173_inw(VRC4173_CMUSRST); + cmusrst &= ~val; + vrc4173_outw(cmusrst, VRC4173_CMUSRST); +} + +void vrc4173_supply_clock(vrc4173_clock_t clock) { if (vrc4173_initialized) { - vrc4173_cmuclkmsk |= mask; + spin_lock_irq(&vrc4173_cmu_lock); + + switch (clock) { + case VRC4173_PIU_CLOCK: + vrc4173_cmuclkmsk |= MSKPIU; + break; + case VRC4173_KIU_CLOCK: + vrc4173_cmuclkmsk |= MSKKIU; + break; + case VRC4173_AIU_CLOCK: + vrc4173_cmuclkmsk |= MSKAIU; + break; + case VRC4173_PS2_CH1_CLOCK: + vrc4173_cmuclkmsk |= MSKPS2CH1; + break; + case VRC4173_PS2_CH2_CLOCK: + vrc4173_cmuclkmsk |= MSKPS2CH2; + break; + case VRC4173_USBU_PCI_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk |= MSKUSB; + break; + case VRC4173_CARDU1_PCI_CLOCK: + set_cmusrst(CARD1RST); + vrc4173_cmuclkmsk |= MSKCARD1; + break; + case VRC4173_CARDU2_PCI_CLOCK: + set_cmusrst(CARD2RST); + vrc4173_cmuclkmsk |= MSKCARD2; + break; + case VRC4173_AC97U_PCI_CLOCK: + set_cmusrst(AC97RST); + vrc4173_cmuclkmsk |= MSKAC97; + break; + case VRC4173_USBU_48MHz_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk |= MSK48MUSB; + break; + case VRC4173_EXT_48MHz_CLOCK: + if (vrc4173_cmuclkmsk & MSK48MOSC) + vrc4173_cmuclkmsk |= MSK48MPIN; + else + printk(KERN_WARNING + "vrc4173_supply_clock: " + "Please supply VRC4173_48MHz_CLOCK first " + "rather than VRC4173_EXT_48MHz_CLOCK.\n"); + break; + case VRC4173_48MHz_CLOCK: + vrc4173_cmuclkmsk |= MSK48MOSC; + break; + default: + printk(KERN_WARNING + "vrc4173_supply_clock: Invalid CLOCK value %u\n", clock); + break; + } + vrc4173_outw(vrc4173_cmuclkmsk, VRC4173_CMUCLKMSK); + + switch (clock) { + case VRC4173_USBU_PCI_CLOCK: + case VRC4173_USBU_48MHz_CLOCK: + clear_cmusrst(USBRST); + break; + case VRC4173_CARDU1_PCI_CLOCK: + clear_cmusrst(CARD1RST); + break; + case VRC4173_CARDU2_PCI_CLOCK: + clear_cmusrst(CARD2RST); + break; + case VRC4173_AC97U_PCI_CLOCK: + clear_cmusrst(AC97RST); + break; + default: + break; + } + + spin_unlock_irq(&vrc4173_cmu_lock); } } -void vrc4173_clock_mask(u16 mask) +EXPORT_SYMBOL(vrc4173_supply_clock); + +void vrc4173_mask_clock(vrc4173_clock_t clock) { if (vrc4173_initialized) { - vrc4173_cmuclkmsk &= ~mask; + spin_lock_irq(&vrc4173_cmu_lock); + + switch (clock) { + case VRC4173_PIU_CLOCK: + vrc4173_cmuclkmsk &= ~MSKPIU; + break; + case VRC4173_KIU_CLOCK: + vrc4173_cmuclkmsk &= ~MSKKIU; + break; + case VRC4173_AIU_CLOCK: + vrc4173_cmuclkmsk &= ~MSKAIU; + break; + case VRC4173_PS2_CH1_CLOCK: + vrc4173_cmuclkmsk &= ~MSKPS2CH1; + break; + case VRC4173_PS2_CH2_CLOCK: + vrc4173_cmuclkmsk &= ~MSKPS2CH2; + break; + case VRC4173_USBU_PCI_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk &= ~MSKUSB; + break; + case VRC4173_CARDU1_PCI_CLOCK: + set_cmusrst(CARD1RST); + vrc4173_cmuclkmsk &= ~MSKCARD1; + break; + case VRC4173_CARDU2_PCI_CLOCK: + set_cmusrst(CARD2RST); + vrc4173_cmuclkmsk &= ~MSKCARD2; + break; + case VRC4173_AC97U_PCI_CLOCK: + set_cmusrst(AC97RST); + vrc4173_cmuclkmsk &= ~MSKAC97; + break; + case VRC4173_USBU_48MHz_CLOCK: + set_cmusrst(USBRST); + vrc4173_cmuclkmsk &= ~MSK48MUSB; + break; + case VRC4173_EXT_48MHz_CLOCK: + vrc4173_cmuclkmsk &= ~MSK48MPIN; + break; + case VRC4173_48MHz_CLOCK: + vrc4173_cmuclkmsk &= ~MSK48MOSC; + break; + default: + printk(KERN_WARNING "vrc4173_mask_clock: Invalid CLOCK value %u\n", clock); + break; + } + vrc4173_outw(vrc4173_cmuclkmsk, VRC4173_CMUCLKMSK); + + switch (clock) { + case VRC4173_USBU_PCI_CLOCK: + case VRC4173_USBU_48MHz_CLOCK: + clear_cmusrst(USBRST); + break; + case VRC4173_CARDU1_PCI_CLOCK: + clear_cmusrst(CARD1RST); + break; + case VRC4173_CARDU2_PCI_CLOCK: + clear_cmusrst(CARD2RST); + break; + case VRC4173_AC97U_PCI_CLOCK: + clear_cmusrst(AC97RST); + break; + default: + break; + } + + spin_unlock_irq(&vrc4173_cmu_lock); } } +EXPORT_SYMBOL(vrc4173_mask_clock); + static inline void vrc4173_cmu_init(void) { vrc4173_cmuclkmsk = vrc4173_inw(VRC4173_CMUCLKMSK); -} -EXPORT_SYMBOL(vrc4173_clock_supply); -EXPORT_SYMBOL(vrc4173_clock_mask); + spin_lock_init(&vrc4173_cmu_lock); +} -void vrc4173_select_function(int func) +void vrc4173_select_function(vrc4173_function_t function) { - u16 val; - if (vrc4173_initialized) { - val = vrc4173_inw(VRC4173_SELECTREG); - switch(func) { - case PS2CH1_SELECT: - val |= 0x0004; + spin_lock_irq(&vrc4173_giu_lock); + + switch(function) { + case PS2_CHANNEL1: + vrc4173_selectreg |= SEL2; break; - case PS2CH2_SELECT: - val |= 0x0002; + case PS2_CHANNEL2: + vrc4173_selectreg |= SEL1; break; - case TOUCHPANEL_SELECT: - val &= 0x0007; + case TOUCHPANEL: + vrc4173_selectreg &= SEL2 | SEL1 | SEL0; break; - case KIU8_SELECT: - val &= 0x000e; + case KEYBOARD_8SCANLINES: + vrc4173_selectreg &= SEL3 | SEL2 | SEL1; break; - case KIU10_SELECT: - val &= 0x000c; + case KEYBOARD_10SCANLINES: + vrc4173_selectreg &= SEL3 | SEL2; break; - case KIU12_SELECT: - val &= 0x0008; + case KEYBOARD_12SCANLINES: + vrc4173_selectreg &= SEL3; break; - case GPIO_SELECT: - val |= 0x0008; + case GPIO_0_15PINS: + vrc4173_selectreg |= SEL0; + break; + case GPIO_16_20PINS: + vrc4173_selectreg |= SEL3; break; } - vrc4173_outw(val, VRC4173_SELECTREG); + + vrc4173_outw(vrc4173_selectreg, VRC4173_SELECTREG); + + spin_unlock_irq(&vrc4173_giu_lock); } } EXPORT_SYMBOL(vrc4173_select_function); +static inline void vrc4173_giu_init(void) +{ + vrc4173_selectreg = vrc4173_inw(VRC4173_SELECTREG); + + spin_lock_init(&vrc4173_giu_lock); +} + static void enable_vrc4173_irq(unsigned int irq) { - u16 val; + uint16_t val; val = vrc4173_inw(VRC4173_MSYSINT1REG); - val |= (u16)1 << (irq - VRC4173_IRQ_BASE); + val |= (uint16_t)1 << (irq - VRC4173_IRQ_BASE); vrc4173_outw(val, VRC4173_MSYSINT1REG); } static void disable_vrc4173_irq(unsigned int irq) { - u16 val; + uint16_t val; val = vrc4173_inw(VRC4173_MSYSINT1REG); - val &= ~((u16)1 << (irq - VRC4173_IRQ_BASE)); + val &= ~((uint16_t)1 << (irq - VRC4173_IRQ_BASE)); vrc4173_outw(val, VRC4173_MSYSINT1REG); } @@ -157,19 +350,18 @@ } static struct hw_interrupt_type vrc4173_irq_type = { - "VRC4173", - startup_vrc4173_irq, - shutdown_vrc4173_irq, - enable_vrc4173_irq, - disable_vrc4173_irq, - ack_vrc4173_irq, - end_vrc4173_irq, - NULL + .typename = "VRC4173", + .startup = startup_vrc4173_irq, + .shutdown = shutdown_vrc4173_irq, + .enable = enable_vrc4173_irq, + .disable = disable_vrc4173_irq, + .ack = ack_vrc4173_irq, + .end = end_vrc4173_irq, }; static int vrc4173_get_irq_number(int irq) { - u16 status, mask; + uint16_t status, mask; int i; status = vrc4173_inw(VRC4173_SYSINT1REG); @@ -179,18 +371,18 @@ if (status) { for (i = 0; i < 16; i++) if (status & (0x0001 << i)) - return VRC4173_IRQ_BASE + i; + return VRC4173_IRQ(i); } return -EINVAL; } -static inline void vrc4173_icu_init(int cascade_irq) +static inline int vrc4173_icu_init(int cascade_irq) { int i; if (cascade_irq < GIU_IRQ(0) || cascade_irq > GIU_IRQ(15)) - return; + return -EINVAL; vrc4173_outw(0, VRC4173_MSYSINT1REG); @@ -199,33 +391,38 @@ for (i = VRC4173_IRQ_BASE; i <= VRC4173_IRQ_LAST; i++) irq_desc[i].handler = &vrc4173_irq_type; + + return 0; } -static int __devinit vrc4173_probe(struct pci_dev *pdev, - const struct pci_device_id *ent) +static int __devinit vrc4173_probe(struct pci_dev *dev, + const struct pci_device_id *id) { unsigned long start, flags; int err; - if ((err = pci_enable_device(pdev)) < 0) { - printk(KERN_ERR "vrc4173: failed to enable device -- err=%d\n", err); + err = pci_enable_device(dev); + if (err < 0) { + printk(KERN_ERR "vrc4173: Failed to enable PCI device, aborting\n"); return err; } - pci_set_master(pdev); + pci_set_master(dev); - start = pci_resource_start(pdev, 0); - if (!start) { - printk(KERN_ERR "vrc4173:No PCI I/O resources, aborting\n"); - return -ENODEV; + start = pci_resource_start(dev, 0); + if (start == 0) { + printk(KERN_ERR "vrc4173:No such PCI I/O resource, aborting\n"); + return -ENXIO; } - if (!start || (((flags = pci_resource_flags(pdev, 0)) & IORESOURCE_IO) == 0)) { - printk(KERN_ERR "vrc4173: No PCI I/O resources, aborting\n"); - return -ENODEV; + flags = pci_resource_flags(dev, 0); + if ((flags & IORESOURCE_IO) == 0) { + printk(KERN_ERR "vrc4173: No such PCI I/O resource, aborting\n"); + return -ENXIO; } - if ((err = pci_request_regions(pdev, "NEC VRC4173")) < 0) { + err = pci_request_regions(dev, "NEC VRC4173"); + if (err < 0) { printk(KERN_ERR "vrc4173: PCI resources are busy, aborting\n"); return err; } @@ -233,25 +430,37 @@ set_vrc4173_io_offset(start); vrc4173_cmu_init(); + vrc4173_giu_init(); - vrc4173_icu_init(pdev->irq); + err = vrc4173_icu_init(dev->irq); + if (err < 0) { + printk(KERN_ERR "vrc4173: Invalid IRQ %d, aborting\n", dev->irq); + return err; + } - if ((err = vr41xx_cascade_irq(pdev->irq, vrc4173_get_irq_number)) < 0) { - printk(KERN_ERR - "vrc4173: IRQ resource %d is busy, aborting\n", pdev->irq); + err = vr41xx_cascade_irq(dev->irq, vrc4173_get_irq_number); + if (err < 0) { + printk(KERN_ERR "vrc4173: IRQ resource %d is busy, aborting\n", dev->irq); return err; } printk(KERN_INFO - "NEC VRC4173 at 0x%#08lx, IRQ is cascaded to %d\n", start, pdev->irq); + "NEC VRC4173 at 0x%#08lx, IRQ is cascaded to %d\n", start, dev->irq); return 0; } +static void vrc4173_remove(struct pci_dev *dev) +{ + free_irq(dev->irq, NULL); + + pci_release_regions(dev); +} + static struct pci_driver vrc4173_driver = { .name = "NEC VRC4173", .probe = vrc4173_probe, - .remove = NULL, + .remove = vrc4173_remove, .id_table = vrc4173_table, }; @@ -259,7 +468,8 @@ { int err; - if ((err = pci_module_init(&vrc4173_driver)) < 0) + err = pci_module_init(&vrc4173_driver); + if (err < 0) return err; vrc4173_initialized = 1; diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h --- linux-orig/include/asm-mips/vr41xx/vrc4173.h Sat Dec 20 01:49:05 2003 +++ linux/include/asm-mips/vr41xx/vrc4173.h Fri May 14 00:32:07 2004 @@ -1,19 +1,24 @@ /* - * FILE NAME - * include/asm-mips/vr41xx/vrc4173.h + * vrc4173.h, Include file for NEC VRC4173. * - * BRIEF MODULE DESCRIPTION - * Include file for NEC VRC4173. + * Copyright (C) 2000 Michael R. McDonald + * Copyright (C) 2001-2003 Montavista Software Inc. + * Author: Yoichi Yuasa + * Copyright (C) 2004 Yoichi Yuasa * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * Copyright (C) 2000 by Michael R. McDonald + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. * - * Copyright 2001-2003 Montavista Software Inc. - * Author: Yoichi Yuasa - * yyuasa@mvista.com or source@mvista.com + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef __NEC_VRC4173_H #define __NEC_VRC4173_H @@ -72,35 +77,38 @@ /* * Clock Mask Unit */ -#define VRC4173_PIU_CLOCK 0x0001 -#define VRC4173_KIU_CLOCK 0x0002 -#define VRC4173_AIU_CLOCK 0x0004 -#define VRC4173_PS2CH1_CLOCK 0x0008 -#define VRC4173_PS2CH2_CLOCK 0x0010 -#define VRC4173_USBU_PCI_CLOCK 0x0020 -#define VRC4173_CARDU1_PCI_CLOCK 0x0040 -#define VRC4173_CARDU2_PCI_CLOCK 0x0080 -#define VRC4173_AC97U_PCI_CLOCK 0x0100 -#define VRC4173_USBU_48MHz_CLOCK 0x0400 -#define VRC4173_EXT_48MHz_CLOCK 0x0800 -#define VRC4173_48MHz_CLOCK 0x1000 +enum vrc4173_clock { + VRC4173_PIU_CLOCK, + VRC4173_KIU_CLOCK, + VRC4173_AIU_CLOCK, + VRC4173_PS2_CH1_CLOCK, + VRC4173_PS2_CH2_CLOCK, + VRC4173_USBU_PCI_CLOCK, + VRC4173_CARDU1_PCI_CLOCK, + VRC4173_CARDU2_PCI_CLOCK, + VRC4173_AC97U_PCI_CLOCK, + VRC4173_USBU_48MHz_CLOCK, + VRC4173_EXT_48MHz_CLOCK, + VRC4173_48MHz_CLOCK, +} vrc4173_clock_t; -extern void vrc4173_clock_supply(u16 mask); -extern void vrc4173_clock_mask(u16 mask); +extern void vrc4173_supply_clock(vrc4173_clock_t clock); +extern void vrc4173_mask_clock(vrc4173_clock_t clock); /* * General-Purpose I/O Unit */ -enum { - PS2CH1_SELECT, - PS2CH2_SELECT, - TOUCHPANEL_SELECT, - KIU8_SELECT, - KIU10_SELECT, - KIU12_SELECT, - GPIO_SELECT -}; +enum vrc4173_function { + PS2_CHANNEL1, + PS2_CHANNEL2, + TOUCHPANEL, + KEYBOARD_8SCANLINES, + KEYBOARD_10SCANLINES, + KEYBOARD_12SCANLINES, + GPIO_0_15PINS, + GPIO_16_20PINS, +} vrc4173_function_t; -extern void vrc4173_select_function(int func); +extern void vrc4173_select_function(vrc4173_function_t function); #endif /* __NEC_VRC4173_H */ From em@realmagic.fr Wed May 26 17:35:19 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 17:35:22 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:22146 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 17:35:19 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4QGZHsL020228 for ; Wed, 26 May 2004 18:35:17 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4QGZGRp020226 for linux-mips@linux-mips.org; Wed, 26 May 2004 18:35:16 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? From: Emmanuel Michon To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1085589315.2306.49.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 26 May 2004 18:35:16 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips Hi, I'm porting linux for a MIPS 4KEc based design; my knowledge of MIPS CPUs generations is still rudimentary but I know for sure this one has both features from R3000 arch but some of R4000 as well (cache, lld/scd --- according to the software user's manual) but it is definitely a 32bit processor. The implementation of down_trylock on linuxmips-2.4.25 is: --------------------------------------------- static inline int down_trylock(struct semaphore * sem) { long ret, tmp, tmp2, sub; #if WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif __asm__ __volatile__( " .set mips3 # down_trylock \n" "0: lld %1, %4 \n" " dli %3, 0x0000000100000000 # count -= 1 \n" " dsubu %1, %3 \n" " li %0, 0 # ret = 0 \n" " bgez %1, 2f # if count >= 0 \n" " sll %2, %1, 0 # extract waking \n" " blez %2, 1f # if waking < 0 -> 1f \n" " daddiu %1, %1, -1 # waking -= 1 \n" " b 2f \n" "1: daddu %1, %1, %3 # count += 1 \n" " li %0, 1 # ret = 1 \n" "2: scd %1, %4 \n" " beqz %1, 0b \n" " sync \n" " .set mips0 \n" : "=&r"(ret), "=&r"(tmp), "=&r"(tmp2), "=&r"(sub) : "m"(*sem) : "memory"); return ret; } --------------------------------------------- and after synthesized assembly dli becomes: a90: 34048000 li a0,0x8000 a94: 00042478 dsll a0,a0,0x11 which is a0=0 (wrong). Why is this computation done on 64bit? Should I workaround a 32bit implementation of this? Subsidiary question: since the 4KEc core is not mentioned explicitely in mips gas possible CPUs, I build the kernel code with: mipsel-linux-gcc -march=r4600 -mips2 -Wa,-32 -Wa,-march=r4600 -Wa,-mips3 with gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113.2) neon Is this the correct option? Thanks a lot for any clue, Sincerely yours, E.M. From kevink@mips.com Wed May 26 17:56:22 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 17:56:28 +0100 (BST) Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:44685 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 17:56:14 +0100 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.11/8.12.11) with ESMTP id i4QGiI1H003481; Wed, 26 May 2004 09:44:18 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i4QGu4DW017689; Wed, 26 May 2004 09:56:05 -0700 (PDT) Message-ID: <012b01c44342$c3ec91e0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Emmanuel Michon" , References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? Date: Wed, 26 May 2004 18:59:08 +0200 Organization: MIPS Technologies Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5182 X-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 Content-Length: 2185 Lines: 83 Are you sure you've specified your CPU type as "MIPS32"? ----- Original Message ----- From: "Emmanuel Michon" To: Sent: Wednesday, May 26, 2004 18:35 Subject: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? > Hi, > > I'm porting linux for a MIPS 4KEc based design; > > my knowledge of MIPS CPUs generations is still rudimentary but I know > for sure this one has both features from R3000 arch but some of > R4000 as well (cache, lld/scd --- according to the software user's > manual) > > but it is definitely a 32bit processor. > > The implementation of down_trylock on linuxmips-2.4.25 is: > > --------------------------------------------- > static inline int down_trylock(struct semaphore * sem) > { > long ret, tmp, tmp2, sub; > > #if WAITQUEUE_DEBUG > CHECK_MAGIC(sem->__magic); > #endif > > __asm__ __volatile__( > " .set mips3 # down_trylock \n" > "0: lld %1, %4 \n" > " dli %3, 0x0000000100000000 # count -= 1 \n" > " dsubu %1, %3 \n" > " li %0, 0 # ret = 0 \n" > " bgez %1, 2f # if count >= 0 \n" > " sll %2, %1, 0 # extract waking \n" > " blez %2, 1f # if waking < 0 -> 1f \n" > " daddiu %1, %1, -1 # waking -= 1 \n" > " b 2f \n" > "1: daddu %1, %1, %3 # count += 1 \n" > " li %0, 1 # ret = 1 \n" > "2: scd %1, %4 \n" > " beqz %1, 0b \n" > " sync \n" > " .set mips0 \n" > : "=&r"(ret), "=&r"(tmp), "=&r"(tmp2), "=&r"(sub) > : "m"(*sem) > : "memory"); > > return ret; > } > --------------------------------------------- > > and after synthesized assembly dli becomes: > > a90: 34048000 li a0,0x8000 > a94: 00042478 dsll a0,a0,0x11 > > which is a0=0 (wrong). > > Why is this computation done on 64bit? Should I workaround a 32bit > implementation of this? > > Subsidiary question: since the 4KEc core is not mentioned explicitely > in mips gas possible CPUs, I build the kernel code with: > > mipsel-linux-gcc -march=r4600 -mips2 -Wa,-32 -Wa,-march=r4600 -Wa,-mips3 > > with gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113.2) neon > > Is this the correct option? > > Thanks a lot for any clue, > > Sincerely yours, > > E.M. > > > From em@realmagic.fr Wed May 26 18:03:48 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 18:03:52 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:43138 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 18:03:40 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4QH3dsL025480; Wed, 26 May 2004 19:03:39 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4QH3deK025478; Wed, 26 May 2004 19:03:39 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? From: Emmanuel Michon To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org In-Reply-To: <012b01c44342$c3ec91e0$10eca8c0@grendel> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <012b01c44342$c3ec91e0$10eca8c0@grendel> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1085591018.2306.82.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 26 May 2004 19:03:38 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips Content-Length: 2818 Lines: 103 On Wed, 2004-05-26 at 18:59, Kevin D. Kissell wrote: > Are you sure you've specified your CPU type as "MIPS32"? No, because this choice of CPU CONFIG_MIPS32 is exclusive with CONFIG_CPU_R3000 and CONFIG_CPU_R4X00 I do use CONFIG_CPU_R4X00 so that appropriate cache routines are used I now realize that the 4KEc has ll/sc but not the 64bit versions lld/scd...! so I force disabled the CONFIG_CPU_HAS_LLDSCD. I'd prefer to find the appropriate combination of flags to get things right though... Sincerely yours, E.M. > > ----- Original Message ----- > From: "Emmanuel Michon" > To: > Sent: Wednesday, May 26, 2004 18:35 > Subject: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? > > > > Hi, > > > > I'm porting linux for a MIPS 4KEc based design; > > > > my knowledge of MIPS CPUs generations is still rudimentary but I know > > for sure this one has both features from R3000 arch but some of > > R4000 as well (cache, lld/scd --- according to the software user's > > manual) > > > > but it is definitely a 32bit processor. > > > > The implementation of down_trylock on linuxmips-2.4.25 is: > > > > --------------------------------------------- > > static inline int down_trylock(struct semaphore * sem) > > { > > long ret, tmp, tmp2, sub; > > > > #if WAITQUEUE_DEBUG > > CHECK_MAGIC(sem->__magic); > > #endif > > > > __asm__ __volatile__( > > " .set mips3 # down_trylock \n" > > "0: lld %1, %4 \n" > > " dli %3, 0x0000000100000000 # count -= 1 \n" > > " dsubu %1, %3 \n" > > " li %0, 0 # ret = 0 \n" > > " bgez %1, 2f # if count >= 0 \n" > > " sll %2, %1, 0 # extract waking \n" > > " blez %2, 1f # if waking < 0 -> 1f \n" > > " daddiu %1, %1, -1 # waking -= 1 \n" > > " b 2f \n" > > "1: daddu %1, %1, %3 # count += 1 \n" > > " li %0, 1 # ret = 1 \n" > > "2: scd %1, %4 \n" > > " beqz %1, 0b \n" > > " sync \n" > > " .set mips0 \n" > > : "=&r"(ret), "=&r"(tmp), "=&r"(tmp2), "=&r"(sub) > > : "m"(*sem) > > : "memory"); > > > > return ret; > > } > > --------------------------------------------- > > > > and after synthesized assembly dli becomes: > > > > a90: 34048000 li a0,0x8000 > > a94: 00042478 dsll a0,a0,0x11 > > > > which is a0=0 (wrong). > > > > Why is this computation done on 64bit? Should I workaround a 32bit > > implementation of this? > > > > Subsidiary question: since the 4KEc core is not mentioned explicitely > > in mips gas possible CPUs, I build the kernel code with: > > > > mipsel-linux-gcc -march=r4600 -mips2 -Wa,-32 -Wa,-march=r4600 -Wa,-mips3 > > > > with gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113.2) neon > > > > Is this the correct option? > > > > Thanks a lot for any clue, > > > > Sincerely yours, > > > > E.M. > > > > > > > From macro@ds2.pg.gda.pl Wed May 26 18:17:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 18:17:19 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:5526 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 18:17:07 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 261F84B8DA; Wed, 26 May 2004 19:16:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id A04744ADBD; Wed, 26 May 2004 19:16:52 +0200 (CEST) Date: Wed, 26 May 2004 19:16:49 +0200 (CEST) From: "Maciej W. Rozycki" To: Emmanuel Michon Cc: "Kevin D. Kissell" , linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? In-Reply-To: <1085591018.2306.82.camel@avalon.france.sdesigns.com> Message-ID: References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <012b01c44342$c3ec91e0$10eca8c0@grendel> <1085591018.2306.82.camel@avalon.france.sdesigns.com> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 649 Lines: 19 On Wed, 26 May 2004, Emmanuel Michon wrote: > No, because this choice of CPU CONFIG_MIPS32 > is exclusive with CONFIG_CPU_R3000 and CONFIG_CPU_R4X00 > > I do use CONFIG_CPU_R4X00 so that appropriate cache routines are used Well, the cache routines for both CONFIG_CPU_R4X00 and CONFIG_MIPS32 are the same. > I'd prefer to find the appropriate combination of flags to get things > right though... The defaults for CONFIG_MIPS32 should be OK. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From em@realmagic.fr Wed May 26 18:28:33 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 18:28:37 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:56194 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 18:28:25 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4QHS2sL026621; Wed, 26 May 2004 19:28:02 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4QHRvoW026619; Wed, 26 May 2004 19:27:57 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? From: Emmanuel Michon To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , linux-mips@linux-mips.org In-Reply-To: References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <012b01c44342$c3ec91e0$10eca8c0@grendel> <1085591018.2306.82.camel@avalon.france.sdesigns.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1085592477.20233.111.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 26 May 2004 19:27:57 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips Content-Length: 697 Lines: 24 On Wed, 2004-05-26 at 19:16, Maciej W. Rozycki wrote: > On Wed, 26 May 2004, Emmanuel Michon wrote: > > > No, because this choice of CPU CONFIG_MIPS32 > > is exclusive with CONFIG_CPU_R3000 and CONFIG_CPU_R4X00 > > > > I do use CONFIG_CPU_R4X00 so that appropriate cache routines are used > > Well, the cache routines for both CONFIG_CPU_R4X00 and CONFIG_MIPS32 are > the same. > > > I'd prefer to find the appropriate combination of flags to get things > > right though... > > The defaults for CONFIG_MIPS32 should be OK. What is the difference between CONFIG_CPU_MIPS32 and CONFIG_MIPS32? If I just set CONFIG_MIPS32 the CPU is still default CONFIG_CPU_R5000. Sincerely yours, E.M. From macro@ds2.pg.gda.pl Wed May 26 18:41:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 18:41:08 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:49052 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 18:40:56 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 3CC5D4B318; Wed, 26 May 2004 19:40:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 3204F4AC7D; Wed, 26 May 2004 19:40:43 +0200 (CEST) Date: Wed, 26 May 2004 19:40:43 +0200 (CEST) From: "Maciej W. Rozycki" To: Emmanuel Michon Cc: "Kevin D. Kissell" , linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bitarithmetics? In-Reply-To: <1085592477.20233.111.camel@avalon.france.sdesigns.com> Message-ID: References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <012b01c44342$c3ec91e0$10eca8c0@grendel> <1085591018.2306.82.camel@avalon.france.sdesigns.com> <1085592477.20233.111.camel@avalon.france.sdesigns.com> Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 1098 Lines: 29 On Wed, 26 May 2004, Emmanuel Michon wrote: > > > No, because this choice of CPU CONFIG_MIPS32 > > > is exclusive with CONFIG_CPU_R3000 and CONFIG_CPU_R4X00 > > > > > > I do use CONFIG_CPU_R4X00 so that appropriate cache routines are used > > > > Well, the cache routines for both CONFIG_CPU_R4X00 and CONFIG_MIPS32 are > > the same. > > > > > I'd prefer to find the appropriate combination of flags to get things > > > right though... > > > > The defaults for CONFIG_MIPS32 should be OK. > > What is the difference between CONFIG_CPU_MIPS32 and CONFIG_MIPS32? Oops -- I've meant CONFIG_CPU_MIPS32, of course, which selects a MIPS32 ISA compliant CPU. CONFIG_MIPS32 (together with CONFIG_MIPS64) selects between a 32-bit and a 64-bit kernel, and for 2.4 it's not directly settable -- it's implied by the architecture selected with the ARCH Makefile variable. Sorry for the confusion. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Wed May 26 17:54:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 17:55:06 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:44323 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 17:54:00 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QGrtlB006965; Wed, 26 May 2004 18:53:55 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QGrte8006964; Wed, 26 May 2004 18:53:55 +0200 Date: Wed, 26 May 2004 18:53:55 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][2/14] vr41xx: GIUINT routines renewal Message-ID: <20040526165355.GC30047@linux-mips.org> References: <20040527005035.4ded334f.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005035.4ded334f.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5181 X-Approved-By: ralf@linux-mips.org X-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 Content-Length: 169 Lines: 10 On Thu, May 27, 2004 at 12:50:35AM +0900, Yoichi Yuasa wrote: > The GIUINT routine and ICU routines was renewed. > > Please apply to v2.6 CVS tree. Applied, Ralf From ralf@linux-mips.org Wed May 26 18:58:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 19:01:08 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:34596 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 18:58:22 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QHwIs9015301; Wed, 26 May 2004 19:58:18 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QHwI4h015300; Wed, 26 May 2004 19:58:18 +0200 Date: Wed, 26 May 2004 19:58:18 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][5/14] vr41xx: update fixup-capcella.c Message-ID: <20040526175818.GE30047@linux-mips.org> References: <20040527005112.7dc0ae6c.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005112.7dc0ae6c.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5187 X-Approved-By: ralf@linux-mips.org X-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 Content-Length: 151 Lines: 11 On Thu, May 27, 2004 at 12:51:12AM +0900, Yoichi Yuasa wrote: > fixup-capcella.c was updated. > > Please apply to v2.6 CVS tree. Applied, Ralf From ralf@linux-mips.org Wed May 26 19:15:00 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 19:19:09 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:48932 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 19:14:43 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QIEgxV015729 for ; Wed, 26 May 2004 20:14:42 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QIEgS3015728 for linux-mips@linux-mips.org; Wed, 26 May 2004 20:14:42 +0200 Resent-Message-Id: <200405261814.i4QIEgS3015728@fluff.linux-mips.net> Date: Wed, 26 May 2004 19:55:06 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][4/14] vr41xx: add fixup-tb0219.c Message-ID: <20040526175506.GD30047@linux-mips.org> References: <20040527005104.40832d5f.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005104.40832d5f.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.1i Resent-From: ralf@linux-mips.org Resent-Date: Wed, 26 May 2004 20:14:42 +0200 Resent-To: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5188 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:51:04AM +0900, Yoichi Yuasa wrote: > fixup-tb0219.c was added. > > Please apply to v2.6 CVS tree. Applying this one. The plan is that this function eventually will be replaced by a table-driven approach, so better don't use it for doing anything else than just returning the interrupt number. Ralf From ralf@linux-mips.org Wed May 26 19:40:11 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 19:46:03 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:6693 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 19:40:02 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QIdwx5016307; Wed, 26 May 2004 20:39:58 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QIdvfX016306; Wed, 26 May 2004 20:39:57 +0200 Date: Wed, 26 May 2004 20:39:57 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][6/14] vr41xx: update fixup-tb0226.c Message-ID: <20040526183957.GF30047@linux-mips.org> References: <20040527005121.5cfa0d93.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005121.5cfa0d93.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5189 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:51:21AM +0900, Yoichi Yuasa wrote: > fixup-tb0226.c was updated. > > Please apply to v2.6 CVS tree. Applied - but the same comment as to the fixup-tb0219 patch applies here as well, Ralf From ralf@linux-mips.org Wed May 26 19:45:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 19:51:03 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:13349 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 19:45:29 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QIjP1T023298; Wed, 26 May 2004 20:45:25 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QIjPjI023297; Wed, 26 May 2004 20:45:25 +0200 Date: Wed, 26 May 2004 20:45:25 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][7/14] vr41xx: update fixup-mpc30x.c Message-ID: <20040526184525.GG30047@linux-mips.org> References: <20040527005128.020b08a9.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005128.020b08a9.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5190 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:51:28AM +0900, Yoichi Yuasa wrote: > fixup-mpc30x.c was updated. Applied, Ralf From ralf@linux-mips.org Wed May 26 20:32:30 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 20:33:51 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:49701 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 20:32:21 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QJWGMD025207; Wed, 26 May 2004 21:32:16 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QJWGS4025206; Wed, 26 May 2004 21:32:16 +0200 Date: Wed, 26 May 2004 21:32:16 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][8/14] vr41xx: update PCIU initialization function Message-ID: <20040526193216.GH30047@linux-mips.org> References: <20040527005139.63740a65.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005139.63740a65.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5191 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:51:39AM +0900, Yoichi Yuasa wrote: > The PCIU initialization function was updated. Applied, Ralf From ralf@linux-mips.org Wed May 26 20:47:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 20:49:05 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:3622 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 20:47:38 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QJlX7Q000627; Wed, 26 May 2004 21:47:33 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QJlXBv000626; Wed, 26 May 2004 21:47:33 +0200 Date: Wed, 26 May 2004 21:47:33 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][9/14] vr41xx: update setup.c for TANBAC TB0229 Message-ID: <20040526194733.GK30047@linux-mips.org> References: <20040527005149.3b13c972.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005149.3b13c972.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5192 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:51:49AM +0900, Yoichi Yuasa wrote: > setup.c for TANBAC TB0229 was updated. > > Please apply to v2.6 CVS tree. Applied, Ralf From ralf@linux-mips.org Wed May 26 20:57:10 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 21:00:01 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:15398 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 20:57:02 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QJuw43007765; Wed, 26 May 2004 21:56:58 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QJuwIt007764; Wed, 26 May 2004 21:56:58 +0200 Date: Wed, 26 May 2004 21:56:57 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][10/14] vr41xx: update setup.c for TANBAC TB0226 Message-ID: <20040526195657.GL30047@linux-mips.org> References: <20040527005156.7d3073a5.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005156.7d3073a5.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5193 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:51:56AM +0900, Yoichi Yuasa wrote: > setup.c for TANBAC TB0226 was updated. > > Please apply to v2.6 CVS tree. Applied, Ralf From ralf@linux-mips.org Wed May 26 20:59:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 21:01:37 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:20006 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 20:59:50 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QJxjpp007839; Wed, 26 May 2004 21:59:45 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QJxj2M007838; Wed, 26 May 2004 21:59:45 +0200 Date: Wed, 26 May 2004 21:59:45 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][11/14] vr41xx: update setup.c for ZAO Networks Capcella Message-ID: <20040526195945.GM30047@linux-mips.org> References: <20040527005206.6e8ecb18.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005206.6e8ecb18.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5194 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:52:06AM +0900, Yoichi Yuasa wrote: > setup.c for ZAO Networks Capcella was updated. Applied, Ralf From ralf@linux-mips.org Wed May 26 21:02:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 21:04:39 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:25382 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 21:02:33 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QK2USp007970; Wed, 26 May 2004 22:02:30 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QK2TJr007969; Wed, 26 May 2004 22:02:29 +0200 Date: Wed, 26 May 2004 22:02:29 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][12/14] vr41xx: update setup.c for Victor MP-C30x Message-ID: <20040526200229.GN30047@linux-mips.org> References: <20040527005214.64ddfa46.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005214.64ddfa46.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5195 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:52:14AM +0900, Yoichi Yuasa wrote: > setup.c for Victor MP-C30x was updated. > > Please apply to v2.6 CVS tree. Applied, Ralf From ralf@linux-mips.org Wed May 26 21:15:13 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 21:18:10 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:37670 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 21:15:04 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QKF0YW008273; Wed, 26 May 2004 22:15:00 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QKF0Tw008272; Wed, 26 May 2004 22:15:00 +0200 Date: Wed, 26 May 2004 22:15:00 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][14/14] vr41xx: vrc4173.c synchronizes with latest Message-ID: <20040526201500.GO30047@linux-mips.org> References: <20040527005231.0d0c03b1.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005231.0d0c03b1.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.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: 5196 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:52:31AM +0900, Yoichi Yuasa wrote: > vrc4173.c synchronizes with latest. Applied also. Ralf From ralf@linux-mips.org Wed May 26 21:22:40 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 21:24:31 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:46374 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 21:22:31 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QKMUmL008506 for ; Wed, 26 May 2004 22:22:30 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QKMUws008505 for linux-mips@linux-mips.org; Wed, 26 May 2004 22:22:30 +0200 Resent-Message-Id: <200405262022.i4QKMUws008505@fluff.linux-mips.net> Date: Wed, 26 May 2004 18:36:59 +0200 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][1/14] vr41xx: change to early_initcall Message-ID: <20040526163659.GB30047@linux-mips.org> References: <20040527005022.53033dd4.yuasa@hh.iij4u.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527005022.53033dd4.yuasa@hh.iij4u.or.jp> User-Agent: Mutt/1.4.1i Resent-From: ralf@linux-mips.org Resent-Date: Wed, 26 May 2004 22:22:30 +0200 Resent-To: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5197 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 12:50:22AM +0900, Yoichi Yuasa wrote: > The some functions change to early_initcall from the call from prom_init(). > > Please apply to v2.6 CVS tree. Applied, Ralf From ralf@linux-mips.org Wed May 26 21:33:56 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 26 May 2004 21:35:14 +0100 (BST) Received: from p508B6E02.dip.t-dialin.net ([IPv6:::ffff:80.139.110.2]:56102 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 26 May 2004 21:33:47 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4QKXk6q008768; Wed, 26 May 2004 22:33:46 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4QKXkn2008767; Wed, 26 May 2004 22:33:46 +0200 Date: Wed, 26 May 2004 22:33:46 +0200 From: Ralf Baechle To: Emmanuel Michon Cc: linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? Message-ID: <20040526203346.GA8430@linux-mips.org> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1085589315.2306.49.camel@avalon.france.sdesigns.com> User-Agent: Mutt/1.4.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: 5198 X-Approved-By: ralf@linux-mips.org X-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, May 26, 2004 at 06:35:16PM +0200, Emmanuel Michon wrote: Semaphores can be implemented using just a single 32-bit variable which would mean the same code could be used for 32-bit and 64-bit processors as long as only they support ll/sc. Maybe somebody has the time at his hands, *hint*, *hint* :-) Ralf From nilanjan@genesis-microchip.com Thu May 27 09:57:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 09:57:13 +0100 (BST) Received: from [IPv6:::ffff:209.47.22.60] ([IPv6:::ffff:209.47.22.60]:55855 "EHLO TOREXCL1.gmi.domain") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 09:57:01 +0100 Received: from INDIAEXCH.gmi.domain ([10.41.1.181]) by TOREXCL1.gmi.domain with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 May 2004 04:56:57 -0400 content-class: urn:content-classes:message Subject: gp_disp MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C443C8.8EBBB9D1" Date: Thu, 27 May 2004 14:26:54 +0530 Message-ID: <9A45247F1AEBB94189B16E7083981F932360AE@INDIAEXCH.gmi.domain> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: gp_disp Thread-Index: AcRDyI6npOp5US6AQPSkvwQdx35XiQ== From: "Nilanjan Roychowdhury" To: X-OriginalArrivalTime: 27 May 2004 08:56:57.0515 (UTC) FILETIME=[90CDE7B0:01C443C8] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nilanjan@genesis-microchip.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------_=_NextPart_001_01C443C8.8EBBB9D1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a kernel module which works fine with linux X86 combo. But when I try to compile it with mips cross toll chain it compiles well = but insmod gives me error on "_gp_disp" unknown symbol. =20 How do I get rid of that ??? Do I need to do anything special with my = compiler flags. ------_=_NextPart_001_01C443C8.8EBBB9D1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I have a kernel module which works fine with linux X86 = combo.

But when I try to compile it with mips cross toll chain it compiles well but = insmod gives me error on “_gp_disp” unknown symbol.

 

How do I get rid of that = ??? Do I need to do anything special with my compiler = flags.

=00 ------_=_NextPart_001_01C443C8.8EBBB9D1-- From guangxing@ict.ac.cn Thu May 27 10:03:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 10:26:24 +0100 (BST) Received: from mail.ict.ac.cn ([IPv6:::ffff:159.226.39.4]:62376 "HELO mail.ict.ac.cn") by linux-mips.org with SMTP id ; Thu, 27 May 2004 10:03:29 +0100 Received: (qmail 22480 invoked from network); 27 May 2004 08:48:35 -0000 Received: from unknown (HELO xing) (159.226.39.104) by mail.ict.ac.cn with SMTP; 27 May 2004 08:48:35 -0000 Date: Thu, 27 May 2004 16:58:17 +0800 From: "Guangxing Zhang" To: "Nilanjan Roychowdhury" , "linux-mips@linux-mips.org" Subject: Re: gp_disp X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: <20040527090329Z8225763-1530+2702@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5200 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: guangxing@ict.ac.cn Precedence: bulk X-list: linux-mips X2dwX2Rpc3AgaXMgYSBtYWdpYyBzeW1ib2wgcmVmZXJlbmNlcyB0byB3aGljaCBhcmUgb25seSBn ZW5lcmF0ZWQgYnkgdGhlIA0KYXNzZW1ibGVyIHdoZW4gZ2VuZXJhdGluZyBQSUMgY29kZSwgc28g eW91IHNpbXBseSBjb21waWxlZCB1c2luZyB0aGUgDQp3cm9uZyBvcHRpb25zLiBBZGQgYGAtZm5v LXBpYyAtbW5vLWFiaWNhbGxzJycgdG8gdGhlIG9wdGlvbnMgYW5kIHRoaXMgDQpwcm9ibGVtIHdp bGwgZ28gYXdheS4gDQpCVFcsSSBmaW5kIHRoaXMgaW4gZ29vZ2xlLCBtYXkgaXQgd2lsbCBiZSBo ZWxwIHRvIHlvdQkhDQoNCj09PT09PT0gbmlsYW5qYW5AZ2VuZXNpcy1taWNyb2NoaXAuY29tIDIw MDQtMDUtMjcgMTc6MjY6NTQgV1JPVEWjuj09PT09PT0NCg0KPkhpLA0KPkkgaGF2ZSBhIGtlcm5l bCBtb2R1bGUgd2hpY2ggd29ya3MgZmluZSB3aXRoIGxpbnV4IFg4NiBjb21iby4NCj5CdXQgd2hl biBJIHRyeSB0byBjb21waWxlIGl0IHdpdGggbWlwcyBjcm9zcyB0b2xsIGNoYWluIGl0IGNvbXBp bGVzIHdlbGwgYnV0IGluc21vZCBnaXZlcyBtZSBlcnJvciBvbiAiX2dwX2Rpc3AiIHVua25vd24g c3ltYm9sLg0KPiANCj5Ib3cgZG8gSSBnZXQgcmlkIG9mIHRoYXQgPz8/IERvIEkgbmVlZCB0byBk byBhbnl0aGluZyBzcGVjaWFsIHdpdGggbXkgY29tcGlsZXIgZmxhZ3MuDQoNCj0gPSA9ID0gPSA9 ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGh oaGhoUd1YW5neGluZyBaaGFuZw0KoaGhoaGhoaGhoaGhoaGhoWd1YW5neGluZ0BpY3QuYWMuY24N CqGhoaGhoaGhoaGhoaGhoaEyMDA0LTA1LTI3IDE2OjU3OjI0DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KRmFyIGFuZCBhd2F5IHRoZSBiZXN0IHByaXplIHRoYXQgbGlmZSBv ZmZlcnMgaXMgdGhlIGNoYW5jZSB0byB3b3JrIGhhcmQgYXQgd29yayB3b3J0aCBkb2luZy4gDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From ralf@linux-mips.org Thu May 27 10:25:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 10:26:50 +0100 (BST) Received: from p508B5AC4.dip.t-dialin.net ([IPv6:::ffff:80.139.90.196]:51527 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 10:25:26 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4R9PHFK024976; Thu, 27 May 2004 11:25:17 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4R9PGsr024975; Thu, 27 May 2004 11:25:16 +0200 Date: Thu, 27 May 2004 11:25:15 +0200 From: Ralf Baechle To: Nilanjan Roychowdhury Cc: linux-mips@linux-mips.org Subject: Re: gp_disp Message-ID: <20040527092515.GA24811@linux-mips.org> References: <9A45247F1AEBB94189B16E7083981F932360AE@INDIAEXCH.gmi.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A45247F1AEBB94189B16E7083981F932360AE@INDIAEXCH.gmi.domain> User-Agent: Mutt/1.4.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: 5201 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 02:26:54PM +0530, Nilanjan Roychowdhury wrote: > Hi, > I have a kernel module which works fine with linux X86 combo. Which provides aproximately zero proof for the correctness of your code, sorry ... > But when I try to compile it with mips cross toll chain it compiles well > but insmod gives me error on "_gp_disp" unknown symbol. > > How do I get rid of that ??? Do I need to do anything special with my > compiler flags. Read the FAQ, it's described there. Ralf From maksik@gmx.co.uk Thu May 27 12:33:14 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 12:33:18 +0100 (BST) Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:6076 "EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 12:33:05 +0100 Received: from wh85.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77]) by relay1.uniklinik-freiburg.de (Email) with ESMTP id DA29B2F47D for ; Thu, 27 May 2004 13:33:00 +0200 (CEST) From: Max Zaitsev Organization: Mutella Dev co. To: linux-mips@linux-mips.org Subject: help needed : cannot install linux on SGI O2 R5000 Date: Thu, 27 May 2004 13:33:04 +0200 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405271333.04712.maksik@gmx.co.uk> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maksik@gmx.co.uk Precedence: bulk X-list: linux-mips Hi List, couple of days ago I've acquired an oldish O2 box with 180MHz R5k CPU, 256MB ram and ~10GB HD space. Since then I'm trying to get linux installed on that thing, but apparently with no success. I've managed to connect it to a linux box and get bootp() and NFS to work. However, I cannot find a working kernel/ rootfs combination to proceed. As it follows from the mailing list postings I've read I shall try installing gentoo distribution. However, the binary kernel for net-install from http://dev.gentoo.org/~kumba/mips/netboot/ip32/ does not seem to boot and hangs straight after the download. The same applies to the older kernel image located in the same place. What I found to work was the 64 bit binary kernel from glaurung (http://www.linux-mips.org/~glaurung/). It boots nicely, but I have no root partition to go on with. I've tried to use the contents of the initrd image for gentoo netinstall, but it hangs in the busybox after diplaying one line with version information. I would like to avoid installing the complete crosscompilation toolchain on my linux box in order to get the recent CVS version of the kernel compiled. Another point is that I have no idea what would be to configuration options to get it to work on my O2. Apparently, it's not straitforward. Can somebody point me a location of the working binary kernel for gentoo install or are there better (or just other) solutions? Regards, Max From em@realmagic.fr Thu May 27 15:32:04 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 15:32:08 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:23196 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 15:31:55 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4REVssL007934; Thu, 27 May 2004 16:31:54 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4REVsam007932; Thu, 27 May 2004 16:31:54 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? From: Emmanuel Michon To: Ralf Baechle Cc: linux-mips@linux-mips.org In-Reply-To: <20040526203346.GA8430@linux-mips.org> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <20040526203346.GA8430@linux-mips.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1085668313.20233.1249.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 May 2004 16:31:53 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips On Wed, 2004-05-26 at 22:33, Ralf Baechle wrote: > On Wed, May 26, 2004 at 06:35:16PM +0200, Emmanuel Michon wrote: > > Semaphores can be implemented using just a single 32-bit variable which > would mean the same code could be used for 32-bit and 64-bit processors > as long as only they support ll/sc. Maybe somebody has the time at his > hands, *hint*, *hint* :-) > > Ralf On 64bit you substract 1ULL<<32 Substracting 1 is enough for it to be algorithmically correct even on 64bit Do you accept a patch with the version for CONFIG_LLSC = y using a substraction by 1? Sincerely yours, E.M. From em@realmagic.fr Thu May 27 15:35:25 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 15:35:28 +0100 (BST) Received: from c2ce9fba.adsl.oleane.fr ([IPv6:::ffff:194.206.159.186]:29852 "EHLO avalon.france.sdesigns.com") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 15:35:16 +0100 Received: from avalon.france.sdesigns.com (localhost.localdomain [127.0.0.1]) by avalon.france.sdesigns.com (8.12.8/8.12.8) with ESMTP id i4REZGsL007956 for ; Thu, 27 May 2004 16:35:16 +0200 Received: (from michon@localhost) by avalon.france.sdesigns.com (8.12.8/8.12.8/Submit) id i4REZGKJ007954 for linux-mips@linux-mips.org; Thu, 27 May 2004 16:35:16 +0200 X-Authentication-Warning: avalon.france.sdesigns.com: michon set sender to em@realmagic.fr using -f Subject: which mipsel-linux-gdb should I use From: Emmanuel Michon To: linux-mips@linux-mips.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: REALmagic France SAS Message-Id: <1085668515.2341.1254.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 27 May 2004 16:35:15 +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: em@realmagic.fr Precedence: bulk X-list: linux-mips Hi, unfortunately most of the toolchain links given on http://www.linux-mips.org/toolchain.html are broken... What is the preferred gcc version for compiling 32bit linux mips kernels? By the way I'd be glad to have a mipsel-linux-gdb matching the gcc to use kgdb, and ftp://ftp.mips.com/pub/tools/software/sde-for-linux/sdelinux-5.01-4.i386.rpm does not provide it... Sincerely yours, E.M. From ralf@linux-mips.org Thu May 27 16:59:58 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 17:17:19 +0100 (BST) Received: from p508B5AC4.dip.t-dialin.net ([IPv6:::ffff:80.139.90.196]:54347 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 16:59:49 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4RFxmGg005006; Thu, 27 May 2004 17:59:48 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4RFxl12005005; Thu, 27 May 2004 17:59:47 +0200 Date: Thu, 27 May 2004 17:59:47 +0200 From: Ralf Baechle To: Emmanuel Michon Cc: linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? Message-ID: <20040527155947.GA4154@linux-mips.org> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <20040526203346.GA8430@linux-mips.org> <1085668313.20233.1249.camel@avalon.france.sdesigns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1085668313.20233.1249.camel@avalon.france.sdesigns.com> User-Agent: Mutt/1.4.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: 5205 X-Approved-By: ralf@linux-mips.org X-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, May 27, 2004 at 04:31:53PM +0200, Emmanuel Michon wrote: > On 64bit you substract 1ULL<<32 > > Substracting 1 is enough for it to be algorithmically correct even on > 64bit > Do you accept a patch with the version for CONFIG_LLSC = y using a > substraction by 1? This sounds wrong - the current algorithm is manipulating two 32-bit variables held in a single register. If you change the algorithm like this you will manipulate the wrong variable. Anyway, I don't see why the code fails for you. With CONFIG_CPU_HAS_LLSC set and CONFIG_CPU_HAS_LLDSCD disabled it should just work for you. The suggestion in my prevous mail was meant for a rewrite along the lines of for example ppc64 - an algorithm that's mostly C and almost portable even. Ralf From kumba@gentoo.org Thu May 27 19:33:51 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 19:33:55 +0100 (BST) Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:65229 "EHLO rwcrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 19:33:43 +0100 Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58]) by comcast.net (rwcrmhc11) with ESMTP id <2004052718333201300ffoh0e> (Authid: kumba12345); Thu, 27 May 2004 18:33:34 +0000 Message-ID: <40B63518.3020509@gentoo.org> Date: Thu, 27 May 2004 14:36:08 -0400 From: Kumba Reply-To: kumba@gentoo.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: help needed : cannot install linux on SGI O2 R5000 References: <200405271333.04712.maksik@gmx.co.uk> In-Reply-To: <200405271333.04712.maksik@gmx.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5206 X-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 Max Zaitsev wrote: > Hi List, > > couple of days ago I've acquired an oldish O2 box with 180MHz R5k CPU, 256MB > ram and ~10GB HD space. Since then I'm trying to get linux installed on that > thing, but apparently with no success. I've managed to connect it to a linux > box and get bootp() and NFS to work. However, I cannot find a working kernel/ > rootfs combination to proceed. > > As it follows from the mailing list postings I've read I shall try installing > gentoo distribution. However, the binary kernel for net-install from > http://dev.gentoo.org/~kumba/mips/netboot/ip32/ does not seem to boot and > hangs straight after the download. The same applies to the older kernel image > located in the same place. > > What I found to work was the 64 bit binary kernel from glaurung > (http://www.linux-mips.org/~glaurung/). It boots nicely, but I have no root > partition to go on with. I've tried to use the contents of the initrd image > for gentoo netinstall, but it hangs in the busybox after diplaying one line > with version information. > > I would like to avoid installing the complete crosscompilation toolchain on my > linux box in order to get the recent CVS version of the kernel compiled. > Another point is that I have no idea what would be to configuration options > to get it to work on my O2. Apparently, it's not straitforward. Can somebody > point me a location of the working binary kernel for gentoo install or are > there better (or just other) solutions? The IP32 Netboot I have requires you to setup an NFS-exportable root for it to work properly, and it's advised you run off of serial console (if you aren't already). There should be an initrd link in the ip32 directory -- use that for NFS root, and pass at minimum 'root=/dev/nfs console=ttyS0,' (where is the speed your running serial console at) after 'bootp(): ', and you should see some data. If you are using serial console, double check to make sure the kb/mouse/monitor is unplugged, and the prom var 'console' is set to 'd1'. See if that gets you anywheres. --Kumba -- "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 kumba@gentoo.org Thu May 27 19:38:24 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 19:38:28 +0100 (BST) Received: from rwcrmhc12.comcast.net ([IPv6:::ffff:216.148.227.85]:32767 "EHLO rwcrmhc12.comcast.net") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 19:38:15 +0100 Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58]) by comcast.net (rwcrmhc12) with ESMTP id <20040527183806014007vkape> (Authid: kumba12345); Thu, 27 May 2004 18:38:07 +0000 Message-ID: <40B635FA.3080807@gentoo.org> Date: Thu, 27 May 2004 14:39:54 -0400 From: Kumba Reply-To: kumba@gentoo.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org CC: Ralf Baechle Subject: [PATCH] Fix for 2.6.5/2.6.6 Swap issue Content-Type: multipart/mixed; boundary="------------040709090100010107080006" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5207 X-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 This is a multi-part message in MIME format. --------------040709090100010107080006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Peter Horton wrote this patch up several weeks ago for Cobalt, but it's applicable for all MIPS machines I've seen thus far (atleast SGI and Cobalt). It fixes the kernel panic resulting from trying to activate swap on a system running 2.6.5 and up. It's been in Gentoo's mips-sources for quite some time, and I've had no problems with it on my O2 or Cobalt. --Kumba -- "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 --------------040709090100010107080006 Content-Type: text/plain; name="mipscvs-2.6.5-swapbug-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mipscvs-2.6.5-swapbug-fix.patch" diff -urN include/asm-mips/pgtable-32.h include/asm-mips/pgtable-32.h --- include/asm-mips/pgtable-32.h 2004-03-11 16:46:57.000000000 +0000 +++ include/asm-mips/pgtable-32.h 2004-04-17 09:06:02.000000000 +0100 @@ -203,14 +203,18 @@ /* Swap entries must have VALID and GLOBAL bits cleared. */ #if defined(CONFIG_CPU_R3000) || defined(CONFIG_CPU_TX39XX) -#define __swp_type(x) (((x).val >> 1) & 0x7f) -#define __swp_offset(x) ((x).val >> 10) -#define __swp_entry(type,offset) ((swp_entry_t) { ((type) << 1) | ((offset) << 10) }) +/* offset is limited to 17 bits (512MB @ 4K page) */ +/* VALID & GLOBAL are bits 9 & 8 */ +#define __swp_type(x) (((x).val >> 10) & 0x1f) +#define __swp_offset(x) ((x).val >> 15) +#define __swp_entry(type,offset) ((swp_entry_t) { ((type) << 10) | ((offset) << 15) }) #else -#define __swp_type(x) (((x).val >> 1) & 0x1f) -#define __swp_offset(x) ((x).val >> 8) -#define __swp_entry(type,offset) ((swp_entry_t) { ((type) << 1) | ((offset) << 8) }) +/* offset is limited to 19 bits (2GB @ 4K page) */ +/* VALID & GLOBAL are bits 7 & 6 */ +#define __swp_type(x) (((x).val >> 8) & 0x1f) +#define __swp_offset(x) ((x).val >> 13) +#define __swp_entry(type,offset) ((swp_entry_t) { ((type) << 8) | ((offset) << 13) }) #endif #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) }) --------------040709090100010107080006-- From hjl@lucon.org Thu May 27 20:02:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 27 May 2004 20:02:41 +0100 (BST) Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:17137 "EHLO sccrmhc13.comcast.net") by linux-mips.org with ESMTP id ; Thu, 27 May 2004 20:02:26 +0100 Received: from lucon.org ([24.6.43.109]) by comcast.net (sccrmhc13) with ESMTP id <2004052719021601600riaiie>; Thu, 27 May 2004 19:02:17 +0000 Received: by lucon.org (Postfix, from userid 1000) id C2A6264CFF; Thu, 27 May 2004 12:02:15 -0700 (PDT) Date: Thu, 27 May 2004 12:02:15 -0700 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ralf Baechle , Linas Vepstas Subject: The Linux binutils 2.15.91.0.1 is released Message-ID: <20040527190215.GA25554@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.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: 5208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips This is the beta release of binutils 2.15.91.0.1 for Linux, which is based on binutils 2004 0527 in CVS on sources.redhat.com plus various changes. It is purely for Linux. Please report any bugs related to binutils 2.15.91.0.1 to hjl@lucon.org. If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches. Changes from binutils 2.15.90.0.3: 1. Update from binutils 2004 0527. 2. Fix -x auto option in the ia64 assembler. 3. Add the AR check in the ia64 assembler. 4. Fix the section group support. 5. Add a new -z relro linker option. 6. Fix an exception section placement bug in linker. 7. Add .serialize.data and .serialize.instruction to the ia64 assembler. Changes from binutils 2.15.90.0.2: 1. Update from binutils 2004 0415. 2. Fix the linker for weak undefined symbol handling. 3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC code. Changes from binutils 2.15.90.0.1.1: 1. Update from binutils 2004 0412. 2. Add --as-needed/--no-as-needed to linker. 3. Fix -z defs in linker. 4. Always reserve the memory for ia64 dynamic linker. 5. Fix a race condition in ia64 lazy binding. Changes from binutils 2.15.90.0.1: 1. Fixed an ia64 assembler bug. 2. Install the assembler man page. Changes from binutils 2.14.90.0.8: 1. Update from binutils 2004 0303. 2. Fixed linker for undefined symbols with non-default visibility. 3. Sped up linker weakdef symbol handling. 4. Fixed mixing ELF32 and ELF64 object files in archive. 5. Added ia64 linker brl optimization. 6. Fixed ia64 linker to disallow invalid dynamic relocations. 7. Fixed DT_TEXTREL handling in ia64 linker. 8. Fixed alignment handling in ia64 assembler. 9. Improved ia64 assembler unwind table handling. Changes from binutils 2.14.90.0.7: 1. Update from binutils 2004 0114. 2. Fixed an ia64 assembler unwind table bug. 3. Better handle IPF linker relaxation overflow. 4. Fixed misc PPC bugs. Changes from binutils 2.14.90.0.6: 1. Update from binutils 2003 1029. 2. Allow type changes for undefined symbols. 3. Fix EH frame optimization. 4. Fix the check for undefined versioned symbol with wildcard. 5. Support generating code for Itanium. 6. Detect and warn bad symbol index. 7. Update IPF assemebler DV check. Changes from binutils 2.14.90.0.5: 1. Update from binutils 2003 0820. 2. No longer use section names for ELF section types nor flags. 3. Fix some ELF/IA64 linker bugs. 4. Fix some ELF/ppc bugs. 5. Add archive support to readelf. Changes from binutils 2.14.90.0.4.1: 1. Update from binutils 2003 0722. 2. Fix an ELF/mips linker bug. 3. Fix an ELF/hpppa linker bug. 4. Fix an ELF/ia64 assembler bug. 5. Fix a linkonce support with C++ debug. 6. A new working C++ demangler. 7. Various alpha, mips, ia64, ... bug fixes. 8. Support for the current gcc and glibc. Changes from binutils 2.14.90.0.4: 1. Fix an ia64 assembler hint@pause bug. 2. Support Intel Precott New Instructions. Changes from binutils 2.14.90.0.3: 1. Work around the brain dead libtool. Changes from binutils 2.14.90.0.2: 1. Update from binutils 2003 0523. 2. Fix 2 ELF visibility bugs. 3. Fix ELF/ppc linker bugs. Changes from binutils 2.14.90.0.1: 1. Update from binutils 2003 0515. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Add more IAS compatibilities to ia64 assembler. Changes from binutils 2.13.90.0.20: 1. Update from binutils 2003 0505. 2. Fix various ELF visibility bugs. 3. Fix some ia64 linker bugs. 4. Fix some ia64 assembler bugs. 5. Add some IAS compatibilities to ia64 assembler. 6. Fix ELF common symbol alignment. 7. Fix ELF weak symbol handling. Changes from binutils 2.13.90.0.18: 1. Update from binutils 2003 0319. 2. Fix an ia64 linker brl relaxation bug. 3. Fix some ELF/ppc linker bugs. Changes from binutils 2.13.90.0.16: 1. Update from binutils 2003 0121. 2. Fix an ia64 gas bug. 3. Fix some TLS bugs. 4. Fix some ELF/ppc bugs. 5. Fix an ELF/m68k bug. 2. Include /usr/bin/c++filt. Changes from binutils 2.13.90.0.14: 1. Update from binutils 2002 1126. 2. Include /usr/bin/c++filt. 3. Fix "ld -r" with execption handling. Changes from binutils 2.13.90.0.10: 1. Update from binutils 2002 1114. 2. Fix ELF/alpha bugs. 3. Fix an ELF/i386 assembler bug. Changes from binutils 2.13.90.0.4: 1. Update from binutils 2002 1010. 2. More ELF/PPC linker bug fixes. 3. Fix an ELF/alpha linker bug. 4. Fix an ELF/sparc linker bug to support Solaris. 5. More TLS updates. Changes from binutils 2.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. The file list: 1. binutils-2.15.91.0.1.tar.bz2. Source code. 2. binutils-2.15.90.0.3-2.15.91.0.1.diff.bz2. Patch against the previous beta source code. 3. binutils-2.15.91.0.1-1.i386.rpm. IA-32 binary RPM for RedHat EL 3. 4. binutils-2.15.91.0.1-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3. 5. binutils-2.15.91.0.1-1.x86_64.rpm. X64_64 binary RPM for RedHat EL 3. There is no separate source rpm. You can do # rpmbuild -ta binutils-2.15.91.0.1.tar.bz2 to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 05/27/2004 From ralf@linux-mips.org Fri May 28 01:35:37 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 01:41:44 +0100 (BST) Received: from p508B5AC4.dip.t-dialin.net ([IPv6:::ffff:80.139.90.196]:21329 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 01:35:28 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4S0ZQEt027903; Fri, 28 May 2004 02:35:26 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4S0ZPgR027902; Fri, 28 May 2004 02:35:25 +0200 Date: Fri, 28 May 2004 02:35:25 +0200 From: Ralf Baechle To: Emmanuel Michon Cc: linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? Message-ID: <20040528003525.GA27796@linux-mips.org> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <20040526203346.GA8430@linux-mips.org> <1085668313.20233.1249.camel@avalon.france.sdesigns.com> <20040527155947.GA4154@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527155947.GA4154@linux-mips.org> User-Agent: Mutt/1.4.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: 5209 X-Approved-By: ralf@linux-mips.org X-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 Oh well, so here is a rewrite of the semaphore code. Less complex, does no longer need 64-bit alignment for the strange union handling we were using in struct semaphore also smaller and no longer relies on 64-bit computing on 32-bit hardware. For my SMP test kernel it did cut off 5972 bytes. The patch below is against 2.6 but fitting it into 2.4 is easy. Ralf Index: include/asm-mips/atomic.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/atomic.h,v retrieving revision 1.29 diff -u -r1.29 atomic.h --- include/asm-mips/atomic.h 19 Feb 2004 03:06:34 -0000 1.29 +++ include/asm-mips/atomic.h 28 May 2004 00:30:05 -0000 @@ -9,7 +9,7 @@ * License. See the file "COPYING" in the main directory of this archive * for more details. * - * Copyright (C) 1996, 97, 99, 2000, 03 by Ralf Baechle + * Copyright (C) 1996, 97, 99, 2000, 03, 04 by Ralf Baechle */ /* @@ -127,6 +127,32 @@ return result; } +/* + * atomic_sub_if_positive - add integer to atomic variable + * @v: pointer of type atomic_t + * + * Atomically test @v and decrement if it is greater than 0. + * The function returns the old value of @v minus 1. + */ +static __inline__ int atomic_sub_if_positive(int i, atomic_t * v) +{ + unsigned long temp, result; + + __asm__ __volatile__( + "1: ll %1, %2 # atomic_sub_if_positive\n" + " subu %0, %1, %3 \n" + " bltz %0, 1f \n" + " sc %0, %2 \n" + " beqz %0, 1b \n" + " sync \n" + "1: \n" + : "=&r" (result), "=&r" (temp), "=m" (v->counter) + : "Ir" (i), "m" (v->counter) + : "memory"); + + return result; +} + #else /* @@ -192,6 +218,28 @@ return temp; } +/* + * atomic_sub_if_positive - add integer to atomic variable + * @v: pointer of type atomic_t + * + * Atomically test @v and decrement if it is greater than 0. + * The function returns the old value of @v minus 1. + */ +static __inline__ int atomic_sub_if_positive(int i, atomic_t * v) +{ + unsigned long flags; + int temp, result; + + spin_lock_irqsave(&atomic_lock, flags); + temp = v->counter; + temp -= i; + if (temp >= 0) + v->counter = temp; + spin_unlock_irqrestore(&atomic_lock, flags); + + return result; +} + #endif /* CONFIG_CPU_HAS_LLSC */ #define atomic_dec_return(v) atomic_sub_return(1,(v)) @@ -229,6 +277,12 @@ #define atomic_dec_and_test(v) (atomic_sub_return(1, (v)) == 0) /* + * atomic_dec_if_positive - decrement by 1 if old value positive + * @v: pointer of type atomic_t + */ +#define atomic_dec_if_positive(v) atomic_sub_if_positive(1, v) + +/* * atomic_inc - increment atomic variable * @v: pointer of type atomic_t * @@ -356,6 +410,32 @@ return result; } +/* + * atomic64_sub_if_positive - add integer to atomic variable + * @v: pointer of type atomic64_t + * + * Atomically test @v and decrement if it is greater than 0. + * The function returns the old value of @v minus 1. + */ +static __inline__ int atomic64_sub_if_positive(int i, atomic64_t * v) +{ + unsigned long temp, result; + + __asm__ __volatile__( + "1: lld %1, %2 # atomic64_sub_if_positive\n" + " subu %0, %1, %3 \n" + " bltz %0, 1f \n" + " scd %0, %2 \n" + " beqz %0, 1b \n" + " sync \n" + "1: \n" + : "=&r" (result), "=&r" (temp), "=m" (v->counter) + : "Ir" (i), "m" (v->counter) + : "memory"); + + return result; +} + #else /* @@ -421,6 +501,28 @@ return temp; } +/* + * atomic64_sub_if_positive - add integer to atomic variable + * @v: pointer of type atomic64_t + * + * Atomically test @v and decrement if it is greater than 0. + * The function returns the old value of @v minus 1. + */ +static __inline__ int atomic64_sub_if_positive(int i, atomic64_t * v) +{ + unsigned long flags; + long temp, result; + + spin_lock_irqsave(&atomic_lock, flags); + temp = v->counter; + temp -= i; + if (temp >= 0) + v->counter = temp; + spin_unlock_irqrestore(&atomic_lock, flags); + + return result; +} + #endif /* CONFIG_CPU_HAS_LLDSCD */ #define atomic64_dec_return(v) atomic64_sub_return(1,(v)) @@ -458,6 +560,12 @@ #define atomic64_dec_and_test(v) (atomic64_sub_return(1, (v)) == 0) /* + * atomic64_dec_if_positive - decrement by 1 if old value positive + * @v: pointer of type atomic64_t + */ +#define atomic64_dec_if_positive(v) atomic64_sub_if_positive(1, v) + +/* * atomic64_inc - increment atomic variable * @v: pointer of type atomic64_t * Index: include/asm-mips/semaphore.h =================================================================== RCS file: /home/cvs/linux/include/asm-mips/semaphore.h,v retrieving revision 1.27 diff -u -r1.27 semaphore.h --- include/asm-mips/semaphore.h 28 Nov 2003 16:56:52 -0000 1.27 +++ include/asm-mips/semaphore.h 28 May 2004 00:30:05 -0000 @@ -4,61 +4,70 @@ * for more details. * * Copyright (C) 1996 Linus Torvalds - * Copyright (C) 1998, 99, 2000, 01 Ralf Baechle + * Copyright (C) 1998, 99, 2000, 01, 04 Ralf Baechle * Copyright (C) 1999, 2000, 01 Silicon Graphics, Inc. * Copyright (C) 2000, 01 MIPS Technologies, Inc. + * + * In all honesty, little of the old MIPS code left - the PPC64 variant was + * just looking nice and portable so I ripped it. Credits to whoever wrote + * it. */ -#ifndef _ASM_SEMAPHORE_H -#define _ASM_SEMAPHORE_H +#ifndef __ASM_SEMAPHORE_H +#define __ASM_SEMAPHORE_H + +/* + * Remove spinlock-based RW semaphores; RW semaphore definitions are + * now in rwsem.h and we use the generic lib/rwsem.c implementation. + * Rework semaphores to use atomic_dec_if_positive. + * -- Paul Mackerras (paulus@samba.org) + */ + +#ifdef __KERNEL__ -#include -#include -#include +#include +#include #include #include -#include struct semaphore { -#ifdef __MIPSEB__ - atomic_t count; - atomic_t waking; -#else - atomic_t waking; + /* + * Note that any negative value of count is equivalent to 0, + * but additionally indicates that some process(es) might be + * sleeping on `wait'. + */ atomic_t count; -#endif wait_queue_head_t wait; -#if WAITQUEUE_DEBUG +#ifdef WAITQUEUE_DEBUG long __magic; #endif -} __attribute__((aligned(8))); +}; -#if WAITQUEUE_DEBUG -# define __SEM_DEBUG_INIT(name) , .__magic = (long)&(name).__magic +#ifdef WAITQUEUE_DEBUG +# define __SEM_DEBUG_INIT(name) \ + , (long)&(name).__magic #else # define __SEM_DEBUG_INIT(name) #endif -#define __SEMAPHORE_INITIALIZER(name,_count) { \ - .count = ATOMIC_INIT(_count), \ - .waking = ATOMIC_INIT(0), \ - .wait = __WAIT_QUEUE_HEAD_INITIALIZER((name).wait) \ - __SEM_DEBUG_INIT(name) \ -} +#define __SEMAPHORE_INITIALIZER(name, count) \ + { ATOMIC_INIT(count), \ + __WAIT_QUEUE_HEAD_INITIALIZER((name).wait) \ + __SEM_DEBUG_INIT(name) } -#define __MUTEX_INITIALIZER(name) __SEMAPHORE_INITIALIZER(name, 1) +#define __MUTEX_INITIALIZER(name) \ + __SEMAPHORE_INITIALIZER(name, 1) -#define __DECLARE_SEMAPHORE_GENERIC(name,count) \ - struct semaphore name = __SEMAPHORE_INITIALIZER(name, count) +#define __DECLARE_SEMAPHORE_GENERIC(name, count) \ + struct semaphore name = __SEMAPHORE_INITIALIZER(name,count) -#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name, 1) -#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name,0) +#define DECLARE_MUTEX(name) __DECLARE_SEMAPHORE_GENERIC(name, 1) +#define DECLARE_MUTEX_LOCKED(name) __DECLARE_SEMAPHORE_GENERIC(name, 0) static inline void sema_init (struct semaphore *sem, int val) { atomic_set(&sem->count, val); - atomic_set(&sem->waking, 0); init_waitqueue_head(&sem->wait); -#if WAITQUEUE_DEBUG +#ifdef WAITQUEUE_DEBUG sem->__magic = (long)&sem->__magic; #endif } @@ -73,211 +82,57 @@ sema_init(sem, 0); } -#ifndef CONFIG_CPU_HAS_LLDSCD -/* - * On machines without lld/scd we need a spinlock to make the manipulation of - * sem->count and sem->waking atomic. - */ -extern spinlock_t semaphore_lock; -#endif - -extern void __down_failed(struct semaphore * sem); -extern int __down_failed_interruptible(struct semaphore * sem); -extern void __up_wakeup(struct semaphore * sem); +extern void __down(struct semaphore * sem); +extern int __down_interruptible(struct semaphore * sem); +extern void __up(struct semaphore * sem); static inline void down(struct semaphore * sem) { - int count; - -#if WAITQUEUE_DEBUG +#ifdef WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif might_sleep(); - count = atomic_dec_return(&sem->count); - if (unlikely(count < 0)) - __down_failed(sem); + + /* + * Try to get the semaphore, take the slow path if we fail. + */ + if (unlikely(atomic_dec_return(&sem->count) < 0)) + __down(sem); } -/* - * Interruptible try to acquire a semaphore. If we obtained - * it, return zero. If we were interrupted, returns -EINTR - */ static inline int down_interruptible(struct semaphore * sem) { - int count; + int ret = 0; -#if WAITQUEUE_DEBUG +#ifdef WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif might_sleep(); - count = atomic_dec_return(&sem->count); - if (unlikely(count < 0)) - return __down_failed_interruptible(sem); - - return 0; -} - -#ifdef CONFIG_CPU_HAS_LLDSCD - -/* - * down_trylock returns 0 on success, 1 if we failed to get the lock. - * - * We must manipulate count and waking simultaneously and atomically. - * Here, we do this by using lld/scd on the pair of 32-bit words. - * - * Pseudocode: - * - * Decrement(sem->count) - * If(sem->count >=0) { - * Return(SUCCESS) // resource is free - * } else { - * If(sem->waking <= 0) { // if no wakeup pending - * Increment(sem->count) // undo decrement - * Return(FAILURE) - * } else { - * Decrement(sem->waking) // otherwise "steal" wakeup - * Return(SUCCESS) - * } - * } - */ -static inline int down_trylock(struct semaphore * sem) -{ - long ret, tmp, tmp2, sub; - -#if WAITQUEUE_DEBUG - CHECK_MAGIC(sem->__magic); -#endif - - __asm__ __volatile__( - " .set mips3 # down_trylock \n" - "0: lld %1, %4 \n" - " dli %3, 0x0000000100000000 # count -= 1 \n" - " dsubu %1, %3 \n" - " li %0, 0 # ret = 0 \n" - " bgez %1, 2f # if count >= 0 \n" - " sll %2, %1, 0 # extract waking \n" - " blez %2, 1f # if waking < 0 -> 1f \n" - " daddiu %1, %1, -1 # waking -= 1 \n" - " b 2f \n" - "1: daddu %1, %1, %3 # count += 1 \n" - " li %0, 1 # ret = 1 \n" - "2: scd %1, %4 \n" - " beqz %1, 0b \n" - " sync \n" - " .set mips0 \n" - : "=&r"(ret), "=&r"(tmp), "=&r"(tmp2), "=&r"(sub) - : "m"(*sem) - : "memory"); + if (unlikely(atomic_dec_return(&sem->count) < 0)) + ret = __down_interruptible(sem); return ret; } -/* - * Note! This is subtle. We jump to wake people up only if - * the semaphore was negative (== somebody was waiting on it). - */ -static inline void up(struct semaphore * sem) -{ - unsigned long tmp, tmp2; - int count; - -#if WAITQUEUE_DEBUG - CHECK_MAGIC(sem->__magic); -#endif - /* - * We must manipulate count and waking simultaneously and atomically. - * Otherwise we have races between up and __down_failed_interruptible - * waking up on a signal. - */ - - __asm__ __volatile__( - " .set mips3 \n" - " sync # up \n" - "1: lld %1, %3 \n" - " dsra32 %0, %1, 0 # extract count to %0 \n" - " daddiu %0, 1 # count += 1 \n" - " slti %2, %0, 1 # %3 = (%0 <= 0) \n" - " daddu %1, %2 # waking += %3 \n" - " dsll32 %1, %1, 0 # zero-extend %1 \n" - " dsrl32 %1, %1, 0 \n" - " dsll32 %2, %0, 0 # Reassemble union \n" - " or %1, %2 # from count and waking \n" - " scd %1, %3 \n" - " beqz %1, 1b \n" - " .set mips0 \n" - : "=&r"(count), "=&r"(tmp), "=&r"(tmp2), "+m"(*sem) - : - : "memory"); - - if (unlikely(count <= 0)) - __up_wakeup(sem); -} - -#else - -/* - * Non-blockingly attempt to down() a semaphore. - * Returns zero if we acquired it - */ static inline int down_trylock(struct semaphore * sem) { - unsigned long flags; - int count, waking; - int ret = 0; - -#if WAITQUEUE_DEBUG +#ifdef WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif - spin_lock_irqsave(&semaphore_lock, flags); - count = atomic_read(&sem->count) - 1; - atomic_set(&sem->count, count); - if (unlikely(count < 0)) { - waking = atomic_read(&sem->waking); - if (waking <= 0) { - atomic_set(&sem->count, count + 1); - ret = 1; - } else { - atomic_set(&sem->waking, waking - 1); - ret = 0; - } - } - spin_unlock_irqrestore(&semaphore_lock, flags); - - return ret; + return atomic_dec_if_positive(&sem->count) < 0; } -/* - * Note! This is subtle. We jump to wake people up only if - * the semaphore was negative (== somebody was waiting on it). - */ static inline void up(struct semaphore * sem) { - unsigned long flags; - int count, waking; - -#if WAITQUEUE_DEBUG +#ifdef WAITQUEUE_DEBUG CHECK_MAGIC(sem->__magic); #endif - /* - * We must manipulate count and waking simultaneously and atomically. - * Otherwise we have races between up and __down_failed_interruptible - * waking up on a signal. - */ - - spin_lock_irqsave(&semaphore_lock, flags); - count = atomic_read(&sem->count) + 1; - waking = atomic_read(&sem->waking); - if (count <= 0) - waking++; - atomic_set(&sem->count, count); - atomic_set(&sem->waking, waking); - spin_unlock_irqrestore(&semaphore_lock, flags); - if (unlikely(count <= 0)) - __up_wakeup(sem); + if (unlikely(atomic_inc_return(&sem->count) <= 0)) + __up(sem); } -#endif /* CONFIG_CPU_HAS_LLDSCD */ +#endif /* __KERNEL__ */ -#endif /* _ASM_SEMAPHORE_H */ +#endif /* __ASM_SEMAPHORE_H */ Index: arch/mips/kernel/semaphore.c =================================================================== RCS file: /home/cvs/linux/arch/mips/kernel/semaphore.c,v retrieving revision 1.8 diff -u -r1.8 semaphore.c --- arch/mips/kernel/semaphore.c 23 Apr 2004 15:54:09 -0000 1.8 +++ arch/mips/kernel/semaphore.c 28 May 2004 00:30:05 -0000 @@ -1,273 +1,165 @@ /* - * Copyright (C) 1999, 2001, 02, 03 Ralf Baechle + * MIPS-specific semaphore code. * - * Heavily inspired by the Alpha implementation + * Copyright (C) 1999 Cort Dougan + * Copyright (C) 2004 Ralf Baechle + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * April 2001 - Reworked by Paul Mackerras + * to eliminate the SMP races in the old version between the updates + * of `count' and `waking'. Now we use negative `count' values to + * indicate that some process(es) are waiting for the semaphore. */ + #include -#include #include -#include #include +#include +#include +#include +#include -#ifdef CONFIG_CPU_HAS_LLDSCD -/* - * On machines without lld/scd we need a spinlock to make the manipulation of - * sem->count and sem->waking atomic. Scalability isn't an issue because - * this lock is used on UP only so it's just an empty variable. - */ -spinlock_t semaphore_lock = SPIN_LOCK_UNLOCKED; - -EXPORT_SYMBOL(semaphore_lock); -#endif +#ifdef CONFIG_CPU_HAS_LLSC /* - * Semaphores are implemented using a two-way counter: The "count" variable is - * decremented for each process that tries to sleep, while the "waking" variable - * is incremented when the "up()" code goes to wake up waiting processes. - * - * Notably, the inline "up()" and "down()" functions can efficiently test if - * they need to do any extra work (up needs to do something only if count was - * negative before the increment operation. - * - * waking_non_zero() must execute atomically. - * - * When __up() is called, the count was negative before incrementing it, and we - * need to wake up somebody. + * Atomically update sem->count. + * This does the equivalent of the following: * - * This routine adds one to the count of processes that need to wake up and - * exit. ALL waiting processes actually wake up but only the one that gets to - * the "waking" field first will gate through and acquire the semaphore. The - * others will go back to sleep. - * - * Note that these functions are only called when there is contention on the - * lock, and as such all this is the "non-critical" part of the whole semaphore - * business. The critical part is the inline stuff in where - * we want to avoid any extra jumps and calls. + * old_count = sem->count; + * tmp = MAX(old_count, 0) + incr; + * sem->count = tmp; + * return old_count; */ -void __up_wakeup(struct semaphore *sem) -{ - wake_up(&sem->wait); -} - -EXPORT_SYMBOL(__up_wakeup); - -#ifdef CONFIG_CPU_HAS_LLSC - -static inline int waking_non_zero(struct semaphore *sem) +static inline int __sem_update_count(struct semaphore *sem, int incr) { - int ret, tmp; + int old_count, tmp; __asm__ __volatile__( - "1: ll %1, %2 # waking_non_zero \n" - " blez %1, 2f \n" - " subu %0, %1, 1 \n" - " sc %0, %2 \n" - " beqz %0, 1b \n" - "2: \n" - : "=r" (ret), "=r" (tmp), "+m" (sem->waking) - : "0" (0)); + "1: ll %0, %2 \n" + " sra %1, %0, 31 \n" + " not %1 \n" + " and %1, %0, %1 \n" + " add %1, %1, %3 \n" + " sc %1, %2 \n" + " beqz %1, 1b \n" + : "=&r" (old_count), "=&r" (tmp), "=m" (sem->count) + : "r" (incr), "m" (sem->count)); - return ret; + return old_count; } -#else /* !CONFIG_CPU_HAS_LLSC */ +#else + +/* + * On machines without lld/scd we need a spinlock to make the manipulation of + * sem->count and sem->waking atomic. Scalability isn't an issue because + * this lock is used on UP only so it's just an empty variable. + */ +static spinlock_t semaphore_lock = SPIN_LOCK_UNLOCKED; -static inline int waking_non_zero(struct semaphore *sem) +static inline int __sem_update_count(struct semaphore *sem, int incr) { unsigned long flags; - int waking, ret = 0; + int old_count, tmp; spin_lock_irqsave(&semaphore_lock, flags); - waking = atomic_read(&sem->waking); - if (waking > 0) { - atomic_set(&sem->waking, waking - 1); - ret = 1; - } + old_count = atomic_read(&sem->count); + tmp = max_t(int, old_count, 0) + incr; + atomic_set(&sem->count, tmp); spin_unlock_irqrestore(&semaphore_lock, flags); - return ret; + return old_count; } -#endif /* !CONFIG_CPU_HAS_LLSC */ - -/* - * Perform the "down" function. Return zero for semaphore acquired, return - * negative for signalled out of the function. - * - * If called from down, the return is ignored and the wait loop is not - * interruptible. This means that a task waiting on a semaphore using "down()" - * cannot be killed until someone does an "up()" on the semaphore. - * - * If called from down_interruptible, the return value gets checked upon return. - * If the return value is negative then the task continues with the negative - * value in the return register (it can be tested by the caller). - * - * Either form may be used in conjunction with "up()". - */ +#endif -void __sched __down_failed(struct semaphore * sem) +void __up(struct semaphore *sem) { - struct task_struct *tsk = current; - wait_queue_t wait; - - init_waitqueue_entry(&wait, tsk); - __set_current_state(TASK_UNINTERRUPTIBLE); - add_wait_queue_exclusive(&sem->wait, &wait); - /* - * Ok, we're set up. sem->count is known to be less than zero - * so we must wait. - * - * We can let go the lock for purposes of waiting. - * We re-acquire it after awaking so as to protect - * all semaphore operations. - * - * If "up()" is called before we call waking_non_zero() then - * we will catch it right away. If it is called later then - * we will have to go through a wakeup cycle to catch it. - * - * Multiple waiters contend for the semaphore lock to see - * who gets to gate through and who has to wait some more. + * Note that we incremented count in up() before we came here, + * but that was ineffective since the result was <= 0, and + * any negative value of count is equivalent to 0. + * This ends up setting count to 1, unless count is now > 0 + * (i.e. because some other cpu has called up() in the meantime), + * in which case we just increment count. */ - for (;;) { - if (waking_non_zero(sem)) - break; - schedule(); - __set_current_state(TASK_UNINTERRUPTIBLE); - } - __set_current_state(TASK_RUNNING); - remove_wait_queue(&sem->wait, &wait); + __sem_update_count(sem, 1); + wake_up(&sem->wait); } -EXPORT_SYMBOL(__down_failed); - -#ifdef CONFIG_CPU_HAS_LLDSCD +EXPORT_SYMBOL(__up); /* - * waking_non_zero_interruptible: - * 1 got the lock - * 0 go to sleep - * -EINTR interrupted - * - * We must undo the sem->count down_interruptible decrement - * simultaneously and atomically with the sem->waking adjustment, - * otherwise we can race with wake_one_more. - * - * This is accomplished by doing a 64-bit lld/scd on the 2 32-bit words. - * - * This is crazy. Normally it's strictly forbidden to use 64-bit operations - * in the 32-bit MIPS kernel. In this case it's however ok because if an - * interrupt has destroyed the upper half of registers sc will fail. - * Note also that this will not work for MIPS32 CPUs! - * - * Pseudocode: - * - * If(sem->waking > 0) { - * Decrement(sem->waking) - * Return(SUCCESS) - * } else If(signal_pending(tsk)) { - * Increment(sem->count) - * Return(-EINTR) - * } else { - * Return(SLEEP) - * } + * Note that when we come in to __down or __down_interruptible, + * we have already decremented count, but that decrement was + * ineffective since the result was < 0, and any negative value + * of count is equivalent to 0. + * Thus it is only when we decrement count from some value > 0 + * that we have actually got the semaphore. */ - -static inline int -waking_non_zero_interruptible(struct semaphore *sem, struct task_struct *tsk) +void __sched __down(struct semaphore *sem) { - long ret, tmp; - - __asm__ __volatile__( - " .set push # waking_non_zero_interruptible \n" - " .set mips3 \n" - " .set noat \n" - "0: lld %1, %2 \n" - " li %0, 0 \n" - " sll $1, %1, 0 \n" - " blez $1, 1f \n" - " daddiu %1, %1, -1 \n" - " li %0, 1 \n" - " b 2f \n" - "1: beqz %3, 2f \n" - " li %0, %4 \n" - " dli $1, 0x0000000100000000 \n" - " daddu %1, %1, $1 \n" - "2: scd %1, %2 \n" - " beqz %1, 0b \n" - " .set pop \n" - : "=&r" (ret), "=&r" (tmp), "=m" (*sem) - : "r" (signal_pending(tsk)), "i" (-EINTR)); - - return ret; -} - -#else /* !CONFIG_CPU_HAS_LLDSCD */ - -static inline int waking_non_zero_interruptible(struct semaphore *sem, - struct task_struct *tsk) -{ - int waking, pending, ret = 0; - unsigned long flags; + struct task_struct *tsk = current; + DECLARE_WAITQUEUE(wait, tsk); - pending = signal_pending(tsk); + __set_task_state(tsk, TASK_UNINTERRUPTIBLE); + add_wait_queue_exclusive(&sem->wait, &wait); - spin_lock_irqsave(&semaphore_lock, flags); - waking = atomic_read(&sem->waking); - if (waking > 0) { - atomic_set(&sem->waking, waking - 1); - ret = 1; - } else if (pending) { - atomic_set(&sem->count, atomic_read(&sem->count) + 1); - ret = -EINTR; + /* + * Try to get the semaphore. If the count is > 0, then we've + * got the semaphore; we decrement count and exit the loop. + * If the count is 0 or negative, we set it to -1, indicating + * that we are asleep, and then sleep. + */ + while (__sem_update_count(sem, -1) <= 0) { + schedule(); + set_task_state(tsk, TASK_UNINTERRUPTIBLE); } - spin_unlock_irqrestore(&semaphore_lock, flags); + remove_wait_queue(&sem->wait, &wait); + __set_task_state(tsk, TASK_RUNNING); - return ret; + /* + * If there are any more sleepers, wake one of them up so + * that it can either get the semaphore, or set count to -1 + * indicating that there are still processes sleeping. + */ + wake_up(&sem->wait); } -#endif /* !CONFIG_CPU_HAS_LLDSCD */ +EXPORT_SYMBOL(__down); -int __sched __down_failed_interruptible(struct semaphore * sem) +int __sched __down_interruptible(struct semaphore * sem) { + int retval = 0; struct task_struct *tsk = current; - wait_queue_t wait; - int ret = 0; + DECLARE_WAITQUEUE(wait, tsk); - init_waitqueue_entry(&wait, tsk); - __set_current_state(TASK_INTERRUPTIBLE); + __set_task_state(tsk, TASK_INTERRUPTIBLE); add_wait_queue_exclusive(&sem->wait, &wait); - /* - * Ok, we're set up. sem->count is known to be less than zero - * so we must wait. - * - * We can let go the lock for purposes of waiting. - * We re-acquire it after awaking so as to protect - * all semaphore operations. - * - * If "up()" is called before we call waking_non_zero() then - * we will catch it right away. If it is called later then - * we will have to go through a wakeup cycle to catch it. - * - * Multiple waiters contend for the semaphore lock to see - * who gets to gate through and who has to wait some more. - */ - for (;;) { - ret = waking_non_zero_interruptible(sem, tsk); - if (ret) { - if (ret == 1) - /* ret != 0 only if we get interrupted -arca */ - ret = 0; + while (__sem_update_count(sem, -1) <= 0) { + if (signal_pending(current)) { + /* + * A signal is pending - give up trying. + * Set sem->count to 0 if it is negative, + * since we are no longer sleeping. + */ + __sem_update_count(sem, 0); + retval = -EINTR; break; } schedule(); - __set_current_state(TASK_INTERRUPTIBLE); + set_task_state(tsk, TASK_INTERRUPTIBLE); } - __set_current_state(TASK_RUNNING); remove_wait_queue(&sem->wait, &wait); + __set_task_state(tsk, TASK_RUNNING); - return ret; + wake_up(&sem->wait); + return retval; } -EXPORT_SYMBOL(__down_failed_interruptible); +EXPORT_SYMBOL(__down_interruptible); From anemo@mba.ocn.ne.jp Fri May 28 05:11:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 05:11:51 +0100 (BST) Received: from [IPv6:::ffff:202.230.225.5] ([IPv6:::ffff:202.230.225.5]:36876 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Fri, 28 May 2004 05:11:37 +0100 Received: from newms.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 28 May 2004 04:11:36 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by newms.toshiba-tops.co.jp (Postfix) with ESMTP id 17EAA239E3D; Fri, 28 May 2004 13:13:17 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i4S4BQwB039335; Fri, 28 May 2004 13:11:26 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 28 May 2004 13:12:36 +0900 (JST) Message-Id: <20040528.131236.112629910.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: 2.4 preempt kernel patch From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F Organization: TOSHIBA Personal Computer System Corporation X-Mailer: Mew version 3.3 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Hi. I'm investigating preempt patch for 2.4 kernel. (MIPS part of preempt-kernel-rml-2.4.26-pre5-1.patch seems a bit old. I'm looking Jun Sun's 030304-b.preempt-mips.patch). The patch contains following block (end of arch/mips/kernel/irq.c:do_IRQ()): if (softirq_pending(cpu)) do_softirq(); + +#if defined(CONFIG_PREEMPT) + for(;;) { + preempt_enable_no_resched(); + if (preempt_is_disabled() || !need_resched()) + break; + + db_assert(intr_off()); + db_assert(!in_interrupt()); + + preempt_disable(); + __sti(); + preempt_schedule(); + __cli(); + } +#endif + return 1; } Q1. What is purpose of this block? (To decrease latency? But other archs (and 2.6 MIPS kernel) do not have block like this...) Q2. If an interrupt happened between __sti() and __cli(), and the interrupt handler raise softirq, the softirq handler will not be called soon (because do_softirq() immediately return if preempt disabled). So we must check softirq_pending again after this block? Thank you. --- Atsushi Nemoto From jbglaw@dvmwest.gt.owl.de Fri May 28 09:11:32 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 09:11:36 +0100 (BST) Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:50378 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 09:11:22 +0100 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 09BF14B762; Fri, 28 May 2004 10:11:22 +0200 (CEST) Date: Fri, 28 May 2004 10:11:21 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Reply to CVS generated mails Message-ID: <20040528081121.GO1912@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xCc3NE+2SqMfpWuY" Content-Disposition: inline X-Operating-System: Linux mail 2.4.18 X-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB X-gpg-key: wwwkeys.de.pgp.net User-Agent: Mutt/1.5.5.1+cvs20040105i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --xCc3NE+2SqMfpWuY Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ralf! Seems one can't any longer reply to CVS generated emails. If this was intentional, please set a "Reply-To: " header... MfG, JBG The Postfix program = =20 = =20 : host mail.linux-mips.org[62.254.210.162] said: = 554 =20 5.0.0 unresolvable address: Failed (in reply= to =20 RCPT TO command) = =20 = =20 [-- Attachment #2: Delivery error report --] = =20 [-- Type: message/delivery-status, Encoding: 7bit, Size: 0.3K --] = =20 = =20 Reporting-MTA: dns; dvmwest.gt.owl.de = =20 Arrival-Date: Fri, 28 May 2004 10:08:38 +0200 (CEST) = =20 = =20 Final-Recipient: rfc822; linux-cvs@linux-mips.org = =20 Action: failed = =20 Status: 5.0.0 = =20 Diagnostic-Code: X-Postfix; host mail.linux-mips.org[62.254.210.162] said: = 554 =20 5.0.0 unresolvable address: Failed (in reply= to =20 RCPT TO command) = =20 = =20 --=20 Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira= k! ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC= PA)); --xCc3NE+2SqMfpWuY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAtvQpHb1edYOZ4bsRAu8xAJ9+/LYdwWo0yED8JqpcdAbxn8Y67gCgh18X fB+LtoDk11z+iETiBPzCYEA= =6KRP -----END PGP SIGNATURE----- --xCc3NE+2SqMfpWuY-- From ica2_ts@csv.ica.uni-stuttgart.de Fri May 28 10:36:46 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 10:36:50 +0100 (BST) Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:41523 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 10:36:37 +0100 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42] ident=mail) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1BTdn0-0000kl-00; Fri, 28 May 2004 11:36:34 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1BTdn0-0007LM-00; Fri, 28 May 2004 11:36:34 +0200 Date: Fri, 28 May 2004 11:36:34 +0200 To: Ralf Baechle Cc: Emmanuel Michon , linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? Message-ID: <20040528093634.GP17309@rembrandt.csv.ica.uni-stuttgart.de> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <20040526203346.GA8430@linux-mips.org> <1085668313.20233.1249.camel@avalon.france.sdesigns.com> <20040527155947.GA4154@linux-mips.org> <20040528003525.GA27796@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040528003525.GA27796@linux-mips.org> User-Agent: Mutt/1.5.6i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Ralf Baechle wrote: [snip] > +static __inline__ int atomic64_sub_if_positive(int i, atomic64_t * v) > +{ > + unsigned long temp, result; > + > + __asm__ __volatile__( > + "1: lld %1, %2 # atomic64_sub_if_positive\n" > + " subu %0, %1, %3 \n" Shouldn't this be "dsubu"? Thiemo From ralf@linux-mips.org Fri May 28 10:58:06 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 11:00:35 +0100 (BST) Received: from p508B5C08.dip.t-dialin.net ([IPv6:::ffff:80.139.92.8]:46678 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 10:57:57 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4S9vsuP013020; Fri, 28 May 2004 11:57:55 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4S9vsTY013019; Fri, 28 May 2004 11:57:54 +0200 Date: Fri, 28 May 2004 11:57:54 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: Emmanuel Michon , linux-mips@linux-mips.org Subject: Re: down_trylock() implementation for MIPS 4KEc CPU implies 64bit arithmetics? Message-ID: <20040528095754.GA12295@linux-mips.org> References: <1085589315.2306.49.camel@avalon.france.sdesigns.com> <20040526203346.GA8430@linux-mips.org> <1085668313.20233.1249.camel@avalon.france.sdesigns.com> <20040527155947.GA4154@linux-mips.org> <20040528003525.GA27796@linux-mips.org> <20040528093634.GP17309@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040528093634.GP17309@rembrandt.csv.ica.uni-stuttgart.de> User-Agent: Mutt/1.4.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: 5213 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 28, 2004 at 11:36:34AM +0200, Thiemo Seufer wrote: > Ralf Baechle wrote: > [snip] > > +static __inline__ int atomic64_sub_if_positive(int i, atomic64_t * v) > > +{ > > + unsigned long temp, result; > > + > > + __asm__ __volatile__( > > + "1: lld %1, %2 # atomic64_sub_if_positive\n" > > + " subu %0, %1, %3 \n" > > Shouldn't this be "dsubu"? Yep, thanks for noticing. Fortunately this function is unused; it only exists for symmetry to it's 32-bit equivalent. I also a few variables that should be long in the atomic64 code were just int; I fixed that also. Ralf From maksik@gmx.co.uk Fri May 28 11:10:15 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 11:10:22 +0100 (BST) Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:58843 "EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 11:10:06 +0100 Received: from wh85.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77]) by relay1.uniklinik-freiburg.de (Email) with ESMTP id 5D1FF2F395 for ; Fri, 28 May 2004 12:10:02 +0200 (CEST) From: Max Zaitsev Organization: Mutella Dev co. To: linux-mips@linux-mips.org Subject: Re: help needed : cannot install linux on SGI O2 R5000 Date: Fri, 28 May 2004 12:10:05 +0200 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405281210.05259.maksik@gmx.co.uk> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: maksik@gmx.co.uk Precedence: bulk X-list: linux-mips Hi! thanks for the prompt answer. actually I've messed things up slightly. The kernel that I could boot with relative success was a frame buffer enabled one from Ilia (http://www.total-knowledge.com/progs/mips/kernels/ vmlinux.64-20040315). > The IP32 Netboot I have requires you to setup an NFS-exportable root for it > to work properly ... There should be an initrd link in the ip32 directory -- > use that for NFS root, and pass at minimum 'root=/dev/nfs > this I've tried already, but the thing is that the netboot kernel does not go beyond telling me what the entry point was. I've also tried to use the kernel from Ilya with the same root. There, everything would hang after starting the initrd script. > and it's advised you run off of serial console (if you > aren't already). > actually, I don't. I don't have a serial console/cable in my possetion and was intending to actually use the display/keyboard combination to perform the installation. Would it be possible? Can you advise me where to get a suitable netboot kernel? Regards, Max From jsun@orion.mvista.com Fri May 28 18:52:02 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 18:52:08 +0100 (BST) Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33006 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 18:51:53 +0100 Received: from orion.mvista.com (localhost.localdomain [127.0.0.1]) by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i4SHppx6020696; Fri, 28 May 2004 10:51:51 -0700 Received: (from jsun@localhost) by orion.mvista.com (8.12.8/8.12.8/Submit) id i4SHpp0U020694; Fri, 28 May 2004 10:51:51 -0700 Date: Fri, 28 May 2004 10:51:51 -0700 From: Jun Sun To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: 2.4 preempt kernel patch Message-ID: <20040528105151.G20139@mvista.com> References: <20040528.131236.112629910.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040528.131236.112629910.nemoto@toshiba-tops.co.jp>; from anemo@mba.ocn.ne.jp on Fri, May 28, 2004 at 01:12:36PM +0900 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Fri, May 28, 2004 at 01:12:36PM +0900, Atsushi Nemoto wrote: > Hi. I'm investigating preempt patch for 2.4 kernel. (MIPS part of > preempt-kernel-rml-2.4.26-pre5-1.patch seems a bit old. I'm looking > Jun Sun's 030304-b.preempt-mips.patch). > > The patch contains following block (end of > arch/mips/kernel/irq.c:do_IRQ()): > > > if (softirq_pending(cpu)) > do_softirq(); > + > +#if defined(CONFIG_PREEMPT) > + for(;;) { > + preempt_enable_no_resched(); > + if (preempt_is_disabled() || !need_resched()) > + break; > + > + db_assert(intr_off()); > + db_assert(!in_interrupt()); > + > + preempt_disable(); > + __sti(); > + preempt_schedule(); > + __cli(); > + } > +#endif > + > return 1; > } > > > Q1. What is purpose of this block? (To decrease latency? But other > archs (and 2.6 MIPS kernel) do not have block like this...) > This is to check possible preemption at the end of (possibly nested) interrupt handling. All other arches and 2.6 MIPS are doing the same thing in .S file (something like ret_from_irq path) > Q2. If an interrupt happened between __sti() and __cli(), and the > interrupt handler raise softirq, the softirq handler will not be > called soon (because do_softirq() immediately return if preempt > disabled). So we must check softirq_pending again after this block? > do_softirq() does not (and should not) return when preemtpion is disabled. We should be fine here. Jun From hadi@cyberus.ca Fri May 28 20:40:20 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 20:40:27 +0100 (BST) Received: from mx03.cybersurf.com ([IPv6:::ffff:209.197.145.106]:55199 "EHLO mx03.cybersurf.com") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 20:40:11 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BTnCB-0002MD-Vr for linux-mips@linux-mips.org; Fri, 28 May 2004 15:39:11 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BTn9w-0003J4-8k; Fri, 28 May 2004 15:36:52 -0400 Subject: weird sb1250 behavior From: jamal Reply-To: hadi@cyberus.ca To: linux-mips@linux-mips.org Cc: sibyte-users@bitmover.com Content-Type: multipart/mixed; boundary="=-yRcc9hJc2nJX+maAD6p5" Organization: jamalopolis Message-Id: <1085773008.1029.59.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 May 2004 15:36:48 -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: linux-mips --=-yRcc9hJc2nJX+maAD6p5 Content-Type: text/plain Content-Transfer-Encoding: 7bit found some very strange behavior with sb1250. Gcc 3.2.3 with sibyte mods. Running Linux 2.4.21 with whatever mods off sibyte. Testcase: sending a large amount of traffic -->eth0-->someprocessing-->eth1 given the nature of processing, say i was getting 100Kpps throughput. Now i fire a very basic program that has just loops and forever sums up two numbers. --- 1 #include 2 3 int main () 4 { 5 int a = 1; 6 int b = 2; 7 int c = 0; 8 // int c; 9 while (1) { 10 c = a + b; 11 } 12 } -------- I see very little drop in throughput - probably around 0.01%. Now comment line 7 then uncomment line 8. Hallelujah. Perfomance drops to about 100pps. Thats about a factor of 1000 down! Interesting thing is if you add a nop (__asm__ __volatile__("nop");) in the second version just before the while loop, we get back the same performance as in the earlier version. Apologies in advance for attaching objdumps (since there maybe folks who dont have access to the sibyte tools) 1) while-init-dis is for case 1 where c is initialized 2) while-noinit-dis is for case 2 where c is not initialize 3) while-nop-dis is for case 3 when you have nop thrown in. cheers, jamal --=-yRcc9hJc2nJX+maAD6p5 Content-Disposition: attachment; filename=while-init-dis Content-Type: text/plain; name=while-init-dis; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit while-init: file format elf32-tradbigmips Disassembly of section .init: 004003f0 <_init>: 4003f0: 3c1c0fc0 lui gp,0xfc0 4003f4: 279c7c40 addiu gp,gp,31808 4003f8: 0399e021 addu gp,gp,t9 4003fc: 27bdffe0 addiu sp,sp,-32 400400: afbc0010 sw gp,16(sp) 400404: afbf001c sw ra,28(sp) 400408: afbc0018 sw gp,24(sp) 40040c: 8f998018 lw t9,-32744(gp) 400410: 00000000 nop 400414: 27390500 addiu t9,t9,1280 ... 400420: 0320f809 jalr t9 400424: 00000000 nop 400428: 8fbc0010 lw gp,16(sp) 40042c: 00000000 nop 400430: 8f998018 lw t9,-32744(gp) 400434: 00000000 nop 400438: 2739063c addiu t9,t9,1596 40043c: 00000000 nop 400440: 0320f809 jalr t9 400444: 00000000 nop 400448: 8fbc0010 lw gp,16(sp) 40044c: 00000000 nop 400450: 8f998018 lw t9,-32744(gp) 400454: 00000000 nop 400458: 27390720 addiu t9,t9,1824 40045c: 00000000 nop 400460: 0320f809 jalr t9 400464: 00000000 nop 400468: 8fbc0010 lw gp,16(sp) 40046c: 00000000 nop 400470: 8fbf001c lw ra,28(sp) 400474: 00000000 nop 400478: 03e00008 jr ra 40047c: 27bd0020 addiu sp,sp,32 Disassembly of section .text: 00400480 <__start>: 400480: 04100001 bltzal zero,400488 <__start+0x8> 400484: 00000000 nop 400488: 3c1c0fc0 lui gp,0xfc0 40048c: 279c7ba8 addiu gp,gp,31656 400490: 039fe021 addu gp,gp,ra 400494: 0000f821 move ra,zero 400498: 8f84803c lw a0,-32708(gp) 40049c: 8fa50000 lw a1,0(sp) 4004a0: 27a60004 addiu a2,sp,4 4004a4: 3c01ffff lui at,0xffff 4004a8: 3421fff8 ori at,at,0xfff8 4004ac: 03a1e824 and sp,sp,at 4004b0: 27bdffe0 addiu sp,sp,-32 4004b4: 8f878040 lw a3,-32704(gp) 4004b8: 8f888034 lw t0,-32716(gp) 4004bc: 00000000 nop 4004c0: afa80010 sw t0,16(sp) 4004c4: afa20014 sw v0,20(sp) 4004c8: afbd0018 sw sp,24(sp) 4004cc: 8f998038 lw t9,-32712(gp) 4004d0: 00000000 nop 4004d4: 0320f809 jalr t9 4004d8: 00000000 nop 004004dc : 4004dc: 1000ffff b 4004dc 4004e0: 00000000 nop ... 00400500 : 400500: 3c1c0fc0 lui gp,0xfc0 400504: 279c7b30 addiu gp,gp,31536 400508: 0399e021 addu gp,gp,t9 40050c: 27bdffe0 addiu sp,sp,-32 400510: afbc0010 sw gp,16(sp) 400514: afbf001c sw ra,28(sp) 400518: 8f82802c lw v0,-32724(gp) 40051c: 00000000 nop 400520: 10400006 beqz v0,40053c 400524: afbc0018 sw gp,24(sp) 400528: 0040c821 move t9,v0 40052c: 00000000 nop 400530: 0320f809 jalr t9 400534: 00000000 nop 400538: 8fbc0010 lw gp,16(sp) 40053c: 8fbf001c lw ra,28(sp) ... 400548: 03e00008 jr ra 40054c: 27bd0020 addiu sp,sp,32 00400550 <__do_global_dtors_aux>: 400550: 3c1c0fc0 lui gp,0xfc0 400554: 279c7ae0 addiu gp,gp,31456 400558: 0399e021 addu gp,gp,t9 40055c: 27bdffe0 addiu sp,sp,-32 400560: afbc0010 sw gp,16(sp) 400564: 8f82801c lw v0,-32740(gp) 400568: 00000000 nop 40056c: 24420080 addiu v0,v0,128 400570: 90420000 lbu v0,0(v0) 400574: afbf001c sw ra,28(sp) 400578: 14400021 bnez v0,400600 <__do_global_dtors_aux+0xb0> 40057c: afbc0018 sw gp,24(sp) 400580: 8f82801c lw v0,-32740(gp) 400584: 00000000 nop 400588: 24420014 addiu v0,v0,20 40058c: 8c420000 lw v0,0(v0) 400590: 00000000 nop 400594: 8c430000 lw v1,0(v0) 400598: 00000000 nop 40059c: 10600013 beqz v1,4005ec <__do_global_dtors_aux+0x9c> 4005a0: 24420004 addiu v0,v0,4 4005a4: 8f81801c lw at,-32740(gp) 4005a8: 00000000 nop 4005ac: 24210014 addiu at,at,20 4005b0: ac220000 sw v0,0(at) 4005b4: 0060c821 move t9,v1 4005b8: 0320f809 jalr t9 4005bc: 00000000 nop 4005c0: 8fbc0010 lw gp,16(sp) 4005c4: 00000000 nop 4005c8: 8f82801c lw v0,-32740(gp) 4005cc: 00000000 nop 4005d0: 24420014 addiu v0,v0,20 4005d4: 8c420000 lw v0,0(v0) 4005d8: 00000000 nop 4005dc: 8c430000 lw v1,0(v0) 4005e0: 00000000 nop 4005e4: 1460ffef bnez v1,4005a4 <__do_global_dtors_aux+0x54> 4005e8: 24420004 addiu v0,v0,4 4005ec: 24020001 li v0,1 4005f0: 8f81801c lw at,-32740(gp) 4005f4: 00000000 nop 4005f8: 24210080 addiu at,at,128 4005fc: a0220000 sb v0,0(at) 400600: 8fbf001c lw ra,28(sp) 400604: 00000000 nop 400608: 03e00008 jr ra 40060c: 27bd0020 addiu sp,sp,32 00400610 : 400610: 3c1c0fc0 lui gp,0xfc0 400614: 279c7a20 addiu gp,gp,31264 400618: 0399e021 addu gp,gp,t9 40061c: 27bdffe0 addiu sp,sp,-32 400620: afbc0010 sw gp,16(sp) 400624: afbf001c sw ra,28(sp) 400628: afbc0018 sw gp,24(sp) 40062c: 8fbf001c lw ra,28(sp) 400630: 00000000 nop 400634: 03e00008 jr ra 400638: 27bd0020 addiu sp,sp,32 0040063c : 40063c: 3c1c0fc0 lui gp,0xfc0 400640: 279c79f4 addiu gp,gp,31220 400644: 0399e021 addu gp,gp,t9 400648: 27bdffe0 addiu sp,sp,-32 40064c: afbc0010 sw gp,16(sp) 400650: afbf001c sw ra,28(sp) 400654: 8f84801c lw a0,-32740(gp) 400658: 00000000 nop 40065c: 24840038 addiu a0,a0,56 400660: 8f838030 lw v1,-32720(gp) 400664: afbc0018 sw gp,24(sp) 400668: 8c820000 lw v0,0(a0) 40066c: 00000000 nop 400670: 10400007 beqz v0,400690 400674: 00000000 nop 400678: 10600005 beqz v1,400690 40067c: 00000000 nop 400680: 0060c821 move t9,v1 400684: 0320f809 jalr t9 400688: 00000000 nop 40068c: 8fbc0010 lw gp,16(sp) 400690: 8fbf001c lw ra,28(sp) 400694: 00000000 nop 400698: 03e00008 jr ra 40069c: 27bd0020 addiu sp,sp,32 004006a0 : 4006a0: 3c1c0fc0 lui gp,0xfc0 4006a4: 279c7990 addiu gp,gp,31120 4006a8: 0399e021 addu gp,gp,t9 4006ac: 27bdffe0 addiu sp,sp,-32 4006b0: afbc0010 sw gp,16(sp) 4006b4: afbf001c sw ra,28(sp) 4006b8: afbc0018 sw gp,24(sp) 4006bc: 8fbf001c lw ra,28(sp) 4006c0: 00000000 nop 4006c4: 03e00008 jr ra 4006c8: 27bd0020 addiu sp,sp,32 4006cc: 00000000 nop 004006d0
: 4006d0: 3c1c0fc0 lui gp,0xfc0 4006d4: 279c7960 addiu gp,gp,31072 4006d8: 0399e021 addu gp,gp,t9 4006dc: 27bdffe0 addiu sp,sp,-32 4006e0: afbc0000 sw gp,0(sp) 4006e4: afbe001c sw s8,28(sp) 4006e8: afbc0018 sw gp,24(sp) 4006ec: 03a0f021 move s8,sp 4006f0: 24020001 li v0,1 4006f4: afc20008 sw v0,8(s8) 4006f8: 24020002 li v0,2 4006fc: afc2000c sw v0,12(s8) 400700: afc00010 sw zero,16(s8) 400704: 8fc20008 lw v0,8(s8) 400708: 8fc3000c lw v1,12(s8) 40070c: 00000000 nop 400710: 00431021 addu v0,v0,v1 400714: 1000fffb b 400704 400718: afc20010 sw v0,16(s8) 40071c: 00000000 nop 00400720 <__do_global_ctors_aux>: 400720: 3c1c0fc0 lui gp,0xfc0 400724: 279c7910 addiu gp,gp,30992 400728: 0399e021 addu gp,gp,t9 40072c: 27bdffd8 addiu sp,sp,-40 400730: afbc0010 sw gp,16(sp) 400734: afb00018 sw s0,24(sp) 400738: 8f82801c lw v0,-32740(gp) 40073c: 00000000 nop 400740: 2442002c addiu v0,v0,44 400744: 2403ffff li v1,-1 400748: afbf0024 sw ra,36(sp) 40074c: afbc0020 sw gp,32(sp) 400750: afb1001c sw s1,28(sp) 400754: 8c44fffc lw a0,-4(v0) 400758: 00000000 nop 40075c: 1083000f beq a0,v1,40079c <__do_global_ctors_aux+0x7c> 400760: 2450fffc addiu s0,v0,-4 400764: 8f83801c lw v1,-32740(gp) 400768: 00000000 nop 40076c: 2463002c addiu v1,v1,44 400770: 8c63fffc lw v1,-4(v1) 400774: 2411ffff li s1,-1 400778: 2610fffc addiu s0,s0,-4 40077c: 0060c821 move t9,v1 400780: 0320f809 jalr t9 400784: 00000000 nop 400788: 8fbc0010 lw gp,16(sp) 40078c: 8e020000 lw v0,0(s0) 400790: 00000000 nop 400794: 1451fff8 bne v0,s1,400778 <__do_global_ctors_aux+0x58> 400798: 00401821 move v1,v0 40079c: 8fbf0024 lw ra,36(sp) 4007a0: 8fb1001c lw s1,28(sp) 4007a4: 8fb00018 lw s0,24(sp) 4007a8: 03e00008 jr ra 4007ac: 27bd0028 addiu sp,sp,40 004007b0 : 4007b0: 3c1c0fc0 lui gp,0xfc0 4007b4: 279c7880 addiu gp,gp,30848 4007b8: 0399e021 addu gp,gp,t9 4007bc: 27bdffe0 addiu sp,sp,-32 4007c0: afbc0010 sw gp,16(sp) 4007c4: afbf001c sw ra,28(sp) 4007c8: afbc0018 sw gp,24(sp) 4007cc: 8fbf001c lw ra,28(sp) 4007d0: 00000000 nop 4007d4: 03e00008 jr ra 4007d8: 27bd0020 addiu sp,sp,32 4007dc: 00000000 nop Disassembly of section .fini: 004007e0 <_fini>: 4007e0: 3c1c0fc0 lui gp,0xfc0 4007e4: 279c7850 addiu gp,gp,30800 4007e8: 0399e021 addu gp,gp,t9 4007ec: 27bdffe0 addiu sp,sp,-32 4007f0: afbc0010 sw gp,16(sp) 4007f4: afbf001c sw ra,28(sp) 4007f8: afbc0018 sw gp,24(sp) 4007fc: 00000000 nop 400800: 8f998018 lw t9,-32744(gp) 400804: 00000000 nop 400808: 27390550 addiu t9,t9,1360 40080c: 00000000 nop 400810: 0320f809 jalr t9 400814: 00000000 nop 400818: 8fbc0010 lw gp,16(sp) 40081c: 00000000 nop 400820: 8fbf001c lw ra,28(sp) 400824: 00000000 nop 400828: 03e00008 jr ra 40082c: 27bd0020 addiu sp,sp,32 --=-yRcc9hJc2nJX+maAD6p5 Content-Disposition: attachment; filename=while-noinit-dis Content-Type: text/plain; name=while-noinit-dis; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit while-noinit: file format elf32-tradbigmips Disassembly of section .init: 004003f0 <_init>: 4003f0: 3c1c0fc0 lui gp,0xfc0 4003f4: 279c7c40 addiu gp,gp,31808 4003f8: 0399e021 addu gp,gp,t9 4003fc: 27bdffe0 addiu sp,sp,-32 400400: afbc0010 sw gp,16(sp) 400404: afbf001c sw ra,28(sp) 400408: afbc0018 sw gp,24(sp) 40040c: 8f998018 lw t9,-32744(gp) 400410: 00000000 nop 400414: 27390500 addiu t9,t9,1280 ... 400420: 0320f809 jalr t9 400424: 00000000 nop 400428: 8fbc0010 lw gp,16(sp) 40042c: 00000000 nop 400430: 8f998018 lw t9,-32744(gp) 400434: 00000000 nop 400438: 2739063c addiu t9,t9,1596 40043c: 00000000 nop 400440: 0320f809 jalr t9 400444: 00000000 nop 400448: 8fbc0010 lw gp,16(sp) 40044c: 00000000 nop 400450: 8f998018 lw t9,-32744(gp) 400454: 00000000 nop 400458: 27390720 addiu t9,t9,1824 40045c: 00000000 nop 400460: 0320f809 jalr t9 400464: 00000000 nop 400468: 8fbc0010 lw gp,16(sp) 40046c: 00000000 nop 400470: 8fbf001c lw ra,28(sp) 400474: 00000000 nop 400478: 03e00008 jr ra 40047c: 27bd0020 addiu sp,sp,32 Disassembly of section .text: 00400480 <__start>: 400480: 04100001 bltzal zero,400488 <__start+0x8> 400484: 00000000 nop 400488: 3c1c0fc0 lui gp,0xfc0 40048c: 279c7ba8 addiu gp,gp,31656 400490: 039fe021 addu gp,gp,ra 400494: 0000f821 move ra,zero 400498: 8f84803c lw a0,-32708(gp) 40049c: 8fa50000 lw a1,0(sp) 4004a0: 27a60004 addiu a2,sp,4 4004a4: 3c01ffff lui at,0xffff 4004a8: 3421fff8 ori at,at,0xfff8 4004ac: 03a1e824 and sp,sp,at 4004b0: 27bdffe0 addiu sp,sp,-32 4004b4: 8f878040 lw a3,-32704(gp) 4004b8: 8f888034 lw t0,-32716(gp) 4004bc: 00000000 nop 4004c0: afa80010 sw t0,16(sp) 4004c4: afa20014 sw v0,20(sp) 4004c8: afbd0018 sw sp,24(sp) 4004cc: 8f998038 lw t9,-32712(gp) 4004d0: 00000000 nop 4004d4: 0320f809 jalr t9 4004d8: 00000000 nop 004004dc : 4004dc: 1000ffff b 4004dc 4004e0: 00000000 nop ... 00400500 : 400500: 3c1c0fc0 lui gp,0xfc0 400504: 279c7b30 addiu gp,gp,31536 400508: 0399e021 addu gp,gp,t9 40050c: 27bdffe0 addiu sp,sp,-32 400510: afbc0010 sw gp,16(sp) 400514: afbf001c sw ra,28(sp) 400518: 8f82802c lw v0,-32724(gp) 40051c: 00000000 nop 400520: 10400006 beqz v0,40053c 400524: afbc0018 sw gp,24(sp) 400528: 0040c821 move t9,v0 40052c: 00000000 nop 400530: 0320f809 jalr t9 400534: 00000000 nop 400538: 8fbc0010 lw gp,16(sp) 40053c: 8fbf001c lw ra,28(sp) ... 400548: 03e00008 jr ra 40054c: 27bd0020 addiu sp,sp,32 00400550 <__do_global_dtors_aux>: 400550: 3c1c0fc0 lui gp,0xfc0 400554: 279c7ae0 addiu gp,gp,31456 400558: 0399e021 addu gp,gp,t9 40055c: 27bdffe0 addiu sp,sp,-32 400560: afbc0010 sw gp,16(sp) 400564: 8f82801c lw v0,-32740(gp) 400568: 00000000 nop 40056c: 24420080 addiu v0,v0,128 400570: 90420000 lbu v0,0(v0) 400574: afbf001c sw ra,28(sp) 400578: 14400021 bnez v0,400600 <__do_global_dtors_aux+0xb0> 40057c: afbc0018 sw gp,24(sp) 400580: 8f82801c lw v0,-32740(gp) 400584: 00000000 nop 400588: 24420014 addiu v0,v0,20 40058c: 8c420000 lw v0,0(v0) 400590: 00000000 nop 400594: 8c430000 lw v1,0(v0) 400598: 00000000 nop 40059c: 10600013 beqz v1,4005ec <__do_global_dtors_aux+0x9c> 4005a0: 24420004 addiu v0,v0,4 4005a4: 8f81801c lw at,-32740(gp) 4005a8: 00000000 nop 4005ac: 24210014 addiu at,at,20 4005b0: ac220000 sw v0,0(at) 4005b4: 0060c821 move t9,v1 4005b8: 0320f809 jalr t9 4005bc: 00000000 nop 4005c0: 8fbc0010 lw gp,16(sp) 4005c4: 00000000 nop 4005c8: 8f82801c lw v0,-32740(gp) 4005cc: 00000000 nop 4005d0: 24420014 addiu v0,v0,20 4005d4: 8c420000 lw v0,0(v0) 4005d8: 00000000 nop 4005dc: 8c430000 lw v1,0(v0) 4005e0: 00000000 nop 4005e4: 1460ffef bnez v1,4005a4 <__do_global_dtors_aux+0x54> 4005e8: 24420004 addiu v0,v0,4 4005ec: 24020001 li v0,1 4005f0: 8f81801c lw at,-32740(gp) 4005f4: 00000000 nop 4005f8: 24210080 addiu at,at,128 4005fc: a0220000 sb v0,0(at) 400600: 8fbf001c lw ra,28(sp) 400604: 00000000 nop 400608: 03e00008 jr ra 40060c: 27bd0020 addiu sp,sp,32 00400610 : 400610: 3c1c0fc0 lui gp,0xfc0 400614: 279c7a20 addiu gp,gp,31264 400618: 0399e021 addu gp,gp,t9 40061c: 27bdffe0 addiu sp,sp,-32 400620: afbc0010 sw gp,16(sp) 400624: afbf001c sw ra,28(sp) 400628: afbc0018 sw gp,24(sp) 40062c: 8fbf001c lw ra,28(sp) 400630: 00000000 nop 400634: 03e00008 jr ra 400638: 27bd0020 addiu sp,sp,32 0040063c : 40063c: 3c1c0fc0 lui gp,0xfc0 400640: 279c79f4 addiu gp,gp,31220 400644: 0399e021 addu gp,gp,t9 400648: 27bdffe0 addiu sp,sp,-32 40064c: afbc0010 sw gp,16(sp) 400650: afbf001c sw ra,28(sp) 400654: 8f84801c lw a0,-32740(gp) 400658: 00000000 nop 40065c: 24840038 addiu a0,a0,56 400660: 8f838030 lw v1,-32720(gp) 400664: afbc0018 sw gp,24(sp) 400668: 8c820000 lw v0,0(a0) 40066c: 00000000 nop 400670: 10400007 beqz v0,400690 400674: 00000000 nop 400678: 10600005 beqz v1,400690 40067c: 00000000 nop 400680: 0060c821 move t9,v1 400684: 0320f809 jalr t9 400688: 00000000 nop 40068c: 8fbc0010 lw gp,16(sp) 400690: 8fbf001c lw ra,28(sp) 400694: 00000000 nop 400698: 03e00008 jr ra 40069c: 27bd0020 addiu sp,sp,32 004006a0 : 4006a0: 3c1c0fc0 lui gp,0xfc0 4006a4: 279c7990 addiu gp,gp,31120 4006a8: 0399e021 addu gp,gp,t9 4006ac: 27bdffe0 addiu sp,sp,-32 4006b0: afbc0010 sw gp,16(sp) 4006b4: afbf001c sw ra,28(sp) 4006b8: afbc0018 sw gp,24(sp) 4006bc: 8fbf001c lw ra,28(sp) 4006c0: 00000000 nop 4006c4: 03e00008 jr ra 4006c8: 27bd0020 addiu sp,sp,32 4006cc: 00000000 nop 004006d0
: 4006d0: 3c1c0fc0 lui gp,0xfc0 4006d4: 279c7960 addiu gp,gp,31072 4006d8: 0399e021 addu gp,gp,t9 4006dc: 27bdffe0 addiu sp,sp,-32 4006e0: afbc0000 sw gp,0(sp) 4006e4: afbe001c sw s8,28(sp) 4006e8: afbc0018 sw gp,24(sp) 4006ec: 03a0f021 move s8,sp 4006f0: 24020001 li v0,1 4006f4: afc20008 sw v0,8(s8) 4006f8: 24020002 li v0,2 4006fc: afc2000c sw v0,12(s8) 400700: 8fc20008 lw v0,8(s8) 400704: 8fc3000c lw v1,12(s8) 400708: 00000000 nop 40070c: 00431021 addu v0,v0,v1 400710: 1000fffb b 400700 400714: afc20010 sw v0,16(s8) ... 00400720 <__do_global_ctors_aux>: 400720: 3c1c0fc0 lui gp,0xfc0 400724: 279c7910 addiu gp,gp,30992 400728: 0399e021 addu gp,gp,t9 40072c: 27bdffd8 addiu sp,sp,-40 400730: afbc0010 sw gp,16(sp) 400734: afb00018 sw s0,24(sp) 400738: 8f82801c lw v0,-32740(gp) 40073c: 00000000 nop 400740: 2442002c addiu v0,v0,44 400744: 2403ffff li v1,-1 400748: afbf0024 sw ra,36(sp) 40074c: afbc0020 sw gp,32(sp) 400750: afb1001c sw s1,28(sp) 400754: 8c44fffc lw a0,-4(v0) 400758: 00000000 nop 40075c: 1083000f beq a0,v1,40079c <__do_global_ctors_aux+0x7c> 400760: 2450fffc addiu s0,v0,-4 400764: 8f83801c lw v1,-32740(gp) 400768: 00000000 nop 40076c: 2463002c addiu v1,v1,44 400770: 8c63fffc lw v1,-4(v1) 400774: 2411ffff li s1,-1 400778: 2610fffc addiu s0,s0,-4 40077c: 0060c821 move t9,v1 400780: 0320f809 jalr t9 400784: 00000000 nop 400788: 8fbc0010 lw gp,16(sp) 40078c: 8e020000 lw v0,0(s0) 400790: 00000000 nop 400794: 1451fff8 bne v0,s1,400778 <__do_global_ctors_aux+0x58> 400798: 00401821 move v1,v0 40079c: 8fbf0024 lw ra,36(sp) 4007a0: 8fb1001c lw s1,28(sp) 4007a4: 8fb00018 lw s0,24(sp) 4007a8: 03e00008 jr ra 4007ac: 27bd0028 addiu sp,sp,40 004007b0 : 4007b0: 3c1c0fc0 lui gp,0xfc0 4007b4: 279c7880 addiu gp,gp,30848 4007b8: 0399e021 addu gp,gp,t9 4007bc: 27bdffe0 addiu sp,sp,-32 4007c0: afbc0010 sw gp,16(sp) 4007c4: afbf001c sw ra,28(sp) 4007c8: afbc0018 sw gp,24(sp) 4007cc: 8fbf001c lw ra,28(sp) 4007d0: 00000000 nop 4007d4: 03e00008 jr ra 4007d8: 27bd0020 addiu sp,sp,32 4007dc: 00000000 nop Disassembly of section .fini: 004007e0 <_fini>: 4007e0: 3c1c0fc0 lui gp,0xfc0 4007e4: 279c7850 addiu gp,gp,30800 4007e8: 0399e021 addu gp,gp,t9 4007ec: 27bdffe0 addiu sp,sp,-32 4007f0: afbc0010 sw gp,16(sp) 4007f4: afbf001c sw ra,28(sp) 4007f8: afbc0018 sw gp,24(sp) 4007fc: 00000000 nop 400800: 8f998018 lw t9,-32744(gp) 400804: 00000000 nop 400808: 27390550 addiu t9,t9,1360 40080c: 00000000 nop 400810: 0320f809 jalr t9 400814: 00000000 nop 400818: 8fbc0010 lw gp,16(sp) 40081c: 00000000 nop 400820: 8fbf001c lw ra,28(sp) 400824: 00000000 nop 400828: 03e00008 jr ra 40082c: 27bd0020 addiu sp,sp,32 --=-yRcc9hJc2nJX+maAD6p5 Content-Disposition: attachment; filename=while-nop-dis Content-Type: text/plain; name=while-nop-dis; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit while-nop: file format elf32-tradbigmips Disassembly of section .init: 004003f0 <_init>: 4003f0: 3c1c0fc0 lui gp,0xfc0 4003f4: 279c7c40 addiu gp,gp,31808 4003f8: 0399e021 addu gp,gp,t9 4003fc: 27bdffe0 addiu sp,sp,-32 400400: afbc0010 sw gp,16(sp) 400404: afbf001c sw ra,28(sp) 400408: afbc0018 sw gp,24(sp) 40040c: 8f998018 lw t9,-32744(gp) 400410: 00000000 nop 400414: 27390500 addiu t9,t9,1280 ... 400420: 0320f809 jalr t9 400424: 00000000 nop 400428: 8fbc0010 lw gp,16(sp) 40042c: 00000000 nop 400430: 8f998018 lw t9,-32744(gp) 400434: 00000000 nop 400438: 2739063c addiu t9,t9,1596 40043c: 00000000 nop 400440: 0320f809 jalr t9 400444: 00000000 nop 400448: 8fbc0010 lw gp,16(sp) 40044c: 00000000 nop 400450: 8f998018 lw t9,-32744(gp) 400454: 00000000 nop 400458: 27390720 addiu t9,t9,1824 40045c: 00000000 nop 400460: 0320f809 jalr t9 400464: 00000000 nop 400468: 8fbc0010 lw gp,16(sp) 40046c: 00000000 nop 400470: 8fbf001c lw ra,28(sp) 400474: 00000000 nop 400478: 03e00008 jr ra 40047c: 27bd0020 addiu sp,sp,32 Disassembly of section .text: 00400480 <__start>: 400480: 04100001 bltzal zero,400488 <__start+0x8> 400484: 00000000 nop 400488: 3c1c0fc0 lui gp,0xfc0 40048c: 279c7ba8 addiu gp,gp,31656 400490: 039fe021 addu gp,gp,ra 400494: 0000f821 move ra,zero 400498: 8f84803c lw a0,-32708(gp) 40049c: 8fa50000 lw a1,0(sp) 4004a0: 27a60004 addiu a2,sp,4 4004a4: 3c01ffff lui at,0xffff 4004a8: 3421fff8 ori at,at,0xfff8 4004ac: 03a1e824 and sp,sp,at 4004b0: 27bdffe0 addiu sp,sp,-32 4004b4: 8f878040 lw a3,-32704(gp) 4004b8: 8f888034 lw t0,-32716(gp) 4004bc: 00000000 nop 4004c0: afa80010 sw t0,16(sp) 4004c4: afa20014 sw v0,20(sp) 4004c8: afbd0018 sw sp,24(sp) 4004cc: 8f998038 lw t9,-32712(gp) 4004d0: 00000000 nop 4004d4: 0320f809 jalr t9 4004d8: 00000000 nop 004004dc : 4004dc: 1000ffff b 4004dc 4004e0: 00000000 nop ... 00400500 : 400500: 3c1c0fc0 lui gp,0xfc0 400504: 279c7b30 addiu gp,gp,31536 400508: 0399e021 addu gp,gp,t9 40050c: 27bdffe0 addiu sp,sp,-32 400510: afbc0010 sw gp,16(sp) 400514: afbf001c sw ra,28(sp) 400518: 8f82802c lw v0,-32724(gp) 40051c: 00000000 nop 400520: 10400006 beqz v0,40053c 400524: afbc0018 sw gp,24(sp) 400528: 0040c821 move t9,v0 40052c: 00000000 nop 400530: 0320f809 jalr t9 400534: 00000000 nop 400538: 8fbc0010 lw gp,16(sp) 40053c: 8fbf001c lw ra,28(sp) ... 400548: 03e00008 jr ra 40054c: 27bd0020 addiu sp,sp,32 00400550 <__do_global_dtors_aux>: 400550: 3c1c0fc0 lui gp,0xfc0 400554: 279c7ae0 addiu gp,gp,31456 400558: 0399e021 addu gp,gp,t9 40055c: 27bdffe0 addiu sp,sp,-32 400560: afbc0010 sw gp,16(sp) 400564: 8f82801c lw v0,-32740(gp) 400568: 00000000 nop 40056c: 24420080 addiu v0,v0,128 400570: 90420000 lbu v0,0(v0) 400574: afbf001c sw ra,28(sp) 400578: 14400021 bnez v0,400600 <__do_global_dtors_aux+0xb0> 40057c: afbc0018 sw gp,24(sp) 400580: 8f82801c lw v0,-32740(gp) 400584: 00000000 nop 400588: 24420014 addiu v0,v0,20 40058c: 8c420000 lw v0,0(v0) 400590: 00000000 nop 400594: 8c430000 lw v1,0(v0) 400598: 00000000 nop 40059c: 10600013 beqz v1,4005ec <__do_global_dtors_aux+0x9c> 4005a0: 24420004 addiu v0,v0,4 4005a4: 8f81801c lw at,-32740(gp) 4005a8: 00000000 nop 4005ac: 24210014 addiu at,at,20 4005b0: ac220000 sw v0,0(at) 4005b4: 0060c821 move t9,v1 4005b8: 0320f809 jalr t9 4005bc: 00000000 nop 4005c0: 8fbc0010 lw gp,16(sp) 4005c4: 00000000 nop 4005c8: 8f82801c lw v0,-32740(gp) 4005cc: 00000000 nop 4005d0: 24420014 addiu v0,v0,20 4005d4: 8c420000 lw v0,0(v0) 4005d8: 00000000 nop 4005dc: 8c430000 lw v1,0(v0) 4005e0: 00000000 nop 4005e4: 1460ffef bnez v1,4005a4 <__do_global_dtors_aux+0x54> 4005e8: 24420004 addiu v0,v0,4 4005ec: 24020001 li v0,1 4005f0: 8f81801c lw at,-32740(gp) 4005f4: 00000000 nop 4005f8: 24210080 addiu at,at,128 4005fc: a0220000 sb v0,0(at) 400600: 8fbf001c lw ra,28(sp) 400604: 00000000 nop 400608: 03e00008 jr ra 40060c: 27bd0020 addiu sp,sp,32 00400610 : 400610: 3c1c0fc0 lui gp,0xfc0 400614: 279c7a20 addiu gp,gp,31264 400618: 0399e021 addu gp,gp,t9 40061c: 27bdffe0 addiu sp,sp,-32 400620: afbc0010 sw gp,16(sp) 400624: afbf001c sw ra,28(sp) 400628: afbc0018 sw gp,24(sp) 40062c: 8fbf001c lw ra,28(sp) 400630: 00000000 nop 400634: 03e00008 jr ra 400638: 27bd0020 addiu sp,sp,32 0040063c : 40063c: 3c1c0fc0 lui gp,0xfc0 400640: 279c79f4 addiu gp,gp,31220 400644: 0399e021 addu gp,gp,t9 400648: 27bdffe0 addiu sp,sp,-32 40064c: afbc0010 sw gp,16(sp) 400650: afbf001c sw ra,28(sp) 400654: 8f84801c lw a0,-32740(gp) 400658: 00000000 nop 40065c: 24840038 addiu a0,a0,56 400660: 8f838030 lw v1,-32720(gp) 400664: afbc0018 sw gp,24(sp) 400668: 8c820000 lw v0,0(a0) 40066c: 00000000 nop 400670: 10400007 beqz v0,400690 400674: 00000000 nop 400678: 10600005 beqz v1,400690 40067c: 00000000 nop 400680: 0060c821 move t9,v1 400684: 0320f809 jalr t9 400688: 00000000 nop 40068c: 8fbc0010 lw gp,16(sp) 400690: 8fbf001c lw ra,28(sp) 400694: 00000000 nop 400698: 03e00008 jr ra 40069c: 27bd0020 addiu sp,sp,32 004006a0 : 4006a0: 3c1c0fc0 lui gp,0xfc0 4006a4: 279c7990 addiu gp,gp,31120 4006a8: 0399e021 addu gp,gp,t9 4006ac: 27bdffe0 addiu sp,sp,-32 4006b0: afbc0010 sw gp,16(sp) 4006b4: afbf001c sw ra,28(sp) 4006b8: afbc0018 sw gp,24(sp) 4006bc: 8fbf001c lw ra,28(sp) 4006c0: 00000000 nop 4006c4: 03e00008 jr ra 4006c8: 27bd0020 addiu sp,sp,32 4006cc: 00000000 nop 004006d0
: 4006d0: 3c1c0fc0 lui gp,0xfc0 4006d4: 279c7960 addiu gp,gp,31072 4006d8: 0399e021 addu gp,gp,t9 4006dc: 27bdffe0 addiu sp,sp,-32 4006e0: afbc0000 sw gp,0(sp) 4006e4: afbe001c sw s8,28(sp) 4006e8: afbc0018 sw gp,24(sp) 4006ec: 03a0f021 move s8,sp 4006f0: 24020001 li v0,1 4006f4: afc20008 sw v0,8(s8) 4006f8: 24020002 li v0,2 4006fc: afc2000c sw v0,12(s8) 400700: 00000000 nop 400704: 8fc20008 lw v0,8(s8) 400708: 8fc3000c lw v1,12(s8) 40070c: 00000000 nop 400710: 00431021 addu v0,v0,v1 400714: 1000fffb b 400704 400718: afc20010 sw v0,16(s8) 40071c: 00000000 nop 00400720 <__do_global_ctors_aux>: 400720: 3c1c0fc0 lui gp,0xfc0 400724: 279c7910 addiu gp,gp,30992 400728: 0399e021 addu gp,gp,t9 40072c: 27bdffd8 addiu sp,sp,-40 400730: afbc0010 sw gp,16(sp) 400734: afb00018 sw s0,24(sp) 400738: 8f82801c lw v0,-32740(gp) 40073c: 00000000 nop 400740: 2442002c addiu v0,v0,44 400744: 2403ffff li v1,-1 400748: afbf0024 sw ra,36(sp) 40074c: afbc0020 sw gp,32(sp) 400750: afb1001c sw s1,28(sp) 400754: 8c44fffc lw a0,-4(v0) 400758: 00000000 nop 40075c: 1083000f beq a0,v1,40079c <__do_global_ctors_aux+0x7c> 400760: 2450fffc addiu s0,v0,-4 400764: 8f83801c lw v1,-32740(gp) 400768: 00000000 nop 40076c: 2463002c addiu v1,v1,44 400770: 8c63fffc lw v1,-4(v1) 400774: 2411ffff li s1,-1 400778: 2610fffc addiu s0,s0,-4 40077c: 0060c821 move t9,v1 400780: 0320f809 jalr t9 400784: 00000000 nop 400788: 8fbc0010 lw gp,16(sp) 40078c: 8e020000 lw v0,0(s0) 400790: 00000000 nop 400794: 1451fff8 bne v0,s1,400778 <__do_global_ctors_aux+0x58> 400798: 00401821 move v1,v0 40079c: 8fbf0024 lw ra,36(sp) 4007a0: 8fb1001c lw s1,28(sp) 4007a4: 8fb00018 lw s0,24(sp) 4007a8: 03e00008 jr ra 4007ac: 27bd0028 addiu sp,sp,40 004007b0 : 4007b0: 3c1c0fc0 lui gp,0xfc0 4007b4: 279c7880 addiu gp,gp,30848 4007b8: 0399e021 addu gp,gp,t9 4007bc: 27bdffe0 addiu sp,sp,-32 4007c0: afbc0010 sw gp,16(sp) 4007c4: afbf001c sw ra,28(sp) 4007c8: afbc0018 sw gp,24(sp) 4007cc: 8fbf001c lw ra,28(sp) 4007d0: 00000000 nop 4007d4: 03e00008 jr ra 4007d8: 27bd0020 addiu sp,sp,32 4007dc: 00000000 nop Disassembly of section .fini: 004007e0 <_fini>: 4007e0: 3c1c0fc0 lui gp,0xfc0 4007e4: 279c7850 addiu gp,gp,30800 4007e8: 0399e021 addu gp,gp,t9 4007ec: 27bdffe0 addiu sp,sp,-32 4007f0: afbc0010 sw gp,16(sp) 4007f4: afbf001c sw ra,28(sp) 4007f8: afbc0018 sw gp,24(sp) 4007fc: 00000000 nop 400800: 8f998018 lw t9,-32744(gp) 400804: 00000000 nop 400808: 27390550 addiu t9,t9,1360 40080c: 00000000 nop 400810: 0320f809 jalr t9 400814: 00000000 nop 400818: 8fbc0010 lw gp,16(sp) 40081c: 00000000 nop 400820: 8fbf001c lw ra,28(sp) 400824: 00000000 nop 400828: 03e00008 jr ra 40082c: 27bd0020 addiu sp,sp,32 --=-yRcc9hJc2nJX+maAD6p5-- From kevink@mips.com Fri May 28 21:11:08 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 21:11:12 +0100 (BST) Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:34037 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 21:10:59 +0100 Received: from mercury.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.11/8.12.11) with ESMTP id i4SJurlE028757; Fri, 28 May 2004 12:56:53 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.12.11/8.12.11) with SMTP id i4SK8iZR002985; Fri, 28 May 2004 13:08:45 -0700 (PDT) Message-ID: <01ea01c444f0$03d6b8e0$10eca8c0@grendel> From: "Kevin D. Kissell" To: , Cc: References: <1085773008.1029.59.camel@jzny.localdomain> Subject: Re: weird sb1250 behavior Date: Fri, 28 May 2004 22:11:49 +0200 Organization: MIPS Technologies Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanned-By: MIMEDefang 2.39 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5217 X-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 This could be any one of a number of wierd effects that one sees from time to time. Rather than speculate, would it be too much to ask you to run objdump --disassemble on the different versions of your test program and post the results? ----- Original Message ----- From: "jamal" To: Cc: Sent: Friday, May 28, 2004 21:36 Subject: weird sb1250 behavior > > found some very strange behavior with sb1250. > Gcc 3.2.3 with sibyte mods. Running Linux 2.4.21 with whatever > mods off sibyte. > > Testcase: > sending a large amount of traffic > -->eth0-->someprocessing-->eth1 > > given the nature of processing, say i was getting 100Kpps throughput. > Now i fire a very basic program that has just loops and forever > sums up two numbers. > > --- > 1 #include > 2 > 3 int main () > 4 { > 5 int a = 1; > 6 int b = 2; > 7 int c = 0; > 8 // int c; > 9 while (1) { > 10 c = a + b; > 11 } > 12 } > -------- > > I see very little drop in throughput - probably around 0.01%. > > Now comment line 7 then uncomment line 8. Hallelujah. > Perfomance drops to about 100pps. Thats about a factor of 1000 down! > > Interesting thing is if you add a nop (__asm__ __volatile__("nop");) > in the second version just before the while loop, we get back the same > performance as in the earlier version. > Apologies in advance for attaching objdumps (since there maybe folks who > dont have access to the sibyte tools) > 1) while-init-dis is for case 1 where c is initialized > 2) while-noinit-dis is for case 2 where c is not initialize > 3) while-nop-dis is for case 3 when you have nop thrown in. > > > cheers, > jamal > > From hadi@cyberus.ca Fri May 28 21:19:35 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 21:19:42 +0100 (BST) Received: from mx01.cybersurf.com ([IPv6:::ffff:209.197.145.104]:35564 "EHLO mx01.cybersurf.com") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 21:19:26 +0100 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BTno6-0007PJ-Ku for linux-mips@linux-mips.org; Fri, 28 May 2004 16:18:22 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BTnlm-00036q-LE; Fri, 28 May 2004 16:15:58 -0400 Subject: Re: weird sb1250 behavior From: jamal Reply-To: hadi@cyberus.ca To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org, sibyte-users@bitmover.com In-Reply-To: <01ea01c444f0$03d6b8e0$10eca8c0@grendel> References: <1085773008.1029.59.camel@jzny.localdomain> <01ea01c444f0$03d6b8e0$10eca8c0@grendel> Content-Type: multipart/mixed; boundary="=-gYSHEU3eEJHsPXWYmfN5" Organization: jamalopolis Message-Id: <1085775352.1031.66.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 28 May 2004 16:15:52 -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: linux-mips --=-gYSHEU3eEJHsPXWYmfN5 Content-Type: text/plain Content-Transfer-Encoding: 7bit I did attach that; but here goes again in case something stripped it off. If it doesnt make it let me know and i will post a URL instead. 1) while-init-dis is for case 1 where c is initialized 2) while-noinit-dis is for case 2 where c is not initialize 3) while-nop-dis is for case 3 when you have nop thrown in. cheers, jamal On Fri, 2004-05-28 at 16:11, Kevin D. Kissell wrote: > This could be any one of a number of wierd effects that one sees > from time to time. Rather than speculate, would it be too much > to ask you to run objdump --disassemble on the different versions > of your test program and post the results? > > ----- Original Message ----- > From: "jamal" > To: > Cc: > Sent: Friday, May 28, 2004 21:36 > Subject: weird sb1250 behavior > > > > > > found some very strange behavior with sb1250. > > Gcc 3.2.3 with sibyte mods. Running Linux 2.4.21 with whatever > > mods off sibyte. > > > > Testcase: > > sending a large amount of traffic > > -->eth0-->someprocessing-->eth1 > > > > given the nature of processing, say i was getting 100Kpps throughput. > > Now i fire a very basic program that has just loops and forever > > sums up two numbers. > > > > --- > > 1 #include > > 2 > > 3 int main () > > 4 { > > 5 int a = 1; > > 6 int b = 2; > > 7 int c = 0; > > 8 // int c; > > 9 while (1) { > > 10 c = a + b; > > 11 } > > 12 } > > -------- > > > > I see very little drop in throughput - probably around 0.01%. > > > > Now comment line 7 then uncomment line 8. Hallelujah. > > Perfomance drops to about 100pps. Thats about a factor of 1000 down! > > > > Interesting thing is if you add a nop (__asm__ __volatile__("nop");) > > in the second version just before the while loop, we get back the same > > performance as in the earlier version. > > Apologies in advance for attaching objdumps (since there maybe folks who > > dont have access to the sibyte tools) > > 1) while-init-dis is for case 1 where c is initialized > > 2) while-noinit-dis is for case 2 where c is not initialize > > 3) while-nop-dis is for case 3 when you have nop thrown in. > > > > > > cheers, > > jamal > > > > > --=-gYSHEU3eEJHsPXWYmfN5 Content-Disposition: attachment; filename=while-init-dis Content-Type: text/plain; name=while-init-dis; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit while-init: file format elf32-tradbigmips Disassembly of section .init: 004003f0 <_init>: 4003f0: 3c1c0fc0 lui gp,0xfc0 4003f4: 279c7c40 addiu gp,gp,31808 4003f8: 0399e021 addu gp,gp,t9 4003fc: 27bdffe0 addiu sp,sp,-32 400400: afbc0010 sw gp,16(sp) 400404: afbf001c sw ra,28(sp) 400408: afbc0018 sw gp,24(sp) 40040c: 8f998018 lw t9,-32744(gp) 400410: 00000000 nop 400414: 27390500 addiu t9,t9,1280 ... 400420: 0320f809 jalr t9 400424: 00000000 nop 400428: 8fbc0010 lw gp,16(sp) 40042c: 00000000 nop 400430: 8f998018 lw t9,-32744(gp) 400434: 00000000 nop 400438: 2739063c addiu t9,t9,1596 40043c: 00000000 nop 400440: 0320f809 jalr t9 400444: 00000000 nop 400448: 8fbc0010 lw gp,16(sp) 40044c: 00000000 nop 400450: 8f998018 lw t9,-32744(gp) 400454: 00000000 nop 400458: 27390720 addiu t9,t9,1824 40045c: 00000000 nop 400460: 0320f809 jalr t9 400464: 00000000 nop 400468: 8fbc0010 lw gp,16(sp) 40046c: 00000000 nop 400470: 8fbf001c lw ra,28(sp) 400474: 00000000 nop 400478: 03e00008 jr ra 40047c: 27bd0020 addiu sp,sp,32 Disassembly of section .text: 00400480 <__start>: 400480: 04100001 bltzal zero,400488 <__start+0x8> 400484: 00000000 nop 400488: 3c1c0fc0 lui gp,0xfc0 40048c: 279c7ba8 addiu gp,gp,31656 400490: 039fe021 addu gp,gp,ra 400494: 0000f821 move ra,zero 400498: 8f84803c lw a0,-32708(gp) 40049c: 8fa50000 lw a1,0(sp) 4004a0: 27a60004 addiu a2,sp,4 4004a4: 3c01ffff lui at,0xffff 4004a8: 3421fff8 ori at,at,0xfff8 4004ac: 03a1e824 and sp,sp,at 4004b0: 27bdffe0 addiu sp,sp,-32 4004b4: 8f878040 lw a3,-32704(gp) 4004b8: 8f888034 lw t0,-32716(gp) 4004bc: 00000000 nop 4004c0: afa80010 sw t0,16(sp) 4004c4: afa20014 sw v0,20(sp) 4004c8: afbd0018 sw sp,24(sp) 4004cc: 8f998038 lw t9,-32712(gp) 4004d0: 00000000 nop 4004d4: 0320f809 jalr t9 4004d8: 00000000 nop 004004dc : 4004dc: 1000ffff b 4004dc 4004e0: 00000000 nop ... 00400500 : 400500: 3c1c0fc0 lui gp,0xfc0 400504: 279c7b30 addiu gp,gp,31536 400508: 0399e021 addu gp,gp,t9 40050c: 27bdffe0 addiu sp,sp,-32 400510: afbc0010 sw gp,16(sp) 400514: afbf001c sw ra,28(sp) 400518: 8f82802c lw v0,-32724(gp) 40051c: 00000000 nop 400520: 10400006 beqz v0,40053c 400524: afbc0018 sw gp,24(sp) 400528: 0040c821 move t9,v0 40052c: 00000000 nop 400530: 0320f809 jalr t9 400534: 00000000 nop 400538: 8fbc0010 lw gp,16(sp) 40053c: 8fbf001c lw ra,28(sp) ... 400548: 03e00008 jr ra 40054c: 27bd0020 addiu sp,sp,32 00400550 <__do_global_dtors_aux>: 400550: 3c1c0fc0 lui gp,0xfc0 400554: 279c7ae0 addiu gp,gp,31456 400558: 0399e021 addu gp,gp,t9 40055c: 27bdffe0 addiu sp,sp,-32 400560: afbc0010 sw gp,16(sp) 400564: 8f82801c lw v0,-32740(gp) 400568: 00000000 nop 40056c: 24420080 addiu v0,v0,128 400570: 90420000 lbu v0,0(v0) 400574: afbf001c sw ra,28(sp) 400578: 14400021 bnez v0,400600 <__do_global_dtors_aux+0xb0> 40057c: afbc0018 sw gp,24(sp) 400580: 8f82801c lw v0,-32740(gp) 400584: 00000000 nop 400588: 24420014 addiu v0,v0,20 40058c: 8c420000 lw v0,0(v0) 400590: 00000000 nop 400594: 8c430000 lw v1,0(v0) 400598: 00000000 nop 40059c: 10600013 beqz v1,4005ec <__do_global_dtors_aux+0x9c> 4005a0: 24420004 addiu v0,v0,4 4005a4: 8f81801c lw at,-32740(gp) 4005a8: 00000000 nop 4005ac: 24210014 addiu at,at,20 4005b0: ac220000 sw v0,0(at) 4005b4: 0060c821 move t9,v1 4005b8: 0320f809 jalr t9 4005bc: 00000000 nop 4005c0: 8fbc0010 lw gp,16(sp) 4005c4: 00000000 nop 4005c8: 8f82801c lw v0,-32740(gp) 4005cc: 00000000 nop 4005d0: 24420014 addiu v0,v0,20 4005d4: 8c420000 lw v0,0(v0) 4005d8: 00000000 nop 4005dc: 8c430000 lw v1,0(v0) 4005e0: 00000000 nop 4005e4: 1460ffef bnez v1,4005a4 <__do_global_dtors_aux+0x54> 4005e8: 24420004 addiu v0,v0,4 4005ec: 24020001 li v0,1 4005f0: 8f81801c lw at,-32740(gp) 4005f4: 00000000 nop 4005f8: 24210080 addiu at,at,128 4005fc: a0220000 sb v0,0(at) 400600: 8fbf001c lw ra,28(sp) 400604: 00000000 nop 400608: 03e00008 jr ra 40060c: 27bd0020 addiu sp,sp,32 00400610 : 400610: 3c1c0fc0 lui gp,0xfc0 400614: 279c7a20 addiu gp,gp,31264 400618: 0399e021 addu gp,gp,t9 40061c: 27bdffe0 addiu sp,sp,-32 400620: afbc0010 sw gp,16(sp) 400624: afbf001c sw ra,28(sp) 400628: afbc0018 sw gp,24(sp) 40062c: 8fbf001c lw ra,28(sp) 400630: 00000000 nop 400634: 03e00008 jr ra 400638: 27bd0020 addiu sp,sp,32 0040063c : 40063c: 3c1c0fc0 lui gp,0xfc0 400640: 279c79f4 addiu gp,gp,31220 400644: 0399e021 addu gp,gp,t9 400648: 27bdffe0 addiu sp,sp,-32 40064c: afbc0010 sw gp,16(sp) 400650: afbf001c sw ra,28(sp) 400654: 8f84801c lw a0,-32740(gp) 400658: 00000000 nop 40065c: 24840038 addiu a0,a0,56 400660: 8f838030 lw v1,-32720(gp) 400664: afbc0018 sw gp,24(sp) 400668: 8c820000 lw v0,0(a0) 40066c: 00000000 nop 400670: 10400007 beqz v0,400690 400674: 00000000 nop 400678: 10600005 beqz v1,400690 40067c: 00000000 nop 400680: 0060c821 move t9,v1 400684: 0320f809 jalr t9 400688: 00000000 nop 40068c: 8fbc0010 lw gp,16(sp) 400690: 8fbf001c lw ra,28(sp) 400694: 00000000 nop 400698: 03e00008 jr ra 40069c: 27bd0020 addiu sp,sp,32 004006a0 : 4006a0: 3c1c0fc0 lui gp,0xfc0 4006a4: 279c7990 addiu gp,gp,31120 4006a8: 0399e021 addu gp,gp,t9 4006ac: 27bdffe0 addiu sp,sp,-32 4006b0: afbc0010 sw gp,16(sp) 4006b4: afbf001c sw ra,28(sp) 4006b8: afbc0018 sw gp,24(sp) 4006bc: 8fbf001c lw ra,28(sp) 4006c0: 00000000 nop 4006c4: 03e00008 jr ra 4006c8: 27bd0020 addiu sp,sp,32 4006cc: 00000000 nop 004006d0
: 4006d0: 3c1c0fc0 lui gp,0xfc0 4006d4: 279c7960 addiu gp,gp,31072 4006d8: 0399e021 addu gp,gp,t9 4006dc: 27bdffe0 addiu sp,sp,-32 4006e0: afbc0000 sw gp,0(sp) 4006e4: afbe001c sw s8,28(sp) 4006e8: afbc0018 sw gp,24(sp) 4006ec: 03a0f021 move s8,sp 4006f0: 24020001 li v0,1 4006f4: afc20008 sw v0,8(s8) 4006f8: 24020002 li v0,2 4006fc: afc2000c sw v0,12(s8) 400700: afc00010 sw zero,16(s8) 400704: 8fc20008 lw v0,8(s8) 400708: 8fc3000c lw v1,12(s8) 40070c: 00000000 nop 400710: 00431021 addu v0,v0,v1 400714: 1000fffb b 400704 400718: afc20010 sw v0,16(s8) 40071c: 00000000 nop 00400720 <__do_global_ctors_aux>: 400720: 3c1c0fc0 lui gp,0xfc0 400724: 279c7910 addiu gp,gp,30992 400728: 0399e021 addu gp,gp,t9 40072c: 27bdffd8 addiu sp,sp,-40 400730: afbc0010 sw gp,16(sp) 400734: afb00018 sw s0,24(sp) 400738: 8f82801c lw v0,-32740(gp) 40073c: 00000000 nop 400740: 2442002c addiu v0,v0,44 400744: 2403ffff li v1,-1 400748: afbf0024 sw ra,36(sp) 40074c: afbc0020 sw gp,32(sp) 400750: afb1001c sw s1,28(sp) 400754: 8c44fffc lw a0,-4(v0) 400758: 00000000 nop 40075c: 1083000f beq a0,v1,40079c <__do_global_ctors_aux+0x7c> 400760: 2450fffc addiu s0,v0,-4 400764: 8f83801c lw v1,-32740(gp) 400768: 00000000 nop 40076c: 2463002c addiu v1,v1,44 400770: 8c63fffc lw v1,-4(v1) 400774: 2411ffff li s1,-1 400778: 2610fffc addiu s0,s0,-4 40077c: 0060c821 move t9,v1 400780: 0320f809 jalr t9 400784: 00000000 nop 400788: 8fbc0010 lw gp,16(sp) 40078c: 8e020000 lw v0,0(s0) 400790: 00000000 nop 400794: 1451fff8 bne v0,s1,400778 <__do_global_ctors_aux+0x58> 400798: 00401821 move v1,v0 40079c: 8fbf0024 lw ra,36(sp) 4007a0: 8fb1001c lw s1,28(sp) 4007a4: 8fb00018 lw s0,24(sp) 4007a8: 03e00008 jr ra 4007ac: 27bd0028 addiu sp,sp,40 004007b0 : 4007b0: 3c1c0fc0 lui gp,0xfc0 4007b4: 279c7880 addiu gp,gp,30848 4007b8: 0399e021 addu gp,gp,t9 4007bc: 27bdffe0 addiu sp,sp,-32 4007c0: afbc0010 sw gp,16(sp) 4007c4: afbf001c sw ra,28(sp) 4007c8: afbc0018 sw gp,24(sp) 4007cc: 8fbf001c lw ra,28(sp) 4007d0: 00000000 nop 4007d4: 03e00008 jr ra 4007d8: 27bd0020 addiu sp,sp,32 4007dc: 00000000 nop Disassembly of section .fini: 004007e0 <_fini>: 4007e0: 3c1c0fc0 lui gp,0xfc0 4007e4: 279c7850 addiu gp,gp,30800 4007e8: 0399e021 addu gp,gp,t9 4007ec: 27bdffe0 addiu sp,sp,-32 4007f0: afbc0010 sw gp,16(sp) 4007f4: afbf001c sw ra,28(sp) 4007f8: afbc0018 sw gp,24(sp) 4007fc: 00000000 nop 400800: 8f998018 lw t9,-32744(gp) 400804: 00000000 nop 400808: 27390550 addiu t9,t9,1360 40080c: 00000000 nop 400810: 0320f809 jalr t9 400814: 00000000 nop 400818: 8fbc0010 lw gp,16(sp) 40081c: 00000000 nop 400820: 8fbf001c lw ra,28(sp) 400824: 00000000 nop 400828: 03e00008 jr ra 40082c: 27bd0020 addiu sp,sp,32 --=-gYSHEU3eEJHsPXWYmfN5 Content-Disposition: attachment; filename=while-noinit-dis Content-Type: text/plain; name=while-noinit-dis; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit while-noinit: file format elf32-tradbigmips Disassembly of section .init: 004003f0 <_init>: 4003f0: 3c1c0fc0 lui gp,0xfc0 4003f4: 279c7c40 addiu gp,gp,31808 4003f8: 0399e021 addu gp,gp,t9 4003fc: 27bdffe0 addiu sp,sp,-32 400400: afbc0010 sw gp,16(sp) 400404: afbf001c sw ra,28(sp) 400408: afbc0018 sw gp,24(sp) 40040c: 8f998018 lw t9,-32744(gp) 400410: 00000000 nop 400414: 27390500 addiu t9,t9,1280 ... 400420: 0320f809 jalr t9 400424: 00000000 nop 400428: 8fbc0010 lw gp,16(sp) 40042c: 00000000 nop 400430: 8f998018 lw t9,-32744(gp) 400434: 00000000 nop 400438: 2739063c addiu t9,t9,1596 40043c: 00000000 nop 400440: 0320f809 jalr t9 400444: 00000000 nop 400448: 8fbc0010 lw gp,16(sp) 40044c: 00000000 nop 400450: 8f998018 lw t9,-32744(gp) 400454: 00000000 nop 400458: 27390720 addiu t9,t9,1824 40045c: 00000000 nop 400460: 0320f809 jalr t9 400464: 00000000 nop 400468: 8fbc0010 lw gp,16(sp) 40046c: 00000000 nop 400470: 8fbf001c lw ra,28(sp) 400474: 00000000 nop 400478: 03e00008 jr ra 40047c: 27bd0020 addiu sp,sp,32 Disassembly of section .text: 00400480 <__start>: 400480: 04100001 bltzal zero,400488 <__start+0x8> 400484: 00000000 nop 400488: 3c1c0fc0 lui gp,0xfc0 40048c: 279c7ba8 addiu gp,gp,31656 400490: 039fe021 addu gp,gp,ra 400494: 0000f821 move ra,zero 400498: 8f84803c lw a0,-32708(gp) 40049c: 8fa50000 lw a1,0(sp) 4004a0: 27a60004 addiu a2,sp,4 4004a4: 3c01ffff lui at,0xffff 4004a8: 3421fff8 ori at,at,0xfff8 4004ac: 03a1e824 and sp,sp,at 4004b0: 27bdffe0 addiu sp,sp,-32 4004b4: 8f878040 lw a3,-32704(gp) 4004b8: 8f888034 lw t0,-32716(gp) 4004bc: 00000000 nop 4004c0: afa80010 sw t0,16(sp) 4004c4: afa20014 sw v0,20(sp) 4004c8: afbd0018 sw sp,24(sp) 4004cc: 8f998038 lw t9,-32712(gp) 4004d0: 00000000 nop 4004d4: 0320f809 jalr t9 4004d8: 00000000 nop 004004dc : 4004dc: 1000ffff b 4004dc 4004e0: 00000000 nop ... 00400500 : 400500: 3c1c0fc0 lui gp,0xfc0 400504: 279c7b30 addiu gp,gp,31536 400508: 0399e021 addu gp,gp,t9 40050c: 27bdffe0 addiu sp,sp,-32 400510: afbc0010 sw gp,16(sp) 400514: afbf001c sw ra,28(sp) 400518: 8f82802c lw v0,-32724(gp) 40051c: 00000000 nop 400520: 10400006 beqz v0,40053c 400524: afbc0018 sw gp,24(sp) 400528: 0040c821 move t9,v0 40052c: 00000000 nop 400530: 0320f809 jalr t9 400534: 00000000 nop 400538: 8fbc0010 lw gp,16(sp) 40053c: 8fbf001c lw ra,28(sp) ... 400548: 03e00008 jr ra 40054c: 27bd0020 addiu sp,sp,32 00400550 <__do_global_dtors_aux>: 400550: 3c1c0fc0 lui gp,0xfc0 400554: 279c7ae0 addiu gp,gp,31456 400558: 0399e021 addu gp,gp,t9 40055c: 27bdffe0 addiu sp,sp,-32 400560: afbc0010 sw gp,16(sp) 400564: 8f82801c lw v0,-32740(gp) 400568: 00000000 nop 40056c: 24420080 addiu v0,v0,128 400570: 90420000 lbu v0,0(v0) 400574: afbf001c sw ra,28(sp) 400578: 14400021 bnez v0,400600 <__do_global_dtors_aux+0xb0> 40057c: afbc0018 sw gp,24(sp) 400580: 8f82801c lw v0,-32740(gp) 400584: 00000000 nop 400588: 24420014 addiu v0,v0,20 40058c: 8c420000 lw v0,0(v0) 400590: 00000000 nop 400594: 8c430000 lw v1,0(v0) 400598: 00000000 nop 40059c: 10600013 beqz v1,4005ec <__do_global_dtors_aux+0x9c> 4005a0: 24420004 addiu v0,v0,4 4005a4: 8f81801c lw at,-32740(gp) 4005a8: 00000000 nop 4005ac: 24210014 addiu at,at,20 4005b0: ac220000 sw v0,0(at) 4005b4: 0060c821 move t9,v1 4005b8: 0320f809 jalr t9 4005bc: 00000000 nop 4005c0: 8fbc0010 lw gp,16(sp) 4005c4: 00000000 nop 4005c8: 8f82801c lw v0,-32740(gp) 4005cc: 00000000 nop 4005d0: 24420014 addiu v0,v0,20 4005d4: 8c420000 lw v0,0(v0) 4005d8: 00000000 nop 4005dc: 8c430000 lw v1,0(v0) 4005e0: 00000000 nop 4005e4: 1460ffef bnez v1,4005a4 <__do_global_dtors_aux+0x54> 4005e8: 24420004 addiu v0,v0,4 4005ec: 24020001 li v0,1 4005f0: 8f81801c lw at,-32740(gp) 4005f4: 00000000 nop 4005f8: 24210080 addiu at,at,128 4005fc: a0220000 sb v0,0(at) 400600: 8fbf001c lw ra,28(sp) 400604: 00000000 nop 400608: 03e00008 jr ra 40060c: 27bd0020 addiu sp,sp,32 00400610 : 400610: 3c1c0fc0 lui gp,0xfc0 400614: 279c7a20 addiu gp,gp,31264 400618: 0399e021 addu gp,gp,t9 40061c: 27bdffe0 addiu sp,sp,-32 400620: afbc0010 sw gp,16(sp) 400624: afbf001c sw ra,28(sp) 400628: afbc0018 sw gp,24(sp) 40062c: 8fbf001c lw ra,28(sp) 400630: 00000000 nop 400634: 03e00008 jr ra 400638: 27bd0020 addiu sp,sp,32 0040063c : 40063c: 3c1c0fc0 lui gp,0xfc0 400640: 279c79f4 addiu gp,gp,31220 400644: 0399e021 addu gp,gp,t9 400648: 27bdffe0 addiu sp,sp,-32 40064c: afbc0010 sw gp,16(sp) 400650: afbf001c sw ra,28(sp) 400654: 8f84801c lw a0,-32740(gp) 400658: 00000000 nop 40065c: 24840038 addiu a0,a0,56 400660: 8f838030 lw v1,-32720(gp) 400664: afbc0018 sw gp,24(sp) 400668: 8c820000 lw v0,0(a0) 40066c: 00000000 nop 400670: 10400007 beqz v0,400690 400674: 00000000 nop 400678: 10600005 beqz v1,400690 40067c: 00000000 nop 400680: 0060c821 move t9,v1 400684: 0320f809 jalr t9 400688: 00000000 nop 40068c: 8fbc0010 lw gp,16(sp) 400690: 8fbf001c lw ra,28(sp) 400694: 00000000 nop 400698: 03e00008 jr ra 40069c: 27bd0020 addiu sp,sp,32 004006a0 : 4006a0: 3c1c0fc0 lui gp,0xfc0 4006a4: 279c7990 addiu gp,gp,31120 4006a8: 0399e021 addu gp,gp,t9 4006ac: 27bdffe0 addiu sp,sp,-32 4006b0: afbc0010 sw gp,16(sp) 4006b4: afbf001c sw ra,28(sp) 4006b8: afbc0018 sw gp,24(sp) 4006bc: 8fbf001c lw ra,28(sp) 4006c0: 00000000 nop 4006c4: 03e00008 jr ra 4006c8: 27bd0020 addiu sp,sp,32 4006cc: 00000000 nop 004006d0
: 4006d0: 3c1c0fc0 lui gp,0xfc0 4006d4: 279c7960 addiu gp,gp,31072 4006d8: 0399e021 addu gp,gp,t9 4006dc: 27bdffe0 addiu sp,sp,-32 4006e0: afbc0000 sw gp,0(sp) 4006e4: afbe001c sw s8,28(sp) 4006e8: afbc0018 sw gp,24(sp) 4006ec: 03a0f021 move s8,sp 4006f0: 24020001 li v0,1 4006f4: afc20008 sw v0,8(s8) 4006f8: 24020002 li v0,2 4006fc: afc2000c sw v0,12(s8) 400700: 8fc20008 lw v0,8(s8) 400704: 8fc3000c lw v1,12(s8) 400708: 00000000 nop 40070c: 00431021 addu v0,v0,v1 400710: 1000fffb b 400700 400714: afc20010 sw v0,16(s8) ... 00400720 <__do_global_ctors_aux>: 400720: 3c1c0fc0 lui gp,0xfc0 400724: 279c7910 addiu gp,gp,30992 400728: 0399e021 addu gp,gp,t9 40072c: 27bdffd8 addiu sp,sp,-40 400730: afbc0010 sw gp,16(sp) 400734: afb00018 sw s0,24(sp) 400738: 8f82801c lw v0,-32740(gp) 40073c: 00000000 nop 400740: 2442002c addiu v0,v0,44 400744: 2403ffff li v1,-1 400748: afbf0024 sw ra,36(sp) 40074c: afbc0020 sw gp,32(sp) 400750: afb1001c sw s1,28(sp) 400754: 8c44fffc lw a0,-4(v0) 400758: 00000000 nop 40075c: 1083000f beq a0,v1,40079c <__do_global_ctors_aux+0x7c> 400760: 2450fffc addiu s0,v0,-4 400764: 8f83801c lw v1,-32740(gp) 400768: 00000000 nop 40076c: 2463002c addiu v1,v1,44 400770: 8c63fffc lw v1,-4(v1) 400774: 2411ffff li s1,-1 400778: 2610fffc addiu s0,s0,-4 40077c: 0060c821 move t9,v1 400780: 0320f809 jalr t9 400784: 00000000 nop 400788: 8fbc0010 lw gp,16(sp) 40078c: 8e020000 lw v0,0(s0) 400790: 00000000 nop 400794: 1451fff8 bne v0,s1,400778 <__do_global_ctors_aux+0x58> 400798: 00401821 move v1,v0 40079c: 8fbf0024 lw ra,36(sp) 4007a0: 8fb1001c lw s1,28(sp) 4007a4: 8fb00018 lw s0,24(sp) 4007a8: 03e00008 jr ra 4007ac: 27bd0028 addiu sp,sp,40 004007b0 : 4007b0: 3c1c0fc0 lui gp,0xfc0 4007b4: 279c7880 addiu gp,gp,30848 4007b8: 0399e021 addu gp,gp,t9 4007bc: 27bdffe0 addiu sp,sp,-32 4007c0: afbc0010 sw gp,16(sp) 4007c4: afbf001c sw ra,28(sp) 4007c8: afbc0018 sw gp,24(sp) 4007cc: 8fbf001c lw ra,28(sp) 4007d0: 00000000 nop 4007d4: 03e00008 jr ra 4007d8: 27bd0020 addiu sp,sp,32 4007dc: 00000000 nop Disassembly of section .fini: 004007e0 <_fini>: 4007e0: 3c1c0fc0 lui gp,0xfc0 4007e4: 279c7850 addiu gp,gp,30800 4007e8: 0399e021 addu gp,gp,t9 4007ec: 27bdffe0 addiu sp,sp,-32 4007f0: afbc0010 sw gp,16(sp) 4007f4: afbf001c sw ra,28(sp) 4007f8: afbc0018 sw gp,24(sp) 4007fc: 00000000 nop 400800: 8f998018 lw t9,-32744(gp) 400804: 00000000 nop 400808: 27390550 addiu t9,t9,1360 40080c: 00000000 nop 400810: 0320f809 jalr t9 400814: 00000000 nop 400818: 8fbc0010 lw gp,16(sp) 40081c: 00000000 nop 400820: 8fbf001c lw ra,28(sp) 400824: 00000000 nop 400828: 03e00008 jr ra 40082c: 27bd0020 addiu sp,sp,32 --=-gYSHEU3eEJHsPXWYmfN5 Content-Disposition: attachment; filename=while-nop-dis Content-Type: text/plain; name=while-nop-dis; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit while-nop: file format elf32-tradbigmips Disassembly of section .init: 004003f0 <_init>: 4003f0: 3c1c0fc0 lui gp,0xfc0 4003f4: 279c7c40 addiu gp,gp,31808 4003f8: 0399e021 addu gp,gp,t9 4003fc: 27bdffe0 addiu sp,sp,-32 400400: afbc0010 sw gp,16(sp) 400404: afbf001c sw ra,28(sp) 400408: afbc0018 sw gp,24(sp) 40040c: 8f998018 lw t9,-32744(gp) 400410: 00000000 nop 400414: 27390500 addiu t9,t9,1280 ... 400420: 0320f809 jalr t9 400424: 00000000 nop 400428: 8fbc0010 lw gp,16(sp) 40042c: 00000000 nop 400430: 8f998018 lw t9,-32744(gp) 400434: 00000000 nop 400438: 2739063c addiu t9,t9,1596 40043c: 00000000 nop 400440: 0320f809 jalr t9 400444: 00000000 nop 400448: 8fbc0010 lw gp,16(sp) 40044c: 00000000 nop 400450: 8f998018 lw t9,-32744(gp) 400454: 00000000 nop 400458: 27390720 addiu t9,t9,1824 40045c: 00000000 nop 400460: 0320f809 jalr t9 400464: 00000000 nop 400468: 8fbc0010 lw gp,16(sp) 40046c: 00000000 nop 400470: 8fbf001c lw ra,28(sp) 400474: 00000000 nop 400478: 03e00008 jr ra 40047c: 27bd0020 addiu sp,sp,32 Disassembly of section .text: 00400480 <__start>: 400480: 04100001 bltzal zero,400488 <__start+0x8> 400484: 00000000 nop 400488: 3c1c0fc0 lui gp,0xfc0 40048c: 279c7ba8 addiu gp,gp,31656 400490: 039fe021 addu gp,gp,ra 400494: 0000f821 move ra,zero 400498: 8f84803c lw a0,-32708(gp) 40049c: 8fa50000 lw a1,0(sp) 4004a0: 27a60004 addiu a2,sp,4 4004a4: 3c01ffff lui at,0xffff 4004a8: 3421fff8 ori at,at,0xfff8 4004ac: 03a1e824 and sp,sp,at 4004b0: 27bdffe0 addiu sp,sp,-32 4004b4: 8f878040 lw a3,-32704(gp) 4004b8: 8f888034 lw t0,-32716(gp) 4004bc: 00000000 nop 4004c0: afa80010 sw t0,16(sp) 4004c4: afa20014 sw v0,20(sp) 4004c8: afbd0018 sw sp,24(sp) 4004cc: 8f998038 lw t9,-32712(gp) 4004d0: 00000000 nop 4004d4: 0320f809 jalr t9 4004d8: 00000000 nop 004004dc : 4004dc: 1000ffff b 4004dc 4004e0: 00000000 nop ... 00400500 : 400500: 3c1c0fc0 lui gp,0xfc0 400504: 279c7b30 addiu gp,gp,31536 400508: 0399e021 addu gp,gp,t9 40050c: 27bdffe0 addiu sp,sp,-32 400510: afbc0010 sw gp,16(sp) 400514: afbf001c sw ra,28(sp) 400518: 8f82802c lw v0,-32724(gp) 40051c: 00000000 nop 400520: 10400006 beqz v0,40053c 400524: afbc0018 sw gp,24(sp) 400528: 0040c821 move t9,v0 40052c: 00000000 nop 400530: 0320f809 jalr t9 400534: 00000000 nop 400538: 8fbc0010 lw gp,16(sp) 40053c: 8fbf001c lw ra,28(sp) ... 400548: 03e00008 jr ra 40054c: 27bd0020 addiu sp,sp,32 00400550 <__do_global_dtors_aux>: 400550: 3c1c0fc0 lui gp,0xfc0 400554: 279c7ae0 addiu gp,gp,31456 400558: 0399e021 addu gp,gp,t9 40055c: 27bdffe0 addiu sp,sp,-32 400560: afbc0010 sw gp,16(sp) 400564: 8f82801c lw v0,-32740(gp) 400568: 00000000 nop 40056c: 24420080 addiu v0,v0,128 400570: 90420000 lbu v0,0(v0) 400574: afbf001c sw ra,28(sp) 400578: 14400021 bnez v0,400600 <__do_global_dtors_aux+0xb0> 40057c: afbc0018 sw gp,24(sp) 400580: 8f82801c lw v0,-32740(gp) 400584: 00000000 nop 400588: 24420014 addiu v0,v0,20 40058c: 8c420000 lw v0,0(v0) 400590: 00000000 nop 400594: 8c430000 lw v1,0(v0) 400598: 00000000 nop 40059c: 10600013 beqz v1,4005ec <__do_global_dtors_aux+0x9c> 4005a0: 24420004 addiu v0,v0,4 4005a4: 8f81801c lw at,-32740(gp) 4005a8: 00000000 nop 4005ac: 24210014 addiu at,at,20 4005b0: ac220000 sw v0,0(at) 4005b4: 0060c821 move t9,v1 4005b8: 0320f809 jalr t9 4005bc: 00000000 nop 4005c0: 8fbc0010 lw gp,16(sp) 4005c4: 00000000 nop 4005c8: 8f82801c lw v0,-32740(gp) 4005cc: 00000000 nop 4005d0: 24420014 addiu v0,v0,20 4005d4: 8c420000 lw v0,0(v0) 4005d8: 00000000 nop 4005dc: 8c430000 lw v1,0(v0) 4005e0: 00000000 nop 4005e4: 1460ffef bnez v1,4005a4 <__do_global_dtors_aux+0x54> 4005e8: 24420004 addiu v0,v0,4 4005ec: 24020001 li v0,1 4005f0: 8f81801c lw at,-32740(gp) 4005f4: 00000000 nop 4005f8: 24210080 addiu at,at,128 4005fc: a0220000 sb v0,0(at) 400600: 8fbf001c lw ra,28(sp) 400604: 00000000 nop 400608: 03e00008 jr ra 40060c: 27bd0020 addiu sp,sp,32 00400610 : 400610: 3c1c0fc0 lui gp,0xfc0 400614: 279c7a20 addiu gp,gp,31264 400618: 0399e021 addu gp,gp,t9 40061c: 27bdffe0 addiu sp,sp,-32 400620: afbc0010 sw gp,16(sp) 400624: afbf001c sw ra,28(sp) 400628: afbc0018 sw gp,24(sp) 40062c: 8fbf001c lw ra,28(sp) 400630: 00000000 nop 400634: 03e00008 jr ra 400638: 27bd0020 addiu sp,sp,32 0040063c : 40063c: 3c1c0fc0 lui gp,0xfc0 400640: 279c79f4 addiu gp,gp,31220 400644: 0399e021 addu gp,gp,t9 400648: 27bdffe0 addiu sp,sp,-32 40064c: afbc0010 sw gp,16(sp) 400650: afbf001c sw ra,28(sp) 400654: 8f84801c lw a0,-32740(gp) 400658: 00000000 nop 40065c: 24840038 addiu a0,a0,56 400660: 8f838030 lw v1,-32720(gp) 400664: afbc0018 sw gp,24(sp) 400668: 8c820000 lw v0,0(a0) 40066c: 00000000 nop 400670: 10400007 beqz v0,400690 400674: 00000000 nop 400678: 10600005 beqz v1,400690 40067c: 00000000 nop 400680: 0060c821 move t9,v1 400684: 0320f809 jalr t9 400688: 00000000 nop 40068c: 8fbc0010 lw gp,16(sp) 400690: 8fbf001c lw ra,28(sp) 400694: 00000000 nop 400698: 03e00008 jr ra 40069c: 27bd0020 addiu sp,sp,32 004006a0 : 4006a0: 3c1c0fc0 lui gp,0xfc0 4006a4: 279c7990 addiu gp,gp,31120 4006a8: 0399e021 addu gp,gp,t9 4006ac: 27bdffe0 addiu sp,sp,-32 4006b0: afbc0010 sw gp,16(sp) 4006b4: afbf001c sw ra,28(sp) 4006b8: afbc0018 sw gp,24(sp) 4006bc: 8fbf001c lw ra,28(sp) 4006c0: 00000000 nop 4006c4: 03e00008 jr ra 4006c8: 27bd0020 addiu sp,sp,32 4006cc: 00000000 nop 004006d0
: 4006d0: 3c1c0fc0 lui gp,0xfc0 4006d4: 279c7960 addiu gp,gp,31072 4006d8: 0399e021 addu gp,gp,t9 4006dc: 27bdffe0 addiu sp,sp,-32 4006e0: afbc0000 sw gp,0(sp) 4006e4: afbe001c sw s8,28(sp) 4006e8: afbc0018 sw gp,24(sp) 4006ec: 03a0f021 move s8,sp 4006f0: 24020001 li v0,1 4006f4: afc20008 sw v0,8(s8) 4006f8: 24020002 li v0,2 4006fc: afc2000c sw v0,12(s8) 400700: 00000000 nop 400704: 8fc20008 lw v0,8(s8) 400708: 8fc3000c lw v1,12(s8) 40070c: 00000000 nop 400710: 00431021 addu v0,v0,v1 400714: 1000fffb b 400704 400718: afc20010 sw v0,16(s8) 40071c: 00000000 nop 00400720 <__do_global_ctors_aux>: 400720: 3c1c0fc0 lui gp,0xfc0 400724: 279c7910 addiu gp,gp,30992 400728: 0399e021 addu gp,gp,t9 40072c: 27bdffd8 addiu sp,sp,-40 400730: afbc0010 sw gp,16(sp) 400734: afb00018 sw s0,24(sp) 400738: 8f82801c lw v0,-32740(gp) 40073c: 00000000 nop 400740: 2442002c addiu v0,v0,44 400744: 2403ffff li v1,-1 400748: afbf0024 sw ra,36(sp) 40074c: afbc0020 sw gp,32(sp) 400750: afb1001c sw s1,28(sp) 400754: 8c44fffc lw a0,-4(v0) 400758: 00000000 nop 40075c: 1083000f beq a0,v1,40079c <__do_global_ctors_aux+0x7c> 400760: 2450fffc addiu s0,v0,-4 400764: 8f83801c lw v1,-32740(gp) 400768: 00000000 nop 40076c: 2463002c addiu v1,v1,44 400770: 8c63fffc lw v1,-4(v1) 400774: 2411ffff li s1,-1 400778: 2610fffc addiu s0,s0,-4 40077c: 0060c821 move t9,v1 400780: 0320f809 jalr t9 400784: 00000000 nop 400788: 8fbc0010 lw gp,16(sp) 40078c: 8e020000 lw v0,0(s0) 400790: 00000000 nop 400794: 1451fff8 bne v0,s1,400778 <__do_global_ctors_aux+0x58> 400798: 00401821 move v1,v0 40079c: 8fbf0024 lw ra,36(sp) 4007a0: 8fb1001c lw s1,28(sp) 4007a4: 8fb00018 lw s0,24(sp) 4007a8: 03e00008 jr ra 4007ac: 27bd0028 addiu sp,sp,40 004007b0 : 4007b0: 3c1c0fc0 lui gp,0xfc0 4007b4: 279c7880 addiu gp,gp,30848 4007b8: 0399e021 addu gp,gp,t9 4007bc: 27bdffe0 addiu sp,sp,-32 4007c0: afbc0010 sw gp,16(sp) 4007c4: afbf001c sw ra,28(sp) 4007c8: afbc0018 sw gp,24(sp) 4007cc: 8fbf001c lw ra,28(sp) 4007d0: 00000000 nop 4007d4: 03e00008 jr ra 4007d8: 27bd0020 addiu sp,sp,32 4007dc: 00000000 nop Disassembly of section .fini: 004007e0 <_fini>: 4007e0: 3c1c0fc0 lui gp,0xfc0 4007e4: 279c7850 addiu gp,gp,30800 4007e8: 0399e021 addu gp,gp,t9 4007ec: 27bdffe0 addiu sp,sp,-32 4007f0: afbc0010 sw gp,16(sp) 4007f4: afbf001c sw ra,28(sp) 4007f8: afbc0018 sw gp,24(sp) 4007fc: 00000000 nop 400800: 8f998018 lw t9,-32744(gp) 400804: 00000000 nop 400808: 27390550 addiu t9,t9,1360 40080c: 00000000 nop 400810: 0320f809 jalr t9 400814: 00000000 nop 400818: 8fbc0010 lw gp,16(sp) 40081c: 00000000 nop 400820: 8fbf001c lw ra,28(sp) 400824: 00000000 nop 400828: 03e00008 jr ra 40082c: 27bd0020 addiu sp,sp,32 --=-gYSHEU3eEJHsPXWYmfN5-- From Adam_Kiepul@pmc-sierra.com Fri May 28 21:21:42 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 21:21:47 +0100 (BST) Received: from mother.pmc-sierra.com ([IPv6:::ffff:216.241.224.12]:3581 "HELO mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP id ; Fri, 28 May 2004 21:21:33 +0100 Received: (qmail 26863 invoked from network); 28 May 2004 20:20:31 -0000 Received: from unknown (HELO ogmios.pmc-sierra.bc.ca) (216.241.226.59) by mother.pmc-sierra.com with SMTP; 28 May 2004 20:20:31 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by ogmios.pmc-sierra.bc.ca (8.12.9/8.12.7) with ESMTP id i4SKKTOM030716; Fri, 28 May 2004 13:20:30 -0700 Received: by bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca with Internet Mail Service (5.5.2656.59) id ; Fri, 28 May 2004 13:20:29 -0700 Message-ID: <9DFF23E1E33391449FDC324526D1F2590283C58B@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> From: Adam Kiepul To: "'hadi@cyberus.ca'" , linux-mips@linux-mips.org Cc: sibyte-users@bitmover.com Subject: RE: weird sb1250 behavior Date: Fri, 28 May 2004 13:11:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Adam_Kiepul@pmc-sierra.com Precedence: bulk X-list: linux-mips Jamal, There is a possible cache line read-after-write pseudo-dependency that, along with the code alignment in terms of the instruction pair doublewords, may do something weird to the sb1250 pipeline. Just my guess. Have a great weekend, Adam -----Original Message----- From: jamal [mailto:hadi@cyberus.ca] Sent: Friday, May 28, 2004 12:37 PM To: linux-mips@linux-mips.org Cc: sibyte-users@bitmover.com Subject: weird sb1250 behavior found some very strange behavior with sb1250. Gcc 3.2.3 with sibyte mods. Running Linux 2.4.21 with whatever mods off sibyte. Testcase: sending a large amount of traffic -->eth0-->someprocessing-->eth1 given the nature of processing, say i was getting 100Kpps throughput. Now i fire a very basic program that has just loops and forever sums up two numbers. --- 1 #include 2 3 int main () 4 { 5 int a = 1; 6 int b = 2; 7 int c = 0; 8 // int c; 9 while (1) { 10 c = a + b; 11 } 12 } -------- I see very little drop in throughput - probably around 0.01%. Now comment line 7 then uncomment line 8. Hallelujah. Perfomance drops to about 100pps. Thats about a factor of 1000 down! Interesting thing is if you add a nop (__asm__ __volatile__("nop");) in the second version just before the while loop, we get back the same performance as in the earlier version. Apologies in advance for attaching objdumps (since there maybe folks who dont have access to the sibyte tools) 1) while-init-dis is for case 1 where c is initialized 2) while-noinit-dis is for case 2 where c is not initialize 3) while-nop-dis is for case 3 when you have nop thrown in. cheers, jamal From ralf@linux-mips.org Fri May 28 22:00:31 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 22:02:16 +0100 (BST) Received: from p508B5C08.dip.t-dialin.net ([IPv6:::ffff:80.139.92.8]:34663 "EHLO mail.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 22:00:22 +0100 Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1]) by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i4SKxPwS015582; Fri, 28 May 2004 22:59:25 +0200 Received: (from ralf@localhost) by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i4SKxNql015581; Fri, 28 May 2004 22:59:23 +0200 Date: Fri, 28 May 2004 22:59:23 +0200 From: Ralf Baechle To: Adam Kiepul Cc: "'hadi@cyberus.ca'" , linux-mips@linux-mips.org, sibyte-users@bitmover.com Subject: Re: [SiByte] RE: weird sb1250 behavior Message-ID: <20040528205923.GA14682@linux-mips.org> References: <9DFF23E1E33391449FDC324526D1F2590283C58B@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DFF23E1E33391449FDC324526D1F2590283C58B@sjc1exm02.pmc_nt.nt.pmc-sierra.bc.ca> User-Agent: Mutt/1.4.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: 5220 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, May 28, 2004 at 01:11:38PM -0700, Adam Kiepul wrote: > There is a possible cache line read-after-write pseudo-dependency that, along with the code alignment in terms of the instruction pair doublewords, may do something weird to the sb1250 pipeline. Just my guess. memcpy's source deals with what probably is another instance of the same effect: #ifdef CONFIG_CPU_SB1 nop # improves slotting #endif Ralf From kumba@gentoo.org Fri May 28 22:12:34 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 28 May 2004 22:12:39 +0100 (BST) Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:46591 "EHLO sccrmhc11.comcast.net") by linux-mips.org with ESMTP id ; Fri, 28 May 2004 22:12:25 +0100 Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58]) by comcast.net (sccrmhc11) with ESMTP id <20040528211218011009i101e> (Authid: kumba12345); Fri, 28 May 2004 21:12:19 +0000 Message-ID: <40B7ABCE.3070809@gentoo.org> Date: Fri, 28 May 2004 17:14:54 -0400 From: Kumba Reply-To: kumba@gentoo.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: help needed : cannot install linux on SGI O2 R5000 References: <200405281210.05259.maksik@gmx.co.uk> In-Reply-To: <200405281210.05259.maksik@gmx.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5221 X-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 Max Zaitsev wrote: > this I've tried already, but the thing is that the netboot kernel does not go > beyond telling me what the entry point was. I've also tried to use the kernel > from Ilya with the same root. There, everything would hang after starting the > initrd script. Since you're on the framebuffer, likely the kernel was attaching to the serial console to display it's messages, thus why you didn't see any messages after the entry point. > actually, I don't. I don't have a serial console/cable in my possetion and was > intending to actually use the display/keyboard combination to perform the > installation. Would it be possible? Can you advise me where to get a suitable > netboot kernel? The framebuffer is still a bit flakey last I heard. The netboot I have supports the netboot, but I have no idea how well it works. Likely, it'll be several revisions of the kernel before the framebuffer becomes stable. The O2 itself uses a standard DB9M connector, so it should be rather easy to obtain a cable and null-modem adapter to do serial console with for the machine. Far easier than hunting down the obscure serial connectors for IP22 machines. Serial, for now, my reccomended form of installing -- it'll be a lot less painless, IMHO. Lastly, the netboot I have is geared for a gentoo install, if that's what you'll be installing, you'll want to aim any gentoo-specific questions to the gentoo-mips ML. If it's a debian install, then you might be in for a fun ride or such, but I believe they are working on an O2 netboot of their own w/ the d-i setup and such. --Kumba -- "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 king_903@yahoo.com Sat May 29 02:41:55 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 May 2004 02:42:00 +0100 (BST) Received: from web13601.mail.yahoo.com ([IPv6:::ffff:216.136.175.112]:59550 "HELO web13601.mail.yahoo.com") by linux-mips.org with SMTP id ; Sat, 29 May 2004 02:41:46 +0100 Message-ID: <20040529014144.37378.qmail@web13601.mail.yahoo.com> Received: from [63.150.34.78] by web13601.mail.yahoo.com via HTTP; Fri, 28 May 2004 18:41:44 PDT Date: Fri, 28 May 2004 18:41:44 -0700 (PDT) From: SCR Subject: mips-4kc pci issue To: linux-mips@linux-mips.org Cc: king_903@yahoo.com 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: 5222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: king_903@yahoo.com Precedence: bulk X-list: linux-mips Hello, I am new to the list, I am having problem with PCI buscard. first the kernel I am using 2.4.18, and CPU is ADMTECK 5120 4KC core. When there is no card installed I can read and write pci host bridge registers, but when I install the card all the registers gets corropted on the host side and target gets unreliable registers value. This pci bus does not have a IDSEL signal going to the target. Also I read different value from the bus if I pluging different card. Cards have a TI and Atheros chipset. First Reg value without any card: 00-51201317 04-04000007 08-06000000 0c-00008000 10-f0000000 14-ff000001 18-00000000 1c-00000000 20-00000000 24-00000000 28-00000000 2c-00000000 30-00000000 34-00000000 38-00000000 3c-00000000 Found 00:00 [1317/5120] 000600 00 / # more /proc/pci PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 1317:5120 (rev 0). Master Capable. Latency=128. Non-prefetchable 32 bit memory at 0xf0000000 [0xffffffff]. I/O at 0xff000000 [0xfeffffff]. Sencond Conf. Reg when WG511T pluged in. Scanning bus 00, I/O 0x11500000:0x115ffff0, Mem 0x11400000:0x11500000 00:00.0 Class 0013: 1317:0000 (rev 8c) Mem at 0x11400000 [size=0xf7f0] Mem at 0x1140f7f0 [size=0xf7f0] Mem at 0x11420000 [size=0xf7f0] Mem at 0x1142f800 [size=0xf7e0] 00:02.0 Class 0200: 2000:0013 (rev 01) Mem at 0x11440000 [size=0x10000] Scanning bus 00 00-00000044 04-00000804 08-02900000 0c-0000080c 10-00000810 14-00000814 18-00000000 1c-0000081c 20-00000000 24-00000824 28-00000000 2c-0000082c 30-4b001385 34-00000834 38-00000044 3c-0000083c Found 00:00 [0800/0000] 000013 0a PCI: device 00:00.0 has unknown header type 0a, ignoring. 00-0013168c 04-02900000 08-02000001 0c-00000810 10-00000000 14-00000000 18-00000000 1c-00000000 20-00000000 24-00000000 28-00005001 2c-4b001385 30-00000000 34-00000044 38-00000000 3c-1c0a0100 Found 00:10 [168c/0013] 000200 00 / # more /proc/pci PCI devices found: Bus 0, device 2, function 0: Class 0200: PCI device 168c:0013 (rev 1). IRQ 6. Master Capable. Latency=168. Min Gnt=10.Max Lat=28. Non-prefetchable 32 bit memory at 0x0 [0xffff]. Now with TI chipset: Autoconfig PCI channel 0x801c360c Scanning bus 00, I/O 0x11500000:0x115ffff0, Mem 0x11400000:0x11500000 00:00.0 Class 0600: 1317:5120 Mem unavailable -- skipping I/O unavailable -- skipping 00:02.0 Class 0280: 104c:9066 Mem at 0x11400000 [size=0x2000] Mem at 0x11420000 [size=0x20000] 00-51201317 04-04000007 08-06000000 0c-00008000 10-f0000000 14-ff000001 18-00000000 1c-00000000 20-00000000 24-00000000 28-00000000 2c-00000000 30-00000000 34-00000000 38-00000000 3c-00000000 Found 00:00 [1317/5120] 000600 00 00-9066104c 04-02100007 08-02800000 0c-00008004 10-00000000 14-00000000 18-00000000 1c-00000000 20-00000000 24-00000000 28-00001c02 2c-12001259 30-00000000 34-00000040 38-00000000 3c-00000100 Found 00:10 [104c/9066] 000280 00 / # more /proc/pci PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 1317:5120 (rev 0). Master Capable. Latency=128. Non-prefetchable 32 bit memory at 0xf0000000 [0xffffffff]. I/O at 0xff000000 [0xfeffffff]. Bus 0, device 2, function 0: Class 0280: PCI device 104c:9066 (rev 0). IRQ 6. Master Capable. Latency=128. Non-prefetchable 32 bit memory at 0x0 [0x1fff]. Non-prefetchable 32 bit memory at 0x0 [0x1ffff]. My question Why I am getting this behaviour, I tried to read and write from the registers with card pluged in but not much luck either, I would appretiate your help. Please let me know what I could be missing. Thanks, _Shahrom __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From anemo@mba.ocn.ne.jp Sat May 29 14:42:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 29 May 2004 14:42:14 +0100 (BST) Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:54736 "HELO smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP id ; Sat, 29 May 2004 14:42:00 +0100 Received: from localhost (p6123-ipad203funabasi.chiba.ocn.ne.jp [222.146.85.123]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 4B1BD660E; Sat, 29 May 2004 22:41:57 +0900 (JST) Date: Sat, 29 May 2004 22:45:10 +0900 (JST) Message-Id: <20040529.224510.59461416.anemo@mba.ocn.ne.jp> To: jsun@mvista.com Cc: linux-mips@linux-mips.org Subject: Re: 2.4 preempt kernel patch From: Atsushi Nemoto In-Reply-To: <20040528105151.G20139@mvista.com> References: <20040528.131236.112629910.nemoto@toshiba-tops.co.jp> <20040528105151.G20139@mvista.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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: 5223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips >>>>> On Fri, 28 May 2004 10:51:51 -0700, Jun Sun said: >> Q1. What is purpose of this block? (To decrease latency? But >> other archs (and 2.6 MIPS kernel) do not have block like this...) jsun> This is to check possible preemption at the end of (possibly jsun> nested) interrupt handling. jsun> All other arches and 2.6 MIPS are doing the same thing in .S jsun> file (something like ret_from_irq path) Oh, I found it in 2.6 MIPS kernel. Thank you very much. >> Q2. If an interrupt happened between __sti() and __cli(), and the >> interrupt handler raise softirq, the softirq handler will not be >> called soon (because do_softirq() immediately return if preempt >> disabled). So we must check softirq_pending again after this >> block? jsun> do_softirq() does not (and should not) return when preemtpion is jsun> disabled. We should be fine here. Sorry, it was my mistake. I was misreading the in_interrupt() code... (&& and ||). Thank you. --- Atsushi Nemoto From yuasa@hh.iij4u.or.jp Sun May 30 18:06:09 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 30 May 2004 18:06:13 +0100 (BST) Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:63176 "EHLO mo02.iij4u.or.jp") by linux-mips.org with ESMTP id ; Sun, 30 May 2004 18:06:00 +0100 Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171]) by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id CAA03106; Mon, 31 May 2004 02:05:55 +0900 (JST) Received: 4UMDO01 id i4UH5sR01446; Mon, 31 May 2004 02:05:55 +0900 (JST) Received: 4UMRO00 id i4UH5qO24414; Mon, 31 May 2004 02:05:53 +0900 (JST) from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated) Date: Mon, 31 May 2004 02:05:51 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yuasa@hh.iij4u.or.jp, linux-mips Subject: [PATCH] fix 2 warning of MIPS PCI codes Message-Id: <20040531020551.413ca901.yuasa@hh.iij4u.or.jp> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf, The 2 warning of PCI was fixed by this patch. drivers/pci/setup-res.c: In function `pci_update_resource': drivers/pci/setup-res.c:43: warning: implicit declaration of function `pcibios_resource_to_bus' arch/mips/pci/pci.c: In function `pcibios_fixup_device_resources': arch/mips/pci/pci.c:234: warning: `offset' might be used uninitialized in this function Please apply to v2.6 CVS tree. Yoichi diff -urN -X dontdiff linux-orig/arch/mips/pci/pci.c linux/arch/mips/pci/pci.c --- linux-orig/arch/mips/pci/pci.c Tue Jan 20 02:48:06 2004 +++ linux/arch/mips/pci/pci.c Sun May 30 07:03:03 2004 @@ -231,7 +231,7 @@ { /* Update device resources. */ struct pci_controller *hose = (struct pci_controller *)bus->sysdata; - unsigned long offset; + unsigned long offset = 0; int i; for (i = 0; i < PCI_NUM_RESOURCES; i++) { diff -urN -X dontdiff linux-orig/include/asm-mips/pci.h linux/include/asm-mips/pci.h --- linux-orig/include/asm-mips/pci.h Tue Apr 13 08:19:05 2004 +++ linux/include/asm-mips/pci.h Sun May 30 11:56:01 2004 @@ -87,6 +87,9 @@ extern void pci_dac_dma_sync_single_for_device(struct pci_dev *pdev, dma64_addr_t dma_addr, size_t len, int direction); +extern void pcibios_resource_to_bus(struct pci_dev *dev, + struct pci_bus_region *region, struct resource *res); + #endif /* __KERNEL__ */ /* implement the pci_ DMA API in terms of the generic device dma_ one */ From macro@ds2.pg.gda.pl Mon May 31 15:46:38 2004 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 31 May 2004 15:46:44 +0100 (BST) Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:48259 "EHLO jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 31 May 2004 15:46:38 +0100 Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011) id 7E5A04ADBD; Mon, 31 May 2004 16:46:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jurand.ds.pg.gda.pl (Postfix) with ESMTP id 6D5834AC7D; Mon, 31 May 2004 16:46:31 +0200 (CEST) Date: Mon, 31 May 2004 16:46:31 +0200 (CEST) From: "Maciej W. Rozycki" To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [patch] 2.4,2.6: Small inline assembly fixes Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 5225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Ralf, These are fixes for a bunch of inline assembly problems. The ARC_CALL5 change is important -- others are just clean-ups. As an extra, a duplicate __NR_O32_Linux_syscalls definition is removed. OK to apply? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.24-pre2-20040116-mips-asm-0 diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/sgiarcs.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/sgiarcs.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/sgiarcs.h 2003-05-29 02:57:12.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/sgiarcs.h 2004-05-30 14:34:33.000000000 +0000 @@ -462,7 +462,7 @@ struct linux_smonblock { long __vec = (long) romvec->dest; \ __asm__ __volatile__( \ "dsubu\t$29, 32\n\t" \ - "sw\t%6, 16($29)\n\t" \ + "sw\t%7, 16($29)\n\t" \ "jalr\t%1\n\t" \ "daddu\t$29, 32\n\t" \ "move\t%0, $2" \ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/unistd.h linux-mips-2.4.24-pre2-20040116/include/asm-mips/unistd.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips/unistd.h 2003-11-01 03:57:23.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips/unistd.h 2004-05-30 14:39:41.000000000 +0000 @@ -951,9 +951,9 @@ type name (atype a,btype b,ctype c,dtype "syscall\n\t" \ "move\t%0, $2\n\t" \ ".set\treorder" \ - : "=&r" (__v0), "+r" (__a3), "+r" (__a4) \ - : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_##name) \ - : "$2","$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ + : "=&r" (__v0), "+r" (__a3) \ + : "r" (__a0), "r" (__a1), "r" (__a2), "r" (__a4), "i" (__NR_##name) \ + : "$2", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ \ if (__a3 == 0) \ return (type) __v0; \ @@ -981,7 +981,7 @@ type name (atype a,btype b,ctype c,dtype : "=&r" (__v0), "+r" (__a3) \ : "r" (__a0), "r" (__a1), "r" (__a2), "r" (__a4), "r" (__a5), \ "i" (__NR_##name) \ - : "$2","$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ + : "$2", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ \ if (__a3 == 0) \ return (type) __v0; \ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/sgiarcs.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/sgiarcs.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/sgiarcs.h 2004-01-07 23:02:08.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/sgiarcs.h 2004-05-30 14:34:33.000000000 +0000 @@ -462,7 +462,7 @@ struct linux_smonblock { long __vec = (long) romvec->dest; \ __asm__ __volatile__( \ "dsubu\t$29, 32\n\t" \ - "sw\t%6, 16($29)\n\t" \ + "sw\t%7, 16($29)\n\t" \ "jalr\t%1\n\t" \ "daddu\t$29, 32\n\t" \ "move\t%0, $2" \ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/uaccess.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/uaccess.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/uaccess.h 2003-09-15 02:57:28.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/uaccess.h 2004-05-30 14:46:22.000000000 +0000 @@ -406,7 +406,6 @@ extern size_t __copy_user(void *__to, co "daddu\t$1, %1, %2\n\t" \ ".set\tat\n\t" \ ".set\treorder\n\t" \ - "move\t%0, $6" \ : "+r" (__cu_to_r), "+r" (__cu_from_r), "+r" (__cu_len_r) \ : \ : "$8", "$9", "$10", "$11", "$12", "$15", "$24", "$31", \ diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/unistd.h linux-mips-2.4.24-pre2-20040116/include/asm-mips64/unistd.h --- linux-mips-2.4.24-pre2-20040116.macro/include/asm-mips64/unistd.h 2003-10-29 03:57:28.000000000 +0000 +++ linux-mips-2.4.24-pre2-20040116/include/asm-mips64/unistd.h 2004-05-30 14:39:41.000000000 +0000 @@ -268,8 +268,6 @@ #define __NR_O32_Linux 4000 #define __NR_O32_Linux_syscalls 240 -#define __NR_O32_Linux_syscalls 240 - #if _MIPS_SIM == _MIPS_SIM_ABI64 /* @@ -953,9 +951,9 @@ type name (atype a,btype b,ctype c,dtype "syscall\n\t" \ "move\t%0, $2\n\t" \ ".set\treorder" \ - : "=&r" (__v0), "+r" (__a3), "+r" (__a4) \ - : "r" (__a0), "r" (__a1), "r" (__a2), "i" (__NR_##name) \ - : "$2","$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ + : "=&r" (__v0), "+r" (__a3) \ + : "r" (__a0), "r" (__a1), "r" (__a2), "r" (__a4), "i" (__NR_##name) \ + : "$2", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ \ if (__a3 == 0) \ return (type) __v0; \ @@ -983,7 +981,7 @@ type name (atype a,btype b,ctype c,dtype : "=&r" (__v0), "+r" (__a3) \ : "r" (__a0), "r" (__a1), "r" (__a2), "r" (__a4), "r" (__a5), \ "i" (__NR_##name) \ - : "$2","$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ + : "$2", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24"); \ \ if (__a3 == 0) \ return (type) __v0; \