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 UkQoc2F2ZWRfY29udGV4dF9zMyk7CkxPQ0FMX1dPUkQoc2F2ZWRfY29udGV4dF9zNCk7CkxPQ0FM X1dPUkQoc2F2ZWRfY29udGV4dF9zNSk7CkxPQ0FMX1dPUkQoc2F2ZWRfY29udGV4dF9zNik7CkxP Q0FMX1dPUkQoc2F2ZWRfY29udGV4dF9zNyk7CkxPQ0FMX1dPUkQoc2F2ZWRfY29udGV4dF9yYSk7 CgpGVU5DKHN3c3VzcF9hcmNoX3N1c3BlbmQpCglzdyBzMCxzYXZlZF9jb250ZXh0X3MwOwoJc3cg czEsc2F2ZWRfY29udGV4dF9zMTsKCXN3IHMyLHNhdmVkX2NvbnRleHRfczI7CglzdyBzMyxzYXZl ZF9jb250ZXh0X3MzOwoJc3cgczQsc2F2ZWRfY29udGV4dF9zNDsKCXN3IHM1LHNhdmVkX2NvbnRl eHRfczU7CglzdyBzNixzYXZlZF9jb250ZXh0X3M2OwoJc3cgczcsc2F2ZWRfY29udGV4dF9zNzsK CXN3IHJhLHNhdmVkX2NvbnRleHRfcmE7CgoJamFsIHN3c3VzcF9zYXZlOwoKCWx3IHJhLHNhdmVk X2NvbnRleHRfcmE7CS8vIHRoaXMgc3RhdGVtZW50IGNvcnJlc3BvbmRzIHRvIFJFVCBpbiB4ODYg YXNtLgoJLy9QUklOVCgiW0FTTV0gUkVUVVJOIFRPIEMhISIpOwoJaiByYTsJCQkJLy8KCQpGVU5D X0VORChzd3N1c3BfYXJjaF9zdXNwZW5kKQoKLy8gZm9yIHVzaW5nIHByaW50awoucmRhdGEKLmFs aWduIDIKJExDMDoKCS5hc2NpaSAiW0RFQlVHXSBSRVRVUk4gVE8gQyEhISBmcm9tIEFTTVxuXDAw MCIKCS5hbGlnbiAyCiRMQzE6CgkuYXNjaWkgIkBAI1wwMDAiCgkuYWxpZ24gMgokTEMyOgoJLmFz Y2lpICJDb3B5ICVkIVxuXDAwMCIKCS5hbGlnbiAyCiRMQzM6CgkuYXNjaWkgIkVuZCBsb29wXG5c MDAwIgoJLmFsaWduIDIKJExDNDoKCS5hc2NpaSAiW0FTTV0gUkVTVU1FIFNVQ0NFU1MhIVxuXDAw MCIKCS5hbGlnbiAyCiRMQzU6CgkuYXNjaWkgIltBU01dIFN0YXJ0IGNvcHlpbmcgcGFnZXMgLi4u IFxuXDAwMCIKCS5hbGlnbiAyCiRMQzY6CgkuYXNjaWkgIltBU01dIExvYWQgbnJfY29weV9wYWdl cyBhbmQgcGFnZWRpcl9ub3NhdmUgc3VjY2VzcyEhXG5cMDAwIgoKTE9DQUxfV09SRCh0bXBfdmFy KTsKTE9DQUxfV09SRCh0bXBfdmFyMik7CgpGVU5DKHN3c3VzcF9hcmNoX3Jlc3VtZSkKLyoKKiAg ICBUaGlzIHBzZXVkbyBjb2RlIHNob3VsZCBiZSBpbXBsZW1lbnRlZC4KKgoqICAgIHJlZ2lzdGVy IHUzMiAqc3JjLCpkc3Q7CiogICAgZm9yIChqPW5yX2NvcHlfcGFnZXM7IGo+MDsgai0tKQoqICAg ICB7CioJc3JjID0gcGFnZWRpcl9ub3NhdmVbal0uc3JjOwoqCWRzdCA9IHBhZ2VkaXJfbm9zYXZl W2pdLmRzdDsKKglmb3IoaT0wO2k8MTAyNDtpKyspewoqCQkqZHN0KysgPSAqc3JjKys7CioJfQoq ICAgICB9CiovCi8qCioJdHlwZWRlZiBzdHJ1Y3QgcGJlewoqCQl1bnNpZ25lZCBsb25nIGFkZHJl c3M7CS8vIGFkZHJlc3Mgb2YgdGhlIGNvcHkJCQk6IGJhc2UgYWRkcjsKKgkJdW5zaWduZWQgbG9u ZyBvcmlnX2FkZHJlc3M7CS8vb3JpZ2luYWwgYWRkcmVzcy4uLgkJOiBiYXNlIGFkZHIgKyA0Owoq CS4uLgoqLwoJLy8gVXNlZCByZWdpc3RlciBsb29rdXAgdGFibGUKCS8vICR0MCA6IG9yaWcncyBj b250ZW50cwoJLy8gJHQxIDoKCS8vICR0MiA6IGNvdW50ZXIsIDEwMjQKCS8vICR0MyA6CgkvLyAk dDQgOgoJLy8gJHQ1IDoKCS8vICR0NiA6CgkvLyAkdDcgOgoJLy8KCS8vICRzMCA6IHBhZ2VkaXJf bm9zYXZlJ3MgYWRkcmVzcwoJLy8gJHMxIDogbnJfY29weV9wYWdlcydzIGFkZHJlc3MKCS8vICRz MiA6IHRlbXBfdmFyCgkvLyAkczMgOiBzcmMgcG9pbnRlcgoJLy8gJHM0IDogZHN0IHBvaW50ZXIK CS8vICRzNSA6CgkvLyAkczYgOgoJLy8gJHM3IDoKCS8vCgkKCS8vIEdldCBwb2ludGVyIGZyb20g dmFyaWFibGVzLgoJbHcgczAscGFnZWRpcl9ub3NhdmU7CQkvLyBsb2FkIHBhZ2VkaXJfbm9zYXZl J3MgYWRkcmVzcwoJbHcgczEsbnJfY29weV9wYWdlczsJCQkvLyAkczE9bnJfY29weV9wYWdlczsK JGNvcHlfbG9vcDoKCWx3IHMzLDAoczApOwkJLy8gJHMzIGhhcyBzb3VyY2UgZGVzdGluYXRpb24n cyBhZGRyZXNzCglsdyBzNCw0KHMwKTsJCS8vICRzNCBoYXMgb3JpZ25hbCBhZGRyZXNzCgkJCQkv LyBPYmplY3RpdmUgOiBjb3B5IG9yaWdfYWRkcmVzcydzIGNvbnRlbnRzIHRvIGFkZHJlc3MKCWxp IHQyLDEwMjQ7CQkvLyAkdDIgPSAxMDI0OywgaW5kZXggdmFyaWFibGUuCiRjb3B5X2xvb3BfaW5u ZXI6CglsdyB0MCwwKHMzKTsJCS8vIG9yaWcncyBjb250ZW50cyBpbnRvICR0MAoJc3cgdDAsMChz NCk7CQkvLyBvcmlnJ3MgY29udGVudHMgdG8gdGFyZ2V0IGFkZHJlc3MncyBjb250ZW50cwoKCWFk ZGl1IHMzLHMzLDQJCS8vIGFkZHJlc3MrKwoJYWRkaXUgczQsczQsNAkJLy8gb3JpZ19hZGRyKysK CQoJYWRkaXUgdDIsdDIsLTEJCS8vIGRlY3JlYXNlIGNvdW50ZXIKCWJsZXogdDIsJGVuZF9pbm5l cl9sb29wCS8vIGxlc3MgdGhhbiBvciBlcXVhbCB6ZXJvCglqICRjb3B5X2xvb3BfaW5uZXI7CS8v IGptcCEKJGVuZF9pbm5lcl9sb29wOgoJLy9QUklOVCgiIyIpOwoJYWRkaXUgczAsczAsMTYKCWFk ZGl1IHMxLHMxLC0xCQkvLyBucl9jb3B5X3BhZ2VzID0gbnJfY29weV9wYWdlcyAtIDE7CglibGV6 IHMxLCRlbmRfY29weQoJaiAkY29weV9sb29wCiRlbmRfY29weToKCWx3IHMwLCBzYXZlZF9jb250 ZXh0X3MwOwoJbHcgczEsIHNhdmVkX2NvbnRleHRfczE7CglsdyBzMiwgc2F2ZWRfY29udGV4dF9z MjsKCWx3IHMzLCBzYXZlZF9jb250ZXh0X3MzOwoJbHcgczQsIHNhdmVkX2NvbnRleHRfczQ7Cgls dyBzNSwgc2F2ZWRfY29udGV4dF9zNTsKCWx3IHM2LCBzYXZlZF9jb250ZXh0X3M2OwoJbHcgczcs IHNhdmVkX2NvbnRleHRfczc7CglqYWwgc3dzdXNwX3Jlc3RvcmU7CglsdyByYSwgc2F2ZWRfY29u dGV4dF9yYTsKCWogcmE7CkZVTkNfRU5EKHN3c3VzcF9hcmNoX3Jlc3VtZSkKCgo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KY3B1LmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci8qCiAqIFN1c3BlbmQg c3VwcG9ydCBmb3IgTUlQUy4KICoKICogRGlzdHJpYnV0ZSB1bmRlciBHUEx2MgogKgogKiBDb3B5 cmlnaHQgKGMpIDIwMDcgSHlvbiBMaW0gPGFsZXhAYWxleGxhYi5uZXQ+CiAqLwoKI2luY2x1ZGUg PGxpbnV4L2NvbmZpZy5oPgojaW5jbHVkZSA8bGludXgva2VybmVsLmg+CiNpbmNsdWRlIDxsaW51 eC9tb2R1bGUuaD4KI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KI2luY2x1ZGUgPGxpbnV4L3R5cGVz Lmg+CiNpbmNsdWRlIDxsaW51eC9zcGlubG9jay5oPgojaW5jbHVkZSA8bGludXgvcG9sbC5oPgoj aW5jbHVkZSA8bGludXgvZGVsYXkuaD4KI2luY2x1ZGUgPGxpbnV4L3N5c3JxLmg+CiNpbmNsdWRl IDxsaW51eC9wcm9jX2ZzLmg+CiNpbmNsdWRlIDxsaW51eC9pcnEuaD4KI2luY2x1ZGUgPGxpbnV4 L3BtLmg+CiNpbmNsdWRlIDxsaW51eC9kZXZpY2UuaD4KI2luY2x1ZGUgPGxpbnV4L3N1c3BlbmQu aD4KI2luY2x1ZGUgPGFzbS91YWNjZXNzLmg+CiNpbmNsdWRlIDxhc20vdGxiZmx1c2guaD4KCnN0 YXRpYyBzdHJ1Y3Qgc2F2ZWRfY29udGV4dCBzYXZlZF9jb250ZXh0OwoKLy8gVGhpcyBpcyBjYWxs ZWUtc2F2ZWQgcmVnaXN0ZXJzCi8vdW5zaWduZWQgbG9uZyBzYXZlZF9jb250ZXh0X3MwOwovL3Vu c2lnbmVkIGxvbmcgc2F2ZWRfY29udGV4dF9zMTsKLy91bnNpZ25lZCBsb25nIHNhdmVkX2NvbnRl eHRfczI7Ci8vdW5zaWduZWQgbG9uZyBzYXZlZF9jb250ZXh0X3MzOwovL3Vuc2lnbmVkIGxvbmcg c2F2ZWRfY29udGV4dF9zNDsKLy91bnNpZ25lZCBsb25nIHNhdmVkX2NvbnRleHRfczU7Ci8vdW5z aWduZWQgbG9uZyBzYXZlZF9jb250ZXh0X3M2OwovL3Vuc2lnbmVkIGxvbmcgc2F2ZWRfY29udGV4 dF9zNzsKLy91bnNpZ25lZCBsb25nIHNhdmVkX2NvbnRleHRfcmE7CS8vIHJldHVybiBhZGRyZXNz Cgp2b2lkIF9fc2F2ZV9wcm9jZXNzb3Jfc3RhdGUodm9pZCkKewoJcHJlZW1wdF9kaXNhYmxlKCk7 CgoJLy8ga2VybmVsX2ZwdV9iZWdpbigpOwoJLy8gbWlwcyB1c2VzIFBGX1VTRURGUFUsIGJ1dCB0 aGVyZSBpc24ndCBmdW5jdGlvbiBvZiBrZXJuZWxfZnB1X2JlZ2luLgoJLy8gVGhpbmsgb2Ygc3Rv cmluZyBmcCByZWxhdGVkIHJlZ2lzdGVycy4KCQoJLyogICAgICAgICAgICAgICAgICAgICAgICAg ICAgQ1BVIHJlZ2lzdGVycyAgICAgICAgICAgICAgICAgICAgICAgICovCgkvKgoJICogc2F2ZSB0 aGUgZ2VuZXJhbCByZWdpc3RlcnMuCgkgKiBub3RlIHRoYXQgZ2NjIGhhcyBjb25zdHJ1Y3RzIHRv IHNwZWNpZnkgb3V0cHV0IG9mIGNlcnRhaW4gcmVnaXN0ZXJzLAoJICogYnV0IHRoZXkncmUgbm90 IHVzZWQgaGVyZSwgYmVjYXVzZSBpdCBhc3N1bWVzIHRoYXQgeW91IHdhbnQgdG8gbW9kaWZ5Cgkg KiB0aG9zZSByZWdpc3RlcnMsIHNvIGl0IHRyaWVzIHRvIGJlIHNtYXJ0IGFuZCBzYXZlIHRoZW0g YmVmb3JlaGFuZC4KCSAqIEl0J3MgcmVhbGx5IG5vdCBuZWNlc3NhcnksIGFuZCBraW5kYSBmaXNo eSAoY2hlY2sgdGhlIGFzc2VtYmx5IG91dHB1dCksCgkgKiBzbyBpdCdzIGF2b2lkZWQuCgkgKi8K CgkvKgoJICogY2FuJ3QgdXNlIG91dHB1dCB3aXRoICJtIiBjb25zdHJhaW50LiBiZWNhdXNlIGRp cmVjdCBhZGRyZXNzaW5nIGlzCm5vdCBwZXJtaXR0ZWQKCSAqIG9uIE1JUFMgaW5saW5lIGFzc2Vt Ymx5LiAocmVnaXN0ZXIgcmVsYXRpdmUgYWRkcmVzc2luZyBhcyBJIHNlZSkKCSAqIGNvbXBpbGVy IHVzdWFsbHkgYWxsb2NhdGVzIGZpcnN0ICJyIiBjb25zdHJhaW50IHJlZ2lzdGVyIHdpdGgKJ3Yw Jy4gKGluIG15IG9waW5pb24pCgkgKiBpZiBpdCBkb2Vzbid0LCBJJ2xsIGRlc2NyaWJlIHJlYWxs eSByZWFsbHkgbWFzc2l2ZSBjbG9iYmVyIGxpc3QKZm9yIHN0YWJpbGl0eS4KCSAqCgkgKiAiYXQi IHJlZ2lzdGVyIGlzIG9ubHkgdXNlZCBieSBhc3NlbWJsZXIuCgkgKiAiemVybyIgcmVnaXN0ZXIg YWx3YXlzIGNvbnRhaW5zIHplcm8uCgkgKi8KCWFzbSB2b2xhdGlsZSAoInN1YnUgJDI5LCA0Iik7 Cglhc20gdm9sYXRpbGUgKCJzdyAkMiwgKCQyOSkiKTsKCQoJYXNtIHZvbGF0aWxlICgic3cgJDMs ICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnZbMV0pKTsKCWFzbSB2b2xhdGlsZSAoInN3 ICQ0LCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5hWzBdKSk7Cglhc20gdm9sYXRpbGUg KCJzdyAkNSwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuYVsxXSkpOwoJYXNtIHZvbGF0 aWxlICgic3cgJDYsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LmFbMl0pKTsKCWFzbSB2 b2xhdGlsZSAoInN3ICQ3LCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5hWzNdKSk7Cglh c20gdm9sYXRpbGUgKCJzdyAkOCwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQudFswXSkp OwoJYXNtIHZvbGF0aWxlICgic3cgJDksICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnRb MV0pKTsKCWFzbSB2b2xhdGlsZSAoInN3ICQxMCwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRl eHQudFsyXSkpOwoJYXNtIHZvbGF0aWxlICgic3cgJDExLCAoJTApIiA6IDogInIiICgmc2F2ZWRf Y29udGV4dC50WzNdKSk7Cglhc20gdm9sYXRpbGUgKCJzdyAkMTIsICglMCkiIDogOiAiciIgKCZz YXZlZF9jb250ZXh0LnRbNF0pKTsKCWFzbSB2b2xhdGlsZSAoInN3ICQxMywgKCUwKSIgOiA6ICJy IiAoJnNhdmVkX2NvbnRleHQudFs1XSkpOwoJYXNtIHZvbGF0aWxlICgic3cgJDE0LCAoJTApIiA6 IDogInIiICgmc2F2ZWRfY29udGV4dC50WzZdKSk7Cglhc20gdm9sYXRpbGUgKCJzdyAkMTUsICgl MCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnRbN10pKTsKCWFzbSB2b2xhdGlsZSAoInN3ICQx NiwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuc1swXSkpOwoJYXNtIHZvbGF0aWxlICgi c3cgJDE3LCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5zWzFdKSk7Cglhc20gdm9sYXRp bGUgKCJzdyAkMTgsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnNbMl0pKTsKCWFzbSB2 b2xhdGlsZSAoInN3ICQxOSwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuc1szXSkpOwoJ YXNtIHZvbGF0aWxlICgic3cgJDIwLCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5zWzRd KSk7Cglhc20gdm9sYXRpbGUgKCJzdyAkMjEsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0 LnNbNV0pKTsKCWFzbSB2b2xhdGlsZSAoInN3ICQyMiwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2Nv bnRleHQuc1s2XSkpOwoJYXNtIHZvbGF0aWxlICgic3cgJDIzLCAoJTApIiA6IDogInIiICgmc2F2 ZWRfY29udGV4dC5zWzddKSk7Cglhc20gdm9sYXRpbGUgKCJzdyAkMjQsICglMCkiIDogOiAiciIg KCZzYXZlZF9jb250ZXh0LnRbOF0pKTsKCWFzbSB2b2xhdGlsZSAoInN3ICQyNSwgKCUwKSIgOiA6 ICJyIiAoJnNhdmVkX2NvbnRleHQudFs5XSkpOwoJYXNtIHZvbGF0aWxlICgic3cgJDI2LCAoJTAp IiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5rWzBdKSk7Cglhc20gdm9sYXRpbGUgKCJzdyAkMjcs ICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LmtbMV0pKTsKCWFzbSB2b2xhdGlsZSAoInN3 ICQyOCwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuZ3ApKTsKCWFzbSB2b2xhdGlsZSAo InN3ICQzMCwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuZnApKTsKCWFzbSB2b2xhdGls ZSAoInN3ICQzMSwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQucmEpKTsKCglhc20gdm9s YXRpbGUgKCJsdyAkMiwgKCQyOSkiKTsKCWFzbSB2b2xhdGlsZSAoImFkZHUgJDI5LCA0Iik7CgkK CWFzbSB2b2xhdGlsZSAoInN3ICQyLCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC52WzBd KSA6ICIkMiIpOwoJYXNtIHZvbGF0aWxlICgic3cgJDI5LCAoJTApIiA6IDogInIiICgmc2F2ZWRf Y29udGV4dC5zcCkpOwoJCgkvKgoJICogc3BlY2lhbCByZWdpc3RlcnMKCSAqLwoJYXNtIHZvbGF0 aWxlICgibWZoaSAlMCIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmhpKSk7Cglhc20gdm9sYXRpbGUg KCJtZmxvICUwIiA6ICI9ciIgKHNhdmVkX2NvbnRleHQubG8pKTsKCS8vIGxvYWQvbGluayByZWdp c3Rlcj8/CgoJLyoKCSAqIGNvcHJvY2Vzc29yIDAgcmVnaXN0ZXJzIChpbmNsZGUvYXNtLW1pcHMv bWlwc3JlZ3MuaCkKCSAqLwoJYXNtIHZvbGF0aWxlICgibWZjMCAlMCwgJDAiIDogIj1yIiAoc2F2 ZWRfY29udGV4dC5jcDBbMF0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxIiA6ICI9ciIg KHNhdmVkX2NvbnRleHQuY3AwWzFdKSk7Cglhc20gdm9sYXRpbGUgKCJtZmMwICUwLCAkMiIgOiAi PXIiIChzYXZlZF9jb250ZXh0LmNwMFsyXSkpOwoJYXNtIHZvbGF0aWxlICgibWZjMCAlMCwgJDMi IDogIj1yIiAoc2F2ZWRfY29udGV4dC5jcDBbM10pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAs ICQ0IiA6ICI9ciIgKHNhdmVkX2NvbnRleHQuY3AwWzRdKSk7Cglhc20gdm9sYXRpbGUgKCJtZmMw ICUwLCAkNSIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFs1XSkpOwoJYXNtIHZvbGF0aWxlICgi bWZjMCAlMCwgJDYiIDogIj1yIiAoc2F2ZWRfY29udGV4dC5jcDBbNl0pKTsKCWFzbSB2b2xhdGls ZSAoIm1mYzAgJTAsICQ3IiA6ICI9ciIgKHNhdmVkX2NvbnRleHQuY3AwWzddKSk7Cglhc20gdm9s YXRpbGUgKCJtZmMwICUwLCAkOCIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFs4XSkpOwoJYXNt IHZvbGF0aWxlICgibWZjMCAlMCwgJDkiIDogIj1yIiAoc2F2ZWRfY29udGV4dC5jcDBbOV0pKTsK CWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxMCIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsx MF0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxMSIgOiAiPXIiIChzYXZlZF9jb250ZXh0 LmNwMFsxMV0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxMiIgOiAiPXIiIChzYXZlZF9j b250ZXh0LmNwMFsxMl0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxMyIgOiAiPXIiIChz YXZlZF9jb250ZXh0LmNwMFsxM10pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxNCIgOiAi PXIiIChzYXZlZF9jb250ZXh0LmNwMFsxNF0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQx NSIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsxNV0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAg JTAsICQxNiIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsxNl0pKTsKCWFzbSB2b2xhdGlsZSAo Im1mYzAgJTAsICQxNyIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsxN10pKTsKCWFzbSB2b2xh dGlsZSAoIm1mYzAgJTAsICQxOCIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsxOF0pKTsKCWFz bSB2b2xhdGlsZSAoIm1mYzAgJTAsICQxOSIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsxOV0p KTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQyMCIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNw MFsyMF0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQyMSIgOiAiPXIiIChzYXZlZF9jb250 ZXh0LmNwMFsyMV0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQyMiIgOiAiPXIiIChzYXZl ZF9jb250ZXh0LmNwMFsyMl0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQyMyIgOiAiPXIi IChzYXZlZF9jb250ZXh0LmNwMFsyM10pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQyNCIg OiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsyNF0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAs ICQyNSIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsyNV0pKTsKCWFzbSB2b2xhdGlsZSAoIm1m YzAgJTAsICQyNiIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsyNl0pKTsKCWFzbSB2b2xhdGls ZSAoIm1mYzAgJTAsICQyNyIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsyN10pKTsKCWFzbSB2 b2xhdGlsZSAoIm1mYzAgJTAsICQyOCIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsyOF0pKTsK CWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQyOSIgOiAiPXIiIChzYXZlZF9jb250ZXh0LmNwMFsy OV0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQzMCIgOiAiPXIiIChzYXZlZF9jb250ZXh0 LmNwMFszMF0pKTsKCWFzbSB2b2xhdGlsZSAoIm1mYzAgJTAsICQzMSIgOiAiPXIiIChzYXZlZF9j b250ZXh0LmNwMFszMV0pKTsKfQoKdm9pZCBzYXZlX3Byb2Nlc3Nvcl9zdGF0ZSh2b2lkKQp7CgkJ cHJpbnRrKCJbREVCVUddIGJlZm9yZSBfX3NhdmVfcHJvY2Vzc29yX3N0YXRlKCkgJXMsJWRcbiIs X19GSUxFX18sX19MSU5FX18pOwoJX19zYXZlX3Byb2Nlc3Nvcl9zdGF0ZSgpOwoJCQlwcmludGso IltERUJVR10gYWZ0ZXIgX19zYXZlX3Byb2Nlc3Nvcl9zdGF0ZSgpICVzLCVkXG4iLF9fRklMRV9f LF9fTElORV9fKTsKfQoKdm9pZCBfX3Jlc3RvcmVfcHJvY2Vzc29yX3N0YXRlKHZvaWQpCnsKCS8q CgkgKiBmaXJzdCByZXN0b3JlICVkcywgc28gd2UgY2FuIGFjY2VzcyBvdXIgZGF0YSBwcm9wZXJs eQoJICovCglhc20gdm9sYXRpbGUgKCIuYWxpZ24gNCIpOwovLwlhc20gdm9sYXRpbGUgKCJtb3Z3 ICUwLCAlJWRzIiA6OiAiciIgKCh1MTYpX19LRVJORUxfRFMpKTsKCgoJLyoKCSAqIGNvcHJvY2Vz c29yIDAgcmVnaXN0ZXJzIChpbmNsZGUvYXNtLW1pcHMvbWlwc3JlZ3MuaCkKCSAqLwoJYXNtIHZv bGF0aWxlICgibXRjMCAlMCwgJDAiIDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzBdKSk7Cglh c20gdm9sYXRpbGUgKCJtdGMwICUwLCAkMSIgOiA6ICJyIiAoc2F2ZWRfY29udGV4dC5jcDBbMV0p KTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQyIiA6IDogInIiIChzYXZlZF9jb250ZXh0LmNw MFsyXSkpOwoJYXNtIHZvbGF0aWxlICgibXRjMCAlMCwgJDMiIDogOiAiciIgKHNhdmVkX2NvbnRl eHQuY3AwWzNdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUwLCAkNCIgOiA6ICJyIiAoc2F2ZWRf Y29udGV4dC5jcDBbNF0pKTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQ1IiA6IDogInIiIChz YXZlZF9jb250ZXh0LmNwMFs1XSkpOwoJYXNtIHZvbGF0aWxlICgibXRjMCAlMCwgJDYiIDogOiAi ciIgKHNhdmVkX2NvbnRleHQuY3AwWzZdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUwLCAkNyIg OiA6ICJyIiAoc2F2ZWRfY29udGV4dC5jcDBbN10pKTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAs ICQ4IiA6IDogInIiIChzYXZlZF9jb250ZXh0LmNwMFs4XSkpOwoJYXNtIHZvbGF0aWxlICgibXRj MCAlMCwgJDkiIDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzldKSk7Cglhc20gdm9sYXRpbGUg KCJtdGMwICUwLCAkMTAiIDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzEwXSkpOwoJYXNtIHZv bGF0aWxlICgibXRjMCAlMCwgJDExIiA6IDogInIiIChzYXZlZF9jb250ZXh0LmNwMFsxMV0pKTsK CWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQxMiIgOiA6ICJyIiAoc2F2ZWRfY29udGV4dC5jcDBb MTJdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUwLCAkMTMiIDogOiAiciIgKHNhdmVkX2NvbnRl eHQuY3AwWzEzXSkpOwoJYXNtIHZvbGF0aWxlICgibXRjMCAlMCwgJDE0IiA6IDogInIiIChzYXZl ZF9jb250ZXh0LmNwMFsxNF0pKTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQxNSIgOiA6ICJy IiAoc2F2ZWRfY29udGV4dC5jcDBbMTVdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUwLCAkMTYi IDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzE2XSkpOwoJYXNtIHZvbGF0aWxlICgibXRjMCAl MCwgJDE3IiA6IDogInIiIChzYXZlZF9jb250ZXh0LmNwMFsxN10pKTsKCWFzbSB2b2xhdGlsZSAo Im10YzAgJTAsICQxOCIgOiA6ICJyIiAoc2F2ZWRfY29udGV4dC5jcDBbMThdKSk7Cglhc20gdm9s YXRpbGUgKCJtdGMwICUwLCAkMTkiIDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzE5XSkpOwoJ YXNtIHZvbGF0aWxlICgibXRjMCAlMCwgJDIwIiA6IDogInIiIChzYXZlZF9jb250ZXh0LmNwMFsy MF0pKTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQyMSIgOiA6ICJyIiAoc2F2ZWRfY29udGV4 dC5jcDBbMjFdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUwLCAkMjIiIDogOiAiciIgKHNhdmVk X2NvbnRleHQuY3AwWzIyXSkpOwoJYXNtIHZvbGF0aWxlICgibXRjMCAlMCwgJDIzIiA6IDogInIi IChzYXZlZF9jb250ZXh0LmNwMFsyM10pKTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQyNCIg OiA6ICJyIiAoc2F2ZWRfY29udGV4dC5jcDBbMjRdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUw LCAkMjUiIDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzI1XSkpOwoJYXNtIHZvbGF0aWxlICgi bXRjMCAlMCwgJDI2IiA6IDogInIiIChzYXZlZF9jb250ZXh0LmNwMFsyNl0pKTsKCWFzbSB2b2xh dGlsZSAoIm10YzAgJTAsICQyNyIgOiA6ICJyIiAoc2F2ZWRfY29udGV4dC5jcDBbMjddKSk7Cglh c20gdm9sYXRpbGUgKCJtdGMwICUwLCAkMjgiIDogOiAiciIgKHNhdmVkX2NvbnRleHQuY3AwWzI4 XSkpOwoJYXNtIHZvbGF0aWxlICgibXRjMCAlMCwgJDI5IiA6IDogInIiIChzYXZlZF9jb250ZXh0 LmNwMFsyOV0pKTsKCWFzbSB2b2xhdGlsZSAoIm10YzAgJTAsICQzMCIgOiA6ICJyIiAoc2F2ZWRf Y29udGV4dC5jcDBbMzBdKSk7Cglhc20gdm9sYXRpbGUgKCJtdGMwICUwLCAkMzEiIDogOiAiciIg KHNhdmVkX2NvbnRleHQuY3AwWzMxXSkpOwoKCS8qCgkgKiBzcGVjaWFsIHJlZ2lzdGVycwoJICov Cglhc20gdm9sYXRpbGUgKCJtdGhpICUwIiA6IDogInIiIChzYXZlZF9jb250ZXh0LmhpKSk7Cglh c20gdm9sYXRpbGUgKCJtdGxvICUwIiA6IDogInIiIChzYXZlZF9jb250ZXh0LmxvKSk7CgoJLyoK CSAqIHRoZSBvdGhlciBnZW5lcmFsIHJlZ2lzdGVycwoJICoKCSAqIG5vdGUgdGhhdCBldmVuIHRo b3VnaCBnY2MgaGFzIGNvbnN0cnVjdHMgdG8gc3BlY2lmeSBtZW1vcnkKCSAqIGlucHV0IGludG8g Y2VydGFpbiByZWdpc3RlcnMsIGl0IHdpbGwgdHJ5IHRvIGJlIHRvbyBzbWFydAoJICogYW5kIHNh dmUgdGhlbSBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBmdW5jdGlvbi4gIFRoaXMgaXMgZXNwLgoJ ICogYmFkIHNpbmNlIHdlIGRvbid0IGhhdmUgYSBzdGFjayBzZXQgdXAgd2hlbiB3ZSBlbnRlciwg YW5kIHdlCgkgKiB3YW50IHRvIHByZXNlcnZlIHRoZSB2YWx1ZXMgb24gZXhpdC4gU28sIHdlIHNl dCB0aGVtIG1hbnVhbGx5LgoJICovCglhc20gdm9sYXRpbGUgKCJsdyAkMywgKCUwKSIgOiA6ICJy IiAoJnNhdmVkX2NvbnRleHQudlsxXSkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDQsICglMCkiIDog OiAiciIgKCZzYXZlZF9jb250ZXh0LmFbMF0pKTsKCWFzbSB2b2xhdGlsZSAoImx3ICQ1LCAoJTAp IiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5hWzFdKSk7Cglhc20gdm9sYXRpbGUgKCJsdyAkNiwg KCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuYVsyXSkpOwoJYXNtIHZvbGF0aWxlICgibHcg JDcsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LmFbM10pKTsKCWFzbSB2b2xhdGlsZSAo Imx3ICQ4LCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC50WzBdKSk7Cglhc20gdm9sYXRp bGUgKCJsdyAkOSwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQudFsxXSkpOwoJYXNtIHZv bGF0aWxlICgibHcgJDEwLCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC50WzJdKSk7Cglh c20gdm9sYXRpbGUgKCJsdyAkMTEsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnRbM10p KTsKCWFzbSB2b2xhdGlsZSAoImx3ICQxMiwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQu dFs0XSkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDEzLCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29u dGV4dC50WzVdKSk7Cglhc20gdm9sYXRpbGUgKCJsdyAkMTQsICglMCkiIDogOiAiciIgKCZzYXZl ZF9jb250ZXh0LnRbNl0pKTsKCWFzbSB2b2xhdGlsZSAoImx3ICQxNSwgKCUwKSIgOiA6ICJyIiAo JnNhdmVkX2NvbnRleHQudFs3XSkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDE2LCAoJTApIiA6IDog InIiICgmc2F2ZWRfY29udGV4dC5zWzBdKSk7Cglhc20gdm9sYXRpbGUgKCJsdyAkMTcsICglMCki IDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnNbMV0pKTsKCWFzbSB2b2xhdGlsZSAoImx3ICQxOCwg KCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuc1syXSkpOwoJYXNtIHZvbGF0aWxlICgibHcg JDE5LCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5zWzNdKSk7Cglhc20gdm9sYXRpbGUg KCJsdyAkMjAsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnNbNF0pKTsKCWFzbSB2b2xh dGlsZSAoImx3ICQyMSwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRleHQuc1s1XSkpOwoJYXNt IHZvbGF0aWxlICgibHcgJDIyLCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5zWzZdKSk7 Cglhc20gdm9sYXRpbGUgKCJsdyAkMjMsICglMCkiIDogOiAiciIgKCZzYXZlZF9jb250ZXh0LnNb N10pKTsKCWFzbSB2b2xhdGlsZSAoImx3ICQyNCwgKCUwKSIgOiA6ICJyIiAoJnNhdmVkX2NvbnRl eHQudFs4XSkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDI1LCAoJTApIiA6IDogInIiICgmc2F2ZWRf Y29udGV4dC50WzldKSk7Cglhc20gdm9sYXRpbGUgKCJsdyAkMjYsICglMCkiIDogOiAiciIgKCZz YXZlZF9jb250ZXh0LmtbMF0pKTsKCWFzbSB2b2xhdGlsZSAoImx3ICQyNywgKCUwKSIgOiA6ICJy IiAoJnNhdmVkX2NvbnRleHQua1sxXSkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDI4LCAoJTApIiA6 IDogInIiICgmc2F2ZWRfY29udGV4dC5ncCkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDI5LCAoJTAp IiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5zcCkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDMwLCAo JTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5mcCkpOwoJYXNtIHZvbGF0aWxlICgibHcgJDMx LCAoJTApIiA6IDogInIiICgmc2F2ZWRfY29udGV4dC5yYSkpOwoJLy8gR29vZCBqb2IgJ3YwJy4g SXQncyB5b3VyIHR1cm4hCglhc20gdm9sYXRpbGUgKCJsdyAkMiwgKCUwKSIgOiA6ICJyIiAoJnNh dmVkX2NvbnRleHQudlswXSkpOwoKCXByZWVtcHRfZW5hYmxlKCk7Cn0KCnZvaWQgcmVzdG9yZV9w cm9jZXNzb3Jfc3RhdGUodm9pZCkKewoJCQlwcmludGsoIltERUJVR10gYmVmb3JlIF9fcmVzdG9y ZV9wcm9jZXNzb3Jfc3RhdGUoKQolcywlZFxuIixfX0ZJTEVfXyxfX0xJTkVfXyk7CglfX3Jlc3Rv cmVfcHJvY2Vzc29yX3N0YXRlKCk7CgkJCQlwcmludGsoIltERUJVR10gYWZ0ZXIgX19yZXN0b3Jl X3Byb2Nlc3Nvcl9zdGF0ZSgpCiVzLCVkXG4iLF9fRklMRV9fLF9fTElORV9fKTsKfQoKLyogTmVl ZGVkIGJ5IGFwbS5jICovCkVYUE9SVF9TWU1CT0woc2F2ZV9wcm9jZXNzb3Jfc3RhdGUpOwpFWFBP UlRfU1lNQk9MKHJlc3RvcmVfcHJvY2Vzc29yX3N0YXRlKTsKCgo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Cktlcm5lbCBQYW5pYyBNZXNzYWdlCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0Ka3N3YXBkMCBsZWZ0IHJlZnJp Z2VyYXRvciwga2VybmVsL3Bvd2VyL3Byb2Nlc3MuYyw2Nwppbml0IGxlZnQgcmVmcmlnZXJhdG9y LCBrZXJuZWwvcG93ZXIvcHJvY2Vzcy5jLDY3CkNQVSAwIFVuYWJsZSB0byBoYW5kbGUga2VybmVs IHBhZ2luZyByZXF1ZXN0IGF0IHZpcnR1YWwgYWRkcmVzcwpmZmZmZjY4OSwgZXBjID09ICA4MDFl MjU4YywgcmEgPT0gODAxZTJjNDQKT29wcyBpbiBhcmNoL21pcHMvbW0vZmF1bHQuYzo6ZG9fcGFn ZV9mYXVsdCwgbGluZSAyMDRbIzFdOgpDcHUgMAokIDAgICA6IDAwMDAwMDAwIDEwMDBmODAwIGZm ZmZmNjg5IDgwMzY0NDE4CiQgNCAgIDogODAzNjQwMTggMDAwMDA0MDAgZmZmZmY2ODkgODAzOGZm MzQKJCA4ICAgOiAwMDAwNDY0MiA4MDJmM2UyOCA4MDM3MDAwMCA4MDM3MDAwMAokMTIgICA6IDgw MzcwMDAwIGZmZmZmZmZhIGZmZmZmZmZmIDAwMDAwMDBhCiQxNiAgIDogODAzNjQwMTggODAzNjQ0 MTcgMTAwMGY4MDEgODAzOGZmMzQKJDIwICAgOiAwMDAwMDAwMCA4MDJmMDAwMCA4MDM2NDAxOCAw MDAwMDQwMAokMjQgICA6IDAwMDAwMDAxIDgwMzhmZDIyCiQyOCAgIDogODAzOGUwMDAgODAzOGZl ODAgODAxNGE0MzggODAxZTJjNDQKSGkgICAgOiAwMDAwMDA4MwpMbyAgICA6IGU0MmIyMDAwCmVw YyAgIDogODAxZTI1OGMgdnNucHJpbnRmKzB4NTgvMHg2ZmMgICAgIFRhaW50ZWQ6IFAKcmEgICAg OiA4MDFlMmM0NCB2c2NucHJpbnRmKzB4MTQvMHgzMApTdGF0dXM6IDEwMDBmODAyICAgIEtFUk5F TCBFWEwKQ2F1c2UgOiAwMDgwMDAwOApCYWRWQSA6IGZmZmZmNjg5ClBySWQgIDogMDAwMTg0NDgK TW9kdWxlcyBsaW5rZWQgaW46IHJmcyBhdHl4MjIwIGF0aWZwbGliClByb2Nlc3MgaW5pdCAocGlk OiAxLCB0aHJlYWRpbmZvPTgwMzhlMDAwLCB0YXNrPTgwMzg4YjkwKQpTdGFjayAxOiA4MDMxZTky MCAwMDAwMzA1ZiAwMDAwMzBiMCA4MDJmMDAwMCA4MDJmMDAwMCA4MDJmM2UyOCA4MDM3MDAwMCA4 MDM3MDAwMAogICAgICAgIDAwMDAwNDAwIDgwMmYwMDAwIDEwMDBmODAxIDgwMTRhNDM4IDAwMDAw MDAwIDgwMmYwMDAwIDgwMmUwMDAwIDgwMTRhNDM4CiAgICAgICAgODAxZTJjNDQgMDAwMDMwYjAg ODAxMjZhMjQgODAxMjZiNWMgZmZmZmY2ODkgODAxNGE0MzggODAzNjAwMDAgODAxMjZkMDAKICAg ICAgICA4MDM2NDA2OSA4MDJmMDAwMCAxMDAwZjgwMCA4MDJmM2UyOCAwMDAwMDA1MSA4MDJmMDAw MCAwMDAwMDAwMSA4MDJmMDAwMAogICAgICAgIDgwMTRhNDM4IDgwMTRhNDM4IDAwMDAwMDAwIDgw MTI2ZWRjIDgwMTI2Zjc4IDgwMTRhNDM4IDAwMDAwMDAwIDgwMTI2ZWRjCiAgICAgICAgODAyZTAw MDAgODAxNGE0MzggODAxNGE0NDAgODAxNGE0MzggODAxNGE0MzggODAyZjAwMDAgMDAwMDAwMDEg MDAwMDAwMDAKICAgICAgICA4MDE0YTQzOCA4MDE0YTQzOCA4MDE0YTQzOCA4MDE0YTQzOCA4MDI1 MzA1YyAwMDAwMDAwMCBmZmZmZmZmZiA4MDJkZjEyMAogICAgICAgIDAwMDAwMGZjIDgwMzdhNGM4 IDgwMTRhNDM4IDgwMTRhNDVjIDgwMzhhZTQwIDgwMmYwMDAwIDAwMDAwMDAxIDAwMDAwMDAwCiAg ICAgICAgMDAwMDAwMDMgMGE3Mzc5NzQgN2ZmZjdjNzAgMDAwMDAwMDMgMDA0MTAwMDAgMDAwMDAw MDAgN2ZmZjdmMTQgMDAwMDAwMDEKICAgICAgICAwMDAwMDAwMSAwMDQ0M2YxMCAwMDAwMDAwMCAw MDQ5MmM4MCAwMDAwMDAwMCAwMDAwMDAwMCAxMDAwZTdhMCA3ZmZmN2JhOAogICAgICAgIDAwNDQz ZmQwIDAwNDBiYWY4IDAwMDBmODEzIDAwMDAwMDAwIDAwMDAwMDAwIDEwMDBlNmYwIDEwODAwMDIw IDAwNDcwMzhjCiAgICAgICAgNTU1NTU1NTUgNTU1NTU1NTUgNTU1NTU1NTUgNTU1NTU1NTUgNTU1 NTU1NTUgNTU1NTU1NTUgNTU1NTU1NTUgNTU1NTU1NTUKU3RhY2sgMjogZmZmZmY2ODkgODAzOGZm MzQgMDAwMDQ2NDIgODAyZjNlMjggODAzNzAwMDAgODAzNzAwMDAgODAzNzAwMDAgZmZmZmZmZmEK ICAgICAgICBmZmZmZmZmZiAwMDAwMDAwYSA4MDM2NDAxOCA4MDM2NDQxNyAxMDAwZjgwMSA4MDM4 ZmYzNCAwMDAwMDAwMCA4MDJmMDAwMAogICAgICAgIDgwMzY0MDE4IDAwMDAwNDAwIDAwMDAwMDAx IDgwMzhmZDIyIDgwMTA2M2RjIDgwMTBkNmY0IDgwMzhlMDAwIDgwMzhmZTgwCiAgICAgICAgODAx NGE0MzggODAxZTJjNDQgMTAwMGY4MDIgZTQyYjIwMDAgMDAwMDAwODMgZmZmZmY2ODkgMDA4MDAw MDggODAxZTI1OGMKICAgICAgICAuLi4KQ2FsbCBUcmFjZToKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bf c3VzcGVuZCsweDc4LzB4YzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAK IFs8ODAxZTJjNDQ+XSB2c2NucHJpbnRmKzB4MTQvMHgzMAogWzw4MDEyNmEyND5dIHJlbGVhc2Vf Y29uc29sZV9zZW0rMHhlYy8weDM2NAogWzw4MDEyNmI1Yz5dIHJlbGVhc2VfY29uc29sZV9zZW0r MHgyMjQvMHgzNjQKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAKIFs8ODAx MjZkMDA+XSB2cHJpbnRrKzB4NjQvMHgyYzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsw eDc4LzB4YzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAKIFs8ODAxMjZl ZGM+XSB2cHJpbnRrKzB4MjQwLzB4MmMwCiBbPDgwMTI2Zjc4Pl0gcHJpbnRrKzB4MWMvMHgyOAog Wzw4MDE0YTQzOD5dIHN3c3VzcF9zdXNwZW5kKzB4NzgvMHhjMAogWzw4MDEyNmVkYz5dIHZwcmlu dGsrMHgyNDAvMHgyYzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAKIFs8 ODAxNGE0NDA+XSBzd3N1c3Bfc3VzcGVuZCsweDgwLzB4YzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bf c3VzcGVuZCsweDc4LzB4YzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAK IFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAKIFs8ODAxNGE0Mzg+XSBzd3N1 c3Bfc3VzcGVuZCsweDc4LzB4YzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4 YzAKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3VzcGVuZCsweDc4LzB4YzAKIFs8ODAyNTMwNWM+XSBy ZXN0b3JlX3Byb2Nlc3Nvcl9zdGF0ZSsweDI0LzB4NWMKIFs8ODAxNGE0Mzg+XSBzd3N1c3Bfc3Vz cGVuZCsweDc4LzB4YzAKIFs8ODAxNGE0NWM+XSBzd3N1c3Bfc3VzcGVuZCsweDljLzB4YzAKCgoK Q29kZToKICAgICAgICAxODQwMDAwOSAgMjVhZGZmZmYgIDI0MDQwMDIwICAwMjBjMTAyYiAgMDFh MDE4MjEgIDE0NDAwMDAyCjI1YWRmZmZmICBhMTg0MDAwMAogICAgICAgIDFjNjBmZmZhICAyNThj MDAwMSAgMDE4MDE4MjEgIDhmYjcwMDY0ICA4ZmI2MDA2MCAgOGZiNTAwNWMKOGZiNDAwNTggIDhm YjMwMDU0CiAgICAgICAgOGZiMjAwNTAgIDhmYjEwMDRjICA4ZmIwMDA0OCAgMDA2MDEwMjEgIDAz ZTAwMDA4ICAyN2JkMDA2OAowNGUwMDA0MSAgMDAxMTEwODIKICAgICAgICAzMDQyMDAwMSAgMTQ0 MDAwMzMgIDAwMTExMGMyICAzMDQyMDAwMSAgMTA0MGZmOTAgIDAwMTE5MTQyCjI1YWRmZmZmICAw ODA3ODg5MAogICAgICAgIDI0MTUwMDIwICAwODA3ODkyYyAgMDBjNzEwMjUgIDAwMDcxMDAyICAw MDQwMjAyMSAgMTA0MDAwMDQKMjVjZTAwMDEgIDAwNGYwMDFiCiAgICAgICAgMDAwMDIwMTIgIDAw MDAxMDEwICAwMDgwNDAyMSAgMDBjMDM4MjEgIDAwNDAyMDIxICAwMDAwYjAyMQowMDAwYjgyMSAg MTAwMDAwMDYKICAgICAgICAyNDA1MDAyMSAgMDAwNDA4NDAgIDAwMDRiZmMyICAwMDIzMjAyNSAg MDAwNzM4NDAgIDAwMTZiMDQwCjE2ZTAwMDAyICAwMDhmMTgyYgogICAgICAgIDE0NjAwMDAzICAy NGE1ZmZmZiAgMDA4ZjIwMjMgIDI2ZDYwMDAxICAxNGEwZmZmNCAgMDAwNzFmYzIKMDA5NDIwMjEg IDkwODUwMDAwCiAgICAgICAgMDAwODE4MDAgIDAwMDAxMDIxICAwMDAwNTgyMSAgMDA1NjQwMjUg IDAwNmI0ODI1ICAwMTAwMzAyMQowMTIwMzgyMSAgMDEwOTEwMjUKICAgICAgICBhMzI1MDAwMCAg MTQ0MGZmZDkgIDAxZGRjODIxICAwODA3ODg5ZiAgMDMwZTEwMmEgIDI1YWRmZmZmCjA4MDc4ODhm ICAyNDE1MDAyYgogICAgICAgIDAyMGMxMDJiICAxNDQwMDAwMiAgMjQwMjAwMzAgIGExODIwMDAw ICAwODA3ODhiZCAgMjU4YzAwMDEKMDgwNzg4OTggIDI1YWRmZmZlCiAgICAgICAgMDAwNjMwMjMg IDAwMDczODIzICAwMDA2MTAyYiAgMDBlMjM4MjMgIDI1YWRmZmZmICAwODA3ODg4ZgoyNDE1MDAy ZCAgMTA0MDAwMDgKICAgICAgICAyNDAyMDAzMCAgMjU4YzAwMDEgIDAyMGMxMDJiICAxNDQwZmZm MCAgMDAwMDAwMDAgIDkyODIwMDIxCjA4MDc4OTM3ICBhMTgyMDAwMAogICAgICAgIDA4MDc4OTQ0 ICBhMTgyMDAwMCAgMjdiZGZmYjggIGFmYjcwMDNjICBhZmI2MDAzOCAgYWZiMzAwMmMKYWZiZjAw NDAgIGFmYjUwMDM0CiAgICAgICAgYWZiNDAwMzAgIGFmYjIwMDI4ICBhZmIxMDAyNCAgYWZiMDAw MjAgIDAwYTBiODIxICAwMDgwYjAyMQphZmE2MDA1MCAgMDRhMDAwYzcKICAgICAgICAwMGUwOTgy MSAgMDA4NTE4MjEgIDI0NzFmZmZmICAyNDgyZmZmZiAgMDIyMjEwMmIgIDE0NDAwMDIzCjAwODA4 MDIxICAwMGMwMTAyMQogICAgICAgPDkwNDQwMDAwPiAxMDgwMDAxMCAgMDA0MDMwMjEgIDAwMDQx ZTAwICAwMDAzMWUwMyAgMjQwMjAwMjUKMTA2MjAwMWQgIDAyMzAxMDJiCiAgICAgICAgMTQ0MDAw MDQgIDI0YzIwMDAxICBhMjA0MDAwMCAgOGZhNjAwNTAgIDI0YzIwMDAxICAyNjEwMDAwMQphZmEy MDA1MCAgOTA0NDAwMDAKICAgICAgICAxNDgwZmZmMiAgMDA0MDMwMjEgIDAyMzAxMDJiICAxNDQw MDAxZSAgMDIxNjEwMjMgIGEyMDAwMDAwCjhmYmYwMDQwICA4ZmI3MDAzYwogICAgICAgIDhmYjYw MDM4ICA4ZmI1MDAzNCAgOGZiNDAwMzAgIDhmYjMwMDJjICA4ZmIyMDAyOCAgOGZiMTAwMjQKOGZi MDAwMjAgIDAzZTAwMDA4CiAgICAgICAgMjdiZDAwNDggIDI0MTFmZmZmICAwODA3ODk2MiAgMDAw NGI4MjMgIDAwMDA5MDIxICAyNGM2MDAwMQphZmE2MDA1MCAgODBjMjAwMDAKICAgICAgICAyNDQy ZmZlMCAgMmM0MzAwMTEgIDEwNjAwMDBiICAzYzAzODAyZCAgMDAwMjEwODAgIDI0NjM4ZDhjCjAw NDMxMDIxICA4YzQ0MDAwMAogICAgICAgIDAwODAwMDA4ICAwMDAwMDAwMCAgMTJlMGZmZTMgIDAw MDAwMDAwICAwODA3ODk3OSAgYTIyMDAwMDAKOTBjNTAwMDAgIDNjMTQ4MDMyCiAgICAgICAgMjY4 MmQ1NjAgIDMwYTMwMGZmICAwMDYyMTgyMSAgOTA2NDAwMDAgIDAwMDQyMDgyICAzMDg0MDAwMQox NDgwMDA0OSAgMjQxNWZmZmYKICAgICAgICAwMDA1MWUwMCAgMDAwMzFlMDMgIDI0MDIwMDJhICAx MDYyMDA2YyAgMjY2MjAwMDMgIDgwYzMwMDAwCjI0MDIwMDJlICAxMDYyMDA0OAogICAgICAgIDI0 MDhmZmZmICA4MGM0MDAwMCAgMzg4MzAwNjggIDM4ODIwMDZjICAyYzYzMDAwMSAgMmM0MjAwMDEK MDA2MjE4MjUgIDE0NjAwMDI1CiAgICAgICAgMjQwNWZmZmYgIDI0MDIwMDRjICAxMDgyMDAyMiAg MjQwMjAwNWEgIDEwODIwMDIwICAyNDAyMDA3YQoxMDgyMDAxZSAgMDAwMDAwMDAKICAgICAgICA4 MGMzMDAwMCAgMjQ2M2ZmZGIgIDJjNjIwMDU0ICAxNDQwMDAyNSAgMjQwOTAwMGEgIDAyMzAxMDJi CjE0NDAwMDAzICAyNDAyMDAyNQogICAgICAgIGEyMDIwMDAwICA4ZmE2MDA1MCAgOTBjMzAwMDAg IDEwNjAwMDNkICAyNjEwMDAwMSAgMDIzMDEwMmIKMTQ0MGZmYTYgIDI0YzIwMDAxCiAgICAgICAg YTIwMzAwMDAgIDA4MDc4OTZmICA4ZmE2MDA1MCAgMDgwNzg5ODggIDM2NTIwMDAxICAwODA3ODk4 OAozNjUyMDAxMCAgMDgwNzg5ODgKICAgICAgICAzNjUyMDAwNCAgMDgwNzg5ODggIDM2NTIwMDIw ICAwODA3ODk4OCAgMzY1MjAwMDggIDgwYzUwMDAwCjI0MDIwMDZjICAyNGM2MDAwMQogICAgICAg IDE0YTJmZmRmICBhZmE2MDA1MCAgODBjMjAwMDAgIDE0NDVmZmRjICAwMDAwMDAwMCAgMjRjNjAw MDEKMjQwNTAwNGMgIDA4MDc4OWJiCgpLZXJuZWwgcGFuaWMgLSBub3Qgc3luY2luZzogQXR0ZW1w dGVkIHRvIGtpbGwgaW5pdCEKCi0tIApIeW9uIExpbSAowNPH9ikKTW9iaWxlLiAwMTAtODIxMi0x MjQwIChJbnRsJyBDYWxsIDogKzgyLTEwLTgyMTItMTI0MCkKRmF4LiAwMzItMjMyLTA1NzggKElu dGwnIEF2YWlsYWJsZSkKSG9tZXBhZ2UgOiBodHRwOi8vd3d3LmFsZXhsYWIubmV0CkJsb2cgOiBo dHRwOi8vd3d3LmFsZXhsYWIubmV0L2Jsb2cK From 12o3l@tiscali.nl Fri Nov 2 18:59:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 18:59:26 +0000 (GMT) Received: from smtp-out3.tiscali.nl ([195.241.79.178]:30087 "EHLO smtp-out3.tiscali.nl") by ftp.linux-mips.org with ESMTP id S20030471AbXKBS7R (ORCPT ); Fri, 2 Nov 2007 18:59:17 +0000 Received: from [82.171.216.234] (helo=[192.168.1.2]) by smtp-out3.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl) id 1Io1jg-0000gx-0R for ; Fri, 02 Nov 2007 19:59:17 +0100 Message-ID: <472B7379.4030003@tiscali.nl> Date: Fri, 02 Nov 2007 19:59:05 +0100 From: Roel Kluin <12o3l@tiscali.nl> User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [PATCH] Use strchr instead of strstr in mips/fw/arc/cmdline.c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: <12o3l@tiscali.nl> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: 12o3l@tiscali.nl Precedence: bulk X-list: linux-mips Use strchr instead of strstr when searching for a single character Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- diff --git a/arch/mips/fw/arc/cmdline.c b/arch/mips/fw/arc/cmdline.c index fd604ef..4ca4eef 100644 --- a/arch/mips/fw/arc/cmdline.c +++ b/arch/mips/fw/arc/cmdline.c @@ -52,7 +52,7 @@ static char * __init move_firmware_args(char* cp) strcat(cp, used_arc[i][1]); cp += strlen(used_arc[i][1]); /* ... and now the argument */ - s = strstr(prom_argv(actr), "="); + s = strchr(prom_argv(actr), '='); if (s) { s++; strcpy(cp, s); From tsbogend@alpha.franken.de Fri Nov 2 22:12:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Nov 2007 22:12:08 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:31129 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20030693AbXKBWMA (ORCPT ); Fri, 2 Nov 2007 22:12:00 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Io4h8-000452-00; Fri, 02 Nov 2007 23:08:50 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 22CECC2191; Fri, 2 Nov 2007 23:08:19 +0100 (CET) Date: Fri, 2 Nov 2007 23:08:19 +0100 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071102220819.GA20792@alpha.franken.de> References: <20071101125236.GA16577@alpha.franken.de> <20071101150741.GA8570@linux-mips.org> <20071101160210.GA20366@linux-mips.org> <20071102101713.GA9110@alpha.franken.de> <20071102122001.GC22829@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071102122001.GC22829@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: 17379 X-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 Fri, Nov 02, 2007 at 12:20:01PM +0000, Ralf Baechle wrote: > One thing I'm still wondering about, does the kernel actually go tickless > for you? a kernel with CONFIG_NO_HZ boots and acts normal. But it looks like the PIT is still ticking at the selected 100HZ... Thomas. -- 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 Sun Nov 4 00:33:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 00:33:48 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:24229 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28577301AbXKDAdq (ORCPT ); Sun, 4 Nov 2007 00:33:46 +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 lA40Xc8t001518; Sun, 4 Nov 2007 00:33:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA40XcS5001517; Sun, 4 Nov 2007 00:33:38 GMT Date: Sun, 4 Nov 2007 00:33:38 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071104003338.GB28717@linux-mips.org> References: <20071101125236.GA16577@alpha.franken.de> <20071101150741.GA8570@linux-mips.org> <20071101160210.GA20366@linux-mips.org> <20071102101713.GA9110@alpha.franken.de> <20071102122001.GC22829@linux-mips.org> <20071102220819.GA20792@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071102220819.GA20792@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: 17380 X-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:08:19PM +0100, Thomas Bogendoerfer wrote: > On Fri, Nov 02, 2007 at 12:20:01PM +0000, Ralf Baechle wrote: > > One thing I'm still wondering about, does the kernel actually go tickless > > for you? > > a kernel with CONFIG_NO_HZ boots and acts normal. But it looks like > the PIT is still ticking at the selected 100HZ... I think this happens because the R4030 clockevent device has a rather high rating of 300 while the PIT because of an omission or intension doesn't set it's rating at all so has rating of 0. So Linux prefers the R4030. You can see which clockevent device is actually getting used by Linux in /proc/timer_list. Ralf From fbuihuu@gmail.com Sun Nov 4 08:19:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 08:19:50 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.191]:13282 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026943AbXKDITk (ORCPT ); Sun, 4 Nov 2007 08:19:40 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1263845fka for ; Sun, 04 Nov 2007 01:19:39 -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:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=X4XThZ4Ium8+3c73WGJsYDASN3SXYv8dWm+egw0+ovo=; b=Uw3B92dTXEmw4MEP+ncBMLVsAOs/OK+Y/FsFLVniHPaWIooz+rQJ9QNdeJ2X5inn06YGnNWT+ZfNM23HszNJSVQtxHn5kbFIUpCEgeEICGsFZQOmSh+Ejyli+f3V+9m01xdLwSgjNnIMBAJvtcmJEscrTCtjU1BQGmge+JaehEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=XLqsUOn1Oo8mBVkr0LiE78/Y7IklKMuofTkBGbCQz0Eash5oMmFvMWUzs7gM7fEYALeccH3AJ0FWbPEE+uMDWf6Ae6/TfzPFsckWxbhLePtWAjny+RsStQCn7hXgqQodBsiLwtj2uiWTPj3PHLKhqL8VewaGaIQ2Ukpouu8WkgI= Received: by 10.86.74.15 with SMTP id w15mr2354736fga.1194164379301; Sun, 04 Nov 2007 01:19:39 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id d13sm9319629fka.2007.11.04.01.19.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Nov 2007 01:19:37 -0700 (PDT) Message-ID: <472D8058.5080209@gmail.com> Date: Sun, 04 Nov 2007 09:18:32 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: [PATCH] Kill __bzero() X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips This patch removes this function because: 1/ Its unconventional prototype is error prone: its prototype is the same as memset one but was documented by mips_ksym.c like the following: extern void *__bzero(void *__s, size_t __count); 2/ For the caller, it makes no difference to call memset instead since it has to setup the second parameter of __bzero to 0. 3/ It's not part of the Linux user access API, so no module can use it. 4/ It needs to be exported with EXPORT_SYMBOL and therefore consumes some extra bytes. 5/ It has only one user. Signed-off-by: Franck Bui-Huu --- I'm wondering if I'm missing something, because this function seems so ugly and useless in the first place, that I can't refrain to submit a patch to get rid of it. Franck arch/mips/kernel/mips_ksyms.c | 2 -- arch/mips/lib/csum_partial.S | 2 +- arch/mips/lib/memcpy.S | 2 +- arch/mips/lib/memset.S | 4 +--- include/asm-mips/uaccess.h | 2 +- 5 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c index 225755d..6da9fa8 100644 --- a/arch/mips/kernel/mips_ksyms.c +++ b/arch/mips/kernel/mips_ksyms.c @@ -14,7 +14,6 @@ #include #include -extern void *__bzero(void *__s, size_t __count); extern long __strncpy_from_user_nocheck_asm(char *__to, const char *__from, long __len); extern long __strncpy_from_user_asm(char *__to, const char *__from, @@ -38,7 +37,6 @@ EXPORT_SYMBOL(kernel_thread); */ EXPORT_SYMBOL(__copy_user); EXPORT_SYMBOL(__copy_user_inatomic); -EXPORT_SYMBOL(__bzero); EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm); EXPORT_SYMBOL(__strncpy_from_user_asm); EXPORT_SYMBOL(__strlen_user_nocheck_asm); diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index c0a77fe..8d3fa1e 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -694,7 +694,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..425f2c3 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -443,7 +443,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 3f8b8b3..a13248b 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -46,7 +46,7 @@ .endm /* - * memset(void *s, int c, size_t n) + * void *memset(void *s, int c, size_t n) * * a0: start of area to clear * a1: char to fill with @@ -68,8 +68,6 @@ LEAF(memset) #endif or a1, t1 1: - -FEXPORT(__bzero) sltiu t0, a2, LONGSIZE /* very small region? */ bnez t0, small_memset andi t0, a0, LONGMASK /* aligned? */ diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index c30c718..9b8234a 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -643,7 +643,7 @@ __clear_user(void __user *addr, __kernel_size_t size) "move\t$4, %1\n\t" "move\t$5, $0\n\t" "move\t$6, %2\n\t" - __MODULE_JAL(__bzero) + __MODULE_JAL(memset) "move\t%0, $6" : "=r" (res) : "r" (addr), "r" (size) -- 1.5.3.4 From vagabon.xyz@gmail.com Sun Nov 4 08:22:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 08:23:00 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.189]:41659 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026948AbXKDIWw (ORCPT ); Sun, 4 Nov 2007 08:22:52 +0000 Received: by mu-out-0910.google.com with SMTP id g7so1252829muf for ; Sun, 04 Nov 2007 01:22:42 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=yKTBsZVYd4dH/Hiau3Txgbhj5UDnVCObjK3658xe6dY=; b=t+/wsedAgmvLrE5E/jO6tuFt6tPvWggVOAYKUh32zFkxaz1AFTasCTjJTHBVJSuswBJlBGmVehItiYuc638qN6Gj+3Qp6LYbNy4oRJlmIMnjp8eDrXPI+DJOZ+b+lyzwhMxjIHZzqQSgmEmw9qYcpX2wUjpuiRVwYbmY+GN+IJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qm3FoHNuJ9WgAYOlfPBRBBou0uyQUy9bMPdvIj3MijLssqNQuEn94LyPdkSzTGgvKO8g+bfNlYVc0++Ubg8LlLOxxQuIBwo0Mc5hHmzI1oOZeK2DlgVuNz+SFvbUinpfUz+Cm/CWcFG74u9w/e2JucWV2SroX3BzbJcIEP1MrJQ= Received: by 10.86.66.1 with SMTP id o1mr2374580fga.1194164561865; Sun, 04 Nov 2007 01:22:41 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j9sm11405495mue.2007.11.04.01.22.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Nov 2007 01:22:40 -0700 (PDT) Message-ID: <472D8110.2080506@gmail.com> Date: Sun, 04 Nov 2007 09:21:36 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Nigel Stephens CC: Thiemo Seufer , "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <470BE1F4.3070800@gmail.com> <47126EDC.1060305@gmail.com> <20071014195324.GT3379@networkno.de> <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> In-Reply-To: <47160D31.5080201@mips.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Nigel Stephens wrote: > Aha, that probably explains it. Franck is using the "SDE for Linux > v6.05" toolchain, and in that version of GCC -march=mips32r2 implies a [snip] BTW, are there any other toolchains out there that support smartmips ASE ? thanks, Franck From vagabon.xyz@gmail.com Sun Nov 4 08:30:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 08:30:20 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.190]:458 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20027003AbXKDIaM (ORCPT ); Sun, 4 Nov 2007 08:30:12 +0000 Received: by mu-out-0910.google.com with SMTP id g7so1254206muf for ; Sun, 04 Nov 2007 01:30:11 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=uaygN2JDcMA9z53Vkfu/fThIq+UgfiWdVKAEhk1udf8=; b=pvT6fsXwrkR7QW8njbTYlImPNeyOcaF68qfdBzmHq9KZwYXPakKgyotHqDIM9rpKMXaRcqQeoFQyNy+NiZqHBuVyOdaPCuKN812Fwo7xsnzDZebTySsLRXMHaPL/MtgfSDHL1iMXIhRXRzttdIyrHr0/e+DA7gdQIWn6qvTxk2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gaWT+o+wL++VSe60THnU+OQjmYenYEAcAKqEeEjg270epE5rN/tdAGzah+T1xg8ks8NGcJhQ2l9xbVSRNw2UxyfQqxCI+iZ9Fb48QtOc3ucuxjh8ZLwSXNn5oW9LKAKXCtySEZdijENtFYntw0BnHuBpgGY/3ZGQ1AyZzW+kJTI= Received: by 10.86.66.1 with SMTP id o1mr2379265fga.1194165011740; Sun, 04 Nov 2007 01:30:11 -0700 (PDT) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id f31sm9311814fkf.2007.11.04.01.30.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Nov 2007 01:30:09 -0700 (PDT) Message-ID: <472D82D1.1050401@gmail.com> Date: Sun, 04 Nov 2007 09:29:05 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Geert Uytterhoeven , linux-mips Subject: Re: [RFC] Add __initbss section References: <470DF25E.60009@gmail.com> <4712738A.5000703@gmail.com> <4713C840.8080206@gmail.com> <4717C1FB.4030602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Thu, 18 Oct 2007, Franck Bui-Huu wrote: >> After spending some fun time trying several different configurations >> with gcc and ld, I noticed that gcc makes a section with @nobits >> attribute if the section name starts with .bss.* > > Exactly how GCC sets section flags is mostly determined by > default_section_type_flags() in gcc/varasm.c; some flags are set elsewhere > too. This is with HEAD of GCC. > It seems that we can rely on this behaviour. I looked at gcc 4.1.2/3.2 sources and they made a section part of .bss if the section name starts with ".bss.". >> Another test I did is to put .init.bss (not .bss.init) section right >> before .bss section in order to have only one segment to load. And it >> makes magically ld do the right thing. I must admit that I don't >> understand why, and the lack of documentation doesn't help... > > Hmm, isn't what `info ld' says enough? Hmm, I'm must be blind but I missed that each time I read it. Could you point out the section number please ? OK, I think the best thing to do now is to respin the patchset and submit it linux arch mailing list. thanks, Franck From stehbrettsegeln@gmx.de Sun Nov 4 09:11:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 09:11:12 +0000 (GMT) Received: from mail.gmx.net ([213.165.64.20]:27831 "HELO mail.gmx.net") by ftp.linux-mips.org with SMTP id S20027427AbXKDJLD (ORCPT ); Sun, 4 Nov 2007 09:11:03 +0000 Received: (qmail invoked by alias); 04 Nov 2007 09:10:58 -0000 Received: from unknown (EHLO localhost.localdomain) [86.56.7.149] by mail.gmx.net (mp024) with SMTP; 04 Nov 2007 10:10:58 +0100 X-Authenticated: #2913508 X-Provags-ID: V01U2FsdGVkX1+ZoKpoaY6ZGIeZ/Dh+B5X9SkxZYtMgmseHfulkfa Kwz9B3GNbdHQmK Date: Sun, 04 Nov 2007 10:10:57 +0100 To: linux-mips@linux-mips.org Subject: "Bad eraseblock"-problem with au1550nd-NAND-driver after kernel update to 2.6.23.1 From: "Thorsten Schulz" Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.24 (Linux) X-Y-GMX-Trusted: 0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stehbrettsegeln@gmx.de Precedence: bulk X-list: linux-mips Hi, I am fiddeling around with an Au1550-System (Lippert CoolMoteMaster). After I updated the Kernel from 2.6.17.7 to 2.6.23.1 the flash driver complaints about Bad eraseblocks at kernel start: [17179570.224000] NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit) [17179570.232000] Scanning device for bad blocks [17179570.236000] Bad eraseblock 0 at 0x00000000 [17179570.240000] Bad eraseblock 1 at 0x00020000 [17179570.248000] Bad eraseblock 2 at 0x00040000 [..] [17179579.748000] Bad eraseblock 2046 at 0x0ffc0000 [17179579.752000] Bad eraseblock 2047 at 0x0ffe0000 [17179579.756000] Creating 1 MTD partitions on "NAND 256MiB 3,3V 8-bit": [17179579.760000] 0x00000000-0x10000000 : "NAND FS 0" [17179579.772000] au1xxx-ohci au1xxx-ohci.0: Au1xxx OHCI [..] I get the same output from the .17.7. kernel apart from the 'Bad'-messages. The size seems correct, as I should get one 256MB-flash-device. I did use the patch from Lippert to set their platform data, which was intended for 2.6.17.7. With small changes it also succeeds on 2.6.23.1 but this doesn't mean that it's correct ;) The 2.6.17.7 kernel still runs fine with that flash. I am quite new to kernel hacking and after some cause searching I'm still lost. Were there any changes in the necessary configuration / platform setup that I am missing? Any ideas / hints what I can look for? Any common mistakes? ciao, Thorsten From tsbogend@alpha.franken.de Sun Nov 4 10:06:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 10:06:30 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:52669 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20022636AbXKDKGV (ORCPT ); Sun, 4 Nov 2007 10:06:21 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IocN2-0002Cu-00; Sun, 04 Nov 2007 11:06:20 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id A1AD3C2250; Sun, 4 Nov 2007 11:05:27 +0100 (CET) Date: Sun, 4 Nov 2007 11:05:27 +0100 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] JAZZ: disable PIT; cleanup R4030 clockevent Message-ID: <20071104100527.GA5391@alpha.franken.de> References: <20071101125236.GA16577@alpha.franken.de> <20071101150741.GA8570@linux-mips.org> <20071101160210.GA20366@linux-mips.org> <20071102101713.GA9110@alpha.franken.de> <20071102122001.GC22829@linux-mips.org> <20071102220819.GA20792@alpha.franken.de> <20071104003338.GB28717@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071104003338.GB28717@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: 17385 X-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 Sun, Nov 04, 2007 at 12:33:38AM +0000, Ralf Baechle wrote: > On Fri, Nov 02, 2007 at 11:08:19PM +0100, Thomas Bogendoerfer wrote: > > > On Fri, Nov 02, 2007 at 12:20:01PM +0000, Ralf Baechle wrote: > > > One thing I'm still wondering about, does the kernel actually go tickless > > > for you? > > > > a kernel with CONFIG_NO_HZ boots and acts normal. But it looks like > > the PIT is still ticking at the selected 100HZ... > > I think this happens because the R4030 clockevent device has a rather r4030 is of course disabled in my test. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From KokHow.Teh@infineon.com Sun Nov 4 11:27:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 11:27:31 +0000 (GMT) Received: from smtp3.infineon.com ([203.126.106.229]:39448 "EHLO smtp3.infineon.com") by ftp.linux-mips.org with ESMTP id S20024851AbXKDL1X convert rfc822-to-8bit (ORCPT ); Sun, 4 Nov 2007 11:27:23 +0000 X-SBRS: None Received: from unknown (HELO sinse301.ap.infineon.com) ([172.20.70.22]) by smtp3.infineon.com with ESMTP; 04 Nov 2007 19:26:13 +0800 Received: from sinse303.ap.infineon.com ([172.20.70.24]) by sinse301.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Nov 2007 19:26:13 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: Get stuck in wake_up_process(rq->migration_thread); Date: Sun, 4 Nov 2007 19:26:12 +0800 Message-ID: <31E09F73562D7A4D82119D7F6C17298602B11510@sinse303.ap.infineon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Get stuck in wake_up_process(rq->migration_thread); Thread-Index: Acge1YErxPuWjyVPRty8t31LfT16Jg== From: To: X-OriginalArrivalTime: 04 Nov 2007 11:26:13.0981 (UTC) FILETIME=[821C28D0:01C81ED5] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: KokHow.Teh@infineon.com Precedence: bulk X-list: linux-mips Hi; I have a linux-2.6.20 kernel configured with CONFIG_MIPS_MT_SMP (SMVPE) running on a MIPS34KC processor emulation platform. Everything goes fine until the scheduler gets stuck in trying to wake up the migration thread. I configured the kernel with max_cache_size=2097152, having no idea of what the variable is all about. Putting debug messages in kernel/sched.c tells me that the the migration_thread() routine has gone to sleep calling schedul() function and set_cpus_allowed() function gets stuck in wake_up_process(rq->migration_thread); Any insight is appreciated. Regards. KH From 12o3l@tiscali.nl Sun Nov 4 12:03:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 12:03:25 +0000 (GMT) Received: from smtp-out3.tiscali.nl ([195.241.79.178]:43214 "EHLO smtp-out3.tiscali.nl") by ftp.linux-mips.org with ESMTP id S20024033AbXKDMDQ (ORCPT ); Sun, 4 Nov 2007 12:03:16 +0000 Received: from [82.171.216.234] (helo=[192.168.1.2]) by smtp-out3.tiscali.nl with esmtp (Tiscali http://www.tiscali.nl) id 1Ioe99-0007uf-Cx for ; Sun, 04 Nov 2007 13:00:07 +0100 Message-ID: <472DB446.3020804@tiscali.nl> Date: Sun, 04 Nov 2007 13:00:06 +0100 From: Roel Kluin <12o3l@tiscali.nl> User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: [PATCH] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: <12o3l@tiscali.nl> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: 12o3l@tiscali.nl Precedence: bulk X-list: linux-mips iounmap if pci clock is over 33MHz Signed-off-by: Roel Kluin <12o3l@tiscali.nl> --- diff --git a/arch/mips/pci/pci-vr41xx.c b/arch/mips/pci/pci-vr41xx.c index 240df9e..33c4f68 100644 --- a/arch/mips/pci/pci-vr41xx.c +++ b/arch/mips/pci/pci-vr41xx.c @@ -154,6 +154,7 @@ static int __init vr41xx_pciu_init(void) pciu_write(PCICLKSELREG, QUARTER_VTCLOCK); else { printk(KERN_ERR "PCI Clock is over 33MHz.\n"); + iounmap(pciu_base); return -EINVAL; } From anemo@mba.ocn.ne.jp Sun Nov 4 15:41:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 15:41:36 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:54775 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20029687AbXKDPl2 (ORCPT ); Sun, 4 Nov 2007 15:41:28 +0000 Received: from localhost (p5165-ipad307funabasi.chiba.ocn.ne.jp [123.217.183.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 80BDC9937; Mon, 5 Nov 2007 00:40:06 +0900 (JST) Date: Mon, 05 Nov 2007 00:42:08 +0900 (JST) Message-Id: <20071105.004208.74752504.anemo@mba.ocn.ne.jp> To: fbuihuu@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Kill __bzero() From: Atsushi Nemoto In-Reply-To: <472D8058.5080209@gmail.com> References: <472D8058.5080209@gmail.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sun, 04 Nov 2007 09:18:32 +0100, Franck Bui-Huu wrote: > 2/ For the caller, it makes no difference to call memset instead > since it has to setup the second parameter of __bzero to 0. __bzero() does not clobber v0 but memset() does. I don't know if gcc does some magical thing to protect v0, but it would be safer to add v0 explicitly to clobber-list of __clear_user(). --- Atsushi Nemoto From ths@networkno.de Sun Nov 4 17:47:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 17:47:28 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:28639 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20030801AbXKDRrU (ORCPT ); Sun, 4 Nov 2007 17:47:20 +0000 Received: from lagash (88-106-176-50.dynamic.dsl.as9105.com [88.106.176.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id B974148F89; Sun, 4 Nov 2007 17:34:11 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IojZ0-0003Ga-R2; Sun, 04 Nov 2007 17:47:10 +0000 Date: Sun, 4 Nov 2007 17:47:10 +0000 From: Thiemo Seufer To: Franck Bui-Huu Cc: Nigel Stephens , "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071104174710.GA9363@networkno.de> References: <47126EDC.1060305@gmail.com> <20071014195324.GT3379@networkno.de> <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472D8110.2080506@gmail.com> 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: 17389 X-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 Franck Bui-Huu wrote: > Nigel Stephens wrote: > > Aha, that probably explains it. Franck is using the "SDE for Linux > > v6.05" toolchain, and in that version of GCC -march=mips32r2 implies a > > [snip] > > BTW, are there any other toolchains out there that support smartmips ASE ? Latest GCC upstream supports it (in SVN since 2007-07-05). Thiemo From KevinK@mips.com Sun Nov 4 18:59:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 18:59:36 +0000 (GMT) Received: from mx.mips.com ([63.167.95.198]:43002 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20030957AbXKDS71 (ORCPT ); Sun, 4 Nov 2007 18:59:27 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id lA4IwmeC006509; Sun, 4 Nov 2007 10:58:48 -0800 (PST) Received: from Ulysses (vpn123 [192.168.3.123]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id lA4IxFhN024897; Sun, 4 Nov 2007 10:59:15 -0800 (PST) Message-ID: <002801c81f14$ddda0900$7b03a8c0@Ulysses> From: "Kevin D. Kissell" To: , References: <31E09F73562D7A4D82119D7F6C17298602B11510@sinse303.ap.infineon.com> Subject: Re: Get stuck in wake_up_process(rq->migration_thread); Date: Sun, 4 Nov 2007 10:59:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: KevinK@mips.com Precedence: bulk X-list: linux-mips Your description isn't much to go on, but the first thing I'd look at in such a situation would be the state of the Cause and Status registers on the two VPEs. Cross-VPE scheduling interrupts on the standard emulation platform, which lacks hardware support for cross-VPE interrupts, sends IPIs by reaching across using MTTR instructions and setting a software interrupt bit on the other VPE. Other uses of the same software interrupt (SW1 by default), or manipulations in other kernel code that might clear its IM bit in the Status register, could cause that mechanism to break down and cease processing interprocessor interrupts. It's a common failure mode if one botches a mod to SMTC, and I've seen it on an SMVP port as well. Kevin K. ----- Original Message ----- From: To: Sent: Sunday, November 04, 2007 3:26 AM Subject: Get stuck in wake_up_process(rq->migration_thread); > Hi; > I have a linux-2.6.20 kernel configured with CONFIG_MIPS_MT_SMP > (SMVPE) running on a MIPS34KC processor emulation platform. Everything > goes fine until the scheduler gets stuck in trying to wake up the > migration thread. I configured the kernel with max_cache_size=2097152, > having no idea of what the variable is all about. Putting debug messages > in kernel/sched.c tells me that the the migration_thread() routine has > gone to sleep calling schedul() function and set_cpus_allowed() function > gets stuck in wake_up_process(rq->migration_thread); > Any insight is appreciated. > > Regards. > KH > > From vagabon.xyz@gmail.com Sun Nov 4 20:04:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 20:04:25 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.184]:26161 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20031057AbXKDUEP (ORCPT ); Sun, 4 Nov 2007 20:04:15 +0000 Received: by nf-out-0910.google.com with SMTP id c10so980591nfd for ; Sun, 04 Nov 2007 12:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=773ZBL/AJovEwPAGlxLJafYre52Kq2ruKRg+HmH4sOg=; b=khg2A+zXFJOj1cQvu9zY9ZrpaEDXHdq+UsM+dHc8HL1BP4Hg80MgRHMRcDSZi3+Y2hCsI6pikhbV1FM598RFkhyZtESZK71BQyNN9VgaXPDDvhhkL9CiR2ZQBwOXusTbFslWpnbmrp0yx7lN0KzsdiMJmGRuTlz1cFWqqaficX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=I/Ehm+gkbvkSDpP1WpMgSfdx6qNIq8Y3iD/YX2PO7H61t2vCdOn7s+ulRpLsuqruemT/HRAnRV34B3bxUr0hy3lIn0j84n9iQIzIBdWO8fyzgjosGtOnbEBQEd7QvXppHMmTPKPvSIhqX4LluTzeAm5Lim7lOOL9WiIaQ8/AzQU= Received: by 10.86.60.7 with SMTP id i7mr2782252fga.1194206645645; Sun, 04 Nov 2007 12:04:05 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id f31sm10567379fkf.2007.11.04.12.04.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Nov 2007 12:04:05 -0800 (PST) Message-ID: <472E2570.3020403@gmail.com> Date: Sun, 04 Nov 2007 21:02:56 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Atsushi Nemoto CC: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Kill __bzero() References: <472D8058.5080209@gmail.com> <20071105.004208.74752504.anemo@mba.ocn.ne.jp> In-Reply-To: <20071105.004208.74752504.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Atsushi Nemoto wrote: > On Sun, 04 Nov 2007 09:18:32 +0100, Franck Bui-Huu wrote: >> 2/ For the caller, it makes no difference to call memset instead >> since it has to setup the second parameter of __bzero to 0. > > __bzero() does not clobber v0 but memset() does. I don't know if gcc > does some magical thing to protect v0, but it would be safer to add v0 > explicitly to clobber-list of __clear_user(). > good catch ! I'll do it. thanks Franck From fbuihuu@gmail.com Sun Nov 4 20:14:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 20:14:43 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.184]:32095 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20031057AbXKDUOf (ORCPT ); Sun, 4 Nov 2007 20:14:35 +0000 Received: by nf-out-0910.google.com with SMTP id c10so982036nfd for ; Sun, 04 Nov 2007 12:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=5Xm9jcuqI1EtgdLfe0qOV0zdK8dvncE3HsM/fsA/VLU=; b=jNanxCbm4MATErYmsHmN2RvUxICrJNInVbzRbFfqquJb/gj+eJe/RnFKZdZAaiybnXMOJaNGSazWsGKND8rlH0HiqETWhc1EGQgbjZOweN2RG70uZF5V8iswYbrl/89TZ5LCvWDAVh4YKIQHfnaRBVyYYXKCmvE1rjNqw/1JBps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=iHsLHVjQUFeUVdE9v/pccfbbFEC0uIpMiTwMX9ZosTNlvKssB5tLWx03pAAwX8izn+XS8BsCToJ+6gH8M8i/ILLLols4wSGo8G+FzdOiAi9TMs4+JcV6ZQYLgikNbeT4mQLlfPU6j3r8ULE+p8vpxu5iKv/Z+JER2HAflwppZUo= Received: by 10.86.86.12 with SMTP id j12mr2796067fgb.1194207264778; Sun, 04 Nov 2007 12:14:24 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id y6sm12861978mug.2007.11.04.12.14.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Nov 2007 12:14:23 -0800 (PST) Message-ID: <472E27D7.9030602@gmail.com> Date: Sun, 04 Nov 2007 21:13:11 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , linux-mips Subject: [PATCH] Kill __bzero() [take #2] X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips This patch removes this function because: 1/ Its unconventional prototype is error prone: its prototype is the same as memset one but was documented by mips_ksym.c like the following: extern void *__bzero(void *__s, size_t __count); 2/ For the caller, it makes no difference to call memset instead since it has to setup the second parameter of __bzero to 0. 3/ It's not part of the Linux user access API, so no module can use it. 4/ It needs to be exported with EXPORT_SYMBOL and therefore consumes some extra bytes. 5/ It has only one user. Signed-off-by: Franck Bui-Huu --- This take includes Atsushi's comment. Franck arch/mips/kernel/mips_ksyms.c | 2 -- arch/mips/lib/csum_partial.S | 2 +- arch/mips/lib/memcpy.S | 2 +- arch/mips/lib/memset.S | 4 +--- include/asm-mips/uaccess.h | 4 ++-- 5 files changed, 5 insertions(+), 9 deletions(-) diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c index 225755d..6da9fa8 100644 --- a/arch/mips/kernel/mips_ksyms.c +++ b/arch/mips/kernel/mips_ksyms.c @@ -14,7 +14,6 @@ #include #include -extern void *__bzero(void *__s, size_t __count); extern long __strncpy_from_user_nocheck_asm(char *__to, const char *__from, long __len); extern long __strncpy_from_user_asm(char *__to, const char *__from, @@ -38,7 +37,6 @@ EXPORT_SYMBOL(kernel_thread); */ EXPORT_SYMBOL(__copy_user); EXPORT_SYMBOL(__copy_user_inatomic); -EXPORT_SYMBOL(__bzero); EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm); EXPORT_SYMBOL(__strncpy_from_user_asm); EXPORT_SYMBOL(__strlen_user_nocheck_asm); diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index c0a77fe..8d3fa1e 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -694,7 +694,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..425f2c3 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -443,7 +443,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 3f8b8b3..a13248b 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -46,7 +46,7 @@ .endm /* - * memset(void *s, int c, size_t n) + * void *memset(void *s, int c, size_t n) * * a0: start of area to clear * a1: char to fill with @@ -68,8 +68,6 @@ LEAF(memset) #endif or a1, t1 1: - -FEXPORT(__bzero) sltiu t0, a2, LONGSIZE /* very small region? */ bnez t0, small_memset andi t0, a0, LONGMASK /* aligned? */ diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index c30c718..35c5fad 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -643,11 +643,11 @@ __clear_user(void __user *addr, __kernel_size_t size) "move\t$4, %1\n\t" "move\t$5, $0\n\t" "move\t$6, %2\n\t" - __MODULE_JAL(__bzero) + __MODULE_JAL(memset) "move\t%0, $6" : "=r" (res) : "r" (addr), "r" (size) - : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31"); + : "$2", "$4", "$5", "$6", __UA_t0, __UA_t1, "$31"); return res; } -- 1.5.3.4 From vagabon.xyz@gmail.com Sun Nov 4 20:20:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 20:21:02 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:45941 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20031037AbXKDUUx (ORCPT ); Sun, 4 Nov 2007 20:20:53 +0000 Received: by nf-out-0910.google.com with SMTP id c10so982898nfd for ; Sun, 04 Nov 2007 12:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=rg5FZYmd7jDiYl+851gemUjlm5PSUS71CMwOLnVNduE=; b=fcNKCI3AeWEYuCc/yT9UzTlPPxKjddoJm64fW6H6bSAgzY5Mu0d20dsTin8cYj0QuGyghUIqGjzODJHQ2cRAnbAjzFjkpCra+AKuJjYivh+UJ0msS44HNXj411XRcNbMrU7Nocr+ZWCv79kyjG7/xoANxVx//tp/uggqi/kciD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=mqURhfT1PUYhXzi2W6uRzYGaV9yM5uLHOCf8SQa8peDOZYqSUUh8SzIxaXXzOUVYSYCJu5vtnZ7pFM0nHyzyfbgE5v17ZFRAOfHTuV8SJjMabWqwmuLZArW2RuBjvP50xjklE26qKwSZv8hkEbNrNLpJQw8SUFanLQqvJs7xRfU= Received: by 10.86.86.12 with SMTP id j12mr2781116fgb.1194207643382; Sun, 04 Nov 2007 12:20:43 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j12sm3231868fkf.2007.11.04.12.20.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Nov 2007 12:20:42 -0800 (PST) Message-ID: <472E2955.3000803@gmail.com> Date: Sun, 04 Nov 2007 21:19:33 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Thiemo Seufer CC: Nigel Stephens , "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <47126EDC.1060305@gmail.com> <20071014195324.GT3379@networkno.de> <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> In-Reply-To: <20071104174710.GA9363@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > > Latest GCC upstream supports it (in SVN since 2007-07-05). > Good news although gcc 4.3 release is planed for end of January. Is SDE gcc going to be obsolete after this release ? Franck From yoichi_yuasa@tripeaks.co.jp Sun Nov 4 22:28:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Nov 2007 22:28:57 +0000 (GMT) Received: from mo32.po.2iij.NET ([210.128.50.17]:21065 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20031681AbXKDW2t (ORCPT ); Sun, 4 Nov 2007 22:28:49 +0000 Received: by mo.po.2iij.net (mo32) id lA4MRTqD015970; Mon, 5 Nov 2007 07:27:29 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox302) id lA4MRNei008200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Nov 2007 07:27:24 +0900 Date: Mon, 5 Nov 2007 07:27:23 +0900 From: Yoichi Yuasa To: Roel Kluin <12o3l@tiscali.nl> Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips@linux-mips.org Subject: Re: [PATCH] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz Message-Id: <20071105072723.0f5abee3.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <472DB446.3020804@tiscali.nl> References: <472DB446.3020804@tiscali.nl> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-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: 17394 X-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 On Sun, 04 Nov 2007 13:00:06 +0100 Roel Kluin <12o3l@tiscali.nl> wrote: > iounmap if pci clock is over 33MHz > > Signed-off-by: Roel Kluin <12o3l@tiscali.nl> Acked-by: Yoichi Yuasa > --- > diff --git a/arch/mips/pci/pci-vr41xx.c b/arch/mips/pci/pci-vr41xx.c > index 240df9e..33c4f68 100644 > --- a/arch/mips/pci/pci-vr41xx.c > +++ b/arch/mips/pci/pci-vr41xx.c > @@ -154,6 +154,7 @@ static int __init vr41xx_pciu_init(void) > pciu_write(PCICLKSELREG, QUARTER_VTCLOCK); > else { > printk(KERN_ERR "PCI Clock is over 33MHz.\n"); > + iounmap(pciu_base); > return -EINVAL; > } > > > From veerasena_b@yahoo.co.in Mon Nov 5 10:01:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 10:01:54 +0000 (GMT) Received: from n7.bullet.mud.yahoo.com ([216.252.100.58]:53614 "HELO n7.bullet.mud.yahoo.com") by ftp.linux-mips.org with SMTP id S20029776AbXKEKBp convert rfc822-to-8bit (ORCPT ); Mon, 5 Nov 2007 10:01:45 +0000 Received: from [209.191.108.97] by n7.bullet.mud.yahoo.com with NNFMP; 05 Nov 2007 10:01:34 -0000 Received: from [209.191.119.153] by t4.bullet.mud.yahoo.com with NNFMP; 05 Nov 2007 10:01:34 -0000 Received: from [127.0.0.1] by omp100.mail.mud.yahoo.com with NNFMP; 05 Nov 2007 10:01:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 474277.26548.bm@omp100.mail.mud.yahoo.com Received: (qmail 32016 invoked by uid 60001); 5 Nov 2007 10:01:32 -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:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ng4kQyqnC2NdQpMOT5vZRBk+XIEdPisPyC4hie7qOO5TbaZkwnpMuo1S4C2gnShfYfioaguLvqJrC6WuWtP84/kI453gu7QKXfHjfK075BocI2QbZUpIZP3c2GmRPw18X/+G0q+cDlXuyd2bqP26DCL3y4g6tADsotMTl33bdfY=; X-YMail-OSG: zfKk4pUVM1k7P1UoheFrliF17TB3IPykPkr4pi11.1g9qfDWQLfDV_BkSzDMIC6gTZYEdKfS8ZdmJNitjLEblqwa0y6fD2MbzyNXj8ACWbY8cWPFcXo- Received: from [199.239.167.162] by web8411.mail.in.yahoo.com via HTTP; Mon, 05 Nov 2007 15:31:32 IST X-Mailer: YahooMailRC/814.06 YahooMailWebService/0.7.152 Date: Mon, 5 Nov 2007 15:31:32 +0530 (IST) From: veerasena reddy Subject: Re: NPTL support To: Markus Gothe Cc: 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: <279675.30374.qm@web8411.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: 17395 X-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 Markus, thanks for the information. i checked out uclibc-nptl (version 0.9.29). is it a stable release? If i want to build toolchain using buildroot with nptl support for linux kernel 2.6.18.8, could you please guide us the right version of buildroot, binutils, and gcc to be used. Thanks & Regards, Veerasena. ----- Original Message ---- From: Markus Gothe To: veerasena reddy Cc: uclibc@uclibc.org; linux-mips ; linux-kernel.org ; buildroot@uclibc.org Sent: Friday, 2 November, 2007 6:01:41 PM Subject: Re: NPTL support 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 > 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 > > _______________________________________ 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 Did you know? You can CHAT without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php/ From ralf@linux-mips.org Mon Nov 5 11:24:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 11:24:48 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37023 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029888AbXKELYq (ORCPT ); Mon, 5 Nov 2007 11:24:46 +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 lA5BOTV9028519; Mon, 5 Nov 2007 11:24:29 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5BOT0r028518; Mon, 5 Nov 2007 11:24:29 GMT Date: Mon, 5 Nov 2007 11:24:29 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips Subject: Re: [PATCH] Kill __bzero() Message-ID: <20071105112429.GC27893@linux-mips.org> References: <472D8058.5080209@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472D8058.5080209@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: 17396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Nov 04, 2007 at 09:18:32AM +0100, Franck Bui-Huu wrote: > 1/ Its unconventional prototype is error prone: its prototype is > the same as memset one but was documented by mips_ksym.c like the > following: > > extern void *__bzero(void *__s, size_t __count); > > 2/ For the caller, it makes no difference to call memset instead > since it has to setup the second parameter of __bzero to 0. > > 3/ It's not part of the Linux user access API, so no module can use > it. > > 4/ It needs to be exported with EXPORT_SYMBOL and therefore consumes > some extra bytes. > > 5/ It has only one user. > > Signed-off-by: Franck Bui-Huu > --- > > I'm wondering if I'm missing something, because this function seems > so ugly and useless in the first place, that I can't refrain to > submit a patch to get rid of it. Memset is almost always only ever invoked with a zero argument. So the idea was to have something like this: extern void *__memset(void *__s, int __c, size_t __count); extern void *bzero(void *__s, size_t __count); static inline void *memset(void *s, int c, size_t count) { if (__builtin_constant_p(c) && c == 0) { bzero(s, count); return s; } else return __memset(s, __c, count); } But that was never quite implemented like this as you noticed. As for the differences in the return value, they're because of of clear_user and __clear_user which return the number of bytes that could _not_ be cleared in $a2. Memset being invoked through the normal C calling conventions ignores this value while it's the actual result of interest for __clear_user. I hope that explains things a little. Ralf From ralf@linux-mips.org Mon Nov 5 11:36:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 11:36:39 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:35476 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029899AbXKELgh (ORCPT ); Mon, 5 Nov 2007 11:36:37 +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 lA5BaKxf028649; Mon, 5 Nov 2007 11:36:20 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5BaIZO028648; Mon, 5 Nov 2007 11:36:18 GMT Date: Mon, 5 Nov 2007 11:36:18 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , Nigel Stephens , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071105113618.GD27893@linux-mips.org> References: <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> <472E2955.3000803@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472E2955.3000803@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: 17397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Nov 04, 2007 at 09:19:33PM +0100, Franck Bui-Huu wrote: > > Latest GCC upstream supports it (in SVN since 2007-07-05). > > > > Good news although gcc 4.3 release is planed for end of January. > > Is SDE gcc going to be obsolete after this release ? As for the kernel I don't really care. The policy is that a working kernel must be buildable with a stock gcc. Which at times is painful, search for all the great use of .word in include/asm-mips/ ... This doesn't say anything against taking advantage of other toolchains such SDE; it's just the functionality must be there with a vanilla GNU toolchain of the miminum supported version which currently still is 3.2. Ralf From ralf@linux-mips.org Mon Nov 5 11:43:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 11:43:31 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:9936 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029893AbXKELn3 (ORCPT ); Mon, 5 Nov 2007 11:43: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 lA5BhDQU028741; Mon, 5 Nov 2007 11:43:13 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5BhDCB028740; Mon, 5 Nov 2007 11:43:13 GMT Date: Mon, 5 Nov 2007 11:43:13 +0000 From: Ralf Baechle To: Roel Kluin <12o3l@tiscali.nl> Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz Message-ID: <20071105114313.GE27893@linux-mips.org> References: <472DB446.3020804@tiscali.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472DB446.3020804@tiscali.nl> 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: 17398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Nov 04, 2007 at 01:00:06PM +0100, Roel Kluin wrote: > iounmap if pci clock is over 33MHz Applied. Note that this is purely cosmetic; for 64-bit kernels or anything in the low 512MB of physcial address space ioremap on a 32-bit kernel ioremap can never fail on MIPS and iounmap is a nop in this case. Ralf From ralf@linux-mips.org Mon Nov 5 11:47:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 11:47:15 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:23484 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029905AbXKELrN (ORCPT ); Mon, 5 Nov 2007 11:47:13 +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 lA5BkvWC029814; Mon, 5 Nov 2007 11:46:57 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5BkuSa029777; Mon, 5 Nov 2007 11:46:56 GMT Date: Mon, 5 Nov 2007 11:46:56 +0000 From: Ralf Baechle To: Roel Kluin <12o3l@tiscali.nl> Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Use strchr instead of strstr in mips/fw/arc/cmdline.c Message-ID: <20071105114655.GF27893@linux-mips.org> References: <472B7379.4030003@tiscali.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472B7379.4030003@tiscali.nl> 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: 17399 X-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 07:59:05PM +0100, Roel Kluin wrote: > Use strchr instead of strstr when searching for a single character > > Signed-off-by: Roel Kluin <12o3l@tiscali.nl> Thanks, queued for 2.6.25. Ralf From markus.gothe@27m.se Mon Nov 5 12:25:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 12:25:12 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:8593 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20029907AbXKEMZD (ORCPT ); Mon, 5 Nov 2007 12:25:03 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 47498200A24A; Mon, 5 Nov 2007 13:24:59 +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 21638-01-99; Mon, 5 Nov 2007 13:24:56 +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 E3BA9200A229; Mon, 5 Nov 2007 13:24:55 +0100 (CET) Message-ID: <472F0B96.4080205@27m.se> Date: Mon, 05 Nov 2007 13:24:54 +0100 From: Markus Gothe User-Agent: Icedove 1.5.0.14pre (X11/20071020) MIME-Version: 1.0 To: veerasena reddy Cc: uclibc@uclibc.org, linux-mips , "linux-kernel.org" , buildroot@uclibc.org Subject: Re: NPTL support References: <279675.30374.qm@web8411.mail.in.yahoo.com> In-Reply-To: <279675.30374.qm@web8411.mail.in.yahoo.com> 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: 17400 X-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 I don't use neither buildroot nor uClibc-nptl, due to uClibc-nptl is a (dev-)branch and not a release. It differs quite a lot from the 0.9.29 release. //Markus veerasena reddy wrote: > Hi Markus, > > thanks for the information. > > i checked out uclibc-nptl (version 0.9.29). is it a stable release? > If i want to build toolchain using buildroot with nptl support for > linux kernel 2.6.18.8, could you please guide us the right version > of buildroot, binutils, and gcc to be used. > > Thanks & Regards, Veerasena. > > ----- Original Message ---- From: Markus Gothe > To: veerasena reddy > Cc: uclibc@uclibc.org; linux-mips > ; linux-kernel.org > ; buildroot@uclibc.org Sent: Friday, > 2 November, 2007 6:01:41 PM Subject: Re: NPTL support > > 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 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 >> >> > > _______________________________________ > > 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 > > > Did you know? You can CHAT without downloading messenger. Go to > http://in.messenger.yahoo.com/webmessengerpromo.php/ > > - -- _______________________________________ 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 iD8DBQFHLwuS6I0XmJx2NrwRCLRDAJ9O5mtOAtncebZ9yTZoZpWQLD7hKwCghfdz IlaSKs6XX+dD6dqC5YFYbRY= =/Kz+ -----END PGP SIGNATURE----- From macro@linux-mips.org Mon Nov 5 12:38:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 12:38:52 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:13998 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20029944AbXKEMio (ORCPT ); Mon, 5 Nov 2007 12:38:44 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 8B7D64003B; Mon, 5 Nov 2007 13:38:14 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id wiQkQxpME0b2; Mon, 5 Nov 2007 13:38:08 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id B989E400A6; Mon, 5 Nov 2007 13:38:07 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA5Cc9Dl024326; Mon, 5 Nov 2007 13:38:10 +0100 Date: Mon, 5 Nov 2007 12:38:06 +0000 (GMT) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Ralf Baechle , Geert Uytterhoeven , linux-mips Subject: Re: [RFC] Add __initbss section In-Reply-To: <472D82D1.1050401@gmail.com> Message-ID: References: <470DF25E.60009@gmail.com> <4712738A.5000703@gmail.com> <4713C840.8080206@gmail.com> <4717C1FB.4030602@gmail.com> <472D82D1.1050401@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4673/Sun Nov 4 23:22:25 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, 4 Nov 2007, Franck Bui-Huu wrote: > > Hmm, isn't what `info ld' says enough? > > Hmm, I'm must be blind but I missed that each time I read it. Could > you point out the section number please ? That's section 3.8, I would guess, but if what you are looking for is not there, then perhaps the description could be improved. Maciej From ralf@linux-mips.org Mon Nov 5 13:03:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 13:03:18 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:2447 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029963AbXKENDP (ORCPT ); Mon, 5 Nov 2007 13:03:15 +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 lA5D2xKj031224 for ; Mon, 5 Nov 2007 13:02:59 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5D2xSP031223 for linux-mips@linux-mips.org; Mon, 5 Nov 2007 13:02:59 GMT Date: Mon, 5 Nov 2007 13:02:59 +0000 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Deleting read-only environment variable on Sibyte board. Message-ID: <20071105130259.GA31023@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 17402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips I've got a read-only environment variable on my Sibyte/Broadcom Bigsur system. Annoyingly it's the network address. Any help on how to delete such an undeletable environment variable would be welcome. Thanks, Ralf From giuseppe@eppesuigoccas.homedns.org Mon Nov 5 13:15:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 13:15:19 +0000 (GMT) Received: from host187-206-dynamic.8-87-r.retail.telecomitalia.it ([87.8.206.187]:5506 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20029976AbXKENPK (ORCPT ); Mon, 5 Nov 2007 13:15:10 +0000 Received: from 89-96-243-184.ip14.fastwebnet.it ([89.96.243.184] helo=[192.168.215.30]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ip1nF-00012L-AU for linux-mips@linux-mips.org; Mon, 05 Nov 2007 14:15:07 +0100 Subject: Re: 2.6.24-rc1 does not boot on SGI From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: <20071029150625.GB4165@linux-mips.org> References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> Content-Type: text/plain Date: Mon, 05 Nov 2007 14:15:51 +0100 Message-Id: <1194268551.4842.3.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Ralf, Il giorno lun, 29/10/2007 alle 15.06 +0000, Ralf Baechle ha scritto: > On Sun, Oct 28, 2007 at 08:17:11PM +0100, Giuseppe Sacco wrote: > > > Nothing changed using this patch: the system does not boot. Currently I > > suspect the reason is the change the IRQ handling because it is the main > > change in arch/mips/sg-ip32. > > All the patch was meant to is to renumber interrupts so interrupts 0 ... 7 > become available for use with cpu_irq.c. Irq 7 is the cp0 compare interrupt > which on IP32 is used as the clockevent device that is the source of > timer interrupts. The latest git update, gave a bootable 2.6.24-rc1 but now, while booting, the system start looping and calling function print_irq_desc() from kernel/irq/internals.h. I can only read "...count:...unhandled:..." since the text scroll too quickly, but I will try to connect a serial console in order to send here the complete message. Bye, Giuseppe From tbm@cyrius.com Mon Nov 5 14:13:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 14:13:43 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:32015 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20030031AbXKEONf (ORCPT ); Mon, 5 Nov 2007 14:13:35 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 478E0D8D1; Mon, 5 Nov 2007 14:12:59 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 941097D111; Mon, 5 Nov 2007 15:12:48 +0100 (CET) Date: Mon, 5 Nov 2007 15:12:48 +0100 From: Martin Michlmayr To: debian-mips@lists.debian.org Cc: debian-boot@lists.debian.org, hardware-donations@debian.org, linux-mips@linux-mips.org Subject: Re: Donation of an Indigo 2 R4K@250 Message-ID: <20071105141248.GQ6244@deprecation.cyrius.com> 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: 17404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips If anyone is interested in an Indigo 2 located in Cologne, Germany, please let me know. > I would like to donate the MIPS porters an SGI Indigo 2 R4K@250Mhz. > Fully working, keyboard/mouse/monitor included, but no IRIX. > > The machine is located in Cologne/Germany - pickup preferred... -- Martin Michlmayr http://www.cyrius.com/ From nigel@mips.com Mon Nov 5 16:01:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 16:01:38 +0000 (GMT) Received: from dmz.mips-uk.com ([194.74.144.194]:39941 "EHLO dmz.mips-uk.com") by ftp.linux-mips.org with ESMTP id S20030388AbXKEQBa (ORCPT ); Mon, 5 Nov 2007 16:01:30 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1Ip4LD-00041K-00; Mon, 05 Nov 2007 15:58:19 +0000 Received: from ukcvpn18.mips-uk.com ([192.168.193.18]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1Ip4L6-0002kv-00; Mon, 05 Nov 2007 15:58:12 +0000 Message-ID: <472F3D93.1070400@mips.com> Date: Mon, 05 Nov 2007 15:58:11 +0000 From: Nigel Stephens User-Agent: IceDove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Franck Bui-Huu CC: Thiemo Seufer , "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <47126EDC.1060305@gmail.com> <20071014195324.GT3379@networkno.de> <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> <472E2955.3000803@gmail.com> In-Reply-To: <472E2955.3000803@gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.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: 17405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nigel@mips.com Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > Thiemo Seufer wrote: > >> Latest GCC upstream supports it (in SVN since 2007-07-05). >> >> > > Good news although gcc 4.3 release is planed for end of January. > Franck A supported toolchain which now includes SmartMIPS support is the CodeSourcery MIPS Linux toolchain, based on gcc-4.2, see http://www.codesourcery.com/store/catalogue/c3/p17 > Is SDE gcc going to be obsolete after this release ? > A pre-built "bare-iron" SDE configuration of GCC will probably continue to exist as part of the MIPS cross-development tools, but we are working to ensure that as many as possible of the SDE changes are available upstream for use by other Linux or GNU toolchain vendors, and/or those who wish to roll their own toolchain. Nigel -- Nigel Stephens | 7200 Cambridge Research Park | t:[+44|0]1223 203110 MIPS Technologies | Cambridge, England CB25 9TL | f:[+44|0]1223 203181 From giuseppe@eppesuigoccas.homedns.org Mon Nov 5 16:59:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 16:59:55 +0000 (GMT) Received: from host94-201-dynamic.14-87-r.retail.telecomitalia.it ([87.14.201.94]:37760 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20030567AbXKEQ7r (ORCPT ); Mon, 5 Nov 2007 16:59:47 +0000 Received: from casa ([192.168.2.34] helo=eppesuigoccas.homedns.org) by eppesuigoccas.homedns.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ip5Fa-00011e-Gi for linux-mips@linux-mips.org; Mon, 05 Nov 2007 17:56:36 +0100 Received: from giuseppe by eppesuigoccas.homedns.org with local (Exim 4.63) (envelope-from ) id 1Ip5E3-00016H-Qs for linux-mips@linux-mips.org; Mon, 05 Nov 2007 17:54:59 +0100 Subject: Re: 2.6.24-rc1 does not boot on SGI From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: <1194268551.4842.3.camel@scarafaggio> References: <1193468825.7474.6.camel@scarafaggio> <20071029.000713.59464443.anemo@mba.ocn.ne.jp> <1193599031.14874.1.camel@scarafaggio> <20071029150625.GB4165@linux-mips.org> <1194268551.4842.3.camel@scarafaggio> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 05 Nov 2007 17:54:59 +0100 Message-Id: <1194281699.4192.3.camel@casa> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Il giorno lun, 05/11/2007 alle 14.15 +0100, Giuseppe Sacco ha scritto: [...] > The latest git update, gave a bootable 2.6.24-rc1 but now, while > booting, the system start looping and calling function print_irq_desc() > from kernel/irq/internals.h. I can only read "...count:...unhandled:..." [...] Here it is: sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.20 sr 0:0:4:0: Attached scsi CD-ROM sr0 mice: PS/2 mouse device common for all mice irq 13, desc: ffffffff804486e0, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff800663c0, handle_bad_irq+0x0/0x2c0 ->chip(): ffffffff8043e320, 0xffffffff8043e320 ->action(): 0000000000000000 IRQ_DISABLED set unexpected IRQ # 13 irq 13, desc: ffffffff804486e0, depth: 1, count: 0, unhandled: 0 ->handle_irq(): ffffffff800663c0, handle_bad_irq+0x0/0x2c0 ->chip(): ffffffff8043e320, 0xffffffff8043e320 ->action(): 0000000000000000 IRQ_DISABLED set unexpected IRQ # 13 and keep printing about interrupt #13. The log from the start is available here http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-2.6.24-rc1-unexpted-irq13.log.bz Bye, Giuseppe From vagabon.xyz@gmail.com Mon Nov 5 20:34:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 20:34:26 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.189]:56538 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20031328AbXKEUeS (ORCPT ); Mon, 5 Nov 2007 20:34:18 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1245627nfd for ; Mon, 05 Nov 2007 12:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=n+dXS9t+JH/C7q/97YHe72YFCvMfojFJol6dfXQgII8=; b=L45Gv7dGPf3QahE5Adk529hVlvRAOLsRD4CcCyuhxlotU5w5OEJ5rrWoDbC26Fh25huRTWrNy9Szl+FXJb30huGwXZOuQ9quyeV1zh72OwxM5KGPEkXlfPADAg+1f7EqStl7l9KvJ3L9kq8M0Er2qWYQTiXQ8iGGc/tJYvUADAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SAuepVkXfIqrzzo2mCge9d2Xhr+oknnQ8+C5LoUo5YCvy/CktwCd7V9fKqfIeFP0xqd1Rr3V0ZBjH6K41wx4aFSdD2guJmqBc1Eh2gFQEN8ms3F211mDTCg/nYVQOCE7TjAkG2Hsnqbnuhmr1reuY/NMCSEhOi2LRXobEQ2CPss= Received: by 10.86.99.9 with SMTP id w9mr3699336fgb.1194294847691; Mon, 05 Nov 2007 12:34:07 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id d13sm13028367fka.2007.11.05.12.34.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Nov 2007 12:34:06 -0800 (PST) Message-ID: <472F7DF2.10901@gmail.com> Date: Mon, 05 Nov 2007 21:32:50 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Geert Uytterhoeven , linux-mips Subject: Re: [RFC] Add __initbss section References: <470DF25E.60009@gmail.com> <4712738A.5000703@gmail.com> <4713C840.8080206@gmail.com> <4717C1FB.4030602@gmail.com> <472D82D1.1050401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Sun, 4 Nov 2007, Franck Bui-Huu wrote: > >>> Hmm, isn't what `info ld' says enough? >> Hmm, I'm must be blind but I missed that each time I read it. Could >> you point out the section number please ? > > That's section 3.8, I would guess, but if what you are looking for is not > there, then perhaps the description could be improved. > After reading section 3.8 "PHDRS Command", I still fail to find something interesting. Franck From vagabon.xyz@gmail.com Mon Nov 5 20:44:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 20:45:02 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.189]:25011 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S28575294AbXKEUow (ORCPT ); Mon, 5 Nov 2007 20:44:52 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1735733fka for ; Mon, 05 Nov 2007 12:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=gw6EXNvxV40Jzla3qHU6BCiO8rXpSjk+jnwq4POPzdE=; b=oEgyyLR9b5gdm/7PwT+JtCzUgIx82FacBGm2HYGYdRbo6skZauatbEU6RYa6ohy5zePX/UPuVPu4pKeiNlscJ0Yo3T/2zlftJObVeBCEFbf72Yk4uGp0fq/nqttZABMJ6kFmoS10UKk6RZSffGfXzU0kSqzNuWn72Xfy7bW8MPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Yin+I+KRZ1sQ3uxENC+wtIwElrYEt0kbQ0mLdBfUFjRvRXqG6k5Qk6Y4TL+939sVrHPZ9a2asFL8sKzO84yRNcpg5Rtdct7nRJuBaqzbrVYQRPDOrCCOzZHMp0Bj0bmQP0G+dgA1ANfyy1jS2dKTO4HYKfy0lWygmEGzBGw0VTw= Received: by 10.82.124.10 with SMTP id w10mr10184136buc.1194295482329; Mon, 05 Nov 2007 12:44:42 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j9sm15646076mue.2007.11.05.12.44.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Nov 2007 12:44:41 -0800 (PST) Message-ID: <472F806C.3060005@gmail.com> Date: Mon, 05 Nov 2007 21:43:24 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Nigel Stephens CC: Thiemo Seufer , "Maciej W. Rozycki" , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <47126EDC.1060305@gmail.com> <20071014195324.GT3379@networkno.de> <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> <472E2955.3000803@gmail.com> <472F3D93.1070400@mips.com> In-Reply-To: <472F3D93.1070400@mips.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Nigel Stephens wrote: > > A supported toolchain which now includes SmartMIPS support is the > CodeSourcery MIPS Linux toolchain, based on gcc-4.2, see > http://www.codesourcery.com/store/catalogue/c3/p17 Interesting. It seems that MIPS toolchains are not part of the 'lite edition' though. Thanks, Franck From vagabon.xyz@gmail.com Mon Nov 5 21:36:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 21:36:27 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.187]:27231 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S28575972AbXKEVgS (ORCPT ); Mon, 5 Nov 2007 21:36:18 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1261011nfd for ; Mon, 05 Nov 2007 13:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=GJC0VXEXYsZPLUh30Cg4JEpZYB62wXM/i4of6WajLw8=; b=JHOfMhivng1+2SJb6PmltTZleQvPxfRnAaxApOLJZqXJX5w8yJ2EBpDo9RCGwe2YhDpfaZKMe0UJw0hlIvZ+A0sU7FCLr4hvcsv5CNpaxb9J3NyNFmIHV8KKyI+bAcP+b/9dBT09pZ+WSTVsn7CT5JNlqe6opH39WgeNR0/eyoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CLaImnFetrNbbxpFhXtT+Cnmof4KFt9c28mmo0VRMu0cnEXe1kuhR4ohbMbB5DRqrFQocKf28Jq2/msrGrrABxOMm2gv6j57F+S8a3aRbSVgb7pQD0ZfCZpiysIG2kWhxMq+Q11HA2c7vTecx55Z1bZaGtjryAF6xYe1sB07O30= Received: by 10.86.87.5 with SMTP id k5mr199657fgb.1194298577599; Mon, 05 Nov 2007 13:36:17 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id p9sm13081710fkb.2007.11.05.13.36.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Nov 2007 13:36:16 -0800 (PST) Message-ID: <472F8C82.4080406@gmail.com> Date: Mon, 05 Nov 2007 22:34:58 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , Nigel Stephens , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <4713C11F.3010903@gmail.com> <4713C958.8080805@mips.com> <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> <472E2955.3000803@gmail.com> <20071105113618.GD27893@linux-mips.org> In-Reply-To: <20071105113618.GD27893@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Sun, Nov 04, 2007 at 09:19:33PM +0100, Franck Bui-Huu wrote: > >>> Latest GCC upstream supports it (in SVN since 2007-07-05). >>> >> Good news although gcc 4.3 release is planed for end of January. >> >> Is SDE gcc going to be obsolete after this release ? > > As for the kernel I don't really care. The policy is that a working kernel > must be buildable with a stock gcc. Which at times is painful, search for > all the great use of .word in include/asm-mips/ ... This doesn't say > anything against taking advantage of other toolchains such SDE; it's just It's actually hard to know the advantages of using SDE over a stock gcc. The only difference I'm aware of is the smartmips ASE support in SDE. But since this support is going to be added in stock gccs, I don't see any advantages now and I'm wondering if I can give up using SDE... Franck From vagabon.xyz@gmail.com Mon Nov 5 21:53:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 21:53:11 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.184]:5750 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S28576552AbXKEVxD (ORCPT ); Mon, 5 Nov 2007 21:53:03 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1753014fka for ; Mon, 05 Nov 2007 13:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=inh8iKzawZia56oMbQDxyWoH94RvI7v6wBeNxKsNI80=; b=Ar9EFX2MyWpKmn6kgDkM4y2KMjNF9gMTCw6fHBUwd1NeOKXz02tuOAXjsrb0RR5p81UWxCqqtpSu5IC4Hp97tjkSER7Kh63bzL0xiHQIqlIX5kqi0If0cHw/No7n6EDRZ+nHRLibN3r7i4/oKCBj40OCQ0QZpR6dpLyRcAS9z4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=mhOwj1nqf5cbOBnLmxrac63BOSlDjl6uMQAzTpFz4ZIzSX+Pvac2SmSp/+vz0A5azpfwL01eoc3RmpH4F5QKAju27EUzCH47LXXZToSdMGXSgktF2+zPBgg0Vz7ueDYW5x1UTYK5se5pZ0oBUguqq+gpBynMWkLUBkSYAB422II= Received: by 10.82.114.3 with SMTP id m3mr9670823buc.1194299581591; Mon, 05 Nov 2007 13:53:01 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j9sm15788325mue.2007.11.05.13.53.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Nov 2007 13:53:00 -0800 (PST) Message-ID: <472F906F.7080205@gmail.com> Date: Mon, 05 Nov 2007 22:51:43 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Franck Bui-Huu , linux-mips Subject: Re: [PATCH] Kill __bzero() References: <472D8058.5080209@gmail.com> <20071105112429.GC27893@linux-mips.org> In-Reply-To: <20071105112429.GC27893@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > > Memset is almost always only ever invoked with a zero argument. So the > idea was to have something like this: > > extern void *__memset(void *__s, int __c, size_t __count); > extern void *bzero(void *__s, size_t __count); > > static inline void *memset(void *s, int c, size_t count) > { > if (__builtin_constant_p(c) && c == 0) { > bzero(s, count); > return s; > } else > return __memset(s, __c, count); > } > > But that was never quite implemented like this as you noticed. Well I'm not sure we really need this. bzero() is not part of the Linux string API, so it can only be used by MIPS specific code. And with the current implementation of bzero(), $a1 needs to be setup to 0 anyway. That's why I simply killed it... BTW, can memset() be an inlined function ? > > As for the differences in the return value, they're because of of > clear_user and __clear_user which return the number of bytes that could > _not_ be cleared in $a2. Memset being invoked through the normal C calling > conventions ignores this value while it's the actual result of interest for > __clear_user. > Yes I noticed this. Actually I'm wondering if we couldn't add a new function, fill_user() like the following: extern size_t fill_user(void __user *to, int c, size_t len); This could be used by both memset() and clear_user(): #define memset(s,c,l) ({ (void)fill(s,c,l); s; }) #define clear_user(t,l) fill_user(t,0,l) Therefore the definition of clear_user() could be saner. What do you think ? Franck From ralf@linux-mips.org Mon Nov 5 23:18:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 23:18:23 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:39094 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28577428AbXKEXSV (ORCPT ); Mon, 5 Nov 2007 23:18:21 +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 lA5NIIqR024424; Mon, 5 Nov 2007 23:18:18 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5NIIjL024423; Mon, 5 Nov 2007 23:18:18 GMT Date: Mon, 5 Nov 2007 23:18:18 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Franck Bui-Huu , linux-mips Subject: Re: [PATCH] Kill __bzero() Message-ID: <20071105231818.GA18820@linux-mips.org> References: <472D8058.5080209@gmail.com> <20071105112429.GC27893@linux-mips.org> <472F906F.7080205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472F906F.7080205@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: 17411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 05, 2007 at 10:51:43PM +0100, Franck Bui-Huu wrote: > > Memset is almost always only ever invoked with a zero argument. So the > > idea was to have something like this: > > > > extern void *__memset(void *__s, int __c, size_t __count); > > extern void *bzero(void *__s, size_t __count); > > > > static inline void *memset(void *s, int c, size_t count) > > { > > if (__builtin_constant_p(c) && c == 0) { > > bzero(s, count); > > return s; > > } else > > return __memset(s, __c, count); > > } > > > > But that was never quite implemented like this as you noticed. > > Well I'm not sure we really need this. bzero() is not part of the > Linux string API, so it can only be used by MIPS specific code. And > with the current implementation of bzero(), $a1 needs to be setup to 0 > anyway. That's why I simply killed it... > > BTW, can memset() be an inlined function ? It can be anything, macro, inline or outline function. In the kernel there are fewer restrictions than for a standards compliant library in userspace. You may take the i386 implementation in include/asm-x86/string_32.h as an extreme example. Older gcc used to generate significantly worse code for inline functions than for macros so Linux became a fairly excessive user of macros. This has very much improved since, so these days inlines are prefered over macros where possible. > Yes I noticed this. Actually I'm wondering if we couldn't add a new > function, fill_user() like the following: > > extern size_t fill_user(void __user *to, int c, size_t len); That's much better function name than the old __bzero - except that __bzero effectivly took a long argument for the 2nd argument so 32-bit on 32-bit kernels and 64-bit on 64-bit kernels. > This could be used by both memset() and clear_user(): > > #define memset(s,c,l) ({ (void)fill(s,c,l); s; }) > #define clear_user(t,l) fill_user(t,0,l) > > Therefore the definition of clear_user() could be saner. Looks alot nicer that way though an inline is probably preferable as expressed above. Ralf From ralf@linux-mips.org Mon Nov 5 23:30:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Nov 2007 23:30:30 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:41965 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28576713AbXKEXa2 (ORCPT ); Mon, 5 Nov 2007 23:30: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 lA5NUQ9c024546; Mon, 5 Nov 2007 23:30:26 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA5NUPRs024545; Mon, 5 Nov 2007 23:30:25 GMT Date: Mon, 5 Nov 2007 23:30:25 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Thiemo Seufer , Nigel Stephens , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code Message-ID: <20071105233025.GB12514@linux-mips.org> References: <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> <472E2955.3000803@gmail.com> <20071105113618.GD27893@linux-mips.org> <472F8C82.4080406@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <472F8C82.4080406@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: 17412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 05, 2007 at 10:34:58PM +0100, Franck Bui-Huu wrote: > It's actually hard to know the advantages of using SDE over a stock gcc. > The only difference I'm aware of is the smartmips ASE support in SDE. > But since this support is going to be added in stock gccs, I don't see > any advantages now and I'm wondering if I can give up using SDE... In general terms the toolchain has been more reliable and had better support for MIPS processors before FSF gcc. Ralf From vagabon.xyz@gmail.com Tue Nov 6 07:24:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 07:24:53 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.190]:3690 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021820AbXKFHYp (ORCPT ); Tue, 6 Nov 2007 07:24:45 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1358760nfd for ; Mon, 05 Nov 2007 23:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=rDMlNyVBA0u3aNDtER6noLjjNPF754KVBkFI+hbBRaE=; b=TfxvlBngmFq+/bq9y4yetR4cFf8UcKsavKJhELHqvxN+6fPX/ZVYSunzphFhD9IeNlW6MZny+f461ACKtP1lWVeeHy8IlQ2K8iqa4jFuRaMgMWzp/21lkj11fx32Potfb2Fpw5oOhBonXbPPOzi5Fz/R0wGgVrS7xcW01JFI2N8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=G9x6AY5NX7f1lHbiGB7hL93Dk0cCs6aeKGonYJnAYWTVVCpDCQaOYuwldHBcTEZVyzYrLnHGg+0CiX610tS1LSJBPWi/nq7pTyTx2laTO11HEySGvYK0Wdl7PiTjBq+Trp8R56V5hoJ9OnFVisAdAcoVPQ7pSCyx8uojaSaYEY8= Received: by 10.86.91.12 with SMTP id o12mr4100015fgb.1194333874429; Mon, 05 Nov 2007 23:24:34 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 28sm13642078fkx.2007.11.05.23.24.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Nov 2007 23:24:33 -0800 (PST) Message-ID: <47301663.2030202@gmail.com> Date: Tue, 06 Nov 2007 08:23:15 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , Nigel Stephens , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: [PATCH] mm/pg-r4k.c: Dump the generated code References: <47147551.1010004@gmail.com> <4714B58E.8020005@mips.com> <4715C039.7090603@gmail.com> <20071017123046.GY3379@networkno.de> <47160D31.5080201@mips.com> <472D8110.2080506@gmail.com> <20071104174710.GA9363@networkno.de> <472E2955.3000803@gmail.com> <20071105113618.GD27893@linux-mips.org> <472F8C82.4080406@gmail.com> <20071105233025.GB12514@linux-mips.org> In-Reply-To: <20071105233025.GB12514@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Mon, Nov 05, 2007 at 10:34:58PM +0100, Franck Bui-Huu wrote: > >> It's actually hard to know the advantages of using SDE over a stock gcc. >> The only difference I'm aware of is the smartmips ASE support in SDE. >> But since this support is going to be added in stock gccs, I don't see >> any advantages now and I'm wondering if I can give up using SDE... > > In general terms the toolchain has been more reliable and had better > support for MIPS processors before FSF gcc. > Good point. Franck From vagabon.xyz@gmail.com Tue Nov 6 07:44:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 07:44:26 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.186]:18384 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20021866AbXKFHoR (ORCPT ); Tue, 6 Nov 2007 07:44:17 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1361901nfd for ; Mon, 05 Nov 2007 23:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=RrGUCz7p4DwiQ0Kwr/vzcDShXumSIbeXEm+1JB2fxuc=; b=uq4HNf6RQTelvN/NtxZfbkEBeXUa3n8DUG5buLXJx3DCdakTtw5y7PXStW7mdTGTzG3hJQ0KiQUntC07nqtLbsIPYWXXPnzoU6ZjOMPkbnELKxypke6D2CihscNYg3af7LlulYSmFp7tnUu7abzsLUCAEOVcaKKLp46eDsb6XDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Tlo9mjOGmIDz5luln9G0V3GLtIpK8VVfhiwZdEw3ab/Obwf+oRz50Mpn4O9pOcgs9p49JEXpHFF0AVynkD9nlwUgYHxHzhYOQb5k2L8O3ZG3kX2GvfkKAwh4+bsqgcNcNL2C2MX6Le52z+Wd5Zbuj7nma+wkm9xhR9oMUywJ55I= Received: by 10.86.51.2 with SMTP id y2mr4122683fgy.1194335047595; Mon, 05 Nov 2007 23:44:07 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 13sm13690421fks.2007.11.05.23.44.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Nov 2007 23:44:06 -0800 (PST) Message-ID: <47301AF8.2000700@gmail.com> Date: Tue, 06 Nov 2007 08:42:48 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: Re: [PATCH] Kill __bzero() References: <472D8058.5080209@gmail.com> <20071105112429.GC27893@linux-mips.org> <472F906F.7080205@gmail.com> <20071105231818.GA18820@linux-mips.org> In-Reply-To: <20071105231818.GA18820@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Mon, Nov 05, 2007 at 10:51:43PM +0100, Franck Bui-Huu wrote: > >>> Memset is almost always only ever invoked with a zero argument. So the >>> idea was to have something like this: >>> >>> extern void *__memset(void *__s, int __c, size_t __count); >>> extern void *bzero(void *__s, size_t __count); >>> >>> static inline void *memset(void *s, int c, size_t count) >>> { >>> if (__builtin_constant_p(c) && c == 0) { >>> bzero(s, count); >>> return s; >>> } else >>> return __memset(s, __c, count); >>> } >>> >>> But that was never quite implemented like this as you noticed. >> Well I'm not sure we really need this. bzero() is not part of the >> Linux string API, so it can only be used by MIPS specific code. And >> with the current implementation of bzero(), $a1 needs to be setup to 0 >> anyway. That's why I simply killed it... >> >> BTW, can memset() be an inlined function ? > > It can be anything, macro, inline or outline function. In the kernel > there are fewer restrictions than for a standards compliant library in > userspace. > > You may take the i386 implementation in include/asm-x86/string_32.h as > an extreme example. > > Older gcc used to generate significantly worse code for inline functions > than for macros so Linux became a fairly excessive user of macros. This > has very much improved since, so these days inlines are prefered over > macros where possible. Yes but ISTR that gcc generates some calls to memset and since builtin functions are disabled the final link failed if memset is inlined. I'll try to reproduce... > >> Yes I noticed this. Actually I'm wondering if we couldn't add a new >> function, fill_user() like the following: >> >> extern size_t fill_user(void __user *to, int c, size_t len); > > That's much better function name than the old __bzero - except that Actually I named it '__fill_user', since it doesn't call access_ok(). > __bzero effectivly took a long argument for the 2nd argument so 32-bit > on 32-bit kernels and 64-bit on 64-bit kernels. Isn't size_t meaning ? Perhaps in this case __kernel_size_t is better... > >> This could be used by both memset() and clear_user(): >> >> #define memset(s,c,l) ({ (void)fill(s,c,l); s; }) >> #define clear_user(t,l) fill_user(t,0,l) >> >> Therefore the definition of clear_user() could be saner. > > Looks alot nicer that way though an inline is probably preferable as > expressed above. > Yes I have a patchset which clean up a bit uaccess.h and does this but it's under construction. It actually tries to convert all macros into inlines and the file is much more readable and as a bonus side we could easily add __must_check annotations which are currently missing. I'll try to finish it this week but in the meantime can we just kill __bzero or do you want me to include it in the future patchset ? Franck From ralf@linux-mips.org Tue Nov 6 10:36:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 10:36:10 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:11437 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28578316AbXKFKgI (ORCPT ); Tue, 6 Nov 2007 10:36:08 +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 lA6Aa410029474; Tue, 6 Nov 2007 10:36:04 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA6Aa3ur029473; Tue, 6 Nov 2007 10:36:03 GMT Date: Tue, 6 Nov 2007 10:36:03 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips Subject: Re: [PATCH] Kill __bzero() Message-ID: <20071106103603.GA24844@linux-mips.org> References: <472D8058.5080209@gmail.com> <20071105112429.GC27893@linux-mips.org> <472F906F.7080205@gmail.com> <20071105231818.GA18820@linux-mips.org> <47301AF8.2000700@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47301AF8.2000700@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: 17415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 06, 2007 at 08:42:48AM +0100, Franck Bui-Huu wrote: > > Older gcc used to generate significantly worse code for inline functions > > than for macros so Linux became a fairly excessive user of macros. This > > has very much improved since, so these days inlines are prefered over > > macros where possible. > > Yes but ISTR that gcc generates some calls to memset and since > builtin functions are disabled the final link failed if memset > is inlined. I'll try to reproduce... So both belt and suspenders then that is an inline/macro plus an outline version? > >> Yes I noticed this. Actually I'm wondering if we couldn't add a new > >> function, fill_user() like the following: > >> > >> extern size_t fill_user(void __user *to, int c, size_t len); > > > > That's much better function name than the old __bzero - except that > > Actually I named it '__fill_user', since it doesn't call access_ok(). > > > __bzero effectivly took a long argument for the 2nd argument so 32-bit > > on 32-bit kernels and 64-bit on 64-bit kernels. > > Isn't size_t meaning ? > > Perhaps in this case __kernel_size_t is better... I wrote about the existing __bzero which takes the size_t length as third argument and a long sized fill pattern as the second. > Yes I have a patchset which clean up a bit uaccess.h and does this but > it's under construction. It actually tries to convert all macros into > inlines and the file is much more readable and as a bonus side we could > easily add __must_check annotations which are currently missing. > > I'll try to finish it this week but in the meantime can we just kill > __bzero or do you want me to include it in the future patchset ? There is enough time until 2.6.25 to complete your cleanups; no more cleanups for 2.6.24. Ralf From ralf@linux-mips.org Tue Nov 6 13:47:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 13:47:53 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:41603 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022610AbXKFNrv (ORCPT ); Tue, 6 Nov 2007 13:47:51 +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 lA6DloLk018692; Tue, 6 Nov 2007 13:47:50 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA6Dlnhi018691; Tue, 6 Nov 2007 13:47:49 GMT Date: Tue, 6 Nov 2007 13:47:49 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org Subject: Re: [PATCH 1/4] tlbex.c: Cleanup __init usages. Message-ID: <20071106134749.GA18017@linux-mips.org> References: <1192691477-4675-1-git-send-email-fbuihuu@gmail.com> <1192691477-4675-2-git-send-email-fbuihuu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1192691477-4675-2-git-send-email-fbuihuu@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: 17416 X-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, Oct 18, 2007 at 09:11:14AM +0200, Franck Bui-Huu wrote: Queued for 2.6.25. Thanks, Ralf From ralf@linux-mips.org Tue Nov 6 14:03:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 14:03:15 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:16296 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022644AbXKFODN (ORCPT ); Tue, 6 Nov 2007 14:03:13 +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 lA6E3C9u028940; Tue, 6 Nov 2007 14:03:12 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA6E3Bj6028939; Tue, 6 Nov 2007 14:03:11 GMT Date: Tue, 6 Nov 2007 14:03:11 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org Subject: Re: [PATCH 2/4] tlbex.c: cleanup include files Message-ID: <20071106140311.GB18017@linux-mips.org> References: <1192691477-4675-1-git-send-email-fbuihuu@gmail.com> <1192691477-4675-3-git-send-email-fbuihuu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1192691477-4675-3-git-send-email-fbuihuu@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: 17417 X-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, Oct 18, 2007 at 09:11:15AM +0200, Franck Bui-Huu wrote: > Date: Thu, 18 Oct 2007 09:11:15 +0200 > To: ralf@linux-mips.org > Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org > Subject: [PATCH 2/4] tlbex.c: cleanup include files Queued for 2.6.25. Thanks, Ralf From ralf@linux-mips.org Tue Nov 6 14:03:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 14:03:43 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:40104 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022644AbXKFODk (ORCPT ); Tue, 6 Nov 2007 14:03:40 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA6E3ej8028946; Tue, 6 Nov 2007 14:03:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA6E3eKU028945; Tue, 6 Nov 2007 14:03:40 GMT Date: Tue, 6 Nov 2007 14:03:40 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org Subject: Re: [PATCH 3/4] tlbex.c: use __cacheline_aligned instead of __tlb_handler_align attribute Message-ID: <20071106140340.GC18017@linux-mips.org> References: <1192691477-4675-1-git-send-email-fbuihuu@gmail.com> <1192691477-4675-4-git-send-email-fbuihuu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1192691477-4675-4-git-send-email-fbuihuu@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: 17418 X-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, Oct 18, 2007 at 09:11:16AM +0200, Franck Bui-Huu wrote: > To: ralf@linux-mips.org > Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org > Subject: [PATCH 3/4] tlbex.c: use __cacheline_aligned instead of > __tlb_handler_align attribute Queued for 2.6.25. Thanks alot, Ralf From ralf@linux-mips.org Tue Nov 6 14:31:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 14:31:54 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:28318 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022718AbXKFObw (ORCPT ); Tue, 6 Nov 2007 14:31:52 +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 lA6EVphq011461; Tue, 6 Nov 2007 14:31:51 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA6EVoOO011436; Tue, 6 Nov 2007 14:31:50 GMT Date: Tue, 6 Nov 2007 14:31:50 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org Subject: Re: [PATCH 4/4] tlbex.c: cleanup debug code Message-ID: <20071106143150.GD18017@linux-mips.org> References: <1192691477-4675-1-git-send-email-fbuihuu@gmail.com> <1192691477-4675-5-git-send-email-fbuihuu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1192691477-4675-5-git-send-email-fbuihuu@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: 17419 X-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, Oct 18, 2007 at 09:11:17AM +0200, Franck Bui-Huu wrote: And this one also queued for 2.6.25. Thanks again, Ralf From anemo@mba.ocn.ne.jp Tue Nov 6 15:38:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 15:38:54 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:16882 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20021820AbXKFPio (ORCPT ); Tue, 6 Nov 2007 15:38:44 +0000 Received: from localhost (p4065-ipad306funabasi.chiba.ocn.ne.jp [123.217.174.65]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CC6BE9687; Wed, 7 Nov 2007 00:37:21 +0900 (JST) Date: Wed, 07 Nov 2007 00:39:25 +0900 (JST) Message-Id: <20071107.003925.74752709.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: <20071103.014649.122254137.anemo@mba.ocn.ne.jp> References: <20071101.013124.108121433.anemo@mba.ocn.ne.jp> <20071031163900.GB22871@linux-mips.org> <20071103.014649.122254137.anemo@mba.ocn.ne.jp> 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: 17420 X-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 Sat, 03 Nov 2007 01:46:49 +0900 (JST), Atsushi Nemoto wrote: > > 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? Revised. As Ralf said on IRC, the adjustment can be done at beginning of handler, instead of ret_from_irq. So we can enable this hack at runtime. I introduced BUILD_ROLLBACK_PROLOGUE macro to build prologue code for handle_int and except_vec_vi. I'm not sure except_vec4 needs the prologue or not. And if the EPC was just after WAIT (i.e. normal wakeup from WAIT) the rollback is not needed. So I arranged r4k_wait so that the rollback region exactly fit to 32 byte. How about this? ------------------------------------------------------------------------ Subject: Fix potential latency problem due to non-atomic cpu_wait. If an interrupt happened between checking of NEED_RESCHED and WAIT instruction, adjust EPC to restart from checking of NEED_RESCHED. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/cpu-probe.c | 16 ++-------------- arch/mips/kernel/genex.S | 38 ++++++++++++++++++++++++++++++++++++++ arch/mips/kernel/traps.c | 22 ++++++++++++++++------ 3 files changed, 56 insertions(+), 20 deletions(-) diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index c8c47a2..c745b91 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -45,18 +45,7 @@ static void r39xx_wait(void) local_irq_enable(); } -/* - * There is a race when WAIT instruction executed with interrupt - * enabled. - * But it is implementation-dependent wheter the pipelie restarts when - * a non-enabled interrupt is requested. - */ -static void r4k_wait(void) -{ - __asm__(" .set mips3 \n" - " wait \n" - " .set mips0 \n"); -} +extern void r4k_wait(void); /* * This variant is preferable as it allows testing need_resched and going to @@ -128,7 +117,7 @@ static int __init wait_disable(char *s) __setup("nowait", wait_disable); -static inline void check_wait(void) +void __init check_wait(void) { struct cpuinfo_mips *c = ¤t_cpu_data; @@ -239,7 +228,6 @@ static inline void check_errata(void) void __init check_bugs32(void) { - check_wait(); check_errata(); } diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index c0f19d6..bb72c3a 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -20,6 +20,7 @@ #include #include #include +#include #define PANIC_PIC(msg) \ .set push; \ @@ -126,7 +127,43 @@ handle_vcei: __FINIT + .align 5 /* 32 byte rollback region */ +LEAF(r4k_wait) + .set push + .set noreorder + /* start of rollback region */ + LONG_L t0, TI_FLAGS($28) + nop + andi t0, _TIF_NEED_RESCHED + bnez t0, 1f + nop + nop + nop + .set mips3 + wait + .set mips0 + /* end of rollback region (the region size must be power of two) */ + .set pop +1: + jr ra + END(r4k_wait) + + .macro BUILD_ROLLBACK_PROLOGUE handler + FEXPORT(rollback_\handler) + .set push + .set noat + MFC0 k0, CP0_EPC + ori k0, 0x1f /* 32 byte rollback region */ + xori k0, 0x1f + PTR_LA k1, r4k_wait + bne k0, k1, 9f + MTC0 k0, CP0_EPC +9: + .set pop + .endm + .align 5 +BUILD_ROLLBACK_PROLOGUE handle_int NESTED(handle_int, PT_SIZE, sp) #ifdef CONFIG_TRACE_IRQFLAGS /* @@ -201,6 +238,7 @@ NESTED(except_vec_ejtag_debug, 0, sp) * This prototype is copied to ebase + n*IntCtl.VS and patched * to invoke the handler */ +BUILD_ROLLBACK_PROLOGUE except_vec_vi NESTED(except_vec_vi, 0, sp) SAVE_SOME SAVE_AT diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index fa50078..0b2cc58 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -43,6 +43,9 @@ #include #include +extern void check_wait(void); +extern asmlinkage void r4k_wait(void); +extern asmlinkage void rollback_handle_int(void); extern asmlinkage void handle_int(void); extern asmlinkage void handle_tlbm(void); extern asmlinkage void handle_tlbl(void); @@ -1198,6 +1201,9 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) extern char except_vec_vi, except_vec_vi_lui; extern char except_vec_vi_ori, except_vec_vi_end; + extern char rollback_except_vec_vi; + char *vec_start = (cpu_wait == r4k_wait) ? + &rollback_except_vec_vi : &except_vec_vi; #ifdef CONFIG_MIPS_MT_SMTC /* * We need to provide the SMTC vectored interrupt handler @@ -1205,11 +1211,11 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) * Status.IM bit to be masked before going there. */ extern char except_vec_vi_mori; - const int mori_offset = &except_vec_vi_mori - &except_vec_vi; + const int mori_offset = &except_vec_vi_mori - vec_start; #endif /* CONFIG_MIPS_MT_SMTC */ - const int handler_len = &except_vec_vi_end - &except_vec_vi; - const int lui_offset = &except_vec_vi_lui - &except_vec_vi; - const int ori_offset = &except_vec_vi_ori - &except_vec_vi; + const int handler_len = &except_vec_vi_end - vec_start; + const int lui_offset = &except_vec_vi_lui - vec_start; + const int ori_offset = &except_vec_vi_ori - vec_start; if (handler_len > VECTORSPACING) { /* @@ -1219,7 +1225,7 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) panic("VECTORSPACING too small"); } - memcpy(b, &except_vec_vi, handler_len); + memcpy(b, vec_start, handler_len); #ifdef CONFIG_MIPS_MT_SMTC BUG_ON(n > 7); /* Vector index %d exceeds SMTC maximum. */ @@ -1497,6 +1503,10 @@ void __init trap_init(void) extern char except_vec3_generic, except_vec3_r4000; extern char except_vec4; unsigned long i; + int rollback; + + check_wait(); + rollback = (cpu_wait == r4k_wait); if (cpu_has_veic || cpu_has_vint) ebase = (unsigned long) alloc_bootmem_low_pages(0x200 + VECTORSPACING*64); @@ -1558,7 +1568,7 @@ void __init trap_init(void) if (board_be_init) board_be_init(); - set_except_vector(0, handle_int); + set_except_vector(0, rollback ? rollback_handle_int : handle_int); set_except_vector(1, handle_tlbm); set_except_vector(2, handle_tlbl); set_except_vector(3, handle_tlbs); From ddaney@avtrex.com Tue Nov 6 15:59:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 15:59:10 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:23992 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20022947AbXKFP7B (ORCPT ); Tue, 6 Nov 2007 15:59:01 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id E83EB3103BA; Tue, 6 Nov 2007 15:59:09 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Tue, 6 Nov 2007 15:59:09 +0000 (UTC) Received: from jennifer.localdomain ([192.168.7.224]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 07:58:57 -0800 Message-ID: <47308F36.2070200@avtrex.com> Date: Tue, 06 Nov 2007 07:58:46 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Atsushi Nemoto Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: WAIT vs. tickless kernel References: <20071101.013124.108121433.anemo@mba.ocn.ne.jp> <20071031163900.GB22871@linux-mips.org> <20071103.014649.122254137.anemo@mba.ocn.ne.jp> <20071107.003925.74752709.anemo@mba.ocn.ne.jp> In-Reply-To: <20071107.003925.74752709.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 15:58:57.0615 (UTC) FILETIME=[F06C0DF0:01C8208D] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Atsushi Nemoto wrote: > +LEAF(r4k_wait) > + .set push > + .set noreorder > + /* start of rollback region */ > + LONG_L t0, TI_FLAGS($28) > + nop > + andi t0, _TIF_NEED_RESCHED > + bnez t0, 1f > + nop > + nop > + nop > + .set mips3 > + wait > + .set mips0 > + /* end of rollback region (the region size must be power of two) */ > + .set pop > The .set mips0 is redundant as .set pop immediately follows. David Daney From anemo@mba.ocn.ne.jp Tue Nov 6 16:02:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 16:02:25 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:43764 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20021819AbXKFQCQ (ORCPT ); Tue, 6 Nov 2007 16:02:16 +0000 Received: from localhost (p4065-ipad306funabasi.chiba.ocn.ne.jp [123.217.174.65]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 274188A69; Wed, 7 Nov 2007 01:00:56 +0900 (JST) Date: Wed, 07 Nov 2007 01:02:59 +0900 (JST) Message-Id: <20071107.010259.25478892.anemo@mba.ocn.ne.jp> To: ddaney@avtrex.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: WAIT vs. tickless kernel From: Atsushi Nemoto In-Reply-To: <47308F36.2070200@avtrex.com> References: <20071103.014649.122254137.anemo@mba.ocn.ne.jp> <20071107.003925.74752709.anemo@mba.ocn.ne.jp> <47308F36.2070200@avtrex.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17422 X-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 Tue, 06 Nov 2007 07:58:46 -0800, David Daney wrote: > > + .set mips0 > > + /* end of rollback region (the region size must be power of two) */ > > + .set pop > > > > The .set mips0 is redundant as .set pop immediately follows. Oh yes. I'll drop it on next revision. Thanks. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Tue Nov 6 16:06:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 16:06:57 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:33786 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20022947AbXKFQGs (ORCPT ); Tue, 6 Nov 2007 16:06:48 +0000 Received: from localhost (p4065-ipad306funabasi.chiba.ocn.ne.jp [123.217.174.65]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 946AC971B; Wed, 7 Nov 2007 01:06:44 +0900 (JST) Date: Wed, 07 Nov 2007 01:08:48 +0900 (JST) Message-Id: <20071107.010848.37531337.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Fix typo in R3000 TRACE_IRQFLAGS code From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17423 X-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 Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index c0f19d6..e76a76b 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -146,7 +146,7 @@ NESTED(handle_int, PT_SIZE, sp) and k0, ST0_IEP bnez k0, 1f - mfc0 k0, EP0_EPC + mfc0 k0, CP0_EPC .set noreorder j k0 rfe From vagabon.xyz@gmail.com Tue Nov 6 16:20:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 16:20:28 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:62738 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20023366AbXKFQUS (ORCPT ); Tue, 6 Nov 2007 16:20:18 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1471565nfd for ; Tue, 06 Nov 2007 08:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=oxC9FEdLrkbBIhvzSpJ7epBWT9C7GT36Rik/fcbPr1M=; b=Tz8xh16XYAJUnzpNhEGYBnzQyuquqdbTiyuioMIuJaQY1895UcO+LysXbVXHP3TrXdpbQHMWeB03uYXhgmZ8+LNAm8AUcMgS5lMQjabsT3VdvyCDxIS6r9NMabUVMPPTNqk4ioqbEWmhQ2/Bu+ZTcpEGezOMM42MQrePJekOb1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CFLXcgq/ZuKJy16mHDmj+saO7e4tbDAx2Muqw5fbkVksMpz+vuz/dw01+Cp9XGR2Mf57BpKhx66/fBzykft6UhC1QiodBWTXahi2xA8tOK7Mtw/Oj2KlOfdmwqAfy3NXwBCjp51GAQAObtoZngztjwdPw8x8JEwkpnvjFHOGPkk= Received: by 10.86.26.11 with SMTP id 11mr4443418fgz.1194366008619; Tue, 06 Nov 2007 08:20:08 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 13sm14664531fks.2007.11.06.08.20.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Nov 2007 08:20:06 -0800 (PST) Message-ID: <473093E1.60507@gmail.com> Date: Tue, 06 Nov 2007 17:18:41 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: Re: [PATCH] Kill __bzero() References: <472D8058.5080209@gmail.com> <20071105112429.GC27893@linux-mips.org> <472F906F.7080205@gmail.com> <20071105231818.GA18820@linux-mips.org> <47301AF8.2000700@gmail.com> <20071106103603.GA24844@linux-mips.org> In-Reply-To: <20071106103603.GA24844@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Tue, Nov 06, 2007 at 08:42:48AM +0100, Franck Bui-Huu wrote: > >>> Older gcc used to generate significantly worse code for inline functions >>> than for macros so Linux became a fairly excessive user of macros. This >>> has very much improved since, so these days inlines are prefered over >>> macros where possible. >> Yes but ISTR that gcc generates some calls to memset and since >> builtin functions are disabled the final link failed if memset >> is inlined. I'll try to reproduce... > OK, using Cobalt config and the patch below, I get the following link failure: $ make [snip] CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o: In function `param_sysfs_init': params.c:(.init.text+0x19ac): undefined reference to `memset' params.c:(.init.text+0x19ac): relocation truncated to fit: R_MIPS_26 against `memset' fs/built-in.o: In function `locks_remove_flock': (.text+0x14518): undefined reference to `memset' fs/built-in.o: In function `locks_remove_flock': (.text+0x14518): relocation truncated to fit: R_MIPS_26 against `memset' fs/built-in.o: In function `__blkdev_get': block_dev.c:(.text+0x31d40): undefined reference to `memset' block_dev.c:(.text+0x31d40): relocation truncated to fit: R_MIPS_26 against `memset' block_dev.c:(.text+0x31d50): undefined reference to `memset' block_dev.c:(.text+0x31d50): relocation truncated to fit: R_MIPS_26 against `memset' make: *** [.tmp_vmlinux1] Error 1 > So both belt and suspenders then that is an inline/macro plus an outline > version? > I guess so. >>>> Yes I noticed this. Actually I'm wondering if we couldn't add a new >>>> function, fill_user() like the following: >>>> >>>> extern size_t fill_user(void __user *to, int c, size_t len); >>> That's much better function name than the old __bzero - except that >> Actually I named it '__fill_user', since it doesn't call access_ok(). >> >>> __bzero effectivly took a long argument for the 2nd argument so 32-bit >>> on 32-bit kernels and 64-bit on 64-bit kernels. >> Isn't size_t meaning ? >> >> Perhaps in this case __kernel_size_t is better... > > I wrote about the existing __bzero which takes the size_t length as third > argument and a long sized fill pattern as the second. > Sorry I was confused (again) because of the invisible second parameter of __bzero... >> Yes I have a patchset which clean up a bit uaccess.h and does this but >> it's under construction. It actually tries to convert all macros into >> inlines and the file is much more readable and as a bonus side we could >> easily add __must_check annotations which are currently missing. >> >> I'll try to finish it this week but in the meantime can we just kill >> __bzero or do you want me to include it in the future patchset ? > > There is enough time until 2.6.25 to complete your cleanups; no more > cleanups for 2.6.24. > Sure. Franck -- 8< -- diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 3f8b8b3..23f0490 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -54,7 +54,7 @@ */ .set noreorder .align 5 -LEAF(memset) +LEAF(__memset) beqz a1, 1f move v0, a0 /* result */ diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h index 436e3ad..b2ef64c 100644 --- a/include/asm-mips/string.h +++ b/include/asm-mips/string.h @@ -132,7 +132,12 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) #endif /* CONFIG_32BIT */ #define __HAVE_ARCH_MEMSET -extern void *memset(void *__s, int __c, size_t __count); +static inline void *memset(void *__s, int __c, size_t __count) +{ + extern void *__memset(void *s, int c, size_t len); + + return __memset(__s, __c, __count); +} #define __HAVE_ARCH_MEMCPY extern void *memcpy(void *__to, __const__ void *__from, size_t __n); From manoj.ekbote@broadcom.com Tue Nov 6 20:19:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 20:19:24 +0000 (GMT) Received: from mms2.broadcom.com ([216.31.210.18]:55310 "EHLO mms2.broadcom.com") by ftp.linux-mips.org with ESMTP id S20024082AbXKFUTP convert rfc822-to-8bit (ORCPT ); Tue, 6 Nov 2007 20:19:15 +0000 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 06 Nov 2007 12:18:53 -0800 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 429C72AF; Tue, 6 Nov 2007 12:18:53 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2E9272AE; Tue, 6 Nov 2007 12:18:53 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FXI20184; Tue, 6 Nov 2007 12:18:52 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 85AE120501; Tue, 6 Nov 2007 12:18:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Deleting read-only environment variable on Sibyte board. Date: Tue, 6 Nov 2007 12:18:51 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36025B77EE@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20071105130259.GA31023@linux-mips.org> Thread-Topic: Deleting read-only environment variable on Sibyte board. Thread-Index: AcgfrFGNFk6haKUcRL21Nr3XOxD9nABBZHMA From: "Manoj Ekbote" To: "Ralf Baechle" , linux-mips@linux-mips.org X-WSS-ID: 6B2E13A72FS16865274-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: manoj.ekbote@broadcom.com Precedence: bulk X-list: linux-mips Hi Ralf, Can you try 'Unsetenv [NAME]'? >-----Original Message----- >From: linux-mips-bounce@linux-mips.org >[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Baechle >Sent: Monday, November 05, 2007 5:03 AM >To: linux-mips@linux-mips.org >Subject: Deleting read-only environment variable on Sibyte board. > >I've got a read-only environment variable on my >Sibyte/Broadcom Bigsur system. Annoyingly it's the network >address. Any help on how to delete such an undeletable >environment variable would be welcome. > >Thanks, > > Ralf > > > From ralf@linux-mips.org Tue Nov 6 22:28:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Nov 2007 22:28:39 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:21428 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025753AbXKFW2h (ORCPT ); Tue, 6 Nov 2007 22:28:37 +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 lA6MSZps004279; Tue, 6 Nov 2007 22:28:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA6MSZBC004278; Tue, 6 Nov 2007 22:28:35 GMT Date: Tue, 6 Nov 2007 22:28:35 +0000 From: Ralf Baechle To: Manoj Ekbote Cc: linux-mips@linux-mips.org Subject: Re: Deleting read-only environment variable on Sibyte board. Message-ID: <20071106222834.GA4079@linux-mips.org> References: <20071105130259.GA31023@linux-mips.org> <03235919BBDE634289BB6A0758A20B36025B77EE@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03235919BBDE634289BB6A0758A20B36025B77EE@NT-SJCA-0751.brcm.ad.broadcom.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: 17426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 06, 2007 at 12:18:51PM -0800, Manoj Ekbote wrote: > Hi Ralf, > > Can you try 'Unsetenv [NAME]'? I'm getting an error message, something about the variable being read-only. Thanks anyway, Ralf From reeve.yang@gmail.com Wed Nov 7 01:08:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 01:08:29 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:59170 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026354AbXKGBIU (ORCPT ); Wed, 7 Nov 2007 01:08:20 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1587258nfd for ; Tue, 06 Nov 2007 17:08:10 -0800 (PST) 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:content-transfer-encoding:content-disposition; bh=ZVCRxtXdNr+V7f6KX0EWYVeTFvdcI+uNHgJ97agLaYI=; b=imeiVQB+kv9ButeMN4c5NTsmBntJgrc3D4P/qZshzaiDn4Q84nbnS1qCsu/D9str6oRBJwa/XnBf7gsTwsBcYjX14367kU0KDQDVQ4NFMT992toIpkOb83qHqdGSsLN35rC2bCOpCo76GCx082vNrKeZctTAvEVM84sbd0B3eO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Xx5WIg/FthiedxlsjXcOcfNbFdFgXr44/tqpo0GzFk17w/MAbUZSoM+XxjSzOFt5IIbVo5xEOG2f0icJQLb2I4/aNYge7Jh3Ol9LpJk9t/3SJsPS0yn7uPXIpcmKGP708u6h/lJT96uMThoRAdyzqH8/BrOV7586+Ro7fD16oz0= Received: by 10.78.176.20 with SMTP id y20mr5480679hue.1194397690264; Tue, 06 Nov 2007 17:08:10 -0800 (PST) Received: by 10.78.29.10 with HTTP; Tue, 6 Nov 2007 17:08:10 -0800 (PST) Message-ID: <3b279e3f0711061708r12913a29o62e4bf99a2ee3664@mail.gmail.com> Date: Wed, 7 Nov 2007 01:08:10 +0000 From: "Reeve Yang" To: linux-mips@linux-mips.org Subject: cross-tool for mips target MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 17427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: reeve.yang@gmail.com Precedence: bulk X-list: linux-mips Hi there, I'm trying to build cross tool chain for mips32 target from my pc (i686) based on crosstoll-0.43. By running "sh demo-mips.sh" (I chose eval `cat mips.dat gcc-3.4.5-glibc-2.3.5.dat` sh all.sh --notest), I got following error from log file. Has anyone ever had similiar experience and how did you fix it? Thanks! - Reeve ## ----------- ## ## Core tests. ## ## ----------- ## configure:1706: checking build system type configure:1724: result: i686-pc-linux-gnu configure:1732: checking host system type configure:1746: result: mips642-unknown-linux-gnu configure:1998: checking sysdep dirs configure:2214: result: sysdeps/generic/elf sysdeps/generic configure:2233: checking for a BSD-compatible install configure:2288: result: /usr/bin/install -c configure:2303: checking whether ln -s works configure:2307: result: yes configure:2323: checking for mips32-linux-gnu-gcc configure:2349: result: gcc configure:2631: checking for C compiler version configure:2634: gcc --version &5 gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2637: $? = 0 configure:2639: gcc -v &5 Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/ usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable -shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale= gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) configure:2642: $? = 0 configure:2644: gcc -V &5 gcc: `-V' option must have argument configure:2647: $? = 1 configure:2651: checking for suffix of object files configure:2672: gcc -c -mabi=n32 conftest.c >&5 cc1: error: invalid option `abi=n32' configure:2675: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU C Library" | #define PACKAGE_TARNAME "c-library" | #define PACKAGE_VERSION "(see version.h)" | #define PACKAGE_STRING "GNU C Library (see version.h)" | #define PACKAGE_BUGREPORT "glibc" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2689: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. From ddaney@avtrex.com Wed Nov 7 01:14:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 01:15:07 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:908 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20026357AbXKGBO6 (ORCPT ); Wed, 7 Nov 2007 01:14:58 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 7C6C63100A6; Wed, 7 Nov 2007 01:14:39 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 7 Nov 2007 01:14:39 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 17:13:27 -0800 Message-ID: <47311137.5090706@avtrex.com> Date: Tue, 06 Nov 2007 17:13:27 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Reeve Yang Cc: linux-mips@linux-mips.org Subject: Re: cross-tool for mips target References: <3b279e3f0711061708r12913a29o62e4bf99a2ee3664@mail.gmail.com> In-Reply-To: <3b279e3f0711061708r12913a29o62e4bf99a2ee3664@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 01:13:27.0779 (UTC) FILETIME=[66FC3330:01C820DB] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Reeve Yang wrote: > Hi there, > > I'm trying to build cross tool chain for mips32 target from my pc > (i686) based on crosstoll-0.43. By running "sh demo-mips.sh" (I chose > eval `cat mips.dat gcc-3.4.5-glibc-2.3.5.dat` sh all.sh --notest), I > got following error from log file. Has anyone ever had similiar > experience and how did you fix it? Thanks! > I would ask over on: crossgcc@sourceware.org That is where crosstool is often discussed. David Daney From ralf@linux-mips.org Wed Nov 7 09:43:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 09:43:17 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:40908 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20031909AbXKGJnP (ORCPT ); Wed, 7 Nov 2007 09:43:15 +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 lA79hEmv027308; Wed, 7 Nov 2007 09:43:14 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA79hDZG027307; Wed, 7 Nov 2007 09:43:13 GMT Date: Wed, 7 Nov 2007 09:43:13 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] Fix typo in R3000 TRACE_IRQFLAGS code Message-ID: <20071107094313.GA27282@linux-mips.org> References: <20071107.010848.37531337.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071107.010848.37531337.anemo@mba.ocn.ne.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: 17429 X-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, Nov 07, 2007 at 01:08:48AM +0900, Atsushi Nemoto wrote: > Subject: [PATCH] Fix typo in R3000 TRACE_IRQFLAGS code I guess that's because the last R3000 is still busy compiling a 2.6.0 kernel ;-) Applied, Ralf From macro@linux-mips.org Wed Nov 7 12:41:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 12:41:46 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:26849 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20030366AbXKGMlh (ORCPT ); Wed, 7 Nov 2007 12:41:37 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 9534D40094; Wed, 7 Nov 2007 13:41:37 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id NX8eOQjJ1C6Y; Wed, 7 Nov 2007 13:41:29 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id CE4444007E; Wed, 7 Nov 2007 13:41:29 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA7CfWJP026006; Wed, 7 Nov 2007 13:41:32 +0100 Date: Wed, 7 Nov 2007 12:41:29 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Florian Fainelli , linux-mips@linux-mips.org Subject: Re: [PATCH][au1000] Remove useless EXTRA_CFLAGS In-Reply-To: <20071029151010.GA3953@linux-mips.org> Message-ID: References: <200710252108.43357.florian.fainelli@telecomint.eu> <20071029151010.GA3953@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4691/Wed Nov 7 06:39:41 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 29 Oct 2007, Ralf Baechle wrote: > And to ensure it will stay that way I'll keep -Werror. It seems only > little PITAs like this keep everybody on their toes :-) Yeah... If only GCC had no bugs and always had a clue of what to warn about... Maciej From anemo@mba.ocn.ne.jp Wed Nov 7 14:08:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 14:08:45 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:60381 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20023949AbXKGOIg (ORCPT ); Wed, 7 Nov 2007 14:08:36 +0000 Received: from localhost (p5186-ipad203funabasi.chiba.ocn.ne.jp [222.146.84.186]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A28D89225; Wed, 7 Nov 2007 23:08:32 +0900 (JST) Date: Wed, 07 Nov 2007 23:10:36 +0900 (JST) Message-Id: <20071107.231036.75185559.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [MIPS] Fix and cleanup the MIPS part of the (ab)use of CLOCK_TICK_RATE. From: Atsushi Nemoto In-Reply-To: References: 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: 17431 X-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 Thu, 01 Nov 2007 15:46:41 +0000, linux-mips@linux-mips.org wrote: > Author: Ralf Baechle Thu Nov 1 15:45:37 2007 +0000 > Commit: 0a354a30fe552b78a4db0873c19d8936551cc158 > Gitweb: http://www.linux-mips.org/g/linux/0a354a30 > Branch: master > > This is the clock rate of the i8253 PIT. A MIPS system may not have > a PIT by the symbol is used all over the kernel including some APIs. > So keeping it defined to the number for the PIT is the only sane thing > for now. The CLOCK_TICK_RATE is used for ACTHZ, TICK_NSEC, etc. At least for i8253-free platforms, It looks a value multiple of HZ would be better for such constants, assuming we have dyntick or accurate HZ clockevents. How about something like this? diff --git a/include/asm-mips/timex.h b/include/asm-mips/timex.h index 5816ad1..e9622b6 100644 --- a/include/asm-mips/timex.h +++ b/include/asm-mips/timex.h @@ -18,7 +18,11 @@ * So keeping it defined to the number for the PIT is the only sane thing * for now. */ +#ifdef CONFIG_I8253 #define CLOCK_TICK_RATE 1193182 +#else +#define CLOCK_TICK_RATE 1024000 /* multiple of HZ */ +#endif /* * Standard way to access the cycle counter. From ralf@linux-mips.org Wed Nov 7 14:17:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 14:18:00 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:44768 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032164AbXKGOR6 (ORCPT ); Wed, 7 Nov 2007 14:17:58 +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 lA7EHvcV001868; Wed, 7 Nov 2007 14:17:57 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA7EHvbx001867; Wed, 7 Nov 2007 14:17:57 GMT Date: Wed, 7 Nov 2007 14:17:57 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Fix and cleanup the MIPS part of the (ab)use of CLOCK_TICK_RATE. Message-ID: <20071107141757.GB1022@linux-mips.org> References: <20071107.231036.75185559.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071107.231036.75185559.anemo@mba.ocn.ne.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: 17432 X-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, Nov 07, 2007 at 11:10:36PM +0900, Atsushi Nemoto wrote: > The CLOCK_TICK_RATE is used for ACTHZ, TICK_NSEC, etc. > > At least for i8253-free platforms, It looks a value multiple of HZ > would be better for such constants, assuming we have dyntick or > accurate HZ clockevents. > > How about something like this? > > diff --git a/include/asm-mips/timex.h b/include/asm-mips/timex.h > index 5816ad1..e9622b6 100644 > --- a/include/asm-mips/timex.h > +++ b/include/asm-mips/timex.h > @@ -18,7 +18,11 @@ > * So keeping it defined to the number for the PIT is the only sane thing > * for now. > */ > +#ifdef CONFIG_I8253 > #define CLOCK_TICK_RATE 1193182 > +#else > +#define CLOCK_TICK_RATE 1024000 /* multiple of HZ */ > +#endif kernel/time/ntp.c:#define CLOCK_TICK_OVERFLOW (LATCH * HZ - CLOCK_TICK_RATE) kernel/time/ntp.c: (s64)CLOCK_TICK_RATE) drivers/char/vt_ioctl.c: arg = CLOCK_TICK_RATE / arg; drivers/char/vt_ioctl.c: count = CLOCK_TICK_RATE / count; There is so much abuse of this variable, it's not even funny. It really deserve to be taken out and shot. And that's just two cases. Ralf From anemo@mba.ocn.ne.jp Wed Nov 7 14:21:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 14:21:53 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:65254 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20032180AbXKGOVn (ORCPT ); Wed, 7 Nov 2007 14:21:43 +0000 Received: from localhost (p5186-ipad203funabasi.chiba.ocn.ne.jp [222.146.84.186]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 591B99DDE; Wed, 7 Nov 2007 23:21:39 +0900 (JST) Date: Wed, 07 Nov 2007 23:23:43 +0900 (JST) Message-Id: <20071107.232343.104640143.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: <20071107.003925.74752709.anemo@mba.ocn.ne.jp> References: <20071031163900.GB22871@linux-mips.org> <20071103.014649.122254137.anemo@mba.ocn.ne.jp> <20071107.003925.74752709.anemo@mba.ocn.ne.jp> 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: 17433 X-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, 07 Nov 2007 00:39:25 +0900 (JST), Atsushi Nemoto wrote: > + MFC0 k0, CP0_EPC > + ori k0, 0x1f /* 32 byte rollback region */ > + xori k0, 0x1f > + PTR_LA k1, r4k_wait Well, this part should be like this, for better pipelining. MFC0 k0, CP0_EPC PTR_LA k1, r4k_wait ori k0, 0x1f /* 32 byte rollback region */ xori k0, 0x1f > + bne k0, k1, 9f > + MTC0 k0, CP0_EPC > +9: And if we could assume branch-likely, this can be: .set noreorder beql k0, k1, 9f MTC0 k0, CP0_EPC 9: But not sure if it really have points. > .align 5 > +BUILD_ROLLBACK_PROLOGUE handle_int > NESTED(handle_int, PT_SIZE, sp) And one more question: should we put one more ".align 5" just befor handle_int for CPUs do not need the rollback? --- Atsushi Nemoto From giuseppe@eppesuigoccas.homedns.org Wed Nov 7 14:45:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 14:45:38 +0000 (GMT) Received: from host153-171-dynamic.9-87-r.retail.telecomitalia.it ([87.9.171.153]:41437 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20032189AbXKGOpa (ORCPT ); Wed, 7 Nov 2007 14:45:30 +0000 Received: from eppesuig3 ([192.168.2.50]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ipm6h-0008F3-Ol for linux-mips@linux-mips.org; Wed, 07 Nov 2007 15:42:17 +0100 Subject: Re: Preliminary patch for ip32 ttyS* device From: Giuseppe Sacco To: mips kernel list In-Reply-To: <20071031130828.GE14187@linux-mips.org> References: <20071030214015.050b7950.giuseppe@eppesuigoccas.homedns.org> <20071031130828.GE14187@linux-mips.org> Content-Type: text/plain Date: Wed, 07 Nov 2007 15:43:05 +0100 Message-Id: <1194446585.5849.21.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Il giorno mer, 31/10/2007 alle 13.08 +0000, Ralf Baechle ha scritto: [...] > > diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c > > index 3bb5d24..7caa877 100644 > > --- a/drivers/serial/serial_core.c > > +++ b/drivers/serial/serial_core.c > > @@ -2455,6 +2455,8 @@ int uart_match_port(struct uart_port *port1, struct uart_port *port2) > > case UPIO_AU: > > case UPIO_TSI: > > case UPIO_DWAPB: > > + if (port1->mapbase==0 && port2->mapbase==0) > > + return (port1->membase == port2->membase); > > This hack is only needed because ->mapbase is not initialized. I have been investigating about it for one week and I am still not convinced that mapbase must be initialised. I tried to understand the meaning of mapbase and membase, but I am unsure about the value I should set mapbase to. I learnt that when specifying mapbase its region would be registered and reserved using request_mem_region(). Otherwise, if you do not specify mapbase, the region is not reserved. Apart from reserving the memory region, mapbase isn't use anymore. Is mapbase mandatory? If mapbase isn't mandatory, the second part of my patch is probably right and fixes a bug. Bye, Giuseppe From johannes@sipsolutions.net Wed Nov 7 15:08:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 15:09:00 +0000 (GMT) Received: from crystal.sipsolutions.net ([195.210.38.204]:174 "EHLO sipsolutions.net") by ftp.linux-mips.org with ESMTP id S28574134AbXKGPIv (ORCPT ); Wed, 7 Nov 2007 15:08:51 +0000 Received: from [131.234.77.13] by sipsolutions.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.67) (envelope-from ) id 1IpmVu-0004Vy-Ed; Wed, 07 Nov 2007 15:08:18 +0000 Message-Id: <20071107135849.207149000@sipsolutions.net> References: <20071107135758.100171000@sipsolutions.net> User-Agent: quilt/0.46-1 Date: Wed, 07 Nov 2007 14:58:00 +0100 From: Johannes Berg To: linux-pm@lists.linux-foundation.org Cc: "Rafael J. Wysocki" , linuxppc-dev@ozlabs.org, Guennadi Liakhovetski , Scott Wood , David Howells , Ralf Baechle , linux-mips@linux-mips.org, Paul Mundt , Bryan Wu , Russell King Subject: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig Content-Disposition: inline; filename=026-suspend-kconfig-cleanup.patch Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 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: 17435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: johannes@sipsolutions.net Precedence: bulk X-list: linux-mips This cleans up the suspend Kconfig and removes the need to declare centrally which architectures support suspend. All architectures that currently support suspend are modified accordingly. Signed-off-by: Johannes Berg Cc: Rafael J. Wysocki Cc: linuxppc-dev@ozlabs.org Cc: linux-pm@lists.linux-foundation.org Cc: Guennadi Liakhovetski Cc: Scott Wood Cc: David Howells Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: Paul Mundt Cc: Bryan Wu Cc: Russell King --- Architecture maintainers should evaluate whether their ARCH_SUSPEND_POSSIBLE symbol should be set only under stricter circumstances like I've done for powerpc. Always setting it is not usually a problem, however, since the infrastructure is only available for use after suspend_set_ops(). arch/arm/Kconfig | 3 +++ arch/blackfin/Kconfig | 4 ++++ arch/frv/Kconfig | 5 +++++ arch/i386/Kconfig | 4 ++++ arch/mips/Kconfig | 4 ++++ arch/powerpc/Kconfig | 4 ++++ arch/sh/Kconfig | 4 ++++ arch/x86_64/Kconfig | 3 +++ kernel/power/Kconfig | 21 +++------------------ 9 files changed, 34 insertions(+), 18 deletions(-) --- everything.orig/arch/i386/Kconfig 2007-11-07 14:45:28.591544215 +0100 +++ everything/arch/i386/Kconfig 2007-11-07 14:45:28.631515461 +0100 @@ -1323,3 +1323,7 @@ config KTIME_SCALAR config ARCH_HIBERNATION_POSSIBLE def_bool y depends on !SMP || !X86_VOYAGER + +config ARCH_SUSPEND_POSSIBLE + def_bool y + depends on !X86_VOYAGER --- everything.orig/arch/x86_64/Kconfig 2007-11-07 14:45:28.591544215 +0100 +++ everything/arch/x86_64/Kconfig 2007-11-07 14:45:28.631515461 +0100 @@ -716,6 +716,9 @@ menu "Power management options" source kernel/power/Kconfig +config ARCH_SUSPEND_POSSIBLE + def_bool y + config ARCH_HIBERNATION_POSSIBLE def_bool y --- everything.orig/kernel/power/Kconfig 2007-11-07 14:45:28.591544215 +0100 +++ everything/kernel/power/Kconfig 2007-11-07 14:45:28.641531465 +0100 @@ -64,7 +64,7 @@ config PM_TRACE config PM_SLEEP_SMP bool depends on SMP - depends on SUSPEND_SMP_POSSIBLE || ARCH_HIBERNATION_POSSIBLE + depends on ARCH_SUSPEND_POSSIBLE || ARCH_HIBERNATION_POSSIBLE depends on PM_SLEEP select HOTPLUG_CPU default y @@ -74,29 +74,14 @@ config PM_SLEEP depends on SUSPEND || HIBERNATION default y -config SUSPEND_UP_POSSIBLE - bool - depends on (X86 && !X86_VOYAGER) || PPC || ARM || BLACKFIN || MIPS \ - || SUPERH || FRV - depends on !SMP - default y - -config SUSPEND_SMP_POSSIBLE - bool - depends on (X86 && !X86_VOYAGER) \ - || (PPC && (PPC_PSERIES || PPC_PMAC)) || ARM - depends on SMP - default y - config SUSPEND bool "Suspend to RAM and standby" - depends on PM - depends on SUSPEND_UP_POSSIBLE || SUSPEND_SMP_POSSIBLE + depends on PM && ARCH_SUSPEND_POSSIBLE default y ---help--- Allow the system to enter sleep states in which main memory is powered and thus its contents are preserved, such as the - suspend-to-RAM state (i.e. the ACPI S3 state). + suspend-to-RAM state (e.g. the ACPI S3 state). config HIBERNATION bool "Hibernation (aka 'suspend to disk')" --- everything.orig/arch/blackfin/Kconfig 2007-11-07 14:44:55.551521971 +0100 +++ everything/arch/blackfin/Kconfig 2007-11-07 14:45:28.641531465 +0100 @@ -993,6 +993,10 @@ endmenu menu "Power management options" source "kernel/power/Kconfig" +config ARCH_SUSPEND_POSSIBLE + def_bool y + depends on !SMP + choice prompt "Select PM Wakeup Event Source" default PM_WAKEUP_GPIO_BY_SIC_IWR --- everything.orig/arch/arm/Kconfig 2007-11-07 14:44:55.651522948 +0100 +++ everything/arch/arm/Kconfig 2007-11-07 14:45:28.641531465 +0100 @@ -977,6 +977,9 @@ menu "Power management options" source "kernel/power/Kconfig" +config ARCH_SUSPEND_POSSIBLE + def_bool y + endmenu source "net/Kconfig" --- everything.orig/arch/mips/Kconfig 2007-11-07 14:44:55.701522460 +0100 +++ everything/arch/mips/Kconfig 2007-11-07 14:45:28.641531465 +0100 @@ -1999,6 +1999,10 @@ endmenu menu "Power management options" +config ARCH_SUSPEND_POSSIBLE + def_bool y + depends on !SMP + source "kernel/power/Kconfig" endmenu --- everything.orig/arch/sh/Kconfig 2007-11-07 14:44:55.801520344 +0100 +++ everything/arch/sh/Kconfig 2007-11-07 14:45:28.651528536 +0100 @@ -748,6 +748,10 @@ endmenu menu "Power management options (EXPERIMENTAL)" depends on EXPERIMENTAL && SYS_SUPPORTS_PM +config ARCH_SUSPEND_POSSIBLE + def_bool y + depends on !SMP + source kernel/power/Kconfig endmenu --- everything.orig/arch/frv/Kconfig 2007-11-07 14:44:55.861520941 +0100 +++ everything/arch/frv/Kconfig 2007-11-07 14:45:28.651528536 +0100 @@ -357,6 +357,11 @@ source "drivers/pcmcia/Kconfig" # should probably wait a while. menu "Power management options" + +config ARCH_SUSPEND_POSSIBLE + def_bool y + depends on !SMP + source kernel/power/Kconfig endmenu --- everything.orig/arch/powerpc/Kconfig 2007-11-07 14:45:28.591544215 +0100 +++ everything/arch/powerpc/Kconfig 2007-11-07 14:45:28.651528536 +0100 @@ -155,6 +155,10 @@ config ARCH_HIBERNATION_POSSIBLE depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32) default y +config ARCH_SUSPEND_POSSIBLE + def_bool y + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 + config PPC_DCR_NATIVE bool default n -- From lethal@linux-sh.org Wed Nov 7 15:14:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 15:15:27 +0000 (GMT) Received: from pip10.gyao.ne.jp ([61.122.117.248]:12693 "EHLO mx.gate01.com") by ftp.linux-mips.org with ESMTP id S28574144AbXKGPO6 (ORCPT ); Wed, 7 Nov 2007 15:14:58 +0000 Received: from [124.34.33.190] (helo=master.linux-sh.org) by smtp32.isp.us-com.jp with esmtp (Mail 4.41) id 1Ipmb4-0006lJ-V7; Thu, 08 Nov 2007 00:13:39 +0900 Received: from localhost (unknown [127.0.0.1]) by master.linux-sh.org (Postfix) with ESMTP id 33C0A64C7C; Wed, 7 Nov 2007 15:13:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at linux-sh.org Received: from master.linux-sh.org ([127.0.0.1]) by localhost (master.linux-sh.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9LclNW9sE96; Thu, 8 Nov 2007 00:13:28 +0900 (JST) Received: by master.linux-sh.org (Postfix, from userid 500) id CC2E064C80; Thu, 8 Nov 2007 00:13:28 +0900 (JST) Date: Thu, 8 Nov 2007 00:13:28 +0900 From: Paul Mundt To: Johannes Berg Cc: linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" , linuxppc-dev@ozlabs.org, Guennadi Liakhovetski , Scott Wood , David Howells , Ralf Baechle , linux-mips@linux-mips.org, Bryan Wu , Russell King Subject: Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig Message-ID: <20071107151328.GA28181@linux-sh.org> Mail-Followup-To: Paul Mundt , Johannes Berg , linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" , linuxppc-dev@ozlabs.org, Guennadi Liakhovetski , Scott Wood , David Howells , Ralf Baechle , linux-mips@linux-mips.org, Bryan Wu , Russell King References: <20071107135758.100171000@sipsolutions.net> <20071107135849.207149000@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071107135849.207149000@sipsolutions.net> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lethal@linux-sh.org Precedence: bulk X-list: linux-mips On Wed, Nov 07, 2007 at 02:58:00PM +0100, Johannes Berg wrote: > This cleans up the suspend Kconfig and removes the need to > declare centrally which architectures support suspend. All > architectures that currently support suspend are modified > accordingly. > > Signed-off-by: Johannes Berg > Cc: Rafael J. Wysocki > Cc: linuxppc-dev@ozlabs.org > Cc: linux-pm@lists.linux-foundation.org > Cc: Guennadi Liakhovetski > Cc: Scott Wood > Cc: David Howells > Cc: Ralf Baechle > Cc: linux-mips@linux-mips.org > Cc: Paul Mundt > Cc: Bryan Wu > Cc: Russell King > --- > Architecture maintainers should evaluate whether their > ARCH_SUSPEND_POSSIBLE symbol should be set only under > stricter circumstances like I've done for powerpc. > The SH bits look fine. Acked-by: Paul Mundt From macro@linux-mips.org Wed Nov 7 16:55:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 16:56:01 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:29338 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20030075AbXKGQzw (ORCPT ); Wed, 7 Nov 2007 16:55:52 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4119B4007E; Wed, 7 Nov 2007 17:55:22 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id 97NHDMBLtFiM; Wed, 7 Nov 2007 17:55:12 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id B89774008F; Wed, 7 Nov 2007 17:55:11 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA7GtFIE020409; Wed, 7 Nov 2007 17:55:15 +0100 Date: Wed, 7 Nov 2007 16:55:10 +0000 (GMT) From: "Maciej W. Rozycki" To: Martin Michlmayr cc: Ralf Baechle , linux-mips@linux-mips.org, Thomas Bogendoerfer Subject: Re: [PATCH] IP22: Disable EARLY PRINTK, because it breaks serial console In-Reply-To: <20071030073349.GA15984@deprecation.cyrius.com> Message-ID: References: <20070911104459.GB7624@alpha.franken.de> <20071030073349.GA15984@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4691/Wed Nov 7 06:39:41 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 30 Oct 2007, Martin Michlmayr wrote: > * Thomas Bogendoerfer [2007-09-11 12:44]: > > Disable EARLY PRINTK, because it breaks serial console > > Ralf, at the moment IP22 output stops after "Serial: IP22 Zilog driver > (1 chips).". Can you put this patch in until there's a real fix? Is it by any chance the same problem that I noticed with the DECstation and reported in the thread starting at: "http://marc.info/?l=linux-kernel&m=119030963931879&w=2"? If so, there is a fix for the DECstation provided somewhere down the discussion which you may consider porting to IP22. I think the change to the serial core by RMK mentioned there has already been applied upstream. Ideally, of course, all the SCC drivers should get merged eventually, but due to subtle (and sometimes broken, as it is the case with the DECstation) differences in wiring for various systems it may never really happen, sigh... Maciej From macro@linux-mips.org Wed Nov 7 17:21:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 17:21:41 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:7136 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20029312AbXKGRVc (ORCPT ); Wed, 7 Nov 2007 17:21:32 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 412B44007F; Wed, 7 Nov 2007 18:21:33 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id ikCVI9WG9jEO; Wed, 7 Nov 2007 18:21:23 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 979434007E; Wed, 7 Nov 2007 18:21:23 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA7HLRAl027110; Wed, 7 Nov 2007 18:21:28 +0100 Date: Wed, 7 Nov 2007 17:21:22 +0000 (GMT) From: "Maciej W. Rozycki" To: Giuseppe Sacco cc: mips kernel list Subject: Re: Preliminary patch for ip32 ttyS* device In-Reply-To: <1194446585.5849.21.camel@scarafaggio> Message-ID: References: <20071030214015.050b7950.giuseppe@eppesuigoccas.homedns.org> <20071031130828.GE14187@linux-mips.org> <1194446585.5849.21.camel@scarafaggio> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4691/Wed Nov 7 06:39:41 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 7 Nov 2007, Giuseppe Sacco wrote: > I have been investigating about it for one week and I am still not > convinced that mapbase must be initialised. I tried to understand the > meaning of mapbase and membase, but I am unsure about the value I should > set mapbase to. > > I learnt that when specifying mapbase its region would be registered and > reserved using request_mem_region(). Otherwise, if you do not specify > mapbase, the region is not reserved. Apart from reserving the memory > region, mapbase isn't use anymore. Is mapbase mandatory? > > If mapbase isn't mandatory, the second part of my patch is probably > right and fixes a bug. You ought to use mapbase and ioremap() with new code as you are not allowed to use readb()/writeb()/etc. on addresses obtained otherwise than by calling ioremap(). The use of request_mem_region(), etc. is not strictly mandatory, but it is nice to have. Many serial drivers use these functions, so I cannot see a reason why it would be a hassle for ip32. Maciej From manoj.ekbote@broadcom.com Wed Nov 7 19:36:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 19:37:05 +0000 (GMT) Received: from mms3.broadcom.com ([216.31.210.19]:34566 "EHLO MMS3.broadcom.com") by ftp.linux-mips.org with ESMTP id S20032268AbXKGTg5 convert rfc822-to-8bit (ORCPT ); Wed, 7 Nov 2007 19:36:57 +0000 Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Wed, 07 Nov 2007 11:36:40 -0800 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 981772AF; Wed, 7 Nov 2007 11:36:40 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 83FB62AE; Wed, 7 Nov 2007 11:36:40 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FXL41467; Wed, 7 Nov 2007 11:36:40 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C536920501; Wed, 7 Nov 2007 11:36:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Deleting read-only environment variable on Sibyte board. Date: Wed, 7 Nov 2007 11:36:38 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36025B79F4@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <20071106222834.GA4079@linux-mips.org> Thread-Topic: Deleting read-only environment variable on Sibyte board. Thread-Index: AcggxGuHpOTKGJIQQ0qeipED5zRbugAq0JnA From: "Manoj Ekbote" To: "Ralf Baechle" cc: linux-mips@linux-mips.org X-WSS-ID: 6B2CCC424QC16690235-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: manoj.ekbote@broadcom.com Precedence: bulk X-list: linux-mips It looks like the variable was set with 'setenv -ro' command. This will need a manual delete. Bad news - This would probably require a new firmware build. There is no current command to remove -ro variables (non-existing feature). >-----Original Message----- >From: Ralf Baechle [mailto:ralf@linux-mips.org] >Sent: Tuesday, November 06, 2007 2:29 PM >To: Manoj Ekbote >Cc: linux-mips@linux-mips.org >Subject: Re: Deleting read-only environment variable on Sibyte board. > >On Tue, Nov 06, 2007 at 12:18:51PM -0800, Manoj Ekbote wrote: > >> Hi Ralf, >> >> Can you try 'Unsetenv [NAME]'? > >I'm getting an error message, something about the variable >being read-only. > >Thanks anyway, > > Ralf > > From ralf@linux-mips.org Wed Nov 7 19:42:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 19:42:58 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:45992 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032283AbXKGTmz (ORCPT ); Wed, 7 Nov 2007 19:42:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA7Jgtji008360; Wed, 7 Nov 2007 19:42:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA7Jgsuc008359; Wed, 7 Nov 2007 19:42:54 GMT Date: Wed, 7 Nov 2007 19:42:54 +0000 From: Ralf Baechle To: Manoj Ekbote Cc: linux-mips@linux-mips.org Subject: Re: Deleting read-only environment variable on Sibyte board. Message-ID: <20071107194254.GA7193@linux-mips.org> References: <20071106222834.GA4079@linux-mips.org> <03235919BBDE634289BB6A0758A20B36025B79F4@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03235919BBDE634289BB6A0758A20B36025B79F4@NT-SJCA-0751.brcm.ad.broadcom.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: 17440 X-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, Nov 07, 2007 at 11:36:38AM -0800, Manoj Ekbote wrote: > It looks like the variable was set with 'setenv -ro' command. This will > need a manual delete. > Bad news - This would probably require a new firmware build. There is > no current command to remove -ro variables (non-existing feature). I ran over a bit of documentation regarding how variables are stored by CFE. Looks easy enough to write a little app to convert those variables to writeable. Ralf From rjw@sisk.pl Wed Nov 7 22:03:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 22:03:19 +0000 (GMT) Received: from ogre.sisk.pl ([217.79.144.158]:1466 "EHLO ogre.sisk.pl") by ftp.linux-mips.org with ESMTP id S20032344AbXKGWDL (ORCPT ); Wed, 7 Nov 2007 22:03:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id 54F54692D1; Wed, 7 Nov 2007 22:51:11 +0100 (CET) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01312-03; Wed, 7 Nov 2007 22:51:00 +0100 (CET) Received: from [192.168.100.100] (nat-be3.aster.pl [212.76.37.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 5E518693E0; Wed, 7 Nov 2007 22:50:49 +0100 (CET) From: "Rafael J. Wysocki" To: Johannes Berg Subject: Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig Date: Wed, 7 Nov 2007 23:19:18 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: linux-pm@lists.linux-foundation.org, linuxppc-dev@ozlabs.org, Guennadi Liakhovetski , Scott Wood , David Howells , Ralf Baechle , linux-mips@linux-mips.org, Paul Mundt , Bryan Wu , Russell King , Andrew Morton , LKML References: <20071107135758.100171000@sipsolutions.net> <20071107135849.207149000@sipsolutions.net> In-Reply-To: <20071107135849.207149000@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711072319.20224.rjw@sisk.pl> X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rjw@sisk.pl Precedence: bulk X-list: linux-mips On Wednesday, 7 of November 2007, Johannes Berg wrote: > This cleans up the suspend Kconfig and removes the need to > declare centrally which architectures support suspend. All > architectures that currently support suspend are modified > accordingly. > > Signed-off-by: Johannes Berg Acked-by: Rafael J. Wysocki > Cc: linuxppc-dev@ozlabs.org > Cc: linux-pm@lists.linux-foundation.org > Cc: Guennadi Liakhovetski > Cc: Scott Wood > Cc: David Howells > Cc: Ralf Baechle > Cc: linux-mips@linux-mips.org > Cc: Paul Mundt > Cc: Bryan Wu > Cc: Russell King > --- > Architecture maintainers should evaluate whether their > ARCH_SUSPEND_POSSIBLE symbol should be set only under > stricter circumstances like I've done for powerpc. > > Always setting it is not usually a problem, however, since the > infrastructure is only available for use after suspend_set_ops(). > > arch/arm/Kconfig | 3 +++ > arch/blackfin/Kconfig | 4 ++++ > arch/frv/Kconfig | 5 +++++ > arch/i386/Kconfig | 4 ++++ > arch/mips/Kconfig | 4 ++++ > arch/powerpc/Kconfig | 4 ++++ > arch/sh/Kconfig | 4 ++++ > arch/x86_64/Kconfig | 3 +++ > kernel/power/Kconfig | 21 +++------------------ > 9 files changed, 34 insertions(+), 18 deletions(-) > > --- everything.orig/arch/i386/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/arch/i386/Kconfig 2007-11-07 14:45:28.631515461 +0100 > @@ -1323,3 +1323,7 @@ config KTIME_SCALAR > config ARCH_HIBERNATION_POSSIBLE > def_bool y > depends on !SMP || !X86_VOYAGER > + > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !X86_VOYAGER > --- everything.orig/arch/x86_64/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/arch/x86_64/Kconfig 2007-11-07 14:45:28.631515461 +0100 > @@ -716,6 +716,9 @@ menu "Power management options" > > source kernel/power/Kconfig > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + > config ARCH_HIBERNATION_POSSIBLE > def_bool y > > --- everything.orig/kernel/power/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/kernel/power/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -64,7 +64,7 @@ config PM_TRACE > config PM_SLEEP_SMP > bool > depends on SMP > - depends on SUSPEND_SMP_POSSIBLE || ARCH_HIBERNATION_POSSIBLE > + depends on ARCH_SUSPEND_POSSIBLE || ARCH_HIBERNATION_POSSIBLE > depends on PM_SLEEP > select HOTPLUG_CPU > default y > @@ -74,29 +74,14 @@ config PM_SLEEP > depends on SUSPEND || HIBERNATION > default y > > -config SUSPEND_UP_POSSIBLE > - bool > - depends on (X86 && !X86_VOYAGER) || PPC || ARM || BLACKFIN || MIPS \ > - || SUPERH || FRV > - depends on !SMP > - default y > - > -config SUSPEND_SMP_POSSIBLE > - bool > - depends on (X86 && !X86_VOYAGER) \ > - || (PPC && (PPC_PSERIES || PPC_PMAC)) || ARM > - depends on SMP > - default y > - > config SUSPEND > bool "Suspend to RAM and standby" > - depends on PM > - depends on SUSPEND_UP_POSSIBLE || SUSPEND_SMP_POSSIBLE > + depends on PM && ARCH_SUSPEND_POSSIBLE > default y > ---help--- > Allow the system to enter sleep states in which main memory is > powered and thus its contents are preserved, such as the > - suspend-to-RAM state (i.e. the ACPI S3 state). > + suspend-to-RAM state (e.g. the ACPI S3 state). > > config HIBERNATION > bool "Hibernation (aka 'suspend to disk')" > --- everything.orig/arch/blackfin/Kconfig 2007-11-07 14:44:55.551521971 +0100 > +++ everything/arch/blackfin/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -993,6 +993,10 @@ endmenu > menu "Power management options" > source "kernel/power/Kconfig" > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > choice > prompt "Select PM Wakeup Event Source" > default PM_WAKEUP_GPIO_BY_SIC_IWR > --- everything.orig/arch/arm/Kconfig 2007-11-07 14:44:55.651522948 +0100 > +++ everything/arch/arm/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -977,6 +977,9 @@ menu "Power management options" > > source "kernel/power/Kconfig" > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + > endmenu > > source "net/Kconfig" > --- everything.orig/arch/mips/Kconfig 2007-11-07 14:44:55.701522460 +0100 > +++ everything/arch/mips/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -1999,6 +1999,10 @@ endmenu > > menu "Power management options" > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > source "kernel/power/Kconfig" > > endmenu > --- everything.orig/arch/sh/Kconfig 2007-11-07 14:44:55.801520344 +0100 > +++ everything/arch/sh/Kconfig 2007-11-07 14:45:28.651528536 +0100 > @@ -748,6 +748,10 @@ endmenu > menu "Power management options (EXPERIMENTAL)" > depends on EXPERIMENTAL && SYS_SUPPORTS_PM > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > source kernel/power/Kconfig > > endmenu > --- everything.orig/arch/frv/Kconfig 2007-11-07 14:44:55.861520941 +0100 > +++ everything/arch/frv/Kconfig 2007-11-07 14:45:28.651528536 +0100 > @@ -357,6 +357,11 @@ source "drivers/pcmcia/Kconfig" > # should probably wait a while. > > menu "Power management options" > + > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > source kernel/power/Kconfig > endmenu > > --- everything.orig/arch/powerpc/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/arch/powerpc/Kconfig 2007-11-07 14:45:28.651528536 +0100 > @@ -155,6 +155,10 @@ config ARCH_HIBERNATION_POSSIBLE > depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32) > default y > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 > + > config PPC_DCR_NATIVE > bool > default n > -- "Premature optimization is the root of all evil." - Donald Knuth From tsbogend@alpha.franken.de Wed Nov 7 22:04:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 22:04:49 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:31898 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20032348AbXKGWEl (ORCPT ); Wed, 7 Nov 2007 22:04:41 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Ipt0q-000136-00; Wed, 07 Nov 2007 23:04:40 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 3E6E3C2256; Wed, 7 Nov 2007 22:54:23 +0100 (CET) Date: Wed, 7 Nov 2007 22:54:23 +0100 To: "Maciej W. Rozycki" Cc: Martin Michlmayr , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] IP22: Disable EARLY PRINTK, because it breaks serial console Message-ID: <20071107215423.GA11915@alpha.franken.de> References: <20070911104459.GB7624@alpha.franken.de> <20071030073349.GA15984@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 17442 X-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 Wed, Nov 07, 2007 at 04:55:10PM +0000, Maciej W. Rozycki wrote: > On Tue, 30 Oct 2007, Martin Michlmayr wrote: > > > * Thomas Bogendoerfer [2007-09-11 12:44]: > > > Disable EARLY PRINTK, because it breaks serial console > > > > Ralf, at the moment IP22 output stops after "Serial: IP22 Zilog driver > > (1 chips).". Can you put this patch in until there's a real fix? > > Is it by any chance the same problem that I noticed with the DECstation > and reported in the thread starting at: it's the same problem > "http://marc.info/?l=linux-kernel&m=119030963931879&w=2"? If so, there is > a fix for the DECstation provided somewhere down the discussion which you > may consider porting to IP22. I think the change to the serial core by > RMK mentioned there has already been applied upstream. I ported your fix, but it didn't work for me. Maybe because the IP22 zilog driver is still a little bit different than the DEC one. > Ideally, of course, all the SCC drivers should get merged eventually, but > due to subtle (and sometimes broken, as it is the case with the > DECstation) differences in wiring for various systems it may never really > happen, sigh... having a more generic zilog driver with platform backends is quite high on my todo list. But I won't make promisses when this happens... Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From rmk+linux-mips=linux-mips.org@arm.linux.org.uk Wed Nov 7 22:23:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Nov 2007 22:23:56 +0000 (GMT) Received: from caramon.arm.linux.org.uk ([78.32.30.218]:55739 "EHLO caramon.arm.linux.org.uk") by ftp.linux-mips.org with ESMTP id S20032377AbXKGWXr (ORCPT ); Wed, 7 Nov 2007 22:23:47 +0000 Received: from flint.arm.linux.org.uk ([2002:4e20:1eda:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1IptHK-0000X6-8i; Wed, 07 Nov 2007 22:21:43 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.62) (envelope-from ) id 1IptHH-000264-3M; Wed, 07 Nov 2007 22:21:39 +0000 Date: Wed, 7 Nov 2007 22:21:38 +0000 From: Russell King To: Johannes Berg Cc: linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" , linuxppc-dev@ozlabs.org, Guennadi Liakhovetski , Scott Wood , David Howells , Ralf Baechle , linux-mips@linux-mips.org, Paul Mundt , Bryan Wu Subject: Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig Message-ID: <20071107222137.GB8801@flint.arm.linux.org.uk> References: <20071107135758.100171000@sipsolutions.net> <20071107135849.207149000@sipsolutions.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071107135849.207149000@sipsolutions.net> User-Agent: Mutt/1.4.2.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: linux-mips On Wed, Nov 07, 2007 at 02:58:00PM +0100, Johannes Berg wrote: > This cleans up the suspend Kconfig and removes the need to > declare centrally which architectures support suspend. All > architectures that currently support suspend are modified > accordingly. > > Signed-off-by: Johannes Berg > Cc: Rafael J. Wysocki > Cc: linuxppc-dev@ozlabs.org > Cc: linux-pm@lists.linux-foundation.org > Cc: Guennadi Liakhovetski > Cc: Scott Wood > Cc: David Howells > Cc: Ralf Baechle > Cc: linux-mips@linux-mips.org > Cc: Paul Mundt > Cc: Bryan Wu Acked-by: Russell King > --- > Architecture maintainers should evaluate whether their > ARCH_SUSPEND_POSSIBLE symbol should be set only under > stricter circumstances like I've done for powerpc. > > Always setting it is not usually a problem, however, since the > infrastructure is only available for use after suspend_set_ops(). > > arch/arm/Kconfig | 3 +++ > arch/blackfin/Kconfig | 4 ++++ > arch/frv/Kconfig | 5 +++++ > arch/i386/Kconfig | 4 ++++ > arch/mips/Kconfig | 4 ++++ > arch/powerpc/Kconfig | 4 ++++ > arch/sh/Kconfig | 4 ++++ > arch/x86_64/Kconfig | 3 +++ > kernel/power/Kconfig | 21 +++------------------ > 9 files changed, 34 insertions(+), 18 deletions(-) > > --- everything.orig/arch/i386/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/arch/i386/Kconfig 2007-11-07 14:45:28.631515461 +0100 > @@ -1323,3 +1323,7 @@ config KTIME_SCALAR > config ARCH_HIBERNATION_POSSIBLE > def_bool y > depends on !SMP || !X86_VOYAGER > + > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !X86_VOYAGER > --- everything.orig/arch/x86_64/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/arch/x86_64/Kconfig 2007-11-07 14:45:28.631515461 +0100 > @@ -716,6 +716,9 @@ menu "Power management options" > > source kernel/power/Kconfig > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + > config ARCH_HIBERNATION_POSSIBLE > def_bool y > > --- everything.orig/kernel/power/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/kernel/power/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -64,7 +64,7 @@ config PM_TRACE > config PM_SLEEP_SMP > bool > depends on SMP > - depends on SUSPEND_SMP_POSSIBLE || ARCH_HIBERNATION_POSSIBLE > + depends on ARCH_SUSPEND_POSSIBLE || ARCH_HIBERNATION_POSSIBLE > depends on PM_SLEEP > select HOTPLUG_CPU > default y > @@ -74,29 +74,14 @@ config PM_SLEEP > depends on SUSPEND || HIBERNATION > default y > > -config SUSPEND_UP_POSSIBLE > - bool > - depends on (X86 && !X86_VOYAGER) || PPC || ARM || BLACKFIN || MIPS \ > - || SUPERH || FRV > - depends on !SMP > - default y > - > -config SUSPEND_SMP_POSSIBLE > - bool > - depends on (X86 && !X86_VOYAGER) \ > - || (PPC && (PPC_PSERIES || PPC_PMAC)) || ARM > - depends on SMP > - default y > - > config SUSPEND > bool "Suspend to RAM and standby" > - depends on PM > - depends on SUSPEND_UP_POSSIBLE || SUSPEND_SMP_POSSIBLE > + depends on PM && ARCH_SUSPEND_POSSIBLE > default y > ---help--- > Allow the system to enter sleep states in which main memory is > powered and thus its contents are preserved, such as the > - suspend-to-RAM state (i.e. the ACPI S3 state). > + suspend-to-RAM state (e.g. the ACPI S3 state). > > config HIBERNATION > bool "Hibernation (aka 'suspend to disk')" > --- everything.orig/arch/blackfin/Kconfig 2007-11-07 14:44:55.551521971 +0100 > +++ everything/arch/blackfin/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -993,6 +993,10 @@ endmenu > menu "Power management options" > source "kernel/power/Kconfig" > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > choice > prompt "Select PM Wakeup Event Source" > default PM_WAKEUP_GPIO_BY_SIC_IWR > --- everything.orig/arch/arm/Kconfig 2007-11-07 14:44:55.651522948 +0100 > +++ everything/arch/arm/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -977,6 +977,9 @@ menu "Power management options" > > source "kernel/power/Kconfig" > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + > endmenu > > source "net/Kconfig" > --- everything.orig/arch/mips/Kconfig 2007-11-07 14:44:55.701522460 +0100 > +++ everything/arch/mips/Kconfig 2007-11-07 14:45:28.641531465 +0100 > @@ -1999,6 +1999,10 @@ endmenu > > menu "Power management options" > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > source "kernel/power/Kconfig" > > endmenu > --- everything.orig/arch/sh/Kconfig 2007-11-07 14:44:55.801520344 +0100 > +++ everything/arch/sh/Kconfig 2007-11-07 14:45:28.651528536 +0100 > @@ -748,6 +748,10 @@ endmenu > menu "Power management options (EXPERIMENTAL)" > depends on EXPERIMENTAL && SYS_SUPPORTS_PM > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > source kernel/power/Kconfig > > endmenu > --- everything.orig/arch/frv/Kconfig 2007-11-07 14:44:55.861520941 +0100 > +++ everything/arch/frv/Kconfig 2007-11-07 14:45:28.651528536 +0100 > @@ -357,6 +357,11 @@ source "drivers/pcmcia/Kconfig" > # should probably wait a while. > > menu "Power management options" > + > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on !SMP > + > source kernel/power/Kconfig > endmenu > > --- everything.orig/arch/powerpc/Kconfig 2007-11-07 14:45:28.591544215 +0100 > +++ everything/arch/powerpc/Kconfig 2007-11-07 14:45:28.651528536 +0100 > @@ -155,6 +155,10 @@ config ARCH_HIBERNATION_POSSIBLE > depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32) > default y > > +config ARCH_SUSPEND_POSSIBLE > + def_bool y > + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 > + > config PPC_DCR_NATIVE > bool > default n > > -- > -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: From paulus@ozlabs.org Thu Nov 8 02:30:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 02:30:32 +0000 (GMT) Received: from ozlabs.org ([203.10.76.45]:58569 "EHLO ozlabs.org") by ftp.linux-mips.org with ESMTP id S28577831AbXKHCaY (ORCPT ); Thu, 8 Nov 2007 02:30:24 +0000 Received: by ozlabs.org (Postfix, from userid 1003) id 03633DDE27; Thu, 8 Nov 2007 13:30:15 +1100 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18226.29871.368838.584925@cargo.ozlabs.ibm.com> Date: Thu, 8 Nov 2007 13:30:07 +1100 From: Paul Mackerras To: Johannes Berg Cc: linux-pm@lists.linux-foundation.org, Bryan Wu , linux-mips@linux-mips.org, Ralf Baechle , "Rafael J. Wysocki" , linuxppc-dev@ozlabs.org, Paul Mundt , Guennadi Liakhovetski , Russell King Subject: Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig In-Reply-To: <20071107135849.207149000@sipsolutions.net> References: <20071107135758.100171000@sipsolutions.net> <20071107135849.207149000@sipsolutions.net> X-Mailer: VM 7.19 under Emacs 21.4.1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: paulus@samba.org Precedence: bulk X-list: linux-mips Johannes Berg writes: > This cleans up the suspend Kconfig and removes the need to > declare centrally which architectures support suspend. All > architectures that currently support suspend are modified > accordingly. Acked-by: Paul Mackerras From ralf@linux-mips.org Thu Nov 8 09:47:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 09:47:12 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:62621 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022346AbXKHJrK (ORCPT ); Thu, 8 Nov 2007 09:47:10 +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 lA89l99A010871; Thu, 8 Nov 2007 09:47:09 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA89l8jf010870; Thu, 8 Nov 2007 09:47:08 GMT Date: Thu, 8 Nov 2007 09:47:08 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Florian Fainelli , linux-mips@linux-mips.org Subject: Re: [PATCH][au1000] Remove useless EXTRA_CFLAGS Message-ID: <20071108094708.GA10665@linux-mips.org> References: <200710252108.43357.florian.fainelli@telecomint.eu> <20071029151010.GA3953@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 17445 X-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, Nov 07, 2007 at 12:41:29PM +0000, Maciej W. Rozycki wrote: > > And to ensure it will stay that way I'll keep -Werror. It seems only > > little PITAs like this keep everybody on their toes :-) > > Yeah... If only GCC had no bugs and always had a clue of what to warn > about... The least of all problems. As of 2.6.20-rc2-git2 we had 137 warnings in MIPS specific code of a total of 218 for the kernel and 44 for modules - that's a insane 52%. And people happily added more crappy code because they didn't not even _notice_ the warnings some of which indeed were bugs. Compare to 2.6.23 - 13 warnings for MIPS specific code of a total of 48 warnings and another 23 warnings for all the modules. For a codebase which overall had grown by half a million lines between those releases. Ralf From ralf@linux-mips.org Thu Nov 8 09:48:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 09:48:31 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:9631 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022395AbXKHJs3 (ORCPT ); Thu, 8 Nov 2007 09:48: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 lA89mSwj010938; Thu, 8 Nov 2007 09:48:28 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA89mPSN010923; Thu, 8 Nov 2007 09:48:25 GMT Date: Thu, 8 Nov 2007 09:48:25 +0000 From: Ralf Baechle To: Johannes Berg Cc: linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" , linuxppc-dev@ozlabs.org, Guennadi Liakhovetski , Scott Wood , David Howells , linux-mips@linux-mips.org, Paul Mundt , Bryan Wu , Russell King Subject: Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig Message-ID: <20071108094825.GB10665@linux-mips.org> References: <20071107135758.100171000@sipsolutions.net> <20071107135849.207149000@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071107135849.207149000@sipsolutions.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: 17446 X-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, Nov 07, 2007 at 02:58:00PM +0100, Johannes Berg wrote: > This cleans up the suspend Kconfig and removes the need to > declare centrally which architectures support suspend. All > architectures that currently support suspend are modified > accordingly. Acked-by: Ralf Baechle Cheers, Ralf From ralf@linux-mips.org Thu Nov 8 09:57:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 09:57:12 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:38856 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022417AbXKHJ5K (ORCPT ); Thu, 8 Nov 2007 09:57:10 +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 lA89vAvq011106; Thu, 8 Nov 2007 09:57:10 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA89v9Aq011105; Thu, 8 Nov 2007 09:57:09 GMT Date: Thu, 8 Nov 2007 09:57:09 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: "Maciej W. Rozycki" , Martin Michlmayr , linux-mips@linux-mips.org Subject: Re: [PATCH] IP22: Disable EARLY PRINTK, because it breaks serial console Message-ID: <20071108095709.GC10665@linux-mips.org> References: <20070911104459.GB7624@alpha.franken.de> <20071030073349.GA15984@deprecation.cyrius.com> <20071107215423.GA11915@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071107215423.GA11915@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: 17447 X-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, Nov 07, 2007 at 10:54:23PM +0100, Thomas Bogendoerfer wrote: > > Ideally, of course, all the SCC drivers should get merged eventually, but > > due to subtle (and sometimes broken, as it is the case with the > > DECstation) differences in wiring for various systems it may never really > > happen, sigh... > > having a more generic zilog driver with platform backends is quite high on > my todo list. But I won't make promisses when this happens... Right now there are alot of artificial differences between the sun and IP22 8530 drivers by just different prefixes. A good start would already be to unify all these needless differences which is largely a mechanical job. Once that is that is it will become easier to spot all the relevant functional differences - there aren't that many but by now they're well hidden. Ralf From macro@linux-mips.org Thu Nov 8 11:13:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 11:13:14 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:54738 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021509AbXKHLNE (ORCPT ); Thu, 8 Nov 2007 11:13:04 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 3F47D40092; Thu, 8 Nov 2007 12:12:34 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id Qrf6aTt6daxM; Thu, 8 Nov 2007 12:12:21 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id D44E84007E; Thu, 8 Nov 2007 12:12:21 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA8BCPMZ027927; Thu, 8 Nov 2007 12:12:25 +0100 Date: Thu, 8 Nov 2007 11:12:21 +0000 (GMT) From: "Maciej W. Rozycki" To: Thomas Bogendoerfer cc: Martin Michlmayr , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: [PATCH] IP22: Disable EARLY PRINTK, because it breaks serial console In-Reply-To: <20071107215423.GA11915@alpha.franken.de> Message-ID: References: <20070911104459.GB7624@alpha.franken.de> <20071030073349.GA15984@deprecation.cyrius.com> <20071107215423.GA11915@alpha.franken.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4708/Thu Nov 8 07:07:54 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 7 Nov 2007, Thomas Bogendoerfer wrote: > having a more generic zilog driver with platform backends is quite high on > my todo list. But I won't make promisses when this happens... Synchronous and DMA operation is the tough part, at least for the DECstation. OTOH, such a framework actually exists already as drivers/net/wan/z85230.[ch], but fitting it into the serial subsystem is a lot of work as the serial core currently has no notion of synchronous modes at all. Ultimately you'd like to be able to switch between asynchronous and synchronous line disciplines on a port by port basis (possibly including halves of the same chip). Maciej From macro@linux-mips.org Thu Nov 8 11:25:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 11:25:18 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:19436 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20021864AbXKHLZJ (ORCPT ); Thu, 8 Nov 2007 11:25:09 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4BEC2400C1; Thu, 8 Nov 2007 12:25:09 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id YY7s097Hh0U7; Thu, 8 Nov 2007 12:25:03 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id E4B5E4007E; Thu, 8 Nov 2007 12:25:02 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA8BP6Z3030135; Thu, 8 Nov 2007 12:25:06 +0100 Date: Thu, 8 Nov 2007 11:25:03 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Florian Fainelli , linux-mips@linux-mips.org Subject: Re: [PATCH][au1000] Remove useless EXTRA_CFLAGS In-Reply-To: <20071108094708.GA10665@linux-mips.org> Message-ID: References: <200710252108.43357.florian.fainelli@telecomint.eu> <20071029151010.GA3953@linux-mips.org> <20071108094708.GA10665@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4708/Thu Nov 8 07:07:54 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 8 Nov 2007, Ralf Baechle wrote: > > Yeah... If only GCC had no bugs and always had a clue of what to warn > > about... > > The least of all problems. It depends for whom I suppose. ;-) It is a pain when you have to stretch your imagination to rewrite a piece of source code GCC warns about unduly and both keep it readable and not make the generated binary worse... Especially where configuration-specific macros are involved. > As of 2.6.20-rc2-git2 we had 137 warnings in MIPS specific code of a total > of 218 for the kernel and 44 for modules - that's a insane 52%. And people > happily added more crappy code because they didn't not even _notice_ the > warnings some of which indeed were bugs. Well, adding no warnings should be the rule #1 and I can understand it is easier for you to enforce it by the means of -Werror. ;-) Maciej From olsajiri@gmail.com Thu Nov 8 13:28:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 13:28:42 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:13625 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20023617AbXKHN2d (ORCPT ); Thu, 8 Nov 2007 13:28:33 +0000 Received: by nf-out-0910.google.com with SMTP id c10so113713nfd for ; Thu, 08 Nov 2007 05:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; bh=QQuB8Z4vHcjj5K/uxSIZRhSFCjxnSwgZIGSGD1Dmphk=; b=lXNRy5ShR7HmFQ34nPq/fmPpL07sC+529EgpVxsmRC1AwVwzmRJtnTiBOZRdeS6OxTgovYDZoiATRF86XDBEWn6QWi1JSX5xb2gRk1ElHgrZrQKaX6x0yV7aIMcm8MrmWgBx0yVo8Vo3o/5iWjMbb3n3c+8vay0HMjSbsi1u34k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=XuBsgIkV7kEsFo5cmeKkL7MhFCbPALYMG6DsRZR3WoPHVBjuJdkcATzvtOVoXcEVduy6lwb601yH+PRyovsOP6GtMMWYCmRjUIrOGlaFrcGY7xaEc7CeHaIFw2ugqLkPP9FAlk0RSFELPQ/n/uq7VTbtI+WvTtkqtVrE/rLuaA4= Received: by 10.78.147.6 with SMTP id u6mr592768hud.1194528503366; Thu, 08 Nov 2007 05:28:23 -0800 (PST) Received: from ?10.0.5.72? ( [80.95.121.137]) by mx.google.com with ESMTPS id 39sm377699hui.2007.11.08.05.28.20 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Nov 2007 05:28:21 -0800 (PST) Message-ID: <47330EF3.70002@gmail.com> Date: Thu, 08 Nov 2007 14:28:19 +0100 From: Jiri Olsa User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: kernel-janitors@vger.kernel.org CC: Andrew Morton , linux-mips@linux-mips.org, ralf@linux-mips.org Subject: [PATCH] MIPS - remove dead config symbols from MIPS code Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: olsajiri@gmail.com Precedence: bulk X-list: linux-mips remove dead config symbols from MIPS code Signed-off-by: Jiri Olsa --- include/asm-mips/pmc-sierra/msp71xx/msp_regs.h | 4 ---- include/asm-mips/sibyte/board.h | 1 - include/asm-mips/sibyte/swarm.h | 12 ------------ include/asm-mips/sn/addrs.h | 2 -- include/asm-mips/sn/agent.h | 4 +--- include/asm-mips/sn/klconfig.h | 18 +----------------- 6 files changed, 2 insertions(+), 39 deletions(-) diff --git a/include/asm-mips/pmc-sierra/msp71xx/msp_regs.h b/include/asm-mips/pmc-sierra/msp71xx/msp_regs.h index 0b56f55..603eb73 100644 --- a/include/asm-mips/pmc-sierra/msp71xx/msp_regs.h +++ b/include/asm-mips/pmc-sierra/msp71xx/msp_regs.h @@ -585,11 +585,7 @@ * UART defines * *************************************************************************** */ -#ifndef CONFIG_MSP_FPGA #define MSP_BASE_BAUD 25000000 -#else -#define MSP_BASE_BAUD 6000000 -#endif #define MSP_UART_REG_LEN 0x20 /* diff --git a/include/asm-mips/sibyte/board.h b/include/asm-mips/sibyte/board.h index da198a1..33028b9 100644 --- a/include/asm-mips/sibyte/board.h +++ b/include/asm-mips/sibyte/board.h @@ -20,7 +20,6 @@ #define _SIBYTE_BOARD_H #if defined(CONFIG_SIBYTE_SWARM) || defined(CONFIG_SIBYTE_PTSWARM) || \ - defined(CONFIG_SIBYTE_PT1120) || defined(CONFIG_SIBYTE_PT1125) || \ defined(CONFIG_SIBYTE_CRHONE) || defined(CONFIG_SIBYTE_CRHINE) || \ defined(CONFIG_SIBYTE_LITTLESUR) #include diff --git a/include/asm-mips/sibyte/swarm.h b/include/asm-mips/sibyte/swarm.h index 540865f..86db37e 100644 --- a/include/asm-mips/sibyte/swarm.h +++ b/include/asm-mips/sibyte/swarm.h @@ -32,18 +32,6 @@ #define SIBYTE_HAVE_IDE 1 #define SIBYTE_DEFAULT_CONSOLE "ttyS0,115200" #endif -#ifdef CONFIG_SIBYTE_PT1120 -#define SIBYTE_BOARD_NAME "PT1120" -#define SIBYTE_HAVE_PCMCIA 1 -#define SIBYTE_HAVE_IDE 1 -#define SIBYTE_DEFAULT_CONSOLE "ttyS0,115200" -#endif -#ifdef CONFIG_SIBYTE_PT1125 -#define SIBYTE_BOARD_NAME "PT1125" -#define SIBYTE_HAVE_PCMCIA 1 -#define SIBYTE_HAVE_IDE 1 -#define SIBYTE_DEFAULT_CONSOLE "ttyS0,115200" -#endif #ifdef CONFIG_SIBYTE_LITTLESUR #define SIBYTE_BOARD_NAME "BCM91250C2 (LittleSur)" #define SIBYTE_HAVE_PCMCIA 0 diff --git a/include/asm-mips/sn/addrs.h b/include/asm-mips/sn/addrs.h index fec9bdd..bef3049 100644 --- a/include/asm-mips/sn/addrs.h +++ b/include/asm-mips/sn/addrs.h @@ -19,8 +19,6 @@ #if defined(CONFIG_SGI_IP27) #include -#elif defined(CONFIG_SGI_IP35) -#include #endif diff --git a/include/asm-mips/sn/agent.h b/include/asm-mips/sn/agent.h index ac4ea85..62ee456 100644 --- a/include/asm-mips/sn/agent.h +++ b/include/asm-mips/sn/agent.h @@ -17,9 +17,7 @@ #if defined(CONFIG_SGI_IP27) #include -#elif defined(CONFIG_SGI_IP35) -#include -#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ +#endif /* !CONFIG_SGI_IP27 */ /* * NIC register macros diff --git a/include/asm-mips/sn/klconfig.h b/include/asm-mips/sn/klconfig.h index 96cfd2a..39ddb19 100644 --- a/include/asm-mips/sn/klconfig.h +++ b/include/asm-mips/sn/klconfig.h @@ -40,26 +40,10 @@ //#include //#include -#elif defined(CONFIG_SGI_IP35) - -#include -#include -#include -#include - -#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ - -#if defined(CONFIG_SGI_IP27) || defined(CONFIG_SGI_IP35) #include #include #include -#if defined(CONFIG_SGI_IP35) -// The hack file has to be before vector and after sn0_fru.... -#include -#include -#include -#endif /* CONFIG_SGI_IP35 */ -#endif /* CONFIG_SGI_IP27 || CONFIG_SGI_IP35 */ +#endif /* CONFIG_SGI_IP27 */ typedef u64 nic_t; From macro@linux-mips.org Thu Nov 8 15:27:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 15:27:12 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:2470 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20023702AbXKHP1D (ORCPT ); Thu, 8 Nov 2007 15:27:03 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id CF01D40092; Thu, 8 Nov 2007 16:26:33 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id c3UUcOo4ouni; Thu, 8 Nov 2007 16:26:27 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 310F44007E; Thu, 8 Nov 2007 16:26:27 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lA8FQVYL012887; Thu, 8 Nov 2007 16:26:31 +0100 Date: Thu, 8 Nov 2007 15:26:26 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Ulrich Eckhardt , linux-mips Subject: Re: [PATCH] Put cast inside macro instead of all the callers In-Reply-To: <20071101174705.GA23917@linux-mips.org> Message-ID: References: <20071031141124.185599da@ripper.onstor.net> <200711011704.01079.eckhardt@satorlaser.com> <20071101174705.GA23917@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4708/Thu Nov 8 07:07:54 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 1 Nov 2007, Ralf Baechle wrote: > > 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. Except that some versions of GCC "forget" to stop a warning here as irrelevant after the cast, hence the need for the stupid "#ifdef", sigh... > > > 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. The casts were an attempt by myself to shut up GCC warning about comparisons giving a predictable result because of a limited size of the data type used. Of course this is no longer true with "long long", but GCC does not care and warns regardless. A possible workaround would be using auxiliary variables of the "long long" type, but I recall it making GCC produce worse code for some cases. I can check it again, since it has been a while, and if a recent version of GCC produces reasonable code, then I can try to recheck this approach. Please note this code changes quite wildly depending on the exact configuration, so chances are GCC may warn with one, but not another. Maciej From tsbogend@alpha.franken.de Thu Nov 8 21:09:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 21:09:27 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:16806 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20024998AbXKHVJR (ORCPT ); Thu, 8 Nov 2007 21:09:17 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IqEcn-0000kC-00; Thu, 08 Nov 2007 22:09:17 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id F138CDE005; Thu, 8 Nov 2007 22:09:11 +0100 (CET) Date: Thu, 8 Nov 2007 22:09:11 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] SNI PCIT CPLUS: workaround for messed up PCI irq wiring Message-ID: <20071108210911.GA19753@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: 17452 X-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 SNI PCIT CPLUS: workaround for messed up irq wiring for onboard PCI bus 1 Signed-off-by: Thomas Bogendoerfer --- diff --git a/arch/mips/pci/fixup-sni.c b/arch/mips/pci/fixup-sni.c index a45bedd..5c8a79b 100644 --- a/arch/mips/pci/fixup-sni.c +++ b/arch/mips/pci/fixup-sni.c @@ -113,6 +113,16 @@ static char irq_tab_pcit[13][5] __initdata = { { 0, INTA, INTB, INTC, INTD }, /* Slot 5 */ }; +static char irq_tab_pcit_cplus[13][5] __initdata = { + /* INTA INTB INTC INTD */ + { 0, 0, 0, 0, 0 }, /* HOST bridge */ + { 0, INTB, INTC, INTD, INTA }, /* PCI Slot 9 */ + { 0, 0, 0, 0, 0 }, /* PCI-EISA */ + { 0, 0, 0, 0, 0 }, /* Unused */ + { 0, INTA, INTB, INTC, INTD }, /* PCI-PCI bridge */ + { 0, INTB, INTC, INTD, INTA }, /* fixup */ +}; + static inline int is_rm300_revd(void) { unsigned char csmsr = *(volatile unsigned char *)PCIMT_CSMSR; @@ -123,8 +133,19 @@ static inline int is_rm300_revd(void) int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) { switch (sni_brd_type) { - case SNI_BRD_PCI_TOWER: case SNI_BRD_PCI_TOWER_CPLUS: + if (slot == 4) { + /* + * SNI messed up interrupt wiring for onboard + * PCI bus 1; we need to fix this up here + */ + while (dev && dev->bus->number != 1) + dev = dev->bus->self; + if (dev && dev->devfn >= PCI_DEVFN(4, 0)) + slot = 5; + } + return irq_tab_pcit_cplus[slot][pin]; + case SNI_BRD_PCI_TOWER: return irq_tab_pcit[slot][pin]; case SNI_BRD_PCI_MTOWER: -- 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 Thu Nov 8 22:24:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Nov 2007 22:24:42 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37541 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025055AbXKHWYk (ORCPT ); Thu, 8 Nov 2007 22:24:40 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA8MObln010599; Thu, 8 Nov 2007 22:24:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA8MOarj010592; Thu, 8 Nov 2007 22:24:36 GMT Date: Thu, 8 Nov 2007 22:24:36 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] SNI PCIT CPLUS: workaround for messed up PCI irq wiring Message-ID: <20071108222436.GA6535@linux-mips.org> References: <20071108210911.GA19753@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071108210911.GA19753@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: 17453 X-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 08, 2007 at 10:09:11PM +0100, Thomas Bogendoerfer wrote: > SNI PCIT CPLUS: workaround for messed up irq wiring for onboard PCI bus 1 Oh pleassure. Thanks & applied, Ralf From ralf@linux-mips.org Fri Nov 9 09:08:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Nov 2007 09:08:11 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:33425 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021637AbXKIJIJ (ORCPT ); Fri, 9 Nov 2007 09:08:09 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id lA9988cB013181; Fri, 9 Nov 2007 09:08:08 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA997v3b013180; Fri, 9 Nov 2007 09:07:57 GMT Date: Fri, 9 Nov 2007 09:07:57 +0000 From: Ralf Baechle To: Andrew Sharp Cc: "linux-mips@linux-mips.org" Subject: Re: gdb chokes on core from 64-bit kernel (patch) Message-ID: <20071109090757.GA12469@linux-mips.org> References: <20071108140322.7bf03aa9@ripper.onstor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071108140322.7bf03aa9@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: 17454 X-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 08, 2007 at 02:03:22PM -0800, Andrew Sharp wrote: > The gdb from debian etch (6.4.90-debian) doesn't like core files > produced by 64-bit kernel it seems. I've got this patch which seems > to do the job, but I'm unclear on what other implications it might have, > if any. > diff --git a/arch/mips/kernel/binfmt_elfo32.c b/arch/mips/kernel/binfmt_elfo32.c > index 993f7ec..58533dc 100644 > --- a/arch/mips/kernel/binfmt_elfo32.c > +++ b/arch/mips/kernel/binfmt_elfo32.c > @@ -54,9 +54,13 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG]; > > #include > #include > -#include > #include > > +void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs); > +#undef ELF_CORE_COPY_REGS > +#define ELF_CORE_COPY_REGS(_dest,_regs) elf32_core_copy_regs(_dest,_regs); > +#include > + > #define elf_prstatus elf_prstatus32 > struct elf_prstatus32 > { > @@ -109,9 +113,6 @@ jiffies_to_compat_timeval(unsigned long jiffies, struct comp > value->tv_usec = rem / NSEC_PER_USEC; > } > > -#undef ELF_CORE_COPY_REGS > -#define ELF_CORE_COPY_REGS(_dest,_regs) elf32_core_copy_regs(_dest,_regs); > - > void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs) > { > int i; Looks like it's a larger change than needed. > diff --git a/include/asm-mips/reg.h b/include/asm-mips/reg.h > index 634b55d..b44b308 100644 > --- a/include/asm-mips/reg.h > +++ b/include/asm-mips/reg.h > @@ -12,7 +12,7 @@ > #ifndef __ASM_MIPS_REG_H > #define __ASM_MIPS_REG_H > > - > +#define WANT_COMPAT_REG_H > #if defined(CONFIG_32BIT) || defined(WANT_COMPAT_REG_H) > > #define EF_R0 6 > @@ -69,7 +69,7 @@ > > #endif > > -#ifdef CONFIG_64BIT > +#if defined(CONFIG_64BIT) && !defined(WANT_COMPAT_REG_H) > > #define EF_R0 0 > #define EF_R1 1 This change breaks the native 64-bit and N32 ptrace and core dumpers. I suggest something more minimal like the below patch. Does that one do the trick for you? Ralf Signed-off-by: Ralf Baechle arch/mips/kernel/ptrace32.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c index 76818be..44109fb 100644 --- a/arch/mips/kernel/ptrace32.c +++ b/arch/mips/kernel/ptrace32.c @@ -14,6 +14,9 @@ * At this time Linux/MIPS64 only supports syscall tracing, even for 32-bit * binaries. */ + +#define WANT_COMPAT_REG_H + #include #include #include From yoichi_yuasa@tripeaks.co.jp Fri Nov 9 09:44:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Nov 2007 09:44:10 +0000 (GMT) Received: from mo32.po.2iij.NET ([210.128.50.17]:15434 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20021646AbXKIJoB (ORCPT ); Fri, 9 Nov 2007 09:44:01 +0000 Received: by mo.po.2iij.net (mo32) id lA99gWXv095126; Fri, 9 Nov 2007 18:42:32 +0900 (JST) Received: from localhost (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (po-mbox301) id lA99gVuY016643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Nov 2007 18:42:31 +0900 Date: Fri, 9 Nov 2007 18:42:35 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] fix LASAT IRQ overlap Message-Id: <20071109184235.d87433e6.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.20; x86_64-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: 17455 X-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 The range of MIPS_CPU IRQ and the range of LASAT IRQ overlap. This patch has fixed it. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/interrupt.c mips/arch/mips/lasat/interrupt.c --- mips-orig/arch/mips/lasat/interrupt.c 2007-11-09 07:54:54.572826750 +0900 +++ mips/arch/mips/lasat/interrupt.c 2007-11-09 08:15:06.752835750 +0900 @@ -19,17 +19,14 @@ * Lasat boards. */ #include -#include -#include -#include #include -#include +#include #include #include #include -#include -#include + +#include static volatile int *lasat_int_status; static volatile int *lasat_int_mask; @@ -97,12 +94,18 @@ asmlinkage void plat_irq_dispatch(void) /* if int_status == 0, then the interrupt has already been cleared */ if (int_status) { - irq = LASATINT_BASE + ls1bit32(int_status); + irq = LASAT_IRQ_BASE + ls1bit32(int_status); do_IRQ(irq); } } +static struct irqaction cascade = { + .handler = no_action, + .mask = CPU_MASK_NONE, + .name = "cascade", +}; + void __init arch_init_irq(void) { int i; @@ -127,6 +130,9 @@ void __init arch_init_irq(void) } mips_cpu_irq_init(); - for (i = LASATINT_BASE; i <= LASATINT_END; i++) + + for (i = LASAT_IRQ_BASE; i <= LASAT_IRQ_END; i++) set_irq_chip_and_handler(i, &lasat_irq_type, handle_level_irq); + + setup_irq(LASAT_CASCADE_IRQ, &cascade); } diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/pci/pci-lasat.c mips/arch/mips/pci/pci-lasat.c --- mips-orig/arch/mips/pci/pci-lasat.c 2007-11-09 07:54:55.596890750 +0900 +++ mips/arch/mips/pci/pci-lasat.c 2007-11-09 08:33:30.421810750 +0900 @@ -5,12 +5,14 @@ * * Copyright (C) 2000, 2001, 04 Keith M Wesolowski */ -#include #include +#include #include #include + #include -#include + +#include extern struct pci_ops nile4_pci_ops; extern struct pci_ops gt64xxx_pci0_ops; @@ -55,15 +57,15 @@ static int __init lasat_pci_setup(void) arch_initcall(lasat_pci_setup); -#define LASATINT_ETH1 (LASATINT_BASE + 0) -#define LASATINT_ETH0 (LASATINT_BASE + 1) -#define LASATINT_HDC (LASATINT_BASE + 2) -#define LASATINT_COMP (LASATINT_BASE + 3) -#define LASATINT_HDLC (LASATINT_BASE + 4) -#define LASATINT_PCIA (LASATINT_BASE + 5) -#define LASATINT_PCIB (LASATINT_BASE + 6) -#define LASATINT_PCIC (LASATINT_BASE + 7) -#define LASATINT_PCID (LASATINT_BASE + 8) +#define LASAT_IRQ_ETH1 (LASAT_IRQ_BASE + 0) +#define LASAT_IRQ_ETH0 (LASAT_IRQ_BASE + 1) +#define LASAT_IRQ_HDC (LASAT_IRQ_BASE + 2) +#define LASAT_IRQ_COMP (LASAT_IRQ_BASE + 3) +#define LASAT_IRQ_HDLC (LASAT_IRQ_BASE + 4) +#define LASAT_IRQ_PCIA (LASAT_IRQ_BASE + 5) +#define LASAT_IRQ_PCIB (LASAT_IRQ_BASE + 6) +#define LASAT_IRQ_PCIC (LASAT_IRQ_BASE + 7) +#define LASAT_IRQ_PCID (LASAT_IRQ_BASE + 8) int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) { @@ -71,13 +73,13 @@ int __init pcibios_map_irq(const struct case 1: case 2: case 3: - return LASATINT_PCIA + (((slot-1) + (pin-1)) % 4); + return LASAT_IRQ_PCIA + (((slot-1) + (pin-1)) % 4); case 4: - return LASATINT_ETH1; /* Ethernet 1 (LAN 2) */ + return LASAT_IRQ_ETH1; /* Ethernet 1 (LAN 2) */ case 5: - return LASATINT_ETH0; /* Ethernet 0 (LAN 1) */ + return LASAT_IRQ_ETH0; /* Ethernet 0 (LAN 1) */ case 6: - return LASATINT_HDC; /* IDE controller */ + return LASAT_IRQ_HDC; /* IDE controller */ default: return 0xff; /* Illegal */ } diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/lasatint.h mips/include/asm-mips/lasat/lasatint.h --- mips-orig/include/asm-mips/lasat/lasatint.h 2007-11-09 07:57:42.283308000 +0900 +++ mips/include/asm-mips/lasat/lasatint.h 2007-11-09 08:04:47.862157500 +0900 @@ -1,11 +1,6 @@ #ifndef __ASM_LASAT_LASATINT_H #define __ASM_LASAT_LASATINT_H -#include - -#define LASATINT_BASE MIPS_CPU_IRQ_BASE -#define LASATINT_END (LASATINT_BASE + 16) - /* lasat 100 */ #define LASAT_INT_STATUS_REG_100 (KSEG1ADDR(0x1c880000)) #define LASAT_INT_MASK_REG_100 (KSEG1ADDR(0x1c890000)) diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-lasat/irq.h mips/include/asm-mips/mach-lasat/irq.h --- mips-orig/include/asm-mips/mach-lasat/irq.h 1970-01-01 09:00:00.000000000 +0900 +++ mips/include/asm-mips/mach-lasat/irq.h 2007-11-09 08:13:55.012352250 +0900 @@ -0,0 +1,13 @@ +#ifndef _ASM_MACH_LASAT_IRQ_H +#define _ASM_MACH_LASAT_IRQ_H + +#define LASAT_CASCADE_IRQ (MIPS_CPU_IRQ_BASE + 0) + +#define LASAT_IRQ_BASE 8 +#define LASAT_IRQ_END 23 + +#define NR_IRQS 24 + +#include_next + +#endif /* _ASM_MACH_LASAT_IRQ_H */ From ralf@linux-mips.org Fri Nov 9 11:06:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Nov 2007 11:06:35 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:52182 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021617AbXKILGd (ORCPT ); Fri, 9 Nov 2007 11:06:33 +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 lA9B6Xkl015126; Fri, 9 Nov 2007 11:06:33 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lA9B6KIb015125; Fri, 9 Nov 2007 11:06:20 GMT Date: Fri, 9 Nov 2007 11:06:20 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] fix LASAT IRQ overlap Message-ID: <20071109110619.GB12469@linux-mips.org> References: <20071109184235.d87433e6.yoichi_yuasa@tripeaks.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071109184235.d87433e6.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: 17456 X-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 09, 2007 at 06:42:35PM +0900, Yoichi Yuasa wrote: > The range of MIPS_CPU IRQ and the range of LASAT IRQ overlap. > This patch has fixed it. You forgot to mention the tidying up part which really is the majority of the patch ;-) Anyway, thanks & applied. Ralf From fbuihuu@gmail.com Sun Nov 11 08:50:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 08:50:56 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.185]:40845 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026192AbXKKIuq (ORCPT ); Sun, 11 Nov 2007 08:50:46 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1055434fka for ; Sun, 11 Nov 2007 00:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=lPRwvNkBz1hLdXAohL/UTR2A0U7fszZcU8tXzIvYv5U=; b=fnkub2d45E5Hpuo2eyg9K2tl8SyvLOl0BAoK9jjwvZ6xxZIQlWSSZSyq2gKEZfcykiMaDmVwIBqhkAE0MaBM+bSkRL4wip6+RpxerrN+jmlGw/9SWqtz5GmSsPkjsWnU+EJBdrARumQSSjadh7o/EwC5///SvD3dOtB04GPQKdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=DDOO1nEP77pj1OvHQS2eg9aRwcWAOlj3s/Mjofri7DqCcx/QlUDvH6FTPbQa+pGU2rkhluN5KzSxVj9hioNRzRm1MIIz+9t6+lbNEQ8uEqKNiOinS1zg8RTgvD4EyzLYjDUMmbsDla0276rm29J6k+BoNPobr802IJN0IHjRCYI= Received: by 10.86.54.3 with SMTP id c3mr3328314fga.1194771035806; Sun, 11 Nov 2007 00:50:35 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id d6sm3362271fga.2007.11.11.00.50.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Nov 2007 00:50:34 -0800 (PST) Message-ID: <4736C1EA.2050009@gmail.com> Date: Sun, 11 Nov 2007 09:48:42 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: [PATCH] Introduce __fill_user() and kill __bzero() X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Currently memset() is used to fill a user space area (clear_user) or kernel one (memset). These two functions don't have the same prototype, the former returning the number of bytes not copied and the latter returning the start address of the area to clear. This forces memset() to actually returns two values in an unconventional way ie the number of bytes not copied is given by $a2. Therefore clear_user() needs to call memset() using inline assembly. Instead this patch creates __fill_user() which is the same as memset() except it always returns the number of bytes not copied. This simplify clear_user() and makes its definition saner. Also an out of line version of memset is given because gcc generates some calls to it since builtin functions have been disabled. It allows assembly code to call it too. Eventually __bzero() has been removed because it's not part of the Linux uaccess API. And the nano-optimization it brings is not worthing. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/mips_ksyms.c | 3 +- arch/mips/lib/csum_partial.S | 2 +- arch/mips/lib/memcpy.S | 2 +- arch/mips/lib/memset.S | 49 ++++++++++++++++++++++++++-------------- include/asm-mips/string.h | 7 +++++- include/asm-mips/uaccess.h | 17 ++----------- 6 files changed, 44 insertions(+), 36 deletions(-) diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c index 225755d..a801e09 100644 --- a/arch/mips/kernel/mips_ksyms.c +++ b/arch/mips/kernel/mips_ksyms.c @@ -14,7 +14,6 @@ #include #include -extern void *__bzero(void *__s, size_t __count); extern long __strncpy_from_user_nocheck_asm(char *__to, const char *__from, long __len); extern long __strncpy_from_user_asm(char *__to, const char *__from, @@ -36,9 +35,9 @@ EXPORT_SYMBOL(kernel_thread); /* * Userspace access stuff. */ +EXPORT_SYMBOL(__fill_user); EXPORT_SYMBOL(__copy_user); EXPORT_SYMBOL(__copy_user_inatomic); -EXPORT_SYMBOL(__bzero); EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm); EXPORT_SYMBOL(__strncpy_from_user_asm); EXPORT_SYMBOL(__strlen_user_nocheck_asm); diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index c0a77fe..8d3fa1e 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -694,7 +694,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..425f2c3 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -443,7 +443,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 3f8b8b3..cb6b83d 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -46,17 +46,34 @@ .endm /* - * memset(void *s, int c, size_t n) + * An outline version of memset, which should be used either by gcc or + * by assembly code. + */ +NESTED(memset, 24, ra) + PTR_ADDU sp, sp, -24 + LONG_S a0, 16(sp) + LONG_S ra, 20(sp) + jal __fill_user + LONG_L v0, 16(sp) + LONG_L ra, 20(sp) + PTR_ADDU sp, sp, 24 + jr ra +END(memset) + +/* + * __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n) * * a0: start of area to clear * a1: char to fill with * a2: size of area to clear + * + * Returns the number of bytes NOT set or 0 on success. */ .set noreorder .align 5 -LEAF(memset) +LEAF(__fill_user) beqz a1, 1f - move v0, a0 /* result */ + move v0, zero /* result */ andi a1, 0xff /* spread fillword */ LONG_SLL t1, a1, 8 @@ -68,8 +85,6 @@ LEAF(memset) #endif or a1, t1 1: - -FEXPORT(__bzero) sltiu t0, a2, LONGSIZE /* very small region? */ bnez t0, small_memset andi t0, a0, LONGMASK /* aligned? */ @@ -127,7 +142,7 @@ memset_partial: EX(LONG_S_L, a1, -1(a0), last_fixup) #endif 1: jr ra - move a2, zero + nop small_memset: beqz a2, 2f @@ -138,29 +153,29 @@ small_memset: sb a1, -1(a0) 2: jr ra /* done */ - move a2, zero - END(memset) + nop +END(__fill_user) first_fixup: - jr ra - nop + jr ra + move v0, a2 fwd_fixup: PTR_L t0, TI_TASK($28) LONG_L t0, THREAD_BUADDR(t0) - andi a2, 0x3f - LONG_ADDU a2, t1 + andi v0, a2, 0x3f + LONG_ADDU v0, t1 jr ra - LONG_SUBU a2, t0 + LONG_SUBU v0, t0 partial_fixup: PTR_L t0, TI_TASK($28) LONG_L t0, THREAD_BUADDR(t0) - andi a2, LONGMASK - LONG_ADDU a2, t1 + andi v0, a2, LONGMASK + LONG_ADDU v0, t1 jr ra - LONG_SUBU a2, t0 + LONG_SUBU v0, t0 last_fixup: jr ra - andi v1, a2, LONGMASK + andi v0, a2, LONGMASK diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h index 436e3ad..2bba927 100644 --- a/include/asm-mips/string.h +++ b/include/asm-mips/string.h @@ -10,6 +10,7 @@ #ifndef _ASM_STRING_H #define _ASM_STRING_H +#include /* __fill_user() */ /* * Most of the inline functions are rather naive implementations so I just @@ -132,7 +133,11 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) #endif /* CONFIG_32BIT */ #define __HAVE_ARCH_MEMSET -extern void *memset(void *__s, int __c, size_t __count); +extern inline void *memset(void *s, int c, size_t count) +{ + __fill_user(s, c, count); + return s; +} #define __HAVE_ARCH_MEMCPY extern void *memcpy(void *__to, __const__ void *__from, size_t __n); diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index c30c718..8c0d226 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -11,7 +11,6 @@ #include #include -#include #include /* @@ -633,23 +632,13 @@ extern size_t __copy_user_inatomic(void *__to, const void *__from, size_t __n); * Returns number of bytes that could not be cleared. * On success, this will be zero. */ +extern __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n); + static inline __kernel_size_t __clear_user(void __user *addr, __kernel_size_t size) { - __kernel_size_t res; - might_sleep(); - __asm__ __volatile__( - "move\t$4, %1\n\t" - "move\t$5, $0\n\t" - "move\t$6, %2\n\t" - __MODULE_JAL(__bzero) - "move\t%0, $6" - : "=r" (res) - : "r" (addr), "r" (size) - : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31"); - - return res; + return __fill_user(addr, 0, size); } #define clear_user(addr,n) \ -- 1.5.3.4 From fbuihuu@gmail.com Sun Nov 11 08:54:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 08:54:35 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.186]:149 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026210AbXKKIy0 (ORCPT ); Sun, 11 Nov 2007 08:54:26 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1056194fka for ; Sun, 11 Nov 2007 00:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=OM6j83eczy43xjGe1mIEsy2WUa93V0lR2Y0zaHmo2k8=; b=OvkAkaDfjXVvKjZpz35zvANG45APwCxWmLk4/7YUo3KWvS/05ZPrwGfol1gpdymy2hcfj0J0/Fv3aVE3gBYtROE1j7r7C5IrFhUroRzNiwn4OMvtBw4NoUf+j6IaeODLr+aR+A1UUCiEwvlXLD4dLhJ28xTq4TJj1u1e/KJOVEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=jhl+i/06pqwUqyB/W2fNufhkP9jJ3yFw4YzWzU2KNTvH2CmpkykYBtOpzcGlQRX/Un9pmXbXwhlQgbQn+v2M3DUsvmpAwvOG2fF6uyTJsj7ZVKaPFUKcBm+t2GD+OYeloNvx1I++D73DWfK3nsfw/fWckZLKjZz+xntpg/N08u8= Received: by 10.86.4.2 with SMTP id 2mr3292256fgd.1194771256806; Sun, 11 Nov 2007 00:54:16 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id p38sm4750230fke.2007.11.11.00.54.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Nov 2007 00:54:16 -0800 (PST) Message-ID: <4736C2C8.9000709@gmail.com> Date: Sun, 11 Nov 2007 09:52:24 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: [PATCH] Use __fill_user() to clear bss. X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips bss is relatively big, more than 70Kb on cobalt config, so it's a pity to clear it one word per loop. Instead this patch uses __fill_user(), which should be faster. Since we do a function jump to __fill_user(), argument registers needs to be modified. However at this point, they contains the firmware arguments which are saved the bss section. To avoid issue, this patch makes them part of the data section. Also this patch makes sure that sp is setup before doing a jal. Signed-off-by: Franck Bui-Huu --- Ralf, I haven't done any benchmarks but it seems the right thing to do. Please consider, Franck arch/mips/kernel/head.S | 14 ++++++-------- arch/mips/kernel/setup.c | 13 ++++++++++--- 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S index 2367687..97273ae 100644 --- a/arch/mips/kernel/head.S +++ b/arch/mips/kernel/head.S @@ -171,14 +171,6 @@ NESTED(kernel_entry, 16, sp) # kernel entry point mtc0 t0, CP0_STATUS #endif /* CONFIG_MIPS_MT_SMTC */ - PTR_LA t0, __bss_start # clear .bss - LONG_S zero, (t0) - PTR_LA t1, __bss_stop - LONGSIZE -1: - PTR_ADDIU t0, LONGSIZE - LONG_S zero, (t0) - bne t0, t1, 1b - LONG_S a0, fw_arg0 # firmware arguments LONG_S a1, fw_arg1 LONG_S a2, fw_arg2 @@ -191,6 +183,12 @@ NESTED(kernel_entry, 16, sp) # kernel entry point set_saved_sp sp, t0, t1 PTR_SUBU sp, 4 * SZREG # init stack pointer + PTR_LA a0, __bss_start # clear .bss + move a1, zero + PTR_LA a2, __bss_stop + LONG_SUBU a2, a0 + jal __fill_user # no need to save ra + j start_kernel END(kernel_entry) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index a06a27d..0eee73f 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -30,6 +30,7 @@ #include #include +unsigned long kernelsp[NR_CPUS]; struct cpuinfo_mips cpu_data[NR_CPUS] __read_mostly; EXPORT_SYMBOL(cpu_data); @@ -39,6 +40,15 @@ struct screen_info screen_info; #endif /* + * Note: they're part of the data section because they're used + * *before* bss is cleared. + */ +unsigned long fw_arg0 = ULONG_MAX; +unsigned long fw_arg1 = ULONG_MAX; +unsigned long fw_arg2 = ULONG_MAX; +unsigned long fw_arg3 = ULONG_MAX; + +/* * Despite it's name this variable is even if we don't have PCI */ unsigned int PCI_DMA_BUS_IS_PHYS; @@ -571,9 +581,6 @@ static int __init dsp_disable(char *s) __setup("nodsp", dsp_disable); -unsigned long kernelsp[NR_CPUS]; -unsigned long fw_arg0, fw_arg1, fw_arg2, fw_arg3; - #ifdef CONFIG_DEBUG_FS struct dentry *mips_debugfs_dir; static int __init debugfs_mips(void) -- 1.5.3.4 From tbm@cyrius.com Sun Nov 11 11:08:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 11:08:21 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:18183 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20026389AbXKKLIN (ORCPT ); Sun, 11 Nov 2007 11:08:13 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id D27E1D8C9; Sun, 11 Nov 2007 11:08:06 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 1364154564; Sun, 11 Nov 2007 12:07:53 +0100 (CET) Date: Sun, 11 Nov 2007 12:07:53 +0100 From: Martin Michlmayr To: debian-mips@lists.debian.org Cc: debian-boot@lists.debian.org, hardware-donations@debian.org, linux-mips@linux-mips.org Subject: Re: Donation of an Indigo 2 R4K@250 Message-ID: <20071111110752.GA21220@deprecation.cyrius.com> References: <20071105141248.GQ6244@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071105141248.GQ6244@deprecation.cyrius.com> 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: 17459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips Anyone interested? * Martin Michlmayr [2007-11-05 15:12]: > If anyone is interested in an Indigo 2 located in Cologne, Germany, > please let me know. > > > I would like to donate the MIPS porters an SGI Indigo 2 R4K@250Mhz. > > Fully working, keyboard/mouse/monitor included, but no IRIX. > > > > The machine is located in Cologne/Germany - pickup preferred... > > -- > Martin Michlmayr > http://www.cyrius.com/ > > > -- > To UNSUBSCRIBE, email to debian-mips-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org -- Martin Michlmayr http://www.cyrius.com/ From ths@networkno.de Sun Nov 11 13:01:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 13:01:47 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:10955 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20026618AbXKKNBj (ORCPT ); Sun, 11 Nov 2007 13:01:39 +0000 Received: from lagash (88-106-176-50.dynamic.dsl.as9105.com [88.106.176.50]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id 857CD490D9; Sun, 11 Nov 2007 12:47:33 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IrCRP-0008AB-48; Sun, 11 Nov 2007 13:01:31 +0000 Date: Sun, 11 Nov 2007 13:01:31 +0000 From: Thiemo Seufer To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() Message-ID: <20071111130130.GB8363@networkno.de> References: <4736C1EA.2050009@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4736C1EA.2050009@gmail.com> 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: 17460 X-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 Franck Bui-Huu wrote: > Currently memset() is used to fill a user space area (clear_user) or > kernel one (memset). These two functions don't have the same > prototype, the former returning the number of bytes not copied and the > latter returning the start address of the area to clear. This forces > memset() to actually returns two values in an unconventional way ie > the number of bytes not copied is given by $a2. Therefore clear_user() > needs to call memset() using inline assembly. > > Instead this patch creates __fill_user() which is the same as memset() > except it always returns the number of bytes not copied. This simplify > clear_user() and makes its definition saner. > > Also an out of line version of memset is given because gcc generates > some calls to it since builtin functions have been disabled. It allows > assembly code to call it too. > > Eventually __bzero() has been removed because it's not part of the > Linux uaccess API. And the nano-optimization it brings is not > worthing. > > Signed-off-by: Franck Bui-Huu > --- > arch/mips/kernel/mips_ksyms.c | 3 +- > arch/mips/lib/csum_partial.S | 2 +- > arch/mips/lib/memcpy.S | 2 +- > arch/mips/lib/memset.S | 49 ++++++++++++++++++++++++++-------------- > include/asm-mips/string.h | 7 +++++- > include/asm-mips/uaccess.h | 17 ++----------- > 6 files changed, 44 insertions(+), 36 deletions(-) > > diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c > index 225755d..a801e09 100644 > --- a/arch/mips/kernel/mips_ksyms.c > +++ b/arch/mips/kernel/mips_ksyms.c > @@ -14,7 +14,6 @@ > #include > #include > > -extern void *__bzero(void *__s, size_t __count); > extern long __strncpy_from_user_nocheck_asm(char *__to, > const char *__from, long __len); > extern long __strncpy_from_user_asm(char *__to, const char *__from, > @@ -36,9 +35,9 @@ EXPORT_SYMBOL(kernel_thread); > /* > * Userspace access stuff. > */ > +EXPORT_SYMBOL(__fill_user); > EXPORT_SYMBOL(__copy_user); > EXPORT_SYMBOL(__copy_user_inatomic); > -EXPORT_SYMBOL(__bzero); > EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm); > EXPORT_SYMBOL(__strncpy_from_user_asm); > EXPORT_SYMBOL(__strlen_user_nocheck_asm); > diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S > index c0a77fe..8d3fa1e 100644 > --- a/arch/mips/lib/csum_partial.S > +++ b/arch/mips/lib/csum_partial.S > @@ -694,7 +694,7 @@ l_exc: > ADD dst, t0 # compute start address in a1 > SUB dst, src > /* > - * Clear len bytes starting at dst. Can't call __bzero because it > + * Clear len bytes starting at dst. Can't call memset because it > * might modify len. An inefficient loop for these rare times... > */ > beqz len, done > diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S > index a526c62..425f2c3 100644 > --- a/arch/mips/lib/memcpy.S > +++ b/arch/mips/lib/memcpy.S > @@ -443,7 +443,7 @@ l_exc: > ADD dst, t0 # compute start address in a1 > SUB dst, src > /* > - * Clear len bytes starting at dst. Can't call __bzero because it > + * Clear len bytes starting at dst. Can't call memset because it > * might modify len. An inefficient loop for these rare times... > */ > beqz len, done > diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S > index 3f8b8b3..cb6b83d 100644 > --- a/arch/mips/lib/memset.S > +++ b/arch/mips/lib/memset.S > @@ -46,17 +46,34 @@ > .endm > > /* > - * memset(void *s, int c, size_t n) > + * An outline version of memset, which should be used either by gcc or > + * by assembly code. > + */ > +NESTED(memset, 24, ra) > + PTR_ADDU sp, sp, -24 > + LONG_S a0, 16(sp) > + LONG_S ra, 20(sp) > + jal __fill_user > + LONG_L v0, 16(sp) > + LONG_L ra, 20(sp) > + PTR_ADDU sp, sp, 24 > + jr ra > +END(memset) This will break on 64bit kernels. Thiemo From vagabon.xyz@gmail.com Sun Nov 11 13:59:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 13:59:53 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.188]:5358 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026792AbXKKN7o (ORCPT ); Sun, 11 Nov 2007 13:59:44 +0000 Received: by nf-out-0910.google.com with SMTP id c10so747391nfd for ; Sun, 11 Nov 2007 05:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=neVcTXFPSfP8rSxdiGkkgDRfYwjtnGilTTLB0FRC0Zw=; b=O2assTj2ZeBG+/xHaYobd6oAyxTSOnmGnxX5lAxXnTO3fQc6alGkE3voIyW24Bek0ExrnSjmlWoXIpGTJ5L1AIVEYWc5IAA+VXsIU0yf8XiThWwSqbchPKGVyi8bZTYIAuKIdiQScdn2o0qqYgWO1pwq+CjIMLFcarrnucnqtqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iqIGVVvcqbTGS4kg/JVYznnMMmkN4yrI1/viyPntTJpkqHmqiu72NW9UgltX2Wyp4WgtPEqhdjUYXDA7Chr2WiPgPuWKuwuQYreg0mMY0VXlEK4LoN/34YnQwvG895HlcwK9x/JxdNMWpRi11eY/SvI85XewOMRrXSIE0CTnEho= Received: by 10.86.49.13 with SMTP id w13mr3543323fgw.1194789583605; Sun, 11 Nov 2007 05:59:43 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id e32sm518447fke.2007.11.11.05.59.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Nov 2007 05:59:42 -0800 (PST) Message-ID: <47370A5C.8060200@gmail.com> Date: Sun, 11 Nov 2007 14:57:48 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Thiemo Seufer CC: Ralf Baechle , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() References: <4736C1EA.2050009@gmail.com> <20071111130130.GB8363@networkno.de> In-Reply-To: <20071111130130.GB8363@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: >> /* >> - * memset(void *s, int c, size_t n) >> + * An outline version of memset, which should be used either by gcc or >> + * by assembly code. >> + */ >> +NESTED(memset, 24, ra) >> + PTR_ADDU sp, sp, -24 >> + LONG_S a0, 16(sp) >> + LONG_S ra, 20(sp) >> + jal __fill_user >> + LONG_L v0, 16(sp) >> + LONG_L ra, 20(sp) >> + PTR_ADDU sp, sp, 24 >> + jr ra >> +END(memset) > > This will break on 64bit kernels. > Obviously... Looks like I should find a good place to implement it in C... or do you know a sane way (without too many #ifdef) to do that in assembly code ? thanks, Franck From tsbogend@alpha.franken.de Sun Nov 11 14:33:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 14:33:08 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:38299 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20026821AbXKKOdA (ORCPT ); Sun, 11 Nov 2007 14:33:00 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IrDrv-0004ny-00 for linux-mips@linux-mips.org; Sun, 11 Nov 2007 15:32:59 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id A4598C2144; Sun, 11 Nov 2007 15:33:02 +0100 (CET) Date: Sun, 11 Nov 2007 15:33:02 +0100 To: linux-mips@linux-mips.org Subject: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0 Message-ID: <20071111143302.GA26458@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: 17462 X-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 I tried to get a working 64bit kernel for SNI RM. Most of things to fix were quite obvious, but there is one thing, which I haven't understood yet. The firmware is only able to boot ELF32 images, which mean I need to use BOOT_ELF32. RM machines have 256MB memory mapped to KSEG0, anything else is outside. To me that would mean I need to use the default spaces from mach-generic/spaces.h. A kernel built that way will hang after calling schedule() in rest_init() (init/main.c). Has anybody seen this as well ? Before digging into schedule() I decided to try mach-ip22/spaces.h and limit the installed memory to 256MB. This kernel boots and runs fine. Then I booted that kernel with all memory (512MB) and it died, when init had troubles mapping libc. That result didn't surprise me that much, since the kernel probably tried to map memory > 256MB via CKSEG0, which won't work. Correct ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From anemo@mba.ocn.ne.jp Sun Nov 11 16:04:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 16:04:40 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:36833 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20023178AbXKKQEb (ORCPT ); Sun, 11 Nov 2007 16:04:31 +0000 Received: from localhost (p5137-ipad310funabasi.chiba.ocn.ne.jp [123.217.207.137]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id F38568EEB; Mon, 12 Nov 2007 01:03:09 +0900 (JST) Date: Mon, 12 Nov 2007 01:05:16 +0900 (JST) Message-Id: <20071112.010516.126571959.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] Move kernel/time/Kconfig menu to appropriate place From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17463 X-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 CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS should be selected in "Kernel type" menu, not in "CPU selection" menu. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2f2ce0c..2ee0330 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -961,8 +961,6 @@ config BOOT_ELF64 menu "CPU selection" -source "kernel/time/Kconfig" - choice prompt "CPU type" default CPU_R4X00 @@ -1734,6 +1732,8 @@ config NR_CPUS performance should round up your number of processors to the next power of two. +source "kernel/time/Kconfig" + # # Timer Interrupt Frequency Configuration # From anemo@mba.ocn.ne.jp Sun Nov 11 16:30:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 16:30:25 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:27898 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20027191AbXKKQaP (ORCPT ); Sun, 11 Nov 2007 16:30:15 +0000 Received: from localhost (p5137-ipad310funabasi.chiba.ocn.ne.jp [123.217.207.137]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 9ACBE9CB6; Mon, 12 Nov 2007 01:30:10 +0900 (JST) Date: Mon, 12 Nov 2007 01:32:17 +0900 (JST) Message-Id: <20071112.013217.59032950.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, wim@iguana.be Subject: [PATCH 1/2] TXx9 watchdog driver From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17464 X-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 This is a driver for watchdog timer built into TXx9 MIPS SoCs. Signed-off-by: Atsushi Nemoto --- drivers/watchdog/Kconfig | 6 + drivers/watchdog/Makefile | 1 + drivers/watchdog/txx9wdt.c | 276 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 283 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 2792bc1..7484ee6 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -616,6 +616,12 @@ config AR7_WDT help Hardware driver for the TI AR7 Watchdog Timer. +config TXX9_WDT + tristate "Toshiba TXx9 Watchdog Timer" + depends on CPU_TX39XX || CPU_TX49XX + help + Hardware driver for the built-in watchdog timer on TXx9 MIPS SoCs. + # PARISC Architecture # POWERPC Architecture diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 7d9e573..0458e62 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -91,6 +91,7 @@ obj-$(CONFIG_INDYDOG) += indydog.o obj-$(CONFIG_WDT_MTX1) += mtx-1_wdt.o obj-$(CONFIG_WDT_RM9K_GPI) += rm9k_wdt.o obj-$(CONFIG_AR7_WDT) += ar7_wdt.o +obj-$(CONFIG_TXX9_WDT) += txx9wdt.o # PARISC Architecture diff --git a/drivers/watchdog/txx9wdt.c b/drivers/watchdog/txx9wdt.c new file mode 100644 index 0000000..f3af8f5 --- /dev/null +++ b/drivers/watchdog/txx9wdt.c @@ -0,0 +1,276 @@ +/* + * txx9wdt: A Hardware Watchdog Driver for TXx9 SoCs + * + * Copyright (C) 2007 Atsushi Nemoto + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TIMER_MARGIN 60 /* Default is 60 seconds */ + +static int timeout = TIMER_MARGIN; /* in seconds */ +module_param(timeout, int, 0); +MODULE_PARM_DESC(timeout, + "Watchdog timeout in seconds. " + "(0> (32 - TXX9_TIMER_BITS)) / WD_TIMER_CLK) + +static unsigned long txx9wdt_alive; +static int expect_close; +static struct txx9_tmr_reg __iomem *txx9wdt_reg; +static struct clk *txx9_imclk; + +static void txx9wdt_ping(void) +{ + __raw_writel(TXx9_TMWTMR_TWIE | TXx9_TMWTMR_TWC, &txx9wdt_reg->wtmr); +} + +static void txx9wdt_start(void) +{ + __raw_writel(WD_TIMER_CLK * timeout, &txx9wdt_reg->cpra); + __raw_writel(WD_TIMER_CCD, &txx9wdt_reg->ccdr); + __raw_writel(0, &txx9wdt_reg->tisr); /* clear pending interrupt */ + __raw_writel(TXx9_TMTCR_TCE | TXx9_TMTCR_CCDE | TXx9_TMTCR_TMODE_WDOG, + &txx9wdt_reg->tcr); + __raw_writel(TXx9_TMWTMR_TWIE | TXx9_TMWTMR_TWC, &txx9wdt_reg->wtmr); +} + +static void txx9wdt_stop(void) +{ + __raw_writel(TXx9_TMWTMR_WDIS, &txx9wdt_reg->wtmr); + __raw_writel(__raw_readl(&txx9wdt_reg->tcr) & ~TXx9_TMTCR_TCE, + &txx9wdt_reg->tcr); +} + +static int txx9wdt_open(struct inode *inode, struct file *file) +{ + if (test_and_set_bit(0, &txx9wdt_alive)) + return -EBUSY; + + if (__raw_readl(&txx9wdt_reg->tcr) & TXx9_TMTCR_TCE) { + clear_bit(0, &txx9wdt_alive); + return -EBUSY; + } + + if (nowayout) + __module_get(THIS_MODULE); + + txx9wdt_start(); + return nonseekable_open(inode, file); +} + +static int txx9wdt_release(struct inode *inode, struct file *file) +{ + if (expect_close) + txx9wdt_stop(); + else { + printk(KERN_CRIT "txx9wdt: " + "Unexpected close, not stopping watchdog!\n"); + txx9wdt_ping(); + } + clear_bit(0, &txx9wdt_alive); + expect_close = 0; + return 0; +} + +static ssize_t txx9wdt_write(struct file *file, const char __user *data, + size_t len, loff_t *ppos) +{ + if (len) { + if (!nowayout) { + size_t i; + + expect_close = 0; + for (i = 0; i != len; i++) { + char c; + if (get_user(c, data + i)) + return -EFAULT; + if (c == 'V') + expect_close = 1; + } + } + txx9wdt_ping(); + } + return len; +} + +static int txx9wdt_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + void __user *argp = (void __user *)arg; + int __user *p = argp; + int new_timeout; + static struct watchdog_info ident = { + .options = WDIOF_SETTIMEOUT | + WDIOF_KEEPALIVEPING | + WDIOF_MAGICCLOSE, + .firmware_version = 0, + .identity = "Hardware Watchdog for TXx9", + }; + + switch (cmd) { + default: + return -ENOTTY; + case WDIOC_GETSUPPORT: + return copy_to_user(argp, &ident, sizeof(ident)) ? -EFAULT : 0; + case WDIOC_GETSTATUS: + case WDIOC_GETBOOTSTATUS: + return put_user(0, p); + case WDIOC_KEEPALIVE: + txx9wdt_ping(); + return 0; + case WDIOC_SETTIMEOUT: + if (get_user(new_timeout, p)) + return -EFAULT; + if (new_timeout < 1 || new_timeout > WD_MAX_TIMEOUT) + return -EINVAL; + timeout = new_timeout; + txx9wdt_stop(); + txx9wdt_start(); + /* Fall */ + case WDIOC_GETTIMEOUT: + return put_user(timeout, p); + } +} + +static int txx9wdt_notify_sys(struct notifier_block *this, unsigned long code, + void *unused) +{ + if (code == SYS_DOWN || code == SYS_HALT) + txx9wdt_stop(); + return NOTIFY_DONE; +} + +static const struct file_operations txx9wdt_fops = { + .owner = THIS_MODULE, + .llseek = no_llseek, + .write = txx9wdt_write, + .ioctl = txx9wdt_ioctl, + .open = txx9wdt_open, + .release = txx9wdt_release, +}; + +static struct miscdevice txx9wdt_miscdev = { + .minor = WATCHDOG_MINOR, + .name = "watchdog", + .fops = &txx9wdt_fops, +}; + +static struct notifier_block txx9wdt_notifier = { + .notifier_call = txx9wdt_notify_sys +}; + +static int __init txx9wdt_probe(struct platform_device *dev) +{ + struct resource *res; + int ret; + + txx9_imclk = clk_get(NULL, "imbus_clk"); + if (IS_ERR(txx9_imclk)) { + ret = PTR_ERR(txx9_imclk); + txx9_imclk = NULL; + goto exit; + } + ret = clk_enable(txx9_imclk); + if (ret) { + clk_put(txx9_imclk); + txx9_imclk = NULL; + goto exit; + } + + res = platform_get_resource(dev, IORESOURCE_MEM, 0); + if (!res) + goto exit_busy; + if (!devm_request_mem_region(&dev->dev, + res->start, res->end - res->start + 1, + "txx9wdt")) + goto exit_busy; + txx9wdt_reg = devm_ioremap(&dev->dev, + res->start, res->end - res->start + 1); + if (!txx9wdt_reg) + goto exit_busy; + + ret = misc_register(&txx9wdt_miscdev); + if (ret) + goto exit; + + ret = register_reboot_notifier(&txx9wdt_notifier); + if (ret) { + misc_deregister(&txx9wdt_miscdev); + goto exit; + } + + printk(KERN_INFO "Hardware Watchdog Timer for TXx9: " + "timeout=%d sec (max %ld) (nowayout= %d)\n", + timeout, WD_MAX_TIMEOUT, nowayout); + + return 0; +exit_busy: + ret = -EBUSY; +exit: + if (txx9_imclk) { + clk_disable(txx9_imclk); + clk_put(txx9_imclk); + } + return ret; +} + +static int __exit txx9wdt_remove(struct platform_device *dev) +{ + misc_deregister(&txx9wdt_miscdev); + unregister_reboot_notifier(&txx9wdt_notifier); + clk_disable(txx9_imclk); + clk_put(txx9_imclk); + return 0; +} + +static struct platform_driver txx9wdt_driver = { + .remove = __exit_p(txx9wdt_remove), + .driver = { + .name = "txx9wdt", + .owner = THIS_MODULE, + }, +}; + +static int __init watchdog_init(void) +{ + return platform_driver_probe(&txx9wdt_driver, txx9wdt_probe); +} + +static void __exit watchdog_exit(void) +{ + platform_driver_unregister(&txx9wdt_driver); +} + +module_init(watchdog_init); +module_exit(watchdog_exit); + +MODULE_DESCRIPTION("TXx9 Watchdog Driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR); From anemo@mba.ocn.ne.jp Sun Nov 11 16:31:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 16:31:46 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:50632 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20027111AbXKKQbg (ORCPT ); Sun, 11 Nov 2007 16:31:36 +0000 Received: from localhost (p5137-ipad310funabasi.chiba.ocn.ne.jp [123.217.207.137]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 6E3919DB2; Mon, 12 Nov 2007 01:30:14 +0900 (JST) Date: Mon, 12 Nov 2007 01:32:20 +0900 (JST) Message-Id: <20071112.013220.96686193.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, wim@iguana.be Subject: [PATCH 2/2] TXx9 watchdog support for rbhma3100,rbhma4200,rbhma4500 From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17465 X-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 This patch adds support for txx9wdt driver to rbhma3100, rbhma4200 and rbhma4500 platform. Signed-off-by: Atsushi Nemoto --- This is a patch against linux-queue tree in linux-mips.org arch/mips/configs/jmr3927_defconfig | 15 +++++- arch/mips/configs/rbhma4200_defconfig | 15 +++++- arch/mips/configs/rbhma4500_defconfig | 15 +++++- arch/mips/jmr3927/rbhma3100/setup.c | 55 ++++++++++++++++++++ .../toshiba_rbtx4927/toshiba_rbtx4927_setup.c | 55 ++++++++++++++++++++ arch/mips/tx4938/toshiba_rbtx4938/setup.c | 25 +++++++++ include/asm-mips/tx4927/tx4927_pci.h | 1 + 7 files changed, 178 insertions(+), 3 deletions(-) diff --git a/arch/mips/configs/jmr3927_defconfig b/arch/mips/configs/jmr3927_defconfig index eb96791..4ace378 100644 --- a/arch/mips/configs/jmr3927_defconfig +++ b/arch/mips/configs/jmr3927_defconfig @@ -464,7 +464,6 @@ CONFIG_SERIAL_TXX9_STDSERIAL=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set -# CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_RTC is not set # CONFIG_R3964 is not set @@ -482,6 +481,20 @@ CONFIG_DEVPORT=y # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_TXX9_WDT=y + +# +# PCI-based Watchdog Cards +# +# CONFIG_PCIPCWATCHDOG is not set +# CONFIG_WDTPCI is not set # # Multifunction device drivers diff --git a/arch/mips/configs/rbhma4200_defconfig b/arch/mips/configs/rbhma4200_defconfig index 9383a59..a67c698 100644 --- a/arch/mips/configs/rbhma4200_defconfig +++ b/arch/mips/configs/rbhma4200_defconfig @@ -431,7 +431,6 @@ CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set -# CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_RTC is not set # CONFIG_R3964 is not set @@ -449,6 +448,20 @@ CONFIG_DEVPORT=y # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_TXX9_WDT=m + +# +# PCI-based Watchdog Cards +# +# CONFIG_PCIPCWATCHDOG is not set +# CONFIG_WDTPCI is not set # # Multifunction device drivers diff --git a/arch/mips/configs/rbhma4500_defconfig b/arch/mips/configs/rbhma4500_defconfig index d1b56cc..ebc8ad4 100644 --- a/arch/mips/configs/rbhma4500_defconfig +++ b/arch/mips/configs/rbhma4500_defconfig @@ -450,7 +450,6 @@ CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set -# CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_RTC is not set # CONFIG_R3964 is not set @@ -479,6 +478,20 @@ CONFIG_SPI_AT25=y # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_TXX9_WDT=m + +# +# PCI-based Watchdog Cards +# +# CONFIG_PCIPCWATCHDOG is not set +# CONFIG_WDTPCI is not set # # Multifunction device drivers diff --git a/arch/mips/jmr3927/rbhma3100/setup.c b/arch/mips/jmr3927/rbhma3100/setup.c index 75cfe65..c886d80 100644 --- a/arch/mips/jmr3927/rbhma3100/setup.c +++ b/arch/mips/jmr3927/rbhma3100/setup.c @@ -35,6 +35,7 @@ #include #include #include +#include #ifdef CONFIG_SERIAL_TXX9 #include #endif @@ -233,6 +234,8 @@ static void __init tx3927_setup(void) tx3927_ccfgptr->ccfg &= ~TX3927_CCFG_BEOW; /* Disable PCI snoop */ tx3927_ccfgptr->ccfg &= ~TX3927_CCFG_PSNP; + /* do reset on watchdog */ + tx3927_ccfgptr->ccfg |= TX3927_CCFG_WR; #ifdef DO_WRITE_THROUGH /* Enable PCI SNOOP - with write through only */ @@ -383,3 +386,55 @@ static int __init jmr3927_rtc_init(void) return IS_ERR(dev) ? PTR_ERR(dev) : 0; } device_initcall(jmr3927_rtc_init); + +/* Watchdog support */ + +static int __init txx9_wdt_init(unsigned long base) +{ + struct resource res = { + .start = base, + .end = base + 0x100 - 1, + .flags = IORESOURCE_MEM, + }; + struct platform_device *dev = + platform_device_register_simple("txx9wdt", -1, &res, 1); + return IS_ERR(dev) ? PTR_ERR(dev) : 0; +} + +static int __init jmr3927_wdt_init(void) +{ + return txx9_wdt_init(TX3927_TMR_REG(2)); +} +device_initcall(jmr3927_wdt_init); + +/* Minimum CLK support */ + +struct clk *clk_get(struct device *dev, const char *id) +{ + if (!strcmp(id, "imbus_clk")) + return (struct clk *)JMR3927_IMCLK; + return ERR_PTR(-ENOENT); +} +EXPORT_SYMBOL(clk_get); + +int clk_enable(struct clk *clk) +{ + return 0; +} +EXPORT_SYMBOL(clk_enable); + +void clk_disable(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_disable); + +unsigned long clk_get_rate(struct clk *clk) +{ + return (unsigned long)clk; +} +EXPORT_SYMBOL(clk_get_rate); + +void clk_put(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_put); diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c index c29a528..e466e5e 100644 --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c @@ -50,6 +50,7 @@ #include #include #include +#include #include #include @@ -803,6 +804,8 @@ void __init plat_mem_setup(void) } /* CCFG */ + /* do reset on watchdog */ + tx4927_ccfgptr->ccfg |= TX4927_CCFG_WR; /* enable Timeout BusError */ if (tx4927_ccfg_toeon) tx4927_ccfgptr->ccfg |= TX4927_CCFG_TOE; @@ -944,3 +947,55 @@ static int __init rbtx4927_ne_init(void) return IS_ERR(dev) ? PTR_ERR(dev) : 0; } device_initcall(rbtx4927_ne_init); + +/* Watchdog support */ + +static int __init txx9_wdt_init(unsigned long base) +{ + struct resource res = { + .start = base, + .end = base + 0x100 - 1, + .flags = IORESOURCE_MEM, + }; + struct platform_device *dev = + platform_device_register_simple("txx9wdt", -1, &res, 1); + return IS_ERR(dev) ? PTR_ERR(dev) : 0; +} + +static int __init rbtx4927_wdt_init(void) +{ + return txx9_wdt_init(TX4927_TMR_REG(2) & 0xfffffffffULL); +} +device_initcall(rbtx4927_wdt_init); + +/* Minimum CLK support */ + +struct clk *clk_get(struct device *dev, const char *id) +{ + if (!strcmp(id, "imbus_clk")) + return (struct clk *)50000000; + return ERR_PTR(-ENOENT); +} +EXPORT_SYMBOL(clk_get); + +int clk_enable(struct clk *clk) +{ + return 0; +} +EXPORT_SYMBOL(clk_enable); + +void clk_disable(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_disable); + +unsigned long clk_get_rate(struct clk *clk) +{ + return (unsigned long)clk; +} +EXPORT_SYMBOL(clk_get_rate); + +void clk_put(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_put); diff --git a/arch/mips/tx4938/toshiba_rbtx4938/setup.c b/arch/mips/tx4938/toshiba_rbtx4938/setup.c index d13af99..47a9c17 100644 --- a/arch/mips/tx4938/toshiba_rbtx4938/setup.c +++ b/arch/mips/tx4938/toshiba_rbtx4938/setup.c @@ -724,6 +724,8 @@ void __init tx4938_board_setup(void) /* CCFG */ /* clear WatchDogReset,BusErrorOnWrite flag (W1C) */ tx4938_ccfgptr->ccfg |= TX4938_CCFG_WDRST | TX4938_CCFG_BEOW; + /* do reset on watchdog */ + tx4938_ccfgptr->ccfg |= TX4938_CCFG_WR; /* clear PCIC1 reset */ if (tx4938_ccfgptr->clkctr & TX4938_CLKCTR_PCIC1RST) tx4938_ccfgptr->clkctr &= ~TX4938_CLKCTR_PCIC1RST; @@ -1121,12 +1123,35 @@ static int __init rbtx4938_spi_init(void) } arch_initcall(rbtx4938_spi_init); +/* Watchdog support */ + +static int __init txx9_wdt_init(unsigned long base) +{ + struct resource res = { + .start = base, + .end = base + 0x100 - 1, + .flags = IORESOURCE_MEM, + .parent = &tx4938_reg_resource, + }; + struct platform_device *dev = + platform_device_register_simple("txx9wdt", -1, &res, 1); + return IS_ERR(dev) ? PTR_ERR(dev) : 0; +} + +static int __init rbtx4938_wdt_init(void) +{ + return txx9_wdt_init(TX4938_TMR_REG(2) & 0xfffffffffULL); +} +device_initcall(rbtx4938_wdt_init); + /* Minimum CLK support */ struct clk *clk_get(struct device *dev, const char *id) { if (!strcmp(id, "spi-baseclk")) return (struct clk *)(txx9_gbus_clock / 2 / 4); + if (!strcmp(id, "imbus_clk")) + return (struct clk *)(txx9_gbus_clock / 2); return ERR_PTR(-ENOENT); } EXPORT_SYMBOL(clk_get); diff --git a/include/asm-mips/tx4927/tx4927_pci.h b/include/asm-mips/tx4927/tx4927_pci.h index 3f1e470..0be77df 100644 --- a/include/asm-mips/tx4927/tx4927_pci.h +++ b/include/asm-mips/tx4927/tx4927_pci.h @@ -9,6 +9,7 @@ #define __ASM_TX4927_TX4927_PCI_H #define TX4927_CCFG_TOE 0x00004000 +#define TX4927_CCFG_WR 0x00008000 #define TX4927_CCFG_TINTDIS 0x01000000 #define TX4927_PCIMEM 0x08000000 From anemo@mba.ocn.ne.jp Sun Nov 11 17:03:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 17:03:26 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:30456 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20027268AbXKKRDR (ORCPT ); Sun, 11 Nov 2007 17:03:17 +0000 Received: from localhost (p5137-ipad310funabasi.chiba.ocn.ne.jp [123.217.207.137]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 310B29AE2; Mon, 12 Nov 2007 02:03:12 +0900 (JST) Date: Mon, 12 Nov 2007 02:05:18 +0900 (JST) Message-Id: <20071112.020518.130850270.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: <20071107.003925.74752709.anemo@mba.ocn.ne.jp> References: <20071031163900.GB22871@linux-mips.org> <20071103.014649.122254137.anemo@mba.ocn.ne.jp> <20071107.003925.74752709.anemo@mba.ocn.ne.jp> 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: 17466 X-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 Take 3. Remove unnecessary .mips0 and make rollback_handler a bit faster. ------------------------------------------------------------------------ Subject: Fix potential latency problem due to non-atomic cpu_wait. If an interrupt happened between checking of NEED_RESCHED and WAIT instruction, adjust EPC to restart from checking of NEED_RESCHED. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/cpu-probe.c | 16 ++-------------- arch/mips/kernel/genex.S | 37 +++++++++++++++++++++++++++++++++++++ arch/mips/kernel/traps.c | 22 ++++++++++++++++------ 3 files changed, 55 insertions(+), 20 deletions(-) diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index 5c27943..1f71fec 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -45,18 +45,7 @@ static void r39xx_wait(void) local_irq_enable(); } -/* - * There is a race when WAIT instruction executed with interrupt - * enabled. - * But it is implementation-dependent wheter the pipelie restarts when - * a non-enabled interrupt is requested. - */ -static void r4k_wait(void) -{ - __asm__(" .set mips3 \n" - " wait \n" - " .set mips0 \n"); -} +extern void r4k_wait(void); /* * This variant is preferable as it allows testing need_resched and going to @@ -128,7 +117,7 @@ static int __init wait_disable(char *s) __setup("nowait", wait_disable); -static inline void check_wait(void) +void __init check_wait(void) { struct cpuinfo_mips *c = ¤t_cpu_data; @@ -239,7 +228,6 @@ static inline void check_errata(void) void __init check_bugs32(void) { - check_wait(); check_errata(); } diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index e76a76b..96f46b3 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -20,6 +20,7 @@ #include #include #include +#include #define PANIC_PIC(msg) \ .set push; \ @@ -126,7 +127,42 @@ handle_vcei: __FINIT + .align 5 /* 32 byte rollback region */ +LEAF(r4k_wait) + .set push + .set noreorder + /* start of rollback region */ + LONG_L t0, TI_FLAGS($28) + nop + andi t0, _TIF_NEED_RESCHED + bnez t0, 1f + nop + nop + nop + .set mips3 + wait + /* end of rollback region (the region size must be power of two) */ + .set pop +1: + jr ra + END(r4k_wait) + + .macro BUILD_ROLLBACK_PROLOGUE handler + FEXPORT(rollback_\handler) + .set push + .set noat + MFC0 k0, CP0_EPC + PTR_LA k1, r4k_wait + ori k0, 0x1f /* 32 byte rollback region */ + xori k0, 0x1f + bne k0, k1, 9f + MTC0 k0, CP0_EPC +9: + .set pop + .endm + .align 5 +BUILD_ROLLBACK_PROLOGUE handle_int NESTED(handle_int, PT_SIZE, sp) #ifdef CONFIG_TRACE_IRQFLAGS /* @@ -201,6 +237,7 @@ NESTED(except_vec_ejtag_debug, 0, sp) * This prototype is copied to ebase + n*IntCtl.VS and patched * to invoke the handler */ +BUILD_ROLLBACK_PROLOGUE except_vec_vi NESTED(except_vec_vi, 0, sp) SAVE_SOME SAVE_AT diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 23e73d0..23807c6 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -43,6 +43,9 @@ #include #include +extern void check_wait(void); +extern asmlinkage void r4k_wait(void); +extern asmlinkage void rollback_handle_int(void); extern asmlinkage void handle_int(void); extern asmlinkage void handle_tlbm(void); extern asmlinkage void handle_tlbl(void); @@ -1146,6 +1149,9 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) extern char except_vec_vi, except_vec_vi_lui; extern char except_vec_vi_ori, except_vec_vi_end; + extern char rollback_except_vec_vi; + char *vec_start = (cpu_wait == r4k_wait) ? + &rollback_except_vec_vi : &except_vec_vi; #ifdef CONFIG_MIPS_MT_SMTC /* * We need to provide the SMTC vectored interrupt handler @@ -1153,11 +1159,11 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) * Status.IM bit to be masked before going there. */ extern char except_vec_vi_mori; - const int mori_offset = &except_vec_vi_mori - &except_vec_vi; + const int mori_offset = &except_vec_vi_mori - vec_start; #endif /* CONFIG_MIPS_MT_SMTC */ - const int handler_len = &except_vec_vi_end - &except_vec_vi; - const int lui_offset = &except_vec_vi_lui - &except_vec_vi; - const int ori_offset = &except_vec_vi_ori - &except_vec_vi; + const int handler_len = &except_vec_vi_end - vec_start; + const int lui_offset = &except_vec_vi_lui - vec_start; + const int ori_offset = &except_vec_vi_ori - vec_start; if (handler_len > VECTORSPACING) { /* @@ -1167,7 +1173,7 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs) panic("VECTORSPACING too small"); } - memcpy(b, &except_vec_vi, handler_len); + memcpy(b, vec_start, handler_len); #ifdef CONFIG_MIPS_MT_SMTC BUG_ON(n > 7); /* Vector index %d exceeds SMTC maximum. */ @@ -1437,6 +1443,10 @@ void __init trap_init(void) extern char except_vec3_generic, except_vec3_r4000; extern char except_vec4; unsigned long i; + int rollback; + + check_wait(); + rollback = (cpu_wait == r4k_wait); if (cpu_has_veic || cpu_has_vint) ebase = (unsigned long) alloc_bootmem_low_pages(0x200 + VECTORSPACING*64); @@ -1496,7 +1506,7 @@ void __init trap_init(void) if (board_be_init) board_be_init(); - set_except_vector(0, handle_int); + set_except_vector(0, rollback ? rollback_handle_int : handle_int); set_except_vector(1, handle_tlbm); set_except_vector(2, handle_tlbl); set_except_vector(3, handle_tlbs); From ralf@linux-mips.org Sun Nov 11 21:31:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Nov 2007 21:31:31 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:64226 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029982AbXKKVb3 (ORCPT ); Sun, 11 Nov 2007 21:31: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 lABLVS5C026844; Sun, 11 Nov 2007 21:31:28 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lABLVSZZ026843; Sun, 11 Nov 2007 21:31:28 GMT Date: Sun, 11 Nov 2007 21:31:28 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0 Message-ID: <20071111213127.GA26297@linux-mips.org> References: <20071111143302.GA26458@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071111143302.GA26458@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: 17467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Nov 11, 2007 at 03:33:02PM +0100, Thomas Bogendoerfer wrote: > I tried to get a working 64bit kernel for SNI RM. Most of things > to fix were quite obvious, but there is one thing, which I haven't > understood yet. > > The firmware is only able to boot ELF32 images, which mean I need to > use BOOT_ELF32. > > RM machines have 256MB memory mapped to KSEG0, anything else is outside. > To me that would mean I need to use the default spaces from > mach-generic/spaces.h. A kernel built that way will hang after calling > schedule() in rest_init() (init/main.c). Has anybody seen this > as well ? No. schedule() doesn't directly depend on very much else working so I get the feeling that your problem may be quite far away. > Before digging into schedule() I decided to try mach-ip22/spaces.h > and limit the installed memory to 256MB. This kernel boots and > runs fine. > > Then I booted that kernel with all memory (512MB) and it died, when > init had troubles mapping libc. That result didn't surprise me > that much, since the kernel probably tried to map memory > 256MB > via CKSEG0, which won't work. Correct ? You should keep all memory mapped in the same kernel segment. Since you have too much to do that in CKSEG0 it will have to be XKPHYS which means the generic spaces.h which will be used when you have none in in mach-rm200/space.h. I suspect what happens is the kernel is trying to access memory at above phys. 512MB. In your setup it would compute a CKSEG1 address for that and stomp over something it better shouldn't ... Ralf From tsbogend@alpha.franken.de Mon Nov 12 08:36:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 08:36:11 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:12523 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20021964AbXKLIgB (ORCPT ); Mon, 12 Nov 2007 08:36:01 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IrUix-0005AQ-00; Mon, 12 Nov 2007 09:32:51 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 996AEC2343; Mon, 12 Nov 2007 09:32:42 +0100 (CET) Date: Mon, 12 Nov 2007 09:32:42 +0100 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0 Message-ID: <20071112083242.GA6065@alpha.franken.de> References: <20071111143302.GA26458@alpha.franken.de> <20071111213127.GA26297@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071111213127.GA26297@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: 17468 X-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 Sun, Nov 11, 2007 at 09:31:28PM +0000, Ralf Baechle wrote: > On Sun, Nov 11, 2007 at 03:33:02PM +0100, Thomas Bogendoerfer wrote: > > > I tried to get a working 64bit kernel for SNI RM. Most of things > > to fix were quite obvious, but there is one thing, which I haven't > > understood yet. > > > > The firmware is only able to boot ELF32 images, which mean I need to > > use BOOT_ELF32. > > > > RM machines have 256MB memory mapped to KSEG0, anything else is outside. > > To me that would mean I need to use the default spaces from > > mach-generic/spaces.h. A kernel built that way will hang after calling > > schedule() in rest_init() (init/main.c). Has anybody seen this > > as well ? > > No. > > schedule() doesn't directly depend on very much else working so I get the > feeling that your problem may be quite far away. well it depends on getting a kernel thread started. And I guess there lies the problem. Maybe I need to ask more precisely what I want to know: Should a kernel linked to CSKEG0 with a CAC_BASE 0x980000000000 work or is this setup "wrong" ? If the answer is yes, I'd say there is still a bug left. If no how do we solve the issue of having a 32bit firmware and a kernel linked for XPHYS (using some sort of bootloader is not want I want to have, if it's avoidable) ? Thomas. -- 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 Mon Nov 12 10:45:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 10:45:18 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:13248 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20023284AbXKLKpP (ORCPT ); Mon, 12 Nov 2007 10:45:15 +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 lACAiYiC028338; Mon, 12 Nov 2007 10:44:49 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lACAiNc1028304; Mon, 12 Nov 2007 10:44:23 GMT Date: Mon, 12 Nov 2007 10:44:23 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0 Message-ID: <20071112104423.GA27588@linux-mips.org> References: <20071111143302.GA26458@alpha.franken.de> <20071111213127.GA26297@linux-mips.org> <20071112083242.GA6065@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071112083242.GA6065@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: 17469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 12, 2007 at 09:32:42AM +0100, Thomas Bogendoerfer wrote: > > schedule() doesn't directly depend on very much else working so I get the > > feeling that your problem may be quite far away. > > well it depends on getting a kernel thread started. And I guess there > lies the problem. > > Maybe I need to ask more precisely what I want to know: Should a > kernel linked to CSKEG0 with a CAC_BASE 0x980000000000 work or is > this setup "wrong" ? If the answer is yes, I'd say there is still > a bug left. If no how do we solve the issue of having a 32bit firmware > and a kernel linked for XPHYS (using some sort of bootloader is not > want I want to have, if it's avoidable) ? Typically systems try to put the kernel into CKSEG0 as long as the given platform happens to have memory mapped there. Using CKSEG0 allows using a shorter sequence to load the address of an in-kernel symbol resulting in a much smaller kernel binary. One implication of this is that kernel modules will have to be allocated to CKSEG2/3 because they're built using the same code model. Modules are allocated using vmalloc so the vmalloc space needs to be in CKSEG2/3. Most people don't care if that space is restricted to just one gig. But even if you get that wrong the expected failure mode is different ... Ralf From markus.gothe@27m.se Mon Nov 12 13:57:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 13:57:48 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:5271 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S28576873AbXKLN5j (ORCPT ); Mon, 12 Nov 2007 13:57:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 53019200A205; Mon, 12 Nov 2007 14:57:02 +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 12657-01-19; Mon, 12 Nov 2007 14:57:01 +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 C10DA200A2DB; Mon, 12 Nov 2007 14:56:58 +0100 (CET) Message-ID: <47385B75.2010700@27m.se> Date: Mon, 12 Nov 2007 14:56:05 +0100 From: Markus Gothe User-Agent: Icedove 1.5.0.14pre (X11/20071020) MIME-Version: 1.0 To: Martin Michlmayr , linux-mips@linux-mips.org Subject: Re: [SPAM] Re: Donation of an Indigo 2 R4K@250 References: <20071105141248.GQ6244@deprecation.cyrius.com> <20071111110752.GA21220@deprecation.cyrius.com> In-Reply-To: <20071111110752.GA21220@deprecation.cyrius.com> 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: 17470 X-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 Which graphics option? A 'hinv -v' would be appreciated. //Markus Martin Michlmayr wrote: > Anyone interested? > > * Martin Michlmayr [2007-11-05 15:12]: >> If anyone is interested in an Indigo 2 located in Cologne, >> Germany, please let me know. >> >>> I would like to donate the MIPS porters an SGI Indigo 2 >>> R4K@250Mhz. Fully working, keyboard/mouse/monitor included, but >>> no IRIX. >>> >>> The machine is located in Cologne/Germany - pickup preferred... >>> >> -- Martin Michlmayr http://www.cyrius.com/ >> >> >> -- To UNSUBSCRIBE, email to debian-mips-REQUEST@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmaster@lists.debian.org > - -- _______________________________________ 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 iD8DBQFHOFtz6I0XmJx2NrwRCEEdAJ9CTkdzTVA+hg+2SFEYn88730L92ACgmRyd SwTUpX6k+hwNFTyuqaNTc0U= =dy8N -----END PGP SIGNATURE----- From macro@linux-mips.org Mon Nov 12 17:31:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 17:31:42 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:44207 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28577229AbXKLRbe (ORCPT ); Mon, 12 Nov 2007 17:31:34 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id EB6F64008C; Mon, 12 Nov 2007 18:31:04 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id P823hnEXYEEr; Mon, 12 Nov 2007 18:30:59 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id A61E0400CE; Mon, 12 Nov 2007 18:30:59 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lACHV4a0009743; Mon, 12 Nov 2007 18:31:04 +0100 Date: Mon, 12 Nov 2007 17:30:52 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: [PATCH] arch/mips/Makefile: Fix canonical system names Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4755/Mon Nov 12 15:41:11 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips The GNU `config.guess' uses "linux-gnu" as the canonical system name. Fix the list of compiler prefixes checked to spell it correctly. Signed-off-by: Maciej W. Rozycki --- I am assuming the current names are a result of a typo and that the extra spaces used here are for readability, so I have not removed them. Please apply. Maciej patch-mips-2.6.23-20071023-mips-linux-gnu-0 diff -up --recursive --new-file linux-mips-2.6.23-20071023.macro/arch/mips/Makefile linux-mips-2.6.23-20071023/arch/mips/Makefile --- linux-mips-2.6.23-20071023.macro/arch/mips/Makefile 2007-10-23 04:57:23.000000000 +0000 +++ linux-mips-2.6.23-20071023/arch/mips/Makefile 2007-11-11 19:04:39.000000000 +0000 @@ -44,7 +44,7 @@ endif ifneq ($(SUBARCH),$(ARCH)) ifeq ($(CROSS_COMPILE),) - CROSS_COMPILE := $(call cc-cross-prefix, $(tool-archpref)-linux- $(tool-archpref)-gnu-linux- $(tool-archpref)-unknown-gnu-linux-) + CROSS_COMPILE := $(call cc-cross-prefix, $(tool-archpref)-linux- $(tool-archpref)-linux-gnu- $(tool-archpref)-unknown-linux-gnu-) endif endif From macro@linux-mips.org Mon Nov 12 17:33:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 17:33:39 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:30384 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S28577237AbXKLRda (ORCPT ); Mon, 12 Nov 2007 17:33:30 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 4748A4008C; Mon, 12 Nov 2007 18:33:01 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id JMXhbs0gAqei; Mon, 12 Nov 2007 18:32:56 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id F2871400CE; Mon, 12 Nov 2007 18:32:55 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lACHX15n010356; Mon, 12 Nov 2007 18:33:01 +0100 Date: Mon, 12 Nov 2007 17:32:48 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: [PATCH] sni/pcimt.c: s/achknowledge/acknowledge Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4755/Mon Nov 12 15:41:11 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips s/achknowledge/acknowledge Signed-off-by: Maciej W. Rozycki --- While at fixing typos... Please apply. Maciej patch-mips-2.6.23-20071023-sni-pcimt-typo-0 diff -up --recursive --new-file linux-mips-2.6.23-20071023.macro/arch/mips/sni/pcimt.c linux-mips-2.6.23-20071023/arch/mips/sni/pcimt.c --- linux-mips-2.6.23-20071023.macro/arch/mips/sni/pcimt.c 2007-10-23 04:57:23.000000000 +0000 +++ linux-mips-2.6.23-20071023/arch/mips/sni/pcimt.c 2007-11-11 23:20:26.000000000 +0000 @@ -244,7 +244,7 @@ static void pcimt_hwint1(void) if (pend & IT_EISA) { int irq; /* - * Note: ASIC PCI's builtin interrupt achknowledge feature is + * Note: ASIC PCI's builtin interrupt acknowledge feature is * broken. Using it may result in loss of some or all i8259 * interrupts, so don't use PCIMT_INT_ACKNOWLEDGE ... */ From ralf@linux-mips.org Mon Nov 12 18:21:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 18:21:53 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:20627 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025516AbXKLSVv (ORCPT ); Mon, 12 Nov 2007 18:21:51 +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 lACIL6Tp007026; Mon, 12 Nov 2007 18:21:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lACIL5Rx007025; Mon, 12 Nov 2007 18:21:05 GMT Date: Mon, 12 Nov 2007 18:21:05 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] arch/mips/Makefile: Fix canonical system names Message-ID: <20071112182105.GA7019@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.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: 17473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 12, 2007 at 05:30:52PM +0000, Maciej W. Rozycki wrote: > The GNU `config.guess' uses "linux-gnu" as the canonical system name. > Fix the list of compiler prefixes checked to spell it correctly. > > Signed-off-by: Maciej W. Rozycki Applied, thanks. Ralf From ralf@linux-mips.org Mon Nov 12 18:22:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 18:23:00 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:26516 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025532AbXKLSW5 (ORCPT ); Mon, 12 Nov 2007 18:22:57 +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 lACIMCaE007066; Mon, 12 Nov 2007 18:22:37 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lACIMCSm007065; Mon, 12 Nov 2007 18:22:12 GMT Date: Mon, 12 Nov 2007 18:22:12 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] sni/pcimt.c: s/achknowledge/acknowledge Message-ID: <20071112182212.GB7019@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.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: 17474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 12, 2007 at 05:32:48PM +0000, Maciej W. Rozycki wrote: Applied as well. Thanks, Ralf From tsbogend@alpha.franken.de Mon Nov 12 22:31:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Nov 2007 22:31:28 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:30399 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28578773AbXKLWbU (ORCPT ); Mon, 12 Nov 2007 22:31:20 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IrhoN-0006yJ-00; Mon, 12 Nov 2007 23:31:19 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 578BAC2AD8; Mon, 12 Nov 2007 23:31:04 +0100 (CET) Date: Mon, 12 Nov 2007 23:31:04 +0100 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0 Message-ID: <20071112223104.GA7900@alpha.franken.de> References: <20071111143302.GA26458@alpha.franken.de> <20071111213127.GA26297@linux-mips.org> <20071112083242.GA6065@alpha.franken.de> <20071112104423.GA27588@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071112104423.GA27588@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: 17475 X-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 Mon, Nov 12, 2007 at 10:44:23AM +0000, Ralf Baechle wrote: > But even if you get that wrong the expected failure mode is different ... Ralf and me had an debug session on IRC and I finally figured out what caused the problem: CONFIG_EARLY_PRINTK via prom calls. I simply used call_o32.S from the decstation part and missed the fact, that it simply uses the normal kernel stack when calling firmware. This works quite good until the first kernel thread gets scheduled, which has a kernel stack via a CAC_BASE address. So after switching stack the next call to prom_putchar() killed the machine. Simply disabling EARLY_PRINTK gives me a working 64bit kernel, which sees the whole 512MB RAM :-) Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From ddaney@avtrex.com Tue Nov 13 07:53:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 07:53:39 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:57061 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20022719AbXKMHxb (ORCPT ); Tue, 13 Nov 2007 07:53:31 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 4468F310125; Tue, 13 Nov 2007 07:52:53 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Tue, 13 Nov 2007 07:52:53 +0000 (UTC) Received: from jennifer.localdomain ([192.168.7.228]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 23:52:47 -0800 Message-ID: <473957B6.3030202@avtrex.com> Date: Mon, 12 Nov 2007 23:52:22 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: linux-mips@linux-mips.org Cc: Richard Sandiford , gcc@gcc.gnu.org Subject: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 07:52:47.0443 (UTC) FILETIME=[2E894A30:01C825CA] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips With the current kernel (2.6.23.1) in my R5000 based O2 it seems impossible for GCC's exception unwinding machinery to unwind through signal frames. The cause of the problems is the ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost impossible to determine offset from the signal return trampoline. The unwinder depends on being able to find the sigcontext given a known location of the trampoline. It seems there are a couple of possible solutions: 1) The comments in war.h indicate the problem only exists in R7000 and E9000 processors. We could turn off the workaround if the kernel is configured for R5000. That would help me, but not those with the effected systems. 2) In the non-workaround case, the siginfo immediately follows the trampoline and the first member is the signal number. For the workaround case the first word following the trampoline is zero. We could replace this with the offset to the sigcontext which is always a small negative value. The unwinder could then distinguish the two cases (signal numbers are positive and the offset negative). If we did this, the change would have to be coordinated with GCC's unwinder (in libgcc_s.so.1). Thoughts? David Daney From tbm@cyrius.com Tue Nov 13 08:21:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 08:21:32 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:46852 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20024171AbXKMIVY (ORCPT ); Tue, 13 Nov 2007 08:21:24 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 6C2F1D8DD; Tue, 13 Nov 2007 08:21:17 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 1663D74171; Tue, 13 Nov 2007 09:21:03 +0100 (CET) Date: Tue, 13 Nov 2007 09:21:03 +0100 From: Martin Michlmayr To: Markus Gothe Cc: linux-mips@linux-mips.org Subject: Re: [SPAM] Re: Donation of an Indigo 2 R4K@250 Message-ID: <20071113082102.GG23088@deprecation.cyrius.com> References: <20071105141248.GQ6244@deprecation.cyrius.com> <20071111110752.GA21220@deprecation.cyrius.com> <47385B75.2010700@27m.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47385B75.2010700@27m.se> 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: 17477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Markus Gothe [2007-11-12 14:56]: > Which graphics option? A 'hinv -v' would be appreciated. I've asked the donor. -- Martin Michlmayr http://www.cyrius.com/ From aph@littlepinkcloud.COM Tue Nov 13 11:49:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 11:49:36 +0000 (GMT) Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48]:28796 "EHLO mtaout02-winn.ispmail.ntl.com") by ftp.linux-mips.org with ESMTP id S20026039AbXKMLt1 (ORCPT ); Tue, 13 Nov 2007 11:49:27 +0000 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20071113114904.NWUS25022.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Tue, 13 Nov 2007 11:49:04 +0000 Received: from zebedee.littlepinkcloud.COM ([82.6.106.47]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20071113114904.BWRN29112.aamtaout04-winn.ispmail.ntl.com@zebedee.littlepinkcloud.COM>; Tue, 13 Nov 2007 11:49:04 +0000 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.8/8.13.5) with ESMTP id lADBmtbf001051; Tue, 13 Nov 2007 11:48:55 GMT Received: (from aph@localhost) by littlepinkcloud.COM (8.13.8/8.13.5/Submit) id lADBmrBn001047; Tue, 13 Nov 2007 11:48:53 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18233.36645.232058.964652@zebedee.pink> Date: Tue, 13 Nov 2007 11:48:53 +0000 From: Andrew Haley To: David Daney Cc: linux-mips@linux-mips.org, Richard Sandiford , gcc@gcc.gnu.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR In-Reply-To: <473957B6.3030202@avtrex.com> References: <473957B6.3030202@avtrex.com> X-Mailer: VM 7.19 under Emacs 22.0.93.1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aph-gcc@littlepinkcloud.COM Precedence: bulk X-list: linux-mips David Daney writes: > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > impossible for GCC's exception unwinding machinery to unwind through > signal frames. The cause of the problems is the > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > impossible to determine offset from the signal return trampoline. The > unwinder depends on being able to find the sigcontext given a known > location of the trampoline. > > It seems there are a couple of possible solutions: > > 1) The comments in war.h indicate the problem only exists in R7000 > and E9000 processors. We could turn off the workaround if the > kernel is configured for R5000. That would help me, but not those > with the effected systems. > > 2) In the non-workaround case, the siginfo immediately follows the > trampoline and the first member is the signal number. For the > workaround case the first word following the trampoline is zero. > We could replace this with the offset to the sigcontext which is > always a small negative value. The unwinder could then distinguish > the two cases (signal numbers are positive and the offset > negative). If we did this, the change would have to be coordinated > with GCC's unwinder (in libgcc_s.so.1). > > Thoughts? The best solution is to put the unwinder info in the kernel. Does MIPS use a vDSO ? Andrew. From macro@linux-mips.org Tue Nov 13 12:10:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 12:11:06 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:59033 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20026085AbXKMMK6 (ORCPT ); Tue, 13 Nov 2007 12:10:58 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 160574016E; Tue, 13 Nov 2007 13:10:58 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id Nv4NKY7sgdrB; Tue, 13 Nov 2007 13:10:48 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id B6CFD4008C; Tue, 13 Nov 2007 13:10:48 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lADCApmq018676; Tue, 13 Nov 2007 13:10:51 +0100 Date: Tue, 13 Nov 2007 12:10:44 +0000 (GMT) From: "Maciej W. Rozycki" To: Thomas Bogendoerfer cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0 In-Reply-To: <20071112223104.GA7900@alpha.franken.de> Message-ID: References: <20071111143302.GA26458@alpha.franken.de> <20071111213127.GA26297@linux-mips.org> <20071112083242.GA6065@alpha.franken.de> <20071112104423.GA27588@linux-mips.org> <20071112223104.GA7900@alpha.franken.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4762/Tue Nov 13 11:42:30 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 12 Nov 2007, Thomas Bogendoerfer wrote: > I simply used call_o32.S from the decstation part and missed the > fact, that it simply uses the normal kernel stack when calling > firmware. This works quite good until the first kernel thread > gets scheduled, which has a kernel stack via a CAC_BASE address. You could do stack switching in call_o32() -- I just figured there was no point in adding this complication as the DECstation always runs from KSEG0 -- it has the maximum of 480MB of RAM mapped linearly starting from 0. Maciej From ralf@linux-mips.org Tue Nov 13 12:12:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 12:13:01 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:21183 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026066AbXKMMM7 (ORCPT ); Tue, 13 Nov 2007 12:12:59 +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 lADCAgJP006695; Tue, 13 Nov 2007 12:11:02 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lADCAaSj006694; Tue, 13 Nov 2007 12:10:36 GMT Date: Tue, 13 Nov 2007 12:10:36 +0000 From: Ralf Baechle To: Andrew Haley Cc: David Daney , linux-mips@linux-mips.org, Richard Sandiford , gcc@gcc.gnu.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Message-ID: <20071113121036.GA6582@linux-mips.org> References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18233.36645.232058.964652@zebedee.pink> 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: 17480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 13, 2007 at 11:48:53AM +0000, Andrew Haley wrote: > David Daney writes: > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > > impossible for GCC's exception unwinding machinery to unwind through > > signal frames. The cause of the problems is the > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > > impossible to determine offset from the signal return trampoline. The > > unwinder depends on being able to find the sigcontext given a known > > location of the trampoline. > > > > It seems there are a couple of possible solutions: > > > > 1) The comments in war.h indicate the problem only exists in R7000 > > and E9000 processors. We could turn off the workaround if the > > kernel is configured for R5000. That would help me, but not those > > with the effected systems. > > > > 2) In the non-workaround case, the siginfo immediately follows the > > trampoline and the first member is the signal number. For the > > workaround case the first word following the trampoline is zero. > > We could replace this with the offset to the sigcontext which is > > always a small negative value. The unwinder could then distinguish > > the two cases (signal numbers are positive and the offset > > negative). If we did this, the change would have to be coordinated > > with GCC's unwinder (in libgcc_s.so.1). > > > > Thoughts? > > The best solution is to put the unwinder info in the kernel. Does > MIPS use a vDSO ? No though we should. Another reason is to get rid of the classic trampoline the kernel installs on the stack. On some multiprocessor systems it requires a cacheflush operation to be performed on all processors which is expensive. Having the trampoline in a vDSO would solve that. I need to look into it, not sure what it would take. Ralf From vagabon.xyz@gmail.com Tue Nov 13 13:15:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 13:15:17 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.191]:52763 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026334AbXKMNPJ (ORCPT ); Tue, 13 Nov 2007 13:15:09 +0000 Received: by nf-out-0910.google.com with SMTP id c10so1252751nfd for ; Tue, 13 Nov 2007 05:14:59 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+w9AdHSBgJKRKkkkvy4WN5gQgLxb3qeEz5CVK3LlbF8=; b=ZOe6FKJK82IuiVDQzIb2PCpNlWZMSd8tpvp4aomfEferm08fRnq9drt5Gu2s1oPhJf/rus46ghiKBUjPvaryIUV/BUY30+n0xA9MtuZj9bz8h4GwSrUtX0n4yo4o1l8cvMBmYrrNfknzLuqOU72SC/yTDugwlASyjnzkLKd9yGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Dm7FUA6NFZ3FrAXNnwxvIsaJooT5u9SYyXVF3CLB6fBfvamTxZFxHzPB/+EtM0cEFC+w7g2h5ThOJDaomJnglAdIdt15DacsjUGx6fDFoV87f1nOIiCIwj14rC4IAxh1USBymXjB6Q9u03nmyTlEC2T7Rtb+lWxW8Lqs3lzvapM= Received: by 10.78.37.7 with SMTP id k7mr6619008huk.1194959698997; Tue, 13 Nov 2007 05:14:58 -0800 (PST) Received: by 10.78.179.18 with HTTP; Tue, 13 Nov 2007 05:14:58 -0800 (PST) Message-ID: Date: Tue, 13 Nov 2007 14:14:58 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Cc: "Andrew Haley" , "David Daney" , linux-mips@linux-mips.org, "Richard Sandiford" , gcc@gcc.gnu.org In-Reply-To: <20071113121036.GA6582@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On Nov 13, 2007 1:10 PM, Ralf Baechle wrote: > > On Tue, Nov 13, 2007 at 11:48:53AM +0000, Andrew Haley wrote: > > > David Daney writes: > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > > > impossible for GCC's exception unwinding machinery to unwind through > > > signal frames. The cause of the problems is the > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > > > impossible to determine offset from the signal return trampoline. The > > > unwinder depends on being able to find the sigcontext given a known > > > location of the trampoline. > > > > > > It seems there are a couple of possible solutions: > > > > > > 1) The comments in war.h indicate the problem only exists in R7000 > > > and E9000 processors. We could turn off the workaround if the > > > kernel is configured for R5000. That would help me, but not those > > > with the effected systems. > > > > > > 2) In the non-workaround case, the siginfo immediately follows the > > > trampoline and the first member is the signal number. For the > > > workaround case the first word following the trampoline is zero. > > > We could replace this with the offset to the sigcontext which is > > > always a small negative value. The unwinder could then distinguish > > > the two cases (signal numbers are positive and the offset > > > negative). If we did this, the change would have to be coordinated > > > with GCC's unwinder (in libgcc_s.so.1). > > > > > > Thoughts? > > > > The best solution is to put the unwinder info in the kernel. Does > > MIPS use a vDSO ? > > No though we should. > > Another reason is to get rid of the classic trampoline the kernel installs > on the stack. On some multiprocessor systems it requires a cacheflush > operation to be performed on all processors which is expensive. Having > the trampoline in a vDSO would solve that. > And the stack wouldn't need to have exec permission anymore. > I need to look into it, not sure what it would take. > I started to add vdso support for MIPS a couple months ago, but it's in a very early stage and I unfortunately haven't time to finish it. I can send it to you if you want. -- Franck From ralf@linux-mips.org Tue Nov 13 14:03:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 14:03:44 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:64134 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026526AbXKMODm (ORCPT ); Tue, 13 Nov 2007 14:03:42 +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 lADE0bJQ007714; Tue, 13 Nov 2007 14:00:57 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lADE0aD7007713; Tue, 13 Nov 2007 14:00:36 GMT Date: Tue, 13 Nov 2007 14:00:36 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Andrew Haley , David Daney , linux-mips@linux-mips.org, Richard Sandiford , gcc@gcc.gnu.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Message-ID: <20071113140036.GA7650@linux-mips.org> References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 17482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote: > > > David Daney writes: > > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > > > > impossible for GCC's exception unwinding machinery to unwind through > > > > signal frames. The cause of the problems is the > > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > > > > impossible to determine offset from the signal return trampoline. The > > > > unwinder depends on being able to find the sigcontext given a known > > > > location of the trampoline. > > > > > > > > It seems there are a couple of possible solutions: > > > > > > > > 1) The comments in war.h indicate the problem only exists in R7000 > > > > and E9000 processors. We could turn off the workaround if the > > > > kernel is configured for R5000. That would help me, but not those > > > > with the effected systems. > > > > > > > > 2) In the non-workaround case, the siginfo immediately follows the > > > > trampoline and the first member is the signal number. For the > > > > workaround case the first word following the trampoline is zero. > > > > We could replace this with the offset to the sigcontext which is > > > > always a small negative value. The unwinder could then distinguish > > > > the two cases (signal numbers are positive and the offset > > > > negative). If we did this, the change would have to be coordinated > > > > with GCC's unwinder (in libgcc_s.so.1). > > > > > > > > Thoughts? > > > > > > The best solution is to put the unwinder info in the kernel. Does > > > MIPS use a vDSO ? > > > > No though we should. > > > > Another reason is to get rid of the classic trampoline the kernel installs > > on the stack. On some multiprocessor systems it requires a cacheflush > > operation to be performed on all processors which is expensive. Having > > the trampoline in a vDSO would solve that. > > > > And the stack wouldn't need to have exec permission anymore. Oh? extern void frob(void (*)(void)); int foo(void) { int x; void bar(void) { x++; } frob(&bar); print("x is %d\n", x); } Compile and enjoy. Ralf From vagabon.xyz@gmail.com Tue Nov 13 14:22:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 14:22:44 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.181]:17114 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20026595AbXKMOWg (ORCPT ); Tue, 13 Nov 2007 14:22:36 +0000 Received: by wa-out-1112.google.com with SMTP id m16so1928597waf for ; Tue, 13 Nov 2007 06:22:33 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sQ3GpZ4vug4Vtccj2keecegQirki9C/rqb9NIXF6mnM=; b=SYHq9hmi/2eXj3ZwMlrNYmvkEJaNicm2tOIm3qCUavmRyyzo0o2O3eKfyCphVD0E2EwxMzvWmj2DWpH86q35C4JAaBL1TSdLt9Bi/HfBad0zY1PWnvmeAse3Q8bH4jIqObNLs+JeKxaJv3SNOlPkDc+Ow8xAtcbTmNNapajWSr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S+rX8YT2U0gUVzKoCqvrO8mOWZjyIbxY1I7+3Qu5nm18p88LPVmHldztYKPD2nySTLuTLjyo3TtxcX+qJurXCAhyzlBHkJ+Inv7lf82oY97gi3Y42DOiSGkbU97nP6aIbel4hANdmgCgZxMQ/uTvEoo1pCSe/E+8HltSLo/uM5s= Received: by 10.114.79.1 with SMTP id c1mr164621wab.1194963753816; Tue, 13 Nov 2007 06:22:33 -0800 (PST) Received: by 10.35.80.12 with HTTP; Tue, 13 Nov 2007 06:22:33 -0800 (PST) Message-ID: Date: Tue, 13 Nov 2007 15:22:33 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Cc: "Andrew Haley" , "David Daney" , linux-mips@linux-mips.org, "Richard Sandiford" , gcc@gcc.gnu.org In-Reply-To: <20071113140036.GA7650@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <20071113140036.GA7650@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On Nov 13, 2007 3:00 PM, Ralf Baechle wrote: > > On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote: > > > > > David Daney writes: > > > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > > > > > impossible for GCC's exception unwinding machinery to unwind through > > > > > signal frames. The cause of the problems is the > > > > > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > > > > > impossible to determine offset from the signal return trampoline. The > > > > > unwinder depends on being able to find the sigcontext given a known > > > > > location of the trampoline. > > > > > > > > > > It seems there are a couple of possible solutions: > > > > > > > > > > 1) The comments in war.h indicate the problem only exists in R7000 > > > > > and E9000 processors. We could turn off the workaround if the > > > > > kernel is configured for R5000. That would help me, but not those > > > > > with the effected systems. > > > > > > > > > > 2) In the non-workaround case, the siginfo immediately follows the > > > > > trampoline and the first member is the signal number. For the > > > > > workaround case the first word following the trampoline is zero. > > > > > We could replace this with the offset to the sigcontext which is > > > > > always a small negative value. The unwinder could then distinguish > > > > > the two cases (signal numbers are positive and the offset > > > > > negative). If we did this, the change would have to be coordinated > > > > > with GCC's unwinder (in libgcc_s.so.1). > > > > > > > > > > Thoughts? > > > > > > > > The best solution is to put the unwinder info in the kernel. Does > > > > MIPS use a vDSO ? > > > > > > No though we should. > > > > > > Another reason is to get rid of the classic trampoline the kernel installs > > > on the stack. On some multiprocessor systems it requires a cacheflush > > > operation to be performed on all processors which is expensive. Having > > > the trampoline in a vDSO would solve that. > > > > > > > And the stack wouldn't need to have exec permission anymore. > > Oh? > > extern void frob(void (*)(void)); > > int foo(void) > { > int x; > > void bar(void) > { > x++; > } > > frob(&bar); > print("x is %d\n", x); > } > > Compile and enjoy. > Sorry Ralf, I missed your point. -- Franck From kevink@mips.com Tue Nov 13 14:46:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 14:47:07 +0000 (GMT) Received: from dns0.mips.com ([63.167.95.198]:62648 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20026641AbXKMOq5 (ORCPT ); Tue, 13 Nov 2007 14:46:57 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id lADEciPK026008; Tue, 13 Nov 2007 06:38:44 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id lADEd9kP006753; Tue, 13 Nov 2007 06:39:10 -0800 (PST) Message-ID: <019e01c82602$f5463bf0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Franck Bui-Huu" , "Ralf Baechle" Cc: "Andrew Haley" , "David Daney" , , "Richard Sandiford" , References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Date: Tue, 13 Nov 2007 15:37:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips Franck a dit: > > Another reason is to get rid of the classic trampoline the kernel installs > > on the stack. On some multiprocessor systems it requires a cacheflush > > operation to be performed on all processors which is expensive. Having > > the trampoline in a vDSO would solve that. > > > > And the stack wouldn't need to have exec permission anymore. True, though it should perhaps be noted that currently it's only on 4KSc/Sd systems (which I know you work on) where it's even possible for the stack *not* to have exec permissions, since the classical MIPS MMU gives execute permission to any page that is readable. Regards, Kevin K. From vagabon.xyz@gmail.com Tue Nov 13 14:49:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 14:49:31 +0000 (GMT) Received: from rv-out-0910.google.com ([209.85.198.191]:1428 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026665AbXKMOtX (ORCPT ); Tue, 13 Nov 2007 14:49:23 +0000 Received: by rv-out-0910.google.com with SMTP id l15so1205225rvb for ; Tue, 13 Nov 2007 06:49:17 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yf4RU0KmsKQvklRVXHk4ecXqABOIXjXK9TqO0vcmzwk=; b=tjIe/iLwc+BCiUM40lr6eDOfv9Ug3axzAeJMWCJGMlsexGtxNJvrBtcKGfAzIZc/KZ3N6n1qlUqYnV8eazvC8Om7yGX8xzTDN0awJqjBQU4QySU6N0zYnLEF3PcF+R2+Ib6S8Wod/yjSBQD+lZtsaz5VU4rTvYCQf6SDOsDcdG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fe855liofhW+SW5dhlSq+zSLEr+v8sdcsamlBdAcvMLTEnGtJdcHMVeohhhLuSKXUtw6RHNtMeH2JEL2te+bMTnsl7nGQKi7WPP2cv8p+JzeTgUmJGmKzja+PG9gl9qmt9+MaLRpuUdtlkAMwBW/d1FQlxLZEc/TaYbIxCRxr/E= Received: by 10.140.186.20 with SMTP id j20mr2850281rvf.1194965357094; Tue, 13 Nov 2007 06:49:17 -0800 (PST) Received: by 10.35.80.12 with HTTP; Tue, 13 Nov 2007 06:49:16 -0800 (PST) Message-ID: Date: Tue, 13 Nov 2007 15:49:16 +0100 From: "Franck Bui-Huu" To: "Kevin D. Kissell" Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Cc: "Ralf Baechle" , "Andrew Haley" , "David Daney" , linux-mips@linux-mips.org, "Richard Sandiford" , gcc@gcc.gnu.org In-Reply-To: <019e01c82602$f5463bf0$10eca8c0@grendel> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <019e01c82602$f5463bf0$10eca8c0@grendel> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On Nov 13, 2007 3:37 PM, Kevin D. Kissell wrote: > Franck a dit: > > > Another reason is to get rid of the classic trampoline the kernel installs > > > on the stack. On some multiprocessor systems it requires a cacheflush > > > operation to be performed on all processors which is expensive. Having > > > the trampoline in a vDSO would solve that. > > > > > > > And the stack wouldn't need to have exec permission anymore. > > True, though it should perhaps be noted that currently it's only on 4KSc/Sd > systems (which I know you work on) where it's even possible for the stack > *not* to have exec permissions, since the classical MIPS MMU gives > execute permission to any page that is readable. > Well, the noexec stack is pretty usefull I think. I can't believe it will be limited to these 2 systems in the near future... -- Franck From ralf@linux-mips.org Tue Nov 13 15:04:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 15:04:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:20933 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026717AbXKMPEp (ORCPT ); Tue, 13 Nov 2007 15:04:45 +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 lADF1mZV008513; Tue, 13 Nov 2007 15:02:08 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lADF1kZ2008512; Tue, 13 Nov 2007 15:01:46 GMT Date: Tue, 13 Nov 2007 15:01:46 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Andrew Haley , David Daney , linux-mips@linux-mips.org, Richard Sandiford , gcc@gcc.gnu.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Message-ID: <20071113150146.GC7650@linux-mips.org> References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <20071113140036.GA7650@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 17486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 13, 2007 at 03:22:33PM +0100, Franck Bui-Huu wrote: > > > And the stack wouldn't need to have exec permission anymore. > > > > Oh? > > > > extern void frob(void (*)(void)); > > > > int foo(void) > > { > > int x; > > > > void bar(void) > > { > > x++; > > } > > > > frob(&bar); > > print("x is %d\n", x); > > } > > > > Compile and enjoy. > > > > Sorry Ralf, I missed your point. This piece of code compiles to something that copies a trampoline to the stack. The address of that trampoline is what is then passed as argument to frob(). Old versions of glibc were probable the most notorious users of trampolines. Objective C also generates them. Since a cacheflush that is a syscall is required performance is less than great. Which means the libc() cacheflush() function is another candidate for a vDSO, it can be optimized by using SYNCI on some configurations. Ralf From ralf@linux-mips.org Tue Nov 13 15:11:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 15:11:39 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:28547 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026755AbXKMPLh (ORCPT ); Tue, 13 Nov 2007 15:11:37 +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 lADF8SMB008582; Tue, 13 Nov 2007 15:08:49 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lADF8KxJ008577; Tue, 13 Nov 2007 15:08:20 GMT Date: Tue, 13 Nov 2007 15:08:20 +0000 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Franck Bui-Huu , Andrew Haley , David Daney , linux-mips@linux-mips.org, Richard Sandiford , gcc@gcc.gnu.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Message-ID: <20071113150820.GB6582@linux-mips.org> References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <019e01c82602$f5463bf0$10eca8c0@grendel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019e01c82602$f5463bf0$10eca8c0@grendel> 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: 17487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 13, 2007 at 03:37:39PM +0100, Kevin D. Kissell wrote: > True, though it should perhaps be noted that currently it's only on 4KSc/Sd > systems (which I know you work on) where it's even possible for the stack > *not* to have exec permissions, since the classical MIPS MMU gives > execute permission to any page that is readable. Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take care of I-cache coherency. So it's somewhat beneficial even in absence of a protection bit in the actual TLB hardware. Some of these performance optimizations are impossible because the kernel can't have definate knowledge that certain addresses have never entered the I-cache. Ralf From ddaney@avtrex.com Tue Nov 13 16:13:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 16:13:08 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:30383 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20026824AbXKMQNA (ORCPT ); Tue, 13 Nov 2007 16:13:00 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 46E2C30FEC8; Tue, 13 Nov 2007 16:12:57 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Tue, 13 Nov 2007 16:12:55 +0000 (UTC) Received: from jennifer.localdomain ([192.168.7.229]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 08:12:35 -0800 Message-ID: <4739CCD6.2080306@avtrex.com> Date: Tue, 13 Nov 2007 08:12:06 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: linux-mips@linux-mips.org Cc: Richard Sandiford , gcc@gcc.gnu.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR References: <473957B6.3030202@avtrex.com> In-Reply-To: <473957B6.3030202@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 16:12:35.0671 (UTC) FILETIME=[00E9BE70:01C82610] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips David Daney wrote: > With the current kernel (2.6.23.1) in my R5000 based O2 it seems > impossible for GCC's exception unwinding machinery to unwind through > signal frames. The cause of the problems is the > ICACHE_REFILLS_WORKAROUND_WAR which puts the sigcontext at an almost > impossible to determine offset from the signal return trampoline. The > unwinder depends on being able to find the sigcontext given a known > location of the trampoline. > > It seems there are a couple of possible solutions: > > 1) The comments in war.h indicate the problem only exists in R7000 and > E9000 processors. We could turn off the workaround if the kernel is > configured for R5000. That would help me, but not those with the > effected systems. > > 2) In the non-workaround case, the siginfo immediately follows the > trampoline and the first member is the signal number. For the > workaround case the first word following the trampoline is zero. We > could replace this with the offset to the sigcontext which is always a > small negative value. The unwinder could then distinguish the two > cases (signal numbers are positive and the offset negative). If we > did this, the change would have to be coordinated with GCC's unwinder > (in libgcc_s.so.1). > I think I have found a solution that doesn't require kernel changes. The CFA (i.e. the stack pointer of the signal handler) of the the context when calling mips_fallback_frame_state is at a constant offset from the sigcontext. I can just use the CFA instead of the trampoline's address. Does this seem plausible? Thanks, David Daney From vagabon.xyz@gmail.com Tue Nov 13 21:29:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 21:29:22 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.185]:5415 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20027420AbXKMV3N (ORCPT ); Tue, 13 Nov 2007 21:29:13 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1882956fka for ; Tue, 13 Nov 2007 13:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=VdfsikXDURqE+3XnCbSX0kv36hT6tShkRfyW6Lide0A=; b=afk5RPuAMgBdlRUfVyg8dirKf/VQhbUizEhSKSaaJeygsvsbtPSszs6m4MphfwfnHd706BX0zANb3KkRIyv/N1ksvMLB/hoBPpPwhzQOCPaTCCZvrEKeCiYEaHiQAtGRZhXJCSN/LTLpkSlzcLUi5qoruaw92SWRhfutWjqmLTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=sRXJ7DlQ6fPL7W63dqLr+HBq73roYuIgFn8+5Ym9Om590hkrfVtZVszo0iAvm13yb8GnYsm4NBDFD5MNzZq69YrdJk0Ps1FS+jbqDf+OeEZYB54/qJMMXW8uU932llxtIYOHKgdzrgJwGMd0+jb5fE0iaqW14r/fgzXaoPxRxdk= Received: by 10.86.49.13 with SMTP id w13mr6159264fgw.1194989342702; Tue, 13 Nov 2007 13:29:02 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j9sm13880896mue.2007.11.13.13.29.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Nov 2007 13:29:02 -0800 (PST) Message-ID: <473A169B.1040501@gmail.com> Date: Tue, 13 Nov 2007 22:26:51 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: VDSO on mips (was Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR) References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > > I started to add vdso support for MIPS a couple months ago, but > it's in a very early stage and I unfortunately haven't time to finish > it. I can send it to you if you want. > Here it is. As I said it far from complete but it might help. Franck --- 8< --- diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile index 2fd96d9..01d700c 100644 --- a/arch/mips/kernel/Makefile +++ b/arch/mips/kernel/Makefile @@ -6,11 +6,13 @@ extra-y := head.o init_task.o vmlinux.lds obj-y += cpu-probe.o branch.o entry.o genex.o irq.o process.o \ ptrace.o reset.o semaphore.o setup.o signal.o syscall.o \ - time.o topology.o traps.o unaligned.o + time.o topology.o traps.o unaligned.o vdso.o binfmt_irix-objs := irixelf.o irixinv.o irixioctl.o irixsig.o \ irix5sys.o sysirix.o +obj-$(CONFIG_32BIT) += vdso32/ + obj-$(CONFIG_STACKTRACE) += stacktrace.o obj-$(CONFIG_MODULES) += mips_ksyms.o module.o diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c new file mode 100644 index 0000000..281b7ce --- /dev/null +++ b/arch/mips/kernel/vdso.c @@ -0,0 +1,52 @@ +#include + +typedef struct { + unsigned long id; + unsigned long vdso_base; +} mm_context_t; + + +static int vdso_enabled __read_mostly = 1; + +static int __init vdso_setup(char *s) +{ + vdso_enabled = simple_strtol(s, NULL, 0); + return 1; +} +__setup("vdso=", vdso_setup); + + +int arch_setup_additional_pages(struct linux_binprm *bprm, int exec_stack) +{ + struct mm_struct *mm = current->mm; + unsigned long vdso_pages; + unsigned long vdso_base; + int rv; + + if (!vdso_enabled) + return 0; + + down_write(&mm->mmap_sem); + + rv = get_unmapped_area(NULL, vdso_base, vdso_pages << PAGE_SHIFT, 0, 0); + if (IS_ERR_VALUE(rv)) + goto out; + vdso_base = rv; + + rv = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT, + VM_READ|VM_EXEC| + VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC| + VM_ALWAYSDUMP, + vdso_pagelist); + if (rv) + goto out; +out: + up_write(&mm->mmap_sem); + return rv; +} + +static int __init vdso_init(void) +{ + return 0; +} +arch_initcall(vdso_init); diff --git a/arch/mips/kernel/vdso32/.gitignore b/arch/mips/kernel/vdso32/.gitignore new file mode 100644 index 0000000..e45fba9 --- /dev/null +++ b/arch/mips/kernel/vdso32/.gitignore @@ -0,0 +1 @@ +vdso32.lds diff --git a/arch/mips/kernel/vdso32/Makefile b/arch/mips/kernel/vdso32/Makefile new file mode 100644 index 0000000..b1ea645 --- /dev/null +++ b/arch/mips/kernel/vdso32/Makefile @@ -0,0 +1,35 @@ +# List of files in the vdso +obj-vdso32 = sigtramp.o + +# Build rules +targets := $(obj-vdso32) vdso32.so +obj-vdso32 := $(addprefix $(obj)/, $(obj-vdso32)) + + +EXTRA_CFLAGS := -shared -s -fno-common -fno-builtin +EXTRA_CFLAGS += -nostdlib -Wl,-soname=linux-vdso32.so.1 +EXTRA_CFLAGS += $(call ld-option, -Wl$(comma)--hash-style=sysv) + +EXTRA_AFLAGS := -D__VDSO32__ -s + +obj-y += vdso32.o +extra-y += vdso32.lds +CPPFLAGS_vdso32.lds += -P -C -U$(ARCH) + +# kbuild does not track this dependency due to usage of .incbin +$(obj)/vdso32.o : $(obj)/vdso32.so + +# link rule for the .so file, .lds has to be first +$(obj)/vdso32.so: $(src)/vdso32.lds $(obj-vdso32) + $(call if_changed,vdso32ld) + +# assembly rules for the .S files +$(obj-vdso32): %.o: %.S + $(call if_changed_dep,vdso32as) + +# actual build commands +quiet_cmd_vdso32ld = VDSO32_LD $@ + cmd_vdso32ld = $(CC) $(c_flags) -Wl,-T $^ -o $@ +quiet_cmd_vdso32as = VDSO32_AS $@ + cmd_vdso32as = $(CC) $(a_flags) -c -o $@ $< + diff --git a/arch/mips/kernel/vdso32/sigtramp.S b/arch/mips/kernel/vdso32/sigtramp.S new file mode 100644 index 0000000..4f83203 --- /dev/null +++ b/arch/mips/kernel/vdso32/sigtramp.S @@ -0,0 +1,13 @@ +#include +#include +#include + +LEAF(__kernel_sigtramp_32) + li v0, __NR_sigreturn + syscall +END(__kernel_sigtramp_32) + +LEAF(__kernel_sigtramp_rt32) + li v0, __NR_rt_sigreturn + syscall +END(__kernel_sigtramp_rt32) diff --git a/arch/mips/kernel/vdso32/vdso32.S b/arch/mips/kernel/vdso32/vdso32.S new file mode 100644 index 0000000..9548930 --- /dev/null +++ b/arch/mips/kernel/vdso32/vdso32.S @@ -0,0 +1,11 @@ +#include + +__INITDATA + + .globl vdso32_start + .globl vdso32_end +vdso32_start: + .incbin "arch/mips/kernel/vdso32/vdso32.so" +vdso32_end: + +__FINIT diff --git a/arch/mips/kernel/vdso32/vdso32.lds.S b/arch/mips/kernel/vdso32/vdso32.lds.S new file mode 100644 index 0000000..250a03d --- /dev/null +++ b/arch/mips/kernel/vdso32/vdso32.lds.S @@ -0,0 +1,73 @@ +/* + * Linker script for vsyscall DSO. The vsyscall page is an ELF shared + * object prelinked to its virtual address, and with only one read-only + * segment (that fits in one page). This script controls its layout. + */ +#include + +/* Default link addresses for the vDSOs */ +#define VDSO32_LBASE 0x100000 +#define VDSO64_LBASE 0x100000 + +/* Default map addresses */ +#define VDSO32_MBASE VDSO32_LBASE +#define VDSO64_MBASE VDSO64_LBASE + +OUTPUT_ARCH(mips) +ENTRY(__kernel_sigtramp_32); + +SECTIONS +{ + . = VDSO32_LBASE + SIZEOF_HEADERS; + + .hash : { *(.hash) } :text + .gnu.hash : { *(.gnu.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + + . = ALIGN(16); + + .text : { *(.text) } :text + .note : { *(.note.*) } :text :note + .eh_frame_hdr : { *(.eh_frame_hdr) } :text :eh_frame_hdr + .eh_frame : { KEEP (*(.eh_frame)) } :text + + .dynamic : { *(.dynamic) } :text :dynamic + .got : { *(.got) } + .plt : { *(.plt) } + + /DISCARD/ : { + *(.got.plt) *(.got) + *(.data .data.* .gnu.linkonce.d.*) + *(.dynbss) + *(.bss .bss.* .gnu.linkonce.b.*) + } :text +} + +/* + * We must supply the ELF program headers explicitly to get just one + * PT_LOAD segment, and set the flags explicitly to make segments read-only. + */ +PHDRS +{ + text PT_LOAD FILEHDR PHDRS FLAGS(5); /* PF_R|PF_X */ + dynamic PT_DYNAMIC FLAGS(4); /* PF_R */ + note PT_NOTE FLAGS(4); /* PF_R */ + eh_frame_hdr 0x6474e550; /* PT_GNU_EH_FRAME, but ld doesn't match the name */ +} + +/* + * This controls what symbols we export from the DSO. + */ +VERSION +{ + LINUX_2.6.24 { + global: + __kernel_sigtramp_32; + __kernel_sigtramp_rt32; + local: *; + }; +} From pinskia@gmail.com Tue Nov 13 22:12:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 22:12:13 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.238]:39084 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20028100AbXKMWMF (ORCPT ); Tue, 13 Nov 2007 22:12:05 +0000 Received: by nz-out-0506.google.com with SMTP id n1so1236572nzf for ; Tue, 13 Nov 2007 14:11:54 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=H7MFF3rT44+V61gO2fjZbrQhkn/yBvZlKlGS+vUzaCk=; b=Ke7M4ajYj5e/i2aVhbs/tAG33ZnbS1WlcNPIOXGFl3UxKZ/1MuwEO7EbuJ/UIy9ckaCWhDx+vjh3x3b4ILsB0ykvn0nFpUKmRO/wRaylOFbFfoh/6tQcwQ2yLrDRB6fE8urWtVJ9R4ZF6Tf1Fziea9Lxee76aHnFl8pCOOdx73s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ln1Rfla843+jAPBPvblidYRs0hAhpw41PLYgeN6/nfy6019gnswGFS1Vd4KjcM4q2OHyAH7ICdG/s5TXwUlScyux2k1nPkTY000EZGNCdrfdIXOsRVW5cpqy6gIJMMyoPtDdKXIC5suHHL1lZFXWxgvziIAn67ufIgzij3F4rxQ= Received: by 10.142.76.4 with SMTP id y4mr87074wfa.1194991912549; Tue, 13 Nov 2007 14:11:52 -0800 (PST) Received: by 10.143.4.16 with HTTP; Tue, 13 Nov 2007 14:11:52 -0800 (PST) Message-ID: Date: Tue, 13 Nov 2007 14:11:52 -0800 From: "Andrew Pinski" To: "Ralf Baechle" Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Cc: "Franck Bui-Huu" , "Andrew Haley" , "David Daney" , linux-mips@linux-mips.org, "Richard Sandiford" , gcc@gcc.gnu.org In-Reply-To: <20071113150146.GC7650@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <20071113140036.GA7650@linux-mips.org> <20071113150146.GC7650@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pinskia@gmail.com Precedence: bulk X-list: linux-mips On 11/13/07, Ralf Baechle wrote: > Old versions of glibc were probable the most notorious users of trampolines. > Objective C also generates them. Since a cacheflush that is a syscall is > required performance is less than great. No Objective-C does not generate them. Objective-C returns the exact function pointer back. Now libffi generates trampolines. -- Pinski From kevink@mips.com Tue Nov 13 22:57:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Nov 2007 22:57:42 +0000 (GMT) Received: from mx.mips.com ([63.167.95.198]:30908 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20029005AbXKMW5d (ORCPT ); Tue, 13 Nov 2007 22:57:33 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id lADMnEuS027365; Tue, 13 Nov 2007 14:49:14 -0800 (PST) Received: from grendel (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with SMTP id lADMncl4023057; Tue, 13 Nov 2007 14:49:40 -0800 (PST) Message-ID: <02c801c82647$7b0619b0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: "Franck Bui-Huu" , "Andrew Haley" , "David Daney" , , "Richard Sandiford" , References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <019e01c82602$f5463bf0$10eca8c0@grendel> <20071113150820.GB6582@linux-mips.org> Subject: Re: Cannot unwind through MIPS signal frames withICACHE_REFILLS_WORKAROUND_WAR Date: Tue, 13 Nov 2007 23:49:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > > True, though it should perhaps be noted that currently it's only on 4KSc/Sd > > systems (which I know you work on) where it's even possible for the stack > > *not* to have exec permissions, since the classical MIPS MMU gives > > execute permission to any page that is readable. > > Disabling PROT_EXEC on a mapping tells the kernel it doesn't need to take > care of I-cache coherency. So it's somewhat beneficial even in absence of > a protection bit in the actual TLB hardware. That depends on just what the consequences of I-cache incoherence might be. Without help from the MMU, the kernel cannot *know* that a given location isn't in the I-cache, because a program can always compute a pointer-to-function to an arbitrary address and dereference it successfully so long as the location is readable. If it's only the user who does this that will suffer as a result of I-cache incoherence, one can argue that it serves him right. But if it can screw up the execution of the kernel, or other user processes, I think we have to assume the worst. > Some of these performance optimizations are impossible because the kernel > can't have definate knowledge that certain addresses have never entered the > I-cache. Sad but true. Regards, Kevin K. From david.kuk@entone.com Wed Nov 14 04:26:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 04:27:01 +0000 (GMT) Received: from rv-out-0910.google.com ([209.85.198.186]:22157 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022719AbXKNE0v (ORCPT ); Wed, 14 Nov 2007 04:26:51 +0000 Received: by rv-out-0910.google.com with SMTP id l15so41939rvb for ; Tue, 13 Nov 2007 20:26:40 -0800 (PST) Received: by 10.141.178.5 with SMTP id f5mr178615rvp.1195012832016; Tue, 13 Nov 2007 20:00:32 -0800 (PST) Received: from ?192.168.1.154? ( [203.198.58.230]) by mx.google.com with ESMTPS id g6sm396382rvb.2007.11.13.20.00.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Nov 2007 20:00:31 -0800 (PST) Message-ID: <473A72DC.1020900@entone.com> Date: Wed, 14 Nov 2007 12:00:28 +0800 From: David Kuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: hello Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david.kuk@entone.com Precedence: bulk X-list: linux-mips Hi all I am a new guy for both linux and mips, may i ask questions here ?? THX From freddy@dusktilldawn.nl Wed Nov 14 07:56:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 07:56:14 +0000 (GMT) Received: from tool.snarl.nl ([82.95.241.19]:54542 "EHLO tool.snarl.nl") by ftp.linux-mips.org with ESMTP id S20024522AbXKNH4C (ORCPT ); Wed, 14 Nov 2007 07:56:02 +0000 Received: from localhost (tool.local.snarl.nl [127.0.0.1]) by tool.snarl.nl (Postfix) with ESMTP id C1F1E5DFB2; Wed, 14 Nov 2007 08:55:55 +0100 (CET) Received: from tool.snarl.nl ([127.0.0.1]) by localhost (tool.local.snarl.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RTPR0YIu5NJz; Wed, 14 Nov 2007 08:55:54 +0100 (CET) Received: by tool.snarl.nl (Postfix, from userid 1000) id 0B7675DFAF; Wed, 14 Nov 2007 08:55:54 +0100 (CET) Date: Wed, 14 Nov 2007 08:55:53 +0100 From: Freddy Spierenburg To: David Kuk Cc: linux-mips@linux-mips.org Subject: Re: hello Message-ID: <20071114075552.GR2391@dusktilldawn.nl> References: <473A72DC.1020900@entone.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVYOjVWOcH+Ezkzp" Content-Disposition: inline In-Reply-To: <473A72DC.1020900@entone.com> X-User-Agent-Feature: All mail clients suck. This one just sucks less. X-GPG-Key: http://snarl.nl/~freddy/keys/freddyPublicKey.gpg 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: 17493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: freddy@dusktilldawn.nl Precedence: bulk X-list: linux-mips --nVYOjVWOcH+Ezkzp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi David, On Wed, Nov 14, 2007 at 12:00:28PM +0800, David Kuk wrote: > I am a new guy for both linux and mips, may i ask questions here ?? If your question is Linux kernel and MIPS related, go ahead! You don't need to ask if you may ask a question, just fire it up! If it is more user-land related in the sense of how can I unpack a tarball or the like, you might wander of to some other places like http://www.linuxquestions.org/. As a general rule of thumb; look at the small description of a list on a page like: http://www.linux-mips.org/wiki/Net_Resources#Mailing_lists and see what kind of questions other people ask on the list archive: http://www.linux-mips.org/archives/ This is true not only for the linux-mips community, but for the rest too. Good luck! --=20 $ cat ~/.signature Freddy Spierenburg http://freddy.snarl.nl/ GnuPG: 0x7941D1E1=3DC948 5851 26D2 FA5C 39F1 E588 6F17 FD5D 7941 D1E1 $ # Please read http://www.ietf.org/rfc/rfc2015.txt before complain! --nVYOjVWOcH+Ezkzp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFHOqoIbxf9XXlB0eERArbQAKCTsXZNnKlFknhe0PiBQ+QNLbqt7ACY6hKv 19gg9Hhl2xcz+F36v2sVkQ== =fMKm -----END PGP SIGNATURE----- --nVYOjVWOcH+Ezkzp-- From vagabon.xyz@gmail.com Wed Nov 14 08:26:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 08:26:54 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.186]:1806 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20024865AbXKNI0q (ORCPT ); Wed, 14 Nov 2007 08:26:46 +0000 Received: by fk-out-0910.google.com with SMTP id f40so95874fka for ; Wed, 14 Nov 2007 00:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=D8tQCcUSeg1/mPL6dfvMfUtk2xFcplY1Vow7KaTLBZQ=; b=aDSglRRJWel5Igc12je8wLumoIOj67U93htaZp6j69GivXseozv50MPL3YAxx44IWxRRd5bvjKQl9usgUhfYs0Rle6L3XtKQstDWMrILEaXcgjo1V16buRjnlww+lVRhu/01aCaDDy96lLjRW+Xwn7VT7KerLgSJeVhsARnkqgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cztoGC4SuySmtC0lRfYRBoh+39VFObhSFXuIxlb6fvzbRGRWJJEwK21l8HvoxCDHyiSvfX74+tJWL3ABiRraSQ6P437AA53NcjQrvEDN/t4vVvhdXYtHe0YvM+YbJh7dx7KytWJqI4lNwx5AkZVUcW61rQACJ9EZgHd09c1c8so= Received: by 10.82.119.17 with SMTP id r17mr3638701buc.1195028795532; Wed, 14 Nov 2007 00:26:35 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id g1sm616777muf.2007.11.14.00.26.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Nov 2007 00:26:34 -0800 (PST) Message-ID: <473AB0B6.2070208@gmail.com> Date: Wed, 14 Nov 2007 09:24:22 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Thiemo Seufer CC: Ralf Baechle , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() References: <4736C1EA.2050009@gmail.com> <20071111130130.GB8363@networkno.de> In-Reply-To: <20071111130130.GB8363@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > Franck Bui-Huu wrote: >> /* >> - * memset(void *s, int c, size_t n) >> + * An outline version of memset, which should be used either by gcc or >> + * by assembly code. >> + */ >> +NESTED(memset, 24, ra) >> + PTR_ADDU sp, sp, -24 >> + LONG_S a0, 16(sp) >> + LONG_S ra, 20(sp) >> + jal __fill_user >> + LONG_L v0, 16(sp) >> + LONG_L ra, 20(sp) >> + PTR_ADDU sp, sp, 24 >> + jr ra >> +END(memset) > > This will break on 64bit kernels. > Is the following correct ? NESTED(memset, 16, ra) PTR_ADDU sp, sp, -16 LONG_S a0, 8(sp) LONG_S ra, 16(sp) jal __fill_user LONG_L v0, 8(sp) LONG_L ra, 16(sp) PTR_ADDU sp, sp, 16 jr ra END(memset) I know it doesn't respect any mips ABI but in this case do we really care ? thanks. Franck From david.kuk@entone.com Wed Nov 14 08:45:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 08:45:17 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.180]:24374 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20024951AbXKNIpJ (ORCPT ); Wed, 14 Nov 2007 08:45:09 +0000 Received: by wa-out-1112.google.com with SMTP id m16so116879waf for ; Wed, 14 Nov 2007 00:44:51 -0800 (PST) Received: by 10.114.166.1 with SMTP id o1mr510380wae.1195029891869; Wed, 14 Nov 2007 00:44:51 -0800 (PST) Received: from ?192.168.1.154? ( [203.198.58.230]) by mx.google.com with ESMTPS id k24sm916182waf.2007.11.14.00.44.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Nov 2007 00:44:50 -0800 (PST) Message-ID: <473AB56B.2070107@entone.com> Date: Wed, 14 Nov 2007 16:44:27 +0800 From: David Kuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: smp8634 add memory at dram1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david.kuk@entone.com Precedence: bulk X-list: linux-mips After study about the memory configuration of sigma smp8634, i found some difficult to accomplish the task. so my question is if have two 128MB ram separately under dram0 and dram1 controller, where dram0 for linux and dram1 for video decoding. Now the situation is the memory for linux is not enough and video decoding can not use all of it's 128MB at dram1, what we plan to do is to share 64MB at dram1 to the linux kernel as high memory, and only reserved 64MB at dram1 for the video decoding. first, in MIPS architecture, we found that the kseg0 and kseg1 are mapped to 0x00000000-0x20000000, which include only dram0 controller, so we wish to add the dram1 memory manually to the kernel using function add_memory_region at setup.c , after booting up result the warning that the memory larger than 512 need to configured the kernel support high memory. then when we configure the kernel to support high memory at menu configure, the kernel when booting up will remind us our CPU do not support high memory due to cache aliases. Both way will lead the linux can not boot up normally, so what should we do, is there any mis-understanding about the hardware implementation or MIPS design? \ From ralf@linux-mips.org Wed Nov 14 11:11:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 11:11:32 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:31665 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026023AbXKNLLa (ORCPT ); Wed, 14 Nov 2007 11:11:30 +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 lAEB4RUG020312; Wed, 14 Nov 2007 11:04:53 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAEB4R3S020311; Wed, 14 Nov 2007 11:04:27 GMT Date: Wed, 14 Nov 2007 11:04:26 +0000 From: Ralf Baechle To: David Kuk Cc: linux-mips@linux-mips.org Subject: Re: smp8634 add memory at dram1 Message-ID: <20071114110426.GA19693@linux-mips.org> References: <473AB56B.2070107@entone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473AB56B.2070107@entone.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: 17496 X-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, Nov 14, 2007 at 04:44:27PM +0800, David Kuk wrote: > After study about the memory configuration of sigma smp8634, i found > some difficult to accomplish the task. > > so my question is if have two 128MB ram separately under dram0 and dram1 > controller, where dram0 for linux and dram1 for video decoding. Now the > situation is the memory for linux is not enough and video decoding can > not use all of it's 128MB at dram1, what we plan to do is to share 64MB > at dram1 to the linux kernel as high memory, and only reserved 64MB at > dram1 for the video decoding. > > first, in MIPS architecture, we found that the kseg0 and kseg1 are > mapped to 0x00000000-0x20000000, which include only dram0 controller, so > we wish to add the dram1 memory manually to the kernel using function > add_memory_region at setup.c , after booting up result the warning that > the memory larger than 512 need to configured the kernel support high > memory. > > then when we configure the kernel to support high memory at menu > configure, the kernel when booting up will remind us our CPU do not > support high memory due to cache aliases. This is really a software restriction. I originally developped highmem for MIPS on a Sibyte SB1250 which doesn't suffer from aliases so I didn't even attempt to solve the cache aliasing issue. The other platforms on whic highmem used to be used was the E9000 family but it seem by now the users of these platforms have all moved to full 64-bit kernels, so aside fo the implementation restrictions has also started to bitrot a little. What would be necessary to get it to work is to flush the page from cache at kunmap() rsp. kunmap_atomic() time. That should do the trick though there are significant further optimizations possible. An alterantive to solve the aliasing issue would be to increase the page size to 16K. Again, the combination of highmem and 16K pages is untested. I don't know what processor core Sigma is using in this SOC. In case its a 64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit kernel, it's much less painful than highmem. Ralf From ths@networkno.de Wed Nov 14 11:58:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 11:58:24 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:48561 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20026069AbXKNL6P (ORCPT ); Wed, 14 Nov 2007 11:58:15 +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 75E9C48BCB; Wed, 14 Nov 2007 11:43:45 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IsGsi-0006AR-4m; Wed, 14 Nov 2007 11:58:08 +0000 Date: Wed, 14 Nov 2007 11:58:08 +0000 From: Thiemo Seufer To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() Message-ID: <20071114115807.GL8363@networkno.de> References: <4736C1EA.2050009@gmail.com> <20071111130130.GB8363@networkno.de> <473AB0B6.2070208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473AB0B6.2070208@gmail.com> 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: 17497 X-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 Franck Bui-Huu wrote: > Thiemo Seufer wrote: > > Franck Bui-Huu wrote: > >> /* > >> - * memset(void *s, int c, size_t n) > >> + * An outline version of memset, which should be used either by gcc or > >> + * by assembly code. > >> + */ > >> +NESTED(memset, 24, ra) > >> + PTR_ADDU sp, sp, -24 > >> + LONG_S a0, 16(sp) > >> + LONG_S ra, 20(sp) > >> + jal __fill_user > >> + LONG_L v0, 16(sp) > >> + LONG_L ra, 20(sp) > >> + PTR_ADDU sp, sp, 24 > >> + jr ra > >> +END(memset) > > > > This will break on 64bit kernels. > > > > Is the following correct ? > > NESTED(memset, 16, ra) > PTR_ADDU sp, sp, -16 > LONG_S a0, 8(sp) > LONG_S ra, 16(sp) > jal __fill_user > LONG_L v0, 8(sp) > LONG_L ra, 16(sp) > PTR_ADDU sp, sp, 16 > jr ra > END(memset) > > I know it doesn't respect any mips ABI but in this case do > we really care ? In general we do (think of stack unwinding etc.). I believe this implementation should move to C, as it doesn't need an assembler implementation: void *memset (void *s, int c, kernel_size_t n) { __fill_user(s, c, n); return s; } It looks much nicer that way. :-) Thiemo From vagabon.xyz@gmail.com Wed Nov 14 12:36:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 12:37:02 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.188]:3784 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20026277AbXKNMgx (ORCPT ); Wed, 14 Nov 2007 12:36:53 +0000 Received: by fk-out-0910.google.com with SMTP id f40so152892fka for ; Wed, 14 Nov 2007 04:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=L4ZWNm9CS0TIPtCphL9PcZWzzLlJTsrXCIPOndF6TeM=; b=UiKq1F3KoZY/D6W7ILacMgAajmlK7KiZI0AclyWGfHocx9l686sAp7mQsH0hI8OFcPjfXD3MyHri1sZFxOUVR5zxcILaSDAWc/WbcbmK35pBgfvvqDGa1+hf4BhcfT3VGQKZUNhv3hgYPRh2LGwIRYVbUw8gABTebeRBWQQYuBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=RUE+s1wvDlOed4b198HJ76I5dmJsflqdqpGCEPNxshmtjWD2/DGq/zNmwpsPaGs9pN56kg77SxEs162QVw3MdnmcJBFyZU/dkPZPcA/rrrmC18zN+YOtUjNLPJ5VtOuH8mmUh9j+nSmWvMQy1Y8IkrDkUxViNMdH8IgTUy6lGjc= Received: by 10.82.190.2 with SMTP id n2mr121460buf.1195043803161; Wed, 14 Nov 2007 04:36:43 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id j9sm1010829mue.2007.11.14.04.36.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Nov 2007 04:36:42 -0800 (PST) Message-ID: <473AEB52.40501@gmail.com> Date: Wed, 14 Nov 2007 13:34:26 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Thiemo Seufer CC: Ralf Baechle , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() References: <4736C1EA.2050009@gmail.com> <20071111130130.GB8363@networkno.de> <473AB0B6.2070208@gmail.com> <20071114115807.GL8363@networkno.de> In-Reply-To: <20071114115807.GL8363@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > In general we do (think of stack unwinding etc.). I believe this > implementation should move to C, as it doesn't need an assembler > implementation: > > void *memset (void *s, int c, kernel_size_t n) > { > __fill_user(s, c, n); > return s; > } > > It looks much nicer that way. :-) > Sure but memset.S was a really good place to implement memset(), wasn't it ? And since the implementation should have been trivial, I thought it was ok to implement in assembly. Ok, I'll look for another place. Thanks, Franck From david@pixelmagicsystems.com Wed Nov 14 12:37:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 12:37:58 +0000 (GMT) Received: from mail197.abchk.net ([203.194.196.197]:60045 "EHLO webmail.abchk.net") by ftp.linux-mips.org with ESMTP id S20026290AbXKNMht (ORCPT ); Wed, 14 Nov 2007 12:37:49 +0000 Received: (qmail 10220 invoked by uid 89); 14 Nov 2007 12:36:33 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by webmail.abchk.net with SMTP; 14 Nov 2007 12:36:33 -0000 Received: from pcd309118.netvigator.com (pcd309118.netvigator.com [203.218.99.118]) by webmail.pixelmagicsystems.com (IMP) with HTTP for ; Wed, 14 Nov 2007 20:36:31 +0800 Message-ID: <1195043791.473aebcfdc740@webmail.pixelmagicsystems.com> Date: Wed, 14 Nov 2007 20:36:31 +0800 From: david@pixelmagicsystems.com To: Ralf Baechle Cc: David Kuk , linux-mips@linux-mips.org Subject: Re: smp8634 add memory at dram1 References: <473AB56B.2070107@entone.com> <20071114110426.GA19693@linux-mips.org> In-Reply-To: <20071114110426.GA19693@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=BIG5 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 203.218.99.118 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david@pixelmagicsystems.com Precedence: bulk X-list: linux-mips Quoting Ralf Baechle : > > I don't know what processor core Sigma is using in this SOC. In case its a > 64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit > kernel, it's much less painful than highmem. > > Ralf > > It is a MIPS 4KEc core. From ths@networkno.de Wed Nov 14 13:48:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 13:48:56 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:26045 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20026852AbXKNNsr (ORCPT ); Wed, 14 Nov 2007 13:48:47 +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 7519848BCD; Wed, 14 Nov 2007 13:34:16 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IsIbg-0008Ol-MK; Wed, 14 Nov 2007 13:48:40 +0000 Date: Wed, 14 Nov 2007 13:48:40 +0000 From: Thiemo Seufer To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() Message-ID: <20071114134840.GN8363@networkno.de> References: <4736C1EA.2050009@gmail.com> <20071111130130.GB8363@networkno.de> <473AB0B6.2070208@gmail.com> <20071114115807.GL8363@networkno.de> <473AEB52.40501@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473AEB52.40501@gmail.com> 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: 17500 X-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 Franck Bui-Huu wrote: > Thiemo Seufer wrote: > > In general we do (think of stack unwinding etc.). I believe this > > implementation should move to C, as it doesn't need an assembler > > implementation: > > > > void *memset (void *s, int c, kernel_size_t n) > > { > > __fill_user(s, c, n); > > return s; > > } > > > > It looks much nicer that way. :-) > > > > Sure but memset.S was a really good place to implement memset(), wasn't > it ? What about using memset.c and fill_user.S ? > And since the implementation should have been trivial, As you found out now, nothing is trivial in assembler. :-) > I thought it was ok to implement in assembly. As a general rule, assembly should only be used when C doesn't cut it. Thiemo From vagabon.xyz@gmail.com Wed Nov 14 15:14:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 15:14:12 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.189]:10706 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20029183AbXKNPOD (ORCPT ); Wed, 14 Nov 2007 15:14:03 +0000 Received: by nf-out-0910.google.com with SMTP id c10so175712nfd for ; Wed, 14 Nov 2007 07:13:53 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nu8LxLXgH/BlThpSYnwMCbWIuDgR54wTRkgcoZ4bJ3E=; b=YldHWVxNyxZwxoYE/gURzOUAu06Za/YPsdBU7umpFkLA5K5W7QHPMla7piWAJzRDBUBPKzBPUhLnDSjT9Wa1YSI/nhR0iwZoaiT+OQTwA2V2eujRTF9fJzB4sfbG4iDA/mens42vIBQa61rczLgoYF/TcebXc6qI9hZZIM9eEiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nEOcRsoHCt7PjwsvtLkxw23iuVoMPMPVF8bXBkCuFb8GsK/1+3owtSpU7Lwz2yeRdQwCq1n6fMJwW+IBHjYZ3fS4wUC9FvSjeMEjYiD9wq2kY1K4GjBxHTT08fuiTATSltWzrVnClOmzwM1ZlJeaYIvF3oCIJjSNcnM6jlfKRrc= Received: by 10.78.167.12 with SMTP id p12mr8166935hue.1195053230606; Wed, 14 Nov 2007 07:13:50 -0800 (PST) Received: by 10.78.179.18 with HTTP; Wed, 14 Nov 2007 07:13:50 -0800 (PST) Message-ID: Date: Wed, 14 Nov 2007 16:13:50 +0100 From: "Franck Bui-Huu" To: "Thiemo Seufer" Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() Cc: "Ralf Baechle" , linux-mips In-Reply-To: <20071114134840.GN8363@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4736C1EA.2050009@gmail.com> <20071111130130.GB8363@networkno.de> <473AB0B6.2070208@gmail.com> <20071114115807.GL8363@networkno.de> <473AEB52.40501@gmail.com> <20071114134840.GN8363@networkno.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On Nov 14, 2007 2:48 PM, Thiemo Seufer wrote: > What about using memset.c and fill_user.S ? > Quite frankly, I don't know if we could create memset.c and put inside a function of 2 lines. And I don't think we're going to add some stuff in it later. What about implementing fill_user() in C ? -- Franck From ddaney@avtrex.com Wed Nov 14 16:10:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 16:10:21 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:4825 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20029619AbXKNQKM (ORCPT ); Wed, 14 Nov 2007 16:10:12 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id EC17130FF5A; Wed, 14 Nov 2007 16:10:08 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Wed, 14 Nov 2007 16:10:08 +0000 (UTC) Received: from jennifer.localdomain ([192.168.7.223]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 08:09:54 -0800 Message-ID: <473B1DD0.2090903@avtrex.com> Date: Wed, 14 Nov 2007 08:09:52 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: David Kuk Cc: linux-mips@linux-mips.org Subject: Re: smp8634 add memory at dram1 References: <473AB56B.2070107@entone.com> In-Reply-To: <473AB56B.2070107@entone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 16:09:55.0013 (UTC) FILETIME=[CB910750:01C826D8] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips David Kuk wrote: > After study about the memory configuration of sigma smp8634, i found > some difficult to accomplish the task. > > so my question is if have two 128MB ram separately under dram0 and > dram1 controller, where dram0 for linux and dram1 for video decoding. > Now the situation is the memory for linux is not enough and video > decoding can not use all of it's 128MB at dram1, what we plan to do is > to share 64MB at dram1 to the linux kernel as high memory, and only > reserved 64MB at dram1 for the video decoding. > > first, in MIPS architecture, we found that the kseg0 and kseg1 are > mapped to 0x00000000-0x20000000, which include only dram0 controller, > so we wish to add the dram1 memory manually to the kernel using > function add_memory_region at setup.c , after booting up result the > warning that the memory larger than 512 need to configured the kernel > support high memory. > > then when we configure the kernel to support high memory at menu > configure, the kernel when booting up will remind us our CPU do not > support high memory due to cache aliases. > > Both way will lead the linux can not boot up normally, so what should > we do, is there any mis-understanding about the hardware > implementation or MIPS design? I think your understanding of the 8634 is at least close to correct. It may be possible (but I have not tried it yet) to use the remapping registers to move dram1 into the first 512MB of the memory space. If it is possible, you would then have to modify the gbus access functions accordingly. Also the 8634 media drivers would probably have to be changed as well. I am not sure about the microcode for the media DSPs, but if it is dependent on the mapping of the DRAM, then you would probably have to get the vendor's help. Let me know if you are successful. Thanks, David Daney From lists@nabble.com Wed Nov 14 20:41:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 20:41:13 +0000 (GMT) Received: from kuber.nabble.com ([216.139.236.158]:27581 "EHLO kuber.nabble.com") by ftp.linux-mips.org with ESMTP id S20030736AbXKNUlF convert rfc822-to-8bit (ORCPT ); Wed, 14 Nov 2007 20:41:05 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IsOzh-0003ol-Sx for linux-mips@linux-mips.org; Wed, 14 Nov 2007 12:37:53 -0800 Message-ID: <13755803.post@talk.nabble.com> Date: Wed, 14 Nov 2007 12:37:53 -0800 (PST) From: Jiju George T To: linux-mips@linux-mips.org Subject: Re: MIPS assembly directives in GCC In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Nabble-From: jijuktm@gmail.com 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: 17503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jijuktm@gmail.com Precedence: bulk X-list: linux-mips See Chapter 8 of http://www.cs.unibo.it/~solmi/teaching/arch_2002-2003/AssemblyLanguageProgDoc.pdf Regards, Jiju 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) > > -- > Hyon Lim (임현) > Mobile. 010-8212-1240 (Intl' Call : +82-10-8212-1240) > Fax. 032-232-0578 (Intl' Available) > Homepage : http://www.alexlab.net > Blog : http://www.alexlab.net/blog > > -- View this message in context: http://www.nabble.com/MIPS-assembly-directives-in-GCC-tf4731041.html#a13755803 Sent from the linux-mips main mailing list archive at Nabble.com. From kaz@zeugmasystems.com Wed Nov 14 23:20:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Nov 2007 23:20:20 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:51862 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20031007AbXKNXUL convert rfc822-to-8bit (ORCPT ); Wed, 14 Nov 2007 23:20:11 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: "exportfs -a" -> stale NFS filehandle Date: Wed, 14 Nov 2007 15:19:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "exportfs -a" -> stale NFS filehandle Thread-Index: AcgnFNbW97dDhBWkQhSAn9o02emXvQ== From: "Kaz Kylheku" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Hi all, I have an NFS problem on a multi-node MIPS system running kernel 2.6.17.7. NFS utils is 1.1.0. ABI is n32. One node (call it primary) exports a directory which is mounted by several others (the secondaries) as their root filesystem. If I run "exportfs -a" on the primary, the secondary nodes lose their root filesystem and so everything stops working. I turned on all NFS debugging on a secondary node (sysctl -w sunrpc.nfs_debug=65535). What is happening is that NFS operations suddenly start returning error -151 (stale NFS filehandle). I don't see exportfs causing this problem on other systems. If I run "exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots of diskless clients, nothing bad happens. (And some of those diskless clients are MIPS systems just like this one!) I'm pretty sure that exportfs -a shouldn't screw up the existing mounted clients. Could there be some ABI problem that corrupts up the effect of the re-exporting operation on the server? (This issure reproduces always. Something which reproduces rarely is a kernel crash on a secondary node, inside the nfsd process, also apparently in response to the "exportfs -a". I don't yet have enough information about that one, such as a call trace, etc. That one I can drill into, if I have a program counter and call stack.) From ralf@linux-mips.org Thu Nov 15 00:49:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 00:49:26 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:48090 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20031102AbXKOAtY (ORCPT ); Thu, 15 Nov 2007 00:49:24 +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 lAF0mMR9032364; Thu, 15 Nov 2007 00:48:47 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAF0mLLw032363; Thu, 15 Nov 2007 00:48:21 GMT Date: Thu, 15 Nov 2007 00:48:21 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: "exportfs -a" -> stale NFS filehandle Message-ID: <20071115004821.GA32332@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.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: 17505 X-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, Nov 14, 2007 at 03:19:43PM -0800, Kaz Kylheku wrote: > I have an NFS problem on a multi-node MIPS system running kernel > 2.6.17.7. NFS utils is 1.1.0. ABI is n32. > > One node (call it primary) exports a directory which is mounted by > several others (the secondaries) as their root filesystem. > > If I run "exportfs -a" on the primary, the secondary nodes lose their > root filesystem and so everything stops working. > > I turned on all NFS debugging on a secondary node (sysctl -w > sunrpc.nfs_debug=65535). What is happening is that NFS operations > suddenly start returning error -151 (stale NFS filehandle). > > I don't see exportfs causing this problem on other systems. If I run > "exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots > of diskless clients, nothing bad happens. (And some of those diskless > clients are MIPS systems just like this one!) > > I'm pretty sure that exportfs -a shouldn't screw up the existing mounted > clients. > > Could there be some ABI problem that corrupts up the effect of the > re-exporting operation on the server? Can you test below patch? Ralf Signed-off-by: Ralf Baechle diff --git a/arch/mips/kernel/scall64-n32.S b/arch/mips/kernel/scall64-n32.S index 118be24..01993ec 100644 --- a/arch/mips/kernel/scall64-n32.S +++ b/arch/mips/kernel/scall64-n32.S @@ -293,7 +293,7 @@ EXPORT(sysn32_call_table) PTR sys_ni_syscall /* 6170, was get_kernel_syms */ PTR sys_ni_syscall /* was query_module */ PTR sys_quotactl - PTR sys_nfsservctl + PTR compat_sys_nfsservctl PTR sys_ni_syscall /* res. for getpmsg */ PTR sys_ni_syscall /* 6175 for putpmsg */ PTR sys_ni_syscall /* res. for afs_syscall */ From vagabon.xyz@gmail.com Thu Nov 15 08:46:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 08:46:50 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.190]:31084 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20023678AbXKOIqm (ORCPT ); Thu, 15 Nov 2007 08:46:42 +0000 Received: by nf-out-0910.google.com with SMTP id c10so390314nfd for ; Thu, 15 Nov 2007 00:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=3V45Wj6xgswpitHtIwmcrgKRmENTDowigN2H9FkfzTM=; b=WsEZlysWLGn2lOJDbIW4vsbwz0hdUNvLlWkSE3q+JfZyp5Jd12ot0hAYxWv4HS1U+CcXYNbVH4lqjsRgJj9axOCklIbablg8SbNk0nhMAbOMTeJRKVz+sSV6t9lsXE181/VL4D+n37kCw8i/PorTVzDjD6YMRXFQuYJ0wjfjLOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=k2rFG1wQWYZ30bbZGaSY3Opf9VJ+n7Dt12pQV6H6gPLnFMvjs6u8T7TCN9kIc486pz7g2p0qhWd8sah4hrOhsLCIAbzn8HbgKvka0SFzSxPKmdon+QdxsoOZM4Z7W2LVMoAkrmfKXLXZbWJs4uyOImiyGfJK0U1wHrA3HGClOuk= Received: by 10.86.9.8 with SMTP id 8mr414907fgi.1195116392123; Thu, 15 Nov 2007 00:46:32 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 22sm2295435fkr.2007.11.15.00.46.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Nov 2007 00:46:31 -0800 (PST) Message-ID: <473C0761.1040205@gmail.com> Date: Thu, 15 Nov 2007 09:46:25 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> In-Reply-To: <20071113121036.GA6582@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Another reason is to get rid of the classic trampoline the kernel installs > on the stack. On some multiprocessor systems it requires a cacheflush BTW, could we get rid of the trampoline so easily ? I mean won't we have to keep it for backward compatibility reasons ? Franck From marcus.gustafsson@motorola.com Thu Nov 15 10:51:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 10:51:47 +0000 (GMT) Received: from mail153.messagelabs.com ([216.82.253.51]:37750 "HELO mail153.messagelabs.com") by ftp.linux-mips.org with SMTP id S20025588AbXKOKvi convert rfc822-to-8bit (ORCPT ); Thu, 15 Nov 2007 10:51:38 +0000 X-VirusChecked: Checked X-Env-Sender: marcus.gustafsson@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1195123771!13775708!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31562 invoked from network); 15 Nov 2007 10:49:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 15 Nov 2007 10:49:31 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id lAFAnQ29020904 for ; Thu, 15 Nov 2007 03:49:30 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id lAFAnQMM020809 for ; Thu, 15 Nov 2007 04:49:26 -0600 (CST) Received: from zuk35exm65.ds.mot.com (zuk35exm65.ea.mot.com [10.178.4.21]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id lAFAnOqI020799 for ; Thu, 15 Nov 2007 04:49:25 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: smp8634 add memory at dram1 Date: Thu, 15 Nov 2007 10:49:23 -0000 Message-ID: <8D20BBB55F590E42AADF592A815E86170155CEB0@zuk35exm65.ds.mot.com> In-Reply-To: <473B1DD0.2090903@avtrex.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: smp8634 add memory at dram1 Thread-Index: Acgm2QB4xn+6fb3YRXGJOOt6dN86XAAm96dA From: "Gustafsson Marcus-MGU001" To: X-CFilter-Loop: Reflected Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: marcus.gustafsson@motorola.com Precedence: bulk X-list: linux-mips David Daney wrote > I think your understanding of the 8634 is at least close to correct. > > It may be possible (but I have not tried it yet) to use the > remapping registers to move dram1 into the first 512MB of the > memory space. If it is possible, you would then have to > modify the gbus access functions accordingly. Also the 8634 > media drivers would probably have to be changed as well. I > am not sure about the microcode for the media DSPs, but if it > is dependent on the mapping of the DRAM, then you would > probably have to get the vendor's help. > > Let me know if you are successful. AFAIK the memory bandwith available is not enough for supporting video decoding and Linux usage at the same dram controller. /Marcus Gustafsson From ralf@linux-mips.org Thu Nov 15 11:53:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 11:53:56 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:16325 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025259AbXKOLxy (ORCPT ); Thu, 15 Nov 2007 11:53:54 +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 lAFBrpY6005214; Thu, 15 Nov 2007 11:53:52 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAFBrpoN005213; Thu, 15 Nov 2007 11:53:51 GMT Date: Thu, 15 Nov 2007 11:53:51 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR Message-ID: <20071115115351.GA4973@linux-mips.org> References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <473C0761.1040205@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473C0761.1040205@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: 17508 X-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 15, 2007 at 09:46:25AM +0100, Franck Bui-Huu wrote: > Ralf Baechle wrote: > > Another reason is to get rid of the classic trampoline the kernel installs > > on the stack. On some multiprocessor systems it requires a cacheflush > > BTW, could we get rid of the trampoline so easily ? I mean won't we have > to keep it for backward compatibility reasons ? The trampolines are an implementation detail. Little software needs to know about it, so while I expect some slight colateral damage from getting rid of trampolines it's not going to be painful. GDB is the primary piece of software that will need to change. Some of the other architectures have an sa_restorer field in struct sigaction but we don't have that on MIPS. One way to deal with this would be to do a similar as IRIX where the sigaction(2) takes a 4th argument which takes the role of sa_restorer. For backward compatibility an SA_RESTORER field. So if the SA_RESTORER is clear we'd be using a classic trampoline, if it's set the value of the 4th argument. Or slightly crazier, put a kernel address into the $ra register of the invoked signal handler. So the signal handler will cause an address error exception which then can be trapped. Additional advantage - some of the "Don't let your children do this ..." sections of code can go away ;-) Ralf From fbuihuu@gmail.com Thu Nov 15 16:21:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 16:22:05 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.185]:51658 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20031829AbXKOQV4 (ORCPT ); Thu, 15 Nov 2007 16:21:56 +0000 Received: by mu-out-0910.google.com with SMTP id g7so604959muf for ; Thu, 15 Nov 2007 08:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=IdK9Gg3Edjg4TeueMZMoWS9xj81foWrf8o/q02d80vs=; b=dZHayId60+3VCxuwTaPQQ7tPRMJRZ0pKT3sWfo57z9pYLNwZfvhPStR/WxbPVayS4Nw/oEVmeEFp6f+1aEeVlf1VE6rLNGHR+XpRsQovx1btRC5epszRNNOEkPwVx4+X+kmUGxkLgjs8U/YrOQ71IU942XnFh/jlRgoobAkQg6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=l3aD9EhvNgqkanw8oXgP9LP2+4QvMLinAM82NfcTPGozeOdRf0UheB84+LIcXn8ZMRbA5slUp40UbAHp66pD+jWYGBYxWjajCZC+ZN/AxQJxjNrYZ/ItqrgmsFgp0d64c4lUerSvKEvv4wh+KhT0IOI5YUhRF3TIcqk5VwqMGdk= Received: by 10.82.183.19 with SMTP id g19mr2336904buf.1195143705756; Thu, 15 Nov 2007 08:21:45 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id w7sm3359260mue.2007.11.15.08.21.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Nov 2007 08:21:41 -0800 (PST) Message-ID: <473C720B.7000100@gmail.com> Date: Thu, 15 Nov 2007 17:21:31 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , linux-mips Subject: [PATCH] Introduce __fill_user() and kill __bzero() [take #2] X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Currently memset() is used to fill a user space area (clear_user) or kernel one (memset). These two functions don't have the same prototype, the former returning the number of bytes not copied and the latter returning the start address of the area to clear. This forces memset() to actually returns two values in an unconventional way ie the number of bytes not copied is given by $a2. Therefore clear_user() needs to call memset() using inline assembly. Instead this patch creates __fill_user() which is the same as memset() except it always returns the number of bytes not copied. This simplify clear_user() and makes its definition saner. Also an out of line version of memset is given because gcc generates some calls to it since builtin functions have been disabled. It allows assembly code to call it too. Eventually __bzero() has been removed because it's not part of the Linux uaccess API. And the nano-optimization it brings is not worthing. Signed-off-by: Franck Bui-Huu --- Thimeo, I put the out of line version of memset in kernel/mips_ksym.c. I haven't found a better place. But if you really think we should create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I can change it. Thanks, Franck arch/mips/kernel/mips_ksyms.c | 13 +++++++++++-- arch/mips/lib/csum_partial.S | 2 +- arch/mips/lib/memcpy.S | 2 +- arch/mips/lib/memset.S | 34 +++++++++++++++++----------------- include/asm-mips/string.h | 7 ++++++- include/asm-mips/uaccess.h | 17 +++-------------- 6 files changed, 39 insertions(+), 36 deletions(-) diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c index 225755d..091275e 100644 --- a/arch/mips/kernel/mips_ksyms.c +++ b/arch/mips/kernel/mips_ksyms.c @@ -14,7 +14,6 @@ #include #include -extern void *__bzero(void *__s, size_t __count); extern long __strncpy_from_user_nocheck_asm(char *__to, const char *__from, long __len); extern long __strncpy_from_user_asm(char *__to, const char *__from, @@ -36,9 +35,9 @@ EXPORT_SYMBOL(kernel_thread); /* * Userspace access stuff. */ +EXPORT_SYMBOL(__fill_user); EXPORT_SYMBOL(__copy_user); EXPORT_SYMBOL(__copy_user_inatomic); -EXPORT_SYMBOL(__bzero); EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm); EXPORT_SYMBOL(__strncpy_from_user_asm); EXPORT_SYMBOL(__strlen_user_nocheck_asm); @@ -51,3 +50,13 @@ EXPORT_SYMBOL(csum_partial_copy_nocheck); EXPORT_SYMBOL(__csum_partial_copy_user); EXPORT_SYMBOL(invalid_pte_table); + +/* + * An outline version of memset, which should be used either by gcc or + * by assembly code. + */ +void *memset(void *s, int c, __kernel_size_t len) +{ + __fill_user(s, c, len); + return s; +} diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index c0a77fe..8d3fa1e 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -694,7 +694,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..425f2c3 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -443,7 +443,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 3f8b8b3..4329811 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -46,17 +46,19 @@ .endm /* - * memset(void *s, int c, size_t n) + * __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n) * * a0: start of area to clear * a1: char to fill with * a2: size of area to clear + * + * Returns the number of bytes NOT set or 0 on success. */ .set noreorder .align 5 -LEAF(memset) +LEAF(__fill_user) beqz a1, 1f - move v0, a0 /* result */ + move v0, zero /* result */ andi a1, 0xff /* spread fillword */ LONG_SLL t1, a1, 8 @@ -68,8 +70,6 @@ LEAF(memset) #endif or a1, t1 1: - -FEXPORT(__bzero) sltiu t0, a2, LONGSIZE /* very small region? */ bnez t0, small_memset andi t0, a0, LONGMASK /* aligned? */ @@ -127,7 +127,7 @@ memset_partial: EX(LONG_S_L, a1, -1(a0), last_fixup) #endif 1: jr ra - move a2, zero + nop small_memset: beqz a2, 2f @@ -138,29 +138,29 @@ small_memset: sb a1, -1(a0) 2: jr ra /* done */ - move a2, zero - END(memset) + nop +END(__fill_user) first_fixup: - jr ra - nop + jr ra + move v0, a2 fwd_fixup: PTR_L t0, TI_TASK($28) LONG_L t0, THREAD_BUADDR(t0) - andi a2, 0x3f - LONG_ADDU a2, t1 + andi v0, a2, 0x3f + LONG_ADDU v0, t1 jr ra - LONG_SUBU a2, t0 + LONG_SUBU v0, t0 partial_fixup: PTR_L t0, TI_TASK($28) LONG_L t0, THREAD_BUADDR(t0) - andi a2, LONGMASK - LONG_ADDU a2, t1 + andi v0, a2, LONGMASK + LONG_ADDU v0, t1 jr ra - LONG_SUBU a2, t0 + LONG_SUBU v0, t0 last_fixup: jr ra - andi v1, a2, LONGMASK + andi v0, a2, LONGMASK diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h index 436e3ad..2bba927 100644 --- a/include/asm-mips/string.h +++ b/include/asm-mips/string.h @@ -10,6 +10,7 @@ #ifndef _ASM_STRING_H #define _ASM_STRING_H +#include /* __fill_user() */ /* * Most of the inline functions are rather naive implementations so I just @@ -132,7 +133,11 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) #endif /* CONFIG_32BIT */ #define __HAVE_ARCH_MEMSET -extern void *memset(void *__s, int __c, size_t __count); +extern inline void *memset(void *s, int c, size_t count) +{ + __fill_user(s, c, count); + return s; +} #define __HAVE_ARCH_MEMCPY extern void *memcpy(void *__to, __const__ void *__from, size_t __n); diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index c30c718..8c0d226 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -11,7 +11,6 @@ #include #include -#include #include /* @@ -633,23 +632,13 @@ extern size_t __copy_user_inatomic(void *__to, const void *__from, size_t __n); * Returns number of bytes that could not be cleared. * On success, this will be zero. */ +extern __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n); + static inline __kernel_size_t __clear_user(void __user *addr, __kernel_size_t size) { - __kernel_size_t res; - might_sleep(); - __asm__ __volatile__( - "move\t$4, %1\n\t" - "move\t$5, $0\n\t" - "move\t$6, %2\n\t" - __MODULE_JAL(__bzero) - "move\t%0, $6" - : "=r" (res) - : "r" (addr), "r" (size) - : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31"); - - return res; + return __fill_user(addr, 0, size); } #define clear_user(addr,n) \ From geert@linux-m68k.org Thu Nov 15 16:46:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 16:46:40 +0000 (GMT) Received: from europa.telenet-ops.be ([195.130.137.75]:56535 "EHLO europa.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20031830AbXKOQqc (ORCPT ); Thu, 15 Nov 2007 16:46:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by europa.telenet-ops.be (Postfix) with SMTP id 9C13441FA; Thu, 15 Nov 2007 17:46:21 +0100 (CET) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by europa.telenet-ops.be (Postfix) with ESMTP id 71B16418B; Thu, 15 Nov 2007 17:46:21 +0100 (CET) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id lAFGkLuw003701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Nov 2007 17:46:21 +0100 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id lAFGkIrY003698; Thu, 15 Nov 2007 17:46:19 +0100 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Thu, 15 Nov 2007 17:46:18 +0100 (CET) From: Geert Uytterhoeven To: Franck Bui-Huu Cc: Ralf Baechle , Thiemo Seufer , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2] In-Reply-To: <473C720B.7000100@gmail.com> Message-ID: References: <473C720B.7000100@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Thu, 15 Nov 2007, Franck Bui-Huu wrote: > I put the out of line version of memset in kernel/mips_ksym.c. I > haven't found a better place. But if you really think we should > create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I > can change it. kernel/mips_ksym.c is not a good place. Adrian `trivial' Bunk is scanning arch/ for *_ksym.c files and moving the EXPORT_SYMBOL()s to the source files they belong to. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ddaney@avtrex.com Thu Nov 15 17:21:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 17:21:34 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:58035 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20031871AbXKORVY (ORCPT ); Thu, 15 Nov 2007 17:21:24 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 770CD30F71D; Thu, 15 Nov 2007 17:21:24 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Thu, 15 Nov 2007 17:21:24 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 09:21:10 -0800 Message-ID: <473C8006.2070902@avtrex.com> Date: Thu, 15 Nov 2007 09:21:10 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Ralf Baechle Cc: Franck Bui-Huu , linux-mips@linux-mips.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <473C0761.1040205@gmail.com> <20071115115351.GA4973@linux-mips.org> In-Reply-To: <20071115115351.GA4973@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 17:21:10.0408 (UTC) FILETIME=[EA504880:01C827AB] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Nov 15, 2007 at 09:46:25AM +0100, Franck Bui-Huu wrote: > >> Ralf Baechle wrote: >>> Another reason is to get rid of the classic trampoline the kernel installs >>> on the stack. On some multiprocessor systems it requires a cacheflush >> BTW, could we get rid of the trampoline so easily ? I mean won't we have >> to keep it for backward compatibility reasons ? There has to be some way for user code to unwind the call stack through signal handler frames. For Linux/MIPS systems that use GCC as their system compiler, this is done by code in libgcc which is part of the GCC runtime. Currently the unwinder examines the code at the signal handler return address and if it detects one of the several know trampoline code sequences, it makes assumptions about the way the kernel lays out the stack. In particular, it assumes that there is a struct sigcontext at a well known offset from the stack pointer at entry to the signal handler. The code that handles this is in gcc/config/mips/linux-unwind.h As of GCC-4.3 the location of the trampoline is unimportant, but the location of the sigcontext relative to the value in $sp is important and should not be changed unless there really is no other choice. > > The trampolines are an implementation detail. Little software needs to > know about it, so while I expect some slight colateral damage from getting > rid of trampolines it's not going to be painful. GDB is the primary piece > of software that will need to change. And any user code that uses SIGSEGV to detect and handle dereferencing null pointers. > > Some of the other architectures have an sa_restorer field in struct > sigaction but we don't have that on MIPS. > > One way to deal with this would be to do a similar as IRIX where the > sigaction(2) takes a 4th argument which takes the role of sa_restorer. > For backward compatibility an SA_RESTORER field. So if the SA_RESTORER > is clear we'd be using a classic trampoline, if it's set the value of > the 4th argument. > > Or slightly crazier, put a kernel address into the $ra register of the > invoked signal handler. So the signal handler will cause an address > error exception which then can be trapped. Additional advantage - some of > the "Don't let your children do this ..." sections of code can go away ;-) I am liking the idea of putting the trampoline code in the (as of yet non-existent vdso). This eliminates the need to flush the icache, but maintains the ability of user code to unwind through signal frames. Putting a .eh_frame section in the vdso would be even better as that would eliminate the need for libgcc to do code reading and let the kernel use any means desired to return from signal handlers. David Daney From kaz@zeugmasystems.com Thu Nov 15 18:38:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 18:38:53 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:42712 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20032184AbXKOSio convert rfc822-to-8bit (ORCPT ); Thu, 15 Nov 2007 18:38:44 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: "exportfs -a" -> stale NFS filehandle Date: Thu, 15 Nov 2007 10:38:37 -0800 Message-ID: In-Reply-To: <20071115004821.GA32332@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "exportfs -a" -> stale NFS filehandle Thread-Index: AcgnIWkmLMP+TSx6QLCshZmhN5OBlAAlI6RA From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Can you test below patch? > > Ralf [ snip ] > - PTR sys_nfsservctl > + PTR compat_sys_nfsservctl That's damn funny! I checked for replies this morning, but your e-mail went to my inbox rather than my linux-mips folder, so I didn't see it. I just made that change just moments ago. As I'm compiling it, a coworker says, ``Kaz, did you see Ralph's reply?''. :) Nope! From kaz@zeugmasystems.com Thu Nov 15 19:26:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 19:26:43 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:12252 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20032448AbXKOT0f convert rfc822-to-8bit (ORCPT ); Thu, 15 Nov 2007 19:26:35 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: "exportfs -a" -> stale NFS filehandle Date: Thu, 15 Nov 2007 11:26:06 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "exportfs -a" -> stale NFS filehandle Thread-Index: AcgnIWkmLMP+TSx6QLCshZmhN5OBlAAlI6RAAABvm/A= From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips linux-mips-bounce@linux-mips.org wrote: > Ralf Baechle wrote: >> Can you test below patch? >> >> Ralf > > [ snip ] > >> - PTR sys_nfsservctl >> + PTR compat_sys_nfsservctl > > That's damn funny! ... but it doesn't work. Now the slave systems won't even boot at all. Looking up port of RPC 100003/2 on 127.3.0.1 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/1 on 127.3.0.1 Root-NFS: Server returned error -13 while mounting /cf2 Ah, but the reason for /that/ is that I have an n32 patch against nfsutils in user space already, which has to be backed out. After backing out the nfsutils patch, the diskless node does boot. However, the original "exportfs -a" problem comes back! So this problem is not resolved simply by using the correct compat routine; it's deeper. Sigh. From andy.sharp@onstor.com Thu Nov 15 19:40:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 19:40:51 +0000 (GMT) Received: from mail.onstor.com ([66.201.51.107]:59817 "EHLO mail.onstor.com") by ftp.linux-mips.org with ESMTP id S20032486AbXKOTkn (ORCPT ); Thu, 15 Nov 2007 19:40:43 +0000 Received: from onstor-exch02.onstor.net ([66.201.51.106]) by mail.onstor.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 11:40:14 -0800 Received: from ripper.onstor.net ([10.0.0.42]) by onstor-exch02.onstor.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 11:40:14 -0800 Date: Thu, 15 Nov 2007 11:40:14 -0800 From: Andrew Sharp To: Ralf Baechle Cc: "linux-mips@linux-mips.org" Subject: Re: gdb chokes on core from 64-bit kernel (patch) Message-ID: <20071115114014.48d27c64@ripper.onstor.net> In-Reply-To: <20071109090757.GA12469@linux-mips.org> References: <20071108140322.7bf03aa9@ripper.onstor.net> <20071109090757.GA12469@linux-mips.org> 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: 15 Nov 2007 19:40:14.0535 (UTC) FILETIME=[57CD0570:01C827BF] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17514 X-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 Fri, 9 Nov 2007 09:07:57 +0000 Ralf Baechle wrote: > On Thu, Nov 08, 2007 at 02:03:22PM -0800, Andrew Sharp wrote: > > > The gdb from debian etch (6.4.90-debian) doesn't like core files > > produced by 64-bit kernel it seems. I've got this patch which seems > > to do the job, but I'm unclear on what other implications it might > > have, if any. > > > diff --git a/arch/mips/kernel/binfmt_elfo32.c > > b/arch/mips/kernel/binfmt_elfo32.c index 993f7ec..58533dc 100644 > > --- a/arch/mips/kernel/binfmt_elfo32.c > > +++ b/arch/mips/kernel/binfmt_elfo32.c > > @@ -54,9 +54,13 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG]; > > > > #include > > #include > > -#include > > #include > > > > +void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs); > > +#undef ELF_CORE_COPY_REGS > > +#define ELF_CORE_COPY_REGS(_dest,_regs) > > elf32_core_copy_regs(_dest,_regs); +#include > > + > > #define elf_prstatus elf_prstatus32 > > struct elf_prstatus32 > > { > > @@ -109,9 +113,6 @@ jiffies_to_compat_timeval(unsigned long > > jiffies, struct comp value->tv_usec = rem / NSEC_PER_USEC; > > } > > > > -#undef ELF_CORE_COPY_REGS > > -#define ELF_CORE_COPY_REGS(_dest,_regs) > > elf32_core_copy_regs(_dest,_regs); - > > void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs) > > { > > int i; > > Looks like it's a larger change than needed. Which change? Both files? > > diff --git a/include/asm-mips/reg.h b/include/asm-mips/reg.h > > index 634b55d..b44b308 100644 > > --- a/include/asm-mips/reg.h > > +++ b/include/asm-mips/reg.h > > @@ -12,7 +12,7 @@ > > #ifndef __ASM_MIPS_REG_H > > #define __ASM_MIPS_REG_H > > > > - > > +#define WANT_COMPAT_REG_H > > #if defined(CONFIG_32BIT) || defined(WANT_COMPAT_REG_H) > > > > #define EF_R0 6 > > @@ -69,7 +69,7 @@ > > > > #endif > > > > -#ifdef CONFIG_64BIT > > +#if defined(CONFIG_64BIT) && !defined(WANT_COMPAT_REG_H) > > > > #define EF_R0 0 > > #define EF_R1 1 > > This change breaks the native 64-bit and N32 ptrace and core dumpers. > > I suggest something more minimal like the below patch. Does that one > do the trick for you? > > Ralf > > Signed-off-by: Ralf Baechle > > arch/mips/kernel/ptrace32.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c > index 76818be..44109fb 100644 > --- a/arch/mips/kernel/ptrace32.c > +++ b/arch/mips/kernel/ptrace32.c > @@ -14,6 +14,9 @@ > * At this time Linux/MIPS64 only supports syscall tracing, even for > 32-bit > * binaries. > */ > + > +#define WANT_COMPAT_REG_H > + > #include > #include > #include Without the change to reg.h, this change causes a bunch of warning: "EF_R0" redefined type messages when compiling ptrace32.c. I tried a combination of mine and yours, well, really mine except I moved the define for WANT_COMPAT_REG_H to ptrace32.c, and that did not produce an comprehensible core file. Any suggestions? Cheers, a From ralf@linux-mips.org Thu Nov 15 19:45:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 19:45:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:64922 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032453AbXKOTpt (ORCPT ); Thu, 15 Nov 2007 19:45:49 +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 lAFJjm7D031101; Thu, 15 Nov 2007 19:45:48 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAFJjmwk031100; Thu, 15 Nov 2007 19:45:48 GMT Date: Thu, 15 Nov 2007 19:45:48 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: "exportfs -a" -> stale NFS filehandle Message-ID: <20071115194548.GA30481@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.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: 17515 X-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 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote: > After backing out the nfsutils patch, the diskless node does boot. > > However, the original "exportfs -a" problem comes back! > > So this problem is not resolved simply by using the correct compat > routine; it's deeper. > > Sigh. Thanks for testing anyway! Ralf From kaz@zeugmasystems.com Thu Nov 15 20:16:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 20:16:16 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:5850 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20032583AbXKOUQH convert rfc822-to-8bit (ORCPT ); Thu, 15 Nov 2007 20:16:07 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: "exportfs -a" -> stale NFS filehandle Date: Thu, 15 Nov 2007 12:15:39 -0800 Message-ID: In-Reply-To: <20071115194548.GA30481@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "exportfs -a" -> stale NFS filehandle Thread-Index: AcgnwCCtCdy5qIVVTMaI/zfLoW8HSAAAB8Cw From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote: > >> After backing out the nfsutils patch, the diskless node does boot. >> >> However, the original "exportfs -a" problem comes back! >> >> So this problem is not resolved simply by using the correct compat >> routine; it's deeper. >> >> Sigh. > > Thanks for testing anyway! I'm continuing to dig into the problem. The export logic doesn't even go through nfsctl() anyway, which is why I originally hadn't even suspected that syscall. The nfsexport() function in nfsutils first tries opening "/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a text-based protocol. Only if that interface doesn't exist does it fall back on the nfsctl(NFSCTL_EXPORT, ...) interface. From vagabon.xyz@gmail.com Thu Nov 15 21:16:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 21:16:56 +0000 (GMT) Received: from mu-out-0910.google.com ([209.85.134.186]:25458 "EHLO mu-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20032656AbXKOVQr (ORCPT ); Thu, 15 Nov 2007 21:16:47 +0000 Received: by mu-out-0910.google.com with SMTP id g7so704719muf for ; Thu, 15 Nov 2007 13:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=zkBxyQzYkDvKnJyvu2batJvPxTh+apCWIOHxywC6GGo=; b=O4hKEiUJw3Uo8ullcYeneO8NKKZkwBOEtEEWU+YOjZHhhOfq5kQBje+jR+efpbDLBSzOXT5UGsffUOqCRFiR0vpk4w4ziqpOL6WKuVMbUrfxyRIpbkv9OaaelyJsDrlAyZHXkG37THaO6ZaTo8QprcTxtak85WT2NKkwn/lI2sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=rPhic0jnwHpQYVndFYTrlZIp1SwpDeUQqMrpxuboCO/wbl/aFcksRz7KS1rK3JS9I3mX3UK2XLGwT+ux/jMJ2p2TjfxrzA35+3VJ8ea6PwshkYwQNdJh/QLNifm7SvxO3TChgXPftofoNcT5DrH7ksY3AfmknkJTjny29wjN16s= Received: by 10.86.84.5 with SMTP id h5mr1039380fgb.1195161397214; Thu, 15 Nov 2007 13:16:37 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id 4sm1196735fge.2007.11.15.13.16.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Nov 2007 13:16:36 -0800 (PST) Message-ID: <473CB727.8010106@gmail.com> Date: Thu, 15 Nov 2007 22:16:23 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Geert Uytterhoeven CC: Ralf Baechle , Thiemo Seufer , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2] References: <473C720B.7000100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Geert Uytterhoeven wrote: > On Thu, 15 Nov 2007, Franck Bui-Huu wrote: >> I put the out of line version of memset in kernel/mips_ksym.c. I >> haven't found a better place. But if you really think we should >> create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I >> can change it. > > kernel/mips_ksym.c is not a good place. Sigh... thanks for spotting this. So since I've no idea where I could put this function I'll follow Thiemo's suggestion but instead of calling the new file lib/memset.c, I'll use lib/string.c since we could move or implement other stuffs in it. Is it ok ? Franck From geert@linux-m68k.org Thu Nov 15 22:09:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 22:09:21 +0000 (GMT) Received: from ananke.telenet-ops.be ([195.130.137.78]:50621 "EHLO ananke.telenet-ops.be") by ftp.linux-mips.org with ESMTP id S20032755AbXKOWJN (ORCPT ); Thu, 15 Nov 2007 22:09:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by ananke.telenet-ops.be (Postfix) with SMTP id AE74A3923F1; Thu, 15 Nov 2007 23:09:02 +0100 (CET) Received: from anakin.of.borg (d54C15D55.access.telenet.be [84.193.93.85]) by ananke.telenet-ops.be (Postfix) with ESMTP id 8661A3923FA; Thu, 15 Nov 2007 23:09:02 +0100 (CET) Received: from anakin.of.borg (geert@localhost [127.0.0.1]) by anakin.of.borg (8.14.1/8.14.1/Debian-9) with ESMTP id lAFM92nP008746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Nov 2007 23:09:02 +0100 Received: from localhost (geert@localhost) by anakin.of.borg (8.14.1/8.14.1/Submit) with ESMTP id lAFM92Jf008743; Thu, 15 Nov 2007 23:09:02 +0100 X-Authentication-Warning: anakin.of.borg: geert owned process doing -bs Date: Thu, 15 Nov 2007 23:09:01 +0100 (CET) From: Geert Uytterhoeven To: Franck Bui-Huu cc: Ralf Baechle , Thiemo Seufer , linux-mips Subject: Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2] In-Reply-To: <473CB727.8010106@gmail.com> Message-ID: References: <473C720B.7000100@gmail.com> <473CB727.8010106@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Thu, 15 Nov 2007, Franck Bui-Huu wrote: > Geert Uytterhoeven wrote: > > On Thu, 15 Nov 2007, Franck Bui-Huu wrote: > >> I put the out of line version of memset in kernel/mips_ksym.c. I > >> haven't found a better place. But if you really think we should > >> create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I > >> can change it. > > > > kernel/mips_ksym.c is not a good place. > > Sigh... thanks for spotting this. > > So since I've no idea where I could put this function I'll follow > Thiemo's suggestion but instead of calling the new file lib/memset.c, > I'll use lib/string.c since we could move or implement other stuffs in > it. > > Is it ok ? lib/string.c sounds fine to me. That's where m68k and s390 implement it as well. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From ralf@linux-mips.org Thu Nov 15 23:02:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Nov 2007 23:02:23 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:60599 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032846AbXKOXCV (ORCPT ); Thu, 15 Nov 2007 23:02:21 +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 lAFN2Kmm003236; Thu, 15 Nov 2007 23:02:20 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAFN2J89003235; Thu, 15 Nov 2007 23:02:19 GMT Date: Thu, 15 Nov 2007 23:02:19 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: "exportfs -a" -> stale NFS filehandle Message-ID: <20071115230218.GA1696@linux-mips.org> References: <20071115194548.GA30481@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 17519 X-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 15, 2007 at 12:15:39PM -0800, Kaz Kylheku wrote: > Ralf Baechle wrote: > > On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote: > > > >> After backing out the nfsutils patch, the diskless node does boot. > >> > >> However, the original "exportfs -a" problem comes back! > >> > >> So this problem is not resolved simply by using the correct compat > >> routine; it's deeper. > >> > >> Sigh. > > > > Thanks for testing anyway! > > I'm continuing to dig into the problem. > > The export logic doesn't even go through nfsctl() anyway, which is why I > originally hadn't even suspected that syscall. > > The nfsexport() function in nfsutils first tries opening > "/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a > text-based protocol. Only if that interface doesn't exist does it fall > back on the nfsctl(NFSCTL_EXPORT, ...) interface. After checking that latest glibc still isn't trying to compensate for the N32 nfsservctl issue in userland I've applied the patch I sent you earlier. Ralf From fbuihuu@gmail.com Fri Nov 16 12:43:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Nov 2007 12:43:48 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.187]:7047 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20031792AbXKPMnj (ORCPT ); Fri, 16 Nov 2007 12:43:39 +0000 Received: by fk-out-0910.google.com with SMTP id f40so877629fka for ; Fri, 16 Nov 2007 04:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; bh=/ChyIysmlntpM+gH5nYHv9L/fI8kdtyNENbO3Sf/Z9I=; b=CnRP5KLyv5wTl7IJ+lUFyhOyhjLgXIlK9/wkkq9+4Rexd/TIqbQn7FT5UVerbusIz5vlvmfUApbh2dvPB3gRUeFFpI8qrMzXRk55hKf3dUXsk57r8jVcgfqLAfdX+LGGvN4VBfKxk8HdJM/MIo2fnrzzUbXhZg0BO9SEtafkH6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:x-enigmail-version:content-type:content-transfer-encoding; b=Np6i8V/26289kSJb0/ka5gsz2k3Y5ywY1UprCOHignGgBYFdUI1qoPK4RsXpC6pQZSlx0nwg/LBLH2AY/W184lUSU2TUnwVTW3bEHwFKdiZdLDn+1jtobrFiUfc7UofDq+N4An1IUmPdsF8dYoA897NZNqMNHHBqoBFi97xAtrM= Received: by 10.82.119.17 with SMTP id r17mr5041276buc.1195217018537; Fri, 16 Nov 2007 04:43:38 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id e9sm5265714muf.2007.11.16.04.43.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Nov 2007 04:43:37 -0800 (PST) Message-ID: <473D9072.1070209@gmail.com> Date: Fri, 16 Nov 2007 13:43:30 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , Geert Uytterhoeven , linux-mips Subject: [PATCH] Introduce __fill_user() and kill __bzero() [take #3] X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips Currently memset() is used to fill a user space area (clear_user) or kernel one (memset). These two functions don't have the same prototype, the former returning the number of bytes not copied and the latter returning the start address of the area to clear. This forces memset() to actually returns two values in an unconventional way ie the number of bytes not copied is given by $a2. Therefore clear_user() needs to call memset() using inline assembly. Instead this patch creates __fill_user() which is the same as memset() except it always returns the number of bytes not copied. This simplify clear_user() and makes its definition saner. This patch also renames memset.S into fill_user.S as suggested by Thiemo. Also an out of line version of memset is given because gcc generates some calls to it since builtin functions have been disabled. It allows assembly code to call it too. It has been put into a new file called string.c. Eventually __bzero() has been removed because it's not part of the Linux uaccess API. And the nano-optimization it brings is not worthing. Signed-off-by: Franck Bui-Huu --- Ralf, Since you use git, this patch has been generated with rename detection enabled. It makes the review a lot easier. Please consider, Franck arch/mips/kernel/mips_ksyms.c | 2 +- arch/mips/lib/Makefile | 4 +- arch/mips/lib/csum_partial.S | 2 +- arch/mips/lib/{memset.S => fill_user.S} | 34 +++++++++++++++--------------- arch/mips/lib/memcpy.S | 2 +- arch/mips/lib/string.c | 13 +++++++++++ include/asm-mips/string.h | 7 +++++- include/asm-mips/uaccess.h | 17 ++------------ 8 files changed, 44 insertions(+), 37 deletions(-) rename arch/mips/lib/{memset.S => fill_user.S} (90%) create mode 100644 arch/mips/lib/string.c diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c index 225755d..c7613d3 100644 --- a/arch/mips/kernel/mips_ksyms.c +++ b/arch/mips/kernel/mips_ksyms.c @@ -38,7 +38,7 @@ EXPORT_SYMBOL(kernel_thread); */ EXPORT_SYMBOL(__copy_user); EXPORT_SYMBOL(__copy_user_inatomic); -EXPORT_SYMBOL(__bzero); +EXPORT_SYMBOL(__fill_user); EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm); EXPORT_SYMBOL(__strncpy_from_user_asm); EXPORT_SYMBOL(__strlen_user_nocheck_asm); diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 8810dfb..1c3fea4 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -2,8 +2,8 @@ # Makefile for MIPS-specific library files.. # -lib-y += csum_partial.o memcpy.o memcpy-inatomic.o memset.o strlen_user.o \ - strncpy_user.o strnlen_user.o uncached.o +lib-y += csum_partial.o fill_user.o memcpy.o memcpy-inatomic.o string.o \ + strlen_user.o strncpy_user.o strnlen_user.o uncached.o obj-y += iomap.o obj-$(CONFIG_PCI) += iomap-pci.o diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S index c0a77fe..8d3fa1e 100644 --- a/arch/mips/lib/csum_partial.S +++ b/arch/mips/lib/csum_partial.S @@ -694,7 +694,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/fill_user.S similarity index 90% rename from arch/mips/lib/memset.S rename to arch/mips/lib/fill_user.S index 3f8b8b3..4329811 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/fill_user.S @@ -46,17 +46,19 @@ .endm /* - * memset(void *s, int c, size_t n) + * __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n) * * a0: start of area to clear * a1: char to fill with * a2: size of area to clear + * + * Returns the number of bytes NOT set or 0 on success. */ .set noreorder .align 5 -LEAF(memset) +LEAF(__fill_user) beqz a1, 1f - move v0, a0 /* result */ + move v0, zero /* result */ andi a1, 0xff /* spread fillword */ LONG_SLL t1, a1, 8 @@ -68,8 +70,6 @@ LEAF(memset) #endif or a1, t1 1: - -FEXPORT(__bzero) sltiu t0, a2, LONGSIZE /* very small region? */ bnez t0, small_memset andi t0, a0, LONGMASK /* aligned? */ @@ -127,7 +127,7 @@ memset_partial: EX(LONG_S_L, a1, -1(a0), last_fixup) #endif 1: jr ra - move a2, zero + nop small_memset: beqz a2, 2f @@ -138,29 +138,29 @@ small_memset: sb a1, -1(a0) 2: jr ra /* done */ - move a2, zero - END(memset) + nop +END(__fill_user) first_fixup: - jr ra - nop + jr ra + move v0, a2 fwd_fixup: PTR_L t0, TI_TASK($28) LONG_L t0, THREAD_BUADDR(t0) - andi a2, 0x3f - LONG_ADDU a2, t1 + andi v0, a2, 0x3f + LONG_ADDU v0, t1 jr ra - LONG_SUBU a2, t0 + LONG_SUBU v0, t0 partial_fixup: PTR_L t0, TI_TASK($28) LONG_L t0, THREAD_BUADDR(t0) - andi a2, LONGMASK - LONG_ADDU a2, t1 + andi v0, a2, LONGMASK + LONG_ADDU v0, t1 jr ra - LONG_SUBU a2, t0 + LONG_SUBU v0, t0 last_fixup: jr ra - andi v1, a2, LONGMASK + andi v0, a2, LONGMASK diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..425f2c3 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -443,7 +443,7 @@ l_exc: ADD dst, t0 # compute start address in a1 SUB dst, src /* - * Clear len bytes starting at dst. Can't call __bzero because it + * Clear len bytes starting at dst. Can't call memset because it * might modify len. An inefficient loop for these rare times... */ beqz len, done diff --git a/arch/mips/lib/string.c b/arch/mips/lib/string.c new file mode 100644 index 0000000..42fb613 --- /dev/null +++ b/arch/mips/lib/string.c @@ -0,0 +1,13 @@ +#include + +#include + +/* + * An outline version of memset, which should be used either by gcc or + * by assembly code. + */ +void *memset(void *s, int c, __kernel_size_t len) +{ + __fill_user(s, c, len); + return s; +} diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h index 436e3ad..2bba927 100644 --- a/include/asm-mips/string.h +++ b/include/asm-mips/string.h @@ -10,6 +10,7 @@ #ifndef _ASM_STRING_H #define _ASM_STRING_H +#include /* __fill_user() */ /* * Most of the inline functions are rather naive implementations so I just @@ -132,7 +133,11 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count) #endif /* CONFIG_32BIT */ #define __HAVE_ARCH_MEMSET -extern void *memset(void *__s, int __c, size_t __count); +extern inline void *memset(void *s, int c, size_t count) +{ + __fill_user(s, c, count); + return s; +} #define __HAVE_ARCH_MEMCPY extern void *memcpy(void *__to, __const__ void *__from, size_t __n); diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index c30c718..8c0d226 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -11,7 +11,6 @@ #include #include -#include #include /* @@ -633,23 +632,13 @@ extern size_t __copy_user_inatomic(void *__to, const void *__from, size_t __n); * Returns number of bytes that could not be cleared. * On success, this will be zero. */ +extern __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n); + static inline __kernel_size_t __clear_user(void __user *addr, __kernel_size_t size) { - __kernel_size_t res; - might_sleep(); - __asm__ __volatile__( - "move\t$4, %1\n\t" - "move\t$5, $0\n\t" - "move\t$6, %2\n\t" - __MODULE_JAL(__bzero) - "move\t%0, $6" - : "=r" (res) - : "r" (addr), "r" (size) - : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31"); - - return res; + return __fill_user(addr, 0, size); } #define clear_user(addr,n) \ -- 1.5.3.5 From kaz@zeugmasystems.com Fri Nov 16 23:52:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Nov 2007 23:53:20 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:10058 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S28573704AbXKPXw4 convert rfc822-to-8bit (ORCPT ); Fri, 16 Nov 2007 23:52:56 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: futex_wake_op deadlock? Date: Fri, 16 Nov 2007 15:52:47 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: futex_wake_op deadlock? Thread-Index: Acgoq8nWvia3iCW7T1uI/ViIlK+6Mw== From: "Kaz Kylheku" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Hey everyone, From time to time, on 2.6.17.7, I see a deadlock situation go off. The soft lockup tick occurs in the middle of do_futex, which is heavily inlined. The system is actually hosed; it's not one of those recoverable CPU busy situations that can sometimes trigger the lockup detector. The instruction that is interrupted by the soft lockup tick appears to be in the assembly code (__futex_atomic_op) used by the futex_wake_op function; the case is FUTEX_OP_SET. It's the instruction just before the load-linked; i.e. the interrupt is outside of the ll/sc loop. I can't figure out how the code would get into a loop here. The ll/sc logic should eventually succeed. There is a large loop in the overall futex operation, but that is bounded by an interation variable (attempt++). (I checked the 2.6.17 head, but there doesn't appear to be any futex-related work). This lockup has reproduced more than once for us. Once at bootup, and several times on shutdown. The call stack always includes several do_futex frames, and a compat_sys_futex/handle_sysn32 at the top of the chain. This is from syslog (the unusual format is due to running metalog rather than syslog in our distribution, and the human-readable time in the square-bracketed printk timestamps is a locally developed patch): Jan 3 02:47:02 [kernel] [02:47:02.953075] [] softlockup_tick+0x1bc/0x208 Jan 3 02:47:02 [kernel] [02:47:02.953121] [] update_process_times+0x9c/0xe8 Jan 3 02:47:02 [kernel] [02:47:02.953158] [] ll_local_timer_interrupt+0x94/0xa8 Jan 3 02:47:02 [kernel] [02:47:02.953194] [] plat_irq_dispatch+0x120/0x1a0 Jan 3 02:47:02 [kernel] [02:47:02.953221] [] do_futex+0x870/0xb58 Jan 3 02:47:02 [kernel] [02:47:02.953251] [] do_futex+0x8f8/0xb58 Jan 3 02:47:02 [kernel] [02:47:02.953275] [] __lock_text_end+0x1b3c/0x474c Jan 3 02:47:02 [kernel] [02:47:02.953312] [] sys_sendto+0xe8/0x140 Jan 3 02:47:02 [kernel] [02:47:02.953345] [] compat_sys_futex+0x84/0x188 Jan 3 02:47:02 [kernel] [02:47:02.953372] [] handle_sysn32+0x54/0xb0 The sys_sendto is a red herring, since the backtrace function dumps every single word on the stack as an address, not having any frame pointers to go by. The code surrounding ffffffff80163758: ffffffff8016374c: 00023000 sll a2,v0,0x0 ffffffff80163750: 08058c77 j ffffffff801631dc ffffffff80163754: 00034000 sll a4,v1,0x0 ffffffff80163758: 0000102d move v0,zero <----<< ffffffff8016375c: c2030000 ll v1,0(s0) ffffffff80163760: 00a0082d move at,a1 ffffffff80163764: e2010000 sc at,0(s0) ffffffff80163768: 1020fffc beqz at,ffffffff8016375c ffffffff8016376c: 00000000 nop ffffffff80163770: 0000000f sync ffffffff80163774: 8f870024 lw a3,36(gp) ffffffff80163778: 00023000 sll a2,v0,0x0 ffffffff8016377c: 08058c77 j ffffffff801631dc You can tell from the "move at, a1" that it's the FUTEX_OP_SET case. From vagabon.xyz@gmail.com Sat Nov 17 08:38:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Nov 2007 08:38:50 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.188]:10117 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20022695AbXKQIim (ORCPT ); Sat, 17 Nov 2007 08:38:42 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1151836fka for ; Sat, 17 Nov 2007 00:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=cVwj1yeFEOen8n81pOF7WtDtMwlrl6aK/Z4KhV5rZUU=; b=dShDS1VBemIXeWDC3J8obbIZrGdbqDHM+fVv+qDyfPilQ9tUiP9+/Piky8jWGDeXHhtRfs5+qTapkLnOlYcMMisIKX8aaxLWAV3ECX1R6WaW2BBwsESLiJlJWtTCc0CWoblfhvQnVVgyhKi8e7zYLcyjwS9lDYfNe7OAKK65mjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ok7+Gp95N8Czvq/no1TZlML2noFz+5+52Ql/8B9Xd79AJAsWMSQrgPnPKP4FbO2CJnMn/DhDddBaSgbxHRz7HK5jJPpn3gUMOnPOo5ooo5yAnKGVPKGeWtWn1fM6MClcgfw3HAv1kJvuSAyZNM+UosQdLbHGFJS00aUZnANGz4s= Received: by 10.86.62.3 with SMTP id k3mr2660278fga.1195288712214; Sat, 17 Nov 2007 00:38:32 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id c28sm5569458fka.2007.11.17.00.38.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Nov 2007 00:38:31 -0800 (PST) Message-ID: <473EA885.80605@gmail.com> Date: Sat, 17 Nov 2007 09:38:29 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: David Daney CC: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR References: <473957B6.3030202@avtrex.com> <18233.36645.232058.964652@zebedee.pink> <20071113121036.GA6582@linux-mips.org> <473C0761.1040205@gmail.com> <20071115115351.GA4973@linux-mips.org> <473C8006.2070902@avtrex.com> In-Reply-To: <473C8006.2070902@avtrex.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips David Daney wrote: > I am liking the idea of putting the trampoline code in the (as of yet > non-existent vdso). This eliminates the need to flush the icache, but > maintains the ability of user code to unwind through signal frames. > > Putting a .eh_frame section in the vdso would be even better as that > would eliminate the need for libgcc to do code reading and let the > kernel use any means desired to return from signal handlers. > You're very welcome to improve the ld script for VDSO generation, I sent a couple days ago. I would be happy to integrate your improvements in my patch for the future version. thanks, Franck From tbm@cyrius.com Sat Nov 17 19:35:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Nov 2007 19:36:05 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:27666 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20023897AbXKQTf5 (ORCPT ); Sat, 17 Nov 2007 19:35:57 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 22D20D8D9; Sat, 17 Nov 2007 19:35:50 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id D239674171; Sat, 17 Nov 2007 20:35:29 +0100 (CET) Date: Sat, 17 Nov 2007 20:35:29 +0100 From: Martin Michlmayr To: "Maciej W. Rozycki" Cc: Giuseppe Sacco , mips kernel list Subject: Re: Preliminary patch for ip32 ttyS* device Message-ID: <20071117193529.GA11798@deprecation.cyrius.com> References: <20071030214015.050b7950.giuseppe@eppesuigoccas.homedns.org> <20071031130828.GE14187@linux-mips.org> <1194446585.5849.21.camel@scarafaggio> 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: 17523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Maciej W. Rozycki [2007-11-07 17:21]: > > If mapbase isn't mandatory, the second part of my patch is > > probably right and fixes a bug. > > You ought to use mapbase and ioremap() with new code as you are not > allowed to use readb()/writeb()/etc. on addresses obtained otherwise > than by calling ioremap(). The use of request_mem_region(), etc. is > not strictly mandatory, but it is nice to have. Many serial drivers > use these functions, so I cannot see a reason why it would be a > hassle for ip32. Can someone propose a patch? It's quote unfortuntely that serial on IP32 is still broken (including 2.6.23). -- Martin Michlmayr http://www.cyrius.com/ From ths@networkno.de Sat Nov 17 22:29:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Nov 2007 22:29:31 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:52151 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20024364AbXKQW3W (ORCPT ); Sat, 17 Nov 2007 22:29:22 +0000 Received: from lagash (88-106-143-223.dynamic.dsl.as9105.com [88.106.143.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id 6FD9348BD0; Sat, 17 Nov 2007 23:30:59 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1ItWA5-0001Xl-T9; Sat, 17 Nov 2007 22:29:14 +0000 Date: Sat, 17 Nov 2007 22:29:13 +0000 From: Thiemo Seufer To: netdev@vger.kernel.org Cc: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: [PATCH, REPOST] Fix/Rewrite of the mipsnet driver Message-ID: <20071117222913.GB11996@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 17524 X-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 Hello All, currently the mipsnet driver fails after transmitting a number of packages because SKBs are allocated but never freed. I fixed that and coudn't refrain from removing the most egregious warts. - mipsnet.h folded into mipsnet.c, as it doesn't provide any useful external interface. - Free SKB after transmission. - Call free_irq in mipsnet_close, to balance the request_irq in mipsnet_open. - Removed duplicate read of rxDataCount. - Some identifiers are now less verbose. - Removed dead and/or unnecessarily complex code. - Code formatting fixes. Tested on Qemu's mipssim emulation, with this patch it can boot a Debian NFSroot. Thiemo Signed-off-by: Thiemo Seufer --- b/drivers/net/mipsnet.c | 201 ++++++++++++++++++++++++++++++++---------------- drivers/net/mipsnet.h | 112 -------------------------- 2 files changed, 134 insertions(+), 179 deletions(-) diff --git a/drivers/net/mipsnet.c b/drivers/net/mipsnet.c index aafc3ce..6d343ef 100644 --- a/drivers/net/mipsnet.c +++ b/drivers/net/mipsnet.c @@ -4,8 +4,6 @@ * for more details. */ -#define DEBUG - #include #include #include @@ -15,11 +13,93 @@ #include #include -#include "mipsnet.h" /* actual device IO mapping */ +#define MIPSNET_VERSION "2007-11-17" + +/* + * Net status/control block as seen by sw in the core. + */ +struct mipsnet_regs { + /* + * Device info for probing, reads as MIPSNET%d where %d is some + * form of version. + */ + u64 devId; /*0x00 */ -#define MIPSNET_VERSION "2005-06-20" + /* + * read only busy flag. + * Set and cleared by the Net Device to indicate that an rx or a tx + * is in progress. + */ + u32 busy; /*0x08 */ -#define mipsnet_reg_address(dev, field) (dev->base_addr + field_offset(field)) + /* + * Set by the Net Device. + * The device will set it once data has been received. + * The value is the number of bytes that should be read from + * rxDataBuffer. The value will decrease till 0 until all the data + * from rxDataBuffer has been read. + */ + u32 rxDataCount; /*0x0c */ +#define MIPSNET_MAX_RXTX_DATACOUNT (1 << 16) + + /* + * Settable from the MIPS core, cleared by the Net Device. + * The core should set the number of bytes it wants to send, + * then it should write those bytes of data to txDataBuffer. + * The device will clear txDataCount has been processed (not + * necessarily sent). + */ + u32 txDataCount; /*0x10 */ + + /* + * Interrupt control + * + * Used to clear the interrupted generated by this dev. + * Write a 1 to clear the interrupt. (except bit31). + * + * Bit0 is set if it was a tx-done interrupt. + * Bit1 is set when new rx-data is available. + * Until this bit is cleared there will be no other RXs. + * + * Bit31 is used for testing, it clears after a read. + * Writing 1 to this bit will cause an interrupt to be generated. + * To clear the test interrupt, write 0 to this register. + */ + u32 interruptControl; /*0x14 */ +#define MIPSNET_INTCTL_TXDONE (1u << 0) +#define MIPSNET_INTCTL_RXDONE (1u << 1) +#define MIPSNET_INTCTL_TESTBIT (1u << 31) + + /* + * Readonly core-specific interrupt info for the device to signal + * the core. The meaning of the contents of this field might change. + */ + /* XXX: the whole memIntf interrupt scheme is messy: the device + * should have no control what so ever of what VPE/register set is + * being used. + * The MemIntf should only expose interrupt lines, and something in + * the config should be responsible for the line<->core/vpe bindings. + */ + u32 interruptInfo; /*0x18 */ + + /* + * This is where the received data is read out. + * There is more data to read until rxDataReady is 0. + * Only 1 byte at this regs offset is used. + */ + u32 rxDataBuffer; /*0x1c */ + + /* + * This is where the data to transmit is written. + * Data should be written for the amount specified in the + * txDataCount register. + * Only 1 byte at this regs offset is used. + */ + u32 txDataBuffer; /*0x20 */ +}; + +#define regaddr(dev, field) \ + (dev->base_addr + offsetof(struct mipsnet_regs, field)) static char mipsnet_string[] = "mipsnet"; @@ -29,32 +109,27 @@ static char mipsnet_string[] = "mipsnet"; static int ioiocpy_frommipsnet(struct net_device *dev, unsigned char *kdata, int len) { - uint32_t available_len = inl(mipsnet_reg_address(dev, rxDataCount)); - - if (available_len < len) - return -EFAULT; - for (; len > 0; len--, kdata++) - *kdata = inb(mipsnet_reg_address(dev, rxDataBuffer)); + *kdata = inb(regaddr(dev, rxDataBuffer)); - return inl(mipsnet_reg_address(dev, rxDataCount)); + return inl(regaddr(dev, rxDataCount)); } -static inline ssize_t mipsnet_put_todevice(struct net_device *dev, +static inline void mipsnet_put_todevice(struct net_device *dev, struct sk_buff *skb) { int count_to_go = skb->len; char *buf_ptr = skb->data; - outl(skb->len, mipsnet_reg_address(dev, txDataCount)); + outl(skb->len, regaddr(dev, txDataCount)); for (; count_to_go; buf_ptr++, count_to_go--) - outb(*buf_ptr, mipsnet_reg_address(dev, txDataBuffer)); + outb(*buf_ptr, regaddr(dev, txDataBuffer)); dev->stats.tx_packets++; dev->stats.tx_bytes += skb->len; - return skb->len; + dev_kfree_skb(skb); } static int mipsnet_xmit(struct sk_buff *skb, struct net_device *dev) @@ -69,18 +144,20 @@ static int mipsnet_xmit(struct sk_buff *skb, struct net_device *dev) return 0; } -static inline ssize_t mipsnet_get_fromdev(struct net_device *dev, size_t count) +static inline ssize_t mipsnet_get_fromdev(struct net_device *dev, size_t len) { struct sk_buff *skb; - size_t len = count; - skb = alloc_skb(len + 2, GFP_KERNEL); + if (!len) + return len; + + skb = dev_alloc_skb(len + NET_IP_ALIGN); if (!skb) { dev->stats.rx_dropped++; return -ENOMEM; } - skb_reserve(skb, 2); + skb_reserve(skb, NET_IP_ALIGN); if (ioiocpy_frommipsnet(dev, skb_put(skb, len), len)) return -EFAULT; @@ -92,50 +169,42 @@ static inline ssize_t mipsnet_get_fromdev(struct net_device *dev, size_t count) dev->stats.rx_packets++; dev->stats.rx_bytes += len; - return count; + return len; } static irqreturn_t mipsnet_interrupt(int irq, void *dev_id) { struct net_device *dev = dev_id; - - irqreturn_t retval = IRQ_NONE; - uint64_t interruptFlags; - - if (irq == dev->irq) { - retval = IRQ_HANDLED; - - interruptFlags = - inl(mipsnet_reg_address(dev, interruptControl)); - - if (interruptFlags & MIPSNET_INTCTL_TXDONE) { - outl(MIPSNET_INTCTL_TXDONE, - mipsnet_reg_address(dev, interruptControl)); - /* only one packet at a time, we are done. */ - netif_wake_queue(dev); - } else if (interruptFlags & MIPSNET_INTCTL_RXDONE) { - mipsnet_get_fromdev(dev, - inl(mipsnet_reg_address(dev, rxDataCount))); - outl(MIPSNET_INTCTL_RXDONE, - mipsnet_reg_address(dev, interruptControl)); - - } else if (interruptFlags & MIPSNET_INTCTL_TESTBIT) { - /* - * TESTBIT is cleared on read. - * And takes effect after a write with 0 - */ - outl(0, mipsnet_reg_address(dev, interruptControl)); - } else { - /* Maybe shared IRQ, just ignore, no clearing. */ - retval = IRQ_NONE; - } - - } else { - printk(KERN_INFO "%s: %s(): irq %d for unknown device\n", - dev->name, __FUNCTION__, irq); - retval = IRQ_NONE; + u32 int_flags; + irqreturn_t ret = IRQ_NONE; + + if (irq != dev->irq) + goto out_badirq; + + /* TESTBIT is cleared on read. */ + int_flags = inl(regaddr(dev, interruptControl)); + if (int_flags & MIPSNET_INTCTL_TESTBIT) { + /* TESTBIT takes effect after a write with 0. */ + outl(0, regaddr(dev, interruptControl)); + ret = IRQ_HANDLED; + } else if (int_flags & MIPSNET_INTCTL_TXDONE) { + /* Only one packet at a time, we are done. */ + dev->stats.tx_packets++; + netif_wake_queue(dev); + outl(MIPSNET_INTCTL_TXDONE, + regaddr(dev, interruptControl)); + ret = IRQ_HANDLED; + } else if (int_flags & MIPSNET_INTCTL_RXDONE) { + mipsnet_get_fromdev(dev, inl(regaddr(dev, rxDataCount))); + outl(MIPSNET_INTCTL_RXDONE, regaddr(dev, interruptControl)); + ret = IRQ_HANDLED; } - return retval; + return ret; + +out_badirq: + printk(KERN_INFO "%s: %s(): irq %d for unknown device\n", + dev->name, __FUNCTION__, irq); + return ret; } static int mipsnet_open(struct net_device *dev) @@ -144,18 +213,15 @@ static int mipsnet_open(struct net_device *dev) err = request_irq(dev->irq, &mipsnet_interrupt, IRQF_SHARED, dev->name, (void *) dev); - if (err) { - release_region(dev->base_addr, MIPSNET_IO_EXTENT); + release_region(dev->base_addr, sizeof(struct mipsnet_regs)); return err; } netif_start_queue(dev); /* test interrupt handler */ - outl(MIPSNET_INTCTL_TESTBIT, - mipsnet_reg_address(dev, interruptControl)); - + outl(MIPSNET_INTCTL_TESTBIT, regaddr(dev, interruptControl)); return 0; } @@ -163,7 +229,7 @@ static int mipsnet_open(struct net_device *dev) static int mipsnet_close(struct net_device *dev) { netif_stop_queue(dev); - + free_irq(dev->irq, dev); return 0; } @@ -194,10 +260,11 @@ static int __init mipsnet_probe(struct device *dev) */ netdev->base_addr = 0x4200; netdev->irq = MIPS_CPU_IRQ_BASE + MIPSCPU_INT_MB0 + - inl(mipsnet_reg_address(netdev, interruptInfo)); + inl(regaddr(netdev, interruptInfo)); /* Get the io region now, get irq on open() */ - if (!request_region(netdev->base_addr, MIPSNET_IO_EXTENT, "mipsnet")) { + if (!request_region(netdev->base_addr, sizeof(struct mipsnet_regs), + "mipsnet")) { err = -EBUSY; goto out_free_netdev; } @@ -217,7 +284,7 @@ static int __init mipsnet_probe(struct device *dev) return 0; out_free_region: - release_region(netdev->base_addr, MIPSNET_IO_EXTENT); + release_region(netdev->base_addr, sizeof(struct mipsnet_regs)); out_free_netdev: free_netdev(netdev); @@ -231,7 +298,7 @@ static int __devexit mipsnet_device_remove(struct device *device) struct net_device *dev = dev_get_drvdata(device); unregister_netdev(dev); - release_region(dev->base_addr, MIPSNET_IO_EXTENT); + release_region(dev->base_addr, sizeof(struct mipsnet_regs)); free_netdev(dev); dev_set_drvdata(device, NULL); diff --git a/drivers/net/mipsnet.h b/drivers/net/mipsnet.h deleted file mode 100644 index 0132c67..0000000 --- a/drivers/net/mipsnet.h +++ /dev/null @@ -1,112 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - */ -#ifndef __MIPSNET_H -#define __MIPSNET_H - -/* - * Id of this Net device, as seen by the core. - */ -#define MIPS_NET_DEV_ID ((uint64_t) \ - ((uint64_t) 'M' << 0)| \ - ((uint64_t) 'I' << 8)| \ - ((uint64_t) 'P' << 16)| \ - ((uint64_t) 'S' << 24)| \ - ((uint64_t) 'N' << 32)| \ - ((uint64_t) 'E' << 40)| \ - ((uint64_t) 'T' << 48)| \ - ((uint64_t) '0' << 56)) - -/* - * Net status/control block as seen by sw in the core. - * (Why not use bit fields? can't be bothered with cross-platform struct - * packing.) - */ -struct net_control_block { - /* - * dev info for probing - * reads as MIPSNET%d where %d is some form of version - */ - uint64_t devId; /* 0x00 */ - - /* - * read only busy flag. - * Set and cleared by the Net Device to indicate that an rx or a tx - * is in progress. - */ - uint32_t busy; /* 0x08 */ - - /* - * Set by the Net Device. - * The device will set it once data has been received. - * The value is the number of bytes that should be read from - * rxDataBuffer. The value will decrease till 0 until all the data - * from rxDataBuffer has been read. - */ - uint32_t rxDataCount; /* 0x0c */ -#define MIPSNET_MAX_RXTX_DATACOUNT (1<<16) - - /* - * Settable from the MIPS core, cleared by the Net Device. The core - * should set the number of bytes it wants to send, then it should - * write those bytes of data to txDataBuffer. The device will clear - * txDataCount has been processed (not necessarily sent). - */ - uint32_t txDataCount; /* 0x10 */ - - /* - * Interrupt control - * - * Used to clear the interrupted generated by this dev. - * Write a 1 to clear the interrupt. (except bit31). - * - * Bit0 is set if it was a tx-done interrupt. - * Bit1 is set when new rx-data is available. - * Until this bit is cleared there will be no other RXs. - * - * Bit31 is used for testing, it clears after a read. - * Writing 1 to this bit will cause an interrupt to be generated. - * To clear the test interrupt, write 0 to this register. - */ - uint32_t interruptControl; /*0x14 */ -#define MIPSNET_INTCTL_TXDONE ((uint32_t)(1 << 0)) -#define MIPSNET_INTCTL_RXDONE ((uint32_t)(1 << 1)) -#define MIPSNET_INTCTL_TESTBIT ((uint32_t)(1 << 31)) -#define MIPSNET_INTCTL_ALLSOURCES (MIPSNET_INTCTL_TXDONE | \ - MIPSNET_INTCTL_RXDONE | \ - MIPSNET_INTCTL_TESTBIT) - - /* - * Readonly core-specific interrupt info for the device to signal the - * core. The meaning of the contents of this field might change. - * - * TODO: the whole memIntf interrupt scheme is messy: the device should - * have no control what so ever of what VPE/register set is being - * used. The MemIntf should only expose interrupt lines, and - * something in the config should be responsible for the - * line<->core/vpe bindings. - */ - uint32_t interruptInfo; /* 0x18 */ - - /* - * This is where the received data is read out. - * There is more data to read until rxDataReady is 0. - * Only 1 byte at this regs offset is used. - */ - uint32_t rxDataBuffer; /* 0x1c */ - - /* - * This is where the data to transmit is written. Data should be - * written for the amount specified in the txDataCount register. Only - * 1 byte at this regs offset is used. - */ - uint32_t txDataBuffer; /* 0x20 */ -}; - -#define MIPSNET_IO_EXTENT 0x40 /* being generous */ - -#define field_offset(field) (offsetof(struct net_control_block, field)) - -#endif /* __MIPSNET_H */ From sbrown@cortland.com Sun Nov 18 18:23:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Nov 2007 18:23:16 +0000 (GMT) Received: from spamgate.koyote.com ([204.11.24.49]:61592 "EHLO spamgate.koyote.com") by ftp.linux-mips.org with ESMTP id S20022867AbXKRSXG (ORCPT ); Sun, 18 Nov 2007 18:23:06 +0000 Received: from localhost (test [127.0.0.1]) by spamgate.koyote.com (Postfix) with ESMTP id 57329CBF8D for ; Sun, 18 Nov 2007 12:21:06 -0600 (CST) Received: from spamgate.koyote.com ([127.0.0.1]) by localhost (spamgate.koyote.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id PG9luhf4f5wI for ; Sun, 18 Nov 2007 12:21:04 -0600 (CST) Received: from mail.localdomain (mail.enetonline.net [204.11.24.29]) by spamgate.koyote.com (Postfix) with ESMTP id 261D8CBC7D for ; Sun, 18 Nov 2007 12:21:04 -0600 (CST) Received: from mythtv.ewol.com (unknown [66.209.47.173]) by mail.localdomain (Postfix) with ESMTP id 3ECDE3F8A4D for ; Sun, 18 Nov 2007 12:23:02 -0600 (CST) Message-ID: <47408305.5090804@cortland.com> Date: Sun, 18 Nov 2007 13:23:01 -0500 From: Steve Brown User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: ohci-ssb driver on a Broadcom BCM5354 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sbrown@cortland.com Precedence: bulk X-list: linux-mips The 5354 has a dual ohci/ehci usb core. It's in an ASUS WL520gu wifi router. The ohci hcd driver registers, but times out reading a descriptor from the device. Any suggestions on how to track down the problem? I'm using 2.6.32.1 kernel from the openwrt project with the "ohci SSB bus glue" and "Fix ohci-ssb with !CONFIG_PM" patches from linux-mips. If there is a better test frame, let me know and I'll build it and test that. Is this driver known to work with some combination of Broadcom hardware? The ohci/usb interface does work w/ the software provided with the WL520gu. Steve usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb ohci_hcd ssb0:1: SSB OHCI Controller ohci_hcd ssb0:1: new USB bus registered, assigned bus number 1 ohci_hcd ssb0:1: irq 5, io mem 0x18003000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected USB Universal Host Controller Interface driver v3.0 Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usb 1-1: new full speed USB device using ohci_hcd and address 2 usb 1-1: device descriptor read/64, error -145 =================== > root@OpenWrt:/# cat > /proc/bus/usb/devices > > > > T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= > 2 > > B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= > 0 > > D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= > 1 > > P: Vendor=0000 ProdID=0000 Rev= > 2.06 > > S: Manufacturer=Linux 2.6.23.1 > ssb-usb-ohci > > S: Product=SSB OHCI > Controller > > S: > SerialNumber=ssb0:1 > > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= > 0mA > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 > Driver=hub > > E: Ad=81(I) Atr=03(Int.) MxPS= 2 > Ivl=255ms > From vagabon.xyz@gmail.com Sun Nov 18 19:53:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Nov 2007 19:54:04 +0000 (GMT) Received: from fk-out-0910.google.com ([209.85.128.191]:47540 "EHLO fk-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20030837AbXKRTx4 (ORCPT ); Sun, 18 Nov 2007 19:53:56 +0000 Received: by fk-out-0910.google.com with SMTP id f40so1610986fka for ; Sun, 18 Nov 2007 11:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=4eqgswGYp8+TtFsfxDHJ6pLX9+0pdahjmenOToXJbMI=; b=SdAtqDyrty/MtSJtxe/YUFsnnpz0tMNUpX+XjcruGblizu9qx+bmDrhJ5AP710oshloK5w1msX3RPBkhcQNT+rdBj/VKFq+qATqjiSGcdBJJ0ACV3nGYuZ3NBnaicYYHspm4jYHPimMqQZwRV4/scB/Kd3bDCNoK1AivNQYt7ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HBpJ+JlWJ0aFtkx7goRkqioikKss9SK5hAadk6+uBoJ1OR2M/gSno0dIoU0CXqjxXyeyG1G8IgjfHTwOl8vkR0vg2/gMg7NYuiFYZXucUfIutN7nv8Chih6cuPIpIw4DQw1eHeOxMVnCb1S8aNbRGj6C5eNTsy/LNYIgILUiVpk= Received: by 10.82.134.12 with SMTP id h12mr11695991bud.1195415624868; Sun, 18 Nov 2007 11:53:44 -0800 (PST) Received: from ?192.168.0.1? ( [82.235.205.153]) by mx.google.com with ESMTPS id w7sm10309495mue.2007.11.18.11.53.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Nov 2007 11:53:44 -0800 (PST) Message-ID: <4740983D.6020408@gmail.com> Date: Sun, 18 Nov 2007 20:53:33 +0100 From: Franck Bui-Huu User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Steve Brown CC: linux-mips@linux-mips.org Subject: Re: ohci-ssb driver on a Broadcom BCM5354 References: <47408305.5090804@cortland.com> In-Reply-To: <47408305.5090804@cortland.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Steve Brown wrote: > The 5354 has a dual ohci/ehci usb core. It's in an ASUS WL520gu wifi > router. The ohci hcd driver registers, but times out reading a > descriptor from the device. > You'd better post this to linux-usb-devel@lists.sourceforge.net > Any suggestions on how to track down the problem? > CONFIG_USB_DEBUG=y and usbmon perhaps. Franck From adm@inseguro.com.br Sun Nov 18 20:40:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Nov 2007 20:40:28 +0000 (GMT) Received: from agamemnon.mpc.com.br ([200.184.85.246]:29888 "EHLO agamemnon.mpc.com.br") by ftp.linux-mips.org with ESMTP id S20027152AbXKRUkR convert rfc822-to-8bit (ORCPT ); Sun, 18 Nov 2007 20:40:17 +0000 Received: from localhost (localhost.mpc.com.br [127.0.0.1]) by agamemnon.mpc.com.br (Postfix) with ESMTP id D5A3175617; Sun, 18 Nov 2007 18:43:25 -0200 (BRST) Received: from agamemnon.mpc.com.br ([127.0.0.1]) by localhost (agamemnon.mpc.com.br [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80460-19; Sun, 18 Nov 2007 18:43:25 -0200 (BRST) Received: from F52F2867C1364CC (unknown [200.211.87.7]) (Authenticated sender: adminseguro@agamemnon.mpc.com.br) by agamemnon.mpc.com.br (Postfix) with ESMTP id 4373075608; Sun, 18 Nov 2007 18:43:25 -0200 (BRST) Message-ID: <387-2200711018204031296@F52F2867C1364CC> X-Priority: 1 To: "INVITATION" From: "inseguro" Subject: INVITATION Date: Sun, 18 Nov 2007 17:40:31 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-new at mpc.com.br Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adm@inseguro.com.br Precedence: bulk X-list: linux-mips INVITE YOU TO VISITE MOST IMPORTANTE BRAZILIAN WEB SITE, PORTUGUESE/ SPANINSH/ ENGLISH. WWW.INSEGURO.COM.BR SEND ME A MESSAGE ABOUT . 2.260.000 VIEWS. ADM@INSEGURO.COM.BR TKS, FERNANDO DOMINGOS From linville@tuxdriver.com Sun Nov 18 22:57:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Nov 2007 22:57:53 +0000 (GMT) Received: from ra.tuxdriver.com ([70.61.120.52]:28428 "EHLO ra.tuxdriver.com") by ftp.linux-mips.org with ESMTP id S20028909AbXKRW5n (ORCPT ); Sun, 18 Nov 2007 22:57:43 +0000 Received: from linville-t61.local (azure.tuxdriver.com [70.61.120.53]) (authenticated bits=0) by ra.tuxdriver.com (8.14.0/8.13.7) with ESMTP id lAIMov1H017455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Nov 2007 17:51:02 -0500 Received: from linville-t61.local (linville-t61.local [127.0.0.1]) by linville-t61.local (8.14.1/8.14.1) with ESMTP id lAIMlrIi012682; Sun, 18 Nov 2007 17:47:53 -0500 Received: (from linville@localhost) by linville-t61.local (8.14.1/8.14.1/Submit) id lAIMlqdr012681; Sun, 18 Nov 2007 17:47:52 -0500 Date: Sun, 18 Nov 2007 17:47:52 -0500 From: "John W. Linville" To: Steve Brown Cc: linux-mips@linux-mips.org, mb@bu3sch.de Subject: Re: ohci-ssb driver on a Broadcom BCM5354 Message-ID: <20071118224752.GB12263@tuxdriver.com> References: <47408305.5090804@cortland.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47408305.5090804@cortland.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: linux-mips You probably want to make Michael Buesch aware of this issue. John On Sun, Nov 18, 2007 at 01:23:01PM -0500, Steve Brown wrote: > The 5354 has a dual ohci/ehci usb core. It's in an ASUS WL520gu wifi > router. The ohci hcd driver registers, but times out reading a descriptor > from the device. > > Any suggestions on how to track down the problem? > > I'm using 2.6.32.1 kernel from the openwrt project with the "ohci SSB bus > glue" and "Fix ohci-ssb with !CONFIG_PM" patches from linux-mips. If there > is a better test frame, let me know and I'll build it and test that. > > Is this driver known to work with some combination of Broadcom hardware? > > The ohci/usb interface does work w/ the software provided with the WL520gu. > > Steve > > usbcore: registered new interface driver usbfs > > usbcore: registered new interface driver hub > > usbcore: registered new device driver usb > > ohci_hcd ssb0:1: SSB OHCI Controller > > ohci_hcd ssb0:1: new USB bus registered, assigned bus number 1 > > ohci_hcd ssb0:1: irq 5, io mem 0x18003000 > > usb usb1: configuration #1 chosen from 1 choice > > hub 1-0:1.0: USB hub found > > hub 1-0:1.0: 2 ports detected > > USB Universal Host Controller Interface driver v3.0 > > Initializing USB Mass Storage driver... > > usbcore: registered new interface driver usb-storage > > USB Mass Storage support registered. usb 1-1: new full speed USB device > using ohci_hcd and address 2 > > usb 1-1: device descriptor read/64, error -145 > > > =================== > >> root@OpenWrt:/# cat /proc/bus/usb/devices >> >> >> >> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 >> >> B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 >> >> D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 >> >> P: Vendor=0000 ProdID=0000 Rev= 2.06 >> >> S: Manufacturer=Linux 2.6.23.1 ssb-usb-ohci >> >> S: Product=SSB OHCI Controller >> >> S: SerialNumber=ssb0:1 >> >> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA >> >> I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 >> Driver=hub >> E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms >> >> > -- John W. Linville linville@tuxdriver.com From flo@rfc822.org Mon Nov 19 16:10:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 16:10:33 +0000 (GMT) Received: from hydra.gt.owl.de ([195.71.99.218]:43478 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S20029566AbXKSQKZ (ORCPT ); Mon, 19 Nov 2007 16:10:25 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 1000) id 32492937BA; Mon, 19 Nov 2007 17:09:54 +0100 (CET) Date: Mon, 19 Nov 2007 17:09:54 +0100 From: Florian Lohoff To: linux-mips@linux-mips.org Subject: IP22 64Bit arcboot - current git crashes on 3 machines at different points Message-ID: <20071119160954.GA12244@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline Organization: rfc822 - pure communication X-SpiderMe: mh-200711191703@listme.rfc822.org User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Bug#451805: linux-image-2.6.22-3-r4k-ip22 dies early on boot /= Starting ELF64 kernel Hi, i am seeing strange issues with 64 Bit kernels IP22 on different machines. This came up when i tried the debian distribution kernel which fails for me on 2 machines. Current git does not work on all 3=20 IP22 Indy R5k 150Mhz r4k-ip22-2.6.22-6 works current git 2.6.24-rc2 breaks in Zilog serial driver (see end) PROM Monitor SGI Version 5.3 Rev B10 R4X00/R5000 IP24 Feb 12, 1996 (BE) IP22 Indy R4k 100Mhz r4k-ip22-2.6.22-6 dies after "Starting ELF64 Kernel" current git 2.6.24-rc2 dies with a backtrace in cache_alloc_refill (see en= d) PROM Monitor SGI Version 5.1.2 Rev B4 R4X00 IP24 Dec 9, 1993 (BE) IP22 Indigo2 R4k 250Mhz r4k-ip22-2.6.22-6 dies after "Starting ELF64 Kernel" current git 2.6.24-rc2 dies after initializing hash tables (see end) PROM Monitor SGI Version 5.3 Rev E IP22 Sep 28, 1995 (BE) IP22 r5k 150Mhz Indy 2.6.24-rc2 >> boot 60928+176+320 entry: 0x88802d9c arcsboot: ARCS Linux ext2fs loader 0.3.8.8 Loading linux2624 from scsi(0)disk(1)partition(1) Allocated 0x70 bytes for segments Loading 64-bit executable Loading program segment 1 at 0x88004000, offset=3D0x0 4000, size =3D 0x0 40= e085 c000 (cache: 22.2%)18000 (cache: 34.7%)24000 (cache: 46.6%)3= 0000 (cache: 57.5%)3c000 (cache: 67.8%)48000 (cache: 74.3%)5= 4000 (cache: 77.7%)60000 (cache: 77.6%)6c000 (cache: 77.5%)7= 8000 (cache: 78.7%)84000 (cache: 78.9%)90000 (cache: 79.1%)9= c000 (cache: 80.3%)a8000 (cache: 82.6%)b4000 (cache: 82.5%)c= 0000 (cache: 82.7%)cc000 (cache: 84.3%)d8000 (cache: 85.0%)e= 4000 (cache: 85.3%)f0000 (cache: 86.1%)fc000 (cache: 85.9%)1= 08000 (cache: 86.8%)114000 (cache: 87.5%)120000 (cache: 88.2= %)12c000 (cache: 88.7%)138000 (cache: 89.2%)144000 (cache: 8= 9.6%)150000 (cache: 90.0%)15c000 (cache: 90.3%)168000 (cache= : 90.6%)174000 (cache: 90.8%)180000 (cache: 91.1%)18c000 (ca= che: 91.3%)198000 (cache: 91.5%)1a4000 (cache: 91.6%)1b0000 = (cache: 91.8%)1bc000 (cache: 92.0%)1c8000 (cache: 92.1%)1d4000 = (cache: 92.2%)1e0000 (cache: 92.4%)1ec000 (cache: 92.5%)1f8000= (cache: 92.6%)204000 (cache: 92.7%)210000 (cache: 92.8%)21c= 000 (cache: 92.9%)228000 (cache: 92.9%)234000 (cache: 93.0%)= 240000 (cache: 93.1%)24c000 (cache: 93.2%)258000 (cache: 93.= 2%)264000 (cache: 93.3%)270000 (cache: 93.4%)27c000 (cache: = 93.4%)288000 (cache: 93.5%)294000 (cache: 93.5%)2a0000 (cach= e: 93.6%)2ac000 (cache: 93.6%)2b8000 (cache: 93.7%)2c4000 (c= ache: 93.7%)2d0000 (cache: 93.8%)2dc000 (cache: 93.8%)2e8000 = (cache: 93.8%)2f4000 (cache: 93.9%)300000 (cache: 93.9%)30c000 = (cache: 93.9%)318000 (cache: 94.0%)324000 (cache: 94.0%)33000= 0 (cache: 94.0%)33c000 (cache: 94.1%)348000 (cache: 94.1%)35= 4000 (cache: 94.1%)360000 (cache: 94.2%)36c000 (cache: 94.2%= )378000 (cache: 94.2%)384000 (cache: 94.2%)390000 (cache: 94= =2E3%)39c000 (cache: 94.3%)3a8000 (cache: 94.3%)3b4000 (cach= e: 94.3%)3c0000 (cache: 94.3%)3cc000 (cache: 94.4%)3d8000 (c= ache: 94.4%)3e4000 (cache: 94.4%)3f0000 (cache: 94.4%)3fc000 = (cache: 94.4%)408000 (cache: 94.5%)414000 (cache: 94.5%)420000 = (cache: 94.5%)42c000 (cache: 94.5%)438000 (cache: 94.5%)44400= 0 (cache: 94.5%)450000 (cache: 94.6%)45c000 (cache: 94.6%)46= 8000 (cache: 94.6%)474000 (cache: 94.6%)480000 (cache: 94.6%= )48c000 (cache: 94.6%)498000 (cache: 94.6%)Zeroing memory at 0x71= 0210, size =3D 0x0 Starting ELF64 kernel Linux version 2.6.24-rc2-gcd60878b-dirty (flo@firewall) (gcc version 4.2.2)= #1 Mon Nov 19 14:33:08 CET 2007 ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 console [early0] enabled CPU revision is: 00002321 (R5000) FPU revision is: 00002310 MC: SGI memory controller Revision 3 MC: Probing memory configuration: bank0: 32M @ 08000000 bank1: 32M @ 0a000000 Determined physical RAM map: memory: 0000000004000000 @ 0000000008000000 (usable) Wasting 1835008 bytes for tracking 32768 unused pages Initrd not found or empty - disabling initrd Built 1 zonelists in Zone order, mobility grouping on. Total pages: 48480 Kernel command line: root=3D/dev/sda2 Primary instruction cache 32kB, VIPT, 2-way, linesize 32 bytes. Primary data cache 32kB, 2-way, VIPT, cache aliases, linesize 32 bytes Synthesized clear page handler (15 instructions). Synthesized copy page handler (24 instructions). Synthesized TLB refill handler (38 instructions). Synthesized TLB load handler fastpath (51 instructions). Synthesized TLB store handler fastpath (51 instructions). Synthesized TLB modify handler fastpath (50 instructions). PID hash table entries: 1024 (order: 10, 8192 bytes) Calibrating system timer... 300000 [150.0000 MHz CPU] Using 75.000 MHz high precision timer. NG1: Revision 6, 8 bitplanes, REX3 revision B, VC2 revision A, xmap9 revisi= on A, cmap revision C, bt445 revision D NG1: Screensize 1024x768 Console: colour SGI Newport 128x48 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Memory: 57600k/65536k available (2925k kernel code, 7524k reserved, 955k da= ta, 272k init, 0k highmem) Security Framework initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 256 Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. net_namespace: 120 bytes NET: Registered protocol family 16 EISA bus registered SCSI subsystem initialized Time: MIPS clocksource has been installed. NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 2, 16384 bytes) TCP established hash table entries: 8192 (order: 5, 131072 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered audit: initializing netlink socket (disabled) audit(1195479647.784:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) Installing knfsd (copyright (C) 1996 okir@monad.swb.de). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) DS1286 Real Time Clock Driver v1.0 Serial: IP22 Zilog driver (1 chips). IP22 r4k 250Mhz Indigo2 2.6.24-rc2: arcsboot: ARCS Linux ext2fs loader 0.3.8.8 Loading linux2624 from scsi(1)disk(5)rdisk(0)partition(0) Allocated 0x70 bytes for segments Loading 64-bit executable Loading program segment 1 at 0x88004000, offset=3D0x0 4000, size =3D 0x0 40= e085 c000 (cache: 46.1%)18000 (cache: 69.3%)24000 (cache: 78.0%)3= 0000 (cache: 82.4%)3c000 (cache: 85.1%)48000 (cache: 86.8%)5= 4000 (cache: 88.1%)60000 (cache: 89.1%)6c000 (cache: 89.8%)7= 8000 (cache: 90.4%)84000 (cache: 90.9%)90000 (cache: 91.3%)9= c000 (cache: 91.6%)a8000 (cache: 91.9%)b4000 (cache: 92.2%)c= 0000 (cache: 92.4%)cc000 (cache: 92.6%)d8000 (cache: 92.8%)e= 4000 (cache: 92.9%)f0000 (cache: 93.1%)fc000 (cache: 93.2%)1= 08000 (cache: 93.3%)114000 (cache: 93.4%)120000 (cache: 93.5= %)12c000 (cache: 93.6%)138000 (cache: 93.7%)144000 (cache: 9= 3.8%)150000 (cache: 93.9%)15c000 (cache: 93.9%)168000 (cache= : 94.0%)174000 (cache: 94.0%)180000 (cache: 94.1%)18c000 (ca= che: 94.1%)198000 (cache: 94.2%)1a4000 (cache: 94.2%)1b0000 = (cache: 94.3%)1bc000 (cache: 94.3%)1c8000 (cache: 94.4%)1d4000 = (cache: 94.4%)1e0000 (cache: 94.4%)1ec000 (cache: 94.5%)1f8000= (cache: 94.5%)204000 (cache: 94.5%)210000 (cache: 94.6%)21c= 000 (cache: 94.6%)228000 (cache: 94.6%)234000 (cache: 94.6%)= 240000 (cache: 94.7%)24c000 (cache: 94.7%)258000 (cache: 94.= 7%)264000 (cache: 94.7%)270000 (cache: 94.7%)27c000 (cache: = 94.8%)288000 (cache: 94.8%)294000 (cache: 94.8%)2a0000 (cach= e: 94.8%)2ac000 (cache: 94.8%)2b8000 (cache: 94.9%)2c4000 (c= ache: 94.9%)2d0000 (cache: 94.9%)2dc000 (cache: 94.9%)2e8000 = (cache: 94.9%)2f4000 (cache: 94.9%)300000 (cache: 94.9%)30c000 = (cache: 95.0%)318000 (cache: 95.0%)324000 (cache: 95.0%)33000= 0 (cache: 95.0%)33c000 (cache: 95.0%)348000 (cache: 95.0%)35= 4000 (cache: 95.0%)360000 (cache: 95.0%)36c000 (cache: 95.0%= )378000 (cache: 95.1%)384000 (cache: 95.1%)390000 (cache: 95= =2E1%)39c000 (cache: 95.1%)3a8000 (cache: 95.1%)3b4000 (cach= e: 95.1%)3c0000 (cache: 95.1%)3cc000 (cache: 95.1%)3d8000 (c= ache: 95.1%)3e4000 (cache: 95.1%)3f0000 (cache: 95.1%)3fc000 = (cache: 95.1%)408000 (cache: 95.2%)414000 (cache: 95.2%)Zeroing = memory at 0x710210, size =3D 0x0 Starting ELF64 kernel Linux version 2.6.24-rc2-gcd60878b-dirty (flo@firewall) (gcc version 4.2.2)= #1 Mon Nov 19 14:33:08 CET 2007 ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 console [early0] enabled CPU revision is: 00000460 (R4400SC) FPU revision is: 00000500 MC: SGI memory controller Revision 3 MC: Probing memory configuration: bank0: 64M @ 10000000 bank1: 64M @ 14000000 bank2: 128M @ 08000000 Determined physical RAM map: memory: 0000000010000000 @ 0000000008000000 (usable) Wasting 1835008 bytes for tracking 32768 unused pages Initrd not found or empty - disabling initrd Built 1 zonelists in Zone order, mobility grouping on. Total pages: 96960 Kernel command line: root=3D/dev/sdf1 console=3DttyS0 auto Primary instruction cache 16kB, VIPT, direct mapped, linesize 16 bytes. Primary data cache 16kB, direct mapped, VIPT, cache aliases, linesize 16 by= tes Unified secondary cache 2048kB direct mapped, linesize 128 bytes. Synthesized clear page handler (22 instructions). Synthesized copy page handler (39 instructions). Synthesized TLB refill handler (38 instructions). Synthesized TLB load handler fastpath (50 instructions). Synthesized TLB store handler fastpath (50 instructions). Synthesized TLB modify handler fastpath (49 instructions). EISA: Probing bus... EISA: Detected 0 card. ISA support compiled in. PID hash table entries: 2048 (order: 11, 16384 bytes) Calibrating system timer... 500000 [250.0000 MHz CPU] Using 125.000 MHz high precision timer. Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Memory: 251104k/262144k available (2925k kernel code, 10628k reserved, 955k= data, 272k init, 0k highmem) IP22 R4k 100Mhz Indy - 2.6.24-rc2: Loading linux2624 from scsi(0)disk(1)rdisk(0)partition(0) Allocated 0x70 bytes for segments Loading 64-bit executable Loading program segment 1 at 0x88004000, offset=3D0x0 4000, size =3D 0x0 40= e085 c000 (cache: 44.0%)18000 (cache: 68.7%)24000 (cache: 77.7%)3= 0000 (cache: 82.2%)3c000 (cache: 85.0%)48000 (cache: 86.8%)5= 4000 (cache: 88.0%)60000 (cache: 89.0%)6c000 (cache: 89.8%)7= 8000 (cache: 90.4%)84000 (cache: 90.9%)90000 (cache: 91.3%)9= c000 (cache: 91.6%)a8000 (cache: 91.9%)b4000 (cache: 92.2%)c= 0000 (cache: 92.4%)cc000 (cache: 92.6%)d8000 (cache: 92.8%)e= 4000 (cache: 92.9%)f0000 (cache: 93.1%)fc000 (cache: 93.2%)1= 08000 (cache: 93.3%)114000 (cache: 93.4%)120000 (cache: 93.5= %)12c000 (cache: 93.6%)138000 (cache: 93.7%)144000 (cache: 9= 3.8%)150000 (cache: 93.8%)15c000 (cache: 93.9%)168000 (cache= : 94.0%)174000 (cache: 94.0%)180000 (cache: 94.1%)18c000 (ca= che: 94.1%)198000 (cache: 94.2%)1a4000 (cache: 94.2%)1b0000 = (cache: 94.3%)1bc000 (cache: 94.3%)1c8000 (cache: 94.4%)1d4000 = (cache: 94.4%)1e0000 (cache: 94.4%)1ec000 (cache: 94.5%)1f8000= (cache: 94.5%)204000 (cache: 94.5%)210000 (cache: 94.6%)21c= 000 (cache: 94.6%)228000 (cache: 94.6%)234000 (cache: 94.6%)= 240000 (cache: 94.7%)24c000 (cache: 94.7%)258000 (cache: 94.= 7%)264000 (cache: 94.7%)270000 (cache: 94.7%)27c000 (cache: = 94.8%)288000 (cache: 94.8%)294000 (cache: 94.8%)2a0000 (cach= e: 94.8%)2ac000 (cache: 94.8%)2b8000 (cache: 94.8%)2c4000 (c= ache: 94.9%)2d0000 (cache: 94.9%)2dc000 (cache: 94.9%)2e8000 = (cache: 94.9%)2f4000 (cache: 94.9%)300000 (cache: 94.9%)30c000 = (cache: 95.0%)318000 (cache: 95.0%)324000 (cache: 95.0%)33000= 0 (cache: 95.0%)33c000 (cache: 95.0%)348000 (cache: 95.0%)35= 4000 (cache: 95.0%)360000 (cache: 95.0%)36c000 (cache: 95.0%= )378000 (cache: 95.1%)384000 (cache: 95.1%)390000 (cache: 95= =2E1%)39c000 (cache: 95.1%)3a8000 (cache: 95.1%)3b4000 (cach= e: 95.1%)3c0000 (cache: 95.1%)3cc000 (cache: 95.1%)3d8000 (c= ache: 95.1%)3e4000 (cache: 95.1%)3f0000 (cache: 95.1%)3fc000 = (cache: 95.1%)408000 (cache: 95.2%)414000 (cache: 95.2%)Zeroing = memory at 0x710210, size =3D 0x0 Starting ELF64 kernel Linux version 2.6.24-rc2-gcd60878b-dirty (flo@firewall) (gcc version 4.2.2)= #1 Mon Nov 19 14:33:08 CET 2007 ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 console [early0] enabled CPU revision is: 00000430 (R4000SC) FPU revision is: 00000500 MC: SGI memory controller Revision 3 MC: Probing memory configuration: bank0: 64M @ 08000000 bank1: 64M @ 0c000000 Determined physical RAM map: memory: 0000000008000000 @ 0000000008000000 (usable) Wasting 1835008 bytes for tracking 32768 unused pages Initrd not found or empty - disabling initrd Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64640 Kernel command line: root=3D/dev/sda1 Primary instruction cache 8kB, VIPT, direct mapped, linesize 16 bytes. Primary data cache 8kB, direct mapped, VIPT, cache aliases, linesize 16 byt= es Unified secondary cache 1024kB direct mapped, linesize 128 bytes. Synthesized clear page handler (22 instructions). Synthesized copy page handler (39 instructions). Synthesized TLB refill handler (38 instructions). Synthesized TLB load handler fastpath (50 instructions). Synthesized TLB store handler fastpath (50 instructions). Synthesized TLB modify handler fastpath (49 instructions). PID hash table entries: 1024 (order: 10, 8192 bytes) Calibrating system timer... 200000 [100.0000 MHz CPU] Using 50.000 MHz high precision timer. NG1: Revision 3, 8 bitplanes, REX3 revision B, VC2 revision A, xmap9 revisi= on A, cmap revision C, bt445 revision A NG1: Screensize 1040x768 Console: colour SGI Newport 130x48 Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Memory: 122336k/131072k available (2925k kernel code, 8448k reserved, 955k = data, 272k init, 0k highmem) Kernel bug detected[#1]: Cpu 0 $ 0 : 0000000000000000 000000001400cce0 0000000000000001 0000000000000000 $ 4 : ffffffff8fc16140 00000000000000d0 00000000000000d0 0000000000000000 $ 8 : ffffffff8fc15000 0000000000000000 ffffffff8fc15030 0000000000000000 $12 : 0000000000100100 0000000000200200 ffffffff883f59a8 ffffffff883f59b8 $16 : ffffffff8fc15180 ffffffff8fc16140 00000000000000d0 ffffffff8fc16140 $20 : 0000000000000080 0000000000000000 0000000000042000 0000000000000000 $24 : 0000000000001463 0000000000000001 = =20 $28 : ffffffff88398000 ffffffff8839bde0 00000000000000d0 ffffffff8808bac8 Hi : 0000000000000000 Lo : 0000000000000080 epc : ffffffff8808bb5c cache_alloc_refill+0x8c/0x710 Not tainted ra : ffffffff8808bac8 kmem_cache_alloc+0xe0/0xe8 Status: 1400cce2 KX SX UX KERNEL EXL=20 Cause : 00000034 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=3Dffffffff88398000, task=3Dffffffff8839= c2a8) Stack : 00000000000000d0 0000000000000000 000000001400cce1 ffffffff88430000 00000000000000d0 ffffffff8fc16140 0000000000000080 0000000000000000 0000000000042000 0000000000042000 ffffffff8834c568 ffffffff8808bac8 ffffffff8fc16140 ffffffff88430000 ffffffff883acfa0 0000000000000080 ffffffff882da754 0000000000000080 0000000000000100 0000000000000000 ffffffff8fc16140 ffffffff8808cdb4 0000001e00000000 0000000000000000 0000000000000001 ffffffffffffff80 0000000000000000 0000000000000000 0000000000000000 0000000000000014 ffffffff883acfb0 ffffffff883f57f8 0000000000040000 ffffffff883acfa0 ffffffff883ad118 ffffffff88430058 ffffffff883f0000 ffffffff883b0000 ffffffff88430000 ffffffff883e69a0 ... Call Trace: [] cache_alloc_refill+0x8c/0x710 [] kmem_cache_alloc+0xe0/0xe8 [] setup_cpu_cache+0x64/0x168 [] kmem_cache_create+0x37c/0x548 [] kmem_cache_init+0x428/0x430 [] start_kernel+0x270/0x3d8 Code: 14e00002 24020001 2d620001 <00028036> dd720040 1240000d 00000000 = 8e030004 8e450000=20 Kernel panic - not syncing: Attempted to kill the idle task! --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little=20 security shall soon have neither - Benjamin Franklin --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQbVRUaz2rXW+gJcRAsqWAJ9cTvCVY8OP8DuJRdQElK+fKluH1QCgtu5m iq2DvF3KH460SIn+Q1f2qhg= =R2g6 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From mb@bu3sch.de Mon Nov 19 18:25:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 18:25:18 +0000 (GMT) Received: from static-ip-62-75-166-246.inaddr.intergenia.de ([62.75.166.246]:59799 "EHLO vs166246.vserver.de") by ftp.linux-mips.org with ESMTP id S20033641AbXKSSZK (ORCPT ); Mon, 19 Nov 2007 18:25:10 +0000 Received: from t1c9e.t.pppool.de ([89.55.28.158] helo=powermac.local) by vs166246.vserver.de with esmtpa (Exim 4.63) (envelope-from ) id 1IuBIh-0006Hb-QA; Mon, 19 Nov 2007 18:24:51 +0000 From: Michael Buesch To: "John W. Linville" Subject: Re: ohci-ssb driver on a Broadcom BCM5354 Date: Mon, 19 Nov 2007 19:23:56 +0100 User-Agent: KMail/1.9.6 Cc: Steve Brown , linux-mips@linux-mips.org References: <47408305.5090804@cortland.com> <20071118224752.GB12263@tuxdriver.com> In-Reply-To: <20071118224752.GB12263@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711191923.56471.mb@bu3sch.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mb@bu3sch.de Precedence: bulk X-list: linux-mips On Sunday 18 November 2007 23:47:52 John W. Linville wrote: > You probably want to make Michael Buesch aware of this issue. I'm not sure anyone really tested this beyond some insmod tests. I did not test this, as I don't have such a device. So if you have any patches to fix this, please send them. I'm certainly the wrong person who can fix this. ;) -- Greetings Michael. From ralf@linux-mips.org Mon Nov 19 18:48:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 18:48:41 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:61155 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20033904AbXKSSsj (ORCPT ); Mon, 19 Nov 2007 18:48:39 +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 lAJImcbF014446; Mon, 19 Nov 2007 18:48:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAJImbnH014445; Mon, 19 Nov 2007 18:48:37 GMT Date: Mon, 19 Nov 2007 18:48:37 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: futex_wake_op deadlock? Message-ID: <20071119184837.GA12287@linux-mips.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17531 X-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 16, 2007 at 03:52:47PM -0800, Kaz Kylheku wrote: > From time to time, on 2.6.17.7, I see a deadlock situation go off. The > soft lockup tick occurs in the middle of do_futex, which is heavily > inlined. The system is actually hosed; it's not one of those > recoverable CPU busy situations that can sometimes trigger the lockup > detector. Can you reproduce thing hang also if you're not running in a binary compat mode, that is either running o32 binaries on a 32-bit kernel or 64-bit binaries on a 64-bit kernel? Ralf From MAILER-DAEMON Mon Nov 19 19:19:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 19:19:42 +0000 (GMT) Received: from mail.rsmu.ru ([195.178.214.57]:13717 "EHLO rsmu.ru") by ftp.linux-mips.org with ESMTP id S20027162AbXKSTTe (ORCPT ); Mon, 19 Nov 2007 19:19:34 +0000 From: "linux administration" Subject: Confirmation Request (1498870506) To: "linux-mips" Date: Mon, 19 Nov 2007 22:16:18 +0300 Message-ID: X-ListServer: CommuniGate Pro LIST 4.3.12 MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R" Return-Path: <> X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: linux-feed@complife.ru Precedence: bulk X-list: linux-mips This is an automated message from the mailing list manager Somebody (probably you) have requested the subscribe(feed) operation for your address If you want to confirm this operation, use the Reply command in your mailer. Check that the Subject of the reply message contains the confirmation ID: 1498870506, the reply is directed to , and the 'From' address of your reply is . If you do not want to confirm the requested operation, simply do nothing All requests about this mailing list should be sent to From ralf@linux-mips.org Mon Nov 19 19:31:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 19:31:41 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:44728 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20034078AbXKSTbj (ORCPT ); Mon, 19 Nov 2007 19:31:39 +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 lAJJVcLL027339; Mon, 19 Nov 2007 19:31:38 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAJJVbMJ027338; Mon, 19 Nov 2007 19:31:37 GMT Date: Mon, 19 Nov 2007 19:31:37 +0000 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@linux-mips.org Subject: Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points Message-ID: <20071119193137.GA27317@linux-mips.org> References: <20071119160954.GA12244@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071119160954.GA12244@paradigm.rfc822.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 19, 2007 at 05:09:54PM +0100, Florian Lohoff wrote: > i am seeing strange issues with 64 Bit kernels IP22 on different > machines. This came up when i tried the debian distribution kernel > which fails for me on 2 machines. I still haven't sorted out all the workarounds for the read-from-compare bug in early R4000 / R4400 with the new time code. It may not be the issue that's hitting you but the new time code definately has the potencial to trigger the issue. Ralf From kaz@zeugmasystems.com Mon Nov 19 21:28:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 21:28:14 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:59305 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20034818AbXKSV2G convert rfc822-to-8bit (ORCPT ); Mon, 19 Nov 2007 21:28:06 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: futex_wake_op deadlock? Date: Mon, 19 Nov 2007 13:27:37 -0800 Message-ID: In-Reply-To: <20071119184837.GA12287@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: futex_wake_op deadlock? Thread-Index: Acgq3M3SscB26V6iT9WqOzIqyKCfJAAFKJyA From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Fri, Nov 16, 2007 at 03:52:47PM -0800, Kaz Kylheku wrote: > >> From time to time, on 2.6.17.7, I see a deadlock situation go off. >> The soft lockup tick occurs in the middle of do_futex, which is >> heavily inlined. The system is actually hosed; it's not one of those >> recoverable CPU busy situations that can sometimes trigger the lockup >> detector. > > Can you reproduce thing hang also if you're not running in a > binary compat > mode, that is either running o32 binaries on a 32-bit kernel or > 64-bit binaries on a 64-bit kernel? I have hacked up little a test program which hosed my board within seconds. The system is not completely hung. However: - I can't kill the test program with Ctrl-C. - I can log into the box with telnet. - If I run "ps aux" to see all processes, the ps command hangs partway through the table, and cannot be killed with Ctrl-C. - System hangs on soft reboot attempt; requires hard reset. The program basically uses several threads to beat up the FUTEX_WAKE_OP. The key trick is that there is an interfering thread which does a mmap/munmap on the futexes in parallel with the threads which are using them. . If I just stick the futexes into a permanently good memory location, nothing bad happens; the program just churns away taking up 400% of the CPU time across the four cores of the 1480. If you call the function with permanently bad addresses, nothing bad happens either; the syscalls bail nicely with EFAULT. The idea is to tickle some race condition or other bug in the interaction between futexes and mmap. I put a little delay into the interfering thread so that the memory is held in a good state most of the time, with a quick unmap/remap. We want the memory to be good most of the time, but an unmap to happen from time to time at an inopportune time, while the kernel is executing the futex code on one or more cores This needs to be compiled -pthread, obviously, and you need -lrt to link in the library for clock_nanosleep. #include #include #include #include #include #include #define FUTEX_WAIT 0 #define FUTEX_WAKE 1 #define FUTEX_FD 2 #define FUTEX_REQUEUE 3 #define FUTEX_CMP_REQUEUE 4 #define FUTEX_WAKE_OP 5 #define FUTEX_OP_SET 0 /* *(int *)UADDR2 = OPARG; */ #define FUTEX_OP_ADD 1 /* *(int *)UADDR2 += OPARG; */ #define FUTEX_OP_OR 2 /* *(int *)UADDR2 |= OPARG; */ #define FUTEX_OP_ANDN 3 /* *(int *)UADDR2 &= ~OPARG; */ #define FUTEX_OP_XOR 4 /* *(int *)UADDR2 ^= OPARG; */ #define FUTEX_OP_OPARG_SHIFT 8 /* Use (1 << OPARG) instead of OPARG. */ #define FUTEX_OP_CMP_EQ 0 /* if (oldval == CMPARG) wake */ #define FUTEX_OP_CMP_NE 1 /* if (oldval != CMPARG) wake */ #define FUTEX_OP_CMP_LT 2 /* if (oldval < CMPARG) wake */ #define FUTEX_OP_CMP_LE 3 /* if (oldval <= CMPARG) wake */ #define FUTEX_OP_CMP_GT 4 /* if (oldval > CMPARG) wake */ #define FUTEX_OP_CMP_GE 5 /* if (oldval >= CMPARG) wake */ #define NUM_THREADS 8 int futex_wake_op(int *addr1, int *addr2, int nr_wake_1, int nr_wake_2, int encoded_op) { syscall(SYS_futex, addr1, FUTEX_WAKE_OP, nr_wake_1, nr_wake_2, addr2, encoded_op); } int futex1 = 0, futex2 = 0; struct { int futex1; int futex2; } *shared; void *mapper(void *arg) { for (;;) { struct timespec delay; void *mem; delay.tv_sec = 0; delay.tv_nsec = 100000000; mem = mmap(0, 16384, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (mem == (void *) -1) { perror("mmap"); exit(EXIT_FAILURE); } shared = mem; clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &delay, 0); if (munmap(mem, 16384) < 0) { perror("munmap"); exit(EXIT_FAILURE); } } } void *waker(void *arg) { int rand_state = 1; for (;;) { int val = rand_r(&rand_state) & 0xFFFF; const int op = (FUTEX_OP_SET << 28) | (FUTEX_OP_CMP_GT << 24) | val; int result = futex_wake_op(&shared->futex1, &shared->futex2, 1, 1, op); if (result < 0 && errno != EFAULT) { perror("futex_wake_op"); exit(EXIT_FAILURE); } } /* notreached */ return 0; } int main(void) { int i; srand(1); for (i = 0; i < NUM_THREADS; i++) { pthread_t thr; void *(*func)(void *) = (i == 0) ? mapper : waker; int result = errno = pthread_create(&thr, 0, func, 0); if (result != 0) { perror("pthread_create"); return EXIT_FAILURE; } } pthread_exit(0); } From kaz@zeugmasystems.com Mon Nov 19 21:42:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 21:43:00 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:7851 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20034829AbXKSVmv convert rfc822-to-8bit (ORCPT ); Mon, 19 Nov 2007 21:42:51 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: futex_wake_op deadlock? Date: Mon, 19 Nov 2007 13:42:23 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: futex_wake_op deadlock? Thread-Index: Acgq3M3SscB26V6iT9WqOzIqyKCfJAAFKJyAAACnbWA= From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Earlier, I wrote: > I have hacked up little a test program which hosed my board within > seconds. The system is not completely hung. However: > > - I can't kill the test program with Ctrl-C. > - I can log into the box with telnet. > - If I run "ps aux" to see all processes, the ps command hangs partway > through the table, and cannot be killed with Ctrl-C. > - System hangs on soft reboot attempt; requires hard reset. Furthermore: my console loglevel was too high to see the crash on the serial console, but, surely enough, the syslog has this: Nov 19 14:19:57 [kernel] [14:19:57.846017] BUG: soft lockup detected on CPU#1! Nov 19 14:19:57 [kernel] [14:19:57.846051] Call Trace: Nov 19 14:19:58 [kernel] [14:19:57.846069] [] softlockup_tick+0x1bc/0x208 Nov 19 14:19:58 [kernel] [14:19:57.846112] [] update_process_times+0x9c/0xe8 Nov 19 14:19:58 [kernel] [14:19:57.846147] [] ll_local_timer_interrupt+0x94/0xa8 Nov 19 14:19:58 [kernel] [14:19:57.846180] [] ll_local_timer_interrupt+0x94/0xa8 Nov 19 14:19:58 [kernel] [14:19:57.846205] [] plat_irq_dispatch+0x120/0x1a0 Nov 19 14:19:58 [kernel] [14:19:57.846232] [] compat_sys_futex+0x0/0x188 Nov 19 14:19:58 [kernel] [14:19:57.846258] [] do_futex+0x8f8/0xb58 Nov 19 14:19:58 [kernel] [14:19:57.846281] [] tlb_do_page_fault_1+0x110/0x128 Nov 19 14:19:58 [kernel] [14:19:57.846317] [] do_futex+0x870/0xb58 Nov 19 14:19:58 [kernel] [14:19:57.846339] [] compat_sys_futex+0x0/0x188 Nov 19 14:19:58 [kernel] [14:19:57.846364] [] do_futex+0x288/0xb58 Nov 19 14:19:58 [kernel] [14:19:57.846385] [] do_futex+0x8f8/0xb58 Nov 19 14:19:58 [kernel] [14:19:57.846407] [] do_futex+0x87c/0xb58 Nov 19 14:19:58 [kernel] [14:19:57.846430] [] __alloc_pages+0x70/0x398 Nov 19 14:19:58 [kernel] [14:19:57.846456] [] try_to_wake_up+0x3c4/0x4f8 Nov 19 14:19:58 [kernel] [14:19:57.846489] [] __up_read+0xe8/0x130 Nov 19 14:19:58 [kernel] [14:19:57.846528] [] compat_sys_futex+0x84/0x188 Nov 19 14:19:58 [kernel] [14:19:57.846552] [] handle_sysn32+0x54/0xb0 Nov 19 14:19:58 [kernel] [14:19:57.846578] [] compat_sys_futex+0x0/0x188 From kaz@zeugmasystems.com Mon Nov 19 22:26:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Nov 2007 22:27:01 +0000 (GMT) Received: from mail.zeugmasystems.com ([70.79.96.174]:1967 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20034930AbXKSW0w convert rfc822-to-8bit (ORCPT ); Mon, 19 Nov 2007 22:26:52 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: "exportfs -a" -> stale NFS filehandle Date: Mon, 19 Nov 2007 14:26:24 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "exportfs -a" -> stale NFS filehandle Thread-Index: AcgnwCCtCdy5qIVVTMaI/zfLoW8HSAAAB8CwAM5jgNA= From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Last week, I wrote: > Ralf Baechle wrote: >> On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote: >> >>> After backing out the nfsutils patch, the diskless node does boot. >>> >>> However, the original "exportfs -a" problem comes back! >>> >>> So this problem is not resolved simply by using the correct compat >>> routine; it's deeper. >>> >>> Sigh. >> >> Thanks for testing anyway! > > I'm continuing to dig into the problem. > > The export logic doesn't even go through nfsctl() anyway, > which is why I > originally hadn't even suspected that syscall. > > The nfsexport() function in nfsutils first tries opening > "/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a > text-based protocol. Only if that interface doesn't exist does it fall > back on the nfsctl(NFSCTL_EXPORT, ...) interface. Basically, the export table is being mismanaged. Simply restarting NFS (service nfs restart) will cause this problem to appear. When the system is first booted up and NFS is started in runlevel 3 by the nfs init script, the exportfs command correctly populates the export table based on the /etc/exports file. However, after that, further management of the export table fails. Doing an "exportfs -a" clears it out. You can see the table in /proc/net/rpc/nfsd.export/content. Before the operation, the table has valid entries. After the operation, it simply clears out and stays empty. This is in spite of the fact that the exportfs command seems to be doing exactly what it did the first time when NFS was successfully started (i.e. it's a kernel problem; user space is doing the same thing that worked before). I verified that by turning on various additional tracing with sysctl (sunrpc.nfsd_debug), and I added some extra traces to the function that adds exports (svc_export_parse) to view the messages that are coming down the nfsd.fh/channel pipe in /proc. So the summary is that this problem appears to be some kind of corruption of the RPC cache for exports. I did see the kernel crash with an alignment exception once upon reproducing the problem, but haven't been able to repro that. From zzh.hust@gmail.com Tue Nov 20 01:06:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 01:07:01 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.177]:53297 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20035053AbXKTBGw (ORCPT ); Tue, 20 Nov 2007 01:06:52 +0000 Received: by wa-out-1112.google.com with SMTP id m16so2184705waf for ; Mon, 19 Nov 2007 17:06:39 -0800 (PST) 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=DLY1KFEzs7t0PUvtwSV11AfhuxmnkPOFTvIUmKAW0Cc=; b=LYtMiUoCvDbLZfIzGdjVHVfAPTy6DhhEZINrAnqVRZ1qgNd5SMFlXP4s1ZmXkmTkC+jGL38NbiXI37T7Hp9GDsH68U9w0WbVPrCwPOCW9hdAlkvkrNxB4+Tvtkd6+UxvRt3RzungDI9uynI6fmAIRVf3qfh9QcIfc+Wtr7Qze4k= 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=J0OnGD7fbO4OrAYuCe+vkCKWKeuGBLaQgq+Ezp8gBNlcdSXP2KfbZE9+ffaKF9NJnB4Fp9yyFaP2bxfsaWKysdIt4If54cqzMC8V57hevCF8Y6A1Gl8QgulwU8dOHgz+iRlgj3IZe5QDypQJNsPoo5vL88aB7Y/OkmjCTlFjro8= Received: by 10.114.153.18 with SMTP id a18mr466804wae.1195520799136; Mon, 19 Nov 2007 17:06:39 -0800 (PST) Received: by 10.114.168.15 with HTTP; Mon, 19 Nov 2007 17:06:39 -0800 (PST) Message-ID: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> Date: Tue, 20 Nov 2007 09:06:39 +0800 From: zhuzhenhua To: linux-mips Subject: how to use memory before kernel load address? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24399_24804143.1195520799125" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_24399_24804143.1195520799125 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello,all i want to place my kernel loadaddr=0x81008000 and set EBASE=0x81000000, it workes. but there is still some memory usable before 0x81000000, for example from 0x80100000 ~ 0x80200000 i have try to pass param as mem=1M@1M mem=16M@16M to the kernel, it seems only take the 0x8000000 ~ kernel_end as reserved. is there any other options to set the memory useable? ( my kernel version is 2.6.14) thanks for any hints zzh ------=_Part_24399_24804143.1195520799125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline hello,all
          i want to place my kernel loadaddr=0x81008000 and set EBASE=0x81000000, it workes.
         but there is still some memory usable before 0x81000000, for example from 0x80100000 ~ 0x80200000
         i have try to pass param as mem=1M@1M mem=16M@16M  to the kernel,  it seems only take the 0x8000000 ~ kernel_end as reserved.
         is there any other options to set the memory useable? ( my kernel version is 2.6.14)
         thanks for any hints


zzh
------=_Part_24399_24804143.1195520799125-- From joe@perches.com Tue Nov 20 02:02:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 02:02:18 +0000 (GMT) Received: from DSL022.labridge.com ([206.117.136.22]:54536 "EHLO perches.com") by ftp.linux-mips.org with ESMTP id S20035091AbXKTCCJ (ORCPT ); Tue, 20 Nov 2007 02:02:09 +0000 Received: from localhost.localdomain ([192.168.1.128]) by perches.com (8.9.3/8.9.3) with ESMTP id SAA32368; Mon, 19 Nov 2007 18:01:19 -0800 From: Joe Perches To: linux-kernel@vger.kernel.org Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: [PATCH 02/59] arch/mips: Add missing "space" Date: Mon, 19 Nov 2007 17:47:54 -0800 Message-Id: <1195523331-15303-3-git-send-email-joe@perches.com> X-Mailer: git-send-email 1.5.3.6.728.gea559 In-Reply-To: <1195523331-15303-2-git-send-email-joe@perches.com> References: 1234567 <1195523331-15303-1-git-send-email-joe@perches.com> <1195523331-15303-2-git-send-email-joe@perches.com> Message-Id: <23f0badf8dab73294c2aa142fafb9301ca843e88.1195454434.git.joe@perches.com> In-Reply-To: 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: 17538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: joe@perches.com Precedence: bulk X-list: linux-mips Signed-off-by: Joe Perches --- arch/mips/kernel/vpe.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/vpe.c b/arch/mips/kernel/vpe.c index 38bd33f..c06eb81 100644 --- a/arch/mips/kernel/vpe.c +++ b/arch/mips/kernel/vpe.c @@ -470,7 +470,7 @@ static int apply_r_mips_lo16(struct module *me, uint32_t *location, */ if (v != l->value) { printk(KERN_DEBUG "VPE loader: " - "apply_r_mips_lo16/hi16: " + "apply_r_mips_lo16/hi16: \t" "inconsistent value information\n"); return -ENOEXEC; } @@ -629,7 +629,7 @@ static void simplify_symbols(Elf_Shdr * sechdrs, break; case SHN_MIPS_SCOMMON: - printk(KERN_DEBUG "simplify_symbols: ignoring SHN_MIPS_SCOMMON" + printk(KERN_DEBUG "simplify_symbols: ignoring SHN_MIPS_SCOMMON " "symbol <%s> st_shndx %d\n", strtab + sym[i].st_name, sym[i].st_shndx); // .sbss section -- 1.5.3.5.652.gf192c From markus.gothe@27m.se Tue Nov 20 02:48:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 02:49:03 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:31916 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20035170AbXKTCsy (ORCPT ); Tue, 20 Nov 2007 02:48:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id A177C200A25B; Tue, 20 Nov 2007 03:48:50 +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 07262-01-86; Tue, 20 Nov 2007 03:48:50 +0100 (CET) Received: from [192.168.0.132] (cust.fiber-lan.vnet.lk.85.194.49.238.stunet.se [85.194.49.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 212F0200A1A4; Tue, 20 Nov 2007 03:48:50 +0100 (CET) In-Reply-To: <20071119193137.GA27317@linux-mips.org> References: <20071119160954.GA12244@paradigm.rfc822.org> <20071119193137.GA27317@linux-mips.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-323899059" Message-Id: <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se> Cc: Florian Lohoff , linux-mips@linux-mips.org Content-Transfer-Encoding: 7bit From: Markus Gothe Subject: Re: [SPAM] Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points Date: Tue, 20 Nov 2007 03:49:07 +0100 To: Ralf Baechle 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: 17539 X-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-5-323899059 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Afaik R4x00 is just semi-64bit in contrast to the R5K, which derives from the R10K. //Markus On 19 Nov 2007, at 20:31, Ralf Baechle wrote: > On Mon, Nov 19, 2007 at 05:09:54PM +0100, Florian Lohoff wrote: > >> i am seeing strange issues with 64 Bit kernels IP22 on different >> machines. This came up when i tried the debian distribution kernel >> which fails for me on 2 machines. > > I still haven't sorted out all the workarounds for the read-from- > compare > bug in early R4000 / R4400 with the new time code. It may not be the > issue that's hitting you but the new time code definately has the > potencial > to trigger the issue. > > Ralf > --Apple-Mail-5-323899059 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) iD8DBQFHQksj6I0XmJx2NrwRAvhCAKCozDd7YHHnx9NqFg4VruGHltsM+ACgg0lC MdljaQaJ2AQ6jeKaCaJle0k= =c4s3 -----END PGP SIGNATURE----- --Apple-Mail-5-323899059-- From markus.gothe@27m.se Tue Nov 20 02:51:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 02:51:15 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:37548 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20035173AbXKTCvG (ORCPT ); Tue, 20 Nov 2007 02:51:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DBF94200A1A9; Tue, 20 Nov 2007 03:51:05 +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 07579-01-100; Tue, 20 Nov 2007 03:51:05 +0100 (CET) Received: from [192.168.0.132] (cust.fiber-lan.vnet.lk.85.194.49.238.stunet.se [85.194.49.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 80348200A25B; Tue, 20 Nov 2007 03:51:05 +0100 (CET) In-Reply-To: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> References: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-324034404" Message-Id: <13D06144-B121-45D1-9A32-B2560785218C@27m.se> Cc: linux-mips Content-Transfer-Encoding: 7bit From: Markus Gothe Subject: Re: [SPAM] how to use memory before kernel load address? Date: Tue, 20 Nov 2007 03:51:22 +0100 To: zhuzhenhua 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: 17540 X-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-6-324034404 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Are you using a MTD, if so just create a partition there. //Markus On 20 Nov 2007, at 02:06, zhuzhenhua wrote: > hello,all > i want to place my kernel loadaddr=0x81008000 and set > EBASE=0x81000000, it workes. > but there is still some memory usable before 0x81000000, > for example from 0x80100000 ~ 0x80200000 > i have try to pass param as mem=1M@1M mem=16M@16M to the > kernel, it seems only take the 0x8000000 ~ kernel_end as reserved. > is there any other options to set the memory useable? ( my > kernel version is 2.6.14) > thanks for any hints > > > zzh --Apple-Mail-6-324034404 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) iD8DBQFHQkuq6I0XmJx2NrwRApHJAJ9z6jg4EoziqhtNmYRGuzAcuN8hDwCgkqnk QLM4b5Z39M1/RDBHxlLzwc0= =22ne -----END PGP SIGNATURE----- --Apple-Mail-6-324034404-- From david.kuk@entone.com Tue Nov 20 04:23:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 04:23:47 +0000 (GMT) Received: from wr-out-0506.google.com ([64.233.184.233]:57269 "EHLO wr-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20021609AbXKTEXi (ORCPT ); Tue, 20 Nov 2007 04:23:38 +0000 Received: by wr-out-0506.google.com with SMTP id 67so821610wri for ; Mon, 19 Nov 2007 20:22:31 -0800 (PST) Received: by 10.142.140.14 with SMTP id n14mr1383343wfd.1195532550378; Mon, 19 Nov 2007 20:22:30 -0800 (PST) Received: by 10.142.169.11 with HTTP; Mon, 19 Nov 2007 20:22:30 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 12:22:30 +0800 From: "David Kuk" To: "David Daney" Subject: Re: smp8634 add memory at dram1 Cc: linux-mips@linux-mips.org In-Reply-To: <473B1DD0.2090903@avtrex.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17367_11062483.1195532550383" References: <473AB56B.2070107@entone.com> <473B1DD0.2090903@avtrex.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: 17541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david.kuk@entone.com Precedence: bulk X-list: linux-mips ------=_Part_17367_11062483.1195532550383 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks you all for helping. AS Daney suggested, I have map the dram1's first 64 MB memory (total 128) to remap register 3, and add the remap register 3 into the BOOT_MEMROY_RAM use the method add_memory_region. When i bootup the linux kernel print out that it have totally 176MB ram , which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at remap register3). How ever, This mapping shows that the total memory in the linux kernel is not contiguous. the OS can run, but as i see the source code, when the kernel divided these memory into pages, it did not consider if the memory is contiguous or not, is it ok ? and how should i allocate the memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all the 176MB memory can be allocate as ZONE[DMA]? Best wishes David On 11/15/07, David Daney wrote: > > David Kuk wrote: > > After study about the memory configuration of sigma smp8634, i found > > some difficult to accomplish the task. > > > > so my question is if have two 128MB ram separately under dram0 and > > dram1 controller, where dram0 for linux and dram1 for video decoding. > > Now the situation is the memory for linux is not enough and video > > decoding can not use all of it's 128MB at dram1, what we plan to do is > > to share 64MB at dram1 to the linux kernel as high memory, and only > > reserved 64MB at dram1 for the video decoding. > > > > first, in MIPS architecture, we found that the kseg0 and kseg1 are > > mapped to 0x00000000-0x20000000, which include only dram0 controller, > > so we wish to add the dram1 memory manually to the kernel using > > function add_memory_region at setup.c , after booting up result the > > warning that the memory larger than 512 need to configured the kernel > > support high memory. > > > > then when we configure the kernel to support high memory at menu > > configure, the kernel when booting up will remind us our CPU do not > > support high memory due to cache aliases. > > > > Both way will lead the linux can not boot up normally, so what should > > we do, is there any mis-understanding about the hardware > > implementation or MIPS design? > > I think your understanding of the 8634 is at least close to correct. > > It may be possible (but I have not tried it yet) to use the remapping > registers to move dram1 into the first 512MB of the memory space. If it > is possible, you would then have to modify the gbus access functions > accordingly. Also the 8634 media drivers would probably have to be > changed as well. I am not sure about the microcode for the media DSPs, > but if it is dependent on the mapping of the DRAM, then you would > probably have to get the vendor's help. > > Let me know if you are successful. > > Thanks, > David Daney > > ------=_Part_17367_11062483.1195532550383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks you all for helping.

AS Daney suggested, I have map the dram1's first 64 MB memory (total 128) to remap register 3,
and add the remap register 3 into the BOOT_MEMROY_RAM use the method add_memory_region.
When i bootup the linux kernel print out that it have totally 176MB ram , which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at remap register3). How ever, This mapping shows that the total memory in the linux kernel is not contiguous. the OS can run, but as i see the source code, when the kernel divided these memory into pages, it did not consider  if the memory is contiguous or not, is it ok ? and  how should i  allocate the memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all the 176MB memory can be allocate as ZONE[DMA]?


Best wishes
David




On 11/15/07, David Daney <ddaney@avtrex.com> wrote:
David Kuk wrote:
> After study about the memory configuration of sigma smp8634, i found
> some difficult to accomplish the task.
>
> so my question is if have two 128MB ram separately under dram0 and
> dram1 controller, where dram0 for linux and dram1 for video decoding.
> Now the situation is the memory for linux is not enough and video
> decoding can not use all of it's 128MB at dram1, what we plan to do is
> to share 64MB at dram1 to the linux kernel as high memory, and only
> reserved 64MB at dram1 for the video decoding.
>
> first, in MIPS architecture, we found that the kseg0 and kseg1 are
> mapped to 0x00000000-0x20000000, which include only dram0 controller,
> so we wish to add the dram1 memory manually to the kernel using
> function add_memory_region at setup.c , after booting up result the
> warning that the memory larger than 512 need to configured the kernel
> support high memory.
>
> then when we configure the kernel to support high memory at menu
> configure, the kernel when booting up will remind us our CPU do not
> support high memory due to cache aliases.
>
> Both way will lead the linux can not boot up normally, so what should
> we do, is there any mis-understanding about the hardware
> implementation or MIPS design?

I think your understanding of the 8634 is at least close to correct.

It may be possible (but I have not tried it yet) to use the remapping
registers to move dram1 into the first 512MB of the memory space.  If it
is possible, you would then have to modify the gbus access functions
accordingly.  Also the 8634 media drivers would probably have to be
changed as well.  I am not sure about the microcode for the media DSPs,
but if it is dependent on the mapping of the DRAM, then you would
probably have to get the vendor's help.

Let me know if you are successful.

Thanks,
David Daney


------=_Part_17367_11062483.1195532550383-- From share.kt@gmail.com Tue Nov 20 06:39:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 06:39:47 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.181]:61348 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20023566AbXKTGjh (ORCPT ); Tue, 20 Nov 2007 06:39:37 +0000 Received: by wa-out-1112.google.com with SMTP id m16so2258501waf for ; Mon, 19 Nov 2007 22:39:26 -0800 (PST) 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:cc:mime-version:content-type; bh=ykgqxqYmkYOAssyTf1g4BM2JoF4kjk9+u4w/BC2YaQM=; b=jbJ7LFyD6EfkLPSWbfSm5Ph8EAvCrgv4gUw6uvGqlscp+/AdjCVbJFSDLYvvp1equ1DEwqQSf7/O2gCxglU/A9c77lVu/o1VUUbyRhytt825ZNdQOvptmOs9jRjMalaYKUhPwKY4fbTrSywTWtDe1qIs57YAjUMG4hnnYiUSBoo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=BMCvFSKscZ7GaksxRcnLUhu9CxVVLABOHm3ZmVYXnK1xTiRypjiSPrcB/+7qIFwC6Kp9k+KeCVX7msvSEYLwkyLBtVZ3ucXq2su+ph8K6nMl+qA4zTenZejkieTG7OIISiQxeYAwRCSi3fTakgaIEt1HzA89NzXavswgNjQYovc= Received: by 10.114.149.2 with SMTP id w2mr314830wad.1195540766175; Mon, 19 Nov 2007 22:39:26 -0800 (PST) Received: by 10.114.158.17 with HTTP; Mon, 19 Nov 2007 22:39:26 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 12:09:26 +0530 From: kaka To: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net Subject: Usage of mmap command Cc: directfb-users@directfb.org, directfb-dev@directfb.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21593_1843271.1195540766162" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_21593_1843271.1195540766162 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset); I am providing 16,00,000 as length parameter in mmap command. It is giving me error as Can't mmap region. on the other hand when i am providing 9,00,000 as length parameter in mmap command. It is successful. This mmap command is being issued from User space. On the other hand in the framebuffer driver in the kernel spce i have specified the length of mmio in the ioremap as 16,00,000. Can anybody provide any clue on it? I want to access the mmio regs at offset ( 0 to 16,00,000). -- Thanks & Regards, kaka ------=_Part_21593_1843271.1195540766162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
void *mmap(void *start, size_t length, int prot, int flags,           int
fd, off_t offset);
 
I am providing 16,00,000 as length parameter in mmap command.
It is giving me error as Can't mmap region. on the other hand when i am providing 9,00,000 as length parameter in mmap command.
It is successful.
This mmap command is being issued from User space.
 
On the other hand in the framebuffer driver in the kernel spce i have specified the length of mmio in the ioremap as 16,00,000.
 
Can anybody provide any clue on it?
I want to access the mmio regs at offset ( 0 to  16,00,000).

--
Thanks & Regards,
kaka
------=_Part_21593_1843271.1195540766162-- From tsbogend@alpha.franken.de Tue Nov 20 08:18:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 08:19:05 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:50057 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20026053AbXKTIS4 (ORCPT ); Tue, 20 Nov 2007 08:18:56 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IuOJo-00069F-00; Tue, 20 Nov 2007 09:18:52 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 47953C2DE7; Tue, 20 Nov 2007 09:18:35 +0100 (CET) Date: Tue, 20 Nov 2007 09:18:35 +0100 To: Markus Gothe Cc: Ralf Baechle , Florian Lohoff , linux-mips@linux-mips.org Subject: Re: [SPAM] Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points Message-ID: <20071120081834.GA8627@alpha.franken.de> References: <20071119160954.GA12244@paradigm.rfc822.org> <20071119193137.GA27317@linux-mips.org> <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se> 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: 17543 X-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 Tue, Nov 20, 2007 at 03:49:07AM +0100, Markus Gothe wrote: > Afaik R4x00 is just semi-64bit in contrast to the R5K, which derives > from the R10K. how about reading documents ? Early R4k have ugly bugs in 64bit mode, but starting with rev5 they run 64bit code pretty well. And R5k does in no way derive from R10k. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From dok@directfb.org Tue Nov 20 08:33:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 08:33:09 +0000 (GMT) Received: from directfb.org ([212.227.87.76]:31483 "EHLO www.directfb.org") by ftp.linux-mips.org with ESMTP id S20026795AbXKTIdA (ORCPT ); Tue, 20 Nov 2007 08:33:00 +0000 Received: from [88.134.87.7] (helo=[10.1.1.6]) by www.directfb.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IuOUI-0006z5-Ri; Tue, 20 Nov 2007 09:29:42 +0100 Message-ID: <47429AEF.3010403@directfb.org> Date: Tue, 20 Nov 2007 09:29:35 +0100 From: Denis Oliver Kropp User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: kaka CC: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org Subject: Re: [directfb-dev] Usage of mmap command References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dok@directfb.org Precedence: bulk X-list: linux-mips kaka wrote: > Hi All, > > void *mmap(void *start, size_t length, int prot, int flags, int > fd, off_t offset); > > I am providing 16,00,000 as length parameter in mmap command. > It is giving me error as Can't mmap region. on the other hand when i am > providing 9,00,000 as length parameter in mmap command. > It is successful. > This mmap command is being issued from User space. > > On the other hand in the framebuffer driver in the kernel spce i have > specified the length of mmio in the ioremap as 16,00,000. The ioremap() is independent of the values propagated to user space and fbmem.c via fix.mmio_start and fix.mmio_len, please check these. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From share.kt@gmail.com Tue Nov 20 09:40:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 09:40:59 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.239]:13863 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20023798AbXKTJkv (ORCPT ); Tue, 20 Nov 2007 09:40:51 +0000 Received: by nz-out-0506.google.com with SMTP id n1so1520782nzf for ; Tue, 20 Nov 2007 01:40:39 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:references; bh=m78fUfcuddF2cykoHWIbV7X2MMthHNtq6MfkAvm/ZLc=; b=howHKGq4CSlVslL9XMHrEc6edlbaLCPSiEPoQWOZWGDzAqCHlQGz3ttFFm4IeVepXe4Yv25ouYok7ZtBLuCX1A3HE65KQrCzkTKMLLE7r7MaArk+l/ZVKjzHz8BCeodWzYBFN9XFEB8k6MCO+m1QJ30G4IADATUmKKKT+RlBB0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=JsIWxAy1eeCox2yjTxcZtETVc0oI6zj9mGlYU+NTuVCYi45oRV4PzMMYRspWmT66H8FbgN4erlXZjfjsi6ujrYSkbTvtVaSlBkuX1tzcUhH4TdkcPYRCKJ3UnbfU8J8/3UJg4DMCf+rFrA5twA6Teh4vGzb7VBYFemXVYwkQzkY= Received: by 10.114.75.1 with SMTP id x1mr639150waa.1195551637161; Tue, 20 Nov 2007 01:40:37 -0800 (PST) Received: by 10.114.158.17 with HTTP; Tue, 20 Nov 2007 01:40:36 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 15:10:36 +0530 From: kaka To: "Denis Oliver Kropp" Subject: Usage of mmap command Cc: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org In-Reply-To: <47429AEF.3010403@directfb.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21958_9268475.1195551637153" References: <47429AEF.3010403@directfb.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_21958_9268475.1195551637153 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Denis, Thanks for the reply. I am writing gfxdriver for directFB library for broadcom chip. I have also written a frambuffer driver for broadcom chip. In directFB code, static volatile void * system_map_mmio( unsigned int offset, int length ) { void *addr; if (length <= 0) length = dfb_fbdev->shared->fix.mmio_len; addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset ); if ((int)(addr) == -1) { D_PERROR( "DirectFB/FBDev: Could not mmap MMIO region " "(offset %d, length %d)!\n", offset, length ); return NULL; } return(volatile void*) ((u8*) addr + (dfb_fbdev->shared->fix.mmio_start& dfb_fbdev->shared->page_mask)); } the length and offset i am providing as 0 and -1. It is throwing me error as Could not mmap MMIO region. length coming from dfb_fbdev->shared->fix.smem_len is 16,00,000. When i change the code to addr = mmap( NULL, 900000, PROT_READ | PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset ); Then it works fine but it is not allowing me to write to addresses with offset greater than 900000. My requirement is to write in to the MMIO registers with offset between 900000 and 16 00 000. Could you please help me in htis regard? Thanks in Advance. On 11/20/07, Denis Oliver Kropp wrote: > > kaka wrote: > > Hi All, > > > > void *mmap(void *start, size_t length, int prot, int flags, > int > > fd, off_t offset); > > > > I am providing 16,00,000 as length parameter in mmap command. > > It is giving me error as Can't mmap region. on the other hand when i am > > providing 9,00,000 as length parameter in mmap command. > > It is successful. > > This mmap command is being issued from User space. > > > > On the other hand in the framebuffer driver in the kernel spce i have > > specified the length of mmio in the ioremap as 16,00,000. > > The ioremap() is independent of the values propagated to user space > and fbmem.c via fix.mmio_start and fix.mmio_len, please check these. > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > -- Thanks & Regards, kaka ------=_Part_21958_9268475.1195551637153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Denis,
 
Thanks for the reply.
I am writing gfxdriver for directFB library for broadcom chip.
I have also written a frambuffer driver for broadcom chip.
In directFB code,

static volatile void *
system_map_mmio( unsigned int    offset,
                 int             length )
{
     void *addr;

     if (length <= 0)
          length = dfb_fbdev->shared->fix.mmio_len;

     addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED,
                  dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset );
     if ((int)(addr) == -1) {
          D_PERROR( "DirectFB/FBDev: Could not mmap MMIO region "
                     "(offset %d, length %d)!\n", offset, length );
          return NULL;
     }

     return(volatile void*) ((u8*) addr + (dfb_fbdev->shared->fix.mmio_start &
                                           dfb_fbdev->shared->page_mask));
}

 

the length and offset i am providing as 0 and -1.
It is throwing me error as Could not mmap MMIO region.
length coming from dfb_fbdev->shared->fix.smem_len is 16,00,000.
When i change the code to  addr = mmap( NULL, 900000, PROT_READ | PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset );
Then it works fine but it is not allowing me to write to addresses with offset greater than 900000.
 
My requirement is to write in to the MMIO registers with offset between 900000 and 16 00 000.
 
Could you please help me in htis regard?
 
Thanks in Advance.
 


 
On 11/20/07, Denis Oliver Kropp <dok@directfb.org> wrote:
kaka wrote:
> Hi All,
>
> void *mmap(void *start, size_t length, int prot, int flags,           int
> fd, off_t offset);
>
> I am providing 16,00,000 as length parameter in mmap command.
> It is giving me error as Can't mmap region. on the other hand when i am
> providing 9,00,000 as length parameter in mmap command.
> It is successful.
> This mmap command is being issued from User space.
>
> On the other hand in the framebuffer driver in the kernel spce i have
> specified the length of mmio in the ioremap as 16,00,000.

The ioremap() is independent of the values propagated to user space
and fbmem.c via fix.mmio_start and fix.mmio_len, please check these.

--
Best regards,
Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"



--
Thanks & Regards,
kaka ------=_Part_21958_9268475.1195551637153-- From dok@directfb.org Tue Nov 20 10:46:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 10:46:38 +0000 (GMT) Received: from directfb.org ([212.227.87.76]:44506 "EHLO www.directfb.org") by ftp.linux-mips.org with ESMTP id S20029764AbXKTKqK (ORCPT ); Tue, 20 Nov 2007 10:46:10 +0000 Received: from [88.134.87.7] (helo=[10.1.1.6]) by www.directfb.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IuQZB-0003PJ-7V; Tue, 20 Nov 2007 11:42:53 +0100 Message-ID: <4742BA25.9070208@directfb.org> Date: Tue, 20 Nov 2007 11:42:45 +0100 From: Denis Oliver Kropp User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: kaka CC: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net, directfb-users@directfb.org, directfb-dev@directfb.org Subject: Re: Usage of mmap command References: <47429AEF.3010403@directfb.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dok@directfb.org Precedence: bulk X-list: linux-mips kaka wrote: > Hi Denis, > > Thanks for the reply. > I am writing gfxdriver for directFB library for broadcom chip. > I have also written a frambuffer driver for broadcom chip. Directly for broadcom or at another company? > In directFB code, > > static volatile void * > system_map_mmio( unsigned int offset, > int length ) > { > void *addr; > > if (length <= 0) > length = dfb_fbdev->shared->fix.mmio_len; > > addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED, > dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + offset ); > if ((int)(addr) == -1) { > D_PERROR( "DirectFB/FBDev: Could not mmap MMIO region " > "(offset %d, length %d)!\n", offset, length ); > return NULL; > } > > return(volatile void*) ((u8*) addr + (dfb_fbdev->shared->fix.mmio_start& > dfb_fbdev->shared->page_mask)); > } Can you add printfs to show dfb_fbdev->shared->fix.mmio_start, mmio_len, smem_start and smem_len? > the length and offset i am providing as 0 and -1. You mean offset 0 and length -1? > It is throwing me error as Could not mmap MMIO region. > length coming from dfb_fbdev->shared->fix.smem_len is 16,00,000. 1600000 = 1.6MB? > When i change the code to addr = mmap( NULL, 900000, PROT_READ | > PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, dfb_fbdev->shared->fix.smem_len + > offset ); You changed the length to 900000, but you need to use this to map offset 900000: addr = mmap( NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED, dfb_fbdev->fd, 900000 ); But it should work if you set smem_len to 900000 in the fb driver. > Then it works fine but it is not allowing me to write to addresses with > offset greater than 900000. Segfault? > My requirement is to write in to the MMIO registers with offset between > 900000 and 16 00 000. What exactly is your frame buffer size and physical MMIO address? You need to put the frame buffer size into smem_len and the physical MMIO address into mmio_start, the length into mmio_len. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From ralf@linux-mips.org Tue Nov 20 11:22:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 11:22:09 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:42219 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20032015AbXKTLWH (ORCPT ); Tue, 20 Nov 2007 11:22:07 +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 lAKBLHGo012079; Tue, 20 Nov 2007 11:21:17 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAKBL3VI012023; Tue, 20 Nov 2007 11:21:03 GMT Date: Tue, 20 Nov 2007 11:21:03 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: futex_wake_op deadlock? Message-ID: <20071120112051.GB30675@linux-mips.org> References: <20071119184837.GA12287@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17547 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 19, 2007 at 01:27:37PM -0800, Kaz Kylheku wrote: > >> From time to time, on 2.6.17.7, I see a deadlock situation go off. > >> The soft lockup tick occurs in the middle of do_futex, which is > >> heavily inlined. The system is actually hosed; it's not one of those > >> recoverable CPU busy situations that can sometimes trigger the lockup > >> detector. > > > > Can you reproduce thing hang also if you're not running in a > > binary compat > > mode, that is either running o32 binaries on a 32-bit kernel or > > 64-bit binaries on a 64-bit kernel? > > I have hacked up little a test program which hosed my board within > seconds. > The system is not completely hung. However: Cute. So looking again at the futex code this morning it was quite obvious what happened. The ll/sc loops in __futex_atomic_op() had the usual fixups necessary for memory acccesses to userspace from kernel space installed: __asm__ __volatile__( " .set push \n" " .set noat \n" " .set mips3 \n" "1: ll %1, %4 # __futex_atomic_op \n" " .set mips0 \n" " " insn " \n" " .set mips3 \n" "2: sc $1, %2 \n" " beqz $1, 1b \n" __WEAK_LLSC_MB "3: \n" " .set pop \n" " .set mips0 \n" " .section .fixup,\"ax\" \n" "4: li %0, %6 \n" " j 2b \n" <----- " .previous \n" " .section __ex_table,\"a\" \n" " "__UA_ADDR "\t1b, 4b \n" " "__UA_ADDR "\t2b, 4b \n" " .previous \n" : "=r" (ret), "=&r" (oldval), "=R" (*uaddr) : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT) : "memory"); Notice the branch at the end of the fixup code, it goes back to the SC instruction. The SC instruction took an exception so it will not have changed $1 so the loop will continue endless unless by coincidence the value to be stored from $1 happened to be zero. Obviously this one was MIPS specific and may hit all supported ABIs. So my initial suspicion this might be the issue David Miller recently discovered in the binary compat code isn't true. And it's a local DoS probably for all of 2.6.16 and up. Patch below. It fixes your test case on a 32-bit kernel for me. Ralf Signed-off-by: Ralf Baechle diff --git a/include/asm-mips/futex.h b/include/asm-mips/futex.h index 3e7e30d..17f082c 100644 --- a/include/asm-mips/futex.h +++ b/include/asm-mips/futex.h @@ -35,7 +35,7 @@ " .set mips0 \n" \ " .section .fixup,\"ax\" \n" \ "4: li %0, %6 \n" \ - " j 2b \n" \ + " j 3b \n" \ " .previous \n" \ " .section __ex_table,\"a\" \n" \ " "__UA_ADDR "\t1b, 4b \n" \ @@ -61,7 +61,7 @@ " .set mips0 \n" \ " .section .fixup,\"ax\" \n" \ "4: li %0, %6 \n" \ - " j 2b \n" \ + " j 3b \n" \ " .previous \n" \ " .section __ex_table,\"a\" \n" \ " "__UA_ADDR "\t1b, 4b \n" \ From ralf@linux-mips.org Tue Nov 20 11:39:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 11:39:35 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:32977 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20029049AbXKTLjd (ORCPT ); Tue, 20 Nov 2007 11:39:33 +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 lAKBdWA2012585; Tue, 20 Nov 2007 11:39:32 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAKBdVZt012584; Tue, 20 Nov 2007 11:39:31 GMT Date: Tue, 20 Nov 2007 11:39:31 +0000 From: Ralf Baechle To: Markus Gothe Cc: Florian Lohoff , linux-mips@linux-mips.org Subject: Re: [SPAM] Re: IP22 64Bit arcboot - current git crashes on 3 machines at different points Message-ID: <20071120113931.GA12018@linux-mips.org> References: <20071119160954.GA12244@paradigm.rfc822.org> <20071119193137.GA27317@linux-mips.org> <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <775F4404-2D0A-4E65-9401-E2193B96DBDC@27m.se> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 20, 2007 at 03:49:07AM +0100, Markus Gothe wrote: > Afaik R4x00 is just semi-64bit in contrast to the R5K, which derives from > the R10K. Total rubbish. The R4x00 family hardly is a family but just happens to have similar type numbers. o R4000/R4400 are very close related, 64-bit databus o R4100, R4200, R4300 series only have 32-bit databus and are low end embedded stuff. All these have 32-bit external busses only. o R4600 was designed by Qed shortly after the R4000 was developed by MIPS. It has a much shorted pipeline, consumes less power and performs better except for the most heavy FP apps. The R4700 is a slightly improved version of the R4600 and catches up on FP too but was rarely used. o R5000 has alot of similarities to the R4600/R4700 and was also designed by QED. Not sure if it really should be considered a derivate of these. The RM7000 and RM9000 family eventually continued this line of evolution. o R10000 is a no-prisoners-taken from scratch OOO CPU design released in '94 and to become SGI's highend processor. The architecture is aggressive to the point where it even today looks complex - but that also means that the R10000 implementation have hardly any similarity with their predecessors. The R12000 is a slightly beefed up shrink of the R10000, the R14000 is the same to the R12000 and the R16000 is one more shrink. Conventional wisdom is that the 2nd shrink already going to return diminishing returns but it seems to have worked for SGI. And of course all these are are MIPS III/MIPS IV processors, so modulo bugs and sanity fully 64-bit software capable. Ralf From ths@networkno.de Tue Nov 20 13:05:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 13:05:37 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:33760 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20039490AbXKTNF3 (ORCPT ); Tue, 20 Nov 2007 13:05:29 +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 651DE48BD9; Tue, 20 Nov 2007 14:04:53 +0100 (CET) Received: from ths by lagash with local (Exim 4.68) (envelope-from ) id 1IuSmZ-00030Q-Vs; Tue, 20 Nov 2007 13:04:51 +0000 Date: Tue, 20 Nov 2007 13:04:51 +0000 From: Thiemo Seufer To: zhuzhenhua Cc: linux-mips Subject: Re: how to use memory before kernel load address? Message-ID: <20071120130451.GI11996@networkno.de> References: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> 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: 17549 X-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 zhuzhenhua wrote: > hello,all > i want to place my kernel loadaddr=0x81008000 and set > EBASE=0x81000000, it workes. > but there is still some memory usable before 0x81000000, for > example from 0x80100000 ~ 0x80200000 The obvious thing to do seems to set LOARADDR to 0x80208000. > i have try to pass param as mem=1M@1M mem=16M@16M to the kernel, > it seems only take the 0x8000000 ~ kernel_end as reserved. > is there any other options to set the memory useable? ( my kernel > version is 2.6.14) > thanks for any hints AFAIR the kernel assumes to occupy the lowest addresses of the usable RAM. Thiemo From anemo@mba.ocn.ne.jp Tue Nov 20 13:44:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 13:44:15 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:50655 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20041004AbXKTNoH (ORCPT ); Tue, 20 Nov 2007 13:44:07 +0000 Received: from localhost (p2098-ipad211funabasi.chiba.ocn.ne.jp [58.91.158.98]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id C80E399BF; Tue, 20 Nov 2007 22:42:45 +0900 (JST) Date: Tue, 20 Nov 2007 22:44:57 +0900 (JST) Message-Id: <20071120.224457.108739276.anemo@mba.ocn.ne.jp> To: ths@networkno.de Cc: zzh.hust@gmail.com, linux-mips@linux-mips.org Subject: Re: how to use memory before kernel load address? From: Atsushi Nemoto In-Reply-To: <20071120130451.GI11996@networkno.de> References: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> <20071120130451.GI11996@networkno.de> 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: 17550 X-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 Tue, 20 Nov 2007 13:04:51 +0000, Thiemo Seufer wrote: > > i have try to pass param as mem=1M@1M mem=16M@16M to the kernel, > > it seems only take the 0x8000000 ~ kernel_end as reserved. > > is there any other options to set the memory useable? ( my kernel > > version is 2.6.14) > > thanks for any hints > > AFAIR the kernel assumes to occupy the lowest addresses of the usable RAM. You can use prom_free_prom_memory() to give some low pages back to kernel. --- Atsushi Nemoto From kaz@zeugmasystems.com Tue Nov 20 18:06:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 18:07:02 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:6604 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20029780AbXKTSGx convert rfc822-to-8bit (ORCPT ); Tue, 20 Nov 2007 18:06:53 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: futex_wake_op deadlock? Date: Tue, 20 Nov 2007 10:06:44 -0800 Message-ID: In-Reply-To: <20071120112051.GB30675@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: futex_wake_op deadlock? Thread-Index: AcgrZ5b0yPwptPInTAa6l6KjBurCtwAN3L6w From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17551 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > __asm__ __volatile__( > " .set push \n" > " .set noat \n" > " .set mips3 \n" > "1: ll %1, %4 # __futex_atomic_op \n" > " .set mips0 \n" > " " insn " \n" > " .set mips3 \n" > "2: sc $1, %2 \n" > " beqz $1, 1b \n" > __WEAK_LLSC_MB "3: > \n" " .set pop \n" > " .set mips0 \n" > " .section .fixup,\"ax\" \n" > "4: li %0, %6 \n" > " j 2b \n" <----- > " .previous \n" > " .section __ex_table,\"a\" \n" > " "__UA_ADDR "\t1b, 4b \n" > " "__UA_ADDR "\t2b, 4b \n" > " .previous \n" > : "=r" (ret), "=&r" (oldval), "=R" (*uaddr) > : "0" (0), "R" (*uaddr), "Jr" (oparg), "i" (-EFAULT) > : "memory"); > > Notice the branch at the end of the fixup code, it goes back to the > SC instruction. Hi Ralf, I had gone through all that code, but didn't see it! The problem is I didn't pay enough attention because I didn't suspect it enough. I was misled by the backtrace address in the soft lockup dump, which points to one instruction /before/ the ll instruction. So I thought that the lockup is somewhere outside of that loop, right? Does the backward branch on MIPS set up the instruction pointer in such a way that if an interrupt goes off, it can be pointing to the previous instruction? I thought about that possibility. From ralf@linux-mips.org Tue Nov 20 18:16:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 18:16:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:23455 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20021314AbXKTSQU (ORCPT ); Tue, 20 Nov 2007 18:16:20 +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 lAKIGJwi018065; Tue, 20 Nov 2007 18:16:19 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAKIGJoW018064; Tue, 20 Nov 2007 18:16:19 GMT Date: Tue, 20 Nov 2007 18:16:19 +0000 From: Ralf Baechle To: Kaz Kylheku Cc: linux-mips@linux-mips.org Subject: Re: futex_wake_op deadlock? Message-ID: <20071120181619.GA17979@linux-mips.org> References: <20071120112051.GB30675@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17552 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 20, 2007 at 10:06:44AM -0800, Kaz Kylheku wrote: > The problem is I didn't pay enough attention because I didn't suspect it > enough. > > I was misled by the backtrace address in the soft lockup dump, which > points to one instruction /before/ the ll instruction. So I thought that > the lockup is somewhere outside of that loop, right? > > Does the backward branch on MIPS set up the instruction pointer in such > a way that if an interrupt goes off, it can be pointing to the previous > instruction? I thought about that possibility. The EPC will always point to the instruction which caused the exception with the one special case where an instruction in a branch delay slot was causing the exception. If that's the case the EPC will point at the branch and the BD bit in the cause register (bit 31) will be set to indicate this special case. Ralf From kaz@zeugmasystems.com Tue Nov 20 18:24:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 18:25:05 +0000 (GMT) Received: from mail.zeugmasystems.com ([192.139.122.66]:8141 "EHLO zeugmasystems.com") by ftp.linux-mips.org with ESMTP id S20021406AbXKTSY5 convert rfc822-to-8bit (ORCPT ); Tue, 20 Nov 2007 18:24:57 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Subject: RE: futex_wake_op deadlock? Date: Tue, 20 Nov 2007 10:24:27 -0800 Message-ID: In-Reply-To: <20071120112051.GB30675@linux-mips.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: futex_wake_op deadlock? Thread-Index: AcgrZ5b0yPwptPInTAa6l6KjBurCtwAOoITg From: "Kaz Kylheku" To: "Ralf Baechle" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kaz@zeugmasystems.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Patch below. It fixes your test case on a 32-bit kernel for me. I'm running it now on 64 bit. The test case isn't causing any ill effects. Thanks a lot, Ralf! From ddaney@avtrex.com Tue Nov 20 18:30:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 18:30:34 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:24514 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20021511AbXKTSa0 (ORCPT ); Tue, 20 Nov 2007 18:30:26 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 1D6FE3100AC; Tue, 20 Nov 2007 18:30:02 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Tue, 20 Nov 2007 18:30:01 +0000 (UTC) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 10:29:48 -0800 Message-ID: <4743279B.7070402@avtrex.com> Date: Tue, 20 Nov 2007 10:29:47 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Ralf Baechle Cc: Kaz Kylheku , linux-mips@linux-mips.org Subject: Re: futex_wake_op deadlock? References: <20071119184837.GA12287@linux-mips.org> <20071120112051.GB30675@linux-mips.org> In-Reply-To: <20071120112051.GB30675@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 18:29:48.0122 (UTC) FILETIME=[54BA53A0:01C82BA3] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > > Notice the branch at the end of the fixup code, it goes back to the > SC instruction. The SC instruction took an exception so it will not have > changed $1 so the loop will continue endless unless by coincidence the > value to be stored from $1 happened to be zero. > > Obviously this one was MIPS specific and may hit all supported ABIs. So > my initial suspicion this might be the issue David Miller recently > discovered in the binary compat code isn't true. And it's a local DoS > probably for all of 2.6.16 and up. > I mostly similar code is in 2.6.15, so I think it is effected as well. 2.6.12 on the other hand doesn't seem to have futex.h David Daney From ralf@linux-mips.org Tue Nov 20 19:00:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Nov 2007 19:00:46 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:1231 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20022090AbXKTTAo (ORCPT ); Tue, 20 Nov 2007 19:00:44 +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 lAKJ0grk028865; Tue, 20 Nov 2007 19:00:42 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAKJ0fYL028864; Tue, 20 Nov 2007 19:00:41 GMT Date: Tue, 20 Nov 2007 19:00:41 +0000 From: Ralf Baechle To: David Daney Cc: Kaz Kylheku , linux-mips@linux-mips.org Subject: Re: futex_wake_op deadlock? Message-ID: <20071120190041.GA18138@linux-mips.org> References: <20071119184837.GA12287@linux-mips.org> <20071120112051.GB30675@linux-mips.org> <4743279B.7070402@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4743279B.7070402@avtrex.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 20, 2007 at 10:29:47AM -0800, David Daney wrote: >> Notice the branch at the end of the fixup code, it goes back to the >> SC instruction. The SC instruction took an exception so it will not have >> changed $1 so the loop will continue endless unless by coincidence the >> value to be stored from $1 happened to be zero. >> >> Obviously this one was MIPS specific and may hit all supported ABIs. So >> my initial suspicion this might be the issue David Miller recently >> discovered in the binary compat code isn't true. And it's a local DoS >> probably for all of 2.6.16 and up. >> > > I mostly similar code is in 2.6.15, so I think it is effected as well. > 2.6.12 on the other hand doesn't seem to have futex.h It originally appeared in the lmo kernel for 2.6.14-rc1 and a little after the 2.6.14 release in kernel.org. If I say 2.6.16 then it's simply that I don't ever look at anything that doesn't have a -stable branch. Ralf From zzh.hust@gmail.com Wed Nov 21 03:58:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Nov 2007 03:58:54 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.181]:39736 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20024767AbXKUD6p (ORCPT ); Wed, 21 Nov 2007 03:58:45 +0000 Received: by wa-out-1112.google.com with SMTP id m16so2629546waf for ; Tue, 20 Nov 2007 19:58:32 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=O+nUE8QUxPfgIN8hH6BJhfnLyDSYLLUhCt8arwODF9o=; b=JNZPuRvstc7OmGtV/DS0HMkMmakkU7kN4CcrRrvGzIGVjFolXyQAlf8cBLHUspzsYzlXDD7ye9XEUR1TBeBlUPVkVA37VsT7BRLN3+/w10Idnl0KY3/nIyKYWDV+U54+sVan64U+/F64IQWmK515HePnlh55VKwVOHIoVClRgSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zqxa1NCogHrRc25eFSUG6TEwYIJgmbDN5UBgbNvjlEXKrWu9Fw4UpusaMisVxQBLwC2RqafXs2UzCVqqBFllY3v+zGewZQemdKOPtPwsmd7mo2ONnMdtnFpiLv1hHRqnXcPikBAUldIZHv6DwbZZMf/dE6OzrIOVtgURkKaQw7o= Received: by 10.114.177.1 with SMTP id z1mr615336wae.1195617512856; Tue, 20 Nov 2007 19:58:32 -0800 (PST) Received: by 10.114.168.15 with HTTP; Tue, 20 Nov 2007 19:58:32 -0800 (PST) Message-ID: <50c9a2250711201958j5b825f9p5b56f841813fa788@mail.gmail.com> Date: Wed, 21 Nov 2007 11:58:32 +0800 From: zhuzhenhua To: "Thiemo Seufer" Subject: Re: how to use memory before kernel load address? Cc: linux-mips In-Reply-To: <20071120130451.GI11996@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50c9a2250711191706g40744ab2w2027124c4bc8dbbb@mail.gmail.com> <20071120130451.GI11996@networkno.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17556 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips On 11/20/07, Thiemo Seufer wrote: > zhuzhenhua wrote: > > hello,all > > i want to place my kernel loadaddr=0x81008000 and set > > EBASE=0x81000000, it workes. > > but there is still some memory usable before 0x81000000, for > > example from 0x80100000 ~ 0x80200000 > > The obvious thing to do seems to set LOARADDR to 0x80208000. > > > i have try to pass param as mem=1M@1M mem=16M@16M to the kernel, > > it seems only take the 0x8000000 ~ kernel_end as reserved. > > is there any other options to set the memory useable? ( my kernel > > version is 2.6.14) > > thanks for any hints > > AFAIR the kernel assumes to occupy the lowest addresses of the usable RAM. > > > Thiemo > i have resolve it, by modify as follow: in arch/mips/kernel/setup.c static inline void bootmem_init(void) ..... if (curr_pfn < start_pfn) // just change the judgement curr_pfn = start_pfn; .... /* Register lowmem ranges */ free_bootmem(PFN_PHYS(curr_pfn), PFN_PHYS(size)); thanks all. zzh From david.kuk@entone.com Thu Nov 22 07:35:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 07:35:33 +0000 (GMT) Received: from rv-out-0910.google.com ([209.85.198.190]:51743 "EHLO rv-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20024401AbXKVHfY (ORCPT ); Thu, 22 Nov 2007 07:35:24 +0000 Received: by rv-out-0910.google.com with SMTP id l15so2009034rvb for ; Wed, 21 Nov 2007 23:35:12 -0800 (PST) Received: by 10.140.163.3 with SMTP id l3mr3773902rve.1195716911828; Wed, 21 Nov 2007 23:35:11 -0800 (PST) Received: by 10.141.146.1 with HTTP; Wed, 21 Nov 2007 23:35:11 -0800 (PST) Message-ID: Date: Thu, 22 Nov 2007 15:35:11 +0800 From: "David Kuk" To: "YH Lin" Subject: Re: smp8634 add memory at dram1 Cc: linux-mips@linux-mips.org In-Reply-To: <5DF100B598199744B111FCEA5222E78A02D52DCE@sigma-exch1.sdesigns.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_323_21630688.1195716911803" References: <5DF100B598199744B111FCEA5222E78A02D52DCE@sigma-exch1.sdesigns.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: 17557 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: david.kuk@entone.com Precedence: bulk X-list: linux-mips ------=_Part_323_21630688.1195716911803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all, thank you very much Lin, for your kindly reply. May I ask you some more questions ? 1. about your answer 2, it's true that 0x10000000 to 0x10020000 are reserved, so what's the way i can sure no one use this area of memory ? because em86xx_kmem_start is still the dram controller0's. 2. about your answer 3, if i need to enable the PCI host, you mean i will have no chance to have greater than 112 MB DMA memory start from the em86xx_kmem_start ? it's seems a dilemma here, I may describe it more clearly. I have one ram size of 128 at dram0 controller and as well as another 128 at dram1 controller. previously it's work very well, the controller0's ram is for linux and controller1's memory is for video decode. But recently because the grow of code size of grow of both linux as well as middle ware, we really need more memory for for kernel run, so if in this situation , what should i do ? thx a lot for your help David On 11/21/07, YH Lin wrote: > > > > Hi David, > > > > We have not done so for SMP8634. But I think it is possible to do this: > > > > 1. Using remap register 4 instead, there you will have > 0x0c000000-0x16fe0000 contiguous space, where 0x0c000000-0x0fffffff is > mapped to DRAM1 and 0x10000000-0x16fe0000 is in DRAM0. > 2. You'd probably reserve the memory 0x10000000-0x10020000 since > this area is used by other things so it'd be better if no one else is using > this portion of memory. > 3. As for DMA zone or normal zone, that depends. Do you have the > need to enable PCI host? If so, the max. size of DMA zone is 112MB, or else > it can all be DMA memory (provide that the address translation routines are > modified accordingly). > > > > Regards, > > YH > > > ------------------------------ > > *From:* linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] > *On Behalf Of *David Kuk > *Sent:* Monday, November 19, 2007 8:23 PM > *To:* David Daney > *Cc:* linux-mips@linux-mips.org > *Subject:* Re: smp8634 add memory at dram1 > > > > Thanks you all for helping. > > AS Daney suggested, I have map the dram1's first 64 MB memory (total 128) > to remap register 3, > and add the remap register 3 into the BOOT_MEMROY_RAM use the method > add_memory_region. > When i bootup the linux kernel print out that it have totally 176MB ram , > which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at > remap register3). How ever, This mapping shows that the total memory in the > linux kernel is not contiguous. the OS can run, but as i see the source > code, when the kernel divided these memory into pages, it did not consider > if the memory is contiguous or not, is it ok ? and how should i allocate > the memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all > the 176MB memory can be allocate as ZONE[DMA]? > > > Best wishes > David > > > > On 11/15/07, *David Daney* wrote: > > David Kuk wrote: > > After study about the memory configuration of sigma smp8634, i found > > some difficult to accomplish the task. > > > > so my question is if have two 128MB ram separately under dram0 and > > dram1 controller, where dram0 for linux and dram1 for video decoding. > > Now the situation is the memory for linux is not enough and video > > decoding can not use all of it's 128MB at dram1, what we plan to do is > > to share 64MB at dram1 to the linux kernel as high memory, and only > > reserved 64MB at dram1 for the video decoding. > > > > first, in MIPS architecture, we found that the kseg0 and kseg1 are > > mapped to 0x00000000-0x20000000, which include only dram0 controller, > > so we wish to add the dram1 memory manually to the kernel using > > function add_memory_region at setup.c , after booting up result the > > warning that the memory larger than 512 need to configured the kernel > > support high memory. > > > > then when we configure the kernel to support high memory at menu > > configure, the kernel when booting up will remind us our CPU do not > > support high memory due to cache aliases. > > > > Both way will lead the linux can not boot up normally, so what should > > we do, is there any mis-understanding about the hardware > > implementation or MIPS design? > > I think your understanding of the 8634 is at least close to correct. > > It may be possible (but I have not tried it yet) to use the remapping > registers to move dram1 into the first 512MB of the memory space. If it > is possible, you would then have to modify the gbus access functions > accordingly. Also the 8634 media drivers would probably have to be > changed as well. I am not sure about the microcode for the media DSPs, > but if it is dependent on the mapping of the DRAM, then you would > probably have to get the vendor's help. > > Let me know if you are successful. > > Thanks, > David Daney > > > ------=_Part_323_21630688.1195716911803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all,

thank you very much Lin, for your kindly reply. May I ask you some more questions ?

1. about your answer 2, it's true that 0x10000000 to 0x10020000 are reserved,
so what's the way i can sure no one use this area of memory ? because em86xx_kmem_start is still the dram controller0's.

2. about your answer 3, if i need to enable the PCI host, you mean i will have no chance to have greater than 112 MB DMA memory start from the em86xx_kmem_start ? it's seems a dilemma here, I may describe it more clearly. I have one ram size of 128 at dram0 controller and as well as another 128 at dram1 controller. previously it's work very well, the controller0's ram is for linux and controller1's memory is for video decode. But recently because the grow of code size of grow of both linux as well as middle ware, we really need more memory for for kernel run, so if in this situation , what should i do ?

thx a lot for your help
David

On 11/21/07, YH Lin < YH_Lin@sdesigns.com> wrote:

 

Hi David,

 

We have not done so for SMP8634. But I think it is possible to do this:

 

  1. Using remap register 4 instead, there you will have 0x0c000000-0x16fe0000 contiguous space, where 0x0c000000-0x0fffffff is mapped to DRAM1 and 0x10000000-0x16fe0000 is in DRAM0.
  2. You'd probably reserve the memory 0x10000000-0x10020000 since this area is used by other things so it'd be better if no one else is using this portion of memory.
  3. As for DMA zone or normal zone, that depends. Do you have the need to enable PCI host? If so, the max. size of DMA zone is 112MB, or else it can all be DMA memory (provide that the address translation routines are modified accordingly).

 

Regards,

YH

 

From: linux-mips-bounce@linux-mips.org [mailto: linux-mips-bounce@linux-mips.org] On Behalf Of David Kuk
Sent: Monday, November 19, 2007 8:23 PM
To: David Daney
Cc: linux-mips@linux-mips.org
Subject: Re: smp8634 add memory at dram1

 

Thanks you all for helping.

AS Daney suggested, I have map the dram1's first 64 MB memory (total 128) to remap register 3,
and add the remap register 3 into the BOOT_MEMROY_RAM use the method add_memory_region.
When i bootup the linux kernel print out that it have totally 176MB ram , which is 06fe0000@10020000(dram0) and 04000000@08000000(64mb dram1 at remap register3). How ever, This mapping shows that the total memory in the linux kernel is not contiguous. the OS can run, but as i see the source code, when the kernel divided these memory into pages, it did not consider  if the memory is contiguous or not, is it ok ? and  how should i  allocate the memories into ZONE[DMA] and ZONE[NORMAL], is it possible if I wish all the 176MB memory can be allocate as ZONE[DMA]?


Best wishes
David



On 11/15/07, David Daney <ddaney@avtrex.com> wrote:

David Kuk wrote:
> After study about the memory configuration of sigma smp8634, i found
> some difficult to accomplish the task.
>
> so my question is if have two 128MB ram separately under dram0 and
> dram1 controller, where dram0 for linux and dram1 for video decoding.
> Now the situation is the memory for linux is not enough and video
> decoding can not use all of it's 128MB at dram1, what we plan to do is
> to share 64MB at dram1 to the linux kernel as high memory, and only
> reserved 64MB at dram1 for the video decoding.
>
> first, in MIPS architecture, we found that the kseg0 and kseg1 are
> mapped to 0x00000000-0x20000000, which include only dram0 controller,
> so we wish to add the dram1 memory manually to the kernel using
> function add_memory_region at setup.c , after booting up result the
> warning that the memory larger than 512 need to configured the kernel
> support high memory.
>
> then when we configure the kernel to support high memory at menu
> configure, the kernel when booting up will remind us our CPU do not
> support high memory due to cache aliases.
>
> Both way will lead the linux can not boot up normally, so what should
> we do, is there any mis-understanding about the hardware
> implementation or MIPS design?

I think your understanding of the 8634 is at least close to correct.

It may be possible (but I have not tried it yet) to use the remapping
registers to move dram1 into the first 512MB of the memory space.  If it
is possible, you would then have to modify the gbus access functions
accordingly.  Also the 8634 media drivers would probably have to be
changed as well.  I am not sure about the microcode for the media DSPs,
but if it is dependent on the mapping of the DRAM, then you would
probably have to get the vendor's help.

Let me know if you are successful.

Thanks,
David Daney

 


------=_Part_323_21630688.1195716911803-- From petersayei@ucom.ne.jp Thu Nov 22 11:39:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 11:39:28 +0000 (GMT) Received: from 122x211x116x75.ap122.ftth.ucom.ne.jp ([122.211.116.75]:19979 "HELO ucom.ne.jp") by ftp.linux-mips.org with SMTP id S20024815AbXKVLjD (ORCPT ); Thu, 22 Nov 2007 11:39:03 +0000 Received: from asx121.turbo-inline.com ([Thu, 22 Nov 2007 16:33:17 +0400]) by public.micromail.com.au with QMQP; Thu, 22 Nov 2007 16:33:17 +0400 Received: from unknown (137.34.24.75) by mail.naihautsui.co.kr with ESMTP; Thu, 22 Nov 2007 16:20:05 +0400 Received: from snmp.otwaloow.com ([Thu, 22 Nov 2007 16:13:02 +0400]) by external.newsubdomain.com with SMTP; Thu, 22 Nov 2007 16:13:02 +0400 Received: from group21.345mail.com ([Thu, 22 Nov 2007 16:02:57 +0400]) by mx03.listsystemsf.net with LOCAL; Thu, 22 Nov 2007 16:02:57 +0400 Received: from mail.gimmicc.net ([Thu, 22 Nov 2007 15:51:57 +0400]) by rly04.hottestmile.com with NNFMP; Thu, 22 Nov 2007 15:51:57 +0400 Message-ID: <440CCCFD.46814719@ucom.ne.jp> Date: Thu, 22 Nov 2007 15:41:38 +0400 From: "Lusia R., Chicago" X-Accept-Language: en-us MIME-Version: 1.0 To: "Lusia R., Chicago" Subject: Bud 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: 17558 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: petersayei@ucom.ne.jp Precedence: bulk X-list: linux-mips All your pharma needs. shallthere.com. Remove the dot from the end of the link to use it. From ralf@linux-mips.org Thu Nov 22 12:56:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 12:56:20 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:35483 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025516AbXKVM4S (ORCPT ); Thu, 22 Nov 2007 12:56: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 lAMCu24I005015; Thu, 22 Nov 2007 12:56:02 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lALMYGe0030899; Wed, 21 Nov 2007 22:34:16 GMT Date: Wed, 21 Nov 2007 22:34:16 +0000 From: Ralf Baechle To: Joe Perches Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH 02/59] arch/mips: Add missing "space" Message-ID: <20071121223415.GA27623@linux-mips.org> References: <23f0badf8dab73294c2aa142fafb9301ca843e88.1195454434.git.joe@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23f0badf8dab73294c2aa142fafb9301ca843e88.1195454434.git.joe@perches.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17559 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 19, 2007 at 05:47:54PM -0800, Joe Perches wrote: Queued for 2.6.25. Thanks, Ralf From anemo@mba.ocn.ne.jp Thu Nov 22 15:39:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 15:39:36 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:10950 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20025821AbXKVPj1 (ORCPT ); Thu, 22 Nov 2007 15:39:27 +0000 Received: from localhost (p8045-ipad307funabasi.chiba.ocn.ne.jp [123.217.186.45]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D7C889521; Fri, 23 Nov 2007 00:39:20 +0900 (JST) Date: Fri, 23 Nov 2007 00:41:32 +0900 (JST) Message-Id: <20071123.004132.61510296.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts. From: Atsushi Nemoto In-Reply-To: References: 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: 17560 X-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 Thu, 15 Nov 2007 20:17:31 +0000, linux-mips@linux-mips.org wrote: > Subject: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts. > Author: Ralf Baechle Thu Nov 15 19:37:15 2007 +0000 > Commit: eebc88e5d2cffc07b969c8f426552a44e5ce51f8 > Gitweb: http://www.linux-mips.org/g/linux/eebc88e5 > Branch: master This might broke probe_irq_on()/probe_irq_off(), since handle_percpu_irq() does not check IRQ_WAITING bit. This is a quick fix. But I'm not sure where is the right place to fix... Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c index 0ee2567..9d97d4b 100644 --- a/arch/mips/kernel/irq_cpu.c +++ b/arch/mips/kernel/irq_cpu.c @@ -114,7 +114,9 @@ void __init mips_cpu_irq_init(void) for (i = irq_base; i < irq_base + 2; i++) set_irq_chip(i, &mips_mt_cpu_irq_controller); - for (i = irq_base + 2; i < irq_base + 8; i++) + for (i = irq_base + 2; i < irq_base + 8; i++) { set_irq_chip_and_handler(i, &mips_cpu_irq_controller, handle_percpu_irq); + irq_desc[i].status |= IRQ_NOPROBE; + } } From anemo@mba.ocn.ne.jp Thu Nov 22 15:42:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 15:42:09 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:60908 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20025159AbXKVPmA (ORCPT ); Thu, 22 Nov 2007 15:42:00 +0000 Received: from localhost (p8045-ipad307funabasi.chiba.ocn.ne.jp [123.217.186.45]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 1EF0C9521; Fri, 23 Nov 2007 00:41:54 +0900 (JST) Date: Fri, 23 Nov 2007 00:44:06 +0900 (JST) Message-Id: <20071123.004406.108119126.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] qemu: do not enable IP7 blindly From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17561 X-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 IP7 will be enabled automatically in mips_clockevent_init(), if it was available. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/qemu/q-irq.c b/arch/mips/qemu/q-irq.c index 11f9847..7df36db 100644 --- a/arch/mips/qemu/q-irq.c +++ b/arch/mips/qemu/q-irq.c @@ -33,5 +33,5 @@ void __init arch_init_irq(void) mips_cpu_irq_init(); init_i8259_irqs(); - set_c0_status(0x8400); + set_c0_status(0x400); } From ralf@linux-mips.org Thu Nov 22 16:19:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 16:19:58 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:21708 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025862AbXKVQT4 (ORCPT ); Thu, 22 Nov 2007 16:19:56 +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 lAMGJaVA006647; Thu, 22 Nov 2007 16:19:36 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAMGJZki006646; Thu, 22 Nov 2007 16:19:35 GMT Date: Thu, 22 Nov 2007 16:19:35 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts. Message-ID: <20071122161935.GA6605@linux-mips.org> References: <20071123.004132.61510296.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071123.004132.61510296.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17562 X-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 23, 2007 at 12:41:32AM +0900, Atsushi Nemoto wrote: > This might broke probe_irq_on()/probe_irq_off(), since > handle_percpu_irq() does not check IRQ_WAITING bit. Ok - but does that matter at all? IRQ probing is only used with ISA drivers and for those there will be another interrupt controller such as a i8259 PIC daisy chained to one of the CPU interrupt pins. Ralf From ralf@linux-mips.org Thu Nov 22 17:24:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 17:24:03 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:64445 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026057AbXKVRYB (ORCPT ); Thu, 22 Nov 2007 17:24:01 +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 lAMHNgXi007405; Thu, 22 Nov 2007 17:23:42 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAMHNfOx007404; Thu, 22 Nov 2007 17:23:41 GMT Date: Thu, 22 Nov 2007 17:23:41 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts. Message-ID: <20071122172341.GA6973@linux-mips.org> References: <20071123.004132.61510296.anemo@mba.ocn.ne.jp> <20071122161935.GA6605@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071122161935.GA6605@linux-mips.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17563 X-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 22, 2007 at 04:19:35PM +0000, Ralf Baechle wrote: > > This might broke probe_irq_on()/probe_irq_off(), since > > handle_percpu_irq() does not check IRQ_WAITING bit. > > Ok - but does that matter at all? IRQ probing is only used with ISA > drivers and for those there will be another interrupt controller such as > a i8259 PIC daisy chained to one of the CPU interrupt pins. Ah, I think I now understand the problem. Seems like no interrupt should ever use IRQ_NOPROBE except ISA interrupts but unfortunately that flag is not everywhere where it should. Maybe the logic should even be negated and the flag become IRQ_PROBE ... Ralf From ralf@linux-mips.org Thu Nov 22 18:43:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Nov 2007 18:43:37 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:12992 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026352AbXKVSne (ORCPT ); Thu, 22 Nov 2007 18:43:34 +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 lAMIhF3k014284; Thu, 22 Nov 2007 18:43:15 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAMIhEIH014283; Thu, 22 Nov 2007 18:43:14 GMT Date: Thu, 22 Nov 2007 18:43:14 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts. Message-ID: <20071122184314.GA14223@linux-mips.org> References: <20071123.004132.61510296.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071123.004132.61510296.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17564 X-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 23, 2007 at 12:41:32AM +0900, Atsushi Nemoto wrote: > This might broke probe_irq_on()/probe_irq_off(), since > handle_percpu_irq() does not check IRQ_WAITING bit. > > This is a quick fix. But I'm not sure where is the right place to fix... Here's a cleaner version. I guess I should scatter a few more set_irq_noprobe calls over arch/mips - just not into i8259.c. Ralf diff --git a/arch/mips/kernel/irq-rm7000.c b/arch/mips/kernel/irq-rm7000.c index 971adf6..a92f2d0 100644 --- a/arch/mips/kernel/irq-rm7000.c +++ b/arch/mips/kernel/irq-rm7000.c @@ -42,7 +42,9 @@ void __init rm7k_cpu_irq_init(void) clear_c0_intcontrol(0x00000f00); /* Mask all */ - for (i = base; i < base + 4; i++) + for (i = base; i < base + 4; i++) { set_irq_chip_and_handler(i, &rm7k_irq_controller, handle_percpu_irq); + set_irq_noprobe(i); + } } diff --git a/arch/mips/kernel/irq-rm9000.c b/arch/mips/kernel/irq-rm9000.c index 7b04583..3f21538 100644 --- a/arch/mips/kernel/irq-rm9000.c +++ b/arch/mips/kernel/irq-rm9000.c @@ -105,4 +105,5 @@ void __init rm9k_cpu_irq_init(void) rm9000_perfcount_irq = base + 1; set_irq_chip_and_handler(rm9000_perfcount_irq, &rm9k_perfcounter_irq, handle_percpu_irq); + set_irq_noprobe(rm9000_perfcount_irq); } diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c index d06e9c9..c2e3279 100644 --- a/arch/mips/kernel/irq.c +++ b/arch/mips/kernel/irq.c @@ -130,6 +130,24 @@ asmlinkage void spurious_interrupt(void) atomic_inc(&irq_err_count); } +void set_irq_noprobe(unsigned int irq) +{ + unsigned long flags; + struct irq_desc *desc; + + if (irq >= NR_IRQS) { + printk(KERN_ERR + "Trying to install type control for IRQ%d\n", irq); + return; + } + + desc = irq_desc + irq; + + spin_lock_irqsave(&desc->lock, flags); + desc->status |= IRQ_NOPROBE; + spin_unlock_irqrestore(&desc->lock, flags); +} + #ifdef CONFIG_KGDB extern void breakpoint(void); extern void set_debug_traps(void); diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c index 0ee2567..810f65d 100644 --- a/arch/mips/kernel/irq_cpu.c +++ b/arch/mips/kernel/irq_cpu.c @@ -114,7 +114,9 @@ void __init mips_cpu_irq_init(void) for (i = irq_base; i < irq_base + 2; i++) set_irq_chip(i, &mips_mt_cpu_irq_controller); - for (i = irq_base + 2; i < irq_base + 8; i++) + for (i = irq_base + 2; i < irq_base + 8; i++) { set_irq_chip_and_handler(i, &mips_cpu_irq_controller, handle_percpu_irq); + set_irq_noprobe(i); + } } diff --git a/include/asm-mips/irq.h b/include/asm-mips/irq.h index a58f0ee..6b60d2a 100644 --- a/include/asm-mips/irq.h +++ b/include/asm-mips/irq.h @@ -160,4 +160,6 @@ extern void free_irqno(unsigned int irq); extern int cp0_compare_irq; extern int cp0_perfcount_irq; +extern void set_irq_noprobe(unsigned int irq); + #endif /* _ASM_IRQ_H */ From anemo@mba.ocn.ne.jp Fri Nov 23 16:19:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Nov 2007 16:19:34 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:21730 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20022565AbXKWQTY (ORCPT ); Fri, 23 Nov 2007 16:19:24 +0000 Received: from localhost (p4171-ipad401funabasi.chiba.ocn.ne.jp [123.217.238.171]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D465B91A1; Sat, 24 Nov 2007 01:18:02 +0900 (JST) Date: Sat, 24 Nov 2007 01:20:15 +0900 (JST) Message-Id: <20071124.012015.03977175.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, wim@iguana.be, akpm@linux-foundation.org Subject: [PATCH 1/2] TXx9 watchdog driver From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17565 X-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 This is a driver for watchdog timer built into TXx9 MIPS SoCs. Signed-off-by: Atsushi Nemoto --- Can be applied on current linux-2.6.git, linux-mips.org or 2.6.24-rc3-mm1. drivers/watchdog/Kconfig | 6 + drivers/watchdog/Makefile | 1 + drivers/watchdog/txx9wdt.c | 276 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 283 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 2792bc1..7484ee6 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -616,6 +616,12 @@ config AR7_WDT help Hardware driver for the TI AR7 Watchdog Timer. +config TXX9_WDT + tristate "Toshiba TXx9 Watchdog Timer" + depends on CPU_TX39XX || CPU_TX49XX + help + Hardware driver for the built-in watchdog timer on TXx9 MIPS SoCs. + # PARISC Architecture # POWERPC Architecture diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 7d9e573..0458e62 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -91,6 +91,7 @@ obj-$(CONFIG_INDYDOG) += indydog.o obj-$(CONFIG_WDT_MTX1) += mtx-1_wdt.o obj-$(CONFIG_WDT_RM9K_GPI) += rm9k_wdt.o obj-$(CONFIG_AR7_WDT) += ar7_wdt.o +obj-$(CONFIG_TXX9_WDT) += txx9wdt.o # PARISC Architecture diff --git a/drivers/watchdog/txx9wdt.c b/drivers/watchdog/txx9wdt.c new file mode 100644 index 0000000..f3af8f5 --- /dev/null +++ b/drivers/watchdog/txx9wdt.c @@ -0,0 +1,276 @@ +/* + * txx9wdt: A Hardware Watchdog Driver for TXx9 SoCs + * + * Copyright (C) 2007 Atsushi Nemoto + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TIMER_MARGIN 60 /* Default is 60 seconds */ + +static int timeout = TIMER_MARGIN; /* in seconds */ +module_param(timeout, int, 0); +MODULE_PARM_DESC(timeout, + "Watchdog timeout in seconds. " + "(0> (32 - TXX9_TIMER_BITS)) / WD_TIMER_CLK) + +static unsigned long txx9wdt_alive; +static int expect_close; +static struct txx9_tmr_reg __iomem *txx9wdt_reg; +static struct clk *txx9_imclk; + +static void txx9wdt_ping(void) +{ + __raw_writel(TXx9_TMWTMR_TWIE | TXx9_TMWTMR_TWC, &txx9wdt_reg->wtmr); +} + +static void txx9wdt_start(void) +{ + __raw_writel(WD_TIMER_CLK * timeout, &txx9wdt_reg->cpra); + __raw_writel(WD_TIMER_CCD, &txx9wdt_reg->ccdr); + __raw_writel(0, &txx9wdt_reg->tisr); /* clear pending interrupt */ + __raw_writel(TXx9_TMTCR_TCE | TXx9_TMTCR_CCDE | TXx9_TMTCR_TMODE_WDOG, + &txx9wdt_reg->tcr); + __raw_writel(TXx9_TMWTMR_TWIE | TXx9_TMWTMR_TWC, &txx9wdt_reg->wtmr); +} + +static void txx9wdt_stop(void) +{ + __raw_writel(TXx9_TMWTMR_WDIS, &txx9wdt_reg->wtmr); + __raw_writel(__raw_readl(&txx9wdt_reg->tcr) & ~TXx9_TMTCR_TCE, + &txx9wdt_reg->tcr); +} + +static int txx9wdt_open(struct inode *inode, struct file *file) +{ + if (test_and_set_bit(0, &txx9wdt_alive)) + return -EBUSY; + + if (__raw_readl(&txx9wdt_reg->tcr) & TXx9_TMTCR_TCE) { + clear_bit(0, &txx9wdt_alive); + return -EBUSY; + } + + if (nowayout) + __module_get(THIS_MODULE); + + txx9wdt_start(); + return nonseekable_open(inode, file); +} + +static int txx9wdt_release(struct inode *inode, struct file *file) +{ + if (expect_close) + txx9wdt_stop(); + else { + printk(KERN_CRIT "txx9wdt: " + "Unexpected close, not stopping watchdog!\n"); + txx9wdt_ping(); + } + clear_bit(0, &txx9wdt_alive); + expect_close = 0; + return 0; +} + +static ssize_t txx9wdt_write(struct file *file, const char __user *data, + size_t len, loff_t *ppos) +{ + if (len) { + if (!nowayout) { + size_t i; + + expect_close = 0; + for (i = 0; i != len; i++) { + char c; + if (get_user(c, data + i)) + return -EFAULT; + if (c == 'V') + expect_close = 1; + } + } + txx9wdt_ping(); + } + return len; +} + +static int txx9wdt_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + void __user *argp = (void __user *)arg; + int __user *p = argp; + int new_timeout; + static struct watchdog_info ident = { + .options = WDIOF_SETTIMEOUT | + WDIOF_KEEPALIVEPING | + WDIOF_MAGICCLOSE, + .firmware_version = 0, + .identity = "Hardware Watchdog for TXx9", + }; + + switch (cmd) { + default: + return -ENOTTY; + case WDIOC_GETSUPPORT: + return copy_to_user(argp, &ident, sizeof(ident)) ? -EFAULT : 0; + case WDIOC_GETSTATUS: + case WDIOC_GETBOOTSTATUS: + return put_user(0, p); + case WDIOC_KEEPALIVE: + txx9wdt_ping(); + return 0; + case WDIOC_SETTIMEOUT: + if (get_user(new_timeout, p)) + return -EFAULT; + if (new_timeout < 1 || new_timeout > WD_MAX_TIMEOUT) + return -EINVAL; + timeout = new_timeout; + txx9wdt_stop(); + txx9wdt_start(); + /* Fall */ + case WDIOC_GETTIMEOUT: + return put_user(timeout, p); + } +} + +static int txx9wdt_notify_sys(struct notifier_block *this, unsigned long code, + void *unused) +{ + if (code == SYS_DOWN || code == SYS_HALT) + txx9wdt_stop(); + return NOTIFY_DONE; +} + +static const struct file_operations txx9wdt_fops = { + .owner = THIS_MODULE, + .llseek = no_llseek, + .write = txx9wdt_write, + .ioctl = txx9wdt_ioctl, + .open = txx9wdt_open, + .release = txx9wdt_release, +}; + +static struct miscdevice txx9wdt_miscdev = { + .minor = WATCHDOG_MINOR, + .name = "watchdog", + .fops = &txx9wdt_fops, +}; + +static struct notifier_block txx9wdt_notifier = { + .notifier_call = txx9wdt_notify_sys +}; + +static int __init txx9wdt_probe(struct platform_device *dev) +{ + struct resource *res; + int ret; + + txx9_imclk = clk_get(NULL, "imbus_clk"); + if (IS_ERR(txx9_imclk)) { + ret = PTR_ERR(txx9_imclk); + txx9_imclk = NULL; + goto exit; + } + ret = clk_enable(txx9_imclk); + if (ret) { + clk_put(txx9_imclk); + txx9_imclk = NULL; + goto exit; + } + + res = platform_get_resource(dev, IORESOURCE_MEM, 0); + if (!res) + goto exit_busy; + if (!devm_request_mem_region(&dev->dev, + res->start, res->end - res->start + 1, + "txx9wdt")) + goto exit_busy; + txx9wdt_reg = devm_ioremap(&dev->dev, + res->start, res->end - res->start + 1); + if (!txx9wdt_reg) + goto exit_busy; + + ret = misc_register(&txx9wdt_miscdev); + if (ret) + goto exit; + + ret = register_reboot_notifier(&txx9wdt_notifier); + if (ret) { + misc_deregister(&txx9wdt_miscdev); + goto exit; + } + + printk(KERN_INFO "Hardware Watchdog Timer for TXx9: " + "timeout=%d sec (max %ld) (nowayout= %d)\n", + timeout, WD_MAX_TIMEOUT, nowayout); + + return 0; +exit_busy: + ret = -EBUSY; +exit: + if (txx9_imclk) { + clk_disable(txx9_imclk); + clk_put(txx9_imclk); + } + return ret; +} + +static int __exit txx9wdt_remove(struct platform_device *dev) +{ + misc_deregister(&txx9wdt_miscdev); + unregister_reboot_notifier(&txx9wdt_notifier); + clk_disable(txx9_imclk); + clk_put(txx9_imclk); + return 0; +} + +static struct platform_driver txx9wdt_driver = { + .remove = __exit_p(txx9wdt_remove), + .driver = { + .name = "txx9wdt", + .owner = THIS_MODULE, + }, +}; + +static int __init watchdog_init(void) +{ + return platform_driver_probe(&txx9wdt_driver, txx9wdt_probe); +} + +static void __exit watchdog_exit(void) +{ + platform_driver_unregister(&txx9wdt_driver); +} + +module_init(watchdog_init); +module_exit(watchdog_exit); + +MODULE_DESCRIPTION("TXx9 Watchdog Driver"); +MODULE_LICENSE("GPL"); +MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR); From anemo@mba.ocn.ne.jp Fri Nov 23 16:19:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Nov 2007 16:20:05 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:4325 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20022517AbXKWQTf (ORCPT ); Fri, 23 Nov 2007 16:19:35 +0000 Received: from localhost (p4171-ipad401funabasi.chiba.ocn.ne.jp [123.217.238.171]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id AEC7E9913; Sat, 24 Nov 2007 01:18:14 +0900 (JST) Date: Sat, 24 Nov 2007 01:20:27 +0900 (JST) Message-Id: <20071124.012027.130850581.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, wim@iguana.be, akpm@linux-foundation.org Subject: [PATCH 2/2] TXx9 watchdog support for rbhma3100,rbhma4200,rbhma4500 From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 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: 17566 X-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 This patch adds support for txx9wdt driver to rbhma3100, rbhma4200 and rbhma4500 platform. Signed-off-by: Atsushi Nemoto --- Can be applied on current linux-queue tree on linux-mips.org or 2.6.24-rc3-mm1. arch/mips/configs/jmr3927_defconfig | 15 +++++- arch/mips/configs/rbhma4200_defconfig | 15 +++++- arch/mips/configs/rbhma4500_defconfig | 15 +++++- arch/mips/jmr3927/rbhma3100/setup.c | 55 ++++++++++++++++++++ .../toshiba_rbtx4927/toshiba_rbtx4927_setup.c | 55 ++++++++++++++++++++ arch/mips/tx4938/toshiba_rbtx4938/setup.c | 25 +++++++++ include/asm-mips/tx4927/tx4927_pci.h | 1 + 7 files changed, 178 insertions(+), 3 deletions(-) diff --git a/arch/mips/configs/jmr3927_defconfig b/arch/mips/configs/jmr3927_defconfig index eb96791..4ace378 100644 --- a/arch/mips/configs/jmr3927_defconfig +++ b/arch/mips/configs/jmr3927_defconfig @@ -464,7 +464,6 @@ CONFIG_SERIAL_TXX9_STDSERIAL=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set -# CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_RTC is not set # CONFIG_R3964 is not set @@ -482,6 +481,20 @@ CONFIG_DEVPORT=y # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_TXX9_WDT=y + +# +# PCI-based Watchdog Cards +# +# CONFIG_PCIPCWATCHDOG is not set +# CONFIG_WDTPCI is not set # # Multifunction device drivers diff --git a/arch/mips/configs/rbhma4200_defconfig b/arch/mips/configs/rbhma4200_defconfig index 9383a59..a67c698 100644 --- a/arch/mips/configs/rbhma4200_defconfig +++ b/arch/mips/configs/rbhma4200_defconfig @@ -431,7 +431,6 @@ CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set -# CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_RTC is not set # CONFIG_R3964 is not set @@ -449,6 +448,20 @@ CONFIG_DEVPORT=y # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_TXX9_WDT=m + +# +# PCI-based Watchdog Cards +# +# CONFIG_PCIPCWATCHDOG is not set +# CONFIG_WDTPCI is not set # # Multifunction device drivers diff --git a/arch/mips/configs/rbhma4500_defconfig b/arch/mips/configs/rbhma4500_defconfig index d1b56cc..ebc8ad4 100644 --- a/arch/mips/configs/rbhma4500_defconfig +++ b/arch/mips/configs/rbhma4500_defconfig @@ -450,7 +450,6 @@ CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set -# CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_RTC is not set # CONFIG_R3964 is not set @@ -479,6 +478,20 @@ CONFIG_SPI_AT25=y # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +# CONFIG_WATCHDOG_NOWAYOUT is not set + +# +# Watchdog Device Drivers +# +# CONFIG_SOFT_WATCHDOG is not set +CONFIG_TXX9_WDT=m + +# +# PCI-based Watchdog Cards +# +# CONFIG_PCIPCWATCHDOG is not set +# CONFIG_WDTPCI is not set # # Multifunction device drivers diff --git a/arch/mips/jmr3927/rbhma3100/setup.c b/arch/mips/jmr3927/rbhma3100/setup.c index 75cfe65..c886d80 100644 --- a/arch/mips/jmr3927/rbhma3100/setup.c +++ b/arch/mips/jmr3927/rbhma3100/setup.c @@ -35,6 +35,7 @@ #include #include #include +#include #ifdef CONFIG_SERIAL_TXX9 #include #endif @@ -233,6 +234,8 @@ static void __init tx3927_setup(void) tx3927_ccfgptr->ccfg &= ~TX3927_CCFG_BEOW; /* Disable PCI snoop */ tx3927_ccfgptr->ccfg &= ~TX3927_CCFG_PSNP; + /* do reset on watchdog */ + tx3927_ccfgptr->ccfg |= TX3927_CCFG_WR; #ifdef DO_WRITE_THROUGH /* Enable PCI SNOOP - with write through only */ @@ -383,3 +386,55 @@ static int __init jmr3927_rtc_init(void) return IS_ERR(dev) ? PTR_ERR(dev) : 0; } device_initcall(jmr3927_rtc_init); + +/* Watchdog support */ + +static int __init txx9_wdt_init(unsigned long base) +{ + struct resource res = { + .start = base, + .end = base + 0x100 - 1, + .flags = IORESOURCE_MEM, + }; + struct platform_device *dev = + platform_device_register_simple("txx9wdt", -1, &res, 1); + return IS_ERR(dev) ? PTR_ERR(dev) : 0; +} + +static int __init jmr3927_wdt_init(void) +{ + return txx9_wdt_init(TX3927_TMR_REG(2)); +} +device_initcall(jmr3927_wdt_init); + +/* Minimum CLK support */ + +struct clk *clk_get(struct device *dev, const char *id) +{ + if (!strcmp(id, "imbus_clk")) + return (struct clk *)JMR3927_IMCLK; + return ERR_PTR(-ENOENT); +} +EXPORT_SYMBOL(clk_get); + +int clk_enable(struct clk *clk) +{ + return 0; +} +EXPORT_SYMBOL(clk_enable); + +void clk_disable(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_disable); + +unsigned long clk_get_rate(struct clk *clk) +{ + return (unsigned long)clk; +} +EXPORT_SYMBOL(clk_get_rate); + +void clk_put(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_put); diff --git a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c index c29a528..e466e5e 100644 --- a/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c +++ b/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c @@ -50,6 +50,7 @@ #include #include #include +#include #include #include @@ -803,6 +804,8 @@ void __init plat_mem_setup(void) } /* CCFG */ + /* do reset on watchdog */ + tx4927_ccfgptr->ccfg |= TX4927_CCFG_WR; /* enable Timeout BusError */ if (tx4927_ccfg_toeon) tx4927_ccfgptr->ccfg |= TX4927_CCFG_TOE; @@ -944,3 +947,55 @@ static int __init rbtx4927_ne_init(void) return IS_ERR(dev) ? PTR_ERR(dev) : 0; } device_initcall(rbtx4927_ne_init); + +/* Watchdog support */ + +static int __init txx9_wdt_init(unsigned long base) +{ + struct resource res = { + .start = base, + .end = base + 0x100 - 1, + .flags = IORESOURCE_MEM, + }; + struct platform_device *dev = + platform_device_register_simple("txx9wdt", -1, &res, 1); + return IS_ERR(dev) ? PTR_ERR(dev) : 0; +} + +static int __init rbtx4927_wdt_init(void) +{ + return txx9_wdt_init(TX4927_TMR_REG(2) & 0xfffffffffULL); +} +device_initcall(rbtx4927_wdt_init); + +/* Minimum CLK support */ + +struct clk *clk_get(struct device *dev, const char *id) +{ + if (!strcmp(id, "imbus_clk")) + return (struct clk *)50000000; + return ERR_PTR(-ENOENT); +} +EXPORT_SYMBOL(clk_get); + +int clk_enable(struct clk *clk) +{ + return 0; +} +EXPORT_SYMBOL(clk_enable); + +void clk_disable(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_disable); + +unsigned long clk_get_rate(struct clk *clk) +{ + return (unsigned long)clk; +} +EXPORT_SYMBOL(clk_get_rate); + +void clk_put(struct clk *clk) +{ +} +EXPORT_SYMBOL(clk_put); diff --git a/arch/mips/tx4938/toshiba_rbtx4938/setup.c b/arch/mips/tx4938/toshiba_rbtx4938/setup.c index d13af99..47a9c17 100644 --- a/arch/mips/tx4938/toshiba_rbtx4938/setup.c +++ b/arch/mips/tx4938/toshiba_rbtx4938/setup.c @@ -724,6 +724,8 @@ void __init tx4938_board_setup(void) /* CCFG */ /* clear WatchDogReset,BusErrorOnWrite flag (W1C) */ tx4938_ccfgptr->ccfg |= TX4938_CCFG_WDRST | TX4938_CCFG_BEOW; + /* do reset on watchdog */ + tx4938_ccfgptr->ccfg |= TX4938_CCFG_WR; /* clear PCIC1 reset */ if (tx4938_ccfgptr->clkctr & TX4938_CLKCTR_PCIC1RST) tx4938_ccfgptr->clkctr &= ~TX4938_CLKCTR_PCIC1RST; @@ -1121,12 +1123,35 @@ static int __init rbtx4938_spi_init(void) } arch_initcall(rbtx4938_spi_init); +/* Watchdog support */ + +static int __init txx9_wdt_init(unsigned long base) +{ + struct resource res = { + .start = base, + .end = base + 0x100 - 1, + .flags = IORESOURCE_MEM, + .parent = &tx4938_reg_resource, + }; + struct platform_device *dev = + platform_device_register_simple("txx9wdt", -1, &res, 1); + return IS_ERR(dev) ? PTR_ERR(dev) : 0; +} + +static int __init rbtx4938_wdt_init(void) +{ + return txx9_wdt_init(TX4938_TMR_REG(2) & 0xfffffffffULL); +} +device_initcall(rbtx4938_wdt_init); + /* Minimum CLK support */ struct clk *clk_get(struct device *dev, const char *id) { if (!strcmp(id, "spi-baseclk")) return (struct clk *)(txx9_gbus_clock / 2 / 4); + if (!strcmp(id, "imbus_clk")) + return (struct clk *)(txx9_gbus_clock / 2); return ERR_PTR(-ENOENT); } EXPORT_SYMBOL(clk_get); diff --git a/include/asm-mips/tx4927/tx4927_pci.h b/include/asm-mips/tx4927/tx4927_pci.h index 3f1e470..0be77df 100644 --- a/include/asm-mips/tx4927/tx4927_pci.h +++ b/include/asm-mips/tx4927/tx4927_pci.h @@ -9,6 +9,7 @@ #define __ASM_TX4927_TX4927_PCI_H #define TX4927_CCFG_TOE 0x00004000 +#define TX4927_CCFG_WR 0x00008000 #define TX4927_CCFG_TINTDIS 0x01000000 #define TX4927_PCIMEM 0x08000000 From tsbogend@alpha.franken.de Fri Nov 23 19:52:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Nov 2007 19:52:18 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:62694 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20029219AbXKWTwJ (ORCPT ); Fri, 23 Nov 2007 19:52:09 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IveZL-0004Ev-00; Fri, 23 Nov 2007 20:52:07 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id BADCCC2DDE; Fri, 23 Nov 2007 20:51:04 +0100 (CET) From: Thomas Bogendoerfer Date: Fri, 23 Nov 2007 20:34:16 +0100 Subject: [PATCH] IP22: Fix broken EISA interrupt setup by switching to generic i8259 Message-Id: <20071123195104.BADCCC2DDE@solo.franken.de> To: undisclosed-recipients:; Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17567 X-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 Signed-off-by: Thomas Bogendoerfer --- arch/mips/Kconfig | 1 + arch/mips/sgi-ip22/ip22-eisa.c | 134 +--------------------------------------- 2 files changed, 3 insertions(+), 132 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2f2ce0c..84059da 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -385,6 +385,7 @@ config SGI_IP22 select DMA_NONCOHERENT select HW_HAS_EISA select I8253 + select I8259 select IP22_CPU_SCACHE select IRQ_CPU select GENERIC_ISA_DMA_SUPPORT_BROKEN diff --git a/arch/mips/sgi-ip22/ip22-eisa.c b/arch/mips/sgi-ip22/ip22-eisa.c index 26854fb..1617241 100644 --- a/arch/mips/sgi-ip22/ip22-eisa.c +++ b/arch/mips/sgi-ip22/ip22-eisa.c @@ -36,6 +36,7 @@ #include #include #include +#include /* I2 has four EISA slots. */ #define IP22_EISA_MAX_SLOTS 4 @@ -93,126 +94,11 @@ static irqreturn_t ip22_eisa_intr(int irq, void *dev_id) return IRQ_NONE; } -static void enable_eisa1_irq(unsigned int irq) -{ - u8 mask; - - mask = inb(EISA_INT1_MASK); - mask &= ~((u8) (1 << irq)); - outb(mask, EISA_INT1_MASK); -} - -static unsigned int startup_eisa1_irq(unsigned int irq) -{ - u8 edge; - - /* Only use edge interrupts for EISA */ - - edge = inb(EISA_INT1_EDGE_LEVEL); - edge &= ~((u8) (1 << irq)); - outb(edge, EISA_INT1_EDGE_LEVEL); - - enable_eisa1_irq(irq); - return 0; -} - -static void disable_eisa1_irq(unsigned int irq) -{ - u8 mask; - - mask = inb(EISA_INT1_MASK); - mask |= ((u8) (1 << irq)); - outb(mask, EISA_INT1_MASK); -} - -static void mask_and_ack_eisa1_irq(unsigned int irq) -{ - disable_eisa1_irq(irq); - - outb(0x20, EISA_INT1_CTRL); -} - -static void end_eisa1_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - enable_eisa1_irq(irq); -} - -static struct irq_chip ip22_eisa1_irq_type = { - .name = "IP22 EISA", - .startup = startup_eisa1_irq, - .ack = mask_and_ack_eisa1_irq, - .mask = disable_eisa1_irq, - .mask_ack = mask_and_ack_eisa1_irq, - .unmask = enable_eisa1_irq, - .end = end_eisa1_irq, -}; - -static void enable_eisa2_irq(unsigned int irq) -{ - u8 mask; - - mask = inb(EISA_INT2_MASK); - mask &= ~((u8) (1 << (irq - 8))); - outb(mask, EISA_INT2_MASK); -} - -static unsigned int startup_eisa2_irq(unsigned int irq) -{ - u8 edge; - - /* Only use edge interrupts for EISA */ - - edge = inb(EISA_INT2_EDGE_LEVEL); - edge &= ~((u8) (1 << (irq - 8))); - outb(edge, EISA_INT2_EDGE_LEVEL); - - enable_eisa2_irq(irq); - return 0; -} - -static void disable_eisa2_irq(unsigned int irq) -{ - u8 mask; - - mask = inb(EISA_INT2_MASK); - mask |= ((u8) (1 << (irq - 8))); - outb(mask, EISA_INT2_MASK); -} - -static void mask_and_ack_eisa2_irq(unsigned int irq) -{ - disable_eisa2_irq(irq); - - outb(0x20, EISA_INT2_CTRL); -} - -static void end_eisa2_irq(unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS))) - enable_eisa2_irq(irq); -} - -static struct irq_chip ip22_eisa2_irq_type = { - .name = "IP22 EISA", - .startup = startup_eisa2_irq, - .ack = mask_and_ack_eisa2_irq, - .mask = disable_eisa2_irq, - .mask_ack = mask_and_ack_eisa2_irq, - .unmask = enable_eisa2_irq, - .end = end_eisa2_irq, -}; - static struct irqaction eisa_action = { .handler = ip22_eisa_intr, .name = "EISA", }; -static struct irqaction cascade_action = { - .handler = no_action, - .name = "EISA cascade", -}; - int __init ip22_eisa_init(void) { int i, c; @@ -248,29 +134,13 @@ int __init ip22_eisa_init(void) outb(1, EISA_EXT_NMI_RESET_CTRL); udelay(50); /* Wait long enough for the dust to settle */ outb(0, EISA_EXT_NMI_RESET_CTRL); - outb(0x11, EISA_INT1_CTRL); - outb(0x11, EISA_INT2_CTRL); - outb(0, EISA_INT1_MASK); - outb(8, EISA_INT2_MASK); - outb(4, EISA_INT1_MASK); - outb(2, EISA_INT2_MASK); - outb(1, EISA_INT1_MASK); - outb(1, EISA_INT2_MASK); - outb(0xfb, EISA_INT1_MASK); - outb(0xff, EISA_INT2_MASK); outb(0, EISA_DMA2_WRITE_SINGLE); - for (i = SGINT_EISA; i < (SGINT_EISA + EISA_MAX_IRQ); i++) { - if (i < (SGINT_EISA + 8)) - set_irq_chip(i, &ip22_eisa1_irq_type); - else - set_irq_chip(i, &ip22_eisa2_irq_type); - } + init_i8259_irqs(); /* Cannot use request_irq because of kmalloc not being ready at such * an early stage. Yes, I've been bitten... */ setup_irq(SGI_EISA_IRQ, &eisa_action); - setup_irq(SGINT_EISA + 2, &cascade_action); EISA_bus = 1; return 0; -- 1.4.4.4 From tsbogend@alpha.franken.de Fri Nov 23 19:52:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Nov 2007 19:52:48 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:62950 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20029230AbXKWTwJ (ORCPT ); Fri, 23 Nov 2007 19:52:09 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IveZL-0004Ev-01; Fri, 23 Nov 2007 20:52:07 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id E0A31C2E30; Fri, 23 Nov 2007 20:51:41 +0100 (CET) From: Thomas Bogendoerfer Date: Fri, 23 Nov 2007 20:40:15 +0100 Subject: [PATCH] IP22: Fix broken eeprom access by using __raw_readl/__raw_writel Message-Id: <20071123195141.E0A31C2E30@solo.franken.de> To: undisclosed-recipients:; Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17568 X-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 Signed-off-by: Thomas Bogendoerfer --- arch/mips/sgi-ip22/ip22-nvram.c | 40 ++++++++++++++++++++------------------ 1 files changed, 21 insertions(+), 19 deletions(-) diff --git a/arch/mips/sgi-ip22/ip22-nvram.c b/arch/mips/sgi-ip22/ip22-nvram.c index e19d60d..0177566 100644 --- a/arch/mips/sgi-ip22/ip22-nvram.c +++ b/arch/mips/sgi-ip22/ip22-nvram.c @@ -32,19 +32,19 @@ for (x=0; x<100000; x++) __asm__ __volatile__(""); }) #define eeprom_cs_on(ptr) ({ \ - *ptr &= ~EEPROM_DATO; \ - *ptr &= ~EEPROM_ECLK; \ - *ptr &= ~EEPROM_EPROT; \ - delay(); \ - *ptr |= EEPROM_CSEL; \ - *ptr |= EEPROM_ECLK; }) + __raw_writel(__raw_readl(ptr) & ~EEPROM_DATO, ptr); \ + __raw_writel(__raw_readl(ptr) & ~EEPROM_ECLK, ptr); \ + __raw_writel(__raw_readl(ptr) & ~EEPROM_EPROT, ptr); \ + delay(); \ + __raw_writel(__raw_readl(ptr) | EEPROM_CSEL, ptr); \ + __raw_writel(__raw_readl(ptr) | EEPROM_ECLK, ptr); }) #define eeprom_cs_off(ptr) ({ \ - *ptr &= ~EEPROM_ECLK; \ - *ptr &= ~EEPROM_CSEL; \ - *ptr |= EEPROM_EPROT; \ - *ptr |= EEPROM_ECLK; }) + __raw_writel(__raw_readl(ptr) & ~EEPROM_ECLK, ptr); \ + __raw_writel(__raw_readl(ptr) & ~EEPROM_CSEL, ptr); \ + __raw_writel(__raw_readl(ptr) | EEPROM_EPROT, ptr); \ + __raw_writel(__raw_readl(ptr) | EEPROM_ECLK, ptr); }) #define BITS_IN_COMMAND 11 /* @@ -60,15 +60,17 @@ static inline void eeprom_cmd(unsigned int *ctrl, unsigned cmd, unsigned reg) ser_cmd = cmd | (reg << (16 - BITS_IN_COMMAND)); for (i = 0; i < BITS_IN_COMMAND; i++) { if (ser_cmd & (1<<15)) /* if high order bit set */ - writel(readl(ctrl) | EEPROM_DATO, ctrl); + __raw_writel(__raw_readl(ctrl) | EEPROM_DATO, ctrl); else - writel(readl(ctrl) & ~EEPROM_DATO, ctrl); - writel(readl(ctrl) & ~EEPROM_ECLK, ctrl); - writel(readl(ctrl) | EEPROM_ECLK, ctrl); + __raw_writel(__raw_readl(ctrl) & ~EEPROM_DATO, ctrl); + __raw_writel(__raw_readl(ctrl) & ~EEPROM_ECLK, ctrl); + delay(); + __raw_writel(__raw_readl(ctrl) | EEPROM_ECLK, ctrl); + delay(); ser_cmd <<= 1; } /* see data sheet timing diagram */ - writel(readl(ctrl) & ~EEPROM_DATO, ctrl); + __raw_writel(__raw_readl(ctrl) & ~EEPROM_DATO, ctrl); } unsigned short ip22_eeprom_read(unsigned int *ctrl, int reg) @@ -76,18 +78,18 @@ unsigned short ip22_eeprom_read(unsigned int *ctrl, int reg) unsigned short res = 0; int i; - writel(readl(ctrl) & ~EEPROM_EPROT, ctrl); + __raw_writel(__raw_readl(ctrl) & ~EEPROM_EPROT, ctrl); eeprom_cs_on(ctrl); eeprom_cmd(ctrl, EEPROM_READ, reg); /* clock the data ouf of serial mem */ for (i = 0; i < 16; i++) { - writel(readl(ctrl) & ~EEPROM_ECLK, ctrl); + __raw_writel(__raw_readl(ctrl) & ~EEPROM_ECLK, ctrl); delay(); - writel(readl(ctrl) | EEPROM_ECLK, ctrl); + __raw_writel(__raw_readl(ctrl) | EEPROM_ECLK, ctrl); delay(); res <<= 1; - if (readl(ctrl) & EEPROM_DATI) + if (__raw_readl(ctrl) & EEPROM_DATI) res |= 1; } -- 1.4.4.4 From tsbogend@alpha.franken.de Fri Nov 23 19:55:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Nov 2007 19:55:27 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:6375 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20029540AbXKWTzR (ORCPT ); Fri, 23 Nov 2007 19:55:17 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IveZL-0004Ev-02; Fri, 23 Nov 2007 20:52:07 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id B86B0C2E30; Fri, 23 Nov 2007 20:51:52 +0100 (CET) From: Thomas Bogendoerfer Date: Fri, 23 Nov 2007 20:41:55 +0100 Subject: [PATCH] IP22: Fix modules for 64bit kernels by using a CKSEG2 MAP_BASE Message-Id: <20071123195152.B86B0C2E30@solo.franken.de> To: undisclosed-recipients:; Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17569 X-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 Signed-off-by: Thomas Bogendoerfer --- include/asm-mips/mach-ip22/spaces.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-mips/mach-ip22/spaces.h b/include/asm-mips/mach-ip22/spaces.h index 7f9fa6f..8264d0a 100644 --- a/include/asm-mips/mach-ip22/spaces.h +++ b/include/asm-mips/mach-ip22/spaces.h @@ -18,7 +18,7 @@ #define CAC_BASE 0xffffffff80000000 #define IO_BASE 0xffffffffa0000000 #define UNCAC_BASE 0xffffffffa0000000 -#define MAP_BASE 0xc000000000000000 +#define MAP_BASE 0xffffffffc0000000 #endif /* CONFIG_64BIT */ -- 1.4.4.4 From ricknu-0@student.ltu.se Sat Nov 24 21:22:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Nov 2007 21:22:29 +0000 (GMT) Received: from gepetto.dc.ltu.se ([130.240.42.40]:37572 "EHLO gepetto.dc.ltu.se") by ftp.linux-mips.org with ESMTP id S20031813AbXKXVWV (ORCPT ); Sat, 24 Nov 2007 21:22:21 +0000 Received: from thinktank.campus.ltu.se (thinktank.campus.luth.se [130.240.205.31]) by gepetto.dc.ltu.se (8.12.5/8.12.5) with ESMTP id lAOLMJOq013855; Sat, 24 Nov 2007 22:22:20 +0100 (MET) Date: Sat, 24 Nov 2007 22:22:19 +0100 (MET) From: Richard Knutsson To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org, Richard Knutsson Message-Id: <20071124211046.9931.46998.sendpatchset@thinktank.campus.ltu.se> Subject: [PATCH] [MIPS]: Compliment va_start() with va_end(). Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ricknu-0@student.ltu.se Precedence: bulk X-list: linux-mips Compliment va_start() with va_end(). Signed-off-by: Richard Knutsson --- ieee754.c | 2 ++ ieee754dp.c | 2 ++ ieee754sp.c | 2 ++ 3 files changed, 6 insertions(+) diff --git a/arch/mips/math-emu/ieee754.c b/arch/mips/math-emu/ieee754.c index 946aee3..cb1b682 100644 --- a/arch/mips/math-emu/ieee754.c +++ b/arch/mips/math-emu/ieee754.c @@ -108,6 +108,7 @@ int ieee754si_xcpt(int r, const char *op, ...) ax.rv.si = r; va_start(ax.ap, op); ieee754_xcpt(&ax); + va_end(ax.ap); return ax.rv.si; } @@ -122,5 +123,6 @@ s64 ieee754di_xcpt(s64 r, const char *op, ...) ax.rv.di = r; va_start(ax.ap, op); ieee754_xcpt(&ax); + va_end(ax.ap); return ax.rv.di; } diff --git a/arch/mips/math-emu/ieee754dp.c b/arch/mips/math-emu/ieee754dp.c index 3e214aa..6d2d89f 100644 --- a/arch/mips/math-emu/ieee754dp.c +++ b/arch/mips/math-emu/ieee754dp.c @@ -57,6 +57,7 @@ ieee754dp ieee754dp_xcpt(ieee754dp r, const char *op, ...) ax.rv.dp = r; va_start(ax.ap, op); ieee754_xcpt(&ax); + va_end(ax.ap); return ax.rv.dp; } @@ -83,6 +84,7 @@ ieee754dp ieee754dp_nanxcpt(ieee754dp r, const char *op, ...) ax.rv.dp = r; va_start(ax.ap, op); ieee754_xcpt(&ax); + va_end(ax.ap); return ax.rv.dp; } diff --git a/arch/mips/math-emu/ieee754sp.c b/arch/mips/math-emu/ieee754sp.c index adda851..4635340 100644 --- a/arch/mips/math-emu/ieee754sp.c +++ b/arch/mips/math-emu/ieee754sp.c @@ -58,6 +58,7 @@ ieee754sp ieee754sp_xcpt(ieee754sp r, const char *op, ...) ax.rv.sp = r; va_start(ax.ap, op); ieee754_xcpt(&ax); + va_end(ax.ap); return ax.rv.sp; } @@ -84,6 +85,7 @@ ieee754sp ieee754sp_nanxcpt(ieee754sp r, const char *op, ...) ax.rv.sp = r; va_start(ax.ap, op); ieee754_xcpt(&ax); + va_end(ax.ap); return ax.rv.sp; } From tsbogend@alpha.franken.de Sun Nov 25 02:10:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 02:10:40 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:30611 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20032282AbXKYCKc (ORCPT ); Sun, 25 Nov 2007 02:10:32 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iw6x2-0000fJ-00; Sun, 25 Nov 2007 03:10:28 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id A7B8AC222A; Sun, 25 Nov 2007 03:10:01 +0100 (CET) From: Thomas Bogendoerfer To: linux-mips@linux-mips.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org cc: ralf@linux-mips.org, akpm@linux-foundation.org Message-Id: <20071125021001.A7B8AC222A@solo.franken.de> Date: Sun, 25 Nov 2007 03:10:01 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17571 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Date: Sun, 25 Nov 2007 03:02:20 +0100 Subject: [PATCH] IP22ZILOG: fix lockup and sysrq - fix lockup when switching from early console to real console - make sysrq reliable - fix panic, if sysrq is issued before console is opened Signed-off-by: Thomas Bogendoerfer --- arch/mips/sgi-ip22/ip22-setup.c | 19 --- drivers/serial/ip22zilog.c | 247 +++++++++++++++++---------------------- include/linux/serial_core.h | 2 +- 3 files changed, 107 insertions(+), 161 deletions(-) diff --git a/arch/mips/sgi-ip22/ip22-setup.c b/arch/mips/sgi-ip22/ip22-setup.c index 174f09e..5f389ee 100644 --- a/arch/mips/sgi-ip22/ip22-setup.c +++ b/arch/mips/sgi-ip22/ip22-setup.c @@ -31,25 +31,6 @@ unsigned long sgi_gfxaddr; EXPORT_SYMBOL_GPL(sgi_gfxaddr); -/* - * Stop-A is originally a Sun thing that isn't standard on IP22 so to avoid - * accidents it's disabled by default on IP22. - * - * FIXME: provide a mechanism to change the value of stop_a_enabled. - */ -int stop_a_enabled; - -void ip22_do_break(void) -{ - if (!stop_a_enabled) - return; - - printk("\n"); - ArcEnterInteractiveMode(); -} - -EXPORT_SYMBOL(ip22_do_break); - extern void ip22_be_init(void) __init; void __init plat_mem_setup(void) diff --git a/drivers/serial/ip22zilog.c b/drivers/serial/ip22zilog.c index f3257f7..9c95bc0 100644 --- a/drivers/serial/ip22zilog.c +++ b/drivers/serial/ip22zilog.c @@ -45,8 +45,6 @@ #include "ip22zilog.h" -void ip22_do_break(void); - /* * On IP22 we need to delay after register accesses but we do not need to * flush writes. @@ -81,12 +79,9 @@ struct uart_ip22zilog_port { #define IP22ZILOG_FLAG_REGS_HELD 0x00000040 #define IP22ZILOG_FLAG_TX_STOPPED 0x00000080 #define IP22ZILOG_FLAG_TX_ACTIVE 0x00000100 +#define IP22ZILOG_FLAG_RESET_DONE 0x00000200 - unsigned int cflag; - - /* L1-A keyboard break state. */ - int kbd_id; - int l1_down; + unsigned int tty_break; unsigned char parity_mask; unsigned char prev_status; @@ -250,13 +245,26 @@ static void ip22zilog_maybe_update_regs(struct uart_ip22zilog_port *up, } } -static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, - struct zilog_channel *channel) +#define Rx_BRK 0x0100 /* BREAK event software flag. */ +#define Rx_SYS 0x0200 /* SysRq event software flag. */ + +static struct tty_struct *ip22zilog_receive_chars(struct uart_ip22zilog_port *up, + struct zilog_channel *channel) { - struct tty_struct *tty = up->port.info->tty; /* XXX info==NULL? */ + struct tty_struct *tty; + unsigned char ch, flag; + unsigned int r1; + + tty = NULL; + if (up->port.info != NULL && + up->port.info->tty != NULL) + tty = up->port.info->tty; - while (1) { - unsigned char ch, r1, flag; + for (;;) { + ch = readb(&channel->control); + ZSDELAY(); + if (!(ch & Rx_CH_AV)) + break; r1 = read_zsreg(channel, R1); if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) { @@ -265,43 +273,26 @@ static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, ZS_WSYNC(channel); } - ch = readb(&channel->control); - ZSDELAY(); - - /* This funny hack depends upon BRK_ABRT not interfering - * with the other bits we care about in R1. - */ - if (ch & BRK_ABRT) - r1 |= BRK_ABRT; - ch = readb(&channel->data); ZSDELAY(); ch &= up->parity_mask; - if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) { - /* Wait for BREAK to deassert to avoid potentially - * confusing the PROM. - */ - while (1) { - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & BRK_ABRT)) - break; - } - ip22_do_break(); - return; - } + /* Handle the null char got when BREAK is removed. */ + if (!ch) + r1 |= up->tty_break; /* A real serial line, record the character and status. */ flag = TTY_NORMAL; up->port.icount.rx++; - if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) { - if (r1 & BRK_ABRT) { - r1 &= ~(PAR_ERR | CRC_ERR); + if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR | Rx_SYS | Rx_BRK)) { + up->tty_break = 0; + + if (r1 & (Rx_SYS | Rx_BRK)) { up->port.icount.brk++; - if (uart_handle_break(&up->port)) - goto next_char; + if (r1 & Rx_SYS) + continue; + r1 &= ~(PAR_ERR | CRC_ERR); } else if (r1 & PAR_ERR) up->port.icount.parity++; @@ -310,30 +301,21 @@ static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, if (r1 & Rx_OVR) up->port.icount.overrun++; r1 &= up->port.read_status_mask; - if (r1 & BRK_ABRT) + if (r1 & Rx_BRK) flag = TTY_BREAK; else if (r1 & PAR_ERR) flag = TTY_PARITY; else if (r1 & CRC_ERR) flag = TTY_FRAME; } - if (uart_handle_sysrq_char(&up->port, ch)) - goto next_char; - if (up->port.ignore_status_mask == 0xff || - (r1 & up->port.ignore_status_mask) == 0) - tty_insert_flip_char(tty, ch, flag); + if (uart_handle_sysrq_char(&up->port, ch)) + continue; - if (r1 & Rx_OVR) - tty_insert_flip_char(tty, 0, TTY_OVERRUN); - next_char: - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & Rx_CH_AV)) - break; + if (tty) + uart_insert_char(&up->port, r1, Rx_OVR, ch, flag); } - - tty_flip_buffer_push(tty); + return tty; } static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, @@ -348,6 +330,15 @@ static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, ZSDELAY(); ZS_WSYNC(channel); + if (up->curregs[R15] & BRKIE) { + if ((status & BRK_ABRT) && !(up->prev_status & BRK_ABRT)) { + if (uart_handle_break(&up->port)) + up->tty_break = Rx_SYS; + else + up->tty_break = Rx_BRK; + } + } + if (ZS_WANTS_MODEM_STATUS(up)) { if (status & SYNC) up->port.icount.dsr++; @@ -356,10 +347,10 @@ static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, * But it does not tell us which bit has changed, we have to keep * track of this ourselves. */ - if ((status & DCD) ^ up->prev_status) + if ((status ^ up->prev_status) ^ DCD) uart_handle_dcd_change(&up->port, (status & DCD)); - if ((status & CTS) ^ up->prev_status) + if ((status ^ up->prev_status) ^ CTS) uart_handle_cts_change(&up->port, (status & CTS)); @@ -447,19 +438,21 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id) while (up) { struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + struct tty_struct *tty; unsigned char r3; spin_lock(&up->port.lock); r3 = read_zsreg(channel, R3); /* Channel A */ + tty = NULL; if (r3 & (CHAEXT | CHATxIP | CHARxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHARxIP) - ip22zilog_receive_chars(up, channel); + tty = ip22zilog_receive_chars(up, channel); if (r3 & CHAEXT) ip22zilog_status_handle(up, channel); if (r3 & CHATxIP) @@ -467,18 +460,22 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id) } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + /* Channel B */ up = up->next; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); spin_lock(&up->port.lock); + tty = NULL; if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHBRxIP) - ip22zilog_receive_chars(up, channel); + tty = ip22zilog_receive_chars(up, channel); if (r3 & CHBEXT) ip22zilog_status_handle(up, channel); if (r3 & CHBTxIP) @@ -486,6 +483,9 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id) } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + up = up->next; } @@ -681,11 +681,46 @@ static void ip22zilog_break_ctl(struct uart_port *port, int break_state) spin_unlock_irqrestore(&port->lock, flags); } +static void __ip22zilog_reset(struct uart_ip22zilog_port *up) +{ + struct zilog_channel *channel; + int i; + + if (up->flags & IP22ZILOG_FLAG_RESET_DONE) + return; + + /* Let pending transmits finish. */ + channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + for (i = 0; i < 1000; i++) { + unsigned char stat = read_zsreg(channel, R1); + if (stat & ALL_SNT) + break; + udelay(100); + } + + if (!ZS_IS_CHANNEL_A(up)) { + up++; + channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + } + write_zsreg(channel, R9, FHWRES); + ZSDELAY_LONG(); + (void) read_zsreg(channel, R0); + + up->flags |= IP22ZILOG_FLAG_RESET_DONE; + up->next->flags |= IP22ZILOG_FLAG_RESET_DONE; +} + static void __ip22zilog_startup(struct uart_ip22zilog_port *up) { struct zilog_channel *channel; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + + __ip22zilog_reset(up); + + __load_zsregs(channel, up->curregs); + /* set master interrupt enable */ + write_zsreg(channel, R9, up->curregs[R9]); up->prev_status = readb(&channel->control); /* Enable receiver and transmitter. */ @@ -859,8 +894,6 @@ ip22zilog_set_termios(struct uart_port *port, struct ktermios *termios, else up->flags &= ~IP22ZILOG_FLAG_MODEM_STATUS; - up->cflag = termios->c_cflag; - ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port)); uart_update_timeout(port, termios->c_cflag, baud); @@ -992,74 +1025,29 @@ ip22zilog_console_write(struct console *con, const char *s, unsigned int count) spin_unlock_irqrestore(&up->port.lock, flags); } -void -ip22serial_console_termios(struct console *con, char *options) -{ - int baud = 9600, bits = 8, cflag; - int parity = 'n'; - int flow = 'n'; - - if (options) - uart_parse_options(options, &baud, &parity, &bits, &flow); - - cflag = CREAD | HUPCL | CLOCAL; - - switch (baud) { - case 150: cflag |= B150; break; - case 300: cflag |= B300; break; - case 600: cflag |= B600; break; - case 1200: cflag |= B1200; break; - case 2400: cflag |= B2400; break; - case 4800: cflag |= B4800; break; - case 9600: cflag |= B9600; break; - case 19200: cflag |= B19200; break; - case 38400: cflag |= B38400; break; - default: baud = 9600; cflag |= B9600; break; - } - - con->cflag = cflag | CS8; /* 8N1 */ - - uart_update_timeout(&ip22zilog_port_table[con->index].port, cflag, baud); -} - static int __init ip22zilog_console_setup(struct console *con, char *options) { struct uart_ip22zilog_port *up = &ip22zilog_port_table[con->index]; unsigned long flags; - int baud, brg; - - printk("Console: ttyS%d (IP22-Zilog)\n", con->index); + int baud = 9600, bits = 8; + int parity = 'n'; + int flow = 'n'; - /* Get firmware console settings. */ - ip22serial_console_termios(con, options); + up->flags |= IP22ZILOG_FLAG_IS_CONS; - /* Firmware console speed is limited to 150-->38400 baud so - * this hackish cflag thing is OK. - */ - switch (con->cflag & CBAUD) { - case B150: baud = 150; break; - case B300: baud = 300; break; - case B600: baud = 600; break; - case B1200: baud = 1200; break; - case B2400: baud = 2400; break; - case B4800: baud = 4800; break; - default: case B9600: baud = 9600; break; - case B19200: baud = 19200; break; - case B38400: baud = 38400; break; - }; - - brg = BPS_TO_BRG(baud, ZS_CLOCK / ZS_CLOCK_DIVISOR); + printk(KERN_INFO "Console: ttyS%d (IP22-Zilog)\n", con->index); spin_lock_irqsave(&up->port.lock, flags); - up->curregs[R15] = BRKIE; - ip22zilog_convert_to_zs(up, con->cflag, 0, brg); + up->curregs[R15] |= BRKIE; __ip22zilog_startup(up); spin_unlock_irqrestore(&up->port.lock, flags); - return 0; + if (options) + uart_parse_options(options, &baud, &parity, &bits, &flow); + return uart_set_options(&up->port, con, baud, parity, bits, flow); } static struct uart_driver ip22zilog_reg; @@ -1140,25 +1128,10 @@ static void __init ip22zilog_prepare(void) up[(chip * 2) + 1].port.line = (chip * 2) + 1; up[(chip * 2) + 1].flags |= IP22ZILOG_FLAG_IS_CHANNEL_A; } -} - -static void __init ip22zilog_init_hw(void) -{ - int i; - - for (i = 0; i < NUM_CHANNELS; i++) { - struct uart_ip22zilog_port *up = &ip22zilog_port_table[i]; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); - unsigned long flags; - int baud, brg; - spin_lock_irqsave(&up->port.lock, flags); - - if (ZS_IS_CHANNEL_A(up)) { - write_zsreg(channel, R9, FHWRES); - ZSDELAY_LONG(); - (void) read_zsreg(channel, R0); - } + for (channel = 0; channel < NUM_CHANNELS; channel++) { + struct uart_ip22zilog_port *up = &ip22zilog_port_table[channel]; + int brg; /* Normal serial TTY. */ up->parity_mask = 0xff; @@ -1169,16 +1142,10 @@ static void __init ip22zilog_init_hw(void) up->curregs[R9] = NV | MIE; up->curregs[R10] = NRZ; up->curregs[R11] = TCBR | RCBR; - baud = 9600; - brg = BPS_TO_BRG(baud, ZS_CLOCK / ZS_CLOCK_DIVISOR); + brg = BPS_TO_BRG(9600, ZS_CLOCK / ZS_CLOCK_DIVISOR); up->curregs[R12] = (brg & 0xff); up->curregs[R13] = (brg >> 8) & 0xff; up->curregs[R14] = BRENAB; - __load_zsregs(channel, up->curregs); - /* set master interrupt enable */ - write_zsreg(channel, R9, up->curregs[R9]); - - spin_unlock_irqrestore(&up->port.lock, flags); } } @@ -1195,8 +1162,6 @@ static int __init ip22zilog_ports_init(void) panic("IP22-Zilog: Unable to register zs interrupt handler.\n"); } - ip22zilog_init_hw(); - ret = uart_register_driver(&ip22zilog_reg); if (ret == 0) { int i; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 6a5203f..9963f81 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -437,7 +437,7 @@ uart_handle_sysrq_char(struct uart_port *port, unsigned int ch) #ifdef SUPPORT_SYSRQ if (port->sysrq) { if (ch && time_before(jiffies, port->sysrq)) { - handle_sysrq(ch, port->info->tty); + handle_sysrq(ch, port->info ? port->info->tty : NULL); port->sysrq = 0; return 1; } -- 1.4.4.4 From tsbogend@alpha.franken.de Sun Nov 25 10:03:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 10:03:40 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:32941 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20031985AbXKYKDc (ORCPT ); Sun, 25 Nov 2007 10:03:32 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IwEKp-0005yB-00; Sun, 25 Nov 2007 11:03:31 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 65E83C223F; Sun, 25 Nov 2007 11:03:12 +0100 (CET) Date: Sun, 25 Nov 2007 11:03:12 +0100 To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [PATCH] IP22: Fix modules for 64bit kernels by using a CKSEG2 MAP_BASE Message-ID: <20071125100224.GA17974@alpha.franken.de> References: <20071123195152.B86B0C2E30@solo.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071123195152.B86B0C2E30@solo.franken.de> 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: 17572 X-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 Fri, Nov 23, 2007 at 08:41:55PM +0100, Thomas Bogendoerfer wrote: > > Signed-off-by: Thomas Bogendoerfer > --- > include/asm-mips/mach-ip22/spaces.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/asm-mips/mach-ip22/spaces.h b/include/asm-mips/mach-ip22/spaces.h > index 7f9fa6f..8264d0a 100644 > --- a/include/asm-mips/mach-ip22/spaces.h > +++ b/include/asm-mips/mach-ip22/spaces.h > @@ -18,7 +18,7 @@ > #define CAC_BASE 0xffffffff80000000 > #define IO_BASE 0xffffffffa0000000 > #define UNCAC_BASE 0xffffffffa0000000 > -#define MAP_BASE 0xc000000000000000 > +#define MAP_BASE 0xffffffffc0000000 > > #endif /* CONFIG_64BIT */ please drop this bogus patch, it causes vmalloc allocations fails. The bug it tries to fix isn't even there. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From share.kt@gmail.com Sun Nov 25 12:29:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 12:29:51 +0000 (GMT) Received: from wa-out-1112.google.com ([209.85.146.183]:62058 "EHLO wa-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20032663AbXKYM3n (ORCPT ); Sun, 25 Nov 2007 12:29:43 +0000 Received: by wa-out-1112.google.com with SMTP id m16so397511waf for ; Sun, 25 Nov 2007 04:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=JEiy+YF1SU11hb8V+AFo7uPH0pjIlltlFtGpWpN5+eE=; b=UCmwoIW2TpCFfP2IAWUhxIc1DgfErv8FA+FW0go9V1NGy0H+6j33e5LeVPfmq78Mo4+LHPz76+GWDO2AH43Ky2CYvdFmgE35QLzYMYq1djo4VAdG8HKq/Wnn2uKlzh+C9t5AF0jTMlImpC6z0nX9/7Kxun1tOu3q7CO2yqVA9Ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=E96zLSvffVTkbWhRF3S9n0Y4BjCLGIBepfhUimdl1Vm30fP+i9489S/TJpm9MLpcnR1chpdT+CuCjAPdIC3/EV259jhKbbwAmkuDOzmUYKKYF+mk3HixjSmNEMOykMu4RwFOnWTx/BVbsJW8T9pRyTzZUBSETdhEBeKmS080GoY= Received: by 10.114.153.18 with SMTP id a18mr34312wae.1195993770311; Sun, 25 Nov 2007 04:29:30 -0800 (PST) Received: by 10.114.158.17 with HTTP; Sun, 25 Nov 2007 04:29:30 -0800 (PST) Message-ID: Date: Sun, 25 Nov 2007 17:59:30 +0530 From: kaka To: linux-mips@linux-mips.org, uclinux-dev@uclinux.org, celinux-dev@tree.celinuxforum.org, linux-fbdev-users@lists.sourceforge.net Subject: Usage of mmap command(in directFB) Cc: directfb-users@directfb.org, directfb-dev@directfb.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_35026_14554447.1195993770305" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: share.kt@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_35026_14554447.1195993770305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset); I am providing 1.6MB as length parameter in mmap command. It is giving me error as Can't mmap region with error number EINVAL. I searched for the probable causes for EINVAL error number, and cheked it that i am satisfying all of them on the other hand when i am providing 1.384MB as length parameter in mmap command. It is successful. This mmap command is being issued from User space(from the DIrectFB code in systems/fbdev.c) The exact command which i am writing is addr = mmap(NULL, dfb_fbdev->shared->fix.mmio_len, PROT_READ | PROT_WRITE, MAO_SHARED, dfb_fbdev->fd, 0); Can anybody provide any clue on it? I want to access the mmio regs at offset (0.9MB to 1.6MB offset). Also in my system MIPS board(broadcom chip), the framebuffer driver contains support for MMIO length as 1.6MB. -- Thanks & Regards, kaka -- Thanks & Regards, kaka ------=_Part_35026_14554447.1195993770305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
 
void *mmap(void *start, size_t length, int prot, int flags,           int
fd, off_t offset);
 
I am providing 1.6MB as length parameter in mmap command.
It is giving me error as Can't mmap region with error number EINVAL. I searched for the probable causes for EINVAL error number, and cheked it that i am satisfying all of them
 
on the other hand when i am providing 1.384MB as length parameter in mmap command.
It is successful.
This mmap command is being issued from User space(from the DIrectFB code in systems/fbdev.c)
 
The exact command which i am writing is
addr = mmap(NULL, dfb_fbdev->shared->fix.mmio_len, PROT_READ | PROT_WRITE, MAO_SHARED, dfb_fbdev->fd, 0);
 
Can anybody provide any clue on it?
I want to access the mmio regs at offset (0.9MB to 1.6MB offset).
Also in my system MIPS board(broadcom chip), the framebuffer driver contains support for MMIO length as 1.6MB.

--
Thanks & Regards,
kaka


--
Thanks & Regards,
kaka ------=_Part_35026_14554447.1195993770305-- From tbm@cyrius.com Sun Nov 25 12:49:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 12:49:17 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:40718 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20032694AbXKYMtJ (ORCPT ); Sun, 25 Nov 2007 12:49:09 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 10AC9D8E0; Sun, 25 Nov 2007 12:49:02 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 7969A544F2; Sun, 25 Nov 2007 13:48:42 +0100 (CET) Date: Sun, 25 Nov 2007 13:48:42 +0100 From: Martin Michlmayr To: linux-mips@linux-mips.org Cc: manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: BigSur: garbled characters during boot Message-ID: <20071125124842.GA32479@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: 17574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips When I boot a current kernel from git on a BigSur board I get some garbled characters: Synthesized TLB store handler fastpath (31 instructions). Synthesized TLB modify handler fastpath (30 instructions). ��͡�х�������ɥ��éšï¿½ï¿½ï¿½ï¿½Bzɑ��éªb�������ѕͥ5R�Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 250436k/257568k available (2561k kernel code, 6940k reserved, 826k data, 132k init, 0k highmem) Mount-cache hash table entries: 512 Any idea what this might be? -- Martin Michlmayr http://www.cyrius.com/ From tbm@cyrius.com Sun Nov 25 12:53:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 12:53:27 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:28430 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20032706AbXKYMxT (ORCPT ); Sun, 25 Nov 2007 12:53:19 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 848A0D8E3; Sun, 25 Nov 2007 12:52:41 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 72EF5544F2; Sun, 25 Nov 2007 13:52:29 +0100 (CET) Date: Sun, 25 Nov 2007 13:52:29 +0100 From: Martin Michlmayr To: linux-mips@linux-mips.org Cc: manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: BigSur: oops loading ramdisk Message-ID: <20071125125229.GJ20922@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 17575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips With a 32 bit kernel (current git) on BigSur, I get an oops while trying to load the ramdisk: Linux version 2.6.24-rc3-g2ffbb837-dirty (tbm@em64t) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #4 Sun Nov 25 12:44:26 UTC 2007 ... RPC: Registered tcp transport module. RAMDISK: Compressed image found at block 0 VFS: Mounted root (cramfs filesystem) readonly. Freeing unused kernel memory: 132k freed CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 802931b8, ra == 802965f4 Oops[#1]: Cpu 0 $ 0 : 00000000 10001f00 00000000 00000000 $ 4 : 8ed01000 00000000 8f421df8 00000000 $ 8 : 80430000 8f472a6c 00000000 0000000e $12 : 8f00603c ffffffff 00000000 00000084 $16 : 8f4a22c0 80440000 00500001 8ed01000 $20 : 00000002 8f0147a0 00000000 00000000 $24 : 00000003 000000cd $28 : 8f420000 8f421da8 00000000 802965f4 Hi : 00000002 Lo : 82828285 epc : 802931b8 init_dev+0x8c/0x56c Not tainted ra : 802965f4 tty_open+0x148/0x330 Status: 10001f03 KERNEL EXL IE Cause : 00808008 BadVA : 00000000 PrId : 01041100 (SiByte SB1A) Modules linked in: Process swapper (pid: 1, threadinfo=8f420000, task=8f41f928) Stack : 80178a60 00000003 804487e4 8ed01000 8f421dfc 00000000 8f4a22c0 80440000 00500001 00000001 00000002 8f0147a0 00000000 00000000 00000000 802965f4 8f006d28 00000000 8f421df8 00000000 8f006d28 00000000 00000000 8048ff20 8f006d28 8f4a22c0 8f4032a0 80173018 00000000 8f413000 ffffff9c 8017bb74 00000000 80435ba0 8f4a22c0 8f006d28 00000000 80172ef8 8016df8c 80430000 ... Call Trace: [<802931b8>] init_dev+0x8c/0x56c [<802965f4>] tty_open+0x148/0x330 [<80173018>] chrdev_open+0x120/0x178 [<8016df8c>] __dentry_open+0x104/0x210 [<8016e144>] nameidata_to_filp+0x30/0x54 [<8016e1a8>] do_filp_open+0x40/0x54 [<8016e220>] do_sys_open+0x64/0x114 [<80100448>] init_post+0x30/0xe8 [<80450874>] kernel_init+0x2e4/0x314 Code: 8c8200a0 00051880 00431021 <8c510000> 162000e2 00000000 8e64003c 10800009 24020002 Kernel panic - not syncing: Attempted to kill init! Rebooting in 5 seconds..Passing control back to CFE... -- Martin Michlmayr http://www.cyrius.com/ From tbm@cyrius.com Sun Nov 25 13:02:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 13:02:34 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:63755 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20032878AbXKYNC0 (ORCPT ); Sun, 25 Nov 2007 13:02:26 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 5EA1CD8E5; Sun, 25 Nov 2007 13:01:49 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 32A69544F2; Sun, 25 Nov 2007 14:01:35 +0100 (CET) Date: Sun, 25 Nov 2007 14:01:35 +0100 From: Martin Michlmayr To: linux-mips@linux-mips.org Cc: manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: oops loading ramdisk Message-ID: <20071125130135.GM20922@deprecation.cyrius.com> References: <20071125125229.GJ20922@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125125229.GJ20922@deprecation.cyrius.com> 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: 17576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Martin Michlmayr [2007-11-25 13:52]: > With a 32 bit kernel (current git) on BigSur, I get an oops while > trying to load the ramdisk: With a 64 bit kernel I get: RAMDISK: Compressed image found at block 0 VFS: Mounted root (cramfs filesystem) readonly. Freeing unused kernel memory: 144k freed Warning: unable to open an initial console. Error -3 while decompressing! ffffffff804f2028(7120)->a800000000516000(4096) Error -3 while decompressing! ffffffff804f1280(7026)->a800000000515000(4096) request_module: runaway loop modprobe binfmt-0000 request_module: runaway loop modprobe binfmt-0000 request_module: runaway loop modprobe binfmt-0000 request_module: runaway loop modprobe binfmt-0000 request_module: runaway loop modprobe binfmt-0000 I have the following in my .config: CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_MIPS32_COMPAT=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_MIPS32_O32=y CONFIG_MIPS32_N32=y CONFIG_BINFMT_ELF32=y With 2.6.22 (64 bit) I get: Linux version 2.6.22-3-sb1a-bcm91480b (Debian 2.6.22-6) (maks@debian.org) (gcc version 4.1.3 20071019 (prerelease) (Debian 4.1.2-17)) #1 SMP Thu Nov 15 10:51:13 UTC 2007 ... RAMDISK: Compressed image found at block 0 VFS: Mounted root (cramfs filesystem) readonly. [ delay of a few seconds here -- tbm ] [DL2?] [DL2D] [DC ?] [DC D] [HELO] [L1CI] [L2CI] [CPU3] [cpu3] [CPU2] [cpu2] ... -- Martin Michlmayr http://www.cyrius.com/ From anemo@mba.ocn.ne.jp Sun Nov 25 13:27:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 13:27:21 +0000 (GMT) Received: from mba.ocn.ne.jp ([122.1.235.107]:42988 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20033066AbXKYN1N (ORCPT ); Sun, 25 Nov 2007 13:27:13 +0000 Received: from localhost (p8217-ipad401funabasi.chiba.ocn.ne.jp [123.217.242.217]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 91BAC8655; Sun, 25 Nov 2007 22:25:50 +0900 (JST) Date: Sun, 25 Nov 2007 22:28:03 +0900 (JST) Message-Id: <20071125.222803.25909189.anemo@mba.ocn.ne.jp> To: tbm@cyrius.com Cc: linux-mips@linux-mips.org, manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: garbled characters during boot From: Atsushi Nemoto In-Reply-To: <20071125124842.GA32479@deprecation.cyrius.com> References: <20071125124842.GA32479@deprecation.cyrius.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17577 X-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 T24gU3VuLCAyNSBOb3YgMjAwNyAxMzo0ODo0MiArMDEwMCwgTWFydGluIE1pY2hsbWF5ciA8dGJt QGN5cml1cy5jb20+IHdyb3RlOg0KPiBXaGVuIEkgYm9vdCBhIGN1cnJlbnQga2VybmVsIGZyb20g Z2l0IG9uIGEgQmlnU3VyIGJvYXJkIEkgZ2V0IHNvbWUNCj4gZ2FyYmxlZCBjaGFyYWN0ZXJzOg0K PiANCj4gU3ludGhlc2l6ZWQgVExCIHN0b3JlIGhhbmRsZXIgZmFzdHBhdGggKDMxIGluc3RydWN0 aW9ucykuDQo+IFN5bnRoZXNpemVkIFRMQiBtb2RpZnkgaGFuZGxlciBmYXN0cGF0aCAoMzAgaW5z dHJ1Y3Rpb25zKS4NCj4g77+977+9zaHvv73Rhe+/ve+/ve+/ve+/ve+/ve+/ve+/vcml77+977+9 6YGa77+977+977+977+9QnrJke+/ve+/vemBqmLvv73vv73vv73vv73vv73vv73vv73Rlc2lNVLv v71Jbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDE2Mzg0IChvcmRlcjogNCwgNjU1MzYg Ynl0ZXMpDQo+IE1lbW9yeTogMjUwNDM2ay8yNTc1NjhrIGF2YWlsYWJsZSAoMjU2MWsga2VybmVs IGNvZGUsIDY5NDBrIHJlc2VydmVkLCA4MjZrIGRhdGEsIDEzMmsgaW5pdCwgMGsgaGlnaG1lbSkN Cj4gTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1MTINCj4gDQo+IEFueSBpZGVhIHdo YXQgdGhpcyBtaWdodCBiZT8NCg0KRG8geW91IGVuYWJsZSBFQVJMWV9QUklOVEs/ICBJZiBzbywg dGhpcyBtaWdodCBiZSB0aGUgY29uc29sZS1oYW5kb3Zlcg0KaXNzdWUuICBPbiB0aGUgaGFuZG92 ZXIsICJjb25zb2xlIGhhbmRvdmVyOiBib290IC4uLiIgbWVzc2FnZSB3aWxsIGJlDQpwcmludGVk IGJvdGggZWFybHkgY29uc29sZSBhbmQgbmV3IGNvbnNvbGUuICBJZiB0aGV5IHdlcmUgc2FtZSBk ZXZpY2UsDQpkcml2ZXJzIG1pZ2h0IGJlIGNvbmZ1c2VkLg0KDQpJSVJDIE1hY2llaiBoYXZlIHRy aWVkIHRvIGZpeCB0aGlzIGlzc3VlIGEgd2hpbGUgYWdvIG9uIExLTUwuDQoNCi0tLQ0KQXRzdXNo aSBOZW1vdG8NCg== From tbm@cyrius.com Sun Nov 25 13:43:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 13:44:02 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:53520 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20033290AbXKYNny (ORCPT ); Sun, 25 Nov 2007 13:43:54 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id D7505D8E0; Sun, 25 Nov 2007 13:43:47 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 4C0A0544F2; Sun, 25 Nov 2007 14:43:33 +0100 (CET) Date: Sun, 25 Nov 2007 14:43:33 +0100 From: Martin Michlmayr To: linux-mips@linux-mips.org Cc: manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: garbled characters during boot Message-ID: <20071125134333.GO20922@deprecation.cyrius.com> References: <20071125124842.GA32479@deprecation.cyrius.com> <20071125.222803.25909189.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125.222803.25909189.anemo@mba.ocn.ne.jp> 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: 17578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Atsushi Nemoto [2007-11-25 22:28]: > Do you enable EARLY_PRINTK? Yes. > IIRC Maciej have tried to fix this issue a while ago on LKML. Right, I think I remember that discussion. Did anything come out of it? -- Martin Michlmayr http://www.cyrius.com/ From tbm@cyrius.com Sun Nov 25 14:26:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 14:27:07 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:23571 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20033924AbXKYO07 (ORCPT ); Sun, 25 Nov 2007 14:26:59 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id E259AD8E0; Sun, 25 Nov 2007 14:26:21 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 651CE544F2; Sun, 25 Nov 2007 15:26:03 +0100 (CET) Date: Sun, 25 Nov 2007 15:26:03 +0100 From: Martin Michlmayr To: linux-mips@linux-mips.org Cc: manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: BigSur: io_map_base not set for PCI bus 0000:00 Message-ID: <20071125142603.GQ20922@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 17579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips When I put a SATA/PATA PCI card into the first PCI slot of my BigSur, I get the following with current git: io_map_base of root PCI bus 0000:00 unset. Trying to continue but you better fix this issue or report it to linux-mips@linux-mips.org or your vendor. Kernel panic - not syncing: To avoid data corruption io_map_base MUST be set with multiple PCI domains. This doesn't happen in any of the other PCI slots but in this case the kernel doesn't seem to see the card (CFE does). CFE says: PCI[0] bus 0 slot 1/0: unknown vendor 0x1106 product 0x3249 (RAID mass storage, rev 0x50) This is with CFE 1.4.2 in LE mode. -- Martin Michlmayr http://www.cyrius.com/ From tbm@cyrius.com Sun Nov 25 14:40:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 14:40:28 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:8455 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20033936AbXKYOkU (ORCPT ); Sun, 25 Nov 2007 14:40:20 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id 883BCD8E3; Sun, 25 Nov 2007 14:39:43 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id CF64A544F2; Sun, 25 Nov 2007 15:39:31 +0100 (CET) Date: Sun, 25 Nov 2007 15:39:31 +0100 From: Martin Michlmayr To: linux-mips@linux-mips.org Cc: manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: io_map_base not set for PCI bus 0000:00 Message-ID: <20071125143931.GR20922@deprecation.cyrius.com> References: <20071125142603.GQ20922@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125142603.GQ20922@deprecation.cyrius.com> 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: 17580 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Martin Michlmayr [2007-11-25 15:26]: > io_map_base of root PCI bus 0000:00 unset. Trying to continue but you better > fix this issue or report it to linux-mips@linux-mips.org or your vendor. > Kernel panic - not syncing: To avoid data corruption io_map_base MUST be set with multiple PCI domains. > > CFE says: > PCI[0] bus 0 slot 1/0: unknown vendor 0x1106 product 0x3249 (RAID mass storage, rev 0x50) With a different card, I get: PCI[0] bus 0 slot 1/0: unknown vendor 0x1095 product 0x0680 (RAID mass storage, rev 0x02) ... nbd: registered device at major 43 sil680: 133MHz clock. scsi0 : pata_sil680 scsi1 : pata_sil680 ata1: PATA max UDMA/133 irq 8 ata2: PATA max UDMA/133 irq 8 ata1.00: ATA-6: SAMSUNG SV1021H, PJ100-13, max UDMA/33 ata1.00: 19932192 sectors, multi 0: LBA ata1.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA SAMSUNG SV1021H PJ10 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 19932192 512-byte hardware sectors (10205 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 19932192 512-byte hardware sectors (10205 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: unknown partition table ... but then it hangs here. The first card (that failed) is a SATA/PATA PCI card, this one is an old IDE PCI card. I think they conform to different PCI specs. Another difference is that CFE knows that my old IDE card is a PCIIDE card ("PCIIDE: 1 controllers found") whereas it doesn't find a PCIIDE controller for the newer card (I think CFE hard codes PCI devices so this is hardly surprising). Maybe the problem is that CFE didn't properly initialize the card? -- Martin Michlmayr http://www.cyrius.com/ From wink@saville.com Sun Nov 25 18:43:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 18:43:55 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.234]:8325 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20034985AbXKYSnp (ORCPT ); Sun, 25 Nov 2007 18:43:45 +0000 Received: by qb-out-0506.google.com with SMTP id z1so200803qbc for ; Sun, 25 Nov 2007 10:43:34 -0800 (PST) Received: by 10.140.133.16 with SMTP id g16mr716981rvd.1196016214125; Sun, 25 Nov 2007 10:43:34 -0800 (PST) Received: from ?192.168.0.111? ( [70.91.206.233]) by mx.google.com with ESMTPS id b39sm1442524rvf.2007.11.25.10.43.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Nov 2007 10:43:33 -0800 (PST) Message-ID: <4749C258.8020400@saville.com> Date: Sun, 25 Nov 2007 10:43:36 -0800 From: Wink Saville User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Tool chain for linux using mips Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wink@saville.com Precedence: bulk X-list: linux-mips Hello, I was wondering which MIPS tool chains people are using and recommend, prebuilt and/or roll-your-own. From http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ there doesn't seem to be any combination that builds cleanly for the mips/mipsel. Regards, Wink Saville From wd@denx.de Sun Nov 25 19:22:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 19:22:21 +0000 (GMT) Received: from mail-out.m-online.net ([212.18.0.9]:42181 "EHLO mail-out.m-online.net") by ftp.linux-mips.org with ESMTP id S20035114AbXKYTWJ (ORCPT ); Sun, 25 Nov 2007 19:22:09 +0000 Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 6D50F26857D; Sun, 25 Nov 2007 20:22:58 +0100 (CET) X-Auth-Info: 4sAlZLa4IfZjgKGaCaU+dNC3SC+J2vxiYXMuhDZ9g+A= X-Auth-Info: 4sAlZLa4IfZjgKGaCaU+dNC3SC+J2vxiYXMuhDZ9g+A= Received: from mail.denx.de (p5B0DDF5F.dip.t-dialin.net [91.13.223.95]) by smtp-auth.mnet-online.de (Postfix) with ESMTP id 19F59903DA; Sun, 25 Nov 2007 20:22:03 +0100 (CET) Received: from gemini.denx.de (gemini.denx.de [10.0.0.2]) by mail.denx.de (Postfix) with ESMTP id 728086D00A7; Sun, 25 Nov 2007 20:22:03 +0100 (CET) Received: from gemini.denx.de (localhost.localdomain [127.0.0.1]) by gemini.denx.de (Postfix) with ESMTP id 4C777246B5; Sun, 25 Nov 2007 20:22:03 +0100 (MET) To: Wink Saville cc: linux-mips@linux-mips.org From: Wolfgang Denk Subject: Re: Tool chain for linux using mips Mime-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In-reply-to: Your message of "Sun, 25 Nov 2007 10:43:36 PST." <4749C258.8020400@saville.com> Date: Sun, 25 Nov 2007 20:22:03 +0100 Message-Id: <20071125192203.4C777246B5@gemini.denx.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17582 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wd@denx.de Precedence: bulk X-list: linux-mips In message <4749C258.8020400@saville.com> you wrote: > > I was wondering which MIPS tool chains people are > using and recommend, prebuilt and/or roll-your-own. > From http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ > there doesn't seem to be any combination that builds cleanly > for the mips/mipsel. Well, we use the ELDK, obviously. See http://www.denx.de/wiki/view/DULG/ELDK. For the ELDK mailing list please see http://lists.denx.de/mailman/listinfo/eldk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Accident: A condition in which presence of mind is good, but absence of body is better. From tsbogend@alpha.franken.de Sun Nov 25 22:18:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Nov 2007 22:18:16 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:57059 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20035418AbXKYWSI (ORCPT ); Sun, 25 Nov 2007 22:18:08 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IwPng-00072C-00; Sun, 25 Nov 2007 23:18:04 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 1E21DC2241; Sun, 25 Nov 2007 23:17:17 +0100 (CET) Date: Sun, 25 Nov 2007 23:17:17 +0100 To: Atsushi Nemoto Cc: tbm@cyrius.com, linux-mips@linux-mips.org, manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: garbled characters during boot Message-ID: <20071125221717.GA11406@alpha.franken.de> References: <20071125124842.GA32479@deprecation.cyrius.com> <20071125.222803.25909189.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125.222803.25909189.anemo@mba.ocn.ne.jp> 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: 17583 X-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 Sun, Nov 25, 2007 at 10:28:03PM +0900, Atsushi Nemoto wrote: > Do you enable EARLY_PRINTK? If so, this might be the console-handover > issue. On the handover, "console handover: boot ..." message will be > printed both early console and new console. If they were same device, > drivers might be confused. it will not be printed on both consoles, but while early console is active the real console driver does things to the serial chip, which might confuse the early console driver/prom. > IIRC Maciej have tried to fix this issue a while ago on LKML. this didn't work out for ip22zilog, so I digged through the mess. I solved the problem by setting up the chip in one go. Before there was some chip setup during probing, which killed prom_putchar(). Thomas -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From markus.gothe@27m.se Mon Nov 26 09:40:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 09:40:47 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:63709 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20038801AbXKZJkg (ORCPT ); Mon, 26 Nov 2007 09:40:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7440D200A1D1; Mon, 26 Nov 2007 10:40:34 +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 19607-01-69; Mon, 26 Nov 2007 10:40:34 +0100 (CET) Received: from [192.168.27.166] (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 0BFC0200A1D0; Mon, 26 Nov 2007 10:40:33 +0100 (CET) Message-ID: <474A93C7.7010101@27m.se> Date: Mon, 26 Nov 2007 10:37:11 +0100 From: Markus Gothe User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Wink Saville Cc: linux-mips@linux-mips.org Subject: Re: [SPAM] Tool chain for linux using mips References: <4749C258.8020400@saville.com> In-Reply-To: <4749C258.8020400@saville.com> X-Enigmail-Version: 0.95.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: 17584 X-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 Hi, see http://wiki.debian.org/BuildingCrossCompilers for Debian-based systems. //Markus Wink Saville wrote: > Hello, > > I was wondering which MIPS tool chains people are using and > recommend, prebuilt and/or roll-your-own. From > http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ there > doesn't seem to be any combination that builds cleanly for the > mips/mipsel. > > Regards, > > Wink Saville > > - -- _______________________________________ 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 iD8DBQFHSpPF6I0XmJx2NrwRCIstAKCsVP/rD4WbrgEF4D9ZItDpBIABjQCcCXYd V4dkQ1XDMEPwAW11wJhUQZs= =o/UK -----END PGP SIGNATURE----- From sbrown@cortland.com Mon Nov 26 11:06:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 11:06:19 +0000 (GMT) Received: from spamgate.koyote.com ([204.11.24.49]:41602 "EHLO spamgate.koyote.com") by ftp.linux-mips.org with ESMTP id S20038869AbXKZLGI (ORCPT ); Mon, 26 Nov 2007 11:06:08 +0000 Received: from localhost (test [127.0.0.1]) by spamgate.koyote.com (Postfix) with ESMTP id 5F611CBA28; Mon, 26 Nov 2007 05:03:24 -0600 (CST) Received: from spamgate.koyote.com ([127.0.0.1]) by localhost (spamgate.koyote.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id mbFQadzg8+nq; Mon, 26 Nov 2007 05:03:21 -0600 (CST) Received: from mail.localdomain (mail.enetonline.net [204.11.24.29]) by spamgate.koyote.com (Postfix) with ESMTP id E77C5CB9BC; Mon, 26 Nov 2007 05:03:21 -0600 (CST) Received: from mythtv.ewol.com (unknown [66.209.47.173]) by mail.localdomain (Postfix) with ESMTP id C3726792DE7; Mon, 26 Nov 2007 05:05:30 -0600 (CST) Message-ID: <474AA87D.7000509@cortland.com> Date: Mon, 26 Nov 2007 06:05:33 -0500 From: Steve Brown User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Michael Buesch CC: "John W. Linville" , linux-mips@linux-mips.org Subject: Re: ohci-ssb driver on a Broadcom BCM5354 References: <47408305.5090804@cortland.com> <20071118224752.GB12263@tuxdriver.com> <200711191923.56471.mb@bu3sch.de> In-Reply-To: <200711191923.56471.mb@bu3sch.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sbrown@cortland.com Precedence: bulk X-list: linux-mips Michael Buesch wrote: > On Sunday 18 November 2007 23:47:52 John W. Linville wrote: > >> You probably want to make Michael Buesch aware of this issue. >> > > I'm not sure anyone really tested this beyond some insmod tests. > I did not test this, as I don't have such a device. > So if you have any patches to fix this, please send them. I'm > certainly the wrong person who can fix this. ;) > > Adding the following at the end of ssb_ohci_attach seems to fix the problem. if (ssb_dma_set_mask(dev, DMA_32BIT_MASK)) return -EOPNOTSUPP; I guessed at the dma mask. Would the code in the b43 driver that selects a dma mask be appropriate here? Steve From macro@linux-mips.org Mon Nov 26 11:35:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 11:35:53 +0000 (GMT) Received: from cerber.ds.pg.gda.pl ([153.19.208.18]:37348 "EHLO cerber.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038904AbXKZLfn (ORCPT ); Mon, 26 Nov 2007 11:35:43 +0000 Received: from localhost (unknown [127.0.0.17]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 5BE2B40003; Mon, 26 Nov 2007 12:35:13 +0100 (CET) X-Virus-Scanned: amavisd-new at cerber.ds.pg.gda.pl Received: from cerber.ds.pg.gda.pl ([153.19.208.18]) by localhost (cerber.ds.pg.gda.pl [153.19.208.18]) (amavisd-new, port 10024) with ESMTP id tVArfQIO7xjT; Mon, 26 Nov 2007 12:34:55 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by cerber.ds.pg.gda.pl (Postfix) with ESMTP id 6B3A3400AB; Mon, 26 Nov 2007 12:34:55 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id lAQBYv9s024818; Mon, 26 Nov 2007 12:34:57 +0100 Date: Mon, 26 Nov 2007 11:34:50 +0000 (GMT) From: "Maciej W. Rozycki" To: Martin Michlmayr cc: linux-mips@linux-mips.org, manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: garbled characters during boot In-Reply-To: <20071125134333.GO20922@deprecation.cyrius.com> Message-ID: References: <20071125124842.GA32479@deprecation.cyrius.com> <20071125.222803.25909189.anemo@mba.ocn.ne.jp> <20071125134333.GO20922@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4923/Mon Nov 26 11:46:15 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, 25 Nov 2007, Martin Michlmayr wrote: > > IIRC Maciej have tried to fix this issue a while ago on LKML. > > Right, I think I remember that discussion. Did anything come out > of it? The exact mess encountered is specific to the chip/board used. I haven't seen too much of clutter on my SWARM, so I just disregarded the issue. If this is found problematic, I may have a look at the driver to see if anything can be done. At least CFE sources are available, so if it turns out to be an issue there, it can be fixed too. All the relevant registers in the DUART are r/w, so the state can easily be examined and preserved if need be. But please feel free to complain to the author of the change -- I am not sure if the amount of breakage throughout systems is justified by the gain from the additional message. And there may be a way to implement it in a less intrusive way. Maciej From mb@bu3sch.de Mon Nov 26 14:17:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 14:18:03 +0000 (GMT) Received: from static-ip-62-75-166-246.inaddr.intergenia.de ([62.75.166.246]:35270 "EHLO vs166246.vserver.de") by ftp.linux-mips.org with ESMTP id S20038971AbXKZORw (ORCPT ); Mon, 26 Nov 2007 14:17:52 +0000 Received: from t0b61.t.pppool.de ([89.55.11.97] helo=powermac.local) by vs166246.vserver.de with esmtpa (Exim 4.63) (envelope-from ) id 1Iwela-00036c-1t; Mon, 26 Nov 2007 14:16:54 +0000 From: Michael Buesch To: Steve Brown Subject: Re: ohci-ssb driver on a Broadcom BCM5354 Date: Mon, 26 Nov 2007 15:15:42 +0100 User-Agent: KMail/1.9.6 Cc: "John W. Linville" , linux-mips@linux-mips.org References: <47408305.5090804@cortland.com> <200711191923.56471.mb@bu3sch.de> <474AA87D.7000509@cortland.com> In-Reply-To: <474AA87D.7000509@cortland.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711261515.42501.mb@bu3sch.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mb@bu3sch.de Precedence: bulk X-list: linux-mips On Monday 26 November 2007 12:05:33 Steve Brown wrote: > Michael Buesch wrote: > > On Sunday 18 November 2007 23:47:52 John W. Linville wrote: > > > >> You probably want to make Michael Buesch aware of this issue. > >> > > > > I'm not sure anyone really tested this beyond some insmod tests. > > I did not test this, as I don't have such a device. > > So if you have any patches to fix this, please send them. I'm > > certainly the wrong person who can fix this. ;) > > > > > Adding the following at the end of ssb_ohci_attach seems to fix the problem. > > if (ssb_dma_set_mask(dev, DMA_32BIT_MASK)) > return -EOPNOTSUPP; > > I guessed at the dma mask. Would the code in the b43 driver that selects > a dma mask be appropriate here? I have no idea. If it makes it work, yeah. Cool. Let's add this. -- Greetings Michael. From ralf@linux-mips.org Mon Nov 26 14:46:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 14:46:32 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:22691 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039032AbXKZOqa (ORCPT ); Mon, 26 Nov 2007 14:46:30 +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 lAQEjiGX021476; Mon, 26 Nov 2007 14:45:45 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAQEjhEa021475; Mon, 26 Nov 2007 14:45:43 GMT Date: Mon, 26 Nov 2007 14:45:43 +0000 From: Ralf Baechle To: Martin Michlmayr Cc: linux-mips@linux-mips.org, manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: oops loading ramdisk Message-ID: <20071126144543.GA19679@linux-mips.org> References: <20071125125229.GJ20922@deprecation.cyrius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125125229.GJ20922@deprecation.cyrius.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Nov 25, 2007 at 01:52:29PM +0100, Martin Michlmayr wrote: > With a 32 bit kernel (current git) on BigSur, I get an oops while > trying to load the ramdisk: > > Linux version 2.6.24-rc3-g2ffbb837-dirty (tbm@em64t) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #4 Sun Nov 25 12:44:26 UTC 2007 I've just modified the memory initialization code significantly to add support for ZONE_DMA32 for the Sibyte boxes, so could you retest? Thanks, Ralf From tsbogend@alpha.franken.de Mon Nov 26 16:09:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 16:09:31 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:27842 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20039114AbXKZQJT (ORCPT ); Mon, 26 Nov 2007 16:09:19 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1IwgTH-0006qF-00; Mon, 26 Nov 2007 17:06:07 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 507EAC2B22; Mon, 26 Nov 2007 17:05:38 +0100 (CET) From: Thomas Bogendoerfer To: linux-mips@linux-mips.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org cc: ralf@linux-mips.org, akpm@linux-foundation.org Date: Mon, 26 Nov 2007 16:58:03 +0100 Subject: [UPDATED PATCH] IP22ZILOG: fix lockup and sysrq Message-Id: <20071126160538.507EAC2B22@solo.franken.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17589 X-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 - fix lockup when switching from early console to real console - make sysrq reliable - fix panic, if sysrq is issued before console is opened Signed-off-by: Thomas Bogendoerfer --- arch/mips/sgi-ip22/ip22-setup.c | 19 --- drivers/serial/ip22zilog.c | 247 +++++++++++++++++---------------------- include/asm-mips/system.h | 2 - include/linux/serial_core.h | 2 +- 4 files changed, 107 insertions(+), 163 deletions(-) diff --git a/arch/mips/sgi-ip22/ip22-setup.c b/arch/mips/sgi-ip22/ip22-setup.c index 174f09e..5f389ee 100644 --- a/arch/mips/sgi-ip22/ip22-setup.c +++ b/arch/mips/sgi-ip22/ip22-setup.c @@ -31,25 +31,6 @@ unsigned long sgi_gfxaddr; EXPORT_SYMBOL_GPL(sgi_gfxaddr); -/* - * Stop-A is originally a Sun thing that isn't standard on IP22 so to avoid - * accidents it's disabled by default on IP22. - * - * FIXME: provide a mechanism to change the value of stop_a_enabled. - */ -int stop_a_enabled; - -void ip22_do_break(void) -{ - if (!stop_a_enabled) - return; - - printk("\n"); - ArcEnterInteractiveMode(); -} - -EXPORT_SYMBOL(ip22_do_break); - extern void ip22_be_init(void) __init; void __init plat_mem_setup(void) diff --git a/drivers/serial/ip22zilog.c b/drivers/serial/ip22zilog.c index f3257f7..9c95bc0 100644 --- a/drivers/serial/ip22zilog.c +++ b/drivers/serial/ip22zilog.c @@ -45,8 +45,6 @@ #include "ip22zilog.h" -void ip22_do_break(void); - /* * On IP22 we need to delay after register accesses but we do not need to * flush writes. @@ -81,12 +79,9 @@ struct uart_ip22zilog_port { #define IP22ZILOG_FLAG_REGS_HELD 0x00000040 #define IP22ZILOG_FLAG_TX_STOPPED 0x00000080 #define IP22ZILOG_FLAG_TX_ACTIVE 0x00000100 +#define IP22ZILOG_FLAG_RESET_DONE 0x00000200 - unsigned int cflag; - - /* L1-A keyboard break state. */ - int kbd_id; - int l1_down; + unsigned int tty_break; unsigned char parity_mask; unsigned char prev_status; @@ -250,13 +245,26 @@ static void ip22zilog_maybe_update_regs(struct uart_ip22zilog_port *up, } } -static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, - struct zilog_channel *channel) +#define Rx_BRK 0x0100 /* BREAK event software flag. */ +#define Rx_SYS 0x0200 /* SysRq event software flag. */ + +static struct tty_struct *ip22zilog_receive_chars(struct uart_ip22zilog_port *up, + struct zilog_channel *channel) { - struct tty_struct *tty = up->port.info->tty; /* XXX info==NULL? */ + struct tty_struct *tty; + unsigned char ch, flag; + unsigned int r1; + + tty = NULL; + if (up->port.info != NULL && + up->port.info->tty != NULL) + tty = up->port.info->tty; - while (1) { - unsigned char ch, r1, flag; + for (;;) { + ch = readb(&channel->control); + ZSDELAY(); + if (!(ch & Rx_CH_AV)) + break; r1 = read_zsreg(channel, R1); if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) { @@ -265,43 +273,26 @@ static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, ZS_WSYNC(channel); } - ch = readb(&channel->control); - ZSDELAY(); - - /* This funny hack depends upon BRK_ABRT not interfering - * with the other bits we care about in R1. - */ - if (ch & BRK_ABRT) - r1 |= BRK_ABRT; - ch = readb(&channel->data); ZSDELAY(); ch &= up->parity_mask; - if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) { - /* Wait for BREAK to deassert to avoid potentially - * confusing the PROM. - */ - while (1) { - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & BRK_ABRT)) - break; - } - ip22_do_break(); - return; - } + /* Handle the null char got when BREAK is removed. */ + if (!ch) + r1 |= up->tty_break; /* A real serial line, record the character and status. */ flag = TTY_NORMAL; up->port.icount.rx++; - if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) { - if (r1 & BRK_ABRT) { - r1 &= ~(PAR_ERR | CRC_ERR); + if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR | Rx_SYS | Rx_BRK)) { + up->tty_break = 0; + + if (r1 & (Rx_SYS | Rx_BRK)) { up->port.icount.brk++; - if (uart_handle_break(&up->port)) - goto next_char; + if (r1 & Rx_SYS) + continue; + r1 &= ~(PAR_ERR | CRC_ERR); } else if (r1 & PAR_ERR) up->port.icount.parity++; @@ -310,30 +301,21 @@ static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, if (r1 & Rx_OVR) up->port.icount.overrun++; r1 &= up->port.read_status_mask; - if (r1 & BRK_ABRT) + if (r1 & Rx_BRK) flag = TTY_BREAK; else if (r1 & PAR_ERR) flag = TTY_PARITY; else if (r1 & CRC_ERR) flag = TTY_FRAME; } - if (uart_handle_sysrq_char(&up->port, ch)) - goto next_char; - if (up->port.ignore_status_mask == 0xff || - (r1 & up->port.ignore_status_mask) == 0) - tty_insert_flip_char(tty, ch, flag); + if (uart_handle_sysrq_char(&up->port, ch)) + continue; - if (r1 & Rx_OVR) - tty_insert_flip_char(tty, 0, TTY_OVERRUN); - next_char: - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & Rx_CH_AV)) - break; + if (tty) + uart_insert_char(&up->port, r1, Rx_OVR, ch, flag); } - - tty_flip_buffer_push(tty); + return tty; } static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, @@ -348,6 +330,15 @@ static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, ZSDELAY(); ZS_WSYNC(channel); + if (up->curregs[R15] & BRKIE) { + if ((status & BRK_ABRT) && !(up->prev_status & BRK_ABRT)) { + if (uart_handle_break(&up->port)) + up->tty_break = Rx_SYS; + else + up->tty_break = Rx_BRK; + } + } + if (ZS_WANTS_MODEM_STATUS(up)) { if (status & SYNC) up->port.icount.dsr++; @@ -356,10 +347,10 @@ static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, * But it does not tell us which bit has changed, we have to keep * track of this ourselves. */ - if ((status & DCD) ^ up->prev_status) + if ((status ^ up->prev_status) ^ DCD) uart_handle_dcd_change(&up->port, (status & DCD)); - if ((status & CTS) ^ up->prev_status) + if ((status ^ up->prev_status) ^ CTS) uart_handle_cts_change(&up->port, (status & CTS)); @@ -447,19 +438,21 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id) while (up) { struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + struct tty_struct *tty; unsigned char r3; spin_lock(&up->port.lock); r3 = read_zsreg(channel, R3); /* Channel A */ + tty = NULL; if (r3 & (CHAEXT | CHATxIP | CHARxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHARxIP) - ip22zilog_receive_chars(up, channel); + tty = ip22zilog_receive_chars(up, channel); if (r3 & CHAEXT) ip22zilog_status_handle(up, channel); if (r3 & CHATxIP) @@ -467,18 +460,22 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id) } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + /* Channel B */ up = up->next; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); spin_lock(&up->port.lock); + tty = NULL; if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHBRxIP) - ip22zilog_receive_chars(up, channel); + tty = ip22zilog_receive_chars(up, channel); if (r3 & CHBEXT) ip22zilog_status_handle(up, channel); if (r3 & CHBTxIP) @@ -486,6 +483,9 @@ static irqreturn_t ip22zilog_interrupt(int irq, void *dev_id) } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + up = up->next; } @@ -681,11 +681,46 @@ static void ip22zilog_break_ctl(struct uart_port *port, int break_state) spin_unlock_irqrestore(&port->lock, flags); } +static void __ip22zilog_reset(struct uart_ip22zilog_port *up) +{ + struct zilog_channel *channel; + int i; + + if (up->flags & IP22ZILOG_FLAG_RESET_DONE) + return; + + /* Let pending transmits finish. */ + channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + for (i = 0; i < 1000; i++) { + unsigned char stat = read_zsreg(channel, R1); + if (stat & ALL_SNT) + break; + udelay(100); + } + + if (!ZS_IS_CHANNEL_A(up)) { + up++; + channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + } + write_zsreg(channel, R9, FHWRES); + ZSDELAY_LONG(); + (void) read_zsreg(channel, R0); + + up->flags |= IP22ZILOG_FLAG_RESET_DONE; + up->next->flags |= IP22ZILOG_FLAG_RESET_DONE; +} + static void __ip22zilog_startup(struct uart_ip22zilog_port *up) { struct zilog_channel *channel; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + + __ip22zilog_reset(up); + + __load_zsregs(channel, up->curregs); + /* set master interrupt enable */ + write_zsreg(channel, R9, up->curregs[R9]); up->prev_status = readb(&channel->control); /* Enable receiver and transmitter. */ @@ -859,8 +894,6 @@ ip22zilog_set_termios(struct uart_port *port, struct ktermios *termios, else up->flags &= ~IP22ZILOG_FLAG_MODEM_STATUS; - up->cflag = termios->c_cflag; - ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port)); uart_update_timeout(port, termios->c_cflag, baud); @@ -992,74 +1025,29 @@ ip22zilog_console_write(struct console *con, const char *s, unsigned int count) spin_unlock_irqrestore(&up->port.lock, flags); } -void -ip22serial_console_termios(struct console *con, char *options) -{ - int baud = 9600, bits = 8, cflag; - int parity = 'n'; - int flow = 'n'; - - if (options) - uart_parse_options(options, &baud, &parity, &bits, &flow); - - cflag = CREAD | HUPCL | CLOCAL; - - switch (baud) { - case 150: cflag |= B150; break; - case 300: cflag |= B300; break; - case 600: cflag |= B600; break; - case 1200: cflag |= B1200; break; - case 2400: cflag |= B2400; break; - case 4800: cflag |= B4800; break; - case 9600: cflag |= B9600; break; - case 19200: cflag |= B19200; break; - case 38400: cflag |= B38400; break; - default: baud = 9600; cflag |= B9600; break; - } - - con->cflag = cflag | CS8; /* 8N1 */ - - uart_update_timeout(&ip22zilog_port_table[con->index].port, cflag, baud); -} - static int __init ip22zilog_console_setup(struct console *con, char *options) { struct uart_ip22zilog_port *up = &ip22zilog_port_table[con->index]; unsigned long flags; - int baud, brg; - - printk("Console: ttyS%d (IP22-Zilog)\n", con->index); + int baud = 9600, bits = 8; + int parity = 'n'; + int flow = 'n'; - /* Get firmware console settings. */ - ip22serial_console_termios(con, options); + up->flags |= IP22ZILOG_FLAG_IS_CONS; - /* Firmware console speed is limited to 150-->38400 baud so - * this hackish cflag thing is OK. - */ - switch (con->cflag & CBAUD) { - case B150: baud = 150; break; - case B300: baud = 300; break; - case B600: baud = 600; break; - case B1200: baud = 1200; break; - case B2400: baud = 2400; break; - case B4800: baud = 4800; break; - default: case B9600: baud = 9600; break; - case B19200: baud = 19200; break; - case B38400: baud = 38400; break; - }; - - brg = BPS_TO_BRG(baud, ZS_CLOCK / ZS_CLOCK_DIVISOR); + printk(KERN_INFO "Console: ttyS%d (IP22-Zilog)\n", con->index); spin_lock_irqsave(&up->port.lock, flags); - up->curregs[R15] = BRKIE; - ip22zilog_convert_to_zs(up, con->cflag, 0, brg); + up->curregs[R15] |= BRKIE; __ip22zilog_startup(up); spin_unlock_irqrestore(&up->port.lock, flags); - return 0; + if (options) + uart_parse_options(options, &baud, &parity, &bits, &flow); + return uart_set_options(&up->port, con, baud, parity, bits, flow); } static struct uart_driver ip22zilog_reg; @@ -1140,25 +1128,10 @@ static void __init ip22zilog_prepare(void) up[(chip * 2) + 1].port.line = (chip * 2) + 1; up[(chip * 2) + 1].flags |= IP22ZILOG_FLAG_IS_CHANNEL_A; } -} - -static void __init ip22zilog_init_hw(void) -{ - int i; - - for (i = 0; i < NUM_CHANNELS; i++) { - struct uart_ip22zilog_port *up = &ip22zilog_port_table[i]; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); - unsigned long flags; - int baud, brg; - spin_lock_irqsave(&up->port.lock, flags); - - if (ZS_IS_CHANNEL_A(up)) { - write_zsreg(channel, R9, FHWRES); - ZSDELAY_LONG(); - (void) read_zsreg(channel, R0); - } + for (channel = 0; channel < NUM_CHANNELS; channel++) { + struct uart_ip22zilog_port *up = &ip22zilog_port_table[channel]; + int brg; /* Normal serial TTY. */ up->parity_mask = 0xff; @@ -1169,16 +1142,10 @@ static void __init ip22zilog_init_hw(void) up->curregs[R9] = NV | MIE; up->curregs[R10] = NRZ; up->curregs[R11] = TCBR | RCBR; - baud = 9600; - brg = BPS_TO_BRG(baud, ZS_CLOCK / ZS_CLOCK_DIVISOR); + brg = BPS_TO_BRG(9600, ZS_CLOCK / ZS_CLOCK_DIVISOR); up->curregs[R12] = (brg & 0xff); up->curregs[R13] = (brg >> 8) & 0xff; up->curregs[R14] = BRENAB; - __load_zsregs(channel, up->curregs); - /* set master interrupt enable */ - write_zsreg(channel, R9, up->curregs[R9]); - - spin_unlock_irqrestore(&up->port.lock, flags); } } @@ -1195,8 +1162,6 @@ static int __init ip22zilog_ports_init(void) panic("IP22-Zilog: Unable to register zs interrupt handler.\n"); } - ip22zilog_init_hw(); - ret = uart_register_driver(&ip22zilog_reg); if (ret == 0) { int i; diff --git a/include/asm-mips/system.h b/include/asm-mips/system.h index 1030562..a944eda 100644 --- a/include/asm-mips/system.h +++ b/include/asm-mips/system.h @@ -209,8 +209,6 @@ extern void *set_except_vector(int n, void *addr); extern unsigned long ebase; extern void per_cpu_trap_init(void); -extern int stop_a_enabled; - /* * See include/asm-ia64/system.h; prevents deadlock on SMP * systems. diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 6a5203f..9963f81 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -437,7 +437,7 @@ uart_handle_sysrq_char(struct uart_port *port, unsigned int ch) #ifdef SUPPORT_SYSRQ if (port->sysrq) { if (ch && time_before(jiffies, port->sysrq)) { - handle_sysrq(ch, port->info->tty); + handle_sysrq(ch, port->info ? port->info->tty : NULL); port->sysrq = 0; return 1; } -- 1.4.4.4 From tbm@cyrius.com Mon Nov 26 16:18:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 16:18:24 +0000 (GMT) Received: from sorrow.cyrius.com ([65.19.161.204]:8967 "EHLO sorrow.cyrius.com") by ftp.linux-mips.org with ESMTP id S20039134AbXKZQSM (ORCPT ); Mon, 26 Nov 2007 16:18:12 +0000 Received: by sorrow.cyrius.com (Postfix, from userid 10) id B87A9D8E0; Mon, 26 Nov 2007 16:17:34 +0000 (UTC) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id A679E544F2; Mon, 26 Nov 2007 17:17:20 +0100 (CET) Date: Mon, 26 Nov 2007 17:17:20 +0100 From: Martin Michlmayr To: Ralf Baechle Cc: linux-mips@linux-mips.org, manoj.ekbote@broadcom.com, mark.e.mason@broadcom.com Subject: Re: BigSur: oops loading ramdisk Message-ID: <20071126161720.GD23315@deprecation.cyrius.com> References: <20071125125229.GJ20922@deprecation.cyrius.com> <20071126144543.GA19679@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071126144543.GA19679@linux-mips.org> 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: 17590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tbm@cyrius.com Precedence: bulk X-list: linux-mips * Ralf Baechle [2007-11-26 14:45]: > > With a 32 bit kernel (current git) on BigSur, I get an oops while > > trying to load the ramdisk: > I've just modified the memory initialization code significantly to add > support for ZONE_DMA32 for the Sibyte boxes, so could you retest? Same problem with your patch (current Linus git plus your patch): Freeing unused kernel memory: 136k freed CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 8029a238, ra == 8029d674 Oops[#1]: Cpu 0 $ 0 : 00000000 10001f00 00000000 00000000 $ 4 : 8e89f000 00000000 8f421df8 00000000 $ 8 : 80440000 8e889a6c 00000000 0000000e $12 : 8ec6903c ffffffff 00000000 00000088 $16 : 8eda0240 80450000 00500001 8e89f000 $20 : 00000002 8f00d114 00000000 00000000 $24 : 00000003 000000cd $28 : 8f420000 8f421da8 00000000 8029d674 Hi : 00000002 Lo : 82828285 epc : 8029a238 init_dev+0x8c/0x56c Not tainted ra : 8029d674 tty_open+0x148/0x330 Status: 10001f03 KERNEL EXL IE Cause : 00808008 BadVA : 00000000 PrId : 01041100 (SiByte SB1A) Modules linked in: Process swapper (pid: 1, threadinfo=8f420000, task=8f41f928) Stack : 801789f0 00000003 8044e874 8e89f000 8f421dfc 00000000 8eda0240 80450000 00500001 00000001 00000002 8f00d114 00000000 00000000 00000000 8029d674 8ec69d28 00000000 8f421df8 00000000 8ec69d28 00000000 00000000 80496fe0 8ec69d28 8eda0240 8f4032a0 80172fa8 00000000 8f413000 ffffff9c 8017bb04 00000000 8043bba0 8eda0240 8ec69d28 00000000 80172e88 8016df1c 80440000 ... Call Trace: [<8029a238>] init_dev+0x8c/0x56c [<8029d674>] tty_open+0x148/0x330 [<80172fa8>] chrdev_open+0x120/0x178 [<8016df1c>] __dentry_open+0x104/0x210 [<8016e0d4>] nameidata_to_filp+0x30/0x54 [<8016e138>] do_filp_open+0x40/0x54 [<8016e1b0>] do_sys_open+0x64/0x114 [<80100448>] init_post+0x30/0xe8 [<80456874>] kernel_init+0x2e4/0x314 Code: 8c8200a0 00051880 00431021 <8c510000> 162000e2 00000000 8e64003c 10800009 24020002 Kernel panic - not syncing: Attempted to kill init! -- Martin Michlmayr http://www.cyrius.com/ From ralf@linux-mips.org Mon Nov 26 16:20:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 16:20:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:43958 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039146AbXKZQUU (ORCPT ); Mon, 26 Nov 2007 16:20:20 +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 lAQGJWLD023229; Mon, 26 Nov 2007 16:19:33 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAQGJVoE023228; Mon, 26 Nov 2007 16:19:31 GMT Date: Mon, 26 Nov 2007 16:19:31 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org Subject: Re: [UPDATED PATCH] IP22ZILOG: fix lockup and sysrq Message-ID: <20071126161931.GA22879@linux-mips.org> References: <20071126160538.507EAC2B22@solo.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071126160538.507EAC2B22@solo.franken.de> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17591 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Nov 26, 2007 at 04:58:03PM +0100, Thomas Bogendoerfer wrote: > - fix lockup when switching from early console to real console > - make sysrq reliable > - fix panic, if sysrq is issued before console is opened > > Signed-off-by: Thomas Bogendoerfer Acked-by: Ralf Baechle Several Indy users have reported the issues fixed by this patch so it's 2.6.24 material. Ralf From ralf@linux-mips.org Mon Nov 26 16:57:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 16:57:09 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:12212 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20025766AbXKZQ5H (ORCPT ); Mon, 26 Nov 2007 16:57:07 +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 lAQGuMv4024582; Mon, 26 Nov 2007 16:56:22 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAQGuL0o024581; Mon, 26 Nov 2007 16:56:21 GMT Date: Mon, 26 Nov 2007 16:56:21 +0000 From: Ralf Baechle To: Thomas Bogendoerfer Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] IP22: Fix modules for 64bit kernels by using a CKSEG2 MAP_BASE Message-ID: <20071126165621.GA24575@linux-mips.org> References: <20071123195152.B86B0C2E30@solo.franken.de> <20071125100224.GA17974@alpha.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071125100224.GA17974@alpha.franken.de> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Nov 25, 2007 at 11:03:12AM +0100, Thomas Bogendoerfer wrote: > please drop this bogus patch, it causes vmalloc allocations fails. The bug > it tries to fix isn't even there. Ok. Ralf From ralf@linux-mips.org Mon Nov 26 17:16:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 17:16:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:63396 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039228AbXKZRQT (ORCPT ); Mon, 26 Nov 2007 17:16:19 +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 lAQHFXjQ027018; Mon, 26 Nov 2007 17:15:34 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id lAQHFXLg027017; Mon, 26 Nov 2007 17:15:33 GMT Date: Mon, 26 Nov 2007 17:15:33 +0000 From: Ralf Baechle To: Richard Knutsson Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] [MIPS]: Compliment va_start() with va_end(). Message-ID: <20071126171533.GA26930@linux-mips.org> References: <20071124211046.9931.46998.sendpatchset@thinktank.campus.ltu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071124211046.9931.46998.sendpatchset@thinktank.campus.ltu.se> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Nov 24, 2007 at 10:22:19PM +0100, Richard Knutsson wrote: > Compliment va_start() with va_end(). Thanks, applied. Ralf From earlm@mips.com Mon Nov 26 19:54:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 19:54:53 +0000 (GMT) Received: from mx.mips.com ([63.167.95.198]:65266 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20039613AbXKZTyn convert rfc822-to-8bit (ORCPT ); Mon, 26 Nov 2007 19:54:43 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id lAQJs5HN022411; Mon, 26 Nov 2007 11:54:05 -0800 (PST) Received: from exchange.MIPS.COM (exchange [192.168.20.29]) by mercury.mips.com (8.13.5/8.13.5) with ESMTP id lAQJsZsN027248; Mon, 26 Nov 2007 11:54:36 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Tool chain for linux using mips Date: Mon, 26 Nov 2007 11:54:58 -0800 Message-ID: <3CB54817FDF733459B230DD27C690CEC04FCB3FF@Exchange.mips.com> In-Reply-To: <4749C258.8020400@saville.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tool chain for linux using mips Thread-Index: Acgvk0DVQs4q6TYjQQaAW9CUn5ew3gA0jXAQ From: "Mitchell, Earl" To: "Wink Saville" , Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: earlm@mips.com Precedence: bulk X-list: linux-mips Few months ago I was able to successfully build using crosstools-0.43. I used demo-mipsel.sh to build c,c++ using the following command line ... eval `cat mips.dat gcc-3.4.5-glibc-2.3.6-tls.dat` sh all.sh --notest --gdb -earlm > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Wink Saville > Sent: Sunday, November 25, 2007 10:44 AM > To: linux-mips@linux-mips.org > Subject: Tool chain for linux using mips > > > Hello, > > I was wondering which MIPS tool chains people are > using and recommend, prebuilt and/or roll-your-own. > From http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ > there doesn't seem to be any combination that builds cleanly > for the mips/mipsel. > > Regards, > > Wink Saville > > > From tsbogend@alpha.franken.de Mon Nov 26 22:40:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:40:25 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:48870 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573735AbXKZWkQ (ORCPT ); Mon, 26 Nov 2007 22:40:16 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmch-0006QN-00 for linux-mips@linux-mips.org; Mon, 26 Nov 2007 23:40:15 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 86229C2B24; Mon, 26 Nov 2007 23:38:14 +0100 (CET) Date: Mon, 26 Nov 2007 23:38:14 +0100 To: linux-mips@linux-mips.org Subject: SGI IP28 support Message-ID: <20071126223814.GA21339@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: 17595 X-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 I finally cleaned up Peter Fuerst's IP28 patches and solved some of the IP28 issues in an IMHO more eye-friendly way (no ip26ucmem). My IP28 boots with these patches from an Debian sarge NFS root and is able to dd data from the harddrive. I'm going to send this patches to this list and the subsystem maintainers. There is one change missing to get a working SCSI driver, because a proper fix will be done in 2.6.25. The quick&dirty workaround is below. The workaround makes sure that the sense_buffer lives in its own cache line by aligning and extendin it. The patch "Use real cache invalidate" still contains one problem. It will not flush the cache correctly, if the given size is bigger than the second level cache. The problem is, that there is no index invalidate cache operation available. I have two ideas to solve that. One is to always do a range invalidate (maybe just by using this only for R10k machines, which usually have quite big caches) or scan through the cache and use the tag informations to do hit invalidate. If anybody has a better idea please speak up :-) Have fun with the patches, Thomas. diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h index 3f47e52..3f3d7aa 100644 --- a/include/scsi/scsi_cmnd.h +++ b/include/scsi/scsi_cmnd.h @@ -87,11 +87,13 @@ struct scsi_cmnd { struct request *request; /* The command we are working on */ + unsigned char xxx1[0x48]; #define SCSI_SENSE_BUFFERSIZE 96 unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE]; /* obtained by REQUEST SENSE when * CHECK CONDITION is received on original * command (auto-sense) */ + unsigned char xxx2[32]; /* Low-level done function - can be used by low-level driver to point * to completion function. Not used by mid/upper level code. */ -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From tsbogend@alpha.franken.de Mon Nov 26 22:40:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:40:55 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:49126 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573737AbXKZWkQ (ORCPT ); Mon, 26 Nov 2007 22:40:16 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmch-0006QN-03; Mon, 26 Nov 2007 23:40:15 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 16FBEC2B26; Mon, 26 Nov 2007 23:39:44 +0100 (CET) From: Thomas Bogendoerfer To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Date: Sun, 25 Nov 2007 11:27:06 +0100 Subject: [PATCH] IP22/IP28: fix extracting board/chip rev Message-Id: <20071126223944.16FBEC2B26@solo.franken.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17596 X-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 Taken from Peter Fuersts IP28 patches Signed-off-by: Thomas Bogendoerfer --- include/asm-mips/sgi/ioc.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-mips/sgi/ioc.h b/include/asm-mips/sgi/ioc.h index f3e3dc9..343ed15 100644 --- a/include/asm-mips/sgi/ioc.h +++ b/include/asm-mips/sgi/ioc.h @@ -138,8 +138,8 @@ struct sgioc_regs { u8 _sysid[3]; volatile u8 sysid; #define SGIOC_SYSID_FULLHOUSE 0x01 -#define SGIOC_SYSID_BOARDREV(x) ((x & 0xe0) > 5) -#define SGIOC_SYSID_CHIPREV(x) ((x & 0x1e) > 1) +#define SGIOC_SYSID_BOARDREV(x) (((x) & 0x1e) >> 1) +#define SGIOC_SYSID_CHIPREV(x) (((x) & 0xe0) >> 5) u32 _unused2; u8 _read[3]; volatile u8 read; -- 1.4.4.4 From tsbogend@alpha.franken.de Mon Nov 26 22:41:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:41:26 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:49382 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573739AbXKZWkR (ORCPT ); Mon, 26 Nov 2007 22:40:17 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmch-0006QN-04; Mon, 26 Nov 2007 23:40:15 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id C7CB3C2B26; Mon, 26 Nov 2007 23:39:48 +0100 (CET) From: Thomas Bogendoerfer To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Date: Sun, 25 Nov 2007 11:28:03 +0100 Subject: [PATCH] fix warning when using PHYS_TO_XKSEG_xx() Message-Id: <20071126223948.C7CB3C2B26@solo.franken.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17597 X-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 use CONST64 cast in PHYS_TO_XPHYS macro to avoid warning about shifts longer than the target type. Signed-off-by: Thomas Bogendoerfer --- arch/mips/lib/uncached.c | 8 ++++---- include/asm-mips/addrspace.h | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c index 58d14f4..b59b770 100644 --- a/arch/mips/lib/uncached.c +++ b/arch/mips/lib/uncached.c @@ -46,8 +46,8 @@ unsigned long __init run_uncached(void *func) 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)) + 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((long long)K_CALG_UNCACHED, XKPHYS_TO_PHYS((long long)sp)); #endif @@ -58,8 +58,8 @@ unsigned long __init run_uncached(void *func) if (lfunc >= (long)CKSEG0 && lfunc < (long)CKSEG2) ufunc = CKSEG1ADDR(lfunc); #ifdef CONFIG_64BIT - else if ((long long)lfunc >= (long long)PHYS_TO_XKPHYS(0LL, 0) && - (long long)lfunc < (long long)PHYS_TO_XKPHYS(8LL, 0)) + else if ((long long)lfunc >= (long long)PHYS_TO_XKPHYS(0, 0) && + (long long)lfunc < (long long)PHYS_TO_XKPHYS(8, 0)) ufunc = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED, XKPHYS_TO_PHYS((long long)lfunc)); #endif diff --git a/include/asm-mips/addrspace.h b/include/asm-mips/addrspace.h index 0bb7a93..9002d66 100644 --- a/include/asm-mips/addrspace.h +++ b/include/asm-mips/addrspace.h @@ -127,7 +127,7 @@ #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)) /* * The ultimate limited of the 64-bit MIPS architecture: 2 bits for selecting -- 1.4.4.4 From tsbogend@alpha.franken.de Mon Nov 26 22:41:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:41:57 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:50150 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573740AbXKZWkS (ORCPT ); Mon, 26 Nov 2007 22:40:18 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmch-0006QN-01; Mon, 26 Nov 2007 23:40:15 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id A566CC2B26; Mon, 26 Nov 2007 23:39:21 +0100 (CET) From: Thomas Bogendoerfer To: linux-scsi@vger.kernel.org, linux-mips@linux-mips.org cc: ralf@linux-mips.org, James.Bottomley@HansenPartnership.com Date: Mon, 26 Nov 2007 18:41:15 +0100 Subject: [PATCH] SGIWD93: use cached memory access to make driver work on IP28 Message-Id: <20071126223921.A566CC2B26@solo.franken.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17598 X-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 Following patch is 2.6.25 material needed to get SGI IP28 machines supported. Thomas. SGI IP28 machines would need special treatment (enable adding addtional wait states) when accessing memory uncached. To avoid this pain I changed the driver to use only cached access to memory. Signed-off-by: Thomas Bogendoerfer --- drivers/scsi/sgiwd93.c | 68 ++++++++++++++++++++++++++++++----------------- 1 files changed, 43 insertions(+), 25 deletions(-) diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c index eef8275..d4e6468 100644 --- a/drivers/scsi/sgiwd93.c +++ b/drivers/scsi/sgiwd93.c @@ -33,19 +33,27 @@ struct ip22_hostdata { struct WD33C93_hostdata wh; - struct hpc_data { - dma_addr_t dma; - void *cpu; - } hd; + dma_addr_t dma; + void *cpu; + void *dev; }; #define host_to_hostdata(host) ((struct ip22_hostdata *)((host)->hostdata)) struct hpc_chunk { struct hpc_dma_desc desc; - u32 _padding; /* align to quadword boundary */ + u32 _padding[128/4 - 3]; /* align to biggest cache line size */ }; +/* space for hpc dma descriptors */ +#define HPC_DMA_SIZE (4 * PAGE_SIZE) + +/* we only need to sync the dma descriptor */ +#define DMA_HPC_SYNC(dev, hcp, dir) \ + dma_cache_sync(dev, hcp, sizeof(struct hpc_dma_desc), dir) + +#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE) + static irqreturn_t sgiwd93_intr(int irq, void *dev_id) { struct Scsi_Host * host = dev_id; @@ -59,14 +67,14 @@ static irqreturn_t sgiwd93_intr(int irq, void *dev_id) } static inline -void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp) +void fill_hpc_entries(void *dev, struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp) { unsigned long len = cmd->SCp.this_residual; void *addr = cmd->SCp.ptr; dma_addr_t physaddr; unsigned long count; - physaddr = dma_map_single(NULL, addr, len, cmd->sc_data_direction); + physaddr = dma_map_single(dev, addr, len, DMA_DIR(datainp)); cmd->SCp.dma_handle = physaddr; while (len) { @@ -77,6 +85,7 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp) count = len > 8192 ? 8192 : len; hcp->desc.pbuf = physaddr; hcp->desc.cntinfo = count; + DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE); hcp++; len -= count; physaddr += count; @@ -89,6 +98,7 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp) */ hcp->desc.pbuf = 0; hcp->desc.cntinfo = HPCDMA_EOX; + DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE); } static int dma_setup(struct scsi_cmnd *cmd, int datainp) @@ -96,7 +106,7 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp) struct ip22_hostdata *hdata = host_to_hostdata(cmd->device->host); struct hpc3_scsiregs *hregs = (struct hpc3_scsiregs *) cmd->device->host->base; - struct hpc_chunk *hcp = (struct hpc_chunk *) hdata->hd.cpu; + struct hpc_chunk *hcp = (struct hpc_chunk *)hdata->cpu; pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hcp); @@ -111,12 +121,12 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp) if (cmd->SCp.ptr == NULL || cmd->SCp.this_residual == 0) return 1; - fill_hpc_entries(hcp, cmd, datainp); + fill_hpc_entries(hdata->dev, hcp, cmd, datainp); pr_debug(" HPCGO\n"); /* Start up the HPC. */ - hregs->ndptr = hdata->hd.dma; + hregs->ndptr = hdata->dma; if (datainp) hregs->ctrl = HPC3_SCTRL_ACTIVE; else @@ -134,6 +144,9 @@ static void dma_stop(struct Scsi_Host *instance, struct scsi_cmnd *SCpnt, if (!SCpnt) return; + if (SCpnt->SCp.ptr == NULL || SCpnt->SCp.this_residual == 0) + return; + hregs = (struct hpc3_scsiregs *) SCpnt->device->host->base; pr_debug("dma_stop: status<%d> ", status); @@ -145,8 +158,9 @@ static void dma_stop(struct Scsi_Host *instance, struct scsi_cmnd *SCpnt, barrier(); } hregs->ctrl = 0; - dma_unmap_single(NULL, SCpnt->SCp.dma_handle, SCpnt->SCp.this_residual, - SCpnt->sc_data_direction); + dma_unmap_single(hdata->dev, SCpnt->SCp.dma_handle, + SCpnt->SCp.this_residual, + DMA_DIR(hdata->wh.dma_dir)); pr_debug("\n"); } @@ -160,22 +174,25 @@ void sgiwd93_reset(unsigned long base) hregs->ctrl = 0; } -static inline void init_hpc_chain(struct hpc_data *hd) +static inline void init_hpc_chain(void *dev, struct ip22_hostdata *hdata) { - struct hpc_chunk *hcp = (struct hpc_chunk *) hd->cpu; - struct hpc_chunk *dma = (struct hpc_chunk *) hd->dma; + struct hpc_chunk *hcp = (struct hpc_chunk *)hdata->cpu; + dma_addr_t dma = hdata->dma; unsigned long start, end; start = (unsigned long) hcp; - end = start + PAGE_SIZE; + end = start + (4 * PAGE_SIZE); while (start < end) { - hcp->desc.pnext = (u32) (dma + 1); + hcp->desc.pnext = (u32) (dma + sizeof(struct hpc_chunk)); hcp->desc.cntinfo = HPCDMA_EOX; - hcp++; dma++; + DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE); + hcp++; + dma += sizeof(struct hpc_chunk); start += sizeof(struct hpc_chunk); }; hcp--; - hcp->desc.pnext = hd->dma; + hcp->desc.pnext = hdata->dma; + DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE); } static int sgiwd93_bus_reset(struct scsi_cmnd *cmd) @@ -234,16 +251,17 @@ static int __init sgiwd93_probe(struct platform_device *pdev) host->irq = irq; hdata = host_to_hostdata(host); - hdata->hd.cpu = dma_alloc_coherent(&pdev->dev, PAGE_SIZE, - &hdata->hd.dma, GFP_KERNEL); - if (!hdata->hd.cpu) { + hdata->dev = &pdev->dev; + hdata->cpu = dma_alloc_noncoherent(&pdev->dev, HPC_DMA_SIZE, + &hdata->dma, GFP_KERNEL); + if (!hdata->cpu) { printk(KERN_WARNING "sgiwd93: Could not allocate memory for " "host %d buffer.\n", unit); err = -ENOMEM; goto out_put; } - init_hpc_chain(&hdata->hd); + init_hpc_chain(&pdev->dev, hdata); regs.SASR = wdregs + 3; regs.SCMD = wdregs + 7; @@ -273,7 +291,7 @@ static int __init sgiwd93_probe(struct platform_device *pdev) out_irq: free_irq(irq, host); out_free: - dma_free_coherent(NULL, PAGE_SIZE, hdata->hd.cpu, hdata->hd.dma); + dma_free_noncoherent(NULL, HPC_DMA_SIZE, hdata->cpu, hdata->dma); out_put: scsi_host_put(host); out: @@ -289,7 +307,7 @@ static void __exit sgiwd93_remove(struct platform_device *pdev) scsi_remove_host(host); free_irq(pd->irq, host); - dma_free_coherent(&pdev->dev, PAGE_SIZE, hdata->hd.cpu, hdata->hd.dma); + dma_free_noncoherent(&pdev->dev, HPC_DMA_SIZE, hdata->cpu, hdata->dma); scsi_host_put(host); } -- 1.4.4.4 From tsbogend@alpha.franken.de Mon Nov 26 22:42:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:42:21 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:49638 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573742AbXKZWkS (ORCPT ); Mon, 26 Nov 2007 22:40:18 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmch-0006QN-05; Mon, 26 Nov 2007 23:40:15 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 9BAAAC2B26; Mon, 26 Nov 2007 23:39:55 +0100 (CET) From: Thomas Bogendoerfer To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Date: Sun, 25 Nov 2007 11:47:56 +0100 Subject: [PATCH] IP28: added cache barrier to assembly routines Message-Id: <20071126223955.9BAAAC2B26@solo.franken.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17599 X-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 IP28 needs special treatment to avoid speculative accesses. gcc takes care for .c code, but for assembly code we need to do it manually. This is taken from Peter Fuersts IP28 patches. Signed-off-by: Thomas Bogendoerfer --- arch/mips/lib/memcpy.S | 10 ++++++++++ arch/mips/lib/memset.S | 5 +++++ arch/mips/lib/strncpy_user.S | 1 + include/asm-mips/asm.h | 8 ++++++++ 4 files changed, 24 insertions(+), 0 deletions(-) diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S index a526c62..054399d 100644 --- a/arch/mips/lib/memcpy.S +++ b/arch/mips/lib/memcpy.S @@ -194,6 +194,7 @@ FEXPORT(__copy_user) */ #define rem t8 + R10KCBARRIER(0(ra)) /* * The "issue break"s below are very approximate. * Issue delays for dcache fills will perturb the schedule, as will @@ -226,6 +227,7 @@ both_aligned: PREF( 1, 3*32(dst) ) .align 4 1: + R10KCBARRIER(0(ra)) EXC( LOAD t0, UNIT(0)(src), l_exc) EXC( LOAD t1, UNIT(1)(src), l_exc_copy) EXC( LOAD t2, UNIT(2)(src), l_exc_copy) @@ -267,6 +269,7 @@ EXC( LOAD t2, UNIT(2)(src), l_exc_copy) EXC( LOAD t3, UNIT(3)(src), l_exc_copy) SUB len, len, 4*NBYTES ADD src, src, 4*NBYTES + R10KCBARRIER(0(ra)) EXC( STORE t0, UNIT(0)(dst), s_exc_p4u) EXC( STORE t1, UNIT(1)(dst), s_exc_p3u) EXC( STORE t2, UNIT(2)(dst), s_exc_p2u) @@ -280,6 +283,7 @@ less_than_4units: beq rem, len, copy_bytes nop 1: + R10KCBARRIER(0(ra)) EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES SUB len, len, NBYTES @@ -325,6 +329,7 @@ EXC( LDFIRST t3, FIRST(0)(src), l_exc) EXC( LDREST t3, REST(0)(src), l_exc_copy) SUB t2, t2, t1 # t2 = number of bytes copied xor match, t0, t1 + R10KCBARRIER(0(ra)) EXC( STFIRST t3, FIRST(0)(dst), s_exc) beq len, t2, done SUB len, len, t2 @@ -345,6 +350,7 @@ src_unaligned_dst_aligned: * It's OK to load FIRST(N+1) before REST(N) because the two addresses * are to the same unit (unless src is aligned, but it's not). */ + R10KCBARRIER(0(ra)) EXC( LDFIRST t0, FIRST(0)(src), l_exc) EXC( LDFIRST t1, FIRST(1)(src), l_exc_copy) SUB len, len, 4*NBYTES @@ -373,6 +379,7 @@ cleanup_src_unaligned: beq rem, len, copy_bytes nop 1: + R10KCBARRIER(0(ra)) EXC( LDFIRST t0, FIRST(0)(src), l_exc) EXC( LDREST t0, REST(0)(src), l_exc_copy) ADD src, src, NBYTES @@ -386,6 +393,7 @@ copy_bytes_checklen: nop copy_bytes: /* 0 < len < NBYTES */ + R10KCBARRIER(0(ra)) #define COPY_BYTE(N) \ EXC( lb t0, N(src), l_exc); \ SUB len, len, 1; \ @@ -498,6 +506,7 @@ LEAF(__rmemcpy) /* a0=dst a1=src a2=len */ ADD a1, a2 # src = src + len r_end_bytes: + R10KCBARRIER(0(ra)) lb t0, -1(a1) SUB a2, a2, 0x1 sb t0, -1(a0) @@ -510,6 +519,7 @@ r_out: move a2, zero r_end_bytes_up: + R10KCBARRIER(0(ra)) lb t0, (a1) SUB a2, a2, 0x1 sb t0, (a0) diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S index 3f8b8b3..aad0639 100644 --- a/arch/mips/lib/memset.S +++ b/arch/mips/lib/memset.S @@ -77,6 +77,7 @@ FEXPORT(__bzero) beqz t0, 1f PTR_SUBU t0, LONGSIZE /* alignment in bytes */ + R10KCBARRIER(0(ra)) #ifdef __MIPSEB__ EX(LONG_S_L, a1, (a0), first_fixup) /* make word/dword aligned */ #endif @@ -94,11 +95,13 @@ FEXPORT(__bzero) PTR_ADDU t1, a0 /* end address */ .set reorder 1: PTR_ADDIU a0, 64 + R10KCBARRIER(0(ra)) f_fill64 a0, -64, a1, fwd_fixup bne t1, a0, 1b .set noreorder memset_partial: + R10KCBARRIER(0(ra)) PTR_LA t1, 2f /* where to start */ #if LONGSIZE == 4 PTR_SUBU t1, t0 @@ -120,6 +123,7 @@ memset_partial: beqz a2, 1f PTR_ADDU a0, a2 /* What's left */ + R10KCBARRIER(0(ra)) #ifdef __MIPSEB__ EX(LONG_S_R, a1, -1(a0), last_fixup) #endif @@ -134,6 +138,7 @@ small_memset: PTR_ADDU t1, a0, a2 1: PTR_ADDIU a0, 1 /* fill bytewise */ + R10KCBARRIER(0(ra)) bne t1, a0, 1b sb a1, -1(a0) diff --git a/arch/mips/lib/strncpy_user.S b/arch/mips/lib/strncpy_user.S index d16c76f..8fd21d5 100644 --- a/arch/mips/lib/strncpy_user.S +++ b/arch/mips/lib/strncpy_user.S @@ -38,6 +38,7 @@ FEXPORT(__strncpy_from_user_nocheck_asm) .set noreorder 1: EX(lbu, t0, (v1), fault) PTR_ADDIU v1, 1 + R10KCBARRIER(0(ra)) beqz t0, 2f sb t0, (a0) PTR_ADDIU v0, 1 diff --git a/include/asm-mips/asm.h b/include/asm-mips/asm.h index 12e1758..608cfcf 100644 --- a/include/asm-mips/asm.h +++ b/include/asm-mips/asm.h @@ -398,4 +398,12 @@ symbol = value #define SSNOP sll zero, zero, 1 +#ifdef CONFIG_SGI_IP28 +/* Inhibit speculative stores to volatile (e.g.DMA) or invalid addresses. */ +#include +#define R10KCBARRIER(addr) cache Cache_Barrier, addr; +#else +#define R10KCBARRIER(addr) +#endif + #endif /* __ASM_ASM_H */ -- 1.4.4.4 From tsbogend@alpha.franken.de Mon Nov 26 22:42:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:42:51 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:50662 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573743AbXKZWkS (ORCPT ); Mon, 26 Nov 2007 22:40:18 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmch-0006QN-06; Mon, 26 Nov 2007 23:40:15 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 48CF6C2B26; Mon, 26 Nov 2007 23:40:01 +0100 (CET) From: Thomas Bogendoerfer Subject: [PATCH] Use real cache invalidate To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Message-Id: <20071126224001.48CF6C2B26@solo.franken.de> Date: Mon, 26 Nov 2007 23:40:01 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17600 X-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 R10k non coherent machines need a real dma cache invalidate to get rid of speculative stores in cache. Signed-off-by: Thomas Bogendoerfer --- diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index 9355f1c..82d0d3e 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -598,7 +598,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size) if (size >= scache_size) r4k_blast_scache(); else - blast_scache_range(addr, addr + size); + blast_inv_scache_range(addr, addr + size); return; } @@ -606,7 +606,7 @@ static void r4k_dma_cache_inv(unsigned long addr, unsigned long size) r4k_blast_dcache(); } else { R4600_HIT_CACHEOP_WAR_IMPL; - blast_dcache_range(addr, addr + size); + blast_inv_dcache_range(addr, addr + size); } bc_inv(addr, size); diff --git a/include/asm-mips/r4kcache.h b/include/asm-mips/r4kcache.h index 2b8466f..4c140db 100644 --- a/include/asm-mips/r4kcache.h +++ b/include/asm-mips/r4kcache.h @@ -403,6 +403,13 @@ __BUILD_BLAST_CACHE(i, icache, Index_Invalidate_I, Hit_Invalidate_I, 64) __BUILD_BLAST_CACHE(s, scache, Index_Writeback_Inv_SD, Hit_Writeback_Inv_SD, 64) __BUILD_BLAST_CACHE(s, scache, Index_Writeback_Inv_SD, Hit_Writeback_Inv_SD, 128) +__BUILD_BLAST_CACHE(inv_d, dcache, Index_Writeback_Inv_D, Hit_Invalidate_D, 16) +__BUILD_BLAST_CACHE(inv_d, dcache, Index_Writeback_Inv_D, Hit_Invalidate_D, 32) +__BUILD_BLAST_CACHE(inv_s, scache, Index_Writeback_Inv_SD, Hit_Invalidate_SD, 16) +__BUILD_BLAST_CACHE(inv_s, scache, Index_Writeback_Inv_SD, Hit_Invalidate_SD, 32) +__BUILD_BLAST_CACHE(inv_s, scache, Index_Writeback_Inv_SD, Hit_Invalidate_SD, 64) +__BUILD_BLAST_CACHE(inv_s, scache, Index_Writeback_Inv_SD, Hit_Invalidate_SD, 128) + /* build blast_xxx_range, protected_blast_xxx_range */ #define __BUILD_BLAST_CACHE_RANGE(pfx, desc, hitop, prot) \ static inline void prot##blast_##pfx##cache##_range(unsigned long start, \ From tsbogend@alpha.franken.de Mon Nov 26 22:43:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Nov 2007 22:43:21 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:50918 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S28573744AbXKZWkT (ORCPT ); Mon, 26 Nov 2007 22:40:19 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1Iwmci-0006QN-00; Mon, 26 Nov 2007 23:40:16 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id D885AC2B26; Mon, 26 Nov 2007 23:40:04 +0100 (CET) From: Thomas Bogendoerfer Subject: [PATCH] IP28 support To: linux-mips@linux-mips.org cc: ralf@linux-mips.org Message-Id: <20071126224004.D885AC2B26@solo.franken.de> Date: Mon, 26 Nov 2007 23:40:04 +0100 (CET) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 17601 X-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 Add support for SGI IP28 machines (Indigo 2 with R10k CPUs) This work is mainly based on Peter Fuersts work. Signed-off-by: Thomas Bogendoerfer --- diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2f2ce0c..21649e4 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -421,6 +421,27 @@ config SGI_IP27 workstations. To compile a Linux kernel that runs on these, say Y here. +config SGI_IP28 + bool "SGI IP28 (Indigo2 R10k) (EXPERIMENTAL)" + depends on EXPERIMENTAL + select ARC + select ARC64 + select CEVT_R4K + select DMA_NONCOHERENT + select IRQ_CPU + select SWAP_IO_SPACE + select HW_HAS_EISA + select I8253 + select I8259 + select SYS_HAS_CPU_R10000 + select SYS_HAS_EARLY_PRINTK + select BOOT_ELF64 + select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + help + This is the SGI Indigo2 with R10000 processor. To compile a Linux + kernel that runs on these, say Y here. + config SGI_IP32 bool "SGI IP32 (O2)" select ARC @@ -932,7 +953,7 @@ config BOOT_ELF32 config MIPS_L1_CACHE_SHIFT int default "4" if MACH_DECSTATION - default "7" if SGI_IP27 || SNI_RM + default "7" if SGI_IP27 || SGI_IP28 || SNI_RM default "4" if PMC_MSP4200_EVAL default "5" @@ -941,7 +962,7 @@ config HAVE_STD_PC_SERIAL_PORT config ARC_CONSOLE bool "ARC console support" - depends on SGI_IP22 || (SNI_RM && CPU_LITTLE_ENDIAN) + depends on SGI_IP22 || SGI_IP28 || (SNI_RM && CPU_LITTLE_ENDIAN) config ARC_MEMORY bool @@ -950,7 +971,7 @@ config ARC_MEMORY config ARC_PROMLIB bool - depends on MACH_JAZZ || SNI_RM || SGI_IP22 || SGI_IP32 + depends on MACH_JAZZ || SNI_RM || SGI_IP22 || SGI_IP28 || SGI_IP32 default y config ARC64 diff --git a/arch/mips/Makefile b/arch/mips/Makefile index a1f8d8b..d91fbca 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -475,6 +475,20 @@ endif endif # +# SGI IP28 (Indigo2 R10k) +# +# Set the load address to >= 0xa800000020080000 if you want to leave space for +# symmon, 0xa800000020004000 for production kernels ? Note that the value must +# be 16kb aligned or the handling of the current variable will break. +# Simplified: what IP22 does at 128MB+ in ksegN, IP28 does at 512MB+ in xkphys +# +#core-$(CONFIG_SGI_IP28) += arch/mips/sgi-ip22/ arch/mips/arc/arc_con.o +core-$(CONFIG_SGI_IP28) += arch/mips/sgi-ip22/ +cflags-$(CONFIG_SGI_IP28) += -mr10k-cache-barrier=1 -Iinclude/asm-mips/mach-ip28 +#cflags-$(CONFIG_SGI_IP28) += -Iinclude/asm-mips/mach-ip28 +load-$(CONFIG_SGI_IP28) += 0xa800000020004000 + +# # SGI-IP32 (O2) # # Set the load address to >= 80069000 if you want to leave space for symmon, diff --git a/arch/mips/sgi-ip22/Makefile b/arch/mips/sgi-ip22/Makefile index e3acb51..ef1564e 100644 --- a/arch/mips/sgi-ip22/Makefile +++ b/arch/mips/sgi-ip22/Makefile @@ -3,9 +3,11 @@ # under Linux. # -obj-y += ip22-mc.o ip22-hpc.o ip22-int.o ip22-berr.o \ - ip22-time.o ip22-nvram.o ip22-platform.o ip22-reset.o ip22-setup.o +obj-y += ip22-mc.o ip22-hpc.o ip22-int.o ip22-time.o ip22-nvram.o \ + ip22-platform.o ip22-reset.o ip22-setup.o +obj-$(CONFIG_SGI_IP22) += ip22-berr.o +obj-$(CONFIG_SGI_IP28) += ip28-berr.o obj-$(CONFIG_EISA) += ip22-eisa.o -EXTRA_CFLAGS += -Werror +# EXTRA_CFLAGS += -Werror diff --git a/arch/mips/sgi-ip22/ip22-mc.c b/arch/mips/sgi-ip22/ip22-mc.c index 01a805d..3f35d63 100644 --- a/arch/mips/sgi-ip22/ip22-mc.c +++ b/arch/mips/sgi-ip22/ip22-mc.c @@ -4,6 +4,7 @@ * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * Copyright (C) 1999 Andrew R. Baker (andrewb@uab.edu) - Indigo2 changes * Copyright (C) 2003 Ladislav Michl (ladis@linux-mips.org) + * Copyright (C) 2004 Peter Fuerst (pf@net.alphadv.de) - IP28 */ #include @@ -137,9 +138,12 @@ void __init sgimc_init(void) /* Step 2: Enable all parity checking in cpu control register * zero. */ + /* don't touch parity settings for IP28 */ +#ifndef CONFIG_SGI_IP28 tmp = sgimc->cpuctrl0; tmp |= (SGIMC_CCTRL0_EPERRGIO | SGIMC_CCTRL0_EPERRMEM | SGIMC_CCTRL0_R4KNOCHKPARR); +#endif sgimc->cpuctrl0 = tmp; /* Step 3: Setup the MC write buffer depth, this is controlled diff --git a/arch/mips/sgi-ip22/ip28-berr.c b/arch/mips/sgi-ip22/ip28-berr.c new file mode 100644 index 0000000..e61e8f3 --- /dev/null +++ b/arch/mips/sgi-ip22/ip28-berr.c @@ -0,0 +1,704 @@ +/* + * ip28-berr.c: Bus error handling. + * + * Copyright (C) 2002, 2003 Ladislav Michl (ladis@linux-mips.org) + * Copyright (C) 2005 Peter Fuerst (pf@net.alphadv.de) - IP28 + */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static unsigned int count_be_is_fixup; +static unsigned int count_be_handler; +static unsigned int count_be_interrupt; +static int debug_be_interrupt; + +static unsigned int cpu_err_stat; /* Status reg for CPU */ +static unsigned int gio_err_stat; /* Status reg for GIO */ +static unsigned int cpu_err_addr; /* Error address reg for CPU */ +static unsigned int gio_err_addr; /* Error address reg for GIO */ +static unsigned int extio_stat; +static unsigned int hpc3_berr_stat; /* Bus error interrupt status */ + +struct hpc3_stat { + unsigned long addr; + unsigned int ctrl; + unsigned int cbp; + unsigned int ndptr; +}; + +static struct { + struct hpc3_stat pbdma[8]; + struct hpc3_stat scsi[2]; + struct hpc3_stat ethrx, ethtx; +} hpc3; + +static struct { + unsigned long err_addr; + struct { + u32 lo; + u32 hi; + } tags[1][2], tagd[4][2], tagi[4][2]; /* Way 0/1 */ +} cache_tags; + +static inline void save_cache_tags(unsigned busaddr) +{ + unsigned long addr = CAC_BASE | busaddr; + int i; + cache_tags.err_addr = addr; + + /* + * Starting with a bus-address, save secondary cache (indexed by + * PA[23..18:7..6]) tags first. + */ + addr &= ~1L; +#define tag cache_tags.tags[0] + cache_op(Index_Load_Tag_S, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:18], VA[13:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_S, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:18], VA[13:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ +#undef tag + + /* + * Save all primary data cache (indexed by VA[13:5]) tags which + * might fit to this bus-address, knowing that VA[11:0] == PA[11:0]. + * Saving all tags and evaluating them later is easier and safer + * than relying on VA[13:12] from the secondary cache tags to pick + * matching primary tags here already. + */ + addr &= (0xffL << 56) | ((1 << 12) - 1); +#define tag cache_tags.tagd[i] + for (i = 0; i < 4; ++i, addr += (1 << 12)) { + cache_op(Index_Load_Tag_D, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_D, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + } +#undef tag + + /* + * Save primary instruction cache (indexed by VA[13:6]) tags + * the same way. + */ + addr &= (0xffL << 56) | ((1 << 12) - 1); +#define tag cache_tags.tagi[i] + for (i = 0; i < 4; ++i, addr += (1 << 12)) { + cache_op(Index_Load_Tag_I, addr); + tag[0].lo = read_c0_taglo(); /* PA[35:12] */ + tag[0].hi = read_c0_taghi(); /* PA[39:36] */ + cache_op(Index_Load_Tag_I, addr | 1L); + tag[1].lo = read_c0_taglo(); /* PA[35:12] */ + tag[1].hi = read_c0_taghi(); /* PA[39:36] */ + } +#undef tag +} + +#define GIO_ERRMASK 0xff00 +#define CPU_ERRMASK 0x3f00 + +static void save_and_clear_buserr(void) +{ + int i; + + /* save status registers */ + cpu_err_addr = sgimc->cerr; + cpu_err_stat = sgimc->cstat; + gio_err_addr = sgimc->gerr; + gio_err_stat = sgimc->gstat; + extio_stat = sgioc->extio; + hpc3_berr_stat = hpc3c0->bestat; + + hpc3.scsi[0].addr = (unsigned long)&hpc3c0->scsi_chan0; + hpc3.scsi[0].ctrl = hpc3c0->scsi_chan0.ctrl; /* HPC3_SCTRL_ACTIVE ? */ + hpc3.scsi[0].cbp = hpc3c0->scsi_chan0.cbptr; + hpc3.scsi[0].ndptr = hpc3c0->scsi_chan0.ndptr; + + hpc3.scsi[1].addr = (unsigned long)&hpc3c0->scsi_chan1; + hpc3.scsi[1].ctrl = hpc3c0->scsi_chan1.ctrl; /* HPC3_SCTRL_ACTIVE ? */ + hpc3.scsi[1].cbp = hpc3c0->scsi_chan1.cbptr; + hpc3.scsi[1].ndptr = hpc3c0->scsi_chan1.ndptr; + + hpc3.ethrx.addr = (unsigned long)&hpc3c0->ethregs.rx_cbptr; + hpc3.ethrx.ctrl = hpc3c0->ethregs.rx_ctrl; /* HPC3_ERXCTRL_ACTIVE ? */ + hpc3.ethrx.cbp = hpc3c0->ethregs.rx_cbptr; + hpc3.ethrx.ndptr = hpc3c0->ethregs.rx_ndptr; + + hpc3.ethtx.addr = (unsigned long)&hpc3c0->ethregs.tx_cbptr; + hpc3.ethtx.ctrl = hpc3c0->ethregs.tx_ctrl; /* HPC3_ETXCTRL_ACTIVE ? */ + hpc3.ethtx.cbp = hpc3c0->ethregs.tx_cbptr; + hpc3.ethtx.ndptr = hpc3c0->ethregs.tx_ndptr; + + for (i = 0; i < 8; ++i) { + /* HPC3_PDMACTRL_ISACT ? */ + hpc3.pbdma[i].addr = (unsigned long)&hpc3c0->pbdma[i]; + hpc3.pbdma[i].ctrl = hpc3c0->pbdma[i].pbdma_ctrl; + hpc3.pbdma[i].cbp = hpc3c0->pbdma[i].pbdma_bptr; + hpc3.pbdma[i].ndptr = hpc3c0->pbdma[i].pbdma_dptr; + } + i = 0; + if (gio_err_stat & CPU_ERRMASK) + i = gio_err_addr; + if (cpu_err_stat & CPU_ERRMASK) + i = cpu_err_addr; + save_cache_tags(i); + + sgimc->cstat = sgimc->gstat = 0; +} + +static void print_cache_tags(void) +{ + u32 scb, scw; + int i; + + printk(KERN_ERR "Cache tags @ %08x:\n", (unsigned)cache_tags.err_addr); + + /* PA[31:12] shifted to PTag0 (PA[35:12]) format */ + scw = (cache_tags.err_addr >> 4) & 0x0fffff00; + + scb = cache_tags.err_addr & ((1 << 12) - 1) & ~((1 << 5) - 1); + for (i = 0; i < 4; ++i) { /* for each possible VA[13:12] value */ + if ((cache_tags.tagd[i][0].lo & 0x0fffff00) != scw && + (cache_tags.tagd[i][1].lo & 0x0fffff00) != scw) + continue; + printk(KERN_ERR + "D: 0: %08x %08x, 1: %08x %08x (VA[13:5] %04x)\n", + cache_tags.tagd[i][0].hi, cache_tags.tagd[i][0].lo, + cache_tags.tagd[i][1].hi, cache_tags.tagd[i][1].lo, + scb | (1 << 12)*i); + } + scb = cache_tags.err_addr & ((1 << 12) - 1) & ~((1 << 6) - 1); + for (i = 0; i < 4; ++i) { /* for each possible VA[13:12] value */ + if ((cache_tags.tagi[i][0].lo & 0x0fffff00) != scw && + (cache_tags.tagi[i][1].lo & 0x0fffff00) != scw) + continue; + printk(KERN_ERR + "I: 0: %08x %08x, 1: %08x %08x (VA[13:6] %04x)\n", + cache_tags.tagi[i][0].hi, cache_tags.tagi[i][0].lo, + cache_tags.tagi[i][1].hi, cache_tags.tagi[i][1].lo, + scb | (1 << 12)*i); + } + i = read_c0_config(); + scb = i & (1 << 13) ? 7:6; /* scblksize = 2^[7..6] */ + scw = ((i >> 16) & 7) + 19 - 1; /* scwaysize = 2^[24..19] / 2 */ + + i = ((1 << scw) - 1) & ~((1 << scb) - 1); + printk(KERN_ERR "S: 0: %08x %08x, 1: %08x %08x (PA[%u:%u] %05x)\n", + cache_tags.tags[0][0].hi, cache_tags.tags[0][0].lo, + cache_tags.tags[0][1].hi, cache_tags.tags[0][1].lo, + scw-1, scb, i & (unsigned)cache_tags.err_addr); +} + +static inline const char *cause_excode_text(int cause) +{ + static const char *txt[32] = + { "Interrupt", + "TLB modification", + "TLB (load or instruction fetch)", + "TLB (store)", + "Address error (load or instruction fetch)", + "Address error (store)", + "Bus error (instruction fetch)", + "Bus error (data: load or store)", + "Syscall", + "Breakpoint", + "Reserved instruction", + "Coprocessor unusable", + "Arithmetic Overflow", + "Trap", + "14", + "Floating-Point", + "16", "17", "18", "19", "20", "21", "22", + "Watch Hi/Lo", + "24", "25", "26", "27", "28", "29", "30", "31", + }; + return txt[(cause & 0x7c) >> 2]; +} + +static void print_buserr(const struct pt_regs *regs) +{ + const int field = 2 * sizeof(unsigned long); + int error = 0; + + if (extio_stat & EXTIO_MC_BUSERR) { + printk(KERN_ERR "MC Bus Error\n"); + error |= 1; + } + if (extio_stat & EXTIO_HPC3_BUSERR) { + printk(KERN_ERR "HPC3 Bus Error 0x%x:\n", + hpc3_berr_stat, + (hpc3_berr_stat & HPC3_BESTAT_PIDMASK) >> + HPC3_BESTAT_PIDSHIFT, + (hpc3_berr_stat & HPC3_BESTAT_CTYPE) ? "PIO" : "DMA", + hpc3_berr_stat & HPC3_BESTAT_BLMASK); + error |= 2; + } + if (extio_stat & EXTIO_EISA_BUSERR) { + printk(KERN_ERR "EISA Bus Error\n"); + error |= 4; + } + if (cpu_err_stat & CPU_ERRMASK) { + printk(KERN_ERR "CPU error 0x%x<%s%s%s%s%s%s> @ 0x%08x\n", + cpu_err_stat, + cpu_err_stat & SGIMC_CSTAT_RD ? "RD " : "", + cpu_err_stat & SGIMC_CSTAT_PAR ? "PAR " : "", + cpu_err_stat & SGIMC_CSTAT_ADDR ? "ADDR " : "", + cpu_err_stat & SGIMC_CSTAT_SYSAD_PAR ? "SYSAD " : "", + cpu_err_stat & SGIMC_CSTAT_SYSCMD_PAR ? "SYSCMD " : "", + cpu_err_stat & SGIMC_CSTAT_BAD_DATA ? "BAD_DATA " : "", + cpu_err_addr); + error |= 8; + } + if (gio_err_stat & GIO_ERRMASK) { + printk(KERN_ERR "GIO error 0x%x:<%s%s%s%s%s%s%s%s> @ 0x%08x\n", + gio_err_stat, + gio_err_stat & SGIMC_GSTAT_RD ? "RD " : "", + gio_err_stat & SGIMC_GSTAT_WR ? "WR " : "", + gio_err_stat & SGIMC_GSTAT_TIME ? "TIME " : "", + gio_err_stat & SGIMC_GSTAT_PROM ? "PROM " : "", + gio_err_stat & SGIMC_GSTAT_ADDR ? "ADDR " : "", + gio_err_stat & SGIMC_GSTAT_BC ? "BC " : "", + gio_err_stat & SGIMC_GSTAT_PIO_RD ? "PIO_RD " : "", + gio_err_stat & SGIMC_GSTAT_PIO_WR ? "PIO_WR " : "", + gio_err_addr); + error |= 16; + } + if (!error) + printk(KERN_ERR "MC: Hmm, didn't find any error condition.\n"); + else { + printk(KERN_ERR "CP0: config %08x, " + "MC: cpuctrl0/1: %08x/%05x, giopar: %04x\n" + "MC: cpu/gio_memacc: %08x/%05x, memcfg0/1: %08x/%08x\n", + read_c0_config(), + sgimc->cpuctrl0, sgimc->cpuctrl0, sgimc->giopar, + sgimc->cmacc, sgimc->gmacc, + sgimc->mconfig0, sgimc->mconfig1); + print_cache_tags(); + } + printk(KERN_ALERT "%s, epc == %0*lx, ra == %0*lx\n", + cause_excode_text(regs->cp0_cause), + field, regs->cp0_epc, field, regs->regs[31]); +} + +/* + * Try to find out, whether the bus error is caused by the instruction + * at EPC, otherwise we have an asynchronous error. + * + * Doc1: "MIPS IV Instruction Set", Rev 3.2 (SGI 007-2597-001) + * Doc2: "MIPS R10000 Microporcessor User's Manual", Ver 2.0 (SGI 007-2490-001) + * Doc3: "MIPS R4000 Microporcessor User's Manual", 2nd Ed. (SGI 007-2489-001) + */ + +#define JMP_INDEX26_OP 1 +#define JMP_REGISTER_OP 2 +#define JMP_PCREL16_OP 3 +#define BASE_OFFSET_OP 4 +#define BASE_IDXREG_OP 5 + +/* Match virtual address in an insn with physical error address */ + +static int match_addr(unsigned paddr, unsigned long vaddr) +{ + unsigned long uaddr; + + if ((vaddr & 0xffffffff80000000L) == 0xffffffff80000000L) + uaddr = (unsigned) CPHYSADDR(vaddr); + else if ((vaddr >> 62) == 2) + uaddr = (unsigned) XPHYSADDR(vaddr); + else { + unsigned long eh = vaddr & ~0x1fffL; + + eh |= read_c0_entryhi() & 0xff; + write_c0_entryhi(eh); + tlb_probe(); + if (read_c0_index() & 0x80000000) + return 0; + tlb_read(); + if (vaddr & (1L << PAGE_SHIFT)) + uaddr = (unsigned) read_c0_entrylo1(); + else + uaddr = (unsigned) read_c0_entrylo0(); + uaddr <<= 6; + uaddr &= ~PAGE_MASK; + uaddr |= vaddr & PAGE_MASK; + } + return ((uaddr & ~0x7f) == (paddr & ~0x7f)); +} + +/* Check, which kind of memory reference is triggered by `insn' */ + +static int check_special(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned func = insn & 0x3f; + + if (8 == func || 8+1 == func) /* JR, JALR */ + return JMP_REGISTER_OP; + + return 0; +} + +static int check_regimm(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned rt = (insn >> 19) & 3; /* bits 20..19[..16] */ + + /* BLTZ, BGEZ, BLTZL, BBGEZL || BLTZAL, BGEZAL, BLTZALL, BBGEZALL */ + if (!rt || 2 == rt) + return JMP_PCREL16_OP; + + return 0; +} + +static int check_cop0(unsigned insn) +{ + /* See Doc2, pages 287 ff., 187 ff. */ + if ((insn >> 26) == 5*8+7) /* CACHE */ + switch ((insn >> 16) & 0x1f) { + case Index_Writeback_Inv_D: + case Hit_Writeback_Inv_D: + case Index_Writeback_Inv_S: + case Hit_Writeback_Inv_S: + return BASE_OFFSET_OP; + } + return 0; +} + +static int check_cop1(unsigned insn) +{ + /* See Doc1, pages B-108 ff. */ + unsigned fmt = (insn >> 21) & 0x1f; /* bits 25..21 */ + + if (8 == fmt) /* BC1* */ + return JMP_PCREL16_OP; + + return 0; +} + +static int check_cop1x(unsigned insn) +{ + /* See Doc1, pages B-108 ff. */ + switch (insn & 0x3f) { + case 0: /* LWXC1 */ + case 1: /* LDXC1 */ + case 8: /* SWXC1 */ + case 8+1: /* SDXC1 */ + return BASE_IDXREG_OP; + } + return 0; +} + +static int check_plain(unsigned insn) +{ + /* See Doc1, page A-180 */ + unsigned opcode = insn >> 26; + + if (2 == opcode || 3 == opcode) /* J, JAL */ + return JMP_INDEX26_OP; + + if ((4 <= opcode && opcode <= 7) || /* BEQ, BNE, BLEZ, BGTZ */ + (4+2*8 <= opcode && opcode <= 7+2*8)) /* BEQL, BNEL, BLEZL, BGTZL */ + return JMP_PCREL16_OP; + + if (6*8+3 == opcode) /* PREF */ + return 0; + + if (3*8+2 == opcode || 3*8+3 == opcode || /* LDL, LDR */ + 4*8 <= opcode) /* misc. LOAD, STORE */ + return BASE_OFFSET_OP; + + return 0; +} + +/* Check, whether the insn at EPC causes a memory access at `paddr' */ + +static int check_addr_in_insn(unsigned paddr, const struct pt_regs *regs) +{ + unsigned long epc; + unsigned insn; + unsigned long a; + int typ; + + epc = regs->cp0_cause & CAUSEF_BD ? regs->cp0_epc:regs->cp0_epc+4; + + /* show_code() from kernel/traps.c */ + if (__get_user(insn, (u32 *)epc)) + return 1; + + /* See Doc1, pages A-180, B-108 ff. */ + switch (insn >> 26) { + case 0: + typ = check_special(insn); + break; + case 1: + typ = check_regimm(insn); + break; + case 2*8: /* COP0 */ + case 5*8+7: /* CACHE */ + typ = check_cop0(insn); + break; + case 2*8+1: + typ = check_cop1(insn); + break; + case 2*8+3: + typ = check_cop1x(insn); + break; + default: + typ = check_plain(insn); + break; + } + switch (typ) { + case JMP_INDEX26_OP: + a = (regs->cp0_epc + 4) & ~0xfffffff; + a |= (insn & 0x3ffffff) << 2; + return match_addr(paddr, a); + case JMP_REGISTER_OP: + a = regs->regs[(insn >> 21) & 0x1f]; + return match_addr(paddr, a); + case JMP_PCREL16_OP: + a = regs->cp0_epc + 4 + ((insn & 0xffff) << 2); + return match_addr(paddr, a); + case BASE_OFFSET_OP: + a = regs->regs[(insn >> 21) & 0x1f] + (insn & 0xffff); + return match_addr(paddr, a); + case BASE_IDXREG_OP: + a = regs->regs[(insn >> 21) & 0x1f]; + a += regs->regs[(insn >> 16) & 0x1f]; + return match_addr(paddr, a); + case 0: + return 0; + } + /* Assume it would be too dangerous to continue ... */ + return 1; +} + +/* + * Check, whether MC's (virtual) DMA address caused the bus error. + * See "Virtual DMA Specification", Draft 1.5, Feb 13 1992, SGI + */ + +static int addr_is_ram(unsigned long addr, unsigned sz) +{ + int i; + + for (i = 0; i < boot_mem_map.nr_map; i++) { + unsigned long a = boot_mem_map.map[i].addr; + if (a <= addr && addr+sz <= a+boot_mem_map.map[i].size) + return 1; + } + return 0; +} + +static int check_microtlb(u32 hi, u32 lo, unsigned long vaddr) +{ + /* This is likely rather similar to correct code ;-) */ + + vaddr &= 0x7fffffff; /* Doc. states that top bit is ignored */ + + /* If tlb-entry is valid and VPN-high (bits [30:21] ?) matches... */ + if ((lo & 2) && (vaddr >> 21) == ((hi<<1) >> 22)) { + u32 ctl = sgimc->dma_ctrl; + if (ctl & 1) { + unsigned int pgsz = (ctl & 2) ? 14:12; /* 16k:4k */ + /* PTEIndex is VPN-low (bits [22:14]/[20:12] ?) */ + unsigned long pte = (lo >> 6) << 12; /* PTEBase */ + pte += 8*((vaddr >> pgsz) & 0x1ff); + if (addr_is_ram(pte, 8)) { + /* + * Note: Since DMA hardware does look up + * translation on its own, this PTE *must* + * match the TLB/EntryLo-register format ! + */ + unsigned long a = *(unsigned long *) + PHYS_TO_XKSEG_UNCACHED(pte); + a = (a & 0x3f) << 6; /* PFN */ + a += vaddr & ((1 << pgsz) - 1); + return (cpu_err_addr == a); + } + } + } + return 0; +} + +static int check_vdma_memaddr(void) +{ + if (cpu_err_stat & CPU_ERRMASK) { + u32 a = sgimc->maddronly; + + if (!(sgimc->dma_ctrl & 0x100)) /* Xlate-bit clear ? */ + return (cpu_err_addr == a); + + if (check_microtlb(sgimc->dtlb_hi0, sgimc->dtlb_lo0, a) || + check_microtlb(sgimc->dtlb_hi1, sgimc->dtlb_lo1, a) || + check_microtlb(sgimc->dtlb_hi2, sgimc->dtlb_lo2, a) || + check_microtlb(sgimc->dtlb_hi3, sgimc->dtlb_lo3, a)) + return 1; + } + return 0; +} + +static int check_vdma_gioaddr(void) +{ + if (gio_err_stat & GIO_ERRMASK) { + u32 a = sgimc->gio_dma_trans; + a = (sgimc->gmaddronly & ~a) | (sgimc->gio_dma_sbits & a); + return (gio_err_addr == a); + } + return 0; +} + +/* + * MC sends an interrupt whenever bus or parity errors occur. In addition, + * if the error happened during a CPU read, it also asserts the bus error + * pin on the R4K. Code in bus error handler save the MC bus error registers + * and then clear the interrupt when this happens. + */ + +static int ip28_be_interrupt(const struct pt_regs *regs) +{ + int i; + + save_and_clear_buserr(); + /* + * Try to find out, whether we got here by a mispredicted speculative + * load/store operation. If so, it's not fatal, we can go on. + */ + /* Any cause other than "Interrupt" (ExcCode 0) is fatal. */ + if (regs->cp0_cause & CAUSEF_EXCCODE) + goto mips_be_fatal; + + /* Any cause other than "Bus error interrupt" (IP6) is weird. */ + if ((regs->cp0_cause & CAUSEF_IP6) != CAUSEF_IP6) + goto mips_be_fatal; + + if (extio_stat & (EXTIO_HPC3_BUSERR | EXTIO_EISA_BUSERR)) + goto mips_be_fatal; + + /* Any state other than "Memory bus error" is fatal. */ + if (cpu_err_stat & CPU_ERRMASK & ~SGIMC_CSTAT_ADDR) + goto mips_be_fatal; + + /* Any state other than "GIO transaction bus timed out" is fatal. */ + if (gio_err_stat & GIO_ERRMASK & ~SGIMC_GSTAT_TIME) + goto mips_be_fatal; + + /* Finding `cpu_err_addr' in the insn at EPC is fatal. */ + if ((cpu_err_stat & CPU_ERRMASK) && + check_addr_in_insn(cpu_err_addr, regs)) + goto mips_be_fatal; + + /* Finding `gio_err_addr' in the insn at EPC is fatal. */ + if ((gio_err_stat & GIO_ERRMASK) && + check_addr_in_insn(gio_err_addr, regs)) + goto mips_be_fatal; + /* + * Now we have an asynchronous bus error, speculatively or DMA caused. + * Need to search all DMA descriptors for the error address. + */ + for (i = 0; i < sizeof(hpc3)/sizeof(struct hpc3_stat); ++i) { + struct hpc3_stat *hp = (struct hpc3_stat *)&hpc3 + i; + if ((cpu_err_stat & CPU_ERRMASK) && + (cpu_err_addr == hp->ndptr || cpu_err_addr == hp->cbp)) + break; + if ((gio_err_stat & GIO_ERRMASK) && + (gio_err_addr == hp->ndptr || gio_err_addr == hp->cbp)) + break; + } + if (i < sizeof(hpc3)/sizeof(struct hpc3_stat)) { + struct hpc3_stat *hp = (struct hpc3_stat *)&hpc3 + i; + printk(KERN_ERR "at DMA addresses: HPC3 @ %08lx:" + " ctl %08x, ndp %08x, cbp %08x\n", + CPHYSADDR(hp->addr), hp->ctrl, hp->ndptr, hp->cbp); + goto mips_be_fatal; + } + /* Check MC's virtual DMA stuff. */ + if (check_vdma_memaddr()) { + printk(KERN_ERR "at GIO DMA: mem address 0x%08x.\n", + sgimc->maddronly); + goto mips_be_fatal; + } + if (check_vdma_gioaddr()) { + printk(KERN_ERR "at GIO DMA: gio address 0x%08x.\n", + sgimc->gmaddronly); + goto mips_be_fatal; + } + /* A speculative bus error... */ + if (debug_be_interrupt) { + print_buserr(regs); + printk(KERN_ERR "discarded!\n"); + } + return MIPS_BE_DISCARD; + +mips_be_fatal: + print_buserr(regs); + return MIPS_BE_FATAL; +} + +void ip22_be_interrupt(int irq) +{ + const struct pt_regs *regs = get_irq_regs(); + + count_be_interrupt++; + + if (ip28_be_interrupt(regs) != MIPS_BE_DISCARD) { + /* Assume it would be too dangerous to continue ... */ + die_if_kernel("Oops", regs); + force_sig(SIGBUS, current); + } else if (debug_be_interrupt) + show_regs((struct pt_regs *)regs); +} + +static int ip28_be_handler(struct pt_regs *regs, int is_fixup) +{ + /* + * We arrive here only in the unusual case of do_be() invocation, + * i.e. by a bus error exception without a bus error interrupt. + */ + if (is_fixup) { + count_be_is_fixup++; + save_and_clear_buserr(); + return MIPS_BE_FIXUP; + } + count_be_handler++; + return ip28_be_interrupt(regs); +} + +void __init ip22_be_init(void) +{ + board_be_handler = ip28_be_handler; +} + +int ip28_show_be_info(struct seq_file *m) +{ + seq_printf(m, "IP28 be fixups\t\t: %u\n", count_be_is_fixup); + seq_printf(m, "IP28 be interrupts\t: %u\n", count_be_interrupt); + seq_printf(m, "IP28 be handler\t\t: %u\n", count_be_handler); + + return 0; +} + +static int __init debug_be_setup(char *str) +{ + debug_be_interrupt++; + return 1; +} +__setup("ip28_debug_be", debug_be_setup); + diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index bf18d75..aa12e26 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -777,7 +777,7 @@ config JS_RTC config SGI_DS1286 tristate "SGI DS1286 RTC support" - depends on SGI_IP22 + depends on (SGI_IP22 || SGI_IP28) help If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod ("man mknod"), you diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h index dd22d91..08a5f20 100644 --- a/drivers/input/serio/i8042.h +++ b/drivers/input/serio/i8042.h @@ -16,7 +16,7 @@ #if defined(CONFIG_MACH_JAZZ) #include "i8042-jazzio.h" -#elif defined(CONFIG_SGI_IP22) +#elif defined(CONFIG_SGI_IP22) || defined(CONFIG_SGI_IP28) #include "i8042-ip22io.h" #elif defined(CONFIG_PPC) #include "i8042-ppcio.h" diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7a55bc1..816d20f 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1795,7 +1795,7 @@ config DE620 config SGISEEQ tristate "SGI Seeq ethernet controller support" - depends on SGI_IP22 + depends on SGI_IP22 || SGI_IP28 help Say Y here if you have an Seeq based Ethernet network card. This is used in many Silicon Graphics machines. diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..e422484 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -345,7 +345,7 @@ config ISCSI_TCP config SGIWD93_SCSI tristate "SGI WD93C93 SCSI Driver" - depends on SGI_IP22 && SCSI + depends on (SGI_IP22 || SGI_IP26 || SGI_IP28) && SCSI help If you have a Western Digital WD93 SCSI controller on an SGI MIPS system, say Y. Otherwise, say N. diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index ed438bc..ab59185 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -878,16 +878,18 @@ config SERIAL_SUNHV config SERIAL_IP22_ZILOG tristate "IP22 Zilog8530 serial support" - depends on SGI_IP22 + depends on (SGI_IP22 || SGI_IP28) select SERIAL_CORE + default y if SGI_IP28 help - This driver supports the Zilog8530 serial ports found on SGI IP22 + This driver supports the Zilog8530 serial ports found on SGI IP22-IP28 systems. Say Y or M if you want to be able to these serial ports. config SERIAL_IP22_ZILOG_CONSOLE - bool "Console on IP22 Zilog8530 serial port" + bool "Console on IP22/IP28 Zilog8530 serial port" depends on SERIAL_IP22_ZILOG=y select SERIAL_CORE_CONSOLE + default y if SGI_IP28 config V850E_UART bool "NEC V850E on-chip UART support" diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 2792bc1..9170501 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -586,7 +586,7 @@ config SBC_EPX_C3_WATCHDOG config INDYDOG tristate "Indy/I2 Hardware Watchdog" - depends on SGI_IP22 + depends on SGI_IP22 || SGI_IP28 help Hardware driver for the Indy's/I2's watchdog. This is a watchdog timer that will reboot the machine after a 60 second diff --git a/fs/partitions/Kconfig b/fs/partitions/Kconfig index a99acd8..4ee783b 100644 --- a/fs/partitions/Kconfig +++ b/fs/partitions/Kconfig @@ -198,7 +198,7 @@ config LDM_DEBUG config SGI_PARTITION bool "SGI partition support" if PARTITION_ADVANCED - default y if (SGI_IP22 || SGI_IP27 || ((MACH_JAZZ || SNI_RM) && !CPU_LITTLE_ENDIAN)) + default y if (SGI_IP22 || SGI_IP27 || SGI_IP28 || ((MACH_JAZZ || SNI_RM) && !CPU_LITTLE_ENDIAN)) help Say Y here if you would like to be able to read the hard disk partition table format used by SGI machines. diff --git a/include/asm-mips/dma.h b/include/asm-mips/dma.h index 833437d..80caf6b 100644 --- a/include/asm-mips/dma.h +++ b/include/asm-mips/dma.h @@ -88,6 +88,9 @@ /* Horrible hack to have a correct DMA window on IP22 */ #include #define MAX_DMA_ADDRESS (PAGE_OFFSET + SGIMC_SEG0_BADDR + 0x01000000) +#elif defined(CONFIG_SGI_IP28) +#include +#define MAX_DMA_ADDRESS (PAGE_OFFSET + SGIMC_SEG1_BADDR + 0x01000000) #else #define MAX_DMA_ADDRESS (PAGE_OFFSET + 0x01000000) #endif diff --git a/include/asm-mips/mach-ip28/cpu-feature-overrides.h b/include/asm-mips/mach-ip28/cpu-feature-overrides.h new file mode 100644 index 0000000..9a53b32 --- /dev/null +++ b/include/asm-mips/mach-ip28/cpu-feature-overrides.h @@ -0,0 +1,50 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2003 Ralf Baechle + * 6/2004 pf + */ +#ifndef __ASM_MACH_IP28_CPU_FEATURE_OVERRIDES_H +#define __ASM_MACH_IP28_CPU_FEATURE_OVERRIDES_H + +/* + * IP28 only comes with R10000 family processors all using the same config + */ +#define cpu_has_watch 1 +#define cpu_has_mips16 0 +#define cpu_has_divec 0 +#define cpu_has_vce 0 +#define cpu_has_cache_cdex_p 0 +#define cpu_has_cache_cdex_s 0 +#define cpu_has_prefetch 1 +#define cpu_has_mcheck 0 +#define cpu_has_ejtag 0 + +#define cpu_has_llsc 1 +#define cpu_has_vtag_icache 0 +#define cpu_has_dc_aliases 0 /* see probe_pcache() */ +#define cpu_has_ic_fills_f_dc 0 +#define cpu_has_dsp 0 +#define cpu_icache_snoops_remote_store 1 +#define cpu_has_mipsmt 0 +#define cpu_has_userlocal 0 + +#define cpu_has_nofpuex 0 +#define cpu_has_64bits 1 + +#define cpu_has_4kex 1 +#define cpu_has_4k_cache 1 + +#define cpu_has_inclusive_pcaches 1 + +#define cpu_dcache_line_size() 32 +#define cpu_icache_line_size() 64 + +#define cpu_has_mips32r1 0 +#define cpu_has_mips32r2 0 +#define cpu_has_mips64r1 0 +#define cpu_has_mips64r2 0 + +#endif /* __ASM_MACH_IP28_CPU_FEATURE_OVERRIDES_H */ diff --git a/include/asm-mips/mach-ip28/ds1286.h b/include/asm-mips/mach-ip28/ds1286.h new file mode 100644 index 0000000..471bb9a --- /dev/null +++ b/include/asm-mips/mach-ip28/ds1286.h @@ -0,0 +1,4 @@ +#ifndef __ASM_MACH_IP28_DS1286_H +#define __ASM_MACH_IP28_DS1286_H +#include +#endif /* __ASM_MACH_IP28_DS1286_H */ diff --git a/include/asm-mips/mach-ip28/spaces.h b/include/asm-mips/mach-ip28/spaces.h new file mode 100644 index 0000000..05aabb2 --- /dev/null +++ b/include/asm-mips/mach-ip28/spaces.h @@ -0,0 +1,22 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 1994 - 1999, 2000, 03, 04 Ralf Baechle + * Copyright (C) 2000, 2002 Maciej W. Rozycki + * Copyright (C) 1990, 1999, 2000 Silicon Graphics, Inc. + * 2004 pf + */ +#ifndef _ASM_MACH_IP28_SPACES_H +#define _ASM_MACH_IP28_SPACES_H + +#define CAC_BASE 0xa800000000000000 + +#define HIGHMEM_START (~0UL) + +#define PHYS_OFFSET _AC(0x20000000, UL) + +#include + +#endif /* _ASM_MACH_IP28_SPACES_H */ diff --git a/include/asm-mips/mach-ip28/war.h