From alex@alexlab.net Thu Nov 1 01:46:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 01:46:22 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.235]:509 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S28576769AbXKABqN (ORCPT ); Thu, 1 Nov 2007 01:46:13 +0000 Received: by nz-out-0506.google.com with SMTP id n1so251627nzf for ; Wed, 31 Oct 2007 18:46:02 -0700 (PDT) Received: by 10.65.240.17 with SMTP id s17mr2544359qbr.1193881561244; Wed, 31 Oct 2007 18:46:01 -0700 (PDT) Received: by 10.65.123.7 with HTTP; Wed, 31 Oct 2007 18:46:01 -0700 (PDT) Message-ID: Date: Thu, 1 Nov 2007 10:46:01 +0900 From: "Hyon Lim" To: "Andrew Dyer" Subject: Re: implementation of software suspend on MIPS. (system log) Cc: linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7167_25384525.1193881561234" References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17343 X-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@alexlab.net Precedence: bulk X-list: linux-mips ------=_Part_7167_25384525.1193881561234 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline WWVzLiB5b3UncmUgcmlnaHQuIEkgZGlkIHNhbWUgYXMgeW91IHNhaWQuCkhvd2V2ZXIsIGlzIHRo ZXJlIGFueSBvcHRpb25zIGZvciBkaXNhc3NlbWJseSB3aXRoIHZhcmlhYmxlIG5hbWU/Ck9mdGVu IEkgY2Fubm90IGZpbmQgdGhhdCB2YXJpYWJsZSdzIGFsbG9jYXRlZCByZWdpc3Rlci4KVGhlcmUg aXMgb25seSByMCxyMS4uLiBidXQgSSB3YW50IGEgY29tbWVudCBmb3IgdmFyaWFibGUgYXNzaWdu bWVudCBzdGF0dXMuCgpPbiAxMS8xLzA3LCBBbmRyZXcgRHllciA8YWR5ZXJAcmlnaHRoYW5kdGVj aC5jb20+IHdyb3RlOgo+Cj4gPiBUaGUgY29kZSBvZiByZXN1bWUgcHJvY2VzcyBzaG91bGQgYmUg aW1wbGVtZW50ZWQgb24KPiBhcmNoL3h4eC9wb3dlci9zd3N1c3AuUwo+ID4gU28gaXQgc2hvdWxk IGJlIGltcGxlbWVudGVkIGJ5IGFzc2VtYmx5Lgo+ID4gVGhhdCdzIHRoZSBwcm9ibGVtLi4uCj4g PiBJJ3ZlIG5vIGlkZWEgYWJvdXQgY29tcGxleCBhc3NlbWJseSBwcm9ncmFtbWluZy4gOi0pCj4g PiBDb3VsZCB5b3UgcmVjb21tZW5kIGFueSBwZGYgb3Igd2Vic2l0ZT8KPgo+IFdoZW5ldmVyIEkg aGF2ZSB0byBkbyBzb21ldGhpbmcgbW9kZXJhdGVseSBjb21wbGV4IGluIGFzc3kuIGxhbmd1YWdl LCBJCj4gb2Z0ZW4gZmluZCBpdCBoZWxwZnVsIHRvIGNvZGUgdGhlIHRoaW5nIGluIEMgYW5kIHJ1 biBpdCB0aHJvdWdoIHRoZSBjb21waWxlcgo+IGFuZCBsb29rIGF0IHRoZSBnZW5lcmF0ZWQgYXNz eS4gbGFuZ3VhZ2UuICBPZnRlbnRpbWVzIHlvdSBjYW4gbW9kaWZ5IHRoZQo+IG91dHB1dCBvZiB0 aGUgY29tcGlsZXIgd2l0aG91dCB0b28gbXVjaCB0cm91YmxlLgo+Cj4KCgotLSAKSHlvbiBMaW0g KMDTx/YpCk1vYmlsZS4gMDEwLTgyMTItMTI0MCAoSW50bCcgQ2FsbCA6ICs4Mi0xMC04MjEyLTEy NDApCkZheC4gMDMyLTIzMi0wNTc4IChJbnRsJyBBdmFpbGFibGUpCkhvbWVwYWdlIDogaHR0cDov L3d3dy5hbGV4bGFiLm5ldApCbG9nIDogaHR0cDovL3d3dy5hbGV4bGFiLm5ldC9ibG9nCg== ------=_Part_7167_25384525.1193881561234 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5ZZXMuIHlvdSYjMzk7cmUgcmlnaHQuIEkgZGlkIHNhbWUgYXMgeW91IHNhaWQuPC9kaXY+ CjxkaXY+SG93ZXZlciwgaXMgdGhlcmUgYW55IG9wdGlvbnMgZm9yIGRpc2Fzc2VtYmx5IHdpdGgg dmFyaWFibGUgbmFtZT88L2Rpdj4KPGRpdj5PZnRlbiBJIGNhbm5vdCBmaW5kJm5ic3A7dGhhdCB2 YXJpYWJsZSYjMzk7cyBhbGxvY2F0ZWQmbmJzcDtyZWdpc3Rlci48L2Rpdj4KPGRpdj5UaGVyZSBp cyBvbmx5IHIwLHIxLi4uIGJ1dCBJIHdhbnQgYSBjb21tZW50IGZvciB2YXJpYWJsZSBhc3NpZ25t ZW50IHN0YXR1cy48YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3Rl Ij5PbiAxMS8xLzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+QW5kcmV3IER5ZXI8L2I+ ICZsdDs8YSBocmVmPSJtYWlsdG86YWR5ZXJAcmlnaHRoYW5kdGVjaC5jb20iPmFkeWVyQHJpZ2h0 aGFuZHRlY2guY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAw LjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4mZ3Q7IFRoZSBjb2RlIG9mIHJlc3Vt ZSBwcm9jZXNzIHNob3VsZCBiZSBpbXBsZW1lbnRlZCBvbiBhcmNoL3h4eC9wb3dlci9zd3N1c3Au Uzxicj4mZ3Q7IFNvIGl0IHNob3VsZCBiZSBpbXBsZW1lbnRlZCBieSBhc3NlbWJseS4KPGJyPiZn dDsgVGhhdCYjMzk7cyB0aGUgcHJvYmxlbS4uLjxicj4mZ3Q7IEkmIzM5O3ZlIG5vIGlkZWEgYWJv dXQgY29tcGxleCBhc3NlbWJseSBwcm9ncmFtbWluZy4gOi0pPGJyPiZndDsgQ291bGQgeW91IHJl Y29tbWVuZCBhbnkgcGRmIG9yIHdlYnNpdGU/PGJyPjxicj5XaGVuZXZlciBJIGhhdmUgdG8gZG8g c29tZXRoaW5nIG1vZGVyYXRlbHkgY29tcGxleCBpbiBhc3N5LiBsYW5ndWFnZSwgSSBvZnRlbiBm aW5kIGl0IGhlbHBmdWwgdG8gY29kZSB0aGUgdGhpbmcgaW4gQyBhbmQgcnVuIGl0IHRocm91Z2gg dGhlIGNvbXBpbGVyIGFuZCBsb29rIGF0IHRoZSBnZW5lcmF0ZWQgYXNzeS4gbGFuZ3VhZ2UuJm5i c3A7Jm5ic3A7T2Z0ZW50aW1lcyB5b3UgY2FuIG1vZGlmeSB0aGUgb3V0cHV0IG9mIHRoZSBjb21w aWxlciB3aXRob3V0IHRvbyBtdWNoIHRyb3VibGUuCjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2 Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5IeW9uIExpbSAowNPH9ik8YnI+TW9iaWxl LiAwMTAtODIxMi0xMjQwIChJbnRsJiMzOTsgQ2FsbCA6ICs4Mi0xMC04MjEyLTEyNDApPGJyPkZh eC4gMDMyLTIzMi0wNTc4IChJbnRsJiMzOTsgQXZhaWxhYmxlKTxicj5Ib21lcGFnZSA6IDxhIGhy ZWY9Imh0dHA6Ly93d3cuYWxleGxhYi5uZXQiPgpodHRwOi8vd3d3LmFsZXhsYWIubmV0PC9hPjxi cj5CbG9nIDogPGEgaHJlZj0iaHR0cDovL3d3dy5hbGV4bGFiLm5ldC9ibG9nIj5odHRwOi8vd3d3 LmFsZXhsYWIubmV0L2Jsb2c8L2E+IAo= ------=_Part_7167_25384525.1193881561234-- From jscottkasten@yahoo.com Thu Nov 1 02:28:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 02:28:54 +0000 (GMT) Received: from smtp109.plus.mail.re1.yahoo.com ([69.147.102.72]:6818 "HELO smtp109.plus.mail.re1.yahoo.com") by ftp.linux-mips.org with SMTP id S28576807AbXKAC2p (ORCPT ); Thu, 1 Nov 2007 02:28:45 +0000 Received: (qmail 49570 invoked from network); 1 Nov 2007 02:27:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type; b=VeJJhY2mLtbp9GND6o0+eblWWNAD72OGWlAqdRja6wQwfuxmyGt72OgTSlT3mSoPc76uAM1cp2sBl+OKp0PQGMf0Z73whct4+VsTSlVuMEw3a1/Tjsd8O2/KWxNnREq3eWsrc/ktAvdd9Ga+7K/Sd/aNWI1Fu+tukjDpvvjtpeg= ; Received: from unknown (HELO zeus.tetracon-eng.net) (jscottkasten@72.185.69.24 with login) by smtp109.plus.mail.re1.yahoo.com with SMTP; 1 Nov 2007 02:27:38 -0000 X-YMail-OSG: gdlf6UwVM1n07P_vX.NsPycmeVKluZxOQVc5j.l6IJpG1sJ2qXh0T3_Cx5MPnk_8.UdIbut6Ag-- Date: Wed, 31 Oct 2007 22:27:31 -0400 From: "J. Scott Kasten" X-X-Sender: jsk@zeus.tetracon-eng.net To: Hyon Lim cc: linux-mips@linux-mips.org Subject: Re: implementation of software suspend on MIPS. (system log) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jscottkasten@yahoo.com Precedence: bulk X-list: linux-mips On Thu, 1 Nov 2007, Hyon Lim wrote: > Yes. you're right. I did same as you said. > However, is there any options for disassembly with variable name? > Often I cannot find that variable's allocated register. > There is only r0,r1... but I want a comment for variable assignment > status. I just have to ask the question, but is it really necessary to code the whole thing in assembly? I understand that the interface probably does need to be, but the main body of the function? If it's very large or complicated, it would seem simpler to use C and write assembly glue to pull it all together rather than trying to debug hand assembly. Many of us here have spent hours before tracking down problems with stale data in branch delay slots. The compiler is a tad more convienient. Regards, -S- From alex@alexlab.net Thu Nov 1 09:12:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 09:12:18 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.180]:50634 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20026518AbXKAJMJ (ORCPT ); Thu, 1 Nov 2007 09:12:09 +0000 Received: by py-out-1112.google.com with SMTP id p76so832821pyb for ; Thu, 01 Nov 2007 02:11:52 -0700 (PDT) Received: by 10.64.131.4 with SMTP id e4mr3352081qbd.1193908311335; Thu, 01 Nov 2007 02:11:51 -0700 (PDT) Received: by 10.65.123.7 with HTTP; Thu, 1 Nov 2007 02:11:51 -0700 (PDT) Message-ID: Date: Thu, 1 Nov 2007 18:11:51 +0900 From: "Hyon Lim" To: "J. Scott Kasten" Subject: Re: implementation of software suspend on MIPS. (system log) Cc: linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7971_20847680.1193908311329" References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17345 X-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@alexlab.net Precedence: bulk X-list: linux-mips ------=_Part_7971_20847680.1193908311329 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayB0aGUgcmVhc29uIG9mIGFzc2VtYmx5IGltcGxlbWVudGF0aW9uIGlzIHByb2Nlc3Nv ciBjb250ZXh0CnJlcGxhY2VtZW50LgpQcm9jZXNzb3IgY29udGV4dCBzaG91bGQgYmUgcmVwbGFj ZWQgd2hlbiBzdXNwZW5kIG9yIHJlc3VtZSBwcm9jZXNzLgpTbyBJIHRoaW5rIHRoYXQgY29kZSBz aG91bGQgYmUgaW1wbGVtZW50ZWQgdXNpbmcgYXNzZW1ibHkgbGFuZ3VhZ2UuClRoZSBzZWNvbmQg cmVhc29uIHRoYXQgSSB0aGlua2luZyBpcyBjYWxsaW5nIGNvbnZlbnRpb24gb2YgQyBsYW5ndWFn ZS4KSG93IGRvIHlvdSB0aGluaz8KCk9uIDExLzEvMDcsIEouIFNjb3R0IEthc3RlbiA8anNjb3R0 a2FzdGVuQHlhaG9vLmNvbT4gd3JvdGU6Cj4KPgo+IE9uIFRodSwgMSBOb3YgMjAwNywgSHlvbiBM aW0gd3JvdGU6Cj4KPiA+IFllcy4geW91J3JlIHJpZ2h0LiBJIGRpZCBzYW1lIGFzIHlvdSBzYWlk Lgo+ID4gSG93ZXZlciwgaXMgdGhlcmUgYW55IG9wdGlvbnMgZm9yIGRpc2Fzc2VtYmx5IHdpdGgg dmFyaWFibGUgbmFtZT8KPiA+IE9mdGVuIEkgY2Fubm90IGZpbmQgdGhhdCB2YXJpYWJsZSdzIGFs bG9jYXRlZCByZWdpc3Rlci4KPiA+IFRoZXJlIGlzIG9ubHkgcjAscjEuLi4gYnV0IEkgd2FudCBh IGNvbW1lbnQgZm9yIHZhcmlhYmxlIGFzc2lnbm1lbnQKPiA+IHN0YXR1cy4KPgo+IEkganVzdCBo YXZlIHRvIGFzayB0aGUgcXVlc3Rpb24sIGJ1dCBpcyBpdCByZWFsbHkgbmVjZXNzYXJ5IHRvIGNv ZGUgdGhlCj4gd2hvbGUgdGhpbmcgaW4gYXNzZW1ibHk/ICBJIHVuZGVyc3RhbmQgdGhhdCB0aGUg aW50ZXJmYWNlIHByb2JhYmx5IGRvZXMKPiBuZWVkIHRvIGJlLCBidXQgdGhlIG1haW4gYm9keSBv ZiB0aGUgZnVuY3Rpb24/ICBJZiBpdCdzIHZlcnkgbGFyZ2Ugb3IKPiBjb21wbGljYXRlZCwgaXQg d291bGQgc2VlbSBzaW1wbGVyIHRvIHVzZSBDIGFuZCB3cml0ZSBhc3NlbWJseSBnbHVlIHRvCj4g cHVsbCBpdCBhbGwgdG9nZXRoZXIgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGRlYnVnIGhhbmQgYXNz ZW1ibHkuICBNYW55IG9mCj4gdXMgaGVyZSBoYXZlIHNwZW50IGhvdXJzIGJlZm9yZSB0cmFja2lu ZyBkb3duIHByb2JsZW1zIHdpdGggc3RhbGUgZGF0YSBpbgo+IGJyYW5jaCBkZWxheSBzbG90cy4g IFRoZSBjb21waWxlciBpcyBhIHRhZCBtb3JlIGNvbnZpZW5pZW50Lgo+Cj4gUmVnYXJkcywKPgo+ IC1TLQo+Cj4KCgotLSAKSHlvbiBMaW0gKMDTx/YpCk1vYmlsZS4gMDEwLTgyMTItMTI0MCAoSW50 bCcgQ2FsbCA6ICs4Mi0xMC04MjEyLTEyNDApCkZheC4gMDMyLTIzMi0wNTc4IChJbnRsJyBBdmFp bGFibGUpCkhvbWVwYWdlIDogaHR0cDovL3d3dy5hbGV4bGFiLm5ldApCbG9nIDogaHR0cDovL3d3 dy5hbGV4bGFiLm5ldC9ibG9nCg== ------=_Part_7971_20847680.1193908311329 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5JIHRoaW5rIHRoZSByZWFzb24gb2YgYXNzZW1ibHkgaW1wbGVtZW50YXRpb24gaXMgcHJv Y2Vzc29yJm5ic3A7Y29udGV4dCByZXBsYWNlbWVudC48L2Rpdj4KPGRpdj5Qcm9jZXNzb3IgY29u dGV4dCBzaG91bGQgYmUgcmVwbGFjZWQgd2hlbiBzdXNwZW5kIG9yIHJlc3VtZSBwcm9jZXNzLjwv ZGl2Pgo8ZGl2PlNvIEkgdGhpbmsgdGhhdCBjb2RlIHNob3VsZCBiZSBpbXBsZW1lbnRlZCB1c2lu ZyBhc3NlbWJseSBsYW5ndWFnZS48L2Rpdj4KPGRpdj5UaGUgc2Vjb25kIHJlYXNvbiB0aGF0IEkg dGhpbmtpbmcgaXMgY2FsbGluZyBjb252ZW50aW9uIG9mIEMgbGFuZ3VhZ2UuPC9kaXY+CjxkaXY+ SG93IGRvIHlvdSB0aGluaz88YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiAxMS8xLzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Si4gU2NvdHQg S2FzdGVuPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpzY290dGthc3RlbkB5YWhvby5jb20iPmpz Y290dGthc3RlbkB5YWhvby5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAw cHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPjxicj5PbiBUaHUsIDEg Tm92IDIwMDcsIEh5b24gTGltIHdyb3RlOjxicj48YnI+Jmd0OyBZZXMuIHlvdSYjMzk7cmUgcmln aHQuIEkgZGlkIHNhbWUgYXMgeW91IHNhaWQuPGJyPiZndDsgSG93ZXZlciwgaXMgdGhlcmUgYW55 IG9wdGlvbnMgZm9yIGRpc2Fzc2VtYmx5IHdpdGggdmFyaWFibGUgbmFtZT8KPGJyPiZndDsgT2Z0 ZW4gSSBjYW5ub3QgZmluZCB0aGF0IHZhcmlhYmxlJiMzOTtzIGFsbG9jYXRlZCByZWdpc3Rlci48 YnI+Jmd0OyBUaGVyZSBpcyBvbmx5IHIwLHIxLi4uIGJ1dCBJIHdhbnQgYSBjb21tZW50IGZvciB2 YXJpYWJsZSBhc3NpZ25tZW50PGJyPiZndDsgc3RhdHVzLjxicj48YnI+SSBqdXN0IGhhdmUgdG8g YXNrIHRoZSBxdWVzdGlvbiwgYnV0IGlzIGl0IHJlYWxseSBuZWNlc3NhcnkgdG8gY29kZSB0aGUK PGJyPndob2xlIHRoaW5nIGluIGFzc2VtYmx5PyZuYnNwOyZuYnNwO0kgdW5kZXJzdGFuZCB0aGF0 IHRoZSBpbnRlcmZhY2UgcHJvYmFibHkgZG9lczxicj5uZWVkIHRvIGJlLCBidXQgdGhlIG1haW4g Ym9keSBvZiB0aGUgZnVuY3Rpb24/Jm5ic3A7Jm5ic3A7SWYgaXQmIzM5O3MgdmVyeSBsYXJnZSBv cjxicj5jb21wbGljYXRlZCwgaXQgd291bGQgc2VlbSBzaW1wbGVyIHRvIHVzZSBDIGFuZCB3cml0 ZSBhc3NlbWJseSBnbHVlIHRvCjxicj5wdWxsIGl0IGFsbCB0b2dldGhlciByYXRoZXIgdGhhbiB0 cnlpbmcgdG8gZGVidWcgaGFuZCBhc3NlbWJseS4mbmJzcDsmbmJzcDtNYW55IG9mPGJyPnVzIGhl cmUgaGF2ZSBzcGVudCBob3VycyBiZWZvcmUgdHJhY2tpbmcgZG93biBwcm9ibGVtcyB3aXRoIHN0 YWxlIGRhdGEgaW48YnI+YnJhbmNoIGRlbGF5IHNsb3RzLiZuYnNwOyZuYnNwO1RoZSBjb21waWxl ciBpcyBhIHRhZCBtb3JlIGNvbnZpZW5pZW50Ljxicj4KPGJyPlJlZ2FyZHMsPGJyPjxicj4tUy08 YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+ SHlvbiBMaW0gKMDTx/YpPGJyPk1vYmlsZS4gMDEwLTgyMTItMTI0MCAoSW50bCYjMzk7IENhbGwg OiArODItMTAtODIxMi0xMjQwKTxicj5GYXguIDAzMi0yMzItMDU3OCAoSW50bCYjMzk7IEF2YWls YWJsZSk8YnI+SG9tZXBhZ2UgOiA8YSBocmVmPSJodHRwOi8vd3d3LmFsZXhsYWIubmV0Ij4KaHR0 cDovL3d3dy5hbGV4bGFiLm5ldDwvYT48YnI+QmxvZyA6IDxhIGhyZWY9Imh0dHA6Ly93d3cuYWxl eGxhYi5uZXQvYmxvZyI+aHR0cDovL3d3dy5hbGV4bGFiLm5ldC9ibG9nPC9hPiAK ------=_Part_7971_20847680.1193908311329-- From tsbogend@alpha.franken.de Thu Nov 1 10:39:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 10:40:03 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:58551 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20026568AbXKAKjy (ORCPT ); Thu, 1 Nov 2007 10:39:54 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1InXPo-0003Sa-00; Thu, 01 Nov 2007 11:36:44 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 66B02FA733; Thu, 1 Nov 2007 11:36:42 +0100 (CET) Date: Thu, 1 Nov 2007 11:36:42 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] SNI: register a02r clockevent; don't use PIT timer Message-ID: <20071101103642.GA28146@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Register A20R clockevent Remove PIT timer setup because it doesn't work Signed-off-by: Thomas Bogendoerfer --- diff --git a/arch/mips/sni/time.c b/arch/mips/sni/time.c index 60bc62e..6f339af 100644 --- a/arch/mips/sni/time.c +++ b/arch/mips/sni/time.c @@ -1,6 +1,7 @@ #include #include #include +#include #include #include @@ -80,7 +81,7 @@ static void __init sni_a20r_timer_setup(void) unsigned int cpu = smp_processor_id(); cd->cpumask = cpumask_of_cpu(cpu); - + clockevents_register_device(cd); action->dev_id = cd; setup_irq(SNI_A20R_IRQ_TIMER, &a20r_irqaction); } @@ -169,8 +170,6 @@ void __init plat_time_init(void) mips_hpt_frequency = r4k_tick * HZ; - setup_pit_timer(); - switch (sni_brd_type) { case SNI_BRD_10: case SNI_BRD_10NEW: -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From yoichi_yuasa@tripeaks.co.jp Thu Nov 1 12:30:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 12:30:55 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:46408 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20026775AbXKAMaq (ORCPT ); Thu, 1 Nov 2007 12:30:46 +0000 Received: by mo.po.2iij.net (mo31) id lA1CUgdq048730; Thu, 1 Nov 2007 21:30:42 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox305) id lA1CUb5E020131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2007 21:30:37 +0900 Date: Thu, 1 Nov 2007 21:30:36 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] bcm47xx: remove unneeded clear_c0_status() Message-Id: <20071101213036.c383957f.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Remove unneeded clear_c0_status(). irq_cpu routines take care of it. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/bcm47xx/irq.c mips/arch/mips/bcm47xx/irq.c --- mips-orig/arch/mips/bcm47xx/irq.c 2007-10-26 23:35:58.630600250 +0900 +++ mips/arch/mips/bcm47xx/irq.c 2007-10-26 23:40:22.587096500 +0900 @@ -33,8 +33,6 @@ void plat_irq_dispatch(void) cause = read_c0_cause() & read_c0_status() & CAUSEF_IP; - clear_c0_status(cause); - if (cause & CAUSEF_IP7) do_IRQ(7); if (cause & CAUSEF_IP2) From yoichi_yuasa@tripeaks.co.jp Thu Nov 1 12:35:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 12:35:55 +0000 (GMT) Received: from mo32.po.2iij.NET ([210.128.50.17]:5924 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20026738AbXKAMfr (ORCPT ); Thu, 1 Nov 2007 12:35:47 +0000 Received: by mo.po.2iij.net (mo32) id lA1CZiPI061130; Thu, 1 Nov 2007 21:35:44 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox303) id lA1CZe3S005923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2007 21:35:40 +0900 Date: Thu, 1 Nov 2007 21:35:39 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] clean up au1xxx_irqmap.c include files Message-Id: <20071101213539.9c47c3e9.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Clean up au1xxx_irqmap.c include files. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/au1000/common/au1xxx_irqmap.c mips/arch/mips/au1000/common/au1xxx_irqmap.c --- mips-orig/arch/mips/au1000/common/au1xxx_irqmap.c 2007-10-26 23:35:58.350582750 +0900 +++ mips/arch/mips/au1000/common/au1xxx_irqmap.c 2007-10-26 23:54:59.221882750 +0900 @@ -25,27 +25,10 @@ * 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 -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include +#include + +#include /* The IC0 interrupt table. This is processor, rather than * board dependent, so no reason to keep this info in the board From alex@alexlab.net Thu Nov 1 12:36:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 12:37:06 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.180]:39004 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20026754AbXKAMg6 (ORCPT ); Thu, 1 Nov 2007 12:36:58 +0000 Received: by py-out-1112.google.com with SMTP id p76so916564pyb for ; Thu, 01 Nov 2007 05:36:46 -0700 (PDT) Received: by 10.65.59.11 with SMTP id m11mr3684320qbk.1193920604906; Thu, 01 Nov 2007 05:36:44 -0700 (PDT) Received: by 10.65.123.7 with HTTP; Thu, 1 Nov 2007 05:36:44 -0700 (PDT) Message-ID: Date: Thu, 1 Nov 2007 21:36:44 +0900 From: "Hyon Lim" To: linux-mips@linux-mips.org Subject: MIPS assembly directives in GCC MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8411_4807151.1193920604837" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17349 X-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@alexlab.net Precedence: bulk X-list: linux-mips ------=_Part_8411_4807151.1193920604837 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline SSBpbnZlc3RpZ2F0ZWQga2VybmVsIGFzc2VtYmx5IHNvdXJjZSBjb2RlIGluIG15IGtlcm5lbCAo Mi42LjEwKS4KSSBmb3VuZCB0aGF0IHRoZXJlIGFyZSBhIGxvdCBvZiBhc3NlbWJseSBkaXJlY3Rp dmVzIChlLmcuLCAuYWxpZ24sIC5zZXQKcmVvcmRlciwgLmNwbG9hZCwgLmZyYW1lIGV0Yy4pLgpJ cyB0aGVyZSBhbnkgZG9jdW1lbnRzIHdoaWNoIGV4cGxhaW5zIHRob3NlIGRpcmVjdGl2ZXM/IChu b3Qgb25seSBJCmRlc2NyaWJlZCBhYm92ZS4gQWxsIG9mIGRpcmVjdGl2ZXMpCgotLSAKSHlvbiBM aW0gKMDTx/YpCk1vYmlsZS4gMDEwLTgyMTItMTI0MCAoSW50bCcgQ2FsbCA6ICs4Mi0xMC04MjEy LTEyNDApCkZheC4gMDMyLTIzMi0wNTc4IChJbnRsJyBBdmFpbGFibGUpCkhvbWVwYWdlIDogaHR0 cDovL3d3dy5hbGV4bGFiLm5ldApCbG9nIDogaHR0cDovL3d3dy5hbGV4bGFiLm5ldC9ibG9nCg== ------=_Part_8411_4807151.1193920604837 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5JIGludmVzdGlnYXRlZCBrZXJuZWwgYXNzZW1ibHkgc291cmNlIGNvZGUgaW4gbXkga2Vy bmVsICgyLjYuMTApLjwvZGl2Pgo8ZGl2PkkgZm91bmQgdGhhdCB0aGVyZSBhcmUgYSBsb3Qgb2Yg YXNzZW1ibHkgZGlyZWN0aXZlcyAoZS5nLiwgLmFsaWduLCAuc2V0IHJlb3JkZXIsIC5jcGxvYWQs IC5mcmFtZSBldGMuKS48L2Rpdj4KPGRpdj5JcyB0aGVyZSBhbnkgZG9jdW1lbnRzIHdoaWNoIGV4 cGxhaW5zIHRob3NlIGRpcmVjdGl2ZXM/IChub3Qgb25seSBJIGRlc2NyaWJlZCBhYm92ZS4gQWxs IG9mIGRpcmVjdGl2ZXMpPGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+SHlvbiBMaW0gKMDTx/Yp PGJyPk1vYmlsZS4gMDEwLTgyMTItMTI0MCAoSW50bCYjMzk7IENhbGwgOiArODItMTAtODIxMi0x MjQwKTxicj5GYXguIDAzMi0yMzItMDU3OCAoSW50bCYjMzk7IEF2YWlsYWJsZSkKPGJyPkhvbWVw YWdlIDogPGEgaHJlZj0iaHR0cDovL3d3dy5hbGV4bGFiLm5ldCI+aHR0cDovL3d3dy5hbGV4bGFi Lm5ldDwvYT48YnI+QmxvZyA6IDxhIGhyZWY9Imh0dHA6Ly93d3cuYWxleGxhYi5uZXQvYmxvZyI+ aHR0cDovL3d3dy5hbGV4bGFiLm5ldC9ibG9nPC9hPiA8L2Rpdj4K ------=_Part_8411_4807151.1193920604837-- From tsbogend@alpha.franken.de Thu Nov 1 12:52:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 12:52:45 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:58573 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20026791AbXKAMwf (ORCPT ); Thu, 1 Nov 2007 12:52:35 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1InZXG-0004c5-00; Thu, 01 Nov 2007 13:52:34 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 19EF5C2361; Thu, 1 Nov 2007 13:52:36 +0100 (CET) Date: Thu, 1 Nov 2007 13:52:36 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071101125236.GA16577@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips PIT doesn't work, disable it completly make r4030 clockevent code look like other mips clockevent code Signed-off-by: Thomas Bogendoerfer --- diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 97da953..c4f7e60 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -119,7 +119,6 @@ config MACH_JAZZ select CEVT_R4K select GENERIC_ISA_DMA select IRQ_CPU - select I8253 select I8259 select ISA select PCSPEAKER diff --git a/arch/mips/jazz/irq.c b/arch/mips/jazz/irq.c index 1dac9e1..a629719 100644 --- a/arch/mips/jazz/irq.c +++ b/arch/mips/jazz/irq.c @@ -118,16 +118,16 @@ static void r4030_set_mode(enum clock_event_mode mode, struct clock_event_device r4030_clockevent = { .name = "r4030", .features = CLOCK_EVT_FEAT_PERIODIC, - .rating = 100, + .rating = 300, .irq = JAZZ_TIMER_IRQ, - .cpumask = CPU_MASK_CPU0, .set_mode = r4030_set_mode, }; static irqreturn_t r4030_timer_interrupt(int irq, void *dev_id) { - r4030_clockevent.event_handler(&r4030_clockevent); + struct clock_event_device *cd = dev_id; + cd->event_handler(cd); return IRQ_HANDLED; } @@ -135,15 +135,22 @@ static struct irqaction r4030_timer_irqaction = { .handler = r4030_timer_interrupt, .flags = IRQF_DISABLED, .mask = CPU_MASK_CPU0, - .name = "timer", + .name = "R4030 timer", }; void __init plat_time_init(void) { - struct irqaction *irq = &r4030_timer_irqaction; + struct clock_event_device *cd = &r4030_clockevent; + struct irqaction *action = &r4030_timer_irqaction; + unsigned int cpu = smp_processor_id(); BUG_ON(HZ != 100); + cd->cpumask = cpumask_of_cpu(cpu); + clockevents_register_device(cd); + action->dev_id = cd; + setup_irq(JAZZ_TIMER_IRQ, action); + /* * Set clock to 100Hz. * @@ -151,8 +158,4 @@ void __init plat_time_init(void) * a programmable 4-bit divider. This makes it fairly inflexible. */ r4030_write_reg32(JAZZ_TIMER_INTERVAL, 9); - setup_irq(JAZZ_TIMER_IRQ, irq); - - clockevents_register_device(&r4030_clockevent); - setup_pit_timer(); } -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From yoichi_yuasa@tripeaks.co.jp Thu Nov 1 12:53:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 12:53:14 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:20772 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20026790AbXKAMwp (ORCPT ); Thu, 1 Nov 2007 12:52:45 +0000 Received: by mo.po.2iij.net (mo31) id lA1CpQqH060965; Thu, 1 Nov 2007 21:51:26 +0900 (JST) Received: from delta (221.25.30.125.dy.iij4u.or.jp [125.30.25.221]) by mbox.po.2iij.net (po-mbox302) id lA1CpN13031798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Nov 2007 21:51:24 +0900 Date: Thu, 1 Nov 2007 21:51:23 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] fix Cobalt IRQ comment Message-Id: <20071101215123.5e65eee6.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Fixed Cobalt IRQ comment. Cobalt kernel uses CP0 counter now. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-cobalt/irq.h mips/include/asm-mips/mach-cobalt/irq.h --- mips-orig/include/asm-mips/mach-cobalt/irq.h 2007-10-27 17:13:58.239256750 +0900 +++ mips/include/asm-mips/mach-cobalt/irq.h 2007-10-27 17:17:45.905485000 +0900 @@ -35,7 +35,7 @@ * 4 - ethernet * 5 - 16550 UART * 6 - cascade i8259 - * 7 - CP0 counter (unused) + * 7 - CP0 counter */ #define MIPS_CPU_IRQ_BASE 16 @@ -48,7 +48,6 @@ #define SCSI_IRQ (MIPS_CPU_IRQ_BASE + 5) #define I8259_CASCADE_IRQ (MIPS_CPU_IRQ_BASE + 6) - #define GT641XX_IRQ_BASE 24 #include From ralf@linux-mips.org Thu Nov 1 13:04:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 13:04:18 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:42701 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026785AbXKANEQ (ORCPT ); Thu, 1 Nov 2007 13:04:16 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1D3tFB012467; Thu, 1 Nov 2007 13:03:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1D3qEo012466; Thu, 1 Nov 2007 13:03:52 GMT Date: Thu, 1 Nov 2007 13:03:52 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] bcm47xx: remove unneeded clear_c0_status() Message-ID: <20071101130352.GA18642@linux-mips.org> References: <20071101213036.c383957f.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101213036.c383957f.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17352 X-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, Nov 01, 2007 at 09:30:36PM +0900, Yoichi Yuasa wrote: > Remove unneeded clear_c0_status(). > irq_cpu routines take care of it. Actually this write is plain nonsense; it has no effect. The only time acknowledging an interrupt in c0_cause is needed is for the two software interrupts but the only user of these is SMTC. Ralf From ralf@linux-mips.org Thu Nov 1 13:13:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 13:13:02 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:18877 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026411AbXKANNA (ORCPT ); Thu, 1 Nov 2007 13:13:00 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1DCda3014464; Thu, 1 Nov 2007 13:12:39 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1DCd5b014463; Thu, 1 Nov 2007 13:12:39 GMT Date: Thu, 1 Nov 2007 13:12:39 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] clean up au1xxx_irqmap.c include files Message-ID: <20071101131239.GA14453@linux-mips.org> References: <20071101213539.9c47c3e9.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101213539.9c47c3e9.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17353 X-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, Nov 01, 2007 at 09:35:39PM +0900, Yoichi Yuasa wrote: > Clean up au1xxx_irqmap.c include files. Thanks, queued up for 2.6.25. Ralf From ralf@linux-mips.org Thu Nov 1 13:14:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 13:14:21 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:32958 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026805AbXKANOS (ORCPT ); Thu, 1 Nov 2007 13:14:18 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1DDw8N014516; Thu, 1 Nov 2007 13:13:58 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1DDwWU014515; Thu, 1 Nov 2007 13:13:58 GMT Date: Thu, 1 Nov 2007 13:13:58 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] fix Cobalt IRQ comment Message-ID: <20071101131358.GB14453@linux-mips.org> References: <20071101215123.5e65eee6.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101215123.5e65eee6.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17354 X-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, Nov 01, 2007 at 09:51:23PM +0900, Yoichi Yuasa wrote: > Fixed Cobalt IRQ comment. > Cobalt kernel uses CP0 counter now. Thanks, applied. Ralf From jscottkasten@yahoo.com Thu Nov 1 13:42:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 13:42:34 +0000 (GMT) Received: from smtp103.plus.mail.re1.yahoo.com ([69.147.102.66]:33104 "HELO smtp103.plus.mail.re1.yahoo.com") by ftp.linux-mips.org with SMTP id S20026803AbXKANmZ (ORCPT ); Thu, 1 Nov 2007 13:42:25 +0000 Received: (qmail 88324 invoked from network); 1 Nov 2007 13:41:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type; b=A8jJnFsh7nG1N8O5f0OGuPcKVBZsvTnzlDZvaqt/GRzzwARsL3bIwYPloA/zwRI2KnM6Dj4OBYgAXffD1RvyDgDK50jEnXlBa+Jn4uemkAEykwGAk6wXKoG0TAHygqgjyyTIeCasKLOLuYpnblINLsJM44/4hnkJPK21QTLR7iM= ; Received: from unknown (HELO ?192.168.254.6?) (jscottkasten@72.185.69.24 with login) by smtp103.plus.mail.re1.yahoo.com with SMTP; 1 Nov 2007 13:41:18 -0000 X-YMail-OSG: mjqeyvUVM1mifQm6PmYvxwcYLtr3u3kiVHBc1flwqEOQRYk8dKYh8l6tVWxPL46sheyQPz28Kg-- Date: Thu, 1 Nov 2007 09:41:12 -0400 (EDT) From: "J. Scott Kasten" X-X-Sender: jsk@pixie.tetracon-eng.net To: Hyon Lim cc: linux-mips@linux-mips.org Subject: Re: implementation of software suspend on MIPS. (system log) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jscottkasten@yahoo.com Precedence: bulk X-list: linux-mips On Thu, 1 Nov 2007, Hyon Lim wrote: > I think the reason of assembly implementation is processor context > replacement. Understood. Assembly may indeed be required for specific things like restoring register state or fiddling with the cache if there aren't already macros or functions in the kernel that do exactly what you need. > The second reason that I thinking is calling convention of C language. It's not uncommon at all to have assembly language glue, say between a BIOS callback and the C language routine that does the work. In your original post, you mentioned tracking variables and things that suggested a module that does much more that just load some odd registers or flip around a function call stack. If that is indeed the case, then for sake of maintainablility and readability, one would be strongly encouraged to write the core stuff in plain old C and sprinkle in assembly glue code as required. Think about it this way. MIPS is a pretty large family of CPUs, each with it's own strange behaviors. Several of those people on this list spend a lot of time tweeking that assembly to make it work cleanly across various CPUs. It's a lot easier to understand 25 lines of assembly interface code and 200 lines of C code, than an entire 1000 line module written in assembly. It's also a lot easier when you can shove most of the work over to the compiler, especially if others like your work and want to generalize it for use on many other MIPS CPUs. I guess the real question here is how complex do you think your code needs to be? That should determine your path. Regards, -S- From ths@networkno.de Thu Nov 1 14:26:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 14:26:42 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:33980 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20026858AbXKAO0e (ORCPT ); Thu, 1 Nov 2007 14:26:34 +0000 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id 607A4490D8; Thu, 1 Nov 2007 15:15:41 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1Inb05-00021y-FE; Thu, 01 Nov 2007 14:26:25 +0000 Date: Thu, 1 Nov 2007 14:26:25 +0000 From: Thiemo Seufer To: Hyon Lim Cc: linux-mips@linux-mips.org Subject: Re: MIPS assembly directives in GCC Message-ID: <20071101142625.GQ7712@networkno.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Hyon Lim wrote: > I investigated kernel assembly source code in my kernel (2.6.10). > I found that there are a lot of assembly directives (e.g., .align, .set > reorder, .cpload, .frame etc.). > Is there any documents which explains those directives? (not only I > described above. All of directives) Short of reading the assembler sourcecode I believe the best document is "See MIPS Run Linux". Thiemo From alex@alexlab.net Thu Nov 1 14:38:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 14:38:15 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.182]:20766 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20026888AbXKAOiG (ORCPT ); Thu, 1 Nov 2007 14:38:06 +0000 Received: by py-out-1112.google.com with SMTP id p76so976851pyb for ; Thu, 01 Nov 2007 07:37:52 -0700 (PDT) Received: by 10.65.96.6 with SMTP id y6mr3930917qbl.1193927871792; Thu, 01 Nov 2007 07:37:51 -0700 (PDT) Received: by 10.65.123.7 with HTTP; Thu, 1 Nov 2007 07:37:51 -0700 (PDT) Message-ID: Date: Thu, 1 Nov 2007 23:37:51 +0900 From: "Hyon Lim" To: "J. Scott Kasten" Subject: Re: implementation of software suspend on MIPS. (system log) Cc: linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8886_6312604.1193927871785" References: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17357 X-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@alexlab.net Precedence: bulk X-list: linux-mips ------=_Part_8886_6312604.1193927871785 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmsgeW91IGZvciBjb21tZW50cy4KVGhlIHJlbWFpbiB3b3JrIG9mIG15IHNvZnR3YXJlIHN1 c3BlbmQgb24gTUlQUyBwcm9qZWN0IGlzIHJlc3VtZSBwcm9jZWR1cmUuCkkgYWxyZWFkeSBjb25m aXJtZWQgdGhhdCBzdXNwZW5kIGZ1bmN0aW9uIHdhcyB3b3JrLiAoU2VlIG15IHBvc3Qgd2hpY2gK Y29udGFpbnMgc3lzdGVtIGxvZykuCgpJbiBhbiBpMzg2IGltcGxlbWVudGF0aW9uLCB0aGVyZSBh cmUgb25seSBmZXcgYXNzZW1ibHkgY29kZSBmb3Igc3VzcGVuZCBhbmQKcmVzdW1lIHByb2NlZHVy ZS4KKFlvdSBjYW4gcmVmZXIgOgpodHRwOi8vbHhyLmxpbnV4Lm5vL3NvdXJjZS9hcmNoL2kzODYv cG93ZXIvc3dzdXNwLlM/dj0yLjYuMTApClNvLCBteSB3b3JrIHdpbGwgYmUgc2ltaWxhciB3aXRo IGkzODYgaW1wbGVtZW50YXRpb24uIEFzc2VtYmx5IGNvZGUgdXNlZCBpbgppMzg2IGltcGxlbWVu dGF0aW9uIGFyZSBzZXZlcmFsIHByb2Nlc3NvciBjb250ZXh0IHJlbGF0ZWQgam9iCmFuZCBjb3B5 IHNhdmVkIHBhZ2UgdG8gbWVtb3J5LiBJbnN0cnVjdGlvbiB1c2VkIGluIG15IE1JUFMgaW1wbGVt ZW50YXRpb24Kd2lsbCBiZSBjb21wYXRpYmxlIHRvIG1vc3Qgb2YgTUlQUyBwcm9jZXNzb3IuCkJl Y2F1c2UgdGhlIGluc3RydWN0aW9uIHVzZWQgaW4gaW1wbGVtZW50YXRpb24gaXMgdmVyeSBiYXNp YyAoc3RvcmUgYW5kIGxvYWQKYW5kIGJyYW5jaCkuCgpJIGFncmVlIHlvdXIgb3BpbmlvbiByZWxh dGVkIHRvIG1haW50YWluYWJpbGl0eSBhbmQgcmVhZGFiaWxpdHkuIFNvIEkKaW1wbGVtZW50IG15 IHdvcmsgd2l0aCBDIGFuZCBmZXcgYXNzZW1ibHkgY29kZS4KVGhhbmsgeW91IGZvciBhZHZpY2Uu CgpPbiAxMS8xLzA3LCBKLiBTY290dCBLYXN0ZW4gPGpzY290dGthc3RlbkB5YWhvby5jb20+IHdy b3RlOgo+Cj4KPgo+IE9uIFRodSwgMSBOb3YgMjAwNywgSHlvbiBMaW0gd3JvdGU6Cj4KPiA+IEkg dGhpbmsgdGhlIHJlYXNvbiBvZiBhc3NlbWJseSBpbXBsZW1lbnRhdGlvbiBpcyBwcm9jZXNzb3Ig Y29udGV4dAo+ID4gcmVwbGFjZW1lbnQuCj4KPiBVbmRlcnN0b29kLiAgQXNzZW1ibHkgbWF5IGlu ZGVlZCBiZSByZXF1aXJlZCBmb3Igc3BlY2lmaWMgdGhpbmdzIGxpa2UKPiByZXN0b3JpbmcgcmVn aXN0ZXIgc3RhdGUgb3IgZmlkZGxpbmcgd2l0aCB0aGUgY2FjaGUgaWYgdGhlcmUgYXJlbid0Cj4g YWxyZWFkeSBtYWNyb3Mgb3IgZnVuY3Rpb25zIGluIHRoZSBrZXJuZWwgdGhhdCBkbyBleGFjdGx5 IHdoYXQgeW91IG5lZWQuCj4KPiA+IFRoZSBzZWNvbmQgcmVhc29uIHRoYXQgSSB0aGlua2luZyBp cyBjYWxsaW5nIGNvbnZlbnRpb24gb2YgQyBsYW5ndWFnZS4KPgo+IEl0J3Mgbm90IHVuY29tbW9u IGF0IGFsbCB0byBoYXZlIGFzc2VtYmx5IGxhbmd1YWdlIGdsdWUsIHNheSBiZXR3ZWVuIGEKPiBC SU9TIGNhbGxiYWNrIGFuZCB0aGUgQyBsYW5ndWFnZSByb3V0aW5lIHRoYXQgZG9lcyB0aGUgd29y ay4KPgo+IEluIHlvdXIgb3JpZ2luYWwgcG9zdCwgeW91IG1lbnRpb25lZCB0cmFja2luZyB2YXJp YWJsZXMgYW5kIHRoaW5ncyB0aGF0Cj4gc3VnZ2VzdGVkIGEgbW9kdWxlIHRoYXQgZG9lcyBtdWNo IG1vcmUgdGhhdCBqdXN0IGxvYWQgc29tZSBvZGQgcmVnaXN0ZXJzCj4gb3IgZmxpcCBhcm91bmQg YSBmdW5jdGlvbiBjYWxsIHN0YWNrLiAgSWYgdGhhdCBpcyBpbmRlZWQgdGhlIGNhc2UsIHRoZW4K PiBmb3Igc2FrZSBvZiBtYWludGFpbmFibGlsaXR5IGFuZCByZWFkYWJpbGl0eSwgb25lIHdvdWxk IGJlIHN0cm9uZ2x5Cj4gZW5jb3VyYWdlZCB0byB3cml0ZSB0aGUgY29yZSBzdHVmZiBpbiBwbGFp biBvbGQgQyBhbmQgc3ByaW5rbGUgaW4gYXNzZW1ibHkKPiBnbHVlIGNvZGUgYXMgcmVxdWlyZWQu Cj4KPiBUaGluayBhYm91dCBpdCB0aGlzIHdheS4gIE1JUFMgaXMgYSBwcmV0dHkgbGFyZ2UgZmFt aWx5IG9mIENQVXMsIGVhY2ggd2l0aAo+IGl0J3Mgb3duIHN0cmFuZ2UgYmVoYXZpb3JzLiAgU2V2 ZXJhbCBvZiB0aG9zZSBwZW9wbGUgb24gdGhpcyBsaXN0IHNwZW5kIGEKPiBsb3Qgb2YgdGltZSB0 d2Vla2luZyB0aGF0IGFzc2VtYmx5IHRvIG1ha2UgaXQgd29yayBjbGVhbmx5IGFjcm9zcyB2YXJp b3VzCj4gQ1BVcy4gIEl0J3MgYSBsb3QgZWFzaWVyIHRvIHVuZGVyc3RhbmQgMjUgbGluZXMgb2Yg YXNzZW1ibHkgaW50ZXJmYWNlIGNvZGUKPiBhbmQgMjAwIGxpbmVzIG9mIEMgY29kZSwgdGhhbiBh biBlbnRpcmUgMTAwMCBsaW5lIG1vZHVsZSB3cml0dGVuIGluCj4gYXNzZW1ibHkuICBJdCdzIGFs c28gYSBsb3QgZWFzaWVyIHdoZW4geW91IGNhbiBzaG92ZSBtb3N0IG9mIHRoZSB3b3JrIG92ZXIK PiB0byB0aGUgY29tcGlsZXIsIGVzcGVjaWFsbHkgaWYgb3RoZXJzIGxpa2UgeW91ciB3b3JrIGFu ZCB3YW50IHRvCj4gZ2VuZXJhbGl6ZSBpdCBmb3IgdXNlIG9uIG1hbnkgb3RoZXIgTUlQUyBDUFVz Lgo+Cj4gSSBndWVzcyB0aGUgcmVhbCBxdWVzdGlvbiBoZXJlIGlzIGhvdyBjb21wbGV4IGRvIHlv dSB0aGluayB5b3VyIGNvZGUgbmVlZHMKPiB0byBiZT8gIFRoYXQgc2hvdWxkIGRldGVybWluZSB5 b3VyIHBhdGguCj4KPiBSZWdhcmRzLAo+Cj4gLVMtCj4KCgoKLS0gCkh5b24gTGltICjA08f2KQpN b2JpbGUuIDAxMC04MjEyLTEyNDAgKEludGwnIENhbGwgOiArODItMTAtODIxMi0xMjQwKQpGYXgu IDAzMi0yMzItMDU3OCAoSW50bCcgQXZhaWxhYmxlKQpIb21lcGFnZSA6IGh0dHA6Ly93d3cuYWxl eGxhYi5uZXQKQmxvZyA6IGh0dHA6Ly93d3cuYWxleGxhYi5uZXQvYmxvZwo= ------=_Part_8886_6312604.1193927871785 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5UaGFuayB5b3UgZm9yIGNvbW1lbnRzLjwvZGl2Pgo8ZGl2PlRoZSByZW1haW4gd29yayBv ZiBteSBzb2Z0d2FyZSBzdXNwZW5kIG9uIE1JUFMgcHJvamVjdCBpcyByZXN1bWUgcHJvY2VkdXJl LjwvZGl2Pgo8ZGl2PkkgYWxyZWFkeSBjb25maXJtZWQgdGhhdCBzdXNwZW5kIGZ1bmN0aW9uIHdh cyB3b3JrLiAoU2VlIG15IHBvc3Qgd2hpY2ggY29udGFpbnMgc3lzdGVtIGxvZykuPC9kaXY+Cjxk aXY+Jm5ic3A7PC9kaXY+CjxkaXY+SW4gYW4gaTM4NiBpbXBsZW1lbnRhdGlvbiwgdGhlcmUgYXJl IG9ubHkgZmV3IGFzc2VtYmx5IGNvZGUgZm9yIHN1c3BlbmQgYW5kIHJlc3VtZSBwcm9jZWR1cmUu PC9kaXY+CjxkaXY+KFlvdSBjYW4gcmVmZXImbmJzcDs6IDxhIGhyZWY9Imh0dHA6Ly9seHIubGlu dXgubm8vc291cmNlL2FyY2gvaTM4Ni9wb3dlci9zd3N1c3AuUz92PTIuNi4xMCI+aHR0cDovL2x4 ci5saW51eC5uby9zb3VyY2UvYXJjaC9pMzg2L3Bvd2VyL3N3c3VzcC5TP3Y9Mi42LjEwPC9hPik8 L2Rpdj4KPGRpdj5TbywgbXkgd29yayB3aWxsIGJlIHNpbWlsYXIgd2l0aCBpMzg2IGltcGxlbWVu dGF0aW9uLiBBc3NlbWJseSBjb2RlIHVzZWQgaW4gaTM4NiBpbXBsZW1lbnRhdGlvbiBhcmUgc2V2 ZXJhbCBwcm9jZXNzb3IgY29udGV4dCByZWxhdGVkIGpvYjwvZGl2Pgo8ZGl2PmFuZCBjb3B5IHNh dmVkIHBhZ2UgdG8gbWVtb3J5LiBJbnN0cnVjdGlvbiB1c2VkJm5ic3A7aW4gbXkgTUlQUyZuYnNw O2ltcGxlbWVudGF0aW9uIHdpbGwgYmUgY29tcGF0aWJsZSB0byBtb3N0IG9mIE1JUFMgcHJvY2Vz c29yLjwvZGl2Pgo8ZGl2PkJlY2F1c2UgdGhlIGluc3RydWN0aW9uIHVzZWQgaW4gaW1wbGVtZW50 YXRpb24gaXMgdmVyeSBiYXNpYyAoc3RvcmUgYW5kIGxvYWQgYW5kIGJyYW5jaCkuPC9kaXY+Cjxk aXY+Jm5ic3A7PC9kaXY+CjxkaXY+SSBhZ3JlZSB5b3VyIG9waW5pb24gcmVsYXRlZCB0byBtYWlu dGFpbmFiaWxpdHkgYW5kIHJlYWRhYmlsaXR5LiBTbyBJIGltcGxlbWVudCBteSB3b3JrIHdpdGgg QyBhbmQgZmV3IGFzc2VtYmx5IGNvZGUuPC9kaXY+CjxkaXY+VGhhbmsgeW91IGZvciBhZHZpY2Uu PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTEvMS8w NywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkouIFNjb3R0IEthc3RlbjwvYj4gJmx0Ozxh IGhyZWY9Im1haWx0bzpqc2NvdHRrYXN0ZW5AeWFob28uY29tIj5qc2NvdHRrYXN0ZW5AeWFob28u Y29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9S REVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj48YnI+PGJyPk9uIFRodSwgMSBOb3YgMjAwNywgSHlv biBMaW0gd3JvdGU6PGJyPjxicj4mZ3Q7IEkgdGhpbmsgdGhlIHJlYXNvbiBvZiBhc3NlbWJseSBp bXBsZW1lbnRhdGlvbiBpcyBwcm9jZXNzb3IgY29udGV4dAo8YnI+Jmd0OyByZXBsYWNlbWVudC48 YnI+PGJyPlVuZGVyc3Rvb2QuJm5ic3A7Jm5ic3A7QXNzZW1ibHkgbWF5IGluZGVlZCBiZSByZXF1 aXJlZCBmb3Igc3BlY2lmaWMgdGhpbmdzIGxpa2U8YnI+cmVzdG9yaW5nIHJlZ2lzdGVyIHN0YXRl IG9yIGZpZGRsaW5nIHdpdGggdGhlIGNhY2hlIGlmIHRoZXJlIGFyZW4mIzM5O3Q8YnI+YWxyZWFk eSBtYWNyb3Mgb3IgZnVuY3Rpb25zIGluIHRoZSBrZXJuZWwgdGhhdCBkbyBleGFjdGx5IHdoYXQg eW91IG5lZWQuCjxicj48YnI+Jmd0OyBUaGUgc2Vjb25kIHJlYXNvbiB0aGF0IEkgdGhpbmtpbmcg aXMgY2FsbGluZyBjb252ZW50aW9uIG9mIEMgbGFuZ3VhZ2UuPGJyPjxicj5JdCYjMzk7cyBub3Qg dW5jb21tb24gYXQgYWxsIHRvIGhhdmUgYXNzZW1ibHkgbGFuZ3VhZ2UgZ2x1ZSwgc2F5IGJldHdl ZW4gYTxicj5CSU9TIGNhbGxiYWNrIGFuZCB0aGUgQyBsYW5ndWFnZSByb3V0aW5lIHRoYXQgZG9l cyB0aGUgd29yay4KPGJyPjxicj5JbiB5b3VyIG9yaWdpbmFsIHBvc3QsIHlvdSBtZW50aW9uZWQg dHJhY2tpbmcgdmFyaWFibGVzIGFuZCB0aGluZ3MgdGhhdDxicj5zdWdnZXN0ZWQgYSBtb2R1bGUg dGhhdCBkb2VzIG11Y2ggbW9yZSB0aGF0IGp1c3QgbG9hZCBzb21lIG9kZCByZWdpc3RlcnM8YnI+ b3IgZmxpcCBhcm91bmQgYSBmdW5jdGlvbiBjYWxsIHN0YWNrLiZuYnNwOyZuYnNwO0lmIHRoYXQg aXMgaW5kZWVkIHRoZSBjYXNlLCB0aGVuCjxicj5mb3Igc2FrZSBvZiBtYWludGFpbmFibGlsaXR5 IGFuZCByZWFkYWJpbGl0eSwgb25lIHdvdWxkIGJlIHN0cm9uZ2x5PGJyPmVuY291cmFnZWQgdG8g d3JpdGUgdGhlIGNvcmUgc3R1ZmYgaW4gcGxhaW4gb2xkIEMgYW5kIHNwcmlua2xlIGluIGFzc2Vt Ymx5PGJyPmdsdWUgY29kZSBhcyByZXF1aXJlZC48YnI+PGJyPlRoaW5rIGFib3V0IGl0IHRoaXMg d2F5LiZuYnNwOyZuYnNwO01JUFMgaXMgYSBwcmV0dHkgbGFyZ2UgZmFtaWx5IG9mIENQVXMsIGVh Y2ggd2l0aAo8YnI+aXQmIzM5O3Mgb3duIHN0cmFuZ2UgYmVoYXZpb3JzLiZuYnNwOyZuYnNwO1Nl dmVyYWwgb2YgdGhvc2UgcGVvcGxlIG9uIHRoaXMgbGlzdCBzcGVuZCBhPGJyPmxvdCBvZiB0aW1l IHR3ZWVraW5nIHRoYXQgYXNzZW1ibHkgdG8gbWFrZSBpdCB3b3JrIGNsZWFubHkgYWNyb3NzIHZh cmlvdXM8YnI+Q1BVcy4mbmJzcDsmbmJzcDtJdCYjMzk7cyBhIGxvdCBlYXNpZXIgdG8gdW5kZXJz dGFuZCAyNSBsaW5lcyBvZiBhc3NlbWJseSBpbnRlcmZhY2UgY29kZQo8YnI+YW5kIDIwMCBsaW5l cyBvZiBDIGNvZGUsIHRoYW4gYW4gZW50aXJlIDEwMDAgbGluZSBtb2R1bGUgd3JpdHRlbiBpbjxi cj5hc3NlbWJseS4mbmJzcDsmbmJzcDtJdCYjMzk7cyBhbHNvIGEgbG90IGVhc2llciB3aGVuIHlv dSBjYW4gc2hvdmUgbW9zdCBvZiB0aGUgd29yayBvdmVyPGJyPnRvIHRoZSBjb21waWxlciwgZXNw ZWNpYWxseSBpZiBvdGhlcnMgbGlrZSB5b3VyIHdvcmsgYW5kIHdhbnQgdG8KPGJyPmdlbmVyYWxp emUgaXQgZm9yIHVzZSBvbiBtYW55IG90aGVyIE1JUFMgQ1BVcy48YnI+PGJyPkkgZ3Vlc3MgdGhl IHJlYWwgcXVlc3Rpb24gaGVyZSBpcyBob3cgY29tcGxleCBkbyB5b3UgdGhpbmsgeW91ciBjb2Rl IG5lZWRzPGJyPnRvIGJlPyZuYnNwOyZuYnNwO1RoYXQgc2hvdWxkIGRldGVybWluZSB5b3VyIHBh dGguPGJyPjxicj5SZWdhcmRzLDxicj48YnI+LVMtPGJyPjwvYmxvY2txdW90ZT48L2Rpdj4KPGJy PjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPkh5b24gTGltICjA08f2KTxicj5Nb2JpbGUuIDAx MC04MjEyLTEyNDAgKEludGwmIzM5OyBDYWxsIDogKzgyLTEwLTgyMTItMTI0MCk8YnI+RmF4LiAw MzItMjMyLTA1NzggKEludGwmIzM5OyBBdmFpbGFibGUpPGJyPkhvbWVwYWdlIDogPGEgaHJlZj0i aHR0cDovL3d3dy5hbGV4bGFiLm5ldCI+aHR0cDovL3d3dy5hbGV4bGFiLm5ldDwvYT4KPGJyPkJs b2cgOiA8YSBocmVmPSJodHRwOi8vd3d3LmFsZXhsYWIubmV0L2Jsb2ciPmh0dHA6Ly93d3cuYWxl eGxhYi5uZXQvYmxvZzwvYT4gCg== ------=_Part_8886_6312604.1193927871785-- From jscottkasten@yahoo.com Thu Nov 1 15:00:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 15:00:45 +0000 (GMT) Received: from smtp106.plus.mail.re1.yahoo.com ([69.147.102.69]:18769 "HELO smtp106.plus.mail.re1.yahoo.com") by ftp.linux-mips.org with SMTP id S20026930AbXKAPAg (ORCPT ); Thu, 1 Nov 2007 15:00:36 +0000 Received: (qmail 10656 invoked from network); 1 Nov 2007 15:00:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type; b=EBFOrolZBocMn8McaG2ExegTffcjMVjPQ8yBhoOmjp+5S/VW/ezO8OJJDXdTppj3OrFrjZa5YzAtflIQT1lRiexg0WrMZz8Jh40oFrASs6zrzsafCtqaV8VLfNeXToPDnxSQV3lrrmg8kW2o1OSfo2R25PpJ6Lg/sIoYzYgh7xI= ; Received: from unknown (HELO ?192.168.254.6?) (jscottkasten@72.185.69.24 with login) by smtp106.plus.mail.re1.yahoo.com with SMTP; 1 Nov 2007 15:00:30 -0000 X-YMail-OSG: a_skwBwVM1lDLX9Eiw7mHFe1PhNU6DRh7hVnit2aM9C9pX21nK_b1ex0bIgsfNDPPkUtWwgTWw-- Date: Thu, 1 Nov 2007 11:00:20 -0400 (EDT) From: "J. Scott Kasten" X-X-Sender: jsk@pixie.tetracon-eng.net To: Hyon Lim cc: linux-mips@linux-mips.org Subject: Re: implementation of software suspend on MIPS. (system log) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jscottkasten@yahoo.com Precedence: bulk X-list: linux-mips On Thu, 1 Nov 2007, Hyon Lim wrote: > Thank you for comments. > The remain work of my software suspend on MIPS project is resume procedure. > I already confirmed that suspend function was work. (See my post which > contains system log). > > In an i386 implementation, there are only few assembly code for suspend and > resume procedure. > (You can refer : > http://lxr.linux.no/source/arch/i386/power/swsusp.S?v=2.6.10) > So, my work will be similar with i386 implementation. Assembly code used in > i386 implementation are several processor context related job > and copy saved page to memory. Instruction used in my MIPS implementation > will be compatible to most of MIPS processor. > Because the instruction used in implementation is very basic (store and load > and branch). > > I agree your opinion related to maintainability and readability. So I > implement my work with C and few assembly code. > Thank you for advice. > I look forward to your eventual success. :) From ralf@linux-mips.org Thu Nov 1 15:08:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 15:08:05 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:59777 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026968AbXKAPID (ORCPT ); Thu, 1 Nov 2007 15:08:03 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1F7fgx019326; Thu, 1 Nov 2007 15:07:41 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1F7fR6019325; Thu, 1 Nov 2007 15:07:41 GMT Date: Thu, 1 Nov 2007 15:07:41 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071101150741.GA8570@linux-mips.org> References: <20071101125236.GA16577@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101125236.GA16577@alpha.franken.de> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17359 X-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, Nov 01, 2007 at 01:52:36PM +0100, Thomas Bogendoerfer wrote: > PIT doesn't work, disable it completly I think this is the explanation: include/asm-mips/mach-jazz/timex.h:#define CLOCK_TICK_RATE 100 while the PIT code actually expects 1193182. Turns out that due to a recent Qemu bug which made the probe for the cp0 compare interrupt fail the Malta code did fall back from the compare timer to the i8253 PIT for the clockevent device. Works perfectly well. Ralf From ralf@linux-mips.org Thu Nov 1 15:50:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 15:50:30 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:43150 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025505AbXKAPu2 (ORCPT ); Thu, 1 Nov 2007 15:50:28 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1Fo6hK020230; Thu, 1 Nov 2007 15:50:06 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1Fo6NC020229; Thu, 1 Nov 2007 15:50:06 GMT Date: Thu, 1 Nov 2007 15:50:06 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] SNI: register a02r clockevent; don't use PIT timer Message-ID: <20071101155006.GA20176@linux-mips.org> References: <20071101103642.GA28146@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101103642.GA28146@alpha.franken.de> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17360 X-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, Nov 01, 2007 at 11:36:42AM +0100, Thomas Bogendoerfer wrote: > Register A20R clockevent > Remove PIT timer setup because it doesn't work > > Signed-off-by: Thomas Bogendoerfer Applied. Ralf From ralf@linux-mips.org Thu Nov 1 16:02:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 16:02:34 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:27068 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025665AbXKAQCc (ORCPT ); Thu, 1 Nov 2007 16:02:32 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1G2AxF020424; Thu, 1 Nov 2007 16:02:10 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1G2A3r020423; Thu, 1 Nov 2007 16:02:10 GMT Date: Thu, 1 Nov 2007 16:02:10 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071101160210.GA20366@linux-mips.org> References: <20071101125236.GA16577@alpha.franken.de> <20071101150741.GA8570@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101150741.GA8570@linux-mips.org> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17361 X-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, Nov 01, 2007 at 03:07:41PM +0000, Ralf Baechle wrote: > On Thu, Nov 01, 2007 at 01:52:36PM +0100, Thomas Bogendoerfer wrote: > > > PIT doesn't work, disable it completly > > I think this is the explanation: > > include/asm-mips/mach-jazz/timex.h:#define CLOCK_TICK_RATE 100 > > while the PIT code actually expects 1193182. > > Turns out that due to a recent Qemu bug which made the probe for the cp0 > compare interrupt fail the Malta code did fall back from the compare timer > to the i8253 PIT for the clockevent device. Works perfectly well. So I just fixed the MIPS part of the CLOCK_TICK_RATE mess which is really all over the kernel. I hope this should bring the i2853 to life for you. Could you test this? It's pretty much the only hope for Jazz to go tickless so we should try to get it to work. Unfortunately there is a locking issue lurking there as well so I need some feedback if you can get it to work. Ralf From Eckhardt@satorlaser.com Thu Nov 1 16:07:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 16:07:29 +0000 (GMT) Received: from mail.domino-printing.com ([64.212.99.82]:20488 "EHLO uk-hc-ps3.domino-printing.com") by ftp.linux-mips.org with ESMTP id S20025665AbXKAQHV convert rfc822-to-8bit (ORCPT ); Thu, 1 Nov 2007 16:07:21 +0000 Received: from emea-exchange3.emea.dps.local (unverified) by uk-hc-ps3.domino-printing.com (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Thu, 1 Nov 2007 16:22:26 +0000 Received: from tuxator2.emea.dps.local ([192.168.55.75]) by emea-exchange3.emea.dps.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 17:04:01 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips Subject: Re: [PATCH] Put cast inside macro instead of all the callers Date: Thu, 1 Nov 2007 17:04:01 +0100 User-Agent: KMail/1.9.7 References: <20071031141124.185599da@ripper.onstor.net> In-Reply-To: <20071031141124.185599da@ripper.onstor.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200711011704.01079.eckhardt@satorlaser.com> X-OriginalArrivalTime: 01 Nov 2007 16:04:01.0946 (UTC) FILETIME=[D1C087A0:01C81CA0] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips I'm by far not a MIPS expert, but I'm puzzled by the code and how it uses signed integers for addresses. I just added some comments below, but I'm not sure if they are valid. Thank you for any clarification! On Wednesday 31 October 2007, Andrew Sharp wrote: > Since all the callers of the PHYS_TO_XKPHYS macro call with a constant, > put the cast to LL inside the macro where it really should be rather > than in all the callers. This makes macros like PHYS_TO_XKSEG_UNCACHED > work without gcc whining. I'm not sure if this is always a compile-time constant so that you can adorn it with a LL. However, note that this is not a cast, a cast is at runtime. > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2) > usp = CKSEG1ADDR(sp); > #ifdef CONFIG_64BIT > - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0) && > - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0)) > - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED, > + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) && > + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0)) > + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED, > XKPHYS_TO_PHYS((long long)sp)); I'd say this code is broken in way too many aspects: 1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical address (i.e. 32 or 64 bits unsigned integer) already, so casting its result should not be necessary. 2. Using a signed integer of undefined size for an address. At least use an explicit 64 bit unsigned integer (__u64). 3. The use of signed types makes me wonder about intended overflow semantics. Just for the record, signed overflow in C causes undefined behaviour, no diagnostic required, and recent GCC even assume that no overflow occurs as an optimisation! > #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) > #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) > #define PHYS_TO_XKPHYS(cm,a) (_CONST64_(0x8000000000000000) | \ > - ((cm)<<59) | (a)) > + (_CONST64_(cm)<<59) | (a)) This macro will always(!!!) generate a negative number, is that intended? Uli - slightly puzzled - -- Sator Laser GmbH Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. ************************************************************************************** From markus.gothe@27m.se Thu Nov 1 16:46:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 16:46:15 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:31152 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20026235AbXKAQqH (ORCPT ); Thu, 1 Nov 2007 16:46:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E377C200A37F; Thu, 1 Nov 2007 17:45:35 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13672-01-60; Thu, 1 Nov 2007 17:45:35 +0100 (CET) Received: from [192.168.27.65] (6.240.216.81.static.lk.siwnet.net [81.216.240.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 80E8A200A1E8; Thu, 1 Nov 2007 17:45:35 +0100 (CET) Message-ID: <472A02AE.5060501@27m.se> Date: Thu, 01 Nov 2007 17:45:34 +0100 From: Markus Gothe User-Agent: Icedove 1.5.0.14pre (X11/20071020) MIME-Version: 1.0 To: Thiemo Seufer Cc: Hyon Lim , linux-mips@linux-mips.org Subject: Re: [SPAM] Re: MIPS assembly directives in GCC References: <20071101142625.GQ7712@networkno.de> In-Reply-To: <20071101142625.GQ7712@networkno.de> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: markus.gothe@27m.se Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thiemo Seufer wrote: > Hyon Lim wrote: >> I investigated kernel assembly source code in my kernel (2.6.10). >> I found that there are a lot of assembly directives (e.g., >> .align, .set reorder, .cpload, .frame etc.). Is there any >> documents which explains those directives? (not only I described >> above. All of directives) > > Short of reading the assembler sourcecode I believe the best > document is "See MIPS Run Linux". > > > Thiemo > Use the source Luke (or Google)... I think if you'vent got a clue about assembler (or anything else you're doing) you need to do some research before asking, that's my not so humble opinion. - -- _______________________________________ Mr Markus Gothe Software Engineer Phone: +46 (0)13 21 81 20 (ext. 1046) Fax: +46 (0)13 21 21 15 Mobile: +46 (0)73 718 72 80 Diskettgatan 11, SE-583 35 Linköping, Sweden www.27m.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKgKr6I0XmJx2NrwRCNxEAJ9S1pVnCyBRismBGVoD/lBl119l2gCg0uDy U4la1KpQWb3zAJfR/Y9Ph0U= =lSeG -----END PGP SIGNATURE----- From ralf@linux-mips.org Thu Nov 1 17:17:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 17:17:06 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:5304 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026298AbXKARRE (ORCPT ); Thu, 1 Nov 2007 17:17:04 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1HGfuH023024; Thu, 1 Nov 2007 17:16:41 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1HGeYo023023; Thu, 1 Nov 2007 17:16:40 GMT Date: Thu, 1 Nov 2007 17:16:40 +0000 From: Ralf Baechle To: Andrew Sharp Cc: linux-mips Subject: Re: [PATCH] Put cast inside macro instead of all the callers Message-ID: <20071101171640.GA21545@linux-mips.org> References: <20071031141124.185599da@ripper.onstor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071031141124.185599da@ripper.onstor.net> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17364 X-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, Oct 31, 2007 at 02:11:24PM -0700, Andrew Sharp wrote: > Resend: I tried sending this a couple of days ago but haven't seen it. > Wondering if it got stuck in a spam filter or our lovely exchange > server or something. It seems the list's spam filter has developed some appetite for patches, I'm afraid. Generally please cc me on patches. > Since all the callers of the PHYS_TO_XKPHYS macro call with a constant, > put the cast to LL inside the macro where it really should be rather > than in all the callers. This makes macros like PHYS_TO_XKSEG_UNCACHED > work without gcc whining. > > Hopefully this will apply ok. I'm afraid, no, the definition of PHYS_TO_XKPHYS did change 3 weeks ago ... Anyway, I fixed that up and queued it for 2.6.25. Thanks, Ralf From andy.sharp@onstor.com Thu Nov 1 17:23:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 17:23:37 +0000 (GMT) Received: from mail.onstor.com ([66.201.51.107]:56270 "EHLO mail.onstor.com") by ftp.linux-mips.org with ESMTP id S20026298AbXKARX2 (ORCPT ); Thu, 1 Nov 2007 17:23:28 +0000 Received: from onstor-exch02.onstor.net ([66.201.51.106]) by mail.onstor.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 10:23:00 -0700 Received: from ripper.onstor.net ([10.0.0.42]) by onstor-exch02.onstor.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 10:23:00 -0700 Date: Thu, 1 Nov 2007 10:23:00 -0700 From: Andrew Sharp To: Ulrich Eckhardt Cc: linux-mips Subject: Re: [PATCH] Put cast inside macro instead of all the callers Message-ID: <20071101102300.1db4ff6a@ripper.onstor.net> In-Reply-To: <200711011704.01079.eckhardt@satorlaser.com> References: <20071031141124.185599da@ripper.onstor.net> <200711011704.01079.eckhardt@satorlaser.com> Organization: Onstor X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2007 17:23:00.0489 (UTC) FILETIME=[DA24CF90:01C81CAB] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: andy.sharp@onstor.com Precedence: bulk X-list: linux-mips On Thu, 1 Nov 2007 17:04:01 +0100 Ulrich Eckhardt wrote: > I'm by far not a MIPS expert, but I'm puzzled by the code and how it > uses signed integers for addresses. I just added some comments below, > but I'm not sure if they are valid. Thank you for any clarification! > > On Wednesday 31 October 2007, Andrew Sharp wrote: > > Since all the callers of the PHYS_TO_XKPHYS macro call with a > > constant, put the cast to LL inside the macro where it really > > should be rather than in all the callers. This makes macros like > > PHYS_TO_XKSEG_UNCACHED work without gcc whining. > > I'm not sure if this is always a compile-time constant so that you > can adorn it with a LL. However, note that this is not a cast, a cast > is at runtime. It is always a constant. > > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2) > > usp = CKSEG1ADDR(sp); > > #ifdef CONFIG_64BIT > > - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, > > 0) && > > - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0)) > > - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED, > > + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) > > && > > + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0)) > > + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED, > > XKPHYS_TO_PHYS((long > > long)sp)); > > I'd say this code is broken in way too many aspects: > 1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical > address (i.e. 32 or 64 bits unsigned integer) already, so casting its > result should not be necessary. > 2. Using a signed integer of undefined size for an address. At least > use an explicit 64 bit unsigned integer (__u64). > 3. The use of signed types makes me wonder about intended overflow > semantics. Just for the record, signed overflow in C causes undefined > behaviour, no diagnostic required, and recent GCC even assume that no > overflow occurs as an optimisation! > > > #define PHYS_TO_XKSEG_CACHED(p) > > PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) #define > > XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) #define > > PHYS_TO_XKPHYS(cm,a) (_CONST64_(0x8000000000000000) > > | \ > > - ((cm)<<59) | (a)) > > + (_CONST64_(cm)<<59) | (a)) > > This macro will always(!!!) generate a negative number, is that > intended? Well, it's an address, not a number. Does that help? The point of the macro is to convert physical addresses to a selectable type of virtual address, of which mips has several. Cheers, a From ralf@linux-mips.org Thu Nov 1 17:47:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 17:47:31 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:19132 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026966AbXKARr3 (ORCPT ); Thu, 1 Nov 2007 17:47:29 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA1Hl6io024297; Thu, 1 Nov 2007 17:47:06 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA1Hl5Er024296; Thu, 1 Nov 2007 17:47:05 GMT Date: Thu, 1 Nov 2007 17:47:05 +0000 From: Ralf Baechle To: Ulrich Eckhardt Cc: linux-mips Subject: Re: [PATCH] Put cast inside macro instead of all the callers Message-ID: <20071101174705.GA23917@linux-mips.org> References: <20071031141124.185599da@ripper.onstor.net> <200711011704.01079.eckhardt@satorlaser.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711011704.01079.eckhardt@satorlaser.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17366 X-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, Nov 01, 2007 at 05:04:01PM +0100, Ulrich Eckhardt wrote: > I'm by far not a MIPS expert, but I'm puzzled by the code and how it uses > signed integers for addresses. I just added some comments below, but I'm not > sure if they are valid. Thank you for any clarification! When going from 32-bit to 64-bit MIPS did sign-extend register values and addresses, that is for example 0x80000000 became 0xffffffff80000000. That is the code sequence which on 32-bit is used to load the first address actually happens to load the 2nd value on a 64-bit machine. Which is an extremly elegant solution on the hardware level but at a few places software need to know. The code tries to make clever use of sign extension by the compiler to avoid multiple constants. > On Wednesday 31 October 2007, Andrew Sharp wrote: > > Since all the callers of the PHYS_TO_XKPHYS macro call with a constant, > > put the cast to LL inside the macro where it really should be rather > > than in all the callers. This makes macros like PHYS_TO_XKSEG_UNCACHED > > work without gcc whining. > > I'm not sure if this is always a compile-time constant so that you can adorn > it with a LL. However, note that this is not a cast, a cast is at runtime. No. The compiler can evaluate the cast of a constant value at compile time and that exactly is what the code is exploiting here. > > if (sp >= (long)CKSEG0 && sp < (long)CKSEG2) > > usp = CKSEG1ADDR(sp); > > #ifdef CONFIG_64BIT > > - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0) && > > - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0)) > > - usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED, > > + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) && > > + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0)) > > + usp = PHYS_TO_XKPHYS(K_CALG_UNCACHED, > > XKPHYS_TO_PHYS((long long)sp)); > > I'd say this code is broken in way too many aspects: > 1. A plethora of casts. PHYS_TO_XKPHYS() should return a physical address > (i.e. 32 or 64 bits unsigned integer) already, so casting its result should > not be necessary. No argument about the beauty of the whole thing. > 2. Using a signed integer of undefined size for an address. At least use an > explicit 64 bit unsigned integer (__u64). long long is 64-bit on Linux. > 3. The use of signed types makes me wonder about intended overflow semantics. > Just for the record, signed overflow in C causes undefined behaviour, no > diagnostic required, and recent GCC even assume that no overflow occurs as an > optimisation! There is no overflow possible here. > > #define PHYS_TO_XKSEG_CACHED(p) PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE,(p)) > > #define XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) > > #define PHYS_TO_XKPHYS(cm,a) (_CONST64_(0x8000000000000000) | \ > > - ((cm)<<59) | (a)) > > + (_CONST64_(cm)<<59) | (a)) > > This macro will always(!!!) generate a negative number, is that intended? Sort of. Most users don't care, the address is just an address for them. Note that the Linux idea of "all virtual addresses can be represented in an unsigned long" and the MIPS concept of sign extending addresses conflict at times, so sometimes addresses want to be handled with alot of care. Ralf From vda.linux@googlemail.com Thu Nov 1 18:43:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Nov 2007 18:43:44 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.184]:271 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20027316AbXKASng (ORCPT ); Thu, 1 Nov 2007 18:43:36 +0000 Received: by fk-out-0910.google.com with SMTP id f40so564445fka for ; Thu, 01 Nov 2007 11:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=jShAyuEj7pJVqlUmO4sEnwGOTNkWLTUR5mI3f0k8+cM=; b=c5Ixo1UMunXh33i4OhQ3F3V5NTR3TBL/n5usF+t0/n7HbKZIyNLFIvW9/UuAPrF4fo4QWfDfBXPFvmcgn4CL8/2QnORBFj59/e6z7peo11GynKqMgTClN2TnvZM0nEQp68p4hYcK6Aje1TGIIxk8l2D9KHpKGe+k4PbDBnHF0zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=rU/YZ5M2M3G906zkX8fSsXsVkLUNT8J25GUgkX8H2wYhU56mMK/gcA0X0roYne6XMKWHN0lISAK6eADlDqlQ8sOlNmke9YnO7WQhLPb08eDCECV8G4Yd7AT7x3UsSyHGzQ9f11lWcFrGvMxah5Jw6pJHSB0w1BR1+Y2QYVsfSRA= Received: by 10.82.138.6 with SMTP id l6mr1894008bud.1193942605675; Thu, 01 Nov 2007 11:43:25 -0700 (PDT) Received: from vda.dub.corp.google.com ( [172.28.3.151]) by mx.google.com with ESMTPS id j5sm272935gve.2007.11.01.11.43.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2007 11:43:23 -0700 (PDT) From: Denys Vlasenko To: Ralf Baechle Subject: Re: [IDE] Fix build bug Date: Thu, 1 Nov 2007 18:43:16 +0000 User-Agent: KMail/1.9.1 Cc: Bartlomiej Zolnierkiewicz , Andrew Morton , linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, linux-mips@linux-mips.org, Martijn Uffing References: <20071025135334.GA23272@linux-mips.org> <200710301134.30087.vda.linux@googlemail.com> <20071030124155.GA7582@linux-mips.org> In-Reply-To: <20071030124155.GA7582@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711011843.16894.vda.linux@googlemail.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: 17367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vda.linux@googlemail.com Precedence: bulk X-list: linux-mips On Tuesday 30 October 2007 12:41, Ralf Baechle wrote: > On Tue, Oct 30, 2007 at 11:34:29AM +0000, Denys Vlasenko wrote: > > > On Thursday 25 October 2007 22:41, Bartlomiej Zolnierkiewicz wrote: > > > > -static const struct ide_port_info generic_chipsets[] __devinitdata = { > > > > +static struct ide_port_info generic_chipsets[] __devinitdata = { > > > > /* 0 */ DECLARE_GENERIC_PCI_DEV("Unknown", 0), > > > > > > > > { /* 1 */ > > > > > > I would prefer to not remove const from generic_chipsets[] so: > > > > > > [PATCH] drivers/ide/pci/generic: fix build for CONFIG_HOTPLUG=n > > > > > > It turns out that const and __{dev}initdata cannot be mixed currently > > > and that generic IDE PCI host driver is also affected by the same issue: > > > > > > On Thursday 25 October 2007, Ralf Baechle wrote: > > > > CC drivers/ide/pci/generic.o > > > > drivers/ide/pci/generic.c:52: error: __setup_str_ide_generic_all_on causes a > > > > +section type conflict > > > > > > [ Also reported by Martijn Uffing . ] > > > > > > This patch workarounds the problem in a bit hackish way but without > > > removing const from generic_chipsets[] (it adds const to __setup() so > > > __setup_str_ide_generic_all becomes const). > > > > You wouldn't believe how much const data is not marked as const because > > we don't have __constinitdata etc. Literally megabytes. > > The gain from marking it const is very little and once any non-const > __initdata object is added to a compilation unit all other const declarations > will have to be removed. Bad tradeoff. We can intrduce new, ro sections or teach gcc that combining const objects into non-ro sections is not a crime. I wonder why it currently disallows that. (And it does it only _somethimes_, const pointers happily go into rw sections!) -- vda From veerasena_b@yahoo.co.in Fri Nov 2 05:05:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 05:05:23 +0000 (GMT) Received: from n7.bullet.mud.yahoo.com ([216.252.100.58]:29071 "HELO n7.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20023061AbXKBFFN convert rfc822-to-8bit (ORCPT ); Fri, 2 Nov 2007 05:05:13 +0000 Received: from [68.142.194.244] by n7.bullet.mud.yahoo.com with NNFMP; 02 Nov 2007 05:03:51 -0000 Received: from [209.191.119.173] by t2.bullet.mud.yahoo.com with NNFMP; 02 Nov 2007 05:03:51 -0000 Received: from [127.0.0.1] by omp104.mail.mud.yahoo.com with NNFMP; 02 Nov 2007 05:03:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 580923.52540.bm@omp104.mail.mud.yahoo.com Received: (qmail 37262 invoked by uid 60001); 2 Nov 2007 05:03:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=HYIk+tGdJDYOhaamjMBrgvatfLo9/N2VcppwpN6wyMBe6xI98kJuhtOzMrpaEVxE037ykOc8zScVXVf1Xwghq1etCxlfKHrZ/0yoiBaGmtXEoy5xbvvyXqkrHxC7x/4IqyOOWpEmtzpvx5JM5SpeS8h8rIA1tci67XEuZimnu6o=; X-YMail-OSG: zcBAlgsVM1npj70zcSTiGKcAZF7C7USAUiLvHnXTJXeIPTTwW_JswRhF_ZtVklRV94A5UehWBfeosFm8jwJCRpHyURwMNskOtDPXOpnme28Rl3Z2HZ8oMzJwk02xHg-- Received: from [199.239.167.162] by web8414.mail.in.yahoo.com via HTTP; Fri, 02 Nov 2007 10:33:49 IST X-Mailer: YahooMailRC/814.06 YahooMailWebService/0.7.134.12 Date: Fri, 2 Nov 2007 10:33:49 +0530 (IST) From: veerasena reddy Subject: NPTL support To: uclibc@uclibc.org, linux-mips , "linux-kernel.org" , buildroot@uclibc.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Message-ID: <335463.37228.qm@web8414.mail.in.yahoo.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Hi, I am trying to build the toolchain for MIPS processor using buildroot. I am using gcc version of 3.4.3, binutils-2.15, uclibc-0.9.28 and linux-2.6.18.8 kernel. Basically i need to enable NPTL feature support in my toolchain. does uclibc-0.9.28 has the support for NPTL? If not, how can i get it enabled for my above build configuration? I see there is separate branch "uclibc-nptl" in uclibc. Do i need to use this (uclibc-nptl) to meet my requirement? Could you please suggest me right approach to succssfully enable NPTL? Thanks in advance. Regards, Veerasena. Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html From kalyanatejaswi@gmail.com Fri Nov 2 05:46:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 05:46:13 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.231]:16532 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20023193AbXKBFqF (ORCPT ); Fri, 2 Nov 2007 05:46:05 +0000 Received: by qb-out-0506.google.com with SMTP id z1so273494qbc for ; Thu, 01 Nov 2007 22:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=ESk45E0fdZrR4LW8K99qDZeh08PVBIvY1L8J/z39n54=; b=jPQ0k+234Q4r1fsX3f8gB5lYOTQz0q05QgpUIDckvnRZ2lnsLCcqs7hu8hbd4c0zRwRtc4DZco5uMRtKB3R3Ek3fqOxBsaTrhgN2K0b6UQRz5QsZuPtYCWoSej56caRGsp09YV4CVoy/aKnPhvwqhbuLDNY41O76rxksvKkRQkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=H4ADIFdnY837IKbu4Lf0u52JS+TORwdLMoTjR7QVoGpXe4L4XOy1uTkqwiP+m9XLKwlt0pG4SMEmQlECCK1UY3z2+VaCKas9OXiY1fOQJc6pagbCwjOCqRHuGwON+DGxi/6Hjh6zRNSUtmaOUYS+75rNZtl7psJ2qFO/IOQ00wM= Received: by 10.115.32.1 with SMTP id k1mr1484389waj.1193982351741; Thu, 01 Nov 2007 22:45:51 -0700 (PDT) Received: by 10.114.15.18 with HTTP; Thu, 1 Nov 2007 22:45:51 -0700 (PDT) Message-ID: <9dd3c65d0711012245r4a1f2061r126d34a907b640cd@mail.gmail.com> Date: Fri, 2 Nov 2007 11:15:51 +0530 From: "kalyan tejaswi" To: linux-mips@linux-mips.org Subject: Oops with kernel 2.6.8 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14509_19194610.1193982351721" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kalyanatejaswi@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_14509_19194610.1193982351721 Content-Type: multipart/alternative; boundary="----=_Part_14510_12367395.1193982351721" ------=_Part_14510_12367395.1193982351721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I am using Malta-4Kc with kernel 2.6.8(from linux-mips.org) compiled with gcc 3.4.4. I can not boot over NFS. The console log is attached. Any hints are greatly appreciated. Regards Kalyan ------=_Part_14510_12367395.1193982351721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
I am using Malta-4Kc with kernel 2.6.8(from linux-mips.org) compiled with gcc 3.4.4.
 
