From owner-freebsd-hackers@freebsd.org Sun Apr 8 08:14:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C636F8D5D0 for ; Sun, 8 Apr 2018 08:14:17 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EC17823AF for ; Sun, 8 Apr 2018 08:14:16 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-10) with ESMTPSA id w388E3D4029560 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 8 Apr 2018 10:14:03 +0200 Subject: Re: [diskless] pkg takes 100% of a CPU To: freebsd-hackers@freebsd.org References: <201804071708.w37H8Ts8009359@pdx.rh.CN85.dnsmgr.net> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= xsFNBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABzSpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj7CwZQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2c7BTQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAcLBfAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: <36a0a944-c276-5e3e-0490-ce8e8c5ab1ac@systella.fr> Date: Sun, 8 Apr 2018 10:14:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: <201804071708.w37H8Ts8009359@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0-beta at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 08:14:17 -0000 Rodney W. Grimes a écrit : >> On Sat, 2018-04-07 at 07:35 -0700, Rodney W. Grimes wrote: >>>> >>>> On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: >>>>> >>>>> Steven Hartland a crit: >>>>>> >>>>>> >>>>>> When we?ve seen it using 100% it?s been doing comprehension stuff which >>>>>> usually finishes you just have to wait. Not sure if that?s what you?re >>>>>> seeing? >>>>> Yesterday, I have killed pkg after more than 100 hours of CPU time... >>>>> >>>>> Best regards, >>>>> >>>>> JB >>>> For me, pkg(8) quit working on systems that have /var/db mounted from >>>> nfs long ago, maybe as much as a year ago at this point. I mentioned >>>> it on irc, and was told "It's probably something to do with locking", >>>> but I already have boot.nfsroot.options="nolockd" in loader.conf >>>> (because that's pretty much the only option because the rc(8) system >>>> was broken years ago when it comes to nfsroot). >>> My understanding of the current broken state of afairs is that pkg >>> does not work over nfs unless you have proper and full lockd support, >>> AND set NFS_WITH_PROPER_LOCKING in pkg's environment.??This really >>> really really just needs to work without a lot of fuss out of the >>> box. >>> >> >> nfs locking support is compiled into the kernel on both the server and >> client side, and rpc.lockd is running on both, but there is no need for >> actual locking on the mount because the rootfs isn't accessed by >> multiple clients at once -- each of my arm boards has its own private >> rootfs exported from the server. I'm pretty sure I tried remounting >> root > > pkg wants to do locking, multiple copies of pkg may be running on one > client, you might get pkg to work for you if you do the > > echo "NFS_WITH_PROPER_LOCKING = true;" >> /usr/local/etc/pkg.conf Of course, I have set this line in /usr/local/etc/pkg.conf. I cannot attach pkg to gdb : root@pythagore:~ # gdb -p 75520 GNU gdb 6.1.1 [FreeBSD] ......... This GDB was configured as "amd64-marcel-freebsd". Attaching to process 75520 /usr/src/contrib/gdb/gdb/solib-svr4.c:1444: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. pkg seems to be called by /usr/local/sbin/pkgcheck-qsa I have killed pkg with -SEGV but I'm unable to find core file. Best regards, JB From owner-freebsd-hackers@freebsd.org Sun Apr 8 08:31:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93EBAF8E8CA for ; Sun, 8 Apr 2018 08:31:15 +0000 (UTC) (envelope-from bogorodskiy@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 1FE6A6BB15 for ; Sun, 8 Apr 2018 08:31:15 +0000 (UTC) (envelope-from bogorodskiy@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id u189so11182224wmd.1 for ; Sun, 08 Apr 2018 01:31:15 -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:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SZp0NBxYvvXnQmYNUeTjLtpumv8Ec9qy+0+Fgebooas=; b=BLBb6wD9VJ2snPIIqW/uxIkz4XxGVbAoeGWE9xuMIDhKU4f87VjMG6D8tHNXCzlyvU 8vKJQbB4/OeEvQLoFH7xqny1tHBxFKgk482Hjuo26SXCbhrJuumS0Q5awULEd0F8pPCC GVsNB+mDF9Rs7tXMg7KLvzbskRuq3ybCPLtNB91L5HbzXPG/Bf1t7zfwpDybxiTGnYeV +GOkKcRQtSExfiJ4dlYhb9VpIw7BujDBb0aLNOaZuh5U2Yv6x+D+vueda0r9jaU0Fc4m FLKL7rvym0B0W2WM7E2OQMziHgaLGaW6kLZvgfxU0neUKnAaFtGjvUzHoqXCpF5/4QIq Wh1A== 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 :references:mime-version:content-disposition:in-reply-to:user-agent; bh=SZp0NBxYvvXnQmYNUeTjLtpumv8Ec9qy+0+Fgebooas=; b=l2tDbAk11k0XcjJ9/cqMobTLKK1NNRATjMgTZ62haJHgl4kZAHrUizAzdlAwpg2m7n Qn5zgP4IHD2tRXAWLOHLFD1rg2S1KFLcO0PRjgKx8gEVNDpPMjCOIKrKxx96gY0juQyQ 6i8HYY3qs9+SXDtikmoGCgCeQlPf/E0GpU/hjMX/3xlbhifaONLrArDvR1tuSv0SWl6o ysDxAEAYA8YxELbhKGVonrIeZQNugIbQR7AU6aHC8SHTZksk4kbZMbe1Z8uph6OzVTtq 9Pxx4ww0GmNudTpCy26OfSZeZcp228q92QgupcfooMjrridMum5h7SprUXRr9ymckhsN HCeg== X-Gm-Message-State: ALQs6tAfl8XNhs2IdQp07KmyZvyIQ+SpXGa7z8NQMZpBF1WV4GpOE4Wo 6UOqy1cTUIPiuG5C5iU4O7X4MQ== X-Google-Smtp-Source: AIpwx49HkiLWVxmkRh49Kc+w85DiK0+mvnBKRwTIVcwwf2wDSfatvdbdJCVaXQydV0T1kGwsgsIldg== X-Received: by 10.46.18.150 with SMTP id 22mr19911952ljs.120.1523176273391; Sun, 08 Apr 2018 01:31:13 -0700 (PDT) Received: from kloomba ([217.65.211.123]) by smtp.gmail.com with ESMTPSA id s1sm2402076lji.92.2018.04.08.01.31.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Apr 2018 01:31:12 -0700 (PDT) Sender: Roman Bogorodskiy Date: Sun, 8 Apr 2018 12:31:05 +0400 From: Roman Bogorodskiy To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Subject: Re: Getting /dev entry by interface name Message-ID: <20180408083104.GA1780@kloomba> References: <20180407025807.GA18883@kloomba> <37078.1523089049@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <37078.1523089049@critter.freebsd.dk> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 08:31:15 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Poul-Henning Kamp wrote: > -------- > In message <20180407025807.GA18883@kloomba>, Roman Bogorodskiy writes: >=20 > >1. Create tap(4) like that: > > > ># ifconfig tap create > >tap2 > ># > > > >2. Rename it > > > ># ifconfig tap2 name testif > >testif > > > >Now I can do 'ifconfig testif' and there'll be no signs that it was > >named 'tap2' previously, however, in /dev it's still /dev/tap2. >=20 > I would argue that is an error. >=20 > The /dev entry should also be renamed, or maybe better, a symlink > with the new name should be created, pointing to the /dev/tap%d > entry. >=20 > However, I dont know if that is actually possible, is the device > driver even even told about the new interface name ? >=20 > There is also a name-space validation issue to think about: >=20 > ifconfig tap2 name ../etc I'm not sure if that's possible (or a reasonable thing to do) either. Not only stuff like '../etc' needs to be validated as you mentioned, but also we need to make sure not to clash with other devices. For example, now it's possible to rename tap device to 'null' which will not be possible if we create a symlink. Back to the original question, julian@ suggested to take a look at sysctl, and there's indeed one that reports this information. There's even some sample code in tools/ available: https://svnweb.freebsd.org/base/head/tools/tools/ifinfo/ifinfo.c?view=3Dmar= kup#l123 This sysctl is not easy to find unless you know what you're looking for. Roman Bogorodskiy --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaydNIAAoJEMltX/4IwiJqtF4H/1m5XUPWap+Ua3og6ofN2Mv2 aoUOBYvJT35KxGmjJ/E5tPtNJ4SIJstyRkZII+xQsrptOswhuFjZmTpRsgDWhhz0 eRw8BDOQGtXtc+XGbcdcS/KScnIJdxb7TN7GE3lX9RXwfpVepqQyEzuSpNBsrIpi uds9nhO6+6QtUSRS10xvH+zpJmE+tZspWHYFH4oMmXG3yi+1UGW6sGtUC5znASu2 OqjfC2JcM4DxZy2N5gKTfTSJw+uh9K2GD1gmsUdN1lfU3UMFot5L8iYcoY5pij+x bvQCmbEECJAT8XvwPi9sLvR79rIslTJZbWoZGUJW2FcEFEsKDXTAmfqQrHLUvq4= =X2y9 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-hackers@freebsd.org Sun Apr 8 11:03:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06A55F996BC for ; Sun, 8 Apr 2018 11:03:20 +0000 (UTC) (envelope-from emorrasg@yahoo.es) Received: from sonic306-19.consmr.mail.ir2.yahoo.com (sonic306-19.consmr.mail.ir2.yahoo.com [77.238.176.205]) (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 7C9F3765E3 for ; Sun, 8 Apr 2018 11:03:19 +0000 (UTC) (envelope-from emorrasg@yahoo.es) X-YMail-OSG: MFq1SZMVM1lGjcdYqLvHbnPZDvKBZlnxdgHha0SrVmaY56hLdRFTGWUC4.imEGQ T0ENAICPk1vTsdbZeMLGBP8NBCy2aC_7URxiqKcbRERbJHAWFG_6xntuTe4xQlfp3Xb.ZeSbzI0n hF.YUwA3tKgg2Jfkfo2W81WNhvXuhP9_YIFNsE_Wk2oYyRfLVHd4HSnJ1urElRZgcBkUexoKte5r g7Yp1lai1DkHiCLoFJfWr9u6z5B.qSUIMPOFlutGhhJCBwY6KLpp2ps9ZJOXk4oe8yL7hluOhqd5 rEfYDT0Pa_5X760mhQCP8Pzkkwkvi6GBq24YoUQgC61I7BLYO8OAMrABMYxoiiIGk_f9GT9MjbTV PEixPxhRYyKEYZNaHKnWqCPoQT2jHUTAV7ZS3g09nRFuB02G5QNuGuR5SjLxfLa7KSralIMWy1jK MZR2YP_wMmVtN0JjdqMrpXc8YoF1WxDH7G2TYFIhXwedsiViAVxUFYjMWyaI6woIwMME_RcBMMJ7 EFLEzXnoU7fyeYRrViHk8_0o- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Sun, 8 Apr 2018 11:03:11 +0000 Received: from 83.173.188.224.dyn.user.ono.com (EHLO emorras.eu) ([83.173.188.224]) by smtp409.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ee21935dbdb8ad545c80c9bffa84d529 for ; Sun, 08 Apr 2018 11:03:10 +0000 (UTC) Date: Sun, 8 Apr 2018 13:11:04 +0200 From: Eduardo Morras To: freebsd-hackers@freebsd.org Subject: Re: [diskless] pkg takes 100% of a CPU Message-Id: <20180408131104.117b849278667b57ca51b223@yahoo.es> In-Reply-To: <1523110791.40504.15.camel@freebsd.org> References: <1523110791.40504.15.camel@freebsd.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 11:03:20 -0000 On Sat, 07 Apr 2018 08:19:51 -0600 Ian Lepore wrote: > On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: > > Steven Hartland a crit: > > >=20 > > > When we?ve seen it using 100% it?s been doing comprehension stuff > > > which usually finishes you just have to wait. Not sure if that?s > > > what you?re seeing? > > Yesterday, I have killed pkg after more than 100 hours of > > CPU time... > >=20 > > Best regards, > >=20 > > JB >=20 > For me, pkg(8) quit working on systems that have /var/db mounted from > nfs long ago, maybe as much as a year ago at this point. I mentioned > it on irc, and was told "It's probably something to do with locking", > but I already have boot.nfsroot.options=3D"nolockd" in loader.conf > (because that's pretty much the only option because the rc(8) system > was broken years ago when it comes to nfsroot). Is the db is on netbsd side? If yes, sqlite db over nfs are pita because nfs lies about file locking. It's true that it works 99% of time, the problematic part is the 1%. Documentation talks about incorrect NFS implementation, but a correct implementation can fail too because network latency, separate memory data between clients and server or different filesystem semantics; or all of them. https://www.sqlite.org/faq.html#q5 https://stackoverflow.com/questions/9907429/locking-sqlite-file-on-nfs-file= system-possible#9962003 >=20 > -- Ian --- --- Eduardo Morras From owner-freebsd-hackers@freebsd.org Sun Apr 8 11:42:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECA74F9C5B3 for ; Sun, 8 Apr 2018 11:42:47 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F6CA6C2DE for ; Sun, 8 Apr 2018 11:42:47 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-10) with ESMTPSA id w38BgZpg000788 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 8 Apr 2018 13:42:35 +0200 Subject: Re: [diskless] pkg takes 100% of a CPU To: freebsd-hackers@freebsd.org References: <1523110791.40504.15.camel@freebsd.org> <20180408131104.117b849278667b57ca51b223@yahoo.es> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= xsFNBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABzSpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj7CwZQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2c7BTQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAcLBfAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: <72ccb066-5238-da87-cb22-642c1995caef@systella.fr> Date: Sun, 8 Apr 2018 13:42:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: <20180408131104.117b849278667b57ca51b223@yahoo.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0-beta at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 11:42:48 -0000 Eduardo Morras via freebsd-hackers a écrit : > On Sat, 07 Apr 2018 08:19:51 -0600 > Ian Lepore wrote: > >> On Sat, 2018-04-07 at 11:50 +0200, BERTRAND Jol wrote: >>> Steven Hartland a crit: >>>> >>>> When we?ve seen it using 100% it?s been doing comprehension stuff >>>> which usually finishes you just have to wait. Not sure if that?s >>>> what you?re seeing? >>> Yesterday, I have killed pkg after more than 100 hours of >>> CPU time... >>> >>> Best regards, >>> >>> JB >> >> For me, pkg(8) quit working on systems that have /var/db mounted from >> nfs long ago, maybe as much as a year ago at this point. I mentioned >> it on irc, and was told "It's probably something to do with locking", >> but I already have boot.nfsroot.options="nolockd" in loader.conf >> (because that's pretty much the only option because the rc(8) system >> was broken years ago when it comes to nfsroot). > > Is the db is on netbsd side? If yes, sqlite db over nfs are pita > because nfs lies about file locking. It's true that it works 99% of > time, the problematic part is the 1%. Documentation talks about > incorrect NFS implementation, but a correct implementation can fail too > because network latency, separate memory data between clients and > server or different filesystem semantics; or all of them. All filesystems are mounted from NetBSD server : root@pythagore:/var # mount 192.168.10.128:/srv/pythagore on / (nfs, asynchronous) devfs on /dev (devfs, local, multilabel) procfs on /proc (procfs, local) fdescfs on /dev/fd (fdescfs) 192.168.10.128:/home on /home (nfs, asynchronous) root@pythagore:/var # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# 192.168.10.128:/srv/pythagore / nfs nfsv3,tcp,soft,intr,rw,async,nolockd 0 0 proc /proc procfs rw 0 0 fdesc /dev/fd fdescfs rw 0 0 192.168.10.128:/home /home nfs nfsv3,tcp,soft,intr,rw,async 0 0 On server, /var/log/messages are full of : Apr 8 13:40:49 legendre rpc.lockd: duplicate lock from hilbert.45141 Apr 8 13:40:49 legendre rpc.lockd: no matching entry for hilbert Apr 8 13:40:52 legendre rpc.lockd: duplicate lock from pythagore.68734 Apr 8 13:40:52 legendre rpc.lockd: duplicate lock from pythagore.68734 Apr 8 13:40:52 legendre rpc.lockd: no matching entry for pythagore Apr 8 13:40:52 legendre rpc.lockd: no matching entry for pythagore Apr 8 13:40:55 legendre rpc.lockd: duplicate lock from pythagore.68734 even if all filesystems are mounted with nolockd option. JB From owner-freebsd-hackers@freebsd.org Sun Apr 8 14:24:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 793BDF855A1 for ; Sun, 8 Apr 2018 14:24:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660054.outbound.protection.outlook.com [40.107.66.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B51585409 for ; Sun, 8 Apr 2018 14:24:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM (52.132.66.153) by YQBPR0101MB1795.CANPRD01.PROD.OUTLOOK.COM (52.132.70.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Sun, 8 Apr 2018 14:24:40 +0000 Received: from YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM ([fe80::185:356:49c5:794c]) by YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM ([fe80::185:356:49c5:794c%13]) with mapi id 15.20.0653.015; Sun, 8 Apr 2018 14:24:40 +0000 From: Rick Macklem To: =?iso-8859-1?Q?BERTRAND_Jo=EBl?= , "freebsd-hackers@freebsd.org" Subject: Re: [diskless] pkg takes 100% of a CPU Thread-Topic: [diskless] pkg takes 100% of a CPU Thread-Index: AQHTzylf/CocNYsxTUC9psbAPHXpaaP2vwsAgAAp4sg= Date: Sun, 8 Apr 2018 14:24:40 +0000 Message-ID: References: <1523110791.40504.15.camel@freebsd.org> <20180408131104.117b849278667b57ca51b223@yahoo.es>, <72ccb066-5238-da87-cb22-642c1995caef@systella.fr> In-Reply-To: <72ccb066-5238-da87-cb22-642c1995caef@systella.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR0101MB1795; 7:AysjJKrU1d5/mtLqjgu3aCEe5nKz7vWKy+rQw82BOrAMe3u/IPTdqfzKe7SuOxO0736zCNONJLQLQqGCuJG6ZyiOLjY9u6Ie57t+HchgBA3rWK8/HmwuWL2329c83fwEsaRsxg3DJWf4+N4PyWc0r1TyoaAgBlSSO8LGs9XhuX9xVye44ebh4ToRre2Q9pLHQ/0Gml5UBMF1BH2JfFoiZduZS2G3X/rdNJKislGciX5RJSdH1KHPadviCs0xhNmI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d07f60ba-357a-4165-49ff-08d59d5c76fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:YQBPR0101MB1795; x-ms-traffictypediagnostic: YQBPR0101MB1795: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:YQBPR0101MB1795; BCL:0; PCL:0; RULEID:; SRVR:YQBPR0101MB1795; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39840400004)(366004)(346002)(39380400002)(376002)(189003)(199004)(68736007)(33656002)(25786009)(6246003)(8936002)(229853002)(53936002)(478600001)(55016002)(3660700001)(3280700002)(2906002)(11346002)(476003)(2900100001)(446003)(81156014)(8676002)(486006)(81166006)(786003)(93886005)(99286004)(105586002)(5250100002)(86362001)(186003)(76176011)(5660300001)(102836004)(6506007)(74482002)(59450400001)(316002)(110136005)(26005)(106356001)(74316002)(97736004)(9686003)(6436002)(2501003)(7696005)(14454004)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB1795; H:YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: UdLRRbmUY8jBToOkas3rxIi2ptBxSlofI1YLSxmSazHj7UcMUEXM8kZld280jV1DTuTRD7xg2Ovk+gcdX4nxDB6qdnHwQh6nOkD85ta+afZ4e37TbpgJByEWAd9VYM/9E5/UIRIQIJbWRWC1Jdcf3ujrY+7+KygxHPg9MADrJu/SLG/wlRJ4fwrGs62i2q5Zb7CZL+Y2hUtcr8wMTir8PvpO3A6EJcFvf012WiRd3zswUyG9ASIS2ylBSJ1rKO+boh62c0WTe2K2hkKfffamYbDjRlZ3BbUlq4VdAk8kW/4MvB3a7ouYQNGdpmt6AhBqLZoj4lDHq1f9SrqR4IvKIUidNVCGVvcASeDVZqaABdeWI5DchaVCtOdcQHv3nKkafR5IfA3Kl/J8VYCkeYCKt0BZH1YfOfOqnzhsrJhDY9E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: d07f60ba-357a-4165-49ff-08d59d5c76fc X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2018 14:24:40.0809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1795 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 14:24:42 -0000 BERTRAND Jo=EBl wrote: [stuff snipped] > All filesystems are mounted from NetBSD server : > >root@pythagore:/var # mount >192.168.10.128:/srv/pythagore on / (nfs, asynchronous) >devfs on /dev (devfs, local, multilabel) >procfs on /proc (procfs, local) >fdescfs on /dev/fd (fdescfs) >192.168.10.128:/home on /home (nfs, asynchronous) Just fyi, "nfsstat -m" on the client will show you what NFS mount options are actually in use. >root@pythagore:/var # cat /etc/fstab ># Device Mountpoint FStype Options Dump Pass# >192.168.10.128:/srv/pythagore / nfs nfsv3,tcp,soft,intr,rw,async,nolockd I'd suggest you try without the "soft,intr" options. When those are set, a system call like write(2) can return with EINTR and very few (if any) applications handle that correctly. [more stuff snipped] > On server, /var/log/messages are full of : >Apr 8 13:40:49 legendre rpc.lockd: duplicate lock from hilbert.45141 >Apr 8 13:40:49 legendre rpc.lockd: no matching entry for hilbert >Apr 8 13:40:52 legendre rpc.lockd: duplicate lock from pythagore.68734 >Apr 8 13:40:52 legendre rpc.lockd: duplicate lock from pythagore.68734 >Apr 8 13:40:52 legendre rpc.lockd: no matching entry for pythagore >Apr 8 13:40:52 legendre rpc.lockd: no matching entry for pythagore >Apr 8 13:40:55 legendre rpc.lockd: duplicate lock from pythagore.68734 > >even if all filesystems are mounted with nolockd option. If you use "nolockd" on all mounts, you do not need to run rpc.lockd or rpc.statd, which is what I prefer. (The NLM and NSM protocols were undocume= nted and fundamentally broken. Eventually they were published in an X/Open XNFS manual, but it was a vague 2 page summary. The only real doc would be the OpenSolaris implementation. NFSv4 does a much better job of locking, so if = you need the locks to be visible to other clients, that is what I'd suggest= . rick= From owner-freebsd-hackers@freebsd.org Sun Apr 8 16:49:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 677FBF8FB3C for ; Sun, 8 Apr 2018 16:49:46 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 EA59B768F4 for ; Sun, 8 Apr 2018 16:49:45 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: u_Ux55QVM1k4XIc7bIAbet2wS8WhBYeQq1NlNCkjUfQ9dWprhhpwLbH4cuFJozg 7kV9AMEjQC7LniK8U2KIPs5gaI1Dafmdl.SbI8bbjj5n8ZR82tFqvcIHG1lt2dONdwNjpFUkHFgP SF7QgiUpk2JjT4Jh8C1SU1MMz.wrenDoIMTh5ke8PBrFfrzHxx8rQ.R1EQU1btpqeKMc05vRbGax O3tRirwCdJlOgsU8ng.4WooHwNNqVjZZascZug1Tx_Ra0jlaAZk5Z95SRjWtb36SVxV4doz7PBVv zCMnDFUNfmOi34O2KOJQGvqeObKw0tGaloxviCDil9uWFBuStt92zxGUboGzvTC1EzCX1aAJCRv4 Z1hkY76p9Cln5iNNoW0RY4NZtT_n_ZopGTggcNgkGEzCuLtgBmV8pAFyjM5Qipp.o5shTAnrlIbA LPM.y8uv9hekIvw1dnUMqG0keoU.fuy0fn7XK2GOkNoi8w2bPGkldqak0dDILKaqF45CUEAhNQla sUO8BLwY7gqIW7a6tAVSdvGeQrfAKmXml5N36 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 8 Apr 2018 16:49:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d9f02034e3b178c021c97b2e13312602; Sun, 08 Apr 2018 16:29:26 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Ryzen Threadripper, Hyper-V, and NUMA vs. DIMMs: 3 DIMMs on each side seems to always be in "Local" mode, not "Distributed" Message-Id: Date: Sun, 8 Apr 2018 09:29:25 -0700 To: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 16:49:46 -0000 Context: Ryzen Threadripper 1950X under Windows 10 Pro with Hyper-V (used to run FreeBSD). In experimenting with switching a Threadripper 1950X to have ECC RAM I discovered: A) The maximum ECC memory it would put to use was 96 GiBytes (3 DIMMs on each side, a 4th on each side was recognized but was ignored/disabled if present). B) AMD Ryzen Master classified the 96 GiByte configurations (with or without the ignored DIMMs) as "Local" without an ability switch to "Distributed". C) The downloaded Windows CoreInfo.exe utility agreed on there being 2 NUMA nodes. D) As did the result of the User Hardware Topology button in the Hyper-V Processor > NUMA settings: On a single virtual non-uniform memory architecture node: Maximum number of processors : 16 Maximum amount of memory (MB) : 48070 Maximum NUMA nodes allowed on a socket: 2 Only 1 socket. E) The CoreInfo.exe quick "Approximate Cross-NUMA Node Access Cost (relative to fastest)" tends to show the 4 numbers varying from 1.0 to 1.7 when retried repeatedly. An oddity is that sometimes the 1.0's are between 00 and 01, in fact this seems usual, and normally at most one 1.0 exists. The 00 row seems to always have the smaller numbers. An example: 00 01 00: 1.2 1.0 01: 1.3 1.5 I had no original intent of playing with NUMA but I figured that the Threadripper could be configured for such, and even has configurations that apparently require such as far as AMD Ryzen Master is concerned, could be of interest and possible use for folks testing FreeBSD NUMA support. Since I'd done nothing to build a kernel with NUMA enabled, FreeBSD 12.0 under Hyper-V did not see the NUMA structure from (D). One thing that did show during booting was getting 4 lines of: "SRAT: Ignoring memory at addr" instead of 2. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Mon Apr 9 10:01:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9559BF95674 for ; Mon, 9 Apr 2018 10:01:48 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03AB768C52 for ; Mon, 9 Apr 2018 10:01:48 +0000 (UTC) (envelope-from dmilith@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id b127so17875453wmf.5 for ; Mon, 09 Apr 2018 03:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:date:references:to:message-id:mime-version; bh=soL/4R3UjjqBGR+sfcTILZvRR+jI/8fvkbdQlLxT8Fc=; b=otRBZIwq72b5E1AumZExCGdf53n0FxRYlkKgwX1gPdjoYxnBCdv3oeweZIfVFl6/+C WMsEFEGR8xlNeAepA6tOYuu7WJBOIsBpgEL+3CP2Tw834V5+zRyNIoiAtZrfO/lA9Uu3 b9uoQjlZfNyjYty1tqm5lWXsu7OCQi5Gp0sJ+llQUYxyg0SLaBSBxEz8vvGPs0hejAxN WQTxlH/9AtOy9/VU1nbvpIaol2GIQiQevsCWYwK6beaLcLAvPb2r/H9NAkSIM2yLfWAZ p+JWnKqDvsX1ifXCD+4n5Icp9VCPDfgvjXW1kFX0i/ySNasxpxLHpocJ9KHA9/iBJUxd 0zzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=soL/4R3UjjqBGR+sfcTILZvRR+jI/8fvkbdQlLxT8Fc=; b=I2SnFmIUI2ybwFFq/QfXdoRjCDqQpNAobMe4TJFrBBT6vJAIzmDw5V0uO24Xs07gME xHk75OC8XRgBhLDh3M+4qsGLOTmVgnrI1XDiyX7Rtr+CFIideWwVA/guoT/XVdyxbRBU CqAKTMiweurWPo88lMRLzyLWewjHSUvm9fzlnuLa8eeC4j94aMUZTXwqsTG/4lHtuojC ZrIhc2beV7OsPNfsmG5KhDTUUR0yUXXv1/kHMxXojYo6PWyS3uNdEkhM1amQAWxgGCwG l9wHA7EYr6C3gM8tpaLSxOtoSov4eD9URTlwdDRY6mWKZ0key4oJHg2nXhtyHWozO8Q4 Y1kw== X-Gm-Message-State: ALQs6tD/cRSK8Au6ctiqvbwXrUHYFL1CbreoVmkjljAcyO4oT9ePcoxF PfTXa/V74NHF8i2F9IdioUVHaAjo X-Google-Smtp-Source: AIpwx4/e2abbyGXcSVAQINsrnj3beM6X12ss6aSHkF+4Wzj1tkOpM0e+7DlNoZPkxLeJuzRPMlFRtA== X-Received: by 10.28.14.9 with SMTP id 9mr18127545wmo.127.1523268106712; Mon, 09 Apr 2018 03:01:46 -0700 (PDT) Received: from [100.64.1.2] (89-64-50-100.dynamic.chello.pl. [89.64.50.100]) by smtp.gmail.com with ESMTPSA id r82sm351946wme.31.2018.04.09.03.01.45 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Apr 2018 03:01:45 -0700 (PDT) From: Daniel Dettlaff Content-Type: multipart/signed; boundary="Apple-Mail=_83BA4A4D-3533-4C18-A6A3-E7B8BB571557"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Tracing with DTrace, when custom probe provider is running as regular user Date: Mon, 9 Apr 2018 12:01:44 +0200 References: To: freebsd-hackers@freebsd.org Message-Id: <1D449DD6-4D38-4561-8BD0-B6E581AB53A8@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 10:01:48 -0000 --Apple-Mail=_83BA4A4D-3533-4C18-A6A3-E7B8BB571557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello FreeBSD hackers. I have question about real world Dtrace tracing = on our favourite platform. Yesterday did enable dtrace for my builds of Erlang*, Php*, Node and = Postgresql9x on my x86_64 11.1 system. It works very well in general, = with one exception - I'm unable to get probes from software running as = regular user. So for example - I can launch Erlang 19.3.x REPL as root (`erl`), and do = `dtrace -l | grep beam` - to see new provider with Erlang probes.. but = if I launch exactly same Erlang REPL as regular user ("www" in my case) = - I cannot see published probes when invoking `dtrace -l` (as root). I = also can't invoke `dtrace -l` as regular user obviously. Here's example on a single screenshot: http://s.verknowsys.com/38a22eb93f473a0bac43e5e56f3d7f35.png =E2=87=92 red lambda =E2=87=92 root, gray lambda =E2=87=92 = regular user. =E2=87=92 Erlang REPL running as root =E2=87=92 probes are = there.. but when as regular user =E2=87=92 nothing Issue is critical for tracing Postgresql which demands to run with NON = privileged user, but in general launching any server software as root = should be considered to be "harmful" / "a bad idea" right? So question is - is there a way to work around this? I wish to be able = to trace user software as root using dtrace. Is there a way to do it? I = build whole system from source so I can even do custom patch if I'd know = where to look :) Thanks in advance! -- Daniel (dmilith) Dettlaff --Apple-Mail=_83BA4A4D-3533-4C18-A6A3-E7B8BB571557 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 - http://gpgtools.org iF0EARECAB0WIQTRxYhlHcH16So4S7KBOC9Vj5almgUCWss6CAAKCRCBOC9Vj5al msv6AJ0eOeEVZ1S5Fuik8hqsR7C+NMVD4QCdHNnk05HsfXpQ21Ub9rmh6daD5dQ= =IsEv -----END PGP SIGNATURE----- --Apple-Mail=_83BA4A4D-3533-4C18-A6A3-E7B8BB571557-- From owner-freebsd-hackers@freebsd.org Mon Apr 9 10:30:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9516BF97567 for ; Mon, 9 Apr 2018 10:30:26 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F896785FD for ; Mon, 9 Apr 2018 10:30:25 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [88.202.132.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id BB28110E71 for ; Mon, 9 Apr 2018 10:30:17 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/BB28110E71; dkim=none; dkim-atps=neutral Subject: Re: Tracing with DTrace, when custom probe provider is running as regular user To: freebsd-hackers@freebsd.org References: <1D449DD6-4D38-4561-8BD0-B6E581AB53A8@gmail.com> From: Matthew Seaman Message-ID: Date: Mon, 9 Apr 2018 11:30:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1D449DD6-4D38-4561-8BD0-B6E581AB53A8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 10:30:26 -0000 On 09/04/2018 11:01, Daniel Dettlaff wrote: > Issue is critical for tracing Postgresql which demands to run with > NON privileged user, but in general launching any server software as root > should be considered to be "harmful" / "a bad idea" right? The issue with allowing non-privileged users access to dtrace is the risk of disclosing kernel memory. Unfortunately blocking this access means that using the UserSDT's from (for example) postgresql-server running as the postgres user is not permitted. > So question is - is there a way to work around this? I wish to be > able to trace user software as root using dtrace. Is there a way to > do it? I build whole system from source so I can even do custom patch > if I'd know where to look :) Actually, it all depends on the permissions on /dev/dtrace/* -- It's fairly easy to. say, add a 'dtrace' group, change /dev/dtrace/helper to be owned by root:dtrace and mode 0770 by tweaking /etc/devfs.rules: [userdtrace=10] add path dtrace/helper mode 0660 group dtrace and adding devfs_system_ruleset="userdtrace" to /etc/rc.conf, and then making the postgres or whatever other users your software runs as members of group dtrace Cheers, Matthew From owner-freebsd-hackers@freebsd.org Mon Apr 9 19:52:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3020F9E28B; Mon, 9 Apr 2018 19:52:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66A476EB7F; Mon, 9 Apr 2018 19:52:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9053110AFD6; Mon, 9 Apr 2018 15:52:43 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Mark Millard , FreeBSD Hackers , freebsd-amd64@freebsd.org Subject: Re: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected? Date: Mon, 09 Apr 2018 12:37:26 -0700 Message-ID: <2644434.8Ktpdmy6i5@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> References: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 09 Apr 2018 15:52:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 19:52:44 -0000 On Sunday, April 01, 2018 02:23:36 PM Mark Millard wrote: > For: > > # uname -apKU > FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 1200060 1200060 > > I get: > > . . . > pci0: at device 7.3 (no driver attached) > . . . > intsmb0: at device 7.3 on pci0 > intsmb0: Could not allocate I/O space > device_attach: intsmb0 attach returned 6 > > on a Ryzen Threadripper 1950X where FreeBSD is being run under > Hyper-V (on a Windows 10 Pro machine). > > Is this expected? Did I misconfigure something in Hyper-V? That seems like an odd device to have for an AMD machine. I suspect that this has never worked and the module started auto-loading due to devmatch. -- John Baldwin From owner-freebsd-hackers@freebsd.org Tue Apr 10 05:32:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E2E3FA2001; Tue, 10 Apr 2018 05:32:24 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) (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 5C8EC7ED3F; Tue, 10 Apr 2018 05:32:23 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f65.google.com with SMTP id v207-v6so9811927lfa.10; Mon, 09 Apr 2018 22:32:23 -0700 (PDT) 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6KRrdrSy1hA/sVZKmDI4gfDh7/MsBVWBc20gVbAOczM=; b=nyk2/O+3Biv6OMA2C9A8I7Ea9r2uSZbwn4mulBOb6aZS84DhHw8s+RATfYNMj/Q5Bb CPNHCi9zdfkIbmORcwK09clCl2DruhTIPGDyvnXV/4W/SPKEUcMFvH/NY55NgKF5eNHH L/0Xa0rlk4kPIOXE6DiWvtBIXQbyM7DJVQM8Cnf6R+is7mq7ZxGb44fIOckiyKcemo1T 9cDWLGBr+ebyhC3Wvf71XROrAjo/v6Xgdj3X7q0B0P4YoGF1eNnQWm+l/YBaVhLl18ob 4tBsp4pL++jmJG/guU3irtCKa2F9tUpDWFV2UAyRyZz+X7dcvkEEy1rxtP6/g8sqyzJO bkuA== X-Gm-Message-State: ALQs6tCABQ0Vtjvh6otFb6OyNcy9R3J2+vh3oKVKyLtXB1obCeSuoXle naz8AEkKxN9rWhqx1qBFq6fqC4oq X-Google-Smtp-Source: AIpwx49LJkG5AU+7I3pvO6tMLkBC4D8Ooh0oS49+1/MUPGtE47WIRHFwv5EkxRjHyzHQKi/H7Cuo8w== X-Received: by 2002:a19:d9d4:: with SMTP id s81-v6mr1011002lfi.49.1523338336228; Mon, 09 Apr 2018 22:32:16 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id r25sm335527ljc.8.2018.04.09.22.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 22:32:15 -0700 (PDT) Subject: Re: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected? To: John Baldwin , freebsd-current@freebsd.org Cc: FreeBSD Hackers , freebsd-amd64@freebsd.org References: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> <2644434.8Ktpdmy6i5@ralph.baldwin.cx> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <2a03f32b-34f9-7fcb-8d4d-94bd7a8d4290@FreeBSD.org> Date: Tue, 10 Apr 2018 08:32:13 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2644434.8Ktpdmy6i5@ralph.baldwin.cx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 05:32:24 -0000 On 09/04/2018 22:37, John Baldwin wrote: > On Sunday, April 01, 2018 02:23:36 PM Mark Millard wrote: >> For: >> >> # uname -apKU >> FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 1200060 1200060 >> >> I get: >> >> . . . >> pci0: at device 7.3 (no driver attached) >> . . . >> intsmb0: at device 7.3 on pci0 >> intsmb0: Could not allocate I/O space >> device_attach: intsmb0 attach returned 6 >> >> on a Ryzen Threadripper 1950X where FreeBSD is being run under >> Hyper-V (on a Windows 10 Pro machine). Note the above. >> Is this expected? Did I misconfigure something in Hyper-V? > > That seems like an odd device to have for an AMD machine. Except that this is not an AMD machine but a Hyper-V? (And even if that were a physical AMD machine the driver would not be odd for it as the driver supports AMD chipsets that provide SMBus controllers compatible with PIIX4). Mark provided the following information in his post: >> # pciconf -l -v 0:0:7:3 >> none0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82371AB/EB/MB PIIX4 ACPI' >> class = bridge My guess is that Hyper-V's emulation of PIIX4 is not complete or correct with respect to the SMBus controller. And, as I am sure that Hyper-V does not emulate any SMBus slaves anyway, it would be completely useless. > I suspect that this has never > worked and the module started auto-loading due to devmatch. This must be true. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Tue Apr 10 17:26:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7A93F89218; Tue, 10 Apr 2018 17:26:10 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BE9F8649B; Tue, 10 Apr 2018 17:26:10 +0000 (UTC) (envelope-from luca.pizzamiglio@gmail.com) Received: by mail-oi0-f45.google.com with SMTP id x9-v6so11923743oig.7; Tue, 10 Apr 2018 10:26:10 -0700 (PDT) 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=fXECtlAUaLaid3USiODCktVRejukMwUjc1tze712kEw=; b=BxOEEgKeVoZJyg/f4Vf7B6OYINuvswkvLWNrZZXjLoooSc/4s8ime7V/bzQLsOAD59 Qrl8zN5Fyp4XTkQ0rNbKMbCC7/Ly29XxgNr7qNZuA6Uxox/xj3YjcL8tHONpH4IRRw9L z91UKtkYIbcgtQiotEv9HCggT7qTUUnvXvf/Z5zjpfnhGqb2OTBoRhbdPDV2V1Sin9lb Xliql/C9L8PgGZTXUUsZtkV8fVRslKal6QwolIbDjFOpTQxl/KabyPAVzQxNdWhiuYDB RghH8boulwh9ECLuH1caga1uExvYMRdvvSexMaS3g+QbIjfW8wIlgwggn+i7gfXpxdt/ 7r/w== X-Gm-Message-State: ALQs6tCa3R9OaEh33JHe3jXleCE8D+kh/WQUQzqGnj0xCjcdlypGky8a 68GVvCxqw8etqE1srvWUnvGjlBfX X-Google-Smtp-Source: AIpwx4/KlCImT52/HpHkGREN7OsO0sinRcu9A1ozUqqGqrJQ0Q56VnOraeA0EijJPOxtfNJ9fxjwLg== X-Received: by 2002:aca:5c02:: with SMTP id q2-v6mr705047oib.106.1523377712239; Tue, 10 Apr 2018 09:28:32 -0700 (PDT) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com. [74.125.82.169]) by smtp.gmail.com with ESMTPSA id p23-v6sm2316187oie.43.2018.04.10.09.28.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 09:28:32 -0700 (PDT) Received: by mail-ot0-f169.google.com with SMTP id o9-v6so13447470otj.5; Tue, 10 Apr 2018 09:28:31 -0700 (PDT) X-Received: by 2002:a9d:27aa:: with SMTP id c39-v6mr774600otb.104.1523377711876; Tue, 10 Apr 2018 09:28:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:22e8:0:0:0:0:0 with HTTP; Tue, 10 Apr 2018 09:28:11 -0700 (PDT) In-Reply-To: <8B1A6A6C-4280-4B96-9D60-FC9E7EEE2222@lists.zabbadoz.net> References: <472069af-0f9d-d830-064b-2d984a5774ae@zirakzigil.org> <8B1A6A6C-4280-4B96-9D60-FC9E7EEE2222@lists.zabbadoz.net> From: Luca Pizzamiglio Date: Tue, 10 Apr 2018 18:28:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Duplicate MAC addresses in VNET epair interaces To: "Bjoern A. Zeeb" Cc: Giulio Ferro , "freebsd-net@freebsd.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 17:26:11 -0000 Hi. I have the same problem. The arc4random() call was committed and reverted ( https://svnweb.freebsd.org/base/head/sys/net/if_epair.c?view=3Dlog) I have a patch, that I'm currently using, that solves the issue locally (available here https://pastebin.com/LpPEVJL7 ) To be more generic, I'd like to add some hostid bits, following the approach of if_bridge, in case your epair interface has to be connected to a LAN. best regards, pizzamig On Mon, Feb 6, 2017 at 8:53 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On 6 Feb 2017, at 18:53, Giulio Ferro wrote: > > Hi all, >> >> >> Setup: >> >> 11.0-STABLE FreeBSD 11.0-STABLE #0 r312338: Tue Jan 17 12:29:38 UTC 2017 >> >> >> I've set up two freebsd hosts, each of which has a single VNET jail. >> >> On each host I've created 2 epair interfaces. >> >> Host A >> >> - epair0a, epair1a on the host >> >> - epair0b, epair1b on the jail >> >> >> Host B >> >> - epair0a, epair10a on the host >> >> - epair0b, epair10b on the jail >> >> >> What I noticed is that on both hosts, each epair interface has the same >> MAC address: >> >> =E2=80=A6> > >> >> (same behavior on the epair interfaces on the jail side) >> >> >> As you can see, the mac addresses seems to depend on the order of the >> creation of the epair, not on the name or address >> >> >> This is a potentially bad behavior, because if I want to bridge say >> epair1a on A with epair10a on B with a VPN or >> >> a physical connection giving 192.168.1.1 to epair1b and 192.168.1.2 to >> epair10b, I won't be able to make them >> >> talk to each other since they have the same MAC address. >> >> >> My question is: is this a bug or something I'm doing wrong? If there any >> workaround I can use? >> > > > From the man page: > > Like any other Ethernet interface, an epair needs to have a network > address. Each epair will be assigned a locally administered address > by > default, that is only guaranteed to be unique within one network > stack. > To change the default addresses one may use the SIOCSIFADDR ioctl(2) > or > ifconfig(8) utility. > > I thought someone patched it a few years ago to have a pseudo-random part > to make collisions less likely and use the FreeBSD vendor space, but it > seems that never happened for epair (or didn=E2=80=99t make it into the t= ree). > > ifconfig epair[ab] ether 02:xx:xx:xx:xx is your friend for now. > > /bz > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Tue Apr 10 22:50:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20BC4FA048A; Tue, 10 Apr 2018 22:50:10 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 AF2C173D02; Tue, 10 Apr 2018 22:50:09 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x243.google.com with SMTP id d7so264613ioc.11; Tue, 10 Apr 2018 15:50:09 -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=+a3TTQwKZ1zs+Vcs/SHP+ZMoY6iHpHPUNUY7vuSWLjk=; b=LdtKmgsierLueQ17v+l+LY8FoO4k4sd0gRCOjFPmcDafJqeI6l3yIyGPocII+tkXyS lohoOXSYKz+3owy6hBZ+HYUFymXN4sFIC1BE3eqBWmZqmU1vnkm5+KcotB2/WJOZbh/r GHvz3ZNgcBtdemoOffBp2C94/GJyDOJ86hp3EmoNOl3Z8uSFrv3HfkDfXkjpon9vcoeM szxnUGKIVA6SSilRq4VtEbkQK2v8dPUHWGbQG0p+fKi3GS211wK1qj1Fsl605qoUywtz gTimoo1aZv0OmAfcFszxFUpGBv+xZb0jT/J/YlDYkKkYYpriUy9JCYziJNX0E5GlLV5B vR7g== 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=+a3TTQwKZ1zs+Vcs/SHP+ZMoY6iHpHPUNUY7vuSWLjk=; b=JIXziYLFk2q7jkiOBNW/+Nzui7j5fFFhxG6WOlLaGH0nBIDAjhaJ1tnBmlI/1wh5mx /TLo8C+W/a0owVqn21xB7sd9DvOMR37FPjZsrlnR5pbh+6FlnXPMlDkcjDnai1Acv3/4 E1/zLOWGZhU47mv6e5K7+Sm2bwMogW/gEMP78m5Wn2D8hNPwqSlV40hZhx2NOZUTfXux YQOacAAZXqLmyJcZrp89Cu6EaCcj8N7qOykH0c6AeviRHYwddGoQ2UjTvIbAleFR6HRt UT0GGo8f4iOBiDMPH2upQMb6cJrKwXJWbnjK+nLVBObGzJGrhujlt4WPdmdxKSSBHX3m eHiQ== X-Gm-Message-State: ALQs6tBJvEXJsmaW5/+4kmHX8I7tB6IIHLlvBHONNP9BSVRnQVfmEYDB speIoWJjt7HOVUZbCnxGI2rXNypg2xvPxTtvLKA= X-Google-Smtp-Source: AIpwx497WZsENuRzh6gRqjo+FsmQli6MGcs9puepID7bNMqmoVOPSSrkKIXdsPRD6qxPYIRNwuFUO/ZsPEyRH4DD6MY= X-Received: by 10.107.186.70 with SMTP id k67mr2527015iof.166.1523400608867; Tue, 10 Apr 2018 15:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Tue, 10 Apr 2018 15:50:08 -0700 (PDT) From: Dieter BSD Date: Tue, 10 Apr 2018 15:50:08 -0700 Message-ID: Subject: Realtek re(4) driver To: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:50:10 -0000 Multiple people have found that FreeBSD's re(4) driver for Realtek Ethernet chips has problems. Something like a rcp(1) with another FreeBSD box merely runs slower due to the stalls, but if the other end has buggy network code and/or if the transfer is forced to use UDP (Unreliable Data Protocol) data is lost. :-( Rumor has it that Realtek has a driver that works properly with FreeBSD. FreeBSD's developers are apparently unable to: a) Fix the existing FreeBSD re(4) device driver so that it works correctly. b) Replace the existing FreeBSD re(4) device driver with Realtek's driver. c) Make Realtek's driver into a port/pkg. d) At least add a warning to the re(4) man page, with the URL for Realtek's driver. Therefore every user with Realtek Ethernet chips are forced to somehow discover that Realtek has a working driver, then somehow obtain a copy of this mythical driver, get it to compile and build a custom kernel. They then need to write a test suite and verify that Realtek's driver does in fact work properly for their applications. I am currently suffering data loss due to this. Therefore I am attempting to obtain a copy of the mythical Realtek device driver. I managed to find > http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false But it does not work for me. It has a listing for > Description Version Update Time File Size Download Site 1 > FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global The machine with the re ports is running 10.3, hopefully the 7&8 code will compile and work on 10. But the real problem is that clicking on "Global" does not work. Some browsers do nothing. Firefox creates a new window with http://www.realtek.com.tw/downloads/ which is going backwards. I was expecting something like a tar file containing the source code. I also tried google, and emailing a FreeBSD user that runs the Realtek driver, but both pointed me to the above non-working URL. I'm told that seamonkey works, but... So my question is: could someone please tell me the URL that points *directly* to the mythical Realtek device driver? (without the broken javascheist garbage) From owner-freebsd-hackers@freebsd.org Tue Apr 10 22:55:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AB20FA0C43; Tue, 10 Apr 2018 22:55:00 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::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 E51D8768C1; Tue, 10 Apr 2018 22:54:59 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x242.google.com with SMTP id 141so267359iou.12; Tue, 10 Apr 2018 15:54:59 -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:cc; bh=g8umbL33JS4JMhFOtXihytGs1MPURHhV0U1dPQO1+1w=; b=PgtnKbfrJWtgc5gFg9ZM+xypbtqwBqoPnGuUmBRCMFI1YoLiYF22vdXhhBEfGYEw6E Hwncpu6scW5gYuCevrEsm/HFBKgWjjUiDIPRDWnZ4DdMgCTjwvOJa/BZcSN8nRP8cbGX qo/M55wB0HvWVzzaX1C4d85MG+S+YspToZfX1SOAtcMTGydmGgRWjpKq1keKkw5z4LwW yES4vgbLeP6DbUyIGSvuRaJEnwyUOJaTrHt1+0+7LSYWWs7B5xrlath/SamB6bfA1O0/ BQtUrNr0+2I68GET7sIXma9YmWbTkmDZrSGdpegyqXgAeWXV1lWUqS7BElOFGk/HR0kd ewNA== 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:cc; bh=g8umbL33JS4JMhFOtXihytGs1MPURHhV0U1dPQO1+1w=; b=gqPCLOtk+hXxuFh8F5zkw997KSP1fyiZ5je/liGyH9WAmOL4urtXXE5VAljrh5E6Pn 4Mte70+J9y4fK01S5hPEHx2ru6mTNYZrqypE+KKOUgC08A5Bz8qdwVeDdt5QJZve/L7a 08fgzMiSC9p4ku3C/CstatLO6JUgZMiU5e2td5Jo3bB3HUdGL6wtZilGWpSlvz523roQ W5Gg43b7oK4hv/S7PRO4c3VSTuhCZJtzvpxMZfoeLzWBI9ixV7L+aiymKQ6f5QBMag6l 09USs56vKvl9Ftvkr3tAQ3AySMjyMyv9P9TjsI7/LV8/t7NV80NTMnyTP81EFn8GiIKK Ydig== X-Gm-Message-State: ALQs6tCeAUptuoNk8MUG/8s22Fk/tzBFqc23Y/g+MSnTrme8rMhQSf1v YQHmu1UxtT6T3ZQ1hm0U8U3rV6K+vyLpUHp1XVg= X-Google-Smtp-Source: AIpwx49b56snKnBLOm9G8UeLhwQsi6yZfRa0YensdI0kYroj8e1y9NcH4URvtU0hynNigyLnQV5tjS7OAL/1wfZ091s= X-Received: by 10.107.146.136 with SMTP id u130mr2324773iod.96.1523400899098; Tue, 10 Apr 2018 15:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Tue, 10 Apr 2018 15:54:58 -0700 (PDT) From: Dieter BSD Date: Tue, 10 Apr 2018 15:54:58 -0700 Message-ID: Subject: AX88179 USB-to-Ethernet is slow and silently corrupts data To: freebsd-usb@freebsd.org, freebsd-net@freebsd.org Cc: freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:55:00 -0000 10.3-RELEASE amd64 with ECC memory VIA VL805 USB 3.0 controller ue0 is Siig USB-to-Ethernet Chipset: AX88179 ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) ue0: flags=8c43 metric 0 mtu 1500 options=8000b inet 10.0.210.66 netmask 0xffffff00 broadcast 10.0.210.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active If media is set to "1000baseT " it "works", but slowly, and received data is silently corrupted. :-( Transmitted data is not corrupted (tested with > 30 GB). ifconfig ue0 -txcsum "works", but still gives silent data corruption ifconfig ue0 -rxcsum (acts the same with or without txcsum) ping out netstat sees packets both directions, but ping doesn't see the response: 8 packets transmitted, 0 packets received, 100.0% packet loss ping in netstat sees packets in, but no responses going out I can see that some Ethernet controllers would not support checksum offloading, but it seems to me that turning the checksum offloading off should always work? (at the expense of more cpu load) Previously (2016 May): # ifconfig ue0 media 100baseTX-FDX fixed the input error problem and the data corruption problem, at the expense of making it even slower. Sent data from machine A with 10Mbps Ethernet. (Netgear Ethernet switch converts 10Mbps to 1000Mbps) Netstat did not report any input errors on ue0 and there was no data corruption. So ue0 can handle gigabit data rate, but gets input errors if packets arrive too frequently. I tried moving it to a USB-2 port. No data corruption, but USB-2 is slow. The chip performs a lot better for tweaktown: http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-network-adapter-review/index.html (Vantec CB-U300GNA with the same Asix AX88179 chip) "full duplex gigabit with 952 Mbps consistently across the chart" http://www.vantecusa.com/products_detail.php?p_id=143&p_name=USB+3.0+Gigabit+Ethernet+Adapter&pc_id=21&pc_name=Network&pt_id=5&pt_name=Accessories Asix AX88179 chip: http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112 "Supports Jumbo frame up to 4KB" But ifconfig rejects any value > 1500: ifconfig ue0 mtu 1501 ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument I tried mtu of 100, 500, 1000, 1400 but they all give rcp: lost connection USB disks are fast, so the USB controller seems to work ok. I also tried a Tek Republic TUN-300 which has the same AX88179, and it acts the same as the Siig. So, transmit works, but is slow. Receive works if the amount of traffic is low enough (limit rate of data sent, limit Ethernet speed, or use USB-2). But if data is received too fast it gets silently corrupted. Setting -rxcsum does not work, and cannot set mtu other than 1500. Questions: Why does -rxcsum not work? Why does attempting to set a larger mtu fail? Why does setting a smaller mtu make rcp fail? Why is the chip acting slow? How do I get it to work properly? (fast and without data corruption) From owner-freebsd-hackers@freebsd.org Tue Apr 10 23:06:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9622AFA1CC2 for ; Tue, 10 Apr 2018 23:06:03 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 155A777B90 for ; Tue, 10 Apr 2018 23:06:02 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wr0-x232.google.com with SMTP id m13so14341594wrj.5 for ; Tue, 10 Apr 2018 16:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=MyHWBIklveE32ec5SRqI+vnf+bIl1v7VwHrGYwKEJgY=; b=RktKguhQTv1xfX2MySr4rKBHnpBNz3GJs7Dut+dceKydVwSKaxOfjc0igmYtcQ1D5+ IleqPz3fPSL1dJubnuq1XiRq8rE36E6/PxL9GTjCdnQNJFFqiG9ND46WRKY2Q/f8lPmL dypRT4KaZ8S4m93n5Gi+HAymC2TKf8f5AaHEl+7rwh+vGtdLHAxQJq2zvtL/1gFl87YG K7DQLxHbNEFoiHW4X+A50Sysv4vQhlS4FSlers+r7You0mNhjqh9WEmqTB0lKW1steTo mJfnyGZd+XddUCc7zAKnnMG/S8SyCnfLdbgRESCO6hdfW3KzTQzWhbEBQa0fJScccf7g XdRw== 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-language; bh=MyHWBIklveE32ec5SRqI+vnf+bIl1v7VwHrGYwKEJgY=; b=fhPgAuktIniHP5t+/1xhNBww/UTYBiGOXXb2uxyitTPWKsmagLL9dwcWSOatNtDIFB 9kEVwviYVAYtP9ZOKMlDnqg3w0zxN893SJk7Jq6JLQSSQ84kxTyLb0CyXizWvelkHatU qg7C/CB2c/L57D+d9cA4lL+gRSQdGV6p5lkPUPqMj+1JXnipCWAlb/MN2WZXlmWub9Fa A4nvknVcydxj5BxS/6TO8oLBvcTyocsHAUWUpFVBLwMjQExyNi46J8vkdxpLn4WxIVAj jsk0i7T4guuSi48EfpvOmC9WyIJIlR7fJU1CmulOqQiBdTZpajRzmc9LqShKsEzu9yQN anwg== X-Gm-Message-State: ALQs6tBZW/SbS5X3AZ08TUZSIF8hskpbqqXiuGZgHz8qysh7cjQyEbV/ lPwr5Ot4DTu03SM5glY5aeHNc0fHgmE= X-Google-Smtp-Source: AIpwx48zCgj+TISKBV+r+bCRFGZHXITsuoVhjfQUMiGWToDp3Br5rMLtCRAFtcQDzL8lwzTh3fonwA== X-Received: by 10.223.163.221 with SMTP id m29mr1765896wrb.4.1523401561102; Tue, 10 Apr 2018 16:06:01 -0700 (PDT) Received: from [10.10.1.111] ([185.97.61.1]) by smtp.gmail.com with ESMTPSA id v75sm3846337wrc.90.2018.04.10.16.05.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 16:05:59 -0700 (PDT) Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org References: From: Steven Hartland Message-ID: Date: Wed, 11 Apr 2018 00:05:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 23:06:03 -0000 Try: http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz May or many not work depending on if its a per client download URL On 10/04/2018 23:50, Dieter BSD wrote: > Multiple people have found that FreeBSD's re(4) driver for Realtek > Ethernet chips has problems. Something like a rcp(1) with another > FreeBSD box merely runs slower due to the stalls, but if the other end > has buggy network code and/or if the transfer is forced to use UDP > (Unreliable Data Protocol) data is lost. :-( > > Rumor has it that Realtek has a driver that works properly with FreeBSD. > > FreeBSD's developers are apparently unable to: > a) Fix the existing FreeBSD re(4) device driver so that it works correctly. > b) Replace the existing FreeBSD re(4) device driver with Realtek's driver. > c) Make Realtek's driver into a port/pkg. > d) At least add a warning to the re(4) man page, with the URL for > Realtek's driver. > > Therefore every user with Realtek Ethernet chips are forced to somehow > discover that Realtek has a working driver, then somehow obtain a copy > of this mythical driver, get it to compile and build a custom kernel. > They then need to write a test suite and verify that Realtek's driver > does in fact work properly for their applications. > > I am currently suffering data loss due to this. Therefore I am > attempting to obtain a copy of the mythical Realtek device driver. > I managed to find > >> http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false > But it does not work for me. It has a listing for > >> Description Version Update Time File Size Download Site 1 >> FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global > The machine with the re ports is running 10.3, hopefully the 7&8 code > will compile and work on 10. But the real problem is that clicking on > "Global" does not work. Some browsers do nothing. Firefox creates > a new window with http://www.realtek.com.tw/downloads/ > which is going backwards. I was expecting something like a tar file > containing the source code. > > I also tried google, and emailing a FreeBSD user that runs the Realtek > driver, but both pointed me to the above non-working URL. I'm > told that seamonkey works, but... > > So my question is: could someone please tell me the URL that points > *directly* to the mythical Realtek device driver? (without > the broken javascheist garbage) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Apr 11 10:14:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1061DF86443 for ; Wed, 11 Apr 2018 10:14:14 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 7752D8FB4B for ; Wed, 11 Apr 2018 10:14:13 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id s12so1197085wrc.8 for ; Wed, 11 Apr 2018 03:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=HAZXlYoNuXzZm01xMGaHcO7vOnYdAPDFMDiwOw70npU=; b=bJsEwh8/aNNw+lEnxWYojrEmnfBZZ4R1S6XbjwIs8ab8nsjP+OsH+rUDni3IelXSxs xs3q8i8w7+nm3Vz2f1fB9+RnZfYj5x3IO/A4Oc4WHCJHMa/bJRNgA8zYhVfFhKjO1N/3 GjdOL7MtnmZOkPe7V5M1KfBus4KemGqxy6/WN2kMIhhzMpPaa1/cqlSDzWRiyTMWZnix iuppSbJj24ssBLajli6etZjGTBvlCNdmYgW4IJnIckTZm6rIQJvTODYedU4bRJFNyo7O AoL24iteiMIsUNeSV87jsQLJGAtiKrmBUey0UdfouHc5Qhho8G9mHJlU+mkEjvxi3JUQ 1LTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=HAZXlYoNuXzZm01xMGaHcO7vOnYdAPDFMDiwOw70npU=; b=hDsU+ZLSB4OB5uQBQsTmdHVTmIVY9A2hWcEolyvNKZpiRaIW08a8t9vB9FEJkcrMwC rlBWHqXcyHW53y9L1q+Tyav4/rJJt7dhIS/WuOZpMBatvA5LuuUiaCtfeM/2uOtOIVza xNOB/wqfPHmLVSuGYbHNYvW94p1xbKidpaulfk32f7r9uXlZelDodsp1WSs5v7C2LAzF qnJWEwE1GShY4LKn5yZKs/c0gPjYQpWWpt6HWWxN0WNG0Lqnd44ty9uE+ew6uYCW1c3t B5hz2BBWNojnm+EEYLCaF+ymyQTmUaD9yX44ndfmy/TDTbUo3NB04mGdUYNhBlZ84Lgb iC7A== X-Gm-Message-State: ALQs6tCVqpTjLHmnWw79cgfdOVm8jl2uCbfmhrRP8fyUZF5XZf4hRSzg T6lCAwBDZaR0EcSLvYGMIOKAiw== X-Google-Smtp-Source: AIpwx49NiY0Rp0nb77aO5Z6p4s07D7AtoScTTSnOPOVFZChFmrFPAteZfSiCAAZZiU2KcTGGVRtB8w== X-Received: by 10.223.166.79 with SMTP id k73mr3042916wrc.200.1523441652493; Wed, 11 Apr 2018 03:14:12 -0700 (PDT) Received: from ernst.home (pD9E23019.dip0.t-ipconnect.de. [217.226.48.25]) by smtp.gmail.com with ESMTPSA id e131sm15044620wmg.1.2018.04.11.03.14.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Apr 2018 03:14:11 -0700 (PDT) Date: Wed, 11 Apr 2018 12:14:04 +0200 From: Gary Jennejohn To: Steven Hartland Cc: freebsd-hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <20180411121404.71a07fef@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 10:14:14 -0000 On Wed, 11 Apr 2018 00:05:59 +0100 Steven Hartland wrote: > Try: > http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz > > May or many not work depending on if its a per client download URL > This is the old if_rl driver by Bill Paul from 1998. Hard to believe it's really superior to the newer version, which is also based on later code from Bill Paul. [snip] -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Apr 11 10:32:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D4F4F87AF2 for ; Wed, 11 Apr 2018 10:32:14 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B8276D62C for ; Wed, 11 Apr 2018 10:32:13 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-10) with ESMTPSA id w3BAW0bY007838 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 11 Apr 2018 12:32:00 +0200 Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org References: <20180411121404.71a07fef@ernst.home> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= xsFNBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABzSpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj7CwZQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2c7BTQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAcLBfAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> Date: Wed, 11 Apr 2018 12:32:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: <20180411121404.71a07fef@ernst.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0-beta at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 10:32:14 -0000 Gary Jennejohn a écrit : > On Wed, 11 Apr 2018 00:05:59 +0100 > Steven Hartland wrote: > >> Try: >> http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz >> >> May or many not work depending on if its a per client download URL >> > > This is the old if_rl driver by Bill Paul from 1998. Hard to > believe it's really superior to the newer version, which is also > based on later code from Bill Paul. > > [snip] I use a diskless workstation. With re driver provided by FreeBSD kernel (9/10/11.x), system randomly crashed because ethernet driver stalls (and datarate is always less than 300mbps). With official realtek driver (v194.01), system now runs as expected (with datarate up to 1 Gbps). Internal re driver is broken on this ethernet adapter (maybe on several other adapters) : re0@pci0:2:0:0: class=0x020000 card=0x78511462 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet Regards, JKB From owner-freebsd-hackers@freebsd.org Wed Apr 11 10:45:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BD9FF88C65 for ; Wed, 11 Apr 2018 10:45:43 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.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 CC9EC70939 for ; Wed, 11 Apr 2018 10:45:41 +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 w3BAjXkI040261; Wed, 11 Apr 2018 10:45:33 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w3BAjXbL040260; Wed, 11 Apr 2018 03:45:33 -0700 (PDT) (envelope-from david) Date: Wed, 11 Apr 2018 03:45:33 -0700 From: David Wolfskill To: BERTRAND =?iso-8859-1?Q?Jo=EBl?= Cc: freebsd-hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <20180411104533.GC1134@albert.catwhisker.org> Reply-To: hackers@freebsd.org Mail-Followup-To: hackers@freebsd.org, BERTRAND =?iso-8859-1?Q?Jo=EBl?= , freebsd-hackers@freebsd.org References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hI0LKvM4dmXJ5Wy2" Content-Disposition: inline In-Reply-To: <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 10:45:43 -0000 --hI0LKvM4dmXJ5Wy2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 11, 2018 at 12:32:00PM +0200, BERTRAND Jo=EBl wrote: > ... > I use a diskless workstation. With re driver provided by FreeBSD kernel > (9/10/11.x), system randomly crashed because ethernet driver stalls (and > datarate is always less than 300mbps). With official realtek driver > (v194.01), system now runs as expected (with datarate up to 1 Gbps). >=20 > Internal re driver is broken on this ethernet adapter (maybe on several > other adapters) : >=20 > re0@pci0:2:0:0: class=3D0x020000 card=3D0x78511462 chip=3D0x816810ec rev= =3D0x0c > hdr=3D0x00 > vendor =3D 'Realtek Semiconductor Co., Ltd.' > device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Contro= ller' > class =3D network > subclass =3D ethernet >=20 > Regards, >=20 > JKB > .... In counterpoint, my build machine for the last few years has been a Dell mini-tower I bought from Costco... with its original disk drive removed (replaced by an SSD, then supplemented with 3 more for a poudriere scratch-space). It runs a GENERIC kernel, tracking stable/11 & head daily, using poudriere to build local packages weekly, and acting as an NFS server for my "production" machines for their weekly updates. Its NIC: re0@pci0:3:0:0: class=3D0x020000 card=3D0x05b71028 chip=3D0x816810ec rev=3D= 0x0c hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet freebeast(11.1-S)[2] ifconfig re0 re0: flags=3D8843 metric 0 mtu 1500 options=3D8209b ether 98:90:96:d6:c9:6d hwaddr 98:90:96:d6:c9:6d inet 172.16.8.10 netmask 0xffffff00 broadcast 172.16.8.255=20 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active freebeast(11.1-S)[3]=20 (It is connected to a "dumb" 16-port Netgear gigabit switch.) I will admit that I avoid having the machine try to do too much else while the production machines are using it as an NFS server (serving /usr/src & /usr/obj, while (e.g.) "make installworld" runs on the production machines), but other than that, I have no issues involving performance and behavior of the NIC and its driver. Peace, david --=20 David H. Wolfskill david@catwhisker.org Well, what did you EXPECT from Trump? He has a history of breaking promise= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --hI0LKvM4dmXJ5Wy2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlrN501fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7hdrCwgA0g7vKNdRGYyATMu36uGuf8ulwaiuu3cAFMu6fLiKpxtZ0jn861x11hUL ITIuMPn+abI6G2cVtE+Mvqk8bizcEP+ls57Ku+bSJ+xACfURIs6o5mvSt/wswbU7 sXyhDS3mSf3XHxDrqK7T8S660rWdGIqoXS4euFzCPqRrgq0wMegGKQFpbh9/MtVD NQNZ4I5C2Z5HDYcLF9VApQWLxaglwHlg8QpVe/LbD1RElHDPCc/kx76WW+y24PBL aLQSZsUlXqdVB8NfeMEsdEXYlhZcwv1QBWoiNG/IE/sf4M3PBEt3QRbiw6pW/sI9 hkK2byILX2sW96Po5hGtqdiOL4337Q== =CjKr -----END PGP SIGNATURE----- --hI0LKvM4dmXJ5Wy2-- From owner-freebsd-hackers@freebsd.org Wed Apr 11 06:30:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BAD5F9B8B4 for ; Wed, 11 Apr 2018 06:30:54 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from lisa.milos.co.za (lisa.milos.co.za [109.169.49.137]) by mx1.freebsd.org (Postfix) with SMTP id 801DA7C7C6 for ; Wed, 11 Apr 2018 06:30:53 +0000 (UTC) (envelope-from clay@milos.co.za) Received: (qmail 65790 invoked by uid 89); 11 Apr 2018 06:24:10 -0000 Received: from unknown (HELO roundcube) (172.16.15.33) by vpopmail with SMTP; 11 Apr 2018 06:24:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Apr 2018 08:24:10 +0200 From: clay@milos.co.za To: Dieter BSD Cc: freebsd-usb@freebsd.org, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, owner-freebsd-usb@freebsd.org Subject: Re: AX88179 USB-to-Ethernet is slow and silently corrupts data In-Reply-To: References: Message-ID: <2cb00163a4b0165f6f05dff56a20ae56@milos.co.za> X-Sender: clay@milos.co.za User-Agent: Roundcube Webmail/1.3.3 X-Mailman-Approved-At: Wed, 11 Apr 2018 10:49:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 06:30:54 -0000 I have one of these (I think it's the same chipset, I know it's AX88xxx) and I've used it before without issue. If I can find it at home and it's the same chipset I'll give it a whirl and check to confirm that it's not a hardware issue. Problem with these cheap USB-whatever adapters is that the quality control is not always server class :=) \\Clay On 2018-04-11 00:54, Dieter BSD wrote: > 10.3-RELEASE > amd64 with ECC memory > VIA VL805 USB 3.0 controller > ue0 is Siig USB-to-Ethernet Chipset: AX88179 > > ugen0.7: at usbus0, cfg=0 md=HOST > spd=SUPER (5.0Gbps) pwr=ON (124mA) > > ue0: flags=8c43 metric > 0 > mtu 1500 > options=8000b > inet 10.0.210.66 netmask 0xffffff00 broadcast 10.0.210.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > If media is set to "1000baseT " it "works", but slowly, > and > received data is silently corrupted. :-( Transmitted data is not > corrupted (tested with > 30 GB). > > ifconfig ue0 -txcsum > "works", but still gives silent data corruption > > ifconfig ue0 -rxcsum (acts the same with or without txcsum) > ping out > netstat sees packets both directions, but ping doesn't see the > response: > 8 packets transmitted, 0 packets received, 100.0% packet loss > ping in > netstat sees packets in, but no responses going out > > I can see that some Ethernet controllers would not support checksum > offloading, > but it seems to me that turning the checksum offloading off should > always > work? (at the expense of more cpu load) > > Previously (2016 May): > # ifconfig ue0 media 100baseTX-FDX > fixed the input error problem and the data corruption problem, > at the expense of making it even slower. > > Sent data from machine A with 10Mbps Ethernet. (Netgear Ethernet > switch > converts 10Mbps to 1000Mbps) Netstat did not report any input errors > on > ue0 and there was no data corruption. So ue0 can handle gigabit data > rate, > but gets input errors if packets arrive too frequently. > > I tried moving it to a USB-2 port. No data corruption, but USB-2 is > slow. > > The chip performs a lot better for tweaktown: > > http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-network-adapter-review/index.html > (Vantec CB-U300GNA with the same Asix AX88179 chip) > "full duplex gigabit with 952 Mbps consistently across the chart" > > http://www.vantecusa.com/products_detail.php?p_id=143&p_name=USB+3.0+Gigabit+Ethernet+Adapter&pc_id=21&pc_name=Network&pt_id=5&pt_name=Accessories > > Asix AX88179 chip: > http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112 > "Supports Jumbo frame up to 4KB" > > But ifconfig rejects any value > 1500: > ifconfig ue0 mtu 1501 > ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument > > I tried mtu of 100, 500, 1000, 1400 but they all give > rcp: lost connection > > USB disks are fast, so the USB controller seems to work ok. > > I also tried a Tek Republic TUN-300 which has the same AX88179, > and it acts the same as the Siig. > > So, transmit works, but is slow. Receive works if the amount of > traffic > is low enough (limit rate of data sent, limit Ethernet speed, or > use USB-2). But if data is received too fast it gets silently > corrupted. > Setting -rxcsum does not work, and cannot set mtu other than 1500. > > Questions: > Why does -rxcsum not work? > Why does attempting to set a larger mtu fail? > Why does setting a smaller mtu make rcp fail? > Why is the chip acting slow? > How do I get it to work properly? (fast and without data corruption) > _______________________________________________ > freebsd-usb@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Wed Apr 11 07:10:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3D9CF9E739; Wed, 11 Apr 2018 07:10:46 +0000 (UTC) (envelope-from vterziev@gvcgroup.com) Received: from mgate03.itsfogo.com (mgate03.itsfogo.com [195.72.134.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.itsfogo.com", Issuer "thawte SSL CA - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4656D8750F; Wed, 11 Apr 2018 07:10:45 +0000 (UTC) (envelope-from vterziev@gvcgroup.com) From: Vladimir Terziev To: Dieter BSD CC: "freebsd-net@freebsd.org" , "freebsd-drivers@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Realtek re(4) driver Thread-Topic: Realtek re(4) driver Thread-Index: AQHT0R8OI42h+gu5D0y7MqkwOTG+kqP7AGUA Date: Wed, 11 Apr 2018 06:55:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-originating-ip: [10.138.239.10] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Apr 2018 10:50:14 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 07:10:47 -0000 SGkgRGlldGVyLA0KDQppIGhhdmUgbWFuYWdlZCB0byBkb3dubG9hZCB0aGUgZHJpdmVyIGZyb20g dGhlIGxpbmsgdGhhdCB5b3UgcHJvdmlkZWQgYnkganVzdCBjbGlja2luZyB0aGUg4oCcR2xvYmFs 4oCdIGxpbmsuDQoNCkp1c3QgbGV0IG1lIGtub3cgaWYgeW91IHdhbnQgbWUgdG8gc2VuZCBpdCB0 byB5b3UuDQoNCg0KUmVnYXJkcywNCg0KVmxhZGltaXINCg0KDQo+IE9uIDExIEFwciAyMDE4LCBh dCAwMTo1MCwgRGlldGVyIEJTRCA8ZGlldGVyYnNkQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBN dWx0aXBsZSBwZW9wbGUgaGF2ZSBmb3VuZCB0aGF0IEZyZWVCU0QncyByZSg0KSBkcml2ZXIgZm9y IFJlYWx0ZWsNCj4gRXRoZXJuZXQgY2hpcHMgaGFzIHByb2JsZW1zLiAgU29tZXRoaW5nIGxpa2Ug YSByY3AoMSkgd2l0aCBhbm90aGVyDQo+IEZyZWVCU0QgYm94IG1lcmVseSBydW5zIHNsb3dlciBk dWUgdG8gdGhlIHN0YWxscywgYnV0IGlmIHRoZSBvdGhlciBlbmQNCj4gaGFzIGJ1Z2d5IG5ldHdv cmsgY29kZSBhbmQvb3IgaWYgdGhlIHRyYW5zZmVyIGlzIGZvcmNlZCB0byB1c2UgVURQDQo+IChV bnJlbGlhYmxlIERhdGEgUHJvdG9jb2wpIGRhdGEgaXMgbG9zdC4gIDotKA0KPiANCj4gUnVtb3Ig aGFzIGl0IHRoYXQgUmVhbHRlayBoYXMgYSBkcml2ZXIgdGhhdCB3b3JrcyBwcm9wZXJseSB3aXRo IEZyZWVCU0QuDQo+IA0KPiBGcmVlQlNEJ3MgZGV2ZWxvcGVycyBhcmUgYXBwYXJlbnRseSB1bmFi bGUgdG86DQo+IGEpIEZpeCB0aGUgZXhpc3RpbmcgRnJlZUJTRCByZSg0KSBkZXZpY2UgZHJpdmVy IHNvIHRoYXQgaXQgd29ya3MgY29ycmVjdGx5Lg0KPiBiKSBSZXBsYWNlIHRoZSBleGlzdGluZyBG cmVlQlNEIHJlKDQpIGRldmljZSBkcml2ZXIgd2l0aCBSZWFsdGVrJ3MgZHJpdmVyLg0KPiBjKSBN YWtlIFJlYWx0ZWsncyBkcml2ZXIgaW50byBhIHBvcnQvcGtnLg0KPiBkKSBBdCBsZWFzdCBhZGQg YSB3YXJuaW5nIHRvIHRoZSByZSg0KSBtYW4gcGFnZSwgd2l0aCB0aGUgVVJMIGZvcg0KPiAgIFJl YWx0ZWsncyBkcml2ZXIuDQo+IA0KPiBUaGVyZWZvcmUgZXZlcnkgdXNlciB3aXRoIFJlYWx0ZWsg RXRoZXJuZXQgY2hpcHMgYXJlIGZvcmNlZCB0byBzb21laG93DQo+IGRpc2NvdmVyIHRoYXQgUmVh bHRlayBoYXMgYSB3b3JraW5nIGRyaXZlciwgdGhlbiBzb21laG93IG9idGFpbiBhIGNvcHkNCj4g b2YgdGhpcyBteXRoaWNhbCBkcml2ZXIsIGdldCBpdCB0byBjb21waWxlIGFuZCBidWlsZCBhIGN1 c3RvbSBrZXJuZWwuDQo+IFRoZXkgdGhlbiBuZWVkIHRvIHdyaXRlIGEgdGVzdCBzdWl0ZSBhbmQg dmVyaWZ5IHRoYXQgUmVhbHRlaydzIGRyaXZlcg0KPiBkb2VzIGluIGZhY3Qgd29yayBwcm9wZXJs eSBmb3IgdGhlaXIgYXBwbGljYXRpb25zLg0KPiANCj4gSSBhbSBjdXJyZW50bHkgc3VmZmVyaW5n IGRhdGEgbG9zcyBkdWUgdG8gdGhpcy4gIFRoZXJlZm9yZSBJIGFtDQo+IGF0dGVtcHRpbmcgdG8g b2J0YWluIGEgY29weSBvZiB0aGUgbXl0aGljYWwgUmVhbHRlayBkZXZpY2UgZHJpdmVyLg0KPiBJ IG1hbmFnZWQgdG8gZmluZA0KPiANCj4+IGh0dHA6Ly93d3cucmVhbHRlay5jb20udHcvRG93bmxv YWRzL2Rvd25sb2Fkc1ZpZXcuYXNweD9MYW5naWQ9NCZQTmlkPTEzJlBGaWQ9NSZMZXZlbD01JkNv bm49NCZEb3duVHlwZUlEPTMmR2V0RG93bj1mYWxzZQ0KPiANCj4gQnV0IGl0IGRvZXMgbm90IHdv cmsgZm9yIG1lLiAgSXQgaGFzIGEgbGlzdGluZyBmb3INCj4gDQo+PiBEZXNjcmlwdGlvbiAgICAg ICAgIFZlcnNpb24gVXBkYXRlIFRpbWUgRmlsZSBTaXplIERvd25sb2FkIFNpdGUgMQ0KPj4gRnJl ZUJTRCA3LnggYW5kIDguMCAxLjk0ICAgIDIwMTcvOS8xNSAgIDkzayAgICAgICBHbG9iYWwNCj4g DQo+IFRoZSBtYWNoaW5lIHdpdGggdGhlIHJlIHBvcnRzIGlzIHJ1bm5pbmcgMTAuMywgaG9wZWZ1 bGx5IHRoZSA3JjggY29kZQ0KPiB3aWxsIGNvbXBpbGUgYW5kIHdvcmsgb24gMTAuICBCdXQgdGhl IHJlYWwgcHJvYmxlbSBpcyB0aGF0IGNsaWNraW5nIG9uDQo+ICJHbG9iYWwiIGRvZXMgbm90IHdv cmsuICBTb21lIGJyb3dzZXJzIGRvIG5vdGhpbmcuICBGaXJlZm94IGNyZWF0ZXMNCj4gYSBuZXcg d2luZG93IHdpdGggaHR0cDovL3d3dy5yZWFsdGVrLmNvbS50dy9kb3dubG9hZHMvDQo+IHdoaWNo IGlzIGdvaW5nIGJhY2t3YXJkcy4gIEkgd2FzIGV4cGVjdGluZyBzb21ldGhpbmcgbGlrZSBhIHRh ciBmaWxlDQo+IGNvbnRhaW5pbmcgdGhlIHNvdXJjZSBjb2RlLg0KPiANCj4gSSBhbHNvIHRyaWVk IGdvb2dsZSwgYW5kIGVtYWlsaW5nIGEgRnJlZUJTRCB1c2VyIHRoYXQgcnVucyB0aGUgUmVhbHRl aw0KPiBkcml2ZXIsIGJ1dCBib3RoIHBvaW50ZWQgbWUgdG8gdGhlIGFib3ZlIG5vbi13b3JraW5n IFVSTC4gIEknbQ0KPiB0b2xkIHRoYXQgc2VhbW9ua2V5IHdvcmtzLCBidXQuLi4NCj4gDQo+IFNv IG15IHF1ZXN0aW9uIGlzOiBjb3VsZCBzb21lb25lIHBsZWFzZSB0ZWxsIG1lIHRoZSBVUkwgdGhh dCBwb2ludHMNCj4gKmRpcmVjdGx5KiB0byB0aGUgbXl0aGljYWwgUmVhbHRlayBkZXZpY2UgZHJp dmVyPyAgKHdpdGhvdXQNCj4gdGhlIGJyb2tlbiBqYXZhc2NoZWlzdCBnYXJiYWdlKQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLW5l dEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtbmV0DQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBt YWlsIHRvICJmcmVlYnNkLW5ldC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg0K From owner-freebsd-hackers@freebsd.org Wed Apr 11 10:57:56 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D64C0F89C74 for ; Wed, 11 Apr 2018 10:57:55 +0000 (UTC) (envelope-from ale@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 5833B74928 for ; Wed, 11 Apr 2018 10:57:55 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 09F90F89C67; Wed, 11 Apr 2018 10:57:55 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA3B2F89C62 for ; Wed, 11 Apr 2018 10:57:54 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (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 496BB74903 for ; Wed, 11 Apr 2018 10:57:53 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 7686 invoked from network); 11 Apr 2018 10:51:10 -0000 Received: from 151-0-207-195.ip282.fastwebnet.it (HELO ale.bitgold.com) (sysadmin@alexdupre.com@151.0.207.195) by lab.alexdupre.com with ESMTPSA; 11 Apr 2018 10:51:10 -0000 Subject: Re: Realtek re(4) driver To: hackers@freebsd.org, =?UTF-8?Q?BERTRAND_Jo=c3=abl?= References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> From: Alex Dupre Openpgp: preference=signencrypt Autocrypt: addr=ale@FreeBSD.org; prefer-encrypt=mutual; keydata= xsDiBDd2Z60RBADHdQ8600NP2/sBbuIW87WqWXZyzDX0Q6AA/czBlV2PKiEhCgTJwZCWJMs/ iR0GgfS3LKYd/eWW48LYj2V/0YjafV/A2B6+1QsVGltXunvtYxC4GnCStzPqsI624jgtwZ5s b8oowOv5ykEVw6lxneRuluymOq3YFxhRfjJ3koNYUwCg/9ouKUPZ3hPNklVoLPAnN+dF3gsE AIxacljfmb3KQ2bnngkhvASu7g0Ipjql2k1AiBwC1oWnsMIYX5qNBLA+6FtAGFYqrT8hV5qR OJyNPVeVKj3p+wt23Co/t/w0gaLccu2JlI6QBFerCNFcqNMgzEAbQ8ARxSrLW/THpOJ8i32z 0AKEtx/1LdYlcFB+l+8FLuKgEgXMA/9RmwjhPmZ/V5xUXW6mrkSfRDtxRsEegaixqUI6Smsk gGgsQybjSc0fxWtlMCKZ4sIqtykPAlf5fGeX+FjYyR6iFnjfJwRFxilLGokqaDEZeE9myB2M ue9YnFoSGB12c6U8HRf4R86uk4tWwzMO70Gyt3bSp2GTXeMiuy7dibKIRs0jQWxleCBEdXBy ZSA8c3lzYWRtaW5AYWxleGR1cHJlLmNvbT7CWwQQEQIAGwYLCQgHAwIDFQIDAxYCAQIeAQUC P+1Q8AIZAQAKCRCBFenYzl9VTRlbAKCtuTeluUEd+myJSy1lFvvNODsMpQCcCO41HyRSAcpx lRAgIzsbPsCXap/OwU0EN3ZnrhAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGn VqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biu dE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3k kQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq /zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqr ol7DVekyCzsAAgIH/iI5BFMs9qKaY0uKL+BThmHy7iIBO0OeQxj2V0idDRBPiqsr39tF7+Oe kdOWtOZop3jwH7AMGhSNTX0RsWXQU3V7Zm6bag4Ep8TCvxSnq2YFj2+zEKypjrl8/jfY/ewg usuH+TzXCpVeG4S9TGmRtky0R48ssKXf0bpFcPYzyp7kuwiCMUf5ry4JHB1RaAUO/9HgenAo 2TlTq7kmaHddaH86gc+yFZXUB9tQUJVLC667avuDZXNWEFtap2VN8uwK9/wkFuZbAFA6PT0X UhA32FnNfFrn4rkN1pK4VdRGCVOlGc41PBuQ/AzfvnbqH+1UB/eBIoES2DWM+94tV0rGgYrC TgQYEQIABgUCN3ZnrgASCRCBFenYzl9VTQdlR1BHAAEB780AnAgv6qjJ/DFiidAm4l4k0ru3 aaI2AJ47Ja6Tgzc0p7UUOaytEmsCV7FlpA== Message-ID: <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> Date: Wed, 11 Apr 2018 12:51:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180411104533.GC1134@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 10:57:56 -0000 David Wolfskill wrote: >> I use a diskless workstation. With re driver provided by FreeBSD kernel >> (9/10/11.x), system randomly crashed because ethernet driver stalls (and >> datarate is always less than 300mbps). With official realtek driver >> (v194.01), system now runs as expected (with datarate up to 1 Gbps). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 Anyone interested in taking the bounty or contributing to it? Perhaps the FreeBSD Foundation should jump in? -- Alex Dupre From owner-freebsd-hackers@freebsd.org Wed Apr 11 10:58:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9293F89CDD for ; Wed, 11 Apr 2018 10:58:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6913074D17 for ; Wed, 11 Apr 2018 10:58:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1f6DS8-000DUK-Q3 for freebsd-hackers@freebsd.org; Wed, 11 Apr 2018 13:58:12 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: sys/conf/newvers.sh Message-Id: Date: Wed, 11 Apr 2018 13:58:12 +0300 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 10:58:25 -0000 hi, while trying to get newvers.sh to work for me (I have the freebsd = sources tracked via svn/hg) i solved one issue: the path should not contain .hg but then I found a new one :-( hg -R /path/src svn info gives the first/oldest info, so hg -R /path/to/src svn info -r tip gives the latest (and correct revision) So, if this is working ok for others, then I have a problem with hg/svn, = or else I=E2=80=99m missing something. thanks, danny From owner-freebsd-hackers@freebsd.org Wed Apr 11 13:54:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E9FDF96540 for ; Wed, 11 Apr 2018 13:54:37 +0000 (UTC) (envelope-from gljennjohn@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 1A8107B981 for ; Wed, 11 Apr 2018 13:54:37 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id CDCEEF9653F; Wed, 11 Apr 2018 13:54:36 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A31D7F9653E for ; Wed, 11 Apr 2018 13:54:36 +0000 (UTC) (envelope-from gljennjohn@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 110D07B963 for ; Wed, 11 Apr 2018 13:54:36 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id x4so3937043wmh.5 for ; Wed, 11 Apr 2018 06:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=YKXZ6ShiMCBog8lgRYbWjFXFlli69wJWpVHiOqEgHao=; b=Jtpje70j2IaV5l3YOyqpJ9Y5oXPx6+yIKzvcU2Appkyq7lLUH1mCptMDlpDYIJoX6q 7uzutS0AFIrU9seYJPwaRCPIQZswKWkN+GYoPPKypgbLYZw0S8I8w7xi6nfoyABeA6Y1 iEjvhlT8AEEtnZrmrpu2/TXQrZm041r02HtbPyp8tG8VQFXhHlG41JpBr56QxZxVGwdL zoPMU6UGZE+dZn9Hj0gqZyT9iVdB2sIXoAyp0JMwHaU694NWQs60J4eYarIRrPv6t5HP WiNewgBoPQtGBAPHn8ShsOpz14hDRXlHQIaZh/N7kH24R+sfaEVPq4PzE3ga8FZKLz4P /hLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=YKXZ6ShiMCBog8lgRYbWjFXFlli69wJWpVHiOqEgHao=; b=bFkjsR9kjJuHoIKqZK3YiOlx9DzOrLxbgtyuqWbx/IkGy0ivAs+kdCmHsQuQTNV12k DcluMCC3FpopbskC847pAXRMPKu7IzUQCO+Q3D2bkKzOJTRHbZhDxvCZvSQ83Yq4rK/O IHzQZeUTsI5GySQw8M5mN/Wn6Gr9Dq3UzSZKKl/1qoLvtadntZa/7CNkXWsR9aZ3fxrb 6MZFzuki3OVtUOvBjRaaDjZ6TVqwov5CrKBf8uPcy80kkqnFbal8oAL940hzYUo7FXc1 lYwrcYO2S75BVC9Hwiw5BVY+ZM6HB1Nvn4JfsYP+iXcpPBUa5gevDQz5E+eOhiDJ/J7Z jx8A== X-Gm-Message-State: ALQs6tAlFle23VX06ivPGiNPbgoqxr/cOwdfV6L+46QnKdraWRVunxlF GbQr38PD5m5K/jNrF18ERqZIgA== X-Google-Smtp-Source: AIpwx4+5fqhGiUWHQ5Vm3n6VMdFf7UF4nTJX6TDP0ENLGeNueBMPWwS+8G9L0Fes9e3/xqK56Yo/7w== X-Received: by 10.28.232.202 with SMTP id f71mr3057808wmi.136.1523454874500; Wed, 11 Apr 2018 06:54:34 -0700 (PDT) Received: from ernst.home (pD9E23019.dip0.t-ipconnect.de. [217.226.48.25]) by smtp.gmail.com with ESMTPSA id t76sm2581943wme.17.2018.04.11.06.54.33 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Apr 2018 06:54:33 -0700 (PDT) Date: Wed, 11 Apr 2018 15:54:32 +0200 From: Gary Jennejohn To: hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <20180411155432.78b23bbe@ernst.home> In-Reply-To: <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 13:54:37 -0000 On Wed, 11 Apr 2018 12:51:09 +0200 Alex Dupre wrote: > David Wolfskill wrote: > >> I use a diskless workstation. With re driver provided by FreeBSD kernel > >> (9/10/11.x), system randomly crashed because ethernet driver stalls (and > >> datarate is always less than 300mbps). With official realtek driver > >> (v194.01), system now runs as expected (with datarate up to 1 Gbps). > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 > > Anyone interested in taking the bounty or contributing to it? Perhaps > the FreeBSD Foundation should jump in? > Reading the bugzilla shows that this is a comples problem with no obvious error source. One poster notes that he could transfer 300+GB of data error-free using rsync, but with NFS he encountered problesm after a few GB. To me this is an indictment of the NFS implementation used and not of the re driver itself. The same goes for some other posts. Everyone blames re, but AFAICT no-one switched to a non-Realtek chip to run tests and prove that, yes, re is really the cause of all the network problems. I've been using re for many years in various incarnations - PCIe cards and integrated on the mainboard. I've never experienced any network instabilities. But I've never used one in a NFS server under FBSD. I do, however, have one in a Linux NFS server (which was at one time my primary FBSD box) and never observed any problems. In summary, this is one tough nut to crack. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Apr 11 14:12:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7028F97AA5 for ; Wed, 11 Apr 2018 14:12:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.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 4195C7EFD9 for ; Wed, 11 Apr 2018 14:12:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 024BCF97AA4; Wed, 11 Apr 2018 14:12:44 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3B5DF97AA3 for ; Wed, 11 Apr 2018 14:12:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E0F77EFD5; Wed, 11 Apr 2018 14:12:42 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w3BECXhm028057; Wed, 11 Apr 2018 07:12:33 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w3BECXhb028056; Wed, 11 Apr 2018 07:12:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804111412.w3BECXhb028056@pdx.rh.CN85.dnsmgr.net> Subject: Re: Realtek re(4) driver In-Reply-To: <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> To: Alex Dupre Date: Wed, 11 Apr 2018 07:12:33 -0700 (PDT) CC: hackers@freebsd.org, =?UTF-8?Q?BERTRAND_Jo=C3=ABl?= X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:12:44 -0000 > David Wolfskill wrote: > >> I use a diskless workstation. With re driver provided by FreeBSD kernel > >> (9/10/11.x), system randomly crashed because ethernet driver stalls (and > >> datarate is always less than 300mbps). With official realtek driver > >> (v194.01), system now runs as expected (with datarate up to 1 Gbps). > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 I have put that bug back on a public bug list (net@freebsd.org) so that it appears in the nag mails sent out periodically. I think I might have some of that hardware around here, but not sure if it is that specific chip. I do know that some "re(4)" cards work just fine with FreeBSD, but others have issues, I suspect the ones that have issues are ones that have hardware bugs that need a specific software work around. I do have this: re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' and I use that pretty regular, including NFS, but rarely push more than 1 or 2 gigabyte through it in any one operation. (src tree size chunks go in and out of that box). > Anyone interested in taking the bounty or contributing to it? Perhaps > the FreeBSD Foundation should jump in? > > -- > Alex Dupre -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Apr 11 14:35:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04E25F99482 for ; Wed, 11 Apr 2018 14:35:34 +0000 (UTC) (envelope-from mike@sentex.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 949EA84951 for ; Wed, 11 Apr 2018 14:35:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: by mailman.ysv.freebsd.org (Postfix) id 53DCFF99481; Wed, 11 Apr 2018 14:35:33 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 424EFF99480 for ; Wed, 11 Apr 2018 14:35:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 29B5D8494E; Wed, 11 Apr 2018 14:35:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w3BEZVRB007619 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Apr 2018 10:35:31 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w3BEZTga066400; Wed, 11 Apr 2018 10:35:29 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Realtek re(4) driver To: "Rodney W. Grimes" , Alex Dupre Cc: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= , hackers@freebsd.org References: <201804111412.w3BECXhb028056@pdx.rh.CN85.dnsmgr.net> From: Mike Tancsa Openpgp: preference=signencrypt Organization: Sentex Communications Message-ID: <74f139e0-4e6b-6efb-eff2-752997dce3b0@sentex.net> Date: Wed, 11 Apr 2018 10:35:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201804111412.w3BECXhb028056@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:35:34 -0000 On 4/11/2018 10:12 AM, Rodney W. Grimes wrote: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 > > I have put that bug back on a public bug list (net@freebsd.org) so > that it appears in the nag mails sent out periodically. > > I think I might have some of that hardware around here, but not sure > if it is that specific chip. I do know that some "re(4)" cards > work just fine with FreeBSD, but others have issues, I suspect the > ones that have issues are ones that have hardware bugs that need > a specific software work around. Over the years I have had mixed results with re nics. Some work as expected, others with issues. I think a big part of the problem is that there are so many varieties out there. That being said, I run into similar issues on Linux from time to time with these NICs, so its not just a FreeBSD problem. Just the other week, on a new MSI RYZEN board (MS-7A34), I found I could wedge the onboard NIC without too much effort doing some network stress tests. (kernel is 4.4.0-119). Havent tried this board on FreeBSD however. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-hackers@freebsd.org Wed Apr 11 15:19:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97227F9CB9C for ; Wed, 11 Apr 2018 15:19:23 +0000 (UTC) (envelope-from ale@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 1C1986FFF8 for ; Wed, 11 Apr 2018 15:19:23 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CB598F9CB9B; Wed, 11 Apr 2018 15:19:22 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F46CF9CB9A for ; Wed, 11 Apr 2018 15:19:22 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (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 F06676FFF6 for ; Wed, 11 Apr 2018 15:19:21 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 11423 invoked from network); 11 Apr 2018 15:19:18 -0000 Received: from 151-0-207-195.ip282.fastwebnet.it (HELO ale.bitgold.com) (sysadmin@alexdupre.com@151.0.207.195) by lab.alexdupre.com with ESMTPSA; 11 Apr 2018 15:19:18 -0000 Subject: Re: Realtek re(4) driver To: gljennjohn@gmail.com, hackers@freebsd.org References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> <20180411155432.78b23bbe@ernst.home> From: Alex Dupre Openpgp: preference=signencrypt Autocrypt: addr=ale@FreeBSD.org; prefer-encrypt=mutual; keydata= xsDiBDd2Z60RBADHdQ8600NP2/sBbuIW87WqWXZyzDX0Q6AA/czBlV2PKiEhCgTJwZCWJMs/ iR0GgfS3LKYd/eWW48LYj2V/0YjafV/A2B6+1QsVGltXunvtYxC4GnCStzPqsI624jgtwZ5s b8oowOv5ykEVw6lxneRuluymOq3YFxhRfjJ3koNYUwCg/9ouKUPZ3hPNklVoLPAnN+dF3gsE AIxacljfmb3KQ2bnngkhvASu7g0Ipjql2k1AiBwC1oWnsMIYX5qNBLA+6FtAGFYqrT8hV5qR OJyNPVeVKj3p+wt23Co/t/w0gaLccu2JlI6QBFerCNFcqNMgzEAbQ8ARxSrLW/THpOJ8i32z 0AKEtx/1LdYlcFB+l+8FLuKgEgXMA/9RmwjhPmZ/V5xUXW6mrkSfRDtxRsEegaixqUI6Smsk gGgsQybjSc0fxWtlMCKZ4sIqtykPAlf5fGeX+FjYyR6iFnjfJwRFxilLGokqaDEZeE9myB2M ue9YnFoSGB12c6U8HRf4R86uk4tWwzMO70Gyt3bSp2GTXeMiuy7dibKIRs0jQWxleCBEdXBy ZSA8c3lzYWRtaW5AYWxleGR1cHJlLmNvbT7CWwQQEQIAGwYLCQgHAwIDFQIDAxYCAQIeAQUC P+1Q8AIZAQAKCRCBFenYzl9VTRlbAKCtuTeluUEd+myJSy1lFvvNODsMpQCcCO41HyRSAcpx lRAgIzsbPsCXap/OwU0EN3ZnrhAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGn VqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biu dE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3k kQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq /zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqr ol7DVekyCzsAAgIH/iI5BFMs9qKaY0uKL+BThmHy7iIBO0OeQxj2V0idDRBPiqsr39tF7+Oe kdOWtOZop3jwH7AMGhSNTX0RsWXQU3V7Zm6bag4Ep8TCvxSnq2YFj2+zEKypjrl8/jfY/ewg usuH+TzXCpVeG4S9TGmRtky0R48ssKXf0bpFcPYzyp7kuwiCMUf5ry4JHB1RaAUO/9HgenAo 2TlTq7kmaHddaH86gc+yFZXUB9tQUJVLC667avuDZXNWEFtap2VN8uwK9/wkFuZbAFA6PT0X UhA32FnNfFrn4rkN1pK4VdRGCVOlGc41PBuQ/AzfvnbqH+1UB/eBIoES2DWM+94tV0rGgYrC TgQYEQIABgUCN3ZnrgASCRCBFenYzl9VTQdlR1BHAAEB780AnAgv6qjJ/DFiidAm4l4k0ru3 aaI2AJ47Ja6Tgzc0p7UUOaytEmsCV7FlpA== Message-ID: Date: Wed, 11 Apr 2018 17:19:18 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180411155432.78b23bbe@ernst.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 15:19:23 -0000 Gary Jennejohn wrote: > Reading the bugzilla shows that this is a comples problem with no > obvious error source. > > One poster notes that he could transfer 300+GB of data error-free > using rsync, but with NFS he encountered problesm after a few GB. > To me this is an indictment of the NFS implementation used and > not of the re driver itself. I agree that is a complex problem with a non obvious solution, I have also used many re cards successfully and others not, but surely it's not a NFS issue. I can tell you more, I've used successfully a re card for years, and started seeing issues with the same card after upgrading my upstream connection to gigabit. The only thing that link all bug reports (and there are tons) is the use of re card sustaining gigabit (duplex) transfers. And I couldn't find similar reports for other chipsets that might lead to think it's a generic FreeBSD issue. Everything is possible, but the main suspect is the re driver. -- Alex Dupre From owner-freebsd-hackers@freebsd.org Wed Apr 11 17:22:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C997EF80F81 for ; Wed, 11 Apr 2018 17:22:39 +0000 (UTC) (envelope-from gljennjohn@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 5BC7B6B984 for ; Wed, 11 Apr 2018 17:22:39 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 15A3AF80F77; Wed, 11 Apr 2018 17:22:39 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF691F80F76 for ; Wed, 11 Apr 2018 17:22:38 +0000 (UTC) (envelope-from gljennjohn@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 4E2BA6B978 for ; Wed, 11 Apr 2018 17:22:38 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id g8so5732163wmd.2 for ; Wed, 11 Apr 2018 10:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=EvozkIcQfuzE49nf1nxIziphjsl1+QYgImLdsfHuTKs=; b=stiZEB9o0LXv7et/MMgj70OlRpMqoAtrp3tC/dC/uMCF4YC86OqRNoTUk4tEjOs/LZ Q7wcAq4y+CizPQOI4My3arFM9aKn5B3lqnepDwqBu+lnSS6piz4GDptvf79AzkBxRGs5 9V0PfmlezBaWpgex0iKemozpgDTJ5trI6QFqYQWkkIMFl7KeF9Q77awIvnywudR5zejf zcl+L75zHXT9gce2WQ4LcOETqAYr3fG6rAWhz0iX5RLmMJPjnGz0bkMJ+IZ2oI3ielH2 VvztgcrIPSKj5IWS7yjQ9FB3M5FGlRbA07iaqn8PKtYLBN6KHLdSIMdsKMFCJuVJL39s HFlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=EvozkIcQfuzE49nf1nxIziphjsl1+QYgImLdsfHuTKs=; b=SOw/8sdXQDcHNNswVco7XeDz6VHRfol5pNeZpAiov+nVkGQpgBd8C4tSEFI8R5V41a Kq2V4sIprzXDhVOSXsEeQyDleGQWVzCYGkENA2VWAaQJ1X0Lh1lG0htt2w4ibUEcB3hs Ue6Kw9WQTCNYv+rpf2xfId0lHj8L2+fKhWC7JT9oMH7gzprlCF1D+Vb9wk3/ntADud5a dFfQLOswdmyIUHEYM3Zd4RLaVddXegnDIzpg2BRrpCiuA6x+xaTwHOB6Xw7NjM4i58RD qpmhUfJcC6vAdAbxSxiF1PLPXThDYD7lM9cYrL9jxX0sub0QFUhpE/NaaHatVp2HsQaX IFZA== X-Gm-Message-State: ALQs6tAmNGWUBWnKavSvG3JOWAIUOj8i19HUIAaafk8ZchM9z+RjgDgp klDKeSbJ3uxtvWlrF3Uc08H8bQ== X-Google-Smtp-Source: AIpwx48I0P8mVoSlrQLv3PRugygtgi6jZBGa+zHMdf4pFwW1kACQk0SF/Meii539Ypkhf5tZVMQGsw== X-Received: by 10.28.153.213 with SMTP id b204mr3479604wme.79.1523467356860; Wed, 11 Apr 2018 10:22:36 -0700 (PDT) Received: from ernst.home (pD9E23019.dip0.t-ipconnect.de. [217.226.48.25]) by smtp.gmail.com with ESMTPSA id t8sm1545564wmc.20.2018.04.11.10.22.35 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Apr 2018 10:22:36 -0700 (PDT) Date: Wed, 11 Apr 2018 19:22:35 +0200 From: Gary Jennejohn To: hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <20180411192235.3ff4d783@ernst.home> In-Reply-To: References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> <20180411155432.78b23bbe@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:22:40 -0000 On Wed, 11 Apr 2018 17:19:18 +0200 Alex Dupre wrote: > Gary Jennejohn wrote: > > Reading the bugzilla shows that this is a comples problem with no > > obvious error source. > > > > One poster notes that he could transfer 300+GB of data error-free > > using rsync, but with NFS he encountered problesm after a few GB. > > To me this is an indictment of the NFS implementation used and > > not of the re driver itself. > I agree that is a complex problem with a non obvious solution, I have > also used many re cards successfully and others not, but surely it's not > a NFS issue. I can tell you more, I've used successfully a re card for > years, and started seeing issues with the same card after upgrading my > upstream connection to gigabit. The only thing that link all bug reports > (and there are tons) is the use of re card sustaining gigabit (duplex) > transfers. And I couldn't find similar reports for other chipsets that > might lead to think it's a generic FreeBSD issue. Everything is > possible, but the main suspect is the re driver. > One thing which did seem common was checksum offloading. My cards don't seem to support that. My Linux NFS server is serving clients with 1Gbps links - never seen a problem. But the MTU is limited to 1500. The re in my FBSD box uses a MTU of 4808. I've transferred lots of data with a Linux device and a Windows machine also using that setting and never saw a problem. Maybe I'm just lucky. The Realtech Linux driver could be a place to start looking for useful changes. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Apr 11 17:34:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87B44F82130 for ; Wed, 11 Apr 2018 17:34:41 +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 360CE6D30E for ; Wed, 11 Apr 2018 17:34:41 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 8E62B141DC for ; Wed, 11 Apr 2018 17:34:40 +0000 (UTC) Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org References: From: Allan Jude Openpgp: preference=signencrypt Message-ID: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> Date: Wed, 11 Apr 2018 13:34:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yBp3oDMkBl3y2uwa2ZFKcSsMY4CYm7JgO" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:34:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yBp3oDMkBl3y2uwa2ZFKcSsMY4CYm7JgO Content-Type: multipart/mixed; boundary="ixyI2VglhJV56xSMmShiSj8CMqDMiBCyM"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> Subject: Re: Realtek re(4) driver References: In-Reply-To: --ixyI2VglhJV56xSMmShiSj8CMqDMiBCyM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-04-10 18:50, Dieter BSD wrote: > Multiple people have found that FreeBSD's re(4) driver for Realtek > Ethernet chips has problems. Something like a rcp(1) with another > FreeBSD box merely runs slower due to the stalls, but if the other end > has buggy network code and/or if the transfer is forced to use UDP > (Unreliable Data Protocol) data is lost. :-( >=20 > Rumor has it that Realtek has a driver that works properly with FreeBSD= =2E >=20 > FreeBSD's developers are apparently unable to: > a) Fix the existing FreeBSD re(4) device driver so that it works correc= tly. > b) Replace the existing FreeBSD re(4) device driver with Realtek's driv= er. > c) Make Realtek's driver into a port/pkg. > d) At least add a warning to the re(4) man page, with the URL for > Realtek's driver. >=20 > Therefore every user with Realtek Ethernet chips are forced to somehow > discover that Realtek has a working driver, then somehow obtain a copy > of this mythical driver, get it to compile and build a custom kernel. > They then need to write a test suite and verify that Realtek's driver > does in fact work properly for their applications. >=20 > I am currently suffering data loss due to this. Therefore I am > attempting to obtain a copy of the mythical Realtek device driver. > I managed to find >=20 >> http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=3D4&PNid= =3D13&PFid=3D5&Level=3D5&Conn=3D4&DownTypeID=3D3&GetDown=3Dfalse >=20 > But it does not work for me. It has a listing for >=20 >> Description Version Update Time File Size Download Site 1 >> FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global >=20 > The machine with the re ports is running 10.3, hopefully the 7&8 code > will compile and work on 10. But the real problem is that clicking on > "Global" does not work. Some browsers do nothing. Firefox creates > a new window with http://www.realtek.com.tw/downloads/ > which is going backwards. I was expecting something like a tar file > containing the source code. >=20 > I also tried google, and emailing a FreeBSD user that runs the Realtek > driver, but both pointed me to the above non-working URL. I'm > told that seamonkey works, but... >=20 > So my question is: could someone please tell me the URL that points > *directly* to the mythical Realtek device driver? (without > the broken javascheist garbage) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 I think it would be useful to collect the 'pciconf -lv' output of the re(4) devices that have issues, so they can be differentiated from the ones that work fine. This would be the first step to getting a developer setup with a reliable reproduction platform, so the bug could be tracked down. --=20 Allan Jude --ixyI2VglhJV56xSMmShiSj8CMqDMiBCyM-- --yBp3oDMkBl3y2uwa2ZFKcSsMY4CYm7JgO 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) iQIcBAEBAgAGBQJazkcwAAoJEBmVNT4SmAt+YlUP/3nCX999PiwnYQGZ2y5GCfeC HM1Re7ExSrprSYVxuHH6BnXK3/9//4B16wQzQjkLR9jIuPp148XYobvSoEzn9ERX mz8gibqc1dkT8XiI+fd8U96k6ZAOC2EsbPdg5sNaasx3YqIuRb1A1eFMClpA17Cs fB5Q5qDfGBN4/KX+vziQP9YoGDx+5F9ImJltV0uLoChxfxUSIBnymlQzJEf731xM nC5NZbdhgxPKevv4rWsja8pj+8TfUz/4A9FwgCqRVKWNkDL39sUMtUAzQyNCPBTM ZlaheDs9CNvjScq92ZGgJ//XL5daAsCeS6Z4tKpHiM5rIfpRbAD0Q9mJ0p9olQPI BrRHEQz8TUWs9/Y4Xe2x+EbeZBWzAecov9n1WKCKSQjoazyuxEn0rpCm9UX2Fy+z Jbxp2/t0nZe8Na831n1j6MfIq9aP3NLenPpcy3gAm5YC5jkX7+oyEa4VrqIu+jt+ eyFoCw5nYd2EleJCXVijyPuGplvyCC4lFsxTdUrxqHEdEgI59mo7iatjcqk3W4Qm 73H9+AiqGGEl/wK7rBQAhJ19R/d0ZYfyO5qKcTR3Av5XkUqMxeDoUZFwSoXi+BOP oyFtcLheDAI+D1Pe17m29ZnCnKUwVyeQ6Vcya8EnMoFr94HnUbw7OY6mkpbP2pUo 0Zb8EVdgZWqmcFTjMb2m =wbiV -----END PGP SIGNATURE----- --yBp3oDMkBl3y2uwa2ZFKcSsMY4CYm7JgO-- From owner-freebsd-hackers@freebsd.org Wed Apr 11 18:01:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4138AF8432C for ; Wed, 11 Apr 2018 18:01:16 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2F707459E; Wed, 11 Apr 2018 18:01:15 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w3BI1DsM028953; Wed, 11 Apr 2018 11:01:13 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w3BI1D9x028952; Wed, 11 Apr 2018 11:01:13 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804111801.w3BI1D9x028952@pdx.rh.CN85.dnsmgr.net> Subject: Re: Realtek re(4) driver In-Reply-To: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> To: Allan Jude Date: Wed, 11 Apr 2018 11:01:13 -0700 (PDT) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 18:01:16 -0000 > On 2018-04-10 18:50, Dieter BSD wrote: > > Multiple people have found that FreeBSD's re(4) driver for Realtek > > Ethernet chips has problems. Something like a rcp(1) with another > > FreeBSD box merely runs slower due to the stalls, but if the other end > > has buggy network code and/or if the transfer is forced to use UDP > > (Unreliable Data Protocol) data is lost. :-( > > > > Rumor has it that Realtek has a driver that works properly with FreeBSD. > > > > FreeBSD's developers are apparently unable to: > > a) Fix the existing FreeBSD re(4) device driver so that it works correctly. > > b) Replace the existing FreeBSD re(4) device driver with Realtek's driver. > > c) Make Realtek's driver into a port/pkg. > > d) At least add a warning to the re(4) man page, with the URL for > > Realtek's driver. > > > > Therefore every user with Realtek Ethernet chips are forced to somehow > > discover that Realtek has a working driver, then somehow obtain a copy > > of this mythical driver, get it to compile and build a custom kernel. > > They then need to write a test suite and verify that Realtek's driver > > does in fact work properly for their applications. > > > > I am currently suffering data loss due to this. Therefore I am > > attempting to obtain a copy of the mythical Realtek device driver. > > I managed to find > > > >> http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false > > > > But it does not work for me. It has a listing for > > > >> Description Version Update Time File Size Download Site 1 > >> FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global > > > > The machine with the re ports is running 10.3, hopefully the 7&8 code > > will compile and work on 10. But the real problem is that clicking on > > "Global" does not work. Some browsers do nothing. Firefox creates > > a new window with http://www.realtek.com.tw/downloads/ > > which is going backwards. I was expecting something like a tar file > > containing the source code. > > > > I also tried google, and emailing a FreeBSD user that runs the Realtek > > driver, but both pointed me to the above non-working URL. I'm > > told that seamonkey works, but... > > > > So my question is: could someone please tell me the URL that points > > *directly* to the mythical Realtek device driver? (without > > the broken javascheist garbage) > > I think it would be useful to collect the 'pciconf -lv' output of the > re(4) devices that have issues, so they can be differentiated from the > ones that work fine. IIRC one of the "issues" with re type devies is that you can have the exact same PCI vendor and device ID, but they are NOT the same device. You have to read some additional realtek specific hwrev register to know which card you actuall have. That is why another person in this thread asked for dmesg output, as the driver decodes these bits and spits out a proper info line. Search for RL_HWREV in both if_rl.c and if_re.c, the re gets this info from the if_rl.h header. SO if you want to submit your pciconf -lv, PLEASE include the dmesg output for the device. > > This would be the first step to getting a developer setup with a > reliable reproduction platform, so the bug could be tracked down. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Apr 11 21:01:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8821AF9124C for ; Wed, 11 Apr 2018 21:01:15 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 13CB37ED30 for ; Wed, 11 Apr 2018 21:01:14 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.10.103] (hilbert.systella.fr [192.168.10.103]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-10) with ESMTPSA id w3BL1100002317 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 11 Apr 2018 23:01:02 +0200 Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org References: <201804111801.w3BI1D9x028952@pdx.rh.CN85.dnsmgr.net> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Openpgp: preference=signencrypt Autocrypt: addr=joel.bertrand@systella.fr; prefer-encrypt=mutual; keydata= xsFNBFphqV8BEAC+ye6YQBdlEn9p/mbZhiQLkZQjIbGL84M0XOd66AgWqJ3T2TiwEyiExQyM Of0VswmB1q6SaIyh0x4bzaRyKwJLWDJy+AMGLGT2cpmsrDgllUxiBv3xAoLpwR8yDuLs5+bT vPpu81Pm/nzO2NDl85+3WAQbW+bUDAUdBhkg7X07bjJePypRxoRh4LF/syalOjzPEFARFNBY VrXFCTS/F7ZwmUHLv2xWJpEyKHfsC4BSo4ZPjrKmPJBxBPxuR+KiSYG/TkjU6CzoFvdwRY33 GNrK+dUmt9/VnPC/l1rGWS3durgah4OEkxciesKiTvQBUzVfMY0dvzBQKJeNNMFLstnjq3NP qvo3g5DnhFYFSAjI7wzqLkcYO8qg01wrWYyY/NLfAY6CvK0VjlenlKu84ePQDu7zh9/DUzBs 75ZAP2vZv4o00B2A3ksbkXSIs9eSDDx19OS1EUkSqw1VtFRfupoMkK7I7zrGR+DBENl5oK09 SOYJw594XVAoPpZ5zVUlEBDpatBNICTTT17EHrVpEB222TVfChvoE0cwYGkS40nVRIhQ1Yo3 A8qeKb2EeeCtslgiNcb1ajeZOSGUSHnczWHTaX5jMB/evNxZpLJH1WX8PqZ/+7wVRYuZGZ/b r8V3wXjZVNzPSTONwq3w/VjizPcQqdwicoNtxvuB6hM1J1tLGQARAQABzSpCRVJUUkFORCBK b8OrbCA8am9lbC5iZXJ0cmFuZEBzeXN0ZWxsYS5mcj7CwZQEEwEKAD4WIQSrhgKgAkzAsSVl Vhc4B+jSUpDz5wUCWmGpXwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRA4 B+jSUpDz5xwED/462ki+I97keYMSDPVjzx9MmcE/pznOqv8b4IbFbWzaSCx5J3BByBVU1IyP LdDCdZgvc7vM5l8Gc6mqxeABbgdyxBGMwoXBBADXt9dcAKW3xl6URMLoor8DwgnuluCdQT+K 7VW6ron23x7wI9iscuXV2M6xG2G84o5kDgW2NrkKBIwfWqS/XATNrC8e9j71h29cv1RvKN2a 3XQMI6kvBRirb9zM8jWaP1K/QCLZpvhuiXCJwJvl+MGTuOUTxvp44MjVaM++Wfljc9NAVyD8 s3UxBTjhei1zIHiLUMANzeFLnW21UnoCLLoqzD558VC2Gyqk9I9kaZ/jgQqEu6drbJG+6LbY zbiYt1OhURCrMh7zXjPbBCF1rjtjhEZx2EmT2U7KWQvgcW75JBEGCRveTXQga8ytBTcNoEC8 e7ZjM0ob769ZQ1HmeWAOJy6xKEnv1A2P3erQ3xTZEHFVesoruhMAzrf2fdWJ9vGvndMt7sV/ G0NabDwlI+eIZ77vEUCdFiCZuE8vk0BglwXHVH5zjgJNVLNgNFSs3uTSf5zOIqLXyQTOd0px 5jNe2mePxdMuI9MuQWXE8Z7InUaU1WZ+95eTMonTs+DRUJzQ+XWYbqllGudx230T/Y6cYxSW stw5bAQl1aNhNCZjHutNUigb8row2cH2kCVJexv4LYUx8vdc2c7BTQRaYalfARAA000pOiAt CMcbNPczj/sFU5UZ6zaEOPj08nNv48UZAfo8ZiWejSp7YbaU4HW0VxcT2ZQvhsHor2wjqI5K Ii7gmGyjMA6NJPhHVoJw8+j64m38mRcOzlSaQEZV+Pp+TAX8PyucZvNPXHy40UQfDqCoYxAw A0bSWwcSwH+N/eEijrEOf7k1QRjEodjGTxaE50XOWXz/NMVx7l9ORcd5r2oq2DLjqnnQzl6k XxmxSV5cm+HDIojLmQz1qxq7r2GhC5hGuR5KXrO/p4bNiqCTw+rwm4bO6YjTfaH+eNRwzg6L OpW7ZNw0pfWf4wO/h+ozZTY5q9EbZSmZyVoSyPu2J1+mX3gF2ZLSzZ7+XgV4z6EIAcF1sjGE hsqA9yF4NVHGlrP9dkhZFoBVtkJgjSfdSWGXp40X+pUROeVuexD6zDadB5rCv05o9/EPDFu0 W7mJ+l8h3rGI0E5ObmR6+HyFGqalByGFxYbia+x51Kj6WbHNMuddkPk0YbHs53zS9VGnRcnh xTGdga2rMzO9ZycKo7DPrdZVi7bZWKM/WM0IL5m6FTPSJteJ886NP9oc8U6o2GxZ1cMeZwnu AprT77mISL0Z1CCcoSDZEnD+EmOcKxYnkxJuhMY2kdMd2x47I2HFxTa1ix6UQ7OY6i0VQ4gG WZ3tgiHYIHbeAyZXn0P4nM5ofgEAEQEAAcLBfAQYAQoAJhYhBKuGAqACTMCxJWVWFzgH6NJS kPPnBQJaYalfAhsMBQkJZgGAAAoJEDgH6NJSkPPn9mEP/2mEFZGT0AaecRRXfpfrVnxxIwK8 YK3mmaa8jqSLXzDgubTO6PWojVt/SCrvhCtEf5vxATPbeFz5Ho0foI/iGys9SQkYmsIn13m0 z9oY8LBIyrPFud56RrIqYBno3qR6N7SWBWtZeUw+gc6HYbMyk2L7//wz4DkneJYLLcTfMxb/ +Ok0tNmWp6YfuyRBt5yHU6VfW4tZxF5qzg+9niW3VbB6BEZbM+ya7qBZD8su4e1EfUjaKb2z Egyw09laSgBW4NzGBwlhX3zeDsNTiReqa78e1pv52Ur3dI5GH4psLw4rH7ghh/aA/eVDMcKn LPNeTNl+Sz/1PK+oVNxz6tGBVsTVbZpwbanv6+qQP3yPvX0MS1x5QQPp/SAsjJv6lpFkoUGK n2clMYH8pSefR7jp0UPCrMBeFv5bom8tNMTHrIQrpnWo7vXUmeJ7OP/lHUtbBB26882pYbpa 05D79xUkBMYX2BGvtM687+CZaWwA4u/Tl7cu3PpIavPWgmmvIBJOwsDKxNgopLkix8AGFbfs wPcE7d03t9tdauheHA8pssNQmy3scoThC3DQc4eIEBUU5M9uIW2HARl3OgJP9h9OePsgaT8g zTlN3q6QmDWQwRmxF6J7Z9dtIDmXr+014XtK7UCzxkBIFS5jPGzL8dSKDu5jIx8cboy9QUeH Tr6FXnLg Message-ID: <90c5e785-1e73-0bcc-2e36-24cabce74c71@systella.fr> Date: Wed, 11 Apr 2018 23:01:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: <201804111801.w3BI1D9x028952@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0-beta at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 21:01:15 -0000 Rodney W. Grimes a écrit : > SO if you want to submit your pciconf -lv, > PLEASE include the dmesg output for the device. I don't know if it's enough as I cannot reboot with FreeBSD officiel driver. I use Realtek one : Mar 24 21:35:06 pythagore kernel: re0: port 0xe000-0xe0ff mem 0xf7d00000-0xf7d00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci2 Mar 24 21:35:06 pythagore kernel: re0: Using Memory Mapping! Mar 24 21:35:06 pythagore kernel: re0: Using 1 MSI-X message Mar 24 21:35:06 pythagore kernel: re0: version:1.94.01 Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59 Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59 Mar 24 21:35:06 pythagore kernel: re0: link state changed to UP This adapter doesn't work as expected on diskless workstation with kernel driver. No problem with Realtek driver. re0@pci0:2:0:0: class=0x020000 card=0x78511462 chip=0x816810ec rev=0x0c hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' class = network subclass = ethernet Regards, JKB From owner-freebsd-hackers@freebsd.org Wed Apr 11 21:13:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C840BF92237 for ; Wed, 11 Apr 2018 21:13:39 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1ACC580F17 for ; Wed, 11 Apr 2018 21:13:35 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.15.2) with ESMTPS id w3BLD3qI062843 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Apr 2018 23:13:04 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.15.2/Submit) with UUCP id w3BLD3A3062842 for freebsd-hackers@FreeBSD.ORG; Wed, 11 Apr 2018 23:13:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id w3BKic8U001856 for ; Wed, 11 Apr 2018 22:44:38 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id w3BKi5GY001744 for ; Wed, 11 Apr 2018 22:44:05 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id w3BKi39J001740 for freebsd-hackers@FreeBSD.ORG; Wed, 11 Apr 2018 22:44:03 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: Realtek re(4) driver Date: Wed, 11 Apr 2018 22:34:49 +0200 Organization: even some more stinky socks Message-ID: References: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 11 Apr 2018 20:35:03 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="412"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 In-Reply-To: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-hackers@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 11 Apr 2018 23:13:05 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 21:13:40 -0000 Allan Jude wrote: > I think it would be useful to collect the 'pciconf -lv' output of the > re(4) devices that have issues, so they can be differentiated from the > ones that work fine. Yes, but that would mean a structured approach, and not everybody loves that. *vbeg* I remember, in the old times there was a rule: on 100Mb never do autonegotiate, on 1Gb always do autonegotiate - but that may vary depending on device. I would think, that option, as well as respective offloading capabilities, should also carefully checked for influences. I have one of these pieces here, but it runs in 100Mb mode and sadly I have no proper counterpart in reach to do full-speed testing. From owner-freebsd-hackers@freebsd.org Wed Apr 11 21:22:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F0F8F92B5C for ; Wed, 11 Apr 2018 21:22:19 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 1F12C83B03 for ; Wed, 11 Apr 2018 21:22:18 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wr0-x22e.google.com with SMTP id o3so3109281wri.2 for ; Wed, 11 Apr 2018 14:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=cV2y7b317iEhbenJWoLx+yfm83gTHiCoZmiHvbKXAAA=; b=XmUkgh1bQv4U7gOeu67BiDwkrwSuZHabAQRW17GZ30C/OwaBQu5F8XV0/k+zZC/Pd+ ibBUAclmiHwC1mwwtkrYN1FyZioiHrwYFrufR6kNjPxqWQyTe9BOgFROXnRl+zOOruzq hQSEGjnXAk54Dn/bV6aaaS48gqJI8ciUDUjX9Bc2uBQXUnZEsgaUay/of4R3hNHIpXgu E//ZSF7Yp9oVichJk8YDdehsGUyWDh1EAqlBFdW/Jzu9J6mFDjVB4YAv6pIvtox6NWJm mB9x6A3bxsS9Ffx0/jMD/Bu4oZYNG2iWim6fjUATKadFCgfsSPLHUX6BJPZbQ4T0vdw/ Dc2g== 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-language; bh=cV2y7b317iEhbenJWoLx+yfm83gTHiCoZmiHvbKXAAA=; b=NbMLfrDaGeQWs2zaVoYhoAkoynKvLrr/WVd0MELqOLjQAXXNaXkWt+aO7zD0MfPKN4 1p5DDNJl0on8XNFEfGF948ZWl9qfHJy1uWVcl/1R++Lbb7EaWSGkQGSXLlaHooqwbAu0 w0m6lMdhBdar9VXEUe6XjnDey6s0Aam+NxhU+2JFlesgxfpT/94ZKaeJS24SNmTFnq2/ Y2Nxe1CNOmpgI7aucoKEAf529Zf0akMjpRW84Lokx3gzHI0lAI/XoA28T1wg+AC5Cz8m O8REOuKd3x3cNAKgr5qy4dKJ7WhEH/xOseemmMVvqkqeHt9OkbTszQGp0jwtvgRo977r erUg== X-Gm-Message-State: ALQs6tDQyE7Op1SyWWB+vIiez4sAjnVYgROrrNqL/j2d+bVRUazpP8wo YYtF7PBDnu1NLcrWGO5GYBDOO9brje0= X-Google-Smtp-Source: AIpwx48VvHKoELvdCAWo7C1ykcM9p096vPb0B4O4QaA0/MEHNi2TMnXcLo1LAHmiJRC3ltYHVw9tcw== X-Received: by 10.223.164.150 with SMTP id g22mr2449979wrb.53.1523481737542; Wed, 11 Apr 2018 14:22:17 -0700 (PDT) Received: from [10.10.1.111] ([185.97.61.1]) by smtp.gmail.com with ESMTPSA id c14sm3105013wmi.28.2018.04.11.14.22.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 14:22:16 -0700 (PDT) Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org References: <201804111801.w3BI1D9x028952@pdx.rh.CN85.dnsmgr.net> <90c5e785-1e73-0bcc-2e36-24cabce74c71@systella.fr> From: Steven Hartland Message-ID: <0466ec9d-b517-bee1-fa5f-b23ed56e7d36@multiplay.co.uk> Date: Wed, 11 Apr 2018 22:22:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <90c5e785-1e73-0bcc-2e36-24cabce74c71@systella.fr> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 21:22:19 -0000 On 11/04/2018 22:01, BERTRAND Joël wrote: > Rodney W. Grimes a écrit : >> SO if you want to submit your pciconf -lv, >> PLEASE include the dmesg output for the device. > I don't know if it's enough as I cannot reboot with FreeBSD officiel > driver. I use Realtek one : > > Mar 24 21:35:06 pythagore kernel: re0: Controller> port 0xe000-0xe0ff mem > 0xf7d00000-0xf7d00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci2 > Mar 24 21:35:06 pythagore kernel: re0: Using Memory Mapping! > Mar 24 21:35:06 pythagore kernel: re0: Using 1 MSI-X message > Mar 24 21:35:06 pythagore kernel: re0: version:1.94.01 > Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59 > Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:59 > Mar 24 21:35:06 pythagore kernel: re0: link state changed to UP > > This adapter doesn't work as expected on diskless workstation with > kernel driver. No problem with Realtek driver. > > re0@pci0:2:0:0: class=0x020000 card=0x78511462 chip=0x816810ec rev=0x0c > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller' > class = network > subclass = ethernet > I know you said you couldn't do this, but it may well be very useful to compare this to the output when using the built in FreeBSD driver as it may highlight a key difference. I'm thinking given the ages of the Realtek driver we could be looking at a different operational mode, different MSI-X count etc. Here's some other links with potentially relevant info: https://forums.freebsd.org/threads/replacing-realtek-re-driver.55861/ https://unixblogger.com/2011/10/18/the-pain-of-an-realtek-rtl8111rtl8168-ethernet-card/     Regards     Steve From owner-freebsd-hackers@freebsd.org Wed Apr 11 22:04:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D57FAF9569C for ; Wed, 11 Apr 2018 22:04:46 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 5E2656CB87 for ; Wed, 11 Apr 2018 22:04:46 +0000 (UTC) (envelope-from khanzf@gmail.com) Received: by mail-it0-x236.google.com with SMTP id 19-v6so4570868itw.3 for ; Wed, 11 Apr 2018 15:04:46 -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=x4v4DoJoEqVSPjxMu965qPvKJ3gF3NBPDfGYTvaRPz4=; b=QFb36umc5Mmqou+KerwKHLdLMSxRibwwAM+gswhz+HqiQhJqlA1skGJVZzZkVpyPVe V8bbVrbdcygjMqt4X0WnqXVwTeIN68iAxDhrndfrz2/tOWodj9UETV2Qxd0rn3I8LWJD xdMF1flRwf3PQtJHkrdUPnqx0O4PQapL0On8vMc1HwhKa299uLXnn/q8KOOHO6PH4iOJ r+s03AZEtWcpSDzKNRx/a1Z955zKmyCm/jI53gWCXZRPTNXtlOnxMDt198Vc4Uauyrie uK3IU7hcd3Trl49BRZNQr2kWGu1SDWEUocFr9E1RGWxI/C2zd5qZOZsKk93idYEUBPA9 ENHQ== 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=x4v4DoJoEqVSPjxMu965qPvKJ3gF3NBPDfGYTvaRPz4=; b=o6BhRliqcK2yewjo7OexpEnX5Wo0y4j5WKXK8OyM5uL97CuKD33jQslz2+t+Bk78jZ r7C537XBWNAA1vPHtCQjYJU8uy9ILkvq4LFslCmgvHP4SgOKW/HRwxzcOAGmMzdtF63t sK48DSE1V6sPL/COD2K4xVDOWoh4niv/cFgzpy3urDwEFLObY9F8CVRPlz5p+d28XYPP fBM1JIM9B0urcSh6Cfcfd9YM/oX4oSagIkgmi8qUMlEZzxRGZEnrf5MkajGGsX012yk6 r7qAtXudU+WdTIGQrZC47feGV7RovobEYpFyf+1Kuigv7nuMhbb1iRkhvWFTC7NXOsnw lLmA== X-Gm-Message-State: ALQs6tDrcKfwRTLp+p2BMCCS6Hf/kiP2dYHYOcYe5FkstmCEnW+JrsgO GWx4pXYFsulEW/YH1H8TTS3akxHmZyznwZWYMhI= X-Google-Smtp-Source: AIpwx4/0MivvISDLB1PdYUGltOjj9BDFqxV2XrgjtBY6C6G0+kacMDfHx78oGEVWUXmVZqT6KQBTsQsCjQ57kIqAMdA= X-Received: by 2002:a24:76c4:: with SMTP id z187-v6mr5932047itb.138.1523484285301; Wed, 11 Apr 2018 15:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.161 with HTTP; Wed, 11 Apr 2018 15:04:24 -0700 (PDT) In-Reply-To: <0466ec9d-b517-bee1-fa5f-b23ed56e7d36@multiplay.co.uk> References: <201804111801.w3BI1D9x028952@pdx.rh.CN85.dnsmgr.net> <90c5e785-1e73-0bcc-2e36-24cabce74c71@systella.fr> <0466ec9d-b517-bee1-fa5f-b23ed56e7d36@multiplay.co.uk> From: Farhan Khan Date: Wed, 11 Apr 2018 18:04:24 -0400 Message-ID: Subject: Re: Realtek re(4) driver To: Steven Hartland Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 22:04:47 -0000 On Wed, Apr 11, 2018 at 5:22 PM, Steven Hartland wrote: > > > On 11/04/2018 22:01, BERTRAND Jo=C3=ABl wrote: > >> Rodney W. Grimes a =C3=A9crit : >> >>> SO if you want to submit your pciconf -lv, >>> PLEASE include the dmesg output for the device. >>> >> I don't know if it's enough as I cannot reboot with FreeBSD >> officiel >> driver. I use Realtek one : >> >> Mar 24 21:35:06 pythagore kernel: re0: > Controller> port 0xe000-0xe0ff mem >> 0xf7d00000-0xf7d00fff,0xf0000000-0xf0003fff irq 19 at device 0.0 on pci2 >> Mar 24 21:35:06 pythagore kernel: re0: Using Memory Mapping! >> Mar 24 21:35:06 pythagore kernel: re0: Using 1 MSI-X message >> Mar 24 21:35:06 pythagore kernel: re0: version:1.94.01 >> Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:= 59 >> Mar 24 21:35:06 pythagore kernel: re0: Ethernet address: d8:cb:8a:7d:10:= 59 >> Mar 24 21:35:06 pythagore kernel: re0: link state changed to UP >> >> This adapter doesn't work as expected on diskless workstation wi= th >> kernel driver. No problem with Realtek driver. >> >> re0@pci0:2:0:0: class=3D0x020000 card=3D0x78511462 chip=3D0x816810ec rev= =3D0x0c >> hdr=3D0x00 >> vendor =3D 'Realtek Semiconductor Co., Ltd.' >> device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet >> Controller' >> class =3D network >> subclass =3D ethernet >> >> I know you said you couldn't do this, but it may well be very useful to > compare this to the output when using the built in FreeBSD driver as it m= ay > highlight a key difference. > > I'm thinking given the ages of the Realtek driver we could be looking at = a > different operational mode, different MSI-X count etc. > > Here's some other links with potentially relevant info: > https://forums.freebsd.org/threads/replacing-realtek-re-driver.55861/ > https://unixblogger.com/2011/10/18/the-pain-of-an-realtek-rt > l8111rtl8168-ethernet-card/ > > Regards > Steve > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > Hi all, I would love to assist and perform testing in any way I can. I have 2 devices running Realtek devices. One is a 4-port NIC. If we can narrow-down the issue and create a reproduceable failure, I might be able to hunt through the code to help identify the problem (I am primarily tapped on rtwn(4), but I would not mind lending an extra pair of eye-balls) Laptop machine running 12.0-CURRENT: re0@pci0:3:0:0: class=3D0x020000 card=3D0x21de103c chip=3D0x813610ec rev=3D= 0x08 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8101/2/6E PCI Express Fast Ethernet controller' class =3D network subclass =3D ethernet Think Server running 11.1-RELEASE-p8: re0@pci0:4:0:0: class=3D0x020000 card=3D0x012310ec chip=3D0x816810ec rev=3D= 0x07 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet re1@pci0:5:0:0: class=3D0x020000 card=3D0x012310ec chip=3D0x816810ec rev=3D= 0x07 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet re2@pci0:6:0:0: class=3D0x020000 card=3D0x012310ec chip=3D0x816810ec rev=3D= 0x07 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet re3@pci0:7:0:0: class=3D0x020000 card=3D0x012310ec chip=3D0x816810ec rev=3D= 0x07 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet pcib9@pci0:8:0:0: class=3D0x060401 card=3D0x30a517aa chip=3D0x88931283 rev= =3D0x41 hdr=3D0x01 vendor =3D 'Integrated Technology Express, Inc.' device =3D 'IT8893E PCIe to PCI Bridge' class =3D bridge subclass =3D PCI-PCI From owner-freebsd-hackers@freebsd.org Wed Apr 11 22:14:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D5C4F9610A for ; Wed, 11 Apr 2018 22:14:48 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 A27C66F99C for ; Wed, 11 Apr 2018 22:14:47 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x241.google.com with SMTP id h10so989957iob.2 for ; Wed, 11 Apr 2018 15:14:47 -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=k1anTZ9oFnBbWNlFMAaIZHsxPHj4x2kxX10mq1RGrtA=; b=cDu6h2Kh3Hx1iWdr763MBK69Xy5XJL4LaSbOvMDf4Ua65YBRvFR0VbmNx/aguZC36J fb+5/Gb6sOni4S+RhnxkTPDnPLFe8NdpRrSp0MbL4UJEsZdYWsF4sM2w8V3fhHcKwEhQ 8Qk/lZ2l0mFNLOWHTtUk2xOnfkw7vBH2jEQAoRGNHOua0uCsw6vEDHs/9MnVd6L+lVsh OADOSsZPBadZiWdY986wFajDTzRw9+HWNxdj9kLTsbbaxNmpfcDUeJ7N7Bn3bv3IB0tO EdigV3Hb4MtzV9tNBeLd2uJ0FCiVLSfQc4ek9izu4f3V5Jo8Z/NxR9I7Xe0dYADqlbpM BfQg== 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=k1anTZ9oFnBbWNlFMAaIZHsxPHj4x2kxX10mq1RGrtA=; b=sds8BUlTSplOrPHClsxP4PF7pjP09n1iCUVwPfg1UXoYDAoPHse0EWh7A3r55tv9bC gKA+BtA4TeADCHobblw+9iLn9jTL7TyyzFgkQ7BnRO4RZsVQonE9N9DazuZi6ZQDUyRZ cGLwVSZcvYyufUM56w0oB3joG9yxC794nENTDx1/NZq793FMSbd3A+61TTldyFZNm6RP pbqx7gKioYOMIyY9gNqJvF3JRubXPMtuEEBRAnzi3wxZsh9nmdTUEMtjuxZU6LNRwXcD KOHv459Bh4DVQ4vBWrTLl251YmaGifsd9yMAmWzi19OK4SuJ/LhxP0w/zAeTjHB0Lr8z e1OQ== X-Gm-Message-State: ALQs6tBHUop8RENgwabj5tUGb9Yqv69C53I5hUfkH6aAHjjiYd2Uxtvq 4FmpodcNM/ElmD04Jsax1IvoyTzZ+wqGXqhDbiY= X-Google-Smtp-Source: AIpwx49y+bMIZ6lP/llOovnhDWmwxicLIeD3qD3qKct+jLmPHJBZAYi1hfpMMaGFRobiSzx4D532nHy+KHKZytKeAjc= X-Received: by 10.107.138.141 with SMTP id c13mr6960608ioj.0.1523484886941; Wed, 11 Apr 2018 15:14:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Wed, 11 Apr 2018 15:14:46 -0700 (PDT) From: Dieter BSD Date: Wed, 11 Apr 2018 15:14:46 -0700 Message-ID: Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 22:14:48 -0000 One problem I see with the Realtek Ethernet and the stock FreeBSD device driver is occasional pauses in Ethernet traffic. Observe with: netstat -w 1 -I re2 With reasonably decent network software and TCP, this is only a minor problem. However with buggy network software (like a "black box" with closed source firmware and maybe a transmit buffer that is *way* too small, and/or true real time requirements), and/or with a brain dead protocol like UDP, you can lose data. So I decided to try and find a way to demonstrate the problem using only 2 normal computers running FreeBSD, one with Realtek Ethernet. The easy way seemed to be to transfer a large file using UDP and look for errors. On machine with Realtek Ethernet: nc -4nul 55555 > /var/tmp/big_file_copied_via_udp On some other machine: nc -4u machine_with_realtek 55555 < big_file If you don't like 55555, pick another port number. ;-) I first tried a 2.9 GB file, which worked ok a few times, then I tried a 28 GB file and the copy was smaller than the original. Tried it a couple more times and also got different sizes which were smaller than the original. Then transferred it twice with tcp, getting the correct size both times, and the two copies passed cmp(1). original: 28132560000 bytes udp copy 1: 28131929216 (smaller) udp copy 2: 28132523136 (smaller) udp copy 3: 28132537472 (smaller) tcp copy 1: 28132560000 (correct) tcp copy 2: 28132560000 (correct) Ran time(1) on nc (using tcp): real 5m56.591s -> 78,893,073 B/s Next, transfer the opposite direction, with Realtek transmitting and non-Realtek receiving. Transferred with tcp, got the correct file size, and the copy passed cmp(1) against the original file. Attempts to transfer using udp seem to run into some sort of flow control problem, the nc processes hang. Sometimes a small amount of data gets through. Both machines are amd64 with ECC memory RTL8111F and stock FreeBSD 10.4 re(4) The other machine has nfe(4) running FreeBSD 8.2 re0@pci0:4:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07 hdr=0x00 re1@pci0:5:0:0: class=0x020000 card=0x012310ec chip=0x816810ec rev=0x07 hdr=0x00 re2@pci0:12:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x0c hdr=0x00 re0: re0: Chip rev. 0x2c800000 re1: re1: Chip rev. 0x2c800000 re2: re2: Chip rev. 0x4c000000 ================================================= Steven writes: >> http://12244.wpc.azureedge.net/8012244/drivers/rtdrivers/cn/nic/0007-rtl_bsd_drv_v194.01.tgz Gary writes: > This is the old if_rl driver by Bill Paul from 1998. Hard to > believe it's really superior to the newer version, which is also > based on later code from Bill Paul. The URL worked for me (using wget). 96,127 bytes. Thank you, Steven! tar tvzf 0007-rtl_bsd_drv_v194.01.tgz drwxrwxrwx 0 0 0 0 Dec 26 2016 rtl_bsd_drv_v194.01/ -rwxrwxrwx 0 0 0 1186892 Aug 29 2017 rtl_bsd_drv_v194.01/if_re.c -rwxrwxrwx 0 0 0 37071 Aug 25 2017 rtl_bsd_drv_v194.01/if_rereg.h -rwxrwxrwx 0 0 0 200 Jun 14 2016 rtl_bsd_drv_v194.01/Makefile -rwxrwxrwx 0 0 0 3172 Jan 3 2017 rtl_bsd_drv_v194.01/Readme.txt Huh? What is this about 1998? Looks like 2017-08-29 to me. The files are newer than FreeBSD 10.3's sources: -r--r--r-- 1 root wheel 111335 Mar 24 2016 re/if_re.c However, I have RTL8111E on UD5 mainboard, and 2x RTL8111F on PCIe card. The FreeBSD sources attempt to support these, but the Realtek sources do not mention these revisions, which seems odd when it is 1.5 years newer. # grep -i 8111e re/* rtl_bsd_drv_v194.01/* re/if_re.c: { RL_HWREV_8168E, RL_8169, "8168E/8111E", RL_JUMBO_MTU_9K}, re/if_re.c: { RL_HWREV_8168E_VL, RL_8169, "8168E/8111E-VL", RL_JUMBO_MTU_6K}, re/if_re.c: { RL_HWREV_8168EP, RL_8169, "8168EP/8111EP", RL_JUMBO_MTU_9K}, # grep -i 8111f re/* rtl_bsd_drv_v194.01/* re/if_re.c: { RL_HWREV_8168F, RL_8169, "8168F/8111F", RL_JUMBO_MTU_9K}, Which leaves me wondering if the Reaktek code supports the chips I have or not. Readme.txt says > for FreeBSD v4.x/5.x/6.x/7.x/8.x/9.x No mention of 10 or newer, which, again, seems odd when it is 1.5 years newer than 10.3. May or may not be a problem. From owner-freebsd-hackers@freebsd.org Thu Apr 12 00:36:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0411F9F1F5 for ; Thu, 12 Apr 2018 00:36:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 4EDE16E7B5 for ; Thu, 12 Apr 2018 00:36:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22d.google.com with SMTP id y23so1183365ywy.4 for ; Wed, 11 Apr 2018 17:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=fSICTGZVYuFy4zNVxcFHYV/IxRbyVqJ+cII3uTKuTqQ=; b=N33TH+N0UMOiwAc/YCu0kRML8sHEVFHTTohxS4EJQcnYR/i6Jd673/hblxMtlAtQu2 FI3O4QV/cM+RHYlUa0g3dltiAaKwkufBMqUAXtp0egkT7OWHoKKbXXsBJpInAH6QYbGZ W7Q6B4tLyYqsKTCB7JXQfRYxBQD6v4mBfgMLU= 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 :content-transfer-encoding; bh=fSICTGZVYuFy4zNVxcFHYV/IxRbyVqJ+cII3uTKuTqQ=; b=NkEs+MWW6+Qp9KkNvbsaxIz0g4uHNiFkVSRzASeFJZpIA4XMgS3uxSEFWCDaP+hkRW ZHiH31t66QNLm7zigzBNhQHE6b8vXlKy2yUPAHVevLP3l8RZvgheABZxDYJT3DDgkv+K DLeJlzSIppcYJ/ee5V1ymTrjnFeJN3KMa6eOEknSC+6xfVDoJTK5e4v+Q/TO5WnnER2E 9Ld2VjbbcY81a1RhoVHKr6dhpnJPinU0jqkX0OP/n8Udq78svFnJxA3tEvl2BWuhCLMX bUfj1LZvC4J9EOGW8J40KW/dvpdQJmmke87cck+eFrvjHjyPZrYGhwg4Qqs6sSK4jL/n QXDw== X-Gm-Message-State: ALQs6tCMHFTYwN2H/4Ng3+49NYTlvRR6Vb/W8B85Frs9GqP9Nkbd7v+M OsM1PiEAxYmE+88mgTK3LxuCUuujv+RFrlftbc2WahYn X-Google-Smtp-Source: AIpwx4+A8SP9nXSMB6Rm6DI+ujpXYHDf7HT9A8BYqNGDax+6PMJ+JuQrseidV5fDfILOjMLjPG9VNcQrC73FX41TS0M= X-Received: by 10.13.219.3 with SMTP id d3mr2960451ywe.182.1523493409239; Wed, 11 Apr 2018 17:36:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 17:36:18 -0700 (PDT) From: Eitan Adler Date: Wed, 11 Apr 2018 17:36:18 -0700 Message-ID: Subject: Crypto READ request failed (error=22). md10.eli[READ(offset=818688, length=512 To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 00:36:50 -0000 vmcore.0 and kernel are available. I'll llkely spend some time this weekend looking at the issues but if anyone cares to get to this first: https://reviews.freebsd.org/P166 ---- Unread portion of the kernel message buffer: [173352] GEOM_ELI: Device md10.eli created. [173352] GEOM_ELI: Encryption: AES-XTS 128 [173352] GEOM_ELI: Integrity: HMAC/SHA1 [173352] GEOM_ELI: Crypto: hardware [173352] GEOM_ELI: Crypto READ request failed (error=3D22). md10.eli[READ(offset=3D818688, length=3D512 )] [173352] panic: crypto_dispatch() failed (error=3D22) [173352] cpuid =3D 20 [173352] time =3D 1523431733 [173352] KDB: stack backtrace: [173352] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00ae86d800 [173352] vpanic() at vpanic+0x18d/frame 0xfffffe00ae86d860 [173352] doadump() at doadump/frame 0xfffffe00ae86d8e0 [173352] g_eli_auth_run() at g_eli_auth_run+0x22b/frame 0xfffffe00ae86da00 [173352] g_eli_worker() at g_eli_worker+0x14c/frame 0xfffffe00ae86da70 [173352] fork_exit() at fork_exit+0x84/frame 0xfffffe00ae86dab0 [173352] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00ae86dab0 [173352] --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- [173352] KDB: enter: panic #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D0x1) at /usr/src/sys/kern/kern_shutdown.c:361 #2 0xffffffff80434f4c in db_fncall_generic (addr=3D, rv=3D, nargs=3D, args=3D) at /usr/src/sys/ddb/db_command.c:609 #3 db_fncall (dummy1=3D, dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:657 #4 0xffffffff80434a99 in db_command (last_cmdp=3D, cmd_table=3D, dopager=3D) at /usr/src/sys/ddb/db_command.c:481 #5 0xffffffff80434814 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #6 0xffffffff80437a3f in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:250 #7 0xffffffff80babf53 in kdb_trap (type=3D0x3, code=3D0xffff0ff0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff81024aa8 in trap (frame=3D0xfffffe00ae86d730) at /usr/src/sys/amd64/amd64/trap.c:548 #9 #10 kdb_enter (why=3D0xffffffff8129f663 "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:479 #11 0xffffffff80b66b5a in vpanic (fmt=3D, ap=3D0xfffffe00ae86d8a0) at /usr/src/sys/kern/kern_shutdown.c:826 #12 0xffffffff80b66920 in kassert_panic (fmt=3D0xffffffff825f243b "crypto_dispatch() failed (error=3D%d)") at /usr/src/sys/kern/kern_shutdown.c:723 #13 0xffffffff825ee10b in g_eli_auth_run (wr=3D0xfffff8003a580bc0, bp=3D) at /usr/src/sys/geom/eli/g_eli_integrity.c:537 #14 0xffffffff825e9b7c in g_eli_worker (arg=3D) at /usr/src/sys/geom/eli/g_eli.c:542 #15 0xffffffff80b26e34 in fork_exit (callout=3D0xffffffff825e9a30 , arg=3D0xfffff8003a580bc0, frame=3D0xfffffe00ae86dac0) at /usr/src/sys/kern/kern_fork.c:1039 #16 (kgdb) info registers rax 0x12 0x12 rbx 0xfffffe00ae86d968 0xfffffe00ae86d968 rcx 0x80 0x80 rdx 0xfffffe00ae86d6f0 0xfffffe00ae86d6f0 rsi 0x80 0x80 rdi 0xffffffff81deab08 0xffffffff81deab08 rbp 0xfffffe00ae86da00 0xfffffe00ae86da00 rsp 0xfffffe00ae86d8f0 0xfffffe00ae86d8f0 r8 0x1 0x1 r9 0x0 0x0 r10 0xffffffff81cdc698 0xffffffff81cdc698 r11 0x0 0x0 r12 0x1e0 0x1e0 r13 0xfffff8004362f428 0xfffff8004362f428 r14 0xfffff8004362f598 0xfffff8004362f598 r15 0x18f800 0x18f800 rip 0xffffffff825ee10b 0xffffffff825ee10b eflags 0x82 [ SF ] cs 0x20 0x20 ss 0x28 0x28 ds es fs gs fs_base gs_base (kgdb) info locals sc =3D 0xfffff80136461c00 encr_secsize =3D 0x200 nsec =3D lsec =3D 0x2 plaindata =3D 0xfffff800051b1a00 "\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\2= 55\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\= 300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336= \336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\25= 5\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\3= 00\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\= 336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255= \336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\30= 0\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\3= 36\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\= 336\336\300\255\336\336\300\255\336\336\300\255\336"... data =3D auth =3D 0xfffff8004362f414 "\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\2= 55\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\= 300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336= \336\300\255\336\336\300\255\336\336\300\255\336\067" p =3D i =3D decr_secsize =3D 0x200 dstoff =3D 0x18f800 error =3D 0x80 crp =3D 0xfffff8004362f428 data_secsize =3D crde =3D crda =3D authkey =3D (kgdb) info args wr =3D 0xfffff8003a580bc0 bp =3D (kgdb) p *crp $1 =3D { crp_next =3D { tqe_next =3D 0xdeadc0dedeadc0de, tqe_prev =3D 0xdeadc0dedeadc0de }, crp_task =3D { ta_link =3D { stqe_next =3D 0xdeadc0dedeadc0de }, ta_pending =3D 0xc0de, ta_priority =3D 0xdead, ta_func =3D 0xdeadc0dedeadc0de, ta_context =3D 0xdeadc0dedeadc0de }, crp_sid =3D 0x500000100000037, crp_ilen =3D 0x1f4, crp_olen =3D 0x1e0, crp_etype =3D 0x16, crp_flags =3D 0x60, { crp_buf =3D 0xfffff8004362f000 "", crp_mbuf =3D 0xfffff8004362f000, crp_uio =3D 0xfffff8004362f000 }, crp_opaque =3D 0xfffff803726ffc00, crp_desc =3D 0xfffff8004362f520, crp_callback =3D 0xffffffff825ee8f0 , crp_tstamp =3D { sec =3D 0xdeadc0dedeadc0de, frac =3D 0xdeadc0dedeadc0de }, crp_seq =3D 0xdeadc0de, crp_retw_id =3D 0x17 } (kgdb) p *crp->crp_desc $3 =3D { crd_skip =3D 0x14, crd_len =3D 0x1e0, crd_inject =3D 0x0, crd_flags =3D 0x10, CRD_INI =3D { cri_alg =3D 0x7, cri_klen =3D 0x100, cri_mlen =3D 0xdeadc0de, cri_key =3D 0xfffff8004362f598 "=3D\031eR\340\275D\366\205\020\307,\304]\bP\207\202\207\061\347\070\344\26= 4\325\267\336\371~x\366\267\336\300\255\336\336\300\255\336\336\300\255\336= \336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\25= 5\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\3= 00\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\= 336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255= \336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\30= 0\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\3= 36\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\= 336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300= \255\336\336\300\255\336"..., cri_iv =3D "\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\2= 55\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\= 300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336= \336\300\255\336\336\300\255\336", cri_next =3D 0xdeadc0dedeadc0de }, crd_next =3D 0xfffff8004362f4a8 } (kgdb) p *crp->crp_desc->crd_next $4 =3D { crd_skip =3D 0x14, crd_len =3D 0x1e0, crd_inject =3D 0xdeadc0de, crd_flags =3D 0x16, CRD_INI =3D { cri_alg =3D 0x16, cri_klen =3D 0x100, cri_mlen =3D 0xdeadc0de, cri_key =3D 0xfffff8003a28ae00 "\214\352\255\370\"\214|\275\367=3D\005\331X\325\251\371\220LN\207\037sY\30= 5\274\033\346\200\217\343\272J\032H\021u[\024:\303\301\275\210\200\321\"\25= 1\071\251\022", cri_iv =3D "", cri_next =3D 0xdeadc0dedeadc0de }, crd_next =3D 0x0 } ---- --=20 Eitan Adler --=20 Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Apr 12 01:27:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F7CBFA31E9 for ; Thu, 12 Apr 2018 01:27:47 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4037278C6E for ; Thu, 12 Apr 2018 01:27:47 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from Ticonderoga.HML3.ScaleEngine.net (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: allanjude) by smtp.freebsd.org (Postfix) with ESMTPSA id 27CDD1DFD5 for ; Thu, 12 Apr 2018 01:27:47 +0000 (UTC) (envelope-from allanjude@freebsd.org) Subject: Re: Crypto READ request failed (error=22). md10.eli[READ(offset=818688, length=512 To: freebsd-hackers@freebsd.org References: From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Message-ID: Date: Wed, 11 Apr 2018 21:27:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 01:27:47 -0000 On 04/11/2018 20:36, Eitan Adler wrote: > vmcore.0 and kernel are available. I'll llkely spend some time this > weekend looking at the issues but if anyone cares to get to this > first: > > > https://reviews.freebsd.org/P166 > > ---- > > Unread portion of the kernel message buffer: > [173352] GEOM_ELI: Device md10.eli created. > [173352] GEOM_ELI: Encryption: AES-XTS 128 > [173352] GEOM_ELI: Integrity: HMAC/SHA1 > [173352] GEOM_ELI: Crypto: hardware > [173352] GEOM_ELI: Crypto READ request failed (error=22). > md10.eli[READ(offset=818688, length=512 > )] Do you happen to know how big the md(4) device is? > [173352] panic: crypto_dispatch() failed (error=22) > [173352] cpuid = 20 > [173352] time = 1523431733 > [173352] KDB: stack backtrace: > [173352] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00ae86d800 > [173352] vpanic() at vpanic+0x18d/frame 0xfffffe00ae86d860 > [173352] doadump() at doadump/frame 0xfffffe00ae86d8e0 > [173352] g_eli_auth_run() at g_eli_auth_run+0x22b/frame 0xfffffe00ae86da00 > [173352] g_eli_worker() at g_eli_worker+0x14c/frame 0xfffffe00ae86da70 > [173352] fork_exit() at fork_exit+0x84/frame 0xfffffe00ae86dab0 > [173352] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00ae86dab0 > [173352] --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > [173352] KDB: enter: panic > > > #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=0x1) at /usr/src/sys/kern/kern_shutdown.c:361 > #2 0xffffffff80434f4c in db_fncall_generic (addr=, > rv=, nargs=, args=) at > /usr/src/sys/ddb/db_command.c:609 > #3 db_fncall (dummy1=, dummy2=, > dummy3=, dummy4=) at > /usr/src/sys/ddb/db_command.c:657 > #4 0xffffffff80434a99 in db_command (last_cmdp=, > cmd_table=, dopager=) at > /usr/src/sys/ddb/db_command.c:481 > #5 0xffffffff80434814 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:534 > #6 0xffffffff80437a3f in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:250 > #7 0xffffffff80babf53 in kdb_trap (type=0x3, code=0xffff0ff0, > tf=) at /usr/src/sys/kern/subr_kdb.c:697 > #8 0xffffffff81024aa8 in trap (frame=0xfffffe00ae86d730) at > /usr/src/sys/amd64/amd64/trap.c:548 > #9 > #10 kdb_enter (why=0xffffffff8129f663 "panic", msg=) at > /usr/src/sys/kern/subr_kdb.c:479 > #11 0xffffffff80b66b5a in vpanic (fmt=, > ap=0xfffffe00ae86d8a0) at /usr/src/sys/kern/kern_shutdown.c:826 > #12 0xffffffff80b66920 in kassert_panic (fmt=0xffffffff825f243b > "crypto_dispatch() failed (error=%d)") at > /usr/src/sys/kern/kern_shutdown.c:723 > #13 0xffffffff825ee10b in g_eli_auth_run (wr=0xfffff8003a580bc0, > bp=) at /usr/src/sys/geom/eli/g_eli_integrity.c:537 > #14 0xffffffff825e9b7c in g_eli_worker (arg=) at > /usr/src/sys/geom/eli/g_eli.c:542 > #15 0xffffffff80b26e34 in fork_exit (callout=0xffffffff825e9a30 > , arg=0xfffff8003a580bc0, frame=0xfffffe00ae86dac0) at > /usr/src/sys/kern/kern_fork.c:1039 > #16 > -- Allan Jude From owner-freebsd-hackers@freebsd.org Thu Apr 12 04:01:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC75F8B616 for ; Thu, 12 Apr 2018 04:01:02 +0000 (UTC) (envelope-from lists@eitanadler.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 3766D7BA97 for ; Thu, 12 Apr 2018 04:01:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id EB0F8F8B611; Thu, 12 Apr 2018 04:01:01 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C902AF8B610 for ; Thu, 12 Apr 2018 04:01:01 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::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 6D49B7BA93 for ; Thu, 12 Apr 2018 04:01:01 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x230.google.com with SMTP id e5-v6so1360055ybq.13 for ; Wed, 11 Apr 2018 21:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=VkwA0oXZxUxSXUyJoiVBwTH+qAx0T4uneSLTvAWSKBE=; b=AX8RUdXxrVfya1HvqF1IPDLy5nSZdxL337BTIAzLtyXa/teIiOxEo2loNNkVZ7iv+j kzpqkvs3sNcAvS+mBuW9HpBSlnA08lL5HtU2vCF6LjUwCOO5B2nujLWYHArNE59Ngumk MNfojklf8ZnwxdQkV6dLDEPG19ZsG0PDp+L9w= 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=VkwA0oXZxUxSXUyJoiVBwTH+qAx0T4uneSLTvAWSKBE=; b=q+HHsiO/0fm1GyneJSD76JIzD/eMvRvc99j0a4BnOR7BSgyLXhFZhSrEflzjmoFzqY 7evf66lfePCFtoScu1Z1tWfQtOeSSaZinTDEpVmUJibfI7C+7XJe5Krv3kv87Q6+69Ou 671uP6ciCtdQDYHGn7Q+lK6I/3803Vd0nuvWwDVxxLeql1kPOyxlhk91w0r3NPyWb31p 9QTPnt6n6wU/8YF4e8aSYYcKvvjaDWnzl+AfZXLVDr/EiZFvVdEd7GohPGa/qmsWvT1b vt6yEDt7TLNZSy0PuLv6E63ea1jOOERCEi7Y84iVl3VRyF+6OBa5cnlBssFUHjB13gF5 zqvw== X-Gm-Message-State: ALQs6tByiBVhZFdcOZCIuZ72SAowYIWc2lMjUxfyVZ7gYVHOMP9PnYrQ 5po/0oLjEuRG8j8KxtNJ8l/3QGfSYAo2ntr8ue919MH7 X-Google-Smtp-Source: AIpwx4+nU3pvBJx90o2uqh5gf+6qR9P5DVKNTWUz3ZWc6TJ6gxkaG1qQQPXJbw/SrdarPkzNHco45jdHu2BTd3NN00E= X-Received: by 2002:a25:268f:: with SMTP id m137-v6mr3310466ybm.460.1523505660477; Wed, 11 Apr 2018 21:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 21:00:29 -0700 (PDT) From: Eitan Adler Date: Wed, 11 Apr 2018 21:00:29 -0700 Message-ID: Subject: panic: deadlkres: possible deadlock detected for 0xfffff80141b04560, blocked for 1801695 ticks To: "hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 04:01:02 -0000 How to reproduce? # kldload sem # kldunload sem < wait debug.deadlkres.slptime_threshold seconds > https://reviews.freebsd.org/P168 Reading symbols from ./kernel/kernel...Reading symbols from /usr/home/eax/crashes/sem_load_dklres/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: [29474] panic: deadlkres: possible deadlock detected for 0xfffff80141b04560, blocked for 1801695 ticks [29474] [29474] cpuid = 31 [29474] time = 1523493929 [29474] KDB: stack backtrace: [29474] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00a6204960 [29474] vpanic() at vpanic+0x18d/frame 0xfffffe00a62049c0 [29474] panic() at panic+0x43/frame 0xfffffe00a6204a20 [29474] deadlkres() at deadlkres+0x3a6/frame 0xfffffe00a6204a70 [29474] fork_exit() at fork_exit+0x84/frame 0xfffffe00a6204ab0 [29474] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00a6204ab0 [29474] --- trap 0, rip = 0, rsp = 0, rbp = 0 --- [29474] KDB: enter: panic __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) bt #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=0x1) at /usr/src/sys/kern/kern_shutdown.c:361 #2 0xffffffff80434f4c in db_fncall_generic (addr=, rv=, nargs=, args=) at /usr/src/sys/ddb/db_command.c:609 #3 db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:657 #4 0xffffffff80434a99 in db_command (last_cmdp=, cmd_table=, dopager=) at /usr/src/sys/ddb/db_command.c:481 #5 0xffffffff80434814 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #6 0xffffffff80437a3f in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:250 #7 0xffffffff80babf53 in kdb_trap (type=0x3, code=0xffff0ff0, tf=) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff81024aa8 in trap (frame=0xfffffe00a6204890) at /usr/src/sys/amd64/amd64/trap.c:548 #9 #10 kdb_enter (why=0xffffffff8129f663 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:479 #11 0xffffffff80b66b5a in vpanic (fmt=, ap=0xfffffe00a6204a00) at /usr/src/sys/kern/kern_shutdown.c:826 #12 0xffffffff80b66be3 in panic (fmt=0xffffffff81deab08 "5i&\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:764 #13 0xffffffff80b00466 in deadlkres () at /usr/src/sys/kern/kern_clock.c:288 #14 0xffffffff80b26e34 in fork_exit (callout=0xffffffff80b000c0 , arg=0x0, frame=0xfffffe00a6204ac0) at /usr/src/sys/kern/kern_fork.c:1039 #15 (kgdb) #13 0xffffffff80b00466 in deadlkres () at /usr/src/sys/kern/kern_clock.c:288 288 panic("%s: possible deadlock detected for %p, blocked for %d ticks\n", (kgdb) info locals tryl = slpticks = 0x1b7740 blkticks = 0xdbba0 p = 0xfffff80141b00538 td = wchan = 0xffffffff81deb2d8 tticks = 0x1b7ddf slptype = i = (more in the paste) -- Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Apr 12 04:23:06 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ABCAF8D218 for ; Thu, 12 Apr 2018 04:23:06 +0000 (UTC) (envelope-from lists@eitanadler.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 3450381848 for ; Thu, 12 Apr 2018 04:23:06 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id E2413F8D216; Thu, 12 Apr 2018 04:23:05 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF747F8D215 for ; Thu, 12 Apr 2018 04:23:05 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 6A4A081847 for ; Thu, 12 Apr 2018 04:23:05 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id p126-v6so1377291ybg.8 for ; Wed, 11 Apr 2018 21:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=eFs8Su+VH+yqdKm5A+8vlBfjS3qEIP6W6lb7dcNuPhM=; b=VCwMhQnUGa0IP4G7sgjkpVZ+WjNMQ3K/NV83OYA0UCIwOy4z1G+aVK0xkodrbDPXdP CQkt7fS0TdojA8iHhibejb8+u6ru0NJSUUI3mxYJv7vQkPJo2Q97e8Vlcmckya7iXXay h+tL66WY7W+PI6Y2+jneDGlrt9glBf7JvP2X4= 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=eFs8Su+VH+yqdKm5A+8vlBfjS3qEIP6W6lb7dcNuPhM=; b=DmBy2EUbqALmBmONmsOT0XbJCy3eDeME4HfiZ7m8Dtl4av4oN1R7lsaox3Rv9A6L4t 8kZ7X04JiUGAmf66JdrqWMFQ9jJsqILEp+486Uby+ad7ZfHkMZ1VLyaLpMgl0jdb9+B8 GawjclwWjHBNZfydFZxU434iYM5hmVhjcpRD3CgMxXW87Fu8iFOwl/6w7mVuU5QQYFam cZ0h5WxwMNy8CbOIT9fGTXJAhca3cFGH2KenYK5VQn0hCfbLUzheEZTgSzL567Ype0dn b9Sgq8aFAvW8qi2ggsmGxX+mW0WL4h/T5HB2wabcuxv1qiEPHUE7oteWooaEhAwzqjCh XshA== X-Gm-Message-State: ALQs6tDt5pizyMBmIDdkYR7OslHFxQHaYwrH+0IdHbinMuVsMJPm+Jm/ F/vJqInLcbmT1jvKRiUkNnejxarbFvXRbJ44+4aDoTxi X-Google-Smtp-Source: AIpwx48tlOjcGaN56nC5ZGt1re6vBiq8CjlmTZoEYgWIavZpzDMuJiT2GqBQgQ6s32I96yc/n+5oCllkF0rh9Z0xqUU= X-Received: by 2002:a25:cf8c:: with SMTP id f134-v6mr3292530ybg.69.1523506984479; Wed, 11 Apr 2018 21:23:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 21:22:33 -0700 (PDT) From: Eitan Adler Date: Wed, 11 Apr 2018 21:22:33 -0700 Message-ID: Subject: dcons unload panic (including debug info): Fatal trap 12: page fault while in kernel mode To: "hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 04:23:06 -0000 How to reproduce: kldload dcons; kldunload dcons Unread portion of the kernel message buffer: [124] [124] [124] Fatal trap 12: page fault while in kernel mode [124] cpuid = 10; apic id = 0a [124] fault virtual address = 0xffffffff8423ef48 [124] fault code = supervisor read data, page not present [124] instruction pointer = 0x20:0xffffffff80be84d0 [124] stack pointer = 0x28:0xfffffe0077bff920 [124] frame pointer = 0x28:0xfffffe0077bff930 [124] code segment = base 0x0, limit 0xfffff, type 0x1b [124] = DPL 0, pres 1, long 1, def32 0, gran 1 [124] processor eflags = interrupt enabled, resume, IOPL = 0 [124] current process = 12 (swi6: Giant taskq) __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=r" (td) more here: https://reviews.freebsd.org/P170 -- Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Apr 12 04:57:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 446FAF90382 for ; Thu, 12 Apr 2018 04:57:58 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002: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 D41B1694B0 for ; Thu, 12 Apr 2018 04:57:57 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22f.google.com with SMTP id y64so1366446ywa.3 for ; Wed, 11 Apr 2018 21:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=AvNqZjGftATqqTKGpd0hm4Q6wP8JAKxRQgLyzaHALaI=; b=CdriGzp/hEZHbH6RihMDHi9r+qIU17s6dtzleZbB+K2SZoeLE8TppRiEnDUSeUva0X dnUxYr3QDH+rHuQHYooShoK4153wnzTnQxMhYlRFATjnFVgRMhjjIUgCvqwQUzRd/Ljx TgJh++SFvoXtT3SvCF3MFewAJER955g9xZAhI= 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=AvNqZjGftATqqTKGpd0hm4Q6wP8JAKxRQgLyzaHALaI=; b=DxoM98RUtnHesxSjqAuPN1gQNqyhjoy+Y7jPiXj5jg55s328ODglmrry1ceu6ZCJCq iOLyxUSK9v8mXxfKKvAgMuB1Sza5cmApz/lRp7QB/xS+4JaLa7Bhmyv2a1lW0RtvCjWY VymvBZK4u4vc8xE2Q8zSiVKI/1c0NzuaEexjvE4iSMJSOusiQo8TAw0Q06JDOtI5vru6 EpF1eCbJTxIiI8ssJImfuFOPN+eRCnwITncGtF6MQW7unzdd/dtVzcAbdkBOFgAImXRU fgw9D8SF+llWh20/3fKZc5MfIbfyzHJO40VaMKYuoMKrDXF8tfv7YtfGuR2O0XczB8mE jl3A== X-Gm-Message-State: ALQs6tDUvXFwDH7PJD8vbCE1QBC8DbFNQaaag7V0xSAEjNI0wXlscrI1 WN3aKUl38YtQ1Ggch0Wg5Eua+JT+oSwrVCXkqt6GDkhC X-Google-Smtp-Source: AIpwx49XpUFsFBnB8ZF4Pn64LHHd6BQRnHJ3nOxL9owEOYtVKd2N8poJep01xRFpUKImUjrVznf87mGSM6g4LBBGhJA= X-Received: by 10.13.219.3 with SMTP id d3mr3176461ywe.182.1523509076820; Wed, 11 Apr 2018 21:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 21:57:26 -0700 (PDT) From: Eitan Adler Date: Wed, 11 Apr 2018 21:57:26 -0700 Message-ID: Subject: panic: probe defined without a provider To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 04:57:58 -0000 Unread portion of the kernel message buffer: [1786] panic: probe defined without a provider [1786] cpuid = 20 [1786] time = 1523508024 [1786] KDB: stack backtrace: [1786] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe010fc77360 [1786] vpanic() at vpanic+0x18d/frame 0xfffffe010fc773c0 [1786] doadump() at doadump/frame 0xfffffe010fc77440 [1786] sdt_kld_load() at sdt_kld_load+0x24e/frame 0xfffffe010fc775f0 [1786] linker_load_module() at linker_load_module+0xd43/frame 0xfffffe010fc77900 [1786] kern_kldload() at kern_kldload+0xf1/frame 0xfffffe010fc77950 [1786] sys_kldload() at sys_kldload+0x5b/frame 0xfffffe010fc77980 [1786] amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe010fc77ab0 [1786] fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe010fc77ab0 [1786] --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002cfd8a, rsp = 0x7fffffff6338, rbp = 0x7fffffff68b0 --- [1786] KDB: enter: panic (kgdb) bt #7 0xffffffff80babf53 in kdb_trap (type=0x3, code=0xffff0ff0, tf=) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff81024aa8 in trap (frame=0xfffffe010fc77290) at /usr/src/sys/amd64/amd64/trap.c:548 #9 #10 kdb_enter (why=0xffffffff8129f663 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:479 #11 0xffffffff80b66b5a in vpanic (fmt=, ap=0xfffffe010fc77400) at /usr/src/sys/kern/kern_shutdown.c:826 #12 0xffffffff80b66920 in kassert_panic (fmt=0xffffffff83bacce0 "probe defined without a provider") at /usr/src/sys/kern/kern_shutdown.c:723 #13 0xffffffff83bac2de in sdt_create_probe (probe=0xffffffff844d9c50 ) at /usr/src/sys/cddl/dev/sdt/sdt.c:156 #14 sdt_kld_load (arg=, lf=0xfffff8003a739200) at /usr/src/sys/cddl/dev/sdt/sdt.c:291 #15 0xffffffff80b36de3 in linker_load_file (filename=, result=) at /usr/src/sys/kern/kern_linker.c:475 #16 linker_load_module (kldname=, modname=0x0, parent=0x0, verinfo=, lfpp=0xfffffe010fc77918) at /usr/src/sys/kern/kern_linker.c:2092 #17 0xffffffff80b38361 in kern_kldload (td=, file=, fileid=0xfffffe010fc77964) at /usr/src/sys/kern/kern_linker.c:1071 #18 0xffffffff80b3848b in sys_kldload (td=0xfffff8004b4cb000, uap=) at /usr/src/sys/kern/kern_linker.c:1097 #19 0xffffffff8102606b in syscallenter (td=0xfffff8004b4cb000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:134 #20 amd64_syscall (td=0xfffff8004b4cb000, traced=0x0) at /usr/src/sys/amd64/amd64/trap.c:936 #21 #22 0x00000008002cfd8a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffff6338 (kgdb) info locals mod = "\b" func = "\317\n\016\177\b\370\377\377" name = "" prov = 0x0 len = from = to = (kgdb) frame Stack level 13, frame at 0xfffffe010fc77600: rip = 0xffffffff83bac2de in sdt_create_probe (/usr/src/sys/cddl/dev/sdt/sdt.c:156); saved rip = 0xffffffff80b36de3 inlined into frame 14, caller of frame at 0xfffffe010fc77450 source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0xfffffe010fc77450 Saved registers: rbx at 0xfffffe010fc77420, rbp at 0xfffffe010fc77440, r12 at 0xfffffe010fc77428, r14 at 0xfffffe010fc77430, r15 at 0xfffffe010fc77438, rip at 0xfffffe010fc77448 probe = 0xffffffff844d9c50 mod = "\b" func = "\317\n\016\177\b\370\377\377" name = "" prov = 0x0 len = from = to = more here: https://reviews.freebsd.org/P171 -- Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Apr 12 05:03:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70520F90EA5 for ; Thu, 12 Apr 2018 05:03:49 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 F3F1769AA0 for ; Thu, 12 Apr 2018 05:03:48 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x229.google.com with SMTP id r145so1364708ywe.7 for ; Wed, 11 Apr 2018 22:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HZS7HQtzHjZZYHYqrgMSZaOrOek4SgV/cASFmnXhvws=; b=G9KagCI2XaG4Zj2oEhDk+rrNP5Dd+K8mwmUPfsY9zhCbxEHbc8YvxD6WMYF7g6Ecgx RrRFWbSmwA6FLJ+a2k5C4+2dtH4igYxzv1f8E24zYqxdBaIY6SzkR7LRqYtQ0I+LbKBJ +Willf7lJdMvzxYrEWEu2NSH4BRER0HzCMj2A= 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:content-transfer-encoding; bh=HZS7HQtzHjZZYHYqrgMSZaOrOek4SgV/cASFmnXhvws=; b=O9Qp8cKTgBm8tR41VjeZNw1HDbSKAcUglhf30o7R/RTAZK+VC2BICpaGe+5k4pRrzW GrEGy4M4te9B86m4nu1dllN82Wn8wZcAijqDjW6cU83MuXTGgL4MblqEPcZo2uIe68Pd lMUYfHCr7VRYCfuX0YDOxozGDjMh9vTRtgOpUd581hfxjyHtTqhtxqjNsvkigIvObrZb PjBt+78/FTMZAkbuTxhXmtv8N2DjjQ090bR0q505sxsW2S9GEr4XEFLPRbIWqvqZjNS8 cOYf3+wtOsZ67OCUJo/a2s9VUvq5Wnq311v47spjg6Y25FcKLwRdVjD+vueGGQ6syxok aptw== X-Gm-Message-State: ALQs6tAoWIi9ugiHCDnxsls51J9GV+WbkYJmW7/6ecVei2ctmhZS6tI2 +tZF8vD1CW8sGThUXhkVPvN0nxOloVtpYvfEim516g== X-Google-Smtp-Source: AIpwx4+yLimENwQC5ARdyrfJXadHNN00k5R5WB0goGanGf2ZjNqfCb36qQoCbC+6lzyRghRUmn1tJ2gzhul+d2EDtaY= X-Received: by 10.13.196.70 with SMTP id g67mr3271383ywd.387.1523509428266; Wed, 11 Apr 2018 22:03:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 22:03:17 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Wed, 11 Apr 2018 22:03:17 -0700 Message-ID: Subject: Re: Crypto READ request failed (error=22). md10.eli[READ(offset=818688, length=512 To: Allan Jude Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 05:03:49 -0000 On 11 April 2018 at 18:27, Allan Jude wrote: > On 04/11/2018 20:36, Eitan Adler wrote: >> vmcore.0 and kernel are available. I'll llkely spend some time this >> weekend looking at the issues but if anyone cares to get to this >> first: >> >> >> https://reviews.freebsd.org/P166 >> >> ---- >> >> Unread portion of the kernel message buffer: >> [173352] GEOM_ELI: Device md10.eli created. >> [173352] GEOM_ELI: Encryption: AES-XTS 128 >> [173352] GEOM_ELI: Integrity: HMAC/SHA1 >> [173352] GEOM_ELI: Crypto: hardware >> [173352] GEOM_ELI: Crypto READ request failed (error=3D22). >> md10.eli[READ(offset=3D818688, length=3D512 >> )] =E2=88=B4sudo kyua --loglevel=3Ddebug test sys/geom/class/eli/init_test is how to reproduce and it fails right after [13174 04:59:40.967 eax@fasteagle /usr/tests !2!]=E2=88=B4sudo kyua --loglevel=3Ddebug test sys/geom/class/eli/init_test sys/geom/class/eli/init_test:init -> failed: Miscompare for ealgo=3Daes-xts keylen=3D128 sec=3D512 [0.070s] sys/geom/class/eli/init_test:init_B -> passed [3.507s] sys/geom/class/eli/init_test:init_J -> passed [78.789s] sys/geom/class/eli/init_test:init_a -> --=20 Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Apr 12 06:11:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F02DEF9657D for ; Thu, 12 Apr 2018 06:11:49 +0000 (UTC) (envelope-from agapon@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 674727B0EB for ; Thu, 12 Apr 2018 06:11:49 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2BED0F96576; Thu, 12 Apr 2018 06:11:49 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E381EF9656C for ; Thu, 12 Apr 2018 06:11:48 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59BCF7B0BC for ; Thu, 12 Apr 2018 06:11:48 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f54.google.com with SMTP id x125-v6so5966084lff.1 for ; Wed, 11 Apr 2018 23:11:48 -0700 (PDT) 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lLvFqo1zgg7P7Lo205el2PPbirT2jg5LpYyCYaJSn18=; b=dx4s8bVp+TiJmT5JvabEKtteJpfhVZU5FEpNf9s6n03YLgy4sfqS5ubve6Zr9JKtTe PPy0BbCC/2YwQfigKXboUjktD3ox+o0+eQY0FcEnPLV0InNCAT6Fp33hDI2fLLfpwlZ/ /vtBOarLJQIdtCE3UasW4qrZzJLY+kFFOupLqr6ppNToKligwatH+4vxhCgK0mmIVQaD KtJuc+PsYiU036p0hbuAxSzkXBofAMikOZaA1AVxDNuFSe7x7Lh7Pr5l2Iua4gksZ/tT r7tkY2ys4K/KDMY9l3i6iP95O0V0tfmG6bubUbGg8IYl4lPlX30ZcwRc3F6Yhailc/ff oVOw== X-Gm-Message-State: ALQs6tCTVjLe8DtaJWFJyl2Y08a2gVTz99Zj1YjjA8ZjvqoIUHxqqLCG IQcTJQXMJxBn5rZU4Ct2X9PiHdLv X-Google-Smtp-Source: AIpwx49OUY614xiAW6Adf2kcKY/XkaSwgT+eqozZ+uEfb8/ksOryublsq8Ty5Lo0TuMCFS09jYORSA== X-Received: by 2002:a19:9c0d:: with SMTP id f13-v6mr4498850lfe.9.1523513500303; Wed, 11 Apr 2018 23:11:40 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id q22sm462607ljj.68.2018.04.11.23.11.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 23:11:39 -0700 (PDT) Subject: Re: panic: deadlkres: possible deadlock detected for 0xfffff80141b04560, blocked for 1801695 ticks To: Eitan Adler , "hackers@freebsd.org" References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <33e482b2-ee50-bd72-51d6-bb320cc95b82@FreeBSD.org> Date: Thu, 12 Apr 2018 09:11:38 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 06:11:50 -0000 On 12/04/2018 07:00, Eitan Adler wrote: > How to reproduce? > > # kldload sem > # kldunload sem > < wait debug.deadlkres.slptime_threshold seconds > > > https://reviews.freebsd.org/P168 > Reading symbols from ./kernel/kernel...Reading symbols from > /usr/home/eax/crashes/sem_load_dklres/kernel/kernel.debug...done. > done. > > Unread portion of the kernel message buffer: > [29474] panic: deadlkres: possible deadlock detected for > 0xfffff80141b04560, blocked for 1801695 ticks The debugging information you provided does not help. You need to do (gdb) p *(struct thread*)0xfffff80141b04560 <=== taken from the panic message find td_tid value and then do (gdb) tid And then examine that thread. I guess that the deadlkres could be enhanced to print the tid and the stack trace of the deadlocked thread, so that it is faster to get started. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Thu Apr 12 07:28:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A55DAF9C631 for ; Thu, 12 Apr 2018 07:28:00 +0000 (UTC) (envelope-from lists@eitanadler.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 3CBD36C279 for ; Thu, 12 Apr 2018 07:28:00 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 01847F9C62C; Thu, 12 Apr 2018 07:28:00 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEA2DF9C62B for ; Thu, 12 Apr 2018 07:27:59 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 671456C25C for ; Thu, 12 Apr 2018 07:27:59 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x235.google.com with SMTP id k199-v6so1481338ybk.12 for ; Thu, 12 Apr 2018 00:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=icj/FmmeBOnW9FSMcT0pzpu6HBc7M3gY1958t/gkCC0=; b=QleyyEzJwEkwYY2RbR56vLniidWx1TBO0H+pm4jmAtbI4qQc6QcAzpteGYxD0FuM4H zLdowNV7tm+3bVkRqmbiLYWGp2SfO+tlIaZY9s7FB+ERbMji9aubPoVRFnz9a9bEpSZd QJ1ji+so0rrJyf40RJEyXHIoRUivbitge3sqI= 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=icj/FmmeBOnW9FSMcT0pzpu6HBc7M3gY1958t/gkCC0=; b=AucvdxxZaG7d4CdlxDRMf5YC6gqf5iKgi3KqTmHaACgmDLSqWwix6wqa52RdUIeNDo nBczpP/N4jURzxgSbuefjwJFc/DpYuQXWBUDarZtFmBsqHGT2OLl4GK0D41VzsZcCdew 0trMDv9UqTFYSwuGFiC2MNTPck8hpRE0Qpa8PT3Q8PbQU7fb2c2jex7xlChUBoNu3XYx YRy2VWfF6Q+EQ1eNjVpq4qB8Lheg9Wtr0RmT4MPbg2LRFB6ZL66GgbffHxM0hfzBymh/ K8Gs6ls6lH/I9PfHQpNrSALF3kPECPe+Aj1zkrBAlswWFmbTYNaCbO4L0T+AmQKcCwN9 EDrQ== X-Gm-Message-State: ALQs6tDq2G5/9gkndHjHd5Fbzbohp0OiBQa2naqbFHh+OmrRw09GbECu Ibotnksc79cduBMBS1Tc8opV3/dOHzUPYQwFS3Z7RA== X-Google-Smtp-Source: AIpwx4/kxKPogVCY05BmFiCJ5u/eeeLMgdS+dG611bryG0OIDYH2a84f1TIJT1o0rFJn5yl6OxBjl09hTX22vxjJcqA= X-Received: by 2002:a25:268f:: with SMTP id m137-v6mr3484245ybm.460.1523518078608; Thu, 12 Apr 2018 00:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:98c3:0:0:0:0:0 with HTTP; Thu, 12 Apr 2018 00:27:28 -0700 (PDT) In-Reply-To: <33e482b2-ee50-bd72-51d6-bb320cc95b82@FreeBSD.org> References: <33e482b2-ee50-bd72-51d6-bb320cc95b82@FreeBSD.org> From: Eitan Adler Date: Thu, 12 Apr 2018 00:27:28 -0700 Message-ID: Subject: Re: panic: deadlkres: possible deadlock detected for 0xfffff80141b04560, blocked for 1801695 ticks To: Andriy Gapon Cc: "hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 07:28:01 -0000 On 11 April 2018 at 23:11, Andriy Gapon wrote: > On 12/04/2018 07:00, Eitan Adler wrote: >> How to reproduce? >> >> # kldload sem >> # kldunload sem >> < wait debug.deadlkres.slptime_threshold seconds > >> >> https://reviews.freebsd.org/P168 >> Reading symbols from ./kernel/kernel...Reading symbols from >> /usr/home/eax/crashes/sem_load_dklres/kernel/kernel.debug...done. >> done. >> >> Unread portion of the kernel message buffer: >> [29474] panic: deadlkres: possible deadlock detected for >> 0xfffff80141b04560, blocked for 1801695 ticks > > The debugging information you provided does not help. > You need to do > (gdb) p *(struct thread*)0xfffff80141b04560 <=== taken from the panic message > find td_tid value and then do > (gdb) tid > And then examine that thread. > > I guess that the deadlkres could be enhanced to print the tid and the stack > trace of the deadlocked thread, so that it is faster to get started. (kgdb) p (*(struct thread*)0xfffff80141b04560).td_tid $2 = 0x18bd8 (kgdb) tid 18bd8 (kgdb) bt #0 sched_switch (td=0xfffff80141b04560, newtd=0xfffff80003699000, flags=) at /usr/src/sys/kern/sched_ule.c:2115 #1 0xffffffff80b7156c in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:437 #2 0xffffffff80bba7ed in sleepq_switch (wchan=0xffffffff81deb2d8 , pri=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:613 #3 0xffffffff80bba693 in sleepq_wait (wchan=0xffffffff81deb2d8 , pri=0x0) at /usr/src/sys/kern/subr_sleepqueue.c:692 #4 0xffffffff80b6f329 in _sx_xlock_hard (sx=0xffffffff81deb2d8 , x=, opts=, file=, line=) at /usr/src/sys/kern/kern_sx.c:777 #5 0xffffffff80b6ef31 in _sx_xlock (sx=0xffffffff81deb2d8 , opts=0x0, file=0xffffffff811a5d65 "/usr/src/sys/kern/kern_linker.c", line=0x42e) at /usr/src/sys/kern/kern_sx.c:319 #6 0xffffffff80b3834e in kern_kldload (td=, file=, fileid=0xfffffe00af1f8964) at /usr/src/sys/kern/kern_linker.c:1070 #7 0xffffffff80b3848b in sys_kldload (td=0xfffff80141b04560, uap=) at /usr/src/sys/kern/kern_linker.c:1097 #8 0xffffffff8102606b in syscallenter (td=0xfffff80141b04560) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:134 #9 amd64_syscall (td=0xfffff80141b04560, traced=0x0) at /usr/src/sys/amd64/amd64/trap.c:936 #10 #11 0x00000008002cfd8a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffd478 (kgdb) frame Stack level 3, frame at 0xfffffe00af1f8820: rip = 0xffffffff80bba693 in sleepq_wait (/usr/src/sys/kern/subr_sleepqueue.c:692); saved rip = 0xffffffff80b6f329 called by frame at 0xfffffe00af1f88d0, caller of frame at 0xfffffe00af1f87f0 source language c. Arglist at 0xfffffe00af1f8810, args: wchan=0xffffffff81deb2d8 , pri=0x0 Locals at 0xfffffe00af1f8810, Previous frame's sp is 0xfffffe00af1f8820 Saved registers: rbx at 0xfffffe00af1f87f8, rbp at 0xfffffe00af1f8810, r14 at 0xfffffe00af1f8800, r15 at 0xfffffe00af1f8808, rip at 0xfffffe00af1f8818 wchan = 0xffffffff81deb2d8 pri = 0x0 td = 0xfffff80141b04560 Updated paste with more info as well -- Eitan Adler From owner-freebsd-hackers@freebsd.org Fri Apr 13 01:30:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7F23FA23D2 for ; Fri, 13 Apr 2018 01:30:43 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 7DABC8DD59 for ; Fri, 13 Apr 2018 01:30:43 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-ot0-x229.google.com with SMTP id h55-v6so8189800ote.9 for ; Thu, 12 Apr 2018 18:30:43 -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=Rs5tSDuLqcwG4j6FsyZs0NCePc1J/j/OnTTcPgyUFzo=; b=REDj+D6Z3iYm3G6/h9mFuRStDYXaM3BNlUKlJi6KdiqsbW56B7dNKfTh69e27Sm01B RHKEO8a9MWsf35YEdIweMo5Buy0mFL8yjcxOkgS0luSc9OGCZx6APEW5gCWnN71jWU4x Fx5LUSD67OZ9tgi9Ct/7TzoLJGJgL4YDRrfHpx0J6bs3MNAtqO9b0PKYAd7QB+mKF3oO CfGXKRtfMbs04qRyHiG8WE7wabtECPlhAVgZDTc4s0kRku5rh5x5LCAH6VwR31WTWvMi n24VDJNnDjHAXu0z9gWy/la78fD1m2iK2lfVH0riaSdgqqqBCc5+N635na8vRwiwyiPy 6yIw== 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=Rs5tSDuLqcwG4j6FsyZs0NCePc1J/j/OnTTcPgyUFzo=; b=ou8do83fUHBSu+oiVEuvJmimfArGuZTNFRCxDHWIjjJ9KG9WMJVFn6/Hz2DaK9EuEm z7oi81TIugFjDVWsul7yozwOe2nASa/gxZuvYfnoM6Rd40zOVi1qbAE/wBA1+tf3FECN 6g60TFtBddHRgJ0jZejrN0er3IH2BoCWQthXzXsaqIAI7DiyosV3QhiIJ8mpixkz+z7u ZsIXZc6GaAK5t0XpufbIQjIzIbZ59NXUKeVB16ieui3plj6s+wyZWKvyoqoSr6HXQhi5 h7FT7skwA54nBHJzTP4APnDr8hO/K6fDVFnz65QEd5LocO1M3/4LKYPru6MxTlfUHrS9 tc8w== X-Gm-Message-State: ALQs6tA7Ebja4b0cAKEoFRfAVNaMvnrS9iXFp/EqdaehjwDaVRiPQ/Hn RiEssC6QlHLTZ0NDm8TmPYkVi52xxk490hF5ejE= X-Google-Smtp-Source: AIpwx49lkS47YFq3dsZziObK20r0WErArOxLiUC5QQJjWY29z2KalLxAhddjLa+ODr2Vzj9gPc/8oeYehpQGnE3u26g= X-Received: by 2002:a9d:11a5:: with SMTP id v34-v6mr2116826otf.215.1523583042565; Thu, 12 Apr 2018 18:30:42 -0700 (PDT) MIME-Version: 1.0 From: Alfonso Sabato Siciliano Date: Fri, 13 Apr 2018 01:30:32 +0000 Message-ID: Subject: mount system call for nullfs To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 01:30:44 -0000 Hello, I would use "mount" system call int mount(const char *type, const char *dir, int flags, void *data); to mount a nullfs, the problem is about *data; Where can I find docs? Example? Code? (the implementation of mount_nullfs(8) uses nmount syscall so it is not usefulI; I put a string "/mount_from_dir" then errno = 45, so I think it should be a struct) Thanks Alfonso From owner-freebsd-hackers@freebsd.org Fri Apr 13 02:30:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B4FBF81CFA for ; Fri, 13 Apr 2018 02:30:20 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 EF07275881 for ; Fri, 13 Apr 2018 02:30:19 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-yb0-x22e.google.com with SMTP id 185-v6so1395519ybv.0 for ; Thu, 12 Apr 2018 19:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ZinnaKtll88UNq0AStecr5ut/t4T5dZ1J++I/CZIKVk=; b=Txc/5R4Quyotu0icMNuDulDotZyVHXrWvnBMikRoJYJvqith1/zWEHbPwfgs684MKa 216NKHbkGq616kfV6rKRkuzlwmyzQtpeCLqf2MCV+u4APCEd6C/YOVXNUpuklVAYuLgH 7bT1tTlgb4PdhQsUlj3O2H0Cd2JrPYp/VML0YapF3e05p+7fuFzQfenyXKYkZxN1qJYc ty1zgMUnoFlBH2Mr6ybATTTOng6uVvJOvirFxFHHD4qUoQfQqaJd2UINBK8S7CHg2anY cP30U1tvy2cpBsxYPlfNLa0Lc3eYvQdxkFBZUaKqM8PkiGL3sQ3GMaFFETI32MaqrG47 ByDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:cc:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ZinnaKtll88UNq0AStecr5ut/t4T5dZ1J++I/CZIKVk=; b=lP/7CiMsCyRdv4DoZXztMGsp6p+98WXgAA5vufEIXG/FGfNAmVOKPxahKWs6H1Tsor 5lo516xEqW7KQHdr+ESU1/kCYS6V5sr5rB0n98stnFRizbICxoS8GQfS3t8RgtBjmjPl i1GmZnI7HxNge7/+M0jSdAGCKSabBF3vUdXYd62kllh6NxeEcCz3N0h53haOrq2CP0H5 MT1+mpMRMvbND6BRLFYuBGahdtX+Y/vR17eaglcELYbhMHNmAOfk3k8QNsRQZkwu6hnX 6xyp7TeAA+tT7+oMuCsx1oxP7xR9TxpVF39m+pNvvlFnoL8NF7oPTkYe+qfhmIQZq2X3 Z7Zg== X-Gm-Message-State: ALQs6tCsy/eH0v/CrZw74V1E679o3uIMxi2GEMzhlMmJ3rTAR/3ru3Pf 9LetouAi9h+m6JFYeI9OnH/e213D X-Google-Smtp-Source: AIpwx4+9upUdv8tRRSq/9mKddl7p5vLwaO89jrt6s2aWxNjiJtpLMwsv7IyoLb4ZeokirDHE+T6+yQ== X-Received: by 2002:a25:b124:: with SMTP id g36-v6mr2843443ybj.418.1523586619252; Thu, 12 Apr 2018 19:30:19 -0700 (PDT) Received: from [168.122.154.98] (dhcp-resnet-168-122-154-98.bu.edu. [168.122.154.98]) by smtp.gmail.com with ESMTPSA id h2sm3473740qkc.27.2018.04.12.19.30.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 19:30:18 -0700 (PDT) Sender: Theron Tarigo Subject: Re: mount system call for nullfs To: Alfonso Sabato Siciliano References: From: Theron Tarigo Cc: freebsd-hackers@freebsd.org Message-ID: <76f78cee-e62a-67fb-3d84-e420c50a4ba1@gmail.com> Date: Thu, 12 Apr 2018 22:30:17 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 02:30:20 -0000 On 04/12/18 21:30, Alfonso Sabato Siciliano wrote: > Hello, > > I would use "mount" system call > > int mount(const char *type, const char *dir, int flags, void *data); > > to mount a nullfs, the problem is about *data; > > Where can I find docs? Example? Code? Hi Alfonso, The MOUNT(2) manual says:      The data argument is a pointer to a structure that contains the type      specific arguments to mount.  The format for these argument structures is      described in the manual page for each file system.  By convention file      system manual pages are named by prefixing ``mount_'' to the name of the      file system as returned by lsvfs(1).  Thus the NFS file system is      described by the mount_nfs(8) manual page.  It should be noted that a      manual page for default file systems, known as UFS and UFS2, does not      exist. Try looking at /usr/src/sbin/mount_nullfs/ for example. Cheers, Theron From owner-freebsd-hackers@freebsd.org Fri Apr 13 02:40:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F9C0F82729 for ; Fri, 13 Apr 2018 02:40:07 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 30B9C784D0 for ; Fri, 13 Apr 2018 02:40:07 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-yb0-x22e.google.com with SMTP id c1-v6so3417822ybm.2 for ; Thu, 12 Apr 2018 19:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=E9guRet8n09kYw7LT68IPT+0Cf4V9tjb6vkW9EXk2N0=; b=uMfylPnK6rMTsQDJ7xXMiAZyUmOoN77iuv0V+9bNvEwwWG3W9G1jIIbd2sKGtnPCdy CiCdD64S3vSLXK5aOUN3RLXyfOvVk9mk8JZdbeKJ6K0ab7HYNp3zZ6tjzrHHwCfGaTK0 FVjI/2dBK9mpyOF7hT+oCYuRuczHiEG2E966iOrHANcTS40adAlSyMq4yeGKVnoTPE0t 3dr+USjxmVQmNmvLHKVYBXbBGFBHwqNV3zPGycBz3Wa3JPeLEbYpM+orevYEjRaPXW64 VbtcKzJcSObQ3IMungKsk38sXwkl5jq1aT8Sb6koqO+2j1P6AUfSQFZHrHrrFQbakDfs pX8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=E9guRet8n09kYw7LT68IPT+0Cf4V9tjb6vkW9EXk2N0=; b=AWvjOhec3xwJddSSHsoGz7RT1MQ83xa6BvTbBP7KFu5TbNSLqJg8400NtdI8v6hlQK Kw8MUWuouoFsyPawN7Irl3Csk0q/TKPTg3rBQrUU0rHfR5T6nxEY7XGzph1f7p5xpRuV msZyImEF+bMrFhUE4/ZP40bGm5G6mnmEzj+3VLLMTpuyR+ukCUVdS2mX01OPTnQF3Uof 0kNB8NLWUueW9F8YoEvDnaSGU5bht9EjFjliB3A+AkitDbOZN19YOQt7q0MGYsGyTG8A l/YhiK5i8npIchbx3gIgwmVc1HMr/XcOFDeFMFMvUgDKwor0h/qvbgXxBq7lu5/uQq+G pqgQ== X-Gm-Message-State: ALQs6tAWxvQ8HNokqZAICU4CCbFcSOicxB0Z06yPUkhAYZnvRaXGoO2N gsPK52w8ykAzffhEDh8SDyQ5ozZV X-Google-Smtp-Source: AIpwx4+EO+LZ6nEUAVkkkcrIK5BvGw4A7wEFj1uMzHyI88Rphr/FXTrQXmzwYzuyb0E8476YSmO3CQ== X-Received: by 2002:a25:8e09:: with SMTP id p9-v6mr2809240ybl.352.1523587206613; Thu, 12 Apr 2018 19:40:06 -0700 (PDT) Received: from [168.122.154.98] (dhcp-resnet-168-122-154-98.bu.edu. [168.122.154.98]) by smtp.gmail.com with ESMTPSA id m53sm4292832qtf.67.2018.04.12.19.40.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 19:40:06 -0700 (PDT) Sender: Theron Tarigo Subject: Re: mount system call for nullfs From: Theron Tarigo To: Alfonso Sabato Siciliano Cc: freebsd-hackers@freebsd.org References: <76f78cee-e62a-67fb-3d84-e420c50a4ba1@gmail.com> Message-ID: <7edc3b8a-5278-dcfb-538e-a9d968dde9fc@gmail.com> Date: Thu, 12 Apr 2018 22:40:05 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <76f78cee-e62a-67fb-3d84-e420c50a4ba1@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 02:40:07 -0000 Sorry, I notice now this: On 04/12/18 21:30, Alfonso Sabato Siciliano wrote: > (the implementation of mount_nullfs(8) uses nmount syscall so it is not > usefulI; Why would mount instead of nmount be more useful? /usr/src/sbin/mount/mount.c notes that         /* XXX: We need to get away from implementing external mount          *      programs for every filesystem, and move towards having          *      each filesystem properly implement the nmount() system call.          */ It might be that mount_nullfs only works at the moment with the nmount-based implementation, in which case you would need to work around this. From owner-freebsd-hackers@freebsd.org Fri Apr 13 08:45:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64487F9B1CD for ; Fri, 13 Apr 2018 08:45:58 +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 F1EA47EA28 for ; Fri, 13 Apr 2018 08:45:57 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Fri, 13 Apr 2018 10:45:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1523609155; bh=QYMa+OKgoNx6SlCPQzbbsyoefvO9VtGBr9KPMFOHJPs=; h=Date:From:To:Subject:References:In-Reply-To; b=vppT0Q2AmADAURh7LDuweQm9GwCbBF+5OzONc+TFrb6wd53N4jm/ubOs3B1GpCgNw 6mYoYELf0x2aW4SR/GQgCaTxBLZchwKoGStuLCFGr0Rh93DAgzmuKYorTFQj/H57k9 uoy0+0GPta+gDCaZCL0JH7ECkChuc3SNA52rDt/Y61uZBZjLxBkTp+Wez+OX0a3d3n Brv1ZHeYMHc038j55pnX4ZxIZe/ZYZT4H7IHwz6x0KaAHKdgck/sq7ZGhqncDeoNQa KGXXM5ipVpe+SzDfq8wdFEsZ0tl86nmW2Gh54ZX/qL7bsKhiqViH0ZEEbIMld6shFW b3nsLO67XjQGA== Message-ID: <20180413104538.Horde.qmK8eOl8lVdSxpY1cQS83Tw@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-hackers@freebsd.org Subject: Re: Tracing with DTrace, when custom probe provider is running as regular user References: <1D449DD6-4D38-4561-8BD0-B6E581AB53A8@gmail.com> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_NTq82rNDf8Y9XZa21dthmow"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Apr 2018 11:00:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 08:45:58 -0000 This message is in MIME format and has been PGP signed. --=_NTq82rNDf8Y9XZa21dthmow Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Matthew Seaman (from Mon, 9 Apr 2018=20=20 11:30:10=20+0100): > On 09/04/2018 11:01, Daniel Dettlaff wrote: >> Issue is critical for tracing Postgresql which demands to run with >> NON privileged user, but in general launching any server software as ro= ot >> should be considered to be "harmful" / "a bad idea" right? > > The issue with allowing non-privileged users access to dtrace is the=20= =20 >=20risk of disclosing kernel memory. Unfortunately blocking this=20=20 >=20access means that using the UserSDT's from (for example)=20=20 >=20postgresql-server running as the postgres user is not permitted. If I understand it right, the original poster was also not able to=20=20 trace=20a non-root process with root-dtrace. What's the reason for this? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_NTq82rNDf8Y9XZa21dthmow Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJa0G4xAAoJEKrxQhqFIICEwE0P/iWNLg7/lWmDFrm08MEL9Dh9 GnA/B+UlLoQ/lQIvFe0Ky6veq7qTkrjwA5ls4vqiS5jPvJyqkNYJAVpxGYinVsKG 3I7XJ/v2AKsaiR0YMqbpBzyZQgKCRGE+9zchUw8ewFZCyceFnvoV1dQRoo9b3Hdj pVgOsvwPqQNnzk1KcGBBlNpT2P+wHu+ezSg2JA4G/NE7jQZECPsRuiO81BZoWrMX wRD9+Y20CEwt4XD6NKUD5uHWJVDgG6qv5MTZ5t4FXRfLnCPXD10o2iBdDrASfPUd gbFUDA00093hfsTo2lV3IBmbqqp2g5I2QEWZHrY/ixfMqlN9xeVLjVwmvsBK2UKe yXpITtLoiHtH3mkQnGSp+ba1ogjllXTUGN1xYH8m6KIc6TzoicakzUZ5NWUxY1K4 h2z7V41nY+B7Mh16PKWbXdu11eer4BTk/r+kWs/+7GZIMRinBUuF5oWKDXH90kQp AQkwlY34ruxPUoJNDdW8L8PtM4AC/S+hO+wnJRUPtlThV903mAaH8A9+IG1KoST1 FgktDPPTqAuCnrLlyvTpc1BupXhtb2GV0YWcUp+iPLIX8Tk52807B6BURBfG8gEw CM0kCXEmVTuQd8bQcIg2K9Yd8NMKFLaftERvPEG4lJD6YKs3A6uc/0eMy6fVUwdp KhdtxgjWXs75q28xSufO =+aLq -----END PGP SIGNATURE----- --=_NTq82rNDf8Y9XZa21dthmow-- From owner-freebsd-hackers@freebsd.org Sat Apr 14 04:44:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2F1BFA2EB0 for ; Sat, 14 Apr 2018 04:44:54 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 33E1D6A606 for ; Sat, 14 Apr 2018 04:44:53 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-wr0-x22b.google.com with SMTP id q6so645236wrd.6 for ; Fri, 13 Apr 2018 21:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=gjfD0WFtQmWJFpcZM6hpU2Ylr40csLf4h8rZjl3XDVU=; b=xZ51omAUXuxYztjsDUn2SOU6yjjY9JrN8dx9xywJYVBcVYuzFXhncgQ5rcWVf7lD5C baHfNbJjMtP5lEMDZnp8yfow2yIXT5gg8TZSOF4JMaQXYOaeYGz1KX8zS7dGJaiQnVQr VDzN3UiabY8xNrcX3Qp/M+Fnjy/H/FFcSBC+w3UjKW9CKLg8e54cvuJuqcCg1MD34coC Xp+0/8mfdfHolj9oGIISQckmtBLI1dVZxNy3/W6dtNnI4Ofq/8txa31Pw2uH4crmbEKn SzeVxjMQKk42ty7/S+sQ94pKtB4BBsZWkHY45i0I5/t4cdLrXglZrEmgqi74/uH8fQ9P fZSA== 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:from:date:message-id:subject :to; bh=gjfD0WFtQmWJFpcZM6hpU2Ylr40csLf4h8rZjl3XDVU=; b=K//wAMYYv0LA7aoVyASQNjWePS4N6cxKW/N0IiEaEeXh7qX1LmFOV00bndNdqI3BRU O4D9Pah7aARsNx5HRrWG+kZTGQOrpvUTY/ZgfldwjQ8WFrABfZCxHd5m8+Dl6zmJxjwj qVpSm5QLjMIvgcnHRYjdSKMxbQvGEKgvfBBIkjxNvP6MIi+RPs/RN+Tbsu9tnFlMtOYX oveak/MIRLfkcZNsQ6LB8ua+g36IyLXgbSvUD4aT3StdkXhnkt2Uo+C0jLjCjqZOOgdV UNHXK7eXo2fzxhwC8UVGpfr/SAIP6WlS0Ll/t5Y/s02hbR3ljX5JOLMn+TyyPQdyEE98 db0w== X-Gm-Message-State: ALQs6tAfxB8cYu+FbBm8xAxgF6KB2Pdyq8ksUwA6Tmr+sdXGY/fuHYGT /Z8bJku1Hy9eIBVo4pyzdrApnk5j1I8momWGMVeTXHTV X-Google-Smtp-Source: AIpwx4+l6uwdQfVZ2iTgRCsLAXQJFAkUCeXL3X+9XqVTOiEUY+Cl/+JaOT8gPyCOuELSuMlwRwmwvdRYRwAnggPIjLg= X-Received: by 10.80.169.197 with SMTP id n63mr23091156edc.20.1523681092127; Fri, 13 Apr 2018 21:44:52 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 10.80.208.17 with HTTP; Fri, 13 Apr 2018 21:44:51 -0700 (PDT) X-Originating-IP: [121.73.38.77] From: Thomas Munro Date: Sat, 14 Apr 2018 16:44:51 +1200 X-Google-Sender-Auth: oQssiEAqQmx__J1cjuniqM6xZWM Message-ID: Subject: PROC_SET_PDEATHSIG to get a signal when your parent exits To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="94eb2c194a123f6cef0569c7a6c0" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 04:44:55 -0000 --94eb2c194a123f6cef0569c7a6c0 Content-Type: text/plain; charset="UTF-8" Hello, In PostgreSQL we are planning to make use of Linux's prctl(PR_SET_PDEATHSIG) facility which tells the kernel to signal you when your parent process exits. This will cut down on polling and contention on a pipe in certain busy loops, where we need to be able to exit quickly if something kills the main supervisor process but we aren't waiting in kevent/epoll/poll-type primitive. We considered SIGIO but that'd require either one pipe per child process or a common process group, neither of which works for us. So I decided to try adding a new command PROC_SET_PDEATHSIG to procctl() to work exactly like Linux. Please see attached early draft patch. This is my first attempt at writing a patch for FreeBSD, so I expect that it contains newbie mistakes and style problems and I would be grateful for any feedback. Is this design sane? Is that the best syscall to use for this? Did I get the ptrace/orphan stuff right? Should this somehow share something with the Linux compat support for prctl(PR_SET_PDEATHSIG, ...)? Would people want this? Here's a quick and dirty userspace program I came up with while developing the patch: https://github.com/macdice/test-deathsig/blob/master/test-deathsig.c That tests a few interesting cases I thought of, but note that I haven't yet tested 32 bit support or the setuid/getuid logic. Thanks for reading, Thomas Munro --94eb2c194a123f6cef0569c7a6c0 Content-Type: application/octet-stream; name="0001-Support-PROC_SET_PDEATHSIG-as-a-command-to-procct-v1.patch" Content-Disposition: attachment; filename="0001-Support-PROC_SET_PDEATHSIG-as-a-command-to-procct-v1.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jfyw92cz0 RnJvbSBiOWE2NzMwNjk3YmEwOWY3ZWUwZjgxMTI5ZjNmOTc2ZGY4MjZkMWNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUaG9tYXMgTXVucm8gPG11bnJvQGlwOS5vcmc+CkRhdGU6IEZy aSwgMTMgQXByIDIwMTggMjM6NDE6MzAgKzAxMDAKU3ViamVjdDogW1BBVENIXSBTdXBwb3J0IFBS T0NfU0VUX1BERUFUSFNJRyBhcyBhIGNvbW1hbmQgdG8gcHJvY2N0bC4KCkFsbG93IHByb2Nlc3Nl cyB0byByZXF1ZXN0IHRoZSBkZWxpdmVyeSBvZiBhIHNpZ25hbCB1cG9uIGRlYXRoCm9mIHRoZWly IHBhcmVudCBwcm9jZXNzLiAgVGhpcyBwcm92aWRlcyBhcHByb3hpbWF0ZWx5IHRoZSBzYW1lCmJl aGF2aW91ciBhcyBwcmN0bChQUl9TRVRfUERFQVRIU0lHLCAuLi4pIG9uIExpbnV4LgoKVGhvbWFz IE11bnJvIDxtdW5yb0BpcDkub3JnPgotLS0KIGxpYi9saWJjL3N5cy9wcm9jY3RsLjIgIHwgMjkg KysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIHN5cy9rZXJuL2tlcm5fZXhlYy5jICAgIHwg IDQgKysrKwogc3lzL2tlcm4va2Vybl9leGl0LmMgICAgfCAxMyArKysrKysrKysrKysrCiBzeXMv a2Vybi9rZXJuX3Byb2NjdGwuYyB8IDMzICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr LQogc3lzL2tlcm4va2Vybl90aHJlYWQuYyAgfCAgNCArKy0tCiBzeXMvc3lzL3Byb2MuaCAgICAg ICAgICB8ICAxICsKIHN5cy9zeXMvcHJvY2N0bC5oICAgICAgIHwgIDIgKysKIDcgZmlsZXMgY2hh bmdlZCwgODMgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saWIv bGliYy9zeXMvcHJvY2N0bC4yIGIvbGliL2xpYmMvc3lzL3Byb2NjdGwuMgppbmRleCBhZjk2YWU2 ZTA0Yy4uZTQ5ZWYzNjk5NWYgMTAwNjQ0Ci0tLSBhL2xpYi9saWJjL3N5cy9wcm9jY3RsLjIKKysr IGIvbGliL2xpYmMvc3lzL3Byb2NjdGwuMgpAQCAtMzkxLDYgKzM5MSwyNCBAQCBvdGhlcndpc2Uu CiBTZWUgdGhlIG5vdGUgYWJvdXQgc3lzY3RsCiAuRHYga2Vybi50cmFwX2Vub3RjYXAKIGFib3Zl LCB3aGljaCBnaXZlcyBpbmRlcGVuZGVudCBnbG9iYWwgY29udHJvbCBvZiBzaWduYWwgZGVsaXZl cnkuCisuSXQgRHYgUFJPQ19TRVRfUERFQVRIU0lHCitSZXF1ZXN0IHRoZSBkZWxpdmVyeSBvZiBh IHNpZ25hbCB3aGVuIHRoZSBwYXJlbnQgb2YgdGhlIGNhbGxpbmcKK3Byb2Nlc3MgZXhpdHMuCitV c2UgaWQgdHlwZSBQX1BJRCBhbmQgaWQgMC4KK1RoZSB2YWx1ZSBpcyBjbGVhcmVkIGZvciB0aGUg Y2hpbGRyZW4KK29mIGZvcmsoKSBhbmQgd2hlbiBleGVjdXRpbmcgc2V0LXVzZXItSUQgb3Igc2V0 LWdyb3VwLUlEIGJpbmFyaWVzLgorLkZhIGFyZworbXVzdCBwb2ludCB0byBhIHZhbHVlIG9mIHR5 cGUgaW50IGluZGljYXRpbmcgdGhlIHNpZ25hbAordGhhdCBzaG91bGQgYmUgZGVsaXZlcmVkIHRv IHRoZSBjYWxsZXIuICBVc2UgemVybyB0byBjYW5jZWwgdGhlCitkZWxpdmVyeSBvZiBzaWduYWxz LgorLkl0IER2IFBST0NfR0VUX1BERUFUSFNJRworUXVlcnkgdGhlIGN1cnJlbnQgc2lnbmFsIG51 bWJlciB0aGF0IHdpbGwgYmUgZGVsaXZlcmVkIHdoZW4gdGhlIHBhcmVudAorb2YgdGhlIGNhbGxp bmcgcHJvY2VzcyBleGl0cy4KK1VzZSBpZCB0eXBlIFBfUElEIGFuZCBpZCAwLgorLkZhIGFyZwor bXVzdCBwb2ludCB0byBhIG1lbW9yeSBsb2NhdGlvbiB0aGF0IGNhbiBob2xkIGEgdmFsdWUgb2Yg dHlwZSBpbnQuCitJZiBzaWduYWwgZGVsaXZlcnkgaGFzIG5vdCBiZWVuIHJlcXVlc3RlZCwgaXQg d2lsbCBjb250YWluIHplcm8KK29uIHJldHVybi4KIC5FbAogLlNoIE5PVEVTCiBEaXNhYmxpbmcg dHJhY2luZyBvbiBhIHByb2Nlc3Mgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGEgc2VjdXJpdHkK QEAgLTQ4Nyw2ICs1MDUsMTIgQEAgcGFyYW1ldGVyIGZvciB0aGUKIG9yCiAuRHYgUFJPQ19UUkFQ Q0FQX0NUTAogcmVxdWVzdCBpcyBpbnZhbGlkLgorLkl0IEJxIEVyIEVJTlZBTAorVGhlCisuRHYg UFJPQ19TRVRfUERFQVRIU0lHCitvcgorLkR2IFBST0NfR0VUX1BERUFUSFNJRworcmVxdWVzdCBy ZWZlcmVuY2VkIGFuIHVuc3VwcG9ydGVkIGlkLCBpZF90eXBlIG9yIGludmFsaWQgc2lnbmFsIG51 bWJlci4KIC5FbAogLlNoIFNFRSBBTFNPCiAuWHIgZHRyYWNlIDEgLApAQCAtNTA2LDMgKzUzMCw4 IEBAIGZ1bmN0aW9uIGFwcGVhcmVkIGluCiBUaGUgcmVhcGVyIGZhY2lsaXR5IGlzIGJhc2VkIG9u IGEgc2ltaWxhciBmZWF0dXJlIG9mIExpbnV4IGFuZAogRHJhZ29uZmx5QlNELCBhbmQgZmlyc3Qg YXBwZWFyZWQgaW4KIC5GeCAxMC4yIC4KK1RoZQorLkR2IFBST0NfU0VUX1BERUFUSFNJRworZmFj aWxpdHkgaXMgYmFzZWQgb24gdGhlIHByY3RsKFBSX1NFVF9QREVBVEhTSUcsIC4uLikgZmVhdHVy ZSBvZiBMaW51eCwKK2FuZCBmaXJzdCBhcHBlYXJlZCBpbgorLkZ4IDEyLjAgLgpkaWZmIC0tZ2l0 IGEvc3lzL2tlcm4va2Vybl9leGVjLmMgYi9zeXMva2Vybi9rZXJuX2V4ZWMuYwppbmRleCAyMWIy NWUwMTQ4Yy4uNjc5OTE1YTZlNmUgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL2tlcm5fZXhlYy5jCisr KyBiL3N5cy9rZXJuL2tlcm5fZXhlYy5jCkBAIC01MjIsNiArNTIyLDEwIEBAIGRvX2V4ZWN2ZShz dHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IGltYWdlX2FyZ3MgKmFyZ3MsIHN0cnVjdCBtYWMgKm1h Y19wKQogCWNyZWRlbnRpYWxfY2hhbmdpbmcgfD0gd2lsbF90cmFuc2l0aW9uOwogI2VuZGlmCiAK KwkvKiBEb24ndCBpbmhlcml0IFBST0NfU0VUX1BERUFUSFNJRyB2YWx1ZSBpZiBzZXR1aWQvc2V0 Z2lkLiAqLworCWlmIChjcmVkZW50aWFsX2NoYW5naW5nKQorCQlpbWdwLT5wcm9jLT5wX3BkZWF0 aHNpZyA9IDA7CisKIAlpZiAoY3JlZGVudGlhbF9jaGFuZ2luZyAmJgogI2lmZGVmIENBUEFCSUxJ VFlfTU9ERQogCSAgICAoKG9sZGNyZWQtPmNyX2ZsYWdzICYgQ1JFRF9GTEFHX0NBUE1PREUpID09 IDApICYmCmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX2V4aXQuYyBiL3N5cy9rZXJuL2tlcm5f ZXhpdC5jCmluZGV4IGY2NzJhMmM3MzU4Li41NWYwOGEwMDRlYiAxMDA2NDQKLS0tIGEvc3lzL2tl cm4va2Vybl9leGl0LmMKKysrIGIvc3lzL2tlcm4va2Vybl9leGl0LmMKQEAgLTQ4MCw2ICs0ODAs MTIgQEAgZXhpdDEoc3RydWN0IHRocmVhZCAqdGQsIGludCBydmFsLCBpbnQgc2lnbm8pCiAJCQkJ UFJPQ19MT0NLKHEtPnBfcmVhcGVyKTsKIAkJCQlwa3NpZ25hbChxLT5wX3JlYXBlciwgU0lHQ0hM RCwga3NpMSk7CiAJCQkJUFJPQ19VTkxPQ0socS0+cF9yZWFwZXIpOworCQkJfSBlbHNlIGlmIChx LT5wX3BkZWF0aHNpZyA+IDApIHsKKwkJCQkvKgorCQkJCSAqIFRoZSBjaGlsZCBhc2tlZCB0byBy ZWNlaXZlZCBhIHNpZ25hbAorCQkJCSAqIHdoZW4gd2UgZXhpdC4KKwkJCQkgKi8KKwkJCQlrZXJu X3BzaWduYWwocSwgcS0+cF9wZGVhdGhzaWcpOwogCQkJfQogCQl9IGVsc2UgewogCQkJLyoKQEAg LTUyMCw2ICs1MjYsMTMgQEAgZXhpdDEoc3RydWN0IHRocmVhZCAqdGQsIGludCBydmFsLCBpbnQg c2lnbm8pCiAJICovCiAJd2hpbGUgKChxID0gTElTVF9GSVJTVCgmcC0+cF9vcnBoYW5zKSkgIT0g TlVMTCkgewogCQlQUk9DX0xPQ0socSk7CisJCS8qCisJCSAqIElmIHdlIGFyZSB0aGUgcmVhbCBw YXJlbnQgb2YgdGhpcyBwcm9jZXNzCisJCSAqIGJ1dCBpdCBoYXMgYmVlbiByZXBhcmVudGVkIHRv IGEgZGVidWdnZXIsIHRoZW4KKwkJICogY2hlY2sgaWYgaXQgYXNrZWQgZm9yIGEgc2lnbmFsIHdo ZW4gd2UgZXhpdC4KKwkJICovCisJCWlmIChxLT5wX3BkZWF0aHNpZyA+IDApCisJCQlrZXJuX3Bz aWduYWwocSwgcS0+cF9wZGVhdGhzaWcpOwogCQlDVFIyKEtUUl9QVFJBQ0UsICJleGl0OiBwaWQg JWQsIGNsZWFyaW5nIG9ycGhhbiAlZCIsIHAtPnBfcGlkLAogCQkgICAgcS0+cF9waWQpOwogCQlj bGVhcl9vcnBoYW4ocSk7CmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX3Byb2NjdGwuYyBiL3N5 cy9rZXJuL2tlcm5fcHJvY2N0bC5jCmluZGV4IGRkZGM2YjljMWQzLi5jMGFkZWVkNTcwZSAxMDA2 NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9wcm9jY3RsLmMKKysrIGIvc3lzL2tlcm4va2Vybl9wcm9j Y3RsLmMKQEAgLTQzMSw3ICs0MzEsNyBAQCBzeXNfcHJvY2N0bChzdHJ1Y3QgdGhyZWFkICp0ZCwg c3RydWN0IHByb2NjdGxfYXJncyAqdWFwKQogCQlzdHJ1Y3QgcHJvY2N0bF9yZWFwZXJfcGlkcyBy cDsKIAkJc3RydWN0IHByb2NjdGxfcmVhcGVyX2tpbGwgcms7CiAJfSB4OwotCWludCBlcnJvciwg ZXJyb3IxLCBmbGFnczsKKwlpbnQgZXJyb3IsIGVycm9yMSwgZmxhZ3MsIHNpZ251bTsKIAogCXN3 aXRjaCAodWFwLT5jb20pIHsKIAljYXNlIFBST0NfU1BST1RFQ1Q6CkBAIC00NjcsNiArNDY3LDE1 IEBAIHN5c19wcm9jY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgcHJvY2N0bF9hcmdzICp1 YXApCiAJY2FzZSBQUk9DX1RSQVBDQVBfU1RBVFVTOgogCQlkYXRhID0gJmZsYWdzOwogCQlicmVh azsKKwljYXNlIFBST0NfU0VUX1BERUFUSFNJRzoKKwkJZXJyb3IgPSBjb3B5aW4odWFwLT5kYXRh LCAmc2lnbnVtLCBzaXplb2Yoc2lnbnVtKSk7CisJCWlmIChlcnJvciAhPSAwKQorCQkJcmV0dXJu IChlcnJvcik7CisJCWRhdGEgPSAmc2lnbnVtOworCQlicmVhazsKKwljYXNlIFBST0NfR0VUX1BE RUFUSFNJRzoKKwkJZGF0YSA9ICZzaWdudW07CisJCWJyZWFrOwogCWRlZmF1bHQ6CiAJCXJldHVy biAoRUlOVkFMKTsKIAl9CkBAIC00ODYsNiArNDk1LDEwIEBAIHN5c19wcm9jY3RsKHN0cnVjdCB0 aHJlYWQgKnRkLCBzdHJ1Y3QgcHJvY2N0bF9hcmdzICp1YXApCiAJCWlmIChlcnJvciA9PSAwKQog CQkJZXJyb3IgPSBjb3B5b3V0KCZmbGFncywgdWFwLT5kYXRhLCBzaXplb2YoZmxhZ3MpKTsKIAkJ YnJlYWs7CisJY2FzZSBQUk9DX0dFVF9QREVBVEhTSUc6CisJCWlmIChlcnJvciA9PSAwKQorCQkJ ZXJyb3IgPSBjb3B5b3V0KCZzaWdudW0sIHVhcC0+ZGF0YSwgc2l6ZW9mKHNpZ251bSkpOworCQli cmVhazsKIAl9CiAJcmV0dXJuIChlcnJvcik7CiB9CkBAIC01MjcsNiArNTQwLDcgQEAga2Vybl9w cm9jY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpZHR5cGVfdCBpZHR5cGUsIGlkX3QgaWQsIGludCBj b20sIHZvaWQgKmRhdGEpCiAJc3RydWN0IHBncnAgKnBnOwogCXN0cnVjdCBwcm9jICpwOwogCWlu dCBlcnJvciwgZmlyc3RfZXJyb3IsIG9rOworCWludCBzaWdudW07CiAJYm9vbCB0cmVlX2xvY2tl ZDsKIAogCXN3aXRjaCAoY29tKSB7CkBAIC01NjAsNiArNTc0LDIzIEBAIGtlcm5fcHJvY2N0bChz dHJ1Y3QgdGhyZWFkICp0ZCwgaWR0eXBlX3QgaWR0eXBlLCBpZF90IGlkLCBpbnQgY29tLCB2b2lk ICpkYXRhKQogCWNhc2UgUFJPQ19UUkFQQ0FQX1NUQVRVUzoKIAkJdHJlZV9sb2NrZWQgPSBmYWxz ZTsKIAkJYnJlYWs7CisJY2FzZSBQUk9DX1NFVF9QREVBVEhTSUc6CisJCXNpZ251bSA9ICooaW50 ICopZGF0YTsKKwkJaWYgKGlkdHlwZSAhPSBQX1BJRCB8fCBpZCAhPSAwIHx8CisJCSAgICAoc2ln bnVtICE9IDAgJiYgIV9TSUdfVkFMSUQoc2lnbnVtKSkpCisJCQlyZXR1cm4gKEVJTlZBTCk7CisJ CVBST0NfTE9DSyh0ZC0+dGRfcHJvYyk7CisJCXRkLT50ZF9wcm9jLT5wX3BkZWF0aHNpZyA9IHNp Z251bTsKKwkJUFJPQ19VTkxPQ0sodGQtPnRkX3Byb2MpOworCQlyZXR1cm4gKDApOworCWNhc2Ug UFJPQ19HRVRfUERFQVRIU0lHOgorCQlpZiAoaWR0eXBlICE9IFBfUElEIHx8IGlkICE9IDApCisJ CQlyZXR1cm4gKEVJTlZBTCk7CisJCVBST0NfTE9DSyh0ZC0+dGRfcHJvYyk7CisJCXNpZ251bSA9 IHRkLT50ZF9wcm9jLT5wX3BkZWF0aHNpZzsKKwkJUFJPQ19VTkxPQ0sodGQtPnRkX3Byb2MpOwor CQkqKGludCAqKWRhdGEgPSBzaWdudW07CisJCXJldHVybiAoMCk7CiAJZGVmYXVsdDoKIAkJcmV0 dXJuIChFSU5WQUwpOwogCX0KZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5fdGhyZWFkLmMgYi9z eXMva2Vybi9rZXJuX3RocmVhZC5jCmluZGV4IDRkMmYwMjAwNjNlLi5iMDFjZDk5ZTU5NyAxMDA2 NDQKLS0tIGEvc3lzL2tlcm4va2Vybl90aHJlYWQuYworKysgYi9zeXMva2Vybi9rZXJuX3RocmVh ZC5jCkBAIC05MSw3ICs5MSw3IEBAIF9TdGF0aWNfYXNzZXJ0KG9mZnNldG9mKHN0cnVjdCBwcm9j LCBwX3BpZCkgPT0gMHhiYywKICAgICAic3RydWN0IHByb2MgS0JJIHBfcGlkIik7CiBfU3RhdGlj X2Fzc2VydChvZmZzZXRvZihzdHJ1Y3QgcHJvYywgcF9maWxlbW9uKSA9PSAweDNkMCwKICAgICAi c3RydWN0IHByb2MgS0JJIHBfZmlsZW1vbiIpOwotX1N0YXRpY19hc3NlcnQob2Zmc2V0b2Yoc3Ry dWN0IHByb2MsIHBfY29tbSkgPT0gMHgzZTAsCitfU3RhdGljX2Fzc2VydChvZmZzZXRvZihzdHJ1 Y3QgcHJvYywgcF9jb21tKSA9PSAweDNlNCwKICAgICAic3RydWN0IHByb2MgS0JJIHBfY29tbSIp OwogX1N0YXRpY19hc3NlcnQob2Zmc2V0b2Yoc3RydWN0IHByb2MsIHBfZW11bGRhdGEpID09IDB4 NGI4LAogICAgICJzdHJ1Y3QgcHJvYyBLQkkgcF9lbXVsZGF0YSIpOwpAQCAtMTExLDcgKzExMSw3 IEBAIF9TdGF0aWNfYXNzZXJ0KG9mZnNldG9mKHN0cnVjdCBwcm9jLCBwX3BpZCkgPT0gMHg3NCwK ICAgICAic3RydWN0IHByb2MgS0JJIHBfcGlkIik7CiBfU3RhdGljX2Fzc2VydChvZmZzZXRvZihz dHJ1Y3QgcHJvYywgcF9maWxlbW9uKSA9PSAweDI3YywKICAgICAic3RydWN0IHByb2MgS0JJIHBf ZmlsZW1vbiIpOwotX1N0YXRpY19hc3NlcnQob2Zmc2V0b2Yoc3RydWN0IHByb2MsIHBfY29tbSkg PT0gMHgyODgsCitfU3RhdGljX2Fzc2VydChvZmZzZXRvZihzdHJ1Y3QgcHJvYywgcF9jb21tKSA9 PSAweDI4YywKICAgICAic3RydWN0IHByb2MgS0JJIHBfY29tbSIpOwogX1N0YXRpY19hc3NlcnQo b2Zmc2V0b2Yoc3RydWN0IHByb2MsIHBfZW11bGRhdGEpID09IDB4MzE0LAogICAgICJzdHJ1Y3Qg cHJvYyBLQkkgcF9lbXVsZGF0YSIpOwpkaWZmIC0tZ2l0IGEvc3lzL3N5cy9wcm9jLmggYi9zeXMv c3lzL3Byb2MuaAppbmRleCBkNjMzNjJkNzIzMi4uMTllOTk0MzkxODggMTAwNjQ0Ci0tLSBhL3N5 cy9zeXMvcHJvYy5oCisrKyBiL3N5cy9zeXMvcHJvYy5oCkBAIC02MjQsNiArNjI0LDcgQEAgc3Ry dWN0IHByb2MgewogCXVfaW50CQlwX3RyZWVmbGFnOwkvKiAoZSkgUF9UUkVFIGZsYWdzICovCiAJ aW50CQlwX3BlbmRpbmdleGl0czsgLyogKGMpIENvdW50IG9mIHBlbmRpbmcgdGhyZWFkIGV4aXRz LiAqLwogCXN0cnVjdCBmaWxlbW9uCSpwX2ZpbGVtb247CS8qIChjKSBmaWxlbW9uLXNwZWNpZmlj IGRhdGEuICovCisJaW50CQlwX3BkZWF0aHNpZzsJLyogKGMpIFNpZ25hbCBmcm9tIHBhcmVudCBv biBleGl0LiAqLwogLyogRW5kIGFyZWEgdGhhdCBpcyB6ZXJvZWQgb24gY3JlYXRpb24uICovCiAj ZGVmaW5lCXBfZW5kemVybwlwX21hZ2ljCiAKZGlmZiAtLWdpdCBhL3N5cy9zeXMvcHJvY2N0bC5o IGIvc3lzL3N5cy9wcm9jY3RsLmgKaW5kZXggMTcxNDRlOWYwYzYuLmNmMGE2OTQ3NWU0IDEwMDY0 NAotLS0gYS9zeXMvc3lzL3Byb2NjdGwuaAorKysgYi9zeXMvc3lzL3Byb2NjdGwuaApAQCAtNTEs NiArNTEsOCBAQAogI2RlZmluZQlQUk9DX1RSQUNFX1NUQVRVUwk4CS8qIHF1ZXJ5IHRyYWNpbmcg c3RhdHVzICovCiAjZGVmaW5lCVBST0NfVFJBUENBUF9DVEwJOQkvKiB0cmFwIGNhcGFiaWxpdHkg ZXJyb3JzICovCiAjZGVmaW5lCVBST0NfVFJBUENBUF9TVEFUVVMJMTAJLyogcXVlcnkgdHJhcCBj YXBhYmlsaXR5IHN0YXR1cyAqLworI2RlZmluZSBQUk9DX1NFVF9QREVBVEhTSUcJMTEJLyogc2V0 IHBhcmVudCBkZWF0aCBzaWduYWwgKi8KKyNkZWZpbmUgUFJPQ19HRVRfUERFQVRIU0lHCTEyCS8q IGdldCBwYXJlbnQgZGVhdGggc2lnbmFsICovCiAKIC8qIE9wZXJhdGlvbnMgZm9yIFBST0NfU1BS T1RFQ1QgKHBhc3NlZCBpbiBpbnRlZ2VyIGFyZykuICovCiAjZGVmaW5lCVBQUk9UX09QKHgpCSgo eCkgJiAweGYpCi0tIAoyLjE2LjIKCg== --94eb2c194a123f6cef0569c7a6c0-- From owner-freebsd-hackers@freebsd.org Sat Apr 14 18:04:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4BE0F8DB70 for ; Sat, 14 Apr 2018 18:04:29 +0000 (UTC) (envelope-from kib@freebsd.org) 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 E9E636F16B for ; Sat, 14 Apr 2018 18:04:28 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w3EI4FOn086082 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Apr 2018 21:04:19 +0300 (EEST) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w3EI4FOn086082 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w3EI4FVY086081; Sat, 14 Apr 2018 21:04:15 +0300 (EEST) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sat, 14 Apr 2018 21:04:15 +0300 From: Konstantin Belousov To: Thomas Munro Cc: freebsd-hackers@freebsd.org Subject: Re: PROC_SET_PDEATHSIG to get a signal when your parent exits Message-ID: <20180414180415.GC1774@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 18:04:30 -0000 On Sat, Apr 14, 2018 at 04:44:51PM +1200, Thomas Munro wrote: > Hello, > > In PostgreSQL we are planning to make use of Linux's > prctl(PR_SET_PDEATHSIG) facility which tells the kernel to signal you > when your parent process exits. This will cut down on polling and > contention on a pipe in certain busy loops, where we need to be able > to exit quickly if something kills the main supervisor process but we > aren't waiting in kevent/epoll/poll-type primitive. We considered > SIGIO but that'd require either one pipe per child process or a common > process group, neither of which works for us. So I decided to try > adding a new command PROC_SET_PDEATHSIG to procctl() to work exactly > like Linux. > > Please see attached early draft patch. This is my first attempt at > writing a patch for FreeBSD, so I expect that it contains newbie > mistakes and style problems and I would be grateful for any feedback. > Is this design sane? Is that the best syscall to use for this? Did I > get the ptrace/orphan stuff right? Should this somehow share > something with the Linux compat support for prctl(PR_SET_PDEATHSIG, > ...)? Would people want this? Do we support prctl(2) in linuxolator ? Even if yes, I doubt that there is PR_SET_PDEATHSIG feature. > > Here's a quick and dirty userspace program I came up with while > developing the patch: > > https://github.com/macdice/test-deathsig/blob/master/test-deathsig.c > > That tests a few interesting cases I thought of, but note that I > haven't yet tested 32 bit support or the setuid/getuid logic. Compile the test program using "cc -m32 -o test-deathsig-32 ...." to easily get binary for compat32 testing. We have test framework, and several procctl(2) tests already. Please look at the tests/sys/kern/reaper.c. You might consider converting your test to the framework and also adding it to the base system. Other comments inline. You may create the account at https://reviews.freebsd.org and putting patch there. > From b9a6730697ba09f7ee0f81129f3f976df826d1cd Mon Sep 17 00:00:00 2001 > From: Thomas Munro > Date: Fri, 13 Apr 2018 23:41:30 +0100 > Subject: [PATCH] Support PROC_SET_PDEATHSIG as a command to procctl. > > Allow processes to request the delivery of a signal upon death > of their parent process. This provides approximately the same > behaviour as prctl(PR_SET_PDEATHSIG, ...) on Linux. > > Thomas Munro > --- > lib/libc/sys/procctl.2 | 29 +++++++++++++++++++++++++++++ > sys/kern/kern_exec.c | 4 ++++ > sys/kern/kern_exit.c | 13 +++++++++++++ > sys/kern/kern_procctl.c | 33 ++++++++++++++++++++++++++++++++- > sys/kern/kern_thread.c | 4 ++-- > sys/sys/proc.h | 1 + > sys/sys/procctl.h | 2 ++ > 7 files changed, 83 insertions(+), 3 deletions(-) > > diff --git a/lib/libc/sys/procctl.2 b/lib/libc/sys/procctl.2 > index af96ae6e04c..e49ef36995f 100644 > --- a/lib/libc/sys/procctl.2 > +++ b/lib/libc/sys/procctl.2 > @@ -391,6 +391,24 @@ otherwise. > See the note about sysctl > .Dv kern.trap_enotcap > above, which gives independent global control of signal delivery. > +.It Dv PROC_SET_PDEATHSIG > +Request the delivery of a signal when the parent of the calling > +process exits. > +Use id type P_PID and id 0. Use .Fa id type .Dv P_PID and .Fa id 0. In fact, '0' is ok as an alias for the current pid, but not allowing current pid as the argument is strange. I can see why you only allow the process to set the parent signal only on itself, but also can see that it does not cost anything to allow arbitrary pid. But I do not see how would pfind(0) return curproc. Don't you need to add some code for this in kern_procctl() ? > +The value is cleared for the children > +of fork() and when executing set-user-ID or set-group-ID binaries. .Xr fork 2 > +.Fa arg > +must point to a value of type int indicating the signal > +that should be delivered to the caller. Use zero to cancel the Start new sentence from the new line. > +delivery of signals. > +.It Dv PROC_GET_PDEATHSIG > +Query the current signal number that will be delivered when the parent > +of the calling process exits. > +Use id type P_PID and id 0. Same markup. > +.Fa arg > +must point to a memory location that can hold a value of type int. > +If signal delivery has not been requested, it will contain zero > +on return. > .El > .Sh NOTES > Disabling tracing on a process should not be considered a security > @@ -487,6 +505,12 @@ parameter for the > or > .Dv PROC_TRAPCAP_CTL > request is invalid. > +.It Bq Er EINVAL > +The > +.Dv PROC_SET_PDEATHSIG > +or > +.Dv PROC_GET_PDEATHSIG > +request referenced an unsupported id, id_type or invalid signal number. > .El > .Sh SEE ALSO > .Xr dtrace 1 , > @@ -506,3 +530,8 @@ function appeared in > The reaper facility is based on a similar feature of Linux and > DragonflyBSD, and first appeared in > .Fx 10.2 . > +The > +.Dv PROC_SET_PDEATHSIG > +facility is based on the prctl(PR_SET_PDEATHSIG, ...) feature of Linux, > +and first appeared in > +.Fx 12.0 . > diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c > index 21b25e0148c..679915a6e6e 100644 > --- a/sys/kern/kern_exec.c > +++ b/sys/kern/kern_exec.c > @@ -522,6 +522,10 @@ do_execve(struct thread *td, struct image_args *args, struct mac *mac_p) > credential_changing |= will_transition; > #endif > > + /* Don't inherit PROC_SET_PDEATHSIG value if setuid/setgid. */ > + if (credential_changing) > + imgp->proc->p_pdeathsig = 0; > + What is the Linux behaviour on exec ? It seems of negative value to receive a signal which disposition is reset to default. In other words, for the non-suid image, you typicall get the process terminated and perhaps core dumped when parent is exiting. > if (credential_changing && > #ifdef CAPABILITY_MODE > ((oldcred->cr_flags & CRED_FLAG_CAPMODE) == 0) && > diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > index f672a2c7358..55f08a004eb 100644 > --- a/sys/kern/kern_exit.c > +++ b/sys/kern/kern_exit.c > @@ -480,6 +480,12 @@ exit1(struct thread *td, int rval, int signo) > PROC_LOCK(q->p_reaper); > pksignal(q->p_reaper, SIGCHLD, ksi1); > PROC_UNLOCK(q->p_reaper); > + } else if (q->p_pdeathsig > 0) { > + /* > + * The child asked to received a signal > + * when we exit. > + */ > + kern_psignal(q, q->p_pdeathsig); Don't you need to lock q around kern_psignal() ? Test your patch with WITNESS and INVARIANTS kernel options enabled. > } > } else { > /* > @@ -520,6 +526,13 @@ exit1(struct thread *td, int rval, int signo) > */ > while ((q = LIST_FIRST(&p->p_orphans)) != NULL) { > PROC_LOCK(q); > + /* > + * If we are the real parent of this process > + * but it has been reparented to a debugger, then > + * check if it asked for a signal when we exit. > + */ > + if (q->p_pdeathsig > 0) > + kern_psignal(q, q->p_pdeathsig); > CTR2(KTR_PTRACE, "exit: pid %d, clearing orphan %d", p->p_pid, > q->p_pid); > clear_orphan(q); > diff --git a/sys/kern/kern_procctl.c b/sys/kern/kern_procctl.c > index dddc6b9c1d3..c0adeed570e 100644 > --- a/sys/kern/kern_procctl.c > +++ b/sys/kern/kern_procctl.c > @@ -431,7 +431,7 @@ sys_procctl(struct thread *td, struct procctl_args *uap) > struct procctl_reaper_pids rp; > struct procctl_reaper_kill rk; > } x; > - int error, error1, flags; > + int error, error1, flags, signum; > > switch (uap->com) { > case PROC_SPROTECT: > @@ -467,6 +467,15 @@ sys_procctl(struct thread *td, struct procctl_args *uap) > case PROC_TRAPCAP_STATUS: > data = &flags; > break; > + case PROC_SET_PDEATHSIG: > + error = copyin(uap->data, &signum, sizeof(signum)); > + if (error != 0) > + return (error); > + data = &signum; > + break; > + case PROC_GET_PDEATHSIG: > + data = &signum; > + break; > default: > return (EINVAL); > } > @@ -486,6 +495,10 @@ sys_procctl(struct thread *td, struct procctl_args *uap) > if (error == 0) > error = copyout(&flags, uap->data, sizeof(flags)); > break; > + case PROC_GET_PDEATHSIG: > + if (error == 0) > + error = copyout(&signum, uap->data, sizeof(signum)); > + break; > } > return (error); > } > @@ -527,6 +540,7 @@ kern_procctl(struct thread *td, idtype_t idtype, id_t id, int com, void *data) > struct pgrp *pg; > struct proc *p; > int error, first_error, ok; > + int signum; > bool tree_locked; > > switch (com) { > @@ -560,6 +574,23 @@ kern_procctl(struct thread *td, idtype_t idtype, id_t id, int com, void *data) > case PROC_TRAPCAP_STATUS: > tree_locked = false; > break; > + case PROC_SET_PDEATHSIG: > + signum = *(int *)data; > + if (idtype != P_PID || id != 0 || > + (signum != 0 && !_SIG_VALID(signum))) > + return (EINVAL); > + PROC_LOCK(td->td_proc); > + td->td_proc->p_pdeathsig = signum; > + PROC_UNLOCK(td->td_proc); > + return (0); > + case PROC_GET_PDEATHSIG: > + if (idtype != P_PID || id != 0) > + return (EINVAL); > + PROC_LOCK(td->td_proc); > + signum = td->td_proc->p_pdeathsig; > + PROC_UNLOCK(td->td_proc); > + *(int *)data = signum; Why do you need to mediate assignment through the signum ? Note that the locking around the lone integer assignment is excessive, but it does not hurt. > + return (0); > default: > return (EINVAL); > } > diff --git a/sys/kern/kern_thread.c b/sys/kern/kern_thread.c > index 4d2f020063e..b01cd99e597 100644 > --- a/sys/kern/kern_thread.c > +++ b/sys/kern/kern_thread.c > @@ -91,7 +91,7 @@ _Static_assert(offsetof(struct proc, p_pid) == 0xbc, > "struct proc KBI p_pid"); > _Static_assert(offsetof(struct proc, p_filemon) == 0x3d0, > "struct proc KBI p_filemon"); > -_Static_assert(offsetof(struct proc, p_comm) == 0x3e0, > +_Static_assert(offsetof(struct proc, p_comm) == 0x3e4, > "struct proc KBI p_comm"); > _Static_assert(offsetof(struct proc, p_emuldata) == 0x4b8, > "struct proc KBI p_emuldata"); > @@ -111,7 +111,7 @@ _Static_assert(offsetof(struct proc, p_pid) == 0x74, > "struct proc KBI p_pid"); > _Static_assert(offsetof(struct proc, p_filemon) == 0x27c, > "struct proc KBI p_filemon"); > -_Static_assert(offsetof(struct proc, p_comm) == 0x288, > +_Static_assert(offsetof(struct proc, p_comm) == 0x28c, > "struct proc KBI p_comm"); > _Static_assert(offsetof(struct proc, p_emuldata) == 0x314, > "struct proc KBI p_emuldata"); > diff --git a/sys/sys/proc.h b/sys/sys/proc.h > index d63362d7232..19e99439188 100644 > --- a/sys/sys/proc.h > +++ b/sys/sys/proc.h > @@ -624,6 +624,7 @@ struct proc { > u_int p_treeflag; /* (e) P_TREE flags */ > int p_pendingexits; /* (c) Count of pending thread exits. */ > struct filemon *p_filemon; /* (c) filemon-specific data. */ > + int p_pdeathsig; /* (c) Signal from parent on exit. */ > /* End area that is zeroed on creation. */ > #define p_endzero p_magic > > diff --git a/sys/sys/procctl.h b/sys/sys/procctl.h > index 17144e9f0c6..cf0a69475e4 100644 > --- a/sys/sys/procctl.h > +++ b/sys/sys/procctl.h > @@ -51,6 +51,8 @@ > #define PROC_TRACE_STATUS 8 /* query tracing status */ > #define PROC_TRAPCAP_CTL 9 /* trap capability errors */ > #define PROC_TRAPCAP_STATUS 10 /* query trap capability status */ > +#define PROC_SET_PDEATHSIG 11 /* set parent death signal */ > +#define PROC_GET_PDEATHSIG 12 /* get parent death signal */ Note that other commands names follow the pattern PROC__, in your case it would be PROC_PDEATHSIG_SET/GET. Please use tab after #define. > > /* Operations for PROC_SPROTECT (passed in integer arg). */ > #define PPROT_OP(x) ((x) & 0xf) > -- > 2.16.2 >