From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 00:42:38 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 9928CF79; Sun, 19 Apr 2015 00:42:38 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::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 59D2CA38; Sun, 19 Apr 2015 00:42:38 +0000 (UTC) Received: by qcbii10 with SMTP id ii10so42203168qcb.2; Sat, 18 Apr 2015 17:42:37 -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=ScRCKLtewcZ64RfDUD5XSXibYMGqhbcet2VZBMWzJ/w=; b=cB5ibmaq19Ck5dIJVur3Ip2miOZW3b2YiULexC7c9mAtC2aRgwMfzC9Y7QM2TLKsSy GHSfAQfgwc8VD3IJ24aT9nr5madd+rp+NMglRASf4NxrVf8+JBzPcceBVwwCmwxLSOXO mSFCMUYiNFK7RvfcNLgOFgMGfSQ2D0qH+FsPonTUnoVMi/ZpVdQOJN/kG9fkZ708QeKX ogbw7kVF1vlV1OS8iJL9Ew0FBkkNiUTWJXotALXSNzxKb3bsTFjSqflV2MRSR2dBVxc6 WvMsemEHOjVu7LxLt3zZpS8BNtUvuzg9KedB7l9SGX3kPGCobw0OZ9ALdvgNMKarTNhe zUSw== MIME-Version: 1.0 X-Received: by 10.140.80.170 with SMTP id c39mr10875848qgd.55.1429404157363; Sat, 18 Apr 2015 17:42:37 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.140.84.179 with HTTP; Sat, 18 Apr 2015 17:42:36 -0700 (PDT) Received: by 10.140.84.179 with HTTP; Sat, 18 Apr 2015 17:42:36 -0700 (PDT) In-Reply-To: References: <241191209.26.1429397785855.JavaMail.jenkins@jenkins-9.freebsd.org> <5F0168F7-4968-4E2E-AD5C-B408540D1963@gmail.com> Date: Sat, 18 Apr 2015 17:42:36 -0700 X-Google-Sender-Auth: 2cLXAtIEr0Ob4h-RbTP1ivvejeI Message-ID: Subject: Re: Build failed in Jenkins: FreeBSD_HEAD #2663 From: Justin Hibbits To: Garrett Cooper Cc: "sjg@FreeBSD.org" , jenkins-admin@freebsd.org, "mav@FreeBSD.org" , "rpaulo@FreeBSD.org" , "markj@FreeBSD.org" , FreeBSD Current , "kib@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: Sun, 19 Apr 2015 00:42:38 -0000 Sorry about that. Forgot the pmc.h changes. -Justin On Apr 18, 2015 4:53 PM, "Justin Hibbits" wrote: > Crap, sorry. I wonder how that compiled fine for me. I'll fix it in a > couple hours when I get home. > > -Justin > On Apr 18, 2015 4:49 PM, "Garrett Cooper" wrote: > >> >> > On Apr 18, 2015, at 15:56, jenkins-admin@freebsd.org wrote: >> >> >> > ===> lib/libpmc (all) >> > --- libpmc.So --- >> > cc -fpic -DPIC -O2 -pipe -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter >> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations >> -Wthread-safety -Wno-empty-body -Wno-string-plus-int >> -Wno-unused-const-variable -Qunused-arguments -c < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/libpmc.c> -o >> libpmc.So >> > --- pmclog.So --- >> > cc -fpic -DPIC -O2 -pipe -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type >> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter >> -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls >> -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations >> -Wthread-safety -Wno-empty-body -Wno-string-plus-int >> -Wno-unused-const-variable -Qunused-arguments -c < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libpmc/pmclog.c> -o >> pmclog.So >> > --- libpmc.So --- >> > :302:1: >> error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean >> 'PMC_CLASS_P5'? >> > PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500, >> PMC_CLASS_TSC); >> > ^ >> > :273:3: >> note: expanded from macro 'PMC_MDEP_TABLE' >> > PMC_CLASS_##C, __VA_ARGS__ \ >> > ^ >> > :64:1: note: expanded from here >> > PMC_CLASS_E500 >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:144:2: >> note: 'PMC_CLASS_P5' declared here >> > __PMC_CLASSES() >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:125:2: >> note: expanded from macro '__PMC_CLASSES' >> > __PMC_CLASS(P5) /* Intel Pentium counters */ \ >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:143:24: >> note: expanded from macro '__PMC_CLASS' >> > #define __PMC_CLASS(N) PMC_CLASS_##N , >> > ^ >> > :46:1: note: expanded from here >> > PMC_CLASS_P5 >> > ^ >> > :302:44: >> error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean >> 'PMC_CLASS_P5'? >> > PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500, >> PMC_CLASS_TSC); >> > ^~~~~~~~~~~~~~ >> > PMC_CLASS_P5 >> > :273:18: >> note: expanded from macro 'PMC_MDEP_TABLE' >> > PMC_CLASS_##C, __VA_ARGS__ \ >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:144:2: >> note: 'PMC_CLASS_P5' declared here >> > __PMC_CLASSES() >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:125:2: >> note: expanded from macro '__PMC_CLASSES' >> > __PMC_CLASS(P5) /* Intel Pentium counters */ \ >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:143:24: >> note: expanded from macro '__PMC_CLASS' >> > #define __PMC_CLASS(N) PMC_CLASS_##N , >> > ^ >> > :46:1: note: expanded from here >> > PMC_CLASS_P5 >> > ^ >> > :2961:7: >> error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean >> 'PMC_CLASS_P5'? >> > case PMC_CLASS_E500: >> > ^~~~~~~~~~~~~~ >> > PMC_CLASS_P5 >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:144:2: >> note: 'PMC_CLASS_P5' declared here >> > __PMC_CLASSES() >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:125:2: >> note: expanded from macro '__PMC_CLASSES' >> > __PMC_CLASS(P5) /* Intel Pentium counters */ \ >> > ^ >> > < >> https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/tmp/usr/include/sys/pmc.h>:143:24: >> note: expanded from macro '__PMC_CLASS' >> > #define __PMC_CLASS(N) PMC_CLASS_##N , >> > ^ >> > :46:1: note: expanded from here >> > PMC_CLASS_P5 >> > ^ >> > :2961:7: >> error: duplicate case value 'PMC_CLASS_P5' >> > case PMC_CLASS_E500: >> > ^ >> > :2925:7: >> note: previous case defined here >> > case PMC_CLASS_P5: >> > ^ >> > 4 errors generated. >> > *** [libpmc.So] Error code 1 >> >> r281713 broke the build :(.. > > From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 01:50: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 79BA36F4; Sun, 19 Apr 2015 01:50:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 62A9EF30; Sun, 19 Apr 2015 01:50:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 94A9D5C9; Sun, 19 Apr 2015 01:50:58 +0000 (UTC) Date: Sun, 19 Apr 2015 01:50:58 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kib@FreeBSD.org, rpaulo@FreeBSD.org, mav@FreeBSD.org, alc@FreeBSD.org, markj@FreeBSD.org, bdrewery@FreeBSD.org, sjg@FreeBSD.org, jhibbits@FreeBSD.org, eadler@FreeBSD.org Message-ID: <1762920807.27.1429408258348.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <241191209.26.1429397785855.JavaMail.jenkins@jenkins-9.freebsd.org> References: <241191209.26.1429397785855.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2664 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-Mailman-Approved-At: Sun, 19 Apr 2015 03:09:18 +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: Sun, 19 Apr 2015 01:50:58 -0000 See Changes: [alc] Eliminate an unused variable. MFC after:=091 week [eadler] bin/ed: use correct type in multiplication =09The result is line_t** so the multiplication should be size * =09sizeof(line_t*) MFC After:=091 month [bdrewery] sh: Fix the trap builtin to be POSIX-compliant for 'trap exit SI= G' and 'trap n n...'. The parser considered 'trap exit INT' to reset the default for both EXIT an= d INT. This beahvior is not POSIX compliant. This was avoided if a value was specified for 'exit', but then disallows exiting with the signal received. = A possible workaround is using ' exit'. However POSIX does allow this type of behavior if the parameters are all integers. Fix the handling for this and clarify its support in the manpage since it is specifically allowed by POSIX. Differential Revision:=09https://reviews.freebsd.org/D2325 Reviewed by:=09jilles MFC after:=092 weeks ------------------------------------------ [...truncated 108947 lines...] --- all_subdir_libdwarf --- --- dwarf_pro_weaks.So --- cc -fpic -DPIC -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-hea= ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite= -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscript= s -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-p= ointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c dwar= f_pro_weaks.c -o dwarf_pro_weaks.So --- all_subdir_libmilter --- --- sm_gethost.o --- cc -O2 -pipe -I -I -I. -DNOT_SENDMAIL= -Dsm_snprintf=3Dsnprintf -D_THREAD_SAFE -DSM_CONF_POLL -DNETINET6 -std=3D= gnu99 -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter= -Wno-parentheses -Qunused-arguments -c = -o sm_gethost.o --- all_subdir_libdwarf --- --- dwarf_pubnames.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror= -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissi= ng-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Ws= witch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -= Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string= -plus-int -Wno-unused-const-variable -Qunused-arguments -c dwarf_pubnames.c= -o dwarf_pubnames.o --- all_subdir_libnetgraph --- --- debug.So --- cc -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsystem-header= s -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign= -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tauto= logical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-fun= ction -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c = -= o debug.So --- all_subdir_libmilter --- --- errstring.o --- cc -O2 -pipe -I -I -I. -DNOT_SENDMAIL= -Dsm_snprintf=3Dsnprintf -D_THREAD_SAFE -DSM_CONF_POLL -DNETINET6 -std=3D= gnu99 -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter= -Wno-parentheses -Qunused-arguments -c -o er= rstring.o --- all_subdir_libngatm --- =3D=3D=3D> lib/libngatm (all) --- all_subdir_libmilter --- --- strl.o --- cc -O2 -pipe -I -I -I. -DNOT_SENDMAIL= -Dsm_snprintf=3Dsnprintf -D_THREAD_SAFE -DSM_CONF_POLL -DNETINET6 -std=3D= gnu99 -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter= -Wno-parentheses -Qunused-arguments -c -o strl.o --- all_subdir_libdwarf --- --- dwarf_pubnames.So --- cc -fpic -DPIC -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-hea= ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite= -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscript= s -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-p= ointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c dwar= f_pubnames.c -o dwarf_pubnames.So --- all_subdir_libmilter --- --- worker.o --- cc -O2 -pipe -I -I -I. -DNOT_SENDMAIL= -Dsm_snprintf=3Dsnprintf -D_THREAD_SAFE -DSM_CONF_POLL -DNETINET6 -std=3D= gnu99 -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter= -Wno-parentheses -Qunused-arguments -c -o w= orker.o --- all_subdir_libdwarf --- --- dwarf_pubtypes.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror= -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissi= ng-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Ws= witch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -= Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string= -plus-int -Wno-unused-const-variable -Qunused-arguments -c dwarf_pubtypes.c= -o dwarf_pubtypes.o --- all_subdir_libngatm --- --- unimsg.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -o unimsg= .So --- all_subdir_libmilter --- --- libmilter.so.5 --- building shared library libmilter.so.5 cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-share= d-textrel -o libmilter.so.5 -Wl,-soname,libmilter.so.5 `NM=3D'nm' lorder = main.So engine.So listener.So handler.So comm.So monitor.So smfi.So signal.= So sm_gethost.So errstring.So strl.So worker.So | tsort -q`=20 --- all_subdir_libdwarf --- --- dwarf_pubtypes.So --- cc -fpic -DPIC -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-hea= ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite= -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscript= s -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-p= ointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c dwar= f_pubtypes.c -o dwarf_pubtypes.So --- all_subdir_libngatm --- --- unimsg_common.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -o unimsg_common.So --- all_subdir_libnetgraph --- --- sock.o --- cc -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= all -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-= prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-comp= are -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num-conversion -Wno-unused-local-typedef -Qunused-arguments -c -o sock.o --- all_subdir_libmilter --- --- libmilter.a --- building static milter library --- all_subdir_libngatm --- --- straddr.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c = -o straddr.So --- all_subdir_libdwarf --- --- dwarf_types.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror= -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissi= ng-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Ws= witch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -= Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string= -plus-int -Wno-unused-const-variable -Qunused-arguments -c dwarf_types.c -o= dwarf_types.o --- all_subdir_libmilter --- ranlib -D libmilter.a --- all_subdir_libnetgraph --- --- msg.o --- cc -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= all -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-= prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-comp= are -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num-conversion -Wno-unused-local-typedef -Qunused-arguments -c -o msg.o --- all_subdir_libngatm --- --- traffic.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -= o traffic.So --- all_subdir_libnetgraph --- --- debug.o --- cc -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= all -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-= prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-comp= are -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num-conversion -Wno-unused-local-typedef -Qunused-arguments -c -o debug.o --- all_subdir_libdwarf --- --- dwarf_types.So --- cc -fpic -DPIC -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-hea= ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite= -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscript= s -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-p= ointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c dwar= f_types.c -o dwarf_types.So --- dwarf_vars.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror= -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissi= ng-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Ws= witch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -= Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string= -plus-int -Wno-unused-const-variable -Qunused-arguments -c dwarf_vars.c -o = dwarf_vars.o --- all_subdir_libnetgraph --- --- libnetgraph.so.4 --- building shared library libnetgraph.so.4 cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-share= d-textrel -o libnetgraph.so.4 -Wl,-soname,libnetgraph.so.4 `NM=3D'nm' lor= der sock.So msg.So debug.So | tsort -q`=20 --- all_subdir_libngatm --- --- uni_ie.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -o= uni_ie.So --- all_subdir_libdwarf --- --- dwarf_vars.So --- cc -fpic -DPIC -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-hea= ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite= -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscript= s -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-p= ointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c dwar= f_vars.c -o dwarf_vars.So --- all_subdir_libnv --- =3D=3D=3D> lib/libnv (all) --- all_subdir_libnetgraph --- --- libnetgraph.a --- building static netgraph library --- all_subdir_libdwarf --- --- dwarf_weaks.o --- cc -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror= -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissi= ng-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Ws= witch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -= Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string= -plus-int -Wno-unused-const-variable -Qunused-arguments -c dwarf_weaks.c -o= dwarf_weaks.o --- dwarf_weaks.So --- --- all_subdir_libnetgraph --- ranlib -D libnetgraph.a --- all_subdir_libdwarf --- cc -fpic -DPIC -O2 -pipe -I. -I -I -I -std=3Dgnu99 -fstack-protector -Wsystem-hea= ders -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite= -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscript= s -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-p= ointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body= -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c dwar= f_weaks.c -o dwarf_weaks.So --- all_subdir_libngatm --- --- uni_msg.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -= o uni_msg.So --- saal_sscop.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -o saal_sscop.So --- all_subdir_libdwarf --- --- libdwarf.a --- building static dwarf library ranlib -D libdwarf.a --- libdwarf.so.4 --- building shared library libdwarf.so.4 cc -fstack-protector -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-share= d-textrel -o libdwarf.so.4 -Wl,-soname,libdwarf.so.4 `NM=3D'nm' lorder dw= arf_abbrev.So dwarf_arange.So dwarf_attr.So dwarf_attrval.So dwarf_cu.So dw= arf_dealloc.So dwarf_die.So dwarf_dump.So dwarf_errmsg.So dwarf_finish.So d= warf_form.So dwarf_frame.So dwarf_funcs.So dwarf_init.So dwarf_lineno.So dw= arf_loclist.So dwarf_macinfo.So dwarf_pro_arange.So dwarf_pro_attr.So dwarf= _pro_die.So dwarf_pro_expr.So dwarf_pro_finish.So dwarf_pro_frame.So dwarf_= pro_funcs.So dwarf_pro_init.So dwarf_pro_lineno.So dwarf_pro_macinfo.So dwa= rf_pro_pubnames.So dwarf_pro_reloc.So dwarf_pro_sections.So dwarf_pro_types= .So dwarf_pro_vars.So dwarf_pro_weaks.So dwarf_pubnames.So dwarf_pubtypes.S= o dwarf_ranges.So dwarf_reloc.So dwarf_sections.So dwarf_seterror.So dwarf_= str.So dwarf_types.So dwarf_vars.So dwarf_weaks.So libdwarf.So libdwarf_abb= rev.So libdwarf_arange.So libdwarf_attr.So libdwarf_die.So libdwarf_error.S= o libdwarf_elf_access.So libdwarf_elf_init.So libdwarf_frame.So libdwarf_in= fo.So libdwarf_init.So libdwarf_lineno.So libdwarf_loc.So libdwarf_loclist.= So libdwarf_macinfo.So libdwarf_nametbl.So libdwarf_ranges.So libdwarf_relo= c.So libdwarf_rw.So libdwarf_sections.So libdwarf_str.So | tsort -q` -lelf --- all_subdir_libngatm --- --- saal_sscfu.So --- cc -fpic -DPIC -O2 -pipe -I -I -I= -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-= y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wun= used-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wr= edundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-= declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Qunused-arguments -c -o saal_sscfu.So --- all_subdir_libohash --- =3D=3D=3D> lib/libohash (all) --- ohash.o --- cc -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -W= all -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-= prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-comp= are -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num-conversion -Wno-unused-local-typedef -Qunused-arguments -c -o ohash.o --- libohash.a --- building static ohash library ranlib -D libohash.a --- all_subdir_libopie --- =3D=3D=3D> lib/libopie (all) --- all_subdir_libpcap --- --- all_subdir_libpmc --- --- all_subdir_libpcap --- =3D=3D=3D> lib/libpcap (all) --- all_subdir_libpmc --- =3D=3D=3D> lib/libpmc (all) --- libpmc.So --- cc -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsystem-header= s -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-st= rings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -= Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-poin= ter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c -o libpmc.So --- all_subdir_libproc --- =3D=3D=3D> lib/libproc (all) --- all_subdir_libpcap --- --- pcap-bpf.So --- cc -fpic -DPIC -O2 -pipe -DHAVE_CONFIG_H -Dyylval=3Dpcapyylval -I -I. -D_U_=3D"__attr= ibute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -DINET6 -DHAVE_NET_PFVA= R_H -I -std=3Dgnu99 -fstack-protector -Wno-pointer-sign -Wno-empty-= body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-comp= are -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-= knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o pcap-bpf.So --- all_subdir_libpmc --- :302:1= : error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean 'PMC_C= LASS_P5'? PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500, PMC_CLASS_TSC); ^ :273:3= : note: expanded from macro 'PMC_MDEP_TABLE' PMC_CLASS_##C, __VA_ARGS__ \ ^ :64:1: note: expanded from here PMC_CLASS_E500 ^ :144:2: note: 'PMC_CLASS_P5' declared here __PMC_CLASSES() ^ :125:2: note: expanded from macro '__PMC_CLASSES' __PMC_CLASS(P5) /* Intel Pentium counters */ \ ^ :143:24: note: expanded from macro '__PMC_CLASS' #define __PMC_CLASS(N) PMC_CLASS_##N , ^ :46:1: note: expanded from here PMC_CLASS_P5 ^ :302:4= 4: error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean 'PMC_= CLASS_P5'? PMC_MDEP_TABLE(e500, E500, PMC_CLASS_SOFT, PMC_CLASS_E500, PMC_CLASS_TSC); ^~~~~~~~~~~~~~ PMC_CLASS_P5 :273:1= 8: note: expanded from macro 'PMC_MDEP_TABLE' PMC_CLASS_##C, __VA_ARGS__ \ ^ :144:2: note: 'PMC_CLASS_P5' declared here __PMC_CLASSES() ^ :125:2: note: expanded from macro '__PMC_CLASSES' __PMC_CLASS(P5) /* Intel Pentium counters */ \ ^ :143:24: note: expanded from macro '__PMC_CLASS' #define __PMC_CLASS(N) PMC_CLASS_##N , ^ :46:1: note: expanded from here PMC_CLASS_P5 ^ :2961:= 7: error: use of undeclared identifier 'PMC_CLASS_E500'; did you mean 'PMC_= CLASS_P5'? case PMC_CLASS_E500: ^~~~~~~~~~~~~~ PMC_CLASS_P5 :144:2: note: 'PMC_CLASS_P5' declared here __PMC_CLASSES() ^ :125:2: note: expanded from macro '__PMC_CLASSES' __PMC_CLASS(P5) /* Intel Pentium counters */ \ ^ :143:24: note: expanded from macro '__PMC_CLASS' #define __PMC_CLASS(N) PMC_CLASS_##N , ^ :46:1: note: expanded from here PMC_CLASS_P5 ^ :2961:= 7: error: duplicate case value 'PMC_CLASS_P5' case PMC_CLASS_E500: ^ :2925:= 7: note: previous case defined here case PMC_CLASS_P5: ^ 4 errors generated. *** [libpmc.So] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [all_subdir_libpmc] Error code 2 make[4]: stopped in --- all_subdir_libproc --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_libproc] Error code 2 make[4]: stopped in --- all_subdir_libpcap --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_libpcap] Error code 2 make[4]: stopped in --- all_subdir_libngatm --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_libngatm] Error code 2 make[4]: stopped in 4 errors make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] 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 Sun Apr 19 09:10:49 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 5F24028A for ; Sun, 19 Apr 2015 09:10:49 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::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 E5631DFC for ; Sun, 19 Apr 2015 09:10:48 +0000 (UTC) Received: by wgin8 with SMTP id n8so150597790wgi.0 for ; Sun, 19 Apr 2015 02:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jGf6EJebwz2ND6YXXKVas8GEARpT2ZW2sgqU85dzA2U=; b=VmL0//eKiIwYnFby8pyQyL5syY6DPJyIKtNiL1IS6H3A/s0U6hWZl61VjCE1M+STrP QAGeH9sbxi2ThXavxdMhEi9A7qUu23Dn3eoItGfSmbLTNdre3ERZKnHYbrHTdqB3eC3h 3See6NajWbnuH66XH4SAG4NYnjnaGyBZ2k6OM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jGf6EJebwz2ND6YXXKVas8GEARpT2ZW2sgqU85dzA2U=; b=HWhCVhpH9/GUUQ2qkJlfuvFj+a9SFj6FphA4wPtQFNLheni2SeoBmugjVTBzzWe+1g +nPAo+8YCX5SfKaP0oxPtfU06XGCF4lP26jXoU0vSnzz/5KJHnIGNwN8nmjh4xia3Uwp gOWkh/vUkC1OGSdz/hrUuaSCYoM3pvCSqEUjHVK8YRbn3EyMPL6q1Rlw6R5xgeQQqa2z JkFRN+kzvSvAViN4iprE3Smrgu5sUTY6ti9Jdxkd65m1at3WkAPM2r3+Z3hsrVO6yz3i Z5l0y+J9eG6tb7Vx31uleD0q0b2avTPBxGB683EnRky2oMHsAOmzVAU/lbCjPzvPUhyi //fw== X-Gm-Message-State: ALoCoQmZm99/8qnTMpOOcqcwDknagbfTgCBY86EARsa+XbpW4dKqmHTp195wityR0AH3NM78cyJg X-Received: by 10.194.237.34 with SMTP id uz2mr20632972wjc.157.1429434647286; Sun, 19 Apr 2015 02:10:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.135 with HTTP; Sun, 19 Apr 2015 02:10:16 -0700 (PDT) In-Reply-To: References: From: Eitan Adler Date: Sun, 19 Apr 2015 02:10:16 -0700 Message-ID: Subject: Re: [Request for Help] Reducing gcc 4.9 compilation warnings To: Craig Rodrigues Cc: freebsd-current Current , "freebsd-testing@freebsd.org" , FreeBSD Toolchain 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, 19 Apr 2015 09:10:49 -0000 " On 18 April 2015 at 11:12, Craig Rodrigues wrote: > Hi, > > After the latest commits by members of freebsd-toolchain@ , > I have managed to compile latest CURRENT world and GENERIC > kernel on amd64 with an gcc 4.9 external toolchain by doing: > > pkg install devel/amd64-xtoolchain-gcc > cd /usr/src > sed -i "" -e 's/boot2//' sys/boot/i386/Makefile > make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR= > make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR= > > > It was necessary to skip boot2 from building because of errors > reported here: > https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html > > The boot2 compilation errors still need to be worked on. > > However, most other things compile with warnings. If folks are > interested in looking at the warnings, you can see them here: > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/warnings17 > > Please look at these warnings, and if you see places to > patch the code to eliminate the warnings, please submit patches > and commit them if you can. Some time ago I tried to do something similar, but with gcc4.6 instead of gcc4.9. The vast majority of warnings (1548) are "unused-but-set-variable" and it may be worthwhile to just silence this warning, at least at low WARNS levels. It has caught real errors but is quite noisy and can cause quite a bit of churn. "inline" (count 515) is generally pure noise, and I think we should disable it. It can be helpful to find certain types of performance optimizations, but it should be opt-in. "strict-aliasing" (154) are likely all real bugs of some form. Very few exist in contrib code, and it would be good to fix them. "Warning" (111) seem to be a mix of warnings, but mostly in contrib code. "maybe-uninitialized" (111) is often noisy, and in a spot check were all false positives. "deprecated-declarations" (22) is all in contrib code Many of these are useful though and I've already fixed a few of the bugs reported. Perhaps it would be useful to do a second run of this, but with a modified share/mk to silence the most useless of these warnings? -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 07:00:44 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 776F7C1F; Sun, 19 Apr 2015 07:00:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 62741F98; Sun, 19 Apr 2015 07:00:44 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8B160659; Sun, 19 Apr 2015 07:00:44 +0000 (UTC) Date: Sun, 19 Apr 2015 07:00:44 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kib@FreeBSD.org, rpaulo@FreeBSD.org, alc@FreeBSD.org, mav@FreeBSD.org, markj@FreeBSD.org, bdrewery@FreeBSD.org, sjg@FreeBSD.org, jhibbits@FreeBSD.org, eadler@FreeBSD.org Message-ID: <384361773.29.1429426844067.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1762920807.27.1429408258348.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1762920807.27.1429408258348.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2665 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-Mailman-Approved-At: Sun, 19 Apr 2015 10:52:19 +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: Sun, 19 Apr 2015 07:00:44 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 11:22:20 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 4C127AAA; Sun, 19 Apr 2015 11:22:20 +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 C53C3D0B; Sun, 19 Apr 2015 11:22:19 +0000 (UTC) Received: by lbbuc2 with SMTP id uc2so111692835lbb.2; Sun, 19 Apr 2015 04:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F5uqIuXx77XeR9U85RPSOpJNLqWvZC1bu2pOM9tuTlU=; b=pwMu2cZfMTpa/yoYR8sKlLXm7fIqvnixSCdlCbvpYQBIyw7OqZNdf89ETqtrFTG433 Dr6noCK53+hgs9fnkja0zApsqi0/ONtIJpWDdIdAY1TOgaMhx7kPIcY2pJQFy8I+jbG4 UMjXlhbSepeeugzq2TUDwCaE5uqJt86ZKqH+pBpvjZ7FxukcBLY4Wa08OQLd2KiJjORU i6Tf+dtwH1NYZY6uOZKTGcUOG84AqT1nHIr7GP5N5LIKmP3fvKxq5bv5ZqE6XHJHvP97 IJUz+esk5/yYuhr6wtmBh3FP6imtg2InKIFZcL4Uw+4kzyYJFRMA7kdg/d+e23sj+FOW bM0Q== X-Received: by 10.112.211.167 with SMTP id nd7mr11582598lbc.62.1429442537582; Sun, 19 Apr 2015 04:22:17 -0700 (PDT) Received: from [10.0.1.6] (broadband-5-228-253-128.nationalcablenetworks.ru. [5.228.253.128]) by mx.google.com with ESMTPSA id ln6sm3609665lac.45.2015.04.19.04.22.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Apr 2015 04:22:17 -0700 (PDT) Sender: Dmitry Sivachenko Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: pkg 1.5.0 is out From: Dmitry Sivachenko In-Reply-To: <20150414200459.GE39658@ivaldir.etoilebsd.net> Date: Sun, 19 Apr 2015 14:22:15 +0300 Cc: ports@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F18CCA1-53B8-4590-9CD3-78FB63590D51@FreeBSD.org> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.2070.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, 19 Apr 2015 11:22:20 -0000 > On 14 =D0=B0=D0=BF=D1=80. 2015 =D0=B3., at 23:05, Baptiste Daroussin = wrote: >=20 > Final pkg 1.5.0 has been released. >=20 Thank a lot for working on pkg! >=20 > For pkg 1.6.0 among other things and depending on the time, here is = what we do > plan to work on: > - >=20 What I really miss a lot is support for package "profiles": an ability = to build the same port with different OPTIONs combination. For example: minimal nginx version; nginx version with passenger module (for puppet server) nginx version with some other rare options turned on for custom = application. Right now I achieve this with manually renaming /var/db/ports/*/options = files and some manipulations in /usr/ports/packages/All. But a framework to automatically handle this would be very useful. Thanks. From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 11:36:09 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 D244EECC; Sun, 19 Apr 2015 11:36:09 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 64D48E18; Sun, 19 Apr 2015 11:36:09 +0000 (UTC) Received: by widdi4 with SMTP id di4so68088832wid.0; Sun, 19 Apr 2015 04:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=uAO/MIQAx3Q1Idvle/yEBpX/170EmVg2pxKqtSj7Xa8=; b=AmFFgY6Hhg7V2kvVIx9ICbYyOGdToQsxslND86LPSHHJjVFTUz4rVeun7y7oULsK1T LgD9gdo76hGENF3ovHFPrAr59PJCdw4gN534Pxe3kF6s3qgVQY7fOED8DZAUnd6rFY6t iUXwqmNOkFJEyPq3YQl7BYDlKjnZdcqznv/4/AjJjujG2znck2UrSPV1UAa2XpODC0i5 aWwMQdKyS2peyJF2qa1hzpwnb2effaNiOG+pwltM75CE7TDw0mzmxLRWprxy070yQq+G 3daMntaF7wNzEBaGkRUSYyBeyet5Q6NMi//qj5n0nGfjYHQor3fnsB9iWprgrr2jsXdo c6mQ== X-Received: by 10.180.104.34 with SMTP id gb2mr15911486wib.95.1429443367863; Sun, 19 Apr 2015 04:36:07 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id e10sm10700341wij.11.2015.04.19.04.36.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 04:36:07 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 19 Apr 2015 13:36:05 +0200 From: Baptiste Daroussin To: Dmitry Sivachenko Cc: ports@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org Subject: Re: pkg 1.5.0 is out Message-ID: <20150419113605.GE960@ivaldir.etoilebsd.net> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <3F18CCA1-53B8-4590-9CD3-78FB63590D51@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u5E4XgoOPWr4PD9E" Content-Disposition: inline In-Reply-To: <3F18CCA1-53B8-4590-9CD3-78FB63590D51@FreeBSD.org> 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: Sun, 19 Apr 2015 11:36:10 -0000 --u5E4XgoOPWr4PD9E Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 19, 2015 at 02:22:15PM +0300, Dmitry Sivachenko wrote: >=20 > > On 14 =D0=B0=D0=BF=D1=80. 2015 =D0=B3., at 23:05, Baptiste Daroussin wrote: > >=20 > > Final pkg 1.5.0 has been released. > >=20 >=20 > Thank a lot for working on pkg! >=20 > >=20 > > For pkg 1.6.0 among other things and depending on the time, here is wha= t we do > > plan to work on: > > - > >=20 >=20 >=20 > What I really miss a lot is support for package "profiles": an ability to= build the same port with different OPTIONs combination. > For example: > minimal nginx version; > nginx version with passenger module (for puppet server) > nginx version with some other rare options turned on for custom applicati= on. >=20 > Right now I achieve this with manually renaming /var/db/ports/*/options f= iles and some manipulations in /usr/ports/packages/All. > But a framework to automatically handle this would be very useful. >=20 > Thanks. >=20 This is already supported on pkg side, the work needs to be done in ports s= ide, what you call profiles, I usually call it flavours but that is the same. Dependencies made on provides/requires allows to handle dependencies in thi= s: For example A can depend on nginx (whatever profile): so it requires "nginx" B can only depend on nginx-passenger: so it requires nginx-passenger nginx itself provides: nginx nginx-passenger provides: nginx and nginx-passenger that should do what you want unfortunatly that mean both nginx nginx-passen= ger both have one origin: www/nginx and this will break portupgrade/portmaster/tinderbox/poudriere (I can easily make poudriere fri= endly for that but I can't for the others). So most of the work is now on ports land (and maybe a couple of bug fixes in pkg) Best regards, Bapt --u5E4XgoOPWr4PD9E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUzkyUACgkQ8kTtMUmk6EyhnACePcqViIXH5vcnBh1NyQC2CofM rG4AoIxTOvXkgcDDEDICnCDgbWmnlhN4 =PPVO -----END PGP SIGNATURE----- --u5E4XgoOPWr4PD9E-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 13:48: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 9018894A for ; Sun, 19 Apr 2015 13:48:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3A1CC2 for ; Sun, 19 Apr 2015 13:48:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A0BE96E6 for ; Sun, 19 Apr 2015 13:48:04 +0000 (UTC) Date: Sun, 19 Apr 2015 13:48:03 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <296940552.30.1429451283510.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #948 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: Sun, 19 Apr 2015 13:48:04 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 15:19:31 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 855EC847; Sun, 19 Apr 2015 15:19:31 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 4E42C80B; Sun, 19 Apr 2015 15:19:31 +0000 (UTC) Received: by igbhj9 with SMTP id hj9so43507055igb.1; Sun, 19 Apr 2015 08:19:30 -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=MlxL5kvb8OhxHBeLDUfegcL4jFp5Llf5rOxVfrrsh1k=; b=Hin6jQNXkDncUwYMT9Wwhypo092j+S0yqgvo5BJy/5/O733iFrq6FrPmGS0iXxloCn ZureQBJZitaxrSUiKkHbVqeFOxbKsrjM5Rmhd5STWxfITryZKQfPbl+i5FRlOQZLlrSp Sy9Nv9aBMXN1OYFA6icFLnq16K5eIHkM10UHXpF6CqxJjzhA78C6qkopiaYpHCG5HHNM HfkxdIxgZC5hNVH1kGT2B250gAIx14+jJMVJL67QCQDaeaL3O1Bfwvlk0v/t4eSySWtt xr0alirS/oEMrXB7EiYvhakZvezHZDoKWpXAbvF5HNBJ0axQtiengdfVKOvzqpxf8qcw S9VA== MIME-Version: 1.0 X-Received: by 10.42.137.202 with SMTP id z10mr14162619ict.37.1429456770652; Sun, 19 Apr 2015 08:19:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Sun, 19 Apr 2015 08:19:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 19 Apr 2015 08:19:30 -0700 X-Google-Sender-Auth: 6h0qlEIN0qAEhgNNivNX9lp3JT8 Message-ID: Subject: Re: [Request for Help] Reducing gcc 4.9 compilation warnings From: Adrian Chadd To: Eitan Adler Cc: Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" , FreeBSD Toolchain 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, 19 Apr 2015 15:19:31 -0000 On 19 April 2015 at 02:10, Eitan Adler wrote: > " > > On 18 April 2015 at 11:12, Craig Rodrigues wrote: >> Hi, >> >> After the latest commits by members of freebsd-toolchain@ , >> I have managed to compile latest CURRENT world and GENERIC >> kernel on amd64 with an gcc 4.9 external toolchain by doing: >> >> pkg install devel/amd64-xtoolchain-gcc >> cd /usr/src >> sed -i "" -e 's/boot2//' sys/boot/i386/Makefile >> make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR= >> make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR= >> >> >> It was necessary to skip boot2 from building because of errors >> reported here: >> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html >> >> The boot2 compilation errors still need to be worked on. >> >> However, most other things compile with warnings. If folks are >> interested in looking at the warnings, you can see them here: >> >> https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/warnings17 >> >> Please look at these warnings, and if you see places to >> patch the code to eliminate the warnings, please submit patches >> and commit them if you can. > > Some time ago I tried to do something similar, but with gcc4.6 instead > of gcc4.9. > > The vast majority of warnings (1548) are "unused-but-set-variable" and > it may be worthwhile to just silence this warning, at least at low > WARNS levels. It has caught real errors but is quite noisy and can > cause quite a bit of churn. > > "inline" (count 515) is generally pure noise, and I think we should > disable it. It can be helpful to find certain types of performance > optimizations, but it should be opt-in. > > "strict-aliasing" (154) are likely all real bugs of some form. Very > few exist in contrib code, and it would be good to fix them. > > "Warning" (111) seem to be a mix of warnings, but mostly in contrib code. > > "maybe-uninitialized" (111) is often noisy, and in a spot check were > all false positives. > > "deprecated-declarations" (22) is all in contrib code > > Many of these are useful though and I've already fixed a few of the > bugs reported. > > Perhaps it would be useful to do a second run of this, but with a > modified share/mk to silence the most useless of these warnings? I just got a booting mips32 kernel using gcc-4.9.2, and boy are there a lot of warnings. I'm going to start fixing the ones I find - cleaner code is better code. Mostly. (I'd be happy with -Wall -Werror.) -adrian From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 18:46:25 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 CA98F655 for ; Sun, 19 Apr 2015 18:46:25 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c: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 52191DEB for ; Sun, 19 Apr 2015 18:46:25 +0000 (UTC) Received: by wizk4 with SMTP id k4so74958359wiz.1 for ; Sun, 19 Apr 2015 11:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=78ucYaBhHPKABVUbbebiva4ue0mOmnqG6vnKQ3s0yZA=; b=XO/4Q2/ZTCcytz5Ua0nN2h2W4GJCRnu0Ysd9vm14KmCbKY3kmi7hUdCp7saRLnY9ug nx3xW+jsgSyyvtNgI4mk6++9jEF/rjGlJIMFAD70KvsQX7EqGkAX+GkHp+eiepsxkMnw 3VqAaqZRn10a0eCMGJxQ5YC6eFlMP5WZ5BaLPYrZmXO09LNUU9WXczGH7Ch6pUkC31h4 9DTfIOj2YWN5u0D9L10FDgC7mMvNA8ShzLW0PFjoKeDbnr2rKHWuPCUroFB0yGt/iRRf DrbcWZN3IwVd/aUmwiGmw6R4BrN3x5/ED9Nlhb6e6pEXL0yoncbs1RQVN4Db0LgTv5Mq ZhlA== X-Received: by 10.180.106.70 with SMTP id gs6mr18543678wib.36.1429469183909; Sun, 19 Apr 2015 11:46:23 -0700 (PDT) Received: from ?IPv6:2001:470:1f15:b1f:2c4b:3537:2f58:deab? ([2001:470:1f15:b1f:2c4b:3537:2f58:deab]) by mx.google.com with ESMTPSA id z12sm24021588wjw.39.2015.04.19.11.46.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 11:46:22 -0700 (PDT) Message-ID: <5533F7FC.3060609@gmail.com> Date: Sun, 19 Apr 2015 20:46:20 +0200 From: =?windows-1252?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Call For Testers: Synaptics touchpads References: <1849381.HnoQVUIgNM@akita> In-Reply-To: <1849381.HnoQVUIgNM@akita> Content-Type: multipart/mixed; boundary="------------000106070501010702030604" 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, 19 Apr 2015 18:46:25 -0000 This is a multi-part message in MIME format. --------------000106070501010702030604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 08.04.2015 09:19, Rui Paulo wrote: > The attached patch adds support for newer touchpad features and implements two > finger scrolling. Hi, thanks for bringing two finger scrolling to the psm driver! I've attached a patch of some more improvements and fixes. I hope some of this stuff can make it into the driver: - Two finger scrolling support for "semi-MT" touchpads. Those include many of the older Synaptics touchpads before "true" multitouch support (indicated by capMultiFinger). Semi-MT touchpads can report a second finger position, but the X or Y coordinate may be swapped with some coordinate of the first finger. This is a result of how the hardware works internally. Therefore, all that can be reliably extracted is the bounding box of the two finger positions. Semi-MT touchpads can be recognized by the capAdvancedGestures capability bit. After setting the mode byte, advanced gestures mode has to be enabled. Then, data packets compatible with the capMultiFinger format are sent, so the same two finger scrolling code can be leveraged. Enabling advanced gestures mode on true multitouch touchpads should be harmless. Linux seems to always enable advanced gestures mode. I don't have a real multitouch touchpad for testing though. - Put mode setting logic into own functions synaptics_preferred_mode() and synaptics_set_mode() to have this in one place. synaptics_passthrough_on() and synaptics_passthrough_off() currently always use 0xc1 as the mode byte, which may be wrong for touchpads that don't have capExtended (sorry, my fault). - Expose X and Y resolution of touchpad to userland. Also expose minimum and maximum X and Y coordinates. This is useful for programs in userspace that read raw PSM packets (with PSM_LEVEL_NATIVE enabled) and need to interpret the coordinates. - Also send "extended w mode" packets (see section 3.2.9 of 511-000275-01_RevB.pdf) to userspace if PSM_LEVEL_NATIVE is enabled. This is useful for userspace programs/drivers such as xf86-input-synaptics that can handle these packets. - Fix parsing of nExtendedQueries, and request extended/continued capability bits depending on this value. - capReportsMax, capClearPad, capAdvancedGestures and capCoveredPad must be extracted from status[0] and not status[2], I think. Two finger scrolling works reasonably well with my semi-MT touchpad (Lenovo T420). However, it is very sensitive if I move my fingers very slowly. I wonder if this is because it's a semi-MT touchpad or if I have to tweak some setting. Also sometimes, if I move my fingers up, it scrolls down, and vice versa. Maybe this is a result of how dxp and dyp are calculated with the abs() function? Cheers, Jan --------------000106070501010702030604 Content-Type: text/x-patch; name="synaptics-improvements.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="synaptics-improvements.patch" diff --git a/sys/dev/atkbdc/psm.c b/sys/dev/atkbdc/psm.c index e8a2a93..4e41eef 100644 --- a/sys/dev/atkbdc/psm.c +++ b/sys/dev/atkbdc/psm.c @@ -483,6 +483,8 @@ static probefunc_t enable_versapad; static void set_trackpoint_parameters(struct psm_softc *sc); static void synaptics_passthrough_on(struct psm_softc *sc); static void synaptics_passthrough_off(struct psm_softc *sc); +static int synaptics_preferred_mode(struct psm_softc *sc); +static void synaptics_set_mode(struct psm_softc *sc, int mode_byte); static struct { int model; @@ -933,14 +935,8 @@ doopen(struct psm_softc *sc, int command_byte) get_mouse_status(sc->kbdc, stat, 0, 3); if ((SYNAPTICS_VERSION_GE(sc->synhw, 7, 5) || stat[1] == 0x47) && - stat[2] == 0x40) { - /* Set the mode byte -- request wmode where - * available */ - if (sc->synhw.capExtended) - mouse_ext_command(sc->kbdc, 0xc1); - else - mouse_ext_command(sc->kbdc, 0xc0); - set_mouse_sampling_rate(sc->kbdc, 20); + stat[2] == 0x40) { + synaptics_set_mode(sc, synaptics_preferred_mode(sc)); VLOG(5, (LOG_DEBUG, "psm%d: Synaptis Absolute Mode " "hopefully restored\n", sc->unit)); @@ -2176,6 +2172,20 @@ psmioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flag, (*(int *)addr > PSM_LEVEL_MAX)) return (EINVAL); sc->mode.level = *(int *)addr; + + if (sc->hw.model == MOUSE_MODEL_SYNAPTICS) { + /* + * If we are entering PSM_LEVEL_NATIVE, we want to + * enable sending of "extended W mode" packets to + * userland. Reset the mode of the touchpad so that the + * change in the level is picked up. + */ + error = block_mouse_data(sc, &command_byte); + if (error) + return (error); + synaptics_set_mode(sc, synaptics_preferred_mode(sc)); + unblock_mouse_data(sc, command_byte); + } break; case MOUSE_GETSTATUS: @@ -2864,7 +2874,8 @@ proc_synaptics(struct psm_softc *sc, packetbuf_t *pb, mousestatus_t *ms, /* Palm detection. */ if (!( - (sc->synhw.capMultiFinger && (w == 0 || w == 1)) || + ((sc->synhw.capMultiFinger || + sc->synhw.capAdvancedGestures) && (w == 0 || w == 1)) || (sc->synhw.capPalmDetect && w >= 4 && w <= max_width) || (!sc->synhw.capPalmDetect && *z <= max_pressure) || (sc->synhw.capPen && w == 2))) { @@ -4191,7 +4202,8 @@ synaptics_sysctl_create_tree(struct psm_softc *sc) * physical area reserved for scrolling or when * there's no multi finger support. */ - if (sc->synhw.verticalScroll || sc->synhw.capMultiFinger == 0) + if (sc->synhw.verticalScroll || (sc->synhw.capMultiFinger == 0 && + sc->synhw.capAdvancedGestures == 0)) sc->syninfo.two_finger_scroll = 0; else sc->syninfo.two_finger_scroll = 1; @@ -4493,6 +4505,43 @@ synaptics_sysctl_create_tree(struct psm_softc *sc) } static int +synaptics_preferred_mode(struct psm_softc *sc) { + int mode_byte; + + mode_byte = 0xc0; + + /* request wmode where available */ + if (sc->synhw.capExtended) + mode_byte |= 1; + + /* + * Disable gesture processing when native packets are requested. This + * enables sending of encapsulated "extended W mode" packets. + */ + if (sc->mode.level == PSM_LEVEL_NATIVE) + mode_byte |= (1 << 2); + + return mode_byte; +} + +static void +synaptics_set_mode(struct psm_softc *sc, int mode_byte) { + mouse_ext_command(sc->kbdc, mode_byte); + + /* "Commit" the Set Mode Byte command sent above. */ + set_mouse_sampling_rate(sc->kbdc, 20); + + /* + * Enable advanced gestures mode if supported and we are not entering + * passthrough mode. + */ + if (sc->synhw.capAdvancedGestures && !(mode_byte & (1 << 5))) { + mouse_ext_command(sc->kbdc, 3); + set_mouse_sampling_rate(sc->kbdc, 0xc8); + } +} + +static int enable_synaptics(KBDC kbdc, struct psm_softc *sc) { synapticshw_t synhw; @@ -4575,7 +4624,7 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) buttons = 0; synhw.capExtended = (status[0] & 0x80) != 0; if (synhw.capExtended) { - synhw.nExtendedQueries = (status[0] & 0x70) != 0; + synhw.nExtendedQueries = (status[0] & 0x70) >> 4; synhw.capMiddle = (status[0] & 0x04) != 0; synhw.capPassthrough = (status[2] & 0x80) != 0; synhw.capLowPower = (status[2] & 0x40) != 0; @@ -4587,6 +4636,16 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) synhw.capMultiFinger = (status[2] & 0x02) != 0; synhw.capPalmDetect = (status[2] & 0x01) != 0; + if (!set_mouse_scaling(kbdc, 1)) + return (FALSE); + if (mouse_ext_command(kbdc, 0x08) == 0) + return (FALSE); + if (get_mouse_status(kbdc, status, 0, 3) != 3) + return (FALSE); + + synhw.infoXupmm = status[0]; + synhw.infoYupmm = status[2]; + if (verbose >= 2) { printf(" Extended capabilities:\n"); printf(" capExtended: %d\n", synhw.capExtended); @@ -4602,6 +4661,8 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) printf(" capBallistics: %d\n", synhw.capBallistics); printf(" capMultiFinger: %d\n", synhw.capMultiFinger); printf(" capPalmDetect: %d\n", synhw.capPalmDetect); + printf(" infoXupmm: %d\n", synhw.infoXupmm); + printf(" infoYupmm: %d\n", synhw.infoYupmm); } /* @@ -4609,7 +4670,9 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) * supports this number of extended queries. We can load * more information about buttons using query 0x09. */ - if (synhw.capExtended && synhw.nExtendedQueries) { + if (synhw.nExtendedQueries >= 1) { + if (!set_mouse_scaling(kbdc, 1)) + return (FALSE); if (mouse_ext_command(kbdc, 0x09) == 0) return (FALSE); if (get_mouse_status(kbdc, status, 0, 3) != 3) @@ -4618,6 +4681,7 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) synhw.horizontalScroll = (status[0] & 0x02) != 0; synhw.verticalWheel = (status[0] & 0x08) != 0; synhw.nExtendedButtons = (status[1] & 0xf0) >> 4; + synhw.capEWmode = (status[0] & 0x04) != 0; if (verbose >= 2) { printf(" Extended model ID:\n"); printf(" verticalScroll: %d\n", @@ -4628,6 +4692,8 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) synhw.verticalWheel); printf(" nExtendedButtons: %d\n", synhw.nExtendedButtons); + printf(" capEWmode: %d\n", + synhw.capEWmode); } /* * Add the number of extended buttons to the total @@ -4641,7 +4707,97 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) * add a fourth button to the total button count. */ buttons = synhw.capFourButtons ? 1 : 0; + + /* Read the continued capabilities bits. */ + if (synhw.nExtendedQueries >= 4) { + if (!set_mouse_scaling(kbdc, 1)) + return (FALSE); + if (mouse_ext_command(kbdc, 0x0c) == 0) + return (FALSE); + if (get_mouse_status(kbdc, status, 0, 3) != 3) + return (FALSE); + + synhw.capClickPad = (status[1] & 0x01) << 1; + synhw.capClickPad |= (status[0] & 0x10) != 0; + synhw.capDeluxeLEDs = (status[1] & 0x02) != 0; + synhw.noAbsoluteFilter = (status[1] & 0x04) != 0; + synhw.capReportsV = (status[1] & 0x08) != 0; + synhw.capUniformClickPad = (status[1] & 0x10) != 0; + synhw.capReportsMin = (status[1] & 0x20) != 0; + synhw.capInterTouch = (status[1] & 0x40) != 0; + synhw.capReportsMax = (status[0] & 0x02) != 0; + synhw.capClearPad = (status[0] & 0x04) != 0; + synhw.capAdvancedGestures = (status[0] & 0x08) != 0; + synhw.capCoveredPad = (status[0] & 0x80) != 0; + + if (synhw.capReportsMax) { + if (!set_mouse_scaling(kbdc, 1)) + return (FALSE); + if (mouse_ext_command(kbdc, 0x0d) == 0) + return (FALSE); + if (get_mouse_status(kbdc, status, 0, 3) != 3) + return (FALSE); + + synhw.maximumXCoord = (status[0] << 5) | + ((status[1] & 0x0f) << 1); + synhw.maximumYCoord = (status[2] << 5) | + ((status[1] & 0xf0) >> 3); + } + if (synhw.capReportsMin) { + if (!set_mouse_scaling(kbdc, 1)) + return (FALSE); + if (mouse_ext_command(kbdc, 0x0f) == 0) + return (FALSE); + if (get_mouse_status(kbdc, status, 0, 3) != 3) + return (FALSE); + + synhw.minimumXCoord = (status[0] << 5) | + ((status[1] & 0x0f) << 1); + synhw.minimumYCoord = (status[2] << 5) | + ((status[1] & 0xf0) >> 3); + } + + if (verbose >= 2) { + printf(" Continued capabilities:\n"); + printf(" capClickPad: %d\n", + synhw.capClickPad); + printf(" capDeluxeLEDs: %d\n", + synhw.capDeluxeLEDs); + printf(" noAbsoluteFilter: %d\n", + synhw.noAbsoluteFilter); + printf(" capReportsV: %d\n", + synhw.capReportsV); + printf(" capUniformClickPad: %d\n", + synhw.capUniformClickPad); + printf(" capReportsMin: %d\n", + synhw.capReportsMin); + printf(" capInterTouch: %d\n", + synhw.capInterTouch); + printf(" capReportsMax: %d\n", + synhw.capReportsMax); + printf(" capClearPad: %d\n", + synhw.capClearPad); + printf(" capAdvancedGestures: %d\n", + synhw.capAdvancedGestures); + printf(" capCoveredPad: %d\n", + synhw.capCoveredPad); + if (synhw.capReportsMax) { + printf(" maximumXCoord: %d\n", + synhw.maximumXCoord); + printf(" maximumYCoord: %d\n", + synhw.maximumYCoord); + } + if (synhw.capReportsMin) { + printf(" minimumXCoord: %d\n", + synhw.minimumXCoord); + printf(" minimumYCoord: %d\n", + synhw.minimumYCoord); + } + } + buttons += synhw.capClickPad; + } } + if (verbose >= 2) { if (synhw.capExtended) printf(" Additional Buttons: %d\n", buttons); @@ -4649,42 +4805,6 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) printf(" No extended capabilities\n"); } - /* Read the continued capabilities bits. */ - if (mouse_ext_command(kbdc, 0xc) != 0 && - get_mouse_status(kbdc, status, 0, 3) == 3) { - synhw.capClickPad = (status[1] & 0x01) << 1; - synhw.capClickPad |= (status[0] & 0x10) != 0; - synhw.capDeluxeLEDs = (status[1] & 0x02) != 0; - synhw.noAbsoluteFilter = (status[1] & 0x04) != 0; - synhw.capReportsV = (status[1] & 0x08) != 0; - synhw.capUniformClickPad = (status[1] & 0x10) != 0; - synhw.capReportsMin = (status[1] & 0x20) != 0; - synhw.capInterTouch = (status[1] & 0x40) != 0; - synhw.capReportsMax = (status[2] & 0x02) != 0; - synhw.capClearPad = (status[2] & 0x04) != 0; - synhw.capAdvancedGestures = (status[2] & 0x08) != 0; - synhw.capCoveredPad = (status[2] & 0x80) != 0; - - if (verbose >= 2) { - printf(" Continued capabilities:\n"); - printf(" capClickPad: %d\n", synhw.capClickPad); - printf(" capDeluxeLEDs: %d\n", synhw.capDeluxeLEDs); - printf(" noAbsoluteFilter: %d\n", - synhw.noAbsoluteFilter); - printf(" capReportsV: %d\n", synhw.capReportsV); - printf(" capUniformClickPad: %d\n", - synhw.capUniformClickPad); - printf(" capReportsMin: %d\n", synhw.capReportsMin); - printf(" capInterTouch: %d\n", synhw.capInterTouch); - printf(" capReportsMax: %d\n", synhw.capReportsMax); - printf(" capClearPad: %d\n", synhw.capClearPad); - printf(" capAdvancedGestures: %d\n", - synhw.capAdvancedGestures); - printf(" capCoveredPad: %d\n", synhw.capCoveredPad); - } - buttons += synhw.capClickPad; - } - /* * Add the default number of 3 buttons to the total * count of supported buttons reported above. @@ -4712,15 +4832,10 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) if (!synaptics_support) return (FALSE); - /* Set the mode byte; request wmode where available. */ - mouse_ext_command(kbdc, synhw.capExtended ? 0xc1 : 0xc0); - - /* "Commit" the Set Mode Byte command sent above. */ - set_mouse_sampling_rate(kbdc, 20); - VLOG(3, (LOG_DEBUG, "synaptics: END init (%d buttons)\n", buttons)); if (sc != NULL) { + synaptics_set_mode(sc, synaptics_preferred_mode(sc)); if (trackpoint_support && synhw.capPassthrough) { synaptics_passthrough_on(sc); enable_trackpoint(kbdc, sc); @@ -4737,30 +4852,17 @@ enable_synaptics(KBDC kbdc, struct psm_softc *sc) static void synaptics_passthrough_on(struct psm_softc *sc) { - int mode_byte; - - mode_byte = 0xc1 | (1 << 5); - VLOG(2, (LOG_NOTICE, "psm: setting pass-through mode. %d\n", - mode_byte)); - mouse_ext_command(sc->kbdc, mode_byte); - - /* "Commit" the Set Mode Byte command sent above. */ - set_mouse_sampling_rate(sc->kbdc, 20); + VLOG(2, (LOG_NOTICE, "psm: setting pass-through mode.\n")); + synaptics_set_mode(sc, synaptics_preferred_mode(sc) | (1 << 5)); } static void synaptics_passthrough_off(struct psm_softc *sc) { - int mode_byte; - - mode_byte = 0xc1; VLOG(2, (LOG_NOTICE, "psm: turning pass-through mode off.\n")); set_mouse_scaling(sc->kbdc, 2); set_mouse_scaling(sc->kbdc, 1); - mouse_ext_command(sc->kbdc, mode_byte); - - /* "Commit" the Set Mode Byte command sent above. */ - set_mouse_sampling_rate(sc->kbdc, 20); + synaptics_set_mode(sc, synaptics_preferred_mode(sc)); } /* IBM/Lenovo TrackPoint */ diff --git a/sys/sys/mouse.h b/sys/sys/mouse.h index 5329693..24d0ffc 100644 --- a/sys/sys/mouse.h +++ b/sys/sys/mouse.h @@ -128,6 +128,13 @@ typedef struct synapticshw { int verticalScroll; int horizontalScroll; int verticalWheel; + int capEWmode; + int minimumXCoord; + int minimumYCoord; + int maximumXCoord; + int maximumYCoord; + int infoXupmm; + int infoYupmm; } synapticshw_t; /* iftype */ --------------000106070501010702030604-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 21:00: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 2BB4AA7C for ; Sun, 19 Apr 2015 21:00:17 +0000 (UTC) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id F0B4BD2E for ; Sun, 19 Apr 2015 21:00:16 +0000 (UTC) Received: from [96.28.24.204] ([96.28.24.204:28658] helo=[192.168.209.109]) by dnvrco-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 8A/F6-10851-85714355; Sun, 19 Apr 2015 21:00:08 +0000 Message-ID: <1429477202.29812.38.camel@gemini.bsd1.net> Subject: AUTOFS and NFS not playing together nicely From: David Boyd To: freebsd-current@freebsd.org Date: Sun, 19 Apr 2015 17:00:02 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-31.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.64.130:25 X-Authority-Analysis: v=2.1 cv=GKuGE49K c=1 sm=1 tr=0 a=LAeh8JulWguKKqZdjpwXog==:117 a=LAeh8JulWguKKqZdjpwXog==:17 a=ayC55rCoAAAA:8 a=IkcTkHD0fZMA:10 a=UNWf5WQ7AAAA:8 a=mjlnPRs6AAAA:8 a=xiTNktAfJqfuuXK_zOQA:9 a=QEXdDO2ut3YA:10 X-Cloudmark-Score: 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: Sun, 19 Apr 2015 21:00:17 -0000 At the risk of being dubbed insane, here goes: On five FreeBSD 10.1-RELEASE-p9 production servers autofs(5) is enabled and working as advertised. On the same servers nfs v3 clients are also fat, dumb and happy. On a test server where autofs(5) is also enabled and working well, I am testing nfs v3 (later v4) server. Strange things are happening. When nfs mountd(8) is running, the autofs(5) auto-mount (via automountd) function seems to work, but the autofs(5) auto-unmount (via autounmountd) never occurs. Without nfs mountd(8), when the filesystem /disc is auto-mounted (via autoumountd), the mount(8) command shows status of (ufs, local, journaled soft-updates, auto-mounted) for the auto-mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted (via autounmountd). No problem. With nfs mountd(8) the mount(8) command shows (ufs, local, journaled soft-updates). The auto-mounted filesystem is never (a long, long time) unmounted. Big problem. Without nfs mountd(8) running, the mount(8) command "mount -o automounted /dev/ada0p8 /disc" mounts the filesystem and the mount(8) command shows (ufs, local, journaled soft-updates, automounted) for the manually mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted even though it was not mounted automatically. No problem. With nfs mountd(8), the mount(8) command "mount -o automounted /dev/ada0p8 /disc" mounts the filesystem but the mount(8) command shows (ufs, local, journaled soft-updates) and after the timeout period (600 seconds) the filesystem is remains mounted. Big problem. It appears that nfs mountd(8) is interferring with the mount(8) command's -o option processing but admittedly that is just a very weak SWAG. I have adequate hardware (real and virtual) to do any testing that may be suggested. Most days there is no time constraint either. -------------------------------------------------------- The /etc/auto_master file is two lines: 1:/net -hosts -nobrowse,nosuid (original) 2:/- /etc/autofs/auto_disc -------------------------------------------------------- The /etc/autofs/auto_disc file is one line: 1:/disc -fstype=ufs :/dev/ada0p8 -------------------------------------------------------- Once again, everything works well when nfs mountd(8) is not present in the system. Thanks for any assistance that you may be able to supply. David Boyd. From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 21:35:26 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 61478F14; Sun, 19 Apr 2015 21:35:26 +0000 (UTC) Received: from st11p00mm-asmtp002.mac.com (st11p00mm-asmtpout002.mac.com [17.172.81.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C574189; Sun, 19 Apr 2015 21:35:25 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NN2005M6PAU9I00@st11p00mm-asmtp002.mac.com>; Sun, 19 Apr 2015 21:35:19 +0000 (GMT) From: Rui Paulo To: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Subject: CTF: wpa_supplicant/hostapd 2.4 import Date: Sun, 19 Apr 2015 14:35:17 -0700 Message-id: <2408123.McWtPaBMsU@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-19_03:2015-04-17,2015-04-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504190192 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, 19 Apr 2015 21:35:26 -0000 Hi, Please test the new wpa_supplicant/hostapd. Here's the patch against FreeBSD HEAD: https://people.freebsd.org/~rpaulo/wpa-2.4.diff Thanks, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 22:05:10 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 4B1DB3A0 for ; Sun, 19 Apr 2015 22:05: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 3793964E for ; Sun, 19 Apr 2015 22:05:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 46AF47C2 for ; Sun, 19 Apr 2015 22:05:11 +0000 (UTC) Date: Sun, 19 Apr 2015 22:05:09 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1197935035.32.1429481109696.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <296940552.30.1429451283510.JavaMail.jenkins@jenkins-9.freebsd.org> References: <296940552.30.1429451283510.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #949 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: Sun, 19 Apr 2015 22:05:10 -0000 See From owner-freebsd-current@FreeBSD.ORG Sun Apr 19 23:18: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 E2BE6D67; Sun, 19 Apr 2015 23:18:09 +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 919EFC9F; Sun, 19 Apr 2015 23:18:08 +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 t3JNI29p003751; Sun, 19 Apr 2015 16:18:02 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t3JNI1rb003750; Sun, 19 Apr 2015 16:18:01 -0700 (PDT) (envelope-from david) Date: Sun, 19 Apr 2015 16:18:01 -0700 From: David Wolfskill To: Rui Paulo Cc: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Subject: Re: CTF: wpa_supplicant/hostapd 2.4 import Message-ID: <20150419231801.GE1223@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Rui Paulo , "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org References: <2408123.McWtPaBMsU@akita> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KlAEzMkarCnErv5Q" Content-Disposition: inline In-Reply-To: <2408123.McWtPaBMsU@akita> 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: Sun, 19 Apr 2015 23:18:10 -0000 --KlAEzMkarCnErv5Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 19, 2015 at 02:35:17PM -0700, Rui Paulo wrote: > Hi, >=20 > Please test the new wpa_supplicant/hostapd. Here's the patch against Fre= eBSD=20 > HEAD: >=20 > https://people.freebsd.org/~rpaulo/wpa-2.4.diff > ... Seems OK so far for both amd64 & i386; sources (prior to applying above patch) @r281736. I only use wpa_supplicant, and I've only tested it lightly at home (which is among my "less challenging" 802.11 environments). 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. --KlAEzMkarCnErv5Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVNDepXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7zp4P/jLyW4FVrHvB7F1CUib/uUq5 R4Guse3COYN+l/rgdeudJsnB2nIoJJ/e9W5QSylu6nT/7MYSoNxq7fsO9NXmsM2z MDlFFdnBM41xfXAWn1nPBgu0hOZqHje6kQ9GyX4DYxcHZEkNHncZkNgvFaRDukD6 2Q28A9lGtnpzRak3GpLYGWhj2IsnT5O3EhrdVSm7+j9BFbK+jBFHE4FCOiPBQlc7 0XONZ+XD39bVYt9xp9eTsH0JlSJM3w/egZrqDs6HqUd+rn807auopxWsg+yaXw6a Xp2VNvxD5Fa3H0FtNJb04S5y+/Xjgl33zz/1DgbGdwDHhokoGCBjAbIhkP5JyjWQ Q45tR5e9WablNIqyeWF+F1eH24a7iAybw4fm6jUPMwWycNra1f2jW9zOXn1OXJY8 vTWB04kN3zYyNy3VJNPOZ2TgnMZV+zTEbKgjo5uLKh4kZzgDaw3tBFhiSlHWcdFx LACG7SjV8cOxo4XbRDip7Y22RVSBWXHP4kWF5a3BFu2BOzWrdYUXQp2OlvmDaN5V 4KtBGWDjy3tue2xkI4D8ObgzX09/1e/msw5VYEKWUQCrb6wtakJUgwt6xh1OeKWh +HqYzB3cV6kR4AdegjoyPE8jlUsB2LaN2GBnVAyKD3dn1+kXkurRUdyodJHg3uPO gD5+OKliqtccPWavDahl =Y3Qd -----END PGP SIGNATURE----- --KlAEzMkarCnErv5Q-- From owner-freebsd-current@FreeBSD.ORG Mon Apr 20 02:04:24 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 205B7EFB; Mon, 20 Apr 2015 02:04:24 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 64170DC8; Mon, 20 Apr 2015 02:04:22 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id t3K1jed5072190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 09:45:40 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id t3K1jdWk072189; Mon, 20 Apr 2015 09:45:39 +0800 (CST) (envelope-from kevlo) Date: Mon, 20 Apr 2015 09:45:39 +0800 From: Kevin Lo To: Rui Paulo Cc: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Subject: Re: CTF: wpa_supplicant/hostapd 2.4 import Message-ID: <20150420014539.GA72180@ns.kevlo.org> References: <2408123.McWtPaBMsU@akita> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2408123.McWtPaBMsU@akita> 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, 20 Apr 2015 02:04:24 -0000 On Sun, Apr 19, 2015 at 02:35:17PM -0700, Rui Paulo wrote: > > Hi, > > Please test the new wpa_supplicant/hostapd. Here's the patch against FreeBSD > HEAD: > > https://people.freebsd.org/~rpaulo/wpa-2.4.diff Seems to be working fine on amd64. Tested on ral(4) and run(4). Thanks. > Thanks, > -- > Rui Paulo Kevin From owner-freebsd-current@FreeBSD.ORG Mon Apr 20 16:46:42 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 A2EEA324; Mon, 20 Apr 2015 16:46:42 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E145DDD2; Mon, 20 Apr 2015 16:46:41 +0000 (UTC) X-AuditID: 1209190d-f79676d000000da0-49-55352d691540 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E5.7A.03488.A6D25355; Mon, 20 Apr 2015 12:46:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t3KGkWMK010733; Mon, 20 Apr 2015 12:46:33 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3KGkUXR000539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2015 12:46:31 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3KGkToZ011605; Mon, 20 Apr 2015 12:46:29 -0400 (EDT) Date: Mon, 20 Apr 2015 12:46:29 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Adrian Chadd cc: Eitan Adler , Craig Rodrigues , freebsd-current Current , "freebsd-testing@freebsd.org" , FreeBSD Toolchain Subject: Re: [Request for Help] Reducing gcc 4.9 compilation warnings In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixCmqrJulaxpqcH8Di8XerduZLOa8+cBk 0T2lk83i19djjBaLTrQzWezt7WFzYPOYtvkgm8eMT/NZApiiuGxSUnMyy1KL9O0SuDKuTvnH XrCdpWJq4xKWBsYDzF2MnBwSAiYS2/6fYoSwxSQu3FvPBmILCSxmkvj0pKCLkQvI3sgo0Xt1 PiOEc4hJ4t3hmSwQTgOjRNv00+wgLSwC2hJf/2wBs9kE1CQe721mhRirKLH51CSgdRwcIgKq Ep3znUHCzAL9TBLfboaB2MICrhL/7iwEK+cUCJTou3mbFaScV8BR4vjxWIiDbjFKrLuiC2KL CuhIrN4/hQXE5hUQlDg58wkLxEgtieXTt7FMYBSahSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd 4uTEvLzUIl0jvdzMEr3UlNJNjOAwl+TdwfjuoNIhRgEORiUeXglDk1Ah1sSy4srcQ4ySHExK orxztU1DhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwCrID5XhTEiurUovyYVLSHCxK4rybfvCF CAmkJ5akZqemFqQWwWRlODiUJHiNdIAaBYtS01Mr0jJzShDSTBycIMN5gIZHgdTwFhck5hZn pkPkTzHqctyZ8n8RkxBLXn5eqpQ4rzVIkQBIUUZpHtwcWHp6xSgO9JYw73SQKh5gaoOb9Apo CRPQkrhtJiBLShIRUlINjHE7XdYE1yXd7v7feCf7t2CNZXLl9Cl2zPrS23Pm+HaU/Co/wiF+ bvbOyd2x1koBqdGybZfsXubfLJ1WIVy66PEmL5V5VZ/NSk/Vz0vzrUz5L77yuLLfAs3bwu3u 6r3OfTf/xcRUnaljudx9Jkb8mRHPmZ9THVc7nTv7+VyDudnqMFXzK3YLlViKMxINtZiLihMB Tvoi8CoDAAA= 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, 20 Apr 2015 16:46:42 -0000 On Sun, 19 Apr 2015, Adrian Chadd wrote: > I just got a booting mips32 kernel using gcc-4.9.2, and boy are there > a lot of warnings. I'm going to start fixing the ones I find - cleaner > code is better code. Mostly. > > (I'd be happy with -Wall -Werror.) I thought that -Wall was a fixed set of warnings nowhere close to all of them (to avoid breaking peoples' builds as new warnings are introduced), and a larger set would be better. (Things like -Wmaybe-uninitialized have too many false positives to be a desirable -Werror target, though.) -Ben From owner-freebsd-current@FreeBSD.ORG Mon Apr 20 18:09: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 3E650850; Mon, 20 Apr 2015 18:09:47 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 BB9CFA34; Mon, 20 Apr 2015 18:09:46 +0000 (UTC) Received: by lbbqq2 with SMTP id qq2so136999725lbb.3; Mon, 20 Apr 2015 11:09:44 -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=BwYe0a/lHGeVQc1OIKATxTmD2ANZNbAdUqR3e0/M9oc=; b=VEO5tFU8r7qH+PwiIauJ4D02PvmkyJ4a2xfGs1CY7VhJ2SntPwK325sZV4JQMNtptW AaW16qg103Y6MB/uZkqaXBoZUgqZcyHtC8wC/zpzN2PsHTQVvN9vJNqrvkIZfpuAY5LC yw0nhZmqKO7Zx2CVSu01wcIXpgkHmq3IJbCm5Ebh+fhYXgF1WGEdxvl0WqvQNO+/hduH mWUG6qiW/csONyY0WHWqFBIDZCp5hjOb+dzqye3pvDrEejd5UTqmgsvjs+sw5QhnqCUH GRHf+GwroxQV3ow9WOGqYyN1P3qhNI6n55qQfQkZSuJTWtJJZbERBU0jyyy69Wdy89q4 LL2Q== MIME-Version: 1.0 X-Received: by 10.152.120.163 with SMTP id ld3mr16921654lab.59.1429553384754; Mon, 20 Apr 2015 11:09:44 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.164.38 with HTTP; Mon, 20 Apr 2015 11:09:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Apr 2015 11:09:44 -0700 X-Google-Sender-Auth: kcv7M7sj21mCbHnZAgkZ-K9drG0 Message-ID: Subject: Re: [Request for Help] Reducing gcc 4.9 compilation warnings From: Craig Rodrigues To: Eitan Adler Cc: freebsd-current Current , "freebsd-testing@freebsd.org" , FreeBSD Toolchain 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, 20 Apr 2015 18:09:47 -0000 On Sun, Apr 19, 2015 at 2:10 AM, Eitan Adler wrote: > > Perhaps it would be useful to do a second run of this, but with a > modified share/mk to silence the most useless of these warnings? > > Sure, that's fine. Can you provide a modified share/mk which you think does the right thing? We can try it. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 10:01: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 389F4D49 for ; Tue, 21 Apr 2015 10:01:01 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 A99001F87 for ; Tue, 21 Apr 2015 10:01:00 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 0A65616A481 for ; Tue, 21 Apr 2015 12:00:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOwYwJNgXbs5; Tue, 21 Apr 2015 12:00:30 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:d50f:5e7:50e:c1fc] (unknown [IPv6:2001:4cb8:3:1:d50f:5e7:50e:c1fc]) by smtp.digiware.nl (Postfix) with ESMTP id EEE0516A466 for ; Tue, 21 Apr 2015 12:00:30 +0200 (CEST) Message-ID: <55361FBC.3020409@digiware.nl> Date: Tue, 21 Apr 2015 12:00:28 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Error in parallel building 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, 21 Apr 2015 10:01:01 -0000 Hi, With a freshly fetched HEAD, and 'make -j 8 buildworld' I get: ---------------------------- --- _bootstrap-tools-kerberos5/lib/libvers --- --- roken.h --- make-roken > roken.h make-roken: not found --- _bootstrap-tools-kerberos5/tools/make-roken --- --- make-roken.c --- awk -f /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roken/roken.awk /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roken/roken.h.in > make-roken.c --- _bootstrap-tools-kerberos5/lib/libvers --- *** [roken.h] Error code 127 make[3]: stopped in /usr/srcs/head/kerberos5/lib/libvers 1 error ---------------------------- Building serial does seem to work, it seems to be slugging away at building clang..... --WjW From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 10:18: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 384A92E6 for ; Tue, 21 Apr 2015 10:18:43 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 ECBDE11A8 for ; Tue, 21 Apr 2015 10:18:42 +0000 (UTC) Received: by obbeb7 with SMTP id eb7so141205566obb.3 for ; Tue, 21 Apr 2015 03:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AEOiGklB7HTbH6Dil25hFKN9hQvMJSkD47WgKQdLbG4=; b=OUPpTWPCDKi+/glHjoWQl6qUh07wv+UYJoidoaYBbLW8kDZ/D3kc94opcOY984y8qe XC7n9TKuhOQRsKIqeZCcbxC114uYOL2TrVyQH52PXSvJT4Jq8x9YfioS0lQmrAlRh6HR kFTcpiChfOHUvNBSV1F58a3R+AAsauiZIjg9A4Qn94nxhf0C6Vg+mx5iTV9eN6mfUyEE CV5vaFZNZmz4hbeSKyoeLXK59DHA6U8Gxy97QRi6WI/nLkCN/OKnswKd2wUirgZOvzuO B623Miqx3ZPNKebnCp/71hiJEG+oZcRoVHyEf9zsuCJMKXM8kbQIfayIMQQJGf+tuyG2 62vQ== X-Received: by 10.60.44.177 with SMTP id f17mr18246458oem.4.1429611522193; Tue, 21 Apr 2015 03:18:42 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:81f7:967e:d230:65b2? ([2601:8:ab80:7d6:81f7:967e:d230:65b2]) by mx.google.com with ESMTPSA id t7sm928947oie.22.2015.04.21.03.18.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Apr 2015 03:18:41 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_D25CF399-774B-4CC7-AE72-81D08B1A8304"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Error in parallel building From: Garrett Cooper In-Reply-To: <55361FBC.3020409@digiware.nl> Date: Tue, 21 Apr 2015 03:18:38 -0700 Cc: FreeBSD Current Message-Id: <4583A01A-75B2-4E7E-9A82-92C3424C3438@gmail.com> References: <55361FBC.3020409@digiware.nl> To: Willem Jan Withagen 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: Tue, 21 Apr 2015 10:18:43 -0000 --Apple-Mail=_D25CF399-774B-4CC7-AE72-81D08B1A8304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 21, 2015, at 3:00, Willem Jan Withagen wrote: > Hi, >=20 > With a freshly fetched HEAD, and 'make -j 8 buildworld' I get: >=20 > ---------------------------- > --- _bootstrap-tools-kerberos5/lib/libvers --- > --- roken.h --- > make-roken > roken.h > make-roken: not found > --- _bootstrap-tools-kerberos5/tools/make-roken --- > --- make-roken.c --- > awk -f = /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roke= n/roken.awk = /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roke= n/roken.h.in > make-roken.c > --- _bootstrap-tools-kerberos5/lib/libvers --- > *** [roken.h] Error code 127 >=20 > make[3]: stopped in /usr/srcs/head/kerberos5/lib/libvers > 1 error I=92m really sorry for not catching this sooner :(=85 I missed the part = about MAKE_ROKEN in libvers. All of kerberos5 built during bootstrap-tools is basically serialized in = an implicit manner, so I=92ve committed the following item to resolve = the build issue you=92ve noted. Thank you for the feedback, -NGie ------------------------------------------------------------------------ r281823 | ngie | 2015-04-21 03:17:25 -0700 (Tue, 21 Apr 2015) | 9 lines Serialize all of _kerberos5_bootstrap_tools to avoid build failures = involving make bootstrap-tools On the plus side, this also greatly reduces complexity MFC after: 1 week Pointyhat to: ngie Reported by: Willem Jan Withagen --Apple-Mail=_D25CF399-774B-4CC7-AE72-81D08B1A8304 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 iQEcBAEBCgAGBQJVNiP+AAoJEMZr5QU6S73ebW8H/3Hp9PlotpWVzyCjlvCpy4E6 NCvWRNfhpL8Y5HA8QgwdxlidyDXicjJHG9J+RrfqSfJ+iS8grhI3hWWuv/I5RZd+ BznLk1htBzGanFnRnos5z6XaSJF91gJzZti7urkqb2etLXrywqO8ZGF0Zr1SsK8u /C2/GWdizHurrL2rCs01y9FdzacHz/JRMt6WbRFgXNn1mVcbHPvh8ZlHccxa44hq v2xQ3Zd56R+YzILFeAoAmv1Ka7q1/tofl/0OpUDgexNZJ8D7BPHw+AWKBMR8FfMS iv211Y/Kvs+71M6jNhQQFqQw288mz9G9kLbthqnlsCyFL6NklY3i0Bd9t/ms2q0= =7bGK -----END PGP SIGNATURE----- --Apple-Mail=_D25CF399-774B-4CC7-AE72-81D08B1A8304-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 10:20:08 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 6194F40B for ; Tue, 21 Apr 2015 10:20:08 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 25E5C11C8 for ; Tue, 21 Apr 2015 10:20:08 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 461FE16A478; Tue, 21 Apr 2015 12:20:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-KP3DiHyZvS; Tue, 21 Apr 2015 12:20:03 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:d50f:5e7:50e:c1fc] (unknown [IPv6:2001:4cb8:3:1:d50f:5e7:50e:c1fc]) by smtp.digiware.nl (Postfix) with ESMTP id 1FC1516A475; Tue, 21 Apr 2015 12:20:03 +0200 (CEST) Message-ID: <55362450.4030905@digiware.nl> Date: Tue, 21 Apr 2015 12:20:00 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Garrett Cooper CC: FreeBSD Current Subject: Re: Error in parallel building References: <55361FBC.3020409@digiware.nl> <4583A01A-75B2-4E7E-9A82-92C3424C3438@gmail.com> In-Reply-To: <4583A01A-75B2-4E7E-9A82-92C3424C3438@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Tue, 21 Apr 2015 10:20:08 -0000 On 21-4-2015 12:18, Garrett Cooper wrote: > On Apr 21, 2015, at 3:00, Willem Jan Withagen wrote: > >> Hi, >> >> With a freshly fetched HEAD, and 'make -j 8 buildworld' I get: >> >> ---------------------------- >> --- _bootstrap-tools-kerberos5/lib/libvers --- >> --- roken.h --- >> make-roken > roken.h >> make-roken: not found >> --- _bootstrap-tools-kerberos5/tools/make-roken --- >> --- make-roken.c --- >> awk -f /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roken/roken.awk /usr/srcs/head/kerberos5/tools/make-roken/../../../crypto/heimdal/lib/roken/roken.h.in > make-roken.c >> --- _bootstrap-tools-kerberos5/lib/libvers --- >> *** [roken.h] Error code 127 >> >> make[3]: stopped in /usr/srcs/head/kerberos5/lib/libvers >> 1 error > > I’m really sorry for not catching this sooner :(… I missed the part about MAKE_ROKEN in libvers. > > All of kerberos5 built during bootstrap-tools is basically serialized in an implicit manner, so I’ve committed the following item to resolve the build issue you’ve noted. > > Thank you for the feedback, > -NGie > > ------------------------------------------------------------------------ > r281823 | ngie | 2015-04-21 03:17:25 -0700 (Tue, 21 Apr 2015) | 9 lines > > Serialize all of _kerberos5_bootstrap_tools to avoid build failures involving > make bootstrap-tools > > On the plus side, this also greatly reduces complexity > > MFC after: 1 week > Pointyhat to: ngie > Reported by: Willem Jan Withagen > Long time that I saw a pointy hat coming by.... :) Usually I'm the one on the receiving end. Thanx, --WjW From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 10:22:22 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 0349954A for ; Tue, 21 Apr 2015 10:22:22 +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 C37661290 for ; Tue, 21 Apr 2015 10:22:21 +0000 (UTC) Received: by paboj16 with SMTP id oj16so236963195pab.0 for ; Tue, 21 Apr 2015 03:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GHfs4qcXRLDLZEx8+T8eXv0J0uPiu9RnsdPaYwyKA+E=; b=sqOt/CgSekoDndR8VSWP/pH/Scw5TjAIRP+WF2+OzxH+dP52m4Z7vVWNmz2PPUqotm Uxk7IdiNnBVSUryXUAK4/z83hWYaMrv6yXQsgtTD9eCc0Fwk/fAoKWC3u+SmFjYovpI3 TXl5hF3f8u1cYh14QsbUBjxpWj3Gq8hCmujyIQADnAAlSVmv8PCDnkss3nOalSUu1Pz3 Wg7RPcDiSBs9srR5sZ6Fp/PTmqx3PiUq8aMQ384shDSw49KBMkxKcg3bfPlIVWb1jWh/ eEdF7NToP0iV4xa5z38yPyGhcso3DnQ6vfbdJnM0s2HyQ5+RnM41afRff4zc4LMTEvPG q+Kg== X-Received: by 10.68.57.201 with SMTP id k9mr36431800pbq.135.1429611741414; Tue, 21 Apr 2015 03:22:21 -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 p9sm1580958pds.92.2015.04.21.03.22.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Apr 2015 03:22:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_36F18C1A-C62C-40E6-95A5-F3B98FCCD7CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Error in parallel building From: Garrett Cooper In-Reply-To: <55362450.4030905@digiware.nl> Date: Tue, 21 Apr 2015 03:22:18 -0700 Cc: FreeBSD Current Message-Id: <618E39F2-DAA7-466A-9327-843E4396571D@gmail.com> References: <55361FBC.3020409@digiware.nl> <4583A01A-75B2-4E7E-9A82-92C3424C3438@gmail.com> <55362450.4030905@digiware.nl> To: Willem Jan Withagen 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: Tue, 21 Apr 2015 10:22:22 -0000 --Apple-Mail=_36F18C1A-C62C-40E6-95A5-F3B98FCCD7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 21, 2015, at 3:20, Willem Jan Withagen wrote: > Long time that I saw a pointy hat coming by.... :) > Usually I'm the one on the receiving end. Happens :) (especially when I=92m not as careful/pedantic as I can be = sometimes..). Thanks! --Apple-Mail=_36F18C1A-C62C-40E6-95A5-F3B98FCCD7CE 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 iQEcBAEBCgAGBQJVNiTaAAoJEMZr5QU6S73enl8H/jJESbXU65IMV8zPOPOSiaWX OynNLMUX33Mfn3Uj/KBBJK6PB7AnZSqUKltMNmNZm7A/tRlOSFi8iwwrf2q9eCFv /GWzfKXzcp8gfl2yA1e96hOp6OxVb40orV94f2zrbXvUHASCCaOJvaF/moY8TE11 a8BJUuahv1pdEozRbBAK/7fd7GI/fBhC7eUBOdMHJLgyi24t+UNffqIblv5tmD5Z MN8oRVUvmefI/QKQaiVaNo61eplL+aHbHfbEO433ReGUTQAcMTR+5PBK8WGvZC12 UE6tD5B8Ugarp5AnHRUx3WtMF/4imXBEyZXAivdwPk6hIdhXSIG1HhEsBzrsM/U= =HDbw -----END PGP SIGNATURE----- --Apple-Mail=_36F18C1A-C62C-40E6-95A5-F3B98FCCD7CE-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 11:10:44 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 C17A2F70; Tue, 21 Apr 2015 11:10:44 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 7917D1747; Tue, 21 Apr 2015 11:10:44 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YkVW2-000PNQ-Du; Tue, 21 Apr 2015 13:34:54 +0300 Date: Tue, 21 Apr 2015 13:34:54 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Cc: ports@FreeBSD.org, current@FreeBSD.org, stable@FreeBSD.org Subject: Re: pkg 1.5.0 is out Message-ID: <20150421103454.GR1394@zxy.spb.ru> References: <20150414200459.GE39658@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150414200459.GE39658@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 21 Apr 2015 11:10:44 -0000 On Tue, Apr 14, 2015 at 10:05:00PM +0200, Baptiste Daroussin wrote: > Hi all, > > Final pkg 1.5.0 has been released. pkg 1.5.1 at 'pkg upgrade' propose === New packages to be INSTALLED: nvidia-driver: 346.47 linux-c6-libGLU: 10.1 === I am use nvidia-driver-340: # pkg info nvidia-driver-340-340.76 nvidia-driver-340-340.76 Name : nvidia-driver-340 Version : 340.76 Installed on : Tue Mar 10 16:15:59 MSK 2015 Origin : x11/nvidia-driver-340 Architecture : freebsd:10:x86:64 Prefix : /usr/local Categories : x11 kld Licenses : NVIDIA Maintainer : danfe@FreeBSD.org WWW : http://www.nvidia.com/object/unix.html Comment : NVidia graphics card binary drivers for hardware OpenGL rendering Options : ACPI_PM : on DOCS : on LINUX : on WBINVD : off Shared Libs required: libXext.so.6 libX11.so.6 Shared Libs provided: libvdpau_nvidia.so.1 libnvidia-glsi.so.1 libnvidia-glcore.so.1 libnvidia-eglcore.so.1 libnvidia-cfg.so.1 libglx.so.1 libGLESv2.so.2 libGLESv1_CM.so.1 libGL.so.1 libEGL.so.1 Annotations : repo_type : binary repository : ivs Flat size : 209MiB From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 17:43:23 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 E64A3E17 for ; Tue, 21 Apr 2015 17:43:23 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 C89E916A1 for ; Tue, 21 Apr 2015 17:43:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t3LHhNNl089709 for ; Tue, 21 Apr 2015 17:43:23 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t3LHhNxV089707 for freebsd-current@freebsd.org; Tue, 21 Apr 2015 17:43:23 GMT (envelope-from bdrewery) Received: (qmail 95348 invoked from network); 21 Apr 2015 12:43:21 -0500 Received: from unknown (HELO ?10.10.1.139?) (freebsd@shatow.net@10.10.1.139) by sweb.xzibition.com with ESMTPA; 21 Apr 2015 12:43:21 -0500 Message-ID: <55368C3B.3010302@FreeBSD.org> Date: Tue, 21 Apr 2015 12:43:23 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Pedro Giffuni CC: FreeBSD Current Subject: Re: [Heads up] : You may need to update your gcc ports. References: <55217362.5040700@FreeBSD.org> <552188BF.5040501@FreeBSD.org> In-Reply-To: <552188BF.5040501@FreeBSD.org> OpenPGP: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W43gcTTxgg2GLHMwlL23w56tomQbUTVA4" 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, 21 Apr 2015 17:43:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W43gcTTxgg2GLHMwlL23w56tomQbUTVA4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/5/2015 2:10 PM, Pedro Giffuni wrote: > I don't know if someone is keeping up-to-date packages for -current > but I will hold the headers update for a while to help such cases. >=20 We build head packages _at least_ once a week. Currently we always update the system from head and force rebuild all packages. It would catch your case fine and rebuild. Regards, Bryan Drewery --W43gcTTxgg2GLHMwlL23w56tomQbUTVA4 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 iQEcBAEBAgAGBQJVNow7AAoJEDXXcbtuRpfPdZAIANz9tj+R9OOqQKI4CBhCLzTg EgI707gV5xNA0ouw57HBWOxPxRk/9zxR1F3FapDug58Y74P8hsGc8DaiHcaHeEqR A2QQSqgonmhIJqQ/yqik7rmL5i/GsnnreaknjjxEWP8S6LVfMElG/uXklip0YMTD ys+L0HEQtxSNHkqfYaeS6reIcQNdN7SHBdD8Hz6chPOT8hYEL7/w47dZbYoAIjDA kgD+sORO1wTihDjPexQlk9EFD1AmSRlOZ72KDuq2FWpRc4imIw6wZn5Oj7qFvAbu 4A0ZpTuBz3t409x9lt/FDVnuT/TC9QuoXu6kDjewmF6Q14zkLI6Ar1Z7vXsVe8k= =CNt4 -----END PGP SIGNATURE----- --W43gcTTxgg2GLHMwlL23w56tomQbUTVA4-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 18:33: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 56A02C1C for ; Tue, 21 Apr 2015 18:33:54 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 32B621C4E for ; Tue, 21 Apr 2015 18:33:53 +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 16E54A4A57 for ; Tue, 21 Apr 2015 18:33:47 +0000 (UTC) Message-ID: <55369814.5060000@freebsd.org> Date: Tue, 21 Apr 2015 14:33:56 -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: [Heads up] : You may need to update your gcc ports. References: <55217362.5040700@FreeBSD.org> In-Reply-To: <55217362.5040700@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V2wqTJP4ElKUjfKCqw3G3t1B3s78dDU5u" 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, 21 Apr 2015 18:33:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V2wqTJP4ElKUjfKCqw3G3t1B3s78dDU5u Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-04-05 13:39, Pedro Giffuni wrote: > Hello; >=20 > I was going to add this to the UPDATING file but this file is not meant= > for changes affecting ports so here it goes instead: >=20 > 20150415: > Our libc headers are starting to use gcc-style attributes to hi= nt > the compiler about probable optimizations or errors. Unfortunat= ely > gcc from ports does some bogus "fixing" of our system headers a= nd > carries them internally so you may have to update your gcc port= s so > that they grab the complete system headers and particularly the= > cdefs.h file changes from r280801. >=20 >=20 > This basically affects only -current users that haven't rebuilt their g= cc > ports in a week. >=20 > Sorry for the inconvenience, >=20 > Pedro. > _______________________________________________ > 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" There is a separate UPDATING file for ports, where it might make sense to include this message. --=20 Allan Jude --V2wqTJP4ElKUjfKCqw3G3t1B3s78dDU5u 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) iQIcBAEBAgAGBQJVNpgXAAoJEJrBFpNRJZKfoZ0P/is26bqSpi+WmUfcWibzk3zA xhS1ZEv+6/Qd+S7SGkxrDWPHFn5gQael6nX+ZBEOBs7L35uTGo2EeOtIbbXeOYpN +TZ+fvuiOTi2MNv9OEesioQla8NND222Zo85a8Tn8rhsJIT2hkcK0HtyfRJ1c7AS bd5gfJUKmCpELZE7DCKDXZyRNpWWHyHNtz4+Txb8FIPuJpQOk9yg6bAGuxdDBzP2 gDzYW7u8BYTuiKioeFmBY5IefnxON0DObZ7FaVKGYxmUbTLta++qTxWWHhRMn5zy rv3lqe6PM8+GFdt9mrVzo81XMVpYULokukQfaxTytJlpAzPP1Oedd6YQHkIIsUOW UfArFt2ZopXPlFfsjpVScfXMrS7jiydUo6E6DMuh7bqAMtGuJyDcIWlT7m64eDoh NivYp17ZsaYmsOGgZC7yy1F3Rk1i6GrQVSY8Wfj2TkGF/dkfX2y8fvdPy8V1T4C8 WRM5ZxstZ8n4e1U2OmqlfqFtodEy7QQv7oCqYMbNB4X5gDQ+/a6K5jyHrn+mLIVP 302Zd3HzMR0w6Oo3lVsOqRTfJkjvgp5OBJOhor0RQZWthYQd8lHMbi2Alp88Gv0e twsyGDdzxm04ZKoc/Sc6tI9vKzbdXEf9WGLnGl7aWuir0ySYL3ui13JmSniJGOtU T90F4p8uiZGCNoAKtxel =X7t5 -----END PGP SIGNATURE----- --V2wqTJP4ElKUjfKCqw3G3t1B3s78dDU5u-- From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 19:23: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 86AF6A6F; Tue, 21 Apr 2015 19:23:28 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::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 50DFF1171; Tue, 21 Apr 2015 19:23:28 +0000 (UTC) Received: by iebrs15 with SMTP id rs15so21599882ieb.3; Tue, 21 Apr 2015 12:23:27 -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=t8rA24C99axlYE6TtWW+8AuoXaR4oJw/Y4i4Xq5Dybc=; b=UIOHQXGiaQdmyMtInm3p27OnGsyWxOc/WUJldSkmN1kqHFv+ikjoq/Kaz3yi9pH3f5 Sl5g8eRwQMphlaH7daQkCib9kThcOk7sZ3wpVDyW3fK3euE6XHbLNd80apt6jCGC4RVj HuUHNvkclJiqoMHhSsR/2kBCRqPgA/xtiH+HHpOt8WwUSq/Xxl3apOOOXeWibbCwwaVN UQ0ivkhh/g0B5HI5SMZZpZpSt5Tjb8c3REXhEf6WT7MjNmdS6Z75/9SHR0ZdCfV8gzZQ J7hzUZrOfyYylzYTmvsnS9nRzhMMca1a+gNPil5mTq4xNVhJ4TEzSqGzRny0MRUrPifD iW+g== MIME-Version: 1.0 X-Received: by 10.50.64.244 with SMTP id r20mr30649849igs.48.1429644207789; Tue, 21 Apr 2015 12:23:27 -0700 (PDT) Received: by 10.36.51.129 with HTTP; Tue, 21 Apr 2015 12:23:27 -0700 (PDT) In-Reply-To: <2408123.McWtPaBMsU@akita> References: <2408123.McWtPaBMsU@akita> Date: Tue, 21 Apr 2015 21:23:27 +0200 Message-ID: Subject: Re: CTF: wpa_supplicant/hostapd 2.4 import From: "Ranjan1018 ." <214748mv@gmail.com> To: Rui Paulo Cc: "freebsd-wireless@freebsd.org" , 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: Tue, 21 Apr 2015 19:23:28 -0000 2015-04-19 23:35 GMT+02:00 Rui Paulo : > Hi, > > Please test the new wpa_supplicant/hostapd. Here's the patch against > FreeBSD > HEAD: > > https://people.freebsd.org/~rpaulo/wpa-2.4.diff > > Thanks, > > It works for me with LAGG(4). # uname -a FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r281782M: Mon Apr 20 21:31:22 CEST 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC amd64 # ifconfig ath0: flags=8843 metric 0 mtu 2290 ether 18:67:b0:39:bd:23 nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng status: associated re0: flags=8843 metric 0 mtu 1500 options=8209b ether 18:67:b0:39:bd:23 nd6 options=29 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 groups: lo lagg0: flags=8843 metric 0 mtu 1500 ether 18:67:b0:39:bd:23 inet 192.168.0.51 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=29 media: Ethernet autoselect status: active groups: lagg laggproto failover lagghash l2,l3,l4 laggport: re0 flags=1 laggport: wlan0 flags=4 wlan0: flags=8843 metric 0 mtu 1500 ether 18:67:b0:39:bd:23 nd6 options=29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid netis channel 1 (2412 MHz 11g ht/20) bssid 08:10:77:53:bc:b5 regdomain 101 indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 20 bmiss 7 scanvalid 60 protmode CTS ampdulimit 32k ampdudensity 16 shortgi wme burst roaming MANUAL groups: wlan vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 nd6 options=29 media: Ethernet autoselect status: active tun0: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::1a67:b0ff:fe39:bd23%tun0 prefixlen 64 scopeid 0x7 inet 10.7.0.6 --> 10.7.0.5 netmask 0xffffffff nd6 options=21 groups: tun Opened by PID 990 tun1: flags=8051 metric 0 mtu 1500 options=80000 inet6 fe80::1a67:b0ff:fe39:bd23%tun1 prefixlen 64 scopeid 0x8 inet 10.8.0.14 --> 10.8.0.13 netmask 0xffffffff nd6 options=21 groups: tun Opened by PID 997 Regards Maurizio From owner-freebsd-current@FreeBSD.ORG Tue Apr 21 19:30:22 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 32C8DC3A for ; Tue, 21 Apr 2015 19:30:22 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F215811C0 for ; Tue, 21 Apr 2015 19:30:21 +0000 (UTC) Received: by igbhj9 with SMTP id hj9so24378507igb.1 for ; Tue, 21 Apr 2015 12:30:21 -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:content-type; bh=mgMxbg1haq7tD7mupcB3+ENjYpuMliYrvcC4NAxjdGo=; b=wFSZ0QLjtpuALJOC7KT97F820qkRnLQs4IbL9v+vAMu7pRKWMIv2C/6nDC3GC/LdWa LtSOn3BZ/fCpp4np6BvsUmIpIbCGfVPUbnXlXxyS0MZjdn+JumCszDoxk46txHk4FRiC PsE9TuRAFDcUXRYqKUBSGjbefBlUqJyTO58MDkTIEcdLmEPsD0RYijcSV+oOt6sjNa+K wqmV2/Mm6xxV14Y4M2RGJMNc8ySKnShycZGIkKHDqkj3/EKSm8z/Xs+bQdwhudtXgMT8 9661I+nfUOkLT/3B19FEEo6mouaDqa4WRDOxjlwmknDZHF1OUAuqyGPlGOcaZBF/Gn7O iklQ== MIME-Version: 1.0 X-Received: by 10.107.129.229 with SMTP id l98mr30297406ioi.32.1429644621413; Tue, 21 Apr 2015 12:30:21 -0700 (PDT) Received: by 10.36.51.129 with HTTP; Tue, 21 Apr 2015 12:30:21 -0700 (PDT) Date: Tue, 21 Apr 2015 21:30:21 +0200 Message-ID: Subject: CM6206 USB Audio is mute. From: "Ranjan1018 ." <214748mv@gmail.com> To: 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: Tue, 21 Apr 2015 19:30:22 -0000 Connecting the USB cable the item is recognized: ugen0.5: at usbus0 uaudio0: on usbus0 uaudio0: Play: 48000 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 44100 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. pcm1: on uaudio0 uaudio0: HID volume keys found. Setting it as default unit # sysctl hw.snd.default_unit=1 and playing a song the interrupts count increase: # sysctl hw.snd.verbose=2 # cat /dev/sndstat FreeBSD Audio Driver (64bit 2009061500/amd64) Installed devices: pcm0: on hdaa0 (1p:1v/0r:0v) snddev flags=0x2e7 [pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x00006100, 0x00000004 interrupts 0, underruns 0, feed 0, ready 0 [b:4096/2048/2|bs:4096/2048/2] channel flags=0x6100 {userland} -> feeder_mixer(0x00200010) -> {hardware} pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000 interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:0/0/0] channel flags=0x10000000 {userland} -> feeder_root(0x00000000) -> {hardware} pcm1: at ? kld snd_uaudio (1p:1v/1r:1v) default snddev flags=0x2e6 [pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010/0x00400010, flags 0x00002108, 0x00000044 interrupts 4926, underruns 0, feed 9850, ready 0 [b:6144/3072/2|bs:4096/2048/2] channel flags=0x2108 {userland} -> feeder_mixer(0x00200010) -> feeder_matrix(2.0 -> 4.0) -> {hardware} pcm1:play:dsp1.p0[pcm1:virtual:dsp1.vp0]: spd 44100/48000, fmt 0x00200010, flags 0x1000010c, 0x00000029, pid 1769 (mplayer) interrupts 0, underruns 0, feed 9287, ready 62192 [b:0/0/0|bs:65536/2048/32] channel flags=0x1000010c {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> feeder_rate(0x00200010 q:1 44100 -> 48000) -> {hardware} [pcm1:record:dsp1.r0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000005 interrupts 0, overruns 0, feed 0, hfree 3072, sfree 4096 [b:3072/1536/2|bs:4096/2048/2] channel flags=0x2100 {hardware} -> feeder_root(0x00200010) -> feeder_mixer(0x00200010) -> {userland} pcm1:record:dsp1.r0[pcm1:virtual:dsp1.vr0]: spd 8000, fmt 0x00100008, flags 0x10000000, 0x00000000 interrupts 0, overruns 0, feed 0, hfree 0, sfree 0 [b:0/0/0|bs:0/0/0] channel flags=0x10000000 {hardware} -> feeder_root(0x00000000) -> {userland} But the output is mute. In Debian Linux it works: # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 014: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device # aplay -l **** List of PLAYBACK Hardware Devices **** card 1: Device [USB Sound Device], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 Looking at http://lxr.free-electrons.com/source/sound/usb/quirks.c I have found this code: /* 632 * C-Media CM106/CM106+ have four 16-bit internal registers that are nicely 633 * documented in the device's data sheet. 634 */ 635 static int snd_usb_cm106_write_int_reg(struct usb_device *dev, int reg, u16 value) 636 { 637 u8 buf[4]; 638 buf[0] = 0x20; 639 buf[1] = value & 0xff; 640 buf[2] = (value >> 8) & 0xff; 641 buf[3] = reg; 642 return snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), USB_REQ_SET_CONFIGURATION, 643 USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_ENDPOINT, 644 0, 0, &buf, 4); 645 } 646 647 static int snd_usb_cm106_boot_quirk(struct usb_device *dev) 648 { 649 /* 650 * Enable line-out driver mode, set headphone source to front 651 * channels, enable stereo mic. 652 */ 653 return snd_usb_cm106_write_int_reg(dev, 2, 0x8004); 654 } 655 656 /* 657 * C-Media CM6206 is based on CM106 with two additional 658 * registers that are not documented in the data sheet. 659 * Values here are chosen based on sniffing USB traffic 660 * under Windows. 661 */ 662 static int snd_usb_cm6206_boot_quirk(struct usb_device *dev) 663 { 664 int err = 0, reg; 665 int val[] = {0x2004, 0x3000, 0xf800, 0x143f, 0x0000, 0x3000}; 666 667 for (reg = 0; reg < ARRAY_SIZE(val); reg++) { 668 err = snd_usb_cm106_write_int_reg(dev, reg, val[reg]); 669 if (err < 0) 670 return err; 671 } 672 673 return err; 674 } 675 How can I test this code in FreeBSD ? Thanks, Maurizio From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 01: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 DAF2F81D for ; Wed, 22 Apr 2015 01:04:58 +0000 (UTC) Received: from nm45-vm8.bullet.mail.bf1.yahoo.com (nm45-vm8.bullet.mail.bf1.yahoo.com [216.109.115.79]) (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 89950154A for ; Wed, 22 Apr 2015 01:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1429664297; bh=JaeND1AGAScoK19aWF8Iuqno8cnB/nxHT3OiKZNL+og=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=DCVDRhWnxKl7Y5eMBjv8WwHXf8XiXTeYHowrt5fvKAtQidL74ngr3hxa1fj1wYITOOKiHIyMs2Z0VrS2n5QBCDHB1bsRzIHSXgQ6YUNwt9oZ6gL4LlbGLmCltIc1Oy1k82VuNsrR3pWMHtwdQtfuHFWWsLvFzuGxLneXsg7AsJJpB0dArN9Q/xNvPa6hVahMksmU8e5Y20EJTqh0BoixEtly6COoRyDyA7Ui4NqrtJW2R2hzPAcv6XckayTSDsAMMXOsuvD1VZbADXYFSlJPt4PWYHEmvdxg5BJCddZMQzFEGulsqlb/Pmg1zzlQojLWIcITRl8aMBOurWnpaNLloQ== Received: from [98.139.215.140] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 00:58:17 -0000 Received: from [68.142.230.77] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 00:58:17 -0000 Received: from [127.0.0.1] by smtp234.mail.bf1.yahoo.com with NNFMP; 22 Apr 2015 00:58:17 -0000 X-Yahoo-Newman-Id: 766742.38676.bm@smtp234.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Zep73UgVM1mlCzkSvdkb10pZSUEP8EF.pUr8FJL4awGqv.i yGNTUBrlj2m8HDCy7vQwJwbi2vuen6ewLr0Dq_m6QbPavVq0AYM..yM4Xkt5 k3Qft2QIOSnU.SdSaBMwTKSm3W31pOPi3rEDg0elpk3fjwGAhi8sJVQVqB3H esRGTSTep914CWT9pnHvd1ukJebOneQuvPmRYtJeS6ayFk9O97yzfJvdvlvY OpJjIztVFQ3ZqRrHwSHMFKoIgSLr30XnD2l4bzBfZuqtGwAa83jFZ9J3Hs3A vPeyKlRILgp.keU4ZPUf11bVia4CYj9q.VCXtSt4ujygj6L7iM.J1Wu0Oqm2 QeuvTmUNIONMTsGu6RYeD.U7b6qdBe1pSRo30CmMuK0GYYtT.Jrwz7AsEX3X 04YROXyyteBSLBhsAQXwuGmw.gq9SArk5EaxUwpLplFYW7_2XKTInny.aimz DLEnN0AjbqW_hjFIf3yxg_C1u2q2xDq34SNMkx94dXVbYCZvEGWVhBgVkrbl iihBODhjmYuS.5XD77z7IgtpBmHUyas1U X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <5536F227.3010607@FreeBSD.org> Date: Tue, 21 Apr 2015 19:58:15 -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: Bryan Drewery CC: FreeBSD Current Subject: Re: [Heads up] : You may need to update your gcc ports. References: <55217362.5040700@FreeBSD.org> <552188BF.5040501@FreeBSD.org> <55368C3B.3010302@FreeBSD.org> In-Reply-To: <55368C3B.3010302@FreeBSD.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: Wed, 22 Apr 2015 01:04:58 -0000 On 04/21/15 12:43, Bryan Drewery wrote: > On 4/5/2015 2:10 PM, Pedro Giffuni wrote: >> I don't know if someone is keeping up-to-date packages for -current >> but I will hold the headers update for a while to help such cases. >> > We build head packages _at least_ once a week. Currently we always > update the system from head and force rebuild all packages. It would > catch your case fine and rebuild. Excellent! I will be bringing a couple of more attributes that are useful. FWIW, as hint for those wanting to avoid rebuilding/upgrading packages: "As a stop gap measure you could use run the equivalent of $PREFIX/libexec/gcc/i386-unknown-freebsd10.1/5.0.0/install-tools/fixinc.sh " Pedro. From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 07:39: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 A7E34BD7 for ; Wed, 22 Apr 2015 07:39:29 +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 336CE1BB4 for ; Wed, 22 Apr 2015 07:39:29 +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 5481C1FE023; Wed, 22 Apr 2015 09:39:27 +0200 (CEST) Message-ID: <55375060.2060705@selasky.org> Date: Wed, 22 Apr 2015 09:40:16 +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: "Ranjan1018 ." <214748mv@gmail.com>, FreeBSD CURRENT Subject: Re: CM6206 USB Audio is mute. References: 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: Wed, 22 Apr 2015 07:39:29 -0000 On 04/21/15 21:30, Ranjan1018 . wrote: > Connecting the USB cable the item is recognized: > ugen0.5: at usbus0 > uaudio0: > on usbus0 > uaudio0: Play: 48000 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Play: 44100 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. > uaudio0: No MIDI sequencer. > pcm1: on uaudio0 > uaudio0: HID volume keys found. > Hi, Did you check: mixer -f /dev/mixerX that sound volume is OK? > Setting it as default unit > # sysctl hw.snd.default_unit=1 > and playing a song the interrupts count increase: Some volume knobs might be hidden. Try to get all: sysctl -a | grep pcm > But the output is mute. > > In Debian Linux it works: > # lsusb > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 002 Device 014: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound > Device > # aplay -l > **** List of PLAYBACK Hardware Devices **** > card 1: Device [USB Sound Device], device 0: USB Audio [USB Audio] > Subdevices: 0/1 > Subdevice #0: subdevice #0 > > Looking at http://lxr.free-electrons.com/source/sound/usb/quirks.c I have > found this code: > /* > 632 * C-Media CM106/CM106+ have four 16-bit internal registers that are > nicely > 633 * documented in the device's data sheet. > 634 */ > 635 static int snd_usb_cm106_write_int_reg(struct usb_device *dev, int reg, > u16 value) > 636 { > 637 u8 buf[4]; > 638 buf[0] = 0x20; > 639 buf[1] = value & 0xff; > 640 buf[2] = (value >> 8) & 0xff; > 641 buf[3] = reg; > 642 return snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), > USB_REQ_SET_CONFIGURATION, > 643 USB_DIR_OUT | USB_TYPE_CLASS | > USB_RECIP_ENDPOINT, > 644 0, 0, &buf, 4); > 645 } This USB control request can be issued from userspace like this (you need to convert all variables below into constants): usbconfig -d X.Y do_request "USB_DIR_OUT | USB_TYPE_CLASS | > USB_RECIP_ENDPOINT" "USB_REQ_SET_CONFIGURATION" 0 0 4 0x20 "(value & 0xff)" "(value >> 8) & 0xff" "reg" Such a command can easily be added like a devd script to run automatically during device attach. > 646 > 647 static int snd_usb_cm106_boot_quirk(struct usb_device *dev) > 648 { > 649 /* > 650 * Enable line-out driver mode, set headphone source to front > 651 * channels, enable stereo mic. > 652 */ > 653 return snd_usb_cm106_write_int_reg(dev, 2, 0x8004); > 654 } > 655 > 656 /* > 657 * C-Media CM6206 is based on CM106 with two additional > 658 * registers that are not documented in the data sheet. > 659 * Values here are chosen based on sniffing USB traffic > 660 * under Windows. > 661 */ > 662 static int snd_usb_cm6206_boot_quirk(struct usb_device *dev) > 663 { > 664 int err = 0, reg; > 665 int val[] = {0x2004, 0x3000, 0xf800, 0x143f, 0x0000, 0x3000}; > 666 > 667 for (reg = 0; reg < ARRAY_SIZE(val); reg++) { > 668 err = snd_usb_cm106_write_int_reg(dev, reg, val[reg]); > 669 if (err < 0) > 670 return err; > 671 } > 672 > 673 return err; > 674 } > 675 > > How can I test this code in FreeBSD ? > See answer above. Please also use -stable or -current when testing. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 08:32: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 A7639553 for ; Wed, 22 Apr 2015 08:32:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9539411CB for ; Wed, 22 Apr 2015 08:32:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 149E3D5A for ; Wed, 22 Apr 2015 08:32:36 +0000 (UTC) Date: Wed, 22 Apr 2015 08:32:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1709362906.39.1429691556932.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #962 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, 22 Apr 2015 08:32:36 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 10:46:14 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 6E9AD9BE for ; Wed, 22 Apr 2015 10:46:14 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (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 05E601F5A for ; Wed, 22 Apr 2015 10:46:13 +0000 (UTC) Received: by wgin8 with SMTP id n8so241655119wgi.0 for ; Wed, 22 Apr 2015 03:46:11 -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:from:resent-message-id:to:cc:subject :in-reply-to:references:mime-version:content-type:content-id :content-transfer-encoding:date:resent-from:resent-to:resent-cc :resent-date; bh=MDz81IhcxrJN4rIKifQTBeH+fqXgOzd1q99VQ6eTXiA=; b=MplL/+QPMy4ZQ1Z5yTs15vMEIJsrz1DeurYDe1XWThTxTm3SwpnAER2CCtyQivhYw2 xHb7BfmeSrKcgXg20/9n44XFddgo6NBl+ACqqfZi8LgaTP18/0nxQhrCa2KqpF1A6GPN EQ7fdyXjg2jWr9q6e2eC9b/fPl74mgmbkax2z1zo9vwMmyM5Gn22TZBQz+ZzoK3o372K 2MrRNIZZ/grQwKBL96+idz6Xk/0x/eJQTSv98eCr3ovstS8Ni+ZKKUB7pbxLyqmAj4kC HJkIs3lg2FiYQkjG4m1qPaEyoEvXCzZE46W/uorYb85o2N3au9lk5lTdhzErfwNsAJzy poxQ== X-Gm-Message-State: ALoCoQlU/Q2nfyTIHoBP2Zn8CpQlnIpM5o+VzPvVlcap0eI9H2UiOjWxgex+eUynar9H0x4pcCsE X-Received: by 10.194.175.70 with SMTP id by6mr50869579wjc.42.1429699571675; Wed, 22 Apr 2015 03:46:11 -0700 (PDT) Received: from clue.co.za ([197.89.111.34]) by mx.google.com with ESMTPSA id g5sm6776938wjr.19.2015.04.22.03.46.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 03:46:11 -0700 (PDT) Message-ID: <55377bf3.653cc20a.6e28.54ad@mx.google.com> From: Ian FREISLICH X-Google-Original-From: Ian FREISLICH Received: from localhost ([127.0.0.1] helo=zen) by clue.co.za with esmtp (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YksAS-0000m1-AI; Wed, 22 Apr 2015 12:46:08 +0200 Resent-Message-Id: To: Rui Paulo cc: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Subject: Re: CTF: wpa_supplicant/hostapd 2.4 import In-Reply-To: <2408123.McWtPaBMsU@akita> References: <2408123.McWtPaBMsU@akita> X-Attribution: BOFH MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2949.1429699452.1@zen> Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Apr 2015 12:44:12 +0200 Resent-From: ianf@capeaugusta.com Resent-To: Rui Paulo Resent-cc: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Resent-Date: Wed, 22 Apr 2015 12:46:08 +0200 X-Mailman-Approved-At: Wed, 22 Apr 2015 11:29:16 +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: Wed, 22 Apr 2015 10:46:14 -0000 Rui Paulo wrote: > Hi, > = > Please test the new wpa_supplicant/hostapd. Here's the patch against Fr= eeBSD = > HEAD: > = > https://people.freebsd.org/~rpaulo/wpa-2.4.diff EAP never actually completes the association. Authentication completes but the link never actually comes up. This configuration worked with the previous wpa_supplicant. Config: network=3D{ ssid=3D"quasar" key_mgmt=3DWPA-EAP eap=3DPEAP identity=3D"zen" password=3D"xxxxxxxxxxxxx" priority=3D8 } RADIUS log: Wed Apr 22 12:28:20 2015 : Auth: Login OK: [zen] (from client AP-PRO-1 por= t 0 cli 00-22-5F-70-A1-DF) Client log: Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Trying to associate with = 00:27:22:6c:0b:8f (SSID=3D'quasar' freq=3D2437 MHz) Apr 22 12:28:20 zen kernel: wlan0: link state changed to UP Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Associated with 00:27:22:= 6c:0b:8f Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-STARTED EA= P authentication started Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-M= ETHOD vendor=3D0 method=3D4 -> NAK Apr 22 12:28:20 zen dhclient[2297]: send_packet: No buffer space available Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-M= ETHOD vendor=3D0 method=3D25 Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-METHOD EAP= vendor 0 method 25 (PEAP) selected Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT = depth=3D1 subject=3D'/C=3DZA/ST=3DWestern Cape/O=3DFreislich Home Network/= OU=3DFreislich Home/CN=3Dfreislich.nom.za/emailAddress=3Dca@freislich.nom.= za' hash=3D79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a= 0 Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT = depth=3D1 subject=3D'/C=3DZA/ST=3DWestern Cape/O=3DFreislich Home Network/= OU=3DFreislich Home/CN=3Dfreislich.nom.za/emailAddress=3Dca@freislich.nom.= za' hash=3D79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a= 0 Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT = depth=3D0 subject=3D'/C=3DZA/ST=3DWestern Cape/L=3DCape Town/O=3DFreislich= Home Network/OU=3DFreislich Home/CN=3Dfreislich.nom.za/emailAddress=3Dca@= freislich.nom.za' hash=3Dea38723d53e84d2574f9edf105cdb904b773479badfedab1f= 8b9d1abbab0c12e Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-MSCHAPV2: Authentication suc= ceeded Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-TLV: TLV Result - Success - = EAP-TLV/Phase2 Completed Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-SUCCESS EA= P authentication completed successfully Apr 22 12:28:21 zen kernel: wlan0: link state changed to DOWN Apr 22 12:28:21 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED b= ssid=3D00:27:22:6c:0b:8f reason=3D0 Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Trying to associate with = 00:27:22:6c:0b:8f (SSID=3D'quasar' freq=3D2437 MHz) Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Associated with 00:27:22:= 6c:0b:8f Apr 22 12:28:24 zen kernel: wlan0: link state changed to UP Apr 22 12:28:24 zen dhclient[2297]: send_packet: No buffer space available Apr 22 12:28:29 zen last message repeated 2 times Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: Authentication with 00:27= :22:6c:0b:8f timed out. Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED b= ssid=3D00:27:22:6c:0b:8f reason=3D3 locally_generated=3D1 Apr 22 12:28:34 zen kernel: wlan0: link state changed to DOWN Ian -- = Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 12:19: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 6AC8E6D0 for ; Wed, 22 Apr 2015 12:19:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 57B3D1959 for ; Wed, 22 Apr 2015 12:19:36 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7D4D2DB7 for ; Wed, 22 Apr 2015 12:19:36 +0000 (UTC) Date: Wed, 22 Apr 2015 12:19:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <710285862.40.1429705176168.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1709362906.39.1429691556932.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1709362906.39.1429691556932.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #963 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: Wed, 22 Apr 2015 12:19:36 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 16:05: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 5C236EEA for ; Wed, 22 Apr 2015 16:05:00 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 21FE912CF for ; Wed, 22 Apr 2015 16:04:59 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 0566D16A50D for ; Wed, 22 Apr 2015 18:04:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd9Ex6ZOWv-P; Wed, 22 Apr 2015 18:04:55 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:65b4:2578:aec8:4cce] (unknown [IPv6:2001:4cb8:3:1:65b4:2578:aec8:4cce]) by smtp.digiware.nl (Postfix) with ESMTP id DEAAA16A4CF for ; Wed, 22 Apr 2015 17:52:30 +0200 (CEST) Message-ID: <5537C3BA.8010206@digiware.nl> Date: Wed, 22 Apr 2015 17:52:26 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: FreeBSD Current Subject: Newer yacc needed for building world 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, 22 Apr 2015 16:05:00 -0000 Hi, [I thought that I've seen talk about this before.] On a customers system I'm trying to build a new world, with a fresh tree. I've deleted lines from other tracks in parallel compilation. --- aslcompilerparse.c --- yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** [aslcompilerparse.c] Error code 2 And I do not find yacc in the tools/tmp tree. So here the buildsystem is in a catch22. And perhaps yacc needs to be added to the buildtools? Probably I can get out of this by first cd /usr/src/usr.bin/yacc make; make install --WjW From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 16:45: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 EB9AAB0D for ; Wed, 22 Apr 2015 16:45:20 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2B0117AD for ; Wed, 22 Apr 2015 16:45:20 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id t3MGjG7Z009400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2015 10:45:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id t3MGjGs0009397; Wed, 22 Apr 2015 10:45:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Wed, 22 Apr 2015 10:45:16 -0600 (MDT) From: Warren Block To: Willem Jan Withagen cc: FreeBSD Current Subject: Re: Newer yacc needed for building world In-Reply-To: <5537C3BA.8010206@digiware.nl> Message-ID: References: <5537C3BA.8010206@digiware.nl> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 22 Apr 2015 10:45:16 -0600 (MDT) 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, 22 Apr 2015 16:45:21 -0000 On Wed, 22 Apr 2015, Willem Jan Withagen wrote: > Hi, > > [I thought that I've seen talk about this before.] > > On a customers system I'm trying to build a new world, with a fresh tree. > I've deleted lines from other tracks in parallel compilation. > > --- aslcompilerparse.c --- > yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y > yacc: 89 shift/reduce conflicts. > yacc: f - maximum table size exceeded > *** [aslcompilerparse.c] Error code 2 > > And I do not find yacc in the tools/tmp tree. > > So here the buildsystem is in a catch22. And perhaps yacc needs to be added > to the buildtools? > > Probably I can get out of this by first > cd /usr/src/usr.bin/yacc > make; make install Yes: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 17:43:18 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 310BD9B6; Wed, 22 Apr 2015 17:43:18 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 11F251E7B; Wed, 22 Apr 2015 17:43:18 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 02F18E34; Wed, 22 Apr 2015 17:43:18 +0000 (UTC) Date: Wed, 22 Apr 2015 17:43:17 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, kib@FreeBSD.org, gjb@FreeBSD.org, rodrigc@FreeBSD.org, andrew@FreeBSD.org Message-ID: <1473512287.44.1429724597962.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_i386 #16 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: 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: Wed, 22 Apr 2015 17:43:18 -0000 See Changes: [rodrigc] Move zlib.c from net to libkern. It is not network-specific code and would be better as part of libkern instead. Move zlib.h and zutil.h from net/ to sys/ Update includes to use sys/zlib.h and sys/zutil.h instead of net/ Submitted by: Steve Kiernan stevek@juniper.net Obtained from: Juniper Networks, Inc. GitHub Pull Request: https://github.com/freebsd/freebsd/pull/28 Relnotes: yes [gjb] Remove the gptboot partition from the arm64 memory stick image, which is not needed/used. Sponsored by: The FreeBSD Foundation [kib] Move some common code from sys/amd64/amd64/machdep.c and sys/i386/i386/machdep.c to new file sys/x86/x86/cpu_machdep.c. Most of the code is related to the idle handling. Discussed with: pluknet Sponsored by: The FreeBSD Foundation [andrew] Add the null implementation of stack_save and stack_save_td. Sponsored by: The FreeBSD Foundation ------------------------------------------ [...truncated 194033 lines...] --- depend_subdir_usb --- --- --- --- depend_subdir_wpi --- --- --- --- depend_subdir_usb --- machine -> --- depend_subdir_wpi --- machine -> --- depend_subdir_usb --- --- --- --- depend_subdir_wpi --- --- --- --- depend_subdir_usb --- x86 -> --- depend_subdir_wpi --- x86 -> --- depend_subdir_usb --- --- opt_bus.h --- ln -sf opt_bus.h --- depend_subdir_wpi --- --- opt_wpi.h --- --- depend_subdir_usb --- --- opt_usb.h --- --- depend_subdir_wpi --- ln -sf opt_wpi.h --- depend_subdir_usb --- ln -sf opt_usb.h --- depend_subdir_wpi --- --- opt_wlan.h --- ln -sf opt_wlan.h --- depend_subdir_usb --- --- vnode_if_newproto.h --- awk -f -p --- depend_subdir_wpi --- --- device_if.h --- awk -f -h --- bus_if.h --- --- depend_subdir_usb --- --- vnode_if_typedef.h --- --- depend_subdir_wpi --- awk -f -h --- depend_subdir_usb --- awk -f -q --- depend_subdir_wpifw --- ===> wpifw (depend) --- depend_subdir_usb --- --- device_if.h --- awk -f -h --- depend_subdir_wpi --- --- pci_if.h --- awk -f -h --- depend_subdir_usb --- --- bus_if.h --- awk -f -h --- depend_subdir_wpi --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I -I -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 --- depend_subdir_usb --- --- usb_if.h --- awk -f -h --- depend_subdir_wpifw --- --- --- --- depend_subdir_usb --- --- vnode_if.h --- awk -f -h --- depend_subdir_wpifw --- machine -> --- --- x86 -> --- wpifw.c --- awk -f iwlwifi-3945-15.32.2.9.fw:wpifw:153229 -mwpifw -cwpifw.c --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I -I -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 wpifw.c --- depend_subdir_usb --- --- usbdevs.h --- awk -f -h --- depend_subdir_x86bios --- ===> x86bios (depend) --- depend_subdir_xe --- ===> xe (depend) --- depend_subdir_x86bios --- --- --- machine -> --- --- x86 -> --- opt_x86bios.h --- ln -sf opt_x86bios.h --- bus_if.h --- awk -f -h --- depend_subdir_xe --- --- --- machine -> --- depend_subdir_xl --- --- depend_subdir_xe --- --- --- --- depend_subdir_xl --- ===> xl (depend) --- depend_subdir_xe --- x86 -> --- depend_subdir_x86bios --- --- device_if.h --- --- depend_subdir_xe --- --- bus_if.h --- --- depend_subdir_x86bios --- awk -f -h --- depend_subdir_xe --- awk -f -h --- depend_subdir_x86bios --- --- pci_if.h --- awk -f -h --- depend_subdir_xe --- --- card_if.h --- awk -f -h --- depend_subdir_x86bios --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I -I -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 --- depend_subdir_xe --- --- device_if.h --- awk -f -h --- depend_subdir_xl --- --- --- --- depend_subdir_xe --- --- pccarddevs.h --- --- depend_subdir_xl --- machine -> --- depend_subdir_xe --- awk -f --- depend_subdir_xl --- --- --- x86 -> --- bus_if.h --- awk -f -h --- device_if.h --- awk -f -h --- miibus_if.h --- awk -f -h --- depend_subdir_xe --- --- .depend --- --- depend_subdir_zfs --- --- depend_subdir_xe --- rm -f .depend --- depend_subdir_zfs --- ===> zfs (depend) --- depend_subdir_xe --- CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I -I -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 --- depend_subdir_xl --- --- miidevs.h --- awk -f --- pci_if.h --- awk -f -h --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I -I -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 --- depend_subdir_zfs --- --- --- machine -> --- --- x86 -> --- vnode_if_newproto.h --- awk -f -p --- vnode_if_typedef.h --- --- depend_subdir_zlib --- --- depend_subdir_zfs --- awk -f -q --- depend_subdir_zlib --- ===> zlib (depend) --- depend_subdir_zfs --- --- bus_if.h --- awk -f -h --- depend_subdir_usb --- --- depend_subdir_uhid --- --- depend_subdir_zfs --- --- device_if.h --- --- depend_subdir_usb --- ===> usb/uhid (depend) --- depend_subdir_zfs --- awk -f -h --- depend_subdir_usb --- --- depend_subdir_atp --- --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I -I -D__printf__=__freebsd_kprintf__ -std=iso9899:1999 --- depend_subdir_zfs --- --- vnode_if.h --- awk -f -h --- depend_subdir_zlib --- --- --- machine -> --- --- x86 -> make[4]: make[4]: don't know how to make zlib.c. Stop make[4]: stopped in *** [depend_subdir_zlib] Error code 2 make[3]: stopped in --- depend_subdir_zfs --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [depend_subdir_zfs] Error code 2 make[3]: stopped in --- depend_subdir_usb --- --- depend_subdir_uhid --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [depend_subdir_uhid] Error code 2 make[4]: stopped in --- depend_subdir_atp --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [depend_subdir_atp] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in *** [depend_subdir_usb] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [modules-depend] 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 Wed Apr 22 18:50: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 2A6EA91A for ; Wed, 22 Apr 2015 18:50:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1929C1587 for ; Wed, 22 Apr 2015 18:50:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6D11FE4C for ; Wed, 22 Apr 2015 18:50:04 +0000 (UTC) Date: Wed, 22 Apr 2015 18:50:04 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1965504384.45.1429728604170.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #964 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, 22 Apr 2015 18:50:04 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 19:55: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 66AFD3D6 for ; Wed, 22 Apr 2015 19:55:28 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 297C11DD8 for ; Wed, 22 Apr 2015 19:55:28 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 376F316A531; Wed, 22 Apr 2015 21:55:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ct6WiaApMey; Wed, 22 Apr 2015 21:55:14 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:f9ee:b7ef:2371:dea6] (unknown [IPv6:2001:4cb8:3:1:f9ee:b7ef:2371:dea6]) by smtp.digiware.nl (Postfix) with ESMTPA id D0F0116A559; Wed, 22 Apr 2015 21:55:14 +0200 (CEST) Message-ID: <5537FCA1.6010108@digiware.nl> Date: Wed, 22 Apr 2015 21:55:13 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Warren Block CC: FreeBSD Current Subject: Re: Newer yacc needed for building world References: <5537C3BA.8010206@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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, 22 Apr 2015 19:55:28 -0000 On 22/04/2015 18:45, Warren Block wrote: > On Wed, 22 Apr 2015, Willem Jan Withagen wrote: > >> Hi, >> >> [I thought that I've seen talk about this before.] >> >> On a customers system I'm trying to build a new world, with a fresh tree. >> I've deleted lines from other tracks in parallel compilation. >> >> --- aslcompilerparse.c --- >> yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y >> yacc: 89 shift/reduce conflicts. >> yacc: f - maximum table size exceeded >> *** [aslcompilerparse.c] Error code 2 >> >> And I do not find yacc in the tools/tmp tree. >> >> So here the buildsystem is in a catch22. And perhaps yacc needs to be >> added to the buildtools? >> >> Probably I can get out of this by first >> cd /usr/src/usr.bin/yacc >> make; make install > > Yes: > https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html > But this is not enough to make yacc part of the build tools?? --WjW From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 20:42:19 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 7D5A6FA3; Wed, 22 Apr 2015 20:42:19 +0000 (UTC) Received: from st11p00im-asmtp001.me.com (st11p00im-asmtp001.me.com [17.172.80.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 583F012EC; Wed, 22 Apr 2015 20:42:19 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NN200AKAK1YQW10@st11p00im-asmtp001.me.com>; Sun, 19 Apr 2015 19:41:59 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-19_03:2015-04-17,2015-04-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504190175 From: Rui Paulo To: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Subject: CTF: wpa_supplicant/hostapd 2.4 import Date: Sun, 19 Apr 2015 12:41:57 -0700 Message-id: <1537009.8hcWOSdFGB@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii 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, 22 Apr 2015 20:42:19 -0000 Hi, Please test the new wpa_supplicant/hostapd. Here's the patch against FreeBSD HEAD: https://people.freebsd.org/~rpaulo/wpa-2.4.diff Thanks, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 21:37:38 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 A5C93BC1 for ; Wed, 22 Apr 2015 21:37:38 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::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 704B918A3 for ; Wed, 22 Apr 2015 21:37:38 +0000 (UTC) Received: by iebrs15 with SMTP id rs15so47936459ieb.3 for ; Wed, 22 Apr 2015 14:37:38 -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:from:date:message-id :subject:to:cc:content-type; bh=5MYLJA9PIC/iC/ZYNHBca+n5ZbhZc7THMLuAU7GIYJ4=; b=0cgSC8LOmOq5aqSTydQDWVlVqBtQBn06Xy8cJSZHxj9v96OBJaBcGOuNAK3fyvbfEL oAQ7aB2aCNyrlA4sa20lwpEo5z5wDdUa3PBgkyG+4X5hRI4OEtOyINAxqwp84xTWBEMz J3pwAax7yR5sU766i2rGJLTooK3MkAbSY5vtdRqEzmtmeSdIaBka5GF0JD72IFEclgYx zHG4vg/Q22M6pvwjIlebkc3p3w5x+cX0oKR5jtooRni/nNoR6/49AEVZn+pHlmWSCjNy qKCn3pX9la9eSPwcFyRBS3n6O0tiMEGAZ8HyPeVCY4ftRjPM+/KwNHHN1tBGgID3htm6 Polg== X-Received: by 10.50.50.74 with SMTP id a10mr7499104igo.21.1429738657908; Wed, 22 Apr 2015 14:37:37 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.48.3 with HTTP; Wed, 22 Apr 2015 14:37:17 -0700 (PDT) In-Reply-To: <5537FCA1.6010108@digiware.nl> References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> From: Ed Maste Date: Wed, 22 Apr 2015 17:37:17 -0400 X-Google-Sender-Auth: bLCzroyEPdxPDr4OlR1TztGjtjM Message-ID: Subject: Re: Newer yacc needed for building world To: Willem Jan Withagen Cc: Warren Block , 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: Wed, 22 Apr 2015 21:37:38 -0000 On 22 April 2015 at 15:55, Willem Jan Withagen wrote: > > > Yes: > > https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html > > > > But this is not enough to make yacc part of the build tools?? yacc is unconditionally built during bootstrap-tools as of r281615. What SVN rev is your tree? From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 21:58: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 4D9046AF; Wed, 22 Apr 2015 21:58:05 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 0D9901ADA; Wed, 22 Apr 2015 21:58:05 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id F06AF16A57A; Wed, 22 Apr 2015 23:58:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gicloq_3jX8V; Wed, 22 Apr 2015 23:58:01 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:254d:b807:25f8:f916] (unknown [IPv6:2001:4cb8:3:1:254d:b807:25f8:f916]) by smtp.digiware.nl (Postfix) with ESMTP id 5EDB116A572; Wed, 22 Apr 2015 23:58:01 +0200 (CEST) Message-ID: <55381961.2040104@digiware.nl> Date: Wed, 22 Apr 2015 23:57:53 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ed Maste CC: Warren Block , FreeBSD Current Subject: Re: Newer yacc needed for building world References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> 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: Wed, 22 Apr 2015 21:58:05 -0000 On 22-4-2015 23:37, Ed Maste wrote: > On 22 April 2015 at 15:55, Willem Jan Withagen wrote: >> >>> Yes: >>> https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html >>> >> >> But this is not enough to make yacc part of the build tools?? > > yacc is unconditionally built during bootstrap-tools as of r281615. > What SVN rev is your tree? > Can't get to the system atm, but freshly fetched this afternoon (GMT). Doing the recover trick as described above did the work. So it is hard to retest, other than to throw away /usr/bin/yacc and what comes of it. Given the fact that I found that I had more issues after my freebsd-upgrade of that system, it could be very well that this was a problem as a result of the same. Even though it was a fresh checkout. I'll do the yacc rename trick, and see if it still barks at me. If so I'll get back here. regards, --WjW From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 23:04:48 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 DAF53333 for ; Wed, 22 Apr 2015 23:04:48 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id C51BA1230 for ; Wed, 22 Apr 2015 23:04:48 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id C204EEA7 for ; Wed, 22 Apr 2015 23:04:48 +0000 (UTC) Date: Wed, 22 Apr 2015 23:04:48 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1023552827.46.1429743888090.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1965504384.45.1429728604170.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1965504384.45.1429728604170.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #965 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: Wed, 22 Apr 2015 23:04:49 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 23:13:02 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 1C9D64C4; Wed, 22 Apr 2015 23:13:02 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::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 971CE1311; Wed, 22 Apr 2015 23:13:01 +0000 (UTC) Received: by lagv1 with SMTP id v1so855323lag.3; Wed, 22 Apr 2015 16:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=G9sW6xAQx3aT2f/DYvsSHQuSP683Hy4TLfEUTZYxYXY=; b=l8C7AAImJc4dUyhKhlIvglGqpK1g5DQqDfeVpyEWqwNGtWO8eFoSTcxw9vYhqYBm3F IhurV7fXo4/D2KzHS8tzMyre94A50Qv4Fd9zeplNVrm3WURsi3Ouy1/1UQfuRmD0EfDp 3KhvEQyoY6Lk1gE4IzFiSBV6HpNN3vy9xhd97C+J0A2U+UFioHS+G3NrfEpwScMzeBy1 i+O+WnX0kqhSroZxqTq97yh+KBz4T4QnHXefINTzHgInRkQVgUNtWepQD8B4FIS8ikPJ w/93Q86xJqe7NKNGglgkNL49IJfgCUiJtVe1w19AkP3OrjdE30n8Jl9nEMffWTu2MeuU QPrA== MIME-Version: 1.0 X-Received: by 10.113.10.134 with SMTP id ea6mr26392914lbd.29.1429744379551; Wed, 22 Apr 2015 16:12:59 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.164.38 with HTTP; Wed, 22 Apr 2015 16:12:59 -0700 (PDT) Date: Wed, 22 Apr 2015 16:12:59 -0700 X-Google-Sender-Auth: 2L9BANvdSWvbzneo490_a8ujHlU Message-ID: Subject: Merging GitHub Pull Requests into Subversion using git-svn From: Craig Rodrigues To: freebsd-git@freebsd.org Cc: freebsd-current Current , ports 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: Wed, 22 Apr 2015 23:13:02 -0000 Hi, Alfred Perlstein recently wrote this document for how to use git-svn for interacting between the FreeBSD Subversion repo, and the GitHub mirror of this repo: https://wiki.freebsd.org/GitWorkflow/GitSvn By following the steps in that article, step-by-step, I was able to: (1) take these three GitHub pull requests from Steve Kiernan: https://github.com/freebsd/freebsd/pull/26 https://github.com/freebsd/freebsd/pull/27 https://github.com/freebsd/freebsd/pull/28 (2) Pull them into my own git checkout of the FreeBSD src tree (3) Modify the commit message slightly (4) Use "git svn dcommit" to push these changes directly from my Git tree back to the FreeBSD svn repo: https://svnweb.freebsd.org/changeset/base/281844 https://svnweb.freebsd.org/changeset/base/281845 https://svnweb.freebsd.org/changeset/base/281855 While there were multiple steps involved, I just followed the steps in the wiki article, and it *just worked*! Thanks for writing this article, Alfred! While not as smooth as clicking a merge button in GitHub, this is a valid way to accept patches submitted via GitHub pull requests, and integrate them in our FreeBSD Subversion repo. -- Craig From owner-freebsd-current@FreeBSD.ORG Wed Apr 22 23:37:14 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 2A4B1CDF for ; Wed, 22 Apr 2015 23:37:14 +0000 (UTC) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (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 EC3771598 for ; Wed, 22 Apr 2015 23:37:13 +0000 (UTC) Received: by oift201 with SMTP id t201so1456899oif.3 for ; Wed, 22 Apr 2015 16:37:07 -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=b1LzF/FMUgB0cw0NWyRalYE5+OLPQ3Ft+5YddHw+pZI=; b=QtlO8BkmUkbfQViTLYKKO7e7pJhEOwaJueFpKFHREOTrljklCJd53IBHsTka5KRtxp WGbxr14qoStY/9601F0pzu8PEqGpKYEa1S3/I12QRoWQ/REJxVDbi9c0vyqP/U52kRnO MW5XRtjl+zEFuPZbtfADgMV4hAFqXjUUkbSt8+W+746g2DXkMVgDIYbUZoXMYngl2rUS 34d70swNnePwvwZzNGpILzC9RwLwgGJHkCr0jaE3EohMAat+oHdwDIWEQ1gjxoP4iVak oWsWehcz3jV54c10CH+cI+58KB3qUExLI4ke9/QdatIPKlt8QXvLzkAb0uvYnE97shjv QTwA== X-Gm-Message-State: ALoCoQmjw4vNIeCf7HZozRx7+gzFnK3m83EHt4OjgcuueDRcZVE2HgPwYfA9slbaSfZWmH0+Uqf7 MIME-Version: 1.0 X-Received: by 10.60.103.234 with SMTP id fz10mr30464oeb.11.1429745826971; Wed, 22 Apr 2015 16:37:06 -0700 (PDT) Received: by 10.202.80.6 with HTTP; Wed, 22 Apr 2015 16:37:06 -0700 (PDT) In-Reply-To: <1537009.8hcWOSdFGB@akita> References: <1537009.8hcWOSdFGB@akita> Date: Thu, 23 Apr 2015 01:37:06 +0200 Message-ID: Subject: Re: CTF: wpa_supplicant/hostapd 2.4 import From: Oliver Pinter To: Rui Paulo Cc: "freebsd-wireless@freebsd.org" , 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: Wed, 22 Apr 2015 23:37:14 -0000 Rui, FYI: http://w1.fi/security/2015-1/wpa_supplicant-p2p-ssid-overflow.txt On Sun, Apr 19, 2015 at 9:41 PM, Rui Paulo wrote: > Hi, > > Please test the new wpa_supplicant/hostapd. Here's the patch against FreeBSD > HEAD: > > https://people.freebsd.org/~rpaulo/wpa-2.4.diff > > Thanks, > -- > Rui Paulo > _______________________________________________ > 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 Apr 23 00:24:20 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 2E8F57CF; Thu, 23 Apr 2015 00:24:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 18DA31B83; Thu, 23 Apr 2015 00:24:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 14F5FEC0; Thu, 23 Apr 2015 00:24:20 +0000 (UTC) Date: Thu, 23 Apr 2015 00:24:20 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org, kib@FreeBSD.org, gjb@FreeBSD.org, loos@FreeBSD.org, andrew@FreeBSD.org, rodrigc@FreeBSD.org, mav@FreeBSD.org, pfg@FreeBSD.org Message-ID: <463387403.47.1429748660051.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1473512287.44.1429724597962.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1473512287.44.1429724597962.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_i386 #17 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-Mailman-Approved-At: Thu, 23 Apr 2015 01:05:53 +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: Thu, 23 Apr 2015 00:24:20 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 02:01:52 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 A118773A; Thu, 23 Apr 2015 02:01:52 +0000 (UTC) Received: from st11p00im-asmtp001.me.com (st11p00im-asmtp001.me.com [17.172.80.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77E841509; Thu, 23 Apr 2015 02:01:52 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NN800KD3LN11420@st11p00im-asmtp001.me.com>; Thu, 23 Apr 2015 02:01:50 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-22_06:2015-04-22,2015-04-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504230023 From: Rui Paulo To: Ian FREISLICH Cc: "freebsd-wireless@freebsd.org" , freebsd-current@freebsd.org Subject: Re: CTF: wpa_supplicant/hostapd 2.4 import Date: Wed, 22 Apr 2015 19:01:48 -0700 Message-id: <3845818.sZ85oEnXDh@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <55377bf3.653cc20a.6e28.54ad@mx.google.com> References: <2408123.McWtPaBMsU@akita> <55377bf3.653cc20a.6e28.54ad@mx.google.com> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii 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, 23 Apr 2015 02:01:52 -0000 On Wednesday 22 April 2015 12:44:12 Ian FREISLICH wrote: > Rui Paulo wrote: > > Hi, > > > > Please test the new wpa_supplicant/hostapd. Here's the patch against > > FreeBSD> > > HEAD: > > https://people.freebsd.org/~rpaulo/wpa-2.4.diff > > EAP never actually completes the association. Authentication > completes but the link never actually comes up. This configuration > worked with the previous wpa_supplicant. > > Config: > network={ > ssid="quasar" > key_mgmt=WPA-EAP > eap=PEAP > identity="zen" > password="xxxxxxxxxxxxx" > priority=8 > } > > > RADIUS log: > Wed Apr 22 12:28:20 2015 : Auth: Login OK: [zen] (from client AP-PRO-1 port > 0 cli 00-22-5F-70-A1-DF) > > Client log: > Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Trying to associate with > 00:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz) Apr 22 12:28:20 zen kernel: > wlan0: link state changed to UP > Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Associated with > 00:27:22:6c:0b:8f Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: > CTRL-EVENT-EAP-STARTED EAP authentication started Apr 22 12:28:20 zen > wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 > method=4 -> NAK Apr 22 12:28:20 zen dhclient[2297]: send_packet: No buffer > space available Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: > CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 Apr 22 12:28:20 zen > wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 > (PEAP) selected Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: > CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich > Home Network/OU=Freislich > Home/CN=freislich.nom.za/emailAddress=ca@freislich.nom.za' > hash=79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a0 Apr > 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT > depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home > Network/OU=Freislich > Home/CN=freislich.nom.za/emailAddress=ca@freislich.nom.za' > hash=79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a0 Apr > 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT > depth=0 subject='/C=ZA/ST=Western Cape/L=Cape Town/O=Freislich Home > Network/OU=Freislich > Home/CN=freislich.nom.za/emailAddress=ca@freislich.nom.za' > hash=ea38723d53e84d2574f9edf105cdb904b773479badfedab1f8b9d1abbab0c12e Apr > 22 12:28:20 zen wpa_supplicant[2191]: EAP-MSCHAPV2: Authentication > succeeded Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-TLV: TLV Result - > Success - EAP-TLV/Phase2 Completed Apr 22 12:28:20 zen > wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication > completed successfully Apr 22 12:28:21 zen kernel: wlan0: link state > changed to DOWN > Apr 22 12:28:21 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED > bssid=00:27:22:6c:0b:8f reason=0 Apr 22 12:28:24 zen wpa_supplicant[2191]: > wlan0: Trying to associate with 00:27:22:6c:0b:8f (SSID='quasar' freq=2437 > MHz) Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Associated with > 00:27:22:6c:0b:8f Apr 22 12:28:24 zen kernel: wlan0: link state changed to > UP > Apr 22 12:28:24 zen dhclient[2297]: send_packet: No buffer space available > Apr 22 12:28:29 zen last message repeated 2 times > Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: Authentication with > 00:27:22:6c:0b:8f timed out. Apr 22 12:28:34 zen wpa_supplicant[2191]: > wlan0: CTRL-EVENT-DISCONNECTED bssid=00:27:22:6c:0b:8f reason=3 > locally_generated=1 Apr 22 12:28:34 zen kernel: wlan0: link state changed > to DOWN Can you send me the log of the previous wpa_supplicant version? -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 03:20: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 9683224E for ; Thu, 23 Apr 2015 03:20: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 75BAE1D9A for ; Thu, 23 Apr 2015 03:20:48 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3N3KhhZ018768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Apr 2015 20:20:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55386505.70708@freebsd.org> Date: Thu, 23 Apr 2015 11:20:37 +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: "current@freebsd.org" Subject: readdir/telldir/seekdir problem (i think) 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: Thu, 23 Apr 2015 03:20:48 -0000 I'm debugging a problem being seen with samba 3.6. basically telldir/seekdir/readdir don't seem to work as advertised.. here's a little test program #include #include #include #include #include #include #include #include #include #include #define CHUNKSIZE 5 #define TOTALFILES 40 static void SeekDir(DIR *dirp, long loc) { printf("Seeking back to location %ld\n", loc); seekdir(dirp, loc); } static long TellDir(DIR *dirp) { long loc; loc = telldir(dirp); printf("telldir assigned location %ld\n", loc); return (loc); } int main(int argc, char *argv[]) { DIR *dirp; int i; int j; long offset = 0, prev_offset = 0; char *files[100]; char filename[100]; int fd; struct dirent *dp = NULL; if (chdir("./test2") != 0) { err(EX_OSERR, "chdir"); } /*****************************************************/ /* Put a set of sample files in the target directory */ /*****************************************************/ for (i=1; i < TOTALFILES ; i++) { sprintf(filename, "file-%d", i); fd = open(filename, O_CREAT, 0666); if (fd == -1) { err(EX_OSERR, "open"); } close(fd); } dirp = opendir("."); offset = TellDir(dirp); for (i = 0; i < 20; i++) files[i] = malloc(20); /*******************************************************/ /* enumerate and delete small sets of files, one group */ /* at a time. */ /*******************************************************/ do { /*****************************************/ /* Read in up to CHUNKSIZE file names */ /* i will be the number of files we hold */ /*****************************************/ for (i = 0; i < CHUNKSIZE; i++) { if ((dp = readdir(dirp)) != NULL) { strcpy(files[i], dp->d_name); printf("readdir (%ld) returned file %s\n", offset, files[i]); prev_offset = offset; offset = TellDir(dirp); } else { printf("readdir returned null\n"); break; } } /****************************************************************/ /* Simuate the last entry not fitting into our (samba's) buffer */ /* If we read someting in on the last slot, push it back */ /* Pretend it didn't fit. This is approximately what SAMBA does.*/ /****************************************************************/ if (dp != NULL) { /* Step back */ SeekDir(dirp, prev_offset); offset = TellDir(dirp); i--; printf("file %s returned\n", files[i]); } /*****************************************/ /* i is the number of names we have left.*/ /* Delete them. */ /*****************************************/ for (j = 0; j < i; j++) { if (*files[j] == '.') { printf ("skipping %s\n", files[j]); } else { printf("Unlinking file %s\n", files[j]); if (unlink(files[j]) != 0) { err(EX_OSERR, "unlink"); } } } } while (dp != NULL); closedir(dirp); //chdir(".."); } The program is simulating what Samba does when fails. (doing a recursive delete of a directory) What it does is reads a chunk of names using readdir() until it's (small) buffer s full, then it uses seekdir() to seek back before the last entry it read, (which fails to fit), theortically leaving it for the next read. It then deletes the entries it found and repeats the cycle. Eventually it should have found all the files in the directory and deleted them. Except that it doesn't. What actually happens is that some files are not enumerated, even though the seekdir() should have made the readdir() find them. for added fun. the FIRST seekdir appears to work. but all subsequent ones don't. It behaves this way in -current , all the way back to at least 8.0. if there's a bug in my program please let me know, but samba has the same problem.. e.g. on freeNAS. to use the program make a directory called "./test2" and then run it in the current directory.. It fills it with files and then tried to (fails) delete them in small batches. here's some (annotated) output: ./testit telldir assigned location 0 readdir (0) returned file . telldir assigned location 1 readdir (1) returned file .. telldir assigned location 2 readdir (2) returned file file-1 telldir assigned location 3 readdir (3) returned file file-2 telldir assigned location 4 readdir (4) returned file file-3 telldir assigned location 5 >>>>> here we pretend the buffer was full and put the file >>>>> marker back so that it will get read next time Seeking back to location 4 telldir assigned location 4 file file-3 returned skipping . skipping .. Unlinking file file-1 Unlinking file file-2 readdir (4) returned file file-3 >>>>> hey it worked (this time) telldir assigned location 5 readdir (5) returned file file-4 telldir assigned location 6 readdir (6) returned file file-5 telldir assigned location 7 readdir (7) returned file file-6 telldir assigned location 8 readdir (8) returned file file-7 telldir assigned location 9 >>>>> OK do it again.. pretend file-7 didn't fit.. >>>>> set the pointer back so we re-read it next time. Seeking back to location 8 telldir assigned location 8 file file-7 returned Unlinking file file-3 Unlinking file file-4 Unlinking file file-5 Unlinking file file-6 >>>>> OK lets go get file-7 again readdir (8) returned file file-9 >>>>> WTF? what happened to file-7 ? telldir assigned location 9 readdir (9) returned file file-10 telldir assigned location 10 From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 03:36:25 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 AD3C8592 for ; Thu, 23 Apr 2015 03:36:25 +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 8D9551EB5 for ; Thu, 23 Apr 2015 03:36:25 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3N3aKKl018838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Apr 2015 20:36:23 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553868AF.8090109@freebsd.org> Date: Thu, 23 Apr 2015 11:36:15 +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: "current@freebsd.org" Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> In-Reply-To: <55386505.70708@freebsd.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, 23 Apr 2015 03:36:25 -0000 On 4/23/15 11:20 AM, Julian Elischer wrote: > I'm debugging a problem being seen with samba 3.6. > > basically telldir/seekdir/readdir don't seem to work as advertised.. On the intergooglewebs I see multiple previous reports of similar problems, some going back 30 years, but we supposedly have the fixes for those in -current. added data point.. if I comment out the 'unlink' lines all the files are enumerated, so it's something similar to the previously reported unlink-vs-readdir bugs. but different. If I insert a rewinddir() after each set of deletes it all works right but that means the system is continuously rereading all the prior directory blocks.. It goes wrong on at least UFS and ZFS. maybe others. I'm not totally sure it can be fixed. If teh underlying directory blocs are reshuffled or changed and things are moved, it may just be impossible to keep any information as to where you are in the directory without adding more state. > here's a little test program > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #define CHUNKSIZE 5 > #define TOTALFILES 40 > > static void > SeekDir(DIR *dirp, long loc) > { > printf("Seeking back to location %ld\n", loc); > seekdir(dirp, loc); > } > > static long > TellDir(DIR *dirp) > { > long loc; > > loc = telldir(dirp); > printf("telldir assigned location %ld\n", loc); > return (loc); > } > > int > main(int argc, char *argv[]) > { > DIR *dirp; > int i; > int j; > long offset = 0, prev_offset = 0; > char *files[100]; > char filename[100]; > int fd; > struct dirent *dp = NULL; > > if (chdir("./test2") != 0) { > err(EX_OSERR, "chdir"); > } > > /*****************************************************/ > /* Put a set of sample files in the target directory */ > /*****************************************************/ > > for (i=1; i < TOTALFILES ; i++) > { > sprintf(filename, "file-%d", i); > fd = open(filename, O_CREAT, 0666); > if (fd == -1) { > err(EX_OSERR, "open"); > } > close(fd); > } > dirp = opendir("."); > offset = TellDir(dirp); > for (i = 0; i < 20; i++) > files[i] = malloc(20); > > /*******************************************************/ > /* enumerate and delete small sets of files, one group */ > /* at a time. */ > /*******************************************************/ > do { > > /*****************************************/ > /* Read in up to CHUNKSIZE file names */ > /* i will be the number of files we hold */ > /*****************************************/ > for (i = 0; i < CHUNKSIZE; i++) { > if ((dp = readdir(dirp)) != NULL) { > strcpy(files[i], dp->d_name); > > printf("readdir (%ld) returned file %s\n", > offset, files[i]); > > prev_offset = offset; > offset = TellDir(dirp); > > } else { > printf("readdir returned null\n"); > break; > } > } > > > /****************************************************************/ > /* Simuate the last entry not fitting into our (samba's) > buffer */ > /* If we read someting in on the last slot, push it > back */ > /* Pretend it didn't fit. This is approximately what SAMBA > does.*/ > /****************************************************************/ > if (dp != NULL) { > /* Step back */ > SeekDir(dirp, prev_offset); > offset = TellDir(dirp); > i--; > printf("file %s returned\n", files[i]); > } > > /*****************************************/ > /* i is the number of names we have left.*/ > /* Delete them. */ > /*****************************************/ > for (j = 0; j < i; j++) { > if (*files[j] == '.') { > printf ("skipping %s\n", files[j]); > } else { > printf("Unlinking file %s\n", files[j]); > if (unlink(files[j]) != 0) { > err(EX_OSERR, "unlink"); > } > } > } > } while (dp != NULL); > > closedir(dirp); > //chdir(".."); > > } > > The program is simulating what Samba does when fails. (doing a > recursive delete of a directory) > What it does is reads a chunk of names using readdir() until it's > (small) buffer s full, > then it uses seekdir() to seek back before the last entry it read, > (which fails to fit), > theortically leaving it for the next read. > It then deletes the entries it found and repeats the cycle. > > Eventually it should have found all the files in the directory and > deleted them. > Except that it doesn't. > > What actually happens is that some files are not enumerated, even > though > the seekdir() should have made the readdir() find them. > for added fun. the FIRST seekdir appears to work. but all subsequent > ones don't. > > It behaves this way in -current , all the way back to at least 8.0. > > if there's a bug in my program please let me know, but samba has the > same problem.. e.g. on freeNAS. > > to use the program make a directory called "./test2" and then run it > in the current directory.. > It fills it with files and then tried to (fails) delete them in > small batches. > > here's some (annotated) output: > > ./testit > telldir assigned location 0 > readdir (0) returned file . > telldir assigned location 1 > readdir (1) returned file .. > telldir assigned location 2 > readdir (2) returned file file-1 > telldir assigned location 3 > readdir (3) returned file file-2 > telldir assigned location 4 > readdir (4) returned file file-3 > telldir assigned location 5 > >>>>> here we pretend the buffer was full and put the file > >>>>> marker back so that it will get read next time > Seeking back to location 4 > telldir assigned location 4 > file file-3 returned > skipping . > skipping .. > Unlinking file file-1 > Unlinking file file-2 > readdir (4) returned file file-3 > >>>>> hey it worked (this time) > telldir assigned location 5 > readdir (5) returned file file-4 > telldir assigned location 6 > readdir (6) returned file file-5 > telldir assigned location 7 > readdir (7) returned file file-6 > telldir assigned location 8 > readdir (8) returned file file-7 > telldir assigned location 9 > >>>>> OK do it again.. pretend file-7 didn't fit.. > >>>>> set the pointer back so we re-read it next time. > > Seeking back to location 8 > telldir assigned location 8 > file file-7 returned > Unlinking file file-3 > Unlinking file file-4 > Unlinking file file-5 > Unlinking file file-6 > >>>>> OK lets go get file-7 again > > readdir (8) returned file file-9 > >>>>> WTF? what happened to file-7 ? > > telldir assigned location 9 > readdir (9) returned file file-10 > telldir assigned location 10 > > > > > > _______________________________________________ > 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 Apr 23 06:38:23 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 5B8A5E1A; Thu, 23 Apr 2015 06:38:23 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001: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 283151FFF; Thu, 23 Apr 2015 06:38:23 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so61077885ied.1; Wed, 22 Apr 2015 23:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=L0c+XTabjEjeV5H3tQ9ZAUEkFJCSRkU+J2u56xSBlSY=; b=AN9ldd3geq6w+a472mnISrkQ/TVOl+xDw7erspFglTUB9+0zLpaN8ouO4hdo2+HrRl J5P77ouU54zkBHJv6KRD5yE1j0VhjgwquW6JygEaAhhFhYM+kOI21kFDHypXwgWl30g0 EkrY5+NlAZku8s26JO4aL3a5535iJz609a4ni3TlY06/SDfiygnVl0DKU4nax7izQCst 7vpu4ua6jD6WiXjb0hVjG/ssNldcLuQiITXRdWlNwtk0u5Sbcu4gJyAaQ1jWvjJx4uRy rEKvkZ/uiIjvUGDd2Axk2v5DqQLDWYUoenKYJjsFHEf/maZrJzkBeJ63ANpT1qUpKOXU LJ1w== MIME-Version: 1.0 X-Received: by 10.107.155.13 with SMTP id d13mr1666838ioe.29.1429771102395; Wed, 22 Apr 2015 23:38:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 22 Apr 2015 23:38:22 -0700 (PDT) Date: Wed, 22 Apr 2015 23:38:22 -0700 X-Google-Sender-Auth: qxH_SXhU5_oShWVXOneeDKWlJc0 Message-ID: Subject: help with sandybridge/ivybridge hwpmc NUMA DRAM counters From: Adrian Chadd To: "freebsd-arch@freebsd.org" , 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: Thu, 23 Apr 2015 06:38:23 -0000 hi all, I'm having a spot of problem trying to get the local/remote dram counters working on the NUMA sandybridge and ivybridge systems here. Things work fine using intel-pcm, but those same counters don't work with hwpmc. Sandybridge - there's apparently an MSR that needs to be fiddled if the counters are active. Ivybridge - the v1 and v2 chips have different local/remote dram counters, and on my v2 setup there's actually /two/ LOCAL_DRAM: adrian@testbox1:~/git/github/erikarn/freebsd/sys/dev/hwpmc % pmccontrol -L | grep DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM Now, i may be able to get to figuring this out at some point in the distant future, but I'd really appreciate any help I can get now. I'm now at the point with the NUMA affinity API stuff where I'm now chasing down when things are correctly working with local/remote RAM, and I'd really like to use hwpmc in sampling mode to work on it. Thanks for any help! -adrian From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 06:50:10 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 B1C3C254; Thu, 23 Apr 2015 06:50:10 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 6BDC61107; Thu, 23 Apr 2015 06:50:10 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YlAxb-000PNf-1J; Thu, 23 Apr 2015 09:50:07 +0300 Date: Thu, 23 Apr 2015 09:50:06 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "freebsd-arch@freebsd.org" , freebsd-current Subject: Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters Message-ID: <20150423065006.GV1394@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 23 Apr 2015 06:50:10 -0000 On Wed, Apr 22, 2015 at 11:38:22PM -0700, Adrian Chadd wrote: > hi all, > > I'm having a spot of problem trying to get the local/remote dram > counters working on the NUMA sandybridge and ivybridge systems here. > > Things work fine using intel-pcm, but those same counters don't work with hwpmc. > > Sandybridge - there's apparently an MSR that needs to be fiddled if > the counters are active. > > Ivybridge - the v1 and v2 chips have different local/remote dram > counters, and on my v2 setup there's actually /two/ LOCAL_DRAM: # pmccontrol -L | grep DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.05-MHz K8-class CPU) > adrian@testbox1:~/git/github/erikarn/freebsd/sys/dev/hwpmc % > pmccontrol -L | grep DRAM > MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM > MEM_LOAD_UOPS_LLC_MISS_RETIRED.LOCAL_DRAM > MEM_LOAD_UOPS_LLC_MISS_RETIRED.REMOTE_DRAM > > Now, i may be able to get to figuring this out at some point in the > distant future, but I'd really appreciate any help I can get now. I'm > now at the point with the NUMA affinity API stuff where I'm now > chasing down when things are correctly working with local/remote RAM, > and I'd really like to use hwpmc in sampling mode to work on it. > > Thanks for any help! > > > > -adrian > _______________________________________________ > 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 Apr 23 07:20:14 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 EA2E6846; Thu, 23 Apr 2015 07:20:14 +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 B4D6513BE; Thu, 23 Apr 2015 07:20:14 +0000 (UTC) Received: by igblo3 with SMTP id lo3so16305795igb.1; Thu, 23 Apr 2015 00:20: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=YX5dm31C1BPGuJ0Fam/OYg2v9+BFx3SI9Km9M5LPQCw=; b=gfch/y7e4OvCr8pRIajahZRmcAusTZM7wGbvcEXXMvOqWO9iVYGbQz+0evnbsy5EQH 4coDUW3fSCmx+Sph64AXCH50XfkfTlMZMv+KOdieGQOpJ+oUl8wyGA5Vq7jNVMz0CStU SL3BQdfckiCeiFPP5t+xSXMtwN1P56g2F+tQrkALI7ka7OjQxoG+2da5OXNI+MJb2TUZ mdmfV43gW/hQjJLv6mhlGwqtxl26kWbklBgyutTQUwtZ1FhVRUV1VrsXsu+FwslvxmkZ p68ZuMzvQG9d4L89SQqQNmQjD0NVInOkFVL/p0QqiujRZUryvzgRsetTLzT7cg03JRIc 4WEA== MIME-Version: 1.0 X-Received: by 10.50.57.51 with SMTP id f19mr2945060igq.6.1429773614170; Thu, 23 Apr 2015 00:20:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Thu, 23 Apr 2015 00:20:14 -0700 (PDT) In-Reply-To: <20150423065006.GV1394@zxy.spb.ru> References: <20150423065006.GV1394@zxy.spb.ru> Date: Thu, 23 Apr 2015 00:20:14 -0700 X-Google-Sender-Auth: 7bptOHC1A3nAiio0P4Po5Gils9I Message-ID: Subject: Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters From: Adrian Chadd To: Slawa Olhovchenkov Cc: "freebsd-arch@freebsd.org" , 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: Thu, 23 Apr 2015 07:20:15 -0000 Yeah, on stable/10. But on -HEAD it's different. There's two entries - one for d3_01 and one for d3_03. -adrian From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 07:22:46 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 9243BA1C; Thu, 23 Apr 2015 07:22:46 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 4BA2C14C4; Thu, 23 Apr 2015 07:22:46 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YlBT9-000Pvy-Ty; Thu, 23 Apr 2015 10:22:44 +0300 Date: Thu, 23 Apr 2015 10:22:43 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "freebsd-arch@freebsd.org" , freebsd-current Subject: Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters Message-ID: <20150423072243.GM9114@zxy.spb.ru> References: <20150423065006.GV1394@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 23 Apr 2015 07:22:46 -0000 On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > Yeah, on stable/10. But on -HEAD it's different. There's two entries - > one for d3_01 and one for d3_03. What CPU model? From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 07:24:07 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 B8207C44; Thu, 23 Apr 2015 07:24:07 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 8163014E1; Thu, 23 Apr 2015 07:24:07 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so17012827igb.0; Thu, 23 Apr 2015 00:24:07 -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=01BgYjGT48qk4Tx5h6A+0C72kbWzEZb4n3orkUPxsHw=; b=n+e4f+7wEtskkCsjzoFh1IuYlcHoSgvzSYXwJ9aoMRTGTChjtcyyVy+0M0OPoFBug7 lcUn0g6fS0zAYQQ4kDqk/IxrQexkC+GPgeisrNHx5d4dQ4ax1ocXQRE2vEhCRlS/bGK1 H7OIGFm4jjHHk8QMiqaW4Hi7u3MSYmXYHVMvoumy39W3eFR93uUud4wU/O6N3Bohw4eL cEEyoXyz74BNKm5LXERVnjFfCDnN2Fmce41WkWF+Qm08Ns1UuXmi0h80F9mP85W4ECjs 2O3+UtEkeB7sn8CmsoU6Uy/rgh0RYlIHLvS+AOTTxbeyEZV58qIZRlRuHWtiKyzUhReU HG3g== MIME-Version: 1.0 X-Received: by 10.42.137.202 with SMTP id z10mr2071751ict.37.1429773846956; Thu, 23 Apr 2015 00:24:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Thu, 23 Apr 2015 00:24:06 -0700 (PDT) In-Reply-To: <20150423072243.GM9114@zxy.spb.ru> References: <20150423065006.GV1394@zxy.spb.ru> <20150423072243.GM9114@zxy.spb.ru> Date: Thu, 23 Apr 2015 00:24:06 -0700 X-Google-Sender-Auth: EsAAgMHyHEbS3kYjMI0OE96FVJw Message-ID: Subject: Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters From: Adrian Chadd To: Slawa Olhovchenkov Cc: "freebsd-arch@freebsd.org" , 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: Thu, 23 Apr 2015 07:24:07 -0000 On 23 April 2015 at 00:22, Slawa Olhovchenkov wrote: > On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > >> Yeah, on stable/10. But on -HEAD it's different. There's two entries - >> one for d3_01 and one for d3_03. > > What CPU model? CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 -adrian From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 07:24: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 D843FDF1; Thu, 23 Apr 2015 07:24:57 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 901881500; Thu, 23 Apr 2015 07:24:57 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YlBVH-000PzS-Hc; Thu, 23 Apr 2015 10:24:55 +0300 Date: Thu, 23 Apr 2015 10:24:55 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "freebsd-arch@freebsd.org" , freebsd-current Subject: Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters Message-ID: <20150423072455.GN9114@zxy.spb.ru> References: <20150423065006.GV1394@zxy.spb.ru> <20150423072243.GM9114@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 23 Apr 2015 07:24:58 -0000 On Thu, Apr 23, 2015 at 12:24:06AM -0700, Adrian Chadd wrote: > On 23 April 2015 at 00:22, Slawa Olhovchenkov wrote: > > On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > > > >> Yeah, on stable/10. But on -HEAD it's different. There's two entries - > >> one for d3_01 and one for d3_03. > > > > What CPU model? > > CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 Same with me? From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 07:48:22 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 20F3998C for ; Thu, 23 Apr 2015 07:48:22 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 DD4891761 for ; Thu, 23 Apr 2015 07:48:21 +0000 (UTC) Received: by iget9 with SMTP id t9so5685472ige.1 for ; Thu, 23 Apr 2015 00:48: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=sFzJ6KvT6/x3d+5VM94P1t5eBUniKQGunc//4fELKcM=; b=qnF3ZOklWDiy7p4YhgGS6KxhAGEWMRrB7XdvDpyU5a3VN0aXzukVGp6DsoWyUGFX1t qtfp25XK/FdwbK2TKLVJrEC7CTMOl7Ka6ib+pbbUXgxDsyAz7wTS89E/h/d3Mupay5ZB Pnps9UmQKrEH1OV3fnVdr46cJp/O6eu6zx2xyKg95P79rE/j5saJTtb/hK3xUt494CVr F/RLfPHzvsXwWVV+sXvyRtPb1/ow/p9TWbKda/Gwxq8CpX+bva8pDIG/F0+pTD5USyXB VXta1QZ0qp2KAsFSIis2M7eCwBUK+ocn4hcedzRUEvMitT6JyYkQwSi7JHSxZGFFuiUe SVIA== MIME-Version: 1.0 X-Received: by 10.107.138.96 with SMTP id m93mr2111672iod.14.1429775301236; Thu, 23 Apr 2015 00:48:21 -0700 (PDT) Received: by 10.36.51.129 with HTTP; Thu, 23 Apr 2015 00:48:21 -0700 (PDT) In-Reply-To: <55375060.2060705@selasky.org> References: <55375060.2060705@selasky.org> Date: Thu, 23 Apr 2015 09:48:21 +0200 Message-ID: Subject: Re: CM6206 USB Audio is mute. From: "Ranjan1018 ." <214748mv@gmail.com> To: Hans Petter Selasky 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: Thu, 23 Apr 2015 07:48:22 -0000 2015-04-22 9:40 GMT+02:00 Hans Petter Selasky : > On 04/21/15 21:30, Ranjan1018 . wrote: > >> Connecting the USB cable the item is recognized: >> ugen0.5: at usbus0 >> uaudio0: > 5> >> on usbus0 >> uaudio0: Play: 48000 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. >> uaudio0: Play: 44100 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. >> uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. >> uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. >> uaudio0: No MIDI sequencer. >> pcm1: on uaudio0 >> uaudio0: HID volume keys found. >> >> > Hi, > > Did you check: > > mixer -f /dev/mixerX > > that sound volume is OK? > > Setting it as default unit >> # sysctl hw.snd.default_unit=1 >> and playing a song the interrupts count increase: >> > > Some volume knobs might be hidden. Try to get all: > > sysctl -a | grep pcm > > > But the output is mute. >> >> In Debian Linux it works: >> # lsusb >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 002 Device 014: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like >> Sound >> Device >> # aplay -l >> **** List of PLAYBACK Hardware Devices **** >> card 1: Device [USB Sound Device], device 0: USB Audio [USB Audio] >> Subdevices: 0/1 >> Subdevice #0: subdevice #0 >> >> Looking at http://lxr.free-electrons.com/source/sound/usb/quirks.c I have >> found this code: >> /* >> 632 * C-Media CM106/CM106+ have four 16-bit internal registers that are >> nicely >> 633 * documented in the device's data sheet. >> 634 */ >> 635 static int snd_usb_cm106_write_int_reg(struct usb_device *dev, int >> reg, >> u16 value) >> 636 { >> 637 u8 buf[4]; >> 638 buf[0] = 0x20; >> 639 buf[1] = value & 0xff; >> 640 buf[2] = (value >> 8) & 0xff; >> 641 buf[3] = reg; >> 642 return snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), >> USB_REQ_SET_CONFIGURATION, >> 643 USB_DIR_OUT | USB_TYPE_CLASS | >> USB_RECIP_ENDPOINT, >> 644 0, 0, &buf, 4); >> 645 } >> > > This USB control request can be issued from userspace like this (you need > to convert all variables below into constants): > > usbconfig -d X.Y do_request "USB_DIR_OUT | USB_TYPE_CLASS | > > USB_RECIP_ENDPOINT" "USB_REQ_SET_CONFIGURATION" 0 0 4 0x20 "(value & > 0xff)" "(value >> 8) & 0xff" "reg" > > Such a command can easily be added like a devd script to run automatically > during device attach. > > > 646 >> 647 static int snd_usb_cm106_boot_quirk(struct usb_device *dev) >> 648 { >> 649 /* >> 650 * Enable line-out driver mode, set headphone source to front >> 651 * channels, enable stereo mic. >> 652 */ >> 653 return snd_usb_cm106_write_int_reg(dev, 2, 0x8004); >> 654 } >> 655 >> 656 /* >> 657 * C-Media CM6206 is based on CM106 with two additional >> 658 * registers that are not documented in the data sheet. >> 659 * Values here are chosen based on sniffing USB traffic >> 660 * under Windows. >> 661 */ >> 662 static int snd_usb_cm6206_boot_quirk(struct usb_device *dev) >> 663 { >> 664 int err = 0, reg; >> 665 int val[] = {0x2004, 0x3000, 0xf800, 0x143f, 0x0000, 0x3000}; >> 666 >> 667 for (reg = 0; reg < ARRAY_SIZE(val); reg++) { >> 668 err = snd_usb_cm106_write_int_reg(dev, reg, val[reg]); >> 669 if (err < 0) >> 670 return err; >> 671 } >> 672 >> 673 return err; >> 674 } >> 675 >> >> How can I test this code in FreeBSD ? >> >> > See answer above. > > Please also use -stable or -current when testing. > > --HPS > > Thank you Hans, it works !!! This is only the first step in supporting the C-Media CM6206 in FreeBSD, but works. I have converted the C code in a bash script: snd-cm6206.sh available at http://pastebin.com/dLtJAqE7 Instructions: - Connect the USB cable of the CM6206 - With the command # dmesg | tail look at the the line : ugenX.Y: at usbus and the line : pcmZ: on uaudio - Run the script: # snd-cm6206.sh X.Y - Run the command: # sysctl hw.snd.default_unit=Z - Reduce the volume ;-) : # mixer -f /dev/mixerZ 10 On my laptop running 11-CURRENT, after connecting the CM6206, I have : # dmesg | tail pcm3: detached ugen1.4: at usbus1 uaudio0: on usbus1 uaudio0: Play: 48000 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Play: 44100 Hz, 4 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. pcm3: on uaudio0 uaudio0: HID volume keys found. # snd-cm6206.sh 1.4 Writing register 0 REQUEST = Writing register 1 REQUEST = Writing register 2 REQUEST = Writing register 3 REQUEST = Writing register 4 REQUEST = Writing register 5 REQUEST = # sysctl hw.snd.default_unit=3 hw.snd.default_unit: 0 -> 3 # mixer -f /dev/mixer3 10 Setting the mixer vol from 75:75 to 10:10. Regards, Maurizio From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 08:07: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 6989C3B9; Thu, 23 Apr 2015 08:07:09 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 20D1519AE; Thu, 23 Apr 2015 08:07:09 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YlCA5-0000lr-Ht; Thu, 23 Apr 2015 11:07:05 +0300 Date: Thu, 23 Apr 2015 11:07:05 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "freebsd-arch@freebsd.org" , freebsd-current Subject: Re: help with sandybridge/ivybridge hwpmc NUMA DRAM counters Message-ID: <20150423080705.GO9114@zxy.spb.ru> References: <20150423065006.GV1394@zxy.spb.ru> <20150423072243.GM9114@zxy.spb.ru> <20150423072455.GN9114@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150423072455.GN9114@zxy.spb.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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, 23 Apr 2015 08:07:09 -0000 On Thu, Apr 23, 2015 at 10:24:55AM +0300, Slawa Olhovchenkov wrote: > On Thu, Apr 23, 2015 at 12:24:06AM -0700, Adrian Chadd wrote: > > > On 23 April 2015 at 00:22, Slawa Olhovchenkov wrote: > > > On Thu, Apr 23, 2015 at 12:20:14AM -0700, Adrian Chadd wrote: > > > > > >> Yeah, on stable/10. But on -HEAD it's different. There's two entries - > > >> one for d3_01 and one for d3_03. > > > > > > What CPU model? > > > > CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (2600.06-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x306e4 Family=0x6 Model=0x3e Stepping=4 > > Same with me? May be in you case E5-269x? From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 09:02:19 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 4B8C158C for ; Thu, 23 Apr 2015 09:02:19 +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 2C1F41FEB for ; Thu, 23 Apr 2015 09:02:19 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3N92EYa020293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 23 Apr 2015 02:02:17 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5538B510.9040603@freebsd.org> Date: Thu, 23 Apr 2015 17:02:08 +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: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> In-Reply-To: <55386505.70708@freebsd.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, 23 Apr 2015 09:02:19 -0000 On 4/23/15 11:20 AM, Julian Elischer wrote: > I'm debugging a problem being seen with samba 3.6. > > basically telldir/seekdir/readdir don't seem to work as advertised.. ok so it looks like readdir() (and friends) is totally broken in the face of deletes unless you read the entire directory at once or reset to the the first file before the deletes, or earlier. So if you use readdir() to enumerate files in order to delete them, and you do it in sections in order to not have to load a potentially huge list of files all at once, you can not do it unless you rewind to 0 after each set of unlinks. (or you do all the unlinks in one hit). this appears to be because getdirentries (or maybe the filesystem behind) will 'compact' the returned data. At least this appears to be the case looking from the outside. Next step is to look at the getdirentries code.. > > here's a little test program > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #define CHUNKSIZE 5 > #define TOTALFILES 40 > > static void > SeekDir(DIR *dirp, long loc) > { > printf("Seeking back to location %ld\n", loc); > seekdir(dirp, loc); > } > > static long > TellDir(DIR *dirp) > { > long loc; > > loc = telldir(dirp); > printf("telldir assigned location %ld\n", loc); > return (loc); > } > > int > main(int argc, char *argv[]) > { > DIR *dirp; > int i; > int j; > long offset = 0, prev_offset = 0; > char *files[100]; > char filename[100]; > int fd; > struct dirent *dp = NULL; > > if (chdir("./test2") != 0) { > err(EX_OSERR, "chdir"); > } > > /*****************************************************/ > /* Put a set of sample files in the target directory */ > /*****************************************************/ > > for (i=1; i < TOTALFILES ; i++) > { > sprintf(filename, "file-%d", i); > fd = open(filename, O_CREAT, 0666); > if (fd == -1) { > err(EX_OSERR, "open"); > } > close(fd); > } > dirp = opendir("."); > offset = TellDir(dirp); > for (i = 0; i < 20; i++) > files[i] = malloc(20); > > /*******************************************************/ > /* enumerate and delete small sets of files, one group */ > /* at a time. */ > /*******************************************************/ > do { > > /*****************************************/ > /* Read in up to CHUNKSIZE file names */ > /* i will be the number of files we hold */ > /*****************************************/ > for (i = 0; i < CHUNKSIZE; i++) { > if ((dp = readdir(dirp)) != NULL) { > strcpy(files[i], dp->d_name); > > printf("readdir (%ld) returned file %s\n", > offset, files[i]); > > prev_offset = offset; > offset = TellDir(dirp); > > } else { > printf("readdir returned null\n"); > break; > } > } > > > /****************************************************************/ > /* Simuate the last entry not fitting into our (samba's) > buffer */ > /* If we read someting in on the last slot, push it > back */ > /* Pretend it didn't fit. This is approximately what SAMBA > does.*/ > /****************************************************************/ > if (dp != NULL) { > /* Step back */ > SeekDir(dirp, prev_offset); > offset = TellDir(dirp); > i--; > printf("file %s returned\n", files[i]); > } > > /*****************************************/ > /* i is the number of names we have left.*/ > /* Delete them. */ > /*****************************************/ > for (j = 0; j < i; j++) { > if (*files[j] == '.') { > printf ("skipping %s\n", files[j]); > } else { > printf("Unlinking file %s\n", files[j]); > if (unlink(files[j]) != 0) { > err(EX_OSERR, "unlink"); > } > } > } > } while (dp != NULL); > > closedir(dirp); > //chdir(".."); > > } > > The program is simulating what Samba does when fails. (doing a > recursive delete of a directory) > What it does is reads a chunk of names using readdir() until it's > (small) buffer s full, > then it uses seekdir() to seek back before the last entry it read, > (which fails to fit), > theortically leaving it for the next read. > It then deletes the entries it found and repeats the cycle. > > Eventually it should have found all the files in the directory and > deleted them. > Except that it doesn't. > > What actually happens is that some files are not enumerated, even > though > the seekdir() should have made the readdir() find them. > for added fun. the FIRST seekdir appears to work. but all subsequent > ones don't. > > It behaves this way in -current , all the way back to at least 8.0. > > if there's a bug in my program please let me know, but samba has the > same problem.. e.g. on freeNAS. > > to use the program make a directory called "./test2" and then run it > in the current directory.. > It fills it with files and then tried to (fails) delete them in > small batches. > > here's some (annotated) output: > > ./testit > telldir assigned location 0 > readdir (0) returned file . > telldir assigned location 1 > readdir (1) returned file .. > telldir assigned location 2 > readdir (2) returned file file-1 > telldir assigned location 3 > readdir (3) returned file file-2 > telldir assigned location 4 > readdir (4) returned file file-3 > telldir assigned location 5 > >>>>> here we pretend the buffer was full and put the file > >>>>> marker back so that it will get read next time > Seeking back to location 4 > telldir assigned location 4 > file file-3 returned > skipping . > skipping .. > Unlinking file file-1 > Unlinking file file-2 > readdir (4) returned file file-3 > >>>>> hey it worked (this time) > telldir assigned location 5 > readdir (5) returned file file-4 > telldir assigned location 6 > readdir (6) returned file file-5 > telldir assigned location 7 > readdir (7) returned file file-6 > telldir assigned location 8 > readdir (8) returned file file-7 > telldir assigned location 9 > >>>>> OK do it again.. pretend file-7 didn't fit.. > >>>>> set the pointer back so we re-read it next time. > > Seeking back to location 8 > telldir assigned location 8 > file file-7 returned > Unlinking file file-3 > Unlinking file file-4 > Unlinking file file-5 > Unlinking file file-6 > >>>>> OK lets go get file-7 again > > readdir (8) returned file file-9 > >>>>> WTF? what happened to file-7 ? > > telldir assigned location 9 > readdir (9) returned file file-10 > telldir assigned location 10 > > > > > > _______________________________________________ > 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 Apr 23 09:05: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 528696D2; Thu, 23 Apr 2015 09:05:55 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 165661020; Thu, 23 Apr 2015 09:05:54 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 77BC316A473; Thu, 23 Apr 2015 11:05:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwMGKICZedpZ; Thu, 23 Apr 2015 11:05:20 +0200 (CEST) Received: from [192.168.101.176] (vpn.ecoracks.nl [31.223.170.173]) by smtp.digiware.nl (Postfix) with ESMTPA id EA81916A474; Thu, 23 Apr 2015 11:05:20 +0200 (CEST) Message-ID: <5538B5CF.9010508@digiware.nl> Date: Thu, 23 Apr 2015 11:05:19 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ed Maste CC: Warren Block , FreeBSD Current Subject: Re: Newer yacc needed for building world References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> In-Reply-To: Content-Type: text/plain; charset=utf-8 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, 23 Apr 2015 09:05:55 -0000 On 22/04/2015 23:37, Ed Maste wrote: > On 22 April 2015 at 15:55, Willem Jan Withagen wrote: >> >>> Yes: >>> https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html >>> >> >> But this is not enough to make yacc part of the build tools?? > > yacc is unconditionally built during bootstrap-tools as of r281615. > What SVN rev is your tree? > # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 281853 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 281849 Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015) Then I removed /usr/obj/* to get a fresh start. Removing yacc just gets me into trouble even earlier: # make -j 32 buildworld . . . --- _bootstrap-tools-usr.bin/compile_et --- --- parse.c --- yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y yacc: not found --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree --- /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for /usr/src/usr.sbin/bsnmpd/gensnmptree --- _bootstrap-tools-usr.bin/compile_et --- *** [parse.c] Error code 127 So I have relatively little further to test. Perhaps the '-j 32' was a bit aggressive, but it gets fast where the error is. --WjW From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 09:16: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 277A1891 for ; Thu, 23 Apr 2015 09:16:59 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B01BE112B for ; Thu, 23 Apr 2015 09:16:58 +0000 (UTC) Received: by wiax7 with SMTP id x7so7989974wia.0 for ; Thu, 23 Apr 2015 02:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=9d9BasXJqrwlBpg1YUdfO6cKfvNyEl0/ohjoIpENuXc=; b=ktQnsuBSy1XIPLR+s5a+pnYtTkUyQyx/TKN65u+Ic60ZK+KtZ2Bd9VvR9TcSq9nSvw 6G8ABiT2Oejh+Cu0tg7DNSoyMb8pwUokx0Jju/slmasbO9fIyzO0L52RgPAJb/2HNu6o 3dSQl89jwEDw/L4sbIeHsKYfVCKbbiOSL4cJkIHj07a093vMROFrayX+xtpyncpoisGD uBu6BgrQhwZAbeT8M0OV2Exi2hZexwHXp4y+Y9IwFbIkV/0p402PV7NlJOYMd0CGirAX nqTYkQMpQ30/rcR0aftLhBV2/A/3zCj+83l2mffL4aqaSLarFFtreA2HTnukLA9bAAbU WkJQ== X-Received: by 10.194.19.197 with SMTP id h5mr3423442wje.109.1429780616893; Thu, 23 Apr 2015 02:16:56 -0700 (PDT) Received: from brick.home (dgp65.neoplus.adsl.tpnet.pl. [83.23.171.65]) by mx.google.com with ESMTPSA id dg8sm11159584wjc.9.2015.04.23.02.16.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 02:16:55 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 23 Apr 2015 11:16:53 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: David Boyd Cc: freebsd-current@freebsd.org Subject: Re: AUTOFS and NFS not playing together nicely Message-ID: <20150423091653.GA1607@brick.home> Mail-Followup-To: David Boyd , freebsd-current@freebsd.org References: <1429477202.29812.38.camel@gemini.bsd1.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1429477202.29812.38.camel@gemini.bsd1.net> 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: Thu, 23 Apr 2015 09:16:59 -0000 On 0419T1700, David Boyd wrote: > At the risk of being dubbed insane, here goes: > > On five FreeBSD 10.1-RELEASE-p9 production servers autofs(5) is enabled > and working as advertised. On the same servers nfs v3 clients are also > fat, dumb and happy. > > On a test server where autofs(5) is also enabled and working well, I am > testing nfs v3 (later v4) server. Strange things are happening. > > When nfs mountd(8) is running, the autofs(5) auto-mount (via automountd) > function seems to work, but the autofs(5) auto-unmount (via > autounmountd) never occurs. > > Without nfs mountd(8), when the filesystem /disc is auto-mounted (via > autoumountd), the mount(8) command shows status of (ufs, local, > journaled soft-updates, auto-mounted) for the auto-mounted filesystem > and after the autofs(5) timeout period (600 seconds) the filesystem is > auto-unmounted (via autounmountd). No problem. > > With nfs mountd(8) the mount(8) command shows (ufs, local, journaled > soft-updates). The auto-mounted filesystem is never (a long, long time) > unmounted. Big problem. > > Without nfs mountd(8) running, the mount(8) command "mount -o > automounted /dev/ada0p8 /disc" mounts the filesystem and the mount(8) > command shows (ufs, local, journaled soft-updates, automounted) for the > manually mounted filesystem and after the autofs(5) timeout period (600 > seconds) the filesystem is auto-unmounted even though it was not mounted > automatically. No problem. > > With nfs mountd(8), the mount(8) command "mount -o > automounted /dev/ada0p8 /disc" mounts the filesystem but the mount(8) > command shows (ufs, local, journaled soft-updates) and after the timeout > period (600 seconds) the filesystem is remains mounted. Big problem. > > It appears that nfs mountd(8) is interferring with the mount(8) > command's -o option processing but admittedly that is just a very weak > SWAG. That's an interesting bug. I can reproduce it, but hadn't tracked down the cause just yet. I'll work on that shortly. Thanks for reporting! From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 14:02:36 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 22232F41; Thu, 23 Apr 2015 14:02:36 +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 F227D1125; Thu, 23 Apr 2015 14:02:35 +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 A073DB94B; Thu, 23 Apr 2015 10:02:34 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) Date: Thu, 23 Apr 2015 09:54:32 -0400 Message-ID: <10872728.5fNYcpCvKN@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <5538B510.9040603@freebsd.org> References: <55386505.70708@freebsd.org> <5538B510.9040603@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); Thu, 23 Apr 2015 10:02:34 -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: Thu, 23 Apr 2015 14:02:36 -0000 On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > On 4/23/15 11:20 AM, Julian Elischer wrote: > > I'm debugging a problem being seen with samba 3.6. > > > > basically telldir/seekdir/readdir don't seem to work as advertised.. > > ok so it looks like readdir() (and friends) is totally broken in the face > of deletes unless you read the entire directory at once or reset to the > the first file before the deletes, or earlier. I'm not sure that Samba isn't assuming non-portable behavior. For example: >From http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified. While this doesn't speak directly to your case, it does note that you will get inconsistencies if you scan a directory concurrent with add and remove. UFS might kind of work actually since deletes do not compact the backing directory, but I suspect NFS and ZFS would not work. In addition, our current NFS support for seekdir is pretty flaky and can't be fixed without changes to return the seek offset for each directory entry (I believe that the projects/ino64 patches include this since they are breaking the ABI of the relevant structures already). The ABI breakage makes this a very non-trivial task. However, even if you have that per-item cookie, it is likely meaningless in the face of filesystems that use any sort of more advanced structure than an array (such as trees, etc.) to store directory entries. POSIX specifically mentions this in the rationale for seekdir: http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html One of the perceived problems of implementation is that returning to a given point in a directory is quite difficult to describe formally, in spite of its intuitive appeal, when systems that use B-trees, hashing functions, or other similar mechanisms to order their directories are considered. The definition of seekdir() and telldir() does not specify whether, when using these interfaces, a given directory entry will be seen at all, or more than once. In fact, given that quote, I would argue that what Samba is doing is non-portable. This would seem to indicate that a conforming seekdir could just change readdir to immediately return EOF until you call rewinddir. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 16:25: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 24B5AFAD; Thu, 23 Apr 2015 16:25:42 +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 E1D6214BF; Thu, 23 Apr 2015 16:25:41 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3NGPTa6021985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Apr 2015 09:25:33 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55391CF4.2080008@freebsd.org> Date: Fri, 24 Apr 2015 00:25:24 +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: John Baldwin , freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <5538B510.9040603@freebsd.org> <10872728.5fNYcpCvKN@ralph.baldwin.cx> In-Reply-To: <10872728.5fNYcpCvKN@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: Thu, 23 Apr 2015 16:25:42 -0000 On 4/23/15 9:54 PM, John Baldwin wrote: > On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >> On 4/23/15 11:20 AM, Julian Elischer wrote: >>> I'm debugging a problem being seen with samba 3.6. >>> >>> basically telldir/seekdir/readdir don't seem to work as advertised.. >> ok so it looks like readdir() (and friends) is totally broken in the face >> of deletes unless you read the entire directory at once or reset to the >> the first file before the deletes, or earlier. > I'm not sure that Samba isn't assuming non-portable behavior. For example: > > >From http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > > If a file is removed from or added to the directory after the most recent call > to opendir() or rewinddir(), whether a subsequent call to readdir() returns an > entry for that file is unspecified. > > While this doesn't speak directly to your case, it does note that you will > get inconsistencies if you scan a directory concurrent with add and remove. > > UFS might kind of work actually since deletes do not compact the backing > directory, but I suspect NFS and ZFS would not work. looking in ufs_getdirent (or whatever it's called) even UFS is packing the list of files and removing deleted entries. it's also what I'm seeing in practice. if I do a seekdir back to the location of the first deleted file, I find a new file in that slot, that has been shuffled down. > In addition, our > current NFS support for seekdir is pretty flaky and can't be fixed without > changes to return the seek offset for each directory entry (I believe that > the projects/ino64 patches include this since they are breaking the ABI of > the relevant structures already). The ABI breakage makes this a very > non-trivial task. However, even if you have that per-item cookie, it is > likely meaningless in the face of filesystems that use any sort of more > advanced structure than an array (such as trees, etc.) to store directory > entries. POSIX specifically mentions this in the rationale for seekdir: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html > > One of the perceived problems of implementation is that returning to a given point in a directory is quite difficult to describe formally, in spite of its intuitive appeal, when systems that use B-trees, hashing functions, or other similar mechanisms to order their directories are considered. The definition of seekdir() and telldir() does not specify whether, when using these interfaces, a given directory entry will be seen at all, or more than once. > > In fact, given that quote, I would argue that what Samba is doing is > non-portable. This would seem to indicate that a conforming seekdir could > just change readdir to immediately return EOF until you call rewinddir. > From owner-freebsd-current@FreeBSD.ORG Thu Apr 23 21:50:27 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 6581EB22; Thu, 23 Apr 2015 21:50:27 +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 1E471181F; Thu, 23 Apr 2015 21:50:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+AwC0ZzlV/95baINbg15cBYMVwwsJgUcMhTROAoFvFAEBAQEBAQGBCoQhAQEEAQEBICsgCxsOCgICDRkCKQEJJgYIBwQBHASICg23WJRkAQEBAQEBBAEBAQEBAQEbgSGKFoQyAQEcNAeCaIFFBY8ZhjKCP4FHg1A8hXlgiUaDTiOBZYIrIjEBBoEEOYEAAQEB X-IronPort-AV: E=Sophos;i="5.11,634,1422939600"; d="scan'208";a="207651558" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 23 Apr 2015 17:50:25 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CF888B4001; Thu, 23 Apr 2015 17:50:25 -0400 (EDT) Date: Thu, 23 Apr 2015 17:50:25 -0400 (EDT) From: Rick Macklem To: John Baldwin Cc: freebsd-current@freebsd.org Message-ID: <336285737.24821463.1429825825843.JavaMail.root@uoguelph.ca> In-Reply-To: <10872728.5fNYcpCvKN@ralph.baldwin.cx> Subject: Re: readdir/telldir/seekdir problem (i think) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] 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, 23 Apr 2015 21:50:27 -0000 John Baldwin wrote: > On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > > On 4/23/15 11:20 AM, Julian Elischer wrote: > > > I'm debugging a problem being seen with samba 3.6. > > > > > > basically telldir/seekdir/readdir don't seem to work as > > > advertised.. > > > > ok so it looks like readdir() (and friends) is totally broken in > > the face > > of deletes unless you read the entire directory at once or reset to > > the > > the first file before the deletes, or earlier. > > I'm not sure that Samba isn't assuming non-portable behavior. For > example: > > From > http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > > If a file is removed from or added to the directory after the most > recent call > to opendir() or rewinddir(), whether a subsequent call to readdir() > returns an > entry for that file is unspecified. > > While this doesn't speak directly to your case, it does note that you > will > get inconsistencies if you scan a directory concurrent with add and > remove. > > UFS might kind of work actually since deletes do not compact the > backing > directory, but I suspect NFS and ZFS would not work. In addition, > our > current NFS support for seekdir is pretty flaky and can't be fixed > without > changes to return the seek offset for each directory entry (I believe > that > the projects/ino64 patches include this since they are breaking the > ABI of > the relevant structures already). The ABI breakage makes this a very > non-trivial task. However, even if you have that per-item cookie, it > is > likely meaningless in the face of filesystems that use any sort of > more > advanced structure than an array (such as trees, etc.) to store > directory > entries. POSIX specifically mentions this in the rationale for > seekdir: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html > > One of the perceived problems of implementation is that returning to > a given point in a directory is quite difficult to describe > formally, in spite of its intuitive appeal, when systems that use > B-trees, hashing functions, or other similar mechanisms to order > their directories are considered. The definition of seekdir() and > telldir() does not specify whether, when using these interfaces, a > given directory entry will be seen at all, or more than once. > > In fact, given that quote, I would argue that what Samba is doing is > non-portable. This would seem to indicate that a conforming seekdir > could > just change readdir to immediately return EOF until you call > rewinddir. > Loosely related to this, I have been tempted to modify readdir() to read the entire directory on the first readdir() for NFS, to avoid the readdir()/unlink() problem. My concern was doing this for a very large directory. Maybe it could be done for directories up to some size? rick > -- > John Baldwin > _______________________________________________ > 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 Apr 23 22:12: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 608C15F8; Thu, 23 Apr 2015 22:12:47 +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 1A4D41AF7; Thu, 23 Apr 2015 22:12:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+AwCJbTlV/95baINbg15cBYMVwwsJgUcMhTROAoFwFAEBAQEBAQGBCoQhAQEEAQEBICsgCxsOCgICDRkCKQEJJgYIBwQBHASICg23WJUKAQEBAQEBBAEBAQEBAQEbgSGKFoQyAQEcNAeCaIFFBY8ZhjKCP4FHg1A8hXlgiUaDTiOBZYIrIjEBBoEEOYEAAQEB X-IronPort-AV: E=Sophos;i="5.11,634,1422939600"; d="scan'208";a="207654193" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 23 Apr 2015 18:12:45 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B3613B3F08; Thu, 23 Apr 2015 18:12:45 -0400 (EDT) Date: Thu, 23 Apr 2015 18:12:45 -0400 (EDT) From: Rick Macklem To: John Baldwin Cc: freebsd-current@freebsd.org Message-ID: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> In-Reply-To: <10872728.5fNYcpCvKN@ralph.baldwin.cx> Subject: Re: readdir/telldir/seekdir problem (i think) 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, 23 Apr 2015 22:12:47 -0000 John Baldwin wrote: > On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > > On 4/23/15 11:20 AM, Julian Elischer wrote: > > > I'm debugging a problem being seen with samba 3.6. > > > > > > basically telldir/seekdir/readdir don't seem to work as > > > advertised.. > > > > ok so it looks like readdir() (and friends) is totally broken in > > the face > > of deletes unless you read the entire directory at once or reset to > > the > > the first file before the deletes, or earlier. > > I'm not sure that Samba isn't assuming non-portable behavior. For > example: > > From > http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > > If a file is removed from or added to the directory after the most > recent call > to opendir() or rewinddir(), whether a subsequent call to readdir() > returns an > entry for that file is unspecified. > > While this doesn't speak directly to your case, it does note that you > will > get inconsistencies if you scan a directory concurrent with add and > remove. > > UFS might kind of work actually since deletes do not compact the > backing > directory, but I suspect NFS and ZFS would not work. In addition, > our > current NFS support for seekdir is pretty flaky and can't be fixed > without > changes to return the seek offset for each directory entry (I believe > that > the projects/ino64 patches include this since they are breaking the > ABI of > the relevant structures already). The ABI breakage makes this a very > non-trivial task. However, even if you have that per-item cookie, it > is > likely meaningless in the face of filesystems that use any sort of > more > advanced structure than an array (such as trees, etc.) to store > directory > entries. POSIX specifically mentions this in the rationale for > seekdir: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html > > One of the perceived problems of implementation is that returning to > a given point in a directory is quite difficult to describe > formally, in spite of its intuitive appeal, when systems that use > B-trees, hashing functions, or other similar mechanisms to order > their directories are considered. The definition of seekdir() and > telldir() does not specify whether, when using these interfaces, a > given directory entry will be seen at all, or more than once. > > In fact, given that quote, I would argue that what Samba is doing is > non-portable. This would seem to indicate that a conforming seekdir > could > just change readdir to immediately return EOF until you call > rewinddir. > Btw, Linux somehow makes readdir()/unlink() work for NFS. I haven't looked, but I strongly suspect that it reads the entire directory upon either opendir() or the first readdir(). Oh, and I hate to say it, but I suspect Linux defines the "standard" on this and not POSIX. (In other words, if it works on Linux, it isn't broken;-) rick > -- > John Baldwin > _______________________________________________ > 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 Fri Apr 24 02:29:43 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 04E0CEB9 for ; Fri, 24 Apr 2015 02:29:43 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E65581295 for ; Fri, 24 Apr 2015 02:29:42 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 85DB61EE for ; Fri, 24 Apr 2015 02:29:40 +0000 (UTC) Date: Fri, 24 Apr 2015 02:29:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1183491007.52.1429842576357.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #969 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: Fri, 24 Apr 2015 02:29:43 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 04:58:35 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 7BBF2D0A for ; Fri, 24 Apr 2015 04:58:35 +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 5DF5111D5 for ; Fri, 24 Apr 2015 04:58:34 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3O4wTQW024814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 23 Apr 2015 21:58:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5539CD6F.2030003@freebsd.org> Date: Fri, 24 Apr 2015 12:58:23 +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: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> In-Reply-To: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> 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, 24 Apr 2015 04:58:35 -0000 On 4/24/15 6:12 AM, Rick Macklem wrote: > John Baldwin wrote: >> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>> I'm debugging a problem being seen with samba 3.6. >>>> >>>> basically telldir/seekdir/readdir don't seem to work as >>>> advertised.. >>> ok so it looks like readdir() (and friends) is totally broken in >>> the face >>> of deletes unless you read the entire directory at once or reset to >>> the >>> the first file before the deletes, or earlier. >> I'm not sure that Samba isn't assuming non-portable behavior. For >> example: >> >> From >> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >> >> If a file is removed from or added to the directory after the most >> recent call >> to opendir() or rewinddir(), whether a subsequent call to readdir() >> returns an >> entry for that file is unspecified. >> >> While this doesn't speak directly to your case, it does note that you >> will >> get inconsistencies if you scan a directory concurrent with add and >> remove. >> >> UFS might kind of work actually since deletes do not compact the >> backing >> directory, but I suspect NFS and ZFS would not work. In addition, >> our >> current NFS support for seekdir is pretty flaky and can't be fixed >> without >> changes to return the seek offset for each directory entry (I believe >> that >> the projects/ino64 patches include this since they are breaking the >> ABI of >> the relevant structures already). The ABI breakage makes this a very >> non-trivial task. However, even if you have that per-item cookie, it >> is >> likely meaningless in the face of filesystems that use any sort of >> more >> advanced structure than an array (such as trees, etc.) to store >> directory >> entries. POSIX specifically mentions this in the rationale for >> seekdir: >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html >> >> One of the perceived problems of implementation is that returning to >> a given point in a directory is quite difficult to describe >> formally, in spite of its intuitive appeal, when systems that use >> B-trees, hashing functions, or other similar mechanisms to order >> their directories are considered. The definition of seekdir() and >> telldir() does not specify whether, when using these interfaces, a >> given directory entry will be seen at all, or more than once. >> >> In fact, given that quote, I would argue that what Samba is doing is >> non-portable. This would seem to indicate that a conforming seekdir >> could >> just change readdir to immediately return EOF until you call >> rewinddir. >> > Btw, Linux somehow makes readdir()/unlink() work for NFS. I haven't looked, > but I strongly suspect that it reads the entire directory upon either opendir() > or the first readdir(). they make it work for everything apparently.. which is quite a trick. > Oh, and I hate to say it, but I suspect Linux defines the "standard" on > this and not POSIX. (In other words, if it works on Linux, it isn't broken;-) > > rick > >> -- >> John Baldwin >> _______________________________________________ >> 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 Fri Apr 24 05:02:49 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 8867717C; Fri, 24 Apr 2015 05:02:49 +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 5DBB812BA; Fri, 24 Apr 2015 05:02:49 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3O52idI024853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Apr 2015 22:02:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5539CE6F.5040802@freebsd.org> Date: Fri, 24 Apr 2015 13:02: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: John Baldwin , freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <5538B510.9040603@freebsd.org> <10872728.5fNYcpCvKN@ralph.baldwin.cx> In-Reply-To: <10872728.5fNYcpCvKN@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, 24 Apr 2015 05:02:49 -0000 On 4/23/15 9:54 PM, John Baldwin wrote: > On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >> On 4/23/15 11:20 AM, Julian Elischer wrote: >>> I'm debugging a problem being seen with samba 3.6. >>> >>> basically telldir/seekdir/readdir don't seem to work as advertised.. >> ok so it looks like readdir() (and friends) is totally broken in the face >> of deletes unless you read the entire directory at once or reset to the >> the first file before the deletes, or earlier. > I'm not sure that Samba isn't assuming non-portable behavior. For example: > > >From http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > > If a file is removed from or added to the directory after the most recent call > to opendir() or rewinddir(), whether a subsequent call to readdir() returns an > entry for that file is unspecified. > > While this doesn't speak directly to your case, it does note that you will > get inconsistencies if you scan a directory concurrent with add and remove. > > UFS might kind of work actually since deletes do not compact the backing > directory, but I suspect NFS and ZFS would not work. In addition, our > current NFS support for seekdir is pretty flaky and can't be fixed without > changes to return the seek offset for each directory entry (I believe that > the projects/ino64 patches include this since they are breaking the ABI of > the relevant structures already). The ABI breakage makes this a very > non-trivial task. However, even if you have that per-item cookie, it is > likely meaningless in the face of filesystems that use any sort of more > advanced structure than an array (such as trees, etc.) to store directory > entries. POSIX specifically mentions this in the rationale for seekdir: > > > One of the perceived problems of implementation is that returning to a given point in a directory is quite difficult to describe formally, in spite of its intuitive appeal, when systems that use B-trees, hashing functions, or other similar mechanisms to order their directories are considered. The definition of seekdir() and telldir() does not specify whether, when using these interfaces, a given directory entry will be seen at all, or more than once. > > In fact, given that quote, I would argue that what Samba is doing is > non-portable. This would seem to indicate that a conforming seekdir could > just change readdir to immediately return EOF until you call rewinddir. how does readdir know that the directory has been changed? fstat? > From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 05:10:46 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 68C51424; Fri, 24 Apr 2015 05:10:46 +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 33A4A13A6; Fri, 24 Apr 2015 05:10:46 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3O5AeKd024876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Apr 2015 22:10:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5539D04A.3090309@freebsd.org> Date: Fri, 24 Apr 2015 13:10:34 +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 , John Baldwin CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <336285737.24821463.1429825825843.JavaMail.root@uoguelph.ca> In-Reply-To: <336285737.24821463.1429825825843.JavaMail.root@uoguelph.ca> 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, 24 Apr 2015 05:10:46 -0000 On 4/24/15 5:50 AM, Rick Macklem wrote: > John Baldwin wrote: >> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>> I'm debugging a problem being seen with samba 3.6. >>>> >>>> basically telldir/seekdir/readdir don't seem to work as >>>> advertised.. >>> ok so it looks like readdir() (and friends) is totally broken in >>> the face >>> of deletes unless you read the entire directory at once or reset to >>> the >>> the first file before the deletes, or earlier. >> I'm not sure that Samba isn't assuming non-portable behavior. For >> example: >> >> From >> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >> >> If a file is removed from or added to the directory after the most >> recent call >> to opendir() or rewinddir(), whether a subsequent call to readdir() >> returns an >> entry for that file is unspecified. >> >> While this doesn't speak directly to your case, it does note that you >> will >> get inconsistencies if you scan a directory concurrent with add and >> remove. >> >> UFS might kind of work actually since deletes do not compact the >> backing >> directory, but I suspect NFS and ZFS would not work. In addition, >> our >> current NFS support for seekdir is pretty flaky and can't be fixed >> without >> changes to return the seek offset for each directory entry (I believe >> that >> the projects/ino64 patches include this since they are breaking the >> ABI of >> the relevant structures already). The ABI breakage makes this a very >> non-trivial task. However, even if you have that per-item cookie, it >> is >> likely meaningless in the face of filesystems that use any sort of >> more >> advanced structure than an array (such as trees, etc.) to store >> directory >> entries. POSIX specifically mentions this in the rationale for >> seekdir: >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html >> >> One of the perceived problems of implementation is that returning to >> a given point in a directory is quite difficult to describe >> formally, in spite of its intuitive appeal, when systems that use >> B-trees, hashing functions, or other similar mechanisms to order >> their directories are considered. The definition of seekdir() and >> telldir() does not specify whether, when using these interfaces, a >> given directory entry will be seen at all, or more than once. >> >> In fact, given that quote, I would argue that what Samba is doing is >> non-portable. This would seem to indicate that a conforming seekdir >> could >> just change readdir to immediately return EOF until you call >> rewinddir. >> > Loosely related to this, I have been tempted to modify readdir() to > read the entire directory on the first readdir() for NFS, to avoid the > readdir()/unlink() problem. I did find a bug in our readdir/seekdir that makes it a lot worse... We reload the kernel's idea of the directory every time we do a seekdir() back, even if it's within the same block, which makes us a lot more susceptible to the problem.. making it not do that unless the new location is in another block made it work on directories with up to several thousand files (with 32k blocksize) before failing. With that bug it's possible do make every seekdir() produce failures even in a directory of just 3 files.. The downside is that the client continues to see the old contents of the block even though he has done a seekdir() within it. > > My concern was doing this for a very large directory. Maybe it could be > done for directories up to some size? > > rick > >> -- >> John Baldwin >> _______________________________________________ >> 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 Fri Apr 24 09:59: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 98BE8F08; Fri, 24 Apr 2015 09:59:56 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 56301118F; Fri, 24 Apr 2015 09:59:56 +0000 (UTC) Received: by obfe9 with SMTP id e9so33943723obf.1; Fri, 24 Apr 2015 02:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=90TsI3ok0pBVACDUO7J8ZZg0JdjWrVCC+rtXjw4RE6U=; b=iKg9TYX73upzLRjvgk9py33kex6veO38AjJscxuhkpG7HmgrVKZU8uEV0UTDUWCP64 9ZXI0NqG9I4mrYwgc32PQ0NjjaEUltJuG2FI3qchEhAPHK/05NmAvyl0EA23b8V+iYQ0 JzUjvG/ePp5QJcDVLvRikqeJ+fr27JWA1D0p8NQp58lovK/WqMLFpIf4zjqnWDRh0t49 6xlxf1yycivtnIe30JAXtn2o6AtZjkgtlWz3qjd0SeReKVa83XTB6Y/y1LVn/ihEDPwr Q9qMSQ4na7l8YyBMn5RM8GoXDqd9guQzVqfkCR1AURvoZHo9ZllNA9pqXgIRxG8SYOCa /v4A== X-Received: by 10.202.224.11 with SMTP id x11mr6139524oig.33.1429869595592; Fri, 24 Apr 2015 02:59:55 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3? ([2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3]) by mx.google.com with ESMTPSA id sn2sm6297452obc.11.2015.04.24.02.59.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Apr 2015 02:59:55 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_10040B4C-8BBC-474F-9503-468A5C45F136"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Newer yacc needed for building world From: Garrett Cooper In-Reply-To: <5538B5CF.9010508@digiware.nl> Date: Fri, 24 Apr 2015 02:59:52 -0700 Cc: Ed Maste , Warren Block , FreeBSD Current Message-Id: References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> <5538B5CF.9010508@digiware.nl> To: Willem Jan Withagen 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: Fri, 24 Apr 2015 09:59:56 -0000 --Apple-Mail=_10040B4C-8BBC-474F-9503-468A5C45F136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 23, 2015, at 2:05, Willem Jan Withagen wrote: > On 22/04/2015 23:37, Ed Maste wrote: >> On 22 April 2015 at 15:55, Willem Jan Withagen = wrote: >>>=20 >>>> Yes: >>>> = https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.h= tml >>>>=20 >>>=20 >>> But this is not enough to make yacc part of the build tools?? >>=20 >> yacc is unconditionally built during bootstrap-tools as of r281615. >> What SVN rev is your tree? >>=20 >=20 > # svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 281853 > Node Kind: directory > Schedule: normal > Last Changed Author: kib > Last Changed Rev: 281849 > Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015) >=20 > Then I removed /usr/obj/* to get a fresh start. > Removing yacc just gets me into trouble even earlier: >=20 > # make -j 32 buildworld > . > . > . > --- _bootstrap-tools-usr.bin/compile_et --- > --- parse.c --- > yacc -d -o parse.c = /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y > yacc: not found > --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree --- > /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for > /usr/src/usr.sbin/bsnmpd/gensnmptree > --- _bootstrap-tools-usr.bin/compile_et --- > *** [parse.c] Error code 127 >=20 > So I have relatively little further to test. > Perhaps the '-j 32' was a bit aggressive, but it gets fast where the > error is. Well, that=92s amusing :(. You found a new race that wasn=92t = present before my changes to parallelize bootstrap-tools (kerberos comes = before yacc in bootstrap-tools). Do you have yacc installed on your = machine? Please try out this patch. Thanks! -NGie $ svn diff Makefile.inc1=20 Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 281823) +++ Makefile.inc1 (working copy) @@ -1358,6 +1358,8 @@ usr.bin/compile_et =20 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} + +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc .endif =20 bootstrap-tools: .PHONY --Apple-Mail=_10040B4C-8BBC-474F-9503-468A5C45F136 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 iQEcBAEBCgAGBQJVOhQYAAoJEMZr5QU6S73eyEEH/RJVdoMij/pIWkhDHCxNxfrU larjaCTwxUjUUQv4eS55Yo6GFa9nGh7MLocyGMtnHmkWpgYpQishcw7zchhu55cK 4ta2iL74wQhTSVMHjIOgCkpA4yPZcC1Sy1e8/e4/WnGzLl+wGj6RsuOIe7YRqpof CfMhkNFrNbgFqloGzga7t3OISkpprCQn8xwmzlkmZ18OS1dBh0xlcWHXLUJhXsF2 zoMNDPNvZza1K+BW03eB4rtkpvNxZOg2fOSNSFKeff82KSAYF2L2lnj9jITb0Dae u46/owobc5u6Kzplu4bO13Zolef3vXBcjMIgSXVJ1CKlkPfKBNTmZLoPoRGJ4sw= =dBIA -----END PGP SIGNATURE----- --Apple-Mail=_10040B4C-8BBC-474F-9503-468A5C45F136-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 10: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 008901D3; Fri, 24 Apr 2015 10:03:36 +0000 (UTC) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 B107A1268; Fri, 24 Apr 2015 10:03:36 +0000 (UTC) Received: by oign205 with SMTP id n205so36473288oig.2; Fri, 24 Apr 2015 03:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iIin2GOda+SsKw00cvkVpd36QYHrlON4fA+TrDw09/o=; b=QHS2s90rXuMMCeBKPlqCxVLvLG57wF8sEoZvKwCJE1bydHYjxrqMOKOfY3B0yJype2 303uq059PGqAvB7nlJ/VPsftADxZdCxRLbBlMwuezJqp9Uz0t0wvPBFl6Nn/s5rAqLoj Nabzvk58928kotf0RHhNIyo0pI+VXgCIhJq/NmIN8eA4F4z9ClYtelPrT2GzxAdaGGcA /nkV518AYmd/So1dboHEqRddsdwT2SUE1SmWbDv0aRLVbGWfv6VWW6eYVNaAyx2BzahC skmPN5uo+IVrlPJ+5X8ForB1x9JbNpVO5DDB2nmLDBKxsrP2wN8scqg89b4xj+BOEBzi EgFQ== X-Received: by 10.202.216.87 with SMTP id p84mr6174927oig.133.1429869815892; Fri, 24 Apr 2015 03:03:35 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3? ([2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3]) by mx.google.com with ESMTPSA id t7sm6302699oie.22.2015.04.24.03.03.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Apr 2015 03:03:35 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9E106D6A-CFF7-4067-B860-DCC87BB20D7B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Newer yacc needed for building world From: Garrett Cooper In-Reply-To: Date: Fri, 24 Apr 2015 03:03:33 -0700 Cc: Ed Maste , Warren Block , FreeBSD Current Message-Id: References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> <5538B5CF.9010508@digiware.nl> To: Willem Jan Withagen 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: Fri, 24 Apr 2015 10:03:37 -0000 --Apple-Mail=_9E106D6A-CFF7-4067-B860-DCC87BB20D7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2015, at 2:59, Garrett Cooper wrote: > On Apr 23, 2015, at 2:05, Willem Jan Withagen wrote: >=20 >> On 22/04/2015 23:37, Ed Maste wrote: >>> On 22 April 2015 at 15:55, Willem Jan Withagen = wrote: >>>>=20 >>>>> Yes: >>>>> = https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.h= tml >>>>>=20 >>>>=20 >>>> But this is not enough to make yacc part of the build tools?? >>>=20 >>> yacc is unconditionally built during bootstrap-tools as of r281615. >>> What SVN rev is your tree? >>>=20 >>=20 >> # svn info >> Path: . >> Working Copy Root Path: /usr/src >> URL: svn://svn.freebsd.org/base/stable/10 >> Relative URL: ^/stable/10 >> Repository Root: svn://svn.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 281853 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: kib >> Last Changed Rev: 281849 >> Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015) >>=20 >> Then I removed /usr/obj/* to get a fresh start. >> Removing yacc just gets me into trouble even earlier: >>=20 >> # make -j 32 buildworld >> . >> . >> . >> --- _bootstrap-tools-usr.bin/compile_et --- >> --- parse.c --- >> yacc -d -o parse.c = /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y >> yacc: not found >> --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree --- >> /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for >> /usr/src/usr.sbin/bsnmpd/gensnmptree >> --- _bootstrap-tools-usr.bin/compile_et --- >> *** [parse.c] Error code 127 >>=20 >> So I have relatively little further to test. >> Perhaps the '-j 32' was a bit aggressive, but it gets fast where the >> error is. >=20 > Well, that=92s amusing :(. You found a new race that wasn=92t = present before my changes to parallelize bootstrap-tools (kerberos comes = before yacc in bootstrap-tools). Do you have yacc installed on your = machine? > Please try out this patch. > Thanks! > -NGie >=20 > $ svn diff Makefile.inc1=20 > Index: Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.inc1 (revision 281823) > +++ Makefile.inc1 (working copy) > @@ -1358,6 +1358,8 @@ > usr.bin/compile_et >=20 > .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} > + > +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc > .endif >=20 > bootstrap-tools: .PHONY It=92ll also need lex too. This should be a bit more comprehensive: Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.inc1 (revision 281823) +++ Makefile.inc1 (working copy) @@ -1358,6 +1358,8 @@ usr.bin/compile_et =20 .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} + +${_bt}-usr.bin/compile_et: ${_bt}$-usr.bin/lex ${_bt}-usr.bin/yacc .endif =20 bootstrap-tools: .PHONY --Apple-Mail=_9E106D6A-CFF7-4067-B860-DCC87BB20D7B 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 iQEcBAEBCgAGBQJVOhT1AAoJEMZr5QU6S73e9MUH/jaHQE7H5VA7hJ1t4xphUPR4 QxARp2lIMk4fr6S97cw36024isJSr1Vr/dkdmsLcNcsC/F3SDd9c6MRm4eB4pJhC v0sYPGyndk/LzE7kMQTf762Wh4goGaGyL1RG9xa+zF4msYozx6kt4An7yDFWYW5X JnJh/hgx+LgiHriGJDEVra1I8xA8/NsePkRRumJ2CAz9lqHYj0ZGpNwN4d7YZO6N z/6PW/WOVCyfdk6M5tS2kHSsWa6i/5cIpszAL5CcIo0rEsEQwQuAhLzG9cOe+9hH JH4vwL0QkGKWrPJ2AtLj9F2iUdJvhR+5zAc0jgTDpaovzztSTJbj4qOhGX5LJ2c= =v9Hs -----END PGP SIGNATURE----- --Apple-Mail=_9E106D6A-CFF7-4067-B860-DCC87BB20D7B-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 10:05: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 03176304; Fri, 24 Apr 2015 10:05:48 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::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 BE0B41289; Fri, 24 Apr 2015 10:05:47 +0000 (UTC) Received: by pdbqa5 with SMTP id qa5so44798530pdb.1; Fri, 24 Apr 2015 03:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=P8ow4/LROkTQL+Fi5iUvUL3xy5KAYhLGceQDbu9wrQg=; b=VLGWv8SHI5A/l3zj0i2voVEYoGtVihiIqyHNQT2pz5pULp38b3q6dWDP+G+Y4Decrb ZiN06f4fI73S63f6KfXiq0ZyFcmjbuqxfy2uBiKSrHh5f/8Ivh2tySdZwkjVoGJ2cNl+ BjmzIWkrLmmclnNgADWVZlaV5Iuw9yCE9Q7EZnLe6r3XjfoStZi2iGnBpEd1MqCRCsUM c00DlDnf5UvZsq45uyXb0UTdPd6Hb2r3T9wJlxP8QL+4wae/DB842div4qyU1Q5mNKvE yu79/lnoNOIOv5/AC+E/taOgPIgY91rP3Rg4ssFGNlUTKu5NTuaXBbspJHwoJz5kTpZ5 7+JA== X-Received: by 10.66.193.33 with SMTP id hl1mr13283781pac.111.1429869947184; Fri, 24 Apr 2015 03:05:47 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3? ([2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3]) by mx.google.com with ESMTPSA id rd7sm10632802pdb.64.2015.04.24.03.05.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Apr 2015 03:05:46 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_879DB1BF-3C30-485B-B225-B6D99E54874F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Newer yacc needed for building world From: Garrett Cooper In-Reply-To: Date: Fri, 24 Apr 2015 03:05:44 -0700 Cc: Ed Maste , Warren Block , FreeBSD Current Message-Id: References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> <5538B5CF.9010508@digiware.nl> To: Willem Jan Withagen 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: Fri, 24 Apr 2015 10:05:48 -0000 --Apple-Mail=_879DB1BF-3C30-485B-B225-B6D99E54874F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2015, at 3:03, Garrett Cooper wrote: > On Apr 24, 2015, at 2:59, Garrett Cooper = wrote: >=20 >> On Apr 23, 2015, at 2:05, Willem Jan Withagen = wrote: >>=20 >>> On 22/04/2015 23:37, Ed Maste wrote: >>>> On 22 April 2015 at 15:55, Willem Jan Withagen = wrote: >>>>>=20 >>>>>> Yes: >>>>>> = https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.h= tml >>>>>>=20 >>>>>=20 >>>>> But this is not enough to make yacc part of the build tools?? >>>>=20 >>>> yacc is unconditionally built during bootstrap-tools as of r281615. >>>> What SVN rev is your tree? >>>>=20 >>>=20 >>> # svn info >>> Path: . >>> Working Copy Root Path: /usr/src >>> URL: svn://svn.freebsd.org/base/stable/10 >>> Relative URL: ^/stable/10 >>> Repository Root: svn://svn.freebsd.org/base >>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>> Revision: 281853 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: kib >>> Last Changed Rev: 281849 >>> Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015) >>>=20 >>> Then I removed /usr/obj/* to get a fresh start. >>> Removing yacc just gets me into trouble even earlier: >>>=20 >>> # make -j 32 buildworld >>> . >>> . >>> . >>> --- _bootstrap-tools-usr.bin/compile_et --- >>> --- parse.c --- >>> yacc -d -o parse.c = /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y >>> yacc: not found >>> --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree --- >>> /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for >>> /usr/src/usr.sbin/bsnmpd/gensnmptree >>> --- _bootstrap-tools-usr.bin/compile_et --- >>> *** [parse.c] Error code 127 >>>=20 >>> So I have relatively little further to test. >>> Perhaps the '-j 32' was a bit aggressive, but it gets fast where the >>> error is. >>=20 >> Well, that=92s amusing :(. You found a new race that wasn=92t = present before my changes to parallelize bootstrap-tools (kerberos comes = before yacc in bootstrap-tools). Do you have yacc installed on your = machine? >> Please try out this patch. >> Thanks! >> -NGie >>=20 >> $ svn diff Makefile.inc1=20 >> Index: Makefile.inc1 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- Makefile.inc1 (revision 281823) >> +++ Makefile.inc1 (working copy) >> @@ -1358,6 +1358,8 @@ >> usr.bin/compile_et >>=20 >> .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} >> + >> +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc >> .endif >>=20 >> bootstrap-tools: .PHONY >=20 > It=92ll also need lex too. This should be a bit more comprehensive: >=20 > Index: Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.inc1 (revision 281823) > +++ Makefile.inc1 (working copy) > @@ -1358,6 +1358,8 @@ > usr.bin/compile_et >=20 > .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} > + > +${_bt}-usr.bin/compile_et: ${_bt}$-usr.bin/lex ${_bt}-usr.bin/yacc > .endif >=20 > bootstrap-tools: .PHONY I=92ll work out the finally kinks with how to spell lex and yacc=85 This is part of the reason why I think BOOTSTRAPPING needs to be kicked = to the curb and everything needs to be built in parallel, but enough = people haven=92t complained about built failures, so the optimization = remains.. --Apple-Mail=_879DB1BF-3C30-485B-B225-B6D99E54874F 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 iQEcBAEBCgAGBQJVOhV4AAoJEMZr5QU6S73ekLYIAI8gpgGDEh5ERXxb7SCO17x2 QHl5w4uRWhhOVdu7MpI6jDzcMBPIQAf/spJfzw2hmP6PXNcteNJr9lQLs23KzXUY xWZtvw13W42X0TVn+Cxk5OP/BuiUUIVZxStbJDbt9dEKhFF57fk6VDKJWnzYm/x/ YRGZ9IHbYzvGE1cxLjh5zZzNojCf4zupqmtXGQkkM2vEiEgC37dCt27J1c/W1md8 R2OxyjWfoiZV6EfPSvx/fk90nWXHOaFWdBtcySwSwdW7EBtfuiP4fBWPSX0EPgCt 1tnDAiwnLMAP8ilQWPJ1vO6/YYLpuAXX9wrhMMYSyMXR0s1t4OCex+jHe9Y7v1Q= =iKMD -----END PGP SIGNATURE----- --Apple-Mail=_879DB1BF-3C30-485B-B225-B6D99E54874F-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 10:42: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 D0585CB8 for ; Fri, 24 Apr 2015 10:42:12 +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 AF8001788 for ; Fri, 24 Apr 2015 10:42:12 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3OAg7bK026363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 24 Apr 2015 03:42:10 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553A1DF9.8060009@freebsd.org> Date: Fri, 24 Apr 2015 18:42:01 +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: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> In-Reply-To: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> 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, 24 Apr 2015 10:42:13 -0000 On 4/24/15 6:12 AM, Rick Macklem wrote: > John Baldwin wrote: >> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>> I'm debugging a problem being seen with samba 3.6. >>>> >>>> basically telldir/seekdir/readdir don't seem to work as >>>> advertised.. >>> ok so it looks like readdir() (and friends) is totally broken in >>> the face >>> of deletes unless you read the entire directory at once or reset to >>> the >>> the first file before the deletes, or earlier. >> I'm not sure that Samba isn't assuming non-portable behavior. For >> example: >> >> From >> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >> >> If a file is removed from or added to the directory after the most >> recent call >> to opendir() or rewinddir(), whether a subsequent call to readdir() >> returns an >> entry for that file is unspecified. >> >> While this doesn't speak directly to your case, it does note that you >> will >> get inconsistencies if you scan a directory concurrent with add and >> remove. >> >> UFS might kind of work actually since deletes do not compact the >> backing >> directory, but I suspect NFS and ZFS would not work. In addition, >> our >> current NFS support for seekdir is pretty flaky and can't be fixed >> without >> changes to return the seek offset for each directory entry (I believe >> that >> the projects/ino64 patches include this since they are breaking the >> ABI of >> the relevant structures already). The ABI breakage makes this a very >> non-trivial task. However, even if you have that per-item cookie, it >> is >> likely meaningless in the face of filesystems that use any sort of >> more >> advanced structure than an array (such as trees, etc.) to store >> directory >> entries. POSIX specifically mentions this in the rationale for >> seekdir: >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html >> >> One of the perceived problems of implementation is that returning to >> a given point in a directory is quite difficult to describe >> formally, in spite of its intuitive appeal, when systems that use >> B-trees, hashing functions, or other similar mechanisms to order >> their directories are considered. The definition of seekdir() and >> telldir() does not specify whether, when using these interfaces, a >> given directory entry will be seen at all, or more than once. >> >> In fact, given that quote, I would argue that what Samba is doing is >> non-portable. This would seem to indicate that a conforming seekdir >> could >> just change readdir to immediately return EOF until you call >> rewinddir. >> > Btw, Linux somehow makes readdir()/unlink() work for NFS. I haven't looked, > but I strongly suspect that it reads the entire directory upon either opendir() > or the first readdir(). > > Oh, and I hate to say it, but I suspect Linux defines the "standard" on > this and not POSIX. (In other words, if it works on Linux, it isn't broken;-) > > rick here's an interesting datapoint. If the test program is run on kFreeBSD using glibc, it runs without flaw. OS-X (bsd derived libc) HFS+ fails FreeBSD libc (UFS) fails FreeBSD libc (ZFS) fails FreeBSD glibc succceeds Centos 6.5 glibc succeeds some NFS tests would be nice to do too I guess... glibc authors seem to have done something right.. it even copes with FreeBSD kernel.. > >> -- >> John Baldwin >> _______________________________________________ >> 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 Fri Apr 24 10:48:40 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 364B4E67; Fri, 24 Apr 2015 10:48:40 +0000 (UTC) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 EA9A517D0; Fri, 24 Apr 2015 10:48:39 +0000 (UTC) Received: by oift201 with SMTP id t201so37202794oif.3; Fri, 24 Apr 2015 03:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rJBRNmbLv0ARMYom1yTkV+DafsfrKfjyQds5DAcgrmo=; b=nxiuiDu2XyPvDoMN77eNtaMXw2rBy43s4l+WasIfm0/CuEdJ1fRlpAv9lLLmaxdDgk t8tzo3wmpnTK0mGDFWD6xl5y9DTqS+oeVyBcSseX+Wm2pIXCOoBnMj9HdNn9eCrkQwH5 09iaddUIIgR/7x2OkTN3gAVzN1MfneSy3WYK6a5lLP/gwihsGV78jgz6HvBnWcEQ1emJ 1duaI++XbUel4Otj1QOe36Qexi5muo5e8+4FFSRCmNRt7yisgJUWYrZFi4G1J5wf9LCP lGYokrScEfhnklfiIJN/iR7WZwPHm1YNwYJdQXSvrUlHFTPRwIZ7mfdB9xxgajrNKKrp wPYw== X-Received: by 10.182.213.38 with SMTP id np6mr6635352obc.34.1429872519291; Fri, 24 Apr 2015 03:48:39 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3? ([2601:8:ab80:7d6:3d8b:afa5:8fc4:e6a3]) by mx.google.com with ESMTPSA id d129sm6348897oig.15.2015.04.24.03.48.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Apr 2015 03:48:38 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_619657EB-1722-49A1-9CDC-0BC3835C518C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: readdir/telldir/seekdir problem (i think) From: Garrett Cooper In-Reply-To: <553A1DF9.8060009@freebsd.org> Date: Fri, 24 Apr 2015 03:48:35 -0700 Cc: freebsd-current@freebsd.org Message-Id: References: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> <553A1DF9.8060009@freebsd.org> To: Julian Elischer 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: Fri, 24 Apr 2015 10:48:40 -0000 --Apple-Mail=_619657EB-1722-49A1-9CDC-0BC3835C518C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2015, at 3:42, Julian Elischer wrote: > here's an interesting datapoint. If the test program is run on = kFreeBSD using glibc, it runs without flaw. >=20 > OS-X (bsd derived libc) HFS+ fails > FreeBSD libc (UFS) fails > FreeBSD libc (ZFS) fails > FreeBSD glibc succceeds > Centos 6.5 glibc succeeds >=20 > some NFS tests would be nice to do too I guess... > glibc authors seem to have done something right.. it even copes with = FreeBSD kernel.. Hi Julian, What version of FreeBSD are you running (uname -a) / coming up = with the above results on? I=92m asking because IIRC there was an issue = that pho@ brought up with readdir/telldir/etc that was fixed on CURRENT = in the past 1-2 years for us, that might be affecting you. Cheers, -NGie --Apple-Mail=_619657EB-1722-49A1-9CDC-0BC3835C518C 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 iQEcBAEBCgAGBQJVOh+DAAoJEMZr5QU6S73e8ZYH/2v7NE17/TEvmfAt5MmDIOBu gHkHK41mg4CQfDTCuW+omD5OQI1kPNjRlskgOGZDrvE9cpD28xOolBgyKD/53qNF i192y+XvhwneVaVb42V19mIOV3VxePWQrY2UD5mSc/ol8jW1KjLaMNdM2klnvSZy WwOTSsUYNG7Rycao62S/YP/7YN7khdCFoM6YjsM620oq1pzQa5rJPeoILdlkJBJt 0k4m3i+ewWWUfjBq7j7yRbyVefaeP0eflJX5PJdWfUEaiNW9SfnnUWWnCBwHO5P7 aJbY1rLiCjUzx4WKVIIYvnygY2iJutl2JmJtpum1PlupzoyLdxq02WNTlajp2BQ= =+hQL -----END PGP SIGNATURE----- --Apple-Mail=_619657EB-1722-49A1-9CDC-0BC3835C518C-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 06:27:11 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 C520F12C for ; Fri, 24 Apr 2015 06:27:11 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c: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 5E6A61B1A for ; Fri, 24 Apr 2015 06:27:11 +0000 (UTC) Received: by wizk4 with SMTP id k4so9848442wiz.1 for ; Thu, 23 Apr 2015 23:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=O7SZ7g/uCC1/M7jitrWbZ9jLED5KUYIBXGlu4acSlXw=; b=mP55lbZ2I83eKnMRfGNKMeKXKCBkJfFE/kqKzYVImMaEUA3kQhUIvbC/Bme1D3L63G jekMKEwCLrYKGkwDRero+2UOdMlUxyGKLZygNelj4f+RLm29FGQLmrLTKbCDrNEvLOB8 bxHmM9PGI4UWPK8g1Bq1xy7VdL9J1bpLlKSDJlrrFLe07HCQgzAYEhFvRG6cMOCPTHvE gOuDjEhzAo873VdIBMcJsl4vKI43468A4yz+zOUad0CzaC3TNIJn8Ven236Mnuk85S69 g20i2iQrVL1BN/XO3QOr0JOAnCs0HcaTtyJ1gFjnt5R2hW22EIhFJcpsshRhcoCrZA3Z IF1g== X-Received: by 10.180.74.144 with SMTP id t16mr832848wiv.33.1429856829835; Thu, 23 Apr 2015 23:27:09 -0700 (PDT) Received: from pumpkin.growveg.org (pumpkin.growveg.org. [62.49.247.162]) by mx.google.com with ESMTPSA id 16sm15447888wjs.41.2015.04.23.23.27.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 23:27:09 -0700 (PDT) From: John X-Google-Original-From: John Message-ID: <5539E23C.4060804@googlemail.com> Date: Fri, 24 Apr 2015 07:27:08 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: geli partition accepts passphrase but will not mount Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Apr 2015 11:28:43 +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: Fri, 24 Apr 2015 06:27:11 -0000 Hello, I'm running 11.0-CURRENT #0 r281867. I've followed the instructions given at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html section 18.12.2. I was able to create the encrypted slice and mount it. I transferred some documents to that drive for safekeeping and unmounted it. Updated the machine and added these lines to the kernel: options GEOM_ELI device crypto but before I could rebuild the system later, it (some hours after this) went into a hard lock. Powering off then on again rebooted the system and from there I was able to run buildworld and friends. Rebooted again, now trying to mount the disk: root@:~ # geli attach -k /root/da0p1.key /dev/da0p1 Enter passphrase: root@:~ root@:~ geli status Name Status Components da0p1.eli ACTIVE da0p1 Trying to mount it, this happens: root@:~ # mount /dev/da0p1.eli /mnt mount: /dev/da0p1.eli: Invalid argument I think this needs fsck but I get root@:~ # fsck -p -t ffs /dev/da0p1.eli Cannot find file system superblock What can I do? thanks, -- John From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 11:30:22 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 12B9DAD5; Fri, 24 Apr 2015 11:30:22 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 952BB1C9E; Fri, 24 Apr 2015 11:30:21 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id AD38816A4B1; Fri, 24 Apr 2015 13:30:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7KYNCU5X_aK; Fri, 24 Apr 2015 13:30:01 +0200 (CEST) Received: from [192.168.101.176] (vpn.ecoracks.nl [31.223.170.173]) by smtp.digiware.nl (Postfix) with ESMTPA id 8896E16A450; Fri, 24 Apr 2015 13:18:36 +0200 (CEST) Message-ID: <553A268B.4000703@digiware.nl> Date: Fri, 24 Apr 2015 13:18:35 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Garrett Cooper CC: Ed Maste , Warren Block , FreeBSD Current Subject: Re: Newer yacc needed for building world References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> <5538B5CF.9010508@digiware.nl> In-Reply-To: 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: Fri, 24 Apr 2015 11:30:22 -0000 On 24/04/2015 12:05, Garrett Cooper wrote: > On Apr 24, 2015, at 3:03, Garrett Cooper wrote: > >> On Apr 24, 2015, at 2:59, Garrett Cooper wrote: >> >>> On Apr 23, 2015, at 2:05, Willem Jan Withagen wrote: >>> >>>> On 22/04/2015 23:37, Ed Maste wrote: >>>>> On 22 April 2015 at 15:55, Willem Jan Withagen wrote: >>>>>> >>>>>>> Yes: >>>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html >>>>>>> >>>>>> >>>>>> But this is not enough to make yacc part of the build tools?? >>>>> >>>>> yacc is unconditionally built during bootstrap-tools as of r281615. >>>>> What SVN rev is your tree? >>>>> >>>> >>>> # svn info >>>> Path: . >>>> Working Copy Root Path: /usr/src >>>> URL: svn://svn.freebsd.org/base/stable/10 >>>> Relative URL: ^/stable/10 >>>> Repository Root: svn://svn.freebsd.org/base >>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> Revision: 281853 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: kib >>>> Last Changed Rev: 281849 >>>> Last Changed Date: 2015-04-22 12:59:05 +0200 (Wed, 22 Apr 2015) >>>> >>>> Then I removed /usr/obj/* to get a fresh start. >>>> Removing yacc just gets me into trouble even earlier: >>>> >>>> # make -j 32 buildworld >>>> . >>>> . >>>> . >>>> --- _bootstrap-tools-usr.bin/compile_et --- >>>> --- parse.c --- >>>> yacc -d -o parse.c /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y >>>> yacc: not found >>>> --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree --- >>>> /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree created for >>>> /usr/src/usr.sbin/bsnmpd/gensnmptree >>>> --- _bootstrap-tools-usr.bin/compile_et --- >>>> *** [parse.c] Error code 127 >>>> >>>> So I have relatively little further to test. >>>> Perhaps the '-j 32' was a bit aggressive, but it gets fast where the >>>> error is. >>> >>> Well, that’s amusing :(. You found a new race that wasn’t present before my changes to parallelize bootstrap-tools (kerberos comes before yacc in bootstrap-tools). Do you have yacc installed on your machine? >>> Please try out this patch. >>> Thanks! >>> -NGie >>> >>> $ svn diff Makefile.inc1 >>> Index: Makefile.inc1 >>> =================================================================== >>> --- Makefile.inc1 (revision 281823) >>> +++ Makefile.inc1 (working copy) >>> @@ -1358,6 +1358,8 @@ >>> usr.bin/compile_et >>> >>> .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} >>> + >>> +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc >>> .endif >>> >>> bootstrap-tools: .PHONY >> >> It’ll also need lex too. This should be a bit more comprehensive: >> >> Index: Makefile.inc1 >> =================================================================== >> --- Makefile.inc1 (revision 281823) >> +++ Makefile.inc1 (working copy) >> @@ -1358,6 +1358,8 @@ >> usr.bin/compile_et >> >> .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} >> + >> +${_bt}-usr.bin/compile_et: ${_bt}$-usr.bin/lex ${_bt}-usr.bin/yacc >> .endif >> >> bootstrap-tools: .PHONY > > I’ll work out the finally kinks with how to spell lex and yacc… > > This is part of the reason why I think BOOTSTRAPPING needs to be kicked to the curb and everything needs to be built in parallel, but enough people haven’t complained about built failures, so the optimization remains.. > Well, what I did for the above test is mv /usr/bin/yacc /usr/bin/yacc.sav Mainly because I already installed a yacc version that did not run out of tablespace for roken. I'll give your patch a go. Turns out that it is even used before that when building bsnmpd. Which make me wonder why that would be a bootstrap-tool, although that is completely different question. :) Everything in Parallel would be interesting. Somebody posted a URL to an paper on this and no more recursive make because it kills the dependancy information, which I found very interesting. --WjW From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 11:30:54 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 C31DABEA for ; Fri, 24 Apr 2015 11:30:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AF9251D44 for ; Fri, 24 Apr 2015 11:30:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 29C6B2E0 for ; Fri, 24 Apr 2015 11:30:54 +0000 (UTC) Date: Fri, 24 Apr 2015 11:30:54 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1568953817.54.1429875054340.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1183491007.52.1429842576357.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1183491007.52.1429842576357.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #970 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: Fri, 24 Apr 2015 11:30:54 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 11:34: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 52FECE71 for ; Fri, 24 Apr 2015 11:34:43 +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 1F2F21D6E for ; Fri, 24 Apr 2015 11:34:43 +0000 (UTC) Received: by iget9 with SMTP id t9so27206911ige.1 for ; Fri, 24 Apr 2015 04:34:42 -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:content-type; bh=7mJmMDzcRjZ52EWYkNCgWODNW1xGE4E/iYeKXtOVjCY=; b=T0RmNJfvEyaMQ5UcykypBhBCPU0pecolbc6IiDdCqw6cmzKw3dMY183UzpsqzIa/iT +Vzz96i5Qp9QXFVQEWKggrYIN4p4T332ZNiyoQfr0HKDW9dS7Q45sTWHF2+Pv7fPHUcj fRdsLPZjJmnc18e+LAnFFSd3Opyexzm7/LLoYlyPDutAt6AltDbTfVLE1B6MM6r9opWJ 1a3kVU6uPsoze/qQQD+mEO0tXwp3sTnJIs5o0ePyQgAH3XKJJIpESiMzpXT7Z9cyzp/w O7rRSKgCGjc0aljO8J97LKa8o5u4QvcUPTlpL5WS3oQWAAoRm3lTFJ8OQTZKj94vVncH ZNxA== MIME-Version: 1.0 X-Received: by 10.107.133.27 with SMTP id h27mr10279499iod.31.1429875282339; Fri, 24 Apr 2015 04:34:42 -0700 (PDT) Received: by 10.64.13.81 with HTTP; Fri, 24 Apr 2015 04:34:42 -0700 (PDT) Date: Fri, 24 Apr 2015 13:34:42 +0200 Message-ID: Subject: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001a113ec1f248a1f0051476c854 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, 24 Apr 2015 11:34:43 -0000 --001a113ec1f248a1f0051476c854 Content-Type: text/plain; charset=UTF-8 The add_bounce_page() can be called from _bus_dmamap_load_phys(). Client virtual address is zero (not valid) in that case. So, client physical address must be used to get an offset when BUS_DMA_KEEP_PG_OFFSET flag is set. Note that client physical address is always valid. Svatopluk Kraus --001a113ec1f248a1f0051476c854 Content-Type: text/plain; charset=US-ASCII; name="add_bounce_page.diff" Content-Disposition: attachment; filename="add_bounce_page.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i8vijyvi0 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2J1c2RtYV9tYWNoZGVwLXY2LmMgYi9zeXMvYXJtL2Fy bS9idXNkbWFfbWFjaGRlcC12Ni5jCmluZGV4IGVkNTAxYzUuLjcyMzZjNWEgMTAwNjQ0Ci0tLSBh L3N5cy9hcm0vYXJtL2J1c2RtYV9tYWNoZGVwLXY2LmMKKysrIGIvc3lzL2FybS9hcm0vYnVzZG1h X21hY2hkZXAtdjYuYwpAQCAtMTY4NSw4ICsxNjg1LDggQEAgYWRkX2JvdW5jZV9wYWdlKGJ1c19k bWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwgdm1fb2Zmc2V0X3QgdmFkZHIsCiAKIAlp ZiAoZG1hdC0+ZmxhZ3MgJiBCVVNfRE1BX0tFRVBfUEdfT0ZGU0VUKSB7CiAJCS8qIFBhZ2Ugb2Zm c2V0IG5lZWRzIHRvIGJlIHByZXNlcnZlZC4gKi8KLQkJYnBhZ2UtPnZhZGRyIHw9IHZhZGRyICYg UEFHRV9NQVNLOwotCQlicGFnZS0+YnVzYWRkciB8PSB2YWRkciAmIFBBR0VfTUFTSzsKKwkJYnBh Z2UtPnZhZGRyIHw9IGFkZHIgJiBQQUdFX01BU0s7CisJCWJwYWdlLT5idXNhZGRyIHw9IGFkZHIg JiBQQUdFX01BU0s7CiAJfQogCWJwYWdlLT5kYXRhdmFkZHIgPSB2YWRkcjsKIAlicGFnZS0+ZGF0 YWFkZHIgPSBhZGRyOwpkaWZmIC0tZ2l0IGEvc3lzL2FybS9hcm0vYnVzZG1hX21hY2hkZXAuYyBi L3N5cy9hcm0vYXJtL2J1c2RtYV9tYWNoZGVwLmMKaW5kZXggMjY1MjkyZC4uYWNkOGY4MSAxMDA2 NDQKLS0tIGEvc3lzL2FybS9hcm0vYnVzZG1hX21hY2hkZXAuYworKysgYi9zeXMvYXJtL2FybS9i dXNkbWFfbWFjaGRlcC5jCkBAIC0xNDQxLDggKzE0NDEsOCBAQCBhZGRfYm91bmNlX3BhZ2UoYnVz X2RtYV90YWdfdCBkbWF0LCBidXNfZG1hbWFwX3QgbWFwLCB2bV9vZmZzZXRfdCB2YWRkciwKIAog CWlmIChkbWF0LT5mbGFncyAmIEJVU19ETUFfS0VFUF9QR19PRkZTRVQpIHsKIAkJLyogUGFnZSBv ZmZzZXQgbmVlZHMgdG8gYmUgcHJlc2VydmVkLiAqLwotCQlicGFnZS0+dmFkZHIgfD0gdmFkZHIg JiBQQUdFX01BU0s7Ci0JCWJwYWdlLT5idXNhZGRyIHw9IHZhZGRyICYgUEFHRV9NQVNLOworCQli cGFnZS0+dmFkZHIgfD0gYWRkciAmIFBBR0VfTUFTSzsKKwkJYnBhZ2UtPmJ1c2FkZHIgfD0gYWRk ciAmIFBBR0VfTUFTSzsKIAl9CiAJYnBhZ2UtPmRhdGF2YWRkciA9IHZhZGRyOwogCWJwYWdlLT5k YXRhYWRkciA9IGFkZHI7CmRpZmYgLS1naXQgYS9zeXMvbWlwcy9taXBzL2J1c2RtYV9tYWNoZGVw LmMgYi9zeXMvbWlwcy9taXBzL2J1c2RtYV9tYWNoZGVwLmMKaW5kZXggMDgzZThmNS4uOTBlYzM5 OSAxMDA2NDQKLS0tIGEvc3lzL21pcHMvbWlwcy9idXNkbWFfbWFjaGRlcC5jCisrKyBiL3N5cy9t aXBzL21pcHMvYnVzZG1hX21hY2hkZXAuYwpAQCAtMTM1OSw4ICsxMzU5LDggQEAgYWRkX2JvdW5j ZV9wYWdlKGJ1c19kbWFfdGFnX3QgZG1hdCwgYnVzX2RtYW1hcF90IG1hcCwgdm1fb2Zmc2V0X3Qg dmFkZHIsCiAKIAlpZiAoZG1hdC0+ZmxhZ3MgJiBCVVNfRE1BX0tFRVBfUEdfT0ZGU0VUKSB7CiAJ CS8qIFBhZ2Ugb2Zmc2V0IG5lZWRzIHRvIGJlIHByZXNlcnZlZC4gKi8KLQkJYnBhZ2UtPnZhZGRy IHw9IHZhZGRyICYgUEFHRV9NQVNLOwotCQlicGFnZS0+YnVzYWRkciB8PSB2YWRkciAmIFBBR0Vf TUFTSzsKKwkJYnBhZ2UtPnZhZGRyIHw9IGFkZHIgJiBQQUdFX01BU0s7CisJCWJwYWdlLT5idXNh ZGRyIHw9IGFkZHIgJiBQQUdFX01BU0s7CiAJfQogCWJwYWdlLT5kYXRhdmFkZHIgPSB2YWRkcjsK IAlicGFnZS0+ZGF0YWFkZHIgPSBhZGRyOwpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvcG93ZXJw Yy9idXNkbWFfbWFjaGRlcC5jIGIvc3lzL3Bvd2VycGMvcG93ZXJwYy9idXNkbWFfbWFjaGRlcC5j CmluZGV4IGJkMjI2YzguLjllYTUxY2UgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3Bvd2VycGMv YnVzZG1hX21hY2hkZXAuYworKysgYi9zeXMvcG93ZXJwYy9wb3dlcnBjL2J1c2RtYV9tYWNoZGVw LmMKQEAgLTExMjEsOCArMTEyMSw4IEBAIGFkZF9ib3VuY2VfcGFnZShidXNfZG1hX3RhZ190IGRt YXQsIGJ1c19kbWFtYXBfdCBtYXAsIHZtX29mZnNldF90IHZhZGRyLAogCiAJaWYgKGRtYXQtPmZs YWdzICYgQlVTX0RNQV9LRUVQX1BHX09GRlNFVCkgewogCQkvKiBQYWdlIG9mZnNldCBuZWVkcyB0 byBiZSBwcmVzZXJ2ZWQuICovCi0JCWJwYWdlLT52YWRkciB8PSB2YWRkciAmIFBBR0VfTUFTSzsK LQkJYnBhZ2UtPmJ1c2FkZHIgfD0gdmFkZHIgJiBQQUdFX01BU0s7CisJCWJwYWdlLT52YWRkciB8 PSBhZGRyICYgUEFHRV9NQVNLOworCQlicGFnZS0+YnVzYWRkciB8PSBhZGRyICYgUEFHRV9NQVNL OwogCX0KIAlicGFnZS0+ZGF0YXZhZGRyID0gdmFkZHI7CiAJYnBhZ2UtPmRhdGFhZGRyID0gYWRk cjsKZGlmZiAtLWdpdCBhL3N5cy94ODYveDg2L2J1c2RtYV9ib3VuY2UuYyBiL3N5cy94ODYveDg2 L2J1c2RtYV9ib3VuY2UuYwppbmRleCAxNDM4MDUzLi5mNWMxYjkyIDEwMDY0NAotLS0gYS9zeXMv eDg2L3g4Ni9idXNkbWFfYm91bmNlLmMKKysrIGIvc3lzL3g4Ni94ODYvYnVzZG1hX2JvdW5jZS5j CkBAIC05OTQsOCArOTk0LDggQEAgYWRkX2JvdW5jZV9wYWdlKGJ1c19kbWFfdGFnX3QgZG1hdCwg YnVzX2RtYW1hcF90IG1hcCwgdm1fb2Zmc2V0X3QgdmFkZHIsCiAKIAlpZiAoZG1hdC0+Y29tbW9u LmZsYWdzICYgQlVTX0RNQV9LRUVQX1BHX09GRlNFVCkgewogCQkvKiBQYWdlIG9mZnNldCBuZWVk cyB0byBiZSBwcmVzZXJ2ZWQuICovCi0JCWJwYWdlLT52YWRkciB8PSB2YWRkciAmIFBBR0VfTUFT SzsKLQkJYnBhZ2UtPmJ1c2FkZHIgfD0gdmFkZHIgJiBQQUdFX01BU0s7CisJCWJwYWdlLT52YWRk ciB8PSBhZGRyICYgUEFHRV9NQVNLOworCQlicGFnZS0+YnVzYWRkciB8PSBhZGRyICYgUEFHRV9N QVNLOwogCX0KIAlicGFnZS0+ZGF0YXZhZGRyID0gdmFkZHI7CiAJYnBhZ2UtPmRhdGFhZGRyID0g YWRkcjsK --001a113ec1f248a1f0051476c854-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 13:36:23 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 40FC3304 for ; Fri, 24 Apr 2015 13:36:23 +0000 (UTC) Received: from relay.mailchannels.net (aso-006-i440.relay.mailchannels.net [23.91.64.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9E66D1AF9 for ; Fri, 24 Apr 2015 13:36:21 +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 90550A10D4; Fri, 24 Apr 2015 13:29:51 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (smtp3.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Fri, 24 Apr 2015 13:29:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1429882191759:4233535000 X-MC-Ingress-Time: 1429882191759 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 1Yldfy-0006CR-Ql; Fri, 24 Apr 2015 13:29:51 +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 t3ODTmRl038216; Fri, 24 Apr 2015 07:29:48 -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+D13QurlkR1ihRcfiohtqs Message-ID: <1429882188.1157.2.camel@freebsd.org> Subject: Re: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET From: Ian Lepore To: Svatopluk Kraus Cc: freebsd-current@freebsd.org Date: Fri, 24 Apr 2015 07:29:48 -0600 In-Reply-To: References: 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: Fri, 24 Apr 2015 13:36:23 -0000 On Fri, 2015-04-24 at 13:34 +0200, Svatopluk Kraus wrote: > The add_bounce_page() can be called from _bus_dmamap_load_phys(). > Client virtual address is zero (not valid) in that case. So, client > physical address must be used to get an offset when > BUS_DMA_KEEP_PG_OFFSET flag is set. Note that client physical address > is always valid. > > Svatopluk Kraus The only user of BUS_DMA_KEEP_PG_OFFSET in the system is USB. If the flag didn't exist, we could do bouncing with a whole lot more efficiency, at least in the ARM world. I wonder if it would be possible to just eliminate the flag (and of course, USB's need for it, which I fully admit I don't understand even a little bit). -- Ian From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 15:03:36 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 515A5B46; Fri, 24 Apr 2015 15:03:36 +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 0F85E16C9; Fri, 24 Apr 2015 15:03:36 +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 C3CA6B95B; Fri, 24 Apr 2015 11:03:34 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) Date: Fri, 24 Apr 2015 10:43:04 -0400 Message-ID: <7363082.VbsWk0ixI7@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <553A1DF9.8060009@freebsd.org> References: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> <553A1DF9.8060009@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, 24 Apr 2015 11:03:34 -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, 24 Apr 2015 15:03:36 -0000 On Friday, April 24, 2015 06:42:01 PM Julian Elischer wrote: > On 4/24/15 6:12 AM, Rick Macklem wrote: > > John Baldwin wrote: > >> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > >>> On 4/23/15 11:20 AM, Julian Elischer wrote: > >>>> I'm debugging a problem being seen with samba 3.6. > >>>> > >>>> basically telldir/seekdir/readdir don't seem to work as > >>>> advertised.. > >>> ok so it looks like readdir() (and friends) is totally broken in > >>> the face > >>> of deletes unless you read the entire directory at once or reset to > >>> the > >>> the first file before the deletes, or earlier. > >> I'm not sure that Samba isn't assuming non-portable behavior. For > >> example: > >> > >> From > >> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > >> > >> If a file is removed from or added to the directory after the most > >> recent call > >> to opendir() or rewinddir(), whether a subsequent call to readdir() > >> returns an > >> entry for that file is unspecified. > >> > >> While this doesn't speak directly to your case, it does note that you > >> will > >> get inconsistencies if you scan a directory concurrent with add and > >> remove. > >> > >> UFS might kind of work actually since deletes do not compact the > >> backing > >> directory, but I suspect NFS and ZFS would not work. In addition, > >> our > >> current NFS support for seekdir is pretty flaky and can't be fixed > >> without > >> changes to return the seek offset for each directory entry (I believe > >> that > >> the projects/ino64 patches include this since they are breaking the > >> ABI of > >> the relevant structures already). The ABI breakage makes this a very > >> non-trivial task. However, even if you have that per-item cookie, it > >> is > >> likely meaningless in the face of filesystems that use any sort of > >> more > >> advanced structure than an array (such as trees, etc.) to store > >> directory > >> entries. POSIX specifically mentions this in the rationale for > >> seekdir: > >> > >> http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html > >> > >> One of the perceived problems of implementation is that returning to > >> a given point in a directory is quite difficult to describe > >> formally, in spite of its intuitive appeal, when systems that use > >> B-trees, hashing functions, or other similar mechanisms to order > >> their directories are considered. The definition of seekdir() and > >> telldir() does not specify whether, when using these interfaces, a > >> given directory entry will be seen at all, or more than once. > >> > >> In fact, given that quote, I would argue that what Samba is doing is > >> non-portable. This would seem to indicate that a conforming seekdir > >> could > >> just change readdir to immediately return EOF until you call > >> rewinddir. > >> > > Btw, Linux somehow makes readdir()/unlink() work for NFS. I haven't looked, > > but I strongly suspect that it reads the entire directory upon either opendir() > > or the first readdir(). > > > > Oh, and I hate to say it, but I suspect Linux defines the "standard" on > > this and not POSIX. (In other words, if it works on Linux, it isn't broken;-) > > > > rick > > here's an interesting datapoint. If the test program is run on > kFreeBSD using glibc, it runs without flaw. > > OS-X (bsd derived libc) HFS+ fails > FreeBSD libc (UFS) fails > FreeBSD libc (ZFS) fails > FreeBSD glibc succceeds > Centos 6.5 glibc succeeds > > some NFS tests would be nice to do too I guess... > glibc authors seem to have done something right.. it even copes with > FreeBSD kernel.. It's probably just reading the entire directory and caching it until rewinddir is called. FreeBSD's libc does this if you have a unionfs mount. It would be a trivial change to always do this, is just means you will never notice any concurrent deletes, adds, or renames until you call rewinddir again. At that point you might as well have the client just do rewinddir each time. You are just moving the caching that Samba should be doing to be portable from samba into libc. I'm not sure that's really an improvement so much as shuffling deck chairs. Also, that is going to keep giving you directory entries for the files you've already removed (unless you patch libc to explicitly hack around that case by stating each entry and skipping ones that fail with ENOENT which would add a lot of overhead). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 15:03:36 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 023C2B43; Fri, 24 Apr 2015 15:03:36 +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 B67D316C8; Fri, 24 Apr 2015 15:03:35 +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 346E4B94B; Fri, 24 Apr 2015 11:03:34 -0400 (EDT) From: John Baldwin To: Julian Elischer Cc: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) Date: Fri, 24 Apr 2015 10:59:35 -0400 Message-ID: <3179863.LLgeEeSADf@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <5539CE6F.5040802@freebsd.org> References: <55386505.70708@freebsd.org> <10872728.5fNYcpCvKN@ralph.baldwin.cx> <5539CE6F.5040802@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, 24 Apr 2015 11:03:34 -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, 24 Apr 2015 15:03:36 -0000 On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote: > On 4/23/15 9:54 PM, John Baldwin wrote: > > On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > >> On 4/23/15 11:20 AM, Julian Elischer wrote: > >>> I'm debugging a problem being seen with samba 3.6. > >>> > >>> basically telldir/seekdir/readdir don't seem to work as advertised.. > >> ok so it looks like readdir() (and friends) is totally broken in the face > >> of deletes unless you read the entire directory at once or reset to the > >> the first file before the deletes, or earlier. > > I'm not sure that Samba isn't assuming non-portable behavior. For example: > > > > >From http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > > > > If a file is removed from or added to the directory after the most recent call > > to opendir() or rewinddir(), whether a subsequent call to readdir() returns an > > entry for that file is unspecified. > > > > While this doesn't speak directly to your case, it does note that you will > > get inconsistencies if you scan a directory concurrent with add and remove. > > > > UFS might kind of work actually since deletes do not compact the backing > > directory, but I suspect NFS and ZFS would not work. In addition, our > > current NFS support for seekdir is pretty flaky and can't be fixed without > > changes to return the seek offset for each directory entry (I believe that > > the projects/ino64 patches include this since they are breaking the ABI of > > the relevant structures already). The ABI breakage makes this a very > > non-trivial task. However, even if you have that per-item cookie, it is > > likely meaningless in the face of filesystems that use any sort of more > > advanced structure than an array (such as trees, etc.) to store directory > > entries. POSIX specifically mentions this in the rationale for seekdir: > > > > > > > One of the perceived problems of implementation is that returning to a given point in a directory is quite difficult to describe formally, in spite of its intuitive appeal, when systems that use B-trees, hashing functions, or other similar mechanisms to order their directories are considered. The definition of seekdir() and telldir() does not specify whether, when using these interfaces, a given directory entry will be seen at all, or more than once. > > > > In fact, given that quote, I would argue that what Samba is doing is > > non-portable. This would seem to indicate that a conforming seekdir could > > just change readdir to immediately return EOF until you call rewinddir. > > how does readdir know that the directory has been changed? fstat? Undefined. FreeBSD's libc doesn't cache the entire directory (unless you are using a union mount), instead it just caches the most recent call to getdirentries(). It then serves up entries from that block until you hit the end. When you hit the end it reads the next block, etc. When you call telldir(), the kernel saves the seek offset from the start of the current block and the offset within that block and returns a cookie to you. seekdir() looks up the cookie to find the (seek offset, block offset) tuple. If the location matches the directory's current location it doesn't do anything, otherwise it seeks to the seek offset and reads a new block via getdirentries(). There is no check for seeing if a directory is changed. Instead, you can only be stale by one "block". When you read a new block it is relative to the directory's state at that time. Rick's suggestion of reusing the block for a seek within a block would be fairly easy to implement, I think it would just be: Index: head/lib/libc/gen/telldir.c =================================================================== --- head/lib/libc/gen/telldir.c (revision 281929) +++ head/lib/libc/gen/telldir.c (working copy) @@ -101,8 +101,10 @@ return; if (lp->loc_loc == dirp->dd_loc && lp->loc_seek == dirp->dd_seek) return; - (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); - dirp->dd_seek = lp->loc_seek; + if (lp->loc_seek != dirp->dd_seek) { + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); + dirp->dd_seek = lp->loc_seek; + } dirp->dd_loc = 0; while (dirp->dd_loc < lp->loc_loc) { dp = _readdir_unlocked(dirp, 0); (You still want to re-parse the block I think since the telldir offset might be from an earlier version of the block and not point to a valid directory entry since they are variable sized.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 16:42: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 A1366A52 for ; Fri, 24 Apr 2015 16:42:12 +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 744ED1367 for ; Fri, 24 Apr 2015 16:42:12 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3OGg09F027681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 09:42:04 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553A7252.2060304@freebsd.org> Date: Sat, 25 Apr 2015 00:41:54 +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: Garrett Cooper CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> <553A1DF9.8060009@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed 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: Fri, 24 Apr 2015 16:42:12 -0000 On 4/24/15 6:48 PM, Garrett Cooper wrote: > On Apr 24, 2015, at 3:42, Julian Elischer wrote: > >> here's an interesting datapoint. If the test program is run on kFreeBSD using glibc, it runs without flaw. >> >> OS-X (bsd derived libc) HFS+ fails >> FreeBSD libc (UFS) fails >> FreeBSD libc (ZFS) fails >> FreeBSD glibc succceeds >> Centos 6.5 glibc succeeds >> >> some NFS tests would be nice to do too I guess... >> glibc authors seem to have done something right.. it even copes with FreeBSD kernel.. > Hi Julian, > What version of FreeBSD are you running (uname -a) / coming up with the above results on? I’m asking because IIRC there was an issue that pho@ brought up with readdir/telldir/etc that was fixed on CURRENT in the past 1-2 years for us, that might be affecting you. > Cheers, > -NGie 11-current as of a few weeks ago From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 16:50: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 2BD00D6D; Fri, 24 Apr 2015 16:50:54 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 BD29214C8; Fri, 24 Apr 2015 16:50:53 +0000 (UTC) Received: by wiax7 with SMTP id x7so39172526wia.0; Fri, 24 Apr 2015 09:50:52 -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:content-type; bh=i2gabPsfiqK3l/ejlwnZktI+OfGWzEDbhnACUPYXjIw=; b=k3NdVRwQQ6AEfk1CgdNxK07sbp1SiQC1lb9UowXOwfpTfKxlaQZy5u6JNsnMgFVaSl H+bXlehCbRe0yiv8CjLQt6AkIK3n4ZLr7YFtRUMPXrmSA+P7IDIs5mvoF6R9NyVCmuk2 RlAHZqvu8iTHpJqEMouKdJ2VIzMcoorE4kuG6Gh/nIZ+E3qoUmeI9wSt4S0+su3gc/r3 Q2LHY8aCcl6YzJn5P1N6x/abUebB8YTCNTUBUjkhmPJs8OMzVLo1WK286tKO1fOdTBMx FEmaiv7n4EafIppXzuszTa+B2LBDXbmcqTPkCPcpHCpVKrbA1sZHAxlV74vbT+FHmEV7 qaMA== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr5474375wib.60.1429894252257; Fri, 24 Apr 2015 09:50:52 -0700 (PDT) Received: by 10.194.38.104 with HTTP; Fri, 24 Apr 2015 09:50:52 -0700 (PDT) Date: Fri, 24 Apr 2015 19:50:52 +0300 Message-ID: Subject: EFI boot loader regression? From: Andrey Fesenko To: freebsd-current , "freebsd-hackers@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, 24 Apr 2015 16:50:54 -0000 Hello, I'm use system with EFI boot loader on Lenovo X220. Old EFI loader work fine if BIOS set any boot priority UEFI or Legacy first. Starting around December last year, system not boot if set UEFI boot first. http://bsdnir.info/files/efi/ screenshots and working version boot loader For the cleanliness of experiment, as a new loader I downloaded and test FreeBSD-11.0-CURRENT-amd64-20150421-r281832-memstick.img From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 17:08:22 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 19E05A24 for ; Fri, 24 Apr 2015 17:08:22 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c: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 A857C16B6 for ; Fri, 24 Apr 2015 17:08:21 +0000 (UTC) Received: by wiun10 with SMTP id n10so27312509wiu.1 for ; Fri, 24 Apr 2015 10:08:20 -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:content-type; bh=pe/2hBib5QyZjh4/lDDoOimLRjrR5HN688oy++VGamQ=; b=eyKWTom13VU7/KZoAmFc9RRBzIctFKjtXJgZMpjvXbTNnnlI0t+O5erwx2myIsGnvc gqvlMmFdwjyGladJUCY7KNLVvi6j6F2flltDcYFeVdL/SsF1t2CbhEtUKjrE54EkW0Qk VDkngzvT58MeO68p+nKXXMdnm8H0kunN7JoCFrUcoadEpl3OiFnDftjNG1yF9lOv1qn7 unQ+H4isQjVNcwnkktJCFFYZbNOWky6T9i3BO/AVxCEIhQO1FTv1qv5hbfYqzVbuymRC ZA4fgNs35DSZhlS2NHdf5/vZURDPR8QfS4DjVHGonkj71scMQIxP8+q6277XPRAs6HEo hqug== MIME-Version: 1.0 X-Received: by 10.194.52.10 with SMTP id p10mr17058303wjo.98.1429895300093; Fri, 24 Apr 2015 10:08:20 -0700 (PDT) Received: by 10.28.218.143 with HTTP; Fri, 24 Apr 2015 10:08:20 -0700 (PDT) Date: Fri, 24 Apr 2015 13:08:20 -0400 Message-ID: Subject: Re: netmap/pkt-gen error From: "S. Amin Marashi" To: freebsd-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: Fri, 24 Apr 2015 17:08:22 -0000 > i am running FreeBSD 9.0R with netmap already in it. > i compiled the pkt-gen.c with gcc in tools/tools/netmap. > after i do ./pkt-gen -i eth0 -f tx -n 500111222 -l 60 -w 5 > > i get an error: > -Unable to open /dev/netmap > -Unable to register bge0 (renamed to eth0). [...] > any idea on the errors/ help. I solved the same issue by compiling the kernel with "device netmap" kernel config. From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 17:21:17 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 8C2E7EFB; Fri, 24 Apr 2015 17:21:17 +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 6A0FD1961; Fri, 24 Apr 2015 17:21:17 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3OHL6G3027860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 10:21:13 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553A7B7C.2060305@freebsd.org> Date: Sat, 25 Apr 2015 01:21:00 +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: John Baldwin , freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <1427525043.24829432.1429827165715.JavaMail.root@uoguelph.ca> <553A1DF9.8060009@freebsd.org> <7363082.VbsWk0ixI7@ralph.baldwin.cx> In-Reply-To: <7363082.VbsWk0ixI7@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, 24 Apr 2015 17:21:17 -0000 On 4/24/15 10:43 PM, John Baldwin wrote: > On Friday, April 24, 2015 06:42:01 PM Julian Elischer wrote: >> On 4/24/15 6:12 AM, Rick Macklem wrote: >>> John Baldwin wrote: >>>> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>>>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>>>> I'm debugging a problem being seen with samba 3.6. >>>>>> >>>>>> basically telldir/seekdir/readdir don't seem to work as >>>>>> advertised.. >>>>> ok so it looks like readdir() (and friends) is totally broken in >>>>> the face >>>>> of deletes unless you read the entire directory at once or reset to >>>>> the >>>>> the first file before the deletes, or earlier. >>>> I'm not sure that Samba isn't assuming non-portable behavior. For >>>> example: >>>> >>>> From >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >>>> >>>> If a file is removed from or added to the directory after the most >>>> recent call >>>> to opendir() or rewinddir(), whether a subsequent call to readdir() >>>> returns an >>>> entry for that file is unspecified. >>>> >>>> While this doesn't speak directly to your case, it does note that you >>>> will >>>> get inconsistencies if you scan a directory concurrent with add and >>>> remove. >>>> >>>> UFS might kind of work actually since deletes do not compact the >>>> backing >>>> directory, but I suspect NFS and ZFS would not work. In addition, >>>> our >>>> current NFS support for seekdir is pretty flaky and can't be fixed >>>> without >>>> changes to return the seek offset for each directory entry (I believe >>>> that >>>> the projects/ino64 patches include this since they are breaking the >>>> ABI of >>>> the relevant structures already). The ABI breakage makes this a very >>>> non-trivial task. However, even if you have that per-item cookie, it >>>> is >>>> likely meaningless in the face of filesystems that use any sort of >>>> more >>>> advanced structure than an array (such as trees, etc.) to store >>>> directory >>>> entries. POSIX specifically mentions this in the rationale for >>>> seekdir: >>>> >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html >>>> >>>> One of the perceived problems of implementation is that returning to >>>> a given point in a directory is quite difficult to describe >>>> formally, in spite of its intuitive appeal, when systems that use >>>> B-trees, hashing functions, or other similar mechanisms to order >>>> their directories are considered. The definition of seekdir() and >>>> telldir() does not specify whether, when using these interfaces, a >>>> given directory entry will be seen at all, or more than once. >>>> >>>> In fact, given that quote, I would argue that what Samba is doing is >>>> non-portable. This would seem to indicate that a conforming seekdir >>>> could >>>> just change readdir to immediately return EOF until you call >>>> rewinddir. >>>> >>> Btw, Linux somehow makes readdir()/unlink() work for NFS. I haven't looked, >>> but I strongly suspect that it reads the entire directory upon either opendir() >>> or the first readdir(). >>> >>> Oh, and I hate to say it, but I suspect Linux defines the "standard" on >>> this and not POSIX. (In other words, if it works on Linux, it isn't broken;-) >>> >>> rick >> here's an interesting datapoint. If the test program is run on >> kFreeBSD using glibc, it runs without flaw. >> >> OS-X (bsd derived libc) HFS+ fails >> FreeBSD libc (UFS) fails >> FreeBSD libc (ZFS) fails >> FreeBSD glibc succceeds >> Centos 6.5 glibc succeeds >> >> some NFS tests would be nice to do too I guess... >> glibc authors seem to have done something right.. it even copes with >> FreeBSD kernel.. > It's probably just reading the entire directory and caching it until > rewinddir is called. FreeBSD's libc does this if you have a unionfs > mount. It would be a trivial change to always do this, is just means > you will never notice any concurrent deletes, adds, or renames until > you call rewinddir again. At that point you might as well have the > client just do rewinddir each time. You are just moving the caching that > Samba should be doing to be portable from samba into libc. I'm not sure > that's really an improvement so much as shuffling deck chairs. > > Also, that is going to keep giving you directory entries for the files > you've already removed (unless you patch libc to explicitly hack around > that case by stating each entry and skipping ones that fail with ENOENT > which would add a lot of overhead). SO I rewrote/ported glibc telldir/readdir to our FreeBSD.. Firstly, a slight addition.. BSD libc also fails on tmpfs ( I found that out by accident.. I thought I was on UFS and forgot I had a tmpfs there) ported glibc readdir/friends works an all three. and it is not caching the whole thing.. I'm doing the deletes in batches of 5. and every 5 deletes I see it doing: 95985 testit2 RET write 30/0x1e 95985 testit2 CALL write(0x1,0x801007000,0x18) 95985 testit2 GIO fd 1 wrote 24 bytes "file file-1756 returned " 95985 testit2 RET write 24/0x18 95985 testit2 CALL write(0x1,0x801007000,0x1d) 95985 testit2 GIO fd 1 wrote 29 bytes "Seeking back to location 144 " 95985 testit2 RET write 29/0x1d 95985 testit2 CALL lseek(0x3,0x90,SEEK_SET) 95985 testit2 RET lseek 144/0x90 95985 testit2 CALL write(0x1,0x801007000,0x1e) 95985 testit2 GIO fd 1 wrote 30 bytes "telldir assigned location 144 " " 95985 testit2 RET write 30/0x1e 95985 testit2 CALL getdents(0x3,0x801008000,0x20000) 95985 testit2 RET getdents 79464/0x13668 95985 testit2 CALL write(0x1,0x801007000,0x26) 95985 testit2 GIO fd 1 wrote 38 bytes "readdir (144) returned file file-1756 " so the matrix appears to be: ZFS UFS TMPFS EXT2FS BSD GLIBC OK OK OK . BSD LIBC BAD BAD BAD . LINUX GLIBC . . . OK KFREEBSD OK OK . . (tmpfs and ZFS on 10.1, UFS on i386/-current (March) (that's the machines I have..) the BSD libc appeared to work on ZFS until I had more files... I think because the block size is bigger... then it failed. I've put both version and the test program at: https://people.freebsd.org/~julian/readdir/ testit is linked with dir.c which is our code extracted out to a standalone file.. testit2 is the same test program linked with dir2.c which is the glibc based code smashed into our format and massively cleaned up. both will write 40,000 files to the directory 'test2' and then delete them in chunks... The glibc inspired one hasn't been seen to fail yet. but I'm not sure what it's doing is actually kosher. From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 17:30:43 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 D4AB737A; Fri, 24 Apr 2015 17:30: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 AF2151A30; Fri, 24 Apr 2015 17:30:43 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3OHUU23027888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 10:30:38 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553A7DB0.8080308@freebsd.org> Date: Sat, 25 Apr 2015 01:30:24 +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: John Baldwin CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <10872728.5fNYcpCvKN@ralph.baldwin.cx> <5539CE6F.5040802@freebsd.org> <3179863.LLgeEeSADf@ralph.baldwin.cx> In-Reply-To: <3179863.LLgeEeSADf@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, 24 Apr 2015 17:30:44 -0000 On 4/24/15 10:59 PM, John Baldwin wrote: > On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote: >> On 4/23/15 9:54 PM, John Baldwin wrote: >>> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>>> I'm debugging a problem being seen with samba 3.6. >>>>> >>>>> basically telldir/seekdir/readdir don't seem to work as advertised.. >>>> ok so it looks like readdir() (and friends) is totally broken in the face >>>> of deletes unless you read the entire directory at once or reset to the >>>> the first file before the deletes, or earlier. >>> I'm not sure that Samba isn't assuming non-portable behavior. For example: >>> >>> >From http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >>> >>> If a file is removed from or added to the directory after the most recent call >>> to opendir() or rewinddir(), whether a subsequent call to readdir() returns an >>> entry for that file is unspecified. >>> >>> While this doesn't speak directly to your case, it does note that you will >>> get inconsistencies if you scan a directory concurrent with add and remove. >>> >>> UFS might kind of work actually since deletes do not compact the backing >>> directory, but I suspect NFS and ZFS would not work. In addition, our >>> current NFS support for seekdir is pretty flaky and can't be fixed without >>> changes to return the seek offset for each directory entry (I believe that >>> the projects/ino64 patches include this since they are breaking the ABI of >>> the relevant structures already). The ABI breakage makes this a very >>> non-trivial task. However, even if you have that per-item cookie, it is >>> likely meaningless in the face of filesystems that use any sort of more >>> advanced structure than an array (such as trees, etc.) to store directory >>> entries. POSIX specifically mentions this in the rationale for seekdir: >>> >>> One of the perceived problems of implementation is that returning to a given point in a directory is quite difficult to describe formally, in spite of its intuitive appeal, when systems that use B-trees, hashing functions, or other similar mechanisms to order their directories are considered. The definition of seekdir() and telldir() does not specify whether, when using these interfaces, a given directory entry will be seen at all, or more than once. >>> >>> In fact, given that quote, I would argue that what Samba is doing is >>> non-portable. This would seem to indicate that a conforming seekdir could >>> just change readdir to immediately return EOF until you call rewinddir. >> how does readdir know that the directory has been changed? fstat? > Undefined. FreeBSD's libc doesn't cache the entire directory (unless you > are using a union mount), instead it just caches the most recent call to > getdirentries(). It then serves up entries from that block until you hit > the end. When you hit the end it reads the next block, etc. When you > call telldir(), the kernel saves the seek offset from the start of the > current block and the offset within that block and returns a cookie to > you. seekdir() looks up the cookie to find the (seek offset, block offset) > tuple. If the location matches the directory's current location it doesn't > do anything, otherwise it seeks to the seek offset and reads a new block via > getdirentries(). There is no check for seeing if a directory is > changed. Instead, you can only be stale by one "block". When you read > a new block it is relative to the directory's state at that time. > > Rick's suggestion of reusing the block for a seek within a block would be > fairly easy to implement, I think it would just be: > > Index: head/lib/libc/gen/telldir.c > =================================================================== > --- head/lib/libc/gen/telldir.c (revision 281929) > +++ head/lib/libc/gen/telldir.c (working copy) > @@ -101,8 +101,10 @@ > return; > if (lp->loc_loc == dirp->dd_loc && lp->loc_seek == dirp->dd_seek) > return; > - (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); > - dirp->dd_seek = lp->loc_seek; > + if (lp->loc_seek != dirp->dd_seek) { > + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); > + dirp->dd_seek = lp->loc_seek; > + } yes I did that yesterday but it still fails when you transition blocks.. (badly). I also tried bigger blocks.. also fails (eventually) I did find a way to make it work... you had to seek back to the first block you deleted on each set.. then work forward from there again.. unfortunately since I'm trying to make a microsoft program not fail (via samba) I have no control over how it does things and seekdir doesn't know what was deleted anyway... (so the fix is fine for the test program but not for real life) I think I can make the BSD one act like the linux one by changing the lseek being done to use the offset (loc) plus the buffer seek address of the target, instead of just going for the buffer base and stepping forward through the entries.. maybe tomorrow. > dirp->dd_loc = 0; > while (dirp->dd_loc < lp->loc_loc) { > dp = _readdir_unlocked(dirp, 0); > > > (You still want to re-parse the block I think since the telldir offset > might be from an earlier version of the block and not point to a valid > directory entry since they are variable sized.) > From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 18:23:35 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 9328F23E for ; Fri, 24 Apr 2015 18:23:35 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 27589107A for ; Fri, 24 Apr 2015 18:23:35 +0000 (UTC) Received: by wgyo15 with SMTP id o15so59084745wgy.2 for ; Fri, 24 Apr 2015 11:23:33 -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 :content-type; bh=kRdnCO52uX3Sp+qNJwlTvW3mUVuH5zAGL87Gjy44Sk0=; b=gQ1QeMdlj1VXO6rSfuj9jQFtiINu8Wu+Qj1wFDe5Pns5F1ZS7U8FXDvexk3CCooxpy Aq+G+vF/ZNPRSsNNYVA0MieOdRPi4tWQju7id6JEOsZ047yoVJaJvA2wIB+rwsSRMVQU Z5coftF2p7sd1jDJoaeP8Qec5b3/tGMBO7TygYxh08z9RBIdHNUx7IahDgQWuJTVo7c2 uriuyalTKsS4DJ51K3urnTrBAXrPI6MbnJAq3A6FV5bf1HSYtRJPobHt+fegjusCy8JR BL6jO55jPa9bVNdJocBXZvVo/PAiGUFyohTbfYF1lEsWZiAFmmHsT9Y7C8WVZT8BKaNH 5zDw== MIME-Version: 1.0 X-Received: by 10.194.52.10 with SMTP id p10mr17561591wjo.98.1429899813748; Fri, 24 Apr 2015 11:23:33 -0700 (PDT) Received: by 10.28.218.143 with HTTP; Fri, 24 Apr 2015 11:23:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Apr 2015 14:23:33 -0400 Message-ID: Subject: Re: netmap/pkt-gen error From: "S. Amin Marashi" To: freebsd-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: Fri, 24 Apr 2015 18:23:35 -0000 the bridge example didn't work till I changed my interface name: em0 to netmap:em0 On Fri, Apr 24, 2015 at 1:08 PM, S. Amin Marashi wrote: > > i am running FreeBSD 9.0R with netmap already in it. > > i compiled the pkt-gen.c with gcc in tools/tools/netmap. > > after i do ./pkt-gen -i eth0 -f tx -n 500111222 -l 60 -w 5 > > > > i get an error: > > -Unable to open /dev/netmap > > -Unable to register bge0 (renamed to eth0). > [...] > > any idea on the errors/ help. > > I solved the same issue by compiling the kernel with "device netmap" > kernel config. > From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 18:36:43 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 17D106BE; Fri, 24 Apr 2015 18:36: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 CACD211DB; Fri, 24 Apr 2015 18:36:42 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3OIaUuj028136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 11:36:38 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553A8D28.7090901@freebsd.org> Date: Sat, 25 Apr 2015 02:36:24 +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: John Baldwin CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <10872728.5fNYcpCvKN@ralph.baldwin.cx> <5539CE6F.5040802@freebsd.org> <3179863.LLgeEeSADf@ralph.baldwin.cx> <553A7DB0.8080308@freebsd.org> In-Reply-To: <553A7DB0.8080308@freebsd.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: Fri, 24 Apr 2015 18:36:43 -0000 On 4/25/15 1:30 AM, Julian Elischer wrote: > On 4/24/15 10:59 PM, John Baldwin wrote: >> On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote: >>> On 4/23/15 9:54 PM, John Baldwin wrote: >>>> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>>>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>>>> I'm debugging a problem being seen with samba 3.6. >>>>>> >>>>>> basically telldir/seekdir/readdir don't seem to work as >>>>>> advertised.. >>>>> ok so it looks like readdir() (and friends) is totally broken in >>>>> the face >>>>> of deletes unless you read the entire directory at once or reset >>>>> to the >>>>> the first file before the deletes, or earlier. >>>> I'm not sure that Samba isn't assuming non-portable behavior. >>>> For example: >>>> >>>> >From >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >>>> >>>> >>>> If a file is removed from or added to the directory after the >>>> most recent call >>>> to opendir() or rewinddir(), whether a subsequent call to >>>> readdir() returns an >>>> entry for that file is unspecified. >>>> >>>> While this doesn't speak directly to your case, it does note that >>>> you will >>>> get inconsistencies if you scan a directory concurrent with add >>>> and remove. >>>> >>>> UFS might kind of work actually since deletes do not compact the >>>> backing >>>> directory, but I suspect NFS and ZFS would not work. In >>>> addition, our >>>> current NFS support for seekdir is pretty flaky and can't be >>>> fixed without >>>> changes to return the seek offset for each directory entry (I >>>> believe that >>>> the projects/ino64 patches include this since they are breaking >>>> the ABI of >>>> the relevant structures already). The ABI breakage makes this a >>>> very >>>> non-trivial task. However, even if you have that per-item >>>> cookie, it is >>>> likely meaningless in the face of filesystems that use any sort >>>> of more >>>> advanced structure than an array (such as trees, etc.) to store >>>> directory >>>> entries. POSIX specifically mentions this in the rationale for >>>> seekdir: >>>> >>>> One of the perceived problems of implementation is that returning >>>> to a given point in a directory is quite difficult to describe >>>> formally, in spite of its intuitive appeal, when systems that use >>>> B-trees, hashing functions, or other similar mechanisms to order >>>> their directories are considered. The definition of seekdir() and >>>> telldir() does not specify whether, when using these interfaces, >>>> a given directory entry will be seen at all, or more than once. >>>> >>>> In fact, given that quote, I would argue that what Samba is doing is >>>> non-portable. This would seem to indicate that a conforming >>>> seekdir could >>>> just change readdir to immediately return EOF until you call >>>> rewinddir. >>> how does readdir know that the directory has been changed? fstat? >> Undefined. FreeBSD's libc doesn't cache the entire directory >> (unless you >> are using a union mount), instead it just caches the most recent >> call to >> getdirentries(). It then serves up entries from that block until >> you hit >> the end. When you hit the end it reads the next block, etc. When you >> call telldir(), the kernel saves the seek offset from the start of the >> current block and the offset within that block and returns a cookie to >> you. seekdir() looks up the cookie to find the (seek offset, block >> offset) >> tuple. If the location matches the directory's current location it >> doesn't >> do anything, otherwise it seeks to the seek offset and reads a new >> block via >> getdirentries(). There is no check for seeing if a directory is >> changed. Instead, you can only be stale by one "block". When you >> read >> a new block it is relative to the directory's state at that time. >> >> Rick's suggestion of reusing the block for a seek within a block >> would be >> fairly easy to implement, I think it would just be: >> >> Index: head/lib/libc/gen/telldir.c >> =================================================================== >> --- head/lib/libc/gen/telldir.c (revision 281929) >> +++ head/lib/libc/gen/telldir.c (working copy) >> @@ -101,8 +101,10 @@ >> return; >> if (lp->loc_loc == dirp->dd_loc && lp->loc_seek == >> dirp->dd_seek) >> return; >> - (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); >> - dirp->dd_seek = lp->loc_seek; >> + if (lp->loc_seek != dirp->dd_seek) { >> + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, >> SEEK_SET); >> + dirp->dd_seek = lp->loc_seek; >> + } > > yes I did that yesterday but it still fails when you transition > blocks.. (badly). > > I also tried bigger blocks.. also fails (eventually) > > I did find a way to make it work... you had to seek back > to the first block you deleted on each set.. > then work forward from there again.. unfortunately since > I'm trying to make a microsoft program not fail (via samba) > I have no control over how it does things and seekdir doesn't > know what was deleted anyway... (so the fix is fine for the > test program but not for real life) > > I think I can make the BSD one act like the linux one by changing > the lseek being done to use the offset (loc) plus the buffer seek > address of the target, instead of just going for the buffer base and > stepping forward through the entries.. > > maybe tomorrow. > The following conditional code makes ours behave the same as the linux one. it breaks several 'rules' but works where ours is clean but fails.. as Rick said.. "maybe that's what we should do too." this is at the end of seekdir() The new code does what linux does.. and shouldn't work.. but does // at least in the limited conditions I need it to. // We'll probably need to do this at work...: The original code is what we have now, but gets mightily confused sometimes. // This is clean(er) but fails in specific situations(when doing commands // from Microft windows, via samba). root@vps1:/tmp # diff -u dir.c.orig dir.c --- dir.c.orig 2015-04-24 11:29:36.855317000 -0700 +++ dir.c 2015-04-24 11:15:49.058500000 -0700 @@ -1105,6 +1105,13 @@ dirp->dd_loc = lp->loc_loc; return; } +#ifdef GLIBC_SEEK + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek + lp->loc_loc, SEEK_SET); + dirp->dd_seek = lp->loc_seek + lp->loc_loc; + dirp->dd_loc = 0; + lp->loc_seek = dirp->dd_seek; + lp->loc_loc = 0; +#else (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); dirp->dd_seek = lp->loc_seek; dirp->dd_loc = 0; @@ -1114,6 +1121,7 @@ if (dp == NULL) break; } +#endif } > > > > > >> dirp->dd_loc = 0; >> while (dirp->dd_loc < lp->loc_loc) { >> dp = _readdir_unlocked(dirp, 0); >> >> >> (You still want to re-parse the block I think since the telldir offset >> might be from an earlier version of the block and not point to a valid >> directory entry since they are variable sized.) >> > > _______________________________________________ > 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 Fri Apr 24 20:28:31 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 9CBE2F9B; Fri, 24 Apr 2015 20:28:31 +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 7345D1E45; Fri, 24 Apr 2015 20:28:31 +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 90176B924; Fri, 24 Apr 2015 16:28:29 -0400 (EDT) From: John Baldwin To: Julian Elischer Cc: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) Date: Fri, 24 Apr 2015 16:28:12 -0400 Message-ID: <4718551.Y2ZnMk6NSM@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <553A8D28.7090901@freebsd.org> References: <55386505.70708@freebsd.org> <553A7DB0.8080308@freebsd.org> <553A8D28.7090901@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, 24 Apr 2015 16:28:29 -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, 24 Apr 2015 20:28:31 -0000 On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote: > On 4/25/15 1:30 AM, Julian Elischer wrote: > > On 4/24/15 10:59 PM, John Baldwin wrote: > >> On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote: > >>> On 4/23/15 9:54 PM, John Baldwin wrote: > >>>> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > >>>>> On 4/23/15 11:20 AM, Julian Elischer wrote: > >>>>>> I'm debugging a problem being seen with samba 3.6. > >>>>>> > >>>>>> basically telldir/seekdir/readdir don't seem to work as > >>>>>> advertised.. > >>>>> ok so it looks like readdir() (and friends) is totally broken in > >>>>> the face > >>>>> of deletes unless you read the entire directory at once or reset > >>>>> to the > >>>>> the first file before the deletes, or earlier. > >>>> I'm not sure that Samba isn't assuming non-portable behavior. > >>>> For example: > >>>> > >>>> >From > >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > >>>> > >>>> > >>>> If a file is removed from or added to the directory after the > >>>> most recent call > >>>> to opendir() or rewinddir(), whether a subsequent call to > >>>> readdir() returns an > >>>> entry for that file is unspecified. > >>>> > >>>> While this doesn't speak directly to your case, it does note that > >>>> you will > >>>> get inconsistencies if you scan a directory concurrent with add > >>>> and remove. > >>>> > >>>> UFS might kind of work actually since deletes do not compact the > >>>> backing > >>>> directory, but I suspect NFS and ZFS would not work. In > >>>> addition, our > >>>> current NFS support for seekdir is pretty flaky and can't be > >>>> fixed without > >>>> changes to return the seek offset for each directory entry (I > >>>> believe that > >>>> the projects/ino64 patches include this since they are breaking > >>>> the ABI of > >>>> the relevant structures already). The ABI breakage makes this a > >>>> very > >>>> non-trivial task. However, even if you have that per-item > >>>> cookie, it is > >>>> likely meaningless in the face of filesystems that use any sort > >>>> of more > >>>> advanced structure than an array (such as trees, etc.) to store > >>>> directory > >>>> entries. POSIX specifically mentions this in the rationale for > >>>> seekdir: > >>>> > >>>> One of the perceived problems of implementation is that returning > >>>> to a given point in a directory is quite difficult to describe > >>>> formally, in spite of its intuitive appeal, when systems that use > >>>> B-trees, hashing functions, or other similar mechanisms to order > >>>> their directories are considered. The definition of seekdir() and > >>>> telldir() does not specify whether, when using these interfaces, > >>>> a given directory entry will be seen at all, or more than once. > >>>> > >>>> In fact, given that quote, I would argue that what Samba is doing is > >>>> non-portable. This would seem to indicate that a conforming > >>>> seekdir could > >>>> just change readdir to immediately return EOF until you call > >>>> rewinddir. > >>> how does readdir know that the directory has been changed? fstat? > >> Undefined. FreeBSD's libc doesn't cache the entire directory > >> (unless you > >> are using a union mount), instead it just caches the most recent > >> call to > >> getdirentries(). It then serves up entries from that block until > >> you hit > >> the end. When you hit the end it reads the next block, etc. When you > >> call telldir(), the kernel saves the seek offset from the start of the > >> current block and the offset within that block and returns a cookie to > >> you. seekdir() looks up the cookie to find the (seek offset, block > >> offset) > >> tuple. If the location matches the directory's current location it > >> doesn't > >> do anything, otherwise it seeks to the seek offset and reads a new > >> block via > >> getdirentries(). There is no check for seeing if a directory is > >> changed. Instead, you can only be stale by one "block". When you > >> read > >> a new block it is relative to the directory's state at that time. > >> > >> Rick's suggestion of reusing the block for a seek within a block > >> would be > >> fairly easy to implement, I think it would just be: > >> > >> Index: head/lib/libc/gen/telldir.c > >> =================================================================== > >> --- head/lib/libc/gen/telldir.c (revision 281929) > >> +++ head/lib/libc/gen/telldir.c (working copy) > >> @@ -101,8 +101,10 @@ > >> return; > >> if (lp->loc_loc == dirp->dd_loc && lp->loc_seek == > >> dirp->dd_seek) > >> return; > >> - (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); > >> - dirp->dd_seek = lp->loc_seek; > >> + if (lp->loc_seek != dirp->dd_seek) { > >> + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, > >> SEEK_SET); > >> + dirp->dd_seek = lp->loc_seek; > >> + } > > > > yes I did that yesterday but it still fails when you transition > > blocks.. (badly). > > > > I also tried bigger blocks.. also fails (eventually) > > > > I did find a way to make it work... you had to seek back > > to the first block you deleted on each set.. > > then work forward from there again.. unfortunately since > > I'm trying to make a microsoft program not fail (via samba) > > I have no control over how it does things and seekdir doesn't > > know what was deleted anyway... (so the fix is fine for the > > test program but not for real life) > > > > I think I can make the BSD one act like the linux one by changing > > the lseek being done to use the offset (loc) plus the buffer seek > > address of the target, instead of just going for the buffer base and > > stepping forward through the entries.. > > > > maybe tomorrow. > > > > The following conditional code makes ours behave the same as the linux > one. > it breaks several 'rules' but works where ours is clean but fails.. > as Rick said.. "maybe that's what we should do too." > > > this is at the end of seekdir() > > > The new code does what linux does.. and shouldn't work.. but does > // at least in the limited conditions I need it to. > // We'll probably need to do this at work...: > > > The original code is what we have now, but gets mightily confused > sometimes. > // This is clean(er) but fails in specific situations(when > doing commands > // from Microft windows, via samba). > > > root@vps1:/tmp # diff -u dir.c.orig dir.c > --- dir.c.orig 2015-04-24 11:29:36.855317000 -0700 > +++ dir.c 2015-04-24 11:15:49.058500000 -0700 > @@ -1105,6 +1105,13 @@ > dirp->dd_loc = lp->loc_loc; > return; > } > +#ifdef GLIBC_SEEK > + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek + lp->loc_loc, > SEEK_SET); > + dirp->dd_seek = lp->loc_seek + lp->loc_loc; > + dirp->dd_loc = 0; > + lp->loc_seek = dirp->dd_seek; > + lp->loc_loc = 0; > +#else > (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); > dirp->dd_seek = lp->loc_seek; > dirp->dd_loc = 0; > @@ -1114,6 +1121,7 @@ > if (dp == NULL) > break; > } > +#endif > } Yes, this isn't at all safe. There's no guarantee whatsoever that the offset on the directory fd that isn't something returned by getdirentries has any meaning. In particular, the size of the directory entry in a random filesystem might be a different size than the structure returned by getdirentries (since it converts things into a FS-independent format). This might work for UFS by accident, but this is probably why ZFS doesn't work. However, this might be properly fixed by the thing that ino64 is doing where each directory entry returned by getdirentries gives you a seek offset that you _can_ directly seek to (as opposed to seeking to the start of the block and then walking forward N entries until you get an inter-block entry that is the same). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Apr 24 21:52:53 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 46602FB2; Fri, 24 Apr 2015 21:52:53 +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 0CB46189E; Fri, 24 Apr 2015 21:52:53 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 7FD3D358C59; Fri, 24 Apr 2015 23:52:49 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 55D6528494; Fri, 24 Apr 2015 23:52:49 +0200 (CEST) Date: Fri, 24 Apr 2015 23:52:49 +0200 From: Jilles Tjoelker To: John Baldwin Cc: Julian Elischer , freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) Message-ID: <20150424215249.GA96554@stack.nl> References: <55386505.70708@freebsd.org> <553A7DB0.8080308@freebsd.org> <553A8D28.7090901@freebsd.org> <4718551.Y2ZnMk6NSM@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4718551.Y2ZnMk6NSM@ralph.baldwin.cx> 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: Fri, 24 Apr 2015 21:52:53 -0000 On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > Yes, this isn't at all safe. There's no guarantee whatsoever that > the offset on the directory fd that isn't something returned by > getdirentries has any meaning. In particular, the size of the > directory entry in a random filesystem might be a different size > than the structure returned by getdirentries (since it converts > things into a FS-independent format). > This might work for UFS by accident, but this is probably why ZFS > doesn't work. > However, this might be properly fixed by the thing that ino64 is > doing where each directory entry returned by getdirentries gives > you a seek offset that you _can_ directly seek to (as opposed to > seeking to the start of the block and then walking forward N > entries until you get an inter-block entry that is the same). The ino64 branch only reserves space for d_off and does not use it in any way. This is appropriate since actually using d_off is a major feature addition. A proper d_off would still be useful even if UFS's readdir keeps masking off the offset so a directory read always starts at the beginning of a 512-byte directory block, since this allows more distinct offset values than safely using getdirentries()'s *basep. With d_off, one outer loop must read at least one directory block to avoid spinning indefinitely, while using getdirentries()'s *basep requires reading the whole getdirentries() buffer. Some Linux filesystems go further and provide a unique d_off for each entry. Another idea would be to store the last d_ino instead of dd_loc into the struct ddloc. On seekdir(), this would seek to loc_seek as before and skip entries until that d_ino is found, or to the start of the buffer if not found (and possibly return some entries again that should not be returned, but Samba copes with that). -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 01:39: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 7401D688; Sat, 25 Apr 2015 01:39:39 +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 192091D5F; Sat, 25 Apr 2015 01:39:38 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwAW7zpV/95baINbg15cBYMVwzkJgUcKhTZOAoF1FAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCwUWGAICDRkCKQEJJgYIBwQBHASIAggNtkWUSgEBAQEGAQEBAQEBARuBIYoWhDIBARw0B4JogUUFlVSECINRPYV7jXsjhBAiMQeBBDmBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,644,1422939600"; d="scan'208";a="206046163" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 24 Apr 2015 21:39:33 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DBD19B3EB1; Fri, 24 Apr 2015 21:39:31 -0400 (EDT) Date: Fri, 24 Apr 2015 21:39:31 -0400 (EDT) From: Rick Macklem To: Jilles Tjoelker Cc: Julian Elischer , freebsd-current@freebsd.org, John Baldwin Message-ID: <326462676.25571625.1429925971889.JavaMail.root@uoguelph.ca> In-Reply-To: <20150424215249.GA96554@stack.nl> Subject: Re: readdir/telldir/seekdir problem (i think) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] 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: Sat, 25 Apr 2015 01:39:39 -0000 Jilles Tjoelker wrote: > On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > > Yes, this isn't at all safe. There's no guarantee whatsoever that > > the offset on the directory fd that isn't something returned by > > getdirentries has any meaning. In particular, the size of the > > directory entry in a random filesystem might be a different size > > than the structure returned by getdirentries (since it converts > > things into a FS-independent format). > > > This might work for UFS by accident, but this is probably why ZFS > > doesn't work. > > > However, this might be properly fixed by the thing that ino64 is > > doing where each directory entry returned by getdirentries gives > > you a seek offset that you _can_ directly seek to (as opposed to > > seeking to the start of the block and then walking forward N > > entries until you get an inter-block entry that is the same). > > The ino64 branch only reserves space for d_off and does not use it in > any way. This is appropriate since actually using d_off is a major > feature addition. > Well, at some point ino64 will need to define a new getdirentries(2) syscall and I believe this new syscall can have different/additional arguments. I'd suggest that the new gtedirentries(2) syscall should return a flag to indicate that the underlying file system is filling in d_off. Then the libc functions can use d_off if it it available. (They will still need to "work" at least as well as they do now if the file system doesn't support d_off. The old getdirentries(2) syscall will be returning the old/current "struct dirent" which doesn't have the field anyhow.) Another bit of fun is that the argument for seekdir()/telldir() is a long and ends up 32bits for some arches. d_off is 64bits, since that is what some file systems require. Maybe the library code can only use d_off if it is a 64bit arch and the file system is filling it in. (Or maybe the library can keep track of 32<->64bit mappings for the offsets. I haven't looked at the libc functions for a while, so I can't remember what they keep track of.) rick > A proper d_off would still be useful even if UFS's readdir keeps > masking > off the offset so a directory read always starts at the beginning of > a > 512-byte directory block, since this allows more distinct offset > values > than safely using getdirentries()'s *basep. With d_off, one outer > loop > must read at least one directory block to avoid spinning > indefinitely, > while using getdirentries()'s *basep requires reading the whole > getdirentries() buffer. > > Some Linux filesystems go further and provide a unique d_off for each > entry. > > Another idea would be to store the last d_ino instead of dd_loc into > the > struct ddloc. On seekdir(), this would seek to loc_seek as before and > skip entries until that d_ino is found, or to the start of the buffer > if > not found (and possibly return some entries again that should not be > returned, but Samba copes with that). > > -- > Jilles Tjoelker > _______________________________________________ > 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 Sat Apr 25 02:46: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 D1302BF6; Sat, 25 Apr 2015 02:46:00 +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 9723E12CF; Sat, 25 Apr 2015 02:46:00 +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 t3P2jpDq029561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 19:45:55 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553AFFD9.9000405@freebsd.org> Date: Sat, 25 Apr 2015 10:45:45 +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: John Baldwin CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <553A7DB0.8080308@freebsd.org> <553A8D28.7090901@freebsd.org> <4718551.Y2ZnMk6NSM@ralph.baldwin.cx> In-Reply-To: <4718551.Y2ZnMk6NSM@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: Sat, 25 Apr 2015 02:46:01 -0000 On 4/25/15 4:28 AM, John Baldwin wrote: > On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote: >> On 4/25/15 1:30 AM, Julian Elischer wrote: >>> On 4/24/15 10:59 PM, John Baldwin wrote: >>>> On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote: >>>>> On 4/23/15 9:54 PM, John Baldwin wrote: >>>>>> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>>>>>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>>>>>> I'm debugging a problem being seen with samba 3.6. >>>>>>>> >>>>>>>> basically telldir/seekdir/readdir don't seem to work as >>>>>>>> advertised.. >>>>>>> ok so it looks like readdir() (and friends) is totally broken in >>>>>>> the face >>>>>>> of deletes unless you read the entire directory at once or reset >>>>>>> to the >>>>>>> the first file before the deletes, or earlier. >>>>>> I'm not sure that Samba isn't assuming non-portable behavior. >>>>>> For example: >>>>>> >>>>>> >From >>>>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >>>>>> >>>>>> >>>>>> If a file is removed from or added to the directory after the >>>>>> most recent call >>>>>> to opendir() or rewinddir(), whether a subsequent call to >>>>>> readdir() returns an >>>>>> entry for that file is unspecified. >>>>>> >>>>>> While this doesn't speak directly to your case, it does note that >>>>>> you will >>>>>> get inconsistencies if you scan a directory concurrent with add >>>>>> and remove. >>>>>> >>>>>> UFS might kind of work actually since deletes do not compact the >>>>>> backing >>>>>> directory, but I suspect NFS and ZFS would not work. In >>>>>> addition, our >>>>>> current NFS support for seekdir is pretty flaky and can't be >>>>>> fixed without >>>>>> changes to return the seek offset for each directory entry (I >>>>>> believe that >>>>>> the projects/ino64 patches include this since they are breaking >>>>>> the ABI of >>>>>> the relevant structures already). The ABI breakage makes this a >>>>>> very >>>>>> non-trivial task. However, even if you have that per-item >>>>>> cookie, it is >>>>>> likely meaningless in the face of filesystems that use any sort >>>>>> of more >>>>>> advanced structure than an array (such as trees, etc.) to store >>>>>> directory >>>>>> entries. POSIX specifically mentions this in the rationale for >>>>>> seekdir: >>>>>> >>>>>> One of the perceived problems of implementation is that returning >>>>>> to a given point in a directory is quite difficult to describe >>>>>> formally, in spite of its intuitive appeal, when systems that use >>>>>> B-trees, hashing functions, or other similar mechanisms to order >>>>>> their directories are considered. The definition of seekdir() and >>>>>> telldir() does not specify whether, when using these interfaces, >>>>>> a given directory entry will be seen at all, or more than once. >>>>>> >>>>>> In fact, given that quote, I would argue that what Samba is doing is >>>>>> non-portable. This would seem to indicate that a conforming >>>>>> seekdir could >>>>>> just change readdir to immediately return EOF until you call >>>>>> rewinddir. >>>>> how does readdir know that the directory has been changed? fstat? >>>> Undefined. FreeBSD's libc doesn't cache the entire directory >>>> (unless you >>>> are using a union mount), instead it just caches the most recent >>>> call to >>>> getdirentries(). It then serves up entries from that block until >>>> you hit >>>> the end. When you hit the end it reads the next block, etc. When you >>>> call telldir(), the kernel saves the seek offset from the start of the >>>> current block and the offset within that block and returns a cookie to >>>> you. seekdir() looks up the cookie to find the (seek offset, block >>>> offset) >>>> tuple. If the location matches the directory's current location it >>>> doesn't >>>> do anything, otherwise it seeks to the seek offset and reads a new >>>> block via >>>> getdirentries(). There is no check for seeing if a directory is >>>> changed. Instead, you can only be stale by one "block". When you >>>> read >>>> a new block it is relative to the directory's state at that time. >>>> >>>> Rick's suggestion of reusing the block for a seek within a block >>>> would be >>>> fairly easy to implement, I think it would just be: >>>> >>>> Index: head/lib/libc/gen/telldir.c >>>> =================================================================== >>>> --- head/lib/libc/gen/telldir.c (revision 281929) >>>> +++ head/lib/libc/gen/telldir.c (working copy) >>>> @@ -101,8 +101,10 @@ >>>> return; >>>> if (lp->loc_loc == dirp->dd_loc && lp->loc_seek == >>>> dirp->dd_seek) >>>> return; >>>> - (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); >>>> - dirp->dd_seek = lp->loc_seek; >>>> + if (lp->loc_seek != dirp->dd_seek) { >>>> + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, >>>> SEEK_SET); >>>> + dirp->dd_seek = lp->loc_seek; >>>> + } >>> yes I did that yesterday but it still fails when you transition >>> blocks.. (badly). >>> >>> I also tried bigger blocks.. also fails (eventually) >>> >>> I did find a way to make it work... you had to seek back >>> to the first block you deleted on each set.. >>> then work forward from there again.. unfortunately since >>> I'm trying to make a microsoft program not fail (via samba) >>> I have no control over how it does things and seekdir doesn't >>> know what was deleted anyway... (so the fix is fine for the >>> test program but not for real life) >>> >>> I think I can make the BSD one act like the linux one by changing >>> the lseek being done to use the offset (loc) plus the buffer seek >>> address of the target, instead of just going for the buffer base and >>> stepping forward through the entries.. >>> >>> maybe tomorrow. >>> >> The following conditional code makes ours behave the same as the linux >> one. >> it breaks several 'rules' but works where ours is clean but fails.. >> as Rick said.. "maybe that's what we should do too." >> >> >> this is at the end of seekdir() >> >> >> The new code does what linux does.. and shouldn't work.. but does >> // at least in the limited conditions I need it to. >> // We'll probably need to do this at work...: >> >> >> The original code is what we have now, but gets mightily confused >> sometimes. >> // This is clean(er) but fails in specific situations(when >> doing commands >> // from Microft windows, via samba). >> >> >> root@vps1:/tmp # diff -u dir.c.orig dir.c >> --- dir.c.orig 2015-04-24 11:29:36.855317000 -0700 >> +++ dir.c 2015-04-24 11:15:49.058500000 -0700 >> @@ -1105,6 +1105,13 @@ >> dirp->dd_loc = lp->loc_loc; >> return; >> } >> +#ifdef GLIBC_SEEK >> + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek + lp->loc_loc, >> SEEK_SET); >> + dirp->dd_seek = lp->loc_seek + lp->loc_loc; >> + dirp->dd_loc = 0; >> + lp->loc_seek = dirp->dd_seek; >> + lp->loc_loc = 0; >> +#else >> (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); >> dirp->dd_seek = lp->loc_seek; >> dirp->dd_loc = 0; >> @@ -1114,6 +1121,7 @@ >> if (dp == NULL) >> break; >> } >> +#endif >> } > Yes, this isn't at all safe. There's no guarantee whatsoever that > the offset on the directory fd that isn't something returned by > getdirentries has any meaning. the value returned by getdirentries is the original seek for the block, and the offset is not sent obviosly.. but we could do somethign where getdirentries 'remembers' all teh offsets it sent for the last set of entries, of we could make it return a a seekable cookie for every entry... > In particular, the size of the > directory entry in a random filesystem might be a different size > than the structure returned by getdirentries (since it converts > things into a FS-independent format). yes I understand all that.. :-) > > This might work for UFS by accident, but this is probably why ZFS > doesn't work. actually ZFS seems to work too which stunned me.. > However, this might be properly fixed by the thing that ino64 is > doing where each directory entry returned by getdirentries gives > you a seek offset that you _can_ directly seek to (as opposed to > seeking to the start of the block and then walking forward N > entries until you get an inter-block entry that is the same). yeah that might be nice. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 02:50: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 546C5D2A; Sat, 25 Apr 2015 02:50:52 +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 260DC12F3; Sat, 25 Apr 2015 02:50:52 +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 t3P2okNC029591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 19:50:49 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553B0100.4070307@freebsd.org> Date: Sat, 25 Apr 2015 10:50:40 +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 , John Baldwin CC: freebsd-current@freebsd.org Subject: Re: readdir/telldir/seekdir problem (i think) References: <55386505.70708@freebsd.org> <553A7DB0.8080308@freebsd.org> <553A8D28.7090901@freebsd.org> <4718551.Y2ZnMk6NSM@ralph.baldwin.cx> <20150424215249.GA96554@stack.nl> In-Reply-To: <20150424215249.GA96554@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: Sat, 25 Apr 2015 02:50:52 -0000 On 4/25/15 5:52 AM, Jilles Tjoelker wrote: > On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: >> Yes, this isn't at all safe. There's no guarantee whatsoever that >> the offset on the directory fd that isn't something returned by >> getdirentries has any meaning. In particular, the size of the >> directory entry in a random filesystem might be a different size >> than the structure returned by getdirentries (since it converts >> things into a FS-independent format). >> This might work for UFS by accident, but this is probably why ZFS >> doesn't work. >> However, this might be properly fixed by the thing that ino64 is >> doing where each directory entry returned by getdirentries gives >> you a seek offset that you _can_ directly seek to (as opposed to >> seeking to the start of the block and then walking forward N >> entries until you get an inter-block entry that is the same). > The ino64 branch only reserves space for d_off and does not use it in > any way. This is appropriate since actually using d_off is a major > feature addition. > > A proper d_off would still be useful even if UFS's readdir keeps masking > off the offset so a directory read always starts at the beginning of a > 512-byte directory block, since this allows more distinct offset values > than safely using getdirentries()'s *basep. With d_off, one outer loop > must read at least one directory block to avoid spinning indefinitely, > while using getdirentries()'s *basep requires reading the whole > getdirentries() buffer. > > Some Linux filesystems go further and provide a unique d_off for each > entry. > > Another idea would be to store the last d_ino instead of dd_loc into the > struct ddloc. On seekdir(), this would seek to loc_seek as before and > skip entries until that d_ino is found, or to the start of the buffer if > not found (and possibly return some entries again that should not be > returned, but Samba copes with that). yes.. though maybe a hash of hte inode number and the name may be a better thing to search on.. I need to check on your statement about samba to see if its true for 3.6.. > From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 02:54:50 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 36117F50; Sat, 25 Apr 2015 02:54:50 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 235BF13AE; Sat, 25 Apr 2015 02:54:49 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id A3374341F841; Fri, 24 Apr 2015 19:54:49 -0700 (PDT) Message-ID: <553B01FD.5010301@freebsd.org> Date: Fri, 24 Apr 2015 19:54:53 -0700 From: Alfred Perlstein Organization: FreeBSD 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: Craig Rodrigues , freebsd-git@freebsd.org CC: freebsd-current Current , ports Subject: Re: Merging GitHub Pull Requests into Subversion using git-svn References: 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: Sat, 25 Apr 2015 02:54:50 -0000 Very cool. Glad it worked and thanks for the shout-out. Hoping this can be automated some day. On 4/22/15 4:12 PM, Craig Rodrigues wrote: > Hi, > > Alfred Perlstein recently wrote this document for how to use > git-svn for interacting between the FreeBSD Subversion repo, > and the GitHub mirror of this repo: > > https://wiki.freebsd.org/GitWorkflow/GitSvn > > By following the steps in that article, step-by-step, > I was able to: > > (1) take these three GitHub pull requests from Steve Kiernan: > > https://github.com/freebsd/freebsd/pull/26 > https://github.com/freebsd/freebsd/pull/27 > https://github.com/freebsd/freebsd/pull/28 > > (2) Pull them into my own git checkout of the FreeBSD src tree > > (3) Modify the commit message slightly > > (4) Use "git svn dcommit" to push these changes directly from my Git tree > back to the > FreeBSD svn repo: > > https://svnweb.freebsd.org/changeset/base/281844 > https://svnweb.freebsd.org/changeset/base/281845 > https://svnweb.freebsd.org/changeset/base/281855 > > While there were multiple steps involved, I just followed the steps in the > wiki article, and it *just worked*! Thanks for writing this article, > Alfred! > > While not as smooth as clicking a merge button in GitHub, > this is a valid way to accept patches submitted via GitHub pull requests, > and integrate them in our FreeBSD Subversion repo. > > -- > Craig > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 03:00: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 DE2C4193; Sat, 25 Apr 2015 03:00:01 +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 BC3CA13D9; Sat, 25 Apr 2015 03:00: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 t3P2xti7029642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2015 19:59:58 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <553B0326.1090306@freebsd.org> Date: Sat, 25 Apr 2015 10:59:50 +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 CC: freebsd-current@freebsd.org, John Baldwin Subject: Re: readdir/telldir/seekdir problem (i think) References: <326462676.25571625.1429925971889.JavaMail.root@uoguelph.ca> In-Reply-To: <326462676.25571625.1429925971889.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: Sat, 25 Apr 2015 03:00:02 -0000 On 4/25/15 9:39 AM, Rick Macklem wrote: > Jilles Tjoelker wrote: >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: >>> Yes, this isn't at all safe. There's no guarantee whatsoever that >>> the offset on the directory fd that isn't something returned by >>> getdirentries has any meaning. In particular, the size of the >>> directory entry in a random filesystem might be a different size >>> than the structure returned by getdirentries (since it converts >>> things into a FS-independent format). >>> This might work for UFS by accident, but this is probably why ZFS >>> doesn't work. >>> However, this might be properly fixed by the thing that ino64 is >>> doing where each directory entry returned by getdirentries gives >>> you a seek offset that you _can_ directly seek to (as opposed to >>> seeking to the start of the block and then walking forward N >>> entries until you get an inter-block entry that is the same). >> The ino64 branch only reserves space for d_off and does not use it in >> any way. This is appropriate since actually using d_off is a major >> feature addition. >> > Well, at some point ino64 will need to define a new getdirentries(2) > syscall and I believe this new syscall can have different/additional > arguments. yes, posix only specifies 2 mandatory fields (d_ino and d_name) and everything else is implementation dependent. > I'd suggest that the new gtedirentries(2) syscall should return a > flag to indicate that the underlying file system is filling in d_off. > Then the libc functions can use d_off if it it available. > (They will still need to "work" at least as well as they do now if > the file system doesn't support d_off. The old getdirentries(2) syscall > will be returning the old/current "struct dirent" which doesn't have > the field anyhow.) > > Another bit of fun is that the argument for seekdir()/telldir() is a > long and ends up 32bits for some arches. d_off is 64bits, since that > is what some file systems require. what does linux use? ------ In glibc up to version 2.1.1, the return type of telldir() was off_t. POSIX.1-2001 specifies long, and this is the type used since glibc 2.1.2. also from the linux man page: this is interesting.. -------- In early filesystems, the value returned by telldir() was a simple file offset within a directory. Modern filesystems use tree or hash structures, rather than flat tables, to represent directories. On such filesystems, the value returned by telldir() (and used internally by readdir(3)) is a "cookie" that is used by the implementation to derive a position within a directory. Application programs should treat this strictly as an opaque value, making no assumptions about its contents. ------ but glibc uses the contents in a nonopaque (and possibly wrong) way itself in seekdir. . (not following their own advice.) > Maybe the library code can only use d_off if it is a 64bit arch and > the file system is filling it in. (Or maybe the library can keep track > of 32<->64bit mappings for the offsets. I haven't looked at the libc > functions for a while, so I can't remember what they keep track of.) one supposes a 32 bit system would not have such large file systems on it.. (maybe?) > > rick > >> A proper d_off would still be useful even if UFS's readdir keeps >> masking >> off the offset so a directory read always starts at the beginning of >> a >> 512-byte directory block, since this allows more distinct offset >> values >> than safely using getdirentries()'s *basep. With d_off, one outer >> loop >> must read at least one directory block to avoid spinning >> indefinitely, >> while using getdirentries()'s *basep requires reading the whole >> getdirentries() buffer. >> >> Some Linux filesystems go further and provide a unique d_off for each >> entry. >> >> Another idea would be to store the last d_ino instead of dd_loc into >> the >> struct ddloc. On seekdir(), this would seek to loc_seek as before and >> skip entries until that d_ino is found, or to the start of the buffer >> if >> not found (and possibly return some entries again that should not be >> returned, but Samba copes with that). >> >> -- >> Jilles Tjoelker >> _______________________________________________ >> 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 Sat Apr 25 05:59:06 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 7F8BD3C6; Sat, 25 Apr 2015 05:59:06 +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 41987166D; Sat, 25 Apr 2015 05:59:05 +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 F3D7C1FE023; Sat, 25 Apr 2015 07:59:02 +0200 (CEST) Message-ID: <553B2D56.1000405@selasky.org> Date: Sat, 25 Apr 2015 07:59:50 +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: Ian Lepore , Svatopluk Kraus CC: freebsd-current@freebsd.org Subject: Re: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET References: <1429882188.1157.2.camel@freebsd.org> In-Reply-To: <1429882188.1157.2.camel@freebsd.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: Sat, 25 Apr 2015 05:59:06 -0000 On 04/24/15 15:29, Ian Lepore wrote: > On Fri, 2015-04-24 at 13:34 +0200, Svatopluk Kraus wrote: >> The add_bounce_page() can be called from _bus_dmamap_load_phys(). >> Client virtual address is zero (not valid) in that case. So, client >> physical address must be used to get an offset when >> BUS_DMA_KEEP_PG_OFFSET flag is set. Note that client physical address >> is always valid. >> >> Svatopluk Kraus > > The only user of BUS_DMA_KEEP_PG_OFFSET in the system is USB. If the > flag didn't exist, we could do bouncing with a whole lot more > efficiency, at least in the ARM world. I wonder if it would be possible > to just eliminate the flag (and of course, USB's need for it, which I > fully admit I don't understand even a little bit). > Hi, USB (EHCI/UHCI/OHCI) needs this flag when computing scatter/gather lists. Please ensure it works like expected. The good news is XHCI needs it less than the EHCI. Ian: The patch looks good - will you commit it? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 06:03:42 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 62879502; Sat, 25 Apr 2015 06:03:42 +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 267881720; Sat, 25 Apr 2015 06:03:42 +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 357E41FE023; Sat, 25 Apr 2015 08:03:40 +0200 (CEST) Message-ID: <553B2E6B.20406@selasky.org> Date: Sat, 25 Apr 2015 08:04:27 +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: Ian Lepore , Svatopluk Kraus CC: freebsd-current@freebsd.org Subject: Re: [patch] fix add_bounce_page() for BUS_DMA_KEEP_PG_OFFSET References: <1429882188.1157.2.camel@freebsd.org> <553B2D56.1000405@selasky.org> In-Reply-To: <553B2D56.1000405@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: Sat, 25 Apr 2015 06:03:42 -0000 On 04/25/15 07:59, Hans Petter Selasky wrote: > On 04/24/15 15:29, Ian Lepore wrote: >> On Fri, 2015-04-24 at 13:34 +0200, Svatopluk Kraus wrote: >>> The add_bounce_page() can be called from _bus_dmamap_load_phys(). >>> Client virtual address is zero (not valid) in that case. So, client >>> physical address must be used to get an offset when >>> BUS_DMA_KEEP_PG_OFFSET flag is set. Note that client physical address >>> is always valid. >>> >>> Svatopluk Kraus >> >> The only user of BUS_DMA_KEEP_PG_OFFSET in the system is USB. If the >> flag didn't exist, we could do bouncing with a whole lot more >> efficiency, at least in the ARM world. I wonder if it would be possible >> to just eliminate the flag (and of course, USB's need for it, which I >> fully admit I don't understand even a little bit). >> > > Hi, > > USB (EHCI/UHCI/OHCI) needs this flag when computing scatter/gather > lists. Please ensure it works like expected. The good news is XHCI needs > it less than the EHCI. > > Ian: The patch looks good - will you commit it? > The reason is that the EHCI/UHCI/OHCI doesn't have separate length fields for each data chunk and somtimes use the "0x1000 - (addr & 0xFFF)" formula to compute how many bytes are left of a transfer when a transfer wraps around 0x1000. Thank you for you understanding this is not a USB problem in general. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 07:30:19 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 E216E543; Sat, 25 Apr 2015 07:30:19 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA2091E4A; Sat, 25 Apr 2015 07:30:18 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.15.1) with ESMTPSA id t3P7UBPf091819 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Apr 2015 07:30:16 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Merging GitHub Pull Requests into Subversion using git-svn From: David Chisnall In-Reply-To: Date: Sat, 25 Apr 2015 08:30:06 +0100 Cc: freebsd-git@freebsd.org, freebsd-current Current , ports Content-Transfer-Encoding: quoted-printable Message-Id: <29BE23C6-EBFE-40FB-91FC-C0E7CBFCFD45@FreeBSD.org> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.2098) 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, 25 Apr 2015 07:30:20 -0000 On 23 Apr 2015, at 00:12, Craig Rodrigues wrote: >=20 > While not as smooth as clicking a merge button in GitHub, > this is a valid way to accept patches submitted via GitHub pull = requests, > and integrate them in our FreeBSD Subversion repo. The merge button on GitHub does the wrong thing anyway (merges without = fast-forward, so you end up with a tangled history), so (after the = initial setup) the steps that I use for merging pull requests from = GitHub projects are very similar (locally pull the branch with = fast-fordward, test, push). =20 David= From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 10:53:48 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 E615D2DF; Sat, 25 Apr 2015 10:53:48 +0000 (UTC) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 A4E7111CA; Sat, 25 Apr 2015 10:53:48 +0000 (UTC) Received: from john by potato.growveg.org with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1YlxiH-000LQI-LX; Sat, 25 Apr 2015 11:53:33 +0100 Date: Sat, 25 Apr 2015 11:53:33 +0100 From: John To: freebsd-geom@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: geli partition accepts passphrase but won't mount [SOLVED] Message-ID: <20150425105333.GA82283@potato.growveg.org> Mail-Followup-To: freebsd-geom@freebsd.org, freebsd-current@freebsd.org References: <20150424225249.GA53863@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150424225249.GA53863@potato.growveg.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: John X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: john@potato.growveg.org X-SA-Exim-Scanned: No (on potato.growveg.org); SAEximRunCond expanded to false 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, 25 Apr 2015 10:53:49 -0000 On Fri, Apr 24, 2015 at 11:52:49PM +0100, John wrote: > Hello, > > I'm running 11.0-CURRENT #0 r281867. I've followed the instructions > given at > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html > section 18.12.2. > > I was able to create the encrypted slice and mount it. I transferred > some documents to that drive for safekeeping and unmounted it. Updated > the machine and added these lines to the kernel: > > options GEOM_ELI > device crypto > > but before I could rebuild the system later, it (some hours after this) > went into a hard lock. Powering off then on again rebooted the system > and from there I was able to run buildworld and friends. Rebooted again, > now trying to mount the disk: > > root@:~ # geli attach -k /root/da0p1.key /dev/da0p1 > Enter passphrase: > root@:~ # > > root@:~ geli status > Name Status Components > da0p1.eli ACTIVE da0p1 > > Trying to mount it, this happens: > > root@:~ # mount /dev/da0p1.eli /mnt > mount: /dev/da0p1.eli: Invalid argument > > I think this needs fsck but I get > > root@:~ # fsck -p -t ffs /dev/da0p1.eli > Cannot find file system superblock > > What can I do? In the grand tradition of replying to my own question, thought I'd post what fixed this. For some reason, I had both a /dev/da0p1.key and a /dev/da0.key. Both were the same. Firstly tried restoring the metadata for /dev/da0p1.eli. Was able to attach but failed mount. Then had the idea of restoring from /var/backups/da0.eli. Then tried to attach da0.key but this time it gave a better error message that said unable to mount r/w because the filesystem was dirty. So I ran fsck_ffs -y /dev/da0.eli and from there (after fixing lots of incorrect block count errors) I was able to mount da0.eli and read/write to it. da0p1.eli I think was made because the initial format of the disk gave da0p1. But looking back at the time before this that the disk was successfully mounted (in the system log emails) the disk appeared as /dev/da0.eli. *whew!* -- John From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 12:16:24 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 30A4E9D2; Sat, 25 Apr 2015 12:16:24 +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 B8CE118DE; Sat, 25 Apr 2015 12:16:23 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+AwBrhDtV/95baINcg19cBYMVwzoJgUgKhTZOAoFwFAEBAQEBAQGBCoQhAQEEAQEBIAQnIAsbGAICDRkCKQEJJgYIBwQBHASICg2yXJQ0AQEBAQYBAQEBAQEBG4EhiheEMwEBHDQHgmiBRQWVVoI/gUmDUj2Fe44HI4FlIR2BbSIxB4EEOYEAAQEB X-IronPort-AV: E=Sophos;i="5.11,646,1422939600"; d="scan'208";a="206101070" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Apr 2015 08:16:22 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C205DB3F34; Sat, 25 Apr 2015 08:16:21 -0400 (EDT) Date: Sat, 25 Apr 2015 08:16:21 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-current@freebsd.org, John Baldwin , Jilles Tjoelker Message-ID: <1910067192.25661527.1429964181784.JavaMail.root@uoguelph.ca> In-Reply-To: <553B0326.1090306@freebsd.org> Subject: Re: readdir/telldir/seekdir problem (i think) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] 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: Sat, 25 Apr 2015 12:16:24 -0000 Julian Elischer wrote: > On 4/25/15 9:39 AM, Rick Macklem wrote: > > Jilles Tjoelker wrote: > >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > >>> Yes, this isn't at all safe. There's no guarantee whatsoever > >>> that > >>> the offset on the directory fd that isn't something returned by > >>> getdirentries has any meaning. In particular, the size of the > >>> directory entry in a random filesystem might be a different size > >>> than the structure returned by getdirentries (since it converts > >>> things into a FS-independent format). > >>> This might work for UFS by accident, but this is probably why ZFS > >>> doesn't work. > >>> However, this might be properly fixed by the thing that ino64 is > >>> doing where each directory entry returned by getdirentries gives > >>> you a seek offset that you _can_ directly seek to (as opposed to > >>> seeking to the start of the block and then walking forward N > >>> entries until you get an inter-block entry that is the same). > >> The ino64 branch only reserves space for d_off and does not use it > >> in > >> any way. This is appropriate since actually using d_off is a major > >> feature addition. > >> > > Well, at some point ino64 will need to define a new > > getdirentries(2) > > syscall and I believe this new syscall can have > > different/additional > > arguments. > yes, posix only specifies 2 mandatory fields (d_ino and d_name) and > everything else is implementation dependent. > > I'd suggest that the new gtedirentries(2) syscall should return a > > flag to indicate that the underlying file system is filling in > > d_off. > > Then the libc functions can use d_off if it it available. > > (They will still need to "work" at least as well as they do now if > > the file system doesn't support d_off. The old getdirentries(2) > > syscall > > will be returning the old/current "struct dirent" which doesn't > > have > > the field anyhow.) > > > > Another bit of fun is that the argument for seekdir()/telldir() is > > a > > long and ends up 32bits for some arches. d_off is 64bits, since > > that > > is what some file systems require. > what does linux use? > ------ > In glibc up to version 2.1.1, the return type of telldir() was > off_t. > POSIX.1-2001 specifies long, and this is the type used since > glibc > 2.1.2. > > also from the linux man page: this is interesting.. > > -------- > In early filesystems, the value returned by telldir() was a > simple > file offset within a directory. Modern filesystems use tree > or hash > structures, rather than flat tables, to represent > directories. On > such filesystems, the value returned by telldir() (and used > internally by readdir(3)) is a "cookie" that is used by the > implementation to derive a position within a directory. > Application > programs should treat this strictly as an opaque value, > making no > assumptions about its contents. > ------ > but glibc uses the contents in a nonopaque (and possibly wrong) way > itself in seekdir. . > (not following their own advice.) > > > > Maybe the library code can only use d_off if it is a 64bit arch and > > the file system is filling it in. (Or maybe the library can keep > > track > > of 32<->64bit mappings for the offsets. I haven't looked at the > > libc > > functions for a while, so I can't remember what they keep track > > of.) > > one supposes a 32 bit system would not have such large file systems > on > it.. > (maybe?) For NFS, the cookie is always an opaque 64bits. These cookies are cached in the kernel by the client, with one for each "logical UFS-like directory block generated for getdirentries(2)". As such, the NFS case does a 64bit->32bit mapping. (Because of endianness etc, there is no guarantee that most of these cookies are 0 for the high order 32bits.) I need to look at the library code (both glibc and ours) before I understand this better and can say more. Have fun with it, rick ps: The ino64 stuff will never be MFC'd, so it would be nice to "improve" what the libc functions do without use of d_off. > > > > rick > > > >> A proper d_off would still be useful even if UFS's readdir keeps > >> masking > >> off the offset so a directory read always starts at the beginning > >> of > >> a > >> 512-byte directory block, since this allows more distinct offset > >> values > >> than safely using getdirentries()'s *basep. With d_off, one outer > >> loop > >> must read at least one directory block to avoid spinning > >> indefinitely, > >> while using getdirentries()'s *basep requires reading the whole > >> getdirentries() buffer. > >> > >> Some Linux filesystems go further and provide a unique d_off for > >> each > >> entry. > >> > >> Another idea would be to store the last d_ino instead of dd_loc > >> into > >> the > >> struct ddloc. On seekdir(), this would seek to loc_seek as before > >> and > >> skip entries until that d_ino is found, or to the start of the > >> buffer > >> if > >> not found (and possibly return some entries again that should not > >> be > >> returned, but Samba copes with that). > >> > >> -- > >> Jilles Tjoelker > >> _______________________________________________ > >> 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 Sat Apr 25 12: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 266CBBA8; Sat, 25 Apr 2015 12:33:47 +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 7C0251A97; Sat, 25 Apr 2015 12:33:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+AwDmiDtV/95baINcg19cBYMVwzoJgUgKhTZOAoFwFAEBAQEBAQGBCoQhAQEEAQEBIAQnIAsbGAICDRkCKQEJJgYIBwQBHASICg2yXpQyAQEBAQYBAQEBAQEBG4EhiheEMwEBHDQHgmiBRQWVVoQIg1I9hXuKN4NQI4IGHYFtIjEHgQQ5gQABAQE X-IronPort-AV: E=Sophos;i="5.11,646,1422939600"; d="scan'208";a="207913073" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Apr 2015 08:33:42 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B790DB3F0C; Sat, 25 Apr 2015 08:33:42 -0400 (EDT) Date: Sat, 25 Apr 2015 08:33:42 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-current@freebsd.org, John Baldwin , Jilles Tjoelker Message-ID: <1781764425.25665403.1429965222745.JavaMail.root@uoguelph.ca> In-Reply-To: <553B0326.1090306@freebsd.org> Subject: Re: readdir/telldir/seekdir problem (i think) 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: Sat, 25 Apr 2015 12:33:47 -0000 Julian Elischer wrote: > On 4/25/15 9:39 AM, Rick Macklem wrote: > > Jilles Tjoelker wrote: > >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > >>> Yes, this isn't at all safe. There's no guarantee whatsoever > >>> that > >>> the offset on the directory fd that isn't something returned by > >>> getdirentries has any meaning. In particular, the size of the > >>> directory entry in a random filesystem might be a different size > >>> than the structure returned by getdirentries (since it converts > >>> things into a FS-independent format). > >>> This might work for UFS by accident, but this is probably why ZFS > >>> doesn't work. > >>> However, this might be properly fixed by the thing that ino64 is > >>> doing where each directory entry returned by getdirentries gives > >>> you a seek offset that you _can_ directly seek to (as opposed to > >>> seeking to the start of the block and then walking forward N > >>> entries until you get an inter-block entry that is the same). > >> The ino64 branch only reserves space for d_off and does not use it > >> in > >> any way. This is appropriate since actually using d_off is a major > >> feature addition. > >> > > Well, at some point ino64 will need to define a new > > getdirentries(2) > > syscall and I believe this new syscall can have > > different/additional > > arguments. > yes, posix only specifies 2 mandatory fields (d_ino and d_name) and > everything else is implementation dependent. > > I'd suggest that the new gtedirentries(2) syscall should return a > > flag to indicate that the underlying file system is filling in > > d_off. > > Then the libc functions can use d_off if it it available. > > (They will still need to "work" at least as well as they do now if > > the file system doesn't support d_off. The old getdirentries(2) > > syscall > > will be returning the old/current "struct dirent" which doesn't > > have > > the field anyhow.) > > > > Another bit of fun is that the argument for seekdir()/telldir() is > > a > > long and ends up 32bits for some arches. d_off is 64bits, since > > that > > is what some file systems require. > what does linux use? > ------ > In glibc up to version 2.1.1, the return type of telldir() was > off_t. > POSIX.1-2001 specifies long, and this is the type used since > glibc > 2.1.2. > > also from the linux man page: this is interesting.. > > -------- > In early filesystems, the value returned by telldir() was a > simple > file offset within a directory. Modern filesystems use tree > or hash > structures, rather than flat tables, to represent > directories. On > such filesystems, the value returned by telldir() (and used > internally by readdir(3)) is a "cookie" that is used by the > implementation to derive a position within a directory. > Application > programs should treat this strictly as an opaque value, > making no > assumptions about its contents. > ------ > but glibc uses the contents in a nonopaque (and possibly wrong) way > itself in seekdir. . > (not following their own advice.) > I believe that most of the FreeBSD file systems except UFS and ZFS just copy the fields of their internal directory structure to fields in "struct dirent", filling blocks sequentially. (Actually, I only took a quick look, but ZFS might also be this way.) As such, the "offsets" for FreeBSD are byte offsets into these "logical directory" blocks. The problem is (as already discussed) that there is no way to predict how these will change for a given file system when entries are removed/added. (I think the only way to "know" what the modified "logical directory" looks like is to read it again from the beginning, so that all the directory entries go through the conversion to logical again.) UFS and the NFS client ensure that no "struct dirent" crosses a 512byte block boundary. I don't think the other file systems do this. I mention this, since the libc functions can't assume the UFS behaviour for this. (At one time, UFS just "consumed" removed entries into the preceding "struct direct" or set it invalid, if it was the first entry in a 512byte block. This implied that the byte offsets (logical == physical) didn't change for subsequent entries upon a removal. It sounds like UFS is no longer doing this, from one of your posts?) I am curious to see what glibc does, since I had assumed it just read the entire directory at opendir/first-readdir. rick ps: This is what I recall from fooling with "struct dirent" a few months ago and I'm getting old, so it may all be wrong;-) > > > Maybe the library code can only use d_off if it is a 64bit arch and > > the file system is filling it in. (Or maybe the library can keep > > track > > of 32<->64bit mappings for the offsets. I haven't looked at the > > libc > > functions for a while, so I can't remember what they keep track > > of.) > > one supposes a 32 bit system would not have such large file systems > on > it.. > (maybe?) > > > > rick > > > >> A proper d_off would still be useful even if UFS's readdir keeps > >> masking > >> off the offset so a directory read always starts at the beginning > >> of > >> a > >> 512-byte directory block, since this allows more distinct offset > >> values > >> than safely using getdirentries()'s *basep. With d_off, one outer > >> loop > >> must read at least one directory block to avoid spinning > >> indefinitely, > >> while using getdirentries()'s *basep requires reading the whole > >> getdirentries() buffer. > >> > >> Some Linux filesystems go further and provide a unique d_off for > >> each > >> entry. > >> > >> Another idea would be to store the last d_ino instead of dd_loc > >> into > >> the > >> struct ddloc. On seekdir(), this would seek to loc_seek as before > >> and > >> skip entries until that d_ino is found, or to the start of the > >> buffer > >> if > >> not found (and possibly return some entries again that should not > >> be > >> returned, but Samba copes with that). > >> > >> -- > >> Jilles Tjoelker > >> _______________________________________________ > >> 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 Sat Apr 25 12:54:25 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 5ABB5FC9; Sat, 25 Apr 2015 12:54:25 +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 F3CD31CAB; Sat, 25 Apr 2015 12:54:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwAHjjtV/95baINcFoNJXAWDFcM6CYFICoU2TgKBcBQBAQEBAQEBgQqEIAEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASIAggNsmOUMgEBAQEGAQEBAQEBARuBIYoXhDMBARw0B4JogUUFlVaECINSPYV7jgcjggccgW0iMQEGgQQ5gQABAQE X-IronPort-AV: E=Sophos;i="5.11,646,1422939600"; d="scan'208";a="206104917" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Apr 2015 08:54:23 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C9F8EB3F6E; Sat, 25 Apr 2015 08:54:23 -0400 (EDT) Date: Sat, 25 Apr 2015 08:54:23 -0400 (EDT) From: Rick Macklem To: Jilles Tjoelker Cc: Julian Elischer , freebsd-current@freebsd.org, John Baldwin Message-ID: <768602615.25669083.1429966463806.JavaMail.root@uoguelph.ca> In-Reply-To: <20150424215249.GA96554@stack.nl> Subject: Re: readdir/telldir/seekdir problem (i think) 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: Sat, 25 Apr 2015 12:54:25 -0000 Jilles Toelker wrote: > On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > > Yes, this isn't at all safe. There's no guarantee whatsoever that > > the offset on the directory fd that isn't something returned by > > getdirentries has any meaning. In particular, the size of the > > directory entry in a random filesystem might be a different size > > than the structure returned by getdirentries (since it converts > > things into a FS-independent format). > > > This might work for UFS by accident, but this is probably why ZFS > > doesn't work. > > > However, this might be properly fixed by the thing that ino64 is > > doing where each directory entry returned by getdirentries gives > > you a seek offset that you _can_ directly seek to (as opposed to > > seeking to the start of the block and then walking forward N > > entries until you get an inter-block entry that is the same). > > The ino64 branch only reserves space for d_off and does not use it in > any way. This is appropriate since actually using d_off is a major > feature addition. > Just fyi, I did a patch: http://people.freebsd.org/~rmacklem/64bitfileno.patch which does fill this field in for the various file systems and copies the new "struct dirent" to "struct dirent32", so it works with an unchanged userland. Since the ino64 folks felt this should come after the ino64 change, I didn't pursue committing it. To commit it to head, it would have to be modified slightly, so that the new structure is called "struct dirent64", so it doesn't screw up userland builds using "struct dirent", but I think that is the only change required for it to go into head/current if people felt that was appropriate. (Oh, and it called d_off "d_cookie", although I have no strong preference w.r.t. what it is called.) If you look at it, you'll see most of the changes are for NFS, but the rest were pretty trivial. rick > A proper d_off would still be useful even if UFS's readdir keeps > masking > off the offset so a directory read always starts at the beginning of > a > 512-byte directory block, since this allows more distinct offset > values > than safely using getdirentries()'s *basep. With d_off, one outer > loop > must read at least one directory block to avoid spinning > indefinitely, > while using getdirentries()'s *basep requires reading the whole > getdirentries() buffer. > > Some Linux filesystems go further and provide a unique d_off for each > entry. > > Another idea would be to store the last d_ino instead of dd_loc into > the > struct ddloc. On seekdir(), this would seek to loc_seek as before and > skip entries until that d_ino is found, or to the start of the buffer > if > not found (and possibly return some entries again that should not be > returned, but Samba copes with that). > > -- > Jilles Tjoelker > _______________________________________________ > 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 Sat Apr 25 13:04:35 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 59F351DA; Sat, 25 Apr 2015 13:04:35 +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 A9AE71D93; Sat, 25 Apr 2015 13:04:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwBTkDtV/95baINcg19cBYMVwzoJgUgMhTROAoFwFAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCxsYAgINGQIpAQkmBggHBAEYBASIAggNsmaUMgEBAQEBBQEBAQEBAQEbgSGJFYEChCwHAQEcATMHgmiBRQWFLIl2hjSCP4FJg1I9hXtgiVeDUCOBZSIcgW0iMQEGewkXIoEAAQEB X-IronPort-AV: E=Sophos;i="5.11,646,1422939600"; d="scan'208";a="206106126" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Apr 2015 09:04:32 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C3AF3B3F82; Sat, 25 Apr 2015 09:04:32 -0400 (EDT) Date: Sat, 25 Apr 2015 09:04:32 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-current@freebsd.org, John Baldwin Message-ID: <1934232494.25671027.1429967072794.JavaMail.root@uoguelph.ca> In-Reply-To: <553AFFD9.9000405@freebsd.org> Subject: Re: readdir/telldir/seekdir problem (i think) 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: Sat, 25 Apr 2015 13:04:35 -0000 Julian Elischer wrote: > On 4/25/15 4:28 AM, John Baldwin wrote: > > On Saturday, April 25, 2015 02:36:24 AM Julian Elischer wrote: > >> On 4/25/15 1:30 AM, Julian Elischer wrote: > >>> On 4/24/15 10:59 PM, John Baldwin wrote: > >>>> On Friday, April 24, 2015 01:02:39 PM Julian Elischer wrote: > >>>>> On 4/23/15 9:54 PM, John Baldwin wrote: > >>>>>> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: > >>>>>>> On 4/23/15 11:20 AM, Julian Elischer wrote: > >>>>>>>> I'm debugging a problem being seen with samba 3.6. > >>>>>>>> > >>>>>>>> basically telldir/seekdir/readdir don't seem to work as > >>>>>>>> advertised.. > >>>>>>> ok so it looks like readdir() (and friends) is totally broken > >>>>>>> in > >>>>>>> the face > >>>>>>> of deletes unless you read the entire directory at once or > >>>>>>> reset > >>>>>>> to the > >>>>>>> the first file before the deletes, or earlier. > >>>>>> I'm not sure that Samba isn't assuming non-portable behavior. > >>>>>> For example: > >>>>>> > >>>>>> >From > >>>>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html > >>>>>> > >>>>>> > >>>>>> If a file is removed from or added to the directory after the > >>>>>> most recent call > >>>>>> to opendir() or rewinddir(), whether a subsequent call to > >>>>>> readdir() returns an > >>>>>> entry for that file is unspecified. > >>>>>> > >>>>>> While this doesn't speak directly to your case, it does note > >>>>>> that > >>>>>> you will > >>>>>> get inconsistencies if you scan a directory concurrent with > >>>>>> add > >>>>>> and remove. > >>>>>> > >>>>>> UFS might kind of work actually since deletes do not compact > >>>>>> the > >>>>>> backing > >>>>>> directory, but I suspect NFS and ZFS would not work. In > >>>>>> addition, our > >>>>>> current NFS support for seekdir is pretty flaky and can't be > >>>>>> fixed without > >>>>>> changes to return the seek offset for each directory entry (I > >>>>>> believe that > >>>>>> the projects/ino64 patches include this since they are > >>>>>> breaking > >>>>>> the ABI of > >>>>>> the relevant structures already). The ABI breakage makes this > >>>>>> a > >>>>>> very > >>>>>> non-trivial task. However, even if you have that per-item > >>>>>> cookie, it is > >>>>>> likely meaningless in the face of filesystems that use any > >>>>>> sort > >>>>>> of more > >>>>>> advanced structure than an array (such as trees, etc.) to > >>>>>> store > >>>>>> directory > >>>>>> entries. POSIX specifically mentions this in the rationale > >>>>>> for > >>>>>> seekdir: > >>>>>> > >>>>>> One of the perceived problems of implementation is that > >>>>>> returning > >>>>>> to a given point in a directory is quite difficult to describe > >>>>>> formally, in spite of its intuitive appeal, when systems that > >>>>>> use > >>>>>> B-trees, hashing functions, or other similar mechanisms to > >>>>>> order > >>>>>> their directories are considered. The definition of seekdir() > >>>>>> and > >>>>>> telldir() does not specify whether, when using these > >>>>>> interfaces, > >>>>>> a given directory entry will be seen at all, or more than > >>>>>> once. > >>>>>> > >>>>>> In fact, given that quote, I would argue that what Samba is > >>>>>> doing is > >>>>>> non-portable. This would seem to indicate that a conforming > >>>>>> seekdir could > >>>>>> just change readdir to immediately return EOF until you call > >>>>>> rewinddir. > >>>>> how does readdir know that the directory has been changed? > >>>>> fstat? > >>>> Undefined. FreeBSD's libc doesn't cache the entire directory > >>>> (unless you > >>>> are using a union mount), instead it just caches the most recent > >>>> call to > >>>> getdirentries(). It then serves up entries from that block > >>>> until > >>>> you hit > >>>> the end. When you hit the end it reads the next block, etc. > >>>> When you > >>>> call telldir(), the kernel saves the seek offset from the start > >>>> of the > >>>> current block and the offset within that block and returns a > >>>> cookie to > >>>> you. seekdir() looks up the cookie to find the (seek offset, > >>>> block > >>>> offset) > >>>> tuple. If the location matches the directory's current location > >>>> it > >>>> doesn't > >>>> do anything, otherwise it seeks to the seek offset and reads a > >>>> new > >>>> block via > >>>> getdirentries(). There is no check for seeing if a directory is > >>>> changed. Instead, you can only be stale by one "block". When > >>>> you > >>>> read > >>>> a new block it is relative to the directory's state at that > >>>> time. > >>>> > >>>> Rick's suggestion of reusing the block for a seek within a block > >>>> would be > >>>> fairly easy to implement, I think it would just be: > >>>> > >>>> Index: head/lib/libc/gen/telldir.c > >>>> =================================================================== > >>>> --- head/lib/libc/gen/telldir.c (revision 281929) > >>>> +++ head/lib/libc/gen/telldir.c (working copy) > >>>> @@ -101,8 +101,10 @@ > >>>> return; > >>>> if (lp->loc_loc == dirp->dd_loc && lp->loc_seek == > >>>> dirp->dd_seek) > >>>> return; > >>>> - (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, > >>>> SEEK_SET); > >>>> - dirp->dd_seek = lp->loc_seek; > >>>> + if (lp->loc_seek != dirp->dd_seek) { > >>>> + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, > >>>> SEEK_SET); > >>>> + dirp->dd_seek = lp->loc_seek; > >>>> + } > >>> yes I did that yesterday but it still fails when you transition > >>> blocks.. (badly). > >>> > >>> I also tried bigger blocks.. also fails (eventually) > >>> > >>> I did find a way to make it work... you had to seek back > >>> to the first block you deleted on each set.. > >>> then work forward from there again.. unfortunately since > >>> I'm trying to make a microsoft program not fail (via samba) > >>> I have no control over how it does things and seekdir doesn't > >>> know what was deleted anyway... (so the fix is fine for the > >>> test program but not for real life) > >>> > >>> I think I can make the BSD one act like the linux one by changing > >>> the lseek being done to use the offset (loc) plus the buffer seek > >>> address of the target, instead of just going for the buffer base > >>> and > >>> stepping forward through the entries.. > >>> > >>> maybe tomorrow. > >>> > >> The following conditional code makes ours behave the same as the > >> linux > >> one. > >> it breaks several 'rules' but works where ours is clean but > >> fails.. > >> as Rick said.. "maybe that's what we should do too." > >> > >> > >> this is at the end of seekdir() > >> > >> > >> The new code does what linux does.. and shouldn't work.. but does > >> // at least in the limited conditions I need it to. > >> // We'll probably need to do this at work...: > >> > >> > >> The original code is what we have now, but gets mightily confused > >> sometimes. > >> // This is clean(er) but fails in specific > >> situations(when > >> doing commands > >> // from Microft windows, via samba). > >> > >> > >> root@vps1:/tmp # diff -u dir.c.orig dir.c > >> --- dir.c.orig 2015-04-24 11:29:36.855317000 -0700 > >> +++ dir.c 2015-04-24 11:15:49.058500000 -0700 > >> @@ -1105,6 +1105,13 @@ > >> dirp->dd_loc = lp->loc_loc; > >> return; > >> } > >> +#ifdef GLIBC_SEEK > >> + (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek + lp->loc_loc, > >> SEEK_SET); > >> + dirp->dd_seek = lp->loc_seek + lp->loc_loc; > >> + dirp->dd_loc = 0; > >> + lp->loc_seek = dirp->dd_seek; > >> + lp->loc_loc = 0; > >> +#else > >> (void) lseek(dirp->dd_fd, (off_t)lp->loc_seek, SEEK_SET); > >> dirp->dd_seek = lp->loc_seek; > >> dirp->dd_loc = 0; > >> @@ -1114,6 +1121,7 @@ > >> if (dp == NULL) > >> break; > >> } > >> +#endif > >> } > > Yes, this isn't at all safe. There's no guarantee whatsoever that > > the offset on the directory fd that isn't something returned by > > getdirentries has any meaning. > the value returned by getdirentries is the original seek for the > block, and the offset is not sent obviosly.. but we could > do somethign where getdirentries 'remembers' all teh offsets it sent > for the last set of entries, of we could make it return a a seekable > cookie for every entry... > The problem is that there are two separate sets of offsets. There are the byte offsets in the "logical UFS-like directory blocks" generated by the file systems for VOP_READDIR() and then there are the "physical offset cookies" which are opaque bits for anything but the underlying file system. The latter is a location for the directory entry within the directory structure it maintains. My thinking was that d_off would be this latter physical offset cookie and that a new getdirenties(2) syscall and a new VOP_READDIR() would allow passage of this to the file system, so that it could return directory entries starting at that place in its directory. I have never gotten around to looking closely at the libc stuff, to try and determine if this can all be made to work correctly. rick ps: This is all "future" stuff and probably doesn't help come up with a better set of libc functions for what is in head/current. (Didn't want to hijack the discussion, but it is in a sense relevant.) > > In particular, the size of the > > directory entry in a random filesystem might be a different size > > than the structure returned by getdirentries (since it converts > > things into a FS-independent format). > > yes I understand all that.. :-) > > > > This might work for UFS by accident, but this is probably why ZFS > > doesn't work. > actually ZFS seems to work too which stunned me.. > > > However, this might be properly fixed by the thing that ino64 is > > doing where each directory entry returned by getdirentries gives > > you a seek offset that you _can_ directly seek to (as opposed to > > seeking to the start of the block and then walking forward N > > entries until you get an inter-block entry that is the same). > > yeah that might be nice. > > > > > _______________________________________________ > 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 Sat Apr 25 13:50:33 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 6DF32935; Sat, 25 Apr 2015 13:50:33 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 1693C1117; Sat, 25 Apr 2015 13:50:32 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id D28E716A4B2; Sat, 25 Apr 2015 15:50:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qceREY6N5ez4; Sat, 25 Apr 2015 15:50:02 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:9d5b:6fac:30b6:fba1] (unknown [IPv6:2001:4cb8:3:1:9d5b:6fac:30b6:fba1]) by smtp.digiware.nl (Postfix) with ESMTPA id 58EE916A45A; Sat, 25 Apr 2015 15:41:00 +0200 (CEST) Message-ID: <553B9969.1070602@digiware.nl> Date: Sat, 25 Apr 2015 15:40:57 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Garrett Cooper CC: Ed Maste , Warren Block , FreeBSD Current Subject: Re: Newer yacc needed for building world References: <5537C3BA.8010206@digiware.nl> <5537FCA1.6010108@digiware.nl> <5538B5CF.9010508@digiware.nl> In-Reply-To: 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: Sat, 25 Apr 2015 13:50:33 -0000 On 24/04/2015 12:05, Garrett Cooper wrote: > On Apr 24, 2015, at 3:03, Garrett Cooper > wrote: > >> On Apr 24, 2015, at 2:59, Garrett Cooper >> wrote: >> >>> On Apr 23, 2015, at 2:05, Willem Jan Withagen >>> wrote: >>> >>>> On 22/04/2015 23:37, Ed Maste wrote: >>>>> On 22 April 2015 at 15:55, Willem Jan Withagen >>>>> wrote: >>>>>> >>>>>>> Yes: >>>>>>> https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> But this is not enough to make yacc part of the build tools?? >>>>> >>>>> yacc is unconditionally built during bootstrap-tools as of >>>>> r281615. What SVN rev is your tree? >>>>> >>>> >>>> # svn info Path: . Working Copy Root Path: /usr/src URL: >>>> svn://svn.freebsd.org/base/stable/10 Relative URL: ^/stable/10 >>>> Repository Root: svn://svn.freebsd.org/base Repository UUID: >>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 281853 Node >>>> Kind: directory Schedule: normal Last Changed Author: kib Last >>>> Changed Rev: 281849 Last Changed Date: 2015-04-22 12:59:05 >>>> +0200 (Wed, 22 Apr 2015) >>>> >>>> Then I removed /usr/obj/* to get a fresh start. Removing yacc >>>> just gets me into trouble even earlier: >>>> >>>> # make -j 32 buildworld . . . --- >>>> _bootstrap-tools-usr.bin/compile_et --- --- parse.c --- yacc -d >>>> -o parse.c >>>> /usr/src/usr.bin/compile_et/../../contrib/com_err/parse.y yacc: >>>> not found --- _bootstrap-tools-usr.sbin/bsnmpd/gensnmptree --- >>>> /usr/obj/usr/src/tmp/usr/src/usr.sbin/bsnmpd/gensnmptree >>>> created for /usr/src/usr.sbin/bsnmpd/gensnmptree --- >>>> _bootstrap-tools-usr.bin/compile_et --- *** [parse.c] Error >>>> code 127 >>>> >>>> So I have relatively little further to test. Perhaps the '-j >>>> 32' was a bit aggressive, but it gets fast where the error is. >>> >>> Well, that’s amusing :(. You found a new race that wasn’t present >>> before my changes to parallelize bootstrap-tools (kerberos comes >>> before yacc in bootstrap-tools). Do you have yacc installed on >>> your machine? Please try out this patch. Thanks! -NGie >>> >>> $ svn diff Makefile.inc1 Index: Makefile.inc1 >>> =================================================================== >>> >>> >>> >>> --- Makefile.inc1 (revision 281823) >>> +++ Makefile.inc1 (working copy) @@ -1358,6 +1358,8 @@ >>> usr.bin/compile_et >>> >>> .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} + >>> +${_bt}-usr.bin/compile_et: ${_bt}-usr.bin/yacc .endif >>> >>> bootstrap-tools: .PHONY >> >> It’ll also need lex too. This should be a bit more comprehensive: >> >> Index: Makefile.inc1 >> =================================================================== >> >> >> >> --- Makefile.inc1 (revision 281823) >> +++ Makefile.inc1 (working copy) @@ -1358,6 +1358,8 @@ >> usr.bin/compile_et >> >> .ORDER: ${_kerberos5_bootstrap_tools:C/^/${_bt}-/g} + >> +${_bt}-usr.bin/compile_et: ${_bt}$-usr.bin/lex >> ${_bt}-usr.bin/yacc .endif >> >> bootstrap-tools: .PHONY > > I’ll work out the finally kinks with how to spell lex and yacc… > > This is part of the reason why I think BOOTSTRAPPING needs to be > kicked to the curb and everything needs to be built in parallel, but > enough people haven’t complained about built failures, so the > optimization remains.. > Remember I moved /usr/bin/out of the path. Which would be different for using an outdated yacc. Which is where the bug originally started. This fixes the problem for a non-parallel build. But once parallel builds (with -j > 5 ) are done, the .for _tool in \ loop runs into trouble when _yacc is not finished/started before config is being build. Normally this would not be a problem as long as config is not dependant on any of the new features/size in the yacc to be build. --WjW From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 19:07:43 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 3ECFD36A; Sat, 25 Apr 2015 19:07:43 +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 C6F251FE2; Sat, 25 Apr 2015 19:07:42 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D+AwD75DtV/95baINcg19cBYMVwzoJgUgKhTZOAoFoFAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCxsYAgINGQIpAQkmBggHBAEcBIgCCA2yP5QbAQEBAQYBAQEBAQEBG4EhiheEMwEBBRc0B4JogUUFlVaCP4FJg1I9hXuKN4NQI4FlIR2BbSIxB4EEOYEAAQEB X-IronPort-AV: E=Sophos;i="5.11,647,1422939600"; d="scan'208";a="206143071" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Apr 2015 15:07:41 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 13C37B4008; Sat, 25 Apr 2015 15:07:41 -0400 (EDT) Date: Sat, 25 Apr 2015 15:07:41 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-current@freebsd.org, Jilles Tjoelker , John Baldwin Message-ID: <1316859246.25755743.1429988861067.JavaMail.root@uoguelph.ca> In-Reply-To: <553B0100.4070307@freebsd.org> Subject: Re: readdir/telldir/seekdir problem (i think) 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: Sat, 25 Apr 2015 19:07:43 -0000 Julian Elischer wrote: > On 4/25/15 5:52 AM, Jilles Tjoelker wrote: > > On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > >> Yes, this isn't at all safe. There's no guarantee whatsoever that > >> the offset on the directory fd that isn't something returned by > >> getdirentries has any meaning. In particular, the size of the > >> directory entry in a random filesystem might be a different size > >> than the structure returned by getdirentries (since it converts > >> things into a FS-independent format). > >> This might work for UFS by accident, but this is probably why ZFS > >> doesn't work. I took a quick look at UFS, ZFS and NFS: - UFS appears to use the offset as a block + offset within the block, so it is understandable that it works for the simple "seek to byte offset" case. - One oddity here is that the loop that copies out directory entries (about line#2188 in ufs_vnops.c) skips over d_ino == 0. Then uiomove() copies the data out and offset is updated. --> Seems to me that uio_offset "skips" entries with d_ino == 0, so it isn't the actual byte offset in the on-disk directory. *** Somehow, this seems it would break seekdir/telldir at some point? (This handling of uio_offset seems just plain broken to me?) - ZFS appears to number directory entries 1, 2, 3, 4, ... But, except for 1, 2, 3 (which are somewhat special, indicating ".", ".." and one other I've already forgotten, maybe ".zfs"), the rest are "serialized", which seems to mean that the byte offset is kept in a list along with some hash function used to find them. --> I didn't really follow the code, but it appears to "offset >> 28", so I don't think the low order 28bits are used to get the directory block. As such, I'm not too surprised that adding in the byte position within the block when doing lseek() doesn't break it. (I didn't really follow the stuff in zap_micro.c, so I could be all wrong here.) - I don't know if removal of an entry changes these indices 3, 4, ...? - NFS gets the block and mostly ignores the byte position within the block. (ie. It does "uio_offset / NFS_DIRBLKSIZ" and then uses that to get a buffer cache block. This will, in turn, look up this value to find a cached cookie.) --> The only effect of "uio_offset % NFS_DIRBLKSIZ" != 0 is that it will return data from this logical position within a block for the readdir. --> If a Readdir RPC is done for the cached cookie after a Remove, it is up to the NFS server's implementation w.r.t. what you'll get back. Not sure if the above is actually useful, at least until all file systems are evaluated, rick. > >> However, this might be properly fixed by the thing that ino64 is > >> doing where each directory entry returned by getdirentries gives > >> you a seek offset that you _can_ directly seek to (as opposed to > >> seeking to the start of the block and then walking forward N > >> entries until you get an inter-block entry that is the same). > > The ino64 branch only reserves space for d_off and does not use it > > in > > any way. This is appropriate since actually using d_off is a major > > feature addition. > > > > A proper d_off would still be useful even if UFS's readdir keeps > > masking > > off the offset so a directory read always starts at the beginning > > of a > > 512-byte directory block, since this allows more distinct offset > > values > > than safely using getdirentries()'s *basep. With d_off, one outer > > loop > > must read at least one directory block to avoid spinning > > indefinitely, > > while using getdirentries()'s *basep requires reading the whole > > getdirentries() buffer. > > > > Some Linux filesystems go further and provide a unique d_off for > > each > > entry. > > > > Another idea would be to store the last d_ino instead of dd_loc > > into the > > struct ddloc. On seekdir(), this would seek to loc_seek as before > > and > > skip entries until that d_ino is found, or to the start of the > > buffer if > > not found (and possibly return some entries again that should not > > be > > returned, but Samba copes with that). > > yes.. though maybe a hash of hte inode number and the name may be a > better thing to search on.. > > I need to check on your statement about samba to see if its true for > 3.6.. > > > > > > _______________________________________________ > 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 Sat Apr 25 19:20: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 27148549; Sat, 25 Apr 2015 19:20:47 +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 9517510CC; Sat, 25 Apr 2015 19:20:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2D/AwBE6DtV/95baINcg19cBYMVwzoJgUgKhTZOAoFoFAEBAQEBAQGBCoQgAQEBAwEBAQEgBCcgCwUWGAICDRkCKQEJJgYIBwQBHASIAggNskSUHQEBAQEGAQEBAQEBARuBIYoXhDMBAQUXNAeCaIFFBZVWhAiDUj2Fe44HI4FlIR2BbSIxB4EEOYEAAQEB X-IronPort-AV: E=Sophos;i="5.11,647,1422939600"; d="scan'208";a="207954118" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Apr 2015 15:20:45 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D1B92B3F61; Sat, 25 Apr 2015 15:20:44 -0400 (EDT) Date: Sat, 25 Apr 2015 15:20:44 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-current@freebsd.org, John Baldwin , Jilles Tjoelker Message-ID: <652208796.25758115.1429989644844.JavaMail.root@uoguelph.ca> In-Reply-To: <553B0326.1090306@freebsd.org> Subject: Re: readdir/telldir/seekdir problem (i think) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.11] 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: Sat, 25 Apr 2015 19:20:47 -0000 Julian Elischer wrote: > On 4/25/15 9:39 AM, Rick Macklem wrote: > > Jilles Tjoelker wrote: > >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > >>> Yes, this isn't at all safe. There's no guarantee whatsoever > >>> that > >>> the offset on the directory fd that isn't something returned by > >>> getdirentries has any meaning. In particular, the size of the > >>> directory entry in a random filesystem might be a different size > >>> than the structure returned by getdirentries (since it converts > >>> things into a FS-independent format). > >>> This might work for UFS by accident, but this is probably why ZFS > >>> doesn't work. > >>> However, this might be properly fixed by the thing that ino64 is > >>> doing where each directory entry returned by getdirentries gives > >>> you a seek offset that you _can_ directly seek to (as opposed to > >>> seeking to the start of the block and then walking forward N > >>> entries until you get an inter-block entry that is the same). > >> The ino64 branch only reserves space for d_off and does not use it > >> in > >> any way. This is appropriate since actually using d_off is a major > >> feature addition. > >> > > Well, at some point ino64 will need to define a new > > getdirentries(2) > > syscall and I believe this new syscall can have > > different/additional > > arguments. > yes, posix only specifies 2 mandatory fields (d_ino and d_name) and > everything else is implementation dependent. > > I'd suggest that the new gtedirentries(2) syscall should return a > > flag to indicate that the underlying file system is filling in > > d_off. > > Then the libc functions can use d_off if it it available. > > (They will still need to "work" at least as well as they do now if > > the file system doesn't support d_off. The old getdirentries(2) > > syscall > > will be returning the old/current "struct dirent" which doesn't > > have > > the field anyhow.) > > > > Another bit of fun is that the argument for seekdir()/telldir() is > > a > > long and ends up 32bits for some arches. d_off is 64bits, since > > that > > is what some file systems require. Now that I've taken a look at the libc code, I can see that loc_XX structures handle the telldir/seekdir stuff (mapping the seek position plus offset within a block to an index). I think d_off could be saved there as well (if the file system provides it) and the new getdirentries() could take a "physical offset" argument where this d_off could be passed down to the file system. I think this would allow the problem to be handled properly "in general". It still doesn't quite solve the NFS case. - For NFS, a server is supposed to have a "directory_cookie_verifier", which allows the server to decide if a "directory offset cookie" is still valid. --> This has never been implemented for the FreeBSD server and it isn't easy. In part, real NFS servers don't do what the RFC describes, at least not in an obvious way. They "understand" if offset cookies still work after removal of an entry and also must store this "directory_offset_verifier" in the file's attributes. FreeBSD just never checks this verifier. rick > what does linux use? > ------ > In glibc up to version 2.1.1, the return type of telldir() was > off_t. > POSIX.1-2001 specifies long, and this is the type used since > glibc > 2.1.2. > > also from the linux man page: this is interesting.. > > -------- > In early filesystems, the value returned by telldir() was a > simple > file offset within a directory. Modern filesystems use tree > or hash > structures, rather than flat tables, to represent > directories. On > such filesystems, the value returned by telldir() (and used > internally by readdir(3)) is a "cookie" that is used by the > implementation to derive a position within a directory. > Application > programs should treat this strictly as an opaque value, > making no > assumptions about its contents. > ------ > but glibc uses the contents in a nonopaque (and possibly wrong) way > itself in seekdir. . > (not following their own advice.) > > > > Maybe the library code can only use d_off if it is a 64bit arch and > > the file system is filling it in. (Or maybe the library can keep > > track > > of 32<->64bit mappings for the offsets. I haven't looked at the > > libc > > functions for a while, so I can't remember what they keep track > > of.) > > one supposes a 32 bit system would not have such large file systems > on > it.. > (maybe?) > > > > rick > > > >> A proper d_off would still be useful even if UFS's readdir keeps > >> masking > >> off the offset so a directory read always starts at the beginning > >> of > >> a > >> 512-byte directory block, since this allows more distinct offset > >> values > >> than safely using getdirentries()'s *basep. With d_off, one outer > >> loop > >> must read at least one directory block to avoid spinning > >> indefinitely, > >> while using getdirentries()'s *basep requires reading the whole > >> getdirentries() buffer. > >> > >> Some Linux filesystems go further and provide a unique d_off for > >> each > >> entry. > >> > >> Another idea would be to store the last d_ino instead of dd_loc > >> into > >> the > >> struct ddloc. On seekdir(), this would seek to loc_seek as before > >> and > >> skip entries until that d_ino is found, or to the start of the > >> buffer > >> if > >> not found (and possibly return some entries again that should not > >> be > >> returned, but Samba copes with that). > >> > >> -- > >> Jilles Tjoelker > >> _______________________________________________ > >> 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 Sat Apr 25 20:26:22 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 4D019DBA for ; Sat, 25 Apr 2015 20:26:22 +0000 (UTC) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id 38FEA171F for ; Sat, 25 Apr 2015 20:26:21 +0000 (UTC) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id 0930E1C1CF1A for ; Sat, 25 Apr 2015 13:26:48 -0700 (PDT) Date: Sat, 25 Apr 2015 13:26:09 -0700 (MST) From: r00ster To: freebsd-current@freebsd.org Message-ID: <1429993569027-6007628.post@n5.nabble.com> In-Reply-To: <1849381.HnoQVUIgNM@akita> References: <1849381.HnoQVUIgNM@akita> Subject: Re: Call For Testers: Synaptics touchpads MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 25 Apr 2015 20:59:08 +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: Sat, 25 Apr 2015 20:26:22 -0000 Do you know if this patch can be applied to 10.1 RELEASE? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Call-For-Testers-Synaptics-touchpads-tp6003555p6007628.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Apr 25 21:15: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 6D36343D; Sat, 25 Apr 2015 21:15:27 +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 CC9AD1BB0; Sat, 25 Apr 2015 21:15:26 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CsBACkAzxV/95baINCGoNfXAWDFcNDgUgKhTZOAoFrEwEBAQEBAQGBCoQhAQEEAQEBIAQnIAsbGAICDRkCKQEJJgYIBwQBHASICg04sgCUDwEBAQEBAQQBAQEBAQEBAQEZgSGKF4QzAQEcNAeCaIFFBZVWhAiDUj2Fe44HI4IGHYFtIjEBBoEEOYEAAQEB X-IronPort-AV: E=Sophos;i="5.11,647,1422939600"; d="scan'208";a="206151471" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Apr 2015 17:15:25 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id CA60FB3F08; Sat, 25 Apr 2015 17:15:24 -0400 (EDT) Date: Sat, 25 Apr 2015 17:15:24 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-current@freebsd.org, John Baldwin , Jilles Tjoelker Message-ID: <1302099206.25780241.1429996524816.JavaMail.root@uoguelph.ca> In-Reply-To: <553B0326.1090306@freebsd.org> Subject: Re: readdir/telldir/seekdir problem (i think) 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: Sat, 25 Apr 2015 21:15:27 -0000 Julian Elischer wrote: > On 4/25/15 9:39 AM, Rick Macklem wrote: > > Jilles Tjoelker wrote: > >> On Fri, Apr 24, 2015 at 04:28:12PM -0400, John Baldwin wrote: > >>> Yes, this isn't at all safe. There's no guarantee whatsoever > >>> that > >>> the offset on the directory fd that isn't something returned by > >>> getdirentries has any meaning. In particular, the size of the > >>> directory entry in a random filesystem might be a different size > >>> than the structure returned by getdirentries (since it converts > >>> things into a FS-independent format). > >>> This might work for UFS by accident, but this is probably why ZFS > >>> doesn't work. > >>> However, this might be properly fixed by the thing that ino64 is > >>> doing where each directory entry returned by getdirentries gives > >>> you a seek offset that you _can_ directly seek to (as opposed to > >>> seeking to the start of the block and then walking forward N > >>> entries until you get an inter-block entry that is the same). > >> The ino64 branch only reserves space for d_off and does not use it > >> in > >> any way. This is appropriate since actually using d_off is a major > >> feature addition. > >> > > Well, at some point ino64 will need to define a new > > getdirentries(2) > > syscall and I believe this new syscall can have > > different/additional > > arguments. > yes, posix only specifies 2 mandatory fields (d_ino and d_name) and > everything else is implementation dependent. > > I'd suggest that the new gtedirentries(2) syscall should return a > > flag to indicate that the underlying file system is filling in > > d_off. > > Then the libc functions can use d_off if it it available. > > (They will still need to "work" at least as well as they do now if > > the file system doesn't support d_off. The old getdirentries(2) > > syscall > > will be returning the old/current "struct dirent" which doesn't > > have > > the field anyhow.) > > > > Another bit of fun is that the argument for seekdir()/telldir() is > > a > > long and ends up 32bits for some arches. d_off is 64bits, since > > that > > is what some file systems require. > what does linux use? Btw, I found this: https://bugs.centos.org/view.php?id=5496 It appears that Linux has been having fun with this too, at least for NFS. I still think that reading the whole directory is the only way to fix NFS. (Unfortunately, they don't say how the Linux distros fixed it.;-) Have fun with it, rick > ------ > In glibc up to version 2.1.1, the return type of telldir() was > off_t. > POSIX.1-2001 specifies long, and this is the type used since > glibc > 2.1.2. > > also from the linux man page: this is interesting.. > > -------- > In early filesystems, the value returned by telldir() was a > simple > file offset within a directory. Modern filesystems use tree > or hash > structures, rather than flat tables, to represent > directories. On > such filesystems, the value returned by telldir() (and used > internally by readdir(3)) is a "cookie" that is used by the > implementation to derive a position within a directory. > Application > programs should treat this strictly as an opaque value, > making no > assumptions about its contents. > ------ > but glibc uses the contents in a nonopaque (and possibly wrong) way > itself in seekdir. . > (not following their own advice.) > > > > Maybe the library code can only use d_off if it is a 64bit arch and > > the file system is filling it in. (Or maybe the library can keep > > track > > of 32<->64bit mappings for the offsets. I haven't looked at the > > libc > > functions for a while, so I can't remember what they keep track > > of.) > > one supposes a 32 bit system would not have such large file systems > on > it.. > (maybe?) > > > > rick > > > >> A proper d_off would still be useful even if UFS's readdir keeps > >> masking > >> off the offset so a directory read always starts at the beginning > >> of > >> a > >> 512-byte directory block, since this allows more distinct offset > >> values > >> than safely using getdirentries()'s *basep. With d_off, one outer > >> loop > >> must read at least one directory block to avoid spinning > >> indefinitely, > >> while using getdirentries()'s *basep requires reading the whole > >> getdirentries() buffer. > >> > >> Some Linux filesystems go further and provide a unique d_off for > >> each > >> entry. > >> > >> Another idea would be to store the last d_ino instead of dd_loc > >> into > >> the > >> struct ddloc. On seekdir(), this would seek to loc_seek as before > >> and > >> skip entries until that d_ino is found, or to the start of the > >> buffer > >> if > >> not found (and possibly return some entries again that should not > >> be > >> returned, but Samba copes with that). > >> > >> -- > >> Jilles Tjoelker > >> _______________________________________________ > >> 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 Sat Apr 25 22:07: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 15390D64 for ; Sat, 25 Apr 2015 22:07:36 +0000 (UTC) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id 00EA01015 for ; Sat, 25 Apr 2015 22:07:35 +0000 (UTC) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id BBE221C1E3F7 for ; Sat, 25 Apr 2015 15:08:14 -0700 (PDT) Date: Sat, 25 Apr 2015 15:07:34 -0700 (MST) From: r00ster To: freebsd-current@freebsd.org Message-ID: <1429999654785-6007638.post@n5.nabble.com> In-Reply-To: <1429993569027-6007628.post@n5.nabble.com> References: <1849381.HnoQVUIgNM@akita> <1429993569027-6007628.post@n5.nabble.com> Subject: Re: Call For Testers: Synaptics touchpads MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 25 Apr 2015 23:34:31 +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: Sat, 25 Apr 2015 22:07:36 -0000 By the way, just to clarify my question, what I'm asking is if it's possible for me to put the relevant additions from this patch for two-finger scrolling into 10.1. This is a feature I've really been looking forward to, so thank you very much for the work you put into it. :) -- View this message in context: http://freebsd.1045724.n5.nabble.com/Call-For-Testers-Synaptics-touchpads-tp6003555p6007638.html Sent from the freebsd-current mailing list archive at Nabble.com.