I can not boot over NFS.
 
The console log is attached.
 
Any hints are greatly appreciated.
 
 
Regards
Kalyan
------=_Part_14510_12367395.1193982351721-- ------=_Part_14509_19194610.1193982351721 Content-Type: text/plain; name=console-log.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_f8ia8m9o Content-Disposition: attachment; filename=console-log.txt c2V0DQoNCmJhc2Vib2FyZHNlcmlhbCAoUk8pICAgMDAwMDAwMDU1NA0KYm9vdGZpbGUgICAgICAg IChSL1cpICB2bWxpbnV4LnNyZWMNCmJvb3Rwcm90ICAgICAgICAoUi9XKSAgdGZ0cA0KYm9vdHNl cnBvcnQgICAgIChSL1cpICB0dHkwDQpib290c2VydmVyICAgICAgKFIvVykgIDEwLjEuMS41OA0K Y3B1Y29uZmlnICAgICAgIChSL1cpDQpldGhhZGRyICAgICAgICAgKFJPKSAgIDAwLmQwLmEwLjAw LjAzLjIyDQpmaWxlICAgICAgICAgICAgKFVTRVIpIHZtbGludXguc3JlYy1XVVNBR0ktV0lQSVAt QVRNLUVWNg0KZ2F0ZXdheSAgICAgICAgIChSL1cpICAxMC4xLjEuNTgNCmdkYiAgICAgICAgICAg ICAoVVNFUikgZ2Rid2FpdCBnZGI4MjUwPTAgMzg0MDANCmlwICAgICAgICAgICAgICAoVVNFUikg MTAuMS4xLjEwMDoxMC4xLjEuNTg6MTAuMS4xLjU4OjI1NS4wLjAuMDptYWx0YTpldGgwOm9mZg0K aXBfbmV3ICAgICAgICAgIChVU0VSKSAxMC4xLjEuMTAwOjEwLjEuMS41NzoxMC4xLjEuNTc6MjU1 LjAuMC4wOm1hbHRhOmV0aDA6b2ZmDQppcF9uZXcxICAgICAgICAgKFVTRVIpIDEwLjEuMS4xMDA6 MTAuMS4xLjU4OjEwLjEuMS41ODoyNTUuMC4wLjA6bWFsdGE6ZXRoMDpvZmYNCmlwX29sZCAgICAg ICAgICAoVVNFUikgMjAuMS4xLjEwMDoyMC4xLjEuNTg6MjAuMS4xLjU4OjI1NS4wLjAuMDptYWx0 YTpldGgwOm9mZg0KaXBhZGRyICAgICAgICAgIChSL1cpICAxMC4xLjEuMTAwDQptZW1zaXplICAg ICAgICAgKFJPKSAgIDB4MDQwMDAwMDANCm1vZGV0dHkwICAgICAgICAoUi9XKSAgMzg0MDAsbiw4 LDEsaHcNCm1vZGV0dHkxICAgICAgICAoUi9XKSAgMzg0MDAsbiw4LDEsaHcNCm5ld3Jvb3QgICAg ICAgICAoVVNFUikgL3Jvb3Qva2lzaG9yZS9seGRiMjYNCm5ld3Jvb3QtdGVtcCAgICAoVVNFUikg L2hvbWUvamVldGVuZHIvcm9vdF9maWxlc3lzdGVtLTEuMy00aw0KbmV3cm9vdDEgICAgICAgIChV U0VSKSAvaG9tZS9qZWV0ZW5kci9yb290NEsNClByZXNzIGFueSBrZXkgKEN0cmwtQyB0byBicmVh aywgRW50ZXIgdG8gc2luZ2xlc3RlcCkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgIICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAhuZXdyb290MiAgICAgICAgKFVTRVIpIC9yb290L2thbHlhbi9yb290X2ZpbGVzeXN0 ZW0NClByZXNzIGFueSBrZXkgKEN0cmwtQyB0byBicmVhaywgRW50ZXIgdG8gc2luZ2xlc3RlcCkI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAhuZXdyb290MyAgICAgICAg KFVTRVIpIC9yb290L2tpc2hvcmUvcm9vdF9maWxlc3lzdGVtLTRLDQpQcmVzcyBhbnkga2V5IChD dHJsLUMgdG8gYnJlYWssIEVudGVyIHRvIHNpbmdsZXN0ZXApCAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgIbmV3cm9vdDQgICAgICAgIChVU0VSKSAvcm9vdC9raXNob3Jl L2x4ZGItMS0yLWxmcw0KUHJlc3MgYW55IGtleSAoQ3RybC1DIHRvIGJyZWFrLCBFbnRlciB0byBz aW5nbGVzdGVwKQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICG5mc3Jv b3QgICAgICAgICAoVVNFUikgL3Jvb3Qva2lzaG9yZS9seGRiLTEtMi11c2VyLWxmcw0KUHJlc3Mg YW55IGtleSAoQ3RybC1DIHRvIGJyZWFrLCBFbnRlciB0byBzaW5nbGVzdGVwKQgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAggICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICHByb21wdCAgICAgICAgICAoUi9XKSAgWUFN T04tNEsNClByZXNzIGFueSBrZXkgKEN0cmwtQyB0byBicmVhaywgRW50ZXIgdG8gc2luZ2xlc3Rl cCkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAhyb290cGF0aCAgICAg ICAgKFVTRVIpIC9yb290L2tpc2hvcmUvcjEtYWxwaGEtcm9vdGZzDQpQcmVzcyBhbnkga2V5IChD dHJsLUMgdG8gYnJlYWssIEVudGVyIHRvIHNpbmdsZXN0ZXApCAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgIc2VydmVyICAgICAgICAgIChVU0VSKSAxMC4xLjEuNTgNClBy ZXNzIGFueSBrZXkgKEN0cmwtQyB0byBicmVhaywgRW50ZXIgdG8gc2luZ2xlc3RlcCkICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAhzdGFydCAgICAgICAgICAgKFIvVykg IGxvYWQ7IGdvIC4gaXA9JGlwIHJvb3Q9L2Rldi9uZnMgbmZzcm9vdD0kbmV3cm9vdCBwYW5pYz0x DQpQcmVzcyBhbnkga2V5IChDdHJsLUMgdG8gYnJlYWssIEVudGVyIHRvIHNpbmdsZXN0ZXApCAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIc3RhcnRfb2xkICAgICAgIChV U0VSKSBsb2FkOyBnbyAuIGlwPSRpcCByb290PS9kZXYvbmZzIG5mc3Jvb3Q9JHJvb3RwYXRoDQpQ cmVzcyBhbnkga2V5IChDdHJsLUMgdG8gYnJlYWssIEVudGVyIHRvIHNpbmdsZXN0ZXApCAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIc3VibmV0bWFzayAgICAgIChSL1cp ICAyNTUuMjU1LjI1NS4wDQpQcmVzcyBhbnkga2V5IChDdHJsLUMgdG8gYnJlYWssIEVudGVyIHRv IHNpbmdsZXN0ZXApCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIeWFt b25yZXYgICAgICAgIChSTykgICAwMi4wMg0KUHJlc3MgYW55IGtleSAoQ3RybC1DIHRvIGJyZWFr LCBFbnRlciB0byBzaW5nbGVzdGVwKQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICAgICAgICAgICAggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI CAgICAgICA0KWUFNT04tNEs+IA0KWUFNT04tNEs+IGxvYWQ7IGdvIC4gaXA9JGlwIHJvb3Q9L2Rl di9uZnMgbmZzcm9vdD0kbmV3cm9vdC10ZW1wDQpBYm91dCB0byBsb2FkIHRmdHA6Ly8xMC4xLjEu NTgvdm1saW51eC5zcmVjDQpQcmVzcyBDdHJsLUMgdG8gYnJlYWsNCi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4NCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4NCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4NCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KU3RhcnQgPSAweDgw MzBkMDE4LCByYW5nZSA9ICgweDgwMTAwMDAwLDB4ODAzMjkwODUpLCBmb3JtYXQgPSBTUkVDDQoN CkxJTlVYIHN0YXJ0ZWQuLi4NCkNvbmZpZyBzZXJpYWwgY29uc29sZTogY29uc29sZT10dHlTMCwz ODQwMG44cg0KTGludXggdmVyc2lvbiAyLjYuOCAoa2FseWFuQGx4ZGIwMikgKGdjYyB2ZXJzaW9u IDMuNC40IDIwMDUwMTE5IChNSVBTIFNERSkpICM5IEZyaSBOb3YgMiAwOToyNjozMiBJU1QgMjAw Nw0KQ1BVIHJldmlzaW9uIGlzOiAwMDAxODAwNQ0KRGV0ZXJtaW5lZCBwaHlzaWNhbCBSQU0gbWFw Og0KIG1lbW9yeTogMDAwMDEwMDAgQCAwMDAwMDAwMCAocmVzZXJ2ZWQpDQogbWVtb3J5OiAwMDBl ZjAwMCBAIDAwMDAxMDAwIChST00gZGF0YSkNCiBtZW1vcnk6IDAwMjUxMDAwIEAgMDAwZjAwMDAg KHJlc2VydmVkKQ0KIG1lbW9yeTogMDNjYmYwMDAgQCAwMDM0MTAwMCAodXNhYmxlKQ0KQnVpbHQg MSB6b25lbGlzdHMNCktlcm5lbCBjb21tYW5kIGxpbmU6IGlwPTEwLjEuMS4xMDA6MTAuMS4xLjU4 OjEwLjEuMS41ODoyNTUuMC4wLjA6bWFsdGE6ZXRoMDpvZmYgcm9vdD0vZGV2L25mcyBuZnNyb290 PS9ob21lL2plZXRlbmRyL3Jvb3RfZmlsZXN5c3RlbS0xLjMtNGsgY29uc29sZT10dHlTMCwzODQw MG44cg0KUHJpbWFyeSBpbnN0cnVjdGlvbiBjYWNoZSAxNmtCLCBwaHlzaWNhbGx5IHRhZ2dlZCwg NC13YXksIGxpbmVzaXplIDE2IGJ5dGVzLg0KUHJpbWFyeSBkYXRhIGNhY2hlIDE2a0IgNC13YXks IGxpbmVzaXplIDE2IGJ5dGVzLg0KUElEIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlciA5 OiA0MDk2IGJ5dGVzKQ0KQ1BVIGZyZXF1ZW5jeSAxMjUuMDEgTUh6DQpVc2luZyA2Mi41MDYgTUh6 IGhpZ2ggcHJlY2lzaW9uIHRpbWVyLg0KRGVudHJ5IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczog MTYzODQgKG9yZGVyOiA0LCA2NTUzNiBieXRlcykNCklub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50 cmllczogODE5MiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0KTWVtb3J5OiA2MTQ4OGsvNjIyMDRr IGF2YWlsYWJsZSAoMTYxOWsga2VybmVsIGNvZGUsIDYzMmsgcmVzZXJ2ZWQsIDQ3NmsgZGF0YSwg MTE2ayBpbml0LCAwayBoaWdobWVtKQ0KQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcC4uLiAxMjMuMzkg Qm9nb01JUFMNCk1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50cmllczogNTEyIChvcmRlcjogMCwg NDA5NiBieXRlcykNCkNoZWNraW5nIGZvciAnd2FpdCcgaW5zdHJ1Y3Rpb24uLi4gIGF2YWlsYWJs ZS4NCkNQVSAwIFVuYWJsZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IHZpcnR1 YWwgYWRkcmVzcyAwMDAwMDAxNCwgZXBjID09IDgwMTcyMTI4LCByYSA9PSA4MDE3MjEzMA0KT29w cyBpbiBhcmNoL21pcHMvbW0vZmF1bHQuYzo6ZG9fcGFnZV9mYXVsdCwgbGluZSAxNjdbIzFdOg0K Q3B1IDANCiQgMCAgIDogMDAwMDAwMDAgMTAwMGZjMDAgMDAwMDAwMDAgODAyYzIwMDANCiQgNCAg IDogODAyYzIwMDAgODNmYzE4NmMgMDAwMDAwMDAgODAxNjNkODANCiQgOCAgIDogMDAwMDAwMDgg ODAxZGFlMjggMDAwMDA4YWMgMDAwMDAwMDANCiQxMiAgIDogODAzMzAwMDAgMDAwMDAwMDAgODAz MmMyNTcgMDAwMDAwMGENCiQxNiAgIDogMDAwMDAwMDAgODNmYzE5MDAgODNmYzE4NmMgZmZmZmZm ZTkNCiQyMCAgIDogMDAwMDAwMDAgMDAwMDAwMDAgODAzMzAwMDAgMDAwMDAwMDANCiQyNCAgIDog MDAwMDAwMDAgODAzMmM2MjMgICAgICAgICAgICAgICAgICANCiQyOCAgIDogODAyYmUwMDAgODAy YmZlNDggODAwOWUzNzAgODAxNzIxMzANCkhpICAgIDogMDAwMDAwMDANCkxvICAgIDogMDAwMDA4 YWMNCmVwYyAgIDogODAxNzIxMjggZG9fcGlwZSsweDU4LzB4MzIwICAgICBOb3QgdGFpbnRlZA0K cmEgICAgOiA4MDE3MjEzMCBkb19waXBlKzB4NjAvMHgzMjANClN0YXR1czogMTAwMGZjMDMgICAg S0VSTkVMIEVYTCBJRSANCkNhdXNlIDogOTA4MDAwMDgNCkJhZFZBIDogODNmYzE5MDANClBySWQg IDogMDAwMTgwMDUNCk1vZHVsZXMgbGlua2VkIGluOg0KUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAs IHRocmVhZGluZm89ODAyYmUwMDAsIHRhc2s9ODAyYzIwMDApDQpTdGFjayA6IDgwMzMwMDAwIDAw MDAwMDAwIDgwMzJjMjU3IDAwMDAwMDBhIDAwNDE4OTM3IDAwMDAyNmI1IDgwMzM0MjU0IDAwNDE4 OTM3DQogICAgICAgIDAwMDAwMDYwIDgwMmMwMDAwIDgwMzJjYjZmIDAwMDAwMDYwIDAwMDAwMDAw IDgwMzJjNjIzIDEwMDBmYzAzIGIyMmNjNzAwDQogICAgICAgIDAwMDAwMDAwIDgwMTAwNDVjIDAw ODAwYjAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQogICAg ICAgIDgwMDllMzcwIDgwMTA3MmZjIDgwMmJmZWMwIDgzZmZmMzQwIDgwMmNiM2NjIDAwMDAwNTAx IDAwMDAwMDBjIDAwMDAwMDA4DQogICAgICAgIDgwMTBiM2U4IDgwMmMwMDAwIDAwODAwYjAwIDAw MDAwMDAwIDgwMmJmZjgwIDAwMDAwMDFkIDgwMmMwMDAwIDgwMmMwMDAwDQogICAgICAgIC4uLg0K Q2FsbCBUcmFjZToNCiBbPDgwMTAwNDVjPl0gaW5pdCsweDAvMHgyNTQNCiBbPDgwMTA3MmZjPl0g c3lzX3BpcGUrMHgyNC8weDQ4DQogWzw4MDEwYjNlOD5dIHN0YWNrX2RvbmUrMHgyNC8weDQwDQog Wzw4MDEyODNjOD5dIHJlbGVhc2VfY29uc29sZV9zZW0rMHgxMjAvMHgzMTQNCiBbPDgwMTI4NGQw Pl0gcmVsZWFzZV9jb25zb2xlX3NlbSsweDIyOC8weDMxNA0KIFs8ODAxMDA0NWM+XSBpbml0KzB4 MC8weDI1NA0KIFs8ODAxMDA0MWM+XSByZXN0X2luaXQrMHgxYy8weDI4DQogWzw4MDEwNTQ4Yz5d IGtlcm5lbF90aHJlYWQrMHgzOC8weDdjDQogWzw4MDEwMDQxYz5dIHJlc3RfaW5pdCsweDFjLzB4 MjgNCiBbPDgwMzBkODFjPl0gc3RhcnRfa2VybmVsKzB4MWIwLzB4MWQ4DQogWzw4MDMwZDgxND5d IHN0YXJ0X2tlcm5lbCsweDFhOC8weDFkOA0KIFs8ODAzMGQyNGM+XSB1bmtub3duX2Jvb3RvcHRp b24rMHgwLzB4MjgwDQogWzw4MDMwZDA4Yz5dIG5vc21wKzB4MC8weDEwDQoNCg0KQ29kZTogMDA0 MDkwMjEgIDNjMTY4MDMzICA4ZWMyMzA1MCA8MGMwNWZmYjA+IDhjNDQwMDE0ICAxMDQwMDA5YiAg MDA0MDgwMjEgIDBjMDVjODAxICAwMDQwMjAyMSANCktlcm5lbCBwYW5pYzogQXR0ZW1wdGVkIHRv IGtpbGwgdGhlIGlkbGUgdGFzayENCkluIGlkbGUgdGFzayAtIG5vdCBzeW5jaW5nDQog ------=_Part_14509_19194610.1193982351721-- From Eckhardt@satorlaser.com Fri Nov 2 08:07:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 08:07:40 +0000 (GMT) Received: from mail.domino-printing.com ([64.212.99.82]:1804 "EHLO uk-hc-ps3.domino-printing.com") by ftp.linux-mips.org with ESMTP id S20027284AbXKBIHb convert rfc822-to-8bit (ORCPT ); Fri, 2 Nov 2007 08:07:31 +0000 Received: from emea-exchange3.emea.dps.local (emea-exchange3.emea.dps.local) by uk-hc-ps3.domino-printing.com (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Fri, 2 Nov 2007 08:22:39 +0000 Received: from tuxator2.emea.dps.local ([192.168.55.75]) by emea-exchange3.emea.dps.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 09:06:01 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips Subject: Re: [PATCH] Put cast inside macro instead of all the callers Date: Fri, 2 Nov 2007 09:06:00 +0100 User-Agent: KMail/1.9.7 References: <20071031141124.185599da@ripper.onstor.net> <200711011704.01079.eckhardt@satorlaser.com> In-Reply-To: <200711011704.01079.eckhardt@satorlaser.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200711020906.00670.eckhardt@satorlaser.com> X-OriginalArrivalTime: 02 Nov 2007 08:06:01.0424 (UTC) FILETIME=[353DED00:01C81D27] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips On Thursday 01 November 2007, Ulrich Eckhardt wrote: [...] > - slightly puzzled - Andrew, Ralf, thanks for the clarifications! Uli -- Sator Laser GmbH Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. ************************************************************************************** From tsbogend@alpha.franken.de Fri Nov 2 10:20:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 10:20:45 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:5065 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20029200AbXKBKUg (ORCPT ); Fri, 2 Nov 2007 10:20:36 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Intag-0005et-00; Fri, 02 Nov 2007 11:17:26 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id F360ADF2E2; Fri, 2 Nov 2007 11:17:13 +0100 (CET) Date: Fri, 2 Nov 2007 11:17:13 +0100 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071102101713.GA9110@alpha.franken.de> References: <20071101125236.GA16577@alpha.franken.de> <20071101150741.GA8570@linux-mips.org> <20071101160210.GA20366@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101160210.GA20366@linux-mips.org> User-Agent: Mutt/1.5.13 (2006-08-11) From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Thu, Nov 01, 2007 at 04:02:10PM +0000, Ralf Baechle wrote: > all over the kernel. I hope this should bring the i2853 to life for you. it does now, even pit clockevent works now (if you apply the patch below). Thomas. Fix ISA irq acknowledge make r4030 clockevent code look like other mips clockevent code Signed-off-by: Thomas Bogendoerfer --- diff --git a/arch/mips/jazz/irq.c b/arch/mips/jazz/irq.c index ae25b48..d7f8a78 100644 --- a/arch/mips/jazz/irq.c +++ b/arch/mips/jazz/irq.c @@ -97,9 +97,10 @@ asmlinkage void plat_irq_dispatch(void) if (pending & IE_IRQ4) { r4030_read_reg32(JAZZ_TIMER_REGISTER); do_IRQ(JAZZ_TIMER_IRQ); - } else if (pending & IE_IRQ2) - do_IRQ(r4030_read_reg32(JAZZ_EISA_IRQ_ACK)); - else if (pending & IE_IRQ1) { + } else if (pending & IE_IRQ2) { + irq = *(volatile u8 *)JAZZ_EISA_IRQ_ACK; + do_IRQ(irq); + } else if (pending & IE_IRQ1) { irq = *(volatile u8 *)JAZZ_IO_IRQ_SOURCE >> 2; if (likely(irq > 0)) do_IRQ(irq + JAZZ_IRQ_START - 1); @@ -117,16 +118,16 @@ static void r4030_set_mode(enum clock_event_mode mode, struct clock_event_device r4030_clockevent = { .name = "r4030", .features = CLOCK_EVT_FEAT_PERIODIC, - .rating = 100, + .rating = 300, .irq = JAZZ_TIMER_IRQ, - .cpumask = CPU_MASK_CPU0, .set_mode = r4030_set_mode, }; static irqreturn_t r4030_timer_interrupt(int irq, void *dev_id) { - r4030_clockevent.event_handler(&r4030_clockevent); + struct clock_event_device *cd = dev_id; + cd->event_handler(cd); return IRQ_HANDLED; } @@ -134,15 +135,22 @@ static struct irqaction r4030_timer_irqaction = { .handler = r4030_timer_interrupt, .flags = IRQF_DISABLED, .mask = CPU_MASK_CPU0, - .name = "timer", + .name = "R4030 timer", }; void __init plat_time_init(void) { - struct irqaction *irq = &r4030_timer_irqaction; + struct clock_event_device *cd = &r4030_clockevent; + struct irqaction *action = &r4030_timer_irqaction; + unsigned int cpu = smp_processor_id(); BUG_ON(HZ != 100); + cd->cpumask = cpumask_of_cpu(cpu); + clockevents_register_device(cd); + action->dev_id = cd; + setup_irq(JAZZ_TIMER_IRQ, action); + /* * Set clock to 100Hz. * @@ -150,8 +158,5 @@ void __init plat_time_init(void) * a programmable 4-bit divider. This makes it fairly inflexible. */ r4030_write_reg32(JAZZ_TIMER_INTERVAL, 9); - setup_irq(JAZZ_TIMER_IRQ, irq); - - clockevents_register_device(&r4030_clockevent); setup_pit_timer(); } -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From ralf@linux-mips.org Fri Nov 2 12:20:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 12:20:33 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:59537 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030372AbXKBMUb (ORCPT ); Fri, 2 Nov 2007 12:20:31 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA2CK1O5013812; Fri, 2 Nov 2007 12:20:01 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA2CK1Xl013811; Fri, 2 Nov 2007 12:20:01 GMT Date: Fri, 2 Nov 2007 12:20:01 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071102122001.GC22829@linux-mips.org> References: <20071101125236.GA16577@alpha.franken.de> <20071101150741.GA8570@linux-mips.org> <20071101160210.GA20366@linux-mips.org> <20071102101713.GA9110@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071102101713.GA9110@alpha.franken.de> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17372 X-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, Nov 02, 2007 at 11:17:13AM +0100, Thomas Bogendoerfer wrote: > On Thu, Nov 01, 2007 at 04:02:10PM +0000, Ralf Baechle wrote: > > all over the kernel. I hope this should bring the i2853 to life for you. > > it does now, even pit clockevent works now (if you apply the patch > below). Applied, thanks, One thing I'm still wondering about, does the kernel actually go tickless for you? Ralf From markus.gothe@27m.se Fri Nov 2 12:32:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 12:32:34 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:16356 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20030379AbXKBMcY (ORCPT ); Fri, 2 Nov 2007 12:32:24 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 04AE2200A231; Fri, 2 Nov 2007 13:31:54 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17478-01-12; Fri, 2 Nov 2007 13:31:53 +0100 (CET) Received: from [10.101.1.157] (nsabfw1.nsab.se [217.28.34.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 2A114200A22C; Fri, 2 Nov 2007 13:31:50 +0100 (CET) In-Reply-To: <335463.37228.qm@web8414.mail.in.yahoo.com> References: <335463.37228.qm@web8414.mail.in.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-951137529" Message-Id: Cc: uclibc@uclibc.org, linux-mips , "linux-kernel.org" , buildroot@uclibc.org Content-Transfer-Encoding: 7bit From: Markus Gothe Subject: Re: NPTL support Date: Fri, 2 Nov 2007 13:31:41 +0100 To: veerasena reddy X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: markus.gothe@27m.se Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-951137529 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed You'll have to use the uClibc-nptl branch on their svn. In 0.9.28, no. //Markus On 2 Nov 2007, at 06:03, veerasena reddy wrote: > Hi, > > I am trying to build the toolchain for MIPS processor using buildroot. > I am using gcc version of 3.4.3, binutils-2.15, uclibc-0.9.28 and =20 > linux-2.6.18.8 kernel. > > Basically i need to enable NPTL feature support in my toolchain. > does uclibc-0.9.28 has the support for NPTL? > If not, how can i get it enabled for my above build configuration? > > I see there is separate branch "uclibc-nptl" in uclibc. > Do i need to use this (uclibc-nptl) to meet my requirement? > > Could you please suggest me right approach to succssfully enable NPTL? > > Thanks in advance. > > Regards, > Veerasena. > > > Why delete messages? Unlimited storage is just a click away. =20 > Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/=20 > tools-08.html > > _______________________________________ Mr Markus Gothe Software Engineer Phone: +46 (0)13 21 81 20 (ext. 1046) Fax: +46 (0)13 21 21 15 Mobile: +46 (0)73 718 72 80 Diskettgatan 11, SE-583 35 Link=F6ping, Sweden www.27m.com --Apple-Mail-1-951137529 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHKxiu6I0XmJx2NrwRAmL9AKC+UJvmi+faIw8jv2mTgX02lQ0SVQCgojMj eb6d+5dvclZWIzioxljUx9A= =PoSc -----END PGP SIGNATURE----- --Apple-Mail-1-951137529-- From ralf@linux-mips.org Fri Nov 2 12:35:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 12:35:07 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:14787 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030383AbXKBMfF (ORCPT ); Fri, 2 Nov 2007 12:35:05 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA2CYWOH014169; Fri, 2 Nov 2007 12:34:32 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA2CYUP8014168; Fri, 2 Nov 2007 12:34:30 GMT Date: Fri, 2 Nov 2007 12:34:30 +0000 From: Ralf Baechle To: Denys Vlasenko Cc: Bartlomiej Zolnierkiewicz , Andrew Morton , linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, linux-mips@linux-mips.org, Martijn Uffing Subject: Re: [IDE] Fix build bug Message-ID: <20071102123428.GA14106@linux-mips.org> References: <20071025135334.GA23272@linux-mips.org> <200710301134.30087.vda.linux@googlemail.com> <20071030124155.GA7582@linux-mips.org> <200711011843.16894.vda.linux@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200711011843.16894.vda.linux@googlemail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17374 X-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, Nov 01, 2007 at 06:43:16PM +0000, Denys Vlasenko wrote: > We can intrduce new, ro sections or teach gcc that combining const objects into > non-ro sections is not a crime. I wonder why it currently disallows that. > (And it does it only _somethimes_, const pointers happily go into rw sections!) The pattern seems to be that const-ness of the first object placed into a particular section determines the writability of that section. If that conflicts with the requirements for a later object such as a non-const object into a section r/o gcc doesn't consider making the section r/w but throws an error instead. Ralf From ralf@linux-mips.org Fri Nov 2 12:58:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 12:58:26 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:9447 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20030414AbXKBM6X (ORCPT ); Fri, 2 Nov 2007 12:58:23 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA2CvsEu014497; Fri, 2 Nov 2007 12:57:54 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA2Cvr69014496; Fri, 2 Nov 2007 12:57:53 GMT Date: Fri, 2 Nov 2007 12:57:53 +0000 From: Ralf Baechle To: kalyan tejaswi Cc: linux-mips@linux-mips.org Subject: Re: Oops with kernel 2.6.8 Message-ID: <20071102125753.GB14106@linux-mips.org> References: <9dd3c65d0711012245r4a1f2061r126d34a907b640cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9dd3c65d0711012245r4a1f2061r126d34a907b640cd@mail.gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17375 X-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, Nov 02, 2007 at 11:15:51AM +0530, kalyan tejaswi wrote: > Hi all, > I am using Malta-4Kc with kernel 2.6.8(from linux-mips.org) compiled with > gcc 3.4.4. > > I can not boot over NFS. > > The console log is attached. > > Any hints are greatly appreciated. 2.6.8 is really old, over 3 years now. So forgive if memory of the bugs in that kernel is fading. I think the one you're seeing was was caused by memory prefetching beyond the end of memory. The easy fix is to disable prefetching. See a modern memcpy for how to do that. There are several other interesting issues hidden in 2.6.8 so I think you really should upgrade. Ralf From anemo@mba.ocn.ne.jp Fri Nov 2 16:44:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 16:45:09 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:32458 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20030140AbXKBQo7 (ORCPT ); Fri, 2 Nov 2007 16:44:59 +0000 Received: from localhost (p3147-ipad212funabasi.chiba.ocn.ne.jp [58.91.167.147]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 2723C9FB6; Sat, 3 Nov 2007 01:44:48 +0900 (JST) Date: Sat, 03 Nov 2007 01:46:49 +0900 (JST) Message-Id: <20071103.014649.122254137.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: WAIT vs. tickless kernel From: Atsushi Nemoto In-Reply-To: <20071031163900.GB22871@linux-mips.org> References: <20071031161333.GA22871@linux-mips.org> <20071101.013124.108121433.anemo@mba.ocn.ne.jp> <20071031163900.GB22871@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 5.2 on Emacs 21.4 / 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: 17376 X-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 Wed, 31 Oct 2007 16:39:00 +0000, Ralf Baechle wrote: > > > The only safe but ugly workaround is to change the return from exception > > > code to detect if the EPC is in the range startin from the condition > > > check in the idle loop to including the WAIT instruction and if so to > > > patch the EPC to resume execution at the condition check or the > > > instruction following the WAIT. > > > > I'm also thinking of this approach. Still wondering if it is worth to > > implement. > > The tickless kernel is very interesting for the low power fraction. And > it's especially those users who would suffer most the loss of the ability > to use the WAIT instruction. For a system running from two AAA cells the > tradeoff is clear ... So I think it's become a must. Then, something like this? Selecting in build-time is not so good, but there are some CPUs which do not need this hack at all. Synthesizing the ret_from_irq() at runtime might satisfy everyone? diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index c8c47a2..621130c 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -51,12 +51,17 @@ static void r39xx_wait(void) * But it is implementation-dependent wheter the pipelie restarts when * a non-enabled interrupt is requested. */ +#ifdef CONFIG_ROLLBACK_CPU_WAIT +extern void cpu_wait_rollback(void); +#define r4k_wait cpu_wait_rollback +#else static void r4k_wait(void) { __asm__(" .set mips3 \n" " wait \n" " .set mips0 \n"); } +#endif /* * This variant is preferable as it allows testing need_resched and going to diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S index e29598a..ffa043c 100644 --- a/arch/mips/kernel/entry.S +++ b/arch/mips/kernel/entry.S @@ -27,6 +27,20 @@ #endif .text +#ifdef CONFIG_ROLLBACK_CPU_WAIT + .align 6 +FEXPORT(cpu_wait_rollback) + LONG_L t0, TI_FLAGS($28) + andi t0, _TIF_NEED_RESCHED + bnez t0, 1f + .set mips3 + wait + .set mips0 +1: + jr ra + .align 6 +cpu_wait_rollback_end: +#endif .align 5 #ifndef CONFIG_PREEMPT FEXPORT(ret_from_exception) @@ -35,6 +49,14 @@ FEXPORT(ret_from_exception) #endif FEXPORT(ret_from_irq) LONG_S s0, TI_REGS($28) +#ifdef CONFIG_ROLLBACK_CPU_WAIT + LONG_L t0, PT_EPC(sp) + ori t0, 0x3f + xori t0, 0x3f + PTR_LA t1, cpu_wait_rollback + bne t0, t1, __ret_from_irq + LONG_S t0, PT_EPC(sp) # return to cpu_wait_rollback +#endif FEXPORT(__ret_from_irq) LONG_L t0, PT_STATUS(sp) # returning to kernel mode? andi t0, t0, KU_USER From alex@alexlab.net Fri Nov 2 17:26:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 17:26:45 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.180]:45031 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20030228AbXKBR0g (ORCPT ); Fri, 2 Nov 2007 17:26:36 +0000 Received: by py-out-1112.google.com with SMTP id p76so1687826pyb for ; Fri, 02 Nov 2007 10:26:24 -0700 (PDT) Received: by 10.65.239.14 with SMTP id q14mr6869495qbr.1194024383114; Fri, 02 Nov 2007 10:26:23 -0700 (PDT) Received: by 10.65.123.7 with HTTP; Fri, 2 Nov 2007 10:26:23 -0700 (PDT) Message-ID: Date: Sat, 3 Nov 2007 02:26:23 +0900 From: "Hyon Lim" To: linux-mips@linux-mips.org Subject: First implementation is done. (software suspend on MIPS) MIME-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17377 X-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@alexlab.net Precedence: bulk X-list: linux-mips Rmlyc3QgaW1wbGVtZW50YXRpb24gaXMgZG9uZS4KTXkgd29yayBpbmNsdWRlcyAiY3B1LmMsIHN3 c3VzcC5TIiB3aGljaCBpcyBsb2NhdGVkIG9uCmFyY2gvbWlwcy94eHgvcG93ZXIuICh4eHggaXMg eW91ciBzcGVjaWZpYyBhcmNoaXRlY3R1cmUpCkJ1dCwgcHJvYmxlbSBzdGlsbCBleGlzdC4gV2hl biBzeXN0ZW0gcmVzdW1lZCwga2VybmVsIHBhbmljIGlzCm9jY3VyZWQuIChTZWUgYmVsb3cpCkkg dGhpbmsgdGhhdCBwcm9ibGVtIGlzIG9jY3VyZWQgYnkgbWlzc2luZyBjb250ZXh0LiAoSSBzYXZl ZCBvbmx5IGZldyByZWdpc3RlcikKUGxlYXNlIHdhdGNoIG15IGNvZGUgYW5kIHBsZWFzZSBjb21t ZW50IG15IG1pc3Rha2UuCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0Kc3dzdXNwLlMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci50ZXh0CgovKgogKiBTdXNwZW5kIHN1cHBvcnQgZm9yIE1JUFMuCiAq CiAqIERpc3RyaWJ1dGUgdW5kZXIgR1BMdjIKICoKICogQ29weXJpZ2h0IChjKSAyMDA3IEh5b24g TGltIDxhbGV4QGFsZXhsYWIubmV0PgogKi8KCiNpbmNsdWRlIDxsaW51eC9saW5rYWdlLmg+CiNp bmNsdWRlIDxhc20vc2VnbWVudC5oPgojaW5jbHVkZSA8YXNtL3BhZ2UuaD4KI2luY2x1ZGUgPGFz bS9hc20uaD4KI2luY2x1ZGUgPGFzbS9vZmZzZXQuaD4KI2luY2x1ZGUgPGFzbS9yZWdkZWYuaD4K CgkudGV4dAoKLyogdGhpcyBtYWNybyBnZW5lcmF0ZXMgbG9jYWwgd29yZCh1bnNpZ25lZCBsb25n KSBzaXplZCB2YXJpYWJsZSAqLwojZGVmaW5lCUxPQ0FMX1dPUkQoeCkJXAoJLmRhdGEJCTtcCgku YWxpZ24gMgk7XAoJLnR5cGUgeCwgQG9iamVjdDtcCgkuc2l6ZSB4LCA0CTtcCng6Cgkuc3BhY2Ug NAoKI2RlZmluZSBXT1JEX0FERFIoeCkJXAoJLmFsaWduIDIJO1wKLkwjI3g6CQkJO1wKCS53b3Jk IHgJCQoKI2RlZmluZSBGVU5DKHgpCQlcCgkudGV4dAkJO1wKCS5hbGlnbiAyCTtcCgkuZ2xvYmwg eAk7XAoJLmVudCB4CQk7XAoJLnR5cGUgeCxAZnVuY3Rpb247XAp4OgoKI2RlZmluZSBGVU5DX0VO RCh4KQlcCgkuZW5kIHgKCkxPQ0FMX1dPUkQoc2F2ZWRfY29udGV4dF9zMCk7CkxPQ0FMX1dPUkQo c2F2ZWRfY29udGV4dF9zMSk7CkxPQ0FMX1dPUkQoc2F2ZWRfY29udGV4dF9zMik7CkxPQ0FMX1dP UkQoc2F