From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 07:30:51 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 2FEAE256; Sun, 6 Oct 2013 07:30:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 46B442C09; Sun, 6 Oct 2013 07:30:50 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id e53so2611084eek.13 for ; Sun, 06 Oct 2013 00:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aEAivdcImJx+yXZI5NuiWTYkGe49ecX2SIFKvkhmty4=; b=WTTPkWUGjjMcV/bRX+SexY5dQnvUyNu9KLmpcu9rMwlLyv1kv97pWT1OLOOKpOdTn4 QPTY14AsZt8qAXxVvWshXTTQtJ2Gyn5rd/HXhwUKjup6CKx9GqtA+/18QCAI5iNs5Ky+ q/kiOiqIwauSh6osx3JUc4J9LJKaVsa/LoTZhGhJNCnRKLDn/TYmnDYL+yz8/XRlNSXR FktfHaKSiaRKpV/UT7teb3HA7lYhgQ6dMXjHwLFPvIVUIDp2BX344a1irStjc/udZomn OaiagxOFiZyoO8vJOnHU9KOguY26lf2soDNBuj0SYZ+Mylm6O70Z2TN2SBe81iQ3jDMG X9VA== X-Received: by 10.15.43.13 with SMTP id w13mr37255953eev.37.1381044647533; Sun, 06 Oct 2013 00:30:47 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id v8sm48252297eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 00:30:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <525111A2.1020106@FreeBSD.org> Date: Sun, 06 Oct 2013 10:30:42 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <5224511D.4090503@FreeBSD.org> <20130906230236.GI43281@caravan.chchile.org> <522AC88D.4070005@FreeBSD.org> <201310021330.23251.jhb@freebsd.org> In-Reply-To: <201310021330.23251.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 07:30:51 -0000 On 02.10.2013 20:30, John Baldwin wrote: > On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: >> On 07.09.2013 02:02, Jeremie Le Hen wrote: >>> On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: >>>> On 06.09.2013 11:06, Jeremie Le Hen wrote: >>>>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote: >>>>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin > wrote: >>>>>>> I've found and fixed possible double request completion, that could > cause >>>>>>> such symptoms if happened. Updated patch located as usual: >>>>>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch >>>>>>> >>>>> With this new one I cannot boot any more (I also updated the source >>>>> tree). This is a hand transcripted version: >>>>> >>>>> Trying to mount root from zfs:zroot/root []... >>>>> panic: Batch flag already set >>>>> cpuid = 1 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() >>>>> kdb_backtrace() >>>>> vpanic() >>>>> kassert_panic() >>>>> xpt_batch_start() >>>>> ata_interrupt() >>>>> softclock_call_cc() >>>>> softclock() >>>>> ithread_loop() >>>>> fork_exit() >>>>> fork_trampoline() >>>> >>>> Thank you for the report. I see my fault. It is probably specific to >>>> ata(4) driver only. I've workarounded that in new patch version, but >>>> probably that area needs some rethinking. >>>> >>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch >>> >>> I'm not sure you needed a confirmation, but it boots. Thanks :). >>> >>> I didn't quite understand the thread; is direct dispatch enabled for >>> amd64? ISTR you said only i386 but someone else posted the macro for >>> amd64. >> >> Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64. > > FYI, I tested mfi with this patch set and mfid worked fine for handling g_up > directly: > > Index: dev/mfi/mfi_disk.c > =================================================================== > --- dev/mfi/mfi_disk.c (revision 257407) > +++ dev/mfi/mfi_disk.c (working copy) > @@ -162,6 +162,7 @@ > sc->ld_disk->d_unit = sc->ld_unit; > sc->ld_disk->d_sectorsize = secsize; > sc->ld_disk->d_mediasize = sectors * secsize; > + sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION; > if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) { > sc->ld_disk->d_fwheads = 255; > sc->ld_disk->d_fwsectors = 63; > Thank you for the feedback. But looking on mfi driver sources I would say that it calls biodone() from mfi_disk_complete() from cm_complete() method, which is called while holding mfi_io_lock mutex. I guess that if on top of mfi device would be some GEOM class, supporting direct dispatch and sending new requests down on previous request completion (or retrying requests), that could cause recursive mfi_io_lock acquisition. That is exactly the cause why I've added this flag. May be it is a bit paranoid, but it is better to be safe then sorry. Another good reason to drop the lock before calling biodone() would be reducing the lock hold time. Otherwise it may just increase lock congestion there and destroy all benefits of the direct dispatch. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 13:44:52 2013 Return-Path: Delivered-To: current@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 ESMTP id A4A3F271 for ; Sun, 6 Oct 2013 13:44:52 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 26F8F2AA4 for ; Sun, 6 Oct 2013 13:44:51 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBE2C9.dip0.t-ipconnect.de [217.251.226.201]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r96DihjL082189 for ; Sun, 6 Oct 2013 13:44:43 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r96DiRMd026177 for ; Sun, 6 Oct 2013 15:44:27 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r96DiLnN059117 for ; Sun, 6 Oct 2013 15:44:27 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310061344.r96DiLnN059117@fire.js.berklix.net> To: current@freebsd.org Subject: lock order reversals on 10.0-ALPHA4 From: "Julian H. Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Sun, 06 Oct 2013 15:44:21 +0200 Sender: jhs@berklix.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 13:44:52 -0000 With: FreeBSD lapr.js.berklix.net 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 r255933: Sun Sep 29 02:50:54 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 At boot dmesg shows several lock order reversals, eg ------ Trying to mount root from ufs:/dev/ad4s2a [rw]... ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled lock order reversal: 1st 0xfffffe00a6e26b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 2nd 0xfffff80005cf8400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c8f3d3f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00c8f3d4a0 witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe00c8f3d530 _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe00c8f3d570 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfffffe00c8f3d5b0 ufs_direnter() at ufs_direnter+0x688/frame 0xfffffe00c8f3d670 ufs_makeinode() at ufs_makeinode+0x573/frame 0xfffffe00c8f3d830 ufs_symlink() at ufs_symlink+0x32/frame 0xfffffe00c8f3d880 VOP_SYMLINK_APV() at VOP_SYMLINK_APV+0xf0/frame 0xfffffe00c8f3d8b0 kern_symlinkat() at kern_symlinkat+0x23e/frame 0xfffffe00c8f3dae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe00c8f3dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00c8f3dbf0 --- syscall (57, FreeBSD ELF64, sys_symlink), rip = 0x800888ffa, rsp = 0x7fffffffca58, rbp = 0x7fffffffdc10 --- lock order reversal: 1st 0xfffff800881b9d50 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851 2nd 0xfffff800881b99a0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c8ed93d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00c8ed9480 witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe00c8ed9510 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe00c8ed9640 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe00c8ed9660 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe00c8ed9690 _vn_lock() at _vn_lock+0xab/frame 0xfffffe00c8ed9700 vget() at vget+0x70/frame 0xfffffe00c8ed9750 devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe00c8ed97a0 devfs_root() at devfs_root+0x43/frame 0xfffffe00c8ed97d0 vfs_donmount() at vfs_donmount+0x115e/frame 0xfffffe00c8ed9aa0 sys_nmount() at sys_nmount+0x72/frame 0xfffffe00c8ed9ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe00c8ed9bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00c8ed9bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a9dd7a, rsp = 0x7fffffffccb8, rbp = 0x7fffffffd220 --- ---- It comes up multi user OK, Do you already have enough lock order reversal to work on, or do you want me to run diagnostics ? what ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 15:22:09 2013 Return-Path: Delivered-To: current@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 ESMTP id 7350BAD1; Sun, 6 Oct 2013 15:22:09 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 F0DAC2FBA; Sun, 6 Oct 2013 15:22:08 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBFF7C.dip0.t-ipconnect.de [93.203.255.124]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r96FM6q9084916; Sun, 6 Oct 2013 15:22:06 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r96FLscY026762; Sun, 6 Oct 2013 17:21:55 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r96FLmxw077281; Sun, 6 Oct 2013 17:21:54 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310061521.r96FLmxw077281@fire.js.berklix.net> Subject: Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 03 Oct 2013 23:28:43 +0200." <201310032128.r93LShdV030701@fire.js.berklix.net> Date: Sun, 06 Oct 2013 17:21:48 +0200 Sender: jhs@berklix.com Cc: Rui Paulo , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 15:22:09 -0000 I wrote Thu, 03 Oct 2013 23:28:43 +0200 > Rui Paulo wrote: > > > > On 2 Oct 2013, at 16:57, Julian H. Stacey wrote: > > > > > Hi current@, > > > It seems I need if_urtwn driver for a really miniature WLAN USB stick, > > > & if_urtwn is only in current ? > > > man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ? > > > > > > This driver was never merged to FreeBSD 9. > > OK, Thanks for confirmation. > > > > Can you use FreeBSD 10 instead? > > Yes, easier than building from 9.X I guess (& helps test alpha :-). > I'll fetch from local mirror, per > http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html > > > > The port reference in the man page is wrong. The firmware is now shipped as part of the base system. > > Oh nice, easier :-) I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load="YES" `ifconfig wlan0 scan` works OK. Thanks :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 15:22:29 2013 Return-Path: Delivered-To: current@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 ESMTP id 91E30CB9 for ; Sun, 6 Oct 2013 15:22:29 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53C0B2FCA for ; Sun, 6 Oct 2013 15:22:29 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id x12so4075919qcv.22 for ; Sun, 06 Oct 2013 08:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=u1DJ9OLMUNhSPTKXdHuxHwCLleeAFtRYcPNYORBVN0o=; b=VMgacoi0zTI0As/w7Ef3NW1gsjiF64AJ+/JZ7tiQZaUpdfnNDzSsyuKs1G7+qBlqMO CBqwuUmXxy/RsQeoj6ijFHUKB0PtO+TSNPJyEQUcGdofaXwa0obwhCh8kAmkICQw/EQR KcKOtj3Tgbz2D9gb3OXHkzb7Olm6ObZSK2TKB1UvZzZRKPzmUH8Jx9cZZRg1BB4l6mwH 6wXBsaqcrWx4X8iaPOQWWyzveYlEGs9M3GhX04ci2GvcRmCuS1qJ9wWTUFXDwimkbVew drsVzCNGP8itcxQddbXK+X4kOKs0EKSvTgmHALD7Kisl88cbkAjEhw0RI8mSH6g7Qbnw tbGQ== MIME-Version: 1.0 X-Received: by 10.224.8.10 with SMTP id f10mr31611773qaf.29.1381072947978; Sun, 06 Oct 2013 08:22:27 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.225.129 with HTTP; Sun, 6 Oct 2013 08:22:27 -0700 (PDT) In-Reply-To: <201310061344.r96DiLnN059117@fire.js.berklix.net> References: <201310061344.r96DiLnN059117@fire.js.berklix.net> Date: Sun, 6 Oct 2013 08:22:27 -0700 X-Google-Sender-Auth: PMESMKChRqabFFxaMMzHB9LNIRI Message-ID: Subject: Re: lock order reversals on 10.0-ALPHA4 From: Matthew Fleming To: "Julian H. Stacey" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "current@freebsd.org Current" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 15:22:29 -0000 On Sun, Oct 6, 2013 at 6:44 AM, Julian H. Stacey wrote: > With: > FreeBSD lapr.js.berklix.net 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 > r255933: Sun Sep 29 02:50:54 UTC 2013 > root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > At boot dmesg shows several lock order reversals, eg > > ------ > Trying to mount root from ufs:/dev/ad4s2a [rw]... > ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, > logging disabled > lock order reversal: > 1st 0xfffffe00a6e26b48 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3059 > 2nd 0xfffff80005cf8400 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00c8f3d3f0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00c8f3d4a0 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe00c8f3d530 > _sx_xlock() at _sx_xlock+0x75/frame 0xfffffe00c8f3d570 > ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfffffe00c8f3d5b0 > ufs_direnter() at ufs_direnter+0x688/frame 0xfffffe00c8f3d670 > ufs_makeinode() at ufs_makeinode+0x573/frame 0xfffffe00c8f3d830 > ufs_symlink() at ufs_symlink+0x32/frame 0xfffffe00c8f3d880 > VOP_SYMLINK_APV() at VOP_SYMLINK_APV+0xf0/frame 0xfffffe00c8f3d8b0 > kern_symlinkat() at kern_symlinkat+0x23e/frame 0xfffffe00c8f3dae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe00c8f3dbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00c8f3dbf0 > --- syscall (57, FreeBSD ELF64, sys_symlink), rip = 0x800888ffa, rsp = > 0x7fffffffca58, rbp = 0x7fffffffdc10 --- > lock order reversal: > 1st 0xfffff800881b9d50 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851 > 2nd 0xfffff800881b99a0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2099 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00c8ed93d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00c8ed9480 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfffffe00c8ed9510 > __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfffffe00c8ed9640 > vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe00c8ed9660 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfffffe00c8ed9690 > _vn_lock() at _vn_lock+0xab/frame 0xfffffe00c8ed9700 > vget() at vget+0x70/frame 0xfffffe00c8ed9750 > devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe00c8ed97a0 > devfs_root() at devfs_root+0x43/frame 0xfffffe00c8ed97d0 > vfs_donmount() at vfs_donmount+0x115e/frame 0xfffffe00c8ed9aa0 > sys_nmount() at sys_nmount+0x72/frame 0xfffffe00c8ed9ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfffffe00c8ed9bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00c8ed9bf0 > --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a9dd7a, rsp = > 0x7fffffffccb8, rbp = 0x7fffffffd220 --- > ---- > > Those two LORs are well-known and at least the fist is definitely a false positive. They're rather tricky to fix; there's been previous discussion. The first one is #261 at http://sources.zabbadoz.net/freebsd/lor.html . The second one is probably #280. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 17:24:11 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F090CDC6 for ; Sun, 6 Oct 2013 17:24:11 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DE8E02584 for ; Sun, 6 Oct 2013 17:24:11 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 7432C1A3C1A for ; Sun, 6 Oct 2013 10:24:11 -0700 (PDT) Message-ID: <52519CB9.8040203@mu.org> Date: Sun, 06 Oct 2013 10:24:09 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter References: <201310061521.r96FLmxw077281@fire.js.berklix.net> In-Reply-To: <201310061521.r96FLmxw077281@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 17:24:12 -0000 On 10/6/13 8:21 AM, Julian H. Stacey wrote: > I wrote Thu, 03 Oct 2013 23:28:43 +0200 >> Rui Paulo wrote: >>> On 2 Oct 2013, at 16:57, Julian H. Stacey wrote: >>> >>>> Hi current@, >>>> It seems I need if_urtwn driver for a really miniature WLAN USB stick, >>>> & if_urtwn is only in current ? >>>> man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ? >>> >>> This driver was never merged to FreeBSD 9. >> OK, Thanks for confirmation. >> >> >>> Can you use FreeBSD 10 instead? >> Yes, easier than building from 9.X I guess (& helps test alpha :-). >> I'll fetch from local mirror, per >> http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html >> >> >>> The port reference in the man page is wrong. The firmware is now shipped as part of the base system. >> Oh nice, easier :-) > I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load="YES" > `ifconfig wlan0 scan` works OK. Thanks :-) > > Cheers, > Julian Cool! I have a g4 tibook 12in with an if_bwn that doesn't really work at all. I got one of these (if_urtwn) and it works enough to download about a meg or so before the watchdog kicks in and I have to ifconfig down/up it to get it to respond again. I even have a patch pending to add the usb identifier for this. Is there someone I can provide debug information for to help resolve this? -- Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 19:05:34 2013 Return-Path: Delivered-To: current@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 ESMTP id D6DAA377; Sun, 6 Oct 2013 19:05:34 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69CC72A4D; Sun, 6 Oct 2013 19:05:31 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r96J59Qt010650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Oct 2013 04:05:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id r96J56pe079701; Mon, 7 Oct 2013 04:05:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 07 Oct 2013 04:04:11 +0900 (JST) Message-Id: <20131007.040411.272534607754482379.hrs@allbsd.org> To: current@FreeBSD.org Subject: CFT: rc.d/jail rewrite (was: jail configuration) From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D In-Reply-To: <8638oerh39.fsf@nine.des.no> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Oct__7_04_04_11_2013_176)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 07 Oct 2013 04:05:21 +0900 (JST) X-Spam-Status: No, score=-94.9 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_BACKQUOTE,MIMEQENC,ONLY1HOPDIRECT,QENCPTR2,RCVD_IN_RP_RNBL, SAMEHELOBY2HOP,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: arch@FreeBSD.org, dteske@FreeBSD.org, jamie@FreeBSD.org, slw@zxy.spb.ru X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: current@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:05:34 -0000 ----Security_Multipart0(Mon_Oct__7_04_04_11_2013_176)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Oct__7_04_04_11_2013_092)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Oct__7_04_04_11_2013_092)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable [Please reply to freebsd-current@] Hi, Can anyone who are using jail_* variables in rc.conf test the attached patch? On freebsd-arch@ there is a discussion about deprecating jail__* variables in favor of jail.conf. This rewrite is one to support the both in a backward compatible way. I want to make sure if this does not break the existing configurations. The following is the entry in UPDATING: +20131007: + The rc.d/jail script has been updated to support jail(8) + configuration file. The "jail__*" rc.conf(5) variables + for per-jail configuration are automatically converted to + /var/run/jail..conf before the jail(8) utility is invoke= d. + This is transparently backward compatible. See the below about= some + incompatibilities. + + These variables are now deprecated in favor of jail(8) configur= ation + file. One can use "rc.d/jail config " command to genera= te + a jail(8) configuration file in /var/run/jail..conf with= out + running the jail(8) utility. The default pathname of the + configuration file is /etc/jail.conf and can be specified by + using $jail_conf or $jail__conf variables. + + Please note that jail_fdesc_enable and jail_procfs_enable are + not supported, and jail_devfs_ruleset accepts an integer at + this moment. Please consider to use exec.fstab for the + additional mount and rewrite the ruleset name with an integer. Dag-Erling Sm=F8rgrav wrote in <8638oerh39.fsf@nine.des.no>: de> I didn't look at the patch very closely, but I see that you print a= de> warning when you generate a configuration for an old-style jail whi= le de> jail.conf exists. I think you should *always* print that warning f= or de> every old-style jail so people will be reminded to convert. We sho= uld de> also remove the examples from /etc/defaults/rc.conf and replace the= de> documentation for jail_${_j}_* in rc.conf(5) with a short paragraph= that de> says they are for compatibility only. Thank you for your feedback. The warning message is always displayed in "rc.d/jail start", and rc.conf(5) and defaults/rc.conf are updated in this patch. -- Hiroki ----Next_Part(Mon_Oct__7_04_04_11_2013_092)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jail_20131007-1.diff" Index: UPDATING =================================================================== --- UPDATING (revision 256090) +++ UPDATING (working copy) @@ -31,6 +31,26 @@ disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20131007: + The rc.d/jail script has been updated to support jail(8) + configuration file. The "jail__*" rc.conf(5) variables + for per-jail configuration are automatically converted to + /var/run/jail..conf before the jail(8) utility is invoked. + This is transparently backward compatible. See the below about some + incompatibilities. + + These variables are now deprecated in favor of jail(8) configuration + file. One can use "rc.d/jail config " command to generate + a jail(8) configuration file in /var/run/jail..conf without + running the jail(8) utility. The default pathname of the + configuration file is /etc/jail.conf and can be specified by + using $jail_conf or $jail__conf variables. + + Please note that jail_fdesc_enable and jail_procfs_enable are + not supported, and jail_devfs_ruleset accepts an integer at + this moment. Please consider to use exec.fstab for the + additional mount and rewrite the ruleset name with an integer. + 20130930: BIND has been removed from the base system. If all you need is a local resolver, simply enable and start the local_unbound Index: etc/rc.d/jail =================================================================== --- etc/rc.d/jail (revision 256090) +++ etc/rc.d/jail (working copy) @@ -8,81 +8,138 @@ # BEFORE: securelevel # KEYWORD: nojail shutdown -# WARNING: This script deals with untrusted data (the data and -# processes inside the jails) and care must be taken when changing the -# code related to this! If you have any doubt whether a change is -# correct and have security impact, please get the patch reviewed by -# the FreeBSD Security Team prior to commit. - . /etc/rc.subr name="jail" rcvar="jail_enable" -start_precmd="jail_prestart" start_cmd="jail_start" +start_postcmd="jail_warn" stop_cmd="jail_stop" +config_cmd="jail_config" +console_cmd="jail_console" +status_cmd="jail_status" +extra_commands="config console status" +: ${jail_conf:=/etc/jail.conf} +: ${jail_program:=/usr/sbin/jail} +: ${jail_consolecmd:=/bin/sh} +: ${jail_jexec:=/usr/sbin/jexec} +: ${jail_jls:=/usr/sbin/jls} -# init_variables _j -# Initialize the various jail variables for jail _j. +need_dad_wait= + +# extact_var jail name param num defval +# Extract value from ${jail_$jail_$name} or ${jail_$name} and +# set it to $param. If not defined, $defval is used. +# When $num is [0-9]*, ${jail_$jail_$name$num} are looked up and +# $param is set by using +=. +# When $num is YN or NY, the value is interpret as boolean. +extract_var() +{ + local i _j _name _param _num _def _name1 _name2 + _j=$1 + _name=$2 + _param=$3 + _num=$4 + _def=$5 + + case $_num in + YN) + _name1=jail_${_j}_${_name} + _name2=jail_${_name} + eval $_name1=\"\${$_name1:-\${$_name2:-$_def}}\" + if checkyesno $_name1; then + echo " $_param = 1;" + else + echo " $_param = 0;" + fi + ;; + NY) + _name1=jail_${_j}_${_name} + _name2=jail_${_name} + eval $_name1=\"\${$_name1:-\${$_name2:-$_def}}\" + if checkyesno $_name1; then + echo " $_param = 0;" + else + echo " $_param = 1;" + fi + ;; + [0-9]*) + i=$_num + while : ; do + _name1=jail_${_j}_${_name}${i} + _name2=jail_${_name}${i} + eval _tmpargs=\"\${$_name1:-\${$_name2:-$_def}}\" + if [ -n "$_tmpargs" ]; then + echo " $_param += \"$_tmpargs\";" + else + break; + fi + i=$(($i + 1)) + done + ;; + *) + _name1=jail_${_j}_${_name} + _name2=jail_${_name} + eval _tmpargs=\"\${$_name1:-\${$_name2:-$_def}}\" + if [ -n "$_tmpargs" ]; then + echo " $_param = \"$_tmpargs\";" + fi + ;; + esac +} + +# parse_options _j +# Parse options and create a temporary configuration file if necessary. # -init_variables() +parse_options() { - _j="$1" + local _j + _j=$1 + _confwarn=0 if [ -z "$_j" ]; then - warn "init_variables: you must specify a jail" + warn "parse_options: you must specify a jail" return fi - + eval _jconf=\"\${jail_${_j}_conf:-/etc/jail.${_j}.conf}\" eval _rootdir=\"\$jail_${_j}_rootdir\" - _devdir="${_rootdir}/dev" - _fdescdir="${_devdir}/fd" - _procdir="${_rootdir}/proc" eval _hostname=\"\$jail_${_j}_hostname\" + if [ -z "$_rootdir" -o \ + -z "$_hostname" ]; then + if [ -r "$_jconf" ]; then + _conf="$_jconf" + return 0 + elif [ -r "$jail_conf" ]; then + _conf="$jail_conf" + return 0 + else + warn "Invalid configuration for $_j " \ + "(no jail.conf, no hostname, or no path). " \ + "Jail $_j was ignored." + fi + return 1 + fi eval _ip=\"\$jail_${_j}_ip\" - eval _interface=\"\${jail_${_j}_interface:-${jail_interface}}\" + if [ -z "$_ip" ] && ! check_kern_features vimage; then + warn "no ipaddress specified and no vimage support. " \ + "Jail $_j was ignored." + return 1 + fi + _conf=/var/run/jail.${_j}.conf + # + # To relieve confusion, show a warning message. + # + _confwarn=1 + if [ -r "$jail_conf" -o -r "$_jconf" ]; then + warn "$_conf is created and used for jail $_j." + fi + /usr/bin/install -m 0644 -o root -g wheel /dev/null $_conf || return 1 + + eval : \${jail_${_j}_flags:=${jail_flags}} eval _exec=\"\$jail_${_j}_exec\" - - i=0 - while : ; do - eval _exec_prestart${i}=\"\${jail_${_j}_exec_prestart${i}:-\${jail_exec_prestart${i}}}\" - [ -z "$(eval echo \"\$_exec_prestart${i}\")" ] && break - i=$((i + 1)) - done - - eval _exec_start=\"\${jail_${_j}_exec_start:-${jail_exec_start}}\" - - i=1 - while : ; do - eval _exec_afterstart${i}=\"\${jail_${_j}_exec_afterstart${i}:-\${jail_exec_afterstart${i}}}\" - [ -z "$(eval echo \"\$_exec_afterstart${i}\")" ] && break - i=$((i + 1)) - done - - i=0 - while : ; do - eval _exec_poststart${i}=\"\${jail_${_j}_exec_poststart${i}:-\${jail_exec_poststart${i}}}\" - [ -z "$(eval echo \"\$_exec_poststart${i}\")" ] && break - i=$((i + 1)) - done - - i=0 - while : ; do - eval _exec_prestop${i}=\"\${jail_${_j}_exec_prestop${i}:-\${jail_exec_prestop${i}}}\" - [ -z "$(eval echo \"\$_exec_prestop${i}\")" ] && break - i=$((i + 1)) - done - - eval _exec_stop=\"\${jail_${_j}_exec_stop:-${jail_exec_stop}}\" - - i=0 - while : ; do - eval _exec_poststop${i}=\"\${jail_${_j}_exec_poststop${i}:-\${jail_exec_poststop${i}}}\" - [ -z "$(eval echo \"\$_exec_poststop${i}\")" ] && break - i=$((i + 1)) - done - + eval _exec_start=\"\$jail_${_j}_exec_start\" + eval _exec_stop=\"\$jail_${_j}_exec_stop\" if [ -n "${_exec}" ]; then # simple/backward-compatible execution _exec_start="${_exec}" @@ -96,285 +153,96 @@ fi fi fi - - # The default jail ruleset will be used by rc.subr if none is specified. - eval _ruleset=\"\${jail_${_j}_devfs_ruleset:-${jail_devfs_ruleset}}\" - eval _devfs=\"\${jail_${_j}_devfs_enable:-${jail_devfs_enable}}\" - [ -z "${_devfs}" ] && _devfs="NO" - eval _fdescfs=\"\${jail_${_j}_fdescfs_enable:-${jail_fdescfs_enable}}\" - [ -z "${_fdescfs}" ] && _fdescfs="NO" - eval _procfs=\"\${jail_${_j}_procfs_enable:-${jail_procfs_enable}}\" - [ -z "${_procfs}" ] && _procfs="NO" - - eval _mount=\"\${jail_${_j}_mount_enable:-${jail_mount_enable}}\" - [ -z "${_mount}" ] && _mount="NO" - # "/etc/fstab.${_j}" will be used for {,u}mount(8) if none is specified. - eval _fstab=\"\${jail_${_j}_fstab:-${jail_fstab}}\" - [ -z "${_fstab}" ] && _fstab="/etc/fstab.${_j}" - eval _flags=\"\${jail_${_j}_flags:-${jail_flags}}\" - [ -z "${_flags}" ] && _flags="-l -U root" - eval _consolelog=\"\${jail_${_j}_consolelog:-${jail_consolelog}}\" - [ -z "${_consolelog}" ] && _consolelog="/var/log/jail_${_j}_console.log" + eval _interface=\"\${jail_${_j}_interface:-${jail_interface}}\" eval _parameters=\"\${jail_${_j}_parameters:-${jail_parameters}}\" - [ -z "${_parameters}" ] && _parameters="" - eval _fib=\"\${jail_${_j}_fib:-${jail_fib}}\" + eval _fstab=\"\${jail_${_j}_fstab:-${jail_fstab:-/etc/fstab.$_j}}\" + ( + date +"# Generated by rc.d/jail at %Y-%m-%d %H:%M:%S" + echo "$_j {" + extract_var $_j hostname host.hostname - "" + extract_var $_j rootdir path - "" + if [ -n "$_ip" ]; then + extract_var $_j interface interface - "" + jail_handle_ips_option $_ip $_interface + alias=0 + while : ; do + eval _x=\"\$jail_${_jail}_ip_multi${alias}\" + [ -z "$_x" ] && break - # Debugging aid - # - debug "$_j devfs enable: $_devfs" - debug "$_j fdescfs enable: $_fdescfs" - debug "$_j procfs enable: $_procfs" - debug "$_j mount enable: $_mount" - debug "$_j hostname: $_hostname" - debug "$_j ip: $_ip" - jail_show_addresses ${_j} - debug "$_j interface: $_interface" - debug "$_j fib: $_fib" - debug "$_j root: $_rootdir" - debug "$_j devdir: $_devdir" - debug "$_j fdescdir: $_fdescdir" - debug "$_j procdir: $_procdir" - debug "$_j ruleset: $_ruleset" - debug "$_j fstab: $_fstab" - - i=0 - while : ; do - eval out=\"\${_exec_prestart${i}:-''}\" - if [ -z "$out" ]; then - break + jail_handle_ips_option $_x $_interface + alias=$(($alias + 1)) + done + case $need_dad_wait in + 1) + # Sleep to let DAD complete before + # starting services. + echo " exec.start += \"sleep " \ + $(($(${SYSCTL_N} net.inet6.ip6.dad_count) + 1)) \ + "\";" + ;; + esac + # These are applicable only to non-vimage jails. + extract_var $_j fib exec.fib - "" + extract_var $_j socket_unixiproute_only \ + allow.raw_sockets NY YES + else + echo " vnet;" + extract_var $_j vnet_interface vnet.interface - "" fi - debug "$_j exec pre-start #${i}: ${out}" - i=$((i + 1)) - done - debug "$_j exec start: $_exec_start" + echo " exec.clean;" + echo " exec.system_user = \"root\";" + echo " exec.jail_user = \"root\";" + extract_var $_j exec_prestart exec.prestart 0 "" + extract_var $_j exec_poststart exec.poststart 0 "" + extract_var $_j exec_prestop exec.prestop 0 "" + extract_var $_j exec_poststop exec.poststop 0 "" - i=1 - while : ; do - eval out=\"\${_exec_afterstart${i}:-''}\" + echo " exec.start += \"$_exec_start\";" + extract_var $_j exec_afterstart exec.start 1 "" + echo " exec.stop = \"$_exec_stop\";" - if [ -z "$out" ]; then - break; - fi + extract_var $_j consolelog exec.consolelog - \ + /var/log/jail_${_j}_console.log - debug "$_j exec after start #${i}: ${out}" - i=$((i + 1)) - done - - i=0 - while : ; do - eval out=\"\${_exec_poststart${i}:-''}\" - if [ -z "$out" ]; then - break + eval : \${jail_${_j}_devfs_enable:=${jail_devfs_enable:-NO}} + if checkyesno jail_${_j}_devfs_enable; then + echo " mount.devfs;" + case $_ruleset in + "") ;; + [0-9]*) echo " devfs_ruleset = \"$_ruleset\";" ;; + devfsrules_jail) + # XXX: This is the default value, + # Let jail(8) to use the default because + # mount(8) only accepts an integer. + # This should accept a ruleset name. + ;; + *) warn "devfs_ruleset must be integer." ;; + esac + if [ -r $_fstab ]; then + echo " mount.fstab = \"$_fstab\";" + fi fi - debug "$_j exec post-start #${i}: ${out}" - i=$((i + 1)) - done - i=0 - while : ; do - eval out=\"\${_exec_prestop${i}:-''}\" - if [ -z "$out" ]; then - break - fi - debug "$_j exec pre-stop #${i}: ${out}" - i=$((i + 1)) - done + # XXX: fdescfs and procfs should be added for + # backward compatibility. - debug "$_j exec stop: $_exec_stop" + echo " ${_parameters};" - i=0 - while : ; do - eval out=\"\${_exec_poststop${i}:-''}\" - if [ -z "$out" ]; then - break + eval : \${jail_${_j}_mount_enable:=${jail_mount_enable:-NO}} + if checkyesno jail_${_j}_mount_enable; then + echo " allow.mount;" >> $_conf fi - debug "$_j exec post-stop #${i}: ${out}" - i=$((i + 1)) - done - debug "$_j flags: $_flags" - debug "$_j consolelog: $_consolelog" - debug "$_j parameters: $_parameters" + extract_var $_j set_hostname_allow allow.set_hostname YN NO + extract_var $_j sysvipc_allow allow.sysvipc YN NO + echo "}" + ) >> $_conf - if [ -z "${_hostname}" ]; then - err 3 "$name: No hostname has been defined for ${_j}" - fi - if [ -z "${_rootdir}" ]; then - err 3 "$name: No root directory has been defined for ${_j}" - fi + return 0 } -# set_sysctl rc_knob mib msg -# If the mib sysctl is set according to what rc_knob -# specifies, this function does nothing. However if -# rc_knob is set differently than mib, then the mib -# is set accordingly and msg is displayed followed by -# an '=" sign and the word 'YES' or 'NO'. -# -set_sysctl() -{ - _knob="$1" - _mib="$2" - _msg="$3" - - _current=`${SYSCTL} -n $_mib 2>/dev/null` - if checkyesno $_knob ; then - if [ "$_current" -ne 1 ]; then - echo -n " ${_msg}=YES" - ${SYSCTL} 1>/dev/null ${_mib}=1 - fi - else - if [ "$_current" -ne 0 ]; then - echo -n " ${_msg}=NO" - ${SYSCTL} 1>/dev/null ${_mib}=0 - fi - fi -} - -# is_current_mountpoint() -# Is the directory mount point for a currently mounted file -# system? -# -is_current_mountpoint() -{ - local _dir _dir2 - - _dir=$1 - - _dir=`echo $_dir | sed -Ee 's#//+#/#g' -e 's#/$##'` - [ ! -d "${_dir}" ] && return 1 - _dir2=`df ${_dir} | tail +2 | awk '{ print $6 }'` - [ "${_dir}" = "${_dir2}" ] - return $? -} - -# is_symlinked_mountpoint() -# Is a mount point, or any of its parent directories, a symlink? -# -is_symlinked_mountpoint() -{ - local _dir - - _dir=$1 - - [ -L "$_dir" ] && return 0 - [ "$_dir" = "/" ] && return 1 - is_symlinked_mountpoint `dirname $_dir` - return $? -} - -# secure_umount -# Try to unmount a mount point without being vulnerable to -# symlink attacks. -# -secure_umount() -{ - local _dir - - _dir=$1 - - if is_current_mountpoint ${_dir}; then - umount -f ${_dir} >/dev/null 2>&1 - else - debug "Nothing mounted on ${_dir} - not unmounting" - fi -} - - -# jail_umount_fs -# This function unmounts certain special filesystems in the -# currently selected jail. The caller must call the init_variables() -# routine before calling this one. -# -jail_umount_fs() -{ - local _device _mountpt _rest - - if checkyesno _fdescfs; then - if [ -d "${_fdescdir}" ] ; then - secure_umount ${_fdescdir} - fi - fi - if checkyesno _devfs; then - if [ -d "${_devdir}" ] ; then - secure_umount ${_devdir} - fi - fi - if checkyesno _procfs; then - if [ -d "${_procdir}" ] ; then - secure_umount ${_procdir} - fi - fi - if checkyesno _mount; then - [ -f "${_fstab}" ] || warn "${_fstab} does not exist" - tail -r ${_fstab} | while read _device _mountpt _rest; do - case ":${_device}" in - :#* | :) - continue - ;; - esac - secure_umount ${_mountpt} - done - fi -} - -# jail_mount_fstab() -# Mount file systems from a per jail fstab while trying to -# secure against symlink attacks at the mount points. -# -# If we are certain we cannot secure against symlink attacks we -# do not mount all of the file systems (since we cannot just not -# mount the file system with the problematic mount point). -# -# The caller must call the init_variables() routine before -# calling this one. -# -jail_mount_fstab() -{ - local _device _mountpt _rest - - while read _device _mountpt _rest; do - case ":${_device}" in - :#* | :) - continue - ;; - esac - if is_symlinked_mountpoint ${_mountpt}; then - warn "${_mountpt} has symlink as parent - not mounting from ${_fstab}" - return - fi - done <${_fstab} - mount -a -F "${_fstab}" -} - -# jail_show_addresses jail -# Debug print the input for the given _multi aliases -# for a jail for init_variables(). -# -jail_show_addresses() -{ - local _j _type alias - _j="$1" - alias=0 - - if [ -z "${_j}" ]; then - warn "jail_show_addresses: you must specify a jail" - return - fi - - while : ; do - eval _addr=\"\$jail_${_j}_ip_multi${alias}\" - if [ -n "${_addr}" ]; then - debug "${_j} ip_multi${alias}: $_addr" - alias=$((${alias} + 1)) - else - break - fi - done -} - -# jail_extract_address argument +# jail_extract_address argument iface # The second argument is the string from one of the _ip # or the _multi variables. In case of a comma separated list # only one argument must be passed in at a time. @@ -382,8 +250,9 @@ # jail_extract_address() { - local _i + local _i _interface _i=$1 + _interface=$2 if [ -z "${_i}" ]; then warn "jail_extract_address: called without input" @@ -439,12 +308,12 @@ _mask=${_mask:-/32} elif [ "${_type}" = "inet6" ]; then - # In case _maske is not set for IPv6, use /128. - _mask=${_mask:-/128} + # In case _maske is not set for IPv6, use /64. + _mask=${_mask:-/64} fi } -# jail_handle_ips_option {add,del} input +# jail_handle_ips_option input iface # Handle a single argument imput which can be a comma separated # list of addresses (theoretically with an option interface and # prefix/netmask/prefixlen). @@ -451,9 +320,9 @@ # jail_handle_ips_option() { - local _x _action _type _i - _action=$1 - _x=$2 + local _x _type _i _iface + _x=$1 + _iface=$2 if [ -z "${_x}" ]; then # No IP given. This can happen for the primary address @@ -468,294 +337,146 @@ *,*) # Extract the first argument and strip it off the list. _i=`expr "${_x}" : '^\([^,]*\)'` _x=`expr "${_x}" : "^[^,]*,\(.*\)"` - ;; + ;; *) _i=${_x} _x="" - ;; + ;; esac _type="" - _iface="" _addr="" _mask="" - jail_extract_address "${_i}" + jail_extract_address $_i $_iface # make sure we got an address. - case "${_addr}" in + case $_addr in "") continue ;; *) ;; esac # Append address to list of addresses for the jail command. - case "${_type}" in + case $_type in inet) - case "${_addrl}" in - "") _addrl="${_addr}" ;; - *) _addrl="${_addrl},${_addr}" ;; - esac - ;; + echo " ip4.addr += \"${_addr}${_mask}\";" + ;; inet6) - case "${_addr6l}" in - "") _addr6l="${_addr}" ;; - *) _addr6l="${_addr6l},${_addr}" ;; - esac - ;; + echo " ip6.addr += \"${_addr}${_mask}\";" + need_dad_wait=1 + ;; esac - - # Configure interface alias if requested by a given interface - # and if we could correctly parse everything. - case "${_iface}" in - "") continue ;; - esac - case "${_type}" in - inet) ;; - inet6) ipv6_address_count=$((ipv6_address_count + 1)) ;; - *) warn "Could not determine address family. Not going" \ - "to ${_action} address '${_addr}' for ${_jail}." - continue - ;; - esac - case "${_action}" in - add) ifconfig ${_iface} ${_type} ${_addr}${_mask} alias - ;; - del) # When removing the IP, ignore the _mask. - ifconfig ${_iface} ${_type} ${_addr} -alias - ;; - esac done } -# jail_ips {add,del} -# Extract the comma separated list of addresses and return them -# for the jail command. -# Handle more than one address via the _multi option as well. -# If an interface is given also add/remove an alias for the -# address with an optional netmask. -# -jail_ips() +jail_config() { - local _action - _action=$1 - - case "${_action}" in - add) ;; - del) ;; - *) warn "jail_ips: invalid action '${_action}'" - return - ;; + case $1 in + _ALL) return ;; esac + for _jail in $@; do + if parse_options $_jail; then + echo "$_jail: parameters are in $_conf." + fi + done +} - # Handle addresses. - ipv6_address_count=0 - jail_handle_ips_option ${_action} "${_ip}" - # Handle jail_xxx_ip_multi - alias=0 - while : ; do - eval _x=\"\$jail_${_jail}_ip_multi${alias}\" - case "${_x}" in - "") break ;; - *) jail_handle_ips_option ${_action} "${_x}" - alias=$((${alias} + 1)) - ;; - esac - done - case ${ipv6_address_count} in - 0) ;; - *) # Sleep 1 second to let DAD complete before starting services. - sleep 1 - ;; +jail_console() +{ + # One argument that is not _ALL. + case $#:$1 in + 1:_ALL) err 3 "Specify a jail name." ;; + 1:*) ;; + *) err 3 "Specify a jail name." ;; esac + eval _cmd=\${jail_$1_consolecmd:-$jail_consolecmd} + $jail_jexec $1 $_cmd } -jail_prestart() +jail_status() { - if checkyesno jail_parallel_start; then - command_args='&' - fi + + $jail_jls -N } jail_start() { - echo -n 'Configuring jails:' - set_sysctl jail_set_hostname_allow security.jail.set_hostname_allowed \ - set_hostname_allow - set_sysctl jail_socket_unixiproute_only \ - security.jail.socket_unixiproute_only unixiproute_only - set_sysctl jail_sysvipc_allow security.jail.sysvipc_allowed \ - sysvipc_allow - echo '.' + if [ $# = 0 ]; then + return + fi + echo -n 'Starting jails:' + case $1 in + _ALL) + echo -n ' ' + command=$jail_program + rc_flags=$jail_flags + command_args="-f $jail_conf -c" + $command $rc_flags $command_args "*" + echo '.' + return + ;; + esac + _tmp=`mktemp -t jail` || exit 3 + for _jail in $@; do + parse_options $_jail || continue - echo -n 'Starting jails:' - _tmp_dir=`mktemp -d /tmp/jail.XXXXXXXX` || \ - err 3 "$name: Can't create temp dir, exiting..." - for _jail in ${jail_list} - do - init_variables $_jail - if [ -f /var/run/jail_${_jail}.id ]; then - echo -n " [${_hostname} already running (/var/run/jail_${_jail}.id exists)]" - continue; - fi - _addrl="" - _addr6l="" - jail_ips "add" - if [ -n "${_fib}" ]; then - _setfib="setfib -F '${_fib}'" + eval rc_flags=\${jail_${_j}_flags:-$jail_flags} + eval command=\${jail_${_j}_program:-$jail_program} + if checkyesno jail_parallel_start; then + command_args="-i -f $_conf -c $_jail &" else - _setfib="" + command_args="-i -f $_conf -c $_jail" fi - if checkyesno _mount; then - info "Mounting fstab for jail ${_jail} (${_fstab})" - if [ ! -f "${_fstab}" ]; then - err 3 "$name: ${_fstab} does not exist" - fi - jail_mount_fstab - fi - if checkyesno _devfs; then - # If devfs is already mounted here, skip it. - df -t devfs "${_devdir}" >/dev/null - if [ $? -ne 0 ]; then - if is_symlinked_mountpoint ${_devdir}; then - warn "${_devdir} has symlink as parent - not starting jail ${_jail}" - continue - fi - info "Mounting devfs on ${_devdir}" - devfs_mount_jail "${_devdir}" ${_ruleset} - # Transitional symlink for old binaries - if [ ! -L "${_devdir}/log" ]; then - ln -sf ../var/run/log "${_devdir}/log" - fi - fi - - # XXX - It seems symlinks don't work when there - # is a devfs(5) device of the same name. - # Jail console output - # __pwd="`pwd`" - # cd "${_devdir}" - # ln -sf ../var/log/console console - # cd "$__pwd" - fi - if checkyesno _fdescfs; then - if is_symlinked_mountpoint ${_fdescdir}; then - warn "${_fdescdir} has symlink as parent, not mounting" - else - info "Mounting fdescfs on ${_fdescdir}" - mount -t fdescfs fdesc "${_fdescdir}" - fi - fi - if checkyesno _procfs; then - if is_symlinked_mountpoint ${_procdir}; then - warn "${_procdir} has symlink as parent, not mounting" - else - info "Mounting procfs onto ${_procdir}" - if [ -d "${_procdir}" ] ; then - mount -t procfs proc "${_procdir}" - fi - fi - fi - _tmp_jail=${_tmp_dir}/jail.$$ - - i=0 - while : ; do - eval out=\"\${_exec_prestart${i}:-''}\" - [ -z "$out" ] && break - ${out} - i=$((i + 1)) - done - - eval ${_setfib} jail -n ${_jail} ${_flags} -i -c path=${_rootdir} host.hostname=${_hostname} \ - ${_addrl:+ip4.addr=\"${_addrl}\"} ${_addr6l:+ip6.addr=\"${_addr6l}\"} \ - ${_parameters} command=${_exec_start} > ${_tmp_jail} 2>&1 \ - ${_consolelog} - echo ${_jail_id} > /var/run/jail_${_jail}.id - - i=0 - while : ; do - eval out=\"\${_exec_poststart${i}:-''}\" - [ -z "$out" ] && break - ${out} - i=$((i + 1)) - done + if $command $rc_flags $command_args \ + >> $_tmp 2>&1 > ${_consolelog} 2>&1 - fi - killall -j ${_jail_id} -TERM > /dev/null 2>&1 - sleep 1 - killall -j ${_jail_id} -KILL > /dev/null 2>&1 - jail_umount_fs - echo -n " $_hostname" - - i=0 - while : ; do - eval out=\"\${_exec_poststop${i}:-''}\" - [ -z "$out" ] && break - ${out} - i=$((i + 1)) - done - fi - jail_ips "del" - rm /var/run/jail_${_jail}.id - else - echo " cannot stop jail ${_jail}. No jail id in /var/run" + case $1 in + _ALL) + echo -n ' ' + command=$jail_program + rc_flags=$jail_flags + command_args="-f $jail_conf -r" + $command $rc_flags $command_args "*" + echo '.' + return + ;; + esac + for _jail in $@; do + parse_options $_jail || continue + eval command=\${jail_${_j}_program:-$jail_program} + if $command -q -f $_conf -r $_jail; then + echo -n " ${_hostname:-${_jail}}" fi done echo '.' } +jail_warn() +{ + + # To relieve confusion, show a warning message. + case $_confwarn in + 1) warn "Per-jail configuration via jail_* variables " \ + "is obsolete. Please consider to migrate to $jail_conf." + ;; + esac +} + load_rc_config $name -cmd="$1" -if [ $# -gt 0 ]; then - shift -fi -if [ -n "$*" ]; then - jail_list="$*" -fi - -run_rc_command "${cmd}" +case $# in +1) run_rc_command $@ ${jail_list:-_ALL} ;; +*) run_rc_command $@ ;; +esac Index: etc/rc.subr =================================================================== --- etc/rc.subr (revision 256090) +++ etc/rc.subr (working copy) @@ -1463,28 +1463,6 @@ return 0 } -# devfs_mount_jail dir [ruleset] -# Mounts a devfs file system appropriate for jails -# on the directory dir. If ruleset is specified, the ruleset -# it names will be used instead. If present, ruleset must -# be the name of a ruleset as defined in a devfs.rules(5) file. -# This function returns non-zero if an error occurs. -# -devfs_mount_jail() -{ - local jdev rs _me - jdev="$1" - [ -n "$2" ] && rs=$2 || rs="devfsrules_jail" - _me="devfs_mount_jail" - - devfs_init_rulesets - if ! devfs_domount "$jdev" $rs; then - warn "$_me: devfs was not mounted on $jdev" - return 1 - fi - return 0 -} - # Provide a function for normalizing the mounting of memory # filesystems. This should allow the rest of the code here to remain # as close as possible between 5-current and 4-stable. Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 256090) +++ etc/defaults/rc.conf (working copy) @@ -674,45 +674,12 @@ opensm_enable="NO" # Opensm(8) for infiniband devices defaults to off ############################################################## -### Jail Configuration ####################################### +### Jail Configuration (see rc.conf(5) manual page) ########## ############################################################## jail_enable="NO" # Set to NO to disable starting of any jails jail_parallel_start="NO" # Start jails in the background jail_list="" # Space separated list of names of jails -jail_set_hostname_allow="YES" # Allow root user in a jail to change its hostname -jail_socket_unixiproute_only="YES" # Route only TCP/IP within a jail -jail_sysvipc_allow="NO" # Allow SystemV IPC use from within a jail -# -# To use rc's built-in jail infrastructure create entries for -# each jail, specified in jail_list, with the following variables. -# NOTES: -# - replace 'example' with the jail's name. -# - except rootdir, hostname, ip and the _multi addresses, -# all of the following variables may be made global jail variables -# if you don't specify a jail name (ie. jail_interface, jail_devfs_ruleset). -# -#jail_example_rootdir="/usr/jail/default" # Jail's root directory -#jail_example_hostname="default.domain.com" # Jail's hostname -#jail_example_interface="" # Jail's interface variable to create IP aliases on -#jail_example_fib="0" # Routing table for setfib(1) -#jail_example_ip="192.0.2.10,2001:db8::17" # Jail's primary IPv4 and IPv6 address -#jail_example_ip_multi0="2001:db8::10" # and another IPv6 address -#jail_example_exec_start="/bin/sh /etc/rc" # command to execute in jail for starting -#jail_example_exec_afterstart0="/bin/sh command" # command to execute after the one for - # starting the jail. More than one can be - # specified using a trailing number -#jail_example_exec_stop="/bin/sh /etc/rc.shutdown" # command to execute in jail for stopping -#jail_example_devfs_enable="NO" # mount devfs in the jail -#jail_example_devfs_ruleset="ruleset_name" # devfs ruleset to apply to jail - - # usually you want "devfsrules_jail". -#jail_example_fdescfs_enable="NO" # mount fdescfs in the jail -#jail_example_procfs_enable="NO" # mount procfs in jail -#jail_example_mount_enable="NO" # mount/umount jail's fs -#jail_example_fstab="" # fstab(5) for mount/umount -#jail_example_flags="-l -U root" # flags for jail(8) -#jail_example_parameters="allow.raw_sockets=1" # extra parameters for this jail - ############################################################## ### Define source_rc_confs, the mechanism used by /etc/rc.* ## ### scripts to source rc_conf_files overrides safely. ## Index: share/man/man5/rc.conf.5 =================================================================== --- share/man/man5/rc.conf.5 (revision 256090) +++ share/man/man5/rc.conf.5 (working copy) @@ -3891,14 +3891,32 @@ If set to .Dq Li NO , any configured jails will not be started. +.It Va jail_conf +.Pq Vt str +The configuration filename used by +.Xr jail 8 +utility. +The default value is +.Pa /etc/jail.conf . .It Va jail_parallel_start .Pq Vt bool If set to .Dq Li YES , all configured jails will be started in the background (in parallel). +.It Va jail_flags +.Pq Vt str +Unset by default. +When set, use as default value for +.Va jail_ Ns Ao Ar jname Ac Ns Va _flags +for every jail in +.Va jail_list . .It Va jail_list .Pq Vt str A space separated list of names for jails. +If this variable is empty, +all of +.Xr jail 8 +instances in the configuration file will be configured. This is purely a configuration aid to help identify and configure multiple jails. The names specified in this list will be used to @@ -3908,171 +3926,41 @@ .Dq Li 0 .Pq zero is not allowed. +.It Va jail_* variables +Note that older releases supported per-jail configuration via +.Xr rc.conf 5 +variables. +For example, +hostname of a jail named +.Li vjail +was able to be set by +.Li jail_vjail_hostname . +These per-jail configuration variables are now obsolete in favor of +.Xr jail 8 +configuration file. +For backward compatibility, +when per-jail configuration variables are defined, +.Xr jail 8 +configuration files are created as +.Pa /var/run/jail. Ns Ao Ar jname Ac Ns Pa .conf +and used. .Pp -Assuming that the jail in question was named -.Li vjail , -you would have the following dependent variables: -.Bd -literal -jail_vjail_hostname="jail.example.com" -jail_vjail_ip="192.0.2.100" -jail_vjail_rootdir="/var/jails/vjail/root" -.Ed -.Pp -.It Va jail_flags -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _flags -for every jail in -.Va jail_list . -.It Va jail_interface -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _interface -for every jail in -.Va jail_list . -.It Va jail_fstab -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _fstab -for every jail in -.Va jail_list . -.It Va jail_mount_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -sets -.Va jail_ Ns Ao Ar jname Ac Ns Va _mount_enable -to -.Dq Li YES -by default for every jail in -.Va jail_list . -.It Va jail_devfs_ruleset -.Pq Vt str -Unset by default. -When set, sets -.Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_ruleset -to given value for every jail in -.Va jail_list . -.It Va jail_devfs_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -sets -.Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_enable -to -.Dq Li YES -by default for every jail in -.Va jail_list . -.It Va jail_fdescfs_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -sets -.Va jail_ Ns Ao Ar jname Ac Ns Va _fdescfs_enable -to -.Dq Li YES -by default for every jail in -.Va jail_list . -.It Va jail_procfs_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -sets -.Va jail_ Ns Ao Ar jname Ac Ns Va _fdescfs_enable -to -.Dq Li YES -by default for every jail in -.Va jail_list . -.It Va jail_exec_prestart Ns Aq Ar N -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_prestart Ns Aq Ar N -for every jail in -.Va jail_list . -.It Va jail_exec_start -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_start -for every jail in -.Va jail_list . -.It Va jail_exec_afterstart Ns Aq Ar N -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_afterstart Ns Aq Ar N -for every jail in -.Va jail_list . -.It Va jail_exec_poststart Ns Aq Ar N -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_poststart Ns Aq Ar N -for every jail in -.Va jail_list . -.It Va jail_exec_prestop Ns Aq Ar N -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_prestop Ns Aq Ar N -for every jail in -.Va jail_list . -.It Va jail_exec_stop -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_stop -for every jail in -.Va jail_list . -.It Va jail_exec_poststop Ns Aq Ar N -.Pq Vt str -Unset by default. -When set, use as default value for -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_poststop Ns Aq Ar N -for every jail in -.Va jail_list . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _rootdir -.Pq Vt str -Unset by default. -Set to the root directory used by jail -.Va jname . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _hostname -.Pq Vt str -Unset by default. -Set to the fully qualified domain name (FQDN) assigned to jail -.Va jname . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _parameters -.Pq Vt str -Unset by default. -Set extra parameters for jail -.Va jname , -such as -.Dq Li allow.chflags -or -.Dq Li children.max . -See -.Xr jail 8 -for a list of available parameters. -Note that the following parameters are already defined by +The following per-jail parameters are handled by .Pa rc.d/jail script out of their corresponding .Nm -variables: +variables. +In addition to them, parameters in +.Va jail_ Ns Ao Ar jname Ac Ns Va _parameters +will be added to the configuration file. +They must be a semi-colon +.Pq Ql \&; +delimited list of +.Dq key=value . +For more details, +see +.Xr jail 8 +manual page. .Bl -tag -width "host.hostname" -offset indent .It Li path set from @@ -4080,202 +3968,85 @@ .It Li host.hostname set from .Va jail_ Ns Ao Ar jname Ac Ns Va _hostname -.It Li command +.It Li exec.consolelog set from -.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_start +.Va jail_ Ns Ao Ar jname Ac Ns Va _consolelog . +The default value is +.Pa /var/log/jail_ Ao Ar jname Ac Pa _console.log . +.It Li interface +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _interface . +.It Li vnet.interface +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _vnet_interface . +This implies +.Li vnet +parameter will be enabled and cannot be specified with +.Va jail_ Ns Ao Ar jname Ac Ns Va _interface , +.Va jail_ Ns Ao Ar jname Ac Ns Va _ip +and/or +.Va jail_ Ns Ao Ar jname Ac Ns Va _ip_multi Ns Aq Ar n +at the same time. +.It Li fstab +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _fstab +.It Li exec.fib +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _fib +.It Li exec.start +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_start . +The parameter name was +.Li command +in some older releases. +.It Li exec.prestart +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_prestart +.It Li exec.poststart +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_poststart +.It Li exec.stop +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_stop +.It Li exec.prestop +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_prestop +.It Li exec.poststop +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _exec_poststop .It Li ip4.addr set if .Va jail_ Ns Ao Ar jname Ac Ns Va _ip -contains IPv4 addresses +or +.Va jail_ Ns Ao Ar jname Ac Ns Va _ip_multi Ns Aq Ar n +contain IPv4 addresses .It Li ip6.addr set if -.Va jail_ Ns Ao Ar jname Ac Ns Va _ip6 -contains IPv6 addresses +.Va jail_ Ns Ao Ar jname Ac Ns Va _ip +or +.Va jail_ Ns Ao Ar jname Ac Ns Va _ip_multi Ns Aq Ar n +contain IPv6 addresses +.It Li allow.mount +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _mount_enable +.It Li mount.devfs +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_enable +.It Li devfs_ruleset +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_ruleset . +This must be an integer, +not a string. +.It Li allow.set_hostname +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _set_hostname_allow +.It Li allow.rawsocket +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _socket_unixiproute_only +.It Li allow.sysvipc +set from +.Va jail_ Ns Ao Ar jname Ac Ns Va _sysvipc_allow .El -.It Va jail_ Ns Ao Ar jname Ac Ns Va _ip -.Pq Vt str -Unset by default. -Set to the (primary) IPv4 and/or IPv6 address(es) assigned to the jail. -The argument can be a sole address or a comma separated list of addresses. -Additionally each address can be prefixed by the name of an interface -followed by a pipe to overwrite -.Va jail_ Ns Ao Ar jname Ac Ns Va _interface -or -.Va jail_interface -and/or suffixed by a netmask, prefixlen or prefix. -In case no netmask, prefixlen or prefix is given, -.Sq /32 -will be used for IPv4 and -.Sq /128 -will be used for an IPv6 address. -If no address is given for the jail then the jail will be started with -no networking support. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _ip_multi Ns Aq Ar n -.Pq Vt str -Unset by default. -Set additional IPv4 and/or IPv6 address(es) assigned to the jail. -The sequence starts with -.Dq Li _multi0 -and the numbers have to be strictly ascending. -These entries follow the same syntax as their primary -.Va jail_ Ns Ao Ar jname Ac Ns Va _ip -entry. -The order of the entries can be important as the first address for -each address family found will be the primary address of the jail. -See -.Va ip-addresses -option in -.Xr jail 8 -for more details. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _flags -.Pq Vt str -Set to -.Dq Li -l -U root -by default. -These are flags to pass to -.Xr jail 8 . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _interface -.Pq Vt str -Unset by default. -When set, sets the interface to use when setting IP address alias. -Note that the alias is created at jail startup and removed at jail shutdown. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _fib -.Pq Vt str -Unset by default. -When set, the jail is started with the specified forwarding table (sometimes -referred to as a routing table) via -.Xr setfib 1 . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _fstab -.Pq Vt str -Set to -.Pa /etc/fstab. Ns Aq Ar jname -by default. -This is the file system information file to use for jail -.Va jname . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _mount_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -mount all file systems from -.Va jail_ Ns Ao Ar jname Ac Ns Va _fstab -at jail startup. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_ruleset -.Pq Vt str -Unset by default. -When set, defines the device file system ruleset file to use for jail -.Va jname . -.It Va jail_ Ns Ao Ar jname Ac Ns Va _devfs_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -mount the device file system inside jail -.Ar jname -at jail startup. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _fdescfs_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -mount the file-descriptor file system inside jail -.Ar jname -at jail startup. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _procfs_enable -.Pq Vt bool -Set to -.Dq Li NO -by default. -When set to -.Dq Li YES , -mount the process file system inside jail -.Ar jname -at jail startup. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_prestart Ns Aq Ar N -.Pq Vt str -Unset by default. -This is the command run as -.Ar N Ns -th command -before jail startup, where -.Ar N -is 0, 1, and so on. -It is run outside the jail. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_start -.Pq Vt str -Set to -.Dq Li /bin/sh /etc/rc -by default. -This is the command executed in a jail at jail startup. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_afterstart Ns Aq Ar N -.Pq Vt str -Unset by default. -This is the command run as -.Ar N Ns -th command -in a jail -after jail startup, where -.Ar N -is 1, 2, and so on. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_poststart Ns Aq Ar N -.Pq Vt str -Unset by default. -This is the command run as -.Ar N Ns -th command -after jail startup, where -.Ar N -is 0, 1, and so on. -It is run outside the jail. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_prestop Ns Aq Ar N -.Pq Vt str -Unset by default. -This is the command run as -.Ar N Ns -th command -before jail shutdown, where -.Ar N -is 0, 1, and so on. -It is run outside the jail. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_stop -.Pq Vt str -Set to -.Dq Li /bin/sh /etc/rc.shutdown -by default. -This is the command executed in a jail at jail shutdown. -.It Va jail_ Ns Ao Ar jname Ac Ns Va _exec_poststop Ns Aq Ar N -.Pq Vt str -Unset by default. -This is the command run as -.Ar N Ns -th command -after jail shutdown, where -.Ar N -is 0, 1, and so on. -It is run outside the jail. -.It Va jail_set_hostname_allow -.Pq Vt bool -If set to -.Dq Li NO , -do not allow the root user in a jail to set its hostname. -.It Va jail_socket_unixiproute_only -.Pq Vt bool -If set to -.Dq Li YES , -do not allow any sockets, -besides UNIX/IP/route sockets, -to be used within a jail. -.It Va jail_sysvipc_allow -.Pq Vt bool -If set to -.Dq Li YES , -allow applications within a jail to use System V IPC. .\" ----------------------------------------------------- .It Va harvest_interrupt .Pq Vt bool Index: usr.sbin/jail/jail.c =================================================================== --- usr.sbin/jail/jail.c (revision 256090) +++ usr.sbin/jail/jail.c (working copy) @@ -470,10 +470,12 @@ if (dep_check(j)) continue; if (j->jid < 0) { - if (!(j->flags & (JF_DEPEND | JF_WILD)) - && verbose >= 0) - jail_quoted_warnx(j, - "not found", NULL); + if (!(j->flags & (JF_DEPEND|JF_WILD))) { + if (verbose >= 0) + jail_quoted_warnx(j, + "not found", NULL); + failed(j); + } goto jail_remove_done; } j->comparam = stopcommands; ----Next_Part(Mon_Oct__7_04_04_11_2013_092)---- ----Security_Multipart0(Mon_Oct__7_04_04_11_2013_176)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlJRtCsACgkQTyzT2CeTzy1z3QCeJ6/3B1fnadI52oGwyepBf6KX 4iUAoNdGI+MKRXsAn4QLzej5+rvkMYxZ =sH1M -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Oct__7_04_04_11_2013_176)---- From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 19:12:48 2013 Return-Path: Delivered-To: current@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 ESMTP id 7CA93607; Sun, 6 Oct 2013 19:12:48 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 0AE562ABD; Sun, 6 Oct 2013 19:12:47 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBF6E6.dip0.t-ipconnect.de [217.251.246.230]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r96JCjgH091925; Sun, 6 Oct 2013 19:12:45 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r96JCXDO028077; Sun, 6 Oct 2013 21:12:33 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r96JCRxR014304; Sun, 6 Oct 2013 21:12:33 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310061912.r96JCRxR014304@fire.js.berklix.net> To: Matthew Fleming Subject: Re: lock order reversals on 10.0-ALPHA4 From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sun, 06 Oct 2013 08:22:27 PDT." Date: Sun, 06 Oct 2013 21:12:27 +0200 Sender: jhs@berklix.com Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:12:48 -0000 > > Those two LORs are well-known and at least the fist is definitely a false > positive. They're rather tricky to fix; there's been previous discussion. > > The first one is #261 at http://sources.zabbadoz.net/freebsd/lor.html . > The second one is probably #280. > > Cheers, > matthew Thanks Matthew, I'll ignore them then, plenty else to do :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 19:26:15 2013 Return-Path: Delivered-To: current@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 ESMTP id A5C559B9; Sun, 6 Oct 2013 19:26:15 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61C122B4F; Sun, 6 Oct 2013 19:26:15 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id ar20so14018835iec.32 for ; Sun, 06 Oct 2013 12:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=RzVULWIPIobqqS7Av5No7zALvJOMfptbl22Hz3Tes+w=; b=QS1NeAjjmUMFEQzn+cXlmNiVlja4JB2iDVYhTFO7foVUS//nxwBjziJoNEppOqdav0 OcgK4I7ORV5xR2z80bpqlac0VQgRQNJNq8RpQ9SkUvjHQBGSkPTvru2oBQyjMXhhjwsb SLEiHwBgV1LLRE9Tt0iJvNlOSJz/vkqP/LRywXUmf0ruVrO5uhZcnXuUX0JTjQWuiWIL 5F49YLho6lAZ9rShBsdUGJvgkjBExjhgW73IT+dIfPqKAqZgjw2ou1tDMFmFyhgy2D0F ZjrrpmJwN8aOjPnfyLo1i5yRFt57id2CnLCb6rZF5lzi8WvLHbermJ0TYgvmjupyf0qo A/wg== MIME-Version: 1.0 X-Received: by 10.50.45.100 with SMTP id l4mr14110990igm.60.1381087574830; Sun, 06 Oct 2013 12:26:14 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.64.27.105 with HTTP; Sun, 6 Oct 2013 12:26:14 -0700 (PDT) Date: Sun, 6 Oct 2013 21:26:14 +0200 X-Google-Sender-Auth: L1jQTvfLxuSh8bc30BKa8hSdZ_A Message-ID: Subject: Re: Call for FreeBSD 2013Q3 (July-September) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 19:26:15 -0000 Dear FreeBSD Community, This is another gentle reminder that the deadline for submissions for the third Quarterly Status Report is tomorrow! Please find the details quoted below. On Sun, Sep 29, 2013 at 12:22 PM, Gabor Pali wrote: > Dear FreeBSD Community, > > Please note that the next submission date for the July to September > Quarterly Status Reports is October 7th, 2013, bit more than a week > away. Please consult my previous message for the details: > > On Mon, Sep 9, 2013 at 12:04 AM, Gabor Pali wrote: >> They do not have to be very long -- basically they may be about >> anything that lets people know what is going on around the FreeBSD >> Project. Submission of reports is not restricted to committers: >> Anyone who is doing anything interesting and FreeBSD-related can (and >> therefore encouraged to) write one! >> >> The preferred and easiest submission method is to use the XML >> generator [1] with the result emailed as an attachment to us, that is, >> monthly@FreeBSD.org [2]. There is also an XML template [3] which can >> be filled out manually and attached if preferred. >> >> To enable compilation and publication of the Q3 report as soon as >> possible for the October 7th deadline, please be prompt with any >> report submissions you may have. >> >> We are looking forward to all of your 2013Q3 reports! >> >> Cheers, >> Gabor >> >> >> [1] http://www.freebsd.org/cgi/monthly.cgi >> [2] mailto:monthly@freebsd.org >> [3] http://www.freebsd.org/news/status/report-sample.xml From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 21:39:19 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 1DE0A5BD for ; Sun, 6 Oct 2013 21:39:19 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm34-vm3.bullet.mail.bf1.yahoo.com (nm34-vm3.bullet.mail.bf1.yahoo.com [72.30.239.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 971A020D8 for ; Sun, 6 Oct 2013 21:39:18 +0000 (UTC) Received: from [98.139.212.144] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 21:39:11 -0000 Received: from [98.139.211.206] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 21:39:11 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 21:39:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381095551; bh=xWaI0dqZPB3dp8Pja39gSbb+GykhJecJ0JBwibpC7CI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=pw9Wo8bH5KwDjYo19N7ZhWqetur++qAoZx3Lq8J1b4jk2na4jt+eUpBgLlZ/FkuwZWHNJM5Ryt6Nvt4m9BjPRiLc9YsdZFgQ6970aTFlIYVBOYttE4fQn0BuyNFgNsxfoWkVD/KZjaK5TKOTLmiGtr59P/T4UWbcxcJLZayMps4= X-Yahoo-Newman-Id: 423583.23012.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AZQ.MFUVM1mW6boJS7kMEMd8GoNuzlv7kPNRfADLbx8RneU HlrMjTTTubdYo33x9QsmQl7t02OjUobqAMLTSgZVbepQx7CiKDhjtKu9x2wJ cTUwn5QqjIUujLdsw41AUzUOgNOLsVJp88fm35aPbUKE_epsMwuxnmmR3b1z 6HortYG3elNHKCgidFOpnLstty_eMiVl.6h8DEbF4fh95bohGJ3JKFUTAHgx YCF7zxkFY0mUW5OgeSE1i9DCYOwZV532faEYcJTX8VlRHWM7riyzgGJpqjBI _AV5cHP2J4aVwwbA9_yMZ8cTYyGG6j2huWGUHRWuh7oJ82dYX9LqPa1XEp_d v8jecjAMthzStOsHb1Tsk8zoRlWjNrSd7s_N65Jik63bcjsIYC7y5QpFfN7Q ItQMzfLBLIKGVRFO.oNI8uriVGKJakuT2CRVLxeKXQ_M1MLt8ci0kx3YESiY rQiBQvMS29k_5A8N8mDdaCEgOzwu3T8kuvOoHQA81KYq0Wy6OlPwVTjzQKnj TcGb5YqvH5_Ii8q6kJ4yqHNY3cP5Cc3xN_XzMARuFxsUCNawO_4EK X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.100.228] (sean_bruno@24.23.220.111 with ) by smtp215.mail.bf1.yahoo.com with SMTP; 06 Oct 2013 14:39:11 -0700 PDT Subject: drm2/radeon dfixed_trunc() warnings From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-rgtCoYwmDgK4fOHKYw7y" Date: Sun, 06 Oct 2013 14:39:09 -0700 Message-ID: <1381095549.1586.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 21:39:19 -0000 --=-rgtCoYwmDgK4fOHKYw7y Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These caught my eye today, and the checks strewn about sys/dev/drm2/radeon seem completely bogus to me, but I don't have the h/w to test it at the moment. /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/rs690.c:491:37= : warning: comparison of unsigned expression < 0 is always false [-Wtautolo= gical-compare] if (dfixed_trunc(priority_mark02) < 0) dfixed_trunc is a macro: drm_fixed.h:#define dfixed_trunc(A) ((A).full >> 12) that returns the output of a shift right operation ... priority_mark02 is of type union fixed20_12, single element union of type u32, so I can't see this check ever doing anything useful. But, as always, I'm probably missing something obvious. =20 Sean --=-rgtCoYwmDgK4fOHKYw7y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSUdh5AAoJEBkJRdwI6BaHMXoH/2a5cP+Wo/00dPi//49N/Jqq jzd1UE3Fy2ZAIsesPmSMMmY3i2ZnvcTFrhrXYuAIoviagREd24SEATm98SHNpOO2 Q4LmnQ2oSMBvoERA/ORnKqG6hPUNAl2WshfpC6OA/1DToy8mN58/moX1jQNNbO3d ulFKW1kTsXTf4LQmspGl0lcytVoONVfk3RY6FXzUKnYJ84VQ0C04Ya987hV3vwjZ 3kg7dgYqhqCELSzxh+XGznPb8iBk+9mYrs3d8oe6X/m694opVaohPQr7nrUFdH70 oIGcaUhn5Lny9yYt+VYcvAh9XZh9JHwIy9r4LPk4avJNJaPqksEef0oNayzglBE= =zlR4 -----END PGP SIGNATURE----- --=-rgtCoYwmDgK4fOHKYw7y-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 22:29:07 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0700ED8 for ; Sun, 6 Oct 2013 22:29:07 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm45-vm8.bullet.mail.bf1.yahoo.com (nm45-vm8.bullet.mail.bf1.yahoo.com [216.109.115.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D2D122AC for ; Sun, 6 Oct 2013 22:29:06 +0000 (UTC) Received: from [98.139.215.141] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 22:28:59 -0000 Received: from [68.142.230.64] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 22:28:59 -0000 Received: from [127.0.0.1] by smtp221.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 22:28:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381098539; bh=wzlyVRJAH0G71jROjuU/uO+ySo1gn4gsApRCr+WTfjQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=c7bVFB+38lbp27s1GCJ0capDuJGfQ+7H2I74PkECrexolUXsSe3BM84V4KWDyuJGLLXskrwdshI4LqjD9uA02pmoSWbgWTYjr8qppJk7kq5il+fP1z0zn/9hQkW+TCKlT9NYG8puyo0la7Xrt5wtZpUOvXFj1gKXCl0sfeP/l/0= X-Yahoo-Newman-Id: 830722.53135.bm@smtp221.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: wW1Z9F0VM1mei6VLaeYoDMf6WFSqBSrvzeswPumMN5r06Gh CzcGAvr3qdwO23BEwncp7a2mUUQundrAG.9wfibOU7s04PtSFt0616udogCN E8C7rDzfIWpmnLJmgfcHNYOJvkO9j3vEHJre.1.lkdrxdGG5G97KwinK.Xoz 3qGH16VU3xitm5xYfywY2TQHnluGK0RGpMpVcRWz4Dx.ZllGjIfaOWfbHxFT Nnww_qKeX.Mw6caejjCAjSZNI09fKyh8fcjnEDimsRSMN42H4On_FEwu7Fv1 x.Tpx6yhkPCBCaYYnrY3gHMKmpSRSOhpG5zAOW.hFlUH2zA88na1HZgEGLVR NsMqnVYY_GYezT89CH.whVnzGI1EYMS_hiR4zMS8JHg3mBX9qHRhojo6lSJ4 qS_vDVFLGP_jIuhE5m54QPLbzwfTwtVwWtuWc6tEjeQZ9NCfGgShBN4A0l1P CXxFWlKoJstyERPVXcqy4EgacebMcennAkVZygpvI6lsOY.1BfL3gVkAQHUI kuDKyTzs7u0dZsJ3iIKXxFtcC6bA8IbWhnDrblVGhaY2TlRHoA0.XktN2d7g LU3hltFBpeM1jQbQ.EC8owOfD.iXdqwdgKXYnGrbJU66O2_eHCYGvD4.XWVe bkFBb8A2kk776 X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.100.228] (sean_bruno@24.23.220.111 with ) by smtp221.mail.bf1.yahoo.com with SMTP; 06 Oct 2013 22:28:59 +0000 UTC Subject: X related ports not finding version strings and hanging From: Sean Bruno To: "freebsd-current@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Gzp1Z7qZUxf1PxFToQQQ" Date: Sun, 06 Oct 2013 15:28:58 -0700 Message-ID: <1381098538.1683.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 22:29:08 -0000 --=-Gzp1Z7qZUxf1PxFToQQQ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be causing problems duing the update. When this happens, some prompt is waiting for me to hit "enter" that has scrolled past and I cannot see it. =20 =3D=3D=3D>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" --=-Gzp1Z7qZUxf1PxFToQQQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSUeQmAAoJEBkJRdwI6BaHrdoH/A79vnEy1V8n9O28256YXEey 7mrkQwSDTfhk9GcJqhTDANtgh8U4ctzdFcTskBncB99GQvavY9qXO7lk7S/oF6vQ ldM2MTrlgDkwUC25QyQmrKQnOj9O8Ts3/oW1CWHiuOidoAJc+Ip3Q0bGFr1OBhwc xMIEMqYu+5kBD0Jw9eG3bvZgcYLKADOo4DPfkZNiJa0Cc/EP6gowvuEfneMYtlqB 0ToQ7Ztew+THNSHjVC/Lkrx9YhpBbBMcn78jOcl4o8uchk6ZPZs2ZmB80x/m2JQq aYOn5pVlv/fzaIcWjdMX+ozBOVazFAjgJykHMvozdWUHVOy6xc/6/Q5fU044dMQ= =sh/f -----END PGP SIGNATURE----- --=-Gzp1Z7qZUxf1PxFToQQQ-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 22:36:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26E6A100 for ; Sun, 6 Oct 2013 22:36:52 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C73052303 for ; Sun, 6 Oct 2013 22:36:51 +0000 (UTC) Received: from [98.139.212.151] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 22:36:44 -0000 Received: from [98.139.213.15] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 22:36:44 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 06 Oct 2013 22:36:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381099004; bh=iZBFKH7S4kmLtO1/0oolV/zmOPDZb4ZxCmblr2KFrmE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=KSP4lr80xhU2EWVHF1XenM5cGw6aIE4PkEJ1i30JmjWPavuArIcIEOl+khhpwSHHOICzo2hc/jZPeFbbT2AsDtDq5f2MvFPDzf0kHjNfcw1ByKfCTYO+p1QXQIkvqyCByjhP404cU+AJ5SJkCkQhOwAEW64LkTwqC9g8W1exs+M= X-Yahoo-Newman-Id: 509574.7004.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ugDD4DoVM1mgrYNTOOF3N.deSRBqUnccGZLG.WBFcqd7hAR xNPnKBI3A6Gi3yAOl0akPx1PWZvOPfYuOCwEk3qmtCCrXM8hmysvSsTjKeuf qdzs7B5SFXciYySDm9ZyTokFSFAgGmrhL51SiFtkg9bdVWqdZew_oG9pkkJK tNPEoij9D8CwuBDe0j2sU.43sgBTTKOaCbr28XN5BRhiaYmKvKxlR91ZGNKN X2OxU5PoIqRO8gq7p5klQNWgG7MqscJD8koWQtkjH3eD6ICDx4m7j3fIcJ8E RslkumByDBwIvJBEOxCAoiqUlgm.vOkhiRcActey2dNpxLOU1xrKhjKhs716 3xZtDU4JoMGQf7UBo_VTixjgjeF6tEaUCBwyDr09dq4F6SN6mJLFKL9meoja 0.4eaMIOhF8a1mzVlSD7321Cc.L_cOA6gtVbLjqj_In4d.P_iIUy0Iq0KYoW 8IvxwZyRwY7tkRs0lRVib5tdCVhzUUShMuFJbGwgTyjRkkn67kZREzGeB6W8 v5xgkEs8ej66Dkb.8zrGOZjibM7.7b6WNf8TJzkiEaiSCto1AVEhVmz6we.U 8mhFDT.1ZQhGyL20rqi8jbxDE193A8yNpJFJxNGZhwvOASThzlApNMvVgu6X aKRnZDZiuz5.f X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.100.228] (sean_bruno@24.23.220.111 with ) by smtp115.mail.bf1.yahoo.com with SMTP; 06 Oct 2013 15:36:44 -0700 PDT Subject: Re: X related ports not finding version strings and hanging From: Sean Bruno To: sbruno@freebsd.org In-Reply-To: <1381098538.1683.1.camel@localhost> References: <1381098538.1683.1.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xzvFKc2j7T+tZmRPHaUU" Date: Sun, 06 Oct 2013 15:36:42 -0700 Message-ID: <1381099002.1683.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 22:36:52 -0000 --=-xzvFKc2j7T+tZmRPHaUU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: > Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be > causing problems duing the update. When this happens, some prompt is > waiting for me to hit "enter" that has scrolled past and I cannot see > it. =20 >=20 >=20 > =3D=3D=3D>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) >=20 > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" >=20 Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild it. sean --=-xzvFKc2j7T+tZmRPHaUU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSUeX6AAoJEBkJRdwI6BaHRNAIAJFPNLJ6gYt6tOdAEPbP6UE3 2XSPfrQ6wtfdYkP8wLSxdATNScVuebXSSVZuzDpsxrKWMIpow+7NZ8ZkX179gyJ6 IU1G31J60Q6TUWblnp7y1+I6StZ0tL+ZAzutnmH8nA4sPqkIvuVDY5BiF407Enic oBK6vTHsa7wgqEw8nXtSls3TdWRhmGnix5sxJOoZ3NgMZVsGK9hqL/k7uID8EP8N X6/ew4SpjNHMNisYUDjitaqqesk+p4HoervWryqwJ/UuJjcKndjwRxDpasV69tU3 43EhClQZM5qqbJPABKUzq6JfdXMryowF2WFJVzU9D2dwuivxejDFfAWbgHugOfg= =2fit -----END PGP SIGNATURE----- --=-xzvFKc2j7T+tZmRPHaUU-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 6 23:29:19 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D4FFFC7C; Sun, 6 Oct 2013 23:29:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B18824D3; Sun, 6 Oct 2013 23:29:19 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r96NTDUZ050031; Sun, 6 Oct 2013 16:29:13 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r96NTD6j050030; Sun, 6 Oct 2013 16:29:13 -0700 (PDT) (envelope-from sgk) Date: Sun, 6 Oct 2013 16:29:13 -0700 From: Steve Kargl To: sbruno@freebsd.org Subject: Re: X related ports not finding version strings and hanging Message-ID: <20131006232913.GA50021@troutmask.apl.washington.edu> References: <1381098538.1683.1.camel@localhost> <1381099002.1683.2.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381099002.1683.2.camel@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 23:29:19 -0000 On Sun, Oct 06, 2013 at 03:36:42PM -0700, Sean Bruno wrote: > On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: > > Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be > > causing problems duing the update. When this happens, some prompt is > > waiting for me to hit "enter" that has scrolled past and I cannot see > > it. > > > > > > ===>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) > > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > > > > Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild > it. > Yep. Yet another port change disaster during a code freeze. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 02:01:26 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 9DEB83CC for ; Mon, 7 Oct 2013 02:01:26 +0000 (UTC) (envelope-from mueller6721@twc.com) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5DC412C50 for ; Mon, 7 Oct 2013 02:01:25 +0000 (UTC) Received: from [74.130.200.176] ([74.130.200.176:24590] helo=localhost) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 4D/24-15529-EE512525; Mon, 07 Oct 2013 02:01:19 +0000 Date: Mon, 07 Oct 2013 02:01:18 +0000 Message-ID: <4D.24.15529.EE512525@cdptpa-oedge01> From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 02:01:26 -0000 I just happened to be browsing man urtwn in NetBSD-current (6.99.23), and Edimax EW-7811Un is listed as supported by this driver. This strongly suggests it should work for FreeBSD-current (barring bugs). Tom From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 02:43:52 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 03850B52 for ; Mon, 7 Oct 2013 02:43:52 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF82B2DED for ; Mon, 7 Oct 2013 02:43:51 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz1so6668189pad.2 for ; Sun, 06 Oct 2013 19:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=N9fU7s/kBMobJgaEYWPzhfhlqsqhmksp0/3nbhvQXU0=; b=NFXBNVhUoWXRkqXJZFRAJabbFFRG8cRAnKldnoDpnZy1re0UOyi3S4imTvH/4+T9KU DoUIXBDriUbfOsHNbg4EubGdpurz0F5pmmIIS2WdQzki9S10IndzKlLYDDSOcr9v9RtU 64723F+0UkzcCNqEZPGdVMsynpVMGlfqF9k8Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=N9fU7s/kBMobJgaEYWPzhfhlqsqhmksp0/3nbhvQXU0=; b=dxekaXF/PLowjjK1Ngp71U4ysC+TmE9FZNmFKCrNosj6IJF4G7+ieabssDJaLCGzID 8IibDp6Ti+6k6bkohOlSRlDkkVF4jfKqn7OBtnkWe0gJwUSWVP/7QEUEIffpiUoKYGTI muZt4gfzOww77AkRmqkjVa4oHV6M1jekX2h35sCeYhukyt+kUhKSFTRVKJG92fH/cYP+ Mc4Rj+84tZ57uZKcGiANX4r4rMO585Lp+0g2fbQ9WswzQZZKyxSVoXL0DaktSms42hJI QhBMv1JtV/V/Nflz8sHF7qe8NAQ8UI7V3Lazf56p8jcpuRXRvYPz7tZw5YAdJ68Hc78v 0DXw== X-Gm-Message-State: ALoCoQmB49ri6i1Ud0U+Y4J8+ngRoon3o6Zp10WRmU1laIdqZjNi1ncWKI6FQjbtMCGo7HQ1ZPnl X-Received: by 10.68.189.163 with SMTP id gj3mr28170718pbc.102.1381113831505; Sun, 06 Oct 2013 19:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Sun, 6 Oct 2013 19:43:21 -0700 (PDT) From: Eitan Adler Date: Sun, 6 Oct 2013 22:43:21 -0400 Message-ID: Subject: [Heads Up] RCS removed from base To: freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 02:43:52 -0000 Hey all, RCS was removed from the base system in r256095. If you still want to use RCS please install either devel/rcs or devel/rcs57. If not, be sure to check out the alternatives (pun stolen and intended). -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 03:21:46 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id C5CCC4F2 for ; Mon, 7 Oct 2013 03:21:46 +0000 (UTC) (envelope-from xenophon+freebsd@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-55.central.biz.rr.com [24.123.13.55]) by mx1.freebsd.org (Postfix) with ESMTP id 9805B205B for ; Mon, 7 Oct 2013 03:21:46 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 51AC3C49 for ; Sun, 6 Oct 2013 23:21:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 185wAkcqUv8r for ; Sun, 6 Oct 2013 23:21:39 -0400 (EDT) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Sun, 6 Oct 2013 23:21:39 -0400 (EDT) Subject: Hyper-V virtual DVD not detected Date: Sun, 6 Oct 2013 23:21:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Hyper-V virtual DVD not detected thread-index: Ac7DB4nyYzEbusN+R7CaVgGxZgrzSA== From: "xenophon\\+freebsd" To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 03:21:46 -0000 Hi everybody! Is anyone else running FreeBSD-current under Hyper-V? I can boot 10.0-ALPHA4 under Hyper-V Server 2012 using the installation CD image, but once running FreeBSD doesn't detect the virtual DVD drive - or at least the cd0 device is missing. Virtual hard disks attached to the same storage controller work just fine, IDE or SCSI. Conversely, everything works as expected under FreeBSD 9.2. I was able to install 10.0-ALPHA4 by attaching a second hard drive and copying the ISO image over the top of it. (The installer had no problems locating the FREEBSD_INSTALL volume on the second hard drive.) I'm not sure how to go about troubleshooting this. To start I am upgrading to r256072 in case any commits since ALPHA4 have fixed this problem. I'm also going to take a look at the source to the Hyper-V drivers. Beyond that, I'm open to any suggestions. Best wishes, Matthew --=20 I FIGHT FOR THE USERS From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 03:32:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A65C6A0 for ; Mon, 7 Oct 2013 03:32:51 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-55.central.biz.rr.com [24.123.13.55]) by mx1.freebsd.org (Postfix) with ESMTP id EB34220D1 for ; Mon, 7 Oct 2013 03:32:50 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 0E2FDC77 for ; Sun, 6 Oct 2013 23:32:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG8azaQ4Z4NR for ; Sun, 6 Oct 2013 23:32:31 -0400 (EDT) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Sun, 6 Oct 2013 23:32:30 -0400 (EDT) Subject: RE: Hyper-V virtual DVD not detected Date: Sun, 6 Oct 2013 23:32:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: In-Reply-To: Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: Hyper-V virtual DVD not detected thread-index: Ac7DB4nyYzEbusN+R7CaVgGxZgrzSAABbyVg References: From: "Matthew X. Economou" To: X-Mailman-Approved-At: Mon, 07 Oct 2013 03:34:41 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 03:32:51 -0000 Oh, never mind - apparently, this particular party has already started over in freebsd-virtualization@, something about how Hyper-V doesn't virtualize the CD/DVD drive. It's a work in progress. Best wishes, Matthew --=20 I FIGHT FOR THE USERS From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 03:39:09 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8D2D7FB; Mon, 7 Oct 2013 03:39:09 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e: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 AAA9D2102; Mon, 7 Oct 2013 03:39:09 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id ro12so6562105pbb.27 for ; Sun, 06 Oct 2013 20:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WSBHMEPmKocY/fu2pZzTAiBm2szoQoWTy4NShcHJPjY=; b=iDahxl1iHT6iGfXAiw7cAsYS87U9oPImvCDoc76GGQS6oskcS0YoYH+UB4Ebevbi0i Z1pK/nvNew9X5RVHghqlalHExxrWOxgKfckoR0LnMSJc2bUO1VnS8ecg7iNwbi/QPIHY LTdksBO+X2aKa9jfSTCTjsgY2EUao1GyaPsIeGtSiI2zf+ySbwL2GtqiKElEUAgvBa3t f3P+H0aLqOaVwoVTgAzj2eIklT/h5tTi0qrHhyJTA4KtOZUtCKf3NgqOVHQi//pDXNuL Y3OKDZLcAdjdk9Cp+37IOsLpR1KFjaUheKh3MhfzBrZBV4c+NjnKw/uLSmNwj3tNkRcM Y9IQ== MIME-Version: 1.0 X-Received: by 10.69.4.100 with SMTP id cd4mr19969732pbd.120.1381117148932; Sun, 06 Oct 2013 20:39:08 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.219.74 with HTTP; Sun, 6 Oct 2013 20:39:08 -0700 (PDT) In-Reply-To: <20131006232913.GA50021@troutmask.apl.washington.edu> References: <1381098538.1683.1.camel@localhost> <1381099002.1683.2.camel@localhost> <20131006232913.GA50021@troutmask.apl.washington.edu> Date: Sun, 6 Oct 2013 20:39:08 -0700 X-Google-Sender-Auth: m6Q2h2kC4q5Vv3JDH2sUM9T9FTw Message-ID: Subject: Re: X related ports not finding version strings and hanging From: Kevin Oberman To: Steve Kargl Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 03:39:10 -0000 On Sun, Oct 6, 2013 at 4:29 PM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Sun, Oct 06, 2013 at 03:36:42PM -0700, Sean Bruno wrote: > > On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: > > > Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be > > > causing problems duing the update. When this happens, some prompt is > > > waiting for me to hit "enter" that has scrolled past and I cannot see > > > it. > > > > > > > > > ===>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) > > > > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > > > > > > > Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild > > it. > > > > Yep. Yet another port change disaster during a code freeze. > > As usual with such upgrades, pkg_libchk is your friend. Assuming you have updated pixman: portmaster graphics/libGL graphics/dri pkg_libchk -o | grep pixman | cut -d: -f1 | sort | uniq > pixman-files.txt portmaster =D `cat pixman-files.txt` portmaster -aD portmaster -y -clean-distfiles This will do the job much more quickly than "portmaster -r pixman -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 13:28:08 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id D42BF439; Mon, 7 Oct 2013 13:28:08 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 627D6236C; Mon, 7 Oct 2013 13:28:08 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBE81A.dip0.t-ipconnect.de [217.251.232.26]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r97DS5bi027609; Mon, 7 Oct 2013 13:28:06 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r97DRrEm035243; Mon, 7 Oct 2013 15:27:53 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r97DRl9W053828; Mon, 7 Oct 2013 15:27:53 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310071327.r97DRl9W053828@fire.js.berklix.net> To: Glen Barber Subject: Re: FreeBSD 10.0-ALPHA4 now available From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sun, 29 Sep 2013 21:58:17 EDT." <20130930015817.GC40093@glenbarber.us> Date: Mon, 07 Oct 2013 15:27:47 +0200 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org, FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:28:08 -0000 > The fourth ALPHA build of the 10.0-RELEASE release cycle is now available > on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and > sparc64 architectures. > > Note: Due to build issues within the head/ branch, ALPHA3 ISO builds > were skipped. > > The 10.0-ALPHA4 builds correlate to svn revision r255933 of the head/ > branch. (After zapping boot on an adjacent parition & repairing,) I avoided installer, & booted another partition, mounted FreeBSD-10.0-ALPHA4-amd64-memstick.img & tar'ed to empty partition 10.0-ALPHA4 runs, built & ran new generic kernel & ports X11 etc. :-) I had supposed an Alpha /usr/src would compile even if it broke at run time. Not so, 10.0-ALPHA4 src/ is broken (with & without obj & depend). cd /usr/src ; make -i install killed the system. To avoid killing, I hacked Makefiles, list below. Reinstalled & survived. I'll try with a newer current later, but Alpha4 src/ needs fixing. cd /usr/src ; cp /dev/null ~/tmp/`uname -r`.diffs foreach i ( `find . -name Makefile\*.pre_jhs | sort`) echo >> ~/tmp/`uname -r`.diffs diff -c $i `dirname $i`/`basename $i .pre_jhs` >> ~/tmp/`uname -r`.diffs end *** ./Makefile.inc1.pre_jhs Mon Oct 7 12:51:25 2013 --- ./Makefile.inc1 Mon Oct 7 12:51:57 2013 *************** *** 71,77 **** .endif SUBDIR+=gnu include .if ${MK_KERBEROS} != "no" ! SUBDIR+=kerberos5 .endif .if ${MK_RESCUE} != "no" SUBDIR+=rescue --- 71,77 ---- .endif SUBDIR+=gnu include .if ${MK_KERBEROS} != "no" ! # pre_jhs SUBDIR+=kerberos5 .endif .if ${MK_RESCUE} != "no" SUBDIR+=rescue *** ./lib/ncurses/Makefile.pre_jhs Mon Oct 7 12:48:21 2013 --- ./lib/ncurses/Makefile Mon Oct 7 14:53:27 2013 *************** *** 1,6 **** # $FreeBSD: head/lib/ncurses/Makefile 167359 2007-03-09 12:11:58Z rafan $ ! SUBDIR= ncurses form menu panel \ ! ncursesw formw menuw panelw .include --- 1,9 ---- # $FreeBSD: head/lib/ncurses/Makefile 167359 2007-03-09 12:11:58Z rafan $ ! SUBDIR= form menu panel \ ! formw menuw panelw ! # pre_jhs breaks compiling SUBDIR += ncurses ! # pre_jhs breaks compiling SUBDIR += ncursesw ! # pre_jhs install breaks /lib/libncurses.so.8: Undefined symbol "_nc_wacs" SUBDIR += ncursesw .include *** ./rescue/Makefile.pre_jhs Mon Oct 7 13:23:46 2013 --- ./rescue/Makefile Mon Oct 7 13:25:57 2013 *************** *** 1,6 **** # $FreeBSD: head/rescue/Makefile 117035 2003-06-29 18:35:37Z gordon $ SUBDIR= librescue \ ! rescue .include --- 1,7 ---- # $FreeBSD: head/rescue/Makefile 117035 2003-06-29 18:35:37Z gordon $ SUBDIR= librescue \ ! ! # pre_jhs rescue .include *** ./sbin/atm/Makefile.pre_jhs Sun Sep 29 03:14:17 2013 --- ./sbin/atm/Makefile Mon Oct 7 13:37:45 2013 *************** *** 23,28 **** # @(#) $Id: Makefile,v 1.5 1998/07/10 16:01:58 jpt Exp $ # $FreeBSD: head/sbin/atm/Makefile 179308 2008-05-25 22:11:40Z rwatson $ ! SUBDIR= atmconfig .include --- 23,28 ---- # @(#) $Id: Makefile,v 1.5 1998/07/10 16:01:58 jpt Exp $ # $FreeBSD: head/sbin/atm/Makefile 179308 2008-05-25 22:11:40Z rwatson $ ! #pre_jhs SUBDIR= atmconfig .include *** ./share/i18n/Makefile.pre_jhs Sun Sep 29 03:09:07 2013 --- ./share/i18n/Makefile Mon Oct 7 13:58:44 2013 *************** *** 3,8 **** .include ! SUBDIR= csmapper esdb .include --- 3,9 ---- .include ! # pre_jhs both break SUBDIR= csmapper esdb ! SUBDIR= .include *** ./sys/boot/userboot/Makefile.pre_jhs Sun Sep 29 03:12:25 2013 --- ./sys/boot/userboot/Makefile Mon Oct 7 14:05:33 2013 *************** *** 2,8 **** .include ! SUBDIR= ficl libstand test userboot .include --- 2,9 ---- .include ! # pre_jhs SUBDIR= ficl libstand test userboot ! SUBDIR= ficl libstand test .include *** ./usr.bin/Makefile.pre_jhs Sun Sep 29 03:13:01 2013 --- ./usr.bin/Makefile Mon Oct 7 14:13:43 2013 *************** *** 261,267 **** .endif .if ${MK_KERBEROS_SUPPORT} != "no" ! SUBDIR+= compile_et .endif .if ${MK_LDNS_UTILS} != "no" --- 261,267 ---- .endif .if ${MK_KERBEROS_SUPPORT} != "no" ! #pre_jhs SUBDIR+= compile_et .endif .if ${MK_LDNS_UTILS} != "no" Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 14:44:24 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 16E32D95 for ; Mon, 7 Oct 2013 14:44:24 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB1FB2858 for ; Mon, 7 Oct 2013 14:44:23 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id t60so1669491wes.30 for ; Mon, 07 Oct 2013 07:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=IYJqUTTfta8e8TNQHAcGhYevFD0u2lV1iMMrNNM6UPo=; b=nCWDTWcJw/Y9HZAhc9zAYjE77tqkZTWYsrBIHmDJeroBdsSFQ5rAl0m2ebbAMpsToy QwC5vneHhS8L5ek4XnT0jrlXBH11OdfW5f6F6eYsG9arLHvk2XE43M1O861abjuc+VYu kNl28QEIC0wanaSv5vzh5TysQDkkRA1lhQpAL790xLcTg+QzBk/iRCNEJd3uRY3BqXmm smv6sKTNArpgbHYZilfD2+lrx41rWdVFsv/Ch9u2CxbWU8lGcJ5vJYsfPqd4LA/1d7LK P1zaZ2V8PMS2/vYw6mui3x7/iN3kCrPNl91HYvdr4N1vNPOSWMUr6pCTn9WFTYb+x5Ha PY1Q== X-Received: by 10.194.104.42 with SMTP id gb10mr24846905wjb.16.1381157061857; Mon, 07 Oct 2013 07:44:21 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.194.236.131 with HTTP; Mon, 7 Oct 2013 07:44:01 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 7 Oct 2013 16:44:01 +0200 X-Google-Sender-Auth: -XCH5vXhzJbTBb-H-TdJw-PUIXs Message-ID: Subject: unionfs related panic on 10.0-ALPHA4 To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:44:24 -0000 Hi all, I've got a panic on my 10.0 FreeBSD. This system was building port with poudriere and generate special nanobsd images (with unionfs usage) when it panic. I didn't have enough swap space for a full dump, I've just have a text dump: root@orange:/var/crash # cat info.last Dump header from device /dev/gpt/swap0 Architecture: amd64 Architecture Version: 1 Dump Length: 30720B (0 MB) Blocksize: 512 Dumptime: Mon Oct 7 15:16:55 2013 Hostname: orange.bsdrp.net Magic: FreeBSD Text Dump Version String: FreeBSD 10.0-ALPHA4 #15 r256062: Sat Oct 5 20:51:12 CEST 2013 root@orange.bsdrp.net:/usr/obj/usr/local/BSDRP/BSDRPcur/FreeBSD/src/sys/PROD Panic String: __lockmgr_args: downgrade a recursed lockmgr zfs @ /usr/local/BSDRP/BSDRPcur/FreeBSD/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1906 Dump Parity: 1116491583 Bounds: 1 Dump Status: good root@orange:/var/crash # cat version.txt FreeBSD 10.0-ALPHA4 #15 r256062: Sat Oct 5 20:51:12 CEST 2013 root@orange.bsdrp.net:/usr/obj/usr/local/BSDRP/BSDRPcur/FreeBSD/src/sys/PROD root@orange:/var/crash # cat msgbuf.txt ... panic: __lockmgr_args: downgrade a recursed lockmgr zfs @ /usr/local/BSDRP/BSDRPcur/FreeBSD/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1906 cpuid = 4 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe095d7d5480 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe095d7d5530 panic() at panic+0x155/frame 0xfffffe095d7d55b0 __lockmgr_args() at __lockmgr_args+0xdd3/frame 0xfffffe095d7d56c0 vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe095d7d56e0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9d/frame 0xfffffe095d7d5710 unionfs_lock() at unionfs_lock+0x2bc/frame 0xfffffe095d7d57a0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9d/frame 0xfffffe095d7d57d0 _vn_lock() at _vn_lock+0x43/frame 0xfffffe095d7d5830 unionfs_readdir() at unionfs_readdir+0x13f/frame 0xfffffe095d7d5980 VOP_READDIR_APV() at VOP_READDIR_APV+0x98/frame 0xfffffe095d7d59b0 kern_getdirentries() at kern_getdirentries+0x20b/frame 0xfffffe095d7d5ab0 sys_getdirentries() at sys_getdirentries+0x28/frame 0xfffffe095d7d5ae0 amd64_syscall() at amd64_syscall+0x357/frame 0xfffffe095d7d5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe095d7d5bf0 --- syscall (196, FreeBSD ELF64, sys_getdirentries), rip = 0x8008adcea, rsp = 0x7fffffffcfd8, rbp = 0x7fffffffd210 --- KDB: enter: panic Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 15:07:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7546F73E for ; Mon, 7 Oct 2013 15:07:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B4D729CC for ; Mon, 7 Oct 2013 15:07:00 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r97F6wep082545; Mon, 7 Oct 2013 08:06:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r97F6ws3082542; Mon, 7 Oct 2013 08:06:58 -0700 (PDT) (envelope-from sgk) Date: Mon, 7 Oct 2013 08:06:58 -0700 From: Steve Kargl To: Eitan Adler Subject: Re: [Heads Up] RCS removed from base Message-ID: <20131007150658.GA79233@troutmask.apl.washington.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:07:00 -0000 On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: > Hey all, > > RCS was removed from the base system in r256095. If you still want to > use RCS please install either devel/rcs or devel/rcs57. If not, be > sure to check out the alternatives (pun stolen and intended). > Perhaps, a note in src/UPDATING is appropriate? -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 16:17:27 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id C8F5EBA0; Mon, 7 Oct 2013 16:17:27 +0000 (UTC) (envelope-from jhb@freebsd.org) 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 998872E6E; Mon, 7 Oct 2013 16:17:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD351B962; Mon, 7 Oct 2013 12:17:26 -0400 (EDT) From: John Baldwin To: Alexander Motin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking Date: Mon, 7 Oct 2013 12:09:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <5224511D.4090503@FreeBSD.org> <201310021330.23251.jhb@freebsd.org> <525111A2.1020106@FreeBSD.org> In-Reply-To: <525111A2.1020106@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201310071209.56312.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 07 Oct 2013 12:17:26 -0400 (EDT) Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:17:28 -0000 On Sunday, October 06, 2013 3:30:42 am Alexander Motin wrote: > On 02.10.2013 20:30, John Baldwin wrote: > > On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: > >> On 07.09.2013 02:02, Jeremie Le Hen wrote: > >>> On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: > >>>> On 06.09.2013 11:06, Jeremie Le Hen wrote: > >>>>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labb=E9 w= rote: > >>>>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin > > wrote: > >>>>>>> I've found and fixed possible double request completion, that cou= ld > > cause > >>>>>>> such symptoms if happened. Updated patch located as usual: > >>>>>>>=20 http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch > >>>>>>> > >>>>> With this new one I cannot boot any more (I also updated the source > >>>>> tree). This is a hand transcripted version: > >>>>> > >>>>> Trying to mount root from zfs:zroot/root []... > >>>>> panic: Batch flag already set > >>>>> cpuid =3D 1 > >>>>> KDB: stack backtrace: > >>>>> db_trace_self_wrapper() > >>>>> kdb_backtrace() > >>>>> vpanic() > >>>>> kassert_panic() > >>>>> xpt_batch_start() > >>>>> ata_interrupt() > >>>>> softclock_call_cc() > >>>>> softclock() > >>>>> ithread_loop() > >>>>> fork_exit() > >>>>> fork_trampoline() > >>>> > >>>> Thank you for the report. I see my fault. It is probably specific to > >>>> ata(4) driver only. I've workarounded that in new patch version, but > >>>> probably that area needs some rethinking. > >>>> > >>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch > >>> > >>> I'm not sure you needed a confirmation, but it boots. Thanks :). > >>> > >>> I didn't quite understand the thread; is direct dispatch enabled for > >>> amd64? ISTR you said only i386 but someone else posted the macro for > >>> amd64. > >> > >> Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd= 64. > > > > FYI, I tested mfi with this patch set and mfid worked fine for handling= =20 g_up > > directly: > > > > Index: dev/mfi/mfi_disk.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- dev/mfi/mfi_disk.c (revision 257407) > > +++ dev/mfi/mfi_disk.c (working copy) > > @@ -162,6 +162,7 @@ > > sc->ld_disk->d_unit =3D sc->ld_unit; > > sc->ld_disk->d_sectorsize =3D secsize; > > sc->ld_disk->d_mediasize =3D sectors * secsize; > > + sc->ld_disk->d_flags =3D DISKFLAG_DIRECT_COMPLETION; > > if (sc->ld_disk->d_mediasize >=3D (1 * 1024 * 1024)) { > > sc->ld_disk->d_fwheads =3D 255; > > sc->ld_disk->d_fwsectors =3D 63; > > >=20 > Thank you for the feedback. But looking on mfi driver sources I would=20 > say that it calls biodone() from mfi_disk_complete() from cm_complete()=20 > method, which is called while holding mfi_io_lock mutex. I guess that if= =20 > on top of mfi device would be some GEOM class, supporting direct=20 > dispatch and sending new requests down on previous request completion=20 > (or retrying requests), that could cause recursive mfi_io_lock=20 > acquisition. That is exactly the cause why I've added this flag. May be=20 > it is a bit paranoid, but it is better to be safe then sorry. >=20 > Another good reason to drop the lock before calling biodone() would be=20 > reducing the lock hold time. Otherwise it may just increase lock=20 > congestion there and destroy all benefits of the direct dispatch. Ah, interesting. What is your policy for such drivers? Should they be left using g_up, should they drop the lock around biodone when completeing multiple requests in an interrupt? Should they try to batch them by waiting and doing biodone at the end after dropping the lock? =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 16:30:34 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 776DC278; Mon, 7 Oct 2013 16:30:34 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5D62F60; Mon, 7 Oct 2013 16:30:34 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id q10so7344927pdj.35 for ; Mon, 07 Oct 2013 09:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=6YTiqRUdh8tjnoygijfbDyM0qcyPWtStbckY38DfQQo=; b=nXumBb0ziWEqzhwbpxMx403kYr6MgGxoqSlXXnoxn4EnuC3iQ0xmULErZyoGvmcZnp 2QUDmFkHwoG1RN9Xxwsxn2khNDYfk0jNwkW+VdUV0uJcOQG/SmRAH75A7bIfd2FTSm1J 1dh601Bbv4x1B96HoB7+jFWr3YhqKrMS9F6e+IjvAXIHQkPuIyvRemquWh29l8ziDquN SR15ERGHUIDwQ6As3CGbzizPZsiRK5lM0Q5jC1uzxHdc+yb06JPTc7o9DaQOz36Pi01Z iK7ha1mMshGR/dbROnNF4EXiufQ9xstIcg6F+D7dqa0rmHMVqORQufuMbUGZj9gPzows ntFA== X-Received: by 10.66.250.47 with SMTP id yz15mr4196712pac.154.1381163433814; Mon, 07 Oct 2013 09:30:33 -0700 (PDT) Received: from localhost (c-76-21-78-151.hsd1.ca.comcast.net. [76.21.78.151]) by mx.google.com with ESMTPSA id bt1sm34353868pbb.2.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 09:30:33 -0700 (PDT) Sender: Gleb Kurtsou Date: Mon, 7 Oct 2013 09:31:11 -0700 From: Gleb Kurtsou To: freebsd-current@freebsd.org Subject: Committing PEFS to CURRENT Message-ID: <20131007163111.GB1590@reks.swifttest.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: delphij@freebsd.org, Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:30:34 -0000 Hello, I would like to ask everybody's opinion regarding committing PEFS to CURRENT. PEFS is a stacked cryptographic file system for FreeBSD. Development started as Google Summer of Code project in 2009. It has been in ports since Sept 2011. I maintain the project. Conceptually PEFS is similar to nullfs adding encryption layer on top of it. But it differs technically by not using vop_bypass. Another popular stacked cryptographic file systems include eCryptfs (linux) and encfs (fuse). There is also pam_pefs pam module to allow user authentication with their PEFS-encrypted home directory password. For those interested in high level introduction I would highly recommend article by Kris Moore in the BSD Magazine Issue 09/2013(50) - http://bsdmag.org/magazine/1848-day-to-day-bsd-administration We are very close to branching 10-STABLE now, but patch is non-intrusive, it only adds new functionality, enabling PEFS for i386 and amd64 (platforms it's known to work on). Patch passes make universe. Patch is available here: https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch Pros/cons: - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS who are already committed to use PEFS in next product releases, e.g. PCBSD provides encrypted home directories. - There is steady interest in the project from users (emails, etc). Many of them note that file system is not well known yet. Moving PEFS to base would greatly increase its exposure. - Committing PEFS to base would also simplify maintenance by keeping it in sync with other subsystems, e.g. it will be updated on large scale changes like VM locking. - There are no bugs known at the moment. I've been using it to encrypt home directory since day one. pho@ ran stress test suite on it a while back, number of bugs was fixed. - PEFS is known to work on amd64 and i386 only. Big endian system and systems with page size larger than 4k are not tested. - NOTE! There has been no cryptography review. I'd like to suggest to add warning about file system and crypto used is experimental and hasn't undergone professional review. Similar to one we had in tmpfs. BSD Magazine article: http://bsdmag.org/magazine/1848-day-to-day-bsd-administration Port: http://www.freshports.org/sysutils/pefs-kmod/ Source code repository: https://github.com/glk/pefs FreeBSD DevSummit'2011 - pefs presentation slides: https://pefs.googlecode.com/files/pefs-devsummit.pdf FreeBSD wiki page: https://wiki.freebsd.org/PEFS I would really appreciate any comments or suggestions. Thank you, Gleb. From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 16:44:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0E2CC951; Mon, 7 Oct 2013 16:44:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18D0C20BB; Mon, 7 Oct 2013 16:44:38 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b45so3411643eek.15 for ; Mon, 07 Oct 2013 09:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=35KWtTscl4vVGFofXojrrZELOiiZi7dj5Nw0m1SbJ74=; b=j51PA/X69Fs1qIT6aHHz1NvmV/+dUI22Nyqg0kq6Hm+aFiE61IqvFwB9h6xQIHw18U JIhtfFT8gG9gqEDJlWOUWS/b8G9kxIAcAIR7ayN42AzeEtR/zFnNVM5sxKjFX3wFJdGL /gpTUO4MWCIZRpdR/4Oc736lBJUy2RkPz2N53WZUS5C+XNuOGE1xOFyrAfWP1Hkj3kbO b64oi17jwW/F1h2T/0H1TB9lCSy8VgtKRsG2q9WGRZz7/ymbknp3n3okhOJZkI17zW0j rusZntKOpLwDPivPpfPebhkV2RY+eGSpCsZAKvgMXUepIBuYUm52+TyyOHWoQ26AcmWM 3qqQ== X-Received: by 10.14.88.65 with SMTP id z41mr49832497eee.38.1381164277446; Mon, 07 Oct 2013 09:44:37 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id r48sm65342167eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 09:44:36 -0700 (PDT) Sender: Alexander Motin Message-ID: <5252E4F1.9070604@FreeBSD.org> Date: Mon, 07 Oct 2013 19:44:33 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Baldwin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking References: <5224511D.4090503@FreeBSD.org> <201310021330.23251.jhb@freebsd.org> <525111A2.1020106@FreeBSD.org> <201310071209.56312.jhb@freebsd.org> In-Reply-To: <201310071209.56312.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:44:40 -0000 On 07.10.2013 19:09, John Baldwin wrote: > On Sunday, October 06, 2013 3:30:42 am Alexander Motin wrote: >> On 02.10.2013 20:30, John Baldwin wrote: >>> On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: >>>> On 07.09.2013 02:02, Jeremie Le Hen wrote: >>>>> On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: >>>>>> On 06.09.2013 11:06, Jeremie Le Hen wrote: >>>>>>> On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote: >>>>>>>> On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin >>> wrote: >>>>>>>>> I've found and fixed possible double request completion, that could >>> cause >>>>>>>>> such symptoms if happened. Updated patch located as usual: >>>>>>>>> > http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch >>>>>>>>> >>>>>>> With this new one I cannot boot any more (I also updated the source >>>>>>> tree). This is a hand transcripted version: >>>>>>> >>>>>>> Trying to mount root from zfs:zroot/root []... >>>>>>> panic: Batch flag already set >>>>>>> cpuid = 1 >>>>>>> KDB: stack backtrace: >>>>>>> db_trace_self_wrapper() >>>>>>> kdb_backtrace() >>>>>>> vpanic() >>>>>>> kassert_panic() >>>>>>> xpt_batch_start() >>>>>>> ata_interrupt() >>>>>>> softclock_call_cc() >>>>>>> softclock() >>>>>>> ithread_loop() >>>>>>> fork_exit() >>>>>>> fork_trampoline() >>>>>> >>>>>> Thank you for the report. I see my fault. It is probably specific to >>>>>> ata(4) driver only. I've workarounded that in new patch version, but >>>>>> probably that area needs some rethinking. >>>>>> >>>>>> http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch >>>>> >>>>> I'm not sure you needed a confirmation, but it boots. Thanks :). >>>>> >>>>> I didn't quite understand the thread; is direct dispatch enabled for >>>>> amd64? ISTR you said only i386 but someone else posted the macro for >>>>> amd64. >>>> >>>> Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64. >>> >>> FYI, I tested mfi with this patch set and mfid worked fine for handling > g_up >>> directly: >>> >>> Index: dev/mfi/mfi_disk.c >>> =================================================================== >>> --- dev/mfi/mfi_disk.c (revision 257407) >>> +++ dev/mfi/mfi_disk.c (working copy) >>> @@ -162,6 +162,7 @@ >>> sc->ld_disk->d_unit = sc->ld_unit; >>> sc->ld_disk->d_sectorsize = secsize; >>> sc->ld_disk->d_mediasize = sectors * secsize; >>> + sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION; >>> if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) { >>> sc->ld_disk->d_fwheads = 255; >>> sc->ld_disk->d_fwsectors = 63; >>> >> >> Thank you for the feedback. But looking on mfi driver sources I would >> say that it calls biodone() from mfi_disk_complete() from cm_complete() >> method, which is called while holding mfi_io_lock mutex. I guess that if >> on top of mfi device would be some GEOM class, supporting direct >> dispatch and sending new requests down on previous request completion >> (or retrying requests), that could cause recursive mfi_io_lock >> acquisition. That is exactly the cause why I've added this flag. May be >> it is a bit paranoid, but it is better to be safe then sorry. >> >> Another good reason to drop the lock before calling biodone() would be >> reducing the lock hold time. Otherwise it may just increase lock >> congestion there and destroy all benefits of the direct dispatch. > > Ah, interesting. What is your policy for such drivers? Should they be > left using g_up, should they drop the lock around biodone when completeing > multiple requests in an interrupt? Should they try to batch them by > waiting and doing biodone at the end after dropping the lock? In CAM's da and ada drivers I've managed to drop the periph lock before calling biodone(). New CAM locking design allowed to do it safe. Possibility of dropping CAM SIM (HBA driver) locks on completion though depends on HBA design. For example, for ATA/SATA drivers I haven't found safe way to drop the lock in place, so I delay commands completions up to the moment when lock can be safely dropped and then process completions in a batch. For SCSI HBAs with more separated request and response queues I guess that may be easier. But now all SCSI drivers are still queuing requests completion to separate CAM threads to decouple the locks that way. I've just added more of them to spread the load between cores. But I hope that, for example, mps driver could be reworked to allow both using multiple MSI-X interrupt threads and lock-less request completion. Whether it is possible to do it safe for mfi I don't know. For cases when dropping the locks is not possible, there is g_up thread to use. For setups with single controller in a system with single interrupt thread queuing to g_up thread may even be better, helping to split load between two CPUs instead of one. But that is in case if HBA is fast or ineffective enough to saturate one CPU. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 16:53:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F2EB121; Mon, 7 Oct 2013 16:53:18 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3821E2173; Mon, 7 Oct 2013 16:53:18 +0000 (UTC) Received: from [10.1.3.5] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id F38DE1A281C; Mon, 7 Oct 2013 12:53:11 -0400 (EDT) Message-ID: <5252E6F6.80009@mail.lifanov.com> Date: Mon, 07 Oct 2013 12:53:10 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Gleb Kurtsou Subject: Re: Committing PEFS to CURRENT References: <20131007163111.GB1590@reks.swifttest.com> In-Reply-To: <20131007163111.GB1590@reks.swifttest.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:53:18 -0000 On 10/07/13 12:31, Gleb Kurtsou wrote: > Hello, > > I would like to ask everybody's opinion regarding committing PEFS to > CURRENT. > > PEFS is a stacked cryptographic file system for FreeBSD. Development > started as Google Summer of Code project in 2009. It has been in ports > since Sept 2011. I maintain the project. > > Conceptually PEFS is similar to nullfs adding encryption layer on top of > it. But it differs technically by not using vop_bypass. Another popular > stacked cryptographic file systems include eCryptfs (linux) and encfs > (fuse). There is also pam_pefs pam module to allow user authentication > with their PEFS-encrypted home directory password. > > For those interested in high level introduction I would highly recommend > article by Kris Moore in the BSD Magazine Issue 09/2013(50) - > http://bsdmag.org/magazine/1848-day-to-day-bsd-administration > > We are very close to branching 10-STABLE now, but patch is > non-intrusive, it only adds new functionality, enabling PEFS for i386 > and amd64 (platforms it's known to work on). Patch passes make universe. > > Patch is available here: > https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch > > Pros/cons: > > - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS > who are already committed to use PEFS in next product releases, e.g. > PCBSD provides encrypted home directories. > > - There is steady interest in the project from users (emails, etc). > Many of them note that file system is not well known yet. Moving PEFS > to base would greatly increase its exposure. > > - Committing PEFS to base would also simplify maintenance by keeping it > in sync with other subsystems, e.g. it will be updated on large scale > changes like VM locking. > > - There are no bugs known at the moment. I've been using it to encrypt > home directory since day one. pho@ ran stress test suite on it a > while back, number of bugs was fixed. > > - PEFS is known to work on amd64 and i386 only. Big endian system and > systems with page size larger than 4k are not tested. > > - NOTE! There has been no cryptography review. I'd like to suggest to > add warning about file system and crypto used is experimental and hasn't > undergone professional review. Similar to one we had in tmpfs. > > > BSD Magazine article: > http://bsdmag.org/magazine/1848-day-to-day-bsd-administration > > Port: > http://www.freshports.org/sysutils/pefs-kmod/ > > Source code repository: > https://github.com/glk/pefs > > FreeBSD DevSummit'2011 - pefs presentation slides: > https://pefs.googlecode.com/files/pefs-devsummit.pdf > > FreeBSD wiki page: > https://wiki.freebsd.org/PEFS > > > I would really appreciate any comments or suggestions. > > > Thank you, > Gleb. Just a personal note: I hoped that you would commit pefs to base someday. It works well, and is the type of a core functionality that would be nice to have as early as the install ISO, before skel is copied over for the first user. I would be happy if this happened. - Nikolai Lifanov From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 18:25:13 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75B76900 for ; Mon, 7 Oct 2013 18:25:13 +0000 (UTC) (envelope-from supportme@ukr.net) Received: from mx-out1.ukr.net (mx-out1.ukr.net [195.214.192.21]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0594427BF for ; Mon, 7 Oct 2013 18:25:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:To:Subject:From:Date; bh=ocWKe6JVDLlnfKyPEcEu05XuU+MbFecIBGbIzFbgaXQ=; b=Q7mz6Iupb9ZmU7A/cYRB/GBMx9AjFrW72lwsVVe5jeUnCNsQNFXckU1XVKlH2jnjNZ4mDksRgefPp/2S06FKM6zQTEWNxnTKGw/pmb+QHMQW4IB24z4VBm4gPWxlFzWYN6ss46ZNXVGBDjSvIKOwofWNt5kpdzzpsW1Vbx9bLxk=; Received: from [10.10.10.45] (helo=frv45.ukr.net) by mx-out1.ukr.net with smtp ID 1VTFEz-000O8r-T6 for freebsd-current@freebsd.org; Mon, 07 Oct 2013 21:09:10 +0300 Date: Mon, 07 Oct 2013 21:09:06 +0300 From: Dmitriy Makarov Subject: ZFS L2ARC - incorrect size and abnormal system load on r255173 To: freebsd-current@freebsd.org X-Mailer: freemail.ukr.net 5.0 Message-Id: <1381166916.122992963.5h9ygiri@frv45.ukr.net> MIME-Version: 1.0 Received: from supportme@ukr.net by frv45.ukr.net; Mon, 07 Oct 2013 21:09:08 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:25:13 -0000 Hi all, On our production system on r255173 we have problem with abnormal high system load caused (not sure) with L2ARC placed on a few SSD, 490 GB total size. After a fresh boot everything seems to be fine, Load Average less then 5.00. But after some time (nearly day-two) Load Average jump to 10.. 20+ and system goes really slow, IO opearations with zfs pool grows from ms to even seconds. And L2ARC sysctls are pretty disturbing: [frv:~]$ sysctl -a | grep l2 vfs.zfs.l2arc_write_max: 25000000 vfs.zfs.l2arc_write_boost: 50000000 vfs.zfs.l2arc_headroom: 8 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_feed_min_ms: 30 vfs.zfs.l2arc_noprefetch: 0 vfs.zfs.l2arc_feed_again: 1 vfs.zfs.l2arc_norw: 1 vfs.zfs.l2c_only_size: 1525206040064 vfs.cache.numfullpathfail2: 4 kstat.zfs.misc.arcstats.evict_l2_cached: 6592742547456 kstat.zfs.misc.arcstats.evict_l2_eligible: 734016778752 kstat.zfs.misc.arcstats.evict_l2_ineligible: 29462561417216 kstat.zfs.misc.arcstats.l2_hits: 576550808 kstat.zfs.misc.arcstats.l2_misses: 128158998 kstat.zfs.misc.arcstats.l2_feeds: 1524059 kstat.zfs.misc.arcstats.l2_rw_clash: 1429740 kstat.zfs.misc.arcstats.l2_read_bytes: 2896069043200 kstat.zfs.misc.arcstats.l2_write_bytes: 2405022640128 kstat.zfs.misc.arcstats.l2_writes_sent: 826642 kstat.zfs.misc.arcstats.l2_writes_done: 826642 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 1059415 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 1640 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 8580680 kstat.zfs.misc.arcstats.l2_abort_lowmem: 2096 kstat.zfs.misc.arcstats.l2_cksum_bad: 212832715 kstat.zfs.misc.arcstats.l2_io_error: 5501886 kstat.zfs.misc.arcstats.l2_size: 1587962307584 kstat.zfs.misc.arcstats.l2_asize: 1425666718720 kstat.zfs.misc.arcstats.l2_hdr_size: 82346948208 kstat.zfs.misc.arcstats.l2_compress_successes: 41707766 kstat.zfs.misc.arcstats.l2_compress_zeros: 0 kstat.zfs.misc.arcstats.l2_compress_failures: 0 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 8847701930 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 21220076 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 27619372107 kstat.zfs.misc.arcstats.l2_write_in_l2: 418007172085 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 29279 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 131001473113 kstat.zfs.misc.arcstats.l2_write_full: 63699 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 1524059 kstat.zfs.misc.arcstats.l2_write_pios: 826642 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 8433038008130560 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 96529899 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 9228464 Here is output from zfs-stats about L2: [frv:~]$ zfs-stats -L ------------------------------------------------------------------------ ZFS Subsystem Report Mon Oct 7 20:50:19 2013 ------------------------------------------------------------------------ L2 ARC Summary: (DEGRADED) Passed Headroom: 21.22m Tried Lock Failures: 8.85b IO In Progress: 29.32k Low Memory Aborts: 2.10k Free on Write: 8.59m Writes While Full: 63.71k R/W Clashes: 1.43m Bad Checksums: 213.07m IO Errors: 5.51m SPA Mismatch: 27.62b L2 ARC Size: (Adaptive) 1.44 TiB Header Size: 5.19% 76.70 GiB L2 ARC Evicts: Lock Retries: 1.64k Upon Reading: 0 L2 ARC Breakdown: 705.25m Hit Ratio: 81.82% 577.01m Miss Ratio: 18.18% 128.24m Feeds: 1.52m L2 ARC Buffer: Bytes Scanned: 7.49 PiB Buffer Iterations: 1.52m List Iterations: 96.55m NULL List Iterations: 9.23m L2 ARC Writes: Writes Sent: 100.00% 826.96k ---------------------------------------------------------------------- In /boot/loader.conf (128GB RAM in system): vm.kmem_size="110G" vfs.zfs.arc_max="100G" vfs.zfs.arc_min="80G" vfs.zfs.vdev.cache.size=16M vfs.zfs.vdev.cache.max="16384" vfs.zfs.txg.timeout="10" vfs.zfs.write_limit_min="134217728" vfs.zfs.vdev.cache.bshift="14" vfs.zfs.arc_meta_limit=53687091200 vfs.zfs.l2arc_write_max=25165824 vfs.zfs.l2arc_write_boost=50331648 vfs.zfs.l2arc_noprefetch=0 In /etc/sysctl.conf: vfs.zfs.l2arc_write_max=25000000 vfs.zfs.l2arc_write_boost=50000000 vfs.zfs.l2arc_noprefetch=0 vfs.zfs.l2arc_headroom=8 vfs.zfs.l2arc_feed_min_ms=30 vfs.zfs.arc_meta_limit=53687091200 How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total physical size of L2ARC devices 490GB? Why this values can grow and become so high? kstat.zfs.misc.arcstats.l2_cksum_bad: 212832715 kstat.zfs.misc.arcstats.l2_io_error: 5501886 Thanks for any help and ideas! From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 18:32:46 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB6F1BBF for ; Mon, 7 Oct 2013 18:32:46 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80A882838 for ; Mon, 7 Oct 2013 18:32:46 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 09A28220DD for ; Mon, 7 Oct 2013 14:32:45 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 07 Oct 2013 14:32:45 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=BL7qIoKx0QN4ISXpkMxpCbHxTWQ=; b=G7V Jho9HUG4rZKamA4o35HSNDdGLlnpS5F3cfUpkOavXa18m47gg+ctT4IrfYMpECmh 7Dhpjk2SzYgaYzzn1DJQxJpWSPXerlhzMuN7h7pkpTkd/RRMrqs/PuhzlBgb9+JP MOg2CwWIQp9s0kvaDKyNjhSHTrtPK9il2gnBWIo8= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id C99B8114991; Mon, 7 Oct 2013 14:32:44 -0400 (EDT) Message-Id: <1381170764.32684.31088349.343931EE@webmail.messagingengine.com> X-Sasl-Enc: a1ciD5Zqt0+57PfGwqf+CJaxjK5noVToJPWxGRdz3qWo 1381170764 From: Mark Felder To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: <1381166916.122992963.5h9ygiri@frv45.ukr.net> References: <1381166916.122992963.5h9ygiri@frv45.ukr.net> Subject: Re: ZFS L2ARC - incorrect size and abnormal system load on r255173 Date: Mon, 07 Oct 2013 13:32:44 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 18:32:46 -0000 On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote: > > How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total physical size > of L2ARC devices 490GB? > http://svnweb.freebsd.org/base?view=revision&revision=251478 L2ARC compression perhaps? From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:04:43 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D3E728C7 for ; Mon, 7 Oct 2013 19:04:43 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm24-vm1.bullet.mail.gq1.yahoo.com (nm24-vm1.bullet.mail.gq1.yahoo.com [98.136.217.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94B042A22 for ; Mon, 7 Oct 2013 19:04:43 +0000 (UTC) Received: from [98.137.12.59] by nm24.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2013 19:04:37 -0000 Received: from [208.71.42.214] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2013 19:04:37 -0000 Received: from [127.0.0.1] by smtp225.mail.gq1.yahoo.com with NNFMP; 07 Oct 2013 19:04:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381172677; bh=zNOi59ZVnlKe1zzhY/rVzK/4O7FqQkDDiCWaucyvLjQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=k8WoP3MgQzd+x9RWJq8FOJzBMbAkU25IGIMKhfQfBRPtHNI06PthTt7Bo0Fu4kdpy6qEHeKGDW9xqp3jrecYIo+AdBdFkW7QHNMAuv3KutR5ld5aYwNc9qfCT3CSnRponRLcUWNss/M6J7PP16IfcEHHGXjdCjwoIKyTUgrJSM8= X-Yahoo-Newman-Id: 163444.62368.bm@smtp225.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ArHPTS0VM1kNXaER3aqdIWY5JEJkYUxboFPWmt8JAJHbZio 7PDLSEabnqAxdlCyRbuyffbAdusMN2JZ53zO1PAKCm0vxEXpEAak15CBZUms fbkCVHtTZjigQWZ9W8_d2Pta2sUZFO84Q60hu9LnkgrCkazY9fc13OoLGrN5 q.9eK8szRrGT6DeK.4MGSTiNhzPQNKtuzS_IDmON.YEFHRG357yUGGbNOAc2 8Scb0BQpeG_8n2onpaDuVpXZp0F.LIpnl7D_P1OeCjnZlWycU6oVMjABdlrI SZRbHRToAkwrdSNlHbjSc4Gi6kT7Rmu.jZxCTLboFS85SRAnjNHt5TayICci aJwsV3CNm7GfzaNJP_Xz5aAFuA9kMe_90Pp_oqmE0Huihlsq_5MjhxVyg.4t wxta9YCyWxnwXwS8qa_pri_k8bN8u9dR1Z7pmNBl7iv47BiQaJ9AMTITXiJz G.MH1aCEh663g8XsY1OpN3H1YF6Zc5j.tZemXHNFP2SnAlHUaVaNtYD4BcBu v9Oqpd9N4lw83Wh5688LoRCXFkbMS6_DqT_PXmXarhBXOmA1sjHce.PkeEJZ Kdo08h.NtJYDorc4RyHvC3TUfQZigaLzNq4nkrShsLLzEJ6KVuPicz9lL.Lg 0dij8t.QzaS5OLzAE7BYUcaVAm7fJN9Q6ZRE4YEK5uNHE9pia X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp225.mail.gq1.yahoo.com with SMTP; 07 Oct 2013 19:04:37 +0000 UTC Subject: [patch] Re: drm2/radeon dfixed_trunc() warnings From: Sean Bruno To: "freebsd-current@freebsd.org" In-Reply-To: <1381095549.1586.7.camel@localhost> References: <1381095549.1586.7.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-KslReGfPW9C9628YLhIx" Date: Mon, 07 Oct 2013 12:04:36 -0700 Message-ID: <1381172676.3091.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:04:44 -0000 --=-KslReGfPW9C9628YLhIx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sun, 2013-10-06 at 14:39 -0700, Sean Bruno wrote:=20 > These caught my eye today, and the checks strewn about > sys/dev/drm2/radeon seem completely bogus to me, but I don't have the > h/w to test it at the moment. >=20 > /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/rs690.c:491:= 37: warning: comparison of unsigned expression < 0 is always false [-Wtauto= logical-compare] > if (dfixed_trunc(priority_mark02) < 0) >=20 >=20 > dfixed_trunc is a macro: > drm_fixed.h:#define dfixed_trunc(A) ((A).full >> 12) >=20 > that returns the output of a shift right operation ... priority_mark02 > is of type union fixed20_12, single element union of type u32, so I > can't see this check ever doing anything useful. >=20 > But, as always, I'm probably missing something obvious. =20 >=20 > Sean Proposed patch to eliminate this check. If I understand the macro correctly, there's no way for these checks to ever do anything as bit shifting an unsigned will simply clear out the value. So, the check for <0 is completely bogus? Sean http://people.freebsd.org/~sbruno/drm2_radeon_useless.txt=20 --=-KslReGfPW9C9628YLhIx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSUwXBAAoJEBkJRdwI6BaHkV0H/2fKecxd9JKu/1Zsvh5bbqS+ uQYqab0ralSU39cuPCw1+aZ5hM08dBRsCoZS3uddC5GPRBYvvBIICxNVffuqfdSD RJPHFqSo/0wZhkcIFks/MbWSOUMBnsL/IbEu4Nrl6DXVbrJvs0KQuyBxvRkxi8LS ZBATQr6404rkqyi5si8rlpRl7ajQ02OB5f7N7GxwtBU8OkLi2LQPPb3xqiekhNc6 Ff/okihzRdyYeW5B10/wz5uHZkTmsNa7zun4k5aO50KzKh5hBk0DYiEjkGkhShLV tl2yF/TSk70CVlR62x7iZn+hgvcIbD80aEUFXAoCxgHqqQYfahKxfTKmBqqh6ns= =XVwr -----END PGP SIGNATURE----- --=-KslReGfPW9C9628YLhIx-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:04:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0E219D2 for ; Mon, 7 Oct 2013 19:04:52 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B79592A2A for ; Mon, 7 Oct 2013 19:04:52 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id up15so7475884pbc.26 for ; Mon, 07 Oct 2013 12:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1+mR4+1XsoJhDTOV7LnphaFYFpmSHDLmSKjsQkRGW6M=; b=AVbOQ+x/9c6hAeltCHPJMaaC0v+37oTN2UucjLR3ehyV6zXZEddNrY4byEv6e8GqXg cSyv21ehPwiFijmPiVHthrGHmUeQn69uf5DniKs4UcbRApd56Iv7CKS3MSJL3fWJGDu7 JWmfMnuv3dAoe33SCx335APki+iuEZ89YN3fg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1+mR4+1XsoJhDTOV7LnphaFYFpmSHDLmSKjsQkRGW6M=; b=P69ITZna1xXQ+RWIaNlwuckaLjGaFUrVKwXltwlkjgys3s8j+/nw/I4+N7SqKiU7uN NDPpwGK8v5ln7eENnQroICxz2ygzGg2mB9L+AnHKzMgdiupwIp6iCblsLP/91Sz0C6QL 6oAmxsqW6M84rTWVxUT9VhgajadPKuNaL3m5ffk6tCXy2o/2qDuPCailCKyogx2zRCHg 5silz3PDX/7Ijt0oAltwEzRzBi2s1Km2ws64aCU6L42q7/ajxmnfoJYLnODdkpa4fpPT KD5m1pKmUz1KKVkxJH/jASRDBlk67xwY425K7SOEIrWxNiP+W8jQ7EiE15JBjz+meE43 pWcg== X-Gm-Message-State: ALoCoQlAtORrOEq0dLMnLfRBYSunaav30oxBZAQPQc05uEHv8TRW62bez5Qp/SORoY3g2LXHMcpa X-Received: by 10.68.4.197 with SMTP id m5mr32563350pbm.46.1381172692465; Mon, 07 Oct 2013 12:04:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.6.3 with HTTP; Mon, 7 Oct 2013 12:04:22 -0700 (PDT) In-Reply-To: <20131007150658.GA79233@troutmask.apl.washington.edu> References: <20131007150658.GA79233@troutmask.apl.washington.edu> From: Eitan Adler Date: Mon, 7 Oct 2013 15:04:22 -0400 Message-ID: Subject: Re: [Heads Up] RCS removed from base To: Steve Kargl Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:04:52 -0000 On Mon, Oct 7, 2013 at 11:06 AM, Steve Kargl wrote: > On Sun, Oct 06, 2013 at 10:43:21PM -0400, Eitan Adler wrote: >> Hey all, >> >> RCS was removed from the base system in r256095. If you still want to >> use RCS please install either devel/rcs or devel/rcs57. If not, be >> sure to check out the alternatives (pun stolen and intended). >> > > Perhaps, a note in src/UPDATING is appropriate? Absolutely! I've sent a request to re@. -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:08:27 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id D5776C42; Mon, 7 Oct 2013 19:08:27 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 909722A76; Mon, 7 Oct 2013 19:08:27 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VTFt2-000Lbt-E4 ; Mon, 07 Oct 2013 21:50:32 +0300 Date: Mon, 7 Oct 2013 21:50:32 +0300 From: Vitalij Satanivskij To: Mark Felder Subject: Re: ZFS L2ARC - incorrect size and abnormal system load on r255173 Message-ID: <20131007185032.GA82932@hell.ukr.net> References: <1381166916.122992963.5h9ygiri@frv45.ukr.net> <1381170764.32684.31088349.343931EE@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1381170764.32684.31088349.343931EE@webmail.messagingengine.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:08:27 -0000 Data on pool have compressratio around 1.4 On diferent servers with same data type and load L2 ARC Size: (Adaptive) can be diferent for example 1.04 TiB vs 1.45 TiB But it's all have same porblem - grow in time. More stange for us - ARC: 80G Total, 4412M MFU, 5040M MRU, 76M Anon, 78G Header, 2195M Other 78G header size and ubnormal - kstat.zfs.misc.arcstats.l2_cksum_bad: 210920592 kstat.zfs.misc.arcstats.l2_io_error: 7362414 sysctl's growing avery second. All part's of server (as hardware part's) in in normal state. After reboot no problem's for some period untile cache size grow to some limit. Mark Felder wrote: MF> On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote: MF> > MF> > How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total physical size MF> > of L2ARC devices 490GB? MF> > MF> MF> http://svnweb.freebsd.org/base?view=revision&revision=251478 MF> MF> L2ARC compression perhaps? MF> _______________________________________________ MF> freebsd-current@freebsd.org mailing list MF> http://lists.freebsd.org/mailman/listinfo/freebsd-current MF> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:54:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2219D335; Mon, 7 Oct 2013 19:54:18 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56C9C2D87; Mon, 7 Oct 2013 19:54:17 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hj3so5421977wib.7 for ; Mon, 07 Oct 2013 12:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=1StacpTJvA4GeZgXVaL3iLFSyZ3I1jQdD/4aJcwuA6I=; b=Z7QBpD4XVC3NvCFpvzFauX1A05qH56NYm32TullTQ+pAR29tssByVmYR6m31e4DlDY M7ooJIleB+ogdRUUSBW6Efyi/uJPo+ZcoRJY/o+5vK+klYYt7WBNUEUW6BbWGCPtP9in nKnTbIJsiD/uUwTXpl8J5ZLtVZF9naO+mX5h/e8GvX/uZoX9XXzreIrA+1d8yPPOt0Pw KMS71P57nYy7P5xsbeZdC3y4FVuxlbEGAE4aXRCduOlsHi6IWAaExo6lXyR4i/4TlLMN F80eYPF99tuIBkXSlMKUdUDspU+j6HQ0K4huB3MFz4MkWqsgHSLzWs6M4qsa7izRfAR0 Gxzg== MIME-Version: 1.0 X-Received: by 10.180.189.205 with SMTP id gk13mr20307097wic.12.1381175655522; Mon, 07 Oct 2013 12:54:15 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.160.70 with HTTP; Mon, 7 Oct 2013 12:54:15 -0700 (PDT) Date: Mon, 7 Oct 2013 21:54:15 +0200 X-Google-Sender-Auth: UT-vnNHObIgX6J0X5BA0I4Qvxn8 Message-ID: Subject: Changes to UART ns8250 From: Zbigniew Bodek To: freebsd-embedded@freebsd.org Content-Type: multipart/mixed; boundary=001a11c366d052011d04e82c04a8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:54:18 -0000 --001a11c366d052011d04e82c04a8 Content-Type: text/plain; charset=ISO-8859-1 Hello. I would like to present a patch for ns8250 serial that I would like to commit in the near future (if there are no objections). The patch is fixing newest DesignWare UART with busy detection. During frequency divisors configuration when UART is busy transferring or receiving data, line control register manipulation will not take effect. Therefore, we will not set divisor latch access bit and we will corrupt LCR instead of configuring divisors. It is necessary to wait until UART finishes all transfers to proceed with the configuration. This was detected on Armada XP as UART fails on this issue 100/100 attempts. The patch was tested by kevlo@ and me and it works on our Armada XP - based systems. Please send your comment or remarks if there are any. Best regards Zbigniew Bodek --001a11c366d052011d04e82c04a8 Content-Type: application/octet-stream; name="0001-Wait-for-DesignWare-UART-transfers-completion-before.patch" Content-Disposition: attachment; filename="0001-Wait-for-DesignWare-UART-transfers-completion-before.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hmi48egp0 RnJvbSBiMWU0Nzc5OGFlMjY5OGY0MjI3N2YwOTFlODQxZGZiNzEyNTY2MzA0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogU2F0LCA1IE9jdCAyMDEzIDAyOjI1OjIzICswMjAwClN1YmplY3Q6IFtQQVRDSCAxLzNdIFdh aXQgZm9yIERlc2lnbldhcmUgVUFSVCB0cmFuc2ZlcnMgY29tcGxldGlvbiBiZWZvcmUKIGFjY2Vz c2luZyBsaW5lIGNvbnRyb2wKCldoZW4gdXNpbmcgRFcgVUFSVCB3aXRoIEJVU1kgZGV0ZWN0aW9u IGl0IGlzIG5lY2Vzc2FyeSB0byB3YWl0CnVudGlsIGFsbCBzZXJpYWwgdHJhbnNmZXJzIGFyZSBm aW5pc2hlZCBiZWZvcmUgbWFuaXB1bGF0aW5nIHRoZQpsaW5lIGNvbnRyb2wuIExDUiB3aWxsIG5v dCBiZSBhZmZlY3RlZCB3aGVuIFVBUlQgaXMgYnVzeS4KSW4gYWRkaXRpb24sIGlmIERpdmlzb3Ig TGF0Y2ggQWNjZXNzIEJpdCBpcyBiZWluZyBzZXQgaW4gb3JkZXIgdG8KbW9kaWZ5IFVBUlQgZGl2 aXNvcnM6CjEuIFdlIHdpbGwgZ2V0IEJVU1kgaW50ZXJydXB0IGlmIGludGVycnVwdHMgYXJlIGVu YWJsZWQuCjIuIEJlY2F1c2UgTENSIHdpbGwgbm90IGJlIGFmZmVjdGVkIHRoZSBUSFIgYW5kIChl dmVuIHdvcnNlKSBJRVIKICAgY29udGVudHMgd2lsbCBiZSBjb3JydXB0ZWQuIFRoaXMgd2lsbCBs ZWFkIHRvIGNvbnNvbGUgaGFuZy4KClRlc3RlZCBieToJa2V2bG8KQXBwcm92ZWQgYnk6CWNvZ25l dCAobWVudG9yKQotLS0KIHN5cy9kZXYvaWMvbnMxNjU1MC5oICAgICAgICAgICB8ICAxICsKIHN5 cy9kZXYvdWFydC91YXJ0X2Rldl9uczgyNTAuYyB8IDEwICsrKysrKysrKysKIDIgZmlsZXMgY2hh bmdlZCwgMTEgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3N5cy9kZXYvaWMvbnMxNjU1MC5o IGIvc3lzL2Rldi9pYy9uczE2NTUwLmgKaW5kZXggNjU5ZjU5MS4uMzNhN2RkMSAxMDA2NDQKLS0t IGEvc3lzL2Rldi9pYy9uczE2NTUwLmgKKysrIGIvc3lzL2Rldi9pYy9uczE2NTUwLmgKQEAgLTE4 NSw2ICsxODUsNyBAQAogI2RlZmluZSBEV19SRUdfVVNSCTMxCS8qIERlc2lnbldhcmUgZGVyaXZl ZCBVYXJ0IFN0YXR1cyBSZWcgKi8KICNkZWZpbmUgY29tX3VzcgkJMzkJLyogT2N0ZW9uIDE2NzUw LzE2NTUwIFVhcnQgU3RhdHVzIFJlZyAqLwogI2RlZmluZSBSRUdfVVNSCQljb21fdXNyCisjZGVm aW5lIFVTUl9CVVNZCTEJLyogVWFydCBCdXN5LiBTZXJpYWwgdHJhbnNmZXIgaW4gcHJvZ3Jlc3Mg Ki8KICNkZWZpbmUgVVNSX1RYRklGT19OT1RGVUxMIDIgICAgLyogVWFydCBUWCBGSUZPIE5vdCBm dWxsICovCiAKIC8qIDE2OTUwIHJlZ2lzdGVyICMxLiAgQWNjZXNzIGVuYWJsZWQgYnkgQUNSWzdd LiAgQWxzbyByZXF1aXJlcyAhTENSWzddLiAqLwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi91YXJ0L3Vh cnRfZGV2X25zODI1MC5jIGIvc3lzL2Rldi91YXJ0L3VhcnRfZGV2X25zODI1MC5jCmluZGV4IDIx MWQxMTMuLjVjOTM5Y2UgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvdWFydC91YXJ0X2Rldl9uczgyNTAu YworKysgYi9zeXMvZGV2L3VhcnQvdWFydF9kZXZfbnM4MjUwLmMKQEAgLTY0NywxMSArNjQ3LDIx IEBAIGludAogbnM4MjUwX2J1c19wYXJhbShzdHJ1Y3QgdWFydF9zb2Z0YyAqc2MsIGludCBiYXVk cmF0ZSwgaW50IGRhdGFiaXRzLAogICAgIGludCBzdG9wYml0cywgaW50IHBhcml0eSkKIHsKKwlz dHJ1Y3QgbnM4MjUwX3NvZnRjICpuczgyNTA7CiAJc3RydWN0IHVhcnRfYmFzICpiYXM7CiAJaW50 IGVycm9yOwogCisJbnM4MjUwID0gKHN0cnVjdCBuczgyNTBfc29mdGMqKXNjOwogCWJhcyA9ICZz Yy0+c2NfYmFzOwogCXVhcnRfbG9jayhzYy0+c2NfaHdtdHgpOworCS8qCisJICogV2hlbiB1c2lu ZyBEVyBVQVJUIHdpdGggQlVTWSBkZXRlY3Rpb24gaXQgaXMgbmVjZXNzYXJ5IHRvIHdhaXQKKwkg KiB1bnRpbCBhbGwgc2VyaWFsIHRyYW5zZmVycyBhcmUgZmluaXNoZWQgYmVmb3JlIG1hbmlwdWxh dGluZyB0aGUKKwkgKiBsaW5lIGNvbnRyb2wuIExDUiB3aWxsIG5vdCBiZSBhZmZlY3RlZCB3aGVu IFVBUlQgaXMgYnVzeS4KKwkgKi8KKwl3aGlsZSAobnM4MjUwLT5idXN5X2RldGVjdCAhPSAwICYm CisJICAgICh1YXJ0X2dldHJlZyhiYXMsIERXX1JFR19VU1IpICYgVVNSX0JVU1kpICE9IDApCisJ CTsKIAllcnJvciA9IG5zODI1MF9wYXJhbShiYXMsIGJhdWRyYXRlLCBkYXRhYml0cywgc3RvcGJp dHMsIHBhcml0eSk7CiAJdWFydF91bmxvY2soc2MtPnNjX2h3bXR4KTsKIAlyZXR1cm4gKGVycm9y KTsKLS0gCjEuOC40Cgo= --001a11c366d052011d04e82c04a8-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:58:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C2C316BA; Mon, 7 Oct 2013 19:58:40 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 366952DD6; Mon, 7 Oct 2013 19:58:39 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBE81A.dip0.t-ipconnect.de [217.251.232.26]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id r97JwUHR041530; Mon, 7 Oct 2013 19:58:31 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id r97JwHIQ040925; Mon, 7 Oct 2013 21:58:17 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id r97Jw56I096162; Mon, 7 Oct 2013 21:58:11 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201310071958.r97Jw56I096162@fire.js.berklix.net> To: Gleb Kurtsou Subject: Re: Committing PEFS to CURRENT From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Mon, 07 Oct 2013 09:31:11 PDT." <20131007163111.GB1590@reks.swifttest.com> Date: Mon, 07 Oct 2013 21:58:05 +0200 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org, delphij@freebsd.org, Kris Moore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:58:40 -0000 Hi Gleb & All Gleb Kurtsou wrote: > Hello, > > I would like to ask everybody's opinion regarding committing PEFS to > CURRENT. > > PEFS is a stacked cryptographic file system for FreeBSD. Development > started as Google Summer of Code project in 2009. It has been in ports > since Sept 2011. I maintain the project. > > Conceptually PEFS is similar to nullfs adding encryption layer on top of > it. But it differs technically by not using vop_bypass. Another popular > stacked cryptographic file systems include eCryptfs (linux) and encfs > (fuse). There is also pam_pefs pam module to allow user authentication > with their PEFS-encrypted home directory password. 2 others are also already in FreeBSD src/ (not just ports) gbde & geli. Whether moved from ports to src or not, either way, I sggest add to man section SEE ALSO gbde(8) & geli(8) Also, SEE ALSO of gbde & geli should probably ref ports/sysutils/pefs-kmod ft: Command not found. No pefs yet i SEE ALSO of http://www.freebsd.org/cgi/man.cgi?query=gbde&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=8&manpath=FreeBSD+9.2-RELEASE&arch=default&format=html I suggest add an href inside: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html Even if just a 1 liner to start, to expand to a section later. (None there for 'pefs', I just searched) Personaly I've been using gbde based on top of a file inside a UFS for a long time, I can't remember why I chose gbde rather than geli, I guess because it was there first ? A dummy's guide short notes along the lines of "Which of these 3 should I use?" might also later be nice at the top of that web page :-) Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:59:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5382D7CB for ; Mon, 7 Oct 2013 19:59:01 +0000 (UTC) (envelope-from freebsd@allanjude.com) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 311902DE5 for ; Mon, 7 Oct 2013 19:59:00 +0000 (UTC) Received: from [10.1.1.1] (S01060001abad1dea.hm.shawcable.net [50.70.108.129]) (Authenticated sender: allan.jude@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 664741D106 for ; Mon, 7 Oct 2013 19:58:53 +0000 (UTC) Message-ID: <52531295.7090700@allanjude.com> Date: Mon, 07 Oct 2013 15:59:17 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:59:01 -0000 Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 19:25:29 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id 66C6D80A for ; Mon, 7 Oct 2013 19:25:29 +0000 (UTC) (envelope-from BSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by mx1.freebsd.org (Postfix) with ESMTP id F394F2BC9 for ; Mon, 7 Oct 2013 19:25:28 +0000 (UTC) Received: from ppp118-210-127-6.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.127.6]) by ipmail06.adl2.internode.on.net with ESMTP; 08 Oct 2013 05:55:28 +1030 Message-ID: <52530AA5.7000304@ShaneWare.Biz> Date: Tue, 08 Oct 2013 05:55:25 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130516 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Continuous timeout messages from 10.0 alpha4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 07 Oct 2013 20:09:11 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:25:29 -0000 Resending to current This is a regression between alpha2 and alpha4. I first setup a disk to boot 10 just after alpha2 was tagged. A few days ago I updated to alpha4 and started getting timeout messages, I have just built alpha5 r256098 and still get them. I just had 10 running for a few hours and 3 of the messages log archives which syslog rotates each hour due to size contain 3370 2508 and 3162 timeout messages over 3 hours uptime. each entry is similar to -- Oct 7 19:00:02 leader kernel: ahcich1: Timeout on slot 15 port 0 Oct 7 19:00:02 leader kernel: ahcich1: is 40000001 cs 00008000 ss 00000000 rs 00008000 tfd 2451 serr 00000000 cmd 00004f17 With slot x cycling from 0-31 but not always in sequence. MB is ASUS P8H61M LE/USB3 - corei5 - 8MB - nvidia GT520 ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported With the following connected to ahcich1 (LG blu-ray burner) cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device Most relevant dmesg info would be (full dmesg/logs available) -- ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ada1 at ahcich4 bus 0 scbus2 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad8 ada2 at ahcich5 bus 0 scbus3 target 0 lun 0 ada2: ATA-6 SATA 2.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 512bytes) ada2: 76324MB (156312576 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad10 ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 20:11:36 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57146321; Mon, 7 Oct 2013 20:11:36 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 109292F11; Mon, 7 Oct 2013 20:11:36 +0000 (UTC) Received: from glenbarber.us (c-71-224-221-174.hsd1.nj.comcast.net [71.224.221.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id 7221882C4; Mon, 7 Oct 2013 20:11:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us 7221882C4 Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 7 Oct 2013 16:11:32 -0400 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-snapshots@FreeBSD.org Subject: FreeBSD 10.0-ALPHA5 now available Message-ID: <20131007201132.GA3890@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-ALPHA4 amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:11:36 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The fifth ALPHA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The 10.0-ALPHA5 builds correlate to svn revision r256092 of the head/ branch. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ (or any of the FreeBSD mirror sites). If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. If you would like to use SVN to do a source based update of an existing system, use the "head/" branch. Please be aware that cvsup and CVS are not supported methods of updating the src/ tree. Important note to freebsd-update(8) users: freebsd-update(8) is not a supported upgrade path for the 10.0-ALPHA builds. Changes between -ALPHA4 and -ALPHA5 include: - Removal of BIND from the base system; replacements may be found within the Ports Collection. - Bug fix introduced with the latest infiniband update. - The GNU ar(1) and ranlib(1) have been removed from the base system. - Bug fixes and updates to the base llvm. - Various bhyve enhancements. - Various XEN enhancements. Checksums: amd64: SHA256 (FreeBSD-10.0-ALPHA5-amd64-bootonly.iso) = a77eefe1d8e14dc790573c6b942cd91cd5bd40f14d16b9e47696d50efa3f7b29 SHA256 (FreeBSD-10.0-ALPHA5-amd64-disc1.iso) = 4b93431f2d72a30e149cbb35cae365e90eb795bfb03186446984f6fa7a8ea167 SHA256 (FreeBSD-10.0-ALPHA5-amd64-memstick.img) = e8d168d68a6bae170238a9c07999d7d697ee1eba68704b4b5f30fadd4f955a8d MD5 (FreeBSD-10.0-ALPHA5-amd64-bootonly.iso) = 634f132e07922d8a09c338f5009034b8 MD5 (FreeBSD-10.0-ALPHA5-amd64-disc1.iso) = 42ae98b45bc74728e61653c8154024e6 MD5 (FreeBSD-10.0-ALPHA5-amd64-memstick.img) = be8c9ce57c26ca02b4628857f4377894 i386: SHA256 (FreeBSD-10.0-ALPHA5-i386-bootonly.iso) = 98ac167991c52cba1902905a6f0cd804361f3692396fb0ecd60060cfde8fb33c SHA256 (FreeBSD-10.0-ALPHA5-i386-disc1.iso) = 02d2cf027aae152bb4c70a32db1a7b3401733f7bd62cc4871aa6ada9405f16af SHA256 (FreeBSD-10.0-ALPHA5-i386-memstick.img) = f407616cce2ca9884014baf150ecbef48e6afc39e8ae04b49c42ca7b335c25e1 MD5 (FreeBSD-10.0-ALPHA5-i386-bootonly.iso) = 2df6f291e9d6e66bfe96b14523249f4a MD5 (FreeBSD-10.0-ALPHA5-i386-disc1.iso) = 999eb957675040629b2d02f851495977 MD5 (FreeBSD-10.0-ALPHA5-i386-memstick.img) = 2543707c92cf6cc3414b7492bb2e0727 ia64: SHA256 (FreeBSD-10.0-ALPHA5-ia64-bootonly.iso) = d24f816b8d87dbe5af8fe982fdeb4bb09badd81c61313dc420a513356a8c3a69 SHA256 (FreeBSD-10.0-ALPHA5-ia64-disc1.iso) = 302d23354f4046b8fe91266cac407f024d6a73ddd040c1181a37a07118fc130f SHA256 (FreeBSD-10.0-ALPHA5-ia64-memstick.img) = 0b8214d14a709ff3817a55968e8ae2c25f6e8b35ab96842d315ef786aa93ba13 MD5 (FreeBSD-10.0-ALPHA5-ia64-bootonly.iso) = 7a7f7c16202b6575943ce5e8f3fe9048 MD5 (FreeBSD-10.0-ALPHA5-ia64-disc1.iso) = 1e78b1c39773f4ee999c82074bad0d68 MD5 (FreeBSD-10.0-ALPHA5-ia64-memstick.img) = c8ec96004ddf8de5e62524dd074ee7a1 powerpc: SHA256 (FreeBSD-10.0-ALPHA5-powerpc-bootonly.iso) = 9ee848156256e46efc067295e7b2d6a95050dfee75e5917bfa1cbda25f950dd8 SHA256 (FreeBSD-10.0-ALPHA5-powerpc-disc1.iso) = cb6214a2691ba2d4090228d35abfc04d249b42b920e0d0081ae09b9dd5ee3f65 SHA256 (FreeBSD-10.0-ALPHA5-powerpc-memstick.img) = 1890435a15ad62893ab880af721d16aa7d70c8297cdbaf9c496dc9e6ee9b3b87 MD5 (FreeBSD-10.0-ALPHA5-powerpc-bootonly.iso) = 677a138a9cfa139e03f91c1a2150fa47 MD5 (FreeBSD-10.0-ALPHA5-powerpc-disc1.iso) = 9b5d07e41c8871ac1ab56f543a89ce8a MD5 (FreeBSD-10.0-ALPHA5-powerpc-memstick.img) = 1c9000b369fdc5dac54df43329f9a8d0 powerpc64: SHA256 (FreeBSD-10.0-ALPHA5-powerpc-powerpc64-bootonly.iso) = 2f6fcbdc1577e908511b98b631331489971fb3e7f0d3b6cdfb2be0b8b05898a1 SHA256 (FreeBSD-10.0-ALPHA5-powerpc-powerpc64-disc1.iso) = cf62b59fd58f40103d340cacb67e38facefb8006f6927e9b1ba319ac611668c9 SHA256 (FreeBSD-10.0-ALPHA5-powerpc-powerpc64-memstick.img) = 6f01baad645819d44a45130cf9f973b2cc99760cab82800ac1fda07881e0235e MD5 (FreeBSD-10.0-ALPHA5-powerpc-powerpc64-bootonly.iso) = 7e4d5996cf2c566724651454abaf08d3 MD5 (FreeBSD-10.0-ALPHA5-powerpc-powerpc64-disc1.iso) = a8b4c40f76b844761d3d84be11c0b517 MD5 (FreeBSD-10.0-ALPHA5-powerpc-powerpc64-memstick.img) = 95d412c35fcba1abb62fdef5f28d6e32 sparc64: SHA256 (FreeBSD-10.0-ALPHA5-sparc64-bootonly.iso) = 7fc48a5098948da7c9b89b6b496bd2942b30e9f4cfe21fe12b62401bdc9fc69a SHA256 (FreeBSD-10.0-ALPHA5-sparc64-disc1.iso) = 8bdaf1ea56e814bb2aba5953fb00ec95d9813dc1f63d83a274cab954a1435e93 MD5 (FreeBSD-10.0-ALPHA5-sparc64-bootonly.iso) = b81d78160fe7ee1092aca01833399ce1 MD5 (FreeBSD-10.0-ALPHA5-sparc64-disc1.iso) = df475bfba115e7c16a43a1832bd5d8a3 Glen --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJSUxV0AAoJELls3eqvi17Q93MP/j9sp2iVNJ3VmBLPonuUDs0c 6gersMZ0SItJ6/9/aP8Sc81I+s7FX6//gi2kAoX3tF0/pblSeigxRqW8GdkW9Msl sqiFy2g8rFtGfOjWgKyioQdxFZ/igFy6bKedqYwjgziLdZ8jifu4n6FFVBjruBTp zuvKtnBUpH0pjyw7koowOPG4M9aO/cSSy2RVZzewTmdT5aKftu+g+4d4uff9pI6G MLOJLPNi2827KW70x76nRPbWArSbcdrxSo1Rd9YSVTXhyxFT+Md3MI9TEhzVVnHG WugJIxilnBlFwbl0+xfF2j2Oi6NvgbmKr0TSYf47xEuRePG/2fCtnCgYrqfaEd1l j251+y+AuFESbXEASBiockvhBcWqJDPmEjHb0ODFU0Uele5oEdh6fO65MbJvOonR 9nbnAzB9txZ+dX0KbCTshR1w3EXbThJ+B2gpjsqc2iPfY+2jJupizq/f3iK0pWaJ NVv0IqOwuTveVXwCjs0E+afjaX0oERAx8YH17gJ2wt3X7dA+gdW6c4nd/GkUH2ZG qcFI9YvFza4kKrm7BZzxozwrnHLTiAIjBHH7obz8tfALTbWqRisJNhyUUb3+cMl8 wtJO0Qtu1GCTQDkfgo95KMeoRho2hWPKaTIzQwYn9LxfgJmnQbY+PHxeq/YrMmHR EmbV6vYhrO7dySZ2MYe0 =rhI3 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 20:15:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 714EF9EE; Mon, 7 Oct 2013 20:15:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F02642F5C; Mon, 7 Oct 2013 20:15:16 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 6so2989873qeb.31 for ; Mon, 07 Oct 2013 13:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GBi01RdvJa/jwavzBSnrAgiK0r5Pe0/Yd32ZEQ1tCaY=; b=EQ0J3ofsKVb1ZY3Ic6c+NjMShUYPzdNjIRcZCjac15iWxDdq9Jikldf+Ih0rJ3xJCX x07aPl+P6H8k3tcv2SGsFAIS+yF5PqOV6BuHe7YBmCYyJ2svUwNg8nt2zLRxRWgW95Mu AsKFvkawrDvx3UJ/qCpmEdNbeRQ++a5CSYhPH4ipC3KXuYE40Z9Gj0onnqcpjZpCZVts bJb5VvASZwtVhn5oUnIl8Cdio+KNy8rwDHoSwF+mULxy5jl9n7ourKYCEG9uQipR1Uvi YGGMK5qaTfJrVvjVUF068j9NxvsQfOIMxSjsPONb0+D8RvaMnb9kzEdvNxzkrKlF4AjA 1PMg== MIME-Version: 1.0 X-Received: by 10.224.157.14 with SMTP id z14mr5169015qaw.90.1381176916112; Mon, 07 Oct 2013 13:15:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 7 Oct 2013 13:15:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 13:15:16 -0700 X-Google-Sender-Auth: NNgCXYLGRSNjy6J5wKblc7oqS8I Message-ID: Subject: Re: Changes to UART ns8250 From: Adrian Chadd To: Zbigniew Bodek Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" , freebsd-current , "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:15:17 -0000 Hi, You should add: * a loop counter, to break out after a while; * a DELAY(1) or something. -adrian On 7 October 2013 12:54, Zbigniew Bodek wrote: > Hello. > > I would like to present a patch for ns8250 serial that I would like to > commit in the near future (if there are no objections). > > The patch is fixing newest DesignWare UART with busy detection. > During frequency divisors configuration when UART is busy transferring or > receiving data, line control register manipulation will not take effect. > Therefore, we will not set divisor latch access bit and we will corrupt LCR > instead of configuring divisors. > It is necessary to wait until UART finishes all transfers to proceed with > the configuration. > > This was detected on Armada XP as UART fails on this issue 100/100 > attempts. > The patch was tested by kevlo@ and me and it works on our Armada XP - > based > systems. > > Please send your comment or remarks if there are any. > > Best regards > Zbigniew Bodek > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 20:17:59 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id B6448DEE for ; Mon, 7 Oct 2013 20:17:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c: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 7682E2F9D for ; Mon, 7 Oct 2013 20:17:59 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id oy12so4091609veb.13 for ; Mon, 07 Oct 2013 13:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z68pefEkzjabQ29Jc54bC1orC639ukK4B/2glTxsg8Q=; b=qdQd1adM9dVK0OivJ7GsL10Cw+5flzvX8Xdpbmi2aRbhN9V0c+AhuhOIU//2zRfv39 geE+gKrpDCwUzxD7mD7hBzTsDmiSUdq9Hj4dCHnp9CRDzr7r5BBIwlYW/6B/h0/4Je3h eexQH529uWIbN32GUpVQl/kFby3NXVG/QZeJjMn7pb0pKwrbKvUumhFj8Hkl+FwlkHTc O29kXD5Q0FgAhDmgJX1bzsG6BCUJRdI7t7N2iAk7clSyHkkoxmk+/O1gXqaKsvI0UJXi Uv3n36rc9DGJQeieyWsOkt71jF1DZFo3BuIhqcSOb5ibE3gLOOBA/NXDTpb5BzLFMQ2B dl4w== MIME-Version: 1.0 X-Received: by 10.52.64.143 with SMTP id o15mr23798052vds.16.1381177078551; Mon, 07 Oct 2013 13:17:58 -0700 (PDT) Received: by 10.220.65.4 with HTTP; Mon, 7 Oct 2013 13:17:58 -0700 (PDT) In-Reply-To: <52530AA5.7000304@ShaneWare.Biz> References: <52530AA5.7000304@ShaneWare.Biz> Date: Mon, 7 Oct 2013 16:17:58 -0400 Message-ID: Subject: Re: Continuous timeout messages from 10.0 alpha4 From: Mark Johnston To: Shane Ambler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:17:59 -0000 Rebuilding sysutils/hal should fix this problem. It's been reported several times in the past week or two, and rebuilding this port fixed it for me when I ran into it. On Mon, Oct 7, 2013 at 3:25 PM, Shane Ambler wrote: > Resending to current > > This is a regression between alpha2 and alpha4. I first setup a disk to > boot 10 just after alpha2 was tagged. A few days ago I updated to > alpha4 and started getting timeout messages, I have just built alpha5 > r256098 and still get them. > > I just had 10 running for a few hours and 3 of the messages log archives > which syslog rotates each hour due to size contain 3370 2508 and 3162 > timeout messages over 3 hours uptime. > > each entry is similar to -- > Oct 7 19:00:02 leader kernel: ahcich1: Timeout on slot 15 port 0 > Oct 7 19:00:02 leader kernel: ahcich1: is 40000001 cs 00008000 ss > 00000000 rs 00008000 tfd 2451 serr 00000000 cmd 00004f17 > > With slot x cycling from 0-31 but not always in sequence. > > MB is ASUS P8H61M LE/USB3 - corei5 - 8MB - nvidia GT520 > > ahci0: port > 0xf070-0xf077,0xf060-0xf063,**0xf050-0xf057,0xf040-0xf043,**0xf020-0xf03f > mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported > > With the following connected to ahcich1 (LG blu-ray burner) > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > > > > Most relevant dmesg info would be (full dmesg/logs available) -- > > ahci0: port > 0xf070-0xf077,0xf060-0xf063,**0xf050-0xf057,0xf040-0xf043,**0xf020-0xf03f > mem 0xfb305000-0xfb3057ff irq 20 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 4 3Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > ahciem0: on ahci0 > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad4 > ada1 at ahcich4 bus 0 scbus2 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > ada1: Previously was known as ad8 > ada2 at ahcich5 bus 0 scbus3 target 0 lun 0 > ada2: ATA-6 SATA 2.x device > ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 512bytes) > ada2: 76324MB (156312576 512 byte sectors: 16H 63S/T 16383C) > ada2: Previously was known as ad10 > ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > From owner-freebsd-current@FreeBSD.ORG Mon Oct 7 20:25:06 2013 Return-Path: Delivered-To: freebsd-current@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 ESMTP id B7BE812E for ; Mon, 7 Oct 2013 20:25:06 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B9672059 for ; Mon, 7 Oct 2013 20:25:06 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id 1so1841449qec.41 for ; Mon, 07 Oct 2013 13:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kiWPEGg7cg72WuyE3rM5Oa1vtz1A/XOdGcSIzkmvSAg=; b=rhrXTkjnnwOEkPSzrh38SPEx/RpNb4lHTeSwzHMron6FS22GafCBqtVbC5u5k+91n5 1UOuXroFFLdIahXuX9orTf2QeYxs/DhPwo6bli0UM0kXWIsm8j+GMITAAa+5UHBZyQhJ mFwtO0O6SOaZeQNUeTBDGeijD2+WWEyrYRECcnupWd46Zu6l/4olSf5vP0Z1Rd98t3HI UR68uhMXHvXfSRLFvzpHyu0WIGTWm6t7hqAx9Jfypj5HLaQEXakYS9wEquFpW53WCjE0 nZEoGrNI693FeBd5BZ/yHQVkAABM5oU8POwtfT0QZShwNDM3lWSnjtIlmp413mfP6r7Y cXcw== MIME-Version: 1.0 X-Received: by 10.224.11.133 with SMTP id t5mr40212118qat.34.1381177505518; Mon, 07 Oct 2013 13:25:05 -0700 (PDT) Received: by 10.229.114.5 with HTTP; Mon, 7 Oct 2013 13:25:05 -0700 (PDT) In-Reply-To: <5252E6F6.80009@mail.lifanov.com> References: <20131007163111.GB1590@reks.swifttest.com> <5252E6F6.80009@mail.lifanov.com> Date: Mon, 7 Oct 2013 13:25:05 -0700 Message-ID: Subject: Re: Committing PEFS to CURRENT From: Gleb Kurtsou To: Nikolai Lifanov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:25:06 -0000 On Mon, Oct 7, 2013 at 9:53 AM, Nikolai Lifanov wrote: > On 10/07/13 12:31, Gleb Kurtsou wrote: >> Hello, >> >> I would like to ask everybody's opinion regarding committing PEFS to >> CURRENT. >> >> PEFS is a stacked cryptographic file system for FreeBSD. Development >> started as Google Summer of Code project in 2009. It has been in ports >> since Sept 2011. I maintain the project. >> >> Conceptually PEFS is similar to nullfs adding encryption layer on top of >> it. But it differs technically by not using vop_bypass. Another popular >> stacked cryptographic file systems include eCryptfs (linux) and encfs >> (fuse). There is also pam_pefs pam module to allow user authentication >> with their PEFS-encrypted home directory password. >> >> For those interested in high level introduction I would highly recommend >> article by Kris Moore in the BSD Magazine Issue 09/2013(50) - >> http://bsdmag.org/magazine/1848-day-to-day-bsd-administration >> >> We are very close to branching 10-STABLE now, but patch is >> non-intrusive, it only adds new functionality, enabling PEFS for i386 >> and amd64 (platforms it's known to work on). Patch passes make universe. >> >> Patch is available here: >> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch >> >> Pros/cons: >> >> - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS >> who are already committed to use PEFS in next product releases, e.g. >> PCBSD provides encrypted home director