From owner-freebsd-current@freebsd.org Sun Jun 4 00:07:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95AE4BFB97F for ; Sun, 4 Jun 2017 00:07:20 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5842682282; Sun, 4 Jun 2017 00:07:19 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1dHJ4e-0008CR-L3; Sun, 04 Jun 2017 02:07:16 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1dHJ4e-0008Pe-Jt; Sun, 04 Jun 2017 02:07:16 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Sun, 04 Jun 2017 00:07:16 GMT From: "Jeffrey Bouquet" To: "Allan Jude" CC: "freebsd-current" Subject: Re: undefined symbol 'stat' Date: Sat, 03 Jun 2017 17:07:16 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <280bd5e8-e3d5-746e-3078-1bf615aee580@freebsd.org> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 00:07:20 -0000 On Sat, 3 Jun 2017 19:32:02 -0400, Allan Jude wrote: > On 2017-06-03 19:28, Jeffrey Bouquet wrote: > > The latest pkg updates broke firefox here, which won't build [ patch= es fail to apply ] > > Also seamonkey, but building sqlite3 locally fixed that. > >=20=20=20 > > [ not that I'd expect firefox to build anyway, not been that lucky re= cently... ]=20 > >=20 > > Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I= can find. > >=20 > > Subject give the entirety of the error.=20 > > Building webkit-gtk2 locally as of now to try to fix it in a third ro= und of ports. ...=20 > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > >=20 >=20 > The ino64 change that went into -current recently changed a lot of stuff > related to stat(), and versioned the symbol. You are trying to run apps > compiled for a newer version of -current than you are running. You need > to update your kernel and userland to patch what pkg is built against. >=20 > --=20 > Allan Jude Thanks. I'm getting around to it, unfortunately too slowly. Not a half ho= ur after the email, I have the v11 firefox package running happily. webkit-gtk2 also bu= ilt here. So no immediate concern, browser or other GUI [ claws-mail ] at least that = I use daily. [ pkg.freebsd.org seems way undermentioned in the wiki, and elsewh= ere... BTW ]=20 =20=20= From owner-freebsd-current@freebsd.org Sat Jun 3 20:59:11 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6068BF902F for ; Sat, 3 Jun 2017 20:59:11 +0000 (UTC) (envelope-from 0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@amazonses.com) Received: from a8-176.smtp-out.amazonses.com (a8-176.smtp-out.amazonses.com [54.240.8.176]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DB257DDE8 for ; Sat, 3 Jun 2017 20:59:11 +0000 (UTC) (envelope-from 0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1496523544; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=57PAa8IQpoQIqei4+hrxx4ZD2VYRrrP4k7fYVbKUd2c=; b=MaPbaTOq95kuFdCZZCCG5L7DynIHcOKaHduHg2dXHuraS73wghRv1LBdIJcQXml3 DP17zNckmqzDdlWJ5YYfGshRjo1wk9d35Iuw3WPD+Kh/a8GH3pqrXATUHgZyBTujw+Y as3BNlENifza8Rlsv9fnnt5Ac7tyqJnv3LJ/1zEk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1496523544; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=57PAa8IQpoQIqei4+hrxx4ZD2VYRrrP4k7fYVbKUd2c=; b=QHB307M/WEDBZ/2E9GotrsBBt+fbiRDnJsVsqEJscVsS+Rmw2TNtLIrMUwTI3wDV 9oMe3/gmJVeeGBG4QhSCjXqv84+JzOxfOrKrP1JNXKSTFX8ZxtuVjAOSOcFwG+azvdR zviXejiD8tboW8ZUfZ6W8SJDEsntk3K/40TItzj4= To: "freebsd-current@freebsd.org" From: Colin Percival Subject: Time to increase MAXPHYS? Message-ID: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> Date: Sat, 3 Jun 2017 20:59:04 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2017.06.03-54.240.8.176 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-Mailman-Approved-At: Sun, 04 Jun 2017 00:29:32 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 03 Jun 2017 20:59:11 -0000 On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ wrote: > Add better support for larger I/O clusters, including larger physical > I/O. The support is not mature yet, and some of the underlying implementation > needs help. However, support does exist for IDE devices now. and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it again, or do we need to wait at least two decades between changes? This is hurting performance on some systems; in particular, EC2 "io1" disks are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning rust) disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) recommends using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O it seems to still be limited by MAXPHYS). -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@freebsd.org Sun Jun 4 02:35:37 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C7FEAF89C7 for ; Sun, 4 Jun 2017 02:35:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D091513E3 for ; Sun, 4 Jun 2017 02:35:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (106-68-195-68.dyn.iinet.net.au [106.68.195.68]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v542ZUsF062285 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 3 Jun 2017 19:35:33 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: Time to increase MAXPHYS? To: Colin Percival , "freebsd-current@freebsd.org" References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> From: Julian Elischer Message-ID: <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> Date: Sun, 4 Jun 2017 10:35:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailman-Approved-At: Sun, 04 Jun 2017 03:50:38 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 02:35:37 -0000 On 4/6/17 4:59 am, Colin Percival wrote: > On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > wrote: >> Add better support for larger I/O clusters, including larger physical >> I/O. The support is not mature yet, and some of the underlying implementation >> needs help. However, support does exist for IDE devices now. > and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it again, > or do we need to wait at least two decades between changes? > > This is hurting performance on some systems; in particular, EC2 "io1" disks > are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning rust) > disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) recommends > using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O it > seems to still be limited by MAXPHYS). > We increase it in freebsd 8 and 10.3 on our systems, Only good results. sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O transfer size */ From owner-freebsd-current@freebsd.org Sun Jun 4 03:55:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD441AF9DB8 for ; Sun, 4 Jun 2017 03:55:58 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 8F5353BFF for ; Sun, 4 Jun 2017 03:55:58 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1AAFE13704 for ; Sun, 4 Jun 2017 03:55:55 +0000 (UTC) Subject: Re: Time to increase MAXPHYS? To: freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> From: Allan Jude Message-ID: <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> Date: Sat, 3 Jun 2017 23:55:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cx0stUMhFrq7XmDAEA141WXqMt1Densin" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 03:55:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cx0stUMhFrq7XmDAEA141WXqMt1Densin Content-Type: multipart/mixed; boundary="v8v1cFKcV5SNXqoRsNBIFD65mdBoUKUi4"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> Subject: Re: Time to increase MAXPHYS? References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> In-Reply-To: <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> --v8v1cFKcV5SNXqoRsNBIFD65mdBoUKUi4 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-06-03 22:35, Julian Elischer wrote: > On 4/6/17 4:59 am, Colin Percival wrote: >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson= @ >> wrote: >>> Add better support for larger I/O clusters, including larger physical= >>> I/O. The support is not mature yet, and some of the underlying >>> implementation >>> needs help. However, support does exist for IDE devices now. >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it= >> again, >> or do we need to wait at least two decades between changes? >> >> This is hurting performance on some systems; in particular, EC2 "io1" >> disks >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized >> spinning rust) >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) >> recommends >> using a maximum I/O size of 1 MB (and despite NFS not being *physical*= >> I/O it >> seems to still be limited by MAXPHYS). >> > We increase it in freebsd 8 and 10.3 on our systems, Only good results= =2E >=20 > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > transfer size */ >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" At some point Warner and I discussed how hard it might be to make this a boot time tunable, so that big amd64 machines can have a larger value without causing problems for smaller machines. ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some of the benefit. I am preparing some benchmarks and other data along with a patch to increase the maximum size of pipe I/O's as well, because using 1MB offers a relatively large performance gain there as well. --=20 Allan Jude --v8v1cFKcV5SNXqoRsNBIFD65mdBoUKUi4-- --Cx0stUMhFrq7XmDAEA141WXqMt1Densin 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) iQIcBAEBAgAGBQJZM4TKAAoJEBmVNT4SmAt++RsQAMESHM5nn7rA7FXik+B1c7b7 RIuGsZmvOwMJ+ByTnW+i5jd/oVEQMl488Jq0mrzNUcTNwesJzBHyLfZUk4tsCW2E nmj6o9E4t/EQJ+v/LwCVAxtdFuGDCFH4gQGeoH31XqXWA2qguAHdm8hCLE3lw7yv xnVUKIsH+B1XYrYtnugK4QQtiKuxvQg1m0iJGR8jQoRr1qqz41yBxc3ZsBIvRSsh 6lw6PHOQLMaxp8vLiMumFcCB4ubMaWuSA0xvzKjWfeFqqNIqH6yut5va9TVZLdHq yNlZz+Cu8ZBxnt+A+ndZtkaC0CvuTyrh9wkgGbF9wfuD83+Td5/LwIYbfqpNASGE 3dpNOIgiz/bpp+s7g9uqEiKnP1BWN7BEgouj/rJ74y1ItsVRljKr+ss4Mmxw12Rc 9J02M8aCYN1uTKDbLoT30FON8kbxzQliXZj6Co/CK1Lv6ngv9UBJKzfxeJ22j3Xz R014WqSfjQxmBCtXZBtYh5CLAmBtWV+9WD/RP4/8Ub0mcRhCgUvRlTE8EJ9b14ZW Scns5WEkFMV4kfNkW9vGmwAid6YM+Ka5xns7f4+88feXdd816Qq4lbkhkaCj76+i cUoCQMaCxZ2s8/IQkjilJZX+tNvKTlMbbr22n1ka05sLE+ajqE7SBXpX0AbIGW3P 02d/gYD1bQ59mDSDd54M =eW2j -----END PGP SIGNATURE----- --Cx0stUMhFrq7XmDAEA141WXqMt1Densin-- From owner-freebsd-current@freebsd.org Sun Jun 4 05:28:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A080CAFB2A3 for ; Sun, 4 Jun 2017 05:28:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 6ED9565C9B for ; Sun, 4 Jun 2017 05:28:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id m47so50273306iti.0 for ; Sat, 03 Jun 2017 22:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TLdBr3kokZOe9pNyrR4QlHpS4v1w/eh6jttYzattdwU=; b=cjSW11CNiu/Uxz0O77PNnqFehoaXRzNSE0OlISI6l89KtIkcNCw8I/H+Pm3BNgd6co gqrt2Koq5ZxlyXSm12SLeEq9oZlfPWTfAX5Udeoy7Xzo529sMW3DOgRfXf8ZtGIUlF0q TwhEYGJOPWmBI4e9jWvolhXfj86UnNXoKO9i9TWx2uXdQ1iaH/8NjvmjzC5xrkpbGgxn DjaYcGhsdIkDyGcz8z4fYLgfDnqDBhgyCMUl8itJrVMG7BZjuFdIE1pjg5nqHw9NIucF rUKwlL1kMPJQ6zyQ7A/aSLaHT/mrFKtW6GhzwNR26VCKrBxUJ6nnWidpF2qfrMi8IH/X oK2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TLdBr3kokZOe9pNyrR4QlHpS4v1w/eh6jttYzattdwU=; b=dd1BncLsB5bperPD9BxYoVDX842vQWYxte0vN4F1BBL3BWatjbJe2uIGtDkrGso4j6 Uqae4mrzq0xbgxT5XCaU9d/TeVsUYS942ZHGqfFca8zhsJKJxQR+M/knN2AZ/CRFAFPm KRy2YskxBI3zwbOQy+kRDBVcPJFew1I72Y7q/7Or1DSaKriGYeRS48guLUdXx64UU5T8 x7ZIS+Rt7kvRLayROFr0Dxe32M8ncKbl7p8a2sEVidgcq+XZTnyeujxslJnPzXV5pwTc SIWKjUOQZoD9NjLD6+xQmMhVnfh6gkgwjN9YtCdNZX7bnO9PPKmp8145J0MgkthGiGOI TrzA== X-Gm-Message-State: AODbwcCw896uLLf5e4ymfXXFBNPaOa/fFQWFcvoNbmkjAIxHlt9bnemT zC/gZCBLd6iTFrcEE63rWxrmVX0Rtyv3 X-Received: by 10.36.26.18 with SMTP id 18mr6579195iti.103.1496554103702; Sat, 03 Jun 2017 22:28:23 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Sat, 3 Jun 2017 22:28:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f916:f485:1733:1e28] In-Reply-To: <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> From: Warner Losh Date: Sat, 3 Jun 2017 23:28:23 -0600 X-Google-Sender-Auth: FPNfRUJwGf30eD8QqbMb86KfXRI Message-ID: Subject: Re: Time to increase MAXPHYS? To: Allan Jude Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 05:28:24 -0000 On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > On 2017-06-03 22:35, Julian Elischer wrote: > > On 4/6/17 4:59 am, Colin Percival wrote: > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > >> wrote: > >>> Add better support for larger I/O clusters, including larger physical > >>> I/O. The support is not mature yet, and some of the underlying > >>> implementation > >>> needs help. However, support does exist for IDE devices now. > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > >> again, > >> or do we need to wait at least two decades between changes? > >> > >> This is hurting performance on some systems; in particular, EC2 "io1" > >> disks > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > >> spinning rust) > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > >> recommends > >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > >> I/O it > >> seems to still be limited by MAXPHYS). > >> > > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > > transfer size */ > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > At some point Warner and I discussed how hard it might be to make this a > boot time tunable, so that big amd64 machines can have a larger value > without causing problems for smaller machines. > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > of the benefit. > > I am preparing some benchmarks and other data along with a patch to > increase the maximum size of pipe I/O's as well, because using 1MB > offers a relatively large performance gain there as well. > It doesn't look to be hard to change this, though struct buf depends on MAXPHYS: struct vm_page *b_pages[btoc(MAXPHYS)]; and b_pages isn't the last item in the list, so changing MAXPHYS at boot time would cause an ABI change. IMHO, we should move it to the last element so that wouldn't happen. IIRC all buf allocations are from a fixed pool. We'd have to audit anybody that creates one on the stack knowing it will be persisted. Given how things work, I don't think this is possible, so we may be safe. Thankfully, struct bio doesn't seem to be affected. As for making it boot-time configurable, it shouldn't be too horrible with the above change. We should have enough of the tunables mechanism up early enough to pull this in before we create the buf pool. Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be sure, especially on memory limited systems. Lots of hardware can't do this big an I/O, and some drivers can't cope, even if the underlying hardware can. Since we don't use such drivers at work, I don't have a list handy (though I think the SG list for NVMe limits it to 1MB). 128k is totally reasonable bump by default, but I think going larger by default should be approached with some caution given the overhead that adds to struct buf. Having it be a run-time tunable would be great. There's a number of places in userland that depend on MAXPHYS, which is unfortunate since they assume a fixed value and don't pick it up from the kernel or kernel config. Thankfully, there are only a limited number of these. Of course, there's times when I/Os can return much more than this. Reading drive log pages, for example, can generate tens or hundreds of MB of data, and there's no way to do that with one transaction today. If drive makers were perfect, we could use the generally defined offset and length fields to read them out piecemeal. If the log is table, a big if for some of the snapshots of internal state logs that are sometimes necessary to investigate problems... It sure would be nice if there were a way to have super-huge I/O on an exception basis for these situations. Warner From owner-freebsd-current@freebsd.org Sun Jun 4 05:33:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C209AFB4A8 for ; Sun, 4 Jun 2017 05:33:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 C64DF6604F for ; Sun, 4 Jun 2017 05:33:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id m47so37703819iti.1 for ; Sat, 03 Jun 2017 22:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lw7Sf7kStioLZapnkl+guNduk/1AW3T86bCsawK2Z9k=; b=rWNBY1OFgu8VqeYca9l4vy3x4cyfj1MDPoIels6kYPX3mr+tvxZJJ72hdswdgkhPn9 UK9T3p3wi+8iH2XhEsXTqHoQ0ORAz/j5jX2hqYhq9/6gbHk2c+i/XFTa0yXxqKxo4zvS aljx1Si3FQDbSh/HIywgtevVsmoOY64elvbe45KrdIRpawCOfeXrMHsRL9DBHCuF1tJi OItKwNuW/WlfVa7Zn8gEIq+rZEgXWaa6f8YHkpMRUPZv0pE8GIy/ydb+xcQDzuMfGKRC QUeUcfc73XhjatjCmORD0iU32wiXqUixQrpjpGzVcvDq1JQDhU4VSH/DEZsKzHx5ewhA PZ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lw7Sf7kStioLZapnkl+guNduk/1AW3T86bCsawK2Z9k=; b=Z5CeJJNLF4VRbcstfkEhn+nv6UwA+aIOEX3yKOgFzemdub4mMkUdCOlj1j2w388ftq t+UMJ/etWz/7f75YfJGSN38eIbeBuKWCMeTuxgsL18hJJ7kzIpZPyygbJPy3A8lcmiC1 sJ96tIXHyD1XdyY7RkRKswmYpEObxeWV9GqAtQUBb+5pX2AO0CCQp/FIH7QfAAJPT4pR vXiZB6tfVfIMNp/JFJx5EVtSGfM4NGxaKwx+65yXpmcweUW/TB5rIbKlu9WsBK8RslZt utkKpnLb9g8QzYNXEipumRkTlo5fVQeiTziZS9PsKHOxBV9Jt8YrBz8mlljy9drmImlk iFBQ== X-Gm-Message-State: AODbwcAdPgFciGnWbb5df3S4Xteu7XWFFgSBapaTnP9Tt5Nxiu8SeWHU PYRzrtHxg+sC7u4ovem/3PpY+FsS6sC3 X-Received: by 10.36.105.13 with SMTP id e13mr6175673itc.64.1496554383197; Sat, 03 Jun 2017 22:33:03 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Sat, 3 Jun 2017 22:33:02 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f916:f485:1733:1e28] In-Reply-To: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> From: Warner Losh Date: Sat, 3 Jun 2017 23:33:02 -0600 X-Google-Sender-Auth: ywZBp4ty4EJC6It94DhpWFyeWDc Message-ID: Subject: Re: Time to increase MAXPHYS? To: Colin Percival Cc: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 05:33:04 -0000 On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival wrote: > On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > wrote: > > Add better support for larger I/O clusters, including larger physical > > I/O. The support is not mature yet, and some of the underlying > implementation > > needs help. However, support does exist for IDE devices now. > > and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > again, > or do we need to wait at least two decades between changes? > > This is hurting performance on some systems; in particular, EC2 "io1" disks > are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning > rust) > disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > recommends > using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O > it > seems to still be limited by MAXPHYS). > MAXPHYS is the largest I/O transaction you can push through the system. It doesn't matter that the I/O is physical or not. The name is a relic from a time that NFS didn't exist. Warner From owner-freebsd-current@freebsd.org Sun Jun 4 05:49:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C34DAFB712 for ; Sun, 4 Jun 2017 05:49:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 2550B66522 for ; Sun, 4 Jun 2017 05:49:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id m47so37814158iti.1 for ; Sat, 03 Jun 2017 22:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SSz/a60fF0wnU8NeACG2PcPUgzcmJfmzuMhDIDE/Axs=; b=X5jIr8OPHTtKUAwYydzL+5M8CtQ4mhUbILQBvHYvQdeuMIywzYNwk8xV9m6MkgfVob FpTz1rcSO0Wgph7+y67kiFgL1IYgUM9hVRnBftnyxZOIBzdusV5hqWFEn86Jyx21RUCw kAbVP3dSwKqKvrxzBhngRICBA/4hlRnmAUIFE0b1uWf6fMMVOxmIx4/aDDIte1+jdgkf alhgefE4YBSgVaTIxz3CMIucRClahECgiEQ/Sfid2ENKMUB7v374k/r8qjMIvpaRQIXw TA+dHWGHhv3UKTy3969ORA8TYAYPM7R/Fkr4C26szXxfcBpkrHrBbmcqCg3gEbBEO/GZ N3jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SSz/a60fF0wnU8NeACG2PcPUgzcmJfmzuMhDIDE/Axs=; b=BDCOCBhMttpPm+IODt8zKyoS5DDRkjpxvGCqJHU7j8AR5B9b3UBlPfl8GLngP/UsXy uwYUQOBqbTAVSTlOEOza2zqd7pP0KLYJL3g90oGeiV0CkedfhYnAs/mrWdkSCrjMVdL8 MtFZ4M1x+ZVpvh9D01Igu30rPKtJA2ZH9vXG2SEV2txhDCZWnnEGCQ3tvtWOqiNRc4D4 dIPnSijeyw1SSUfYgjATX/xl+/rQipgUDsr9qu5GqwAqvXFg09S35Vow56A1h2cf6vkm /97QduMH7O088uM4yj2W694VKnzFE7ho1dug/WXvRYfSIf4MiBvjbu3AqOAh99rEidMm Nr1A== X-Gm-Message-State: AODbwcB5CfBk6MZMkE+a8+YEFvjiQEFKA6dlW5EbtrcRzDbNoivGDbCY 5l2Ct6Ibqj//wInGp+QIPzdcNDeBZ+Ub3T8= X-Received: by 10.107.16.217 with SMTP id 86mr10618991ioq.134.1496555342401; Sat, 03 Jun 2017 22:49:02 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Sat, 3 Jun 2017 22:49:01 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:f916:f485:1733:1e28] In-Reply-To: References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> From: Warner Losh Date: Sat, 3 Jun 2017 23:49:01 -0600 X-Google-Sender-Auth: -TnUnFKnNRHEzm_urDOfsj4CaT0 Message-ID: Subject: Re: Time to increase MAXPHYS? To: Allan Jude Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 05:49:03 -0000 On Sat, Jun 3, 2017 at 11:28 PM, Warner Losh wrote: > > > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > >> On 2017-06-03 22:35, Julian Elischer wrote: >> > On 4/6/17 4:59 am, Colin Percival wrote: >> >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ >> >> wrote: >> >>> Add better support for larger I/O clusters, including larger physical >> >>> I/O. The support is not mature yet, and some of the underlying >> >>> implementation >> >>> needs help. However, support does exist for IDE devices now. >> >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it >> >> again, >> >> or do we need to wait at least two decades between changes? >> >> >> >> This is hurting performance on some systems; in particular, EC2 "io1" >> >> disks >> >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized >> >> spinning rust) >> >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) >> >> recommends >> >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* >> >> I/O it >> >> seems to still be limited by MAXPHYS). >> >> >> > We increase it in freebsd 8 and 10.3 on our systems, Only good results. >> > >> > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O >> > transfer size */ >> > >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >> reebsd.org" >> >> At some point Warner and I discussed how hard it might be to make this a >> boot time tunable, so that big amd64 machines can have a larger value >> without causing problems for smaller machines. >> >> ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some >> of the benefit. >> >> I am preparing some benchmarks and other data along with a patch to >> increase the maximum size of pipe I/O's as well, because using 1MB >> offers a relatively large performance gain there as well. >> > > It doesn't look to be hard to change this, though struct buf depends on > MAXPHYS: > struct vm_page *b_pages[btoc(MAXPHYS)]; > and b_pages isn't the last item in the list, so changing MAXPHYS at boot > time would cause an ABI change. IMHO, we should move it to the last element > so that wouldn't happen. IIRC all buf allocations are from a fixed pool. > We'd have to audit anybody that creates one on the stack knowing it will be > persisted. Given how things work, I don't think this is possible, so we may > be safe. Thankfully, struct bio doesn't seem to be affected. > > As for making it boot-time configurable, it shouldn't be too horrible with > the above change. We should have enough of the tunables mechanism up early > enough to pull this in before we create the buf pool. > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > sure, especially on memory limited systems. Lots of hardware can't do this > big an I/O, and some drivers can't cope, even if the underlying hardware > can. Since we don't use such drivers at work, I don't have a list handy > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > reasonable bump by default, but I think going larger by default should be > approached with some caution given the overhead that adds to struct buf. > Having it be a run-time tunable would be great. > Of course 128k is reasonable, it's the current default :). I'd mean to say that doubling would have a limited impact. 1MB might be a good default, but it might be too big for smaller systems (nothing says it has to be a MI constant, though). It would be a perfectly fine default if it were a tunable. > There's a number of places in userland that depend on MAXPHYS, which is > unfortunate since they assume a fixed value and don't pick it up from the > kernel or kernel config. Thankfully, there are only a limited number of > these. > There's a number of other places that assume MAXPHYS is constant. The ahci driver uses it to define the max number of SG operations you can have, for example. aio has an array sized based off of it. There are some places that use this when they should use 128k instead. There's several places that use it to define other constants, and it would take a while to run them all to ground to make sure they are all good. We might need to bump DFLTPHYS as well, so it might also make a good tunable. There's a few places that check things in terms of a fixed multiple of MAXPHYS that are rules of thumb that kinda work today maybe by accident or maybe the 100 * MAXPHYS is highly scientific. It's hard to say without careful study. For example, until recently, nvmecontrol would use MAXPHYS. But it's the system default MAXPHYS. And even if it isn't, there's currently a hard limit of 1MB for an I/O imposed by how the driver uses nvme's SG lists. But it doesn't show up as MAXPHYS, but rather as NVME_MAX_XFER_SIZE in places. It totally surprised me when I hit this problem at runtime and tracked it to ground. > Of course, there's times when I/Os can return much more than this. Reading > drive log pages, for example, can generate tens or hundreds of MB of data, > and there's no way to do that with one transaction today. If drive makers > were perfect, we could use the generally defined offset and length fields > to read them out piecemeal. If the log is table, a big if for some of the > snapshots of internal state logs that are sometimes necessary to > investigate problems... It sure would be nice if there were a way to have > super-huge I/O on an exception basis for these situations. > The hardest part about doing this is chasing down all the references since it winds up in the craziest of places. Warner From owner-freebsd-current@freebsd.org Sun Jun 4 07:04:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDF48AFC58F for ; Sun, 4 Jun 2017 07:04:12 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 91C1E680D3 for ; Sun, 4 Jun 2017 07:04:12 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x229.google.com with SMTP id m17so69372100pfg.3 for ; Sun, 04 Jun 2017 00:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1zzJyFvGnT97MvkaZTfP5EWBFKxcgf8H3NmaxXFqc/M=; b=J9QOS05VZo+wpGaDwjEai5cvW1v69JvxYMpS5ypmruESpfQex5nVBf1fSzFCIvbukI UhmgIMkH9n3cpeKrXDHcpRrsw8OXSHrYtXeLqVdIoqJfapQKctyYoXLAQZr36+lbhbDu oiWnygdBiTlPtXZWUNA3p930ZdEh96cEkQV2lw5U45m0qPUCuTkrGUWIw2LvDRw1F/o7 AMC6hI2ZmGCRUVRnYBmHEQhZL7VRq44JIFclejN2L0hF1EnuxlcLKjtwjw8pnVaJDidD P1NABdavECEQ2ttHFBQQXAZcjjv7zbTFpJFKghYxm/AKTKAz7COHnwLZ8AWwVJ36C6Cz 53Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1zzJyFvGnT97MvkaZTfP5EWBFKxcgf8H3NmaxXFqc/M=; b=QwjOl+LOQNTsy9qjvGdc1ZZVqBlxn/OCx/tsyPmjlFE6eWQqQCrrVk4sKgta950Jpc IX4pPzquBLfutWPud9xtC/E9poyethJ0fPhWQt185W+kUPFcyPoIWvYm8CkWFtXrwAvR ELQRFpeSPD8AgHExdnFvvOhN7HottPZ49aP1PXhr1ytN9oW07bjvlFbep78jtbdxmv74 jOZFa7/C9T+TrXC00Tt+d1vAfgwDMcnXWzMW9B+FbkWW4H8BHmFSNLRBJyKcaNA5XAKG 67oSYvVPwaApJ+6flCLAj/t/jzQtwQckd4teLwywkxc4BjVK6z932Szmt6wsK6obk0Qe gDxw== X-Gm-Message-State: AODbwcBIQlYnEkQqlOqaq+SJc5k7Y0Rptvlhno9gAfUWOzLpqX+ld2/H vRLxdb+vsabGCQzjeseiYT1w7OXHDQ== X-Received: by 10.98.93.217 with SMTP id n86mr14627375pfj.113.1496559851977; Sun, 04 Jun 2017 00:04:11 -0700 (PDT) MIME-Version: 1.0 References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> In-Reply-To: <1100140349.1166835.1496498112171@mail.yahoo.com> From: blubee blubeeme Date: Sun, 04 Jun 2017 07:04:01 +0000 Message-ID: Subject: Re: nvidia drivers mutex lock To: Jeffrey Bouquet , freebsd-current@freebsd.org, Tomoaki AOKI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 07:04:12 -0000 Hi @tomoaki Is that version of nvidia drivers currently in the ports tree? I just checked but it seems not to be. @jeffrey I just generated a new xorg based on the force composition setting. I merged it with my previous xorg I'll reboot, see if it gives better performance. It seems like my system is locking up more frequently now. Sometimes right after a reboot the system, the screen locks and it's reboot and pray. Best, Owen On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet wrote= : > SOME LINES BOTTOM POSTED, SEE... > -------------------------------------------- > On Fri, 6/2/17, Tomoaki AOKI wrote: > > Subject: Re: nvidia drivers mutex lock > To: freebsd-current@freebsd.org > Cc: "Jeffrey Bouquet" , "blubee blubeeme" < > gurenchan@gmail.com> > Date: Friday, June 2, 2017, 11:25 PM > > Hi. > Version > 381.22 (5 days newer than 375.66) of the driver states... > [1] > > Fixed hangs and > crashes that could occur when an OpenGL context is > created while the system is out of available > memory. > > Can this be related > with your hang? > > IMHO, > possibly allocating new resource (using os.lock_mtx > guard) > without checking the lock first while > previous request is waiting for > another can > cause the duplicated lock situation. And high memory > pressure would easily cause the situation. > > [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us > > Hope it helps. > > > On Thu, 1 Jun > 2017 22:35:46 +0000 (UTC) > Jeffrey Bouquet > > wrote: > > > I see the same > message, upon load, ... > > > -------------------------------------------- > > On Thu, 6/1/17, blubee blubeeme > wrote: > > > > Subject: > nvidia drivers mutex lock > > To: freebsd-ports@freebsd.org, > freebsd-current@freebsd.org > > Date: Thursday, June 1, 2017, 11:35 > AM > > > > I'm > running nvidia-drivers 375.66 with a GTX > > 1070 on FreeBSD-Current > > > > This problem > just started happening > > recently but, > every so often my laptop > > screen will > just blank out and then I > > have to > power cycle to get the > > machine up and > running again. > > > > It seems to be a problem with nvidia > > drivers acquiring duplicate lock. Any > > info on this? > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: > > acquiring duplicate lock of same > type: > > "os.lock_mtx" > > Jun=E3=80=93 2 02:29:41 blubee kernel: 1st > > os.lock_mtx @ nvidia_os.c:841 > > Jun=E3=80=93 2 02:29:41 blubee kernel: 2nd > > os.lock_mtx @ nvidia_os.c:841 > > Jun=E3=80=93 2 02:29:41 blubee kernel: > > stack backtrace: > > > Jun=E3=80=93 2 02:29:41 blubee kernel: #0 > > > 0xffffffff80ab7770 at > > > witness_debugger+0x70 > > Jun=E3=80=93 2 > 02:29:41 blubee kernel: #1 > > > 0xffffffff80ab7663 at > > > witness_checkorder+0xe23 > > Jun=E3=80=93 2 > 02:29:41 blubee kernel: #2 > > > 0xffffffff80a35b93 at > > > __mtx_lock_flags+0x93 > > Jun=E3=80=93 2 > 02:29:41 blubee kernel: #3 > > > 0xffffffff82f4397b at > > > os_acquire_spinlock+0x1b > > Jun=E3=80=93 2 > 02:29:41 blubee kernel: #4 > > > 0xffffffff82c48b15 at _nv012002rm+0x185 > > Jun=E3=80=93 2 02:29:41 blubee kernel: > > ACPI Warning: > \_SB.PCI0.PEG0.PEGP._DSM: > > Argument #4 > type mismatch - Found > > [Buffer], ACPI > requires [Package] > > > (20170303/nsarguments-205) > > Jun=E3=80=93 2 > 02:29:42 blubee kernel: > > > nvidia-modeset: Allocated GPU:0 > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > > PCI:0000:01:00.0 > > > > > Best, > > Owen > > > _______________________________________________ > > freebsd-ports@freebsd.org > > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to > "freebsd-ports-unsubscribe@freebsd.org" > > > > > > > > ... then Xorg will > run happily twelve hours or so. The lockups here happen > usually > > when too large or too many of > number of tabs/ large web pages with complex CSS etc > > are opened at a time. > > So no help, just a 'me > too'. > > > _______________________________________________ > > freebsd-current@freebsd.org > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g > " > > > > > > > -- > Tomoaki > AOKI > > > > ........................ > might be a workaround > Xorg/nvidia ran all night with this: > nvidia-settings >> X server display configuration >> Advanced >> Forc= e > Full Composition Pipeline > ... for the laptop freezing. Could not hurt to try. " merge with > Xorg.conf " from nvidia-settings... > ...................... > 18 hours uptime so far, even past > the 3 am periodic scripts. Have not rebooted out of the Xorg though so > may require edit-out of > xorg.conf if that is the case, in other words differing from real-time > apply and > xorg initially start applies. > ........ > > From owner-freebsd-current@freebsd.org Sun Jun 4 07:15:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9647FAFC77D for ; Sun, 4 Jun 2017 07:15:17 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 5A5A16848A; Sun, 4 Jun 2017 07:15:17 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id n23so17177745pfb.3; Sun, 04 Jun 2017 00:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cva7Ceb/inCW0m+65QJQgEYyyD3mpHMFOp758TMZxFI=; b=r9I3cx4hkgklPSquyv3XmZL0k3u+H+aN9XGYCzkezYWummFp4Hs1cHStreu7bmHPGV 3IsuUYAkuPrD6sffa7GOi+1PiyvC/JvCVTSiZVrLsi2+N6qTFEcfCiye3CIrdLYRlpg3 VfqXXGcc/68v4YhaE3K+o5UuQyADIOaGscK51tgJ2kNqd1QdquVam4nO4RWcbQaOBsJM tJxvdKh6S0xdZcqkBD+sXtdYm8CX1pNoq5FMv4ZmdcgrVnMnp88FSOUZ1hybEsbzLScX 6hKP5yUjTaHziI3dGfHI2nadthaHJTV7PP3nBvb8bhY7eOciKm9j793WJm3EqS6dE7EY BxqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cva7Ceb/inCW0m+65QJQgEYyyD3mpHMFOp758TMZxFI=; b=g9ugf5bOyx00atvK3YwE9RnM3lg+R4HuvWhQPJzhQOKOYZV32KhiI822V3tkar4/gt nG7pnZkE51SVyKujmtZV+l3yhytC75LtUKMB4yEgHh6nBiNaqhNfwbvSykeSaUawWmM3 iPRdGHI10uSIxZMyb0/y89Sx3QK/18f8VtdxiOfsv8euivNa26PeFdIxOlEL05m924HT 41AfT/TaDx47Pn98jlD9yjz4hD51mIn+dA7lSw76ec2RQGOqKPa1HBUJ7TrVaKqi1ob7 8yc1tor1dCtvtQ1Xov4DAsjMAtiIKJSXLsL6YJka9yHuWBEN2wnxRFKMP2LkVkqVR5DY BB0A== X-Gm-Message-State: AODbwcCiNYrqkXPAZ7YMmd4Z5WfoPtXUZaIUpc5BVuHtitdImh+0+4Ng gDp4/KMjnu9PEI+cVW9yqIZw3ec7jQ== X-Received: by 10.98.163.25 with SMTP id s25mr14152879pfe.217.1496560516881; Sun, 04 Jun 2017 00:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.79 with HTTP; Sun, 4 Jun 2017 00:15:16 -0700 (PDT) In-Reply-To: <3348A21B-754F-41FE-A94D-C3F53AD691C8@kientzle.com> References: <3348A21B-754F-41FE-A94D-C3F53AD691C8@kientzle.com> From: blubee blubeeme Date: Sun, 4 Jun 2017 15:15:16 +0800 Message-ID: Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT To: Tim Kientzle Cc: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 07:15:17 -0000 thanks for the two great pieces of advice. Best, Owen On Sat, Jun 3, 2017 at 2:26 PM, Tim Kientzle wrote: > > > On Jun 1, 2017, at 11:37 PM, Jean-S=C3=A9bastien P=C3=A9dron > wrote: > > > > On 28.05.2017 19:21, blubee blubeeme wrote: > >> =3D=3D=3D> Building for rust-1.17.0 > >> ... > >> extracting > >> rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_ > 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0= / > librustc_llvm-74a1be1110b5d4d0.so > >> gmake[7]: Leaving directory '/usr/ports/lang/rust/work/ > rustc-1.17.0-src' > >> *** Error code 1 > > > > Hi! > > > > This failure is caused by Python 2's tarfile module not supporting > > sparse files in archives. Python 3 supports them but the configure > > script insists on using Python 2. > > > > Before a proper fix is committed, you can change the following line in > > lang/rust/Makefile: > > https://github.com/freebsd/freebsd-ports/blob/master/ > lang/rust/Makefile#L159 > > > > to say (this is a single line): > > gtar -c -C ${WRKSRC} -f - > > rust-std-1.16.0-${RUST_ARCH_${ARCH}}-unknown-freebsd | gzip > > > ${WRKSRC}/rustc.tbz > > You could add --format=3Dustar to the existing command line; that would > force bsdtar to use the older "ustar" format (without any extensions that > might confuse Python's tar file module). > > > > Then, change the following line: > > https://github.com/freebsd/freebsd-ports/blob/master/ > lang/rust/Makefile#L34 > > > > to say: > > BUILD_DEPENDS=3D cmake:devel/cmake \ > > gtar:archivers/gtar > > > > This will use GNU tar instead of BSD tar to recreate the bootstrap and > > GNU tar doesn't seem to produce sparse file entries in the archive. > > How ironic; using GNU tar in order to avoid having GNU sparse file > entries. ;-) > > Tim > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Jun 4 07:39:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 162FFAFCB38 for ; Sun, 4 Jun 2017 07:39:57 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 CA22968C2A for ; Sun, 4 Jun 2017 07:39:56 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v547dm8K031881 for ; Sun, 4 Jun 2017 16:39:48 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 4 Jun 2017 16:39:48 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-Id: <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> In-Reply-To: References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 07:39:57 -0000 Hi One possibility would be to make it MD build-time OTIONS, defaulting 1M on regular systems and 128k on smaller systems. Of course I guess making it a tunable (or sysctl) would be best, though. On Sat, 3 Jun 2017 23:49:01 -0600 Warner Losh wrote: > On Sat, Jun 3, 2017 at 11:28 PM, Warner Losh wrote: > > > > > > > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > > > >> On 2017-06-03 22:35, Julian Elischer wrote: > >> > On 4/6/17 4:59 am, Colin Percival wrote: > >> >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > >> >> wrote: > >> >>> Add better support for larger I/O clusters, including larger physical > >> >>> I/O. The support is not mature yet, and some of the underlying > >> >>> implementation > >> >>> needs help. However, support does exist for IDE devices now. > >> >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > >> >> again, > >> >> or do we need to wait at least two decades between changes? > >> >> > >> >> This is hurting performance on some systems; in particular, EC2 "io1" > >> >> disks > >> >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > >> >> spinning rust) > >> >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > >> >> recommends > >> >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > >> >> I/O it > >> >> seems to still be limited by MAXPHYS). > >> >> > >> > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > >> > > >> > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > >> > transfer size */ > >> > > >> > _______________________________________________ > >> > freebsd-current@freebsd.org mailing list > >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f > >> reebsd.org" > >> > >> At some point Warner and I discussed how hard it might be to make this a > >> boot time tunable, so that big amd64 machines can have a larger value > >> without causing problems for smaller machines. > >> > >> ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > >> of the benefit. > >> > >> I am preparing some benchmarks and other data along with a patch to > >> increase the maximum size of pipe I/O's as well, because using 1MB > >> offers a relatively large performance gain there as well. > >> > > > > It doesn't look to be hard to change this, though struct buf depends on > > MAXPHYS: > > struct vm_page *b_pages[btoc(MAXPHYS)]; > > and b_pages isn't the last item in the list, so changing MAXPHYS at boot > > time would cause an ABI change. IMHO, we should move it to the last element > > so that wouldn't happen. IIRC all buf allocations are from a fixed pool. > > We'd have to audit anybody that creates one on the stack knowing it will be > > persisted. Given how things work, I don't think this is possible, so we may > > be safe. Thankfully, struct bio doesn't seem to be affected. > > > > As for making it boot-time configurable, it shouldn't be too horrible with > > the above change. We should have enough of the tunables mechanism up early > > enough to pull this in before we create the buf pool. > > > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > > sure, especially on memory limited systems. Lots of hardware can't do this > > big an I/O, and some drivers can't cope, even if the underlying hardware > > can. Since we don't use such drivers at work, I don't have a list handy > > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > > reasonable bump by default, but I think going larger by default should be > > approached with some caution given the overhead that adds to struct buf. > > Having it be a run-time tunable would be great. > > > > Of course 128k is reasonable, it's the current default :). I'd mean to say > that doubling would have a limited impact. 1MB might be a good default, but > it might be too big for smaller systems (nothing says it has to be a MI > constant, though). It would be a perfectly fine default if it were a > tunable. > > > > There's a number of places in userland that depend on MAXPHYS, which is > > unfortunate since they assume a fixed value and don't pick it up from the > > kernel or kernel config. Thankfully, there are only a limited number of > > these. > > > > There's a number of other places that assume MAXPHYS is constant. The ahci > driver uses it to define the max number of SG operations you can have, for > example. aio has an array sized based off of it. There are some places that > use this when they should use 128k instead. There's several places that use > it to define other constants, and it would take a while to run them all to > ground to make sure they are all good. We might need to bump DFLTPHYS as > well, so it might also make a good tunable. There's a few places that check > things in terms of a fixed multiple of MAXPHYS that are rules of thumb that > kinda work today maybe by accident or maybe the 100 * MAXPHYS is highly > scientific. It's hard to say without careful study. > > For example, until recently, nvmecontrol would use MAXPHYS. But it's the > system default MAXPHYS. And even if it isn't, there's currently a hard > limit of 1MB for an I/O imposed by how the driver uses nvme's SG lists. But > it doesn't show up as MAXPHYS, but rather as NVME_MAX_XFER_SIZE in places. > It totally surprised me when I hit this problem at runtime and tracked it > to ground. > > > > Of course, there's times when I/Os can return much more than this. Reading > > drive log pages, for example, can generate tens or hundreds of MB of data, > > and there's no way to do that with one transaction today. If drive makers > > were perfect, we could use the generally defined offset and length fields > > to read them out piecemeal. If the log is table, a big if for some of the > > snapshots of internal state logs that are sometimes necessary to > > investigate problems... It sure would be nice if there were a way to have > > super-huge I/O on an exception basis for these situations. > > > > The hardest part about doing this is chasing down all the references since > it winds up in the craziest of places. > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Jun 4 07:53:23 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4ACEAFD05B for ; Sun, 4 Jun 2017 07:53:23 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 B0E256A32E for ; Sun, 4 Jun 2017 07:53:23 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v547rK0m032033; Sun, 4 Jun 2017 16:53:21 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 4 Jun 2017 16:53:20 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: blubee blubeeme Subject: Re: nvidia drivers mutex lock Message-Id: <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> In-Reply-To: References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 07:53:24 -0000 Hi. Not in ports tree, but easily overridden by adding DISTVERSION=381.22 -DNO_CHECKSUM on make command line. Makefile of x11/nvidia-driver has a mechanism to do so for someone requires newer version (newer GPU support, etc.). If you're using portupgrade, portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f x11/nvidia-driver would do the same. If you installed it via pkg, there's no way to try. :-( (As it's pre-built.) On Sun, 04 Jun 2017 07:04:01 +0000 blubee blubeeme wrote: > Hi @tomoaki > Is that version of nvidia drivers currently in the ports tree? I just > checked but it seems not to be. > > @jeffrey > I just generated a new xorg based on the force composition setting. I > merged it with my previous xorg I'll reboot, see if it gives better > performance. > > It seems like my system is locking up more frequently now. Sometimes right > after a reboot the system, the screen locks and it's reboot and pray. > > Best, > Owen > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet wrote: > > > SOME LINES BOTTOM POSTED, SEE... > > -------------------------------------------- > > On Fri, 6/2/17, Tomoaki AOKI wrote: > > > > Subject: Re: nvidia drivers mutex lock > > To: freebsd-current@freebsd.org > > Cc: "Jeffrey Bouquet" , "blubee blubeeme" < > > gurenchan@gmail.com> > > Date: Friday, June 2, 2017, 11:25 PM > > > > Hi. > > Version > > 381.22 (5 days newer than 375.66) of the driver states... > > [1] > > > > Fixed hangs and > > crashes that could occur when an OpenGL context is > > created while the system is out of available > > memory. > > > > Can this be related > > with your hang? > > > > IMHO, > > possibly allocating new resource (using os.lock_mtx > > guard) > > without checking the lock first while > > previous request is waiting for > > another can > > cause the duplicated lock situation. And high memory > > pressure would easily cause the situation. > > > > [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us > > > > Hope it helps. > > > > > > On Thu, 1 Jun > > 2017 22:35:46 +0000 (UTC) > > Jeffrey Bouquet > > > > wrote: > > > > > I see the same > > message, upon load, ... > > > > > -------------------------------------------- > > > On Thu, 6/1/17, blubee blubeeme > > wrote: > > > > > > Subject: > > nvidia drivers mutex lock > > > To: freebsd-ports@freebsd.org, > > freebsd-current@freebsd.org > > > Date: Thursday, June 1, 2017, 11:35 > > AM > > > > > > I'm > > running nvidia-drivers 375.66 with a GTX > > > 1070 on FreeBSD-Current > > > > > > This problem > > just started happening > > > recently but, > > every so often my laptop > > > screen will > > just blank out and then I > > > have to > > power cycle to get the > > > machine up and > > running again. > > > > > > It seems to be a problem with nvidia > > > drivers acquiring duplicate lock. Any > > > info on this? > > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > > > acquiring duplicate lock of same > > type: > > > "os.lock_mtx" > > > Jun$B".(B 2 02:29:41 blubee kernel: 1st > > > os.lock_mtx @ nvidia_os.c:841 > > > Jun$B".(B 2 02:29:41 blubee kernel: 2nd > > > os.lock_mtx @ nvidia_os.c:841 > > > Jun$B".(B 2 02:29:41 blubee kernel: > > > stack backtrace: > > > > > Jun$B".(B 2 02:29:41 blubee kernel: #0 > > > > > 0xffffffff80ab7770 at > > > > > witness_debugger+0x70 > > > Jun$B".(B 2 > > 02:29:41 blubee kernel: #1 > > > > > 0xffffffff80ab7663 at > > > > > witness_checkorder+0xe23 > > > Jun$B".(B 2 > > 02:29:41 blubee kernel: #2 > > > > > 0xffffffff80a35b93 at > > > > > __mtx_lock_flags+0x93 > > > Jun$B".(B 2 > > 02:29:41 blubee kernel: #3 > > > > > 0xffffffff82f4397b at > > > > > os_acquire_spinlock+0x1b > > > Jun$B".(B 2 > > 02:29:41 blubee kernel: #4 > > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 > > > Jun$B".(B 2 02:29:41 blubee kernel: > > > ACPI Warning: > > \_SB.PCI0.PEG0.PEGP._DSM: > > > Argument #4 > > type mismatch - Found > > > [Buffer], ACPI > > requires [Package] > > > > > (20170303/nsarguments-205) > > > Jun$B".(B 2 > > 02:29:42 blubee kernel: > > > > > nvidia-modeset: Allocated GPU:0 > > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > > > PCI:0000:01:00.0 > > > > > > > > Best, > > > Owen > > > > > _______________________________________________ > > > freebsd-ports@freebsd.org > > > mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > To unsubscribe, send any mail to > > "freebsd-ports-unsubscribe@freebsd.org" > > > > > > > > > > > > ... then Xorg will > > run happily twelve hours or so. The lockups here happen > > usually > > > when too large or too many of > > number of tabs/ large web pages with complex CSS etc > > > are opened at a time. > > > So no help, just a 'me > > too'. > > > > > _______________________________________________ > > > freebsd-current@freebsd.org > > mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > > " > > > > > > > > > > > > -- > > Tomoaki > > AOKI > > > > > > > > ........................ > > might be a workaround > > Xorg/nvidia ran all night with this: > > nvidia-settings >> X server display configuration >> Advanced >> Force > > Full Composition Pipeline > > ... for the laptop freezing. Could not hurt to try. " merge with > > Xorg.conf " from nvidia-settings... > > ...................... > > 18 hours uptime so far, even past > > the 3 am periodic scripts. Have not rebooted out of the Xorg though so > > may require edit-out of > > xorg.conf if that is the case, in other words differing from real-time > > apply and > > xorg initially start applies. > > ........ > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Jun 4 07:54:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16EF9AFD127 for ; Sun, 4 Jun 2017 07:54:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 D1F396A477 for ; Sun, 4 Jun 2017 07:54:48 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 A235D260873; Sun, 4 Jun 2017 09:54:39 +0200 (CEST) Subject: Re: Time to increase MAXPHYS? To: Tomoaki AOKI , freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> From: Hans Petter Selasky Message-ID: <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> Date: Sun, 4 Jun 2017 09:52:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 07:54:50 -0000 On 06/04/17 09:39, Tomoaki AOKI wrote: > Hi > > One possibility would be to make it MD build-time OTIONS, > defaulting 1M on regular systems and 128k on smaller systems. > > Of course I guess making it a tunable (or sysctl) would be best, > though. > Hi, A tunable sysctl would be fine, but beware that commonly used firmware out there produced in the millions might hang in a non-recoverable way if you exceed their "internal limits". Conditionally lowering this definition is fine, but increasing it needs to be carefully verified. For example many USB devices are only tested with OS'es like Windows and MacOS and if these have any kind of limitation on the SCSI transfer sizes, it is very likely many devices out there do not support any larger transfer sizes either. --HPS From owner-freebsd-current@freebsd.org Sun Jun 4 08:10:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EB5BAFD55E for ; Sun, 4 Jun 2017 08:10:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 C886B6A9E2; Sun, 4 Jun 2017 08:10:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v548AWCR029995 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 Jun 2017 11:10:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v548AWCR029995 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v548AWCe029994; Sun, 4 Jun 2017 11:10:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Jun 2017 11:10:32 +0300 From: Konstantin Belousov To: Warner Losh Cc: Allan Jude , FreeBSD Current Subject: Re: Time to increase MAXPHYS? Message-ID: <20170604081032.GN82323@kib.kiev.ua> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) 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.23 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, 04 Jun 2017 08:10:42 -0000 On Sat, Jun 03, 2017 at 11:28:23PM -0600, Warner Losh wrote: > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > > > On 2017-06-03 22:35, Julian Elischer wrote: > > > On 4/6/17 4:59 am, Colin Percival wrote: > > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > > >> wrote: > > >>> Add better support for larger I/O clusters, including larger physical > > >>> I/O. The support is not mature yet, and some of the underlying > > >>> implementation > > >>> needs help. However, support does exist for IDE devices now. > > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > > >> again, > > >> or do we need to wait at least two decades between changes? > > >> > > >> This is hurting performance on some systems; in particular, EC2 "io1" > > >> disks > > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > > >> spinning rust) > > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > > >> recommends > > >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > > >> I/O it > > >> seems to still be limited by MAXPHYS). > > >> > > > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > > > transfer size */ > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > freebsd.org" > > > > At some point Warner and I discussed how hard it might be to make this a > > boot time tunable, so that big amd64 machines can have a larger value > > without causing problems for smaller machines. > > > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > > of the benefit. > > > > I am preparing some benchmarks and other data along with a patch to > > increase the maximum size of pipe I/O's as well, because using 1MB > > offers a relatively large performance gain there as well. > > > > It doesn't look to be hard to change this, though struct buf depends on > MAXPHYS: > struct vm_page *b_pages[btoc(MAXPHYS)]; > and b_pages isn't the last item in the list, so changing MAXPHYS at boot > time would cause an ABI change. IMHO, we should move it to the last element > so that wouldn't happen. IIRC all buf allocations are from a fixed pool. > We'd have to audit anybody that creates one on the stack knowing it will be > persisted. Given how things work, I don't think this is possible, so we may > be safe. Thankfully, struct bio doesn't seem to be affected. > > As for making it boot-time configurable, it shouldn't be too horrible with > the above change. We should have enough of the tunables mechanism up early > enough to pull this in before we create the buf pool. > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > sure, especially on memory limited systems. Lots of hardware can't do this > big an I/O, and some drivers can't cope, even if the underlying hardware > can. Since we don't use such drivers at work, I don't have a list handy > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > reasonable bump by default, but I think going larger by default should be > approached with some caution given the overhead that adds to struct buf. > Having it be a run-time tunable would be great. The most important side-effect of bumping MAXPHYS as high as you did, which is somewhat counter-intuitive and also probably does not matter for typical Netflix cache box load (as I understand it) is increase of fragmentation for UFS volumes. MAXPHYS limits the max cluster size, and larger the cluster we trying to build, larger is the probability of failure. We might end with single-block writes more often, defeating reallocblk defragmenter. This might be somewhat theoretical, and probably can be mitigated in the clustering code if real, but it is a thing to look at. WRT making the MAXPHYS tunable, I do not like the proposal of converting b_pages[] into the flexible array. I think that making b_pages a pointer to off-structure page run is better. One of the reason is that buf cache buffers are not only buffers in the system. There are several cases where the buffers are malloced, like markers for iterating queues. In this case, b_pages[] can be eliminated at all. (I believe I changed all local struct bufs to be allocated with malloc). Another non-struct buf supply of buffers are phys buffers pool, see vm/vm_pager.c. > > There's a number of places in userland that depend on MAXPHYS, which is > unfortunate since they assume a fixed value and don't pick it up from the > kernel or kernel config. Thankfully, there are only a limited number of > these. > > Of course, there's times when I/Os can return much more than this. Reading > drive log pages, for example, can generate tens or hundreds of MB of data, > and there's no way to do that with one transaction today. If drive makers > were perfect, we could use the generally defined offset and length fields > to read them out piecemeal. If the log is table, a big if for some of the > snapshots of internal state logs that are sometimes necessary to > investigate problems... It sure would be nice if there were a way to have > super-huge I/O on an exception basis for these situations. From owner-freebsd-current@freebsd.org Sun Jun 4 08:50:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D702AFE258 for ; Sun, 4 Jun 2017 08:50:50 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 CF6106F41C for ; Sun, 4 Jun 2017 08:50:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v548olJS032868; Sun, 4 Jun 2017 17:50:48 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 4 Jun 2017 17:50:46 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: Hans Petter Selasky Subject: Re: Time to increase MAXPHYS? Message-Id: <20170604175046.f2a9d0f68ce5abefa7c2ac2a@dec.sakura.ne.jp> In-Reply-To: <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 08:50:50 -0000 On Sun, 4 Jun 2017 09:52:36 +0200 Hans Petter Selasky wrote: > On 06/04/17 09:39, Tomoaki AOKI wrote: > > Hi > > > > One possibility would be to make it MD build-time OTIONS, > > defaulting 1M on regular systems and 128k on smaller systems. > > > > Of course I guess making it a tunable (or sysctl) would be best, > > though. > > > > Hi, > > A tunable sysctl would be fine, but beware that commonly used firmware > out there produced in the millions might hang in a non-recoverable way > if you exceed their "internal limits". Conditionally lowering this > definition is fine, but increasing it needs to be carefully verified. > > For example many USB devices are only tested with OS'es like Windows and > MacOS and if these have any kind of limitation on the SCSI transfer > sizes, it is very likely many devices out there do not support any > larger transfer sizes either. > > --HPS Hmm, so making it tunable (or sysctl) as Warner noted would allow drivers to use quirks to workaround, i.e., QUIRKS_MAXPHYS_128K. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Jun 4 08:59:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE3BAAFE499 for ; Sun, 4 Jun 2017 08:59:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 62E206F7CC for ; Sun, 4 Jun 2017 08:59:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v548xBt6032978; Sun, 4 Jun 2017 17:59:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 4 Jun 2017 17:59:11 +0900 From: Tomoaki AOKI To: blubee blubeeme Cc: freebsd-current@freebsd.org Subject: Re: nvidia drivers mutex lock Message-Id: <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> In-Reply-To: References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 08:59:14 -0000 Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. But beware! Sometimes upstream changes make any of FreeBSD patches not applicable (incorporating any of these, incompatible modifies, ...). For 381.22, current patchset applies and builds fine for me. On Sun, 04 Jun 2017 08:04:50 +0000 blubee blubeeme wrote: > I'm running with svn and I build by make. > If in use these steps, the BSD related patches will be applied, etc? > > Best, > Owen > > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI wrote: > > > Hi. > > > > Not in ports tree, but easily overridden by adding > > > > DISTVERSION=381.22 -DNO_CHECKSUM > > > > on make command line. Makefile of x11/nvidia-driver has a mechanism > > to do so for someone requires newer version (newer GPU support, etc.). > > > > If you're using portupgrade, > > > > portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f x11/nvidia-driver > > > > would do the same. > > > > If you installed it via pkg, there's no way to try. :-( > > (As it's pre-built.) > > > > > > On Sun, 04 Jun 2017 07:04:01 +0000 > > blubee blubeeme wrote: > > > > > Hi @tomoaki > > > Is that version of nvidia drivers currently in the ports tree? I just > > > checked but it seems not to be. > > > > > > @jeffrey > > > I just generated a new xorg based on the force composition setting. I > > > merged it with my previous xorg I'll reboot, see if it gives better > > > performance. > > > > > > It seems like my system is locking up more frequently now. Sometimes > > right > > > after a reboot the system, the screen locks and it's reboot and pray. > > > > > > Best, > > > Owen > > > > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet > > wrote: > > > > > > > SOME LINES BOTTOM POSTED, SEE... > > > > -------------------------------------------- > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: > > > > > > > > Subject: Re: nvidia drivers mutex lock > > > > To: freebsd-current@freebsd.org > > > > Cc: "Jeffrey Bouquet" , "blubee blubeeme" < > > > > gurenchan@gmail.com> > > > > Date: Friday, June 2, 2017, 11:25 PM > > > > > > > > Hi. > > > > Version > > > > 381.22 (5 days newer than 375.66) of the driver states... > > > > [1] > > > > > > > > Fixed hangs and > > > > crashes that could occur when an OpenGL context is > > > > created while the system is out of available > > > > memory. > > > > > > > > Can this be related > > > > with your hang? > > > > > > > > IMHO, > > > > possibly allocating new resource (using os.lock_mtx > > > > guard) > > > > without checking the lock first while > > > > previous request is waiting for > > > > another can > > > > cause the duplicated lock situation. And high memory > > > > pressure would easily cause the situation. > > > > > > > > [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us > > > > > > > > Hope it helps. > > > > > > > > > > > > On Thu, 1 Jun > > > > 2017 22:35:46 +0000 (UTC) > > > > Jeffrey Bouquet > > > > > > > > wrote: > > > > > > > > > I see the same > > > > message, upon load, ... > > > > > > > > > -------------------------------------------- > > > > > On Thu, 6/1/17, blubee blubeeme > > > > wrote: > > > > > > > > > > Subject: > > > > nvidia drivers mutex lock > > > > > To: freebsd-ports@freebsd.org, > > > > freebsd-current@freebsd.org > > > > > Date: Thursday, June 1, 2017, 11:35 > > > > AM > > > > > > > > > > I'm > > > > running nvidia-drivers 375.66 with a GTX > > > > > 1070 on FreeBSD-Current > > > > > > > > > > This problem > > > > just started happening > > > > > recently but, > > > > every so often my laptop > > > > > screen will > > > > just blank out and then I > > > > > have to > > > > power cycle to get the > > > > > machine up and > > > > running again. > > > > > > > > > > It seems to be a problem with nvidia > > > > > drivers acquiring duplicate lock. Any > > > > > info on this? > > > > > > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > > > > > acquiring duplicate lock of same > > > > type: > > > > > "os.lock_mtx" > > > > > Jun$B".(B 2 02:29:41 blubee kernel: 1st > > > > > os.lock_mtx @ nvidia_os.c:841 > > > > > Jun$B".(B 2 02:29:41 blubee kernel: 2nd > > > > > os.lock_mtx @ nvidia_os.c:841 > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > > > > > stack backtrace: > > > > > > > > > Jun$B".(B 2 02:29:41 blubee kernel: #0 > > > > > > > > > 0xffffffff80ab7770 at > > > > > > > > > witness_debugger+0x70 > > > > > Jun$B".(B 2 > > > > 02:29:41 blubee kernel: #1 > > > > > > > > > 0xffffffff80ab7663 at > > > > > > > > > witness_checkorder+0xe23 > > > > > Jun$B".(B 2 > > > > 02:29:41 blubee kernel: #2 > > > > > > > > > 0xffffffff80a35b93 at > > > > > > > > > __mtx_lock_flags+0x93 > > > > > Jun$B".(B 2 > > > > 02:29:41 blubee kernel: #3 > > > > > > > > > 0xffffffff82f4397b at > > > > > > > > > os_acquire_spinlock+0x1b > > > > > Jun$B".(B 2 > > > > 02:29:41 blubee kernel: #4 > > > > > > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > > > > > ACPI Warning: > > > > \_SB.PCI0.PEG0.PEGP._DSM: > > > > > Argument #4 > > > > type mismatch - Found > > > > > [Buffer], ACPI > > > > requires [Package] > > > > > > > > > (20170303/nsarguments-205) > > > > > Jun$B".(B 2 > > > > 02:29:42 blubee kernel: > > > > > > > > > nvidia-modeset: Allocated GPU:0 > > > > > > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > > > > > PCI:0000:01:00.0 > > > > > > > > > > > > > > Best, > > > > > Owen > > > > > > > > > _______________________________________________ > > > > > freebsd-ports@freebsd.org > > > > > mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > > > To unsubscribe, send any mail to > > > > "freebsd-ports-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > ... then Xorg will > > > > run happily twelve hours or so. The lockups here happen > > > > usually > > > > > when too large or too many of > > > > number of tabs/ large web pages with complex CSS etc > > > > > are opened at a time. > > > > > So no help, just a 'me > > > > too'. > > > > > > > > > _______________________________________________ > > > > > freebsd-current@freebsd.org > > > > mailing list > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscribe@freebsd.org > > > > " > > > > > > > > > > > > > > > > > > > > > > -- > > > > Tomoaki > > > > AOKI > > > > > > > > > > > > > > > > ........................ > > > > might be a workaround > > > > Xorg/nvidia ran all night with this: > > > > nvidia-settings >> X server display configuration >> Advanced >> > > Force > > > > Full Composition Pipeline > > > > ... for the laptop freezing. Could not hurt to try. " merge with > > > > Xorg.conf " from nvidia-settings... > > > > ...................... > > > > 18 hours uptime so far, even past > > > > the 3 am periodic scripts. Have not rebooted out of the Xorg though > > so > > > > may require edit-out of > > > > xorg.conf if that is the case, in other words differing from real-time > > > > apply and > > > > xorg initially start applies. > > > > ........ > > > > > > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscribe@freebsd.org" > > > > > > > > > > > > -- > > Tomoaki AOKI > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Jun 4 10:12:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D735EAFF490 for ; Sun, 4 Jun 2017 10:12:07 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 A42DA71238 for ; Sun, 4 Jun 2017 10:12:07 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x230.google.com with SMTP id t185so11700804pgd.1 for ; Sun, 04 Jun 2017 03:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fpji8LdtUS3VAU7snnSyCY7CV6EsXSqXH7NTv+Yq8T8=; b=MFSq6pSrhG0B+QPdH5tQdi6g855LPg942TpUUpmmMHaIb4R7jHTsQOFxjcKojurGo4 /qEOItmVQpP63PzsbTdIT8hcMUA1/ed6TaeJlujbXepxXdG+dJXXOc6pg3lxLLeFRkUZ bksMWYkWwAP9dPp06aT+kvySmtY1L9uKAkEJ/ssyKIizyrfvGEDHGV8tcYnK/nhX77G+ SQqKzb2WSQOHGUtd795Bc8OiBTI7BuJbu8Nyr5X/fy4YIjnrBFPCfWRV7zVPsDBI7cEu 8zXKqGlO1c7F59Iu++KLgU7lW14kUvjNWzNu+q/DCWiGbXrZUzvwW9VhICv0J27lVGDo 9yOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fpji8LdtUS3VAU7snnSyCY7CV6EsXSqXH7NTv+Yq8T8=; b=hvf6cg6jOaM0UFFCYy95M6xzm40RHV+lNjGXDPnVSZUrp6tRpT0qyEpOQiw0TGO1wu Xv1oDjo05OlaIWAgCezgUAT/KxPq8dNC89wkiS2sxXQkZLrci4f5RKwANMJ49DGqT/FV ppxjHPTXEQH47DQCksPMv/IHse0VJLHp/pKDnAOAqpdGKauEAPmFtjoz8qgbY/4pPsYw V6HFZxlVFYgn+v5Qnp8Gohj+YiFRmlQ3L2Adtj18gXSVt8tJHcZSTmhi7obDZrfcd6+G uWwkcTzGQAXMlMpUkTpjhEHABhD9oFu+JAzEVo7SXmcnDjH872wOO4boCxEdJLJfc3+z zJ+A== X-Gm-Message-State: AODbwcBKvK6qvzQEYbLpmeSl0lhch3F5rtxeFPwnCNuS2DPWLqHsLizT qDEB7WVlOfn/Y5gyJ/M35/Snku4pYw== X-Received: by 10.99.126.67 with SMTP id o3mr15491682pgn.36.1496571127115; Sun, 04 Jun 2017 03:12:07 -0700 (PDT) MIME-Version: 1.0 References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> In-Reply-To: <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> From: blubee blubeeme Date: Sun, 04 Jun 2017 10:11:56 +0000 Message-ID: Subject: Re: nvidia drivers mutex lock To: Tomoaki AOKI Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 10:12:08 -0000 Thanks a lot! I'll give it a shot in a bit. Best, Owen On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI wrote: > Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. > > But beware! Sometimes upstream changes make any of FreeBSD patches not > applicable (incorporating any of these, incompatible modifies, ...). > > For 381.22, current patchset applies and builds fine for me. > > > On Sun, 04 Jun 2017 08:04:50 +0000 > blubee blubeeme wrote: > > > I'm running with svn and I build by make. > > If in use these steps, the BSD related patches will be applied, etc? > > > > Best, > > Owen > > > > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI > wrote: > > > > > Hi. > > > > > > Not in ports tree, but easily overridden by adding > > > > > > DISTVERSION=3D381.22 -DNO_CHECKSUM > > > > > > on make command line. Makefile of x11/nvidia-driver has a mechanism > > > to do so for someone requires newer version (newer GPU support, etc.)= . > > > > > > If you're using portupgrade, > > > > > > portupgrade -m 'DISTVERSION=3D381.22 -DNO_CHECKSUM' -f > x11/nvidia-driver > > > > > > would do the same. > > > > > > If you installed it via pkg, there's no way to try. :-( > > > (As it's pre-built.) > > > > > > > > > On Sun, 04 Jun 2017 07:04:01 +0000 > > > blubee blubeeme wrote: > > > > > > > Hi @tomoaki > > > > Is that version of nvidia drivers currently in the ports tree? I ju= st > > > > checked but it seems not to be. > > > > > > > > @jeffrey > > > > I just generated a new xorg based on the force composition setting.= I > > > > merged it with my previous xorg I'll reboot, see if it gives better > > > > performance. > > > > > > > > It seems like my system is locking up more frequently now. Sometime= s > > > right > > > > after a reboot the system, the screen locks and it's reboot and pra= y. > > > > > > > > Best, > > > > Owen > > > > > > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet > > > > wrote: > > > > > > > > > SOME LINES BOTTOM POSTED, SEE... > > > > > -------------------------------------------- > > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: > > > > > > > > > > Subject: Re: nvidia drivers mutex lock > > > > > To: freebsd-current@freebsd.org > > > > > Cc: "Jeffrey Bouquet" , "blubee > blubeeme" < > > > > > gurenchan@gmail.com> > > > > > Date: Friday, June 2, 2017, 11:25 PM > > > > > > > > > > Hi. > > > > > Version > > > > > 381.22 (5 days newer than 375.66) of the driver states... > > > > > [1] > > > > > > > > > > Fixed hangs and > > > > > crashes that could occur when an OpenGL context is > > > > > created while the system is out of available > > > > > memory. > > > > > > > > > > Can this be related > > > > > with your hang? > > > > > > > > > > IMHO, > > > > > possibly allocating new resource (using os.lock_mtx > > > > > guard) > > > > > without checking the lock first while > > > > > previous request is waiting for > > > > > another can > > > > > cause the duplicated lock situation. And high memory > > > > > pressure would easily cause the situation. > > > > > > > > > > [1] > http://www.nvidia.com/Download/driverResults.aspx/118527/en-us > > > > > > > > > > Hope it helps. > > > > > > > > > > > > > > > On Thu, 1 Jun > > > > > 2017 22:35:46 +0000 (UTC) > > > > > Jeffrey Bouquet > > > > > > > > > > wrote: > > > > > > > > > > > I see the same > > > > > message, upon load, ... > > > > > > > > > > > -------------------------------------------- > > > > > > On Thu, 6/1/17, blubee blubeeme > > > > > wrote: > > > > > > > > > > > > Subject: > > > > > nvidia drivers mutex lock > > > > > > To: freebsd-ports@freebsd.org, > > > > > freebsd-current@freebsd.org > > > > > > Date: Thursday, June 1, 2017, 11:35 > > > > > AM > > > > > > > > > > > > I'm > > > > > running nvidia-drivers 375.66 with a GTX > > > > > > 1070 on FreeBSD-Current > > > > > > > > > > > > This problem > > > > > just started happening > > > > > > recently but, > > > > > every so often my laptop > > > > > > screen will > > > > > just blank out and then I > > > > > > have to > > > > > power cycle to get the > > > > > > machine up and > > > > > running again. > > > > > > > > > > > > It seems to be a problem with nvidia > > > > > > drivers acquiring duplicate lock. Any > > > > > > info on this? > > > > > > > > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: > > > > > > acquiring duplicate lock of same > > > > > type: > > > > > > "os.lock_mtx" > > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: 1st > > > > > > os.lock_mtx @ nvidia_os.c:841 > > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: 2nd > > > > > > os.lock_mtx @ nvidia_os.c:841 > > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: > > > > > > stack backtrace: > > > > > > > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: #0 > > > > > > > > > > > 0xffffffff80ab7770 at > > > > > > > > > > > witness_debugger+0x70 > > > > > > Jun=E3=80=93 2 > > > > > 02:29:41 blubee kernel: #1 > > > > > > > > > > > 0xffffffff80ab7663 at > > > > > > > > > > > witness_checkorder+0xe23 > > > > > > Jun=E3=80=93 2 > > > > > 02:29:41 blubee kernel: #2 > > > > > > > > > > > 0xffffffff80a35b93 at > > > > > > > > > > > __mtx_lock_flags+0x93 > > > > > > Jun=E3=80=93 2 > > > > > 02:29:41 blubee kernel: #3 > > > > > > > > > > > 0xffffffff82f4397b at > > > > > > > > > > > os_acquire_spinlock+0x1b > > > > > > Jun=E3=80=93 2 > > > > > 02:29:41 blubee kernel: #4 > > > > > > > > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 > > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: > > > > > > ACPI Warning: > > > > > \_SB.PCI0.PEG0.PEGP._DSM: > > > > > > Argument #4 > > > > > type mismatch - Found > > > > > > [Buffer], ACPI > > > > > requires [Package] > > > > > > > > > > > (20170303/nsarguments-205) > > > > > > Jun=E3=80=93 2 > > > > > 02:29:42 blubee kernel: > > > > > > > > > > > nvidia-modeset: Allocated GPU:0 > > > > > > > > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > > > > > > PCI:0000:01:00.0 > > > > > > > > > > > > > > > > > Best, > > > > > > Owen > > > > > > > > > > > _______________________________________________ > > > > > > freebsd-ports@freebsd.org > > > > > > mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > > > > > > To unsubscribe, send any mail to > > > > > "freebsd-ports-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > > > > > ... then Xorg will > > > > > run happily twelve hours or so. The lockups here happen > > > > > usually > > > > > > when too large or too many of > > > > > number of tabs/ large web pages with complex CSS etc > > > > > > are opened at a time. > > > > > > So no help, just a 'me > > > > > too'. > > > > > > > > > > > _______________________________________________ > > > > > > freebsd-current@freebsd.org > > > > > mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > > > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscribe@freebsd.org > > > > > " > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Tomoaki > > > > > AOKI > > > > > > > > > > > > > > > > > > > > ........................ > > > > > might be a workaround > > > > > Xorg/nvidia ran all night with this: > > > > > nvidia-settings >> X server display configuration >> Advanced > >> > > > Force > > > > > Full Composition Pipeline > > > > > ... for the laptop freezing. Could not hurt to try. " merge wit= h > > > > > Xorg.conf " from nvidia-settings... > > > > > ...................... > > > > > 18 hours uptime so far, even past > > > > > the 3 am periodic scripts. Have not rebooted out of the Xorg > though > > > so > > > > > may require edit-out of > > > > > xorg.conf if that is the case, in other words differing from > real-time > > > > > apply and > > > > > xorg initially start applies. > > > > > ........ > > > > > > > > > > > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > -- > > > Tomoaki AOKI > > > > > > -- > Tomoaki AOKI > From owner-freebsd-current@freebsd.org Sun Jun 4 11:07:22 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFDE2AFFD09; Sun, 4 Jun 2017 11:07:22 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 92A4972241; Sun, 4 Jun 2017 11:07:22 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x22f.google.com with SMTP id 8so23555506pgc.2; Sun, 04 Jun 2017 04:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zdJ9TxVaGvhEgs2WVqCedKnb0E241BD0xH49bDhr+mE=; b=gzOPnXkW3KM1g5/LIgdO68TyIh9h2SqzYHW5KSEX7jFE9ugs7SqHjukc41TIqDmYXp bj+0n1vBuga3OIv4dZt5biH8OCV97TZMLyilk2oQbXrx7Lh39fjksavLNAe9V4Ykv4BE bP8zIgXC7zcGygr55utEgPHFlXIMdL8bVeYE6y2LEMT1myA1GzWfTE9ci8ACuzSOjdCu C0W1nNOTveUwn6/YX5ZqZPZFFV0JWnjjXtIQAwjPAo1Crmr6FqtIVOyibye9buYgoc2l ozKA/YZn44OpjhAqtIW/rrcuzM4fnlNHBDE8q6PGmJ1VzAQOFlVWLmkB5I7KgqNZvL92 ehHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zdJ9TxVaGvhEgs2WVqCedKnb0E241BD0xH49bDhr+mE=; b=MdUmLSMbVOUQxsw2sCMHddIS3nrDnYTTLK8422uekgPWT1oPWzCTLZ3yFeZP7eDRrw ihTJrBnzOB/iSzUdUGsu3N3A2oV4WdF/r4u8sALfM5T1v3UxcE4vEWxd89vzAwnfzBeS Kb1gjb30AEh47z1vjybDtyItAI8oWFHCgRStmKE4hzyXVXak/qh/VNTdi5NSKd32SfbH lml9yZyoukkUQVvhVRbbpqOTm12x6uhe2MedUwW3LIEr0kbe/cbLogqkz75d9P/7gmyo MqXgY7i7DWy9X0evq5PmPNEliB5ogiPvmm3ETqTsJ54TDOPTIRpIHe5clqGzxHQvxWc/ /wmw== X-Gm-Message-State: AODbwcDDi8mmE/nsAqgCdOMy3KqIVgW0MSYYvrJZ3u8X8E8MVrLFEl9F cJ/nRv/QJEkP3T7hq32py+wk5RcrzC9G X-Received: by 10.99.43.201 with SMTP id r192mr15401292pgr.135.1496574441836; Sun, 04 Jun 2017 04:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.79 with HTTP; Sun, 4 Jun 2017 04:07:21 -0700 (PDT) From: blubee blubeeme Date: Sun, 4 Jun 2017 19:07:21 +0800 Message-ID: Subject: [Help] Linux low level data structures < - > FreeBSD low level data structures To: FreeBSD current , freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 11:07:22 -0000 Hello Is there anyone on either of these lists that have experience with both linux low level data structures and their equivalents on FreeBSD? For instance the linux header file: which includes the header file: Then looking at that file: I'll be doing a lot of work trying to find these FreeBSD equivalent of these types of files to port some code. Does anyone here have experience with something like this? Is there any other projects that maps these low level data structures from Linux <-> FreeBSD, etc? Best, Owen From owner-freebsd-current@freebsd.org Sun Jun 4 12:09:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 288F3B7A746 for ; Sun, 4 Jun 2017 12:09:59 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD1C745B9 for ; Sun, 4 Jun 2017 12:09:59 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 0B063B7A745; Sun, 4 Jun 2017 12:09:59 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AA08B7A744 for ; Sun, 4 Jun 2017 12:09:59 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2118745B8 for ; Sun, 4 Jun 2017 12:09:58 +0000 (UTC) (envelope-from Alexander@leidinger.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1496578164; bh=8/J0hUyBkbgCIQgezcp74IvKSpCjXyG5G+kPYz7yyIY=; h=Date:From:To:Subject; b=IcBKwGogEQyMo4VpSzQg5CsGF25+kXgoBkIBRJ1ft5PQMOgBzQI9h9DoAf/7M/zaa JK8Gj++wSI11TyRBAFJY9Jy//urG5oBEseUgLMJvOc+aMNqE3E9V+VDZ2pnQXz4X2Y f3eqmY8Lw0dlhYH5BLJUC7dq0SJb5wpuG5IdnZwCj1gntIyi4kmNRgI8NWO6KFQB/s z7r1IVAV/aMi3eTKwN0+FlQoWuLmRAkedhL7/Zyzyqp9axDeYPDLVXbzCQXB/OC+pE gbgAf2wn4bVL+3bbK4Be2IDUtT0qndzmneFAg6aRn6dN84RSt30p9+DGW99qyXdP0d GCts1aGuvrckQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1496578187; bh=8/J0hUyBkbgCIQgezcp74IvKSpCjXyG5G+kPYz7yyIY=; h=Date:From:To:Subject; b=Asb2x8/7yrDfII0i63wRgCmJdHafIRkR7XqoMT0B6KZ2kD0ElPPV/C/l//o3GBPCy +Vq9OZnyB9PaUEXsx7HaK4nZUP3X0dyBkQKSvZqQ7e9QgH3hhBwLDXXYCCo+u9ThyM 7WNAVtdcLP5//wIUUV5JqfuiyYHw5wNkfzjImujz6V5v7+D9f1v0rLiQfpCbysRbcu 2/4uKH8d3OWHvdu3e5M1P7o5IHtOq7CnkVkwnhp/0f7/zONrCsxDJBDH16MFzvstAB fIREfbA8MRgqvx0huzJ80YQD8EH0gyhfzFZH/wQ8FLoxXTcMK2Vh9aeoaGxDai8VIl hz5vt8eRMMbSw== Date: Sun, 04 Jun 2017 14:09:24 +0200 Message-ID: <20170604140924.Horde.oGvD2didLbdx2PCsGHE3gDi@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: old syslog (jail) and new kernel = 100% CPU User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_MjyA3Ys--7hQ7eUb3JkFvvV"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 12:09:59 -0000 This message is in MIME format and has been PGP signed. --=_MjyA3Ys--7hQ7eUb3JkFvvV Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, new kernel (surely r318877 and later) and old syslog in a jail =3D NOK. I remember some mails about syslog going 100% COU some weeks ago, but=20=20 thought=20it was solved. As we have the goal to keep backward=20=20 compatibility,=20what is the issue here? I have this in the kernel: ---snip--- options COMPAT_FREEBSD32 options COMPAT_FREEBSD10 options COMPAT_FREEBSD11 ---snip--- new kernel and new syslog =3D OK Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_MjyA3Ys--7hQ7eUb3JkFvvV Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJZM/h0AAoJEKrxQhqFIICEH7IP/31iy+25iEhELKDMmxLcOKfp L+Mprps/fJCkt+iEg7BZrh5EUwP3k88Beq1KMoS26yWHL0+cgSPkPfpyB7E02/Td TelUXM6ENbwmUXwkaOA+EW2eBGaLBrLpAS4a812La/HtbWQa9uu6Tw6ifRZYx9hh fHwWThyLUPhpCzbGxNhwlfDUkv/8LzkS/KP80mWCcWqSyMfvmbnpqEHS/VEiPTuN Rq03ats5jqWhrwY1+Fj8GWhGPDrkNVfACq1VxRzcKfC4ejTNBYHEMCfd3VsPRg55 uNKfCNMw2yjRfyPdDSG3j9gZ50tSrxH11DDDWLE0cTs6I+5RvtZewmiE4xhhR2Q1 lQhyYEtdEJy53Y/9OqPVQGeMmMKShuVCjUg0j+tFw+O80Gk/scGTI0x/O0n2hdpY Qg/mJr4SXH66abslgFTioUQyRltlNXKI4i35S2xA3eRRbrMiN+X4Iyhv7z0ri7DR XinDJ6sAOgSHzBQ/ujV9gB+ONAdkCFrBR9tfYFaTKZdlWFeSUGLYiZRkhweOc4R6 8YH9CHUe+zXiaMmvd2qiJ9pmsHdEBNPSKReExE0ZWcqNy0GgXAPpgm3mvNRuyOCq HL8/+baUk6uWBa482GYlVMBe7NjeFtPSSBY9OYhpoWiE1qwml89y0j/7AZ/9HH8n s+S2V4Qx9fiov//iJMtB =0waf -----END PGP SIGNATURE----- --=_MjyA3Ys--7hQ7eUb3JkFvvV-- From owner-freebsd-current@freebsd.org Sun Jun 4 12:28:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23CF4B7AFA6 for ; Sun, 4 Jun 2017 12:28:46 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 07CD274F27 for ; Sun, 4 Jun 2017 12:28:46 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 0418BB7AFA5; Sun, 4 Jun 2017 12:28:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 039E0B7AFA4 for ; Sun, 4 Jun 2017 12:28:46 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8911D74F26 for ; Sun, 4 Jun 2017 12:28:44 +0000 (UTC) (envelope-from Alexander@leidinger.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1496579289; bh=FKQGxeNuEeTawStstHGOLGHHUZMfE26CHhnRKi29KB4=; h=Date:From:To:Subject; b=fkRI7u1AR9dJK3opJFw4itCQP+sSokjiV9n4h8SmtWPuzmRODosBYlnARIeBvcAR0 YAuamhpmApaqXLNtwC4mY8sAoFIcqz8wf3Hzd9V8p22QtllBy8r1f1pDkSwe54b830 KvHxXkLN6qBoBuIDuno4w9PASsTu/w42U+XeJayQMgRVakALYK6SDB+qnSqZqVzCGs V7yvFWtqOdiL/C98a7Gs1fewLt+pFx4I+GtKRpc5KOuKMxvDRtIxZocteA9skgXdRd 4ZGFk8YBIGhcNBF/b6QUNy5TjHg7kIKkXwNZA428v1b53t3cpguLqlGckvP2B3pZ7M dHcjHux20qBkA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1496579321; bh=FKQGxeNuEeTawStstHGOLGHHUZMfE26CHhnRKi29KB4=; h=Date:From:To:Subject; b=q9TohpcrZEbToHNV0nIASNz6GGHg7nDzbzCMkuylLbu/btELKKHUzqBSyQyWjimmE 2fynjwhPgcMeDIMfRgx+XfuG66DNvxp/lvgesOX4kD2OVGM+XPm+jsB648bHVxXQGv /YtK8JXOhn+1YuKvaqyQeOPYdq78yv7XVm0ep1mYu9MRhpnZtp2bse2BCfkwtzM52d z1BJ6nEANjmFUwk07yqeuCpsxU6eE1uO13I8JNcJOL5cK5tYEQkflXVhAchQhMtHu2 J+M4Pa2lITqTsKs0bxzAsWIwZoeAAjEHVnMkU/I1bQbdsymHb1BzoZ9XMF5cKztsgW jvRvXzSqaVnxA== Date: Sun, 04 Jun 2017 14:28:09 +0200 Message-ID: <20170604142809.Horde.fwk20aBDjbwJYjG3hhX43yk@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: zfsloader and compiler options/version? User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_Ll4-GB0ZnOuykTGt063R7HK"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 12:28:46 -0000 This message is in MIME format and has been PGP signed. --=_Ll4-GB0ZnOuykTGt063R7HK Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have a zfsloader which hangs directly after "Booting". First I=20=20 attributed=20it to maybe a bug in meta-mode/ccache + ino64 (easy=20=20 assumption=20without knowing if ino64 is involved in zfsloader), but=20=20 after=20ccache -C, removing /usr/obj and running 2x "make cleanworld"=20=20 and=202x "make clean" before a buildworld I now get some kind of a=20=20 loader-dump=20(BTX halted) message. The zfsloader binary from a=20=20 downloaded=20release-snapshot (r318945) after ino64 update doesn't=20=20 exhibit=20this issue. Has someone seen something similar? So far I assume this is something=20=20 with=20the compiler flags... I have the broken zfsloader (r319541) available at http://www.leidinger.net/FreeBSD/zfsloader.nok if someone wants to play around with it. Here the settings I used to compile it: dmesg: FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on=20=20 LLVM=204.0.0) CPU: Intel(R) Xeon(R) CPU L5630 @ 2.13GHz (2133.35-MHz=20=20 K8-class=20CPU) /etc/src-env.conf WITH_META_MODE=3Dyes /etc/src.conf WITH_IDEA=3Dyes WITHOUT_PROFILE=3Dyes CFLAGS+=3D-DFTP_COMBINE_CWDS MALLOC_PRODUCTION=3Dyes LOADER_FIREWIRE_SUPPORT=3Dyes #WITH_FAST_DEPEND=3Dyes KERNCONF=3DANDROMEDA /etc/make.conf CFLAGS+=3D -O2 -pipe #-mfpmath=3Dsse -msse2 COPTFLAGS=3D -O2 -pipe CPUTYPE?=3Dnative WITH_CCACHE_BUILD=3Dyes Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_Ll4-GB0ZnOuykTGt063R7HK Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJZM/zZAAoJEKrxQhqFIICEZigQALOaeZ2AWvkItxXNPxsI5ncf aVuvQjS6cbiN1M/Nkx1TeUK/+X+IIFQF4XvWlTZrrpu3JIUaYYL7ZGwGWTOCS9jC iEs62grPXUQz4iToKix16MjZ3d36CLBbHgRnz5G6+1AnDjBD0ngImAC5Lu8ro4jw oXzJBMDX5S2JphyXCqNe11uY+5To4XCRD3dvUu6zKLhSF164nDTb8pBEpP3iW6VO iFpMZn6t2zUzjjsafloSoaemal15+h0DyMle4gb4kbwmySCYerUOUL64okDDswfY HEsMtmj64/cWhSCjcrZsigzIa/niwZLjCiA9MwDEXL5g+lJIV2XZ7dBuSlcdUJm0 ThbbfzmyqAPofb5/y8tpNOBukx4/Fs1HwsIyLM2Xz9Ylo9ASS5QBWQdG/7IHev+9 JarnXWkSnCpLEnH5xyftpdeU1wMpZJqlvMgWmfYG8UNClnFfo2eKTFtNNS/XYSDA VPcn3dKytDYv7/kicoFm+GTY/RNNfZ6YB4WbDu9YYaGczCG/ZeC5LmKKcPWbc2W5 ljrWNXcNZlxQJh+Q9iYRj6rTIRoPNnBCSaRryEPNIs2kQcwzrmmiEI236mIF0K40 lN+TYXSW8u3xVQGi3F3QVbit1uxeLet0TgrnTjrENKfllwqXHulm4fIFo2RsptoM +Ijio9SbCozooBV0iyAq =wW3y -----END PGP SIGNATURE----- --=_Ll4-GB0ZnOuykTGt063R7HK-- From owner-freebsd-current@freebsd.org Sun Jun 4 12:40:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56BF8B7B30D for ; Sun, 4 Jun 2017 12:40:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670087.outbound.protection.outlook.com [40.107.67.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC937553B; Sun, 4 Jun 2017 12:40:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Sun, 4 Jun 2017 12:40:55 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1143.016; Sun, 4 Jun 2017 12:40:55 +0000 From: Rick Macklem To: Konstantin Belousov , Warner Losh CC: Allan Jude , FreeBSD Current Subject: Re: Time to increase MAXPHYS? Thread-Topic: Time to increase MAXPHYS? Thread-Index: AQHS3MmlzeCiZMQNZE6lL7/mJ9kEx6IT/NwAgAAWeoCAABnbgIAALU4AgABK9Uo= Date: Sun, 4 Jun 2017 12:40:55 +0000 Message-ID: References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> , <20170604081032.GN82323@kib.kiev.ua> In-Reply-To: <20170604081032.GN82323@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:MKDwYGFirPRAb80UhyXDGtYTnKqKtkKbZplodiYwOEPIfelK5gT+Ox0V99XaD3ZCK5z+pxITmLe/hc5e1MU68HTIPqRuf90RLEEHReOhryvURYR2PVc/0dZbflaSvRNnemEEcMBrLwWLpT9noRuR4twd0MXdVds3b7am41CJ2aLGywSXNLpIEG5Y0te+P6yu3eLu4+2ABR2mCPeQatZ4bbibaGWPK74ZX4b6NFtsr9KjUsUmh14cwzhWlMHG/ZGRJdqLGjuimV8BvL1vDH5kyJMfj21P7dc/twwD+LQOrO1yyJJWyEIPVwwFp1LRzesCrhqkYIsmcEilMuWOEO8XFA== x-ms-traffictypediagnostic: YTXPR01MB0190: x-ms-office365-filtering-correlation-id: 1ece7c25-8f67-453d-861a-08d4ab46f1ac x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:YTXPR01MB0190; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTXPR01MB0190; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39410400002)(39850400002)(39840400002)(377424004)(377454003)(51444003)(57704003)(24454002)(3660700001)(3280700002)(7696004)(14454004)(86362001)(551934003)(561944003)(39060400002)(966005)(229853002)(53546009)(25786009)(50986999)(2950100002)(4326008)(76176999)(54356999)(8676002)(81166006)(478600001)(8936002)(3480700004)(93886004)(6246003)(305945005)(74316002)(38730400002)(102836003)(74482002)(122556002)(2900100001)(6436002)(6506006)(33656002)(77096006)(2906002)(6306002)(189998001)(9686003)(53936002)(55016002)(5660300001)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2017 12:40:55.6289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 12:40:59 -0000 There is an array in aio.h sized on MAXPHYS as well. A simpler possibility might be to leave MAXPHYS as a compile time setting, but allow it to be set "per arch" and make it bigger for amd64. Good luck with it, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Konstantin Belousov Sent: Sunday, June 4, 2017 4:10:32 AM To: Warner Losh Cc: Allan Jude; FreeBSD Current Subject: Re: Time to increase MAXPHYS? On Sat, Jun 03, 2017 at 11:28:23PM -0600, Warner Losh wrote: > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > > > On 2017-06-03 22:35, Julian Elischer wrote: > > > On 4/6/17 4:59 am, Colin Percival wrote: > > >> On January 24, 1998, in what was later renumbered to SVN r32724, dys= on@ > > >> wrote: > > >>> Add better support for larger I/O clusters, including larger physic= al > > >>> I/O. The support is not mature yet, and some of the underlying > > >>> implementation > > >>> needs help. However, support does exist for IDE devices now. > > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase = it > > >> again, > > >> or do we need to wait at least two decades between changes? > > >> > > >> This is hurting performance on some systems; in particular, EC2 "io1= " > > >> disks > > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > > >> spinning rust) > > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > > >> recommends > > >> using a maximum I/O size of 1 MB (and despite NFS not being *physica= l* > > >> I/O it > > >> seems to still be limited by MAXPHYS). > > >> > > > We increase it in freebsd 8 and 10.3 on our systems, Only good resul= ts. > > > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/= O > > > transfer size */ > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > freebsd.org" > > > > At some point Warner and I discussed how hard it might be to make this = a > > boot time tunable, so that big amd64 machines can have a larger value > > without causing problems for smaller machines. > > > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > > of the benefit. > > > > I am preparing some benchmarks and other data along with a patch to > > increase the maximum size of pipe I/O's as well, because using 1MB > > offers a relatively large performance gain there as well. > > > > It doesn't look to be hard to change this, though struct buf depends on > MAXPHYS: > struct vm_page *b_pages[btoc(MAXPHYS)]; > and b_pages isn't the last item in the list, so changing MAXPHYS at boot > time would cause an ABI change. IMHO, we should move it to the last eleme= nt > so that wouldn't happen. IIRC all buf allocations are from a fixed pool. > We'd have to audit anybody that creates one on the stack knowing it will = be > persisted. Given how things work, I don't think this is possible, so we m= ay > be safe. Thankfully, struct bio doesn't seem to be affected. > > As for making it boot-time configurable, it shouldn't be too horrible wit= h > the above change. We should have enough of the tunables mechanism up earl= y > enough to pull this in before we create the buf pool. > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to b= e > sure, especially on memory limited systems. Lots of hardware can't do thi= s > big an I/O, and some drivers can't cope, even if the underlying hardware > can. Since we don't use such drivers at work, I don't have a list handy > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > reasonable bump by default, but I think going larger by default should be > approached with some caution given the overhead that adds to struct buf. > Having it be a run-time tunable would be great. The most important side-effect of bumping MAXPHYS as high as you did, which is somewhat counter-intuitive and also probably does not matter for typical Netflix cache box load (as I understand it) is increase of fragmentation for UFS volumes. MAXPHYS limits the max cluster size, and larger the cluster we trying to build, larger is the probability of failure. We might end with single-bloc= k writes more often, defeating reallocblk defragmenter. This might be somewhat theoretical, and probably can be mitigated in the clustering code if real, but it is a thing to look at. WRT making the MAXPHYS tunable, I do not like the proposal of converting b_pages[] into the flexible array. I think that making b_pages a pointer to off-structure page run is better. One of the reason is that buf cache buffers are not only buffers in the system. There are several cases where the buffers are malloced, like markers for iterating queues. In this case, b_pages[] can be eliminated at all. (I believe I changed all local struct bufs to be allocated with malloc). Another non-struct buf supply of buffers are phys buffers pool, see vm/vm_pager.c. > > There's a number of places in userland that depend on MAXPHYS, which is > unfortunate since they assume a fixed value and don't pick it up from the > kernel or kernel config. Thankfully, there are only a limited number of > these. > > Of course, there's times when I/Os can return much more than this. Readin= g > drive log pages, for example, can generate tens or hundreds of MB of data= , > and there's no way to do that with one transaction today. If drive makers > were perfect, we could use the generally defined offset and length fields > to read them out piecemeal. If the log is table, a big if for some of the > snapshots of internal state logs that are sometimes necessary to > investigate problems... It sure would be nice if there were a way to have > super-huge I/O on an exception basis for these situations. _______________________________________________ freebsd-current@freebsd.org mailing list https://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 Jun 4 12:51:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01A48B7B6E1 for ; Sun, 4 Jun 2017 12:51:58 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 96FD375BE2 for ; Sun, 4 Jun 2017 12:51:56 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v54CprX1035977; Sun, 4 Jun 2017 21:51:53 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 4 Jun 2017 21:51:53 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: Alexander Leidinger Subject: Re: zfsloader and compiler options/version? Message-Id: <20170604215153.962478860d60be4be699f951@dec.sakura.ne.jp> In-Reply-To: <20170604142809.Horde.fwk20aBDjbwJYjG3hhX43yk@webmail.leidinger.net> References: <20170604142809.Horde.fwk20aBDjbwJYjG3hhX43yk@webmail.leidinger.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 12:51:58 -0000 Hi. Possibly setting CPUTYPE in make.conf (or src.conf) can cause problem for loaders. I have below in make.conf. (amd64) .if !${.CURDIR:M/usr/src/sys/boot*} CPUTYPE?= corei7-avx .endif Additionally, for something above doesn't work: .if ${.CURDIR:M/usr/ports/games/rubix} CPUTYPE= core .endif .if ${.CURDIR:M/usr/ports/lang/gcc} CPUTYPE= core2 .endif Possibly lang/gcc can handle corei7-avx now, but not yet tested. On Sun, 04 Jun 2017 14:28:09 +0200 Alexander Leidinger wrote: > Hi, > > I have a zfsloader which hangs directly after "Booting". First I > attributed it to maybe a bug in meta-mode/ccache + ino64 (easy > assumption without knowing if ino64 is involved in zfsloader), but > after ccache -C, removing /usr/obj and running 2x "make cleanworld" > and 2x "make clean" before a buildworld I now get some kind of a > loader-dump (BTX halted) message. The zfsloader binary from a > downloaded release-snapshot (r318945) after ino64 update doesn't > exhibit this issue. > > Has someone seen something similar? So far I assume this is something > with the compiler flags... > > I have the broken zfsloader (r319541) available at > http://www.leidinger.net/FreeBSD/zfsloader.nok > if someone wants to play around with it. > > Here the settings I used to compile it: > > dmesg: > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > CPU: Intel(R) Xeon(R) CPU L5630 @ 2.13GHz (2133.35-MHz > K8-class CPU) > > /etc/src-env.conf > WITH_META_MODE=yes > > /etc/src.conf > WITH_IDEA=yes > WITHOUT_PROFILE=yes > CFLAGS+=-DFTP_COMBINE_CWDS > MALLOC_PRODUCTION=yes > LOADER_FIREWIRE_SUPPORT=yes > #WITH_FAST_DEPEND=yes > KERNCONF=ANDROMEDA > > /etc/make.conf > CFLAGS+= -O2 -pipe #-mfpmath=sse -msse2 > COPTFLAGS= -O2 -pipe > CPUTYPE?=native > WITH_CCACHE_BUILD=yes > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sun Jun 4 12:57:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 734B0B7B809 for ; Sun, 4 Jun 2017 12:57:54 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protected-networks.net", Issuer "Protected Networks CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 44D5175DE2 for ; Sun, 4 Jun 2017 12:57:54 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding :content-language:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from; s= 201508; t=1496581065; bh=vkwm2OzsSxmPpxa9ptgU1ZqzdKpKg50l7bU9Ijf HT14=; b=KiZWyGAo5ctSnReMnbn0pQfbAeSg3aEFduTv14VQnLSr8zUG6CdgsYt 5hbPFRdHajPqZ9rG4ugZKgH+brbFo9hidQBZ9HR41VChWIIt6VcrHhhfFddbtdjr /8c3CiUFYTd6yu2y/6mc5iZHDdbS3dXpYU3XpdTk09TH4fkkVtDM= Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 4192AB617; Sun, 4 Jun 2017 08:57:45 -0400 (EDT) To: freebsd-current , Rick Macklem From: Michael Butler Subject: post ino64: lockd no runs? Openpgp: id=6F63E6399DCC8E3E94D60F0642FF6BAE0442D492 Message-ID: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> Date: Sun, 4 Jun 2017 08:57:44 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 12:57:54 -0000 It seems that {rpc.}lockd no longer runs after the ino64 changes on any of my systems after a full rebuild of src and ports. No log entries offer any insight as to why :-( imb From owner-freebsd-current@freebsd.org Sun Jun 4 14:16:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A8DFB7C73A for ; Sun, 4 Jun 2017 14:16:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 BC2B37777F; Sun, 4 Jun 2017 14:15:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1dHWJp-000Gzg-Ul; Sun, 04 Jun 2017 17:15:49 +0300 Date: Sun, 4 Jun 2017 17:15:49 +0300 From: Slawa Olhovchenkov To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170604141549.GC3182@zxy.spb.ru> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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.23 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, 04 Jun 2017 14:16:00 -0000 On Sat, Jun 03, 2017 at 11:55:51PM -0400, Allan Jude wrote: > On 2017-06-03 22:35, Julian Elischer wrote: > > On 4/6/17 4:59 am, Colin Percival wrote: > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > >> wrote: > >>> Add better support for larger I/O clusters, including larger physical > >>> I/O. The support is not mature yet, and some of the underlying > >>> implementation > >>> needs help. However, support does exist for IDE devices now. > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > >> again, > >> or do we need to wait at least two decades between changes? > >> > >> This is hurting performance on some systems; in particular, EC2 "io1" > >> disks > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > >> spinning rust) > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > >> recommends > >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > >> I/O it > >> seems to still be limited by MAXPHYS). > >> > > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > > transfer size */ > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > At some point Warner and I discussed how hard it might be to make this a > boot time tunable, so that big amd64 machines can have a larger value > without causing problems for smaller machines. > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > of the benefit. 16MB From owner-freebsd-current@freebsd.org Sun Jun 4 14:18:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F37B9B7C810 for ; Sun, 4 Jun 2017 14:18:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 B34DE778CC; Sun, 4 Jun 2017 14:18:31 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1dHWMP-000H0y-Mm; Sun, 04 Jun 2017 17:18:29 +0300 Date: Sun, 4 Jun 2017 17:18:29 +0300 From: Slawa Olhovchenkov To: Warner Losh Cc: Allan Jude , FreeBSD Current Subject: Re: Time to increase MAXPHYS? Message-ID: <20170604141829.GD3182@zxy.spb.ru> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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.23 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, 04 Jun 2017 14:18:32 -0000 On Sat, Jun 03, 2017 at 11:49:01PM -0600, Warner Losh wrote: > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > > sure, especially on memory limited systems. Lots of hardware can't do this > > big an I/O, and some drivers can't cope, even if the underlying hardware > > can. Since we don't use such drivers at work, I don't have a list handy > > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > > reasonable bump by default, but I think going larger by default should be > > approached with some caution given the overhead that adds to struct buf. > > Having it be a run-time tunable would be great. > > > > Of course 128k is reasonable, it's the current default :). I'd mean to say > that doubling would have a limited impact. 1MB might be a good default, but > it might be too big for smaller systems (nothing says it has to be a MI > constant, though). It would be a perfectly fine default if it were a > tunable. Some cloud providers limit IOPs per VM, for this cases MAXPHYS must be large as posible. From owner-freebsd-current@freebsd.org Sun Jun 4 14:22:06 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF660B7CA0C for ; Sun, 4 Jun 2017 14:22:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 904E177C2D for ; Sun, 4 Jun 2017 14:22:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8F50CB7CA0B; Sun, 4 Jun 2017 14:22:06 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EE64B7CA0A for ; Sun, 4 Jun 2017 14:22:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6803477C2C for ; Sun, 4 Jun 2017 14:22:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OR000400YDTMI00@st13p35im-asmtp001.me.com> for current@freebsd.org; Sun, 04 Jun 2017 13:21:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1496582518; bh=7IMGgg+ploaWMOHaoyFSMuf6XzcmS+sQejhpxCO7h3A=; h=From:Content-type:MIME-version:Subject:Date:To:Message-id; b=AbAloJw+AkR7HH+VziUVvRhJLpJKWljVjpweiee++tyPB48Y1xMf9JXfIBvfM5SgP Jlym8ivv5jZVkzdv4yaZyPD/7mA26Wxlw9sVSY7TlLzr4PlbkiyH4nkUESg+eJRV7B UoDzt0LrJbUcP9hiWTTlfixF4Xow37ABiXkqSW3dgUGCGGwSlKEDT7GIIsvTAaiO9Y 2H37O8aspH0mQkrxPxu0tiyA0aQFmWZ7xVR3bfqT6nU7LAdbjMRiRbeedJ6wLA/SLJ 5QUofStlXLmUClgODDjnyCaCoLVyN00I1hUGq7REF2BD0+7BvzLSnzhDmGnSlVxeH4 cl7UCVASXnL3A== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OR0000EWYGKMD20@st13p35im-asmtp001.me.com> for current@freebsd.org; Sun, 04 Jun 2017 13:21:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-04_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706040258 From: Toomas Soome Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: zfsloader and compiler options/version? Date: Sun, 04 Jun 2017 16:21:56 +0300 References: <20170604142809.Horde.fwk20aBDjbwJYjG3hhX43yk@webmail.leidinger.net> To: current@freebsd.org In-reply-to: <20170604142809.Horde.fwk20aBDjbwJYjG3hhX43yk@webmail.leidinger.net> Message-id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 14:22:06 -0000 > On 4. juuni 2017, at 15:28, Alexander Leidinger = wrote: >=20 > Hi, >=20 > I have a zfsloader which hangs directly after "Booting". First I = attributed it to maybe a bug in meta-mode/ccache + ino64 (easy = assumption without knowing if ino64 is involved in zfsloader), but after = ccache -C, removing /usr/obj and running 2x "make cleanworld" and 2x = "make clean" before a buildworld I now get some kind of a loader-dump = (BTX halted) message. The zfsloader binary from a downloaded = release-snapshot (r318945) after ino64 update doesn't exhibit this = issue. >=20 > Has someone seen something similar? So far I assume this is something = with the compiler flags... >=20 > I have the broken zfsloader (r319541) available at > http://www.leidinger.net/FreeBSD/zfsloader.nok > if someone wants to play around with it. >=20 note, with zfsboot.nok, selecting old kernel and boot did result in nice = BTX dump. And pressing the key with default kernel does get reboot. anyhow, it seems the issue is indeed about compile flags, with all = defaults my zfsloader has no problem booting the kernel. rgds, toomas > Here the settings I used to compile it: >=20 > dmesg: > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) > CPU: Intel(R) Xeon(R) CPU L5630 @ 2.13GHz (2133.35-MHz = K8-class CPU) >=20 > /etc/src-env.conf > WITH_META_MODE=3Dyes >=20 > /etc/src.conf > WITH_IDEA=3Dyes > WITHOUT_PROFILE=3Dyes > CFLAGS+=3D-DFTP_COMBINE_CWDS > MALLOC_PRODUCTION=3Dyes > LOADER_FIREWIRE_SUPPORT=3Dyes > #WITH_FAST_DEPEND=3Dyes > KERNCONF=3DANDROMEDA >=20 > /etc/make.conf > CFLAGS+=3D -O2 -pipe #-mfpmath=3Dsse -msse2 > COPTFLAGS=3D -O2 -pipe > CPUTYPE?=3Dnative > WITH_CCACHE_BUILD=3Dyes >=20 > Bye, > Alexander. >=20 > --=20 > http://www.Leidinger.net Alexander@Leidinger.net: PGP = 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP = 0x8F31830F9F2772BF From owner-freebsd-current@freebsd.org Sun Jun 4 14:36:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D6A1B7CDCD; Sun, 4 Jun 2017 14:36:00 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 13DC578363; Sun, 4 Jun 2017 14:36:00 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x241.google.com with SMTP id v18so3708930pgb.3; Sun, 04 Jun 2017 07:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LQrCAlml5h9EkeSF+HHs1vW/4G6M9x7PaYVtVv55HS0=; b=GPf9wviEloPFtVrJ4GYxQEf+PXvClAZ09MPI7GwB7xfH2TqWdRYeRHe46ngCyGKond K2kdA8v/qAKg2Ho5XOCmdpYyMeAS6HaB8MsnV6MQwQGDQTn62IKOq3D8YQa4F4Bc5DCI nR2mS7C+rclOT3Hgh2qfInybOdB/B3AeoRDDh+mmAW6wVcw9bqT9mbnzeuq//uQSoHuC wo3n/O9ong/WQlDHd5674Tc9FqBQDdhY6emjQVwLEtuB9thgVgl/5NDEoy1jWtsrBOVs Phs0H04TjnO8eQn1wn0YoKd/NiErGga7s+rtC0wkIW/qEj2YlcP6iibyBGPE+CD8doJz rnRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LQrCAlml5h9EkeSF+HHs1vW/4G6M9x7PaYVtVv55HS0=; b=CAaZJms3jlNxDJgv5paOL2TYzLwVfXYd1WAnGCMxSXAAVEAvDUY2j10RngDunjhun2 HOA6YivIxv8DHBMsBvbzCcZ3VW+VcrKfneJwNgnvW9CPWIrehxK5sNkdMth2S6cd0jro xr+/8vSRX1AfnLHJuh4hQwl/gvx6bE2TfR63V2dcjeZ3yNxB+USPCmLC4SgA+82KCMIc wOwtPlBdhThhrJN6qKkjYj8Hr07tHRhi1YxOnJ9oFI/v6BOS2HnJAusnU7IKQ/QsK7M5 dpWdJiaZpqiBowLTIv7Z8u097mv4WlZQxErWRSACj5ndOnZVk5u/TpPoHF2yOoYIDEDJ dhyQ== X-Gm-Message-State: AODbwcARYTrFOWjbSxippxxSJVmKka/ZnsIJyv6rzZA4ZFipmXRqisjR zUyRLCd2/k7cH8GWDsLDJohzpY179w== X-Received: by 10.84.179.65 with SMTP id a59mr9733231plc.82.1496586959507; Sun, 04 Jun 2017 07:35:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.79 with HTTP; Sun, 4 Jun 2017 07:35:59 -0700 (PDT) In-Reply-To: <16f2c369-2758-9bd8-9dcb-5e1b400d2336@elischer.org> References: <16f2c369-2758-9bd8-9dcb-5e1b400d2336@elischer.org> From: blubee blubeeme Date: Sun, 4 Jun 2017 22:35:59 +0800 Message-ID: Subject: Re: [Help] Linux low level data structures < - > FreeBSD low level data structures To: Julian Elischer Cc: FreeBSD current , freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 14:36:00 -0000 Hi Julian My goals are to port the Linux graphics stack over to FreeBSD w/o relying too heavily on the linuxkpi stuff. That's cool for a lot of use cases but it just seems a bit too brittle. It is a very large I understand the task will not be easy but I am willing to do the work, even from scratch if necessary although some help would be appreciated. I've been watching the Linux DRM project grow and while the top levels has changed, it's been a very long time since the actual low level stuff has been changed. Most of the diffs have shown changes in the [linux/driver/gpu/drm] layer which relies heavily on the [linux/include/drm] that does a lot of the heavy lifting here's a link to the latest version files: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm?h=v4.12-rc3 here's a diff of the latest version of the [linux/driver/gpu/drm] : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2 The diffs in the drivers change constantly but the lower level stuff hasn't changed as much. Doing some of the lower level translation to native FreeBSD style data structures then the upper part could be easily migrated, even with something as using AST to translate the headers to their FreeBSD equivalent without worrying about inadvertently breaking something or having major diffs that needs people to actively look at maintaining. That's a high level overview of my plan and what I'd like to achieve. Will it be easy, most likely not but once it's done FreeBSD will be just fine. Hope that helps clarify things for anyone who is interested. Any assistance would be greatly appreciated. Best, Owen On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer wrote: > On 4/6/17 7:07 pm, blubee blubeeme wrote: > >> Hello >> >> Is there anyone on either of these lists that have experience with both >> linux low level data structures and their equivalents on FreeBSD? >> >> For instance the linux header file: >> >> >> which includes the header file: >> >> >> Then looking at that file: >> >> >> >> >> >> > > You are going to have to be a lot more specific about this. > I have worked in several places where they use s shim layer to make Linux > basic services work on freeBSD. > usually a mix of functions, macros and inlines. > However you need to narrow down your questions a bit as the POSSIBLE scope > of your question is too large for anyone to attempt an answer. > > Remember that both systems are POSIX inspired so outside the kernel there > are many more simlarities than one might be led to expect, > but you need to be way more specific. > It's even possible to write kernel code to run on both, but it is usually > domain specific. > > > >> I'll be doing a lot of work trying to find these FreeBSD equivalent of >> these types of files to port some code. >> >> Does anyone here have experience with something like this? Is there any >> other projects that maps these low level data structures from >> Linux <-> FreeBSD, etc? >> >> Best, >> Owen >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://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 Jun 4 16:09:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24B1EB7ED6F; Sun, 4 Jun 2017 16:09:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 C5ED47B015; Sun, 4 Jun 2017 16:09:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (31.89-11-148.nextgentel.com [89.11.148.31]) (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 D507226011D; Sun, 4 Jun 2017 18:09:21 +0200 (CEST) Subject: Re: [Help] Linux low level data structures < - > FreeBSD low level data structures To: blubee blubeeme , Julian Elischer Cc: FreeBSD current , freebsd-ports@freebsd.org References: <16f2c369-2758-9bd8-9dcb-5e1b400d2336@elischer.org> From: Hans Petter Selasky Message-ID: Date: Sun, 4 Jun 2017 18:07:18 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 16:09:25 -0000 Hi Owen, The most comprehensive open-source wrappers for Linux kernel APIs in the FreeBSD kernel is found at: https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-next/sys/compat/linuxkpi The most comprehensive open-source wrappers for Linux kernel APIs in FreeBSD user-space is found at: http://www.freshports.org/multimedia/webcamd I recommend you start with webcamd. Download the source code and look at the sources. See if there is something you think you can improve. It is much easier to debug using GDB and if something goes wrong it can easily be restarted. When you have a working solution for webcamd, try to use the same solution with the kernel. There is no simple 1:1 mapping for Linux APIs to FreeBSD APIs. Take for example linux/list.h . You might think that a list can be re-implemented and mapped to our sys/queue.h. But oh-no. Linux kernel code depends on all the characteristics of list.h, how the structure members are stored and named, and how foreach() macros complete with NULL or non-NULL in the iterator. Further you'll find resistance among the Linux kernel developers to support compilers different from GCC. I recently found a piece of code in a header file, which works with GCC and causes a panic() when compiled with clang. I reported it to one of the Linux kernel team members and they didn't care about it. Even if you get everything compiling it doesn't it will work :-( --HPS On 06/04/17 16:35, blubee blubeeme wrote: > Hi Julian > > My goals are to port the Linux graphics stack over to FreeBSD w/o relying > too heavily on the linuxkpi stuff. That's cool for a lot of use cases but > it just seems a bit too brittle. > > It is a very large I understand the task will not be easy but I am willing > to do the work, even from scratch if necessary although some help would be > appreciated. > > I've been watching the Linux DRM project grow and while the top levels has > changed, it's been a very long time since the actual low level stuff has > been changed. Most of the diffs have shown changes in the > [linux/driver/gpu/drm] layer which relies heavily on the > [linux/include/drm] that does a lot of the heavy lifting here's a link to > the latest version files: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm?h=v4.12-rc3 > > here's a diff of the latest version of the [linux/driver/gpu/drm] : > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2 > > The diffs in the drivers change constantly but the lower level stuff hasn't > changed as much. > > Doing some of the lower level translation to native FreeBSD style data > structures then the upper part could be easily migrated, even with > something as using AST to translate the headers to their FreeBSD equivalent > without worrying about inadvertently breaking something or having major > diffs that needs people to actively look at maintaining. > > That's a high level overview of my plan and what I'd like to achieve. Will > it be easy, most likely not but once it's done FreeBSD will be just fine. > > Hope that helps clarify things for anyone who is interested. Any assistance > would be greatly appreciated. > > Best, > Owen > > On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer wrote: > >> On 4/6/17 7:07 pm, blubee blubeeme wrote: >> >>> Hello >>> >>> Is there anyone on either of these lists that have experience with both >>> linux low level data structures and their equivalents on FreeBSD? >>> >>> For instance the linux header file: >>> >>> >>> which includes the header file: >>> >>> >>> Then looking at that file: >>> >>> >>> >>> >>> >>> >> >> You are going to have to be a lot more specific about this. >> I have worked in several places where they use s shim layer to make Linux >> basic services work on freeBSD. >> usually a mix of functions, macros and inlines. >> However you need to narrow down your questions a bit as the POSSIBLE scope >> of your question is too large for anyone to attempt an answer. >> >> Remember that both systems are POSIX inspired so outside the kernel there >> are many more simlarities than one might be led to expect, >> but you need to be way more specific. >> It's even possible to write kernel code to run on both, but it is usually >> domain specific. >> >> >> >>> I'll be doing a lot of work trying to find these FreeBSD equivalent of >>> these types of files to port some code. >>> >>> Does anyone here have experience with something like this? Is there any >>> other projects that maps these low level data structures from >>> Linux <-> FreeBSD, etc? >>> >>> Best, >>> Owen From owner-freebsd-current@freebsd.org Sun Jun 4 16:44:33 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3328B7F871; Sun, 4 Jun 2017 16:44:33 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 9E0B97BFE2; Sun, 4 Jun 2017 16:44:33 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x22c.google.com with SMTP id f185so10297400pgc.0; Sun, 04 Jun 2017 09:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LeVqF+IUh1tyasfY7OPd69RfRAi0GkR0/oz3o0db69w=; b=hGEiRraVw4W1nAvLSGGuc+p+p0x9b3kbZIK/mVUEEK8EvNEMT2TNKxKyBz+h0pX9jH XccR+StRzmb1lK3eGyGy/L3IPDkfvPqHSv0L3uR8LwqjThBqPhvWkS4580igDa3AoUkv gHD85fcGg82GresA0/96m2Ej+O57FCei35Am/Yskfv9zDm352VTJHoG/SoSHnwkUEnYu ntQIMJVsFdreeHtNkrPkrpvVlWBibAkgoaNDxSriK3LcBRoKf6fKOuF4SMUboDWUqpYp Ycyc4OrXQyfyQN3UdFSki6STLCy0dwWrDESFteq/8HBEVOpxo4tDXnKYUuh4mJJvj7WW GPTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LeVqF+IUh1tyasfY7OPd69RfRAi0GkR0/oz3o0db69w=; b=Ax/bSgSgQHdc9y0cHzCfvrhr9FfnL/1aEvWuaQQBp3iZoeeUAJD6Mxoq17CYcpkjSQ HxREcDTBmn2cC1yMsKHMe89fXyu9hRXtKc2RH0ZZkY4zJp0tea6cpgde67Dmy/2eQhGI ITeO9iQsd+m8Dh/dcxCMPei8OQXxS345/NWrcgsMiyJ/Fb6v9Y8P2PhtxGeChxgjm/62 lqb2ZMPjSYJSTosjevpFVe1bE7C6ng9aKRdN1rB+Cajgbsnz7ORbYyiI4j2rq/uKrVns GZ00J+hwD6ew2gCV63+wqyH94Jz+JEx1DFLzkt9VKn1w0UBst018bdXFgR+TmjaaKfke gwzA== X-Gm-Message-State: AODbwcCFv36N4tbHfRoA9ZvldkPz+v8PvnHEVFcRTjq1X3lY8xnfKlqv 34cgvEiEh9awrM5Ucuz9Cv5+X322/Q== X-Received: by 10.84.215.207 with SMTP id g15mr10346995plj.161.1496594672746; Sun, 04 Jun 2017 09:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.79 with HTTP; Sun, 4 Jun 2017 09:44:32 -0700 (PDT) In-Reply-To: References: <16f2c369-2758-9bd8-9dcb-5e1b400d2336@elischer.org> From: blubee blubeeme Date: Mon, 5 Jun 2017 00:44:32 +0800 Message-ID: Subject: Re: [Help] Linux low level data structures < - > FreeBSD low level data structures To: Hans Petter Selasky Cc: Julian Elischer , FreeBSD current , freebsd-ports@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 16:44:33 -0000 =EF=BC=A0Hans I've noticed these things about Linux. A lot of stuff relies on knowing the internals of the data structures instead of working with the API but I don't want to start all that stuff up. The goal is to lift up FreeBSD w/o tearing down Linux and as u know needing to be glued to the Linux data structures, while they always seem to be in flux is one reason why I want to steer clear from the linuxkpi stuff. I cam across the webcamd thing a while ago, it was written when Linux was not moving so fast if I remember correctly. This is a big challenge but I think once it's up and running it will bring some additional resources to FreeBSD that can bring the desktop world up to snuff with it's server acumen. Thanks for the tips though! Best, Owen On Mon, Jun 5, 2017 at 12:07 AM, Hans Petter Selasky wrote: > Hi Owen, > > The most comprehensive open-source wrappers for Linux kernel APIs in the > FreeBSD kernel is found at: > > https://github.com/FreeBSDDesktop/freebsd-base-graphics/ > tree/drm-next/sys/compat/linuxkpi > > The most comprehensive open-source wrappers for Linux kernel APIs in > FreeBSD user-space is found at: > > http://www.freshports.org/multimedia/webcamd > > I recommend you start with webcamd. Download the source code and look at > the sources. See if there is something you think you can improve. It is > much easier to debug using GDB and if something goes wrong it can easily = be > restarted. > > When you have a working solution for webcamd, try to use the same solutio= n > with the kernel. > > There is no simple 1:1 mapping for Linux APIs to FreeBSD APIs. Take for > example linux/list.h . You might think that a list can be re-implemented > and mapped to our sys/queue.h. But oh-no. Linux kernel code depends on al= l > the characteristics of list.h, how the structure members are stored and > named, and how foreach() macros complete with NULL or non-NULL in the > iterator. Further you'll find resistance among the Linux kernel developer= s > to support compilers different from GCC. I recently found a piece of code > in a header file, which works with GCC and causes a panic() when compiled > with clang. I reported it to one of the Linux kernel team members and the= y > didn't care about it. Even if you get everything compiling it doesn't it > will work :-( > > --HPS > > > On 06/04/17 16:35, blubee blubeeme wrote: > >> Hi Julian >> >> My goals are to port the Linux graphics stack over to FreeBSD w/o relyin= g >> too heavily on the linuxkpi stuff. That's cool for a lot of use cases bu= t >> it just seems a bit too brittle. >> >> It is a very large I understand the task will not be easy but I am willi= ng >> to do the work, even from scratch if necessary although some help would = be >> appreciated. >> >> I've been watching the Linux DRM project grow and while the top levels h= as >> changed, it's been a very long time since the actual low level stuff has >> been changed. Most of the diffs have shown changes in the >> [linux/driver/gpu/drm] layer which relies heavily on the >> [linux/include/drm] that does a lot of the heavy lifting here's a link t= o >> the latest version files: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin >> ux.git/tree/include/drm?h=3Dv4.12-rc3 >> >> here's a diff of the latest version of the [linux/driver/gpu/drm] : >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin >> ux.git/diff/?id=3Dv4.12-rc3&id2=3Dv4.12-rc2&dt=3D2 >> >> The diffs in the drivers change constantly but the lower level stuff >> hasn't >> changed as much. >> >> Doing some of the lower level translation to native FreeBSD style data >> structures then the upper part could be easily migrated, even with >> something as using AST to translate the headers to their FreeBSD >> equivalent >> without worrying about inadvertently breaking something or having major >> diffs that needs people to actively look at maintaining. >> >> That's a high level overview of my plan and what I'd like to achieve. Wi= ll >> it be easy, most likely not but once it's done FreeBSD will be just fine= . >> >> Hope that helps clarify things for anyone who is interested. Any >> assistance >> would be greatly appreciated. >> >> Best, >> Owen >> >> On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer >> wrote: >> >> On 4/6/17 7:07 pm, blubee blubeeme wrote: >>> >>> Hello >>>> >>>> Is there anyone on either of these lists that have experience with bot= h >>>> linux low level data structures and their equivalents on FreeBSD? >>>> >>>> For instance the linux header file: >>>> >>>> >>>> which includes the header file: >>>> >>>> >>>> Then looking at that file: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> You are going to have to be a lot more specific about this. >>> I have worked in several places where they use s shim layer to make Lin= ux >>> basic services work on freeBSD. >>> usually a mix of functions, macros and inlines. >>> However you need to narrow down your questions a bit as the POSSIBLE >>> scope >>> of your question is too large for anyone to attempt an answer. >>> >>> Remember that both systems are POSIX inspired so outside the kernel the= re >>> are many more simlarities than one might be led to expect, >>> but you need to be way more specific. >>> It's even possible to write kernel code to run on both, but it is usual= ly >>> domain specific. >>> >>> >>> >>> I'll be doing a lot of work trying to find these FreeBSD equivalent of >>>> these types of files to port some code. >>>> >>>> Does anyone here have experience with something like this? Is there an= y >>>> other projects that maps these low level data structures from >>>> Linux <-> FreeBSD, etc? >>>> >>>> Best, >>>> Owen >>>> >>> From owner-freebsd-current@freebsd.org Sun Jun 4 13:26:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F2C5B7BD33; Sun, 4 Jun 2017 13:26:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EBAB476764; Sun, 4 Jun 2017 13:26:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from Julian-MBP3.local (125-209-137-153.dyn.iinet.net.au [125.209.137.153]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v54DQfuf086920 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 4 Jun 2017 06:26:47 -0700 (PDT) (envelope-from julian@elischer.org) Subject: Re: [Help] Linux low level data structures < - > FreeBSD low level data structures To: blubee blubeeme , FreeBSD current , freebsd-ports@freebsd.org References: From: Julian Elischer Message-ID: <16f2c369-2758-9bd8-9dcb-5e1b400d2336@elischer.org> Date: Sun, 4 Jun 2017 21:26:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailman-Approved-At: Sun, 04 Jun 2017 20:18:13 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 13:26:50 -0000 On 4/6/17 7:07 pm, blubee blubeeme wrote: > Hello > > Is there anyone on either of these lists that have experience with both > linux low level data structures and their equivalents on FreeBSD? > > For instance the linux header file: > > > which includes the header file: > > > Then looking at that file: > > > > > You are going to have to be a lot more specific about this. I have worked in several places where they use s shim layer to make Linux basic services work on freeBSD. usually a mix of functions, macros and inlines. However you need to narrow down your questions a bit as the POSSIBLE scope of your question is too large for anyone to attempt an answer. Remember that both systems are POSIX inspired so outside the kernel there are many more simlarities than one might be led to expect, but you need to be way more specific. It's even possible to write kernel code to run on both, but it is usually domain specific. > > I'll be doing a lot of work trying to find these FreeBSD equivalent of > these types of files to port some code. > > Does anyone here have experience with something like this? Is there any > other projects that maps these low level data structures from > Linux <-> FreeBSD, etc? > > Best, > Owen > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Jun 4 21:19:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02441BEF8BA for ; Sun, 4 Jun 2017 21:19:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 ABC6EC25 for ; Sun, 4 Jun 2017 21:19:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1122 invoked from network); 4 Jun 2017 21:20:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Jun 2017 21:20:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 04 Jun 2017 17:19:20 -0400 (EDT) Received: (qmail 17605 invoked from network); 4 Jun 2017 21:19:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jun 2017 21:19:20 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 686D4EC805D for ; Sun, 4 Jun 2017 14:19:19 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Help] Linux low level data structures < - > FreeBSD low level data structures Message-Id: <4EAE8582-14C1-4B25-A4E6-2000D8A23F33@dsl-only.net> Date: Sun, 4 Jun 2017 14:19:18 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 21:19:28 -0000 Hans Petter Selasky hps at selasky.org write on Sun Jun 4 16:09:25 UTC 2017: > I recently found a > piece of code in a header file, which works with GCC and causes a > panic() when compiled with clang. I reported it to one of the Linux > kernel team members and they didn't care about it. Even if you get > everything compiling it doesn't it will work I do not know if it would help anyone but I'm aware of one linux distribution for x86_64 that uses clang instead of gcc as the main compiler: OpenMandriva Lx . https://wiki.openmandriva.org/en/3.01/Release_Notes says: > OpenMandriva decided to give a go for a switch to LLVM/clang 3.9.1 as > the default compiler, and finally has replaced GCC. Over 90% of > packages in our main repository are built with LLVM/clang. It reports kernels 4.9.0 and 4.1.18 nrJQL. Downloads are of the current version at: https://sourceforge.net/projects/openmandriva/files/release/3.01/3.01.1/ but there is only the x86_64 variant there. As I understand being clang based started with V3.0 . Notes: There is an earlier clang-based release for i586 (V3.0). (V3.0 was apparently kernel 4.6.5 based.) See: https://en.wikipedia.org/wiki/OpenMandriva_Lx and: https://sourceforge.net/projects/openmandriva/files/release/3.0/ There is a 2015-03-02 release for the Raspberry-Pi 2 but it appears to have been someone's one-off experiment rather than a regular build/release: http://comments.gmane.org/gmane.linux.openmandriva.cooker.devel/4841 It likely predates clang as the main compiler. I have no clue if the said header file's code is valid or not vs. if clang has a problem or not --or some mix. But checking the file's content as used in/for OpenMandriva Lx and the related material in the source for the clang OpenMandriva Lx uses might give additional clues about whatever issues are involved. I've never installed or used OpenMandriva Lx. But if a question of comparison to clang use on FreeBSD vs. Linux ever came up it would seem to be a candidate for use in making the comparison -- at least when amd64/x86_64 is a useful context for the comparison. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Jun 4 22:33:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E058BF118F for ; Sun, 4 Jun 2017 22:33:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660049.outbound.protection.outlook.com [40.107.66.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5C3A3C6B for ; Sun, 4 Jun 2017 22:33:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Sun, 4 Jun 2017 22:33:02 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1143.018; Sun, 4 Jun 2017 22:33:02 +0000 From: Rick Macklem To: Michael Butler , freebsd-current Subject: Re: post ino64: lockd no runs? Thread-Topic: post ino64: lockd no runs? Thread-Index: AQHS3TIwDExU8gwuaE2AQbeUNFuu+6IVSX3x Date: Sun, 4 Jun 2017 22:33:02 +0000 Message-ID: References: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> In-Reply-To: <24b27f3e-f91b-553d-f2c1-e876608e0baf@protected-networks.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: protected-networks.net; dkim=none (message not signed) header.d=none; protected-networks.net; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:iOxBi8SwoUyYpAcDl8unf9qABxUqcZYaLi8vNfZwR3xueNfyKyPQdYUOyVu0AqEwXGM1Z2oySIBG51OkPanrOnOREHnsZ5CGEo9UCcm7/CqCiJImkeEET1PKjmGjC/H+9u3r1MV38flQvx0A+sIYg7iqjIGp+webiJjqEJRplCtUGBRnLLlRmCvAda8nM7llnlHw07+B4Prdcd1ZyYfBQ1f5kBSCLRKGubqbejjPGgao3UjNVofhlvemhoer7lv3W0WMX1lT8x5/v+eXyknmkNlDCg4HUQtTAXZ3BCKAqXGv/LhWvZH/LJgsRkExjYmnnh+HawCvJdtg9aRd7pneFA== x-ms-traffictypediagnostic: YTXPR01MB0192: x-ms-office365-filtering-correlation-id: 4b2356eb-64bc-4dc7-25d3-08d4ab99a925 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(155532106045638); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTXPR01MB0192; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39410400002)(377454003)(86362001)(54356999)(76176999)(9686003)(5660300001)(305945005)(3660700001)(38730400002)(53936002)(74316002)(6436002)(189998001)(478600001)(122556002)(74482002)(6506006)(14454004)(2906002)(33656002)(2900100001)(2950100002)(8936002)(55016002)(102836003)(50986999)(3280700002)(6246003)(77096006)(81166006)(8676002)(53546009)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2017 22:33:02.1743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Jun 2017 22:33:05 -0000 Just fyi, rpc.lockd isn't NFS. It is a separate protocol Sun called NLM and I didn't ever implement it for what I believed were good reasons. Hopefully someone who works with the code can help. Btw, if you don't the locks visible to multiple clients concurrently, you c= an just do your mounts with "nolockd" and avoid running it. Or, you can switch to NFSv4, which does a reasonable job of implementing locking. I might take a look at the code, in case I can spot something obvious, but = I won't bet on it. rick ________________________________________ From: Michael Butler Sent: Sunday, June 4, 2017 8:57:44 AM To: freebsd-current; Rick Macklem Subject: post ino64: lockd no runs? It seems that {rpc.}lockd no longer runs after the ino64 changes on any of my systems after a full rebuild of src and ports. No log entries offer any insight as to why :-( imb From owner-freebsd-current@freebsd.org Mon Jun 5 07:02:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA591BF83EF for ; Mon, 5 Jun 2017 07:02:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 6DADF73976 for ; Mon, 5 Jun 2017 07:02:14 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 6658C260872; Mon, 5 Jun 2017 09:02:12 +0200 (CEST) Subject: Re: [Help] Linux low level data structures < - > FreeBSD low level data structures To: Mark Millard , FreeBSD Current References: <4EAE8582-14C1-4B25-A4E6-2000D8A23F33@dsl-only.net> From: Hans Petter Selasky Message-ID: Date: Mon, 5 Jun 2017 09:00:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <4EAE8582-14C1-4B25-A4E6-2000D8A23F33@dsl-only.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 07:02:15 -0000 Hi Mark, Mandriva was a really god hint. Let's see how it goes: https://issues.openmandriva.org/show_bug.cgi?id=2176 --HPS From owner-freebsd-current@freebsd.org Mon Jun 5 09:34:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25D6ABFA7C0 for ; Mon, 5 Jun 2017 09:34:46 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 063BF77751 for ; Mon, 5 Jun 2017 09:34:46 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 02604BFA7BF; Mon, 5 Jun 2017 09:34:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 001F4BFA7BE for ; Mon, 5 Jun 2017 09:34:45 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:375::1:5]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF8E677750 for ; Mon, 5 Jun 2017 09:34:45 +0000 (UTC) (envelope-from Alexander@leidinger.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1496655253; bh=qNkiwjci0lpOGvkEsXlBjEv2rDr/ZswD0mpShLzaCO4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ZVX4S+Ud+s+O080GAT17VS4Ay9nViTAnjPJFWHt0Nd/UshjpU6gtwmJ2o2ltm9Gs1 S2TFTeeauBT2lQKlyqYOemVQQt6NGdM/jn3z1Tp9bQau+laclXnO1iRhCSyeARemzx nUzrJIEzy9GsVxTmOv1xEo4BsWQeNlpcWzETtBGG4YFRkXaZ4OW3AyPWu+Nky72VO8 Xajv0QHErWnnl8m/sUUmzVWVy6zb5PdoQVJkkRpocmvzCJ1FVvE+4IZF8K7BKi1DNB /ydd33JYUVL0XGcCk++Dm1LLXBFRXQN6xdCgDG7bh4wuddfDk1qDShBEZp+oWOtqtn tfim5C4hvppqQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1496655282; bh=qNkiwjci0lpOGvkEsXlBjEv2rDr/ZswD0mpShLzaCO4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iJxM0ED9GPozbw7fcdrhdKnBIPHxB8X8A3HpD39y1xs7P8vWRfsDrhYL1Yp4ROflD 6l0PAeFT2++yEdv85BqAuJJZKBNCzt8XmDW9jEjGWZLblapkmx2MH3fZqtiVvo3uan P45osibTfsVQg6JpCH+Tc2MftvpdDCAelqGd80n0wlmQ1+mMTe4Jul/686Ec7r1KBk IjyDqoCDF/wrPcArF8huKS5mVJZVtrnuMtbjmyLuRkrFlf4fpK5NhRtCis5KldiFIZ XmMtOWXKnbtgTAPekZ4KM6PBC7YptKFi9h6nuoSDfifoPEGVAoC3MIRHQmDeIhaM7a bMvKnrQl4M5TA== Date: Mon, 05 Jun 2017 11:34:12 +0200 Message-ID: <20170605113412.Horde.RZna3Dra3jMHzoVyzHFOKJR@webmail.leidinger.net> From: Alexander Leidinger To: Bryan Drewery Cc: current@freebsd.org Subject: Re: old syslog (jail) and new kernel = 100% CPU References: <20170604140924.Horde.oGvD2didLbdx2PCsGHE3gDi@webmail.leidinger.net> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_L0DNC3SbHwWIukV19wacnUv"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 09:34:46 -0000 This message is in MIME format and has been PGP signed. --=_L0DNC3SbHwWIukV19wacnUv Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Bryan Drewery (from Sun, 4 Jun 2017=20=20 14:38:07=20-0700): > On 6/4/17 5:09 AM, Alexander Leidinger wrote: >> Hi, >> >> new kernel (surely r318877 and later) and old syslog in a jail =3D NOK. >> > > What branch and revision is the syslogd? From my understanding the bug > exists in a head version of syslogd only, maybe MFC'd to stable/11, but > not released. If it was MFC'd we need to fix it before the 11.1 release. This was a syslogd from head for sure. So the issue was that for an intermediate period of time a bug was in=20=20 syslogd=20in head which was causing this, and if I would have upgraded a=20= =20 system=20were the jail would have been head from before the or after the=20= =20 bug,=20then I wouldn't have noticed it? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_L0DNC3SbHwWIukV19wacnUv Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJZNSWUAAoJEKrxQhqFIICEb5UP/0vNAT+Zor2JhfGVL8g95jgC Ki4yIpK7rI2LV144r7ZQBTPNwT7u/gqfcPUfSuRmqkfy09csvBQmoL1O/3vUMRWu /A5+o31TVKojnvV/SbgFpVZDuFi3tXxxKClXjgMi3sDDDDa/kz0POIgzLlwsvhFN p/7uoU++b/rxtkh8I6HJoywVMPedjcV+N76XVrZPkdQ1GQYIB63fz8CA6vIW4xjf W1DLHmlczrrLZwSG+SIvYXPwuMHwQ5lhwqsx7XQTQUCD9x9WyDXYwlT/JM0sMf3F dc1CmF2Da7xqqBC4k5cyAiAmDdJL7ArLOO0S4g/qvZch8a81FkoKjUk48tcyFf8w 9T5l50x4gACNAvF729B3oVeG+XezKLzN5bxkFn40z8atJUG8y2pqMmLYlyj2kPPt CH5g8/E9KQnrJ9e8RvQ6blbbxrXwzPdONpFOeejaRDFBM2JXvHmw7Z6SIy6pmFQ4 1Et/G9/OtA+d1RuRkNp7MZF1fFkl7WYy40RmKS70ID3oXFk8nwHGCn13FBnKKB3I kIcujKg/Tkj92I6m1Uzv5ewS/Z3tVNe3RQk6XfNMjfS4S1It1Y7EDk8w8+8Rw0vA 8d6bW+24zrLv/qu5hhG4b3x8xoV0aJaYXIuTz/7NAY7+DHJHwvTf3b2Qzh93M0Mr ZsobHc2kHew7uZU0p9GX =ATaw -----END PGP SIGNATURE----- --=_L0DNC3SbHwWIukV19wacnUv-- From owner-freebsd-current@freebsd.org Mon Jun 5 15:21:13 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10CC1AFB85C for ; Mon, 5 Jun 2017 15:21:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DECFA83875 for ; Mon, 5 Jun 2017 15:21:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id DE28EAFB85A; Mon, 5 Jun 2017 15:21:12 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDCDFAFB859 for ; Mon, 5 Jun 2017 15:21:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD5E183874; Mon, 5 Jun 2017 15:21:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id DB38A3761; Mon, 5 Jun 2017 15:21:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 970F91C9D; Mon, 5 Jun 2017 15:21:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id sRZ57277xoi5; Mon, 5 Jun 2017 15:21:01 +0000 (UTC) Subject: Re: old syslog (jail) and new kernel = 100% CPU DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 8A7411C98 To: Alexander Leidinger Cc: current@freebsd.org References: <20170604140924.Horde.oGvD2didLbdx2PCsGHE3gDi@webmail.leidinger.net> <20170605113412.Horde.RZna3Dra3jMHzoVyzHFOKJR@webmail.leidinger.net> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Mon, 5 Jun 2017 08:20:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170605113412.Horde.RZna3Dra3jMHzoVyzHFOKJR@webmail.leidinger.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SP64G9wIhf6PrHHQwVATuCaMUlPokwHeL" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 15:21:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SP64G9wIhf6PrHHQwVATuCaMUlPokwHeL Content-Type: multipart/mixed; boundary="Gr62bVioEttHrT1E6krMgGITWVhfwDTFE"; protected-headers="v1" From: Bryan Drewery To: Alexander Leidinger Cc: current@freebsd.org Message-ID: Subject: Re: old syslog (jail) and new kernel = 100% CPU References: <20170604140924.Horde.oGvD2didLbdx2PCsGHE3gDi@webmail.leidinger.net> <20170605113412.Horde.RZna3Dra3jMHzoVyzHFOKJR@webmail.leidinger.net> In-Reply-To: <20170605113412.Horde.RZna3Dra3jMHzoVyzHFOKJR@webmail.leidinger.net> --Gr62bVioEttHrT1E6krMgGITWVhfwDTFE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/5/2017 2:34 AM, Alexander Leidinger wrote: >=20 > Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07= > -0700): >=20 >> On 6/4/17 5:09 AM, Alexander Leidinger wrote: >>> Hi, >>> >>> new kernel (surely r318877 and later) and old syslog in a jail =3D NO= K. >>> >> >> What branch and revision is the syslogd? From my understanding the bug= >> exists in a head version of syslogd only, maybe MFC'd to stable/11, bu= t >> not released. If it was MFC'd we need to fix it before the 11.1 relea= se. >=20 > This was a syslogd from head for sure. >=20 > So the issue was that for an intermediate period of time a bug was in > syslogd in head which was causing this, and if I would have upgraded a > system were the jail would have been head from before the or after the > bug, then I wouldn't have noticed it? >=20 Yes, that's my understanding. So it's ultimately a non-issue for releases since it is just a temporary issue on head. --=20 Regards, Bryan Drewery --Gr62bVioEttHrT1E6krMgGITWVhfwDTFE-- --SP64G9wIhf6PrHHQwVATuCaMUlPokwHeL 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 iQEcBAEBAgAGBQJZNXbPAAoJEDXXcbtuRpfPb+gH/i7crE/w86MoZnm5dz0em3xm tzqkIA+velc8EN8ECV6XHxcp3FZpbUWyug9oIKFiqHovoHH1eLqfHuUKbNwKd4Zf zi2IjsOuOjq8TK4wZBWwP04k/i5br3h3RPnkNjcMJS0ctZbl8Y5Ox4wZOFvSO6BP awnqvsbkID6EjBI3hgliRG+noQYaxI5h5KqFQjqLA2dbc55yEdoA1ru8w+D5vgBT dfLdKsQ31QUjhIPbhzWGsBQ4ay9O0a5458csHWCyOcSSVWcTKGONzMgLJkrPtTDk eczgx+1yLuqQ+Uf1RcFBu3aoqAgLZjomUjducikGCq3XFpBk6VT/hRvSBQFtYYw= =rpGq -----END PGP SIGNATURE----- --SP64G9wIhf6PrHHQwVATuCaMUlPokwHeL-- From owner-freebsd-current@freebsd.org Mon Jun 5 15:53:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E870FAFC1DD for ; Mon, 5 Jun 2017 15:53:53 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BE99784A72 for ; Mon, 5 Jun 2017 15:53:53 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BAC0EAFC1DC; Mon, 5 Jun 2017 15:53:53 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA534AFC1DB for ; Mon, 5 Jun 2017 15:53:53 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 83BAC84A71; Mon, 5 Jun 2017 15:53:53 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id w69so21111719pfk.1; Mon, 05 Jun 2017 08:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=jXBXIthn9Fu3/crMZRhkqaVMnbmz4StHQfIh20AUpm8=; b=i9n5XhQIbIE3njYPuHrIJVrKSrSvHEMJPVys9eIReeZdEHZeuvvQWpedR564bT+Td2 QZuqPZV8k7hx0uzdog0wQgOWOPZg20btU2OhmrQOmT+LbCyuKk5Vs3bt6ClZt0vvJm42 yRq0zAmlEzH8UoAR43xZMEAFk2P+AC0QCaHIS/qkAPf4fl+uHhNvltyI0gYt6c1fkwhm mjC8OZcDMpakISiB42/m2RFjTj4kolihly7dez0zlA5sEBmyZmiAxeuN1oI+u30RQ7Lq DrmHvY/WpRdS1mq1vvf3Nd+6GromeeDAzCfVi8i3gbz9pI8ZRLT/i3DRxsrwtZW9Ayke ACTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=jXBXIthn9Fu3/crMZRhkqaVMnbmz4StHQfIh20AUpm8=; b=Z3IuemJZq2Gc9bg7h7rFSzHnBx6oxX1AWi1x4NyP71M82weikQxwI+NwK1iIxdZ5I+ cH3cRAk00dec7ZBbDiy2Sslzwj6EOqkyGkIT/VQxHzC7hfNEprxo896jksQbjnThyVOx TSUYdKjxSysd/lvm7qSsQyh5RAmvGL0gY/lkMp2YONcT+/fxOjlM4CW9F/gK6FUzhq6o 9Csflel4vbLXNzyg0K1FKhKheIrAu4LhM4xfHNPAKT6+YNf/LSTH61k1Kzf4k7hvnhl9 UUYpMY0RJC9d2MJgjfr1lLnQPLePBfIv03pnWgtUKr3qVDu53gJSj6QE6LDFTx5ejsZo i77Q== X-Gm-Message-State: AODbwcBfPcUW3D6fWvLNXFlf7FaMSftDLcHFjZNQkBHNMfQR89zwfzha DPudW36rYui6OU78rUw= X-Received: by 10.99.0.209 with SMTP id 200mr22002727pga.208.1496678032651; Mon, 05 Jun 2017 08:53:52 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id h84sm61411572pfh.45.2017.06.05.08.53.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Jun 2017 08:53:52 -0700 (PDT) Subject: Re: old syslog (jail) and new kernel = 100% CPU Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C4C13FEC-47ED-445C-8D76-DDD66E658431"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Mon, 5 Jun 2017 08:53:50 -0700 Cc: Alexander Leidinger , current@freebsd.org Message-Id: <55114361-9212-49AE-A3FF-7691CADB2367@gmail.com> References: <20170604140924.Horde.oGvD2didLbdx2PCsGHE3gDi@webmail.leidinger.net> <20170605113412.Horde.RZna3Dra3jMHzoVyzHFOKJR@webmail.leidinger.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 15:53:54 -0000 --Apple-Mail=_C4C13FEC-47ED-445C-8D76-DDD66E658431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 5, 2017, at 08:20, Bryan Drewery wrote: >=20 > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: >>=20 >> Quoting Bryan Drewery (from Sun, 4 Jun 2017 = 14:38:07 >> -0700): >>=20 >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote: >>>> Hi, >>>>=20 >>>> new kernel (surely r318877 and later) and old syslog in a jail =3D = NOK. >>>>=20 >>>=20 >>> What branch and revision is the syslogd? =46rom my understanding the = bug >>> exists in a head version of syslogd only, maybe MFC'd to stable/11, = but >>> not released. If it was MFC'd we need to fix it before the 11.1 = release. >>=20 >> This was a syslogd from head for sure. >>=20 >> So the issue was that for an intermediate period of time a bug was in >> syslogd in head which was causing this, and if I would have upgraded = a >> system were the jail would have been head from before the or after = the >> bug, then I wouldn't have noticed it? >>=20 >=20 > Yes, that's my understanding. So it's ultimately a non-issue for > releases since it is just a temporary issue on head. Yes. syslogd was refactored on ^/head. Some of the refactoring caused = the issue Alexander brought up. The changes were never backported = though, so the concern you had in the previous message isn=E2=80=99t = something to be worried about, since the code hasn=E2=80=99t seen the = changes the ^/head copy has. Cheers! -Ngie --Apple-Mail=_C4C13FEC-47ED-445C-8D76-DDD66E658431 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 iQIcBAEBCgAGBQJZNX6PAAoJEPWDqSZpMIYVIpcQAMDdZFDCAwcwANLA77BOCuio vaGTs7X/T4NgMFAVeLWfGzbvzplB9uVVGlPxLdcAiYMNB9JcXy35g2XpVsVSQMCe MAzpn4JKVX2HAdbXWTIg+eii3DSAg4/P2pMwkFiM3Zf/fxBMUiI68+RbMoeNmUVU HFl7CkyrwjKV5YBY6X2F6EBhTkPNHiIkjRbtqcXM7Ly2jOtnDzOUiOjeC40TcuIv NmU2nv61DgAJSvFYZgEUNkDIFUrWc9JzOI0v/C6wE7bdDhu5A/sxJpBE/jFFWnIV nTU6vkWtARt6geu9WyTAeYGMQstVrya9ey53H/5Dd365RDEhlJ941d6td9N+0FpN GZPc6BYLVb+h9X/l0wfBECumfb6eJhtNXIMQmvWWp68LtrC3eO67c03lZH1rXI7D Sy60CBp4cJAkXk0BJ+jCIphkuHNLdtVsrfIChSZfFcPy/qMsEq2Snw5g0TY8Cxg8 WsnJfFG6tFU+/cbM9eWX9f2gk8lMgdrPmF/j0UBk69lDMoTUrSQt9eMYYNMHmdMK GEp3MU6tt0QeVQnJeOAjyGTJyte+kuplI6HAOMJ5ecVPPRXj8Q9GhaQNP6ICm6dt jbDo3froY0nqy1Sc6P/vZj/IXaozLf0PTs/JlAfuoB1/NpTUwbDM5Sqc+IP5wneT /PRk2NR0ojVnRYe2P/xK =JrUQ -----END PGP SIGNATURE----- --Apple-Mail=_C4C13FEC-47ED-445C-8D76-DDD66E658431-- From owner-freebsd-current@freebsd.org Mon Jun 5 16:03:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4B9FAFC709 for ; Mon, 5 Jun 2017 16:03:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 78B2B2E5 for ; Mon, 5 Jun 2017 16:03:07 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id v55G2sg7018575 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Jun 2017 12:02:54 -0400 (EDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.14.9/Submit) id v55G2rFV018574; Mon, 5 Jun 2017 12:02:53 -0400 (EDT) (envelope-from ken) Date: Mon, 5 Jun 2017 12:02:53 -0400 From: "Kenneth D. Merry" To: Hans Petter Selasky Cc: Tomoaki AOKI , freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170605160253.GA17376@mithlond.kdm.org> References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 05 Jun 2017 12:02:54 -0400 (EDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 16:03:07 -0000 On Sun, Jun 04, 2017 at 09:52:36 +0200, Hans Petter Selasky wrote: > On 06/04/17 09:39, Tomoaki AOKI wrote: > > Hi > > > > One possibility would be to make it MD build-time OTIONS, > > defaulting 1M on regular systems and 128k on smaller systems. > > > > Of course I guess making it a tunable (or sysctl) would be best, > > though. > > > > Hi, > > A tunable sysctl would be fine, but beware that commonly used firmware > out there produced in the millions might hang in a non-recoverable way > if you exceed their "internal limits". Conditionally lowering this > definition is fine, but increasing it needs to be carefully verified. > > For example many USB devices are only tested with OS'es like Windows and > MacOS and if these have any kind of limitation on the SCSI transfer > sizes, it is very likely many devices out there do not support any > larger transfer sizes either. I agree that I'd like to see a tunable. We've been using a MAXPHYS value slightly larger than 1MB at Spectra for years with no problems, but then again, we're only running on newer hardware. If we keep DFLTPHYS the same (64K) or come up with another constant that is defined to 64K, the way the da(4) and sa(4) handle things will keep most older controllers working properly. Here is what da(4) does: if (cpi.maxio == 0) softc->maxio = DFLTPHYS; /* traditional default */ else if (cpi.maxio > MAXPHYS) softc->maxio = MAXPHYS; /* for safety */ else softc->maxio = cpi.maxio; softc->disk->d_maxsize = softc->maxio; cpi is the XPT_PATH_INQ CCB. The maxio field was added later, so older, unmodified drivers that haven't set the maxio field default to a 64K I/O size. Drivers for some of the more common SAS and FC hardware set maxio to a value that is correct for the hardware. (e.g. mpt(4), mps(4), mpr(4), and isp(4) all set it correctly.) As Warner pointed out, the way ahci(4) works is that it sets its maximum I/O size to MAXPHYS. The question is, does all AHCI hardware support arbitrary transfer sizes? Is there a way to figure out what the hardware supports, and if not, we should probably default it to 128K instead of MAXPHYS. Tape drives are another related issue. Tape block sizes up to 1MB are pretty common. LTFS allows for blocksizes up to 1MB. You can't currently read a tape with a 1MB blocksize on FreeBSD without bumping MAXPHYS and having a controller and tape drive that can handle the larger blocksize. The sa(4) driver has the same logic as the da(4) driver for limiting transfer sizes to the smaller of MAXPHYS and cpi.maxio. The sa(4) driver gives the user some tools for figuring things out: {sm4u-1-mgmt:/root:!:1} mt status -v Drive: sa0: Serial Number: 101500520A --------------------------------- Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual: 0 Reported File Number: 0 Reported Record Number: 0 Flags: BOP --------------------------------- Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 1048576 bytes Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes Maximum block size supported by tape drive and media (max_blk): 8388608 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 1048576 bytes On this particular FreeBSD/head machine, I have MAXPHYS set to 1MB. The controller (isp(4)) supports ~5MB I/O sizes and the drive (IBM LTO-5) supports ~8MB I/O, but MAXPHYS is set to 1MB, so that is the limit. I have considered changing the sa(4) driver to not use physio(9), and instead use a custom allocator to allow reading and writing tapes with blocksizes up to what the hardware (combination of tape drive and controller) allows. I haven't gotten around to it yet, because bumping MAXPHYS works well enough in most cases. It also has a nice side effect of allowing unmapped I/O. The pass(4) driver limits I/O sizes in the same way as the da(4) and sa(4) drivers for CCBs sent via the blocking (CAMIOCOMMAND) ioctl, but for CCBs sent via the asynchronous API, the only limit is the controller (cpi.maxio) limit. The latter is because the buffers for the asynchronous interface are malloced. If it were possible to send arbitrary sized, unmapped S/G lists, then we could convert the asynchronous pass(4) interface to do unmapped I/O. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@freebsd.org Mon Jun 5 17:31:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACEFBAFDC2F for ; Mon, 5 Jun 2017 17:31:51 +0000 (UTC) (envelope-from a.n.us@ieee.org) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 727673557 for ; Mon, 5 Jun 2017 17:31:51 +0000 (UTC) (envelope-from a.n.us@ieee.org) Received: by mail-vk0-x229.google.com with SMTP id p62so34889186vkp.0 for ; Mon, 05 Jun 2017 10:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wndz4mXKS4llL15Yf8w4CSrWAbKZkSj8H0wIFE0LMsM=; b=l4PWmSUBpjmB8nJweCItakd1SHTI1Th/Zc9h5GoDKj/GC9lZqn/KD1vDZAeTpb2s7X RizM7a4pIIJCNuTX4xHraUF93cIaB4VLlr82DnoGBHasuPIxWjxrgbp5+6C4FDwCuiQJ LmBWw7tYagWjMpFFVXX5qmNdb4WPGlVqCCMnsTb3pNQCnupWbRSLTT9mWuE41X0mjPMa G8M1CAJfQZF7l18PrfBGRItTWZoJ3JUNjipRmMY0EKDUETpIEv891QzrPtuQjdoe8xL1 //fE59SaOffWouAZ6babwYvkPATL8hEqXhJkIGRgByri8sJFih+8UAkoo3dUYzjLkD8T eXfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wndz4mXKS4llL15Yf8w4CSrWAbKZkSj8H0wIFE0LMsM=; b=oDFTO1SAmhxvFUMKSkEYjdR0RpV8X3pLxoLNzuIPXayoJuw3mtOgACtzLxCIDuxZfJ atkFnSsL+vwI5ALCie1tKMSHlO97nfqA7gV6w/aStqMYtOjQLU9ytzzG7l85igojIw2h be3qPF1EqAhKFFK+l/PFWGXj3f44BWDWsgxN7m7MbB0C34pUXqXrCNP4NLycBQQQjhcf RDdqGIUBfWoWnWlYXHx512ymI8M8TaSGU9OSZhunKoAgSOoWjIgSR42r5OT2hMvHkLuH /EjCmWoukIZt9l3cQEegxVEdJJ698QvfS/amQm2txdy01v/pmIHsoJImuLfzU79KDiYI Os5g== X-Gm-Message-State: AODbwcDADXgkzzrU4E9DPH1ZxohNJOBb01cRr39mnvUfZij3msYYlP6R G9D/Z58ezauxZAMP63aQ/EAthAku+6X4 X-Received: by 10.31.151.70 with SMTP id z67mr10803893vkd.108.1496683910349; Mon, 05 Jun 2017 10:31:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.56.145 with HTTP; Mon, 5 Jun 2017 10:31:10 -0700 (PDT) From: Andy Neustadter Date: Mon, 5 Jun 2017 13:31:10 -0400 Message-ID: Subject: Boot CURRENT without efi To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 17:31:51 -0000 Hi: I have an older HP desktop that does not support USB boot or UEFI. Is it possible to use this machine with 12-current using GPT? Any help or pointers to info would be greatly appreciated. Thanks in advance. From owner-freebsd-current@freebsd.org Mon Jun 5 17:53:27 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48070AFE238 for ; Mon, 5 Jun 2017 17:53:27 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 2437E641BF for ; Mon, 5 Jun 2017 17:53:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 233D1133A9 for ; Mon, 5 Jun 2017 17:53:25 +0000 (UTC) Subject: Re: Boot CURRENT without efi To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <5040e292-aedd-2fe3-67e7-9b0e440fc662@freebsd.org> Date: Mon, 5 Jun 2017 13:53:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jB5AMvLC7jwN62qVIpjGnOHu4gElcaJ3b" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 17:53:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jB5AMvLC7jwN62qVIpjGnOHu4gElcaJ3b Content-Type: multipart/mixed; boundary="Ceis3B5lGrGWp5xvJ5JpjvKL0W8f9gsH3"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <5040e292-aedd-2fe3-67e7-9b0e440fc662@freebsd.org> Subject: Re: Boot CURRENT without efi References: In-Reply-To: --Ceis3B5lGrGWp5xvJ5JpjvKL0W8f9gsH3 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-06-05 13:31, Andy Neustadter wrote: > Hi: >=20 > I have an older HP desktop that does not support USB boot or UEFI. Is > it possible to use this machine with 12-current using GPT? Any help > or pointers to info would be greatly appreciated. Thanks in advance. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 If your BIOS does not actively interfere, then yes, you can boot from a GPT partitioned disk in legacy mode, without UEFI. If it doesn't work, the installer still supports MBR. --=20 Allan Jude --Ceis3B5lGrGWp5xvJ5JpjvKL0W8f9gsH3-- --jB5AMvLC7jwN62qVIpjGnOHu4gElcaJ3b 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) iQIcBAEBAgAGBQJZNZqUAAoJEBmVNT4SmAt+JusP/3G1Kd1WVeASyjel6LjjCVrR zWCJB9QBcF3Xav0x+F3M6eL6xaLKUW6i9A5SkKccEiIUu0VnFFvUwe7sdWxiUORN SfRtaQ74++B4XReLgFmRnBQ+GXrKfLRntf39PujTAFySZFQBwv6rqoyNxEDtIFCG 1mCrpFrrOAqELd6E/ebp2kL3ECKnokR7JiasMAcz4QN9m1LSJUAHOfvBSZQ8x5cv uYKkzt6YqkB6n0enBEMktRrTLu9maGNnkvF6Ennaoupln6NvcElCx8ve2j2Hjn+O ZBsaOz2R0HgL4TicATB5ivYGHzE0aVRYgkNOOdBJLSIhbdCc8PyaWbM0m5Z96Q3X 6F9S0KHNPWSSScsg10Ib4/D9J7qSnVu3J+AOZROpCMi5Kv8KHcYINH+ZHN0hJMM8 js9rRV84P1JDKVdoYqXXtnJPhUT80PI4nPpYkvqCe0eKDQU8HRLDr7fpie6A/vsB UHIOou4aacgrxzT3AlQsW7wF8g7GnVShnEy3Vu2xsBud1b2mUg0bjuVoeRSUzxeH nT7qc91lDRiQYvfNP62EmL9gmzdCoCV7TlMlHomIjlAyBowyiP4uHGiFUxnAvZgO bSfw8zNmFfsfYaU7OzgNPX1dIHR8/PfoZtnKQ2ItBZok4oKcsmioeNTgAzPn7M99 gF2vxkQJmL3h3q/jKJuE =TYEt -----END PGP SIGNATURE----- --jB5AMvLC7jwN62qVIpjGnOHu4gElcaJ3b-- From owner-freebsd-current@freebsd.org Mon Jun 5 18:17:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44A24AFE990 for ; Mon, 5 Jun 2017 18:17:15 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 C510C64EB4 for ; Mon, 5 Jun 2017 18:17:14 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id n195so82597534wmg.1 for ; Mon, 05 Jun 2017 11:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=T4wpSQ0OD3EGGhTstZ025ZIC7p3/UXC4OiQ/uh27MUg=; b=ny+fk3UdQOWiIqozBdQPIcMJV4Vzwt6t83xZpMpGKWb/ZwKxzq7ectGL+EV3XS99CG 3vKK31+pr7P3pqN6osSFgq5/3xsP09JsffQbQ1U8To+DaCmjU8xdFmvYQTbMmPOjPfCm zYfSUy91ja/wKsbQXOIeDZH2I4/Esgg42a8WTiRETSyhCQJKkiwTfTUK/YGF+Yrr4gNm stwMaB9nPxCw5FQZd0nAtpHMpAMiTO5HO1Ct4HjMm4jfU3IG2dnCUoD9VO+6CvZ0uJk3 mX+rD5NK4lemWDHRbvIPExZqwZcT+WEdybUnbu28C/3kRSoMEDNSk4+4MJ48bWz7L6zf Hx+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=T4wpSQ0OD3EGGhTstZ025ZIC7p3/UXC4OiQ/uh27MUg=; b=IV/mhYOdcsOXEP1sti41JL+KHwm1clMe4XDV4rBshD7hUEYcLvEqVmX7JKpxCNFAew PqUYo7NJz9oRhaL1wtQWuAiWaQSEEq2yg2iceLT2LDcKXkL3/oAsnuYICVF0Oy8oGt3v kDVNDZOAFl3amhrGt896lKPudHyRfG4VmleQaP/A3rpNnwD++7wtfcu9yqWm4zCScjwy e6I+mqfB98lueW1TQq90A+SEgk2NU2RkbOU4Ldl1+N4u2kprCfS/U7JEZxUt6wHreFHM ns2ZqJ2Ps9jOhJ+S12/cDYmbPQ+NWzfDvfHxp4HY7WetbJxRo4tzv1H1EylWe4MHh20k iHpA== X-Gm-Message-State: AODbwcBseMQubZSJwhwROQFSdxK1gSqOZa4jxAfZdsaSAcxpiFp7HmMO bykt7+4lEOE3W8KS X-Received: by 10.28.20.14 with SMTP id 14mr9169441wmu.52.1496686632733; Mon, 05 Jun 2017 11:17:12 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id a127sm2365262wme.28.2017.06.05.11.17.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 11:17:11 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 5 Jun 2017 18:49:30 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Hans Petter Selasky Cc: Tomoaki AOKI , freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170605174930.GA6259@brick> Mail-Followup-To: Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 18:17:15 -0000 On 0604T0952, Hans Petter Selasky wrote: > On 06/04/17 09:39, Tomoaki AOKI wrote: > > Hi > > > > One possibility would be to make it MD build-time OTIONS, > > defaulting 1M on regular systems and 128k on smaller systems. > > > > Of course I guess making it a tunable (or sysctl) would be best, > > though. > > > > Hi, > > A tunable sysctl would be fine, but beware that commonly used firmware > out there produced in the millions might hang in a non-recoverable way > if you exceed their "internal limits". Conditionally lowering this > definition is fine, but increasing it needs to be carefully verified. > > For example many USB devices are only tested with OS'es like Windows and > MacOS and if these have any kind of limitation on the SCSI transfer > sizes, it is very likely many devices out there do not support any > larger transfer sizes either. FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed that both issue 1MB requests. I wouldn't be surprised if they avoided doing that for older devices, depending on eg the SCSI version reported by device. From owner-freebsd-current@freebsd.org Mon Jun 5 18:34:52 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DF7EAFEF7C for ; Mon, 5 Jun 2017 18:34:52 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36BDA65885 for ; Mon, 5 Jun 2017 18:34:52 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OR300D004K7OD00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Mon, 05 Jun 2017 17:34:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1496684078; bh=erqoh4aqc9sIApWJYU4RkcrNqvFJ45izcKFSaY+ONf4=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=dj/1812hMlVKNZiF/IOTB6VLEGnBo5TZDZtuHMo1EE3LhDOQ0kso8msBzZutZM71/ zaluLVPTAEuWjVVfR8AG2qukb6N3LTmbbWAZF0ckv8IQGtPmNe+VJuVTBnDMliOB7L 51PV8ik1caEoQ3ixXZOuuLo5LkxndoUk2ETNbDTvmEHWG73Tac7rVzi9G6lARM4fYc KmED3R0zak0v54cGbDBXc4RBN9Jv9rbwjkI1LQuIcjQvdgMA4X+5DbYRwYEjU9TdTn oPe4EEly31SwU2G0+Z4lXBTLyaQMwYEiEG0xNnJxLjYiu9/3fNk26jG5ZC5QfzxOSz 8Grteov6VOsbA== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OR300ONI4TMTD50@st13p35im-asmtp002.me.com>; Mon, 05 Jun 2017 17:34:36 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-05_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1706050332 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Boot CURRENT without efi From: Toomas Soome In-reply-to: Date: Mon, 05 Jun 2017 20:34:33 +0300 Cc: freebsd-current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: To: Andy Neustadter X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 18:34:52 -0000 > On 5. juuni 2017, at 20:31, Andy Neustadter wrote: >=20 > Hi: >=20 > I have an older HP desktop that does not support USB boot or UEFI. Is > it possible to use this machine with 12-current using GPT? Any help > or pointers to info would be greatly appreciated. Thanks in advance. GPT does not require UEFI, BIOS boot will read the pmbr and should = behave just as with MBR partitioning. rgds, toomas From owner-freebsd-current@freebsd.org Mon Jun 5 21:31:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9519FB7AB8C for ; Mon, 5 Jun 2017 21:31:35 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (mail.made4.biz [195.154.164.132]) (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 504186E974 for ; Mon, 5 Jun 2017 21:31:34 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freebsd.org ; s=20170531; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=VP8P84UU8QMeZB+7noUjqcN8BK1aQVOp9Pv8uAEiPNE=; b=TNZTz3sE7q+KurFTpjKcADYv0P CwtUYL8Q+z4i11v/degWXi0mC6K2i8W4Y47+zuw6AGm8qSQllqxFhTSX65nbk+47h9Vo84PYGM/9B UueOCtpIarB0uZPQKXAftmVRcrqsn5HJ7dyOoWucWnFSh+9Fi43+SCuecBvVsGOOLDts=; Received: from 2a02-8428-011a-ed00-ea2a-eaff-fe8d-676f.rev.sfr.net ([2a02:8428:11a:ed00:ea2a:eaff:fe8d:676f] helo=rosetta.dumbbell.fr) by mail.made4.biz with esmtpa (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dHzav-000ExJ-VS; Mon, 05 Jun 2017 23:31:25 +0200 Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT To: Tim Kientzle Cc: FreeBSD current References: <3348A21B-754F-41FE-A94D-C3F53AD691C8@kientzle.com> From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Organization: The FreeBSD Project Message-ID: Date: Mon, 5 Jun 2017 23:31:22 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <3348A21B-754F-41FE-A94D-C3F53AD691C8@kientzle.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Svuka5O2Sm096eBRpIcWkqOLCTKp7UH2g" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Jun 2017 21:31:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Svuka5O2Sm096eBRpIcWkqOLCTKp7UH2g Content-Type: multipart/mixed; boundary="LN7J2IufhC6SK8NwrIC4cK5coDlxNSWxL"; protected-headers="v1" From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= To: Tim Kientzle Cc: FreeBSD current Message-ID: Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT References: <3348A21B-754F-41FE-A94D-C3F53AD691C8@kientzle.com> In-Reply-To: <3348A21B-754F-41FE-A94D-C3F53AD691C8@kientzle.com> --LN7J2IufhC6SK8NwrIC4cK5coDlxNSWxL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 03.06.2017 08:26, Tim Kientzle wrote: > You could add --format=3Dustar to the existing command line; that=20 > would force bsdtar to use the older "ustar" format (without any > extensions that might confuse Python's tar file module). Even better! Thank you :) >> This will use GNU tar instead of BSD tar to recreate the bootstrap and= >> GNU tar doesn't seem to produce sparse file entries in the archive. >=20 > How ironic; using GNU tar in order to avoid having GNU sparse file entr= ies. ;-) Yes :) --=20 Jean-S=C3=A9bastien P=C3=A9dron --LN7J2IufhC6SK8NwrIC4cK5coDlxNSWxL-- --Svuka5O2Sm096eBRpIcWkqOLCTKp7UH2g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEZwh/0a6uDhLbxqbwOemXYaX9lMwFAlk1zapfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDY3 MDg3RkQxQUVBRTBFMTJEQkM2QTZGMDM5RTk5NzYxQTVGRDk0Q0MACgkQOemXYaX9 lMzKMw//d8nRHhYTr59v027xfLyUGaSEQOG6Ky+IkaXbnpC96uhvCs0VeemNScvx VvNcOp1v41A2elkv5ARUf0WE/RuMzP+6Xmbu5GeoflzhG8zVQRl4BPbTvusiv1oJ 6ndmGLfU5QK+qLPKGrRd4OqyWr65BMaWFP/tskY9w/9KmcZ/G50Ow/ea1yZwP2eU gQ8lJwPSYirQZwMHBuBW7RZsCvdZj8WPFC+nd3rUw07O/HvcDAPprNIP/+2EnkAh l/ZFsIESghzR3X/n5JEy6nF+kTix7u+z0Sfzk6zHGVQQ1w4O/Asf7Jwli2M7whAk RpTuL2WZliBRVeBSTaJFVV62iFPHoH1nFQ5eD/FLdo2f5sr0z/I+oSRERrkAwjH5 3F73g2QUrMjxYyywlOeAhyAVv5Q9AwvwCFdcyqYQBWGVNBYWruJ35CN8d/6+Ovkh mJJBkap45nWomkJIECDtuvDgsYnUUs/3X+AEbRfONRYkkt8/coLBZ6yNYDJa2jIo JtzCDWjlPCBg/kt8vs9OJ86MdcDHE6JandbtZI46084MuyQr0VOHSL2bLNG3yv00 DzCK17iZXUM7aBjhEIb1O/WDb97aASFOKypg2yr+J0jHFhMhNVkkdYKTzSa2XL3U 7SSutK8ekK2Ln/z+p+hk3NUx0ps8Xgs6yNOQKg3vVJx90kk9ORw= =2+fD -----END PGP SIGNATURE----- --Svuka5O2Sm096eBRpIcWkqOLCTKp7UH2g-- From owner-freebsd-current@freebsd.org Tue Jun 6 12:18:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5162BB9416F for ; Tue, 6 Jun 2017 12:18:03 +0000 (UTC) (envelope-from brandon.kastning@protonmail.com) Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "QuoVadis Global SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CB476587B for ; Tue, 6 Jun 2017 12:18:02 +0000 (UTC) (envelope-from brandon.kastning@protonmail.com) Date: Tue, 06 Jun 2017 08:10:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1496751031; bh=Z1A3FufWK0LWHWNwDY3Y7L5Wr6bHBKLX5yVAwZFRv3I=; h=To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:From; b=Owz3IA+5rapmeGFt9cI+GiC1QpfpryYIaV9NQ9dYXAHnb2Ro+OLDj0vJ46O5/j7uG e5W+nGDlGCL9xD8hW0y3uGxQ4Oxi6SiyjoXZ3UZmUmboQ8YBpE/BwOGKJWaXaWi+F5 CU2Raic7AgvOaDTeCf8yJ7J8QzZJqQ9mGPEBfHNk= To: "freebsd-current@freebsd.org" From: Brandon Kastning Reply-To: Brandon Kastning Subject: Re: freebsd-current Digest, Vol 711, Issue 2 Message-ID: In-Reply-To: References: Feedback-ID: DdW-bEtIpV68b95CbuhBGnubG8nTmN8B6IwX2VxvFNdywaF7m-Y3L8VZvJHdbkD9hD5X-mFX1NaGAJpzLbkuqw==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=0.3 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MISSING_DATE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail3.protonmail.ch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Jun 2017 12:18:03 -0000 RnJlZUJTRCAxMi1DdXJyZW50IENvbW11bml0eSBhbmQgRGV2ZWxvcGVycywKClJlZ2FyZGluZyBJ c3N1ZSAjODsgSSB0b28gYW0gaGF2aW5nIGlzc3Vlcy4gSSByZW1vdmVkIEZpcmVmb3ggYmVjYXVz ZSBpdCB3YXMgcmFuZG9tbHkgY2xvc2luZy4gQW5kIHVwb24gcmVpbnN0YWxsLCBJIHdhcyByZWNl aXZpbmcgdGhlIHB5dGhvbiBydXN0IGJ1aWxkIGVycm9yLgoKV2hhdCBpcyB0aGUgcHJvcGVyIHN5 bnRheCBmb3IgYSBidWlsZCB3aXRoIHRoZSAiLS1mb3JtYXQ9dXN0YXIiID8KCkkgYXBvbG9naXpl IGlmIEkgYW0gcGFydGljaXBhdGluZyBpbmNvcnJlY3RseS4gQXMgSSBhbSBuZXcgdG8gdGhlIGNv bW11bml0eSBhbmQgdW5peC4KCkJlc3QgUmVnYXJkcywKCkJyYW5kb24gS2FzdG5pbmcKQUtBLiBT dHJlZXREYW5jZXIgKElSQyAmIEZvcnVtcykKClNlbnQgd2l0aCBbUHJvdG9uTWFpbF0oaHR0cHM6 Ly9wcm90b25tYWlsLmNvbSkgU2VjdXJlIEVtYWlsLgoKLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLS0tLQpTdWJqZWN0OiBmcmVlYnNkLWN1cnJlbnQgRGlnZXN0LCBWb2wgNzExLCBJc3N1 ZSAyCkxvY2FsIFRpbWU6IEp1bmUgNiwgMjAxNyA1OjAwIEFNClVUQyBUaW1lOiBKdW5lIDYsIDIw MTcgMTI6MDAgUE0KRnJvbTogZnJlZWJzZC1jdXJyZW50LXJlcXVlc3RAZnJlZWJzZC5vcmcKVG86 IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZwoKU2VuZCBmcmVlYnNkLWN1cnJlbnQgbWFpbGlu ZyBsaXN0IHN1Ym1pc3Npb25zIHRvCmZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZwoKVG8gc3Vi c2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0Cmh0dHBz Oi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQKb3Is IHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRv CmZyZWVic2QtY3VycmVudC1yZXF1ZXN0QGZyZWVic2Qub3JnCgpZb3UgY2FuIHJlYWNoIHRoZSBw ZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQKZnJlZWJzZC1jdXJyZW50LW93bmVyQGZyZWVic2Qu b3JnCgpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBp cyBtb3JlIHNwZWNpZmljCnRoYW4gIlJlOiBDb250ZW50cyBvZiBmcmVlYnNkLWN1cnJlbnQgZGln ZXN0Li4uIgoKVG9kYXkncyBUb3BpY3M6CgoxLiBSZTogb2xkIHN5c2xvZyAoamFpbCkgYW5kIG5l dyBrZXJuZWwgPSAxMDAlIENQVSAoQnJ5YW4gRHJld2VyeSkKMi4gUmU6IG9sZCBzeXNsb2cgKGph aWwpIGFuZCBuZXcga2VybmVsID0gMTAwJSBDUFUKKE5naWUgQ29vcGVyICh5YW5ldXJhYmV5YSkp CjMuIFJlOiBUaW1lIHRvIGluY3JlYXNlIE1BWFBIWVM/IChLZW5uZXRoIEQuIE1lcnJ5KQo0LiBC b290IENVUlJFTlQgd2l0aG91dCBlZmkgKEFuZHkgTmV1c3RhZHRlcikKNS4gUmU6IEJvb3QgQ1VS UkVOVCB3aXRob3V0IGVmaSAoQWxsYW4gSnVkZSkKNi4gUmU6IFRpbWUgdG8gaW5jcmVhc2UgTUFY UEhZUz8gKEVkd2FyZCBUb21hc3ogTmFwaWVyYT9hKQo3LiBSZTogQm9vdCBDVVJSRU5UIHdpdGhv dXQgZWZpIChUb29tYXMgU29vbWUpCjguIFJlOiBmaXJlZm94LyBydXN0IGZhaWxlZCB0byBpbnN0 YWxsIG9uIEZyZWVCU0QgMTItQ1VSUkVOVAooSmVhbi1TP2Jhc3RpZW4gUD9kcm9uKQoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQoKTWVzc2FnZTogMQpEYXRlOiBNb24sIDUgSnVuIDIwMTcgMDg6MjA6NDcgLTA3MDAK RnJvbTogQnJ5YW4gRHJld2VyeSA8YmRyZXdlcnlARnJlZUJTRC5vcmc+ClRvOiBBbGV4YW5kZXIg TGVpZGluZ2VyIDxBbGV4YW5kZXJAbGVpZGluZ2VyLm5ldD4KQ2M6IGN1cnJlbnRAZnJlZWJzZC5v cmcKU3ViamVjdDogUmU6IG9sZCBzeXNsb2cgKGphaWwpIGFuZCBuZXcga2VybmVsID0gMTAwJSBD UFUKTWVzc2FnZS1JRDogPGIwYmUxYmUzLTRhYTctYTc2OC02MTAyLTNjNzc2ZjA1MzdmNkBGcmVl QlNELm9yZz4KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCIKCk9uIDYv NS8yMDE3IDI6MzQgQU0sIEFsZXhhbmRlciBMZWlkaW5nZXIgd3JvdGU6Cj4KPiBRdW90aW5nIEJy eWFuIERyZXdlcnkgPGJyeWFuQHNoYXRvdy5uZXQ+IChmcm9tIFN1biwgNCBKdW4gMjAxNyAxNDoz ODowNwo+IC0wNzAwKToKPgo+PiBPbiA2LzQvMTcgNTowOSBBTSwgQWxleGFuZGVyIExlaWRpbmdl ciB3cm90ZToKPj4+IEhpLAo+Pj4KPj4+IG5ldyBrZXJuZWwgKHN1cmVseSByMzE4ODc3IGFuZCBs YXRlcikgYW5kIG9sZCBzeXNsb2cgaW4gYSBqYWlsID0gTk9LLgo+Pj4KPj4KPj4gV2hhdCBicmFu Y2ggYW5kIHJldmlzaW9uIGlzIHRoZSBzeXNsb2dkPyBGcm9tIG15IHVuZGVyc3RhbmRpbmcgdGhl IGJ1Zwo+PiBleGlzdHMgaW4gYSBoZWFkIHZlcnNpb24gb2Ygc3lzbG9nZCBvbmx5LCBtYXliZSBN RkMnZCB0byBzdGFibGUvMTEsIGJ1dAo+PiBub3QgcmVsZWFzZWQuIElmIGl0IHdhcyBNRkMnZCB3 ZSBuZWVkIHRvIGZpeCBpdCBiZWZvcmUgdGhlIDExLjEgcmVsZWFzZS4KPgo+IFRoaXMgd2FzIGEg c3lzbG9nZCBmcm9tIGhlYWQgZm9yIHN1cmUuCj4KPiBTbyB0aGUgaXNzdWUgd2FzIHRoYXQgZm9y IGFuIGludGVybWVkaWF0ZSBwZXJpb2Qgb2YgdGltZSBhIGJ1ZyB3YXMgaW4KPiBzeXNsb2dkIGlu IGhlYWQgd2hpY2ggd2FzIGNhdXNpbmcgdGhpcywgYW5kIGlmIEkgd291bGQgaGF2ZSB1cGdyYWRl ZCBhCj4gc3lzdGVtIHdlcmUgdGhlIGphaWwgd291bGQgaGF2ZSBiZWVuIGhlYWQgZnJvbSBiZWZv cmUgdGhlIG9yIGFmdGVyIHRoZQo+IGJ1ZywgdGhlbiBJIHdvdWxkbid0IGhhdmUgbm90aWNlZCBp dD8KPgoKWWVzLCB0aGF0J3MgbXkgdW5kZXJzdGFuZGluZy4gU28gaXQncyB1bHRpbWF0ZWx5IGEg bm9uLWlzc3VlIGZvcgpyZWxlYXNlcyBzaW5jZSBpdCBpcyBqdXN0IGEgdGVtcG9yYXJ5IGlzc3Vl IG9uIGhlYWQuCgotLQpSZWdhcmRzLApCcnlhbiBEcmV3ZXJ5CgotLS0tLS0tLS0tLS0tLSBuZXh0 IHBhcnQgLS0tLS0tLS0tLS0tLS0KQSBub24tdGV4dCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4u LgpOYW1lOiBzaWduYXR1cmUuYXNjClR5cGU6IGFwcGxpY2F0aW9uL3BncC1zaWduYXR1cmUKU2l6 ZTogNDczIGJ5dGVzCkRlc2M6IE9wZW5QR1AgZGlnaXRhbCBzaWduYXR1cmUKVVJMOiA8aHR0cDov L2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNkLWN1cnJlbnQvYXR0YWNobWVudHMv MjAxNzA2MDUvNjQzNWVhZWYvYXR0YWNobWVudC0wMDAxLnNpZz4KCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQoKTWVzc2FnZTogMgpEYXRlOiBNb24sIDUgSnVuIDIwMTcgMDg6NTM6NTAg LTA3MDAKRnJvbTogIk5naWUgQ29vcGVyICh5YW5ldXJhYmV5YSkiIDx5YW5ldXJhYmV5YUBnbWFp bC5jb20+ClRvOiBCcnlhbiBEcmV3ZXJ5IDxiZHJld2VyeUBGcmVlQlNELm9yZz4KQ2M6IEFsZXhh bmRlciBMZWlkaW5nZXIgPEFsZXhhbmRlckBsZWlkaW5nZXIubmV0PiwgY3VycmVudEBmcmVlYnNk Lm9yZwpTdWJqZWN0OiBSZTogb2xkIHN5c2xvZyAoamFpbCkgYW5kIG5ldyBrZXJuZWwgPSAxMDAl IENQVQpNZXNzYWdlLUlEOiA8NTUxMTQzNjEtOTIxMi00OUFFLUEzRkYtNzY5MUNBREIyMzY3QGdt YWlsLmNvbT4KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCIKCj4gT24g SnVuIDUsIDIwMTcsIGF0IDA4OjIwLCBCcnlhbiBEcmV3ZXJ5IDxiZHJld2VyeUBGcmVlQlNELm9y Zz4gd3JvdGU6Cj4KPiBPbiA2LzUvMjAxNyAyOjM0IEFNLCBBbGV4YW5kZXIgTGVpZGluZ2VyIHdy b3RlOgo+Pgo+PiBRdW90aW5nIEJyeWFuIERyZXdlcnkgPGJyeWFuQHNoYXRvdy5uZXQ+IChmcm9t IFN1biwgNCBKdW4gMjAxNyAxNDozODowNwo+PiAtMDcwMCk6Cj4+Cj4+PiBPbiA2LzQvMTcgNTow OSBBTSwgQWxleGFuZGVyIExlaWRpbmdlciB3cm90ZToKPj4+PiBIaSwKPj4+Pgo+Pj4+IG5ldyBr ZXJuZWwgKHN1cmVseSByMzE4ODc3IGFuZCBsYXRlcikgYW5kIG9sZCBzeXNsb2cgaW4gYSBqYWls ID0gTk9LLgo+Pj4+Cj4+Pgo+Pj4gV2hhdCBicmFuY2ggYW5kIHJldmlzaW9uIGlzIHRoZSBzeXNs b2dkPyBGcm9tIG15IHVuZGVyc3RhbmRpbmcgdGhlIGJ1Zwo+Pj4gZXhpc3RzIGluIGEgaGVhZCB2 ZXJzaW9uIG9mIHN5c2xvZ2Qgb25seSwgbWF5YmUgTUZDJ2QgdG8gc3RhYmxlLzExLCBidXQKPj4+ IG5vdCByZWxlYXNlZC4gSWYgaXQgd2FzIE1GQydkIHdlIG5lZWQgdG8gZml4IGl0IGJlZm9yZSB0 aGUgMTEuMSByZWxlYXNlLgo+Pgo+PiBUaGlzIHdhcyBhIHN5c2xvZ2QgZnJvbSBoZWFkIGZvciBz dXJlLgo+Pgo+PiBTbyB0aGUgaXNzdWUgd2FzIHRoYXQgZm9yIGFuIGludGVybWVkaWF0ZSBwZXJp b2Qgb2YgdGltZSBhIGJ1ZyB3YXMgaW4KPj4gc3lzbG9nZCBpbiBoZWFkIHdoaWNoIHdhcyBjYXVz aW5nIHRoaXMsIGFuZCBpZiBJIHdvdWxkIGhhdmUgdXBncmFkZWQgYQo+PiBzeXN0ZW0gd2VyZSB0 aGUgamFpbCB3b3VsZCBoYXZlIGJlZW4gaGVhZCBmcm9tIGJlZm9yZSB0aGUgb3IgYWZ0ZXIgdGhl Cj4+IGJ1ZywgdGhlbiBJIHdvdWxkbid0IGhhdmUgbm90aWNlZCBpdD8KPj4KPgo+IFllcywgdGhh dCdzIG15IHVuZGVyc3RhbmRpbmcuIFNvIGl0J3MgdWx0aW1hdGVseSBhIG5vbi1pc3N1ZSBmb3IK PiByZWxlYXNlcyBzaW5jZSBpdCBpcyBqdXN0IGEgdGVtcG9yYXJ5IGlzc3VlIG9uIGhlYWQuCgpZ ZXMuIHN5c2xvZ2Qgd2FzIHJlZmFjdG9yZWQgb24gXi9oZWFkLiBTb21lIG9mIHRoZSByZWZhY3Rv cmluZyBjYXVzZWQgdGhlIGlzc3VlIEFsZXhhbmRlciBicm91Z2h0IHVwLiBUaGUgY2hhbmdlcyB3 ZXJlIG5ldmVyIGJhY2twb3J0ZWQgdGhvdWdoLCBzbyB0aGUgY29uY2VybiB5b3UgaGFkIGluIHRo ZSBwcmV2aW91cyBtZXNzYWdlIGlzbj90IHNvbWV0aGluZyB0byBiZSB3b3JyaWVkIGFib3V0LCBz aW5jZSB0aGUgY29kZSBoYXNuP3Qgc2VlbiB0aGUgY2hhbmdlcyB0aGUgXi9oZWFkIGNvcHkgaGFz LgpDaGVlcnMhCi1OZ2llCi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLQpB IG5vbi10ZXh0IGF0dGFjaG1lbnQgd2FzIHNjcnViYmVkLi4uCk5hbWU6IHNpZ25hdHVyZS5hc2MK VHlwZTogYXBwbGljYXRpb24vcGdwLXNpZ25hdHVyZQpTaXplOiA4NDIgYnl0ZXMKRGVzYzogTWVz c2FnZSBzaWduZWQgd2l0aCBPcGVuUEdQIHVzaW5nIEdQR01haWwKVVJMOiA8aHR0cDovL2xpc3Rz LmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNkLWN1cnJlbnQvYXR0YWNobWVudHMvMjAxNzA2 MDUvMjYzMGRhYzIvYXR0YWNobWVudC0wMDAxLnNpZz4KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQoKTWVzc2FnZTogMwpEYXRlOiBNb24sIDUgSnVuIDIwMTcgMTI6MDI6NTMgLTA0MDAK RnJvbTogIktlbm5ldGggRC4gTWVycnkiIDxrZW5ARnJlZUJTRC5PUkc+ClRvOiBIYW5zIFBldHRl ciBTZWxhc2t5IDxocHNAc2VsYXNreS5vcmc+CkNjOiBUb21vYWtpIEFPS0kgPGp1bmNob29uQGRl Yy5zYWt1cmEubmUuanA+LApmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcKU3ViamVjdDogUmU6 IFRpbWUgdG8gaW5jcmVhc2UgTUFYUEhZUz8KTWVzc2FnZS1JRDogPDIwMTcwNjA1MTYwMjUzLkdB MTczNzZAbWl0aGxvbmQua2RtLm9yZz4KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0 PXVzLWFzY2lpCgpPbiBTdW4sIEp1biAwNCwgMjAxNyBhdCAwOTo1MjozNiArMDIwMCwgSGFucyBQ ZXR0ZXIgU2VsYXNreSB3cm90ZToKPiBPbiAwNi8wNC8xNyAwOTozOSwgVG9tb2FraSBBT0tJIHdy b3RlOgo+ID4gSGkKPiA+Cj4gPiBPbmUgcG9zc2liaWxpdHkgd291bGQgYmUgdG8gbWFrZSBpdCBN RCBidWlsZC10aW1lIE9USU9OUywKPiA+IGRlZmF1bHRpbmcgMU0gb24gcmVndWxhciBzeXN0ZW1z IGFuZCAxMjhrIG9uIHNtYWxsZXIgc3lzdGVtcy4KPiA+Cj4gPiBPZiBjb3Vyc2UgSSBndWVzcyBt YWtpbmcgaXQgYSB0dW5hYmxlIChvciBzeXNjdGwpIHdvdWxkIGJlIGJlc3QsCj4gPiB0aG91Z2gu Cj4gPgo+Cj4gSGksCj4KPiBBIHR1bmFibGUgc3lzY3RsIHdvdWxkIGJlIGZpbmUsIGJ1dCBiZXdh cmUgdGhhdCBjb21tb25seSB1c2VkIGZpcm13YXJlCj4gb3V0IHRoZXJlIHByb2R1Y2VkIGluIHRo ZSBtaWxsaW9ucyBtaWdodCBoYW5nIGluIGEgbm9uLXJlY292ZXJhYmxlIHdheQo+IGlmIHlvdSBl eGNlZWQgdGhlaXIgImludGVybmFsIGxpbWl0cyIuIENvbmRpdGlvbmFsbHkgbG93ZXJpbmcgdGhp cwo+IGRlZmluaXRpb24gaXMgZmluZSwgYnV0IGluY3JlYXNpbmcgaXQgbmVlZHMgdG8gYmUgY2Fy ZWZ1bGx5IHZlcmlmaWVkLgo+Cj4gRm9yIGV4YW1wbGUgbWFueSBVU0IgZGV2aWNlcyBhcmUgb25s eSB0ZXN0ZWQgd2l0aCBPUydlcyBsaWtlIFdpbmRvd3MgYW5kCj4gTWFjT1MgYW5kIGlmIHRoZXNl IGhhdmUgYW55IGtpbmQgb2YgbGltaXRhdGlvbiBvbiB0aGUgU0NTSSB0cmFuc2Zlcgo+IHNpemVz LCBpdCBpcyB2ZXJ5IGxpa2VseSBtYW55IGRldmljZXMgb3V0IHRoZXJlIGRvIG5vdCBzdXBwb3J0 IGFueQo+IGxhcmdlciB0cmFuc2ZlciBzaXplcyBlaXRoZXIuCgpJIGFncmVlIHRoYXQgSSdkIGxp a2UgdG8gc2VlIGEgdHVuYWJsZS4gV2UndmUgYmVlbiB1c2luZyBhIE1BWFBIWVMgdmFsdWUKc2xp Z2h0bHkgbGFyZ2VyIHRoYW4gMU1CIGF0IFNwZWN0cmEgZm9yIHllYXJzIHdpdGggbm8gcHJvYmxl bXMsIGJ1dCB0aGVuCmFnYWluLCB3ZSdyZSBvbmx5IHJ1bm5pbmcgb24gbmV3ZXIgaGFyZHdhcmUu CgpJZiB3ZSBrZWVwIERGTFRQSFlTIHRoZSBzYW1lICg2NEspIG9yIGNvbWUgdXAgd2l0aCBhbm90 aGVyIGNvbnN0YW50IHRoYXQgaXMKZGVmaW5lZCB0byA2NEssIHRoZSB3YXkgdGhlIGRhKDQpIGFu ZCBzYSg0KSBoYW5kbGUgdGhpbmdzIHdpbGwga2VlcCBtb3N0Cm9sZGVyIGNvbnRyb2xsZXJzIHdv cmtpbmcgcHJvcGVybHkuIEhlcmUgaXMgd2hhdCBkYSg0KSBkb2VzOgoKaWYgKGNwaS5tYXhpbyA9 PSAwKQpzb2Z0Yy0+bWF4aW8gPSBERkxUUEhZUzsgLyogdHJhZGl0aW9uYWwgZGVmYXVsdCAqLwpl bHNlIGlmIChjcGkubWF4aW8gPiBNQVhQSFlTKQpzb2Z0Yy0+bWF4aW8gPSBNQVhQSFlTOyAvKiBm b3Igc2FmZXR5ICovCmVsc2UKc29mdGMtPm1heGlvID0gY3BpLm1heGlvOwpzb2Z0Yy0+ZGlzay0+ ZF9tYXhzaXplID0gc29mdGMtPm1heGlvOwoKY3BpIGlzIHRoZSBYUFRfUEFUSF9JTlEgQ0NCLiBU aGUgbWF4aW8gZmllbGQgd2FzIGFkZGVkIGxhdGVyLCBzbyBvbGRlciwKdW5tb2RpZmllZCBkcml2 ZXJzIHRoYXQgaGF2ZW4ndCBzZXQgdGhlIG1heGlvIGZpZWxkIGRlZmF1bHQgdG8gYSA2NEsgSS9P CnNpemUuCgpEcml2ZXJzIGZvciBzb21lIG9mIHRoZSBtb3JlIGNvbW1vbiBTQVMgYW5kIEZDIGhh cmR3YXJlIHNldCBtYXhpbyB0byBhCnZhbHVlIHRoYXQgaXMgY29ycmVjdCBmb3IgdGhlIGhhcmR3 YXJlLiAoZS5nLiBtcHQoNCksIG1wcyg0KSwgbXByKDQpLAphbmQgaXNwKDQpIGFsbCBzZXQgaXQg Y29ycmVjdGx5LikKCkFzIFdhcm5lciBwb2ludGVkIG91dCwgdGhlIHdheSBhaGNpKDQpIHdvcmtz IGlzIHRoYXQgaXQgc2V0cyBpdHMgbWF4aW11bQpJL08gc2l6ZSB0byBNQVhQSFlTLiBUaGUgcXVl c3Rpb24gaXMsIGRvZXMgYWxsIEFIQ0kgaGFyZHdhcmUgc3VwcG9ydAphcmJpdHJhcnkgdHJhbnNm ZXIgc2l6ZXM/IElzIHRoZXJlIGEgd2F5IHRvIGZpZ3VyZSBvdXQgd2hhdCB0aGUgaGFyZHdhcmUK c3VwcG9ydHMsIGFuZCBpZiBub3QsIHdlIHNob3VsZCBwcm9iYWJseSBkZWZhdWx0IGl0IHRvIDEy OEsgaW5zdGVhZCBvZgpNQVhQSFlTLgoKVGFwZSBkcml2ZXMgYXJlIGFub3RoZXIgcmVsYXRlZCBp c3N1ZS4gVGFwZSBibG9jayBzaXplcyB1cCB0byAxTUIgYXJlCnByZXR0eSBjb21tb24uIExURlMg YWxsb3dzIGZvciBibG9ja3NpemVzIHVwIHRvIDFNQi4gWW91IGNhbid0IGN1cnJlbnRseQpyZWFk IGEgdGFwZSB3aXRoIGEgMU1CIGJsb2Nrc2l6ZSBvbiBGcmVlQlNEIHdpdGhvdXQgYnVtcGluZyBN QVhQSFlTIGFuZApoYXZpbmcgYSBjb250cm9sbGVyIGFuZCB0YXBlIGRyaXZlIHRoYXQgY2FuIGhh bmRsZSB0aGUgbGFyZ2VyIGJsb2Nrc2l6ZS4KClRoZSBzYSg0KSBkcml2ZXIgaGFzIHRoZSBzYW1l IGxvZ2ljIGFzIHRoZSBkYSg0KSBkcml2ZXIgZm9yIGxpbWl0aW5nCnRyYW5zZmVyIHNpemVzIHRv IHRoZSBzbWFsbGVyIG9mIE1BWFBIWVMgYW5kIGNwaS5tYXhpby4KClRoZSBzYSg0KSBkcml2ZXIg Z2l2ZXMgdGhlIHVzZXIgc29tZSB0b29scyBmb3IgZmlndXJpbmcgdGhpbmdzIG91dDoKCntzbTR1 LTEtbWdtdDovcm9vdDohOjF9IG10IHN0YXR1cyAtdgpEcml2ZTogc2EwOiA8SUJNIFVMVFJJVU0t SEg1IEc5TjE+IFNlcmlhbCBOdW1iZXI6IDEwMTUwMDUyMEEKLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCk1vZGUgRGVuc2l0eSBCbG9ja3NpemUgYnBpIENvbXByZXNzaW9uCkN1cnJl bnQ6IDB4NTg6TFRPLTUgdmFyaWFibGUgMzg0NjA3IGVuYWJsZWQgKDB4MSkKLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCkN1cnJlbnQgRHJpdmVyIFN0YXRlOiBhdCByZXN0LgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KUGFydGl0aW9uOiAwIENhbGMgRmlsZSBOdW1i ZXI6IDAgQ2FsYyBSZWNvcmQgTnVtYmVyOiAwClJlc2lkdWFsOiAwIFJlcG9ydGVkIEZpbGUgTnVt YmVyOiAwIFJlcG9ydGVkIFJlY29yZCBOdW1iZXI6IDAKRmxhZ3M6IEJPUAotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KVGFwZSBJL08gcGFyYW1ldGVyczoKTWF4aW11bSBJL08gc2l6 ZSBhbGxvd2VkIGJ5IGRyaXZlciBhbmQgY29udHJvbGxlciAobWF4aW8pOiAxMDQ4NTc2IGJ5dGVz Ck1heGltdW0gSS9PIHNpemUgcmVwb3J0ZWQgYnkgY29udHJvbGxlciAoY3BpX21heGlvKTogNTE5 NzgyNCBieXRlcwpNYXhpbXVtIGJsb2NrIHNpemUgc3VwcG9ydGVkIGJ5IHRhcGUgZHJpdmUgYW5k IG1lZGlhIChtYXhfYmxrKTogODM4ODYwOCBieXRlcwpNaW5pbXVtIGJsb2NrIHNpemUgc3VwcG9y dGVkIGJ5IHRhcGUgZHJpdmUgYW5kIG1lZGlhIChtaW5fYmxrKTogMSBieXRlcwpCbG9jayBncmFu dWxhcml0eSBzdXBwb3J0ZWQgYnkgdGFwZSBkcml2ZSBhbmQgbWVkaWEgKGJsa19ncmFuKTogMCBi eXRlcwpNYXhpbXVtIHBvc3NpYmxlIEkvTyBzaXplIChtYXhfZWZmZWN0aXZlX2lvc2l6ZSk6IDEw NDg1NzYgYnl0ZXMKCk9uIHRoaXMgcGFydGljdWxhciBGcmVlQlNEL2hlYWQgbWFjaGluZSwgSSBo YXZlIE1BWFBIWVMgc2V0IHRvIDFNQi4gVGhlCmNvbnRyb2xsZXIgKGlzcCg0KSkgc3VwcG9ydHMg fjVNQiBJL08gc2l6ZXMgYW5kIHRoZSBkcml2ZSAoSUJNIExUTy01KQpzdXBwb3J0cyB+OE1CIEkv TywgYnV0IE1BWFBIWVMgaXMgc2V0IHRvIDFNQiwgc28gdGhhdCBpcyB0aGUgbGltaXQuCgpJIGhh dmUgY29uc2lkZXJlZCBjaGFuZ2luZyB0aGUgc2EoNCkgZHJpdmVyIHRvIG5vdCB1c2UgcGh5c2lv KDkpLCBhbmQKaW5zdGVhZCB1c2UgYSBjdXN0b20gYWxsb2NhdG9yIHRvIGFsbG93IHJlYWRpbmcg YW5kIHdyaXRpbmcgdGFwZXMgd2l0aApibG9ja3NpemVzIHVwIHRvIHdoYXQgdGhlIGhhcmR3YXJl IChjb21iaW5hdGlvbiBvZiB0YXBlIGRyaXZlIGFuZApjb250cm9sbGVyKSBhbGxvd3MuIEkgaGF2 ZW4ndCBnb3R0ZW4gYXJvdW5kIHRvIGl0IHlldCwgYmVjYXVzZSBidW1waW5nCk1BWFBIWVMgd29y a3Mgd2VsbCBlbm91Z2ggaW4gbW9zdCBjYXNlcy4gSXQgYWxzbyBoYXMgYSBuaWNlIHNpZGUgZWZm ZWN0IG9mCmFsbG93aW5nIHVubWFwcGVkIEkvTy4KClRoZSBwYXNzKDQpIGRyaXZlciBsaW1pdHMg SS9PIHNpemVzIGluIHRoZSBzYW1lIHdheSBhcyB0aGUgZGEoNCkgYW5kIHNhKDQpCmRyaXZlcnMg Zm9yIENDQnMgc2VudCB2aWEgdGhlIGJsb2NraW5nIChDQU1JT0NPTU1BTkQpIGlvY3RsLCBidXQg Zm9yIENDQnMKc2VudCB2aWEgdGhlIGFzeW5jaHJvbm91cyBBUEksIHRoZSBvbmx5IGxpbWl0IGlz IHRoZSBjb250cm9sbGVyIChjcGkubWF4aW8pCmxpbWl0LiBUaGUgbGF0dGVyIGlzIGJlY2F1c2Ug dGhlIGJ1ZmZlcnMgZm9yIHRoZSBhc3luY2hyb25vdXMgaW50ZXJmYWNlCmFyZSBtYWxsb2NlZC4g SWYgaXQgd2VyZSBwb3NzaWJsZSB0byBzZW5kIGFyYml0cmFyeSBzaXplZCwgdW5tYXBwZWQgUy9H Cmxpc3RzLCB0aGVuIHdlIGNvdWxkIGNvbnZlcnQgdGhlIGFzeW5jaHJvbm91cyBwYXNzKDQpIGlu dGVyZmFjZSB0byBkbwp1bm1hcHBlZCBJL08uCgpLZW4KLS0KS2VubmV0aCBNZXJyeQprZW5ARnJl ZUJTRC5PUkcKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKTWVzc2FnZTogNApEYXRl OiBNb24sIDUgSnVuIDIwMTcgMTM6MzE6MTAgLTA0MDAKRnJvbTogQW5keSBOZXVzdGFkdGVyIDxh Lm4udXNAaWVlZS5vcmc+ClRvOiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcKU3ViamVjdDog Qm9vdCBDVVJSRU5UIHdpdGhvdXQgZWZpCk1lc3NhZ2UtSUQ6CjxDQSsyemVjd2JxV2F3YlIwTmY3 NUFxdzA0cThKellpbXhyeHFldk1iaFRBakNKWHNtWWdAbWFpbC5nbWFpbC5jb20+CkNvbnRlbnQt VHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0iVVRGLTgiCgpIaToKCkkgaGF2ZSBhbiBvbGRlciBI UCBkZXNrdG9wIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBVU0IgYm9vdCBvciBVRUZJLiBJcwppdCBw b3NzaWJsZSB0byB1c2UgdGhpcyBtYWNoaW5lIHdpdGggMTItY3VycmVudCB1c2luZyBHUFQ/IEFu eSBoZWxwCm9yIHBvaW50ZXJzIHRvIGluZm8gd291bGQgYmUgZ3JlYXRseSBhcHByZWNpYXRlZC4g VGhhbmtzIGluIGFkdmFuY2UuCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCk1lc3Nh Z2U6IDUKRGF0ZTogTW9uLCA1IEp1biAyMDE3IDEzOjUzOjIwIC0wNDAwCkZyb206IEFsbGFuIEp1 ZGUgPGFsbGFuanVkZUBmcmVlYnNkLm9yZz4KVG86IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9y ZwpTdWJqZWN0OiBSZTogQm9vdCBDVVJSRU5UIHdpdGhvdXQgZWZpCk1lc3NhZ2UtSUQ6IDw1MDQw ZTI5Mi1hZWRkLTJmZTMtNjdlNy05YjBlNDQwZmM2NjJAZnJlZWJzZC5vcmc+CkNvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiCgpPbiAyMDE3LTA2LTA1IDEzOjMxLCBBbmR5 IE5ldXN0YWR0ZXIgd3JvdGU6Cj4gSGk6Cj4KPiBJIGhhdmUgYW4gb2xkZXIgSFAgZGVza3RvcCB0 aGF0IGRvZXMgbm90IHN1cHBvcnQgVVNCIGJvb3Qgb3IgVUVGSS4gSXMKPiBpdCBwb3NzaWJsZSB0 byB1c2UgdGhpcyBtYWNoaW5lIHdpdGggMTItY3VycmVudCB1c2luZyBHUFQ/IEFueSBoZWxwCj4g b3IgcG9pbnRlcnMgdG8gaW5mbyB3b3VsZCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkLiBUaGFua3Mg aW4gYWR2YW5jZS4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKPiBodHRwczov L2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50Cj4gVG8g dW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtY3VycmVudC11bnN1YnNjcmli ZUBmcmVlYnNkLm9yZyIKPgoKSWYgeW91ciBCSU9TIGRvZXMgbm90IGFjdGl2ZWx5IGludGVyZmVy ZSwgdGhlbiB5ZXMsIHlvdSBjYW4gYm9vdCBmcm9tIGEKR1BUIHBhcnRpdGlvbmVkIGRpc2sgaW4g bGVnYWN5IG1vZGUsIHdpdGhvdXQgVUVGSS4KCklmIGl0IGRvZXNuJ3Qgd29yaywgdGhlIGluc3Rh bGxlciBzdGlsbCBzdXBwb3J0cyBNQlIuCgotLQpBbGxhbiBKdWRlCgotLS0tLS0tLS0tLS0tLSBu ZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0KQSBub24tdGV4dCBhdHRhY2htZW50IHdhcyBzY3J1YmJl ZC4uLgpOYW1lOiBzaWduYXR1cmUuYXNjClR5cGU6IGFwcGxpY2F0aW9uL3BncC1zaWduYXR1cmUK U2l6ZTogODM0IGJ5dGVzCkRlc2M6IE9wZW5QR1AgZGlnaXRhbCBzaWduYXR1cmUKVVJMOiA8aHR0 cDovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNkLWN1cnJlbnQvYXR0YWNobWVu dHMvMjAxNzA2MDUvYWI1ZDJiZjYvYXR0YWNobWVudC0wMDAxLnNpZz4KCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQoKTWVzc2FnZTogNgpEYXRlOiBNb24sIDUgSnVuIDIwMTcgMTg6NDk6 MzAgKzAxMDAKRnJvbTogRWR3YXJkIFRvbWFzeiBOYXBpZXJhP2EgPHRyYXN6QEZyZWVCU0Qub3Jn PgpUbzogSGFucyBQZXR0ZXIgU2VsYXNreSA8aHBzQHNlbGFza3kub3JnPgpDYzogVG9tb2FraSBB T0tJIDxqdW5jaG9vbkBkZWMuc2FrdXJhLm5lLmpwPiwKZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qu b3JnClN1YmplY3Q6IFJlOiBUaW1lIHRvIGluY3JlYXNlIE1BWFBIWVM/Ck1lc3NhZ2UtSUQ6IDwy MDE3MDYwNTE3NDkzMC5HQTYyNTlAYnJpY2s+CkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hh cnNldD11cy1hc2NpaQoKT24gMDYwNFQwOTUyLCBIYW5zIFBldHRlciBTZWxhc2t5IHdyb3RlOgo+ IE9uIDA2LzA0LzE3IDA5OjM5LCBUb21vYWtpIEFPS0kgd3JvdGU6Cj4gPiBIaQo+ID4KPiA+IE9u ZSBwb3NzaWJpbGl0eSB3b3VsZCBiZSB0byBtYWtlIGl0IE1EIGJ1aWxkLXRpbWUgT1RJT05TLAo+ ID4gZGVmYXVsdGluZyAxTSBvbiByZWd1bGFyIHN5c3RlbXMgYW5kIDEyOGsgb24gc21hbGxlciBz eXN0ZW1zLgo+ID4KPiA+IE9mIGNvdXJzZSBJIGd1ZXNzIG1ha2luZyBpdCBhIHR1bmFibGUgKG9y IHN5c2N0bCkgd291bGQgYmUgYmVzdCwKPiA+IHRob3VnaC4KPiA+Cj4KPiBIaSwKPgo+IEEgdHVu YWJsZSBzeXNjdGwgd291bGQgYmUgZmluZSwgYnV0IGJld2FyZSB0aGF0IGNvbW1vbmx5IHVzZWQg ZmlybXdhcmUKPiBvdXQgdGhlcmUgcHJvZHVjZWQgaW4gdGhlIG1pbGxpb25zIG1pZ2h0IGhhbmcg aW4gYSBub24tcmVjb3ZlcmFibGUgd2F5Cj4gaWYgeW91IGV4Y2VlZCB0aGVpciAiaW50ZXJuYWwg bGltaXRzIi4gQ29uZGl0aW9uYWxseSBsb3dlcmluZyB0aGlzCj4gZGVmaW5pdGlvbiBpcyBmaW5l LCBidXQgaW5jcmVhc2luZyBpdCBuZWVkcyB0byBiZSBjYXJlZnVsbHkgdmVyaWZpZWQuCj4KPiBG b3IgZXhhbXBsZSBtYW55IFVTQiBkZXZpY2VzIGFyZSBvbmx5IHRlc3RlZCB3aXRoIE9TJ2VzIGxp a2UgV2luZG93cyBhbmQKPiBNYWNPUyBhbmQgaWYgdGhlc2UgaGF2ZSBhbnkga2luZCBvZiBsaW1p dGF0aW9uIG9uIHRoZSBTQ1NJIHRyYW5zZmVyCj4gc2l6ZXMsIGl0IGlzIHZlcnkgbGlrZWx5IG1h bnkgZGV2aWNlcyBvdXQgdGhlcmUgZG8gbm90IHN1cHBvcnQgYW55Cj4gbGFyZ2VyIHRyYW5zZmVy IHNpemVzIGVpdGhlci4KCkZXSVcsIHdoZW4gdGVzdGluZyBjZmlzY3NpKDQpIHdpdGggV2luZG93 cyBhbmQgT1NYIEkndmUgbm90aWNlZAp0aGF0IGJvdGggaXNzdWUgMU1CIHJlcXVlc3RzLiBJIHdv dWxkbid0IGJlIHN1cnByaXNlZCBpZiB0aGV5IGF2b2lkZWQKZG9pbmcgdGhhdCBmb3Igb2xkZXIg ZGV2aWNlcywgZGVwZW5kaW5nIG9uIGVnIHRoZSBTQ1NJIHZlcnNpb24gcmVwb3J0ZWQKYnkgZGV2 aWNlLgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpNZXNzYWdlOiA3CkRhdGU6IE1v biwgMDUgSnVuIDIwMTcgMjA6MzQ6MzMgKzAzMDAKRnJvbTogVG9vbWFzIFNvb21lIDx0c29vbWVA bWUuY29tPgpUbzogQW5keSBOZXVzdGFkdGVyIDxhLm4udXNAaWVlZS5vcmc+CkNjOiBmcmVlYnNk LWN1cnJlbnRAZnJlZWJzZC5vcmcKU3ViamVjdDogUmU6IEJvb3QgQ1VSUkVOVCB3aXRob3V0IGVm aQpNZXNzYWdlLUlEOiA8QTcxRUI5NkUtQTQwNC00NDJELTk1MkMtREY2Nzc0Q0RDNUMyQG1lLmNv bT4KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lpCgo+IE9uIDUuIGp1 dW5pIDIwMTcsIGF0IDIwOjMxLCBBbmR5IE5ldXN0YWR0ZXIgPGEubi51c0BpZWVlLm9yZz4gd3Jv dGU6Cj4KPiBIaToKPgo+IEkgaGF2ZSBhbiBvbGRlciBIUCBkZXNrdG9wIHRoYXQgZG9lcyBub3Qg c3VwcG9ydCBVU0IgYm9vdCBvciBVRUZJLiBJcwo+IGl0IHBvc3NpYmxlIHRvIHVzZSB0aGlzIG1h Y2hpbmUgd2l0aCAxMi1jdXJyZW50IHVzaW5nIEdQVD8gQW55IGhlbHAKPiBvciBwb2ludGVycyB0 byBpbmZvIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIFRoYW5rcyBpbiBhZHZhbmNlLgoK R1BUIGRvZXMgbm90IHJlcXVpcmUgVUVGSSwgQklPUyBib290IHdpbGwgcmVhZCB0aGUgcG1iciBh bmQgc2hvdWxkIGJlaGF2ZSBqdXN0IGFzIHdpdGggTUJSIHBhcnRpdGlvbmluZy4KCnJnZHMsCnRv b21hcwoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpNZXNzYWdlOiA4CkRhdGU6IE1v biwgNSBKdW4gMjAxNyAyMzozMToyMiArMDIwMApGcm9tOiBKZWFuLVM/YmFzdGllbiBQP2Ryb24g PGR1bWJiZWxsQEZyZWVCU0Qub3JnPgpUbzogVGltIEtpZW50emxlIDx0aW1Aa2llbnR6bGUuY29t PgpDYzogRnJlZUJTRCBjdXJyZW50IDxmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc+ClN1Ympl Y3Q6IFJlOiBmaXJlZm94LyBydXN0IGZhaWxlZCB0byBpbnN0YWxsIG9uIEZyZWVCU0QgMTItQ1VS UkVOVApNZXNzYWdlLUlEOiA8ZTQ0OWUxZjgtMTliMC0wNGE4LWY5YTctM2VhYjFmZTM2NTdiQEZy ZWVCU0Qub3JnPgpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04IgoKT24g MDMuMDYuMjAxNyAwODoyNiwgVGltIEtpZW50emxlIHdyb3RlOgo+IFlvdSBjb3VsZCBhZGQgLS1m b3JtYXQ9dXN0YXIgdG8gdGhlIGV4aXN0aW5nIGNvbW1hbmQgbGluZTsgdGhhdAo+IHdvdWxkIGZv cmNlIGJzZHRhciB0byB1c2UgdGhlIG9sZGVyICJ1c3RhciIgZm9ybWF0ICh3aXRob3V0IGFueQo+ IGV4dGVuc2lvbnMgdGhhdCBtaWdodCBjb25mdXNlIFB5dGhvbidzIHRhciBmaWxlIG1vZHVsZSku CgpFdmVuIGJldHRlciEgVGhhbmsgeW91IDopCgo+PiBUaGlzIHdpbGwgdXNlIEdOVSB0YXIgaW5z dGVhZCBvZiBCU0QgdGFyIHRvIHJlY3JlYXRlIHRoZSBib290c3RyYXAgYW5kCj4+IEdOVSB0YXIg ZG9lc24ndCBzZWVtIHRvIHByb2R1Y2Ugc3BhcnNlIGZpbGUgZW50cmllcyBpbiB0aGUgYXJjaGl2 ZS4KPgo+IEhvdyBpcm9uaWM7IHVzaW5nIEdOVSB0YXIgaW4gb3JkZXIgdG8gYXZvaWQgaGF2aW5n IEdOVSBzcGFyc2UgZmlsZSBlbnRyaWVzLiA7LSkKClllcyA6KQoKLS0KSmVhbi1TP2Jhc3RpZW4g UD9kcm9uCgotLS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0KQSBub24tdGV4 dCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLgpOYW1lOiBzaWduYXR1cmUuYXNjClR5cGU6IGFw cGxpY2F0aW9uL3BncC1zaWduYXR1cmUKU2l6ZTogOTYzIGJ5dGVzCkRlc2M6IE9wZW5QR1AgZGln aXRhbCBzaWduYXR1cmUKVVJMOiA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC9m cmVlYnNkLWN1cnJlbnQvYXR0YWNobWVudHMvMjAxNzA2MDUvODhjMWQ1NjYvYXR0YWNobWVudC0w MDAxLnNpZz4KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKU3ViamVjdDogRGlnZXN0 IEZvb3RlcgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K ZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdApodHRwczovL2xpc3RzLmZy ZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50ClRvIHVuc3Vic2NyaWJl LCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWN1cnJlbnQtdW5zdWJzY3JpYmVAZnJlZWJzZC5v cmciCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkVuZCBvZiBmcmVlYnNkLWN1cnJl bnQgRGlnZXN0LCBWb2wgNzExLCBJc3N1ZSAyCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioq From owner-freebsd-current@freebsd.org Tue Jun 6 12:22:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D285EB9440A for ; Tue, 6 Jun 2017 12:22:49 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 A0C8365CC3 for ; Tue, 6 Jun 2017 12:22:49 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x22b.google.com with SMTP id v18so24531299pgb.1 for ; Tue, 06 Jun 2017 05:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MHwxV0HDnXd6Vhn9wy71Sp600gkPvLfzw34y6Pdv3tM=; b=b3U4jJf9EeqYxIiNfaq9PvEqVvxscXB1XQBOvdOHV4xuu9pSjFj5/FJMNjzCdh9/hx IZ5RK006us+NYm8ly0L7TAl90uGebr84cILTRp1W4FDjV4b0rIneS3Np336kO6LrnJd3 phgidKKxFpg7XuZo4iE7rs2h1t4BU0kTvqh5fOW1an6iFEoTthpz3MUMH3kQMy/4iQvG SaWV4kPMefFr0Md4HcOozrVp/YZTB8+ffBWi+2ahNCvi/aMvGJ4Svy+V/tQcCYHrikK1 vK88PMpv0WEJTlAwf303ysMovHCpCiHmJPNB4xGcJ8qFQQO/VALHiJeuHbv5DpGmTNSR DwAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MHwxV0HDnXd6Vhn9wy71Sp600gkPvLfzw34y6Pdv3tM=; b=nwAsGpYnnahMeJsCHaky1/4HMfavrkfsHDsJEPkQ5lUAic0EiudrTXydrT0sP7/eCh bEC7GpqDPCUhrC8+HyidLVdqeg/B5tF8E7NI5PAH9J5aZdxayO3dPem7vXaEqJWm8i2g ZXUU8amPUBDOkxMsiPh65xSNQHt06gg5y6hs1Q6fXTveqlhF6pE6X76esNXD11lRGC59 jHnXhdVrJou2MjgR0H4C8TK60fLQQO4qvo2bk3UMTiFnlLpbr7B12vqw4Z4DhS98bYSi nR+d3UU7ZpAWYQr82BXbHk19ghMeDsPfMycH3qFFPs99NlzfOs7OX/J5Q568aPkrR0ku CwOQ== X-Gm-Message-State: AODbwcCRr4uVn2ZPoAuv99TVjjV6gmrYyt3QJZri2AXuaq8vq1dTmbGg PIwZHpIVsLhNb3VJyGzQGwkQqgKJGQ== X-Received: by 10.98.163.25 with SMTP id s25mr24966800pfe.217.1496751768971; Tue, 06 Jun 2017 05:22:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: blubee blubeeme Date: Tue, 06 Jun 2017 12:22:38 +0000 Message-ID: Subject: Re: freebsd-current Digest, Vol 711, Issue 2 To: Brandon Kastning , "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Jun 2017 12:22:50 -0000 I was able to sort this out by installing rust from pkg. The pkg and ports version was the same when I did it a lil while ago. Try that, then running the Firefox build again. Best, Owen On Tue, Jun 6, 2017, 20:18 Brandon Kastning wrote: > FreeBSD 12-Current Community and Developers, > > Regarding Issue #8; I too am having issues. I removed Firefox because it > was randomly closing. And upon reinstall, I was receiving the python rust > build error. > > What is the proper syntax for a build with the "--format=ustar" ? > > I apologize if I am participating incorrectly. As I am new to the > community and unix. > > Best Regards, > > Brandon Kastning > AKA. StreetDancer (IRC & Forums) > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > -------- Original Message -------- > Subject: freebsd-current Digest, Vol 711, Issue 2 > Local Time: June 6, 2017 5:00 AM > UTC Time: June 6, 2017 12:00 PM > From: freebsd-current-request@freebsd.org > To: freebsd-current@freebsd.org > > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org > > You can reach the person managing the list at > freebsd-current-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > Today's Topics: > > 1. Re: old syslog (jail) and new kernel = 100% CPU (Bryan Drewery) > 2. Re: old syslog (jail) and new kernel = 100% CPU > (Ngie Cooper (yaneurabeya)) > 3. Re: Time to increase MAXPHYS? (Kenneth D. Merry) > 4. Boot CURRENT without efi (Andy Neustadter) > 5. Re: Boot CURRENT without efi (Allan Jude) > 6. Re: Time to increase MAXPHYS? (Edward Tomasz Napiera?a) > 7. Re: Boot CURRENT without efi (Toomas Soome) > 8. Re: firefox/ rust failed to install on FreeBSD 12-CURRENT > (Jean-S?bastien P?dron) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Jun 2017 08:20:47 -0700 > From: Bryan Drewery > To: Alexander Leidinger > Cc: current@freebsd.org > Subject: Re: old syslog (jail) and new kernel = 100% CPU > Message-ID: > Content-Type: text/plain; charset="utf-8" > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > > > > Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > > -0700): > > > >> On 6/4/17 5:09 AM, Alexander Leidinger wrote: > >>> Hi, > >>> > >>> new kernel (surely r318877 and later) and old syslog in a jail = NOK. > >>> > >> > >> What branch and revision is the syslogd? From my understanding the bug > >> exists in a head version of syslogd only, maybe MFC'd to stable/11, but > >> not released. If it was MFC'd we need to fix it before the 11.1 release. > > > > This was a syslogd from head for sure. > > > > So the issue was that for an intermediate period of time a bug was in > > syslogd in head which was causing this, and if I would have upgraded a > > system were the jail would have been head from before the or after the > > bug, then I wouldn't have noticed it? > > > > Yes, that's my understanding. So it's ultimately a non-issue for > releases since it is just a temporary issue on head. > > -- > Regards, > Bryan Drewery > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 473 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/6435eaef/attachment-0001.sig > > > > ------------------------------ > > Message: 2 > Date: Mon, 5 Jun 2017 08:53:50 -0700 > From: "Ngie Cooper (yaneurabeya)" > To: Bryan Drewery > Cc: Alexander Leidinger , current@freebsd.org > Subject: Re: old syslog (jail) and new kernel = 100% CPU > Message-ID: <55114361-9212-49AE-A3FF-7691CADB2367@gmail.com> > Content-Type: text/plain; charset="utf-8" > > > On Jun 5, 2017, at 08:20, Bryan Drewery wrote: > > > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > >> > >> Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > >> -0700): > >> > >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote: > >>>> Hi, > >>>> > >>>> new kernel (surely r318877 and later) and old syslog in a jail = NOK. > >>>> > >>> > >>> What branch and revision is the syslogd? From my understanding the bug > >>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but > >>> not released. If it was MFC'd we need to fix it before the 11.1 > release. > >> > >> This was a syslogd from head for sure. > >> > >> So the issue was that for an intermediate period of time a bug was in > >> syslogd in head which was causing this, and if I would have upgraded a > >> system were the jail would have been head from before the or after the > >> bug, then I wouldn't have noticed it? > >> > > > > Yes, that's my understanding. So it's ultimately a non-issue for > > releases since it is just a temporary issue on head. > > Yes. syslogd was refactored on ^/head. Some of the refactoring caused the > issue Alexander brought up. The changes were never backported though, so > the concern you had in the previous message isn?t something to be worried > about, since the code hasn?t seen the changes the ^/head copy has. > Cheers! > -Ngie > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 842 bytes > Desc: Message signed with OpenPGP using GPGMail > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/2630dac2/attachment-0001.sig > > > > ------------------------------ > > Message: 3 > Date: Mon, 5 Jun 2017 12:02:53 -0400 > From: "Kenneth D. Merry" > To: Hans Petter Selasky > Cc: Tomoaki AOKI , > freebsd-current@freebsd.org > Subject: Re: Time to increase MAXPHYS? > Message-ID: <20170605160253.GA17376@mithlond.kdm.org> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jun 04, 2017 at 09:52:36 +0200, Hans Petter Selasky wrote: > > On 06/04/17 09:39, Tomoaki AOKI wrote: > > > Hi > > > > > > One possibility would be to make it MD build-time OTIONS, > > > defaulting 1M on regular systems and 128k on smaller systems. > > > > > > Of course I guess making it a tunable (or sysctl) would be best, > > > though. > > > > > > > Hi, > > > > A tunable sysctl would be fine, but beware that commonly used firmware > > out there produced in the millions might hang in a non-recoverable way > > if you exceed their "internal limits". Conditionally lowering this > > definition is fine, but increasing it needs to be carefully verified. > > > > For example many USB devices are only tested with OS'es like Windows and > > MacOS and if these have any kind of limitation on the SCSI transfer > > sizes, it is very likely many devices out there do not support any > > larger transfer sizes either. > > I agree that I'd like to see a tunable. We've been using a MAXPHYS value > slightly larger than 1MB at Spectra for years with no problems, but then > again, we're only running on newer hardware. > > If we keep DFLTPHYS the same (64K) or come up with another constant that is > defined to 64K, the way the da(4) and sa(4) handle things will keep most > older controllers working properly. Here is what da(4) does: > > if (cpi.maxio == 0) > softc->maxio = DFLTPHYS; /* traditional default */ > else if (cpi.maxio > MAXPHYS) > softc->maxio = MAXPHYS; /* for safety */ > else > softc->maxio = cpi.maxio; > softc->disk->d_maxsize = softc->maxio; > > cpi is the XPT_PATH_INQ CCB. The maxio field was added later, so older, > unmodified drivers that haven't set the maxio field default to a 64K I/O > size. > > Drivers for some of the more common SAS and FC hardware set maxio to a > value that is correct for the hardware. (e.g. mpt(4), mps(4), mpr(4), > and isp(4) all set it correctly.) > > As Warner pointed out, the way ahci(4) works is that it sets its maximum > I/O size to MAXPHYS. The question is, does all AHCI hardware support > arbitrary transfer sizes? Is there a way to figure out what the hardware > supports, and if not, we should probably default it to 128K instead of > MAXPHYS. > > Tape drives are another related issue. Tape block sizes up to 1MB are > pretty common. LTFS allows for blocksizes up to 1MB. You can't currently > read a tape with a 1MB blocksize on FreeBSD without bumping MAXPHYS and > having a controller and tape drive that can handle the larger blocksize. > > The sa(4) driver has the same logic as the da(4) driver for limiting > transfer sizes to the smaller of MAXPHYS and cpi.maxio. > > The sa(4) driver gives the user some tools for figuring things out: > > {sm4u-1-mgmt:/root:!:1} mt status -v > Drive: sa0: Serial Number: 101500520A > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x58:LTO-5 variable 384607 enabled (0x1) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > Residual: 0 Reported File Number: 0 Reported Record Number: 0 > Flags: BOP > --------------------------------- > Tape I/O parameters: > Maximum I/O size allowed by driver and controller (maxio): 1048576 bytes > Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes > Maximum block size supported by tape drive and media (max_blk): 8388608 > bytes > Minimum block size supported by tape drive and media (min_blk): 1 bytes > Block granularity supported by tape drive and media (blk_gran): 0 bytes > Maximum possible I/O size (max_effective_iosize): 1048576 bytes > > On this particular FreeBSD/head machine, I have MAXPHYS set to 1MB. The > controller (isp(4)) supports ~5MB I/O sizes and the drive (IBM LTO-5) > supports ~8MB I/O, but MAXPHYS is set to 1MB, so that is the limit. > > I have considered changing the sa(4) driver to not use physio(9), and > instead use a custom allocator to allow reading and writing tapes with > blocksizes up to what the hardware (combination of tape drive and > controller) allows. I haven't gotten around to it yet, because bumping > MAXPHYS works well enough in most cases. It also has a nice side effect of > allowing unmapped I/O. > > The pass(4) driver limits I/O sizes in the same way as the da(4) and sa(4) > drivers for CCBs sent via the blocking (CAMIOCOMMAND) ioctl, but for CCBs > sent via the asynchronous API, the only limit is the controller (cpi.maxio) > limit. The latter is because the buffers for the asynchronous interface > are malloced. If it were possible to send arbitrary sized, unmapped S/G > lists, then we could convert the asynchronous pass(4) interface to do > unmapped I/O. > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG > > ------------------------------ > > Message: 4 > Date: Mon, 5 Jun 2017 13:31:10 -0400 > From: Andy Neustadter > To: freebsd-current@freebsd.org > Subject: Boot CURRENT without efi > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Hi: > > I have an older HP desktop that does not support USB boot or UEFI. Is > it possible to use this machine with 12-current using GPT? Any help > or pointers to info would be greatly appreciated. Thanks in advance. > > ------------------------------ > > Message: 5 > Date: Mon, 5 Jun 2017 13:53:20 -0400 > From: Allan Jude > To: freebsd-current@freebsd.org > Subject: Re: Boot CURRENT without efi > Message-ID: <5040e292-aedd-2fe3-67e7-9b0e440fc662@freebsd.org> > Content-Type: text/plain; charset="utf-8" > > On 2017-06-05 13:31, Andy Neustadter wrote: > > Hi: > > > > I have an older HP desktop that does not support USB boot or UEFI. Is > > it possible to use this machine with 12-current using GPT? Any help > > or pointers to info would be greatly appreciated. Thanks in advance. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > > If your BIOS does not actively interfere, then yes, you can boot from a > GPT partitioned disk in legacy mode, without UEFI. > > If it doesn't work, the installer still supports MBR. > > -- > Allan Jude > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 834 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/ab5d2bf6/attachment-0001.sig > > > > ------------------------------ > > Message: 6 > Date: Mon, 5 Jun 2017 18:49:30 +0100 > From: Edward Tomasz Napiera?a > To: Hans Petter Selasky > Cc: Tomoaki AOKI , > freebsd-current@freebsd.org > Subject: Re: Time to increase MAXPHYS? > Message-ID: <20170605174930.GA6259@brick> > Content-Type: text/plain; charset=us-ascii > > On 0604T0952, Hans Petter Selasky wrote: > > On 06/04/17 09:39, Tomoaki AOKI wrote: > > > Hi > > > > > > One possibility would be to make it MD build-time OTIONS, > > > defaulting 1M on regular systems and 128k on smaller systems. > > > > > > Of course I guess making it a tunable (or sysctl) would be best, > > > though. > > > > > > > Hi, > > > > A tunable sysctl would be fine, but beware that commonly used firmware > > out there produced in the millions might hang in a non-recoverable way > > if you exceed their "internal limits". Conditionally lowering this > > definition is fine, but increasing it needs to be carefully verified. > > > > For example many USB devices are only tested with OS'es like Windows and > > MacOS and if these have any kind of limitation on the SCSI transfer > > sizes, it is very likely many devices out there do not support any > > larger transfer sizes either. > > FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed > that both issue 1MB requests. I wouldn't be surprised if they avoided > doing that for older devices, depending on eg the SCSI version reported > by device. > > ------------------------------ > > Message: 7 > Date: Mon, 05 Jun 2017 20:34:33 +0300 > From: Toomas Soome > To: Andy Neustadter > Cc: freebsd-current@freebsd.org > Subject: Re: Boot CURRENT without efi > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On 5. juuni 2017, at 20:31, Andy Neustadter wrote: > > > > Hi: > > > > I have an older HP desktop that does not support USB boot or UEFI. Is > > it possible to use this machine with 12-current using GPT? Any help > > or pointers to info would be greatly appreciated. Thanks in advance. > > GPT does not require UEFI, BIOS boot will read the pmbr and should behave > just as with MBR partitioning. > > rgds, > toomas > > ------------------------------ > > Message: 8 > Date: Mon, 5 Jun 2017 23:31:22 +0200 > From: Jean-S?bastien P?dron > To: Tim Kientzle > Cc: FreeBSD current > Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT > Message-ID: > Content-Type: text/plain; charset="utf-8" > > On 03.06.2017 08:26, Tim Kientzle wrote: > > You could add --format=ustar to the existing command line; that > > would force bsdtar to use the older "ustar" format (without any > > extensions that might confuse Python's tar file module). > > Even better! Thank you :) > > >> This will use GNU tar instead of BSD tar to recreate the bootstrap and > >> GNU tar doesn't seem to produce sparse file entries in the archive. > > > > How ironic; using GNU tar in order to avoid having GNU sparse file > entries. ;-) > > Yes :) > > -- > Jean-S?bastien P?dron > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 963 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/88c1d566/attachment-0001.sig > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > ------------------------------ > > End of freebsd-current Digest, Vol 711, Issue 2 > *********************************************** > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://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 Jun 6 12:37:52 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08376B94777; Tue, 6 Jun 2017 12:37:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C070A66247; Tue, 6 Jun 2017 12:37:51 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [2.247.252.203] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dIDk4-0004Vx-Eb; Tue, 06 Jun 2017 14:37:49 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v56CbjnX005319 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Jun 2017 14:37:45 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v56CbiWe005318; Tue, 6 Jun 2017 14:37:44 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 6 Jun 2017 14:37:38 +0200 From: Matthias Apitz To: freebsd-questions@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: mount_smbfs gives error when stored crypted pw is used Message-ID: <20170606123738.GA5213@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-questions@freebsd.org, freebsd-current@freebsd.org References: <20170606100034.GA4245@c720-r314251> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20170606100034.GA4245@c720-r314251> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 2.247.252.203 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Jun 2017 12:37:52 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa martes, junio 06, 2017 a las 12:00:34p. m. +0200, Matthias Apit= z escribi=C3=B3: >=20 > Hello, >=20 > At work I have to run FreeBSD (12-CURRENT, amd64) in vbox on Win7 host > and used successful mount_smbfs to mount the hosts disk to FreeBSD. This > worked fine until the last password change of the domain pw we have todo > every 12 weeks or so. >=20 > Now the new crypted and stored pw from /etc/nsmb.conf is not accepted > anymore. In detail, when I do: >=20 > ... I looked into the sources in src/contrib/smbfs/lib/smb to understand how the hashed pw is translated to clear text and wrote a small test pgm which uses the same function of the /usr/lib/libsmb.so $ cc -o smbpw smbpw.c -l smb I now crypt a dummy pw with the following chars '1234567890-1-1234567': $ smbutil crypt 1234567890-1-1234567 $$12a1a06767a6a5e4ebaa0b09b9af5e3eddfcd1312 the resulting hash gives retranslated by smb_simpledecrypt(): $ ./smbpw=20 smb_simpledecrypt(): hash: [$$12a1a06767a6a5e4ebaa0b09b9af5e3eddfcd1312] gi= ves clear [1234567890-1-12345] i.e. the last two chars are missing. $ cat smbpw.c #include int smb_simpledecrypt(char *dst, const char *src); int main() { char *hash =3D "$$12a1a06767a6a5e4ebaa0b09b9af5e3eddfcd1312"; char clear[256]; clear[0] =3D '\0'; smb_simpledecrypt(clear, hash); printf("smb_simpledecrypt(): hash: [%s] gives clear [%s]\n", hash, clea= r); } This seems to be an issue in the libsmb... matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =E2=98=8E +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi=C3=B3 la Guerra. May 8, 1945: Who does not celebrate lost the War. --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlk2ogoACgkQR8z35Hb+ nRHWFhAAoqC614OwHMRp3vZCwWqlGaT+Rf3u5AJYgFevgBdiwHbywaodrV4U/SfZ db6U9+5KsMHfqc1sfR83AqyIt7VAUBG/TROyrGaKHlPgJKALI67bvTg7LNfv96iL 8woXL+obewGSiqPCYyvVlwDauMovi0LFI5MmF3SQ42XllzDDZ7PzAJ6JnotTzLta RxyPxs8yfASChx+72ZGWdQdj2W4bBjAVZRoLSDR/JzvnQSPNJO28tBv2YJlmo57O JnzAGcyGu1Tx7VrM9Pzqu2+/p+HZehK+kvoT1jm0JtLib6DNKkgmI0r1uvN/M1u9 253RF6dpqTGoDHMQUpzhZCIvNsXTofAgAmDANAoOJ6bp+qXtx0PVSZG91Vwr7cEp caGD/UEQXUr7skhob618W8H/wpJY42HKBRkkw8Jr13t2C4fZl7sL6DCbxE9wPB2Z iMRVGmEXp3+ejnhzDfbheyxIvWvPmJAKHXx8Q+cbjyYdnj4IRqOVuliabL1k0N+Q RyLl6w7NAp3LqAAoM1QnXh6pU6TdkvyM2MMl00gazfl1A/qCZAuMUQ8m0CLEdEWA sHX+bVORUkUGb3kkhdx/2OtxDQ6UbyGVPygIjU0yws1egyzcLwvfNZ6rL5av6xrj rllm9UH3ASz3YHzb3JbyJWSNG+e2aU4po9HxsMVQYfQvXpBllFs= =rVwD -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-current@freebsd.org Tue Jun 6 14:08:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 881E3BD377A for ; Tue, 6 Jun 2017 14:08:25 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e: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 46F626ABF4 for ; Tue, 6 Jun 2017 14:08:25 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id l89so24045264pfi.2 for ; Tue, 06 Jun 2017 07:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lXnDtAPaYWjlleIzev9yDlsS3f/bRDsf6GzxQ0tRBwI=; b=Eg/XOcDBPs6vHg7Ict0fp+ThUeV2e0yToeWBESOT/JnOJ0roSktCkT2vr4lBF4eUmE MjpOzWeYXdMF4p3M2L7xkIgjAm7HNVph+zdkVmuDt+28mRkGMjICSuFyVOWR8Y/ndmIY gIG07TFgdjbh7FTcsfchZ5pA+6ej3R5N7kFa5q3flvMACG+RUsAtHe0rmGLMI3HfVMFm ZCU4/tH81QBpkfltB2GG/7OsO+4Ri1mfaYeG/7gTbmIGq1Bl9BIEXkDBDE4s05dI39+z ofUrHmvR84waZGEpE/iFBuwg+zlZuU/HBwBD4LDRovDorGjKfhbsPJ6LTt/LnAeyFPCF 0u3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lXnDtAPaYWjlleIzev9yDlsS3f/bRDsf6GzxQ0tRBwI=; b=Xr13gQGL9Sxksc99edMzg5pB1+h2uNOdtyb3Tbc7MEBNC9wFCLJOIkgxQ3/UuaaWCZ EysMwDVI5X1mfiQ+/yNdSF7vlrBM8txrfPcqdE4yNIpld672s17xqtlV0pp18sFvwwmF Z/LiHNnFgzLBXqPrLO12bV5Z/kq/AX6VBgsLL2yTo279/P+FNdP3D7ajvvL3ypwamFZT cIsGF4dNj2SALAxp7tQmo9v7nDmH/0uF1kMp/a0P855ZbyrlJKaEYkY7kMatM7cQ3r07 7OC//TPCDy7KXNYwyKi9a8nS8qeABbq6rZWj+2dfwzMP8xuYi2ExaNhSSg5okyME7XGb GZfg== X-Gm-Message-State: AODbwcDilKG14HnBGaILVy3vzwgPgRidCdolT3vMtUHAi/Xj7Oe1PJxF BT8Z6WwhtLiaz7KLxbNM1YvjN4dYWHFl X-Received: by 10.99.165.29 with SMTP id n29mr26893740pgf.233.1496758104676; Tue, 06 Jun 2017 07:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Tue, 6 Jun 2017 07:08:24 -0700 (PDT) In-Reply-To: References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> From: blubee blubeeme Date: Tue, 6 Jun 2017 22:08:24 +0800 Message-ID: Subject: Re: nvidia drivers mutex lock To: Tomoaki AOKI Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Jun 2017 14:08:25 -0000 This is getting out of hand. I can't even keep x going for ten minutes sometimes. I've tested all the suggestions in this thread and they just don't work. I have put out a print of sysctl hw. here : https://paste2.org/ With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz The bios on this laptop I can either set graphics to discrete or mshybrid. I've tried in the past to disable discrete and run mshybrid but that always comes up with 0 screens found. Even just doing Xorg -configure. Anyone have some tips on disabling nvidia drivers, running this cpu with igpu for a while? Best, Owen On Sun, Jun 4, 2017, 18:11 blubee blubeeme wrote: > Thanks a lot! I'll give it a shot in a bit. > > Best, > Owen > > On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI wrote= : > >> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. >> >> But beware! Sometimes upstream changes make any of FreeBSD patches not >> applicable (incorporating any of these, incompatible modifies, ...). >> >> For 381.22, current patchset applies and builds fine for me. >> >> >> On Sun, 04 Jun 2017 08:04:50 +0000 >> blubee blubeeme wrote: >> >> > I'm running with svn and I build by make. >> > If in use these steps, the BSD related patches will be applied, etc? >> > >> > Best, >> > Owen >> > >> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI >> wrote: >> > >> > > Hi. >> > > >> > > Not in ports tree, but easily overridden by adding >> > > >> > > DISTVERSION=3D381.22 -DNO_CHECKSUM >> > > >> > > on make command line. Makefile of x11/nvidia-driver has a mechanism >> > > to do so for someone requires newer version (newer GPU support, etc.= ). >> > > >> > > If you're using portupgrade, >> > > >> > > portupgrade -m 'DISTVERSION=3D381.22 -DNO_CHECKSUM' -f >> x11/nvidia-driver >> > > >> > > would do the same. >> > > >> > > If you installed it via pkg, there's no way to try. :-( >> > > (As it's pre-built.) >> > > >> > > >> > > On Sun, 04 Jun 2017 07:04:01 +0000 >> > > blubee blubeeme wrote: >> > > >> > > > Hi @tomoaki >> > > > Is that version of nvidia drivers currently in the ports tree? I >> just >> > > > checked but it seems not to be. >> > > > >> > > > @jeffrey >> > > > I just generated a new xorg based on the force composition setting= . >> I >> > > > merged it with my previous xorg I'll reboot, see if it gives bette= r >> > > > performance. >> > > > >> > > > It seems like my system is locking up more frequently now. Sometim= es >> > > right >> > > > after a reboot the system, the screen locks and it's reboot and >> pray. >> > > > >> > > > Best, >> > > > Owen >> > > > >> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet < >> jeffreybouquet@yahoo.com> >> > > wrote: >> > > > >> > > > > SOME LINES BOTTOM POSTED, SEE... >> > > > > -------------------------------------------- >> > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: >> > > > > >> > > > > Subject: Re: nvidia drivers mutex lock >> > > > > To: freebsd-current@freebsd.org >> > > > > Cc: "Jeffrey Bouquet" , "blubee >> blubeeme" < >> > > > > gurenchan@gmail.com> >> > > > > Date: Friday, June 2, 2017, 11:25 PM >> > > > > >> > > > > Hi. >> > > > > Version >> > > > > 381.22 (5 days newer than 375.66) of the driver states... >> > > > > [1] >> > > > > >> > > > > Fixed hangs and >> > > > > crashes that could occur when an OpenGL context is >> > > > > created while the system is out of available >> > > > > memory. >> > > > > >> > > > > Can this be related >> > > > > with your hang? >> > > > > >> > > > > IMHO, >> > > > > possibly allocating new resource (using os.lock_mtx >> > > > > guard) >> > > > > without checking the lock first while >> > > > > previous request is waiting for >> > > > > another can >> > > > > cause the duplicated lock situation. And high memory >> > > > > pressure would easily cause the situation. >> > > > > >> > > > > [1] http://www.nvidia.com/Download/driverResults.aspx/ >> 118527/en-us >> > > > > >> > > > > Hope it helps. >> > > > > >> > > > > >> > > > > On Thu, 1 Jun >> > > > > 2017 22:35:46 +0000 (UTC) >> > > > > Jeffrey Bouquet >> > > > > >> > > > > wrote: >> > > > > >> > > > > > I see the same >> > > > > message, upon load, ... >> > > > > > >> > > > > -------------------------------------------- >> > > > > > On Thu, 6/1/17, blubee blubeeme >> > > > > wrote: >> > > > > > >> > > > > > Subject: >> > > > > nvidia drivers mutex lock >> > > > > > To: freebsd-ports@freebsd.org, >> > > > > freebsd-current@freebsd.org >> > > > > > Date: Thursday, June 1, 2017, 11:35 >> > > > > AM >> > > > > > >> > > > > > I'm >> > > > > running nvidia-drivers 375.66 with a GTX >> > > > > > 1070 on FreeBSD-Current >> > > > > > >> > > > > > This problem >> > > > > just started happening >> > > > > > recently but, >> > > > > every so often my laptop >> > > > > > screen will >> > > > > just blank out and then I >> > > > > > have to >> > > > > power cycle to get the >> > > > > > machine up and >> > > > > running again. >> > > > > > >> > > > > > It seems to be a problem with nvidia >> > > > > > drivers acquiring duplicate lock. Any >> > > > > > info on this? >> > > > > > >> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: >> > > > > > acquiring duplicate lock of same >> > > > > type: >> > > > > > "os.lock_mtx" >> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: 1st >> > > > > > os.lock_mtx @ nvidia_os.c:841 >> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: 2nd >> > > > > > os.lock_mtx @ nvidia_os.c:841 >> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: >> > > > > > stack backtrace: >> > > > > > >> > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: #0 >> > > > > > >> > > > > 0xffffffff80ab7770 at >> > > > > > >> > > > > witness_debugger+0x70 >> > > > > > Jun=E3=80=93 2 >> > > > > 02:29:41 blubee kernel: #1 >> > > > > > >> > > > > 0xffffffff80ab7663 at >> > > > > > >> > > > > witness_checkorder+0xe23 >> > > > > > Jun=E3=80=93 2 >> > > > > 02:29:41 blubee kernel: #2 >> > > > > > >> > > > > 0xffffffff80a35b93 at >> > > > > > >> > > > > __mtx_lock_flags+0x93 >> > > > > > Jun=E3=80=93 2 >> > > > > 02:29:41 blubee kernel: #3 >> > > > > > >> > > > > 0xffffffff82f4397b at >> > > > > > >> > > > > os_acquire_spinlock+0x1b >> > > > > > Jun=E3=80=93 2 >> > > > > 02:29:41 blubee kernel: #4 >> > > > > > >> > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 >> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: >> > > > > > ACPI Warning: >> > > > > \_SB.PCI0.PEG0.PEGP._DSM: >> > > > > > Argument #4 >> > > > > type mismatch - Found >> > > > > > [Buffer], ACPI >> > > > > requires [Package] >> > > > > > >> > > > > (20170303/nsarguments-205) >> > > > > > Jun=E3=80=93 2 >> > > > > 02:29:42 blubee kernel: >> > > > > > >> > > > > nvidia-modeset: Allocated GPU:0 >> > > > > > >> > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ >> > > > > > PCI:0000:01:00.0 >> > > > > > >> > > > > >> > > > > > Best, >> > > > > > Owen >> > > > > > >> > > > > _______________________________________________ >> > > > > > freebsd-ports@freebsd.org >> > > > > > mailing list >> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports >> > > > > > To unsubscribe, send any mail to >> > > > > "freebsd-ports-unsubscribe@freebsd.org" >> > > > > > >> > > > > > >> > > > > > >> > > > > > ... then Xorg will >> > > > > run happily twelve hours or so. The lockups here happen >> > > > > usually >> > > > > > when too large or too many of >> > > > > number of tabs/ large web pages with complex CSS etc >> > > > > > are opened at a time. >> > > > > > So no help, just a 'me >> > > > > too'. >> > > > > > >> > > > > _______________________________________________ >> > > > > > freebsd-current@freebsd.org >> > > > > mailing list >> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > > > > > >> > > > > To unsubscribe, send any mail to " >> > > freebsd-current-unsubscribe@freebsd.org >> > > > > " >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Tomoaki >> > > > > AOKI >> > > > > >> > > > > >> > > > > >> > > > > ........................ >> > > > > might be a workaround >> > > > > Xorg/nvidia ran all night with this: >> > > > > nvidia-settings >> X server display configuration >> Advance= d >> >> >> > > Force >> > > > > Full Composition Pipeline >> > > > > ... for the laptop freezing. Could not hurt to try. " merge wi= th >> > > > > Xorg.conf " from nvidia-settings... >> > > > > ...................... >> > > > > 18 hours uptime so far, even past >> > > > > the 3 am periodic scripts. Have not rebooted out of the Xorg >> though >> > > so >> > > > > may require edit-out of >> > > > > xorg.conf if that is the case, in other words differing from >> real-time >> > > > > apply and >> > > > > xorg initially start applies. >> > > > > ........ >> > > > > >> > > > > >> > > > _______________________________________________ >> > > > freebsd-current@freebsd.org mailing list >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > > > To unsubscribe, send any mail to " >> > > freebsd-current-unsubscribe@freebsd.org" >> > > > >> > > > >> > > >> > > >> > > -- >> > > Tomoaki AOKI >> > > >> >> >> -- >> Tomoaki AOKI >> > From owner-freebsd-current@freebsd.org Wed Jun 7 06:10:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61CA5BFC3AB for ; Wed, 7 Jun 2017 06:10:32 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e: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 3D75A2ED1 for ; Wed, 7 Jun 2017 06:10:32 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x235.google.com with SMTP id 9so1914908pfj.1 for ; Tue, 06 Jun 2017 23:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jJycZd2ShdRxrehpwVo/Ej56qcM1uXfmWOpl+I1T+vw=; b=NMJI+qLBjWA2GjNZCB9Ji63VTGJhtkwhNHbrB2+dJdnpr0Lt0vCBSIv66eUH4u+q/s GGpR1qsGBGcqmtYLEIpMngyCAMbjyo946I4n4IZF1xmdpzmiQ0sjeRW0E87iUxcqMVAM MgfryRoghqlQc08Cyz+AsGSx4rMhWKE3Ldxn7ODH7a7KFQfGixzcrHCn3UEmxM8ULfgr YvneOeuvAeR0LssUGBKYpr3y8puvEk1ex5Mc9MaehXvalx48NjLYWjGM9RluoG3RJ8A/ bfP60bQdIJZMe6Yq+Zlcsyn+pLEQBmjsZxNw1uyzdksyrug8k9TlCDxzFlTNe29ZyJD8 KSZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jJycZd2ShdRxrehpwVo/Ej56qcM1uXfmWOpl+I1T+vw=; b=mDc4vThkFZnTAo5p9fO9Twg7oxeTIKxwbpdW01XM800LWxo5dQxv/hkfuyM02uBiws J6p6RUobkPhhYeezVDWj/rWgHysBgNUOHNjlGBUIhq4hXNWQXCilfsevuCXEv6jDqshb 2Q3gYuFTLqwtMjrgdr4HCPF6AeIRE58MKqxvoxKViW2Uhd5DJSCscVaCPo/3IZwzGwAf VFFpFO+5UrxGr5/FNUk1gHi923eIp3r0Gr2o5edYFUPQtxTt2Pw0UtH9ppUfCIorXAHw RNnvxJ3lb1lEjsc6LKfqwy8csABy7qr6NlDHqLOtDs7nxptdPg9xz6nRrbIAEi8Wr/20 ZYag== X-Gm-Message-State: AODbwcBoqWX8hiOn3GALMm9huPedafM05IA+mg3ekn09I1Bv3c+jyjIj x/OA5cvnU+zJIgpMdAk5oyrum8sfR5Cc X-Received: by 10.84.217.90 with SMTP id e26mr14648523plj.161.1496815831467; Tue, 06 Jun 2017 23:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Tue, 6 Jun 2017 23:10:31 -0700 (PDT) From: blubee blubeeme Date: Wed, 7 Jun 2017 14:10:31 +0800 Message-ID: Subject: [sed] command failure? Porting a project to FreeBSD To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 06:10:32 -0000 Hello I am trying to bring these updated print drivers to FreeBSD: https://github.com/utsushi/utsushi.git There's the automake scripts in there that's sorta helpful but I seem to have gotten stuck with something. I made sure that my environmental variables are set LDFLAGS -L/usr/local/lib CPPFLAGS -I/usr/local/include i run autoreconf -fmi that does it's thing and everything goes smoothly ./configure also seems to run just fine when I run make there's a problem; sed command just hangs, it's been there for hours now and no change. the line in the makefile looks like this: $(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \ $(srcdir)/lib/tag.xsl format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \ sed -n \ -e "/^/{ /-->/d; s|^$$|//|p; s|^....|//|p; }' $< > $@; \ xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@ sed -i 's/SEC_N_("%1%")/"%1%"/' $@ I am not the best with sed but I feel like there might be some issues; I am running tcsh shell, it could be it or that command is malformed. Trying to run the same make file with gmake, I get this output. format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \ sed -n \ -e "/^/{ /-->/d; s|^$|//|p; s|^....|//|p; }' lib/tag.xml > lib/tag.cpp; \ xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >> lib/tag.cpp sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp sed: 1: "lib/tag.cpp": extra characters at the end of l command gmake: *** [Makefile:1042: lib/tag.cpp] Error 1 extra character at the end of | command. It's a bit unclear to me. There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be a sed issue. Any assistance would be appreciated. Best, Owen From owner-freebsd-current@freebsd.org Wed Jun 7 06:26:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16A7FBFC815 for ; Wed, 7 Jun 2017 06:26:04 +0000 (UTC) (envelope-from amutu@amutu.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 D857C3699 for ; Wed, 7 Jun 2017 06:26:03 +0000 (UTC) (envelope-from amutu@amutu.com) Received: by mail-ot0-x22b.google.com with SMTP id a2so2041679oth.2 for ; Tue, 06 Jun 2017 23:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amutu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xxtU2ZV0H0Sr/pMlschdBOJcXvyk+fMf/MgD//8yiXw=; b=ysyvn+CTeGOItIGxa26Z+uiCK3pHoHBdBZvFcVdmtFhbHEI9xmUg2C8+qiB0FzKr1S zS+/2y85vJPykfgqSo2aNR5O9Cy36k0y1A2i4Oiol+3o66KiGMMBsnc8t4/ANSdLi6Id g+RFm2fSif6KjtmC+n9ogv0QvGWdwtkAwOFOWUYTMESAUh9EMum/oKIh86OmKgxGDJ6J dXVde1a/1UtHHIwxNLACGLqtoCyp0AlR0351RxHFPjAWZz8KsctpcQBdKrvoyaaySfAN hwveCXHrxhAlr094CFFFZPaKcbQU1j84qpGHxMCuHuqLR2geCI4iQFNlmbwi2f5ipgcG DnhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xxtU2ZV0H0Sr/pMlschdBOJcXvyk+fMf/MgD//8yiXw=; b=g+RkZR0w4AQBsoFf7mNZrlAnrSAd1QebAmh7fMTsERcin7gx1wQS6QNxV6MdVaY85B F61gowm95Du7+O6SQ8wDKGoQOwp1rdz7Ex0JDdIqyhNioiMrIwACHtxan98U4ZZzojTt FXd4KnKD1c7Wshe+d+TipRshDFRoua0w1P74LCae98r789DWt4dhDZGhucxr2MlUgdLQ XjBJkh/vmWsOWR3VntsTmltAf5+hZb/ucxV7n5tpvpV7bBvhgmzertmkDCOEWtWg4jn1 liXOMwO10bZdp2v1ZMddm7Pve5LMm7Jr3CwdMUEzeH0UADpYmreazDINcqAuFH3cNrGg lV/A== X-Gm-Message-State: AKS2vOxFCMWLjLn3PwswSiNcZyBn32D1vWS8uysuELBREy3YarP2D8X1 mBeJZCNB9To/mHGYkaLYiQ== X-Received: by 10.157.21.61 with SMTP id u58mr14804805otf.126.1496816763031; Tue, 06 Jun 2017 23:26:03 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id h71sm460464oic.16.2017.06.06.23.26.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 23:26:02 -0700 (PDT) Received: by mail-oi0-f45.google.com with SMTP id o65so1614573oif.1 for ; Tue, 06 Jun 2017 23:26:02 -0700 (PDT) X-Received: by 10.202.44.134 with SMTP id s128mr13209517ois.7.1496816762290; Tue, 06 Jun 2017 23:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.133.136 with HTTP; Tue, 6 Jun 2017 23:25:41 -0700 (PDT) In-Reply-To: References: From: Jov Date: Wed, 7 Jun 2017 14:25:41 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [sed] command failure? Porting a project to FreeBSD To: blubee blubeeme Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 06:26:04 -0000 The default sed on FreeBSD is different from GNU sed,there is some limit for bsd sed.You can try to patch the makefile to using gsed. 2017-06-07 14:10 GMT+08:00 blubee blubeeme : > Hello > > I am trying to bring these updated print drivers to FreeBSD: > https://github.com/utsushi/utsushi.git > > > There's the automake scripts in there that's sorta helpful but I seem to > have gotten stuck with something. > > I made sure that my environmental variables are set > LDFLAGS -L/usr/local/lib > CPPFLAGS -I/usr/local/include > > i run autoreconf -fmi > that does it's thing and everything goes smoothly > > ./configure also seems to run just fine > > when I run make there's a problem; sed command just hangs, it's been there > for hours now and no change. > > the line in the makefile looks like this: > $(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \ > $(srcdir)/lib/tag.xsl > format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \ > sed -n \ > -e "/^/{ /-->/d; s|^$$|//|p; s|^....|//|p; }' $< > $@; \ > xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@ > sed -i 's/SEC_N_("%1%")/"%1%"/' $@ > > I am not the best with sed but I feel like there might be some issues; I am > running tcsh shell, it could be it or that command is malformed. > > Trying to run the same make file with gmake, I get this output. > > format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \ > sed -n \ > -e "/^/{ /-->/d; s|^$|//|p; s|^....|//|p; }' lib/tag.xml > > lib/tag.cpp; \ > xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >> > lib/tag.cpp > sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp > sed: 1: "lib/tag.cpp": extra characters at the end of l command > gmake: *** [Makefile:1042: lib/tag.cpp] Error 1 > > extra character at the end of | command. It's a bit unclear to me. > > There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be a > sed issue. > > Any assistance would be appreciated. > > Best, > Owen > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Wed Jun 7 07:30:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 210CBBFD65C for ; Wed, 7 Jun 2017 07:30:40 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from turad.lysandor.de (turad.lysandor.de [136.243.10.60]) (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 C0A5864FB4 for ; Wed, 7 Jun 2017 07:30:39 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from localhost (localhost [127.0.0.1]) by turad.lysandor.de (Postfix) with ESMTP id CDCD9AACF15 for ; Wed, 7 Jun 2017 09:20:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at turad.lysandor.de Received: from turad.lysandor.de ([127.0.0.1]) by localhost (turad.lysandor.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id l2A9VKRbV9W6 for ; Wed, 7 Jun 2017 09:20:39 +0200 (CEST) Received: from [192.168.2.105] (p4FDCCE85.dip0.t-ipconnect.de [79.220.206.133]) (Authenticated sender: flo@snakeoilproductions.net) by turad.lysandor.de (Postfix) with ESMTPSA id BAA15AAC37B for ; Wed, 7 Jun 2017 09:20:39 +0200 (CEST) From: Florian Limberger To: freebsd-current@freebsd.org Subject: undefined reference to `em_intr' Message-ID: Date: Wed, 7 Jun 2017 09:20:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 07:30:40 -0000 Hi, since two or three weeks I'm unable to build the -CURRENT kernel due to undefined references to `em_intr`. The build commandline is `make -j2 KERNCONF=3DGENERIC-NODEBUG buildkernel`. Due to the ino64-change, I've cleared /usr/obj to rebuild everything. Also, I'm using meta-mode. The error-log, /etc/src.conf, /etc/src-env.conf and /etc/make.conf as well as the output of dmesg are included below. Regards flo ~~~ Build log: Building /usr/obj/usr/src/sys/GENERIC-NODEBUG/kernel.full [104/1782] --- kernel.full --- linking kernel.full em_txrx.o:(.data+0x38): undefined reference to `em_intr' em_txrx.o:(.data+0x78): undefined reference to `em_intr' igb_txrx.o:(.data+0x38): undefined reference to `em_intr' *** [kernel.full] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG .ERROR_TARGET=3D'kernel.full' .ERROR_META_FILE=3D'/usr/obj/usr/src/sys/GENERIC-NODEBUG/kernel.full.meta= ' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' .CURDIR=3D'/usr/obj/usr/src/sys/GENERIC-NODEBUG' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src/sys/GENERIC-NODEBUG' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' PATH=3D'/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/= usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/us= r/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.co nf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf Makefile /usr/src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk / usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk /usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/obj/usr/src/sys/GENERIC-NODEBUG' 1 error make[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG .ERROR_TARGET=3D'kernel.full' .ERROR_META_FILE=3D'/usr/obj/usr/src/sys/GENERIC-NODEBUG/kernel.full.meta= ' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose curdirOk=3Dyes' .CURDIR=3D'/usr/obj/usr/src/sys/GENERIC-NODEBUG' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src/sys/GENERIC-NODEBUG' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' PATH=3D'/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/= usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/us= r/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/[53/1782] SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.co nf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf Makefile /usr/src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk / usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/kern.post.mk /usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/obj/usr/src/sys/GENERIC-NODEBUG' *** [buildkernel] Error code 2 make[1]: stopped in /usr/src .ERROR_TARGET=3D'buildkernel' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'1' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'buildkernel' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.co nf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/sha re/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/Makefile.libcompat /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk' .PATH=3D'. /usr/src' 1 error make[1]: stopped in /usr/src .ERROR_TARGET=3D'buildkernel' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'1' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'buildkernel' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' [2/1782] PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.co nf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/sha re/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/Makefile.libcompat /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk' .PATH=3D'. /usr/src' *** [buildkernel] Error code 2 make: stopped in /usr/src .ERROR_TARGET=3D'buildkernel' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'0' MAKEFILE=3D'' .MAKE.MODE=3D'normal' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'buildkernel' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' 1 error make: stopped in /usr/src .ERROR_TARGET=3D'buildkernel' .ERROR_META_FILE=3D'' .MAKE.LEVEL=3D'0' MAKEFILE=3D'' .MAKE.MODE=3D'normal' .CURDIR=3D'/usr/src' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/usr/src' .TARGETS=3D'buildkernel' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' ~~~ /etc/src.conf: # Meta mode is enabled in /etc/src-env.conf # Faster build options WITH_FAST_DEPEND=3D YES WITH_CCACHE_BUILD=3D YES WITH_SYSTEM_COMPILER=3D YES # TODO: The documentation has only WITH= OUT_=E2=80=A6 WITHOUT_CROSS_COMPILER=3D YES # Configuration WITH_BSD_GREP=3D YES WITHOUT_DYNAMICROOT=3D YES WITHOUT_FLOPPY=3D YES WITHOUT_HYPERV=3D YES WITHOUT_IPFILTER=3D YES WITHOUT_IPFW=3D YES # WITHOUT_LIB32=3D YES # currently needed for linuxemu WITHOUT_NTP=3D YES # I use opennptd WITHOUT_UNBOUND=3D YES WITHOUT_HTML=3D YES WITHOUT_SVNLITE=3D YES WITHOUT_SYSCONS=3D YES ~~~ /etc/src-env.conf: WITH_META_MODE=3D YES ~~~ /etc/make.conf: CPUTYPE?=3D native OPTIONS_SET=3D MMX OPTIMIZATION PYTHON OPENMP SSE SSE2 SNDIO THREADS UNICODE OPTIONS_UNSET=3D AVAHI AVX AVX2 EMACS GCONF GNOME HAL LUA NOUVEAU PULSEAUDIO RUBY XML DEFAULT_VERSIONS =3D linux=3Dc7_64 DEFAULT_VERSIONS+=3D perl5=3D5.24 DEFAULT_VERSIONS+=3D python=3D2.7 python2=3D2.7 python3=3D3.6 DEFAULT_VERSIONS+=3D ruby=3D2.4 DEFAULT_VERSIONS+=3D samba=3D4.6 DEFAULT_VERSIONS+=3D ssl=3Dlibressl # Freetype2 bytecode for better fonts .if ${.CURDIR:M*/ports/print/freetype2} TTF_BYTECODE_ENABLED=3D yes .endif # Use Python3 for vim .if ${.CURDIR:M*/ports/editors/vim} PYTHON_VERSION=3D 3.6 .endif # I'm building myself, so disable debugging MALLOC_PRODUCTION=3D yes # Debug, at least for cmake based ports .if defined(${DBG}) WITH_DEBUG=3D yes ENABLE_DEBUG=3D yes DEBUG_FLAGS+=3D -g .endif ~~~ dmesg: Copyright (c) 1992-2017 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 12.0-CURRENT #11 r317280+bf9915d77795(master): Sat Apr 22 18:12:34 CEST 2017 root@nachtschatten.purplekraken.com:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT(vga): resolution 640x480 can't re-use a leaf (hwpstate_verbose)! module_register: cannot register cpu/ichss from kernel; already loaded from cpufreq.ko Module cpu/ichss failed to register: 17 module_register: cannot register cpu/powernow from kernel; already loaded from cpufreq.ko Module cpu/powernow failed to register: 17 module_register: cannot register cpu/est from kernel; already loaded from cpufreq.ko Module cpu/est failed to register: 17 module_register: cannot register cpu/hwpstate from kernel; already loaded from cpufreq.ko Module cpu/hwpstate failed to register: 17 module_register: cannot register cpu/p4tcc from kernel; already loaded from cpufreq.ko Module cpu/p4tcc failed to register: 17 CPU: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz (2660.06-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x20655 Family=3D0x6 Model=3D0x25 Step= ping=3D5 Features=3D0xbfebfbff Features2=3D0x29ae3ff AMD Features=3D0x28100800 AMD Features2=3D0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory =3D 4294967296 (4096 MB) avail memory =3D 3930447872 (3748 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: unblocking device. ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20170303/tbfadt-748) ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20170303/tbfadt-850) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Timecounter "TSC-low" frequency 1330030276 Hz quality 1000 Cuse v0.1.34 @ /dev/cuse random: entropy device external interface netmap: loaded module module_register_init: MOD_LOAD (vesa, 0xffffffff80f84830, 0) error 19 kbd1 at kbdmux0 nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: port 0xcf8-0xcff on acpi0 pci1: on pcib1 pcib2: irq 16 at device 1.0 on pci1 pci2: on pcib2 vgapci0: port 0x2000-0x207f mem 0xcc000000-0xccffffff,0xd0000000-0xdfffffff,0xce000000-0xcfffffff irq 16 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device hdac0: mem 0xcdefc000-0xcdefffff at device 0.1 on pci2 pci1: at device 22.0 (no driver attached) uart2: <5 Series/3400 Series Chipset KT Controller> port 0x1800-0x1807 mem 0xf2424000-0xf2424fff irq 17 at device 22.3 on pci1 uart2: Using 1 MSI message em0: port 0x1820-0x183f mem 0xf2400000-0xf241ffff,0xf2425000-0xf2425fff irq 20 at device 25.0 on pci1 em0: attach_pre capping queues at 1 em0: using 1024 tx descriptors and 1024 rx descriptors em0: msix_init qsets capped at 1 em0: PCIY_MSIX capability not found; or rid 0 =3D=3D 0. em0: Using an MSI interrupt em0: allocated for 1 tx_queues em0: allocated for 1 rx_queues em0: Ethernet address: f0:de:f1:46:1b:8c em0: netmap queues/slots: TX 1/1024, RX 1/1024 ehci0: mem 0xf2428000-0xf24283ff irq 23 at device 26.0 on pci1 usbus0: EHCI version 1.0 usbus0 on ehci0 usbus0: 480Mbps High Speed USB v2.0 hdac1: mem 0xf2420000-0xf2423fff irq 17 at device 27.0 on pci1 pcib3: irq 20 at device 28.0 on pci1 pci3: on pcib3 pcib4: irq 21 at device 28.1 on pci1 pci4: on pcib4 iwn0: mem 0xf2000000-0xf2001fff irq 17 at device 0.0 on pci4 pcib5: irq 20 at device 28.4 on pci1 pci5: on pcib5 sdhci_pci0: mem 0xf2100000-0xf21000ff irq 16 at device 0.0 on pci5 sdhci_pci0: 1 slot(s) allocated ehci1: mem 0xf2428400-0xf24287ff irq 19 at device 29.0 on pci1 usbus1: EHCI version 1.0 usbus1 on ehci1 usbus1: 480Mbps High Speed USB v2.0 pcib6: at device 30.0 on pci1 pci6: on pcib6 isab0: at device 31.0 on pci1 isa0: on isab0 ahci0: port 0x1818-0x181f,0x180c-0x180f,0x1810-0x1817,0x1808-0x180b,0x1840-0x185f mem 0xf2427000-0xf24277ff irq 16 at device 31.2 on pci1 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xd1fff,0xdd000-0xdffff,0xe0000-0xeffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 coretemp1: on cpu1 est1: on cpu1 coretemp2: on cpu2 est2: on cpu2 coretemp3: on cpu3 est3: on cpu3 Timecounters tick every 10.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 5 on hdaa0 hdacc1: at cad 1 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 hdacc2: at cad 2 on hdac0 hdaa2: at nid 1 on hdacc2 pcm2: at nid 5 on hdaa2 hdacc3: at cad 3 on hdac0 hdaa3: at nid 1 on hdacc3 pcm3: at nid 5 on hdaa3 hdacc4: at cad 0 on hdac1 hdaa4: at nid 1 on hdacc4 pcm4: at nid 31,25 and 27 on hdaa4 pcm5: at nid 35 on hdaa4 ugen1.1: at usbus1 ugen0.1: at usbus0 uhub0: on usbus1 uhub1: on usbus0 ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA8-ACS SATA 2.x device ada0: Serial Number WD-WXD1A1154275 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes= ) cd0: Attempt Trying to mount root from ufs:/dev/label/root [rw]... uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered ugen1.2: at usbus1 uhub2 on uhub0 uhub2: on usbus1 ugen0.2: at usbus0 uhub3 on uhub1 uhub3: on usbus0 uhub3: 6 ports with 6 removable, self powered uhub2: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ugen0.4: at usbus0 wlan0: Ethernet address: 00:24:d7:91:b5:44 iwn0: iwn_read_firmware: ucode rev=3D0x09dd0401 wlan0: link state changed to UP ubt0 on uhub3 ubt0: on usbus0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() From owner-freebsd-current@freebsd.org Wed Jun 7 07:41:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D48B0BFDA5A for ; Wed, 7 Jun 2017 07:41:00 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e: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 A517B658C6 for ; Wed, 7 Jun 2017 07:41:00 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id 83so2749031pfr.0 for ; Wed, 07 Jun 2017 00:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CBUXd+T8yy/g3dzqEGAa93OWwRMwtFTFx0MWswNrx4E=; b=EkPJBhzJCjehOsYv7TEQ8VaBLaW+HSmR3/t2d/5+hCbvBgZ9sPjRtIJZCnsrU1OSOd jUZ3Gaz7dRQT5zj51dOHYPoVr2cD60moXYBSF/O0rYCn6Yb71bfcbLq6CJDq3VhD+Sqb eLXeOP89NPzXwF76lzN+lOM+/rinC1GQSICxgkxjWjZ/89Mv4Jl3NmW1o4UHO06b26eK zXdNN7Yb2e2dmI0CLuNBY0TsYGMOqG7SHi6sG3lNkiWc1T/wemO2mLZM56jwu3lfuDTy R9zo5DanfGQVUlMxhAb5ezYaG69qN7lG0d6fOruUfRZQ+c8hs4+NHfeiADYk4SzpTTgk pj9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CBUXd+T8yy/g3dzqEGAa93OWwRMwtFTFx0MWswNrx4E=; b=P8VJJbldv4Pp29dzmrsI+SpO3qB7Q2ay/F0e3dZ53089nEI4n77eR3hYpKoNTjBvF5 X3vkESz6t1BgN7z6EcDzxXvIuAlBg/xEfBAbeCyphwH15DANRhr1D5TbPPFwRSWPkQ21 3PMMyN3sQ0ERNqvla70Ib7D/pNJ/A9DYopR2NLVhOMzcDFIBgJ9X1xrE8H+dq/XA1vwc 2phdxvZc1SaLu/kMuNZBczL0w+eLLhRzcBbqUBhtCCaPFW8u5KoazhMbmjhHn7ln+dCI +f16bvoG9O9+mputMOg6HUYT2Cv5ZF7D+qIjAr6OU+AZMJaGMkpMHnmamrEYfGlWoReD ok8g== X-Gm-Message-State: AODbwcBqvHoEUMDEHNN3ikkxUDxwoHux99vsEBjRunvln1uwClU8Zo+w iQsJhSymjG3L+OxrLPg+oIoscKn2wA== X-Received: by 10.98.252.77 with SMTP id e74mr18313331pfh.42.1496821260185; Wed, 07 Jun 2017 00:41:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: blubee blubeeme Date: Wed, 07 Jun 2017 07:40:49 +0000 Message-ID: Subject: Re: [sed] command failure? Porting a project to FreeBSD To: Jov Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 07:41:00 -0000 Ahhh, that was it. Doing a find and ask to replace all instances of sed with gsed passed that part. By the way, is knowledge like this written down somewhere centralized or is it just floating in the ether? Thank you, Owen On Wed, Jun 7, 2017, 14:26 Jov wrote: > The default sed on FreeBSD is different from GNU sed,there is some limit > for bsd sed.You can try to patch the makefile to using gsed. > > 2017-06-07 14:10 GMT+08:00 blubee blubeeme : > >> Hello >> >> I am trying to bring these updated print drivers to FreeBSD: >> https://github.com/utsushi/utsushi.git >> >> >> There's the automake scripts in there that's sorta helpful but I seem to >> have gotten stuck with something. >> >> I made sure that my environmental variables are set >> LDFLAGS -L/usr/local/lib >> CPPFLAGS -I/usr/local/include >> >> i run autoreconf -fmi >> that does it's thing and everything goes smoothly >> >> ./configure also seems to run just fine >> >> when I run make there's a problem; sed command just hangs, it's been there >> for hours now and no change. >> >> the line in the makefile looks like this: >> $(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \ >> $(srcdir)/lib/tag.xsl >> format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \ >> sed -n \ >> -e "/^/{ /-->/d; s|^$$|//|p; s|^....|//|p; }' $< > $@; \ >> xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@ >> sed -i 's/SEC_N_("%1%")/"%1%"/' $@ >> >> I am not the best with sed but I feel like there might be some issues; I >> am >> running tcsh shell, it could be it or that command is malformed. >> >> Trying to run the same make file with gmake, I get this output. >> >> format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \ >> sed -n \ >> -e "/^/{ /-->/d; s|^$|//|p; s|^....|//|p; }' lib/tag.xml > >> lib/tag.cpp; \ >> xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >> >> lib/tag.cpp >> sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp >> sed: 1: "lib/tag.cpp": extra characters at the end of l command >> gmake: *** [Makefile:1042: lib/tag.cpp] Error 1 >> >> extra character at the end of | command. It's a bit unclear to me. >> >> There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be >> a >> sed issue. >> >> Any assistance would be appreciated. >> >> Best, >> Owen >> > _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-current@freebsd.org Wed Jun 7 08:54:26 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8593DBFEFC7 for ; Wed, 7 Jun 2017 08:54:26 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (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 4C5DF67A5C for ; Wed, 7 Jun 2017 08:54:26 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id F2A6C42ED1; Wed, 7 Jun 2017 10:54:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVZ7y67VZbwP; Wed, 7 Jun 2017 10:54:21 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 37B4942ED0; Wed, 7 Jun 2017 10:54:21 +0200 (CEST) Subject: Re: [sed] command failure? Porting a project to FreeBSD To: blubee blubeeme , Jov Cc: FreeBSD current References: From: Willem Jan Withagen Message-ID: Date: Wed, 7 Jun 2017 10:54:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: nl Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 08:54:26 -0000 On 07/06/2017 09:40, blubee blubeeme wrote: > Ahhh, that was it. Doing a find and ask to replace all instances of sed > with gsed passed that part. > > By the way, is knowledge like this written down somewhere centralized or is > it just floating in the ether? >From my experience of porting Ceph.... (And I agree with HPS, that if it looks a like, it does not have to be the same.) Most of these thing you have to find out on your own. But that is also the fun of porting: issue arise from the strangest of corners. Regular expression are among the most notorious, some of the Linux tools also use Perl REs. Something the basic FreeeBSD will not do, since it requires pulling Perl into base. So for most of the tools, there is also a GNU equivalent, so that is usually the first thing to look at. Even more tricky are the tools you can install, but hat the same name as their base counterpart. Like getopt, where the packaged one understands a completely different set of options. Not sure if you will be running into bash, but that ends up in /usr/local/bin, whilest just about every script expects /bin/sh to be bash. Even things like /usr/bin/env do not work the same way, and or have the same parameters. So even there it does not always help. --WjW From owner-freebsd-current@freebsd.org Wed Jun 7 09:06:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FD2DBFF38E for ; Wed, 7 Jun 2017 09:06:55 +0000 (UTC) (envelope-from amutu@amutu.com) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 6136268091 for ; Wed, 7 Jun 2017 09:06:55 +0000 (UTC) (envelope-from amutu@amutu.com) Received: by mail-ot0-x231.google.com with SMTP id t31so3756524ota.1 for ; Wed, 07 Jun 2017 02:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amutu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5wZm/krXkHCf1jdMIKawAgsn+vaKEIa1AJFehTVHVTQ=; b=zjFz670tdXOrnhKSUUTnBvzp9cEXNymJZv19Gz7n7I9jLouhQBdaGF9UCnKpWhIQXs JsJlGNOJglB+uZIuRqEp+WAUsVlIZ+nQopWVfIF8Ts6WUWQOzRSCcqSczXDIIvI4i3NK eyOemTK7Lg5w1PlxP3UOt3H+boUw8jOTV71un1QLMS9YkVx+vW9V+UgemFBHfKXcJiit 7Gi4uP8E1viPlgtUBu3NN76VcHdWQdR4D9BgNUOHilx0hn0YA0d0L7aNsMkU9v6oyiyN lSK6EIcbCaqs/zZWkdVTHalG0ZA0oOOVUEi5YPJGDVJ1N6SQ1xuO2j7RdDqiVKTsSB5o AxtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5wZm/krXkHCf1jdMIKawAgsn+vaKEIa1AJFehTVHVTQ=; b=Ff3oxx8rEwMocom4rMVCx1wAocXXtwpKLvZp+5in9wF1F5HSKeUAzPjaJmimwApVvo HDHKRv/EqnSi8jiC5r9NDosZAr4c0/whxJ4kJfZyg/pK/YCRNCgsYfkRdqixydASwwlY 9qNisJVP+ytzFNkPiq/Hb+90I2fKcKR+zfcbAVtgfTJofDuNzHaIfYdGZ9dA3rBxfKvN jls7szoz+LRT/HwxEoj2jGoVgZ24RBPNEdb4O/4GeN1PuETYv1FqhKtu9lLY01ItArKe n2wUYY/n77/UgwlnbXGqU5jRtPMCzFbyuELXqGwskhdFUKJyGiI7Uw9SwWQHTmFM6QTm 80LQ== X-Gm-Message-State: AKS2vOz0wjM22Czk6kox4RGZEdLWjb93CFu520lizMFUkmgtzQ5Gyrs7 Ws00L1+uGJJNxTzstacRNA== X-Received: by 10.157.54.145 with SMTP id h17mr3682291otc.104.1496826414527; Wed, 07 Jun 2017 02:06:54 -0700 (PDT) Received: from mail-ot0-f179.google.com (mail-ot0-f179.google.com. [74.125.82.179]) by smtp.gmail.com with ESMTPSA id g29sm623822ote.2.2017.06.07.02.06.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 02:06:53 -0700 (PDT) Received: by mail-ot0-f179.google.com with SMTP id a2so3732618oth.2 for ; Wed, 07 Jun 2017 02:06:53 -0700 (PDT) X-Received: by 10.157.60.118 with SMTP id j51mr14927746ote.127.1496826413527; Wed, 07 Jun 2017 02:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.133.136 with HTTP; Wed, 7 Jun 2017 02:06:33 -0700 (PDT) In-Reply-To: References: From: Jov Date: Wed, 7 Jun 2017 17:06:33 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [sed] command failure? Porting a project to FreeBSD To: blubee blubeeme Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 09:06:55 -0000 I don't think there is. Man page of FreeBSD tool may have a section of STANDARDS and/or COMPATIBILITY, but it does not list all the difference with GNU version. 2017-06-07 15:40 GMT+08:00 blubee blubeeme : > Ahhh, that was it. Doing a find and ask to replace all instances of sed > with gsed passed that part. > > By the way, is knowledge like this written down somewhere centralized or > is it just floating in the ether? > > Thank you, > Owen > > On Wed, Jun 7, 2017, 14:26 Jov wrote: > >> The default sed on FreeBSD is different from GNU sed,there is some limit >> for bsd sed.You can try to patch the makefile to using gsed. >> >> 2017-06-07 14:10 GMT+08:00 blubee blubeeme : >> >>> Hello >>> >>> I am trying to bring these updated print drivers to FreeBSD: >>> https://github.com/utsushi/utsushi.git >>> >>> >>> There's the automake scripts in there that's sorta helpful but I seem to >>> have gotten stuck with something. >>> >>> I made sure that my environmental variables are set >>> LDFLAGS -L/usr/local/lib >>> CPPFLAGS -I/usr/local/include >>> >>> i run autoreconf -fmi >>> that does it's thing and everything goes smoothly >>> >>> ./configure also seems to run just fine >>> >>> when I run make there's a problem; sed command just hangs, it's been >>> there >>> for hours now and no change. >>> >>> the line in the makefile looks like this: >>> $(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \ >>> $(srcdir)/lib/tag.xsl >>> format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \ >>> sed -n \ >>> -e "/^/{ /-->/d; s|^$$|//|p; s|^....|//|p; }' $< > $@; \ >>> xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@ >>> sed -i 's/SEC_N_("%1%")/"%1%"/' $@ >>> >>> I am not the best with sed but I feel like there might be some issues; I >>> am >>> running tcsh shell, it could be it or that command is malformed. >>> >>> Trying to run the same make file with gmake, I get this output. >>> >>> format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \ >>> sed -n \ >>> -e "/^/{ /-->/d; s|^$|//|p; s|^....|//|p; }' lib/tag.xml > >>> lib/tag.cpp; \ >>> xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >> >>> lib/tag.cpp >>> sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp >>> sed: 1: "lib/tag.cpp": extra characters at the end of l command >>> gmake: *** [Makefile:1042: lib/tag.cpp] Error 1 >>> >>> extra character at the end of | command. It's a bit unclear to me. >>> >>> There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to >>> be a >>> sed issue. >>> >>> Any assistance would be appreciated. >>> >>> Best, >>> Owen >>> >> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >>> freebsd.org" >>> >> >> From owner-freebsd-current@freebsd.org Wed Jun 7 09:30:39 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F6E1BFFB21 for ; Wed, 7 Jun 2017 09:30:39 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 002CA68E4A for ; Wed, 7 Jun 2017 09:30:38 +0000 (UTC) (envelope-from henry.vogt@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id n195so6904556wmg.1 for ; Wed, 07 Jun 2017 02:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=C5jyhDfyuT1V1V8Upw+DYQ3IsXBpDnPNjkUWDxrWFUQ=; b=cELuJxlDSDHgwODZXAlGjHWsZ2o+o7QZZxPbiK2WsaGbHpxMb2YCdyFSz1tFsb03F+ A9x0weAOhpZGuurVQRH5kVfui+uON5XrlziMKueaVl2yETtwJcmeVbPCWTGkIjiybNcP uAL5YUIitO3A6cUm9ZksPibElwdxMvXF8Dni3h3PA9fIyV9gP7t9XqZo8wvtq07Duw0x XvSu2GhtekBtv8iqP4P0aa1xos/TETwgP8DEVH9oTprCo2/Hie6JCwEwnweGHyQHGCAC 0poJ6dRAY5ECaldiDuifSbNGuANvgMd2See4DldDOR26EDFpIortom73nBniNBd+ClZ1 5Elw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=C5jyhDfyuT1V1V8Upw+DYQ3IsXBpDnPNjkUWDxrWFUQ=; b=dEup9inoDWaAQ7R1PyTcoFcedHYFUCvTNKlxp8n4CNWJX0Y+vXhSiuxgbnIDiMLF+Y CauV9sbqtGQyREt2TpXR/XgMWTN6ZJ/NXJKrD4GS8Pb2F+qSgFc2V4v/GMz3Bjjprcf/ VXWKT9447cZMDRDJyqCZDlXNWb7Gg77PXWUpoRh0pQMvB+UWTfuK3GdLs7RmTA7cuOc1 Pi0/Uzhp+aeAVb4hpnlTysZFiNQJBM3n8O10pqzY5gooXE1enxQpsM1l4MJZMtgm75af R6Hi0tMwL4xNZdhmvwFgHQsTxj615cPPE1ydQS8PtVmh3VhRZL/5cZrK98liXa7QudU7 +hZg== X-Gm-Message-State: AODbwcDhN6YNoo8X6Q21F7VAzrZ5jeUzthrWGo13HlFp9wm86no/laoe fswRC+bBvnxLkjHj X-Received: by 10.80.158.99 with SMTP id z90mr12746431ede.144.1496827837339; Wed, 07 Jun 2017 02:30:37 -0700 (PDT) Received: from woody.local (p4FE76B3F.dip0.t-ipconnect.de. [79.231.107.63]) by smtp.googlemail.com with ESMTPSA id f48sm748759eda.42.2017.06.07.02.30.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 02:30:36 -0700 (PDT) Subject: Re: [sed] command failure? Porting a project to FreeBSD To: freebsd-current@freebsd.org References: From: Henry Vogt Message-ID: <5d82dba3-3860-8a74-5d59-1d69738411f2@gmail.com> Date: Wed, 7 Jun 2017 11:30:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 09:30:39 -0000 Am 07.06.17 um 11:06 schrieb Jov: > I don't think there is. > Man page of FreeBSD tool may have a section of STANDARDS and/or > COMPATIBILITY, but it does not list all the difference with GNU version. Greg Leheys 'Porting Unix Software' published by O'Reilly and later re-released under Creative Commons, exists for 20 years. Some bits may be outdated, but still useful. Best Henry -- Henry Vogt From owner-freebsd-current@freebsd.org Wed Jun 7 09:34:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1279FBFFCD7 for ; Wed, 7 Jun 2017 09:34:05 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 DACCC6A214 for ; Wed, 7 Jun 2017 09:34:04 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x22e.google.com with SMTP id f185so3550468pgc.0 for ; Wed, 07 Jun 2017 02:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GGcIvjRImhEb5zy5nbakt6f6bSRWcKyJzWljirIHOZA=; b=r11AOrfhgP3Tu/82KC/f1V+WYwmNebqdgw23xDJQ0uaExZtOlHm44mD6ZYRaMbqKMf 16yooxCyfITLyR0i9qCQPyKyid1oZrlZLyiMJ84rEHCDNqq4OZmNwwHZlSQqPu/w5tqw FFmk3GY8XZjUL7Yo3bJC8mcJw0lOUWnM+1th+1fwGFm44lWWlLf90jPuFWMNYPUslGez /f0Y5CPZowmdDTeu+DGoX/dxQZPcp905XLi8EA43sEZJIfHLnwMZByhmR/se/Eu0lJuZ WjZqsuVhTx3qGHl0IACZXvDB9xy7ji/K/tZZH4u1Xm7MYGiwuqwwkcoch3CDXGwlbm3Q yqKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GGcIvjRImhEb5zy5nbakt6f6bSRWcKyJzWljirIHOZA=; b=IZaHYYIB9bveT18pMMOh26OYD9vex41KwORKcQrSCOczRyVYNryT82/IfjDe/npU2A gE/1xiCmzXYKF4ela5HVDHnA/kmegVY1dhtPkORFg/xgTBPHu+itH+tHgZAYGQpinChi FhzwDSTl4bfWZSuP0j9zsCUeSq3upU+LG+4ik08zWB78ef1RmkV2nZfz4lfEXcxQfWwz f5Kse0UW3Y/EXYXIz4qUUUsQiMSGCl0BU4UgiNd9zKxCuvo0w6HLqi2pRPPAJUnzs+b7 cnqsQDcdtPvWPNbQArqTDo/GbjZjvJaNkf/w6bnyDyOIsZx8mBd69AsOz13kCQUhtGhM ix8w== X-Gm-Message-State: AODbwcCZlQ1j48weqy3L5E08AfXNskH35/KTsLuA90gG9OBFw+aOaR3r Gh7K+islYP6dT0W8roeYzv5lqJNTzg== X-Received: by 10.84.210.194 with SMTP id a60mr17187048pli.17.1496828044250; Wed, 07 Jun 2017 02:34:04 -0700 (PDT) MIME-Version: 1.0 From: blubee blubeeme Date: Wed, 07 Jun 2017 09:33:53 +0000 Message-ID: Subject: [libltdl] removal from gnu ports To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 09:34:05 -0000 Hi I'm sure I was reading yesterday on a different machine about the linker flag -ld which has something to do with gnu dlopen and how it's ok to remove those from your Makefile since FreeBSD handles dlopen and a few other things from that header in the standard libc. Is that correct? I'm seeing some errors when running make because of #include LT_CONFIG_H Those files in this instance also handles dlopen and related system calls. It should also be safe up remove those "ltdl" headers from the Makefile as well? Best, Owen From owner-freebsd-current@freebsd.org Wed Jun 7 10:33:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C48BC090B4 for ; Wed, 7 Jun 2017 10:33:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) 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 "theravensnest.org", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 518E46E89B for ; Wed, 7 Jun 2017 10:33:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host81-140-166-137.range81-140.btcentralplus.com [81.140.166.137]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v57AXcxO006935 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Jun 2017 10:33:41 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host host81-140-166-137.range81-140.btcentralplus.com [81.140.166.137] claimed to be [192.168.1.65] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [libltdl] removal from gnu ports From: David Chisnall In-Reply-To: Date: Wed, 7 Jun 2017 11:33:32 +0100 Cc: FreeBSD current Content-Transfer-Encoding: quoted-printable Message-Id: <224BF120-F91A-4997-9920-90225E55393B@FreeBSD.org> References: To: blubee blubeeme X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 10:33:49 -0000 On 7 Jun 2017, at 10:33, blubee blubeeme wrote: >=20 > Hi >=20 > I'm sure I was reading yesterday on a different machine about the = linker > flag -ld which has something to do with gnu dlopen and how it's ok to > remove those from your Makefile since FreeBSD handles dlopen and a few > other things from that header in the standard libc. >=20 > Is that correct? Do you mean -ldl? If so, then yes. On Linux, the dl* symbols are only = exported from ld-linux.so if you link against libdl. On FreeBSD, they = are exported from rtld regardless. David From owner-freebsd-current@freebsd.org Wed Jun 7 11:13:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 206DDC09BF2 for ; Wed, 7 Jun 2017 11:13:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 9E4EA6FE1C; Wed, 7 Jun 2017 11:13:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v57BDVtt064656 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Jun 2017 14:13:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v57BDVtt064656 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v57BDVOf064655; Wed, 7 Jun 2017 14:13:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Jun 2017 14:13:31 +0300 From: Konstantin Belousov To: David Chisnall Cc: blubee blubeeme , FreeBSD current Subject: Re: [libltdl] removal from gnu ports Message-ID: <20170607111331.GJ2088@kib.kiev.ua> References: <224BF120-F91A-4997-9920-90225E55393B@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <224BF120-F91A-4997-9920-90225E55393B@FreeBSD.org> User-Agent: Mutt/1.8.2 (2017-04-18) 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.23 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, 07 Jun 2017 11:13:38 -0000 On Wed, Jun 07, 2017 at 11:33:32AM +0100, David Chisnall wrote: > On 7 Jun 2017, at 10:33, blubee blubeeme wrote: > > > > Hi > > > > I'm sure I was reading yesterday on a different machine about the linker > > flag -ld which has something to do with gnu dlopen and how it's ok to > > remove those from your Makefile since FreeBSD handles dlopen and a few > > other things from that header in the standard libc. > > > > Is that correct? > > Do you mean -ldl? If so, then yes. On Linux, the dl* symbols are only exported from ld-linux.so if you link against libdl. On FreeBSD, they are exported from rtld regardless. Symbols from the dynamic linker are always exported. Issue is that the dynamic linker is never specified as the library on the static linker (ld) command line. Linux puts stabs for the rtld symbols into libdl.so, while FreeBSD provides weak symbols in the libc.so dynamic symbol table. As result, FreeBSD does not need -ldl for access to dl*(3), and does not provide libdl.so. FreeBSD scheme is problematic because rtld have to prefer non-weak symbols over weak, to have dynamic binaries to use real rtld symbols and not libc stubs. It is non-compliant with the ELF spec. Unfortunately, it is used also in other places, making us stuck with the non-compliant behaviour. From owner-freebsd-current@freebsd.org Wed Jun 7 12:35:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 684F8C27BDB for ; Wed, 7 Jun 2017 12:35:42 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28C6372AB0 for ; Wed, 7 Jun 2017 12:35:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [2.247.254.247] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dIaBQ-0003Ov-HF for freebsd-current@freebsd.org; Wed, 07 Jun 2017 14:35:32 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v57CZV20004950 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 7 Jun 2017 14:35:31 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v57CZVn3004949 for freebsd-current@freebsd.org; Wed, 7 Jun 2017 14:35:31 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 7 Jun 2017 14:35:31 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: mount_smbfs gives error when stored crypted pw is used Message-ID: <20170607123531.GA4867@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20170606100034.GA4245@c720-r314251> <20170606123738.GA5213@c720-r314251> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20170606123738.GA5213@c720-r314251> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 2.247.254.247 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 12:35:42 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have located the bug in /usr/src/contrib/smbfs/lib/smb/subr.c=20 The printf(3C) calls have been added for debugging; the bug is the addition of 13 after crypting every char which let the mask used in ^ opera= tion exceeding 256, i.e. more than one byte, if the string to be crypted is long enough. The two lines added: if (pos > 256) pos =3D pos-256; fixes this issue and the crypting/decypting works fine; see below; I'll later file a PR and propose the patch; matthias char * smb_simplecrypt(char *dst, const char *src) { int ch, pos; char *dp; printf("smb_simplecrypt(): pw: [%s]\n", src); if (dst =3D=3D NULL) { dst =3D malloc(4 + 2 * strlen(src)); if (dst =3D=3D NULL) return NULL; } dp =3D dst; *dst++ =3D '$'; *dst++ =3D '$'; *dst++ =3D '1'; pos =3D 27; while (*src) { ch =3D *src++; printf("ch [%c] --> ", ch); if (isascii(ch)) ch =3D (isupper(ch) ? ('A' + (ch - 'A' + 13) % 26) : islower(ch) ? ('a' + (ch - 'a' + 13) % 26) : ch); ch ^=3D pos; pos +=3D 13; if (pos > 256) pos =3D pos-256; sprintf(dst, "%02x", ch); printf("0x%02x next ^mask (pos): 0x%02x\n", ch, pos); dst +=3D 2; } *dst =3D 0; return dp; } $ ./smbpw smb_simplecrypt(): pw: [1234567890-1-1234567] ch [1] --> 0x2a next ^mask (pos): 0x28 ch [2] --> 0x1a next ^mask (pos): 0x35 ch [3] --> 0x06 next ^mask (pos): 0x42 ch [4] --> 0x76 next ^mask (pos): 0x4f ch [5] --> 0x7a next ^mask (pos): 0x5c ch [6] --> 0x6a next ^mask (pos): 0x69 ch [7] --> 0x5e next ^mask (pos): 0x76 ch [8] --> 0x4e next ^mask (pos): 0x83 ch [9] --> 0xba next ^mask (pos): 0x90 ch [0] --> 0xa0 next ^mask (pos): 0x9d ch [-] --> 0xb0 next ^mask (pos): 0xaa ch [1] --> 0x9b next ^mask (pos): 0xb7 ch [-] --> 0x9a next ^mask (pos): 0xc4 ch [1] --> 0xf5 next ^mask (pos): 0xd1 ch [2] --> 0xe3 next ^mask (pos): 0xde ch [3] --> 0xed next ^mask (pos): 0xeb ch [4] --> 0xdf next ^mask (pos): 0xf8 ch [5] --> 0xcd next ^mask (pos): 0x05 ch [6] --> 0x33 next ^mask (pos): 0x12 ch [7] --> 0x25 next ^mask (pos): 0x1f cp: [$$12a1a06767a6a5e4ebaa0b09b9af5e3eddfcd3325] smb_simpledecrypt(): hash: [$$12a1a06767a6a5e4ebaa0b09b9af5e3eddfcd3325] gi= ves clear [1234567890-1-1234567] --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =E2=98=8E +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi=C3=B3 la Guerra. May 8, 1945: Who does not celebrate lost the War. --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlk38w0ACgkQR8z35Hb+ nRFD6xAAkIq+YFQlROewnDBY60FHeGuriuPByPsBXytwhIbUYWDcrwACe/GxmcEI +VxID5Lo9wuyQfYOeIxed+iyhnScWDgDyrV6G8bAP4ODz6SgsirPRy/HE8uIkNuo e5YHrMB5ZhVoK/3kmKI2eLK656VaXbV17CSsBWC8G57fpUJNyEigyUrCmGvFHdpq 0/GL0kNTGDV/WLM6TpQgVddCiIGMhXjxD7A3p2CbCLMBE4v87yRZU9eSMhgnBiCx O44yFLTePXt1JYBamwBKe3Z2HGb6HAnfe4S1g83CXezcgl57eA8JxH89oyusFoCZ p7orBIbs4n2+KHVbRPy2j0aFuBSRbzqYKlo/WtkkGmo6QaYWb5aL0z7yQGXlZ7tI NgRWuItcElTvg0faPeiSITjUymn66afdZqnPbH+z4LtQ7jSFR2nLkgjmtOG1cvxS EQH56PpkRHrUQVaPrMWNo+7TuTZBSf2b72n14Ps5mCCwKHqBfXrERZyVUx+PTGrS 6UVithD82jJe19x0Y40mb/6XFkKcN9JQNR97kaoBv4EudEBR6CNdfjbmrqTr9/ep fo1zAssQz7ClhuoLjD1XXLLNoxwtM8nygmz2znDNiW832WvdhTaotkBoyg5QzXBs 1YlbtttilmGbXmRtiPu1Jqh+jJGjMDsfBI8gCfn1gL5Nj/FXVK8= =SkAS -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@freebsd.org Wed Jun 7 17:22:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 696F6C79BD4 for ; Wed, 7 Jun 2017 17:22:40 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D3017B7EB for ; Wed, 7 Jun 2017 17:22:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.110.0] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1dIefE-0001jT-5X; Wed, 07 Jun 2017 19:22:36 +0200 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id v57HMZ6G004028 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Jun 2017 19:22:35 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id v57HMYt3004027; Wed, 7 Jun 2017 19:22:34 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 7 Jun 2017 19:22:34 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Cc: Matthias Apitz Subject: Re: mount_smbfs gives error when stored crypted pw is used Message-ID: <20170607172234.GA3972@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20170606100034.GA4245@c720-r314251> <20170606123738.GA5213@c720-r314251> <20170607123531.GA4867@c720-r314251> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20170607123531.GA4867@c720-r314251> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.110.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 17:22:40 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa mi=C3=A9rcoles, junio 07, 2017 a las 02:35:31p. m. +0200, Matth= ias Apitz escribi=C3=B3: > I have located the bug in /usr/src/contrib/smbfs/lib/smb/subr.c=20 >=20 > The printf(3C) calls have been added for debugging; the bug is the > addition of 13 after crypting every char which let the mask used in ^ ope= ration > exceeding 256, i.e. more than one byte, if the string to be crypted is lo= ng > enough. The two lines added: >=20 > if (pos > 256) > pos =3D pos-256; >=20 > fixes this issue and the crypting/decypting works fine; see below; >=20 > I'll later file a PR and propose the patch; The PR was already made in 2009: https://bugs.freebsd.org/bugzilla/show_bug= =2Ecgi?id=3D132302 has a patch attached (nearly the same solution as I have found), but was never ci'ed :-( matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =E2=98=8E +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 8. Mai 1945: Wer nicht feiert hat den Krieg verloren. 8 de mayo de 1945: Quien no festeja perdi=C3=B3 la Guerra. May 8, 1945: Who does not celebrate lost the War. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlk4NlMACgkQR8z35Hb+ nRFPEg/8D/jNZ+Qcxy8wM3j06IziChQ4UenjiQfEKewNpZig0sJXTI2ClmpKkFpR N23trcVAe5OieLfbIwtaqmogJLX8cdbi5zt1Hn7vi03W+ArlhNzvJporOugcfavC upeAHVBYPft+UftbzIih7xqPR56D9YMTUSK7LE72b2JDg3vmbeId+N1rFbKEfOdl wz7jwV5oMR2fdf4todmR6xVolHH+mPlbBLcCEapspVVk2pMgcQCwocnJyfhXxEs1 OccGcpeGsNfk5N/Pl1QrbSyypYm8xmx2WBtmixNqI0rSu0VVrDpfKNTZRzL+mUy/ 6I7w2fpzYC5vNdB0h+TkCJ6dpsq3Dlmibw2fcF1X+AikL9ijXQb54yQYV/a9i3qR FvwS7O0EepZCpLj7M/OFOslKO06Ig6dznBW+p1klbfVi+jYZqQ3oMearhiR8Sw+9 m4VWa583SOn+XZGLta798Ss+uGjlHiLBI6xG88psl0domiSf7/HRQcl3mZwTLD5B NJ/8xg6ncgwGEG2h1ZmytgIgI49MRRr/HI5LgVAkgymCyFCB0qCrIf+Fkhdv9l1E SEb0z1eKulMjFeAkFo9Uq4tZkiUkhofsBm0QFVHIXLi1Xg7VUUhEdzMwXvZf2U73 13yei3tFhwbN8wYNjnNzg+Y6J1SHOBIk6niZCPBnEXTu9SpJEak= =/1/P -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@freebsd.org Wed Jun 7 17:34:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14B27C79E3E for ; Wed, 7 Jun 2017 17:34:40 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A6A77BF1B for ; Wed, 7 Jun 2017 17:34:38 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.128.66]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lj1Cw-1drRYj1sRq-00dGSH; Wed, 07 Jun 2017 19:29:23 +0200 Date: Wed, 7 Jun 2017 19:29:15 +0200 From: "O. Hartmann" To: Matthias Apitz Cc: freebsd-current@freebsd.org Subject: Re: mount_smbfs gives error when stored crypted pw is used Message-ID: <20170607192915.28088b71@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20170607172234.GA3972@c720-r314251> References: <20170606100034.GA4245@c720-r314251> <20170606123738.GA5213@c720-r314251> <20170607123531.GA4867@c720-r314251> <20170607172234.GA3972@c720-r314251> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/IEq3dtuK6wSBbPAQ_kW830V"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:u3wQSaJc2vf5sv0W1ongfVozxrCPkhR2iFITH4XyBipvxey8hAT CT5tf2rqI0mJG/wZkuM597LIgQMBmmzn8eGNISaBwtFg11qZFR81O36nfQJV8UhKHMrhyKY bmHm71WXLt6ASVFXhd7Qzh3MvwPwmCcKyH+zs7D5RRrc1zVcfC3RNduk0UHNV+PowbnU9M/ YvojYg5KF1xrTpgN0cQtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:BeaIHwiX/5o=:0sBo7aDBto+HdmMqnf5k3y QRxlUwNVqOYe9SJ9jpIvBAFhSdIoW5FFv7xRjH6MFDtrXSVaArG3PDfUNEEjLCTCEjSSGtc1A KIvjalRX/fQGgrRGo3sQMHd/vS8Qt8MDFyDcNyZBJ+dYcRBRlTPATCVVkUVZP/icyS30+uYDw ohvF5Pcgtt9QJRKN8AWetIoAqLd4hnnvSuC9Jq0MolIRW8/QPYXNodLqM/37O9W3BxYgnBbu5 yoRA65fE9WRlHKzF+udYzzWs8Fo7BeZvz4PkslhKwTrFlPNJ5WPIt2inlGvLJY3Nq5mrfkXwK rP6AFRGPO3gBSnMfsL1i256qfOwXSHKiHP6ukEKwehwQRhHBl4v8M0AUYx4Va1SdGEwNQ7ept eQ45wbY41hT+ukb5+Zsh4Z3dLjEI55KTSGWctDQcPUb+VjsYPzJvm01qc53RFfsxg/WxS4ZwL 3v0q378zjlsinZcEK5l0pp4zn57ZlLVnftRtbyw+h90iG+WrdZ1h6AyUMgjkETiu8xvAlaLfb zmql3Su7S3dOxGVCixkZYxoUWhpRdznNLoG3mwtCjAgRWyQLksjfhYxelZ63KXvwMevlGCeLT CJSCKTCTStDGLPW1vMP9HDfbt5XYKkESCfapkoHPQTje+7Avzt8hfDtIShHJ1eEqsio8nwOA0 6L3AwbU7c+HjcBeDxvUXnnLfAwZ6bATxLGnsv9KU7iIyvzV1+tyaqM4y9L4M0TLLs1aMptbuA fzHfpzMdepY8l/X6lOQKlJhDrbu7ec3lGmNQ7vK3Bsl4ytCITFN4wzcNvI0= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 17:34:40 -0000 --Sig_/IEq3dtuK6wSBbPAQ_kW830V Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Wed, 7 Jun 2017 19:22:34 +0200 Matthias Apitz schrieb: > El d=C3=ADa mi=C3=A9rcoles, junio 07, 2017 a las 02:35:31p. m. +0200, Mat= thias Apitz escribi=C3=B3: >=20 > > I have located the bug in /usr/src/contrib/smbfs/lib/smb/subr.c=20 > >=20 > > The printf(3C) calls have been added for debugging; the bug is the > > addition of 13 after crypting every char which let the mask used in ^ o= peration > > exceeding 256, i.e. more than one byte, if the string to be crypted is = long > > enough. The two lines added: > >=20 > > if (pos > 256) > > pos =3D pos-256; > >=20 > > fixes this issue and the crypting/decypting works fine; see below; > >=20 > > I'll later file a PR and propose the patch; =20 >=20 > The PR was already made in 2009: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D132302 has a patch at= tached (nearly > the same solution as I have found), but was never ci'ed :-( >=20 > matthias >=20 >=20 Wow ... that is, simply ... not very good! :-( High quality! --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/IEq3dtuK6wSBbPAQ_kW830V Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWTg36wAKCRDS528fyFhY lIHBAgCfzFwuQ/UXdq2gVYjnz8rp4zZIlujJVqDHPFgAqGcUbryVAFdMcT3QfJII EMUCFNdc7OYMGAvvGQhBo3CgWPihAf9vDr5h0fWFhKoWP5KBhszOKznai9OFrCqf HxpWLbgIRYumqJ6HN9zcscRA2zl3EuUsRVQufL0cPcMPbahqZy6K =WCxB -----END PGP SIGNATURE----- --Sig_/IEq3dtuK6wSBbPAQ_kW830V-- From owner-freebsd-current@freebsd.org Wed Jun 7 18:27:52 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C08E9D764F6 for ; Wed, 7 Jun 2017 18:27:52 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 7EBFA7DC78 for ; Wed, 7 Jun 2017 18:27:52 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x233.google.com with SMTP id k71so7949892pgd.2 for ; Wed, 07 Jun 2017 11:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ysMUnYdKPU5hlllD/STtMvBuF8Wi45VbXtdi6a3E+KU=; b=hHkwerBC2QVObH28PDltAeIV70etGsiVT05+t76qslM7XY9OXKrTMhWJ0p+bIjxOIC m1QvxYdDoDRMK/Dfkq6lTQrxvph5ov/DXe5cBd8HP+Exrk5Pj9pKoPrTvwVbp2okY4hP ANEdBdcBQr1m9aw6aOTujKOFvZHRvOe6vgLvW9CQLRN+FTevJ+eXbPn1M8mxwOQyUSTl UeuxCLEiGuWcoo9ckRZIGA/LPwowkPW1MxFHJlN0uIUViJTwDOaXiVjQbtUCNnXzxeIN oF5zl6RVTNX7og6bYAUY+solikgG9KYDwSY/rVpc2rFhCEtBSacxl6MXtNSnOOwgGIDB oOuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ysMUnYdKPU5hlllD/STtMvBuF8Wi45VbXtdi6a3E+KU=; b=jPcBinuz1tE6CMSk9/g+aPKODE+77ZPKq5THGwixyPe/YcHwi8oh22pWXQOeSSXCYx cpkjCSK/rGPiZ8sFYxmzJiQhqk54XboZac40+3VVRkTPOSeHCKFuZv6Bnc4eN5n57sVK Zn6HC4/DqC0hW+XLB9D84IJLAqbAMMVkzhEMSQZ3adQ+uadKFaz86EWNVOjK7lRVvTlp Fayp0I3crFKrEC7hBDlgr6SoGt23gpCkCYnyT1TyNW2HEhiN5LgvKSoussES0o6oafvD +5esFA82btLW8WoWM7hV6zVchm73tOf+i44ilvkuy3TTR32qbmxTiTLfgd/KVNTIsPa8 hAwg== X-Gm-Message-State: AODbwcBC15QqoIWDcP5WLGsTnLCT/sQJj9QH330ThRjWz+lHAj93/C4F v00D1Qn0qECE/N2fknl/f8lhASGstZM/ X-Received: by 10.84.179.65 with SMTP id a59mr28631804plc.82.1496860071868; Wed, 07 Jun 2017 11:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Wed, 7 Jun 2017 11:27:51 -0700 (PDT) In-Reply-To: References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> From: blubee blubeeme Date: Thu, 8 Jun 2017 02:27:51 +0800 Message-ID: Subject: Re: nvidia drivers mutex lock To: Tomoaki AOKI Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 18:27:52 -0000 I was just looking through dmesg and noticed these: Jun 6 21:40:52 blubee kernel: nvidia-modeset: Allocated GPU:0 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI:0000:01:00.0 Jun 6 21:41:05 blubee kernel: NVRM: GPU at PCI:0000:01:00: GPU-54a7b304-c99d-efee-0117-0ce119063cd6 Jun 6 21:41:05 blubee kernel: NVRM: GPU Board Serial Number: Jun 6 21:41:05 blubee kernel: NVRM: Xid (PCI:0000:01:00): 79, GPU has fallen off the bus. Jun 6 21:41:05 blubee kernel: Jun 6 21:41:05 blubee kernel: NVRM: GPU at 0000:01:00.0 has fallen off the bus. Jun 6 21:41:05 blubee kernel: NVRM: GPU is on Board . Jun 6 21:41:05 blubee kernel: NVRM: A GPU crash dump has been created. If possible, please run Jun 6 21:41:05 blubee kernel: NVRM: nvidia-bug-report.sh as root to collect this data before Jun 6 21:41:05 blubee kernel: NVRM: the NVIDIA kernel module is unloaded. Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000927c:0:0:0x0000000f Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000927c:0:0:0x0000000f Jun 6 21:41:05 blubee kernel: vgapci0: child nvidia0 requested pci_enable_io Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000927c:0:0:0x0000000f Jun 6 21:41:06 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000927c:0:0:0x0000000f Jun 6 21:41:22 blubee kernel: . then that lead me to this nvidia forum thread: https://devtalk.nvidia.com/default/topic/985037/gtx-1070-quot-gpu-has-falle= n-off-the-bus-quot-running-3d-games-in-arch-linux-/ maybe it could help somehow? Best, Owen On Tue, Jun 6, 2017 at 10:08 PM, blubee blubeeme wrote: > This is getting out of hand. I can't even keep x going for ten minutes > sometimes. > I've tested all the suggestions in this thread and they just don't work. > > I have put out a print of sysctl hw. here : https://paste2.org/ > > With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz > The bios on this laptop I can either set graphics to discrete or mshybrid= . > > I've tried in the past to disable discrete and run mshybrid but that > always comes up with 0 screens found. Even just doing Xorg -configure. > > Anyone have some tips on disabling nvidia drivers, running this cpu with > igpu for a while? > > Best, > Owen > > On Sun, Jun 4, 2017, 18:11 blubee blubeeme wrote: > >> Thanks a lot! I'll give it a shot in a bit. >> >> Best, >> Owen >> >> On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI >> wrote: >> >>> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. >>> >>> But beware! Sometimes upstream changes make any of FreeBSD patches not >>> applicable (incorporating any of these, incompatible modifies, ...). >>> >>> For 381.22, current patchset applies and builds fine for me. >>> >>> >>> On Sun, 04 Jun 2017 08:04:50 +0000 >>> blubee blubeeme wrote: >>> >>> > I'm running with svn and I build by make. >>> > If in use these steps, the BSD related patches will be applied, etc? >>> > >>> > Best, >>> > Owen >>> > >>> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI >>> wrote: >>> > >>> > > Hi. >>> > > >>> > > Not in ports tree, but easily overridden by adding >>> > > >>> > > DISTVERSION=3D381.22 -DNO_CHECKSUM >>> > > >>> > > on make command line. Makefile of x11/nvidia-driver has a mechanism >>> > > to do so for someone requires newer version (newer GPU support, >>> etc.). >>> > > >>> > > If you're using portupgrade, >>> > > >>> > > portupgrade -m 'DISTVERSION=3D381.22 -DNO_CHECKSUM' -f >>> x11/nvidia-driver >>> > > >>> > > would do the same. >>> > > >>> > > If you installed it via pkg, there's no way to try. :-( >>> > > (As it's pre-built.) >>> > > >>> > > >>> > > On Sun, 04 Jun 2017 07:04:01 +0000 >>> > > blubee blubeeme wrote: >>> > > >>> > > > Hi @tomoaki >>> > > > Is that version of nvidia drivers currently in the ports tree? I >>> just >>> > > > checked but it seems not to be. >>> > > > >>> > > > @jeffrey >>> > > > I just generated a new xorg based on the force composition >>> setting. I >>> > > > merged it with my previous xorg I'll reboot, see if it gives bett= er >>> > > > performance. >>> > > > >>> > > > It seems like my system is locking up more frequently now. >>> Sometimes >>> > > right >>> > > > after a reboot the system, the screen locks and it's reboot and >>> pray. >>> > > > >>> > > > Best, >>> > > > Owen >>> > > > >>> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet < >>> jeffreybouquet@yahoo.com> >>> > > wrote: >>> > > > >>> > > > > SOME LINES BOTTOM POSTED, SEE... >>> > > > > -------------------------------------------- >>> > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: >>> > > > > >>> > > > > Subject: Re: nvidia drivers mutex lock >>> > > > > To: freebsd-current@freebsd.org >>> > > > > Cc: "Jeffrey Bouquet" , "blubee >>> blubeeme" < >>> > > > > gurenchan@gmail.com> >>> > > > > Date: Friday, June 2, 2017, 11:25 PM >>> > > > > >>> > > > > Hi. >>> > > > > Version >>> > > > > 381.22 (5 days newer than 375.66) of the driver states... >>> > > > > [1] >>> > > > > >>> > > > > Fixed hangs and >>> > > > > crashes that could occur when an OpenGL context is >>> > > > > created while the system is out of available >>> > > > > memory. >>> > > > > >>> > > > > Can this be related >>> > > > > with your hang? >>> > > > > >>> > > > > IMHO, >>> > > > > possibly allocating new resource (using os.lock_mtx >>> > > > > guard) >>> > > > > without checking the lock first while >>> > > > > previous request is waiting for >>> > > > > another can >>> > > > > cause the duplicated lock situation. And high memory >>> > > > > pressure would easily cause the situation. >>> > > > > >>> > > > > [1] http://www.nvidia.com/Download >>> /driverResults.aspx/118527/en-us >>> > > > > >>> > > > > Hope it helps. >>> > > > > >>> > > > > >>> > > > > On Thu, 1 Jun >>> > > > > 2017 22:35:46 +0000 (UTC) >>> > > > > Jeffrey Bouquet >>> > > > > >>> > > > > wrote: >>> > > > > >>> > > > > > I see the same >>> > > > > message, upon load, ... >>> > > > > > >>> > > > > -------------------------------------------- >>> > > > > > On Thu, 6/1/17, blubee blubeeme >>> > > > > wrote: >>> > > > > > >>> > > > > > Subject: >>> > > > > nvidia drivers mutex lock >>> > > > > > To: freebsd-ports@freebsd.org, >>> > > > > freebsd-current@freebsd.org >>> > > > > > Date: Thursday, June 1, 2017, 11:35 >>> > > > > AM >>> > > > > > >>> > > > > > I'm >>> > > > > running nvidia-drivers 375.66 with a GTX >>> > > > > > 1070 on FreeBSD-Current >>> > > > > > >>> > > > > > This problem >>> > > > > just started happening >>> > > > > > recently but, >>> > > > > every so often my laptop >>> > > > > > screen will >>> > > > > just blank out and then I >>> > > > > > have to >>> > > > > power cycle to get the >>> > > > > > machine up and >>> > > > > running again. >>> > > > > > >>> > > > > > It seems to be a problem with nvidia >>> > > > > > drivers acquiring duplicate lock. Any >>> > > > > > info on this? >>> > > > > > >>> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: >>> > > > > > acquiring duplicate lock of same >>> > > > > type: >>> > > > > > "os.lock_mtx" >>> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: 1st >>> > > > > > os.lock_mtx @ nvidia_os.c:841 >>> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: 2nd >>> > > > > > os.lock_mtx @ nvidia_os.c:841 >>> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: >>> > > > > > stack backtrace: >>> > > > > > >>> > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: #0 >>> > > > > > >>> > > > > 0xffffffff80ab7770 at >>> > > > > > >>> > > > > witness_debugger+0x70 >>> > > > > > Jun=E3=80=93 2 >>> > > > > 02:29:41 blubee kernel: #1 >>> > > > > > >>> > > > > 0xffffffff80ab7663 at >>> > > > > > >>> > > > > witness_checkorder+0xe23 >>> > > > > > Jun=E3=80=93 2 >>> > > > > 02:29:41 blubee kernel: #2 >>> > > > > > >>> > > > > 0xffffffff80a35b93 at >>> > > > > > >>> > > > > __mtx_lock_flags+0x93 >>> > > > > > Jun=E3=80=93 2 >>> > > > > 02:29:41 blubee kernel: #3 >>> > > > > > >>> > > > > 0xffffffff82f4397b at >>> > > > > > >>> > > > > os_acquire_spinlock+0x1b >>> > > > > > Jun=E3=80=93 2 >>> > > > > 02:29:41 blubee kernel: #4 >>> > > > > > >>> > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 >>> > > > > > Jun=E3=80=93 2 02:29:41 blubee kernel: >>> > > > > > ACPI Warning: >>> > > > > \_SB.PCI0.PEG0.PEGP._DSM: >>> > > > > > Argument #4 >>> > > > > type mismatch - Found >>> > > > > > [Buffer], ACPI >>> > > > > requires [Package] >>> > > > > > >>> > > > > (20170303/nsarguments-205) >>> > > > > > Jun=E3=80=93 2 >>> > > > > 02:29:42 blubee kernel: >>> > > > > > >>> > > > > nvidia-modeset: Allocated GPU:0 >>> > > > > > >>> > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ >>> > > > > > PCI:0000:01:00.0 >>> > > > > > >>> > > > > >>> > > > > > Best, >>> > > > > > Owen >>> > > > > > >>> > > > > _______________________________________________ >>> > > > > > freebsd-ports@freebsd.org >>> > > > > > mailing list >>> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports >>> > > > > > To unsubscribe, send any mail to >>> > > > > "freebsd-ports-unsubscribe@freebsd.org" >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > ... then Xorg will >>> > > > > run happily twelve hours or so. The lockups here happen >>> > > > > usually >>> > > > > > when too large or too many of >>> > > > > number of tabs/ large web pages with complex CSS etc >>> > > > > > are opened at a time. >>> > > > > > So no help, just a 'me >>> > > > > too'. >>> > > > > > >>> > > > > _______________________________________________ >>> > > > > > freebsd-current@freebsd.org >>> > > > > mailing list >>> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> > > > > > >>> > > > > To unsubscribe, send any mail to " >>> > > freebsd-current-unsubscribe@freebsd.org >>> > > > > " >>> > > > > > >>> > > > > > >>> > > > > >>> > > > > >>> > > > > -- >>> > > > > Tomoaki >>> > > > > AOKI >>> > > > > >>> > > > > >>> > > > > >>> > > > > ........................ >>> > > > > might be a workaround >>> > > > > Xorg/nvidia ran all night with this: >>> > > > > nvidia-settings >> X server display configuration >> >>> Advanced >> >>> > > Force >>> > > > > Full Composition Pipeline >>> > > > > ... for the laptop freezing. Could not hurt to try. " merge >>> with >>> > > > > Xorg.conf " from nvidia-settings... >>> > > > > ...................... >>> > > > > 18 hours uptime so far, even past >>> > > > > the 3 am periodic scripts. Have not rebooted out of the Xorg >>> though >>> > > so >>> > > > > may require edit-out of >>> > > > > xorg.conf if that is the case, in other words differing from >>> real-time >>> > > > > apply and >>> > > > > xorg initially start applies. >>> > > > > ........ >>> > > > > >>> > > > > >>> > > > _______________________________________________ >>> > > > freebsd-current@freebsd.org mailing list >>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> > > > To unsubscribe, send any mail to " >>> > > freebsd-current-unsubscribe@freebsd.org" >>> > > > >>> > > > >>> > > >>> > > >>> > > -- >>> > > Tomoaki AOKI >>> > > >>> >>> >>> -- >>> Tomoaki AOKI >>> >> From owner-freebsd-current@freebsd.org Wed Jun 7 19:12:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51E96D7B964 for ; Wed, 7 Jun 2017 19:12:51 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.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 27D997FD86 for ; Wed, 7 Jun 2017 19:12:50 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 86CE820CCC for ; Wed, 7 Jun 2017 15:12:44 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute2.internal (MEProxy); Wed, 07 Jun 2017 15:12:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KJGC+e KzQbRzj+CUfzGjs8II+U9MfZXWRJqnf9oX0rQ=; b=LKNa6Mn6zi+meP9NBkt+sD q+5xaM1/41Oa6kM5CMrm41o8Bq0fLuT64/hv3gnog2hsdcdp888TLvYPXaOualYO ppPXa1YTOlEsEU1mq4E+dv+upSSR+pS6hwZNROqzZrVGBcQ/zJ+CXMb9My5vSSvu LPiO1IQ4T+kj0zyb+AAIoqgvyqXFt+W1joelfUy9yc92gqqTUu23eRO1SWWsm9jd R3wMqvc4pqyUsAtkCAlwzOUZYE2hnrIO1/HAD/wLmaHYjIRcMG943eU0iRvGR+vo fi3C9ketlCqvRM3BGGoAdw1bp+uFi8mej+oFka+XXQHpanIGJqnrmNN0TjjaLjKA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 68F9D946C4; Wed, 7 Jun 2017 15:12:44 -0400 (EDT) Message-Id: <1496862764.923234.1002086344.272B2D5D@webmail.messagingengine.com> From: Josh Paetzel To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-72fcb609 References: <20170606100034.GA4245@c720-r314251> <20170606123738.GA5213@c720-r314251> <20170607123531.GA4867@c720-r314251> <20170607172234.GA3972@c720-r314251> <20170607192915.28088b71@thor.intern.walstatt.dynvpn.de> Date: Wed, 07 Jun 2017 14:12:44 -0500 In-Reply-To: <20170607192915.28088b71@thor.intern.walstatt.dynvpn.de> Subject: Re: mount_smbfs gives error when stored crypted pw is used X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 19:12:51 -0000 On Wed, Jun 7, 2017, at 12:29 PM, O. Hartmann wrote: > Am Wed, 7 Jun 2017 19:22:34 +0200 > Matthias Apitz schrieb: >=20 > > El d=C3=ADa mi=C3=A9rcoles, junio 07, 2017 a las 02:35:31p. m. +0200, M= atthias Apitz escribi=C3=B3: > >=20 > > > I have located the bug in /usr/src/contrib/smbfs/lib/smb/subr.c=20 > > >=20 > > > The printf(3C) calls have been added for debugging; the bug is the > > > addition of 13 after crypting every char which let the mask used in ^= operation > > > exceeding 256, i.e. more than one byte, if the string to be crypted i= s long > > > enough. The two lines added: > > >=20 > > > if (pos > 256) > > > pos =3D pos-256; > > >=20 > > > fixes this issue and the crypting/decypting works fine; see below; > > >=20 > > > I'll later file a PR and propose the patch;=20=20 > >=20 > > The PR was already made in 2009: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D132302 has a patch = attached (nearly > > the same solution as I have found), but was never ci'ed :-( > >=20 > > matthias > >=20 > >=20 >=20 > Wow ... that is, simply ... not very good! :-( >=20 > High quality! >=20 > --=20 > O. Hartmann >=20 > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s. 4 > BDSG). > Email had 1 attachment: > + Attachment2 > 1k (application/pgp-signature) I've taken the bug and am testing it now. Should have it committed by this evening. With some luck we can get it in to 11.1 --=20 Thanks, Josh Paetzel From owner-freebsd-current@freebsd.org Wed Jun 7 23:33:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7178FD7F3E8; Wed, 7 Jun 2017 23:33:38 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 043423291; Wed, 7 Jun 2017 23:33:37 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-afdff70000001600-ed-59388d485873 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 87.0E.05632.84D88395; Wed, 7 Jun 2017 19:33:29 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v57NXRUF004009; Wed, 7 Jun 2017 19:33:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v57NXOud010771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2017 19:33:26 -0400 Date: Wed, 7 Jun 2017 18:33:24 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2017Q2 Quarterly Status Reports Message-ID: <20170607233323.GZ39245@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3eH4Qcq5fItR5cpy" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrOvZaxFpsPevgcWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6Ma0u9C/4LVjTOaGNvYLzA38XIySEhYCJxpvcHYxcj F4eQwGImiYWfHjBBOBsYJZY93MYC4VxhkrjUsYoFpIVFQEVi6vYFYDabgJrE+hXXmEFsEQF5 iX1N79lBbGYg+9fWJjBbWMBQYvqCjWA2L9C663u2QtmCEidnPmGBqC+TOP/yNFsXIweQLS2x /B8HSFhUQFni7+F7LBMY+WYh6ZiFpGMWQgdEWEvixr+XTBjCthLr1r1nWcDItopRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyM4YCV5djCeeeN1iFGAg1GJhzdAziJSiDWxrLgy 9xCjJAeTkihvhSdQiC8pP6UyI7E4I76oNCe1+BCjCtCuRxtWX2CUYsnLz0tVEuGd3QRUx5uS WFmVWpQPUybNwaIkziuh0RghJJCeWJKanZpakFoEk5Xh4FCS4LXpAWoULEpNT61Iy8wpQUgz cXAeYpTg4AEa/qMOZHhxQWJucWY6RP4Uo6KUOK8BSLMASCKjNA+uF5RoJLL317xiFAd6S5iX AaSKB5ik4LpfAQ1mAhrMd8kEZHBJIkJKqoEx8rKjzqzo3umpq7lve7hb7A33vTnzfmu8ZISU t8iUno63iWIVt/pVmJbNcDucK9TyKYp7Rl/Jh0cmJTL833J6F/7ida6vlNkZycG33025sf6I uLr8H88v33e89cv7NmWq5ZQj8QEcbiIHTnLsuHoqlMOIYVlioOtMhrTHbZ1vpu598OB40ikl luKMREMt5qLiRACokFRpDwMAAA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 23:33:38 -0000 --3eH4Qcq5fItR5cpy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is July 7, 2017, for work done in April through June. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q2 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html [5] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html --3eH4Qcq5fItR5cpy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZOI00AAoJECjZpvNk63USKBwMIKJS/VEY3Eh18tFggVc8+rHQ NE7Z+nMUfMokRM9eiBnHTODfVsUMoyycD5z8HTTQaSKEmH5W5knzMz6hk5VpvV1P fObTMuxounYJ8nLb5DyhWRJJSg2qMYw+OY9cr2f9zVBjo3hg/0V4J+tuMAd7qr1r RReHfErfee5cv5GYY1eg0QW37wkBCsn96+q7wU3Vuin+BjK9Xt70EfMTvOlzx2p3 fyO4xbQjXqYvHJI33ewda2n7FzvyPuKekr71e2zkLYhSEt0JI9sV8sp3mO2BeK8z kDjAmexdJpucd3eJRfNj7dSvTdG2spQlXV4l/VFJ04a362gkQ7pNhiHQYPaFlCL7 OFf598FWzepoQUZMKRiJLdqWd32tRtFmbprw/idhiu/kb18LSvyj6zUnUSsTIjgA 7T3EbeXOe5bUqWIAMS/9GBkqmqBs6x0yi8057FWbljq8nJflk8QJdqbTCTLDRoDl DlOurghfTpFZRlSbrchgAAwBDVhQzAjZznFMr/6j9QvLR5U= =rleg -----END PGP SIGNATURE----- --3eH4Qcq5fItR5cpy-- From owner-freebsd-current@freebsd.org Wed Jun 7 23:35:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 993AFD7F55A for ; Wed, 7 Jun 2017 23:35:55 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 74165352E for ; Wed, 7 Jun 2017 23:35:55 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6FC20D7F558; Wed, 7 Jun 2017 23:35:55 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F4CBD7F556 for ; Wed, 7 Jun 2017 23:35:55 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30A48352D for ; Wed, 7 Jun 2017 23:35:54 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1496878375; bh=qrviGp6cRHRsrDU1q5f1FTRW14aJta8gVMrYBNuhkXQ=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=YiWzqxF1ZTNdvLg95ozW1IL8ekFAQlDcoMJVcmrm1l5JX9QXwmLSyiZfAXytk/lzA1/ScMed9MbWYpRygbeSkHLRtffPsGEAvMOPD0EVY0b7wWoYN94jE0sF3EnF3AZ+RpmyNAIAah0h3/TvnRlpZHvuF+PrROuT50xqYRUvBGCvgetDY+MIdgQHqOMMV7A9nBECLs5s1QoJC3kTkxec3jYOVGHAU2kJOvkGeMkgFqM4YhI1KJbJJ6NTvDJz/MX/a2+Cew6CLL96IgaP5WOvY1DOQN7k0FMaNq+OqSBpqUZXLL9ZSRbnfYnHVJtx/QEx5HcAmA39JUhSUntnZc5dwA== Received: from [98.139.170.178] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2017 23:32:55 -0000 Received: from [68.142.230.73] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 07 Jun 2017 23:32:55 -0000 Received: from [127.0.0.1] by smtp230.mail.bf1.yahoo.com with NNFMP; 07 Jun 2017 23:32:55 -0000 X-Yahoo-Newman-Id: 419438.87863.bm@smtp230.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: rA0aEK4VM1nAPsIdOb2xgNEzJ4hfIhBE6tHFJhPtupqU9_t TtWRO79tKxLEsD9E1V79Jx5i8hGPSJk9srpSmQ4Kl8uFKrqDddnOed2jZSav G.KuhuacsDn0UuHhZqPeaULBZa5GFI01V00U73kR7QeWcjPNlxPuYiyEdvI0 a1UtkAj2dkHmFuVi6mSb_Z.Di_M2NPf4YVTjnJVP0kLxKGSyJQA8Lbe2cZdK TVo8z.jFhSLmYh8byZ4JHnMMdM.2KZCGYQfXIQ.2WIRdcuAkv.HcIBIuctYD jZIwTEXPm8QvboqqbZ.QBQxENEYC4A8Geprkcg_QZTBBL_tbprYrakWl9z3i SMqxX_uaPQXjfEu42mlToUoaF3Vi19HyKB0ySpgU2EzAN826dI9g4YqGxYVL ZdDXERR4EuKCfZqM7AntvleozBjoL6HrN8oNk3rAYOdSv.q1yMmsRyXPgZYI 5bMX1vElaMZf4WIE3.11j9BvxHXem8pTm9myPY6xxyCrUy2coma1B1joqgIu bMJAxpdAGy_SLFVoQtzqw61VkfY8JQRxb5RGHvEUIoy.GcldTAXny_hVNkg- - X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- From: Anthony Jenkins Subject: Re: CFT: EVDEV support in psm(4) driver To: =?UTF-8?Q?Jan_Kokem=c3=bcller?= , Vladimir Kondratyev Cc: current@freebsd.org, freebsd-mobile@freebsd.org References: <5fa9225de944d6cdac0b7e5749b452a9@kondratyev.su> <5446ec03-c501-a369-01fc-e58a7d8712d9@gmail.com> Message-ID: <420c37d0-79bf-ac53-58aa-dcf1b99bd5c7@yahoo.com> Date: Wed, 7 Jun 2017 19:32:52 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <5446ec03-c501-a369-01fc-e58a7d8712d9@gmail.com> Content-Type: multipart/mixed; boundary="------------CB2650C7656876520F46E561" Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Jun 2017 23:35:55 -0000 This is a multi-part message in MIME format. --------------CB2650C7656876520F46E561 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are reporting multiple (wrong) events and some aren't emitting any events (or they are, but they're NoSymbol): - Down arrow: emits KeyPress for keycode 116 (Super_R), KeyRelease for keycode 116, KeyRelease for keycode 104 (Down) - Left arrow: emits KeyPress for keycode 113 (Alt_R), KeyPress for keycode 100 (Left), KeyRelease for keycode 113, KeyRelease for keycode 100 - Volume up: emits KeyPress 123 (NoSymbol), KeyPress 176 (NoSymbol), KeyRelease for same - Volume down: emits KeyPress 122 (NoSymbol), KeyPress 174 (NoSymbol), KeyRelease for same - Volume mute toggle: emits KeyPress 121 (NoSymbol), KeyRelease 121 (NoSymbol), KeyRelease 140 (NoSymbol) - Keypad end: emits KeyPress 115 (Super_L), KeyPress 103 (End), KeyRelease for same I'll attach the output of 'evdev -event keyboard' for everything but the Keypad end key which I recently found. /usr/local/etc/X11/xorg.conf.d/evdev1.conf: Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "Device" "/dev/input/event1" EndSection dmesg | grep kbd: [ajenkins@ajenkins-hplaptop ~]$ dmesg | grep kbd kbd: new array size 4 kbd1 at kbdmux0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] random: harvesting attach, 8 bytes (4 bits) from atkbd0 random: harvesting attach, 8 bytes (4 bits) from atkbdc0 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm0: irq 12 on atkbdc0 atkbdc: atkbdc0 already exists; skipping it /var/log/Xorg.0.log stuff: [ 24.763] (**) Option "config_info" "udev:/dev/input/event1" [ 24.763] (II) XINPUT: Adding extended input device "System keyboard multiplexer" (type: KEYBOARD, id 7) [ 24.763] (**) Option "xkb_rules" "evdev" [ 24.839] (II) config/udev: Adding input device AT keyboard (/dev/input/event2) [ 24.839] (**) AT keyboard: Applying InputClass "evdev keyboard catchall" [ 24.839] (II) Using input driver 'evdev' for 'AT keyboard' [ 24.839] Option "_source" "server/udev" [ 24.839] Option "name" "AT keyboard" [ 24.839] Option "path" "/dev/input/event2" [ 24.839] Option "device" "/dev/input/event2" [ 24.839] Option "major" "0" [ 24.839] Option "minor" "45" [ 24.839] Option "driver" "evdev" [ 24.839] Option "config_info" "udev:/dev/input/event2" [ 24.839] (**) AT keyboard: always reports core events [ 24.839] (**) evdev: AT keyboard: Device: "/dev/input/event2" [ 24.839] (--) evdev: AT keyboard: Vendor 0x1 Product 0x1 [ 24.839] (--) evdev: AT keyboard: Found keys [ 24.839] (II) evdev: AT keyboard: Configuring as keyboard [ 24.839] (**) Option "config_info" "udev:/dev/input/event2" [ 24.840] (II) XINPUT: Adding extended input device "AT keyboard" (type: KEYBOARD, id 8) [ 24.840] (**) Option "xkb_rules" "evdev" [ 24.840] (II) XKB: Reusing cached keymap [ 24.840] (II) config/udev: Adding input device Synaptics Touchpad (/dev/input/event3) [ 24.841] (**) Synaptics Touchpad: Applying InputClass "evdev pointer catchall" [ 24.841] (**) Synaptics Touchpad: Applying InputClass "evdev touchpad catchall" [ 24.841] (**) Synaptics Touchpad: Applying InputClass "touchpad catchall" [ 24.841] (**) Synaptics Touchpad: Applying InputClass "Default clickpad buttons" [ 24.841] (II) LoadModule: "synaptics" [ 24.841] (II) Loading /usr/local/lib/xorg/modules/input/synaptics_drv.so [ 24.842] (II) Module synaptics: vendor="X.Org Foundation" [ 24.842] compiled for 1.19.3, module version = 1.9.0 [ 24.842] Module class: X.Org XInput Driver [ 24.843] ABI class: X.Org XInput driver, version 24.1 [ 24.843] (II) Using input driver 'synaptics' for 'Synaptics Touchpad' [ 24.843] Option "_source" "server/udev" [ 24.843] Option "name" "Synaptics Touchpad" [ 24.843] Option "path" "/dev/input/event3" [ 24.843] Option "device" "/dev/input/event3" [ 24.843] Option "major" "0" [ 24.843] Option "minor" "50" [ 24.843] Option "driver" "synaptics" Not sure what else to add. I have applied the patches from this email thread. Any ideas? Thanks in advance, Anthony Jenkins On 04/17/17 06:59, Jan Kokemüller wrote: > Hi Vladimir, > this patch works great for me! > I'm testing this with a semi-mt Synaptics touchpad and a TrackPoint of > a Lenovo T420. I'm running 12-CURRENT (amd64) and Xorg 1.19.3 from > Matthew's CFT with the libudev-devd backend. The Evdev devices are > picked up correctly by libudev-devd and xf86-input-libinput (even the > TrackPoint). I haven't tested this with xf86-input-synaptics (which is > in maintenance mode) or xf86-input-evdev. I am not > using xf86-input-mouse or xf86-input-keyboard. > > What works (everything): > - true smooth scrolling with Xinput2 (tested with GTK3 Firefox or > gtk3-demo) > - TrackPoint scrolling holding the middle button > - both horizontal/vertical scrolling > - two finger scrolling powered by libinput (this semi-mt touchpad > doesn't really support more gestures than this) > > The only thing that doesn't work out of the box is the mouse pointer > on the VT console. It wouldn't be hard though to write a small tool > that uses libinput to translate Evdev events into CONS_MOUSECTL ioctls > needed for the VT pointer. > > Some comments: > - PS2_MOUSE_SYNAPTICS_PRODUCT should be 0x0007, not 0x0009 > (http://lxr.free-electrons.com/source/drivers/input/mouse/psmouse.h#L86) > - The TrackPoint should be added with product id 0x000A as on Linux > and with the INPUT_PROP_POINTING_STICK Evdev property set > - I think it would be better if the same Evdev device names were > exposed as on Linux (for example "SynPS/2 Synaptics TouchPad"). Many > scripts using xinput to change device properties depend on the Linux > device names. > > I've added a patch and comments to https://reviews.freebsd.org/D10265 . > > Even Linux 64-bit binaries work correctly with the created > /dev/input/event* devices after applying those two patches here: > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218625 > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218627 > > This will be very useful for Linux games using joysticks, game > controllers etc. Hi Vladimir and Jan, Thanks for the patches! I'm having some issues with 3 patches from this thread: - https://reviews.freebsd.org/file/data/pqjvpuhwfgsu5nnamibg/PHID-FILE-uuyjx66blb344hre3nc2/D10207.vson.id27478.whitespaceignore-most.diff - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218625 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218627 These may or may not have anything to do with the patches... 1. For some reason Xorg keyboard driver isn't getting some key events, or had shuffled them. When I first applied the patches, X thought my arrow was and was something else. At some point that behavior changed and worked, but emits and doesn't emit anything. Rebooting didn't change the new behavior, and I don't know what caused it to change. Switching to a console, I get the expected characters/actions when pressing these keys. 2. My Synaptics clickpad (and the pointer in general) freeze for several seconds, although it hasn't done it lately. When a freeze occurs (in X windows), other GUI processes don't seem to be affected. If I have another pointer device attached (e.g. USB mouse), it also doesn't move the pointer during the freeze. Here's my config: --------------CB2650C7656876520F46E561 Content-Type: text/plain; charset=UTF-8; name="keyboard_issue.xev.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="keyboard_issue.xev.txt" IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMjIyMjIyBTVEFSVCB4 ZXYgLWV2ZW50IGtleWJvYXJkICMjIyMjIwojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMKCk91dGVyIHdpbmRvdyBpcyAweDU2MDAwMDEsIGlubmVyIHdpbmRvdyBp cyAweDU2MDAwMDIKCktleW1hcE5vdGlmeSBldmVudCwgc2VyaWFsIDIxLCBzeW50aGV0aWMg Tk8sIHdpbmRvdyAweDAsCiAgICBrZXlzOiAgNDI5NDk2NzIwNSAwICAgMCAgIDAgICAwICAg MCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAKICAgICAgICAg ICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAg MCAgIDAgICAwICAgCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojIyMjIyMgUFJF U1MgVVAgQVJST1cgICMjIyMjIwojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKS2V5 UHJlc3MgZXZlbnQsIHNlcmlhbCAyNSwgc3ludGhldGljIE5PLCB3aW5kb3cgMHg1NjAwMDAx LAogICAgcm9vdCAweDQ5OSwgc3VidyAweDAsIHRpbWUgMTA1MjE3OCwgKC0zNzEsNDY1KSwg cm9vdDooNTI3LDQ4OCksCiAgICBzdGF0ZSAweDEwLCBrZXljb2RlIDExMSAoa2V5c3ltIDB4 ZmY2MSwgUHJpbnQpLCBzYW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3RyaW5nIGdpdmVz IDAgYnl0ZXM6IAogICAgWG1iTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZp bHRlckV2ZW50IHJldHVybnM6IEZhbHNlCgpLZXlQcmVzcyBldmVudCwgc2VyaWFsIDI1LCBz eW50aGV0aWMgTk8sIHdpbmRvdyAweDU2MDAwMDEsCiAgICByb290IDB4NDk5LCBzdWJ3IDB4 MCwgdGltZSAxMDUyMTc5LCAoLTM3MSw0NjUpLCByb290Oig1MjcsNDg4KSwKICAgIHN0YXRl IDB4MTAsIGtleWNvZGUgOTggKGtleXN5bSAweGZmNTIsIFVwKSwgc2FtZV9zY3JlZW4gWUVT LAogICAgWExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhtYkxvb2t1cFN0cmlu ZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1cm5zOiBGYWxzZQoKTWFw cGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDI4LCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDAs CiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rfa2V5Y29kZSA4LCBjb3VudCAy NDgKCktleVJlbGVhc2UgZXZlbnQsIHNlcmlhbCAyOCwgc3ludGhldGljIE5PLCB3aW5kb3cg MHg1NjAwMDAxLAogICAgcm9vdCAweDQ5OSwgc3VidyAweDAsIHRpbWUgMTA1MjI5NCwgKC0z NzEsNDY1KSwgcm9vdDooNTI3LDQ4OCksCiAgICBzdGF0ZSAweDEwLCBrZXljb2RlIDExMSAo a2V5c3ltIDB4ZmY2MSwgUHJpbnQpLCBzYW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3Ry aW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50IHJldHVybnM6IEZhbHNlCgpN YXBwaW5nTm90aWZ5IGV2ZW50LCBzZXJpYWwgMjgsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4 MCwKICAgIHJlcXVlc3QgTWFwcGluZ0tleWJvYXJkLCBmaXJzdF9rZXljb2RlIDgsIGNvdW50 IDI0OAoKS2V5UmVsZWFzZSBldmVudCwgc2VyaWFsIDI4LCBzeW50aGV0aWMgTk8sIHdpbmRv dyAweDU2MDAwMDEsCiAgICByb290IDB4NDk5LCBzdWJ3IDB4MCwgdGltZSAxMDUyMjk0LCAo LTM3MSw0NjUpLCByb290Oig1MjcsNDg4KSwKICAgIHN0YXRlIDB4MTAsIGtleWNvZGUgOTgg KGtleXN5bSAweGZmNTIsIFVwKSwgc2FtZV9zY3JlZW4gWUVTLAogICAgWExvb2t1cFN0cmlu ZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1cm5zOiBGYWxzZQoKIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIyMjIyMjIFBSRVNTIFJJR0hUIEFSUk9X ICAjIyMjIyMKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKCk1hcHBpbmdOb3Rp ZnkgZXZlbnQsIHNlcmlhbCAzMCwgc3ludGhldGljIE5PLCB3aW5kb3cgMHgwLAogICAgcmVx dWVzdCBNYXBwaW5nS2V5Ym9hcmQsIGZpcnN0X2tleWNvZGUgOCwgY291bnQgMjQ4CgpLZXlQ cmVzcyBldmVudCwgc2VyaWFsIDMwLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDU2MDAwMDEs CiAgICByb290IDB4NDk5LCBzdWJ3IDB4MCwgdGltZSAxMDU5NDM5LCAoLTM3MSw0NjUpLCBy b290Oig1MjcsNDg4KSwKICAgIHN0YXRlIDB4MTAsIGtleWNvZGUgMTE0IChrZXlzeW0gMHgw LCBOb1N5bWJvbCksIHNhbWVfc2NyZWVuIFlFUywKICAgIFhMb29rdXBTdHJpbmcgZ2l2ZXMg MCBieXRlczogCiAgICBYbWJMb29rdXBTdHJpbmcgZ2l2ZXMgMCBieXRlczogCiAgICBYRmls dGVyRXZlbnQgcmV0dXJuczogRmFsc2UKCk1hcHBpbmdOb3RpZnkgZXZlbnQsIHNlcmlhbCAz MCwgc3ludGhldGljIE5PLCB3aW5kb3cgMHgwLAogICAgcmVxdWVzdCBNYXBwaW5nS2V5Ym9h cmQsIGZpcnN0X2tleWNvZGUgOCwgY291bnQgMjQ4CgpLZXlQcmVzcyBldmVudCwgc2VyaWFs IDMwLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDU2MDAwMDEsCiAgICByb290IDB4NDk5LCBz dWJ3IDB4MCwgdGltZSAxMDU5NDM5LCAoLTM3MSw0NjUpLCByb290Oig1MjcsNDg4KSwKICAg IHN0YXRlIDB4MTAsIGtleWNvZGUgMTAyIChrZXlzeW0gMHhmZjUzLCBSaWdodCksIHNhbWVf c2NyZWVuIFlFUywKICAgIFhMb29rdXBTdHJpbmcgZ2l2ZXMgMCBieXRlczogCiAgICBYbWJM b29rdXBTdHJpbmcgZ2l2ZXMgMCBieXRlczogCiAgICBYRmlsdGVyRXZlbnQgcmV0dXJuczog RmFsc2UKCk1hcHBpbmdOb3RpZnkgZXZlbnQsIHNlcmlhbCAzMiwgc3ludGhldGljIE5PLCB3 aW5kb3cgMHgwLAogICAgcmVxdWVzdCBNYXBwaW5nS2V5Ym9hcmQsIGZpcnN0X2tleWNvZGUg OCwgY291bnQgMjQ4CgpLZXlSZWxlYXNlIGV2ZW50LCBzZXJpYWwgMzIsIHN5bnRoZXRpYyBO Tywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0aW1lIDEw NTk1MzcsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgxMCwga2V5 Y29kZSAxMTQgKGtleXN5bSAweDAsIE5vU3ltYm9sKSwgc2FtZV9zY3JlZW4gWUVTLAogICAg WExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1cm5z OiBGYWxzZQoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDMyLCBzeW50aGV0aWMgTk8s IHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rfa2V5Y29k ZSA4LCBjb3VudCAyNDgKCktleVJlbGVhc2UgZXZlbnQsIHNlcmlhbCAzMiwgc3ludGhldGlj IE5PLCB3aW5kb3cgMHg1NjAwMDAxLAogICAgcm9vdCAweDQ5OSwgc3VidyAweDAsIHRpbWUg MTA1OTUzNywgKC0zNzEsNDY1KSwgcm9vdDooNTI3LDQ4OCksCiAgICBzdGF0ZSAweDEwLCBr ZXljb2RlIDEwMiAoa2V5c3ltIDB4ZmY1MywgUmlnaHQpLCBzYW1lX3NjcmVlbiBZRVMsCiAg ICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50IHJldHVy bnM6IEZhbHNlCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMj IyMjIyBQUkVTUyBET1dOIEFSUk9XIChCUk9LRU4pICAjIyMjIyMKIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFs IDM0LCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXli b2FyZCwgZmlyc3Rfa2V5Y29kZSA4LCBjb3VudCAyNDgKCktleVByZXNzIGV2ZW50LCBzZXJp YWwgMzQsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTks IHN1YncgMHgwLCB0aW1lIDEwODIxNDYsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAog ICAgc3RhdGUgMHgxMCwga2V5Y29kZSAxMTYgKGtleXN5bSAweGZmZWMsIFN1cGVyX1IpLCBz YW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAg WG1iTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50IHJldHVy bnM6IEZhbHNlCgpNYXBwaW5nTm90aWZ5IGV2ZW50LCBzZXJpYWwgMzQsIHN5bnRoZXRpYyBO Tywgd2luZG93IDB4MCwKICAgIHJlcXVlc3QgTWFwcGluZ0tleWJvYXJkLCBmaXJzdF9rZXlj b2RlIDgsIGNvdW50IDI0OAoKS2V5bWFwTm90aWZ5IGV2ZW50LCBzZXJpYWwgMzYsIHN5bnRo ZXRpYyBOTywgd2luZG93IDB4MCwKICAgIGtleXM6ICAxICAgMCAgIDAgICAwICAgMCAgIDAg ICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMSAgIDE2ICAwICAgCiAgICAgICAgICAg MCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAgICAwICAgMCAgIDAg ICAwICAgMCAgIAoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDM2LCBzeW50aGV0aWMg Tk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rfa2V5 Y29kZSA4LCBjb3VudCAyNDgKCktleVJlbGVhc2UgZXZlbnQsIHNlcmlhbCAzNiwgc3ludGhl dGljIE5PLCB3aW5kb3cgMHg1NjAwMDAxLAogICAgcm9vdCAweDQ5OSwgc3VidyAweDAsIHRp bWUgMTA4MjMwNCwgKC0zNzEsNDY1KSwgcm9vdDooNTI3LDQ4OCksCiAgICBzdGF0ZSAweDUw LCBrZXljb2RlIDExNiAoa2V5c3ltIDB4ZmZlYywgU3VwZXJfUiksIHNhbWVfc2NyZWVuIFlF UywKICAgIFhMb29rdXBTdHJpbmcgZ2l2ZXMgMCBieXRlczogCiAgICBYRmlsdGVyRXZlbnQg cmV0dXJuczogRmFsc2UKCk1hcHBpbmdOb3RpZnkgZXZlbnQsIHNlcmlhbCAzNiwgc3ludGhl dGljIE5PLCB3aW5kb3cgMHgwLAogICAgcmVxdWVzdCBNYXBwaW5nS2V5Ym9hcmQsIGZpcnN0 X2tleWNvZGUgOCwgY291bnQgMjQ4CgpLZXlSZWxlYXNlIGV2ZW50LCBzZXJpYWwgMzYsIHN5 bnRoZXRpYyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgw LCB0aW1lIDEwODIzMDQsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUg MHgxMCwga2V5Y29kZSAxMDQgKGtleXN5bSAweGZmNTQsIERvd24pLCBzYW1lX3NjcmVlbiBZ RVMsCiAgICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50 IHJldHVybnM6IEZhbHNlCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjCiMjIyMjIyBQUkVTUyBMRUZUIEFSUk9XIChCUk9LRU4pICAjIyMjIyMKIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKTWFwcGluZ05vdGlmeSBldmVudCwg c2VyaWFsIDM4LCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBp bmdLZXlib2FyZCwgZmlyc3Rfa2V5Y29kZSA4LCBjb3VudCAyNDgKCktleVByZXNzIGV2ZW50 LCBzZXJpYWwgMzgsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3Qg MHg0OTksIHN1YncgMHgwLCB0aW1lIDEwODk2NzMsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0 ODgpLAogICAgc3RhdGUgMHgxMCwga2V5Y29kZSAxMTMgKGtleXN5bSAweGZmZWEsIEFsdF9S KSwgc2FtZV9zY3JlZW4gWUVTLAogICAgWExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAK ICAgIFhtYkxvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCBy ZXR1cm5zOiBGYWxzZQoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDM4LCBzeW50aGV0 aWMgTk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rf a2V5Y29kZSA4LCBjb3VudCAyNDgKCktleVByZXNzIGV2ZW50LCBzZXJpYWwgMzgsIHN5bnRo ZXRpYyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0 aW1lIDEwODk2NzMsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgx OCwga2V5Y29kZSAxMDAgKGtleXN5bSAweGZmNTEsIExlZnQpLCBzYW1lX3NjcmVlbiBZRVMs CiAgICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWG1iTG9va3VwU3RyaW5n IGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50IHJldHVybnM6IEZhbHNlCgpNYXBw aW5nTm90aWZ5IGV2ZW50LCBzZXJpYWwgNDAsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4MCwK ICAgIHJlcXVlc3QgTWFwcGluZ0tleWJvYXJkLCBmaXJzdF9rZXljb2RlIDgsIGNvdW50IDI0 OAoKS2V5UmVsZWFzZSBldmVudCwgc2VyaWFsIDQwLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAw eDU2MDAwMDEsCiAgICByb290IDB4NDk5LCBzdWJ3IDB4MCwgdGltZSAxMDg5Nzk4LCAoLTM3 MSw0NjUpLCByb290Oig1MjcsNDg4KSwKICAgIHN0YXRlIDB4MTgsIGtleWNvZGUgMTEzIChr ZXlzeW0gMHhmZmVhLCBBbHRfUiksIHNhbWVfc2NyZWVuIFlFUywKICAgIFhMb29rdXBTdHJp bmcgZ2l2ZXMgMCBieXRlczogCiAgICBYRmlsdGVyRXZlbnQgcmV0dXJuczogRmFsc2UKCk1h cHBpbmdOb3RpZnkgZXZlbnQsIHNlcmlhbCA0MCwgc3ludGhldGljIE5PLCB3aW5kb3cgMHgw LAogICAgcmVxdWVzdCBNYXBwaW5nS2V5Ym9hcmQsIGZpcnN0X2tleWNvZGUgOCwgY291bnQg MjQ4CgpLZXlSZWxlYXNlIGV2ZW50LCBzZXJpYWwgNDAsIHN5bnRoZXRpYyBOTywgd2luZG93 IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0aW1lIDEwODk3OTgsICgt MzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgxMCwga2V5Y29kZSAxMDAg KGtleXN5bSAweGZmNTEsIExlZnQpLCBzYW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3Ry aW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50IHJldHVybnM6IEZhbHNlCgoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKIyMjIyMjIFBSRVNTIFZP TFVNRSBVUCAoQlJPS0VOKSAgIyMjIyMjCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIwoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDQyLCBzeW50aGV0aWMg Tk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rfa2V5 Y29kZSA4LCBjb3VudCAyNDgKCktleVByZXNzIGV2ZW50LCBzZXJpYWwgNDIsIHN5bnRoZXRp YyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0aW1l IDEwOTg1NjIsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgxMCwg a2V5Y29kZSAxMjMgKGtleXN5bSAweDAsIE5vU3ltYm9sKSwgc2FtZV9zY3JlZW4gWUVTLAog ICAgWExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhtYkxvb2t1cFN0cmluZyBn aXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1cm5zOiBGYWxzZQoKTWFwcGlu Z05vdGlmeSBldmVudCwgc2VyaWFsIDQyLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDAsCiAg ICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rfa2V5Y29kZSA4LCBjb3VudCAyNDgK CktleVByZXNzIGV2ZW50LCBzZXJpYWwgNDIsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4NTYw MDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0aW1lIDEwOTg1NjIsICgtMzcxLDQ2 NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgxMCwga2V5Y29kZSAxNzYgKGtleXN5 bSAweDAsIE5vU3ltYm9sKSwgc2FtZV9zY3JlZW4gWUVTLAogICAgWExvb2t1cFN0cmluZyBn aXZlcyAwIGJ5dGVzOiAKICAgIFhtYkxvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAg IFhGaWx0ZXJFdmVudCByZXR1cm5zOiBGYWxzZQoKTWFwcGluZ05vdGlmeSBldmVudCwgc2Vy aWFsIDQyLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdL ZXlib2FyZCwgZmlyc3Rfa2V5Y29kZSA4LCBjb3VudCAyNDgKCktleVJlbGVhc2UgZXZlbnQs IHNlcmlhbCA0Miwgc3ludGhldGljIE5PLCB3aW5kb3cgMHg1NjAwMDAxLAogICAgcm9vdCAw eDQ5OSwgc3VidyAweDAsIHRpbWUgMTA5ODU2NCwgKC0zNzEsNDY1KSwgcm9vdDooNTI3LDQ4 OCksCiAgICBzdGF0ZSAweDEwLCBrZXljb2RlIDEyMyAoa2V5c3ltIDB4MCwgTm9TeW1ib2wp LCBzYW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAog ICAgWEZpbHRlckV2ZW50IHJldHVybnM6IEZhbHNlCgpNYXBwaW5nTm90aWZ5IGV2ZW50LCBz ZXJpYWwgNDIsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4MCwKICAgIHJlcXVlc3QgTWFwcGlu Z0tleWJvYXJkLCBmaXJzdF9rZXljb2RlIDgsIGNvdW50IDI0OAoKS2V5UmVsZWFzZSBldmVu dCwgc2VyaWFsIDQyLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDU2MDAwMDEsCiAgICByb290 IDB4NDk5LCBzdWJ3IDB4MCwgdGltZSAxMDk4NTY1LCAoLTM3MSw0NjUpLCByb290Oig1Mjcs NDg4KSwKICAgIHN0YXRlIDB4MTAsIGtleWNvZGUgMTc2IChrZXlzeW0gMHgwLCBOb1N5bWJv bCksIHNhbWVfc2NyZWVuIFlFUywKICAgIFhMb29rdXBTdHJpbmcgZ2l2ZXMgMCBieXRlczog CiAgICBYRmlsdGVyRXZlbnQgcmV0dXJuczogRmFsc2UKCiMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjCiMjIyMjIyBQUkVTUyBWT0xVTUUgRE9XTiAoQlJPS0VO KSAgIyMjIyMjCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCgpN YXBwaW5nTm90aWZ5IGV2ZW50LCBzZXJpYWwgNDYsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4 MCwKICAgIHJlcXVlc3QgTWFwcGluZ0tleWJvYXJkLCBmaXJzdF9rZXljb2RlIDgsIGNvdW50 IDI0OAoKS2V5UHJlc3MgZXZlbnQsIHNlcmlhbCA0Niwgc3ludGhldGljIE5PLCB3aW5kb3cg MHg1NjAwMDAxLAogICAgcm9vdCAweDQ5OSwgc3VidyAweDAsIHRpbWUgMTEwMzQ2OCwgKC0z NzEsNDY1KSwgcm9vdDooNTI3LDQ4OCksCiAgICBzdGF0ZSAweDEwLCBrZXljb2RlIDEyMiAo a2V5c3ltIDB4MCwgTm9TeW1ib2wpLCBzYW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3Ry aW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWG1iTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6 IAogICAgWEZpbHRlckV2ZW50IHJldHVybnM6IEZhbHNlCgpNYXBwaW5nTm90aWZ5IGV2ZW50 LCBzZXJpYWwgNDYsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4MCwKICAgIHJlcXVlc3QgTWFw cGluZ0tleWJvYXJkLCBmaXJzdF9rZXljb2RlIDgsIGNvdW50IDI0OAoKS2V5UHJlc3MgZXZl bnQsIHNlcmlhbCA0Niwgc3ludGhldGljIE5PLCB3aW5kb3cgMHg1NjAwMDAxLAogICAgcm9v dCAweDQ5OSwgc3VidyAweDAsIHRpbWUgMTEwMzQ2OSwgKC0zNzEsNDY1KSwgcm9vdDooNTI3 LDQ4OCksCiAgICBzdGF0ZSAweDEwLCBrZXljb2RlIDE3NCAoa2V5c3ltIDB4MCwgTm9TeW1i b2wpLCBzYW1lX3NjcmVlbiBZRVMsCiAgICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6 IAogICAgWG1iTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50 IHJldHVybnM6IEZhbHNlCgpLZXlSZWxlYXNlIGV2ZW50LCBzZXJpYWwgNDYsIHN5bnRoZXRp YyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0aW1l IDExMDM0NzEsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgxMCwg a2V5Y29kZSAxNzQgKGtleXN5bSAweDAsIE5vU3ltYm9sKSwgc2FtZV9zY3JlZW4gWUVTLAog ICAgWExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1 cm5zOiBGYWxzZQoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDQ2LCBzeW50aGV0aWMg Tk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rfa2V5 Y29kZSA4LCBjb3VudCAyNDgKCktleVJlbGVhc2UgZXZlbnQsIHNlcmlhbCA0Niwgc3ludGhl dGljIE5PLCB3aW5kb3cgMHg1NjAwMDAxLAogICAgcm9vdCAweDQ5OSwgc3VidyAweDAsIHRp bWUgMTEwMzQ3MSwgKC0zNzEsNDY1KSwgcm9vdDooNTI3LDQ4OCksCiAgICBzdGF0ZSAweDEw LCBrZXljb2RlIDEyMiAoa2V5c3ltIDB4MCwgTm9TeW1ib2wpLCBzYW1lX3NjcmVlbiBZRVMs CiAgICBYTG9va3VwU3RyaW5nIGdpdmVzIDAgYnl0ZXM6IAogICAgWEZpbHRlckV2ZW50IHJl dHVybnM6IEZhbHNlCgojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IwojIyMjIyMgUFJFU1MgVk9MVU1FIE1VVEUgKEJST0tFTikgICMjIyMjIwojIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKTWFwcGluZ05vdGlmeSBldmVudCwg c2VyaWFsIDQ5LCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBp bmdLZXlib2FyZCwgZmlyc3Rfa2V5Y29kZSA4LCBjb3VudCAyNDgKCktleVByZXNzIGV2ZW50 LCBzZXJpYWwgNDksIHN5bnRoZXRpYyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3Qg MHg0OTksIHN1YncgMHgwLCB0aW1lIDExMTA4NzIsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0 ODgpLAogICAgc3RhdGUgMHgxMCwga2V5Y29kZSAxNDAgKGtleXN5bSAweDAsIE5vU3ltYm9s KSwgc2FtZV9zY3JlZW4gWUVTLAogICAgWExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAK ICAgIFhtYkxvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCBy ZXR1cm5zOiBGYWxzZQoKTWFwcGluZ05vdGlmeSBldmVudCwgc2VyaWFsIDQ5LCBzeW50aGV0 aWMgTk8sIHdpbmRvdyAweDAsCiAgICByZXF1ZXN0IE1hcHBpbmdLZXlib2FyZCwgZmlyc3Rf a2V5Y29kZSA4LCBjb3VudCAyNDgKCktleVByZXNzIGV2ZW50LCBzZXJpYWwgNDksIHN5bnRo ZXRpYyBOTywgd2luZG93IDB4NTYwMDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0 aW1lIDExMTA4NzIsICgtMzcxLDQ2NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgx MCwga2V5Y29kZSAxMjEgKGtleXN5bSAweDAsIE5vU3ltYm9sKSwgc2FtZV9zY3JlZW4gWUVT LAogICAgWExvb2t1cFN0cmluZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhtYkxvb2t1cFN0cmlu ZyBnaXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1cm5zOiBGYWxzZQoKS2V5 UmVsZWFzZSBldmVudCwgc2VyaWFsIDUxLCBzeW50aGV0aWMgTk8sIHdpbmRvdyAweDU2MDAw MDEsCiAgICByb290IDB4NDk5LCBzdWJ3IDB4MCwgdGltZSAxMTEwODc2LCAoLTM3MSw0NjUp LCByb290Oig1MjcsNDg4KSwKICAgIHN0YXRlIDB4MTAsIGtleWNvZGUgMTIxIChrZXlzeW0g MHgwLCBOb1N5bWJvbCksIHNhbWVfc2NyZWVuIFlFUywKICAgIFhMb29rdXBTdHJpbmcgZ2l2 ZXMgMCBieXRlczogCiAgICBYRmlsdGVyRXZlbnQgcmV0dXJuczogRmFsc2UKCk1hcHBpbmdO b3RpZnkgZXZlbnQsIHNlcmlhbCA1MSwgc3ludGhldGljIE5PLCB3aW5kb3cgMHgwLAogICAg cmVxdWVzdCBNYXBwaW5nS2V5Ym9hcmQsIGZpcnN0X2tleWNvZGUgOCwgY291bnQgMjQ4CgpL ZXlSZWxlYXNlIGV2ZW50LCBzZXJpYWwgNTEsIHN5bnRoZXRpYyBOTywgd2luZG93IDB4NTYw MDAwMSwKICAgIHJvb3QgMHg0OTksIHN1YncgMHgwLCB0aW1lIDExMTA4NzYsICgtMzcxLDQ2 NSksIHJvb3Q6KDUyNyw0ODgpLAogICAgc3RhdGUgMHgxMCwga2V5Y29kZSAxNDAgKGtleXN5 bSAweDAsIE5vU3ltYm9sKSwgc2FtZV9zY3JlZW4gWUVTLAogICAgWExvb2t1cFN0cmluZyBn aXZlcyAwIGJ5dGVzOiAKICAgIFhGaWx0ZXJFdmVudCByZXR1cm5zOiBGYWxzZQoKQ2xpZW50 TWVzc2FnZSBldmVudCwgc2VyaWFsIDUyLCBzeW50aGV0aWMgWUVTLCB3aW5kb3cgMHg1NjAw MDAxLAogICAgbWVzc2FnZV90eXBlIDB4MTQ4IChXTV9QUk9UT0NPTFMpLCBmb3JtYXQgMzIs IG1lc3NhZ2UgMHgxNDkgKFdNX0RFTEVURV9XSU5ET1cpCgojIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIwojIyMjIyBFTkQgeGV2IC1ldmVudCBrZXlib2FyZCAjIyMjIwoj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwo= --------------CB2650C7656876520F46E561-- From owner-freebsd-current@freebsd.org Thu Jun 8 05:34:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59B9CBF6834 for ; Thu, 8 Jun 2017 05:34:58 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 319E774FB6 for ; Thu, 8 Jun 2017 05:34:58 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 30F4BBF6832; Thu, 8 Jun 2017 05:34:58 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30846BF6831; Thu, 8 Jun 2017 05:34:58 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 E3E6374FB5; Thu, 8 Jun 2017 05:34:57 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-ot0-x230.google.com with SMTP id i31so17911985ota.3; Wed, 07 Jun 2017 22:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oO4h/+/tUBGQ3chNEc/2xgNE0s/X5JZKG2/0/uj/ZTI=; b=Yt5ViEaDyNn0YgAMU5E+pPkS2WPUP3zHT3t7nZfrYJ4araWaYkdbL5gDHnFvgxldgc wL8lQdCGFbenvV0vXSgemnM/HMS/8odPWundKX5rI5MZFJjGnyJS8msBRaJhJZqaN+e+ +LrCwu26nyzzGEUNMFwLVgTtmtmvZX6N/BbqLIjND17CbHfUpKHFXcpaJqjjgjP1BAUz OgV9DWEJ9r5E4jADH6kiVPbv/3QjQ059aC+tpUiwg9wLKRRacdT1xxFJAfZQz32TA3bh 1A5I36RJ5OmYnjehR1hDITZ7aNzSJ0j4YpsZGRNIM/zOArfYA7qhJgYcm3BKntLIoOod JFDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oO4h/+/tUBGQ3chNEc/2xgNE0s/X5JZKG2/0/uj/ZTI=; b=Wn2vracwixOS59dZhZUrXbZ+/4dXcQ0alZvUclnFLHdnovQzoDB9tGuc9G32EYh4Mm 5j/sEoqwobxQfqnaw1VP1qPXLKjCokCnOp0NS5soI9KKgeqt0geQZVrAgMDsqx2pLbJb /DlL8W3Tq7Op/FAQjZwUmEUPWLoDmTfwZA1QLI/gbdQVyeLz7j1abMRofDiXUWpdWIQK dnG5petr+vbV5dTSgJmb/Rh22qdtHxng7VNNzSwAmjrWf1QPg/zIp9Cj97yHDVpJ/5ZB honmOt8NAx+cC2WGNliwDWfRi6Ps2Jzx1QfDYdfoJGZmRwhlB22WENYHPdTevg4NGYva BGqA== X-Gm-Message-State: AKS2vOxismOwMRp9abBSE6v7vYTV9ePAZNx2y5fS1RBf7XD7W4l09KLi dMedhlOh4gvFSO5sVr8= X-Received: by 10.157.68.167 with SMTP id v39mr17075220ote.250.1496900097197; Wed, 07 Jun 2017 22:34:57 -0700 (PDT) Received: from ?IPv6:2003:d2:1bc8:2b00:182e:ccdc:1d71:9fbe? (p200300D21BC82B00182ECCDC1D719FBE.dip0.t-ipconnect.de. [2003:d2:1bc8:2b00:182e:ccdc:1d71:9fbe]) by smtp.googlemail.com with ESMTPSA id y31sm2131098ota.47.2017.06.07.22.34.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 22:34:56 -0700 (PDT) Subject: Re: CFT: EVDEV support in psm(4) driver To: Anthony Jenkins , Vladimir Kondratyev Cc: current@freebsd.org, freebsd-mobile@freebsd.org References: <5fa9225de944d6cdac0b7e5749b452a9@kondratyev.su> <5446ec03-c501-a369-01fc-e58a7d8712d9@gmail.com> <420c37d0-79bf-ac53-58aa-dcf1b99bd5c7@yahoo.com> From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= Message-ID: <7b6cf8e4-e330-9149-8fae-dfde5e9e01bf@gmail.com> Date: Thu, 8 Jun 2017 07:34:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <420c37d0-79bf-ac53-58aa-dcf1b99bd5c7@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 05:34:58 -0000 Hi, On 08.06.2017 01:32, Anthony Jenkins wrote: > I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are > reporting multiple (wrong) events and some aren't emitting any events > (or they are, but they're NoSymbol): It is true that the Evdev drivers emit other keycodes compared to the 'legacy' drivers. I'm using this command to specify the correct mapping ("-rules evdev" is the important part): setxkbmap -rules evdev -layout us -variant altgr-intl -option ctrl:nocaps,compose:menu I'm not sure if this is enough for KDE. I see 'Option "xkb_rules" "evdev"' in your log, so the correct mapping should already be used? Maybe KDE reverts this somehow. FWIW, when I press the arrow keys in xev I see the following (correct) output: KeyPress event, serial 33, synthetic NO, window 0x4200001, root 0xc2, subw 0x0, time 820816, (158,533), root:(960,556), state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x4200001, root 0xc2, subw 0x0, time 820911, (158,533), root:(960,556), state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x4200001, root 0xc2, subw 0x0, time 821494, (158,533), root:(960,556), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x4200001, root 0xc2, subw 0x0, time 821565, (158,533), root:(960,556), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Cheers, Jan From owner-freebsd-current@freebsd.org Thu Jun 8 11:08:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B240BFC10A for ; Thu, 8 Jun 2017 11:08:18 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3E13E7D7D9 for ; Thu, 8 Jun 2017 11:08:18 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: by mailman.ysv.freebsd.org (Postfix) id 3CEEEBFC108; Thu, 8 Jun 2017 11:08:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A846BFC107; Thu, 8 Jun 2017 11:08:18 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id DBCD07D7D8; Thu, 8 Jun 2017 11:08:16 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id 5C6F01C92; Thu, 8 Jun 2017 13:59:21 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id gjTBt4aFjFih; Thu, 8 Jun 2017 13:59:20 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 4A6D91C89; Thu, 8 Jun 2017 13:59:20 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id 9E964574B0C; Thu, 8 Jun 2017 13:59:14 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id vWbWqhteHvPd; Thu, 8 Jun 2017 13:59:07 +0300 (MSK) Received: from [192.168.0.30] (gateway [10.0.2.2]) by mail.cicgroup.ru (Postfix) with ESMTPA id B9A97574A91; Thu, 8 Jun 2017 13:59:07 +0300 (MSK) Subject: Re: CFT: EVDEV support in psm(4) driver To: Anthony Jenkins Cc: =?UTF-8?Q?Jan_Kokem=c3=bcller?= , current@freebsd.org, freebsd-mobile@freebsd.org References: <5fa9225de944d6cdac0b7e5749b452a9@kondratyev.su> <5446ec03-c501-a369-01fc-e58a7d8712d9@gmail.com> <420c37d0-79bf-ac53-58aa-dcf1b99bd5c7@yahoo.com> From: Vladimir Kondratyev Message-ID: <53ee09b4-6ecf-584b-fea1-1d5bf3d52aa4@kondratyev.su> Date: Thu, 8 Jun 2017 13:57:29 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <420c37d0-79bf-ac53-58aa-dcf1b99bd5c7@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 11:08:18 -0000 On 08.06.2017 02:32, Anthony Jenkins wrote: > I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are > reporting multiple (wrong) events and some aren't emitting any events > (or they are, but they're NoSymbol): You can test evdev directly w/o Xserver started by running of evemu-record utility from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218383 PR to see if events are matching keys or not. Note: depending on kern.evdev.rcpt_mask sysctl value only one of kdbmux or AT keyboard devices should emit events. Not bother! > Section "InputDevice" > Identifier "Keyboard0" > Driver "evdev" > Option "Device" "/dev/input/event1" > EndSection This lines are not required usually if you are using devd or udev autoconfiguration backends. Moreover they can do a harm. Could you compare input device lists from xinput command output with evemu-record output? They should be the same except "Virtual core XTEST" entries. If they are not, that could be the culprit. It is possinle that Xorg receives one key event several times. In that case try to uninstall xf86-input-keyboard and restart Xserver than. > 2. My Synaptics clickpad (and the pointer in general) freeze for several > seconds, although it hasn't done it lately. When a freeze occurs (in X > windows), other GUI processes don't seem to be affected. If I have > another pointer device attached (e.g. USB mouse), it also doesn't move > the pointer during the freeze. Try run evemu-record on synaptics device node to see if you are receiving events from touchpad during freezes or not From owner-freebsd-current@freebsd.org Thu Jun 8 15:56:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63B69C095CE for ; Thu, 8 Jun 2017 15:56:08 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 2EB9929F1 for ; Thu, 8 Jun 2017 15:56:08 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x22f.google.com with SMTP id f185so17413982pgc.0 for ; Thu, 08 Jun 2017 08:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cwI9QCwDHyGCE/DBqI90CNjO35OxOmECtFKm9mfN5fk=; b=VzY48Gt0TQdmTiK3LeNbW9+oCmZuvPtmePrsjcajK7GosM03s5oDB5agTQWwThRNM7 piYyCJj9F+Z33FldrKFTyC9Wzgzh7jqimF5wwUYdksFQsGlYhquw7hTSQseYEZpmQzOO nMpIacICdujgAoh3BBQtHHjmxOlaf3kEJdmg6LsZB9gZGbHiVvc/sjHjq7NydbXtxqoF UyP9MQkv8V9Sk0Ylp62HFSTjqmW52siE6QQimZg2fBBznD01HJqL9pbHkZh+I0i0eM5K 0bR0UiATYhFpDtL9XFZXV4GvoBwRu50vpXZixIIr5fKi59fA4RLGCmRr6mmGymihXEth pTsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cwI9QCwDHyGCE/DBqI90CNjO35OxOmECtFKm9mfN5fk=; b=W+VBxR3x0fHPp83hpnHaWJHcNjQOAqNHHwHNksbnLuBqDiVDvsE38gi8NHDWaDg4Z0 UbCJc/IYVfT2sZnH0nd2MTliaYwrT1EpCcHHe9w1lnHoV2mSZMgzrsBOc513eySGx6xa KFacifzasGe0PAOdW6BWbG6ImGRu+CCDEkGvqqdPQHN4RqanEJvqfO0ZpBdPdvB09BHV giOGlH1OCdbSoYxbuZ7CFteW47IpJ6hR/HNFAqv36aRuVWkSthBMwD0+taRb+2ADcQu2 ymJZma80I6NWxXjvvdN5y79I7JMG/Um/Cltzvl2+/pF9O/WZFbgrTJVyxebwgF+rDDXO AHWg== X-Gm-Message-State: AODbwcDTX3Oh8dqXL+G6pzkPiylv4bwPonZaVUjy6EKe/mpVucWmHdbP 8tGb11dz3eLmU9BzbpewlzR/If9h9Z0l X-Received: by 10.98.163.25 with SMTP id s25mr37230905pfe.217.1496937367151; Thu, 08 Jun 2017 08:56:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Thu, 8 Jun 2017 08:56:06 -0700 (PDT) From: blubee blubeeme Date: Thu, 8 Jun 2017 23:56:06 +0800 Message-ID: Subject: autoreconf missing boost? To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 15:56:08 -0000 Hi I'm running a autoreconf trying to port a project; some printer code. Having a bit of trouble. I ran autoreconf -fi then I do: ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld --with-libintl-prefix=/usr/local that goes straight forward. Then when I run gmake, it seems to fail at linking boost or something like that. Here's the output of gmake, i've tried both make and gmake: me@blubee:~/Downloads/Epson/ut % gmake gmake all-recursive gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' Making all in . gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' Making all in lib gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' Making all in . gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' CXX connexion.lo In file included from connexion.cpp:32:0: /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a type typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a type typedef __vm_pindex_t vm_pindex_t; ^ In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0, from /usr/local/include/boost/core/demangle.hpp:39, from /usr/local/include/boost/core/typeinfo.hpp:119, from /usr/local/include/boost/detail/sp_typeinfo.hpp:20, from /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27, from /usr/local/include/boost/smart_ptr/detail/sp_counted_base.hpp:54, from /usr/local/include/boost/smart_ptr/detail/shared_count.hpp:29, from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:28, from /usr/local/include/boost/shared_ptr.hpp:17, from /usr/local/include/boost/filesystem/path.hpp:29, from /usr/local/include/boost/filesystem.hpp:16, from connexion.cpp:40: /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46: error: expected initializer before '__nonnull' int posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */ ^ In file included from /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0, from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35, from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39, from /usr/local/lib/gcc49/include/c++/ios:42, from /usr/local/lib/gcc49/include/c++/ostream:38, from /usr/local/lib/gcc49/include/c++/iostream:39, from connexion.cpp:38: /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1: error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_once) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1: error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_getspecific) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1: error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_setspecific) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1: error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void* (*)(void*), void*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_create) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:106:1: error: 'int __gthrw_pthread_join(pthread_t, void**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_join) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:107:1: error: 'int __gthrw_pthread_equal(pthread_t, pthread_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_equal) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:108:1: error: 'pthread* __gthrw_pthread_self()' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_self) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:109:1: error: 'int __gthrw_pthread_detach(pthread_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_detach) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:111:1: error: 'int __gthrw_pthread_cancel(pthread_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cancel) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:113:1: error: 'int __gthrw_sched_yield()' declared 'static' but never defined [-Werror=unused-function] __gthrw(sched_yield) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:115:1: error: 'int __gthrw_pthread_mutex_lock(pthread_mutex**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutex_lock) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:116:1: error: 'int __gthrw_pthread_mutex_trylock(pthread_mutex**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutex_trylock) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:118:1: error: 'int __gthrw_pthread_mutex_timedlock(pthread_mutex**, const timespec*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutex_timedlock) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:120:1: error: 'int __gthrw_pthread_mutex_unlock(pthread_mutex**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutex_unlock) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:121:1: error: 'int __gthrw_pthread_mutex_init(pthread_mutex**, pthread_mutex_attr* const*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutex_init) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:122:1: error: 'int __gthrw_pthread_mutex_destroy(pthread_mutex**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutex_destroy) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:124:1: error: 'int __gthrw_pthread_cond_init(pthread_cond**, pthread_cond_attr* const*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cond_init) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:125:1: error: 'int __gthrw_pthread_cond_broadcast(pthread_cond**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cond_broadcast) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:126:1: error: 'int __gthrw_pthread_cond_signal(pthread_cond**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cond_signal) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:127:1: error: 'int __gthrw_pthread_cond_wait(pthread_cond**, pthread_mutex**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cond_wait) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:128:1: error: 'int __gthrw_pthread_cond_timedwait(pthread_cond**, pthread_mutex**, const timespec*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cond_timedwait) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:129:1: error: 'int __gthrw_pthread_cond_destroy(pthread_cond**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_cond_destroy) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:131:1: error: 'int __gthrw_pthread_key_create(pthread_key_t*, void (*)(void*))' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_key_create) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:132:1: error: 'int __gthrw_pthread_key_delete(pthread_key_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_key_delete) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:133:1: error: 'int __gthrw_pthread_mutexattr_init(pthread_mutex_attr**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutexattr_init) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:134:1: error: 'int __gthrw_pthread_mutexattr_settype(pthread_mutex_attr**, int)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutexattr_settype) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:135:1: error: 'int __gthrw_pthread_mutexattr_destroy(pthread_mutex_attr**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_mutexattr_destroy) ^ cc1plus: all warnings being treated as errors gmake[3]: *** [Makefile:667: connexion.lo] Error 1 gmake[3]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut/lib' gmake[2]: *** [Makefile:688: all-recursive] Error 1 gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut/lib' gmake[1]: *** [Makefile:605: all-recursive] Error 1 gmake[1]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' gmake: *** [Makefile:513: all] Error 2 me@blubee:~/Downloads/Epson/ut % ==================================== is this a glang vs gcc thing or something else? I feel like I'm getting close to porting this software but this is a little bit above me. Any help would be helpful. Best, Owen From owner-freebsd-current@freebsd.org Thu Jun 8 16:52:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C9B7C0A2CE for ; Thu, 8 Jun 2017 16:52:01 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 6BF58648F0 for ; Thu, 8 Jun 2017 16:52:01 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id x63so19062900pff.3 for ; Thu, 08 Jun 2017 09:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=SgCND6CrA/36XvhXOf11g7zt8fOLJFWI2ScEXZEoD1E=; b=Lj5E2qikABDzFdl5Uo2mERMgX0cGBBzq/r2YmIMRb05oWPJPfz3BNz8b/WBMdz6vZr TOKZRbCdj6+OfCrEAv6Nq68UxUn+Kj1lY6NKmdYzn1eiG+W3OPmjwNafI2GwUDS6q92x jBztQVZEt7Pr6OxiqrkG1aUSmWZu8gD91VL4P1RyrYjpDjG1KiuPjUxcznFS9KloTOGb V/hOJsIxbka/isvBrZFDsyAuAd8GM9CWZOAfPHeYhaTSZGwrUPsbv7h5ZXBGoPXofT5e FiPiLpgH8wAdxiSxPjHrNX/Xl4CA8U1UUvEGvc9AsGMW4sAyQMX448Xp0YnB9PjhAP/X cAow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=SgCND6CrA/36XvhXOf11g7zt8fOLJFWI2ScEXZEoD1E=; b=I1QkYcKMviyu6SZJcy1Fjukqh+96hOWymcqJg6KOjPwwvvEUlMDqkpXbA+WlXDFTUr qw2/3GsKbQ0poV15uAfNrmMfNWio95oYY/h41/s07gtnSEGBmREHfQZ6IWfkCtl/qo7/ FUuSi2jS6LAKPzxI+odhO+FVJqVRobjmVjriSscPHY8yUrg5Bd3DSgJi0vRrruD7rDXb jqxQP8B3TFGTDwY05aJS0e7QwdWoj0wOpA4OlqSx8WEDfjddABWGbRRV+8javYdlRMsS DJHGhtDScd5RvFm3Sqci4DcypU1FdcyBA5Fcv7A35wBXwqOVwTn8XLVx8WP+0zkX4LKk dI6g== X-Gm-Message-State: AODbwcDqW7xzfNXmbJiIrvE55Ka1lxINteBnhwLjaDeA54l/VfkMkdf8 rWLJPxRbJQXtRQyUxSjGaIgqom32LSYr X-Received: by 10.84.179.65 with SMTP id a59mr34453549plc.82.1496940720691; Thu, 08 Jun 2017 09:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Thu, 8 Jun 2017 09:52:00 -0700 (PDT) In-Reply-To: References: From: blubee blubeeme Date: Fri, 9 Jun 2017 00:52:00 +0800 Message-ID: Subject: Re: autoreconf missing boost? To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 16:52:01 -0000 I forgot to add this in my last email, here's the boost packages that I have installed. me@blubee:~ % pkg info | grep boost boost-jam-1.64.0 Build tool from the boost.org boost-libs-1.64.0 Free portable C++ libraries (without Boost.Python) boost-python-libs-1.62.0 Framework for interfacing Python and C++ boost_build-2.0.m12_4 Extensible cross-platform build tool suite On Thu, Jun 8, 2017 at 11:56 PM, blubee blubeeme wrote: > Hi > > I'm running a autoreconf trying to port a project; some printer code. > Having a bit of trouble. > > I ran autoreconf -fi > > then I do: > ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld > --with-libintl-prefix=/usr/local > > that goes straight forward. > > Then when I run gmake, it seems to fail at linking boost or something like > that. Here's the output of gmake, i've tried both make and gmake: > me@blubee:~/Downloads/Epson/ut % gmake > gmake all-recursive > gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' > Making all in . > gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' > gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' > Making all in lib > gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' > Making all in . > gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' > CXX connexion.lo > In file included from connexion.cpp:32:0: > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ > include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a > type > typedef __vm_ooffset_t vm_ooffset_t; > ^ > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ > include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a > type > typedef __vm_pindex_t vm_pindex_t; > ^ > In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0, > from /usr/local/include/boost/core/demangle.hpp:39, > from /usr/local/include/boost/core/typeinfo.hpp:119, > from /usr/local/include/boost/detail/sp_typeinfo.hpp:20, > from /usr/local/include/boost/ > smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27, > from /usr/local/include/boost/ > smart_ptr/detail/sp_counted_base.hpp:54, > from /usr/local/include/boost/ > smart_ptr/detail/shared_count.hpp:29, > from /usr/local/include/boost/ > smart_ptr/shared_ptr.hpp:28, > from /usr/local/include/boost/shared_ptr.hpp:17, > from /usr/local/include/boost/filesystem/path.hpp:29, > from /usr/local/include/boost/filesystem.hpp:16, > from connexion.cpp:40: > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46: > error: expected initializer before '__nonnull' > int posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */ > ^ > In file included from /usr/local/lib/gcc49/include/ > c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0, > from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35, > from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39, > from /usr/local/lib/gcc49/include/c++/ios:42, > from /usr/local/lib/gcc49/include/c++/ostream:38, > from /usr/local/lib/gcc49/include/c++/iostream:39, > from connexion.cpp:38: > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1: > error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_once) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1: > error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_getspecific) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1: > error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_setspecific) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1: > error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void* > (*)(void*), void*)' declared 'static' but never defined > [-Werror=unused-function] > __gthrw(pthread_create) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:106:1: > error: 'int __gthrw_pthread_join(pthread_t, void**)' declared 'static' > but never defined [-Werror=unused-function] > __gthrw(pthread_join) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:107:1: > error: 'int __gthrw_pthread_equal(pthread_t, pthread_t)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_equal) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:108:1: > error: 'pthread* __gthrw_pthread_self()' declared 'static' but never > defined [-Werror=unused-function] > __gthrw(pthread_self) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:109:1: > error: 'int __gthrw_pthread_detach(pthread_t)' declared 'static' but > never defined [-Werror=unused-function] > __gthrw(pthread_detach) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:111:1: > error: 'int __gthrw_pthread_cancel(pthread_t)' declared 'static' but > never defined [-Werror=unused-function] > __gthrw(pthread_cancel) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:113:1: > error: 'int __gthrw_sched_yield()' declared 'static' but never defined > [-Werror=unused-function] > __gthrw(sched_yield) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:115:1: > error: 'int __gthrw_pthread_mutex_lock(pthread_mutex**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutex_lock) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:116:1: > error: 'int __gthrw_pthread_mutex_trylock(pthread_mutex**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutex_trylock) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:118:1: > error: 'int __gthrw_pthread_mutex_timedlock(pthread_mutex**, const > timespec*)' declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutex_timedlock) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:120:1: > error: 'int __gthrw_pthread_mutex_unlock(pthread_mutex**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutex_unlock) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:121:1: > error: 'int __gthrw_pthread_mutex_init(pthread_mutex**, > pthread_mutex_attr* const*)' declared 'static' but never defined > [-Werror=unused-function] > __gthrw(pthread_mutex_init) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:122:1: > error: 'int __gthrw_pthread_mutex_destroy(pthread_mutex**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutex_destroy) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:124:1: > error: 'int __gthrw_pthread_cond_init(pthread_cond**, pthread_cond_attr* > const*)' declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_cond_init) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:125:1: > error: 'int __gthrw_pthread_cond_broadcast(pthread_cond**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_cond_broadcast) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:126:1: > error: 'int __gthrw_pthread_cond_signal(pthread_cond**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_cond_signal) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:127:1: > error: 'int __gthrw_pthread_cond_wait(pthread_cond**, pthread_mutex**)' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_cond_wait) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:128:1: > error: 'int __gthrw_pthread_cond_timedwait(pthread_cond**, > pthread_mutex**, const timespec*)' declared 'static' but never defined > [-Werror=unused-function] > __gthrw(pthread_cond_timedwait) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:129:1: > error: 'int __gthrw_pthread_cond_destroy(pthread_cond**)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_cond_destroy) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:131:1: > error: 'int __gthrw_pthread_key_create(pthread_key_t*, void (*)(void*))' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_key_create) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:132:1: > error: 'int __gthrw_pthread_key_delete(pthread_key_t)' declared 'static' > but never defined [-Werror=unused-function] > __gthrw(pthread_key_delete) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:133:1: > error: 'int __gthrw_pthread_mutexattr_init(pthread_mutex_attr**)' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutexattr_init) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:134:1: > error: 'int __gthrw_pthread_mutexattr_settype(pthread_mutex_attr**, int)' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutexattr_settype) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:135:1: > error: 'int __gthrw_pthread_mutexattr_destroy(pthread_mutex_attr**)' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_mutexattr_destroy) > ^ > cc1plus: all warnings being treated as errors > gmake[3]: *** [Makefile:667: connexion.lo] Error 1 > gmake[3]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut/lib' > gmake[2]: *** [Makefile:688: all-recursive] Error 1 > gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut/lib' > gmake[1]: *** [Makefile:605: all-recursive] Error 1 > gmake[1]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' > gmake: *** [Makefile:513: all] Error 2 > me@blubee:~/Downloads/Epson/ut % > > > ==================================== > is this a glang vs gcc thing or something else? > I feel like I'm getting close to porting this software but this is a > little bit above me. > > Any help would be helpful. > > Best, > Owen > From owner-freebsd-current@freebsd.org Thu Jun 8 18:46:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D54FCC776FA for ; Thu, 8 Jun 2017 18:46:31 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq2.tb.mail.iss.as9143.net (smtpq2.tb.mail.iss.as9143.net [212.54.42.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7FA186A23B; Thu, 8 Jun 2017 18:46:31 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.34.120] (helo=smtp12.mnd.mail.iss.as9143.net) by smtpq2.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dJ2Rq-0007se-Fw; Thu, 08 Jun 2017 20:46:22 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp12.mnd.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dJ2Rq-0005UM-D5; Thu, 08 Jun 2017 20:46:22 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id 90DED720C; Thu, 8 Jun 2017 20:46:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlzmmbWJ7KfU; Thu, 8 Jun 2017 20:46:20 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id B86B87202; Thu, 8 Jun 2017 20:46:19 +0200 (CEST) From: peter.blok@bsd4all.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Time to increase MAXPHYS? Date: Thu, 8 Jun 2017 20:46:19 +0200 In-Reply-To: <20170605174930.GA6259@brick> Cc: Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> <20170605174930.GA6259@brick> X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=Baeo6vl2 c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=LWSFodeU3zMA:10 a=6I5d2MoRAAAA:8 a=TInpbu2Uoq2eLERIPWUA:9 a=QEXdDO2ut3YA:10 a=Yu5NEQuBHAHfXgcPOwwA:9 a=ZI24qOWCWR5z0UmS:21 a=_W_S_7VecoQA:10 a=IjZwj45LgO3ly-622nXo:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 18:46:31 -0000 One area that breaks after changing MAXPHYS from 128K to 1MB is the = iscsi target. I don=E2=80=99t have details, because that server is = semi-production and I reverted it back ASAP > On 5 Jun 2017, at 19:49, Edward Tomasz Napiera=C5=82a = wrote: >=20 > On 0604T0952, Hans Petter Selasky wrote: >> On 06/04/17 09:39, Tomoaki AOKI wrote: >>> Hi >>>=20 >>> One possibility would be to make it MD build-time OTIONS, >>> defaulting 1M on regular systems and 128k on smaller systems. >>>=20 >>> Of course I guess making it a tunable (or sysctl) would be best, >>> though. >>>=20 >>=20 >> Hi, >>=20 >> A tunable sysctl would be fine, but beware that commonly used = firmware=20 >> out there produced in the millions might hang in a non-recoverable = way=20 >> if you exceed their "internal limits". Conditionally lowering this=20 >> definition is fine, but increasing it needs to be carefully verified. >>=20 >> For example many USB devices are only tested with OS'es like Windows = and=20 >> MacOS and if these have any kind of limitation on the SCSI transfer=20= >> sizes, it is very likely many devices out there do not support any=20 >> larger transfer sizes either. >=20 > FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed > that both issue 1MB requests. I wouldn't be surprised if they avoided > doing that for older devices, depending on eg the SCSI version = reported > by device. >=20 > _______________________________________________ > freebsd-current@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current = > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Thu Jun 8 21:18:41 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9C10C79CD4 for ; Thu, 8 Jun 2017 21:18:41 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 695DC71DAC for ; Thu, 8 Jun 2017 21:18:41 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id d64so353883wmf.1 for ; Thu, 08 Jun 2017 14:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=z0YwTEgHkeOdRQLWjlnRu1JHqxVGBLufucmE3cVEj7Q=; b=WTtUkS9FC5SVY2R6WH3DfrX5WAXfzHygdwIviKOVqaEseU0rj8GSKXUVA37KLxr6zH FZHPbJMoKbwXsyxf4nFQQydnjZbQmG4OSMzeAVBsOuatxjmkzEHM56C77dHWogBhHA5v R0MkjkYO2ATWG+vsyTibGTevPtUm3Pw6wCfipkM0zvOKt7JfMPRzD69tDEeQx3H3imDH SZF/pQxWVqwqI4EJCr8umyeJ3BNr7RW05ib7VPhtPP9IH0uApsKW8+TM/BWQTULWc7QZ 4vi1DA1Q/7fPhCxKd3wuoMHl5zFoO6hA8DOC3aScc1EElsr3MNpeAQ0TFSzeyU503NcD 9JeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=z0YwTEgHkeOdRQLWjlnRu1JHqxVGBLufucmE3cVEj7Q=; b=HkRcl5LYKqohTUCudVhPWKwgD4E7btFZc29DPsrX635EtWmQyXOXsGNtjC/xpstwC3 Btn+l7p6RZhNEslUQKUt1FLfZiPCwh4+I7WrwsL2YxSIQ/OOgIO+uBQIU0JdaV24o0tH egYQN9eRBaXzGqpWa4fhpqkHFvSIJ2NZIQo2kncYdQwA/LQB2jMVjLp3/7yM9mlH66jx 9DTXmcLR7kbllZmsG4x4Vge8i575bF33pfU7JHaIGUCEQzUDTAMGCgCHQckfDRV3tZNS utfFMNCE1LvBhtD5Hl/ns5AaH5G3zp0b8Jaf7konRmpwTMOUpvmVbmb0vc8atsKFkKCW 5pAw== X-Gm-Message-State: AODbwcB1kPKEVpAOo1nbE0XktC0vuAEREcEm/C1W8uwn+UFbGAst+yYM lZJH8NntvCcx0PiF X-Received: by 10.28.216.205 with SMTP id p196mr4882352wmg.18.1496956718295; Thu, 08 Jun 2017 14:18:38 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id e24sm8779264wre.54.2017.06.08.14.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 14:18:37 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 8 Jun 2017 22:18:35 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170608211835.GA5348@brick> Mail-Followup-To: Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> <20170605174930.GA6259@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170605174930.GA6259@brick> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 21:18:42 -0000 On 0605T1849, Edward Tomasz Napierała wrote: > On 0604T0952, Hans Petter Selasky wrote: > > On 06/04/17 09:39, Tomoaki AOKI wrote: > > > Hi > > > > > > One possibility would be to make it MD build-time OTIONS, > > > defaulting 1M on regular systems and 128k on smaller systems. > > > > > > Of course I guess making it a tunable (or sysctl) would be best, > > > though. > > > > > > > Hi, > > > > A tunable sysctl would be fine, but beware that commonly used firmware > > out there produced in the millions might hang in a non-recoverable way > > if you exceed their "internal limits". Conditionally lowering this > > definition is fine, but increasing it needs to be carefully verified. > > > > For example many USB devices are only tested with OS'es like Windows and > > MacOS and if these have any kind of limitation on the SCSI transfer > > sizes, it is very likely many devices out there do not support any > > larger transfer sizes either. > > FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed > that both issue 1MB requests. I wouldn't be surprised if they avoided > doing that for older devices, depending on eg the SCSI version reported > by device. Erm, this was obviously - or perhaps not - say: when testing cfumass(4). As in, Windows and OSX both seem to issue 1MB requests to USB Mass Storage devices. From owner-freebsd-current@freebsd.org Thu Jun 8 21:19:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E776C79D4E for ; Thu, 8 Jun 2017 21:19:17 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 BE28A71ECE for ; Thu, 8 Jun 2017 21:19:16 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wr0-x230.google.com with SMTP id q97so23324665wrb.2 for ; Thu, 08 Jun 2017 14:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=1JXlnHMr5d3XS9tQ+1QvWKhedk6feNcTcWQakoQQPr4=; b=sq67puKZkmEI778lvt1Xy91RoLT1nsZrhIXn6NCN+boHMMj2t/wvF2XZ4kB6ldbk2+ 2ohzEevpimSMqPmx9Ni4+NQegtUNCftYm+dVkEFsJZA/lazM3wpqZgyBFSmFHfddTWvM NyHGK11G45RWQRPMBXioMlw1aKv5lTugypeUPw6mBC5RbBUWsTQqUpJuX7kkpW+Wcq24 s2j3G6eehTvCWJyxDxZ95H5B9Ctrt1nTUZgb3FqEGl8RtyUCoGNqdak4gcpX8nJFS9hc +qQFxwiHIkdwYAFW5rCg2lxPVsMqr2KMFnXzoXvT5N/5fykZHx5g0xeGEf4tcxly1CVk ISNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=1JXlnHMr5d3XS9tQ+1QvWKhedk6feNcTcWQakoQQPr4=; b=qn7tGVg0KGbwG6lnMRBHwdx3K60NQf6Fpl2jBDobgiJNA7NcjWMeY/zKJtoRGs90KC 4mi0891PR43sfVkKCx65RwAhjqnAzun9gk0rHPmImubOYPesygMVVmNXcTl+DC1G+t2n lJFmT4vLUNAdXT5ZRfYKfDKP36lkWWTj44IhDNHwCaZ61l2K+vkgzxTUkU/Vz/dzFc2+ AY7I0DpfW7whuylIU0TJe7xB4+E46Z0t1q+4nAr1ZOKIm3GNxNeGwIPUcmQLTyA3CHXo FSauVwUHUm9spIDnkw+URQ5UbdrLa9KmhS17feK4UqFYD/z1CspMS9XOTlHwIFlPJwYZ b93w== X-Gm-Message-State: AODbwcCVuSrKe3/RsO0gKI+EZELUea84uHHL7afMWv94alCmju0LIWAi p3v6+kr9xWoztQ== X-Received: by 10.223.135.78 with SMTP id 14mr26790560wrz.166.1496956755215; Thu, 08 Jun 2017 14:19:15 -0700 (PDT) Received: from brick (cpc92310-cmbg19-2-0-cust934.5-4.cable.virginm.net. [82.9.227.167]) by smtp.gmail.com with ESMTPSA id 64sm8482246wmn.20.2017.06.08.14.19.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 14:19:14 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 8 Jun 2017 22:19:11 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: peter.blok@bsd4all.org Cc: Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170608211911.GB5348@brick> Mail-Followup-To: peter.blok@bsd4all.org, Hans Petter Selasky , Tomoaki AOKI , freebsd-current@freebsd.org References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604163948.eb5f74ce2a233b8f204ba671@dec.sakura.ne.jp> <15e42fd1-055d-28f6-5e24-1448e16954a9@selasky.org> <20170605174930.GA6259@brick> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 08 Jun 2017 21:19:17 -0000 Huh, can't say I've tested that. I'll try to look into this. Thanks for the report! On 0608T2046, peter.blok@bsd4all.org wrote: > One area that breaks after changing MAXPHYS from 128K to 1MB is the iscsi target. I don’t have details, because that server is semi-production and I reverted it back ASAP > > On 5 Jun 2017, at 19:49, Edward Tomasz Napierała wrote: > > > > On 0604T0952, Hans Petter Selasky wrote: > >> On 06/04/17 09:39, Tomoaki AOKI wrote: > >>> Hi > >>> > >>> One possibility would be to make it MD build-time OTIONS, > >>> defaulting 1M on regular systems and 128k on smaller systems. > >>> > >>> Of course I guess making it a tunable (or sysctl) would be best, > >>> though. > >>> > >> > >> Hi, > >> > >> A tunable sysctl would be fine, but beware that commonly used firmware > >> out there produced in the millions might hang in a non-recoverable way > >> if you exceed their "internal limits". Conditionally lowering this > >> definition is fine, but increasing it needs to be carefully verified. > >> > >> For example many USB devices are only tested with OS'es like Windows and > >> MacOS and if these have any kind of limitation on the SCSI transfer > >> sizes, it is very likely many devices out there do not support any > >> larger transfer sizes either. > > > > FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed > > that both issue 1MB requests. I wouldn't be surprised if they avoided > > doing that for older devices, depending on eg the SCSI version reported > > by device. > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org " > From owner-freebsd-current@freebsd.org Fri Jun 9 06:11:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECFFEB94CBB; Fri, 9 Jun 2017 06:11:15 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e: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 AB9467FD32; Fri, 9 Jun 2017 06:11:15 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pg0-x234.google.com with SMTP id v18so23320578pgb.1; Thu, 08 Jun 2017 23:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=evZ1XQ1eLWhqSBoOxU+NFfpMirj+j9IHy7I/SC/9JiY=; b=WRJkVIuEMHjf/YVMacmD026c6S7lB4nknICYQhTu1Q47My0+Tk28/KnA2IK1pSiflJ nQPBVXy0uDVz599fjWNkt51b9FKSbtQnbZGq2ivhOuttbwaPrtZzuuQcX4AU9MdpU9iJ 2M+9LZC7hIKK05dFyfI/zVSqCPcNHAt5Tf/OdyeRWLeuMgEsZLXP02UFepEglU+Ki9Ge HnZDHsnBTlveDHs9ftTeuM/U1gg0nOmr/Q3Bt3/57krW+WwjHbH6WImeRJVwudeeCJ9U I62PlLli21a6PH1cHuaVxTNQ/X1BTH2vq5vFcr6++I52T321MgWHwBm7m/ATLdRyNxoD aoug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:references:from:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=evZ1XQ1eLWhqSBoOxU+NFfpMirj+j9IHy7I/SC/9JiY=; b=TggLeWRtkgLIzEpZqMx0qIaf/nwuI4M63Li5VQ2u2qsuKR4t7q48JtIUU16XkM/ChW UPaS0LT/ZmqPcoQitkEQsuBsseDRMEUU+0d9hvPwccWpRziDqdEGcqZQ4R7jjFESjGRU tvmv79lrFyeHaRtZJrCha5VIQkhTI6OyLFY+udMmIyNSR69UUz2CAFImjzvdYHkd1mUW 4bqP4mbQ0v6QX94QmMMmLrAfyGD6auj1zU6csfGFKpzGXnc2vZKmKJImYBLobqKyWsBB TZnIda/hSIjym5h6NQQ9GvRdv2bD0XFPoTFw8t563KOoD1IjAS1pe4oul88t15edlA4R Ob+w== X-Gm-Message-State: AODbwcBkpiw/GIUmvA1tQ+tQVr98BW6ftDipl0IxHJfKS8/FtpcfmEVE 5K+mo9jYpI+6SMP4Zd0= X-Received: by 10.99.96.81 with SMTP id u78mr35607710pgb.101.1496988674595; Thu, 08 Jun 2017 23:11:14 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b01:2042:3e8:d7ce:9b9c? (2001-44b8-31ae-7b01-2042-03e8-d7ce-9b9c.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:2042:3e8:d7ce:9b9c]) by smtp.gmail.com with ESMTPSA id t77sm412797pfg.102.2017.06.08.23.11.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Jun 2017 23:11:14 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: autoreconf missing boost? To: blubee blubeeme , FreeBSD current References: From: Kubilay Kocak Cc: Koop Mast , FreeBSD Ports List Message-ID: Date: Fri, 9 Jun 2017 16:06:34 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 06:11:16 -0000 On 6/9/17 2:52 AM, blubee blubeeme wrote: > I forgot to add this in my last email, here's the boost packages that I > have installed. > > me@blubee:~ % pkg info | grep boost > boost-jam-1.64.0 Build tool from the boost.org > boost-libs-1.64.0 Free portable C++ libraries (without > Boost.Python) > boost-python-libs-1.62.0 Framework for interfacing Python and C++ > boost_build-2.0.m12_4 Extensible cross-platform build tool suite > > > On Thu, Jun 8, 2017 at 11:56 PM, blubee blubeeme > wrote: > >> Hi >> >> I'm running a autoreconf trying to port a project; some printer code. >> Having a bit of trouble. >> >> I ran autoreconf -fi >> >> then I do: >> ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld >> --with-libintl-prefix=/usr/local >> >> that goes straight forward. >> >> Then when I run gmake, it seems to fail at linking boost or something like >> that. Here's the output of gmake, i've tried both make and gmake: >> me@blubee:~/Downloads/Epson/ut % gmake >> gmake all-recursive >> gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' >> Making all in . >> gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' >> gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' >> Making all in lib >> gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' >> Making all in . >> gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' >> CXX connexion.lo >> In file included from connexion.cpp:32:0: >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ >> include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a >> type >> typedef __vm_ooffset_t vm_ooffset_t; >> ^ >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ >> include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a >> type >> typedef __vm_pindex_t vm_pindex_t; >> ^ >> In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0, >> from /usr/local/include/boost/core/demangle.hpp:39, >> from /usr/local/include/boost/core/typeinfo.hpp:119, >> from /usr/local/include/boost/detail/sp_typeinfo.hpp:20, >> from /usr/local/include/boost/ >> smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27, >> from /usr/local/include/boost/ >> smart_ptr/detail/sp_counted_base.hpp:54, >> from /usr/local/include/boost/ >> smart_ptr/detail/shared_count.hpp:29, >> from /usr/local/include/boost/ >> smart_ptr/shared_ptr.hpp:28, >> from /usr/local/include/boost/shared_ptr.hpp:17, >> from /usr/local/include/boost/filesystem/path.hpp:29, >> from /usr/local/include/boost/filesystem.hpp:16, >> from connexion.cpp:40: >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46: >> error: expected initializer before '__nonnull' >> int posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */ >> ^ >> In file included from /usr/local/lib/gcc49/include/ >> c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0, >> from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35, >> from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39, >> from /usr/local/lib/gcc49/include/c++/ios:42, >> from /usr/local/lib/gcc49/include/c++/ostream:38, >> from /usr/local/lib/gcc49/include/c++/iostream:39, >> from connexion.cpp:38: >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1: >> error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_once) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1: >> error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_getspecific) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1: >> error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_setspecific) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1: >> error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void* >> (*)(void*), void*)' declared 'static' but never defined >> [-Werror=unused-function] >> __gthrw(pthread_create) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:106:1: >> error: 'int __gthrw_pthread_join(pthread_t, void**)' declared 'static' >> but never defined [-Werror=unused-function] >> __gthrw(pthread_join) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:107:1: >> error: 'int __gthrw_pthread_equal(pthread_t, pthread_t)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_equal) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:108:1: >> error: 'pthread* __gthrw_pthread_self()' declared 'static' but never >> defined [-Werror=unused-function] >> __gthrw(pthread_self) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:109:1: >> error: 'int __gthrw_pthread_detach(pthread_t)' declared 'static' but >> never defined [-Werror=unused-function] >> __gthrw(pthread_detach) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:111:1: >> error: 'int __gthrw_pthread_cancel(pthread_t)' declared 'static' but >> never defined [-Werror=unused-function] >> __gthrw(pthread_cancel) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:113:1: >> error: 'int __gthrw_sched_yield()' declared 'static' but never defined >> [-Werror=unused-function] >> __gthrw(sched_yield) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:115:1: >> error: 'int __gthrw_pthread_mutex_lock(pthread_mutex**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutex_lock) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:116:1: >> error: 'int __gthrw_pthread_mutex_trylock(pthread_mutex**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutex_trylock) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:118:1: >> error: 'int __gthrw_pthread_mutex_timedlock(pthread_mutex**, const >> timespec*)' declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutex_timedlock) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:120:1: >> error: 'int __gthrw_pthread_mutex_unlock(pthread_mutex**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutex_unlock) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:121:1: >> error: 'int __gthrw_pthread_mutex_init(pthread_mutex**, >> pthread_mutex_attr* const*)' declared 'static' but never defined >> [-Werror=unused-function] >> __gthrw(pthread_mutex_init) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:122:1: >> error: 'int __gthrw_pthread_mutex_destroy(pthread_mutex**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutex_destroy) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:124:1: >> error: 'int __gthrw_pthread_cond_init(pthread_cond**, pthread_cond_attr* >> const*)' declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_cond_init) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:125:1: >> error: 'int __gthrw_pthread_cond_broadcast(pthread_cond**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_cond_broadcast) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:126:1: >> error: 'int __gthrw_pthread_cond_signal(pthread_cond**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_cond_signal) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:127:1: >> error: 'int __gthrw_pthread_cond_wait(pthread_cond**, pthread_mutex**)' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_cond_wait) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:128:1: >> error: 'int __gthrw_pthread_cond_timedwait(pthread_cond**, >> pthread_mutex**, const timespec*)' declared 'static' but never defined >> [-Werror=unused-function] >> __gthrw(pthread_cond_timedwait) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:129:1: >> error: 'int __gthrw_pthread_cond_destroy(pthread_cond**)' declared >> 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_cond_destroy) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:131:1: >> error: 'int __gthrw_pthread_key_create(pthread_key_t*, void (*)(void*))' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_key_create) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:132:1: >> error: 'int __gthrw_pthread_key_delete(pthread_key_t)' declared 'static' >> but never defined [-Werror=unused-function] >> __gthrw(pthread_key_delete) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:133:1: >> error: 'int __gthrw_pthread_mutexattr_init(pthread_mutex_attr**)' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutexattr_init) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:134:1: >> error: 'int __gthrw_pthread_mutexattr_settype(pthread_mutex_attr**, int)' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutexattr_settype) >> ^ >> /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:135:1: >> error: 'int __gthrw_pthread_mutexattr_destroy(pthread_mutex_attr**)' >> declared 'static' but never defined [-Werror=unused-function] >> __gthrw(pthread_mutexattr_destroy) >> ^ >> cc1plus: all warnings being treated as errors >> gmake[3]: *** [Makefile:667: connexion.lo] Error 1 >> gmake[3]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut/lib' >> gmake[2]: *** [Makefile:688: all-recursive] Error 1 >> gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut/lib' >> gmake[1]: *** [Makefile:605: all-recursive] Error 1 >> gmake[1]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' >> gmake: *** [Makefile:513: all] Error 2 >> me@blubee:~/Downloads/Epson/ut % >> >> >> ==================================== >> is this a glang vs gcc thing or something else? >> I feel like I'm getting close to porting this software but this is a >> little bit above me. >> >> Any help would be helpful. >> >> Best, >> Owen >> Hi Owen, freebsd-ports (CC'd) is probably the better place for this question (currently). CC Koop (kwm@) given recent update [1] to boost-python-libs, though not necessarily implicated. You may want to additionally consider CC'ing freebsd-office in replies given (office@) is the current maintainer. [1] http://svnweb.freebsd.org/changeset/ports/442853 ./koobs From owner-freebsd-current@freebsd.org Fri Jun 9 09:24:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBB98BF06B4 for ; Fri, 9 Jun 2017 09:24:38 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 ADD9E84E3A for ; Fri, 9 Jun 2017 09:24:38 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pf0-x232.google.com with SMTP id x63so26613566pff.3 for ; Fri, 09 Jun 2017 02:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NlNfqF+ooFKYn8EnlkHUgE3Zxost5I0IhQklCvbRZSA=; b=FbrxNmzy7xalZF81w+U+w0tqon1jIkgrSkfeTqPMFAEgbrLPxGZrnRSsjJBUzuG19S xkrkFdTinaIu7hrM/dZlASEBJX0FEiu+vJX4OxIaj1j15lTvGAiPRdJyPjFmZ/3NtfvM NrEHBCjDs+2WmSW+86IvMFnhvz13UDBNzisqoiR4AawkwM/fCbLvQRZPA38XovEB6vS5 wpPnspUUdO9jYIrC8ge30kzJxRFjgh1fbeFYftw+C52Wv/6hkB9d/STrWw7oHyhE6m7B gz79sEXM5IwBiJZEzx3qlofLn2HAb1SXsc1AMbYhNFoHdEFd25v2Ip0XIf6xohEftoF3 00TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NlNfqF+ooFKYn8EnlkHUgE3Zxost5I0IhQklCvbRZSA=; b=DC23D+LrRmHGSNyg+akwc5OGpe8KdoL9VKT7ZwtVgIVlSN9RXEXJVTn17gqUBXkyIm nqzeqz8PtAYl/it/zETm5trW+Qv8lKK8IGXmcQp8pETbC/bWKcs2zhZPfkgKUs4FIdly a2GQoFCGHAh2oIhGF9B8LxGfVNg7K8bIPxY5w+Y/2AfxeZ8tJ6rQqAX4OkdE/684SeN1 ue77EKND+USV2HMy8uf13qCIjoZ/Wq/YCh7eZr+tl9TzeCFNBtzxAmo+eTVXDL0hm610 izOEbedtzeca3aTR4/9T6RmQatlV8ddf92/4kGk8OjgA/qz9iK9ThpUC/Loss1HEiK+W SoNQ== X-Gm-Message-State: AODbwcA5QbwFp1wthfaNYaHJ3bMZpGr0IJ2F3/Ppyhm3+CDJYBuIr9Q0 11AY/jbIYSdATbc6Yus3lUhGeauediIf X-Received: by 10.98.0.69 with SMTP id 66mr2857787pfa.127.1497000277496; Fri, 09 Jun 2017 02:24:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Fri, 9 Jun 2017 02:24:37 -0700 (PDT) From: blubee blubeeme Date: Fri, 9 Jun 2017 17:24:37 +0800 Message-ID: Subject: xsltproc outputting nothing To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 09:24:39 -0000 I tried sending this email to the gnome mailing list but no responses. Can possibly get some help with this here: === Hi I am trying to convert a .xsl file to a hpp file but the output is only a blank file. Here's the commands that I am running: ======================================== xsltproc --verbose --stringparam format hpp ./lib/tag.xsl > TAGS.hpp creating dictionary for stylesheet reusing dictionary from ./lib/tag.xsl for stylesheet xsltParseStylesheetProcess : found stylesheet xsltPrecomputeStylesheet: removing ignorable blank node xsltParseTemplateContent: removing text xsltCompilePattern : parsing 'tags' xsltCompilePattern : parsed tags, default priority 0.000000 added pattern : 'tags' priority 0.000000 parsed 1 templates Resolving attribute sets references freeing dictionary from stylesheet here's the tags.xsl file: ======================================== // Automatically generated from lib/tag.xml using lib/tag.xsl. #ifndef utsushi_tag_hpp_ #define utsushi_tag_hpp_ #include <set> #include <boost/operators.hpp> #include "key.hpp" #include "string.hpp" namespace utsushi { struct tag { //! Collect options and groups by the aspects they affect /*! A %tag::symbol is a string-like key that can be used to indicate * which aspects are affected by an option or group. An option may * specify zero or more %tag symbols. * * Similar to a descriptor, every %tag::symbol provides name() and * text() accessors describing its purpose. A user interface may * use this information to provide a more human-oriented and mostly * self-documenting view of tags. * * \note The UI is responsible for the translation of name() and * text() as well as any formatting of the text(). * * \sa descriptor::name(), descriptor::text() */ class symbol : boost::totally_ordered< symbol > { public: symbol (const key& key, const string& name, const string& text); //! \copybrief descriptor::name const string& name () const; //! \copybrief descriptor::text const string& text () const; bool operator== (const symbol& ts) const; bool operator< (const symbol& ts) const; operator key () const; private: key key_; string name_; string text_; }; static const symbol none; static const symbol ; }; class tags { private: typedef std::set< tag::symbol > container_type; static container_type set_; static void initialize (); public: typedef container_type::size_type size_type; typedef container_type::const_iterator const_iterator; static size_type count (); static const_iterator begin (); static const_iterator end (); }; } // namespace utsushi #endif /* utsushi_tag_hpp_ */ // Automatically generated from tag.xml using tag.xsl. #ifdef HAVE_CONFIG_H #include <config.h> #endif #include "utsushi/i18n.hpp" #include "utsushi/tag.hpp" namespace utsushi { tag::symbol::symbol (const key& key, const string& name, const string& text) : key_(key), name_(name), text_(text) {} const string& tag::symbol::name () const { return name_; } const string& tag::symbol::text () const { return text_; } bool tag::symbol::operator== (const symbol& ts) const { return key_ == ts.key_; } bool tag::symbol::operator< (const tag::symbol& ts) const { return key_ < ts.key_; } tag::symbol::operator key () const { return key_; } const tag::symbol tag:: ( "_", SEC_N_(""), CCB_N_("") ); tags::container_type tags::set_; void tags::initialize () { container_type::iterator hint = set_.begin (); hint = set_.insert (hint, tag::); } tags::size_type tags::count () { if (set_.empty ()) { initialize (); } return set_.size (); } tags::const_iterator tags::begin () { if (set_.empty ()) { initialize (); } return set_.begin (); } tags::const_iterator tags::end () { if (set_.empty ()) { initialize (); } return set_.end (); } } // namespace utsushi Best, Owen From owner-freebsd-current@freebsd.org Fri Jun 9 12:57:24 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EB29BF415C for ; Fri, 9 Jun 2017 12:57:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 17B6366161 for ; Fri, 9 Jun 2017 12:57:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 13A66BF415B; Fri, 9 Jun 2017 12:57:24 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11667BF415A for ; Fri, 9 Jun 2017 12:57:24 +0000 (UTC) (envelope-from david@catwhisker.org) 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 5A73666160 for ; Fri, 9 Jun 2017 12:57:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v59CvFJ6075637 for ; Fri, 9 Jun 2017 12:57:15 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v59CvFgr075636 for current@freebsd.org; Fri, 9 Jun 2017 05:57:15 -0700 (PDT) (envelope-from david) Date: Fri, 9 Jun 2017 05:57:15 -0700 From: David Wolfskill To: current@freebsd.org Subject: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305" Message-ID: <20170609125715.GP1180@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="55BQxs/tzKPczcTk" Content-Disposition: inline User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 12:57:24 -0000 --55BQxs/tzKPczcTk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Build machine updated from r319689 to r319733 OK; smoke test was uneventful. Laptop updated similarly, but smoke test was a little more "interesting". Turns out that laptop gets to multi-user mode OK... if I disable starting xdm, devd, and hald. But then, issuing "service hald onestart" generates the panic in question -- at r319733. At r319689, xdm & friends worked fine. I have placed copies of the /var/crash/*.6 files in -- along with gzipped copies, as well. (It's residential DSL in the US, so there's not a huge amount of bandwidth.) I get the impression that something (ini hald) was trying to use the freebsd11 version of stat(), and Something Bad happened: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305 cpuid =3D 7 time =3D 1497011454 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff803a461b =3D db_trace_self_wrapper+0x2= b/frame 0xfffffe0c268ff600 vpanic() at 0xffffffff80a1f94c =3D vpanic+0x19c/frame 0xfffffe0c268ff680 kassert_panic() at 0xffffffff80a1f7a6 =3D kassert_panic+0x126/frame 0xfffff= e0c268ff6f0 __mtx_lock_flags() at 0xffffffff809fedfe =3D __mtx_lock_flags+0x14e/frame 0= xfffffe0c268ff740 soo_stat() at 0xffffffff80a8f8f0 =3D soo_stat+0x60/frame 0xfffffe0c268ff770 kern_fstat() at 0xffffffff809cb378 =3D kern_fstat+0xa8/frame 0xfffffe0c268f= f7c0 freebsd11_fstat() at 0xffffffff809cb28d =3D freebsd11_fstat+0x1d/frame 0xff= fffe0c268ff930 amd64_syscall() at 0xffffffff80e31fb4 =3D amd64_syscall+0x5a4/frame 0xfffff= e0c268ffab0 Xfast_syscall() at 0xffffffff80e12eab =3D Xfast_syscall+0xfb/frame 0xfffffe= 0c268ffab0 --- syscall (189, FreeBSD ELF64, freebsd11_fstat), rip =3D 0x801b4973a, rsp= =3D 0x7fffffffe988, rbp =3D 0x7fffffffea20 --- KDB: enter: panic Note: the hald in question was built under FreeBSD stable/11 (as are all my ports); I noted the existence of, and installed, ports/misc/compat11s before (re-)creating the crash. (And yes, the ports that have kernel modules get the kernel modules rebuilt on head every time I rebuild the kernel on head.) With the caveat that I actually use the laptop in my day-to-day activities, I'm happy to try various combinations of patching, testing, and reporting results. Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --55BQxs/tzKPczcTk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZOpsrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XkoEH/RCqu5LTiwnqD6BDaQMnpf1x oAL+KcqsY6D5Nv0cGXapRW9BjxEv5DoiQLcU07HZDYaf2X/F25AzaRw88vzQJ4cQ bW/l8auPa12F5HBPvVhohcsEOn/qKcuHTZ+f2mCPtVzSkj4MGKQDoTT71mz3S7vt 4B3JuN5ph/iha4A4rwzBaCkL/UwQV9yUQd9Oy2MyAqEVbihOx0K44LfYPhIMFgM2 3Y03uMHrRIwMlOLs+q5B6Sef3bKklvnZszon4qJs+yBWSXSpRI+r0Sza2apYQvgz QB66yXsYP6JwkCG2PFD1BkAx0wP+ajxMNwflyKmNWLbYs5o1oaqSC919EIqSfzw= =zH80 -----END PGP SIGNATURE----- --55BQxs/tzKPczcTk-- From owner-freebsd-current@freebsd.org Fri Jun 9 12:57:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE1ACBF41E0 for ; Fri, 9 Jun 2017 12:57:59 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC4326628B; Fri, 9 Jun 2017 12:57:59 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [IPv6:::1] (unknown [127.0.1.132]) by freefall.freebsd.org (Postfix) with ESMTP id D4E939E86; Fri, 9 Jun 2017 12:57:58 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Subject: Re: CFT: EVDEV support in psm(4) driver To: freebsd-current@freebsd.org References: <5fa9225de944d6cdac0b7e5749b452a9@kondratyev.su> From: Jonathan Anderson Cc: vladimir@kondratyev.su Message-ID: <03831fcc-5744-21da-0756-d28bf256c203@FreeBSD.org> Date: Fri, 9 Jun 2017 08:57:58 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5fa9225de944d6cdac0b7e5749b452a9@kondratyev.su> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 12:58:00 -0000 Hi Vladimir, On 04/16/17 15:18, Vladimir Kondratyev wrote: > Following patch [1] bring in multitouch EVDEV support for Synaptics > and Elan PS/2 > touchpads found in many laptops. (And for generic relative PS/2 mices > as well). > This allows to replace our limited in-kernel gesture processor with > full-blown > one from xf86-input-synaptics or xf86-input-libinput driver and makes > Synaptics and Elan PS/2 touchpad support to be mostly on par with Linux Thanks very much... I've been using your patch for awhile with my Synaptics touchpad and it's lovely to have two-finger scrolling that works properly! I did need to massage the patch to make it apply on drm-next: https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5 Sometimes I experience dropped touchpad events, particularly when the system is busy and my wi-fi is being reconfigured. Is there anything I can do to help debug this? Jon -- jonathan@FreeBSD.org From owner-freebsd-current@freebsd.org Fri Jun 9 13:55:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E70D2BF53AD for ; Fri, 9 Jun 2017 13:55:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CE148685AE for ; Fri, 9 Jun 2017 13:55:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id CA40EBF53AC; Fri, 9 Jun 2017 13:55:34 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9B4DBF53AB for ; Fri, 9 Jun 2017 13:55:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 6EED8685AD; Fri, 9 Jun 2017 13:55:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v59DtHxV056482 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Jun 2017 16:55:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v59DtHxV056482 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v59DtHVh056481; Fri, 9 Jun 2017 16:55:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 9 Jun 2017 16:55:17 +0300 From: Konstantin Belousov To: David Wolfskill Cc: current@freebsd.org, glebius@freebsd.org Subject: Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305" Message-ID: <20170609135517.GA2088@kib.kiev.ua> References: <20170609125715.GP1180@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170609125715.GP1180@albert.catwhisker.org> User-Agent: Mutt/1.8.2 (2017-04-18) 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.23 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, 09 Jun 2017 13:55:35 -0000 On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote: > Build machine updated from r319689 to r319733 OK; smoke test was > uneventful. > > Laptop updated similarly, but smoke test was a little more "interesting". > > Turns out that laptop gets to multi-user mode OK... if I disable > starting xdm, devd, and hald. But then, issuing "service hald onestart" > generates the panic in question -- at r319733. At r319689, xdm & > friends worked fine. > > I have placed copies of the /var/crash/*.6 files in > -- along with > gzipped copies, as well. (It's residential DSL in the US, so there's > not a huge amount of bandwidth.) > > I get the impression that something (ini hald) was trying to use > the freebsd11 version of stat(), and Something Bad happened: > > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305 > cpuid = 7 > time = 1497011454 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff803a461b = db_trace_self_wrapper+0x2b/frame 0xfffffe0c268ff600 > vpanic() at 0xffffffff80a1f94c = vpanic+0x19c/frame 0xfffffe0c268ff680 > kassert_panic() at 0xffffffff80a1f7a6 = kassert_panic+0x126/frame 0xfffffe0c268ff6f0 > __mtx_lock_flags() at 0xffffffff809fedfe = __mtx_lock_flags+0x14e/frame 0xfffffe0c268ff740 > soo_stat() at 0xffffffff80a8f8f0 = soo_stat+0x60/frame 0xfffffe0c268ff770 The main suspect is r319722. Try reverting it or downgrading before it (the later might be simple due to the patch size). > kern_fstat() at 0xffffffff809cb378 = kern_fstat+0xa8/frame 0xfffffe0c268ff7c0 > freebsd11_fstat() at 0xffffffff809cb28d = freebsd11_fstat+0x1d/frame 0xfffffe0c268ff930 > amd64_syscall() at 0xffffffff80e31fb4 = amd64_syscall+0x5a4/frame 0xfffffe0c268ffab0 > Xfast_syscall() at 0xffffffff80e12eab = Xfast_syscall+0xfb/frame 0xfffffe0c268ffab0 > --- syscall (189, FreeBSD ELF64, freebsd11_fstat), rip = 0x801b4973a, rsp = 0x7fffffffe988, rbp = 0x7fffffffea20 --- > KDB: enter: panic > > > Note: the hald in question was built under FreeBSD stable/11 (as > are all my ports); I noted the existence of, and installed, > ports/misc/compat11s before (re-)creating the crash. (And yes, the > ports that have kernel modules get the kernel modules rebuilt on > head every time I rebuild the kernel on head.) > > With the caveat that I actually use the laptop in my day-to-day > activities, I'm happy to try various combinations of patching, > testing, and reporting results. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Looking forward to telling Mr. Trump: "You're fired!" > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Fri Jun 9 14:58:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65C0CBF6860 for ; Fri, 9 Jun 2017 14:58:30 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 335E66EE7B for ; Fri, 9 Jun 2017 14:58:29 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v59EwLP7038406; Fri, 9 Jun 2017 23:58:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 9 Jun 2017 23:58:21 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: blubee blubeeme Subject: Re: nvidia drivers mutex lock Message-Id: <20170609235821.5f76f8377f71051ef631a9f0@dec.sakura.ne.jp> In-Reply-To: References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 14:58:30 -0000 If you want to try internal GPU... GPU on Skylake-generation processors is not yet supported on -head. If you want to test without nvidia GPU, you need to try drm-next branch with x11-drivers/xf86-video-intel (for the branch?). https://lists.freebsd.org/pipermail/freebsd-current/2016-December/063980.html https://github.com/freebsd/freebsd-base-graphics https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM#Testing_Instructions_.2F_How_To Don't forget to remove (or comment out) nvidia-driver related things from loader.conf and xorg.conf if you try Intel internal GPU. x11/nvidia-driver doesn't support hybrid (Optimus) graphics (even on Linux version). As I'm running with nvidia-driver, I've not tested the branch at all. So possibly some info could be racked to make it fully functional. On Tue, 6 Jun 2017 22:08:24 +0800 blubee blubeeme wrote: > This is getting out of hand. I can't even keep x going for ten minutes > sometimes. > I've tested all the suggestions in this thread and they just don't work. > > I have put out a print of sysctl hw. here : https://paste2.org/ It was the top page. No info available. > > With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz > The bios on this laptop I can either set graphics to discrete or mshybrid. > > I've tried in the past to disable discrete and run mshybrid but that always > comes up with 0 screens found. Even just doing Xorg -configure. > > Anyone have some tips on disabling nvidia drivers, running this cpu with > igpu for a while? > > Best, > Owen > > On Sun, Jun 4, 2017, 18:11 blubee blubeeme wrote: > > > Thanks a lot! I'll give it a shot in a bit. > > > > Best, > > Owen > > > > On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI wrote: > > > >> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. > >> > >> But beware! Sometimes upstream changes make any of FreeBSD patches not > >> applicable (incorporating any of these, incompatible modifies, ...). > >> > >> For 381.22, current patchset applies and builds fine for me. > >> > >> > >> On Sun, 04 Jun 2017 08:04:50 +0000 > >> blubee blubeeme wrote: > >> > >> > I'm running with svn and I build by make. > >> > If in use these steps, the BSD related patches will be applied, etc? > >> > > >> > Best, > >> > Owen > >> > > >> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI > >> wrote: > >> > > >> > > Hi. > >> > > > >> > > Not in ports tree, but easily overridden by adding > >> > > > >> > > DISTVERSION=381.22 -DNO_CHECKSUM > >> > > > >> > > on make command line. Makefile of x11/nvidia-driver has a mechanism > >> > > to do so for someone requires newer version (newer GPU support, etc.). > >> > > > >> > > If you're using portupgrade, > >> > > > >> > > portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f > >> x11/nvidia-driver > >> > > > >> > > would do the same. > >> > > > >> > > If you installed it via pkg, there's no way to try. :-( > >> > > (As it's pre-built.) > >> > > > >> > > > >> > > On Sun, 04 Jun 2017 07:04:01 +0000 > >> > > blubee blubeeme wrote: > >> > > > >> > > > Hi @tomoaki > >> > > > Is that version of nvidia drivers currently in the ports tree? I > >> just > >> > > > checked but it seems not to be. > >> > > > > >> > > > @jeffrey > >> > > > I just generated a new xorg based on the force composition setting. > >> I > >> > > > merged it with my previous xorg I'll reboot, see if it gives better > >> > > > performance. > >> > > > > >> > > > It seems like my system is locking up more frequently now. Sometimes > >> > > right > >> > > > after a reboot the system, the screen locks and it's reboot and > >> pray. > >> > > > > >> > > > Best, > >> > > > Owen > >> > > > > >> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet < > >> jeffreybouquet@yahoo.com> > >> > > wrote: > >> > > > > >> > > > > SOME LINES BOTTOM POSTED, SEE... > >> > > > > -------------------------------------------- > >> > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: > >> > > > > > >> > > > > Subject: Re: nvidia drivers mutex lock > >> > > > > To: freebsd-current@freebsd.org > >> > > > > Cc: "Jeffrey Bouquet" , "blubee > >> blubeeme" < > >> > > > > gurenchan@gmail.com> > >> > > > > Date: Friday, June 2, 2017, 11:25 PM > >> > > > > > >> > > > > Hi. > >> > > > > Version > >> > > > > 381.22 (5 days newer than 375.66) of the driver states... > >> > > > > [1] > >> > > > > > >> > > > > Fixed hangs and > >> > > > > crashes that could occur when an OpenGL context is > >> > > > > created while the system is out of available > >> > > > > memory. > >> > > > > > >> > > > > Can this be related > >> > > > > with your hang? > >> > > > > > >> > > > > IMHO, > >> > > > > possibly allocating new resource (using os.lock_mtx > >> > > > > guard) > >> > > > > without checking the lock first while > >> > > > > previous request is waiting for > >> > > > > another can > >> > > > > cause the duplicated lock situation. And high memory > >> > > > > pressure would easily cause the situation. > >> > > > > > >> > > > > [1] http://www.nvidia.com/Download/driverResults.aspx/ > >> 118527/en-us > >> > > > > > >> > > > > Hope it helps. > >> > > > > > >> > > > > > >> > > > > On Thu, 1 Jun > >> > > > > 2017 22:35:46 +0000 (UTC) > >> > > > > Jeffrey Bouquet > >> > > > > > >> > > > > wrote: > >> > > > > > >> > > > > > I see the same > >> > > > > message, upon load, ... > >> > > > > > > >> > > > > -------------------------------------------- > >> > > > > > On Thu, 6/1/17, blubee blubeeme > >> > > > > wrote: > >> > > > > > > >> > > > > > Subject: > >> > > > > nvidia drivers mutex lock > >> > > > > > To: freebsd-ports@freebsd.org, > >> > > > > freebsd-current@freebsd.org > >> > > > > > Date: Thursday, June 1, 2017, 11:35 > >> > > > > AM > >> > > > > > > >> > > > > > I'm > >> > > > > running nvidia-drivers 375.66 with a GTX > >> > > > > > 1070 on FreeBSD-Current > >> > > > > > > >> > > > > > This problem > >> > > > > just started happening > >> > > > > > recently but, > >> > > > > every so often my laptop > >> > > > > > screen will > >> > > > > just blank out and then I > >> > > > > > have to > >> > > > > power cycle to get the > >> > > > > > machine up and > >> > > > > running again. > >> > > > > > > >> > > > > > It seems to be a problem with nvidia > >> > > > > > drivers acquiring duplicate lock. Any > >> > > > > > info on this? > >> > > > > > > >> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > >> > > > > > acquiring duplicate lock of same > >> > > > > type: > >> > > > > > "os.lock_mtx" > >> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: 1st > >> > > > > > os.lock_mtx @ nvidia_os.c:841 > >> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: 2nd > >> > > > > > os.lock_mtx @ nvidia_os.c:841 > >> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > >> > > > > > stack backtrace: > >> > > > > > > >> > > > > Jun$B".(B 2 02:29:41 blubee kernel: #0 > >> > > > > > > >> > > > > 0xffffffff80ab7770 at > >> > > > > > > >> > > > > witness_debugger+0x70 > >> > > > > > Jun$B".(B 2 > >> > > > > 02:29:41 blubee kernel: #1 > >> > > > > > > >> > > > > 0xffffffff80ab7663 at > >> > > > > > > >> > > > > witness_checkorder+0xe23 > >> > > > > > Jun$B".(B 2 > >> > > > > 02:29:41 blubee kernel: #2 > >> > > > > > > >> > > > > 0xffffffff80a35b93 at > >> > > > > > > >> > > > > __mtx_lock_flags+0x93 > >> > > > > > Jun$B".(B 2 > >> > > > > 02:29:41 blubee kernel: #3 > >> > > > > > > >> > > > > 0xffffffff82f4397b at > >> > > > > > > >> > > > > os_acquire_spinlock+0x1b > >> > > > > > Jun$B".(B 2 > >> > > > > 02:29:41 blubee kernel: #4 > >> > > > > > > >> > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 > >> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > >> > > > > > ACPI Warning: > >> > > > > \_SB.PCI0.PEG0.PEGP._DSM: > >> > > > > > Argument #4 > >> > > > > type mismatch - Found > >> > > > > > [Buffer], ACPI > >> > > > > requires [Package] > >> > > > > > > >> > > > > (20170303/nsarguments-205) > >> > > > > > Jun$B".(B 2 > >> > > > > 02:29:42 blubee kernel: > >> > > > > > > >> > > > > nvidia-modeset: Allocated GPU:0 > >> > > > > > > >> > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > >> > > > > > PCI:0000:01:00.0 > >> > > > > > > >> > > > > > >> > > > > > Best, > >> > > > > > Owen > >> > > > > > > >> > > > > _______________________________________________ > >> > > > > > freebsd-ports@freebsd.org > >> > > > > > mailing list > >> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > >> > > > > > To unsubscribe, send any mail to > >> > > > > "freebsd-ports-unsubscribe@freebsd.org" > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > ... then Xorg will > >> > > > > run happily twelve hours or so. The lockups here happen > >> > > > > usually > >> > > > > > when too large or too many of > >> > > > > number of tabs/ large web pages with complex CSS etc > >> > > > > > are opened at a time. > >> > > > > > So no help, just a 'me > >> > > > > too'. > >> > > > > > > >> > > > > _______________________________________________ > >> > > > > > freebsd-current@freebsd.org > >> > > > > mailing list > >> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > > > > > > >> > > > > To unsubscribe, send any mail to " > >> > > freebsd-current-unsubscribe@freebsd.org > >> > > > > " > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Tomoaki > >> > > > > AOKI > >> > > > > > >> > > > > > >> > > > > > >> > > > > ........................ > >> > > > > might be a workaround > >> > > > > Xorg/nvidia ran all night with this: > >> > > > > nvidia-settings >> X server display configuration >> Advanced > >> >> > >> > > Force > >> > > > > Full Composition Pipeline > >> > > > > ... for the laptop freezing. Could not hurt to try. " merge with > >> > > > > Xorg.conf " from nvidia-settings... > >> > > > > ...................... > >> > > > > 18 hours uptime so far, even past > >> > > > > the 3 am periodic scripts. Have not rebooted out of the Xorg > >> though > >> > > so > >> > > > > may require edit-out of > >> > > > > xorg.conf if that is the case, in other words differing from > >> real-time > >> > > > > apply and > >> > > > > xorg initially start applies. > >> > > > > ........ > >> > > > > > >> > > > > > >> > > > _______________________________________________ > >> > > > freebsd-current@freebsd.org mailing list > >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > > > To unsubscribe, send any mail to " > >> > > freebsd-current-unsubscribe@freebsd.org" > >> > > > > >> > > > > >> > > > >> > > > >> > > -- > >> > > Tomoaki AOKI > >> > > > >> > >> > >> -- > >> Tomoaki AOKI > >> > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Fri Jun 9 15:11:25 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F682BF70F3 for ; Fri, 9 Jun 2017 15:11:25 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 B55DE701B6 for ; Fri, 9 Jun 2017 15:11:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v59FBMZ8038645; Sat, 10 Jun 2017 00:11:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 10 Jun 2017 00:11:22 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: blubee blubeeme Subject: Re: nvidia drivers mutex lock Message-Id: <20170610001122.9ea858d8feb2c7b58cfc00a6@dec.sakura.ne.jp> In-Reply-To: References: <1100140349.1166835.1496498112171.ref@mail.yahoo.com> <1100140349.1166835.1496498112171@mail.yahoo.com> <20170604165320.f4c06ed7ad867f4ec0280f09@dec.sakura.ne.jp> <20170604175911.6926dc73386d211c4a39bbc0@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 15:11:25 -0000 Hmm, now I now strongly suspect hardware or noise issue, as nvidia GPU seems to fall / re-appear on bus for some times. If it WAS a desktop one and GPU is attached via PCIe connector, I'll immediately power off and re-connect the card, with some physical dust cleaning, but this time the GPU is onboard... *Not shure, but possibly, too short timeout on driver initialization code can show problems like this (too short to initialize). On Thu, 8 Jun 2017 02:27:51 +0800 blubee blubeeme wrote: > I was just looking through dmesg and noticed these: > > Jun 6 21:40:52 blubee kernel: nvidia-modeset: Allocated GPU:0 > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI:0000:01:00.0 > Jun 6 21:41:05 blubee kernel: NVRM: GPU at PCI:0000:01:00: > GPU-54a7b304-c99d-efee-0117-0ce119063cd6 > Jun 6 21:41:05 blubee kernel: NVRM: GPU Board Serial Number: > Jun 6 21:41:05 blubee kernel: NVRM: Xid (PCI:0000:01:00): 79, GPU has > fallen off the bus. > Jun 6 21:41:05 blubee kernel: > Jun 6 21:41:05 blubee kernel: NVRM: GPU at 0000:01:00.0 has fallen off the > bus. > Jun 6 21:41:05 blubee kernel: NVRM: GPU is on Board . > Jun 6 21:41:05 blubee kernel: NVRM: A GPU crash dump has been created. If > possible, please run > Jun 6 21:41:05 blubee kernel: NVRM: nvidia-bug-report.sh as root to > collect this data before > Jun 6 21:41:05 blubee kernel: NVRM: the NVIDIA kernel module is unloaded. > Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to > query display engine channel state: 0x0000927c:0:0:0x0000000f > Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to > query display engine channel state: 0x0000927c:0:0:0x0000000f > Jun 6 21:41:05 blubee kernel: vgapci0: child nvidia0 requested > pci_enable_io > Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to > query display engine channel state: 0x0000927c:0:0:0x0000000f > Jun 6 21:41:06 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to > query display engine channel state: 0x0000927c:0:0:0x0000000f > Jun 6 21:41:22 blubee kernel: . > > then that lead me to this nvidia forum thread: > https://devtalk.nvidia.com/default/topic/985037/gtx-1070-quot-gpu-has-fallen-off-the-bus-quot-running-3d-games-in-arch-linux-/ > > maybe it could help somehow? > > Best, > Owen > > On Tue, Jun 6, 2017 at 10:08 PM, blubee blubeeme > wrote: > > > This is getting out of hand. I can't even keep x going for ten minutes > > sometimes. > > I've tested all the suggestions in this thread and they just don't work. > > > > I have put out a print of sysctl hw. here : https://paste2.org/ > > > > With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz > > The bios on this laptop I can either set graphics to discrete or mshybrid. > > > > I've tried in the past to disable discrete and run mshybrid but that > > always comes up with 0 screens found. Even just doing Xorg -configure. > > > > Anyone have some tips on disabling nvidia drivers, running this cpu with > > igpu for a while? > > > > Best, > > Owen > > > > On Sun, Jun 4, 2017, 18:11 blubee blubeeme wrote: > > > >> Thanks a lot! I'll give it a shot in a bit. > >> > >> Best, > >> Owen > >> > >> On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI > >> wrote: > >> > >>> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. > >>> > >>> But beware! Sometimes upstream changes make any of FreeBSD patches not > >>> applicable (incorporating any of these, incompatible modifies, ...). > >>> > >>> For 381.22, current patchset applies and builds fine for me. > >>> > >>> > >>> On Sun, 04 Jun 2017 08:04:50 +0000 > >>> blubee blubeeme wrote: > >>> > >>> > I'm running with svn and I build by make. > >>> > If in use these steps, the BSD related patches will be applied, etc? > >>> > > >>> > Best, > >>> > Owen > >>> > > >>> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI > >>> wrote: > >>> > > >>> > > Hi. > >>> > > > >>> > > Not in ports tree, but easily overridden by adding > >>> > > > >>> > > DISTVERSION=381.22 -DNO_CHECKSUM > >>> > > > >>> > > on make command line. Makefile of x11/nvidia-driver has a mechanism > >>> > > to do so for someone requires newer version (newer GPU support, > >>> etc.). > >>> > > > >>> > > If you're using portupgrade, > >>> > > > >>> > > portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f > >>> x11/nvidia-driver > >>> > > > >>> > > would do the same. > >>> > > > >>> > > If you installed it via pkg, there's no way to try. :-( > >>> > > (As it's pre-built.) > >>> > > > >>> > > > >>> > > On Sun, 04 Jun 2017 07:04:01 +0000 > >>> > > blubee blubeeme wrote: > >>> > > > >>> > > > Hi @tomoaki > >>> > > > Is that version of nvidia drivers currently in the ports tree? I > >>> just > >>> > > > checked but it seems not to be. > >>> > > > > >>> > > > @jeffrey > >>> > > > I just generated a new xorg based on the force composition > >>> setting. I > >>> > > > merged it with my previous xorg I'll reboot, see if it gives better > >>> > > > performance. > >>> > > > > >>> > > > It seems like my system is locking up more frequently now. > >>> Sometimes > >>> > > right > >>> > > > after a reboot the system, the screen locks and it's reboot and > >>> pray. > >>> > > > > >>> > > > Best, > >>> > > > Owen > >>> > > > > >>> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet < > >>> jeffreybouquet@yahoo.com> > >>> > > wrote: > >>> > > > > >>> > > > > SOME LINES BOTTOM POSTED, SEE... > >>> > > > > -------------------------------------------- > >>> > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: > >>> > > > > > >>> > > > > Subject: Re: nvidia drivers mutex lock > >>> > > > > To: freebsd-current@freebsd.org > >>> > > > > Cc: "Jeffrey Bouquet" , "blubee > >>> blubeeme" < > >>> > > > > gurenchan@gmail.com> > >>> > > > > Date: Friday, June 2, 2017, 11:25 PM > >>> > > > > > >>> > > > > Hi. > >>> > > > > Version > >>> > > > > 381.22 (5 days newer than 375.66) of the driver states... > >>> > > > > [1] > >>> > > > > > >>> > > > > Fixed hangs and > >>> > > > > crashes that could occur when an OpenGL context is > >>> > > > > created while the system is out of available > >>> > > > > memory. > >>> > > > > > >>> > > > > Can this be related > >>> > > > > with your hang? > >>> > > > > > >>> > > > > IMHO, > >>> > > > > possibly allocating new resource (using os.lock_mtx > >>> > > > > guard) > >>> > > > > without checking the lock first while > >>> > > > > previous request is waiting for > >>> > > > > another can > >>> > > > > cause the duplicated lock situation. And high memory > >>> > > > > pressure would easily cause the situation. > >>> > > > > > >>> > > > > [1] http://www.nvidia.com/Download > >>> /driverResults.aspx/118527/en-us > >>> > > > > > >>> > > > > Hope it helps. > >>> > > > > > >>> > > > > > >>> > > > > On Thu, 1 Jun > >>> > > > > 2017 22:35:46 +0000 (UTC) > >>> > > > > Jeffrey Bouquet > >>> > > > > > >>> > > > > wrote: > >>> > > > > > >>> > > > > > I see the same > >>> > > > > message, upon load, ... > >>> > > > > > > >>> > > > > -------------------------------------------- > >>> > > > > > On Thu, 6/1/17, blubee blubeeme > >>> > > > > wrote: > >>> > > > > > > >>> > > > > > Subject: > >>> > > > > nvidia drivers mutex lock > >>> > > > > > To: freebsd-ports@freebsd.org, > >>> > > > > freebsd-current@freebsd.org > >>> > > > > > Date: Thursday, June 1, 2017, 11:35 > >>> > > > > AM > >>> > > > > > > >>> > > > > > I'm > >>> > > > > running nvidia-drivers 375.66 with a GTX > >>> > > > > > 1070 on FreeBSD-Current > >>> > > > > > > >>> > > > > > This problem > >>> > > > > just started happening > >>> > > > > > recently but, > >>> > > > > every so often my laptop > >>> > > > > > screen will > >>> > > > > just blank out and then I > >>> > > > > > have to > >>> > > > > power cycle to get the > >>> > > > > > machine up and > >>> > > > > running again. > >>> > > > > > > >>> > > > > > It seems to be a problem with nvidia > >>> > > > > > drivers acquiring duplicate lock. Any > >>> > > > > > info on this? > >>> > > > > > > >>> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > >>> > > > > > acquiring duplicate lock of same > >>> > > > > type: > >>> > > > > > "os.lock_mtx" > >>> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: 1st > >>> > > > > > os.lock_mtx @ nvidia_os.c:841 > >>> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: 2nd > >>> > > > > > os.lock_mtx @ nvidia_os.c:841 > >>> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > >>> > > > > > stack backtrace: > >>> > > > > > > >>> > > > > Jun$B".(B 2 02:29:41 blubee kernel: #0 > >>> > > > > > > >>> > > > > 0xffffffff80ab7770 at > >>> > > > > > > >>> > > > > witness_debugger+0x70 > >>> > > > > > Jun$B".(B 2 > >>> > > > > 02:29:41 blubee kernel: #1 > >>> > > > > > > >>> > > > > 0xffffffff80ab7663 at > >>> > > > > > > >>> > > > > witness_checkorder+0xe23 > >>> > > > > > Jun$B".(B 2 > >>> > > > > 02:29:41 blubee kernel: #2 > >>> > > > > > > >>> > > > > 0xffffffff80a35b93 at > >>> > > > > > > >>> > > > > __mtx_lock_flags+0x93 > >>> > > > > > Jun$B".(B 2 > >>> > > > > 02:29:41 blubee kernel: #3 > >>> > > > > > > >>> > > > > 0xffffffff82f4397b at > >>> > > > > > > >>> > > > > os_acquire_spinlock+0x1b > >>> > > > > > Jun$B".(B 2 > >>> > > > > 02:29:41 blubee kernel: #4 > >>> > > > > > > >>> > > > > 0xffffffff82c48b15 at _nv012002rm+0x185 > >>> > > > > > Jun$B".(B 2 02:29:41 blubee kernel: > >>> > > > > > ACPI Warning: > >>> > > > > \_SB.PCI0.PEG0.PEGP._DSM: > >>> > > > > > Argument #4 > >>> > > > > type mismatch - Found > >>> > > > > > [Buffer], ACPI > >>> > > > > requires [Package] > >>> > > > > > > >>> > > > > (20170303/nsarguments-205) > >>> > > > > > Jun$B".(B 2 > >>> > > > > 02:29:42 blubee kernel: > >>> > > > > > > >>> > > > > nvidia-modeset: Allocated GPU:0 > >>> > > > > > > >>> > > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > >>> > > > > > PCI:0000:01:00.0 > >>> > > > > > > >>> > > > > > >>> > > > > > Best, > >>> > > > > > Owen > >>> > > > > > > >>> > > > > _______________________________________________ > >>> > > > > > freebsd-ports@freebsd.org > >>> > > > > > mailing list > >>> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > >>> > > > > > To unsubscribe, send any mail to > >>> > > > > "freebsd-ports-unsubscribe@freebsd.org" > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > ... then Xorg will > >>> > > > > run happily twelve hours or so. The lockups here happen > >>> > > > > usually > >>> > > > > > when too large or too many of > >>> > > > > number of tabs/ large web pages with complex CSS etc > >>> > > > > > are opened at a time. > >>> > > > > > So no help, just a 'me > >>> > > > > too'. > >>> > > > > > > >>> > > > > _______________________________________________ > >>> > > > > > freebsd-current@freebsd.org > >>> > > > > mailing list > >>> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> > > > > > > >>> > > > > To unsubscribe, send any mail to " > >>> > > freebsd-current-unsubscribe@freebsd.org > >>> > > > > " > >>> > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > > >>> > > > > -- > >>> > > > > Tomoaki > >>> > > > > AOKI > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > ........................ > >>> > > > > might be a workaround > >>> > > > > Xorg/nvidia ran all night with this: > >>> > > > > nvidia-settings >> X server display configuration >> > >>> Advanced >> > >>> > > Force > >>> > > > > Full Composition Pipeline > >>> > > > > ... for the laptop freezing. Could not hurt to try. " merge > >>> with > >>> > > > > Xorg.conf " from nvidia-settings... > >>> > > > > ...................... > >>> > > > > 18 hours uptime so far, even past > >>> > > > > the 3 am periodic scripts. Have not rebooted out of the Xorg > >>> though > >>> > > so > >>> > > > > may require edit-out of > >>> > > > > xorg.conf if that is the case, in other words differing from > >>> real-time > >>> > > > > apply and > >>> > > > > xorg initially start applies. > >>> > > > > ........ > >>> > > > > > >>> > > > > > >>> > > > _______________________________________________ > >>> > > > freebsd-current@freebsd.org mailing list > >>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>> > > > To unsubscribe, send any mail to " > >>> > > freebsd-current-unsubscribe@freebsd.org" > >>> > > > > >>> > > > > >>> > > > >>> > > > >>> > > -- > >>> > > Tomoaki AOKI > >>> > > > >>> > >>> > >>> -- > >>> Tomoaki AOKI > >>> > >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Fri Jun 9 15:23:57 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4DC7BF76A7 for ; Fri, 9 Jun 2017 15:23:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BBF5E70EBB for ; Fri, 9 Jun 2017 15:23:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id B87B9BF76A5; Fri, 9 Jun 2017 15:23:57 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B811FBF76A4 for ; Fri, 9 Jun 2017 15:23:57 +0000 (UTC) (envelope-from david@catwhisker.org) 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 8B5D870EBA; Fri, 9 Jun 2017 15:23:57 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v59FNtAj076957; Fri, 9 Jun 2017 15:23:55 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v59FNtRe076956; Fri, 9 Jun 2017 08:23:55 -0700 (PDT) (envelope-from david) Date: Fri, 9 Jun 2017 08:23:55 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org, glebius@freebsd.org Subject: Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305" Message-ID: <20170609152355.GZ1180@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org, glebius@freebsd.org References: <20170609125715.GP1180@albert.catwhisker.org> <20170609135517.GA2088@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NnUDYhz5zoqA1Riz" Content-Disposition: inline In-Reply-To: <20170609135517.GA2088@kib.kiev.ua> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 15:23:57 -0000 --NnUDYhz5zoqA1Riz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 09, 2017 at 04:55:17PM +0300, Konstantin Belousov wrote: > On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote: > > Build machine updated from r319689 to r319733 OK; smoke test was > > uneventful. > >=20 > > Laptop updated similarly, but smoke test was a little more "interesting= ". > >=20 > > Turns out that laptop gets to multi-user mode OK... if I disable > > starting xdm, devd, and hald. But then, issuing "service hald onestart" > > generates the panic in question -- at r319733. At r319689, xdm & > > friends worked fine. > >=20 > > I have placed copies of the /var/crash/*.6 files in > > -- along with > > gzipped copies, as well. (It's residential DSL in the US, so there's > > not a huge amount of bandwidth.) > >=20 > > I get the impression that something (ini hald) was trying to use > > the freebsd11 version of stat(), and Something Bad happened: > >=20 > > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c= :305 > > cpuid =3D 7 > > time =3D 1497011454 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff803a461b =3D db_trace_self_wrapper= +0x2b/frame 0xfffffe0c268ff600 > > vpanic() at 0xffffffff80a1f94c =3D vpanic+0x19c/frame 0xfffffe0c268ff680 > > kassert_panic() at 0xffffffff80a1f7a6 =3D kassert_panic+0x126/frame 0xf= ffffe0c268ff6f0 > > __mtx_lock_flags() at 0xffffffff809fedfe =3D __mtx_lock_flags+0x14e/fra= me 0xfffffe0c268ff740 > > soo_stat() at 0xffffffff80a8f8f0 =3D soo_stat+0x60/frame 0xfffffe0c268f= f770 > > The main suspect is r319722. > Try reverting it or downgrading before it (the later might be simple due > to the patch size). > .... It was easy enough for me to use "svn diff -c r319722" & "svn patch --reverse-diff" to effectively revert r319722. I re-ran the build after that, and a subsequent reboot allowed me to "sudo service hald onestart" (which whined a bit about dbus not being enabled but started it anyway), after which I was able to start xdm -- so that seems to have been successful. Perhaps I'll chat with Gleb a bit later today. :-) (Our cubes are adjacent.) Thanks, Konstantin! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --NnUDYhz5zoqA1Riz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZOr2LXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XlnkH/3kcm1elZsj/DQXCIwSXFEpb zbKbIUnqnuI+HFKf5c57SiCqduu4d5W/n3idGElOsquT10wSZzwTCYiHKSG/ytj8 jO51X1cfA+7LIJGSQCiFnHjbyYw6awo6Hvlh7i4wO6NQmEwMYffBgDvHt6zHSfd+ 2br24fBBzWihn+XtJd3HU50n394vyz/TKLl/9Idj1lhQMSPC5pJxxofnUKQGpQVF qeFoDVuwEcH157qc8BV/QygHThooay2/WhPzTmCiPsfXgGUPAHxpGvnvOUaOo/VU RrRC6YKenSohNRYmKULoRwuEdpqDh5kiYqRfuOfoLjgUg6MUNp9Lj9Fzq5PFOKA= =PoRa -----END PGP SIGNATURE----- --NnUDYhz5zoqA1Riz-- From owner-freebsd-current@freebsd.org Fri Jun 9 18:40:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA60ABFA804 for ; Fri, 9 Jun 2017 18:40:20 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAD8D776F0 for ; Fri, 9 Jun 2017 18:40:20 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date:Sender :Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=hbwQeevIamg40V58JJNWd5BZhMsrjK9HytULOaxmiHE=; b=M1043TrIAm+EGlLTJrI2ceM9yt mF6DYex9G8SoTrUV0KCtqteyAEJrPjmZFT/0ryymYRj9tdt3TSUK8umHPmqGz658aUk+pO0LA0j0b zuuN2XwwqRlUv/c6SG2GbQedF74YnaMDxrbiVqDymfvUh27iMqHMNJzI9WqpP4k2xD4A=; Received: from [74.203.163.58] (port=56627 helo=lrosenman.local) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1dJOpY-000LDz-0m for freebsd-current@FreeBSD.org; Fri, 09 Jun 2017 13:40:20 -0500 Date: Fri, 9 Jun 2017 13:40:09 -0500 From: Larry Rosenman To: freebsd-current@FreeBSD.org Subject: destroying non-empty racct Message-ID: <20170609184009.pepwhgm3hfoaccmj@lrosenman.local> Mail-Followup-To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 18:40:20 -0000 I know we had this a while back, and it was fixed, but it's back. Dump header from device: /dev/mfid0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 105984 Blocksize: 512 Dumptime: Fri Jun 9 13:25:25 2017 Hostname: borg.lerctr.org Magic: FreeBSD Text Dump Version String: FreeBSD 12.0-CURRENT #29 r319458: Thu Jun 1 16:15:44 CDT 2017 root@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER Panic String: destroying non-empty racct: 4124672 allocated for resource 4 Dump Parity: 1629450792 Bounds: 3 Dump Status: good I do NOT have a core due to insufficient swap (I do have a text dump). Ideas? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-current@freebsd.org Fri Jun 9 22:55:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FD3EBFECB7 for ; Fri, 9 Jun 2017 22:55:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EACA57F0E9 for ; Fri, 9 Jun 2017 22:55:31 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id E6CE7BFECB6; Fri, 9 Jun 2017 22:55:31 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6524BFECB5 for ; Fri, 9 Jun 2017 22:55:31 +0000 (UTC) (envelope-from david@catwhisker.org) 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 977D97F0E8; Fri, 9 Jun 2017 22:55:29 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v59MtSn3080366; Fri, 9 Jun 2017 22:55:28 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v59MtSHg080364; Fri, 9 Jun 2017 15:55:28 -0700 (PDT) (envelope-from david) Date: Fri, 9 Jun 2017 15:55:28 -0700 From: David Wolfskill To: Konstantin Belousov , current@freebsd.org, glebius@freebsd.org Subject: Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305" Message-ID: <20170609225528.GD1180@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org, glebius@freebsd.org References: <20170609125715.GP1180@albert.catwhisker.org> <20170609135517.GA2088@kib.kiev.ua> <20170609152355.GZ1180@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tyhzcnTYDIcSS9Td" Content-Disposition: inline In-Reply-To: <20170609152355.GZ1180@albert.catwhisker.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 22:55:32 -0000 --tyhzcnTYDIcSS9Td Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 09, 2017 at 08:23:55AM -0700, David Wolfskill wrote: > ... > > The main suspect is r319722. > > Try reverting it or downgrading before it (the later might be simple due > > to the patch size). > > .... >=20 > It was easy enough for me to use "svn diff -c r319722" & > "svn patch --reverse-diff" to effectively revert r319722. >=20 > I re-ran the build after that, and a subsequent reboot allowed me to > "sudo service hald onestart" (which whined a bit about dbus not being > enabled but started it anyway), after which I was able to start xdm -- > so that seems to have been successful. >=20 > Perhaps I'll chat with Gleb a bit later today. :-) (Our cubes are > adjacent.) > ... Gleb committed r319754; I finally(!) had a chance to revert the reversion of r319722, then apply r319754 and rebuild; the follow-up smoke test was successful. > Thanks, Konstantin! :-) > ... And Gleb! :-) [Apparently hald invokes stat(2) on a listening socket, which was ... unexpected.] Peace, david --=20 David H. Wolfskill david@catwhisker.org Looking forward to telling Mr. Trump: "You're fired!" See http://www.catwhisker.org/~david/publickey.gpg for my public key. --tyhzcnTYDIcSS9Td Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZOydgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4Xj8YH/32Wy48Swy+A3wKCNXfTKuHp TnC4bCNgjAYZumgdsrx69jIKOO4Zj0C7Xf2gMC28XjdHOKyhG8/k4hLDEXGCFX9f 5KcHJvcC9w/UIJLjA+hGP3/5zexrt2fAZFW1iyCy8cgAXDZysiA8W63LYDb752dU 7ccEoec3n8iRXrMWJF3ha2TPX8DDhXtdvxJ1LQXkRt5QDXl/g8mwzXRVyPaJgvBi 1UfFS8LFpUnCqwBoExPliOXSWhIj6Fydu9U7EDeLrsiJADfPlJ4+/l4ceUb79lZ7 x2pQS4H6HAo6Wx8s0R/pLsA+aCuEKKcg4obZKCHSmbdkaDD/cuodFBIKo+5Cv8o= =hqtO -----END PGP SIGNATURE----- --tyhzcnTYDIcSS9Td-- From owner-freebsd-current@freebsd.org Fri Jun 9 23:08:52 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60A97BFEF86 for ; Fri, 9 Jun 2017 23:08:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCD57F5FD for ; Fri, 9 Jun 2017 23:08:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 38A05BFEF85; Fri, 9 Jun 2017 23:08:52 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38384BFEF84 for ; Fri, 9 Jun 2017 23:08:52 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 E6B807F5FC; Fri, 9 Jun 2017 23:08:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id w1so91616053qtg.2; Fri, 09 Jun 2017 16:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4XMzMpJ2mJ4c1mnwyt/E5U+zFnglCybJyw7HZ0vApbM=; b=at7FkwuzhuVKQY6uW/uiZcOXSMnh1FimtELC4NhhZkWb2CUZUUppdfjLymg7a9NW+8 qIzpfdrBi3AFLQRi+PqHYGjsKVMYBhg9COvu+/k2Z8roZeBFpz8gd7DZW4oFgBA3Zvhf aqG6OtOLoyQJ9av51m1lYWiqmAOBKUQrj+cvmyzF062Knp2SA2I7iBeOlYHN6Zt90z1W 5HVqf9BZvVDh8WhYRJmJoMs7UPW89oV4/kvdWzpKDnbRgUdnSs1dTi//gOvJvGTCL6m6 mXOpWSZLgYKlAlFpTEBYc4giiiYMdWoGQX45wR8gVwyhbRTQG/ESaTr1upBwnuEKxPrw F1Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4XMzMpJ2mJ4c1mnwyt/E5U+zFnglCybJyw7HZ0vApbM=; b=Nnr9FJRd8sKsmpjZb3HpkJFpNy1T39g44J6431/3yH/NvoZI30JePxXixNwjI/Wm1F Q5tB+ihEDc+bLX7cgpbNq3+70v5P8wVw41KgO3iE/5PDMmj/4RV2AMHVJaNEx59z9Nh5 jW4Q1kJ1MtxMJ/asyQgWeJuPMdqiCNfcqLgnqqtgDjYra+WmDRhFXWEaY9tN+4MzPWZx qjn6BdP63wIFXkQem8pe7fl60b8yzQfHbbG/qMgIiiTw1RwpdinahHHk5TS0TEcgNHji sh6ewq3W7RgxOck/90bbRc047ApFEkATVPeSiaW19JBKFW7ICdgn0jFjXOucXKHN1bEs 9CMQ== X-Gm-Message-State: AODbwcAuBMS0CE084LTEfETEJMp4iIMmaP/omOYlMwc9I6RFgXjwXAka L3VprTdWMwYKRcy6J2kRUf9CbpS3cQ== X-Received: by 10.200.49.81 with SMTP id h17mr46192915qtb.13.1497049731164; Fri, 09 Jun 2017 16:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.92.214 with HTTP; Fri, 9 Jun 2017 16:08:50 -0700 (PDT) In-Reply-To: <20170609225528.GD1180@albert.catwhisker.org> References: <20170609125715.GP1180@albert.catwhisker.org> <20170609135517.GA2088@kib.kiev.ua> <20170609152355.GZ1180@albert.catwhisker.org> <20170609225528.GD1180@albert.catwhisker.org> From: Ngie Cooper Date: Fri, 9 Jun 2017 16:08:50 -0700 Message-ID: Subject: Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305" To: David Wolfskill , Konstantin Belousov , FreeBSD Current , Gleb Smirnoff Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Jun 2017 23:08:52 -0000 On Fri, Jun 9, 2017 at 3:55 PM, David Wolfskill wrote: ... > Gleb committed r319754; I finally(!) had a chance to revert the > reversion of r319722, then apply r319754 and rebuild; the follow-up > smoke test was successful. ... > [Apparently hald invokes stat(2) on a listening socket, which was ... > unexpected.] This might have been caught by lib/libc/sys/stat_test:stat_socket . If only the compat stuff was working on ci.freebsd.org as well, or the test(s) had been run... -Ngie From owner-freebsd-current@freebsd.org Sat Jun 10 07:14:14 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54BB2D86D8B for ; Sat, 10 Jun 2017 07:14:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 086536ACC9 for ; Sat, 10 Jun 2017 07:14:13 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from fortune.joker.local (124-18-21-125.dz.commufa.jp [124.18.21.125]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id v5A7EBSj052100; Sat, 10 Jun 2017 16:14:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 10 Jun 2017 16:14:10 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Cc: Rick Macklem , Konstantin Belousov Subject: Re: Time to increase MAXPHYS? Message-Id: <20170610161410.b5c158aefede850ec3b42f41@dec.sakura.ne.jp> In-Reply-To: References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> <972dbd34-b5b3-c363-721e-c6e48806e2cd@elischer.org> <3719c729-9434-3121-cf52-393a4453d0b2@freebsd.org> <20170604081032.GN82323@kib.kiev.ua> Organization: Junchoon corps X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 10 Jun 2017 07:14:14 -0000 It's what I proposed first. ;-) But looking through this thread, I now like Konstantin's idea, in conjunction with quirks mechanism. With single MAXPHYS all over the OS, many non-latest hardwares could be fallen out if it's set larger, but the larger the MAXPHYS is, the better the virtual instances (AWS, Azure, ...) runs. It seems that there should be flexible way to make MAXPHYS "per consumer" (devices, drivers, virtual instances, ...), and Konstantin's idea looks good to me. (Although there would be some risk of memory leak problem.) One more possibility. Abusing quirks to allow larger MAXPHYS only if possible, and keep current default. This way, only something requires larger value would be affected, IMHO. *I guess quirks should only be uesd for problematic things, though. On Sun, 4 Jun 2017 12:40:55 +0000 Rick Macklem wrote: > There is an array in aio.h sized on MAXPHYS as well. > > A simpler possibility might be to leave MAXPHYS as a compile > time setting, but allow it to be set "per arch" and make it bigger > for amd64. > > Good luck with it, rick > ________________________________________ > From: owner-freebsd-current@freebsd.org on behalf of Konstantin Belousov > Sent: Sunday, June 4, 2017 4:10:32 AM > To: Warner Losh > Cc: Allan Jude; FreeBSD Current > Subject: Re: Time to increase MAXPHYS? > > On Sat, Jun 03, 2017 at 11:28:23PM -0600, Warner Losh wrote: > > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > > > > > On 2017-06-03 22:35, Julian Elischer wrote: > > > > On 4/6/17 4:59 am, Colin Percival wrote: > > > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > > > >> wrote: > > > >>> Add better support for larger I/O clusters, including larger physical > > > >>> I/O. The support is not mature yet, and some of the underlying > > > >>> implementation > > > >>> needs help. However, support does exist for IDE devices now. > > > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > > > >> again, > > > >> or do we need to wait at least two decades between changes? > > > >> > > > >> This is hurting performance on some systems; in particular, EC2 "io1" > > > >> disks > > > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > > > >> spinning rust) > > > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > > > >> recommends > > > >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > > > >> I/O it > > > >> seems to still be limited by MAXPHYS). > > > >> > > > > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > > > > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > > > > transfer size */ > > > > > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > > freebsd.org" > > > > > > At some point Warner and I discussed how hard it might be to make this a > > > boot time tunable, so that big amd64 machines can have a larger value > > > without causing problems for smaller machines. > > > > > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > > > of the benefit. > > > > > > I am preparing some benchmarks and other data along with a patch to > > > increase the maximum size of pipe I/O's as well, because using 1MB > > > offers a relatively large performance gain there as well. > > > > > > > It doesn't look to be hard to change this, though struct buf depends on > > MAXPHYS: > > struct vm_page *b_pages[btoc(MAXPHYS)]; > > and b_pages isn't the last item in the list, so changing MAXPHYS at boot > > time would cause an ABI change. IMHO, we should move it to the last element > > so that wouldn't happen. IIRC all buf allocations are from a fixed pool. > > We'd have to audit anybody that creates one on the stack knowing it will be > > persisted. Given how things work, I don't think this is possible, so we may > > be safe. Thankfully, struct bio doesn't seem to be affected. > > > > As for making it boot-time configurable, it shouldn't be too horrible with > > the above change. We should have enough of the tunables mechanism up early > > enough to pull this in before we create the buf pool. > > > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > > sure, especially on memory limited systems. Lots of hardware can't do this > > big an I/O, and some drivers can't cope, even if the underlying hardware > > can. Since we don't use such drivers at work, I don't have a list handy > > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > > reasonable bump by default, but I think going larger by default should be > > approached with some caution given the overhead that adds to struct buf. > > Having it be a run-time tunable would be great. > The most important side-effect of bumping MAXPHYS as high as you did, > which is somewhat counter-intuitive and also probably does not matter > for typical Netflix cache box load (as I understand it) is increase of > fragmentation for UFS volumes. > > MAXPHYS limits the max cluster size, and larger the cluster we trying to > build, larger is the probability of failure. We might end with single-block > writes more often, defeating reallocblk defragmenter. This might be > somewhat theoretical, and probably can be mitigated in the clustering code > if real, but it is a thing to look at. > > WRT making the MAXPHYS tunable, I do not like the proposal of converting > b_pages[] into the flexible array. I think that making b_pages a pointer > to off-structure page run is better. One of the reason is that buf cache > buffers are not only buffers in the system. There are several cases where > the buffers are malloced, like markers for iterating queues. In this case, > b_pages[] can be eliminated at all. (I believe I changed all local > struct bufs to be allocated with malloc). > > Another non-struct buf supply of buffers are phys buffers pool, see > vm/vm_pager.c. > > > > > There's a number of places in userland that depend on MAXPHYS, which is > > unfortunate since they assume a fixed value and don't pick it up from the > > kernel or kernel config. Thankfully, there are only a limited number of > > these. > > > > Of course, there's times when I/Os can return much more than this. Reading > > drive log pages, for example, can generate tens or hundreds of MB of data, > > and there's no way to do that with one transaction today. If drive makers > > were perfect, we could use the generally defined offset and length fields > > to read them out piecemeal. If the log is table, a big if for some of the > > snapshots of internal state logs that are sometimes necessary to > > investigate problems... It sure would be nice if there were a way to have > > super-huge I/O on an exception basis for these situations. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sat Jun 10 10:10:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92112D8A1D3 for ; Sat, 10 Jun 2017 10:10:00 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49A4572E6D; Sat, 10 Jun 2017 10:09:59 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id E01A91248E; Sat, 10 Jun 2017 13:09:50 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id hafXHG_LZh7Y; Sat, 10 Jun 2017 13:09:42 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 2C94A12488; Sat, 10 Jun 2017 13:09:42 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id B41B3574B10; Sat, 10 Jun 2017 13:09:38 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id wALh23O1qpmw; Sat, 10 Jun 2017 13:09:31 +0300 (MSK) Received: from [192.168.0.30] (gateway [10.0.2.2]) by mail.cicgroup.ru (Postfix) with ESMTPA id 79A27574A91; Sat, 10 Jun 2017 13:09:31 +0300 (MSK) Subject: Re: CFT: EVDEV support in psm(4) driver To: Jonathan Anderson , freebsd-current@freebsd.org References: <5fa9225de944d6cdac0b7e5749b452a9@kondratyev.su> <03831fcc-5744-21da-0756-d28bf256c203@FreeBSD.org> From: Vladimir Kondratyev Message-ID: Date: Sat, 10 Jun 2017 13:07:49 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <03831fcc-5744-21da-0756-d28bf256c203@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 10 Jun 2017 10:10:00 -0000 On 09.06.2017 15:57, Jonathan Anderson wrote: > Hi Vladimir, > > Thanks very much... I've been using your patch for awhile with my > Synaptics touchpad and it's lovely to have two-finger scrolling that > works properly! I did need to massage the patch to make it apply on > drm-next: > https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5 > > The patch is commited to CURRENT already so you don`t need apply extra patches anymore. Part of initial patch that I can find under your link has not been committed as it can trigger deadlock on KDB entering. > Sometimes I experience dropped touchpad events, particularly when the > system is busy and my wi-fi is being reconfigured. Is there anything I > can do to help debug this? Are you observing SYN_DROPPED events in evemu-record output? If so run it under "nice -n -20" If SYN_DROPPED still persists, add debug.psm.loglevel=5 to /boot/loader.conf, reboot and send me content of /var/log/messages. Only "dropped touch" part of log is needed. Event dropping occurs when kernel writes events faster than user can read, so usually it is a user-land problem.