From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 07:23:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA2973A6 for ; Mon, 20 Jan 2014 07:23:48 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id AB78D194B for ; Mon, 20 Jan 2014 07:23:48 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MZO00I2ESFGUU90@st11p09mm-asmtp001.mac.com> for freebsd-hackers@freebsd.org; Mon, 20 Jan 2014 06:23:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-01-19_03:2014-01-18,2014-01-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=5 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1401190303 From: Kimmo Paasiala Content-type: multipart/signed; boundary="Apple-Mail=_24A1291F-2A70-4C64-9D55-9DE2BD870FC2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Kernel build when going from WITHOUT_CTF world to WITH_CTF world. Message-id: <08780E49-8FFA-4A8A-A9DD-B60C8CC735D7@icloud.com> Date: Mon, 20 Jan 2014 08:23:34 +0200 To: freebsd-hackers@freebsd.org MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 07:23:48 -0000 --Apple-Mail=_24A1291F-2A70-4C64-9D55-9DE2BD870FC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I=92d like to try to fix an annoyance in the kernel build. If you have a = world built with WITHOUT_CTF (in my case I had WITHOUT_CDDL that = includes WITHOUT_CTF) that does not have a ctfmerge binary (and other = related ones) installed the next buildkernel will fail if you have built = the world before the kernel build with WITH_CTF set. Of course you can = manually go and install the ctfmerge and related binaries before = launching the buildkernel process but that is just too hacky for me. = Where should I look and what would be needed to change in the kernel = build so that it would check for the ctfmerge binaries from the = buildworld that was done before the buildkernel? -Kimmo --Apple-Mail=_24A1291F-2A70-4C64-9D55-9DE2BD870FC2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS3MDqAAoJEFvLZC0FWRVpVpUIAIrKt6rexm0jup1ku9PfYzXq JdpnKE0TNw0tosaElrxVBAkyPPI+yjfximJ8M91rVai94hzdzVdqzeWDYW1utOJK GvWwVNMe95yRcIIKVurqJQLD9kIXhk4ccvC4B+qNRLxF5dtT7uLiI0XgLoPVpbMf vFv532aQNpg8xh8F3IzWqdZJFzx5bdJyInn7fV2+Hj+BGe599wemqgksPiLEeLSg 9U3YMuPKfayMj5x/6zOWPE8xDZ1F4uxI30Xx9KRXfs0rO6Wx5Htzi+3Bue8DBkcn No23bstz38EEC6kOaTPYHmcvGeddAv0JiBBEQQw/ED03bqN4Q1FRCoXBjtOtzJ4= =Jrhw -----END PGP SIGNATURE----- --Apple-Mail=_24A1291F-2A70-4C64-9D55-9DE2BD870FC2-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 07:59:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 921DAD72 for ; Mon, 20 Jan 2014 07:59:55 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BD6F1CD4 for ; Mon, 20 Jan 2014 07:59:55 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::15d7:a1c2:121d:286b] (unknown [IPv6:2001:7b8:3a7:0:15d7:a1c2:121d:286b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5CD125C44; Mon, 20 Jan 2014 08:59:53 +0100 (CET) Subject: Re: Kernel build when going from WITHOUT_CTF world to WITH_CTF world. Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B9ACBD02-73B0-4E7D-BA45-D66FE49A8AE1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <08780E49-8FFA-4A8A-A9DD-B60C8CC735D7@icloud.com> Date: Mon, 20 Jan 2014 08:59:53 +0100 Message-Id: <32F7628E-D8BF-4534-B74E-38C589125D8F@FreeBSD.org> References: <08780E49-8FFA-4A8A-A9DD-B60C8CC735D7@icloud.com> To: Kimmo Paasiala X-Mailer: Apple Mail (2.1827) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 07:59:55 -0000 --Apple-Mail=_B9ACBD02-73B0-4E7D-BA45-D66FE49A8AE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 20 Jan 2014, at 07:23, Kimmo Paasiala wrote: >=20 > I=92d like to try to fix an annoyance in the kernel build. If you have = a world built with WITHOUT_CTF (in my case I had WITHOUT_CDDL that = includes WITHOUT_CTF) that does not have a ctfmerge binary (and other = related ones) installed the next buildkernel will fail if you have built = the world before the kernel build with WITH_CTF set. Of course you can = manually go and install the ctfmerge and related binaries before = launching the buildkernel process but that is just too hacky for me. = Where should I look and what would be needed to change in the kernel = build so that it would check for the ctfmerge binaries from the = buildworld that was done before the buildkernel? This is unfortunately a long-standing problem. To fix it, the CTF tools and libraries should be conditionally added to the kernel-tools stage. As of r260401 (by scottl), this stage is rather empty: aicasm was really the only tool built specifically for the kernel. So you would have to look at Makefile.inc1 before that revision to have an idea of how to add the CTF tools. -Dimitry --Apple-Mail=_B9ACBD02-73B0-4E7D-BA45-D66FE49A8AE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlLc13kACgkQsF6jCi4glqPABwCdGbCuTRT1LiXYIa/C4TElt1yZ RU8AoLP6Mti0caLI5Gc263luwD2z1GMh =fGmz -----END PGP SIGNATURE----- --Apple-Mail=_B9ACBD02-73B0-4E7D-BA45-D66FE49A8AE1-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 10:40:14 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 972DE2FE for ; Mon, 20 Jan 2014 10:40:14 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5594F19D0 for ; Mon, 20 Jan 2014 10:40:13 +0000 (UTC) Received: from [89.204.153.232] (helo=tiny-r255948) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W5CH1-0005Ex-Cu for freebsd-hackers@freebsd.org; Mon, 20 Jan 2014 11:40:07 +0100 Received: from tiny-r255948 (localhost [127.0.0.1]) by tiny-r255948 (8.14.7/8.14.3) with ESMTP id s0KAe44l001572 for ; Mon, 20 Jan 2014 11:40:04 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny-r255948 (8.14.7/8.14.3/Submit) id s0KAe34H001571 for freebsd-hackers@freebsd.org; Mon, 20 Jan 2014 11:40:03 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny-r255948: guru set sender to guru@unixarea.de using -f Date: Mon, 20 Jan 2014 11:40:03 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: untaring into ext2fs ./dev/* entries Message-ID: <20140120104003.GA1548@tiny-r255948> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.153.232 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 10:40:14 -0000 Hello, I'm using an OpenSource Linux based cellphone. The software is provided as a tar-archive which must be unpacked into an ext2fs on a microSD; I do not have any Linux box and want to do this on my FreeBSD (10-CURRENT) laptop; I can mount the ext2fs fine and when I say: # cd /mnt # gtar --numeric-owner -xpzf shr-image-om-gta02.tar.gz it gives errors like this example for all special files: gtar: ./dev/hda7: Cannot utime: Operation not supported gtar: ./dev/hda7: Cannot change ownership to uid 0, gid 6: Operation not supported gtar: ./dev/hda7: Cannot change mode to rw-rw----: Operation not supported in the tar-archive the file looks like this # gtar tzvf shr-image-om-gta02.tar.gz | fgrep ./dev/hda7 brw-rw---- 0 root disk 3,7 Jan 8 23:36 ./dev/hda7 and after unpacking into /mnt it is: # ls -l dev/hda7 brw------- 1 root wheel 0x307 Jan 20 11:00 dev/hda7 Which is not what we want. I've checked the man page of devfs(8), but see no way to solve this. Any ideas? matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 12:32:12 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC2179B0 for ; Mon, 20 Jan 2014 12:32:12 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98D371B06 for ; Mon, 20 Jan 2014 12:32:12 +0000 (UTC) Received: from [89.204.153.232] (helo=tiny-r255948) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1W5E1R-0002bG-Sc for freebsd-hackers@freebsd.org; Mon, 20 Jan 2014 13:32:10 +0100 Received: from tiny-r255948 (localhost [127.0.0.1]) by tiny-r255948 (8.14.7/8.14.3) with ESMTP id s0KCW7dY001842 for ; Mon, 20 Jan 2014 13:32:07 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny-r255948 (8.14.7/8.14.3/Submit) id s0KCW6Wq001841 for freebsd-hackers@freebsd.org; Mon, 20 Jan 2014 13:32:06 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny-r255948: guru set sender to guru@unixarea.de using -f Date: Mon, 20 Jan 2014 13:32:06 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: Re: untaring into ext2fs ./dev/* entries Message-ID: <20140120123205.GA1768@tiny-r255948> References: <20140120104003.GA1548@tiny-r255948> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140120104003.GA1548@tiny-r255948> X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.153.232 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 12:32:12 -0000 El día Monday, January 20, 2014 a las 11:40:03AM +0100, Matthias Apitz escribió: > > Hello, > > I'm using an OpenSource Linux based cellphone. The software is provided > as a tar-archive which must be unpacked into an ext2fs on a microSD; > I do not have any Linux box and want to do this on my FreeBSD > (10-CURRENT) laptop; > > I can mount the ext2fs fine and when I say: > > # cd /mnt > # gtar --numeric-owner -xpzf shr-image-om-gta02.tar.gz > > it gives errors like this example for all special files: > > gtar: ./dev/hda7: Cannot utime: Operation not supported > gtar: ./dev/hda7: Cannot change ownership to uid 0, gid 6: Operation not supported > gtar: ./dev/hda7: Cannot change mode to rw-rw----: Operation not supported ... This issue is clearly related to ext2fs; in UFS all is fine: # mkdir dev # mknod dev/hda7 b 3 7 root:mail # chmod 0660 dev/hda7 # ls -l dev/hda7 brw-rw---- 1 root mail 0x307 Jan 20 13:25 dev/hda7 in ext2fs mounted as /mnt it does not work: # mkdir /mnt/dev # mknod /mnt/dev/hda7 b 3 7 root:mail mknod: setting ownership on /mnt/dev/hda7: Operation not supported # chmod 0660 /mnt/dev/hda7 chmod: /mnt/dev/hda7: Operation not supported # ls -l /mnt/dev/hda7 brw-r--r-- 1 root wheel 0x307 Jan 20 13:26 /mnt/dev/hda7 Is this a bug in ext2fs or a feature? matthias -- Sent from my FreeBSD netbook Matthias Apitz, , http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 21:24:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEFA9EC6 for ; Mon, 20 Jan 2014 21:24:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 949EC1D2E for ; Mon, 20 Jan 2014 21:24:34 +0000 (UTC) Received: from pippin.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0B3CB918; Mon, 20 Jan 2014 16:24:33 -0500 (EST) From: John Baldwin To: Nomad Esst Subject: Re: Access pci devices' serial numbers programmatically Date: Mon, 20 Jan 2014 16:02:23 -0500 Message-ID: <37639448.Wf1F1apyVZ@pippin.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/11.0-CURRENT; KDE/4.10.5; amd64; ; ) In-Reply-To: <1389765959.45668.YahooMailNeo@web162702.mail.bf1.yahoo.com> References: <1389515545.51283.YahooMailNeo@web162704.mail.bf1.yahoo.com> <201401140824.03549.jhb@freebsd.org> <1389765959.45668.YahooMailNeo@web162702.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 20 Jan 2014 16:24:33 -0500 (EST) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 21:24:34 -0000 On Tuesday 14 January 2014 22:05:59 Nomad Esst wrote: > Yes I'm trying to get these information from user-land. Any ideas now? I just committed a change to HEAD to add a new flag to pciconf to dump VPD data. If you just need it in a shell script then 'pciconf -lV ' might be sufficient for you. If you want it programmatically, you can use the new ioctl I added to retrieve it from the kernel. If you need to do this on an older OS version where you can't backport my change (or upgrade to a version with this change), then you can use direct config register access to find the VPD capability and read the data directly using the VPD registers. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 21:59:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 087E11F6 for ; Mon, 20 Jan 2014 21:59:31 +0000 (UTC) Received: from rmx.billfink.com (rmx.billfink.com [98.175.222.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95D571FD6 for ; Mon, 20 Jan 2014 21:59:30 +0000 (UTC) Received: from BillsPC (wsip-174-79-172-9.ri.ri.cox.net [174.79.172.9]) (authenticated bits=0) by rmx.billfink.com (8.14.4/8.14.3) with ESMTP id s0KLxTE5039423 for ; Mon, 20 Jan 2014 16:59:29 -0500 (EST) (envelope-from bill@billfink.com) From: "William A. Fink" To: Subject: Looking For Beginner/Mediocre Help Date: Mon, 20 Jan 2014 16:59:11 -0500 Message-ID: <06be01cf162a$dd337bd0$979a7370$@billfink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8WKl6Av0/UiVZdT4CetOQCE7aMTQ== Content-Language: en-us X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 21:59:31 -0000 I hope I'm not double-posting, posting in a list I'm not supposed to, but it seems (to me, anyway) a great place to start. Seems it never fails, someone comes back and complains, this is the wrong list. (No matter which list I've posted to in the past.) I've these log entries each and every single day in my security logs: (needless to say, there are quite a few variations they attempt to use for username, seems it's getting worse every day.) I've ALL of China/Korea blocked, might I add. There's a guy who posts the CIDR addresses for/from China that's ALL in my black-hole routing table. I recognize that can only go so far, but it did indeed help for a good while. Any other solution(?) that anyone could help me with here? I'm simply looking for a simple way to stop these and/or determine where they're coming from. (No other log shows where they originate from.) I'm not even certain if I'm USING SASLAUTHD, so is there a way I can determine where these scripts are coming from so I can easily add their IP to the black-hole route? Thanks SO much in advance, and if I posted in the wrong place, please accept my sincerest apologies - even a one liner where to start to figure out where these are originating from would be a great help! Jan 12 00:02:27 rmx saslauthd[978]: do_auth : auth failure: [user=ups] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 00:16:00 rmx saslauthd[980]: do_auth : auth failure: [user=ups] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 00:29:36 rmx saslauthd[981]: do_auth : auth failure: [user=fedex] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 00:35:03 rmx saslauthd[966]: do_auth : auth failure: [user=student] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 00:43:07 rmx saslauthd[979]: do_auth : auth failure: [user=fedex] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 00:56:47 rmx saslauthd[978]: do_auth : auth failure: [user=phone] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 01:10:23 rmx saslauthd[980]: do_auth : auth failure: [user=phone] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 01:24:04 rmx saslauthd[981]: do_auth : auth failure: [user=noreply] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 01:24:56 rmx saslauthd[966]: do_auth : auth failure: [user=support] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 01:37:48 rmx saslauthd[979]: do_auth : auth failure: [user=noreply] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] Jan 12 01:51:20 rmx saslauthd[978]: do_auth : auth failure: [user=ttest] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 22:17:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 861E36C5 for ; Mon, 20 Jan 2014 22:17:37 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 404C51151 for ; Mon, 20 Jan 2014 22:17:37 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id uq10so9133685igb.2 for ; Mon, 20 Jan 2014 14:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=vxDY7blsZ+ESrJXSllNGHTqUusvq+CbwEwITZcOwy1I=; b=Of1OntE+yvZcKTtoUEUXmybDa8U0GMKUdOzfmTFcSH0nOxPw8+pJGaK40F0895B7GP LsT79UI2Ly+/fTvtRZpL8REAddHaZvVGmvbtUB6DRdOSu76uRrYE0bLhojFLnjQsBWMS 3ggVi+7xqat+oAGa7Pek9QVZaaqRmAxOL4qPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=vxDY7blsZ+ESrJXSllNGHTqUusvq+CbwEwITZcOwy1I=; b=XsQfjG1hJSaf07UErENke63UMrwpUEuBul4nct6yYk3xBxExTY1P5x2RldvBBeyTTe VuHAGyDc6itU1ncIiX0zTpqKzvlmbi1CV+8fp7nSrzyiWQCmVmkz0D0/XZ0YATqAzr1j O+prCcyBXJMvALifd8c6+6G8Ksue3KQOvsxjH6RGQykn5aPcMFnUTIWnT3kfctdHrOgi D1jC50yBigYLYWnztcKzfej91QoGYP7nAStpq50xFkCh0N4cfvp6tLAs8JLOvJ8LD3y1 EMMfZfTDNkXFjPkkkooV4d/jn/u34nvIKgWSiqnXgg53hpCV6zOfyIwBPhcJlbbh5SZr 8a5Q== X-Gm-Message-State: ALoCoQkGBNa6Sfd2rkSYAFIjRVc4whxP8OSA0SnrD2RM9jeIpRiNooR4Gosa/Yr4kAKCKOaJQjAA X-Received: by 10.43.106.137 with SMTP id du9mr9277icc.93.1390256256639; Mon, 20 Jan 2014 14:17:36 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id u1sm5979320ige.1.2014.01.20.14.17.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Jan 2014 14:17:34 -0800 (PST) References: <06be01cf162a$dd337bd0$979a7370$@billfink.com> Mime-Version: 1.0 (1.0) In-Reply-To: <06be01cf162a$dd337bd0$979a7370$@billfink.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-BD7F3473-28F8-499F-8288-E34684D16357; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <45D07BAC-D99A-4F54-AB3A-48AB611E4185@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Looking For Beginner/Mediocre Help Date: Mon, 20 Jan 2014 17:17:30 -0500 To: "William A. Fink" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 22:17:37 -0000 --Apple-Mail-BD7F3473-28F8-499F-8288-E34684D16357 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Since this is SMTP and not a service like http you might be able to benefit f= rom throttling and then shoving into a blacklist that expires the entries af= ter a certain period of time after they run a threshold. This is a pf exampl= e rule that would do that but still requires a table and the pf expiration p= rogram expiretable. I use this method for ssh connections but should work fine for 25, 587 or ot= herwise. pass in quick inet proto tcp from any port >1023 to any port =3D 22 keep sta= te \ (max-src-conn 5, max-src-states 10, max-src-nodes 5, max-src-conn-rate 5/300= overload flush global) --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 20, 2014, at 16:59, "William A. Fink" wrote: >=20 > I hope I'm not double-posting, posting in a list I'm not supposed to, but i= t > seems (to me, anyway) a great place to start. Seems it never fails, someon= e > comes back and complains, this is the wrong list. (No matter which list I'= ve > posted to in the past.) >=20 > I've these log entries each and every single day in my security logs: > (needless to say, there are quite a few variations they attempt to use for= > username, seems it's getting worse every day.) I've ALL of China/Korea > blocked, might I add. There's a guy who posts the CIDR addresses for/from > China that's ALL in my black-hole routing table. I recognize that can only= > go so far, but it did indeed help for a good while. >=20 > Any other solution(?) that anyone could help me with here? I'm simply > looking for a simple way to stop these and/or determine where they're comi= ng > from. (No other log shows where they originate from.) >=20 > I'm not even certain if I'm USING SASLAUTHD, so is there a way I can > determine where these scripts are coming from so I can easily add their IP= > to the black-hole route? >=20 > Thanks SO much in advance, and if I posted in the wrong place, please acce= pt > my sincerest apologies - even a one liner where to start to figure out whe= re > these are originating from would be a great help! >=20 > Jan 12 00:02:27 rmx saslauthd[978]: do_auth : auth failure: > [user=3Dups] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth e= rror] > Jan 12 00:16:00 rmx saslauthd[980]: do_auth : auth failure: > [user=3Dups] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth e= rror] > Jan 12 00:29:36 rmx saslauthd[981]: do_auth : auth failure: > [user=3Dfedex] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth= error] > Jan 12 00:35:03 rmx saslauthd[966]: do_auth : auth failure: > [user=3Dstudent] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM au= th error] > Jan 12 00:43:07 rmx saslauthd[979]: do_auth : auth failure: > [user=3Dfedex] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth= error] > Jan 12 00:56:47 rmx saslauthd[978]: do_auth : auth failure: > [user=3Dphone] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth= error] > Jan 12 01:10:23 rmx saslauthd[980]: do_auth : auth failure: > [user=3Dphone] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth= error] > Jan 12 01:24:04 rmx saslauthd[981]: do_auth : auth failure: > [user=3Dnoreply] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM au= th error] > Jan 12 01:24:56 rmx saslauthd[966]: do_auth : auth failure: > [user=3Dsupport] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM au= th error] > Jan 12 01:37:48 rmx saslauthd[979]: do_auth : auth failure: > [user=3Dnoreply] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM au= th error] > Jan 12 01:51:20 rmx saslauthd[978]: do_auth : auth failure: > [user=3Dttest] [service=3Dsmtp] [realm=3D] [mech=3Dpam] [reason=3DPAM auth= error] >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= --Apple-Mail-BD7F3473-28F8-499F-8288-E34684D16357 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDEyMDIyMTczM1owIwYJKoZIhvcN AQkEMRYEFOI55wg8j+bmeZd1v0HCaJehLgmpMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAIRngp/fTXLR/aN363mz2 4yhydpVPnSWWhkuoSDUSxF4hZdngm/CuCLng0knJ/+D9QEfV9TSOesPKc7hjqTzGoirE7Ka7Wsyk Pg/Sp7VJ4YuVU7SCpOwDpMZPzZRICs3xfzBpuhxTCSYn+BlT4Ayt2VKEFvVRtkOv2uIIY2ryTMiE Ar/Z4hjRGxmhzwSkiqaYw8gMJzUboFw3m1UQHsIMIBU6dE+mHj33mEk6aIITZgRaCw9yu0dD5yJZ uCK9GjNgcH9nQnVIP6a9msI+5YwLFdof73moLopz535OwFN0Jz2NXLQVdFUtnEKQnLkli97v04TJ bYII+hfa8LbNrK0lZgAAAAAAAA== --Apple-Mail-BD7F3473-28F8-499F-8288-E34684D16357-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 20 22:55:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF46F508 for ; Mon, 20 Jan 2014 22:55:23 +0000 (UTC) Received: from away.numachi.com (away.numachi.com [66.228.38.138]) by mx1.freebsd.org (Postfix) with SMTP id 7E4E6145B for ; Mon, 20 Jan 2014 22:55:23 +0000 (UTC) Received: (qmail 14911 invoked from network); 20 Jan 2014 22:48:39 -0000 Received: from unknown (HELO meisai.numachi.com) (71.181.44.212) by away.numachi.com with SMTP; 20 Jan 2014 22:48:39 -0000 Received: (qmail 94596 invoked by uid 1001); 20 Jan 2014 22:25:23 -0000 Date: Mon, 20 Jan 2014 17:25:23 -0500 From: Brian Reichert To: "William A. Fink" Subject: Re: Looking For Beginner/Mediocre Help Message-ID: <20140120222523.GG55121@numachi.com> References: <06be01cf162a$dd337bd0$979a7370$@billfink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06be01cf162a$dd337bd0$979a7370$@billfink.com> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 22:55:23 -0000 On Mon, Jan 20, 2014 at 04:59:11PM -0500, William A. Fink wrote: > I hope I'm not double-posting, posting in a list I'm not supposed to, but it > seems (to me, anyway) a great place to start. Seems it never fails, someone > comes back and complains, this is the wrong list. (No matter which list I've > posted to in the past.) if you're looking to expoose the incoming IP addresses, this post: http://serverfault.com/questions/281231/help-linux-server-under-smtp-saslauthd-attack has a response that says: You have to increase the LogLevel to 10 or more. Look in sendmail.mc or put something like define(confLOG_LEVEL',10')dnl This will log the IP number on auth failures. Presumably, once they're exposed, any of the mechanims for softly managing an IP blacklist would help. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Brian Reichert BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 06:54:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C10971BD for ; Tue, 21 Jan 2014 06:54:50 +0000 (UTC) Received: from ohta.kitchenlab.org (ohta.kitchenlab.org [IPv6:2001:470:1f05:55c::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 783551882 for ; Tue, 21 Jan 2014 06:54:50 +0000 (UTC) Received: from Bruces-MacBook-Pro.local (c-67-188-254-192.hsd1.ca.comcast.net [67.188.254.192]) (authenticated bits=0) by ohta.kitchenlab.org (8.14.7/8.14.7) with ESMTP id s0L6sjs6001161 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 22:54:46 -0800 (PST) (envelope-from bmah@FreeBSD.org) X-Authentication-Warning: ohta.kitchenlab.org: Host c-67-188-254-192.hsd1.ca.comcast.net [67.188.254.192] claimed to be Bruces-MacBook-Pro.local Message-ID: <52DE19B5.4040402@FreeBSD.org> Date: Mon, 20 Jan 2014 22:54:45 -0800 From: "Bruce A. Mah" Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brian Reichert , "William A. Fink" Subject: Re: Looking For Beginner/Mediocre Help References: <06be01cf162a$dd337bd0$979a7370$@billfink.com> <20140120222523.GG55121@numachi.com> In-Reply-To: <20140120222523.GG55121@numachi.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TxTscXrstpWDCbLN9Okjcro4VcK41RCAP" Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 06:54:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TxTscXrstpWDCbLN9Okjcro4VcK41RCAP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Brian Reichert wrote: > On Mon, Jan 20, 2014 at 04:59:11PM -0500, William A. Fink wrote: >> I hope I'm not double-posting, posting in a list I'm not supposed to, = but it >> seems (to me, anyway) a great place to start. Seems it never fails, so= meone >> comes back and complains, this is the wrong list. (No matter which lis= t I've >> posted to in the past.) >=20 > if you're looking to expoose the incoming IP addresses, this post: >=20 > http://serverfault.com/questions/281231/help-linux-server-under-smtp-= saslauthd-attack Thanks for posting that...this is something I've wondered about for awhile but was too lazy to look up. :-p > has a response that says: >=20 > You have to increase the LogLevel to 10 or more. Look in sendmail.mc = or put > something like define(confLOG_LEVEL',10')dnl >=20 > This will log the IP number on auth failures. >=20 > Presumably, once they're exposed, any of the mechanims for softly > managing an IP blacklist would help. I'm not sure about the syntax in the response. I think that this is correct (assuming it's going in sendmail.mc): define(`confLOG_LEVEL',10)dnl Bruce. --TxTscXrstpWDCbLN9Okjcro4VcK41RCAP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS3hm1AAoJEEmEkQqMqu6KWGQH/RJwRJqZxr6dgcd9I7MuJ1m7 IyBXOsgjwwQ+HY4fghHBSBAKnGEQS9Zab46OncGFBszGbKTi5UXX6CUvowSJgtVV T571f1Aj3qSHboN9Ns1c0UV79Dc7MaAF1YzW6GqKvJP+oIw9eGaBYGVfoP6fX5oi 5BGFlsG+xPExH8iKa5lOH3tt674ESqBTbDT8k3os1Ap0zrU4z1Oi05M5GilbROQK A4on6DQ6P8EbQKxcFGH9MYJ8T71vrdUVOSk3HhgPINFXRy1i3iCF85ZwJ3NCM2uS J8QNcZNqNPcrt9PPTMcdDruF4xNNVKYE+MAeIOW1USURLC84gLc/GRJVq73S02U= =fK8A -----END PGP SIGNATURE----- --TxTscXrstpWDCbLN9Okjcro4VcK41RCAP-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 17:26:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17E5AAA3 for ; Tue, 21 Jan 2014 17:26:48 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3A1B13E3 for ; Tue, 21 Jan 2014 17:26:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C2215B94C; Tue, 21 Jan 2014 12:26:46 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Atom Board ACPI API MOPNV10J failing since 9.1 Date: Tue, 21 Jan 2014 11:58:37 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52CF850A.9060906@erdgeist.org> <52D61BFA.1070205@erdgeist.org> In-Reply-To: <52D61BFA.1070205@erdgeist.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401211158.37784.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 12:26:46 -0500 (EST) Cc: Dirk Engling , David Shane Holden X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:26:48 -0000 On Wednesday, January 15, 2014 12:26:18 am Dirk Engling wrote: > On 15.01.14 05:02, David Shane Holden wrote: > > > I'm all for chalking this up to a subpar BIOS that ships with this > > board, but if it might be a problem in FreeBSD that could rear its ugly > > head somewhere else I'd like to help track down what's causing it. I'll > > try to find some time to test a Debian live CD and see how Linux handles > > it tomorrow. > > Look no further than FreeBSD pre 9.1, where my system worked flawlessly > for several years despite the on board audio and ACHI settings. It would > be interesting to see what has changed between 9.0 and 9.1. One of the changes is that for ACPI devices we always reserve the resources they claim even if the driver only asks for a subset (previously we only claimed what the driver explicitly asked for). This is important for making sure we don't hand a resource out to another device that is actually in use by an ACPI device (just not by the current driver). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 17:26:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80C95BAD for ; Tue, 21 Jan 2014 17:26:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58BD313E6 for ; Tue, 21 Jan 2014 17:26:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4E4DEB945; Tue, 21 Jan 2014 12:26:49 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Atom Board ACPI API MOPNV10J failing since 9.1 Date: Tue, 21 Jan 2014 12:15:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52CF850A.9060906@erdgeist.org> <201401140823.00259.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401211215.22021.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 12:26:49 -0500 (EST) Cc: David Shane Holden X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:26:50 -0000 On Tuesday, January 14, 2014 11:02:36 pm David Shane Holden wrote: > On 01/14/14 08:23, John Baldwin wrote: > > > > It's a resource conflict in the BIOS-assigned resources. > > > > It would be really handy if you could get the output of 'devinfo -u' > > and 'devinfo -rv' when it works, and a verbose dmesg when it is > > broken. > > > > I don't see how this would cause all the pcib allocation failures though > that are in the dmesg output. You mention that it's a resource conflict > in the BIOS, but I'm not seeing where it could be. Could these > allocation failures also explain why my Atheros card doesn't get > assigned an irq? Resources are not just IRQs. Looking at the dmesg diff: @@ -416,11 +417,12 @@ pcib0: allocated type 4 (0x1800-0x18ff) for rid 1c of pcib1 pcib1: allocating non-ISA range 0x1c00-0x1cff pcib0: allocated type 4 (0x1c00-0x1cff) for rid 1c of pcib1 -pcib1: failed to allocate initial prefetch window: 0xe0000000-0xe00fffff +pcib0: allocated type 3 (0xf0000000-0xf00fffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x1000-0x1fff +pcib1: prefetched decode 0xf0000000-0xf00fffff pcib1: special decode ISA pci1: on pcib1 pci1: domain=0, physical bus=1 This means that the pcib1 device was assigned a range by the BIOS at 0xe0000000 that was already assigned to another device. In this case it was assigned to agp0: -pcib0: allocated type 3 (0xe0000000-0xe0000fff) for rid 64 of agp0 -agp0: Allocated flush page phys 0xe0000000 virt 0xfffff800e0000000 And later on it was also assigned to re0: pcib1: allocated I/O port range (0x1000-0x10ff) for rid 10 of pci0:1:0:0 - map[18]: type Prefetchable Memory, range 64, base 0xe0004000, size 12, enabled -pcib1: failed to allocate initial prefetch window (0xe0004000-0xe0004fff,0x1000) -pcib1: failed to allocate initial memory window (0xe0004000-0xe0004fff,0x1000) -pci1: pci0:1:0:0 bar 0x18 failed to allocate - map[20]: type Prefetchable Memory, range 64, base 0xe0000000, size 14, memory disabled -pcib1: failed to allocate initial prefetch window (0xe0000000-0xe0003fff,0x4000) -pcib1: failed to allocate initial memory window (0xe0000000-0xe0003fff,0x4000) -pci1: pci0:1:0:0 bar 0x20 failed to allocate Hmm, I think I see the issue, and I might have a fix for it in the works already. The problem is that we haven't reserved pcib1's windows when agp probes, so agp0 steals a resource that is already in use. The change I have that might fix this isn't trivial though, so I don't have a patch I can just give you to test right now. :( Also, this isn't a BIOS issue per se. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 18:51:15 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15E3CF04 for ; Tue, 21 Jan 2014 18:51:15 +0000 (UTC) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED4781D07 for ; Tue, 21 Jan 2014 18:51:14 +0000 (UTC) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 48220C017B for ; Tue, 21 Jan 2014 18:12:41 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Tue, 21 Jan 2014 18:12:41 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 27FF62035E; Tue, 21 Jan 2014 18:12:41 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 21 Jan 2014 10:12:40 -0800 To: freebsd-hackers@freebsd.org Subject: reviving old FreeBSD4 SCSI beast From: "Dave Ng" Message-Id: <20140121181241.27FF62035E@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:51:15 -0000 So I have an older machine with a floppy drive, 4x SCSI drives, and a SCSI CDROM. Some of the drives are bad, and I managed to hose the userland by trying to install newer (~9.0 era, I think) binaries, before the kernel. Or was it the other way around. Either way, I have a machine that totally does not boot, and I am trying to revive it and read the drives that are still good. I have a newer, working IDE drive I can stick in there, which should help me out of this jam. However I still need to boot something in order to do an install. If I had another floppy drive I could write some boot floppies, if that is even still supported. But I only have the one floppy. A USB stick would have been a great solution except the motherboard is too old to support booting from USB. Is it likely that my Adaptec SCSI board can boot from a CDROM if I hook that device back up? The other path I was thinking, is I could probably stick the IDE drive in another (working) machine and dd a bootable image there. What would I want to use, the memstick image, or disc1, or what? The last option I can think of is PXE. Apparently this network board supports that, since I get PXE error messages when I try to boot now. However I have never set up a PXE server and have no idea how difficult that is. Thanks! Sent using Hushmail From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 18:54:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1FFB171 for ; Tue, 21 Jan 2014 18:54:47 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DF7AC1D3B for ; Tue, 21 Jan 2014 18:54:47 +0000 (UTC) Received: from Alfreds-MacBook-Pro.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id C4D6C1A3C19 for ; Tue, 21 Jan 2014 10:54:46 -0800 (PST) Message-ID: <52DEC272.3070907@mu.org> Date: Tue, 21 Jan 2014 10:54:42 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: reviving old FreeBSD4 SCSI beast References: <20140121181241.27FF62035E@smtp.hushmail.com> In-Reply-To: <20140121181241.27FF62035E@smtp.hushmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:54:48 -0000 Use a more modern machine to install to the IDE using an external USB->IDE bridge, then relocate drive to old machine. On 1/21/14, 10:12 AM, Dave Ng wrote: > So I have an older machine with a floppy drive, 4x SCSI drives, and a > SCSI CDROM. Some of the drives are bad, and I managed to hose the > userland by trying to install newer (~9.0 era, I think) binaries, > before the kernel. Or was it the other way around. Either way, I have > a machine that totally does not boot, and I am trying to revive it and > read the drives that are still good. > > I have a newer, working IDE drive I can stick in there, which should > help me out of this jam. However I still need to boot something in > order to do an install. If I had another floppy drive I could write > some boot floppies, if that is even still supported. But I only have > the one floppy. A USB stick would have been a great solution except > the motherboard is too old to support booting from USB. > Is it likely that my Adaptec SCSI board can boot from a CDROM if I > hook that device back up? > The other path I was thinking, is I could probably stick the IDE drive > in another (working) machine and dd a bootable image there. What would > I want to use, the memstick image, or disc1, or what? > The last option I can think of is PXE. Apparently this network board > supports that, since I get PXE error messages when I try to boot now. > However I have never set up a PXE server and have no idea how > difficult that is. > Thanks! > Sent using Hushmail > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://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 Jan 21 19:23:41 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E26A8475 for ; Tue, 21 Jan 2014 19:23:41 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B9951001 for ; Tue, 21 Jan 2014 19:23:41 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s0LJNdkv057955; Tue, 21 Jan 2014 12:23:39 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s0LJNdhD057952; Tue, 21 Jan 2014 12:23:39 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 21 Jan 2014 12:23:39 -0700 (MST) From: Warren Block To: Dave Ng Subject: Re: reviving old FreeBSD4 SCSI beast In-Reply-To: <20140121181241.27FF62035E@smtp.hushmail.com> Message-ID: References: <20140121181241.27FF62035E@smtp.hushmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 21 Jan 2014 12:23:39 -0700 (MST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:23:41 -0000 On Tue, 21 Jan 2014, Dave Ng wrote: > So I have an older machine with a floppy drive, 4x SCSI drives, and a > SCSI CDROM. Some of the drives are bad, and I managed to hose the > userland by trying to install newer (~9.0 era, I think) binaries, > before the kernel. Or was it the other way around. Either way, I have > a machine that totally does not boot, and I am trying to revive it and > read the drives that are still good. > > I have a newer, working IDE drive I can stick in there, which should > help me out of this jam. However I still need to boot something in > order to do an install. If I had another floppy drive I could write > some boot floppies, if that is even still supported. But I only have > the one floppy. A USB stick would have been a great solution except > the motherboard is too old to support booting from USB. > Is it likely that my Adaptec SCSI board can boot from a CDROM if I > hook that device back up? > The other path I was thinking, is I could probably stick the IDE drive > in another (working) machine and dd a bootable image there. What would > I want to use, the memstick image, or disc1, or what? > The last option I can think of is PXE. Apparently this network board > supports that, since I get PXE error messages when I try to boot now. > However I have never set up a PXE server and have no idea how > difficult that is. Rather than install a new drive in that machine, why not just move the old SCSI drives and controller into a newer machine? Boot from CD or USB on the new machine, use mfsBSD or live CD mode of an install CD, and copy the data off the drives. If the old machine is the only choice to run the drives, preinstalling FreeBSD on an IDE drive is a good option. PXE takes a bit of setup, but can be useful in a lot of situations: http://www.wonkity.com/~wblock/docs/html/pxe.html From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 19:54:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D23BE1E0 for ; Tue, 21 Jan 2014 19:54:18 +0000 (UTC) Received: from nm48-vm10.bullet.mail.bf1.yahoo.com (nm48-vm10.bullet.mail.bf1.yahoo.com [216.109.114.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 827631290 for ; Tue, 21 Jan 2014 19:54:18 +0000 (UTC) Received: from [66.196.81.171] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2014 19:54:11 -0000 Received: from [98.139.213.13] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2014 19:54:11 -0000 Received: from [127.0.0.1] by smtp113.mail.bf1.yahoo.com with NNFMP; 21 Jan 2014 19:54:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1390334051; bh=tR503NmCSRHH1uJnl/q9s5lAAAmldCtvdGnL3ADveDk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=wVHmoqmwaxlO1cb13TOvkJ4Jr+VYrM5S0LQeeRwx4Vfzj7E2dPdC7M1KHYNaeHtCq9xroBnJhWGki+luIIVP/Qf2AHm5uC+8qrc3xNo9MGa2Ig2UwuJlQrz8OKDnbePOihUdrhW/guEWVEhkcHweOTf1qBfIGf0OI9I5P02uH2M= X-Yahoo-Newman-Id: 651190.26307.bm@smtp113.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 66AA2rIVM1kg.OdYrlWfMDghBq8iGWhA8Ig_MIwMiannOqH l_cB1u_0vBLhoGj9kKB6g2nJX1_qP1f4ygB0g3tTw_KybNL_siPQuXXTJA9d sQ8_yFgjB4J4UzsWx77VwPr9PAsOAXlwJT6Bwx.Y5sCOaTAbgY2cT5FvorUp 1.D84zeWeF7_OCo41MTFl5mtnbgWnD5tuj3I5RIPEXQGeB5o6d5iJRRHLcHp V64lQbi9ogYi1rcfz1rO4G09sgENaapYHa_rldiIpAbe_EcR4k33bP1.MJXx BHezGbusZPbPnXzJdk2Fj3z1DJOC9Dg6bdOkcimOxOOFzcFczlQefxdUXCzD g.4yqGaKVYOmSWfdvIMgLBrGxO.5b5S_JTRm_n.uxHWr5v7c6mBOi2NTK... kUPQEAVD72STO5tyLQfNKJZ5cp.MRFIMe2fNGKCES4dVSEFegp3hsNTU.2yC eeTmOhuh.Qb.9yfqd13.SoV7i8xxA7FJxUf_c06Rj7MaMwuTblw9cm1CVpDc eqvoYfOaH4cVmwVopsp3CRw_SV4qR9IxI6j.Eiov0CYm6glE- X-Yahoo-SMTP: 4VhmBaWswBBKhhYsa0wE5OAFfRI- X-Rocket-Received: from i7x.pr1.dpejesh.net (dpejesh@97.96.39.205 with plain [63.250.193.228]) by smtp113.mail.bf1.yahoo.com with SMTP; 21 Jan 2014 11:54:11 -0800 PST Message-ID: <52DED060.4070800@yahoo.com> Date: Tue, 21 Jan 2014 14:54:08 -0500 From: David Shane Holden User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Atom Board ACPI API MOPNV10J failing since 9.1 References: <52CF850A.9060906@erdgeist.org> <201401140823.00259.jhb@freebsd.org> <201401211215.22021.jhb@freebsd.org> In-Reply-To: <201401211215.22021.jhb@freebsd.org> Content-Type: multipart/mixed; boundary="------------070503030404060103050504" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 19:54:18 -0000 This is a multi-part message in MIME format. --------------070503030404060103050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/21/14 12:15, John Baldwin wrote: > > Hmm, I think I see the issue, and I might have a fix for it in the > works already. The problem is that we haven't reserved pcib1's > windows when agp probes, so agp0 steals a resource that is already > in use. The change I have that might fix this isn't trivial though, > so I don't have a patch I can just give you to test right now. :( > Also, this isn't a BIOS issue per se. > I came to the same conclusion a few days ago when I started digging into it more. The agp driver requests some memory and the resource manager gives it a chunk which should be reserved for the bridge. I couldn't find an elegant solution; the best I could come up with was to add the bridge devices first in pci_add_children() to ensure they got attached before anything else. Which worked, but seems like a hack. Feel free to ping me if you have something that needs testing. --------------070503030404060103050504 Content-Type: text/plain; charset=us-ascii; name="pci.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pci.patch" diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c index 4d8837f..38c102f 100644 --- a/sys/dev/pci/pci.c +++ b/sys/dev/pci/pci.c @@ -3278,7 +3278,8 @@ pci_add_children(device_t dev, int domain, int busno, size_t dinfo_size) dinfo = pci_read_device(pcib, domain, busno, s, f, dinfo_size); if (dinfo != NULL) { - pci_add_child(dev, dinfo); + pci_add_child_ordered(dev, + (hdrtype & PCIM_HDRTYPE) == PCIM_HDRTYPE_BRIDGE ? 0 : 1, dinfo); } } } @@ -3288,7 +3289,13 @@ pci_add_children(device_t dev, int domain, int busno, size_t dinfo_size) void pci_add_child(device_t bus, struct pci_devinfo *dinfo) { - dinfo->cfg.dev = device_add_child(bus, NULL, -1); + pci_add_child_ordered(bus, 0, dinfo); +} + +void +pci_add_child_ordered(device_t bus, u_int order, struct pci_devinfo *dinfo) +{ + dinfo->cfg.dev = device_add_child_ordered(bus, order, NULL, -1); device_set_ivars(dinfo->cfg.dev, dinfo); resource_list_init(&dinfo->resources); pci_cfg_save(dinfo->cfg.dev, dinfo, 0); diff --git a/sys/dev/pci/pci_private.h b/sys/dev/pci/pci_private.h index 1502288..10536fc 100644 --- a/sys/dev/pci/pci_private.h +++ b/sys/dev/pci/pci_private.h @@ -48,6 +48,8 @@ extern int pci_do_power_suspend; void pci_add_children(device_t dev, int domain, int busno, size_t dinfo_size); void pci_add_child(device_t bus, struct pci_devinfo *dinfo); +void pci_add_child_ordered(device_t bus, u_int order, + struct pci_devinfo *dinfo); void pci_add_resources(device_t bus, device_t dev, int force, uint32_t prefetchmask); int pci_attach_common(device_t dev); --------------070503030404060103050504-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 20:17:31 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD951C78 for ; Tue, 21 Jan 2014 20:17:31 +0000 (UTC) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8CF0B14BD for ; Tue, 21 Jan 2014 20:17:31 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZR00C00PCXRW00@smtpauth4.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Tue, 21 Jan 2014 14:17:29 -0600 (CST) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.21.200617, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (i3-user-nat.icecube.wisc.edu [128.104.255.12]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZR00EJ2PP44P30@smtpauth4.wiscmail.wisc.edu>; Tue, 21 Jan 2014 14:17:29 -0600 (CST) Message-id: <52DED5D8.6040908@freebsd.org> Date: Tue, 21 Jan 2014 14:17:28 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Dave Ng , freebsd-hackers@freebsd.org Subject: Re: reviving old FreeBSD4 SCSI beast References: <20140121181241.27FF62035E@smtp.hushmail.com> In-reply-to: <20140121181241.27FF62035E@smtp.hushmail.com> X-Enigmail-Version: 1.6 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:17:31 -0000 On 01/21/14 12:12, Dave Ng wrote: > So I have an older machine with a floppy drive, 4x SCSI drives, and a > SCSI CDROM. Some of the drives are bad, and I managed to hose the > userland by trying to install newer (~9.0 era, I think) binaries, > before the kernel. Or was it the other way around. Either way, I have > a machine that totally does not boot, and I am trying to revive it and > read the drives that are still good. > > I have a newer, working IDE drive I can stick in there, which should > help me out of this jam. However I still need to boot something in > order to do an install. If I had another floppy drive I could write > some boot floppies, if that is even still supported. But I only have > the one floppy. A USB stick would have been a great solution except > the motherboard is too old to support booting from USB. > Is it likely that my Adaptec SCSI board can boot from a CDROM if I > hook that device back up? > The other path I was thinking, is I could probably stick the IDE drive > in another (working) machine and dd a bootable image there. What would > I want to use, the memstick image, or disc1, or what? > The last option I can think of is PXE. Apparently this network board > supports that, since I get PXE error messages when I try to boot now. > However I have never set up a PXE server and have no idea how > difficult that is. > Thanks! > Sent using Hushmail > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" SCSI CD drives should be perfectly bootable. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 22 11:32:46 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 854DAB2E; Wed, 22 Jan 2014 11:32:46 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC991EF1; Wed, 22 Jan 2014 11:32:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA23687; Wed, 22 Jan 2014 13:32:37 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W5w2v-000MSQ-Jd; Wed, 22 Jan 2014 13:32:37 +0200 Message-ID: <52DFAC31.6030905@FreeBSD.org> Date: Wed, 22 Jan 2014 13:32:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: core dump vs kern.ipc.shm_use_phys X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 11:32:46 -0000 I seems that if kern.ipc.shm_use_phys is enabled then shared memory regions are not included into a coredump. Seems that each_writable_segment() in sys/kern/imgact_elf.c skips OBJT_PHYS objects. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 24 08:09:51 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47D51A6A; Fri, 24 Jan 2014 08:09:51 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 72A1410A2; Fri, 24 Jan 2014 08:09:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA05508; Fri, 24 Jan 2014 10:09:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W6bpk-0005ku-Hz; Fri, 24 Jan 2014 10:09:48 +0200 Message-ID: <52E21F94.5000104@FreeBSD.org> Date: Fri, 24 Jan 2014 10:08:52 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: doc@FreeBSD.org Subject: Fwd: Re: svn commit: r258713 - in head/sys: kern sys References: <52D93F91.502@FreeBSD.org> In-Reply-To: <52D93F91.502@FreeBSD.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <52D93F91.502@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 08:09:51 -0000 I would like to commit the following manual page update. Could you please review it? Thank you very much! -------- Original Message -------- Message-ID: <52D93F91.502@FreeBSD.org> Date: Fri, 17 Jan 2014 16:34:57 +0200 From: Andriy Gapon To: Justin T. Gibbs CC: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r258713 - in head/sys: kern sys References: <201311281856.rASIuZu8059699@svn.freebsd.org> <3784C560-3648-4E03-93DA-9A60E3AC401D@scsiguy.com> In-Reply-To: <3784C560-3648-4E03-93DA-9A60E3AC401D@scsiguy.com> on 30/11/2013 08:46 Justin T. Gibbs said the following: > Man page update? I came up with the following update that - adds taskqueue_drain_all documentation - extends taskqueue_drain description - adds description for previously undocumented taskqueue_block / taskqueue_unblock, including a warning on taskqueue_block + taskqueue_drain combination All reviews and suggestions are welcome. Both for content and language. diff --git a/share/man/man9/taskqueue.9 b/share/man/man9/taskqueue.9 index 5f6131a..4db3d7a 100644 --- a/share/man/man9/taskqueue.9 +++ b/share/man/man9/taskqueue.9 @@ -86,6 +86,12 @@ struct timeout_task; .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" .Ft void .Fn taskqueue_drain_timeout "struct taskqueue *queue" "struct timeout_task *timeout_task" +.Ft void +.Fn taskqueue_drain_all "struct taskqueue *queue" +.Ft void +.Fn taskqueue_block "struct taskqueue *queue" +.Ft void +.Fn taskqueue_unblock "struct taskqueue *queue" .Ft int .Fn taskqueue_member "struct taskqueue *queue" "struct thread *td" .Ft void @@ -255,6 +261,74 @@ function is used to wait for the scheduled task to finish. There is no guarantee that the task will not be enqueued after call to .Fn taskqueue_drain . +Because the caller typically would use +.Fn taskqueue_drain +to put the task into a known state, then the caller should use +out-of-band means to ensure, before calling +.Fn taskqueue_drain , +that the task would not be enqueued. +For example, if the task is enqueued by an interrupt filter, then +the interrupt could be disabled. +.Pp +The +.Fn taskqueue_drain_all +function is used to wait for all the pending and running tasks that +are enqueued on the taskqueue to finish. +The caller must arrange that the tasks are not re-enqueued. +Note that +.Fn taskqueue_drain_all +currently does not handle tasks with delayed enqueueing. +.Pp +The +.Fn taskqueue_block +function blocks the taskqueue. +It prevents any enqueued but not running tasks from being executed. +Future calls to +.Fn taskqueue_enqueue +will enqueue tasks, but the tasks will not be run until +.Fn taskqueue_unblock +is called. +Please note that +.Fn taskqueue_block +does not wait for any currently running tasks to finish. +Thus, the +.Fn taskqueue_block +does not provide a guarantee that +.Fn taskqueue_run +is not running after +.Fn taskqueue_block +returns, but it does provide a guarantee that +.Fn taskqueue_run +will not be called again +until +.Fn taskqueue_unblock +is called. +If the caller requires a guarantee that +.Fn taskqueue_run +is not running, then this must be arranged by the caller. +Note that if +.Fn taskqueue_drain +is called on a task that is enqueued on a taskqueue that is blocked by +.Fn taskqueue_block , +then +.Fn taskqueue_drain +can not return until the taskqueue is unblocked. +This can result in a deadlock if the thread blocked in +.Fn taskqueue_drain +is a thread that is supposed to call +.Fn taskqueue_unblock . +Thus, use of +.Fn taskqueue_drain +after +.Fn taskqueue_block +is discouraged, because a state of the task can not be known in advance. +The same applies to +.Fn taskqueue_drain_all . +.Pp +The +.Fn taskqueue_unblock +function unblocks the previously blocked taskqueue. +All enqueued tasks can be run after this call. .Pp The .Fn taskqueue_member -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 24 07:36:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 978D1B30; Fri, 24 Jan 2014 07:36:24 +0000 (UTC) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA6B91E5B; Fri, 24 Jan 2014 07:36:23 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id EEAFD640156; Fri, 24 Jan 2014 11:36:08 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id C9BB92C074A; Fri, 24 Jan 2014 11:36:08 +0400 (MSK) Received: from 95.108.170.36-red.dhcp.yndx.net (95.108.170.36-red.dhcp.yndx.net [95.108.170.36]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id CgjK8oGxfP-a8vOdV3E; Fri, 24 Jan 2014 11:36:08 +0400 (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 2899ebf9-2281-439c-b2c4-dd8a763c3304 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1390548968; bh=XstNle/Nib50Wr/KnaHqTfMQgR6GwXxknNCPO1w7158=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type; b=NzrnCFjPf0allBuiNwQH4bNA+J1u+097C6xHJ9uP9x9DH0CrhEJl8oL4Hwq4gL7Ti PmIqsYTMj42p/8vgHLuLULAwfAiM9yEA6/D7Q1G6+t2bKeheTbw2AWYmSvXE6OtxIC w+SQGebWUBVgfKMW2c0CyONl54SnHlHxUvnWpkWc= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <52E21721.5010309@yandex-team.ru> Date: Fri, 24 Jan 2014 11:32:49 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "net@freebsd.org" Subject: "slow path" in network code || IPv6 panic on inteface removal Content-Type: multipart/mixed; boundary="------------050804080408080705010802" X-Mailman-Approved-At: Fri, 24 Jan 2014 12:52:20 +0000 Cc: arch@freebsd.org, hackers@freebsd.org, "Andrey V. Elsukov" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 07:36:24 -0000 This is a multi-part message in MIME format. --------------050804080408080705010802 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello guys! Typically we're mostly interested in making "fast" paths in our code running faster. However it seems it is time to take care of code which is either called rarely or is quite complex in terms of relative code size or/and locking. Some good examples from current codebase are probably: * L3->L2 mapping like ARP handling - while doing doing arpresolve we discover there is no valid entry, so we start doing complex locking, are request preparing/sending in the same piece of code. This washes out both i/d caches and makes sending process _more_ unpredictable. Here we can queue given mbuf to delayed processing and return quickly. * ip_fastfwd() handling corner cases. This is already optimized in terms of splitting "fast" and "slow" code paths for all cases. * ipfw(4) (and probably other pfil consumers) generating/sending various icmp/icmp6 packets for inbound mbuf What exactly is proposed: - Another one netisr queue for handling different types of packets - metainfo is stored in mbuf_tag attached to packet - ifnet departure handler taking care of packets queued from/to killed ifnet - API to register/unregister/dispath given type of traffic Real problem which is solved by this approach (traced by ae@): We're using per-LLE IPv6 timers for various purposes, most of them requires LLE modifications, so timer function starts with lle write lock held. Some timer events requires us to send neighbour solicication messages which involves a) source address selection (requiring LLE lock being held ) and b) calling ip6_output() which requires LLE lock being not held. It is solved exactly as in IPv4 arp handling code: timer function drops write lock before calling nd6_ns_output(). Dropping/acquiring lock is error-prone, for example, the following scenario is possible (traced by ae@): we're calling if_detach(ifp) (thread 1) and nd6_llinfo_timer (thread 2). Then the following can happen: #1 T2 releases LLE lock and runs nd6_ns_output(). #2 T1 proceeds with detaching: in6_ifdetach() -> in6_purgeaddr() -> nd6_rem_ifa_lle() -> in6_lltable_prefix_free() which removes all LLEs for given prefix acquiring each LLE write lock. "Our" LLE is not destroyed since it is refcounted by nd6_llinfo_settimer_locked(). #3 T2 proceeds with nd6_ns_output() selecting source address (which involves acquiring LLE read lock) #4 T1 finishes with detaching interface addresses and sets ifp->if_addr to NULL #5 T2 calls nd6_ifptomac() which reads interface MAC from ifp->if_addr #6 User inspects core generated by previous call Using new API, we can avoid #6 by making the following code changes: * LLE timer does not drop/reacquire LLE lock * we require nd6_ns_output callers to lock LLE if it is provided * nd6_ns_output() uses "slow" path instead of sending mbuf to ip6_output() immediately if LLE is not NULL. What do you think? --------------050804080408080705010802 Content-Type: text/x-patch; name="dly_fin2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dly_fin2.diff" Index: sys/conf/files =================================================================== --- sys/conf/files (revision 260983) +++ sys/conf/files (working copy) @@ -3044,6 +3044,7 @@ net/bpf_filter.c optional bpf | netgraph_bpf net/bpf_zerocopy.c optional bpf net/bridgestp.c optional bridge | if_bridge net/flowtable.c optional flowtable inet | flowtable inet6 +net/delayed_dispatch.c standard net/ieee8023ad_lacp.c optional lagg net/if.c standard net/if_arcsubr.c optional arcnet Index: sys/net/netisr.c =================================================================== --- sys/net/netisr.c (revision 260983) +++ sys/net/netisr.c (working copy) @@ -555,6 +555,81 @@ netisr_setqlimit(const struct netisr_handler *nhp, } /* + * Scan workqueue and delete mbufs pointed to handler. + */ +static int +netisr_scan_workqueue(struct netisr_work *npwp, netisr_scan_t *scan_f, + void *data) +{ + struct mbuf *m, *m_prev; + int deleted; + + deleted = 0; + m_prev = NULL; + m = npwp->nw_head; + while (m != NULL) { + if (scan_f(m, data) == 0) { + m_prev = m; + m = m->m_nextpkt; + continue; + } + + /* Handler requested item deletion */ + if (m_prev == NULL) + npwp->nw_head = m->m_nextpkt; + else + m_prev->m_nextpkt = m->m_nextpkt; + + if (m->m_nextpkt == NULL) + npwp->nw_tail = m_prev; + + npwp->nw_len--; + m_freem(m); + deleted++; + + if (m_prev == NULL) + m = npwp->nw_head; + else + m = m_prev->m_nextpkt; + } + + return (deleted); +} + +int +netisr_scan(unsigned int proto, netisr_scan_t *scan_f, void *data) +{ +#ifdef NETISR_LOCKING + struct rm_priotracker tracker; +#endif + struct netisr_proto *np; + struct netisr_work *npwp; + unsigned int i; + int deleted; + +#ifdef NETISR_LOCKING + NETISR_RLOCK(&tracker); +#endif + + deleted = 0; + + KASSERT(scan_f != NULL, ("%s: scan function is NULL", __func__)); + + np = &netisr_proto[proto]; + + CPU_FOREACH(i) { + npwp = &(DPCPU_ID_PTR(i, nws))->nws_work[proto]; + deleted += netisr_scan_workqueue(npwp, scan_f, data); + } + +#ifdef NETISR_LOCKING + NETISR_RUNLOCK(&tracker); +#endif + + return (deleted); +} + +/* * Drain all packets currently held in a particular protocol work queue. */ static void Index: sys/net/netisr.h =================================================================== --- sys/net/netisr.h (revision 260983) +++ sys/net/netisr.h (working copy) @@ -61,6 +61,7 @@ #define NETISR_IPV6 10 #define NETISR_NATM 11 #define NETISR_EPAIR 12 /* if_epair(4) */ +#define NETISR_SLOWPATH 13 /* delayed dispatch */ /* * Protocol ordering and affinity policy constants. See the detailed @@ -178,6 +179,7 @@ struct sysctl_netisr_work { */ struct mbuf; typedef void netisr_handler_t(struct mbuf *m); +typedef int netisr_scan_t(struct mbuf *m, void *); typedef struct mbuf *netisr_m2cpuid_t(struct mbuf *m, uintptr_t source, u_int *cpuid); typedef struct mbuf *netisr_m2flow_t(struct mbuf *m, uintptr_t source); @@ -212,6 +214,7 @@ void netisr_getqlimit(const struct netisr_handler void netisr_register(const struct netisr_handler *nhp); int netisr_setqlimit(const struct netisr_handler *nhp, u_int qlimit); void netisr_unregister(const struct netisr_handler *nhp); +int netisr_scan(u_int proto, netisr_scan_t *, void *); /* * Process a packet destined for a protocol, and attempt direct dispatch. Index: sys/netinet6/nd6.c =================================================================== --- sys/netinet6/nd6.c (revision 260983) +++ sys/netinet6/nd6.c (working copy) @@ -153,6 +153,8 @@ nd6_init(void) callout_init(&V_nd6_slowtimo_ch, 0); callout_reset(&V_nd6_slowtimo_ch, ND6_SLOWTIMER_INTERVAL * hz, nd6_slowtimo, curvnet); + + nd6_nbr_init(); } #ifdef VIMAGE @@ -160,6 +162,7 @@ void nd6_destroy() { + nd6_nbr_destroy(); callout_drain(&V_nd6_slowtimo_ch); callout_drain(&V_nd6_timer_ch); } @@ -500,9 +503,7 @@ nd6_llinfo_timer(void *arg) if (ln->la_asked < V_nd6_mmaxtries) { ln->la_asked++; nd6_llinfo_settimer_locked(ln, (long)ndi->retrans * hz / 1000); - LLE_WUNLOCK(ln); nd6_ns_output(ifp, NULL, dst, ln, 0); - LLE_WLOCK(ln); } else { struct mbuf *m = ln->la_hold; if (m) { @@ -547,9 +548,7 @@ nd6_llinfo_timer(void *arg) ln->la_asked = 1; ln->ln_state = ND6_LLINFO_PROBE; nd6_llinfo_settimer_locked(ln, (long)ndi->retrans * hz / 1000); - LLE_WUNLOCK(ln); nd6_ns_output(ifp, dst, dst, ln, 0); - LLE_WLOCK(ln); } else { ln->ln_state = ND6_LLINFO_STALE; /* XXX */ nd6_llinfo_settimer_locked(ln, (long)V_nd6_gctimer * hz); @@ -559,9 +558,7 @@ nd6_llinfo_timer(void *arg) if (ln->la_asked < V_nd6_umaxtries) { ln->la_asked++; nd6_llinfo_settimer_locked(ln, (long)ndi->retrans * hz / 1000); - LLE_WUNLOCK(ln); nd6_ns_output(ifp, dst, dst, ln, 0); - LLE_WLOCK(ln); } else { EVENTHANDLER_INVOKE(lle_event, ln, LLENTRY_EXPIRED); (void)nd6_free(ln, 0); Index: sys/netinet6/nd6.h =================================================================== --- sys/netinet6/nd6.h (revision 260983) +++ sys/netinet6/nd6.h (working copy) @@ -421,6 +421,8 @@ int nd6_storelladdr(struct ifnet *, struct mbuf *, const struct sockaddr *, u_char *, struct llentry **); /* nd6_nbr.c */ +void nd6_nbr_init(void); +void nd6_nbr_destroy(void); void nd6_na_input(struct mbuf *, int, int); void nd6_na_output(struct ifnet *, const struct in6_addr *, const struct in6_addr *, u_long, int, struct sockaddr *); Index: sys/netinet6/nd6_nbr.c =================================================================== --- sys/netinet6/nd6_nbr.c (revision 260983) +++ sys/netinet6/nd6_nbr.c (working copy) @@ -74,6 +74,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #define SDL(s) ((struct sockaddr_dl *)s) @@ -87,12 +88,37 @@ static void nd6_dad_ns_input(struct ifaddr *); static void nd6_dad_na_input(struct ifaddr *); static void nd6_na_output_fib(struct ifnet *, const struct in6_addr *, const struct in6_addr *, u_long, int, struct sockaddr *, u_int); +static int nd6_ns_output2(struct mbuf *, int, uintptr_t, struct ifnet *); VNET_DEFINE(int, dad_ignore_ns) = 0; /* ignore NS in DAD - specwise incorrect*/ VNET_DEFINE(int, dad_maxtry) = 15; /* max # of *tries* to transmit DAD packet */ #define V_dad_ignore_ns VNET(dad_ignore_ns) #define V_dad_maxtry VNET(dad_maxtry) +static struct dly_dispatcher dly_d = { + .name = "nd6_ns", + .dly_dispatch = nd6_ns_output2, +}; + +static int nd6_dlyid; + +void +nd6_nbr_init() +{ + + if (IS_DEFAULT_VNET(curvnet)) + nd6_dlyid = dly_register(&dly_d); +} + +void +nd6_nbr_destroy() +{ + + if (IS_DEFAULT_VNET(curvnet)) + dly_unregister(nd6_dlyid); +} + + /* * Input a Neighbor Solicitation Message. * @@ -366,11 +392,34 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len m_freem(m); } +static int +nd6_ns_output2(struct mbuf *m, int dad, uintptr_t _data, struct ifnet *ifp) +{ + struct ip6_moptions im6o; + + if (m->m_flags & M_MCAST) { + im6o.im6o_multicast_ifp = ifp; + im6o.im6o_multicast_hlim = 255; + im6o.im6o_multicast_loop = 0; + } + + /* Zero ingress interface not to fool PFIL consumers */ + m->m_pkthdr.rcvif = NULL; + + ip6_output(m, NULL, NULL, dad ? IPV6_UNSPECSRC : 0, &im6o, NULL, NULL); + icmp6_ifstat_inc(ifp, ifs6_out_msg); + icmp6_ifstat_inc(ifp, ifs6_out_neighborsolicit); + ICMP6STAT_INC(icp6s_outhist[ND_NEIGHBOR_SOLICIT]); + + return (0); +} + /* * Output a Neighbor Solicitation Message. Caller specifies: * - ICMP6 header source IP6 address * - ND6 header target IP6 address * - ND6 header source datalink address + * Note llentry has to be locked if specified * * Based on RFC 2461 * Based on RFC 2462 (duplicate address detection) @@ -386,11 +435,9 @@ nd6_ns_output(struct ifnet *ifp, const struct in6_ struct m_tag *mtag; struct ip6_hdr *ip6; struct nd_neighbor_solicit *nd_ns; - struct ip6_moptions im6o; int icmp6len; int maxlen; caddr_t mac; - struct route_in6 ro; if (IN6_IS_ADDR_MULTICAST(taddr6)) return; @@ -413,13 +460,8 @@ nd6_ns_output(struct ifnet *ifp, const struct in6_ if (m == NULL) return; - bzero(&ro, sizeof(ro)); - if (daddr6 == NULL || IN6_IS_ADDR_MULTICAST(daddr6)) { m->m_flags |= M_MCAST; - im6o.im6o_multicast_ifp = ifp; - im6o.im6o_multicast_hlim = 255; - im6o.im6o_multicast_loop = 0; } icmp6len = sizeof(*nd_ns); @@ -468,7 +510,6 @@ nd6_ns_output(struct ifnet *ifp, const struct in6_ hsrc = NULL; if (ln != NULL) { - LLE_RLOCK(ln); if (ln->la_hold != NULL) { struct ip6_hdr *hip6; /* hold ip6 */ @@ -483,7 +524,6 @@ nd6_ns_output(struct ifnet *ifp, const struct in6_ hsrc = &hip6->ip6_src; } } - LLE_RUNLOCK(ln); } if (hsrc && (ifa = (struct ifaddr *)in6ifa_ifpwithaddr(ifp, hsrc)) != NULL) { @@ -502,7 +542,7 @@ nd6_ns_output(struct ifnet *ifp, const struct in6_ oifp = ifp; error = in6_selectsrc(&dst_sa, NULL, - NULL, &ro, NULL, &oifp, &src_in); + NULL, NULL, NULL, &oifp, &src_in); if (error) { char ip6buf[INET6_ADDRSTRLEN]; nd6log((LOG_DEBUG, @@ -572,20 +612,16 @@ nd6_ns_output(struct ifnet *ifp, const struct in6_ m_tag_prepend(m, mtag); } - ip6_output(m, NULL, &ro, dad ? IPV6_UNSPECSRC : 0, &im6o, NULL, NULL); - icmp6_ifstat_inc(ifp, ifs6_out_msg); - icmp6_ifstat_inc(ifp, ifs6_out_neighborsolicit); - ICMP6STAT_INC(icp6s_outhist[ND_NEIGHBOR_SOLICIT]); + if (ln == NULL) + nd6_ns_output2(m, dad, 0, ifp); + else { + m->m_pkthdr.rcvif = ifp; /* Save VNET */ + dly_queue(nd6_dlyid, m, dad, 0, ifp); + } - /* We don't cache this route. */ - RO_RTFREE(&ro); - return; bad: - if (ro.ro_rt) { - RTFREE(ro.ro_rt); - } m_freem(m); return; } Index: sys/sys/mbuf.h =================================================================== --- sys/sys/mbuf.h (revision 260983) +++ sys/sys/mbuf.h (working copy) @@ -1022,6 +1022,7 @@ struct mbuf *m_unshare(struct mbuf *, int); #define PACKET_TAG_CARP 28 /* CARP info */ #define PACKET_TAG_IPSEC_NAT_T_PORTS 29 /* two uint16_t */ #define PACKET_TAG_ND_OUTGOING 30 /* ND outgoing */ +#define PACKET_TAG_DISPATCH_INFO 31 /* Netist slow dispatch */ /* Specific cookies and tags. */ --- /dev/null 2014-01-24 00:33:00.000000000 +0400 +++ sys/net/delayed_dispatch.c 2014-01-24 00:17:05.573964680 +0400 @@ -0,0 +1,364 @@ +/*- + * Copyright (c) 2014 Alexander V. Chernikov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD: head/sys/net/delayed_dispatch.c$"); + +/* + * delayed dispatch is so-called "slowpath" packet path which permits you + * to enqueue mbufs requiring complex dispath (and/or possibly complex locking) + * into separate netisr queue instead of trying to deal with it in "fast" code path. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +struct dly_info { + struct dly_dispatcher *index; + int alloc; + int count; + struct rmlock lock; +}; +#define DLY_ALLOC_ITEMS 16 + +static struct dly_info dly; + +#define DLY_LOCK_INIT() rm_init(&dly.lock, "dly_lock") +#define DLY_RLOCK() rm_rlock(&dly.lock, &tracker) +#define DLY_RUNLOCK() rm_runlock(&dly.lock, &tracker) +#define DLY_WLOCK() rm_wlock(&dly.lock) +#define DLY_WUNLOCK() rm_wunlock(&dly.lock) +#define DLY_READER struct rm_priotracker tracker + +static eventhandler_tag ifdetach_tag; + +/* + * Adds mbuf to slowpath queue. Additional information + * is stored in PACKET_TAG_DISPATCH_INFO mbuf tag. + * Returns 0 if successfull, error code overwise. + */ +int +dly_queue(int dtype, struct mbuf *m, int dsubtype, uintptr_t data, + struct ifnet *ifp) +{ + struct dly_item *item; + struct m_tag *dtag; + DLY_READER; + + /* Ensure we're not going to cycle packet */ + if ((dtag = m_tag_find(m, PACKET_TAG_DISPATCH_INFO, NULL)) != NULL) { + printf("tag found: %p\n", dtag); + return (EINVAL); + } + + DLY_RLOCK(); + if (dtype < 0 || dtype >= dly.alloc || dly.index[dtype].name == NULL) { + DLY_RUNLOCK(); + printf("invalid dtype: 0..%d..%d\n", dtype, dly.alloc); + return (EINVAL); + } + DLY_RUNLOCK(); + + VNET_ASSERT(m->m_pkthdr.rcvif != NULL, + ("%s:%d rcvif == NULL: m=%p", __func__, __LINE__, m)); + + /* + * Do not allocate tag for basic IPv4/IPv6 output + */ + if (dtype != 0) { + dtag = m_tag_get(PACKET_TAG_DISPATCH_INFO, + sizeof(struct dly_item), M_NOWAIT); + + if (dtag == NULL) + return (ENOBUFS); + + item = (struct dly_item *)(dtag + 1); + + item->type = dtype; + item->subtype = dsubtype; + item->data = data; + item->ifp = ifp; + + m_tag_prepend(m, dtag); + } + + netisr_queue(NETISR_SLOWPATH, m); + + return (0); +} + +/* + * Adds mbuf to slowpath queue. User-provided buffer + * of size @size is stored inside PACKET_TAG_DISPATCH_INFO + * mbuf tag. Buffer structure needs to embed properly filled + * dly_item structure at the beginning of buffer. Such buffers + * needs to be dispatched by dly_pdispatch() handler. + * + * Returns 0 if successfull, error code overwise. + */ +int +dly_pqueue(int dtype, struct mbuf *m, struct dly_item *item, size_t size) +{ + struct m_tag *dtag; + DLY_READER; + + /* Ensure we're not going to cycle packet */ + if ((dtag = m_tag_find(m, PACKET_TAG_DISPATCH_INFO, NULL)) != NULL) { + return (EINVAL); + } + + DLY_RLOCK(); + if (dtype < 0 || dtype >= dly.alloc || dly.index[dtype].name == NULL) { + DLY_RUNLOCK(); + return (EINVAL); + } + DLY_RUNLOCK(); + + VNET_ASSERT(m->m_pkthdr.rcvif != NULL, + ("%s:%d rcvif == NULL: m=%p", __func__, __LINE__, m)); + + dtag = m_tag_get(PACKET_TAG_DISPATCH_INFO, size, M_NOWAIT); + + if (dtag == NULL) + return (ENOBUFS); + + memcpy(dtag + 1, item, size); + m_tag_prepend(m, dtag); + netisr_queue(NETISR_SLOWPATH, m); + + return (0); +} + +/* + * Base netisr handler for slowpath + */ +static void +dly_dispatch_item(struct mbuf *m) +{ + struct m_tag *dtag; + struct dly_item *item; + int dtype; + struct dly_dispatcher *dld; + DLY_READER; + + item = NULL; + dtype = 0; + + if ((dtag = m_tag_find(m, PACKET_TAG_DISPATCH_INFO, NULL)) != NULL) { + item = (struct dly_item *)(dtag + 1); + dtype = item->type; + } + + DLY_RLOCK(); + if (dtype < 0 || dtype >= dly.alloc || dly.index[dtype].name == NULL) { + DLY_RUNLOCK(); + return; + } + + dld = &dly.index[dtype]; + + if (dld->dly_dispatch != NULL) + dld->dly_dispatch(m, item->subtype, item->data, item->ifp); + else + dld->dly_pdispatch(m, item); + + DLY_RUNLOCK(); + + return; +} + + +/* + * Check if queue items is received or going to be transmitted + * via destroying interface. + */ +static int +dly_scan_ifp(struct mbuf *m, void *_data) +{ + struct m_tag *dtag; + struct dly_item *item; + struct ifnet *difp; + + difp = (struct ifnet *)_data; + + if (m->m_pkthdr.rcvif == difp) + return (1); + + if ((dtag = m_tag_find(m, PACKET_TAG_DISPATCH_INFO, NULL)) != NULL) { + item = (struct dly_item *)(dtag + 1); + if (item->ifp == difp) + return (1); + } + + return (0); +} + +/* + * Registers new slowpath handler. + * Returns handler id to use in dly_queue() or + * dly_pqueue() functions/ + */ +int +dly_register(struct dly_dispatcher *dld) +{ + int i, alloc; + struct dly_dispatcher *dd, *tmp; + +again: + DLY_WLOCK(); + + if (dly.count < dly.alloc) { + i = dly.count++; + dly.index[i] = *dld; + DLY_WUNLOCK(); + return (i); + } + + alloc = dly.alloc + DLY_ALLOC_ITEMS; + + DLY_WUNLOCK(); + + /* No spare room, need to increase */ + dd = malloc(sizeof(struct dly_dispatcher) * alloc, M_TEMP, + M_ZERO|M_WAITOK); + + DLY_WLOCK(); + if (dly.alloc >= alloc) { + /* Lost the race, try again */ + DLY_WUNLOCK(); + free(dd, M_TEMP); + goto again; + } + + memcpy(dly.index, dd, sizeof(struct dly_dispatcher) * dly.alloc); + tmp = dly.index; + dly.index = dd; + dly.alloc = alloc; + i = dly.count++; + dly.index[i] = *dld; + DLY_WUNLOCK(); + + free(tmp, M_TEMP); + + return (i); +} + +/* + * Checks if given netisr queue item is of type which + * needs to be unregistered. + */ +static int +dly_scan_unregistered(struct mbuf *m, void *_data) +{ + struct m_tag *dtag; + struct dly_item *item; + int i; + + i = *((int *)(intptr_t)_data); + + if ((dtag = m_tag_find(m, PACKET_TAG_DISPATCH_INFO, NULL)) != NULL) { + item = (struct dly_item *)(dtag + 1); + if (item->type == i) + return (1); + } + + return (0); +} + +/* + * Unregisters slow handler registered previously by dly_register(). + * Caller needs to ensure that no new items of given type can be queued + * prior calling this function. + */ +void +dly_unregister(int dtype) +{ + + netisr_scan(NETISR_SLOWPATH, dly_scan_unregistered, &dtype); + + DLY_WLOCK(); + if (dtype < 0 || dtype >= dly.alloc || dly.index[dtype].name == NULL) { + DLY_WUNLOCK(); + return; + } + + KASSERT(dly.index[dtype].name != NULL, + ("%s: unresigstering non-existend protocol %d", __func__, dtype)); + + memset(&dly.index[dtype], 0, sizeof(struct dly_dispatcher)); + DLY_WUNLOCK(); +} + + +static void +dly_ifdetach(void *arg __unused, struct ifnet *ifp) +{ + + netisr_scan(NETISR_SLOWPATH, dly_scan_ifp, ifp); +} + +static struct netisr_handler dly_nh = { + .nh_name = "slow", + .nh_handler = dly_dispatch_item, + .nh_proto = NETISR_SLOWPATH, + .nh_policy = NETISR_POLICY_SOURCE, +}; + +static void +dly_init(__unused void *arg) +{ + + memset(&dly, 0, sizeof(dly)); + dly.index = malloc(sizeof(struct dly_dispatcher) * DLY_ALLOC_ITEMS, + M_TEMP, M_ZERO|M_WAITOK); + dly.alloc = DLY_ALLOC_ITEMS; + dly.count = 1; + + DLY_LOCK_INIT(); + + netisr_register(&dly_nh); + ifdetach_tag = EVENTHANDLER_REGISTER(ifnet_departure_event, + dly_ifdetach, NULL, EVENTHANDLER_PRI_ANY); +} + +/* Exactly after netisr */ +SYSINIT(dly_init, SI_SUB_SOFTINTR, SI_ORDER_SECOND, dly_init, NULL); + --- /dev/null 2014-01-24 00:33:00.000000000 +0400 +++ sys/net/delayed_dispatch.h 2014-01-23 23:54:50.166594749 +0400 @@ -0,0 +1,57 @@ +/*- + * Copyright (c) 2014 Alexander V. Chernikov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD: head/sys/net/netisr.h 222249 2011-05-24 12:34:19Z rwatson $ + */ + +#ifndef _NET_DELAYED_DISPATCH_H_ +#define _NET_DELAYED_DISPATCH_H_ + +struct dly_item { + int type; + int subtype; + struct ifnet *ifp; + uintptr_t data; +}; + +typedef int dly_dispatch_t(struct mbuf *, int, uintptr_t, struct ifnet *); +typedef int dly_pdispatch_t(struct mbuf *, struct dly_item *); +typedef int dly_free_t(struct mbuf *, int, uintptr_t, struct ifnet *); + +struct dly_dispatcher { + const char *name; + dly_dispatch_t *dly_dispatch; + dly_pdispatch_t *dly_pdispatch; + dly_free_t *dly_free; +}; + + +int dly_register(struct dly_dispatcher *); +void dly_unregister(int); +int dly_queue(int, struct mbuf *, int, uintptr_t, struct ifnet *); +int dly_pqueue(int, struct mbuf *, struct dly_item *, size_t); + +#endif + --------------050804080408080705010802-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 24 14:16:37 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A63917D; Fri, 24 Jan 2014 14:16:37 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 39092112B; Fri, 24 Jan 2014 14:16:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA11609; Fri, 24 Jan 2014 16:16:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1W6hYg-0006By-1Q; Fri, 24 Jan 2014 16:16:34 +0200 Message-ID: <52E27589.8050302@FreeBSD.org> Date: Fri, 24 Jan 2014 16:15:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: doc@FreeBSD.org Subject: taskqueue(9) manual page update References: <52D93F91.502@FreeBSD.org> In-Reply-To: <52D93F91.502@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:16:37 -0000 [I intended to change the subject line and forgot, so this is a dupe.] I would like to commit the following manual page update. Could you please review it? Thank you very much! -------- Original Message -------- Message-ID: <52D93F91.502@FreeBSD.org> Date: Fri, 17 Jan 2014 16:34:57 +0200 From: Andriy Gapon To: Justin T. Gibbs CC: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r258713 - in head/sys: kern sys References: <201311281856.rASIuZu8059699@svn.freebsd.org> <3784C560-3648-4E03-93DA-9A60E3AC401D@scsiguy.com> In-Reply-To: <3784C560-3648-4E03-93DA-9A60E3AC401D@scsiguy.com> on 30/11/2013 08:46 Justin T. Gibbs said the following: > Man page update? I came up with the following update that - adds taskqueue_drain_all documentation - extends taskqueue_drain description - adds description for previously undocumented taskqueue_block / taskqueue_unblock, including a warning on taskqueue_block + taskqueue_drain combination All reviews and suggestions are welcome. Both for content and language. diff --git a/share/man/man9/taskqueue.9 b/share/man/man9/taskqueue.9 index 5f6131a..4db3d7a 100644 --- a/share/man/man9/taskqueue.9 +++ b/share/man/man9/taskqueue.9 @@ -86,6 +86,12 @@ struct timeout_task; .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" .Ft void .Fn taskqueue_drain_timeout "struct taskqueue *queue" "struct timeout_task *timeout_task" +.Ft void +.Fn taskqueue_drain_all "struct taskqueue *queue" +.Ft void +.Fn taskqueue_block "struct taskqueue *queue" +.Ft void +.Fn taskqueue_unblock "struct taskqueue *queue" .Ft int .Fn taskqueue_member "struct taskqueue *queue" "struct thread *td" .Ft void @@ -255,6 +261,74 @@ function is used to wait for the scheduled task to finish. There is no guarantee that the task will not be enqueued after call to .Fn taskqueue_drain . +Because the caller typically would use +.Fn taskqueue_drain +to put the task into a known state, then the caller should use +out-of-band means to ensure, before calling +.Fn taskqueue_drain , +that the task would not be enqueued. +For example, if the task is enqueued by an interrupt filter, then +the interrupt could be disabled. +.Pp +The +.Fn taskqueue_drain_all +function is used to wait for all the pending and running tasks that +are enqueued on the taskqueue to finish. +The caller must arrange that the tasks are not re-enqueued. +Note that +.Fn taskqueue_drain_all +currently does not handle tasks with delayed enqueueing. +.Pp +The +.Fn taskqueue_block +function blocks the taskqueue. +It prevents any enqueued but not running tasks from being executed. +Future calls to +.Fn taskqueue_enqueue +will enqueue tasks, but the tasks will not be run until +.Fn taskqueue_unblock +is called. +Please note that +.Fn taskqueue_block +does not wait for any currently running tasks to finish. +Thus, the +.Fn taskqueue_block +does not provide a guarantee that +.Fn taskqueue_run +is not running after +.Fn taskqueue_block +returns, but it does provide a guarantee that +.Fn taskqueue_run +will not be called again +until +.Fn taskqueue_unblock +is called. +If the caller requires a guarantee that +.Fn taskqueue_run +is not running, then this must be arranged by the caller. +Note that if +.Fn taskqueue_drain +is called on a task that is enqueued on a taskqueue that is blocked by +.Fn taskqueue_block , +then +.Fn taskqueue_drain +can not return until the taskqueue is unblocked. +This can result in a deadlock if the thread blocked in +.Fn taskqueue_drain +is a thread that is supposed to call +.Fn taskqueue_unblock . +Thus, use of +.Fn taskqueue_drain +after +.Fn taskqueue_block +is discouraged, because a state of the task can not be known in advance. +The same applies to +.Fn taskqueue_drain_all . +.Pp +The +.Fn taskqueue_unblock +function unblocks the previously blocked taskqueue. +All enqueued tasks can be run after this call. .Pp The .Fn taskqueue_member -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 24 20:01:43 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79FC8DCF for ; Fri, 24 Jan 2014 20:01:43 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51990139F for ; Fri, 24 Jan 2014 20:01:43 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0OK1g7X003297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Jan 2014 12:01:42 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0OK1grV003296 for hackers@FreeBSD.org; Fri, 24 Jan 2014 12:01:42 -0800 (PST) (envelope-from jmg) Date: Fri, 24 Jan 2014 12:01:42 -0800 From: John-Mark Gurney To: hackers@FreeBSD.org Subject: make buildkernel figure out compiler type.. Message-ID: <20140124200141.GE75135@funkthat.com> Mail-Followup-To: hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 24 Jan 2014 12:01:42 -0800 (PST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:01:43 -0000 When I was building armeb, I would often specify the correct compiler on buildtools/kernel-tools, but then when I went to buildkernel, I would forget... So, I figured out if we just drop COMPILER_TYPE from KMAKEENV, the right magic will be executed to figure out which of clang/gcc should be used... $ svn diff Makefile.inc1 Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 260499) +++ Makefile.inc1 (working copy) @@ -451,7 +451,7 @@ IMAKE_MTREE= MTREE_CMD="nmtree ${MTREEFLAGS}" .endif # kernel stage -KMAKEENV= ${WMAKEENV} +KMAKEENV= ${WMAKEENV:NCOMPILER_TYPE=*} KMAKE= ${KMAKEENV} ${MAKE} ${.MAKEFLAGS} ${KERNEL_FLAGS} KERNEL=${INSTKERNNAME} # Comments? Please CC me as I'm not subscribed to -hackers. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 24 20:56:58 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89C91C72; Fri, 24 Jan 2014 20:56:58 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C1E3B17B2; Fri, 24 Jan 2014 20:56:57 +0000 (UTC) X-AuditID: 12074425-f79906d000000cf9-2f-52e2d2651911 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 82.38.03321.562D2E25; Fri, 24 Jan 2014 15:51:49 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s0OKpmWZ002727; Fri, 24 Jan 2014 15:51:49 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s0OKpkN8009934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jan 2014 15:51:48 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s0OKpk3B017448; Fri, 24 Jan 2014 15:51:46 -0500 (EST) Date: Fri, 24 Jan 2014 15:51:46 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Andriy Gapon Subject: Re: Fwd: Re: svn commit: r258713 - in head/sys: kern sys In-Reply-To: <52E21F94.5000104@FreeBSD.org> Message-ID: References: <52D93F91.502@FreeBSD.org> <52E21F94.5000104@FreeBSD.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrpt66VGQwZt1MhaTXnWyW0z9uJPV YsOCQgdmjxmf5rMEMEZx2aSk5mSWpRbp2yVwZdz7dIS5YKZmxYsu+wbGnYpdjJwcEgImEvNu 9bFB2GISF+6tB7K5OIQEZjNJ/Hr4H8rZyChx8kEzM4RziEli+62frBBOA6PEoVOnmUD6WQS0 JT6cmMEMYrMJqEk83tvMCjFXUWLzqUlgcREBJYnHS7+wgNjMAhoSe5r2gNnCAo4Sl6/dA6vh BJrTsGcmWC8vUHzKq11g9wkJuEr823sKbJeogI7E6v1TWCBqBCVOznwCNdNS4tyf62wTGIVm IUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIziAXVR3ME44pHSI UYCDUYmHd0bgwyAh1sSy4srcQ4ySHExKorxqpx8FCfEl5adUZiQWZ8QXleakFh9ilOBgVhLh nbsZKMebklhZlVqUD5OS5mBREue9xWEfJCSQnliSmp2aWpBaBJOV4eBQkuA9fhGoUbAoNT21 Ii0zpwQhzcTBCTKcB2j4A5Aa3uKCxNzizHSI/ClGRSlx3nsgCQGQREZpHlwvLMG8YhQHekWY 9yRIFQ8wOcF1vwIazAQ0eMXZByCDSxIRUlINjPJHtVx/3PwRtyliSiTnGSPHiVpcy0xPV4je LOPa8kabJ/ZV0drpN99dT78c+voCi8mdidcOqN/dk9FzyNEnTmFqxQq+fbL/rOa97yhKcEvo 5dkn+XbJ6bM2u2c8rHJf1BkzNfKOIUPKx2OttR/rw/gaM1qXXre9FlkUeePvxqr45EWKDctm 7VdiKc5INNRiLipOBAC7wmdFCwMAAA== Cc: hackers@freebsd.org, doc@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 20:56:58 -0000 On Fri, 24 Jan 2014, Andriy Gapon wrote: > > I would like to commit the following manual page update. > Could you please review it? > Thank you very much! > > -------- Original Message -------- > Message-ID: <52D93F91.502@FreeBSD.org> > Date: Fri, 17 Jan 2014 16:34:57 +0200 > From: Andriy Gapon > To: Justin T. Gibbs > CC: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org > Subject: Re: svn commit: r258713 - in head/sys: kern sys > References: <201311281856.rASIuZu8059699@svn.freebsd.org> > <3784C560-3648-4E03-93DA-9A60E3AC401D@scsiguy.com> > In-Reply-To: <3784C560-3648-4E03-93DA-9A60E3AC401D@scsiguy.com> > > on 30/11/2013 08:46 Justin T. Gibbs said the following: >> Man page update? > > I came up with the following update that > - adds taskqueue_drain_all documentation > - extends taskqueue_drain description > - adds description for previously undocumented taskqueue_block / > taskqueue_unblock, including a warning on taskqueue_block + taskqueue_drain > combination > > All reviews and suggestions are welcome. Both for content and language. > > diff --git a/share/man/man9/taskqueue.9 b/share/man/man9/taskqueue.9 > index 5f6131a..4db3d7a 100644 > --- a/share/man/man9/taskqueue.9 > +++ b/share/man/man9/taskqueue.9 > @@ -86,6 +86,12 @@ struct timeout_task; > .Fn taskqueue_drain "struct taskqueue *queue" "struct task *task" > .Ft void > .Fn taskqueue_drain_timeout "struct taskqueue *queue" "struct timeout_task > *timeout_task" > +.Ft void > +.Fn taskqueue_drain_all "struct taskqueue *queue" > +.Ft void > +.Fn taskqueue_block "struct taskqueue *queue" > +.Ft void > +.Fn taskqueue_unblock "struct taskqueue *queue" > .Ft int > .Fn taskqueue_member "struct taskqueue *queue" "struct thread *td" > .Ft void > @@ -255,6 +261,74 @@ function is used to wait for the scheduled task to finish. > There is no guarantee that the task will not be > enqueued after call to > .Fn taskqueue_drain . > +Because the caller typically would use > +.Fn taskqueue_drain > +to put the task into a known state, then the caller should use This "then" is a bit odd, I think the sentence is better without it. > +out-of-band means to ensure, before calling > +.Fn taskqueue_drain , > +that the task would not be enqueued. > +For example, if the task is enqueued by an interrupt filter, then > +the interrupt could be disabled. > +.Pp > +The > +.Fn taskqueue_drain_all > +function is used to wait for all the pending and running tasks that > +are enqueued on the taskqueue to finish. > +The caller must arrange that the tasks are not re-enqueued. > +Note that > +.Fn taskqueue_drain_all > +currently does not handle tasks with delayed enqueueing. > +.Pp > +The > +.Fn taskqueue_block > +function blocks the taskqueue. > +It prevents any enqueued but not running tasks from being executed. > +Future calls to > +.Fn taskqueue_enqueue > +will enqueue tasks, but the tasks will not be run until > +.Fn taskqueue_unblock > +is called. > +Please note that > +.Fn taskqueue_block > +does not wait for any currently running tasks to finish. > +Thus, the > +.Fn taskqueue_block > +does not provide a guarantee that > +.Fn taskqueue_run > +is not running after > +.Fn taskqueue_block > +returns, but it does provide a guarantee that > +.Fn taskqueue_run > +will not be called again > +until > +.Fn taskqueue_unblock > +is called. > +If the caller requires a guarantee that > +.Fn taskqueue_run > +is not running, then this must be arranged by the caller. > +Note that if > +.Fn taskqueue_drain > +is called on a task that is enqueued on a taskqueue that is blocked by > +.Fn taskqueue_block , > +then > +.Fn taskqueue_drain > +can not return until the taskqueue is unblocked. I would prefer "cannot" as a single word here, though I don't think our style guide says anything about this case. > +This can result in a deadlock if the thread blocked in > +.Fn taskqueue_drain > +is a thread that is supposed to call Is s/a/the/ correct? That is, by my reading, if the thread blocked in taskqueue_drain is only one of several that could call taskqueue_unblock, the other threads would still (eventually) do so and there is no deadlock. So the risk of deadlock would (only?) be if there is only one thread that is supposed to call taskqueue_unblock. > +.Fn taskqueue_unblock . > +Thus, use of > +.Fn taskqueue_drain > +after > +.Fn taskqueue_block > +is discouraged, because a state of the task can not be known in advance. s/ a / the / here is needed, though, I am certain. > +The same applies to I would put another noun here, as "same caveat" or "same warning" or something like that. -Ben > +.Fn taskqueue_drain_all . > +.Pp > +The > +.Fn taskqueue_unblock > +function unblocks the previously blocked taskqueue. > +All enqueued tasks can be run after this call. > .Pp > The > .Fn taskqueue_member > > > -- > Andriy Gapon > > > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 25 20:02:09 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7A2F597; Sat, 25 Jan 2014 20:02:09 +0000 (UTC) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C188310EB; Sat, 25 Jan 2014 20:02:08 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id r15so1592562ead.27 for ; Sat, 25 Jan 2014 12:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:organization:mime-version :content-type:content-transfer-encoding; bh=9OrG1crjScIS5qBul504Q91aeahDnazNQ/C384mH5c0=; b=ieXXUj857YjuOhgCL+dG4EkU6iDk3fk5irmNNNMzApQqUCL7RjnXmhB1b/Bd2kCozH E5AGoWwwmjfuTQfluy4ro07u5UPN9Y1CwBPQNljMMY9wimnayOka+mS7KPZ1gO4SmCaE cpvclhadjJy3uyExaHvXk9ehf/cvus6XfXjOsL+HZBe+w8qHpMDsCQWsICr79rCNd6GZ IgOyPFiJHP5zVG5zuKb1CKefQ5pLEjtGkKm5TmyCAZU5LJlGKjK7Dr2482A601jjrxmA hnWrjxVhRQYuL7KFog/Z9GL2a3D6LWMMdOKgWCAw75RbDvIIdPoFhLY6LQu67+vHRzb4 0tfQ== X-Received: by 10.14.10.73 with SMTP id 49mr252139eeu.96.1390680126946; Sat, 25 Jan 2014 12:02:06 -0800 (PST) Received: from funktor (catv-80-99-67-72.catv.broadband.hu. [80.99.67.72]) by mx.google.com with ESMTPSA id n7sm19770939eef.5.2014.01.25.12.02.04 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 25 Jan 2014 12:02:06 -0800 (PST) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sat, 25 Jan 2014 21:02:01 +0100 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report, October-December 2013 Message-ID: <20140125210201.0310e35e@funktor> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 20:02:09 -0000 FreeBSD Quarterly Status Report, October-December 2013 Introduction This report covers FreeBSD-related projects between October and December 2013. This is the last of four reports planned for 2013. The last quarter of 2013 was very active for the FreeBSD community, much like the preceding quarters. Many advances were made in getting FreeBSD to run on ARM-based System-on-Chip boards like Cubieboard, Rockchip, Snapdragon, S4, Freescale i.MX6 and Vybrid VF6xx. FreeBSD is also becoming a better platform for Xen and the Amazon Elastic Compute Cloud. There are plans for FreeBSD to become a fully supported compute host for OpenStack. The I/O stack has again received some performance boosts on multi-processor systems through work touching the CAM and GEOM subsystems, and through better adaptation of UMA caches to system memory constraints for ZFS. The FreeBSD Foundation did an excellent job in this quarter, and many of their sponsored projects like VT-d and UEFI support, iSCSI stack, Capsicum, and auditdistd are about to complete. At the same time, new projects like Automounter and Intel GPU updates have just been launched. The Newcons project has been merged into -CURRENT, which will make it possible to finally move to the latest version of X.Org in the Ports Collection. Efforts are also under way to improve testing with Jenkins and Kyua. It is an exciting time for users and developers of FreeBSD! Thanks to all the reporters for the excellent work! This report contains 37 entries and we hope you enjoy reading it. The deadline for submissions covering between January and March 2014 is April 7th, 2014. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Cluster Administration Team * FreeBSD Core Team * FreeBSD Port Management Team * FreeBSD Postmaster Team * FreeBSD Release Engineering Team Projects * CBSD * Jenkins Continuous Integration for FreeBSD Kernel * GEOM Direct Dispatch and Fine-Grained CAM Locking * Intel 802.11n NIC (iwn(4)) Work * Intel GPU Driver Update * Native iSCSI Stack * New Automounter * UEFI Boot * UMA/ZFS and RPC/NFS Performance Improvements * Updated vt(9) System Console Architectures * FreeBSD Host Support for OpenStack and OpenContrail * FreeBSD on Cubieboard{1,2} * FreeBSD on Freescale i.MX6 processors * FreeBSD on Freescale Vybrid VF6xx * FreeBSD on Newer ARM Boards * FreeBSD/EC2 * FreeBSD/Xen * Intel IOMMU (VT-d, DMAR) Support Userland Programs * auditdistd(8) * Base GCC Updates * BSDInstall ZFSBoot * Capsicum and Casper * Centralized Panic Reporting * FreeBSD Test Suite * The LLDB Debugger Ports * FreeBSD Python Ports * GNOME/FreeBSD * KDE/FreeBSD * Wine/FreeBSD * X.Org on FreeBSD * Xfce/FreeBSD Miscellaneous * The FreeBSD Foundation __________________________________________________________________ FreeBSD Cluster Administration Team Contact: FreeBSD Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In the last quarter of 2013, they continued general maintenance of the FreeBSD cluster across all sites. In addition to general upkeep tasks, additional cluster-related items were addressed. Some of these items include: * Added several machines for the Kyua testing framework. * Replaced failed hardware hosting various web services. * Coordinated with the FreeBSD Security Officer and Ports Management Teams to implement signed binary packages. * Added the redports.org machines to the list of machines managed by the Cluster Administration Team. * Began discussion with contacts at Yandex regarding the addition of a mirror site for binary packages and Subversion repositories. __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. In the fourth quarter of 2013, the Core Team finally reached its previous goal of launching the official repositories for pkg(8)-based binary packages. The Core Team also unified the commit bit expiration policies for all Project repositories, allowing committers to idle for 18 months before their commit bits are automatically taken into safekeeping. This was then followed by an extension to suspension of cluster accounts for the committers who lost all of their commit bits. This helps to improve the security of the Project server cluster by temporarily disabling inactive accounts. In addition to the above efforts, Thomas Abthorpe resurrected the "Grim Reaper" service which helps to enforce the aforementioned policy. With the work of John Baldwin, Hiroki Sato, and others, many licenses in the base system source code have been revisited and cleaned up. Furthermore, the Core Team is hoping that the situation can be improved by introducing periodic automated checks of the license agreements, and by providing developers guidelines on questions of licensing. John Baldwin and David Chisnall have been guiding the work of the FreeBSD Graphics Team on moving to the newer version of X.Org and related software in the Ports Collection, in coordination with the switch to Newcons on FreeBSD 10.x. It was a busy quarter for the src repository as well. The Core Team was happy to welcome Jordan K. Hubbard (jkh) back who has recently returned to the FreeBSD business, and joined iXsystems as project manager and release engineer of FreeNAS. In addition to this, there were 3 commit bits offered for new developers, 2 committers were upgraded, 1 commit bit was taken for safekeeping, and 1 src bit was reactivated. __________________________________________________________________ FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en/articles/contributing-ports/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: FreeBSD Port Management Team The FreeBSD Ports collection is a package management system for the FreeBSD operating system, providing an easy and consistent way of installing software packages. The FreeBSD Ports Collection now contains approximately 24,500 ports, while the PR count exceeds 1,900. The FreeBSD Port Management Team ensures that the FreeBSD ports developer community provides a Ports Collection that is functional, stable, up-to-date and full-featured. Its secondary responsibility is to coordinate among the committers and developers who work on it. As part of these efforts, we added 3 new committers, took in 3 commit bits for safe keeping, and reinstated 1 commit bit in the fourth quarter of 2013. Ongoing effort went into testing larger changes, as many as 8 a week, including sweeping changes to the tree, moderization of the infrastructure, and basic quality assurance (QA) runs. Many iterations of tests against 10.0-RELEASE were run to ensure that the maximum number of packages would be available for the release. We now have pkg(8) packages for the releases 8.3, 8.4, 9.1, 9.2, 10.0 and -CURRENT on pkg.FreeBSD.org. During this same time, further enhancements were put into pkg(8), including secure package signing. Commencing November 1, the Port Management Team undertook a "portmgr-lurkers" pilot project in which ports committers could volunteer to assist the Port Management Team for a four-month duration. The first two candiates are Mathieu Arnold (mat) and Antoine Brodin (antoine). Ongoing maintenance goes into redports.org, including QAT runs, ports and security updates. Open tasks: 1. As previously noted, many PRs continue to languish; we would like to see some committers dedicate themselves to closing as many as possible! __________________________________________________________________ FreeBSD Postmaster Team URL: http://lists.freebsd.org/mailman/listinfo/svn-src-stable-10 URL: http://lists.freebsd.org/mailman/listinfo/ctm-src-10 URL: http://lists.freebsd.org/mailman/listinfo/ctm-src-10-fast URL: http://www.freebsd.org/doc/en/articles/committers-guide/pgpkeys.html Contact: FreeBSD Postmaster Team In the fourth quarter of 2013, the FreeBSD Postmaster Team has implemented the following items that may be interest of the general public: * Retired the freebsd-aic7xxx mailing list. * Created a graphics-team alias, requested by Niclas Zeising. * Worked with the FreeBSD Port Management Team to set up portmgr-lurkers so port managers can move addresses between those two aliases at their discretion. * Created the lists associated with the new stable/10 branch: svn-src-stable-10, ctm-src-10, and ctm-src-10-fast. * Redirected the vbox alias to the emulation list, requested by Bernhard Fr=C3=B6hlich. * Continued a discussion on current and possible future mail and spam filtering. * Disbanded lua and transferred it to Baptiste Daroussin, requested by Matthias Andree and Baptiste Daroussin. * Modified the list moderators/administrators for ports-secteam, requested by Dag-Erling Sm=C3=B8rgrav. * Assisted Warren Block with an update to the "OpenPGP Keys for FreeBSD" section of the Committer's Guide. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.FreeBSD.org/releases/10.0R/schedule.html URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/VM-IMAGES/ URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is finishing the 10.0-RELEASE cycle. The release cycle changed with two last-minute release candidate builds, each addressing fixes critical to include in the final release. The FreeBSD 10.0-RELEASE cycle is expected to be completed by mid-January, approximately eight weeks behind the original schedule. __________________________________________________________________ CBSD URL: http://www.bsdstore.ru/ URL: https://github.com/olevole/cbsd Contact: Oleg Ginzburg CBSD is another FreeBSD jail management solution, aimed at combining various features, such as racct(8), vnet, zfs(8), carp(4), and hastd(8), into a single tool. This provides a more comprehensive way to build application servers using pre-installed jails with a typical set of software, and requires minimal effort to configure. Open tasks: 1. Proper English translation of the website and the documentation. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: http://www.ixsystems.com/whats-new/jenkins-bhyve-and-webdriver-cont= inuous-integration-testing-on-freenas/ Contact: Craig Rodrigues At the November 2013 FreeBSD Vendor Summit, some of the work was presented that Craig Rodrigues has been doing with Continuous Integration and Testing at iXsystems. Craig's presentation described how iXsystems is using modern best practices for building and testing the FreeNAS code. Jenkins is a framework for doing continuous builds and integration that is used by hundreds of companies. BHyve (BSD Hypvervisor) is the new virtual machine system which will be part of FreeBSD 10. Webdriver is a Python toolkit for testing web applications. By combining these technologies, iXsystems is developing a modern and sophisticated workflow for testing and improving the quality of FreeNAS. Ed Maste from The FreeBSD Foundation was interested in this work, and based on this interest, it is now being ported to FreeBSD. Currently, a machine in the FreeBSD cluster has been allocated for this purpose, where a bhyve(4)-based virtual machine was set up and Jenkins was installed. The remainder is still in progress. Open tasks: 1. Finish setting up Jenkins. 2. Add more builds to Jenkins. 3. Integrate testing with Jenkins. __________________________________________________________________ GEOM Direct Dispatch and Fine-Grained CAM Locking URL: http://people.freebsd.org/~mav/disk.pdf URL: http://svnweb.freebsd.org/changeset/base/260387 URL: http://svnweb.freebsd.org/changeset/base/260385 Contact: Alexander Motin The CAM and GEOM multi-processor scalability improvement project has completed. The corresponding code has been committed to FreeBSD head and recently merged to the stable/10 branch; it shall appear in 10.1-RELEASE. As part of this project, cam(4) (the ATA/SCSI subsystem) has received more fine-grained locking for better utilization of multi-core systems. In addition, the locking in geom(4) (the block storage subsystem) has also been polished, and a new direct dispatch functionality was implemented to spread the load between multiple threads and processors, and reduce the number of context switches. Thanks to these cam(4) and geom(4) changes, the peak I/O rate has doubled on comptemporary hardware, reaching up to 1,000,000 IOPS! This project is sponsored by iXsystems, Inc. Open tasks: 1. Some CAM controller drivers (SIMs) could also be optimized to get more benefits from this project, utilizing the new locking models and direct command completions from multiple interrupt threads. __________________________________________________________________ Intel 802.11n NIC (iwn(4)) Work Contact: Adrian Chadd There has been a large amount of work on iwn(4) over the last six months: * New hardware support: 2xxx, 6xxx, 1xx series hardware. * Many bugs were fixed, including scanning, association, EAPOL related fixes. * iwn(4) now natively works with 802.11n rates from the net80211 rate control code, rather than mapping non-11n rates to 11n rates. Open tasks: 1. There are still some scan hangs, due to how net80211 scans a single channel at a time. This needs to be resolved. 2. The transmit, receive, scan and calibration code needs to be refactored out of if_iwn.c and into separate source files. 3. There still seem to be some issues surrounding 2 GHz versus 5 GHz association attempts leading to firmware assertions, especially on the Intel 4965 NIC. __________________________________________________________________ Intel GPU Driver Update Contact: Konstantin Belousov This project will update the Intel graphics chipset driver, i915kms, to a recent snapshot of the Linux upstream code. The update will provide at least 1.5 years of bugfixes from the Intel team, and introduce support for the newest hardware -- in particular Haswell and ValleyView. The IvyBridge code will also be updated. The addition of several features, which are required in order to update X.Org and Mesa, is also planned. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Native iSCSI Stack URL: https://wiki.freebsd.org/Native%20iSCSI%20target Contact: Edward Tomasz Napiera=C5=82a iSCSI is a popular block storage protocol. Under this project, a new, fast, and reliable kernel-based iSCSI initiator (client) and target (server) have been implemented. During October to December, the work focused on performance and scalability. The target and the initiator now spread the load over multiple kernel threads, and the locking is optimized to reduce contention. This makes better use of multiple processor cores. Work to finish iSER support is ongoing. All those optimizations will be gradually merged to head in February, and are expected to merged back to stable/10 and finally arrive in 10.1-RELEASE. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ New Automounter Contact: Edward Tomasz Napiera=C5=82a Research and prototyping has begun on a new project to implement autofs(4) -- an automounter filesystem -- and its userland counterpart, automountd(8). The idea is to provide a very similar user experience to the automounters available on Linux, MacOS X, and Solaris, including using the same map format. The automounter will also integrate with directory services, such as LDAP. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://svnweb.freebsd.org/base/projects/uefi/ Contact: Ed Maste The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 computers, and is a replacement for the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. In 2013, The FreeBSD Foundation sponsored Benno Rice for a short project to improve the UEFI bootloader. This resulted in a working proof-of-concept in the UEFI project branch, but it was not ready to be merged to FreeBSD head. Ed Maste has taken that original work and, with review feedback from Konstantin Belousov, been preparing it for integration into FreeBSD head. Some changes have been merged to head already. The rest will be merged as they are refined. Intel provided a motherboard and CPU for the project, which proved invaluable for addressing bugs that did not appear while testing with the QEMU emulator. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Resolve a 32- versus 64-bit libstand(3) build issue. 2. Merge kernel parsing of EFI memory map metadata. 3. Integrate the EFI framebuffer with vt(9) (also known as Newcons). 4. Connect efiloader to the build. 5. Document manual installation for dual-boot configurations. 6. Integrate UEFI configuration with the FreeBSD installer. 7. Support secure boot. __________________________________________________________________ UMA/ZFS and RPC/NFS Performance Improvements URL: http://docs.freebsd.org/cgi/mid.cgi?52894C92.60905 Contact: Alexander Motin The performance of ZFS and NFS was suboptimal in FreeBSD, so we have recently investigated some possible improvement paths. The uma(9) memory allocator caching code was improved to adapt better to system memory constraints. Combined with other virtual memory subsystem improvements done in the previous years, it should be safe to actively use uma(9) caches now. Their use in ZFS for ZIO/ARC may be enabled via the vfs.zfs.zio.use_uma loader(8) tunable, which is now the default for amd64, where it is recommended. Use of uma(9) caches for LZ4 compression buffers is unconditionally enabled on all architectures as it is has no serious drawbacks. On systems with many CPUs, these changes doubled the performance in the benchmarks. Several areas of the NFS server stack (RPC, FHA, DRC) got a number of fixes and performance optimizations that significantly improve performance and reduce the CPU usage in a number of tests. Together with the ZFS memory allocator changes mentioned above, it was possible to reach 200K NFS block read IOPS and 55K SPEC NFS IOPS. The code was committed to head. The uma(9) ZFS commits have been already merged to stable/10, and the remainder will be done soon as well. This project is sponsored by iXsystems, Inc. Open tasks: 1. The SPEC NFS test hits lock congestion on several global locks in the file system layer when a quite intensive READDIRPLUS NFS request is received. Fixing this problem could improve performance on large systems even further. __________________________________________________________________ Updated vt(9) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Colloquially known as Newcons, vt(9) is a modern replacement for the existing, quite old, virtual terminal emulator called syscons(4). Initially motivated by the lack of Unicode support in syscons(4), the project was later expanded to cover the new requirement to support Kernel Mode Switching (KMS). The project is now approaching completion and is ready for wider testing as the related code was already merged to FreeBSD head. Hence, vt(9) can be tested easily by replacing the following two lines in the kernel config file: device sc device vga with the following ones: device vt device vt_vga Major highlights: * Unicode support. * Double-width character support for CJK characters. * xterm(1)-like terminal emulation. * Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms). * Support for different fonts per terminal window. * Simplified drivers. Brief status of supported architectures and hardware: * amd64 (VGA/i915kms/radeonkms) -- works. * ARM framebuffer -- works. * i386 (VGA/i915kms/radeonkms) -- works. * IA64 -- untested. * MIPS -- untested. * PPC and PPC64 -- Works, but without X.Org yet. * SPARC -- works on certain hardware (e.g., Ultra 5). * vesa(4) -- in progress. * i386/amd64 nVidia driver -- need testing. * Xbox framebuffer driver -- need testing. Known Issues: * Switching to vty0 from X.Org on Fatal events will not work. * Certain hardware (e.g., Lenovo X220) get a black screen when i915kms is preloaded. * Scrolling can be slow; * Screen borders are not cleared when changing fonts. * vt(9) locks up with the gallant12x22 font in VirtualBox. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Create sub-directories for vt(9) under /usr/share/ to store key maps and fonts. 2. Implement remaining features supported by vidcontrol(1). 3. Write the vt(9) manual page. 4. Support keyboard handled directly by device kbd (without kbdmux(4)). 5. CJK fonts (in progress). __________________________________________________________________ FreeBSD Host Support for OpenStack and OpenContrail URL: http://www.openstack.org/ URL: http://www.opencontrail.org/ URL: https://github.com/Semihalf/openstack-devstack URL: https://github.com/Semihalf/openstack-nova URL: https://github.com/Semihalf/contrail-vrouter URL: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node Contact: Grzegorz Bernacki Contact: Micha=C5=82 Dubiel Contact: Rafa=C5=82 Jaworowski OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a data center. OpenContrail is a network virtualization (SDN) solution comprising a network controller, a virtual router, and an analytics engine, which can be integrated with cloud orchestration systems like OpenStack or CloudStack. The goal of this work is to enable FreeBSD as a fully supported compute host for OpenStack, using OpenContrail virtualized networking. The main areas of development are the following: * OpenStack compute driver (nova-compute) for the FreeBSD bhyve(4) hypervisor. * OpenContrail vRouter (forwarding-plane kernel module) port to FreeBSD. * Integration and performance optimizations. The current state of development features a working demo of OpenStack with compute node components running on a FreeBSD host: * The native bhyve(4) hypervisor is driven by a nova-compute component for spawning guest instances and a nova-network component for providing simple networking between those guests. * The nova-network approach (based on local host bridging) is becoming an obsolete technology in OpenStack and was used here only for demonstration and proof-of-concept purposes, without exploring all the possible features. * The main objective is to move to OpenContrail-based networking, therefore becoming compliant with the modern OpenStack networking API ("neutron"). This project is sponsored by Juniper Networks, Inc. Open tasks: 1. Decide how to integrate bhyve(4) with nova-compute, either natively or via the libvirt management layer. __________________________________________________________________ FreeBSD on Cubieboard{1,2} URL: https://github.com/tsgan/allwinner_a10/blob/master/if_emac.c Contact: Ganbold Tsagaankhuu Cubieboard is a single-board computer based on the AllWinner A10 SoC, popular on cheap tablets, phones and media PCs. The second version enhances the board mainly by replacing the AllWinner A10 SoC with an AllWinner A20 which contains 2 ARM Cortex-A7 MPCore CPUs and 2 Mali-400 GPUs (Mali-400MP2). In the last few months, work has continued on their FreeBSD port, and some work was done on the EMAC 10/100 Ethernet driver (see link). The driver is now in a good shape, however the RX side is very slow and there is need to have an external DMA driver that can be used in this case. __________________________________________________________________ FreeBSD on Freescale i.MX6 processors URL: http://lists.freebsd.org/pipermail/freebsd-arm/2013-November/006877= .html Contact: Ian Lepore The i.MX range is a family of Freescale Semiconductor proprietary microprocessors for multimedia applications based on the ARM architecture and focused on low-power consumption. The i.MX6x series is based on the ARM Cortex A9 solo, dual or quad cores. Initial support for them has been committed to head, and merged to stable/10. All members of the i.MX6 family (Solo, Dual, and Quad core) are supported, but SMP support on the multi-core SoCs has not yet been enabled. Initial driver support includes: * USB (EHCI) * Ethernet (Gigabit) * SD Card * UART The initial hardware bringup was done on Wandboard hardware, see the announcement on freebsd-arm in the links section for more information. Open tasks: 1. Write drivers for additional on-chip hardware, including I2C, SPI, AHCI, audio, and video. 2. Add support to FreeBSD-crochet script to generate Wandboard images __________________________________________________________________ FreeBSD on Freescale Vybrid VF6xx URL: http://svnweb.freebsd.org/changeset/base/258057 Contact: Ruslan Bukin Basic support for the Freescale Vybrid Family VF6xx heterogeneous ARM Cortex-A5/M4 System-on-Chip (SoC) was added to FreeBSD head. The Vybrid VF6xx family is an implementation of the new modern Cortex-A5-based low-power ARM SoC boards. Vybrid devices are ideal for applications including simple HMI in appliances and industrial machines, secure control of infrastructure and manufacturing equipment, energy conversion applications such as motor drives and power inverters, ruggedized wired and wireless connectivity, and control of mobile battery-operated systems such as robots and industrial vehicles. Supported device drivers: * NAND Flash Controller (NFC) * USB Enhanced Host Controller Interface (EHCI) * General-Purpose Input/Output (GPIO) * Universal Asynchronous Receiver/Transmitter (UART) Also supported: * Generic Interrupt Controller (GIC) * MPCore timer * ffec Ethernet driver Open tasks: 1. Add support for a number of different VF5xx- and VF6xx-based development boards. 2. Expand device driver support, including framebuffer and other devices. __________________________________________________________________ FreeBSD on Newer ARM Boards URL: https://wiki.freebsd.org/FreeBSD/arm/Radxa%20Rock URL: http://svnweb.freebsd.org/changeset/base/256949 URL: https://github.com/tsgan/qualcomm Contact: Ganbold Tsagaankhuu Rockchip is a series of SoC (System on Chip) integrated circuits that are mainly for embedded systems applications in mobile entertainment devices such as smartphones, tablets, e-books, set-top boxes, media players, personal video, and MP3 players. Due to their evolution from the MP3/MP4 player market, most Rockchip ICs feature advanced media decoding logic but lack integrated cellular radio basebands. Initial support for the Rockchip RK3188 (Quad core Cortex A9) SoC is committed to head. Now FreeBSD runs on Radxa Rock and it supports the following peripherals: * Existing DWC OTG driver in host mode * GPIO Some work was also done on initial support for the Qualcomm Snapdragon S4 SoC, featuring the Krait CPU, which is considered a "platform" for use in smartphones, tablets, and smartbook devices. Krait has many similarities with the ARM Cortex-A15 CPU and is also based on the ARMv7 instruction set. A minimal console driver was written, and FreeBSD's early boot messages can be now seen on the serial console. The timer driver works too, and the boot now stops at the mountroot prompt. __________________________________________________________________ FreeBSD/EC2 URL: http://www.daemonology.net/freebsd-on-ec2/ URL: http://www.daemonology.net/blog/2013-12-09-FreeBSD-EC2-configinit.h= tml Contact: Colin Percival An Amazon Machine Image (AMI) is a special type of virtual appliance that is used to create a virtual machine within the Amazon Elastic Compute Cloud ("EC2"). It serves as the basic unit of deployment for services delivered using EC2. Such AMIs are available for 8.3-RELEASE and later FreeBSD releases, and every ALPHA, BETA, and RC of FreeBSD 10.0. Starting from FreeBSD 10.0-BETA1, FreeBSD/EC2 images are running "fully supported" FreeBSD binaries, and starting from FreeBSD 10.0-RC1, FreeBSD/EC2 images include a "configinit" system for autoconfiguration using EC2 user-data. Due to limitations of old (m1, m2, c1, t1) instance types, "Windows"-labelled images are required for those instance types; however all of the recent instances types -- m3 (general purpose), c3 (high-CPU), and i2 (high-I/O) -- support FreeBSD at the "unix" pricing rates. The maintainer of this platform considers it to be ready for production use. Open tasks: 1. Hand over the task of building FreeBSD AMIs to the Release Engineering Team. 2. Get Amazon to add "FreeBSD" to the list of platforms supported by EC2, so that it can stop showing up as "Other Linux". __________________________________________________________________ FreeBSD/Xen URL: http://wiki.xen.org/wiki/FreeBSD_PVH Contact: Roger Pau Monn=C3=A9 Contact: Justin T. Gibbs Xen is a native (bare-metal) hypervisor providing services that allow multiple computer operating systems to execute on the same computer hardware concurrently. Xen 4.4 will bring a virtualization mode called PVH -- PV (paravirtualization) in an HVM (fully-virtual) container. This is essentially a paravirtualized guest using paravirtualized drivers for boot and I/O. Otherwise it uses hardware virtualization extensions, without the need for emulation. After merging the changes in order to improve Xen PVHVM support, work has shifted on getting PVH DomU support on FreeBSD. Patches have been posted, and after a couple of rounds of review the series looks almost ready for merging into head. Also, very initial patches for FreeBSD PVH Dom0 support has been posted. So far the posted series only focuses on getting FreeBSD booting as a Dom0 and being able to interact with the hardware. This project is sponsored by Citrix Systems R&D, and Spectra Logic Corporation. Open tasks: 1. Finish reviewing and commit the PVH DomU support. 2. Work on PVH Dom0 support. __________________________________________________________________ Intel IOMMU (VT-d, DMAR) Support URL: http://svnweb.freebsd.org/changeset/base/257251 URL: http://svnweb.freebsd.org/changeset/base/259512 Contact: Konstantin Belousov An Input/Output Memory Management Unit (IOMMU) is a Memory Management Unit (MMU) that connects a Direct Memory Access-capable (DMA-capable) I/O bus to main memory; therefore, I/O virtualization is performed by the chipset. An example IOMMU is the graphics address remapping table (GART) used by AGP and PCI Express graphics cards. Intel has published a specification for IOMMU technology as Virtualization Technology for Directed I/O, abbreviated VT-d. A VT-d driver was committed to head and stable/10, so busdma(9) is now able to utilize VT-d. The feature is disabled by default, but it may be enabled via the hw.dmar.enable loader(8) tunable -- see the links for more information. The immediate plans include increasing the support for this kind of hardware by testing and providing workarounds for specific issues, and by adding features of the next generation of Intel IOMMU. Hopefully, the existing and new consumers of VT-d will start to use the driver soon. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ auditdistd(8) Contact: Pawel Jakub Dawidek The auditdistd(8) daemon is responsible for distributing audit trail files over TCP/IP network securely and reliably. Currently, the daemon uses Transport Layer Security (TLS) for communication, but only server-side certificates are verified, based on the certificate's fingerprint. The ongoing work will make it possible to use client-side certificates and will support more complete public-key infastructure, which includes validation of the entire certificate chain, including revocation checking against Certification Revocation Lists at every level. From now on, auditdistd(8) will support TLSv1.2 and PFS modes only. In addition, it will be possible to send audit trail files to multiple receivers. The work will be completed at the beginning of February 2014. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Base GCC Updates Contact: Pedro Giffuni The GCC compiler in the FreeBSD base system is on its way to deprecation and is only used by some Tier-2 platforms at this time. While Clang is much better in many aspects, we still cannot use in the base system all the new features that it brings until we can drop GCC completely. As a stop-gap solution, several bug fixes and features from Apple GCC and other sources have been ported to our version of GCC 4.2.1 to make it more compatible with Clang. FreeBSD's GCC has added more warnings and some enhancements like -Wmost and -Wnewline-eof. An implementation for Apple's blocks extension is now available, too, and it will be very useful to enhance FreeBSD's support for Apple's Grand Central Dispatch (GCD). Open tasks: 1. A merge from head to stable/9 is being considered but it disables nested functions by default, so the impact on the Ports Collection needs to be evaluated. 2. No further development of GCC 4.2 in the base system is planned. __________________________________________________________________ BSDInstall ZFSBoot URL: http://lists.freebsd.org/mailman/listinfo/freebsd-sysinstall URL: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE Contact: Allan Jude Contact: Devin Teske Contact: Warren Block BSDInstall has been the default installation program since FreeBSD 9.0-RELEASE. However, it could not utilize one of the best features of FreeBSD, ZFS. The ZFSBoot project started at EuroBSDCon 2013 and reached stable status in December, just in time for FreeBSD 10.0-RELEASE. Currently, ZFSBoot implements root-on-ZFS with 4k partition alignment, optional forced 4k sectors, optional geli(8) full disk encryption, and support for boot environments. As part of ZFSBoot, BSDInstall itself also received a number of updates, including enhanced debugging, more scriptability, a new keymap selection menu, and a number of other small changes to streamline the installation process. The new keymap menu allows the user to test the selected keymap before continuing, to ensure it is the desired keymap. Minor changes were made to the network configuration dialogues to make the identification of wireless interfaces easier. A number of additional features are also planned. The user should be able to create additional datasets and adjust the properties on all datasets in an interactive menu. There should also be integration with BSDConfig to allow users to install packages and the various other functionality that was previously provided by sysinstall. Open tasks: 1. Interactive dataset editor. 2. Dataset property editor. 3. Consider using shell geom(4) parser. 4. BSDConfig integration. 5. UFS as a file system option, to allow users to create encrypted UFS installs. 6. Optionally make the boot pool UFS or reside on USB device(s). 7. Further streamline the installation process. __________________________________________________________________ Capsicum and Casper URL: http://freebsdfoundation.blogspot.com/2013/12/freebsd-foundation-an= nounces-capsicum.html Contact: Pawel Jakub Dawidek Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model. The Casper daemon enables sandboxed application to use functionality normally unavailable in capability-mode sandboxes. The Casper daemon, libcasper, libcapsicum(3), libnv(3) and Casper services (system.dns, system.grp, system.pwd, system.random and system.sysctl) have been committed to FreeBSD head. The tcpdump(8) utility in head now uses the system.dns service to do DNS lookups. The kdump(1) utility in head now uses the system.pwd and system.grp services to convert user and group identifiers to user and group names. There is ongoing work to sandbox more applications. If you are interested in helping to make FreeBSD more secure and would like to learn about Capsicum and Casper, do not hesitate to contact Pawel -- he can provide candidate programs that could use sandboxing. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Centralized Panic Reporting URL: http://www.daemonology.net/blog/2013-11-06-automated-freebsd-panic-= reporting.html Contact: Colin Percival With the sysutils/panicmail port, a mechanism is now in place for automated submission of kernel panic reports to a central location. It is hoped that this will prove useful, as similar systems have for other operating systems, in identifying common panics so that developers can be alerted and they can be fixed faster. In the first two months that this mechanism has been in place, 28 kernel panics have been reported. This is nowhere near enough to be useful, so readers are strongly encouraged to install the sysutils/panicmail port and follow the instructions to enable it. Open tasks: 1. Get more systems set up to automatically submit panic reports! __________________________________________________________________ FreeBSD Test Suite URL: http://wiki.FreeBSD.org/TestSuite URL: http://kyua1.nyi.FreeBSD.org/ URL: http://lists.freebsd.org/pipermail/freebsd-testing/2013-December/00= 0109.html URL: http://julipedia.meroh.net/2013/12/introducing-freebsd-test-suite.h= tml Contact: Julio Merino The FreeBSD Test Suite project aims to equip FreeBSD with a comprehensive test suite that is easy to run out of the box and during the development of the system. The test suite is installed into /usr/tests/ and the kyua(1) command-line tool (devel/kyua in the Ports Collection) is used to run them. The benefits of having a test suite that is easy to use and continuously run are obvious: regressions can be caught sooner rather than later and the Release Engineering Team can better assess the quality of the tree before deciding to cut a release. Additionally, because we choose to install the tests, we allow any end user to perform sanity checks on new installations of the system on their particular hardware configuration -- a very attractive thing to do when deploying production servers. During the last few months, we have added the necessary pieces to the build system to support building and installing test programs of various kinds. To demonstrate the functionality of these, some test programs were added and others were migrated from the old testing tree in tools/regression/ to the new layout for tests. The current test suite should be seen as a proof of concept at this point: it is only composed of a small set of test programs and the goal is to get the infrastructure in place before mass-migrating existing test code and/or importing external tests. As part of this work, two new releases of Kyua were published. Of special interest is the addition of a TAP-compliant backend so that existing tests from tools/regression/ can be plugged into the test suite with minimum effort. As of December 31st, the basic continuous testing infrastructure is up and running, see the links section for the home page. For further information, please see the related announcement and blog post on the subject (also in the links section). Open tasks: 1. We have three machines for the test cluster. At the moment, only one of them is in use to continuously test amd64 on both head and stable/10. We need to figure out the right level of parallelization to put other machines to use -- but a first easy cut may be to just test different architectures (with the help of QEMU). 2. Related to the above, the Kyua reporting engine needs significant tuning to make the reports nice and clean. Ideally, Kyua should be able to coalesce results from different runs into a single location and generate cohesive reports out of them. Fixing this is a high priority. 3. A tutorial on writing tests for FreeBSD has been proposed for AsiaBSDCon 2014. The outcome of the proposal is still unknown, but stay tuned! 4. Port, port, and port more tests to the new test suite. A test suite is worthless if it does not validate stuff. Stay tuned for a request for help once we have put all basic pieces in place and have streamlined the migration process. __________________________________________________________________ The LLDB Debugger URL: https://wiki.freebsd.org/lldb Contact: Ed Maste LLDB is the debugger in the LLVM family of projects. It supports Mac OS X, Linux, and FreeBSD, with ongoing work to support Windows. In the last quarter of 2013, LLDB gained support for live (ptrace(2)-based) debugging of multithreaded processes on FreeBSD. Initial FreeBSD MIPS target support has also been committed, along with a number of endianness fixes in the general LLDB infrastructure. The LLDB snapshot in the FreeBSD tree was updated to r196322. Currently disabled by default, it will be enabled for amd64 after the import of Clang 3.4. In the interim, it may be enabled by adding WITH_LLDB=3D to src.conf(5). This project is sponsored by DARPA/AFRL, SRI International, and University of Cambridge. Open tasks: 1. Update the in-tree snapshot to build after the Clang 3.4 import. 2. Fix amd64 watchpoints. 3. Test and fix the i386 port. 4. Implement FreeBSD ARM support. 5. Add support for kernel debugging (live local and remote debugging, and core files). 6. Fix the remaining test suite failures. 7. Enable by default on the amd64 architecture. __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team Python is a widely used general-purpose, high-level programming language. For many operating systems, Python is a standard component; it ships with FreeBSD as well. A lot of progress has been made around the FreeBSD Python ports in the last quarter. The devel/py-distribute port has been replaced by the refreshed devel/py-setuptools port, which comes with a lot of features that simplify the ways of installing Python packages. The change also led us to install everything through Setuptools now, which resembles a PyIP a bit and allows us to perform some major cleanup on the distutils installation behaviour. The implicit lang/python build and run-time dependency was removed from the ports infrastructure. Every port now depends on a specific Python version or on the lang/python metaport. This prevents compatibility issues for ports that depend on Python 2.x OR Python 3.x exclusively, but use the python command, which might point to a version of incompatible user choice. The lang/python27 port was updated to version 2.7.6, and the lang/python33 port was updated to version 3.3.3, and the lang/pypy port was updated to version 2.2.1. We are currently working on the necessary infrastructure quirks to support different Python versions for the same port. Most of the work has been done and needs to be tested before it can be integrated. Open tasks: 1. Develop a high-level and lightweight Python Ports Policy. 2. Add support for granular dependencies (for example >=3D1.0 or <2.0). 3. Look at what adding pip support looks like. 4. Convert all USE_PYDISTUTILS=3Deasy_install entries to yes and remove the use of easy_install from the ports infrastructure. 5. More tasks can be found on the team's wiki page (see links). __________________________________________________________________ GNOME/FreeBSD URL: http://www.FreeBSD.org/gnome/ URL: http://svnweb.freebsd.org/changeset/ports/334661 Contact: FreeBSD GNOME Team GNOME is a desktop environment and graphical user interface that runs on top of a computer operating system. GNOME is part of the GNU Project and can be used with various Unix-like operating systems, including FreeBSD. In this quarter, MATE 1.6 was finally imported into the Ports Collection, thanks to the efforts of Jeremy Messenger. MATE is a desktop environment forked from the now-unmaintained code base of GNOME 2, therefore it is basically a replacement for GNOME 2. It recommended for users wanting to keep GNOME 2 as their desktop to switch since GNOME 2 will be replaced by GNOME 3 in the near future. This switch will be announced in advance, so people will have time to move to MATE if they have not already. The complete MATE-based desktop environment can be installed via the x11/mate port, or, for a minimal install, x11/mate-base. Our home page is quite out of date. An update for it for GNOME 3.6 is underway. Part of this update is rewriting and updating the old GNOME porting guide as a chapter of the Porter's Handbook. Another major task required for getting a bleeding-edge GNOME to build on FreeBSD mostly out-of-the box is moving to JHbuild with some custom rules. This is done to find and fix compile issues on other BSDs more quickly. Open tasks: 1. GNOME 2 ports still need to be sorted out to evaluate which GNOME 2 components will be gone or be replaced with their newer GNOME 3 versions. This task is current halted until we can get the documentation into a shape good enough to gather the issues and document the migration, including how to avoid the migration if the upgrade is not preferred. (This does not mean we do not want to know about issues with upgrading, though). 2. Help the X11 Team with Cairo 1.12, since the next version of GNOME 3 (3.12) will need an up-to-date version of Pango and GTK 3. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php URL: http://portscout.freebsd.org/kde@freebsd.org.html Contact: KDE FreeBSD Team KDE is an international free software community producing an integrated set of cross-platform applications designed to run on Linux, FreeBSD, Solaris, Microsoft Windows, and OS X systems. The KDE/FreeBSD Team have continued to improve the experience of KDE software and Qt under FreeBSD. During last quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC (area51): 4.11.2, 4.11.3, 4.11.4 * Qt: 4.8.5 and 5.2 (area51) * PyQt: 4.10.3; SIP: 4.15.2; QScintilla2: 2.8 * Qt Creator 2.8.0 * KDevelop: 4.5.2 * Calligra: 2.7.5 * CMake: 2.8.12, 2.8.12.1 As a result, according to PortScout, our team has 464 ports (down from 473), of which 88.15% are up-to-date (down from 98.73%). iXsystems Inc. continues to provide a machine for the team to build packages and to test updates. iXsystems Inc. has been providing the KDE/FreeBSD Team with support for quite a long time and we are very grateful for that. As usual, the team is always looking for more testers and porters so please contact us or visit our home page (see links). It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface. Open tasks: 1. Update out-of-date ports, see links for a list. 2. Worke on KDE 4.12 and Qt 5. 3. Make sure the whole KDE stack (including Qt) builds and works correctly with Clang and libc++. 4. Remove the dependency on HAL. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org/ Contact: Gerald Pfeiffer Contact: David Naylor Wine is a free and open source software application that aims to allow applications designed for Microsoft Windows to run on Unix-like operating systems, such as FreeBSD. The Wine/FreeBSD Team have continued to improve the experience of Wine under FreeBSD. During the fourth quarter of 2013, the team has kept Wine updated by porting: * Stable releases: 1.6 and 1.6.1 * Development releases: 1.7.4 through 1.7.8 The ports have included packages built for amd64 (available through the Ports Collection). The Wine ports have been kept up-to-date with the changes in the Ports Collection, including some improvements: * Building with Clang by default (via USES=3Dcompiler:c11). * Conditional X11 support (on by default; allowing for headless instances of Wine). * Staging support and other ports best practices. Support in improving the experience of Wine on FreeBSD is needed. Key areas including fixing regressions, adding copy protection scheme support and fixing regressions when using Wine under FreeBSD/amd64. Open tasks: 1. Open Tasks and Known Problems (see links for the wiki page). 2. FreeBSD/amd64 integration (see links for the i386-Wine wiki page). 3. Porting WoW64 and Wine64. __________________________________________________________________ X.Org on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://trillian.chruetertee.ch/ports/browser/trunk URL: http://lists.freebsd.org/pipermail/freebsd-x11/2014-January/014003.= html Contact: FreeBSD X11 Team The newer graphics stack (WITH_NEW_XORG) is now built by default on head and is provided as binary packages from the official FreeBSD pkg(8) repository for 11-CURRENT. The major updates are: * X.Org server 1.12. * Mesa 9.1. * Recent Intel and Radeon X.Org drivers, using exclusively the KMS kernel drivers available in FreeBSD 9.x (Intel) and FreeBSD 10.x (Radeon). This change makes X.Org on FreeBSD head work out-of-the-box on workstations and laptops based on recent Intel and Radeon GPUs. FreeBSD 10.x will follow in a few weeks or months. Some software has started to require Cairo 1.12, for example GTK+ 3.10 and Pango. Unfortunately, this version of Cairo triggers a bug in the old Intel driver (2.7.1, installed when WITH_NEW_XORG is not set), which causes display artifacts. A "Call For Testers" mail was posted on the freebsd-x11 mailing-list (see the links above) to gather information about the behavior on other configurations (new Intel driver and non-Intel drivers). As of this writing, the reports received talk about improvements or, at least, no change noticed. To better manage changes such as the WITH_NEW_XORG and Cairo 1.12 changes mentioned above, we asked on the freebsd-x11 mailing-list if people are using FreeBSD 8.x on their desktop computers and why they do not upgrade to FreeBSD 9.x or 10.x. So far, we received very few answers to this. The Radeon KMS driver in FreeBSD 10.x is now considered stable, especially that integrated GPUs are now properly initialized. One of the next steps will be to merge this to stable/9. A "Graphics" wiki article (see links) was created to centralize and coordinate the work being done on both the ports and the kernel. It contains the following important information: * A roadmap of the team. * A matrix of supported hardware. * Instructions on upgrading to KMS. * Project status and results. This starting page then points to project- and topic-specific articles where more detailed information is available. Open tasks: 1. Report why FreeBSD 8.x is still used on your desktop and why moving to FreeBSD 9.x or 10.x is not an option. 2. Report about the Cairo 1.12 update on your system. 3. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Xfce/FreeBSD URL: https://wiki.freebsd.org/Xfce URL: https://people.freebsd.org/~olivierd/xfce-core-unstable.html URL: https://people.freebsd.org/~olivierd/parole-unstable.html Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. The FreeBSD Xfce Team has kept most of the Xfce ports up-to-date, while fixing many issues along the way in this quarter. Currently, the following components with the following versions are available: Applications: * Orage (4.10.0) * Midori (0.5.6) * xfce4-terminal (0.6.3) * xfce4-parole (0.5.3, 0.5.4) Panel plugins: * xfce4-whiskermenu-plugin (1.2.0, 1.2.1, 1.2.2, 1.3.0) * xfce4-mailwatch-plugin (1.2.0) * xfce4-wmdock-plugin (0.6.0) We helped Midori's upstream switch from Waf (Python script) to CMake. Xfce now also supports Gtk2, Gtk3, and the new WebKitGtk API, available from the 2.x branch, not present in our ports tree at the moment, though. Most of the ports now use stage directories, with only some plugins left to convert. We also removed obsolete ports: * x11-themes/lila-xfwm4 (Xfwm4 theme) * multimedia/xfce4-media (multimedia player) * net-im/xfce4-messenger-plugin Besides, we followed the development of the Xfce core components and Parole closely. See the links for documentation on how to upgrade those libraries. Open tasks: 1. Fix Midori's build on DragonFly, through DPorts. 2. Fix build of the Granite framework (it is an extension to Gtk and Midori uses it) on FreeBSD 10 and head. Those are mostly LLVM failures. 3. Add support for Berkeley DB 5 and higher to Orage. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://www.freebsdfoundation.org/press/2013Dec-newsletter URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We held our year-end fundraising campaign. We are still processing donations and will post the final numbers by mid-January. We are extremely grateful to all the individuals and organizations that supported us and the Project by making a donation in 2013. We have already started our fundraising efforts for 2014. Some of the highlights from this past quarter include: * We sponsored or are sponsoring the following projects: + Projects completed last quarter: Capsicum, Casper daemon, and Intel I/O Memory Management Unit driver. + Projects in progress: Native in-kernel iSCSI stack, network stack layer 2 modernization, UEFI boot, updated vt(9) system console. + Projects started last quarter: Automounter, Intel graphics driver update. * Continued work on the FreeBSD Journal, our new online FreeBSD magazine, which debuts on January 27th (see links). * Sponsored, organized, and ran the Bay Area Developer Summit. * Sponsored and attended the first ever vBSDCon, which had an impressive attendance. * Sponsored and attended the OpenZFS developer summit. * Represented the foundation at the following conferences: All Things Open in Raleigh, NC and LISA in Washington, DC. * Sponsored the FreeBSD 20th Birthday Party, held in San Francisco. * Attended the ICANN meeting in Buenos Aires in November and gave a short presentation on the change from BIND to unbound in FreeBSD 10.0 during the ccNSO Tech Day. * Met with a few companies to discuss their FreeBSD use, what they would like to see supported in FreeBSD, and assist with collaboration between them and the Project. * Purchased an 80-core server to reside at Sentex for the Project to use for stability, scalability, and performance improvements. It is a big step forwards for the Foundation in providing this kind of hardware to the Project's developers. It will let us test our scaling to 80 simultaneous cores and 1 TB of RAM. It will also be used to do performance analysis on large workloads, such as large databases etc. * Acquired a second rack to use at Sentex. * We received a commitment from VMware, Inc. for BSD-licensed drivers. They also committed to a yearly silver level donation. * Signed up as a Google Compute trusted tester for the Project. * Funded a project to produce a white paper titled "Managed Services Using FreeBSD at NYI". * Finally, we published our semi-annual newsletter (see links) highlighting what we did to support the FreeBSD Project and Community in 2013. __________________________________________________________________ Love FreeBSD? Support the development with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/