From owner-freebsd-mips@FreeBSD.ORG Sun Dec 5 22:10:11 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2F4E106566B for ; Sun, 5 Dec 2010 22:10:11 +0000 (UTC) (envelope-from freebsd-mips@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8958FC14 for ; Sun, 5 Dec 2010 22:10:10 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sun, 05 Dec 2010 23:09:53 +0100 id 00033C19.4CFC0DBF.00015EE1 From: Milan Obuch To: freebsd-mips@freebsd.org Date: Sun, 5 Dec 2010 23:10:37 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.3; i386; ; ) MIME-Version: 1.0 Message-Id: <201012052310.37998.freebsd-mips@dino.sk> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: xz in base system trouble on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 22:10:11 -0000 Hi, I am trying to test various system parts and ports building on my RSPRO. There is a problem with xz as compiled with base system - trying to build misc/mc gives 'unknown file format' error on /usr/ports/distfiles/mc-4.7.4.tar.lzma tarball. After commenting out IGNORE line in archive/xz Makefile, compilling, installing the port and 'cp /usr/local/bin/xz /usr/bin/xz' this error is gone. What could be root cause of this? As both base system and ports xz is version 5.0, I think there must be some error in base system integration or some tweaking is not done... Regards, Milan From owner-freebsd-mips@FreeBSD.ORG Sun Dec 5 23:06:43 2010 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D531065670 for ; Sun, 5 Dec 2010 23:06:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 456E58FC14 for ; Sun, 5 Dec 2010 23:06:43 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id oB5N6f4B013502 for ; Sun, 5 Dec 2010 16:06:41 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4CFC1B01.4010009@bsdimp.com> Date: Sun, 05 Dec 2010 16:06:41 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-mips@FreeBSD.org References: <201012052310.37998.freebsd-mips@dino.sk> In-Reply-To: <201012052310.37998.freebsd-mips@dino.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: xz in base system trouble on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 23:06:43 -0000 On 12/05/2010 15:10, Milan Obuch wrote: > Hi, > > I am trying to test various system parts and ports building on my RSPRO. There > is a problem with xz as compiled with base system - trying to build misc/mc > gives 'unknown file format' error on /usr/ports/distfiles/mc-4.7.4.tar.lzma > tarball. After commenting out IGNORE line in archive/xz Makefile, compilling, > installing the port and 'cp /usr/local/bin/xz /usr/bin/xz' this error is gone. > > What could be root cause of this? As both base system and ports xz is version > 5.0, I think there must be some error in base system integration or some > tweaking is not done... I always guess endian problems on MIPS or big endian ARM when things don't work quite right. But I don't see any errors there... First step: diff the sources? also, current or stable? Warner From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 06:39:24 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC829106564A for ; Mon, 6 Dec 2010 06:39:24 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5AF968FC13 for ; Mon, 6 Dec 2010 06:39:23 +0000 (UTC) Received: by wyf19 with SMTP id 19so11872487wyf.13 for ; Sun, 05 Dec 2010 22:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=k3fm96GRCSJ66KGasI9Ei9R20Dj0FYvjeAqLmgxeUBE=; b=vv8UkQL8HtinPaDUL5xEXYT0vaCxg+UBS8CdQMnTQRq+qzcL3mfNa5Uxhk9ZzVvEs/ gn7Euwr9iIj66Kz0JaFUcB/K+xQ5Kt1vy8W+ttdkFxfZpjnmsVIKjQifRUpeROHy2Tvh 9yVDIf8qUsLgEYOZsvGDY/wUSfOtjQy9am9ZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QI4dxJtnwJ+aQrg/7hAaO9fR82s0bHbS/xabmumtpczjZSKKYxcgFUTrQ2Fxj7OYlu y2CMFERzn9SnU1IhVFANmnYIX63/CFZJ/lHOapm61Fg83YB0RMBguyIAyynblAXhHU2K AkXNMiwv9mI/XWkaiIvhsXs84NPQ4kBszhAf4= MIME-Version: 1.0 Received: by 10.227.141.78 with SMTP id l14mr5199896wbu.15.1291617563178; Sun, 05 Dec 2010 22:39:23 -0800 (PST) Received: by 10.227.135.84 with HTTP; Sun, 5 Dec 2010 22:39:23 -0800 (PST) Date: Mon, 6 Dec 2010 12:09:23 +0530 Message-ID: From: "Jayachandran C." To: freebsd-mips@freebsd.org, Alan Cox Content-Type: multipart/mixed; boundary=0016e65b584009f8a40496b826c3 Cc: Subject: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 06:39:24 -0000 --0016e65b584009f8a40496b826c3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The attached patch uses the mechanism used to allocate page table pages for UMA small allocations too. This will make sure that all the small UMA allocations comes from KSEG0 pages in 32 bit and XKPHYS in 64bit. This reduces TLB misses in kernel code significantly, and can give major performance advantage for applications that spent a lot of time in kernel. Please let me know your comments. Thanks, JC. --0016e65b584009f8a40496b826c3 Content-Type: text/x-patch; charset=US-ASCII; name="mips-uma.patch" Content-Disposition: attachment; filename="mips-uma.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ghcyuj7h0 SW5kZXg6IHN5cy9taXBzL2luY2x1ZGUvcG1hcC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBzL2lu Y2x1ZGUvcG1hcC5oCShyZXZpc2lvbiAyMTYxNDcpCisrKyBzeXMvbWlwcy9pbmNsdWRlL3BtYXAu aAkod29ya2luZyBjb3B5KQpAQCAtMTYzLDYgKzE2Myw5IEBACiBpbnQgcG1hcF9jb21wdXRlX3Bh Z2VzX3RvX2R1bXAodm9pZCk7CiB2b2lkIHBtYXBfZmx1c2hfcHZjYWNoZSh2bV9wYWdlX3QgbSk7 CiBpbnQgcG1hcF9lbXVsYXRlX21vZGlmaWVkKHBtYXBfdCBwbWFwLCB2bV9vZmZzZXRfdCB2YSk7 Cit2b2lkIHBtYXBfZ3Jvd19kaXJlY3RfcGFnZV9jYWNoZSh2b2lkKTsKK3ZtX3BhZ2VfdCBwbWFw X2FsbG9jX2RpcmVjdF9wYWdlKHVuc2lnbmVkIGludCBpbmRleCwgaW50IHJlcSk7CisKICNlbmRp ZgkJCQkvKiBfS0VSTkVMICovCiAKICNlbmRpZgkJCQkvKiAhTE9DT1JFICovCkluZGV4OiBzeXMv bWlwcy9pbmNsdWRlL3ZtcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbWlwcy9pbmNsdWRlL3Zt cGFyYW0uaAkocmV2aXNpb24gMjE2MTU3KQorKysgc3lzL21pcHMvaW5jbHVkZS92bXBhcmFtLmgJ KHdvcmtpbmcgY29weSkKQEAgLTE0OSw2ICsxNDksOCBAQAogI2RlZmluZQlWTV9JTklUSUFMX1BB R0VJTgkxNgogI2VuZGlmCiAKKyNkZWZpbmUJVU1BX01EX1NNQUxMX0FMTE9DCisKIC8qCiAgKiBt YXggbnVtYmVyIG9mIG5vbi1jb250aWcgY2h1bmtzIG9mIHBoeXNpY2FsIFJBTSB5b3UgY2FuIGhh dmUKICAqLwpJbmRleDogc3lzL21pcHMvbWlwcy92bV9tYWNoZGVwLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c3lzL21pcHMvbWlwcy92bV9tYWNoZGVwLmMJKHJldmlzaW9uIDIxNjE0NykKKysrIHN5cy9taXBz L21pcHMvdm1fbWFjaGRlcC5jCSh3b3JraW5nIGNvcHkpCkBAIC01MzgsOCArNTM4LDU3IEBACiB2 b2lkCiBzd2lfdm0odm9pZCAqZHVtbXkpCiB7CisKKwlpZiAoYnVzZG1hX3N3aV9wZW5kaW5nKQor CQlidXNkbWFfc3dpKCk7CiB9CiAKK3ZvaWQgKgordW1hX3NtYWxsX2FsbG9jKHVtYV96b25lX3Qg em9uZSwgaW50IGJ5dGVzLCB1X2ludDhfdCAqZmxhZ3MsIGludCB3YWl0KQoreworCXN0YXRpYyB2 bV9waW5kZXhfdCBjb2xvcjsKKwl2bV9wYWRkcl90IHBhOworCXZtX3BhZ2VfdCBtOworCWludCBw ZmxhZ3M7CisJdm9pZCAqdmE7CisKKwkqZmxhZ3MgPSBVTUFfU0xBQl9QUklWOworCisJaWYgKCh3 YWl0ICYgKE1fTk9XQUlUfE1fVVNFX1JFU0VSVkUpKSA9PSBNX05PV0FJVCkKKwkJcGZsYWdzID0g Vk1fQUxMT0NfSU5URVJSVVBUOworCWVsc2UKKwkJcGZsYWdzID0gVk1fQUxMT0NfU1lTVEVNOwor CisJZm9yICg7OykgeworCQltID0gcG1hcF9hbGxvY19kaXJlY3RfcGFnZShjb2xvcisrLCBwZmxh Z3MpOworCQlpZiAobSA9PSBOVUxMKSB7CisJCQlpZiAod2FpdCAmIE1fTk9XQUlUKQorCQkJCXJl dHVybiAoTlVMTCk7CisJCQllbHNlCisJCQkJcG1hcF9ncm93X2RpcmVjdF9wYWdlX2NhY2hlKCk7 CisJCX0gZWxzZQorCQkJYnJlYWs7CisJfQorCisJcGEgPSBWTV9QQUdFX1RPX1BIWVMobSk7CisJ dmEgPSAodm9pZCAqKU1JUFNfUEhZU19UT19ESVJFQ1QocGEpOworCWlmICgod2FpdCAmIE1fWkVS TykgJiYgKG0tPmZsYWdzICYgUEdfWkVSTykgPT0gMCkKKwkJYnplcm8odmEsIFBBR0VfU0laRSk7 CisJcmV0dXJuICh2YSk7Cit9CisKK3ZvaWQKK3VtYV9zbWFsbF9mcmVlKHZvaWQgKm1lbSwgaW50 IHNpemUsIHVfaW50OF90IGZsYWdzKQoreworCXZtX3BhZ2VfdCBtOworCisJbSA9IFBIWVNfVE9f Vk1fUEFHRShNSVBTX0RJUkVDVF9UT19QSFlTKCh2bV9vZmZzZXRfdCltZW0pKTsKKwltLT53aXJl X2NvdW50LS07CisJdm1fcGFnZV9mcmVlKG0pOworCWF0b21pY19zdWJ0cmFjdF9pbnQoJmNudC52 X3dpcmVfY291bnQsIDEpOworfQorCisKIGludAogY3B1X3NldF91c2VyX3RscyhzdHJ1Y3QgdGhy ZWFkICp0ZCwgdm9pZCAqdGxzX2Jhc2UpCiB7CkluZGV4OiBzeXMvbWlwcy9taXBzL3BtYXAuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvbWlwcy9taXBzL3BtYXAuYwkocmV2aXNpb24gMjE2MTU3KQorKysg c3lzL21pcHMvbWlwcy9wbWFwLmMJKHdvcmtpbmcgY29weSkKQEAgLTE4NSw4ICsxODUsNiBAQAog c3RhdGljIHZtX3BhZ2VfdCBfcG1hcF9hbGxvY3B0ZShwbWFwX3QgcG1hcCwgdW5zaWduZWQgcHRl cGluZGV4LCBpbnQgZmxhZ3MpOwogc3RhdGljIGludCBwbWFwX3VudXNlX3B0KHBtYXBfdCwgdm1f b2Zmc2V0X3QsIHZtX3BhZ2VfdCk7CiBzdGF0aWMgaW50IGluaXRfcHRlX3Byb3Qodm1fb2Zmc2V0 X3QgdmEsIHZtX3BhZ2VfdCBtLCB2bV9wcm90X3QgcHJvdCk7Ci1zdGF0aWMgdm1fcGFnZV90IHBt YXBfYWxsb2NfcHRlX3BhZ2UodW5zaWduZWQgaW50IGluZGV4LCBpbnQgcmVxKTsKLXN0YXRpYyB2 b2lkIHBtYXBfZ3Jvd19wdGVfcGFnZV9jYWNoZSh2b2lkKTsKIAogI2lmZGVmIFNNUAogc3RhdGlj IHZvaWQgcG1hcF9pbnZhbGlkYXRlX3BhZ2VfYWN0aW9uKHZvaWQgKmFyZyk7CkBAIC0xMDYyLDgg KzEwNjAsOCBAQAogCWJ6ZXJvKCZwbWFwLT5wbV9zdGF0cywgc2l6ZW9mIHBtYXAtPnBtX3N0YXRz KTsKIH0KIAotc3RhdGljIHZvaWQKLXBtYXBfZ3Jvd19wdGVfcGFnZV9jYWNoZSgpCit2b2lkCitw bWFwX2dyb3dfZGlyZWN0X3BhZ2VfY2FjaGUoKQogewogCiAjaWZkZWYgX19taXBzX242NApAQCAt MTA3Myw4ICsxMDcxLDggQEAKICNlbmRpZgogfQogCi1zdGF0aWMgdm1fcGFnZV90Ci1wbWFwX2Fs bG9jX3B0ZV9wYWdlKHVuc2lnbmVkIGludCBpbmRleCwgaW50IHJlcSkKK3ZtX3BhZ2VfdAorcG1h cF9hbGxvY19kaXJlY3RfcGFnZSh1bnNpZ25lZCBpbnQgaW5kZXgsIGludCByZXEpCiB7CiAJdm1f cGFnZV90IG07CiAKQEAgLTExMDcsOCArMTEwNSw4IEBACiAJLyoKIAkgKiBhbGxvY2F0ZSB0aGUg cGFnZSBkaXJlY3RvcnkgcGFnZQogCSAqLwotCXdoaWxlICgocHRkcGcgPSBwbWFwX2FsbG9jX3B0 ZV9wYWdlKE5VU0VSUEdUQkxTLCBWTV9BTExPQ19OT1JNQUwpKSA9PSBOVUxMKQotCSAgICAgICBw bWFwX2dyb3dfcHRlX3BhZ2VfY2FjaGUoKTsKKwl3aGlsZSAoKHB0ZHBnID0gcG1hcF9hbGxvY19k aXJlY3RfcGFnZShOVVNFUlBHVEJMUywgVk1fQUxMT0NfTk9STUFMKSkgPT0gTlVMTCkKKwkgICAg ICAgcG1hcF9ncm93X2RpcmVjdF9wYWdlX2NhY2hlKCk7CiAKIAlwdGR2YSA9IE1JUFNfUEhZU19U T19ESVJFQ1QoVk1fUEFHRV9UT19QSFlTKHB0ZHBnKSk7CiAJcG1hcC0+cG1fc2VndGFiID0gKHBk X2VudHJ5X3QgKilwdGR2YTsKQEAgLTExNDEsMTEgKzExMzksMTEgQEAKIAkvKgogCSAqIEZpbmQg b3IgZmFicmljYXRlIGEgbmV3IHBhZ2V0YWJsZSBwYWdlCiAJICovCi0JaWYgKChtID0gcG1hcF9h bGxvY19wdGVfcGFnZShwdGVwaW5kZXgsIFZNX0FMTE9DX05PUk1BTCkpID09IE5VTEwpIHsKKwlp ZiAoKG0gPSBwbWFwX2FsbG9jX2RpcmVjdF9wYWdlKHB0ZXBpbmRleCwgVk1fQUxMT0NfTk9STUFM KSkgPT0gTlVMTCkgewogCQlpZiAoZmxhZ3MgJiBNX1dBSVRPSykgewogCQkJUE1BUF9VTkxPQ0so cG1hcCk7CiAJCQl2bV9wYWdlX3VubG9ja19xdWV1ZXMoKTsKLQkJCXBtYXBfZ3Jvd19wdGVfcGFn ZV9jYWNoZSgpOworCQkJcG1hcF9ncm93X2RpcmVjdF9wYWdlX2NhY2hlKCk7CiAJCQl2bV9wYWdl X2xvY2tfcXVldWVzKCk7CiAJCQlQTUFQX0xPQ0socG1hcCk7CiAJCX0KQEAgLTEzMTMsNyArMTMx MSw3IEBACiAjaWZkZWYgX19taXBzX242NAogCQlpZiAoKnBkcGUgPT0gMCkgewogCQkJLyogbmV3 IGludGVybWVkaWF0ZSBwYWdlIHRhYmxlIGVudHJ5ICovCi0JCQlua3BnID0gcG1hcF9hbGxvY19w dGVfcGFnZShua3B0LCBWTV9BTExPQ19JTlRFUlJVUFQpOworCQkJbmtwZyA9IHBtYXBfYWxsb2Nf ZGlyZWN0X3BhZ2UobmtwdCwgVk1fQUxMT0NfSU5URVJSVVBUKTsKIAkJCWlmIChua3BnID09IE5V TEwpCiAJCQkJcGFuaWMoInBtYXBfZ3Jvd2tlcm5lbDogbm8gbWVtb3J5IHRvIGdyb3cga2VybmVs Iik7CiAJCQkqcGRwZSA9IChwZF9lbnRyeV90KU1JUFNfUEhZU19UT19ESVJFQ1QoVk1fUEFHRV9U T19QSFlTKG5rcGcpKTsKQEAgLTEzMzMsNyArMTMzMSw3IEBACiAJCS8qCiAJCSAqIFRoaXMgaW5k ZXggaXMgYm9ndXMsIGJ1dCBvdXQgb2YgdGhlIHdheQogCQkgKi8KLQkJbmtwZyA9IHBtYXBfYWxs b2NfcHRlX3BhZ2UobmtwdCwgVk1fQUxMT0NfSU5URVJSVVBUKTsKKwkJbmtwZyA9IHBtYXBfYWxs b2NfZGlyZWN0X3BhZ2UobmtwdCwgVk1fQUxMT0NfSU5URVJSVVBUKTsKIAkJaWYgKCFua3BnKQog CQkJcGFuaWMoInBtYXBfZ3Jvd2tlcm5lbDogbm8gbWVtb3J5IHRvIGdyb3cga2VybmVsIik7CiAJ CW5rcHQrKzsK --0016e65b584009f8a40496b826c3-- From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 09:37:28 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 166B4106564A; Mon, 6 Dec 2010 09:37:28 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id C06098FC0C; Mon, 6 Dec 2010 09:37:27 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1PPXVc-0001Nn-Tp; Mon, 06 Dec 2010 11:37:25 +0200 Date: Mon, 6 Dec 2010 11:37:41 +0200 From: Alexandr Rybalko To: Adrian Chadd Message-Id: <20101206113741.fdb82ab3.ray@dlink.ua> In-Reply-To: References: <4CE491ED.3030308@userid.org> <20101118125812.60e9aafc.ray@dlink.ua> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-mips@freebsd.org Subject: Re: What platforms are you running? X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 09:37:28 -0000 On Sun, 21 Nov 2010 15:20:35 +0800 Adrian Chadd wrote: >> This sounds like the beginnings of a "Actively developed devices" >> section on the Wiki. :-) --------------------------------------------------------------- DIR-320_A1 D-Link Good -HEAD MIPS BCM5354 32MB bfe 10/100 attached to internal 5port 10/100 switch - 4MB NOR USB 2.0 8x GPIO Pins(LED/Button) - --------------------------------------------------------------- DAP-1350_A1 D-Link Good -HEAD MIPS RT3052F 32MB rt 10/100/1000 attached to internal 5port 10/100 switch(only 1 port wired) - 8MB NOR USB 2.0 OTG 7x GPIO Pins(LED/Button)(+2 if disable UART) USB - not yet done --------------------------------------------------------------- >> >> >> Adrian >> >> On 18 November 2010 18:58, Alexandr Rybalko wrote: >> > On Wed, 17 Nov 2010 21:39:41 -0500 >> > Pierre Lamy wrote: >> > >> >>> I'm curious, what specific MIPS platforms will the -CURRENT tree run on, >> >>> and what are you developing on? >> >>> >> > >> > I'm using Broadcom BCM5354 and Ralink RT3052F. >> > >> > -- >> > Alexandr Rybalko >> > aka Alex RAY >> > _______________________________________________ >> > freebsd-mips@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >> > -- Рыбалко Александр Консультант D-Link Украина From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 09:54:34 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24B941065670 for ; Mon, 6 Dec 2010 09:54:34 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gw0-f49.google.com (mail-gw0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id DEC738FC1C for ; Mon, 6 Dec 2010 09:54:33 +0000 (UTC) Received: by mail-gw0-f49.google.com with SMTP id 20so6348909gwj.36 for ; Mon, 06 Dec 2010 01:54:33 -0800 (PST) Received: by 10.150.146.18 with SMTP id t18mr5143550ybd.19.1291629273682; Mon, 06 Dec 2010 01:54:33 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.236.108.51 with HTTP; Mon, 6 Dec 2010 01:54:13 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Mon, 6 Dec 2010 01:54:13 -0800 X-Google-Sender-Auth: eEVhoXDBjzuaACPzixiIVoSSArw Message-ID: To: "Jayachandran C." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 09:54:34 -0000 Hi JC, On Sun, Dec 5, 2010 at 22:39, Jayachandran C. wr= ote: > The attached patch uses the mechanism used to allocate page table > pages for UMA small allocations too. =A0This will make sure that all the > small UMA allocations comes from KSEG0 pages in 32 bit and XKPHYS in > 64bit. > > This reduces TLB misses in kernel code significantly, and can give > major performance advantage for applications that spent a lot of time > in kernel. > > Please let me know your comments. It looks reasonable to me. I've gone over the other unmerged changes related to the direct map in my Octeon branch and wonder if you would like to handle other expansions of use of the direct map, particularly on n64: o) Using the direct map for sendfile. (Making sf_buf_alloc and sf_buf_free no-ops, like on sun4v, I think, rather than the whole freelist approach of e.g. sparc64, but I don't remember the details of why one implementation vs. the other at the moment.) o) Making uiomove_fromphys use XKPHYS on n64. (I think that this will help our pipe performance a non-trivial amount, but it has been some time since I tested it.) If not I will try to make those changes in the near future, but I thought that (1) perhaps you had a reason for not making those changes with your n64 work in -CURRENT (2) since you're making related changes, you might like to do so, and also might be able to quantify what you feel the overall affect on performance to be. Thanks again for all of your work in this area! Juli. From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 10:26:01 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D1C106566C; Mon, 6 Dec 2010 10:26:01 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D77CE8FC15; Mon, 6 Dec 2010 10:26:00 +0000 (UTC) Received: by wyf19 with SMTP id 19so12042872wyf.13 for ; Mon, 06 Dec 2010 02:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4Gwvv2n9PkeyUzRYliD5/LEFRHMkFNFFzr5850pCmXc=; b=fceA7ZdJGKXMl49O/St2jXMhfEZLBldIb04F0EjzDzMrxsCQHfwQQK+Ad53xvKSbS0 kWEXMYzldzhpjoxmp6sJfnGLYOGHOr1CJ9sjvozzxfkSaOxVCUkirRdyng9AZLm8L1u7 gTqe7rUXw3fkTnmvPMtf2yNmEherKR6awbmQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NqLjI5tRzM0hAKaKvmytZyk+42UYBhaRP3wOvdEsQPXft+tRt3tqZr1foCokyZY+D2 pQ+a0MHPvWB8/eTQ5adAPrnZeUTEseW5/S8+DjHBOC2+AqzZZEJ3K/A3O8cqr8rz6KW9 UgDxP5s1nZN4GdegyFzRHArAp9mfOFcPlWZzI= MIME-Version: 1.0 Received: by 10.227.128.211 with SMTP id l19mr5333905wbs.73.1291631159838; Mon, 06 Dec 2010 02:25:59 -0800 (PST) Received: by 10.227.135.84 with HTTP; Mon, 6 Dec 2010 02:25:59 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Dec 2010 15:55:59 +0530 Message-ID: From: "Jayachandran C." To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 10:26:01 -0000 On Mon, Dec 6, 2010 at 3:24 PM, Juli Mallett wrote: > Hi JC, > > On Sun, Dec 5, 2010 at 22:39, Jayachandran C. = wrote: >> The attached patch uses the mechanism used to allocate page table >> pages for UMA small allocations too. =A0This will make sure that all the >> small UMA allocations comes from KSEG0 pages in 32 bit and XKPHYS in >> 64bit. >> >> This reduces TLB misses in kernel code significantly, and can give >> major performance advantage for applications that spent a lot of time >> in kernel. >> >> Please let me know your comments. > > It looks reasonable to me. =A0I've gone over the other unmerged changes > related to the direct map in my Octeon branch and wonder if you would > like to handle other expansions of use of the direct map, particularly > on n64: > > o) Using the direct map for sendfile. =A0(Making sf_buf_alloc and > sf_buf_free no-ops, like on sun4v, I think, rather than the whole > freelist approach of e.g. sparc64, but I don't remember the details of > why one implementation vs. the other at the moment.) > o) Making uiomove_fromphys use XKPHYS on n64. =A0(I think that this will > help our pipe performance a non-trivial amount, but it has been some > time since I tested it.) > > If not I will try to make those changes in the near future, but I > thought that (1) perhaps you had a reason for not making those changes > with your n64 work in -CURRENT (2) since you're making related > changes, you might like to do so, and also might be able to quantify > what you feel the overall affect on performance to be. I was planning to merge these changes. Now that the XLR platform code changes and 8-STABLE merge is done - I hope to get some time to do the rest of the n64 work. My rough todo list is : - 64bit PTEs which will give >4GB phys address, - 32 bit compat in n64 (merge from /user/jmallett/octeon) - Complete merge from /user/jmallett/octeon - UIO, sf buf - DDB/KDB fixes for n32/n64. - 16K pagesize (there were some patches from SoC, but it crashed for me) JC. From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 10:58:34 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1291F1065695 for ; Mon, 6 Dec 2010 10:58:34 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C9EB38FC19 for ; Mon, 6 Dec 2010 10:58:33 +0000 (UTC) Received: by gyf3 with SMTP id 3so6236008gyf.13 for ; Mon, 06 Dec 2010 02:58:33 -0800 (PST) Received: by 10.90.120.20 with SMTP id s20mr7545344agc.132.1291633113040; Mon, 06 Dec 2010 02:58:33 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.236.108.51 with HTTP; Mon, 6 Dec 2010 02:58:12 -0800 (PST) In-Reply-To: References: From: Juli Mallett Date: Mon, 6 Dec 2010 02:58:12 -0800 X-Google-Sender-Auth: 8KwNB-ORAdpZwXz9XMgb7PneOpI Message-ID: To: "Jayachandran C." Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 10:58:34 -0000 On Mon, Dec 6, 2010 at 02:25, Jayachandran C. wr= ote: > I was planning to merge these changes. Now that the XLR platform code > changes and 8-STABLE merge is done - I hope to get some time to do the > rest of the n64 work. My rough todo list is : > > - 64bit PTEs which will give >4GB phys address, I'm very excited about that; on Octeon it will mean that we can participate in the networking/messaging subsystem from userland, which I know will be very valuable for a lot of applications. > - 32 bit compat in n64 (merge from /user/jmallett/octeon) You probably don't want to spend much time on those changes; they were incomplete and focused on n32-on-n64. I know n32-on-n64 would be good, but is it your highest priority? o32-on-n64 will be easy because it's just like on other architectures. o32-on-n32 and n32-on-n64 require a complementary set of conditionals in the freebsd32 code to handle (in the former case) pointer size being unchanged and (in the latter case) register width being unchanged. I think we actually need to consider alternate compilation strategies for the freebsd32 code, such as filling it with ifdefs and #including the source files with different definitions so we can include o32 and n32 compat together on n64 kernels. > - Complete merge from /user/jmallett/octeon - UIO, sf buf Great :) > - DDB/KDB fixes for n32/n64. For what it's worth, DDB seems mostly complete on n64 these days, save for some issues in the trace code =97 I think we took the machdep ddb code from NetBSD and now that they support n32 and n64 I think we may just want to merge from them, no point duplicating that effort when the code is so crufty, complex and massive already. Maybe talk to bde@ or freebsd-arch@ or freebsd-hackers@ about the DDB changes required for n32 (and get someone to review the change to ufs to not use register_t where it mean uintptr_t / vm_offset_t) =97 some of the cleanups to be had there are good, but I think that there is some resistance to changing DDB just for n32. I think it's a good idea, but I'm not sure e.g. whether it's better to adjust the DDB APIs that pass addresses to use vm_offset_t or uintptr_t, or to keep them passing register_t and to make code that takes addresses from registers (or register_ts) more careful about how it converts them, since probably other ABIs will come along where using an opaque register type as something that can be converted directly to a pointer is bad. Perhaps what we really need are more debugger-specific types. Something that might be a worthwhile sell would be to continue to pass register_t in those APIs and to introduce a call (that can fail) to map a register_t to an address usable by the debugger, that way we can also do clever things to avoid page faults within the debugger, in addition to doing the necessary casts on n32. That would benefit more than just MIPS. > - 16K pagesize (there were some patches from SoC, but it crashed for me) Do you want to support both 4K and 16K pages on all MIPS ABIs, or just n64, or make n64 always 16k and everything else always 4k? Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Mon Dec 6 17:04:32 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E18ED1065673 for ; Mon, 6 Dec 2010 17:04:32 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by mx1.freebsd.org (Postfix) with ESMTP id B76E38FC20 for ; Mon, 6 Dec 2010 17:04:32 +0000 (UTC) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id E0C0028F6FF; Mon, 6 Dec 2010 11:04:31 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh3.mail.rice.edu, auth channel Received: from mh3.mail.rice.edu ([127.0.0.1]) by mh3.mail.rice.edu (mh3.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id NiqJIphKCUBm; Mon, 6 Dec 2010 11:04:31 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id ACDC128F6F9; Mon, 6 Dec 2010 11:04:30 -0600 (CST) Message-ID: <4CFD179D.7000005@rice.edu> Date: Mon, 06 Dec 2010 11:04:29 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: "Jayachandran C." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 17:04:33 -0000 Jayachandran C. wrote: > Hi all, > > The attached patch uses the mechanism used to allocate page table > pages for UMA small allocations too. This will make sure that all the > small UMA allocations comes from KSEG0 pages in 32 bit and XKPHYS in > 64bit. > > This reduces TLB misses in kernel code significantly, and can give > major performance advantage for applications that spent a lot of time > in kernel. > > Please let me know your comments. > > It looks ok. My only suggested change is that you follow the precedent of amd64, ia64, and powerpc, and place uma_small_alloc() and uma_small_free() in a new file, mips/mips/uma_machdep.c. Alan From owner-freebsd-mips@FreeBSD.ORG Tue Dec 7 09:29:30 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5860D1065695; Tue, 7 Dec 2010 09:29:30 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AC7438FC12; Tue, 7 Dec 2010 09:29:29 +0000 (UTC) Received: by wwf26 with SMTP id 26so8906084wwf.31 for ; Tue, 07 Dec 2010 01:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YEBhov1fphH+efx6gc/Yc7/ac/Xh2U+WosPep+omtHA=; b=CJLzICYsNQItuOdGoKXjorH4j2O4qMyKZx6wH8ZcHkDnuVs6U7Wuq+HZOuXlhgJhW/ YSCT0VGUc0dk+iJf/QPvsQTlIHX43hInhBHjvyXnMvHeGoUyuZVaWeHLtzjXZ5RSxv8H dRA9ySmq4vpOuYXua0KgWIf/1m3B6qIhGkVKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hpaXJDZ4BOq+hwjP9WhhELAIpzoE2jwhG76vXc40PZgoUlbU02FgNpMRLDsOrMCLnS ZYRXFvgn5ITUtudwvEpt4e6OGD1PoXB2nKzfQad6jqv4TSfaLUQSLhAD0DrVIUqqq6CN ivFGlEXIprKtsy7QRFRYYGSUsTUNDEP+Hbtbs= MIME-Version: 1.0 Received: by 10.227.147.213 with SMTP id m21mr6928591wbv.131.1291714167280; Tue, 07 Dec 2010 01:29:27 -0800 (PST) Received: by 10.227.135.84 with HTTP; Tue, 7 Dec 2010 01:29:27 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Dec 2010 14:59:27 +0530 Message-ID: From: "Jayachandran C." To: Juli Mallett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , freebsd-mips@freebsd.org Subject: Re: uma_small_alloc from direct mapped memory. X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 09:29:30 -0000 On Mon, Dec 6, 2010 at 4:28 PM, Juli Mallett wrote: > On Mon, Dec 6, 2010 at 02:25, Jayachandran C. = wrote: >> I was planning to merge these changes. Now that the XLR platform code >> changes and 8-STABLE merge is done - I hope to get some time to do the >> rest of the n64 work. My rough todo list is : >> >> - 64bit PTEs which will give >4GB phys address, > > I'm very excited about that; on Octeon it will mean that we can > participate in the networking/messaging subsystem from userland, which > I know will be very valuable for a lot of applications. > >> - 32 bit compat in n64 (merge from /user/jmallett/octeon) > > You probably don't want to spend much time on those changes; they were > incomplete and focused on n32-on-n64. =A0I know n32-on-n64 would be > good, but is it your highest priority? =A0o32-on-n64 will be easy > because it's just like on other architectures. =A0o32-on-n32 and > n32-on-n64 require a complementary set of conditionals in the > freebsd32 code to handle (in the former case) pointer size being > unchanged and (in the latter case) register width being unchanged. =A0I > think we actually need to consider alternate compilation strategies > for the freebsd32 code, such as filling it with ifdefs and #including > the source files with different definitions so we can include o32 and > n32 compat together on n64 kernels. o32 on n64 is probably the most useful one, but I haven't looked at it in detail. I thought I would merge your code first and then understand what more is needed. >> - Complete merge from /user/jmallett/octeon - UIO, sf buf > > Great :) > >> - DDB/KDB fixes for n32/n64. > > For what it's worth, DDB seems mostly complete on n64 these days, save > for some issues in the trace code =97 I think we took the machdep ddb > code from NetBSD and now that they support n32 and n64 I think we may > just want to merge from them, no point duplicating that effort when > the code is so crufty, complex and massive already. > > Maybe talk to bde@ or freebsd-arch@ or freebsd-hackers@ about the DDB > changes required for n32 (and get someone to review the change to ufs > to not use register_t where it mean uintptr_t / vm_offset_t) =97 some of > the cleanups to be had there are good, but I think that there is some > resistance to changing DDB just for n32. =A0I think it's a good idea, > but I'm not sure e.g. whether it's better to adjust the DDB APIs that > pass addresses to use vm_offset_t or uintptr_t, or to keep them > passing register_t and to make code that takes addresses from > registers (or register_ts) more careful about how it converts them, > since probably other ABIs will come along where using an opaque > register type as something that can be converted directly to a pointer > is bad. =A0Perhaps what we really need are more debugger-specific types. > > Something that might be a worthwhile sell would be to continue to pass > register_t in those APIs and to introduce a call (that can fail) to > map a register_t to an address usable by the debugger, that way we can > also do clever things to avoid page faults within the debugger, in > addition to doing the necessary casts on n32. =A0That would benefit more > than just MIPS. There are fixes needed in n64 too. But as you said, to do n32 correctly would be a lot of trouble :) >> - 16K pagesize (there were some patches from SoC, but it crashed for me) > > Do you want to support both 4K and 16K pages on all MIPS ABIs, or just > n64, or make n64 always 16k and everything else always 4k? I was thinking of a config option. The executables are already aligned at 64K, so the userspace should not be a problem. Last time this was discussed, someone noted that there was issues in earlier FreeBSD versions for large page sizes. I have the 16K patch booting, but the userspace crashes a lot and I did not get enough time to debug that. JC. From owner-freebsd-mips@FreeBSD.ORG Wed Dec 8 15:47:27 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE04A1065670; Wed, 8 Dec 2010 15:47:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECA58FC22; Wed, 8 Dec 2010 15:47:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8FlPoK039455; Wed, 8 Dec 2010 10:47:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8FlPod039450; Wed, 8 Dec 2010 15:47:25 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 15:47:25 GMT Message-Id: <201012081547.oB8FlPod039450@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 15:47:27 -0000 TB --- 2010-12-08 15:22:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 15:22:40 - starting HEAD tinderbox run for mips/mips TB --- 2010-12-08 15:22:40 - cleaning the object tree TB --- 2010-12-08 15:22:47 - cvsupping the source tree TB --- 2010-12-08 15:22:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-12-08 15:22:58 - building world TB --- 2010-12-08 15:22:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 15:22:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 15:22:58 - TARGET=mips TB --- 2010-12-08 15:22:58 - TARGET_ARCH=mips TB --- 2010-12-08 15:22:58 - TZ=UTC TB --- 2010-12-08 15:22:58 - __MAKE_CONF=/dev/null TB --- 2010-12-08 15:22:58 - cd /src TB --- 2010-12-08 15:22:58 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 15:22:59 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 15:47:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 15:47:25 - ERROR: failed to build world TB --- 2010-12-08 15:47:25 - 1105.76 user 257.85 system 1485.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Wed Dec 8 17:04:43 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA96010656AC for ; Wed, 8 Dec 2010 17:04:43 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id 916888FC2D for ; Wed, 8 Dec 2010 17:04:43 +0000 (UTC) Received: by iwn9 with SMTP id 9so2040558iwn.19 for ; Wed, 08 Dec 2010 09:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=jItuGtHlxit/396OT3G3LjlEkiBBHhzqdqbrg3laGzc=; b=JJJ7FERjUPbWa16dHINWzkxkbnTUe4zB3fkgppApn9k0aorRCUr0GkmUIBGij1XG1D zTQyN2JoVZmq8Fs4qwdM5J+Ui2/hoWkhAnuRTHc3FhK/5neh0G4THNIftDbMFmaqrcPV IOSRwvfhLcKAp73bvy7sZsPMHWm+uprlXSqYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=grYSH5zqFiY1NXqixQIVnAJ5/ja8u4og9mTThJUa38HRqUO/ETaNRYFU8oCuJF8xIQ +ThY49s97KZVs+pTsAdfPg6jzWWVzTxo04V67M6l3xLTxiALIANGY7a6Bp1GZD2PE2jM efZA+27HVeNnl47G09zrNKLVheOBqruZmes6M= MIME-Version: 1.0 Received: by 10.231.36.5 with SMTP id r5mr2888707ibd.106.1291826040555; Wed, 08 Dec 2010 08:34:00 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.231.8.233 with HTTP; Wed, 8 Dec 2010 08:34:00 -0800 (PST) Date: Wed, 8 Dec 2010 17:34:00 +0100 X-Google-Sender-Auth: 5p0Llbkh-Q3eK4rCTNynTFRZKZE Message-ID: From: Robert Millan To: freebsd-mips@freebsd.org Content-Type: multipart/mixed; boundary=00248c6a57264247f90496e8b040 Subject: [PATCH] Retrieval of TLS pointer via RDHWR X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 17:04:44 -0000 --00248c6a57264247f90496e8b040 Content-Type: text/plain; charset=UTF-8 This patch implements support for retrieving the TLS pointer via RDHWR instruction. It is implemented through emulation for platforms that don't provide this instruction natively (such as gxemul/malta). Platforms that do provide it would need a separate patch. Reading register $29 with RDHWR is becoming the de-facto standard to implement TLS. According to linux-mips wiki, MIPS Technologies has reserved hardware register $29 for ABI use. Furthermore current GCC [1] makes the following assumptions: - RDHWR is natively available or otherwise emulated by the kernel - Register $29 holds the TLS pointer [1] gcc-4.4.4/gcc/config/mips/mips.md reads: ;; The TLS base pointer is accessed via "rdhwr $3, $29". No current ;; MIPS architecture defines this register, and no current ;; implementation provides it; instead, any OS which supports TLS is ;; expected to trap and emulate this instruction. rdhwr is part of the ;; MIPS 32r2 specification, but we use it on any architecture because ;; we expect it to be emulated. -- Robert Millan --00248c6a57264247f90496e8b040 Content-Type: text/x-patch; charset=US-ASCII; name="rdhwr.diff" Content-Disposition: attachment; filename="rdhwr.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ghgfuu2a0 SW5kZXg6IG1pcHMvaW5jbHVkZS9taXBzX29wY29kZS5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIG1pcHMvaW5j bHVkZS9taXBzX29wY29kZS5oCShyZXZpc2lvbiAyMTYyOTkpCisrKyBtaXBzL2luY2x1ZGUvbWlw c19vcGNvZGUuaAkod29ya2luZyBjb3B5KQpAQCAtMTc2LDYgKzE3NiwxMSBAQAogI2RlZmluZQlP UF9MREwJCTAzMgogI2RlZmluZQlPUF9MRFIJCTAzMwogCisjZGVmaW5lIE9QX1NQRUNJQUwyCTAz NAorI2RlZmluZSBPUF9KQUxYCQkwMzUKKworI2RlZmluZSBPUF9TUEVDSUFMMwkwMzcKKwogI2Rl ZmluZQlPUF9MQgkJMDQwCiAjZGVmaW5lCU9QX0xICQkwNDEKICNkZWZpbmUJT1BfTFdMCQkwNDIK QEAgLTM4OSw2ICszOTQsMTEgQEAKICNkZWZpbmUJT1BfUl9CR0VaQUxMCU9QX0JHRVpBTEwKIAog LyoKKyAqIFZhbHVlcyBmb3IgdGhlICdmdW5jJyBmaWVsZCB3aGVuICdvcCcgPT0gT1BfU1BFQ0lB TDMuCisgKi8KKyNkZWZpbmUJT1BfUkRIV1IJMDczCisKKy8qCiAgKiBWYWx1ZXMgZm9yIHRoZSAn cnMnIGZpZWxkIHdoZW4gJ29wJyA9PSBPUF9DT1B6LgogICovCiAjZGVmaW5lCU9QX01GCQkwMDAK SW5kZXg6IG1pcHMvbWlwcy90cmFwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbWlwcy9taXBzL3RyYXAuYwko cmV2aXNpb24gMjE2Mjk5KQorKysgbWlwcy9taXBzL3RyYXAuYwkod29ya2luZyBjb3B5KQpAQCAt ODI0LDkgKzgyNCwyNiBAQAogCQl9CiAKIAljYXNlIFRfUkVTX0lOU1QgKyBUX1VTRVI6Ci0JCWxv Z19pbGxlZ2FsX2luc3RydWN0aW9uKCJSRVNfSU5TVCIsIHRyYXBmcmFtZSk7Ci0JCWkgPSBTSUdJ TEw7Ci0JCWFkZHIgPSB0cmFwZnJhbWUtPnBjOworCQl7CisJCQlyZWdpc3Rlcl90IGluc3QgPSAq KChyZWdpc3Rlcl90ICopIHRyYXBmcmFtZS0+cGMpOworCQkJc3dpdGNoIChNSVBTX0lOU1RfT1BD T0RFKGluc3QpKSB7CisJCQljYXNlIE9QX1NQRUNJQUwzOgorCQkJCXN3aXRjaCAoTUlQU19JTlNU X0ZVTkMoaW5zdCkpIHsKKwkJCQljYXNlIE9QX1JESFdSOgorCQkJCQkvKiBSZWdpc3RlciAyOSB1 c2VkIGZvciBUTFMgKi8KKwkJCQkJaWYgKE1JUFNfSU5TVF9SRChpbnN0KSA9PSAyOSkgeworCQkJ CQkJKChyZWdpc3Rlcl90ICopIHRyYXBmcmFtZSlbTUlQU19JTlNUX1JUKGluc3QpXSA9IHRkLT50 ZF9tZC5tZF90bHM7CisJCQkJCQl0cmFwZnJhbWUtPnBjICs9IHNpemVvZihpbnQpOworCQkJCQkJ Z290byBvdXQ7CisJCQkJCX0KKwkJCQlicmVhazsKKwkJCQl9CisJCQlicmVhazsKKwkJCX0KKwkJ CWxvZ19pbGxlZ2FsX2luc3RydWN0aW9uKCJSRVNfSU5TVCIsIHRyYXBmcmFtZSk7CisJCQlpID0g U0lHSUxMOworCQkJYWRkciA9IHRyYXBmcmFtZS0+cGM7CisJCX0KIAkJYnJlYWs7CiAJY2FzZSBU X0MyRToKIAljYXNlIFRfQzJFICsgVF9VU0VSOgo= --00248c6a57264247f90496e8b040-- From owner-freebsd-mips@FreeBSD.ORG Wed Dec 8 17:07:03 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 425C1106566C; Wed, 8 Dec 2010 17:07:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DD80C8FC20; Wed, 8 Dec 2010 17:07:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id oB8H72ss000684; Wed, 8 Dec 2010 12:07:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id oB8H723M000675; Wed, 8 Dec 2010 17:07:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 8 Dec 2010 17:07:02 GMT Message-Id: <201012081707.oB8H723M000675@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 17:07:03 -0000 TB --- 2010-12-08 16:42:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-12-08 16:42:20 - starting HEAD tinderbox run for mips/mips TB --- 2010-12-08 16:42:20 - cleaning the object tree TB --- 2010-12-08 16:42:24 - cvsupping the source tree TB --- 2010-12-08 16:42:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-12-08 16:42:36 - building world TB --- 2010-12-08 16:42:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-12-08 16:42:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-12-08 16:42:36 - TARGET=mips TB --- 2010-12-08 16:42:36 - TARGET_ARCH=mips TB --- 2010-12-08 16:42:36 - TZ=UTC TB --- 2010-12-08 16:42:36 - __MAKE_CONF=/dev/null TB --- 2010-12-08 16:42:36 - cd /src TB --- 2010-12-08 16:42:36 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 8 16:42:36 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] rm -f .depend mkdep -f .depend -a -I/src/lib/libblocksruntime /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/data.c /src/lib/libblocksruntime/../../contrib/compiler-rt/BlocksRuntime/runtime.c ===> lib/libbluetooth (depend) rm -f .depend mkdep -f .depend -a -I/src/lib/libbluetooth -I/src/lib/libbluetooth/../../sys /src/lib/libbluetooth/bluetooth.c /src/lib/libbluetooth/dev.c /src/lib/libbluetooth/hci.c ===> lib/libbsnmp (depend) ===> lib/libbsnmp/libbsnmp (depend) make: don't know how to make snmpcrypto.c. Stop *** Error code 2 Stop in /src/lib/libbsnmp. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-12-08 17:07:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-12-08 17:07:02 - ERROR: failed to build world TB --- 2010-12-08 17:07:02 - 1105.76 user 255.27 system 1481.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Thu Dec 9 09:49:20 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73781065693 for ; Thu, 9 Dec 2010 09:49:20 +0000 (UTC) (envelope-from freebsd-mips@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 571358FC12 for ; Thu, 9 Dec 2010 09:49:19 +0000 (UTC) Received: from door.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Thu, 09 Dec 2010 10:48:57 +0100 id 00033C18.4D00A609.00012981 From: Milan Obuch To: freebsd-mips@freebsd.org Date: Thu, 9 Dec 2010 10:49:12 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.5.4; i386; ; ) References: <201012052310.37998.freebsd-mips@dino.sk> <4CFC1B01.4010009@bsdimp.com> In-Reply-To: <4CFC1B01.4010009@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012091049.14626.freebsd-mips@dino.sk> Cc: Subject: Re: xz in base system trouble on MIPS X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 09:49:20 -0000 On Monday 06 December 2010 00:06:41 Warner Losh wrote: > On 12/05/2010 15:10, Milan Obuch wrote: > > Hi, > > > > I am trying to test various system parts and ports building on my RSPRO. > > There is a problem with xz as compiled with base system - trying to > > build misc/mc gives 'unknown file format' error on > > /usr/ports/distfiles/mc-4.7.4.tar.lzma tarball. After commenting out > > IGNORE line in archive/xz Makefile, compilling, installing the port and > > 'cp /usr/local/bin/xz /usr/bin/xz' this error is gone. > > > > What could be root cause of this? As both base system and ports xz is > > version 5.0, I think there must be some error in base system integration > > or some tweaking is not done... > > I always guess endian problems on MIPS or big endian ARM when things > don't work quite right. But I don't see any errors there... I would expect something similar, too. I just asked if somebody encountered this error already so maybe an answer could be known... > First step: diff the sources? No difference found in souces (*.c, *.h), so maybe make infrastructure is different. I will try to compare build process if there are differences. > also, current or stable? current. Milan From owner-freebsd-mips@FreeBSD.ORG Thu Dec 9 11:16:10 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 511FA1065670 for ; Thu, 9 Dec 2010 11:16:10 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D803D8FC0A for ; Thu, 9 Dec 2010 11:16:09 +0000 (UTC) Received: by wwf26 with SMTP id 26so2177374wwf.31 for ; Thu, 09 Dec 2010 03:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kneTlAVMnVZHNAXDnYu9ubVQjybNMJi0w5pi/4ihPwE=; b=SnPFd6/bFtWKeBsVcfJKi0Rm6yAsX4G6uaAocUMc5pnzcvuvQbsb7FU9S0OU4O6+g3 ooWA6n04jPhxJ4Fzp90w7rtLrzUGs2eiTOOdINYWakRGcv2cAkY6c3LAqYC2X8j84LQt yQmNpWXktXIirZAufL65lqC/QX5fHCet0nbCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j4x+1wjRjpc7tVljgOQHnpgdtelxGeAgSuZJ1xIdpkRhNPQd4N7F2jUsgzHEZeVnqS 01+OZupKpcq9IxglsfOKYDzMR7FO5g9YuaA7qtjNrJkHpqPDNPNxXfboq5JBPJGO1eJt 6HIjUfyQGSB69zxKb22m5eqJ/DpciXtrrydpw= MIME-Version: 1.0 Received: by 10.227.144.12 with SMTP id x12mr10189490wbu.218.1291893368472; Thu, 09 Dec 2010 03:16:08 -0800 (PST) Sender: c.jayachandran@gmail.com Received: by 10.227.135.84 with HTTP; Thu, 9 Dec 2010 03:16:08 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Dec 2010 16:46:08 +0530 X-Google-Sender-Auth: TloKCiY_l5YGAuZ4HgthHpbIhZQ Message-ID: From: "Jayachandran C." To: Robert Millan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: [PATCH] Retrieval of TLS pointer via RDHWR X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 11:16:10 -0000 On Wed, Dec 8, 2010 at 10:04 PM, Robert Millan wrote: > This patch implements support for retrieving the TLS pointer via RDHWR > instruction. > > It is implemented through emulation for platforms that don't provide > this instruction natively (such as gxemul/malta). =A0Platforms that do > provide it would need a separate patch. > > Reading register $29 with RDHWR is becoming the de-facto standard to > implement TLS. =A0According to linux-mips wiki, MIPS Technologies has > reserved hardware register $29 for ABI use. =A0Furthermore current GCC [1= ] > makes the following assumptions: > - RDHWR is natively available or otherwise emulated by the kernel > - Register $29 holds the TLS pointer > > [1] gcc-4.4.4/gcc/config/mips/mips.md reads: > > ;; The TLS base pointer is accessed via "rdhwr $3, $29". =A0No current > ;; MIPS architecture defines this register, and no current > ;; implementation provides it; instead, any OS which supports TLS is > ;; expected to trap and emulate this instruction. =A0rdhwr is part of the > ;; MIPS 32r2 specification, but we use it on any architecture because > ;; we expect it to be emulated. I'm not sure that the freebsd mips toolchain supports the __thread directive yet. Were you able to test this from C? Regards, JC From owner-freebsd-mips@FreeBSD.ORG Thu Dec 9 12:06:41 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 903E21065679 for ; Thu, 9 Dec 2010 12:06:41 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5524E8FC18 for ; Thu, 9 Dec 2010 12:06:41 +0000 (UTC) Received: by iwn9 with SMTP id 9so3633673iwn.19 for ; Thu, 09 Dec 2010 04:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FMYdtexjV9QGDoczu4OnCUOdLFELls7uvyyO/+AXCko=; b=huWUSxHsF48RVVFfY108LIBt75q6CgJNXbzafjERxoXVJrWaSIPG/KK96W8/mCgBpC 4Grsbc1HshnEFZW+5HzpLUHYv0bJQAWYx0InKh/trSGB7itm9jOKtV7SeWZzWYWCX5kE jl4NJS+jQHy9KS10I/OADTi4rZtTxXiiCQyKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rTldz+xO/UcAanM5oaKK5xLlqrAIvm5Hr/FTuQQNe51u/rVoZlY8GIF909BYFEtPCE dtI+mFFjCoZJIwlyxivkUkNaq+E4Ofd9lZr43ZmaN9M4IZyoAczZCDh2PC3jh2ABjz4D a7jauJGpQyrGVAeA7ZTNzbOAHEQFlVzvC/rIs= MIME-Version: 1.0 Received: by 10.231.35.71 with SMTP id o7mr247994ibd.156.1291896400599; Thu, 09 Dec 2010 04:06:40 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.231.8.233 with HTTP; Thu, 9 Dec 2010 04:06:40 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Dec 2010 13:06:40 +0100 X-Google-Sender-Auth: fc1GogP5YGsTO0-YqOLUNSPVb8M Message-ID: From: Robert Millan To: "Jayachandran C." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: [PATCH] Retrieval of TLS pointer via RDHWR X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 12:06:41 -0000 2010/12/9 Jayachandran C. : > I'm not sure that the freebsd mips toolchain supports the __thread > directive yet. =C2=A0Were you able to test this from C? Yes, but not via __thread. I wrote a small program that sets the TLS pointer to an arbitrary value (via MIPS_SET_TLS), then issued rdhwr instruction using C inline assembly, and finally verified that both values are the same. (the toolchain I'm using doesn't support __thread either, but I submit this patch with the expectation that it can be useful later on) --=20 Robert Millan