From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 01:25:05 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DEB2736; Mon, 29 Sep 2014 01:25:05 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BB45186; Mon, 29 Sep 2014 01:25:05 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s8T0upVF006623; Sun, 28 Sep 2014 20:00:45 -0500 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp2.rice.edu with ESMTP id 1pp1a4rajp-1; Sun, 28 Sep 2014 20:00:44 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (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 D5001403E3; Sun, 28 Sep 2014 20:00:43 -0500 (CDT) Message-ID: <5428AF3B.1030906@rice.edu> Date: Sun, 28 Sep 2014 20:00:43 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Svatopluk Kraus , alc@freebsd.org Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------030707070306010907080705" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.0213074882763902 suspectscore=11 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=498 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409290009 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:25:05 -0000 This is a multi-part message in MIME format. --------------030707070306010907080705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09/27/2014 03:51, Svatopluk Kraus wrote: > > On Fri, Sep 26, 2014 at 8:08 PM, Alan Cox > wrote: > > > > On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus > wrote: > > Hi, > > I and Michal are finishing new ARM pmap-v6 code. There is one > problem we've > dealt with somehow, but now we would like to do it better. > It's about > physical pages which are allocated before vm subsystem is > initialized. > While later on these pages could be found in vm_page_array when > VM_PHYSSEG_DENSE memory model is used, it's not true for > VM_PHYSSEG_SPARSE > memory model. And ARM world uses VM_PHYSSEG_SPARSE model. > > It really would be nice to utilize vm_page_array for such > preallocated > physical pages even when VM_PHYSSEG_SPARSE memory model is > used. Things > could be much easier then. In our case, it's about pages which > are used for > level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two > sets of such > pages. First ones are preallocated and second ones are > allocated after vm > subsystem was inited. We must deal with each set differently. > So code is > more complex and so is debugging. > > Thus we need some method how to say that some part of physical > memory > should be included in vm_page_array, but the pages from that > region should > not be put to free list during initialization. We think that such > possibility could be utilized in general. There could be a > need for some > physical space which: > > (1) is needed only during boot and later on it can be freed > and put to vm > subsystem, > > (2) is needed for something else and vm_page_array code could > be used > without some kind of its duplication. > > There is already some code which deals with blacklisted pages > in vm_page.c > file. So the easiest way how to deal with presented situation > is to add > some callback to this part of code which will be able to > either exclude > whole phys_avail[i], phys_avail[i+1] region or single pages. > As the biggest > phys_avail region is used for vm subsystem allocations, there > should be > some more coding. (However, blacklisted pages are not dealt > with on that > part of region.) > > We would like to know if there is any objection: > > (1) to deal with presented problem, > (2) to deal with the problem presented way. > Some help is very appreciated. Thanks > > > > As an experiment, try modifying vm_phys.c to use dump_avail > instead of phys_avail when sizing vm_page_array. On amd64, where > the same problem exists, this allowed me to use > VM_PHYSSEG_SPARSE. Right now, this is probably my preferred > solution. The catch being that not all architectures implement > dump_avail, but my recollection is that arm does. > > > Frankly, I would prefer this too, but there is one big open question: > > What is dump_avail for? dump_avail[] is solving a similar problem in the minidump code, hence, the prefix "dump_" in its name. In other words, the minidump code couldn't use phys_avail[] either because it didn't describe the full range of physical addresses that might be included in a minidump, so dump_avail[] was created. There is already precedent for what I'm suggesting. dump_avail[] is already (ab)used outside of the minidump code on x86 to solve this same problem in x86/x86/nexus.c, and on arm in arm/arm/mem.c. > Using it for vm_page_array initialization and segmentation means that > phys_avail must be a subset of it. And this must be stated and be > visible enough. Maybe it should be even checked in code. I like the > idea of thinking about dump_avail as something what desribes all > memory in a system, but it's not how dump_avail is defined in archs now. When you say "it's not how dump_avail is defined in archs now", I'm not sure whether you're talking about the code or the comments. In terms of code, dump_avail[] is a superset of phys_avail[], and I'm not aware of any code that would have to change. In terms of comments, I did a grep looking for comments defining what dump_avail[] is, because I couldn't remember any. I found one ... on arm. So, I don't think it's a onerous task changing the definition of dump_avail[]. :-) Already, as things stand today with dump_avail[] being used outside of the minidump code, one could reasonably argue that it should be renamed to something like phys_exists[]. > > I will experiment with it on monday then. However, it's not only about > how memory segments are created in vm_phys.c, but it's about how > vm_page_array size is computed in vm_page.c too. Yes, and there is also a place in vm_reserv.c that needs to change. I've attached the patch that I developed and tested a long time ago. It still applies cleanly and runs ok on amd64. --------------030707070306010907080705 Content-Type: text/plain; charset=ISO-8859-15; name="dump_avail_sparse.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dump_avail_sparse.patch" SW5kZXg6IHZtL3ZtX3BoeXMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB2bS92bV9waHlzLmMJKHJl dmlzaW9uIDIyMDEwMikKKysrIHZtL3ZtX3BoeXMuYwkod29ya2luZyBjb3B5KQpAQCAtMjg5 LDM4ICsyODksMzggQEAgdm1fcGh5c19pbml0KHZvaWQpCiAJaW50IG5kb21haW5zLCBqOwog I2VuZGlmCiAKLQlmb3IgKGkgPSAwOyBwaHlzX2F2YWlsW2kgKyAxXSAhPSAwOyBpICs9IDIp IHsKKwlmb3IgKGkgPSAwOyBkdW1wX2F2YWlsW2kgKyAxXSAhPSAwOyBpICs9IDIpIHsKICNp ZmRlZglWTV9GUkVFTElTVF9JU0FETUEKLQkJaWYgKHBoeXNfYXZhaWxbaV0gPCAxNjc3NzIx NikgewotCQkJaWYgKHBoeXNfYXZhaWxbaSArIDFdID4gMTY3NzcyMTYpIHsKLQkJCQl2bV9w aHlzX2NyZWF0ZV9zZWcocGh5c19hdmFpbFtpXSwgMTY3NzcyMTYsCisJCWlmIChkdW1wX2F2 YWlsW2ldIDwgMTY3NzcyMTYpIHsKKwkJCWlmIChkdW1wX2F2YWlsW2kgKyAxXSA+IDE2Nzc3 MjE2KSB7CisJCQkJdm1fcGh5c19jcmVhdGVfc2VnKGR1bXBfYXZhaWxbaV0sIDE2Nzc3MjE2 LAogCQkJCSAgICBWTV9GUkVFTElTVF9JU0FETUEpOwotCQkJCXZtX3BoeXNfY3JlYXRlX3Nl ZygxNjc3NzIxNiwgcGh5c19hdmFpbFtpICsgMV0sCisJCQkJdm1fcGh5c19jcmVhdGVfc2Vn KDE2Nzc3MjE2LCBkdW1wX2F2YWlsW2kgKyAxXSwKIAkJCQkgICAgVk1fRlJFRUxJU1RfREVG QVVMVCk7CiAJCQl9IGVsc2UgewotCQkJCXZtX3BoeXNfY3JlYXRlX3NlZyhwaHlzX2F2YWls W2ldLAotCQkJCSAgICBwaHlzX2F2YWlsW2kgKyAxXSwgVk1fRlJFRUxJU1RfSVNBRE1BKTsK KwkJCQl2bV9waHlzX2NyZWF0ZV9zZWcoZHVtcF9hdmFpbFtpXSwKKwkJCQkgICAgZHVtcF9h dmFpbFtpICsgMV0sIFZNX0ZSRUVMSVNUX0lTQURNQSk7CiAJCQl9CiAJCQlpZiAoVk1fRlJF RUxJU1RfSVNBRE1BID49IHZtX25mcmVlbGlzdHMpCiAJCQkJdm1fbmZyZWVsaXN0cyA9IFZN X0ZSRUVMSVNUX0lTQURNQSArIDE7CiAJCX0gZWxzZQogI2VuZGlmCiAjaWZkZWYJVk1fRlJF RUxJU1RfSElHSE1FTQotCQlpZiAocGh5c19hdmFpbFtpICsgMV0gPiBWTV9ISUdITUVNX0FE RFJFU1MpIHsKLQkJCWlmIChwaHlzX2F2YWlsW2ldIDwgVk1fSElHSE1FTV9BRERSRVNTKSB7 Ci0JCQkJdm1fcGh5c19jcmVhdGVfc2VnKHBoeXNfYXZhaWxbaV0sCisJCWlmIChkdW1wX2F2 YWlsW2kgKyAxXSA+IFZNX0hJR0hNRU1fQUREUkVTUykgeworCQkJaWYgKGR1bXBfYXZhaWxb aV0gPCBWTV9ISUdITUVNX0FERFJFU1MpIHsKKwkJCQl2bV9waHlzX2NyZWF0ZV9zZWcoZHVt cF9hdmFpbFtpXSwKIAkJCQkgICAgVk1fSElHSE1FTV9BRERSRVNTLCBWTV9GUkVFTElTVF9E RUZBVUxUKTsKIAkJCQl2bV9waHlzX2NyZWF0ZV9zZWcoVk1fSElHSE1FTV9BRERSRVNTLAot CQkJCSAgICBwaHlzX2F2YWlsW2kgKyAxXSwgVk1fRlJFRUxJU1RfSElHSE1FTSk7CisJCQkJ ICAgIGR1bXBfYXZhaWxbaSArIDFdLCBWTV9GUkVFTElTVF9ISUdITUVNKTsKIAkJCX0gZWxz ZSB7Ci0JCQkJdm1fcGh5c19jcmVhdGVfc2VnKHBoeXNfYXZhaWxbaV0sCi0JCQkJICAgIHBo eXNfYXZhaWxbaSArIDFdLCBWTV9GUkVFTElTVF9ISUdITUVNKTsKKwkJCQl2bV9waHlzX2Ny ZWF0ZV9zZWcoZHVtcF9hdmFpbFtpXSwKKwkJCQkgICAgZHVtcF9hdmFpbFtpICsgMV0sIFZN X0ZSRUVMSVNUX0hJR0hNRU0pOwogCQkJfQogCQkJaWYgKFZNX0ZSRUVMSVNUX0hJR0hNRU0g Pj0gdm1fbmZyZWVsaXN0cykKIAkJCQl2bV9uZnJlZWxpc3RzID0gVk1fRlJFRUxJU1RfSElH SE1FTSArIDE7CiAJCX0gZWxzZQogI2VuZGlmCi0JCXZtX3BoeXNfY3JlYXRlX3NlZyhwaHlz X2F2YWlsW2ldLCBwaHlzX2F2YWlsW2kgKyAxXSwKKwkJdm1fcGh5c19jcmVhdGVfc2VnKGR1 bXBfYXZhaWxbaV0sIGR1bXBfYXZhaWxbaSArIDFdLAogCQkgICAgVk1fRlJFRUxJU1RfREVG QVVMVCk7CiAJfQogCWZvciAoZmxpbmQgPSAwOyBmbGluZCA8IHZtX25mcmVlbGlzdHM7IGZs aW5kKyspIHsKSW5kZXg6IHZtL3ZtX3Jlc2Vydi5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHZtL3Zt X3Jlc2Vydi5jCShyZXZpc2lvbiAyMjAxMDIpCisrKyB2bS92bV9yZXNlcnYuYwkod29ya2lu ZyBjb3B5KQpAQCAtNDg3LDkgKzQ4Nyw5IEBAIHZtX3Jlc2Vydl9pbml0KHZvaWQpCiAJICog SW5pdGlhbGl6ZSB0aGUgcmVzZXJ2YXRpb24gYXJyYXkuICBTcGVjaWZpY2FsbHksIGluaXRp YWxpemUgdGhlCiAJICogInBhZ2VzIiBmaWVsZCBmb3IgZXZlcnkgZWxlbWVudCB0aGF0IGhh cyBhbiB1bmRlcmx5aW5nIHN1cGVycGFnZS4KIAkgKi8KLQlmb3IgKGkgPSAwOyBwaHlzX2F2 YWlsW2kgKyAxXSAhPSAwOyBpICs9IDIpIHsKLQkJcGFkZHIgPSByb3VuZHVwMihwaHlzX2F2 YWlsW2ldLCBWTV9MRVZFTF8wX1NJWkUpOwotCQl3aGlsZSAocGFkZHIgKyBWTV9MRVZFTF8w X1NJWkUgPD0gcGh5c19hdmFpbFtpICsgMV0pIHsKKwlmb3IgKGkgPSAwOyBkdW1wX2F2YWls W2kgKyAxXSAhPSAwOyBpICs9IDIpIHsKKwkJcGFkZHIgPSByb3VuZHVwMihkdW1wX2F2YWls W2ldLCBWTV9MRVZFTF8wX1NJWkUpOworCQl3aGlsZSAocGFkZHIgKyBWTV9MRVZFTF8wX1NJ WkUgPD0gZHVtcF9hdmFpbFtpICsgMV0pIHsKIAkJCXZtX3Jlc2Vydl9hcnJheVtwYWRkciA+ PiBWTV9MRVZFTF8wX1NISUZUXS5wYWdlcyA9CiAJCQkgICAgUEhZU19UT19WTV9QQUdFKHBh ZGRyKTsKIAkJCXBhZGRyICs9IFZNX0xFVkVMXzBfU0laRTsKSW5kZXg6IHZtL3ZtX3BhZ2Uu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB2bS92bV9wYWdlLmMJKHJldmlzaW9uIDIyMDEwMikKKysr IHZtL3ZtX3BhZ2UuYwkod29ya2luZyBjb3B5KQpAQCAtMzg5LDggKzM4OSw4IEBAIHZtX3Bh Z2Vfc3RhcnR1cCh2bV9vZmZzZXRfdCB2YWRkcikKIAlmaXJzdF9wYWdlID0gbG93X3dhdGVy IC8gUEFHRV9TSVpFOwogI2lmZGVmIFZNX1BIWVNTRUdfU1BBUlNFCiAJcGFnZV9yYW5nZSA9 IDA7Ci0JZm9yIChpID0gMDsgcGh5c19hdmFpbFtpICsgMV0gIT0gMDsgaSArPSAyKQotCQlw YWdlX3JhbmdlICs9IGF0b3AocGh5c19hdmFpbFtpICsgMV0gLSBwaHlzX2F2YWlsW2ldKTsK Kwlmb3IgKGkgPSAwOyBkdW1wX2F2YWlsW2kgKyAxXSAhPSAwOyBpICs9IDIpCisJCXBhZ2Vf cmFuZ2UgKz0gYXRvcChkdW1wX2F2YWlsW2kgKyAxXSAtIGR1bXBfYXZhaWxbaV0pOwogI2Vs aWYgZGVmaW5lZChWTV9QSFlTU0VHX0RFTlNFKQogCXBhZ2VfcmFuZ2UgPSBoaWdoX3dhdGVy IC8gUEFHRV9TSVpFIC0gZmlyc3RfcGFnZTsKICNlbHNlCkluZGV4OiBhbWQ2NC9pbmNsdWRl L3ZtcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBhbWQ2NC9pbmNsdWRlL3ZtcGFyYW0uaAko cmV2aXNpb24gMjIwMTAyKQorKysgYW1kNjQvaW5jbHVkZS92bXBhcmFtLmgJKHdvcmtpbmcg Y29weSkKQEAgLTc5LDcgKzc5LDcgQEAKIC8qCiAgKiBUaGUgcGh5c2ljYWwgYWRkcmVzcyBz cGFjZSBpcyBkZW5zZWx5IHBvcHVsYXRlZC4KICAqLwotI2RlZmluZQlWTV9QSFlTU0VHX0RF TlNFCisjZGVmaW5lCVZNX1BIWVNTRUdfU1BBUlNFCiAKIC8qCiAgKiBUaGUgbnVtYmVyIG9m IFBIWVNTRUcgZW50cmllcyBtdXN0IGJlIG9uZSBncmVhdGVyIHRoYW4gdGhlIG51bWJlcgo= --------------030707070306010907080705-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 11:37:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E638C9C8; Mon, 29 Sep 2014 11:37:25 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 389E7B9B; Mon, 29 Sep 2014 11:37:25 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id n3so1722472wiv.2 for ; Mon, 29 Sep 2014 04:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lM0BDC2+GpvT7C9YleJYlAYW7vROAFq4v4hsD83YTqs=; b=IBRWNwz84l/ClR4TXoNrUWIBF97zD0V/k2gI3cVk3VtToyCuIoGYFcQCkyUMDIteJx sbB1tq13eneAH0M17Da53HPYiVOaFsY1AStxRtrjmXlWJfh6mMLQj0BxV88EowtVdmz7 hbbdQNVrYsXSmwb0VZszshXLWDebkfE79Xbt713lPqGwL0v0N6JwuKmrzfLjIaEw4g0Z eoBNBve0ooRokRp6Cte3Xn6APMWaaO3KexyLX8eRRRjH+AsXGzJ59fUnVF55/Zzj69Mw k5Frv+gtsLxh8L1SOdfmEdHL/QsZRuW9oQ3mvc4KRzqsYopsxIfHj4Sic47U6PbpF6xP eGLQ== MIME-Version: 1.0 X-Received: by 10.194.185.14 with SMTP id ey14mr10704544wjc.91.1411990643331; Mon, 29 Sep 2014 04:37:23 -0700 (PDT) Received: by 10.216.141.6 with HTTP; Mon, 29 Sep 2014 04:37:23 -0700 (PDT) In-Reply-To: References: <20140711232914.GH41807@pwnie.vrt.sourcefire.com> Date: Mon, 29 Sep 2014 14:37:23 +0300 Message-ID: Subject: Re: [RFC] ASLR Whitepaper and Candidate Final Patch From: Shawn Webb To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: PaX Team , Bryan Drewery , Alan Cox , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Oliver Pinter X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 11:37:26 -0000 Hey everybody, I've uploaded a new patch to Phabricator. A lot has changed in the month that has passed. ARM is now fixed 100% thanks to Ilya Bakulin! We're looking for people who want to test it out as well as people who can do performance tests. Building world and kernel and/or a poudriere bulk run is a good real-world performance benchmark. Thanks, Shawn On Mon, Aug 18, 2014 at 11:44 PM, Shawn Webb wrote: > I've uploaded a new patch to Phabric: https://reviews.freebsd.org/D473. > I'm interested in hearing feedback from the community. > > > On Fri, Jul 11, 2014 at 7:29 PM, Shawn Webb wrote: > >> Hey All, >> >> Oliver Pinter and I have been working hard on our ASLR implementation. >> We're now in the final stages of development and would like to get >> feedback from the community. I've attached to this email a small >> whitepaper that details our implementation and the accompanying patch. >> >> There is one part of the patch that I wrote that is quite an ugly hack >> and would like to get some feedback on. I added a little hack to >> sys_mmap() to apply ASLR to calls to mmap(2) when MAP_32BIT is >> specified. I'd like to remove that ugly hack to something a bit more >> beautiful, so if anyone has any suggestions, I'm all ears. >> >> Other than that ugly hack, the code adheres to FreeBSD's style(9) >> standards. I believe we have an awesome implementation, one I've >> personally been using without issue for months. >> >> I'm looking forward to your comments and questions. I've CC'd the PaX >> team. Please keep them CC'd in your replies. >> >> Thank you very much, >> >> Shawn Webb >> CC: PaX Team >> CC: Oliver Pinter >> CC: des@freebsd.org >> CC: alc@rice.edu >> CC: bdrewery@freebsd.org >> >> PS - Sorry for the duplicate emails. I hit the wrong key and didn't CC >> everyone. >> > > From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 15:51:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DF679B5; Mon, 29 Sep 2014 15:51:34 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBEC1D69; Mon, 29 Sep 2014 15:51:33 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id r5so8942680qcx.14 for ; Mon, 29 Sep 2014 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X+aRJKon7p8YETci/bYYaaAzqvpqNFlbjQOp69HhGDs=; b=gJ5N3REr3NqBpyecVsmQie9SkMXSGVZpk5YTJRTVN8Jufnnd7ZMG+7Flf5ryhxAmbo 3n1kY9WAp7jmmBlJgH2Fhw7tiHwq20qncVgeSS76Fq8uKxLm9DVlsptnJT+Lyu3nendn r4AjdZZIzq1OMjU2vEsmzPDBRps6OZphfi1GBlx4NZ9xtSDsSaZGKkxzw46WzsTlOjjT vMmtUZiY5tEpJx+0m5Z/RDKWOZsqS0AX2yLdZTx7uT6un26fZliAdw6nJGY/rPilVgRS e+dP8FUv/rUoaXh5paMJ/TMaK4DwgsoGpMROfr8KmH4ypZAyuqk67OglVhPCBK+UPwVo fhng== MIME-Version: 1.0 X-Received: by 10.224.46.6 with SMTP id h6mr53590476qaf.45.1412005892861; Mon, 29 Sep 2014 08:51:32 -0700 (PDT) Received: by 10.140.23.242 with HTTP; Mon, 29 Sep 2014 08:51:32 -0700 (PDT) In-Reply-To: <5428AF3B.1030906@rice.edu> References: <5428AF3B.1030906@rice.edu> Date: Mon, 29 Sep 2014 17:51:32 +0200 Message-ID: Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Svatopluk Kraus To: Alan Cox Content-Type: multipart/mixed; boundary=001a11c35a9caa54240504363d05 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: alc@freebsd.org, FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:51:34 -0000 --001a11c35a9caa54240504363d05 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 29, 2014 at 3:00 AM, Alan Cox wrote: > On 09/27/2014 03:51, Svatopluk Kraus wrote: > > > On Fri, Sep 26, 2014 at 8:08 PM, Alan Cox wrote: > >> >> >> On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus >> wrote: >> >>> Hi, >>> >>> I and Michal are finishing new ARM pmap-v6 code. There is one problem >>> we've >>> dealt with somehow, but now we would like to do it better. It's about >>> physical pages which are allocated before vm subsystem is initialized. >>> While later on these pages could be found in vm_page_array when >>> VM_PHYSSEG_DENSE memory model is used, it's not true for >>> VM_PHYSSEG_SPARSE >>> memory model. And ARM world uses VM_PHYSSEG_SPARSE model. >>> >>> It really would be nice to utilize vm_page_array for such preallocated >>> physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things >>> could be much easier then. In our case, it's about pages which are used >>> for >>> level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such >>> pages. First ones are preallocated and second ones are allocated after vm >>> subsystem was inited. We must deal with each set differently. So code is >>> more complex and so is debugging. >>> >>> Thus we need some method how to say that some part of physical memory >>> should be included in vm_page_array, but the pages from that region >>> should >>> not be put to free list during initialization. We think that such >>> possibility could be utilized in general. There could be a need for some >>> physical space which: >>> >>> (1) is needed only during boot and later on it can be freed and put to vm >>> subsystem, >>> >>> (2) is needed for something else and vm_page_array code could be used >>> without some kind of its duplication. >>> >>> There is already some code which deals with blacklisted pages in >>> vm_page.c >>> file. So the easiest way how to deal with presented situation is to add >>> some callback to this part of code which will be able to either exclude >>> whole phys_avail[i], phys_avail[i+1] region or single pages. As the >>> biggest >>> phys_avail region is used for vm subsystem allocations, there should be >>> some more coding. (However, blacklisted pages are not dealt with on that >>> part of region.) >>> >>> We would like to know if there is any objection: >>> >>> (1) to deal with presented problem, >>> (2) to deal with the problem presented way. >>> Some help is very appreciated. Thanks >>> >>> >> >> As an experiment, try modifying vm_phys.c to use dump_avail instead of >> phys_avail when sizing vm_page_array. On amd64, where the same problem >> exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is >> probably my preferred solution. The catch being that not all architectures >> implement dump_avail, but my recollection is that arm does. >> > > Frankly, I would prefer this too, but there is one big open question: > > What is dump_avail for? > > > > dump_avail[] is solving a similar problem in the minidump code, hence, the > prefix "dump_" in its name. In other words, the minidump code couldn't use > phys_avail[] either because it didn't describe the full range of physical > addresses that might be included in a minidump, so dump_avail[] was created. > > There is already precedent for what I'm suggesting. dump_avail[] is > already (ab)used outside of the minidump code on x86 to solve this same > problem in x86/x86/nexus.c, and on arm in arm/arm/mem.c. > > > Using it for vm_page_array initialization and segmentation means that > phys_avail must be a subset of it. And this must be stated and be visible > enough. Maybe it should be even checked in code. I like the idea of > thinking about dump_avail as something what desribes all memory in a > system, but it's not how dump_avail is defined in archs now. > > > > When you say "it's not how dump_avail is defined in archs now", I'm not > sure whether you're talking about the code or the comments. In terms of > code, dump_avail[] is a superset of phys_avail[], and I'm not aware of any > code that would have to change. In terms of comments, I did a grep looking > for comments defining what dump_avail[] is, because I couldn't remember > any. I found one ... on arm. So, I don't think it's a onerous task > changing the definition of dump_avail[]. :-) > > Already, as things stand today with dump_avail[] being used outside of the > minidump code, one could reasonably argue that it should be renamed to > something like phys_exists[]. > > > > I will experiment with it on monday then. However, it's not only about how > memory segments are created in vm_phys.c, but it's about how vm_page_array > size is computed in vm_page.c too. > > > > Yes, and there is also a place in vm_reserv.c that needs to change. I've > attached the patch that I developed and tested a long time ago. It still > applies cleanly and runs ok on amd64. > > I took your patch and added some changes to vm_page.c to make - IMHO - things more consistent across dense and sparse cases. It runs ok on arm (odroid-xu). New patch is attached. I've investigated dump_avail and phys_avail in other archs. In mips, dump_avail is equal to phys_avail, so it should run with no difference there. However, sys\mips\atheros\ar71xx_machdep.c should be fixed probably. There is no dump_avail definition in sparc64 and powerpc. There, dump_avail could be defined same way like in mips. So, it should run with no problem too. The involved files are: sys\powerpc\aim\mmu_oea.c sys\powerpc\aim\mmu_oea64.c sys\powerpc\booke\pmap.c sys\sparc64\sparc64\pmap.c There are some files where I can imagine that phys_avail could be replaced by dump_avail as a matter of purity. sys\arm\arm\busdma_machdep.c sys\mips\mips\busdma_machdep.c sys\arm\arm\busdma_machdep-v6.c sys\sparc64\sparc64\mem.c sys\mips\mips\minidump_machdep.c I agree that dump_avail should be renamed if this change happen. I'm prepared to work on full patch. Svata --001a11c35a9caa54240504363d05 Content-Type: application/octet-stream; name="vm_page_array.path" Content-Disposition: attachment; filename="vm_page_array.path" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i0nyk4771 SW5kZXg6IHN5cy92bS92bV9wYWdlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX3BhZ2UuYwko cmV2aXNpb24gMjcyMjgxKQorKysgc3lzL3ZtL3ZtX3BhZ2UuYwkod29ya2luZyBjb3B5KQpAQCAt MzAxLDMxICszMDEsMzggQEAKIAliaWdnZXN0b25lID0gMDsKIAl2YWRkciA9IHJvdW5kX3BhZ2Uo dmFkZHIpOwogCi0JZm9yIChpID0gMDsgcGh5c19hdmFpbFtpICsgMV07IGkgKz0gMikgewotCQlw aHlzX2F2YWlsW2ldID0gcm91bmRfcGFnZShwaHlzX2F2YWlsW2ldKTsKLQkJcGh5c19hdmFpbFtp ICsgMV0gPSB0cnVuY19wYWdlKHBoeXNfYXZhaWxbaSArIDFdKTsKKwlmb3IgKGkgPSAwOyBkdW1w X2F2YWlsW2kgKyAxXTsgaSArPSAyKSB7CisJCWR1bXBfYXZhaWxbaV0gPSByb3VuZF9wYWdlKGR1 bXBfYXZhaWxbaV0pOworCQlkdW1wX2F2YWlsW2kgKyAxXSA9IHRydW5jX3BhZ2UoZHVtcF9hdmFp bFtpICsgMV0pOwogCX0KIAotCWxvd193YXRlciA9IHBoeXNfYXZhaWxbMF07Ci0JaGlnaF93YXRl ciA9IHBoeXNfYXZhaWxbMV07CisJbG93X3dhdGVyID0gZHVtcF9hdmFpbFswXTsKKwloaWdoX3dh dGVyID0gZHVtcF9hdmFpbFsxXTsKIAorCWZvciAoaSA9IDA7IGR1bXBfYXZhaWxbaSArIDFdOyBp ICs9IDIpIHsKKwkJaWYgKGR1bXBfYXZhaWxbaV0gPCBsb3dfd2F0ZXIpCisJCQlsb3dfd2F0ZXIg PSBkdW1wX2F2YWlsW2ldOworCQlpZiAoZHVtcF9hdmFpbFtpICsgMV0gPiBoaWdoX3dhdGVyKQor CQkJaGlnaF93YXRlciA9IGR1bXBfYXZhaWxbaSArIDFdOworCX0KKworI2lmZGVmIFhFTgorCWxv d193YXRlciA9IDA7CisjZW5kaWYKKwogCWZvciAoaSA9IDA7IHBoeXNfYXZhaWxbaSArIDFdOyBp ICs9IDIpIHsKLQkJdm1fcGFkZHJfdCBzaXplID0gcGh5c19hdmFpbFtpICsgMV0gLSBwaHlzX2F2 YWlsW2ldOworCQl2bV9wYWRkcl90IHNpemU7CiAKKwkJcGh5c19hdmFpbFtpXSA9IHJvdW5kX3Bh Z2UocGh5c19hdmFpbFtpXSk7CisJCXBoeXNfYXZhaWxbaSArIDFdID0gdHJ1bmNfcGFnZShwaHlz X2F2YWlsW2kgKyAxXSk7CisKKwkJc2l6ZSA9IHBoeXNfYXZhaWxbaSArIDFdIC0gcGh5c19hdmFp bFtpXTsKIAkJaWYgKHNpemUgPiBiaWdnZXN0c2l6ZSkgewogCQkJYmlnZ2VzdG9uZSA9IGk7CiAJ CQliaWdnZXN0c2l6ZSA9IHNpemU7CiAJCX0KLQkJaWYgKHBoeXNfYXZhaWxbaV0gPCBsb3dfd2F0 ZXIpCi0JCQlsb3dfd2F0ZXIgPSBwaHlzX2F2YWlsW2ldOwotCQlpZiAocGh5c19hdmFpbFtpICsg MV0gPiBoaWdoX3dhdGVyKQotCQkJaGlnaF93YXRlciA9IHBoeXNfYXZhaWxbaSArIDFdOwogCX0K IAotI2lmZGVmIFhFTgotCWxvd193YXRlciA9IDA7Ci0jZW5kaWYJCi0KIAllbmQgPSBwaHlzX2F2 YWlsW2JpZ2dlc3RvbmUrMV07CiAKIAkvKgpAQCAtMzkzLDggKzQwMCw4IEBACiAJZmlyc3RfcGFn ZSA9IGxvd193YXRlciAvIFBBR0VfU0laRTsKICNpZmRlZiBWTV9QSFlTU0VHX1NQQVJTRQogCXBh Z2VfcmFuZ2UgPSAwOwotCWZvciAoaSA9IDA7IHBoeXNfYXZhaWxbaSArIDFdICE9IDA7IGkgKz0g MikKLQkJcGFnZV9yYW5nZSArPSBhdG9wKHBoeXNfYXZhaWxbaSArIDFdIC0gcGh5c19hdmFpbFtp XSk7CisJZm9yIChpID0gMDsgZHVtcF9hdmFpbFtpICsgMV0gIT0gMDsgaSArPSAyKQorCQlwYWdl X3JhbmdlICs9IGF0b3AoZHVtcF9hdmFpbFtpICsgMV0gLSBkdW1wX2F2YWlsW2ldKTsKICNlbGlm IGRlZmluZWQoVk1fUEhZU1NFR19ERU5TRSkKIAlwYWdlX3JhbmdlID0gaGlnaF93YXRlciAvIFBB R0VfU0laRSAtIGZpcnN0X3BhZ2U7CiAjZWxzZQpJbmRleDogc3lzL3ZtL3ZtX3BoeXMuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzeXMvdm0vdm1fcGh5cy5jCShyZXZpc2lvbiAyNzIyODEpCisrKyBzeXMvdm0v dm1fcGh5cy5jCSh3b3JraW5nIGNvcHkpCkBAIC0zNjUsMTcgKzM2NSwxNyBAQAogCXN0cnVjdCB2 bV9mcmVlbGlzdCAqZmw7CiAJaW50IGRvbSwgZmxpbmQsIGksIG9pbmQsIHBpbmQ7CiAKLQlmb3Ig KGkgPSAwOyBwaHlzX2F2YWlsW2kgKyAxXSAhPSAwOyBpICs9IDIpIHsKKwlmb3IgKGkgPSAwOyBk dW1wX2F2YWlsW2kgKyAxXSAhPSAwOyBpICs9IDIpIHsKICNpZmRlZglWTV9GUkVFTElTVF9JU0FE TUEKLQkJaWYgKHBoeXNfYXZhaWxbaV0gPCAxNjc3NzIxNikgewotCQkJaWYgKHBoeXNfYXZhaWxb aSArIDFdID4gMTY3NzcyMTYpIHsKLQkJCQl2bV9waHlzX2NyZWF0ZV9zZWcocGh5c19hdmFpbFtp XSwgMTY3NzcyMTYsCisJCWlmIChkdW1wX2F2YWlsW2ldIDwgMTY3NzcyMTYpIHsKKwkJCWlmIChk dW1wX2F2YWlsW2kgKyAxXSA+IDE2Nzc3MjE2KSB7CisJCQkJdm1fcGh5c19jcmVhdGVfc2VnKGR1 bXBfYXZhaWxbaV0sIDE2Nzc3MjE2LAogCQkJCSAgICBWTV9GUkVFTElTVF9JU0FETUEpOwotCQkJ CXZtX3BoeXNfY3JlYXRlX3NlZygxNjc3NzIxNiwgcGh5c19hdmFpbFtpICsgMV0sCisJCQkJdm1f cGh5c19jcmVhdGVfc2VnKDE2Nzc3MjE2LCBkdW1wX2F2YWlsW2kgKyAxXSwKIAkJCQkgICAgVk1f RlJFRUxJU1RfREVGQVVMVCk7CiAJCQl9IGVsc2UgewotCQkJCXZtX3BoeXNfY3JlYXRlX3NlZyhw aHlzX2F2YWlsW2ldLAotCQkJCSAgICBwaHlzX2F2YWlsW2kgKyAxXSwgVk1fRlJFRUxJU1RfSVNB RE1BKTsKKwkJCQl2bV9waHlzX2NyZWF0ZV9zZWcoZHVtcF9hdmFpbFtpXSwKKwkJCQkgICAgZHVt cF9hdmFpbFtpICsgMV0sIFZNX0ZSRUVMSVNUX0lTQURNQSk7CiAJCQl9CiAJCQlpZiAoVk1fRlJF RUxJU1RfSVNBRE1BID49IHZtX25mcmVlbGlzdHMpCiAJCQkJdm1fbmZyZWVsaXN0cyA9IFZNX0ZS RUVMSVNUX0lTQURNQSArIDE7CkBAIC0zODIsMjEgKzM4MiwyMSBAQAogCQl9IGVsc2UKICNlbmRp ZgogI2lmZGVmCVZNX0ZSRUVMSVNUX0hJR0hNRU0KLQkJaWYgKHBoeXNfYXZhaWxbaSArIDFdID4g Vk1fSElHSE1FTV9BRERSRVNTKSB7Ci0JCQlpZiAocGh5c19hdmFpbFtpXSA8IFZNX0hJR0hNRU1f QUREUkVTUykgewotCQkJCXZtX3BoeXNfY3JlYXRlX3NlZyhwaHlzX2F2YWlsW2ldLAorCQlpZiAo ZHVtcF9hdmFpbFtpICsgMV0gPiBWTV9ISUdITUVNX0FERFJFU1MpIHsKKwkJCWlmIChkdW1wX2F2 YWlsW2ldIDwgVk1fSElHSE1FTV9BRERSRVNTKSB7CisJCQkJdm1fcGh5c19jcmVhdGVfc2VnKGR1 bXBfYXZhaWxbaV0sCiAJCQkJICAgIFZNX0hJR0hNRU1fQUREUkVTUywgVk1fRlJFRUxJU1RfREVG QVVMVCk7CiAJCQkJdm1fcGh5c19jcmVhdGVfc2VnKFZNX0hJR0hNRU1fQUREUkVTUywKLQkJCQkg ICAgcGh5c19hdmFpbFtpICsgMV0sIFZNX0ZSRUVMSVNUX0hJR0hNRU0pOworCQkJCSAgICBkdW1w X2F2YWlsW2kgKyAxXSwgVk1fRlJFRUxJU1RfSElHSE1FTSk7CiAJCQl9IGVsc2UgewotCQkJCXZt X3BoeXNfY3JlYXRlX3NlZyhwaHlzX2F2YWlsW2ldLAotCQkJCSAgICBwaHlzX2F2YWlsW2kgKyAx XSwgVk1fRlJFRUxJU1RfSElHSE1FTSk7CisJCQkJdm1fcGh5c19jcmVhdGVfc2VnKGR1bXBfYXZh aWxbaV0sCisJCQkJICAgIGR1bXBfYXZhaWxbaSArIDFdLCBWTV9GUkVFTElTVF9ISUdITUVNKTsK IAkJCX0KIAkJCWlmIChWTV9GUkVFTElTVF9ISUdITUVNID49IHZtX25mcmVlbGlzdHMpCiAJCQkJ dm1fbmZyZWVsaXN0cyA9IFZNX0ZSRUVMSVNUX0hJR0hNRU0gKyAxOwogCQl9IGVsc2UKICNlbmRp ZgotCQl2bV9waHlzX2NyZWF0ZV9zZWcocGh5c19hdmFpbFtpXSwgcGh5c19hdmFpbFtpICsgMV0s CisJCXZtX3BoeXNfY3JlYXRlX3NlZyhkdW1wX2F2YWlsW2ldLCBkdW1wX2F2YWlsW2kgKyAxXSwK IAkJICAgIFZNX0ZSRUVMSVNUX0RFRkFVTFQpOwogCX0KIAlmb3IgKGRvbSA9IDA7IGRvbSA8IHZt X25kb21haW5zOyBkb20rKykgewpJbmRleDogc3lzL3ZtL3ZtX3Jlc2Vydi5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy92bS92bV9yZXNlcnYuYwkocmV2aXNpb24gMjcyMjgxKQorKysgc3lzL3ZtL3ZtX3Jl c2Vydi5jCSh3b3JraW5nIGNvcHkpCkBAIC04MjQsOSArODI0LDkgQEAKIAkgKiBJbml0aWFsaXpl IHRoZSByZXNlcnZhdGlvbiBhcnJheS4gIFNwZWNpZmljYWxseSwgaW5pdGlhbGl6ZSB0aGUKIAkg KiAicGFnZXMiIGZpZWxkIGZvciBldmVyeSBlbGVtZW50IHRoYXQgaGFzIGFuIHVuZGVybHlpbmcg c3VwZXJwYWdlLgogCSAqLwotCWZvciAoaSA9IDA7IHBoeXNfYXZhaWxbaSArIDFdICE9IDA7IGkg Kz0gMikgewotCQlwYWRkciA9IHJvdW5kdXAyKHBoeXNfYXZhaWxbaV0sIFZNX0xFVkVMXzBfU0la RSk7Ci0JCXdoaWxlIChwYWRkciArIFZNX0xFVkVMXzBfU0laRSA8PSBwaHlzX2F2YWlsW2kgKyAx XSkgeworCWZvciAoaSA9IDA7IGR1bXBfYXZhaWxbaSArIDFdICE9IDA7IGkgKz0gMikgeworCQlw YWRkciA9IHJvdW5kdXAyKGR1bXBfYXZhaWxbaV0sIFZNX0xFVkVMXzBfU0laRSk7CisJCXdoaWxl IChwYWRkciArIFZNX0xFVkVMXzBfU0laRSA8PSBkdW1wX2F2YWlsW2kgKyAxXSkgewogCQkJdm1f cmVzZXJ2X2FycmF5W3BhZGRyID4+IFZNX0xFVkVMXzBfU0hJRlRdLnBhZ2VzID0KIAkJCSAgICBQ SFlTX1RPX1ZNX1BBR0UocGFkZHIpOwogCQkJcGFkZHIgKz0gVk1fTEVWRUxfMF9TSVpFOwo= --001a11c35a9caa54240504363d05-- From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 15:54:28 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54C5DACE for ; Mon, 29 Sep 2014 15:54:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EB74D7F for ; Mon, 29 Sep 2014 15:54:28 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 19C36B939 for ; Mon, 29 Sep 2014 11:54:27 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Removing disconnected tty drivers Date: Mon, 29 Sep 2014 11:53:53 -0400 Message-ID: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 29 Sep 2014 11:54:27 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:54:28 -0000 The following drivers have never been converted to use the new tty layer introduced in 8.0 and have been disconnected since then. Several of them are for older multiport serial cards, and in the case of sio(4), current kernels use uart(4) instead. Barring major objections, I plan to remove them from the tree later this week. If someone wishes to update them, they can always be pulled back from svn history. dev/cx/if_cx.c: d->tty = ttyalloc (); dev/cy/cy.c: tp = com->tp = ttyalloc(); dev/digi/digi.c: tp = port->tp = ttyalloc(); dev/rc/rc.c: tp = rc->rc_tp = ttyalloc(); dev/sio/sio.c: tp = com->tp = ttyalloc(); pc98/cbus/sio.c: tp = com->tp = ttyalloc(); -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 16:10:28 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55C90FC9; Mon, 29 Sep 2014 16:10:28 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 13EA2F01; Mon, 29 Sep 2014 16:10:27 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9AF461598; Mon, 29 Sep 2014 16:10:26 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s8TGAQs1033700; Mon, 29 Sep 2014 16:10:26 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: Removing disconnected tty drivers In-reply-to: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> From: "Poul-Henning Kamp" References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33698.1412007026.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Sep 2014 16:10:26 +0000 Message-ID: <33699.1412007026@critter.freebsd.dk> Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:10:28 -0000 -------- In message <1789815.bS8Ac2qsJ6@ralph.baldwin.cx>, John Baldwin writes: >Barring major objections, I plan to remove them from the tree later this = week. >dev/cx/if_cx.c: d->tty =3D ttyalloc (); >dev/cy/cy.c: tp =3D com->tp =3D ttyalloc(); >dev/digi/digi.c: tp =3D port->tp =3D ttyalloc(); >dev/rc/rc.c: tp =3D rc->rc_tp =3D ttyalloc(); >dev/sio/sio.c: tp =3D com->tp =3D ttyalloc(); >pc98/cbus/sio.c: tp =3D com->tp =3D ttyalloc(); Those drivers ran a LOT of modems back when the internet spread like wildfire... Sic Transit Gloria Mundi! & Good Riddance! -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@FreeBSD.ORG Mon Sep 29 23:46:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15FE59F0 for ; Mon, 29 Sep 2014 23:46:46 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1230AB8 for ; Mon, 29 Sep 2014 23:46:45 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id rl12so3556946iec.17 for ; Mon, 29 Sep 2014 16:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=YMTCMU53SDHUzTRdvHyK2Ocd0r2nMsnjI0q4eE+vuvM=; b=gmNrHmzbxjX+Kbgh55+OK4snD0rbCEdAe0NubcgIibbiK7rgkEbwc92lsJTR0mAyif D/enUP6JvdrVKBrWMFDhcHAsIUru5TvV5qfw8okoyCz5LM2/UNbqXuVV7rE9pGJUw4JZ BAzgcsRg0XBHmMGpYaHxuH8LEsGbTpH+f4GhIYcEtonvvci0ELcJU+yvCt2ORSnQaWG3 g/trVggJSc3NgYKjXlpR1TE8HbawDrD0BZMcSmUziBWDR0Md8WWSwqKPK3yTbz+p1U5d OdgTUcGIWl/jcNXvagBzDu05RumFGvH547/n097sEqoh8wSmw4cUPltYIJf28J7G5bnQ bG4g== X-Gm-Message-State: ALoCoQmB2YVpeyg56w1CFPlRlabDyhS+FZLP6e/9gOFZFgcHe7ByiuxMxV/hI0b2hCcyjkyD/8gW X-Received: by 10.50.79.232 with SMTP id m8mr1771194igx.0.1412034405094; Mon, 29 Sep 2014 16:46:45 -0700 (PDT) Received: from [10.1.10.201] ([50.253.99.174]) by mx.google.com with ESMTPSA id ci9sm11695810igb.17.2014.09.29.16.46.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 16:46:44 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_C5BDF6ED-62FA-4740-85EF-F5BDF1746F4C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Removing disconnected tty drivers From: Warner Losh In-Reply-To: <33699.1412007026@critter.freebsd.dk> Date: Mon, 29 Sep 2014 17:46:43 -0600 Message-Id: <0FAA4685-F4EA-416B-A28F-D04499804B95@bsdimp.com> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <33699.1412007026@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 23:46:46 -0000 --Apple-Mail=_C5BDF6ED-62FA-4740-85EF-F5BDF1746F4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 29, 2014, at 10:10 AM, Poul-Henning Kamp = wrote: > -------- > In message <1789815.bS8Ac2qsJ6@ralph.baldwin.cx>, John Baldwin writes: >=20 >> Barring major objections, I plan to remove them from the tree later = this week. >=20 >> dev/cx/if_cx.c: d->tty =3D ttyalloc (); >> dev/cy/cy.c: tp =3D com->tp =3D ttyalloc(); >> dev/digi/digi.c: tp =3D port->tp =3D ttyalloc(); >> dev/rc/rc.c: tp =3D rc->rc_tp =3D ttyalloc(); >> dev/sio/sio.c: tp =3D com->tp =3D ttyalloc(); >> pc98/cbus/sio.c: tp =3D com->tp =3D ttyalloc(); >=20 > Those drivers ran a LOT of modems back when the internet spread like > wildfire... >=20 > Sic Transit Gloria Mundi! & Good Riddance! Agreed. I bought cy and digi hardware so that I could convert them, but = never did. I=92ve had that hardware in my garage for about 5 or 6 years now. = Anybody that wants it can drop me a note. Warner --Apple-Mail=_C5BDF6ED-62FA-4740-85EF-F5BDF1746F4C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKe9jAAoJEGwc0Sh9sBEAsYgQANFk+6jzGnHNL5n25CKO5Tue NVSMcfES1KGMFQBRwToaMoc1s8JOaZfLrZpF8oQkw08P0uvW5gFEW0b4bNpbp94J KgEN9kEG1WAaDmVs+ZuDuO+BjhAlsI3h+uyGjysX6nSxKzr6H4Q/3T2W9ZCO0S9+ vdhNYoeBjx9fVrI4WFne0bLNtjN1AAUN+Wfycp1BEJzaFpq++fzOF+txemM5ebkN ePx9YLpj+08zKlT599xKTA+/50vVlzd4F/acKvFn1RsFR8FAxIm1gALCAJiI2q+y diUfDUtgBcAMPmzd43kc8M/esbxFXOC9ddY2mJ8gLx+yMZulPzKCOapA0KXXgJdL Ee1Z50Z5jxT+aMLSBk+3MOaDagMgQiL98LX36ZUTNzX0g3oFmMl0gxmCYHLgCi0W SvxDriGkDMrO/c0Dw4uPMWl6pGaVRkVnlJ73zRVNLn4RaSdm3E7iGS7pu7gubT+g 4k/s2iE2gGlYTxaNvXHN2T9JfZEHt8yVBbHtYGwbyVlQ9NVtCYhZulKZPDGOrZ0X 841GtB4SNaSygYmD+1dMg03tkatBQ34z/dihzNQq5OjMoAl2J8m4i8OQ/dtcH1Fx +TzmyFl9TexP92mKoeaSbB5t+owDKnV9oU+2vxZgX6kCBQID5DhtDJJQTGVOTHTM 2nZyfudKO1hMobbbo+nO =5Upf -----END PGP SIGNATURE----- --Apple-Mail=_C5BDF6ED-62FA-4740-85EF-F5BDF1746F4C-- From owner-freebsd-arch@FreeBSD.ORG Tue Sep 30 12:37:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6535CCBE; Tue, 30 Sep 2014 12:37:06 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBCCD30F; Tue, 30 Sep 2014 12:37:05 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id n8so10104430qaq.41 for ; Tue, 30 Sep 2014 05:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wt7eqEnc0Nni+B8Y9qjkslOckaPfPPvgv7LhuWPsw3E=; b=PEM4ww2YVBFI/YO5Anous87iKgUC9Feb13wpqeAmas6PGKKVqfLbTLpcBB11X8gMlc IvV49o95WV7hGpdzdpJEn5TPrwDJU3AXHrM/5VkTJFwomds9ItTv5WiCys3RIjAA2FXw nWbl2F4gWRB0m/3YPPrOH2/khoF/2UZkJqo9jMexkPeohBeXAJHVsLeV5UgAsd7MzcTc 9WBaYIGwcJFMYRJMIDItHF2tts/9YdNiqV1z6BiIagmjMT9v8IgyPMcx5TVkpv0Xr4ty ceSZmwbA2RNcyU49VpyOKYiJsxTg2RV2ea1+5lZuM2HrakPea2tzmLbW2yul5rzqy4DE yZmQ== MIME-Version: 1.0 X-Received: by 10.224.86.68 with SMTP id r4mr39598580qal.0.1412080621924; Tue, 30 Sep 2014 05:37:01 -0700 (PDT) Received: by 10.140.23.242 with HTTP; Tue, 30 Sep 2014 05:37:01 -0700 (PDT) In-Reply-To: <5428AF3B.1030906@rice.edu> References: <5428AF3B.1030906@rice.edu> Date: Tue, 30 Sep 2014 14:37:01 +0200 Message-ID: Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Svatopluk Kraus To: Alan Cox Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: alc@freebsd.org, FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 12:37:06 -0000 On Mon, Sep 29, 2014 at 3:00 AM, Alan Cox wrote: > On 09/27/2014 03:51, Svatopluk Kraus wrote: > > > On Fri, Sep 26, 2014 at 8:08 PM, Alan Cox wrote: > >> >> >> On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus >> wrote: >> >>> Hi, >>> >>> I and Michal are finishing new ARM pmap-v6 code. There is one problem >>> we've >>> dealt with somehow, but now we would like to do it better. It's about >>> physical pages which are allocated before vm subsystem is initialized. >>> While later on these pages could be found in vm_page_array when >>> VM_PHYSSEG_DENSE memory model is used, it's not true for >>> VM_PHYSSEG_SPARSE >>> memory model. And ARM world uses VM_PHYSSEG_SPARSE model. >>> >>> It really would be nice to utilize vm_page_array for such preallocated >>> physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things >>> could be much easier then. In our case, it's about pages which are used >>> for >>> level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such >>> pages. First ones are preallocated and second ones are allocated after vm >>> subsystem was inited. We must deal with each set differently. So code is >>> more complex and so is debugging. >>> >>> Thus we need some method how to say that some part of physical memory >>> should be included in vm_page_array, but the pages from that region >>> should >>> not be put to free list during initialization. We think that such >>> possibility could be utilized in general. There could be a need for some >>> physical space which: >>> >>> (1) is needed only during boot and later on it can be freed and put to vm >>> subsystem, >>> >>> (2) is needed for something else and vm_page_array code could be used >>> without some kind of its duplication. >>> >>> There is already some code which deals with blacklisted pages in >>> vm_page.c >>> file. So the easiest way how to deal with presented situation is to add >>> some callback to this part of code which will be able to either exclude >>> whole phys_avail[i], phys_avail[i+1] region or single pages. As the >>> biggest >>> phys_avail region is used for vm subsystem allocations, there should be >>> some more coding. (However, blacklisted pages are not dealt with on that >>> part of region.) >>> >>> We would like to know if there is any objection: >>> >>> (1) to deal with presented problem, >>> (2) to deal with the problem presented way. >>> Some help is very appreciated. Thanks >>> >>> >> >> As an experiment, try modifying vm_phys.c to use dump_avail instead of >> phys_avail when sizing vm_page_array. On amd64, where the same problem >> exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is >> probably my preferred solution. The catch being that not all architectures >> implement dump_avail, but my recollection is that arm does. >> > > Frankly, I would prefer this too, but there is one big open question: > > What is dump_avail for? > > > > dump_avail[] is solving a similar problem in the minidump code, hence, the > prefix "dump_" in its name. In other words, the minidump code couldn't use > phys_avail[] either because it didn't describe the full range of physical > addresses that might be included in a minidump, so dump_avail[] was created. > > There is already precedent for what I'm suggesting. dump_avail[] is > already (ab)used outside of the minidump code on x86 to solve this same > problem in x86/x86/nexus.c, and on arm in arm/arm/mem.c. > > > Using it for vm_page_array initialization and segmentation means that > phys_avail must be a subset of it. And this must be stated and be visible > enough. Maybe it should be even checked in code. I like the idea of > thinking about dump_avail as something what desribes all memory in a > system, but it's not how dump_avail is defined in archs now. > > > > When you say "it's not how dump_avail is defined in archs now", I'm not > sure whether you're talking about the code or the comments. In terms of > code, dump_avail[] is a superset of phys_avail[], and I'm not aware of any > code that would have to change. In terms of comments, I did a grep looking > for comments defining what dump_avail[] is, because I couldn't remember > any. I found one ... on arm. So, I don't think it's a onerous task > changing the definition of dump_avail[]. :-) > > Already, as things stand today with dump_avail[] being used outside of the > minidump code, one could reasonably argue that it should be renamed to > something like phys_exists[]. > > > > I will experiment with it on monday then. However, it's not only about how > memory segments are created in vm_phys.c, but it's about how vm_page_array > size is computed in vm_page.c too. > > > > Yes, and there is also a place in vm_reserv.c that needs to change. I've > attached the patch that I developed and tested a long time ago. It still > applies cleanly and runs ok on amd64. > I've thought about it once again considering what I've learned yesterday from all archs in tree. (1) In arm, there are defined two extra arrays - hwregions and exregions - which already describes all memory on platform. This regions could be filled from FDT. => There is no need to describe all memory on platform for MI kernel sake, but there is need to describe memory which (a) should be kept in vm_page_array and, (b) is available to vm subsystem. For (a) phys_held[] or phys_known[] or phys_filed[] or phys_managed[] or ... For (b) phys_avail[]. (2) In mips, dump_avail[] is defined from phys_avail[] and is same. => One step is a renaming of misused dump_avail, for example to phys_known[]. But why not to do another step? The phys_known[] must be a superset of phys_avail[] and so superior. Thus phys_avail[] should be defined from phys_known[]. (3) In sparc64 and powerpc, dump_avail[] is not defined. => Why to force all archs to use both phys_known[] and phys_avail[]. If a pointer to phys_avail[] will be defined, then if not NULL, the array being pointed will be used. Otherwise, phys_known[] will be used. The pointer can be defined in MI code and initialized to NULL. So in archs which do not need both arrays there will be no need to do anything. The vm_reserv_init() and vm_phys_init() are called from vm_page_startup(). All three functions are only ones in MI code involved in this thing. The first two of them have no arguments now. If this will be changed and a pointer to array which should be processed will be given to them, then only real work remains in vm_page_startup(). What do you think about this? Svata From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 08:00:37 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA5FA2F7 for ; Wed, 1 Oct 2014 08:00:37 +0000 (UTC) Received: from mail-s93.mailgun.info (mail-s93.mailgun.info [184.173.153.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6E58FB for ; Wed, 1 Oct 2014 08:00:37 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=soundestdirect.com; q=dns/txt; s=pic; t=1412150436; h=Date: Message-Id: List-Unsubscribe: From: To: Subject: Content-Type: Mime-Version: Sender; bh=LiY8mBTDk9nSBwJ8H3kgZ0x6VDDejIC3rp3tmUkiPbc=; b=pjJyiblsXLTmZ0KotcJ71oTKxKm5SQQclSzOjcSYGGai6iGqZG/3PpM0WmRZyBv8Wdn1Q3p0 GoqphmQIR4u7yxibC469xuIaIcRpTMt+zp7LWaAm4vH0zo6p9E2tzrtrqmhPaNyOa2/hRf+s 2B1WFY+pFx2nu8whRofUhsxVJpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=soundestdirect.com; s=pic; q=dns; h=Date: Message-Id: List-Unsubscribe: From: To: Subject: Content-Type: Mime-Version: Sender; b=cUAz2XE4rKl2z5M6HHmaxaqIvarRbtT6BrBoZvfRyuZ8mN19lC336E6PzF58U9Jm0ALGdp WI9l5qY2VWUsU6/BBfczDOgu/VrRQzdWayQvAKrwTGczctobJcZ7PsAVRJXFj7tstbnqPZ4z uEQEfmJOC6TaaSaZ6bGRLLe6iItjw= Received: from [127.0.0.1] (app-1.radar.soundest.net [192.96.207.97]) by mxa.mailgun.org with ESMTP id 542bb4a3.5792660-in3; Wed, 01 Oct 2014 08:00:35 -0000 (UTC) Date: Wed, 01 Oct 2014 08:00:34 GMT Message-Id: <71674c4b08caa2c103838e80f70773@app-1> From: "Johan Watson" To: freebsd-arch@freebsd.org Subject: October Specials from Furnways Mime-Version: 1.0 X-Mailgun-Sid: WyIzNzVhNiIsICJmcmVlYnNkLWFyY2hAZnJlZWJzZC5vcmciLCAiNTgzYzUiXQ== Sender: sales=furnways.co.za@soundestdirect.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:00:37 -0000 Hospitality Furniture [Web version](http://furnways-uoonf0.soundestdirect.= com/view/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 95/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 94/542ba73858026ef77f21399c/54264699fe7da963021cb802) Furnways - Corporate Turnkey Solutions [**Furnways is a leading office furniture supplier**](http://furnways-uoonf= 0.soundestdirect.com/link/542ba6f558026ef77f213993/542ba73858026ef77f21399c= /54264699fe7da963021cb802) in South Africa. WE offer the widest range of = products, from executive desks [to school furniture](http://furnways-uoonf0= .soundestdirect.com/link/542ba6f558026ef77f213992/542ba73858026ef77f21399c/= 54264699fe7da963021cb802). We are the biggest online furniture store in = Africa, delivering high quality products at affordable prices, = understanding our customers' need to acquire top of the line furniture for = their business with reasonable investments. If you are looking for stylish = furniture for your office, hotel or restaurant, then this is the perfect = place for you, as we specialize in creating innovative and chic designs for= your furniture. [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213991= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Wimpey Side Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213991/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Available in over 20 Colours 5 Year Warranty. R240.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213991/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213990= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Wimpey Arm Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213990/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Available in over 20 Colours 5 Year Warranty. R260.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213990/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398f= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Wimpey Ultra Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398f/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Available in over 20 Colours 5 Year Warranty. R280.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398f/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398e= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Chloe Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398e/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Available in over 20 Colours 5 Year Warranty. R480.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398e/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398d= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Alpine Chairs ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398d/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Available in over 20 Colours 5 Year Warranty. R132.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398d/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398c= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Avatar Caf=C3=A9 Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398c/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Available in over 20 Colours 5 Year Warranty. R260.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398c/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398b= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Double Pedestal Desk ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398b/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) 32mm Melamine Top 1800mm*900mm Single Pedestal: R2865 Available in a variety of colours 5 Year Warranty R3540.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398b/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398a= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Rectangular Tables ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398a/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) 16mm Melamine Tops Available in Oak, Mahogany or Supawood 1800 * 900 From R1093 1400 * 700 From R663 1200 * 600 From R504=C2=A0 5 Year Warranty R504.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398a/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213989= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Perforated Metal Set ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213989/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Contains: 2 tier letter tray Paper bin Pencil cup Paper cube 5 Year Warranty **Available in Siver for R1428** Black/White: R1165.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213989/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213988= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Big & Tall Heavy Duty Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213988/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) Supports Up to 150kg Leather Seat Chrome base Chrome arms with polyurethane pads 5 Year Warranty R3496.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213988/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213987= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Spine Ergonomic High Back Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213987/542ba73858026ef77f21399c/54264699fe7da963= 021cb802) 2 Part shell Permanent contact mechanism Adjustable arms Available in leather Loads of extras and materials available 5 Year Warranty R1750.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213987/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213986= /542ba73858026ef77f21399c/54264699fe7da963021cb802) [ Lucea 1500 Ergonomic Typist Chair ](http://furnways-uoonf0.soundestdirect= .com/link/542ba6f558026ef77f213986/542ba73858026ef77f21399c/54264699fe7da96= 3021cb802) Ergonomic shaped back with rake and height adjustment Standard with black nylon base Available in leather Loads of extras and materials available 5 Year Warranty R811.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213986/542ba73858026ef77f21399c/54264699fe7da963021cb802) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 85/542ba73858026ef77f21399c/54264699fe7da963021cb802) =C2=A0[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f= 213984/542ba73858026ef77f21399c/54264699fe7da963021cb802)=C2=A0 =C2=A0[ = ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213983/5= 42ba73858026ef77f21399c/54264699fe7da963021cb802)=C2=A0 =C2=A0[ = ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213982/5= 42ba73858026ef77f21399c/54264699fe7da963021cb802)=C2=A0 [sales@furnways.co.za](mailto:sales@furnways.co.za) Furnways Lonehill Boulevard , 22 , Sandton , 2062 , South Africa All prices are in ZAR and excludes VAT and delivery =C2=A9 2014 Furnways [Unsubscribe](http://furnways-uoonf0.soundestdirect.= com/unsubscribe/542ba73858026ef77f21399c/54264699fe7da963021cb802) Proudly delivered by [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213981= /542ba73858026ef77f21399c/54264699fe7da963021cb802) From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 10:17:47 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F16CE2CB; Wed, 1 Oct 2014 10:17:47 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C62EBB5; Wed, 1 Oct 2014 10:17:46 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id s91A3xWD090854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Oct 2014 20:04:04 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id s91A3r3q002187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Oct 2014 20:03:53 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id s91A3rJH002186; Wed, 1 Oct 2014 20:03:53 +1000 (EST) (envelope-from peter) Date: Wed, 1 Oct 2014 20:03:53 +1000 From: Peter Jeremy To: John Baldwin Subject: Re: Removing disconnected tty drivers Message-ID: <20141001100353.GF20707@server.rulingia.com> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 10:17:48 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Sep-29 11:53:53 -0400, John Baldwin wrote: >The following drivers have never been converted to use the new tty layer= =20 >introduced in 8.0 and have been disconnected since then. Several of them = are=20 >for older multiport serial cards, and in the case of sio(4), current kerne= ls=20 >use uart(4) instead. Barring major objections, I plan to remove them from= the=20 >tree later this week. If someone wishes to update them, they can always b= e=20 >pulled back from svn history. > >dev/digi/digi.c: tp =3D port->tp =3D ttyalloc(); See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D152253 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D158086 unfortunately, I no longer have access to the hardware. I'm happy to update the patches to compile on -current but can't do more than that. --=20 Peter Jeremy --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUK9GJXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0SgYP/15wTAAQQc2JDK0NfgN8EZ2W sL6CcVbz+/zc37KyDCD8SHCl1QzAlvVEmfngqrEh0FdN7vTm9MsPAl9IR4DeV3+h +va7Bel1GqN0h2w7fLW3tMFWzUcQ5EPpxpk+FFm9339eA4YB75eMUEmOPA98g3m5 HtA2SWm/fqL4KoNzyA+75aywobfwPRbOC2yavKa5ak/v2cB7W7deUOMO3NiWQ+8e ih/DVKPggA4P5ECGK7K5Z9GCRyeCBLFlq+TGrR6kzY3j73mSwx7QfUTDyFib9QOh EYcaMUY6HNcXF1AyWe+Pe4G5yc82SvCZgGdQy8Wy9LGZGfDlbiwhuM1rLRfjWIxp JFurHJANw1VTbxirUxsAbnX+0tL/j2ACAGrIcE4fStvkWMDDIf70SpgI/Z2Zp+eA GqewvfRL2GhFSNPtC5KmDktrsiaKJMjBQMbEExvmLqAjwbBhxhyd2P4NY0kXHZ9s 4OI8kNrX4Yd59qRVckOXm/SJc8JoGdBNM6K4l93w689NsKUD3dyygLcg5ayKUTjJ yiS+t5C5tCqkq4pN/VGG8xXp7IpvG2+iH1Meo9dpL0twTuqULyUnloGYHuJzx/QX 7KmI26mG1mZIL9yougWb62TKY5itJWqSjy1Tckxknj9WGPE+B338g8RD+vVuNO78 aMGoSsyrZY6psE5Q4oBX =BGgL -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 17:59:55 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44F57888; Wed, 1 Oct 2014 17:59:55 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F701D06; Wed, 1 Oct 2014 17:59:54 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s91Hxr8r062625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 10:59:53 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s91HxqDo062624; Wed, 1 Oct 2014 10:59:52 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Oct 2014 10:59:52 -0700 From: John-Mark Gurney To: Peter Jeremy Subject: Re: Removing disconnected tty drivers Message-ID: <20141001175952.GZ43300@funkthat.com> Mail-Followup-To: Peter Jeremy , John Baldwin , freebsd-arch@freebsd.org References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141001100353.GF20707@server.rulingia.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Oct 2014 10:59:53 -0700 (PDT) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:59:55 -0000 Peter Jeremy wrote this message on Wed, Oct 01, 2014 at 20:03 +1000: > On 2014-Sep-29 11:53:53 -0400, John Baldwin wrote: > >The following drivers have never been converted to use the new tty layer > >introduced in 8.0 and have been disconnected since then. Several of them are > >for older multiport serial cards, and in the case of sio(4), current kernels > >use uart(4) instead. Barring major objections, I plan to remove them from the > >tree later this week. If someone wishes to update them, they can always be > >pulled back from svn history. > > > >dev/digi/digi.c: tp = port->tp = ttyalloc(); > > See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152253 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158086 > unfortunately, I no longer have access to the hardware. I'm happy to > update the patches to compile on -current but can't do more than that. I think I have digi hardware (an old ISA card), and I just recently upgraded a box to HEAD that has ISA slots, so I'll look at testing out these patches... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 18:50:26 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ADEDA99 for ; Wed, 1 Oct 2014 18:50:26 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B32465FF for ; Wed, 1 Oct 2014 18:50:25 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id s91IoGGn092764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 2 Oct 2014 04:50:21 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id s91IoBX3088214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Oct 2014 04:50:11 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id s91IoBXC088213 for freebsd-arch@freebsd.org; Thu, 2 Oct 2014 04:50:11 +1000 (EST) (envelope-from peter) Date: Thu, 2 Oct 2014 04:50:11 +1000 From: Peter Jeremy To: freebsd-arch@freebsd.org Subject: Re: Removing disconnected tty drivers Message-ID: <20141001185011.GA12174@server.rulingia.com> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <20141001175952.GZ43300@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <20141001175952.GZ43300@funkthat.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:50:26 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Oct-01 10:59:52 -0700, John-Mark Gurney wrote: >Peter Jeremy wrote this message on Wed, Oct 01, 2014 at 20:03 +1000: >> See >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D152253 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D158086 >> unfortunately, I no longer have access to the hardware. I'm happy to >> update the patches to compile on -current but can't do more than that. > >I think I have digi hardware (an old ISA card), and I just recently >upgraded a box to HEAD that has ISA slots, so I'll look at testing >out these patches... Note that I only had access to PCI hardware and the ISA bus interface was significantly different so those patches only support PCI cards. (I'm not sure how much effort would be necessary to get it working with both ISA and PCI). --=20 Peter Jeremy --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJULEziXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0cfgQAKAjA2nBdGgBz1VwvZ6DLXes 4GoeGxa3IolP8NC5tSAjEOFK/hGxhzkpNUGgUqZKDLa0a4PxxVGl13e77iIC75zH CoiM37QCySHyOcJcsIAO1j8n98w4cnK5xhLy4CIB1OiW2GQvzlcSK5zLkpbtpkWh XVvq7EpsDoemM5pL/cy7lvJ3un1gnBvqKbwkq59tqqlM+x9dhQKnx9lMlnRuB2NY ts7b3c9YLtVBal2ETRFYPE/VLbwAodAdpf700nUtSBn8turNDm8/v+2or8v2hAui 15Ed4JEJkpirhMvttHVwpEg5YK/yyNCbxzulOcLAvfid9Tnvb7IWpJbNXASVhBUB Vpj1+apbCIWIaWec0a0CMjJQooDQHCC+iMUNmVX3DT1Ihch8ZacLy9oakfmU7Tbj d0y90VIxYZXLCzdM78Vyo1J4uXFftDWsGNq4EG3PeLSUacKRt+k8yeI8W3cLPRa1 JJGs521NnzzzhEf5g6sa3H9Vy2Hrn2c5h2CCFVvUPH2MTnvSJ5XyvvhQulReHYFh Ke2Y+7raePwL1/XfTGdxRE3WU9ZY2NwkqZbJFlhetRXdmBNG1eHCeXuANk6TjVNG pWcE2SHjN+4ikgsr0ZwI5g9QfImP9zo/XAPoDXH98XOl6U7nMzeS5dgnN0Xd4Bbx p3beKwyY7WZii0PSfYEa =ems+ -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-arch@FreeBSD.ORG Wed Oct 1 20:58:04 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25A4BEBC for ; Wed, 1 Oct 2014 20:58:04 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E932B839 for ; Wed, 1 Oct 2014 20:58:03 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id et14so937952pad.31 for ; Wed, 01 Oct 2014 13:57:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=CDv0HvPSGf/6x8ZIGlcuvyp5Zty8PJYXxGgO7hUosjc=; b=Muiwi6WOzInXBLiC8Ag6ESFBJv1/wEhYwiP1Pm/8EOJHH9mpfIHCf37zqTW/bbIPie nCUUgj+Elt56RM55NqojAGNURHFxONwlHRY2ptligOrIFUE8pVxhGG1srK46ni0IFzlD 144oaZ5+e3wzLIOzlUpApFzItJSXZ5gDdZElz3b/Wx4AzXdGzlJvxVyDkijoZ41k0LJa 9mw7lhHntSauC3ahRyXv3Vfxkjz5kz16u0S2mcpWCyMtLPEbsmul+g5vEeV8JRfc5B/w LsEK6xsvV7qympGw2iYa4vQQTdIdd7gyJivXUCDAzpSyblgsxN5JjeTL/D/o6+jSu8PW uhyw== X-Gm-Message-State: ALoCoQnGL2gv1rWpDJiJel49y+7lVWO4GY2lmcrYM9oNNE8DAt1Hzb8ciZRF0gFSv2iuITozMYn4 X-Received: by 10.70.96.102 with SMTP id dr6mr102631337pdb.86.1412197077421; Wed, 01 Oct 2014 13:57:57 -0700 (PDT) Received: from [10.64.25.146] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id bl3sm1772037pdb.53.2014.10.01.13.57.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 13:57:56 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_9A783086-F54B-4801-8136-F25F139A922D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Removing disconnected tty drivers From: Warner Losh In-Reply-To: <20141001185011.GA12174@server.rulingia.com> Date: Wed, 1 Oct 2014 14:58:00 -0600 Message-Id: <2EBCF1DA-6D6D-4BBF-A751-8810ED594A88@bsdimp.com> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <20141001175952.GZ43300@funkthat.com> <20141001185011.GA12174@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:58:04 -0000 --Apple-Mail=_9A783086-F54B-4801-8136-F25F139A922D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 1, 2014, at 12:50 PM, Peter Jeremy wrote: > On 2014-Oct-01 10:59:52 -0700, John-Mark Gurney = wrote: >> Peter Jeremy wrote this message on Wed, Oct 01, 2014 at 20:03 +1000: >>> See >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D152253 >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D158086 >>> unfortunately, I no longer have access to the hardware. I'm happy = to >>> update the patches to compile on -current but can't do more than = that. >>=20 >> I think I have digi hardware (an old ISA card), and I just recently >> upgraded a box to HEAD that has ISA slots, so I'll look at testing >> out these patches... >=20 > Note that I only had access to PCI hardware and the ISA bus interface > was significantly different so those patches only support PCI cards. > (I'm not sure how much effort would be necessary to get it working > with both ISA and PCI). I=92m cleaning out my garage. I=92ll check to see if I have the PCI = version for anybody that=92s interested=85 Warner --Apple-Mail=_9A783086-F54B-4801-8136-F25F139A922D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULGrYAAoJEGwc0Sh9sBEAhEkQANunJklTOMGFR4msxAbWXH7n n4avZMBAYAoSZcfhrEcoc9wnrgIJ/liH9xo782E97NWJbLMhvs/BJPg2aQCDbiGa HEooqUnP/ZrHteIuC4WDbJQqZnQRQiXFUHlDvsnafUo0coqKJSSZoMREYSTjY6ig ccdV3mVWO+4mZJ4KlAO/noPAh56+DKIRmjKR6j4xSEsjjVWj4g5i59FGFm9F7OUx Jp9xlygjpecnA9kPXDbHgS0xP3TJQ9rePQYkBZ0hXmrrFbBeFWXMnIwKEGtKo7J1 m455JwZNEelQZJqkK/fLW3he7RIdDmgWnNXlIwRRMtGLLJCOg1laFhFM2mOapQGs X9jNtyZWMb9XOss8AKhhFxJjwn1mZ7YamAx089Ng0YJ8IWeS3ISTVWrxXnZiYs7e PLNNcRdUGLUA/+ZC8U1zo73BbNhnru9o2ZhtWF0rZGnHL8wVk0Ehhp+SIURI1e62 VNKXpbAIfVQu32LGvHoBNBebp3zuCVb++Ho8wk+p04b1Gum1elbA0NpPA9g0MXI2 ijFqrMyJ54/6TdGe1P5tnoCfRmUPbGHTHwAvGWzfxdPn50RYAIsVvqnsF61ipqXd MAPewUBfH2wuUj5YibvyC+ue2O7FRAkyC0KH4ugwTY/0ZvTe9T4DoxoqLcHAAau3 D5x6W+uVDsn2yGtcmxNT =Yvjj -----END PGP SIGNATURE----- --Apple-Mail=_9A783086-F54B-4801-8136-F25F139A922D-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 2 12:34:03 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E43827C for ; Thu, 2 Oct 2014 12:34:03 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4841DB34 for ; Thu, 2 Oct 2014 12:34:03 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XZfZw-0002b3-2b; Thu, 02 Oct 2014 16:33:52 +0400 Date: Thu, 2 Oct 2014 16:33:52 +0400 From: Slawa Olhovchenkov To: Peter Jeremy Subject: Re: Removing disconnected tty drivers Message-ID: <20141002123351.GA9212@zxy.spb.ru> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <20141001175952.GZ43300@funkthat.com> <20141001185011.GA12174@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141001185011.GA12174@server.rulingia.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 12:34:03 -0000 On Thu, Oct 02, 2014 at 04:50:11AM +1000, Peter Jeremy wrote: > On 2014-Oct-01 10:59:52 -0700, John-Mark Gurney wrote: > >Peter Jeremy wrote this message on Wed, Oct 01, 2014 at 20:03 +1000: > >> See > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152253 > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158086 > >> unfortunately, I no longer have access to the hardware. I'm happy to > >> update the patches to compile on -current but can't do more than that. > > > >I think I have digi hardware (an old ISA card), and I just recently > >upgraded a box to HEAD that has ISA slots, so I'll look at testing > >out these patches... > > Note that I only had access to PCI hardware and the ISA bus interface > was significantly different so those patches only support PCI cards. > (I'm not sure how much effort would be necessary to get it working > with both ISA and PCI). As I remember ISA/EISA and PCI different only in interrupt path. All other logic is common. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 2 15:59:54 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9B0BAA4 for ; Thu, 2 Oct 2014 15:59:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4B73819 for ; Thu, 2 Oct 2014 15:59:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7FB5BB9AE; Thu, 2 Oct 2014 11:59:53 -0400 (EDT) From: John Baldwin To: Peter Jeremy Subject: Re: Removing disconnected tty drivers Date: Thu, 2 Oct 2014 11:19:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> In-Reply-To: <20141001100353.GF20707@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201410021119.37723.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 02 Oct 2014 11:59:53 -0400 (EDT) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:59:54 -0000 On Wednesday, October 01, 2014 6:03:53 am Peter Jeremy wrote: > On 2014-Sep-29 11:53:53 -0400, John Baldwin wrote: > >The following drivers have never been converted to use the new tty layer > >introduced in 8.0 and have been disconnected since then. Several of them are > >for older multiport serial cards, and in the case of sio(4), current kernels > >use uart(4) instead. Barring major objections, I plan to remove them from the > >tree later this week. If someone wishes to update them, they can always be > >pulled back from svn history. > > > >dev/digi/digi.c: tp = port->tp = ttyalloc(); > > See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152253 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158086 > unfortunately, I no longer have access to the hardware. I'm happy to > update the patches to compile on -current but can't do more than that. The second one was tested by another submitter, so if you want to spend the time, please update them and see if you can get someone to test them. To be honest, I would be happy to drop ISA support and just keep PCI support if that is simpler. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Oct 2 20:07:02 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26B56DE0 for ; Thu, 2 Oct 2014 20:07:02 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9749FABC for ; Thu, 2 Oct 2014 20:07:00 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id s92K6hW0099408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Oct 2014 06:06:50 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id s92K6bn3079502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Oct 2014 06:06:37 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id s92K6axd079501; Fri, 3 Oct 2014 06:06:36 +1000 (EST) (envelope-from peter) Date: Fri, 3 Oct 2014 06:06:36 +1000 From: Peter Jeremy To: Slawa Olhovchenkov Subject: Re: Removing disconnected tty drivers Message-ID: <20141002200636.GK20707@server.rulingia.com> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <20141001175952.GZ43300@funkthat.com> <20141001185011.GA12174@server.rulingia.com> <20141002123351.GA9212@zxy.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <20141002123351.GA9212@zxy.spb.ru> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:07:02 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Oct-02 16:33:52 +0400, Slawa Olhovchenkov wrote: >As I remember ISA/EISA and PCI different only in interrupt path. >All other logic is common. =46rom memory, the actual board access is different as well - the ISA boards have a memory-mapped window and you need to move the window around. The PCI boards linearly map the board's entire memory space. --=20 Peter Jeremy --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJULbBMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0XiAQAJedkU8aqpn2uEHdNd8OYskh 6VILnV/909vcBhw/tBfEv8JjbVcOzerCoJOGZ61mXRwvS2wLn8a2AidOzra5ZyjV eW/c/R9NIWAymUDVsUIaP9PMyinXOaPU+LXMg6YCnNto7oWfNy/axDg3+SeM7FFn A35diaT2npJMqSMlnkU6f/D0AexvFCF6NFDrYcdlpmCqM+wKHKhGuwD9zoat8mSx LQR+1vzJpIG00iMIiUVp6HYXVgf2BE72qXnAAWwcZHB5akKweJv4wEFh881PX6Jm suJ5SlVJkGPfRs+hGLB4GVrtmMv7EHwkpy+EQmTsFzZ9u8rcr7Xd6dP9Qw7LVZfQ b+gmx405pHsdANKPvsoPIXi219CLcShBBunDDUz31ZNwEYYT+7KgN7Y0mF9NbLgl 6MbUv74dRlK2cChAKfYS6AKZhF9ymmxZ0zjbj0TWRKX6RwnzOrNkGVcaUMfkiVLB Xt5P6O2OB1y6EL+GA4DLRlEhLX5oKcN+i6WA5wXa5GDt67JU1BXLUPSk813kGker sXtKYERIjzUF2jWkFM8ZWpwovq3qxQzA1X2wqKsrNDZ7TXBtheB1KC6VIxVjgfRv SWuMGVr1HUk3I2SZvfbyLrGNE5Bb+iofQaoTgsUbgYYDh+shuZae+ThXd1uAMA3a Avx8XFVns6HJxxvyvdN+ =TsEr -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 2 20:43:20 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F608CA1 for ; Thu, 2 Oct 2014 20:43:20 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 278F0E80 for ; Thu, 2 Oct 2014 20:43:20 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XZnDX-000Ak8-9W; Fri, 03 Oct 2014 00:43:15 +0400 Date: Fri, 3 Oct 2014 00:43:15 +0400 From: Slawa Olhovchenkov To: Peter Jeremy Subject: Re: Removing disconnected tty drivers Message-ID: <20141002204315.GB45169@zxy.spb.ru> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <20141001175952.GZ43300@funkthat.com> <20141001185011.GA12174@server.rulingia.com> <20141002123351.GA9212@zxy.spb.ru> <20141002200636.GK20707@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002200636.GK20707@server.rulingia.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:43:20 -0000 On Fri, Oct 03, 2014 at 06:06:36AM +1000, Peter Jeremy wrote: > On 2014-Oct-02 16:33:52 +0400, Slawa Olhovchenkov wrote: > >As I remember ISA/EISA and PCI different only in interrupt path. > >All other logic is common. > > From memory, the actual board access is different as well - the ISA > boards have a memory-mapped window and you need to move the window > around. The PCI boards linearly map the board's entire memory space. All cards have different window size. In PCI case windows size == memory size. Also, ISA PC/Xi have windows size == memory size. This is not significant difference. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 3 08:49:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28212AB5; Fri, 3 Oct 2014 08:49:25 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D66E1BCD; Fri, 3 Oct 2014 08:49:24 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XZyYB-000L3p-NR; Fri, 03 Oct 2014 12:49:19 +0400 Date: Fri, 3 Oct 2014 12:49:19 +0400 From: Slawa Olhovchenkov To: John Baldwin Subject: Re: Removing disconnected tty drivers Message-ID: <20141003084919.GA79756@zxy.spb.ru> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <201410021119.37723.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201410021119.37723.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:49:25 -0000 On Thu, Oct 02, 2014 at 11:19:37AM -0400, John Baldwin wrote: > On Wednesday, October 01, 2014 6:03:53 am Peter Jeremy wrote: > > On 2014-Sep-29 11:53:53 -0400, John Baldwin wrote: > > >The following drivers have never been converted to use the new tty layer > > >introduced in 8.0 and have been disconnected since then. Several of them are > > >for older multiport serial cards, and in the case of sio(4), current kernels > > >use uart(4) instead. Barring major objections, I plan to remove them from the > > >tree later this week. If someone wishes to update them, they can always be > > >pulled back from svn history. > > > > > >dev/digi/digi.c: tp = port->tp = ttyalloc(); > > > > See > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152253 > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158086 > > unfortunately, I no longer have access to the hardware. I'm happy to > > update the patches to compile on -current but can't do more than that. > > The second one was tested by another submitter, so if you want to spend the > time, please update them and see if you can get someone to test them. To be > honest, I would be happy to drop ISA support and just keep PCI support if > that is simpler. Most difference between ISA/EISA and PCI at initialise time (and most difference between models, not buses). After initialization all code is common. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 3 20:13:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6D69557; Fri, 3 Oct 2014 20:13:31 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C390F63; Fri, 3 Oct 2014 20:13:30 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id s93KDFMJ004915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 4 Oct 2014 06:13:20 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id s93KDAHn013726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Oct 2014 06:13:10 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id s93KDA7G013725; Sat, 4 Oct 2014 06:13:10 +1000 (EST) (envelope-from peter) Date: Sat, 4 Oct 2014 06:13:10 +1000 From: Peter Jeremy To: John Baldwin Subject: Re: Removing disconnected tty drivers Message-ID: <20141003201310.GC12174@server.rulingia.com> References: <1789815.bS8Ac2qsJ6@ralph.baldwin.cx> <20141001100353.GF20707@server.rulingia.com> <201410021119.37723.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <201410021119.37723.jhb@freebsd.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:13:32 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2014-Oct-02 11:19:37 -0400, John Baldwin wrote: >On Wednesday, October 01, 2014 6:03:53 am Peter Jeremy wrote: >> On 2014-Sep-29 11:53:53 -0400, John Baldwin wrote: >> >The following drivers have never been converted to use the new tty laye= r=20 >> >introduced in 8.0 and have been disconnected since then. Several of th= em are=20 >> >for older multiport serial cards, and in the case of sio(4), current ke= rnels=20 >> >use uart(4) instead. Barring major objections, I plan to remove them f= rom the=20 >> >tree later this week. If someone wishes to update them, they can alway= s be=20 >> >pulled back from svn history. >> > >> >dev/digi/digi.c: tp =3D port->tp =3D ttyalloc(); >>=20 >> See >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D152253 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D158086 >> unfortunately, I no longer have access to the hardware. I'm happy to >> update the patches to compile on -current but can't do more than that. > >The second one was tested by another submitter, so if you want to spend the >time, please update them and see if you can get someone to test them. To = be >honest, I would be happy to drop ISA support and just keep PCI support if >that is simpler. The patches in kern/158086 subsume those in kern/152253 and it builds (at least on amd64) at head r272410. All we need is someone with the hardware. My biggest concern with the ISA code is that there is no locking around all the window twiddling. =20 --=20 Peter Jeremy --l76fUT7nc3MelDdI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJULwNWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0PmsP/02GYI9iXiZ+d14RJBcbJAXE kg7JOFADcsdW0jY9zIgsZYXszXdbwmhKXPAPKwAPbVnfF0kWP7k/CEkjbVOsV/U0 WBuovwvQZSXz6eZNI4pZb8NdYoIqJ6SmF4bwd/NLM5IWv7vHDPniMG2/e//63BJp n1JS+WXKgsZ8bDzkjzkCZc43WZJ1UivD1KDp3JPQewP2SHHn8dm5aWueJIVjIkCC A2Zu5QDySRGBJBYqF8m0NqNcXk64tUU0PL42cFoe0Lzaws0gxVa6R/q3g2T1uxgS njeVEzMJHRWqBbtuY08afq9UuRlIAU/AEb8fYFM333DzwmU+xA9mrMtHVNZQOrx1 lZCpT0xUX7Eg4hKCFyIMWW3vQMYROdnqt5swSclBTf2cWxYmPyeDZcpGxkuLoIp4 WGjE70q48xHxW7jKRQqtqn5RQFbmtJCUvI6TizlRad/1aDhoS3+TS7sRzwMGPNzg cLR3xi1Bs1/BGiNi8X4DxsA3SQhU1wZFPSaPjwOXnf+zK/x3Hust5F6AqnLgP+Ax ZSUh/h8ykx/58tNI2apcg6dbZf/vHVmaWU3K4qCQFZgfPakRsqgGDASJSTizIfuh 9zzaaW2SIAeZ9CQauZl5+66IcpKvLw9oYYcz2+1cXnLG5wjaeRcjsAK7EK8Z0MIj SPW/WxdKF2wsrWuzXC9P =YSod -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 05:28:57 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97CDD122; Sat, 4 Oct 2014 05:28:57 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1B14EB; Sat, 4 Oct 2014 05:28:56 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id n3so543007wiv.3 for ; Fri, 03 Oct 2014 22:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=tmR1lACNoNWKjFrxzkamfRTEbWVllEQjLqMV0iLSzMc=; b=hl2f+8WszAh4Ox+TxMpwOZy3S/f0w15UaJ+dMAJnM/klxoTFE0M7FAUflAjL09jbFg t3zrk2r6VpkuuLVKazrJmyS6jq/E8Gu/gilzp/81CeHyKZDW4FvNBze2mgtL2ZcJZxud MOgmLtfs2F+inaXHsuAHfZvWQi5yv/be4tiYFHdBcYZgPUdJBwWVOxX7Gx1Drn7PPXPM dPiNC7TklgBHCj+V1Z0DPHet+XM1hWFqRPjIlZECsGlQuDXW+lp+Eo0DQWZvz1WOXIeS o4XFbLEE+7I41iV6uiAw/YUAO3U3MQ4Irny5YXJQ1w5WzvBvwp2DtJAVeKnxTZJ6W3nR 8Q9A== X-Received: by 10.194.120.138 with SMTP id lc10mr12230208wjb.55.1412400534872; Fri, 03 Oct 2014 22:28:54 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id eg8sm3978832wib.15.2014.10.03.22.28.53 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 03 Oct 2014 22:28:53 -0700 (PDT) Date: Sat, 4 Oct 2014 07:28:51 +0200 From: Mateusz Guzik To: alc@freebsd.org Subject: Re: [PATCH 1/2] Implement simple sequence counters with memory barriers. Message-ID: <20141004052851.GA27891@dft-labs.eu> References: <1408064112-573-1-git-send-email-mjguzik@gmail.com> <1408064112-573-2-git-send-email-mjguzik@gmail.com> <20140816093811.GX2737@kib.kiev.ua> <20140816185406.GD2737@kib.kiev.ua> <20140817012646.GA21025@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , attilio@freebsd.org, Johan Schuijt , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 05:28:57 -0000 Reviving. Sorry everyone for such big delay, $life. On Tue, Aug 19, 2014 at 02:24:16PM -0500, Alan Cox wrote: > On Sat, Aug 16, 2014 at 8:26 PM, Mateusz Guzik wrote: > > Well, my memory-barrier-and-so-on-fu is rather weak. > > > > I had another look at the issue. At least on amd64, it looks like only > > compiler barrier is required for both reads and writes. > > > > According to AMD64 Architecture Programmer’s Manual Volume 2: System > > Programming, 7.2 Multiprocessor Memory Access Ordering states: > > > > "Loads do not pass previous loads (loads are not reordered). Stores do > > not pass previous stores (stores are not reordered)" > > > > Since the code modifying stuff only performs a series of writes and we > > expect exclusive writers, I find it applicable to this scenario. > > > > I checked linux sources and generated assembly, they indeed issue only > > a compiler barrier on amd64 (and for intel processors as well). > > > > atomic_store_rel_int on amd64 seems fine in this regard, but the only > > function for loads issues lock cmpxhchg which kills performance > > (median 55693659 -> 12789232 ops in a microbenchmark) for no gain. > > > > Additionally release and acquire semantics seems to be a stronger than > > needed guarantee. > > > > > > This statement left me puzzled and got me to look at our x86 atomic.h for > the first time in years. It appears that our implementation of > atomic_load_acq_int() on x86 is, umm ..., unconventional. That is, it is > enforcing a constraint that simple acquire loads don't normally enforce. > For example, the C11 stdatomic.h simple acquire load doesn't enforce this > constraint. Moreover, our own implementation of atomic_load_acq_int() on > ia64, where the mapping from atomic_load_acq_int() to machine instructions > is straightforward, doesn't enforce this constraint either. > By 'this constraint' I presume you mean full memory barrier. It is unclear to me if one can just get rid of it currently. It definitely would be beneficial. In the meantime, if for some reason full barrier is still needed, we can speed up concurrent load_acq of the same var considerably. There is no need to lock cmpxchg on the same address. We should be able to replace it with +/-: lock add $0,(%rsp); movl ...; I believe it is possible that cpu will perform some writes before doing read listed here, but this should be fine. If this is considered too risky to hit 10.1, I would like to implement it within seq as a temporary hack to be fixed up later. something along: static inline int atomic_load_acq_rmb(volatile u_int *p) { volaitle u_int *v; v = *p; atomic_load_acq(&v); return (v); } This hack fixes aforementioned performance degradation and covers all architectures. > Give us a chance to sort this out before you do anything further. As > Kostik said, but in different words, we've always written our > machine-independent layer code using acquires and releases to express the > required ordering constraints and not {r,w}mb() primitives. > -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 07:11:45 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58A4026D; Sat, 4 Oct 2014 07:11:45 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5C5EC46; Sat, 4 Oct 2014 07:11:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s947BdnI010516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 10:11:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s947BdnI010516 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s947BdF0010515; Sat, 4 Oct 2014 10:11:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Oct 2014 10:11:39 +0300 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: [PATCH 1/2] Implement simple sequence counters with memory barriers. Message-ID: <20141004071139.GL26076@kib.kiev.ua> References: <1408064112-573-1-git-send-email-mjguzik@gmail.com> <1408064112-573-2-git-send-email-mjguzik@gmail.com> <20140816093811.GX2737@kib.kiev.ua> <20140816185406.GD2737@kib.kiev.ua> <20140817012646.GA21025@dft-labs.eu> <20141004052851.GA27891@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141004052851.GA27891@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: alc@freebsd.org, attilio@freebsd.org, Johan Schuijt , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 07:11:45 -0000 On Sat, Oct 04, 2014 at 07:28:51AM +0200, Mateusz Guzik wrote: > Reviving. Sorry everyone for such big delay, $life. > > On Tue, Aug 19, 2014 at 02:24:16PM -0500, Alan Cox wrote: > > On Sat, Aug 16, 2014 at 8:26 PM, Mateusz Guzik wrote: > > > Well, my memory-barrier-and-so-on-fu is rather weak. > > > > > > I had another look at the issue. At least on amd64, it looks like only > > > compiler barrier is required for both reads and writes. > > > > > > According to AMD64 Architecture Programmer???s Manual Volume 2: System > > > Programming, 7.2 Multiprocessor Memory Access Ordering states: > > > > > > "Loads do not pass previous loads (loads are not reordered). Stores do > > > not pass previous stores (stores are not reordered)" > > > > > > Since the code modifying stuff only performs a series of writes and we > > > expect exclusive writers, I find it applicable to this scenario. > > > > > > I checked linux sources and generated assembly, they indeed issue only > > > a compiler barrier on amd64 (and for intel processors as well). > > > > > > atomic_store_rel_int on amd64 seems fine in this regard, but the only > > > function for loads issues lock cmpxhchg which kills performance > > > (median 55693659 -> 12789232 ops in a microbenchmark) for no gain. > > > > > > Additionally release and acquire semantics seems to be a stronger than > > > needed guarantee. > > > > > > > > > > This statement left me puzzled and got me to look at our x86 atomic.h for > > the first time in years. It appears that our implementation of > > atomic_load_acq_int() on x86 is, umm ..., unconventional. That is, it is > > enforcing a constraint that simple acquire loads don't normally enforce. > > For example, the C11 stdatomic.h simple acquire load doesn't enforce this > > constraint. Moreover, our own implementation of atomic_load_acq_int() on > > ia64, where the mapping from atomic_load_acq_int() to machine instructions > > is straightforward, doesn't enforce this constraint either. > > > > By 'this constraint' I presume you mean full memory barrier. > > It is unclear to me if one can just get rid of it currently. It > definitely would be beneficial. > > In the meantime, if for some reason full barrier is still needed, we can > speed up concurrent load_acq of the same var considerably. There is no > need to lock cmpxchg on the same address. We should be able to replace > it with +/-: > lock add $0,(%rsp); > movl ...; > > I believe it is possible that cpu will perform some writes before doing > read listed here, but this should be fine. > > If this is considered too risky to hit 10.1, I would like to implement > it within seq as a temporary hack to be fixed up later. > > something along: > static inline int > atomic_load_acq_rmb(volatile u_int *p) > { > volaitle u_int *v; > > v = *p; > atomic_load_acq(&v); > return (v); > } Do you need it as designated primitive ? I think you could write this inline for the purpose of getting the fix into 10.1. With the inline quirk, I think that the fix should go into the HEAD now, with some reasonable MFC timer. > > This hack fixes aforementioned performance degradation and covers all > architectures. > > > Give us a chance to sort this out before you do anything further. As > > Kostik said, but in different words, we've always written our > > machine-independent layer code using acquires and releases to express the > > required ordering constraints and not {r,w}mb() primitives. > > > > -- > Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 07:40:56 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ADC6CC7; Sat, 4 Oct 2014 07:40:56 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2298CDF5; Sat, 4 Oct 2014 07:40:54 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x13so3048410wgg.18 for ; Sat, 04 Oct 2014 00:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=UoGVXadj9OtpFOgg790yonjvLS0iBPVKW4fX1U8dpEs=; b=Bq91ld8oXLZGH6ufUjL28nmpDteZy11rQnmK8tPVVAOvo2MTYosOle7tTdKUbHkyVT s0PkcPsMA7IL7wVt9Eg9ac7ZQ5eSgjEaWM/iqF4C7GZlVAJrzHSZNqpY3VmJpeVchN4q Bj5Fv1i1wNZq4yR46HOyS9OvTuVyB8yDIx9dT19VzgIaxBtvTf+HvMTrx8j8+EvZa7GE VJ0XIOQnbcfd5nLSu4oAr7zpAvdkoS4fvzf+8kHrMhPvU6Tnh7vblsP0QnGMkVijVTM2 NnI1hjop1Gvr+SyHhtBhMnh4URsEKIiUtQvcPhFiRRQIj4Aou/WX5AL5Sy8B7Rjd17Tk 3Njw== X-Received: by 10.180.101.70 with SMTP id fe6mr3716257wib.37.1412408453465; Sat, 04 Oct 2014 00:40:53 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id dc9sm4243920wib.5.2014.10.04.00.40.52 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 04 Oct 2014 00:40:52 -0700 (PDT) Date: Sat, 4 Oct 2014 09:40:50 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH 1/2] Implement simple sequence counters with memory barriers. Message-ID: <20141004074049.GA17491@dft-labs.eu> References: <1408064112-573-1-git-send-email-mjguzik@gmail.com> <1408064112-573-2-git-send-email-mjguzik@gmail.com> <20140816093811.GX2737@kib.kiev.ua> <20140816185406.GD2737@kib.kiev.ua> <20140817012646.GA21025@dft-labs.eu> <20141004052851.GA27891@dft-labs.eu> <20141004071139.GL26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141004071139.GL26076@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: alc@freebsd.org, attilio@freebsd.org, Johan Schuijt , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 07:40:56 -0000 On Sat, Oct 04, 2014 at 10:11:39AM +0300, Konstantin Belousov wrote: > On Sat, Oct 04, 2014 at 07:28:51AM +0200, Mateusz Guzik wrote: > > Reviving. Sorry everyone for such big delay, $life. > > > > On Tue, Aug 19, 2014 at 02:24:16PM -0500, Alan Cox wrote: > > > On Sat, Aug 16, 2014 at 8:26 PM, Mateusz Guzik wrote: > > > > Well, my memory-barrier-and-so-on-fu is rather weak. > > > > > > > > I had another look at the issue. At least on amd64, it looks like only > > > > compiler barrier is required for both reads and writes. > > > > > > > > According to AMD64 Architecture Programmer???s Manual Volume 2: System > > > > Programming, 7.2 Multiprocessor Memory Access Ordering states: > > > > > > > > "Loads do not pass previous loads (loads are not reordered). Stores do > > > > not pass previous stores (stores are not reordered)" > > > > > > > > Since the code modifying stuff only performs a series of writes and we > > > > expect exclusive writers, I find it applicable to this scenario. > > > > > > > > I checked linux sources and generated assembly, they indeed issue only > > > > a compiler barrier on amd64 (and for intel processors as well). > > > > > > > > atomic_store_rel_int on amd64 seems fine in this regard, but the only > > > > function for loads issues lock cmpxhchg which kills performance > > > > (median 55693659 -> 12789232 ops in a microbenchmark) for no gain. > > > > > > > > Additionally release and acquire semantics seems to be a stronger than > > > > needed guarantee. > > > > > > > > > > > > > > This statement left me puzzled and got me to look at our x86 atomic.h for > > > the first time in years. It appears that our implementation of > > > atomic_load_acq_int() on x86 is, umm ..., unconventional. That is, it is > > > enforcing a constraint that simple acquire loads don't normally enforce. > > > For example, the C11 stdatomic.h simple acquire load doesn't enforce this > > > constraint. Moreover, our own implementation of atomic_load_acq_int() on > > > ia64, where the mapping from atomic_load_acq_int() to machine instructions > > > is straightforward, doesn't enforce this constraint either. > > > > > > > By 'this constraint' I presume you mean full memory barrier. > > > > It is unclear to me if one can just get rid of it currently. It > > definitely would be beneficial. > > > > In the meantime, if for some reason full barrier is still needed, we can > > speed up concurrent load_acq of the same var considerably. There is no > > need to lock cmpxchg on the same address. We should be able to replace > > it with +/-: > > lock add $0,(%rsp); > > movl ...; > > > > I believe it is possible that cpu will perform some writes before doing > > read listed here, but this should be fine. > > > > If this is considered too risky to hit 10.1, I would like to implement > > it within seq as a temporary hack to be fixed up later. > > > > something along: > > static inline int > > atomic_load_acq_rmb(volatile u_int *p) > > { > > volaitle u_int *v; > > > > v = *p; > > atomic_load_acq(&v); > > return (v); > > } > Do you need it as designated primitive ? I think you could write this > inline for the purpose of getting the fix into 10.1. > > With the inline quirk, I think that the fix should go into the HEAD > now, with some reasonable MFC timer. Well, proposed seq.h is here: https://people.freebsd.org/~mjg/seq.h Note it uses atomic_add_{acq,rel}_int for lack of appropriate _store_acq. This is temporary as well. I also do realize atomic_load_acq_rmb_int sounds at least weird, but well... And here is the rest of the patch just in case: https://people.freebsd.org/~mjg/plug-caps-race.diff -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 08:11:14 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98BE5BE6; Sat, 4 Oct 2014 08:11:14 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2C0212B; Sat, 4 Oct 2014 08:11:13 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so689340wib.9 for ; Sat, 04 Oct 2014 01:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=UpQZ96dAkgbs8w6T/ochgxr6pGsklMqJwyMRoivW73E=; b=bVzyTUCV/jQ9DfJwnWCAoIY2etk9lN+JRbr7XjWoRf6blKUE8gEFzGl1QvJQDtbHZz K7UoA6jVK5UWwMroQajXYOpOkWtvN83kM5k7W8O8aN9dtXqy3/ffJtuFeO1pCozSZefu hcdg2GwZgI0hvEQ58RqYn7Xga7bGp3GDYYXQTOFTdkvFKXxDfvD/Zv3UYFT6ESGuZ3ES oauvtDZvy2ZqDYQrONm0JDvqomlTUlT18x+cVCp69Qi+OWT+xVG64sXQxBoUv3gP5WPJ le7pRUThfR1IBgS6v2R+PY6hIBX9pNmuCFIh3X0ViTtJ8s1+Nr8BU9+Ch5AdQ1jn7BWy K4kQ== X-Received: by 10.180.188.49 with SMTP id fx17mr3949028wic.17.1412410271986; Sat, 04 Oct 2014 01:11:11 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hp2sm9510160wjb.40.2014.10.04.01.11.10 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 04 Oct 2014 01:11:11 -0700 (PDT) Date: Sat, 4 Oct 2014 10:11:08 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: [PATCH 1/2] Implement simple sequence counters with memory barriers. Message-ID: <20141004081108.GB17491@dft-labs.eu> References: <1408064112-573-1-git-send-email-mjguzik@gmail.com> <1408064112-573-2-git-send-email-mjguzik@gmail.com> <20140816093811.GX2737@kib.kiev.ua> <20140816185406.GD2737@kib.kiev.ua> <20140817012646.GA21025@dft-labs.eu> <20141004052851.GA27891@dft-labs.eu> <20141004071139.GL26076@kib.kiev.ua> <20141004074049.GA17491@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141004074049.GA17491@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: alc@freebsd.org, attilio@freebsd.org, Johan Schuijt , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:11:14 -0000 On Sat, Oct 04, 2014 at 09:40:50AM +0200, Mateusz Guzik wrote: > On Sat, Oct 04, 2014 at 10:11:39AM +0300, Konstantin Belousov wrote: > > On Sat, Oct 04, 2014 at 07:28:51AM +0200, Mateusz Guzik wrote: > > > Reviving. Sorry everyone for such big delay, $life. > > > > > > On Tue, Aug 19, 2014 at 02:24:16PM -0500, Alan Cox wrote: > > > > On Sat, Aug 16, 2014 at 8:26 PM, Mateusz Guzik wrote: > > > > > Well, my memory-barrier-and-so-on-fu is rather weak. > > > > > > > > > > I had another look at the issue. At least on amd64, it looks like only > > > > > compiler barrier is required for both reads and writes. > > > > > > > > > > According to AMD64 Architecture Programmer???s Manual Volume 2: System > > > > > Programming, 7.2 Multiprocessor Memory Access Ordering states: > > > > > > > > > > "Loads do not pass previous loads (loads are not reordered). Stores do > > > > > not pass previous stores (stores are not reordered)" > > > > > > > > > > Since the code modifying stuff only performs a series of writes and we > > > > > expect exclusive writers, I find it applicable to this scenario. > > > > > > > > > > I checked linux sources and generated assembly, they indeed issue only > > > > > a compiler barrier on amd64 (and for intel processors as well). > > > > > > > > > > atomic_store_rel_int on amd64 seems fine in this regard, but the only > > > > > function for loads issues lock cmpxhchg which kills performance > > > > > (median 55693659 -> 12789232 ops in a microbenchmark) for no gain. > > > > > > > > > > Additionally release and acquire semantics seems to be a stronger than > > > > > needed guarantee. > > > > > > > > > > > > > > > > > > This statement left me puzzled and got me to look at our x86 atomic.h for > > > > the first time in years. It appears that our implementation of > > > > atomic_load_acq_int() on x86 is, umm ..., unconventional. That is, it is > > > > enforcing a constraint that simple acquire loads don't normally enforce. > > > > For example, the C11 stdatomic.h simple acquire load doesn't enforce this > > > > constraint. Moreover, our own implementation of atomic_load_acq_int() on > > > > ia64, where the mapping from atomic_load_acq_int() to machine instructions > > > > is straightforward, doesn't enforce this constraint either. > > > > > > > > > > By 'this constraint' I presume you mean full memory barrier. > > > > > > It is unclear to me if one can just get rid of it currently. It > > > definitely would be beneficial. > > > > > > In the meantime, if for some reason full barrier is still needed, we can > > > speed up concurrent load_acq of the same var considerably. There is no > > > need to lock cmpxchg on the same address. We should be able to replace > > > it with +/-: > > > lock add $0,(%rsp); > > > movl ...; > > > > > > I believe it is possible that cpu will perform some writes before doing > > > read listed here, but this should be fine. > > > > > > If this is considered too risky to hit 10.1, I would like to implement > > > it within seq as a temporary hack to be fixed up later. > > > > > > something along: > > > static inline int > > > atomic_load_acq_rmb(volatile u_int *p) > > > { > > > volaitle u_int *v; > > > > > > v = *p; > > > atomic_load_acq(&v); > > > return (v); > > > } > > Do you need it as designated primitive ? I think you could write this > > inline for the purpose of getting the fix into 10.1. > > > > With the inline quirk, I think that the fix should go into the HEAD > > now, with some reasonable MFC timer. > > Well, proposed seq.h is here: > https://people.freebsd.org/~mjg/seq.h > > Note it uses atomic_add_{acq,rel}_int for lack of appropriate > _store_acq. This is temporary as well. > > I also do realize atomic_load_acq_rmb_int sounds at least weird, but > well... > > And here is the rest of the patch just in case: > https://people.freebsd.org/~mjg/plug-caps-race.diff > After a short off-list discussion committed as https://svnweb.freebsd.org/base?view=revision&revision=272503 and https://svnweb.freebsd.org/base?view=revision&revision=272505 respectively. -- Mateusz Guzik From owner-freebsd-arch@FreeBSD.ORG Sat Oct 4 09:37:19 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6310F2AE; Sat, 4 Oct 2014 09:37:19 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4087AF7; Sat, 4 Oct 2014 09:37:18 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so776038wib.15 for ; Sat, 04 Oct 2014 02:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Ii9f544oQnFb0MX0RpKEem1vRD7GJGrztIE5zxlDeKE=; b=OK3Qa9ia9wRiZMYGDre9tA64z4ipk9qqF2qAw/6R6YQjusLQvCSQq2yPc/wXZNsiNp 6DzJpfxfeFVg/W9l3NrTKxwWRigxLlEzarkGZc9WTtJgUxIuc8QxZveJ29tcNShKDSNT jO6uk3K8gmafwC9ZvVpVfXW0TkUJA39MB0rHdG+o/4YIZLBz3UcPckr1d23TNXByliNu yYJBU3JwgY3O4MFVDapabrveVCHTTruoFfR+oLXq7sFo0ZutcEmz/DYJ3ZV1FEQXXooQ xQ1zgH9VoAJ6dm2ni1G1WJdTTarPXfBFff4ArFNwG8LHLWJrWU8DhjQB49XaDeTVp1+1 aSxQ== MIME-Version: 1.0 X-Received: by 10.194.223.2 with SMTP id qq2mr1680120wjc.122.1412415437023; Sat, 04 Oct 2014 02:37:17 -0700 (PDT) Reply-To: attilio@FreeBSD.org Sender: asmrookie@gmail.com Received: by 10.217.39.135 with HTTP; Sat, 4 Oct 2014 02:37:16 -0700 (PDT) In-Reply-To: <20141004052851.GA27891@dft-labs.eu> References: <1408064112-573-1-git-send-email-mjguzik@gmail.com> <1408064112-573-2-git-send-email-mjguzik@gmail.com> <20140816093811.GX2737@kib.kiev.ua> <20140816185406.GD2737@kib.kiev.ua> <20140817012646.GA21025@dft-labs.eu> <20141004052851.GA27891@dft-labs.eu> Date: Sat, 4 Oct 2014 11:37:16 +0200 X-Google-Sender-Auth: VALReNx5CyBY7rx0KgSeiYj7VNc Message-ID: Subject: Re: [PATCH 1/2] Implement simple sequence counters with memory barriers. From: Attilio Rao To: Mateusz Guzik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , Konstantin Belousov , Johan Schuijt , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 09:37:19 -0000 On Sat, Oct 4, 2014 at 7:28 AM, Mateusz Guzik wrote: > Reviving. Sorry everyone for such big delay, $life. > > On Tue, Aug 19, 2014 at 02:24:16PM -0500, Alan Cox wrote: >> On Sat, Aug 16, 2014 at 8:26 PM, Mateusz Guzik wrote= : >> > Well, my memory-barrier-and-so-on-fu is rather weak. >> > >> > I had another look at the issue. At least on amd64, it looks like only >> > compiler barrier is required for both reads and writes. >> > >> > According to AMD64 Architecture Programmer=E2=80=99s Manual Volume 2: = System >> > Programming, 7.2 Multiprocessor Memory Access Ordering states: >> > >> > "Loads do not pass previous loads (loads are not reordered). Stores do >> > not pass previous stores (stores are not reordered)" >> > >> > Since the code modifying stuff only performs a series of writes and we >> > expect exclusive writers, I find it applicable to this scenario. >> > >> > I checked linux sources and generated assembly, they indeed issue only >> > a compiler barrier on amd64 (and for intel processors as well). >> > >> > atomic_store_rel_int on amd64 seems fine in this regard, but the only >> > function for loads issues lock cmpxhchg which kills performance >> > (median 55693659 -> 12789232 ops in a microbenchmark) for no gain. >> > >> > Additionally release and acquire semantics seems to be a stronger than >> > needed guarantee. >> > >> > >> >> This statement left me puzzled and got me to look at our x86 atomic.h fo= r >> the first time in years. It appears that our implementation of >> atomic_load_acq_int() on x86 is, umm ..., unconventional. That is, it i= s >> enforcing a constraint that simple acquire loads don't normally enforce. >> For example, the C11 stdatomic.h simple acquire load doesn't enforce thi= s >> constraint. Moreover, our own implementation of atomic_load_acq_int() o= n >> ia64, where the mapping from atomic_load_acq_int() to machine instructio= ns >> is straightforward, doesn't enforce this constraint either. >> > > By 'this constraint' I presume you mean full memory barrier. > > It is unclear to me if one can just get rid of it currently. It > definitely would be beneficial. > > In the meantime, if for some reason full barrier is still needed, we can > speed up concurrent load_acq of the same var considerably. There is no > need to lock cmpxchg on the same address. We should be able to replace > it with +/-: > lock add $0,(%rsp); > movl ...; When I looked into some AMD manual (I think the same one which reports using lock add $0, (%rsp)) I recall that the (reported) added instructions latencies of "lock add" + "movl" is superior than the single "cmpxchg". Moreover, I think that the simple movl is going to lock the cache-line anyway, so I doubt the "lock add" is going to provide any benefit. The only benefit I can think of is that we will be able to use an _acq() barriers on read-only memory with this trick (which is not possible today as timecounters code can testify). If the latencies for "lock add" + "movl" is changed in the latest Intel processors I can't say for sure, it may be worth to look at it. Attilio --=20 Peace can only be achieved by understanding - A. Einstein