From owner-freebsd-hackers@freebsd.org Sun Dec 9 03:47:35 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 043571335A3B for ; Sun, 9 Dec 2018 03:47:35 +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 22D0F76F3B for ; Sun, 9 Dec 2018 03:47:34 +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 0F56E1E46E for ; Sun, 9 Dec 2018 03:47:27 +0000 (UTC) Subject: Re: "gptzfsboot: No ZFS pools located, can't boot." - What am I doing wrong? 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: <31bbc0ab-b551-5dc7-69c2-e0341da0d7db@freebsd.org> Date: Sat, 8 Dec 2018 22:47:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GOc30Wfxa8Qepog3XmrdZZlvxkYdbPGsQ" X-Rspamd-Queue-Id: 22D0F76F3B X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2018 03:47:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GOc30Wfxa8Qepog3XmrdZZlvxkYdbPGsQ Content-Type: multipart/mixed; boundary="hnd9ozNUbDCKzLx680cph3FBEFolursod"; protected-headers="v1" From: Allan Jude To: freebsd-hackers@freebsd.org Message-ID: <31bbc0ab-b551-5dc7-69c2-e0341da0d7db@freebsd.org> Subject: Re: "gptzfsboot: No ZFS pools located, can't boot." - What am I doing wrong? References: In-Reply-To: --hnd9ozNUbDCKzLx680cph3FBEFolursod Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-12-07 19:14, Hubert Hauser wrote: > I'm trying to do FreeBSD dual-boot with Debian on legacy BIOS. My > partition scheme is: >=20 > =C2=A0- /dev/ada0 (gpt) > =C2=A0 - /dev/ada0p1 (bios boot) > =C2=A0 - /dev/ada0p2 (linux filesystem) > =C2=A0 - /dev/ada0p3 (linux filesystem) > =C2=A0 - /dev/ada0p4 (freebsd boot) > =C2=A0 - /dev/ada0p5 (freebsd swap) > =C2=A0 - /dev/ada0p6 (freebsd zfs) >=20 > I've followed these instructions (link: > https://wiki.freebsd.org/MasonLoringBliss/LegacyZFSandGELI) but > unfortunately, I've got the following error during booting system: > "gptzfsboot: No ZFS pools located, can't boot." >=20 > What am I doing wrong? >=20 > _______________________________________________ > 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 Can you provide the output for `gpart show` Are your disks encrypted? Make sure they are set for geliboot: geli configure -g adaXpY --=20 Allan Jude --hnd9ozNUbDCKzLx680cph3FBEFolursod-- --GOc30Wfxa8Qepog3XmrdZZlvxkYdbPGsQ 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) iQIcBAEBAgAGBQJcDJBOAAoJEBmVNT4SmAt+ER0P/iXyKBrWO8Od0jQeXYxheCeQ C4iXDb50cS+tfRMjHCK314X3cO/mBNLQrLSbDm8VHOONplBV1vyCoMYXjGl8WLqQ 6/cLbgCVbI7PBfYEWXb2gfG+wFeEU5MOPNZUbt4spEugxWnV9/Nw1LvBFNAZcp26 8hLTqbWTth40zOitUbhFtnwfoSCVEET5NO23hG6Nh6TKML5Ft8/pcXmlB7Ktnk5Y IHWeutR5D5XZgcXPN4n+lFK8UECszTlw1Zv/HfxdJE5dWWd/SV2JTPA2Jw/L4jmz FHEcc6GWOFBxkUzJIH3UKwkSpXSj3jlki50Ww7fHnZCD++6mN9WYmXlQFK43ZzDH 30JttRGk2FiHWBdwJ8aqugafX9StO18xqkE4GG0X7s6rgwZlNgbEGqZuEbiYV8Fc jrw6UqigUlISLq93n9GoioHFek09l15HaU0y5h77w5jBwo6e8KohutKNgSjBCjJB nvUUSIPT12DfeTs5JkFQ1obzUNlXbKEcgjhaKdGdtONcyyNuqp2pDJlb4mYPXORd rsZnSlszkT/YhEEkezAGz6TyBdQsX4wAEqSQkkAiGtqwZNKf39Fmu8uYS2ymrQjm hqYmbFhHCo91R+xn46Nhsaa5D06WZwMI5rEp+KofY9n909jI2xR6lg0s2eC5GJWK rylzMJj4rsI8wTz8JBXl =K8mn -----END PGP SIGNATURE----- --GOc30Wfxa8Qepog3XmrdZZlvxkYdbPGsQ-- From owner-freebsd-hackers@freebsd.org Sun Dec 9 19:57: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 D08EE132CD03 for ; Sun, 9 Dec 2018 19:57:54 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from cloud-vps.localdomain (unknown [IPv6:2001:15e8:110:75a::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 318D978683 for ; Sun, 9 Dec 2018 19:57:54 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from localhost (localhost [127.0.0.1]) by cloud-vps.localdomain (Postfix) with ESMTP id 8CC793FD07 for ; Sun, 9 Dec 2018 20:48:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.autisticstory.net Received: from cloud-vps.localdomain ([127.0.0.1]) by localhost (mail.autisticstory.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc7t4CgWdegz for ; Sun, 9 Dec 2018 20:48:19 +0100 (CET) Received: from [192.168.1.104] (unknown [83.142.188.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: atypical@autisticstory.net) by cloud-vps.localdomain (Postfix) with ESMTPSA id 196023FB75 for ; Sun, 9 Dec 2018 20:48:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=autisticstory.net; s=201807; t=1544384899; bh=zaTHa+6w3TGRsQigyq6LTyISrxmDh+bxrGORNWDsAwQ=; h=To:From:Subject:Date:From; b=G77kLlj+zlnE4f08QAkLUw9G9Dj0sypl4lWdCYeuzhBX91/dhwG2lWSMNTnUOHzw0 B+t9vlldc1xHNfWWia2aWPNmH91otsZ35xIQ3J4UiozHWQk//ruCne6DT7qp1lWd0z PgopJarYLMYcZSb1+a37+o322AsJtrk0UPdeHRIhSAyZtx3Am7mvY9zMmYwsbad4hc KD8HOvfH9dA07vpFLGDG42jTQ8EZqHwpcGgz53EjxmqOtln1osR4Pl7AfAUCfK8mLw Li0kpDlE0S3s9MYAZNQTH8dI6+6P0bk4FQmRyqrl1j6bZ2/VAE4mebxNAfWCAM3lED ZQEAHEtWFlv4LvbEWDXTvBMXdPil7efhfgqXfIgaCeoShsqyqA4YUot/yiNGzKKlPx pQwnbaekDkjIW4bgW1XHjByblzeImxOkdhKIz2yz0/cHoyz3PilImoW/6HEFdB1++R 7SQhWCTLYG3nCojBQU3wLlRwOr6Sirfhg+OWqwRgHGY3utyYI2BaopykU9GhZSZB/W PJe1teUpY7bojKN2HTljbLQwiOR5Vs0gnkMNn3pdJbltLcbjOGlu8vE+gE93zlvlZe plqSiZoGUZoJVoRp2cXdJT4VtsMuUVT6ZDVlmwkvarvNZjLPx2fj5R118ulVkvfm7z JUi6jjlVfIIwN//Isfcyfw9E= To: freebsd-hackers@freebsd.org From: Hubert Hauser Subject: Can anyone help me with booting FreeBSD from GRUB? Openpgp: preference=signencrypt Autocrypt: addr=atypical@autisticstory.net; keydata= xsFNBFvfH1cBEADMaaPj9N4y/pGIYrpYgkmabzCa+3AP/GZH3++d7DLGcVH7cePoCKKANa/F 9LXXACQDMmkdXBPXndUAN1sZmzYiQF+E15G9U9BEx1wBJxMmevGbJ28XGIu8ZTwOcNzIlO5G yhQVbKlfckuIEMFnPhqm863a91UyyQL19/JWnDBfq/DOTmPSc/tWPfWgpJdCsI6zRWreLXCb fwVg4L3prqkJbjVIuPsKS5YBF1eII6ABqcFvlGdZFQaN6Cy/4+pswVQUAaySWG/1tYq9XMbV 6zuBl15l8txRYu0aNdnV6A6900HmeKAWCthw1JMemOggMokxU5OR8dHez0CMPDvSJaXLJr0t wZeOlcK2Z8vSE1IRyvdSbtBKWM6YzfX+hOQzxRGy3qi4Z8Pk1yx9pjtrueM1Fhz3Ag7TQNuv tLMlfYx1PgZyWVNo8K7J/D2jS/Sk6uMkgMfq5D3Ef1sJb8lh2kIxU5mRrlQQof+g/HW9iIP2 qXuylJvwNGpqGX52Hrz17B6tZaRtBnRHV2ZX4dv3LI+msGzjePrYdKPUmjdkPf8ztUps0qMY F93zXL5PEyuv9UmNeJlr+5UCcWWB9w71vSbTCqIIxTzhlQ+09118b//XTYYnolAcFb3KE5iM eMYG67OkmvAjaKFh75TKlGcQNmvX45l4kzl9guyYsysH7knJQQARAQABzSpIdWJlcnQgSGF1 c2VyIDxhdHlwaWNhbEBhdXRpc3RpY3N0b3J5Lm5ldD7CwZQEEwEIAD4WIQRJqW9Zo0ULA/tV 5BgsJbHYs2XiPQUCW98fVwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAs JbHYs2XiPcuXEACsPUZvMEJ7wUfnRr0EEVF3jWCuTSW2cD/HJG2mgwmu0SHDQJTwn5TNUYfv Yt2fBnL6TxnJxz2gjnF7DLuk7Gpo5ABmIjuh41f4NaVIbiBdVhMjueQISSEaaMJTbg4lQpr5 kPR+SWN6om3gff7V2SJ9ZozsVl/wc1wl75ndwk87gxvZJsQxhwIB6JOWCrtnD6SbldDcrKy9 wYGTEKnZpHMQaE5BB/1BADrHICPe4V2GYVTNpV/o7cneVAPSUT/AlUJHvVq6PWEOg7ld/rWq CaW9YbR+/wSikiwY5X7F+yg33G3Ys0mHVuDnWIKhGr24C/n6g3PjWTAdpg3MTBDitYFxjucZ S1luTooCkgYIF04/weV2ghrVOvAYCbtr+oN5mvfR2BwIW6v6SChyHOUMAEYyA2SHOjlNEv7+ Ws9zEHYlYXeTYIc/KMxsSEaVSuXQfsVn5uxMHlbeJ5ypMBDdke9zh6XJ39npgkR2eFHQJIqd 4BTqQbuSJPZllhXYwaeHfMy4ZZf41JFdXLNBXeQqXvnjjugGG0IrsC72OORp9iE+/4zbO/yg BvMD0jWVO94DL/3amH4nMM0RUBXIlo0mBDeuDvB0PIAyw2/fqSuMAmykLI40JoaKIfgeMcyU bv4Ra06Lz8oLXC63T6ZKT655lLU/P1cbgJXiwGjPvjupir9nEs7BTQRb3x9XARAAsz4qZEDX HpJ7s9AJS0YWjMkG2STodEV6XNaNum5BnXUF583vJUeAH9bEGqh0CY+MDXBhs4diLGVbacpe Vzac6UBQYKdwfYeZMuX5TFvPsVBv3XGvrNfhNWFnPlTUA7r9fah4QFNcDX0nRt/y1wtGknb1 JQW3vVRb/Z0q4oemPRw1cZ7yCsgBD1yD6ib13U8VYt6v+jxavS6EKh6hXjb/gUC/KOvsm2t7 UIBV5C0b8O98Dvy5csi5qQx3x0h7IAOvchpJ8i31Ke0s7xaJf2ghW2YqfNZOujtebqbc9/uf wuNOCQkL/yRirWpe7WXGAGUbM2rsqucWWpEKaHEEc5icYEeShJOyESOvRR1aEWeNBbntXMXK KMeUzLwYlqPptTxOWApIPbKJ37fHEG8QJi2H1jyn+NKLzB75GsyydUkmj/dLAuD00OF9Nn5B iJQPNFV58Q7VL99pTBhzXDj/2ZHxnYt0dVnyxE+FEOdklIcwX1PizUwHz01nUyFn+7bjgiFS LE2/5P8p7KDnpZAJgIy06sD2g8CsM4WUzRx4VHvHFkJhEWBA/E7AE+JVdEcyzjrhbM4xPR6i GbbxdvzLkUY5puM9srCnDmEN92k8joV3gFRffd2z7wIC+fYtZAhKqJiPHBaLZRQGDwmqO85x zbZBz8BPcP10JE7I4zjXvQmywgsAEQEAAcLBfAQYAQgAJhYhBEmpb1mjRQsD+1XkGCwlsdiz ZeI9BQJb3x9XAhsMBQkJZgGAAAoJECwlsdizZeI9B3kP/iBhveI7ov5IXgSMUmeMyc0MXrUB S8F4KE6kS4o82MGXPFpJunWM8WFtJwmOt6AmtE49RzuI0tH6RPfumiCFs8oaQxfQIfOw9q1I xKgF2nGRBf40OU69K7p9tKEFhqiJRyoqyTNmdunRbMTKUPobyxbH7RArobq+YaDiu4DKZ43Z W/0yR/Z0OBavE3aXeN2ePX6JM0sF2MWBIyha4lT7va1njcgLjUHzMi0l8XLAYH/YfuDHbi3S g5rDXGuvA/DfjHV3Yup1tdx+u3X65sKmSvQ1E8Ol8QCbxyfcHWResAdBdIrBBtQ6PjTw+bS4 29UCVyUJBP8oDWv3G4F9or+rUZjVxSyVdRIsFMe7+64gcPc8GFiT2ML2WhlK15b/F6qrT/bz eT/LATJUyBhYy5FEgaN1sR0YH6PPj1yOOiFS3shY1frasSZrtQS0uOv1tbR0kC40LRwIjodT CiqqoeocxvmCcSUmdS7sO5dwk5UxqHb0pggicR4FtAi9MsAFgqQLli32uAk3sKcoweuzurGe CRZQ3j54zXYQTXMc5l4ciZrwlt9l58VJvWqJzvBxa9XY7I8Y65FfA0dr+QaGtc85Ahq4LVF4 asP53ZlxwK4U7IQC0eg+LctuAxyoViMmGUu2G4arr4N8lGkiXyzzcP9QkWD0uCaH/Ig2JsC7 sCu5NBfl Message-ID: <371b0099-0c0f-e8d2-867e-62c57b9ad646@autisticstory.net> Date: Sun, 9 Dec 2018 19:47:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 318D978683 X-Spamd-Result: default: False [6.85 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RDNS_NONE(1.00)[]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[cloud-vps.localdomain]; HFILTER_HELO_NORES_A_OR_MX(0.30)[cloud-vps.localdomain]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[autisticstory.net:+]; DMARC_POLICY_ALLOW(-0.50)[autisticstory.net,none]; MX_GOOD(-0.01)[cached: mail.autisticstory.net]; NEURAL_HAM_SHORT(-0.21)[-0.206,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.08)[asn: 24806(0.40), country: CZ(0.01)]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[autisticstory.net]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.996,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.99)[0.988,0]; R_SPF_NA(0.00)[]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; GREYLIST(0.00)[pass,body] X-Rspamd-Server: mx1.freebsd.org X-Spam: Yes Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2018 19:57:55 -0000 Hello! I have got installed Debian 9 Stretch and FreeBSD with UFS boot partition and root filesystem on ZFS. I use GPT scheme of partitioning on a legacy BIOS. Here's content of /etc/grub.d/40_custom: menuentry "FreeBSD" {     insmod bsd     insmod ufs2     set root='(hd0,gpt5)'     chainloader +1 } When I'm trying to boot FreeBSD through GRUB I receive `error: attempt to read or write outside of disk 'hd0'`. My partition layout is: * ada0 - primary 3 TB hard drive with GPT partition scheme * ada0p1 - BIOS boot * ada0p2 - linux filesystem, mountpoint: /boot * ada0p3 - linux filesystem LVM on LUKS * ada0p4 - FreeBSD boot, gptboot * ada0p5 - FreeBSD UFS, mountpoint: /boot, required by geli to boot FreeBSD * ada0p6 - FreeBSD swap * ada0p7 - FreeBSD ZFS on geli My actual config menuentry "FreeBSD" {     insmod bsd     insmod ufs2     insmod part_gpt     set root='(hd0,gpt4)'     kfreebsd /boot/loader } doesn't work. It returns an error: unknown filesystem. Can anyone help me? From owner-freebsd-hackers@freebsd.org Sun Dec 9 19:34:21 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 9A622132C1EE for ; Sun, 9 Dec 2018 19:34:21 +0000 (UTC) (envelope-from hubot@mail.com) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.com", Issuer "GeoTrust RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D733877A74 for ; Sun, 9 Dec 2018 19:34:20 +0000 (UTC) (envelope-from hubot@mail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mail.com; s=dbd5af2cbaf7; t=1544384058; bh=ffz1iyeccDhT+0jiMsarzvorwq7oK4YejBnMoTSiFt0=; h=X-UI-Sender-Class:To:From:Subject:Date; b=Td/caFZ87DEi47KBWfpfq15noOuR/1C5FuoxQ3tt/MJavnLkGLr/5Pwzs8DHFSqkj cmtf4g+eA4ebbVahR5r7oVpYrEsKzw+3ZpWJR44ERVCg3CfX6fwvEAzCvBZaxUOq1T L71n06G8Qtx+BbB+c15UVRXfglu3C/MRTNsEshuk= X-UI-Sender-Class: 214d933f-fd2f-45c7-a636-f5d79ae31a79 Received: from [192.168.1.104] ([83.142.188.79]) by mail.gmx.com (mrgmxus002 [74.208.5.15]) with ESMTPSA (Nemesis) id 0MPDug-1gaUc71Cj2-004QQS for ; Sun, 09 Dec 2018 20:29:07 +0100 To: freebsd-hackers@freebsd.org From: Hubert Hauser Subject: Can anyone help me with booting FreeBSD from GRUB? Message-ID: Date: Sun, 9 Dec 2018 19:27:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 Content-Language: en-US X-Provags-ID: V03:K1:iff/UQn1liecRIwjzxzqd0lobw4pYFGNSoDdzyYtG9ETcA+MdLc 498MlekCKZTnbAkfb4lZtOMDxHhhM5FO6FKwdNpXqNGusS+aZWchCkNzqwIzJn98zwhaMj3 GJ6Q/2Dcu+4jNK4uFFO5+osZURqocet1mcMXjD9zBn8y59ah3UPyegsVkDEX+LsBEVx9FxP tzBBL8V41GanNbpk2HaKA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:hMFndCz0BBk=:Z8+U2GXV25bbs+oGD3JzXa v91U/JChrm8ubz9nkqPKyiTNYmlhBV7VmioCaEdDg9WWIzFn1/LhP7h56LqBJgThHoowTofWE Ap6KWQ0enphS1Wp6m5L6ng7tePYFyULKV147p7l3emmu/oz1jqrb0vH3mmu0HyuagvPQwNUm9 NoPApUOzyoWyPbamxDEnLipxk+VznfyTlXtOdN37S8UtxwrEjdV3pjmtCLKrP71rqS8wJ/NXk F/zFOfk9+jeAMiPJ8LuCCfhN2PT/5Xf64V/z0wTxfTc10IwG714FFjKl44DJl7N2abOaFheLZ gKxPJVykYlMoO8qrXKdtefYZCxVMN/409neIN91toq0aoeFn47FQWb5HiCl8zMu9gVWyzyrvw FK5vIBE42OKgCLKckLj80cOPJn1nvx3Y7Kr47u9ar5PLGQzqleaWRvHybSqu1p+DN5biPPJgC AXSIcSML15qsxez9L60qa1T7LCUmRptno20a/scbAY9AruFMu0iZ2VufkCnFEGuqfdVLIwaPJ dd13A3WlXa9bVTZV5bBS1krIJK10Cgd0IzpaIunooeBPmq73Hf1fSnETrOoti8j9lX9vbp4jg /7PSHZvp9ScJAZEiJxuWo6uwVDExcLFULgRIWVSXSPcuxcL/oBHhH0nX/WbD4vCHH3d1Jg6Jw SxPXiA0ba07U7VGxUXlcb1wFL22XDkxUbwu97WpfzFHAyDDiMV1bWb422I5ggIbBm6RiZi8Js IN/0Le8gLool0rZPlFb5xxIv1hHzhC0Toq9x3hvecAqKpZxCBO3uRkJmS9cwspIY9wCW8NQB0 KbeI5LtK61weHWpiUtCPDw9uVXjZkN+kpmvshaorFE4KQ4qqfCTH9gj8fWeP41cXDHPqsrpyp c4Qb4r8951Pvye/i2o+bbkEQGksl6LJzeo2z8KsYt5sLBcG+5FmMWQ/I3q9JWz X-Rspamd-Queue-Id: D733877A74 X-Spamd-Result: default: False [-2.28 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:74.208.4.192/26]; FREEMAIL_FROM(0.00)[mail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[mail.com:+]; MX_GOOD(-0.01)[cached: mx01.mail.com]; NEURAL_HAM_SHORT(-0.72)[-0.719,0]; RCVD_IN_DNSWL_LOW(-0.10)[200.4.208.74.list.dnswl.org : 127.0.3.1]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[mail.com]; ASN(0.00)[asn:8560, ipnet:74.208.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.890,0]; R_DKIM_ALLOW(-0.20)[mail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[mail.com]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.06)[ipnet: 74.208.0.0/16(-0.18), asn: 8560(-0.10), country: DE(-0.01)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-Mailman-Approved-At: Sun, 09 Dec 2018 20:44:02 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2018 19:34:21 -0000 I have got installed Debian 9 Stretch and FreeBSD with UFS boot partition and root filesystem on ZFS. I use GPT scheme of partitioning on a legacy BIOS. Here's content of /etc/grub.d/40_custom: menuentry "FreeBSD" {     insmod bsd     insmod ufs2     set root='(hd0,gpt5)'     chainloader +1 } When I'm trying to boot FreeBSD through GRUB I receive `error: attempt to read or write outside of disk 'hd0'`. My partition layout is: * ada0 - primary 3 TB hard drive with GPT partition scheme * ada0p1 - BIOS boot * ada0p2 - linux filesystem, mountpoint: /boot * ada0p3 - linux filesystem LVM on LUKS * ada0p4 - FreeBSD boot, gptboot * ada0p5 - FreeBSD UFS, mountpoint: /boot, required by geli to boot FreeBSD * ada0p6 - FreeBSD swap * ada0p7 - FreeBSD ZFS on geli My actual config menuentry "FreeBSD" {     insmod bsd     insmod ufs2     insmod part_gpt     set root='(hd0,gpt4)'     kfreebsd /boot/loader } doesn't work. It returns an error: unknown filesystem. Can anyone help me? From owner-freebsd-hackers@freebsd.org Mon Dec 10 13:06:04 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 E87A71325479 for ; Mon, 10 Dec 2018 13:06:03 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tutanota.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA3FA77550; Mon, 10 Dec 2018 13:06:02 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w2.tutanota.de (unknown [192.168.1.163]) by w1.tutanota.de (Postfix) with ESMTP id 4AD98FA0621; Mon, 10 Dec 2018 13:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com; s=20161216; t=1544447155; bh=stpDA2i8Z69Jp25ctxXiRrGuoR9kM79ubrgPBAZlXDU=; h=Date:From:To:In-Reply-To:References:Subject:From; b=0S3dxAt68NBmfP8AaVffd64rM3YvSmdM1zPSNWzP5TliAstlpkhA7sccs8dHslZBm wTtDkcxNA6ykwqX3CyiiV4RLRK9rWv1RvmTjtQcb2jTmHMO9nWGY6uc8o+kVn921P9 Ex9Ck3qJaGeUpt+M5fvliftUBmlpdXsJGxaB5do7U7ULleUO2JvtLyw6J5HZXGFmqG 6cXaSq0XOdfDuYeMdaCOQ9pew1sSgthn9zO/vtR2RJKdhIbqDcNo7QktogdaGtzkIz 7xtxNk+zgRNmEH4ZA4i00dXyoZy8kLX/1n02hFnNMHwbc8PfPbQY3GqMFPK75+5PpR C4UKw3HeLKSig== Date: Mon, 10 Dec 2018 14:05:55 +0100 (CET) From: To: Conrad Meyer , Freebsd Hackers Message-ID: In-Reply-To: References: <> Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot MIME-Version: 1.0 X-Rspamd-Queue-Id: DA3FA77550 X-Spamd-Result: default: False [-0.60 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tutanota.com]; IP_SCORE(-0.00)[country: DE(-0.01)]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.21)[0.206,0]; NEURAL_HAM_LONG(-0.79)[-0.794,0]; NEURAL_SPAM_MEDIUM(0.10)[0.101,0]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; MX_GOOD(-0.01)[mail.tutanota.de,mail.tutanota.de]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,none]; RCVD_IN_DNSWL_LOW(-0.10)[162.6.3.81.list.dnswl.org : 127.0.10.1]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 13:06:04 -0000 Thank you, this information helped a lot! I am not sure where I should submit my patch to ... I'll post it here if th= at's okay. If it needs to go somewhere else, please provide instructions or= if you don't mind ... submit it on my behalf ^^; This patch has been created against -CURRENT, and has been tested successfu= lly on 12.0-RC3. It allows me to power off my ASRock X399M (mATX) motherboa= rd, and should also work for ASRock X399 (ATX) users who have reported the = same problem of ACPI hanging during shutdown. Hopefully it will be useful t= o other users in the future who experience ACPI shutdown issues as a fallba= ck option. I relinquish the entire copyright to the FreeBSD project. It's public domai= n, no credit is necessary. Some notes: As requested, I moved IPMI to PRI-2 instead of PRI-1. I then placed EFI shu= tdown at PRI-1. In the spirit of DRY, I modified efi_reset_system(void) to efi_reset_system= (int type). I did a grep -rn . search on -CURRENT, and absolutely nothing e= ver uses efi_reset_system(void), nor is it exposed via the /dev/efi ioctl i= nterface. I hope this is okay. I named the sysctl tunable "hw.efi.poweroff", after the similarly named "hw= .acpi." set of tunables, and the use of "poweroff" over "shutdown" in vario= us other tunables. Please feel free to rename the tunable to anything you l= ike. I think it would be nice if we exposed this tunable to the "sysctl" tool, a= nd allowed modifying it at run-time. I didn't want to complicate the patch,= but if you're okay with that, please add that as well. However, if you're = worried about people mucking with the value inadvertently, I'm okay if it r= emains a "secret" /boot/loader.conf option only. Lastly, I added the needed event handler headers, and added the new EFI_RES= ET_SHUTDOWN define. I tried to respect all formatting conventions of the existing code. But as = with everything else, please feel free to make any changes you like. If I can be of any further assistance on this, please let me know. Thank yo= u very much! diff -ru old/sys/dev/efidev/efirt.c new/sys/dev/efidev/efirt.c --- old/sys/dev/efidev/efirt.c=092018-12-10 04:32:01.231607000 +0900 +++ new/sys/dev/efidev/efirt.c=092018-12-10 04:45:29.548147000 +0900 @@ -46,6 +46,8 @@ #include #include #include +#include +#include #include #include @@ -126,6 +128,24 @@ return (false); } +static void +efi_shutdown_final(void *unused, int howto) +{ +=09int efi_poweroff; + +=09/* +=09 * On some systems, ACPI S5 is missing or does not function properly. +=09 * Allow shutdown via EFI Runtime Services instead with a sysctl tunabl= e. +=09 */ +=09if((howto & RB_POWEROFF) !=3D 0) { +=09=09efi_poweroff =3D 0; +=09=09TUNABLE_INT_FETCH("hw.efi.poweroff", &efi_poweroff); +=09=09if (efi_poweroff =3D=3D 1) { +=09=09=09efi_reset_system(EFI_RESET_SHUTDOWN); +=09=09} +=09} +} + static int efi_init(void) { @@ -214,6 +234,13 @@ } #endif +=09/* +=09 * We use SHUTDOWN_PRI_LAST - 1 to trigger after IPMI, but before ACPI. +=09 * When not enabled via sysctl tunable, this will fall through to ACPI. +=09 */ +=09EVENTHANDLER_REGISTER(shutdown_final, efi_shutdown_final, NULL, +=09=09SHUTDOWN_PRI_LAST - 1); + return (0); } @@ -411,16 +438,20 @@ } int -efi_reset_system(void) +efi_reset_system(int type) { struct efirt_callinfo ec; +=09if (type !=3D EFI_RESET_COLD +=09 && type !=3D EFI_RESET_WARM +=09 && type !=3D EFI_RESET_SHUTDOWN) +=09=09return (EINVAL); if (efi_runtime =3D=3D NULL) return (ENXIO); bzero(&ec, sizeof(ec)); ec.ec_name =3D "rt_reset"; ec.ec_argcnt =3D 4; -=09ec.ec_arg1 =3D (uintptr_t)EFI_RESET_WARM; +=09ec.ec_arg1 =3D (uintptr_t)type; ec.ec_arg2 =3D (uintptr_t)0; ec.ec_arg3 =3D (uintptr_t)0; ec.ec_arg4 =3D (uintptr_t)NULL; diff -ru old/sys/dev/ipmi/ipmi.c new/sys/dev/ipmi/ipmi.c --- old/sys/dev/ipmi/ipmi.c=092018-12-10 04:34:07.535522000 +0900 +++ new/sys/dev/ipmi/ipmi.c=092018-12-10 04:36:35.757611000 +0900 @@ -938,14 +938,14 @@ } else if (!on) (void)ipmi_set_watchdog(sc, 0); /* -=09 * Power cycle the system off using IPMI. We use last - 1 since we don'= t +=09 * Power cycle the system off using IPMI. We use last - 2 since we don'= t * handle all the other kinds of reboots. We'll let others handle them. * We only try to do this if the BMC supports the Chassis device. */ if (sc->ipmi_dev_support & IPMI_ADS_CHASSIS) { device_printf(dev, "Establishing power cycle handler\n"); sc->ipmi_power_cycle_tag =3D EVENTHANDLER_REGISTER(shutdown_final, -=09=09=C2=A0=C2=A0=C2=A0 ipmi_power_cycle, sc, SHUTDOWN_PRI_LAST - 1); +=09=09=C2=A0=C2=A0=C2=A0 ipmi_power_cycle, sc, SHUTDOWN_PRI_LAST - 2); } } diff -ru old/sys/sys/efi.h new/sys/sys/efi.h --- old/sys/sys/efi.h=092018-12-10 04:32:34.850892000 +0900 +++ new/sys/sys/efi.h=092018-12-10 04:35:41.011396000 +0900 @@ -43,7 +43,8 @@ enum efi_reset { EFI_RESET_COLD, -=09EFI_RESET_WARM +=09EFI_RESET_WARM, +=09EFI_RESET_SHUTDOWN }; typedef uint16_t=09efi_char; @@ -184,7 +185,7 @@ int efi_get_table(struct uuid *uuid, void **ptr); int efi_get_time(struct efi_tm *tm); int efi_get_time_capabilities(struct efi_tmcap *tmcap); -int efi_reset_system(void); +int efi_reset_system(int type); int efi_set_time(struct efi_tm *tm); int efi_var_get(uint16_t *name, struct uuid *vendor, uint32_t *attrib, =C2=A0=C2=A0=C2=A0=C2=A0 size_t *datasize, void *data); Dec 9, 2018, 3:35 AM by cem@freebsd.org: > Hi, > > I think the way you would do this properly is by adding a > 'EVENTHANDLER_REGISTER(shutdown_final, efi_shutdown_final, ..., > SHUTDOWN_PRI_LAST - 1);' in efidev/efirt (or '- 2', see below). > Because the priority number is *lower* than acpi's > (SHUTDOWN_PRI_LAST), it will be invoked *before* acpi. If an EFI > shutdown is inappropriate or the particular howto mode is unsupported > on that system, it can just do return doing nothing; the ACPI > acpi_shutdown_final handler will be called next. > > You can see numerous examples of such handlers in various ARM devices > which don't have ACPI (grep for > 'EVENTHANDLER_REGISTER(shutdown_final'). > > One other relevant example on x86 is ipmi shutdown, which like I just > suggested for efi shutdown, registers itself as SHUTDOWN_PRI_LAST - 1 > to precede ACPI shutdown. I guess if IPMI is configured, maybe it > should supersede both EFI and ACPI. So maybe your patch should bump > the IPMI number to SHUTDOWN_PRI_LAST - 2 and add EFI as - 1. > > As hinted above, your efirt_shutdown_final() would take the place of > acpi_shutdown_final() in your callstack above, called from > kern_reboot() -> shutdown_final event. > > I hope that helps, > Conrad > On Sat, Dec 8, 2018 at 9:53 AM <> byuu@tutanota.com > > wrote: > >> >> Hello, first time poster here, please go easy on me ^-^; >> >> I would like to submit a patch for inclusion to the FreeBSD kernel, but = want to first see if there is a chance it will be accepted before writing i= t or not. >> >> Currently, /usr/src/sys/dev/efidev/efirt.c contains the efi_reset_system= () function, which calls EFI_RESET_WARM. It's exposed in /usr/src/sys/sys/e= fi.h >> >> I would like to add efi_poweroff_system() to efirt.c, which is identical= to efi_reset_system(), but with EFI_RESET_SHUTDOWN as arg1, which we have = to add as an enum item to efi.h as well (its value is 2, so it would go dir= ectly after EFI_RESET_WARM.) >> >> (These two functions are wrappers to invoke the EFI Runtime Services fun= ction ResetSystem with EfiResetWarm and EfiResetShutdown. FreeBSD's loader.= eli uses them to implement its reboot and poweroff commands, for example.) >> >> Next, I would like to add a patch to /usr/src/sys/dev/acpica/acpi.c to a= cpi_shutdown_final to check a new kernel sysctl, not picky about the name, = but something like "hw.acpi.efi_shutdown=3D0", which can be optionally chan= ged to 1 by the users. It could be changed at run-time with no ill effect. >> >> When this option is set to 1, and efi_systbl_phys is not NULL (eg we are= running on an EFI system), I would like to invoke efi_poweroff_system() in= stead of AcpiEnterSleepStatePrep(ACPI_STATE_S5) >> >> This is well after all services have been halted, all disks have been de= tached, and all USB devices have been detached. acpi_shutdown_final calls A= cpiEnterSleepStatePrep (_PTS), followed by AcpiEnterSleepState (_S5), and t= hat's it. The idea is to reuse all of the shutdown handling we can. >> >> If it would be desired, I could do the same for reset events to invoke e= fi_reset_system(). >> >> ... >> >> The reason I am requesting this, is because I am the owner of a Threadri= pper 2950X with an ASRock Taichi X399M motherboard, and when I attempt to s= hutdown my system from FreeBSD 11.2-RELEASE or 12.0-RC3, the system hangs f= orever and fails to power down. The call frame for this is as follows: >> >> kern_psignal(initproc, SIGUSR2); >> kern_reboot >> shutdown_final >> acpi_shutdown_final >> AcpiEnterSleepStatePre >> AcpiEvaluateObject >> AcpiNsEvaluate >> AcpiPsExecuteMethod >> AcpiPsParseAml >> AcpiPsParseLoop //from this point on, it likely varies per DSDT >> WalkState->AscendingCallback >> AcpiDsExecEndOp >> AcpiGbl_OpTypeDispatch[OpType] >> AcpiExOpcode_1A_0T_0R >> AcpiExSystemDoSleep >> AcpiOsSleep >> pause("acpislp", 300) (eg tsleep) >> >> I do not know why, but the call to pause never returns. I have tried ove= r a dozen things to find a fix for this: analyzing my DSDT ASL code via acp= idump, disabling SMT + all cores, wrapping pause in a critical section, try= ing SLEEP instead of pause, trying a spinloop instead of pause, trying to s= kip the AcpiEnterSleepStatePrep call, building a kernel with options ACPI_D= EBUG and trying to selectively disable every device driver and ACPI subsyst= em possible (including USB) while still allowing me to get to a login promp= t, tweaking every sysctl I could find around ACPI, USB, debugging, etc. Not= hing helped. >> >> Looking into Linux' ACPI support, they have acpi_no_s5, which they claim= is used for certain motherboards which lack an _S5 DSDT entry. >> >> I believe my proposed patch would be useful both for the case of a missi= ng _S5 entry, as well as for when there are bugs in FreeBSD, or the motherb= oard DSDT, or in Intel's ASL parser, or in the hardware itself. Obviously, = it's most desirable to fix ACPI on the Threadripper + Taichi X399 platform,= but a sysctl as I'm proposing would be beneficial for this and future plat= forms while users wait for a fix. >> >> If someone with kernel commit access would be interested, I can write al= l of the code against -CURRENT, and submit a diff patch for review. It woul= d be only a small amount of code, maybe 30 lines or so, with appropriate er= ror checking and fallbacks in place. Again, I'm very new to this, so please= bear with me. >> >> Personally, for now, I just monkey patched it into acpica.c and confirme= d that the concept works. >> >> If there's no interest, then I will drop the matter. >> >> Thank you everyone for your time! >> >> _______________________________________________ >> freebsd-hackers@freebsd.org >> mail= ing 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 Mon Dec 10 13:12:09 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 D6B7313256DA for ; Mon, 10 Dec 2018 13:12:08 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tutanota.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 257C077907; Mon, 10 Dec 2018 13:12:08 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w2.tutanota.de (unknown [192.168.1.163]) by w1.tutanota.de (Postfix) with ESMTP id F1FFEFA0D53; Mon, 10 Dec 2018 13:12:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com; s=20161216; t=1544447527; bh=VOUhBq2ryJxrEJR1LLXqisbnhSHJYd4V3vAcqslH6/E=; h=Date:From:To:In-Reply-To:References:Subject:From; b=K5vhBw616NpkaebgHc0j3lDZOFqrQLjMwPd6JgKqXDhvVP29P85AkrmNG0ntM5JBc dZlh/nTMtfaIdTYDuk14F5WfC5ri0GFtKZnrR9LzWmqBDFTdv6gpPEOQUV4fhhe8BM oP9tlAWol6r1pJLN+zqpjxkVqy5qRbnrM3L+uMPlVQCtn0bLbNUu88wR5B/hLjkbqI TsNTUL6GTNCVPca0hiEgpragpnOMnzIEsvNRu4dqWWFRR1JS4y6FpV2seHHcOv4AWc 2s7Jepbhi2PedjWGOWRPXkazsaqfI6r3asgfuTOgmD1d+PBTvzkhesrXdTzJY5XOYD omW6J+PLsgrsg== Date: Mon, 10 Dec 2018 14:12:06 +0100 (CET) From: To: Conrad Meyer , Freebsd Hackers Message-ID: In-Reply-To: References: <> Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot MIME-Version: 1.0 X-Rspamd-Queue-Id: 257C077907 X-Spamd-Result: default: False [-2.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.57)[-0.571,0]; R_DKIM_ALLOW(-0.20)[tutanota.com]; RCVD_IN_DNSWL_LOW(-0.10)[162.6.3.81.list.dnswl.org : 127.0.10.1]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-0.98)[-0.984,0]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; MX_GOOD(-0.01)[cached: mail.tutanota.de]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,none]; NEURAL_HAM_SHORT(-0.00)[-0.002,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 13:12:09 -0000 In case the formatting was damaged by posting it through the mailing list .= .. here's another copy of the patch: https://pastebin.com/raw/US5VbZGp Dec 10, 2018, 10:05 PM by byuu@tutanota.com: > Thank you, this information helped a lot! > > I am not sure where I should submit my patch to ... I'll post it here if = that's okay. If it needs to go somewhere else, please provide instructions = or if you don't mind ... submit it on my behalf ^^; > > This patch has been created against -CURRENT, and has been tested success= fully on 12.0-RC3. It allows me to power off my ASRock X399M (mATX) motherb= oard, and should also work for ASRock X399 (ATX) users who have reported th= e same problem of ACPI hanging during shutdown. Hopefully it will be useful= to other users in the future who experience ACPI shutdown issues as a fall= back option. > > I relinquish the entire copyright to the FreeBSD project. It's public dom= ain, no credit is necessary. > > Some notes: > > As requested, I moved IPMI to PRI-2 instead of PRI-1. I then placed EFI s= hutdown at PRI-1. > > In the spirit of DRY, I modified efi_reset_system(void) to efi_reset_syst= em(int type). I did a grep -rn . search on -CURRENT, and absolutely nothing= ever uses efi_reset_system(void), nor is it exposed via the /dev/efi ioctl= interface. I hope this is okay. > > I named the sysctl tunable "hw.efi.poweroff", after the similarly named "= hw.acpi." set of tunables, and the use of "poweroff" over "shutdown" in var= ious other tunables. Please feel free to rename the tunable to anything you= like. > > I think it would be nice if we exposed this tunable to the "sysctl" tool,= and allowed modifying it at run-time. I didn't want to complicate the patc= h, but if you're okay with that, please add that as well. However, if you'r= e worried about people mucking with the value inadvertently, I'm okay if it= remains a "secret" /boot/loader.conf option only. > > Lastly, I added the needed event handler headers, and added the new EFI_R= ESET_SHUTDOWN define. > > I tried to respect all formatting conventions of the existing code. But a= s with everything else, please feel free to make any changes you like. > > If I can be of any further assistance on this, please let me know. Thank = you very much! > > diff -ru old/sys/dev/efidev/efirt.c new/sys/dev/efidev/efirt.c > --- old/sys/dev/efidev/efirt.c=092018-12-10 04:32:01.231607000 +0900 > +++ new/sys/dev/efidev/efirt.c=092018-12-10 04:45:29.548147000 +0900 > @@ -46,6 +46,8 @@ > #include > #include > #include > +#include > +#include > > #include > #include > @@ -126,6 +128,24 @@ > return (false); > } > > +static void > +efi_shutdown_final(void *unused, int howto) > +{ > +=09int efi_poweroff; > + > +=09/* > +=09 * On some systems, ACPI S5 is missing or does not function properly. > +=09 * Allow shutdown via EFI Runtime Services instead with a sysctl tuna= ble. > +=09 */ > +=09if((howto & RB_POWEROFF) !=3D 0) { > +=09=09efi_poweroff =3D 0; > +=09=09TUNABLE_INT_FETCH("hw.efi.poweroff", &efi_poweroff); > +=09=09if (efi_poweroff =3D=3D 1) { > +=09=09=09efi_reset_system(EFI_RESET_SHUTDOWN); > +=09=09} > +=09} > +} > + > static int > efi_init(void) > { > @@ -214,6 +234,13 @@ > } > #endif > > +=09/* > +=09 * We use SHUTDOWN_PRI_LAST - 1 to trigger after IPMI, but before ACP= I. > +=09 * When not enabled via sysctl tunable, this will fall through to ACP= I. > +=09 */ > +=09EVENTHANDLER_REGISTER(shutdown_final, efi_shutdown_final, NULL, > +=09=09SHUTDOWN_PRI_LAST - 1); > + > return (0); > } > > @@ -411,16 +438,20 @@ > } > > int > -efi_reset_system(void) > +efi_reset_system(int type) > { > struct efirt_callinfo ec; > > +=09if (type !=3D EFI_RESET_COLD > +=09 && type !=3D EFI_RESET_WARM > +=09 && type !=3D EFI_RESET_SHUTDOWN) > +=09=09return (EINVAL); > if (efi_runtime =3D=3D NULL) > return (ENXIO); > bzero(&ec, sizeof(ec)); > ec.ec_name =3D "rt_reset"; > ec.ec_argcnt =3D 4; > -=09ec.ec_arg1 =3D (uintptr_t)EFI_RESET_WARM; > +=09ec.ec_arg1 =3D (uintptr_t)type; > ec.ec_arg2 =3D (uintptr_t)0; > ec.ec_arg3 =3D (uintptr_t)0; > ec.ec_arg4 =3D (uintptr_t)NULL; > diff -ru old/sys/dev/ipmi/ipmi.c new/sys/dev/ipmi/ipmi.c > --- old/sys/dev/ipmi/ipmi.c=092018-12-10 04:34:07.535522000 +0900 > +++ new/sys/dev/ipmi/ipmi.c=092018-12-10 04:36:35.757611000 +0900 > @@ -938,14 +938,14 @@ > } else if (!on) > (void)ipmi_set_watchdog(sc, 0); > /* > -=09 * Power cycle the system off using IPMI. We use last - 1 since we do= n't > +=09 * Power cycle the system off using IPMI. We use last - 2 since we do= n't > * handle all the other kinds of reboots. We'll let others handle them. > * We only try to do this if the BMC supports the Chassis device. > */ > if (sc->ipmi_dev_support & IPMI_ADS_CHASSIS) { > device_printf(dev, "Establishing power cycle handler\n"); > sc->ipmi_power_cycle_tag =3D EVENTHANDLER_REGISTER(shutdown_final, > -=09=09=C2=A0=C2=A0=C2=A0 ipmi_power_cycle, sc, SHUTDOWN_PRI_LAST - 1); > +=09=09=C2=A0=C2=A0=C2=A0 ipmi_power_cycle, sc, SHUTDOWN_PRI_LAST - 2); > } > } > > diff -ru old/sys/sys/efi.h new/sys/sys/efi.h > --- old/sys/sys/efi.h=092018-12-10 04:32:34.850892000 +0900 > +++ new/sys/sys/efi.h=092018-12-10 04:35:41.011396000 +0900 > @@ -43,7 +43,8 @@ > > enum efi_reset { > EFI_RESET_COLD, > -=09EFI_RESET_WARM > +=09EFI_RESET_WARM, > +=09EFI_RESET_SHUTDOWN > }; > > typedef uint16_t=09efi_char; > @@ -184,7 +185,7 @@ > int efi_get_table(struct uuid *uuid, void **ptr); > int efi_get_time(struct efi_tm *tm); > int efi_get_time_capabilities(struct efi_tmcap *tmcap); > -int efi_reset_system(void); > +int efi_reset_system(int type); > int efi_set_time(struct efi_tm *tm); > int efi_var_get(uint16_t *name, struct uuid *vendor, uint32_t *attrib, > =C2=A0=C2=A0=C2=A0=C2=A0 size_t *datasize, void *data); > > Dec 9, 2018, 3:35 AM by > cem@freebsd.org > : > >> Hi, >> >> I think the way you would do this properly is by adding a >> 'EVENTHANDLER_REGISTER(shutdown_final, efi_shutdown_final, ..., >> SHUTDOWN_PRI_LAST - 1);' in efidev/efirt (or '- 2', see below). >> Because the priority number is *lower* than acpi's >> (SHUTDOWN_PRI_LAST), it will be invoked *before* acpi. If an EFI >> shutdown is inappropriate or the particular howto mode is unsupported >> on that system, it can just do return doing nothing; the ACPI >> acpi_shutdown_final handler will be called next. >> >> You can see numerous examples of such handlers in various ARM devices >> which don't have ACPI (grep for >> 'EVENTHANDLER_REGISTER(shutdown_final'). >> >> One other relevant example on x86 is ipmi shutdown, which like I just >> suggested for efi shutdown, registers itself as SHUTDOWN_PRI_LAST - 1 >> to precede ACPI shutdown. I guess if IPMI is configured, maybe it >> should supersede both EFI and ACPI. So maybe your patch should bump >> the IPMI number to SHUTDOWN_PRI_LAST - 2 and add EFI as - 1. >> >> As hinted above, your efirt_shutdown_final() would take the place of >> acpi_shutdown_final() in your callstack above, called from >> kern_reboot() -> shutdown_final event. >> >> I hope that helps, >> Conrad >> On Sat, Dec 8, 2018 at 9:53 AM <>> byuu@tutanota.com >> > wrote: >> >>> >>> Hello, first time poster here, please go easy on me ^-^; >>> >>> I would like to submit a patch for inclusion to the FreeBSD kernel, but= want to first see if there is a chance it will be accepted before writing = it or not. >>> >>> Currently, /usr/src/sys/dev/efidev/efirt.c contains the efi_reset_syste= m() function, which calls EFI_RESET_WARM. It's exposed in /usr/src/sys/sys/= efi.h >>> >>> I would like to add efi_poweroff_system() to efirt.c, which is identica= l to efi_reset_system(), but with EFI_RESET_SHUTDOWN as arg1, which we have= to add as an enum item to efi.h as well (its value is 2, so it would go di= rectly after EFI_RESET_WARM.) >>> >>> (These two functions are wrappers to invoke the EFI Runtime Services fu= nction ResetSystem with EfiResetWarm and EfiResetShutdown. FreeBSD's loader= .eli uses them to implement its reboot and poweroff commands, for example.) >>> >>> Next, I would like to add a patch to /usr/src/sys/dev/acpica/acpi.c to = acpi_shutdown_final to check a new kernel sysctl, not picky about the name,= but something like "hw.acpi.efi_shutdown=3D0", which can be optionally cha= nged to 1 by the users. It could be changed at run-time with no ill effect. >>> >>> When this option is set to 1, and efi_systbl_phys is not NULL (eg we ar= e running on an EFI system), I would like to invoke efi_poweroff_system() i= nstead of AcpiEnterSleepStatePrep(ACPI_STATE_S5) >>> >>> This is well after all services have been halted, all disks have been d= etached, and all USB devices have been detached. acpi_shutdown_final calls = AcpiEnterSleepStatePrep (_PTS), followed by AcpiEnterSleepState (_S5), and = that's it. The idea is to reuse all of the shutdown handling we can. >>> >>> If it would be desired, I could do the same for reset events to invoke = efi_reset_system(). >>> >>> ... >>> >>> The reason I am requesting this, is because I am the owner of a Threadr= ipper 2950X with an ASRock Taichi X399M motherboard, and when I attempt to = shutdown my system from FreeBSD 11.2-RELEASE or 12.0-RC3, the system hangs = forever and fails to power down. The call frame for this is as follows: >>> >>> kern_psignal(initproc, SIGUSR2); >>> kern_reboot >>> shutdown_final >>> acpi_shutdown_final >>> AcpiEnterSleepStatePre >>> AcpiEvaluateObject >>> AcpiNsEvaluate >>> AcpiPsExecuteMethod >>> AcpiPsParseAml >>> AcpiPsParseLoop //from this point on, it likely varies per DSDT >>> WalkState->AscendingCallback >>> AcpiDsExecEndOp >>> AcpiGbl_OpTypeDispatch[OpType] >>> AcpiExOpcode_1A_0T_0R >>> AcpiExSystemDoSleep >>> AcpiOsSleep >>> pause("acpislp", 300) (eg tsleep) >>> >>> I do not know why, but the call to pause never returns. I have tried ov= er a dozen things to find a fix for this: analyzing my DSDT ASL code via ac= pidump, disabling SMT + all cores, wrapping pause in a critical section, tr= ying SLEEP instead of pause, trying a spinloop instead of pause, trying to = skip the AcpiEnterSleepStatePrep call, building a kernel with options ACPI_= DEBUG and trying to selectively disable every device driver and ACPI subsys= tem possible (including USB) while still allowing me to get to a login prom= pt, tweaking every sysctl I could find around ACPI, USB, debugging, etc. No= thing helped. >>> >>> Looking into Linux' ACPI support, they have acpi_no_s5, which they clai= m is used for certain motherboards which lack an _S5 DSDT entry. >>> >>> I believe my proposed patch would be useful both for the case of a miss= ing _S5 entry, as well as for when there are bugs in FreeBSD, or the mother= board DSDT, or in Intel's ASL parser, or in the hardware itself. Obviously,= it's most desirable to fix ACPI on the Threadripper + Taichi X399 platform= , but a sysctl as I'm proposing would be beneficial for this and future pla= tforms while users wait for a fix. >>> >>> If someone with kernel commit access would be interested, I can write a= ll of the code against -CURRENT, and submit a diff patch for review. It wou= ld be only a small amount of code, maybe 30 lines or so, with appropriate e= rror checking and fallbacks in place. Again, I'm very new to this, so pleas= e bear with me. >>> >>> Personally, for now, I just monkey patched it into acpica.c and confirm= ed that the concept works. >>> >>> If there's no interest, then I will drop the matter. >>> >>> Thank you everyone for your time! >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org >>> ma= iling list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to ">>> freebsd-hackers-unsubscribe@freeb= sd.org >>> " >>> > > From owner-freebsd-hackers@freebsd.org Mon Dec 10 19:38: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 87E87133143F; Mon, 10 Dec 2018 19:38:48 +0000 (UTC) (envelope-from j@nitrology.com) Received: from nitrology.com (wsip-72-215-204-58.ph.ph.cox.net [72.215.204.58]) (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 1C9EA6B867; Mon, 10 Dec 2018 19:38:46 +0000 (UTC) (envelope-from j@nitrology.com) Received: by nitrology.com (Postfix, from userid 58) id 4E015B419A; Mon, 10 Dec 2018 12:38:32 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on nitrology.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from m.nitrology.com (unknown [10.255.255.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: evidence) by nitrology.com (Postfix) with ESMTPSA id 1A7C7B4193; Mon, 10 Dec 2018 12:38:31 -0700 (MST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 10 Dec 2018 12:38:31 -0700 From: Jason Wolfe To: byuu@tutanota.com Cc: Conrad Meyer , Freebsd Hackers , owner-freebsd-hackers@freebsd.org Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot In-Reply-To: References: <> Message-ID: <23b3fe208bfb2b6ba5e50f4b88a84ac6@nitrology.com> X-Sender: j@nitrology.com User-Agent: Roundcube Webmail/1.3.7 X-Rspamd-Queue-Id: 1C9EA6B867 X-Spamd-Result: default: False [1.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-0.30)[-0.301,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nitrology.com]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.58)[0.584,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.76)[0.763,0]; MX_GOOD(-0.01)[nitrology.com]; IP_SCORE(0.29)[asn: 22773(1.55), country: US(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22773, ipnet:72.215.192.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 19:38:48 -0000 Hey, https://wiki.freebsd.org/Phabricator is a good guide on how to get your patch some visibility and hopefully ushered in. Jason On 2018-12-10 06:05, byuu@tutanota.com wrote: > Thank you, this information helped a lot! > > I am not sure where I should submit my patch to ... I'll post it here > if that's okay. If it needs to go somewhere else, please provide > instructions or if you don't mind ... submit it on my behalf ^^; > > This patch has been created against -CURRENT, and has been tested > successfully on 12.0-RC3. It allows me to power off my ASRock X399M > (mATX) motherboard, and should also work for ASRock X399 (ATX) users > who have reported the same problem of ACPI hanging during shutdown. > Hopefully it will be useful to other users in the future who > experience ACPI shutdown issues as a fallback option. > > I relinquish the entire copyright to the FreeBSD project. It's public > domain, no credit is necessary. > > Some notes: > > As requested, I moved IPMI to PRI-2 instead of PRI-1. I then placed > EFI shutdown at PRI-1. > > In the spirit of DRY, I modified efi_reset_system(void) to > efi_reset_system(int type). I did a grep -rn . search on -CURRENT, and > absolutely nothing ever uses efi_reset_system(void), nor is it exposed > via the /dev/efi ioctl interface. I hope this is okay. > > I named the sysctl tunable "hw.efi.poweroff", after the similarly > named "hw.acpi." set of tunables, and the use of "poweroff" over > "shutdown" in various other tunables. Please feel free to rename the > tunable to anything you like. > > I think it would be nice if we exposed this tunable to the "sysctl" > tool, and allowed modifying it at run-time. I didn't want to > complicate the patch, but if you're okay with that, please add that as > well. However, if you're worried about people mucking with the value > inadvertently, I'm okay if it remains a "secret" /boot/loader.conf > option only. > > Lastly, I added the needed event handler headers, and added the new > EFI_RESET_SHUTDOWN define. > > I tried to respect all formatting conventions of the existing code. > But as with everything else, please feel free to make any changes you > like. > > If I can be of any further assistance on this, please let me know. > Thank you very much! > > diff -ru old/sys/dev/efidev/efirt.c new/sys/dev/efidev/efirt.c > --- old/sys/dev/efidev/efirt.c 2018-12-10 04:32:01.231607000 +0900 > +++ new/sys/dev/efidev/efirt.c 2018-12-10 04:45:29.548147000 +0900 > @@ -46,6 +46,8 @@ > #include > #include > #include > +#include > +#include > > #include > #include > @@ -126,6 +128,24 @@ > return (false); > } > > +static void > +efi_shutdown_final(void *unused, int howto) > +{ > + int efi_poweroff; > + > + /* > + * On some systems, ACPI S5 is missing or does not function properly. > + * Allow shutdown via EFI Runtime Services instead with a sysctl > tunable. > + */ > + if((howto & RB_POWEROFF) != 0) { > + efi_poweroff = 0; > + TUNABLE_INT_FETCH("hw.efi.poweroff", &efi_poweroff); > + if (efi_poweroff == 1) { > + efi_reset_system(EFI_RESET_SHUTDOWN); > + } > + } > +} > + > static int > efi_init(void) > { > @@ -214,6 +234,13 @@ > } > #endif > > + /* > + * We use SHUTDOWN_PRI_LAST - 1 to trigger after IPMI, but before > ACPI. > + * When not enabled via sysctl tunable, this will fall through to > ACPI. > + */ > + EVENTHANDLER_REGISTER(shutdown_final, efi_shutdown_final, NULL, > + SHUTDOWN_PRI_LAST - 1); > + > return (0); > } > > @@ -411,16 +438,20 @@ > } > > int > -efi_reset_system(void) > +efi_reset_system(int type) > { > struct efirt_callinfo ec; > > + if (type != EFI_RESET_COLD > + && type != EFI_RESET_WARM > + && type != EFI_RESET_SHUTDOWN) > + return (EINVAL); > if (efi_runtime == NULL) > return (ENXIO); > bzero(&ec, sizeof(ec)); > ec.ec_name = "rt_reset"; > ec.ec_argcnt = 4; > - ec.ec_arg1 = (uintptr_t)EFI_RESET_WARM; > + ec.ec_arg1 = (uintptr_t)type; > ec.ec_arg2 = (uintptr_t)0; > ec.ec_arg3 = (uintptr_t)0; > ec.ec_arg4 = (uintptr_t)NULL; > diff -ru old/sys/dev/ipmi/ipmi.c new/sys/dev/ipmi/ipmi.c > --- old/sys/dev/ipmi/ipmi.c 2018-12-10 04:34:07.535522000 +0900 > +++ new/sys/dev/ipmi/ipmi.c 2018-12-10 04:36:35.757611000 +0900 > @@ -938,14 +938,14 @@ > } else if (!on) > (void)ipmi_set_watchdog(sc, 0); > /* > - * Power cycle the system off using IPMI. We use last - 1 since we > don't > + * Power cycle the system off using IPMI. We use last - 2 since we > don't > * handle all the other kinds of reboots. We'll let others handle them. > * We only try to do this if the BMC supports the Chassis device. > */ > if (sc->ipmi_dev_support & IPMI_ADS_CHASSIS) { > device_printf(dev, "Establishing power cycle handler\n"); > sc->ipmi_power_cycle_tag = EVENTHANDLER_REGISTER(shutdown_final, > -     ipmi_power_cycle, sc, SHUTDOWN_PRI_LAST - 1); > +     ipmi_power_cycle, sc, SHUTDOWN_PRI_LAST - 2); > } > } > > diff -ru old/sys/sys/efi.h new/sys/sys/efi.h > --- old/sys/sys/efi.h 2018-12-10 04:32:34.850892000 +0900 > +++ new/sys/sys/efi.h 2018-12-10 04:35:41.011396000 +0900 > @@ -43,7 +43,8 @@ > > enum efi_reset { > EFI_RESET_COLD, > - EFI_RESET_WARM > + EFI_RESET_WARM, > + EFI_RESET_SHUTDOWN > }; > > typedef uint16_t efi_char; > @@ -184,7 +185,7 @@ > int efi_get_table(struct uuid *uuid, void **ptr); > int efi_get_time(struct efi_tm *tm); > int efi_get_time_capabilities(struct efi_tmcap *tmcap); > -int efi_reset_system(void); > +int efi_reset_system(int type); > int efi_set_time(struct efi_tm *tm); > int efi_var_get(uint16_t *name, struct uuid *vendor, uint32_t *attrib, >      size_t *datasize, void *data); > > Dec 9, 2018, 3:35 AM by cem@freebsd.org: > >> Hi, >> >> I think the way you would do this properly is by adding a >> 'EVENTHANDLER_REGISTER(shutdown_final, efi_shutdown_final, ..., >> SHUTDOWN_PRI_LAST - 1);' in efidev/efirt (or '- 2', see below). >> Because the priority number is *lower* than acpi's >> (SHUTDOWN_PRI_LAST), it will be invoked *before* acpi. If an EFI >> shutdown is inappropriate or the particular howto mode is unsupported >> on that system, it can just do return doing nothing; the ACPI >> acpi_shutdown_final handler will be called next. >> >> You can see numerous examples of such handlers in various ARM devices >> which don't have ACPI (grep for >> 'EVENTHANDLER_REGISTER(shutdown_final'). >> >> One other relevant example on x86 is ipmi shutdown, which like I just >> suggested for efi shutdown, registers itself as SHUTDOWN_PRI_LAST - 1 >> to precede ACPI shutdown. I guess if IPMI is configured, maybe it >> should supersede both EFI and ACPI. So maybe your patch should bump >> the IPMI number to SHUTDOWN_PRI_LAST - 2 and add EFI as - 1. >> >> As hinted above, your efirt_shutdown_final() would take the place of >> acpi_shutdown_final() in your callstack above, called from >> kern_reboot() -> shutdown_final event. >> >> I hope that helps, >> Conrad >> On Sat, Dec 8, 2018 at 9:53 AM <> byuu@tutanota.com >> > > wrote: >> >>> >>> Hello, first time poster here, please go easy on me ^-^; >>> >>> I would like to submit a patch for inclusion to the FreeBSD kernel, >>> but want to first see if there is a chance it will be accepted before >>> writing it or not. >>> >>> Currently, /usr/src/sys/dev/efidev/efirt.c contains the >>> efi_reset_system() function, which calls EFI_RESET_WARM. It's exposed >>> in /usr/src/sys/sys/efi.h >>> >>> I would like to add efi_poweroff_system() to efirt.c, which is >>> identical to efi_reset_system(), but with EFI_RESET_SHUTDOWN as arg1, >>> which we have to add as an enum item to efi.h as well (its value is >>> 2, so it would go directly after EFI_RESET_WARM.) >>> >>> (These two functions are wrappers to invoke the EFI Runtime Services >>> function ResetSystem with EfiResetWarm and EfiResetShutdown. >>> FreeBSD's loader.eli uses them to implement its reboot and poweroff >>> commands, for example.) >>> >>> Next, I would like to add a patch to /usr/src/sys/dev/acpica/acpi.c >>> to acpi_shutdown_final to check a new kernel sysctl, not picky about >>> the name, but something like "hw.acpi.efi_shutdown=0", which can be >>> optionally changed to 1 by the users. It could be changed at run-time >>> with no ill effect. >>> >>> When this option is set to 1, and efi_systbl_phys is not NULL (eg we >>> are running on an EFI system), I would like to invoke >>> efi_poweroff_system() instead of >>> AcpiEnterSleepStatePrep(ACPI_STATE_S5) >>> >>> This is well after all services have been halted, all disks have been >>> detached, and all USB devices have been detached. acpi_shutdown_final >>> calls AcpiEnterSleepStatePrep (_PTS), followed by AcpiEnterSleepState >>> (_S5), and that's it. The idea is to reuse all of the shutdown >>> handling we can. >>> >>> If it would be desired, I could do the same for reset events to >>> invoke efi_reset_system(). >>> >>> ... >>> >>> The reason I am requesting this, is because I am the owner of a >>> Threadripper 2950X with an ASRock Taichi X399M motherboard, and when >>> I attempt to shutdown my system from FreeBSD 11.2-RELEASE or >>> 12.0-RC3, the system hangs forever and fails to power down. The call >>> frame for this is as follows: >>> >>> kern_psignal(initproc, SIGUSR2); >>> kern_reboot >>> shutdown_final >>> acpi_shutdown_final >>> AcpiEnterSleepStatePre >>> AcpiEvaluateObject >>> AcpiNsEvaluate >>> AcpiPsExecuteMethod >>> AcpiPsParseAml >>> AcpiPsParseLoop //from this point on, it likely varies per DSDT >>> WalkState->AscendingCallback >>> AcpiDsExecEndOp >>> AcpiGbl_OpTypeDispatch[OpType] >>> AcpiExOpcode_1A_0T_0R >>> AcpiExSystemDoSleep >>> AcpiOsSleep >>> pause("acpislp", 300) (eg tsleep) >>> >>> I do not know why, but the call to pause never returns. I have tried >>> over a dozen things to find a fix for this: analyzing my DSDT ASL >>> code via acpidump, disabling SMT + all cores, wrapping pause in a >>> critical section, trying SLEEP instead of pause, trying a spinloop >>> instead of pause, trying to skip the AcpiEnterSleepStatePrep call, >>> building a kernel with options ACPI_DEBUG and trying to selectively >>> disable every device driver and ACPI subsystem possible (including >>> USB) while still allowing me to get to a login prompt, tweaking every >>> sysctl I could find around ACPI, USB, debugging, etc. Nothing helped. >>> >>> Looking into Linux' ACPI support, they have acpi_no_s5, which they >>> claim is used for certain motherboards which lack an _S5 DSDT entry. >>> >>> I believe my proposed patch would be useful both for the case of a >>> missing _S5 entry, as well as for when there are bugs in FreeBSD, or >>> the motherboard DSDT, or in Intel's ASL parser, or in the hardware >>> itself. Obviously, it's most desirable to fix ACPI on the >>> Threadripper + Taichi X399 platform, but a sysctl as I'm proposing >>> would be beneficial for this and future platforms while users wait >>> for a fix. >>> >>> If someone with kernel commit access would be interested, I can write >>> all of the code against -CURRENT, and submit a diff patch for review. >>> It would be only a small amount of code, maybe 30 lines or so, with >>> appropriate error checking and fallbacks in place. Again, I'm very >>> new to this, so please bear with me. >>> >>> Personally, for now, I just monkey patched it into acpica.c and >>> confirmed that the concept works. >>> >>> If there's no interest, then I will drop the matter. >>> >>> Thank you everyone for your time! >>> >>> _______________________________________________ >>> 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 >>> >> " >>> > > _______________________________________________ > 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 Mon Dec 10 21:37:27 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 263DA133435F for ; Mon, 10 Dec 2018 21:37:27 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7702B6FF22 for ; Mon, 10 Dec 2018 21:37:26 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f43.google.com with SMTP id r200so10023926iod.11 for ; Mon, 10 Dec 2018 13:37:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=9mpk/KOyJtx+uDNKiS/ozZkRujI7eqdnx92XgyTrulY=; b=lmquj7NJn3MNgjHDI19I1aAHrTvvc/o4qhqCORgsxDa9Auvj+aiPvu96oNCkzClQbn 0gbVIydbEyFQ0n8pSmYtDOFhuEGJbwcJeu49HnAbe4bIKNtt8qsX8QlV3vJzxX8ftuST 7QzJpxQuu4uvNvLqDE+z7snDNoI/mYxR0ke5GVPqSw89RQY8d1qVuRNz8etYFhuKmHEq dM0/hEPo03Ux3vpY3q/pNIOdw6Ztk6QHm1Y9sNuGE5cNQ82GSpNJ0pf3Jy8tmcUc82Cx KIJ9n0/SrIeHHRLbFDNCOjxhE292VMQPdWoKFTC7ypp+r6Gaj8tAFKnQG4dXShl7PT0U KCLA== X-Gm-Message-State: AA+aEWbZUyu3i/P3QbbBrzA+O/dsDsFooLyYEtR2QQUXk/0tgcGST9N1 Ljjt0/opNelYzOEfKZNOra6D4Ko5 X-Google-Smtp-Source: AFSGD/XAAlWhAmdCmc5JJajQBfbuJ6ZUSg690ftuud0hOdhgrtnKo9vzx0evGTZSvJvE3C7gHn9d7A== X-Received: by 2002:a6b:92d6:: with SMTP id u205mr11676041iod.221.1544477517184; Mon, 10 Dec 2018 13:31:57 -0800 (PST) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id a16sm4790264ioh.48.2018.12.10.13.31.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Dec 2018 13:31:56 -0800 (PST) Received: by mail-io1-f52.google.com with SMTP id t24so10100633ioi.0 for ; Mon, 10 Dec 2018 13:31:56 -0800 (PST) X-Received: by 2002:a6b:ee16:: with SMTP id i22mr10687467ioh.124.1544477516130; Mon, 10 Dec 2018 13:31:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 10 Dec 2018 13:31:45 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot To: byuu@tutanota.com Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7702B6FF22 X-Spamd-Result: default: False [-3.84 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.85)[-0.854,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; IP_SCORE(-0.98)[ipnet: 209.85.128.0/17(-3.54), asn: 15169(-1.28), country: US(-0.09)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[43.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[43.166.85.209.rep.mailspike.net : 127.0.0.17] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 21:37:27 -0000 On Mon, Dec 10, 2018 at 5:06 AM wrote: > > Thank you, this information helped a lot! I am glad to hear it. > I am not sure where I should submit my patch to ... I'll post it here if = that's okay. If it needs to go somewhere else, please provide instructions = or if you don't mind ... submit it on my behalf ^^; I'll second Jason's request =E2=80=94 please go ahead and submit a diff to Phabricator (reviews.freebsd.org), if you don't mind. > This patch has been created against -CURRENT, and has been tested success= fully on 12.0-RC3. It allows me to power off my ASRock X399M (mATX) motherb= oard, and should also work for ASRock X399 (ATX) users who have reported th= e same problem of ACPI hanging during shutdown. Hopefully it will be useful= to other users in the future who experience ACPI shutdown issues as a fall= back option. Hm, I don't recall my ASRock X399 board having issues shutting down with AC= PI. Thanks, Conrad From owner-freebsd-hackers@freebsd.org Mon Dec 10 23:56: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 C392C1336CEA for ; Mon, 10 Dec 2018 23:56:39 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tutanota.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF3C74727; Mon, 10 Dec 2018 23:56:39 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w2.tutanota.de (unknown [192.168.1.163]) by w1.tutanota.de (Postfix) with ESMTP id 04259FBF1BB; Mon, 10 Dec 2018 23:47:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com; s=20161216; t=1544485662; bh=W2pPR4jHkIDnQlnTQpY9mUXJ6er9pjzBLhivGSWzIxs=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Nspb6bd3o9STv6IHAnZSwqKySJRLR4LFG7npuTa5qBjlu9eCo4y3hVTRxK2fVhtka ACM9qqg4yQdCdT8mcMVu2LPK9M2c+wo7e1wZV1O5swLVidHqBjk379Nn4mstegQ6iq SnDYYSM49lJ6Q607/z8AgExNT8T/GPSH030J2e6BAfWHllnbpvUzKwob6CJl9Qe14e 30jQMwKL58vDPugv29sdJGMtztkAsNdK9Kynmpo5TfqYvzbX7BkwsDtU+M3AsRzOUz OjlgHrOpNi/tZ/pO3XiWLFHITIy+3/YP4DW9IhCDAJP5JcdVewsREAX9qVA0CRACyP fLljzyH2/iKJA== Date: Tue, 11 Dec 2018 00:47:41 +0100 (CET) From: To: Conrad Meyer , Freebsd Hackers Message-ID: In-Reply-To: References: <> <> Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot MIME-Version: 1.0 X-Rspamd-Queue-Id: 0AF3C74727 X-Spamd-Result: default: False [7.31 / 15.00]; R_SPF_ALLOW(0.00)[+ip4:81.3.6.160/28]; URIBL_RED(3.50)[freenas.org.multi.uribl.com]; URI_COUNT_ODD(1.00)[7]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[tutanota.com,none]; MX_GOOD(-0.01)[cached: mail.tutanota.de]; HAS_ANON_DOMAIN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[162.6.3.81.list.dnswl.org : 127.0.10.1]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; IP_SCORE(-0.00)[country: DE(-0.01)]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[tutanota.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.52)[0.520,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(0.97)[0.966,0]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_LONG(0.93)[0.934,0]; FROM_NO_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body] X-Rspamd-Server: mx1.freebsd.org X-Spam: Yes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:56:40 -0000 I made an account on reviews.freebsd.org, but it won't allow me to submit a= patch via the website. Tutorials online want me to install a bunch of software, install certificat= es, configure Git, and ... I'm very sorry, but I don't have the patience ju= st for a quick patch. No hard feelings if you can't use it like this. As far as the bug not occurring on your X399 ... very interesting. Are you = using a Threadripper as well? This user was having the same issue on the X3= 99 as I am on my X399M: https://forums.freenas.org/index.php?threads/amd-th= readripper-build.70194/#post-485064 I've exhausted all latest version BIOS settings, toggled lots of sysctl tun= ables, etc to no avail. Not a big deal really, just had nothing better to w= ork on while waiting for 12-RELEASE ^-^; Dec 11, 2018, 6:31 AM by cem@freebsd.org: > On Mon, Dec 10, 2018 at 5:06 AM <> byuu@tutanota.com > > wrote: > >> >> Thank you, this information helped a lot! >> > > I am glad to hear it. > >> I am not sure where I should submit my patch to ... I'll post it here if= that's okay. If it needs to go somewhere else, please provide instructions= or if you don't mind ... submit it on my behalf ^^; >> > > I'll second Jason's request =E2=80=94 please go ahead and submit a diff t= o > Phabricator (reviews.freebsd.org), if you don't mind. > >> This patch has been created against -CURRENT, and has been tested succes= sfully on 12.0-RC3. It allows me to power off my ASRock X399M (mATX) mother= board, and should also work for ASRock X399 (ATX) users who have reported t= he same problem of ACPI hanging during shutdown. Hopefully it will be usefu= l to other users in the future who experience ACPI shutdown issues as a fal= lback option. >> > > Hm, I don't recall my ASRock X399 board having issues shutting down with = ACPI. > > Thanks, > Conrad > _______________________________________________ > freebsd-hackers@freebsd.org > mailin= g list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "> freebsd-hackers-unsubscribe@freebsd.o= rg > " > From owner-freebsd-hackers@freebsd.org Mon Dec 10 23:56:40 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 C0B1B1336CE9 for ; Mon, 10 Dec 2018 23:56:39 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tutanota.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF9B74728; Mon, 10 Dec 2018 23:56:39 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w2.tutanota.de (unknown [192.168.1.163]) by w1.tutanota.de (Postfix) with ESMTP id AD1C1FBF16F; Mon, 10 Dec 2018 23:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com; s=20161216; t=1544485789; bh=VUs/P9Ey7HL/rS+v/lqqfAmwl+k4zm03Q2b/+lWZ4DE=; h=Date:From:To:In-Reply-To:References:Subject:From; b=LApoqBkDY8UvK4U/sxcz2AQWmhNdQyKjxxQT8whnjao/u9oKXWpo+fE6MrUGNJQRc fjt7gfer5utiWJH5kW0eWvqYleA0YfhWHAGbgCPWWsseD7Mg4tMJYd4Gxo1KQHGX2g GAU4jNg7vyHuA37Mfp9uS3JTaKPydX7H1dWgfsI9G1v8XQu1v62UrZL4KYQ5PgJYqM fenO44umYHp2R0A1WUREC4i8dnWuwvmXMTi0cx/g/IkUiOJUM8Uq24QNDKs/hbm/DL P6nT9CJ6JrkdZNgtTPFZ9xw+vjOjUzeVO5a1V7jdND3UB6PgF3nFmCswtWvC1PEvlD qRVbUNxS84nKQ== Date: Tue, 11 Dec 2018 00:49:49 +0100 (CET) From: To: Conrad Meyer , Freebsd Hackers Message-ID: In-Reply-To: References: <> <> Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot MIME-Version: 1.0 X-Rspamd-Queue-Id: 0AF9B74728 X-Spamd-Result: default: False [7.30 / 15.00]; R_SPF_ALLOW(0.00)[+ip4:81.3.6.160/28]; URIBL_RED(3.50)[freenas.org.multi.uribl.com]; URI_COUNT_ODD(1.00)[7]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[tutanota.com,none]; MX_GOOD(-0.01)[cached: mail.tutanota.de]; HAS_ANON_DOMAIN(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[162.6.3.81.list.dnswl.org : 127.0.10.1]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; IP_SCORE(-0.00)[country: DE(-0.01)]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[tutanota.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.52)[0.518,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(0.97)[0.965,0]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_LONG(0.93)[0.933,0]; FROM_NO_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,meta] X-Rspamd-Server: mx1.freebsd.org X-Spam: Yes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:56:40 -0000 Sorry, I meant to say, "Are you using a Threadripper 2 as well?", of course= it's a TR4 socket board ... sigh. Dec 11, 2018, 8:47 AM by byuu@tutanota.com: > I made an account on reviews.freebsd.org, but it won't allow me to submit= a patch via the website. > > Tutorials online want me to install a bunch of software, install certific= ates, configure Git, and ... I'm very sorry, but I don't have the patience = just for a quick patch. No hard feelings if you can't use it like this. > > As far as the bug not occurring on your X399 ... very interesting. Are yo= u using a Threadripper as well? This user was having the same issue on the = X399 as I am on my X399M: > https://forums.freenas.org/index.php?threads/am= d-threadripper-build.70194/#post-485064 > > I've exhausted all latest version BIOS settings, toggled lots of sysctl t= unables, etc to no avail. Not a big deal really, just had nothing better to= work on while waiting for 12-RELEASE ^-^; > > Dec 11, 2018, 6:31 AM by > cem@freebsd.org > : > >> On Mon, Dec 10, 2018 at 5:06 AM <>> byuu@tutanota.com >> > wrote: >> >>> >>> Thank you, this information helped a lot! >>> >> >> I am glad to hear it. >> >>> I am not sure where I should submit my patch to ... I'll post it here i= f that's okay. If it needs to go somewhere else, please provide instruction= s or if you don't mind ... submit it on my behalf ^^; >>> >> >> I'll second Jason's request =E2=80=94 please go ahead and submit a diff = to >> Phabricator (reviews.freebsd.org), if you don't mind. >> >>> This patch has been created against -CURRENT, and has been tested succe= ssfully on 12.0-RC3. It allows me to power off my ASRock X399M (mATX) mothe= rboard, and should also work for ASRock X399 (ATX) users who have reported = the same problem of ACPI hanging during shutdown. Hopefully it will be usef= ul to other users in the future who experience ACPI shutdown issues as a fa= llback option. >>> >> >> Hm, I don't recall my ASRock X399 board having issues shutting down with= ACPI. >> >> Thanks, >> Conrad >> _______________________________________________ >> freebsd-hackers@freebsd.org >> mail= ing 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 Dec 11 00:53: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 83332130B17C for ; Tue, 11 Dec 2018 00:53:00 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f195.google.com (mail-it1-f195.google.com [209.85.166.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B22177465 for ; Tue, 11 Dec 2018 00:52:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f195.google.com with SMTP id x19so998127itl.1 for ; Mon, 10 Dec 2018 16:52:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=O4JvcuQ0QqJqfzIJHTox/SjodbhBWONcKGW8aDk0RYU=; b=du6Bi3kIi5hBkJ6DD/KNGx9Y3nX7WLPwPJCt5wU1FV0jPsWxhl+ZEJ4Lo74CqWdapL S3BLu4xT78UfAv8A6QlVyqea4sh1S6KugIbw8a6R7ny8FUuqIw3GnMJ2KSv29bL8UBeP v+bKI5Q/LgdsWNmOrwlUkVXA1SdtXSEooDfJLBiStfqxYyJmhYCOOOu8ZIJ+pcBMVHbG 2t8lPueqlku6U2AA34tnNC+qRktEOtax7cdYOznEYfgoA0NdUEEA6kWpZmLkKi2bx6Uq rNTHK8OCWW+M5chQXMOeKWCvqjJScqZVvt30eayGQtOcYvfNtB77BA7MmhBL5jUknuKh IZ7Q== X-Gm-Message-State: AA+aEWYviBMjx8wXcV1a/XYDeNZB2YjZYyFlbyRZLpk/Z4AD1j7e1D5/ kcRat0Bli40JvN6Y9gGE/aysRLpf X-Google-Smtp-Source: AFSGD/WH6b2ezdWoTHscaZ2v3MGOr6VdyhYqUpMAABeknlHXm7QTBki+fb2yEy8cx1bsVa0qMABC4w== X-Received: by 2002:a05:660c:281:: with SMTP id s1mr551130itl.36.1544489070568; Mon, 10 Dec 2018 16:44:30 -0800 (PST) Received: from mail-it1-f178.google.com (mail-it1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id e16sm5720850iob.43.2018.12.10.16.44.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Dec 2018 16:44:30 -0800 (PST) Received: by mail-it1-f178.google.com with SMTP id b5so1020516iti.2 for ; Mon, 10 Dec 2018 16:44:30 -0800 (PST) X-Received: by 2002:a24:5411:: with SMTP id t17mr552872ita.32.1544489070037; Mon, 10 Dec 2018 16:44:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 10 Dec 2018 16:44:19 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot To: byuu@tutanota.com Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9B22177465 X-Spamd-Result: default: False [0.53 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(0.00)[+ip4:209.85.128.0/17]; URIBL_RED(3.50)[freenas.org.multi.uribl.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; HAS_ANON_DOMAIN(0.50)[]; NEURAL_HAM_SHORT(-0.83)[-0.827,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[195.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.98)[ipnet: 209.85.128.0/17(-3.53), asn: 15169(-1.27), country: US(-0.09)]; RWL_MAILSPIKE_POSSIBLE(0.00)[195.166.85.209.rep.mailspike.net : 127.0.0.17] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 00:53:00 -0000 On Mon, Dec 10, 2018 at 3:56 PM wrote: > > I made an account on reviews.freebsd.org, but it won't allow me to submit= a patch via the website. Hm, it should. Oh well! > Tutorials online want me to install a bunch of software, install certific= ates, configure Git, and ... I'm very sorry, but I don't have the patience = just for a quick patch. No hard feelings if you can't use it like this. No, it's fine. We'll make it work. Thanks. > As far as the bug not occurring on your X399 ... very interesting. Are yo= u using a Threadripper [2] as well? This user was having the same issue on = the X399 as I am on my X399M: https://forums.freenas.org/index.php?threads/= amd-threadripper-build.70194/#post-485064 > > I've exhausted all latest version BIOS settings, toggled lots of sysctl t= unables, etc to no avail. Not a big deal really, just had nothing better to= work on while waiting for 12-RELEASE ^-^; First-gen Threadripper (1950x), and newest BIOS version (3.30). I might be misremembering, though =E2=80=94 I rarely shut down this machine. Usually either reboot or panic -> reboot :-). Best, Conrad From owner-freebsd-hackers@freebsd.org Tue Dec 11 01:19:40 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 4907B130D34B for ; Tue, 11 Dec 2018 01:19:40 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tutanota.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EB0D793FE; Tue, 11 Dec 2018 01:19:39 +0000 (UTC) (envelope-from byuu@tutanota.com) Received: from w2.tutanota.de (unknown [192.168.1.163]) by w1.tutanota.de (Postfix) with ESMTP id 2C09BFA0929; Tue, 11 Dec 2018 01:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tutanota.com; s=20161216; t=1544491177; bh=FDmGQglbiDhSic+UjHvghHmKCdidpxxfeRQoZRlcd3A=; h=Date:From:To:In-Reply-To:References:Subject:From; b=0+Joxfv3mVNufRDCKy5wiGeBlzDwih8HMzUuXFzj2F4DE2ZuMjMQJk1CraFenTDHO ug1ubxPNBN7SVJfrY+SOQ77N3/bshTH+PjhYq5rzTxF8MoThG5pqnQmKSYGwPMc9aJ bj0pQE5yrZgmMbBddwWCIpCRbIwfM63NGRxhJ+zMHLWZt/txc1kunuRQOpxtsQpqSt QcdYSGXAk+zm2C4DBWcMIy15buwQoatxUvO2Rl2OFh1ByU0tvBQvkDz7bobeZx29T3 NPHF/8FMg7wRSiF+oTJeDn5xuU0/2RXGyQq2nb+ATd1JRTRWu+JNnEd5cE6xbdgGtn mLzl/E+nC2hIg== Date: Tue, 11 Dec 2018 02:19:37 +0100 (CET) From: To: Conrad Meyer , Freebsd Hackers Message-ID: In-Reply-To: References: <> <> <> Subject: Re: I'd like to submit a kernel patch for a new sysctl to use EFI instead of ACPI for poweroff + reboot MIME-Version: 1.0 X-Rspamd-Queue-Id: 5EB0D793FE X-Spamd-Result: default: False [-4.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; R_DKIM_ALLOW(-0.20)[tutanota.com]; IP_SCORE(-0.60)[asn: 24679(-2.99), country: DE(-0.01)]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: mail.tutanota.de]; DKIM_TRACE(0.00)[tutanota.com:+]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.75)[-0.750,0]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,none]; RCVD_IN_DNSWL_LOW(-0.10)[162.6.3.81.list.dnswl.org : 127.0.10.1]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 01:19:40 -0000 > Hm, it should. Oh well! > The tutorial I read said to use "Code Review" on the left, which wasn't the= re for me =3D/ >> No, it's fine. We'll make it work. Thanks. >> That's very generous, thank you! If you're ever in Tokyo, I owe you a beer = ;) I'll learn Phabricator for next time. Apologies again. > First-gen Threadripper (1950x), and newest BIOS version (3.30). I > might be misremembering, though =E2=80=94 I rarely shut down this machine= . > Usually either reboot or panic -> reboot :-). > Hmm, then it reduces the value of the patch somewhat ... perhaps it's a TR2= -only issue? Tried 3.20 and 3.30 here. Well, I already spent two days on this and have wasted enough of your time,= to save myself five seconds on shutting down ... thank you again! ^-^; From owner-freebsd-hackers@freebsd.org Tue Dec 11 01:43: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 02E7D1310120 for ; Tue, 11 Dec 2018 01:43:25 +0000 (UTC) (envelope-from hubot@mail.com) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.com", Issuer "GeoTrust RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA1B97ACF3 for ; Tue, 11 Dec 2018 01:43:23 +0000 (UTC) (envelope-from hubot@mail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mail.com; s=dbd5af2cbaf7; t=1544492588; bh=b6Jb8z7maKPzwNoXWoB+sqc/LMNJlk1vWUaxuFZ3uLw=; h=X-UI-Sender-Class:To:From:Subject:Date; b=Hd2DCGjf/Q4dHlFf89lh4n067nx/rUif1x9Zuvuz/ffiBsHF7hVXz3u4y/0kGx3Lr PZgXwFhEPAdrGW/TkKgMEyRI1LDbTbtq2wJJPl8pYEejLqKO6I2xqmNN0HriycZehk gWrwKpC4MukR+VJnyh/81ypofnfd1jnvFLntH7kw= X-UI-Sender-Class: 214d933f-fd2f-45c7-a636-f5d79ae31a79 Received: from [192.168.1.104] ([83.142.188.79]) by mail.gmx.com (mrgmxus001 [74.208.5.15]) with ESMTPSA (Nemesis) id 0MEWTv-1ghHdq2l2H-00FnmL for ; Tue, 11 Dec 2018 02:43:07 +0100 To: freebsd-hackers@freebsd.org From: Hubert Hauser Subject: Running Tor service in the jail environment Message-ID: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> Date: Tue, 11 Dec 2018 01:41:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 Content-Language: en-US X-Provags-ID: V03:K1:q121G9SjY201FQz9KtwxDGuZjCipuWA6jGP38fvKoPsSJGoXHxV RsM9g6GMyGP8ph6EbzoRdnkz3Tt06KVnHPqYtXQQ30N6JzUvFSj61Ts8Aqs7Q5C4jY8soAs fJAphUKSHQkcvnwlGSN298HZnCC7v3JOb9KhHKsNzcbKAe1EGKPsbW4fhO8wpjvm7Y0REsQ gbLNBP29OrWtn/u303tHA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:G/VDwNGfhtk=:Cmv1QtITiEvkuyHFjmtyCT kxBR0ZeQLCbs2I1Kq52vROA22nFwdP2VK9xD6pjqeAGgK4XHZUH+QZu7OExm34kpInjKfjfoe SdaBREpfj4HawIMJ+a0sxq39L+11B0GeKyZm1GXxYMH7DNbTfYc2x53KvxPxDcRLaIrKehYiR er8aVs+Y6za2iMWyvYPTQnXWF1ooNr7vjxZCpus+Sx/nvZQ4hCrWuq/79LocGpgtxc/1XyNXi RjOZpx42+2eFIlpK6j8TdTJ6yMDmD/BtH9Fza/02mquqB0MMZljbNeyAF19kJM595YkELe94v SGLs8T32v1b7zimsUvEhbKgtZu35fSSMCZ+U8orGAvzcLtYkHdFcxxaA9tC6ud7re8Bd8aBoe 2mUomVXOJ2q2smm8RVnVzeVJPaNVqwARR3ViZvEteZeoJ1V4AZL3ySKsOMI6+zP9zX+vZaOu2 jSkm/lvKJf5FSIaQ/Jbskf4o6f+gxoranDSmRIDBwOQxUaDXZFU4w7TJIT5++/zukW9jQo4mh rAXlj6Sc4ubUG9txdfGSGQhZFkYyiNaQuIlEE+gaT2/zCnRqrj+6JycUpBd7pNqTqjGItUcTM kbSaHfzwo/X1GvSivDR7nkfaXogvBsHzd0Nlf09qh7XKJNWvKTggmYcMfD+7v/vYqo5aeRqyw m3V6v48sGWierm5ZsfqgpHQ9ynxNGx14aTyEP14KDExjf56rr1Wo+GnGlgk9oUtxUdqthqNrf 2nkhWfnN3C+U61a9c6vrLG+gl7Io84bDZoY+gWF2y9SzDu0Rza94C0C1ia6MB5jvmUB20w2JN 4aTNANWgR1+sPa5fpzXwi3qZNluMNpB7O/b84BX4i8IDU/K+BF/ZbgK5UfCtWqalJty4tD35m PkDnEsT/OHAzk5eUT3YmCVbvDzQRTNAksc5iavWYLK7TsnTvazPmq0pXYx0cLQ X-Rspamd-Queue-Id: CA1B97ACF3 X-Spamd-Result: default: False [-2.65 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[mail.com]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:74.208.4.192/26]; FREEMAIL_FROM(0.00)[mail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[mail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.com:+]; MX_GOOD(-0.01)[mx00.mail.com,mx01.mail.com]; NEURAL_SPAM_SHORT(0.07)[0.070,0]; IP_SCORE(-0.13)[ipnet: 74.208.0.0/16(-0.54), asn: 8560(-0.12), country: DE(-0.01)]; RCVD_IN_DNSWL_LOW(-0.10)[200.4.208.74.list.dnswl.org : 127.0.3.1]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[mail.com]; ASN(0.00)[asn:8560, ipnet:74.208.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-Mailman-Approved-At: Tue, 11 Dec 2018 05:03:22 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 01:43:25 -0000 I want to torify my FreeBSD old machine purposed to mainly darknet activities. Should I worry about these errors during creating jail? |Warning: Some services already seem to be listening on all IP, (including 127.0.1.1) This may cause some confusion, here they are: root ntpd 58008 20 udp6 *:123 *:* root ntpd 58008 21 udp4 *:123 *:* root lpd 48726 6 tcp6 *:515 *:* root lpd 48726 7 tcp4 *:515 *:* Warning: Some services already seem to be listening on IP 192.168.1.105 This may cause some confusion, here they are: root ntpd 58008 23 udp4 192.168.1.105:123 *:* Warning: Some services already seem to be listening on all IP, (including 192.168.1.105) This may cause some confusion, here they are: root ntpd 58008 20 udp6 *:123 *:* root ntpd 58008 21 udp4 *:123 *:* root lpd 48726 6 tcp6 *:515 *:* root lpd 48726 7 tcp4 *:515 *:| Should jail have access to loopback interface and public Ethernet interface assuming that all traffic from this machine will be routed through Tor? Is it necessary to set up a virtual network interface to communicate between jails? From owner-freebsd-hackers@freebsd.org Tue Dec 11 15:51:01 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 460DA13359C6 for ; Tue, 11 Dec 2018 15:51:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (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 5A4E27BDBC for ; Tue, 11 Dec 2018 15:49:50 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1544543370; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=p59jY7+wPtp5/qvadryeD9RuhYlHk6/x7mSgiafKjRZyqH9aBZ74QJS8qBM+mPXwJbpqOgVRPho87 7zjKrE+5+zsQsXm2LTJ/6B06jOomK2qx8WaPK7eY4+G66XVZYiLSqsIKgglK6agwk0s7brpeqGfdGo DyNR69xJvOLeVukxzbiPwinJHDoYQoUG0pK8dnjPEyT2aNIYkJi8PJ+JFK9zfizyBZz3OkGH/dUehi V4km0QWsdSL9kBY0zLfXLsVeBH+iKT9BehvjwYUYOs1WsS0FVX9IuQYZ/vBloyNk6HnKTYLuMu6bye qPY0qPogLp1mVsK7ZzwKjIiAx1x5uuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=A8Jt865s9lXU+fGNVwLvBsk5aVDdC9I76bKw0UD4MHI=; b=Q2YvBLQSVjbtg5QTzZ70d9pmicFwXH7+qtrb3q7EVmVr1iycREi124jdr7XTeNO1GSIHLLsYHJBNm VYDk2m9ULXGEVhgVCK/cW0BWZ2kbpYmVOdAeEd7pdeKX9SZisKSnzE8Th92mUMhff2Y46JJ8zlCJKC 9sBjz1nTSuqnNP3ncra75crJEGUTlWe5x6AHwdNnu9GaktQlX3En/uFq09/01jcF2qyYPewQb5Zvyb oQGBkEvOzrdmiAfdcHhRzN9hJxrF0Jrkv2ydb54wuITSf0iL/CKtUb1RxWycXNTBfFiWAavNZH2/X/ AMsb4q1B2jzcrpPbLhjPeLPmeM5mswg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=A8Jt865s9lXU+fGNVwLvBsk5aVDdC9I76bKw0UD4MHI=; b=N3xsLzmTDpc2CagGYHDG7RNjMax8M1Yacg4q3idwYsF+wHxySPkK0xpYafu1F73/VrYOwUrEWzkdP eAa8gA1ZU8Yyc62PXdbdngu/Gri2tnr9ZsKIJ9GDHad0MMbHLTsXx/x6jhcrZuUPCWc0BrK267v/3k Ik+HfAHb9EOEaKdIN7QTLa98/zQmJbUIpxzpwCUWBEIcqPXOVijdoVK38AvoEEmol5mm+2E0hhheV5 Ttsfz/tpkiF0vkcWtUbzDdLIHKndUzAV0R8IoazbwvVjwvlMxWrB52a1i5fzl3ZRqhD0yo9rrTHEfV YY+RslJVtK4DTMP15D+OFmaEZBLps4w== X-MHO-RoutePath: aGlwcGll X-MHO-User: 57a45dec-fd5c-11e8-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 57a45dec-fd5c-11e8-befd-af03bedce89f; Tue, 11 Dec 2018 15:49:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBBFnlSk075340; Tue, 11 Dec 2018 08:49:47 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1544543387.1860.347.camel@freebsd.org> Subject: Re: Running Tor service in the jail environment From: Ian Lepore To: Hubert Hauser , freebsd-hackers@freebsd.org Date: Tue, 11 Dec 2018 08:49:47 -0700 In-Reply-To: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> References: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5A4E27BDBC X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 15:51:01 -0000 On Tue, 2018-12-11 at 01:41 +0000, Hubert Hauser wrote: > I want to torify my FreeBSD old machine purposed to mainly darknet > activities. > > Should I worry about these errors during creating jail? > > > > > Warning: Some services already seem to be listening on all IP, > (including 127.0.1.1) This may cause some confusion, here they are: > root > ntpd 58008 20 udp6 *:123 *:* root ntpd 58008 21 udp4 *:123 *:* root > lpd > 48726 6 tcp6 *:515 *:* root lpd 48726 7 tcp4 *:515 *:* Warning: Some > services already seem to be listening on IP 192.168.1.105 This may > cause > some confusion, here they are: root ntpd 58008 23 udp4 > 192.168.1.105:123 > *:* Warning: Some services already seem to be listening on all IP, > (including 192.168.1.105) This may cause some confusion, here they > are: > root ntpd 58008 20 udp6 *:123 *:* root ntpd 58008 21 udp4 *:123 *:* > root > lpd 48726 6 tcp6 *:515 *:* root lpd 48726 7 tcp4 *:515 *:| > > Should jail have access to loopback interface and public Ethernet > interface assuming that all traffic from this machine will be routed > through Tor? Is it necessary to set up a virtual network interface to > communicate between jails? You should not be running ntpd inside a jail, it won't have the priveleges to set the kernel clock anyway, only the ntpd running in a non-jailed environment can do that. I suspect the same is true of lpd, but I've never used that and know nothing about it. -- Ian From owner-freebsd-hackers@freebsd.org Tue Dec 11 16:55: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 B90631337E31 for ; Tue, 11 Dec 2018 16:55:34 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D525F8059D for ; Tue, 11 Dec 2018 16:55:33 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wr1-x42e.google.com with SMTP id x10so14821748wrs.8 for ; Tue, 11 Dec 2018 08:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0aElMd4RGfclfBOQuXTYBKjX5LwmM/t+0NLrK/rXIs4=; b=ilke02go2UqyG4XanaYBixrb4N5u2yfQ+9I/G8elazDoINuxD7TpLleHY9c/Lkcb3x sZw32JoWGzx9kbY+irC3Fn0ZrHUjvqXk9luUwXbZQUeEqlqvvcvp7gEoN6vhfN8L6iqN Jh0iaiNha3ssKz/yzARYKRmfknfg7zBDJhk6WLYPr0MCQ6SN8Xw0Z5KgLD4esrOkU1qk 7MQvUz3qHdGI/mTdh8VQG3435rjMP1XLdpsfqM8b4MhpIlkSopO+FUyzPjV+C99Amsf+ Y+Ru5ObHlzrupQHy+uNv+++iBAUaOv949ubU0GjD9JQ5vCfBAHPL5zpGptydCTijHfET AR+A== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0aElMd4RGfclfBOQuXTYBKjX5LwmM/t+0NLrK/rXIs4=; b=Cjw/dqX1IyYLWeX4IKwIfC/cqZ3xEA3rePe34A73rn5fNL573ubUDbDj/hTO1Bc+/5 6KzB+Frnchigj9fjxQilS+4ZcCVcnDJkL3EZtiKYG/SShy1FRKU00lMBAAgrY9HZXzkX szRXnHWcYMgiRDPO8ca6zxzrC3vrPp+4cQt8evTX4pQpJVcFcg6+y128s7NwqEY1Ht6l xZezQO39XAhP+mZgqPGBbQI0+PGSPjrbo2nWs5mjKMC/52iaYvXYV0831LB6lBVoJHd+ s2yMnUU9jZcKKIQYMMup4222GUQvuWMyv/Hsy9sp3Ia5GQRuTJaHZZYKo1YJXPDTEuhJ OLxg== X-Gm-Message-State: AA+aEWaiZvKSCxMFLBTYT7E35X1WhR1VoEFoZMKB611yeVKF2e68HCIZ lxtgoP20iWvipKJoFnAKlZ0eGQ== X-Google-Smtp-Source: AFSGD/VQ/FK4ZNauj1iIN24LL/EmSkC7WZ4cXL3VR/kZg2JvQjwON+X4CQk+/XM1L+wf7MQ9V+7svg== X-Received: by 2002:a5d:470b:: with SMTP id y11mr14114980wrq.16.1544547332559; Tue, 11 Dec 2018 08:55:32 -0800 (PST) Received: from mutt-hbsd ([216.218.222.14]) by smtp.gmail.com with ESMTPSA id n17sm659056wmc.5.2018.12.11.08.55.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Dec 2018 08:55:31 -0800 (PST) Date: Tue, 11 Dec 2018 11:54:40 -0500 From: Shawn Webb To: Hubert Hauser Cc: freebsd-hackers@freebsd.org Subject: Re: Running Tor service in the jail environment Message-ID: <20181211165440.hscrml6jtvp72hhw@mutt-hbsd> References: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sks7bk5hbsz7jm5q" Content-Disposition: inline In-Reply-To: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT FreeBSD 13.0-CURRENT HARDENEDBSD-13-CURRENT amd64 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: D525F8059D X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=ilke02go; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.974,0]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[mail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; IP_SCORE(-2.21)[ip: (-8.26), ipnet: 2a00:1450::/32(-1.45), asn: 15169(-1.27), country: US(-0.09)]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(3.00)[14.222.218.216.zen.spamhaus.org : 127.0.0.4]; R_DKIM_ALLOW(0.00)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[e.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 16:55:35 -0000 --sks7bk5hbsz7jm5q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2018 at 01:41:50AM +0000, Hubert Hauser wrote: > I want to torify my FreeBSD old machine purposed to mainly darknet > activities. >=20 > Should I worry about these errors during creating jail? >=20 > |Warning: Some services already seem to be listening on all IP, > (including 127.0.1.1) This may cause some confusion, here they are: root > ntpd 58008 20 udp6 *:123 *:* root ntpd 58008 21 udp4 *:123 *:* root lpd > 48726 6 tcp6 *:515 *:* root lpd 48726 7 tcp4 *:515 *:* Warning: Some > services already seem to be listening on IP 192.168.1.105 This may cause > some confusion, here they are: root ntpd 58008 23 udp4 192.168.1.105:123 > *:* Warning: Some services already seem to be listening on all IP, > (including 192.168.1.105) This may cause some confusion, here they are: > root ntpd 58008 20 udp6 *:123 *:* root ntpd 58008 21 udp4 *:123 *:* root > lpd 48726 6 tcp6 *:515 *:* root lpd 48726 7 tcp4 *:515 *:| >=20 > Should jail have access to loopback interface and public Ethernet > interface assuming that all traffic from this machine will be routed > through Tor? Is it necessary to set up a virtual network interface to > communicate between jails? I wouldn't use a jail for that. Take a look at this article I wrote about how to use Tor in the manner you're looking for: https://github.com/lattera/articles/blob/master/infosec/tor/2017-01-14_tori= fied_home/article.md Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --sks7bk5hbsz7jm5q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlwP68sACgkQaoRlj1JF bu5w8Q/9GMkymyjypFrxtF8rMGdOOFWry8rHij8oR8s6tNRZ2Zs+C/f0CCBwylUl b9rinquRH38Vi8RlLZAEopp+nbsGM8Lpy/gg1Ho+IZFNoOKVkb7Yr0aSRyBivF9g oE81gd5Ec5H3CWKi78J6OX6wRhKOxY2K1ChG1miWamw9g+uBSQZR0vZ2nl2W8qws xYdaiYQZW7yWNVqvCPlHcHTWto0kaj8qsstgvb27SU2aKi/g1I15TcJyPYKXNWCh 3r4hJCP+MYTHHVn8tHdRqutCMGXeA55uDNb6MOmZFCpxGIsOPWSAL17ig8rqjFb7 iegJv7bDWUONcTl1y7cxQKOqej2etfXkQCRIl7wkF2avpIQOsBBgWcnhXUM1efNy qPcNftZWiyi6/7fSBsoPVrChdUfySg7FRVMlvb6dTzFqJl2xWU9E3/xrbO1wXI7x b45+gouueJFvCjSLyPMqVoR7sUMqTbu+KyTL1TDuoCz2it9/bNecx5LORsYtLE93 TZCKgcfaMEucdRonKDU9q9KT5YAzF0uqVwCdoHwUajNeYqFDELP7wkIrtDwGhG/h R9eA30nIVZk2OXjcH3PfOgGbXM9fPg/e7Rf/D6jtTQmZcyQxwLmfBWAMt3RadxhS XemTbxg3Q0q1kjokc/QeLC8xXvYV5kqL3oVgDqyNUJndZUq2Ez0= =gVwW -----END PGP SIGNATURE----- --sks7bk5hbsz7jm5q-- From owner-freebsd-hackers@freebsd.org Tue Dec 11 18:59: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 B0B00130F0F0 for ; Tue, 11 Dec 2018 18:59:54 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from cloud-vps.localdomain (unknown [IPv6:2001:15e8:110:75a::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 F282A85FE0 for ; Tue, 11 Dec 2018 18:59:53 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from localhost (localhost [127.0.0.1]) by cloud-vps.localdomain (Postfix) with ESMTP id 009C340635 for ; Tue, 11 Dec 2018 19:59:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.autisticstory.net Received: from cloud-vps.localdomain ([127.0.0.1]) by localhost (mail.autisticstory.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovKm3eLhM_6A for ; Tue, 11 Dec 2018 19:59:48 +0100 (CET) Received: from [192.168.1.104] (unknown [83.142.188.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: atypical@autisticstory.net) by cloud-vps.localdomain (Postfix) with ESMTPSA id 4AB953FD09 for ; Tue, 11 Dec 2018 19:59:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=autisticstory.net; s=201807; t=1544554788; bh=/pXQnTDOUiXU6llget3c8qDX6dk2iT99boMRvSEODsc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FMwZ67E8xM7Rtn3KJSo8//hMNS9GetCu6ISoFe3yHO7f4geMkWmYY5VQGe2TaA4PB G/v/OO6b2M1X7ef9vp8XIF9zkNmKOYUPhC6jZ0rNo3Xh4KSkYZ+S+DqQsvAMe93n/A dWhP3Z7sZzlKRN64AYenmnfAZocA+39/+gB07ygNRhOdrcd/zrFDxM/9uT7LeHoh0u 2+tjmAqGeKubvbKhYIH0ip0BU3p7OS3jG+8teS3qht1hKXc62WjFn+PW/NA0vpoWLV 0Qc9ewUD8DZaY1serrUb2x6zYGu6QqAPitSrz7tiuhe4mY6yJrt9ySpZFl+83pxK3c b/0gCoY6QUpK0E9Jyd0Uu08gnl64OxzdSTj5ZBhihHpKO30cPLhK2+XXAsp09I7nS0 uRpwKoc1w9h2+G9zwUx160TaBnCOgT3uQd6KIBpNVWGXBhaZM2EBIZa+gXUgS6rKen JeNKioHG/qq7H7N5R4PNHCkTbnfzQ5xQQ4UwjhAuZ+Jw2vW1b0bIHCVtX09nNwdhAM 3XqyG1j3aTP3TxxdmfaPioXCz8BmP2gdpzu6hlBKtsPrKs0+TcuC2IPPSswGaTUMNS CQ6TTXSbqnscS3PeIARtFKbxvxK/FRmuQnTMc6gxWA9Jol9gy2nb0oCCTQS26F7BSN yKMGdUrL7lNgW78PmBmbk/8M= Subject: Re: Running Tor service in the jail environment To: freebsd-hackers@freebsd.org References: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> <1544543387.1860.347.camel@freebsd.org> From: Hubert Hauser Openpgp: preference=signencrypt Autocrypt: addr=atypical@autisticstory.net; keydata= xsFNBFvfH1cBEADMaaPj9N4y/pGIYrpYgkmabzCa+3AP/GZH3++d7DLGcVH7cePoCKKANa/F 9LXXACQDMmkdXBPXndUAN1sZmzYiQF+E15G9U9BEx1wBJxMmevGbJ28XGIu8ZTwOcNzIlO5G yhQVbKlfckuIEMFnPhqm863a91UyyQL19/JWnDBfq/DOTmPSc/tWPfWgpJdCsI6zRWreLXCb fwVg4L3prqkJbjVIuPsKS5YBF1eII6ABqcFvlGdZFQaN6Cy/4+pswVQUAaySWG/1tYq9XMbV 6zuBl15l8txRYu0aNdnV6A6900HmeKAWCthw1JMemOggMokxU5OR8dHez0CMPDvSJaXLJr0t wZeOlcK2Z8vSE1IRyvdSbtBKWM6YzfX+hOQzxRGy3qi4Z8Pk1yx9pjtrueM1Fhz3Ag7TQNuv tLMlfYx1PgZyWVNo8K7J/D2jS/Sk6uMkgMfq5D3Ef1sJb8lh2kIxU5mRrlQQof+g/HW9iIP2 qXuylJvwNGpqGX52Hrz17B6tZaRtBnRHV2ZX4dv3LI+msGzjePrYdKPUmjdkPf8ztUps0qMY F93zXL5PEyuv9UmNeJlr+5UCcWWB9w71vSbTCqIIxTzhlQ+09118b//XTYYnolAcFb3KE5iM eMYG67OkmvAjaKFh75TKlGcQNmvX45l4kzl9guyYsysH7knJQQARAQABzSpIdWJlcnQgSGF1 c2VyIDxhdHlwaWNhbEBhdXRpc3RpY3N0b3J5Lm5ldD7CwZQEEwEIAD4WIQRJqW9Zo0ULA/tV 5BgsJbHYs2XiPQUCW98fVwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAs JbHYs2XiPcuXEACsPUZvMEJ7wUfnRr0EEVF3jWCuTSW2cD/HJG2mgwmu0SHDQJTwn5TNUYfv Yt2fBnL6TxnJxz2gjnF7DLuk7Gpo5ABmIjuh41f4NaVIbiBdVhMjueQISSEaaMJTbg4lQpr5 kPR+SWN6om3gff7V2SJ9ZozsVl/wc1wl75ndwk87gxvZJsQxhwIB6JOWCrtnD6SbldDcrKy9 wYGTEKnZpHMQaE5BB/1BADrHICPe4V2GYVTNpV/o7cneVAPSUT/AlUJHvVq6PWEOg7ld/rWq CaW9YbR+/wSikiwY5X7F+yg33G3Ys0mHVuDnWIKhGr24C/n6g3PjWTAdpg3MTBDitYFxjucZ S1luTooCkgYIF04/weV2ghrVOvAYCbtr+oN5mvfR2BwIW6v6SChyHOUMAEYyA2SHOjlNEv7+ Ws9zEHYlYXeTYIc/KMxsSEaVSuXQfsVn5uxMHlbeJ5ypMBDdke9zh6XJ39npgkR2eFHQJIqd 4BTqQbuSJPZllhXYwaeHfMy4ZZf41JFdXLNBXeQqXvnjjugGG0IrsC72OORp9iE+/4zbO/yg BvMD0jWVO94DL/3amH4nMM0RUBXIlo0mBDeuDvB0PIAyw2/fqSuMAmykLI40JoaKIfgeMcyU bv4Ra06Lz8oLXC63T6ZKT655lLU/P1cbgJXiwGjPvjupir9nEs7BTQRb3x9XARAAsz4qZEDX HpJ7s9AJS0YWjMkG2STodEV6XNaNum5BnXUF583vJUeAH9bEGqh0CY+MDXBhs4diLGVbacpe Vzac6UBQYKdwfYeZMuX5TFvPsVBv3XGvrNfhNWFnPlTUA7r9fah4QFNcDX0nRt/y1wtGknb1 JQW3vVRb/Z0q4oemPRw1cZ7yCsgBD1yD6ib13U8VYt6v+jxavS6EKh6hXjb/gUC/KOvsm2t7 UIBV5C0b8O98Dvy5csi5qQx3x0h7IAOvchpJ8i31Ke0s7xaJf2ghW2YqfNZOujtebqbc9/uf wuNOCQkL/yRirWpe7WXGAGUbM2rsqucWWpEKaHEEc5icYEeShJOyESOvRR1aEWeNBbntXMXK KMeUzLwYlqPptTxOWApIPbKJ37fHEG8QJi2H1jyn+NKLzB75GsyydUkmj/dLAuD00OF9Nn5B iJQPNFV58Q7VL99pTBhzXDj/2ZHxnYt0dVnyxE+FEOdklIcwX1PizUwHz01nUyFn+7bjgiFS LE2/5P8p7KDnpZAJgIy06sD2g8CsM4WUzRx4VHvHFkJhEWBA/E7AE+JVdEcyzjrhbM4xPR6i GbbxdvzLkUY5puM9srCnDmEN92k8joV3gFRffd2z7wIC+fYtZAhKqJiPHBaLZRQGDwmqO85x zbZBz8BPcP10JE7I4zjXvQmywgsAEQEAAcLBfAQYAQgAJhYhBEmpb1mjRQsD+1XkGCwlsdiz ZeI9BQJb3x9XAhsMBQkJZgGAAAoJECwlsdizZeI9B3kP/iBhveI7ov5IXgSMUmeMyc0MXrUB S8F4KE6kS4o82MGXPFpJunWM8WFtJwmOt6AmtE49RzuI0tH6RPfumiCFs8oaQxfQIfOw9q1I xKgF2nGRBf40OU69K7p9tKEFhqiJRyoqyTNmdunRbMTKUPobyxbH7RArobq+YaDiu4DKZ43Z W/0yR/Z0OBavE3aXeN2ePX6JM0sF2MWBIyha4lT7va1njcgLjUHzMi0l8XLAYH/YfuDHbi3S g5rDXGuvA/DfjHV3Yup1tdx+u3X65sKmSvQ1E8Ol8QCbxyfcHWResAdBdIrBBtQ6PjTw+bS4 29UCVyUJBP8oDWv3G4F9or+rUZjVxSyVdRIsFMe7+64gcPc8GFiT2ML2WhlK15b/F6qrT/bz eT/LATJUyBhYy5FEgaN1sR0YH6PPj1yOOiFS3shY1frasSZrtQS0uOv1tbR0kC40LRwIjodT CiqqoeocxvmCcSUmdS7sO5dwk5UxqHb0pggicR4FtAi9MsAFgqQLli32uAk3sKcoweuzurGe CRZQ3j54zXYQTXMc5l4ciZrwlt9l58VJvWqJzvBxa9XY7I8Y65FfA0dr+QaGtc85Ahq4LVF4 asP53ZlxwK4U7IQC0eg+LctuAxyoViMmGUu2G4arr4N8lGkiXyzzcP9QkWD0uCaH/Ig2JsC7 sCu5NBfl Message-ID: <65a5540f-2f1c-0470-b650-cf9fd696ea7a@autisticstory.net> Date: Tue, 11 Dec 2018 19:58:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <1544543387.1860.347.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 18:59:55 -0000 Hello! > You should not be running ntpd inside a jail, it won't have the > priveleges to set the kernel clock anyway, only the ntpd running in a > non-jailed environment can do that. How can I prevent running ntpd and lpd in the jail environment? > I wouldn't use a jail for that. Take a look at this article I wrote > about how to use Tor in the manner you're looking for: > > https://github.com/lattera/articles/blob/master/infosec/tor/2017-01-14_= torified_home/article.md It sounds like a good idea but weren't a better solution use an open-hardware device acting as Tor router with installed OpenBSD or HardenedBSD? Why wouldn't you use for it jail environment? I want to place Tor in the jail environment because I want to prevent system being compromised in case compromising Tor service. Thank you in advance, Hubert. From owner-freebsd-hackers@freebsd.org Tue Dec 11 19:12: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 01A3313100FC for ; Tue, 11 Dec 2018 19:12:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (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 5EE168722A for ; Tue, 11 Dec 2018 19:12:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1544555552; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=ZGA35fk4sc+GrtiNE4/JkdLKY+BBsXmsViOPf7jfv1mzJSi2qmt4v4EFqW+mz68zvcqtqGYxZeY8U rU2Kcir76s4k55Tb99vOSBvM89hwygDQ/BabAGt4x/OpeiZffp29sNPyGE24I08pRgBGDmCkAoun5s g36NeHe3PC+cJaJKriUZqzFpKuitSpFa+24kc3EBrhxFLhMEaQZouQyJo+ZecZE44Ax3lLa+InC188 l4E0yQRYz/4pcoFVp9a4Cxwuf0/JQYqFZydcNZ5oqrzigjifYFm2DeBHXiSH0Iw1nULkCtf0vshaHi mSa4WrFYUfIaU84bqnuquYjzGgDmmHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=S3ntATMsWw1wYis5WyNEdBiu+Gr6FLBooBsJzz5wO5U=; b=P+oMakK2Btyad51a45VoPLa8Wsl/7NN/QmpOczFLTwj/hh33/e+oUqCm6DO0pqGzCHFfgKZ67Kod3 HR0VGa+ilc20kuHuLzgkdL0GZFOLlvIyYlCcgMU59rdxpTclUBZQgX5s6tPUzvJD3+jAWtKBpRfILN UoQxvdOeSnlOtjHbkFAG1ydqSqaqQWKncDCbGtJDrdyjyqM3tE6KDlew5KjYP9RqfOuWOGM+mPwFhH 4QGSToVXMP6MQSS8Kfr2fcr6UlsiJ0Blxw9QtEiMjbyn6lzWJCmo1pjBNdeLXEF826u38hw+h5NFPH rXmf8tlO62rgmfkcPF0Y7uHCF2ZLtJQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=S3ntATMsWw1wYis5WyNEdBiu+Gr6FLBooBsJzz5wO5U=; b=u4cASiEqO5GJ5H3+xN1lpBjRYtyPnbcv+33d0GGJggieeDEFD3jb02xC4bRr5fUEEH4YZGj6mFkpa dFfMWgKb7sQL2y1w6QSFTVkyEgq6d9aRyKeq+eU3125QEkUMixxz29fhR998Hy40dP1eZkXFqbJkf4 y/SkBqNpPDQx7Pm2ZC/wIqM91w6ZJJoedj4ecDt3LLfXX+wu5xHjdA/EFlHvfdPDM3yEbUeLRQl8Zw WjZzQJ4EU5sNEYnI9nbX7PNCHaE8pSpQEM2qiKzqrAYykCurkAzgklLqzUzn70kKFr+dKUGv+sB15X 9W/Lv00UAm9jl5IcmGYdKT8XTiin7dg== X-MHO-RoutePath: aGlwcGll X-MHO-User: b45d063d-fd78-11e8-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id b45d063d-fd78-11e8-befd-af03bedce89f; Tue, 11 Dec 2018 19:12:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBBJCmJ5075644; Tue, 11 Dec 2018 12:12:48 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1544555568.44045.12.camel@freebsd.org> Subject: Re: Running Tor service in the jail environment From: Ian Lepore To: Hubert Hauser , freebsd-hackers@freebsd.org Date: Tue, 11 Dec 2018 12:12:48 -0700 In-Reply-To: <65a5540f-2f1c-0470-b650-cf9fd696ea7a@autisticstory.net> References: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> <1544543387.1860.347.camel@freebsd.org> <65a5540f-2f1c-0470-b650-cf9fd696ea7a@autisticstory.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5EE168722A X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.97 / 15.00]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 19:12:55 -0000 On Tue, 2018-12-11 at 19:58 +0100, Hubert Hauser wrote: > Hello! > > > > You should not be running ntpd inside a jail, it won't have the > > priveleges to set the kernel clock anyway, only the ntpd running in > > a > > non-jailed environment can do that. > How can I prevent running ntpd and lpd in the jail environment? > Set the appropriate variables (ntpd_enable=NO, etc) in the /etc/rc.conf for the jail. -- Ian > > > > I wouldn't use a jail for that. Take a look at this article I wrote > > about how to use Tor in the manner you're looking for: > > > > https://github.com/lattera/articles/blob/master/infosec/tor/2017-01 > > -14_torified_home/article.md > It sounds like a good idea but weren't a better solution use an > open-hardware device acting as Tor router with installed OpenBSD or > HardenedBSD? Why wouldn't you use for it jail environment? I want to > place Tor in the jail environment because I want to prevent system > being > compromised in case compromising Tor service. > > Thank you in advance, > Hubert. > > > _______________________________________________ > 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 Dec 11 19:14: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 9B2471310288 for ; Tue, 11 Dec 2018 19:14:42 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from cloud-vps.localdomain (unknown [IPv6:2001:15e8:110:75a::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 02CC2873D8; Tue, 11 Dec 2018 19:14:42 +0000 (UTC) (envelope-from atypical@autisticstory.net) Received: from localhost (localhost [127.0.0.1]) by cloud-vps.localdomain (Postfix) with ESMTP id BFD4D40635; Tue, 11 Dec 2018 20:14:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.autisticstory.net Received: from cloud-vps.localdomain ([127.0.0.1]) by localhost (mail.autisticstory.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZg6-oz2dmsR; Tue, 11 Dec 2018 20:14:38 +0100 (CET) Received: from [192.168.1.104] (unknown [83.142.188.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: atypical@autisticstory.net) by cloud-vps.localdomain (Postfix) with ESMTPSA id 7DDCA3FD09; Tue, 11 Dec 2018 20:14:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=autisticstory.net; s=201807; t=1544555678; bh=UWEfjO6wNIMGJPyhxeKjaoFECGMyThnMh95Ld7KszoA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lW5jxFFd7DCQaW9Pf74duQJyQindu4Mnc5f5M9TlM3Q+EF/lmjkvjxjlgpvLe5Jva DcZtddH8fgIPFAw5GwOptORUVzhynUtfW5YhqZqoNb3VKeXM5DLUKx6lD5hMG8tGj5 /Xvl/V12NLEB+gvT+L3SkoeIkTWaBEkrn4Q1yGSDcilQF6NvOCqu5LUt562Yhx+Mt4 VTs48XyaDCT5n+qvEbvIioNO/68/mhO0fZlkrWrfn9zTpp7rrVWLES99+dFc3Rvh3T tDBjyhtAt1dPk968e1lsshofLeS8Fv3dfLYnSQd5K6H1KDZDqxxqbFFd5YW6Lp3XAh /XZHpFur61uDjSSea9JiHGCmHuT8akow1wOFQN7Syq5RPd4L9tESyZDh6bIt0Ubqgc V/Xs6HQ3zIzbEcCux6x/Wb9bm4jVtFxtvZrksKNWBXb7k9aF3ifAxoXHyCWnl6FiOV jOGYpe/KTOAO2xC/maA7bRSHfwW5eN4y/KyxIkmwPBUL1HUzAx1lUhvOA1YMFeq1Ns 4TBlWCRv2oyY49RXeCoVRmKmAFfBFJBxzdZVeLxyfSSrjFbDKZz1A6JD/tF0TlBepB 17JrEqZiV8noPyGXnelOpFDoT0kO9ipXHD2XQF4A/oBh2Zr2zGT+Hi653i/tq82pNi tNbmcUvSRF3yQVPM2py5eRRg= Subject: Re: Running Tor service in the jail environment To: Ian Lepore , freebsd-hackers@freebsd.org References: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> <1544543387.1860.347.camel@freebsd.org> <65a5540f-2f1c-0470-b650-cf9fd696ea7a@autisticstory.net> <1544555568.44045.12.camel@freebsd.org> From: Hubert Hauser Openpgp: preference=signencrypt Autocrypt: addr=atypical@autisticstory.net; keydata= xsFNBFvfH1cBEADMaaPj9N4y/pGIYrpYgkmabzCa+3AP/GZH3++d7DLGcVH7cePoCKKANa/F 9LXXACQDMmkdXBPXndUAN1sZmzYiQF+E15G9U9BEx1wBJxMmevGbJ28XGIu8ZTwOcNzIlO5G yhQVbKlfckuIEMFnPhqm863a91UyyQL19/JWnDBfq/DOTmPSc/tWPfWgpJdCsI6zRWreLXCb fwVg4L3prqkJbjVIuPsKS5YBF1eII6ABqcFvlGdZFQaN6Cy/4+pswVQUAaySWG/1tYq9XMbV 6zuBl15l8txRYu0aNdnV6A6900HmeKAWCthw1JMemOggMokxU5OR8dHez0CMPDvSJaXLJr0t wZeOlcK2Z8vSE1IRyvdSbtBKWM6YzfX+hOQzxRGy3qi4Z8Pk1yx9pjtrueM1Fhz3Ag7TQNuv tLMlfYx1PgZyWVNo8K7J/D2jS/Sk6uMkgMfq5D3Ef1sJb8lh2kIxU5mRrlQQof+g/HW9iIP2 qXuylJvwNGpqGX52Hrz17B6tZaRtBnRHV2ZX4dv3LI+msGzjePrYdKPUmjdkPf8ztUps0qMY F93zXL5PEyuv9UmNeJlr+5UCcWWB9w71vSbTCqIIxTzhlQ+09118b//XTYYnolAcFb3KE5iM eMYG67OkmvAjaKFh75TKlGcQNmvX45l4kzl9guyYsysH7knJQQARAQABzSpIdWJlcnQgSGF1 c2VyIDxhdHlwaWNhbEBhdXRpc3RpY3N0b3J5Lm5ldD7CwZQEEwEIAD4WIQRJqW9Zo0ULA/tV 5BgsJbHYs2XiPQUCW98fVwIbIwUJCWYBgAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAs JbHYs2XiPcuXEACsPUZvMEJ7wUfnRr0EEVF3jWCuTSW2cD/HJG2mgwmu0SHDQJTwn5TNUYfv Yt2fBnL6TxnJxz2gjnF7DLuk7Gpo5ABmIjuh41f4NaVIbiBdVhMjueQISSEaaMJTbg4lQpr5 kPR+SWN6om3gff7V2SJ9ZozsVl/wc1wl75ndwk87gxvZJsQxhwIB6JOWCrtnD6SbldDcrKy9 wYGTEKnZpHMQaE5BB/1BADrHICPe4V2GYVTNpV/o7cneVAPSUT/AlUJHvVq6PWEOg7ld/rWq CaW9YbR+/wSikiwY5X7F+yg33G3Ys0mHVuDnWIKhGr24C/n6g3PjWTAdpg3MTBDitYFxjucZ S1luTooCkgYIF04/weV2ghrVOvAYCbtr+oN5mvfR2BwIW6v6SChyHOUMAEYyA2SHOjlNEv7+ Ws9zEHYlYXeTYIc/KMxsSEaVSuXQfsVn5uxMHlbeJ5ypMBDdke9zh6XJ39npgkR2eFHQJIqd 4BTqQbuSJPZllhXYwaeHfMy4ZZf41JFdXLNBXeQqXvnjjugGG0IrsC72OORp9iE+/4zbO/yg BvMD0jWVO94DL/3amH4nMM0RUBXIlo0mBDeuDvB0PIAyw2/fqSuMAmykLI40JoaKIfgeMcyU bv4Ra06Lz8oLXC63T6ZKT655lLU/P1cbgJXiwGjPvjupir9nEs7BTQRb3x9XARAAsz4qZEDX HpJ7s9AJS0YWjMkG2STodEV6XNaNum5BnXUF583vJUeAH9bEGqh0CY+MDXBhs4diLGVbacpe Vzac6UBQYKdwfYeZMuX5TFvPsVBv3XGvrNfhNWFnPlTUA7r9fah4QFNcDX0nRt/y1wtGknb1 JQW3vVRb/Z0q4oemPRw1cZ7yCsgBD1yD6ib13U8VYt6v+jxavS6EKh6hXjb/gUC/KOvsm2t7 UIBV5C0b8O98Dvy5csi5qQx3x0h7IAOvchpJ8i31Ke0s7xaJf2ghW2YqfNZOujtebqbc9/uf wuNOCQkL/yRirWpe7WXGAGUbM2rsqucWWpEKaHEEc5icYEeShJOyESOvRR1aEWeNBbntXMXK KMeUzLwYlqPptTxOWApIPbKJ37fHEG8QJi2H1jyn+NKLzB75GsyydUkmj/dLAuD00OF9Nn5B iJQPNFV58Q7VL99pTBhzXDj/2ZHxnYt0dVnyxE+FEOdklIcwX1PizUwHz01nUyFn+7bjgiFS LE2/5P8p7KDnpZAJgIy06sD2g8CsM4WUzRx4VHvHFkJhEWBA/E7AE+JVdEcyzjrhbM4xPR6i GbbxdvzLkUY5puM9srCnDmEN92k8joV3gFRffd2z7wIC+fYtZAhKqJiPHBaLZRQGDwmqO85x zbZBz8BPcP10JE7I4zjXvQmywgsAEQEAAcLBfAQYAQgAJhYhBEmpb1mjRQsD+1XkGCwlsdiz ZeI9BQJb3x9XAhsMBQkJZgGAAAoJECwlsdizZeI9B3kP/iBhveI7ov5IXgSMUmeMyc0MXrUB S8F4KE6kS4o82MGXPFpJunWM8WFtJwmOt6AmtE49RzuI0tH6RPfumiCFs8oaQxfQIfOw9q1I xKgF2nGRBf40OU69K7p9tKEFhqiJRyoqyTNmdunRbMTKUPobyxbH7RArobq+YaDiu4DKZ43Z W/0yR/Z0OBavE3aXeN2ePX6JM0sF2MWBIyha4lT7va1njcgLjUHzMi0l8XLAYH/YfuDHbi3S g5rDXGuvA/DfjHV3Yup1tdx+u3X65sKmSvQ1E8Ol8QCbxyfcHWResAdBdIrBBtQ6PjTw+bS4 29UCVyUJBP8oDWv3G4F9or+rUZjVxSyVdRIsFMe7+64gcPc8GFiT2ML2WhlK15b/F6qrT/bz eT/LATJUyBhYy5FEgaN1sR0YH6PPj1yOOiFS3shY1frasSZrtQS0uOv1tbR0kC40LRwIjodT CiqqoeocxvmCcSUmdS7sO5dwk5UxqHb0pggicR4FtAi9MsAFgqQLli32uAk3sKcoweuzurGe CRZQ3j54zXYQTXMc5l4ciZrwlt9l58VJvWqJzvBxa9XY7I8Y65FfA0dr+QaGtc85Ahq4LVF4 asP53ZlxwK4U7IQC0eg+LctuAxyoViMmGUu2G4arr4N8lGkiXyzzcP9QkWD0uCaH/Ig2JsC7 sCu5NBfl Message-ID: Date: Tue, 11 Dec 2018 20:13:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <1544555568.44045.12.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 19:14:42 -0000 Hi there! > It sounds like a good idea but weren't a better solution use an > open-hardware device acting as Tor router with installed OpenBSD or > HardenedBSD? Why wouldn't you use for it jail environment? I want to > place Tor in the jail environment because I want to prevent system > being > compromised in case compromising Tor service. Ian, thank you for reply about disabling ntpd in jails but you haven't replied for above questions. Cheers, Hubert. From owner-freebsd-hackers@freebsd.org Tue Dec 11 19:15:59 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 EEEE013103D1 for ; Tue, 11 Dec 2018 19:15:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (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 74EAA87507 for ; Tue, 11 Dec 2018 19:15:58 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1544555736; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=l6KnlCGKkbgmit8Z9ibyaqdY6xroVr87VMHVU/E4WNC2apG0snEKpaV1GIun0Ok8etLD8iRoi9Lgq DvlF41bVQW4fdTU0CzNfw3eY/8BtHYQFCiIfcflH9DbqrDPNQME9WdXInQM9F07yCTcf/iI8+Q+Kdo XoGLzC+kdVugETrQ1mF+RfnhVxjl543muZbzUDctGsKBs7FA3+JbcT8X8VG8PWViDNNFAaJTMWYqdr bdOAJWNztZNh9Oh979RVXhEB6LsCGjuJC1yPBaOO73XBl0Fk1rtnZvnlqnw6y45Yrva0Ws24/DvD+m USZctTUfIqDEh5LXqmaEPXAja2JTWCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=dPYH9NKLMzespEA+4evCi3SRXJw67sSGr7KDhqRrr0o=; b=ro4BG/s8lCOo8460gQofFJgZ2UT5hMjX5CMl/QptNYrD04HBQIyyBpAgNDaCQQuVnx33OeUuChly/ xyDdarh0YdPizARe0hHhdP9bZrW/uCp/AVKUNKKoaPSljqyHaqXl+6muYA/KiFzxWZkmo7+eFO/2c3 FPcCB2Jv6CVgpAPWXeqW9Tje1rZw1RfQs+Ke4XTNlhXrGWi2vgZq0WgcRUt/4njP8ZYIp74xcdDS55 m15R4foTaKzZXDxhx+ZejcIUBDhV5ke5RMEAvRbuwUu5Fq9RjyG0aZvPYb3s9k4gyQX44t60BQ4pqT 3By4aTAZcb9aujuesGbOJLRS90DKQog== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=dPYH9NKLMzespEA+4evCi3SRXJw67sSGr7KDhqRrr0o=; b=d5pNyeEuqWyJQ4IBiHTFTyo9R0QXR3TY5+SS8Q6A/8ZviojYiO1fNKC3Z5Wfz/F9amr2on9B1s9j5 JOC8VZetVLhNi+t/dGor7dt9dnApRuU+82U2Fw4V3x7lkcWBxCJUBhWOSVmjXcfjSpcaXEPMTjCIvO 3PtdOORzdIxJ0cff6goWlTPLEGaZh+nky85K/fn8S782FlCkHHtRG61DzHwSnkAI3AgX4Gi8neXTLI 4rTea5xXXyWp4j0n4IJiDOG2b5CyXH+B/YoNfBQLSxGpZKEI2c/TOv7gExjMckjOOB/7ou7lKOyppV 2+shtbmj0Yd+lOsFIKME8KDIiruB+sw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 22a8f89e-fd79-11e8-a59a-7b143e15dabc X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 22a8f89e-fd79-11e8-a59a-7b143e15dabc; Tue, 11 Dec 2018 19:15:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBBJFt6R075667; Tue, 11 Dec 2018 12:15:55 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1544555755.44045.14.camel@freebsd.org> Subject: Re: Running Tor service in the jail environment From: Ian Lepore To: Hubert Hauser , freebsd-hackers@freebsd.org Date: Tue, 11 Dec 2018 12:15:55 -0700 In-Reply-To: References: <66526968-1446-c95e-629a-fb9e1b246111@mail.com> <1544543387.1860.347.camel@freebsd.org> <65a5540f-2f1c-0470-b650-cf9fd696ea7a@autisticstory.net> <1544555568.44045.12.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 74EAA87507 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.97 / 15.00]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 19:15:59 -0000 On Tue, 2018-12-11 at 20:13 +0100, Hubert Hauser wrote: > Hi there! > > > > > It sounds like a good idea but weren't a better solution use an > > open-hardware device acting as Tor router with installed OpenBSD or > > HardenedBSD? Why wouldn't you use for it jail environment? I want > > to > > place Tor in the jail environment because I want to prevent system > > being > > compromised in case compromising Tor service. > Ian, thank you for reply about disabling ntpd in jails but you > haven't > replied for above questions. > > Cheers, > Hubert. > I know nothing about tor, or hardendedbsd, or openbsd.  I answered the part I do know about. -- Ian From owner-freebsd-hackers@freebsd.org Wed Dec 12 11:58: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 C1D1A133A837 for ; Wed, 12 Dec 2018 11:58:26 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (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 A2CCB8C9F6 for ; Wed, 12 Dec 2018 11:58:25 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Wed, 12 Dec 2018 12:53:15 +0100 id 00DD601F.5C10F6AB.0000A0AF Date: Wed, 12 Dec 2018 12:53:14 +0100 From: Milan Obuch Cc: freebsd-hackers@freebsd.org Subject: Re: EFI boot with multiple alternate boot/OS partitions - possible? Message-ID: <20181212125314.75464bac@zeta.dino.sk> In-Reply-To: <20181130174510.2944ffae@zeta.dino.sk> References: <20181130151820.1a197589@zeta.dino.sk> <20181130174510.2944ffae@zeta.dino.sk> Followup-To: Warner Losh X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; i386-portbld-freebsd10.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A2CCB8C9F6 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [3.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.70)[0.699,0]; MX_GOOD(-0.01)[mail.dino.sk]; MISSING_TO(2.00)[]; IP_SCORE(0.01)[country: SK(0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 11:58:27 -0000 On Fri, 30 Nov 2018 17:45:10 +0100 Milan Obuch wrote: > On Fri, 30 Nov 2018 09:23:31 -0700 > Warner Losh wrote: > > > On Fri, Nov 30, 2018 at 7:26 AM Milan Obuch > > wrote: [ snip ] > > > Then partitions' roles are swapped, as /etc/fstab file in now > > > active secondary partition would be > > > > > > # Device Mountpoint FStype Options Dump Pass# > > > /dev/sdda0p2 /alt ufs ro 2 2 > > > /dev/sdda0p3 / ufs ro 1 1 > > > /dev/sdda0p4 none swap sw 0 0 > > > > > > Any ideas/hints would be appreciated, I tried to look into > > > efibootmgr and efivar man pages, but got no clear idea how they > > > could be used for my purpose. I do not fully understand some > > > details of EFI boot process, so if some good material for reading > > > is available, let me know (I did some googling, but found no > > > definitive answers yet). > > > > efibootmgr is what you want, though if it's under-documented we > > should fix that. Assuming that p1 is the ESP, you should be able to > > do: > > > > efibootmgr -c -l ssd0p1:/efi/freebsd/loader.efi -k > > ssd0p3:/boot/kernel/kernel -b 10 -a > > efibootmgr -c -l ssd0p1:/efi/freebsd/loader.efi -k > > ssd0p2:/boot/kernel/kernel -b 11 -a > > > > this will setup Boot0010 and Boot0011. > > > > You can then set the order either with efibootmgr -o or efibootmgr > > -n. In theory you can also use the full unix path for the -k and -l > > lines if things are mounted, but I hadn't fixed all the weird edge > > cases with that which kept cropping up (I think they are are fixed > > since I can't recreate the problems, but I'm not 100% sure). > > > > Thank you for quick reply! Yes, this looks really well, so I test what > you wrote to verify it (and learn a bit more, again). This just fills > one gap in my undestanding the process of UEFI boot. I try to read our > man pages again, and if verified successfully, write something to > document this usage. > I experiment a bit with it, command arguments need slight modification: efibootmgr -c -l sdda0p1:/efi/boot/bootx64.efi -k sdda0p2:/boot/kernel/kernel -a Boot0003 There is a complaint when trying to use -b option, rejected as invalid option. Also -a option requires argument, so I ended with the command I wrote. This is usable for my purpose. I do not understand in detail variable behavior... First, I have following: efibootmgr -v BootCurrent: 0004 Timeout : 1 seconds BootOrder : 0004, 0001, 0000, 0002 +Boot0004* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) sdda0p1:/EFI/BOOT/BOOTX64.EFI (null) HD(3,GPT,32401f28-ec10-11e8-8f99-00073249ad88,0x364028,0x300000)/File(\boot\kernel\kernel) sdda0p3:/boot/kernel/kernel //boot/kernel/kernel Boot0001 UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012) Boot0000 Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) HD(2,GPT,02c27b37-4fb4-4890-8382-f4d25a60f5e9,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) Boot0002 ubuntu VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) HD(1,GPT,dc7cd941-1c91-4076-89db-2650d73ef7a5,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI) Then, after issuing command to create new variable, I got efibootmgr -v BootCurrent: 0004 Timeout : 1 seconds BootOrder : 0003, 0004, 0001, 0000, 0002 Boot0003* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\efi\boot\bootx64.efi) sdda0p1:/efi/boot/bootx64.efi (null) HD(2,GPT,d8ae0cb4-ec14-11e8-8041-00073249ad88,0x64028,0x300000)/File(\boot\kernel\kernel) sdda0p2:/boot/kernel/kernel /alt//boot/kernel/kernel +Boot0004* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) sdda0p1:/EFI/BOOT/BOOTX64.EFI (null) HD(3,GPT,32401f28-ec10-11e8-8f99-00073249ad88,0x364028,0x300000)/File(\boot\kernel\kernel) sdda0p3:/boot/kernel/kernel //boot/kernel/kernel Boot0001 UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012) Boot0000 Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) HD(2,GPT,02c27b37-4fb4-4890-8382-f4d25a60f5e9,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) Boot0002 ubuntu VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) HD(1,GPT,dc7cd941-1c91-4076-89db-2650d73ef7a5,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI) This changes partition used for system load, but after reboot, I am getting efibootmgr -v BootCurrent: 0003 Timeout : 1 seconds BootOrder : 0003, 0001, 0000, 0002 +Boot0003* HD(1,GPT,22d32889-ec10-11e8-8f99-00073249ad88,0x28,0x64000)/File(\EFI\BOOT\BOOTX64.EFI) sdda0p1:/EFI/BOOT/BOOTX64.EFI (null) HD(2,GPT,d8ae0cb4-ec14-11e8-8041-00073249ad88,0x64028,0x300000)/File(\boot\kernel\kernel) sdda0p2:/boot/kernel/kernel //boot/kernel/kernel Boot0001 UEFI: Built-in EFI Shell VenMedia(5023b95c-db26-429b-a648-bd47664c8012) Boot0000 Windows Boot Manager VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) HD(2,GPT,02c27b37-4fb4-4890-8382-f4d25a60f5e9,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI) Boot0002 ubuntu VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb) HD(1,GPT,dc7cd941-1c91-4076-89db-2650d73ef7a5,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI) which means original Boot0004 is lost. This is not a big deal, I just thought boot variables are being kept once defined, so it is necessary just switch active one, but if it needs new definition when partition swap is desired again, it is just a line in a script, so no trouble at all. Thanks again and regards, Milan From owner-freebsd-hackers@freebsd.org Wed Dec 12 18:13: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 88E7613178BE for ; Wed, 12 Dec 2018 18:13:25 +0000 (UTC) (envelope-from oliver@fromme.com) Received: from nox.thiemo.net (nox.thiemo.net [IPv6:2a01:4f8:110:1345::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nox.thiemo.net", Issuer "thiemo.net CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 14FEC70D19 for ; Wed, 12 Dec 2018 18:13:24 +0000 (UTC) (envelope-from oliver@fromme.com) Received: from nox.thiemo.net (localhost [127.0.0.1]) by nox.thiemo.net (8.15.2/8.15.2) with ESMTPS id wBCIDL9t047123 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Dec 2018 19:13:21 +0100 (CET) (envelope-from olli@nox.thiemo.net) X-Clacks-Overhead: GNU Terry Pratchett Received: (from olli@localhost) by nox.thiemo.net (8.15.2/8.15.2/Submit) id wBCIDLHa047117; Wed, 12 Dec 2018 19:13:21 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201812121813.wBCIDLHa047117@nox.thiemo.net> Subject: Re: Running Tor service in the jail environment To: freebsd-hackers@freebsd.org, atypical@autisticstory.net (Hubert Hauser) Date: Wed, 12 Dec 2018 19:13:21 +0100 (CET) In-Reply-To: <65a5540f-2f1c-0470-b650-cf9fd696ea7a@autisticstory.net> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (nox.thiemo.net [127.0.0.1]); Wed, 12 Dec 2018 19:13:22 +0100 (CET) X-Rspamd-Queue-Id: 14FEC70D19 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-4.95 / 15.00]; NEURAL_HAM_SHORT(-0.95)[-0.945,0]; REPLY(-4.00)[] X-Mailman-Approved-At: Wed, 12 Dec 2018 20:36:59 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 18:13:25 -0000 Hubert Hauser wrote: > It sounds like a good idea but weren't a better solution use an > open-hardware device acting as Tor router with installed OpenBSD > or HardenedBSD? Personally I trust FreeBSD more than the alternatives. But that's just me. ;-) > Why wouldn't you use for it jail environment? I want to place > Tor in the jail environment because I want to prevent system > being compromised in case compromising Tor service. I think it would be better to put the Tor service inside a virtual machine, for example VirtualBox or FreeBSD's own technology called bhyve. It has two advantages: First, the separation is somewhat "stricter" and more extensive than jails (for example, jails still share the same kernel, but VMs do not). Second, it is easier to create a setup suitable for networking with Tor. It might be possible with a jail, too, but I think that would be more difficult and error-prone. And you *do* want to avoid errors when you're going to set up a Tor service. Disclaimer: I've never set up a Tor service myself. Best regards Olli -- Oliver Fromme, München -- FreeBSD + DragonFly BSD ``We are all but compressed light'' - Albert Einstein From owner-freebsd-hackers@freebsd.org Thu Dec 13 05:11: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 EE2831339093 for ; Thu, 13 Dec 2018 05:11:36 +0000 (UTC) (envelope-from andrew@ziglang.org) Received: from mail.ziglang.org (mail.ziglang.org [108.61.23.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.ziglang.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D8786DB83 for ; Thu, 13 Dec 2018 05:11:31 +0000 (UTC) (envelope-from andrew@ziglang.org) To: freebsd-hackers@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ziglang.org; s=mail; t=1544677884; bh=kVPTHPmVhDfhewR1VzgUG/M1EXfOTjr7cakFpsHvHoI=; h=To:From:Subject:Date; b=XXuYpRKn+u9NVWaCXBMB59Xu9IBqC0WEFj8zCPi1Weui5vQvUY4iQv1Wo21UN4/5/ JLxCavDz0ofVCGI/H/QNLcD/nfadnTbCgtb6ygnojNpmylJMEPAPlPGimtLvO6VBoA xGH2grOSp2V+WmqQTliNktEFaoE9w9nVFNWimV3I= From: Andrew Kelley Subject: raise() implementation in freebsd libc vs musl libc Openpgp: preference=signencrypt Autocrypt: addr=andrew@ziglang.org; prefer-encrypt=mutual; keydata= mQINBFv8SrUBEADCku6WktTc1g+iyE9ZCtMv4kWqSHyQxFaEV8V5J2EAkjAzgr6wNLmHGmNm Xm8EzCWnwn/KfHJCeXTcgma/FtIF7hJfWB0xktA7WENUVc3qtT0cY9z39jh6J3TW3m9hcN7s zSyEqGvPMVCvd5pERZXfof9OaRqtNak3GBOcklHYrVJ0KCtAquR0t9NYrdOQikmBy4c9GaDs q/6H39LPuuj/vm7M+MHrw5dlKh+HPeUP9jMbFoXUohz97RSy8T2lUQDQx1EisAJNvdpU3mzA lWy2pEH+pKCBs5L0vPV/tvH1J5Pd489s7VcdM9AolIuHvV0qCDAG7fcWujV5R5w48vznvfi6 R3DN8O2iVrYdOWn2Bm60HdGmXxGQswb6/MfThpFzQUNQpvnXxdbt2vefUTmM4suid6ki/jLf siY1rqcNdEcriYFxJ6ma4SvZOB7OB2DG9bjWSItDIa2HqW37o//FYoFHJO0L+v5qjemYx5Qr pL2wCpnYUgJEII5UoagGwr0igtnjyT4fw5Xt7en3ukMoBRxrn8HoMXE4oh28tYfJfOABVrOt wpD7UpsWK0rmSFZDPa8yLRgqfS6ac2AmR0LcbK+3EYmFcCErh4IdY6Q5T0EYBnijwFqoFuRv cnQFJ6Q3oUTKOqB8OGg0v2E26qQZtkRHjmccPwNg9wftvrgjwQARAQABtCJBbmRyZXcgS2Vs bGV5IDxhbmRyZXdAemlnbGFuZy5vcmc+iQJOBBMBCAA4FiEEl8v20Nl/A6duouJgfF9Uj3KF AakFAlv8SrUCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQfF9Uj3KFAanVlg//VWPd qLcWx6mVWnSlpkXpGxp/V+zZaZlOuvDRMMk53V6zUpXrBDXDRiihx5Gwn3n0Ma9KBP7mcr35 2iNdurbFqtU494NG17lPCSyHf4ot/ohkvqYedoC3u+mRm0FRL4rjXkS7OH8U9UuolyIbYNPr 3B9X+F74uV1C+NH+AaHydhVwlEKeY82k1ingK8dojiCTyueErdp3/0pM5B4S86uSDZmXVqdp mCMXhicp0ZxaPWyDQYy1Ds+34GB5Nzq2cT/J6+aNpQ2IBDMSRKSWh/nymiwBcQcWNzg28LFi 34T9bf33lvVFordLEk45ygNDBNFa3/VH6ascKqtZ1LaS6JaCPWR/sYr+8l3JV7qvkINLDdA+ sUEtMpT97uPBcUjpHRqWlMc4esBSqN23sl9uguip6dmEiLiUdPtDisjiNb0M4fZTCWOF99ns NY0J7Cr/88iggtPaxyoEknTJMAdNnuz/QheIHSibvTT36r/+KIObzsCroxCqXCfKDoNhPBSg Qyrf7fYFVeGKr4/HJiONejRjAFw1/WqBzShOALiXhiZHJVeWk6PCk9ow2wGmlpji+U2MCaJb /bvrIJbFjuOK/N1U/zLDLQ5fsfCWcuf0QtPD/qBSlWMBDSPAjvo/Oq5lhXgvbiN3Q5PGt6RE Dw0C2BgF1MedBr484N12A+LQavdA9SS5Ag0EW/xKtQEQAN+OKUfbpeU82h38RYkdkUzL/Ppt wjEmZ5Gubfho0CyydrMNyY92LbRFwPSGB8sVwFhpNQprHoipdqqBDaUB/+yiztKr6W+HSoDj RyTFBfiTZhpKgqPzTh8ZE2tDsmaT00Fp/zIHVyuCxupPvDqytMzA+Gw+si9hTDDLIl3WYFhJ i9QN6hXLstDArExIkOzWF8H9CzP+gTizhZDDchrdTakKZHR0n52/FxAsVLfYC0gEt6h5dL+7 pZZaR3g+Wv9mQEm97z9stPiI/KfKX9SkRMgZ5KtoT+RO53ujpuzNGejYP5Vb2gw9wRa6oLIQ f0Lqqem7acaHwoBITMihn/2H9MaLl77iGTZVYNUTRF89/X5cP5Zy76gnV+m/oNHyXSaSMZV+ fQa8wTTAKhJAdy6FrhbpzfwDEZXyfpQidk5OgnQjGtXmN2fO5CXdFdmbXV9BXdtQcblC1DpJ ihBqv868+ffDPuAdZ+TWnsMwLLbcAMtSnTwR1LO8UnnRCBGmuffhSiKB4ZHQvX1jg5pO+AZu Flr+/sb3AKnXUaiBi6m4Cr9B+NfS+Tm3vPsjUvCctOD8DVucpkNOqSXBP9KWWcJ26yCIxeQN 9Fn6R0ryTYPVvshg7aHKbh8lZyTES1VQknWPCoL0Kfy9UH6Mp+GOVhQNbl/0/cXC/4ZasRep ArGUx/3BABEBAAGJAjYEGAEIACAWIQSXy/bQ2X8Dp26i4mB8X1SPcoUBqQUCW/xKtQIbDAAK CRB8X1SPcoUBqamXD/0auson+G862fAAqd0I2+cXis2AKpTqUTiNYiExsR6Zfh3UpCaJrElf lWU7xmjIoZKlZ3m4amAvSfdJ1i3qn1TkKn1uZ7K8GSQKjMebv/OkMUdOxAwvqmxvYE/buQr5 R5Y+jdOhGSih3DJh1toR5rlWbkagPzIFlEHCJzpG2SagZ+I39DQwxsme5pdz1zxFsODs0z/a rFdh8yRTtJXRzDGbS5kAh5/9ApUGpSbPZ5chBKmxmVVCmThlkNuwAzeiiM9Qum6Kzx54ZyXg KWw2GMZjTDjL0jQWZuGz4hySqDRO29nWo8D3t+DK82NNPjzBYMve7qeLn/4+WaBfRobSUplh 4vyVJdzEf1wK0pE8HR4Dfild1cmYDSklsAa6lFYelKnonQFucIZBVSdhyEWKwqYcDMOBdlL3 yf1P0AEq/XzxnqEUDx7kmc+JYpsEeFdcrAvcW/rtDLF+peugFPnehS14Ji+K4m3WWIM1OsdF R1y/UTNaYvfPiBs9hIVNWx9jX4GiPFYrYXRhIuKkvD9lSzp2GzaUriCZ2sgT42OuCE3crCRV LeDLemTLHmFjZqIZ0c1rG1HAbFw3pi1OdpPOOvDdrjCJszub9gQJdq4jG73LsHj3N3cx86m3 7A2Lmr7CVXzwFaNDB4z6Qvz6vD6Rc0BpuVCC+vCFipdCD3PPBOwHbQ== Message-ID: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> Date: Thu, 13 Dec 2018 00:11:21 -0500 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XIgApqZuOrt2zj5has1qHEWEWoc3PXhgM" X-Rspamd-Queue-Id: 6D8786DB83 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ziglang.org header.s=mail header.b=XXuYpRKn; spf=pass (mx1.freebsd.org: domain of andrew@ziglang.org designates 108.61.23.47 as permitted sender) smtp.mailfrom=andrew@ziglang.org X-Spamd-Result: default: False [-4.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.982,0]; R_DKIM_ALLOW(-0.20)[ziglang.org:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:108.61.23.47]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[ziglang.org]; DKIM_TRACE(0.00)[ziglang.org:+]; MX_GOOD(-0.01)[mail.ziglang.org]; NEURAL_HAM_SHORT(-0.81)[-0.814,0]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; IP_SCORE(-0.15)[asn: 20473(-0.67), country: US(-0.09)]; ASN(0.00)[asn:20473, ipnet:108.61.0.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 05:11:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XIgApqZuOrt2zj5has1qHEWEWoc3PXhgM Content-Type: multipart/mixed; boundary="yKqsLoVNDuOgjEM2fX4ndnu9mScsO9dee"; protected-headers="v1" From: Andrew Kelley To: freebsd-hackers@freebsd.org Message-ID: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> Subject: raise() implementation in freebsd libc vs musl libc --yKqsLoVNDuOgjEM2fX4ndnu9mScsO9dee Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Howdy, I noticed that musl-libc blocks signals in raise() to prevent a race condition, but freebsd libc does not. is there a reason it's necessary on linux and not freebsd? musl int raise(int sig) { sigset_t set; __block_app_sigs(&set); int ret =3D syscall(SYS_tkill, __pthread_self()->tid, sig); __restore_sigs(&set); return ret; } freebsd int __raise(int s) { long id; if (__sys_thr_self(&id) =3D=3D -1) return (-1); return (__sys_thr_kill(id, s)); } Regards, Andrew --yKqsLoVNDuOgjEM2fX4ndnu9mScsO9dee-- --XIgApqZuOrt2zj5has1qHEWEWoc3PXhgM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEl8v20Nl/A6duouJgfF9Uj3KFAakFAlwR6fkACgkQfF9Uj3KF AanXAhAAubSBV5ekwOjyRSXn9J1aeUx358Zes3vq7auuzyEgmjpI2tJ5o1du1QLM WRHHPvSpFzkGa3+P3or7Fs/ZZ+RzhJ4LEZwB9vRRFb8uzOQ0MztdQrwk4F+M0bTz VqLI8hF71FoXUZerjtxJo0tMGrHf3Q666ONp9L9/jwVP6KDsI2drBkoN3jie+Psz 1xAQ7nCpd+Zva4UXLkj7xYC3QfTG77yoEdBhwTH4yScCk5ppoh8ggT7OJ5fenNfq Tjxafc84DXsjtu9xIaV61M4EQaqdiLr5MroduHXX9XIC/qCdGV9PtY8+HTGJZgxP d7DdMSm+jVaWivjubnzgPeXn/e4GysAAGUVwPsFwchPSUbMsEQWfUr2In+NwPuRU +AKK9VzupX8l5G55NSpvmG/4tB2qz9h9JxHO2sOJCm2xLSWDQbKuUL8elH3E2ySj M7B8qRzITmfnviNKcgmi/8CrrF22YlJV2Xncz23ejD5ss2gMFBOaSgckuSTN/YNH d9RVA5sMZLn0wzk5Cbj3y4q3PZ8hsYZclnZs4epOif/cNOeqkvAFW0gaREdhAjXU NUxV/anCpX4YYv7igg4CWUMvGb3P1dGAsnfoJ4i8ei5b87qkfOcsjKtuuzXJw/sP kbiSykTtJQu6DR/FJhfFXjj/auFnqaL6YyTzlVmd4xaylni99Dg= =7NxN -----END PGP SIGNATURE----- --XIgApqZuOrt2zj5has1qHEWEWoc3PXhgM-- From owner-freebsd-hackers@freebsd.org Thu Dec 13 06: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 AE553130A77F for ; Thu, 13 Dec 2018 06:01:15 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f194.google.com (mail-it1-f194.google.com [209.85.166.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B871D6F4C8 for ; Thu, 13 Dec 2018 06:01:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f194.google.com with SMTP id a6so2138648itl.4 for ; Wed, 12 Dec 2018 22:01:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Q4QSXzafRS0EavJN6NDA4nZFBkss6/74FekA/NzOsAQ=; b=tQnpDBSVsK7NmTudy+A6UF0EhzGUSoqy0Sxv5XE36oq7pAXwi22/NXKiLpvRTLqssN 5JMkp0pNHn9wus9CRX6TOWoPzo+L1LwFrx+cFwPDRATr6Evhoq2gXyV84+sQp/nbPY2T rMdZxrja+JELaEaZTzwI9V5bKRR4lLJ5EG9c4uMcoPW3qOfdRv0KurQWGIYVDeMzwc0T jZGMHEMCqsxu2lq5pQLqei+FP+I83uCdMRIeMzj+svYQ31J4Qfbe3Lnc+D1DvHQbXgV1 MOfEN8uGWvYMp8UNOS5HgqKcYkMje4AuJFqtiKxM6LN1YqJwwRT52tZmgTeanQ7Vf1Vo P9bg== X-Gm-Message-State: AA+aEWbXrqWhsSssLQYOB5Fmtq346VdkpKyvAZX9YMRbKr7Vw/QD54WZ 0aeL7TiHRm/W2H4b1dlcy+44MhJ5 X-Google-Smtp-Source: AFSGD/XRE1+TLYni9K2OMjSyhB+thGSbYNAhzblas3HFJH5ckJz8sR6QvqTBblhuB9zfvyEJgUPSIQ== X-Received: by 2002:a05:660c:fd2:: with SMTP id m18mr8647172itn.1.1544680868005; Wed, 12 Dec 2018 22:01:08 -0800 (PST) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id v202sm818744ita.13.2018.12.12.22.01.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Dec 2018 22:01:07 -0800 (PST) Received: by mail-it1-f171.google.com with SMTP id z7so2091273iti.0 for ; Wed, 12 Dec 2018 22:01:07 -0800 (PST) X-Received: by 2002:a24:5411:: with SMTP id t17mr8175337ita.32.1544680867147; Wed, 12 Dec 2018 22:01:07 -0800 (PST) MIME-Version: 1.0 References: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> In-Reply-To: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 12 Dec 2018 22:00:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: raise() implementation in freebsd libc vs musl libc To: andrew@ziglang.org Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B871D6F4C8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.194 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-2.95 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; IP_SCORE(-0.99)[ipnet: 209.85.128.0/17(-3.55), asn: 15169(-1.30), country: US(-0.09)]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[194.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.166.85.209.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 06:01:15 -0000 Hi Andrew, The musl signal blocking dates to this commit: https://git.musl-libc.org/cgit/musl/commit/?id=0bed7e0acfd34e3fb63ca0e4d99b7592571355a9 The concern raised in that commit was that raise(3) could theoretically be interrupted by a concurrently running signal handler which invokes fork() (also sighandler-safe), resulting in inconsistent/stale values from gettid(2)/getpid(2) on Linux (at the time). On both systems, gettid(2) / thr_self(2) returns a unique thread identifier that cannot be reused until the thread it identifies has exited. So, I don't know. I guess if fork happens between thr_self() and thr_kill(), the parent process may have already exited and had its tid recycled by the time the child process invokes thr_kill(). OTOH, that seems like a pretty byzantine / broken application? I'm not sure it's libc's job to prevent applications from shooting themselves in the foot. Forking in a signal handler is already somewhat dicey, and especially so if the child does not immediately exec() or _exit(2). Anyway, that's just my guess. I am not a libthr expert on either BSD nor Linux, so take this with a big grain of salt. Signals were a mistake ;-). Best, Conrad P.S., Zig looks quite promising, I am excited to see where it goes. On Wed, Dec 12, 2018 at 9:12 PM Andrew Kelley wrote: > > Howdy, > > I noticed that musl-libc blocks signals in raise() to prevent a race > condition, but freebsd libc does not. is there a reason it's necessary > on linux and not freebsd? > > musl > int raise(int sig) > { > sigset_t set; > __block_app_sigs(&set); > int ret = syscall(SYS_tkill, __pthread_self()->tid, sig); > __restore_sigs(&set); > return ret; > } > > freebsd > int > __raise(int s) > { > long id; > > if (__sys_thr_self(&id) == -1) > return (-1); > return (__sys_thr_kill(id, s)); > } > > Regards, > Andrew > From owner-freebsd-hackers@freebsd.org Thu Dec 13 06:05: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 819D0130AB12 for ; Thu, 13 Dec 2018 06:05:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BCF06F941 for ; Thu, 13 Dec 2018 06:05:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id wBD654Mv043728 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 12 Dec 2018 22:05:04 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id wBD654lE043727; Wed, 12 Dec 2018 22:05:04 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Dec 2018 22:05:04 -0800 From: Steve Kargl To: Andrew Kelley Cc: freebsd-hackers@freebsd.org Subject: Re: raise() implementation in freebsd libc vs musl libc Message-ID: <20181213060504.GA43628@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 7BCF06F941 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.55 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.76)[0.764,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; NEURAL_SPAM_MEDIUM(0.92)[0.915,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.18)[ip: (0.80), ipnet: 128.95.0.0/16(0.09), asn: 73(0.11), country: US(-0.09)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 06:05:07 -0000 On Thu, Dec 13, 2018 at 12:11:21AM -0500, Andrew Kelley wrote: > > I noticed that musl-libc blocks signals in raise() to prevent a race > condition, but freebsd libc does not. is there a reason it's necessary > on linux and not freebsd? > > if (__sys_thr_self(&id) == -1) > return (-1); > return (__sys_thr_kill(id, s)); The answer probably lies in the meaining of '_thr_' in the above function names. See src/sys/kern/kern_thr.c. -- Steve From owner-freebsd-hackers@freebsd.org Thu Dec 13 10:04: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 13D5D1314FA0; Thu, 13 Dec 2018 10:04:16 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 626BB80444; Thu, 13 Dec 2018 10:04:15 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-wr1-x42b.google.com with SMTP id z5so1319328wrt.11; Thu, 13 Dec 2018 02:04:15 -0800 (PST) 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=LxHKRq0TG85/hYg4YVoEoF6YTc33Usep0g1fYHrUsHc=; b=FnSPY8XDJKlzk3RdxrJVRgLwzy0iX8YXHSO27BT/1QMeLcTEgHqeGFUWF5KtKxbnhq A/F7PX/5feakv1kGbbnkJEyEt+tc8rO+fnp+5MYcnZ2cBt27Hka5JPgjPtwdU7kggWTh 4u5dRSzvK7khXj9BL7pC6GMspheEpl7zFFZ2ieXhCk0rX6Yl3X7fBQ9H82fOrw0fI8tV OFqvFi6jTLBdv5lEHR3UczQejkIjoUpeJrdbZUofDA6Kgs0JIbRa+6FbOr0CiCR7d+0Q 57moXO5OXxjth279AGmJozRc5776ZOas1sSw10M6Bp71ubzr+bzuPbsn8B7kivNVrkLg DKBw== 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=LxHKRq0TG85/hYg4YVoEoF6YTc33Usep0g1fYHrUsHc=; b=nmtqULGyCrToSwO1471T8OPJswehlhNmGU6M7qzLU4OHdvBSeZJkw1Ui8KPxHNmpY6 AqKb8mcr2xyrqlIwHJzhB/bF5RJVGJYHQ1iEKj/PHiSeOeEJbGj9dbTwTP6OU4rHXwQ5 HxX55v6xl8ouhFEYLU0HPSOMh3AWn5gnGjE8CmdZVl/JPgFINT7fXINQNWgYsirp7d8g kKcD6cGQ4BNEh3NvXNUc6R2yRld8g+K7bHTQlIMedg1rx0XbwLEVn6irUGQaavslouud qForGnZDBpgzJnYb8UqWYWAWvSZTQq+EzMlPLayBuYTC/G0PmOCPmFnXJmIe2MtZyoOU GklA== X-Gm-Message-State: AA+aEWZe0IXoD4bH8kTRATzCdStbPeR+9ep1F/NeRwEUHRNtjEHKAHpC mf6SH+RtOCnGf05HrwQIgOuYp/pjC3DydEWC5ldnaA== X-Google-Smtp-Source: AFSGD/UO6W0P9fuPYyf4jjJMVgUOKp55RCoK4VjxKvbA+mbcvWkUxVhdnqBAmI5VJ/v+++mrybzHRa/JFwHE6O9vGIA= X-Received: by 2002:adf:fd03:: with SMTP id e3mr19654008wrr.280.1544695453984; Thu, 13 Dec 2018 02:04:13 -0800 (PST) MIME-Version: 1.0 From: Rajesh Kumar Date: Thu, 13 Dec 2018 15:34:02 +0530 Message-ID: Subject: How to use the DMA Engine in FreeBSD? To: freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 626BB80444 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=FnSPY8XD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rajfbsd@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=rajfbsd@gmail.com X-Spamd-Result: default: False [-2.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.972,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[b.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.85)[-0.847,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-0.58)[ipnet: 2a00:1450::/32(-1.49), asn: 15169(-1.30), country: US(-0.09)]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 10:04:16 -0000 Hi, Is there any good documentation available to understand the existing support, API's and how-to use the DMA Engine in FreeBSD? I am trying to write a test driver which will use DMA Engine to do the data transfer (rather than plain memcpy which involves cpu). Can anyone point to any driver implementation which has similar functions implemented? I see references to SYS_RES_DRQ to allocate DMA channels and play around. But that seems to be specific to ISA. Can it be used for PCI drivers as well? Thanks, Rajesh. From owner-freebsd-hackers@freebsd.org Thu Dec 13 10:41: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 84DED1316561; Thu, 13 Dec 2018 10:41:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CA0A81D64; Thu, 13 Dec 2018 10:41:19 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [178.17.145.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B060C26019D; Thu, 13 Dec 2018 11:41:10 +0100 (CET) Subject: Re: How to use the DMA Engine in FreeBSD? To: Rajesh Kumar , freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org References: From: Hans Petter Selasky Message-ID: <434ed3ba-6613-b5eb-5a68-f69936bcda21@selasky.org> Date: Thu, 13 Dec 2018 11:39:17 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 9CA0A81D64 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-4.17 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[mail.turbocat.net]; NEURAL_HAM_SHORT(-0.96)[-0.956,0]; IP_SCORE(-2.91)[ip: (-8.71), ipnet: 2a01:4f8::/29(-3.30), asn: 24940(-2.52), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 10:41:20 -0000 On 12/13/18 11:04 AM, Rajesh Kumar wrote: > Hi, > > Is there any good documentation available to understand the existing > support, API's and how-to use the DMA Engine in FreeBSD? > > I am trying to write a test driver which will use DMA Engine to do the data > transfer (rather than plain memcpy which involves cpu). Can anyone point > to any driver implementation which has similar functions implemented? I > see references to SYS_RES_DRQ to allocate DMA channels and play around. But > that seems to be specific to ISA. Can it be used for PCI drivers as well? Hi, What you are looking for is called PCI busmaster. --HPS From owner-freebsd-hackers@freebsd.org Thu Dec 13 11:16:32 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 B89551317937; Thu, 13 Dec 2018 11:16:32 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01ED983366; Thu, 13 Dec 2018 11:16:32 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-oi1-x22d.google.com with SMTP id x202so1284095oif.13; Thu, 13 Dec 2018 03:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=8qW5LlRMkcuhT9loX/aiMkvfpazq/y7Z/PX2nBuHS7g=; b=JMWQs9XvG2qBL2bAPdxL6Wv2L0y7sXt7Ecg+7LZtDLXwZQ5B2ViPJmnMf69gTQVeYO PrPHdNH7BKaVHBZOboDpXymmSVTgNbCElezVnJbunY/UkKto1bkC0amFe4oSwARKmbXz HE7uxjKAQqcWFmc9oqhL+E7i7hqHyndILoLjBVbXniI0wn0HHj1bSK4zdJadwGT259wM c4qXIh6dzI0zmuJvzQ50HK0I5AB9YqYBEL9g610Bu3GUFm9wnDRGvT/D5CUgy5o2kC5P k4jS1GbvlnOp+EnRsA/DIo+Yg44vS1eEG6yItrRbwLi6g6cM5a47RcEITRAXdNZMfyGJ OYOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8qW5LlRMkcuhT9loX/aiMkvfpazq/y7Z/PX2nBuHS7g=; b=U6HzK0Jy+ixenQDnm6+hXhGN8h0/aObK6lRW6pLHt8WpvAooZG/d4KcpKpedZFuTfz 8NW5hPalJ6umfq/jhKEGbCW4FrySK/9Mt4z5zuzaOJP+sX7g1xQ9r3ibFNmEtaakNg0Z r1PvXl9BnfLE1V+ofZvJ+7jKv2J0eeOz4dSo0fndO/KPaoyMeIae/KLvGBsx4I+ejDn9 3IU6x1z7zr38ItaJDaINtg9Xty2IB1tp/PpJ2pqlJoEN+uZAWT2WBB1uHygO0loPOaZr JdHTJSaujOhavKpQtaV+A1vOpMX/WT5sXrpJwdbdtvRp8DwGsee7IwiGMzJdsa38tiKk rmMA== X-Gm-Message-State: AA+aEWYP3VO6wu3dWk6B9dtWp2YzQwmZffiVulwwBVHDOEFRVqAZDusz dHs7VdAnFEzE9mWFns5EalP+vMIa X-Google-Smtp-Source: AFSGD/VDPu6q0wJHAOUDne2nbVnrbT+aCJHYK5+vcomoC0UWafTTkH3iWlBNsanmLutaWTmMUylBQg== X-Received: by 2002:aca:b104:: with SMTP id a4mr2471872oif.133.1544699790824; Thu, 13 Dec 2018 03:16:30 -0800 (PST) Received: from [192.168.1.33] ([81.174.250.12]) by smtp.gmail.com with ESMTPSA id j23sm679877oih.22.2018.12.13.03.16.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Dec 2018 03:16:30 -0800 (PST) Subject: Re: How to use the DMA Engine in FreeBSD? To: Rajesh Kumar , freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org References: From: Johannes Lundberg Message-ID: <90ce7684-6a8f-c398-5a46-a7f6b03015e8@gmail.com> Date: Thu, 13 Dec 2018 11:16:27 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 01ED983366 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JMWQs9Xv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johalun0@gmail.com designates 2607:f8b0:4864:20::22d as permitted sender) smtp.mailfrom=johalun0@gmail.com X-Spamd-Result: default: False [-2.55 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-0.95)[-0.949,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-0.59)[ipnet: 2607:f8b0::/32(-1.58), asn: 15169(-1.30), country: US(-0.09)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 11:16:33 -0000 On 12/13/18 10:04 AM, Rajesh Kumar wrote: > Hi, > > Is there any good documentation available to understand the existing > support, API's and how-to use the DMA Engine in FreeBSD? > > I am trying to write a test driver which will use DMA Engine to do the data > transfer (rather than plain memcpy which involves cpu). Can anyone point > to any driver implementation which has similar functions implemented? I > see references to SYS_RES_DRQ to allocate DMA channels and play around. But > that seems to be specific to ISA. Can it be used for PCI drivers as well? Hi The book "FreeBSD Device Drivers" by Joseph Kong has an example. Not sure it matches exactly what you are looking for but it might help more than the FreeBSD source code which tends to lack documentation. > Thanks, > Rajesh. > _______________________________________________ > 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 Thu Dec 13 15:53: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 ECE341329A0B for ; Thu, 13 Dec 2018 15:53:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0097C8D997 for ; Thu, 13 Dec 2018 15:53:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id r14so2672370qtp.1 for ; Thu, 13 Dec 2018 07:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fzccQgKTpAFs4ytrOSOCXM6BAxqxFNZ9e4SObqusW7c=; b=yHR7qIMAKmY7D60/gyWTftxnB3QktcYcUf8JMLWBgoWVEo6LzFoH1T5Rl7UKrCSbs9 L/Wr9mRONca/vdhWZxwzjSX5Isgq2MmwrakP+dgZgmb4UVSQOhDRSSSCOTY9JzxZROKo 11FHHg/I4ZPseRyX9loErwbmAF8FiCAbimhibjF4opzXe+61iWd58FDf1xk9CMor7efU 5m4xC/OknDF/bQr4t33AMx6DxPY7RzPLk2Ak/EQvCe6GQ9nBM1mcoHte1zR9+FaAQRdz 5j6HTUIZ0Eszm/JFZ52reVhUOo2cwn//0w8E0rPU7Cky/wooQI8tFKLipHlMfWZJVqpX B7iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fzccQgKTpAFs4ytrOSOCXM6BAxqxFNZ9e4SObqusW7c=; b=avQgck3rV2UaEK4iFIBWfpE5FeqNRpcFvSaVzp5BD6tXfwUAUDHtiQm0h78mRCVt07 UOEIMHlxjZ4t7xZk9b6GlCccbyJcIcFNRW9YfznvXEf2KHQJcXcMk+JecwISsdPuwfTM BySMIpEAl1ieGsxyUGo4qyPepko6JWX5uXZ8j/QyS0UZwPn2XdN+amFVWiBT3/18KLOm kJF26OKItteDxkg3okD2w+arbHK0vXlOoSbGR9tB8+4benFdWrPgu9NzKlNIaTiwtlmB WD/If3NVd6BihqXGMSXoYLs0+K80rtAAr7Y7kO0cLow5HphN8/nJtCNF/Ag/RvC1iZk2 UuqA== X-Gm-Message-State: AA+aEWaOLBfx9VPz9fRQZz8V46IZRgcAKXyueRz2fpQWeK8fai7t+yHi lphqIn1xERhzGf7v8u/Muf5Wnrat2YA7VhO0mHOCuWPy X-Google-Smtp-Source: AFSGD/UZ/ZHRQ+Vx8fR93m4D6LW7NJpTFxgTfJzv6+bk3qZ6+SeW0iLrMX/UYA5VRHiyEEj4wN+9Y2ma25WvHh3Nb60= X-Received: by 2002:a0c:f143:: with SMTP id y3mr23963534qvl.21.1544716419308; Thu, 13 Dec 2018 07:53:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 13 Dec 2018 08:53:15 -0700 Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: Rajesh Kumar Cc: freebsd-drivers@freebsd.org, FreeBSD Hackers X-Rspamd-Queue-Id: 0097C8D997 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=yHR7qIMA X-Spamd-Result: default: False [3.10 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.45)[ip: (5.22), ipnet: 2607:f8b0::/32(-1.58), asn: 15169(-1.30), country: US(-0.09)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_MEDIUM(0.99)[0.991,0]; NEURAL_SPAM_SHORT(0.67)[0.670,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 15:53:41 -0000 On Thu, Dec 13, 2018, 3:04 AM Rajesh Kumar Hi, > > Is there any good documentation available to understand the existing > support, API's and how-to use the DMA Engine in FreeBSD? > Usually you just use pci busmastering and it just works. I am trying to write a test driver which will use DMA Engine to do the data > transfer (rather than plain memcpy which involves cpu). Can anyone point > to any driver implementation which has similar functions implemented? I > see references to SYS_RES_DRQ to allocate DMA channels and play around. But > that seems to be specific to ISA. Can it be used for PCI drivers as well? > No. ISA DMA is only for really old hardware without it's own DMA engine. Look at the busdma api/man page. Warner > Thanks, > Rajesh. > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Dec 13 20:11:52 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 4EB7A1332EE9 for ; Thu, 13 Dec 2018 20:11:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79924702E7; Thu, 13 Dec 2018 20:11:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wBDKBh1M027920 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Dec 2018 22:11:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wBDKBh1M027920 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wBDKBgIL027919; Thu, 13 Dec 2018 22:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Dec 2018 22:11:42 +0200 From: Konstantin Belousov To: Conrad Meyer Cc: andrew@ziglang.org, "freebsd-hackers@freebsd.org" Subject: Re: raise() implementation in freebsd libc vs musl libc Message-ID: <20181213201142.GP60291@kib.kiev.ua> References: <70c7214e-3619-115d-abca-09853a1729a6@ziglang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 20:11:52 -0000 On Wed, Dec 12, 2018 at 10:00:56PM -0800, Conrad Meyer wrote: > Hi Andrew, > > The musl signal blocking dates to this commit: > > https://git.musl-libc.org/cgit/musl/commit/?id=0bed7e0acfd34e3fb63ca0e4d99b7592571355a9 > > The concern raised in that commit was that raise(3) could > theoretically be interrupted by a concurrently running signal handler > which invokes fork() (also sighandler-safe), resulting in > inconsistent/stale values from gettid(2)/getpid(2) on Linux (at the > time). But even then, for the child to signal wrong thread, it must return from the signal frame to the interrupted frame executing raise(). This would be really weird design. > > On both systems, gettid(2) / thr_self(2) returns a unique thread > identifier that cannot be reused until the thread it identifies has > exited. So, I don't know. I guess if fork happens between thr_self() > and thr_kill(), the parent process may have already exited and had its > tid recycled by the time the child process invokes thr_kill(). The difference between Linux and FreeBSD there, as I see it, is that thr_kill() only allows to send signals to the threads in the current process. So when the forked child sends a signal to the thread identified by the parent' thread id, nothing happens except an error code returned. > > OTOH, that seems like a pretty byzantine / broken application? I'm > not sure it's libc's job to prevent applications from shooting > themselves in the foot. Forking in a signal handler is already > somewhat dicey, and especially so if the child does not immediately > exec() or _exit(2). Forking in a signal handler is fine, assuming that the signal handler only uses async-signal safe functions, regardless of exec/_exit. Problem there is that atfork handlers must only use async-safe functions, which means that the author of the signal handler must be aware of the whole application code, including all libraries. > > Anyway, that's just my guess. I am not a libthr expert on either BSD > nor Linux, so take this with a big grain of salt. Signals were a > mistake ;-). > > Best, > Conrad > > P.S., Zig looks quite promising, I am excited to see where it goes. > > > On Wed, Dec 12, 2018 at 9:12 PM Andrew Kelley wrote: > > > > Howdy, > > > > I noticed that musl-libc blocks signals in raise() to prevent a race > > condition, but freebsd libc does not. is there a reason it's necessary > > on linux and not freebsd? > > > > musl > > int raise(int sig) > > { > > sigset_t set; > > __block_app_sigs(&set); > > int ret = syscall(SYS_tkill, __pthread_self()->tid, sig); > > __restore_sigs(&set); > > return ret; > > } > > > > freebsd > > int > > __raise(int s) > > { > > long id; > > > > if (__sys_thr_self(&id) == -1) > > return (-1); > > return (__sys_thr_kill(id, s)); > > } > > > > Regards, > > Andrew > > > _______________________________________________ > 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 Fri Dec 14 15:35: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 B0C6F1337E0C; Fri, 14 Dec 2018 15:35:19 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:11::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D3DA81FE3; Fri, 14 Dec 2018 15:35:19 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:10:702f:25e8:7b4f:59c6]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id wBEFZ9B2072892; Fri, 14 Dec 2018 10:35:16 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:10:702f:25e8:7b4f:59c6] claimed to be torb.pix.net Subject: Re: How to use the DMA Engine in FreeBSD? To: Warner Losh , Rajesh Kumar Cc: FreeBSD Hackers , freebsd-drivers@freebsd.org References: From: Kurt Lidl Message-ID: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> Date: Fri, 14 Dec 2018 10:35:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 15:35:19 -0000 On 12/13/18 10:53 AM, Warner Losh wrote: > On Thu, Dec 13, 2018, 3:04 AM Rajesh Kumar >> Hi, >> >> Is there any good documentation available to understand the existing >> support, API's and how-to use the DMA Engine in FreeBSD? >> > > > Usually you just use pci busmastering and it just works. > > I am trying to write a test driver which will use DMA Engine to do the data >> transfer (rather than plain memcpy which involves cpu). Can anyone point >> to any driver implementation which has similar functions implemented? I >> see references to SYS_RES_DRQ to allocate DMA channels and play around. But >> that seems to be specific to ISA. Can it be used for PCI drivers as well? >> > > No. ISA DMA is only for really old hardware without it's own DMA engine. > > Look at the busdma api/man page. For some Intel based server hardware, there is the "ioat" driver, which allows for user code to schedule DMA operations. See ioat(4) for details, including a pointer to the test program. -Kurt From owner-freebsd-hackers@freebsd.org Fri Dec 14 16:16: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 C984A133A823; Fri, 14 Dec 2018 16:16:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48CD384A2F; Fri, 14 Dec 2018 16:16:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f194.google.com with SMTP id v1-v6so5395173ljd.0; Fri, 14 Dec 2018 08:16:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jejr1c7PhunWb6ZkdwVBhQmtzlD9MaCe/Ck1w0V5Dwg=; b=jiSu97OWKztqzjVVqx7NwM9M6G8hknqWcJjta33V+gUqGWhwwpcagn3l+w50xDSE1Q 1YjKsVYTioKf7v+jfwHgpOTQMzjBXpTWlMAF0tc0Hn3vQeEFR+hP5TggJL9JrpKyW5/J wd7Beccgr5i1Lml2WgT949IcuMuAY+E5LliR1LPAmMALuv8dQjLGQIxlAvgjh3bJzNS5 43+yBhPcuATvUkm1UrGFuKQVcZvb2IldQI02fVIp3RtQbTIIHM9+GGkM1RcuOvbCxNJI IovRtpljcyLV8QqG5e9FSCU+rVVkh+h6Y2JdoXzVqwOWQu272VxjBl8l1VcgZ1f+g7AV bryA== X-Gm-Message-State: AA+aEWaj88PM60PNqBQQVbtEsqMffIQEjAWsJ0XMbA+aPHafXWUWzZ/D ySZQvrO8LFf4Qd6sTrY35O29UxqMPxT0oJBQ6B4= X-Google-Smtp-Source: AFSGD/WsMu2bPw9w1+XIV72/rjnbYssNNFytmXEiqxqw/uhw5rhUCOgaDuuPkibDlI+EMVgIoVaN/lUuVrjiCW3Bog4= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr2414937ljb.51.1544803769469; Fri, 14 Dec 2018 08:09:29 -0800 (PST) MIME-Version: 1.0 References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> In-Reply-To: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> From: Alan Somers Date: Fri, 14 Dec 2018 09:09:17 -0700 Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: Kurt Lidl Cc: Warner Losh , rajfbsd@gmail.com, "freebsd-hackers@freebsd.org" , freebsd-drivers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48CD384A2F X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; NEURAL_HAM_SHORT(-0.90)[-0.902,0]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 16:16:30 -0000 On Fri, Dec 14, 2018 at 8:36 AM Kurt Lidl wrote: > > On 12/13/18 10:53 AM, Warner Losh wrote: > > On Thu, Dec 13, 2018, 3:04 AM Rajesh Kumar > > >> Hi, > >> > >> Is there any good documentation available to understand the existing > >> support, API's and how-to use the DMA Engine in FreeBSD? > >> > > > > > > Usually you just use pci busmastering and it just works. > > > > I am trying to write a test driver which will use DMA Engine to do the data > >> transfer (rather than plain memcpy which involves cpu). Can anyone point > >> to any driver implementation which has similar functions implemented? I > >> see references to SYS_RES_DRQ to allocate DMA channels and play around. But > >> that seems to be specific to ISA. Can it be used for PCI drivers as well? > >> > > > > No. ISA DMA is only for really old hardware without it's own DMA engine. > > > > Look at the busdma api/man page. > > For some Intel based server hardware, there is the "ioat" driver, which > allows for user code to schedule DMA operations. See ioat(4) for > details, including a pointer to the test program. > > -Kurt ioat(4) looks cool. But the man page is vague on a few points. Do you know the answers to these questions? * What happened to ioatcontrol(8)? It's reference by the man page, but doesn't exist anywhere. * In what context are callbacks called? Are they called from a signal handler, or in a separate thread, or something else? * Why isn't ioat.h installed? * Are "interrupts" synonymous with callbacks? * Do you have a rough idea for about the minimum buffer size that makes sense to use with ioat? -Alan From owner-freebsd-hackers@freebsd.org Fri Dec 14 23:04: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 2007C132381D; Fri, 14 Dec 2018 23:04:03 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:11::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 737FC6F8F0; Fri, 14 Dec 2018 23:04:02 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:10:702f:25e8:7b4f:59c6]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id wBEN3pBB083640; Fri, 14 Dec 2018 18:03:58 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:10:702f:25e8:7b4f:59c6] claimed to be torb.pix.net Subject: Re: How to use the DMA Engine in FreeBSD? To: Alan Somers Cc: Warner Losh , rajfbsd@gmail.com, "freebsd-hackers@freebsd.org" , freebsd-drivers@freebsd.org References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> From: Kurt Lidl Message-ID: Date: Fri, 14 Dec 2018 18:03:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 23:04:03 -0000 On 12/14/18 11:09 AM, Alan Somers wrote: > On Fri, Dec 14, 2018 at 8:36 AM Kurt Lidl wrote: >> >> On 12/13/18 10:53 AM, Warner Losh wrote: >>> On Thu, Dec 13, 2018, 3:04 AM Rajesh Kumar >> >>>> Hi, >>>> >>>> Is there any good documentation available to understand the existing >>>> support, API's and how-to use the DMA Engine in FreeBSD? >>>> >>> >>> >>> Usually you just use pci busmastering and it just works. >>> >>> I am trying to write a test driver which will use DMA Engine to do the data >>>> transfer (rather than plain memcpy which involves cpu). Can anyone point >>>> to any driver implementation which has similar functions implemented? I >>>> see references to SYS_RES_DRQ to allocate DMA channels and play around. But >>>> that seems to be specific to ISA. Can it be used for PCI drivers as well? >>>> >>> >>> No. ISA DMA is only for really old hardware without it's own DMA engine. >>> >>> Look at the busdma api/man page. >> >> For some Intel based server hardware, there is the "ioat" driver, which >> allows for user code to schedule DMA operations. See ioat(4) for >> details, including a pointer to the test program. >> >> -Kurt > > ioat(4) looks cool. But the man page is vague on a few points. Do > you know the answers to these questions? > * What happened to ioatcontrol(8)? It's reference by the man page, > but doesn't exist anywhere. root@busybox: locate ioatcontrol /usr/src/tools/tools/ioat/ioatcontrol.8 /usr/src/tools/tools/ioat/ioatcontrol.c > * In what context are callbacks called? Are they called from a signal > handler, or in a separate thread, or something else? I don't know. > * Why isn't ioat.h installed? I don't know that either, but it is in the source tree: root@busybox: locate ioat.h /usr/src/sys/dev/ioat/ioat.h > * Are "interrupts" synonymous with callbacks? > * Do you have a rough idea for about the minimum buffer size that > makes sense to use with ioat? I don't know that either -- I was mostly just pointing out that the facility and driver existed for (some) Intel server hardware. Mostly I'm aware of this because I was surprised when a machine I using this summer started reporting this hardware, and I wasn't familiar with it. Good luck. -Kurt From owner-freebsd-hackers@freebsd.org Sat Dec 15 00:21: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 3F0261326116 for ; Sat, 15 Dec 2018 00:21:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA474724C7 for ; Sat, 15 Dec 2018 00:21:39 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id wBENuueh031892 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 15 Dec 2018 00:56:56 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id wBENuo9Y031889 for ; Sat, 15 Dec 2018 00:56:51 +0100 (CET) (envelope-from puchar-wojtek@puchar.net) Date: Sat, 15 Dec 2018 00:56:50 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: please help with virtualbox Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: DA474724C7 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [1.09 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.33)[0.331,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.59)[0.588,0]; MX_GOOD(-0.01)[puchar.net]; NEURAL_SPAM_LONG(0.47)[0.472,0]; RCVD_IN_DNSWL_NONE(0.00)[90.144.1.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(0.01)[country: PL(0.03)]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 00:21:41 -0000 i use virtualbox on my own laptop just to run windows 7 from time to time. No problems. But today i needed sound. I enabled sound in virtualbox as intel HD sound emulation. Windows automatically detect "new hardware". Everything seems fine. But anything i play from windows result in no errors and silence. Sound under FreeBSD works fine without problems after i've set dev.hdac.0.polling=1 From owner-freebsd-hackers@freebsd.org Sat Dec 15 00:59: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 9382A13278DB; Sat, 15 Dec 2018 00:59:56 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9366B73870; Sat, 15 Dec 2018 00:59:55 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f179.google.com with SMTP id c9so12298907itj.1; Fri, 14 Dec 2018 16:59:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=EU5UMKETp3I2V730UX34nZFrsQLTwDvGGqEmFD4No18=; b=nFyfrZSodB8TGGdP4cdVuI44Wax0iYG3DUe611GXw2Y3l5b/1Q72SMrM6vRU4o4TaZ cZLwlM+/Djb7WVYL44fRBC4mgQPByFON1jN+RIoHmVRdCyKdDqluMvZyjcsLUdWtJo6f tuYBdC5M4FPhl1ZEfeKTSlepUxU7d8S1AtKQm5qZd5J6TIDFCv3eOnObqu/6OVgn8481 6eoDFAzkDM1ufuOzwIQxTusYFwl2BHPod/HURYsx2IC1KgTR/lpPwaYF+jdEXAlwVr9a k06ribbhJ2tzp0x+R40kw2vX825zM6cAlXRApmU2yK2IuE9srSnoRiOWEW86TKj3rGNa UWKw== X-Gm-Message-State: AA+aEWbOOW/aqyXmoX+l7XgmKzY1rpK+Q4e0wyB916blsRCRHRpUyPSU 7aDyxzkMg0Chmo4M6jP9jSEaFfnS X-Google-Smtp-Source: AFSGD/XUX3GrM+fBKa+bw8roDrvBqNMlKlvrkvbC79tNWb9nI696Zz6ZOOvL5qEmnSirJqgx2V/auA== X-Received: by 2002:a24:4ac3:: with SMTP id k186mr4514863itb.76.1544835588913; Fri, 14 Dec 2018 16:59:48 -0800 (PST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id 196sm3419524itu.37.2018.12.14.16.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Dec 2018 16:59:48 -0800 (PST) Received: by mail-io1-f51.google.com with SMTP id o13so2406987iom.4; Fri, 14 Dec 2018 16:59:48 -0800 (PST) X-Received: by 2002:a6b:6111:: with SMTP id v17mr4620029iob.107.1544835588458; Fri, 14 Dec 2018 16:59:48 -0800 (PST) MIME-Version: 1.0 References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Fri, 14 Dec 2018 16:59:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: Alan Somers Cc: "freebsd-hackers@freebsd.org" , freebsd-drivers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9366B73870 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.83 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.95)[-0.948,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[179.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.87)[ip: (-9.42), ipnet: 209.85.128.0/17(-3.53), asn: 15169(-1.33), country: US(-0.09)]; RWL_MAILSPIKE_POSSIBLE(0.00)[179.166.85.209.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 00:59:56 -0000 On Fri, Dec 14, 2018 at 8:17 AM Alan Somers wrote: > > For some Intel based server hardware, there is the "ioat" driver, which > > allows for user code to schedule DMA operations. See ioat(4) for > > details, including a pointer to the test program. This isn't true (or at least, only for testing). It's only usable by the kernel at the moment. > * In what context are callbacks called? Are they called from a signal > handler, or in a separate thread, or something else? Directly from the ithread, mostly. Callers can't take sleep locks or do very much besides set a flag and wakeup, or kick off a callout or taskqueue. > * Why isn't ioat.h installed? Why would it be? It's a kernel interface. > * Are "interrupts" synonymous with callbacks? I don't understand the question. Interrupts are synonymous with interrupts. Like, MSI-X. > * Do you have a rough idea for about the minimum buffer size that > makes sense to use with ioat? What makes sense will depend on your use case. It's not necessarily faster than CPU memcpy, but it may be worth some slowdown to offload latency-insensitive bulk copies. (It may make a lot of sense for asynchronous page zero, if someone wants to bring that back.) It's worth benchmarking your specific model. We use it for >= 8kB copies on Broadwell, although that's largely an artifact of our use case (write sizes are exactly 8 bytes, 512 bytes, or multiples of 8kB). IIRC, it shows up as a gen3 PCIe device with some small number of lanes on Broadwell, although I may be mistaken; and it may not communicate with RAM over the PCIe bus anyway, given the tight integration with the CPU. Best, Conrad From owner-freebsd-hackers@freebsd.org Sat Dec 15 01:02: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 0EDF81327C11; Sat, 15 Dec 2018 01:02:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C9DD73C45; Sat, 15 Dec 2018 01:02:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f196.google.com with SMTP id e5-v6so6408691lja.4; Fri, 14 Dec 2018 17:02:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YksFTx6dp36biHe3ZqVMIxRi4GshjX65ibeFAbvHzfY=; b=h567i4G4KICLYY+A4tASOncpzX/1BwFyCPyMa2N1MG/wnfMfDvPmS9cJQUik5ZEAlI ryP4FurOyNzZKjKQnpWZ4oPpe7mL8Pu65Z2VX0GEB4ZYgy+RiJQxYrXgCJ++RJlJAfRy ee4vqOr5BW3xd7/SD0LdKnrdC1Cs+I7K/gt14hwu6vy9jmWx2jaEPZlBtM5p3pACStH8 HV12bdhxXaKpepNBMzLHdIdHfNLPDDFr2l/GLqThLEXch2GkYBj2JIxpNquhH4sP29oB vXEBLQZW02vTD+eyue6F5n+V/1J/VuE8EG+D9IJkNHKLEw+N0Vt0YIOvehqvQ8XhTPko bRhA== X-Gm-Message-State: AA+aEWaNTy8x3R5p5e5CnyqgJ1cHg1ksYwJK4qzTSPXtNFsjgkre9HmJ E7FWCp8WPsAIVG2nFk+uf3sOaF5da2hRcQxOwvmOsA== X-Google-Smtp-Source: AFSGD/WCE+5K7BcFi8Cyl8coRf9Ci1dJ3movDX6EU4eW5/DExTIryXBDKYKIp0ZTlnqJelU5MVUGiHNyhnpofchi1QA= X-Received: by 2002:a2e:94ce:: with SMTP id r14-v6mr2635221ljh.34.1544831841853; Fri, 14 Dec 2018 15:57:21 -0800 (PST) MIME-Version: 1.0 References: <26df913b-a2f8-2709-1cec-d11ad7d113a8@pix.net> In-Reply-To: From: Alan Somers Date: Fri, 14 Dec 2018 16:57:09 -0700 Message-ID: Subject: Re: How to use the DMA Engine in FreeBSD? To: Kurt Lidl Cc: Warner Losh , Rajesh Kumar , "freebsd-hackers@freebsd.org" , freebsd-drivers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7C9DD73C45 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 01:02:24 -0000 On Fri, Dec 14, 2018 at 4:04 PM Kurt Lidl wrote: > > On 12/14/18 11:09 AM, Alan Somers wrote: > > On Fri, Dec 14, 2018 at 8:36 AM Kurt Lidl wrote: > >> > >> On 12/13/18 10:53 AM, Warner Losh wrote: > >>> On Thu, Dec 13, 2018, 3:04 AM Rajesh Kumar >>> > >>>> Hi, > >>>> > >>>> Is there any good documentation available to understand the existing > >>>> support, API's and how-to use the DMA Engine in FreeBSD? > >>>> > >>> > >>> > >>> Usually you just use pci busmastering and it just works. > >>> > >>> I am trying to write a test driver which will use DMA Engine to do the data > >>>> transfer (rather than plain memcpy which involves cpu). Can anyone point > >>>> to any driver implementation which has similar functions implemented? I > >>>> see references to SYS_RES_DRQ to allocate DMA channels and play around. But > >>>> that seems to be specific to ISA. Can it be used for PCI drivers as well? > >>>> > >>> > >>> No. ISA DMA is only for really old hardware without it's own DMA engine. > >>> > >>> Look at the busdma api/man page. > >> > >> For some Intel based server hardware, there is the "ioat" driver, which > >> allows for user code to schedule DMA operations. See ioat(4) for > >> details, including a pointer to the test program. > >> > >> -Kurt > > > > ioat(4) looks cool. But the man page is vague on a few points. Do > > you know the answers to these questions? > > * What happened to ioatcontrol(8)? It's reference by the man page, > > but doesn't exist anywhere. > > root@busybox: locate ioatcontrol > /usr/src/tools/tools/ioat/ioatcontrol.8 > /usr/src/tools/tools/ioat/ioatcontrol.c > > > * In what context are callbacks called? Are they called from a signal > > handler, or in a separate thread, or something else? > > I don't know. > > > * Why isn't ioat.h installed? > > I don't know that either, but it is in the source tree: > > root@busybox: locate ioat.h > /usr/src/sys/dev/ioat/ioat.h > > > * Are "interrupts" synonymous with callbacks? > > * Do you have a rough idea for about the minimum buffer size that > > makes sense to use with ioat? > > I don't know that either -- I was mostly just pointing out that the > facility and driver existed for (some) Intel server hardware. Mostly > I'm aware of this because I was surprised when a machine I using this > summer started reporting this hardware, and I wasn't familiar with it. > > Good luck. > > -Kurt Oh, I see. ioat(4) can't be used from userland at all. It's strictly an in-kernel API. The man page should probably be moved to section 9. I'll take it up with cem. -Alan