From owner-freebsd-current@FreeBSD.ORG Sun May 3 02:25:15 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0127C227 for ; Sun, 3 May 2015 02:25:14 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C64DB12AA for ; Sun, 3 May 2015 02:25:14 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so125201731ied.1 for ; Sat, 02 May 2015 19:25:14 -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=xdj86CKEGZS6d6wx1IiLMj5MNbz3VuhsKEtsRd8BWYQ=; b=G7dT2mDeD8geYMt1Cesa84VrgnQofxSnYrBCWFkXJSKdjeFde+gHAeTI+Titmf0AmH 9yDVAU/nxunM16d5rMzyWpNvAlrs7ilsfIpLiegt8cj7DaRgfI1ilRzzY2wBcBBY0SCO qkv0ByYYFWgplBOJvSJLex/Pdn+eQHCAiI1Zm0ukCQoHbLZvfwden4Uo17Iusaa5/Bj+ ngC6hKDdVNBi78GmT2u1GC+y+UEg7erYOF4PWvr97QHb37zlIugSoQ+ZWYaYrZF1X0RZ kRsjE/NGPyOtj/QfbdmsFavwMA0oiS8AX1k/HK/Hcxfq5j+jvMRNehluLRDgFrD9hWpr tBBw== MIME-Version: 1.0 X-Received: by 10.107.168.143 with SMTP id e15mr20180272ioj.88.1430619914022; Sat, 02 May 2015 19:25:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Sat, 2 May 2015 19:25:13 -0700 (PDT) In-Reply-To: <20150324155426.M7719@admin16.site.uottawa.ca> References: <20150319095306.C7719@admin16.site.uottawa.ca> <528B3B45-378E-44CD-A286-0269E84C4F70@me.com> <54997.66.186.85.232.1427195954.squirrel@courriel.site.uottawa.ca> <1A6D6059-21A2-467C-979D-E413623753FD@me.com> <20150324155426.M7719@admin16.site.uottawa.ca> Date: Sat, 2 May 2015 19:25:13 -0700 X-Google-Sender-Auth: 33pWNy-c0CThNYZ9zlktafxBXH8 Message-ID: Subject: Re: panic: UMA: Increase vm.boot_pages on Dell R920 r279210 From: Adrian Chadd To: Keith White Cc: Rui Paulo , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 02:25:15 -0000 hi, Hm, should we be upping this limit automatically? Can we get cpu counts or memory amount early enough in boot to have a hope of auto-tuning? 64 seems low, 1024 seems high as a default. :) -adrian On 24 March 2015 at 13:00, Keith White wrote: > On Tue, 24 Mar 2015, Rui Paulo wrote: > >> On Mar 24, 2015, at 04:19, kwhite@site.uottawa.ca wrote: >>> >>> >>> I'm using /boot/loader.conf. Is there another place I should be doing >>> this? >> >> >> No, that's correct, but apparently there's a problem: the RDTUN sysctl is >> not picked up early enough. Can you try this patch? I haven't really >> tested it. :-) >> >> diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c >> index 79665ba..a764788 100644 >> --- a/sys/vm/vm_page.c >> +++ b/sys/vm/vm_page.c >> @@ -134,8 +134,9 @@ long first_page; >> int vm_page_zero_count; >> >> static int boot_pages = UMA_BOOT_PAGES; >> -SYSCTL_INT(_vm, OID_AUTO, boot_pages, CTLFLAG_RDTUN, &boot_pages, 0, >> - "number of pages allocated for bootstrapping the VM system"); >> +SYSCTL_INT(_vm, OID_AUTO, boot_pages, CTLFLAG_RDTUN | CTLFLAG_NOFETCH, >> + &boot_pages, 0, >> + "number of pages allocated for bootstrapping the VM system"); >> >> static int pa_tryrelock_restart; >> SYSCTL_INT(_vm, OID_AUTO, tryrelock_restart, CTLFLAG_RD, >> @@ -349,6 +350,7 @@ vm_page_startup(vm_offset_t vaddr) >> * Allocate memory for use when boot strapping the kernel memory >> * allocator. >> */ >> + TUNABLE_INT_FETCH("vm.boot_pages", &boot_pages); >> new_end = end - (boot_pages * UMA_SLAB_SIZE); >> new_end = trunc_page(new_end); >> mapped = pmap_map(&vaddr, new_end, end, >> @@ -443,7 +445,7 @@ vm_page_startup(vm_offset_t vaddr) >> >> >> -- >> Rui Paulo > > > Patch tried. Success! > > I now get this after setting vm.boot_pages=1024 in /boot/loader.conf: > > Booting... > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #1: Tue Mar 24 13:44:48 UTC 2015 > root@:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 > WARNING: WITNESS option enabled, expect reduced performance. > UMA startup boot_pages: 1024 > ... > > And can start all 120 processors. > > Thanks! > > ...keith > -- > Keith White, genie.uottawa.ca engineering.uottawa.ca > kwhite@uottawa.ca [+1 613 562 5800 x6681] > _______________________________________________ > 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 Sun May 3 11:59:16 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23B28658 for ; Sun, 3 May 2015 11:59:16 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A53EB1580 for ; Sun, 3 May 2015 11:59:15 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t43Brl2B001798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 3 May 2015 13:53:48 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t43C3nRf042514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 3 May 2015 14:03:49 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.9/8.14.9/Submit) id t43C3n7L042511 for freebsd-current@freebsd.org; Sun, 3 May 2015 14:03:49 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sun, 3 May 2015 14:03:49 +0200 From: Wolfgang Zenker To: freebsd-current@freebsd.org Subject: mergemaster failing with read-only /usr/src Message-ID: <20150503120349.GA42415@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: private site User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sun, 03 May 2015 13:53:48 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 11:59:16 -0000 Hi, I'm trying to update this system: FreeBSD pomona 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Mon Apr 13 03:48:04 CEST 2015 wolfgang@pomona:/usr/obj/usr/src/sys/UBQTERL mips Source for that was probably from about April 11th. I sucessfully built world and kernel, ran mergemaster -p and make installworld on rev 282299 but then mergemaster fails with: # mergemaster -iFU *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot /bin/sh: cannot create routing_test.tmp: Read-only file system *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to the temproot environment Filesystems are mounted like this: # mount /dev/da0s2a on / (ufs, local, noatime) devfs on /dev (devfs, local, multilabel) /dev/da0s1 on /boot (msdosfs, local) vulcan.lyx:/usr/src11 on /usr/src (nfs, read-only) vulcan.lyx:/var/obj/11/mips64 on /usr/obj (nfs) This used to work before. Any ideas, any further info I could provide? Wolfgang From owner-freebsd-current@FreeBSD.ORG Sun May 3 12:53:29 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D9D5D3D; Sun, 3 May 2015 12:53:29 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 42CA51A7D; Sun, 3 May 2015 12:53:28 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 4EE8A358C68; Sun, 3 May 2015 14:53:25 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 3744728494; Sun, 3 May 2015 14:53:25 +0200 (CEST) Date: Sun, 3 May 2015 14:53:25 +0200 From: Jilles Tjoelker To: Wolfgang Zenker Cc: freebsd-current@freebsd.org, Will Andrews , Garrett Cooper Subject: Re: mergemaster failing with read-only /usr/src Message-ID: <20150503125325.GA70576@stack.nl> References: <20150503120349.GA42415@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150503120349.GA42415@lyxys.ka.sub.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 12:53:29 -0000 On Sun, May 03, 2015 at 02:03:49PM +0200, Wolfgang Zenker wrote: > I'm trying to update this system: > FreeBSD pomona 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Mon Apr 13 03:48:04 CEST 2015 wolfgang@pomona:/usr/obj/usr/src/sys/UBQTERL mips > Source for that was probably from about April 11th. I sucessfully built > world and kernel, ran mergemaster -p and make installworld on rev 282299 > but then mergemaster fails with: > # mergemaster -iFU > *** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot > /bin/sh: cannot create routing_test.tmp: Read-only file system > *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to > the temproot environment > Filesystems are mounted like this: > # mount > /dev/da0s2a on / (ufs, local, noatime) > devfs on /dev (devfs, local, multilabel) > /dev/da0s1 on /boot (msdosfs, local) > vulcan.lyx:/usr/src11 on /usr/src (nfs, read-only) > vulcan.lyx:/var/obj/11/mips64 on /usr/obj (nfs) > This used to work before. Any ideas, any further info I could provide? This broke after a test was added for etc/rc.d/. Without special code, this causes these tests to be built and installed as part of mergemaster/etcmerge, like other parts of etc. As a workaround you can do: echo make -C etc obj all | make buildenv on the build machine after make buildworld. Then mergemaster will work, even with a read-only /usr/obj. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun May 3 13:01:48 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A4ECFC1 for ; Sun, 3 May 2015 13:01:48 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A6191B79 for ; Sun, 3 May 2015 13:01:47 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t43D1Y61020771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 3 May 2015 06:01:38 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55461C28.6050408@freebsd.org> Date: Sun, 03 May 2015 21:01:28 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Konstantin Belousov CC: "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> In-Reply-To: <20150501161742.GW2390@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 13:01:48 -0000 On 5/2/15 12:17 AM, Konstantin Belousov wrote: > On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >> if you are interested in readdir(3), seekdir(3) and telldir(3) then >> you should look at >> https://reviews.freebsd.org/D2410 >> >> this patches around a problem in seekdir() that breaks Samba. >> Seekdir(3) will not work as expected when files prior to the point of >> interest in directory have been deleted since the directory was opened. >> >> Windows clients using Samba cause both these things to happen, causing >> the next readdir(3) after the bad seekdir(3) to skip some entries and >> return the wrong file. >> >> Samba only needs to step back a single directory entry in the case >> where it reads an entry and then discovers it can't fit it into the >> buffer it is sending to the windows client. It turns out we can >> reliably cater to Samba's requirement because the "last returned >> element" is always still in memory, so with a little care, we can >> set our filepointer back to it safely. (once) >> >> seekdir and readdir (and telldir()) need a complete rewrite along with >> getdirentries() but that is more than a small edit like this. > Can you explain your expectations from the whole readdir() vs. parallel > directory modifications interaction ? From what I understood so far, > there is unlocked modification of the container and parallel iterator > over the same container. IMO, in such situation, whatever tweaks you > apply to the iterator, it is still cannot be made reliable. > > Before making single-purpose changes to the libc readdir and seekdir > code, or to the kernel code, it would be useful to state exact behaviour > of the dirent machinery we want to see. No, 'make samba works in my > situation' does not sound good enough. Well samba is a MAJOR application for FreeBSD. there are many people who combine the two, (e.g. FreeNAS, which suffers from this problem) so taking it from "The Samba community does not recommend running on FreeBSD due to problems with seekdir" to "Samba works correctly on FreeBSD" is important.. Samba's behaviour here is governed by Windows expectiations. I am specifically NOT changing kernel code.. though in discussion with jhb and others, it becomes clear that this will have to happen some time in the future. There is no way to make seekdir 100% reliable without going to exposing cookies through getdirentries(), and even then it relies on the file systems doing the right thing with the cookies. Don't let Perfect be the enemy of 'better'. I think hte two changes here make seekdir much more reliable. not only does it make the 'back up one entry' case 100% reliable, but it also makes any backwards seek within the current buffer also work correctly. The expectation is that if you read an entry and then "immediately" set the pointer back by one so that you can read it again, that hte next readdir() will once again return the same entry regardless of whether any deletes have happenned between the seekdir and the readdir() In other words if we 'pre-read' an item to find its size, and then read it again.. we get the same item. the change is small, makes it more reliable and helps a number of FreeBSD users (e.g. FreeNAS). I don't see why it would be objectionable to anyone. unless you are relying an samba failing to delete random files when you try delete a subdirectory. > > From owner-freebsd-current@FreeBSD.ORG Sun May 3 14:33:48 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C49D2F2; Sun, 3 May 2015 14:33:48 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C44A9134E; Sun, 3 May 2015 14:33:47 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id E1EAD358C68; Sun, 3 May 2015 16:33:45 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id B8FDA28494; Sun, 3 May 2015 16:33:45 +0200 (CEST) Date: Sun, 3 May 2015 16:33:45 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: Julian Elischer , "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. Message-ID: <20150503143345.GB70576@stack.nl> References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150501161742.GW2390@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 14:33:48 -0000 On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov wrote: > On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: > > if you are interested in readdir(3), seekdir(3) and telldir(3) then > > you should look at > > https://reviews.freebsd.org/D2410 > > this patches around a problem in seekdir() that breaks Samba. > > Seekdir(3) will not work as expected when files prior to the point of > > interest in directory have been deleted since the directory was opened. > > Windows clients using Samba cause both these things to happen, causing > > the next readdir(3) after the bad seekdir(3) to skip some entries and > > return the wrong file. > > Samba only needs to step back a single directory entry in the case > > where it reads an entry and then discovers it can't fit it into the > > buffer it is sending to the windows client. It turns out we can > > reliably cater to Samba's requirement because the "last returned > > element" is always still in memory, so with a little care, we can > > set our filepointer back to it safely. (once) > > seekdir and readdir (and telldir()) need a complete rewrite along with > > getdirentries() but that is more than a small edit like this. > Can you explain your expectations from the whole readdir() vs. parallel > directory modifications interaction ? From what I understood so far, > there is unlocked modification of the container and parallel iterator > over the same container. IMO, in such situation, whatever tweaks you > apply to the iterator, it is still cannot be made reliable. > Before making single-purpose changes to the libc readdir and seekdir > code, or to the kernel code, it would be useful to state exact behaviour > of the dirent machinery we want to see. No, 'make samba works in my > situation' does not sound good enough. Consider the subsequence of entries that existed at opendir() time and were not removed until now. This subsequence is clearly defined and does not have concurrency problems. The order of this subsequence must remain unchanged and seekdir() must be correct with respect to this subsequence. Additionally, two other kinds of entries may be returned. New entries may be inserted anywhere in between the entries of the subsequence, and removed entries may be returned as if they were still part of the subsequence (so that not every readdir() needs a system call). A simple implementation for UFS-style directories is to store the offset in the directory (all bits of it, not masking off the lower 9 bits). This needs d_off or similar in struct dirent. The kernel getdirentries() then needs a similar loop as the old libc seekdir() to go from the start of the 512-byte directory block to the desired entry (since an entry may not exist at the stored offset within the directory block). This means that a UFS-style directory cannot be compacted (existing entries moved from higher to lower offsets to fill holes) while it is open for reading. An NFS exported directory is always open for reading. This also means that duplicate entries can only be returned if that particular filename was deleted and created again. Without kernel support, it is hard to get telldir/seekdir completely reliable. The current libc implementation is wrong since the "holes" within the block just disappear and change the offsets of the following entries; the kernel cannot fix this using entries with d_fileno = 0 since it cannot know, in the general case, how long the deleted entry was in the filesystem-independent dirent format. My previous idea of storing one d_fileno during telldir() is wrong since it will fail if that entry is deleted. If you do not care about memory usage (which probably is already excessive with the current libc implementation), you could store at telldir() time the offset of the current block returned by getdirentries() and the d_fileno of all entries already returned in the current block. The D2410 patch can conceptually work for what Samba needs, stepping back one directory entry. I will comment on it. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sun May 3 15:45:51 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D989376; Sun, 3 May 2015 15:45:51 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A118D1A2A; Sun, 3 May 2015 15:45:50 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t43FjXPl002361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 3 May 2015 17:45:34 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t43Ftdev043590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 May 2015 17:55:39 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.9/8.14.9/Submit) id t43Ftdla043589; Sun, 3 May 2015 17:55:39 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sun, 3 May 2015 17:55:39 +0200 From: Wolfgang Zenker To: Jilles Tjoelker Cc: freebsd-current@freebsd.org, Will Andrews , Garrett Cooper Subject: Re: mergemaster failing with read-only /usr/src Message-ID: <20150503155539.GA43387@lyxys.ka.sub.org> References: <20150503120349.GA42415@lyxys.ka.sub.org> <20150503125325.GA70576@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150503125325.GA70576@stack.nl> Organization: private site User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sun, 03 May 2015 17:45:34 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 15:45:51 -0000 * Jilles Tjoelker [150503 14:53]: > On Sun, May 03, 2015 at 02:03:49PM +0200, Wolfgang Zenker wrote: >> I'm trying to update this system: >> FreeBSD pomona 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Mon Apr 13 03:48:04 CEST 2015 wolfgang@pomona:/usr/obj/usr/src/sys/UBQTERL mips >> Source for that was probably from about April 11th. I sucessfully built >> world and kernel, ran mergemaster -p and make installworld on rev 282299 >> but then mergemaster fails with: >> # mergemaster -iFU >> *** Creating the temporary root environment in /var/tmp/temproot >> *** /var/tmp/temproot ready for use >> *** Creating and populating directory structure in /var/tmp/temproot >> /bin/sh: cannot create routing_test.tmp: Read-only file system >> *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to >> the temproot environment >> Filesystems are mounted like this: >> # mount >> /dev/da0s2a on / (ufs, local, noatime) >> devfs on /dev (devfs, local, multilabel) >> /dev/da0s1 on /boot (msdosfs, local) >> vulcan.lyx:/usr/src11 on /usr/src (nfs, read-only) >> vulcan.lyx:/var/obj/11/mips64 on /usr/obj (nfs) >> This used to work before. Any ideas, any further info I could provide? > This broke after a test was added for etc/rc.d/. Without special code, > this causes these tests to be built and installed as part of > mergemaster/etcmerge, like other parts of etc. > As a workaround you can do: > echo make -C etc obj all | make buildenv > on the build machine after make buildworld. Then mergemaster will work, > even with a read-only /usr/obj. Well, I do build on that machine directly, and /usr/obj is mounted r/w, only /usr/src is a read-only mount. Trying the workaround on the machine istself does not help, unfortunately: while the "make buildenv" does work without a problem, mergemaster still fails in the same way. Wolfgang From owner-freebsd-current@FreeBSD.ORG Sun May 3 19:11:58 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01D8B8BB; Sun, 3 May 2015 19:11:58 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA0A51DAB; Sun, 3 May 2015 19:11:56 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so142149836pac.1; Sun, 03 May 2015 12:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=hGavoTGkfi2d8pmhpUOFK9DEaZwXCAN47ALHj6yds78=; b=IfRYo9P36JIkMLmhQvTNLu0vfPi2HSuAceANSPQ/hMZvFo2Q+alUYgSa86q44USFhn o6cxM1hkfHaAOiDlFT6LXoTczvv2zOcN3DEvV5Kc6NdAAyFxilEplYq4eqU/VZGyvESE ALO/nOEq5S7i2L1xS6kNQL3rWQRC0ITooZVrqmg3TaK8rowj1U4MQZSPHDKppqnM3gfD qimr9JZgV2mzQI6FILHGpGCvdzpLvYakZcoQb8Ljo+PskeGA7Taku9m8QvprxukmnCeD ZnMCFGfn1UZ+bXJfmI3DUZYDONR8+1eaIpMZW1ezw51sKwFxr3t5ivN7WQmyvDsOVLWs sMXw== X-Received: by 10.66.177.238 with SMTP id ct14mr36172883pac.121.1430680265221; Sun, 03 May 2015 12:11:05 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:b875:2fa7:b346:90ff? ([2601:8:ab80:7d6:b875:2fa7:b346:90ff]) by mx.google.com with ESMTPSA id bs4sm10571628pbc.3.2015.05.03.12.11.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 May 2015 12:11:04 -0700 (PDT) Subject: Re: mergemaster failing with read-only /usr/src Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_89736F57-F704-42E0-9C68-23F8CEB8414A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: <20150503155539.GA43387@lyxys.ka.sub.org> Date: Sun, 3 May 2015 12:11:03 -0700 Cc: Jilles Tjoelker , freebsd-current@freebsd.org, Will Andrews , Garrett Cooper Message-Id: References: <20150503120349.GA42415@lyxys.ka.sub.org> <20150503125325.GA70576@stack.nl> <20150503155539.GA43387@lyxys.ka.sub.org> To: Wolfgang Zenker X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 19:11:58 -0000 --Apple-Mail=_89736F57-F704-42E0-9C68-23F8CEB8414A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 3, 2015, at 8:55, Wolfgang Zenker = wrote: > * Jilles Tjoelker [150503 14:53]: >> On Sun, May 03, 2015 at 02:03:49PM +0200, Wolfgang Zenker wrote: >>> I'm trying to update this system: >>> FreeBSD pomona 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Mon Apr 13 = 03:48:04 CEST 2015 wolfgang@pomona:/usr/obj/usr/src/sys/UBQTERL mips >=20 >>> Source for that was probably from about April 11th. I sucessfully = built >>> world and kernel, ran mergemaster -p and make installworld on rev = 282299 >>> but then mergemaster fails with: >=20 >>> # mergemaster -iFU >=20 >>> *** Creating the temporary root environment in /var/tmp/temproot >>> *** /var/tmp/temproot ready for use >>> *** Creating and populating directory structure in /var/tmp/temproot >=20 >>> /bin/sh: cannot create routing_test.tmp: Read-only file system >=20 >>> *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to >>> the temproot environment >=20 >>> Filesystems are mounted like this: >>> # mount >>> /dev/da0s2a on / (ufs, local, noatime) >>> devfs on /dev (devfs, local, multilabel) >>> /dev/da0s1 on /boot (msdosfs, local) >>> vulcan.lyx:/usr/src11 on /usr/src (nfs, read-only) >>> vulcan.lyx:/var/obj/11/mips64 on /usr/obj (nfs) >=20 >>> This used to work before. Any ideas, any further info I could = provide? >=20 >> This broke after a test was added for etc/rc.d/. Without special = code, >> this causes these tests to be built and installed as part of >> mergemaster/etcmerge, like other parts of etc. >=20 >> As a workaround you can do: >> echo make -C etc obj all | make buildenv >> on the build machine after make buildworld. Then mergemaster will = work, >> even with a read-only /usr/obj. >=20 > Well, I do build on that machine directly, and /usr/obj is mounted = r/w, > only /usr/src is a read-only mount. Trying the workaround on the = machine > istself does not help, unfortunately: while the "make buildenv" does > work without a problem, mergemaster still fails in the same way. I was going to move it to etc/tests soon since it wasn=92t really = testing /etc/rc.d/, but it makes more sense (with the issue above), just = to create .../tests/etc, and move things there. I wish etc/ wasn=92t = such a special butterfly... --Apple-Mail=_89736F57-F704-42E0-9C68-23F8CEB8414A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVRnLIAAoJEMZr5QU6S73eAlEIALh7FmTeIA1Np5GbgX6fhaUn hpuz7XGp9Fbsfrh6pKBeZ4sFYvTK9uDF2XAxo4sLFNDeOSDGi+9yzmR0/FKYlKz4 AWdxxlwNhRc/o1xglGebbbAGKRG+sOZcc88KWVPIALPHURTfvdixBljLOvgr4vkD 9I8MdgququYL0GI/W+51xeyRqVs5rB4VEflP8/mvlQ26+ZxAaX5BCtKzEaPF5deT rgLyEXFieVD/6mQ43ykhwHlzPV89GypIyEfMowJ6211dum2vj/YuNdc0LD1GMYBD eIruXkRrHWIC4kSD2nR+STFPFoMQd3nU1IMqXe6rDkfvQDnnywTx4Gh9D4dErE0= =7NkH -----END PGP SIGNATURE----- --Apple-Mail=_89736F57-F704-42E0-9C68-23F8CEB8414A-- From owner-freebsd-current@FreeBSD.ORG Sun May 3 20:22:04 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60D751FE for ; Sun, 3 May 2015 20:22:04 +0000 (UTC) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D84041666 for ; Sun, 3 May 2015 20:22:03 +0000 (UTC) Received: by laat2 with SMTP id t2so92536047laa.1 for ; Sun, 03 May 2015 13:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=04a3G9MbbgoBzO0oHgke0Et+Pia9Futq+Bw0Sn6ptpo=; b=ZrR+ZCc7ZVyBVwQdJZjz3dXn9YiwVkxT5nw2KNgerW/uXA+wlrKau4KSEZR0z1qHlW MlA2HkJksCux28s9izXLUMN/b899zMpkDXmb3A7PdCqjoDJghq2SCeBb78uaWPlG2ymz izCvAzqPIb8ZbfZwZXmX8E+tln2W0MAR5uDQ0ve483VFYTn0u0W8+b4Rizao7Nzwqs6U NQ38yU6Xz+mDSe5u2qwcNkEu7XmjdoKipnGuA2notBnrZ+kHd8jAovm5nCZFmmndr4dx MjhBD+mioTznH6UiWoPfI1JqpU/0kGIRopV/ZboNNp6Ogg6ljc8MxrqgoO9d2dmJJOBt ugzw== X-Gm-Message-State: ALoCoQltw/YfjmX+1CvpZDQ7IJsqzOUC+gYWXe4FVjXBGHKQ5ZL6bpx2DUsFJu2dP3NRIUZhm347 X-Received: by 10.152.3.97 with SMTP id b1mr17247828lab.54.1430684028281; Sun, 03 May 2015 13:13:48 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id lc8sm2884444lbc.33.2015.05.03.13.13.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 May 2015 13:13:47 -0700 (PDT) Message-ID: <55468177.6070100@freebsd.org> Date: Sun, 03 May 2015 23:13:43 +0300 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Julian Elischer , Konstantin Belousov CC: "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> <55461C28.6050408@freebsd.org> In-Reply-To: <55461C28.6050408@freebsd.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 03 May 2015 20:22:04 -0000 On 03.05.2015 16:01, Julian Elischer wrote: >> Before making single-purpose changes to the libc readdir and seekdir >> code, or to the kernel code, it would be useful to state exact behaviour >> of the dirent machinery we want to see. No, 'make samba works in my >> situation' does not sound good enough. > Well samba is a MAJOR application for FreeBSD. there are many people > who combine the two, (e.g. FreeNAS, which suffers from this problem) > so taking it from "The Samba community does not recommend > running on FreeBSD due to problems with seekdir" to "Samba works > correctly on FreeBSD" is important.. Samba's behaviour here is governed > by Windows expectiations. Please look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198819 too. Perhaps it is related or may be not (sorry currently I am not able to inspect the code). -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Mon May 4 01:57:28 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C0B4E44; Mon, 4 May 2015 01:57:28 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 78BFE1714; Mon, 4 May 2015 01:57:28 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EFDAA211; Mon, 4 May 2015 01:57:28 +0000 (UTC) Date: Mon, 4 May 2015 01:57:28 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, loos@FreeBSD.org, imp@FreeBSD.org, adrian@FreeBSD.org, mav@FreeBSD.org Message-ID: <1278978687.3.1430704648903.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_i386 #76 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 01:57:28 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 4 05:31:31 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67482411 for ; Mon, 4 May 2015 05:31:31 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 461F31C17 for ; Mon, 4 May 2015 05:31:30 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t445VP24023679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 3 May 2015 22:31:28 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55470427.3010009@freebsd.org> Date: Mon, 04 May 2015 13:31:19 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jilles Tjoelker , Konstantin Belousov CC: "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> <20150503143345.GB70576@stack.nl> In-Reply-To: <20150503143345.GB70576@stack.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 05:31:31 -0000 On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov wrote: >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >>> if you are interested in readdir(3), seekdir(3) and telldir(3) then >>> you should look at >>> https://reviews.freebsd.org/D2410 >>> this patches around a problem in seekdir() that breaks Samba. >>> Seekdir(3) will not work as expected when files prior to the point of >>> interest in directory have been deleted since the directory was opened. >>> Windows clients using Samba cause both these things to happen, causing >>> the next readdir(3) after the bad seekdir(3) to skip some entries and >>> return the wrong file. >>> Samba only needs to step back a single directory entry in the case >>> where it reads an entry and then discovers it can't fit it into the >>> buffer it is sending to the windows client. It turns out we can >>> reliably cater to Samba's requirement because the "last returned >>> element" is always still in memory, so with a little care, we can >>> set our filepointer back to it safely. (once) >>> seekdir and readdir (and telldir()) need a complete rewrite along with >>> getdirentries() but that is more than a small edit like this. >> Can you explain your expectations from the whole readdir() vs. parallel >> directory modifications interaction ? From what I understood so far, >> there is unlocked modification of the container and parallel iterator >> over the same container. IMO, in such situation, whatever tweaks you >> apply to the iterator, it is still cannot be made reliable. >> Before making single-purpose changes to the libc readdir and seekdir >> code, or to the kernel code, it would be useful to state exact behaviour >> of the dirent machinery we want to see. No, 'make samba works in my >> situation' does not sound good enough. > Consider the subsequence of entries that existed at opendir() time and > were not removed until now. This subsequence is clearly defined and does > not have concurrency problems. The order of this subsequence must remain > unchanged and seekdir() must be correct with respect to this > subsequence. > > Additionally, two other kinds of entries may be returned. New entries > may be inserted anywhere in between the entries of the subsequence, and > removed entries may be returned as if they were still part of the > subsequence (so that not every readdir() needs a system call). > > A simple implementation for UFS-style directories is to store the offset > in the directory (all bits of it, not masking off the lower 9 bits). > This needs d_off or similar in struct dirent. The kernel getdirentries() > then needs a similar loop as the old libc seekdir() to go from the start > of the 512-byte directory block to the desired entry (since an entry may > not exist at the stored offset within the directory block). > > This means that a UFS-style directory cannot be compacted (existing > entries moved from higher to lower offsets to fill holes) while it is > open for reading. An NFS exported directory is always open for reading. > > This also means that duplicate entries can only be returned if that > particular filename was deleted and created again. > > Without kernel support, it is hard to get telldir/seekdir completely > reliable. The current libc implementation is wrong since the "holes" > within the block just disappear and change the offsets of the following > entries; the kernel cannot fix this using entries with d_fileno = 0 > since it cannot know, in the general case, how long the deleted entry > was in the filesystem-independent dirent format. My previous idea of > storing one d_fileno during telldir() is wrong since it will fail if > that entry is deleted. > > If you do not care about memory usage (which probably is already > excessive with the current libc implementation), you could store at > telldir() time the offset of the current block returned by > getdirentries() and the d_fileno of all entries already returned in the > current block. > > The D2410 patch can conceptually work for what Samba needs, stepping > back one directory entry. I will comment on it. thanks your comment is correct, but I don't think it really matters because I'm only claiming to fix a really small set of possible usages.. I might add a sentence in the seekdir man page specifying what does and doesn't work. From owner-freebsd-current@FreeBSD.ORG Mon May 4 07:09:43 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBC5C266 for ; Mon, 4 May 2015 07:09:43 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E5FD15DA for ; Mon, 4 May 2015 07:09:43 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t446ki13023897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 3 May 2015 23:46:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <554715CF.2010703@freebsd.org> Date: Mon, 04 May 2015 14:46:39 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jilles Tjoelker , Konstantin Belousov CC: "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> <20150503143345.GB70576@stack.nl> In-Reply-To: <20150503143345.GB70576@stack.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 07:09:43 -0000 On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov wrote: >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >>> if you are interested in readdir(3), seekdir(3) and telldir(3) then >>> you should look at >>> https://reviews.freebsd.org/D2410 >>> this patches around a problem in seekdir() that breaks Samba. >>> Seekdir(3) will not work as expected when files prior to the point of >>> interest in directory have been deleted since the directory was opened. >>> Windows clients using Samba cause both these things to happen, causing >>> the next readdir(3) after the bad seekdir(3) to skip some entries and >>> return the wrong file. >>> Samba only needs to step back a single directory entry in the case >>> where it reads an entry and then discovers it can't fit it into the >>> buffer it is sending to the windows client. It turns out we can >>> reliably cater to Samba's requirement because the "last returned >>> element" is always still in memory, so with a little care, we can >>> set our filepointer back to it safely. (once) >>> seekdir and readdir (and telldir()) need a complete rewrite along with >>> getdirentries() but that is more than a small edit like this. >> Can you explain your expectations from the whole readdir() vs. parallel >> directory modifications interaction ? From what I understood so far, >> there is unlocked modification of the container and parallel iterator >> over the same container. IMO, in such situation, whatever tweaks you >> apply to the iterator, it is still cannot be made reliable. >> Before making single-purpose changes to the libc readdir and seekdir >> code, or to the kernel code, it would be useful to state exact behaviour >> of the dirent machinery we want to see. No, 'make samba works in my >> situation' does not sound good enough. > Consider the subsequence of entries that existed at opendir() time and > were not removed until now. This subsequence is clearly defined and does > not have concurrency problems. The order of this subsequence must remain > unchanged and seekdir() must be correct with respect to this > subsequence. > > Additionally, two other kinds of entries may be returned. New entries > may be inserted anywhere in between the entries of the subsequence, and > removed entries may be returned as if they were still part of the > subsequence (so that not every readdir() needs a system call). > > A simple implementation for UFS-style directories is to store the offset > in the directory (all bits of it, not masking off the lower 9 bits). > This needs d_off or similar in struct dirent. The kernel getdirentries() > then needs a similar loop as the old libc seekdir() to go from the start > of the 512-byte directory block to the desired entry (since an entry may > not exist at the stored offset within the directory block). At least it needs some more information in struct dirent than there is now.. A cookie is the current fashion.. that assumes however that the filesystems are capable of converting backwards from cookie to 'location'. ZFS claims to be able to do so.. Thee other thing to do would be to store some sort of strong hash of the name and inode# in each telldir entry.. we would seek to the saved seek location and seek forward computing or looking for a matching hash. I woudl also add that the man pages talk about the readdir blocksize a bit and mention the file blocksize (and stat) which is often way dfferent from 512 bytes.. usually 16k or so these days. I found setting the read size to the same as the fs blocksize seemd to work well. > > This means that a UFS-style directory cannot be compacted (existing > entries moved from higher to lower offsets to fill holes) while it is > open for reading. An NFS exported directory is always open for reading. yes so a UFS filesystem that is exported could never do garbage collection. > > This also means that duplicate entries can only be returned if that > particular filename was deleted and created again. > > Without kernel support, it is hard to get telldir/seekdir completely > reliable. The current libc implementation is wrong since the "holes" > within the block just disappear and change the offsets of the following > entries; the kernel cannot fix this using entries with d_fileno = 0 > since it cannot know, in the general case, how long the deleted entry > was in the filesystem-independent dirent format. yes it's the filesystem that knows.. we USED to return empty entries in the dirent list but that was removed recently think. > My previous idea of > storing one d_fileno during telldir() is wrong since it will fail if > that entry is deleted. > > If you do not care about memory usage (which probably is already > excessive with the current libc implementation), you could store at > telldir() time the offset of the current block returned by > getdirentries() and the d_fileno of all entries already returned in the > current block. > > The D2410 patch can conceptually work for what Samba needs, stepping > back one directory entry. I will comment on it. > From owner-freebsd-current@FreeBSD.ORG Mon May 4 09:13:45 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7820390A; Mon, 4 May 2015 09:13:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6334B1327; Mon, 4 May 2015 09:13:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0C2A92EF; Mon, 4 May 2015 09:13:45 +0000 (UTC) Date: Mon, 4 May 2015 09:13:44 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, neel@FreeBSD.org, cy@FreeBSD.org Message-ID: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2725 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 09:13:45 -0000 See Changes: [cy] MFV ntp 4.2.8p2 (r281348) Reviewed by: delphij (suggested MFC) Approved by:=09roberto Security: CVE-2015-1798, CVE-2015-1799 Security: VuXML ebd84c96-dd7e-11e4-854e-3c970e169bc2 MFC after:=091 month [neel] Emulate the 'CMP r/m8, imm8' instruction encountered when booting a = Windows Vista guest. Reported by:=09Leon Dang (ldang@nahannisys.com) MFC after:=091 week ------------------------------------------ [...truncated 125654 lines...] echo tty: >> .depend --- depend_subdir_ul --- =3D=3D=3D> usr.bin/ul (depend) --- usr.sbin.depend__D --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.bin.depend__D --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.sbin.depend__D --- echo rwhod: >> .depend --- usr.bin.depend__D --- --- depend_subdir_uname --- =3D=3D=3D> usr.bin/uname (depend) --- depend_subdir_ul --- echo ul: >> .depend --- depend_subdir_svn --- =3D=3D=3D> usr.bin/svn/lib/libsvn_client (depend) --- usr.sbin.depend__D --- --- depend_subdir_sa --- =3D=3D=3D> usr.sbin/sa (depend) --- usr.bin.depend__D --- --- .depend --- rm -f .depend --- depend_subdir_uname --- --- .depend --- --- depend_subdir_svn --- CC=3D'cc ' mkdep -f .depend -a -I -I -I -I -I -I -I -I -I -std=3Dgnu99 <= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/svn/lib/libsvn_clie= nt/../../../../contrib/subversion/subversion/libsvn_client/merge.c> --- depend_subdir_uname --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.sbin.depend__D --- --- _sub.depend --- =3D=3D=3D> usr.sbin/sa/tests (depend) --- usr.bin.depend__D --- echo uname: >> .depend --- usr.sbin.depend__D --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- _sub.depend --- --- scripts.depend --- (cd && = make -f SUBDIR=3D _RECURSING_PROGS=3D depend) --- usr.bin.depend__D --- --- depend_subdir_unexpand --- =3D=3D=3D> usr.bin/unexpand (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.sbin.depend__D --- --- .depend --- echo sa: >> .depend --- depend_subdir_sendmail --- =3D=3D=3D> usr.sbin/sendmail (depend) --- usr.bin.depend__D --- echo unexpand: >> .depend --- depend_subdir_unifdef --- =3D=3D=3D> usr.bin/unifdef (depend) --- usr.sbin.depend__D --- --- sm_os.h --- ln -sf sm_os.h --- .depend --- --- usr.bin.depend__D --- --- .depend --- --- usr.sbin.depend__D --- rm -f .depend --- usr.bin.depend__D --- rm -f .depend --- usr.sbin.depend__D --- CC=3D'cc ' mkdep -f .depend -a -I -I -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DS= TARTTLS -D_FFR_TLS_1 -std=3Dgnu99 = usr.bin.depend__D --- CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.sbin.depend__D --- dmail/src/recipient.c = --- usr.bin.depend__D --- echo unifdef: >> .depend --- usr.sbin.depend__D --- --- depend_subdir_service --- =3D=3D=3D> usr.sbin/service (depend) --- depend_subdir_services_mkdb --- =3D=3D=3D> usr.sbin/services_mkdb (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo services_mkdb: >> .depend --- usr.bin.depend__D --- --- depend_subdir_uniq --- =3D=3D=3D> usr.bin/uniq (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo uniq: >> .depend --- usr.sbin.depend__D --- --- depend_subdir_setfib --- =3D=3D=3D> usr.sbin/setfib (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo setfib: >> .depend --- usr.bin.depend__D --- --- depend_subdir_units --- =3D=3D=3D> usr.bin/units (depend) --- _sub.depend --- =3D=3D=3D> usr.bin/units/tests (depend) --- scripts.depend --- (cd &= & make -f SUBDIR=3D _RECURSING_PROGS=3D depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo units: >> .depend --- depend_subdir_unvis --- =3D=3D=3D> usr.bin/unvis (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo unvis: >> .depend --- depend_subdir_unzip --- =3D=3D=3D> usr.bin/unzip (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Diso9899:1999 echo unzip: >> .depend --- depend_subdir_usbhidaction --- =3D=3D=3D> usr.bin/usbhidaction (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo usbhidaction: >> .depend --- depend_subdir_usbhidctl --- =3D=3D=3D> usr.bin/usbhidctl (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo usbhidctl: >> .depend --- usr.sbin.depend__D --- --- depend_subdir_setfmac --- =3D=3D=3D> usr.sbin/setfmac (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo setfmac: >> .depend --- usr.bin.depend__D --- --- depend_subdir_users --- =3D=3D=3D> usr.bin/users (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a =20 echo users: >> .depend echo users: >> .depend --- usr.sbin.depend__D --- --- depend_subdir_setpmac --- =3D=3D=3D> usr.sbin/setpmac (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo setpmac: >> .depend --- usr.bin.depend__D --- --- depend_subdir_uudecode --- =3D=3D=3D> usr.bin/uudecode (depend) --- _sub.depend --- =3D=3D=3D> usr.bin/uudecode/tests (depend) --- usr.sbin.depend__D --- --- depend_subdir_ntp --- mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_ntp] Error code 2 make[3]: stopped in --- usr.bin.depend__D --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_uudecode] Error code 2 make[3]: stopped in --- depend_subdir_svn --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.depend] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_svn] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.depend__D] Error code 2 make[2]: stopped in --- usr.sbin.depend__D --- --- depend_subdir_sendmail --- echo sendmail: = >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_sendmail] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.sbin.depend__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [_depend] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon May 4 13:26:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C9CB4EE; Mon, 4 May 2015 13:26:20 +0000 (UTC) Received: from smtp-out-05.shaw.ca (smtp-out-05.shaw.ca [64.59.134.13]) by mx1.freebsd.org (Postfix) with ESMTP id 19F411E30; Mon, 4 May 2015 13:26:19 +0000 (UTC) Received: from slippy.cwsent.com ([24.68.119.200]) by shaw.ca with SMTP id pGO1Y7E5emG59pGO3YaEOE; Mon, 04 May 2015 07:26:19 -0600 X-Authority-Analysis: v=2.1 cv=MeGmwcLf c=1 sm=1 tr=0 a=DtyMuQCYAJf2vvIh/Mv8eA==:117 a=DtyMuQCYAJf2vvIh/Mv8eA==:17 a=VxmjJ2MpAAAA:8 a=kj9zAlcOel0A:10 a=BWvPGDcYAAAA:8 a=h1PgugrvaO0A:10 a=6I5d2MoRAAAA:8 a=o_TrnTDbAAAA:8 a=YxBL1-UpAAAA:8 a=uj5d0zTGfImf68Ectz0A:9 a=CjuIK1q_8ugA:10 Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id t44DQHE5046970; Mon, 4 May 2015 06:26:17 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id t44DQH1E046967; Mon, 4 May 2015 06:26:17 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201505041326.t44DQH1E046967@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: jenkins-admin@freebsd.org cc: freebsd-current@freebsd.org, neel@FreeBSD.org, cy@FreeBSD.org Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 In-Reply-To: Message from jenkins-admin@freebsd.org of "Mon, 04 May 2015 09:13:44 -0000." <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 May 2015 06:26:17 -0700 X-CMAE-Envelope: MS4wfN8TiY4b8TYv/THnFdT7ZtHUkg584LITl9NKNwwdMJl88NAGmpxcY5nlvCXyvzeYLxgBzaUO8QT/BYi7kGRseJs3IoNRlewMJcYKLGm/miMgDTMFczyE8nECeiCzIeplOy9mjX4/6AfMT6MPqy2wqqj29tekkxKgVnijAP1vjqC5GtGNQD1Q7lcgnbFbv4lAsjg4MpBlFAEX+Hey3VCgQmHiDXDkUjgCHsH7oxidRUJEH0a8I5ArXmlsPh3zdC0VegQo62YJBePVJP8Gc43OLO1F7xMCWbkM2FKO7bw7X2gh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 13:26:20 -0000 In message <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org >, jenkins-admin@freebsd.org writes: > See > > Changes: > > [cy] MFV ntp 4.2.8p2 (r281348) > > Reviewed by: delphij (suggested MFC) > Approved by: roberto > Security: CVE-2015-1798, CVE-2015-1799 > Security: VuXML ebd84c96-dd7e-11e4-854e-3c970e169bc2 > MFC after: 1 month > > [neel] Emulate the 'CMP r/m8, imm8' instruction encountered when booting a Wi > ndows > Vista guest. > > Reported by: Leon Dang (ldang@nahannisys.com) > MFC after: 1 week > > ------------------------------------------ > [...truncated 125654 lines...] > ===> usr.bin/uudecode/tests (depend) > --- usr.sbin.depend__D --- > --- depend_subdir_ntp --- > mkdep: compile failed > *** [.depend] Error code 1 > > make[5]: stopped in /ntp/ntpd> > 1 error > > make[5]: stopped in /ntp/ntpd> > *** [_sub.depend] Error code 2 > > make[4]: stopped in /ntp> > 1 error > > make[4]: stopped in /ntp> > *** [depend_subdir_ntp] Error code 2 > > make[3]: stopped in > > --- usr.bin.depend__D --- > A failure has been detected in another branch of the parallel make > > make[5]: stopped in uudecode/tests> > *** [_sub.depend] Error code 2 > > make[4]: stopped in uudecode> > 1 error > > make[4]: stopped in uudecode> > *** [depend_subdir_uudecode] Error code 2 > > make[3]: stopped in > --- depend_subdir_svn --- > A failure has been detected in another branch of the parallel make > > make[6]: stopped in svn/lib/libsvn_client> > *** [_sub.depend] Error code 2 > > make[5]: stopped in svn/lib> > 1 error > > make[5]: stopped in svn/lib> > *** [_sub.depend] Error code 2 > > make[4]: stopped in svn> > 1 error > > make[4]: stopped in svn> > *** [depend_subdir_svn] Error code 2 > > make[3]: stopped in > 2 errors > > make[3]: stopped in > *** [usr.bin.depend__D] Error code 2 > > make[2]: stopped in > --- usr.sbin.depend__D --- > --- depend_subdir_sendmail --- > echo sendmail: eeBSD_HEAD/tmp/usr/lib/libc.a> /ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libutil.a> rg/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libwrap.a> //jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/lib/libsm/l > ibsm.a> EAD/lib/libsmdb/libsmutil.a> /obj/builds/FreeBSD_HEAD/tmp/usr/lib/libssl.a> ob/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/lib/libcrypto.a> >> .depen > d > A failure has been detected in another branch of the parallel make > > make[4]: stopped in /sendmail> > *** [depend_subdir_sendmail] Error code 2 > > make[3]: stopped in > > 2 errors > > make[3]: stopped in > > *** [usr.sbin.depend__D] Error code 2 > > make[2]: stopped in > 2 errors > > make[2]: stopped in > *** [_depend] Error code 2 > > make[1]: stopped in > 1 error > > make[1]: stopped in > *** [buildworld] Error code 2 > > make: stopped in > 1 error > > make: stopped in > Build step 'Execute shell' marked build as failure > > I cannot see where the problem is. All local tests, including universe, have built cleanly. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Mon May 4 14:49:48 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8D8EB6; Mon, 4 May 2015 14:49:47 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89AEA17DD; Mon, 4 May 2015 14:49:47 +0000 (UTC) Received: by lbbqq2 with SMTP id qq2so106479540lbb.3; Mon, 04 May 2015 07:49:45 -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=Vmh3LHoLz7jMvHfdCXOHZOc38F1Q30KlMNzfkt3pYOU=; b=uJni1/bi0b7OLjBy2sZddTp5e8r5qnl1DaO3nrRaNfmK1+d2PSvdZoOj4zUGgU5p2y IIHhlz2BpCW1njJ4N3xDDO8GyLuiGO3V36uD8Q0dSLJcYAJ989S957/58UsQOAGv5nym FS46bGU74a06TK+Xtb1Bp0Fwd7lBPCUQTogxdE4LXdr9DzSuiIHfvHU+1WVSJqAZXUFt SCW6RrT9jePmN46lWCwv/ME9YJiRfCNafcGPzWs2zPUCADhYKDvLZsI0ENmK2zyx515y YkiFwtJYNfKnp0Z50SyTDC3vVQm48TVZaQ4eJFd4ZJ+nmy/AA6oUTLF5HNtbpO3ZxE2t wiZg== MIME-Version: 1.0 X-Received: by 10.152.170.170 with SMTP id an10mr19781214lac.84.1430750985240; Mon, 04 May 2015 07:49:45 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.164.38 with HTTP; Mon, 4 May 2015 07:49:45 -0700 (PDT) In-Reply-To: <201505041326.t44DQH1E046967@slippy.cwsent.com> References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> Date: Mon, 4 May 2015 10:49:45 -0400 X-Google-Sender-Auth: u3KBU1RAC7NAXzL4ZTQbDdLRR2g Message-ID: Subject: Build failed in Jenkins: FreeBSD_HEAD #2725 From: Craig Rodrigues To: Cy Schubert Cc: "jenkins-admin@freebsd.org" , "freebsd-current@freebsd.org" , "neel@freebsd.org" , "cy@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 14:49:48 -0000 On Monday, May 4, 2015, Cy Schubert > wrote: > > > I cannot see where the problem is. All local tests, including universe, > have built cleanly. > In this log: https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/console search for: error: version control conflict marker in file -- Craig From owner-freebsd-current@FreeBSD.ORG Mon May 4 14:53:02 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47EE2302 for ; Mon, 4 May 2015 14:53:02 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26ADE18BC for ; Mon, 4 May 2015 14:53:01 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t44EqmVg025602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 May 2015 07:52:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <554787BA.1020105@freebsd.org> Date: Mon, 04 May 2015 22:52:42 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jilles Tjoelker , Konstantin Belousov CC: "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> <20150503143345.GB70576@stack.nl> In-Reply-To: <20150503143345.GB70576@stack.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 14:53:02 -0000 On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov wrote: >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >>> if you are interested in readdir(3), seekdir(3) and telldir(3) then >>> you should look at >>> https://reviews.freebsd.org/D2410 >>> this patches around a problem in seekdir() that breaks Samba. >>> Seekdir(3) will not work as expected when files prior to the point of >>> interest in directory have been deleted since the directory was opened. >>> Windows clients using Samba cause both these things to happen, causing >>> the next readdir(3) after the bad seekdir(3) to skip some entries and >>> return the wrong file. >>> Samba only needs to step back a single directory entry in the case >>> where it reads an entry and then discovers it can't fit it into the >>> buffer it is sending to the windows client. It turns out we can >>> reliably cater to Samba's requirement because the "last returned >>> element" is always still in memory, so with a little care, we can >>> set our filepointer back to it safely. (once) >>> seekdir and readdir (and telldir()) need a complete rewrite along with >>> getdirentries() but that is more than a small edit like this. >> Can you explain your expectations from the whole readdir() vs. parallel >> directory modifications interaction ? From what I understood so far, >> there is unlocked modification of the container and parallel iterator >> over the same container. IMO, in such situation, whatever tweaks you >> apply to the iterator, it is still cannot be made reliable. >> Before making single-purpose changes to the libc readdir and seekdir >> code, or to the kernel code, it would be useful to state exact behaviour >> of the dirent machinery we want to see. No, 'make samba works in my >> situation' does not sound good enough. > Consider the subsequence of entries that existed at opendir() time and > were not removed until now. This subsequence is clearly defined and does > not have concurrency problems. The order of this subsequence must remain > unchanged and seekdir() must be correct with respect to this > subsequence. > > Additionally, two other kinds of entries may be returned. New entries > may be inserted anywhere in between the entries of the subsequence, and > removed entries may be returned as if they were still part of the > subsequence (so that not every readdir() needs a system call). > > A simple implementation for UFS-style directories is to store the offset > in the directory (all bits of it, not masking off the lower 9 bits). > This needs d_off or similar in struct dirent. The kernel getdirentries() > then needs a similar loop as the old libc seekdir() to go from the start > of the 512-byte directory block to the desired entry (since an entry may > not exist at the stored offset within the directory block). > > This means that a UFS-style directory cannot be compacted (existing > entries moved from higher to lower offsets to fill holes) while it is > open for reading. An NFS exported directory is always open for reading. > > This also means that duplicate entries can only be returned if that > particular filename was deleted and created again. > > Without kernel support, it is hard to get telldir/seekdir completely > reliable. The current libc implementation is wrong since the "holes" > within the block just disappear and change the offsets of the following > entries; the kernel cannot fix this using entries with d_fileno = 0 > since it cannot know, in the general case, how long the deleted entry > was in the filesystem-independent dirent format. My previous idea of > storing one d_fileno during telldir() is wrong since it will fail if > that entry is deleted. > > If you do not care about memory usage (which probably is already > excessive with the current libc implementation), you could store at > telldir() time the offset of the current block returned by > getdirentries() and the d_fileno of all entries already returned in the > current block. > > The D2410 patch can conceptually work for what Samba needs, stepping > back one directory entry. I will comment on it. > how long do I have to wait until I can commit this and was kib's comment a "do not commit"? From owner-freebsd-current@FreeBSD.ORG Mon May 4 15:21:01 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E31CDC7 for ; Mon, 4 May 2015 15:21:01 +0000 (UTC) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D54CD1BD1 for ; Mon, 4 May 2015 15:21:00 +0000 (UTC) Received: by qcvz3 with SMTP id z3so24119734qcv.0 for ; Mon, 04 May 2015 08:20:53 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YrgepcM28DrI4s5hXKNKNJn6IU8qbJEMZWE9eprTWyc=; b=RTWaumEZpo56lrbKRVVtKZMtOt9+7yTYBNMcaN0pRGSJsSCyLlcB47ELoE34ayMaZQ 3f5FcftlmhF4igdlcS6Ei8un561pmnzF5dS4eWCgdXt30ECH9RPXQs726Oy1/ch5tgIV hNK2v6Gz1X+Eve02NNo52s7DAYAON3q8quNn0YXh6gQwKGtWosHwgKfcGlk65JnzMl0w 7F9gjF5bV3Tett4Ku9Vk9nftTIhIbjRRr8/o/s5lDEE+Y3GdA9R5Lbau6B8KXRYAhQ8j auuG9eSeXhtVhmACRZMl3QCJniU7vg+MlLg56JaUWpoUqyjWP84Tyrpgwk9E1z5L7tak VfeQ== X-Gm-Message-State: ALoCoQlco6urd1n79cNKW3FieVDRbkWPHTfs0Amo+PsPCO4hTUJ44q1heX8KFm2HjISMgVgMERA6 MIME-Version: 1.0 X-Received: by 10.55.40.215 with SMTP id o84mr44541698qko.93.1430752853236; Mon, 04 May 2015 08:20:53 -0700 (PDT) Received: by 10.140.85.84 with HTTP; Mon, 4 May 2015 08:20:53 -0700 (PDT) In-Reply-To: References: <20150503120349.GA42415@lyxys.ka.sub.org> <20150503125325.GA70576@stack.nl> <20150503155539.GA43387@lyxys.ka.sub.org> Date: Mon, 4 May 2015 09:20:53 -0600 Message-ID: Subject: Re: mergemaster failing with read-only /usr/src From: Will Andrews To: Garrett Cooper Cc: Wolfgang Zenker , Jilles Tjoelker , FreeBSD Current , Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 15:21:01 -0000 On Sun, May 3, 2015 at 1:11 PM, Garrett Cooper wrot= e: >> Well, I do build on that machine directly, and /usr/obj is mounted r/w, >> only /usr/src is a read-only mount. Trying the workaround on the machine >> istself does not help, unfortunately: while the "make buildenv" does >> work without a problem, mergemaster still fails in the same way. > > I was going to move it to etc/tests soon since it wasn=E2=80=99t really t= esting /etc/rc.d/, but it makes more sense (with the issue above), just to = create .../tests/etc, and move things there. I wish etc/ wasn=E2=80=99t suc= h a special butterfly... I'm not sure which is the better approach. I guess you could argue that etc/rc.d tests like this are technically kernel tests (and only incidentally test the relevant rc.d script), and therefore belong in tests/etc, the same way the kernel tests are in tests/sys. --Will. From owner-freebsd-current@FreeBSD.ORG Mon May 4 15:45:09 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 022C582F; Mon, 4 May 2015 15:45:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF7B91F29; Mon, 4 May 2015 15:45:08 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C493AB99B; Mon, 4 May 2015 11:45:07 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Garrett Cooper , Wolfgang Zenker , Jilles Tjoelker , Will Andrews , Garrett Cooper Subject: Re: mergemaster failing with read-only /usr/src Date: Mon, 04 May 2015 10:05:07 -0400 Message-ID: <4602642.x7Cmbsudvo@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <20150503120349.GA42415@lyxys.ka.sub.org> <20150503155539.GA43387@lyxys.ka.sub.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 04 May 2015 11:45:07 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 15:45:09 -0000 On Sunday, May 03, 2015 12:11:03 PM Garrett Cooper wrote: > On May 3, 2015, at 8:55, Wolfgang Zenker = wrote: >=20 > > * Jilles Tjoelker [150503 14:53]: > >> On Sun, May 03, 2015 at 02:03:49PM +0200, Wolfgang Zenker wrote: > >>> I'm trying to update this system: > >>> FreeBSD pomona 11.0-CURRENT FreeBSD 11.0-CURRENT #0: Mon Apr 13 0= 3:48:04 CEST 2015 wolfgang@pomona:/usr/obj/usr/src/sys/UBQTERL mips= > >=20 > >>> Source for that was probably from about April 11th. I sucessfully= built > >>> world and kernel, ran mergemaster -p and make installworld on rev= 282299 > >>> but then mergemaster fails with: > >=20 > >>> # mergemaster -iFU > >=20 > >>> *** Creating the temporary root environment in /var/tmp/temproot > >>> *** /var/tmp/temproot ready for use > >>> *** Creating and populating directory structure in /var/tmp/tempr= oot > >=20 > >>> /bin/sh: cannot create routing_test.tmp: Read-only file system > >=20 > >>> *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to > >>> the temproot environment > >=20 > >>> Filesystems are mounted like this: > >>> # mount > >>> /dev/da0s2a on / (ufs, local, noatime) > >>> devfs on /dev (devfs, local, multilabel) > >>> /dev/da0s1 on /boot (msdosfs, local) > >>> vulcan.lyx:/usr/src11 on /usr/src (nfs, read-only) > >>> vulcan.lyx:/var/obj/11/mips64 on /usr/obj (nfs) > >=20 > >>> This used to work before. Any ideas, any further info I could pro= vide? > >=20 > >> This broke after a test was added for etc/rc.d/. Without special c= ode, > >> this causes these tests to be built and installed as part of > >> mergemaster/etcmerge, like other parts of etc. > >=20 > >> As a workaround you can do: > >> echo make -C etc obj all | make buildenv > >> on the build machine after make buildworld. Then mergemaster will = work, > >> even with a read-only /usr/obj. > >=20 > > Well, I do build on that machine directly, and /usr/obj is mounted = r/w, > > only /usr/src is a read-only mount. Trying the workaround on the ma= chine > > istself does not help, unfortunately: while the "make buildenv" doe= s > > work without a problem, mergemaster still fails in the same way. >=20 > I was going to move it to etc/tests soon since it wasn=E2=80=99t real= ly testing /etc/rc.d/, but it makes more sense (with the issue above), = just to create .../tests/etc, and move things there. I wish etc/ wasn=E2= =80=99t such a special butterfly... /etc is quite special as it isn't installed during installworld, only f= or distribution. The tests should probably be part of installworld, so pl= ease move it. --=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon May 4 16:04:45 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 555F6F76; Mon, 4 May 2015 16:04:45 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED7BB1198; Mon, 4 May 2015 16:04:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t44G4ca8095725 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 May 2015 19:04:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t44G4ca8095725 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t44G4bV9095724; Mon, 4 May 2015 19:04:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 4 May 2015 19:04:37 +0300 From: Konstantin Belousov To: Julian Elischer Cc: Jilles Tjoelker , "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. Message-ID: <20150504160437.GI2390@kib.kiev.ua> References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> <20150503143345.GB70576@stack.nl> <554787BA.1020105@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554787BA.1020105@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 16:04:45 -0000 On Mon, May 04, 2015 at 10:52:42PM +0800, Julian Elischer wrote: > On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov wrote: > >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: > >>> if you are interested in readdir(3), seekdir(3) and telldir(3) then > >>> you should look at > >>> https://reviews.freebsd.org/D2410 > >>> this patches around a problem in seekdir() that breaks Samba. > >>> Seekdir(3) will not work as expected when files prior to the point of > >>> interest in directory have been deleted since the directory was opened. > >>> Windows clients using Samba cause both these things to happen, causing > >>> the next readdir(3) after the bad seekdir(3) to skip some entries and > >>> return the wrong file. > >>> Samba only needs to step back a single directory entry in the case > >>> where it reads an entry and then discovers it can't fit it into the > >>> buffer it is sending to the windows client. It turns out we can > >>> reliably cater to Samba's requirement because the "last returned > >>> element" is always still in memory, so with a little care, we can > >>> set our filepointer back to it safely. (once) > >>> seekdir and readdir (and telldir()) need a complete rewrite along with > >>> getdirentries() but that is more than a small edit like this. > >> Can you explain your expectations from the whole readdir() vs. parallel > >> directory modifications interaction ? From what I understood so far, > >> there is unlocked modification of the container and parallel iterator > >> over the same container. IMO, in such situation, whatever tweaks you > >> apply to the iterator, it is still cannot be made reliable. > >> Before making single-purpose changes to the libc readdir and seekdir > >> code, or to the kernel code, it would be useful to state exact behaviour > >> of the dirent machinery we want to see. No, 'make samba works in my > >> situation' does not sound good enough. > > Consider the subsequence of entries that existed at opendir() time and > > were not removed until now. This subsequence is clearly defined and does > > not have concurrency problems. The order of this subsequence must remain > > unchanged and seekdir() must be correct with respect to this > > subsequence. > > > > Additionally, two other kinds of entries may be returned. New entries > > may be inserted anywhere in between the entries of the subsequence, and > > removed entries may be returned as if they were still part of the > > subsequence (so that not every readdir() needs a system call). > > > > A simple implementation for UFS-style directories is to store the offset > > in the directory (all bits of it, not masking off the lower 9 bits). > > This needs d_off or similar in struct dirent. The kernel getdirentries() > > then needs a similar loop as the old libc seekdir() to go from the start > > of the 512-byte directory block to the desired entry (since an entry may > > not exist at the stored offset within the directory block). > > > > This means that a UFS-style directory cannot be compacted (existing > > entries moved from higher to lower offsets to fill holes) while it is > > open for reading. An NFS exported directory is always open for reading. > > > > This also means that duplicate entries can only be returned if that > > particular filename was deleted and created again. > > > > Without kernel support, it is hard to get telldir/seekdir completely > > reliable. The current libc implementation is wrong since the "holes" > > within the block just disappear and change the offsets of the following > > entries; the kernel cannot fix this using entries with d_fileno = 0 > > since it cannot know, in the general case, how long the deleted entry > > was in the filesystem-independent dirent format. My previous idea of > > storing one d_fileno during telldir() is wrong since it will fail if > > that entry is deleted. > > > > If you do not care about memory usage (which probably is already > > excessive with the current libc implementation), you could store at > > telldir() time the offset of the current block returned by > > getdirentries() and the d_fileno of all entries already returned in the > > current block. > > > > The D2410 patch can conceptually work for what Samba needs, stepping > > back one directory entry. I will comment on it. > > > how long do I have to wait until I can commit this and was kib's > comment a > "do not commit"? No, I only mean what I asked about. I do not have strong objections about the patch, but whatever is done in this regard, should clearly explain the case it handles and related limitations (IMO). From owner-freebsd-current@FreeBSD.ORG Mon May 4 16:10:41 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 756C62B9 for ; Mon, 4 May 2015 16:10:41 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 331D511F3 for ; Mon, 4 May 2015 16:10:40 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t44GAYte025881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 May 2015 09:10:37 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <554799F4.9030309@freebsd.org> Date: Tue, 05 May 2015 00:10:28 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Konstantin Belousov CC: Jilles Tjoelker , "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <55432593.6050709@freebsd.org> <20150501161742.GW2390@kib.kiev.ua> <20150503143345.GB70576@stack.nl> <554787BA.1020105@freebsd.org> <20150504160437.GI2390@kib.kiev.ua> In-Reply-To: <20150504160437.GI2390@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 16:10:41 -0000 On 5/5/15 12:04 AM, Konstantin Belousov wrote: > On Mon, May 04, 2015 at 10:52:42PM +0800, Julian Elischer wrote: >> On 5/3/15 10:33 PM, Jilles Tjoelker wrote: >>> On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov wrote: >>>> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >>>>> if you are interested in readdir(3), seekdir(3) and telldir(3) then >>>>> you should look at >>>>> https://reviews.freebsd.org/D2410 >>>>> this patches around a problem in seekdir() that breaks Samba. >>>>> Seekdir(3) will not work as expected when files prior to the point of >>>>> interest in directory have been deleted since the directory was opened. >>>>> Windows clients using Samba cause both these things to happen, causing >>>>> the next readdir(3) after the bad seekdir(3) to skip some entries and >>>>> return the wrong file. >>>>> Samba only needs to step back a single directory entry in the case >>>>> where it reads an entry and then discovers it can't fit it into the >>>>> buffer it is sending to the windows client. It turns out we can >>>>> reliably cater to Samba's requirement because the "last returned >>>>> element" is always still in memory, so with a little care, we can >>>>> set our filepointer back to it safely. (once) >>>>> seekdir and readdir (and telldir()) need a complete rewrite along with >>>>> getdirentries() but that is more than a small edit like this. >>>> Can you explain your expectations from the whole readdir() vs. parallel >>>> directory modifications interaction ? From what I understood so far, >>>> there is unlocked modification of the container and parallel iterator >>>> over the same container. IMO, in such situation, whatever tweaks you >>>> apply to the iterator, it is still cannot be made reliable. >>>> Before making single-purpose changes to the libc readdir and seekdir >>>> code, or to the kernel code, it would be useful to state exact behaviour >>>> of the dirent machinery we want to see. No, 'make samba works in my >>>> situation' does not sound good enough. >>> Consider the subsequence of entries that existed at opendir() time and >>> were not removed until now. This subsequence is clearly defined and does >>> not have concurrency problems. The order of this subsequence must remain >>> unchanged and seekdir() must be correct with respect to this >>> subsequence. >>> >>> Additionally, two other kinds of entries may be returned. New entries >>> may be inserted anywhere in between the entries of the subsequence, and >>> removed entries may be returned as if they were still part of the >>> subsequence (so that not every readdir() needs a system call). >>> >>> A simple implementation for UFS-style directories is to store the offset >>> in the directory (all bits of it, not masking off the lower 9 bits). >>> This needs d_off or similar in struct dirent. The kernel getdirentries() >>> then needs a similar loop as the old libc seekdir() to go from the start >>> of the 512-byte directory block to the desired entry (since an entry may >>> not exist at the stored offset within the directory block). >>> >>> This means that a UFS-style directory cannot be compacted (existing >>> entries moved from higher to lower offsets to fill holes) while it is >>> open for reading. An NFS exported directory is always open for reading. >>> >>> This also means that duplicate entries can only be returned if that >>> particular filename was deleted and created again. >>> >>> Without kernel support, it is hard to get telldir/seekdir completely >>> reliable. The current libc implementation is wrong since the "holes" >>> within the block just disappear and change the offsets of the following >>> entries; the kernel cannot fix this using entries with d_fileno = 0 >>> since it cannot know, in the general case, how long the deleted entry >>> was in the filesystem-independent dirent format. My previous idea of >>> storing one d_fileno during telldir() is wrong since it will fail if >>> that entry is deleted. >>> >>> If you do not care about memory usage (which probably is already >>> excessive with the current libc implementation), you could store at >>> telldir() time the offset of the current block returned by >>> getdirentries() and the d_fileno of all entries already returned in the >>> current block. >>> >>> The D2410 patch can conceptually work for what Samba needs, stepping >>> back one directory entry. I will comment on it. >>> >> how long do I have to wait until I can commit this and was kib's >> comment a >> "do not commit"? > No, I only mean what I asked about. I do not have strong objections about > the patch, but whatever is done in this regard, should clearly explain the > case it handles and related limitations (IMO). ok I'll add some comments and add more in the commit message and man page. JUlian From owner-freebsd-current@FreeBSD.ORG Mon May 4 16:44:37 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 85875FF6; Mon, 4 May 2015 16:44:37 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23B80166B; Mon, 4 May 2015 16:44:37 +0000 (UTC) Received: by lbbuc2 with SMTP id uc2so109024262lbb.2; Mon, 04 May 2015 09:44:35 -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=JpLCYZCfGsMh23He267aQBpUiBjNIb6L3h/C2SmdeS4=; b=Z74lSzTjmvKCQ+AyINqSgIwxEZgI55xGX2pNEdFZm2zYRJaDHkTeubLE8Xk+2gIR0h b9qF58ROKwyMURzIOkvlp++TQdlcnfBJO3knt6j7KNEQHgcu3pyUqf96Ya0tclAfLcf0 E+wf6bTb49RS4BuRJpz5yCZ25R7ziNKdUte1n5VC1cpTKtlBemtmASefy2vlGWHm4rIj BsnzQB5OINS4UmQLXhRGTGkbszO+gyBnncXlF8hISNnjZve/tRgiGI5MGHbnSrxYyJGy y6U2tIQzXmd+69iwv6UL7wUSz3+Q88D7DTQDosXhW3KtJYuQQaZZii86hrhENmmhbXFV U2Eg== MIME-Version: 1.0 X-Received: by 10.112.220.34 with SMTP id pt2mr20368673lbc.81.1430757875158; Mon, 04 May 2015 09:44:35 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.164.38 with HTTP; Mon, 4 May 2015 09:44:34 -0700 (PDT) Received: by 10.112.164.38 with HTTP; Mon, 4 May 2015 09:44:34 -0700 (PDT) In-Reply-To: References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> Date: Mon, 4 May 2015 12:44:34 -0400 X-Google-Sender-Auth: qy-uQiHbMlgnQgCOQXMTBysPcAQ Message-ID: Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 From: Craig Rodrigues To: Cy Schubert Cc: freebsd-current Current , jenkins-admin@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 16:44:37 -0000 You need to do a better job at figuring out why you broke things. This is not the first time you've broken things with an ntp import. -- Craig On May 4, 2015 8:45 AM, "Cy Schubert" wrote: > That file was deleted long ago. > > Cy Schubert > > On May 4, 2015 7:49 AM, "Craig Rodrigues" wrote: > >> >> >> On Monday, May 4, 2015, Cy Schubert wrote: >>> >>> >>> I cannot see where the problem is. All local tests, including universe, >>> have built cleanly. >>> >> >> In this log: https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/console >> search for: >> >> error: version control conflict marker in file >> >> >> -- >> >> Craig >> >> >> >> From owner-freebsd-current@FreeBSD.ORG Mon May 4 16:57:01 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F180838; Mon, 4 May 2015 16:57:01 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 656B417C1; Mon, 4 May 2015 16:57:01 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 63F9E3AB; Mon, 4 May 2015 16:57:01 +0000 (UTC) Date: Mon, 4 May 2015 16:57:01 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ian@FreeBSD.org, jhb@FreeBSD.org, neel@FreeBSD.org, cy@FreeBSD.org, gjb@FreeBSD.org Message-ID: <1873931779.6.1430758621302.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2726 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 16:57:01 -0000 See Changes: [gjb] Add logic to detect if the net/bsdec2-image-upload port needs to be installed. [1] For the cw-ec2-portinstall and ec2ami targets, touch the .TARGET file after completion to prevent duplicate invocations. Add cw-ec2-portinstall and ec2ami to CLEANFILES. Submitted by:=09cperciva[1] MFC after:=093 days Sponsored by:=09The FreeBSD Foundation [ian] On an icache sync by address/len, round the length up if the operatio= n spans a cacheline boundary. PR:=09=09199740 Submitted by:=09Juergen Weiss [jhb] Various updates to the ftruncate(2) documentation: - Note that ftruncate(2) can operate on shared memory objects and cross reference shm_open(2). - Note that ftruncate(2) does not change the file position pointer (aka seek pointer) of the file descriptor. - ftruncate(2) will fail with EINVAL for all sorts of other fd types than just sockets, so instead note that it fails for all but regular files and shared memory objects. - Note that ftruncate(2) also appeared in 4.2BSD along with truncate(2). (Or at least the manpage for both appeared in 4.2, I did not check the kernel code itself to see if either predated 4.2.) PR:=09=09199472 (2) Submitted by:=09andrew@ugh.net.au (2) MFC after:=091 week [jhb] Partially revert r255486, the first argument to socketpair() is a soc= ket domain, not a file descriptor. Use 'domain' instead of the original 'd' for this argument to match socket(2). PR:=09=09199491 Reported by:=09sp55aa@qq.com MFC after:=091 week [cy] Restore CPU dependent compile time conditionals. MFC after:=091 month (with r281143 and r282408) ------------------------------------------ [...truncated 129257 lines...] ^ y.tab.c:1351:1: error: version control conflict marker in file <<<<<<< .mine ^ y.tab.c:1286:1: error: version control conflict marker in file <<<<<<< .mine ^ :382:1: error: version control conflict mark= er in file <<<<<<< .mine ^ :420:1: error: version control conflict mark= er in file <<<<<<< .mine ^ :488:1: error: version control conflict mark= er in file <<<<<<< .mine ^ :543:1: error: version control conflict mark= er in file <<<<<<< .mine ^ fatal error: too many errors emitted, stopping now [-ferror-limit=3D] 20 errors generated. --- usr.bin.depend__D --- --- .depend --- --- usr.sbin.depend__D --- --- depend_subdir_smbmsg --- echo smbmsg: >> .depend --- usr.bin.depend__D --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DHAVE_ICONV=3D1 -DHAVE_ICONV_H=3D1 -DIC= ONV_CONST=3Dconst -DBSDTAR_VERSION_STRING=3D\"3.1.2\" -DPLATFORM_CONFIG_H= =3D\" -I -I = -I -std=3Dgnu99 --- usr.sbin.depend__D --- --- depend_subdir_snapinfo --- =3D=3D=3D> usr.sbin/snapinfo (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo snapinfo: >> .depend --- depend_subdir_spkrtest --- =3D=3D=3D> usr.sbin/spkrtest (depend) --- usr.bin.depend__D --- --- depend_subdir_tcopy --- =3D=3D=3D> usr.bin/tcopy (depend) --- depend_subdir_tar --- echo bsdtar: >> .depend --- usr.sbin.depend__D --- --- depend_subdir_spray --- =3D=3D=3D> usr.sbin/spray (depend) --- usr.bin.depend__D --- --- depend_subdir_tcopy --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo tcopy: >> .depend --- usr.sbin.depend__D --- --- .depend --- rm -f .depend --- usr.bin.depend__D --- --- depend_subdir_tee --- --- usr.sbin.depend__D --- CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.bin.depend__D --- =3D=3D=3D> usr.bin/tee (depend) --- usr.sbin.depend__D --- echo spray: >> .depend --- usr.bin.depend__D --- --- depend_subdir_telnet --- =3D=3D=3D> usr.bin/telnet (depend) --- depend_subdir_tee --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- depend_subdir_telnet --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DKLUDGELINEMODE -DUSE_TERMIO -DENV_HACK= -DOPIE -I -I -DINET6 -DIPSEC -DENCRYPTION -= DAUTHENTICATION -DIPSEC -DKRB5 -DFORWARD -Dnet_write=3Dtelnet_net_write -st= d=3Dgnu99 --- depend_subdir_tee --- echo tee: >> .depend --- depend_subdir_tests --- =3D=3D=3D> usr.bin/tests (depend) --- usr.sbin.depend__D --- --- depend_subdir_syslogd --- =3D=3D=3D> usr.sbin/syslogd (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DINET6 -I -std=3Dgnu99 echo syslogd: >> .depend --- depend_subdir_sysrc --- =3D=3D=3D> usr.sbin/sysrc (depend) --- depend_subdir_tcpdchk --- =3D=3D=3D> usr.sbin/tcpdchk (depend) --- usr.bin.depend__D --- --- depend_subdir_telnet --- echo telnet: >> .depend --- usr.sbin.depend__D --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DREAL_DAEMON_DIR=3D\"/usr/libexec\" -DS= EVERITY=3DLOG_INFO -DRFC931_TIMEOUT=3D10 -DPROCESS_OPTIONS -DHOSTS_DENY=3D\= "/etc/hosts.deny\" -DHOSTS_ALLOW=3D\"/etc/hosts.allow\" -DINET6 -std=3Dgnu9= 9 --- usr.bin.depend__D --- --- depend_subdir_tftp --- =3D=3D=3D> usr.bin/tftp (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -std=3Dgnu99 = --- usr.sbin.depend__D --- echo tcpdchk: >> .depend --- depend_subdir_tcpdmatch --- =3D=3D=3D> usr.sbin/tcpdmatch (depend) --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DREAL_DAEMON_DIR=3D\"/usr/libexec\" -DS= EVERITY=3DLOG_INFO -DRFC931_TIMEOUT=3D10 -DINET6 -std=3Dgnu99 --- usr.bin.depend__D --- echo tftp: >> .depend --- depend_subdir_time --- =3D=3D=3D> usr.bin/time (depend) --- usr.sbin.depend__D --- echo tcpdmatch: >> .depend --- depend_subdir_tcpdrop --- =3D=3D=3D> usr.sbin/tcpdrop (depend) --- usr.bin.depend__D --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.sbin.depend__D --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 --- usr.bin.depend__D --- echo time: >> .depend --- usr.sbin.depend__D --- echo tcpdrop: >> .depend --- usr.bin.depend__D --- --- depend_subdir_timeout --- --- depend_subdir_tip --- --- depend_subdir_timeout --- =3D=3D=3D> usr.bin/timeout (depend) --- depend_subdir_tip --- =3D=3D=3D> usr.bin/tip (depend) --- _sub.depend --- =3D=3D=3D> usr.bin/tip/tip (depend) --- depend_subdir_timeout --- --- _sub.depend --- =3D=3D=3D> usr.bin/timeout/tests (depend) --- scripts.depend --- (cd = && make -f SUBDIR=3D _RECURSING_PROGS=3D depend) --- depend_subdir_tip --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -I -DDEFBR=3D9600 -DDEFFS=3DBUFSIZ -DACULOG -DPRIS= TINE -DCONNECT -DV831 -DVENTEL -DHAYES -DCOURIER -DT3000 -std=3Dgnu99 <= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/tip/tip/../libacu/d= f.c> --- depend_subdir_timeout --- --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -std=3Dgnu99 echo timeout: >> .depend --- depend_subdir_top --- =3D=3D=3D> usr.bin/top (depend) --- sigdesc.h --- awk -f < > sigdesc.h --- top.local.h --- Making top.local.h from --- .depend --- rm -f .depend CC=3D'cc ' mkdep -f .depend -a -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I= -I -I. -s= td=3Dgnu99 --- usr.sbin.depend__D --- --- depend_subdir_ntp --- mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_ntp] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.sbin.depend__D] Error code 2 make[2]: stopped in --- usr.bin.depend__D --- --- depend_subdir_tip --- echo tip: >> .depend A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_tip] Error code 2 make[3]: stopped in --- depend_subdir_top --- echo top: >> .depend A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_top] Error code 2 make[3]: stopped in --- depend_subdir_svn --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.depend] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.depend] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [depend_subdir_svn] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [usr.bin.depend__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [_depend] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:38:01 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C123885F; Mon, 4 May 2015 17:38:01 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E5031C7B; Mon, 4 May 2015 17:38:01 +0000 (UTC) Received: by pabtp1 with SMTP id tp1so166623350pab.2; Mon, 04 May 2015 10:38:01 -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=jSpR3m4/n4XeQCWcshG1dL2HmGJfkrgEOqvncPPCQhY=; b=YqUpYK1MZw5vNOCJOy9HZFGbYwHoe+sFzvY0454vt4SuJQG31pcfgTnS+BDJsh4i90 GFhmsY/Sl5um4PgX4t/KdOlARb4bLPIxzbZNn4+EHBZ4EOxHDwZ2R4e0v7p3nYKpiHjO tQ16nP7E0XptgNdNN+NBFQzmPMLVH9HpISYBdpJHtdEvQGMOioJBuI1+CIDiVvLoYfO1 /GeUHZsgcVLnPqW9EzBDKiEHwLc98omHIYJyqBa3s3z6FQ2JSfX7227y2vnzttX6sAIq 5/4tWEHJgLT1RNwHf7/Uv/hugV1t/a35FLzv04TRr3QRTQ6a0Xb5+Nvpp1hrbwmiup48 h+2Q== MIME-Version: 1.0 X-Received: by 10.68.198.101 with SMTP id jb5mr23635415pbc.84.1430761080921; Mon, 04 May 2015 10:38:00 -0700 (PDT) Sender: cschuber@gmail.com Received: by 10.70.128.10 with HTTP; Mon, 4 May 2015 10:38:00 -0700 (PDT) Received: by 10.70.128.10 with HTTP; Mon, 4 May 2015 10:38:00 -0700 (PDT) In-Reply-To: References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> Date: Mon, 4 May 2015 10:38:00 -0700 X-Google-Sender-Auth: oPZclCSC9c7k9GpyQ8VQSJSAJnE Message-ID: Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 From: Cy Schubert To: Craig Rodrigues Cc: jenkins-admin@freebsd.org, freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 17:38:01 -0000 I think jenkins copy of head still contains ntp_parser.y. I see no issue here. Cy Schubert You need to do a better job at figuring out why you broke things. This is not the first time you've broken things with an ntp import. -- Craig On May 4, 2015 8:45 AM, "Cy Schubert" wrote: > That file was deleted long ago. > > Cy Schubert > > On May 4, 2015 7:49 AM, "Craig Rodrigues" wrote: > >> >> >> On Monday, May 4, 2015, Cy Schubert wrote: >>> >>> >>> I cannot see where the problem is. All local tests, including universe, >>> have built cleanly. >>> >> >> In this log: https://jenkins.freebsd.org/job/FreeBSD_HEAD/2725/console >> search for: >> >> error: version control conflict marker in file >> >> >> -- >> >> Craig >> >> >> >> From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:46:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 557DFC0D; Mon, 4 May 2015 17:46:17 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CE2B1D92; Mon, 4 May 2015 17:46:17 +0000 (UTC) Received: by pdea3 with SMTP id a3so169274419pde.3; Mon, 04 May 2015 10:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=D2mwQ0WuSQP+yVcH+Hikt19gtVJLbzYKM4V2w1tAPrM=; b=utQVQMqR9nhwWcNSJ9AVvtbGg3UH245K0ltQSQezF838mCxUiWwRL1s3j0pqemDiso y1pRJrT6bYllOCcv3eiJsYmEKUarRSnYdW9zIa1wYZyk8h++Ms3WA+BgxNnTE86pTJZ7 b6trOMexfDpbQv2CG81TjVC7Jb7yVp4xkvODjL0YOUgOtCAMqt4uzqMNFWdS6OEROXJl 7JxIEkem9SUSgvNn+NGMsdK5cq0wNVPlhKzPMCaxYLtRkJIAR6gkxS5QPovQGbCu7bOz U3GppP66E7EgF5DKRnIf4TbDpQN0OP3GhM43QKbaP7APMQ0R3E7+UHpZO2+2K4dB0Wi1 cQNw== X-Received: by 10.66.186.142 with SMTP id fk14mr44298751pac.74.1430761576560; Mon, 04 May 2015 10:46:16 -0700 (PDT) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id tk9sm13395730pbc.35.2015.05.04.10.46.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 May 2015 10:46:15 -0700 (PDT) Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_25D6209B-BC82-4CC3-B423-FF575009E03F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: Date: Mon, 4 May 2015 10:46:10 -0700 Cc: Craig Rodrigues , jenkins-admin@freebsd.org, freebsd-current Current Message-Id: References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 17:46:17 -0000 --Apple-Mail=_25D6209B-BC82-4CC3-B423-FF575009E03F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 4, 2015, at 10:38, Cy Schubert wrote: > I think jenkins copy of head still contains ntp_parser.y. I see no = issue > here. >=20 > Cy Schubert > >=20 > You need to do a better job at figuring out why you broke things. > This is not the first time you've broken things with an ntp import. I don=92t see that file either=85 $ ls contrib/ntp/ntpd/ntp_parser.y ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory $ svnversion 282423M $ svn status | grep -v \? M Makefile Thanks, -NGie --Apple-Mail=_25D6209B-BC82-4CC3-B423-FF575009E03F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVR7BlAAoJEMZr5QU6S73egAYH/Rou90ELa3ADjAiUa6/uvJPA Dp9Du6YseOi1puB7uAK+FtSoT+RDSRoJLnvywpQbP7RR2XMyK0WFHL2keaTB2Mte BxGg7GEt7jwQQ5y5+CCe2nLZrWnvJTgZ4C1SAoras5SbRV4wTWGM5BOgBsJLUnPB 2QOB846LwYS0Jj8xFRAF4GwgANWATbDc6SAO5uhDH0sbSQVxz7gEcfKio2a5c6xe uVTKsaiZ+agb+fKOS00rBnq/i+Cj5rnxackc9hzDBCVlh5Jp75QMQkbE8RvSHibh L9XIlbxKvvdTZJBqtS1ybxYmR9S0MxrZzjfsCc1vQEccl9+4P/IG47UTQ0eeS4w= =6fqs -----END PGP SIGNATURE----- --Apple-Mail=_25D6209B-BC82-4CC3-B423-FF575009E03F-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:48:36 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEB12E1D; Mon, 4 May 2015 17:48:35 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3EAF1DB5; Mon, 4 May 2015 17:48:35 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so166826750pac.1; Mon, 04 May 2015 10:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=vgrt8L+loYVz0eVkVT1M7aN2vo+WI+apiO8jCfrSR0Q=; b=AO2GpYd1aajIzOXLu5+GTg0SjQ3uSC1LdjLkw9CMNizzzh8EZOiBtf+L4Qw2S6z3wb /rd3Ed36XEBu+L3dCUXRiSKbO+zTpBcKzjv/JzMyPTcI7a9Ul1WZ9DTSciyiGQPRdMwO cdWz2MCoYE/0+ijB8kqH6nJIofPRZ0E9SYmObB5xv2Au0txcKgs/Ln1eMEw73n+2nSnC aABWK9yV/fDPBTRz8Ncr6rUtIvwQWVr0ixC0hn5P+1tMCiD/ImcBWX06LAXDjGco+WeD vVjfiI9njlG0CYPk6kmOGe/Uo/5pvlPExFL8+PsajKfge72j3gu2tfmRmCgAfD1tkVhp hOsw== X-Received: by 10.70.101.231 with SMTP id fj7mr44883278pdb.84.1430761715261; Mon, 04 May 2015 10:48:35 -0700 (PDT) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id om10sm13392887pbb.58.2015.05.04.10.48.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 May 2015 10:48:34 -0700 (PDT) Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E9156F81-6FAC-4AD7-B1A8-43175D5B7F77"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: Date: Mon, 4 May 2015 10:48:34 -0700 Cc: Craig Rodrigues , jenkins-admin@freebsd.org, freebsd-current Current Message-Id: <4155B752-510F-4429-A97F-EB15A89D0301@gmail.com> References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 17:48:36 -0000 --Apple-Mail=_E9156F81-6FAC-4AD7-B1A8-43175D5B7F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 4, 2015, at 10:46, Garrett Cooper wrote: >=20 > On May 4, 2015, at 10:38, Cy Schubert = wrote: >=20 >> I think jenkins copy of head still contains ntp_parser.y. I see no = issue >> here. >>=20 >> Cy Schubert >> >>=20 >> You need to do a better job at figuring out why you broke things. >> This is not the first time you've broken things with an ntp import. >=20 > I don=92t see that file either=85 >=20 > $ ls contrib/ntp/ntpd/ntp_parser.y > ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory > $ svnversion > 282423M > $ svn status | grep -v \? > M Makefile >=20 > Thanks, > -NGie That being said, I=92m not sure if checking in bison-processed source = was the wisest thing in the world (contrib/ntp/ntpd/ntp_parser.c). Thanks! --Apple-Mail=_E9156F81-6FAC-4AD7-B1A8-43175D5B7F77 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVR7DyAAoJEMZr5QU6S73eMIIIAKbgrhvSHR83IB1G/iyCX36f F6kV7wtlyZ4F79t4F6gTq76KvQ899STwbemXDXxIMqROqPo1GZFh1CMoO+7XxlTe Xusi51n3qtuwOnmBJKiNEfTg7WK6K5YqF1z9ZQpSSvjMfc4rZGRjC1SosrZGLXX2 WKIkDKIRZzMi5fy6w4sWlvB0z9+NOSWviVb/Q5kZknqMMdO9i9KJKhghvCvwggyo 66AwX36M2ZKfHAGIyH8JL1FCZxcI4qgQHsIZJY5EDbW/p/5RSHJsO/vh9w5wIXD8 P3YmB+dMcdfBOcj8qVJ9b7r3eeae7nkk24aPuPPKAHuH2dfrFe1mRf5QAGyETnY= =1UtI -----END PGP SIGNATURE----- --Apple-Mail=_E9156F81-6FAC-4AD7-B1A8-43175D5B7F77-- From owner-freebsd-current@FreeBSD.ORG Mon May 4 17:52:26 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93EE2AB; Mon, 4 May 2015 17:52:26 +0000 (UTC) Received: from FreeBSD.cs.nctu.edu.tw (FreeBSD.cs.nctu.edu.tw [140.113.17.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDB01E96; Mon, 4 May 2015 17:52:26 +0000 (UTC) Received: by FreeBSD.cs.nctu.edu.tw (Postfix, from userid 1058) id D3A652C54; Tue, 5 May 2015 01:52:18 +0800 (CST) Date: Tue, 5 May 2015 01:52:18 +0800 From: Li-Wen Hsu To: Garrett Cooper Cc: Cy Schubert , Craig Rodrigues , jenkins-admin@freebsd.org, freebsd-current Current Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 Message-ID: <20150504175218.GA41785@FreeBSD.cs.nctu.edu.tw> References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 17:52:26 -0000 On Mon, May 04, 2015 at 10:46:10 -0700, Garrett Cooper wrote: > > On May 4, 2015, at 10:38, Cy Schubert wrote: > > > I think jenkins copy of head still contains ntp_parser.y. I see no issue > > here. > > > > Cy Schubert > > > > > > You need to do a better job at figuring out why you broke things. > > This is not the first time you've broken things with an ntp import. > > I don’t see that file either… > > $ ls contrib/ntp/ntpd/ntp_parser.y > ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory > $ svnversion > 282423M > $ svn status | grep -v \? > M Makefile > I wiped out the workspace, it will do a fresh checkout on next build. Let's see if this helps. Li-Wen -- Li-Wen Hsu http://lwhsu.org From owner-freebsd-current@FreeBSD.ORG Mon May 4 18:25:13 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B08B44; Mon, 4 May 2015 18:25:13 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D3141263; Mon, 4 May 2015 18:25:13 +0000 (UTC) Received: by pdbqa5 with SMTP id qa5so170065115pdb.1; Mon, 04 May 2015 11:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=n6DGBrQqP6EHid0LkRVhqVHy6BdlU160MUHyP6detyM=; b=fraYhXsKREAycXE1LJNmSSHPjlyD63617N6jNQKwR5tov6fomzbRtW+o6AkKAMwoad nzQxA429vn/3/soZS8t2dlbs8Csh8pJwBpFWzsrc0xM1A3QbmsFDOdg2zEuvHmMLugBH pTNcIZLmP0qvagDloEMivzgxR6yLWvMXx3qJ+p6nLhzt1Z5hSWKnb7k3F00qmyxIYiBW yinNzHjza9NXpeJpRzFwE3GgKrkiHINNAb9qs/Um1CcH/C3FBz6XQxbZAtWhSL7lp+el OMpky0Cgqxq7tcKcq5gbWit3JDjbD712uLHQWwVMGLXgJWkeqxzJ2Tqgs/5hl9EbklHv lkOw== X-Received: by 10.70.98.171 with SMTP id ej11mr44388919pdb.72.1430763913040; Mon, 04 May 2015 11:25:13 -0700 (PDT) Received: from [127.0.0.1] ([184.151.231.207]) by mx.google.com with ESMTPSA id m4sm13497659pdo.78.2015.05.04.11.25.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 May 2015 11:25:12 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.2.1.3442) Message-ID: <20150504182511.6623380.70839.387@gmail.com> Date: Mon, 04 May 2015 11:25:11 -0700 Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 From: cschuber@gmail.com In-Reply-To: <4155B752-510F-4429-A97F-EB15A89D0301@gmail.com> References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> <4155B752-510F-4429-A97F-EB15A89D0301@gmail.com> To: Garrett Cooper , Cy Schubert Cc: Craig Rodrigues , jenkins-admin@freebsd.org, freebsd-current Current X-Mailman-Approved-At: Mon, 04 May 2015 18:39:51 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 18:25:13 -0000 There was some debate about this last time. It was decided to use the .c fi= le. The tarball ships with both. The .y file only used if its timestamp is = newer, which is never the case. The .y file should never have been imported in the first place. That was my= fault.=C2=A0 ~cy Sent from my BlackBerry 10 smartphone on the Bell network. =C2=A0 Original Message =C2=A0 From: Garrett Cooper Sent: Monday, May 4, 2015 10:49 To: Cy Schubert Cc: Craig Rodrigues; jenkins-admin@freebsd.org; freebsd-current Current Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 On May 4, 2015, at 10:46, Garrett Cooper wrote: >=20 > On May 4, 2015, at 10:38, Cy Schubert wrote: >=20 >> I think jenkins copy of head still contains ntp_parser.y. I see no issue >> here. >>=20 >> Cy Schubert >> >>=20 >> You need to do a better job at figuring out why you broke things. >> This is not the first time you've broken things with an ntp import. >=20 > I don=E2=80=99t see that file either=E2=80=A6 >=20 > $ ls contrib/ntp/ntpd/ntp_parser.y > ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory > $ svnversion > 282423M > $ svn status | grep -v \? > M Makefile >=20 > Thanks, > -NGie That being said, I=E2=80=99m not sure if checking in bison-processed source= was the wisest thing in the world (contrib/ntp/ntpd/ntp_parser.c). Thanks! From owner-freebsd-current@FreeBSD.ORG Mon May 4 21:42:00 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C24CE3AF; Mon, 4 May 2015 21:42:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AE3371A8B; Mon, 4 May 2015 21:42:00 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 077B6413; Mon, 4 May 2015 21:42:00 +0000 (UTC) Date: Mon, 4 May 2015 21:42:00 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, ian@FreeBSD.org, jhb@FreeBSD.org, neel@FreeBSD.org, cy@FreeBSD.org, bapt@FreeBSD.org, gjb@FreeBSD.org Message-ID: <1054425166.7.1430775720769.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1873931779.6.1430758621302.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1873931779.6.1430758621302.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2727 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 21:42:00 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon May 4 22:07:42 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B432AB8; Mon, 4 May 2015 22:07:42 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 675DB1D06; Mon, 4 May 2015 22:07:42 +0000 (UTC) Received: by pdea3 with SMTP id a3so175110146pde.3; Mon, 04 May 2015 15:07:42 -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=hyhcMmhmxMntyWcdDI3JSPB6ErGPdU49MzwnxYgGoEg=; b=Q7Sw8af6ClelojDXJS/ZGRNGSRvngrgiKNEXImv4FE52JeYXYaP3tSOf2CFfXg67MX ydBJ3fzsyzehdCJYJ8rPn5n/Y/LogAwaRfvzdHxL3+ckAAxytdBKBKlwBBv6VqEaXVPs XUrXZk+TO39hUTw5MDC3XVYErU6N0kwA1SiO2DskQu2rXnmAJC9BTTc9GBd2OcGrHSxr 8Eh4oCHbowMRtM7En1KRKZkwYl/3K7OdVMlJi3FbD6cNDRpvPm7rjS+8AwaYmDHJviyY EnVtQeMKr71B47VG3aazYwJt5bye3oGVmhlYl3EFUuyf00Ujoydlt2AEHJef6wRNrkB1 q3TQ== MIME-Version: 1.0 X-Received: by 10.68.190.9 with SMTP id gm9mr35224488pbc.110.1430777262035; Mon, 04 May 2015 15:07:42 -0700 (PDT) Sender: cschuber@gmail.com Received: by 10.70.128.10 with HTTP; Mon, 4 May 2015 15:07:41 -0700 (PDT) Received: by 10.70.128.10 with HTTP; Mon, 4 May 2015 15:07:41 -0700 (PDT) In-Reply-To: <20150504175218.GA41785@FreeBSD.cs.nctu.edu.tw> References: <861766483.4.1430730824975.JavaMail.jenkins@jenkins-9.freebsd.org> <201505041326.t44DQH1E046967@slippy.cwsent.com> <20150504175218.GA41785@FreeBSD.cs.nctu.edu.tw> Date: Mon, 4 May 2015 15:07:41 -0700 X-Google-Sender-Auth: d_oCXeY6pHo_k3Ma93VhqHqdDFI Message-ID: Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2725 From: Cy Schubert To: Li-Wen Hsu Cc: jenkins-admin@freebsd.org, Craig Rodrigues , Garrett Cooper , freebsd-current Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 May 2015 22:07:42 -0000 Thanks. That fixed the jenkins build. Cy Schubert On May 4, 2015 10:52 AM, "Li-Wen Hsu" wrote: > On Mon, May 04, 2015 at 10:46:10 -0700, Garrett Cooper wrote: > > > > On May 4, 2015, at 10:38, Cy Schubert wrote: > > > > > I think jenkins copy of head still contains ntp_parser.y. I see no > issue > > > here. > > > > > > Cy Schubert > > > > > > > > > You need to do a better job at figuring out why you broke things. > > > This is not the first time you've broken things with an ntp import. > > > > I don=E2=80=99t see that file either=E2=80=A6 > > > > $ ls contrib/ntp/ntpd/ntp_parser.y > > ls: contrib/ntp/ntpd/ntp_parser.y: No such file or directory > > $ svnversion > > 282423M > > $ svn status | grep -v \? > > M Makefile > > > > I wiped out the workspace, it will do a fresh checkout on next build. > Let's see if this helps. > > Li-Wen > > > -- > Li-Wen Hsu > http://lwhsu.org > > From owner-freebsd-current@FreeBSD.ORG Tue May 5 02:36:45 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75110EBF; Tue, 5 May 2015 02:36:45 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C1B61914; Tue, 5 May 2015 02:36:44 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t452abHq027778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 May 2015 19:36:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55482CAF.8010905@freebsd.org> Date: Tue, 05 May 2015 10:36:31 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Rick Macklem , Jilles Tjoelker , Jilles Tjoelker , "current@freebsd.org" Subject: Re: seekdir/readdir patch .. Call for Review. References: <250284541.31463801.1430786573076.JavaMail.root@uoguelph.ca> In-Reply-To: <250284541.31463801.1430786573076.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 02:36:45 -0000 On 5/5/15 8:42 AM, Rick Macklem wrote: > Julian Elischer wrote: >> On 5/3/15 10:33 PM, Jilles Tjoelker wrote: >>> On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov >>> wrote: >>>> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >>>>> if you are interested in readdir(3), seekdir(3) and telldir(3) >>>>> then >>>>> you should look at >>>>> https://reviews.freebsd.org/D2410 >>>>> this patches around a problem in seekdir() that breaks Samba. >>>>> Seekdir(3) will not work as expected when files prior to the >>>>> point of >>>>> interest in directory have been deleted since the directory was >>>>> opened. >>>>> Windows clients using Samba cause both these things to happen, >>>>> causing >>>>> the next readdir(3) after the bad seekdir(3) to skip some entries >>>>> and >>>>> return the wrong file. >>>>> Samba only needs to step back a single directory entry in the >>>>> case >>>>> where it reads an entry and then discovers it can't fit it into >>>>> the >>>>> buffer it is sending to the windows client. It turns out we can >>>>> reliably cater to Samba's requirement because the "last returned >>>>> element" is always still in memory, so with a little care, we can >>>>> set our filepointer back to it safely. (once) >>>>> seekdir and readdir (and telldir()) need a complete rewrite along >>>>> with >>>>> getdirentries() but that is more than a small edit like this. >>>> Can you explain your expectations from the whole readdir() vs. >>>> parallel >>>> directory modifications interaction ? From what I understood so >>>> far, >>>> there is unlocked modification of the container and parallel >>>> iterator >>>> over the same container. IMO, in such situation, whatever tweaks >>>> you >>>> apply to the iterator, it is still cannot be made reliable. >>>> Before making single-purpose changes to the libc readdir and >>>> seekdir >>>> code, or to the kernel code, it would be useful to state exact >>>> behaviour >>>> of the dirent machinery we want to see. No, 'make samba works in >>>> my >>>> situation' does not sound good enough. >>> Consider the subsequence of entries that existed at opendir() time >>> and >>> were not removed until now. This subsequence is clearly defined and >>> does >>> not have concurrency problems. The order of this subsequence must >>> remain >>> unchanged and seekdir() must be correct with respect to this >>> subsequence. >>> >>> Additionally, two other kinds of entries may be returned. New >>> entries >>> may be inserted anywhere in between the entries of the subsequence, >>> and >>> removed entries may be returned as if they were still part of the >>> subsequence (so that not every readdir() needs a system call). >>> >>> A simple implementation for UFS-style directories is to store the >>> offset >>> in the directory (all bits of it, not masking off the lower 9 >>> bits). >>> This needs d_off or similar in struct dirent. The kernel >>> getdirentries() >>> then needs a similar loop as the old libc seekdir() to go from the >>> start >>> of the 512-byte directory block to the desired entry (since an >>> entry may >>> not exist at the stored offset within the directory block). >>> >>> This means that a UFS-style directory cannot be compacted (existing >>> entries moved from higher to lower offsets to fill holes) while it >>> is >>> open for reading. An NFS exported directory is always open for >>> reading. >>> >>> This also means that duplicate entries can only be returned if that >>> particular filename was deleted and created again. >>> >>> Without kernel support, it is hard to get telldir/seekdir >>> completely >>> reliable. The current libc implementation is wrong since the >>> "holes" >>> within the block just disappear and change the offsets of the >>> following >>> entries; the kernel cannot fix this using entries with d_fileno = 0 >>> since it cannot know, in the general case, how long the deleted >>> entry >>> was in the filesystem-independent dirent format. My previous idea >>> of >>> storing one d_fileno during telldir() is wrong since it will fail >>> if >>> that entry is deleted. >>> >>> If you do not care about memory usage (which probably is already >>> excessive with the current libc implementation), you could store at >>> telldir() time the offset of the current block returned by >>> getdirentries() and the d_fileno of all entries already returned in >>> the >>> current block. >>> >>> The D2410 patch can conceptually work for what Samba needs, >>> stepping >>> back one directory entry. I will comment on it. >>> >> how long do I have to wait until I can commit this and was kib's >> comment a >> "do not commit"? >> > What about the bug Jilles reports in D2410? > - He said you might fix the problem by having telldir move the entry > to the head of the list when it has a hit. However, this means that > an "old" entry gets modified. Is it possible for this "modified" > entry to be a match and get modified again, and so on...? > > I will comment on the patch once you decide how to deal with Jilles > bug. I don't think is is a "bug" as such.. it wasn't a case I was looking to fix and it is just as it was before. I'd rephrase it as: "Jilles asks that we also fix the case where the previous telldir response is a recycling of an old telldir response." In actual fact this scenario will almost never happen. because the previous time the telldir call returned that location, the 'fixtelldir' function would have later been called on the result, which would have been modified to point to the start of the NEXT buffer, and as such would not get matched on the next telldir to the same place, as that would be looking for the first location after the end of the previous buffer. OR it does match because we seeked back to that location, o which case we will get the same buffer alredy fixed. The two addresses are logically equivalent, but you can only know that after you have loaded the next buffer. i.e. the first time telldir is called on location X it returns seek=123, location= 4096 (one past end of buffer) then a read happens and it gets converted to: seek= 124 location=0 (beginning of next buffer.. then some more reads happen or so and we seek back to 124,0 and do a new telldir, in which case we get a 'pre-fixed' value of 124,0 not 123,4096. so while fixtelldir is not called, it doesn't matter. If we seek back FURTHER than 124,0 then we are into the "unreliable unfixed zone". Assuming that by some luck we don't get confused (there were no deletes) and we then work forwards back to 123,4096 and do a telldir again, we will NOT match the old one, which was changed to be 124,0 so we will allocate a new one at 123,4096, which in turn will get 'fixed' to be 124,0 So it worked. the only 'less than optimal' thing here is that we now have two entries saying 124,0. But the case is so unusual and in a totally unsupported mode of operation, that as far as I know no-one uses, that adding code to merge the two entries is just not worth it. It still returns the correct values, just wastes some memory. Anyone who wants to do a DOS wasting these 16 bytes of memory, has to do it via writing code to do it. so.. why would one DOS oneself? we COULD mode the item up front but it'd never get matched unless there had not been a matching read following the first telldir which is really unlikely. > rick > >> _______________________________________________ >> 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 Tue May 5 11:04:47 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 337D91FA; Tue, 5 May 2015 11:04:47 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A21F31120; Tue, 5 May 2015 11:04:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBACWokhV/95baINWBoNfXAWDGMJogUwKhTdOAoFxEgEBAQEBAQGBCoQgAQEBAwEBAQEaBisgCwUWGAICDRkCKQEJGAENBggHBAEcBIgDCA2wEZNTAQEBAQEFAQEBAQEBAQEBGYEhihiEMwEBDQ8BMweCaIFFBZYwgkaBTINVPYYOim2DUyOBZR8DHIFtIjEHgQQ5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,372,1427774400"; d="scan'208";a="208694941" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 05 May 2015 07:04:44 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E2C09B3F45; Tue, 5 May 2015 07:04:43 -0400 (EDT) Date: Tue, 5 May 2015 07:04:43 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: Jilles Tjoelker , Jilles Tjoelker , "current@freebsd.org" Message-ID: <1741454718.31580103.1430823883918.JavaMail.root@uoguelph.ca> In-Reply-To: <55482CAF.8010905@freebsd.org> Subject: Re: seekdir/readdir patch .. Call for Review. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 11:04:47 -0000 Julian Elischer wrote: > On 5/5/15 8:42 AM, Rick Macklem wrote: > > Julian Elischer wrote: > >> On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > >>> On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov > >>> wrote: > >>>> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: > >>>>> if you are interested in readdir(3), seekdir(3) and telldir(3) > >>>>> then > >>>>> you should look at > >>>>> https://reviews.freebsd.org/D2410 > >>>>> this patches around a problem in seekdir() that breaks Samba. > >>>>> Seekdir(3) will not work as expected when files prior to the > >>>>> point of > >>>>> interest in directory have been deleted since the directory was > >>>>> opened. > >>>>> Windows clients using Samba cause both these things to happen, > >>>>> causing > >>>>> the next readdir(3) after the bad seekdir(3) to skip some > >>>>> entries > >>>>> and > >>>>> return the wrong file. > >>>>> Samba only needs to step back a single directory entry in the > >>>>> case > >>>>> where it reads an entry and then discovers it can't fit it into > >>>>> the > >>>>> buffer it is sending to the windows client. It turns out we can > >>>>> reliably cater to Samba's requirement because the "last > >>>>> returned > >>>>> element" is always still in memory, so with a little care, we > >>>>> can > >>>>> set our filepointer back to it safely. (once) > >>>>> seekdir and readdir (and telldir()) need a complete rewrite > >>>>> along > >>>>> with > >>>>> getdirentries() but that is more than a small edit like this. > >>>> Can you explain your expectations from the whole readdir() vs. > >>>> parallel > >>>> directory modifications interaction ? From what I understood so > >>>> far, > >>>> there is unlocked modification of the container and parallel > >>>> iterator > >>>> over the same container. IMO, in such situation, whatever > >>>> tweaks > >>>> you > >>>> apply to the iterator, it is still cannot be made reliable. > >>>> Before making single-purpose changes to the libc readdir and > >>>> seekdir > >>>> code, or to the kernel code, it would be useful to state exact > >>>> behaviour > >>>> of the dirent machinery we want to see. No, 'make samba works in > >>>> my > >>>> situation' does not sound good enough. > >>> Consider the subsequence of entries that existed at opendir() > >>> time > >>> and > >>> were not removed until now. This subsequence is clearly defined > >>> and > >>> does > >>> not have concurrency problems. The order of this subsequence must > >>> remain > >>> unchanged and seekdir() must be correct with respect to this > >>> subsequence. > >>> > >>> Additionally, two other kinds of entries may be returned. New > >>> entries > >>> may be inserted anywhere in between the entries of the > >>> subsequence, > >>> and > >>> removed entries may be returned as if they were still part of the > >>> subsequence (so that not every readdir() needs a system call). > >>> > >>> A simple implementation for UFS-style directories is to store the > >>> offset > >>> in the directory (all bits of it, not masking off the lower 9 > >>> bits). > >>> This needs d_off or similar in struct dirent. The kernel > >>> getdirentries() > >>> then needs a similar loop as the old libc seekdir() to go from > >>> the > >>> start > >>> of the 512-byte directory block to the desired entry (since an > >>> entry may > >>> not exist at the stored offset within the directory block). > >>> > >>> This means that a UFS-style directory cannot be compacted > >>> (existing > >>> entries moved from higher to lower offsets to fill holes) while > >>> it > >>> is > >>> open for reading. An NFS exported directory is always open for > >>> reading. > >>> > >>> This also means that duplicate entries can only be returned if > >>> that > >>> particular filename was deleted and created again. > >>> > >>> Without kernel support, it is hard to get telldir/seekdir > >>> completely > >>> reliable. The current libc implementation is wrong since the > >>> "holes" > >>> within the block just disappear and change the offsets of the > >>> following > >>> entries; the kernel cannot fix this using entries with d_fileno = > >>> 0 > >>> since it cannot know, in the general case, how long the deleted > >>> entry > >>> was in the filesystem-independent dirent format. My previous idea > >>> of > >>> storing one d_fileno during telldir() is wrong since it will fail > >>> if > >>> that entry is deleted. > >>> > >>> If you do not care about memory usage (which probably is already > >>> excessive with the current libc implementation), you could store > >>> at > >>> telldir() time the offset of the current block returned by > >>> getdirentries() and the d_fileno of all entries already returned > >>> in > >>> the > >>> current block. > >>> > >>> The D2410 patch can conceptually work for what Samba needs, > >>> stepping > >>> back one directory entry. I will comment on it. > >>> > >> how long do I have to wait until I can commit this and was kib's > >> comment a > >> "do not commit"? > >> > > What about the bug Jilles reports in D2410? > > - He said you might fix the problem by having telldir move the > > entry > > to the head of the list when it has a hit. However, this means > > that > > an "old" entry gets modified. Is it possible for this "modified" > > entry to be a match and get modified again, and so on...? > > > > I will comment on the patch once you decide how to deal with Jilles > > bug. > I don't think is is a "bug" as such.. > it wasn't a case I was looking to fix and it is just as it was > before. > I'd rephrase it as: "Jilles asks that we also fix the case where the > previous telldir response is > a recycling of an old telldir response." > For the case where it hits a matching entry, the entry at the head of the list is some older entry. Your fixtelldir() changes that older entry. Is that what you want? > In actual fact this scenario will almost never happen. > because the previous time the telldir call returned that location, > the 'fixtelldir' function would have later been called on the > result, > which > would have been modified to point to the start of the NEXT buffer, > and as such would not get matched on the next telldir to the same > place, as that would be looking for the first location after the end > of the previous buffer. OR it does match because we seeked back to > that location, o which case we will get the same buffer alredy fixed. If at this point, it fixes it again by replacing the values with the same ones, then I guess it may be ok. I'll have to take another look at this. I may remove myself from the review, since I'll admit I don't understand the implications of this patch well enough. I'm looking for weird cases where it would cause a regression, because to me, if it doesn't break anything not already broken, I don't have a problem with it. I will comment in phabricator soon (maybe to-night). rick ps: This should probably go in the phabricator comments if it isn't already there. > The two addresses are logically equivalent, > but you can only know that after you have loaded the next buffer. > > i.e. the first time telldir is called on location X it returns > seek=123, location= 4096 (one past end of buffer) > then a read happens and it gets converted to: > seek= 124 location=0 (beginning of next buffer.. > then some more reads happen or so and we > seek back to 124,0 > and do a new telldir, in which case we get a 'pre-fixed' value of > 124,0 not 123,4096. > so while fixtelldir is not called, it doesn't matter. > > If we seek back FURTHER than 124,0 then we are into the "unreliable > unfixed zone". > Assuming that by some luck we don't get confused (there were no > deletes) and we then work forwards back to 123,4096 and do a telldir > again, > we will NOT match the old one, which was changed to be 124,0 > so we will allocate a new one at 123,4096, > which in turn will get 'fixed' to be 124,0 So it worked. the only > 'less > than optimal' thing here is that we now have two entries saying > 124,0. > But the case is so unusual and in a totally unsupported mode of > operation, that as far as I know no-one uses, that adding code > to merge the two entries is just not worth it. It still returns the > correct values, just wastes some memory. Anyone who wants to > do a DOS wasting these 16 bytes of memory, has to do it via writing > code to do it. so.. why would one DOS oneself? > > we COULD mode the item up front but it'd never get matched unless > there had not been a matching read following the first telldir which > is really unlikely. > > > rick > > > >> _______________________________________________ > >> 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 Tue May 5 12:24:04 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1C87C16; Tue, 5 May 2015 12:24:04 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAD71ACD; Tue, 5 May 2015 12:24:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwBxtUhV/95baINcg19cBYMYwl8JgUwKhTdOAoFuFAEBAQEBAQGBCoQhAQEEAQEBGgYEJyALGxgCAg0ZAikBCRgBDQYIBwQBHASICw2wRJNWAQEBAQEBBAEBAQEBAQEBARmBIYoYhDMBARw0B4JogUUFljCCRoFMg1U9hg6KbYNTI4FlgisiMQeBBDmBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,372,1427774400"; d="scan'208";a="208708009" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 05 May 2015 08:24:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 74735B3F33; Tue, 5 May 2015 08:24:02 -0400 (EDT) Date: Tue, 5 May 2015 08:24:02 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: "current@freebsd.org" , Jilles Tjoelker , Konstantin Belousov Message-ID: <899435410.31616191.1430828642464.JavaMail.root@uoguelph.ca> In-Reply-To: <55470427.3010009@freebsd.org> Subject: Re: seekdir/readdir patch .. Call for Review. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 12:24:04 -0000 Julian Elischer wrote: > On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov > > wrote: > >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: > >>> if you are interested in readdir(3), seekdir(3) and telldir(3) > >>> then > >>> you should look at > >>> https://reviews.freebsd.org/D2410 > >>> this patches around a problem in seekdir() that breaks Samba. > >>> Seekdir(3) will not work as expected when files prior to the > >>> point of > >>> interest in directory have been deleted since the directory was > >>> opened. > >>> Windows clients using Samba cause both these things to happen, > >>> causing > >>> the next readdir(3) after the bad seekdir(3) to skip some entries > >>> and > >>> return the wrong file. > >>> Samba only needs to step back a single directory entry in the > >>> case > >>> where it reads an entry and then discovers it can't fit it into > >>> the > >>> buffer it is sending to the windows client. It turns out we can > >>> reliably cater to Samba's requirement because the "last returned > >>> element" is always still in memory, so with a little care, we can > >>> set our filepointer back to it safely. (once) > >>> seekdir and readdir (and telldir()) need a complete rewrite along > >>> with > >>> getdirentries() but that is more than a small edit like this. > >> Can you explain your expectations from the whole readdir() vs. > >> parallel > >> directory modifications interaction ? From what I understood so > >> far, > >> there is unlocked modification of the container and parallel > >> iterator > >> over the same container. IMO, in such situation, whatever tweaks > >> you > >> apply to the iterator, it is still cannot be made reliable. > >> Before making single-purpose changes to the libc readdir and > >> seekdir > >> code, or to the kernel code, it would be useful to state exact > >> behaviour > >> of the dirent machinery we want to see. No, 'make samba works in > >> my > >> situation' does not sound good enough. > > Consider the subsequence of entries that existed at opendir() time > > and > > were not removed until now. This subsequence is clearly defined and > > does > > not have concurrency problems. The order of this subsequence must > > remain > > unchanged and seekdir() must be correct with respect to this > > subsequence. > > > > Additionally, two other kinds of entries may be returned. New > > entries > > may be inserted anywhere in between the entries of the subsequence, > > and > > removed entries may be returned as if they were still part of the > > subsequence (so that not every readdir() needs a system call). > > > > A simple implementation for UFS-style directories is to store the > > offset > > in the directory (all bits of it, not masking off the lower 9 > > bits). > > This needs d_off or similar in struct dirent. The kernel > > getdirentries() > > then needs a similar loop as the old libc seekdir() to go from the > > start > > of the 512-byte directory block to the desired entry (since an > > entry may > > not exist at the stored offset within the directory block). > > > > This means that a UFS-style directory cannot be compacted (existing > > entries moved from higher to lower offsets to fill holes) while it > > is > > open for reading. An NFS exported directory is always open for > > reading. > > > > This also means that duplicate entries can only be returned if that > > particular filename was deleted and created again. > > > > Without kernel support, it is hard to get telldir/seekdir > > completely > > reliable. The current libc implementation is wrong since the > > "holes" > > within the block just disappear and change the offsets of the > > following > > entries; the kernel cannot fix this using entries with d_fileno = 0 > > since it cannot know, in the general case, how long the deleted > > entry > > was in the filesystem-independent dirent format. My previous idea > > of > > storing one d_fileno during telldir() is wrong since it will fail > > if > > that entry is deleted. > > > > If you do not care about memory usage (which probably is already > > excessive with the current libc implementation), you could store at > > telldir() time the offset of the current block returned by > > getdirentries() and the d_fileno of all entries already returned in > > the > > current block. > > > > The D2410 patch can conceptually work for what Samba needs, > > stepping > > back one directory entry. I will comment on it. > thanks > > your comment is correct, but I don't think it really matters because > I'm only claiming > to fix a really small set of possible usages.. I might add a > sentence > in the seekdir > man page specifying what does and doesn't work. > Ok, I think I finally understand the bug that this patch is fixing... If telldir() is called when at the end of a block read by getdirentries(), it sets loc_seek to the seek position for the block and loc_loc to the offset of the end of the block. This is somewhat bogus, but works for the simple read-only case for seekdir() because it does a readdir()->getdirentries() of the next block. This patch fixes the telldir entry to refer to the beginning of the next block, so that seekdir() seeks to the correct block. I could argue that a more correct version of your fixup function would scan the telldir list for a match instead of just testing the first one. However, I now see that once fixed up, it won't match it again, so your code seems safe, just not completely correct. I'll take a closer look at it and put something in pahbricator later to-day, but I think it's ok. I would suggest describing the bug would help simple types like me figure it out. Thanks for your work on this, rick > > > _______________________________________________ > 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 Tue May 5 13:40:29 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D449014B; Tue, 5 May 2015 13:40:29 +0000 (UTC) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Verizon Public SureServer CA G14-SHA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 81E801357; Tue, 5 May 2015 13:40:29 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="5.13,372,1427778000"; d="scan'208";a="269036787" From: Eric Badger To: "current@freebsd.org" , "rstone@FreeBSD.org" Subject: PCI PF memory decode disable when sizing VF BARs Thread-Topic: PCI PF memory decode disable when sizing VF BARs Thread-Index: AdCHMw+ggum3MjVXSzieEZBy1GXG8wABWymg Date: Tue, 5 May 2015 13:37:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.100.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 13:40:29 -0000 Hi Ryan and -current, During IOV config, when setting up VF bars, several calls are made to 'pci_= read_bar' (in sys/dev/pci/pci.c) in order to size VF BARs, which causes mem= ory decoding to be turned off temporarily for the PF associated with those = VFs. I'm finding that this can interfere with an already running PF. I've s= everal thoughts about how this might be handled, but I'm not convinced I un= derstand all of the consequences each of them entails, so any thoughts from= others would be appreciated. Here are ideas I've considered: 1. Check the value of the 'reg' arg to 'pci_read_bar' and, if it is outside= a standard BAR range, don't disable memory decoding. This is simple, but f= eels a little hackish and may have consequences I'm missing. 2. Pass some flag/context through such that pci_read_bar knows it is config= uring VF BARs (we might instead disable VF MSE in this case, if it is enabl= ed). It would be necessary to carry this flag/context through several funct= ion calls before reaching pci_read_bar, which might end up being ugly. 3. Rearrange the calls so that VF BARs are sized when the PF is not yet run= ning, and that info saved until VFs are created. Probably it would be done = when the PF BARs are sized for any device supporting IOV, even if that devi= ce never creates VFs. Thanks, Eric From owner-freebsd-current@FreeBSD.ORG Tue May 5 19:53:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87E7916B; Tue, 5 May 2015 19:53:45 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5601279; Tue, 5 May 2015 19:53:45 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A2D0D1FE023; Tue, 5 May 2015 21:53:42 +0200 (CEST) Message-ID: <55491FF5.8020006@selasky.org> Date: Tue, 05 May 2015 21:54:29 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org CC: Ian Lepore , Svatopluk Kraus Subject: Re: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET References: <1429882188.1157.2.camel@freebsd.org> <553B2D56.1000405@selasky.org> <1878637.qa1RymYSTA@ralph.baldwin.cx> <553F253D.7010605@selasky.org> In-Reply-To: <553F253D.7010605@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:53:45 -0000 Hi, https://svnweb.freebsd.org/changeset/base/282506 https://svnweb.freebsd.org/changeset/base/282507 Does this need to be MFC'ed to 8-stable? I guess not? --HPS From owner-freebsd-current@FreeBSD.ORG Tue May 5 19:58:55 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76768421; Tue, 5 May 2015 19:58:55 +0000 (UTC) Received: from relay.mailchannels.net (ar-005-i192.relay.mailchannels.net [162.253.144.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7183D12BC; Tue, 5 May 2015 19:58:53 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 48D73A18F7; Tue, 5 May 2015 19:58:45 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (smtp3.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 05 May 2015 19:58:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1430855925547:3678586346 X-MC-Ingress-Time: 1430855925547 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp3.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YpizM-0006yU-UV; Tue, 05 May 2015 19:58:45 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t45JwguT063225; Tue, 5 May 2015 13:58:42 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+/KoT6+65lOkifuLWrlhYX Message-ID: <1430855922.6170.127.camel@freebsd.org> Subject: Re: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET From: Ian Lepore To: Hans Petter Selasky Cc: John Baldwin , freebsd-current@freebsd.org, Svatopluk Kraus Date: Tue, 05 May 2015 13:58:42 -0600 In-Reply-To: <55491FF5.8020006@selasky.org> References: <1429882188.1157.2.camel@freebsd.org> <553B2D56.1000405@selasky.org> <1878637.qa1RymYSTA@ralph.baldwin.cx> <553F253D.7010605@selasky.org> <55491FF5.8020006@selasky.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:58:55 -0000 On Tue, 2015-05-05 at 21:54 +0200, Hans Petter Selasky wrote: > Hi, > > https://svnweb.freebsd.org/changeset/base/282506 > https://svnweb.freebsd.org/changeset/base/282507 > > Does this need to be MFC'ed to 8-stable? I guess not? > > --HPS We don't really maintain the arm code on branches earlier than 10-stable unless someone specifically asks for a change in 8.x. (afaik, virtually nobody uses 9.x on arm). -- Ian From owner-freebsd-current@FreeBSD.ORG Tue May 5 23:15:22 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3716A938 for ; Tue, 5 May 2015 23:15:22 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0121A19C8 for ; Tue, 5 May 2015 23:15:22 +0000 (UTC) Received: by igblo3 with SMTP id lo3so115225998igb.1 for ; Tue, 05 May 2015 16:15:21 -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=1GVVVz6cNJ9Mj+Qbwdb70cle93cVEt4k40BM53xJXos=; b=Rc3i/sS78yiBtLR+4h9nMAdNCnUCmXaswygNcyFTFpT85N3dYLllr/lKZ9baESmD+M qLARA/1YGwIGCbQvz6W3xOeM7i5VanQ3Xa+cFcQyCrH7Oz3FBQPopkcYp5Mbl4qHBeCZ ANwZiA7J9DfZaWVt+YnPSN6hwMVDO9qH+EYCZWeoQ2hofi/SE6R40tS+SZ8TYZuD/NDL lcAMJ1dHq/pRKXhH8yz7Ys5a+6pAPyA8NbP5RZXgrHD0j080N12n0fcfRMEiSrkSZ8li 4vXcjAkKUl6L5mcArXlkMukrWu7d9rFAkoyloiz0bhtl9Q3jN9qKlFBstSVGaPcVszj1 V7SA== MIME-Version: 1.0 X-Received: by 10.107.33.21 with SMTP id h21mr37247195ioh.1.1430867721402; Tue, 05 May 2015 16:15:21 -0700 (PDT) Received: by 10.107.40.194 with HTTP; Tue, 5 May 2015 16:15:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 May 2015 19:15:21 -0400 Message-ID: Subject: Re: PCI PF memory decode disable when sizing VF BARs From: Ryan Stone To: Eric Badger Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 23:15:22 -0000 On Tue, May 5, 2015 at 9:17 AM, Eric Badger wrote: > Hi Ryan and -current, > > During IOV config, when setting up VF bars, several calls are made to > 'pci_read_bar' (in sys/dev/pci/pci.c) in order to size VF BARs, which > causes memory decoding to be turned off temporarily for the PF associated > with those VFs. I'm finding that this can interfere with an already running > PF. > Ouch. That's a nasty bug. Thanks for tracking this down. > 1. Check the value of the 'reg' arg to 'pci_read_bar' and, if it is > outside a standard BAR range, don't disable memory decoding. This is > simple, but feels a little hackish and may have consequences I'm missing. > 2. Pass some flag/context through such that pci_read_bar knows it is > configuring VF BARs (we might instead disable VF MSE in this case, if it is > enabled). It would be necessary to carry this flag/context through several > function calls before reaching pci_read_bar, which might end up being ugly. > 3. Rearrange the calls so that VF BARs are sized when the PF is not yet > running, and that info saved until VFs are created. Probably it would be > done when the PF BARs are sized for any device supporting IOV, even if that > device never creates VFs. > I don't think that #3 is possible. Unfortunately the BAR is sized again when the BAR is allocated so it's difficult so it wouldn't be enough to just size the BAR during attach. I would have to reserve the memory space during attach, but that might reserve physical address space that other devices need to function. Actually, that problem will prevent #2 from being easy to implement too. We'd have to add an extra flag to pci_alloc_multi_resource. I think that #1 is the best option. There's already a precedent for something similar has it has a special base for the device ROM BAR. I haven't had a chance to test this yet, but I believe that this patch will solve the problem: https://people.freebsd.org/~rstone/patches/iov_bar.diff From owner-freebsd-current@FreeBSD.ORG Tue May 5 23:33:30 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7077AEEE; Tue, 5 May 2015 23:33:30 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 16E591BF7; Tue, 5 May 2015 23:33:29 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBADKUklV/95baINcg19cBYMYwnKBTAqFN04CgXATAQEBAQEBAYEKhCABAQEDAQEBARoGBCcgCwUWGAICDRkCKQEJGAENBggHBAEcBIgDCA2weJNeAQEBAQEBBAEBAQEBAQEBARmBIYoYhDMBAQUXNAeCaIFFBYsgixCCRoFMg1U9hg6KbYNTI4FlHwIBHIFtIjEHgQQ5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,376,1427774400"; d="scan'208";a="208890770" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 05 May 2015 19:33:27 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A5A8AB4056; Tue, 5 May 2015 19:33:27 -0400 (EDT) Date: Tue, 5 May 2015 19:33:27 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: "current@freebsd.org" , Jilles Tjoelker , Konstantin Belousov Message-ID: <1054739779.32254571.1430868807663.JavaMail.root@uoguelph.ca> In-Reply-To: <554715CF.2010703@freebsd.org> Subject: Re: seekdir/readdir patch .. Call for Review. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 23:33:30 -0000 Julian Elischer wrote: > On 5/3/15 10:33 PM, Jilles Tjoelker wrote: > > On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov > > wrote: > >> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: > >>> if you are interested in readdir(3), seekdir(3) and telldir(3) > >>> then > >>> you should look at > >>> https://reviews.freebsd.org/D2410 > >>> this patches around a problem in seekdir() that breaks Samba. > >>> Seekdir(3) will not work as expected when files prior to the > >>> point of > >>> interest in directory have been deleted since the directory was > >>> opened. > >>> Windows clients using Samba cause both these things to happen, > >>> causing > >>> the next readdir(3) after the bad seekdir(3) to skip some entries > >>> and > >>> return the wrong file. > >>> Samba only needs to step back a single directory entry in the > >>> case > >>> where it reads an entry and then discovers it can't fit it into > >>> the > >>> buffer it is sending to the windows client. It turns out we can > >>> reliably cater to Samba's requirement because the "last returned > >>> element" is always still in memory, so with a little care, we can > >>> set our filepointer back to it safely. (once) > >>> seekdir and readdir (and telldir()) need a complete rewrite along > >>> with > >>> getdirentries() but that is more than a small edit like this. > >> Can you explain your expectations from the whole readdir() vs. > >> parallel > >> directory modifications interaction ? From what I understood so > >> far, > >> there is unlocked modification of the container and parallel > >> iterator > >> over the same container. IMO, in such situation, whatever tweaks > >> you > >> apply to the iterator, it is still cannot be made reliable. > >> Before making single-purpose changes to the libc readdir and > >> seekdir > >> code, or to the kernel code, it would be useful to state exact > >> behaviour > >> of the dirent machinery we want to see. No, 'make samba works in > >> my > >> situation' does not sound good enough. > > Consider the subsequence of entries that existed at opendir() time > > and > > were not removed until now. This subsequence is clearly defined and > > does > > not have concurrency problems. The order of this subsequence must > > remain > > unchanged and seekdir() must be correct with respect to this > > subsequence. > > > > Additionally, two other kinds of entries may be returned. New > > entries > > may be inserted anywhere in between the entries of the subsequence, > > and > > removed entries may be returned as if they were still part of the > > subsequence (so that not every readdir() needs a system call). > > > > A simple implementation for UFS-style directories is to store the > > offset > > in the directory (all bits of it, not masking off the lower 9 > > bits). > > This needs d_off or similar in struct dirent. The kernel > > getdirentries() > > then needs a similar loop as the old libc seekdir() to go from the > > start > > of the 512-byte directory block to the desired entry (since an > > entry may > > not exist at the stored offset within the directory block). > At least it needs some more information in struct dirent than there > is > now.. > A cookie is the current fashion.. that assumes however that the > filesystems > are capable of converting backwards from cookie to 'location'. ZFS > claims to > be able to do so.. My current plan for a patch is... - d_cookie would be the "physical" file system position of the next directory entry - a ngetdirentries() would take a "physical" cookie as a value/result argument. It would indicate where to start and would return the cookie for the next entry after what is returned. (It could probably be stuffed in uio_offset, but I think it might be clearer to make it a separate arg.) --> It would pass this physical cookie down to the file system's VOP_READDIR(). (For UFS it would be the byte offset in the on-disk directory. For ZFS, I believe it is an index for the entry. For NFS, it is the cookie that is sent to the server. For others, I don't yet know.) - dd_seek, dd_loc, loc_seek and loc_loc would be replaced by dd_cookie and loc_cookie. (For arches where sizeof(long) == 8, I think telldir() could just return the cookie and forget about the loc_XX structures?) This would get rid of the loc_seek, loc_loc bogosity that no longer makes much sense, since the byte offset in what is returned by getdirentries() has little to do with the "physical" directory position. I have already done the kernel stuff for some file systems and the libc changes actually simplify things compared to what is there now. rick > Thee other thing to do would be to store some sort > of strong > hash of the name and inode# in each telldir entry.. > we would seek to the saved seek location and seek forward computing > or > looking > for a matching hash. I woudl also add that the man pages talk about > the > readdir blocksize a bit and mention the file blocksize (and stat) > which is often > way dfferent from 512 bytes.. usually 16k or so these days. > I found setting the read size to the same as the fs blocksize seemd > to > work well. > > > > This means that a UFS-style directory cannot be compacted (existing > > entries moved from higher to lower offsets to fill holes) while it > > is > > open for reading. An NFS exported directory is always open for > > reading. > yes so a UFS filesystem that is exported could never do garbage > collection. > > > > This also means that duplicate entries can only be returned if that > > particular filename was deleted and created again. > > > > Without kernel support, it is hard to get telldir/seekdir > > completely > > reliable. The current libc implementation is wrong since the > > "holes" > > within the block just disappear and change the offsets of the > > following > > entries; the kernel cannot fix this using entries with d_fileno = 0 > > since it cannot know, in the general case, how long the deleted > > entry > > was in the filesystem-independent dirent format. > > yes it's the filesystem that knows.. we USED to return empty entries > in the dirent list but that was removed recently think. > > My previous idea of > > storing one d_fileno during telldir() is wrong since it will fail > > if > > that entry is deleted. > > > > If you do not care about memory usage (which probably is already > > excessive with the current libc implementation), you could store at > > telldir() time the offset of the current block returned by > > getdirentries() and the d_fileno of all entries already returned in > > the > > current block. > > > > The D2410 patch can conceptually work for what Samba needs, > > stepping > > back one directory entry. I will comment on it. > > > > _______________________________________________ > 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 Wed May 6 03:54:58 2015 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F510E4B for ; Wed, 6 May 2015 03:54:58 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F605179C for ; Wed, 6 May 2015 03:54:57 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-241-118.lns20.per4.internode.on.net [121.45.241.118]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t463shEe041266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 5 May 2015 20:54:48 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5549907E.1020501@freebsd.org> Date: Wed, 06 May 2015 11:54:38 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Rick Macklem CC: "current@freebsd.org" , Jilles Tjoelker , Konstantin Belousov Subject: Re: seekdir/readdir patch .. Call for Review. References: <1054739779.32254571.1430868807663.JavaMail.root@uoguelph.ca> In-Reply-To: <1054739779.32254571.1430868807663.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 03:54:58 -0000 On 5/6/15 7:33 AM, Rick Macklem wrote: > Julian Elischer wrote: >> On 5/3/15 10:33 PM, Jilles Tjoelker wrote: >>> On Fri, May 01, 2015 at 07:17:42PM +0300, Konstantin Belousov >>> wrote: >>>> On Fri, May 01, 2015 at 03:04:51PM +0800, Julian Elischer wrote: >>>>> if you are interested in readdir(3), seekdir(3) and telldir(3) >>>>> then >>>>> you should look at >>>>> https://reviews.freebsd.org/D2410 >>>>> this patches around a problem in seekdir() that breaks Samba. >>>>> Seekdir(3) will not work as expected when files prior to the >>>>> point of >>>>> interest in directory have been deleted since the directory was >>>>> opened. >>>>> Windows clients using Samba cause both these things to happen, >>>>> causing >>>>> the next readdir(3) after the bad seekdir(3) to skip some entries >>>>> and >>>>> return the wrong file. >>>>> Samba only needs to step back a single directory entry in the >>>>> case >>>>> where it reads an entry and then discovers it can't fit it into >>>>> the >>>>> buffer it is sending to the windows client. It turns out we can >>>>> reliably cater to Samba's requirement because the "last returned >>>>> element" is always still in memory, so with a little care, we can >>>>> set our filepointer back to it safely. (once) >>>>> seekdir and readdir (and telldir()) need a complete rewrite along >>>>> with >>>>> getdirentries() but that is more than a small edit like this. >>>> Can you explain your expectations from the whole readdir() vs. >>>> parallel >>>> directory modifications interaction ? From what I understood so >>>> far, >>>> there is unlocked modification of the container and parallel >>>> iterator >>>> over the same container. IMO, in such situation, whatever tweaks >>>> you >>>> apply to the iterator, it is still cannot be made reliable. >>>> Before making single-purpose changes to the libc readdir and >>>> seekdir >>>> code, or to the kernel code, it would be useful to state exact >>>> behaviour >>>> of the dirent machinery we want to see. No, 'make samba works in >>>> my >>>> situation' does not sound good enough. >>> Consider the subsequence of entries that existed at opendir() time >>> and >>> were not removed until now. This subsequence is clearly defined and >>> does >>> not have concurrency problems. The order of this subsequence must >>> remain >>> unchanged and seekdir() must be correct with respect to this >>> subsequence. >>> >>> Additionally, two other kinds of entries may be returned. New >>> entries >>> may be inserted anywhere in between the entries of the subsequence, >>> and >>> removed entries may be returned as if they were still part of the >>> subsequence (so that not every readdir() needs a system call). >>> >>> A simple implementation for UFS-style directories is to store the >>> offset >>> in the directory (all bits of it, not masking off the lower 9 >>> bits). >>> This needs d_off or similar in struct dirent. The kernel >>> getdirentries() >>> then needs a similar loop as the old libc seekdir() to go from the >>> start >>> of the 512-byte directory block to the desired entry (since an >>> entry may >>> not exist at the stored offset within the directory block). >> At least it needs some more information in struct dirent than there >> is >> now.. >> A cookie is the current fashion.. that assumes however that the >> filesystems >> are capable of converting backwards from cookie to 'location'. ZFS >> claims to >> be able to do so.. > My current plan for a patch is... > - d_cookie would be the "physical" file system position of the next > directory entry > - a ngetdirentries() would take a "physical" cookie as a value/result > argument. It would indicate where to start and would return the cookie > for the next entry after what is returned. (It could probably be stuffed > in uio_offset, but I think it might be clearer to make it a separate arg.) > --> It would pass this physical cookie down to the file system's > VOP_READDIR(). (For UFS it would be the byte offset in the on-disk > directory. For ZFS, I believe it is an index for the entry. For > NFS, it is the cookie that is sent to the server. For others, I > don't yet know.) > - dd_seek, dd_loc, loc_seek and loc_loc would be replaced by dd_cookie and > loc_cookie. (For arches where sizeof(long) == 8, I think telldir() could > just return the cookie and forget about the loc_XX structures?) > This would get rid of the loc_seek, loc_loc bogosity that no longer makes > much sense, since the byte offset in what is returned by getdirentries() > has little to do with the "physical" directory position. > > I have already done the kernel stuff for some file systems and the libc > changes actually simplify things compared to what is there now. zfs already has a cookie production facility as part of the VFS readdir (or is it dir-read?) method. > > rick > >> Thee other thing to do would be to store some sort >> of strong >> hash of the name and inode# in each telldir entry.. >> we would seek to the saved seek location and seek forward computing >> or >> looking >> for a matching hash. I woudl also add that the man pages talk about >> the >> readdir blocksize a bit and mention the file blocksize (and stat) >> which is often >> way dfferent from 512 bytes.. usually 16k or so these days. >> I found setting the read size to the same as the fs blocksize seemd >> to >> work well. >>> This means that a UFS-style directory cannot be compacted (existing >>> entries moved from higher to lower offsets to fill holes) while it >>> is >>> open for reading. An NFS exported directory is always open for >>> reading. >> yes so a UFS filesystem that is exported could never do garbage >> collection. >>> This also means that duplicate entries can only be returned if that >>> particular filename was deleted and created again. >>> >>> Without kernel support, it is hard to get telldir/seekdir >>> completely >>> reliable. The current libc implementation is wrong since the >>> "holes" >>> within the block just disappear and change the offsets of the >>> following >>> entries; the kernel cannot fix this using entries with d_fileno = 0 >>> since it cannot know, in the general case, how long the deleted >>> entry >>> was in the filesystem-independent dirent format. >> yes it's the filesystem that knows.. we USED to return empty entries >> in the dirent list but that was removed recently think. >>> My previous idea of >>> storing one d_fileno during telldir() is wrong since it will fail >>> if >>> that entry is deleted. >>> >>> If you do not care about memory usage (which probably is already >>> excessive with the current libc implementation), you could store at >>> telldir() time the offset of the current block returned by >>> getdirentries() and the d_fileno of all entries already returned in >>> the >>> current block. >>> >>> The D2410 patch can conceptually work for what Samba needs, >>> stepping >>> back one directory entry. I will comment on it. >>> >> _______________________________________________ >> 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 Wed May 6 09:06:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9010A52 for ; Wed, 6 May 2015 09:06:49 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78896181D for ; Wed, 6 May 2015 09:06:49 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1YpvHs-0043er-N8>; Wed, 06 May 2015 11:06:40 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1YpvHs-0036It-JA>; Wed, 06 May 2015 11:06:40 +0200 Date: Wed, 6 May 2015 11:06:31 +0200 From: "O. Hartmann" To: freebsd-current Subject: vt: blank screen switching from X11 to console/vtty Message-ID: <20150506110631.403eec15@freyja.zeit4.iv.bundesimmobilien.de> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 09:06:49 -0000 Running a Fujitsu Celsius M740 Workstation with a nVidia Quadro NVS 315 GPU, most recent driver (346.16), UEFI boot, and FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r282520: Wed May 6 08:14:14 CEST 2015 amd64, switching from graphics terminal (X11), located at vty7 (xdm) to any console vty[0-6], results in a blank screen. I use older nVidia hardware (GTX560Ti) on another system with the same CURRENT and xorg port (most recent updated), but with legacy boot (no UEFI), but with vt() enabled and same revision of the nVidia driver, there is no problem switching from graphical console to consoles. What is the solution, if any? Regards, O. Hartmann From owner-freebsd-current@FreeBSD.ORG Wed May 6 16:49:40 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5614D2FD; Wed, 6 May 2015 16:49:40 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 302D61E8F; Wed, 6 May 2015 16:49:40 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0D9F0B9B3; Wed, 6 May 2015 12:49:39 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Ryan Stone , Eric Badger , "current@freebsd.org" Subject: Re: PCI PF memory decode disable when sizing VF BARs Date: Wed, 06 May 2015 11:45:52 -0400 Message-ID: <11092809.7nmbPfKl0V@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 May 2015 12:49:39 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 16:49:40 -0000 On Tuesday, May 05, 2015 07:15:21 PM Ryan Stone wrote: > On Tue, May 5, 2015 at 9:17 AM, Eric Badger wrote: > > > Hi Ryan and -current, > > > > During IOV config, when setting up VF bars, several calls are made to > > 'pci_read_bar' (in sys/dev/pci/pci.c) in order to size VF BARs, which > > causes memory decoding to be turned off temporarily for the PF associated > > with those VFs. I'm finding that this can interfere with an already running > > PF. > > > > Ouch. That's a nasty bug. Thanks for tracking this down. > > > > 1. Check the value of the 'reg' arg to 'pci_read_bar' and, if it is > > outside a standard BAR range, don't disable memory decoding. This is > > simple, but feels a little hackish and may have consequences I'm missing. > > > 2. Pass some flag/context through such that pci_read_bar knows it is > > configuring VF BARs (we might instead disable VF MSE in this case, if it is > > enabled). It would be necessary to carry this flag/context through several > > function calls before reaching pci_read_bar, which might end up being ugly. > > > 3. Rearrange the calls so that VF BARs are sized when the PF is not yet > > running, and that info saved until VFs are created. Probably it would be > > done when the PF BARs are sized for any device supporting IOV, even if that > > device never creates VFs. > > > > I don't think that #3 is possible. Unfortunately the BAR is sized again > when the BAR is allocated so it's difficult so it wouldn't be enough to > just size the BAR during attach. I would have to reserve the memory space > during attach, but that might reserve physical address space that other > devices need to function. > > Actually, that problem will prevent #2 from being easy to implement too. > We'd have to add an extra flag to pci_alloc_multi_resource. I think that > #1 is the best option. There's already a precedent for something similar > has it has a special base for the device ROM BAR. > > I haven't had a chance to test this yet, but I believe that this patch will > solve the problem: > > https://people.freebsd.org/~rstone/patches/iov_bar.diff There are some devices with BARs in non-standard locations. :( If there is a flag to just disable the VF bar decoding, then ideally we should just be doing that and leaving the global decoding flag alone while sizing the VF BAR. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed May 6 18:24:26 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1DCE933; Wed, 6 May 2015 18:24:25 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA8481AB3; Wed, 6 May 2015 18:24:25 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so103701328igb.0; Wed, 06 May 2015 11:24:24 -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=vcw8JI0ZFh7d6nd9PRJaIYOdgzAQJlT/59UDmhK6hZg=; b=nMOAuWDKNlDfKezeLfnEzB5yBOp/ISIbcIuOzmQp9hE+WU+WhgP7jfZV+C9299vPDq fe76/cB8XdYKJQjgDfEnvsXjrcuHS/U3xUCt5xXK8Yf0vSR6BOd+vXMoZthoi01f/zAM 4FKoet/bWn+yk8Ca3WMuDkrbKRfQBVYJAWkGplViHiF9v+KPB3f1HJI4DsBwyDEbRGvy 2zVlv5R24UcfUI32/7gzgDjk4gfqLexnDXbsVShmL16/o6BE3NnqZsawT50n+a8dXc07 a2LFPtEAuHB2MY5RmlTByX27xOV6HOg5ZQIXNYlJti2GZZCs1EBge332PrbbLM3e1qYV ZduA== MIME-Version: 1.0 X-Received: by 10.43.71.75 with SMTP id yj11mr3924777icb.69.1430936664433; Wed, 06 May 2015 11:24:24 -0700 (PDT) Received: by 10.107.40.194 with HTTP; Wed, 6 May 2015 11:24:24 -0700 (PDT) In-Reply-To: <11092809.7nmbPfKl0V@ralph.baldwin.cx> References: <11092809.7nmbPfKl0V@ralph.baldwin.cx> Date: Wed, 6 May 2015 14:24:24 -0400 Message-ID: Subject: Re: PCI PF memory decode disable when sizing VF BARs From: Ryan Stone To: John Baldwin Cc: FreeBSD Current , Eric Badger , "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:24:26 -0000 On Wed, May 6, 2015 at 11:45 AM, John Baldwin wrote: > There are some devices with BARs in non-standard locations. :( If there is > a flag to just disable the VF bar decoding, then ideally we should just be > doing that and leaving the global decoding flag alone while sizing the VF > BAR. > Disabling SR-IOV BAR decoding in this function is currently redundant, as it's already done in pci_iov.c, but I guess to keep the interface sane it makes sense to do it here too. Something like this then? diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c index b4c6151..c9d7541 100644 --- a/sys/dev/pci/pci.c +++ b/sys/dev/pci/pci.c @@ -37,6 +37,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -62,6 +63,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -75,6 +77,11 @@ __FBSDID("$FreeBSD$"); (((cfg)->hdrtype == PCIM_HDRTYPE_NORMAL && reg == PCIR_BIOS) || \ ((cfg)->hdrtype == PCIM_HDRTYPE_BRIDGE && reg == PCIR_BIOS_1)) +#define PCIR_IS_IOV(cfg, reg) \ + (((cfg)->iov != NULL) && \ + ((reg) >= (cfg)->iov->iov_pos + PCIR_SRIOV_BAR(0)) && \ + ((reg) <= (cfg)->iov->iov_pos + PCIR_SRIOV_BAR(PCIR_MAX_BAR_0))) + static int pci_has_quirk(uint32_t devid, int quirk); static pci_addr_t pci_mapbase(uint64_t mapreg); static const char *pci_maptype(uint64_t mapreg); @@ -2647,7 +2654,8 @@ pci_read_bar(device_t dev, int reg, pci_addr_t *mapp, pci_addr_t *testvalp, struct pci_devinfo *dinfo; pci_addr_t map, testval; int ln2range; - uint16_t cmd; + uint32_t restore_reg; + uint16_t cmd, mask; /* * The device ROM BAR is special. It is always a 32-bit @@ -2677,9 +2685,21 @@ pci_read_bar(device_t dev, int reg, pci_addr_t *mapp, pci_addr_t *testvalp, * determining the BAR's length since we will be placing it in * a weird state. */ - cmd = pci_read_config(dev, PCIR_COMMAND, 2); - pci_write_config(dev, PCIR_COMMAND, - cmd & ~(PCI_BAR_MEM(map) ? PCIM_CMD_MEMEN : PCIM_CMD_PORTEN), 2); +#ifdef PCI_IOV + if (PCIR_IS_IOV(&dinfo->cfg, reg)) { + restore_reg = dinfo->cfg.iov->iov_pos + PCIR_SRIOV_CTL; + cmd = pci_read_config(dev, restore_reg, 2); + pci_write_config(dev, restore_reg, cmd & ~PCIM_SRIOV_VF_MSE, 2); + } else +#endif + { + cmd = pci_read_config(dev, PCIR_COMMAND, 2); + mask = PCI_BAR_MEM(map) ? PCIM_CMD_MEMEN : PCIM_CMD_PORTEN; + pci_write_config(dev, PCIR_COMMAND, cmd & ~mask, 2); + restore_reg = PCIR_COMMAND; + } /* * Determine the BAR's length by writing all 1's. The bottom @@ -2701,7 +2721,7 @@ pci_read_bar(device_t dev, int reg, pci_addr_t *mapp, pci_addr_t *testvalp, pci_write_config(dev, reg, map, 4); if (ln2range == 64) pci_write_config(dev, reg + 4, map >> 32, 4); - pci_write_config(dev, PCIR_COMMAND, cmd, 2); + pci_write_config(dev, restore_reg, cmd, 2); *mapp = map; *testvalp = testval; From owner-freebsd-current@FreeBSD.ORG Wed May 6 18:33:47 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B45E7CDC; Wed, 6 May 2015 18:33:47 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E4A11BED; Wed, 6 May 2015 18:33:47 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81014B93C; Wed, 6 May 2015 14:33:46 -0400 (EDT) From: John Baldwin To: Ryan Stone Cc: FreeBSD Current , Eric Badger , "current@freebsd.org" Subject: Re: PCI PF memory decode disable when sizing VF BARs Date: Wed, 06 May 2015 14:33:44 -0400 Message-ID: <2106775.8KnH0oLhUZ@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <11092809.7nmbPfKl0V@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 May 2015 14:33:46 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:33:47 -0000 On Wednesday, May 06, 2015 02:24:24 PM Ryan Stone wrote: > On Wed, May 6, 2015 at 11:45 AM, John Baldwin wrote: > > > There are some devices with BARs in non-standard locations. :( If there is > > a flag to just disable the VF bar decoding, then ideally we should just be > > doing that and leaving the global decoding flag alone while sizing the VF > > BAR. > > > > Disabling SR-IOV BAR decoding in this function is currently redundant, as > it's already done in pci_iov.c, but I guess to keep the interface sane it > makes sense to do it here too. Something like this then? Ah, sorry, I didn't know you did it in the caller already. Perhaps then something more like your previous patch, but using the test you added here (PCIR_IS_IOV) instead of your previous check against BAR values to decide when to frob the command register? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed May 6 18:58:40 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E252A326; Wed, 6 May 2015 18:58:40 +0000 (UTC) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Verizon Public SureServer CA G14-SHA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A9C41E3F; Wed, 6 May 2015 18:58:39 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="5.13,380,1427778000"; d="scan'208";a="269948827" Message-ID: <554A6457.4060702@compellent.com> Date: Wed, 6 May 2015 13:58:31 -0500 From: Eric Badger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , Ryan Stone CC: FreeBSD Current Subject: Re: PCI PF memory decode disable when sizing VF BARs References: <11092809.7nmbPfKl0V@ralph.baldwin.cx> <2106775.8KnH0oLhUZ@ralph.baldwin.cx> In-Reply-To: <2106775.8KnH0oLhUZ@ralph.baldwin.cx> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:58:41 -0000 On 05/06/15 13:33, John Baldwin wrote: > On Wednesday, May 06, 2015 02:24:24 PM Ryan Stone wrote: >> On Wed, May 6, 2015 at 11:45 AM, John Baldwin wrote: >> >>> There are some devices with BARs in non-standard locations. :( If there is >>> a flag to just disable the VF bar decoding, then ideally we should just be >>> doing that and leaving the global decoding flag alone while sizing the VF >>> BAR. >>> >> Disabling SR-IOV BAR decoding in this function is currently redundant, as >> it's already done in pci_iov.c, but I guess to keep the interface sane it >> makes sense to do it here too. Something like this then? > Ah, sorry, I didn't know you did it in the caller already. Perhaps > then something more like your previous patch, but using the test you > added here (PCIR_IS_IOV) instead of your previous check against BAR > values to decide when to frob the command register? > Does the disabling of VF MSE in pci_iov_config actually protect anything else beyond what happens in pci_read_bar? I gave a read through which suggests "no", but I might have missed something. Just thinking that the code would be a bit more hardy if it were done the same way for both VFs and other devices. Eric From owner-freebsd-current@FreeBSD.ORG Wed May 6 22:31:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F37CA970 for ; Wed, 6 May 2015 22:31:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E20741913 for ; Wed, 6 May 2015 22:31:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 64C748E4 for ; Wed, 6 May 2015 22:31:11 +0000 (UTC) Date: Wed, 6 May 2015 22:31:10 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <46316353.15.1430951470713.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #1010 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 22:31:11 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed May 6 23:12:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B97D22D5; Wed, 6 May 2015 23:12:17 +0000 (UTC) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Verizon Public SureServer CA G14-SHA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5486D1D83; Wed, 6 May 2015 23:12:17 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="5.13,381,1427778000"; d="scan'208,217";a="270085008" Message-ID: <554A9FBD.4010908@compellent.com> Date: Wed, 6 May 2015 18:11:57 -0500 From: Eric Badger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ryan Stone , FreeBSD Current , John Baldwin Subject: Re: PCI PF memory decode disable when sizing VF BARs References: <11092809.7nmbPfKl0V@ralph.baldwin.cx> <2106775.8KnH0oLhUZ@ralph.baldwin.cx> <554A6457.4060702@compellent.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 23:12:17 -0000 On 05/06/15 14:54, Ryan Stone wrote: > On Wed, May 6, 2015 at 2:33 PM, John Baldwin > wrote: > > Ah, sorry, I didn't know you did it in the caller already. Perhaps > then something more like your previous patch, but using the test you > added here (PCIR_IS_IOV) instead of your previous check against BAR > values to decide when to frob the command register? > > I think that I prefer the current version, as it keeps the interface > consistent. It's redundant now, but caller could evolve in the > future. Given that this is just being run during initialization a > couple of extra register accesses are irrelevant anyway. > > On Wed, May 6, 2015 at 2:58 PM, Eric Badger > > wrote: > > Does the disabling of VF MSE in pci_iov_config actually protect > anything else beyond what happens in pci_read_bar? I gave a read > through which suggests "no", but I might have missed something. > Just thinking that the code would be a bit more hardy if it were > done the same way for both VFs and other devices. > > Eric > > > I think that it inherently has to be done differently. For real PCI > devices the device might be important during the boot process (e.g. > the video card) so we need to stay working. For VFs the devices don't > even exist until I enable the VF Enable bit is set, so setting MSE > before that point is irrelevant (it's allowed by the spec, but any > access to a VF memory space with MSE set and VF Enable clear just gets > an Unsupported Request response). Sure; what I meant was to leave the disabling of VF MSE when sizing VF BARs in pci_read_bar (as in your second patch) for consistency and, if possible, not bother disabling VF MSE in pci_iov_config. But if it's not worth nixing the latter (or not possible), it's no big deal. I've been testing out the second patch in my environment and it looks good. I might suggest something like the below (which I find more readable) as a cosmetic change: @@ -2627,9 +2635,18 @@ pci_read_bar(device_t dev, int reg, pci_addr_t *mapp, pci_addr_t *testvalp, * determining the BAR's length since we will be placing it in * a weird state. */ - cmd = pci_read_config(dev, PCIR_COMMAND, 2); - pci_write_config(dev, PCIR_COMMAND, - cmd & ~(PCI_BAR_MEM(map) ? PCIM_CMD_MEMEN : PCIM_CMD_PORTEN), 2); +#ifdef PCI_IOV + if (PCIR_IS_IOV(&dinfo->cfg, reg)) { + restore_reg = dinfo->cfg.iov->iov_pos + PCIR_SRIOV_CTL; + mask = PCIM_SRIOV_VF_MSE; + } else +#endif + { + restore_reg = PCIR_COMMAND; + mask = PCI_BAR_MEM(map) ? PCIM_CMD_MEMEN : PCIM_CMD_PORTEN; + } + cmd = pci_read_config(dev, restore_reg, 2); + pci_write_config(dev, restore_reg, cmd & ~mask, 2); Thanks, Eric From owner-freebsd-current@FreeBSD.ORG Thu May 7 01:10:06 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72F56FE6; Thu, 7 May 2015 01:10:06 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2CC911A06; Thu, 7 May 2015 01:10:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AMBAAYukpV/95baINcg2BeAQWDGMJNCYFWhgWBXxQBAQEBAQEBgQqESgRSNQINGQJfiD8NsTCTOAEBAQEBBQEBAQEBARyBIY5pNIJvgUUFljyCRoUiPYpzIoIEhz8jgggcgW4iMQEBAQGBQIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,382,1427774400"; d="scan'208";a="209322897" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 06 May 2015 21:10:04 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A80D5B42A2; Wed, 6 May 2015 21:10:04 -0400 (EDT) Date: Wed, 6 May 2015 21:10:04 -0400 (EDT) From: Rick Macklem To: freebsd current Cc: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , David.Boyd49@twc.com Message-ID: <1588878108.33116674.1430961004678.JavaMail.root@uoguelph.ca> Subject: nmount, mountd drops high order MNT_xx flags during a mount update MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 01:10:06 -0000 David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED flag getting cleared by mountd. http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel I just took a look at this and it's kinda ugly... mountd acquires a list of mounts via getmntinfo() and then does an nmount() for each of them to get rid of any exports. It uses f_flags from the statfs returned by getmntinfo() as the 3rd argument to nmount(). --> Since nmount()s 3rd argument is a "int", it silently drops any MNT_xx flag in the high order 32bits of f_flags. At this time, it happens that MNT_AUTOMOUNTED is the only one, but... I can think of a couple of ways to fix this, but I don't like any of them;-) 1) I suppose mountd could check for each flag set in f_flags and generate a vfsopts string for it, but that means that every time a new flag that can be updated is added to MNT_xx, this mountd.c code would have to updated. --> Ugly!! 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. I wouldn`t mind this except in means that the MNT_xx flags must be redefined and I don`t think that could get MFC`d. 3) Add a new newernmount(2) which has a 64bit flags argument instead of int. Hopefully someone can think of a nice way to fix this, rick From owner-freebsd-current@FreeBSD.ORG Thu May 7 06:03:37 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1786EA7 for ; Thu, 7 May 2015 06:03:37 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ADE6D1A44 for ; Thu, 7 May 2015 06:03:37 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id ADFD69A5 for ; Thu, 7 May 2015 06:03:37 +0000 (UTC) Date: Thu, 7 May 2015 06:03:37 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <96774674.17.1430978617645.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <46316353.15.1430951470713.JavaMail.jenkins@jenkins-9.freebsd.org> References: <46316353.15.1430951470713.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1011 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:03:37 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu May 7 06:47:34 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7D098CC for ; Thu, 7 May 2015 06:47:34 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B86D51F1C for ; Thu, 7 May 2015 06:47:34 +0000 (UTC) Received: by igbhj9 with SMTP id hj9so37446207igb.1 for ; Wed, 06 May 2015 23:47:28 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=xnG5Cu78zkSb1L9zDztf0Q0vGvmgPAuPQveRhhJOQho=; b=JPcTEUgwOu7nMsck/Zc3vfjAXXHPQl1zkohI78kIGcjfdn0/93995jy5WsSwEulM5w FeWhRo86LgdB2unlnMUV4gF4M4d/MuLpT7wE3Ui84feUe/GxS+IuoaBVbjjGO+brXijG kS6nY9RcJiiNsg7GfkDmx2BQdGzTfDzv19W9pcrCw+rTSZckNWpDGhGPfDGyN+Zk37+d 6vNAaDByLV71uwfA7i8fDR2o/KDl/qJtQULFjR5O4ZWduG86+fFgqV+0LcWMGW6AKr/7 xxBDsltY4k55e8nuBQ/yPmwtyGwPUeQD0hNhp4BCbPGIS2gQu7vTDVXE2YUIFI0saZxd GdZA== X-Gm-Message-State: ALoCoQmMI1PVzjnrc0klfzbOvJ9fOwW2hm+LKQsAx0TzMSKR0utZEwTle0Wmu8HfJffv6ifl3wGL MIME-Version: 1.0 X-Received: by 10.107.136.158 with SMTP id s30mr2960237ioi.65.1430981247882; Wed, 06 May 2015 23:47:27 -0700 (PDT) Received: by 10.36.153.1 with HTTP; Wed, 6 May 2015 23:47:27 -0700 (PDT) In-Reply-To: <1588878108.33116674.1430961004678.JavaMail.root@uoguelph.ca> References: <1588878108.33116674.1430961004678.JavaMail.root@uoguelph.ca> Date: Thu, 7 May 2015 07:47:27 +0100 Message-ID: Subject: Re: nmount, mountd drops high order MNT_xx flags during a mount update From: Doug Rabson To: Rick Macklem Cc: freebsd current , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= , David.Boyd49@twc.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:47:35 -0000 You could add a single integer-valued vfsopt which holds the high-order bits of f_flags? On 7 May 2015 at 02:10, Rick Macklem wrote: > David Boyd reported a problem to freebsd-current@ w.r.t. the > MNT_AUTOMOUNTED > flag getting cleared by mountd. > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > I just took a look at this and it's kinda ugly... > > mountd acquires a list of mounts via getmntinfo() and then does an > nmount() for each of them to get rid of any exports. It uses > f_flags from the statfs returned by getmntinfo() as the 3rd > argument to nmount(). > --> Since nmount()s 3rd argument is a "int", it silently drops any > MNT_xx flag in the high order 32bits of f_flags. At this time, > it happens that MNT_AUTOMOUNTED is the only one, but... > > I can think of a couple of ways to fix this, but I don't like any of > them;-) > > 1) I suppose mountd could check for each flag set in f_flags and generate > a vfsopts string for it, but that means that every time a new flag that > can be updated is added to MNT_xx, this mountd.c code would have to > updated. > --> Ugly!! > > 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. > I wouldn`t mind this except in means that the MNT_xx flags must be > redefined > and I don`t think that could get MFC`d. > > 3) Add a new newernmount(2) which has a 64bit flags argument instead of > int. > > Hopefully someone can think of a nice way to fix this, rick > _______________________________________________ > 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 Thu May 7 12:39:03 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B53730A; Thu, 7 May 2015 12:39:03 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E42E91F7D; Thu, 7 May 2015 12:39:02 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 542731FE023; Thu, 7 May 2015 14:39:00 +0200 (CEST) Message-ID: <554B5D11.3080709@selasky.org> Date: Thu, 07 May 2015 14:39:45 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Current , Aleksandr Rybalko Subject: Race VT+X11 on -current Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 12:39:03 -0000 Hi, Sometimes when logging into X11 the keyboard input is not working. Pressing ALT+F9 makes it work. Any idea where the race is? --HPS From owner-freebsd-current@FreeBSD.ORG Thu May 7 16:43:34 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F73347C; Thu, 7 May 2015 16:43:34 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0ED8D1E1E; Thu, 7 May 2015 16:43:34 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so164736772igb.0; Thu, 07 May 2015 09:43:33 -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=XkaC3D+PLhBI9Ea8iS490CoP+Wp2NQdcUfUYizOoi64=; b=s0fMePZk36vDJpqsvk0vggHl5hGowq3jTbb4Su/TbZVr3CjxSNKgk/p+k/n31izMKq NP7m5gd25K4KTRoEYA/vJJ+7q3NIM8BVW0H6AudkIo7+/s5OJNaqUPCTRG1pO20Y+E5x 1bD0pLGqKcWE+D8kPkLNn0uvdy6Qg8tzalOMXqYkIu/DVXSmUnr9QY2Uy+6jgYiWJmaw hvPoBSqU7XXaPGpVtQ4Ufw8FLK6vf2ETNWZDdqKCE8ePwgz+GPRvzj6E2kKvts0m/YWd ZZYFcnEkDOXJwsyGlyoLPyX1uii3q868JWdlmhkVV4yBitbRcnyRRPaqWUogVYPKhE3K 8R4w== MIME-Version: 1.0 X-Received: by 10.107.25.131 with SMTP id 125mr6181241ioz.44.1431017013258; Thu, 07 May 2015 09:43:33 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.22 with HTTP; Thu, 7 May 2015 09:43:33 -0700 (PDT) In-Reply-To: <554B5D11.3080709@selasky.org> References: <554B5D11.3080709@selasky.org> Date: Thu, 7 May 2015 09:43:33 -0700 X-Google-Sender-Auth: 36gVn45Dnt_ZlLWJrL_zUO_qlVA Message-ID: Subject: Re: Race VT+X11 on -current From: Kevin Oberman To: Hans Petter Selasky Cc: FreeBSD Current , Aleksandr Rybalko Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:43:34 -0000 On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky wrote: > Hi, > > Sometimes when logging into X11 the keyboard input is not working. > Pressing ALT+F9 makes it work. Any idea where the race is? > > --HPS > Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) and back to vty1 does the job. I must admit that this is a pretty minor annoyance, so I never got around to reporting it. Still, any bug report should show that it impacts multiple users. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu May 7 18:23:12 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C27297C; Thu, 7 May 2015 18:23:12 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EBAA1B76; Thu, 7 May 2015 18:23:12 +0000 (UTC) Received: by obfe9 with SMTP id e9so38073486obf.1; Thu, 07 May 2015 11:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7gpfxxqVem4a3H+0wvwmYfmrIfKfRlA7G5kQ6GMSRxE=; b=WyQ+vaGfyG3JaK8KzGn+W3GZQSOt/64Thl2pzfcR1WIsL62HWSzgdf+JsWBqEV760L eo/D8DwtaZ/bLuH4r8glHe1fHBLEqnA2C2lCYNDY/5u7k/gh4xeVVATMRffuMoZQQ4b5 Wkwz+MmSGFqmtifAOCGgsg6d8i/CKwVCFa2BoCpyEpiA5jNm4IcfvG3uYmB4g/Q+aCQa UQ4Jud/w0mrbczmx/55PNK8siekgaMm7T0ofUU7xJ7Fvfo7R+vFJ6/pTRxgq9YqFQFv3 jwQSFXV4r4Ik3YUXogmMRsTu4CVOM6HOeEe1mp9r/VY3RQSM0JBjyZpmL/LxZrm+bBde W0PQ== X-Received: by 10.60.45.201 with SMTP id p9mr4375296oem.82.1431022991688; Thu, 07 May 2015 11:23:11 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id oi5sm1554645obc.21.2015.05.07.11.23.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 May 2015 11:23:10 -0700 (PDT) References: <554B5D11.3080709@selasky.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Hans Petter Selasky , FreeBSD Current , Aleksandr Rybalko X-Mailer: iPhone Mail (12F70) From: Garrett Cooper Subject: Re: Race VT+X11 on -current Date: Thu, 7 May 2015 11:23:08 -0700 To: Kevin Oberman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 18:23:12 -0000 > On May 7, 2015, at 09:43, Kevin Oberman wrote: >=20 >> On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky wro= te: >>=20 >> Hi, >>=20 >> Sometimes when logging into X11 the keyboard input is not working. >> Pressing ALT+F9 makes it work. Any idea where the race is? >>=20 >> --HPS >=20 > Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) > and back to vty1 does the job. >=20 > I must admit that this is a pretty minor annoyance, so I never got around > to reporting it. Still, any bug report should show that it impacts multipl= e > users. Speaking of which, please file a bug for this issue so it doesn't get lost! Thanks, -NGie= From owner-freebsd-current@FreeBSD.ORG Thu May 7 19:09:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6E34B81 for ; Thu, 7 May 2015 19:09:03 +0000 (UTC) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A06F109D for ; Thu, 7 May 2015 19:09:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431025736; bh=zG/pA35rEAvKMXgODuNhwzGybRqGsx2WToalZ4O5t7Q=; h=Date:From:To:Subject:From:Subject; b=XEdE99BcJFkmzKwWC8Z5gDPGYUBm0C628V2p5FXloux0AsyLkrm8pxX3aVbup++b95AJTw3GABmukNHMcISHPvTaXyDhipSw14WicEkYNrAKhRG+uwuZvpAXYWnNnbhw5oi4bDNQbvOoICAD+pOk49V9sj65+qMttnze5ByU7zNdfjUIDZ2/xIzxbINv0HfbPBiEZ/y5HyB/Jq7k8hMUoVTFuHlLmJatyJMkW1jLS1rIpmRgoGQU8piSl5TZvpDD9NsEA/C1kj5LgZu2llCjiLtXTkZCRHDt3JypKyK9WA/Nhb78n+jB40dcWlOmU2X3r5MmivS3Rc4CjnDj9Sp42g== Received: from [98.139.215.142] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 19:08:56 -0000 Received: from [98.139.211.207] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 19:08:56 -0000 Received: from [127.0.0.1] by smtp216.mail.bf1.yahoo.com with NNFMP; 07 May 2015 19:08:56 -0000 X-Yahoo-Newman-Id: 546405.67679.bm@smtp216.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dxfEd_MVM1kS2IBla8CRALBJHzM_MHeVUd1Jy4UoiL7Akdr bbayDkou_TqjYOmhzfiZ4kD8pi3VRBXiZUm6ji6TEirv9FGBGAsOjtIYtHcF kmnVOhwxJ47FZWRDCoF9veaYKxJN8idK4X_DGf9PjQX1.SeoPW.MG42KbdSH 3VjAyvGhSxq8WrjH8ttvORB3fE8efGSQo.bL9Qf9fTC2Fg93WbeOfwFo2_95 3vppgoG3Rv.lp.64ErIMP.U8agUnipU.23SDDRBZgiZt8UI9FtITqI8YljXR kNAQnvFyeHd8AQIHJxFuHsHS2b6DqxnlWowNEmL3y.34EQ4hiPnrHFmZnMXA mgoSj7T6OaMPIVGtKYO_AWDq1eAKMBaDPPDSPykN_fPIr2OWckVoi1XjyOck G4Z4OR1LAWlJIIx0nwjlORkrtHPZ5FVv6JhG.3S5fGVgpm37A35wlTWfPzDD U03upK3YMAyd.h1xW27DYjTsTJRDCQpqC6DN0B21oDrTyFT.SzzO_HroqaZs 282dLBX9W.R2u1IxG1qeuTzvFCDEzgTfJ X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <554BB84F.7060605@FreeBSD.org> Date: Thu, 07 May 2015 14:09:03 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: FreeBSD Current list Subject: What to do about RCS/OpenRCS Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:09:03 -0000 Hello; Some of you might recall that right before 10.0-Release there was a painful attempt to remove GNU RCS from the base system. From my point of view, the lessons learned from that were: -A lot more people than you might think find it useful to have a small version control system for thing like the files in /etc. -Just removing features without a discussion is not wise. -IMHO, people wondering about the bloat in the OS should focus on other bigger VCS we carry, namely svn. For all I know, it looks like OpenRCS is the most viable option and can completely replace the old RCS we have in base. In order to avoid painful surprises late in the release cycle, I started the process to consider OpenRCS by bringing it to the vendor area (OpenBSD/usr.bin/rcs/*). I also have an initial patch[1] so that it builds on FreeBSD. Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. All in all, it looks like whatever is done about RCS it may be controversial so I am opening the discussion in the hope that someone else will take the lead and do something about it much ahead of 11-Release. Regards, Pedro. [1] Follow the link in: https://wiki.freebsd.org/GPLinBase From owner-freebsd-current@FreeBSD.ORG Thu May 7 19:56:59 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18747C33; Thu, 7 May 2015 19:56:59 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ftp.orthanc.ca", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D9B44169B; Thu, 7 May 2015 19:56:58 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.14.9/8.14.9) with ESMTP id t47Jutow053881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 May 2015 12:56:55 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Thu, 7 May 2015 12:56:55 -0700 (PDT) From: Lyndon Nerenberg To: Pedro Giffuni cc: FreeBSD Current list Subject: Re: What to do about RCS/OpenRCS In-Reply-To: <554BB84F.7060605@FreeBSD.org> Message-ID: References: <554BB84F.7060605@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,MISSING_MID, NO_RECEIVED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on orthanc.ca X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:56:59 -0000 On Thu, 7 May 2015, Pedro Giffuni wrote: > Unfortunately I don't use RCS enough (it looks like I should though) so > I am not in a good position to take the next step and deal with any > fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. From owner-freebsd-current@FreeBSD.ORG Thu May 7 20:00:11 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D44AF13; Thu, 7 May 2015 20:00:11 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40CB616D0; Thu, 7 May 2015 20:00:11 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 081451FE023; Thu, 7 May 2015 22:00:08 +0200 (CEST) Message-ID: <554BC475.50203@selasky.org> Date: Thu, 07 May 2015 22:00:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper , Kevin Oberman CC: FreeBSD Current , Aleksandr Rybalko Subject: Re: Race VT+X11 on -current References: <554B5D11.3080709@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:00:11 -0000 On 05/07/15 20:23, Garrett Cooper wrote: > >> On May 7, 2015, at 09:43, Kevin Oberman wrote: >> >>> On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky wrote: >>> >>> Hi, >>> >>> Sometimes when logging into X11 the keyboard input is not working. >>> Pressing ALT+F9 makes it work. Any idea where the race is? >>> >>> --HPS >> >> Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) >> and back to vty1 does the job. >> >> I must admit that this is a pretty minor annoyance, so I never got around >> to reporting it. Still, any bug report should show that it impacts multiple >> users. > > Speaking of which, please file a bug for this issue so it doesn't get lost! > Thanks, > -NGie Hi, Here it is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200032 --HPS From owner-freebsd-current@FreeBSD.ORG Thu May 7 20:20:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8C1A8DF; Thu, 7 May 2015 20:20:16 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B824F18F1; Thu, 7 May 2015 20:20:16 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 90C422348; Thu, 7 May 2015 13:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1431030015; x=1431044415; bh=Olm2guRl1gsUlJrBfb0wfukirnsNx1xpCrYZKykCUww=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=tX5Dir4+02yzHzaF5wRUbfzdUxxIbqUBWgxCMcq59pIvZGwQq5fdJhsEMC0kxFcoM GqbXuKNGoVcw8ZPZzbqQ6nTzg0zu0qqvpinkpUTUgYbLay4NlOrEoKMdHCv10YaXtJ 9TnZjwIj/hLtKWxZW0RciBNMqgz0XvGIrjr0ujvU= Message-ID: <554BC8FF.6080409@delphij.net> Date: Thu, 07 May 2015 13:20:15 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Pedro Giffuni , FreeBSD Current list Subject: Re: What to do about RCS/OpenRCS References: <554BB84F.7060605@FreeBSD.org> In-Reply-To: <554BB84F.7060605@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:20:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/15 12:09, Pedro Giffuni wrote: > Hello; > > Some of you might recall that right before 10.0-Release there was a > painful attempt to remove GNU RCS from the base system. > > From my point of view, the lessons learned from that were: > > -A lot more people than you might think find it useful to have a > small version control system for thing like the files in /etc. > -Just removing features without a discussion is not wise. -IMHO, > people wondering about the bloat in the OS should focus on other > bigger VCS we carry, namely svn. > > For all I know, it looks like OpenRCS is the most viable option and > can completely replace the old RCS we have in base. I have objected this in 2013 because OpenRCS did not pass GNU RCS's test suite: https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045185. html More specifically: + : -Dhas_conf_h + : cc + : diff + CL='cc -Dhas_conf_h -o a.out' + L='' + RCSINIT=-x + export RCSINIT + SLASH=/ + RCSfile=RCS/a.c + RCS_alt=RCS/a.d + lockfile=RCS/a._ + q=-q + test -d RCS + rmdir=rmdir + mkdir RCS + rm -f 'a.*' RCS/a.c RCS/a.d RCS/a._ + echo 1.1 + echo 1.1.1.1 + echo 1.2 + diff -c a.11 a.3x1 + diff='diff -c' + rcs -i -L -ta.11 -q a.c + test -r RCS/a.c + rlog a.c + rm -f RCS/a.c + cp a.11 a.c + ci -ta.11 -mm -q a.c + test -r RCS/a.c + rcs -L -q a.c + test ! -f a.c + co -q a.c + test -f a.c + diff -c a.11 a.c + co -l -q a.c + test -f a.c + diff -c a.11 a.c + cp a.12 a.c + ci -mm -q a.c + co -q a.c + diff -c a.12 a.c + rm -f a.c + co -r1.1 -q a.c + diff -c a.11 a.c + rm -f a.c + cp a.3x1 a.c + ci -r1.1.1 -mm -q a.c ci: RCS/a.c: no lock set by delphij + echo '#branches failed' #branches failed + exit 1 The checkout as of today ported to FreeBSD still does not pass the test cases, so I still object the replacement unless the issues have been taken care of. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVS8j7AAoJEJW2GBstM+nsUR4P/1X9hvotuBLzjgY1S6389HJP 3FXoT0+xjJqW0L6Ke5wGJy01Q3awJBGG6OUgSYufZhg32uIwPbLmKKouUuscPj/p 77e+EdonjkNcKIDYurtL8ifLm6bhPUvuWX4JSPcy8SBZtehqXUF0s4WdLqISGXpM t8iJ56AoGAffQAHEAeHzJDxf41+7Jdb8aw314aFyAAcrcH2Q3giuo6QH75psGoSy 0X3BLu7Wi0eADcTgvLps6eJ6Uwwt+FbCKFySqkNeiXy9+LRnNg8lGUyzHp1gwSJW 5KQ9l+8vFabnAkwVZWkwnZ0mFZRRu24Ui97nwfLOrv0fDYflZIcmfEQQUHTZNp5Z zsZEulU9MZDA10LgNvIAr4rsDDa41HOY3KA89rGuWXQpxZUOwzibWNnNfHOJIW9c b4rGJ+femjr5wllvjG3vURGS6mkPvtLt7e/nO4pAZ+ev06KBLQAp+qd3RCjFPMRw +cFpFXwSN+O2e6aQbYLduk18UAJFLkZf/1tH1AaO4pnjxyM3liZeE5oeIVoqUVMu 2iNNyb15Vk7dJL2DIam1MSX4UA+mCLgsJ6m+SIbigB6zYusUm2vPbDkx+e82fnhu QlXml8k+ZQjZm6nZl45l2yaRmhRyIVq2b4GgiC6zG/WUfn4mSju83gI2hEfuGqhj VgaTuJMDK6pjCpTKfA/B =di1X -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu May 7 20:38:37 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4A871E1 for ; Thu, 7 May 2015 20:38:37 +0000 (UTC) Received: from nm41-vm4.bullet.mail.bf1.yahoo.com (nm41-vm4.bullet.mail.bf1.yahoo.com [216.109.114.159]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 541731AED for ; Thu, 7 May 2015 20:38:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431031110; bh=if2RjSZtGvef9ISA+LSPfet9mGSpsmUzanoF5YKSOHc=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=Fa6C/AV0/gfQDH516ICCmyZ6xyF5cpQddWukEuZ7YUudU10Nc1iaLu+nUztFNS39Vl5kvHqWl1P/qBkxki1i0fFnzeTZABpAX7gffBsoqj1f6nHfYMN1hyVugYQ+8K3vwkynBgtpVRAfLJspVrVPP4iLX1WmDme4flh39o/BJKB0uC1OTwbdk/DtCW/X4xQ//N0YNHCeqnn1QvFdC/TZTJXfu/YsYiJ6XSamF5/ZWV8pOdSx5hSfZq5SKsbouZ8i7Hs03mHfaAvFqNd0ZwmVkhNSVr35/vigB2GZMpdkVoOWyrt8McaGAFPMUd4I8rh/1SP0DJEFIrHk8Be/YeaYEw== Received: from [66.196.81.171] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 20:38:30 -0000 Received: from [98.139.213.14] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2015 20:38:30 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 07 May 2015 20:38:30 -0000 X-Yahoo-Newman-Id: 39385.14619.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QsfQ1_8VM1lKoyaCCJYmiUyehSH7KCy4hzjKlaPb24wuoQy rQzd6SyUX67zCuoyEAC7gyU8DvW6756gRdrUAB5uwD_.SiMo1xGL1n5LJsxG ga69bofztB7IrMIOdPuqlRuW5gLA9Qf.mjXLvz8sXUvtZDUsXXvb3aIUusP5 GDElICQ5pLVsIpYNrdTafwF44e.qxIT3qcmxj4ay5GXbsEKhS74m1H722..P MBOwN7pxXfm_0gDWW_jZMAtznFykc3IpTPKDws6aLeAZk0EF_3fm5bwayR4G uy05KTXfPomv9mz0_e_gn97J2MAFYlMJGzKBY8dKbZ4ZR0vnwPmmnZKklUO6 zSADVpVfowkmH0bVDj7eUiDzKRbocBZ_pSCBPN45VRxkko7XlXy4Z7qz2TX2 fIa7pp4Kcc0h9n6IOB5TzMkSc0_1yMS0SIZJCikv4Fl.o01Xe6kpvy5pOB_O CuUf..AoP1g016y1uEiN9vIKr85_iqG0T2pidB9VfCopweJTfQssDGiNqcPR CL_9TAvztH4uW5TrFwWm1kehkLj2LIc5R X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <554BCD4C.8090500@FreeBSD.org> Date: Thu, 07 May 2015 15:38:36 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Lyndon Nerenberg CC: FreeBSD Current list Subject: Re: What to do about RCS/OpenRCS References: <554BB84F.7060605@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:38:37 -0000 Hello; On 05/07/15 14:56, Lyndon Nerenberg wrote: > On Thu, 7 May 2015, Pedro Giffuni wrote: > >> Unfortunately I don't use RCS enough (it looks like I should though) so >> I am not in a good position to take the next step and deal with any >> fallout it may produce. > > If we can have a build-knob to disable GNU RCS and enable the new one > I will happily twist up the new version and hammer on it. > Yes, that's usually the next step in the process. It is a little bit messy because there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and perhaps something else that we don't use). I really want to check out first if there is some strong opinion against OpenRCS. Perhaps someone that has used it before and thinks it is a bad idea. It looks like there are voices against it, so those have to be addressed first. Pedro. From owner-freebsd-current@FreeBSD.ORG Thu May 7 21:00:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97492474; Thu, 7 May 2015 21:00:47 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 580431D56; Thu, 7 May 2015 21:00:47 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4B5AA1FE023; Thu, 7 May 2015 23:00:44 +0200 (CEST) Message-ID: <554BD2A8.70702@selasky.org> Date: Thu, 07 May 2015 23:01:28 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper , Kevin Oberman CC: FreeBSD Current , Aleksandr Rybalko Subject: Re: Race VT+X11 on -current References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> In-Reply-To: <554BC475.50203@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:00:47 -0000 On 05/07/15 22:00, Hans Petter Selasky wrote: > On 05/07/15 20:23, Garrett Cooper wrote: >> >>> On May 7, 2015, at 09:43, Kevin Oberman wrote: >>> >>>> On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky >>>> wrote: >>>> >>>> Hi, >>>> >>>> Sometimes when logging into X11 the keyboard input is not working. >>>> Pressing ALT+F9 makes it work. Any idea where the race is? >>>> >>>> --HPS >>> >>> Actually, I have found that switching to ANY other terminal (e.g. >>> ALT-F2) >>> and back to vty1 does the job. >>> >>> I must admit that this is a pretty minor annoyance, so I never got >>> around >>> to reporting it. Still, any bug report should show that it impacts >>> multiple >>> users. >> >> Speaking of which, please file a bug for this issue so it doesn't get >> lost! >> Thanks, >> -NGie > > Hi, > > Here it is: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200032 > > --HPS Hi, It might look like you can reproduce like this: 1) Boot computer into GDM / slim. 2) Wait more than 15 seconds. 3) Keyboard appears frozen. 4) Press ALT+F9 5) Keyboard works again. If waiting less than 15 seconds everything is fine. Might be related to "vw_proc_dead_timer" in VT. I'll debug more tomorrow. Seems trivial. --HPS From owner-freebsd-current@FreeBSD.ORG Thu May 7 21:07:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35D575CE for ; Thu, 7 May 2015 21:07:43 +0000 (UTC) Received: from mail03.SiriusCloud.jp (mail03.SiriusCloud.jp [219.118.72.3]) by mx1.freebsd.org (Postfix) with ESMTP id 070BA1E39 for ; Thu, 7 May 2015 21:07:42 +0000 (UTC) Received: from artemis (pl2497.nas82m.p-tokyo.nttpc.ne.jp [157.65.58.193]) (Authenticated sender: jack@st.rim.or.jp) by access03.SiriusCloud.jp (Postfix) with ESMTPA id DEC473000243D for ; Fri, 8 May 2015 06:02:02 +0900 (JST) Authentication-Results: access03.SiriusCloud.jp; dkim=none (no signature) header.i=unknown; x-dkim-adsp=none (insecure policy) Message-ID: <8A0CADA1C80C4310BFFA1828554F473C@ad.peach.ne.jp> From: "Daisuke Aoyama" To: Subject: hastd fail and panic on MAXPHYS=1m Date: Fri, 8 May 2015 06:02:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: clamav-milter 0.97.8 at si-mail03 X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:07:43 -0000 Hi all, I have problem with MAXPHYS=1m. (I don't know MAXPHYS=1m works on HAST.) I put "options MAXPHYS=(1024*1024)" in kernel config. Then, update primary node to the kernel and world. If the role back to primary on the machine, writing to the hast device cause an error and panic. I didn't check carefully, but it seems that geom_gate.ko use MAXPHYS=1m and hastd use MAXPHYS=128k. Of course, secondary is MAXPHYS=128k at this time. Is it an expected result? Here is a log while manually mounted test: [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b240) Request received from the kernel: READ(163840, 28672). [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b240) Moving request to the send queues. [DEBUG][2] [hast1] (primary) ggate_recv: Taking free request. [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b1f0) Gotg_vfs_done():hast/hast1p1[WRITE(offset=174784512, length=393216)]error = 6 /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem free request. [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b1f0) Waiting for request from the kernel. [DEBUG][2] [hast1] (primary) local_send: (0x20c4b240) Got request. [DEBUG][2] [hast1] (primary) local_send: (0x20c4b240) Moving request to the done queue. [DEBUG][2] [hast1] (primary) [DEBUG][2] [hast1] (primary) ggate_send: (0x20c4b240) Got request. local_send: Taking request. [DEBUG][2] [hast1] (primary) ggate_send: (0x20c4b240) Moving request to the free queue. [DEBUG][2] [hast1] (primary) ggate_send: Taking request. [ERROR] [hast1] (primary) G_GATE_CMD_START failed: Cannot allocate memory. [DEBUG][1] Unable to receive event header: Socket is not connected. softdep_deallocate_dependencies: got error 6 while accessing filesystem /dev: got error 6 while accessing filesystem panic: brelvp: Buffer 0xb33129d0 not on queue. cpuid = 3 KDB: enter: panic -- Daisuke Aoyama From owner-freebsd-current@FreeBSD.ORG Thu May 7 22:22:13 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 962DCB93; Thu, 7 May 2015 22:22:13 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE5A166A; Thu, 7 May 2015 22:22:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwA35EtV/95baINcg2JeBoMYwlEJgU0KhTdOAoF0FAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCwUWDgoCAg0ZAikBCSYGCAcEARoCBIgDCA2zV5NRAQEBAQEBBAEBAQEBAQEbgSGKGYQzAQEcNAeCaIFFBZZKgkaBTYNVPYp8IoIFh0MjgggcgW4iMQEBAQEDgQU5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,386,1427774400"; d="scan'208";a="211341683" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 07 May 2015 18:22:11 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7821DB3F13; Thu, 7 May 2015 18:22:11 -0400 (EDT) Date: Thu, 7 May 2015 18:22:11 -0400 (EDT) From: Rick Macklem To: Doug Rabson Cc: freebsd current , Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , David Boyd49 Message-ID: <1368896693.33831868.1431037331485.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: nmount, mountd drops high order MNT_xx flags during a mount update MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:22:13 -0000 Doug Rabson wrote: > You could add a single integer-valued vfsopt which holds the > high-order > bits of f_flags? > Yes, that sounds better than any of my ideas. I'll code up a patch and put it up for review unless someone has a better solution. Thanks Doug, rick > On 7 May 2015 at 02:10, Rick Macklem wrote: > > > David Boyd reported a problem to freebsd-current@ w.r.t. the > > MNT_AUTOMOUNTED > > flag getting cleared by mountd. > > http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel > > I just took a look at this and it's kinda ugly... > > > > mountd acquires a list of mounts via getmntinfo() and then does an > > nmount() for each of them to get rid of any exports. It uses > > f_flags from the statfs returned by getmntinfo() as the 3rd > > argument to nmount(). > > --> Since nmount()s 3rd argument is a "int", it silently drops any > > MNT_xx flag in the high order 32bits of f_flags. At this time, > > it happens that MNT_AUTOMOUNTED is the only one, but... > > > > I can think of a couple of ways to fix this, but I don't like any > > of > > them;-) > > > > 1) I suppose mountd could check for each flag set in f_flags and > > generate > > a vfsopts string for it, but that means that every time a new flag > > that > > can be updated is added to MNT_xx, this mountd.c code would have to > > updated. > > --> Ugly!! > > > > 2) Require that all flags in MNT_UPDATEMASK be in the low order > > 32bits. > > I wouldn`t mind this except in means that the MNT_xx flags must > > be > > redefined > > and I don`t think that could get MFC`d. > > > > 3) Add a new newernmount(2) which has a 64bit flags argument > > instead of > > int. > > > > Hopefully someone can think of a nice way to fix this, rick > > _______________________________________________ > > 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" > > > _______________________________________________ > 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 Thu May 7 23:18:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ADC3754; Thu, 7 May 2015 23:18:39 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA37A1C22; Thu, 7 May 2015 23:18:38 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so7355604igb.0; Thu, 07 May 2015 16:18:38 -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=nTO0fDTwqLkrm3shc+TIoVFyMZuBEqMId7W7zzrDiP0=; b=VtH3hO2Ht+PzIeiGxYxEOnIv/d9sOESFPEDmih4+owiGWv+F9M7XIKFUuJJDEjc/Pw 6lra95ckL8Oos/RBev4CcDDp528O9N8vZnTb9xSfo2tNSJnAz+1TwsWuKIBPoK7qZfVg 6VT8qoXS3B43ATy9B9IDVHdgxNsOsMshi0ZZmTZZNjRu0HhlukrpNIUSCD1dp3r2kXI3 oZ3+nso4J9D1Ptuy/mnQmKY4HyQpFxawlihPW1gtBLgJ0A9+jB7/Ovn99dbxtjzoRHxD 4xcQRnetmYbZ9o1An//IN9BQfsryybiLYGpVrzFOnEChyyWCyuYwNsGTLW6TfCH1oG/I NzYQ== MIME-Version: 1.0 X-Received: by 10.50.114.35 with SMTP id jd3mr819056igb.14.1431040718180; Thu, 07 May 2015 16:18:38 -0700 (PDT) Received: by 10.107.131.20 with HTTP; Thu, 7 May 2015 16:18:38 -0700 (PDT) In-Reply-To: <554BCD4C.8090500@FreeBSD.org> References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> Date: Thu, 7 May 2015 16:18:38 -0700 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: NGie Cooper To: Pedro Giffuni Cc: Lyndon Nerenberg , FreeBSD Current list Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 23:18:39 -0000 On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni wrote: > Hello; > > On 05/07/15 14:56, Lyndon Nerenberg wrote: >> >> On Thu, 7 May 2015, Pedro Giffuni wrote: >> >>> Unfortunately I don't use RCS enough (it looks like I should though) so >>> I am not in a good position to take the next step and deal with any >>> fallout it may produce. >> >> >> If we can have a build-knob to disable GNU RCS and enable the new one I >> will happily twist up the new version and hammer on it. >> > > Yes, that's usually the next step in the process. It is a little bit messy > because > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and > perhaps something else that we don't use). > > I really want to check out first if there is some strong opinion against > OpenRCS. Perhaps someone that has used it before and thinks it is a > bad idea. > > It looks like there are voices against it, so those have to be addressed > first. Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs bits); check with jhb first to make sure that OpenRCS works with etcupdate. Cheers! From owner-freebsd-current@FreeBSD.ORG Fri May 8 04:33:37 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99C98CC4; Fri, 8 May 2015 04:33:37 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A6DB1D88; Fri, 8 May 2015 04:33:37 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 66E041FE023; Fri, 8 May 2015 06:33:35 +0200 (CEST) Message-ID: <554C3CCB.3030809@selasky.org> Date: Fri, 08 May 2015 06:34:19 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper , Kevin Oberman CC: FreeBSD Current , Ed Maste , Aleksandr Rybalko Subject: Re: Race VT+X11 on -current References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> In-Reply-To: <554BD2A8.70702@selasky.org> Content-Type: multipart/mixed; boundary="------------080204030301050704060908" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:33:37 -0000 This is a multi-part message in MIME format. --------------080204030301050704060908 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a fix, attached. I'll just throw this in if nobody objects. Seems like a trivial issue: Prevent switching to NULL or own window in the "vt_proc_window_switch" function. This fixes an issue where X11 keyboard input can appear stuck. The cause of the problem is a duplicate TTY device window switch IOCTL during boot, which leaves the "vt_switch_timer" running, because the current window is already selected. While at it factor out some NULL checks. PR: 200032 Reported by: multiple people MFC after: 1 week --HPS --------------080204030301050704060908 Content-Type: text/x-diff; name="vt.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vt.diff" Index: vt_core.c =================================================================== --- vt_core.c (revision 282504) +++ vt_core.c (working copy) @@ -451,9 +451,22 @@ struct vt_device *vd; int ret; + /* Prevent switching to NULL */ + if (vw == NULL) { + DPRINTF(30, "%s: Cannot switch to NULL.", __func__); + return (EINVAL); + } vd = vw->vw_device; curvw = vd->vd_curwindow; + /* + * Prevent switching to self to avoid starting the + * "vt_switch_timer()" again: + */ + if (vw == curvw) { + DPRINTF(30, "%s: Cannot switch to self.", __func__); + return (0); + } if (curvw->vw_flags & VWF_VTYLOCK) return (EBUSY); @@ -664,8 +677,7 @@ if (console == 0) { if (c >= F_SCR && c <= MIN(L_SCR, F_SCR + VT_MAXWINDOWS - 1)) { vw = vd->vd_windows[c - F_SCR]; - if (vw != NULL) - vt_proc_window_switch(vw); + vt_proc_window_switch(vw); return; } VT_LOCK(vd); @@ -750,8 +762,7 @@ if (c >= F_SCR && c <= MIN(L_SCR, F_SCR + VT_MAXWINDOWS - 1)) { vw = vd->vd_windows[c - F_SCR]; - if (vw != NULL) - vt_proc_window_switch(vw); + vt_proc_window_switch(vw); return (0); } @@ -760,15 +771,13 @@ /* Switch to next VT. */ c = (vw->vw_number + 1) % VT_MAXWINDOWS; vw = vd->vd_windows[c]; - if (vw != NULL) - vt_proc_window_switch(vw); + vt_proc_window_switch(vw); return (0); case PREV: /* Switch to previous VT. */ c = (vw->vw_number - 1) % VT_MAXWINDOWS; vw = vd->vd_windows[c]; - if (vw != NULL) - vt_proc_window_switch(vw); + vt_proc_window_switch(vw); return (0); case SLK: { vt_save_kbd_state(vw, kbd); --------------080204030301050704060908-- From owner-freebsd-current@FreeBSD.ORG Fri May 8 04:47:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B703410E; Fri, 8 May 2015 04:47:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A54301EAF; Fri, 8 May 2015 04:47:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B7399BDB; Fri, 8 May 2015 04:47:30 +0000 (UTC) Date: Fri, 8 May 2015 04:47:30 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, delphij@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1031617806.18.1431060450627.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2742 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:47:30 -0000 See Changes: [adrian] Add initial memory locality cost awareness to the VM, and include a basic ACPI SLIT table parser. For now this just exports the map via sysctl; it'll eventually be useful to userland when there's more useful NUMA support in -HEAD. * Add an optional mem_locality map; * add a mapping function taking from/to domain and returning the relative cost, or -1 if it's not available; * Add a very basic SLIT parser to x86 ACPI. Differential Revision:=09https://reviews.freebsd.org/D2460 Reviewed by:=09rpaulo, stas, jhb Sponsored by:=09Norse Corp, Inc (hardware, coding); Dell (hardware) [delphij] MFV r282611: netcat from OpenBSD 5.7. MFC after:=092 weeks ------------------------------------------ [...truncated 277250 lines...] --- drm_dma.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_d= ma.o --- all_subdir_i915kms --- ctfconvert -L VERSION -g i915_gem_context.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_mm.o --- drm_pci.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_pci.= o --- all_subdir_drm2 --- --- i915_gem_execbuffer.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_gem_execbuffer.o --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_dma.o --- all_subdir_dtrace --- --- dtmalloc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I -I -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys> -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-= decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-= arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__free= bsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkno= wn-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-err= or-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign= -mno-aes -mno-avx -std=3Diso9899:1999 -include -c = -o dtmalloc.o --- all_subdir_drm2 --- --- drm_dp_helper.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o= drm_dp_helper.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_pci.o --- all_subdir_drm2 --- --- all_subdir_i915kms --- :795:13: warning: comparison of= address of 'obj->base' equal to a null pointer is always false [-Wtautolog= ical-pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :1261:13: warning: comparison o= f address of 'obj->base' equal to a null pointer is always false [-Wtautolo= gical-pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ --- all_subdir_drm --- --- drm_scatter.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_= scatter.o --- all_subdir_dtrace --- ctfconvert -L VERSION -g dtmalloc.o --- all_subdir_drm2 --- --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_dp_helper.o --- all_subdir_dtrace --- --- dtmalloc.ko.debug --- ld -d -warn-common -r -d -o dtmalloc.ko.debug dtmalloc.o ctfmerge -L VERSION -g -o dtmalloc.ko.debug dtmalloc.o --- all_subdir_drm2 --- --- drm_drv.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_d= rv.o --- all_subdir_dtrace --- :> export_syms awk -f dtmalloc.ko.debug export_syms | xargs -J% objcopy % dtmalloc.ko.debug --- dtmalloc.ko.symbols --- objcopy --only-keep-debug dtmalloc.ko.debug dtmalloc.ko.symbols --- all_subdir_drm2 --- --- all_subdir_i915kms --- 2 warnings generated. ctfconvert -L VERSION -g i915_gem_execbuffer.o --- all_subdir_dtrace --- --- dtmalloc.ko --- objcopy --strip-debug --add-gnu-debuglink=3Ddtmalloc.ko.symbols dtmalloc.ko= .debug dtmalloc.ko =3D=3D=3D> dtrace/dtnfscl (all) --- all_subdir_drm2 --- --- i915_gem_evict.o --- --- all_subdir_drm --- ctfconvert -L VERSION -g drm_scatter.o --- all_subdir_drm2 --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_gem_evict.o --- all_subdir_drm --- --- drm_sman.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_sma= n.o --- all_subdir_dtrace --- --- nfs_clkdtrace.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -I -I -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I<= https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys> -fno-common -g -fno-om= it-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkern= el -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-t= ables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-= decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-= arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__free= bsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkno= wn-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-err= or-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign= -mno-aes -mno-avx -std=3Diso9899:1999 -include -c = -o nfs_clkdtrace.o --- all_subdir_drm2 --- --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_drv.o --- drm_fb_helper.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o= drm_fb_helper.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_sman.o --- drm_sysctl.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_s= ysctl.o --- all_subdir_drm2 --- --- all_subdir_i915kms --- ctfconvert -L VERSION -g i915_gem_evict.o --- i915_gem_gtt.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_gem_gtt.o --- all_subdir_dtrace --- ctfconvert -L VERSION -g nfs_clkdtrace.o --- dtnfscl.ko.debug --- ld -d -warn-common -r -d -o dtnfscl.ko.debug nfs_clkdtrace.o ctfmerge -L VERSION -g -o dtnfscl.ko.debug nfs_clkdtrace.o :> export_syms awk -f dtnfscl.ko.debug export_syms | xargs -J% objcopy % dtnfscl.ko.debug --- all_subdir_drm --- ctfconvert -L VERSION -g drm_sysctl.o --- all_subdir_dtrace --- --- dtnfscl.ko.symbols --- objcopy --only-keep-debug dtnfscl.ko.debug dtnfscl.ko.symbols --- all_subdir_drm --- --- drm_vm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_vm.o --- all_subdir_dtrace --- --- dtnfscl.ko --- objcopy --strip-debug --add-gnu-debuglink=3Ddtnfscl.ko.symbols dtnfscl.ko.d= ebug dtnfscl.ko =3D=3D=3D> dtrace/dtrace (all) --- all_subdir_drm2 --- --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_fb_helper.o --- all_subdir_i915kms --- ctfconvert -L VERSION -g i915_gem_gtt.o --- all_subdir_drm2 --- --- drm_fops.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_= fops.o --- all_subdir_i915kms --- --- i915_gem_stolen.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -fno-omit= -frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel= -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tab= les -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-de= cls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar= ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebs= d_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown= -pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error= -parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign = -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_gem_stolen.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_vm.o --- drm.ko.debug --- ld -d -warn-common -r -d -o drm.ko.debug ati_pcigart.o drm_agpsupport.o drm= _auth.o drm_bufs.o drm_context.o drm_dma.o drm_drawable.o drm_drv.o drm_fop= s.o drm_hashtab.o drm_ioctl.o drm_irq.o drm_lock.o drm_memory.o drm_mm.o dr= m_pci.o drm_scatter.o drm_sman.o drm_sysctl.o drm_vm.o drm_agpsupport.o: In function `drm_device_is_agp': :88: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_auth.o: In function `drm_getmagic': :141: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_bufs.o: In function `drm_get_resource_start': :82: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_context.o: In function `drm_ctxbitmap_free': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_dma.o: In function `drm_dma_setup': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_drawable.o: In function `drm_get_drawable_info': :63: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_drv.o: In function `drm_probe': :161: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_fops.o: In function `drm_open_helper': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_hashtab.o: In function `drm_ht_create': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_ioctl.o: In function `drm_getunique': :49: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_irq.o: In function `drm_irq_by_busid': :41: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_lock.o: In function `drm_lock': :56: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_memory.o: In function `drm_mem_init': :67: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_mm.o: In function `drm_mm_tail_space': :53: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_pci.o: In function `drm_pci_alloc': :59: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_scatter.o: In function `drm_sg_alloc': :38: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_sman.o: In function `drm_sman_takedown': :53: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_sysctl.o: In function `drm_name_info': :134: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_vm.o: In function `drm_mmap': :36: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here *** [drm.ko.debug] Error code 1 make[5]: stopped in 1 error make[5]: stopped in --- all_subdir_dtrace --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_dtrace] Error code 2 make[3]: stopped in --- all_subdir_drm --- *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_drm] Error code 2 make[3]: stopped in --- all_subdir_drm2 --- ctfconvert -L VERSION -g i915_gem_stolen.o --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_fops.o --- all_subdir_i915kms --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_i915kms] Error code 2 make[4]: stopped in --- all_subdir_drm2 --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_drm2] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in *** [all_subdir_drm2] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-all] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Fri May 8 05:27:01 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BFBF64E; Fri, 8 May 2015 05:27:01 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9B25124B; Fri, 8 May 2015 05:27:00 +0000 (UTC) Received: by wizk4 with SMTP id k4so16218186wiz.1; Thu, 07 May 2015 22:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2Frei6u+gZNhpxz+NWrIE9ljzor96KXcUYprFMgS8Qg=; b=v8rznKBPZyMpNEnWOtSe2J88Z7uynRmq/Y9y7dl1HQLQTL5z2mkOXDOXalLKqhCDyB Ng+7kjKDwVmS81yAuTsJMPBK03SafLVL+NJ9RxacAoJzqUkQ+EExJX/FWRjYCOAujhRg Ee6yqvl1XnE+i4ALaT+N5duDNIneOWp5rlxt+22D6FkCkdz5Z5wLIXFGDyAb8jlxiPn1 X2Yi5PqBhXZ115GaHYpNvrz6wRxI1H0DM1vSyMRappfx5CU0YBSegMQmtJ6JUtn9rZAF YjPQKK5xrwIGG6awxwzeffBeSvMEIjUl1L5GY4dbfzO6K68DYlDz5ukwT7LJrCO5Kllg eotQ== MIME-Version: 1.0 X-Received: by 10.180.10.102 with SMTP id h6mr2749017wib.37.1431062818443; Thu, 07 May 2015 22:26:58 -0700 (PDT) Received: by 10.27.210.147 with HTTP; Thu, 7 May 2015 22:26:58 -0700 (PDT) Date: Fri, 8 May 2015 13:26:58 +0800 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: Doug Brewer To: NGie Cooper , Pedro Giffuni Cc: FreeBSD Current list , Lyndon Nerenberg Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 05:27:01 -0000 On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote: > > On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni wrote: > > Hello; > > > > On 05/07/15 14:56, Lyndon Nerenberg wrote: > >> > >> On Thu, 7 May 2015, Pedro Giffuni wrote: > >> > >>> Unfortunately I don't use RCS enough (it looks like I should though) so > >>> I am not in a good position to take the next step and deal with any > >>> fallout it may produce. > >> > >> > >> If we can have a build-knob to disable GNU RCS and enable the new one I > >> will happily twist up the new version and hammer on it. > >> > > > > Yes, that's usually the next step in the process. It is a little bit messy > > because > > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and > > perhaps something else that we don't use). > > > > I really want to check out first if there is some strong opinion against > > OpenRCS. Perhaps someone that has used it before and thinks it is a > > bad idea. > > > > It looks like there are voices against it, so those have to be addressed > > first. > > Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs > bits); check with jhb first to make sure that OpenRCS works with > etcupdate. Confirmed. Pedro, are you also willing to fix fallout as Xin Li pointed out? If not, please revert, thanks. From owner-freebsd-current@FreeBSD.ORG Fri May 8 05:47:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F05F878 for ; Fri, 8 May 2015 05:47:54 +0000 (UTC) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B92C1468 for ; Fri, 8 May 2015 05:47:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431064067; bh=GnuYGblxfbiuEOSep/KoxMsoEpg9+Z99oYJEcgIwZ90=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=KN3XY50lcRekjdfp7lrcetNX8Sqe3W5dFOUZviQiJJOYTJupKzXJ8+flrhppRmm578YAPAaAdqFHo+UI6Vodl3O4nLuH2HZeVpvwpRX12vehqMBQSXx0kZTBBrj1xLWqwkKXsKKMQHwUI/vV7C6Qb+gRvioNUl1ON9iHne0fDEjYRXfFhfzk9EUO34/KnKpUGNX9KJF/GGNcYUtcl38dVGmaGNFA3yQJI3B8oPc4Joyn9i6MR0cPiV5y8t0Q/2UZC1k3wbwtfbwcdqYSIW85j4HLJT9zBsCiin1NEFrDyK2sNS2RKZ14pE3Fuw+c8G0+4+Ije5MBIe1athSl6cUeew== Received: from [66.196.81.172] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 05:47:47 -0000 Received: from [98.139.213.10] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 05:47:47 -0000 Received: from [127.0.0.1] by smtp110.mail.bf1.yahoo.com with NNFMP; 08 May 2015 05:47:47 -0000 X-Yahoo-Newman-Id: 74705.92184.bm@smtp110.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GlNzePkVM1lQvwjcEA.AXKQvQ8kcNehGnzkO1XtGQ49HlAU 9agdfeUws0cTUnbr6le1_bAfkTFaG1iigNc0IPbXwduEtH.0CT4aqzhatMxg yG7Yh7UhWX6g_.mmiNE740CRMMq.SVPVZu9jv0aE6nsmOj2SqWyxFlIHkNUj GS.DSx.Z8UDYJ8xkCP3GwOXTtpO0s6zG34C57KRgDz0cwVSlb9fzA8T77Nmy buyfV2vPAXaY7obNwMs0sRii_S9jFiovt39coP8myO9qMpqwxxVRLqslNbAE RRHRdqja1RNGZjbSq2tcxvcJoDrBFTT_G_od.t8n8wUspGOBBxf2B58ZBau9 OCS0NpF0o7LAGnNCfoTXonmHtFRwmytxA0aP0rz_SqVqFabMVgsj.QG55tEV 2vPFfKtz9tnZCkfQBc9fU0zX4LlZhLXZdLsHkv_AqhVMd3qCQ9pKPAJ_2j0_ gfZ0cIbbUzYu5i6s9FV4HLkp1GNV0UIntDPIvZVvCctYDs4ZKsg6qswc9ocN b58vcCHBriv34COHbs9lB2ydk88xV58lz X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: What to do about RCS/OpenRCS From: Pedro Giffuni In-Reply-To: Date: Fri, 8 May 2015 00:47:43 -0500 Cc: NGie Cooper , FreeBSD Current list , Lyndon Nerenberg Message-Id: <46E9A948-9D19-4ED6-AB4E-03CFDD5B92A0@FreeBSD.org> References: To: Doug Brewer X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 05:47:54 -0000 > Il giorno 08/mag/2015, alle ore 00:26, Doug Brewer = ha scritto: >=20 > On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote:=20 > >=20 > > On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni > wrote:=20 > > > Hello;=20 > > >=20 > > > On 05/07/15 14:56, Lyndon Nerenberg wrote:=20 > > >>=20 > > >> On Thu, 7 May 2015, Pedro Giffuni wrote:=20 > > >>=20 > > >>> Unfortunately I don't use RCS enough (it looks like I should = though) so=20 > > >>> I am not in a good position to take the next step and deal with = any=20 > > >>> fallout it may produce.=20 > > >>=20 > > >>=20 > > >> If we can have a build-knob to disable GNU RCS and enable the new = one I=20 > > >> will happily twist up the new version and hammer on it.=20 > > >>=20 > > >=20 > > > Yes, that's usually the next step in the process. It is a little = bit messy=20 > > > because=20 > > > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze = (and=20 > > > perhaps something else that we don't use).=20 > > > > > > I really want to check out first if there is some strong opinion = against=20 > > > OpenRCS. Perhaps someone that has used it before and thinks it is = a=20 > > > bad idea.=20 > > >=20 > > > It looks like there are voices against it, so those have to be = addressed=20 > > > first.=20 > >=20 > > Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs=20 > > bits); check with jhb first to make sure that OpenRCS works with=20 > > etcupdate.=20 >=20 > Confirmed. Pedro, are you also willing to fix fallout as Xin Li = pointed out?=20 > If not, please revert, thanks. I haven=E2=80=99t committed anything to base so there=E2=80=99s nothing = to revert (?). Pedro. >=20 From owner-freebsd-current@FreeBSD.ORG Fri May 8 06:00:18 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2499C15; Fri, 8 May 2015 06:00:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id CF4BF163E; Fri, 8 May 2015 06:00:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F03ECBF5; Fri, 8 May 2015 06:00:17 +0000 (UTC) Date: Fri, 8 May 2015 06:00:16 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1969195445.19.1431064817905.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_i386 #98 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 06:00:18 -0000 See Changes: [adrian] Add initial memory locality cost awareness to the VM, and include a basic ACPI SLIT table parser. For now this just exports the map via sysctl; it'll eventually be useful to userland when there's more useful NUMA support in -HEAD. * Add an optional mem_locality map; * add a mapping function taking from/to domain and returning the relative cost, or -1 if it's not available; * Add a very basic SLIT parser to x86 ACPI. Differential Revision:=09https://reviews.freebsd.org/D2460 Reviewed by:=09rpaulo, stas, jhb Sponsored by:=09Norse Corp, Inc (hardware, coding); Dell (hardware) ------------------------------------------ [...truncated 203904 lines...] ctfmerge -L VERSION -g -o t4_tom.kld t4_connect.o t4_cpl_io.o t4_ddp.o t4_l= isten.o t4_tom.o t4_tom_l2t.o --- all_subdir_drm --- --- drm_lock.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -= o drm_lock.o --- all_subdir_cxgbe --- :> export_syms awk -f t4_tom.kld export_syms | xargs -J% objcopy % t4_tom.kld --- t4_tom.ko.debug --- ld -Bshareable -d -warn-common -o t4_tom.ko.debug t4_tom.kld --- t4_tom.ko.symbols --- objcopy --only-keep-debug t4_tom.ko.debug t4_tom.ko.symbols --- t4_tom.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dt4_tom.ko.symbols t4_tom.ko.deb= ug t4_tom.ko --- all_subdir_drm2 --- --- all_subdir_i915kms --- =3D=3D=3D> drm2/i915kms (all) --- i915_debug.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -Wno-unused-function -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_debug.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_lock.o --- all_subdir_drm2 --- --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_crtc_helper.o --- all_subdir_drm --- --- drm_memory.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c = -o drm_memory.o --- all_subdir_drm2 --- --- drm_dma.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c = -o drm_dma.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_memory.o --- drm_mm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o = drm_mm.o --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_dma.o --- drm_dp_helper.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_dp_helper.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_mm.o --- all_subdir_drm2 --- --- all_subdir_i915kms --- ctfconvert -L VERSION -g i915_debug.o --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_dp_helper.o --- drm_drv.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c = -o drm_drv.o --- all_subdir_drm --- --- drm_pci.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o= drm_pci.o --- all_subdir_drm2 --- --- all_subdir_i915kms --- --- i915_dma.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_dma.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_pci.o --- drm_scatter.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_scatter.o --- all_subdir_drm2 --- --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_drv.o --- drm_fb_helper.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_fb_helper.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_scatter.o --- drm_sman.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -= o drm_sman.o ctfconvert -L VERSION -g drm_sman.o --- all_subdir_drm2 --- --- all_subdir_i915kms --- ctfconvert -L VERSION -g i915_dma.o --- all_subdir_drm --- --- drm_sysctl.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c = -o drm_sysctl.o --- all_subdir_drm2 --- --- i915_gem.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o i915_gem.o --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_fb_helper.o --- drm_fops.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o drm_fops.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_sysctl.o --- drm_vm.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c -o = drm_vm.o --- all_subdir_drm2 --- --- all_subdir_i915kms --- :709:12: warning: comparison of addre= ss of 'obj->base' equal to a null pointer is always false [-Wtautological-p= ointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :748:12: warning: comparison of addre= ss of 'obj->base' equal to a null pointer is always false [-Wtautological-p= ointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :842:12: warning: comparison of addre= ss of 'obj->base' equal to a null pointer is always false [-Wtautological-p= ointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :1362:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :1722:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :1809:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :1841:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ :2117:12: warning: comparison of addr= ess of 'obj->base' equal to a null pointer is always false [-Wtautological-= pointer-compare] if (&obj->base =3D=3D NULL) { ~~~~~^~~~ ~~~~ --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_fops.o --- drm_gem.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -fno-common -g -I -mno-mmx -mno-sse -msof= t-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan= t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointe= r-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__fr= eebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-e= rror-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-si= gn -mno-aes -mno-avx -std=3Diso9899:1999 -c = -o drm_gem.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_vm.o --- drm.kld --- ld -d -warn-common -r -d -o drm.kld ati_pcigart.o drm_agpsupport.o drm_auth= .o drm_bufs.o drm_context.o drm_dma.o drm_drawable.o drm_drv.o drm_fops.o d= rm_hashtab.o drm_ioctl.o drm_irq.o drm_lock.o drm_memory.o drm_mm.o drm_pci= .o drm_scatter.o drm_sman.o drm_sysctl.o drm_vm.o drm_agpsupport.o: In function `drm_device_is_agp': :88: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_auth.o: In function `drm_getmagic': :141: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_bufs.o: In function `drm_get_resource_start': :82: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_context.o: In function `drm_ctxbitmap_free': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_dma.o: In function `drm_dma_setup': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_drawable.o: In function `drm_get_drawable_info': :63: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_drv.o: In function `drm_probe': :161: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_fops.o: In function `drm_open_helper': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_hashtab.o: In function `drm_ht_create': :45: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_ioctl.o: In function `drm_getunique': :49: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_irq.o: In function `drm_irq_by_busid': :41: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_lock.o: In function `drm_lock': :56: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_memory.o: In function `drm_mem_init': :67: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_mm.o: In function `drm_mm_tail_space': :53: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_pci.o: In function `drm_pci_alloc': :59: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_scatter.o: In function `drm_sg_alloc': :38: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_sman.o: In function `drm_sman_takedown': :53: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_sysctl.o: In function `drm_name_info': :134: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here drm_vm.o: In function `drm_mmap': :36: multiple definition of `mem_locality' ati_pcigart.o::129: first defined here *** [drm.kld] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_drm] Error code 2 make[3]: stopped in --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_gem.o A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_drm2] Error code 2 make[4]: stopped in --- all_subdir_i915kms --- 8 warnings generated. ctfconvert -L VERSION -g i915_gem.o A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_i915kms] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in *** [all_subdir_drm2] Error code 2 make[3]: stopped in --- all_subdir_dtrace --- ctfconvert -L VERSION -g dis_tables.o A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_dtrace] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-all] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Fri May 8 06:03:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3B57EB5; Fri, 8 May 2015 06:03:04 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF4D61664; Fri, 8 May 2015 06:03:04 +0000 (UTC) Received: by iget9 with SMTP id t9so25040278ige.1; Thu, 07 May 2015 23:03:04 -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=E4HCbDI3ABRjIM/Tckm7JBoBEuxXJ2ugzCAjyj9QaaM=; b=rD+Fs/ZktmC1XgRPCMMKKNEjUkngxE1O+MS3QXsIXxqAKq2qZIh2DcN/yGWmbrhMpv jtR9VPhMhPFqMTmcSI6W/miPJxigQIxNoYguzMpo1RZzptyz09qU8guP05KKxd/wOEh3 PPjR4rHdpKoPKTsWxw9byqmUg2f2b0CwCpONyEUiK2D1e5LFbW5URgTlQ9tvrHVuP29a yK6PeIasKxYDR/eMAkp+hzeWd08V3Z7IMfntSu4M0sgSI6nv1SuSb2P3vZQwIDBFS3Mw O1yaHJTw+vZbJD//cT8KWVMFqeg0AhC8unKqgTtmezTEv1rTvzTuUfXmRFa4GwBoz6UN iY6A== MIME-Version: 1.0 X-Received: by 10.107.46.39 with SMTP id i39mr2858873ioo.8.1431064984267; Thu, 07 May 2015 23:03:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Thu, 7 May 2015 23:03:04 -0700 (PDT) In-Reply-To: <1969195445.19.1431064817905.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1969195445.19.1431064817905.JavaMail.jenkins@jenkins-9.freebsd.org> Date: Thu, 7 May 2015 23:03:04 -0700 X-Google-Sender-Auth: wPkzOpzmDPkN1JbFrvYPnOdbNSU Message-ID: Subject: Re: Build failed in Jenkins: FreeBSD_HEAD_i386 #98 From: Adrian Chadd To: "jenkins-admin@freebsd.org" Cc: freebsd-current , freebsd-i386@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 06:03:05 -0000 [snip] fixed! -a From owner-freebsd-current@FreeBSD.ORG Fri May 8 09:54:15 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F404F39; Fri, 8 May 2015 09:54:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0561ED5; Fri, 8 May 2015 09:54:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C733FC68; Fri, 8 May 2015 09:54:15 +0000 (UTC) Date: Fri, 8 May 2015 09:54:15 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, delphij@FreeBSD.org, ganbold@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1518779888.21.1431078855493.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1031617806.18.1431060450627.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1031617806.18.1431060450627.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2743 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 09:54:15 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri May 8 09:56:53 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9134E1CD; Fri, 8 May 2015 09:56:53 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EEF41EFD; Fri, 8 May 2015 09:56:53 +0000 (UTC) Received: by pdea3 with SMTP id a3so75526703pde.3; Fri, 08 May 2015 02:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=He/e0Og7iN/Nx2RoEyncH/NuA7g1ciIPpqBMwFwFgNQ=; b=DQ4Ai8+v2w3sNcKU9Wle2u1Cq5Vr3UFwlJv+jfZ89pQfLowOd+QCHOBEOv1BUvN3aI UE577DYxJ5mXZnmDFDFDN2O/Qse5gW0zw+f7GT1sj7Y7iF7eCpX4a62nVPkRE/wZj0M6 s8KqZGIXbpIKnNWIm4y5tpO2Tr5xaKVURXuq3pB9LNKN1TusNtu4SGFg34ggS+jBORHn n3Ys6febgTXLDaP1LoY/dv6NcyT10k1Gmlw+1191yW0L9450sAOwuYwhSyhUMGhUD6pL aaxbrlyPIEZ6uagOxP+r/5pdE0M+pcYECsSMDfEGR5BNTaR3h4n/tP84qtqSxUgsLUjY 48Kg== X-Received: by 10.68.252.38 with SMTP id zp6mr5105659pbc.159.1431078970604; Fri, 08 May 2015 02:56:10 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:c555:c310:d7f4:96d3? ([2601:8:ab80:7d6:c555:c310:d7f4:96d3]) by mx.google.com with ESMTPSA id mi1sm4562828pab.0.2015.05.08.02.56.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 May 2015 02:56:09 -0700 (PDT) References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> Mime-Version: 1.0 (1.0) In-Reply-To: <554C3CCB.3030809@selasky.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> Cc: Kevin Oberman , FreeBSD Current , Ed Maste , Aleksandr Rybalko X-Mailer: iPhone Mail (12F70) From: Garrett Cooper Subject: Re: Race VT+X11 on -current Date: Fri, 8 May 2015 02:56:08 -0700 To: Hans Petter Selasky X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 09:56:53 -0000 > On May 7, 2015, at 21:34, Hans Petter Selasky wrote: > > Hi, > > I have a fix, attached. > > I'll just throw this in if nobody objects. Seems like a trivial issue: > > Prevent switching to NULL or own window in the "vt_proc_window_switch" > function. This fixes an issue where X11 keyboard input can appear > stuck. The cause of the problem is a duplicate TTY device window > switch IOCTL during boot, which leaves the "vt_switch_timer" running, > because the current window is already selected. While at it factor out > some NULL checks. > > PR: 200032 > Reported by: multiple people > MFC after: 1 week Hi Hans, Can you please toss that up on phabricator? Thanks! -NGie From owner-freebsd-current@FreeBSD.ORG Fri May 8 10:07:04 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D04458F8; Fri, 8 May 2015 10:07:04 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EAAC1069; Fri, 8 May 2015 10:07:04 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6CDBC1FE023; Fri, 8 May 2015 12:06:55 +0200 (CEST) Message-ID: <554C8AEB.2080502@selasky.org> Date: Fri, 08 May 2015 12:07:39 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Garrett Cooper CC: Kevin Oberman , FreeBSD Current , Ed Maste , Aleksandr Rybalko Subject: Re: Race VT+X11 on -current References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> In-Reply-To: <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 10:07:04 -0000 On 05/08/15 11:56, Garrett Cooper wrote: > >> On May 7, 2015, at 21:34, Hans Petter Selasky wrote: >> >> Hi, >> >> I have a fix, attached. >> >> I'll just throw this in if nobody objects. Seems like a trivial issue: >> >> Prevent switching to NULL or own window in the "vt_proc_window_switch" >> function. This fixes an issue where X11 keyboard input can appear >> stuck. The cause of the problem is a duplicate TTY device window >> switch IOCTL during boot, which leaves the "vt_switch_timer" running, >> because the current window is already selected. While at it factor out >> some NULL checks. >> >> PR: 200032 >> Reported by: multiple people >> MFC after: 1 week > > Hi Hans, > Can you please toss that up on phabricator? > Thanks! > -NGie If it helps getting the stuff committed ... https://reviews.freebsd.org/D2480 --HPS From owner-freebsd-current@FreeBSD.ORG Fri May 8 10:12:57 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F2DCB44; Fri, 8 May 2015 10:12:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id EFC96115C; Fri, 8 May 2015 10:12:56 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7A2AFC69; Fri, 8 May 2015 10:12:57 +0000 (UTC) Date: Fri, 8 May 2015 10:12:57 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, ganbold@FreeBSD.org, adrian@FreeBSD.org Message-ID: <589514525.22.1431079977453.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1969195445.19.1431064817905.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1969195445.19.1431064817905.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_i386 #99 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_i386 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 10:12:57 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri May 8 14:29:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62BA4336 for ; Fri, 8 May 2015 14:29:32 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 3C125103C for ; Fri, 8 May 2015 14:29:31 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7C939A8A96 for ; Fri, 8 May 2015 14:29:25 +0000 (UTC) Message-ID: <554CC841.60908@freebsd.org> Date: Fri, 08 May 2015 10:29:21 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Race VT+X11 on -current References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> In-Reply-To: <554C8AEB.2080502@selasky.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RxEQL24akg37KpJTHsIS3FPdCLQ0LVfa2" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 14:29:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RxEQL24akg37KpJTHsIS3FPdCLQ0LVfa2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-05-08 06:07, Hans Petter Selasky wrote: > On 05/08/15 11:56, Garrett Cooper wrote: >> >>> On May 7, 2015, at 21:34, Hans Petter Selasky wrote= : >>> >>> Hi, >>> >>> I have a fix, attached. >>> >>> I'll just throw this in if nobody objects. Seems like a trivial issue= : >>> >>> Prevent switching to NULL or own window in the "vt_proc_window_switch= " >>> function. This fixes an issue where X11 keyboard input can appear >>> stuck. The cause of the problem is a duplicate TTY device window >>> switch IOCTL during boot, which leaves the "vt_switch_timer" running,= >>> because the current window is already selected. While at it factor ou= t >>> some NULL checks. >>> >>> PR: 200032 >>> Reported by: multiple people >>> MFC after: 1 week >> >> Hi Hans, >> Can you please toss that up on phabricator? >> Thanks! >> -NGie >=20 > If it helps getting the stuff committed ... >=20 > https://reviews.freebsd.org/D2480 >=20 > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" My experience is a little different. When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) Sometimes when I resume, it seems like the keyboard is frozen. If I alt+f1, then alt+f9, it seems to work fine after that. I'd never though of trying just alt+f9 right away, as I could already see my X session. Not sure if this is related, but it sounds very similar. --=20 Allan Jude --RxEQL24akg37KpJTHsIS3FPdCLQ0LVfa2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVTMhJAAoJEJrBFpNRJZKfTJAP+gOX+rLi425H3re1EmOSgN2q Xu+1yV43DXH0MTF+FU7NshZx8WlTZCcc+YsqY7suOn3tThHQ3YqNJmTg3GPGe3lC NHJP5YdfK2qj3pvSKDPfz1heEXwx8zo4EnLcfw6KLwm4BnqvzKEwThyNs5FKgjYf TJKWMAZCAd2KOfoVJpqNYEb6u7n5UHdlJSdNewrUyE5yJnAGxRDTIIRUQtRKiPs+ i5eIB+jygrOPU8fQM/pqKA1aYhrbAfTmgV7Ip3q+J+58cVUiQf9pxz6t63uoYtV/ CxMwFs45qytnQCdVg/Fb90x8IaLZRFWc1smJRaMUIZx2JDPFLu0d8Da8rKy8dLWF QvqgLNsADnoIictlSFpGzpJf6gcWjFJa9SQNJYwCOktbLIf8fzL0IKBEW7UyEXOF rgynGViZ3Ii0azScokLpOvazmdf/IeouWJOoJalQUKSt1CZmSRgPaQghbCWZyATo m0njPqEh4C5BQ9l5Plalx460UNVrTVieX3IzKk4GMNGJZQeJh/tvgx7+4HbYrE/J Y65tGISkTbV2bxWPGiJLxR8f+RSx18yNcegnIrHRIOHxHAmuYyJItTucOFnWkwPj k/TFOY5uPPBm09ZA1rHqIC6ORmex8vH9o6hO1WYcPQcS/z0e67kb6cuvcc4q4bkT Lvd1rdO1OqVd1XUN1hdq =ZDQQ -----END PGP SIGNATURE----- --RxEQL24akg37KpJTHsIS3FPdCLQ0LVfa2-- From owner-freebsd-current@FreeBSD.ORG Fri May 8 20:16:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C16A665A; Fri, 8 May 2015 20:16:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AAF31BB0; Fri, 8 May 2015 20:16:52 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9786CB94E; Fri, 8 May 2015 16:16:51 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: NGie Cooper , Pedro Giffuni , Lyndon Nerenberg Subject: Re: What to do about RCS/OpenRCS Date: Fri, 08 May 2015 11:44:44 -0400 Message-ID: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 08 May 2015 16:16:51 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 20:16:52 -0000 On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote: > On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni wrote: > > Hello; > > > > On 05/07/15 14:56, Lyndon Nerenberg wrote: > >> > >> On Thu, 7 May 2015, Pedro Giffuni wrote: > >> > >>> Unfortunately I don't use RCS enough (it looks like I should though) so > >>> I am not in a good position to take the next step and deal with any > >>> fallout it may produce. > >> > >> > >> If we can have a build-knob to disable GNU RCS and enable the new one I > >> will happily twist up the new version and hammer on it. > >> > > > > Yes, that's usually the next step in the process. It is a little bit messy > > because > > there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and > > perhaps something else that we don't use). > > > > I really want to check out first if there is some strong opinion against > > OpenRCS. Perhaps someone that has used it before and thinks it is a > > bad idea. > > > > It looks like there are voices against it, so those have to be addressed > > first. > > Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs > bits); check with jhb first to make sure that OpenRCS works with > etcupdate. > Cheers! I think this can be fixed by using diff3 instead of merge, I just haven't sat down and figured out the correct incantation. That said, I think that having a not-quite-working rcs (OpenRCS) in base is worse than having no rcs. If OpenRCS is improved as per Xin's notes then just switching over is probably the path of least resistance. I guess I see the following options: 1) Just leave GNU RCS in the tree. 2) Improve OpenRCS so it can be swapped in. 3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate) and import just a /bin/ident binary (perhaps from OpenRCS). Both 2) and 3) require some work. I suspect 3) requires less. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri May 8 20:34:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C31E444F for ; Fri, 8 May 2015 20:34:27 +0000 (UTC) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8072B1DD8 for ; Fri, 8 May 2015 20:34:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431117260; bh=7TX9sgu4xakHJAaouTsbNW0jO58SLQpD6oIZKR3X1t0=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=M2c2dB+Y1tHYomnLPXCoTd2hWGO9kizQqOMx/hYiZ/RUOMS0Yd0haQPHxrdm93gbfLZu4nUon8ykkj28N/2aIdOfXlm+vvndOFFc5KPpgj2Q1prPHCMr8BIF0QPa0GdsbG5hrqA5CkJdKJ0syp+9poe9rPyQDt7b2H0wfThWNFSf662TivW+qxl94OZuMM/bspzKP80oNWNXwcn5vZJsen2spgI41gOgQVPASsU++QUBQkq/QMIypjv3ii4Ai82iCiKk98A5fYpx1dnB8b6r581AJnh/4fGmUq64DGpXQkLJX/ghmj1BWrXguu5Zx6RKMJ8+NZoltZ0eMWXsJhLZHA== Received: from [98.139.215.141] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 20:34:20 -0000 Received: from [98.139.211.196] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 08 May 2015 20:34:20 -0000 Received: from [127.0.0.1] by smtp205.mail.bf1.yahoo.com with NNFMP; 08 May 2015 20:34:20 -0000 X-Yahoo-Newman-Id: 45143.85904.bm@smtp205.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: y6U5CpcVM1kb7LSVFZY6QgI7YCxV0qS6ekwOg7fkI0UKFN7 5uYShSNqauJOOXx1ROLhFT4wh6Hup9s_WkawYNWwdJt2U7BtnU7Q7kqQHFWS UVplupl6pgk6NK5EFRMIUGxTHh_cjXTxVb0CX3eXlHnVP2.ZDn2CqC6hQ008 JmOl_IUC3u439.4iSB37HB77gX1DE1zKKjmBRomeGzkWVGjnIFlIJokwIyHL rMhizA.oBk596tETLxrNlco.ABqH6dT568gmnB_u4QCC_oi4kySVz3Q53yxB 5IJjubCNAi6gEfDQhq1.1Gjj1qfErH09D2H.i5hc5M3oSyq5z.rHowHUk.UO S0mHBfQIdwkNyMkHHzHVhpdMkJnaMsCXvlyIf.pEWXFkgfaVw1yQEh5kU6nE ilfj1hDrwdqHAgpSamxDhzUf9amoFEYVv7HzTGbUecAPM474ZUM.XnRbtqsZ 2KQ_tvXoVk0iuZAWHcjyuGLhOeBZJZimt04Y2rxnvHN9an3yf_eo0OaO7vd6 kGzNtnQAfkYcDEu9mGyaYQWREzMaDetgi X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <554D1DD5.5080106@FreeBSD.org> Date: Fri, 08 May 2015 15:34:29 -0500 From: Pedro Giffuni Organization: FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org CC: NGie Cooper , Lyndon Nerenberg Subject: Re: What to do about RCS/OpenRCS References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> In-Reply-To: <3137063.YOSa6Au8Xi@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 20:34:28 -0000 Hi; On 08/05/2015 10:44 a.m., John Baldwin wrote: > On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote: >> On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni wrote: >>> Hello; >>> >>> On 05/07/15 14:56, Lyndon Nerenberg wrote: >>>> On Thu, 7 May 2015, Pedro Giffuni wrote: >>>> >>>>> Unfortunately I don't use RCS enough (it looks like I should though) so >>>>> I am not in a good position to take the next step and deal with any >>>>> fallout it may produce. >>>> >>>> If we can have a build-knob to disable GNU RCS and enable the new one I >>>> will happily twist up the new version and hammer on it. >>>> >>> Yes, that's usually the next step in the process. It is a little bit messy >>> because >>> there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and >>> perhaps something else that we don't use). >>> >>> I really want to check out first if there is some strong opinion against >>> OpenRCS. Perhaps someone that has used it before and thinks it is a >>> bad idea. >>> >>> It looks like there are voices against it, so those have to be addressed >>> first. >> Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs >> bits); check with jhb first to make sure that OpenRCS works with >> etcupdate. >> Cheers! > I think this can be fixed by using diff3 instead of merge, I just haven't > sat down and figured out the correct incantation. > > That said, I think that having a not-quite-working rcs (OpenRCS) in base > is worse than having no rcs. If OpenRCS is improved as per Xin's notes > then just switching over is probably the path of least resistance. To be honest, I just want to have options, and unfortunately OpenRCS is not one at this time. > I guess I see the following options: > > 1) Just leave GNU RCS in the tree. > > 2) Improve OpenRCS so it can be swapped in. > > 3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate) > and import just a /bin/ident binary (perhaps from OpenRCS). > > Both 2) and 3) require some work. I suspect 3) requires less. :) I honestly don't see a real problem with (1): we do want to replace as much GNU software as we can but not at the cost of making our life unnecessarily difficult. No. 2 is something that has to be reported/submitted upstream before we can adopt it. We do that with major components we take from other places and it is the proven, safe way to do it. No. 3 is something that seems necessary in any case: apparently the WITHOUT_RCS option has been always broken. I am currently reporting (2), but doing the /bin/ident part of (3) looks easy enough that I may do it at a later time ;). Pedro. From owner-freebsd-current@FreeBSD.ORG Fri May 8 20:59:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D26BCDE; Fri, 8 May 2015 20:59:50 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 237581093; Fri, 8 May 2015 20:59:50 +0000 (UTC) Received: by labbd9 with SMTP id bd9so60768743lab.2; Fri, 08 May 2015 13:59:48 -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=kWv/8nvaxBu6gkHIqpVdy91mdW9fRn3+yWWZZP5Wd5w=; b=lSB9/tLyscgDRnwiWiT3INYU6WR50RpIFzQirGGRSmqEU81us5kk/6FoNPn6xWf1rf n/9yZXpmi/vFwv6xLshOqy3HlgMU2tNdNSN+4aM3MwbxjEfCYytX6Gtt5uz+7rBXDcpH +Gmxj2jlWd1vjPsVxZEjwTD3FnpMOB01BA0nQLfgbR/RdjpKq12I+Lfw8bTAnA1OLTjY FUAprz5zZ6nUkNvbDnBtpKs7h8vah4MiZwLl4FLQNY/MIBo8Qr2kL1Ryg24RUslqYhHS tHuk8KBwRHhIKYBo/nH6O1hawFzYCWzQMWrnBNTxtCqoMx+O/iIsZWcKFGeFtOsPbeUc R7Hg== MIME-Version: 1.0 X-Received: by 10.152.42.242 with SMTP id r18mr4294031lal.8.1431118788057; Fri, 08 May 2015 13:59:48 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.25.88.77 with HTTP; Fri, 8 May 2015 13:59:47 -0700 (PDT) In-Reply-To: <554D1DD5.5080106@FreeBSD.org> References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> Date: Fri, 8 May 2015 13:59:47 -0700 X-Google-Sender-Auth: PG2TTBnShP77grcEN8KfhLjKa18 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: Davide Italiano To: Pedro Giffuni Cc: John Baldwin , freebsd-current , NGie Cooper , Lyndon Nerenberg Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 20:59:50 -0000 On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni wrote: > Hi; > > >> I guess I see the following options: >> >> 1) Just leave GNU RCS in the tree. >> >> 2) Improve OpenRCS so it can be swapped in. >> >> 3) Remove RCS dependencies from other parts of the tree (e.g. >> etcupdate) >> and import just a /bin/ident binary (perhaps from OpenRCS). >> >> Both 2) and 3) require some work. I suspect 3) requires less. :) > > > I honestly don't see a real problem with (1): we do want to replace as much > GNU > software as we can but not at the cost of making our life unnecessarily > difficult. > To be honest I'm not entirely sure what's the real reason of this crusade. FreeBSD can't import newer version of some components of the toolchain (e.g. compiler, linker, debugger) and some of them are slowly (or less slowly) bitrotting. I feel that in that case there's a real goal which justifies all the headache derived from the conversion. For GNU RCS, I'm not completely sure there is. I've never heard anybody complaining about lack of features for RCS or bugs. My $0.02, I suspect very few people really rely on it and just complain for the sake of doing it, but I'm not gonna argue on this further. That said, unfortunately there's a lot more than doing the conversion and fixing the code so that the testsuite will pass. You need to upstream the fixes and so deal with another layer and other maintainers otherwise the code in base and the one upstream will diverge. People rely from time to time on bugs of old software (e.g. single vs double dash options) and are gonna complain. The testsuite, even if comprehensive, unlikely will cover some corner cases and suddenly software will start breaking. In other words, a lot of (unneeded) work for you for a software that just worked fine(TM) until yesterday. I'm not gonna stop you from doing this, but I learned the hard way that it's something that can/should be avoided unless really necessary (and a better license doesn't seem to be a strong enough reason, IMHO). -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Sat May 9 10:24:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BEFEEC3 for ; Sat, 9 May 2015 10:24:56 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8067151F for ; Sat, 9 May 2015 10:24:55 +0000 (UTC) Received: by widdi4 with SMTP id di4so51034517wid.0 for ; Sat, 09 May 2015 03:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TPXhzfEPUTyd+/o9ePl/NFsupznW75EGUw5Lp9+gclw=; b=pHffXZUpJsqi/O3FJGcARMxw8MicieLnrZaa//s8k2mpIYTF3TQ1eAAnZSlaqE05HR lXU0SVBiliVDFY0Yc0GGP0OdLrA0IpG7vk3KF4WEle4WD1rnDVQYDmqjRwMOBNN3B6ZV sdwSHU5k2ffr6QT27hnCbqaQC8L1w9RtVmnZgkwiUnWoMjno5UcynrhS6fAUTLfsqsiI uJaMP3hzI5gAySaA/oPFmfAvhSXZFnCfnTRKLp0F9VH3ysC+oP9QXyf7azZGLCcjeRhK NsEpPvsxm5cGqU+AuUlp8iIIPB7xZpKCfaN68zqUR1UuI5szbyvh5/ttfJhWFkrQUe6L YzQg== X-Received: by 10.180.78.199 with SMTP id d7mr5135589wix.94.1431167093786; Sat, 09 May 2015 03:24:53 -0700 (PDT) Received: from localhost ([91.225.203.160]) by mx.google.com with ESMTPSA id 16sm12641332wjs.41.2015.05.09.03.24.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2015 03:24:53 -0700 (PDT) Date: Sat, 9 May 2015 13:24:51 +0300 From: Mykola Golub To: Daisuke Aoyama Cc: freebsd-current@freebsd.org Subject: Re: hastd fail and panic on MAXPHYS=1m Message-ID: <20150509102450.GA35014@gmail.com> References: <8A0CADA1C80C4310BFFA1828554F473C@ad.peach.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A0CADA1C80C4310BFFA1828554F473C@ad.peach.ne.jp> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 10:24:56 -0000 On Fri, May 08, 2015 at 06:02:03AM +0900, Daisuke Aoyama wrote: > Hi all, > > I have problem with MAXPHYS=1m. (I don't know MAXPHYS=1m works on HAST.) > > I put "options MAXPHYS=(1024*1024)" in kernel config. > Then, update primary node to the kernel and world. > If the role back to primary on the machine, writing to the hast device cause an error and panic. > > I didn't check carefully, but it seems that geom_gate.ko use MAXPHYS=1m and hastd use > MAXPHYS=128k. > Of course, secondary is MAXPHYS=128k at this time. > > Is it an expected result? Putting "options MAXPHYS..." in kernel config does not change the value for userspace (hastd). You might want to try adding to make.conf: CFLAGS += -DMAXPHYS=1048576 and rebuild userspace (or just hastd). Also, running the secondary with smaller MAXPHYS will likely fail too. If you can't reinstall simultaneously I suggest running only the updated primary (don't starting the secondary) until the secondary is updated. -- Mykola Golub From owner-freebsd-current@FreeBSD.ORG Sat May 9 14:27:53 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2427B6D for ; Sat, 9 May 2015 14:27:53 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82C171C6F for ; Sat, 9 May 2015 14:27:52 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t49ERpIl049669 for ; Sat, 9 May 2015 07:27:51 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t49ERpXm049668 for current@freebsd.org; Sat, 9 May 2015 07:27:51 -0700 (PDT) (envelope-from david) Date: Sat, 9 May 2015 07:27:51 -0700 From: David Wolfskill To: current@freebsd.org Subject: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again Message-ID: <20150509142751.GV1158@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="quHH9trqkXa1YO4R" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 14:27:53 -0000 --quHH9trqkXa1YO4R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ref. -- similar symptoms. And again, I captured screenshots on a phone, but FreeBSD doesn't seem to recognize the (USB-attached) phone as something that might act like a file system (I guess; I'm a bit new to "smartphones"). In this case, my starting-point was r282623; sources were updated to r282676. I was able to update from: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #55 r28262= 3M/282623:1100072: Fri May 8 05:40:49 PDT 2015 root@g1-254.catwhisker.= org:/common/S3/obj/usr/src/sys/CANARY amd64 to FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r28267= 6M/282676:1100073: Sat May 9 05:50:15 PDT 2015 root@g1-254.catwhisker.= org:/common/S3/obj/usr/src/sys/CANARY amd64 without incident, but the update from: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1590 r282= 623M/282623:1100072: Fri May 8 06:40:11 PDT 2015 root@g1-254.catwhiske= r.org:/common/S4/obj/usr/src/sys/CANARY i386 was only able to build; the panic occurs before we've found any disks, so I can't get a crash dump. I do have a kdb prompt, though, so if someone has a suggestion for something to check, please let me know. (Mind, reading email will be rather awkward while the laptop is exploring the mysteries of a panic, so that might be worth bearing in mind.) Just prior to the bactrace, I see: =2E.. hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r =3D 0 (0xcfef... src/sys/dev/sound/pci/hda/hdaa.c:1571 The most recent relevant entries in the backtrace are: hdaa_configure() hdaa_attach() device_attach() bus_generic_attach() hdacc_attach() device_attach() bus_generic_attach() hdac_attach2() run_interrupt_driven_config_hooks() boot_interrupt_driven_config_hooks() mi_startup() begin() The panic message is "fatal trap 12: page fault while in kernel mode" =2E.. fault code =3D supervisor read, page not present =2E.. current process =3D 0 (swapper) =2E.. Stopped at ... =3D hdaa_configure+0x14af: movb 0x3,%dl The only commit I see in the range from r282623 - r282676 that looks as if it might be implicated to me is r282650, but I don't see anything glaringly obvious. Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --quHH9trqkXa1YO4R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVThlnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7PyoP+QGC66mEOeeA98pdHmrpn/Vf VaG2AxXh/EMNa9HcWW7KkahoPibddgW8LNafX5A+mYUNd9B1CCtc8IDhxewGmKgy jZ5GfPChYL1fQDGDyGl6fTKnRdksoxrEuCITP74+/1ivZn73XeDtXRWVUB+VwAg4 WUiFWBju/sh1POF88MC0ShZ5qhR3CyFMZbhF8TildSgo6+rqiWZLrgeJwGmEdhAJ uNk/JMr0yhUhGdBtENp0P1mNZBS0PTbwIBxiwWTzsO3wdV11bkwKq4+63lEOJxQs nr4qJEps09AsmbuRsTN4M8PLm8+YqpAWGP8SveX9XTMwDzYxKPLY+yDzwtAAPyMn 36zcN1GyRtdXKKZgF8uV7/uDyzVZHCZaviZGrd8IT90hHT/ESEjFmOSF3xwvKV+F /lmhge6n8IkwvmcsjYEdQgO9di8FrKbYq0UXg/G7CGk/2LINWELYWCuFsuObxPra oNv+XhtwcqBynhDILsXXJ7X6zVntjIEDbc1KBOQwa7smQvEIr7xPTAxUGlyoCf0i 3d5d/nRstXsZ6skkhWOJIjZ22ldyW7b4nxNhL+jkjAHqKkjr6idOWYZ12DQGT8oa U08pH677HacstdNZmlY7IR96fI9nu66i39k5n+yIBjsB3pozLrimNuhijVuCFmSM 8u0vnF/dgG8Nfylz5x8R =4WzT -----END PGP SIGNATURE----- --quHH9trqkXa1YO4R-- From owner-freebsd-current@FreeBSD.ORG Sat May 9 15:04:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A9E64F8 for ; Sat, 9 May 2015 15:04:58 +0000 (UTC) Received: from nm37-vm1.bullet.mail.bf1.yahoo.com (nm37-vm1.bullet.mail.bf1.yahoo.com [72.30.238.201]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14A95106C for ; Sat, 9 May 2015 15:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1431183896; bh=CWYNwWQVJG8T17LMCHRYie4jiyApnpTy31dFj9Guhf0=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=Aq4FBl7SUZP3/k/fHvWOgJTYwfIpxYDaitKtv23wUuE9Y5cw3OqqzBru40qPGUmtN2NnV6u1jTGz+Q5am7iQ55nd+NuMCQGxeh9xomhhNO4q6h873l7ABeUacSmxG1FA+gg+9aBgV7wUOAqWcwHMT6qppH0lfbbN+nkq7qKn6VS2tS9fOggsSBieFPc7gU+Byz/o7PDGPEDp7EqUcK8RDTQ1KqnBQzUi4YXOENm8ZLi+oQJ8QzjwSjalxpoAurH+9e9nriW4VS1vpG9Zgjeq8gPzX/l9goukh9e93l5nS+Ydr66qdp7ECy54F2Ocej560mSFrK80k2r9z+kzj7AJPg== Received: from [98.139.170.180] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 09 May 2015 15:04:56 -0000 Received: from [98.139.211.201] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 09 May 2015 15:04:56 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 09 May 2015 15:04:56 -0000 X-Yahoo-Newman-Id: 286474.48825.bm@smtp210.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aCtXirsVM1nAeodw7kkqtVfiB1wHkcAJeeE8SM8eAdVbtN4 4LQH4Rqe_oCZFgWVp_0IhCXLqJVfS2hdhGLpC.bTanonrMlKzdcII4nDnxDs qFZK7..tWT4Wv_xf9bEcjPqzDN16eYg790PabLfDDxp67FJ2j8CWKEzq4keD FegIBnz.6MmCBwHrCXt4UtzDjFisvFK1AC1jfVR.Bx5ypx1m9IsmEBztkxym NSB0fuzYPaz3CPOMr4GYXr.q47FieIeL4Ft7sT7rqqI6zrGd7KD9OaAy7_nv 6OU12M95tCMwbf8Jr1RxgpE2kn5tderPOK4hXsneTtBASjbxQCZ8l1tN3oqA oLhXDbujG5xFDa3HEdu1hY7w1Rb.ScuPRcQ0Fj7d_h4Ka20d1dzjjfIFyEkE AgLrZe2i1rY00yEaN8m2iYJiU3yX_wd3_bgSAzYKUKyJAlUJI_EmjvKwRlEo 3VxVvvxfDq54p3wmKO5_D6KAaFq4L.8lUjTZXqac1wntTFQloMHY2HiFUVWW DVIct6uArIDPbIW6Xldj4WrC9GKxeVuQE X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <554E2221.1040105@FreeBSD.org> Date: Sat, 09 May 2015 10:05:05 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Davide Italiano CC: John Baldwin , freebsd-current , NGie Cooper , Lyndon Nerenberg Subject: Re: What to do about RCS/OpenRCS References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 15:04:58 -0000 On 05/08/15 15:59, Davide Italiano wrote: > On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni wrote: >> Hi; >> >> >>> I guess I see the following options: >>> >>> 1) Just leave GNU RCS in the tree. >>> >>> 2) Improve OpenRCS so it can be swapped in. >>> >>> 3) Remove RCS dependencies from other parts of the tree (e.g. >>> etcupdate) >>> and import just a /bin/ident binary (perhaps from OpenRCS). >>> >>> Both 2) and 3) require some work. I suspect 3) requires less. :) >> >> I honestly don't see a real problem with (1): we do want to replace as much >> GNU >> software as we can but not at the cost of making our life unnecessarily >> difficult. >> > To be honest I'm not entirely sure what's the real reason of this > crusade. FreeBSD can't import newer version of some components of the > toolchain (e.g. compiler, linker, debugger) and some of them are > slowly (or less slowly) bitrotting. I feel that in that case there's a > real goal which justifies all the headache derived from the > conversion. Having a consistent license for all the OS has important advantages. The main principle is that while we are fine about sharing and having other people re-use our code we don't really want to have to check with a lawyer before taking any decision. Some years ago, this was basically impossible due to the toolchain, now it seems possible although it certainly requires more work. > For GNU RCS, I'm not completely sure there is. I've never > heard anybody complaining about lack of features for RCS or bugs. > My $0.02, I suspect very few people really rely on it and just > complain for the sake of doing it, but I'm not gonna argue on this > further. I think there are legitimate reasons for having it in base. > That said, unfortunately there's a lot more than doing the conversion > and fixing the code so that the testsuite will pass. > You need to upstream the fixes and so deal with another layer and > other maintainers otherwise the code in base and the one upstream will > diverge. We do that with GNU code anyways. The latest (GPLv3) version of RCS has already diverged and is incompatible for some third party software so we basically ran out of support from upstream. OpenRCS has it's own share of problems but generally we can work with the OpenBSD maintainers to get things to improve. I think I found the issue at hand and the code has an /* XXX: This is wrong ... */ Which doesn't really get me nearer to a solution but at least upstream knows where to look. We can wait. > People rely from time to time on bugs of old software (e.g. single vs > double dash options) and are gonna complain. > The testsuite, even if comprehensive, unlikely will cover some corner > cases and suddenly software will start breaking. In other words, a lot > of (unneeded) work for you for a software that just worked fine(TM) > until yesterday. > I'm not gonna stop you from doing this, but I learned the hard way > that it's something that can/should be avoided unless really necessary > (and a better license doesn't seem to be a strong enough reason, > IMHO). > No one (or at least not me) is going to replace GNU RCS with something of considerable less quality just for the license. Pedro. From owner-freebsd-current@FreeBSD.ORG Sat May 9 17:31:51 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E50F6BB0 for ; Sat, 9 May 2015 17:31:51 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ftp.orthanc.ca", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC8FC1EC2 for ; Sat, 9 May 2015 17:31:51 +0000 (UTC) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.9/8.14.9) with ESMTP id t49HVlNB015551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 9 May 2015 10:31:49 -0700 (PDT) (envelope-from lyndon@orthanc.ca) From: Lyndon Nerenberg Content-Type: multipart/signed; boundary="Apple-Mail=_62553C5E-DC82-4F30-B802-A3439F39C50E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What to do about RCS/OpenRCS Date: Sat, 9 May 2015 10:31:47 -0700 References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> To: freebsd-current Current In-Reply-To: <554E2221.1040105@FreeBSD.org> X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:31:52 -0000 --Apple-Mail=_62553C5E-DC82-4F30-B802-A3439F39C50E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 9, 2015, at 8:05 AM, Pedro Giffuni wrote: > We do that with GNU code anyways. The latest (GPLv3) version > of RCS has already diverged and is incompatible for some third > party software so we basically ran out of support from upstream. > OpenRCS has it's own share of problems but generally we can work > with the OpenBSD maintainers to get things to improve. But really, how often does the RCS code change? This is a piece of = software you get running once, and then leave alone. The last thing we = want is for it to start growing "features" :-P There seems to be an ever-increasing paranoia about adopting code in the = base. Are we going to end up at the point where /usr/src/ is nothing = but a bunch of Makefiles with VPATH pointed at /usr/src/contrib? I get = it for large outside components that are moving targets (e.g. llvm). = But RCS? I think the paranoia might be a bit overdone in this case. --lyndon --Apple-Mail=_62553C5E-DC82-4F30-B802-A3439F39C50E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJVTkSDAAoJEG8PnXiV/JnU2rgP/jZLVABooFki6wGme+I6wEFt 2v5Nr/bu6b6y63ZZV5vLKAZ+2sDCXdRSOx8DKvdc3vhowffNrqG1y1dSzOnC16j5 6dkO/ZYL4JbkEJA+lG4FibKp3kH7GwCImcEP1UJhDpJ4l7uuPcrvm5wKghIcdrdP qlLyWL9k7Xlbch36NB+IIOLSOnBfQzV++dh9IlYoA36g0dP/OKtdl2RiejnUNW3S VtDFDz5cadghGwCEfJvBHObjZWlsPANohpFD6a+iGHHRWrLA8ZlNtvf4BYwNNJuL zoXc21C4s++6ht5kdNIw4Nua6wPGRmqiQGkfz3tfFkTsKzau/HXtYaxppp+k6ip7 6/CL++vltO/djXeV9oM2tk8qonU8vIW3mBN68J8YjX37ld/WFEddZPAcRGw8R3tt SrueNVqeiw5SE5J93RTipyfbSlzxktnmn7ayA63tDtKXE0OipHFI3fmgA34+/Lcg gZw4yb0Q3MfTHfOwQWAyXK7pFtTKsfuWOvl+MMREaVncQk/1NQNWL/mIsJjyUphU aO/7HJlhQgpWfb0FC+2PQdDKMNdDD/bDhE/urC6o0oawcW/4GnAm0qfk7j05CBpf DxzVaSAp558zrgUqpE72lNuPS7QrkyOPVEEcOrylZMlAKEkHayK3HZtMDtk1qmyx Hg/JchnsEbj6ofOLIYtA =XmdN -----END PGP SIGNATURE----- --Apple-Mail=_62553C5E-DC82-4F30-B802-A3439F39C50E-- From owner-freebsd-current@FreeBSD.ORG Sat May 9 18:28:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D97E197 for ; Sat, 9 May 2015 18:28:05 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E923E1392 for ; Sat, 9 May 2015 18:28:04 +0000 (UTC) Received: by pdbqa5 with SMTP id qa5so111479264pdb.1 for ; Sat, 09 May 2015 11:27:58 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=/wfD6hfgrN5HPjJHmsssr7t9nV341XNw5vt2WlKxjZY=; b=JGqXisin/7VmYuRMNM5zP4L55mrn5o9GQlxz9eQnI1DWOPWV91dzRt2IIKAlW62qZu 0v240VnlEGZ5wllY+7WELlopXJ3nsTeTQXlJ+C9OvWdNdsy+3dWdZxBwNXwQaZ/zFrS+ GRNpD8sbPgMC326rFqgnUi0N5J1xZ/dFndtwC74gtbx92LiHLeD20DAfIJGKpkiyQ4Hx 6pSlzI4bXyCYU0HUMYZeYftsJwWYYauMbPx7Gan+TP0Ot0EBbZdYZ8deOMEHmbvVS+n0 gv53B2Cm7IV+Nqbqm6SdiD3YpwSyyD5kPCd1ba8S9IoStMijHa96kmonjXqbFtF/8T8b CRuw== X-Gm-Message-State: ALoCoQlWj1Lxg0qjO3hQL6L3tfQrqIWh3ymNgCHIrCcLJ/7PZV5zspR23TQfbqd2txM1E9l9z6na MIME-Version: 1.0 X-Received: by 10.70.136.169 with SMTP id qb9mr6355886pdb.46.1431196078408; Sat, 09 May 2015 11:27:58 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Sat, 9 May 2015 11:27:57 -0700 (PDT) Received: by 10.70.102.99 with HTTP; Sat, 9 May 2015 11:27:57 -0700 (PDT) In-Reply-To: References: <554BB84F.7060605@FreeBSD.org> <554BCD4C.8090500@FreeBSD.org> <3137063.YOSa6Au8Xi@ralph.baldwin.cx> <554D1DD5.5080106@FreeBSD.org> <554E2221.1040105@FreeBSD.org> Date: Sat, 9 May 2015 11:27:57 -0700 Message-ID: Subject: Re: What to do about RCS/OpenRCS From: Jos Backus To: Lyndon Nerenberg Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 18:28:05 -0000 Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. Jos From owner-freebsd-current@FreeBSD.ORG Sat May 9 20:53:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89870904 for ; Sat, 9 May 2015 20:53:12 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FA601208 for ; Sat, 9 May 2015 20:53:11 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t49Kqkpx091547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 9 May 2015 22:52:47 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t49L5QLF081358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 9 May 2015 23:05:26 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.9/8.14.9/Submit) id t49L5Qna081357 for freebsd-current@freebsd.org; Sat, 9 May 2015 23:05:26 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sat, 9 May 2015 23:05:26 +0200 From: Wolfgang Zenker To: freebsd-current@freebsd.org Subject: Re: Race VT+X11 on -current Message-ID: <20150509210525.GA80848@lyxys.ka.sub.org> References: <554B5D11.3080709@selasky.org> <554BC475.50203@selasky.org> <554BD2A8.70702@selasky.org> <554C3CCB.3030809@selasky.org> <4937E44E-C0EF-4052-961C-F46D5EC5BE00@gmail.com> <554C8AEB.2080502@selasky.org> <554CC841.60908@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554CC841.60908@freebsd.org> Organization: private site User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sat, 09 May 2015 22:52:47 +0200 (CEST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 20:53:12 -0000 * Allan Jude [150508 16:29]: > [..] > My experience is a little different. > When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) > Sometimes when I resume, it seems like the keyboard is frozen. If I > alt+f1, then alt+f9, it seems to work fine after that. I'd never though > of trying just alt+f9 right away, as I could already see my X session. > Not sure if this is related, but it sounds very similar. Similar problem on 10-STABLE: I usually start X by running startx on ttyv0. After exiting X screen shows ttyv0 again but keyboard appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to ttyv1 and back "unfreezes" keyboard. Wolfgang