From owner-freebsd-current@FreeBSD.ORG Sun May 10 06:10:55 2015 Return-Path: Delivered-To: freebsd-current@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 CB118BD7 for ; Sun, 10 May 2015 06:10:55 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B9C981332 for ; Sun, 10 May 2015 06:10:55 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9CEAD1F8 for ; Sun, 10 May 2015 06:10:55 +0000 (UTC) Date: Sun, 10 May 2015 06:10:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <141152756.2.1431238255363.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #1023 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 06:10:55 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun May 10 12:47:10 2015 Return-Path: Delivered-To: freebsd-current@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 9D6F63C6 for ; Sun, 10 May 2015 12:47:10 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 5B180198D for ; Sun, 10 May 2015 12:47:10 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 650141FE023; Sun, 10 May 2015 14:47:08 +0200 (CEST) Message-ID: <554F5379.2070100@selasky.org> Date: Sun, 10 May 2015 14:47:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Wolfgang Zenker , freebsd-current@freebsd.org Subject: Re: Race VT+X11 on -current References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> <20150509210525.GA80848@lyxys.ka.sub.org> In-Reply-To: <20150509210525.GA80848@lyxys.ka.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 12:47:10 -0000 On 05/09/15 23:05, Wolfgang Zenker wrote: > * Allan Jude [150508 16:29]: >> [..] >> My experience is a little different. > >> When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) > >> Sometimes when I resume, it seems like the keyboard is frozen. If I >> alt+f1, then alt+f9, it seems to work fine after that. I'd never though >> of trying just alt+f9 right away, as I could already see my X session. > >> Not sure if this is related, but it sounds very similar. > > Similar problem on 10-STABLE: I usually start X by running startx > on ttyv0. After exiting X screen shows ttyv0 again but keyboard > appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to > ttyv1 and back "unfreezes" keyboard. Can you try applying to 10-stable: https://svnweb.freebsd.org/changeset/base/282645 --HPS From owner-freebsd-current@FreeBSD.ORG Sun May 10 13:03:43 2015 Return-Path: Delivered-To: freebsd-current@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 21FE0687; Sun, 10 May 2015 13:03:43 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B11EC1BA0; Sun, 10 May 2015 13:03:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwBkVk9V/95baINcg2NeBoMYwUUJgU4KhTdOAoFRFAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCwUWDgoCAg0ZAikBCSYGCAcEARwEiAMIDbNZknQBAQEBAQEBAQEBAQEBAQEBAQEBGYEhihiEMwEBHDQHgmiBRQWWW4JGgU2DVj6DHIdqIoIGh0cjggkcgW4iMQEBAQEDgQU5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,401,1427774400"; d="scan'208";a="211910200" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 10 May 2015 09:03:25 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 192A3B3F04; Sun, 10 May 2015 09:03:25 -0400 (EDT) Date: Sun, 10 May 2015 09:03:25 -0400 (EDT) From: Rick Macklem To: Doug Rabson Cc: freebsd current , Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , David Boyd49 Message-ID: <581797832.35173877.1431263005089.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: nmount, mountd drops high order MNT_xx flags during a mount update MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 13:03:43 -0000 Doug Rabson wrote: > You could add a single integer-valued vfsopt which holds the > high-order > bits of f_flags? > I have created a patch that does this. It is on https://reviews.freebsd.org/D2506 (I have also attached it here, for those who don't use Phabricator.) Please review/comment on this. (Feel free to add yourself as a reviewer, etc.) Also, David, if you can test this patch, it would be appreciated. Thanks for the suggestion Doug, rick > On 7 May 2015 at 02:10, Rick Macklem wrote: > > > David Boyd reported a problem to freebsd-current@ w.r.t. the > > MNT_AUTOMOUNTED > > flag getting cleared by mountd. > > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > I just took a look at this and it's kinda ugly... > > > > mountd acquires a list of mounts via getmntinfo() and then does an > > nmount() for each of them to get rid of any exports. It uses > > f_flags from the statfs returned by getmntinfo() as the 3rd > > argument to nmount(). > > --> Since nmount()s 3rd argument is a "int", it silently drops any > > MNT_xx flag in the high order 32bits of f_flags. At this time, > > it happens that MNT_AUTOMOUNTED is the only one, but... > > > > I can think of a couple of ways to fix this, but I don't like any > > of > > them;-) > > > > 1) I suppose mountd could check for each flag set in f_flags and > > generate > > a vfsopts string for it, but that means that every time a new flag > > that > > can be updated is added to MNT_xx, this mountd.c code would have to > > updated. > > --> Ugly!! > > > > 2) Require that all flags in MNT_UPDATEMASK be in the low order > > 32bits. > > I wouldn`t mind this except in means that the MNT_xx flags must > > be > > redefined > > and I don`t think that could get MFC`d. > > > > 3) Add a new newernmount(2) which has a 64bit flags argument > > instead of > > int. > > > > Hopefully someone can think of a nice way to fix this, rick > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun May 10 13:08:08 2015 Return-Path: Delivered-To: freebsd-current@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 3DB247BA; Sun, 10 May 2015 13:08:08 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C64B61BC2; Sun, 10 May 2015 13:08:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+AwA4CE9V/95baINcg2NeBoMYwUQJgU4KhTdOAoFVFAEBAQEBAQGBCoQgAQEBBAEBASAEJyALDA8OChEZAgQlAQkmBggHBAEcBIgLDbNXknoBAQEBAQEBAQEBAQEBAQEBAQEBARiLOYQzAQEcGRsHgmiBRQWLMYkRghmCRoFNg1Y+gxyHaiKCBodHI4IJHIFuIjEBAQEBA3wJFwMfgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,401,1427774400"; d="scan'208";a="210090147" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 10 May 2015 09:07:58 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6DFD3B42F8; Sun, 10 May 2015 09:07:54 -0400 (EDT) Date: Sun, 10 May 2015 09:07:54 -0400 (EDT) From: Rick Macklem To: Doug Rabson Cc: freebsd current , Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , David Boyd49 Message-ID: <917688730.35175530.1431263274444.JavaMail.root@uoguelph.ca> In-Reply-To: <581797832.35173877.1431263005089.JavaMail.root@uoguelph.ca> Subject: Re: nmount, mountd drops high order MNT_xx flags during a mount update MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_35175528_844751710.1431263274441" X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 13:08:08 -0000 ------=_Part_35175528_844751710.1431263274441 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Oops, I did my usual and forgot to attach the patch. Here it is, rick ----- Original Message ----- > Doug Rabson wrote: > > You could add a single integer-valued vfsopt which holds the > > high-order > > bits of f_flags? > > > I have created a patch that does this. It is on > https://reviews.freebsd.org/D2506 > (I have also attached it here, for those who don't use Phabricator.) > > Please review/comment on this. (Feel free to add yourself as a > reviewer, etc.) > > Also, David, if you can test this patch, it would be appreciated. > > Thanks for the suggestion Doug, rick > > > On 7 May 2015 at 02:10, Rick Macklem wrote: > > > > > David Boyd reported a problem to freebsd-current@ w.r.t. the > > > MNT_AUTOMOUNTED > > > flag getting cleared by mountd. > > > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > > I just took a look at this and it's kinda ugly... > > > > > > mountd acquires a list of mounts via getmntinfo() and then does > > > an > > > nmount() for each of them to get rid of any exports. It uses > > > f_flags from the statfs returned by getmntinfo() as the 3rd > > > argument to nmount(). > > > --> Since nmount()s 3rd argument is a "int", it silently drops > > > any > > > MNT_xx flag in the high order 32bits of f_flags. At this > > > time, > > > it happens that MNT_AUTOMOUNTED is the only one, but... > > > > > > I can think of a couple of ways to fix this, but I don't like any > > > of > > > them;-) > > > > > > 1) I suppose mountd could check for each flag set in f_flags and > > > generate > > > a vfsopts string for it, but that means that every time a new > > > flag > > > that > > > can be updated is added to MNT_xx, this mountd.c code would have > > > to > > > updated. > > > --> Ugly!! > > > > > > 2) Require that all flags in MNT_UPDATEMASK be in the low order > > > 32bits. > > > I wouldn`t mind this except in means that the MNT_xx flags > > > must > > > be > > > redefined > > > and I don`t think that could get MFC`d. > > > > > > 3) Add a new newernmount(2) which has a 64bit flags argument > > > instead of > > > int. > > > > > > Hopefully someone can think of a nice way to fix this, rick > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > ------=_Part_35175528_844751710.1431263274441 Content-Type: text/x-patch; name=highbits.patch Content-Disposition: attachment; filename=highbits.patch Content-Transfer-Encoding: base64 LS0tIGtlcm4vdmZzX21vdW50LmMuc2F2bW50CTIwMTUtMDUtMDkgMTk6MzA6MTQuMDAwMDAwMDAw IC0wNDAwCisrKyBrZXJuL3Zmc19tb3VudC5jCTIwMTUtMDUtMTAgMDg6MzQ6NDUuMDAwMDAwMDAw IC0wNDAwCkBAIC01MzcsNiArNTM3LDcgQEAgdmZzX2Rvbm1vdW50KHN0cnVjdCB0aHJlYWQgKnRk LCB1aW50NjRfdAogCXN0cnVjdCB2ZnNvcHQgKm9wdCwgKnRtcF9vcHQ7CiAJY2hhciAqZnN0eXBl LCAqZnNwYXRoLCAqZXJybXNnOwogCWludCBlcnJvciwgZnN0eXBlbGVuLCBmc3BhdGhsZW4sIGVy cm1zZ19sZW4sIGVycm1zZ19wb3M7CisJdWludDY0X3QgZnNmbGFnX2hpZ2g7CiAKIAllcnJtc2cg PSBmc3BhdGggPSBOVUxMOwogCWVycm1zZ19sZW4gPSBmc3BhdGhsZW4gPSAwOwpAQCAtNjUzLDYg KzY1NCwyMCBAQCB2ZnNfZG9ubW91bnQoc3RydWN0IHRocmVhZCAqdGQsIHVpbnQ2NF90CiAJCQlm c2ZsYWdzIHw9IE1OVF9BVVRPTU9VTlRFRDsKIAkJCXZmc19mcmVlb3B0KG9wdGxpc3QsIG9wdCk7 CiAJCX0KKwkJZWxzZSBpZiAoc3RyY21wKG9wdC0+bmFtZSwgImZzZmxhZ2hpZ2giKSA9PSAwKSB7 CisJCQkvKgorCQkJICogVGhpcyBvcHRpb24gYWxsb3dzIGEgcHJvY2VzcyBkb2luZyBhIG1vdW50 IHVwZGF0ZQorCQkJICogdG8gc2V0IGFsbCB0aGUgaGlnaCBvcmRlciAzMmJpdHMgb2YgbW50X2Zs YWcgd2l0aAorCQkJICogb25lIG9wdGlvbi4gIFRoaXMgaXMgbmVlZGVkLCBzaW5jZSBubW91bnQo MikKKwkJCSAqIGFjY2VwdHMgYW4gImludCIgb3B0aW9uIGFuZCwgdGhlcmVmb3JlLCBvbmx5IHRh a2VzCisJCQkgKiB0aGUgbG93IG9yZGVyIDMyYml0cy4KKwkJCSAqLworCQkJaWYgKHZmc19jb3B5 b3B0KG9wdGxpc3QsICJmc2ZsYWdoaWdoIiwKKwkJCSAgICAmZnNmbGFnX2hpZ2gsIHNpemVvZihm c2ZsYWdfaGlnaCkpID09IDAgJiYKKwkJCSAgICAoZnNmbGFnX2hpZ2ggJiAweGZmZmZmZmZmVUxM KSA9PSAwKQorCQkJCWZzZmxhZ3MgfD0gZnNmbGFnX2hpZ2g7CisJCQl2ZnNfZnJlZW9wdChvcHRs aXN0LCBvcHQpOworCQl9CiAJfQogCiAJLyoKLS0tIHVzci5zYmluL21vdW50ZC9tb3VudGQuYy5v cmlnCTIwMTUtMDUtMDkgMjI6MDQ6MTUuMDAwMDAwMDAwIC0wNDAwCisrKyB1c3Iuc2Jpbi9tb3Vu dGQvbW91bnRkLmMJMjAxNS0wNS0wOSAyMjoyNzowNi4wMDAwMDAwMDAgLTA0MDAKQEAgLTE2NDks NiArMTY0OSw3IEBAIGdldF9leHBvcnRsaXN0KHZvaWQpCiAJaW50IGlvdmxlbjsKIAlpbnQgZG9u ZTsKIAlzdHJ1Y3QgbmZzZXhfYXJncyBlYXJnczsKKwl1aW50NjRfdCBmc2ZsYWdfaGlnaDsKIAog CWlmIChzdXNwZW5kX25mc2QgIT0gMCkKIAkJKHZvaWQpbmZzc3ZjKE5GU1NWQ19TVVNQRU5ETkZT RCwgTlVMTCk7CkBAIC0xNzA2LDYgKzE3MDcsOCBAQCBnZXRfZXhwb3J0bGlzdCh2b2lkKQogCQli dWlsZF9pb3ZlYygmaW92LCAmaW92bGVuLCAidXBkYXRlIiwgTlVMTCwgMCk7CiAJCWJ1aWxkX2lv dmVjKCZpb3YsICZpb3ZsZW4sICJleHBvcnQiLCAmZXhwb3J0LCBzaXplb2YoZXhwb3J0KSk7CiAJ CWJ1aWxkX2lvdmVjKCZpb3YsICZpb3ZsZW4sICJlcnJtc2ciLCBlcnJtc2csIHNpemVvZihlcnJt c2cpKTsKKwkJYnVpbGRfaW92ZWMoJmlvdiwgJmlvdmxlbiwgImZzZmxhZ2hpZ2giLCAmZnNmbGFn X2hpZ2gsCisJCSAgICBzaXplb2YoZnNmbGFnX2hpZ2gpKTsKIAl9CiAKIAlmb3IgKGkgPSAwOyBp IDwgbnVtOyBpKyspIHsKQEAgLTE3MzYsNiArMTczOSw5IEBAIGdldF9leHBvcnRsaXN0KHZvaWQp CiAJCWlvdlszXS5pb3ZfbGVuID0gc3RybGVuKGZzcC0+Zl9tbnRvbm5hbWUpICsgMTsKIAkJaW92 WzVdLmlvdl9iYXNlID0gZnNwLT5mX21udGZyb21uYW1lOwogCQlpb3ZbNV0uaW92X2xlbiA9IHN0 cmxlbihmc3AtPmZfbW50ZnJvbW5hbWUpICsgMTsKKwkJLyogVXNlICJmc2ZsYWdoaWdoIiB0byBz ZXQgdGhlIGhpZ2ggb3JkZXIgYml0cyBvZiBmX2ZsYWdzLiAqLworCQlmc2ZsYWdfaGlnaCA9IChm c3AtPmZfZmxhZ3MgJiAweGZmZmZmZmZmMDAwMDAwMDBVTEwpOworCiAJCWVycm1zZ1swXSA9ICdc MCc7CiAKIAkJLyoKQEAgLTIzOTQsNiArMjQwMCw3IEBAIGRvX21vdW50KHN0cnVjdCBleHBvcnRs aXN0ICplcCwgc3RydWN0IGcKIAlpbnQgaSwgaW92bGVuOwogCWludCByZXQ7CiAJc3RydWN0IG5m c2V4X2FyZ3MgbmZzZWE7CisJdWludDY0X3QgZnNmbGFnX2hpZ2g7CiAKIAllYXAgPSAmbmZzZWEu ZXhwb3J0OwogCkBAIC0yNDI5LDYgKzI0MzYsMTIgQEAgZG9fbW91bnQoc3RydWN0IGV4cG9ydGxp c3QgKmVwLCBzdHJ1Y3QgZwogCQlidWlsZF9pb3ZlYygmaW92LCAmaW92bGVuLCAiZXhwb3J0Iiwg ZWFwLAogCQkgICAgc2l6ZW9mIChzdHJ1Y3QgZXhwb3J0X2FyZ3MpKTsKIAkJYnVpbGRfaW92ZWMo JmlvdiwgJmlvdmxlbiwgImVycm1zZyIsIGVycm1zZywgc2l6ZW9mKGVycm1zZykpOworCisJCS8q IFVzZSAiZnNmbGFnaGlnaCIgdG8gc2V0IHRoZSBoaWdoIG9yZGVyIGJpdHMgb2YgZl9mbGFncy4g Ki8KKwkJZnNmbGFnX2hpZ2ggPSAoZnNiLT5mX2ZsYWdzICYgMHhmZmZmZmZmZjAwMDAwMDAwVUxM KTsKKwkJaWYgKGZzZmxhZ19oaWdoICE9IDApCisJCQlidWlsZF9pb3ZlYygmaW92LCAmaW92bGVu LCAiZnNmbGFnaGlnaCIsICZmc2ZsYWdfaGlnaCwKKwkJCSAgICBzaXplb2YoZnNmbGFnX2hpZ2gp KTsKIAl9CiAKIAl3aGlsZSAoIWRvbmUpIHsK ------=_Part_35175528_844751710.1431263274441-- From owner-freebsd-current@FreeBSD.ORG Sun May 10 13:33:03 2015 Return-Path: Delivered-To: freebsd-current@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 06A0A27E for ; Sun, 10 May 2015 13:33:03 +0000 (UTC) Received: from forward12o.cmail.yandex.net (forward12o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::1e2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B01371E74 for ; Sun, 10 May 2015 13:33:02 +0000 (UTC) Received: from web15o.yandex.ru (web15o.yandex.ru [95.108.205.115]) by forward12o.cmail.yandex.net (Yandex) with ESMTP id 253A92143D for ; Sun, 10 May 2015 16:32:49 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web15o.yandex.ru (Yandex) with ESMTP id C5B7B2A0241D; Sun, 10 May 2015 16:32:48 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1431264768; bh=3rhx0HrW7qGeZCwx23gatgwo1ZuU+DReIwY5VzyBvas=; h=From:To:Subject:Date; b=EY1uCXQWHtzaOLQ3Lh9fRDjNk6lDk00YREqnQMTU96coPtRi71uaiDsfWzZQe3UCz YzCfQA6BIwokirLTlwm91fs7veolHkRredpN+El+lMRKGxuHl9rM2oTLRTvVCjtrZx ImmBIEk8V2Zy3sb5E6bgwChwuXdOf5V6+BOCdYbE= Received: by web15o.yandex.ru with HTTP; Sun, 10 May 2015 16:32:48 +0300 From: Dmitry Postolov To: freebsd-current@freebsd.org Subject: Problem with latest BIOS Intel NUC DN2820FYKH(2830) & FreeBSD-11-CURRENT MIME-Version: 1.0 Message-Id: <832521431264768@web15o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 10 May 2015 16:32:48 +0300 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 13:33:03 -0000 Hi to all! Sorry for my bad English... This message is translated with help of the translator's online. You could comment on a situation with my nettop Intel NUC DN2820FYKH (CPU Celeron N2830)? This NUC was delivered with pre-installed BIOS 0032. With this version BIOS I am could install FreeBSD 10 and 11-CURRENT. In next version of BIOS 0034 and later installing was a problems. Message of other user, NUC DN2820 can't recognize FreeBSD bootsect. https://communities.intel.com/message/245413 My situation: --- FreeBSD-10.1-STABLE-usb-stick.img (May 5 2015) after #dd: ls /dev/da* /dev/da0 /dev/da0a # Probable this is MBR structure? FreeBSD-11-CURRENT-usb-stick.img (May 5 2015) after #dd: ls /dev/da* /dev/da0 /dev/da0p1 /dev/da0p2 /dev/da0p3 /dev/da0p4 # Probable this is GPT structure? --- And probable the Bug of Intel BIOS for NUC 2820 (N2830): 0032 BIOS can start MBR FreeBSD-10.1-usb-stick installer, bsdinstall by default offers GPT structure for HDD. 0032 successfully run FreeBSD from GPT HDD. Also 0032 can start GPT FreeBSD-11-CURRENT-usb-stick installer, bsdinstall by default offers MBR structure for HDD? (or use last MBR-HDD setting). After install 0032 successfully start FreeBSD-11-CURRENT from HDD. But with modern BIOS (for example 0050 - latest at this time): 0050 BIOS can start MBR FreeBSD-10.1-usb-stick installer, bsdinstaller by default offers GPT HDD structure. If install 10.1 with default settings and start 10.1 from HDD -> Error. If GPT HDD manually changed to MBR HDD, then 10.1 successfully starts from HDD. But 11-CURRENT-usb-stick has GPT structure and BIOS 0050 can't run it from USB. :-(( Workaround: Reflash 0032 -> Install FreeBSD-11-CURRENT -> OK -> Reflash 0050 -> 11-CURRENT starts OK from MBR HDD. Question: if this situation doesn't be fixed by Intel, how NUC 2820(2830) new versions of BIOS users can start FreeBSD-11 without BIOS reflashing, if FreeBSD-11-stick.img will be only at GPT structure? --- best regards, Dmitry Postolov dip-freebsd@yandex.ru From owner-freebsd-current@FreeBSD.ORG Sun May 10 15:20:08 2015 Return-Path: Delivered-To: current@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 35A369FF for ; Sun, 10 May 2015 15:20:08 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 D943B18E8 for ; Sun, 10 May 2015 15:20:06 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4AFJxxn004134 for ; Sun, 10 May 2015 08:19:59 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4AFJx8U004133 for current@freebsd.org; Sun, 10 May 2015 08:19:59 -0700 (PDT) (envelope-from david) Date: Sun, 10 May 2015 08:19:59 -0700 From: David Wolfskill To: current@freebsd.org Subject: Turbulence in head @r282676. Message-ID: <20150510151959.GA1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 15:20:08 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As noted yesterday, my laptop panicked trying to boot head/i386 @r282676, but seemed OK withe head/amd64. That turns out to have been a bit optimistic: today, while performing a src update on the laptop from head/amd64 from r282676 to r282719, the laptop locked up. While I was able to reproduce the overall symptoms, I don't know how good the match was, as I'm not sure exactly where in the processing the machine was each of the 3 times. (After that, I gave up, and booted the previous day's kernel (@r282623); that permitted a complete build of sources @r282719.) And my build machine (which is only i386) didn't have the panic (as it hasn't any HDA sound), but while it was running head/i386 @r282676, builoding head/i386 @r282719, I found it sitting at a "db> " prompt. This appears to be a kassert_panic() in head/i386 @r282676. I have a crash dump and a text excerpt; here are excerpts from that excerpt: Sun May 10 08:05:58 PDT 2015 FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1829 r= 282676M/282676:1100073: Sat May 9 07:34:18 PDT 2015 root@freebeast.cat= whisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 panic: object 0xc9dbb750 ref_count =3D 1 =2E.. Unread portion of the kernel message buffer: panic: object 0xc9dbb750 ref_count =3D 1 cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper(c11db478,0,c11b0e6c,202,f4e0e740,...) at db_trace_sel= f_wrapper+0x2a/frame 0xf4e0e710 kdb_backtrace(c13a164b,1,c1216514,f4e0e7dc,1,...) at kdb_backtrace+0x2d/fra= me 0xf4e0e778 vpanic(c1216514,f4e0e7dc,c1216514,f4e0e7dc,f4e0e7dc,...) at vpanic+0x117/fr= ame 0xf4e0e7ac kassert_panic(c1216514,c9dbb750,1,c1f558c0,f4e0e828,...) at kassert_panic+0= xe9/frame 0xf4e0e7d0 vm_object_zdtor(c9dbb750,9c,0,8,10,...) at vm_object_zdtor+0x75/frame 0xf4e= 0e7e8 uma_zfree_arg(c1f558c0,c9dbb750,0) at uma_zfree_arg+0x61/frame 0xf4e0e828 vm_object_destroy(c9dbb750,0,c1218fa3,ef,f4e0e884,...) at vm_object_destroy= +0x75/frame 0xf4e0e840 vnode_pager_alloc(c9dad470,1015,0,0,0,...) at vnode_pager_alloc+0x68/frame = 0xf4e0e880 vnode_create_vobject(c9dad470,1015,0,c890d000,c14730b4,...) at vnode_create= _vobject+0x1f8/frame 0xf4e0e93c ufs_open(f4e0e9d0,c75f4c40,c84a0400,0,d3,...) at ufs_open+0x70/frame 0xf4e0= e95c VOP_OPEN_APV(c1472a90,f4e0e9d0,100,c6d83178,f4e0e9f4,...) at VOP_OPEN_APV+0= xfe/frame 0xf4e0e988 vn_open_vnode(c9dad470,1,c88d1700,c890d000,c7b16b60,...) at vn_open_vnode+0= x1e5/frame 0xf4e0ea00 vn_open_cred(f4e0eb40,f4e0ebcc,0,0,c88d1700,c7b16b60) at vn_open_cred+0x32a= /frame 0xf4e0ead0 vn_open(f4e0eb40,f4e0ebcc,0,c7b16b60,2adcfdd4,...) at vn_open+0x3d/frame 0x= f4e0eaf8 kern_openat(c890d000,ffffff9c,2adcfdd4,0,0,0) at kern_openat+0x2ec/frame 0x= f4e0ebf0 sys_openat(c890d000,f4e0eca8,c11cfcd9,4,c105e827,...) at sys_openat+0x3a/fr= ame 0xf4e0ec18 syscall(f4e0ece8) at syscall+0x33b/frame 0xf4e0ecdc Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf4e0ecdc --- syscall (499, FreeBSD ELF32, sys_openat), eip =3D 0xa1298ff, esp =3D 0x= bfbfa910, ebp =3D 0xbfbfa928 --- KDB: enter: panic Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols #0 doadump (textdump=3D0) at pcpu.h:205 205 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D0) at pcpu.h:205 #1 0xc05311f1 in db_dump (dummy=3D-1061584035, dummy2=3D0, dummy3=3D-1,=20 dummy4=3D0xf4e0e4bc "") at /usr/src/sys/ddb/db_command.c:533 #2 0xc0530d9f in db_command (cmd_table=3D) at /usr/src/sys/ddb/db_command.c:440 #3 0xc05309e0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xc053337b in db_trap (code=3D) at /usr/src/sys/ddb/db_main.c:251 #5 0xc0b98ac7 in kdb_trap (tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xc10568ff in trap (frame=3D) at /usr/src/sys/i386/i386/trap.c:693 #7 0xc10427fc in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc0b9835d in kdb_enter (why=3D0xc11d6ba9 "panic",=20 msg=3D) at cpufunc.h:60 #9 0xc0b5a1b7 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:737 #10 0xc0b5a079 in kassert_panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xc0e1ea45 in vm_object_zdtor (mem=3D0xc9dbb750, size=3D156, arg=3D0x0) at /usr/src/sys/vm/vm_object.c:169 #12 0xc0e0a691 in uma_zfree_arg (zone=3D0xc1f558c0, item=3D,=20 udata=3D0x10) at /usr/src/sys/vm/uma_core.c:2723 #13 0xc0e20195 in vm_object_destroy (object=3D0xc9dbb750) at uma.h:364 #14 0xc0e326d8 in vnode_pager_alloc (handle=3D0xc9dad470, size=3D4117,=20 prot=3D0 '\0', offset=3D0, cred=3D0xc88d1700) at /usr/src/sys/vm/vnode_pager.c:240 #15 0xc0e330d8 in vnode_create_vobject (vp=3D0xc9dad470,=20 isize=3D, td=3D0xc890d000) at /usr/src/sys/vm/vnode_pager.c:144 #16 0xc0dfd510 in ufs_open (ap=3D) at /usr/src/sys/ufs/ufs/ufs_vnops.c:284 #17 0xc10849de in VOP_OPEN_APV (vop=3D, a=3D0xf4e0e9d0) at vnode_if.c:467 #18 0xc0c23bb5 in vn_open_vnode (vp=3D0xc9dad470, fmode=3D,=20 cred=3D, fp=3D) at vnode_if.h= :196 #19 0xc0c237da in vn_open_cred (ndp=3D0xf4e0eb40, flagp=3D,=20 vn_open_flags=3D, fp=3D) at /usr/src/sys/kern/vfs_vnops.c:264 #20 0xc0c2349d in vn_open (ndp=3D0xf4e0eb40, flagp=3D0xf4e0ebcc, cmode=3D0,= =20 fp=3D0xc7b16b60) at /usr/src/sys/kern/vfs_vnops.c:166 #21 0xc0c1b9fc in kern_openat (td=3D0xc890d000, fd=3D0, path=3D0x0,=20 pathseg=3D, flags=3D,=20 mode=3D) at /usr/src/sys/kern/vfs_syscalls.c:1090 #22 0xc0c1bd7a in sys_openat (td=3D0xc890d000, uap=3D0xf4e0eca8) at /usr/src/sys/kern/vfs_syscalls.c:1038 #23 0xc105760b in syscall (frame=3D) at subr_syscall.c= :133 #24 0xc1042891 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:269 #25 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 =2E... I can make the dumps, as well as a verbose dmesg.boot, available. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVT3cfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7JSgP/0ZKZiZWmmH0d9fF0Bd/Tj+p ZKRr7L9IO6z0Uq9RIxBf3WdFSiqLBffue4tvqWewk4eLdmdH+rFwv8ubacJQ0A17 295Euy2Br/CEsYT81kPAFRvQMMP9iAaZsJ6SKHisGgb3EJ381to49Fl7AFQcqale D48NiEbErmt2ndfRLc9TNKqExGOkXzrhF7+MzuSrNJpCSk19GX9YLrwARE/0Hbep 4h8KxnfbrpyolKeOdHFSbOwTSI4WUhKT5w4YtRRkUMCG+HVGA3sKI6NhwLVcio++ 46HENmJU5JbO4soUFM/aTwb6zGX8BnD3kQirocYn0y8aHpEfWeeCEqH+UNlUWFsU npaBMrI6MW56sLboWo3fcV9lTfQ9YsCxrcUvd+OA77hV4tJj/XpGHBojtwXkmSJs rDOKAn7EloKVU8gvGmtoIdYqiXBij51Z5+LU6sFOTQnglkxGsI6xBef6plnSpIjE tMma03eYNyt/wjaXqbLE6p23mzezYOeO+g5fgK0lyarKr5sgSP24aUL4ulDkUG0F AB5Fu2LaPTB81zMYzjOgHpZM+BlnDPVt54epzntCihU/Xvvpi59O4rNYO4NQN6Ob M3UbBgYjxT+7batBQnGASSH1On14HTqNuRB7hYceWXM9evhFf1dQLOh/zm7KU8or 6i2pgRI4LNYmm0sv3RdL =Ffvv -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Sun May 10 15:58:51 2015 Return-Path: Delivered-To: freebsd-current@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 3E3551FD for ; Sun, 10 May 2015 15:58:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1441CAB for ; Sun, 10 May 2015 15:58:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7EBBF58A for ; Sun, 10 May 2015 15:58:51 +0000 (UTC) Date: Sun, 10 May 2015 15:58:50 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <555994524.1.1431273531004.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <141152756.2.1431238255363.JavaMail.jenkins@jenkins-9.freebsd.org> References: <141152756.2.1431238255363.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1024 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 15:58:51 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun May 10 16:32:52 2015 Return-Path: Delivered-To: freebsd-current@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 ECF7448A; Sun, 10 May 2015 16:32:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id CDBCD1FE5; Sun, 10 May 2015 16:32:51 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id D24C15A2; Sun, 10 May 2015 16:32:51 +0000 (UTC) Date: Sun, 10 May 2015 16:32:51 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, jilles@FreeBSD.org, ian@FreeBSD.org, hselasky@FreeBSD.org, thomas@FreeBSD.org Message-ID: <1904526881.2.1431275571828.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2753 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 16:32:52 -0000 See Changes: [jilles] recv(),send(): Directly call interposing entry instead of going th= rough PLT. recv() and send()'s calls to recvfrom() and sendto() are much like waitpid()'s call to wait4(), and likewise need not allow PLT interposing on the called function. [ian] Don't check the return value from self_reloc(), it can't fail and doe= sn't return a value. Despite what I said in my prior commit, it turns out this one platform was checking the return value from the old self-reloc code (which returned a hard-coded 0). [ian] The self-relocation code is not efi-specific, move it to boot/common. The function was defined as taking 4 parameters and returning EFI_STATUS, but all existing callers (in asm code) passed only two parameters and don't use the return value. The function signature now matches that usage, and doesn't refer to efi-specific types. Parameters and variables now use the cannonical typenames set up by elf.h (Elf_Word, Elf_Addr, etc) instead of raw C types. Hopefully this will prevent suprises as new platforms come along and use this code. The function was renamed from _reloc() to self_reloc() to emphasize its difference from the other elf relocation code found in boot/common. Differential Revision:=09https://reviews.freebsd.org/D2490 [thomas] Ensure libmd symbols do not clash with libcrypto Add a prefix to all symbols in libmd to avoid incompatibilites with same-named, but not binary compatible, symbols from libcrypto. Also introduce Weak aliases to avoid the need to rebuild dependent binaries and a major version bump. PR:=09=09199119 Differential Revision:=09D2216 Reviewed by:=09roberto, delphij MFC after:=092 weeks [hselasky] Put recycle pointer in own memory area which is not mmap'able. ------------------------------------------ [...truncated 82157 lines...] ^ In file included from :36: :43:9: warning: 'MD4Pad' macro redefined [-Wmacro-redefined] #define MD4Pad _libmd_MD4Pad ^ :6:9: note: previous definition is here #define MD4Pad __MD4Pad ^ In file included from :36: :44:9: warning: 'MD4Final' macro redefined [-Wmacro-redefined] #define MD4Final _libmd_MD4Final ^ :4:9: note: previous definition is here #define MD4Final __MD4Final ^ 4 warnings generated. In file included from :30: :41:9: warning: 'MD4Init' macro redefined [-Wmacro-redefined] #define MD4Init _libmd_MD4Init ^ :3:9: note: previous definition is here #define MD4Init __MD4Init ^ In file included from :30: :42:9: warning: 'MD4Update' macro redefined [-Wmacro-redefined] #define MD4Update _libmd_MD4Update ^ :5:9: note: previous definition is here #define MD4Update __MD4Update ^ In file included from :30: :43:9: warning: 'MD4Pad' macro redefined [-Wmacro-redefined] #define MD4Pad _libmd_MD4Pad ^ :6:9: note: previous definition is here #define MD4Pad __MD4Pad ^ In file included from :30: :44:9: warning: 'MD4Final' macro redefined [-Wmacro-redefined] #define MD4Final _libmd_MD4Final ^ :4:9: note: previous definition is here #define MD4Final __MD4Final ^ 4 warnings generated. --- lib/libcom_err__L --- --- error.So --- cc -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-q= ual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wcha= r-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-defini= tion -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno= -empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-argume= nts -c -o error.So --- lib/libcrypt__L --- In file included from :38: :44:9: warning: 'SHA256_Init' macro redefined [-Wmacro-redefined] #define SHA256_Init _libmd_SHA256_Init ^ :11:9: note: previous definition is here #define SHA256_Init __SHA256_Init ^ In file included from :38: :45:9: warning: 'SHA256_Update' macro redefined [-Wmacro-redefined] #define SHA256_Update _libmd_SHA256_Update ^ :13:9: note: previous definition is here #define SHA256_Update __SHA256_Update ^ In file included from :38: :46:9: warning: 'SHA256_Final' macro redefined [-Wmacro-redefined] #define SHA256_Final _libmd_SHA256_Final ^ :12:9: note: previous definition is here #define SHA256_Final __SHA256_Final ^ 3 warnings generated. In file included from :35: :44:9: warning: 'SHA256_Init' macro redefined [-Wmacro-redefined] #define SHA256_Init _libmd_SHA256_Init ^ :11:9: note: previous definition is here #define SHA256_Init __SHA256_Init ^ In file included from :35: :45:9: warning: 'SHA256_Update' macro redefined [-Wmacro-redefined] #define SHA256_Update _libmd_SHA256_Update ^ :13:9: note: previous definition is here #define SHA256_Update __SHA256_Update ^ In file included from :35: :46:9: warning: 'SHA256_Final' macro redefined [-Wmacro-redefined] #define SHA256_Final _libmd_SHA256_Final ^ :12:9: note: previous definition is here #define SHA256_Final __SHA256_Final ^ 3 warnings generated. In file included from :38: :44:9: warning: 'SHA512_Init' macro redefined [-Wmacro-redefined] #define SHA512_Init _libmd_SHA512_Init ^ :14:9: note: previous definition is here #define SHA512_Init __SHA512_Init ^ In file included from :38: :45:9: warning: 'SHA512_Update' macro redefined [-Wmacro-redefined] #define SHA512_Update _libmd_SHA512_Update ^ :16:9: note: previous definition is here #define SHA512_Update __SHA512_Update ^ In file included from :38: :46:9: warning: 'SHA512_Final' macro redefined [-Wmacro-redefined] #define SHA512_Final _libmd_SHA512_Final ^ :15:9: note: previous definition is here #define SHA512_Final __SHA512_Final ^ 3 warnings generated. --- lib/libbz2__L --- --- bzlib.So --- --- lib/libcom_err__L --- --- com_err.o --- --- lib/libbz2__L --- cc -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsyste= m-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-poin= ter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -W= no-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-un= used-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-argum= ents -c -o bzlib.So --- lib/libcom_err__L --- cc -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-= strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts= -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-po= inter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c -o com_err.o --- lib/libcrypt__L --- In file included from :35: :44:9: warning: 'SHA512_Init' macro redefined [-Wmacro-redefined] #define SHA512_Init _libmd_SHA512_Init ^ :14:9: note: previous definition is here #define SHA512_Init __SHA512_Init ^ In file included from :35: :45:9: warning: 'SHA512_Update' macro redefined [-Wmacro-redefined] #define SHA512_Update _libmd_SHA512_Update ^ :16:9: note: previous definition is here #define SHA512_Update __SHA512_Update ^ In file included from :35: :46:9: warning: 'SHA512_Final' macro redefined [-Wmacro-redefined] #define SHA512_Final _libmd_SHA512_Final ^ :15:9: note: previous definition is here #define SHA512_Final __SHA512_Final ^ 3 warnings generated. --- lib/libcom_err__L --- --- error.o --- cc -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsystem-head= ers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-= strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts= -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-po= inter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c -o error.o --- libcom_err.so.5 --- building shared library libcom_err.so.5 cc -Wl,--no-undefined -Wl,--version-script=3D -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-t= extrel -o libcom_err.so.5 -Wl,-soname,libcom_err.so.5 `NM=3D'nm' lorder c= om_err.So error.So | tsort -q`=20 --- lib/libcrypt__L --- --- crypt.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAS_DES -DHAS_BLOWFISH -DMD4Init=3D__MD4Init -DMD4Fina= l=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad -DMD5Init=3D__= MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -DMD5Pad=3D__MD5P= ad -DSHA256_Init=3D__SHA256_Init -DSHA256_Final=3D__SHA256_Final -DSHA256_U= pdate=3D__SHA256_Update -DSHA512_Init=3D__SHA512_Init -DSHA512_Final=3D__SH= A512_Final -DSHA512_Update=3D__SHA512_Update -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-poi= nter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -= Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c -o crypt.So --- lib/libcom_err__L --- --- libcom_err.a --- building static com_err library --- lib/libcrypt__L --- --- misc.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAS_DES -DHAS_BLOWFISH -DMD4Init=3D__MD4Init -DMD4Fina= l=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad -DMD5Init=3D__= MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -DMD5Pad=3D__MD5P= ad -DSHA256_Init=3D__SHA256_Init -DSHA256_Final=3D__SHA256_Final -DSHA256_U= pdate=3D__SHA256_Update -DSHA512_Init=3D__SHA512_Init -DSHA512_Final=3D__SH= A512_Final -DSHA512_Update=3D__SHA512_Update -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-poi= nter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -= Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c -o misc.So --- lib/libcom_err__L --- ranlib -D libcom_err.a --- _libinstall --- sh -C -o= root -g wheel -m 444 libcom_err.a sh -s -o= root -g wheel -m 444 libcom_err.so.5 sh -l s = libcom_err.so.5 --- _INCSINS --- sh -C -o= root -g wheel -m 444 --- lib/libcrypt__L --- --- crypt-md5.So --- --- lib/libexpat__L --- --- lib/libcrypt__L --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAS_DES -DHAS_BLOWFISH -DMD4Init=3D__MD4Init -DMD4Fina= l=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad -DMD5Init=3D__= MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -DMD5Pad=3D__MD5P= ad -DSHA256_Init=3D__SHA256_Init -DSHA256_Final=3D__SHA256_Final -DSHA256_U= pdate=3D__SHA256_Update -DSHA512_Init=3D__SHA512_Init -DSHA512_Final=3D__SH= A512_Final -DSHA512_Update=3D__SHA512_Update -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-poi= nter-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -= Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-u= nused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -= Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c -o crypt-= md5.So --- lib/libexpat__L --- =3D=3D=3D> lib/libexpat (obj,depend,all,install) --- lib/libcrypt__L --- In file included from :33: :10:9: error: 'MD5Init' macro redefined [-Werror,-Wmacro-redefined] #define MD5Init _libmd_MD5Init ^ :8:9: note: previous definition is here #define MD5Init __MD5Init ^ In file included from :33: :11:9: error: 'MD5Update' macro redefined [-Werror,-Wmacro-redefined] #define MD5Update _libmd_MD5Update ^ :10:9: note: previous definition is here #define MD5Update __MD5Update ^ In file included from :33: :12:9: error: 'MD5Pad' macro redefined [-Werror,-Wmacro-redefined] #define MD5Pad _libmd_MD5Pad ^ :11:9: note: previous definition is here #define MD5Pad __MD5Pad ^ In file included from :33: :13:9: error: 'MD5Final' macro redefined [-Werror,-Wmacro-redefined] #define MD5Final _libmd_MD5Final ^ :9:9: note: previous definition is here #define MD5Final __MD5Final ^ --- lib/libexpat__L --- --- obj --- --- lib/libcrypt__L --- 4 errors generated. *** [crypt-md5.So] Error code 1 make[4]: stopped in 1 error make[4]: stopped in --- lib/libexpat__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib/libbz2__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib/libelf__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sun May 10 16:40:49 2015 Return-Path: Delivered-To: freebsd-current@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 B35CC6D4 for ; Sun, 10 May 2015 16:40:49 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (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 26060100D for ; Sun, 10 May 2015 16:40:48 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t4AGeUtt095288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 May 2015 18:40:31 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t4AGrU0m086918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 May 2015 18:53:30 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.9/8.14.9/Submit) id t4AGrUPk086917; Sun, 10 May 2015 18:53:30 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sun, 10 May 2015 18:53:30 +0200 From: Wolfgang Zenker To: Hans Petter Selasky Cc: freebsd-current@freebsd.org Subject: Re: Race VT+X11 on -current Message-ID: <20150510165330.GA86856@lyxys.ka.sub.org> References: <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> <20150509210525.GA80848@lyxys.ka.sub.org> <554F5379.2070100@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554F5379.2070100@selasky.org> Organization: private site User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sun, 10 May 2015 18:40:31 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 16:40:49 -0000 Hi, * Hans Petter Selasky [150510 14:47]: > On 05/09/15 23:05, Wolfgang Zenker wrote: >> * Allan Jude [150508 16:29]: >>> [..] >>> My experience is a little different. >>> When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) >>> Sometimes when I resume, it seems like the keyboard is frozen. If I >>> alt+f1, then alt+f9, it seems to work fine after that. I'd never though >>> of trying just alt+f9 right away, as I could already see my X session. >>> Not sure if this is related, but it sounds very similar. >> Similar problem on 10-STABLE: I usually start X by running startx >> on ttyv0. After exiting X screen shows ttyv0 again but keyboard >> appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to >> ttyv1 and back "unfreezes" keyboard. > Can you try applying to 10-stable: > https://svnweb.freebsd.org/changeset/base/282645 Patch needs a little tweaking to apply in vt_resume() on 10-stable (vd is main_vd here), but appears to fix the problem. Wolfgang From owner-freebsd-current@FreeBSD.ORG Sun May 10 16:46:52 2015 Return-Path: Delivered-To: freebsd-current@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 E546A864 for ; Sun, 10 May 2015 16:46:52 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 A5FA71113 for ; Sun, 10 May 2015 16:46:52 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3976D1FE023; Sun, 10 May 2015 18:46:50 +0200 (CEST) Message-ID: <554F8BA6.9000702@selasky.org> Date: Sun, 10 May 2015 18:47:34 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Wolfgang Zenker CC: freebsd-current@freebsd.org Subject: Re: Race VT+X11 on -current References: <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> <20150509210525.GA80848@lyxys.ka.sub.org> <554F5379.2070100@selasky.org> <20150510165330.GA86856@lyxys.ka.sub.org> In-Reply-To: <20150510165330.GA86856@lyxys.ka.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 16:46:53 -0000 On 05/10/15 18:53, Wolfgang Zenker wrote: > Hi, > > * Hans Petter Selasky [150510 14:47]: >> On 05/09/15 23:05, Wolfgang Zenker wrote: >>> * Allan Jude [150508 16:29]: >>>> [..] >>>> My experience is a little different. > >>>> When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) > >>>> Sometimes when I resume, it seems like the keyboard is frozen. If I >>>> alt+f1, then alt+f9, it seems to work fine after that. I'd never though >>>> of trying just alt+f9 right away, as I could already see my X session. > >>>> Not sure if this is related, but it sounds very similar. > >>> Similar problem on 10-STABLE: I usually start X by running startx >>> on ttyv0. After exiting X screen shows ttyv0 again but keyboard >>> appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to >>> ttyv1 and back "unfreezes" keyboard. > >> Can you try applying to 10-stable: > >> https://svnweb.freebsd.org/changeset/base/282645 > > Patch needs a little tweaking to apply in vt_resume() on 10-stable > (vd is main_vd here), but appears to fix the problem. > Hi, Sounds good. I'll MFC the patch sometime next week. Seems like more people need it for daily FreeBSD use :-) --HPS From owner-freebsd-current@FreeBSD.ORG Sun May 10 17:00:27 2015 Return-Path: Delivered-To: freebsd-current@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 14279B90 for ; Sun, 10 May 2015 17:00:27 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D823D122E for ; Sun, 10 May 2015 17:00:26 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so53544910igb.1 for ; Sun, 10 May 2015 10:00:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L0k/ErITUT4AVbv3zdtuhWvyRygDe+xkvXxjWihqqtA=; b=Wx9uMB6fYVJYM2AKsNlErUH07ofBIeU+lo7p9OWrN2V6PGHroAaZd3oILEYsVZd7HZ WvYqOgDvlpp3H+yP6x6rglBJZY9JFxO9JsbcuKjqOhUyG0U4mIDwA5Ckf4l5AqeeU13s 0PDw/lmqguVFqRtFZvFKddeNKup0G3+3eq2a6lM1BAwQrE6gPDVkeFt/t7XdwrrWYitu Fnjadyti1tZeEj/f8wrZtEMcwQ4algVfTt02L8TXaaZMbDIuaJcG13/op3SZrLzO1746 SfIuvMvnbz8kiLmOMucJiKMfTLjCR4qEAuGGydoLz0QMzPtX/yuLTPCHkWFOwHJTcIjM wZYQ== X-Gm-Message-State: ALoCoQkAFEzshwHHEd3J7RUiEnQjoWFKAx/4PH+CPapjzhtqXfU23UDdR2vMzO8zWZafbOFl7Tqk MIME-Version: 1.0 X-Received: by 10.43.173.70 with SMTP id ob6mr7363709icc.45.1431277219863; Sun, 10 May 2015 10:00:19 -0700 (PDT) Received: by 10.79.11.6 with HTTP; Sun, 10 May 2015 10:00:19 -0700 (PDT) In-Reply-To: <554F8BA6.9000702@selasky.org> References: <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> <20150509210525.GA80848@lyxys.ka.sub.org> <554F5379.2070100@selasky.org> <20150510165330.GA86856@lyxys.ka.sub.org> <554F8BA6.9000702@selasky.org> Date: Sun, 10 May 2015 19:00:19 +0200 Message-ID: Subject: Re: Race VT+X11 on -current From: Oliver Pinter To: Hans Petter Selasky Cc: Wolfgang Zenker , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:00:27 -0000 Hi Hans! On 5/10/15, Hans Petter Selasky wrote: > On 05/10/15 18:53, Wolfgang Zenker wrote: >> Hi, >> >> * Hans Petter Selasky [150510 14:47]: >>> On 05/09/15 23:05, Wolfgang Zenker wrote: >>>> * Allan Jude [150508 16:29]: >>>>> [..] >>>>> My experience is a little different. >> >>>>> When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) >> >>>>> Sometimes when I resume, it seems like the keyboard is frozen. If I >>>>> alt+f1, then alt+f9, it seems to work fine after that. I'd never >>>>> though >>>>> of trying just alt+f9 right away, as I could already see my X session. >> >>>>> Not sure if this is related, but it sounds very similar. >> >>>> Similar problem on 10-STABLE: I usually start X by running startx >>>> on ttyv0. After exiting X screen shows ttyv0 again but keyboard >>>> appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to >>>> ttyv1 and back "unfreezes" keyboard. >> >>> Can you try applying to 10-stable: >> >>> https://svnweb.freebsd.org/changeset/base/282645 >> >> Patch needs a little tweaking to apply in vt_resume() on 10-stable >> (vd is main_vd here), but appears to fix the problem. >> > > Hi, > > Sounds good. I'll MFC the patch sometime next week. Seems like more > people need it for daily FreeBSD use :-) I have this fix or enhancements in our HardenedBSD codebase: https://github.com/HardenedBSD/hardenedBSD/commit/18058137da01598403b6ffa40c37b0a907441530 Please review them, and if you feel this required in FreeBSD too, and cherry-pick them. > > --HPS > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun May 10 17:13:24 2015 Return-Path: Delivered-To: freebsd-current@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 30216FD1 for ; Sun, 10 May 2015 17:13:24 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 E238C13D8 for ; Sun, 10 May 2015 17:13:23 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0D9B71FE023; Sun, 10 May 2015 19:13:22 +0200 (CEST) Message-ID: <554F91DE.8010209@selasky.org> Date: Sun, 10 May 2015 19:14:06 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Oliver Pinter CC: Wolfgang Zenker , freebsd-current@freebsd.org Subject: Re: Race VT+X11 on -current References: <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> <20150509210525.GA80848@lyxys.ka.sub.org> <554F5379.2070100@selasky.org> <20150510165330.GA86856@lyxys.ka.sub.org> <554F8BA6.9000702@selasky.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:13:24 -0000 On 05/10/15 19:00, Oliver Pinter wrote: > Hi Hans! > > > Hi, >> >> Sounds good. I'll MFC the patch sometime next week. Seems like more >> people need it for daily FreeBSD use :-) > > I have this fix or enhancements in our HardenedBSD codebase: > https://github.com/HardenedBSD/hardenedBSD/commit/18058137da01598403b6ffa40c37b0a907441530 > Please review them, and if you feel this required in FreeBSD too, and > cherry-pick them. > Hi Oliver, Your patch is correct from what I can see. Signed modulus can be creepy sometimes! Better if VT_MAXWINDOWS was power of two and we used a bitwise AND. https://svnweb.freebsd.org/changeset/base/282730 --HPS From owner-freebsd-current@FreeBSD.ORG Sun May 10 17:36:19 2015 Return-Path: Delivered-To: freebsd-current@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 567873B3; Sun, 10 May 2015 17:36:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 42ADA1623; Sun, 10 May 2015 17:36:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5F28F5BD; Sun, 10 May 2015 17:36:19 +0000 (UTC) Date: Sun, 10 May 2015 17:36:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <803622889.4.1431279379355.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_i386 #111 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:36:19 -0000 See ------------------------------------------ [...truncated 155497 lines...] ^ :3:9: note: previous definition is here #define MD4Init __MD4Init ^ In file included from :36: :42:9: warning: 'MD4Update' macro redefined [-Wmacro-redefined] #define MD4Update _libmd_MD4Update ^ :5:9: note: previous definition is here #define MD4Update __MD4Update ^ In file included from :36: :43:9: warning: 'MD4Pad' macro redefined [-Wmacro-redefined] #define MD4Pad _libmd_MD4Pad ^ :6:9: note: previous definition is here #define MD4Pad __MD4Pad ^ In file included from :36: :44:9: warning: 'MD4Final' macro redefined [-Wmacro-redefined] #define MD4Final _libmd_MD4Final ^ :4:9: note: previous definition is here #define MD4Final __MD4Final ^ 4 warnings generated. --- lib/libcom_err__L --- --- com_err.So --- cc -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-protec= tor -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wc= ast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-d= efinition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety= -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-a= rguments -c -o com_err.So --- lib/libcrypt__L --- In file included from :30: :41:9: warning: 'MD4Init' macro redefined [-Wmacro-redefined] #define MD4Init _libmd_MD4Init ^ :3:9: note: previous definition is here #define MD4Init __MD4Init ^ In file included from :30: :42:9: warning: 'MD4Update' macro redefined [-Wmacro-redefined] #define MD4Update _libmd_MD4Update ^ :5:9: note: previous definition is here #define MD4Update __MD4Update ^ In file included from :30: :43:9: warning: 'MD4Pad' macro redefined [-Wmacro-redefined] #define MD4Pad _libmd_MD4Pad ^ :6:9: note: previous definition is here #define MD4Pad __MD4Pad ^ In file included from :30: :44:9: warning: 'MD4Final' macro redefined [-Wmacro-redefined] #define MD4Final _libmd_MD4Final ^ :4:9: note: previous definition is here #define MD4Final __MD4Final ^ 4 warnings generated. In file included from :38: :44:9: warning: 'SHA256_Init' macro redefined [-Wmacro-redefined] #define SHA256_Init _libmd_SHA256_Init ^ :11:9: note: previous definition is here #define SHA256_Init __SHA256_Init ^ In file included from :38: :45:9: warning: 'SHA256_Update' macro redefined [-Wmacro-redefine= d] #define SHA256_Update _libmd_SHA256_Update ^ :13:9: note: previous definition is here #define SHA256_Update __SHA256_Update ^ In file included from :38: :46:9: warning: 'SHA256_Final' macro redefined [-Wmacro-redefined= ] #define SHA256_Final _libmd_SHA256_Final ^ :12:9: note: previous definition is here #define SHA256_Final __SHA256_Final ^ 3 warnings generated. In file included from :35: :44:9: warning: 'SHA256_Init' macro redefined [-Wmacro-redefined] #define SHA256_Init _libmd_SHA256_Init ^ :11:9: note: previous definition is here #define SHA256_Init __SHA256_Init ^ In file included from :35: :45:9: warning: 'SHA256_Update' macro redefined [-Wmacro-redefine= d] #define SHA256_Update _libmd_SHA256_Update ^ :13:9: note: previous definition is here #define SHA256_Update __SHA256_Update ^ In file included from :35: :46:9: warning: 'SHA256_Final' macro redefined [-Wmacro-redefined= ] #define SHA256_Final _libmd_SHA256_Final ^ :12:9: note: previous definition is here #define SHA256_Final __SHA256_Final ^ 3 warnings generated. In file included from :38: :44:9: warning: 'SHA512_Init' macro redefined [-Wmacro-redefined] #define SHA512_Init _libmd_SHA512_Init ^ :14:9: note: previous definition is here #define SHA512_Init __SHA512_Init ^ In file included from :38: :45:9: warning: 'SHA512_Update' macro redefined [-Wmacro-redefine= d] #define SHA512_Update _libmd_SHA512_Update ^ :16:9: note: previous definition is here #define SHA512_Update __SHA512_Update ^ In file included from :38: :46:9: warning: 'SHA512_Final' macro redefined [-Wmacro-redefined= ] #define SHA512_Final _libmd_SHA512_Final ^ :15:9: note: previous definition is here #define SHA512_Final __SHA512_Final ^ 3 warnings generated. --- lib/libcom_err__L --- --- error.So --- --- lib/libcrypt__L --- In file included from :35: :44:9: warning: 'SHA512_Init' macro redefined [-Wmacro-redefined] #define SHA512_Init _libmd_SHA512_Init ^ :14:9: note: previous definition is here #define SHA512_Init __SHA512_Init ^ In file included from :35: :45:9: warning: 'SHA512_Update' macro redefined [-Wmacro-redefine= d] #define SHA512_Update _libmd_SHA512_Update ^ :16:9: note: previous definition is here #define SHA512_Update __SHA512_Update ^ In file included from :35: :46:9: warning: 'SHA512_Final' macro redefined [-Wmacro-redefined= ] #define SHA512_Final _libmd_SHA512_Final ^ :15:9: note: previous definition is here #define SHA512_Final __SHA512_Final ^ --- lib/libcom_err__L --- cc -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-protec= tor -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter= -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wc= ast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-d= efinition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety= -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-a= rguments -c -o error.So --- lib/libcrypt__L --- 3 warnings generated. --- lib/libbz2__L --- --- bzlib.So --- cc -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-protector -W= system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstr= ict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno= -pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variab= le -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -W= no-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-= arguments -c -o bzlib.So --- lib/libcom_err__L --- --- com_err.o --- cc -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsystem= -headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr= ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Ww= rite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subsc= ripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -W= no-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o com_err.o --- lib/libcrypt__L --- --- crypt.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAS_DES -DHAS_BLOWFISH -DMD4Init=3D__MD= 4Init -DMD4Final=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad= -DMD5Init=3D__MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -D= MD5Pad=3D__MD5Pad -DSHA256_Init=3D__SHA256_Init -DSHA256_Final=3D__SHA256_F= inal -DSHA256_Update=3D__SHA256_Update -DSHA512_Init=3D__SHA512_Init -DSHA5= 12_Final=3D__SHA512_Final -DSHA512_Update=3D__SHA512_Update -std=3Dgnu99 -f= stack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uniniti= alized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-= equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typede= f -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-argumen= ts -c -o crypt.So --- lib/libcom_err__L --- --- error.o --- cc -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsystem= -headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pr= ototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Ww= rite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subsc= ripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -W= no-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c = -o error.o --- lib/libcrypt__L --- --- misc.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAS_DES -DHAS_BLOWFISH -DMD4Init=3D__MD= 4Init -DMD4Final=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad= -DMD5Init=3D__MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -D= MD5Pad=3D__MD5Pad -DSHA256_Init=3D__SHA256_Init -DSHA256_Final=3D__SHA256_F= inal -DSHA256_Update=3D__SHA256_Update -DSHA512_Init=3D__SHA512_Init -DSHA5= 12_Final=3D__SHA512_Final -DSHA512_Update=3D__SHA512_Update -std=3Dgnu99 -f= stack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uniniti= alized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-= equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typede= f -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-argumen= ts -c -o misc.So --- lib/libcom_err__L --- --- libcom_err.so.5 --- building shared library libcom_err.so.5 cc -Wl,--no-undefined -Wl,--version-script=3D -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-sha= red-textrel -o libcom_err.so.5 -Wl,-soname,libcom_err.so.5 `NM=3D'nm' lor= der com_err.So error.So | tsort -q`=20 --- lib/libcrypt__L --- --- crypt-md5.So --- cc -fpic -DPIC -O2 -pipe -I -I -I -DHAS_DES -DHAS_BLOWFISH -DMD4Init=3D__MD= 4Init -DMD4Final=3D__MD4Final -DMD4Update=3D__MD4Update -DMD4Pad=3D__MD4Pad= -DMD5Init=3D__MD5Init -DMD5Final=3D__MD5Final -DMD5Update=3D__MD5Update -D= MD5Pad=3D__MD5Pad -DSHA256_Init=3D__SHA256_Init -DSHA256_Final=3D__SHA256_F= inal -DSHA256_Update=3D__SHA256_Update -DSHA512_Init=3D__SHA512_Init -DSHA5= 12_Final=3D__SHA512_Final -DSHA512_Update=3D__SHA512_Update -std=3Dgnu99 -f= stack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uniniti= alized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-c= onst-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-= equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typede= f -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-argumen= ts -c -o crypt-md5.So --- lib/libcom_err__L --- --- libcom_err.a --- building static com_err library --- lib/libcrypt__L --- In file included from :33: :10:9: error: 'MD5Init' macro redefined [-Werror,-Wmacro-redefined] #define MD5Init _libmd_MD5Init ^ :8:9: note: previous definition is here #define MD5Init __MD5Init ^ In file included from :33: :11:9: error: 'MD5Update' macro redefined [-Werror,-Wmacro-redefined= ] #define MD5Update _libmd_MD5Update ^ :10:9: note: previous definition is here #define MD5Update __MD5Update ^ In file included from :33: :12:9: error: 'MD5Pad' macro redefined [-Werror,-Wmacro-redefined] #define MD5Pad _libmd_MD5Pad ^ :11:9: note: previous definition is here #define MD5Pad __MD5Pad ^ In file included from :33: :13:9: error: 'MD5Final' macro redefined [-Werror,-Wmacro-redefined] #define MD5Final _libmd_MD5Final ^ :9:9: note: previous definition is here #define MD5Final __MD5Final ^ 4 errors generated. *** [crypt-md5.So] Error code 1 make[4]: stopped in 1 error make[4]: stopped in --- lib/libcom_err__L --- ranlib -D libcom_err.a A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib/libbz2__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib/libelf__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sun May 10 17:39:18 2015 Return-Path: Delivered-To: current@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 3190F4CA for ; Sun, 10 May 2015 17:39:18 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 903841631 for ; Sun, 10 May 2015 17:39:17 +0000 (UTC) Received: by labbd9 with SMTP id bd9so80047252lab.2 for ; Sun, 10 May 2015 10:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=zgUmXnCVAiCu9+H2Wxgm1NBJ5Kdrq6mKRatgjKNuBB8=; b=CABqm3A/ScSDJbPzDD4sH1wM8FQ7mUSXYazIBHPKXPP2pzeM6HGaPEoMyQbUIGXcaC EwQ9T4HBOEc4j4eooWx3L6u2Ket6kitoRGimWn5YiLsXAXwyfxWEIH/L/LZHYzhImuCt BiwaUrFCYi/NCU+/AejgDN/I/V6OGEObOk3eqgNFdCLC7++hROMEOwcb9zIBdcAQOcuU rDZUQlgr14gyl4peRpFrIXjnoGcolRP/CxsoxvpKiiR1wc6QSpNVdzljgs9fouYNZadH IhDqJidjTA4hRck2OdvG+K/WWLFb7jbvRNSjiMol+R31+1yPBnoM+FhNG5v9vn1z5Fjo jhdQ== MIME-Version: 1.0 X-Received: by 10.112.65.37 with SMTP id u5mr5334554lbs.44.1431279555278; Sun, 10 May 2015 10:39:15 -0700 (PDT) Received: by 10.25.31.71 with HTTP; Sun, 10 May 2015 10:39:15 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: <20150510151959.GA1215@albert.catwhisker.org> References: <20150510151959.GA1215@albert.catwhisker.org> Date: Sun, 10 May 2015 12:39:15 -0500 Message-ID: Subject: Re: Turbulence in head @r282676. From: Alan Cox To: David Wolfskill , "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:39:18 -0000 This is fixed in r282706. On Sun, May 10, 2015 at 10:19 AM, David Wolfskill wrote: > As noted yesterday, my laptop panicked trying to boot head/i386 > @r282676, but seemed OK withe head/amd64. > > That turns out to have been a bit optimistic: today, while performing a > src update on the laptop from head/amd64 from r282676 to r282719, the > laptop locked up. While I was able to reproduce the overall symptoms, I > don't know how good the match was, as I'm not sure exactly where in the > processing the machine was each of the 3 times. (After that, I gave up, > and booted the previous day's kernel (@r282623); that permitted a > complete build of sources @r282719.) > > And my build machine (which is only i386) didn't have the panic (as it > hasn't any HDA sound), but while it was running head/i386 @r282676, > builoding head/i386 @r282719, I found it sitting at a "db> " prompt. > > This appears to be a kassert_panic() in head/i386 @r282676. > > I have a crash dump and a text excerpt; here are excerpts from that > excerpt: > > Sun May 10 08:05:58 PDT 2015 > > FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1829 > r282676M/282676:1100073: Sat May 9 07:34:18 PDT 2015 > root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386 > > panic: object 0xc9dbb750 ref_count = 1 > ... > Unread portion of the kernel message buffer: > panic: object 0xc9dbb750 ref_count = 1 > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper(c11db478,0,c11b0e6c,202,f4e0e740,...) at > db_trace_self_wrapper+0x2a/frame 0xf4e0e710 > kdb_backtrace(c13a164b,1,c1216514,f4e0e7dc,1,...) at > kdb_backtrace+0x2d/frame 0xf4e0e778 > vpanic(c1216514,f4e0e7dc,c1216514,f4e0e7dc,f4e0e7dc,...) at > vpanic+0x117/frame 0xf4e0e7ac > kassert_panic(c1216514,c9dbb750,1,c1f558c0,f4e0e828,...) at > kassert_panic+0xe9/frame 0xf4e0e7d0 > vm_object_zdtor(c9dbb750,9c,0,8,10,...) at vm_object_zdtor+0x75/frame > 0xf4e0e7e8 > uma_zfree_arg(c1f558c0,c9dbb750,0) at uma_zfree_arg+0x61/frame 0xf4e0e828 > vm_object_destroy(c9dbb750,0,c1218fa3,ef,f4e0e884,...) at > vm_object_destroy+0x75/frame 0xf4e0e840 > vnode_pager_alloc(c9dad470,1015,0,0,0,...) at vnode_pager_alloc+0x68/frame > 0xf4e0e880 > vnode_create_vobject(c9dad470,1015,0,c890d000,c14730b4,...) at > vnode_create_vobject+0x1f8/frame 0xf4e0e93c > ufs_open(f4e0e9d0,c75f4c40,c84a0400,0,d3,...) at ufs_open+0x70/frame > 0xf4e0e95c > VOP_OPEN_APV(c1472a90,f4e0e9d0,100,c6d83178,f4e0e9f4,...) at > VOP_OPEN_APV+0xfe/frame 0xf4e0e988 > vn_open_vnode(c9dad470,1,c88d1700,c890d000,c7b16b60,...) at > vn_open_vnode+0x1e5/frame 0xf4e0ea00 > vn_open_cred(f4e0eb40,f4e0ebcc,0,0,c88d1700,c7b16b60) at > vn_open_cred+0x32a/frame 0xf4e0ead0 > vn_open(f4e0eb40,f4e0ebcc,0,c7b16b60,2adcfdd4,...) at vn_open+0x3d/frame > 0xf4e0eaf8 > kern_openat(c890d000,ffffff9c,2adcfdd4,0,0,0) at kern_openat+0x2ec/frame > 0xf4e0ebf0 > sys_openat(c890d000,f4e0eca8,c11cfcd9,4,c105e827,...) at > sys_openat+0x3a/frame 0xf4e0ec18 > syscall(f4e0ece8) at syscall+0x33b/frame 0xf4e0ecdc > Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf4e0ecdc > --- syscall (499, FreeBSD ELF32, sys_openat), eip = 0xa1298ff, esp = > 0xbfbfa910, ebp = 0xbfbfa928 --- > KDB: enter: panic > > Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. > Loaded symbols for /boot/kernel/tmpfs.ko.symbols > #0 doadump (textdump=0) at pcpu.h:205 > 205 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:205 > #1 0xc05311f1 in db_dump (dummy=-1061584035, dummy2=0, dummy3=-1, > dummy4=0xf4e0e4bc "") at /usr/src/sys/ddb/db_command.c:533 > #2 0xc0530d9f in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:440 > #3 0xc05309e0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 > #4 0xc053337b in db_trap (code=) > at /usr/src/sys/ddb/db_main.c:251 > #5 0xc0b98ac7 in kdb_trap (tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xc10568ff in trap (frame=) > at /usr/src/sys/i386/i386/trap.c:693 > #7 0xc10427fc in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > #8 0xc0b9835d in kdb_enter (why=0xc11d6ba9 "panic", > msg=) at cpufunc.h:60 > #9 0xc0b5a1b7 in vpanic (fmt=, ap= out>) > at /usr/src/sys/kern/kern_shutdown.c:737 > #10 0xc0b5a079 in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:634 > #11 0xc0e1ea45 in vm_object_zdtor (mem=0xc9dbb750, size=156, arg=0x0) > at /usr/src/sys/vm/vm_object.c:169 > #12 0xc0e0a691 in uma_zfree_arg (zone=0xc1f558c0, item= out>, > udata=0x10) at /usr/src/sys/vm/uma_core.c:2723 > #13 0xc0e20195 in vm_object_destroy (object=0xc9dbb750) at uma.h:364 > #14 0xc0e326d8 in vnode_pager_alloc (handle=0xc9dad470, size=4117, > prot=0 '\0', offset=0, cred=0xc88d1700) > at /usr/src/sys/vm/vnode_pager.c:240 > #15 0xc0e330d8 in vnode_create_vobject (vp=0xc9dad470, > isize=, td=0xc890d000) > at /usr/src/sys/vm/vnode_pager.c:144 > #16 0xc0dfd510 in ufs_open (ap=) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:284 > #17 0xc10849de in VOP_OPEN_APV (vop=, a=0xf4e0e9d0) > at vnode_if.c:467 > #18 0xc0c23bb5 in vn_open_vnode (vp=0xc9dad470, fmode= out>, > cred=, fp=) at vnode_if.h:196 > #19 0xc0c237da in vn_open_cred (ndp=0xf4e0eb40, flagp= out>, > vn_open_flags=, fp=) > at /usr/src/sys/kern/vfs_vnops.c:264 > #20 0xc0c2349d in vn_open (ndp=0xf4e0eb40, flagp=0xf4e0ebcc, cmode=0, > fp=0xc7b16b60) at /usr/src/sys/kern/vfs_vnops.c:166 > #21 0xc0c1b9fc in kern_openat (td=0xc890d000, fd=0, path=0x0, > pathseg=, flags=, > mode=) at /usr/src/sys/kern/vfs_syscalls.c:1090 > #22 0xc0c1bd7a in sys_openat (td=0xc890d000, uap=0xf4e0eca8) > at /usr/src/sys/kern/vfs_syscalls.c:1038 > #23 0xc105760b in syscall (frame=) at > subr_syscall.c:133 > #24 0xc1042891 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:269 > #25 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > .... > > I can make the dumps, as well as a verbose dmesg.boot, available. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Those who murder in the name of God or prophet are blasphemous cowards. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-current@FreeBSD.ORG Sun May 10 18:30:46 2015 Return-Path: Delivered-To: freebsd-current@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 D3FE4C21; Sun, 10 May 2015 18:30:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BC2E71B09; Sun, 10 May 2015 18:30:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F141A5D5; Sun, 10 May 2015 18:30:45 +0000 (UTC) Date: Sun, 10 May 2015 18:30:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, jilles@FreeBSD.org, ian@FreeBSD.org, hselasky@FreeBSD.org, thomas@FreeBSD.org Message-ID: <1700366011.5.1431282645891.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1904526881.2.1431275571828.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1904526881.2.1431275571828.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2754 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 18:30:46 -0000 See Changes: [hselasky] Ensure the result from signed subtraction under modulus does not become negative. Submitted by:=09=09Oliver Pinter MFC after:=09=093 days ------------------------------------------ [...truncated 1841 lines...] --- depend_subdir_pfbtops --- =3D=3D=3D> gnu/usr.bin/groff/src/utils/pfbtops (depend) --- _bootstrap-tools-usr.bin/xinstall --- --- obj --- created for --- _bootstrap-tools-gnu/usr.bin/groff --- --- .depend --- rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -I -I -I -std=3Dgnu99 echo pfbtops: /usr/lib/libc.a >> .depend --- _bootstrap-tools-usr.bin/xinstall --- --- .depend --- rm -f .depend --- _bootstrap-tools-gnu/usr.bin/groff --- --- depend_subdir_tfmtodit --- --- _bootstrap-tools-usr.bin/xinstall --- mkdep -f .depend -a -I -I -I -I -std=3Dgnu99 --- _bootstrap-tools-gnu/usr.bin/groff --- =3D=3D=3D> gnu/usr.bin/groff/src/utils/tfmtodit (depend) --- .depend --- rm -f .depend mkdep -f .depend -a -DHAVE_CONFIG_H -I -I -I =20 echo tfmtodit: /usr/lib/libc.a /usr/lib/libm.a >> .depend echo tfmtodit: /usr/lib/libc++.a >> .depend =3D=3D=3D> gnu/usr.bin/groff/tmac (depend) --- _bootstrap-tools-usr.bin/xinstall --- echo xinstall: /usr/lib/libc.a /usr/lib/libmd.a >> .depend --- _bootstrap-tools-gnu/usr.bin/groff --- --- _sub.all --- =3D=3D=3D> gnu/usr.bin/groff/contrib (all) --- _sub.all --- =3D=3D=3D> gnu/usr.bin/groff/contrib/mm (all) --- _bootstrap-tools-usr.bin/xinstall --- --- xinstall.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-= arguments -I -c -o xinstall.o --- _bootstrap-tools-gnu/usr.bin/groff --- =3D=3D=3D> gnu/usr.bin/groff/font (all) --- _bootstrap-tools-lib/libmd --- --- md4c.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-arguments -I -c -o md4c.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- _sub.all --- =3D=3D=3D> gnu/usr.bin/groff/font/devX100 (all) =3D=3D=3D> gnu/usr.bin/groff/font/devX100-12 (all) =3D=3D=3D> gnu/usr.bin/groff/font/devX75 (all) --- _bootstrap-tools-lib/libmd --- --- md5c.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-arguments -I -c -o md5c.o --- _bootstrap-tools-gnu/usr.bin/groff --- =3D=3D=3D> gnu/usr.bin/groff/font/devX75-12 (all) =3D=3D=3D> gnu/usr.bin/groff/font/devascii (all) --- I --- Making I --- B --- Making B --- BI --- Making BI --- S --- Making S --- _bootstrap-tools-lib/libmd --- --- md5hl.o --- --- _bootstrap-tools-gnu/usr.bin/groff --- --- L --- --- _bootstrap-tools-lib/libmd --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-arguments -I -c md5hl.c -o md= 5hl.o --- _bootstrap-tools-gnu/usr.bin/groff --- Making L --- CW --- Making CW --- R --- Making R --- DESC --- Making DESC --- _bootstrap-tools-lib/libmd --- --- rmd160c.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-arguments -I -c -o rmd160c.o --- _bootstrap-tools-gnu/usr.bin/groff --- =3D=3D=3D> gnu/usr.bin/groff/font/devcp1047 (all) --- _bootstrap-tools-usr.bin/xinstall --- --- getid.o --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-= arguments -I -c -o getid.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- I --- Making I --- B --- Making B --- BI --- Making BI --- S --- Making S --- L --- Making L --- CW --- Making CW --- R --- Making R --- DESC --- Making DESC =3D=3D=3D> gnu/usr.bin/groff/font/devdvi (all) --- _bootstrap-tools-usr.bin/xinstall --- --- xinstall --- cc -O2 -pipe -I -I -I -std=3Dgnu99 -Qunused-= arguments -I -static -L -o xinstall = xinstall.o getid.o -lmd -legacy --- _bootstrap-tools-lib/clang/libllvmsupport --- --- FormattedStream.o --- c++ -O2 -pipe -I -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMI= T_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGE= T_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-unk= nown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -Qunused-arguments -I -std=3Dc++11 -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c= ++11-extensions -c -= o FormattedStream.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- DESC --- cat >DESC if test "letter" =3D A4; then echo "papersize a4" >>DESC; else echo "pap= ersize letter" >>DESC; fi test -z 'lpr -d' || echo print 'lpr -d' >>DESC =3D=3D=3D> gnu/usr.bin/groff/font/devhtml (all) --- I --- Making I --- B --- Making B --- BI --- Making BI --- CR --- Making CR --- CI --- Making CI --- CB --- Making CB --- CBI --- Making CBI --- S --- Making S --- R --- Making R --- DESC --- Making DESC --- _bootstrap-tools-usr.bin/xinstall --- xinstall.o: In function `install': :(.text+0xdff): undefined reference to `_libmd_MD5File' --- _bootstrap-tools-gnu/usr.bin/groff --- =3D=3D=3D> gnu/usr.bin/groff/font/devkoi8-r (all) --- _bootstrap-tools-usr.bin/xinstall --- :(.text+0x12ee): undefined reference to `_libmd_MD5Init' :(.text+0x12fa): undefined reference to `_libmd_RIPEMD160_File' :(.text+0x1303): undefined reference to `_libmd_SHA1_File' :(.text+0x130c): undefined reference to `_libmd_SHA256_File' :(.text+0x1315): undefined reference to `_libmd_SHA512_File' :(.text+0x1370): undefined reference to `_libmd_RIPEMD160_Init' :(.text+0x137e): undefined reference to `_libmd_SHA1_Init' :(.text+0x138c): undefined reference to `_libmd_SHA256_Init' :(.text+0x139a): undefined reference to `_libmd_SHA512_Init' :(.text+0x1482): undefined reference to `_libmd_MD5Update' :(.text+0x150f): undefined reference to `_libmd_MD5Update' :(.text+0x1523): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x1537): undefined reference to `_libmd_SHA1_Update' :(.text+0x154b): undefined reference to `_libmd_SHA256_Update' :(.text+0x155f): undefined reference to `_libmd_SHA512_Update' :(.text+0x15d1): undefined reference to `_libmd_MD5End' :(.text+0x15e1): undefined reference to `_libmd_RIPEMD160_End' :(.text+0x15f1): undefined reference to `_libmd_SHA1_End' :(.text+0x1601): undefined reference to `_libmd_SHA256_End' :(.text+0x1611): undefined reference to `_libmd_SHA512_End' :(.text+0x180c): undefined reference to `_libmd_MD5File' :(.text+0x181c): undefined reference to `_libmd_RIPEMD160_File' :(.text+0x182c): undefined reference to `_libmd_SHA1_File' :(.text+0x183c): undefined reference to `_libmd_SHA256_File' :(.text+0x184c): undefined reference to `_libmd_SHA512_File' :(.text+0x1c44): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x1c5c): undefined reference to `_libmd_SHA1_Update' :(.text+0x1c74): undefined reference to `_libmd_SHA256_Update' :(.text+0x1c8c): undefined reference to `_libmd_SHA512_Update' xinstall.o: In function `compare': :(.text+0x23e8): undefined reference to `_libmd_MD5Init' :(.text+0x23f6): undefined reference to `_libmd_RIPEMD160_Init' :(.text+0x2404): undefined reference to `_libmd_SHA1_Init' :(.text+0x2412): undefined reference to `_libmd_SHA256_Init' :(.text+0x2420): undefined reference to `_libmd_SHA512_Init' :(.text+0x253d): undefined reference to `_libmd_MD5Update' :(.text+0x25f6): undefined reference to `_libmd_MD5Update' :(.text+0x260a): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x261e): undefined reference to `_libmd_SHA1_Update' :(.text+0x2632): undefined reference to `_libmd_SHA256_Update' :(.text+0x2646): undefined reference to `_libmd_SHA512_Update' :(.text+0x26a6): undefined reference to `_libmd_MD5End' :(.text+0x26b6): undefined reference to `_libmd_RIPEMD160_End' :(.text+0x26c6): undefined reference to `_libmd_SHA1_End' :(.text+0x26d6): undefined reference to `_libmd_SHA256_End' :(.text+0x26e6): undefined reference to `_libmd_SHA512_End' :(.text+0x2718): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x272c): undefined reference to `_libmd_SHA1_Update' :(.text+0x2740): undefined reference to `_libmd_SHA256_Update' :(.text+0x2754): undefined reference to `_libmd_SHA512_Update' --- _bootstrap-tools-lib/libmd --- --- rmd160hl.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-arguments -I -c rmd160hl.c -o= rmd160hl.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- I --- Making I --- B --- Making B --- BI --- Making BI --- S --- --- _bootstrap-tools-usr.bin/xinstall --- cc: error: linker command failed with exit code 1 (use -v to see invocation= ) --- _bootstrap-tools-gnu/usr.bin/groff --- Making S --- _bootstrap-tools-usr.bin/xinstall --- *** [xinstall] Error code 1 make[3]: stopped in 1 error make[3]: stopped in --- _bootstrap-tools-gnu/usr.bin/groff --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [_sub.all] Error code 2 make[3]: stopped in 1 error make[3]: stopped in --- _bootstrap-tools-lib/libmd --- A failure has been detected in another branch of the parallel make make[3]: stopped in --- _bootstrap-tools-lib/clang/libllvmsupport --- A failure has been detected in another branch of the parallel make make[3]: stopped in A failure has been detected in another branch of the parallel make make[2]: stopped in *** [_bootstrap-tools] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sun May 10 19:58:28 2015 Return-Path: Delivered-To: current@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 21DC0B93 for ; Sun, 10 May 2015 19:58:28 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5ED31350 for ; Sun, 10 May 2015 19:58:27 +0000 (UTC) Received: by wizk4 with SMTP id k4so83030115wiz.1 for ; Sun, 10 May 2015 12:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=7p+TCujF3kWf3VSeCk0EHnyico5y7BKjWiYPUB+ZhZ0=; b=SruhfkduETQfV2A3MmdZi3v15ztRa8Nycy+esVFARG6N+2nhA5Irp+ookd0rCZixar o1PdM6H3Evt5ixt0KTQi3F+4vv+HZ8YfbvchYFfb0m63vHwDFiWTOBZ4RP6CElZvqOrh afDuX2Sv2mFouJe1T60BJ/id2YTgeFtHsDsd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=7p+TCujF3kWf3VSeCk0EHnyico5y7BKjWiYPUB+ZhZ0=; b=f/cvGO+J/qH/hfv8ZpC7fw8Lm0fCrr4Vu003AnweysMPYml8hja+FOJDkYo+htNF47 pNDlsfCw6Rq2NZPcdAliC75sqBSN/ZG5wD/H0jDlzrvwtMewXl4a4zrBX3i4XuhhUlWb LJlZ2BJx3Qx0C/nZMIj1BC6ZOf8PHEUtP+bViJwiRqsoIC6Fc4VxDa4cTRhET+d8T6XG 9IXM5RPNqzdjtD2qqIAuNxGJ5G8Oa4tHJpBbiYtjTe07Tx8ZUcjO3KsaPV4+Tgmm7uAp zLrqI1AU+rBPvh7VVR66Zsg5o6kyyQZmeYb2cpRylEz5FK2PQn+0Q8ELCGo7+LKsjkii xbIw== X-Gm-Message-State: ALoCoQmEjMpvtECW0aD4LOJgrRspAlkGQsp7asjkWmKCsQM44vZyfXXO2jKrFMXX6kkPrqBUatgg X-Received: by 10.180.38.70 with SMTP id e6mr13414713wik.91.1431287905780; Sun, 10 May 2015 12:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.20.75 with HTTP; Sun, 10 May 2015 12:57:55 -0700 (PDT) From: Eitan Adler Date: Sun, 10 May 2015 12:57:55 -0700 Message-ID: Subject: kernel panic with ZFS & VM subsystems: refcount == 1 To: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 19:58:28 -0000 I left my computer on overnight and came back to find it sitting in ddb. Here is the backtrace and a little more information. Let me know what other debugging information I can provide. I have vmcore.1 and /boot/kernel FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r282701: Sat May 9 18:16:45 PDT 2015 eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 gdb$ b gdb$ bt #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:221 #1 0xffffffff80353f86 in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:568 #2 0xffffffff80353c6c in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0xffffffff803539d4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0xffffffff80356510 in db_trap (type=, code=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff80948f0e in kdb_trap (type=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff80d2262b in trap (frame=0xfffffe0232d601e0) at /usr/src/sys/amd64/amd64/trap.c:540 #7 0xffffffff80d03302 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:235 #8 0xffffffff809485fe in kdb_enter (why=0xffffffff80fbf391 "panic", msg=0x80
) at cpufunc.h:63 #9 0xffffffff8090c1b9 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:737 #10 0xffffffff8090c002 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xffffffff80bb03ea in vm_object_zdtor (mem=0xfffff8019f407400, size=, arg=0xfffffe0232d60190) at /usr/src/sys/vm/vm_object.c:169 #12 0xffffffff80b9d3d0 in uma_zfree_arg (zone=0xfffff8023f5de680, item=0xfffff8019f407400, udata=0x0) at /usr/src/sys/vm/uma_core.c:2723 #13 0xffffffff80bc378e in vnode_pager_alloc (handle=0xfffff8017bdb23b0, size=0xe000, prot=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vnode_pager.c:240 #14 0xffffffff80bc4051 in vnode_create_vobject (vp=0xfffff8017bdb23b0, isize=, td=0xfffff800896ba940) at /usr/src/sys/vm/vnode_pager.c:144 #15 0xffffffff81c80050 in zfs_freebsd_open (ap=0xfffffe0232d60668) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:6049 #16 0xffffffff80e62a81 in VOP_OPEN_APV (vop=, a=) at vnode_if.c:467 #17 0xffffffff809d1372 in vn_open_vnode (vp=0xfffff8017bdb23b0, fmode=Unhandled dwarf expression opcode 0x93 ) at vnode_if.h:196 #18 0xffffffff809d0f24 in vn_open_cred (ndp=0xfffffe0232d60880, flagp=0xfffffe0232d6095c, cmode=0x0, vn_open_flags=0xfffff800, cred=0xfffffe0232d60190, fp=0x0) at /usr/src/sys/kern/vfs_vnops.c:264 #19 0xffffffff809ca327 in kern_openat (td=0xfffff800896ba940, fd=0xffffff9c, path=0x800daca1f
, pathseg=UIO_USERSPACE, flags=Cannot access memory at address 0x80 ) at /usr/src/sys/kern/vfs_syscalls.c:1090 #20 0xffffffff80d2354f in amd64_syscall (td=0xfffff800896ba940, traced=0x0) at subr_syscall.c:133 #21 0xffffffff80d035eb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #22 0x0000000800d98c7a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal gdb$ info frame Stack level 10, frame at 0xfffffe0232d603b0: rip = 0xffffffff8090c002 in kassert_panic (/usr/src/sys/kern/kern_shutdown.c:634); saved rip 0xffffffff 80bb03ea called by frame at 0xfffffe0232d603d0, caller of frame at 0xfffffe0232d60340 source language minimal. Arglist at 0xfffffe0232d603a0, args: fmt= Locals at 0xfffffe0232d603a0, Previous frame's sp is 0xfffffe0232d603b0 Saved registers: rax at 0xfffffe0232d60210, rbx at 0xfffffe0232d60388, rcx at 0xfffffe0232d601f8, rdx at 0xfffffe0232d6 01f0, rsi at 0xfffffe0232d601e8, rdi at 0xfffffe0232d601e0, rbp at 0xfffffe0232d603a0, r8 at 0xfffffe0232d60200, r9 at 0xfffffe0232d60208, r10 at 0xfffffe0232d60228, r11 at 0xfffffe0232d60230, r12 at 0xfffffe0232d60318, r13 at 0xfffffe0232d60240, r14 at 0xfffffe0232d60390, r15 at 0xfffffe0232d60398, rip at 0xfffffe0232d603a8, eflags at 0xfffffe0232d60288, cs at 0xfffffe0232d60280, ss at 0xfffffe0232d60298 gdb$ up #11 0xffffffff80bb03ea in vm_object_zdtor (mem=0xfffff8019f407400, size=, arg=0xfff ffe0232d60190) at /usr/src/sys/vm/vm_object.c:169 169 KASSERT(object->ref_count == 0, gdb$ info frame Stack level 11, frame at 0xfffffe0232d603d0: rip = 0xffffffff80bb03ea in vm_object_zdtor (/usr/src/sys/vm/vm_object.c:169); saved rip 0xffffffff80b9 d3d0 called by frame at 0xfffffe0232d60430, caller of frame at 0xfffffe0232d603b0 source language minimal. Arglist at 0xfffffe0232d603c0, args: mem=0xfffff8019f407400, size=, arg=0xfffffe02 32d60190 Locals at 0xfffffe0232d603c0, Previous frame's sp is 0xfffffe0232d603d0 Saved registers: rax at 0xfffffe0232d60210, rbx at 0xfffffe0232d603b8, rcx at 0xfffffe0232d601f8, rdx at 0xfffffe0232d6 01f0, rsi at 0xfffffe0232d601e8, rdi at 0xfffffe0232d601e0, rbp at 0xfffffe0232d603c0, r8 at 0xfffffe0232d60200, r9 at 0xfffffe0232d60208, r10 at 0xfffffe0232d60228, r11 at 0xfffffe0232d60230, r12 at 0xfffffe0232d60318, r13 at 0xfffffe0232d60240, r14 at 0xfffffe0232d60390, r15 at 0xfffffe0232d60398, rip at 0xfffffe0232d603c8, eflags at 0xfffffe0232d60288, cs at 0xfffffe0232d60280, ss at 0xfffffe0232d60298 -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Sun May 10 20:11:04 2015 Return-Path: Delivered-To: current@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 8D9B8FE7 for ; Sun, 10 May 2015 20:11:04 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 159F714BA for ; Sun, 10 May 2015 20:11:03 +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 t4AKAvLH070045 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 May 2015 23:10:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t4AKAvLH070045 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t4AKAv3e070044; Sun, 10 May 2015 23:10:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 May 2015 23:10:57 +0300 From: Konstantin Belousov To: Eitan Adler Cc: "current@freebsd.org" Subject: Re: kernel panic with ZFS & VM subsystems: refcount == 1 Message-ID: <20150510201057.GV2390@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 20:11:04 -0000 On Sun, May 10, 2015 at 12:57:55PM -0700, Eitan Adler wrote: > I left my computer on overnight and came back to find it sitting in > ddb. Here is the backtrace and a little more information. Let me > know what other debugging information I can provide. I have vmcore.1 > and /boot/kernel > You did not provided the panic message. Your issue is most likely fixed by the r282706. > > FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r282701: > Sat May 9 18:16:45 PDT 2015 > eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 > > gdb$ b > gdb$ bt > #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > ) at pcpu.h:221 > #1 0xffffffff80353f86 in db_fncall (dummy1=, > dummy2=, dummy3=, > dummy4=) at /usr/src/sys/ddb/db_command.c:568 > #2 0xffffffff80353c6c in db_command (cmd_table=0x0) at > /usr/src/sys/ddb/db_command.c:440 > #3 0xffffffff803539d4 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:493 > #4 0xffffffff80356510 in db_trap (type=, > code=Unhandled dwarf expression opcode 0x93 > ) at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff80948f0e in kdb_trap (type=Unhandled dwarf expression opcode 0x93 > ) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff80d2262b in trap (frame=0xfffffe0232d601e0) at > /usr/src/sys/amd64/amd64/trap.c:540 > #7 0xffffffff80d03302 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:235 > #8 0xffffffff809485fe in kdb_enter (why=0xffffffff80fbf391 "panic", > msg=0x80
) at cpufunc.h:63 > #9 0xffffffff8090c1b9 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:737 > #10 0xffffffff8090c002 in kassert_panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:634 > #11 0xffffffff80bb03ea in vm_object_zdtor (mem=0xfffff8019f407400, > size=, arg=0xfffffe0232d60190) at > /usr/src/sys/vm/vm_object.c:169 > #12 0xffffffff80b9d3d0 in uma_zfree_arg (zone=0xfffff8023f5de680, > item=0xfffff8019f407400, udata=0x0) at /usr/src/sys/vm/uma_core.c:2723 > #13 0xffffffff80bc378e in vnode_pager_alloc > (handle=0xfffff8017bdb23b0, size=0xe000, prot=Unhandled dwarf > expression opcode 0x93 > ) at /usr/src/sys/vm/vnode_pager.c:240 > #14 0xffffffff80bc4051 in vnode_create_vobject (vp=0xfffff8017bdb23b0, > isize=, td=0xfffff800896ba940) at > /usr/src/sys/vm/vnode_pager.c:144 > #15 0xffffffff81c80050 in zfs_freebsd_open (ap=0xfffffe0232d60668) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:6049 > #16 0xffffffff80e62a81 in VOP_OPEN_APV (vop=, > a=) at vnode_if.c:467 > #17 0xffffffff809d1372 in vn_open_vnode (vp=0xfffff8017bdb23b0, > fmode=Unhandled dwarf expression opcode 0x93 > ) at vnode_if.h:196 > #18 0xffffffff809d0f24 in vn_open_cred (ndp=0xfffffe0232d60880, > flagp=0xfffffe0232d6095c, cmode=0x0, vn_open_flags=0xfffff800, > cred=0xfffffe0232d60190, fp=0x0) at /usr/src/sys/kern/vfs_vnops.c:264 > #19 0xffffffff809ca327 in kern_openat (td=0xfffff800896ba940, > fd=0xffffff9c, path=0x800daca1f
, > pathseg=UIO_USERSPACE, flags=Cannot access memory at address 0x80 > ) at /usr/src/sys/kern/vfs_syscalls.c:1090 > #20 0xffffffff80d2354f in amd64_syscall (td=0xfffff800896ba940, > traced=0x0) at subr_syscall.c:133 > #21 0xffffffff80d035eb in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:395 > #22 0x0000000800d98c7a in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > gdb$ info frame > Stack level 10, frame at 0xfffffe0232d603b0: > rip = 0xffffffff8090c002 in kassert_panic > (/usr/src/sys/kern/kern_shutdown.c:634); saved rip 0xffffffff > 80bb03ea > called by frame at > 0xfffffe0232d603d0, caller of frame at 0xfffffe0232d60340 > source language minimal. > Arglist at 0xfffffe0232d603a0, args: fmt= > Locals at 0xfffffe0232d603a0, Previous frame's sp is 0xfffffe0232d603b0 > Saved registers: > rax at 0xfffffe0232d60210, rbx at 0xfffffe0232d60388, rcx at > 0xfffffe0232d601f8, rdx at 0xfffffe0232d6 > 01f0, rsi at 0xfffffe0232d601e8, rdi at 0xfffffe0232d601e0, rbp at > 0xfffffe0232d603a0, r8 at 0xfffffe0232d60200, r9 at > 0xfffffe0232d60208, r10 at 0xfffffe0232d60228, r11 at > 0xfffffe0232d60230, r12 at 0xfffffe0232d60318, r13 at > 0xfffffe0232d60240, r14 at 0xfffffe0232d60390, r15 at > 0xfffffe0232d60398, rip at 0xfffffe0232d603a8, eflags at > 0xfffffe0232d60288, cs at 0xfffffe0232d60280, ss at 0xfffffe0232d60298 > gdb$ up > #11 0xffffffff80bb03ea in vm_object_zdtor (mem=0xfffff8019f407400, > size=, arg=0xfff > ffe0232d60190) at /usr/src/sys/vm/vm_object.c:169 > 169 > KASSERT(object->ref_count == 0, > gdb$ info frame > Stack level 11, frame at 0xfffffe0232d603d0: > rip = 0xffffffff80bb03ea in vm_object_zdtor > (/usr/src/sys/vm/vm_object.c:169); saved rip 0xffffffff80b9 > d3d0 > called by frame at > 0xfffffe0232d60430, caller of frame at 0xfffffe0232d603b0 > source language minimal. > Arglist at 0xfffffe0232d603c0, args: mem=0xfffff8019f407400, > size=, arg=0xfffffe02 > 32d60190 > Locals at 0xfffffe0232d603c0, > Previous frame's sp is 0xfffffe0232d603d0 > Saved registers: > rax at 0xfffffe0232d60210, rbx at 0xfffffe0232d603b8, rcx at > 0xfffffe0232d601f8, rdx at 0xfffffe0232d6 > 01f0, rsi at 0xfffffe0232d601e8, rdi at 0xfffffe0232d601e0, rbp at > 0xfffffe0232d603c0, r8 at 0xfffffe0232d60200, r9 at > 0xfffffe0232d60208, r10 at 0xfffffe0232d60228, r11 at > 0xfffffe0232d60230, r12 at 0xfffffe0232d60318, r13 at > 0xfffffe0232d60240, r14 at 0xfffffe0232d60390, r15 at > 0xfffffe0232d60398, rip at 0xfffffe0232d603c8, eflags at > 0xfffffe0232d60288, cs at 0xfffffe0232d60280, ss at 0xfffffe0232d60298 > > > > -- > Eitan Adler > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun May 10 20:42:27 2015 Return-Path: Delivered-To: freebsd-current@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 B4DF3612; Sun, 10 May 2015 20:42:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9E74218D6; Sun, 10 May 2015 20:42:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2865A5F2; Sun, 10 May 2015 20:42:28 +0000 (UTC) Date: Sun, 10 May 2015 20:42:28 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Message-ID: <694831986.8.1431290548132.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <803622889.4.1431279379355.JavaMail.jenkins@jenkins-9.freebsd.org> References: <803622889.4.1431279379355.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_i386 #112 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 20:42:27 -0000 See ------------------------------------------ [...truncated 73459 lines...] cc -O2 -pipe -DHAVE_CONFIG_H -I -I -std=3Dgnu99 -Qun= used-arguments -I -c -o itoa.o --- _bootstrap-tools-usr.bin/yacc --- --- yacc --- cc -O2 -pipe -DHAVE_FCNTL_H=3D1 -DHAVE_MKSTEMP=3D1 -DMAXTABLE=3DINT_MAX = -DMIXEDCASE_FILENAMES=3D1 -DYYPATCH=3D20141006 -std=3Dgnu99 -Qunused-argu= ments -I -static -L -o yacc closure.o error.o graph.o lalr.o lr0.o ma= in.o mkpar.o mstring.o output.o reader.o yaccpar.o symtab.o verbose.o warsh= all.o -legacy --- _bootstrap-tools-gnu/usr.bin/groff --- --- matherr.o --- cc -O2 -pipe -DHAVE_CONFIG_H -I -I -std=3Dgnu99 -Qun= used-arguments -I -c -o matherr.= o --- progname.o --- cc -O2 -pipe -DHAVE_CONFIG_H -I -I -std=3Dgnu99 -Qun= used-arguments -I -c -o prognam= e.o --- version.o --- c++ -O2 -pipe -DHAVE_CONFIG_H -I -I -Qunused-arguments= -I -fno-rtti -fno-exceptions -W= no-c++11-extensions -c version.cpp -o version.o --- _bootstrap-tools-lib/libmd --- =3D=3D=3D> lib/libmd (obj,depend,all,install) --- _bootstrap-tools-gnu/usr.bin/groff --- --- libgroff.a --- building static groff library --- _bootstrap-tools-lib/clang/libllvmsupport --- --- Host.o --- c++ -O2 -pipe -I -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_F= REEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRI= PLE=3D\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -Qunused-argume= nts -I -std=3Dc++11 -fno-excepti= ons -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c -o Host.o --- _bootstrap-tools-gnu/usr.bin/groff --- ranlib -D libgroff.a --- _bootstrap-tools-usr.bin/yacc --- --- _proginstall --- sh = -s -o root -g wheel -m 555 yacc --- _bootstrap-tools-gnu/usr.bin/groff --- --- all_subdir_devices --- =3D=3D=3D> gnu/usr.bin/groff/src/devices (all) --- all_subdir_grodvi --- =3D=3D=3D> gnu/usr.bin/groff/src/devices/grodvi (all) --- _bootstrap-tools-lib/libmd --- --- obj --- --- _bootstrap-tools-usr.bin/yacc --- --- _installlinks --- /usr/bin/byacc -> /usr/bin/yacc --- _bootstrap-tools-lib/libmd --- creat= ed for --- _bootstrap-tools-usr.bin/xinstall --- =3D=3D=3D> usr.bin/xinstall (obj,depend,all,install) --- _bootstrap-tools-gnu/usr.bin/groff --- --- dvi.o --- c++ -O2 -pipe -DHAVE_CONFIG_H -I -I -Qunused-argument= s -I -fno-rtti -fno-exceptions -= Wno-c++11-extensions -c -o dvi.o --- _bootstrap-tools-lib/libmd --- --- md5hl.c --- (echo '#define LENGTH 16'; sed -e 's/mdX/md5/g' -e 's/MDX/MD5/g' > md5hl.c --- rmd160hl.c --- (echo '#define LENGTH 20'; sed -e 's/mdX/ripemd/g' -e 's/MDX/RIPEMD160_/g'= -e 's/RIPEMD160__/RIPEMD160_/g' > rmd160hl.c --- sha0hl.c --- (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA_/g' -e 's/SH= A__/SHA_/g' > sha0hl.c --- sha1hl.c --- (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA1_/g' -e 's/S= HA1__/SHA1_/g' > sha1hl.c --- sha256hl.c --- (echo '#define LENGTH 32'; sed -e 's/mdX/sha256/g' -e 's/MDX/SHA256_/g'=09= -e 's/SHA256__/SHA256_/g' > sha256hl.c --- sha512hl.c --- (echo '#define LENGTH 64'; sed -e 's/mdX/sha512/g' -e 's/MDX/SHA512_/g'=09= -e 's/SHA512__/SHA512_/g' > sha512hl.c --- md4hl.c --- (echo '#define LENGTH 16'; sed -e 's/mdX/md4/g' -e 's/MDX/MD4/g' > md4hl.c --- .depend --- rm -f .depend mkdep -f .depend -a -I -DSHA1_ASM -DRMD160_ASM -I -std=3Dgnu99 md4hl.c md5hl.c rmd160hl.c sha0hl.c sha1hl.c sha256hl.c sha51= 2hl.c --- _bootstrap-tools-usr.bin/xinstall --- --- obj --- created for --- .depend --- rm -f .depend mkdep -f .depend -a -I -I -I= -I -std=3Dgnu99 --- _bootstrap-tools-lib/libmd --- := 86:9: warning: 'ripemd160_block' macro redefined #define ripemd160_block ripemd160_block_x86 ^ :9= 7:9: note: previous definition is here #define ripemd160_block _libmd_ripemd160_block ^ 1 warning generated. :10= 4:13: warning: 'sha1_block' macro redefined # define sha1_block sha1_block_x86 ^ :107:= 9: note: previous definition is here #define sha1_block _libmd_sha1_block ^ 1 warning generated. --- _bootstrap-tools-gnu/usr.bin/groff --- --- grodvi --- c++ -O2 -pipe -DHAVE_CONFIG_H -I -I -Qunused-argument= s -I -fno-rtti -fno-exceptions -= Wno-c++11-extensions -static -L -o g= rodvi dvi.o <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/= FreeBSD_HEAD_i386/tmp/jenkins/workspace/FreeBSD_HEAD_i386/gnu/usr.bin/groff= /src/devices/grodvi/../../../src/libs/libgroff/libgroff.a> -lm -legacy --- _bootstrap-tools-lib/libmd --- --- md4c.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c -o md4c.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- all_subdir_grohtml --- =3D=3D=3D> gnu/usr.bin/groff/src/devices/grohtml (all) --- _bootstrap-tools-lib/libmd --- --- md5c.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c -o md5c.o --- _bootstrap-tools-gnu/usr.bin/groff --- --- post-html.o --- c++ -O2 -pipe -DHAVE_CONFIG_H -I -I -Qunused-argume= nts -I -fno-rtti -fno-exceptions= -Wno-c++11-extensions -c -o post-html.o --- _bootstrap-tools-usr.bin/xinstall --- echo xinstall: /usr/lib/libc.a /usr/lib/libmd.a >> .depend --- xinstall.o --- cc -O2 -pipe -I -I -I -std=3Dg= nu99 -Qunused-arguments -I -c -o xinstall.o --- _bootstrap-tools-lib/libmd --- --- md5hl.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c md5hl.c -o md5hl.o --- rmd160c.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c -o rmd160c.o := 86:9: warning: 'ripemd160_block' macro redefined #define ripemd160_block ripemd160_block_x86 ^ :9= 7:9: note: previous definition is here #define ripemd160_block _libmd_ripemd160_block ^ 1 warning generated. --- rmd160hl.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c rmd160hl.c -o rmd160hl.o --- sha0c.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c -o sha0c.o --- _bootstrap-tools-usr.bin/xinstall --- --- getid.o --- cc -O2 -pipe -I -I -I -std=3Dg= nu99 -Qunused-arguments -I -c -o getid.o --- xinstall --- cc -O2 -pipe -I -I -I -std=3Dg= nu99 -Qunused-arguments -I -sta= tic -L -o xinstall xinstall.o getid.o= -lmd -legacy --- _bootstrap-tools-lib/clang/libllvmsupport --- --- IntEqClasses.o --- c++ -O2 -pipe -I -I -I -I. -I -DLLVM_ON_UNIX -DLLVM_ON_F= REEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRI= PLE=3D\"i386-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -Qunused-argume= nts -I -std=3Dc++11 -fno-excepti= ons -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c -o IntEqClasses.o --- _bootstrap-tools-lib/libmd --- --- sha0hl.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c sha0hl.c -o sha0hl.o --- sha1c.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c -o sha1c.o :10= 4:13: warning: 'sha1_block' macro redefined # define sha1_block sha1_block_x86 ^ :107:= 9: note: previous definition is here #define sha1_block _libmd_sha1_block ^ 1 warning generated. --- sha1hl.o --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c sha1hl.c -o sha1hl.o --- _bootstrap-tools-usr.bin/xinstall --- xinstall.o: In function `install': :(.text+0xf3e): undefined reference to `_libmd_MD5File' :(.text+0x148a): undefined reference to `_libmd_MD5Init' :(.text+0x14af): undefined reference to `_libmd_RIPEMD160_File' :(.text+0x14c5): undefined reference to `_libmd_SHA1_File' :(.text+0x14db): undefined reference to `_libmd_SHA256_File' :(.text+0x14f1): undefined reference to `_libmd_SHA512_File' :(.text+0x1566): undefined reference to `_libmd_RIPEMD160_Init' :(.text+0x1577): undefined reference to `_libmd_SHA1_Init' :(.text+0x1588): undefined reference to `_libmd_SHA256_Init' --- _bootstrap-tools-lib/libmd --- --- sha256c.o --- --- _bootstrap-tools-usr.bin/xinstall --- :(.text+0x1599): undefined reference to `_libmd_SHA512_Init' :(.text+0x16c5): undefined reference to `_libmd_MD5Update' :(.text+0x16ee): undefined reference to `_libmd_SHA256_Update' :(.text+0x1765): undefined reference to `_libmd_MD5Update' :(.text+0x177e): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x179a): undefined reference to `_libmd_SHA1_Update' :(.text+0x17b6): undefined reference to `_libmd_SHA512_Update' :(.text+0x1804): undefined reference to `_libmd_MD5End' :(.text+0x181d): undefined reference to `_libmd_RIPEMD160_End' :(.text+0x1836): undefined reference to `_libmd_SHA1_End' :(.text+0x184f): undefined reference to `_libmd_SHA256_End' :(.text+0x1868): undefined reference to `_libmd_SHA512_End' :(.text+0x1a91): undefined reference to `_libmd_MD5File' :(.text+0x1aa9): undefined reference to `_libmd_RIPEMD160_File' :(.text+0x1ac1): undefined reference to `_libmd_SHA1_File' :(.text+0x1ad9): undefined reference to `_libmd_SHA256_File' :(.text+0x1af1): undefined reference to `_libmd_SHA512_File' :(.text+0x1f1d): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x1f3e): undefined reference to `_libmd_SHA1_Update' --- _bootstrap-tools-lib/libmd --- cc -O2 -pipe -I -DSHA1_ASM -DRMD160_ASM -std=3Dgnu99 -Qunused-arguments -I -c -o sha256c.o --- _bootstrap-tools-usr.bin/xinstall --- :(.text+0x1f5f): undefined reference to `_libmd_SHA256_Update' :(.text+0x1f80): undefined reference to `_libmd_SHA512_Update' xinstall.o: In function `compare': :(.text+0x275b): undefined reference to `_libmd_MD5Init' :(.text+0x276c): undefined reference to `_libmd_RIPEMD160_Init' :(.text+0x277d): undefined reference to `_libmd_SHA1_Init' :(.text+0x278e): undefined reference to `_libmd_SHA256_Init' :(.text+0x279f): undefined reference to `_libmd_SHA512_Init' :(.text+0x2914): undefined reference to `_libmd_MD5Update' :(.text+0x2a07): undefined reference to `_libmd_MD5Update' :(.text+0x2a20): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x2a39): undefined reference to `_libmd_SHA1_Update' :(.text+0x2a52): undefined reference to `_libmd_SHA256_Update' :(.text+0x2a6b): undefined reference to `_libmd_SHA512_Update' :(.text+0x2af6): undefined reference to `_libmd_MD5End' :(.text+0x2b0f): undefined reference to `_libmd_RIPEMD160_End' :(.text+0x2b28): undefined reference to `_libmd_SHA1_End' :(.text+0x2b41): undefined reference to `_libmd_SHA256_End' :(.text+0x2b5a): undefined reference to `_libmd_SHA512_End' :(.text+0x2b87): undefined reference to `_libmd_RIPEMD160_Update' :(.text+0x2ba4): undefined reference to `_libmd_SHA1_Update' :(.text+0x2bc1): undefined reference to `_libmd_SHA256_Update' :(.text+0x2bde): undefined reference to `_libmd_SHA512_Update' cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [xinstall] Error code 1 make[3]: stopped in 1 error make[3]: stopped in --- _bootstrap-tools-gnu/usr.bin/groff --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [all_subdir_grohtml] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [all_subdir_devices] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [_sub.all] Error code 2 make[3]: stopped in 1 error make[3]: stopped in --- _bootstrap-tools-lib/clang/libllvmsupport --- A failure has been detected in another branch of the parallel make make[3]: stopped in --- _bootstrap-tools-lib/libmd --- A failure has been detected in another branch of the parallel make make[3]: stopped in A failure has been detected in another branch of the parallel make make[2]: stopped in *** [_bootstrap-tools] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon May 11 00:14:39 2015 Return-Path: Delivered-To: current@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 8A3AEA3 for ; Mon, 11 May 2015 00:14:39 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 489BA1DFF for ; Mon, 11 May 2015 00:14:39 +0000 (UTC) Received: by wgbhc8 with SMTP id hc8so13574929wgb.2 for ; Sun, 10 May 2015 17:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=89cDfsMHFXw6r/1v/6VVnzxXl7mq5tJyV8+n9gxd6FE=; b=gyOVWan9owQErXVuvg4goevWNDok2VGzxNIMR9Fvxc91S0Hj0GJDh3V6dSPAxpr/hQ lnMhHwV4iLBazoCEoFiMruKgl348LprVQ6yh9tP4GQcyOByN2QYDYOdySuyZNzf3gliu RZGVRYsybTjsKuMRd8EhRyIUg9kufOCS+R5uA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=89cDfsMHFXw6r/1v/6VVnzxXl7mq5tJyV8+n9gxd6FE=; b=O7V2BDT7i9bkPL+wcudsx7C5sVhYUNsqI8fHVR1ZjQVBviWDPJn3eswyAnVMVB/HWe G7EAGPpnFpHV4afUSgsipAWJSC3ngeMQm+6Xr2RvGLsgU3eQpOsW8uKfNsKAKNqV3eps 2cA35cOOLI7Kv1FpppGOhFseUlWRvbDwBLVU0jHpR5OzQAbvJM4BuS1syGYvQqi5udzt KYuU+RgLspKk+X3TU8roQFj/XRsMOUz93s3ZQKOk2HP9qZO6jzTfNLNloGPc7LWkHxGX 9gZdeXOL8UPQCsrI6DdlIEWCmRO/Dbe140H/bKaYNul8nnR1RPNUTz/gaxpUuz9lERfC V/mg== X-Gm-Message-State: ALoCoQnVhE1OIo5GL5MH7ww96crz+cguAw0WwBFTxOf/dBTr1JC7wORm8uFQHjntSApHbse9fIoX X-Received: by 10.194.9.6 with SMTP id v6mr15528762wja.13.1431303277180; Sun, 10 May 2015 17:14:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.20.75 with HTTP; Sun, 10 May 2015 17:14:06 -0700 (PDT) In-Reply-To: <20150510201057.GV2390@kib.kiev.ua> References: <20150510201057.GV2390@kib.kiev.ua> From: Eitan Adler Date: Sun, 10 May 2015 17:14:06 -0700 Message-ID: Subject: Re: kernel panic with ZFS & VM subsystems: refcount == 1 To: Konstantin Belousov Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 00:14:39 -0000 On 10 May 2015 at 13:10, Konstantin Belousov wrote: > On Sun, May 10, 2015 at 12:57:55PM -0700, Eitan Adler wrote: >> I left my computer on overnight and came back to find it sitting in >> ddb. Here is the backtrace and a little more information. Let me >> know what other debugging information I can provide. I have vmcore.1 >> and /boot/kernel >> > You did not provided the panic message. > Your issue is most likely fixed by the r282706. Seems likely. Interestingly, compiling a kernel reliably triggered the panic. I reverted to an old kernel, updated sources, and rebuilt. Will capture more information if it happens again. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Mon May 11 02:17:53 2015 Return-Path: Delivered-To: freebsd-current@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 5F32936A; Mon, 11 May 2015 02:17:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4ACE91921; Mon, 11 May 2015 02:17:53 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 64BE0683; Mon, 11 May 2015 02:17:53 +0000 (UTC) Date: Mon, 11 May 2015 02:17:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, adrian@FreeBSD.org, markj@FreeBSD.org, sjg@FreeBSD.org, rpaulo@FreeBSD.org, thomas@FreeBSD.org Message-ID: <700965817.10.1431310673380.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <694831986.8.1431290548132.JavaMail.jenkins@jenkins-9.freebsd.org> References: <694831986.8.1431290548132.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_i386 #113 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 02:17:53 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 11 06:51:58 2015 Return-Path: Delivered-To: freebsd-current@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 E624DEC6; Mon, 11 May 2015 06:51:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D276314BA; Mon, 11 May 2015 06:51:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6F17B703; Mon, 11 May 2015 06:51:59 +0000 (UTC) Date: Mon, 11 May 2015 06:51:59 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, jilles@FreeBSD.org, ian@FreeBSD.org, hselasky@FreeBSD.org, thomas@FreeBSD.org Message-ID: <1159493302.13.1431327119334.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1700366011.5.1431282645891.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1700366011.5.1431282645891.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2755 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 06:51:59 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 11 09:00:57 2015 Return-Path: Delivered-To: freebsd-current@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 564DBBA0 for ; Mon, 11 May 2015 09:00:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 43E061366 for ; Mon, 11 May 2015 09:00:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B5B23738 for ; Mon, 11 May 2015 09:00:56 +0000 (UTC) Date: Mon, 11 May 2015 09:00:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <888154015.14.1431334855288.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #1025 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 09:00:57 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 11 09:31:09 2015 Return-Path: Delivered-To: freebsd-current@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 12A2A3C8 for ; Mon, 11 May 2015 09:31:09 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 BE73B170F for ; Mon, 11 May 2015 09:31:08 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 8322F6ABECE; Mon, 11 May 2015 11:31:03 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t4B9V35d052361; Mon, 11 May 2015 11:31:03 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t4B9V1YW048487; Mon, 11 May 2015 11:31:01 +0200 (CEST) (envelope-from lars) Date: Mon, 11 May 2015 11:31:01 +0200 From: Lars Engels To: Jos Backus Cc: Lyndon Nerenberg , freebsd-current Subject: Re: What to do about RCS/OpenRCS Message-ID: <20150511093100.GC53149@e-new.0x20.net> Mail-Followup-To: Lars Engels , Jos Backus , Lyndon Nerenberg , freebsd-current References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 09:31:09 -0000 --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: > Maybe off-topic, but functionality-wise it might make much more sense to > import Fossil. RCS has too many limitations this day and age when better > tools are available. Of course, this would require people to learn > something new, which I know can be a challenge. I really like fossil. But it's still under development, so it would soon be outdated. It's better installed from ports/packages. --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJVUHbUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tpUMH/2LzUP+0+o4HwPjrbjvZEzz8 OqRabkcBJp3zhMsOmJXqCPzIDTWBJwOkutRam1gig4SUZa81X9pxEiUaOYy2mx/d 0XdcN2ieeoCobhKyybyhWXmRpYOhyvYHIhpaiXgc3htE8GZUldz3sS5M39fBBKj7 c18idBg32HiKVMsM0OPad9ciye6Yxj1nf0igcFJtQlqvDM1n2ig4T7vgtNkUrgY8 +jtLDJgOJ70YgGJt0wUbBq/cNFP6+xIBtvoqODExW/aGT2qx3kGFdKNrc3RmE0se DxHSU7PvW5QWxONdd9k/QLw5+cb5SZaZq2YyeXJLZv8Z5FHRxdRq/H/OZFGvcrE= =2TH6 -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB-- From owner-freebsd-current@FreeBSD.ORG Mon May 11 15:49:29 2015 Return-Path: Delivered-To: freebsd-current@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 C937AE5E for ; Mon, 11 May 2015 15:49:29 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2801431 for ; Mon, 11 May 2015 15:49:29 +0000 (UTC) Received: by pacwv17 with SMTP id wv17so113046971pac.0 for ; Mon, 11 May 2015 08:49:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2gkq65fi5HuWEuUJNn1HBUk1ucd0P+l2gWSaessF5QA=; b=NkL+2ufzHF8WPKNzQR4HJt5iH/VIIGdkv4FpbNqGZrD37slb/6kE45pF88q//p9rXL XGQl4XD5vtYovmQ37DqRXy8xav2a7L4NLtSdtpG5srXHXb4jDVER0qsAs7hJtghEf2pZ KzFitqqVljYouHnbXbbkuJvPp14X5GzPV3hSyvg7XNwsKIB1WeauPA7Y5juCnxs06PIS qAerKDbnZPZUKeDXY90M9PPDED+5Mfo2JK2ardv83wEAGPUG/YMAPorJYLh1HtIUfpH0 Xsa03abdKps8aNZEICjKU2jFnRdGTjijiwvvWPwiSHsFQJ/mOziTrEdSPnTGHd8Qjix1 44AA== X-Gm-Message-State: ALoCoQlxujF0dlSktlBk05aeZ9z9EahIh2tJxaLqVInO17MFISTaGt2OcRKx3be0dLrc/JFcwP1U MIME-Version: 1.0 X-Received: by 10.68.232.194 with SMTP id tq2mr20280121pbc.90.1431358986320; Mon, 11 May 2015 08:43:06 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Mon, 11 May 2015 08:43:06 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Mon, 11 May 2015 08:43:06 -0700 (PDT) In-Reply-To: <20150511093100.GC53149@e-new.0x20.net> References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> Date: Mon, 11 May 2015 08:43:06 -0700 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: Jos Backus To: Lars Engels , freebsd-current , Lyndon Nerenberg Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:49:30 -0000 On May 11, 2015 2:31 AM, "Lars Engels" wrote: > > On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: > > Maybe off-topic, but functionality-wise it might make much more sense to > > import Fossil. RCS has too many limitations this day and age when better > > tools are available. Of course, this would require people to learn > > something new, which I know can be a challenge. > > I really like fossil. But it's still under development, so it would soon > be outdated. It's better installed from ports/packages. It seems OpenRCS is still under development ;-p It's better installed from ports/packages, too. It would give Fossil a recognition boost as a BSD-licensed DVCS. Jos From owner-freebsd-current@FreeBSD.ORG Mon May 11 15:50:32 2015 Return-Path: Delivered-To: freebsd-current@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 02EABFF1 for ; Mon, 11 May 2015 15:50:32 +0000 (UTC) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.232]) by mx1.freebsd.org (Postfix) with ESMTP id BB26D150A for ; Mon, 11 May 2015 15:50:31 +0000 (UTC) Received: from [96.28.24.204] ([96.28.24.204:28658] helo=[192.168.209.109]) by dnvrco-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 77/D6-18241-38FC0555; Mon, 11 May 2015 15:49:24 +0000 Message-ID: <1431359362.10811.2.camel@gemini.bsd1.net> Subject: Re: nmount, mountd drops high order MNT_xx flags during a mount update From: David Boyd To: Rick Macklem Cc: Doug Rabson , freebsd current , Edward Tomasz =?UTF-8?Q?Napiera=C5=82a?= Date: Mon, 11 May 2015 11:49:22 -0400 In-Reply-To: <917688730.35175530.1431263274444.JavaMail.root@uoguelph.ca> References: <917688730.35175530.1431263274444.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-31.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.64.130:25 X-Authority-Analysis: v=2.1 cv=XJy+SGRE c=1 sm=1 tr=0 a=LAeh8JulWguKKqZdjpwXog==:117 a=LAeh8JulWguKKqZdjpwXog==:17 a=ayC55rCoAAAA:8 a=IkcTkHD0fZMA:10 a=UNWf5WQ7AAAA:8 a=mjlnPRs6AAAA:8 a=6I5d2MoRAAAA:8 a=4RTEIeP134CyENfvOlIA:9 a=QEXdDO2ut3YA:10 X-Cloudmark-Score: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:50:32 -0000 On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote: > Oops, I did my usual and forgot to attach the patch. > > Here it is, rick > > ----- Original Message ----- > > Doug Rabson wrote: > > > You could add a single integer-valued vfsopt which holds the > > > high-order > > > bits of f_flags? > > > > > I have created a patch that does this. It is on > > https://reviews.freebsd.org/D2506 > > (I have also attached it here, for those who don't use Phabricator.) > > > > Please review/comment on this. (Feel free to add yourself as a > > reviewer, etc.) > > > > Also, David, if you can test this patch, it would be appreciated. > > > > Thanks for the suggestion Doug, rick > > > > > On 7 May 2015 at 02:10, Rick Macklem wrote: > > > > > > > David Boyd reported a problem to freebsd-current@ w.r.t. the > > > > MNT_AUTOMOUNTED > > > > flag getting cleared by mountd. > > > > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > > > I just took a look at this and it's kinda ugly... > > > > > > > > mountd acquires a list of mounts via getmntinfo() and then does > > > > an > > > > nmount() for each of them to get rid of any exports. It uses > > > > f_flags from the statfs returned by getmntinfo() as the 3rd > > > > argument to nmount(). > > > > --> Since nmount()s 3rd argument is a "int", it silently drops > > > > any > > > > MNT_xx flag in the high order 32bits of f_flags. At this > > > > time, > > > > it happens that MNT_AUTOMOUNTED is the only one, but... > > > > > > > > I can think of a couple of ways to fix this, but I don't like any > > > > of > > > > them;-) > > > > > > > > 1) I suppose mountd could check for each flag set in f_flags and > > > > generate > > > > a vfsopts string for it, but that means that every time a new > > > > flag > > > > that > > > > can be updated is added to MNT_xx, this mountd.c code would have > > > > to > > > > updated. > > > > --> Ugly!! > > > > > > > > 2) Require that all flags in MNT_UPDATEMASK be in the low order > > > > 32bits. > > > > I wouldn`t mind this except in means that the MNT_xx flags > > > > must > > > > be > > > > redefined > > > > and I don`t think that could get MFC`d. > > > > > > > > 3) Add a new newernmount(2) which has a 64bit flags argument > > > > instead of > > > > int. > > > > > > > > Hopefully someone can think of a nice way to fix this, rick > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to > > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Rick, Edward, et al, I have applied your patches to several (four) servers and have not noticed any more instances of the errant behavior. I think (hope) that this is the correct fix and wonder if this fix might make it's way into an errata. Thanks for the quick responses. David Boyd. From owner-freebsd-current@FreeBSD.ORG Mon May 11 15:52:42 2015 Return-Path: Delivered-To: freebsd-current@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 D0D931E3 for ; Mon, 11 May 2015 15:52:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BDF1E1553 for ; Mon, 11 May 2015 15:52:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 50C857F9 for ; Mon, 11 May 2015 15:52:41 +0000 (UTC) Date: Mon, 11 May 2015 15:52:40 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <733318287.16.1431359560548.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <888154015.14.1431334855288.JavaMail.jenkins@jenkins-9.freebsd.org> References: <888154015.14.1431334855288.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #1026 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 15:52:42 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 11 16:11:01 2015 Return-Path: Delivered-To: freebsd-current@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 B2FF95FE for ; Mon, 11 May 2015 16:11:01 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F1BF16F0 for ; Mon, 11 May 2015 16:11:01 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t4BGAo5x089880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 May 2015 09:10:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t4BGAnqn089879; Mon, 11 May 2015 09:10:49 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 May 2015 09:10:49 -0700 From: Steve Kargl To: Jos Backus Cc: Lars Engels , freebsd-current , Lyndon Nerenberg Subject: Re: What to do about RCS/OpenRCS Message-ID: <20150511161049.GA89855@troutmask.apl.washington.edu> References: <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:11:01 -0000 On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: > On May 11, 2015 2:31 AM, "Lars Engels" wrote: > > > > On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: > > > Maybe off-topic, but functionality-wise it might make much more sense to > > > import Fossil. RCS has too many limitations this day and age when better > > > tools are available. Of course, this would require people to learn > > > something new, which I know can be a challenge. > > > > I really like fossil. But it's still under development, so it would soon > > be outdated. It's better installed from ports/packages. > > It seems OpenRCS is still under development ;-p It's better installed from > ports/packages, too. > > It would give Fossil a recognition boost as a BSD-licensed DVCS. > Please, just stop. Thanks. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon May 11 16:17:04 2015 Return-Path: Delivered-To: freebsd-current@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 D95CC750 for ; Mon, 11 May 2015 16:17:04 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 AECEC17CC for ; Mon, 11 May 2015 16:17:04 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8E02220B4F for ; Mon, 11 May 2015 12:17:03 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Mon, 11 May 2015 12:17:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=u4y5U1JgOh2nhXd qfJr16XWffWk=; b=quZBcOXdW4huRAQmS+qL9XYCoSQbqXJ1YxZDJdqy3ov7K2Z 4fwxL21S8BuqLZSjMlEdv8+rMOt8yslErOtUB69hiMijFlmJxFd59d4osma14m0B xVyPnQv0s658dIHISYtIM4wt0FImoLqhmxAjkQ4iTyk8SZ2SPmYIdK4ckyEA= Received: by web3.nyi.internal (Postfix, from userid 99) id 653C7110212; Mon, 11 May 2015 12:17:03 -0400 (EDT) Message-Id: <1431361023.2444239.265770073.51A54CE6@webmail.messagingengine.com> X-Sasl-Enc: nA6S2lpsW/bhDPCCbVCSRId/4hM7NiIOZnYf5wCuSXfR 1431361023 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-102d4956 Subject: Re: Turbulence in head @r282676. Date: Mon, 11 May 2015 11:17:03 -0500 In-Reply-To: References: <20150510151959.GA1215@albert.catwhisker.org> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:17:04 -0000 On Sun, May 10, 2015, at 12:39, Alan Cox wrote: > This is fixed in r282706. > > The r282694 snapshots (amd64 at least) are useless because of this bug and was causing me constant crashing. From owner-freebsd-current@FreeBSD.ORG Mon May 11 16:21:23 2015 Return-Path: Delivered-To: freebsd-current@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 2132A8D1 for ; Mon, 11 May 2015 16:21:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F12C6181B for ; Mon, 11 May 2015 16:21:22 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t4BGLM6O090031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 May 2015 09:21:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t4BGLLfY090030; Mon, 11 May 2015 09:21:21 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 May 2015 09:21:21 -0700 From: Steve Kargl To: Jos Backus Cc: freebsd-current@freebsd.org Subject: Re: What to do about RCS/OpenRCS Message-ID: <20150511162121.GA89954@troutmask.apl.washington.edu> References: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> <20150511161049.GA89855@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:21:23 -0000 On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote: >On May 11, 2015 9:10 AM, "Steve Kargl" > wrote: >> >> On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: >>> On May 11, 2015 2:31 AM, "Lars Engels" wrote: >>>> >>>> On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: >>>>> Maybe off-topic, but functionality-wise it might make >>>>> much more sense to import Fossil. RCS has too many limitations >>>>> this day and age when better >>>>> tools are available. Of course, this would require people to learn >>>>> something new, which I know can be a challenge. >>>> >>>> I really like fossil. But it's still under development, so it >>>> would soon be outdated. It's better installed from ports/packages. >>> >>> It seems OpenRCS is still under development ;-p It's better >>> installed from ports/packages, too. >>> >>> It would give Fossil a recognition boost as a BSD-licensed DVCS. >>> >> >> Please, just stop. Thanks. > > Like I said, a challenge. > You've completely missed the point. OpenRCS is intended to replace ancient GNU RCS, which is already included in the base system and used by a few scripts. Fossil is not a drop-in replacement for the rcs utilities. So, please just stop. PS: Please reply to the list not directly to me. CC stored. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon May 11 16:27:55 2015 Return-Path: Delivered-To: freebsd-current@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 E15CEAE0 for ; Mon, 11 May 2015 16:27:54 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B62561909 for ; Mon, 11 May 2015 16:27:54 +0000 (UTC) Received: by pdea3 with SMTP id a3so151798306pde.3 for ; Mon, 11 May 2015 09:27:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=mOvrJvfkQ3S6IGIofJD1G8eVAzk2mZ1EsE0jceWCQIQ=; b=N2zJQMIPYJWfmcYXW7FsutOP5kBFdnJINWxq/iGGtMkuNW2UArg7Hpzro/wmF1wxvu WgJiLKzyp+Bmu4Sg5L65uhG6AZkAsOQxdrQfIzxEH0ImfyKVcDJ2cc09Shjtf/B8D5RS 6mP80i0LVGL/BxR5RbDh21tuTgKBUZZq7JdCNXLxCdLHKFRUrlzrRSonAx+lAW22MdqE HL2tP6oz53xXc+PtfgSBqwmH7o7vOYyk4BVWMhhHxt0CF6ijmPY0bKjPQnAuCUMrXZjq W/ehOD9uVyjDvbKpgiTe2+VvR5XZtD9z715inLjjn/ycMi2wEZw3ASmdYu6CxXQxRZ1d XMMQ== X-Gm-Message-State: ALoCoQluCUyxpEdcV/QcmfRL/I7aFIcC2dgieDLXTZZS96ULAp2R/08VkAm+O40S+ghkuOpu4H0/ MIME-Version: 1.0 X-Received: by 10.70.63.1 with SMTP id c1mr20592427pds.90.1431361667917; Mon, 11 May 2015 09:27:47 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Mon, 11 May 2015 09:27:47 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Mon, 11 May 2015 09:27:47 -0700 (PDT) In-Reply-To: <20150511162121.GA89954@troutmask.apl.washington.edu> References: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> <20150511161049.GA89855@troutmask.apl.washington.edu> <20150511162121.GA89954@troutmask.apl.washington.edu> Date: Mon, 11 May 2015 09:27:47 -0700 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: Jos Backus Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:27:55 -0000 On May 11, 2015 9:21 AM, "Steve Kargl" wrote: > > On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote: > >On May 11, 2015 9:10 AM, "Steve Kargl" > > wrote: > >> > >> On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: > >>> On May 11, 2015 2:31 AM, "Lars Engels" wrote: > >>>> > >>>> On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: > >>>>> Maybe off-topic, but functionality-wise it might make > >>>>> much more sense to import Fossil. RCS has too many limitations > >>>>> this day and age when better > >>>>> tools are available. Of course, this would require people to learn > >>>>> something new, which I know can be a challenge. > >>>> > >>>> I really like fossil. But it's still under development, so it > >>>> would soon be outdated. It's better installed from ports/packages. > >>> > >>> It seems OpenRCS is still under development ;-p It's better > >>> installed from ports/packages, too. > >>> > >>> It would give Fossil a recognition boost as a BSD-licensed DVCS. > >>> > >> > >> Please, just stop. Thanks. > > > > Like I said, a challenge. > > > > You've completely missed the point. OpenRCS is intended > to replace ancient GNU RCS, which is already included in the > base system and used by a few scripts. Fossil is not a > drop-in replacement for the rcs utilities. I didn't miss anything. My point is that debating to update one piece of obsolete software with another is silly, and that FreeBSD should try to move forward in this area. But that's hard, as your response indicates. This is the last I'll say about this, because it appears the community isn't ready. Have fun with your ancient version control while Linux continues to grow in market share. :-( Jos > So, please just stop. > > PS: Please reply to the list not directly to me. CC stored. > > -- > Steve From owner-freebsd-current@FreeBSD.ORG Mon May 11 16:33:51 2015 Return-Path: Delivered-To: freebsd-current@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 241DFC30 for ; Mon, 11 May 2015 16:33:51 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7FA21A27 for ; Mon, 11 May 2015 16:33:49 +0000 (UTC) Received: from dhcp-172-17-153-170.eduroam.wireless.private.cam.ac.uk (global-1-26.nat.csx.cam.ac.uk [131.111.184.26]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t4BGXZwr018733 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2015 16:33:36 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host global-1-26.nat.csx.cam.ac.uk [131.111.184.26] claimed to be dhcp-172-17-153-170.eduroam.wireless.private.cam.ac.uk Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: What to do about RCS/OpenRCS From: David Chisnall In-Reply-To: Date: Mon, 11 May 2015 17:33:30 +0100 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <4AA6F972-0684-4B20-8FCC-9B41B58F85D7@FreeBSD.org> References: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> <20150511161049.GA89855@troutmask.apl.washington.edu> <20150511162121.GA89954@troutmask.apl.washington.edu> To: Jos Backus X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:33:51 -0000 On 11 May 2015, at 17:27, Jos Backus wrote: >=20 > I didn't miss anything. My point is that debating to update one piece = of > obsolete software with another is silly, and that FreeBSD should try = to > move forward in this area. But that's hard, as your response = indicates. Steve is correct, and you are missing the point. Fossil, Git, = Mercurial, and so on are all available as packages. No one is = suggesting using RCS in preference to any of them. =20 Deleting RCS from the base system would be nice, but unfortunately we = can=E2=80=99t because of scripts that depend on some components of RCS. = Replacing these with the OpenRCS equivalents (if they work) would allow = us to remove a GPL=E2=80=99d piece of code from the base system. As = long as this doesn=E2=80=99t come with a functionality regression, this = would be a nice thing to do. Replacing RCS in the base system with Fossil solves no problems that = actually exist. It does not allow the scripts that rely on RCS to = continue to work and it does not make Fossil easier to use (would you = really want to stick with the one in the base system for the entire = lifetime of a major release, rather than use the packaged one?). It = would only make sense if we were to move FreeBSD development to Fossil = and currently there are a few showstoppers in Fossil that prevent this. > This is the last I'll say about this, because it appears the community > isn't ready. Have fun with your ancient version control while Linux > continues to grow in market share. :-( And now you=E2=80=99re moving beyond missing the point and just = trolling. David From owner-freebsd-current@FreeBSD.ORG Mon May 11 16:41:27 2015 Return-Path: Delivered-To: freebsd-current@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 2A3C7DF5 for ; Mon, 11 May 2015 16:41:27 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8E631A7D for ; Mon, 11 May 2015 16:41:26 +0000 (UTC) Received: by wiun10 with SMTP id n10so103538978wiu.1 for ; Mon, 11 May 2015 09:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=8JaKxkqvALnuWKBEhUIuiJxILKuBKb414q/Slprx6PU=; b=H3VvShksoUjuV8VJpOFeDneXBu8nQDPeAgYGix5G+C1YrYrcrVIxKd1sMyLnjiKS0b OKQTF9dTigPsfvhiHx05HJ8tK1b3b4nXSMM8bjliZXqldcZARjBxgUKKesAgty/Rentu bXjd6eNhMQo6Ah2x8iJQQVDIQqeT6df9cXYRRNfA58GqbepdihMdXJeI/4/0TxgzOHd4 plZSFapEnrPj823qp2BtNVklq8Ywrorik4aQYkdIyxPNyrCylMsgZiMuB7FPaIji4AjE LRy4e5wmb28+h8RTt51gbWGwyfZaXds9kGKj5OULR+uAB4BsjW1ulAYJX9R4DwZnPyaA LI1Q== X-Received: by 10.180.91.137 with SMTP id ce9mr887751wib.76.1431362484977; Mon, 11 May 2015 09:41:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.179.84 with HTTP; Mon, 11 May 2015 09:41:04 -0700 (PDT) From: sadegh solati Date: Mon, 11 May 2015 21:11:04 +0430 Message-ID: Subject: Weird problem with rand_harvestq To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:41:27 -0000 Hi, I am using FreeBSD 10.0-RELEASE #0 r260789. the following lines are a section of ps command out put on my server. as you see in second line rand_harvestq made completely busy one core my four cores CPU . The OS got very slow and top output doesn't show cpu usage . top output ======================== last pid: 40488; load averages: 2.57, 0.69, 0.34 up 6+22:29:24 11:38:01 74 processes: 2 running, 72 sleeping CPU: % user, % nice, % system, % interrupt, % idle Mem: 50M Active, 1128M Inact, 718M Wired, 1780K Cache, 622M Buf, 4040M Free Swap: 4096M Total, 4096M Free ps output ========================= USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 11 300.0 0.0 0 64 - R Delivered-To: freebsd-current@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 2C11D5FC; Mon, 11 May 2015 17:05:15 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 37D141D9A; Mon, 11 May 2015 17:05:12 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4BH52Eo013908; Mon, 11 May 2015 10:05:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4BH4qcJ013905; Mon, 11 May 2015 10:04:52 -0700 (PDT) (envelope-from david) Date: Mon, 11 May 2015 10:04:52 -0700 From: David Wolfskill To: Mark Felder Cc: freebsd-current@freebsd.org Subject: Re: Turbulence in head @r282676. Message-ID: <20150511170452.GG1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Mark Felder , freebsd-current@freebsd.org References: <20150510151959.GA1215@albert.catwhisker.org> <1431361023.2444239.265770073.51A54CE6@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GUPx2O/K0ibUojHx" Content-Disposition: inline In-Reply-To: <1431361023.2444239.265770073.51A54CE6@webmail.messagingengine.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 17:05:15 -0000 --GUPx2O/K0ibUojHx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 11, 2015 at 11:17:03AM -0500, Mark Felder wrote: >=20 >=20 > On Sun, May 10, 2015, at 12:39, Alan Cox wrote: > > This is fixed in r282706. > >=20 > >=20 >=20 > The r282694 snapshots (amd64 at least) are useless because of this bug > and was causing me constant crashing. > ... On a positive note, my update this morning from r282719 to r282766 for amd64 was sufficiently uneventful to qualify as "fairly boring" -- which I consider A Good Thing. :-} On a less-positive note, the most recent head/i386 that I have been able to boot was r282623 -- r282676, r282719, and r282766 all panic in the HDA device attach code with: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r =3D 0 (0xcfef... src/sys/= dev/sound/pci/hda/hdaa.c:1571 as cited in . Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --GUPx2O/K0ibUojHx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVUOE0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7/GkP/RIigMBJvkeJuX6ijimhBsXU B7VPKvFVXAjrOH314k5PkCoV+lEUnwCJbImuERr+vH//eskIdmBuq+PfSd4jtEDX x9YgkwOeDmoQDvah9WmuntLG9QLlLYgjB5m79VB7Lq3jKeB+I1HB7VbRrmB58T0o 3E20PngXaEawZRH/ZKt1Ngbffy3S9GeHZW1x81c0vd3Llyxyz4fLHKlMMLLpoQTm x6FNQuyLodW5HbG8Zuk2frJkAZNiTKPYjkNavatqmKh7zpi3Yo55Sk2ji+hepkWB G3fOV1Ocax27nt0C/uP/YamRcJOgypayXknmeEygHSdNPHAIHNLrtrYB0JPaiQtZ lagqKgJDsQZZFSSw5ljQ09dqLes2oOmlwyxaazkp009g1KWiYw8k1nKkavdLT/Ar EkPY0eUTL0O5wgm99uu3Z8PDc+ZiuX7TZH0sp3TLtfNmmeEMfap3uWBtuEnm6lT8 PjDWDD4z8Jk8DHbDnumxKdwgntVSbiyoHUqEZYR9DunQA9sMFO+4yDpkWvw29aGP TW21N4QCCOzv0kR6IW5svS4l9RHsIAV+T3b0ojamJEl7axGuEmecSvr+XIJFq7LY 5xQcAL31iyGNrXysLSO525K7khLyr4VQSsSt5s6u4HX3bo2jjx5gT7njxahWBKN+ PFm0P7zrvwu4X8AXqcPP =ZX9S -----END PGP SIGNATURE----- --GUPx2O/K0ibUojHx-- From owner-freebsd-current@FreeBSD.ORG Mon May 11 17:12:12 2015 Return-Path: Delivered-To: freebsd-current@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 8F036776 for ; Mon, 11 May 2015 17:12:12 +0000 (UTC) Received: from relay.mailchannels.net (ar-005-i191.relay.mailchannels.net [162.253.144.73]) by mx1.freebsd.org (Postfix) with ESMTP id BD7231E85 for ; Mon, 11 May 2015 17:12:10 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id BF0EB4474; Mon, 11 May 2015 17:12:02 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (smtp3.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 11 May 2015 17:12:03 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1431364322963:2020095474 X-MC-Ingress-Time: 1431364322963 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp3.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YrrFH-0006oY-Kw; Mon, 11 May 2015 17:12:00 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4BHBr8B076295; Mon, 11 May 2015 11:11:54 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18VD+ohUnOLMYMPFq0sGq6a Message-ID: <1431364313.6170.238.camel@freebsd.org> Subject: Re: What to do about RCS/OpenRCS From: Ian Lepore To: Jos Backus Cc: freebsd-current Date: Mon, 11 May 2015 11:11:53 -0600 In-Reply-To: References: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> <20150511161049.GA89855@troutmask.apl.washington.edu> <20150511162121.GA89954@troutmask.apl.washington.edu> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 17:12:12 -0000 On Mon, 2015-05-11 at 09:27 -0700, Jos Backus wrote: > On May 11, 2015 9:21 AM, "Steve Kargl" > wrote: > > > > On Mon, May 11, 2015 at 09:12:57AM -0700, Jos Backus wrote: > > >On May 11, 2015 9:10 AM, "Steve Kargl" > > > wrote: > > >> > > >> On Mon, May 11, 2015 at 08:43:06AM -0700, Jos Backus wrote: > > >>> On May 11, 2015 2:31 AM, "Lars Engels" wrote: > > >>>> > > >>>> On Sat, May 09, 2015 at 11:27:57AM -0700, Jos Backus wrote: > > >>>>> Maybe off-topic, but functionality-wise it might make > > >>>>> much more sense to import Fossil. RCS has too many limitations > > >>>>> this day and age when better > > >>>>> tools are available. Of course, this would require people to learn > > >>>>> something new, which I know can be a challenge. > > >>>> > > >>>> I really like fossil. But it's still under development, so it > > >>>> would soon be outdated. It's better installed from ports/packages. > > >>> > > >>> It seems OpenRCS is still under development ;-p It's better > > >>> installed from ports/packages, too. > > >>> > > >>> It would give Fossil a recognition boost as a BSD-licensed DVCS. > > >>> > > >> > > >> Please, just stop. Thanks. > > > > > > Like I said, a challenge. > > > > > > > You've completely missed the point. OpenRCS is intended > > to replace ancient GNU RCS, which is already included in the > > base system and used by a few scripts. Fossil is not a > > drop-in replacement for the rcs utilities. > > I didn't miss anything. My point is that debating to update one piece of > obsolete software with another is silly, and that FreeBSD should try to > move forward in this area. But that's hard, as your response indicates. > > This is the last I'll say about this, because it appears the community > isn't ready. Have fun with your ancient version control while Linux > continues to grow in market share. :-( So you're saying that it's not that you're missing the point, it's just that you're trolling the list. That will be remembered. (Of course, it's clear to those who've actually read the thread that you are in fact completely missing the point.) -- Ian From owner-freebsd-current@FreeBSD.ORG Mon May 11 17:17:34 2015 Return-Path: Delivered-To: freebsd-current@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 83E19A1E for ; Mon, 11 May 2015 17:17:34 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 572E01EBE for ; Mon, 11 May 2015 17:17:33 +0000 (UTC) Received: by pabsx10 with SMTP id sx10so114790086pab.3 for ; Mon, 11 May 2015 10:17:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jxy62r2St3xsssKmUcHPQ/ndjqFgruwkGYGdNvJltGk=; b=KsHvgw79KVHdPnurQdj8sKSwGwgYjjcVSd/fyA3ZbkPi7do7WXEMkcM031vnx1t5NE wFUtyE80LUGFXlq2u4n82UbWpEIGCWF5yB+UbB/CW0MO+LySETNraFb/Py3sN5XvtwwK rNat0sYHsjqTB92HRxGezgxzlxAJQ3l3cahwibqTN4Pv12LF+i3sNVNxYc4GCvA2ClVM vHh/Rx2MwPG/LIF2/sO/+TxV1AHTP4rokVAs4ux6Fkti7XCj1XHIjs6rJ4O/QoSC0Dt0 ICNxJWW2ZnZiO862vNDs08kV0HeaMRhZEiLfWQVJKYYt87WJIHHh6Ib40XGpjpG6mBT6 lceA== X-Gm-Message-State: ALoCoQl/OCnvz5NhrS1hHjlHYIi4wLcaZAPxTFuz1SEEmQ9XTRPqIJ1lWWmcN8SB4h+QRE7XKuvA MIME-Version: 1.0 X-Received: by 10.66.66.108 with SMTP id e12mr21161050pat.155.1431364647159; Mon, 11 May 2015 10:17:27 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Mon, 11 May 2015 10:17:26 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Mon, 11 May 2015 10:17:26 -0700 (PDT) In-Reply-To: <4AA6F972-0684-4B20-8FCC-9B41B58F85D7@FreeBSD.org> References: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> <20150511093100.GC53149@e-new.0x20.net> <20150511161049.GA89855@troutmask.apl.washington.edu> <20150511162121.GA89954@troutmask.apl.washington.edu> <4AA6F972-0684-4B20-8FCC-9B41B58F85D7@FreeBSD.org> Date: Mon, 11 May 2015 10:17:26 -0700 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: Jos Backus To: David Chisnall Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 17:17:34 -0000 On May 11, 2015 9:33 AM, "David Chisnall" wrote: [snip] > And now you=E2=80=99re moving beyond missing the point and just trolling. Thanks for the ad hominen, David. You continue to make my point. Over and out, Jos > David > From owner-freebsd-current@FreeBSD.ORG Mon May 11 19:52:44 2015 Return-Path: Delivered-To: freebsd-current@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 AD008F47 for ; Mon, 11 May 2015 19:52:44 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 702D1137A for ; Mon, 11 May 2015 19:52:44 +0000 (UTC) Received: by iepj10 with SMTP id j10so114357978iep.0 for ; Mon, 11 May 2015 12:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Qq84hm8pupYIUAZSL88vQIbio5Glmk9xT3PQPtaAKJA=; b=JziqGlS5pMW7vgVNJGtQ1wk1fPMjLGoPd367FYJAljHQkeqViu/2VaFSJGbY47iimL g060hqpU6NyxdEukewoZCuAcioQry3vs93GtZ9THFcVbHgyUOk+jrtfcXw3XsqA1HJiI eVj4fHGxRjOV+7Vj+RDqR3ZI7ibG0+eb/TwqvBF5wI8D7HnWUUrnfAvyUGOjYre8iKj3 jLPqMPS/9vUBjTTAxOzIMfl+GkDX8bTRSQUjcq0uuoIBgVQhUJSZF2IB/A+V4z/7GAwG npXxZlpinKPe3uR8sPUNTQlEp1zM6/7HMbKbwE44QmHsJtzqdcriBq2hEKeneLhvncwf FASw== X-Received: by 10.50.43.226 with SMTP id z2mr14997684igl.33.1431373963809; Mon, 11 May 2015 12:52:43 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.48.3 with HTTP; Mon, 11 May 2015 12:52:23 -0700 (PDT) In-Reply-To: <554F91DE.8010209@selasky.org> References: <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> <20150509210525.GA80848@lyxys.ka.sub.org> <554F5379.2070100@selasky.org> <20150510165330.GA86856@lyxys.ka.sub.org> <554F8BA6.9000702@selasky.org> <554F91DE.8010209@selasky.org> From: Ed Maste Date: Mon, 11 May 2015 15:52:23 -0400 X-Google-Sender-Auth: g4dhcL1Kblh158kBNvDb64ARqsw Message-ID: Subject: Re: Race VT+X11 on -current To: Hans Petter Selasky Cc: Oliver Pinter , Wolfgang Zenker , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 19:52:44 -0000 On 10 May 2015 at 13:14, Hans Petter Selasky wrote: > > Your patch is correct from what I can see. Signed modulus can be creepy > sometimes! Better if VT_MAXWINDOWS was power of two and we used a bitwise > AND. The patch is correct, although signedness doesn't come into play. The unsigned vw_number just wraps to 2^32-1, which is 3 modulo 12. From owner-freebsd-current@FreeBSD.ORG Mon May 11 21:16:00 2015 Return-Path: Delivered-To: freebsd-current@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 255FDE8D for ; Mon, 11 May 2015 21:16:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2E91D67 for ; Mon, 11 May 2015 21:16:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 61A3687B for ; Mon, 11 May 2015 21:15:55 +0000 (UTC) Date: Mon, 11 May 2015 21:15:53 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1105899419.18.1431378953760.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <733318287.16.1431359560548.JavaMail.jenkins@jenkins-9.freebsd.org> References: <733318287.16.1431359560548.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1027 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 21:16:00 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 11 23:06:40 2015 Return-Path: Delivered-To: current@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 D108C4A7 for ; Mon, 11 May 2015 23:06:40 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67AF31982 for ; Mon, 11 May 2015 23:06:40 +0000 (UTC) Received: by wggj6 with SMTP id j6so7605066wgg.3 for ; Mon, 11 May 2015 16:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=TNFhjXHnhcUqyN2PVzODkpY6EZeXfjhxhCzY9BZfEMU=; b=NJ6oupuSxbOXDeZlT6FvT/XZJ+nvRdw78SjI/S2/4Bp0Fi+XkWKNTp9wyATOwV6kks 5SBFKnt0ARgVk80NFznnaqZd1Wnc2WM89KVYSseF3Rr8OdsL1L0e0jXUJpJZwexyONRU /9VO/I6PdGHkEvwb9wlWsoy66WgP7Ui5+9oUDDm+uHMQzjkbwvfFTJnl6Y2uH6VTIWii n9amLGs3pWjywMavUlG0iLum3iHyeSG3yaaK+vpR516uUVT+RM9eQW0B2D0+jXkVCKQb Q09sKnzmMXicWmK7VnZjIP1gZ/r7GZdk43axZdOUSsC6NgZkDb+/XSKjN9UJEbyhjU3l ThFg== X-Received: by 10.180.88.99 with SMTP id bf3mr24538368wib.75.1431385598801; Mon, 11 May 2015 16:06:38 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n1sm47042wix.0.2015.05.11.16.06.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2015 16:06:37 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 12 May 2015 01:06:35 +0200 From: Baptiste Daroussin To: current@FreeBSD.org Subject: Increase BUFSIZ to 8192 Message-ID: <20150511230635.GA46991@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:06:40 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I would like to change the default value of BUFSIZ to 8192. After testing various applications that uses BUFSIZ like changing it in libmd I can often see performance improvements: For example with md5(1): Current BUFSIZ (1024) 0.13 real 0.04 user 0.09 sys New BUFSIZ (8192) 0.08 real 0.04 user 0.03 sys sha256(1): Before: 0.44 real 0.39 user 0.04 sys After: 0.37 real 0.35 user 0.01 sys This is done on a small amd64 Lenovo S20 laptop Review available here: https://reviews.freebsd.org/D2515 Any opinion? Best regards, Bapt --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVRNfsACgkQ8kTtMUmk6Ews+wCgkk/8OWO/DVpvzFgpPqgwhxaj 7dkAoJQw0rRLbnpNL3gdr7BprYWnZOnH =yWcN -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-current@FreeBSD.ORG Mon May 11 23:14:47 2015 Return-Path: Delivered-To: current@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 48A1567C; Mon, 11 May 2015 23:14:47 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 149CE1AD2; Mon, 11 May 2015 23:14:47 +0000 (UTC) Received: by iepj10 with SMTP id j10so118414654iep.0; Mon, 11 May 2015 16:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lRmM3Rdd6hg1+4WK+C1h9zRzTIuYmKFPEUX6PuQOmeA=; b=Dz9Vpj0mB7pZBSP7zS4sxYMZh9HK9u+vUacIYxgyBdipp7PQHplIz+eqbhmDNdnMFQ z/pL4nKrxZbyXTNDxj04OmcvKTXFa+OEB3XnR7K8XS9wjXyNtW5TxS7IZAlOM0WQiZi5 rW72+qHhU/k/6aQXUCuEDAoPUpdhgPUMQ6naLlS+kb02fgpF2Qchen2VfgrHiStaEuOG 68IcTXvEjqLsx07H++y5M5/H7aXnBXmXVqQKTMhsHHRUAcHeiXanzVzTBpJmZGsQYp76 N4T/SddUI6NeUwH3CNKlVUCgK2vIQIV5HEcpbryEvhiHOurFGEt9ZfxzbUBE71PvSidq vrgQ== MIME-Version: 1.0 X-Received: by 10.107.46.39 with SMTP id i39mr15875547ioo.8.1431386086381; Mon, 11 May 2015 16:14:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 11 May 2015 16:14:46 -0700 (PDT) In-Reply-To: <20150511230635.GA46991@ivaldir.etoilebsd.net> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> Date: Mon, 11 May 2015 16:14:46 -0700 X-Google-Sender-Auth: DnkawK_Zq00leierG1HNhBywD-c Message-ID: Subject: Re: Increase BUFSIZ to 8192 From: Adrian Chadd To: Baptiste Daroussin Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:14:47 -0000 So I'm curious - why's it faster? -adrian From owner-freebsd-current@FreeBSD.ORG Tue May 12 03:23:15 2015 Return-Path: Delivered-To: current@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 3AB00417; Tue, 12 May 2015 03:23:15 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ADB871622; Tue, 12 May 2015 03:23:14 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4C3N7Ek005366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 May 2015 20:23:07 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4C3N7XQ005365; Mon, 11 May 2015 20:23:07 -0700 (PDT) (envelope-from jmg) Date: Mon, 11 May 2015 20:23:07 -0700 From: John-Mark Gurney To: Baptiste Daroussin Cc: current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150512032307.GP37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150511230635.GA46991@ivaldir.etoilebsd.net> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 11 May 2015 20:23:07 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 03:23:15 -0000 Baptiste Daroussin wrote this message on Tue, May 12, 2015 at 01:06 +0200: > I would like to change the default value of BUFSIZ to 8192. > > After testing various applications that uses BUFSIZ like changing it in libmd I > can often see performance improvements: > > For example with md5(1): > Current BUFSIZ (1024) > 0.13 real 0.04 user 0.09 sys > New BUFSIZ (8192) > 0.08 real 0.04 user 0.03 sys > > sha256(1): > Before: > 0.44 real 0.39 user 0.04 sys > After: > 0.37 real 0.35 user 0.01 sys > > This is done on a small amd64 Lenovo S20 laptop > > Review available here: > https://reviews.freebsd.org/D2515 personally, I think the applications that are abusing BUFSIZ should be fixed to use a properly sized buffer for their applications... BUFSIZ is defined for the default stdio buffer sizes... I got significant perf improvement many years ago by fixed lpd to use a sane BUFSIZ... And did the same recently w/ nc (bumping from 2k to 16k, though I'd'f liked to go larger)... Also, you'd probably see even better performance by increasing the size to 64k, though as with all things, this means more memory use on smaller systems (though on smaller/slower systems, this may be an even bigger win)... This mostly just reduces number of context switches... -- 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-current@FreeBSD.ORG Tue May 12 08:13:07 2015 Return-Path: Delivered-To: freebsd-current@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 5991CB03 for ; Tue, 12 May 2015 08:13:07 +0000 (UTC) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBFAF18B3 for ; Tue, 12 May 2015 08:13:06 +0000 (UTC) Received: by wgic8 with SMTP id c8so129843380wgi.1 for ; Tue, 12 May 2015 01:13:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eLZkSzTypeDsj+TbwUT7af0Qul+KkdtPQYc7QjFaW80=; b=fYCATnjGk5axb2TtAUytpzpZfku1Y3sg+yVWbBogWDnoDgVGtgvq53uwbIwcR1gHKt 78Xqkiid5nVQna3CwxjSjLzGkhw0NHkBmNyG/obtKTgWl9NDwLwaT2AyCX0nycMRI4ID nOmCMpJsf3GRFMA6dk2iZ5qkh3lWHQ+LIZgbvSOubFQmzHMWOnCcY10BgxNCmJ53FiV1 7y3yTOD/YV8HDL4b41ZS8CqI5OZGkmlkbdaYDV76oIaj1NQNDZjJR7YIveaqjyTTErKw IFOBP586lPaNkXWl9+kkwzaztzz1//5eFdARbUFdcBf7t3dWVFLKzzcUwLbDjs1QcgFZ q79g== X-Gm-Message-State: ALoCoQltcEid9jU2mJ4/D6xPVpe4Znj2FwL5fYdli0WO61RsIdtFRJcVOBLfub2B2Bg7ErQ0RIfx X-Received: by 10.180.84.67 with SMTP id w3mr3051248wiy.68.1431418384720; Tue, 12 May 2015 01:13:04 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id m1sm1606734wiw.7.2015.05.12.01.13.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 01:13:03 -0700 (PDT) Message-ID: <5551B60F.6010407@multiplay.co.uk> Date: Tue, 12 May 2015 09:13:03 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 References: <20150511230635.GA46991@ivaldir.etoilebsd.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 08:13:07 -0000 4k block size on the underlying device? On 12/05/2015 00:14, Adrian Chadd wrote: > So I'm curious - why's it faster? > > > -adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue May 12 11:33:05 2015 Return-Path: Delivered-To: current@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 D17E19D3; Tue, 12 May 2015 11:33:05 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 183481F77; Tue, 12 May 2015 11:33:05 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E4D583BB88; Tue, 12 May 2015 11:24:46 +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 t4C6VXo6014995; Tue, 12 May 2015 06:31:34 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney cc: Baptiste Daroussin , current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <20150512032307.GP37063@funkthat.com> From: "Poul-Henning Kamp" References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14991.1431412293.1@critter.freebsd.dk> Date: Tue, 12 May 2015 06:31:33 +0000 Message-ID: <14994.1431412293@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 11:33:05 -0000 -------- In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney writes: >Also, you'd probably see even better performance by increasing the >size to 64k, [...] easy: 8K on 32bit 64k on 64bit -- 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-current@FreeBSD.ORG Tue May 12 12:04:07 2015 Return-Path: Delivered-To: current@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 DEFF9509; Tue, 12 May 2015 12:04:07 +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 9A430131F; Tue, 12 May 2015 12:04:07 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Ys8ui-0009RI-JG; Tue, 12 May 2015 15:03:56 +0300 Date: Tue, 12 May 2015 15:03:56 +0300 From: Slawa Olhovchenkov To: Poul-Henning Kamp Cc: John-Mark Gurney , Baptiste Daroussin , current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150512120356.GE1394@zxy.spb.ru> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14994.1431412293@critter.freebsd.dk> 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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:04:08 -0000 On Tue, May 12, 2015 at 06:31:33AM +0000, Poul-Henning Kamp wrote: > >Also, you'd probably see even better performance by increasing the > >size to 64k, [...] > > easy: > 8K on 32bit > 64k on 64bit Need benchmarking. May be 16K is local maximum (L1 cache-efficient). From owner-freebsd-current@FreeBSD.ORG Tue May 12 12:10:21 2015 Return-Path: Delivered-To: freebsd-current@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 3CEBD6DD; Tue, 12 May 2015 12:10:21 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id D63071399; Tue, 12 May 2015 12:10:20 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwA4CE9V/95baINcg2NeBoMYwUQJgU4KhTdOAoFVFAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCwUHDxgCAg0ZAikBCSYGCAcEARwEiAMIDbNXknoBAQEBAQEBAQEBAQEBAQEBAQEBGYEhihiEMwEBHDQHgmiBRQWWW4JGgU2DVj6DHIdqIoIGg3KDVSOCCRyBbiIxAQEBAQOBBTmBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,414,1427774400"; d="scan'208";a="210359025" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 May 2015 08:10:18 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7FC3CB3F67; Tue, 12 May 2015 08:10:17 -0400 (EDT) Date: Tue, 12 May 2015 08:10:17 -0400 (EDT) From: Rick Macklem To: David Boyd Cc: Doug Rabson , freebsd current , Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Message-ID: <1435928923.36294067.1431432617509.JavaMail.root@uoguelph.ca> In-Reply-To: <1431359362.10811.2.camel@gemini.bsd1.net> Subject: Re: nmount, mountd drops high order MNT_xx flags during a mount update MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 12:10:21 -0000 David Boyd wrote: > On Sun, 2015-05-10 at 09:07 -0400, Rick Macklem wrote: > > Oops, I did my usual and forgot to attach the patch. > > > > Here it is, rick > > > > ----- Original Message ----- > > > Doug Rabson wrote: > > > > You could add a single integer-valued vfsopt which holds the > > > > high-order > > > > bits of f_flags? > > > > > > > I have created a patch that does this. It is on > > > https://reviews.freebsd.org/D2506 > > > (I have also attached it here, for those who don't use > > > Phabricator.) > > > > > > Please review/comment on this. (Feel free to add yourself as a > > > reviewer, etc.) > > > > > > Also, David, if you can test this patch, it would be appreciated. > > > > > > Thanks for the suggestion Doug, rick > > > > > > > On 7 May 2015 at 02:10, Rick Macklem > > > > wrote: > > > > > > > > > David Boyd reported a problem to freebsd-current@ w.r.t. the > > > > > MNT_AUTOMOUNTED > > > > > flag getting cleared by mountd. > > > > > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > > > > I just took a look at this and it's kinda ugly... > > > > > > > > > > mountd acquires a list of mounts via getmntinfo() and then > > > > > does > > > > > an > > > > > nmount() for each of them to get rid of any exports. It uses > > > > > f_flags from the statfs returned by getmntinfo() as the 3rd > > > > > argument to nmount(). > > > > > --> Since nmount()s 3rd argument is a "int", it silently > > > > > drops > > > > > any > > > > > MNT_xx flag in the high order 32bits of f_flags. At this > > > > > time, > > > > > it happens that MNT_AUTOMOUNTED is the only one, but... > > > > > > > > > > I can think of a couple of ways to fix this, but I don't like > > > > > any > > > > > of > > > > > them;-) > > > > > > > > > > 1) I suppose mountd could check for each flag set in f_flags > > > > > and > > > > > generate > > > > > a vfsopts string for it, but that means that every time a new > > > > > flag > > > > > that > > > > > can be updated is added to MNT_xx, this mountd.c code would > > > > > have > > > > > to > > > > > updated. > > > > > --> Ugly!! > > > > > > > > > > 2) Require that all flags in MNT_UPDATEMASK be in the low > > > > > order > > > > > 32bits. > > > > > I wouldn`t mind this except in means that the MNT_xx flags > > > > > must > > > > > be > > > > > redefined > > > > > and I don`t think that could get MFC`d. > > > > > > > > > > 3) Add a new newernmount(2) which has a 64bit flags argument > > > > > instead of > > > > > int. > > > > > > > > > > Hopefully someone can think of a nice way to fix this, rick > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to > > > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to > > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to > > > "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > Rick, Edward, et al, > > I have applied your patches to several (four) servers and have not > noticed any more instances of the errant behavior. > Thanks for testing it and confirming that the problem is what I thought it was. > I think (hope) that this is the correct fix and wonder if this fix > might > make it's way into an errata. > Well, at this point, it isn't obvious if it should even go in head/current. (See https://reviews.freebsd.org/D2506) The patch already in head/current (r281699) should fix your problem. (It stops mountd from updating non-exported mounts.) It has not been MFC'd, but I will look into that. I don't know if it could also be an errata. Since it now appears to be a fix for an observed bug and not just an optimization, maybe? rick > Thanks for the quick responses. > > David Boyd. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 12 21:21:37 2015 Return-Path: Delivered-To: current@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 8DB4D54E for ; Tue, 12 May 2015 21:21:37 +0000 (UTC) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2a00:d1e0:1000:c00::25]) (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 DF3DA1847 for ; Tue, 12 May 2015 21:21:36 +0000 (UTC) Received: from cloud.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 3lmXBP32BBzVnHk for ; Tue, 12 May 2015 21:21:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cloud.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id 9Rs-miyeyH16 for ; Tue, 12 May 2015 21:21:33 +0000 (UTC) Received: from tifa.daemonic.se (c-4c10e555.012-98-73746f24.cust.bredbandsbolaget.se [85.229.16.76]) by mail.daemonic.se (Postfix) with ESMTPSA id 3lmXBP0BVczVnHj for ; Tue, 12 May 2015 21:21:33 +0000 (UTC) Received: from tifa.daemonic.se (localhost [127.0.0.1]) by tifa.daemonic.se (Postfix) with ESMTP id 9FD5922818 for ; Tue, 12 May 2015 23:21:33 +0200 (CEST) Message-ID: <55526EDD.4050105@freebsd.org> Date: Tue, 12 May 2015 23:21:33 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: current@freebsd.org Subject: Panic using QLogic NetXtreme II BCM57810 with latest CURRENT snapshot X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:21:37 -0000 Hi! I got the following panic with a QLogic NetXtreme II BCM57810 when trying to assign an IP address using dhclient. The network card uses the bxe driver. The machine in question is a HP DL380 Gen9. Kernel page fault with the following non-sleepable locks held: shared rw if_addr_lock (if_addr_lock) locked @ /usr/src/sys/net/if.c:1539 exclusive sleep mutex bxe0_mcast_lock lockeed @ /usr/src/sys/dev/bxe/bxe.c:12548 See screenshots at the links below for details and a stack trace. I can provoke this panic at will, let me know if you need more details. Unfortunately I don't have access to a console where I can copy things out currently, so screenshots have to do. Screenshot 1: https://people.freebsd.org/~zeising/panic1.png Screenshot 2: https://people.freebsd.org/~zeising/panic2.png Regards! -- Niclas From owner-freebsd-current@FreeBSD.ORG Wed May 13 05:45:32 2015 Return-Path: Delivered-To: current@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 84938161; Wed, 13 May 2015 05:45:32 +0000 (UTC) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E15E1EB3; Wed, 13 May 2015 05:45:32 +0000 (UTC) Received: by oica37 with SMTP id a37so23323596oic.0; Tue, 12 May 2015 22:45:31 -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=PkJuGgt3/wgtOcacQCyc0iq2F0U3sEER/NjFA5rYLc0=; b=NgbX2FfXyGwYWbN+RVZ5IB865F8+pLlaGQdeJVF19WXi+3Rnd1A6qblFWRW52P1eDT BJad/5H3cRA4Wdvrb/nbN+gexcRpS25I80pcE9+ufWyN0emXfUktR/2wbkkmk9p7XGGQ FypkV/Evh5lAU2d3VrDsthqKRFpQa3wrlsD0n+ACPqNSi5ctTtPfjnwIwROOtLeltMx5 YaQVmrP79T+Dvqg6P6S/QgLWp8kLVZxxdzrO7IiFiAuIdmBeRW8y043gTua9z+r0d8jx IAbf+k3HyanbgWOS0uo2URatVH+8fqLkSh7Z4j7dwp6qNxdAd+TFxL14kO1wcxlt/fzx Ll9w== MIME-Version: 1.0 X-Received: by 10.60.123.83 with SMTP id ly19mr14655770oeb.13.1431495930885; Tue, 12 May 2015 22:45:30 -0700 (PDT) Received: by 10.202.214.133 with HTTP; Tue, 12 May 2015 22:45:30 -0700 (PDT) In-Reply-To: <55526EDD.4050105@freebsd.org> References: <55526EDD.4050105@freebsd.org> Date: Wed, 13 May 2015 08:45:30 +0300 Message-ID: Subject: Re: Panic using QLogic NetXtreme II BCM57810 with latest CURRENT snapshot From: Sergey Kandaurov To: Niclas Zeising Cc: current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 05:45:32 -0000 On 13 May 2015 at 00:21, Niclas Zeising wrote: > Hi! > I got the following panic with a QLogic NetXtreme II BCM57810 when > trying to assign an IP address using dhclient. The network card uses > the bxe driver. The machine in question is a HP DL380 Gen9. > > Kernel page fault with the following non-sleepable locks held: > shared rw if_addr_lock (if_addr_lock) locked @ /usr/src/sys/net/if.c:1539 > exclusive sleep mutex bxe0_mcast_lock lockeed @ > /usr/src/sys/dev/bxe/bxe.c:12548 > > See screenshots at the links below for details and a stack trace. > I can provoke this panic at will, let me know if you need more details. > Unfortunately I don't have access to a console where I can copy things > out currently, so screenshots have to do. > > Screenshot 1: https://people.freebsd.org/~zeising/panic1.png > Screenshot 2: https://people.freebsd.org/~zeising/panic2.png > I'm not in any way a network/bxe expert, and this is probably unrelated, but I see there at least a missing unlock at the error path. Index: sys/dev/bxe/bxe.c =================================================================== --- sys/dev/bxe/bxe.c (revision 282468) +++ sys/dev/bxe/bxe.c (working copy) @@ -12551,6 +12551,7 @@ rc = ecore_config_mcast(sc, &rparam, ECORE_MCAST_CMD_DEL); if (rc < 0) { BLOGE(sc, "Failed to clear multicast configuration: %d\n", rc); + BXE_MCAST_UNLOCK(sc); return (rc); } BXE_MCAST_LOCK acquires two locks: sc mutex, and if_maddr_rlock(ifp) OTOH, in bxe_init_mcast_macs_list(), down the path, if_maddr_rlock is acquired (and released) one more time: in if_multiaddr_array / if_multiaddr_count functions. Is it recursive? Another one is bcopy under lock. It is probably inlined under bxe_handle_rx_mode_tq() in ddb, so the actual place where it's called is not visible. My guess is bcopy in bxe_init_mcast_macs_list(): bcopy((mta + (i * ETHER_ADDR_LEN)), mc_mac->mac, ETHER_ADDR_LEN); Previously, there was a pointer assignment, see stable/10: mc_mac->mac = (uint8_t *)LLADDR((struct sockaddr_dl *)ifma->ifma_addr); mc_mac itself is malloc(M_ZERO)'ed, so that mc_mac->mac is NULL. Probably bcopy should be restored to assignment (not even compile tested): Index: sys/dev/bxe/bxe.c =================================================================== --- sys/dev/bxe/bxe.c (revision 282468) +++ sys/dev/bxe/bxe.c (working copy) @@ -12506,7 +12506,7 @@ to be different */ for(i=0; i< mcnt; i++) { - bcopy((mta + (i * ETHER_ADDR_LEN)), mc_mac->mac, ETHER_ADDR_LEN); + mc_mac->mac = (uint8_t *)(mta + (i * ETHER_ADDR_LEN)); ECORE_LIST_PUSH_TAIL(&mc_mac->link, &p->mcast_list); BLOGD(sc, DBG_LOAD, -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed May 13 08:03:50 2015 Return-Path: Delivered-To: current@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 4A720ABA; Wed, 13 May 2015 08:03:50 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCB651E63; Wed, 13 May 2015 08:03:49 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4D83g4H045482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 01:03:42 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4D83gX6045481; Wed, 13 May 2015 01:03:42 -0700 (PDT) (envelope-from jmg) Date: Wed, 13 May 2015 01:03:42 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Cc: Baptiste Daroussin , current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150513080342.GE37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14994.1431412293@critter.freebsd.dk> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 13 May 2015 01:03:43 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 08:03:50 -0000 Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +0000: > -------- > In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney writes: > > >Also, you'd probably see even better performance by increasing the > >size to 64k, [...] > > easy: > 8K on 32bit > 64k on 64bit Sounds good to me... Just for people who care... I did a quick set of benchmarks on sha256.. This is using my preliminary patch to use sse4 optimized sha256... But this should be the same for others... The numbers in ministat output are the time in seconds it takes my 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so lower numbers are better.. I've processed them into easier to read format: BUFSIZ: 145MB/sec 8k: 193MB/sec 16k: 198MB/sec 64k: 202MB/sec 128k: 202MB/sec -t: 211MB/sec x def.times + 8k.times * 16k.times % 64k.times # 128k.times +-------------------------------------------------------------------------+ |#% * + x | |#% * + x | |#% * + x | |## * + xx| |A| A A |A|| +-------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 3.53 3.55 3.53 3.536 0.0089442719 + 5 2.65 2.66 2.65 2.654 0.0054772256 Difference at 95.0% confidence -0.882 +/- 0.0108161 -24.9434% +/- 0.305885% (Student's t, pooled s = 0.0074162) * 5 2.58 2.59 2.58 2.584 0.0054772256 Difference at 95.0% confidence -0.952 +/- 0.0108161 -26.9231% +/- 0.305885% (Student's t, pooled s = 0.0074162) % 5 2.53 2.54 2.54 2.538 0.004472136 Difference at 95.0% confidence -0.998 +/- 0.0103127 -28.224% +/- 0.29165% (Student's t, pooled s = 0.00707107) # 5 2.53 2.54 2.53 2.532 0.004472136 Difference at 95.0% confidence -1.004 +/- 0.0103127 -28.3937% +/- 0.29165% (Student's t, pooled s = 0.00707107) -- 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-current@FreeBSD.ORG Wed May 13 08:27:21 2015 Return-Path: Delivered-To: current@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 B25F22CB; Wed, 13 May 2015 08:27:21 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E5481107; Wed, 13 May 2015 08:27:20 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t4D8RBgn031684 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 08:27:12 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Increase BUFSIZ to 8192 From: David Chisnall In-Reply-To: <20150513080342.GE37063@funkthat.com> Date: Wed, 13 May 2015 09:27:05 +0100 Cc: Poul-Henning Kamp , Baptiste Daroussin , current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 08:27:21 -0000 On 13 May 2015, at 09:03, John-Mark Gurney wrote: >=20 > Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 = +0000: >> -------- >> In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney = writes: >>=20 >>> Also, you'd probably see even better performance by increasing the >>> size to 64k, [...] >>=20 >> easy: >> 8K on 32bit >> 64k on 64bit >=20 > Sounds good to me... Just for people who care... I did a quick set of > benchmarks on sha256.. This is using my preliminary patch to use sse4 > optimized sha256... But this should be the same for others... >=20 > The numbers in ministat output are the time in seconds it takes my > 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so lower > numbers are better.. I've processed them into easier to read format: > BUFSIZ: 145MB/sec > 8k: 193MB/sec > 16k: 198MB/sec > 64k: 202MB/sec > 128k: 202MB/sec > -t: 211MB/sec It looks like most of the benefit is gained at 16KB. Did you try = running the benchmark with something else running at the same time to = see if there is any advantage in trashing the caches a bit less (simple = case, what happens if you run two instances of the same benchmark at = once)? I suspect that you=E2=80=99re about right anyway - I recently did some = tests while playing with JavaScript FFI generation with a multithreaded = process JavaScript environment calling out to OpenSSL to do SHA = calculations and having each of 8 threads reading in 128KB chunks gave = the fastest performance (Core i7, 4 cores + hyperthreading), with only a = negligible gain over 64KB. In all cases, the JavaScript implementation = was significantly faster than the openssl tool, which used 8KB buffers. David From owner-freebsd-current@FreeBSD.ORG Wed May 13 08:34:34 2015 Return-Path: Delivered-To: current@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 3521D462; Wed, 13 May 2015 08:34:34 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 E8A2011FC; Wed, 13 May 2015 08:34:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F025F1FE023; Wed, 13 May 2015 10:34:30 +0200 (CEST) Message-ID: <55530CC3.1090204@selasky.org> Date: Wed, 13 May 2015 10:35:15 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Chisnall , John-Mark Gurney CC: Poul-Henning Kamp , Baptiste Daroussin , current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 08:34:34 -0000 On 05/13/15 10:27, David Chisnall wrote: > On 13 May 2015, at 09:03, John-Mark Gurney wrote: >> >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +0000: >>> -------- >>> In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney writes: >>> >>>> Also, you'd probably see even better performance by increasing the >>>> size to 64k, [...] >>> >>> easy: >>> 8K on 32bit >>> 64k on 64bit >> >> Sounds good to me... Just for people who care... I did a quick set of >> benchmarks on sha256.. This is using my preliminary patch to use sse4 >> optimized sha256... But this should be the same for others... >> >> The numbers in ministat output are the time in seconds it takes my >> 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so lower >> numbers are better.. I've processed them into easier to read format: >> BUFSIZ: 145MB/sec >> 8k: 193MB/sec >> 16k: 198MB/sec >> 64k: 202MB/sec >> 128k: 202MB/sec >> -t: 211MB/sec > > It looks like most of the benefit is gained at 16KB. Did you try running the benchmark with something else running at the same time to see if there is any advantage in trashing the caches a bit less (simple case, what happens if you run two instances of the same benchmark at once)? > > I suspect that you’re about right anyway - I recently did some tests while playing with JavaScript FFI generation with a multithreaded process JavaScript environment calling out to OpenSSL to do SHA calculations and having each of 8 threads reading in 128KB chunks gave the fastest performance (Core i7, 4 cores + hyperthreading), with only a negligible gain over 64KB. In all cases, the JavaScript implementation was significantly faster than the openssl tool, which used 8KB buffers. > Hi, You should also try this using an USB disk. The performance numbers heavily depends on the hardware's interrupt moderation values. --HPS From owner-freebsd-current@FreeBSD.ORG Wed May 13 15:21:09 2015 Return-Path: Delivered-To: current@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 549804C3; Wed, 13 May 2015 15:21:09 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE181965; Wed, 13 May 2015 15:21:05 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id E88D21013A0; Wed, 13 May 2015 14:44:20 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org ([TEMPUNAVAIL]. [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Wed, 13 May 2015 14:44:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1431528261139:1580616211 X-MC-Ingress-Time: 1431528261139 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YsXtN-0001gY-QG; Wed, 13 May 2015 14:44:13 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4DEi93P003468; Wed, 13 May 2015 08:44:09 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18zqKsH2h7c9DvCens0acNn Message-ID: <1431528249.1221.15.camel@freebsd.org> Subject: Re: Increase BUFSIZ to 8192 From: Ian Lepore To: Hans Petter Selasky Cc: David Chisnall , John-Mark Gurney , Poul-Henning Kamp , Baptiste Daroussin , current@freebsd.org Date: Wed, 13 May 2015 08:44:09 -0600 In-Reply-To: <55530CC3.1090204@selasky.org> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 X-AuthUser: hippie Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 15:21:09 -0000 On Wed, 2015-05-13 at 10:35 +0200, Hans Petter Selasky wrote: > On 05/13/15 10:27, David Chisnall wrote: > > On 13 May 2015, at 09:03, John-Mark Gurney wrote: > >> > >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 += 0000: > >>> -------- > >>> In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney = writes: > >>> > >>>> Also, you'd probably see even better performance by increasing the > >>>> size to 64k, [...] > >>> > >>> easy: > >>> 8K on 32bit > >>> 64k on 64bit > >> > >> Sounds good to me... Just for people who care... I did a quick set = of > >> benchmarks on sha256.. This is using my preliminary patch to use sse= 4 > >> optimized sha256... But this should be the same for others... > >> > >> The numbers in ministat output are the time in seconds it takes my > >> 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so low= er > >> numbers are better.. I've processed them into easier to read format= : > >> BUFSIZ: 145MB/sec > >> 8k: 193MB/sec > >> 16k: 198MB/sec > >> 64k: 202MB/sec > >> 128k: 202MB/sec > >> -t: 211MB/sec > > > > It looks like most of the benefit is gained at 16KB. Did you try run= ning the benchmark with something else running at the same time to see if= there is any advantage in trashing the caches a bit less (simple case, w= hat happens if you run two instances of the same benchmark at once)? > > > > I suspect that you=A2re about right anyway - I recently did some test= s while playing with JavaScript FFI generation with a multithreaded proce= ss JavaScript environment calling out to OpenSSL to do SHA calculations a= nd having each of 8 threads reading in 128KB chunks gave the fastest perf= ormance (Core i7, 4 cores + hyperthreading), with only a negligible gain = over 64KB. In all cases, the JavaScript implementation was significantly= faster than the openssl tool, which used 8KB buffers. > > >=20 > Hi, >=20 > You should also try this using an USB disk. The performance numbers=20 > heavily depends on the hardware's interrupt moderation values. All this discussion should be happening in phabricator, not the email that announces the review on phab. But, since it's now happening here, I guess I'll transplant my comments from there to here... There are 2125 occurrances of BUFSIZ in the base code (probably 95% of them inappropriately used to size a local temp buffer or string). Do you really want to perturb that much working tested software because it makes md5 faster? How many of those occurrances are stack-allocated variables and is it wise to allocate 8k buffers on the stack for all of them? How about existing programs (not necessarily in base) that open many streams concurrently... what will be the impact of a sudden 8x increase in memory usage for them? It seems to me that if libmd needs bigger buffers to perform well, it should use setvbuf(). -- Ian From owner-freebsd-current@FreeBSD.ORG Wed May 13 15:34:34 2015 Return-Path: Delivered-To: current@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 37440BCE; Wed, 13 May 2015 15:34:34 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1CAE1C03; Wed, 13 May 2015 15:34:33 +0000 (UTC) Received: by igbsb11 with SMTP id sb11so48296844igb.0; Wed, 13 May 2015 08:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6oMSv4gLDw6g7UwtrQBJAvrVnckOye68rLywhgLAX5I=; b=xgsQJtELMAW+ZtYNxgpxMoxBF7/xz7MbL6059sgLlGlK6DEVdi+z77NMaEIoKEicC9 B0VXvGChRn/apM774X5SYQ7yiLl7VyxLsfeMfooudweJDuijYkV83wtFrcf+AcyjFbg9 r//VEWBF0e64ubzbeEsb8OCgQyXb1IZKoKYBsKYk8bpeI0P3fYbq1zVF3/MjUIBRjjwo JFKPy1sRc3td2/pjL45Fw4jLuGhuWu2iEvB9h4WNeR12b1AWH2lVCbfKFbiih9gAdL77 926/V9wDZG3YwosNPnrINIq8BWiZO5aFGlVNFaQZSvLhmJ1+Ib3eZIWScDZwHOrMb9kN zLLw== MIME-Version: 1.0 X-Received: by 10.50.57.51 with SMTP id f19mr28762115igq.6.1431531273214; Wed, 13 May 2015 08:34:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 13 May 2015 08:34:33 -0700 (PDT) In-Reply-To: <1431528249.1221.15.camel@freebsd.org> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> Date: Wed, 13 May 2015 08:34:33 -0700 X-Google-Sender-Auth: yqLUQBnfxmmTv18E6vUkyXqqGy4 Message-ID: Subject: Re: Increase BUFSIZ to 8192 From: Adrian Chadd To: Ian Lepore Cc: Hans Petter Selasky , David Chisnall , John-Mark Gurney , Poul-Henning Kamp , Baptiste Daroussin , "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 15:34:34 -0000 [snip] The reason I ask about "why is it faster?" is because for embedded-y things with low RAM we may not want that to happen due to memory constraints. However, we may actually want to do some form of autotuning on some platforms. So, if it's underlying block size, maybe BUFSIZ isn't the thing to tweak, but based on disk io buffer size. If it's filling L1 or L2 cache with useful work, maybe auto-tune it based on that. If it's hiding interrupt latency over USB, then that should be addressed. etc, etc. Please don't take this as bikeshedding, I'd really like to see some "this is why it's faster" analysis rather than just numbers thrown around. -adrian From owner-freebsd-current@FreeBSD.ORG Wed May 13 16:05:32 2015 Return-Path: Delivered-To: freebsd-current@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 BF313B08 for ; Wed, 13 May 2015 16:05:32 +0000 (UTC) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7123C1155 for ; Wed, 13 May 2015 16:05:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431533125; bh=fT152/dXoxQ8p8FtFCSNCF512BWbCDIA7YWCDH+DXfw=; h=Date:From:To:Subject:From:Subject; b=iUkvZMfyAbTLZ/G0YpOMAWvPTq6AH7fk4D+JBpDEMEXz4YEO2v+Y7+vCOCqidZOmcNe3uMxIzXc8nVszxgERMJuHn1sRAN+Xe4nd8myu8ry2Tw18KLA1CTBogAYwkTYzYfIC3HKB9h9QPHbLsllK5qB/q2HyU9GWRAN1cr7j1Wy/Vcrnlb7ihlBKYXrBHk/jYuAYhQ3S0E+hY/CtkP/ioK4pj9uG4KjpJefzIc/3QMJ3U4yEq9Nt5tXw4t1z9yTnw9v/Pbhuo9+i/PW+1IB+VZKbUKy3PW+/khwqImtOQtKCPqpcjGqx91FXaqbfzUanOd47cKg1kvUkr4/JGQKpQA== Received: from [98.139.170.182] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2015 16:05:25 -0000 Received: from [98.139.211.160] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 13 May 2015 16:05:25 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 13 May 2015 16:05:25 -0000 X-Yahoo-Newman-Id: 509801.18377.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0FdL2WwVM1mH2LGNWX9u6slsseSwnY3CqkTkwSOoq8gsXT3 x5Z3LhLf6YXmQGWymJhj3AykfZuJdTDaCZJM.tIAQ8veym06t66IOk.DEwAl Sf4los.dLuc.0jrphq16lqWGrF1UJ5vLSpo_s0vbG.1JMUZbxR7uZNJS5n9d xuMuxpz8lghPXveTX5rELTk2u7We7qSOARgE8AarAhq._HtkyAOcd9Ap4QN2 TFIoiTdJGXtfpAd0QCsP20vrLBXvUU5TNJODnVa3Tk4LolufSqLKjyQr9TT7 1qRp03ZrUrgKRRowzygbc9zB82CcMFdIu2yrb.KuMoBh8JsbfLYoylaYOQfr _FYnC3m5B2C4fqVwEtSrRpjrT6mrGVyqXpA0mL.S1CiHEVG2SNb.28vVoUp6 p.7DYLgF9dWEqRpxBt54qh66XE.gz9betw.pDfCjKo.Xp2w165NLcqfmIFhj 8Rn_CKTLzspqhhA6FTYySmNjOulgNMxJVUSlUBcFxnxBgu0_wUdolMBudOvi t8VEiCeoJRAEV.wqUfpteb7EU_yhje.co X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <5553764A.9010202@FreeBSD.org> Date: Wed, 13 May 2015 11:05:30 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: FreeBSD Current Subject: CFR: a new __unreachable() builtin Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:05:32 -0000 Hello; I am looking at the cdefs in other BSDs hoping to avoid adopting the same definitions with incompatible names and I noticed NetBSD is using a new __builtin_unreachable (void) function from gcc 4.6: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Apparently it was interesting enough that clang implemented it too so I created a code review differential for it. https://reviews.freebsd.org/D2536 I don't want to add new C definitions unless they are going to be used so feel free to comment on the convenience or not of having it. Pedro. From owner-freebsd-current@FreeBSD.ORG Wed May 13 16:09:45 2015 Return-Path: Delivered-To: freebsd-current@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 C42F0E16; Wed, 13 May 2015 16:09:45 +0000 (UTC) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (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 8A58B11D6; Wed, 13 May 2015 16:09:45 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-153-228.eduroam.wireless.private.cam.ac.uk ([172.17.153.228]:61074) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:dc552) (TLSv1:DHE-RSA-AES256-SHA:256) id 1YsZE7-0005DY-rd (Exim 4.82_3-c0e5623) (return-path ); Wed, 13 May 2015 17:09:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: CFR: a new __unreachable() builtin From: David Chisnall In-Reply-To: <5553764A.9010202@FreeBSD.org> Date: Wed, 13 May 2015 17:09:43 +0100 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <5553764A.9010202@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.2098) Sender: "Dr D. Chisnall" X-Mailman-Approved-At: Wed, 13 May 2015 16:28:54 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:09:45 -0000 On 13 May 2015, at 17:05, Pedro Giffuni wrote: >=20 > Hello; >=20 > I am looking at the cdefs in other BSDs hoping to avoid adopting the > same definitions with incompatible names and I noticed NetBSD is using > a new __builtin_unreachable (void) function from gcc 4.6: >=20 > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html >=20 > Apparently it was interesting enough that clang implemented it too so > I created a code review differential for it. >=20 > https://reviews.freebsd.org/D2536 >=20 > I don't want to add new C definitions unless they are going to be used > so feel free to comment on the convenience or not of having it. LLVM uses this quite heavily, in a macro that expands to something = equivalent to assert(0 && "unreachable reached!=E2=80=9D) in debug mode = and __builtin_unreachable() in release mode. When you=E2=80=99re = debugging, you get errors if you reach unreachable code and in = deployment the compiler gets a useful hint for optimisation. David From owner-freebsd-current@FreeBSD.ORG Wed May 13 18:02:26 2015 Return-Path: Delivered-To: current@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 AE581AE3; Wed, 13 May 2015 18:02:26 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CBF61FF0; Wed, 13 May 2015 18:02:26 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4DI2NiD052864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 11:02:23 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4DI2M5s052863; Wed, 13 May 2015 11:02:22 -0700 (PDT) (envelope-from jmg) Date: Wed, 13 May 2015 11:02:22 -0700 From: John-Mark Gurney To: Hans Petter Selasky Cc: David Chisnall , Poul-Henning Kamp , Baptiste Daroussin , current@FreeBSD.org Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150513180221.GL37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55530CC3.1090204@selasky.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 13 May 2015 11:02:23 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:02:26 -0000 Hans Petter Selasky wrote this message on Wed, May 13, 2015 at 10:35 +0200: > On 05/13/15 10:27, David Chisnall wrote: > > On 13 May 2015, at 09:03, John-Mark Gurney wrote: > >> > >> Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +0000: > >>> -------- > >>> In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney writes: > >>> > >>>> Also, you'd probably see even better performance by increasing the > >>>> size to 64k, [...] > >>> > >>> easy: > >>> 8K on 32bit > >>> 64k on 64bit > >> > >> Sounds good to me... Just for people who care... I did a quick set of > >> benchmarks on sha256.. This is using my preliminary patch to use sse4 > >> optimized sha256... But this should be the same for others... > >> > >> The numbers in ministat output are the time in seconds it takes my > >> 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so lower > >> numbers are better.. I've processed them into easier to read format: > >> BUFSIZ: 145MB/sec > >> 8k: 193MB/sec > >> 16k: 198MB/sec > >> 64k: 202MB/sec > >> 128k: 202MB/sec > >> -t: 211MB/sec > > > > It looks like most of the benefit is gained at 16KB. Did you try running the benchmark with something else running at the same time to see if there is any advantage in trashing the caches a bit less (simple case, what happens if you run two instances of the same benchmark at once)? > > > > I suspect that you???re about right anyway - I recently did some tests while playing with JavaScript FFI generation with a multithreaded process JavaScript environment calling out to OpenSSL to do SHA calculations and having each of 8 threads reading in 128KB chunks gave the fastest performance (Core i7, 4 cores + hyperthreading), with only a negligible gain over 64KB. In all cases, the JavaScript implementation was significantly faster than the openssl tool, which used 8KB buffers. > > You should also try this using an USB disk. The performance numbers > heavily depends on the hardware's interrupt moderation values. This shouldn't matter.. I wasn't flushing the buffer cache between runs, so this was entirely from the buffer cache... This is purely, syscall+copy overhead that is being measured here... No matter what you're source is, NFS, USB disk, you'll always have this overhead... -- 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-current@FreeBSD.ORG Wed May 13 18:13:51 2015 Return-Path: Delivered-To: current@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 80B63E2F; Wed, 13 May 2015 18:13:51 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C8E41181; Wed, 13 May 2015 18:13:50 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4DIDm07052962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 11:13:48 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4DIDl7u052961; Wed, 13 May 2015 11:13:47 -0700 (PDT) (envelope-from jmg) Date: Wed, 13 May 2015 11:13:47 -0700 From: John-Mark Gurney To: Adrian Chadd Cc: Ian Lepore , Hans Petter Selasky , David Chisnall , Poul-Henning Kamp , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150513181347.GM37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Wed, 13 May 2015 11:13:48 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:13:51 -0000 Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700: > The reason I ask about "why is it faster?" is because for embedded-y > things with low RAM we may not want that to happen due to memory > constraints. However, we may actually want to do some form of > autotuning on some platforms. If you're already running a program, the difference between 1k and 8k isn't significant... I'll give you 64k can be significant for embedded-y platforms... But this goes back to the, we need a global knob saying I want low memory usage, and I am willing to pay for it in performance... > So, if it's underlying block size, maybe BUFSIZ isn't the thing to > tweak, but based on disk io buffer size. > If it's filling L1 or L2 cache with useful work, maybe auto-tune it > based on that. I'm pretty sure this is just simply, syscalls+copies are expensive, and larger block sizes reduces the number of calls, going from 1k to 64k means 64 times less syscalls... So, in my benchmark, we went from 148271 syscalls/second to 3228 syscalls/second for 64k block size, and we got a 40% perf increase on top of this... i.e. we spend ~40% of the cpu time to do 145k syscalls instead of doing real work... > Please don't take this as bikeshedding, I'd really like to see some > "this is why it's faster" analysis rather than just numbers thrown > around. I don't really see a need to analyize this any more... We are batching work in a more effecient manner... I could list many other examples of where we do similar optimizations... -- 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-current@FreeBSD.ORG Wed May 13 18:56:19 2015 Return-Path: Delivered-To: current@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 88899B52; Wed, 13 May 2015 18:56:19 +0000 (UTC) Received: from relay.mailchannels.net (aso-006-i431.relay.mailchannels.net [23.91.64.112]) by mx1.freebsd.org (Postfix) with ESMTP id 528A6169F; Wed, 13 May 2015 18:56:17 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id 5B21A60DC4; Wed, 13 May 2015 18:47:18 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (smtp3.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Wed, 13 May 2015 18:47:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1431542838540:3629874207 X-MC-Ingress-Time: 1431542838539 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp3.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Ysbgb-0002PV-NC; Wed, 13 May 2015 18:47:17 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4DIlFcs004018; Wed, 13 May 2015 12:47:15 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+NSwqKEZSXtb8FJeesGARZ Message-ID: <1431542835.1221.30.camel@freebsd.org> Subject: Re: Increase BUFSIZ to 8192 From: Ian Lepore To: John-Mark Gurney Cc: Adrian Chadd , Hans Petter Selasky , David Chisnall , Poul-Henning Kamp , Baptiste Daroussin , "current@freebsd.org" Date: Wed, 13 May 2015 12:47:15 -0600 In-Reply-To: <20150513181347.GM37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:56:19 -0000 On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700: > > The reason I ask about "why is it faster?" is because for embedded-y > > things with low RAM we may not want that to happen due to memory > > constraints. However, we may actually want to do some form of > > autotuning on some platforms. > > If you're already running a program, the difference between 1k and > 8k isn't significant... I'll give you 64k can be significant for > embedded-y platforms... But this goes back to the, we need a global > knob saying I want low memory usage, and I am willing to pay for it > in performance... > It is NOT just a difference of 1K vs 8K. It's that much times however many BUFSIZ-sized things a program has allocated at once. It's where they are allocated. As I've already pointed out, BUFSIZ appears in the base code over 2000 times. Where is the analysis of the impact an 8x change is going to have on all those uses? -- Ian From owner-freebsd-current@FreeBSD.ORG Wed May 13 19:58:57 2015 Return-Path: Delivered-To: freebsd-current@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 76557C4F for ; Wed, 13 May 2015 19:58:57 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5EB61E19 for ; Wed, 13 May 2015 19:58:56 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id t4DJwm5w015312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 13 May 2015 21:58:48 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id t4DJwmVa015309 for ; Wed, 13 May 2015 21:58:48 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 13 May 2015 21:58:48 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: r282420 omits /usr/lib/private/libssh_p.a Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 19:58:57 -0000 make delete-old can't finish off the /usr/lib/private directory due to the presence of libssh_p.a. Manual intervention is required UFN. From owner-freebsd-current@FreeBSD.ORG Thu May 14 00:02:16 2015 Return-Path: Delivered-To: current@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 479F91DD for ; Thu, 14 May 2015 00:02:16 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2A3B1B1C for ; Thu, 14 May 2015 00:02:15 +0000 (UTC) Received: by wgin8 with SMTP id n8so58828286wgi.0 for ; Wed, 13 May 2015 17:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=Qf01k+m/q6DdsBi8JUSBGVjsz+xKSpARlYy9U1tgotI=; b=NXK4ZWroWVwBdbgrZcvnqtco3538jo/v42EjA29X4U/BUxb85OWNaSGU/wSSu2uiD1 cKs38XtfXk+kVlDne1lwgJaNQkBpYTmgIaA8ayfbgNgfyPw9K7L0khE9nzQWtfNq/bFg PvPM9B6RDz0uGvbH85+4dOIa7lOXn8SB89pychtlwAuAkc5GlGpAs1MUc78yMSqwFDu9 fLSRVjim9CmL0X+MD1QgFEtb66Eyhi6gNtYEJ1wCskpSqeJrjl4/USTx5xVqVGcA4zab mopHI5q7RXL71ePzG2/PZ8hHjm6f+dF4LTXYKHVpAJlVcy8NQBGPnX4qd4Hqk6Q6zZck eMpw== X-Received: by 10.180.188.170 with SMTP id gb10mr917734wic.39.1431561734205; Wed, 13 May 2015 17:02:14 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id k9sm10480734wia.6.2015.05.13.17.02.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 17:02:13 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 14 May 2015 02:02:11 +0200 From: Baptiste Daroussin To: current@FreeBSD.org Subject: [RFC] Replace gnu groff in base by heirloom doctools Message-ID: <20150514000211.GA9410@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 00:02:16 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom doctools. This mostly concern documentation in share/docs and the fallback when mando= c(1) is not able to render a manpage. Heirloom doctools has progressed a lot recently and is now able to render correctly all the document we do provide in base, it has active development= and integrate quickly new features. Upstream have been very reactive to bug report I have sent to them and fixed them very quickly. Heirloom has multiple advantages over GNU groff: - it is partially CDDL partially BSD license. - it is mainly written in C (to the exception of a single tool in C++ which= I do not plan to important) - it is derived from the original macros from AT&T (in particular ms(7)) - it is smaller than GNU groff - it has better unicode support than GNU groff - it has better error reporting than GNU groff (which allowed me to fix a c= ouple of the documentation there) - heirloom manpages are mandoc(1) friendly which is not the case for GNU gr= off's one I do only plan to incorporate part of it and keeping our own version of too= ls we already have like: col(1), soelim(1), checknr(1) and vgrind(1). mandoc(1) is still the target for rendering manpages and but I think keepin= g a fully functionnal roff(7) toolchain part of the base system is very good on= a unix. The issue we have with GNU groff is that newer version are in GPLv3 so we cannot upgrade base version to a newer version. Base version of GNU groff i= s a stripped down version of GNU groff so users willing to user some extra functionnality of GNU groff will have to rely on the ports tree. what have already been done: - col(1): updated and fixed base on work with the heirloom doctools and collaboration with OpenBSD folks. While there I have already sandboxed col(1) using capsicum. - checknr(1): now handles more roff(7) commands. - vgrind(11): modernize code base and synchronized some changes from NetBSD I plan to import heirloom doctool later this month. So far the only issue we have is with documents using pic(1) when rendering= in ascii (postscript and pdf rendering are ok) upstream is working on a fix bu= t I do not consider this as a blocker. Allowing to have both gnu groff and heirloom at once switchable via an opti= on will be hard so I plan to make the switch happening at once. =46rom what I could check I cannot find any regression when migrating from = gnu groff to heirloom doctools, if there is a particular area when you think ex= tra care is needed please share it. Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Best regards, Bapt --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVT5gMACgkQ8kTtMUmk6EzsjgCbBOa7l+MqICrMAGWGxyCkaxAI afoAn36vmByJ9NHDKQoAgiicHO1KCJbS =5btX -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 01:18:16 2015 Return-Path: Delivered-To: current@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 97C7BCF for ; Thu, 14 May 2015 01:18:16 +0000 (UTC) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49C5F1284 for ; Thu, 14 May 2015 01:18:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431565928; bh=S8uBM3+Fp30BdsRKJ2kUQ0zaQ97zbLyqVjgX6i2BUxE=; h=From:Subject:Date:Cc:To:From:Subject; b=eIFWYShgOSvcl/Ih3zvrIb2Bn8tIZuN8fwambgIVFhHW53gAVecsetFRVhDrofDfhntTfUcjFUnQXvgkJHCzuNlni6aT0jzrouq9638SSzgNwBmYBSm2JyW9JH9gbeMHMObAsd+1VkBEwP/AF5IRV3cEtVlqmmoKgyVtDa764uMJkcWHvzozXs6LsX7UdHMASLm6DiwHBU5qJHm0ivIEhU2Fbfvm/eTZHVXpzGh3cf1qZWJs3I0/oPEmmuJ0Sdkn+MDNYbR10o5hGgCueUdgIlLdXGvBdze14JJbdbz+uibJuh3IK9e+d42fK8lUz66VLxx4rxtcncT44wkornc7sA== Received: from [98.139.170.181] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2015 01:12:08 -0000 Received: from [98.139.213.8] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 14 May 2015 01:12:08 -0000 Received: from [127.0.0.1] by smtp108.mail.bf1.yahoo.com with NNFMP; 14 May 2015 01:12:08 -0000 X-Yahoo-Newman-Id: 442601.19415.bm@smtp108.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8cDnHd0VM1lWAbdiCakW7hrKEURMS7SJLDqEFbEAJlkjxKu A.VuSWV7uyzZzCwqPMC6SVsAGkRvxEy0u4BAzX0dahENbFLR9eu_.H.42LKw qQziFqrVrXZ694nq4p4grtnzK2T_XYrA.E5ZAAby6gs60raP6SYq5zx.0XiX OSJwOFzYXDhCNX.J2Pe3Hz9zKEE9pMvjuuDkixBDnosaf3DeSY7.Fh5r5RWy JwOqay57Mu8qnDPyavtDpmQJULCLK5kvUnd1mB6_zAOy8P8KsGt2MI6mkLmX Daol4_jr5D8ee07Eo8i9V9Hq6FvU3Tf.w8mpychXzn__fx3n2nWO8pxizYjI PxDPhQAy2s.eNGaD1E8VaacxUJoMTcB6Hyn_PxglvUCJXt2zGaDETKScT5wa yv1aVvaVvh_stJcz1nh3N7BGEUjUuyDTFe52b7nW3WO8TUEiB1OCHuK4EVgr GHNIxLJ1jnpMhBqXzs93GnhlKoluGy2NOZ0vku4d_zpXPAS_APiElqpUeR2y bjAI_d58sy7Zen5K3ruL0TGk84WsnsucAQ1aX X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf From: Pedro Giffuni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Date: Wed, 13 May 2015 20:12:05 -0500 Message-Id: Cc: current@FreeBSD.org To: Baptiste Daroussin Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 01:18:16 -0000 +1 Great idea. Pedro. From owner-freebsd-current@FreeBSD.ORG Thu May 14 03:17:44 2015 Return-Path: Delivered-To: freebsd-current@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 AAA005FA for ; Thu, 14 May 2015 03:17:44 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 574461FFD for ; Thu, 14 May 2015 03:17:44 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t4E3IAwE058566 for ; Wed, 13 May 2015 20:18:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: <20150514000211.GA9410@ivaldir.etoilebsd.net> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Date: Wed, 13 May 2015 20:18:16 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 03:17:44 -0000 On Thu, 14 May 2015 02:02:11 +0200 Baptiste Daroussin wrote > Hi, > > I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirloom > doctools. > > This mostly concern documentation in share/docs and the fallback when > mandoc(1) is not able to render a manpage. > > Heirloom doctools has progressed a lot recently and is now able to render > correctly all the document we do provide in base, it has active development > and integrate quickly new features. > > Upstream have been very reactive to bug report I have sent to them and fixed > them very quickly. > > Heirloom has multiple advantages over GNU groff: > - it is partially CDDL partially BSD license. > - it is mainly written in C (to the exception of a single tool in C++ which I > do not plan to important) > - it is derived from the original macros from AT&T (in particular ms(7)) > - it is smaller than GNU groff > - it has better unicode support than GNU groff > - it has better error reporting than GNU groff (which allowed me to fix a > couple of the documentation there) > - heirloom manpages are mandoc(1) friendly which is not the case for GNU > groff's one > > I do only plan to incorporate part of it and keeping our own version of tools > we already have like: col(1), soelim(1), checknr(1) and vgrind(1). > > mandoc(1) is still the target for rendering manpages and but I think keeping > a fully functionnal roff(7) toolchain part of the base system is very good on > a unix. > > The issue we have with GNU groff is that newer version are in GPLv3 so we > cannot upgrade base version to a newer version. Base version of GNU groff is > a stripped down version of GNU groff so users willing to user some extra > functionnality of GNU groff will have to rely on the ports tree. > > what have already been done: > - col(1): updated and fixed base on work with the heirloom doctools and > collaboration with OpenBSD folks. While there I have already sandboxed > col(1) using capsicum. > - checknr(1): now handles more roff(7) commands. > - vgrind(11): modernize code base and synchronized some changes from NetBSD > > I plan to import heirloom doctool later this month. > > So far the only issue we have is with documents using pic(1) when rendering > in ascii (postscript and pdf rendering are ok) upstream is working on a fix > but I do not consider this as a blocker. > > Allowing to have both gnu groff and heirloom at once switchable via an option > will be hard so I plan to make the switch happening at once. > > From what I could check I cannot find any regression when migrating from gnu > groff to heirloom doctools, if there is a particular area when you think > extra care is needed please share it. > > Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools > > Best regards, > Bapt +1 Please do, and *thank you* for all the work you put into this! --Chris From owner-freebsd-current@FreeBSD.ORG Thu May 14 07:22:00 2015 Return-Path: Delivered-To: current@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 0B0ADAF3; Thu, 14 May 2015 07:22:00 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B3E40182E; Thu, 14 May 2015 07:21:59 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4E7LvMx061941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 00:21:57 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4E7Lu1K061940; Thu, 14 May 2015 00:21:56 -0700 (PDT) (envelope-from jmg) Date: Thu, 14 May 2015 00:21:56 -0700 From: John-Mark Gurney To: Ian Lepore Cc: Adrian Chadd , Hans Petter Selasky , David Chisnall , Poul-Henning Kamp , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150514072155.GT37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1431542835.1221.30.camel@freebsd.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 14 May 2015 00:21:57 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:22:00 -0000 Ian Lepore wrote this message on Wed, May 13, 2015 at 12:47 -0600: > On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote: > > Adrian Chadd wrote this message on Wed, May 13, 2015 at 08:34 -0700: > > > The reason I ask about "why is it faster?" is because for embedded-y > > > things with low RAM we may not want that to happen due to memory > > > constraints. However, we may actually want to do some form of > > > autotuning on some platforms. > > > > If you're already running a program, the difference between 1k and > > 8k isn't significant... I'll give you 64k can be significant for > > embedded-y platforms... But this goes back to the, we need a global > > knob saying I want low memory usage, and I am willing to pay for it > > in performance... > > It is NOT just a difference of 1K vs 8K. It's that much times however > many BUFSIZ-sized things a program has allocated at once. It's where > they are allocated. As I've already pointed out, BUFSIZ appears in the > base code over 2000 times. Where is the analysis of the impact an 8x > change is going to have on all those uses? Since you apprently missed my original reply, I said that we shouldn't abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... I agree that changing this size to effect all the other files is ill advised and should not be done... -- 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-current@FreeBSD.ORG Thu May 14 07:30:25 2015 Return-Path: Delivered-To: current@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 54504C60; Thu, 14 May 2015 07:30:25 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D30C1880; Thu, 14 May 2015 07:30:24 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4E7UOtG062071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 00:30:24 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4E7UO79062070; Thu, 14 May 2015 00:30:24 -0700 (PDT) (envelope-from jmg) Date: Thu, 14 May 2015 00:30:24 -0700 From: John-Mark Gurney To: David Chisnall Cc: Poul-Henning Kamp , Baptiste Daroussin , current@FreeBSD.org Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150514073024.GW37063@funkthat.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 14 May 2015 00:30:24 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:30:25 -0000 David Chisnall wrote this message on Wed, May 13, 2015 at 09:27 +0100: > On 13 May 2015, at 09:03, John-Mark Gurney wrote: > > > > Poul-Henning Kamp wrote this message on Tue, May 12, 2015 at 06:31 +0000: > >> -------- > >> In message <20150512032307.GP37063@funkthat.com>, John-Mark Gurney writes: > >> > >>> Also, you'd probably see even better performance by increasing the > >>> size to 64k, [...] > >> > >> easy: > >> 8K on 32bit > >> 64k on 64bit > > > > Sounds good to me... Just for people who care... I did a quick set of > > benchmarks on sha256.. This is using my preliminary patch to use sse4 > > optimized sha256... But this should be the same for others... > > > > The numbers in ministat output are the time in seconds it takes my > > 3.4GHz AMD A10-5700 APU running HEAD to process a 512MB file, so lower > > numbers are better.. I've processed them into easier to read format: > > BUFSIZ: 145MB/sec > > 8k: 193MB/sec > > 16k: 198MB/sec > > 64k: 202MB/sec > > 128k: 202MB/sec > > -t: 211MB/sec > > It looks like most of the benefit is gained at 16KB. Did you try running the benchmark with something else running at the same time to see if there is any advantage in trashing the caches a bit less (simple case, what happens if you run two instances of the same benchmark at once)? > > I suspect that you???re about right anyway - I recently did some tests while playing with JavaScript FFI generation with a multithreaded process JavaScript environment calling out to OpenSSL to do SHA calculations and having each of 8 threads reading in 128KB chunks gave the fastest performance (Core i7, 4 cores + hyperthreading), with only a negligible gain over 64KB. In all cases, the JavaScript implementation was significantly faster than the openssl tool, which used 8KB buffers. Just in case anyone else wants to know how to run benchmarks themselves.. Go into /usr/src/lib/libmd, edit mdXhl.c, and change the occurence of BUFSIZ to what you want to test, say 64*1024, run: make all && make install and then you can run programs like sha256 -t, or: for i in `jot 5 1`; do /usr/bin/time sha256 test.file ; done 2> XXX.times Where test.file is populated maybe like: dd if=/dev/urandom of=test.file bs=1m count=512 Then run: ministat XXX.times YYY.times to compare multiple results... Happy benchmarking! -- 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-current@FreeBSD.ORG Thu May 14 07:34:49 2015 Return-Path: Delivered-To: freebsd-current@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 8370FDCE for ; Thu, 14 May 2015 07:34:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9ED1954 for ; Thu, 14 May 2015 07:34:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 57AA7E41 for ; Thu, 14 May 2015 07:34:47 +0000 (UTC) Date: Thu, 14 May 2015 07:34:44 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <2081898632.5.1431588884601.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #1032 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:34:49 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu May 14 07:42:25 2015 Return-Path: Delivered-To: current@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 3B30EDB; Thu, 14 May 2015 07:42:25 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id EE95B1A8B; Thu, 14 May 2015 07:42:24 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C93833BD35; Thu, 14 May 2015 07:42:17 +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 t4E7gFlm062512; Thu, 14 May 2015 07:42:16 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney cc: Ian Lepore , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <20150514072155.GT37063@funkthat.com> From: "Poul-Henning Kamp" References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62510.1431589335.1@critter.freebsd.dk> Date: Thu, 14 May 2015 07:42:15 +0000 Message-ID: <62511.1431589335@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:42:25 -0000 -------- In message <20150514072155.GT37063@funkthat.com>, John-Mark Gurney writes: >Since you apprently missed my original reply, I said that we shouldn't >abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... Say what ? BUFSIZ is used entirely appropriately in MDXFileChunk(): For reading a file into an algorithm. If in stead of open(2), fopen(3) had been used, the exact same thing would happen, but using malloc space rather than stack space. -- 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-current@FreeBSD.ORG Thu May 14 07:53:18 2015 Return-Path: Delivered-To: current@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 A8D4955F; Thu, 14 May 2015 07:53:18 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 679981BC5; Thu, 14 May 2015 07:53:17 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t4E7rGAc062344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 00:53:16 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t4E7rGEA062343; Thu, 14 May 2015 00:53:16 -0700 (PDT) (envelope-from jmg) Date: Thu, 14 May 2015 00:53:16 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Cc: Ian Lepore , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150514075316.GY37063@funkthat.com> References: <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62511.1431589335@critter.freebsd.dk> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 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? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 14 May 2015 00:53:17 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:53:18 -0000 Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +0000: > -------- > In message <20150514072155.GT37063@funkthat.com>, John-Mark Gurney writes: > > >Since you apprently missed my original reply, I said that we shouldn't > >abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... > > Say what ? > > BUFSIZ is used entirely appropriately in MDXFileChunk(): For reading > a file into an algorithm. Posix-2008: BUFSIZ: Size of buffers. This shall expand to a positive value. C99: BUFSIZ which expands to an integer constant expression that is the size of the buffer used by the setbuf function; In fact, posix-2008 references LINE_MAX because: Frequently, utility writers selected the UNIX system constant BUFSIZ to allocate these buffers; therefore, some utilities were limited to 512 bytes for I/O lines, while others achieved 4 096 bytes or greater. BUFSIZ was already recognized as to small to hold a single line, yet you're saying it's perfectly fine to use as a buffer for binary data? > If in stead of open(2), fopen(3) had been used, the exact same thing > would happen, but using malloc space rather than stack space. Plus extra overhead.. :) -- 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-current@FreeBSD.ORG Thu May 14 08:01:43 2015 Return-Path: Delivered-To: current@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 BC6066E7; Thu, 14 May 2015 08:01:43 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE151CB7; Thu, 14 May 2015 08:01:43 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 577B43BB88; Thu, 14 May 2015 08:01:42 +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 t4E81eQN077804; Thu, 14 May 2015 08:01:41 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore cc: John-Mark Gurney , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <1431542835.1221.30.camel@freebsd.org> From: "Poul-Henning Kamp" References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77802.1431590500.1@critter.freebsd.dk> Date: Thu, 14 May 2015 08:01:40 +0000 Message-ID: <77803.1431590500@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:01:43 -0000 -------- In message <1431542835.1221.30.camel@freebsd.org>, Ian Lepore writes: >On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote: >As I've already pointed out, BUFSIZ appears in the >base code over 2000 times. Where is the analysis of the impact an 8x >change is going to have on all those uses? Not to pick on Ian in particular, but I'm going to call bike-shed on this discussion now. Please just make it 4K on 32bit archs and 16K on 64 bit archs, and get on with your lives. If experience in -current (that's why developers run current, right ?!) documents that this was the wrong decision, we can revisit it. Until then: Shut up and code. -- 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-current@FreeBSD.ORG Thu May 14 08:06:32 2015 Return-Path: Delivered-To: current@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 63F7E863; Thu, 14 May 2015 08:06:32 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2663F1CFC; Thu, 14 May 2015 08:06:31 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 3CF0B3BB88; Thu, 14 May 2015 08:06:30 +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 t4E86TBl077888; Thu, 14 May 2015 08:06:29 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney cc: Ian Lepore , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <20150514075316.GY37063@funkthat.com> From: "Poul-Henning Kamp" References: <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> <20150514075316.GY37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77886.1431590789.1@critter.freebsd.dk> Date: Thu, 14 May 2015 08:06:29 +0000 Message-ID: <77887.1431590789@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:06:32 -0000 -------- In message <20150514075316.GY37063@funkthat.com>, John-Mark Gurney writes: >Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +0000: >> -------- >> In message <20150514072155.GT37063@funkthat.com>, John-Mark Gurney writes: >> >> >Since you apprently missed my original reply, I said that we shouldn't >> >abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... >> >> Say what ? >> >> BUFSIZ is used entirely appropriately in MDXFileChunk(): For reading >> a file into an algorithm. >In fact, posix-2008 references LINE_MAX because: MDXFileChunk() does not read lines, it reads an entire file. -- 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-current@FreeBSD.ORG Thu May 14 08:55:36 2015 Return-Path: Delivered-To: current@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 E0DE6491; Thu, 14 May 2015 08:55:36 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 94B5C128F; Thu, 14 May 2015 08:55:36 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t4E8tORX039170 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 08:55:28 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools From: David Chisnall In-Reply-To: <20150514000211.GA9410@ivaldir.etoilebsd.net> Date: Thu, 14 May 2015 09:55:19 +0100 Cc: current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <2915B2EB-DE58-451B-801B-92EB7CBCAA43@FreeBSD.org> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:55:37 -0000 On 14 May 2015, at 01:02, Baptiste Daroussin wrote: >=20 > - it is partially CDDL partially BSD license. We currently have a WITHOUT_CDDL knob that some people use. If we = don=E2=80=99t build the CDDL parts, what will break? David From owner-freebsd-current@FreeBSD.ORG Thu May 14 08:59:53 2015 Return-Path: Delivered-To: current@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 B280C5D2; Thu, 14 May 2015 08:59:53 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 475C512C0; Thu, 14 May 2015 08:59:53 +0000 (UTC) Received: by wibt6 with SMTP id t6so7119445wib.0; Thu, 14 May 2015 01:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=U8TM2FwmuBwtZl0etFxT0x43UlIU4u5lyBGggbVXAg8=; b=E/H2s+0uKzFXq7qQBaYQ9K16N4/4yaEfh5UjK7yROTgi/36afLS0QV/aKFs/RN09RN F4v/dZ2OyV8nQN9kls1QptU+usBQE+lafabNQ+lPVu7mskv+TkkKzW4Smr3AMqIXJUXT GeExO+mcN4p4qRzs7+bORLmiaWtX1JQzQykaQibcTjpci065fkb4xFctp+KiDhGt1Skl Usjmv/lVW4wF/vDgL2grbiiRtB4ZGh99ZtURz2XN9wNZHOsIPzpXI6sfSr5jluWxR9IO yLt4MJmvIuBKL3G4A7CfkIMad8JSdiG0w7b8CZQY7aRuikci5WOoh8a+Ao5ViNNhnDyo ojbA== X-Received: by 10.194.185.238 with SMTP id ff14mr6022073wjc.150.1431593990959; Thu, 14 May 2015 01:59:50 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id df1sm12199465wib.12.2015.05.14.01.59.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 01:59:50 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 14 May 2015 10:59:48 +0200 From: Baptiste Daroussin To: David Chisnall Cc: current@FreeBSD.org Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Message-ID: <20150514085948.GC11201@ivaldir.etoilebsd.net> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> <2915B2EB-DE58-451B-801B-92EB7CBCAA43@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <2915B2EB-DE58-451B-801B-92EB7CBCAA43@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:59:53 -0000 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: > On 14 May 2015, at 01:02, Baptiste Daroussin wrote: > >=20 > > - it is partially CDDL partially BSD license. >=20 > We currently have a WITHOUT_CDDL knob that some people use. If we don=E2= =80=99t build the CDDL parts, what will break? >=20 Exactly the same thing that breaks right now WITHOUT_GNU and/or WITHOUT_CXX= aka you won't have the main part of the toolchain (aka troff/nroff) Best regards, Bapt --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVUZAQACgkQ8kTtMUmk6EzdQgCfQC3Ei2yCL6g3Gk7suMazpB2P IicAoKCNiWWzHZpWLlfaeqMC0sEljtga =dKNS -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:13:27 2015 Return-Path: Delivered-To: current@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 2E943B44; Thu, 14 May 2015 09:13:27 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EF80714FF; Thu, 14 May 2015 09:13:26 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t4E9DNB8039269 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 09:13:25 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools From: David Chisnall In-Reply-To: <20150514085948.GC11201@ivaldir.etoilebsd.net> Date: Thu, 14 May 2015 10:13:18 +0100 Cc: current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <20A766BD-1AE4-44B2-B508-CD2E96B5DD65@FreeBSD.org> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> <2915B2EB-DE58-451B-801B-92EB7CBCAA43@FreeBSD.org> <20150514085948.GC11201@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:13:27 -0000 On 14 May 2015, at 09:59, Baptiste Daroussin wrote: >=20 > On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: >> On 14 May 2015, at 01:02, Baptiste Daroussin = wrote: >>>=20 >>> - it is partially CDDL partially BSD license. >>=20 >> We currently have a WITHOUT_CDDL knob that some people use. If we = don=E2=80=99t build the CDDL parts, what will break? >>=20 > Exactly the same thing that breaks right now WITHOUT_GNU and/or = WITHOUT_CXX aka > you won't have the main part of the toolchain (aka troff/nroff) But man pages will still work via mandoc? WITHOUT_GNU is known not to = work (though we=E2=80=99re trying to address that with 11). = WITHOUT_CDDL is generally expected to give a working system currently. David From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:23:38 2015 Return-Path: Delivered-To: current@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 44D569B; Thu, 14 May 2015 09:23:38 +0000 (UTC) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F338E1673; Thu, 14 May 2015 09:23:37 +0000 (UTC) Received: by oiko83 with SMTP id o83so51242929oik.1; Thu, 14 May 2015 02:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=/c1IQskXBtfQtVQjGq1IOXOVISkLs176CLKilx0+KD8=; b=Q3rPE5QDTidXaLNL567U9t2D2azF2xbKmabKCTtegH548KwvQyNFnNSiZPRDDYJIRV 2jGh/D1qlSRP534JqXhidcjkdfnRqcfyTlw3tydlumqevPdC5dT0qqWyV2eprZuENvjI oFntJjqSU9Lc1Oikry0fs7Gsr2sJD+M3QZNPPGPsJyUkvrC2gzNLqm78C77Q4pIvPIXa qQBCgZef0y0QT6Irbj0jv+OclHENhOEE96HM6XeYkxsNtwzt/fvZmJCypyTYZRBCWjuj XXhyAFlqB9hRuDqg/BmC+KJV6B/quJBqmtbE6YpvtCqS+laxbbM39NRpTrtGTwa70wAZ Rg7g== X-Received: by 10.60.132.208 with SMTP id ow16mr2708830oeb.66.1431595417052; Thu, 14 May 2015 02:23:37 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:c178:acbe:4cc0:2fd4? ([2601:8:ab80:7d6:c178:acbe:4cc0:2fd4]) by mx.google.com with ESMTPSA id x17sm14526064oif.1.2015.05.14.02.23.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 02:23:36 -0700 (PDT) Subject: Re: Increase BUFSIZ to 8192 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E07D28FA-D10A-42CF-8781-790246C2B15C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: <77887.1431590789@critter.freebsd.dk> Date: Thu, 14 May 2015 02:23:30 -0700 Cc: John-Mark Gurney , Ian Lepore , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Message-Id: <6AE8973B-3C03-497F-85A9-96C4D464B4BD@gmail.com> References: <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> <20150514075316.GY37063@funkthat.com> <77887.1431590789@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:23:38 -0000 --Apple-Mail=_E07D28FA-D10A-42CF-8781-790246C2B15C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 14, 2015, at 1:06, Poul-Henning Kamp wrote: > -------- > In message <20150514075316.GY37063@funkthat.com>, John-Mark Gurney = writes: >> Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 = +0000: >>> -------- >>> In message <20150514072155.GT37063@funkthat.com>, John-Mark Gurney = writes: >>>=20 >>>> Since you apprently missed my original reply, I said that we = shouldn't >>>> abuse BUFSIZ for this work, and that it should be changed in = mdXhl.c... >>>=20 >>> Say what ? >>>=20 >>> BUFSIZ is used entirely appropriately in MDXFileChunk(): For = reading >>> a file into an algorithm. >=20 >> In fact, posix-2008 references LINE_MAX because: >=20 > MDXFileChunk() does not read lines, it reads an entire file. Being pedantic, technically it=92s a portion of a file, which can be the = whole thing, and it reads it in =93sizeof(buffer)=94 chunks (of which = buffer is =93hardcoded" to BUFSIZ right now). Cheers! --Apple-Mail=_E07D28FA-D10A-42CF-8781-790246C2B15C 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 iQEcBAEBCgAGBQJVVGmSAAoJEMZr5QU6S73eVIYIALM8mAuABG5q2xHdTaR5TqaR YbazmhKDn4ZUke+pd7BcyNstQKD4hNMkU+ZIZsvevH+0PINAmUrLRfu++lYFhSM7 239VCHwqGlJLOAuE+HyfcM1fURo85hYRkIgbPNRw0iwJ6HEvIudyR5KYW0nsHceO Gw3EX7ZHxDdeupZ/dkG4oiJIhAUc6HgPFcHvsy/kBRwrH6zrjSGldmqoQaotYQLR muQwGCFq/cq++4bu5Nr4S90UKNeRluRSXbAAd8QaSTPvgAK3R99l4uv0saIzyeO8 JHj+j8r7O5R3Hfa4035Y6V+5kWv8Ha8odykFo3+YsN2WPR62cK6IWZmDPtKFTpo= =MLZT -----END PGP SIGNATURE----- --Apple-Mail=_E07D28FA-D10A-42CF-8781-790246C2B15C-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:24:12 2015 Return-Path: Delivered-To: current@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 419091A4; Thu, 14 May 2015 09:24:12 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9F7F1684; Thu, 14 May 2015 09:24:11 +0000 (UTC) Received: by wibt6 with SMTP id t6so7856734wib.0; Thu, 14 May 2015 02:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ODIL/j33jUxw9RcxWF7ZP1AN+fYJE0N7m1Vr75xRpak=; b=lkRIl3DPCBpKovNVDNmfVb24808rQw7rhJav79QjcloVL+Z5wj3DOqCL2l1VUwEUzI hoUGkXfWMNnX/27P4oJu5iwhr+pZ2VGgaZoppQ43aqk5jPpoBR1OZK1yPUVO0dUB7og1 yR7vlhiX8JOnOJxzAeqqdESahin+2PpBGRJFFg8LoQd+rQO3VObQ4Sv36nSxwOAINE/u qQOscxge26l/zX1SkE4Wf6+x9AeqHJN38I5u54tup4oI/6npeocAsR3lq7MRrNme5fK4 kAP7laXCBALBTDBFgJ7PWy+5wGT+Cnyz75ZBFPEGU2njeXQxrgkQXNXi5ApzbF/AhE0y 6BlQ== X-Received: by 10.180.188.35 with SMTP id fx3mr47083695wic.43.1431595450241; Thu, 14 May 2015 02:24:10 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id xy5sm37181373wjc.35.2015.05.14.02.24.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 02:24:09 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 14 May 2015 11:24:07 +0200 From: Baptiste Daroussin To: David Chisnall Cc: current@FreeBSD.org Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Message-ID: <20150514092407.GD11201@ivaldir.etoilebsd.net> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> <2915B2EB-DE58-451B-801B-92EB7CBCAA43@FreeBSD.org> <20150514085948.GC11201@ivaldir.etoilebsd.net> <20A766BD-1AE4-44B2-B508-CD2E96B5DD65@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline In-Reply-To: <20A766BD-1AE4-44B2-B508-CD2E96B5DD65@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:24:12 -0000 --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2015 at 10:13:18AM +0100, David Chisnall wrote: > On 14 May 2015, at 09:59, Baptiste Daroussin wrote: > >=20 > > On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: > >> On 14 May 2015, at 01:02, Baptiste Daroussin wrote: > >>>=20 > >>> - it is partially CDDL partially BSD license. > >>=20 > >> We currently have a WITHOUT_CDDL knob that some people use. If we don= =E2=80=99t build the CDDL parts, what will break? > >>=20 > > Exactly the same thing that breaks right now WITHOUT_GNU and/or WITHOUT= _CXX aka > > you won't have the main part of the toolchain (aka troff/nroff) >=20 > But man pages will still work via mandoc? WITHOUT_GNU is known not to wo= rk (though we=E2=80=99re trying to address that with 11). WITHOUT_CDDL is = generally expected to give a working system currently. Yes since I switched the default manpage renderer to mandoc(1) :) (meaning = that WITHOUT_GNU is also not blocking manpage rendering) Best regards, Bapt --UfEAyuTBtIjiZzX6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVUabcACgkQ8kTtMUmk6EwuxQCfcJqI3vrZ8Unynfk1s0zSe9ZI WLsAn1V0QB+oCpRBGkqjqy78V9tY9B9U =GopL -----END PGP SIGNATURE----- --UfEAyuTBtIjiZzX6-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:25:55 2015 Return-Path: Delivered-To: current@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 DCBD72CD; Thu, 14 May 2015 09:25:55 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A895716A4; Thu, 14 May 2015 09:25:55 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t4E9PpYk039348 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 09:25:53 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools From: David Chisnall In-Reply-To: <20150514092407.GD11201@ivaldir.etoilebsd.net> Date: Thu, 14 May 2015 10:25:32 +0100 Cc: current@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150514000211.GA9410@ivaldir.etoilebsd.net> <2915B2EB-DE58-451B-801B-92EB7CBCAA43@FreeBSD.org> <20150514085948.GC11201@ivaldir.etoilebsd.net> <20A766BD-1AE4-44B2-B508-CD2E96B5DD65@FreeBSD.org> <20150514092407.GD11201@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:25:56 -0000 On 14 May 2015, at 10:24, Baptiste Daroussin wrote: >=20 > On Thu, May 14, 2015 at 10:13:18AM +0100, David Chisnall wrote: >> On 14 May 2015, at 09:59, Baptiste Daroussin = wrote: >>>=20 >>> On Thu, May 14, 2015 at 09:55:19AM +0100, David Chisnall wrote: >>>> On 14 May 2015, at 01:02, Baptiste Daroussin = wrote: >>>>>=20 >>>>> - it is partially CDDL partially BSD license. >>>>=20 >>>> We currently have a WITHOUT_CDDL knob that some people use. If we = don=E2=80=99t build the CDDL parts, what will break? >>>>=20 >>> Exactly the same thing that breaks right now WITHOUT_GNU and/or = WITHOUT_CXX aka >>> you won't have the main part of the toolchain (aka troff/nroff) >>=20 >> But man pages will still work via mandoc? WITHOUT_GNU is known not = to work (though we=E2=80=99re trying to address that with 11). = WITHOUT_CDDL is generally expected to give a working system currently. >=20 > Yes since I switched the default manpage renderer to mandoc(1) :) = (meaning that > WITHOUT_GNU is also not blocking manpage rendering) Sounds good to me. Probably warrants a release notes entry specifically = documenting that change, but otherwise sounds like a big improvement! David From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:30:10 2015 Return-Path: Delivered-To: current@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 F0AB0562; Thu, 14 May 2015 09:30:09 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB3B516F7; Thu, 14 May 2015 09:30:09 +0000 (UTC) Received: by obblk2 with SMTP id lk2so49030307obb.0; Thu, 14 May 2015 02:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=WKLn7J5YiJBL3US6NM4JZAcA3kdhlQaPRuXvkeofnoc=; b=RUVnciGERLeSyEt/251u4svQNMWWMVmKpjhF42i92oycFUX5IM+09WJQytCx0Lmt98 E/ljiKqCuWk5RMMmcQIa+7hvqYCVL8FjvLj0h+yS5Gvgj37S0r8GQoCo6PKleFfeRFGM QPVQHDmBI/LVtvZCIvrXa/AZhC9xjkuSOsN8YrQAbgmw7XC/s32dIVu6hc9J9IjHGvbh ntgQNjsblV4IdNxalUMrmwJO6K8QtilOmzfa+ULSyyPq4iFib2KzE+33V7GwEKsOhBXS KyP3HmWTg3GkrhQyb4s/lTfKs72OnrWDIXzfQHc4mAzl7zm+TG6W3PPuPQhRJraRw2Xq H8Gw== X-Received: by 10.60.101.195 with SMTP id fi3mr2721750oeb.65.1431595808888; Thu, 14 May 2015 02:30:08 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:c178:acbe:4cc0:2fd4? ([2601:8:ab80:7d6:c178:acbe:4cc0:2fd4]) by mx.google.com with ESMTPSA id bt6sm14462973obd.0.2015.05.14.02.30.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 02:30:08 -0700 (PDT) Subject: Re: Increase BUFSIZ to 8192 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3D45A5D2-5BC5-4B7D-BFCE-0D489B5A074E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: <77803.1431590500@critter.freebsd.dk> Date: Thu, 14 May 2015 02:30:06 -0700 Cc: Ian Lepore , John-Mark Gurney , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Message-Id: <72720EA2-C251-40B9-9EC0-702C07D5EDF9@gmail.com> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <77803.1431590500@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:30:10 -0000 --Apple-Mail=_3D45A5D2-5BC5-4B7D-BFCE-0D489B5A074E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 14, 2015, at 1:01, Poul-Henning Kamp wrote: > -------- > In message <1431542835.1221.30.camel@freebsd.org>, Ian Lepore writes: >> On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote: >=20 >> As I've already pointed out, BUFSIZ appears in the >> base code over 2000 times. Where is the analysis of the impact an 8x >> change is going to have on all those uses? >=20 > Not to pick on Ian in particular, but I'm going to call bike-shed > on this discussion now. >=20 > Please just make it 4K on 32bit archs and 16K on 64 bit archs, and > get on with your lives. >=20 > If experience in -current (that's why developers run current, right = ?!) > documents that this was the wrong decision, we can revisit it. >=20 > Until then: Shut up and code. Baptiste=92s recommendation was related to md5 performance, so it might = be that (as you pointed out with MDXFileChunk), things might be less = performant in the application than they could be =97 but that=92s an = application bug (only helped by scaling issues with FreeBSD, = potentially). Until performance has been characterized on 32-bit vs = 64-bit architectures, blanket changing a value doesn=92t make sense. I think that changing buffers sized at BUFSIZ for md5/libmd5 probably = makes a lot more sense as that change is isolated and the end result = could be easily micro benchmarked. If/when we have an overall = characterization we can look at increasing the value across the board. Thanks! -NGie --Apple-Mail=_3D45A5D2-5BC5-4B7D-BFCE-0D489B5A074E 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 iQEcBAEBCgAGBQJVVGseAAoJEMZr5QU6S73eXywIALZHKkiI/SycxRvlLjfEuU49 XvHLyOr5fOMGoQoCo/93XeEBtltV4KruFLPkcxg/UP21jL7ZP3kFeQK61l14erte V6ygAXDTtzbG3mAfNDhGWKoACggwXXdXnyEgczbje707wSo8IFpwt/lefKF/nJ+Y TRUKNsBMb7QK2/M8nCnuHRTBRelk0Y9g5QXcBztsPoKaRBTYtYo+BvV6p4+LUzFO TqhoHmXp/P5P2a6ryW9O0ESVWaukSZUsMpSejaiZxYo7KJQZyiXrJ9tvd2UCntCh ABnahnu1KmWwRRDIk9CC23zIM8FRMZGpnKNtEs8XwzV6OJtbewZ/qK0vojqe/mQ= =a30F -----END PGP SIGNATURE----- --Apple-Mail=_3D45A5D2-5BC5-4B7D-BFCE-0D489B5A074E-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:31:58 2015 Return-Path: Delivered-To: current@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 709F06CA; Thu, 14 May 2015 09:31:58 +0000 (UTC) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31E1717CB; Thu, 14 May 2015 09:31:58 +0000 (UTC) Received: by oica37 with SMTP id a37so51367458oic.0; Thu, 14 May 2015 02:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=wy4iKGIAdKtNnnOykpXqXSKViKioZRCy1MLITMBtdFo=; b=aKeWFi/Y2dx8254ObRSUPbRmueoa0PPORp2vioHJ35EzfSL35O2V91iZCkOET0RyB8 Z2IVVL2RgZOcpsdYRuKDxAeIfdouNoOWt13CfYRHSynhwctGfy3AUXo2bKsNWF4Rh82k RFHLuEuALH1F/Ot/GzJ6Rp0ACZSjsno0LOt2Z5hk9OaQW/ZBrvmglDenn/5PTWuy4Njl 1522MJRbhqU1NRBb9h6L1HG6blCBBas1Zx99rlvU3zBQ7N9W9JN37Mj2NgXGPg4IVRe+ o3Il0bHWWOHL8VOvrvq2m3vTL6iew7I2aLGQ5wSJb5CPmMsiEJJKTwcTVZDs0lxKHdF2 neSw== X-Received: by 10.202.92.9 with SMTP id q9mr1959255oib.8.1431595917302; Thu, 14 May 2015 02:31:57 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:c178:acbe:4cc0:2fd4? ([2601:8:ab80:7d6:c178:acbe:4cc0:2fd4]) by mx.google.com with ESMTPSA id pn16sm14305576oeb.16.2015.05.14.02.31.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 02:31:56 -0700 (PDT) Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5798B909-BF32-4AF5-9900-77D055A152E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: <20150514000211.GA9410@ivaldir.etoilebsd.net> Date: Thu, 14 May 2015 02:31:55 -0700 Cc: current@FreeBSD.org Message-Id: <66E508AC-1329-4E73-804B-E15BD7042FAD@gmail.com> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:31:58 -0000 --Apple-Mail=_5798B909-BF32-4AF5-9900-77D055A152E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 13, 2015, at 17:02, Baptiste Daroussin wrote: > Hi, >=20 > I plan to work in replacing GNU groff for FreeBSD 11.0 in base by = heirloom > doctools. =85 Hi Bapt, Do you have a list of items that require doctools [if groff = isn=92t present]? Thanks! -NGie --Apple-Mail=_5798B909-BF32-4AF5-9900-77D055A152E7 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 iQEcBAEBCgAGBQJVVGuLAAoJEMZr5QU6S73egdcH/2VIXpE9jXmvsMDw+rh5EeFF M87y6W4ZMa9ZxiaeaqkSS+ooX/c6kyy1VE8n8rdOkWQkSiavFf1CRqR6W9v2mqe2 4YH1AElKah1yl6C6KsmtPmK1wM6TOloUevLGGomYEr0TUPGAqP6Awrz01qzvJdUp KvmW5AUu3bibzFh+v2hHDRDTZTshMpM4i0a977yjOvlfghQUGnoIxNFV+Wsm1OZl BQXF4DX606FqN2jBjXkGbmVKEbbc8q4Gon00fQs3Rx7/VHJg/ORgg/sSrPX/Kn7b hzhkmotWOczJw4PepvwMollkngnyWHmDuyAd3m2+KTUY4vnrUAxdKiGe0mlGM60= =puHP -----END PGP SIGNATURE----- --Apple-Mail=_5798B909-BF32-4AF5-9900-77D055A152E7-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 09:35:04 2015 Return-Path: Delivered-To: current@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 4971D812 for ; Thu, 14 May 2015 09:35:04 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1DC6180B for ; Thu, 14 May 2015 09:35:03 +0000 (UTC) Received: by wgbhc8 with SMTP id hc8so35487088wgb.3 for ; Thu, 14 May 2015 02:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=U/C7DGI9ytZctdfwKlnaAa4nqxNLpn7XwXj4S0jIvpU=; b=WeUkAtyVXJJJmxSBwoHs/fMleTzh/X7Gb8CAbjhI3n33AmgU3uMtjozNdPMrrCTuN4 +QsARqGaARUW2k3zFSlkNGJttER/P3bo38ePd15ydtX+DfqDdUBlQJCePNe/RonYI3ye VCu9MSpNFE4EIqgw0IV9kVOjPRndC77jPCbK93aOg86JIJesewT4156pfWb4GaeptSgX xHCsr2bX7pt3uOgOzjij8YnuaK64jvfLLBLg8+yYSJoT+jHWoA7Xw8TBY/ymG9dJX6dL Zkl5N01+CXZtvN22D5t6uIK1x/Sy6B4KTHNPgbqQAHyPFliv+ARvVkA2FqUFZeHHa0vo Hd5Q== X-Received: by 10.180.84.8 with SMTP id u8mr47515639wiy.39.1431596102237; Thu, 14 May 2015 02:35:02 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id k2sm12340710wif.3.2015.05.14.02.35.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 02:35:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 14 May 2015 11:34:59 +0200 From: Baptiste Daroussin To: Garrett Cooper Cc: current@FreeBSD.org Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools Message-ID: <20150514093458.GE11201@ivaldir.etoilebsd.net> References: <20150514000211.GA9410@ivaldir.etoilebsd.net> <66E508AC-1329-4E73-804B-E15BD7042FAD@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <66E508AC-1329-4E73-804B-E15BD7042FAD@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 09:35:04 -0000 --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2015 at 02:31:55AM -0700, Garrett Cooper wrote: > On May 13, 2015, at 17:02, Baptiste Daroussin wrote: >=20 > > Hi, > >=20 > > I plan to work in replacing GNU groff for FreeBSD 11.0 in base by heirl= oom > > doctools. >=20 > =E2=80=A6 >=20 > Hi Bapt, > Do you have a list of items that require doctools [if groff isn=E2=80=99= t present]? > Thanks! They are all only build time and all locate in share/docs basically everyth= ing using bsd.doc.mk man(1) also falls back on gnu groff when not able to read a manpage with ma= ndoc and I will switch that to use heirloom (and if not present try to use gnu g= roff =66rom ports) Best regards, Bapt --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVUbEIACgkQ8kTtMUmk6ExCyQCeIF3gBZumSYpH2nRby6ffUqfG f5EAoJ+hNura8ssX6eVByKtNC/uQW6EU =2Zui -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- From owner-freebsd-current@FreeBSD.ORG Thu May 14 14:50:57 2015 Return-Path: Delivered-To: current@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 911B3114; Thu, 14 May 2015 14:50:57 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAC21438; Thu, 14 May 2015 14:50:57 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 358683BB88; Thu, 14 May 2015 14:50:55 +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 t4EEoqAb048272; Thu, 14 May 2015 14:50:53 GMT (envelope-from phk@phk.freebsd.dk) To: Garrett Cooper cc: Ian Lepore , John-Mark Gurney , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <72720EA2-C251-40B9-9EC0-702C07D5EDF9@gmail.com> From: "Poul-Henning Kamp" References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <77803.1431590500@critter.freebsd.dk> <72720EA2-C251-40B9-9EC0-702C07D5EDF9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48270.1431615052.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 14 May 2015 14:50:52 +0000 Message-ID: <48271.1431615052@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:50:57 -0000 -------- In message <72720EA2-C251-40B9-9EC0-702C07D5EDF9@gmail.com>, Garrett Coope= r writes: >Until performance has been characterized on 32-bit vs = >64-bit architectures, blanket changing a value doesn't make sense. First time I saw benchmarks which showed improved performance from a larger BUFSIZe was around 1998... -- = 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-current@FreeBSD.ORG Thu May 14 14:54:18 2015 Return-Path: Delivered-To: current@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 E4AA428F for ; Thu, 14 May 2015 14:54:18 +0000 (UTC) Received: from erouter4.ore.mailhop.org (erouter4.ore.mailhop.org [54.148.38.162]) by mx1.freebsd.org (Postfix) with SMTP id BC3701556 for ; Thu, 14 May 2015 14:54:18 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 14 May 2015 14:53:12 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4EEr5E7005972; Thu, 14 May 2015 08:53:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1431615185.1221.57.camel@freebsd.org> Subject: Re: Increase BUFSIZ to 8192 From: Ian Lepore To: Poul-Henning Kamp Cc: John-Mark Gurney , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Date: Thu, 14 May 2015 08:53:05 -0600 In-Reply-To: <62511.1431589335@critter.freebsd.dk> References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:54:19 -0000 On Thu, 2015-05-14 at 07:42 +0000, Poul-Henning Kamp wrote: > -------- > In message <20150514072155.GT37063@funkthat.com>, John-Mark Gurney writes: > > >Since you apprently missed my original reply, I said that we shouldn't > >abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... > > Say what ? > > BUFSIZ is used entirely appropriately in MDXFileChunk(): For reading > a file into an algorithm. > > If in stead of open(2), fopen(3) had been used, the exact same thing > would happen, but using malloc space rather than stack space. > > I think we've got differing interpretations of what BUFSIZ is for. IMO, the one correct use of BUFSIZ outside of libc is "if you are going to call setbuf() the buffer you pass must be BUFSIZ bytes long." Over the years, it seems that many people have somehow gotten the impression that the intent was "BUFSIZ is the right/ideal/whatever size to allocate general purpose IO buffers in any program" and I don't believe that was ever the intent, or was ever correct. All such usage is erronious and must inevitably lead to the situation we've got now: it's so widely misused that it can't be changed in the context of its original purpose without pondering what the wider implications of the change might be. At least I'm inclined to ponder it. Apparently nobody else is. People running servers with more GB of ram than grains of sand on the beach won't care about things like 64k buffers used by /bin/sh to read a line of text, and all the world is big servers now, right? -- Ian From owner-freebsd-current@FreeBSD.ORG Thu May 14 15:01:43 2015 Return-Path: Delivered-To: freebsd-current@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 4D09A6B5 for ; Thu, 14 May 2015 15:01:43 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 36FC5167C for ; Thu, 14 May 2015 15:01:43 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 1E2D8341F810 for ; Thu, 14 May 2015 08:01:43 -0700 (PDT) Message-ID: <5554B8D6.1010705@mu.org> Date: Thu, 14 May 2015 08:01:42 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 References: <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> <20150514075316.GY37063@funkthat.com> <77887.1431590789@critter.freebsd.dk> <6AE8973B-3C03-497F-85A9-96C4D464B4BD@gmail.com> In-Reply-To: <6AE8973B-3C03-497F-85A9-96C4D464B4BD@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:01:43 -0000 On 5/14/15 2:23 AM, Garrett Cooper wrote: > On May 14, 2015, at 1:06, Poul-Henning Kamp wrote: > >> -------- >> In message <20150514075316.GY37063@funkthat.com>, John-Mark Gurney writes: >>> Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +0000: >>>> -------- >>>> In message <20150514072155.GT37063@funkthat.com>, John-Mark Gurney writes: >>>> >>>>> Since you apprently missed my original reply, I said that we shouldn't >>>>> abuse BUFSIZ for this work, and that it should be changed in mdXhl.c... >>>> Say what ? >>>> >>>> BUFSIZ is used entirely appropriately in MDXFileChunk(): For reading >>>> a file into an algorithm. >>> In fact, posix-2008 references LINE_MAX because: >> MDXFileChunk() does not read lines, it reads an entire file. > Being pedantic, technically it’s a portion of a file, which can be the whole thing, and it reads it in “sizeof(buffer)” chunks (of which buffer is “hardcoded" to BUFSIZ right now). > Cheers! Shouldn't most of these be using st.st_blksize ? I recall being part of the move to get rid of PAGE_SIZE, perhaps many places should be rid of BUFSIZE as well and BUFSIZE should be something we query the system for. -Alfred From owner-freebsd-current@FreeBSD.ORG Thu May 14 15:08:41 2015 Return-Path: Delivered-To: current@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 21974A7B; Thu, 14 May 2015 15:08:41 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CECC416D2; Thu, 14 May 2015 15:08:40 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 29BFC3BB88; Thu, 14 May 2015 15:08:39 +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 t4EF8cRO048340; Thu, 14 May 2015 15:08:38 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Lepore cc: John-Mark Gurney , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <1431615185.1221.57.camel@freebsd.org> From: "Poul-Henning Kamp" References: <20150511230635.GA46991@ivaldir.etoilebsd.net> <20150512032307.GP37063@funkthat.com> <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> <1431615185.1221.57.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48338.1431616118.1@critter.freebsd.dk> Date: Thu, 14 May 2015 15:08:38 +0000 Message-ID: <48339.1431616118@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:08:41 -0000 -------- In message <1431615185.1221.57.camel@freebsd.org>, Ian Lepore writes: >I think we've got differing interpretations of what BUFSIZ is for. > >IMO, the one correct use of BUFSIZ outside of libc is "if you are going >to call setbuf() the buffer you pass must be BUFSIZ bytes long." > >Over the years, it seems that many people have somehow gotten the >impression that the intent was "BUFSIZ is the right/ideal/whatever size >to allocate general purpose IO buffers in any program" I don't know when you started, but when I started, on sys-III and v7 in the mid 1980ies, that was exactly what people told you: "Do disk-I/O in BUFSIZ units". I did a quick sampling of src and that seems to be exactly how it is being used in most of the cases I looked at, including libmd where I put it there on exactly that reason back in 1994 (5?) -- 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-current@FreeBSD.ORG Thu May 14 15:27:17 2015 Return-Path: Delivered-To: freebsd-current@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 A8A9CD5 for ; Thu, 14 May 2015 15:27:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8D40F1947 for ; Thu, 14 May 2015 15:27:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C72FDEE3 for ; Thu, 14 May 2015 15:27:10 +0000 (UTC) Date: Thu, 14 May 2015 15:27:00 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1380954185.8.1431617220899.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2081898632.5.1431588884601.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2081898632.5.1431588884601.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1033 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:27:17 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu May 14 15:29:47 2015 Return-Path: Delivered-To: freebsd-current@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 27C6929A for ; Thu, 14 May 2015 15:29:47 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DE4FC1971 for ; Thu, 14 May 2015 15:29:46 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 68F023BB88; Thu, 14 May 2015 15:29:45 +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 t4EFTiLn048539; Thu, 14 May 2015 15:29:44 GMT (envelope-from phk@phk.freebsd.dk) To: Alfred Perlstein cc: freebsd-current@freebsd.org Subject: Re: Increase BUFSIZ to 8192 In-reply-to: <5554B8D6.1010705@mu.org> From: "Poul-Henning Kamp" References: <14994.1431412293@critter.freebsd.dk> <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> <20150514075316.GY37063@funkthat.com> <77887.1431590789@critter.freebsd.dk> <6AE8973B-3C03-497F-85A9-96C4D464B4BD@gmail.com> <5554B8D6.1010705@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48537.1431617383.1@critter.freebsd.dk> Date: Thu, 14 May 2015 15:29:44 +0000 Message-ID: <48538.1431617384@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:29:47 -0000 -------- In message <5554B8D6.1010705@mu.org>, Alfred Perlstein writes: >Shouldn't most of these be using st.st_blksize ? We had a long discussion about that back when GEOM was young and the conclusionis that st_blksize doesn't tell you anything useful and generally does the wrong thing, in particular on non-native filesystems like msdosfs and cd9660. But the world is more complex than even that. For instance on a RAID-5 volume, you want to write stripe-width chunks, properly aligned, no matter what the st_blksize might be in your filesystem. Unless your filesystem is guaranteed to lay out sequentially, you would have to ask before each write. Other filesystems may have opinions about read-sizes (ie: NFS). The only sane way to do this properly would be to ask each individual file with fcntl(2) for preferred read or write sizes. You could then have embedded system mount filesystems with -o iosize=min and servers instead use -o iosize=fastest But for most practical purposes, having a sane constant BUFSIZ is just fine. -- 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-current@FreeBSD.ORG Thu May 14 16:27:31 2015 Return-Path: Delivered-To: current@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 7E7072AA; Thu, 14 May 2015 16:27:31 +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 30A5F1156; Thu, 14 May 2015 16:27:31 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Ysvyj-000J6e-C3; Thu, 14 May 2015 19:27:21 +0300 Date: Thu, 14 May 2015 19:27:21 +0300 From: Slawa Olhovchenkov To: Ian Lepore Cc: Poul-Henning Kamp , John-Mark Gurney , Adrian Chadd , Hans Petter Selasky , David Chisnall , Baptiste Daroussin , "current@freebsd.org" Subject: Re: Increase BUFSIZ to 8192 Message-ID: <20150514162721.GF1394@zxy.spb.ru> References: <20150513080342.GE37063@funkthat.com> <55530CC3.1090204@selasky.org> <1431528249.1221.15.camel@freebsd.org> <20150513181347.GM37063@funkthat.com> <1431542835.1221.30.camel@freebsd.org> <20150514072155.GT37063@funkthat.com> <62511.1431589335@critter.freebsd.dk> <1431615185.1221.57.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1431615185.1221.57.camel@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 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:27:31 -0000 On Thu, May 14, 2015 at 08:53:05AM -0600, Ian Lepore wrote: > At least I'm inclined to ponder it. Apparently nobody else is. People > running servers with more GB of ram than grains of sand on the beach > won't care about things like 64k buffers used by /bin/sh to read a line > of text, and all the world is big servers now, right? I have setups with servering tens of gigabits pers second from one server. Default send_lowat (SO_SNDLOWAT) is 2048. Settnig to 128K increase load. Setting to 16k slightly reduce. Not so simple. From owner-freebsd-current@FreeBSD.ORG Fri May 15 05:04:28 2015 Return-Path: Delivered-To: freebsd-current@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 CF133DEF for ; Fri, 15 May 2015 05:04:28 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B34C5131A for ; Fri, 15 May 2015 05:04:28 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EC25BC7 for ; Fri, 15 May 2015 05:04:24 +0000 (UTC) Date: Fri, 15 May 2015 05:04:20 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <857018251.11.1431666260686.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD-tests2 #1035 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 05:04:28 -0000 See ------------------------------------------ [...truncated 2446 lines...] lib/libnv/dnv_tests:dnvlist_take_string__present -> passed [0.017s] lib/libnv/nv_tests:nvlist_add_binary__single_insert -> passed [0.019s] lib/libnv/nv_tests:nvlist_add_bool__single_insert -> passed [0.018s] lib/libnv/nv_tests:nvlist_add_null__single_insert -> passed [0.018s] lib/libnv/nv_tests:nvlist_add_number__single_insert -> passed [0.017s] lib/libnv/nv_tests:nvlist_add_nvlist__child_with_error -> passed [0.017s] lib/libnv/nv_tests:nvlist_add_nvlist__single_insert -> passed [0.162s] lib/libnv/nv_tests:nvlist_add_string__single_insert -> passed [0.018s] lib/libnv/nv_tests:nvlist_clone__empty_nvlist -> passed [0.018s] lib/libnv/nv_tests:nvlist_clone__error_nvlist -> passed [0.019s] lib/libnv/nv_tests:nvlist_clone__nested_nvlist -> passed [0.184s] lib/libnv/nv_tests:nvlist_clone__nonempty_nvlist -> passed [0.017s] lib/libnv/nv_tests:nvlist_create__is_empty -> passed [0.018s] lib/libnv/nv_tests:nvlist_free__single_binary -> passed [0.018s] lib/libnv/nv_tests:nvlist_free__single_bool -> passed [0.079s] lib/libnv/nv_tests:nvlist_free__single_null -> passed [0.020s] lib/libnv/nv_tests:nvlist_free__single_number -> passed [0.018s] lib/libnv/nv_tests:nvlist_free__single_nvlist -> passed [0.045s] lib/libnv/nv_tests:nvlist_free__single_string -> passed [0.017s] lib/libnv/nv_tests:nvlist_free_binary__single_binary -> passed [0.018s] lib/libnv/nv_tests:nvlist_free_bool__single_bool -> passed [0.021s] lib/libnv/nv_tests:nvlist_free_null__single_null -> passed [0.021s] lib/libnv/nv_tests:nvlist_free_number__single_number -> passed [0.020s] lib/libnv/nv_tests:nvlist_free_nvlist__single_nvlist -> passed [0.025s] lib/libnv/nv_tests:nvlist_free_string__single_string -> passed [0.026s] lib/libnv/nv_tests:nvlist_move_binary__single_insert -> passed [0.018s] lib/libnv/nv_tests:nvlist_move_nvlist__child_with_error -> passed [0.020s] lib/libnv/nv_tests:nvlist_move_nvlist__null_child -> passed [0.051s] lib/libnv/nv_tests:nvlist_move_nvlist__single_insert -> passed [0.189s] lib/libnv/nv_tests:nvlist_move_string__single_insert -> passed [0.018s] lib/libnv/nv_tests:nvlist_pack__empty_nvlist -> passed [0.019s] lib/libnv/nv_tests:nvlist_pack__error_nvlist -> passed [0.019s] lib/libnv/nv_tests:nvlist_pack__multiple_values -> passed [0.041s] lib/libnv/nv_tests:nvlist_take_binary__other_keys_unchanged -> passed [0.019s] lib/libnv/nv_tests:nvlist_take_binary__single_remove -> passed [0.061s] lib/libnv/nv_tests:nvlist_take_bool__other_keys_unchanged -> passed [0.018s] lib/libnv/nv_tests:nvlist_take_bool__single_remove -> passed [0.018s] lib/libnv/nv_tests:nvlist_take_number__other_keys_unchanged -> passed [0.018s] lib/libnv/nv_tests:nvlist_take_number__single_remove -> passed [0.017s] lib/libnv/nv_tests:nvlist_take_nvlist__other_keys_unchanged -> passed [0.017s] lib/libnv/nv_tests:nvlist_take_nvlist__single_remove -> passed [0.020s] lib/libnv/nv_tests:nvlist_take_string__other_keys_unchanged -> passed [0.018s] lib/libnv/nv_tests:nvlist_take_string__single_remove -> passed [0.017s] lib/libnv/nv_tests:nvlist_unpack__duplicate_key -> passed [0.021s] lib/libnv/nv_tests:nvlist_unpack__flags_nvlist -> passed [0.018s] lib/libnv/nvlist_add_test:main -> passed [0.021s] lib/libnv/nvlist_exists_test:main -> passed [0.025s] lib/libnv/nvlist_free_test:main -> passed [0.107s] lib/libnv/nvlist_get_test:main -> passed [0.023s] lib/libnv/nvlist_move_test:main -> passed [0.024s] lib/libnv/nvlist_send_recv_test:main -> passed [0.059s] lib/libpam/t_openpam_ctype:main -> passed [0.016s] lib/libpam/t_openpam_readlinev:main -> passed [0.090s] lib/libpam/t_openpam_readword:main -> May 15 04:50:35 t_openpam_readword: in openpam_readword(): unexpected end of file passed [0.124s] lib/libthr/barrier_test:barrier -> passed [10.257s] lib/libthr/cond_test:bogus_timedwaits -> passed [0.017s] lib/libthr/cond_test:broadcast -> passed [2.798s] lib/libthr/cond_test:cond_timedwait_race -> passed [4.698s] lib/libthr/cond_test:destroy_after_cancel -> passed [0.018s] lib/libthr/cond_test:signal_before_unlock -> passed [2.227s] lib/libthr/cond_test:signal_before_unlock_static_init -> passed [2.115s] lib/libthr/cond_test:signal_delay_wait -> passed [2.027s] lib/libthr/cond_test:signal_wait_race -> passed [5.953s] lib/libthr/condwait_test:cond_wait_mono -> passed [2.120s] lib/libthr/condwait_test:cond_wait_real -> passed [2.287s] lib/libthr/detach_test:pthread_detach -> May 15 04:50:35 last message repeated 2 times passed [4.083s] lib/libthr/equal_test:pthread_equal -> passed [0.165s] lib/libthr/fork_test:fork -> passed [5.082s] lib/libthr/fpu_test:fpu -> passed [0.022s] lib/libthr/join_test:pthread_join -> passed [0.034s] lib/libthr/kill_test:simple -> passed [0.037s] lib/libthr/mutex_test:mutex1 -> passed [4.097s] lib/libthr/mutex_test:mutex2 -> passed [2.067s] lib/libthr/mutex_test:mutex3 -> passed [2.386s] lib/libthr/mutex_test:mutex4 -> passed [4.039s] lib/libthr/once_test:once1 -> passed [0.018s] lib/libthr/once_test:once2 -> passed [0.074s] lib/libthr/once_test:once3 -> passed [0.149s] lib/libthr/preempt_test:preempt1 -> passed [1.098s] lib/libthr/rwlock_test:rwlock1 -> passed [2.147s] lib/libthr/sem_test:before_start_no_threads -> passed [8.825s] lib/libthr/sem_test:before_start_one_thread -> passed [3.300s] lib/libthr/sem_test:named -> passed [0.019s] lib/libthr/sem_test:unnamed -> passed [0.244s] lib/libthr/sigmask_test:before_threads -> passed [0.016s] lib/libthr/sigmask_test:incorrect_mask_bug -> passed [3.071s] lib/libthr/sigmask_test:respected_while_running -> passed [1.082s] lib/libthr/sigmask_test:upcalls_not_started -> passed [0.019s] lib/libthr/sigsuspend_test:sigsuspend -> passed [1.088s] lib/libthr/siglongjmp_test:siglongjmp1 -> passed [0.019s] lib/libthr/sleep_test:sleep1 -> passed [1.084s] lib/libthr/swapcontext_test:swapcontext1 -> passed [0.197s] lib/libthr/atexit_test:atexit -> passed [5.322s] lib/libthr/cancel_test:register_while_disabled -> passed [2.429s] lib/libthr/exit_test:main_thread -> passed [0.144s] lib/libthr/resolv_test:resolv -> passed [2.280s] lib/libthr/dlopen/dlopen_test:dlopen -> passed [0.021s] lib/libthr/dlopen/dlopen_test:dlopen_mutex -> passed [0.073s] lib/libthr/dlopen/dlopen_test:dlopen_mutex_libc -> passed [0.043s] lib/libthr/dlopen/dlopen_test:dlopen_mutex_libpthread -> passed [0.018s] lib/libthr/dlopen/main_pthread_create_test:main_pthread_create_dso -> passed [0.018s] lib/libthr/dlopen/main_pthread_create_test:main_pthread_create_main -> passed [0.071s] usr.sbin/newsyslog/legacy_test:main -> passed [60.448s] usr.sbin/pw/pw_etcdir:etcdir_must_exist -> passed [0.876s] usr.sbin/pw/pw_lock:user_locking -> passed [0.784s] usr.sbin/pw/pw_groupdel:group_do_not_delete_wheel_if_group_unknown -> passed [0.264s] usr.sbin/pw/pw_groupmod:do_not_duplicate_group_on_gid_change -> passed [0.115s] usr.sbin/pw/pw_groupmod:groupmod_bug_193704 -> passed [0.115s] usr.sbin/pw/pw_groupmod:groupmod_invalid_user -> passed [0.174s] usr.sbin/pw/pw_groupmod:groupmod_user -> passed [0.496s] usr.sbin/pw/pw_groupmod:usermod_bug_185666 -> passed [0.272s] usr.sbin/pw/pw_useradd:user_add -> passed [0.119s] usr.sbin/pw/pw_useradd:user_add_account_expiration_date_month -> passed [0.155s] usr.sbin/pw/pw_useradd:user_add_account_expiration_date_numeric -> passed [0.115s] usr.sbin/pw/pw_useradd:user_add_account_expiration_date_relative -> passed [0.115s] usr.sbin/pw/pw_useradd:user_add_account_expiration_epoch -> passed [0.261s] usr.sbin/pw/pw_useradd:user_add_comments -> passed [0.230s] usr.sbin/pw/pw_useradd:user_add_comments_invalid -> passed [0.108s] usr.sbin/pw/pw_useradd:user_add_comments_invalid_noupdate -> passed [0.174s] usr.sbin/pw/pw_useradd:user_add_comments_noupdate -> passed [0.103s] usr.sbin/pw/pw_useradd:user_add_homedir -> passed [0.137s] usr.sbin/pw/pw_useradd:user_add_noupdate -> passed [0.996s] usr.sbin/pw/pw_useradd:user_add_password_expiration_date_month -> passed [0.203s] usr.sbin/pw/pw_useradd:user_add_password_expiration_date_numeric -> passed [0.203s] usr.sbin/pw/pw_useradd:user_add_password_expiration_date_relative -> passed [0.204s] usr.sbin/pw/pw_useradd:user_add_password_expiration_epoch -> passed [0.204s] usr.sbin/pw/pw_userdel:rmuser_seperate_group -> passed [0.313s] usr.sbin/pw/pw_userdel:user_do_not_try_to_delete_root_if_user_unknown -> passed [0.077s] usr.sbin/pw/pw_usermod:user_mod -> passed [0.203s] usr.sbin/pw/pw_usermod:user_mod_comments -> passed [0.144s] usr.sbin/pw/pw_usermod:user_mod_comments_invalid -> passed [0.167s] usr.sbin/pw/pw_usermod:user_mod_comments_invalid_noupdate -> passed [0.157s] usr.sbin/pw/pw_usermod:user_mod_comments_noupdate -> passed [0.332s] usr.sbin/pw/pw_usermod:user_mod_name -> passed [0.336s] usr.sbin/pw/pw_usermod:user_mod_name_noupdate -> passed [0.128s] usr.sbin/pw/pw_usermod:user_mod_noupdate -> passed [0.201s] usr.sbin/pw/pw_usernext:usernext -> ahcich0: Timeout on slot 24 port 0 ahcich0: is 00000000 cs 00000000 ss 01000000 rs 01000000 tfd 50 serr 00000000 cmd 1000d817 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 80 c0 98 21 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command broken: Test case body timed out [309.064s] usr.sbin/pw/pw_usernext:usernext_assigned_group -> passed [10.099s] usr.sbin/pw/pw_test:longname -> ahcich0: Timeout on slot 22 port 0 ahcich0: is 00000000 cs 00000000 ss 00400000 rs 00400000 tfd 50 serr 00000000 cmd 1000d617 (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 e8 89 14 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command passed [100.453s] usr.sbin/sa/legacy_test:main -> passed [4.850s] usr.sbin/nmtree/nmtree_test:mtree_check -> passed [4.126s] usr.sbin/nmtree/nmtree_test:mtree_convert_C -> passed [0.102s] usr.sbin/nmtree/nmtree_test:mtree_convert_C_S -> passed [0.067s] usr.sbin/nmtree/nmtree_test:mtree_convert_D -> passed [0.062s] usr.sbin/nmtree/nmtree_test:mtree_convert_D_S -> passed [0.129s] usr.sbin/nmtree/nmtree_test:mtree_create -> passed [1.854s] usr.sbin/nmtree/nmtree_test:mtree_ignore -> passed [0.292s] usr.sbin/nmtree/nmtree_test:mtree_merge -> passed [0.076s] usr.sbin/nmtree/nmtree_test:mtree_nonemptydir -> passed [0.880s] usr.sbin/nmtree/nmtree_test:netbsd6_check -> passed [15.004s] usr.sbin/nmtree/nmtree_test:netbsd6_convert_C -> passed [0.061s] usr.sbin/nmtree/nmtree_test:netbsd6_convert_C_S -> passed [0.536s] usr.sbin/nmtree/nmtree_test:netbsd6_convert_D -> passed [0.081s] usr.sbin/nmtree/nmtree_test:netbsd6_convert_D_S -> passed [0.051s] usr.sbin/nmtree/nmtree_test:netbsd6_create -> passed [3.046s] usr.sbin/nmtree/nmtree_test:netbsd6_ignore -> passed [2.564s] usr.sbin/nmtree/nmtree_test:netbsd6_merge -> passed [0.057s] usr.sbin/nmtree/nmtree_test:netbsd6_nonemptydir -> passed [0.179s] usr.sbin/etcupdate/always_test:main -> Traceback (most recent call last): File "/vm/freebsd-ci/scripts/test/run-tests.py", line 152, in main(sys.argv) File "/vm/freebsd-ci/scripts/test/run-tests.py", line 80, in main runTest() File "/vm/freebsd-ci/scripts/test/run-tests.py", line 124, in runTest child2.expect(prompt, timeout=7200) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1451, in expect timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1466, in expect_list timeout, searchwindowsize) File "/usr/local/lib/python2.7/site-packages/pexpect/__init__.py", line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. version: 3.3 command: /usr/sbin/bhyve args: [u'/usr/sbin/bhyve', u'-c', u'2', u'-m', u'2G', u'-AI', u'-H', u'-P', u'-g', u'0', u'-s', u'0:0,hostbridge', u'-s', u'1:0,lpc', u'-s', u'2:0,virtio-net,tap0,mac=58:9c:fc:00:00:2e', u'-s', u'3:0,ahci-hd,/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'-l', u'com1,stdio', u'vm_test'] searcher: buffer (last 100 chars): 'tree/nmtree_test:netbsd6_nonemptydir -> passed [0.179s]\nusr.sbin/etcupdate/always_test:main -> ' before (last 100 chars): 'tree/nmtree_test:netbsd6_nonemptydir -> passed [0.179s]\nusr.sbin/etcupdate/always_test:main -> ' after: match: None match_index: None exitstatus: None flag_eof: False pid: 38414 child_fd: 4 closed: False timeout: 30 delimiter: logfile: ', mode 'w' at 0x800670150> logfile_read: None logfile_send: None maxread: 2000 ignorecase: False searchwindowsize: None delaybeforesend: 0.05 delayafterclose: 0.1 delayafterterminate: 0.1 Build step 'Execute shell' marked build as failure Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: Test reports were found but none of them are new. Did tests run? For example, is 6 hr 26 min old at hudson.tasks.junit.TestResult.parse(TestResult.java:178) at hudson.tasks.junit.TestResult.parse(TestResult.java:146) at hudson.tasks.junit.TestResult.(TestResult.java:122) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2691) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to havoc.ysv.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1361) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at hudson.FilePath.act(FilePath.java:980) at hudson.FilePath.act(FilePath.java:969) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:75) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:764) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:724) at hudson.model.Build$BuildExecution.post2(Build.java:185) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671) at hudson.model.Run.execute(Run.java:1769) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:374) From owner-freebsd-current@FreeBSD.ORG Fri May 15 13:14:34 2015 Return-Path: Delivered-To: freebsd-current@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 832819D2 for ; Fri, 15 May 2015 13:14:34 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6FCA21A21 for ; Fri, 15 May 2015 13:14:34 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 87D651B5 for ; Fri, 15 May 2015 13:14:34 +0000 (UTC) Date: Fri, 15 May 2015 13:14:33 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <762711024.13.1431695673676.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <857018251.11.1431666260686.JavaMail.jenkins@jenkins-9.freebsd.org> References: <857018251.11.1431666260686.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD-tests2 #1036 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 13:14:34 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri May 15 15:50:56 2015 Return-Path: Delivered-To: freebsd-current@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 AB8B2494 for ; Fri, 15 May 2015 15:50:56 +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 859601D88 for ; Fri, 15 May 2015 15:50:56 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 69A98B95E; Fri, 15 May 2015 11:50:55 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Date: Fri, 15 May 2015 11:40:44 -0400 Message-ID: <3725154.XnIHrZucd0@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150509142751.GV1158@albert.catwhisker.org> References: <20150509142751.GV1158@albert.catwhisker.org> 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); Fri, 15 May 2015 11:50:55 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 15:50:56 -0000 On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote: > Ref. -- > similar symptoms. And again, I captured screenshots on a phone, but > FreeBSD doesn't seem to recognize the (USB-attached) phone as something > that might act like a file system (I guess; I'm a bit new to > "smartphones"). > > In this case, my starting-point was r282623; sources were updated to > r282676. I was able to update from: > > FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #55 r282623M/282623:1100072: Fri May 8 05:40:49 PDT 2015 root@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 > > to > > FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r282676M/282676:1100073: Sat May 9 05:50:15 PDT 2015 root@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 > > without incident, but the update from: > > FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1590 r282623M/282623:1100072: Fri May 8 06:40:11 PDT 2015 root@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > was only able to build; the panic occurs before we've found any disks, > so I can't get a crash dump. I do have a kdb prompt, though, so if > someone has a suggestion for something to check, please let me know. > (Mind, reading email will be rather awkward while the laptop is exploring > the mysteries of a panic, so that might be worth bearing in mind.) > > Just prior to the bactrace, I see: > ... > hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex hdac1 (HDA driver mutex) r = 0 (0xcfef... > src/sys/dev/sound/pci/hda/hdaa.c:1571 > > The most recent relevant entries in the backtrace are: > hdaa_configure() > hdaa_attach() > device_attach() > bus_generic_attach() > hdacc_attach() > device_attach() > bus_generic_attach() > hdac_attach2() > run_interrupt_driven_config_hooks() > boot_interrupt_driven_config_hooks() > mi_startup() > begin() > > The panic message is "fatal trap 12: page fault while in kernel mode" > ... > fault code = supervisor read, page not present > ... > current process = 0 (swapper) > ... > Stopped at ... = hdaa_configure+0x14af: movb 0x3,%dl Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug? Perhaps set 'hint.hdac.0.disabled=1' at the loader prompt as a temporary workaround to boot if needed? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 15 18:30:44 2015 Return-Path: Delivered-To: freebsd-current@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 735616AF for ; Fri, 15 May 2015 18:30:44 +0000 (UTC) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 013DF111E for ; Fri, 15 May 2015 18:30:43 +0000 (UTC) Received: by lagr1 with SMTP id r1so51477723lag.0 for ; Fri, 15 May 2015 11:30:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=8gnCshJ79yqyj66V57nzpHg17W9kD0Q7xBoLqQnouzE=; b=aFCms8I1oXVUNHHZ5gHE2c+0kGHCTk3e4lfradlHgi/YqWeqBuivrA0tj4zusfNBA+ oriFN+tw3TQyUcSX0ALVWi+MnYS1FRFismo07H+YIf8sLwEp87/SWA2p3Q5AZuAFvsc0 6shgEAjgDIm29Yfoh62qzz/jfRjyO2owHVrMOzrdwnW0b+M/PaFss8Yg+mmXvB/llVOK GQnOMWwzBe6ykwsl9m1W+ZMchr+fYZw7kBoIFLg2DnCDomogrBLAsvcyfCnbRpnK+f5c xk0C+aAIJgsXnA2Da1NlGyCju4oRarwGNXmYMpwNEIOMDVvsU0Aude96wSO7R5qR7Vut 0lnw== X-Gm-Message-State: ALoCoQkWf+wW9F0vQsFwCOkpmQ6sf8hkvAqUGToQFXWksvjEiBAd+Fipb7mlek6OYUa223Js6X/P MIME-Version: 1.0 X-Received: by 10.152.203.233 with SMTP id kt9mr8138922lac.21.1431714635683; Fri, 15 May 2015 11:30:35 -0700 (PDT) Received: by 10.25.201.8 with HTTP; Fri, 15 May 2015 11:30:35 -0700 (PDT) Date: Fri, 15 May 2015 20:30:35 +0200 Message-ID: Subject: UMA initialization failure with 48 core ARM64 From: =?UTF-8?Q?Micha=C5=82_Stanek?= To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary=001a11345984485e700516230aeb X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:30:44 -0000 --001a11345984485e700516230aeb Content-Type: text/plain; charset=UTF-8 Hi, I am experiencing an early failure of UMA on an ARM64 platform with 48 cores enabled. I get a kernel panic during initialization of VM. Here is the boot log (lines with 'MST:' are my own debug printfs). Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #333 52fd91e(smp_48)-dirty: Fri May 15 18:26:56 CEST 2015 mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home/mst/freebsd_v8/kernel/sys/THUNDER-88XX arm64 FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 MST: in vm_mem_init() MST: in vmem_init() with param *vm == kernel_arena MST: in vmem_xalloc() with param *vm == kernel_arena MST: in vmem_xalloc() with param *vm == kmem_arena panic: mtx_lock() of spin mutex (null) @ /usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165 cpuid = 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at 0xffffff80001f4f80: The kernel boots fine when MAXCPU is set to 30 or lower, but the error above always appears when it is set to a higher value. The panic is triggered by a KASSERT in __mtx_lock_flags() which is called with the macro VMEM_LOCK(vm) in vmem_xalloc(). This is line 1143 in subr_vmem.c (log shows different line number due to added printfs). It looks like the lock belongs to 'kmem_arena' which is uninitialized at this point (kmeminit() has not been called yet). While debugging, I tried modifying VM code as a quick workaround. I replaced the number of cores to 1 wherever mp_ncpus, mp_maxid or MAXCPU (and others) are read. This, I believe, limits UMA per-cpu caches to just one, while the rest of the OS (scheduler, etc) sees all 48 cores. In addition, I changed UMA_BOOT_PAGES in sys/vm/uma_int.h to 512 (default was 64). With these tweaks, I got a successful (but not really stable) boot with 48 cores. Of course these are dirty hacks and a proper solution is needed. I am a bit surprised that the kernel fails with MAXCPU==48 as the amd64 arch has this value set to '256' and I have read posts that other platforms with even more cores have worked fine. Perhaps I need to tweak some other VM parameters, apart from UMA_BOOT_PAGES (AKA vm.boot_pages), but I am not sure how. I included a full stacktrace and a more verbose log (with UMA_DEBUG macros enabled) in the attachment. There is also a diff of the hacks I used while debugging. Best regards, Michal Stanek --001a11345984485e700516230aeb Content-Type: text/plain; charset=US-ASCII; name="smp_uma_WA.diff" Content-Disposition: attachment; filename="smp_uma_WA.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i9pxcjzk2 ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5fbWFsbG9jLmMgYi9zeXMva2Vybi9rZXJuX21hbGxv Yy5jCmluZGV4IGFlZjFlNGUuLmJlMjI1ZmIgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL2tlcm5fbWFs bG9jLmMKKysrIGIvc3lzL2tlcm4va2Vybl9tYWxsb2MuYwpAQCAtODc0LDcgKzg3NCw3IEBAIG1h bGxvY191bmluaXQodm9pZCAqZGF0YSkKIAkgKiBMb29rIGZvciBtZW1vcnkgbGVha3MuCiAJICov CiAJdGVtcF9hbGxvY3MgPSB0ZW1wX2J5dGVzID0gMDsKLQlmb3IgKGkgPSAwOyBpIDwgTUFYQ1BV OyBpKyspIHsKKwlmb3IgKGkgPSAwOyBpIDwgMTsgaSsrKSB7CiAJCW10c3AgPSAmbXRpcC0+bXRp X3N0YXRzW2ldOwogCQl0ZW1wX2FsbG9jcyArPSBtdHNwLT5tdHNfbnVtYWxsb2NzOwogCQl0ZW1w X2FsbG9jcyAtPSBtdHNwLT5tdHNfbnVtZnJlZXM7CmRpZmYgLS1naXQgYS9zeXMva2Vybi9zdWJy X3ZtZW0uYyBiL3N5cy9rZXJuL3N1YnJfdm1lbS5jCmluZGV4IDgwOTQwYmUuLjg5ZDYyZWQgMTAw NjQ0Ci0tLSBhL3N5cy9rZXJuL3N1YnJfdm1lbS5jCisrKyBiL3N5cy9rZXJuL3N1YnJfdm1lbS5j CkBAIC02NjUsNyArNjY1LDggQEAgdm1lbV9zdGFydHVwKHZvaWQpCiAJICogQ1BVcyB0byBhdHRl bXB0IHRvIGFsbG9jYXRlIG5ldyB0YWdzIGNvbmN1cnJlbnRseSB0byBsaW1pdAogCSAqIGZhbHNl IHJlc3RhcnRzIGluIFVNQS4KIAkgKi8KLQl1bWFfem9uZV9yZXNlcnZlKHZtZW1fYnRfem9uZSwg QlRfTUFYQUxMT0MgKiAobXBfbmNwdXMgKyAxKSAvIDIpOworCS8vbXN0IGxvb2sgaGVyZQorCXVt YV96b25lX3Jlc2VydmUodm1lbV9idF96b25lLCBCVF9NQVhBTExPQyAqICgxICsgMSkgLyAyKTsK IAl1bWFfem9uZV9zZXRfYWxsb2NmKHZtZW1fYnRfem9uZSwgdm1lbV9idF9hbGxvYyk7CiAjZW5k aWYKIH0KZGlmZiAtLWdpdCBhL3N5cy92bS91bWFfY29yZS5jIGIvc3lzL3ZtL3VtYV9jb3JlLmMK aW5kZXggYjk2YzQyMS4uNjM4MjQzNyAxMDA2NDQKLS0tIGEvc3lzL3ZtL3VtYV9jb3JlLmMKKysr IGIvc3lzL3ZtL3VtYV9jb3JlLmMKQEAgLTk4LDYgKzk4LDE0IEBAIF9fRkJTRElEKCIkRnJlZUJT RCQiKTsKICNpbmNsdWRlIDx2bS9tZW1ndWFyZC5oPgogI2VuZGlmCiAKKy8vbXN0OiBvdmVycmlk ZSBzb21lIGRlZmluZXMKKyN1bmRlZiBjdXJjcHUKKyNkZWZpbmUJY3VyY3B1CTAKKyN1bmRlZglD UFVfRk9SRUFDSAorI2RlZmluZQlDUFVfRk9SRUFDSChpKQkJCQkJCQlcCisJZm9yICgoaSkgPSAw OyAoaSkgPD0gMDsgKGkpKyspCQkJCVwKKwkJaWYgKCFDUFVfQUJTRU5UKChpKSkpCisKIC8qCiAg KiBUaGlzIGlzIHRoZSB6b25lIGFuZCBrZWcgZnJvbSB3aGljaCBhbGwgem9uZXMgYXJlIHNwYXdu ZWQuICBUaGUgaWRlYSBpcyB0aGF0CiAgKiBldmVuIHRoZSB6b25lICYga2VnIGhlYWRzIGFyZSBh bGxvY2F0ZWQgZnJvbSB0aGUgYWxsb2NhdG9yLCBzbyB3ZSB1c2UgdGhlCkBAIC0xMjI4LDYgKzEy MzYsNyBAQCBrZWdfc21hbGxfaW5pdCh1bWFfa2VnX3Qga2VnKQogCiAJaWYgKGtlZy0+dWtfZmxh Z3MgJiBVTUFfWk9ORV9QQ1BVKSB7CiAJCXVfaW50IG5jcHVzID0gbXBfbmNwdXMgPyBtcF9uY3B1 cyA6IE1BWENQVTsKKwkJbmNwdXMgPSAxOwogCiAJCWtlZy0+dWtfc2xhYnNpemUgPSBzaXplb2Yo c3RydWN0IHBjcHUpOwogCQlrZWctPnVrX3BwZXJhID0gaG93bWFueShuY3B1cyAqIHNpemVvZihz dHJ1Y3QgcGNwdSksCkBAIC0xODIyLDcgKzE4MzEsNyBAQCB1bWFfc3RhcnR1cCh2b2lkICpib290 bWVtLCBpbnQgYm9vdF9wYWdlcykKICNlbmRpZgogCWFyZ3MubmFtZSA9ICJVTUEgWm9uZXMiOwog CWFyZ3Muc2l6ZSA9IHNpemVvZihzdHJ1Y3QgdW1hX3pvbmUpICsKLQkgICAgKHNpemVvZihzdHJ1 Y3QgdW1hX2NhY2hlKSAqIChtcF9tYXhpZCArIDEpKTsKKwkgICAgKHNpemVvZihzdHJ1Y3QgdW1h X2NhY2hlKSAqICgwICsgMSkpOwogCWFyZ3MuY3RvciA9IHpvbmVfY3RvcjsKIAlhcmdzLmR0b3Ig PSB6b25lX2R0b3I7CiAJYXJncy51bWluaXQgPSB6ZXJvX2luaXQ7CkBAIC0zMzAxLDcgKzMzMTAs NyBAQCB1bWFfemVyb19pdGVtKHZvaWQgKml0ZW0sIHVtYV96b25lX3Qgem9uZSkKIHsKIAogCWlm ICh6b25lLT51el9mbGFncyAmIFVNQV9aT05FX1BDUFUpIHsKLQkJZm9yIChpbnQgaSA9IDA7IGkg PCBtcF9uY3B1czsgaSsrKQorCQlmb3IgKGludCBpID0gMDsgaSA8IDE7IGkrKykKIAkJCWJ6ZXJv KHpwY3B1X2dldF9jcHUoaXRlbSwgaSksIHpvbmUtPnV6X3NpemUpOwogCX0gZWxzZQogCQliemVy byhpdGVtLCB6b25lLT51el9zaXplKTsKQEAgLTM0NjUsNyArMzQ3NCw3IEBAIHN5c2N0bF92bV96 b25lX3N0YXRzKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiAJICovCiAJYnplcm8oJnVzaCwgc2l6ZW9m KHVzaCkpOwogCXVzaC51c2hfdmVyc2lvbiA9IFVNQV9TVFJFQU1fVkVSU0lPTjsKLQl1c2gudXNo X21heGNwdXMgPSAobXBfbWF4aWQgKyAxKTsKKwl1c2gudXNoX21heGNwdXMgPSAoMCArIDEpOwog CXVzaC51c2hfY291bnQgPSBjb3VudDsKIAkodm9pZClzYnVmX2JjYXQoJnNidWYsICZ1c2gsIHNp emVvZih1c2gpKTsKIApAQCAtMzUwOSw3ICszNTE4LDcgQEAgc3lzY3RsX3ZtX3pvbmVfc3RhdHMo U1lTQ1RMX0hBTkRMRVJfQVJHUykKIAkJCSAqIGFjY2VwdCB0aGUgcG9zc2libGUgcmFjZSBhc3Nv Y2lhdGVkIHdpdGggYnVja2V0CiAJCQkgKiBleGNoYW5nZSBkdXJpbmcgbW9uaXRvcmluZy4KIAkJ CSAqLwotCQkJZm9yIChpID0gMDsgaSA8IChtcF9tYXhpZCArIDEpOyBpKyspIHsKKwkJCWZvciAo aSA9IDA7IGkgPCAoMCArIDEpOyBpKyspIHsKIAkJCQliemVybygmdXBzLCBzaXplb2YodXBzKSk7 CiAJCQkJaWYgKGt6LT51a19mbGFncyAmIFVNQV9aRkxBR19JTlRFUk5BTCkKIAkJCQkJZ290byBz a2lwOwpkaWZmIC0tZ2l0IGEvc3lzL3ZtL3VtYV9pbnQuaCBiL3N5cy92bS91bWFfaW50LmgKaW5k ZXggMTFhYjI0Zi4uYjViNWEwNSAxMDA2NDQKLS0tIGEvc3lzL3ZtL3VtYV9pbnQuaAorKysgYi9z eXMvdm0vdW1hX2ludC5oCkBAIC0xMDcsNyArMTA3LDcgQEAKICNkZWZpbmUgVU1BX1NMQUJfTUFT SwkoUEFHRV9TSVpFIC0gMSkJLyogTWFzayB0byBnZXQgYmFjayB0byB0aGUgcGFnZSAqLwogI2Rl ZmluZSBVTUFfU0xBQl9TSElGVAlQQUdFX1NISUZUCS8qIE51bWJlciBvZiBiaXRzIFBBR0VfTUFT SyAqLwogCi0jZGVmaW5lIFVNQV9CT09UX1BBR0VTCQk2NAkvKiBQYWdlcyBhbGxvY2F0ZWQgZm9y IHN0YXJ0dXAgKi8KKyNkZWZpbmUgVU1BX0JPT1RfUEFHRVMJCTUxMgkvKiBQYWdlcyBhbGxvY2F0 ZWQgZm9yIHN0YXJ0dXAgKi8KIAogLyogTWF4IHdhc3RlIHBlcmNlbnRhZ2UgYmVmb3JlIGdvaW5n IHRvIG9mZiBwYWdlIHNsYWIgbWFuYWdlbWVudCAqLwogI2RlZmluZSBVTUFfTUFYX1dBU1RFCTEw Cg== --001a11345984485e700516230aeb-- From owner-freebsd-current@FreeBSD.ORG Fri May 15 18:32:38 2015 Return-Path: Delivered-To: freebsd-current@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 CF6B37CA for ; Fri, 15 May 2015 18:32:38 +0000 (UTC) Received: from pmta2.delivery4.ore.mailhop.org (pmta2.delivery4.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id 9671B11D8 for ; Fri, 15 May 2015 18:32:38 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA for ; Fri, 15 May 2015 18:31:31 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4FIVT5d008568 for ; Fri, 15 May 2015 12:31:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1431714689.91685.10.camel@freebsd.org> Subject: CFR - watchdogd exit timeout From: Ian Lepore To: "freebsd-current@freebsd.org" Date: Fri, 15 May 2015 12:31:29 -0600 Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:32:38 -0000 I would like to add a new feature to watchdogd(8): -x option to specify the watchdog timeout to leave in effect when the program exits (currently behavior is to disable the watchdog on exit). The change is available for review... https://reviews.freebsd.org/D2556 -- Ian From owner-freebsd-current@FreeBSD.ORG Fri May 15 18:39:58 2015 Return-Path: Delivered-To: freebsd-current@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 9CDDED48; Fri, 15 May 2015 18:39:58 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 6CF6C126C; Fri, 15 May 2015 18:39:57 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4FIdukY067247; Fri, 15 May 2015 11:39:56 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4FIduVO067246; Fri, 15 May 2015 11:39:56 -0700 (PDT) (envelope-from david) Date: Fri, 15 May 2015 11:39:56 -0700 From: David Wolfskill To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Message-ID: <20150515183956.GU1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , John Baldwin , freebsd-current@freebsd.org References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6y2Evnd5/t1JTLIo" Content-Disposition: inline In-Reply-To: <3725154.XnIHrZucd0@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:39:58 -0000 --6y2Evnd5/t1JTLIo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2015 at 11:40:44AM -0400, John Baldwin wrote: > On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote: > > Ref. -- > > similar symptoms. And again, I captured screenshots on a phone, but > > FreeBSD doesn't seem to recognize the (USB-attached) phone as something > > that might act like a file system (I guess; I'm a bit new to > > "smartphones"). > >=20 > > In this case, my starting-point was r282623; sources were updated to > > r282676. I was able to update from: > ... > > Stopped at ... =3D hdaa_configure+0x14af: movb 0x3,%dl >=20 > Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug? > Perhaps set 'hint.hdac.0.disabled=3D1' at the loader prompt as a temporary > workaround to boot if needed? > ... 'hint.hdac.0.disabled=3D1' appended to /boot/device.hints temporarily. now running: FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1597 r282948M/282952:= 1100073: Fri May 15 09:13:17 PDT 2015 root@g1-254.catwhisker.org:/commo= n/S4/obj/usr/src/sys/CANARY i386 Info you requested: (gdb) l *hdaa_configure+0x14af 0xc08c8e3f is in hdaa_configure (/usr/src/sys/dev/sound/pci/hda/hdaa.c:3280= ). 3275 as[cnt].pincnt++; 3276 /* Association 15 is a multiple unassociate= d pins. */ 3277 if (j =3D=3D 15) 3278 cnt++; 3279 } 3280 if (j !=3D 15 && as[cnt].pincnt > 0) { 3281 if (hpredir && as[cnt].pincnt > 1) 3282 as[cnt].hpredir =3D first; 3283 cnt++; 3284 } (gdb)=20 Info about the machine (verbose dmesg.boot; dmidecode; pciconf -lv output) may be found at . Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --6y2Evnd5/t1JTLIo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVVj18XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7HN0P/3vI7eXNn+PzFdqxLsAfYgTa VDwCnhcGeTYPrBF2s6E/CAItj7LI8M3OCH+gYvwrJn/tJXEffs6HmAqREQC9dWnJ 6F7WFfrSBAkcsPN3S56SYJ5lys5yPS0dRkOF0XaQvAATFThWse9x8e2WIbrjo6Lg pVBpVlkkaco9zw2ifkC0bK7gCqKfwBvALxoaCrnUPF1Fb/O3yZYaRw9V3XLXCZzI 9tH//FHbEPZaekTxCjDeZSKwv8XCUkVQ9jngdJfcS4Dl/vyywLyh5T2Hg+mV4Ege W634Dr8DOvthXEkd2PraQKImzEgILjHm77KZFjpkZR7VepNzoGonJu2oPle0Xpwe 8pmN6rPYPi0gkO6oNcQoQYR+143c3AThatltkPUFFnDrN5N2rsbdI29fyohEOtee I6EnRGghKQaIGWnuzkjk8v4KT4KT7VvshBHYh0aIdtfjlxg0kArcNRWHEIitvVr0 I6Ru+k8y20/qG9d9hn+UngQa0jt33yK/yPOPg675p1AbchAjeCIcwO5PAFsGur/N BqQSMiD2oq8HzjT/gzBR0IcVjf2qapTVC544a5N1B1xvPe9kVuXw8dx06o5sh51C 0nkDc34354KeZ2e+hDvDGeupEtkcr/80VgBN6XBVLoeSIyIskthuw+zo1OEa5r+K H7N9/8x6cBkj5ZEcP0MI =RvcF -----END PGP SIGNATURE----- --6y2Evnd5/t1JTLIo-- From owner-freebsd-current@FreeBSD.ORG Fri May 15 18:59:16 2015 Return-Path: Delivered-To: freebsd-current@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 1CA141BB for ; Fri, 15 May 2015 18:59:16 +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 EC3F6153A for ; Fri, 15 May 2015 18:59:15 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E96CB915; Fri, 15 May 2015 14:59:14 -0400 (EDT) From: John Baldwin To: David Wolfskill Cc: freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Date: Fri, 15 May 2015 14:59:10 -0400 Message-ID: <1567746.I7cSSt5lv5@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.1-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150515183956.GU1215@albert.catwhisker.org> References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> 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); Fri, 15 May 2015 14:59:14 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:59:16 -0000 On Friday, May 15, 2015 11:39:56 AM David Wolfskill wrote: > On Fri, May 15, 2015 at 11:40:44AM -0400, John Baldwin wrote: > > On Saturday, May 09, 2015 07:27:51 AM David Wolfskill wrote: > > > Ref. -- > > > similar symptoms. And again, I captured screenshots on a phone, but > > > FreeBSD doesn't seem to recognize the (USB-attached) phone as something > > > that might act like a file system (I guess; I'm a bit new to > > > "smartphones"). > > > > > > In this case, my starting-point was r282623; sources were updated to > > > r282676. I was able to update from: > > ... > > > Stopped at ... = hdaa_configure+0x14af: movb 0x3,%dl > > > > Can you do 'l *hdaa_configure+0x14af' in gdb against the kernel.debug? > > Perhaps set 'hint.hdac.0.disabled=1' at the loader prompt as a temporary > > workaround to boot if needed? > > ... > > 'hint.hdac.0.disabled=1' appended to /boot/device.hints temporarily. > > now running: > FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1597 r282948M/282952:1100073: Fri May 15 09:13:17 PDT 2015 root@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > Info you requested: > > (gdb) l *hdaa_configure+0x14af > 0xc08c8e3f is in hdaa_configure (/usr/src/sys/dev/sound/pci/hda/hdaa.c:3280). > 3275 as[cnt].pincnt++; > 3276 /* Association 15 is a multiple unassociated pins. */ > 3277 if (j == 15) > 3278 cnt++; > 3279 } > 3280 if (j != 15 && as[cnt].pincnt > 0) { > 3281 if (hpredir && as[cnt].pincnt > 1) > 3282 as[cnt].hpredir = first; > 3283 cnt++; > 3284 } > (gdb) Hummm, the only recent change is 281544, but that should be in your working kernel. It does mess with the layout of pins though so maybe try reverting it anyway? It might also be worth trying to revert just the one commit you identified earlier. It just seems odd for 'as[cnt]' to fault here but not earlier. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 15 20:07:31 2015 Return-Path: Delivered-To: freebsd-current@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 BA143423; Fri, 15 May 2015 20:07:31 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 86F6A1D17; Fri, 15 May 2015 20:07:30 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4FK7SNt068158; Fri, 15 May 2015 13:07:28 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4FK7RNR068157; Fri, 15 May 2015 13:07:27 -0700 (PDT) (envelope-from david) Date: Fri, 15 May 2015 13:07:27 -0700 From: David Wolfskill To: John Baldwin Cc: freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Message-ID: <20150515200727.GV1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , John Baldwin , freebsd-current@freebsd.org References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q2B1bTINGa+6bWWJ" Content-Disposition: inline In-Reply-To: <1567746.I7cSSt5lv5@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:07:31 -0000 --q2B1bTINGa+6bWWJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2015 at 02:59:10PM -0400, John Baldwin wrote: > ... > Hummm, the only recent change is 281544, but that should be in your worki= ng > kernel. Yes; that dates from 14 April, and I had been doing daily build/boots of head/i386 through thta period without incident. Absent something compelling, I'm pretty sure that experience alone removes 281544 from plausibly being implicated. > It does mess with the layout of pins though so maybe try reverting it > anyway? >=20 > It might also be worth trying to revert just the one commit you identified > earlier. It just seems odd for 'as[cnt]' to fault here but not earlier. > .... OK; I tried reverting 282650, but the result wouldn't build because the AFMT_CHANNEL_MAX token wasn't defined. Turns out it had been used by 282651, so I reverted that (and found that it would have been cleaner had I reverted them in reverse sequence, but "svn patch" seemed to merely whine a bit, but cope anyway). After reverting both 282650 & 282651, the resulting kernel built. I commented out the 'hint.hdac.0.disabled=3D1' entry in /boot/device.hints, pressed the button, and watched for magic smoke.... FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1598 r282948M/282952:= 1100072: Fri May 15 12:39:11 PDT 2015 root@localhost:/common/S4/obj/usr= /src/sys/CANARY i386 localhost(11.0-C)[4] cat /dev/sndstat=20 Installed devices: pcm0: (play) pcm1: (play) pcm2: (play/rec) default pcm3: (play/rec) localhost(11.0-C)[5]=20 No magic smoke leaked out this time! :-) (I note that with 'hint.hdac.0.disabled=3D1' in place, only the RealTek codec showed up in that output. Not that this is surprising -- rather, it's a bit of a "comforting reality check" after seeing so many panics.) Please also note: * head/amd64 hasn't experienced any such panics for me (yes, on the same hardware; that's one of the reasons I do this sort of thing). * This hardware exhibits a bit of a peculiarity under FreeBSD: if phones are inserted in the headphone jack, there's a loud static/hissing sound, regardless of any intentional source of a signal being played. Neither MS Windows 7, Fedora 20, nor Fedora 21 exhibits this behavior. (I'm trying to puzzle my way through the way the Linux folks document the HDA configuration to try to figure out what knob needs to be twisted in what way so I can use headphones on the machine.... Clues would be welcome.) Anyway, I think we have a smoking gun, as it were. Thanks for your help, John! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --q2B1bTINGa+6bWWJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVVlH/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7hj0P/R3KqIlBZTt+OpRhaHF1kinG NiyflOcmBib6XSvtJEfqSN5PUiSQD37RmlkipGkkJ8W3qTlmT/Kst4K4oiLg7PEr UIdL7g/QFFrrquEVJFBpN4Ifog5430RGm25qkVBf9qStTUOOpaa/FkITCguN/CLI edSG7jh1p4VwaCvcwCq6wlJPgP/EX+BRdSTzuDdfxCFgEp6IaTUK5l3f/dKlR+q3 c2NHvXmr7xj1JvJD0WEUxVE5GEv0guukQU97xyNNNmq9BjpvpztAr4HTujRh6nIj GnRMhtpM9n/V00BxWg1+I9WtwbJX+mKyDDxLA/qJbrk/M01JHNfxhFzxwySJP5Z9 YhZ5Gs+3MDZdg+w48sA6QZXtBR0XTqfkY5dm72yg5ImzpGN5megDFsLCGS7yWkqM R/zADCak3jSMKfvRI9AjOUiL9r8o+pJLH2nA640NIoqOQWpTd0V04TbVZlNwROi1 H3b6UejC1iTlXzCIN+XjXVZSAMsZK3v140eALfEB/Hdf5fUVseCfGXENZuDrE9zz 5X47i4kf4PsNfLXuhMgVWQVTyI/aw6dFwAtY1JTIaUPJxZGdw+iIvFLBiDiVkW5i D6Aw6xIATa491L/XmqgJrGxZRk+XHOV3bVEH41/oa06iKU4HACSU/8K7KiCumE0H 38r38+Tg5VZ7I6my/AgC =vAQA -----END PGP SIGNATURE----- --q2B1bTINGa+6bWWJ-- From owner-freebsd-current@FreeBSD.ORG Fri May 15 20:37:13 2015 Return-Path: Delivered-To: freebsd-current@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 11CF4DA7 for ; Fri, 15 May 2015 20:37:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 013231045 for ; Fri, 15 May 2015 20:37:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A385F263 for ; Fri, 15 May 2015 20:37:12 +0000 (UTC) Date: Fri, 15 May 2015 20:37:11 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1269880774.15.1431722231881.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #1037 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:37:13 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri May 15 20:39:48 2015 Return-Path: Delivered-To: freebsd-current@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 C33EBEC2; Fri, 15 May 2015 20:39:48 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AE06D105D; Fri, 15 May 2015 20:39:48 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B9912265; Fri, 15 May 2015 20:39:48 +0000 (UTC) Date: Fri, 15 May 2015 20:39:47 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, ian@FreeBSD.org, gnn@FreeBSD.org, cy@FreeBSD.org, zbb@FreeBSD.org, pfg@FreeBSD.org Message-ID: <81719606.16.1431722388689.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_i386 #137 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:39:48 -0000 See Changes: [pfg] Break apart the gnu_inline attribute and use "artificial" if available. In general it is bad practice to use the gnu_inline attribute but we will need it in special cases like FORTIFY_SOURCE. In this specific case it is also useful to have the "artificial" attribute: "This attribute is useful for small inline wrappers which if possible should appear during debugging as a unit, depending on the debug info format it will either mean marking the function as artificial or using the caller location for all instructions within the inlined body." This attribute appears to be currently implemented only in GCC. Use it only in conjuntion with gnu_inline in the cases where it is available, which is similar in spirit in how it's used in glibc. [cy] Correct location for libntpevent.a. [zbb] Introduce support for the Alpine PoC from Annapurna Labs The Alpine Platform-On-Chip offers multicore processing (quad ARM Cortex-A15), 1/10Gb Ethernet, SATA 3, PCI-E 3, DMA engines, Virtualization, Advanced Power Management and other. This code drop involves basic platform support including: SMP, IRQs, SerDes, SATA. As of now it is missing the PCIe support. Part of the functionality is provided by the low-level code (HAL) delivered by the chip vendor (Annapurna Labs) and is a subject to change in the future (is planned to be moved to sys/contrib directory). The review log for this commit is available here: https://reviews.freebsd.org/D2340 Reviewed by: andrew, ian, imp Obtained from: Semihalf Sponsored by: Annapurna Labs [ian] Add assertions that the addresses passed to tlb maintenance are page-aligned. Perform cache writebacks and invalidations in the correct (inner to outer or vice versa) order, and add comments that explain that. Consistantly use 'va' as the variable name for virtual addresses. Submitted by: Michal Meloun [ian] Retrieve the cache parms in the proper arch-specific way. Submitted by: Michal Meloun [gnn] Summary: Remove spurious, extra, next header comments. Correct the name of the pad length field. [pfg] Replace a CONSTCOND for a void value as a replacement for __unreachable builtin This only applies if we are not using clang or gcc but it lets us use the __unreachable() buitin in expressions. Suggested by: tijl ------------------------------------------ [...truncated 62285 lines...] 14 errors generated. In file included from :15: In file included from :52: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :52: In file included from :138: In file included from :35: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :33: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :55: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :34: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ 14 errors generated. In file included from :15: In file included from :52: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :52: In file included from :138: In file included from :35: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :33: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :55: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :34: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ 14 errors generated. In file included from :15: In file included from :52: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :52: In file included from :138: In file included from :35: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :33: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :55: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :34: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ 14 errors generated. mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in 1 error make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Fri May 15 22:28:06 2015 Return-Path: Delivered-To: freebsd-current@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 B5EF0D1D; Fri, 15 May 2015 22:28:06 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9E63B1CAE; Fri, 15 May 2015 22:28:06 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7507F27E; Fri, 15 May 2015 22:28:06 +0000 (UTC) Date: Fri, 15 May 2015 22:27:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, pkelsey@FreeBSD.org, br@FreeBSD.org, jhb@FreeBSD.org, ian@FreeBSD.org, gnn@FreeBSD.org, emaste@FreeBSD.org, mav@FreeBSD.org, cy@FreeBSD.org, zbb@FreeBSD.org, pfg@FreeBSD.org, bapt@FreeBSD.org Message-ID: <1008793256.17.1431728886223.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2769 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-Mailman-Approved-At: Fri, 15 May 2015 22:35:27 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 22:28:06 -0000 See Changes: [pfg] Break apart the gnu_inline attribute and use "artificial" if available. In general it is bad practice to use the gnu_inline attribute but we will need it in special cases like FORTIFY_SOURCE. In this specific case it is also useful to have the "artificial" attribute: "This attribute is useful for small inline wrappers which if possible should appear during debugging as a unit, depending on the debug info format it will either mean marking the function as artificial or using the caller location for all instructions within the inlined body." This attribute appears to be currently implemented only in GCC. Use it only in conjuntion with gnu_inline in the cases where it is available, which is similar in spirit in how it's used in glibc. [cy] Correct location for libntpevent.a. [zbb] Introduce support for the Alpine PoC from Annapurna Labs The Alpine Platform-On-Chip offers multicore processing (quad ARM Cortex-A15), 1/10Gb Ethernet, SATA 3, PCI-E 3, DMA engines, Virtualization, Advanced Power Management and other. This code drop involves basic platform support including: SMP, IRQs, SerDes, SATA. As of now it is missing the PCIe support. Part of the functionality is provided by the low-level code (HAL) delivered by the chip vendor (Annapurna Labs) and is a subject to change in the future (is planned to be moved to sys/contrib directory). The review log for this commit is available here: https://reviews.freebsd.org/D2340 Reviewed by: andrew, ian, imp Obtained from: Semihalf Sponsored by: Annapurna Labs [ian] Add assertions that the addresses passed to tlb maintenance are page-aligned. Perform cache writebacks and invalidations in the correct (inner to outer or vice versa) order, and add comments that explain that. Consistantly use 'va' as the variable name for virtual addresses. Submitted by: Michal Meloun [ian] Retrieve the cache parms in the proper arch-specific way. Submitted by: Michal Meloun [gnn] Summary: Remove spurious, extra, next header comments. Correct the name of the pad length field. [pfg] Replace a CONSTCOND for a void value as a replacement for __unreachable builtin This only applies if we are not using clang or gcc but it lets us use the __unreachable() buitin in expressions. Suggested by: tijl [bapt] Allow MANWIDTH to work with mandoc(1) Reported by: bdrewery [pkelsey] When a netmap process terminates without the full set of buffers it was granted via rings and ni_bufs_list_head represented in those rings and lists (e.g., via SIGKILL), those buffers are no longer available for subsequent users for the lifetime of the system. To mitigate this resource leak, reset the allocator state when the last ref to that allocator is released. Note that this only recovers leaked resources for an allocator when there are no longer any users of that allocator, so there remain circumstances in which leaked allocator resources may not ever be recovered - consider a set of multiple netmap processes that are all using the same allocator (say, the global allocator) where members of that set may be killed and restarted over time but at any given point there is one member of that set running. Based on intial work by adrian@. Reviewed by: Giuseppe Lettieri (g.lettieri@iet.unipi.it), luigi Approved by: jmallett (mentor) MFC after: 1 week Sponsored by: Norse Corp, Inc. [emaste] Build libgomp only if we're also building base system GCC Clang's OpenMP support will emit Intel OpenMP API library calls, and will therefore require libiomp (or whatever name is settled on). An up-to-date version of libgomp is included in ports or pkg GCC. Thus, there is no reason to build base libgomp without base system GCC. PR: 199979 (exp-run) Reviewed by: pfg Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D2459 [br] Provide the number of interrupt resources added to the list by using extra argument, so caller will know that. [jhb] Previously, cv_waiters was only updated by cv_signal or cv_wait. If a thread awakened due to a time out, then cv_waiters was not decremented. If INT_MAX threads timed out on a cv without an intervening cv_broadcast, then cv_waiters could overflow. To fix this, have each sleeping thread decrement cv_waiters when it resumes. Note that previously cv_waiters was protected by the sleepq chain lock. However, that lock is not held when threads resume from sleep. In addition, the interlock is also not always reacquired after resuming (cv_wait_unlock), nor is it always held by callers of cv_signal() or cv_broadcast(). Instead, use atomic ops to update cv_waiters. Since the sleepq chain lock is still held on every increment, it should still be safe to compare cv_waiters against zero while holding the lock in the wakeup routines as the only way the race should be lost would result in extra calls to sleepq_signal() or sleepq_broadcast(). Differential Revision: https://reviews.freebsd.org/D2427 Reviewed by: benno Reported by: benno (wrap of cv_waiters in the field) MFC after: 2 weeks [mav] Close some potential races around socket start/close. There are some reports about panics on ic->ic_socket NULL derefence. This kind of races is the only way I can imagine it to happen. MFC after: 2 weeks ------------------------------------------ [...truncated 81378 lines...] 14 errors generated. In file included from :15: In file included from :52: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :52: In file included from :138: In file included from :35: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :33: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :55: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :34: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ 14 errors generated. In file included from :15: In file included from :52: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :52: In file included from :138: In file included from :35: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :33: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :55: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :34: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ 14 errors generated. In file included from :15: In file included from :52: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :52: In file included from :138: In file included from :35: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :53: In file included from :33: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :55: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :32: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ In file included from :15: In file included from :59: In file included from :21: In file included from :38: In file included from :34: In file included from :6: In file included from :36: :550:2: error: #else after #else #else ^ :36:2: error: unterminated conditional directive #ifndef _SYS_CDEFS_H_ ^ 14 errors generated. mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in 1 error make[4]: stopped in 1 error make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Fri May 15 22:43:02 2015 Return-Path: Delivered-To: freebsd-current@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 E71C011A; Fri, 15 May 2015 22:43:02 +0000 (UTC) Received: from mx0.deglitch.com (unknown [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id A29311E70; Fri, 15 May 2015 22:43:02 +0000 (UTC) Received: from dhcp-250-37.sj.pi-coral.com (unknown [12.218.212.178]) by mx0.deglitch.com (Postfix) with ESMTPSA id 1F5EA8FC2D; Sat, 16 May 2015 02:42:53 +0400 (MSK) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: UMA initialization failure with 48 core ARM64 From: Stanislav Sedov In-Reply-To: Date: Fri, 15 May 2015 15:42:49 -0700 Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A6C7643-0C10-4451-B547-9D50EA6809B8@freebsd.org> References: To: =?utf-8?Q?Micha=C5=82_Stanek?= X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 22:43:03 -0000 > On May 15, 2015, at 11:30 AM, Micha=C5=82 Stanek = wrote: >=20 > Hi, >=20 > I am experiencing an early failure of UMA on an ARM64 platform with 48 > cores enabled. I get a kernel panic during initialization of VM. Here = is > the boot log (lines with 'MST:' are my own debug printfs). >=20 > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #333 52fd91e(smp_48)-dirty: Fri May 15 18:26:56 = CEST > 2015 > = mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home= /mst/freebsd_v8/kernel/sys/THUNDER-88XX > arm64 > FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 > MST: in vm_mem_init() > MST: in vmem_init() with param *vm =3D=3D kernel_arena > MST: in vmem_xalloc() with param *vm =3D=3D kernel_arena > MST: in vmem_xalloc() with param *vm =3D=3D kmem_arena > panic: mtx_lock() of spin mutex (null) @ > /usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165 > cpuid =3D 0 > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at 0xffffff80001f4f80: >=20 > The kernel boots fine when MAXCPU is set to 30 or lower, but the error > above always appears when it is set to a higher value. >=20 > The panic is triggered by a KASSERT in __mtx_lock_flags() which is = called > with the macro VMEM_LOCK(vm) in vmem_xalloc(). This is line 1143 in > subr_vmem.c (log shows different line number due to added printfs). > It looks like the lock belongs to 'kmem_arena' which is uninitialized = at > this point (kmeminit() has not been called yet). >=20 > While debugging, I tried modifying VM code as a quick workaround. I > replaced the number of cores to 1 wherever mp_ncpus, mp_maxid or = MAXCPU > (and others) are read. This, I believe, limits UMA per-cpu caches to = just > one, while the rest of the OS (scheduler, etc) sees all 48 cores. > In addition, I changed UMA_BOOT_PAGES in sys/vm/uma_int.h to 512 = (default > was 64). > With these tweaks, I got a successful (but not really stable) boot = with 48 > cores. Of course these are dirty hacks and a proper solution is = needed. >=20 > I am a bit surprised that the kernel fails with MAXCPU=3D=3D48 as the = amd64 > arch has this value set to '256' and I have read posts that other = platforms > with even more cores have worked fine. Perhaps I need to tweak some = other > VM parameters, apart from UMA_BOOT_PAGES (AKA vm.boot_pages), but I am = not > sure how. >=20 > I included a full stacktrace and a more verbose log (with UMA_DEBUG = macros > enabled) in the attachment. There is also a diff of the hacks I used = while > debugging. >=20 >=20 Hi, Michal! It looks like the log attachment didn=E2=80=99t make it though the = mailing list. Can you please resend it again? The panic suggests that a mutex was left uninitialized... -- ST4096-RIPE From owner-freebsd-current@FreeBSD.ORG Fri May 15 23:42:47 2015 Return-Path: Delivered-To: current@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 68A08C3; Fri, 15 May 2015 23:42:47 +0000 (UTC) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (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 D508C1603; Fri, 15 May 2015 23:42:44 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBD461.dip0.t-ipconnect.de [93.203.212.97]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t4FNhXIg009053; Sat, 16 May 2015 01:43:33 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t4FNgdvQ053941; Sat, 16 May 2015 01:42:39 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t4FNgRgq076946; Sat, 16 May 2015 01:42:39 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201505152342.t4FNgRgq076946@fire.js.berklix.net> To: Baptiste Daroussin cc: current@freebsd.org Subject: Re: [RFC] Replace gnu groff in base by heirloom doctools From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 14 May 2015 02:02:11 +0200." <20150514000211.GA9410@ivaldir.etoilebsd.net> Date: Sat, 16 May 2015 01:42:26 +0200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 23:42:47 -0000 Hi Bapt & current@ > I think keeping a fully functionnal roff(7) toolchain part of the > base system is very good on a unix. Yes, Unix has always also been a tool to get jobs done (aka PWB), as well as merely recompile more Unix. Ditto FreeBSD. > From what I could check I cannot find any regression when migrating from gnu > groff to heirloom doctools, if there is a particular area when you think extra > care is needed please share it. > > Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Regression tests that use public BSD source & data to build more BSD are a good start, but just a start, insufficient to discover all problems. There's non public user data sets to consider. Many users won't read current@, just announce@, so before removal hits a Release, we need a one Release warning, ie "This is the last Release before old functionality goes. Assume lots of user data will Not be compatible with heirloom-doctools & users wont know to start checking their data, until they see an announcement in the next Release. We'll need a copy of same version of existing tools, macros etc, copied out unchanged to a port or meta port so users affected have a lifeboat. User data Will break: (My groff usage frequently broke when groff changed: I use groff for CV, business card, letters, invoices, & personal, with embedded pics, scaled & offset figures, tables, fonts, sizes, & ouput in all of txt ps pdf pcl & html output.) Unfortnately I have'nt time to help test with my data as FreeBSD already eats too much time, shoving bind from src to ports (+planning to dump bind & move on) + ripping majordomo & acroread out of ports, all of which I need & must restore before upgrading servers & workstations. Changes would need maximal warning & minimum disruption please. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. From owner-freebsd-current@FreeBSD.ORG Sat May 16 01:08:45 2015 Return-Path: Delivered-To: freebsd-current@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 F2E44994; Sat, 16 May 2015 01:08:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DC6BA1DAF; Sat, 16 May 2015 01:08:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 039232C7; Sat, 16 May 2015 01:08:44 +0000 (UTC) Date: Sat, 16 May 2015 01:08:44 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, gnn@FreeBSD.org, emaste@FreeBSD.org, cy@FreeBSD.org, bapt@FreeBSD.org, pkelsey@FreeBSD.org, br@FreeBSD.org, jhb@FreeBSD.org, dim@FreeBSD.org, ian@FreeBSD.org, mav@FreeBSD.org, zbb@FreeBSD.org, pfg@FreeBSD.org, adrian@FreeBSD.org Message-ID: <196644437.19.1431738524868.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1008793256.17.1431728886223.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1008793256.17.1431728886223.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2770 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Sat, 16 May 2015 01:31:24 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 01:08:45 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat May 16 02:18:05 2015 Return-Path: Delivered-To: freebsd-current@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 455AD3AE for ; Sat, 16 May 2015 02:18:05 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0621487 for ; Sat, 16 May 2015 02:18:05 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5BEDB2E4 for ; Sat, 16 May 2015 02:18:05 +0000 (UTC) Date: Sat, 16 May 2015 02:18:05 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1416019450.21.1431742685343.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1269880774.15.1431722231881.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1269880774.15.1431722231881.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1038 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:18:05 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat May 16 02:13:42 2015 Return-Path: Delivered-To: freebsd-current@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 EEA05359; Sat, 16 May 2015 02:13:41 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D96591470; Sat, 16 May 2015 02:13:41 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E0B982E3; Sat, 16 May 2015 02:13:41 +0000 (UTC) Date: Sat, 16 May 2015 02:13:41 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, dim@FreeBSD.org, gnn@FreeBSD.org, ian@FreeBSD.org, cy@FreeBSD.org, zbb@FreeBSD.org, pfg@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1399830580.20.1431742421875.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <81719606.16.1431722388689.JavaMail.jenkins@jenkins-9.freebsd.org> References: <81719606.16.1431722388689.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_i386 #138 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS X-Mailman-Approved-At: Sat, 16 May 2015 03:47:33 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:13:42 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat May 16 13:27:15 2015 Return-Path: Delivered-To: freebsd-current@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 51527F70; Sat, 16 May 2015 13:27:15 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 16707164E; Sat, 16 May 2015 13:27:14 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6936A1FE023; Sat, 16 May 2015 15:27:12 +0200 (CEST) Message-ID: <555745DD.8080506@selasky.org> Date: Sat, 16 May 2015 15:27:57 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Wolfskill , John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> <20150515200727.GV1215@albert.catwhisker.org> In-Reply-To: <20150515200727.GV1215@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 13:27:15 -0000 On 05/15/15 22:07, David Wolfskill wrote: > On Fri, May 15, 2015 at 02:59:10PM -0400, John Baldwin wrote: >> ... >> Hummm, the only recent change is 281544, but that should be in your working >> kernel. > > Yes; that dates from 14 April, and I had been doing daily build/boots of > head/i386 through thta period without incident. Absent something > compelling, I'm pretty sure that experience alone removes 281544 from > plausibly being implicated. > >> It does mess with the layout of pins though so maybe try reverting it >> anyway? >> >> It might also be worth trying to revert just the one commit you identified >> earlier. It just seems odd for 'as[cnt]' to fault here but not earlier. >> .... > > OK; I tried reverting 282650, but the result wouldn't build because the > AFMT_CHANNEL_MAX token wasn't defined. > > Turns out it had been used by 282651, so I reverted that (and found that > it would have been cleaner had I reverted them in reverse sequence, but > "svn patch" seemed to merely whine a bit, but cope anyway). > > After reverting both 282650 & 282651, the resulting kernel built. > Hi, I'm seeing two of my commits mentioned here, r282650 & r282651. Are these what is causing the problem? You are sure the built the kernel and all modules from clean, hence some structures are changed, panic would be expected if you don't. --HPS From owner-freebsd-current@FreeBSD.ORG Sat May 16 13:37:47 2015 Return-Path: Delivered-To: freebsd-current@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 BF6B2292; Sat, 16 May 2015 13:37:47 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 7DEFD179B; Sat, 16 May 2015 13:37:46 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4GDbiRn076766; Sat, 16 May 2015 06:37:44 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4GDbiKL076765; Sat, 16 May 2015 06:37:44 -0700 (PDT) (envelope-from david) Date: Sat, 16 May 2015 06:37:44 -0700 From: David Wolfskill To: Hans Petter Selasky Cc: John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Message-ID: <20150516133744.GF1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Hans Petter Selasky , John Baldwin , freebsd-current@freebsd.org References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> <20150515200727.GV1215@albert.catwhisker.org> <555745DD.8080506@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WLt36Y5q0ztVU3FZ" Content-Disposition: inline In-Reply-To: <555745DD.8080506@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 13:37:47 -0000 --WLt36Y5q0ztVU3FZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 16, 2015 at 03:27:57PM +0200, Hans Petter Selasky wrote: > ... > > After reverting both 282650 & 282651, the resulting kernel built. > > >=20 > Hi, >=20 > I'm seeing two of my commits mentioned here, r282650 & r282651. Are=20 > these what is causing the problem? You are sure the built the kernel and= =20 > all modules from clean, hence some structures are changed, panic would=20 > be expected if you don't. > .... I'll admit that the vast bulk of my builds are done with -DNOCLEAN -- I actually want to use my laptop for things other than rebuilding FreeBSD (4x/day) and rebuilding updated installed ports (2x/day). After I finish the build I'm presently doing, I will try re-doing r282650 & r282651, then rebuilding cleanly. I noted that r282650 included a bump to param.h to force all modules to be rebuilt. I also note that the panic was only seen in head/i386 -- head/amd64 on the same hardware, using the same procedures, sources updated from the same local private mirror of the SVN repo, using a copy of the same "CANARY" kernel config file, had no issue. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --WLt36Y5q0ztVU3FZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVV0goXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7gzMQAKZLSZRYj7ypVIBZe+XHRlSF hgGW2Mji0xXMvScA2UaeSFyfmXqXnS0ojBIFDvfWW4STSEe6oVZy5pieqFnOpLOR Sj8gOKZdeTvhQ9a+KvXtGDv+PDbKiRUOlODixEmO6Sguf/nvxFozywbBlyCtc0cW cv1Qf69DQZlVhnX+Pnqwn2ALhbmEjSsuEwCSELmaXOF811bAUn6gslgLTrRqJ0Li NSi55GJULTl9IdOETrilkucXxJczhN6tioso/CelagA2zoY7TOOv0o63OCqbrxkf zeK+AP7y1NzBL4TUGTaq18OACm+tkcPRaDDND8uQazce+mvWXZLVGeCakR7pD/+6 /rc3aZZlU5a95tvucjkQdpH6h0LiwzJwIVOzLiD1YHCR9WVRtZBT8rHJh9u9XLBt Me6FhI/Y5rXsqI7LWCc+nuGxEZz3LPVLLGA8ey6UikPp3igVGI0FTuBOKJzyOOIB Ak7ylPGXxO3QkuW5yDakYdjPyuPy1VOFBPMWEhcyJfavrNgOszGjo164wrdOhvnt BPHiA6vljsjFkNuU41uDpvptesDbhjqTh/o+19hyE+XWyluItHfQKCqmNzgMP5lu SwW3NQCftVpGKrmCx07HHZg+jeId7Je4p4ArWF/TfclNfW6zy1aG41Fj9GkUYWE+ oZl1DKS5BStJX44zLqW+ =UNLP -----END PGP SIGNATURE----- --WLt36Y5q0ztVU3FZ-- From owner-freebsd-current@FreeBSD.ORG Sat May 16 13:45:43 2015 Return-Path: Delivered-To: freebsd-current@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 CF94F44E; Sat, 16 May 2015 13:45:43 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 9058F1893; Sat, 16 May 2015 13:45:42 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4D35F1FE023; Sat, 16 May 2015 15:45:33 +0200 (CEST) Message-ID: <55574A2A.3060800@selasky.org> Date: Sat, 16 May 2015 15:46:18 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Wolfskill , John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> <20150515200727.GV1215@albert.catwhisker.org> <555745DD.8080506@selasky.org> In-Reply-To: <555745DD.8080506@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 13:45:43 -0000 On 05/16/15 15:27, Hans Petter Selasky wrote: > On 05/15/15 22:07, David Wolfskill wrote: >> On Fri, May 15, 2015 at 02:59:10PM -0400, John Baldwin wrote: >>> ... >>> Hummm, the only recent change is 281544, but that should be in your >>> working >>> kernel. >> >> Yes; that dates from 14 April, and I had been doing daily build/boots of >> head/i386 through thta period without incident. Absent something >> compelling, I'm pretty sure that experience alone removes 281544 from >> plausibly being implicated. >> >>> It does mess with the layout of pins though so maybe try reverting it >>> anyway? >>> >>> It might also be worth trying to revert just the one commit you >>> identified >>> earlier. It just seems odd for 'as[cnt]' to fault here but not earlier. >>> .... >> >> OK; I tried reverting 282650, but the result wouldn't build because the >> AFMT_CHANNEL_MAX token wasn't defined. >> >> Turns out it had been used by 282651, so I reverted that (and found that >> it would have been cleaner had I reverted them in reverse sequence, but >> "svn patch" seemed to merely whine a bit, but cope anyway). >> >> After reverting both 282650 & 282651, the resulting kernel built. >> > > Hi, > > I'm seeing two of my commits mentioned here, r282650 & r282651. Are > these what is causing the problem? You are sure the built the kernel and > all modules from clean, hence some structures are changed, panic would > be expected if you don't. > > --HPS Hi, Can you collect output from booting with bootverbose set? From current amd64 as of today. Then repeat using i386. Possibly some array is out of bounds or code has not been compiled properly. I just quickly counted the fmtlist size and from what I can see we are using 30 of 32 entries at least. Before that ensure /usr/obj is clean: "rm -rf /usr/obj" --HPS From owner-freebsd-current@FreeBSD.ORG Sat May 16 13:49:17 2015 Return-Path: Delivered-To: freebsd-current@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 DA69D56D; Sat, 16 May 2015 13:49:17 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 9A5B618B4; Sat, 16 May 2015 13:49:17 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 561CC1FE023; Sat, 16 May 2015 15:49:15 +0200 (CEST) Message-ID: <55574B08.9010202@selasky.org> Date: Sat, 16 May 2015 15:50:00 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Wolfskill , John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> <20150515200727.GV1215@albert.catwhisker.org> <555745DD.8080506@selasky.org> <20150516133744.GF1215@albert.catwhisker.org> In-Reply-To: <20150516133744.GF1215@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 13:49:17 -0000 On 05/16/15 15:37, David Wolfskill wrote: > On Sat, May 16, 2015 at 03:27:57PM +0200, Hans Petter Selasky wrote: >> ... >>> After reverting both 282650 & 282651, the resulting kernel built. >>> >> >> Hi, >> >> I'm seeing two of my commits mentioned here, r282650 & r282651. Are >> these what is causing the problem? You are sure the built the kernel and >> all modules from clean, hence some structures are changed, panic would >> be expected if you don't. >> .... > Hi, > I'll admit that the vast bulk of my builds are done with -DNOCLEAN -- I > actually want to use my laptop for things other than rebuilding FreeBSD > (4x/day) and rebuilding updated installed ports (2x/day). Then it will possibly trigger bad, because AFMT_CHANNELS() returns part of the old EXT channels, which is used in the HDAA driver. If you want to save time, you need to rebuild all of "modules/sound" only, w/o -DNO_CLEAN and doing "clean" first. The rest of the kernel is fine with -DNO_CLEAN. > After I finish the build I'm presently doing, I will try re-doing > r282650 & r282651, then rebuilding cleanly. > > I noted that r282650 included a bump to param.h to force all modules to > be rebuilt. > > I also note that the panic was only seen in head/i386 -- head/amd64 on > the same hardware, using the same procedures, sources updated from the > same local private mirror of the SVN repo, using a copy of the same > "CANARY" kernel config file, had no issue. Send output from bootverbose! Let's hunt this bug down :-) --HPS From owner-freebsd-current@FreeBSD.ORG Sat May 16 14:07:27 2015 Return-Path: Delivered-To: freebsd-current@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 3999E8BE; Sat, 16 May 2015 14:07:27 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 092761AA6; Sat, 16 May 2015 14:07:26 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4GE7Pur077048; Sat, 16 May 2015 07:07:25 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4GE7P5s077047; Sat, 16 May 2015 07:07:25 -0700 (PDT) (envelope-from david) Date: Sat, 16 May 2015 07:07:25 -0700 From: David Wolfskill To: Hans Petter Selasky Cc: John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Message-ID: <20150516140725.GG1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Hans Petter Selasky , John Baldwin , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3BZbN51TFvUEXf+G" Content-Disposition: inline In-Reply-To: <55574B08.9010202@selasky.org> <55574A2A.3060800@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 14:07:27 -0000 --3BZbN51TFvUEXf+G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 16, 2015 at 03:46:18PM +0200, Hans Petter Selasky wrote: > ... >=20 > Can you collect output from booting with bootverbose set? From current=20 > amd64 as of today. OK; I just copied it over; please see ; the dmesg in question is dmesg.boot.11.0-CURRENT_amd64. It is for: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 r28300= 5M/283005:1100073: Sat May 16 06:04:16 PDT 2015 root@g1-254.catwhisker.= org:/common/S3/obj/usr/src/sys/CANARY amd64 > Then repeat using i386. For now, I've copied yesterday's head/i386 dmesg. I'll copy over my stable/10 dmesg.boot files, as well -- same directory; the names will be similarly verbosely unambiguous. :-} I'll copy today's head/i386 once I've generated it (which should be within a few minutes). > Possibly some array is out of bounds or code has not been compiled > properly. I just quickly counted the fmtlist size and from what I > can see we are using 30 of 32 entries at least. OK. > Before that ensure /usr/obj is clean: "rm -rf /usr/obj" > ... OK. On Sat, May 16, 2015 at 03:50:00PM +0200, Hans Petter Selasky wrote: > ... > > I'll admit that the vast bulk of my builds are done with -DNOCLEAN -- I > > actually want to use my laptop for things other than rebuilding FreeBSD > > (4x/day) and rebuilding updated installed ports (2x/day). >=20 > Then it will possibly trigger bad, because AFMT_CHANNELS() returns part= =20 > of the old EXT channels, which is used in the HDAA driver. If you want=20 > to save time, you need to rebuild all of "modules/sound" only, w/o=20 > -DNO_CLEAN and doing "clean" first. The rest of the kernel is fine with= =20 > -DNO_CLEAN. To make things easier to understand and explain, I think it's best to=20 go ahead and just do a clean build this time. That should reduce uncertainty a fair bit. > ... > Send output from bootverbose! Let's hunt this bug down :-) > .... As above (along with a fair bit more information). And hunting the bug down and ... disposing of it ... is my intent all along -- thanks for your efforts! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --3BZbN51TFvUEXf+G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVV08cXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7nd0P/AzRp8iOE4VSO1vMTyydB90r hhPfM1ehOyFeebGU5cddU+6oLoxGaeu1thny0B4v79ZcVe3ayrqYLyVYSh9rlhsL HcB637LJHOSALRxrsINYQbFayBrMNcqWVrh44Eyvvcda/BIDyBJjBXMMhdtH6sFh t57BKdyd778zcoUY7DaDvhJDsitnsrzldfXILkC7YPekn0/C98KD2kRiqKipl0Z7 wqSxntJ9+/Rz91nTrANkBGJ8bY4IbhO4TG8Tmp5ySK6NrDwaW047/dnJxmS4Vxxv fX/rkZVvhbUlpK5pfzGwzOmEbc0gSkTKp3w9Dej79Mj8U1tFBHy6LheKn4twJliu KUOSYjOT4Z+5v6XMcgykXWh8ARoiEf72UHLVJJyXweH2HncLS+J1OqjsOtRKtvko Ck6cFnxXoOnEj9rPX7Hd+GnaFqpVrdwEeasDXVafHhja9xp6/PiFIrg6K+KQ+P48 NxlTF6vgJCtVSiWLkcnwwVZOXeJ1FR2m0cTjskeSL3Up/Y9lT8w4sAQIbhJx4xTH 0KC68m0DloTnqcrU0jTmlZglxsdkV2ZyY+0F8CjsvFG4cP8qrylxlwJs42OvYf8D UBvK/au2fnJkA8WsREx5aytjd2UlG8GNENQ4Uy7I4heApjVkplKs07X/7503lrNl hsAFoHYfloDrFv0blIdg =pB4s -----END PGP SIGNATURE----- --3BZbN51TFvUEXf+G-- From owner-freebsd-current@FreeBSD.ORG Sat May 16 15:54:03 2015 Return-Path: Delivered-To: freebsd-current@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 E719A526; Sat, 16 May 2015 15:54:02 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 A3312150E; Sat, 16 May 2015 15:54:02 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t4GFs0rL078500; Sat, 16 May 2015 08:54:00 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t4GFs0F3078499; Sat, 16 May 2015 08:54:00 -0700 (PDT) (envelope-from david) Date: Sat, 16 May 2015 08:54:00 -0700 From: David Wolfskill To: Hans Petter Selasky Cc: John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Message-ID: <20150516155400.GI1215@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Hans Petter Selasky , John Baldwin , freebsd-current@freebsd.org References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> <20150515200727.GV1215@albert.catwhisker.org> <555745DD.8080506@selasky.org> <20150516133744.GF1215@albert.catwhisker.org> <55574B08.9010202@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ewecuplBYD0UBlH/" Content-Disposition: inline In-Reply-To: <55574B08.9010202@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 15:54:03 -0000 --ewecuplBYD0UBlH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 16, 2015 at 03:50:00PM +0200, Hans Petter Selasky wrote: > ... > Send output from bootverbose! Let's hunt this bug down :-) > .... OK; after restoring r282650 & r282651, clearing /usr/obj, and performing a clean buildworld, kernel, and installworld, the "smoke test" reboot yielded (a recurrence of) the panic that has been the topic of this thread. I then appended: hint.hdac.0.disabled=3D1 to /boot/device.hints, and was then able to complete a boot of: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283005= M/283005:1100073: Sat May 16 08:17:05 PDT 2015 root@g1-254.catwhisker.o= rg:/common/S4/obj/usr/src/sys/CANARY i386 to multi-user mode. As noted earlier, there's a fair amount of information about the system at , including verbose dmesg.boot copies from {head,stable10}{amd64,i386}. I will be happy to provide anything else I can The panic information appears to be the same as I originally reported; ref. for that. What's next? Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ewecuplBYD0UBlH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVV2gYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7XD4P/jLAiLew9/jj6fJxDyEHfVWX 20rpH7SZSJgWdgF/lWK9/RBecZMrpoPgvEVGEljsNHPYWl+4xRIIsnGA/CmEGUcU agRrBYCtA6751UWWVcDhodo/8BxZ2NLtdmnDz7+4Yk2883Ep5thb5thL56xL0+K+ AWc8udOjBjZ98s3opnQYalD7gkZTTw0sqnETOSAG4xhf8iFfUSRx8hXE63WwKqNT FhVeNuIMguLWZkk4wl677qQtqrhSWQ/iKXkMbL+kgw+a+kWR8w7D8quz35xdwexB ItRa6QHNpOIQs7b+rkUfUY2hLn1cIpeO2W+orSUTnduV1Fo3FWw2JPWW59dB5A86 nUvgOGxlCQfp4O9VqplY0H0h3yA78uYJxUCLaZlMCf4lhKcdy4aQfpMwsNAOcCwC nkHWc4yiQXUey2Uz0Q6Xfh+mOP+JURJ9yroPJadCDA6zoyxQ1+fwIwMmQfDJo36a T6zx5JseHQCuHGVN9EOr7Oji92WLAO15hKiMxGrXp2qRiIcF1AGw6ZAwOgZSKf2N KdT1YtT+PUeH5Zu0U8U9N5XAMBCP82F90QEEMnML6BXYC493gez/ebFcX9xjMRoI cpanv3K6e4BHxxG7xmqtcYsEMmEz3RY1qTPbE3Oc6Vp8La58m9Q2oluNFjBotm9L 1PXHl4wFI0ltnjWfsyA8 =CMkl -----END PGP SIGNATURE----- --ewecuplBYD0UBlH/-- From owner-freebsd-current@FreeBSD.ORG Sat May 16 16:43:05 2015 Return-Path: Delivered-To: freebsd-current@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 82BB7660; Sat, 16 May 2015 16:43:05 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 3FFC71A0E; Sat, 16 May 2015 16:43:04 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 59FAD1FE023; Sat, 16 May 2015 18:43:02 +0200 (CEST) Message-ID: <555773C3.3030408@selasky.org> Date: Sat, 16 May 2015 18:43:47 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Wolfskill , John Baldwin , freebsd-current@freebsd.org Subject: Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again References: <20150509142751.GV1158@albert.catwhisker.org> <3725154.XnIHrZucd0@ralph.baldwin.cx> <20150515183956.GU1215@albert.catwhisker.org> <1567746.I7cSSt5lv5@ralph.baldwin.cx> <20150515200727.GV1215@albert.catwhisker.org> <555745DD.8080506@selasky.org> <20150516133744.GF1215@albert.catwhisker.org> <55574B08.9010202@selasky.org> <20150516155400.GI1215@albert.catwhisker.org> In-Reply-To: <20150516155400.GI1215@albert.catwhisker.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 16:43:05 -0000 On 05/16/15 17:54, David Wolfskill wrote: > On Sat, May 16, 2015 at 03:50:00PM +0200, Hans Petter Selasky wrote: >> ... >> Send output from bootverbose! Let's hunt this bug down :-) >> .... > > OK; after restoring r282650 & r282651, clearing /usr/obj, and performing > a clean buildworld, kernel, and installworld, the "smoke test" reboot > yielded (a recurrence of) the panic that has been the topic of this > thread. > > I then appended: > > hint.hdac.0.disabled=1 > > to /boot/device.hints, and was then able to complete a boot of: > > FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283005M/283005:1100073: Sat May 16 08:17:05 PDT 2015 root@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > to multi-user mode. > > As noted earlier, there's a fair amount of information about the system > at , including verbose > dmesg.boot copies from {head,stable10}{amd64,i386}. I will be happy to > provide anything else I can > > The panic information appears to be the same as I originally reported; > ref. for > that. > > What's next? Maybe you can remove hda from the kernel config and load as modules instead on the panicing i386, after multi-user mode is enabled. Then also set bootverbose and you'll get a proper dump with dmesg. I want to compare the prints using meld or something like that. --HPS From owner-freebsd-current@FreeBSD.ORG Sat May 16 19:50:49 2015 Return-Path: Delivered-To: current@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 B630ED1D for ; Sat, 16 May 2015 19:50:49 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9561C42 for ; Sat, 16 May 2015 19:50:49 +0000 (UTC) Received: by lagr1 with SMTP id r1so86123176lag.0 for ; Sat, 16 May 2015 12:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=LXWeXY5UkckcRLvYMlkhq4Y4Ex9QQJMbtSHIkXK6PUA=; b=gBsXKbYLd2yq4dxj72C5TrsJdDiSXT76Z8Onu3Rw0TM4Rik2I7E6vqQ3ZTPQMBztt7 kBKIGL6mmKFDnZZXRZ0eDZUALZhyrcB6s3SEq4/R0+bzfro0GFXnBIkhLK2nb8Rh4EmS DYrh+nLKiDMoSF/Ru4FOHtknlcm0gV4eAvhmH3j3QC9JsNVZvC0uIfjjK/ka6H6oEEdv TGIgu82w+/UTLKR5sfRwDlvEonB7oaUQrvHWihM3tAVF14qoW2ZkboyythGNtu9hOWT3 8mZqvBhth6sdObqUZXhmGnkCEOKQHAmsFHGxpN2apD22OY3SWKTBC2ugOjdTn3u5T3xv rqOQ== X-Received: by 10.112.171.101 with SMTP id at5mr11972681lbc.66.1431805847243; Sat, 16 May 2015 12:50:47 -0700 (PDT) Received: from kloomba ([77.94.196.84]) by mx.google.com with ESMTPSA id jl4sm1361386lbc.14.2015.05.16.12.50.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 12:50:46 -0700 (PDT) Sender: Roman Bogorodskiy Date: Sat, 16 May 2015 19:50:25 +0300 From: Roman Bogorodskiy To: current@FreeBSD.org Subject: UEFI, loader and keyboard problems Message-ID: <20150516165024.GA1230@kloomba> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 19:50:49 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm running -CURRENT amd64 and have weird problems with keyboard in loader. Specifically, some char keys produce numbers. For example: boot --> b66t The problem appears to be with the right side of the query layout. 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The same for the second row, 'h' is still 'h', but 'j' is '1' etc. That happens with USB keyboard only, PS/2 works as expected. I also cannot use keyboard in serial console in boot loader, but it becomes available when system boots. FreeBSD 11.0-CURRENT (GENERIC) #0 r282110: Mon Apr 27 20:49:15 UTC 2015 /boot/loader.conf: boot_multicons="YES" boot_serial="YES" comconsole_speed="115200" console="efi,comconsole" Am I triggering some bug or it's some configuration problem? Roman Bogorodskiy --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVV3VQAAoJEMltX/4IwiJqFF8IAJXrprimUkk6+OgJFGV2krSn yN8ORrqxD/gyEivfqH3K5JOOf94wPnllQV2ednBce4RQk7ykkQAS1t1B00tI3kfa TBmhzZAYBlcen5ATndn8VZGuo9Z8Zt/9oLm7GF5F8RYxsZW/CN0zETbqEWZo8sPh kTPUIGjScW4YhBT/dOSd9nATRpzw/6oKcRnTMbkksgvolxgqjMa0/Z3Bkj2DtKwj FZm1CX+PB6jA1Eg6q9VTSHU7gP9zV8IHkpfzfdJW4esGcFXoz7+01Y6wOaaj7EmO vJHfxB2q3EfLRtzs2ZC3+Czg8UMKafLNhcfrJUC0qs5Oo1/h+XA+qwl/Uhqet4A= =48f7 -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-current@FreeBSD.ORG Sat May 16 21:28:19 2015 Return-Path: Delivered-To: current@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 DC45152E; Sat, 16 May 2015 21:28:19 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:0:20e:cff:fea0:e4a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D13A1611; Sat, 16 May 2015 21:28:19 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::939:9e23:89a9:92e3] (unknown [IPv6:2001:7b8:3a7:0:939:9e23:89a9:92e3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B0ABA1D4F7; Sat, 16 May 2015 23:28:07 +0200 (CEST) Subject: Re: UEFI, loader and keyboard problems Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_022498A7-BB75-458B-B48D-3AF349067EA6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <20150516165024.GA1230@kloomba> Date: Sat, 16 May 2015 23:27:52 +0200 Cc: current@FreeBSD.org Message-Id: References: <20150516165024.GA1230@kloomba> To: Roman Bogorodskiy X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 21:28:20 -0000 --Apple-Mail=_022498A7-BB75-458B-B48D-3AF349067EA6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 16 May 2015, at 18:50, Roman Bogorodskiy wrote: > > I'm running -CURRENT amd64 > > and have weird problems with keyboard in loader. Specifically, some char > keys produce numbers. For example: > > boot --> b66t > > The problem appears to be with the right side of the query layout. > > 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The same > for the second row, 'h' is still 'h', but 'j' is '1' etc. Is this maybe some weird keyboard in combination with NUM LOCK on? -Dimitry --Apple-Mail=_022498A7-BB75-458B-B48D-3AF349067EA6 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----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlVXtmcACgkQsF6jCi4glqNpFwCg7uvKLRp2zmPfxMgMpC4S5SLK VuYAoJD5JaephcdCoPhlBk9EE4HqkF75 =gs93 -----END PGP SIGNATURE----- --Apple-Mail=_022498A7-BB75-458B-B48D-3AF349067EA6-- From owner-freebsd-current@FreeBSD.ORG Sat May 16 21:47:08 2015 Return-Path: Delivered-To: freebsd-current@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 DCC1F854 for ; Sat, 16 May 2015 21:47:08 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id BA44417CB for ; Sat, 16 May 2015 21:47:08 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 0B37EABC61 for ; Sat, 16 May 2015 21:47:06 +0000 (UTC) Message-ID: <5557BAF8.4070904@freebsd.org> Date: Sat, 16 May 2015 17:47:36 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: UEFI, loader and keyboard problems References: <20150516165024.GA1230@kloomba> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xi24e1KEJACDpicp2GELhToLA0FXLBiOg" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 21:47:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xi24e1KEJACDpicp2GELhToLA0FXLBiOg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-05-16 17:27, Dimitry Andric wrote: > On 16 May 2015, at 18:50, Roman Bogorodskiy wrote: >> >> I'm running -CURRENT amd64 >> >> and have weird problems with keyboard in loader. Specifically, some ch= ar >> keys produce numbers. For example: >> >> boot --> b66t >> >> The problem appears to be with the right side of the query layout. >> >> 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The same >> for the second row, 'h' is still 'h', but 'j' is '1' etc. >=20 > Is this maybe some weird keyboard in combination with NUM LOCK on? >=20 > -Dimitry >=20 That is a good insight, I know a lot of laptops have a 'numpad' feature where the keys on the right side of the keyboard can provide the functionality of the numpad when numlock is on or when a function modify key is depressed. --=20 Allan Jude --xi24e1KEJACDpicp2GELhToLA0FXLBiOg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVV7r7AAoJEJrBFpNRJZKfwzoQALTSkZ/YYtFaonzo6oE1+Gp0 qu1j5esIbYjsIeNpQHEqYsqLo0Cz+Y+yFgam3E3juf/pwniUznELJVKFwQ2MToHa KrBQD6MqrgnMgSSZhHQJP0kddaWM1fm6lQa1i2xrVczhJgZMQF357m2CBzu5Hn5P xvv+BLwpglhdFuiQ35JeLdkj2Wy25j4Y/vAZr7yLyl5EaJE/mz4sMFYcFPvhNaqY /JOv3UaJxrOSXRubqg+9P2WMx1kBoHG/rgyBOLZ1ziZI7IQXIBmPMe7KytCwKtfX l9nWCMpYJV7mcgjveZgpL/RyAprKbBnHE3jNyeOhMY3TMNADDJsWJd77lZlRPotB inztXsjxFgWHPDJVEuz83/jYFpP5/Ej59zkBmOCRS3HZZokPvzZy78xSe6UtbUNS gbifAWQJ5IL78RFRgZREDE1KeXJIoJ9/SgxfMqR4H9lIbvFJALLOefDoVDDnePS1 +bmdwjzjb1izi6bj+6OXdhvpzonC//P8+Mc6wfXEp3VRsc2QZHuPKumb6q3jU3ko 5GKxYATZ303J9Xjz/v/HsuUIqSnfGgd4Hs3XMTB9l4SVEzLge/B7x6aA00xdsHi0 h1arvLDSaIcYhGbYjDHa8GIgnYS9O3xV92BxBvQzWUcAjag8n6ejtt7PadC5ir/X GzwwgC2D78QkFTpRIs6D =ZMgs -----END PGP SIGNATURE----- --xi24e1KEJACDpicp2GELhToLA0FXLBiOg-- From owner-freebsd-current@FreeBSD.ORG Sat May 16 21:49:16 2015 Return-Path: Delivered-To: freebsd-current@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 D0724999; Sat, 16 May 2015 21:49:16 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E7AF17FD; Sat, 16 May 2015 21:49:16 +0000 (UTC) Received: by pabru16 with SMTP id ru16so82798356pab.1; Sat, 16 May 2015 14:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=w20YO/7UPyM6H8bwSfx1R5TjZJrPWdyPFAfGZRW0L2c=; b=yMbHvB452ssjObLqbbjYNblSqGT6SknACFuE4DWe0FYbOb7yuDu/EtzOVP0FOCt6zf Cy//GCBNu6LFOlldiXy8zOdN4ZCjbaLJIIEFqlKH0H8p9bps1sQTzvu2/hFhDHg09Ymv 6G4d0Wl6G1haJVPu7ypBLogcSx2UPvWCEzYh0sOj65/Nnn1OzDusRZf9005G0et1WYPT EDe59FAP/1Qrm/tKd9odogiXmtFNKbcmr714EA+pZU9QAYYWCDr1LtlCCmHgmQozG/zQ hXjttNEEKQfZNMMYdXmazD7oqx5VoKXXk6E7jYSlto/ZCapea0yyWc4wZuPaRGCqsiU6 bgJA== X-Received: by 10.70.127.202 with SMTP id ni10mr30892024pdb.10.1431812956038; Sat, 16 May 2015 14:49:16 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:f826:2ec1:1713:8219? ([2601:8:ab80:7d6:f826:2ec1:1713:8219]) by mx.google.com with ESMTPSA id rt8sm5549444pbb.37.2015.05.16.14.49.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 14:49:15 -0700 (PDT) Subject: Re: UEFI, loader and keyboard problems Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6D1C9327-3A11-4B97-A006-988681DF3D40"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: <5557BAF8.4070904@freebsd.org> Date: Sat, 16 May 2015 14:49:12 -0700 Cc: freebsd-current@freebsd.org Message-Id: <1B7BB188-33D0-4EFD-ACD3-6CB0F1A1AE66@gmail.com> References: <20150516165024.GA1230@kloomba> <5557BAF8.4070904@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 21:49:17 -0000 --Apple-Mail=_6D1C9327-3A11-4B97-A006-988681DF3D40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 16, 2015, at 14:47, Allan Jude wrote: > On 2015-05-16 17:27, Dimitry Andric wrote: >> On 16 May 2015, at 18:50, Roman Bogorodskiy = wrote: >>>=20 >>> I'm running -CURRENT amd64 >>>=20 >>> and have weird problems with keyboard in loader. Specifically, some = char >>> keys produce numbers. For example: >>>=20 >>> boot --> b66t >>>=20 >>> The problem appears to be with the right side of the query layout. >>>=20 >>> 'y' is still 'y', but 'u' becomes '4', 'i' becomes '5', etc. The = same >>> for the second row, 'h' is still 'h', but 'j' is '1' etc. >>=20 >> Is this maybe some weird keyboard in combination with NUM LOCK on? >>=20 >> -Dimitry >>=20 >=20 > That is a good insight, I know a lot of laptops have a 'numpad' = feature > where the keys on the right side of the keyboard can provide the > functionality of the numpad when numlock is on or when a function = modify > key is depressed. It also depends on the keyboard itself. US keyboards are fairly = straightforward, but other ones are a bit more complex, e.g. Japanese = keyboards. Thanks! -NGie --Apple-Mail=_6D1C9327-3A11-4B97-A006-988681DF3D40 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 iQEcBAEBCgAGBQJVV7tZAAoJEMZr5QU6S73edoYH/jPJoyiHYEURzE2zGSXAIHDt 9qMx7JRx2aTrWZEYtObxmUS1J/J6iaXAcE3z4Ind81Bn1aFgdfrjA6dZe7Q0ygW/ KuxIO5AtVoeUbCVWCS7B5Tqe8915E5DO93l3Q+kSIHQk1enpHbCwNRchvV9V0efj R0iiHbvpp/vJ4MwBgJXE6e/5VVD9NviarFCJ4GHwu5TfZuFJNTljg5XK7crrR6n1 ngIIoiGV2NuH1/wYGECBHeBWwQx94Pow5AA4G2DiGuZ8mK01TZMYUQLMZjndazvP Kbm00wGym5wKn2C9qz68UcjCRreeeI5OhlxE820/D9Dm7APrUSwDZkM4HGcKUJk= =L/MD -----END PGP SIGNATURE----- --Apple-Mail=_6D1C9327-3A11-4B97-A006-988681DF3D40--