From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 00:34: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 E61A2F2 for ; Sun, 29 Mar 2015 00:34:47 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 80E0A18A for ; Sun, 29 Mar 2015 00:34:44 +0000 (UTC) Received: by wgdm6 with SMTP id m6so135178770wgd.2 for ; Sat, 28 Mar 2015 17:34:42 -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:cc:subject :content-type:content-transfer-encoding; bh=KoNWuI8hPvBi1zOQFk5VS3u0hF4WOx8xglJI3YrJfEU=; b=ng803D4TaNzkNTtdsIB9E7sn8qG8JQO1a6QqgFvEUXvAddAWn5spzsPHdJXoqIrtl7 lVM6z82Q6in8H1xxv6WRCOnhz/3nPgH1ZGRjTHh1/RFvaM5TIAg/WAv/inVNJBFd6IAr /AZ1WNkW0J5ydnHWFMqGyPBx4Es5WLps3x0QDx4NTSMIp3lgpjGU9rHV8VfV6/kK5K4X cj1XWvgDMVH+qY+k7pcu2It5aY4qWImyzMUlFj0yu07OSRcg3AolWq0RhKfWw7y+ZWPt 1UEHRP/5zWnACJ09yy9mTjEKM9841UXbuUmM5TH89z8wDyje6hejdqp2CGrGFgFeW6cB 6+sw== X-Received: by 10.194.6.70 with SMTP id y6mr48657739wjy.97.1427589282771; Sat, 28 Mar 2015 17:34:42 -0700 (PDT) Received: from [192.168.1.105] (ppp-203-12.26-151.libero.it. [151.26.12.203]) by mx.google.com with ESMTPSA id wo10sm9127270wjb.35.2015.03.28.17.34.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 17:34:42 -0700 (PDT) Message-ID: <551748A4.1090303@gmail.com> Date: Sun, 29 Mar 2015 01:34:44 +0100 From: bsdml User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org. Subject: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 29 Mar 2015 04:23:15 +0000 Cc: mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 00:34:48 -0000 Hello guys, since I tried to install FreeBSD 10.1 on my recently purchased T40 I got stuck at this annoying bootloop that says "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: Command timeout". I have also tried latest 11-CURRENT snapshot and it did not make any difference at all, it is affected from the same exact bootloop. I use to boot the kernel and installation image from PXE, however did try from usb and didn't make any difference, the bootloop goes on forever. I did a bunch of researches on Google and somebody suggested to boot with hint.achci.0.msi="0" or with hw.achi.force="1" but again it did not make any difference. It seems like there might be an issue with the CAM ATA stack that is clashing with the PATA controller on my T40. Interestingly enough, I did try to remove the cdrom drive and boot the installation image with no cd drive installed. However in this case the kernel hangs and seat endlessly on the usb controller detection, it does not progress or give out any logs past the usb controller recognition. Unfortunately at the time being it seems like I am stuck with 10 release, hopefully someone will eventually address this issue so that my T40 can see the light again :) . Here's the link to the picture that showcase the bootloop. https://lh4.googleusercontent.com/-XtUvTbUf_pQ/VQy37HOXAwI/AAAAAAAAHGQ/t8Pjl7oMlls/s512/IMG_20150321_011327.jpg Regards, Pietro Sammarco From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 08:12: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 B171BFB1 for ; Sun, 29 Mar 2015 08:12:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9204DF64 for ; Sun, 29 Mar 2015 08:12:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 975816E9 for ; Sun, 29 Mar 2015 08:12:12 +0000 (UTC) Date: Sun, 29 Mar 2015 08:12:11 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <417452041.4.1427616732149.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1450 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: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 08:12:12 -0000 See ------------------------------------------ Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build number 949 originally caused by: Started by upstream project "FreeBSD_HEAD" build number 2606 originally caused by: Started by an SCM change Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # timeout=10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=10 > git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://github.com/freebsd/freebsd-ci at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1270) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531) at hudson.model.Run.execute(Run.java:1751) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: unable to access 'https://github.com/freebsd/freebsd-ci/': Unknown SSL protocol error in connection to github.com:443 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to jenkins-10.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1360) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131) at com.sun.proxy.$Proxy57.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733) ... 11 more ERROR: Error fetching remote repo 'origin' From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 09:27: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 68A44E13; Sun, 29 Mar 2015 09:27:14 +0000 (UTC) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (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 E2D37848; Sun, 29 Mar 2015 09:27:13 +0000 (UTC) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t2T9O3ai031626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 29 Mar 2015 11:24:03 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.14.9/8.14.9) with ESMTP id t2T9RDQd069961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 29 Mar 2015 11:27:13 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.14.9/8.14.9/Submit) id t2T9RD2B069960; Sun, 29 Mar 2015 11:27:13 +0200 (CEST) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Sun, 29 Mar 2015 11:27:13 +0200 From: Wolfgang Zenker To: bsdml Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT Message-ID: <20150329092713.GA69272@lyxys.ka.sub.org> References: <551748A4.1090303@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551748A4.1090303@gmail.com> Organization: private site User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Sun, 29 Mar 2015 11:24:04 +0200 (CEST) Cc: mav@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 09:27:14 -0000 Hi, * bsdml [150329 01:34]: > since I tried to install FreeBSD 10.1 on my recently purchased T40 I got > stuck at this annoying bootloop that says > "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: > Command timeout". I have also tried latest 11-CURRENT snapshot and it > did not make any difference at all, it is affected from the same exact > bootloop. > [..] > It seems like there might be an issue with the CAM ATA stack that is > clashing with the PATA controller on my T40. I had the same problem on an ancient T42p. In my case, disabling the second ata channel allowed me to boot. I added the following line to /boot/device.hints: hint.ata.1.disabled="1" Wolfgang From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 10:07: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 DD58789D for ; Sun, 29 Mar 2015 10:07:38 +0000 (UTC) Received: from theia.rz.uni-saarland.de (theia.rz.uni-saarland.de [134.96.7.31]) by mx1.freebsd.org (Postfix) with ESMTP id 646E6C1E for ; Sun, 29 Mar 2015 10:07:37 +0000 (UTC) Received: from itz-mail.htw-saarland.de (itz-mail.htw-saarland.de [134.96.210.141]) by theia.rz.uni-saarland.de (8.14.9/8.14.0) with ESMTP id t2TA7ZRH015736; Sun, 29 Mar 2015 12:07:35 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.6 at HIZ-Mailrelay theia.rz.uni-saarland.de Received: from magritte.htw-saarland.de (magritte.htw-saarland.de [134.96.214.195]) by itz-mail.htw-saarland.de (8.14.5/8.14.5) with ESMTP id t2TA7ZDU009266; Sun, 29 Mar 2015 12:07:35 +0200 (CEST) Date: Sun, 29 Mar 2015 12:07:30 +0200 (CEST) From: Damian Weber To: Kurt Jaeger Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 In-Reply-To: <20150328164413.GG62590@home.opsec.eu> Message-ID: References: <5516BC51.6080108@selasky.org> <20150328164413.GG62590@home.opsec.eu> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.3 at itz-mail X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (theia.rz.uni-saarland.de [134.96.7.31]); Sun, 29 Mar 2015 12:07:35 +0200 (CEST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 10:07:39 -0000 > > > I did not find where the product ID goes ... > > is that everything I have to consider? > > At the end of sys/dev/usb/usbdevs you'll find the product IDs. I tried and failed to get Verbatim Store N Go working. This included the following attempts 1) include the quirk UQ_MSC_NO_SYNC_CACHE 2) include the quirk UQ_MSC_NO_SYNC_CACHE and UQ_MSC_NO_TEST_UNIT_READY 3) I found http://randominfo.pyret.net/index.php?controller=post&action=view&id_post=10 where some Verbatim Store N Go worked with "quirks=0x2" but there is no NO_6_BYTE quirk in dev/usb/quirk/usb_quirk.c instead I found a quirk in cam/scsi/scsi_da.c so I changed scsi_da.c, as follows --- ./cam/scsi/scsi_da.c.orig 2015-03-28 21:33:12.001813000 +0100 +++ ./cam/scsi/scsi_da.c 2015-03-28 21:37:24.196604000 +0100 @@ -413,6 +413,14 @@ }, { /* + * Verbatim Verbatim STORE N GO + * dweber@htwsaar.de + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "Verbatim", "*", + "*"}, /*quirks*/ DA_Q_NO_6_BYTE + }, + { + /* * Sigmatel USB Flash MP3 Player * PR: kern/57046 */ so in that case, the scsi_da.c quirk and the usb_quirk.c-quirks were in place, resulting in "failed to attach to device" 4) I removed the usb_quirks from the picture, leaving only the scsi_da.c quirk (NO_6_BYTE) in place, the result being the output below ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:4:0: Attached to scbus4 Trying to mount root from ufs:/dev/ada0p2 [rw]... (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (probe0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): got CAM status 0x50 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device = = == anything I should try next? Below the patches I tried, the version 4) being active, version 3) commented out with a "#if 0 ... #endif" Best wishes Damian = = == kernel patches of system FreeBSD 11.0-CURRENT #4 r280370M as of Sun Mar 29 12:06:02 CEST 2015 --- ./cam/scsi/scsi_da.c.orig 2015-03-28 21:33:12.001813000 +0100 +++ ./cam/scsi/scsi_da.c 2015-03-28 21:37:24.196604000 +0100 @@ -413,6 +413,14 @@ }, { /* + * Verbatim Verbatim STORE N GO + * dweber@htwsaar.de + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "Verbatim", "*", + "*"}, /*quirks*/ DA_Q_NO_6_BYTE + }, + { + /* * Sigmatel USB Flash MP3 Player * PR: kern/57046 */ --- ./dev/usb/quirk/usb_quirk.c.orig 2015-03-28 16:15:07.980503000 +0100 +++ ./dev/usb/quirk/usb_quirk.c 2015-03-29 10:42:14.931664000 +0200 @@ -523,6 +523,9 @@ USB_QUIRK(FEIYA, DUMMY, 0x0000, 0xffff, UQ_MSC_NO_SYNC_CACHE, UQ_MATCH_VENDOR_ONLY), USB_QUIRK(REALTEK, DUMMY, 0x0000, 0xffff, UQ_MSC_NO_SYNC_CACHE, UQ_MATCH_VENDOR_ONLY), USB_QUIRK(INITIO, DUMMY, 0x0000, 0xffff, UQ_MSC_NO_SYNC_CACHE, UQ_MATCH_VENDOR_ONLY), +#if 0 /* didn't work, we try patching ./cam/scsi/scsi_da.c */ + USB_QUIRK(VERBATIM, STORENGO, 0x0000, 0xffff, UQ_MSC_NO_SYNC_CACHE, UQ_MSC_NO_TEST_UNIT_READY, UQ_MATCH_VENDOR_ONLY), +#endif }; #undef USB_QUIRK_VP #undef USB_QUIRK --- ./dev/usb/usbdevs.orig 2015-03-28 15:55:34.870376000 +0100 +++ ./dev/usb/usbdevs 2015-03-28 16:27:37.709561000 +0100 @@ -689,6 +689,7 @@ vendor DISPLAYLINK 0x17e9 DisplayLink vendor LENOVO 0x17ef Lenovo vendor WAVESENSE 0x17f4 WaveSense +vendor VERBATIM 0x18a5 Verbatim vendor VAISALA 0x1843 Vaisala vendor AMIT 0x18c5 AMIT vendor GOOGLE 0x18d1 Google @@ -4467,6 +4468,9 @@ /* Vaisala products */ product VAISALA CABLE 0x0200 USB Interface cable +/* Verbatim products */ +product VERBATIM STORENGO 0x0243 Verbatim Store N Go + /* Vertex products */ product VERTEX VW110L 0x0100 Vertex VW110L modem From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 13:01:32 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 4A4BBF47; Sun, 29 Mar 2015 13:01:32 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD6A0EAD; Sun, 29 Mar 2015 13:01:31 +0000 (UTC) Received: by wicne17 with SMTP id ne17so1451791wic.0; Sun, 29 Mar 2015 06:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=khvIjErxUUULF5nFNMtGAymHhuz5iea9U0Z079fgK/U=; b=dO+5Jlx1S0TebzTRKBcsphd559BtsaoCWm/ML0VZ8zr6wYzC0ACltK0mCwWm0JTBbf I8/6FPw5fGBwiGqq7HyKonScnKjFBvpI4Qb0sJnGytUKR+fgWe8jiDrCo+LwZjalRigU l6r4KAFloR5cpOt01PfUkk856ntQQv0yQEYK2BzcDDkvqyvl6KTcFcyJACeZn8rNlowt s0rQhq+++h7/EPBpapaUqOhBAM/Pk9AAauItmACv3ubNm15+nI6FMAAwDe65RUaIjMU3 ntmuYgNviyaLQ4wGlvr3eNbamhaR3Uy+x3PCCl7+WeQ1y3bfcR0c08Wsp94/xOPYiwdV 2Dog== X-Received: by 10.194.200.229 with SMTP id jv5mr54394927wjc.59.1427634090358; Sun, 29 Mar 2015 06:01:30 -0700 (PDT) Received: from [192.168.190.100] (cpc74755-dals16-0-0-cust98.20-2.cable.virginm.net. [80.195.239.99]) by mx.google.com with ESMTPSA id lb6sm11160423wjb.22.2015.03.29.06.01.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 06:01:29 -0700 (PDT) References: <55168627.5060509@riseup.net> <5516CF6C.6080808@riseup.net> Mime-Version: 1.0 (1.0) In-Reply-To: <5516CF6C.6080808@riseup.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Sevan / Venture37 Subject: Re: Libreboot X200 and FreeBSD Date: Sun, 29 Mar 2015 14:01:25 +0100 To: Piotr Kubaj Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 13:01:32 -0000 > On 28 Mar 2015, at 15:57, Piotr Kubaj wrote: >=20 > It's a modified Thinkpad X200, so it uses the same chipset, i.e. GM45. Hi Piotr, Unfortunately its not possible to boot freebsd with the libreboot images due= to libreboot not have a binary blob vga bios & seabios payload. You should be able to run freebsd without issue using coreboot however (libr= eboot is a consumer of coreboot which produces images without any close comp= onents). I've managed to reflash a stock x60s with coreboot & run net/free & dragonfl= ybsd on there. I don't believer the laptops are modified physically in anyway & just have t= heir bios reflashed, might be worth asking them if you can get a laptop with= coreboot+vgabios+seabios. Alternatively, just get a thinkpad x200 & diy. You may have to resort to using linux for the initial flash. If it goes wrong & provided you made backup images before starting, you can r= ecover without issue using a raspberry pi or a beaglebone black as your repr= ogrammer & the flashrom utility. Dmesg of the x60s running coreboot is on the wiki & freebsd-acpi@ Regards Sevan / Venture37= From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 13:02:41 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 D9C27DE; Sun, 29 Mar 2015 13:02:41 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 685B5EBE; Sun, 29 Mar 2015 13:02:41 +0000 (UTC) Received: by wgra20 with SMTP id a20so143261955wgr.3; Sun, 29 Mar 2015 06:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=zeyb+mImK1X2kOgTADmg5xCxIzNlSE5hC7OCbTYPsTI=; b=YYKIwBh3zxxx2J7QnvNjJGiYvUnL+6odrvsUrKVyxtwXnuoJTyO8m/ZnVKcGfz31f2 3s4G9lEveqtq4o6C3P+Aw9AiXTugYKRwMDreWuv57ZXdzfFROlkis+njK28V75g3PBRw pXNEkj+ArcsMe/n3/nC5AzZktR+9Nnt3rw1PEAq7K+KNXr0f22FM39lK7tmnB0TPnYwv +OYAPzPmd/wPy27wCEXiJzYCcjDqHOcIulg0bA815i+vYUnJcprClxrdZ9TLbGiJrgPy 1tfpZejnXjaxvHXvu8mQDARTTRf/Lu82koiFGdoUDXl9lWxvjS/mSVfPXrIwsgwSvMCe rxkg== X-Received: by 10.180.89.34 with SMTP id bl2mr13415869wib.23.1427634159918; Sun, 29 Mar 2015 06:02:39 -0700 (PDT) Received: from [192.168.190.100] (cpc74755-dals16-0-0-cust98.20-2.cable.virginm.net. [80.195.239.99]) by mx.google.com with ESMTPSA id g2sm15520983wib.1.2015.03.29.06.02.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 06:02:39 -0700 (PDT) References: <55168627.5060509@riseup.net> <5516CF6C.6080808@riseup.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Sevan / Venture37 Subject: Re: Libreboot X200 and FreeBSD Date: Sun, 29 Mar 2015 14:02:35 +0100 To: Adrian Chadd Cc: "freebsd-hackers@freebsd.org" , freebsd-current , Piotr Kubaj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 13:02:42 -0000 > On 28 Mar 2015, at 17:42, Adrian Chadd wrote: > > Oh, in that case, someone should send me one so I can use it to verify > that my frame-buffer bootloader hack will work correctly on it. Why don't you reflash your existing one? :) Sevan / Venture37 From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 18:29: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 3CC2B640; Sun, 29 Mar 2015 18:29:24 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12C8E632; Sun, 29 Mar 2015 18:29:23 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 3245640FD5; Sun, 29 Mar 2015 18:29:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1427653757; bh=6HjBNyZb1696kTQPouRbwNbiaxhONRSyBA5FXTBR34o=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=knoqxeml1HDR/PfQIeO/kPV8V1e6CB+rRK6xKVpyiqoZ5aIO7GEg1nSjif2KV0fSA qmZ493OIUnG74cGWL5eoB2FqPTDUlDq8xcSQKsoLU+Y1sEEQqvzCR4eo4xm+0QqDY3 IBa7YqHIRXD13d6MAKM3ek+f1hOhCpTUyBfGRBRU= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 73C2E22728 Message-ID: <5518447B.7020601@riseup.net> Date: Sun, 29 Mar 2015 20:29:15 +0200 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: adrian@freebsd.org Subject: Re: Libreboot X200 and FreeBSD References: <55168627.5060509@riseup.net> <5516CF6C.6080808@riseup.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tH3qvXSKEQODcj6WbcU9QBelIQRpBKiFX" X-Virus-Scanned: clamav-milter 0.98.6 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 29 Mar 2015 19:04:46 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 18:29:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tH3qvXSKEQODcj6WbcU9QBelIQRpBKiFX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/29/2015 15:01, Sevan / Venture37 wrote: >=20 >=20 >> On 28 Mar 2015, at 15:57, Piotr Kubaj wrote: >> >> It's a modified Thinkpad X200, so it uses the same chipset, i.e. GM45.= >=20 > Hi Piotr, > Unfortunately its not possible to boot freebsd with the libreboot image= s due to libreboot not have a binary blob vga bios & seabios payload. > You should be able to run freebsd without issue using coreboot however = (libreboot is a consumer of coreboot which produces images without any cl= ose components). > I've managed to reflash a stock x60s with coreboot & run net/free & dra= gonflybsd on there. > I don't believer the laptops are modified physically in anyway & just h= ave their bios reflashed, might be worth asking them if you can get a lap= top with coreboot+vgabios+seabios. > Alternatively, just get a thinkpad x200 & diy. > You may have to resort to using linux for the initial flash. > If it goes wrong & provided you made backup images before starting, you= can recover without issue using a raspberry pi or a beaglebone black as = your reprogrammer & the flashrom utility. > Dmesg of the x60s running coreboot is on the wiki & freebsd-acpi@ >=20 > Regards >=20 >=20 > Sevan / Venture37 >=20 So, based on this information, are you able and willing to rewrite necessary code to make it work with Libreboot? --tH3qvXSKEQODcj6WbcU9QBelIQRpBKiFX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVGER7AAoJEC9nKukRsfY+fQwP/RUTkpQMdSn5U+xS0oC5xwE8 l6cwkja7jwdXNexbms4/lbmHecgdbwEvJZ02J/cMVqc0OFDSCsyL8y9YWT+8DCRq 9wiA7vP37vyy5AMqab6V/c1mMCzXqshHFYywInBVcw6ho0DL6aSRB+Z0ktXZf1+y bS+ZX6/kNP3YLzo5tbaFaES2banEbm2hpIZlz+4S/WTMY4orb8oiKeN+UUjAQL75 R7X/0JHF82eNVbx6CrHNI9Zi1O0ImnpbHcwY9M2RBgGmPHzTM/EqZstKf7kSvMsr G1EVfG1uDzHO/e4vHjjT8rSpLBX6+9fY26qq+GZghCAjYPRS5gaemk25zSR6cIa0 0Y45ga2TlFDszTV92Ia+Ot9dVovPmPGhD/i7AmaIyES4lX+S8NM8sj2GyZl/6CN4 g+55Yuijw/IRTIfG1FM8G+rZJv1APTe26VCF5PAfuT5T7a09AozTM4ixIBIlDT9Q gWpBH75LR8nkCtK31B/XXIiwqfPKCfbYSM33N3Cl28I3ISGVsHXoqemZ34dHdazp +era9xFcypaZc3c667a+B0qoBJXdp7KgVmtFStiS2YQC7irMpp3FSWnDgm9gZj6D X+EP1GgRegQN3o7iq3r62g3Ro7f6ScnfteyO+Rf7j8jgMWXOO4fPzMrqTN5cge9G +VJGIg9J2eOKTeMsvhxL =BAHX -----END PGP SIGNATURE----- --tH3qvXSKEQODcj6WbcU9QBelIQRpBKiFX-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 19:29: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 69C18A29 for ; Sun, 29 Mar 2015 19:29:53 +0000 (UTC) Received: from munin.odin-corporation.com (173-161-46-1-Illinois.hfc.comcastbusiness.net [173.161.46.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Lars Fredriksen", Issuer "Lars Fredriksen" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E4AEC8A for ; Sun, 29 Mar 2015 19:29:51 +0000 (UTC) Received: from larsmacmini.fredriksen.us (valhall.odin-corporation.com [173.161.46.2]) (authenticated bits=0) by munin.odin-corporation.com (8.14.5/8.14.5) with ESMTP id t2TJTh3S075317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Mar 2015 14:29:44 -0500 (CDT) (envelope-from lars@odin-corporation.com) From: Lars Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Is a high witness refcount indicative of a missing unlock? Message-Id: <1117D087-AD76-4A87-8798-AB5526BECF3A@odin-corporation.com> Date: Sun, 29 Mar 2015 14:29:42 -0500 To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2093\)) X-Mailer: Apple Mail (2.2093) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 19:29:53 -0000 Hi, I am poking around for a cause for my repeating deadlock issues on my = system based on r 279869. ddb show witness show the =E2=80=9Cvnode = interlock=E2=80=9D and the =E2=80=9Czfs=E2=80=9D locks both with = reference counts over 200K. Obviously they are related, and there is a = find running (all the filesystems on this machine are zfs ( minus the = specialty ones like devfs). I don=E2=80=99t see any other withness entry with reference counts even = in the ballpark of these two, so does this indicate that we have a = vnode/zfs path were we don=E2=80=99t unlock? Thanks, Lars= From owner-freebsd-current@FreeBSD.ORG Sun Mar 29 20:43: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 32D9B519 for ; Sun, 29 Mar 2015 20:43:48 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB5BE695 for ; Sun, 29 Mar 2015 20:43:47 +0000 (UTC) Received: by igcau2 with SMTP id au2so58051206igc.0 for ; Sun, 29 Mar 2015 13:43:46 -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=QRT6Snm/qbpvzc4WWrZ4P8dKp2Ih3desfn5O2nRT580=; b=pCIAVJiS5ht9OKnNIikKmk1uNODV1bitfmAKcXLqUT0LaX27m5UZCo5uHIx0VCSMt6 gR3mhGQg/wYqCBmK8+M+SpxIMFyEiA2hu0Vk87pk284sgsAwnXfTeeIemTbDXbKKAear wGTPjunt3CMIjNDjd2OrpgFIXPgAxJgS8V2nCIYQ2HVfdAE32RMid26Yq95qfaJfPxfD UFYYXzyjP6+ug1MArA4ghfF+flA6v36vFj4Zxi8LfZELywg7LYogakpQX4n7BVWKy4lv YeGKOoLLo2b0a7k94rG83/rKPOI/w3B9DnoIiyWi7BpJKTdc9bBtrUuQnnedtOwevKlU h6yA== MIME-Version: 1.0 X-Received: by 10.50.107.7 with SMTP id gy7mr13351573igb.49.1427661826887; Sun, 29 Mar 2015 13:43:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Sun, 29 Mar 2015 13:43:46 -0700 (PDT) In-Reply-To: <5518447B.7020601@riseup.net> References: <55168627.5060509@riseup.net> <5516CF6C.6080808@riseup.net> <5518447B.7020601@riseup.net> Date: Sun, 29 Mar 2015 13:43:46 -0700 X-Google-Sender-Auth: wlpMU0UaueqX11OsZwY5TiQTg_U Message-ID: Subject: Re: Libreboot X200 and FreeBSD From: Adrian Chadd To: Piotr Kubaj Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 20:43:48 -0000 So, the loader needs updating to have VGA framebuffer support. I have started that as an investigation but I don't have anything tidy enough to start pushing into -HEAD. But yes, as long as they expose the VGA framebuffer in some meaningful way (read: either they pre-initialise a dumb framebuffer, or they provide basic BIOS services for it) then it'll eventually happen. -adrian From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 00:20:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D7B8275 for ; Mon, 30 Mar 2015 00:20:32 +0000 (UTC) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 7FB12F78 for ; Mon, 30 Mar 2015 00:20:31 +0000 (UTC) Received: from ppp118-210-45-229.lns20.adl2.internode.on.net (HELO leader.local) ([118.210.45.229]) by ipmail04.adl6.internode.on.net with ESMTP; 30 Mar 2015 10:44:53 +1030 Message-ID: <5518957B.4050505@ShaneWare.Biz> Date: Mon, 30 Mar 2015 10:44:51 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Lars , freebsd-current@freebsd.org Subject: Re: Is a high witness refcount indicative of a missing unlock? References: <1117D087-AD76-4A87-8798-AB5526BECF3A@odin-corporation.com> In-Reply-To: <1117D087-AD76-4A87-8798-AB5526BECF3A@odin-corporation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 00:20:32 -0000 On 30/03/2015 05:59, Lars wrote: > Hi, I am poking around for a cause for my repeating deadlock issues > on my system based on r 279869. ddb show witness show the “vnode > interlock” and the “zfs” locks both with reference counts over > 200K. Obviously they are related, and there is a find running (all > the filesystems on this machine are zfs ( minus the specialty ones > like devfs). > > I don’t see any other withness entry with reference counts even in > the ballpark of these two, so does this indicate that we have a > vnode/zfs path were we don’t unlock? > I am running 10.1-STABLE and have bad locking issues. Running a witness kernel I got a duplicate lock from nvidia and lock order reversals involving zfs. Any chance your issue is related to mine? What command can give me the witness lock counts? The debug data I have collected so far is at - http://shaneware.biz/freebsddebugdata/ The lock reversal output I had was (after uptime of about 12 mins) - Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Mar 24 00:24:25 leader kernel: Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 done Mar 24 00:24:25 leader kernel: All buffers synced. Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xfffff800224555f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xfffff800222d67c8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2268 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e4c0 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022df6e570 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe022df6e600 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe022df6e740 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe022df6e760 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe022df6e790 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfffffe022df6e800 Mar 24 00:24:25 leader kernel: vputx() at vputx+0x232/frame 0xfffffe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x301/frame 0xfffffe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfffffe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfffffe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffffffe6d8, rbp = 0x7fffffffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xfffff800222d6b78 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1814 Mar 24 00:24:25 leader kernel: 2nd 0xffffffff818514a8 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2872 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e690 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022df6e740 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe022df6e7d0 Mar 24 00:24:25 leader kernel: _sx_slock() at _sx_slock+0x76/frame 0xfffffe022df6e810 Mar 24 00:24:25 leader kernel: mountcheckdirs() at mountcheckdirs+0x47/frame 0xfffffe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x36f/frame 0xfffffe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfffffe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfffffe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffffffe6d8, rbp = 0x7fffffffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xfffff8001ca8e240 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xfffff8001ca8e5f0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2157 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e460 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe022df6e510 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe022df6e5a0 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe022df6e6e0 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfffffe022df6e700 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfffffe022df6e730 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfffffe022df6e7a0 Mar 24 00:24:25 leader kernel: vget() at vget+0x67/frame 0xfffffe022df6e7e0 Mar 24 00:24:25 leader kernel: devfs_allocv() at devfs_allocv+0xfd/frame 0xfffffe022df6e830 Mar 24 00:24:25 leader kernel: devfs_root() at devfs_root+0x43/frame 0xfffffe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x345/frame 0xfffffe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfffffe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfffffe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfffffe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffffffe6d8, rbp = 0x7fffffffe7d0 --- Mar 24 00:24:25 leader kernel: Uptime: 12m42s -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 04:17: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 AC5A4979; Mon, 30 Mar 2015 04:17:05 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::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 6DDFCB6E; Mon, 30 Mar 2015 04:17:05 +0000 (UTC) Received: by iedm5 with SMTP id m5so107779682ied.3; Sun, 29 Mar 2015 21:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ln3rJUXxOUa76a3o0QwcLSR5OM7lmxp+nb8Zyop+V8U=; b=e+9xGzpFxbqn6Vba+XJ5VFbgmOr0ZeTcxRYcXR8amhCF/syE9NRpv67RpKMikopZyN ankTpLDsH7Kw0TR9Xo7hR7yJQOrEY2RTmpmM92IbIF/iy63fPZc9g2yZahHhasGotn8W G6EVmLOi9YfJW8t7kketife6B6z/T6TPWchFvx8jCWkULx+xCPtdLT5+kBbMHOIVBEZD sJa5F4ZLP1aznqem2H1wd3JqpVgbgooLx3mHiGuy331+1Z/7HPzNGVaKOsSKa/luQGhm 4NdyVwnOwS6B9mhRHb/euzpYVVhDDd2F93DCnE05L7nqooIexjYn/b8+pD3ET4B/bOfj Pn7Q== MIME-Version: 1.0 X-Received: by 10.42.100.211 with SMTP id b19mr44889476ico.5.1427689024833; Sun, 29 Mar 2015 21:17:04 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Sun, 29 Mar 2015 21:17:04 -0700 (PDT) In-Reply-To: <20150329092713.GA69272@lyxys.ka.sub.org> References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> Date: Sun, 29 Mar 2015 21:17:04 -0700 X-Google-Sender-Auth: B2Y_gGoacbhzl4KwVCtkJoQn_QA Message-ID: Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT From: Kevin Oberman To: Wolfgang Zenker Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: bsdml , Alexander Motin , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 04:17:05 -0000 On Sun, Mar 29, 2015 at 2:27 AM, Wolfgang Zenker wrote: > Hi, > > * bsdml [150329 01:34]: > > since I tried to install FreeBSD 10.1 on my recently purchased T40 I got > > stuck at this annoying bootloop that says > > "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: > > Command timeout". I have also tried latest 11-CURRENT snapshot and it > > did not make any difference at all, it is affected from the same exact > > bootloop. > > [..] > > It seems like there might be an issue with the CAM ATA stack that is > > clashing with the PATA controller on my T40. > > I had the same problem on an ancient T42p. In my case, disabling the > second ata channel allowed me to boot. > > I added the following line to /boot/device.hints: > hint.ata.1.disabled="1" This is an annoying side-effect of the brain-dead SATA-PATA converter in that generation of ThinkPads. The Intel ICH6 chipset is SATA, but, for reasons known ot IBM/Lenovo, the systems used PATA drives! So they has a SATA-PATA converter built in that screwed up a LOT of things, mostly compromising performance and generating assorted log entries. Looks like that also is broken in modern ATA support if a drive is not present. This was always my biggest complaint with this laptop (T42) which I used for several years until I retired and returned to so it could be excessed legally as it was government property (and, I didn't really want it, even if I could have kept it). Not an awful system, but this one issue was really annoying to me. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 07:05:11 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 7BFF8957 for ; Mon, 30 Mar 2015 07:05:11 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (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 26E98E08 for ; Mon, 30 Mar 2015 07:05:11 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2U753IZ093171 for ; Sun, 29 Mar 2015 23:05:07 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503300705.t2U753IZ093171@gw.catspoiler.org> Date: Mon, 30 Mar 2015 00:05:03 -0700 (PDT) From: Don Lewis Subject: parallel buildworld breakage To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 07:05:11 -0000 I just got this failure during a make -j12 buildworld on head r280837. --- realinstall --- sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/tmp/usr/lib/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/tmp/usr/lib/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o /usr/obj/usr/src/tmp/usr/lib/crtbeginT.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginS.o /usr/obj/usr/src/tmp/usr/lib/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtendS.o /usr/obj/usr/src/tmp/usr/lib/crtendS.o --- lib/libc__L --- /usr/src/lib/libc/net/nslexer.l:47:10: fatal error: 'nsparser.h' file not found #include "nsparser.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 I don't see any recent commits that look suspicious. Starting a single-threaded buildworld now ... From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 08:57: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 23EAE764; Mon, 30 Mar 2015 08:57:29 +0000 (UTC) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 D95AAC80; Mon, 30 Mar 2015 08:57:28 +0000 (UTC) Received: by oicf142 with SMTP id f142so113134143oic.3; Mon, 30 Mar 2015 01:57:28 -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=S8W6rlAboOPBDDGfszViRbsIz90HllMSYv25hg5Ahpk=; b=INZp22l8V1r795iniSRcyLW14jzwM4vDvEFGiMKvqDsCxdqejQ55jq0UCrzqX1hz2K aUNUdvDgRmxno3bE4QSoIC6Ym5A4juJDrEIh//kvg8ZlpO9e0GBMzBa+BrS+slSz1R9S 6sgDizYKM1FuxNmrBEbrC6y2UEMw7OTU6BRcrZ+GDXS9FUCDUmqjVwOALNWu2sNlXR42 WeuyhTRqOgENEDb7WkCljcA9FMgN0+rhCmNX51HrLN6dE2yeh7H0RqWsj2x6grYR04Hr O0AxQF6Gh6R+OxHlBkzZQC35rTztwFnaQC7hAdHbrWF1HzpiYXYmVatO5+u5O3IK4Emq P9wg== MIME-Version: 1.0 X-Received: by 10.202.210.149 with SMTP id j143mr9720895oig.131.1427705848317; Mon, 30 Mar 2015 01:57:28 -0700 (PDT) Received: by 10.76.86.42 with HTTP; Mon, 30 Mar 2015 01:57:28 -0700 (PDT) In-Reply-To: <5518447B.7020601@riseup.net> References: <55168627.5060509@riseup.net> <5516CF6C.6080808@riseup.net> <5518447B.7020601@riseup.net> Date: Mon, 30 Mar 2015 09:57:28 +0100 Message-ID: Subject: Re: Libreboot X200 and FreeBSD From: "Sevan / Venture37" To: Piotr Kubaj Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 08:57:29 -0000 On 29 March 2015 at 19:29, Piotr Kubaj wrote: > So, based on this information, are you able and willing to rewrite > necessary code to make it work with Libreboot? No, I'm multi booting my thinkpad, none of the operating systems which support the grub payload, this means I'm pretty much dependent on SeaBIOS + VGABIOS blob. That's ok for me. x86 openfirmware boot loader support on the other hand would be pretty cool.... ;) Sevan / Venture37 From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:38: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 32EBB5FC for ; Mon, 30 Mar 2015 17:38:57 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 C66E77B2 for ; Mon, 30 Mar 2015 17:38:56 +0000 (UTC) Received: by wixm2 with SMTP id m2so92508254wix.0 for ; Mon, 30 Mar 2015 10:38:55 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PFIwXVWOthY/jHwrH2WirAZdwhfNuHNbodQEfUTIUMU=; b=uJ02q84pABPzxnXjuUxF53zf/mD2yDk9S7MTeKXc8VNRLDAO8ymeRAGHUj2ojEyJjO EUvpVLpmXfTtjx1s79/OEzsp9RSjgoW623sMcLPL6k5WTzMkf7eEgMjOaOfwoL27I7Vk xzOtZ4BRLzbkjG/hSwtDRkPYTsTaBVJPbJxH5+xMM4VSWhvEb1B0xsyiMdJzph2WGBwe SPyKhzPUy+FBufOkseCXnhdF2RaR4wUlS1QSO7BhghPw3zRjwvgGhm0BIgOt8Tlfa5kq /2grUlMNq0SY68B/w3R8IZT0q55tnIEaLOFBTpYBTfbaHCNbT7NNRHuvCI3y9g5LTNBw k4Gg== X-Received: by 10.180.84.198 with SMTP id b6mr11610907wiz.25.1427737135248; Mon, 30 Mar 2015 10:38:55 -0700 (PDT) Received: from [192.168.1.6] (host121-93-dynamic.247-95-r.retail.telecomitalia.it. [95.247.93.121]) by mx.google.com with ESMTPSA id hq4sm11458489wib.0.2015.03.30.10.38.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 10:38:54 -0700 (PDT) Message-ID: <55198A31.4090203@gmail.com> Date: Mon, 30 Mar 2015 19:38:57 +0200 From: bsdml User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org. Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> In-Reply-To: <20150329092713.GA69272@lyxys.ka.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: wolfgang@lyxys.ka.sub.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 17:38:57 -0000 Hey wolfgang, thanks for getting back to me. Adding hint.ata.1.disabled="1" in /boot/device.hints indeed did the trick and allowed me to boot both 10.1 and 11-CURRENT, however this workaround has temporary solved my problem but brings up to another headache. I have planned to get a bay caddy and swap the cdrom drive with a 7.200 rpm SATA hdd, but doing this way disabling the second SATA channel I will be unable to achieve such a thing. Is there a chance that the bay caddy ATA will work without the need to disable the second ATA channel? Regards, Pietro Sammarco On 29/03/2015 11:27, Wolfgang Zenker wrote: > Hi, > > * bsdml [150329 01:34]: >> since I tried to install FreeBSD 10.1 on my recently purchased T40 I got >> stuck at this annoying bootloop that says >> "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: >> Command timeout". I have also tried latest 11-CURRENT snapshot and it >> did not make any difference at all, it is affected from the same exact >> bootloop. >> [..] >> It seems like there might be an issue with the CAM ATA stack that is >> clashing with the PATA controller on my T40. > I had the same problem on an ancient T42p. In my case, disabling the > second ata channel allowed me to boot. > > I added the following line to /boot/device.hints: > hint.ata.1.disabled="1" > > Wolfgang From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 17:49: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 41EECB5C for ; Mon, 30 Mar 2015 17:49:10 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e: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 0B2B291D for ; Mon, 30 Mar 2015 17:49:10 +0000 (UTC) Received: by pacgg7 with SMTP id gg7so44435885pac.0 for ; Mon, 30 Mar 2015 10:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=StFSvWslKw4PlgnJJ+BFbHWkm2CLPpWoL02KI+bwIj0=; b=B05H60yT/0ZLIoBeT7wCXgDqe0SA+VUgm/pI/N5ZwzZsDzAhpYuKcDrE/H0+PfIO86 w7nTNT1iBLF4iDeDK2gVQdFpVss2WJsI7IgDsvoboalxG9aVQ2cdYrXgKdfHmfXatAS3 wEUiMzCeeiaT0SzRPghK1y0Vof0/5moSc1SKGOtVEzrgSrLsRZhbcMCmVDftWYCjBnz7 vmxYOUuaidO3+oLGLqTTit83cnEa9nWVfDWb8W0smU5NUl6yaA+uiRKeirXrutfSzyaA P28zQGIQuZtoN5o3BBtoO1seryHoE0TTN9VAwOjLuAH8P/HMg42RPkIARY2TSe+FC/XC JvOA== X-Received: by 10.70.140.67 with SMTP id re3mr61340604pdb.19.1427737749557; Mon, 30 Mar 2015 10:49:09 -0700 (PDT) Received: from [10.186.94.230] ([166.170.41.89]) by mx.google.com with ESMTPSA id rx3sm11312932pbc.78.2015.03.30.10.49.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Mar 2015 10:49:08 -0700 (PDT) References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> <55198A31.4090203@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <55198A31.4090203@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12D508) From: Garrett Cooper Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT Date: Mon, 30 Mar 2015 10:49:06 -0700 To: bsdml Cc: "freebsd-current@freebsd.org" , "wolfgang@lyxys.ka.sub.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 17:49:10 -0000 > On Mar 30, 2015, at 10:38, bsdml wrote: >=20 > Hey wolfgang, >=20 > thanks for getting back to me. Adding hint.ata.1.disabled=3D"1" in /boot/d= evice.hints indeed did the trick and allowed me to boot both 10.1 and 11-CUR= RENT, however this workaround has temporary solved my problem but brings up t= o another headache. I have planned to get a bay caddy and swap the cdrom dri= ve with a 7.200 rpm SATA hdd, but doing this way disabling the second SATA c= hannel I will be unable to achieve such a thing. >=20 > Is there a chance that the bay caddy ATA will work without the need to dis= able the second ATA channel? Has a bug been filed for this issue?= From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 18:07: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 7239B4F0 for ; Mon, 30 Mar 2015 18:07:52 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 F30D4BD6 for ; Mon, 30 Mar 2015 18:07:51 +0000 (UTC) Received: by wgbdm7 with SMTP id dm7so77918094wgb.1 for ; Mon, 30 Mar 2015 11:07:50 -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:cc:subject :references:in-reply-to:content-type; bh=JkugAz83Y5ehGY6SbYj1TnlwBlaCzKyMcSg5zezqWYE=; b=H5aW5oCTSe0wn/mYPkJ3PUNsOlN4vXNBORRgPfDH0BPCZ/qslr+iweFi++zL9Jn9XA ajVcfGgJhtyKdTgIe7/nHCVx4a+gqenu9x9eC8qHwLOK8lwn9Tn6lEfbIMyI3U8seH+F X43x1y7xjZW/GKhOtoSNeWj2mI2cW0Yb4NNGwQJmgZuQ21L9iEQ3VFaGxjjU9T4H5Kju WmN2HLuIZ7fqzKx3qQjATTgy0QjC5AKt8HAUcOLuXIde4SLpIjacZ2aDu90bfRSsbSZn cFtxE1Tgs55VqS4EJUDMDcXbRhG964KXjMEt2Nh+rt6ZB7e0DXZhZtv0YXDevPy0GSKf jtSQ== X-Received: by 10.195.13.104 with SMTP id ex8mr65167256wjd.12.1427738870207; Mon, 30 Mar 2015 11:07:50 -0700 (PDT) Received: from [192.168.1.6] (host121-93-dynamic.247-95-r.retail.telecomitalia.it. [95.247.93.121]) by mx.google.com with ESMTPSA id u10sm17402996wib.1.2015.03.30.11.07.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 11:07:49 -0700 (PDT) Message-ID: <551990F6.6070202@gmail.com> Date: Mon, 30 Mar 2015 20:07:50 +0200 From: bsdml User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org. Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: mav@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 18:07:52 -0000 Hello Kevin, thanks for your clarification. Unfortunately I wasn't aware that the T40 and *4's line used a SATA-PATA convertor and especially that was going to clash with the new ATA stack in FreeBSD. Either OpenBSD and NetBSD do work out of the box without any hassle, however I'd still prefer to use FreeBSD on it as I have been using FreeBSD for about 8 years now and I am very comfortable with it. The question at this point is, is there any hope to see this issue resolved in the future? Or will I have to give up to the second ATA channel in order to use FreeBSD? Regards, Pietro Sammarco On 30/03/2015 06:17, Kevin Oberman wrote: > On Sun, Mar 29, 2015 at 2:27 AM, Wolfgang Zenker > > wrote: > > Hi, > > * bsdml > > [150329 01:34]: > > since I tried to install FreeBSD 10.1 on my recently purchased T40 I got > > stuck at this annoying bootloop that says > > "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM > status: > > Command timeout". I have also tried latest 11-CURRENT snapshot > and it > > did not make any difference at all, it is affected from the same > exact > > bootloop. > > [..] > > It seems like there might be an issue with the CAM ATA stack that is > > clashing with the PATA controller on my T40. > > I had the same problem on an ancient T42p. In my case, disabling the > second ata channel allowed me to boot. > > I added the following line to /boot/device.hints: > hint.ata.1.disabled="1" > > > This is an annoying side-effect of the brain-dead SATA-PATA converter > in that generation of ThinkPads. The Intel ICH6 chipset is SATA, but, > for reasons known ot IBM/Lenovo, the systems used PATA drives! So they > has a SATA-PATA converter built in that screwed up a LOT of things, > mostly compromising performance and generating assorted log entries. > Looks like that also is broken in modern ATA support if a drive is not > present. > > This was always my biggest complaint with this laptop (T42) which I > used for several years until I retired and returned to so it could be > excessed legally as it was government property (and, I didn't really > want it, even if I could have kept it). Not an awful system, but this > one issue was really annoying to me. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 19:38: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 E82EFEB5 for ; Mon, 30 Mar 2015 19:38:52 +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 7CF0A99C for ; Mon, 30 Mar 2015 19:38:51 +0000 (UTC) Received: by wgbdm7 with SMTP id dm7so80417279wgb.1 for ; Mon, 30 Mar 2015 12:38:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lG5JPEZ6WCVkQDGpEW4XxNAju0K22UWj5t7vXJPUKwY=; b=NJ6Er388zj+BA/3MpX9qkxNGtz4sqLH8bQbbu9n87W8tYwEd2XAvgT2868Qto242X2 GYT0TH7DLojiBjyljPWwLx/yn/IcT4ksv7rKOSStCyHOMokGauitYgCZ10dijdz7H1Mp x4lg48zPR9P+CGdDykp1VVXW3HD4CYu6Tm/Qbjb568d7V0Ohu9qmYctwogrm55VdbEHq WrS8qcj3tYWut5aqfYEm8C7zzFnj4Gi4bF224VX2E4yN+hfPDhOhX5QEgZOQIJx5ZPY9 pQ19hfxgu0S/7i642y39wOJOcwBG5/NE49tEnZNXeOHhZ4ZMTn8km4v2i2ZakTluuISa rZXg== X-Gm-Message-State: ALoCoQkcVOed1Ti+vtZVXWieEr95DkaPshQMheXgFbIZiurv60jkjXD5/8g4fEALpb6b2jGyU2On X-Received: by 10.194.158.234 with SMTP id wx10mr67946071wjb.23.1427744328282; Mon, 30 Mar 2015 12:38:48 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id q6sm17063700wix.3.2015.03.30.12.38.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 12:38:47 -0700 (PDT) Message-ID: <5519A650.1020507@multiplay.co.uk> Date: Mon, 30 Mar 2015 20:38:56 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> <551990F6.6070202@gmail.com> In-Reply-To: <551990F6.6070202@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 19:38:53 -0000 Is there anything connected to the second channel, if so what. Was this working in a previous version and if so which one and what was the verbose boot log from it? On 30/03/2015 19:07, bsdml wrote: > Hello Kevin, > > thanks for your clarification. Unfortunately I wasn't aware that the > T40 and *4's line used a SATA-PATA convertor and especially that was > going to clash with the new ATA stack in FreeBSD. Either OpenBSD and > NetBSD do work out of the box without any hassle, however I'd still > prefer to use FreeBSD on it as I have been using FreeBSD for about 8 > years now and I am very comfortable with it. > > The question at this point is, is there any hope to see this issue > resolved in the future? Or will I have to give up to the second ATA > channel in order to use FreeBSD? > > Regards, > Pietro Sammarco > > On 30/03/2015 06:17, Kevin Oberman wrote: >> On Sun, Mar 29, 2015 at 2:27 AM, Wolfgang Zenker >> > wrote: >> >> Hi, >> >> * bsdml > >> [150329 01:34]: >> > since I tried to install FreeBSD 10.1 on my recently purchased >> T40 I got >> > stuck at this annoying bootloop that says >> > "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM >> status: >> > Command timeout". I have also tried latest 11-CURRENT snapshot >> and it >> > did not make any difference at all, it is affected from the same >> exact >> > bootloop. >> > [..] >> > It seems like there might be an issue with the CAM ATA stack >> that is >> > clashing with the PATA controller on my T40. >> >> I had the same problem on an ancient T42p. In my case, disabling the >> second ata channel allowed me to boot. >> >> I added the following line to /boot/device.hints: >> hint.ata.1.disabled="1" >> >> >> This is an annoying side-effect of the brain-dead SATA-PATA converter >> in that generation of ThinkPads. The Intel ICH6 chipset is SATA, but, >> for reasons known ot IBM/Lenovo, the systems used PATA drives! So >> they has a SATA-PATA converter built in that screwed up a LOT of >> things, mostly compromising performance and generating assorted log >> entries. Looks like that also is broken in modern ATA support if a >> drive is not present. >> >> This was always my biggest complaint with this laptop (T42) which I >> used for several years until I retired and returned to so it could be >> excessed legally as it was government property (and, I didn't really >> want it, even if I could have kept it). Not an awful system, but this >> one issue was really annoying to me. >> -- >> Kevin Oberman, Network Engineer, Retired >> E-mail: rkoberman@gmail.com > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 21:19: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 8AA6F1B6; Mon, 30 Mar 2015 21:19:58 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0092487A; Mon, 30 Mar 2015 21:19:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2ULJiqu046305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 00:19:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2ULJh9C046304; Tue, 31 Mar 2015 00:19:43 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 31 Mar 2015 00:19:43 +0300 From: Gleb Smirnoff To: Manfred Antar Subject: Re: Panic on current amd64 Message-ID: <20150330211943.GV64665@FreeBSD.org> References: <201503282202.t2SM2cAb004263@pozo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201503282202.t2SM2cAb004263@pozo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: rrs@FreeBSD.org, freebsd-current@freebsd.org, hps@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 21:19:58 -0000 On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote: M> I get the following panic on current svn ver r280793: M> M> Sat Mar 28 14:41:28 PDT 2015 M> M> FreeBSD/amd64 (pozo.com) (ttyu0) M> M> panic: Invalid CPU in callout 16 The same happened to me in the OFED code. After investigation it appeared that for some unknown reason, the OFED code used /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h, that yield in wrong value passing as parameter. I failed to reproduce the problem. :( So, the fix is a rebuild of kernel. But the right fix is to understand what went wrong in the previous build. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 21:30: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 E05E1A7E; Mon, 30 Mar 2015 21:30: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 AAACF9A0; Mon, 30 Mar 2015 21:30:04 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so1288202igc.0; Mon, 30 Mar 2015 14:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U4g7Td2c+rOTMMwmy2xY5NKiAZNjqS87d0XhI/3BIcw=; b=DOV2zx6QY7sGkNaQqsGhihVqNmVkfij4EX4e9zflmlKuvUe0ub+Xy7QLtfhqUfAHd0 i7qz6rVWVGjECRBcvCxJ28e1AUH1epSKVHi5GHX9UWzVcgvVuQh6B4UDn2FeQNP60eeU 6mjYyXvELmp9X8ndy8ihFaoam1kqGAcPlrb7hM+FYThrUqSmaOaYntbU5m8jMLPv0Kpp M2mlxu/df1ara3WtKCJaOVUGTcamRyRr76Lca/9ehSZIYO2WmjFGkcgKBAC0Swgw67UJ CiTn/72Uq+gsMxm4sdjiGEynWiTZgJFiDG9+OjmnpTrSHevPsIwDuc0+Qx7fpPmDO9vR hYrA== MIME-Version: 1.0 X-Received: by 10.107.5.131 with SMTP id 125mr50488840iof.88.1427751004131; Mon, 30 Mar 2015 14:30:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Mon, 30 Mar 2015 14:30:04 -0700 (PDT) In-Reply-To: <20150330211943.GV64665@FreeBSD.org> References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> Date: Mon, 30 Mar 2015 14:30:04 -0700 X-Google-Sender-Auth: N3nF_NqTHU3x5fjPGmiHK8Ln44Y Message-ID: Subject: Re: Panic on current amd64 From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Cc: rrs@freebsd.org, freebsd-current , hps@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 21:30:08 -0000 Hi, Would you mind filing a PR for it so it isn't forgotten? -a From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 21:36:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D05D18A; Mon, 30 Mar 2015 21:36:53 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88746AC3; Mon, 30 Mar 2015 21:36:52 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2ULaolF046436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 00:36:50 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2ULaoEY046435; Tue, 31 Mar 2015 00:36:50 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 31 Mar 2015 00:36:50 +0300 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: Panic on current amd64 Message-ID: <20150330213650.GW64665@glebius.int.ru> References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> 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) Cc: rrs@freebsd.org, freebsd-current , hps@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 21:36:53 -0000 On Mon, Mar 30, 2015 at 02:30:04PM -0700, Adrian Chadd wrote: A> Would you mind filing a PR for it so it isn't forgotten? If I could provide enough information to fix that, I would either fix myself or forward information to someone confident in build. Creating PR with what I have now means simply garbaging the bugzilla. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 22:24:08 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 5D9B284A; Mon, 30 Mar 2015 22:24:08 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 061DDFC; Mon, 30 Mar 2015 22:24:07 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t2UMNw17046520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 16:23:58 -0600 (MDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t2UMNwQi046519; Mon, 30 Mar 2015 16:23:58 -0600 (MDT) (envelope-from ken) Date: Mon, 30 Mar 2015 16:23:58 -0600 From: "Kenneth D. Merry" To: scsi@freebsd.org, current@freebsd.org Subject: async pass(4) patches available Message-ID: <20150330222358.GA46342@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Mon, 30 Mar 2015 16:23:58 -0600 (MDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 22:24:08 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have put patches to add an asynchronous interface to the pass(4) driver and add a new camdd(8) utility here: FreeBSD/head as of SVN revision 280857: http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt FreeBSD stable/10 as of SVN revision 280856: http://people.freebsd.org/~ken/async_pass.stable_10.20150330.1.txt And the description / draft commit message: http://people.freebsd.org/~ken/async_pass_commitmsg.20150330.txt I have also attached the description and draft commit message to this email. The asynchronous changes to the pass(4) driver allow queueing and fetching CAM CCBs via two new ioctls. Notification of completed I/O can come via kqueue(2), poll(2), select(2), etc. The camdd(8) utility is intended as a simple data transfer utility, benchmark, and an in-tree example of how to use the asynchronous pass(4) interface. camdd(8) is still a work in progress. It needs to be cleaned up a bit and streamlined. There is one known arrival and departure bug with the pass(4) driver changes. We've reproduced it with our tests at Spectra, but I haven't yet tracked it down. There are many more arrival and departure bugs in FreeBSD/head, however. We have fixed quite a few in our local tree, but the test (called devad2) that triggers all of the problems uses the asynchronous pass(4) interface. So this is a prerequisite for fixing/verifying those bugs. Comments and testing are welcome! As I said, camdd(8) in particular is a work in progress. It could use some cleanup and there are some more useful features that could be added there. Part of the reason for camdd(8) was as a test facility for the new interface. But, it also serves as a useful demonstration of the asynchronous pass(4) functionality, given that the original application that used the API doesn't make sense to go into FreeBSD. (It is Spectra-specific, and not generally useful.) Ken -- Kenneth Merry ken@FreeBSD.ORG --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="async_pass_commitmsg.20150330.txt" Add asynchronous command support to the pass(4) driver, and the new camdd(8) utility. CCBs may be queued to the driver via the new CAMIOQUEUE ioctl, and completed CCBs may be retrieved via the CAMIOGET ioctl. User processes can use poll(2) or kevent(2) to get notification when I/O has completed. While the existing CAMIOCOMMAND blocking ioctl interface only supports user virtual data pointers in a CCB (generally only one per CCB), the new CAMIOQUEUE ioctl supports user virtual and physical address pointers, as well as user virtual and physical scatter/gather lists. This allows user applications to have more flexibility in their data handling operations. Kernel memory for data transferred via the queued interface is allocated from the zone allocator in MAXPHYS sized chunks, and user data is copied in and out. This is likely faster than the vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in configurations with many processors (there are more TLB shootdowns caused by the mapping/unmapping operation) but may not be as fast as running with unmapped I/O. The new memory handling model for user requests also allows applications to send CCBs with request sizes that are larger than MAXPHYS. The pass(4) driver now limits queued requests to the I/O size listed by the SIM driver in the maxio field in the Path Inquiry (XPT_PATH_INQ) CCB. There are some things things would be good to add: 1. Come up with a way to do unmapped I/O on multiple buffers. Currently the unmapped I/O interface operates on a struct bio, which includes only one address and length. It would be nice to be able to send an unmapped scatter/gather list down to busdma. This would allow eliminating the copy we currently do for data. 2. Add an ioctl to list currently outstanding CCBs in the various queues. 3. Add an ioctl to cancel a request, or use the XPT_ABORT CCB to do that. 4. Test physical address support. Virtual pointers and scatter gather lists have been tested, but I have not yet tested physical addresses or scatter/gather lists. 5. Investigate multiple queue support. At the moment there is one queue of commands per pass(4) device. If multiple processes open the device, they will submit I/O into the same queue and get events for the same completions. This is probably the right model for most applications, but it would be good to make sure that there is not really a case for multiple queues before pushing this code upstream. Also, add a new utility, camdd(8) that uses the asynchronous pass(4) driver interface. This utility is intended to be a basic data transfer/copy utility, a simple benchmark utility, and an example of how to use the asynchronous pass(4) interface. It can copy data to and from pass(4) devices using any target queue depth, starting offset and blocksize for the input and ouptut devices. It currently only supports SCSI devices, but could be easily extended to support ATA devices. It can also copy data to and from regular files, block devices, tape devices, pipes, stdin, and stdout. It does not support queueing multiple commands to any of those targets, since it uses the standard read(2)/write(2)/writev(2)/readv(2) system calls. The I/O is done by two threads, one for the reader and one for the writer. The reader thread sends completed read requests to the writer thread in strictly sequential order, even if they complete out of order. That could be modified later on for random I/O patterns or slightly out of order I/O. camdd(8) uses kqueue(2)/kevent(2) to get I/O compeltion events from the pass(4) driver and also to send request notifications internally. For pass(4) devcies, camdd(8) uses a single buffer (CAM_DATA_VADDR) per CAM CCB on the reading side, and a scatter/gather list (CAM_DATA_SG) on the writing side. In addition to testing both interfaces, this makes any potential reblocking of I/O easier. No data is copied between the reader and the writer, but rather the reader's buffers are split into multiple I/O requests or combined into a single I/O request depending on the input and output blocksize. For the file I/O path, camdd(8) also uses a single buffer (read(2), write(2), pread(2) or pwrite(2)) on reads, and a scatter/gather list (readv(2), writev(2), preadv(2), pwritev(2)) on writes. Things that would be nice to do for camdd(8) eventually: 1. Add support for I/O pattern generation. Patterns like all zeros, all ones, LBA-based patterns, random patterns, etc. Right Now you can always use /dev/zero, /dev/random, etc. 2. Add support for a "sink" mode, so we do only reads with no writes. Right now, you can use /dev/null. 3. Add support for automatic queue depth probing, so that we can figure out the right queue depth on the input and output side for maximum throughput. At the moment it defaults to 6. 4. Add support for SATA device passthrough I/O. 5. Add support for random LBAs and/or lengths on the input and side. 6. Track average per-I/O latency and busy time. The busy time and latency could also feed in to the automatic queue depth determination. sys/cam/scsi/scsi_pass.h: Define two new ioctls, CAMIOQUEUE and CAMIOGET, that queue and fetch asynchronous CAM CCBs respectively. Although these ioctls do not have a declared argument, they both take a union ccb pointer. If we declare a size here, the ioctl code in sys/kern/sys_generic.c will malloc and free a buffer for either the CCB or the CCB pointer (depending on how it is declared). Since we have to keep a copy of the CCB (which is fairly large) anyway, having the ioctl malloc and free a CCB for each call is wasteful. sys/cam/scsi/scsi_pass.c: Add asynchronous CCB support. Add two new ioctls, CAMIOQUEUE and CAMIOGET. CAMIOQUEUE adds a CCB to the incoming queue. The CCB is executed immediately (and moved to the active queue) if it is an immediate CCB, but otherwise it will be executed in passstart() when a CCB is available from the transport layer. When CCBs are completed (because they are immediate or passdone() if they are queued), they are put on the done queue. If we get the final close on the device before all pending I/O is complete, all active I/O is moved to the abandoned queue and we increment the peripheral reference count so that the peripheral driver instance doesn't go away before all pending I/O is done. The new passcreatezone() function is called on the first call to the CAMIOQUEUE ioctl on a given device to allocate the UMA zones for I/O requests and S/G list buffers. This may be good to move off to a taskqueue at some point. The new passmemsetup() function allocates memory and scatter/gather lists to hold the user's data, and copies in any data that needs to be written. For virtual pointers (CAM_DATA_VADDR), the kernel buffer is malloced from the new pass(4) driver malloc bucket. For virtual scatter/gather lists (CAM_DATA_SG), buffers are allocated from a new per-pass(9) UMA zone in MAXPHYS-sized chunks. Physical pointers are passed in unchanged. We have support for up to 16 scatter/gather segments (for the user and kernel S/G lists) in the default struct pass_io_req, so requests with longer S/G lists require an extra kernel malloc. The new passcopysglist() function copies a user scatter/gather list to a kernel scatter/gather list. The number of elements in each list may be different, but (obviously) the amount of data stored has to be identical. The new passmemdone() function copies data out for the CAM_DATA_VADDR and CAM_DATA_SG cases. The new passiocleanup() function restores data pointers in user CCBs and frees memory. Add new functions to support kqueue(2)/kevent(2): passreadfilt() tells kevent whether or not the done queue is empty. passkqfilter() adds a knote to our list. passreadfiltdetach() removes a knote from our list. Add a new function, passpoll(), for poll(2)/select(2) to use. Add devstat(9) support for the queued CCB path. usr.sbin/camdd/Makefile: Add a makefile for camdd(8). usr.sbin/camdd/camdd.8: Man page for camdd(8). usr.sbin/camdd/camdd.c: The new camdd(8) utility. --7AUc2qLy4jB3hD7Z-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 22:29: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 9A60BC07; Mon, 30 Mar 2015 22:29:23 +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 5A0B1169; Mon, 30 Mar 2015 22:29:23 +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 47B5F1FE023; Tue, 31 Mar 2015 00:29:18 +0200 (CEST) Message-ID: <5519CE6C.10600@selasky.org> Date: Tue, 31 Mar 2015 00:30:04 +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: Gleb Smirnoff , Manfred Antar Subject: Re: Panic on current amd64 References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> In-Reply-To: <20150330211943.GV64665@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: rrs@FreeBSD.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 22:29:23 -0000 On 03/30/15 23:19, Gleb Smirnoff wrote: > On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote: > M> I get the following panic on current svn ver r280793: > M> > M> Sat Mar 28 14:41:28 PDT 2015 > M> > M> FreeBSD/amd64 (pozo.com) (ttyu0) > M> > M> panic: Invalid CPU in callout 16 > > The same happened to me in the OFED code. After investigation > it appeared that for some unknown reason, the OFED code used > /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h, > that yield in wrong value passing as parameter. > > I failed to reproduce the problem. :( So, the fix is a rebuild > of kernel. But the right fix is to understand what went wrong > in the previous build. > Hi, How did you compile the OFED stuff? Did you set the SYSDIR variable when building? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 22:41: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 1E64E43B; Mon, 30 Mar 2015 22:41:08 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 99415313; Mon, 30 Mar 2015 22:41:07 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2UMf5Kb046778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 01:41:05 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2UMf4sK046777; Tue, 31 Mar 2015 01:41:04 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 31 Mar 2015 01:41:04 +0300 From: Gleb Smirnoff To: Hans Petter Selasky Subject: Re: Panic on current amd64 Message-ID: <20150330224104.GZ64665@glebius.int.ru> References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> <5519CE6C.10600@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5519CE6C.10600@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: rrs@FreeBSD.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 22:41:08 -0000 On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote: H> On 03/30/15 23:19, Gleb Smirnoff wrote: H> > On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote: H> > M> I get the following panic on current svn ver r280793: H> > M> H> > M> Sat Mar 28 14:41:28 PDT 2015 H> > M> H> > M> FreeBSD/amd64 (pozo.com) (ttyu0) H> > M> H> > M> panic: Invalid CPU in callout 16 H> > H> > The same happened to me in the OFED code. After investigation H> > it appeared that for some unknown reason, the OFED code used H> > /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h, H> > that yield in wrong value passing as parameter. H> > H> > I failed to reproduce the problem. :( So, the fix is a rebuild H> > of kernel. But the right fix is to understand what went wrong H> > in the previous build. H> H> How did you compile the OFED stuff? Did you set the SYSDIR variable when H> building? I just have this in my kernel config: options OFED device mlxen -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Mon Mar 30 23:51: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 6DC70CA3; Mon, 30 Mar 2015 23:51:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 D0B25D0C; Mon, 30 Mar 2015 23:51:52 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2UNplH6073232 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Mar 2015 02:51:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2UNplH6073232 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2UNplpV073231; Tue, 31 Mar 2015 02:51:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Mar 2015 02:51:47 +0300 From: Konstantin Belousov To: Gleb Smirnoff Subject: Re: Panic on current amd64 Message-ID: <20150330235147.GH2379@kib.kiev.ua> References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> <5519CE6C.10600@selasky.org> <20150330224104.GZ64665@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330224104.GZ64665@glebius.int.ru> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Hans Petter Selasky , rrs@FreeBSD.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Mar 2015 23:51:53 -0000 On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote: > On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote: > H> On 03/30/15 23:19, Gleb Smirnoff wrote: > H> > On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote: > H> > M> I get the following panic on current svn ver r280793: > H> > M> > H> > M> Sat Mar 28 14:41:28 PDT 2015 > H> > M> > H> > M> FreeBSD/amd64 (pozo.com) (ttyu0) > H> > M> > H> > M> panic: Invalid CPU in callout 16 > H> > > H> > The same happened to me in the OFED code. After investigation > H> > it appeared that for some unknown reason, the OFED code used > H> > /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h, > H> > that yield in wrong value passing as parameter. > H> > > H> > I failed to reproduce the problem. :( So, the fix is a rebuild > H> > of kernel. But the right fix is to understand what went wrong > H> > in the previous build. > H> > H> How did you compile the OFED stuff? Did you set the SYSDIR variable when > H> building? > > I just have this in my kernel config: > > options OFED > device mlxen Quick grep of the sys/ofed immediately shows the following: sys/ofed/include/linux/wait.h:#include sys/ofed/include/linux/wait.h:#include sys/ofed/include/linux/wait.h:#include sys/ofed/include/linux/wait.h:#include sys/ofed/include/linux/wait.h:#include ys/ofed/include/linux/timer.h:#include sys/ofed/include/linux/types.h:#include sys/ofed/include/linux/types.h:#include sys/ofed/include/linux/types.h:#include sys/ofed/include/linux/types.h:#include and so on. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 00:05:16 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 878B2FC for ; Tue, 31 Mar 2015 00:05:16 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::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 47091E22 for ; Tue, 31 Mar 2015 00:05:16 +0000 (UTC) Received: by iedm5 with SMTP id m5so3362683ied.3 for ; Mon, 30 Mar 2015 17:05:15 -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=K3wZYU47FxAOsqppRHeoIhUcil2J3Zu9Z7ratVwHWxs=; b=QcqpYqoc3rRjzqUf80lmwvsdQ+xLwSh1NUsbGi6eepQAi5kyAZMxm4DY7uIDl23qrZ ZN+Lh5N7ymxXzvG3HkWhHHzl/JqaKTYUAigRNI+HrqkjsDyx7x36u4g9tZJ5ZJ1uUlGn ZZ0LToC5du2yGDvnbu4m8olafXdMZIcrFtkoBy4dKPKu7jvh3aEvMiJ36uc/fCW9BEfd qm8JKf/oM3AQSDmTqrGyiegifORpdnWT2Xfy4y48A2r6tejXkcXE2R2KzRm0ekWftIhf e9PwUP/t4QiiEmW0X9biQzn1vzo7TNnkgea3eWWnVMSkiTQG3TqpPeiag6WKnDjXdzQR rnNg== MIME-Version: 1.0 X-Received: by 10.42.119.202 with SMTP id c10mr64166660icr.4.1427760315232; Mon, 30 Mar 2015 17:05:15 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Mon, 30 Mar 2015 17:05:15 -0700 (PDT) In-Reply-To: References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> <55198A31.4090203@gmail.com> Date: Mon, 30 Mar 2015 17:05:15 -0700 X-Google-Sender-Auth: X8pQjVJbOsa2UfekS_U_eWDzK9A Message-ID: Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT From: Kevin Oberman To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: bsdml , "freebsd-current@freebsd.org" , "wolfgang@lyxys.ka.sub.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 00:05:16 -0000 On Mon, Mar 30, 2015 at 10:49 AM, Garrett Cooper wrote: > > > On Mar 30, 2015, at 10:38, bsdml wrote: > > > > Hey wolfgang, > > > > thanks for getting back to me. Adding hint.ata.1.disabled="1" in > /boot/device.hints indeed did the trick and allowed me to boot both 10.1 > and 11-CURRENT, however this workaround has temporary solved my problem but > brings up to another headache. I have planned to get a bay caddy and swap > the cdrom drive with a 7.200 rpm SATA hdd, but doing this way disabling the > second SATA channel I will be unable to achieve such a thing. > > > > Is there a chance that the bay caddy ATA will work without the need to > disable the second ATA channel? > > Has a bug been filed for this issue? > > It's not been fixed and is pretty much unfixable, but it is also only annoying. The problem shows up when because the SATA-PATA converter shows the second drive as present whether it is or not. This leads the driver to try to probe the drive. The probe of the non-existant fails. (Gee, what a surprise!) If you don't have a second PATA drive in hte system, you need to disable this drive to prevent the probe. If you have a second drive, you only need to enable it and it works. At least my second drive did on my old T42. I can only hope the T40 is the same. IF you can get the PATA caddy, try finding a drive to plug in and see if it works at all. I suspect that it will. Be aware that old PATA drives are getting harder to come by. Most are pretty small, though I did find a 360 GB drive on Amazon. Good luck! -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 00:15: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 427F5611; Tue, 31 Mar 2015 00:15:36 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A660BF3F; Tue, 31 Mar 2015 00:15:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2V0FNE5078507 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Mar 2015 03:15:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2V0FNE5078507 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2V0FNNM078505; Tue, 31 Mar 2015 03:15:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Mar 2015 03:15:23 +0300 From: Konstantin Belousov To: Gleb Smirnoff Subject: Re: Panic on current amd64 Message-ID: <20150331001523.GJ2379@kib.kiev.ua> References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> <5519CE6C.10600@selasky.org> <20150330224104.GZ64665@glebius.int.ru> <20150330235147.GH2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330235147.GH2379@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Hans Petter Selasky , rrs@FreeBSD.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 00:15:36 -0000 On Tue, Mar 31, 2015 at 02:51:47AM +0300, Konstantin Belousov wrote: > On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote: > > On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote: > > H> On 03/30/15 23:19, Gleb Smirnoff wrote: > > H> > On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote: > > H> > M> I get the following panic on current svn ver r280793: > > H> > M> > > H> > M> Sat Mar 28 14:41:28 PDT 2015 > > H> > M> > > H> > M> FreeBSD/amd64 (pozo.com) (ttyu0) > > H> > M> > > H> > M> panic: Invalid CPU in callout 16 > > H> > > > H> > The same happened to me in the OFED code. After investigation > > H> > it appeared that for some unknown reason, the OFED code used > > H> > /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h, > > H> > that yield in wrong value passing as parameter. > > H> > > > H> > I failed to reproduce the problem. :( So, the fix is a rebuild > > H> > of kernel. But the right fix is to understand what went wrong > > H> > in the previous build. > > H> > > H> How did you compile the OFED stuff? Did you set the SYSDIR variable when > > H> building? > > > > I just have this in my kernel config: > > > > options OFED > > device mlxen > > Quick grep of the sys/ofed immediately shows the following: > > sys/ofed/include/linux/wait.h:#include > sys/ofed/include/linux/wait.h:#include > sys/ofed/include/linux/wait.h:#include > sys/ofed/include/linux/wait.h:#include > sys/ofed/include/linux/wait.h:#include > > ys/ofed/include/linux/timer.h:#include > sys/ofed/include/linux/types.h:#include > sys/ofed/include/linux/types.h:#include > sys/ofed/include/linux/types.h:#include > sys/ofed/include/linux/types.h:#include > > and so on. Err, I am sorry, scratch this. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 00:49:18 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 26B8EF8E; Tue, 31 Mar 2015 00:49:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 8C6D32C5; Tue, 31 Mar 2015 00:49:17 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2V0nCZT086383 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Mar 2015 03:49:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2V0nCZT086383 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2V0nCtE086382; Tue, 31 Mar 2015 03:49:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Mar 2015 03:49:12 +0300 From: Konstantin Belousov To: "Kenneth D. Merry" Subject: Re: async pass(4) patches available Message-ID: <20150331004912.GM2379@kib.kiev.ua> References: <20150330222358.GA46342@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330222358.GA46342@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 00:49:18 -0000 On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > Kernel memory for data transferred via the queued interface is > allocated from the zone allocator in MAXPHYS sized chunks, and user > data is copied in and out. This is likely faster than the > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > configurations with many processors (there are more TLB shootdowns > caused by the mapping/unmapping operation) but may not be as fast > as running with unmapped I/O. cam_periph_mapmem() uses vmapbuf() with an indicator to always map the user pages mostly because I do not know CAM code and wanted to make the least intrusive changes there. It is not inherently impossible to pass unmapped pages down from cam_periph_mapmem(), but might require some more plumbing for driver to indicate that it is acceptable. > > The new memory handling model for user requests also allows > applications to send CCBs with request sizes that are larger than > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > size listed by the SIM driver in the maxio field in the Path > Inquiry (XPT_PATH_INQ) CCB. > > There are some things things would be good to add: > > 1. Come up with a way to do unmapped I/O on multiple buffers. > Currently the unmapped I/O interface operates on a struct bio, > which includes only one address and length. It would be nice > to be able to send an unmapped scatter/gather list down to > busdma. This would allow eliminating the copy we currently do > for data. Only because nothing more was needed. The struct bio does not use address/length pair when unmapped, it passes the list of physical pages, see bio_ma array pointer. It is indeed taylored to be a pointer to struct buf' b_pages, but it does not have to be. The busdma unmapped non-specific interface is bus_dmamap_load_ma(), which again takes array of pages to load. If you want some additional helper, suitable for your goals, please provide the desired interface definition. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 07:10: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 2263DB58; Tue, 31 Mar 2015 07:10:36 +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 D2812228; Tue, 31 Mar 2015 07:10:35 +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 D92A11FE023; Tue, 31 Mar 2015 09:10:31 +0200 (CEST) Message-ID: <551A4895.6090500@selasky.org> Date: Tue, 31 Mar 2015 09:11:17 +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: Konstantin Belousov , Gleb Smirnoff Subject: Re: Panic on current amd64 References: <201503282202.t2SM2cAb004263@pozo.com> <20150330211943.GV64665@FreeBSD.org> <5519CE6C.10600@selasky.org> <20150330224104.GZ64665@glebius.int.ru> <20150330235147.GH2379@kib.kiev.ua> <20150331001523.GJ2379@kib.kiev.ua> In-Reply-To: <20150331001523.GJ2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: rrs@FreeBSD.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 07:10:36 -0000 On 03/31/15 02:15, Konstantin Belousov wrote: > On Tue, Mar 31, 2015 at 02:51:47AM +0300, Konstantin Belousov wrote: >> On Tue, Mar 31, 2015 at 01:41:04AM +0300, Gleb Smirnoff wrote: >>> On Tue, Mar 31, 2015 at 12:30:04AM +0200, Hans Petter Selasky wrote: >>> H> On 03/30/15 23:19, Gleb Smirnoff wrote: >>> H> > On Sat, Mar 28, 2015 at 03:02:28PM -0700, Manfred Antar wrote: >>> H> > M> I get the following panic on current svn ver r280793: >>> H> > M> >>> H> > M> Sat Mar 28 14:41:28 PDT 2015 >>> H> > M> >>> H> > M> FreeBSD/amd64 (pozo.com) (ttyu0) >>> H> > M> >>> H> > M> panic: Invalid CPU in callout 16 >>> H> > >>> H> > The same happened to me in the OFED code. After investigation >>> H> > it appeared that for some unknown reason, the OFED code used >>> H> > /usr/include/sys/callout.h instead of SYSDIR/sys/callout.h, >>> H> > that yield in wrong value passing as parameter. >>> H> > >>> H> > I failed to reproduce the problem. :( So, the fix is a rebuild >>> H> > of kernel. But the right fix is to understand what went wrong >>> H> > in the previous build. >>> H> >>> H> How did you compile the OFED stuff? Did you set the SYSDIR variable when >>> H> building? >>> >>> I just have this in my kernel config: >>> >>> options OFED >>> device mlxen >> >> Quick grep of the sys/ofed immediately shows the following: >> >> sys/ofed/include/linux/wait.h:#include >> sys/ofed/include/linux/wait.h:#include >> sys/ofed/include/linux/wait.h:#include >> sys/ofed/include/linux/wait.h:#include >> sys/ofed/include/linux/wait.h:#include >> >> ys/ofed/include/linux/timer.h:#include >> sys/ofed/include/linux/types.h:#include >> sys/ofed/include/linux/types.h:#include >> sys/ofed/include/linux/types.h:#include >> sys/ofed/include/linux/types.h:#include >> >> and so on. > > Err, I am sorry, scratch this. Hi, Could you: cd sys/amd64/conf config YOURCONFIG cd ../compile/YOURCONFIG less Makefile and see if it includes something outside /sys ? OFED uses its own CFLAGS and check if some include directives have space after the "-Ixxxspace", because then this simple flag conversion will fail: OFEDCFLAGS= ${CFLAGS:N-I*} ${OFEDINCLUDES} ${CFLAGS:M-I*} ${OFEDNOERR} Thank you! --HPS From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 08:54:37 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 34684F6F for ; Tue, 31 Mar 2015 08:54:37 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCE07FD4 for ; Tue, 31 Mar 2015 08:54:36 +0000 (UTC) Received: by widdi4 with SMTP id di4so879842wid.0 for ; Tue, 31 Mar 2015 01:54:35 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cYJK+zg1A0hmNMJyk06LBjhnMcF1XfbWxVdiAnz7rNA=; b=juwKgtlySZb0b5MGoVtwsxQ4H2yGhk9ql1cRh/y/iyXHrnN5MUijk0qfYz5GJdMJLE NJix1uvaeYi4gyDUkckt8LUEisVIpA/yjEEOJI7QBFs8I+vtGI5uU/BGFwQuIloTsP69 IOKrn57AurCrFyRssxNB+aco9s+OiDLXDSGmuTZYokWc/4MrjbujyXi1QUU79NCN11A7 aOuhZ6g68uu+mkF2GcySZfcpEalSUs0y7U1oglrU2piI+WLi+Vpd4SC/A564Op0SNqA2 dVTvGU9lyP1LEUmNSy3TDa8EwxT3gRWdKoopToUV5w06JHUsicB+tTLXaTncU/PQHCbg zXpw== X-Received: by 10.194.77.230 with SMTP id v6mr73037791wjw.25.1427792075256; Tue, 31 Mar 2015 01:54:35 -0700 (PDT) Received: from [192.168.1.7] (host77-84-dynamic.23-79-r.retail.telecomitalia.it. [79.23.84.77]) by mx.google.com with ESMTPSA id l10sm19359098wje.15.2015.03.31.01.54.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 01:54:34 -0700 (PDT) Message-ID: <551A60CE.3030908@gmail.com> Date: Tue, 31 Mar 2015 10:54:38 +0200 From: Pietro Sammarco User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org. Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> <551990F6.6070202@gmail.com> <5519A650.1020507@multiplay.co.uk> In-Reply-To: <5519A650.1020507@multiplay.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: killing@multiplay.co.uk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 08:54:37 -0000 Currently the cdrom drive and yes it works fine till 10 with the legacy ATA stack. Verbose boot doesn't give out any errors or logs beside what's shown in the picture I have attached with the first email. Regards, Pietro Sammarco On 30/03/2015 21:38, Steven Hartland wrote: > Is there anything connected to the second channel, if so what. > > Was this working in a previous version and if so which one and what > was the verbose boot log from it? > > On 30/03/2015 19:07, bsdml wrote: >> Hello Kevin, >> >> thanks for your clarification. Unfortunately I wasn't aware that the >> T40 and *4's line used a SATA-PATA convertor and especially that was >> going to clash with the new ATA stack in FreeBSD. Either OpenBSD and >> NetBSD do work out of the box without any hassle, however I'd still >> prefer to use FreeBSD on it as I have been using FreeBSD for about 8 >> years now and I am very comfortable with it. >> >> The question at this point is, is there any hope to see this issue >> resolved in the future? Or will I have to give up to the second ATA >> channel in order to use FreeBSD? >> >> Regards, >> Pietro Sammarco >> >> On 30/03/2015 06:17, Kevin Oberman wrote: >>> On Sun, Mar 29, 2015 at 2:27 AM, Wolfgang Zenker >>> > wrote: >>> >>> Hi, >>> >>> * bsdml > >>> [150329 01:34]: >>> > since I tried to install FreeBSD 10.1 on my recently purchased >>> T40 I got >>> > stuck at this annoying bootloop that says >>> > "ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM >>> status: >>> > Command timeout". I have also tried latest 11-CURRENT snapshot >>> and it >>> > did not make any difference at all, it is affected from the same >>> exact >>> > bootloop. >>> > [..] >>> > It seems like there might be an issue with the CAM ATA stack >>> that is >>> > clashing with the PATA controller on my T40. >>> >>> I had the same problem on an ancient T42p. In my case, disabling >>> the >>> second ata channel allowed me to boot. >>> >>> I added the following line to /boot/device.hints: >>> hint.ata.1.disabled="1" >>> >>> >>> This is an annoying side-effect of the brain-dead SATA-PATA >>> converter in that generation of ThinkPads. The Intel ICH6 chipset is >>> SATA, but, for reasons known ot IBM/Lenovo, the systems used PATA >>> drives! So they has a SATA-PATA converter built in that screwed up a >>> LOT of things, mostly compromising performance and generating >>> assorted log entries. Looks like that also is broken in modern ATA >>> support if a drive is not present. >>> >>> This was always my biggest complaint with this laptop (T42) which I >>> used for several years until I retired and returned to so it could >>> be excessed legally as it was government property (and, I didn't >>> really want it, even if I could have kept it). Not an awful system, >>> but this one issue was really annoying to me. >>> -- >>> Kevin Oberman, Network Engineer, Retired >>> E-mail: rkoberman@gmail.com >> >> _______________________________________________ >> 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 Tue Mar 31 11:06: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 747D6713 for ; Tue, 31 Mar 2015 11:06:36 +0000 (UTC) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 07DD0FEC for ; Tue, 31 Mar 2015 11:06:35 +0000 (UTC) Received: by wixo5 with SMTP id o5so9244877wix.1 for ; Tue, 31 Mar 2015 04:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZFp+henRE13nudRnRsDqrLrAub/l8+CyMNwV+BAO3NY=; b=YV7YKqNKla4xNWNzbRS5cxggCLNAha6WNpmJ88qN04XhO6XDrn2RiZ16EXR6Gqj2K6 BO9XhrBmuVvms31JZjr9bwfEzDATcifayARt9pGWHpKifBnX+YtCPcBCe4yWGBXSJKdv tpQe5pCSOUGP1mLh6B8OVjVKz4vRuOrpcadTslFHgBj8AjrugOva3ffgoWGsiOCtfHIb vn9ix3FarCNkSEMVLzBtyGEUyLC2dVJ6QwfeWVmTvK+0emriIsBKQ+vHxZGWLN4iZ8Po yBlmtpD7ccleAz13fU7R62iGlw7om8C2Bb7S3jlAPPti/JXhtlG3ggKUguyc1Sb8iys6 2qAA== X-Gm-Message-State: ALoCoQnhqN50OriitR6pps24B1MlahS6UCqJyOLmMx/w62UG1di3GtjO5nDlSjglU5ToHjNAhFGR X-Received: by 10.181.8.76 with SMTP id di12mr4481647wid.75.1427799988184; Tue, 31 Mar 2015 04:06:28 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id hq4sm14609634wib.0.2015.03.31.04.06.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 04:06:27 -0700 (PDT) Message-ID: <551A7FBD.906@multiplay.co.uk> Date: Tue, 31 Mar 2015 12:06:37 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Pietro Sammarco , freebsd-current@freebsd.org. Subject: Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT References: <551748A4.1090303@gmail.com> <20150329092713.GA69272@lyxys.ka.sub.org> <551990F6.6070202@gmail.com> <5519A650.1020507@multiplay.co.uk> <551A60CE.3030908@gmail.com> In-Reply-To: <551A60CE.3030908@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 11:06:36 -0000 Verbose boot of the working OS version was what I was after, which should provide details of what its detecting ;-) Also a camcontrol identify of the cdrom from the working version may also be useful On 31/03/2015 09:54, Pietro Sammarco wrote: > Currently the cdrom drive and yes it works fine till 10 with the > legacy ATA stack. Verbose boot doesn't give out any errors or logs > beside what's shown in the picture I have attached with the first email. From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 06:02: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 74348763; Tue, 31 Mar 2015 06:02:56 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1F3A9B; Tue, 31 Mar 2015 06:02:56 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 598D8B60; Tue, 31 Mar 2015 06:02:54 +0000 (UTC) Date: Tue, 31 Mar 2015 06:02:37 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, markj@FreeBSD.org, adrian@FreeBSD.org, emaste@FreeBSD.org, amdmi3@FreeBSD.org, gjb@FreeBSD.org, dim@FreeBSD.org, jilles@FreeBSD.org, glebius@FreeBSD.org, eadler@FreeBSD.org, zbb@FreeBSD.org, royger@FreeBSD.org, jhb@FreeBSD.org, cy@FreeBSD.org, mav@FreeBSD.org, np@FreeBSD.org, dumbbell@FreeBSD.org, kib@FreeBSD.org, pfg@FreeBSD.org, rrs@FreeBSD.org, bdrewery@FreeBSD.org, cperciva@FreeBSD.org, andrew@FreeBSD.org Message-ID: <1690585634.1.1427781771177.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2610 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: Tue, 31 Mar 2015 11:28:30 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 06:02:56 -0000 See Changes: [markj] Fix a misparenthesization that could cause a crash if TERM is not s= et. Reported by:=09Coverity (internal) MFC after:=093 days Sponsored by:=09EMC / Isilon Storage Division [cperciva] Partially revert r278118 now that the required logic for decidin= g whether freebsd-update can be useful has moved into the firstboot_freebsd_update script. [kib] Provide workaround for a performance issue with the popcnt instructio= n on Intel processors. Clear spurious dependency by explicitely xoring the destination register of popcnt. Use bitcount64() instead of re-implementing SWAR locally, for processors without popcnt instruction. Reviewed by:=09jhb Discussed with:=09jilles (previous version) Sponsored by:=09The FreeBSD Foundation [cperciva] Add bits for building EC2 disk images. Make logic for uploading= these to create EC2 AMIs will come in a later commit. [np] cxgbe/tom: return rx credits promptly if the socket buffer's low water mark cannot be reached because the window advertised to the peer isn't wide enough. While here, tweak the normal credit return too. MFC after:=091 month [rrs] Adopt jhb's suggested changes, updated comments and callout_migration= () moving to kern/kern_timeout.c This does *not* address his -1 -> NOCPU comment. Sponsored by:=09Netflix Inc. [rrs] Change the c_iflags and c_flags fields to short rather then int. This allows us to keep the KPI the same. Discussed and brain-stormed with imp (thanks for the help Warner!) Sponsored by:=09Netflix Inc. [bdrewery] Fix --one-file-system to include the directory encountered rathe= r than excluding it. This was broken in 3.0.4 (r238856). Obtained from:=09https://github.com/libarchive/libarchive/commit/fa9e61 MFC after:=093 days Sponsored by:=09EMC / Isilon Storage Division [glebius] Catch up on r271387 and remove unused parameter from VOP_GETPAGES_ASYNC(). [andrew] Restore setting cpufuncs on arm1176, it was removed by accident wi= th the arm1136 code. Reviewed by:=09ian [dim] Add llvm patch corresponding to r280865. [jhb] Wait 100 microseconds for a local APIC to dispatch each startup-relat= ed IPI rather than 20. The MP 1.4 specification states in Appendix B.2: "A period of 20 microseconds should be sufficient for IPI dispatch to complete under normal operating conditions". (Note that this appears to be separate from the 10 millisecond (INIT) and 200 microsecond (STARTUP) waits after the IPIs are dispatched.) The Intel SDM is silent on this issue as far as I can tell. At least some hardware requires 60 microseconds as noted in the PR, so bump this to 100 to be on the safe side. PR:=09=09197756 Reported by:=09zaphod@berentweb.com MFC after:=091 week [emaste] llvm: Backport upstream r229195 to fix arm64 TLS relocations As is described at http://llvm.org/bugs/show_bug.cgi?id=3D22408, the GNU linkers ld.bfd and ld.gold currently only support a subset of the whole range of AArch64 ELF TLS relocations. Furthermore, they assume that some of the code sequences to access thread-local variables are produced in a very specific sequence. When the sequence is not as the linker expects, it can silently mis-relaxe/mis-optimize the instructions. Even if that wouldn't be the case, it's good to produce the exact sequence, as that ensures that linkers can perform optimizing relaxations. This patch: * implements support for 16MiB TLS area size instead of 4GiB TLS area size. Ideally clang would grow an -mtls-size option to allow support for both, but that's not part of this patch. * by default doesn't produce local dynamic access patterns, as even modern ld.bfd and ld.gold linkers do not support the associated relocations. An option (-aarch64-elf-ldtls-generation) is added to enable generation of local dynamic code sequence, but is off by default. * makes sure that the exact expected code sequence for local dynamic and general dynamic accesses is produced, by making use of a new pseudo instruction. The patch also removes two (AArch64ISD::TLSDESC_BLR, AArch64ISD::TLSDESC_CALL) pre-existing AArch64-specific pseudo SDNode instructions that are superseded by the new one (TLSDESC_CALLSEQ). Submitted by:=09Kristof Beyls Differential Revision:=09https://reviews.freebsd.org/D2175 [dim] Pull in r233552 from upstream libc++ trunk (by Eric Fiselier): [libcxx] Fix PR22771 - Support access control SFINAE in the library version of is_convertible. Summary: Currently the conversion check does not take place in a context where access control SFINAE is applied. This patch changes the context of the test expression so that SFINAE occurs if access control does not permit the conversion. Related bug: https://llvm.org/bugs/show_bug.cgi?id=3D22771 Reviewers: mclow.lists, rsmith, dim Reviewed By: dim Subscribers: dim, rodrigc, emaste, cfe-commits Differential Revision: http://reviews.llvm.org/D8461 This fixes building clang, and other programs using libc++, with newer versions of gcc (specifically, gcc 4.8 and higher). Reported by:=09rodrigc MFC after:=091 week [andrew] Add pthread_md.h for arm64. Differential Revision:=09https://reviews.freebsd.org/D2137 Reviewed by:=09kib Sponsored by:=09The FreeBSD Foundation [gjb] Sigh. s/AutoSize/Growfs/ following upstream commit r761. MFH:=09=093 days Sponsored by:=09The FreeBSD Foundation [emaste] Switch to ELF toolchain readelf(1) ELF toolchain readelf lacked some functionality at the time other tools (like size, strip, nm, etc.) were switched over to the ELF toolchain versions. That has been addressed as of the last update, so we can add it to the list. PR:=09=09198950 [exp-run] Reviewed by:=09bapt, imp, rpaulo Relnotes:=09yes Sponsored by:=09The FreeBSD Foundation Differential Revision:=09https://reviews.freebsd.org/D2156 [emaste] Fill out arm64 dynamic relocation #defines Sponsored by:=09The FreeBSD Foundation [emaste] Correct mrs_fpcr and mrs_fpsr macros in arm64 fenv.h Submitted by:=09andrew Sponsored by:=09The FreeBSD Foundation [emaste] compiler-rt: Build additional quad precision floating point builti= ns These are needed for arm64 Sponsored by:=09The FreeBSD Foundation Differential Revision:=09https://reviews.freebsd.org/D2160 [amdmi3] - Remove more files when MK_INET6 =3D=3D no MFC after:=091 week Reviewed by:=09ngie Approved by:=09ngie Differential Revision:=09D1600 [amdmi3] - Remove more files when MK_FORTH =3D=3D no MFC after:=091 week Reviewed by:=09ngie Approved by:=09ngie Differential Revision:=09D1600 [mav] Periodically wake up threads waiting for vmem(9) resources, so they c= ould ask for resource reclamation again. This is kind of dirty hack, but as last resort this is better then stuck indefinitely because of KVA fragmentation, waiting until some random event free something sufficient. OpenSolaris also has this hack in its vmem(9). MFC after:=092 weeks [cy] MFV ntp 4.2.8p1 (r258945, r275970, r276091, r276092, r276093, r278284) Thanks to roberto for providing pointers to wedge this into HEAD. Approved by:=09roberto [zbb] Fix bug in xrefinfo_find() for 64-bit platforms uintptr_t may be 64-bit on some platforms, therefore when finding xrefinfo by pointer to device the high word is being cut off due to cast to phandle_t which is 32-bit long by definition. Due to that we loose the high word of the address to compare with xi->dev's address. To fix that, first argument of xrefinfo_find() is extended to uintptr_t and is being cast to appropriate type (phandle_t) when compared. Submitted by: Zbigniew Bodek Reviewed by: nwhitehorn Obtained from: Semihalf [andrew] Remove support for CPU_XSCALE_80200. None of our configs support i= t, and there wasn;t an option to enable it. While here remove a check for CPU_ARM10 being defined as it has also been removed. [cperciva] Improve check for whether ${DESTDIR}/dev is mounted. Submitted by:=09gcooper [eadler] Add some additional quirks for various Western Digital Caviar MHDD= s Submitted by:=09Jeremy Chadwick PR:=09=09188685 MFC After:=091 month [eadler] And it turns out someone beat me to it.... PR:=09=09199013 [eadler] Add support for "MosChip MCS9922 PCIe to Peripheral Controller" to= uart Submitted by:=09 PR:=09=09199013 MFC After:=091 month [andrew] Remove support for CPU_FA626TE. It's unused by any of our kernel c= onfigs. [andrew] Only build cpufunc_asm_armv4.S when needed. [cperciva] Clean up filesystem unmounting in vmimage builds: * Remove vm_umount_base function which is currently unused. * Add umount_loop function which loops attempting to unmount one filesystem= . * Replace calls to umount with calls to umount_loop. * Don't attempt to unmount ${DESTDIR}/dev if it isn't mounted. The looping is necessary because sometimes umount fails due to filesystems being busy. The most common cause of such busyness is periodic(8) jobs running `find / ...`. Reviewed by:=09gjb [royger] xen: add a handler for the debug interrupt Handle the VIRQ_DEBUG signal and print a stack trace of each vCPU on the Xe= n console. This is only used for debug purposes and is triggered by the administrator of the Xen host. Sponsored by: Citrix Systems R&D MFC after: 1 week [markj] Fix ping(8) and ping6(8) usage in a couple of ip provider tests, an= d update expected test output to reflect differences in default TTL and payload length. MFC after:=091 week [markj] Fix ping(8) usage in funcs/tst.system.d so that the test actually c= ompletes. MFC after:=091 week [markj] Replace dtest.pl, the upstream DTrace test suite harness, with a sh= ell script. This reimplementation is much simpler than dtest.pl and is more amenable to being run under Kyua - dtest.pl writes error output to a temporary directory that is deleted when the run finishes, making it hard to debug test failures. This change also removes the test suite's dependenc= y on perl. [markj] Import a missing piece of commit b8fac8e162eda7e98d from illumos-ga= te. This adds an upper bound, dtrace_ustackdepth_max, to the number of frames traversed when computing the userland stack depth. Some programs - notably firefox - are otherwise able to trigger an infinite loop in dtrace_getustack_common(), causing a panic. MFC after:=091 week [andrew] arm11_sleep is no longer needed, remove it. [andrew] pj4b_config and pj4bv7_setup are only used when CPU_MV_PJ4B is def= ined. [andrew] Build the cpufunc_asm_* files based on the cpu type, not which con= fig file we happen to be building. [jilles] wordexp(): Add testcase for non-default IFS in environment. The non-default IFS is expected to be used. MFC after:=091 week [adrian] Add initial support for the HAL channel survey support to the AR93= 00 HAL. This is used by the 'athsurvey' command to print out channel survey statistics - % busy times transmit, receive and airtime. It's as buggy and incomplete as the rest of the HAL survey support - notably, tying into the ANI code to read channel stats and occasionally getting garbage counters isn't very nice. It also doesn't (yet!) get channel survey information during a scan. But it's good enough for basic air-time debugging, which is why I'm committing it in this state. Tested: * AR9380, STA mode [adrian] Move the HAL channel survey support out to be in the top-level HAL= , rathe than private in each HAL module. Whilst here, modify ath_hal_private to always have the per-channel noisefloor stats, rather than conditionally. This just makes life easier in general (no strange ABI differences between different HAL compile options.) Add a couple of methods (clear/reset, add) rather than using hand-rolled versions of things. [adrian] Add a new field to HAL_ANISTATS - the extension channel busy count= . This is only used by the AR9300 HAL for now - but just be careful if you decide to recompile the kernel with NO_CLEAN=3D1. [andrew] Remove cpufunc_asm_arm11.S from the ARMv7 configs, it's not used. [adrian] Fix more ticks wrapping bugs exposed by the ticks wrapping bug che= ck. This symptom is "calibrations don't ever run", which may cause some pretty spectacularly bad behaviour in noisy environments or with longer uptimes. Thanks to dtrace to make it easy to check if specific non-inlined functions are getting called by things like the ANI and calibration HAL methods. Grr. Tested: * AR9380, STA mode [andrew] Remove arm1136 support. We don't have any configs that use it, and= I don't expect us to add support for any more arm11 SoCs. [andrew] Remove the bootconfig parsing. We never used it and always passed = either an empty string or NULL to the setup functions that called into it. [mav] Some cosmetic polishing. No functional change. MFC after:=091 week [andrew] We only need cpufunc_asm_arm11.S on bcm2835, not bcm2836 [pfg] Clean some spaces vs tabs. No, this file doesn't conform with KNF at all. [kib] Formatting changes to the pthread_testcancel(3). Use list for the cancellation points enumeration. Move notes about functions into the list inline. The discussion of the idiomatic use of cancellation facilities does not belong to RETURN VALUES section, move it to NOTES. Sponsored by:=09The FreeBSD Foundation MFC after:=092 weeks [kib] Make kevent(2) a cancellation point. Note that to cancel blocked kevent(2) call, changelist must be empty, since we cannot cancel a call which already made changes to the process state. And in reverse, call which only makes changes to the kqueue state, without waiting for an event, is not cancellable. This makes a natural usage model to migrate kqueue loop to support cancellation, where existing single kevent(2) call must be split into two: first uncancellable update of kqueue, then cancellable wait for events. Note that this is ABI-incompatible change, but it is believed that there is no cancel-safe code that relies on kevent(2) not being a cancellation point. Option to preserve the ABI would be to keep kevent(2) as is, but add new call with flags to specify cancellation behaviour, which only value seems to add complications. Suggested and reviewed by:=09jilles Sponsored by:=09The FreeBSD Foundation MFC after:=092 weeks [andrew] Remove ARM9_CACHE_WRITE_THROUGH, none of our configs define it. [kib] Change compiler setting to make default visibility of the symbols for rtld on x86 to be hidden. This is a micro-optimization, which allows intrinsic references inside rtld to be handled without indirection through PLT. The visibility of rtld symbols for other objects in the symbol namespace is controlled by a version script. Reviewed by:=09kan, jilles Sponsored by:=09The FreeBSD Foundation MFC after:=092 weeks [andrew] Remove the unused armv5 cpufunc code. [dumbbell] drm: Import Linux commit 9bc3cd5673d84d29272fa7181a4dfca83cbb48c= 1 Author: Ville Syrj=C3=A4l=C3=A4 Date: Fri May 31 12:17:08 2013 +0000 drm: Sort connector modes based on vrefresh Keeping the modes sorted by vrefresh before the pixel clock makes the mode list somehow more pleasing to the eye. Signed-off-by: Ville Syrj=C3=A4l=C3=A4 Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie PR:=09=09198936 Obtained from:=09Linux MFC after:=091 month MFC with:=09r280183 [andrew] Remove unused cpufunc arm11 and armv6 code. While here only define= the remaining functions in the context we use them in. [andrew] We don't use cpufunc_asm_armv5.S in any of these configs, remove i= t. ------------------------------------------ [...truncated 196029 lines...] ^ :380:5: error: use of undeclared identifier = 'ip_file'; did you mean 'ip_fil'? ip_file->err_col_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :670:13: error: use of undeclared identifier= 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "statsdir remote configura= tion ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :724:13: error: use of undeclared identifier= 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen file remote confi= g ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :733:13: error: use of undeclared identifier= 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen type remote confi= g ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :748:13: error: use of undeclared identifier= 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :794:9: error: use of undeclared identifier = 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :802:9: error: use of undeclared identifier = 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :810:9: error: use of undeclared identifier = 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :825:5: error: use of undeclared identifier = 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :840:5: error: use of undeclared identifier = 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :849:45: error: use of undeclared identifier= 'ip_file'; did you mean 'ip_fil'? NULL, NULL, yystack.l_mark[0].Int_fifo, ip_= file->line_no); ^~~= ~~~~ ip_= fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ --- usr.bin.all__D --- --- all_subdir_svn --- --- util.o --- --- usr.sbin.all__D --- :1059:13: error: use of undeclared identifie= r 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err_str); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ --- usr.bin.all__D --- cc -O2 -pipe -I -= I -I -I -I -I -I -I -I -std=3Dgnu= 99 -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int= -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wn= o-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unuse= d-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -W= no-parentheses -Qunused-arguments -c -o util.o --- usr.sbin.all__D --- :1151:13: error: use of undeclared identifie= r 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, error_text); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1157:13: error: use of undeclared identifie= r 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "remote includefile ignore= d"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1169:6: error: use of undeclared identifier= 'ip_file'; did you mean 'ip_fil'? ip_file =3D fp[++curr_include_level= ]; ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1445:13: error: use of undeclared identifie= r 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "Integer value is not bool= ean (0 or 1). Assuming 1"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ 3 warnings and 18 errors generated. *** [ntp_parser.o] Error code 1 make[5]: stopped in 1 error make[5]: stopped in --- usr.bin.all__D --- --- all_subdir_tty --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_tty] Error code 2 make[3]: stopped in --- usr.sbin.all__D --- *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ntp] Error code 2 make[3]: stopped in --- usr.bin.all__D --- --- all_subdir_svn --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.all] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_svn] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in --- usr.sbin.all__D --- --- all_subdir_sendmail --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_sendmail] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] 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 Tue Mar 31 07:54: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 AAB7BCE3; Tue, 31 Mar 2015 07:54:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 84FA4934; Tue, 31 Mar 2015 07:54:57 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 51BF1B9F; Tue, 31 Mar 2015 07:54:56 +0000 (UTC) Date: Tue, 31 Mar 2015 07:54:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, markj@FreeBSD.org, adrian@FreeBSD.org, emaste@FreeBSD.org, amdmi3@FreeBSD.org, gjb@FreeBSD.org, dim@FreeBSD.org, jilles@FreeBSD.org, glebius@FreeBSD.org, eadler@FreeBSD.org, zbb@FreeBSD.org, royger@FreeBSD.org, jhb@FreeBSD.org, np@FreeBSD.org, mav@FreeBSD.org, cy@FreeBSD.org, dumbbell@FreeBSD.org, kib@FreeBSD.org, pfg@FreeBSD.org, jhibbits@FreeBSD.org, rrs@FreeBSD.org, bdrewery@FreeBSD.org, andrew@FreeBSD.org, cperciva@FreeBSD.org Message-ID: <1714267852.3.1427788496739.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1690585634.1.1427781771177.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1690585634.1.1427781771177.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2611 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: FAILURE X-Mailman-Approved-At: Tue, 31 Mar 2015 11:28:38 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 07:54:58 -0000 See Changes: [jhibbits] CCSRBAR_VA is mpc85xx-specific, so add guards, and include the proper header file for it. MFC after: 1 month [jhibbits] machine/fdt.h no longer exists for powerpc. MFC after: 1 month [amdmi3] - Remove more files when MK_ZONEINFO == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 [amdmi3] - Remove more files when MK_TESTS_SUPPORT == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 [amdmi3] - Remove more files when MK_LEGACY_CONSOLE == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 [amdmi3] - Remove more files when MK_KERBEROS_SUPPORT == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 [amdmi3] - Remove more files when MK_KDUMP == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 [amdmi3] - Remove more files when MK_JAIL == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 [cperciva] It would help if I committed the right patch... [amdmi3] - Remove more files when MK_CASPER == no MFC after: 1 week Reviewed by: ngie Approved by: ngie Differential Revision: D1600 ------------------------------------------ [...truncated 191296 lines...] # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :379:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->err_line_no, ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :380:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->err_col_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :670:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "statsdir remote configuration ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :724:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen file remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :733:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen type remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :748:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :794:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :802:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :810:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :825:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :840:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :849:45: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? NULL, NULL, yystack.l_mark[0].Int_fifo, ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1059:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err_str); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1151:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, error_text); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1157:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "remote includefile ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1169:6: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file = fp[++curr_include_level]; ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1445:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "Integer value is not boolean (0 or 1). Assuming 1"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ 3 warnings and 18 errors generated. *** [ntp_parser.o] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ntp] Error code 2 make[3]: stopped in --- all_subdir_sendmail --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_sendmail] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.all] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_svn] Error code 2 make[3]: stopped in --- all_subdir_truss --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_truss] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] 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 Tue Mar 31 11:51:16 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 0ACEB2D0; Tue, 31 Mar 2015 11:51:16 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D323E687; Tue, 31 Mar 2015 11:51:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4031FBEB; Tue, 31 Mar 2015 11:51:13 +0000 (UTC) Date: Tue, 31 Mar 2015 11:51:00 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, markj@FreeBSD.org, adrian@FreeBSD.org, emaste@FreeBSD.org, amdmi3@FreeBSD.org, gjb@FreeBSD.org, dim@FreeBSD.org, jilles@FreeBSD.org, glebius@FreeBSD.org, eadler@FreeBSD.org, zbb@FreeBSD.org, royger@FreeBSD.org, jhb@FreeBSD.org, np@FreeBSD.org, mav@FreeBSD.org, cy@FreeBSD.org, dumbbell@FreeBSD.org, kib@FreeBSD.org, ngie@FreeBSD.org, pfg@FreeBSD.org, jhibbits@FreeBSD.org, rrs@FreeBSD.org, bdrewery@FreeBSD.org, andrew@FreeBSD.org, cperciva@FreeBSD.org Message-ID: <1452708997.4.1427802672681.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1714267852.3.1427788496739.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1714267852.3.1427788496739.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2612 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: FAILURE X-Mailman-Approved-At: Tue, 31 Mar 2015 11:55:08 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 11:51:16 -0000 See Changes: [ngie] - Fix -Wsign issue - Bump up to WARNS=6 [ngie] Minor cleanup before converting to ATF testcases - Remove blank (tab-only) lines. - Fix -Wunused warnings. - Bump up to WARNS= 6 [ngie] Cleanup and do minor refactoring before converting testcases to ATF - Convert errx(-1, ..) to errx(1, ..) - Move the aio(4) checks to a single function (aio_available); use modfind(2) instead of depending on SIGSYS (doesn't work when aio(4) support is missing, not documented in the aio syscall manpages). - Use aio_available liberally in the testcase functions - Use mkstemp(3) + unlink(2) instead of mktemp(3) - Fix some -Wunused warnings - Bump WARNS to 6 MFC after: 1 week Submitted by: mjohnston [*] Sponsored by: EMC / Isilon Storage Division ------------------------------------------ [...truncated 193766 lines...] ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :670:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "statsdir remote configuration ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :724:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen file remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :733:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen type remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :748:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :794:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :802:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :810:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :825:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :840:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :849:45: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? NULL, NULL, yystack.l_mark[0].Int_fifo, ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1059:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err_str); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1151:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, error_text); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ --- usr.bin.all__D --- --- all_subdir_truss --- --- amd64-fbsd.o --- --- usr.sbin.all__D --- :1157:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "remote includefile ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ --- usr.bin.all__D --- cc -O2 -pipe -I -I. -std=gnu99 -fstack-protector -Wsystem-headers -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 -o amd64-fbsd.o --- usr.sbin.all__D --- :1169:6: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file = fp[++curr_include_level]; ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1445:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "Integer value is not boolean (0 or 1). Assuming 1"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ 3 warnings and 18 errors generated. *** [ntp_parser.o] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ntp] Error code 2 make[3]: stopped in --- usr.bin.all__D --- In file included from :65: ./syscalls.h:9:13: warning: no previous extern declaration for non-static variable 'syscallnames' [-Wmissing-variable-declarations] const char *syscallnames[] = { ^ 1 warning generated. A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_truss] Error code 2 make[3]: stopped in --- all_subdir_svn --- 1 warning generated. A failure has been detected in another branch of the parallel make make[6]: stopped in *** [_sub.all] Error code 2 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_svn] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in --- usr.sbin.all__D --- --- all_subdir_sendmail --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_sendmail] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] 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 Tue Mar 31 13:02: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 D46D1B67 for ; Tue, 31 Mar 2015 13:02:31 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::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 97F0CF46 for ; Tue, 31 Mar 2015 13:02:31 +0000 (UTC) Received: by ierf6 with SMTP id f6so14716431ier.2 for ; Tue, 31 Mar 2015 06:02:31 -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=ku8lQ8F6EFfOrpuZEcjGp2SKsyhlvCesR6/Fizli6D4=; b=gMt+6msCbKr8ts9EM/usQWS8AxXSr6/2MJU/W5ePs3RNwktG10wFFahEKDMTpcq/Yh YzHXZIGu2DzlI/wCwtMB9GUrf+SLe9AdpK+DWqWcCmapySpz2QtwiNRRPsycuzWxW8j8 bBi0mqQsnNB6NdyuzjRTc3y+RC5Qjk4z3J1ZRNdDr9QtJddqUJXLJhSquyUm88bCQCTM 9nz7hFsY3mNzl7Ybmz3zi9ip/UyCDrdWc0fZwlhdupnfHDbq1h5dck/p3L4IuS9Mom1u 9DYRFZqskh/Ugx+5x17cK3gMhIeH/xKKrWkn+iWwtW2i1oAt84MP6jmgg7UoAF33sC83 Payw== MIME-Version: 1.0 X-Received: by 10.50.40.7 with SMTP id t7mr4097321igk.48.1427806951089; Tue, 31 Mar 2015 06:02:31 -0700 (PDT) Received: by 10.36.61.65 with HTTP; Tue, 31 Mar 2015 06:02:31 -0700 (PDT) In-Reply-To: <55157D0C.2040808@selasky.org> References: <55157D0C.2040808@selasky.org> Date: Tue, 31 Mar 2015 15:02:31 +0200 Message-ID: Subject: Re: [PATCH] Adding backlight support for the i915 driver. From: "Ranjan1018 ." <214748mv@gmail.com> To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 13:02:31 -0000 2015-03-27 16:53 GMT+01:00 Hans Petter Selasky : > On 03/27/15 16:01, Ranjan1018 . wrote: > >> This patch exposes the backlight support via a sysctl: >> >> set the backlight to 10%: >> >> # sysctl hw.dri.0.i915_backlight=3D10 >> >> hw.dri.0.i915_backlight: 25 -> 10 >> >> set the backlight to 50%: >> >> # sysctl hw.dri.0.i915_backlight=3D50 >> >> hw.dri.0.i915_backlight: 10 -> 50 >> >> decrease the current backlight value: >> >> # sysctl hw.dri.0.i915_backlight=3D-1000 >> >> hw.dri.0.i915_backlight: 50 -> 43 >> >> increment the current backlight value: >> >> # sysctl hw.dri.0.i915_backlight=3D1000 >> >> hw.dri.0.i915_backlight: 43 -> 51 >> >> # sysctl hw.dri.0.i915_backlight=3D1000 >> >> hw.dri.0.i915_backlight: 51 -> 60 >> >> I am running this path on for about a week without issue. >> >> This path can be found at: >> https://github.com/maurizio-emmex/i915_backlight_freebsd >> >> I thank Elizabeth Myers, elizabeth at interlinked dot me, for the idea o= f >> adding the backlight support for the i915 driver and for the original >> patch. >> >> Regards, >> Maurizio >> > > Maybe you want to use "CTLFLAG_RWTUN" so that it also can be set from > /boot/loader.conf ? > > --HPS > The ability to set the backlight at startup may be useful. With this new patch I expose two ways to do this: - with the tunable "drm.i915.init_backlight" in /boot/loader.conf, just after the driver initialization (eg. drm.i915.init_backlight=3D20) - with the OID "hw.dri.0.i915_backlight" in /etc/sysctl.conf as suggested by Hans I don=E2=80=99t know if setting the backlight with the tunable "drm.i915.init_backlight" is useful, but I have already written the code and is simple to remove it. The patch file is i915_backlight.patch at https://github.com/maurizio-emmex/i915_backlight_freebsd Regards, Maurizio From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 13:41:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7B6ABCB; Tue, 31 Mar 2015 13:41:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A7AA2676; Tue, 31 Mar 2015 13:41:49 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 94E82C19; Tue, 31 Mar 2015 13:41:49 +0000 (UTC) Date: Tue, 31 Mar 2015 13:41:49 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, markj@FreeBSD.org, adrian@FreeBSD.org, emaste@FreeBSD.org, amdmi3@FreeBSD.org, gjb@FreeBSD.org, dim@FreeBSD.org, jilles@FreeBSD.org, glebius@FreeBSD.org, eadler@FreeBSD.org, zbb@FreeBSD.org, royger@FreeBSD.org, jhb@FreeBSD.org, np@FreeBSD.org, mav@FreeBSD.org, cy@FreeBSD.org, dumbbell@FreeBSD.org, kib@FreeBSD.org, ganbold@FreeBSD.org, ngie@FreeBSD.org, pfg@FreeBSD.org, jch@FreeBSD.org, jhibbits@FreeBSD.org, rrs@FreeBSD.org, bdrewery@FreeBSD.org, andrew@FreeBSD.org, cperciva@FreeBSD.org Message-ID: <1559182182.5.1427809309379.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1452708997.4.1427802672681.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1452708997.4.1427802672681.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2613 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: FAILURE X-Mailman-Approved-At: Tue, 31 Mar 2015 16:07:06 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 13:41:50 -0000 See Changes: [ganbold] Add kernel config files for Hardkernel Odroid-C1 and Visson ATV-102 devices. Submitted by: John Wehle Approved by: stas (mentor) [ganbold] Add device tree files for Hardkernel Odroid-C1 and Visson ATV-102 devices. Submitted by: John Wehle Approved by: stas (mentor) [ganbold] Add necessary changes to support various Amlogic SoC devices specially aml8726-m6 and aml8726-m8b SoC based devices. aml8726-m6 SoC exist in devices such as Visson ATV-102. Hardkernel ODROID-C1 board has aml8726-m8b SoC. The following support is included: Basic machdep code SMP Interrupt controller Clock control driver (aka gate) Pinctrl Timer Real time clock UART GPIO I2C SD controller SDXC controller USB Watchdog Random number generator PLL / Clock frequency measurement Frame buffer Submitted by: John Wehle Approved by: stas (mentor) [jch] Use appropriate timeout_t* instead of void* in tcp_timer_activate() Suggested by: imp Differential Revision: https://reviews.freebsd.org/D2154 Reviewed by: imp, jhb Approved by: jhb [andrew] Add the arm64 code to the runtime linker. It's not able to be built as we still need libc_pic for a few things, but this is expected to be ready soon. Differential Revision: https://reviews.freebsd.org/D2136 Reviewed by: kib Sponsored by: The FreeBSD Foundation ------------------------------------------ [...truncated 188046 lines...] y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :379:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->err_line_no, ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :380:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->err_col_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :670:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "statsdir remote configuration ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ --- all_subdir_tcpdump --- --- nlpid.o --- cc -O2 -pipe -I -I -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -DINET6 -DLBL_ALIGN -DHAVE_CAPSICUM -I -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -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-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c -o nlpid.o --- all_subdir_ntp --- :724:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen file remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :733:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen type remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :748:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :794:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :802:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :810:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :825:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :840:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :849:45: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? NULL, NULL, yystack.l_mark[0].Int_fifo, ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1059:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err_str); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1151:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, error_text); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1157:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "remote includefile ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1169:6: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file = fp[++curr_include_level]; ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1445:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "Integer value is not boolean (0 or 1). Assuming 1"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ 3 warnings and 18 errors generated. *** [ntp_parser.o] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ntp] Error code 2 make[3]: stopped in --- all_subdir_tcpdump --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_tcpdump] Error code 2 make[3]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_procstat] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in --- usr.sbin.all__D --- --- all_subdir_sendmail --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_sendmail] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] 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 Tue Mar 31 16:48: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 270B8A69; Tue, 31 Mar 2015 16:48: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 05E166E; Tue, 31 Mar 2015 16:48:43 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id AC175C4F; Tue, 31 Mar 2015 16:48:42 +0000 (UTC) Date: Tue, 31 Mar 2015 16:48:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, markj@FreeBSD.org, emaste@FreeBSD.org, gjb@FreeBSD.org, amdmi3@FreeBSD.org, zbb@FreeBSD.org, jhb@FreeBSD.org, royger@FreeBSD.org, mav@FreeBSD.org, np@FreeBSD.org, kib@FreeBSD.org, kevlo@FreeBSD.org, pfg@FreeBSD.org, jhibbits@FreeBSD.org, adrian@FreeBSD.org, dim@FreeBSD.org, jilles@FreeBSD.org, glebius@FreeBSD.org, eadler@FreeBSD.org, cy@FreeBSD.org, dumbbell@FreeBSD.org, ae@FreeBSD.org, ganbold@FreeBSD.org, ngie@FreeBSD.org, jch@FreeBSD.org, rrs@FreeBSD.org, bdrewery@FreeBSD.org, cperciva@FreeBSD.org, andrew@FreeBSD.org Message-ID: <1188150773.6.1427820521526.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1559182182.5.1427809309379.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1559182182.5.1427809309379.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2614 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: FAILURE X-Mailman-Approved-At: Tue, 31 Mar 2015 16:53:54 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 16:48:43 -0000 See Changes: [kevlo] Remove bogus cast. [ae] The offset variable has been cleared all bits except IP6F_OFF_MASK. Use ip6f_mf variable instead of checking its bits. [emaste] unwind-d2 build workaround for arm64 The __builtin_init_dwarf_reg_size_table function is unimplemented in clang 3.6 for AArch64. Comment it out for now and replace it with a message and abort. Tracked in upstream LLVM PR 22997 https://llvm.org/bugs/show_bug.cgi?id=22997 Submitted by: andrew [emaste] Correct copyright typo ------------------------------------------ [...truncated 185022 lines...] ip_file->fname, ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :379:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->err_line_no, ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :380:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->err_col_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :670:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "statsdir remote configuration ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :724:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen file remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :733:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "filegen type remote config ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :748:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :794:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :802:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :810:9: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :825:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :840:5: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :849:45: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? NULL, NULL, yystack.l_mark[0].Int_fifo, ip_file->line_no); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1059:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, err_str); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1151:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, error_text); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1157:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "remote includefile ignored"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1169:6: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? ip_file = fp[++curr_include_level]; ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ :1445:13: error: use of undeclared identifier 'ip_file'; did you mean 'ip_fil'? yyerror(ip_file, "Integer value is not boolean (0 or 1). Assuming 1"); ^~~~~~~ ip_fil y.tab.c:1157:1: note: 'ip_fil' declared here YYPARSE_DECL() ^ y.tab.c:89:51: note: expanded from macro 'YYPARSE_DECL' # define YYPARSE_DECL() yyparse(struct FILE_INFO *ip_fil) ^ 3 warnings and 18 errors generated. *** [ntp_parser.o] Error code 1 make[5]: stopped in 1 error make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make --- usr.sbin.all__D --- 1 error make[4]: stopped in --- usr.bin.all__D --- make[4]: stopped in --- usr.sbin.all__D --- *** [all_subdir_ntp] Error code 2 make[3]: stopped in --- usr.bin.all__D --- *** [all_subdir_lockf] Error code 2 make[3]: stopped in --- all_subdir_lock --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_lock] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in --- usr.sbin.all__D --- --- all_subdir_ppp --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_ppp] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] 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 Tue Mar 31 19:03:29 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 954DDA04; Tue, 31 Mar 2015 19:03:29 +0000 (UTC) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 4D57063A; Tue, 31 Mar 2015 19:03:29 +0000 (UTC) Received: by ykeg184 with SMTP id g184so8203580yke.2; Tue, 31 Mar 2015 12:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=s9kSJ+ZgLSPn7H8kAlheHKUJt2qjwQu7ZIlbDe29zz0=; b=FKeWlP0Q4JkXN1S6t5mQpLyUcQNjSpnmeUqGrxM2UPEjQ2Gcf38BW7bX76NMG881hV xpMGEkbZe7ZvNK/BW1ja+vmu2E/HrO5PmLF4g1UzmOGV/7hzWfHpva/Gmjm6zRHU4Lkn QlcBPiSyUHCCIl+msz1gdX3LjWj+s7ysyZkYEnN3aXs0JIGXpDctKGakaYwFv0VY3u14 czTg6bpBJ5Ty4wXO2LuhEbjvHv5PjW0ty95q70ADbzxSsJrqGIJ5/7q7Qb+DqXaSSXeW 2z84XgOdob+6weT3+AX2srBNmLWZ5ekk+s9JFPoOXHFkfMOnJnZMshqeyR4Y07DAuO/8 0uEA== X-Received: by 10.52.149.65 with SMTP id ty1mr39737687vdb.67.1427828608444; Tue, 31 Mar 2015 12:03:28 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fa2sm761497vdd.17.2015.03.31.12.03.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 12:03:27 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 31 Mar 2015 21:03:23 +0200 From: Baptiste Daroussin To: pkg@FreeBSD.org, ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org Subject: [CFT] Call for testing pkg 1.5.0 Message-ID: <20150331190323.GF30115@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HCdXmnRlPgeNBad2" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 19:03:29 -0000 --HCdXmnRlPgeNBad2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), Here is what happened since pkg 1.4.0: - pkg has grown with an initial support for provides/requires: this is a naive version but good enough to at least make major upgrade of php safer as well as making pear/pecl maintenance saner (note that this will need modifications in the ports tree) - Lots of new regression tests has been added, which allows us not less break your systems an unexpected way (do not worry there are still rooms for breakage) - Initial support for OS X - Initial support for NetBSD/EdjeBSD - Update most of the bundled third party software has been updated to their latest version - Improve the messages reported by pkg (and probably make some other worse) - Properly support file flags - Implement argument support for custom keywords - Extend setting credential via plist to allow to set file flags - Make credential syntax via plist more flexible allow to only defines the first fields and not latest for example @(user,,) can now be written just @(user) - pkg updating now supports case insensitive matching - pkg create now support a verbose mode - Add an option to change the default on question, until now the default answer was "No" with that option set it would be "Yes" - lots of fixes to pkg audit -r - Global memory usage reduction and speed up - Improvements and cleanup on pkg alias - pkg annotate --show --all has been fixed - Make pkg.h C++ friendly - Lots of improvements in the solver - Lots of fixes on 32 bits platforms - Add support for: pkg create -M ./plop.ucl -p ./plop.plist - New pkg -r that will install in the given rootdir without chrooting - Export PKG_ROOTDIR to scripts allow to make them as portable as possible - Stop trying to remove all installed package with the argument of pkg delete is a local file - Be more explicit about why the solver it going to reinstall, remove or upgrade (when possible) - Plenty of bug fixes - Plenty of new bugs Please test and report as much bugs as you can! We could be very grateful if regressions tests could be provided along with the bug reports :) Plan is to release 1.5.0 as soon as possible Best regards, Bapt --HCdXmnRlPgeNBad2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUa73sACgkQ8kTtMUmk6Ez5BwCbBc35ig3+qOqmpjisPCgYq384 wd8An1/W2kU5JZhNqR5Ldl66ni8XlmeG =uqMn -----END PGP SIGNATURE----- --HCdXmnRlPgeNBad2-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 19:19:22 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF2EC5B8 for ; Tue, 31 Mar 2015 19:19:21 +0000 (UTC) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.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 9ADC6864 for ; Tue, 31 Mar 2015 19:19:21 +0000 (UTC) Received: by yhjf44 with SMTP id f44so6406375yhj.3 for ; Tue, 31 Mar 2015 12:19:14 -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:subject:from:to:cc:date:in-reply-to :references:organization:content-type:mime-version; bh=YyT7jrzydJfhCxnf6RUb5WgXEOuPdtdKcI0KQ6+AQTs=; b=EpmuT/oLdXwmTiv6Qow4lYtVcXZS7kl/xVh8RmU4M4laC64ycO45HwHJ9jKpDPEOir FAK1lJte04ayW04hOMn8S14Mp2sF7mGn4141DyoGcjbmKXrsF0F4wv+qNPPnjyDAql6A FFrMKXvyHo3nivLhebGLIGkXjvdVaeJDdCaf+/jyHqktkbLcxnnzr38EcHzqBSX6kcB3 4Z/c/LE5QTYdlm77grPMnZjDK98hxDMab1Go0J4Q0dTci8E3F643WzXV6BLBGVx7gNVW T2bCeKcFypDQR1dP0/AesoX/42Q1vgDCPL4I2tPbPlvu2k9eIcKV3O2gnkw3yoWxxm7P 17QQ== X-Gm-Message-State: ALoCoQmEa05itzLwF+PCNVcnSAoRf+PXGiTCWkOkotA38kqdozoemTgjE9W6d3Q3hKNWo9RokIJz X-Received: by 10.52.153.168 with SMTP id vh8mr39809183vdb.60.1427829554381; Tue, 31 Mar 2015 12:19:14 -0700 (PDT) Received: from [10.3.0.21] ([63.88.83.66]) by mx.google.com with ESMTPSA id k10sm2521407vdi.18.2015.03.31.12.19.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 12:19:13 -0700 (PDT) Message-ID: <1427829555.3892.7.camel@hardenedbsd.org> Subject: Re: [CFT] Call for testing pkg 1.5.0 From: Shawn Webb To: Baptiste Daroussin Date: Tue, 31 Mar 2015 15:19:15 -0400 In-Reply-To: <20150331190323.GF30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> Organization: HardenedBSD Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-o/MtVoTkUc7/Wutj888l" X-Mailer: Evolution 3.12.10-0ubuntu1~14.10.1 Mime-Version: 1.0 Cc: pkg@FreeBSD.org, ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 19:19:22 -0000 --=-o/MtVoTkUc7/Wutj888l Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-31 at 21:03 +0200, Baptiste Daroussin wrote: > Hi all, >=20 > We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), Hey Baptiste, Great work to you and all those involved in this project! I'm grateful to have such an awesome tool. For those of us who run our own package repos via Poudriere, what kinds of changes should we expect to make once pkg 1.5.0 is released? Do we need to do a full rebuild of our package repo? I'm also assuming that the upgrade path from 1.4.x to 1.5.0 will simply be as easy as running `pkg upgrade`, right? Thanks again for your hard work. Thanks, Shawn --=-o/MtVoTkUc7/Wutj888l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVGvMzAAoJEGqEZY9SRW7uaL8P/1GWA70SzZlXRhSKCHOtgeqk fvpB8lWQNpWWn2yywKNwYMjm1A/J0/xtd0gtsgumAjUbK0YnRt5exjSEWud7le7h eqo4uaFANMjAynIe0POyc7RNxlALgoA7wVe0Djg9oMAyPHvworuME0PRA9pjJbHU kjRVpAghEPWwxOEP2WcSANOK+tn3ciw3KmrwoGihh9K7oLSVxIvr8qyMhtmV4qfq pW8dON6V16pfrsXgob2UZfXwk9Lp9P58/uUjCpHX9bliSKuWv9bSdsVYFgmAC+7F 5YAtGAFwowcdNiXm80OTdfg4ts9FP4DtmniidXILgh2x0fC3FiXEka8Ipj5rx5rG 3Q0nGx0/PJPMez9dufV0X9hlm664Og3AQubc5K4W0FFLycwDzTnanBWjRxqsweHT fruqQFccVSZBcSsVQzpHZBW2mQAVc3sELNRjWRRrZYN957YdrXBJMzaovJ7Hkjge 2FPAns21D0HPIM1qdQKG/s3vSq6ddoX7qrYLszifffuUzEyqAHrPYxFRzPA36FMm jZJ813rZ/lwSX0nappSGve2TjQwYiApqzwLnUHPo/ogUg+W2IK00MwYzmgUTMWKp 7nBJyaRCUKyUm8EaE/laCYf4GCzyfbncJeL8et6aGq1JgdPoiDN2Dkw40hHvOf7W msRuOH2nIalzUkv2AADr =YEJA -----END PGP SIGNATURE----- --=-o/MtVoTkUc7/Wutj888l-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 19:23:23 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 1A48491F; Tue, 31 Mar 2015 19:23:23 +0000 (UTC) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3350936; Tue, 31 Mar 2015 19:23:22 +0000 (UTC) Received: by yhfw71 with SMTP id w71so6415754yhf.2; Tue, 31 Mar 2015 12:23:22 -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=Vy68YzEVUirPkMDLoYBQS7GpWKYZQ6gfk4duQF7L9C8=; b=IEzivNX80GwhKbMT5TpQlZJBye6gOm72fU9yUYlvWV5OxrnANfXJqVjQMHK8fjiJRE dY1loq9dVlvZVQInhUx5Q3RVPVJSuJe85A8kmEkC/kTjTW4NsT2p3aYhhpSG/hT+OeIq 4MUJWhyieLjSi2PuUL+uKfZPbK92cqnE8OQmuZPbThN2RnUx+9KlUw1sd8ILLMzq4MYd j6vkbquzM9WICgXtizAP1hXACfdJL0TRag1vfuseCJYHgQi1jQTh4pZiKRcl4NJiAOXd ThP1UiZRtOi9D5WnQastEchw1Axp42ihoxecsMTogACGkAWPllFd0PgmUo4RI95sAGYF xbhQ== X-Received: by 10.52.29.147 with SMTP id k19mr39765545vdh.56.1427829801812; Tue, 31 Mar 2015 12:23:21 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id d4sm2524080vdh.19.2015.03.31.12.23.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 12:23:20 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 31 Mar 2015 21:23:16 +0200 From: Baptiste Daroussin To: Shawn Webb Subject: Re: [CFT] Call for testing pkg 1.5.0 Message-ID: <20150331192315.GH30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <1427829555.3892.7.camel@hardenedbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JI+G0+mN8WmwPnOn" Content-Disposition: inline In-Reply-To: <1427829555.3892.7.camel@hardenedbsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: pkg@FreeBSD.org, ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 19:23:23 -0000 --JI+G0+mN8WmwPnOn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 31, 2015 at 03:19:15PM -0400, Shawn Webb wrote: > On Tue, 2015-03-31 at 21:03 +0200, Baptiste Daroussin wrote: > > Hi all, > >=20 > > We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), >=20 > Hey Baptiste, >=20 > Great work to you and all those involved in this project! I'm grateful > to have such an awesome tool. >=20 > For those of us who run our own package repos via Poudriere, what kinds > of changes should we expect to make once pkg 1.5.0 is released? Do we > need to do a full rebuild of our package repo? I'm also assuming that > the upgrade path from 1.4.x to 1.5.0 will simply be as easy as running > `pkg upgrade`, right? >=20 > Thanks again for your hard work. >=20 Add WITH_PKG=3Ddevel in your build make.conf then pkg upgrade will want you to upgrade to 1.4.99.16 (which is pkg 1.5.0 beta1) Best regards, Bapt --JI+G0+mN8WmwPnOn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUa9CMACgkQ8kTtMUmk6EysoACfaDu+CsBJOmoge39tU0JHNF40 qHUAn1cU0+JaE5/GLU0SBjrW60fQmBx/ =Z7aK -----END PGP SIGNATURE----- --JI+G0+mN8WmwPnOn-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 21:17:35 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 B5D2CF9B for ; Tue, 31 Mar 2015 21:17:35 +0000 (UTC) Received: from munin.odin-corporation.com (173-161-46-1-Illinois.hfc.comcastbusiness.net [173.161.46.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Lars Fredriksen", Issuer "Lars Fredriksen" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 736F9901 for ; Tue, 31 Mar 2015 21:17:34 +0000 (UTC) Received: from larsmacmini.fredriksen.us (valhall.odin-corporation.com [173.161.46.2]) (authenticated bits=0) by munin.odin-corporation.com (8.14.5/8.14.5) with ESMTP id t2VLHRk9075607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2015 16:17:27 -0500 (CDT) (envelope-from lars@odin-corporation.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2096\)) Subject: Re: Is a high witness refcount indicative of a missing unlock? From: Lars In-Reply-To: <5518957B.4050505@ShaneWare.Biz> Date: Tue, 31 Mar 2015 16:17:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8858A68D-D68C-4CD5-A6D9-4886EE746216@odin-corporation.com> References: <1117D087-AD76-4A87-8798-AB5526BECF3A@odin-corporation.com> <5518957B.4050505@ShaneWare.Biz> To: Shane Ambler X-Mailer: Apple Mail (2.2096) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 21:17:35 -0000 Hi Shane, While our configs shoulds much the same (ignoring 10.1-stable vs = current) and I had the nvidia driver loaded, my lockups did not involve = the nvidia driver. That of course does not necessarily mean anything if = the issue is squarly in zfs somewhere. You can see the reference counts from the ddb kernel debugger (man 8 = ddb) using the =E2=80=9Cshow witness=E2=80=9D command Lars > On Mar 29, 2015, at 19:14, Shane Ambler wrote: >=20 > On 30/03/2015 05:59, Lars wrote: >> Hi, I am poking around for a cause for my repeating deadlock issues >> on my system based on r 279869. ddb show witness show the = =C3=A2=E2=82=AC=C5=93vnode >> interlock=C3=A2=E2=82=AC=C2=9D and the =C3=A2=E2=82=AC=C5=93zfs=C3=A2=E2= =82=AC=C2=9D locks both with reference counts over >> 200K. Obviously they are related, and there is a find running (all >> the filesystems on this machine are zfs ( minus the specialty ones >> like devfs). >>=20 >> I don=C3=A2=E2=82=AC=E2=84=A2t see any other withness entry with = reference counts even in >> the ballpark of these two, so does this indicate that we have a >> vnode/zfs path were we don=C3=A2=E2=82=AC=E2=84=A2t unlock? >>=20 >=20 > I am running 10.1-STABLE and have bad locking issues. Running a = witness > kernel I got a duplicate lock from nvidia and lock order reversals > involving zfs. Any chance your issue is related to mine? >=20 > What command can give me the witness lock counts? >=20 > The debug data I have collected so far is at - > http://shaneware.biz/freebsddebugdata/ >=20 > The lock reversal output I had was (after uptime of about 12 mins) - >=20 > Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system = process `vnlru' to stop...done > Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system = process `bufdaemon' to stop...done > Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system = process `syncer' to stop... > Mar 24 00:24:25 leader kernel: Syncing disks, vnodes remaining...0 0 0 = 0 0 0 0 0 done > Mar 24 00:24:25 leader kernel: All buffers synced. > Mar 24 00:24:25 leader kernel: lock order reversal: > Mar 24 00:24:25 leader kernel: 1st 0xfffff800224555f0 zfs (zfs) @ = /usr/src/sys/kern/vfs_mount.c:1229 > Mar 24 00:24:25 leader kernel: 2nd 0xfffff800222d67c8 syncer (syncer) = @ /usr/src/sys/kern/vfs_subr.c:2268 > Mar 24 00:24:25 leader kernel: KDB: stack backtrace: > Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at = db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e4c0 > Mar 24 00:24:25 leader kernel: kdb_backtrace() at = kdb_backtrace+0x39/frame 0xfffffe022df6e570 > Mar 24 00:24:25 leader kernel: witness_checkorder() at = witness_checkorder+0xdc2/frame 0xfffffe022df6e600 > Mar 24 00:24:25 leader kernel: __lockmgr_args() at = __lockmgr_args+0x9ea/frame 0xfffffe022df6e740 > Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame = 0xfffffe022df6e760 > Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at = VOP_LOCK1_APV+0xfc/frame 0xfffffe022df6e790 > Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame = 0xfffffe022df6e800 > Mar 24 00:24:25 leader kernel: vputx() at vputx+0x232/frame = 0xfffffe022df6e860 > Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x301/frame = 0xfffffe022df6e8e0 > Mar 24 00:24:25 leader kernel: vfs_unmountall() at = vfs_unmountall+0x61/frame 0xfffffe022df6e910 > Mar 24 00:24:25 leader kernel: kern_reboot() at = kern_reboot+0x540/frame 0xfffffe022df6e980 > Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame = 0xfffffe022df6e9a0 > Mar 24 00:24:25 leader kernel: amd64_syscall() at = amd64_syscall+0x25a/frame 0xfffffe022df6eab0 > Mar 24 00:24:25 leader kernel: Xfast_syscall() at = Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 > Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, = sys_reboot), rip =3D 0x40f1bc, rsp =3D 0x7fffffffe6d8, rbp =3D = 0x7fffffffe7d0 --- > Mar 24 00:24:25 leader kernel: lock order reversal: > Mar 24 00:24:25 leader kernel: 1st 0xfffff800222d6b78 zfs (zfs) @ = /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/= zfs_vfsops.c:1814 > Mar 24 00:24:25 leader kernel: 2nd 0xffffffff818514a8 allproc = (allproc) @ /usr/src/sys/kern/kern_descrip.c:2872 > Mar 24 00:24:25 leader kernel: KDB: stack backtrace: > Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at = db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e690 > Mar 24 00:24:25 leader kernel: kdb_backtrace() at = kdb_backtrace+0x39/frame 0xfffffe022df6e740 > Mar 24 00:24:25 leader kernel: witness_checkorder() at = witness_checkorder+0xdc2/frame 0xfffffe022df6e7d0 > Mar 24 00:24:25 leader kernel: _sx_slock() at _sx_slock+0x76/frame = 0xfffffe022df6e810 > Mar 24 00:24:25 leader kernel: mountcheckdirs() at = mountcheckdirs+0x47/frame 0xfffffe022df6e860 > Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x36f/frame = 0xfffffe022df6e8e0 > Mar 24 00:24:25 leader kernel: vfs_unmountall() at = vfs_unmountall+0x61/frame 0xfffffe022df6e910 > Mar 24 00:24:25 leader kernel: kern_reboot() at = kern_reboot+0x540/frame 0xfffffe022df6e980 > Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame = 0xfffffe022df6e9a0 > Mar 24 00:24:25 leader kernel: amd64_syscall() at = amd64_syscall+0x25a/frame 0xfffffe022df6eab0 > Mar 24 00:24:25 leader kernel: Xfast_syscall() at = Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 > Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, = sys_reboot), rip =3D 0x40f1bc, rsp =3D 0x7fffffffe6d8, rbp =3D = 0x7fffffffe7d0 --- > Mar 24 00:24:25 leader kernel: lock order reversal: > Mar 24 00:24:25 leader kernel: 1st 0xfffff8001ca8e240 zfs (zfs) @ = /usr/src/sys/kern/vfs_mount.c:1229 > Mar 24 00:24:25 leader kernel: 2nd 0xfffff8001ca8e5f0 devfs (devfs) @ = /usr/src/sys/kern/vfs_subr.c:2157 > Mar 24 00:24:25 leader kernel: KDB: stack backtrace: > Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at = db_trace_self_wrapper+0x2b/frame 0xfffffe022df6e460 > Mar 24 00:24:25 leader kernel: kdb_backtrace() at = kdb_backtrace+0x39/frame 0xfffffe022df6e510 > Mar 24 00:24:25 leader kernel: witness_checkorder() at = witness_checkorder+0xdc2/frame 0xfffffe022df6e5a0 > Mar 24 00:24:25 leader kernel: __lockmgr_args() at = __lockmgr_args+0x9ea/frame 0xfffffe022df6e6e0 > Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame = 0xfffffe022df6e700 > Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at = VOP_LOCK1_APV+0xfc/frame 0xfffffe022df6e730 > Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame = 0xfffffe022df6e7a0 > Mar 24 00:24:25 leader kernel: vget() at vget+0x67/frame = 0xfffffe022df6e7e0 > Mar 24 00:24:25 leader kernel: devfs_allocv() at = devfs_allocv+0xfd/frame 0xfffffe022df6e830 > Mar 24 00:24:25 leader kernel: devfs_root() at devfs_root+0x43/frame = 0xfffffe022df6e860 > Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x345/frame = 0xfffffe022df6e8e0 > Mar 24 00:24:25 leader kernel: vfs_unmountall() at = vfs_unmountall+0x61/frame 0xfffffe022df6e910 > Mar 24 00:24:25 leader kernel: kern_reboot() at = kern_reboot+0x540/frame 0xfffffe022df6e980 > Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame = 0xfffffe022df6e9a0 > Mar 24 00:24:25 leader kernel: amd64_syscall() at = amd64_syscall+0x25a/frame 0xfffffe022df6eab0 > Mar 24 00:24:25 leader kernel: Xfast_syscall() at = Xfast_syscall+0xfb/frame 0xfffffe022df6eab0 > Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, = sys_reboot), rip =3D 0x40f1bc, rsp =3D 0x7fffffffe6d8, rbp =3D = 0x7fffffffe7d0 --- > Mar 24 00:24:25 leader kernel: Uptime: 12m42s >=20 >=20 > --=20 > FreeBSD - the place to B...Software Developing >=20 > Shane Ambler >=20 > _______________________________________________ > 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" >=20 From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 22:51:00 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 561132A5; Tue, 31 Mar 2015 22:51:00 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 20E6A671; Tue, 31 Mar 2015 22:50:59 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t2VMopFx067670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 16:50:51 -0600 (MDT) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t2VMop3o067669; Tue, 31 Mar 2015 16:50:51 -0600 (MDT) (envelope-from ken) Date: Tue, 31 Mar 2015 16:50:51 -0600 From: "Kenneth D. Merry" To: Konstantin Belousov Subject: Re: async pass(4) patches available Message-ID: <20150331225051.GA64520@mithlond.kdm.org> References: <20150330222358.GA46342@mithlond.kdm.org> <20150331004912.GM2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150331004912.GM2379@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 31 Mar 2015 16:50:51 -0600 (MDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 22:51:00 -0000 On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote: > On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > > Kernel memory for data transferred via the queued interface is > > allocated from the zone allocator in MAXPHYS sized chunks, and user > > data is copied in and out. This is likely faster than the > > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > > configurations with many processors (there are more TLB shootdowns > > caused by the mapping/unmapping operation) but may not be as fast > > as running with unmapped I/O. > cam_periph_mapmem() uses vmapbuf() with an indicator to always map the > user pages mostly because I do not know CAM code and wanted to make > the least intrusive changes there. It is not inherently impossible > to pass unmapped pages down from cam_periph_mapmem(), but might > require some more plumbing for driver to indicate that it is acceptable. I think that would probably not be too difficult to change. That API isn't one that is exposed, so changing it shouldn't be a problem. The only reason not to do unmapped I/O there is just if the underlying controller doesn't support it. The lower parts of the stack shouldn't be trying to sniff the data that is read or written to the device, although that has happened in the past. We'd have to audit a couple of the drivers to make sure they aren't trying to access the data. > > The new memory handling model for user requests also allows > > applications to send CCBs with request sizes that are larger than > > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > > size listed by the SIM driver in the maxio field in the Path > > Inquiry (XPT_PATH_INQ) CCB. > > > > There are some things things would be good to add: > > > > 1. Come up with a way to do unmapped I/O on multiple buffers. > > Currently the unmapped I/O interface operates on a struct bio, > > which includes only one address and length. It would be nice > > to be able to send an unmapped scatter/gather list down to > > busdma. This would allow eliminating the copy we currently do > > for data. > Only because nothing more was needed. The struct bio does not use > address/length pair when unmapped, it passes the list of physical > pages, see bio_ma array pointer. It is indeed taylored to be a pointer > to struct buf' b_pages, but it does not have to be. > > The busdma unmapped non-specific interface is bus_dmamap_load_ma(), > which again takes array of pages to load. If you want some additional > helper, suitable for your goals, please provide the desired interface > definition. What I'd like to be able to do is pass down a CCB with a user virtual S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal with it. The trouble would likely be figuring out a flag to use to indicate that the S/G list in question contains user virtual pointers. (Backwards/binary compatibility is always an issue with CCB flags, since they have all been used.) But that is essentially what is needed. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Tue Mar 31 23:12:55 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 EAAE1A26; Tue, 31 Mar 2015 23:12: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 CB1758D2; Tue, 31 Mar 2015 23:12:54 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BDE21D61; Tue, 31 Mar 2015 23:12:54 +0000 (UTC) Date: Tue, 31 Mar 2015 23:12:54 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, markj@FreeBSD.org, emaste@FreeBSD.org, amdmi3@FreeBSD.org, gjb@FreeBSD.org, zbb@FreeBSD.org, royger@FreeBSD.org, jhb@FreeBSD.org, mav@FreeBSD.org, np@FreeBSD.org, kib@FreeBSD.org, pfg@FreeBSD.org, kevlo@FreeBSD.org, jhibbits@FreeBSD.org, delphij@FreeBSD.org, adrian@FreeBSD.org, dim@FreeBSD.org, jilles@FreeBSD.org, glebius@FreeBSD.org, eadler@FreeBSD.org, cy@FreeBSD.org, dumbbell@FreeBSD.org, ganbold@FreeBSD.org, ae@FreeBSD.org, ngie@FreeBSD.org, jch@FreeBSD.org, rrs@FreeBSD.org, bdrewery@FreeBSD.org, cperciva@FreeBSD.org, andrew@FreeBSD.org Message-ID: <1477033515.11.1427843574704.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1188150773.6.1427820521526.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1188150773.6.1427820521526.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #2615 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: Tue, 31 Mar 2015 23:45:02 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 31 Mar 2015 23:12:55 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 02:39:21 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 9EEE495F; Wed, 1 Apr 2015 02:39:21 +0000 (UTC) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 8C632CF; Wed, 1 Apr 2015 02:39:21 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:58014 helo=tinkerbell.pixel8networks.com) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yd20z-000EgI-Ee; Tue, 31 Mar 2015 12:39:57 -0700 From: Devin Teske Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Phabricator -- can't update review Date: Tue, 31 Mar 2015 19:39:06 -0700 Message-Id: <79F1A8D6-EF8F-4D45-8045-D5895A811ADE@FreeBSD.org> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Sender: devin@shxd.cx Cc: Devin Teske X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 02:39:21 -0000 Hi, I=E2=80=99ve been beating my head on the below issue for an hour now. I=E2=80=99m getting frustrated and don=E2=80=99t understand what it is = trying to say. head $ arc diff =E2=80=94update D2105 Exception Field =E2=80=9CrevisionID=E2=80=9D occurs twice in commit message! So I go and look at the commit message. I think it is confused. I am at an impasse. I=E2=80=99m starting to consider closing D2105 and creating a new entry ;( Trace available upon request, but it=E2=80=99s pretty boring stuff. = Could use some help here. =E2=80=94=20 Thanks in advance, Devin= From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 02:56: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 83BD2D16; Wed, 1 Apr 2015 02:56:38 +0000 (UTC) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 6EAD12DE; Wed, 1 Apr 2015 02:56:38 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:58176 helo=tinkerbell.pixel8networks.com) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yd2Hv-000Enp-02; Tue, 31 Mar 2015 12:57:27 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Phabricator -- can't update review From: Devin Teske In-Reply-To: <79F1A8D6-EF8F-4D45-8045-D5895A811ADE@FreeBSD.org> Date: Tue, 31 Mar 2015 19:56:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46B2C11D-737F-4E56-9F22-6AF38A6D806F@FreeBSD.org> References: <79F1A8D6-EF8F-4D45-8045-D5895A811ADE@FreeBSD.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1990.1) Sender: devin@shxd.cx Cc: Devin Teske X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 02:56:38 -0000 > On Mar 31, 2015, at 7:39 PM, Devin Teske wrote: >=20 > Hi, >=20 > I=E2=80=99ve been beating my head on the below issue for an hour now. > I=E2=80=99m getting frustrated and don=E2=80=99t understand what it is = trying to say. >=20 > head $ arc diff =E2=80=94update D2105 > Exception > Field =E2=80=9CrevisionID=E2=80=9D occurs twice in commit message! >=20 >=20 > So I go and look at the commit message. I think it is confused. >=20 > I am at an impasse. I=E2=80=99m starting to consider closing D2105 and > creating a new entry ;( >=20 > Trace available upon request, but it=E2=80=99s pretty boring stuff. = Could > use some help here. Full trace here: http://pastebin.com/NzBvDruM From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 03:29:21 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 9F994702; Wed, 1 Apr 2015 03:29:21 +0000 (UTC) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (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 86A899D6; Wed, 1 Apr 2015 03:29:21 +0000 (UTC) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:58445 helo=tinkerbell.pixel8networks.com) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yd2nY-000F2W-1s; Tue, 31 Mar 2015 13:30:08 -0700 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Phabricator -- can't update review From: Devin Teske In-Reply-To: <46B2C11D-737F-4E56-9F22-6AF38A6D806F@FreeBSD.org> Date: Tue, 31 Mar 2015 20:29:12 -0700 Message-Id: <34289FFB-0560-40DB-A51A-681F1C5092B0@FreeBSD.org> References: <79F1A8D6-EF8F-4D45-8045-D5895A811ADE@FreeBSD.org> <46B2C11D-737F-4E56-9F22-6AF38A6D806F@FreeBSD.org> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1990.1) Sender: devin@shxd.cx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Devin Teske , eadler@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 03:29:21 -0000 > On Mar 31, 2015, at 7:56 PM, Devin Teske wrote: >=20 >>=20 >> On Mar 31, 2015, at 7:39 PM, Devin Teske wrote: >>=20 >> Hi, >>=20 >> I=E2=80=99ve been beating my head on the below issue for an hour now. >> I=E2=80=99m getting frustrated and don=E2=80=99t understand what it = is trying to say. >>=20 >> head $ arc diff =E2=80=94update D2105 >> Exception >> Field =E2=80=9CrevisionID=E2=80=9D occurs twice in commit message! >>=20 >>=20 >> So I go and look at the commit message. I think it is confused. >>=20 >> I am at an impasse. I=E2=80=99m starting to consider closing D2105 = and >> creating a new entry ;( >>=20 >> Trace available upon request, but it=E2=80=99s pretty boring stuff. = Could >> use some help here. >=20 > Full trace here: > http://pastebin.com/NzBvDruM Eitan found it. I needed to remove "Differential Review:=E2=80=9D line from my commit = message. What was non-obvious was that =E2=80=94 when using SVN =E2=80=94 you = can=E2=80=99t see that this line is already being added by the arc template (iirc from Eitan). Removing the Differential Review line from the commit message makes it appear as the line is no longer there (using svn; using hg or git you = can see that it is appended to the end of the summary). Just need to take it on Faith that it=E2=80=99s there even if not = displayed (you=E2=80=99ll get a warning if it=E2=80=99s not there, so no harm no fowl). All is good now. Thanks again Eitan! =E2=80=94=20 Devin From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 00:24:49 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 82334F4B; Wed, 1 Apr 2015 00:24:49 +0000 (UTC) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::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 4450DFCD; Wed, 1 Apr 2015 00:24:49 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so34223702ied.1; Tue, 31 Mar 2015 17:24:48 -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=Zk+wc4diuCUDiVULFZk3aTtcfrvO2o1JwNyHJAPxaSA=; b=A/mUCE9xkFJtLAzrSwhW/5ecSAeAaXsaGZtPJ5898yxK3TCw8uxcEdHyhS+p9MtG4k MK12JbooX4l8dDRCycywOMDcE2HUfLq2DTAkD6xd0mf9tcXxz/XhNcq0QikXewsTRK5e Z8bC/t8yotYLHcnNGMkMV5ga+MeqJFu5O8Wsul/GMF3vQ4/C8t1C1i8G+OLyvo1yNKdA 7uIWPX5nqUt62tADTH98qidRKdq/ubI6uJSB2CqwhmOl9kEO5g4RnMLAVzDBJpQec0Ec G94p06wVS/oCv2nH9mWghAvgiQH9nBJA/iwQ8rGqoXRipdne48zO1woxtVil8ELuEexF vG7A== MIME-Version: 1.0 X-Received: by 10.43.95.5 with SMTP id ca5mr35851755icc.33.1427847888583; Tue, 31 Mar 2015 17:24:48 -0700 (PDT) Received: by 10.36.21.130 with HTTP; Tue, 31 Mar 2015 17:24:48 -0700 (PDT) In-Reply-To: <20150331192315.GH30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <1427829555.3892.7.camel@hardenedbsd.org> <20150331192315.GH30115@ivaldir.etoilebsd.net> Date: Wed, 1 Apr 2015 02:24:48 +0200 Message-ID: Subject: Re: [CFT] Call for testing pkg 1.5.0 From: Sergei Vyshenski To: Baptiste Daroussin X-Mailman-Approved-At: Wed, 01 Apr 2015 03:52:23 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: pkg@freebsd.org, ports@freebsd.org, stable@freebsd.org, current@freebsd.org, Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 00:24:49 -0000 Hi, On Tue, Mar 31, 2015 at 9:23 PM, Baptiste Daroussin wrote: > Add WITH_PKG=devel in your build make.conf > then pkg upgrade will want you to upgrade to 1.4.99.16 (which is pkg 1.5.0 > beta1) > This does not work for me. # cat /etc/make.conf |grep PKG WITH_PKGNG=yes WITH_PKG=devel # pkg upgrade Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (218 candidates): 100% Processing candidates (218 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date. # pkg -v 1.4.12 # pkg info |grep pkg pkg-1.4.12 Package manager Instead, the following succeded: # cd /usr/ports/ports-mgmt/pkg-devel # make reinstall ... # pkg -v 1.4.99.16 All the best, Sergei From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 08:29:09 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 AA54A1B3; Wed, 1 Apr 2015 08:29:09 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 31B0169B; Wed, 1 Apr 2015 08:29:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t318T48S042800 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 11:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t318T48S042800 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t318T3KP042799; Wed, 1 Apr 2015 11:29:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Apr 2015 11:29:03 +0300 From: Konstantin Belousov To: "Kenneth D. Merry" Subject: Re: async pass(4) patches available Message-ID: <20150401082903.GW2379@kib.kiev.ua> References: <20150330222358.GA46342@mithlond.kdm.org> <20150331004912.GM2379@kib.kiev.ua> <20150331225051.GA64520@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150331225051.GA64520@mithlond.kdm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 08:29:09 -0000 On Tue, Mar 31, 2015 at 04:50:51PM -0600, Kenneth D. Merry wrote: > On Tue, Mar 31, 2015 at 03:49:12 +0300, Konstantin Belousov wrote: > > On Mon, Mar 30, 2015 at 04:23:58PM -0600, Kenneth D. Merry wrote: > > > Kernel memory for data transferred via the queued interface is > > > allocated from the zone allocator in MAXPHYS sized chunks, and user > > > data is copied in and out. This is likely faster than the > > > vmapbuf()/vunmapbuf() method used by the CAMIOCOMMAND ioctl in > > > configurations with many processors (there are more TLB shootdowns > > > caused by the mapping/unmapping operation) but may not be as fast > > > as running with unmapped I/O. > > cam_periph_mapmem() uses vmapbuf() with an indicator to always map the > > user pages mostly because I do not know CAM code and wanted to make > > the least intrusive changes there. It is not inherently impossible > > to pass unmapped pages down from cam_periph_mapmem(), but might > > require some more plumbing for driver to indicate that it is acceptable. > > I think that would probably not be too difficult to change. That API isn't > one that is exposed, so changing it shouldn't be a problem. The only > reason not to do unmapped I/O there is just if the underlying controller > doesn't support it. The lower parts of the stack shouldn't be trying to > sniff the data that is read or written to the device, although that has > happened in the past. We'd have to audit a couple of the drivers to > make sure they aren't trying to access the data. This is why I mentioned 'plumbing' required to map pages when needed. > > > > The new memory handling model for user requests also allows > > > applications to send CCBs with request sizes that are larger than > > > MAXPHYS. The pass(4) driver now limits queued requests to the I/O > > > size listed by the SIM driver in the maxio field in the Path > > > Inquiry (XPT_PATH_INQ) CCB. > > > > > > There are some things things would be good to add: > > > > > > 1. Come up with a way to do unmapped I/O on multiple buffers. > > > Currently the unmapped I/O interface operates on a struct bio, > > > which includes only one address and length. It would be nice > > > to be able to send an unmapped scatter/gather list down to > > > busdma. This would allow eliminating the copy we currently do > > > for data. > > Only because nothing more was needed. The struct bio does not use > > address/length pair when unmapped, it passes the list of physical > > pages, see bio_ma array pointer. It is indeed taylored to be a pointer > > to struct buf' b_pages, but it does not have to be. > > > > The busdma unmapped non-specific interface is bus_dmamap_load_ma(), > > which again takes array of pages to load. If you want some additional > > helper, suitable for your goals, please provide the desired interface > > definition. > > What I'd like to be able to do is pass down a CCB with a user virtual > S/G list (CAM_DATA_SG, but with user virtual pointers) and have busdma deal > with it. Is there an existing definition of the 'user s/g list' ? Some structure, or existing example of use ? > > The trouble would likely be figuring out a flag to use to indicate that the > S/G list in question contains user virtual pointers. (Backwards/binary > compatibility is always an issue with CCB flags, since they have all been > used.) > > But that is essentially what is needed. > I can write the code, but I need API specification. Also, ideally I need a rough example which uses the API. From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 02:13: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 2766755C for ; Wed, 1 Apr 2015 02:13:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 D6324E45 for ; Wed, 1 Apr 2015 02:13:53 +0000 (UTC) Received: (qmail 12629 invoked from network); 1 Apr 2015 02:13:46 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Apr 2015 02:13:46 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 31 Mar 2015 22:13:46 -0400 (EDT) Received: (qmail 10659 invoked from network); 1 Apr 2015 02:13:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Apr 2015 02:13:46 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 491721C4052; Tue, 31 Mar 2015 19:13:40 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages Date: Tue, 31 Mar 2015 19:13:44 -0700 Message-Id: <52A97222-C183-4CDC-8FA5-A4CA7552BF5F@dsl-only.net> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Wed, 01 Apr 2015 10:42:35 +0000 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 02:13:54 -0000 Basic context: > $ dmesg | head > ... > FreeBSD 11.0-CURRENT #3 r280867M: Tue Mar 31 16:19:53 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > $ freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r280867M: Tue = Mar 31 16:19:53 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100067 1100066 I normally do not go beyond the most recent 11.0-CURRENT snapshot = (-r280862 at this point) but I wanted to pick up the the checkins that = enable building the system clang via powerpc64-xtoolchain-gcc's = powerpc64-gcc (as part of a self-hosted rebuild). So I choose to: = svnlite update /usr/src -r280867 . I also later did "svnlite update /usr/src/contrib/ntp/ -r280915" because = the overall the -r280867 vintage materials in that area failed to = compile. Other than -r280915's contrib/ntp/ntpd/ntp_parser.y, contrib/ntp/... is = the -r280849 update that would have been in a -r280862 snapshot. The problem (new ntpd error messages but probably not important to my = activities): After buildworld buildkernel installkernel installworld and rebooting it = now reports during the boot (with a little context shown): > ... > Starting sendmail_submit. > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for = [omitted] fails: Can't assign requested address > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for = [omitted] fails: Can't assign requested address > Starting sendmail_msp_queue. > ... The "line 22 column 1 syntax error" is not explicit about the file = involved. Presuming /etc/ntp.conf ... > # > # $FreeBSD: head/etc/ntp.conf 259973 2013-12-27 23:06:15Z delphij $ > # > ... > # The option `iburst' is used for faster initial synchronization. > # > server 0.freebsd.pool.ntp.org iburst > server 1.freebsd.pool.ntp.org iburst > server 2.freebsd.pool.ntp.org iburst > #server 3.freebsd.pool.ntp.org iburst > ... That first "server" line is line 22 and is the first non-#/non-empty = line in the file. head/etc/ntp.conf 259973 seems to still be the most = recent in head's svn area. And /etc/ntp.conf is unedited: > # diff /etc/ntp.conf /usr/src/etc/ntp.conf=20 > #=20 As of the the earlier "svnlite update /usr/src -r280598" to match that = earlier snapshot I was not getting such messages from the earlier build. Context details: > # more /etc/rc.conf > hostname=3D"FBSDG5C0" > ifconfig_bge0=3D"DHCP" > ifconfig_bge0_ipv6=3D"inet6 accept_rtadv" > ifconfig_gem0=3D"DHCP" > ifconfig_gem0_ipv6=3D"inet6 accept_rtadv" > sshd_enable=3D"YES" > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > hald_enable=3D"YES" > dbus_enable=3D"YES" > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CFLAGS+=3D-L/usr/obj/usr/src/tmp/usr/lib/. > CXXFLAGS+=3D-I/usr/obj/usr/src/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/src/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 04:03:59 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 201C1D9B; Wed, 1 Apr 2015 04:03:59 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (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 64D64D85; Wed, 1 Apr 2015 04:03:58 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NM400F1D0MC1H40@st11p02mm-asmtp001.mac.com>; Wed, 01 Apr 2015 04:03:51 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-01_02:2015-03-31,2015-04-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504010039 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: [CFT] Call for testing pkg 1.5.0 From: Rui Paulo In-reply-to: Date: Tue, 31 Mar 2015 21:03:48 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <1427829555.3892.7.camel@hardenedbsd.org> <20150331192315.GH30115@ivaldir.etoilebsd.net> To: Sergei Vyshenski X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Wed, 01 Apr 2015 11:24:02 +0000 Cc: pkg@freebsd.org, Baptiste Daroussin , current@freebsd.org, stable@freebsd.org, Shawn Webb , ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 04:03:59 -0000 On Mar 31, 2015, at 17:24, Sergei Vyshenski = wrote: > Instead, the following succeded: > # cd /usr/ports/ports-mgmt/pkg-devel > # make reinstall > ... > # pkg -v > 1.4.99.16 That is expected. WITH_PKG=3Ddevel is a make(1) option that only = affects ports (non-binary pkgs). -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 11:53:53 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 217A5DC0 for ; Wed, 1 Apr 2015 11:53:53 +0000 (UTC) Received: from nm10-vm2.access.bullet.mail.bf1.yahoo.com (nm10-vm2.access.bullet.mail.bf1.yahoo.com [216.109.114.209]) (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 BF2958A for ; Wed, 1 Apr 2015 11:53:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1427888907; bh=50ftUWhAqNA/N5/U8DtKqguIpSq/9FOzptW+CxCnJ14=; h=Date:From:To:CC:Subject:References:From:Subject; b=H2/wOY9mBGXehy3PaTM9pIm5hGx7AS5Kw1OOHVELC/nYxipeCNNrXN9m5uMUopQQbTmO0ff9Pk9CAUcfSait7zumtD7paXcQmX3wtnMvbWgiS6yh2XHlK+ooPRbW1Bw3KqJQHM0/gTLznb0/3NgmNOyrzm6EA0Ca3FNELN9g9gvlC6SmvIo7KrA1Q4gMDOgZTSKSFWBTUEspBXY9hSm/k9RIBgNwqp8+ulpUalC6A3Ye+mDybwEJE99yHxnBxpzgJ6bmQj3m6UQin/GI8Sq0d5mhONa6cb2RrRq6AWBRqJKZmZDi6V/5E9IGnmb7lhVSHFEdgC/WyiqUuDdwQonrTA== Received: from [66.196.81.157] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 11:48:27 -0000 Received: from [98.138.226.243] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 11:48:27 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 11:48:27 -0000 X-Yahoo-Newman-Id: 212148.13892.bm@smtp114.sbc.mail.ne1.yahoo.com Message-ID: <212148.13892.bm@smtp114.sbc.mail.ne1.yahoo.com> Date: Wed, 1 Apr 2015 11:48:27 +0000 (UTC) X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tlmLAiUVM1lbWlbbpdj9gJkb25snXyOsZT7zmHUk5H7Rz9O CF4x7cxqp12v55nP2PCXSuiu4mTigE8Tp4XRvnop8KFIjLRjgunxMhHtU2LG mk1puTQf_qDO05ABE3mH.c0E1M8DQ7tS1v14qLoRWm97kcHAmFlz3nPhA7Uh 3Ou6qkW2RmbjVi60MOtYIj1o_3XVZ_lgsmHq5iyohSgvXJIOaiqH7LovfHWX 4Sie3wiY.vufqN5TaLnpM4zQrtv9FeZt2JXBBC36N2Kf2ulFr2E9BXfDc15V l2JmxBkSt1jpsZNIND.ED34pmYGnEBDEIlhJUr7ujj5w2sO1SlCRXm5.598S 6IkHsFgwqpXY64mQ5lWnNVDbToq5FPTq7CbcdUlhCMv9JnL1u5pEJ5GV5u9u k0Sc5jYcciSJa__3fkUyBoFdDHZEtWSlCg0r3kzyTgXIFdlbLs0dFkZqZYsN _gzNo8M2DnhC4CDA2IsHjTIq8MdIjGGbCiY5k6j6iEm1EJTjwOPzt7z.Utd1 l8IX6nLLSPa78nVqINv8LwOjp25Hb8YKsn7bEBpMW5b4GwMovEo9w2o3IGob y8PK8qoCu32bpZMjnHo1fTn2t8HgzqcVDaGysB8biSWSObOr8618vHw-- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- From: "Thomas Mueller" To: freebsd-ports@freebsd.org Subject: Re: [CFT] Call for testing pkg 1.5.0 References: <20150331190323.GF30115@ivaldir.etoilebsd.net> Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 11:53:53 -0000 Excerpt from Baptiste Daroussin: - Initial support for OS X - Initial support for NetBSD/EdjeBSD How would pkg-1.5.0 integrate with NetBSD pkgsrc? I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is such a plan in the works? EdjeBSD should be EdgeBSD. A little spelling error can be critical when trying to find something on the Internet. Web site is edgebsd.org (I just went there). Tom From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 12:15: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 0AFB5B45; Wed, 1 Apr 2015 12:15:44 +0000 (UTC) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 B1362336; Wed, 1 Apr 2015 12:15:43 +0000 (UTC) Received: by ykef74 with SMTP id f74so13366213yke.1; Wed, 01 Apr 2015 05:15:42 -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=wF4oldX5FDUnjyltjHqpYFjbTiUF5GUuE0Pz9zfK3+s=; b=qdtcfw+PgyuqqoNJ5Bx1u2o9ikl4pIHSV6V8A1oJ8Lb7mzgHIGdnrbpmlviyVm3KqS 9YV1YdYZtw7iXdP5EcXay+Sr23QAldkhie5S5SFGrRA20tYlBkqK2BRiva8LH5I7v+W+ 1JzuZ4Vpj77wVA6mqjeKp6GyazsQA0tjcmuBP5sK9n2yWP/yA4G4dxftktsuA+6ltBRU nNzmmef9aAHWGJ51uRrnatyimQi72cA/C/8NR36RlJHbZMovmDPWa8FR0RSw5WYUluDB PcEIdSU5hkZ+cTHY18uDIRpnLsX9Qt80Sii2O9HvFniIoNYm/EjfZoVZncxZ2svUXRzv kt1A== X-Received: by 10.52.146.179 with SMTP id td19mr42052674vdb.8.1427890542796; Wed, 01 Apr 2015 05:15:42 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id cw4sm275900vdd.14.2015.04.01.05.15.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 05:15:41 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 1 Apr 2015 14:15:37 +0200 From: Baptiste Daroussin To: Thomas Mueller Subject: Re: [CFT] Call for testing pkg 1.5.0 Message-ID: <20150401121537.GP30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <212148.13892.bm@smtp114.sbc.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3bc47Eih9dS+biPM" Content-Disposition: inline In-Reply-To: <212148.13892.bm@smtp114.sbc.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: stable@freebsd.org, current@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 12:15:44 -0000 --3bc47Eih9dS+biPM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 01, 2015 at 11:48:27AM +0000, Thomas Mueller wrote: > Excerpt from Baptiste Daroussin: >=20 > - Initial support for OS X > - Initial support for NetBSD/EdjeBSD >=20 > How would pkg-1.5.0 integrate with NetBSD pkgsrc? >=20 > I didn't think there were any plans to port FreeBSD ports to NetBSD. Or = is such a plan in the works? >=20 There are people looking at integrating pkg with pkgsrc yes, don't know the status, (pkg is already in pkgsrc-wip but no further integration for what I= do know And yes you are right it is EdgeBSD not EdjeBSD sorry. Best regards, Bapt --3bc47Eih9dS+biPM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUb4WkACgkQ8kTtMUmk6Eya1ACeI6TC/Bn3jCMudXeXN4C0Krsz wMgAnik3eN+pOjO7AmIAsqUb2fS0l1ii =C+pT -----END PGP SIGNATURE----- --3bc47Eih9dS+biPM-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 12:56:53 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42B2DD80; Wed, 1 Apr 2015 12:56:53 +0000 (UTC) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 F19729BC; Wed, 1 Apr 2015 12:56:52 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net ([86.5.162.61]:64772 helo=[192.168.0.7]) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:465) with esmtpsa (PLAIN:dc552) (TLSv1:DHE-RSA-AES256-SHA:256) id 1YdICI-0003a9-6o (Exim 4.82_3-c0e5623) (return-path ); Wed, 01 Apr 2015 13:56:42 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: [CFT] Call for testing pkg 1.5.0 From: David Chisnall In-Reply-To: Date: Wed, 1 Apr 2015 13:56:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <1427829555.3892.7.camel@hardenedbsd.org> <20150331192315.GH30115@ivaldir.etoilebsd.net> To: Rui Paulo X-Mailer: Apple Mail (2.2070.6) Sender: "Dr D. Chisnall" X-Mailman-Approved-At: Wed, 01 Apr 2015 13:08:32 +0000 Cc: pkg@freebsd.org, Baptiste Daroussin , Sergei Vyshenski , current@freebsd.org, stable@freebsd.org, Shawn Webb , ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 12:56:53 -0000 On 1 Apr 2015, at 05:03, Rui Paulo wrote: >=20 > That is expected. WITH_PKG=3Ddevel is a make(1) option that only = affects ports (non-binary pkgs). Are you sure? I have it in make.conf on one of my systems where I never = build ports manually (and don't even have a ports tree installed) and = there I get this: $ pkg -v 1.4.99.13 In a jail on the same machine without the make.conf entry, I get the = stable version. This is how I've been testing pkg-devel for a while. = Is there a different recommended way? David From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 13:15:42 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 D47E0713; Wed, 1 Apr 2015 13:15:42 +0000 (UTC) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 829C0C2D; Wed, 1 Apr 2015 13:15:42 +0000 (UTC) Received: by ykfa3 with SMTP id a3so9718832ykf.0; Wed, 01 Apr 2015 06:15:41 -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=Z0lDlu0dyPcx+lALNPNsvjmhZtyd05wYK6A5koxxGdU=; b=r2Yo47juUQvHIR6s1qh0DKRbxfmilzyBSm64+kRUXVgIIVL5uN51BO32pS8VAZi3Qh Tiob69paKZuLDfpv9KigIjOos/ChLL++SughSNsJRbZ24nnl39S2Q9Z8fc6E4iJmSvFg LVPzUGni1qrW5FVjBvHi0kMfD1xCHbE3fSltlp0u4I5HKSvW19pmYxA5M3u4pCP3XKPF GLoToBXrcdgt7wXpMVzFX0neubgka2/Rx5VDsDijSHpPN+TIO0LuWQQdwpFYXop8bzSW sByP7J/Dhz9Wi6eNRMQ0ZbBH7PjtQuiFc7YFhFiBsadiyaDAIE/HN4MJLMqRMF2XA492 Kj+A== X-Received: by 10.52.38.166 with SMTP id h6mr41892204vdk.80.1427894141784; Wed, 01 Apr 2015 06:15:41 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fa2sm296639vdd.17.2015.04.01.06.15.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 06:15:40 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 1 Apr 2015 15:15:36 +0200 From: Baptiste Daroussin To: David Chisnall Subject: Re: [CFT] Call for testing pkg 1.5.0 Message-ID: <20150401131536.GQ30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <1427829555.3892.7.camel@hardenedbsd.org> <20150331192315.GH30115@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yFH6hwN92mUA4HK5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: pkg@freebsd.org, stable@freebsd.org, Sergei Vyshenski , current@freebsd.org, Rui Paulo , Shawn Webb , ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 13:15:43 -0000 --yFH6hwN92mUA4HK5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 01, 2015 at 01:56:38PM +0100, David Chisnall wrote: > On 1 Apr 2015, at 05:03, Rui Paulo wrote: > >=20 > > That is expected. WITH_PKG=3Ddevel is a make(1) option that only affec= ts ports (non-binary pkgs). >=20 > Are you sure? I have it in make.conf on one of my systems where I never = build ports manually (and don't even have a ports tree installed) and there= I get this: >=20 > $ pkg -v > 1.4.99.13 >=20 > In a jail on the same machine without the make.conf entry, I get the stab= le version. This is how I've been testing pkg-devel for a while. Is there= a different recommended way? >=20 That is because you enforced installing pkg-devel one day via: pkg install pkg-devel probably then it will stay on pkg-devel :) pkg itself is not aware of make.conf Best regards Bapt --yFH6hwN92mUA4HK5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUb73gACgkQ8kTtMUmk6EyhkgCfaqp6t97I3ATVaInQuCOkvUrX Q/EAn3Te+4baGaRVFkcM0p09KU6C88N/ =J+VI -----END PGP SIGNATURE----- --yFH6hwN92mUA4HK5-- From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 14:27: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 99490996 for ; Wed, 1 Apr 2015 14:27:14 +0000 (UTC) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC373EA for ; Wed, 1 Apr 2015 14:27:13 +0000 (UTC) Received: from itz-mail.htw-saarland.de (itz-mail.htw-saarland.de [134.96.210.141]) by triton.rz.uni-saarland.de (8.14.9/8.14.0) with ESMTP id t31ERACr023862; Wed, 1 Apr 2015 16:27:11 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.6 at HIZ-Mailrelay triton.rz.uni-saarland.de Received: from magritte.htw-saarland.de (magritte.htw-saarland.de [134.96.214.195]) by itz-mail.htw-saarland.de (8.14.5/8.14.5) with ESMTP id t31ERAIH011721; Wed, 1 Apr 2015 16:27:10 +0200 (CEST) Date: Wed, 1 Apr 2015 16:27:05 +0200 (CEST) From: Damian Weber To: Hans Petter Selasky , Kurt Jaeger Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 In-Reply-To: <5516BC51.6080108@selasky.org> Message-ID: References: <5516BC51.6080108@selasky.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.3 at itz-mail X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (triton.rz.uni-saarland.de [134.96.7.25]); Wed, 01 Apr 2015 16:27:11 +0200 (CEST) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 14:27:14 -0000 > Try adding some quirks: > > usbconfig dump_quirk_names | grep MSC > > --HPS Dear Hans Petter and Kurt, thank you for your great advice, I successfully attached my Verbatim USB drive the magic lines are in ./dev/usb/usbdevs : +vendor VERBATIM 0x18a5 Verbatim +product VERBATIM STORENGO 0x0243 Verbatim Store N Go in ./dev/usb/quirk/usb_quirk.c /* copied from SANDISK, SDCZ2_128 */ + USB_QUIRK(VERBATIM, STORENGO, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, + UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_IGNORE_RESIDUE, + UQ_MSC_NO_SYNC_CACHE), result: a) can mount it (mount_msdosfs) b) can read/write files (sha1-checksums verified) two questions remain 1) can the dmesg error messages be dealt with? ILLEGAL REQUEST asc:20,0 ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x4080 umass0:4:0: Attached to scbus4 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe0:umass-sim0:0:0:0): Error 22, Unretryable error da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: 40.000MB/s transfers da0: 14909MB (30535401 512 byte sectors: 255H 63S/T 1900C) da0: quirks=0x2 2) is it possible to modify usb_quirk.c without going through the whole make-kernel dance? Best wishes Damian From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 14:37:21 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 9141FD6E for ; Wed, 1 Apr 2015 14:37:21 +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 4FD0E763 for ; Wed, 1 Apr 2015 14:37:21 +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 1C2C61FE023; Wed, 1 Apr 2015 16:37:19 +0200 (CEST) Message-ID: <551C02CB.4000201@selasky.org> Date: Wed, 01 Apr 2015 16:38:03 +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: Damian Weber , Kurt Jaeger Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 References: <5516BC51.6080108@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 14:37:21 -0000 On 04/01/15 16:27, Damian Weber wrote: > >> Try adding some quirks: >> >> usbconfig dump_quirk_names | grep MSC >> >> --HPS > > Dear Hans Petter and Kurt, thank you for your great advice, > I successfully attached my Verbatim USB drive > > the magic lines are > > in ./dev/usb/usbdevs : > > +vendor VERBATIM 0x18a5 Verbatim > +product VERBATIM STORENGO 0x0243 Verbatim Store N Go > > in ./dev/usb/quirk/usb_quirk.c > > /* copied from SANDISK, SDCZ2_128 */ > > + USB_QUIRK(VERBATIM, STORENGO, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, > + UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_IGNORE_RESIDUE, > + UQ_MSC_NO_SYNC_CACHE), > > > result: > a) can mount it (mount_msdosfs) > b) can read/write files (sha1-checksums verified) > > two questions remain > > 1) can the dmesg error messages be dealt with? ILLEGAL REQUEST asc:20,0 > > ugen2.2: at usbus2 > umass0: on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x4080 > umass0:4:0: Attached to scbus4 > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) > (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Removable Direct Access SPC-4 SCSI device > da0: 40.000MB/s transfers > da0: 14909MB (30535401 512 byte sectors: 255H 63S/T 1900C) > da0: quirks=0x2 > > 2) is it possible to modify usb_quirk.c without > going through the whole make-kernel dance? > Hi, If usb_quirk is built like a module you only rebuild that and load. Can you put this quirk and patch in a PR and assign to me and I'll get it in! --HPS From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 15:34:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCEC96E1 for ; Wed, 1 Apr 2015 15:34:03 +0000 (UTC) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCDBEE10 for ; Wed, 1 Apr 2015 15:34:03 +0000 (UTC) Received: from T61p.pozo.com (t61p.pozo.com [192.168.0.4]) (authenticated bits=0) by pozo.com (8.14.9/8.14.9) with ESMTP id t31FWRhp059914 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Apr 2015 08:33:43 -0700 (PDT) (envelope-from null@pozo.com) Message-Id: <201504011533.t31FWRhp059914@pozo.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Apr 2015 08:32:15 -0700 To: freebsd-current@freebsd.org From: Manfred Antar Subject: ntpd errors after upgrade on current amd64 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-102.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, MISSING_MID,URIBL_BLOCKED,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0, No X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: t31FWRhp059914 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 15:34:03 -0000 After build install world on current ntpd doesn't work. Here is error: FreeBSD/amd64 (pozo.com) (ttyu0) login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax error Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%2 fails: Can't assign requested address I'm using the stock ntp.conf from /usr/src/etc. It worked fine before the upgrade Thanks ======================== || null@pozo.com || || || ======================== From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 16:55:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34CF4B0A for ; Wed, 1 Apr 2015 16:55:45 +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 B7C049CB for ; Wed, 1 Apr 2015 16:55:44 +0000 (UTC) Received: by wixo5 with SMTP id o5so56397135wix.1 for ; Wed, 01 Apr 2015 09:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=jeqlEaXgQK/+CDz9vTihV3g2UoyERvuwN1OM6HnIa4Y=; b=TkaBcxteT+CbaYBZReqBzqYp1uxtkn2URMFN2cu4DmCrjwHFvus6fUr3nBeGQtbn4N 7NaBJInB8GPDacvs7w+oSzDZ05IlYyi6evpSa5sTq3mKm/zNIF8pDHKu8F82PI/bNCPc 0MyhCTn+YmWQ5+j/JPEsVDppnONS9Wr1is9Mo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=jeqlEaXgQK/+CDz9vTihV3g2UoyERvuwN1OM6HnIa4Y=; b=M1S0pSU+9Mp3OTpFuu5q+METP4uKyJPNiSuxuW8H60G7RirO43WIVsqWEYmCvrm1J0 owCcHLfVBY8kIoAZgoNMklE3SXC0XlSCG8RJNy7F//R5eTFB13FMbjwHBkVrLu8KXxYA gl/xc+gZKfz57IbVv674aN0F9c2ZzXDCcQ/r3hQNGBC0MYCaOljV3smWM8t+5Lw10EqO vnNfFOEXKB25XKwFcsi7bxjlZyqCKN6l3Db2yGkt/u+5eAPlQNGcLRSBb7UD/NW2Yra4 5GTxyU6/mOP5hBznH1J79aJRJtzrq4iJ0Y4Dg4uQneaYp0sXUBaV7xsmkT+HLn3d82/Z +0oA== X-Gm-Message-State: ALoCoQl475KK8Y4F3A/QhIYc4j3giJTp6FxxEj5Qcp/JfXeWvm6FUUOJxcRwq6qj5cEUL5Iea5hu X-Received: by 10.180.77.40 with SMTP id p8mr16616050wiw.1.1427907343117; Wed, 01 Apr 2015 09:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.135 with HTTP; Wed, 1 Apr 2015 09:55:11 -0700 (PDT) From: Eitan Adler Date: Wed, 1 Apr 2015 09:55:11 -0700 Message-ID: Subject: Bazaaring the cathedral (Lowering the Barrier to Entry) To: FreeBSD Hackers , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 16:55:45 -0000 Hi all, FreeBSD today has a significant problem of attracting new developers. The lack of new developers manifests itself in a dearth of driver support, inadequate documentation, and trailing third party packages. One of the key reasons for the lack of people is the high barrier of entry to joining the FreeBSD project. While every modern project uses git (usually hosted on github), FreeBSD uses self-hosted subversion. The use of git goes beyond just the choice of version control. It allows for workflows that FreeBSD can't even dream of. The linux kernel has no concept of a committer. Instead anyone can clone the git tree, build a kernel, and call themselves a Linux distribution. Our wiki and code review tools are in an even worse position than our repository. In order to contribute you need to send an email to clusteradm@ and hope they deem you worthy enough of access. The bug tracking system is in a better shape but isn't perfect: while any user can create an account, their privileges are limited: they can't help close out bad PRs, reclassify good ones, or do other generally useful work. To solve this problem I propose a simple solution: self-serve commit access. We create a web service on accounts.freebsd.org via which users can create themselves a freefall account. In addition to a freefall account, the identical username would be created for the wiki and phabricator, bugzilla, and any other service we might provide. This will allow us to quickly gain large number of contributors, who will be able to make better progress on our missing features, and rectify some of the drawbacks listed above. Today I hope we turn ourselves from the cathedral into a truly open and democratic project! -- Eitan Adler From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 17:29: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 CFB09A0A; Wed, 1 Apr 2015 17:29:07 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010: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 4D802DAF; Wed, 1 Apr 2015 17:29:07 +0000 (UTC) Received: by lahf3 with SMTP id f3so41586381lah.2; Wed, 01 Apr 2015 10:29:05 -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=4Rl+8yuxKvNtdD6G45a/kp5iYeKktLh6tKua40pyXfY=; b=rDDQ+KZ5mvaFSJQ8AAlP6UHoRFXPZFwrmcq6Jvvt/5rUcd1E/tgh1P06dYitOSWflf JKYfwViKjIsGfri6LD8yhPisVbEQkEnRyJeOartzd1B5Av8Ek1Rh+ByG6LIpCB+WUpc+ kZA5fF77kG97GOYfmXjRF1DW41o7dWKJXjsjkQHNTSXS8vLS2Ntx6cOQCtMsfSJ9BgAw LyUVv6yypVCpI6c/0M5lvTMDpMPQrK5vOtOtQK7Uw9njwyqZKjgjcaMJW/vmmlFKvD1S jbgJ2lOlc0mskYsunCZOhWpcmgzY7zbKTsqsAjgdgFzMCrOGLVBakixMPDwln6+LnTm9 ZxBQ== MIME-Version: 1.0 X-Received: by 10.112.8.76 with SMTP id p12mr33189488lba.29.1427909345423; Wed, 01 Apr 2015 10:29:05 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Wed, 1 Apr 2015 10:29:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Apr 2015 10:29:05 -0700 X-Google-Sender-Auth: E3k1euLDb8bhsd4DB6j-pDs5vII Message-ID: Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) From: Craig Rodrigues To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Hackers , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 17:29:07 -0000 On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. > I support the creation of accounts.freebsd.org. I suggest that we use PWM ( http://code.google.com/p/pwm/ ) as a web-based front-end to a back-end LDAP database. The FreeBSD cluster already has LDAP ( https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#kerberos-ldap ) The FreeBSD cluster LDAP + Kerberos back-end infrastructure is something developed by clusteradm (most likely Peter Wemm). It works quite well. I succeeded in using the FreeBSD cluster LDAP system for Jenkins authentication, and it just worked like a champ. The FreeBSD cluster LDAP system just needs a better front-end that is more user friendly, and easier to manage. If you log into hub.freebsd.org and look at /etc/aliases, you will see that there are 12 people who receive clusteradm e-mails. My experience working with Jenkins is that only about 2-3 people actively do clusteradm work, and they are *way* overloaded. If we could have accounts.freebsd.org which streamlines a lot of the account creation and management, and works across many modern web applications, that would be super cool, and would hopefully reduce the load on clusteradm! -- Craig From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:09:15 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 3382C68C; Wed, 1 Apr 2015 19:09:15 +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 E9B10B72; Wed, 1 Apr 2015 19:09:14 +0000 (UTC) Received: by igbud6 with SMTP id ud6so57297017igb.1; Wed, 01 Apr 2015 12:09: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=QFB8CU9/vT7S6LG9GcJZPnJyiYLb7qZm/KY2EBE3bvQ=; b=og0vZpteMugp5LFsfWuTVma23iv9ie8iWInF+AVf1zO4QxzEDjQzAaFwc6v2lKUqDE xntj3v8YFzqkYrJsflfIsRKEd6RtRcoFKKjRjx5cYCnRxO7C3CLZMN42PXLVybmbwxX3 eaq+fd14bxAJifslijlwxnX5/ZxQ73WwY3GAjzZfQCpxIyPYL9BeAUNgufqFdxy3BSfH 50CsNJgzhsZVrIz5WjWGtM/8rtzNfxMZujSVeAluUsUls113FS8n1cHytdb0kRA0D6va IEtA7hTbeczelWA4XmarfMTR8ltMiBR9xHiP3rw65viXkzaHwsrzCLzR61hCA45u6qLT 9Bbw== MIME-Version: 1.0 X-Received: by 10.50.67.100 with SMTP id m4mr14345667igt.32.1427915354423; Wed, 01 Apr 2015 12:09:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Wed, 1 Apr 2015 12:09:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Apr 2015 12:09:14 -0700 X-Google-Sender-Auth: mYRIk_gGE835OskVq20rZWHcB5s Message-ID: Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) From: Adrian Chadd To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: Eitan Adler , freebsd-current Current , FreeBSD Hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 19:09:15 -0000 You mean, like sourceforge offered in 2000? :) -a From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:17:41 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 20387CB8 for ; Wed, 1 Apr 2015 19:17:41 +0000 (UTC) Received: from theia.rz.uni-saarland.de (theia.rz.uni-saarland.de [134.96.7.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9483AC89 for ; Wed, 1 Apr 2015 19:17:40 +0000 (UTC) Received: from itz-mail.htw-saarland.de (itz-mail.htw-saarland.de [134.96.210.141]) by theia.rz.uni-saarland.de (8.14.9/8.14.0) with ESMTP id t31JHW7l017121; Wed, 1 Apr 2015 21:17:32 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.6 at HIZ-Mailrelay theia.rz.uni-saarland.de Received: from magritte.htw-saarland.de (magritte.htw-saarland.de [134.96.214.195]) by itz-mail.htw-saarland.de (8.14.5/8.14.5) with ESMTP id t31JHWeY001721; Wed, 1 Apr 2015 21:17:32 +0200 (CEST) Date: Wed, 1 Apr 2015 21:17:27 +0200 (CEST) From: Damian Weber To: Hans Petter Selasky Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 In-Reply-To: <551C02CB.4000201@selasky.org> Message-ID: References: <5516BC51.6080108@selasky.org> <551C02CB.4000201@selasky.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.97.3 at itz-mail X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (theia.rz.uni-saarland.de [134.96.7.31]); Wed, 01 Apr 2015 21:17:32 +0200 (CEST) Cc: Kurt Jaeger , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 19:17:41 -0000 On Wed, 1 Apr 2015, Hans Petter Selasky wrote: > Date: Wed, 1 Apr 2015 16:38:03 > From: Hans Petter Selasky > To: Damian Weber , Kurt Jaeger > Cc: freebsd-current@freebsd.org > Subject: Re: umass, Verbatim STORE N GO drive, CAM status 0x50 > > On 04/01/15 16:27, Damian Weber wrote: > > > > > Try adding some quirks: > > > > > > usbconfig dump_quirk_names | grep MSC > > > > > > --HPS > > > > Dear Hans Petter and Kurt, thank you for your great advice, > > I successfully attached my Verbatim USB drive > > > > the magic lines are > > > > in ./dev/usb/usbdevs : > > > > +vendor VERBATIM 0x18a5 Verbatim > > +product VERBATIM STORENGO 0x0243 Verbatim Store N Go > > > > in ./dev/usb/quirk/usb_quirk.c > > > > /* copied from SANDISK, SDCZ2_128 */ > > > > + USB_QUIRK(VERBATIM, STORENGO, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB, > > + UQ_MSC_FORCE_PROTO_SCSI, UQ_MSC_IGNORE_RESIDUE, > > + UQ_MSC_NO_SYNC_CACHE), > > > > > > result: > > a) can mount it (mount_msdosfs) > > b) can read/write files (sha1-checksums verified) > > > > two questions remain > > > > 1) can the dmesg error messages be dealt with? ILLEGAL REQUEST asc:20,0 > > > > ugen2.2: at usbus2 > > umass0: on usbus2 > > umass0: SCSI over Bulk-Only; quirks = 0x4080 > > umass0:4:0: Attached to scbus4 > > (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 > > 00 00 > > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > > (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid > > command operation code) > > (probe0:umass-sim0:0:0:0): Error 22, Unretryable error > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > da0: Removable Direct Access SPC-4 SCSI device > > da0: 40.000MB/s transfers > > da0: 14909MB (30535401 512 byte sectors: 255H 63S/T 1900C) > > da0: quirks=0x2 > > > > 2) is it possible to modify usb_quirk.c without > > going through the whole make-kernel dance? > > > > Hi, > > If usb_quirk is built like a module you only rebuild that and load. > > Can you put this quirk and patch in a PR and assign to me and I'll get it in! > > --HPS > PR filed as Bug 199101 has been added to the database Email sent to: freebsd-usb@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 23:09:55 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 E1FFA6E7; Wed, 1 Apr 2015 23:09:55 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F0A55A39; Wed, 1 Apr 2015 23:09:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id CAA01636; Thu, 02 Apr 2015 02:07:05 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1YdRgS-0005DF-5B; Thu, 02 Apr 2015 02:04:28 +0300 Message-ID: <551C7840.4020409@FreeBSD.org> Date: Thu, 02 Apr 2015 01:59:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eitan Adler , FreeBSD Hackers , freebsd-current Current Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) References: 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.18-1 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, 01 Apr 2015 23:09:56 -0000 On 01/04/2015 19:55, Eitan Adler wrote: > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. Your proposal is incomplete because itd oesn't say anything about booking a mentor. Even if it's a bazaar a neophyte still has to get themselves a mentor, JIMHO. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Apr 1 19:09:02 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 19990668 for ; Wed, 1 Apr 2015 19:09:02 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 C6DB5B6F for ; Wed, 1 Apr 2015 19:09:01 +0000 (UTC) Received: (qmail 30493 invoked from network); 1 Apr 2015 19:08:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Apr 2015 19:08:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 01 Apr 2015 15:08:58 -0400 (EDT) Received: (qmail 5734 invoked from network); 1 Apr 2015 19:08:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Apr 2015 19:08:57 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id A4B3D1C43A2; Wed, 1 Apr 2015 12:08:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages From: Mark Millard In-Reply-To: <52A97222-C183-4CDC-8FA5-A4CA7552BF5F@dsl-only.net> Date: Wed, 1 Apr 2015 12:08:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A97222-C183-4CDC-8FA5-A4CA7552BF5F@dsl-only.net> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Thu, 02 Apr 2015 02:56:33 +0000 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Apr 2015 19:09:02 -0000 I rebuilt and the boot-message line > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error is no longer is occurring. But I'm still getting the other two: > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for = [omitted] fails: Can't assign requested address > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for = [omitted] fails: Can't assign requested address =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-31, at 07:13 PM, Mark Millard = wrote: Basic context: > $ dmesg | head > ... > FreeBSD 11.0-CURRENT #3 r280867M: Tue Mar 31 16:19:53 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > $ freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r280867M: Tue = Mar 31 16:19:53 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100067 1100066 I normally do not go beyond the most recent 11.0-CURRENT snapshot = (-r280862 at this point) but I wanted to pick up the the checkins that = enable building the system clang via powerpc64-xtoolchain-gcc's = powerpc64-gcc (as part of a self-hosted rebuild). So I choose to: = svnlite update /usr/src -r280867 . I also later did "svnlite update /usr/src/contrib/ntp/ -r280915" because = the overall the -r280867 vintage materials in that area failed to = compile. Other than -r280915's contrib/ntp/ntpd/ntp_parser.y, contrib/ntp/... is = the -r280849 update that would have been in a -r280862 snapshot. The problem (new ntpd error messages but probably not important to my = activities): After buildworld buildkernel installkernel installworld and rebooting it = now reports during the boot (with a little context shown): > ... > Starting sendmail_submit. > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for = [omitted] fails: Can't assign requested address > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for = [omitted] fails: Can't assign requested address > Starting sendmail_msp_queue. > ... The "line 22 column 1 syntax error" is not explicit about the file = involved. Presuming /etc/ntp.conf ... > # > # $FreeBSD: head/etc/ntp.conf 259973 2013-12-27 23:06:15Z delphij $ > # > ... > # The option `iburst' is used for faster initial synchronization. > # > server 0.freebsd.pool.ntp.org iburst > server 1.freebsd.pool.ntp.org iburst > server 2.freebsd.pool.ntp.org iburst > #server 3.freebsd.pool.ntp.org iburst > ... That first "server" line is line 22 and is the first non-#/non-empty = line in the file. head/etc/ntp.conf 259973 seems to still be the most = recent in head's svn area. And /etc/ntp.conf is unedited: > # diff /etc/ntp.conf /usr/src/etc/ntp.conf=20 > #=20 As of the the earlier "svnlite update /usr/src -r280598" to match that = earlier snapshot I was not getting such messages from the earlier build. Context details: > # more /etc/rc.conf > hostname=3D"FBSDG5C0" > ifconfig_bge0=3D"DHCP" > ifconfig_bge0_ipv6=3D"inet6 accept_rtadv" > ifconfig_gem0=3D"DHCP" > ifconfig_gem0_ipv6=3D"inet6 accept_rtadv" > sshd_enable=3D"YES" > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > hald_enable=3D"YES" > dbus_enable=3D"YES" > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CFLAGS+=3D-L/usr/obj/usr/src/tmp/usr/lib/. > CXXFLAGS+=3D-I/usr/obj/usr/src/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/src/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 03:12:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22764A95; Thu, 2 Apr 2015 03:12:45 +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 D8E1B84D; Thu, 2 Apr 2015 03:12:44 +0000 (UTC) Received: by igcau2 with SMTP id au2so42310641igc.1; Wed, 01 Apr 2015 20:12: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=UaS0PbVB1MgxPTXl2vMYsVTCBaSWn/dIegplQyE6Ftg=; b=KLSWMRix2jcR/jRkEQQXDgsbp0A8KGk3AgGeaIP+GdhW0xbmSj/E/jOiqwrfpAsFij B34dpn+yrb8sZlbbbk2zReSbkG1ZwophDwYeM41TeyBtyRRH1ULSFmqXY+MK/fE34MKb FzH42h2TofQ9wvIwb9IZCbLuYA4UA51NWn3BZvyWcp6B0IhORvw70rEWKEl/PmS27vKI ROnUZKgJKb65nte2H1t9Nr+zs7kfaCMdVgqNhFMYBUe3vVQeFRin7zZa9UI8Ytc98JpB n0rax7ECn0ERIMcOzSEyuZ2ZwINyJY0inUidIn36Vzfo75FGo25eGD8QKpQVU06gc7Cb JjVA== MIME-Version: 1.0 X-Received: by 10.50.143.36 with SMTP id sb4mr16735377igb.0.1427944364376; Wed, 01 Apr 2015 20:12:44 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 1 Apr 2015 20:12:44 -0700 (PDT) In-Reply-To: References: <52A97222-C183-4CDC-8FA5-A4CA7552BF5F@dsl-only.net> Date: Wed, 1 Apr 2015 20:12:44 -0700 X-Google-Sender-Auth: iCq1TOZNzZOmJelZT8n9W5e05o4 Message-ID: Subject: Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages From: Kevin Oberman To: Mark Millard Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 03:12:45 -0000 On Wed, Apr 1, 2015 at 12:08 PM, Mark Millard wrote: > I rebuilt and the boot-message line > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > > > is no longer is occurring. But I'm still getting the other two: > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for > [omitted] fails: Can't assign requested address > > > === > Mark Millard > markmi at dsl-only.net > This is probably way too obvious, but is the system configured for IPv6? -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 03:50: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 3F733F47; Thu, 2 Apr 2015 03:50:20 +0000 (UTC) Received: from Cns.Cns.SU (IPv6.Cns.SU [IPv6:2001:470:7240::]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "", Issuer "" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BAD59BED; Thu, 2 Apr 2015 03:50:10 +0000 (UTC) Received: from Cns.Cns.SU (cnst@localhost [127.0.0.1]) by Cns.Cns.SU (8.14.5/8.14.5) with ESMTP id t323o8CW003423 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 20:50:08 -0700 (PDT) Received: (from cnst@localhost) by Cns.Cns.SU (8.14.5/8.14.5/Submit) id t323o85M006949; Wed, 1 Apr 2015 20:50:08 -0700 (PDT) X-Authentication-Warning: Cns.Cns.SU: cnst set sender to cnst++@FreeBSD.org using -f Date: Wed, 1 Apr 2015 20:50:08 -0700 From: "Constantine A. Murenin" To: FreeBSD-advocacy@FreeBSD.org, FreeBSD-chat@FreeBSD.org, FreeBSD-current@FreeBSD.org, FreeBSD-doc@FreeBSD.org Subject: FreeBSD.org gets SANCTIONED .RU! Message-ID: <20150402035008.GH2206@Cns.Cns.SU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: cnst++@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 03:50:20 -0000 Dear FreeBSD-{advocacy,chat,current,doc}@, It has come to my attention that FreeBSD.org has been sanctioned today. It has been sanctioned in the category of best server OS. Some other sites sanctioned together with FreeBSD.org are OpenBSD.org for providing a desktop OS, NetBSD.org for powering toasters, and nginx.org for an engine with an X (not sure what that means, anyone?). http://We.Are.Sanctioned.RU/ Regardless, everyone, please keep up the good work! And feel free to nominate other web-sites with #SanctionedRU! Cheers, Constantine. From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 05:58: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 EBFCEBF7; Thu, 2 Apr 2015 05:58:54 +0000 (UTC) Received: from bitcloud.desync.com (bitcloud.desync.com [IPv6:2607:f178::100]) by mx1.freebsd.org (Postfix) with ESMTP id C2C2B8C8; Thu, 2 Apr 2015 05:58:54 +0000 (UTC) Received: from bitcloud.desync.com (localhost [127.0.1.100]) by bitcloud.desync.com (Postfix) with ESMTP id 7C1485E86D; Thu, 2 Apr 2015 01:58:46 -0400 (EDT) Received: from exile.desync.com (exile.desync.com [IPv6:2607:f178::167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bitcloud.desync.com (Postfix) with ESMTPSA id 3A8515E86C; Thu, 2 Apr 2015 01:58:46 -0400 (EDT) Date: Thu, 2 Apr 2015 01:58:45 -0400 From: ben wilber To: Mark Millard Subject: Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages Message-ID: <20150402055844.GB87787@exile.desync.com> References: <52A97222-C183-4CDC-8FA5-A4CA7552BF5F@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailer: NeXT Mail 3.3 X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3b1) X-Virus-Scanned: ClamAV+desync1124 Cc: freebsd-current@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 05:58:55 -0000 On Wed, Apr 01, 2015 at 12:08:55PM -0700, Mark Millard wrote: > I rebuilt and the boot-message line > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error > > > is no longer is occurring. But I'm still getting the other two: > > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for [omitted] fails: Can't assign requested address > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 for [omitted] fails: Can't assign requested address I've also noticed that net/bird6 can't seem to do OSPF on -CURRENT (r280426 here): Apr 2 05:41:32 midgar bird6: ospf0: Socket error on vlan2: Can't assign requested address vlan2 has both an auto_linklocal address and globally unique unicast address. From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 07:17:55 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 3F200266 for ; Thu, 2 Apr 2015 07:17:55 +0000 (UTC) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.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 BE32A211 for ; Thu, 2 Apr 2015 07:17:54 +0000 (UTC) Received: by lajy8 with SMTP id y8so53553603laj.0 for ; Thu, 02 Apr 2015 00:17:47 -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:date:message-id:subject:from:to :content-type; bh=npK22xDA8gT7K7mv8SfVNK0VkFhGbpYTELhR3l1/KAM=; b=WQd9tpuP6N8eM8JXRpzI+OU3du5oshNr6mTzS7+MCOlmimOUIoiGJ3P5iN+Rsc/ufV v9xrfDEo2phCMQtRK6H8lJJcid1L2Y+AWlB/VX8+lAqc9IoBNzQkaOsytBMyly2P6JM2 dlwuC85EZdkiUB+Q6FcmpxQlQdT6tQQILlmQ5DpbSzsspe/46jNFY4x0TnTSjK1hv1zc TN5QMKfwYb5Pg4iD+gij2QKkRrltTmwb6zD7ZypNThDT8hWQQOmKjM9LcvTFKRLJcqIh UOF3bLSvyGy06Lc+v7m01mEtFI1gp3CvgqFbpbBkU9kGerggbpfwi/J34dTUeKGbnT/G 4DMg== X-Gm-Message-State: ALoCoQk+WexGHvBDBBb82Zimtte9L60Ox3WtsD5z060hlwCass7K88nT6vTjnjaOCvMPEoF2Q4KN MIME-Version: 1.0 X-Received: by 10.152.239.135 with SMTP id vs7mr4029247lac.104.1427959067046; Thu, 02 Apr 2015 00:17:47 -0700 (PDT) Received: by 10.25.31.2 with HTTP; Thu, 2 Apr 2015 00:17:47 -0700 (PDT) Date: Thu, 2 Apr 2015 10:17:47 +0300 Message-ID: Subject: How to hotplug pci/e devices in freeBSD? (Or How to remove and rescan/re-enumerate pci device?) From: Eran Harpaz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 07:17:55 -0000 I'm looking for a way to refresh/re-enumerate the pci device list. In Linux, you can remove a particular pci device, and then after preforming a "rescan" the device will appear again. In Linux it is done by: echo 1 > /sys/bus/pci/devices/.../remove echo 1 > /sys/bus/pci/rescan I'm looking for a similar functionality in freeBSD. *What do I want to achieve?* I'm using freeBSD and my pcie device can be reset from the host. But when it boots again, it's uncommunicative, so I want to rescan the pci devices in order to initiate a new connection between the host and the device. Any idea would be appreciated, even if it takes some coding effort. Thanks! From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 08:58: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 E6D7584A for ; Thu, 2 Apr 2015 08:58:25 +0000 (UTC) Received: from frv158.fwdcdn.com (frv158.fwdcdn.com [212.42.77.158]) (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 A5EB6FC3 for ; Thu, 2 Apr 2015 08:58:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=+KwFu2ITemAywYLKvj5eFynjruZt911+hLYy7cTCVRQ=; b=tymDhQlqRJwqOUVgbrCv2Y/M2qQCrGNMzPKyMBMLQZD/ckxfCtRl/VgXy8lcEpoQrxV3mm8KJ4mRHgXolYeWg+oOe36EMLYPuGuxRYbdEHRszvBibOEkoiwP77J9oavuUvl1xb+v1j+Wgl0TWnggTOG/EezeB+R/Aiq/O00/1n8=; Received: from [178.137.139.0] (helo=nonamehost.local) by frv158.fwdcdn.com with esmtpsa ID 1Ydax7-000NXY-7d for current@freebsd.org; Thu, 02 Apr 2015 11:58:17 +0300 Date: Thu, 2 Apr 2015 11:58:17 +0300 From: Ivan Klymenko To: current@freebsd.org Subject: [SOLVED] Re: >r280312 - r280332 VirtualBox is broken. Message-ID: <20150402115817.297e6501@nonamehost.local> In-Reply-To: <20150322001311.34994231@nonamehost.local> References: <20150322001311.34994231@nonamehost.local> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=178.137.139.0; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 08:58:26 -0000 Sun, 22 Mar 2015 00:13:11 +0200 Ivan Klymenko =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2: > After auditing the r280312 I just upgraded to revision r280332 and > then discovered that my VirtualBox is broken. >=20 > Thanks. The problem was to use the port security/openssl. 1. Added WITH_OPENSSL_BASE=3Dyes > /etc/make.conf 2. Delete installed security/openssl 3. Rebuild VirtualBox and others depends ports From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 09:02: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 4C0BCC18; Thu, 2 Apr 2015 09:02:46 +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 08FB7F3; Thu, 2 Apr 2015 09:02:45 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 9451E1FE022; Thu, 2 Apr 2015 11:02:42 +0200 (CEST) Message-ID: <551D05DE.3070200@selasky.org> Date: Thu, 02 Apr 2015 11:03:26 +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: Eitan Adler , FreeBSD Hackers , freebsd-current Current Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) 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.18-1 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, 02 Apr 2015 09:02:46 -0000 On 04/01/15 18:55, Eitan Adler wrote: > One of the key reasons for the lack of people is the high barrier of > entry to joining the FreeBSD project. While every modern project uses > git (usually hosted on github), FreeBSD uses self-hosted subversion. > The use of git goes beyond just the choice of version control. It > allows for workflows that FreeBSD can't even dream of. The linux > kernel has no concept of a committer. Instead anyone can clone the > git tree, build a kernel, and call themselves a Linux distribution. Hi Eitan, Before you speak so nicely about how Linux is doing things, have you ever tried to submit a patch to Linux yourself? I have a bunch of candidates in /usr/ports/multimedia/webcamd/work/webcamd-3.18.0.1/patches (Use this latest tarball: http://home.selasky.org:8192/distfiles/webcamd-4.0.0.2.tar.bz2) which you can start with as a fun experiment ! And then write back when your done. I'm starting counting right now. I have ported a lot of Linux USB drivers to userspace in FreeBSD through the webcamd project, and quite frequently I need to make patches to make the code compile which really should be up-streamed. Sometimes I also find real bugs. Sending the patch to Linux-USB is easy. Getting attention to the patch is hard. Frequent roadblocks in the Linux-USB: - patch must be styled correctly - patch must be send using a certain e-mail program - patch must apply cleanly to the Linux GIT - patch must have a signed-off-by before it can be committed Speaking about USB I don't want FreeBSD-USB to become what Linux-USB is. There are so many mails flowing into Linux-USB every day that no-one is caring to read it all. Getting a decent reply from someone can take months, because of the huge amount of e-mails. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 09:33: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 6B6C61B2; Thu, 2 Apr 2015 09:33:24 +0000 (UTC) Received: from m.saper.info (m.saper.info [IPv6:2a01:4f8:a0:7383::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "m.saper.info", Issuer "Marcin Cieslak 2011" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D47355EF; Thu, 2 Apr 2015 09:33:23 +0000 (UTC) Received: from m.saper.info (saper@m.saper.info [IPv6:2a01:4f8:a0:7383::]) by m.saper.info (8.14.9/8.14.9) with ESMTP id t329XJwg013591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 09:33:19 GMT (envelope-from saper@saper.info) Received: from localhost (saper@localhost) by m.saper.info (8.14.9/8.14.9/Submit) with ESMTP id t329XIVQ013578; Thu, 2 Apr 2015 09:33:19 GMT (envelope-from saper@saper.info) X-Authentication-Warning: m.saper.info: saper owned process doing -bs Date: Thu, 2 Apr 2015 09:33:18 +0000 From: Marcin Cieslak To: Eitan Adler Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Hackers , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 09:33:24 -0000 On Wed, 1 Apr 2015, Eitan Adler wrote: > Hi all, > > One of the key reasons for the lack of people is the high barrier of > entry to joining the FreeBSD project. While every modern project uses > git (usually hosted on github), As much as I love github - please try to go to http://github.com/freebsd/freebsd-ports and try to view history of one particular port. Example task I am facing right now: "I need to compile iojs 1.0.4 using older version of FreeBSD port". Github web interface says to me: > > Sorry, this commit history is taking too long to generate. > > Refresh the page to try again, or view this history locally using the following command: > > git log master -- www/iojs/Makefile Sure one might argue every ports should be a separate repository and we should use git submodules. No, thank you. > Our wiki and code review tools are in an even worse position than our > repository. In order to contribute you need to send an email to > clusteradm@ and hope they deem you worthy enough of access. The bug > tracking system is in a better shape but isn't perfect: while any user > can create an account, their privileges are limited: they can't help > close out bad PRs, reclassify good ones, or do other generally useful > work. I am pretty frustrated I can't login to Phabricator without @freebsd.org address. This is something that should be addressed _ReallySoonNow_ I don't follow FreeBSD intrastructure discussions but I don't understand while we jumed from gnats onto bugzilla instead of going straight to Phabricator Maniphest. Also from my Phabricator experience it is still a bit better suited for svn-centralized model than git (although it supports git as well). > Today I hope we turn ourselves from the cathedral into a truly open > and democratic project! I'd love to have a Phabricator account but despite using FreeBSD since I think version 2.1 and contributing very little I never aspired to get a commit bit. //Marcin From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:28: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 D5246300; Thu, 2 Apr 2015 10:28:20 +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 91421BD6; Thu, 2 Apr 2015 10:28:20 +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 CC29A1FE022; Thu, 2 Apr 2015 12:28:10 +0200 (CEST) Message-ID: <551D19E6.8080405@selasky.org> Date: Thu, 02 Apr 2015 12:28:54 +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: =?UTF-8?B?RmVybmFuZG8gQXBlc3RlZ3XDrWE=?= Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) References: <551D05DE.3070200@selasky.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Eitan Adler , freebsd-current@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 10:28:20 -0000 I hope this is not one more of those April fools :-) --HPS From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 03:49: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 0C9C0F18 for ; Thu, 2 Apr 2015 03:49:47 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 A50BEB57 for ; Thu, 2 Apr 2015 03:49:46 +0000 (UTC) Received: (qmail 2925 invoked from network); 2 Apr 2015 03:49:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Apr 2015 03:49:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 01 Apr 2015 23:49:45 -0400 (EDT) Received: (qmail 2937 invoked from network); 2 Apr 2015 03:49:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Apr 2015 03:49:45 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 886001C4052; Wed, 1 Apr 2015 20:49:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: FYI: 11.0-CURRENT's contrib/ntp -r280915, some boot-time ntpd error messages From: Mark Millard In-Reply-To: Date: Wed, 1 Apr 2015 20:49:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A97222-C183-4CDC-8FA5-A4CA7552BF5F@dsl-only.net> To: Kevin Oberman X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Thu, 02 Apr 2015 11:31:24 +0000 Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 03:49:47 -0000 On 2015-Apr-1, at 08:12 PM, Kevin Oberman = wrote: >=20 > On Wed, Apr 1, 2015 at 12:08 PM, Mark Millard = wrote: > I rebuilt and the boot-message line >=20 > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: line 22 column 1 syntax error >=20 >=20 > is no longer is occurring. But I'm still getting the other two: >=20 > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 = for [omitted] fails: Can't assign requested address > > Mar 31 17:20:08 FBSDG5C0 ntpd[775]: setsockopt IPV6_MULTICAST_IF 0 = for [omitted] fails: Can't assign requested address >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > This is probably way too obvious, but is the system configured for = IPv6?=20 > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com >=20 I do not know how much the two messages matter --for me or to anyone = else. They might not be interesting other than my being educated a bit. As for what all is non-default for my configuration files (not much)... My use of networking is minimal and the configuration changes for that = are limited to rc.conf: > # more /etc/rc.conf > hostname=3D"FBSDG5C0" > ifconfig_bge0=3D"DHCP" > ifconfig_bge0_ipv6=3D"inet6 accept_rtadv" > ifconfig_gem0=3D"DHCP" > ifconfig_gem0_ipv6=3D"inet6 accept_rtadv" > sshd_enable=3D"YES" > ntpd_enable=3D"YES" > ntpd_sync_on_start=3D"YES" > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=3D"AUTO" > hald_enable=3D"YES" > dbus_enable=3D"YES" Historically I've used 10.1-STABLE that way and still do. Recently I've = been experimenting with 11.0-CURRENT based on the same sort of = /etc/rc.conf file. I'm not getting the notices for 10.1-STABLE and have not been. I am getting the notices for 11.0-CURRENT now but I did not notice such = with the few earlier-vintage builds that I've done. It is possible that = I just did not notice: I do not have much 11.0-CURRENT history. If so, = then my notes are more of a 10.1-STABLE vs. 11.0-CURRENT difference = notice. I also fiddle with /boot/loader.conf, /etc/fstab, /etc/make.conf, and = /etc/src.conf primarily. /etc/sysctl.conf for dump issues. = /usr/local/etc/sudoers . The rest of the configuration files are at the default/installation = status. The PowerMac that I plug the SSD into at the time determines which of = bge0 vs. gem0 actually exists. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 10:08:32 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 734739FC; Thu, 2 Apr 2015 10:08:32 +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 14CBC96E; Thu, 2 Apr 2015 10:08:32 +0000 (UTC) Received: by wiaa2 with SMTP id a2so99077410wia.0; Thu, 02 Apr 2015 03:08:30 -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=Wcl6KZVwlp4a9+XEpcLrICdfNbGsUTNFBtay2xd8YDw=; b=VeG3MuS0ioQt9IFs4VaGMI++JoEHY+b8I2CamKKHgUrBaalNvd9B4cwir5daedrQ0Y gjvOta8V/YkDmkuFxLuscGHmQYalNvhAOS+6f8/NB7Kahq5aabykwIlbvXhkW3kvjdhh wpfweAxbgNDDkT9GtPzhX1o2dZ4shIrCZOVPi8603/FR1ulQqfwpbixow5xOLiqc5hCj hbSBN3RztWoq81RLJ+8BlvIlLWv9egofPUMCZx1lmTtIRpeIQFCYGv2euqaBMqmwf6Zz MuMH6p6op36LJiGZ6LDPKhSPnJm8OB3FhGWAAzt/4CowlALTqKc39/ul7fmqNQYIXSzT tfaA== MIME-Version: 1.0 X-Received: by 10.180.208.46 with SMTP id mb14mr23036258wic.31.1427969310423; Thu, 02 Apr 2015 03:08:30 -0700 (PDT) Received: by 10.180.4.41 with HTTP; Thu, 2 Apr 2015 03:08:29 -0700 (PDT) Received: by 10.180.4.41 with HTTP; Thu, 2 Apr 2015 03:08:29 -0700 (PDT) In-Reply-To: <551D05DE.3070200@selasky.org> References: <551D05DE.3070200@selasky.org> Date: Thu, 2 Apr 2015 12:08:29 +0200 Message-ID: Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= To: Hans Petter Selasky X-Mailman-Approved-At: Thu, 02 Apr 2015 11:37:02 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Eitan Adler , freebsd-current@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 10:08:32 -0000 El 02/04/2015 11:03, "Hans Petter Selasky" escribi=C3=B3: > > On 04/01/15 18:55, Eitan Adler wrote: >> >> One of the key reasons for the lack of people is the high barrier of >> entry to joining the FreeBSD project. While every modern project uses >> git (usually hosted on github), FreeBSD uses self-hosted subversion. >> The use of git goes beyond just the choice of version control. It >> allows for workflows that FreeBSD can't even dream of. The linux >> kernel has no concept of a committer. Instead anyone can clone the >> git tree, build a kernel, and call themselves a Linux distribution. > > > Hi Eitan, > > Before you speak so nicely about how Linux is doing things, have you ever tried to submit a patch to Linux yourself? I have a bunch of candidates in /usr/ports/multimedia/webcamd/work/webcamd-3.18.0.1/patches (Use this latest tarball: http://home.selasky.org:8192/distfiles/webcamd-4.0.0.2.tar.bz2) which you can start with as a fun experiment ! And then write back when your done. I'm starting counting right now. > > I have ported a lot of Linux USB drivers to userspace in FreeBSD through the webcamd project, and quite frequently I need to make patches to make the code compile which really should be up-streamed. Sometimes I also find real bugs. Sending the patch to Linux-USB is easy. Getting attention to the patch is hard. Frequent roadblocks in the Linux-USB: > - patch must be styled correctly > - patch must be send using a certain e-mail program > - patch must apply cleanly to the Linux GIT > - patch must have a signed-off-by before it can be committed > I suppose no project is perfect, but all of the above make sense to me. The only thing I disagree is about the mail client. I've never seen that restriction in the documents in the documentation directory of the kernel. I've read restrictions about the format of the mails though. > Speaking about USB I don't want FreeBSD-USB to become what Linux-USB is. There are so many mails flowing into Linux-USB every day that no-one is caring to read it all. Getting a decent reply from someone can take months, because of the huge amount of e-mails. > Getting attention to the patch being hard is probably because of the amount of patches sent every day, but with a fairly smaller stream of patches in FreeBSD, we have some of them sitting in bugzilla for a really long time. Cheers. > --HPS > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 12:19: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 BC09AFB for ; Thu, 2 Apr 2015 12:19:28 +0000 (UTC) Received: from mtaout.vnode.se (mtaout.vnode.se [192.121.62.130]) by mx1.freebsd.org (Postfix) with ESMTP id 7C470AA1 for ; Thu, 2 Apr 2015 12:19:28 +0000 (UTC) Received: from [10.101.128.104] (unknown [192.121.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout.vnode.se (Postfix) with ESMTPSA id EC268B0591; Thu, 2 Apr 2015 14:08:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: ntpd errors after upgrade on current amd64 From: Joel Dahl In-Reply-To: <201504011533.t31FWRhp059914@pozo.com> Date: Thu, 2 Apr 2015 14:19:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41B56119-8262-4E7F-AA2B-E0EDC274F564@vnode.se> References: <201504011533.t31FWRhp059914@pozo.com> To: Manfred Antar X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 12:19:28 -0000 FWIW, I=E2=80=99m seeing the same thing. =E2=80=94 Joel > 1 apr 2015 kl. 17:32 skrev Manfred Antar : >=20 > After build install world on current ntpd doesn't work. > Here is error: >=20 > FreeBSD/amd64 (pozo.com) (ttyu0) >=20 > login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax error > Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 for = fe80::1%2 fails: Can't assign requested address >=20 > I'm using the stock ntp.conf from /usr/src/etc. > It worked fine before the upgrade > Thanks From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 13:54:21 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 5EBA9791; Thu, 2 Apr 2015 13:54:21 +0000 (UTC) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (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 DF23B88C; Thu, 2 Apr 2015 13:54:16 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBEFBF.dip0.t-ipconnect.de [93.203.239.191]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t32Dx06w058153; Thu, 2 Apr 2015 15:59:00 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t32Drvmq010120; Thu, 2 Apr 2015 15:53:57 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t32DrKd1075099; Thu, 2 Apr 2015 15:53:38 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201504021353.t32DrKd1075099@fire.js.berklix.net> To: Hans Petter Selasky Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 02 Apr 2015 12:28:54 +0200." <551D19E6.8080405@selasky.org> Date: Thu, 02 Apr 2015 15:53:20 +0200 Cc: Eitan Adler , freebsd-current@freebsd.org, FreeBSD Hackers , =?UTF-8?B?RmVybmFuZG8gQXBlc3RlZ3XDrWE=?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 13:54:21 -0000 Hans Petter Selasky wrote: > I hope this is not one more of those April fools :-) I've been thinking that since Eitan's first post of Wed, 1 Apr 2015 09:55:11 -0700 (18:55 CEST) "self-serve commit access" I kept wondering what would keep looneys out ? :-) Your experience feeding back to Linux was interesting, I suppose we assume "the grass is greener" till we hear someone tried it :-) Fernando, Your mailer software auto fold mechanism is bad, best turn it off. It corrupted quote from Hans Petter. It inserted repeated "\n" not "\n> " Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with "> ". Reply Below as a play script. Send plain text, Not quoted-printable, HTML, or base64. From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 14:21:10 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 56306338; Thu, 2 Apr 2015 14:21:10 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 CB76DB77; Thu, 2 Apr 2015 14:21:09 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t32ELDGk031919; Thu, 2 Apr 2015 07:21:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: pkg@FreeBSD.org, ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org, Baptiste Daroussin In-Reply-To: <20150331190323.GF30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> From: "Chris H" Subject: Re: [CFT] Call for testing pkg 1.5.0 Date: Thu, 02 Apr 2015 07:21:19 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <2ee112c1eb589c7cb08aa1c53680fadd@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 14:21:10 -0000 On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin wrote > Hi all, > > We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), > .. > Please test and report as much bugs as you can! > We could be very grateful if regressions tests could be provided along with > the bug reports :) > > Plan is to release 1.5.0 as soon as possible > > Best regards, > Bapt Hello, Baptiste. I just wanted to take the time to thank you for all the work you've put into this. Thanks! --Chris From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 15:19:13 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 C1729A36; Thu, 2 Apr 2015 15:19:13 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 33FDF234; Thu, 2 Apr 2015 15:19:12 +0000 (UTC) X-AuditID: 1209190e-f79a76d000000d1b-53-551d5cba7445 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.E0.03355.ABC5D155; Thu, 2 Apr 2015 11:14:02 -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 t32FE1qB010441; Thu, 2 Apr 2015 11:14:02 -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 t32FDxxb013987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Apr 2015 11:14:01 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t32FDxjb022363; Thu, 2 Apr 2015 11:13:59 -0400 (EDT) Date: Thu, 2 Apr 2015 11:13:59 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org Subject: Last week to submit FreeBSD 2015Q1 (January-March) Status Reports Message-ID: 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+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrLsrRjbU4MRqPYtd106zW8x584HJ Yvvmf4wOzB4zPs1nCWCM4rJJSc3JLEst0rdL4Mp4fOcQY8F67oq3i+6wNjDu5Oxi5OSQEDCR mHvgKiOELSZx4d56ti5GLg4hgcVMEi+u72GBcDYwSvxtmscM4Rxkkvi9vIcVpEVIoF7i15fn 7CA2i4CWxKnlf8FGsQmoSTze28wKMVZRYvOpSUDNHBwiAvISC87bg4SZgcz/Vy4zgdjCAl4S k79fB2vlFXCU6Jj2DMwWFdCRWL1/CgtEXFDi5MwnLBC9WhLLp29jmcAoMAtJahaS1AJGplWM sim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBASnJt4Px60GlQ4wCHIxKPLwZe2RC hVgTy4orcw8xSnIwKYny3o6UDRXiS8pPqcxILM6ILyrNSS0+xCjBwawkwisSApTjTUmsrEot yodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLg/RoF1ChYlJqeWpGWmVOCkGbi4AQZ zgM0/A5IDW9xQWJucWY6RP4Uo6KUOO9rkIQASCKjNA+uF5YwXjGKA70izOsZDVTFA0w2cN2v gAYzAQ12mCcNMrgkESEl1cC40W5bunH7rGdLjgnWaWUW9HD8sygruZX5S/1+yb2F4albegwn iWfcMdH5smt+nttZ65Me+Uuu2KYWTrg8q153b2vvf67NclLpk5bz95ZZ1eioL9Yykpd8lhne scPw/bWDXyJiX8i+SVi8bRN38APvwE9duqIz17yYrFgkPXGGvzRr+T09tx4lluKMREMt5qLi RAAuOUlA8wIAAA== Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 15:19:14 -0000 Dear FreeBSD Community, The first quarter of 2015 has come and passed, and the deadline for the FreeBSD Quarterly Status Report for the first quarter is fast approaching -- the deadline is April 7, 2015, for work done in January through March. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled in manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4,5] for ideas on the style and format. We are looking forward to all of your 2015Q1 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-07-2014-09.html [5] http://www.freebsd.org/news/status/report-2014-10-2014-12.html From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 15:21: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 43FBADCA for ; Thu, 2 Apr 2015 15:21:05 +0000 (UTC) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 DBA9B31E for ; Thu, 2 Apr 2015 15:21:04 +0000 (UTC) Received: by lagg8 with SMTP id g8so62645903lag.1 for ; Thu, 02 Apr 2015 08:20:57 -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=4ySAkDzwS5/dYtWY7a+ayjwKlBMrNVLqv5ivFpWiKWY=; b=TvUzECzlIP0EI39+c8ZGhbiKsVKloWVAvhRYDSXk0fGTT0UdzvkjPtDROJVf+CPO2C l9F3gjpQXODGuZcq0Gqa84L9ayEj1lFt8S1S4v4HHfq45buCxUEUoM/6Aq1TynbZtqQc 9mTMOh+1K/lCg5+DUvgnC80wlr72V67VgNfaNjZKpkT+el9/n9qztZpxPWm1Aw5aBx1+ DpJqan7IbCLCKV4Hq4IVINGNw326LyVdfqTS+FEdnvovu0qCwOV4RyeqInfJJXk3ddEn ndABSsv5kNTfKwmOtgcxdnPnq5399/qZP6hiDq4cWifP3b2MFuKN3yS6plMNzRqbDtSO LEjg== X-Gm-Message-State: ALoCoQmMeT/ubci+rnsBBsZ2Pgj8SxesSorPlHvO+euNWytCpbvbeo0lQHvVUCS2+tEWYlExJ+ay MIME-Version: 1.0 X-Received: by 10.112.198.40 with SMTP id iz8mr27623398lbc.101.1427988057277; Thu, 02 Apr 2015 08:20:57 -0700 (PDT) Received: by 10.25.19.83 with HTTP; Thu, 2 Apr 2015 08:20:57 -0700 (PDT) X-Originating-IP: [8.25.222.10] In-Reply-To: References: Date: Thu, 2 Apr 2015 08:20:57 -0700 Message-ID: Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) From: Samuel Cassiba To: Eitan Adler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Hackers , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 15:21:05 -0000 Eitan, This being posted on April 1 sets off my BS-o-meter, but I'll bite since it's a topic worth shaving a yak or two over. WARNING: there be perceptions and opinions here Having been ephemerally associated with FreeBSD since early 4.x, I never really saw FreeBSD as being cathedral-like, but the barrier to entry today feels even higher than it did 15 years ago. I view FreeBSD as being very much bazaar-like in terms of the actual code that comprises the OS and how it's treated, but like I must reiterate: the wall is harder to scale today. I appreciate the work that everyone has done over the years to bring the project's infrastructure up to modern times, such as the work done bringing in CI, a modern bug tracker and an honest to goodness code review tool, but the general workflow that I learned all those years ago for getting a change to go live *feels* more or less still the same: - find/fix bug - send-pr (okay... but you get the idea) - pester a committer with the proper access - ??? - profit!!! The arbitrary nature of how commit bits have historically been allocated have been more of a detractor than anything, making the the barrier appear even higher than it may actually be. The general wisdom I learned was "when you've bugged people often enough to commit your code, they'll burden you with that ability", which is great in terms of a pure meritocracy, but we're people and things aren't so black and white. Commit access thresholds shouldn't be measured in SLOC. Yes, the meritocratic way of handling commit access has worked well enough so far, but it has been at a cost (see FreeBSD's standing in the mindshare/overall market, as well as number of active FreeBSD committers vs your favorite big name Linux flavor). Access to the tools that the project has gravitated towards can be difficult if not impossible to obtain without a long slog through commit hell to get that sweet @FreeBSD.org spiff. Is a "free commit access for anyone!" approach really the answer? It feels like going from one extreme to the other, and we all know how extremes work. I feel that commit access should be more transparent, so that if someone really wants to be able to push code or act as a representative of the project, they can learn how to work towards that, instead of some nebulous "push enough code until we get tired of committing it". Again, I'm pretty sure this is just a April 1 troll, but it's all worth saying since the topic was brought up. Lowering the barrier to entry is good, but the act of doing so mustn't come at a detriment to quality. -Samuel On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > Hi all, > > FreeBSD today has a significant problem of attracting new developers. > The lack of new developers manifests itself in a dearth of driver > support, inadequate documentation, and trailing third party packages. > > One of the key reasons for the lack of people is the high barrier of > entry to joining the FreeBSD project. While every modern project uses > git (usually hosted on github), FreeBSD uses self-hosted subversion. > The use of git goes beyond just the choice of version control. It > allows for workflows that FreeBSD can't even dream of. The linux > kernel has no concept of a committer. Instead anyone can clone the > git tree, build a kernel, and call themselves a Linux distribution. > > Our wiki and code review tools are in an even worse position than our > repository. In order to contribute you need to send an email to > clusteradm@ and hope they deem you worthy enough of access. The bug > tracking system is in a better shape but isn't perfect: while any user > can create an account, their privileges are limited: they can't help > close out bad PRs, reclassify good ones, or do other generally useful > work. > > To solve this problem I propose a simple solution: self-serve commit > access. We create a web service on accounts.freebsd.org via which > users can create themselves a freefall account. In addition to a > freefall account, the identical username would be created for the wiki > and phabricator, bugzilla, and any other service we might provide. > > This will allow us to quickly gain large number of contributors, who > will be able to make better progress on our missing features, and > rectify some of the drawbacks listed above. > > Today I hope we turn ourselves from the cathedral into a truly open > and democratic project! > > > -- > Eitan Adler > _______________________________________________ > 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 2 16:15: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 1EB62A83; Thu, 2 Apr 2015 16:15:14 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 C42D0C01; Thu, 2 Apr 2015 16:15:13 +0000 (UTC) Received: by qgdy78 with SMTP id y78so11804165qgd.0; Thu, 02 Apr 2015 09:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nc/5m8SgKpy8XDQ7l8bAuuZ0ox+mkebzMyCyPq9+GHU=; b=FUhB6tP275t6s7CiH+/++4P+s2ejr4YlE0ESLS0QfNfrymbuw2c4bB79QNAOJ0g9do 0M4iqQ7nRpOvb7k56SZB+U605LzEnZuqwV2d7XIo69fWteCYBFepjyguwBc9eBvXWwus IA44MWBY8DOROqfCH8DoR1/rdxk3IV9cVaDaeo7JhV441dunl9gaigkgrJg5jYafkAW4 9F/BGKt1dYeD9q/jQxp3TkqCwBAHwBBb01j2bh65P5eCuw4LYmc6sJfGrZXuerLgj97F 3w7Oh2gdcaTtFUsYWNbp+Y/PDUgs9Sv2SMdjH+L4Wkk5qMwuU996mjrE5nQHeas4zy9w jKaA== X-Received: by 10.141.18.208 with SMTP id u199mr62774193qhd.47.1427991312834; Thu, 02 Apr 2015 09:15:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.200 with HTTP; Thu, 2 Apr 2015 09:14:51 -0700 (PDT) In-Reply-To: References: From: "B. Estrade" Date: Thu, 2 Apr 2015 11:14:51 -0500 Message-ID: Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) To: Samuel Cassiba Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Eitan Adler , freebsd-current Current , FreeBSD Hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 16:15:14 -0000 Joke or not, it's worth pointing out that while DragonFlyBSD's approach seems to be a fairly sane hybrid; there is no reason this can't be done within FreeBSD right now. https://www.dragonflybsd.org/docs/developer/TypicalGitUsage/ Anyone can clone, but if you can't commit to the repo then you're asked to register at http://bugs.dragonflybsd.org/ and send your patch over email. DFBSD's GItub repo is just a mirror and FreeBSD has something similar available, including a "GitWorkFlow" document: https://wiki.freebsd.org/GitWorkflow So I don't see why *now* someone couldn't basically follow the same workflow if they wanted to contribute to FreeBSD; namely: * clone mirrored repo/branch from GH * make changes * create a problem report at bugs.freebsd.org * submit patches And if this is not possible, it is likely a procedural impediment and not a technical one. Cheers, Brett On Thu, Apr 2, 2015 at 10:20 AM, Samuel Cassiba wrote: > Eitan, > > This being posted on April 1 sets off my BS-o-meter, but I'll bite since > it's a topic worth shaving a yak or two over. > > WARNING: there be perceptions and opinions here > > Having been ephemerally associated with FreeBSD since early 4.x, I never > really saw FreeBSD as being cathedral-like, but the barrier to entry today > feels even higher than it did 15 years ago. I view FreeBSD as being very > much bazaar-like in terms of the actual code that comprises the OS and how > it's treated, but like I must reiterate: the wall is harder to scale today. > > I appreciate the work that everyone has done over the years to bring the > project's infrastructure up to modern times, such as the work done bringing > in CI, a modern bug tracker and an honest to goodness code review tool, but > the general workflow that I learned all those years ago for getting a > change to go live *feels* more or less still the same: > - find/fix bug > - send-pr (okay... but you get the idea) > - pester a committer with the proper access > - ??? > - profit!!! > > The arbitrary nature of how commit bits have historically been allocated > have been more of a detractor than anything, making the the barrier appear > even higher than it may actually be. The general wisdom I learned was "when > you've bugged people often enough to commit your code, they'll burden you > with that ability", which is great in terms of a pure meritocracy, but > we're people and things aren't so black and white. Commit access thresholds > shouldn't be measured in SLOC. > > Yes, the meritocratic way of handling commit access has worked well enough > so far, but it has been at a cost (see FreeBSD's standing in the > mindshare/overall market, as well as number of active FreeBSD committers vs > your favorite big name Linux flavor). Access to the tools that the project > has gravitated towards can be difficult if not impossible to obtain without > a long slog through commit hell to get that sweet @FreeBSD.org spiff. > > Is a "free commit access for anyone!" approach really the answer? It feels > like going from one extreme to the other, and we all know how extremes > work. I feel that commit access should be more transparent, so that if > someone really wants to be able to push code or act as a representative of > the project, they can learn how to work towards that, instead of some > nebulous "push enough code until we get tired of committing it". > > Again, I'm pretty sure this is just a April 1 troll, but it's all worth > saying since the topic was brought up. Lowering the barrier to entry is > good, but the act of doing so mustn't come at a detriment to quality. > > > -Samuel > > On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > > > Hi all, > > > > FreeBSD today has a significant problem of attracting new developers. > > The lack of new developers manifests itself in a dearth of driver > > support, inadequate documentation, and trailing third party packages. > > > > One of the key reasons for the lack of people is the high barrier of > > entry to joining the FreeBSD project. While every modern project uses > > git (usually hosted on github), FreeBSD uses self-hosted subversion. > > The use of git goes beyond just the choice of version control. It > > allows for workflows that FreeBSD can't even dream of. The linux > > kernel has no concept of a committer. Instead anyone can clone the > > git tree, build a kernel, and call themselves a Linux distribution. > > > > Our wiki and code review tools are in an even worse position than our > > repository. In order to contribute you need to send an email to > > clusteradm@ and hope they deem you worthy enough of access. The bug > > tracking system is in a better shape but isn't perfect: while any user > > can create an account, their privileges are limited: they can't help > > close out bad PRs, reclassify good ones, or do other generally useful > > work. > > > > To solve this problem I propose a simple solution: self-serve commit > > access. We create a web service on accounts.freebsd.org via which > > users can create themselves a freefall account. In addition to a > > freefall account, the identical username would be created for the wiki > > and phabricator, bugzilla, and any other service we might provide. > > > > This will allow us to quickly gain large number of contributors, who > > will be able to make better progress on our missing features, and > > rectify some of the drawbacks listed above. > > > > Today I hope we turn ourselves from the cathedral into a truly open > > and democratic project! > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 17:44:34 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E839646F; Thu, 2 Apr 2015 17:44:33 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (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 B43DB964; Thu, 2 Apr 2015 17:44:33 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t32HiYX2058636; Thu, 2 Apr 2015 10:44:40 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Eitan Adler , Samuel Cassiba In-Reply-To: References: , From: "Chris H" Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) Date: Thu, 02 Apr 2015 10:44:40 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 17:44:34 -0000 On Thu, 2 Apr 2015 08:20:57 -0700 Samuel Cassiba wrote > Eitan, > > This being posted on April 1 sets off my BS-o-meter, but I'll bite since > it's a topic worth shaving a yak or two over. > > WARNING: there be perceptions and opinions here > > Having been ephemerally associated with FreeBSD since early 4.x, I never .. > Again, I'm pretty sure this is just a April 1 troll, but it's all worth > saying since the topic was brought up. Lowering the barrier to entry is > good, but the act of doing so mustn't come at a detriment to quality. OK. I'll bite... IMHO I believe that the height of the bar, is directly proportionate to the quality of the product. --Chris > > > -Samuel > > On Wed, Apr 1, 2015 at 9:55 AM, Eitan Adler wrote: > > > Hi all, > > > > FreeBSD today has a significant problem of attracting new developers. > > The lack of new developers manifests itself in a dearth of driver > > support, inadequate documentation, and trailing third party packages. > > > > One of the key reasons for the lack of people is the high barrier of > > entry to joining the FreeBSD project. While every modern project uses > > git (usually hosted on github), FreeBSD uses self-hosted subversion. > > The use of git goes beyond just the choice of version control. It > > allows for workflows that FreeBSD can't even dream of. The linux > > kernel has no concept of a committer. Instead anyone can clone the > > git tree, build a kernel, and call themselves a Linux distribution. > > > > Our wiki and code review tools are in an even worse position than our > > repository. In order to contribute you need to send an email to > > clusteradm@ and hope they deem you worthy enough of access. The bug > > tracking system is in a better shape but isn't perfect: while any user > > can create an account, their privileges are limited: they can't help > > close out bad PRs, reclassify good ones, or do other generally useful > > work. > > > > To solve this problem I propose a simple solution: self-serve commit > > access. We create a web service on accounts.freebsd.org via which > > users can create themselves a freefall account. In addition to a > > freefall account, the identical username would be created for the wiki > > and phabricator, bugzilla, and any other service we might provide. > > > > This will allow us to quickly gain large number of contributors, who > > will be able to make better progress on our missing features, and > > rectify some of the drawbacks listed above. > > > > Today I hope we turn ourselves from the cathedral into a truly open > > and democratic project! > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 18:34:42 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 5CBA387E; Thu, 2 Apr 2015 18:34:42 +0000 (UTC) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002: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 0C379ED9; Thu, 2 Apr 2015 18:34:42 +0000 (UTC) Received: by yhjf44 with SMTP id f44so23032889yhj.3; Thu, 02 Apr 2015 11:34:41 -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=y+0rE1NsQpkY9blkl7LGF7yJqn0NywcIF48/aYyFS3w=; b=lc/GBep//nfi8IckxkUBfEmvLE5AVwplgmzzot4b/Eii7RsN6mrEGOhOxDrLa2hjdO 865vQaC2woqRNHQzywgsUIV5IU5AEQMEFWnWP25RwlFXjFBMsKdYIgF2n0uh/7YA8kwq WTlcHoz9gNz12WVua+Inf85ViDX8ZQy5ZzelSxCMRse8HX/k9O1NxPih+a1odU6tTkdC SMDT62VAoMVDFObJ6BTTbG2aJYa0EVJzl74m/OlrQMTCMNi0FHT9P6SShRuzcqJF5qGb uPSJVgQ37uUUDmrOyMToUp3/NkoqQp00iGxnXHf87w9XxWH04b39MWDPKyYpy1Ux1sJE piDw== X-Received: by 10.52.255.171 with SMTP id ar11mr46817756vdd.36.1427999681149; Thu, 02 Apr 2015 11:34:41 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id xc11sm930862vdc.2.2015.04.02.11.34.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 11:34:39 -0700 (PDT) Sender: Baptiste Daroussin Date: Thu, 2 Apr 2015 20:34:36 +0200 From: Baptiste Daroussin To: Chris H Subject: Re: [CFT] Call for testing pkg 1.5.0 Message-ID: <20150402183435.GB30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <2ee112c1eb589c7cb08aa1c53680fadd@ultimatedns.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M5PHxtWZRXQUdpfa" Content-Disposition: inline In-Reply-To: <2ee112c1eb589c7cb08aa1c53680fadd@ultimatedns.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: pkg@FreeBSD.org, ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 18:34:42 -0000 --M5PHxtWZRXQUdpfa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 02, 2015 at 07:21:19AM -0700, Chris H wrote: > On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin = wrote >=20 > > Hi all, > >=20 > > We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), > >=20 > .. > > Please test and report as much bugs as you can! > > We could be very grateful if regressions tests could be provided along = with > > the bug reports :) > >=20 > > Plan is to release 1.5.0 as soon as possible > >=20 > > Best regards, > > Bapt > Hello, Baptiste. > I just wanted to take the time to thank you for all the > work you've put into this. >=20 > Thanks! Thanks much appreciated, I want to share that with vsevolod@ and az@ who al= so spent a lot of time working on it! Best regards, Bapt --M5PHxtWZRXQUdpfa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUdi7sACgkQ8kTtMUmk6Ey5swCfdKpeuPQVO9BZ+omMLazlxbah j98Anj7o/onniMjkNextkcE3z6iPTefD =Bunk -----END PGP SIGNATURE----- --M5PHxtWZRXQUdpfa-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 20:11:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10BA3936; Thu, 2 Apr 2015 20:11:05 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 429E09E7; Thu, 2 Apr 2015 20:11:04 +0000 (UTC) Message-ID: <551DA257.6060100@FreeBSD.org> Date: Thu, 02 Apr 2015 16:11:03 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Manfred Antar , freebsd-current@freebsd.org Subject: Re: ntpd errors after upgrade on current amd64 References: <201504011533.t31FWRhp059914@pozo.com> In-Reply-To: <201504011533.t31FWRhp059914@pozo.com> Content-Type: multipart/mixed; boundary="------------090800070300040107060309" Cc: roberto@FreeBSD.org, Cy Schubert , Xin LI , Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 20:11:05 -0000 This is a multi-part message in MIME format. --------------090800070300040107060309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/01/2015 11:32, Manfred Antar wrote: > After build install world on current ntpd doesn't work. Here is > error: > > FreeBSD/amd64 (pozo.com) (ttyu0) > > login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax > error ntp_crypto.c was not properly merged. Basically, the fix for SA-14:31.ntp was applied twice. Please try the attached patch. > Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 > for fe80::1%2 fails: Can't assign requested address A separate issue, I think. Jung-uk Kim * Note: ntp_parser.y is redundant and it was the root cause of inconsistent builds and build failures, i.e., ntp_parser.c and ntp_parser.h may be regenerated on the *source* directory depending on phase of the moon. Although we can re-gen them after r280915, upstream does not support BSD yacc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVHaJXAAoJEHyflib82/FGla0H/i7cQunatuUUhGYPGGenmy1X DEo7zL/LYNWX7XY392dIDKFGZguvErehVy7KNiVXZzrlsz0JRVpQp/r8OT6xPrFF lGFaOgGB9tfIYKZl+Bn2gE40mwtfp7UX3B2nIswwF2SFBhyuJPiIZ5Y+j3YDyIHS /BGUs0D+CaKq9RgU66QrowMOtA/uElWix44VHVSNJ2knAL+x6cZF4VzNTC+6wG2c DVODrTMSqMAwiIkPYJCndbxH7C9ZaQEHVq19pTmYRb1V7x2VO0/3NrBJJYSP9GGe PQS/HiU9lkIi/JSj3AN9+ntyzKpne/DJz6/AAe/JpCGj/o1Ke+ageA6m7yoqHL8= =wNw9 -----END PGP SIGNATURE----- --------------090800070300040107060309 Content-Type: text/x-patch; name="ntp.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ntp.diff" Index: contrib/ntp/ntpd/ntp_crypto.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/ntp/ntpd/ntp_crypto.c (revision 280991) +++ contrib/ntp/ntpd/ntp_crypto.c (working copy) @@ -826,10 +826,10 @@ crypto_recv( * Decrypt the cookie, hunting all the time for * errors. */ - if (vallen =3D=3D (u_int) EVP_PKEY_size(host_pkey)) { + if (vallen =3D=3D (u_int)EVP_PKEY_size(host_pkey)) { u_int32 *cookiebuf =3D malloc( RSA_size(host_pkey->pkey.rsa)); - if (cookiebuf =3D=3D NULL) { + if (!cookiebuf) { rval =3D XEVNT_CKY; break; } @@ -3817,7 +3817,7 @@ crypto_setup(void) randfile); exit (-1); } - get_systime(&seed); + arc4random_buf(&seed, sizeof(l_fp)); RAND_seed(&seed, sizeof(l_fp)); RAND_write_file(randfile); #ifdef DEBUG @@ -3850,36 +3850,6 @@ crypto_setup(void) pinfo =3D crypto_key(filename, passwd, NULL); if (pinfo =3D=3D NULL) { msyslog(LOG_ERR, - "crypto_setup: random seed file not specified"); - exit (-1); - } - if ((bytes =3D RAND_load_file(rand_file, -1)) =3D=3D 0) { - msyslog(LOG_ERR, - "crypto_setup: random seed file %s not found\n", - rand_file); - exit (-1); - } - arc4random_buf(&seed, sizeof(l_fp)); - RAND_seed(&seed, sizeof(l_fp)); - RAND_write_file(rand_file); - OpenSSL_add_all_algorithms(); -#ifdef DEBUG - if (debug) - printf( - "crypto_setup: OpenSSL version %lx random seed file %s bytes read = %d\n", - SSLeay(), rand_file, bytes); -#endif - - /* - * Load required host key from file "ntpkey_host_". If - * no host key file is not found or has invalid password, life - * as we know it ends. The host key also becomes the default - * sign key.=20 - */ - snprintf(filename, sizeof(filename), "ntpkey_host_%s", hostname); - pinfo =3D crypto_key(filename, passwd, NULL); - if (pinfo =3D=3D NULL) { - msyslog(LOG_ERR, "crypto_setup: host key file %s not found or corrupt", filename); exit (-1); Index: contrib/ntp/ntpd/ntp_parser.y =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/ntp/ntpd/ntp_parser.y (revision 280991) +++ contrib/ntp/ntpd/ntp_parser.y (working copy) @@ -1,1641 +0,0 @@ -/* ntp_parser.y - * - * The parser for the NTP configuration file. - * - * Written By: Sachin Kamboj - * University of Delaware - * Newark, DE 19711 - * Copyright (c) 2006 - */ - -%parse-param { struct FILE_INFO *ip_file } -%lex-param { struct FILE_INFO *ip_file } - -%{ - #ifdef HAVE_CONFIG_H - # include - #endif - - #include "ntp.h" - #include "ntpd.h" - #include "ntp_machine.h" - #include "ntp_stdlib.h" - #include "ntp_filegen.h" - #include "ntp_scanner.h" - #include "ntp_config.h" - #include "ntp_crypto.h" - - #include "ntpsim.h" /* HMS: Do we really want this all the time? */ - /* SK: It might be a good idea to always - include the simulator code. That way - someone can use the same configuration file - for both the simulator and the daemon - */ - - #define YYMALLOC emalloc - #define YYFREE free - #define YYERROR_VERBOSE - #define YYMAXDEPTH 1000 /* stop the madness sooner */ - void yyerror(struct FILE_INFO *ip_file, const char *msg); - - #ifdef SIM - # define ONLY_SIM(a) (a) - #else - # define ONLY_SIM(a) NULL - #endif -%} - -/*=20 - * Enable generation of token names array even without YYDEBUG. - * We access via token_name() defined below. - */ -%token-table - -%union { - char * String; - double Double; - int Integer; - unsigned U_int; - gen_fifo * Generic_fifo; - attr_val * Attr_val; - attr_val_fifo * Attr_val_fifo; - int_fifo * Int_fifo; - string_fifo * String_fifo; - address_node * Address_node; - address_fifo * Address_fifo; - setvar_node * Set_var; - server_info * Sim_server; - server_info_fifo * Sim_server_fifo; - script_info * Sim_script; - script_info_fifo * Sim_script_fifo; -} - -/* TERMINALS (do not appear left of colon) */ -%token T_Abbrev -%token T_Age -%token T_All -%token T_Allan -%token T_Allpeers -%token T_Auth -%token T_Autokey -%token T_Automax -%token T_Average -%token T_Bclient -%token T_Beacon -%token T_Broadcast -%token T_Broadcastclient -%token T_Broadcastdelay -%token T_Burst -%token T_Calibrate -%token T_Ceiling -%token T_Clockstats -%token T_Cohort -%token T_ControlKey -%token T_Crypto -%token T_Cryptostats -%token T_Ctl -%token T_Day -%token T_Default -%token T_Digest -%token T_Disable -%token T_Discard -%token T_Dispersion -%token T_Double /* not a token */ -%token T_Driftfile -%token T_Drop -%token T_Ellipsis /* "..." not "ellipsis" */ -%token T_Enable -%token T_End -%token T_False -%token T_File -%token T_Filegen -%token T_Filenum -%token T_Flag1 -%token T_Flag2 -%token T_Flag3 -%token T_Flag4 -%token T_Flake -%token T_Floor -%token T_Freq -%token T_Fudge -%token T_Host -%token T_Huffpuff -%token T_Iburst -%token T_Ident -%token T_Ignore -%token T_Incalloc -%token T_Incmem -%token T_Initalloc -%token T_Initmem -%token T_Includefile -%token T_Integer /* not a token */ -%token T_Interface -%token T_Intrange /* not a token */ -%token T_Io -%token T_Ipv4 -%token T_Ipv4_flag -%token T_Ipv6 -%token T_Ipv6_flag -%token T_Kernel -%token T_Key -%token T_Keys -%token T_Keysdir -%token T_Kod -%token T_Mssntp -%token T_Leapfile -%token T_Limited -%token T_Link -%token T_Listen -%token T_Logconfig -%token T_Logfile -%token T_Loopstats -%token T_Lowpriotrap -%token T_Manycastclient -%token T_Manycastserver -%token T_Mask -%token T_Maxage -%token T_Maxclock -%token T_Maxdepth -%token T_Maxdist -%token T_Maxmem -%token T_Maxpoll -%token T_Mdnstries -%token T_Mem -%token T_Memlock -%token T_Minclock -%token T_Mindepth -%token T_Mindist -%token T_Minimum -%token T_Minpoll -%token T_Minsane -%token T_Mode -%token T_Mode7 -%token T_Monitor -%token T_Month -%token T_Mru -%token T_Multicastclient -%token T_Nic -%token T_Nolink -%token T_Nomodify -%token T_Nomrulist -%token T_None -%token T_Nonvolatile -%token T_Nopeer -%token T_Noquery -%token T_Noselect -%token T_Noserve -%token T_Notrap -%token T_Notrust -%token T_Ntp -%token T_Ntpport -%token T_NtpSignDsocket -%token T_Orphan -%token T_Orphanwait -%token T_Panic -%token T_Peer -%token T_Peerstats -%token T_Phone -%token T_Pid -%token T_Pidfile -%token T_Pool -%token T_Port -%token T_Preempt -%token T_Prefer -%token T_Protostats -%token T_Pw -%token T_Randfile -%token T_Rawstats -%token T_Refid -%token T_Requestkey -%token T_Reset -%token T_Restrict -%token T_Revoke -%token T_Rlimit -%token T_Saveconfigdir -%token T_Server -%token T_Setvar -%token T_Source -%token T_Stacksize -%token T_Statistics -%token T_Stats -%token T_Statsdir -%token T_Step -%token T_Stepout -%token T_Stratum -%token T_String /* not a token */ -%token T_Sys -%token T_Sysstats -%token T_Tick -%token T_Time1 -%token T_Time2 -%token T_Timer -%token T_Timingstats -%token T_Tinker -%token T_Tos -%token T_Trap -%token T_True -%token T_Trustedkey -%token T_Ttl -%token T_Type -%token T_U_int /* Not a token */ -%token T_Unconfig -%token T_Unpeer -%token T_Version -%token T_WanderThreshold /* Not a token */ -%token T_Week -%token T_Wildcard -%token T_Xleave -%token T_Year -%token T_Flag /* Not a token */ -%token T_EOC - - -/* NTP Simulator Tokens */ -%token T_Simulate -%token T_Beep_Delay -%token T_Sim_Duration -%token T_Server_Offset -%token T_Duration -%token T_Freq_Offset -%token T_Wander -%token T_Jitter -%token T_Prop_Delay -%token T_Proc_Delay - - - -/*** NON-TERMINALS ***/ -%type access_control_flag -%type ac_flag_list -%type address -%type address_fam -%type address_list -%type boolean -%type client_type -%type counter_set_keyword -%type counter_set_list -%type crypto_command -%type crypto_command_list -%type crypto_str_keyword -%type discard_option -%type discard_option_keyword -%type discard_option_list -%type enable_disable -%type filegen_option -%type filegen_option_list -%type filegen_type -%type fudge_factor -%type fudge_factor_bool_keyword -%type fudge_factor_dbl_keyword -%type fudge_factor_list -%type integer_list -%type integer_list_range -%type integer_list_range_elt -%type integer_range -%type nic_rule_action -%type interface_command -%type interface_nic -%type ip_address -%type link_nolink -%type log_config_command -%type log_config_list -%type misc_cmd_dbl_keyword -%type misc_cmd_str_keyword -%type misc_cmd_str_lcl_keyword -%type mru_option -%type mru_option_keyword -%type mru_option_list -%type nic_rule_class -%type number -%type option -%type option_flag -%type option_flag_keyword -%type option_list -%type option_int -%type option_int_keyword -%type option_str -%type option_str_keyword -%type reset_command -%type rlimit_option_keyword -%type rlimit_option -%type rlimit_option_list -%type stat -%type stats_list -%type string_list -%type system_option -%type system_option_flag_keyword -%type system_option_local_flag_keyword -%type system_option_list -%type t_default_or_zero -%type tinker_option_keyword -%type tinker_option -%type tinker_option_list -%type tos_option -%type tos_option_dbl_keyword -%type tos_option_int_keyword -%type tos_option_list -%type trap_option -%type trap_option_list -%type unpeer_keyword -%type variable_assign - -/* NTP Simulator non-terminals */ -%type sim_init_statement -%type sim_init_statement_list -%type sim_init_keyword -%type sim_server_list -%type sim_server -%type sim_server_offset -%type sim_server_name -%type sim_act -%type sim_act_list -%type sim_act_keyword -%type sim_act_stmt_list -%type sim_act_stmt - -%% - -/* ntp.conf - * Configuration File Grammar - * -------------------------- - */ - -configuration - : command_list - ; - -command_list - : command_list command T_EOC - | command T_EOC - | error T_EOC - { - /* I will need to incorporate much more fine grained - * error messages. The following should suffice for - * the time being. - */ - msyslog(LOG_ERR,=20 - "syntax error in %s line %d, column %d", - ip_file->fname, - ip_file->err_line_no, - ip_file->err_col_no); - } - ; - -command : /* NULL STATEMENT */ - | server_command - | unpeer_command - | other_mode_command - | authentication_command - | monitoring_command - | access_control_command - | orphan_mode_command - | fudge_command - | rlimit_command - | system_option_command - | tinker_command - | miscellaneous_command - | simulate_command - ; - -/* Server Commands - * --------------- - */ - -server_command - : client_type address option_list - { - peer_node *my_node; - - my_node =3D create_peer_node($1, $2, $3); - APPEND_G_FIFO(cfgt.peers, my_node); - } - ; - -client_type - : T_Server - | T_Pool - | T_Peer - | T_Broadcast - | T_Manycastclient - ; - -address - : ip_address - | address_fam T_String - { $$ =3D create_address_node($2, $1); } - ; - -ip_address - : T_String=20 - { $$ =3D create_address_node($1, AF_UNSPEC); } - ; - -address_fam - : T_Ipv4_flag - { $$ =3D AF_INET; } - | T_Ipv6_flag - { $$ =3D AF_INET6; } - ; - -option_list - : /* empty list */ - { $$ =3D NULL; } - | option_list option=20 - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -option - : option_flag - | option_int - | option_str - ; - -option_flag - : option_flag_keyword - { $$ =3D create_attr_ival(T_Flag, $1); } - ; - -option_flag_keyword - : T_Autokey - | T_Burst - | T_Iburst - | T_Noselect - | T_Preempt - | T_Prefer - | T_True - | T_Xleave - ; - -option_int - : option_int_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - | option_int_keyword T_U_int - { $$ =3D create_attr_uval($1, $2); } - ; - -option_int_keyword - : T_Key - | T_Minpoll - | T_Maxpoll - | T_Ttl - | T_Mode - | T_Version - ; - -option_str - : option_str_keyword T_String - { $$ =3D create_attr_sval($1, $2); } - ; - -option_str_keyword - : T_Ident - ; - - -/* unpeer commands - * --------------- - */ - -unpeer_command - : unpeer_keyword address - { - unpeer_node *my_node; - =09 - my_node =3D create_unpeer_node($2); - if (my_node) - APPEND_G_FIFO(cfgt.unpeers, my_node); - } - ;=09 -unpeer_keyword=09 - : T_Unconfig - | T_Unpeer - ; -=09 -=09 -/* Other Modes - * (broadcastclient manycastserver multicastclient) - * ------------------------------------------------ - */ - -other_mode_command - : T_Broadcastclient - { cfgt.broadcastclient =3D 1; } - | T_Manycastserver address_list - { CONCAT_G_FIFOS(cfgt.manycastserver, $2); } - | T_Multicastclient address_list - { CONCAT_G_FIFOS(cfgt.multicastclient, $2); } - | T_Mdnstries T_Integer - { cfgt.mdnstries =3D $2; } - ; - - - -/* Authentication Commands - * ----------------------- - */ - -authentication_command - : T_Automax T_Integer - { - attr_val *atrv; - =09 - atrv =3D create_attr_ival($1, $2); - APPEND_G_FIFO(cfgt.vars, atrv); - } - | T_ControlKey T_Integer - { cfgt.auth.control_key =3D $2; } - | T_Crypto crypto_command_list - {=20 - cfgt.auth.cryptosw++; - CONCAT_G_FIFOS(cfgt.auth.crypto_cmd_list, $2); - } - | T_Keys T_String - { cfgt.auth.keys =3D $2; } - | T_Keysdir T_String - { cfgt.auth.keysdir =3D $2; } - | T_Requestkey T_Integer - { cfgt.auth.request_key =3D $2; } - | T_Revoke T_Integer - { cfgt.auth.revoke =3D $2; } - | T_Trustedkey integer_list_range - { - cfgt.auth.trusted_key_list =3D $2; - - // if (!cfgt.auth.trusted_key_list) - // cfgt.auth.trusted_key_list =3D $2; - // else - // LINK_SLIST(cfgt.auth.trusted_key_list, $2, link); - } - | T_NtpSignDsocket T_String - { cfgt.auth.ntp_signd_socket =3D $2; } - ; - -crypto_command_list - : /* empty list */ - { $$ =3D NULL; } - | crypto_command_list crypto_command - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -crypto_command - : crypto_str_keyword T_String - { $$ =3D create_attr_sval($1, $2); } - | T_Revoke T_Integer - { - $$ =3D NULL; - cfgt.auth.revoke =3D $2; - msyslog(LOG_WARNING, - "'crypto revoke %d' is deprecated, " - "please use 'revoke %d' instead.", - cfgt.auth.revoke, cfgt.auth.revoke); - } - ; - -crypto_str_keyword - : T_Host - | T_Ident - | T_Pw - | T_Randfile - | T_Digest - ; - - -/* Orphan Mode Commands - * -------------------- - */ - -orphan_mode_command - : T_Tos tos_option_list - { CONCAT_G_FIFOS(cfgt.orphan_cmds, $2); } - ; - -tos_option_list - : tos_option_list tos_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | tos_option - {=09 - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -tos_option - : tos_option_int_keyword T_Integer - { $$ =3D create_attr_dval($1, (double)$2); } - | tos_option_dbl_keyword number - { $$ =3D create_attr_dval($1, $2); } - | T_Cohort boolean - { $$ =3D create_attr_dval($1, (double)$2); } - ; - -tos_option_int_keyword - : T_Ceiling - | T_Floor - | T_Orphan - | T_Orphanwait - | T_Minsane - | T_Beacon - ; - -tos_option_dbl_keyword - : T_Mindist - | T_Maxdist - | T_Minclock - | T_Maxclock - ; - - -/* Monitoring Commands - * ------------------- - */ - -monitoring_command - : T_Statistics stats_list - { CONCAT_G_FIFOS(cfgt.stats_list, $2); } - | T_Statsdir T_String - { - if (input_from_file) { - cfgt.stats_dir =3D $2; - } else { - YYFREE($2); - yyerror(ip_file, "statsdir remote configuration ignored"); - } - } - | T_Filegen stat filegen_option_list - { - filegen_node *fgn; - =09 - fgn =3D create_filegen_node($2, $3); - APPEND_G_FIFO(cfgt.filegen_opts, fgn); - } - ; - -stats_list - : stats_list stat=20 - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - | stat - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_int_node($1)); - } - ; - -stat - : T_Clockstats - | T_Cryptostats - | T_Loopstats - | T_Peerstats - | T_Rawstats - | T_Sysstats - | T_Timingstats - | T_Protostats - ; - -filegen_option_list - : /* empty list */ - { $$ =3D NULL; } - | filegen_option_list filegen_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -filegen_option - : T_File T_String - { - if (input_from_file) { - $$ =3D create_attr_sval($1, $2); - } else { - $$ =3D NULL; - YYFREE($2); - yyerror(ip_file, "filegen file remote config ignored"); - } - } - | T_Type filegen_type - { - if (input_from_file) { - $$ =3D create_attr_ival($1, $2); - } else { - $$ =3D NULL; - yyerror(ip_file, "filegen type remote config ignored"); - } - } - | link_nolink - { - const char *err; - =09 - if (input_from_file) { - $$ =3D create_attr_ival(T_Flag, $1); - } else { - $$ =3D NULL; - if (T_Link =3D=3D $1) - err =3D "filegen link remote config ignored"; - else - err =3D "filegen nolink remote config ignored"; - yyerror(ip_file, err); - } - } - | enable_disable - { $$ =3D create_attr_ival(T_Flag, $1); } - ; - -link_nolink - : T_Link - | T_Nolink - ; - -enable_disable - : T_Enable - | T_Disable - ; - -filegen_type - : T_None - | T_Pid - | T_Day - | T_Week - | T_Month - | T_Year - | T_Age - ; - - -/* Access Control Commands - * ----------------------- - */ - -access_control_command - : T_Discard discard_option_list - { - CONCAT_G_FIFOS(cfgt.discard_opts, $2); - } - | T_Mru mru_option_list - { - CONCAT_G_FIFOS(cfgt.mru_opts, $2); - } - | T_Restrict address ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node($2, NULL, $3, - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict ip_address T_Mask ip_address ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node($2, $4, $5, - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Default ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node(NULL, NULL, $3, - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Ipv4_flag T_Default ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node( - create_address_node( - estrdup("0.0.0.0"),=20 - AF_INET), - create_address_node( - estrdup("0.0.0.0"),=20 - AF_INET), - $4,=20 - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Ipv6_flag T_Default ac_flag_list - { - restrict_node *rn; - =09 - rn =3D create_restrict_node( - create_address_node( - estrdup("::"),=20 - AF_INET6), - create_address_node( - estrdup("::"),=20 - AF_INET6), - $4,=20 - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Source ac_flag_list - { - restrict_node * rn; - - APPEND_G_FIFO($3, create_int_node($2)); - rn =3D create_restrict_node( - NULL, NULL, $3, ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - ; - -ac_flag_list - : /* empty list is allowed */ - { $$ =3D NULL; } - | ac_flag_list access_control_flag - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - ; - -access_control_flag - : T_Flake - | T_Ignore - | T_Kod - | T_Mssntp - | T_Limited - | T_Lowpriotrap - | T_Nomodify - | T_Nomrulist - | T_Nopeer - | T_Noquery - | T_Noserve - | T_Notrap - | T_Notrust - | T_Ntpport - | T_Version - ; - -discard_option_list - : discard_option_list discard_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | discard_option=20 - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -discard_option - : discard_option_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - ; - -discard_option_keyword - : T_Average - | T_Minimum - | T_Monitor - ; - -mru_option_list - : mru_option_list mru_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | mru_option=20 - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -mru_option - : mru_option_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - ; - -mru_option_keyword - : T_Incalloc - | T_Incmem - | T_Initalloc - | T_Initmem - | T_Maxage - | T_Maxdepth - | T_Maxmem - | T_Mindepth - ; - -/* Fudge Commands - * -------------- - */ - -fudge_command - : T_Fudge address fudge_factor_list - { - addr_opts_node *aon; - =09 - aon =3D create_addr_opts_node($2, $3); - APPEND_G_FIFO(cfgt.fudge, aon); - } - ; - -fudge_factor_list - : fudge_factor_list fudge_factor - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | fudge_factor - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; -=09 -fudge_factor - : fudge_factor_dbl_keyword number - { $$ =3D create_attr_dval($1, $2); } - | fudge_factor_bool_keyword boolean - { $$ =3D create_attr_ival($1, $2); } - | T_Stratum T_Integer - { $$ =3D create_attr_ival($1, $2); } - | T_Abbrev T_String - { $$ =3D create_attr_sval($1, $2); } - | T_Refid T_String - { $$ =3D create_attr_sval($1, $2); } - ; - -fudge_factor_dbl_keyword - : T_Time1 - | T_Time2 - ; - -fudge_factor_bool_keyword - : T_Flag1 - | T_Flag2 - | T_Flag3 - | T_Flag4 - ; - -/* rlimit Commands - * --------------- - */ - -rlimit_command - : T_Rlimit rlimit_option_list - { CONCAT_G_FIFOS(cfgt.rlimit, $2); } - ; - -rlimit_option_list - : rlimit_option_list rlimit_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | rlimit_option - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -rlimit_option - : rlimit_option_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - ; - -rlimit_option_keyword - : T_Memlock - | T_Stacksize - | T_Filenum - ; - - -/* Command for System Options - * -------------------------- - */ - -system_option_command - : T_Enable system_option_list - { CONCAT_G_FIFOS(cfgt.enable_opts, $2); } - | T_Disable system_option_list - { CONCAT_G_FIFOS(cfgt.disable_opts, $2); } - ; - -system_option_list - : system_option_list system_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | system_option - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -system_option - : system_option_flag_keyword - { $$ =3D create_attr_ival(T_Flag, $1); } - | system_option_local_flag_keyword - {=20 - if (input_from_file) { - $$ =3D create_attr_ival(T_Flag, $1); - } else { - char err_str[128]; - =09 - $$ =3D NULL; - snprintf(err_str, sizeof(err_str), - "enable/disable %s remote configuration ignored", - keyword($1)); - yyerror(ip_file, err_str); - } - } - ; - -system_option_flag_keyword - : T_Auth - | T_Bclient - | T_Calibrate - | T_Kernel - | T_Monitor - | T_Ntp - ; - -system_option_local_flag_keyword - : T_Mode7 - | T_Stats - ; - -/* Tinker Commands - * --------------- - */ - -tinker_command - : T_Tinker tinker_option_list - { CONCAT_G_FIFOS(cfgt.tinker, $2); } - ; - -tinker_option_list - : tinker_option_list tinker_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | tinker_option - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -tinker_option - : tinker_option_keyword number - { $$ =3D create_attr_dval($1, $2); } - ; - -tinker_option_keyword - : T_Allan - | T_Dispersion - | T_Freq - | T_Huffpuff - | T_Panic - | T_Step - | T_Stepout - | T_Tick - ; - - -/* Miscellaneous Commands - * ---------------------- - */ - -miscellaneous_command - : interface_command - | reset_command - | misc_cmd_dbl_keyword number - { - attr_val *av; - =09 - av =3D create_attr_dval($1, $2); - APPEND_G_FIFO(cfgt.vars, av); - } - | misc_cmd_str_keyword T_String - { - attr_val *av; - =09 - av =3D create_attr_sval($1, $2); - APPEND_G_FIFO(cfgt.vars, av); - } - | misc_cmd_str_lcl_keyword T_String - { - char error_text[64]; - attr_val *av; - - if (input_from_file) { - av =3D create_attr_sval($1, $2); - APPEND_G_FIFO(cfgt.vars, av); - } else { - YYFREE($2); - snprintf(error_text, sizeof(error_text), - "%s remote config ignored", - keyword($1)); - yyerror(ip_file, error_text); - } - } - | T_Includefile T_String command - { - if (!input_from_file) { - yyerror(ip_file, "remote includefile ignored"); - break; - } - if (curr_include_level >=3D MAXINCLUDELEVEL) { - fprintf(stderr, "getconfig: Maximum include file level exceeded.\n")= ; - msyslog(LOG_ERR, "getconfig: Maximum include file level exceeded.");= - } else { - fp[curr_include_level + 1] =3D F_OPEN(FindConfig($2), "r"); - if (fp[curr_include_level + 1] =3D=3D NULL) { - fprintf(stderr, "getconfig: Couldn't open <%s>\n", FindConfig($2));= - msyslog(LOG_ERR, "getconfig: Couldn't open <%s>", FindConfig($2)); - } else { - ip_file =3D fp[++curr_include_level]; - } - } - } - | T_End - { - while (curr_include_level !=3D -1) - FCLOSE(fp[curr_include_level--]); - } - | T_Driftfile drift_parm - { /* see drift_parm below for actions */ } - | T_Logconfig log_config_list - { CONCAT_G_FIFOS(cfgt.logconfig, $2); } - | T_Phone string_list - { CONCAT_G_FIFOS(cfgt.phone, $2); } - | T_Setvar variable_assign - { APPEND_G_FIFO(cfgt.setvar, $2); } - | T_Trap ip_address trap_option_list - { - addr_opts_node *aon; - =09 - aon =3D create_addr_opts_node($2, $3); - APPEND_G_FIFO(cfgt.trap, aon); - } - | T_Ttl integer_list - { CONCAT_G_FIFOS(cfgt.ttl, $2); } - ; - -misc_cmd_dbl_keyword - : T_Broadcastdelay - | T_Nonvolatile - | T_Tick - ; - -misc_cmd_str_keyword - : T_Ident - | T_Leapfile - | T_Pidfile - ; - -misc_cmd_str_lcl_keyword - : T_Logfile - | T_Saveconfigdir - ; - -drift_parm - : T_String - { - attr_val *av; - =09 - av =3D create_attr_sval(T_Driftfile, $1); - APPEND_G_FIFO(cfgt.vars, av); - } - | T_String T_Double - { - attr_val *av; - =09 - av =3D create_attr_sval(T_Driftfile, $1); - APPEND_G_FIFO(cfgt.vars, av); - av =3D create_attr_dval(T_WanderThreshold, $2); - APPEND_G_FIFO(cfgt.vars, av); - } - | /* Null driftfile, indicated by empty string "" */ - { - attr_val *av; - =09 - av =3D create_attr_sval(T_Driftfile, ""); - APPEND_G_FIFO(cfgt.vars, av); - } - ; - -variable_assign - : T_String '=3D' T_String t_default_or_zero - { $$ =3D create_setvar_node($1, $3, $4); } - ; - -t_default_or_zero - : T_Default - | /* empty, no "default" modifier */ - { $$ =3D 0; } - ; - -trap_option_list - : /* empty list */ - { $$ =3D NULL; } - | trap_option_list trap_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -trap_option - : T_Port T_Integer - { $$ =3D create_attr_ival($1, $2); } - | T_Interface ip_address - { - $$ =3D create_attr_sval($1, estrdup($2->address)); - destroy_address_node($2); - } - ; - -log_config_list - : log_config_list log_config_command - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | log_config_command - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -log_config_command - : T_String - { - char prefix; - char * type; - =09 - switch ($1[0]) { - =09 - case '+': - case '-': - case '=3D': - prefix =3D $1[0]; - type =3D $1 + 1; - break; - =09 - default: - prefix =3D '=3D'; - type =3D $1; - }=09 - =09 - $$ =3D create_attr_sval(prefix, estrdup(type)); - YYFREE($1); - } - ; - -interface_command - : interface_nic nic_rule_action nic_rule_class - { - nic_rule_node *nrn; - =09 - nrn =3D create_nic_rule_node($3, NULL, $2); - APPEND_G_FIFO(cfgt.nic_rules, nrn); - } - | interface_nic nic_rule_action T_String - { - nic_rule_node *nrn; - =09 - nrn =3D create_nic_rule_node(0, $3, $2); - APPEND_G_FIFO(cfgt.nic_rules, nrn); - } - ; - -interface_nic - : T_Interface - | T_Nic - ; - -nic_rule_class - : T_All - | T_Ipv4 - | T_Ipv6 - | T_Wildcard - ; - -nic_rule_action - : T_Listen - | T_Ignore - | T_Drop - ; - -reset_command - : T_Reset counter_set_list - { CONCAT_G_FIFOS(cfgt.reset_counters, $2); } - ; - -counter_set_list - : counter_set_list counter_set_keyword - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - | counter_set_keyword - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_int_node($1)); - } - ; - -counter_set_keyword - : T_Allpeers - | T_Auth - | T_Ctl - | T_Io - | T_Mem - | T_Sys - | T_Timer - ; - - - -/* Miscellaneous Rules - * ------------------- - */ - -integer_list - : integer_list T_Integer - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - | T_Integer - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_int_node($1)); - } - ; - -integer_list_range - : integer_list_range integer_list_range_elt - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | integer_list_range_elt - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -integer_list_range_elt - : T_Integer - { $$ =3D create_attr_ival('i', $1); } - | integer_range - ; - -integer_range - : '(' T_Integer T_Ellipsis T_Integer ')' - { $$ =3D create_attr_rangeval('-', $2, $4); } - ; - -string_list - : string_list T_String - { - $$ =3D $1; - APPEND_G_FIFO($$, create_string_node($2)); - } - | T_String - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_string_node($1)); - } - ; - -address_list - : address_list address - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | address - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -boolean - : T_Integer - { - if ($1 !=3D 0 && $1 !=3D 1) { - yyerror(ip_file, "Integer value is not boolean (0 or 1). Assuming 1"= ); - $$ =3D 1; - } else { - $$ =3D $1; - } - } - | T_True { $$ =3D 1; } - | T_False { $$ =3D 0; } - ; - -number - : T_Integer { $$ =3D (double)$1; } - | T_Double - ; - - -/* Simulator Configuration Commands - * -------------------------------- - */ - -simulate_command - : sim_conf_start '{' sim_init_statement_list sim_server_list '}' - { - sim_node *sn; - =09 - sn =3D create_sim_node($3, $4); - APPEND_G_FIFO(cfgt.sim_details, sn); - - /* Revert from ; to \n for end-of-command */ - old_config_style =3D 1; - } - ; - -/* The following is a terrible hack to get the configuration file to - * treat newlines as whitespace characters within the simulation. - * This is needed because newlines are significant in the rest of the - * configuration file. - */ -sim_conf_start - : T_Simulate { old_config_style =3D 0; } - ; - -sim_init_statement_list - : sim_init_statement_list sim_init_statement T_EOC - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_init_statement T_EOC - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_init_statement - : sim_init_keyword '=3D' number - { $$ =3D create_attr_dval($1, $3); } - ; - -sim_init_keyword - : T_Beep_Delay - | T_Sim_Duration - ; - -sim_server_list - : sim_server_list sim_server - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_server - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_server - : sim_server_name '{' sim_server_offset sim_act_list '}' - { $$ =3D ONLY_SIM(create_sim_server($1, $3, $4)); } - ; - -sim_server_offset - : T_Server_Offset '=3D' number T_EOC - { $$ =3D $3; } - ; - -sim_server_name - : T_Server '=3D' address - { $$ =3D $3; } - ; - -sim_act_list - : sim_act_list sim_act - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_act - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_act - : T_Duration '=3D' number '{' sim_act_stmt_list '}' - { $$ =3D ONLY_SIM(create_sim_script_info($3, $5)); } - ; - -sim_act_stmt_list - : sim_act_stmt_list sim_act_stmt T_EOC - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_act_stmt T_EOC - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_act_stmt - : sim_act_keyword '=3D' number - { $$ =3D create_attr_dval($1, $3); } - ; - -sim_act_keyword - : T_Freq_Offset - | T_Wander - | T_Jitter - | T_Prop_Delay - | T_Proc_Delay - ; - -%% - -void=20 -yyerror( - struct FILE_INFO *ip_file, - const char *msg - ) -{ - int retval; - - ip_file->err_line_no =3D ip_file->prev_token_line_no; - ip_file->err_col_no =3D ip_file->prev_token_col_no; -=09 - msyslog(LOG_ERR,=20 - "line %d column %d %s",=20 - ip_file->err_line_no, - ip_file->err_col_no, - msg); - if (!input_from_file) { - /* Save the error message in the correct buffer */ - retval =3D snprintf(remote_config.err_msg + remote_config.err_pos, - MAXLINE - remote_config.err_pos, - "column %d %s", - ip_file->err_col_no, msg); - - /* Increment the value of err_pos */ - if (retval > 0) - remote_config.err_pos +=3D retval; - - /* Increment the number of errors */ - ++remote_config.no_errors; - } -} - - -/* - * token_name - convert T_ token integers to text - * example: token_name(T_Server) returns "T_Server" - */ -const char * -token_name( - int token - ) -{ - return yytname[YYTRANSLATE(token)]; -} - - -/* Initial Testing function -- ignore */ -#if 0 -int main(int argc, char *argv[]) -{ - ip_file =3D FOPEN(argv[1], "r"); - if (!ip_file) - fprintf(stderr, "ERROR!! Could not open file: %s\n", argv[1]); - yyparse(); - return 0; -} -#endif - --------------090800070300040107060309-- From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 20:04: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 D5024571; Thu, 2 Apr 2015 20:04:10 +0000 (UTC) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 98CCDC41; Thu, 2 Apr 2015 20:04:10 +0000 (UTC) Received: by obbgh1 with SMTP id gh1so138254638obb.1; Thu, 02 Apr 2015 13:04:10 -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=VmJ222OcUfN53aXPDEjDiRFsKEQQUr3MJOECKUTCmv8=; b=P9bUPWTul5g1KXMj+jITpAPqEAwsM+eY3wIKmXlEPZN3Z1RM6hrlicCRo49RtUXNCl GtQFDZcCN1HX0V2jcIAVjAYxlhwFjHKOO9ZlULf7q9gse0nVlNfrOHwpJBMJKtWsTh+Y nZVkeliIekxl/flrm1mFiF0NGSLFrU1ZFq2yVVjSZ7mJl6APSoaPfzvy2tItQYMPCopi fZLiYe8uh/+GKc1kmAJAMDLI38HHidWSu9Wfr5GVtR+6vyCOm8zZmG8fPudcTcD58nxM SisgDMu/8UG0IzNdSirPxICk3JGQZoif38kR9ATEFhwXD3IYxcX40sp9RxzlZGIYA9qs Azhg== MIME-Version: 1.0 X-Received: by 10.60.33.106 with SMTP id q10mr48119403oei.67.1428005049501; Thu, 02 Apr 2015 13:04:09 -0700 (PDT) Sender: royce.williams@gmail.com Received: by 10.202.79.205 with HTTP; Thu, 2 Apr 2015 13:04:09 -0700 (PDT) Received: by 10.202.79.205 with HTTP; Thu, 2 Apr 2015 13:04:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Apr 2015 12:04:09 -0800 X-Google-Sender-Auth: 3SvuA2SZRB_hTc29khbmhF_7LiE Message-ID: Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) From: Royce Williams To: Chris H X-Mailman-Approved-At: Thu, 02 Apr 2015 21:09:20 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Eitan Adler , Samuel Cassiba , freebsd-current@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 20:04:10 -0000 On Apr 2, 2015 9:44 AM, "Chris H" wrote: > > IMHO I believe that the height of the bar, is directly proportionate > to the quality of the product. We were all new once. There are many reasons - language, social fluidity, economic background, etc. - for which a too-high initial hurdle can make a high bar so insurmountable as to prevent valuable contributors from getting in at all. Mentorship needs to take this into account. The trick is maintaining quality control at higher volumes, without quashing newbie enthusiasm. :) There are tools for managing this somewhat, but open source needs to grow more in this area. Royce From owner-freebsd-current@FreeBSD.ORG Thu Apr 2 21:29:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E709F6F; Thu, 2 Apr 2015 21:29:59 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 4F2E6334A; Thu, 2 Apr 2015 21:29:58 +0000 (UTC) Message-ID: <551DB4D5.8030805@FreeBSD.org> Date: Thu, 02 Apr 2015 17:29:57 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Manfred Antar , freebsd-current@freebsd.org Subject: Re: ntpd errors after upgrade on current amd64 References: <201504011533.t31FWRhp059914@pozo.com> <551DA257.6060100@FreeBSD.org> In-Reply-To: <551DA257.6060100@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------080502090604030801050601" Cc: roberto@FreeBSD.org, Cy Schubert , Xin LI , Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Apr 2015 21:29:59 -0000 This is a multi-part message in MIME format. --------------080502090604030801050601 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/02/2015 16:11, Jung-uk Kim wrote: > On 04/01/2015 11:32, Manfred Antar wrote: >> Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 >> for fe80::1%2 fails: Can't assign requested address > > A separate issue, I think. This issue will be fixed in the next release, it seems. http://lists.ntp.org/pipermail/bk-ntp-stable-send/2015-March/000594.html Please try the updated patch. It fixed the problem for me. Note this patch supersedes the previous patch. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVHbTRAAoJEHyflib82/FGPP0H/iZpzPxGokR1CD16K4i/dH/F qSfefNpW20dnl3ozIv3P0e1yC/xxMUJJNF4HQ8fwjr1bTI3efZ8gTPR2Zk3k5r7i 2OcQfrQma3cSkzoks6tjobor/yGpQEHJkwFwSSEsUKgA/rI0FpvviHQsQOi/6BnA KbWQWLt5ZTe/V/27Zc2AU38evJxRFiYiJTycutQzMZ1NHle8DWqQ7vMKOe+CilAW MX/16AW2tp2yrBs9XQKmkh0Yd2dTLJuBxAV7Rl8cVUZgdELqyE2FNSEL7L7TKKbs QjJj6+7oee/c22Fc11CA7fBRFkK6m8fzmL/2CuTvf0JLefisCvMMcymvxH/edoM= =UPrE -----END PGP SIGNATURE----- --------------080502090604030801050601 Content-Type: text/x-patch; name="ntp.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ntp.diff" Index: contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c (revision 281003) +++ contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c (working copy) @@ -212,6 +212,9 @@ internal_current(isc_interfaceiter_t *iter) { get_addr(family, &iter->current.broadcast, ifa->ifa_broadaddr, ifa->ifa_name); =20 +#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX + iter->current.ifindex =3D if_nametoindex(iter->current.name); +#endif return (ISC_R_SUCCESS); } =20 Index: contrib/ntp/lib/isc/unix/ifiter_ioctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/ntp/lib/isc/unix/ifiter_ioctl.c (revision 281003) +++ contrib/ntp/lib/isc/unix/ifiter_ioctl.c (working copy) @@ -588,6 +588,9 @@ internal_current4(isc_interfaceiter_t *iter) { } iter->current.netmask.type.in6.s6_addr[i] =3D (~0 << bits) & 0xff; } +#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX + iter->current.ifindex =3D if_nametoindex(iter->current.name); +#endif return (ISC_R_SUCCESS); =20 inet: @@ -664,6 +667,9 @@ internal_current4(isc_interfaceiter_t *iter) { } get_addr(family, &iter->current.netmask, (struct sockaddr *)&ifreq.ifr_addr, ifreq.ifr_name); +#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX + iter->current.ifindex =3D if_nametoindex(iter->current.name); +#endif return (ISC_R_SUCCESS); } =20 @@ -704,7 +710,6 @@ internal_current6(isc_interfaceiter_t *iter) { get_addr(family, &iter->current.address, (struct sockaddr *)&lifreq.lifr_addr, lifreq.lifr_name); =20 - iter->current.ifindex =3D lifreq.lifr_index; if (isc_netaddr_islinklocal(&iter->current.address)) isc_netaddr_setzone(&iter->current.address,=20 (isc_uint32_t)lifreq.lifr_index); @@ -844,7 +849,9 @@ internal_current6(isc_interfaceiter_t *iter) { iter->current.netmask.type.in6.s6_addr[i / 8] =3D (~0 << bits) & 0xff; } - +#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX + iter->current.ifindex =3D if_nametoindex(iter->current.name); +#endif return (ISC_R_SUCCESS); } #endif @@ -867,6 +874,9 @@ internal_current6(isc_interfaceiter_t *iter) { get_addr(family, &iter->current.netmask, (struct sockaddr *)&lifreq.lifr_addr, lifreq.lifr_name); =20 +#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX + iter->current.ifindex =3D if_nametoindex(iter->current.name); +#endif return (ISC_R_SUCCESS); } #endif Index: contrib/ntp/ntpd/ntp_crypto.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/ntp/ntpd/ntp_crypto.c (revision 281003) +++ contrib/ntp/ntpd/ntp_crypto.c (working copy) @@ -826,10 +826,10 @@ crypto_recv( * Decrypt the cookie, hunting all the time for * errors. */ - if (vallen =3D=3D (u_int) EVP_PKEY_size(host_pkey)) { + if (vallen =3D=3D (u_int)EVP_PKEY_size(host_pkey)) { u_int32 *cookiebuf =3D malloc( RSA_size(host_pkey->pkey.rsa)); - if (cookiebuf =3D=3D NULL) { + if (!cookiebuf) { rval =3D XEVNT_CKY; break; } @@ -3817,7 +3817,7 @@ crypto_setup(void) randfile); exit (-1); } - get_systime(&seed); + arc4random_buf(&seed, sizeof(l_fp)); RAND_seed(&seed, sizeof(l_fp)); RAND_write_file(randfile); #ifdef DEBUG @@ -3850,36 +3850,6 @@ crypto_setup(void) pinfo =3D crypto_key(filename, passwd, NULL); if (pinfo =3D=3D NULL) { msyslog(LOG_ERR, - "crypto_setup: random seed file not specified"); - exit (-1); - } - if ((bytes =3D RAND_load_file(rand_file, -1)) =3D=3D 0) { - msyslog(LOG_ERR, - "crypto_setup: random seed file %s not found\n", - rand_file); - exit (-1); - } - arc4random_buf(&seed, sizeof(l_fp)); - RAND_seed(&seed, sizeof(l_fp)); - RAND_write_file(rand_file); - OpenSSL_add_all_algorithms(); -#ifdef DEBUG - if (debug) - printf( - "crypto_setup: OpenSSL version %lx random seed file %s bytes read = %d\n", - SSLeay(), rand_file, bytes); -#endif - - /* - * Load required host key from file "ntpkey_host_". If - * no host key file is not found or has invalid password, life - * as we know it ends. The host key also becomes the default - * sign key.=20 - */ - snprintf(filename, sizeof(filename), "ntpkey_host_%s", hostname); - pinfo =3D crypto_key(filename, passwd, NULL); - if (pinfo =3D=3D NULL) { - msyslog(LOG_ERR, "crypto_setup: host key file %s not found or corrupt", filename); exit (-1); Index: contrib/ntp/ntpd/ntp_parser.y =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- contrib/ntp/ntpd/ntp_parser.y (revision 281003) +++ contrib/ntp/ntpd/ntp_parser.y (working copy) @@ -1,1641 +0,0 @@ -/* ntp_parser.y - * - * The parser for the NTP configuration file. - * - * Written By: Sachin Kamboj - * University of Delaware - * Newark, DE 19711 - * Copyright (c) 2006 - */ - -%parse-param { struct FILE_INFO *ip_file } -%lex-param { struct FILE_INFO *ip_file } - -%{ - #ifdef HAVE_CONFIG_H - # include - #endif - - #include "ntp.h" - #include "ntpd.h" - #include "ntp_machine.h" - #include "ntp_stdlib.h" - #include "ntp_filegen.h" - #include "ntp_scanner.h" - #include "ntp_config.h" - #include "ntp_crypto.h" - - #include "ntpsim.h" /* HMS: Do we really want this all the time? */ - /* SK: It might be a good idea to always - include the simulator code. That way - someone can use the same configuration file - for both the simulator and the daemon - */ - - #define YYMALLOC emalloc - #define YYFREE free - #define YYERROR_VERBOSE - #define YYMAXDEPTH 1000 /* stop the madness sooner */ - void yyerror(struct FILE_INFO *ip_file, const char *msg); - - #ifdef SIM - # define ONLY_SIM(a) (a) - #else - # define ONLY_SIM(a) NULL - #endif -%} - -/*=20 - * Enable generation of token names array even without YYDEBUG. - * We access via token_name() defined below. - */ -%token-table - -%union { - char * String; - double Double; - int Integer; - unsigned U_int; - gen_fifo * Generic_fifo; - attr_val * Attr_val; - attr_val_fifo * Attr_val_fifo; - int_fifo * Int_fifo; - string_fifo * String_fifo; - address_node * Address_node; - address_fifo * Address_fifo; - setvar_node * Set_var; - server_info * Sim_server; - server_info_fifo * Sim_server_fifo; - script_info * Sim_script; - script_info_fifo * Sim_script_fifo; -} - -/* TERMINALS (do not appear left of colon) */ -%token T_Abbrev -%token T_Age -%token T_All -%token T_Allan -%token T_Allpeers -%token T_Auth -%token T_Autokey -%token T_Automax -%token T_Average -%token T_Bclient -%token T_Beacon -%token T_Broadcast -%token T_Broadcastclient -%token T_Broadcastdelay -%token T_Burst -%token T_Calibrate -%token T_Ceiling -%token T_Clockstats -%token T_Cohort -%token T_ControlKey -%token T_Crypto -%token T_Cryptostats -%token T_Ctl -%token T_Day -%token T_Default -%token T_Digest -%token T_Disable -%token T_Discard -%token T_Dispersion -%token T_Double /* not a token */ -%token T_Driftfile -%token T_Drop -%token T_Ellipsis /* "..." not "ellipsis" */ -%token T_Enable -%token T_End -%token T_False -%token T_File -%token T_Filegen -%token T_Filenum -%token T_Flag1 -%token T_Flag2 -%token T_Flag3 -%token T_Flag4 -%token T_Flake -%token T_Floor -%token T_Freq -%token T_Fudge -%token T_Host -%token T_Huffpuff -%token T_Iburst -%token T_Ident -%token T_Ignore -%token T_Incalloc -%token T_Incmem -%token T_Initalloc -%token T_Initmem -%token T_Includefile -%token T_Integer /* not a token */ -%token T_Interface -%token T_Intrange /* not a token */ -%token T_Io -%token T_Ipv4 -%token T_Ipv4_flag -%token T_Ipv6 -%token T_Ipv6_flag -%token T_Kernel -%token T_Key -%token T_Keys -%token T_Keysdir -%token T_Kod -%token T_Mssntp -%token T_Leapfile -%token T_Limited -%token T_Link -%token T_Listen -%token T_Logconfig -%token T_Logfile -%token T_Loopstats -%token T_Lowpriotrap -%token T_Manycastclient -%token T_Manycastserver -%token T_Mask -%token T_Maxage -%token T_Maxclock -%token T_Maxdepth -%token T_Maxdist -%token T_Maxmem -%token T_Maxpoll -%token T_Mdnstries -%token T_Mem -%token T_Memlock -%token T_Minclock -%token T_Mindepth -%token T_Mindist -%token T_Minimum -%token T_Minpoll -%token T_Minsane -%token T_Mode -%token T_Mode7 -%token T_Monitor -%token T_Month -%token T_Mru -%token T_Multicastclient -%token T_Nic -%token T_Nolink -%token T_Nomodify -%token T_Nomrulist -%token T_None -%token T_Nonvolatile -%token T_Nopeer -%token T_Noquery -%token T_Noselect -%token T_Noserve -%token T_Notrap -%token T_Notrust -%token T_Ntp -%token T_Ntpport -%token T_NtpSignDsocket -%token T_Orphan -%token T_Orphanwait -%token T_Panic -%token T_Peer -%token T_Peerstats -%token T_Phone -%token T_Pid -%token T_Pidfile -%token T_Pool -%token T_Port -%token T_Preempt -%token T_Prefer -%token T_Protostats -%token T_Pw -%token T_Randfile -%token T_Rawstats -%token T_Refid -%token T_Requestkey -%token T_Reset -%token T_Restrict -%token T_Revoke -%token T_Rlimit -%token T_Saveconfigdir -%token T_Server -%token T_Setvar -%token T_Source -%token T_Stacksize -%token T_Statistics -%token T_Stats -%token T_Statsdir -%token T_Step -%token T_Stepout -%token T_Stratum -%token T_String /* not a token */ -%token T_Sys -%token T_Sysstats -%token T_Tick -%token T_Time1 -%token T_Time2 -%token T_Timer -%token T_Timingstats -%token T_Tinker -%token T_Tos -%token T_Trap -%token T_True -%token T_Trustedkey -%token T_Ttl -%token T_Type -%token T_U_int /* Not a token */ -%token T_Unconfig -%token T_Unpeer -%token T_Version -%token T_WanderThreshold /* Not a token */ -%token T_Week -%token T_Wildcard -%token T_Xleave -%token T_Year -%token T_Flag /* Not a token */ -%token T_EOC - - -/* NTP Simulator Tokens */ -%token T_Simulate -%token T_Beep_Delay -%token T_Sim_Duration -%token T_Server_Offset -%token T_Duration -%token T_Freq_Offset -%token T_Wander -%token T_Jitter -%token T_Prop_Delay -%token T_Proc_Delay - - - -/*** NON-TERMINALS ***/ -%type access_control_flag -%type ac_flag_list -%type address -%type address_fam -%type address_list -%type boolean -%type client_type -%type counter_set_keyword -%type counter_set_list -%type crypto_command -%type crypto_command_list -%type crypto_str_keyword -%type discard_option -%type discard_option_keyword -%type discard_option_list -%type enable_disable -%type filegen_option -%type filegen_option_list -%type filegen_type -%type fudge_factor -%type fudge_factor_bool_keyword -%type fudge_factor_dbl_keyword -%type fudge_factor_list -%type integer_list -%type integer_list_range -%type integer_list_range_elt -%type integer_range -%type nic_rule_action -%type interface_command -%type interface_nic -%type ip_address -%type link_nolink -%type log_config_command -%type log_config_list -%type misc_cmd_dbl_keyword -%type misc_cmd_str_keyword -%type misc_cmd_str_lcl_keyword -%type mru_option -%type mru_option_keyword -%type mru_option_list -%type nic_rule_class -%type number -%type option -%type option_flag -%type option_flag_keyword -%type option_list -%type option_int -%type option_int_keyword -%type option_str -%type option_str_keyword -%type reset_command -%type rlimit_option_keyword -%type rlimit_option -%type rlimit_option_list -%type stat -%type stats_list -%type string_list -%type system_option -%type system_option_flag_keyword -%type system_option_local_flag_keyword -%type system_option_list -%type t_default_or_zero -%type tinker_option_keyword -%type tinker_option -%type tinker_option_list -%type tos_option -%type tos_option_dbl_keyword -%type tos_option_int_keyword -%type tos_option_list -%type trap_option -%type trap_option_list -%type unpeer_keyword -%type variable_assign - -/* NTP Simulator non-terminals */ -%type sim_init_statement -%type sim_init_statement_list -%type sim_init_keyword -%type sim_server_list -%type sim_server -%type sim_server_offset -%type sim_server_name -%type sim_act -%type sim_act_list -%type sim_act_keyword -%type sim_act_stmt_list -%type sim_act_stmt - -%% - -/* ntp.conf - * Configuration File Grammar - * -------------------------- - */ - -configuration - : command_list - ; - -command_list - : command_list command T_EOC - | command T_EOC - | error T_EOC - { - /* I will need to incorporate much more fine grained - * error messages. The following should suffice for - * the time being. - */ - msyslog(LOG_ERR,=20 - "syntax error in %s line %d, column %d", - ip_file->fname, - ip_file->err_line_no, - ip_file->err_col_no); - } - ; - -command : /* NULL STATEMENT */ - | server_command - | unpeer_command - | other_mode_command - | authentication_command - | monitoring_command - | access_control_command - | orphan_mode_command - | fudge_command - | rlimit_command - | system_option_command - | tinker_command - | miscellaneous_command - | simulate_command - ; - -/* Server Commands - * --------------- - */ - -server_command - : client_type address option_list - { - peer_node *my_node; - - my_node =3D create_peer_node($1, $2, $3); - APPEND_G_FIFO(cfgt.peers, my_node); - } - ; - -client_type - : T_Server - | T_Pool - | T_Peer - | T_Broadcast - | T_Manycastclient - ; - -address - : ip_address - | address_fam T_String - { $$ =3D create_address_node($2, $1); } - ; - -ip_address - : T_String=20 - { $$ =3D create_address_node($1, AF_UNSPEC); } - ; - -address_fam - : T_Ipv4_flag - { $$ =3D AF_INET; } - | T_Ipv6_flag - { $$ =3D AF_INET6; } - ; - -option_list - : /* empty list */ - { $$ =3D NULL; } - | option_list option=20 - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -option - : option_flag - | option_int - | option_str - ; - -option_flag - : option_flag_keyword - { $$ =3D create_attr_ival(T_Flag, $1); } - ; - -option_flag_keyword - : T_Autokey - | T_Burst - | T_Iburst - | T_Noselect - | T_Preempt - | T_Prefer - | T_True - | T_Xleave - ; - -option_int - : option_int_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - | option_int_keyword T_U_int - { $$ =3D create_attr_uval($1, $2); } - ; - -option_int_keyword - : T_Key - | T_Minpoll - | T_Maxpoll - | T_Ttl - | T_Mode - | T_Version - ; - -option_str - : option_str_keyword T_String - { $$ =3D create_attr_sval($1, $2); } - ; - -option_str_keyword - : T_Ident - ; - - -/* unpeer commands - * --------------- - */ - -unpeer_command - : unpeer_keyword address - { - unpeer_node *my_node; - =09 - my_node =3D create_unpeer_node($2); - if (my_node) - APPEND_G_FIFO(cfgt.unpeers, my_node); - } - ;=09 -unpeer_keyword=09 - : T_Unconfig - | T_Unpeer - ; -=09 -=09 -/* Other Modes - * (broadcastclient manycastserver multicastclient) - * ------------------------------------------------ - */ - -other_mode_command - : T_Broadcastclient - { cfgt.broadcastclient =3D 1; } - | T_Manycastserver address_list - { CONCAT_G_FIFOS(cfgt.manycastserver, $2); } - | T_Multicastclient address_list - { CONCAT_G_FIFOS(cfgt.multicastclient, $2); } - | T_Mdnstries T_Integer - { cfgt.mdnstries =3D $2; } - ; - - - -/* Authentication Commands - * ----------------------- - */ - -authentication_command - : T_Automax T_Integer - { - attr_val *atrv; - =09 - atrv =3D create_attr_ival($1, $2); - APPEND_G_FIFO(cfgt.vars, atrv); - } - | T_ControlKey T_Integer - { cfgt.auth.control_key =3D $2; } - | T_Crypto crypto_command_list - {=20 - cfgt.auth.cryptosw++; - CONCAT_G_FIFOS(cfgt.auth.crypto_cmd_list, $2); - } - | T_Keys T_String - { cfgt.auth.keys =3D $2; } - | T_Keysdir T_String - { cfgt.auth.keysdir =3D $2; } - | T_Requestkey T_Integer - { cfgt.auth.request_key =3D $2; } - | T_Revoke T_Integer - { cfgt.auth.revoke =3D $2; } - | T_Trustedkey integer_list_range - { - cfgt.auth.trusted_key_list =3D $2; - - // if (!cfgt.auth.trusted_key_list) - // cfgt.auth.trusted_key_list =3D $2; - // else - // LINK_SLIST(cfgt.auth.trusted_key_list, $2, link); - } - | T_NtpSignDsocket T_String - { cfgt.auth.ntp_signd_socket =3D $2; } - ; - -crypto_command_list - : /* empty list */ - { $$ =3D NULL; } - | crypto_command_list crypto_command - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -crypto_command - : crypto_str_keyword T_String - { $$ =3D create_attr_sval($1, $2); } - | T_Revoke T_Integer - { - $$ =3D NULL; - cfgt.auth.revoke =3D $2; - msyslog(LOG_WARNING, - "'crypto revoke %d' is deprecated, " - "please use 'revoke %d' instead.", - cfgt.auth.revoke, cfgt.auth.revoke); - } - ; - -crypto_str_keyword - : T_Host - | T_Ident - | T_Pw - | T_Randfile - | T_Digest - ; - - -/* Orphan Mode Commands - * -------------------- - */ - -orphan_mode_command - : T_Tos tos_option_list - { CONCAT_G_FIFOS(cfgt.orphan_cmds, $2); } - ; - -tos_option_list - : tos_option_list tos_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | tos_option - {=09 - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -tos_option - : tos_option_int_keyword T_Integer - { $$ =3D create_attr_dval($1, (double)$2); } - | tos_option_dbl_keyword number - { $$ =3D create_attr_dval($1, $2); } - | T_Cohort boolean - { $$ =3D create_attr_dval($1, (double)$2); } - ; - -tos_option_int_keyword - : T_Ceiling - | T_Floor - | T_Orphan - | T_Orphanwait - | T_Minsane - | T_Beacon - ; - -tos_option_dbl_keyword - : T_Mindist - | T_Maxdist - | T_Minclock - | T_Maxclock - ; - - -/* Monitoring Commands - * ------------------- - */ - -monitoring_command - : T_Statistics stats_list - { CONCAT_G_FIFOS(cfgt.stats_list, $2); } - | T_Statsdir T_String - { - if (input_from_file) { - cfgt.stats_dir =3D $2; - } else { - YYFREE($2); - yyerror(ip_file, "statsdir remote configuration ignored"); - } - } - | T_Filegen stat filegen_option_list - { - filegen_node *fgn; - =09 - fgn =3D create_filegen_node($2, $3); - APPEND_G_FIFO(cfgt.filegen_opts, fgn); - } - ; - -stats_list - : stats_list stat=20 - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - | stat - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_int_node($1)); - } - ; - -stat - : T_Clockstats - | T_Cryptostats - | T_Loopstats - | T_Peerstats - | T_Rawstats - | T_Sysstats - | T_Timingstats - | T_Protostats - ; - -filegen_option_list - : /* empty list */ - { $$ =3D NULL; } - | filegen_option_list filegen_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -filegen_option - : T_File T_String - { - if (input_from_file) { - $$ =3D create_attr_sval($1, $2); - } else { - $$ =3D NULL; - YYFREE($2); - yyerror(ip_file, "filegen file remote config ignored"); - } - } - | T_Type filegen_type - { - if (input_from_file) { - $$ =3D create_attr_ival($1, $2); - } else { - $$ =3D NULL; - yyerror(ip_file, "filegen type remote config ignored"); - } - } - | link_nolink - { - const char *err; - =09 - if (input_from_file) { - $$ =3D create_attr_ival(T_Flag, $1); - } else { - $$ =3D NULL; - if (T_Link =3D=3D $1) - err =3D "filegen link remote config ignored"; - else - err =3D "filegen nolink remote config ignored"; - yyerror(ip_file, err); - } - } - | enable_disable - { $$ =3D create_attr_ival(T_Flag, $1); } - ; - -link_nolink - : T_Link - | T_Nolink - ; - -enable_disable - : T_Enable - | T_Disable - ; - -filegen_type - : T_None - | T_Pid - | T_Day - | T_Week - | T_Month - | T_Year - | T_Age - ; - - -/* Access Control Commands - * ----------------------- - */ - -access_control_command - : T_Discard discard_option_list - { - CONCAT_G_FIFOS(cfgt.discard_opts, $2); - } - | T_Mru mru_option_list - { - CONCAT_G_FIFOS(cfgt.mru_opts, $2); - } - | T_Restrict address ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node($2, NULL, $3, - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict ip_address T_Mask ip_address ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node($2, $4, $5, - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Default ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node(NULL, NULL, $3, - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Ipv4_flag T_Default ac_flag_list - { - restrict_node *rn; - - rn =3D create_restrict_node( - create_address_node( - estrdup("0.0.0.0"),=20 - AF_INET), - create_address_node( - estrdup("0.0.0.0"),=20 - AF_INET), - $4,=20 - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Ipv6_flag T_Default ac_flag_list - { - restrict_node *rn; - =09 - rn =3D create_restrict_node( - create_address_node( - estrdup("::"),=20 - AF_INET6), - create_address_node( - estrdup("::"),=20 - AF_INET6), - $4,=20 - ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - | T_Restrict T_Source ac_flag_list - { - restrict_node * rn; - - APPEND_G_FIFO($3, create_int_node($2)); - rn =3D create_restrict_node( - NULL, NULL, $3, ip_file->line_no); - APPEND_G_FIFO(cfgt.restrict_opts, rn); - } - ; - -ac_flag_list - : /* empty list is allowed */ - { $$ =3D NULL; } - | ac_flag_list access_control_flag - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - ; - -access_control_flag - : T_Flake - | T_Ignore - | T_Kod - | T_Mssntp - | T_Limited - | T_Lowpriotrap - | T_Nomodify - | T_Nomrulist - | T_Nopeer - | T_Noquery - | T_Noserve - | T_Notrap - | T_Notrust - | T_Ntpport - | T_Version - ; - -discard_option_list - : discard_option_list discard_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | discard_option=20 - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -discard_option - : discard_option_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - ; - -discard_option_keyword - : T_Average - | T_Minimum - | T_Monitor - ; - -mru_option_list - : mru_option_list mru_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | mru_option=20 - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -mru_option - : mru_option_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - ; - -mru_option_keyword - : T_Incalloc - | T_Incmem - | T_Initalloc - | T_Initmem - | T_Maxage - | T_Maxdepth - | T_Maxmem - | T_Mindepth - ; - -/* Fudge Commands - * -------------- - */ - -fudge_command - : T_Fudge address fudge_factor_list - { - addr_opts_node *aon; - =09 - aon =3D create_addr_opts_node($2, $3); - APPEND_G_FIFO(cfgt.fudge, aon); - } - ; - -fudge_factor_list - : fudge_factor_list fudge_factor - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | fudge_factor - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; -=09 -fudge_factor - : fudge_factor_dbl_keyword number - { $$ =3D create_attr_dval($1, $2); } - | fudge_factor_bool_keyword boolean - { $$ =3D create_attr_ival($1, $2); } - | T_Stratum T_Integer - { $$ =3D create_attr_ival($1, $2); } - | T_Abbrev T_String - { $$ =3D create_attr_sval($1, $2); } - | T_Refid T_String - { $$ =3D create_attr_sval($1, $2); } - ; - -fudge_factor_dbl_keyword - : T_Time1 - | T_Time2 - ; - -fudge_factor_bool_keyword - : T_Flag1 - | T_Flag2 - | T_Flag3 - | T_Flag4 - ; - -/* rlimit Commands - * --------------- - */ - -rlimit_command - : T_Rlimit rlimit_option_list - { CONCAT_G_FIFOS(cfgt.rlimit, $2); } - ; - -rlimit_option_list - : rlimit_option_list rlimit_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | rlimit_option - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -rlimit_option - : rlimit_option_keyword T_Integer - { $$ =3D create_attr_ival($1, $2); } - ; - -rlimit_option_keyword - : T_Memlock - | T_Stacksize - | T_Filenum - ; - - -/* Command for System Options - * -------------------------- - */ - -system_option_command - : T_Enable system_option_list - { CONCAT_G_FIFOS(cfgt.enable_opts, $2); } - | T_Disable system_option_list - { CONCAT_G_FIFOS(cfgt.disable_opts, $2); } - ; - -system_option_list - : system_option_list system_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | system_option - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -system_option - : system_option_flag_keyword - { $$ =3D create_attr_ival(T_Flag, $1); } - | system_option_local_flag_keyword - {=20 - if (input_from_file) { - $$ =3D create_attr_ival(T_Flag, $1); - } else { - char err_str[128]; - =09 - $$ =3D NULL; - snprintf(err_str, sizeof(err_str), - "enable/disable %s remote configuration ignored", - keyword($1)); - yyerror(ip_file, err_str); - } - } - ; - -system_option_flag_keyword - : T_Auth - | T_Bclient - | T_Calibrate - | T_Kernel - | T_Monitor - | T_Ntp - ; - -system_option_local_flag_keyword - : T_Mode7 - | T_Stats - ; - -/* Tinker Commands - * --------------- - */ - -tinker_command - : T_Tinker tinker_option_list - { CONCAT_G_FIFOS(cfgt.tinker, $2); } - ; - -tinker_option_list - : tinker_option_list tinker_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | tinker_option - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -tinker_option - : tinker_option_keyword number - { $$ =3D create_attr_dval($1, $2); } - ; - -tinker_option_keyword - : T_Allan - | T_Dispersion - | T_Freq - | T_Huffpuff - | T_Panic - | T_Step - | T_Stepout - | T_Tick - ; - - -/* Miscellaneous Commands - * ---------------------- - */ - -miscellaneous_command - : interface_command - | reset_command - | misc_cmd_dbl_keyword number - { - attr_val *av; - =09 - av =3D create_attr_dval($1, $2); - APPEND_G_FIFO(cfgt.vars, av); - } - | misc_cmd_str_keyword T_String - { - attr_val *av; - =09 - av =3D create_attr_sval($1, $2); - APPEND_G_FIFO(cfgt.vars, av); - } - | misc_cmd_str_lcl_keyword T_String - { - char error_text[64]; - attr_val *av; - - if (input_from_file) { - av =3D create_attr_sval($1, $2); - APPEND_G_FIFO(cfgt.vars, av); - } else { - YYFREE($2); - snprintf(error_text, sizeof(error_text), - "%s remote config ignored", - keyword($1)); - yyerror(ip_file, error_text); - } - } - | T_Includefile T_String command - { - if (!input_from_file) { - yyerror(ip_file, "remote includefile ignored"); - break; - } - if (curr_include_level >=3D MAXINCLUDELEVEL) { - fprintf(stderr, "getconfig: Maximum include file level exceeded.\n")= ; - msyslog(LOG_ERR, "getconfig: Maximum include file level exceeded.");= - } else { - fp[curr_include_level + 1] =3D F_OPEN(FindConfig($2), "r"); - if (fp[curr_include_level + 1] =3D=3D NULL) { - fprintf(stderr, "getconfig: Couldn't open <%s>\n", FindConfig($2));= - msyslog(LOG_ERR, "getconfig: Couldn't open <%s>", FindConfig($2)); - } else { - ip_file =3D fp[++curr_include_level]; - } - } - } - | T_End - { - while (curr_include_level !=3D -1) - FCLOSE(fp[curr_include_level--]); - } - | T_Driftfile drift_parm - { /* see drift_parm below for actions */ } - | T_Logconfig log_config_list - { CONCAT_G_FIFOS(cfgt.logconfig, $2); } - | T_Phone string_list - { CONCAT_G_FIFOS(cfgt.phone, $2); } - | T_Setvar variable_assign - { APPEND_G_FIFO(cfgt.setvar, $2); } - | T_Trap ip_address trap_option_list - { - addr_opts_node *aon; - =09 - aon =3D create_addr_opts_node($2, $3); - APPEND_G_FIFO(cfgt.trap, aon); - } - | T_Ttl integer_list - { CONCAT_G_FIFOS(cfgt.ttl, $2); } - ; - -misc_cmd_dbl_keyword - : T_Broadcastdelay - | T_Nonvolatile - | T_Tick - ; - -misc_cmd_str_keyword - : T_Ident - | T_Leapfile - | T_Pidfile - ; - -misc_cmd_str_lcl_keyword - : T_Logfile - | T_Saveconfigdir - ; - -drift_parm - : T_String - { - attr_val *av; - =09 - av =3D create_attr_sval(T_Driftfile, $1); - APPEND_G_FIFO(cfgt.vars, av); - } - | T_String T_Double - { - attr_val *av; - =09 - av =3D create_attr_sval(T_Driftfile, $1); - APPEND_G_FIFO(cfgt.vars, av); - av =3D create_attr_dval(T_WanderThreshold, $2); - APPEND_G_FIFO(cfgt.vars, av); - } - | /* Null driftfile, indicated by empty string "" */ - { - attr_val *av; - =09 - av =3D create_attr_sval(T_Driftfile, ""); - APPEND_G_FIFO(cfgt.vars, av); - } - ; - -variable_assign - : T_String '=3D' T_String t_default_or_zero - { $$ =3D create_setvar_node($1, $3, $4); } - ; - -t_default_or_zero - : T_Default - | /* empty, no "default" modifier */ - { $$ =3D 0; } - ; - -trap_option_list - : /* empty list */ - { $$ =3D NULL; } - | trap_option_list trap_option - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - ; - -trap_option - : T_Port T_Integer - { $$ =3D create_attr_ival($1, $2); } - | T_Interface ip_address - { - $$ =3D create_attr_sval($1, estrdup($2->address)); - destroy_address_node($2); - } - ; - -log_config_list - : log_config_list log_config_command - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | log_config_command - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -log_config_command - : T_String - { - char prefix; - char * type; - =09 - switch ($1[0]) { - =09 - case '+': - case '-': - case '=3D': - prefix =3D $1[0]; - type =3D $1 + 1; - break; - =09 - default: - prefix =3D '=3D'; - type =3D $1; - }=09 - =09 - $$ =3D create_attr_sval(prefix, estrdup(type)); - YYFREE($1); - } - ; - -interface_command - : interface_nic nic_rule_action nic_rule_class - { - nic_rule_node *nrn; - =09 - nrn =3D create_nic_rule_node($3, NULL, $2); - APPEND_G_FIFO(cfgt.nic_rules, nrn); - } - | interface_nic nic_rule_action T_String - { - nic_rule_node *nrn; - =09 - nrn =3D create_nic_rule_node(0, $3, $2); - APPEND_G_FIFO(cfgt.nic_rules, nrn); - } - ; - -interface_nic - : T_Interface - | T_Nic - ; - -nic_rule_class - : T_All - | T_Ipv4 - | T_Ipv6 - | T_Wildcard - ; - -nic_rule_action - : T_Listen - | T_Ignore - | T_Drop - ; - -reset_command - : T_Reset counter_set_list - { CONCAT_G_FIFOS(cfgt.reset_counters, $2); } - ; - -counter_set_list - : counter_set_list counter_set_keyword - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - | counter_set_keyword - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_int_node($1)); - } - ; - -counter_set_keyword - : T_Allpeers - | T_Auth - | T_Ctl - | T_Io - | T_Mem - | T_Sys - | T_Timer - ; - - - -/* Miscellaneous Rules - * ------------------- - */ - -integer_list - : integer_list T_Integer - { - $$ =3D $1; - APPEND_G_FIFO($$, create_int_node($2)); - } - | T_Integer - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_int_node($1)); - } - ; - -integer_list_range - : integer_list_range integer_list_range_elt - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | integer_list_range_elt - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -integer_list_range_elt - : T_Integer - { $$ =3D create_attr_ival('i', $1); } - | integer_range - ; - -integer_range - : '(' T_Integer T_Ellipsis T_Integer ')' - { $$ =3D create_attr_rangeval('-', $2, $4); } - ; - -string_list - : string_list T_String - { - $$ =3D $1; - APPEND_G_FIFO($$, create_string_node($2)); - } - | T_String - { - $$ =3D NULL; - APPEND_G_FIFO($$, create_string_node($1)); - } - ; - -address_list - : address_list address - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | address - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -boolean - : T_Integer - { - if ($1 !=3D 0 && $1 !=3D 1) { - yyerror(ip_file, "Integer value is not boolean (0 or 1). Assuming 1"= ); - $$ =3D 1; - } else { - $$ =3D $1; - } - } - | T_True { $$ =3D 1; } - | T_False { $$ =3D 0; } - ; - -number - : T_Integer { $$ =3D (double)$1; } - | T_Double - ; - - -/* Simulator Configuration Commands - * -------------------------------- - */ - -simulate_command - : sim_conf_start '{' sim_init_statement_list sim_server_list '}' - { - sim_node *sn; - =09 - sn =3D create_sim_node($3, $4); - APPEND_G_FIFO(cfgt.sim_details, sn); - - /* Revert from ; to \n for end-of-command */ - old_config_style =3D 1; - } - ; - -/* The following is a terrible hack to get the configuration file to - * treat newlines as whitespace characters within the simulation. - * This is needed because newlines are significant in the rest of the - * configuration file. - */ -sim_conf_start - : T_Simulate { old_config_style =3D 0; } - ; - -sim_init_statement_list - : sim_init_statement_list sim_init_statement T_EOC - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_init_statement T_EOC - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_init_statement - : sim_init_keyword '=3D' number - { $$ =3D create_attr_dval($1, $3); } - ; - -sim_init_keyword - : T_Beep_Delay - | T_Sim_Duration - ; - -sim_server_list - : sim_server_list sim_server - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_server - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_server - : sim_server_name '{' sim_server_offset sim_act_list '}' - { $$ =3D ONLY_SIM(create_sim_server($1, $3, $4)); } - ; - -sim_server_offset - : T_Server_Offset '=3D' number T_EOC - { $$ =3D $3; } - ; - -sim_server_name - : T_Server '=3D' address - { $$ =3D $3; } - ; - -sim_act_list - : sim_act_list sim_act - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_act - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_act - : T_Duration '=3D' number '{' sim_act_stmt_list '}' - { $$ =3D ONLY_SIM(create_sim_script_info($3, $5)); } - ; - -sim_act_stmt_list - : sim_act_stmt_list sim_act_stmt T_EOC - { - $$ =3D $1; - APPEND_G_FIFO($$, $2); - } - | sim_act_stmt T_EOC - { - $$ =3D NULL; - APPEND_G_FIFO($$, $1); - } - ; - -sim_act_stmt - : sim_act_keyword '=3D' number - { $$ =3D create_attr_dval($1, $3); } - ; - -sim_act_keyword - : T_Freq_Offset - | T_Wander - | T_Jitter - | T_Prop_Delay - | T_Proc_Delay - ; - -%% - -void=20 -yyerror( - struct FILE_INFO *ip_file, - const char *msg - ) -{ - int retval; - - ip_file->err_line_no =3D ip_file->prev_token_line_no; - ip_file->err_col_no =3D ip_file->prev_token_col_no; -=09 - msyslog(LOG_ERR,=20 - "line %d column %d %s",=20 - ip_file->err_line_no, - ip_file->err_col_no, - msg); - if (!input_from_file) { - /* Save the error message in the correct buffer */ - retval =3D snprintf(remote_config.err_msg + remote_config.err_pos, - MAXLINE - remote_config.err_pos, - "column %d %s", - ip_file->err_col_no, msg); - - /* Increment the value of err_pos */ - if (retval > 0) - remote_config.err_pos +=3D retval; - - /* Increment the number of errors */ - ++remote_config.no_errors; - } -} - - -/* - * token_name - convert T_ token integers to text - * example: token_name(T_Server) returns "T_Server" - */ -const char * -token_name( - int token - ) -{ - return yytname[YYTRANSLATE(token)]; -} - - -/* Initial Testing function -- ignore */ -#if 0 -int main(int argc, char *argv[]) -{ - ip_file =3D FOPEN(argv[1], "r"); - if (!ip_file) - fprintf(stderr, "ERROR!! Could not open file: %s\n", argv[1]); - yyparse(); - return 0; -} -#endif - --------------080502090604030801050601-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 01:26:51 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 1D098746; Fri, 3 Apr 2015 01:26:51 +0000 (UTC) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id AFED85F2; Fri, 3 Apr 2015 01:26:50 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=fFZG4Gi6Ti+n5xNglQHwJrHnRNS8KoVN1SmTF8dh+qI= c=1 sm=1 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=DtyMuQCYAJf2vvIh/Mv8eA==:17 a=6I5d2MoRAAAA:8 a=5n-WxztdAAAA:8 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=OGD07Oae5bG9UwQjw-EA:9 a=CjuIK1q_8ugA:10 a=E8VsCGGvpFHbyNCx:21 a=WjgMOb-_HTQBipj2:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO slippy.cwsent.com) ([24.68.119.200]) by idcmail-mo2no.shaw.ca with ESMTP; 02 Apr 2015 19:26:43 -0600 Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id t331Qgd5006355; Thu, 2 Apr 2015 18:26:42 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id t331Qgk9006352; Thu, 2 Apr 2015 18:26:42 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201504030126.t331Qgk9006352@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Jung-uk Kim Subject: Re: ntpd errors after upgrade on current amd64 In-Reply-To: Message from Jung-uk Kim of "Thu, 02 Apr 2015 16:11:03 -0400." <551DA257.6060100@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Apr 2015 18:26:42 -0700 Cc: Joel Dahl , roberto@FreeBSD.org, freebsd-current@freebsd.org, Xin LI , Cy Schubert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 01:26:51 -0000 In message <551DA257.6060100@FreeBSD.org>, Jung-uk Kim writes: > This is a multi-part message in MIME format. > --------------090800070300040107060309 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 04/01/2015 11:32, Manfred Antar wrote: > > After build install world on current ntpd doesn't work. Here is > > error: > > > > FreeBSD/amd64 (pozo.com) (ttyu0) > > > > login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax > > error > > ntp_crypto.c was not properly merged. Basically, the fix for > SA-14:31.ntp was applied twice. Please try the attached patch. > > > Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 > > for fe80::1%2 fails: Can't assign requested address > > A separate issue, I think. > > Jung-uk Kim > > * Note: ntp_parser.y is redundant and it was the root cause of > inconsistent builds and build failures, i.e., ntp_parser.c and > ntp_parser.h may be regenerated on the *source* directory depending on > phase of the moon. Although we can re-gen them after r280915, > upstream does not support BSD yacc. Ntp_parser.y is not redundant. It is referenced by ntp_parser.c. I put that fix in two days ago. I'll re-merge based on your second patch/the posted fix. I'll try it first in the port though. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 03:21: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 30904415 for ; Fri, 3 Apr 2015 03:21:53 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC2A810 for ; Fri, 3 Apr 2015 03:21:52 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id CE288341F948 for ; Thu, 2 Apr 2015 20:21:51 -0700 (PDT) Message-ID: <551E074E.5090803@mu.org> Date: Thu, 02 Apr 2015 20:21:50 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) References: <201504021353.t32DrKd1075099@fire.js.berklix.net> In-Reply-To: <201504021353.t32DrKd1075099@fire.js.berklix.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 03:21:53 -0000 On 4/2/15 6:53 AM, Julian H. Stacey wrote: > Hans Petter Selasky wrote: >> I hope this is not one more of those April fools :-) > I've been thinking that since Eitan's first post of > Wed, 1 Apr 2015 09:55:11 -0700 (18:55 CEST) > "self-serve commit access" > I kept wondering what would keep looneys out ? :-) > > Your experience feeding back to Linux was interesting, I suppose > we assume "the grass is greener" till we hear someone tried it :-) > Agreed. Contributing to the git project itself was quite eye opening. They are very particular about the patch format and a few processes involved were very long. They also don't use github. That said, the community was pretty open to the patches (once I got the format correct) and it took about average amount of work to get my code submitted. -Alfred From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 07:27:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4580414A; Fri, 3 Apr 2015 07:27:47 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id A0D7E2449; Fri, 3 Apr 2015 07:27:46 +0000 (UTC) Message-ID: <551E40F2.3050907@FreeBSD.org> Date: Fri, 03 Apr 2015 03:27:46 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Cy Schubert Subject: Re: ntpd errors after upgrade on current amd64 References: <201504030126.t331Qgk9006352@slippy.cwsent.com> In-Reply-To: <201504030126.t331Qgk9006352@slippy.cwsent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Cy Schubert , roberto@FreeBSD.org, freebsd-current@freebsd.org, Xin LI , Joel Dahl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 07:27:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/02/2015 21:26, Cy Schubert wrote: > In message <551DA257.6060100@FreeBSD.org>, Jung-uk Kim writes: >> This is a multi-part message in MIME format. >> --------------090800070300040107060309 Content-Type: text/plain; >> charset=utf-8 Content-Transfer-Encoding: 8bit >> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 04/01/2015 11:32, Manfred Antar wrote: >>> After build install world on current ntpd doesn't work. Here >>> is error: >>> >>> FreeBSD/amd64 (pozo.com) (ttyu0) >>> >>> login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 >>> syntax error >> >> ntp_crypto.c was not properly merged. Basically, the fix for >> SA-14:31.ntp was applied twice. Please try the attached patch. >> >>> Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF >>> 0 for fe80::1%2 fails: Can't assign requested address >> >> A separate issue, I think. >> >> Jung-uk Kim >> >> * Note: ntp_parser.y is redundant and it was the root cause of >> inconsistent builds and build failures, i.e., ntp_parser.c and >> ntp_parser.h may be regenerated on the *source* directory >> depending on phase of the moon. Although we can re-gen them >> after r280915, upstream does not support BSD yacc. > > Ntp_parser.y is not redundant. It is redundant because ntp_parser.c and ntp_parser.h are generated from ntp_parser.y. Once it is done, it can be safely removed. Remove it and see for yourself. > It is referenced by ntp_parser.c. Nope. # grep ntp_parser.y /usr/src/contrib/ntp/ntpd/ntp_parser.c #line 14 "ntp_parser.y" /* yacc.c:339 */ #line 54 "ntp_parser.y" /* yacc.c:355 */ #line 371 "ntp_parser.y" /* yacc.c:1646 */ ... # grep ntp_parser.y /usr/src/contrib/ntp/ntpd/ntp_parser.h #line 54 "ntp_parser.y" /* yacc.c:1909 */ These are inserted for debugging purpose only. See yacc(1) for -l optio n. > I put that fix in two days ago. Your "fix" is just to make ntp_parser.y compilable with our yacc(1). Now ntp_parser.c and ntp_parser.h may be regenerated and *overwritten* depending upon timestamps of these files. # svn revert /usr/src/contrib/ntp/ntpd/ntp_parser.[chy] # touch /usr/src/contrib/ntp/ntpd/ntp_parser.y # cd /usr/src/usr.sbin/ntp/ntpd # make depend yacc -d /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntp_parser. y mv y.tab.c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntp_parser.c ... # svn stat /usr/src/contrib/ntp/ntpd/ntp_parser.? M /usr/src/contrib/ntp/ntpd/ntp_parser.c Unfortunately, bundled ntp_parser.c and ntp_parser.h were originally generated with GNU Bison and the new ntp_parser.c is totally different. # svn diff /usr/src/contrib/ntp/ntpd/ntp_parser.c | grep ^+ | wc -l 1918 # svn diff /usr/src/contrib/ntp/ntpd/ntp_parser.c | grep ^- | wc -l 3214. If you really want to keep ntp_parser.y for some reason, ntp_parser.c and ntp_parser.h must be removed from source tree instead. Also, you have to patch /usr/src/usr.sbin/ntp/ntpd/Makefile a little (hint: replace ntp_parser.c with ntp_parser.y for SRCS and add "-I." to CFLAGS) . Basically, you have to remove either ntp_parser.y or ntp_parser.[ch]. You just can't keep them all. > I'll re-merge based on your second patch/the posted fix. I'll try > it first in the port though. Okay. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVHkDoAAoJEHyflib82/FGTVQIAJ6wEudATveKaYSTok9Q5T5K xwE3Ym6XdZqEXprKCSfeIea+EqeWNLmf7uDOsPqr2k0KwwN//sHhXAWR/9ze4+em auypHxM3LTUEYZnoBvy17dOJ1gde/3jXZt9q8ZLnz3M91W439j5jWGGU6LXY97wy Vlv97eqISEMPvI21pA3EI3xC3f56xM6fjruDMAq6VLarAfTaLmhn5fbMpP5XEBBF hybSde+YVf36i/ojKPUYz2mSyJ1y7j+zR0n+S+ccLnGfoS/sXePdoDzjm0lNWVDa bRpkZYbWrVQiGyw+equs6WORKBh0ZIICBaQa0IPGycrD0UKt37wx0YzN7xRDsQo= =tkma -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 08:01: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 3067D65A; Fri, 3 Apr 2015 08:01:37 +0000 (UTC) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::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 E14D418C; Fri, 3 Apr 2015 08:01:36 +0000 (UTC) Received: from roberto-aw.eurocontrol.fr (195-154-243-243.rev.poneytelecom.eu [195.154.243.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 122F952AD; Fri, 3 Apr 2015 10:01:25 +0200 (CEST) Date: Fri, 3 Apr 2015 10:01:19 +0200 From: Ollivier Robert To: Cy Schubert Subject: Re: ntpd errors after upgrade on current amd64 Message-ID: <20150403080118.GA2375@roberto-aw.eurocontrol.fr> References: <551DA257.6060100@FreeBSD.org> <201504030126.t331Qgk9006352@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201504030126.t331Qgk9006352@slippy.cwsent.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Joel Dahl , freebsd-current@freebsd.org, Xin LI , Cy Schubert , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 08:01:37 -0000 According to Cy Schubert on Thu, Apr 02, 2015 at 06:26:42PM -0700: > Ntp_parser.y is not redundant. It is referenced by ntp_parser.c. I put that > fix in two days ago. No, it is the source of ntp_parser.c/h through yacc (or bison) as jkim said. In theory, you have only the .y and during build you generate the .c/.h. In practice, you always use the ntp_parser.c/.h that come pre-built and build with that. As jkim shows, the generated file can be quite different. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 10:40: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 1BC11C09; Fri, 3 Apr 2015 10:40:47 +0000 (UTC) Received: from smtp-out-03.shaw.ca (smtp-out-03.shaw.ca [64.59.136.139]) by mx1.freebsd.org (Postfix) with ESMTP id BAC4A67F; Fri, 3 Apr 2015 10:40:46 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=tLeJwtg1FCvAouMblIYY1Z5/U6XdMrtw4y2B9g+QINc= c=1 sm=1 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=DtyMuQCYAJf2vvIh/Mv8eA==:17 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=8u-t0dKGQeUU_shf9toA:9 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO slippy.cwsent.com) ([24.68.119.200]) by smtp-out-03.shaw.ca with ESMTP; 03 Apr 2015 04:40:39 -0600 Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id t33AecvI076104; Fri, 3 Apr 2015 03:40:38 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id t33AeZhN076101; Fri, 3 Apr 2015 03:40:35 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201504031040.t33AeZhN076101@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Ollivier Robert Subject: Re: ntpd errors after upgrade on current amd64 In-Reply-To: Message from Ollivier Robert of "Fri, 03 Apr 2015 10:01:19 +0200." <20150403080118.GA2375@roberto-aw.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Apr 2015 03:40:35 -0700 Cc: Joel Dahl , freebsd-current@freebsd.org, Xin LI , Cy Schubert , Jung-uk Kim X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 10:40:47 -0000 In message <20150403080118.GA2375@roberto-aw.eurocontrol.fr>, Ollivier Robert w rites: > According to Cy Schubert on Thu, Apr 02, 2015 at 06:26:42PM -0700: > > Ntp_parser.y is not redundant. It is referenced by ntp_parser.c. I put that > > > fix in two days ago. > > No, it is the source of ntp_parser.c/h through yacc (or bison) as jkim said. > > In theory, you have only the .y and during build you generate the .c/.h. In > practice, you always use the ntp_parser.c/.h that come pre-built and build wi > th that. As jkim shows, the generated file can be quite different. The fix has just been committed. 4.2.8p2 should be released shortly to resolve the other issues. I've added an ntp-rc port to track the release candidates. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 13:33: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 AFD2E436 for ; Fri, 3 Apr 2015 13:33:08 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66702A79 for ; Fri, 3 Apr 2015 13:33:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Ye1iW-001AGh-G3>; Fri, 03 Apr 2015 15:33:00 +0200 Received: from x5ce2b0a4.dyn.telefonica.de ([92.226.176.164] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Ye1iW-002UxT-Be>; Fri, 03 Apr 2015 15:33:00 +0200 Date: Fri, 3 Apr 2015 15:32:55 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: pkg-static: sqlite error while executing INSERT OR REPLACE INTO Message-ID: <20150403153255.6d281130.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/NhKZU/4+8fmCLtkSux2hJof"; protocol="application/pgp-signature" X-Originating-IP: 92.226.176.164 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 13:33:08 -0000 --Sig_/NhKZU/4+8fmCLtkSux2hJof Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On a CURRENT system (FreeBSD 11.0-CURRENT #0 r280991: Thu Apr 2 19:01:05 C= EST 2015) with most recent SVN tree revision of /usr/ports (Revision: 383115) I run i= nto a very nasty/sticky problem, which prevents updating/reinstalling/deleting port textproc/clucene, see below. I tried to reinstall/recompile sqlite and all requisite ports, but with no = effect. I maintain my ports in the traditional/flexible FreeBSD style by compiling th= em - not using packages. I also tried to use pkg to install the port in question, see this error ben= eath the error when using portmaster: "portmaster -da" / or "portmaster clucene" [...] =3D=3D=3D>>> Starting check for runtime dependencies =3D=3D=3D>>> Gathering dependency list for textproc/clucene from ports =3D=3D=3D>>> No dependencies for textproc/clucene =3D=3D=3D> Installing for clucene-2.3.3.4_6 =3D=3D=3D> Registering installation for clucene-2.3.3.4_6 Installing clucene-2.3.3.4_6... pkg-static: sqlite error while executing INSERT OR REPLACE INTO packages( o= rigin, name, version, comment, desc, message, arch, maintainer, www, prefix, flatsize, a= utomatic, licenselogic, mtree_id, time, manifestdigest) VALUES( ?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, (SELECT id = FROM mtree WHERE content =3D ?14), NOW(), ?15) in file pkgdb.c:1602: FOREIGN KEY const= raint failed *** Error code 70 Stop. make: stopped in /usr/ports/textproc/clucene root: [ports] pkg install textproc/clucene Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking integrity...Assertion failed: (strcmp(uid, p->uid) !=3D 0), functi= on pkg_conflicts_check_local_path, file pkg_jobs_conflicts.c, line 360. Child = process pid=3D49420 terminated abnormally: Abort trap Can somebody help? Regards, Oliver --Sig_/NhKZU/4+8fmCLtkSux2hJof Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVHpaHAAoJEOgBcD7A/5N8BzIIAKcqoBb6QfutLVfsjeStaDQI QQ3EJ13x1wM2VNWqwINEstAFdX/pmhR2GWINA1pk7BBTg4JuvAs5jh2yUHh3iWEV 8H2LSu3A83lzcxy9GaMNLHIQEmEoCo2P5L/jSc5bPbKXGrpmjiLWvXwqgIpeAfZY aGpC/B5WsNWn5AWocrrUSN5W8DR+ldh9vIIqS7lUluEbJaGvT1A1zcZEWkVpk2TM xqz/tTgmK4ibUxClJ4o2Vo6TimfwZdgw7svVsrFDKIWFwi5jIEkZSSYoU7OWE4g0 M308x88If9cNveYIP3E0I4D433JCJxHWJEX/ZivR1SEZOBUf4pLQf5pLGhsuP7k= =orsH -----END PGP SIGNATURE----- --Sig_/NhKZU/4+8fmCLtkSux2hJof-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 13:32:31 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 833B52A1; Fri, 3 Apr 2015 13:32:31 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4067DA61; Fri, 3 Apr 2015 13:32:31 +0000 (UTC) Received: by qgej70 with SMTP id j70so6757753qge.2; Fri, 03 Apr 2015 06:32:30 -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=PZjyDZaHyndlcAZ7gWeWEQ1hmkRt8cQ9/sHHPrVNHgM=; b=ZJO8BQ7UG3OQXYSsAlx1rx71uF6Br+hhqs2WEV/71cEKvon4i0iqWcvVQG7A7XQwCq xpB9u2ZUeXugUpnk8vQbQ/PrelvAbEVczvoinOYOuEzclSfJsm2oC63NUhtaeOEPbQCk QSaJl8WCXm6S+jJVLZI9PSuYWHEJQqSFQ0xU4ANyBHpUGq5tWgjA3DXhlr0LFg5p2FSs DeMHI0j8JLoTLEnTQc8YNu9w/Tm2c+SEhEI6+loYKwcxoYPd4KBY8R3WVOfV2NwUkDkV mGeSE0xCPtiHLEtc/11HrsPgNZz6LBwyyQElnHEKTPaz0kR7Ube9VxXM1HwkXc0m6sw8 mbIw== MIME-Version: 1.0 X-Received: by 10.140.238.79 with SMTP id j76mr2711236qhc.83.1428067950317; Fri, 03 Apr 2015 06:32:30 -0700 (PDT) Received: by 10.229.200.66 with HTTP; Fri, 3 Apr 2015 06:32:30 -0700 (PDT) In-Reply-To: <20150402183435.GB30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <2ee112c1eb589c7cb08aa1c53680fadd@ultimatedns.net> <20150402183435.GB30115@ivaldir.etoilebsd.net> Date: Fri, 3 Apr 2015 14:32:30 +0100 Message-ID: Subject: Re: [CFT] Call for testing pkg 1.5.0 From: Big Lebowski To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 03 Apr 2015 13:56:45 +0000 Cc: pkg@freebsd.org, "ports@FreeBSD.org Ports" , stable@freebsd.org, current@freebsd.org, Chris H X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 13:32:31 -0000 >> I just wanted to take the time to thank you for all the >> work you've put into this. >> >> Thanks! > > Thanks much appreciated, I want to share that with vsevolod@ and az@ who also > spent a lot of time working on it! > Indeed, HUGE THANKS for what you guys are doing with pkg - I cant wait to see that OS X integration in action (and other things as well), you rock! S. From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 13:35:45 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 48F37652; Fri, 3 Apr 2015 13:35:45 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d: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 016E8AAA; Fri, 3 Apr 2015 13:35:45 +0000 (UTC) Received: by qcbii10 with SMTP id ii10so66549447qcb.2; Fri, 03 Apr 2015 06:35:44 -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=duRQMzT+07L9hdxPjQphgMDWg61TfcbO1Z74fszP6C4=; b=bRIu6Ijyur55MI9uG+BMI3x1owsCSK0PrBVqjgEiSItIpLjVDBjnj0fB2fRa6nxcOs 0zXKsGIBiSR/s17075w9hS8UUvi+VZPqdwSFEi4p++3guZKSSYD2ss8d11U9BptYh9Vf bSDgSzNskDjs2k796Cvez0DP6jI21SPSyUb6TpuRI1Od3T/XlnqTxHPtWV6IICsPrdDJ Pw06Kzof981mCifBwMK9Sn/Rm/JEO1s2t6XsFsnJJ30Gi0e26HLTjqMdI5iBYE5wkFqv UuyfU2F03RfkCDUfFFltbOhAfgbHzlKvhi9tRK43z9DHF6SOvl7Yq5chHwYo2GdTHT31 f2sA== MIME-Version: 1.0 X-Received: by 10.55.49.143 with SMTP id x137mr4382411qkx.72.1428068143988; Fri, 03 Apr 2015 06:35:43 -0700 (PDT) Received: by 10.229.200.66 with HTTP; Fri, 3 Apr 2015 06:35:43 -0700 (PDT) In-Reply-To: <20150331190323.GF30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> Date: Fri, 3 Apr 2015 14:35:43 +0100 Message-ID: Subject: Re: [CFT] Call for testing pkg 1.5.0 From: Big Lebowski To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 03 Apr 2015 13:56:59 +0000 Cc: pkg@freebsd.org, "ports@FreeBSD.org Ports" , stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 13:35:45 -0000 > > Please test and report as much bugs as you can! > We could be very grateful if regressions tests could be provided along with the > bug reports :) > Mine just did something like that: foobar# uname -a FreeBSD foobar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r280994M: Thu Apr 2 20:16:53 CEST 2015 root@pd.valinor.palantiri.org:/usr/obj/usr/src/sys/FOOBAR amd64 foobar [uname -a] ~/ 15-04-03 3:33PM foobar# pkg --version 1.4.99.15 foobar [pkg --version] ~/ 15-04-03 3:33PM foobar# pkg version Child process pid=41119 terminated abnormally: Segmentation fault foobar [pkg version] ~/ 15-04-03 3:33PM foobar# pkg version -t 0.2.o.git20150311 0.2.o.20150402 < foobar [pkg version -t 0.2.o.git20150311 0.2.o.20150402] ~/ 15-04-03 3:33PM pd# From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 14:15: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 02332A87 for ; Fri, 3 Apr 2015 14:15:28 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CC8B6EE2 for ; Fri, 3 Apr 2015 14:15:27 +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 237332222E for ; Fri, 3 Apr 2015 14:15:25 +0000 (UTC) Message-ID: <551EA084.2020702@freebsd.org> Date: Fri, 03 Apr 2015 10:15:32 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CFT] Call for testing pkg 1.5.0 References: <20150331190323.GF30115@ivaldir.etoilebsd.net> <1427829555.3892.7.camel@hardenedbsd.org> <20150331192315.GH30115@ivaldir.etoilebsd.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dmAP7mJ6tWwrjkrwUvttKG5GVnBF6G9Me" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 14:15:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dmAP7mJ6tWwrjkrwUvttKG5GVnBF6G9Me Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-03-31 20:24, Sergei Vyshenski wrote: > Hi, >=20 > On Tue, Mar 31, 2015 at 9:23 PM, Baptiste Daroussin > wrote: >=20 >> Add WITH_PKG=3Ddevel in your build make.conf >> then pkg upgrade will want you to upgrade to 1.4.99.16 (which is pkg 1= =2E5.0 >> beta1) >> >=20 > This does not work for me. >=20 > # cat /etc/make.conf |grep PKG > WITH_PKGNG=3Dyes > WITH_PKG=3Ddevel >=20 > # pkg upgrade > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > Checking for upgrades (218 candidates): 100% > Processing candidates (218 candidates): 100% > Checking integrity... done (0 conflicting) > Your packages are up to date. >=20 > # pkg -v > 1.4.12 >=20 > # pkg info |grep pkg > pkg-1.4.12 Package manager >=20 > Instead, the following succeded: > # cd /usr/ports/ports-mgmt/pkg-devel > # make reinstall > ... > # pkg -v > 1.4.99.16 >=20 > All the best, Sergei > _______________________________________________ > 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" >=20 Baptiste meant that setting WITH_PKG=3Ddevel in the make.conf of a poudriere would make it compiled pkg 1.4.99.x and make all users using your repo use that. You'd have to run poudriere to make it rebuild everything with that new make.conf first, before 'pkg upgrade' would upgrade you to 1.4.99.x --=20 Allan Jude --dmAP7mJ6tWwrjkrwUvttKG5GVnBF6G9Me 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) iQIcBAEBAgAGBQJVHqCHAAoJEJrBFpNRJZKfzoYQAKXmTfHfLGbG2z18lauhrgvw r72tYwVxhzYOPUyJI8WblSu8uwf03gv6lUar57TTsmEwhJgcf9INSyVe0uHfuYuZ TlbnQAQl5ByqigjN8XfasMggqnM7AraEQThpvyGOVpUb83KhT9pEylKQxjLyJIjh CbGRgaityplLv8v/xZsXKGOY56JFfwlisl4/ECPhf6vU+q9pagSQsS7dCiXE0gca jwzoNSXRESa7GIJlzmk1+gHuDu7ESInprd9Ed2kBP0pKnJ4effpINqTAXiUqpHVE ufEBQloFW9kliJfi8DX03mEQZ9emRaNpN2JNA0930pqq+zl8qwdFwGRy4vpqIfBy NCrdzmcz42nZA+iYkC+8xAqEjq18fkgW1EBKfVQ2+oNr5NMWzpdvhvYbboEhoVIu dw8njWh26DyQO2jQnlRi7tmakcBjm6OmZ7v663cG9NAH2esaCsaSxk3Nqhv4VA1l LjJYHNaXIEi65tFqnXqXJb5PZdgkYpJP3Yp92B6VfdCpYZrhuYt+EQKFD9Nnnwza 03iEQRD+hF7n2D3/pSxVEqvp3dQaGMJqGnCJ0KZpGnBfAbNbnuBJ4ahsUJQZFF8b rYEwkc8QR0lMPRSzvoUJOIcUgo5rkJxh6LYyt58d03hbQ/OyRfPXgb0wftcM0CXV 38SLjO4Zc9MOpCiGpN44 =9d8B -----END PGP SIGNATURE----- --dmAP7mJ6tWwrjkrwUvttKG5GVnBF6G9Me-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 14:34:40 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 9C042EEF; Fri, 3 Apr 2015 14:34:40 +0000 (UTC) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 4E8FF118; Fri, 3 Apr 2015 14:34:40 +0000 (UTC) Received: by ykeg184 with SMTP id g184so29640141yke.2; Fri, 03 Apr 2015 07:34:39 -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=Zuqs+D0vkczQTXh1i7YLEiBBmuLHAxjYyUVJl99hXBY=; b=KuiftkJNgo/z/ezC42yjo8zTi6i8H5zsVd2uDyMd7s/RDJUygF3q1TwDtxiiQhbbn+ zaoeAA5buFgVqKizqTeOGN4f7i7H8ZavcuZeiGnQzYQR6f1HzysrJb0+2uo8VYLs74mO 8P7ySCIMxu8CkcFZ8Z9+DJNy5lS1/umCNfOKEhgrLdy8y9yy/r8BO3Vfg9JMkbRIxjMb qprTb2YSfUxK39hcBOG4gA7f1epA0PDcMH4NoFsnwRhH2RrweQn2iT9tSQm4S+BCapN1 b7OnQjABp5PQd0BILsDYxKY6cYK6k4yfZUO45Pg//KugPqXjyLDDJa53T+o+IDF8ZEEt s42Q== X-Received: by 10.52.243.41 with SMTP id wv9mr1504131vdc.20.1428071679382; Fri, 03 Apr 2015 07:34:39 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id yr19sm1346719vdc.8.2015.04.03.07.34.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2015 07:34:37 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 3 Apr 2015 16:34:33 +0200 From: Baptiste Daroussin To: Big Lebowski Subject: Re: [CFT] Call for testing pkg 1.5.0 Message-ID: <20150403143433.GJ30115@ivaldir.etoilebsd.net> References: <20150331190323.GF30115@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ohWw6IXhY39HKnGA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: pkg@freebsd.org, "ports@FreeBSD.org Ports" , stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Apr 2015 14:34:40 -0000 --ohWw6IXhY39HKnGA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 03, 2015 at 02:35:43PM +0100, Big Lebowski wrote: > > > > Please test and report as much bugs as you can! > > We could be very grateful if regressions tests could be provided along = with the > > bug reports :) > > >=20 > Mine just did something like that: >=20 > foobar# uname -a > FreeBSD foobar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r280994M: Thu > Apr 2 20:16:53 CEST 2015 > root@pd.valinor.palantiri.org:/usr/obj/usr/src/sys/FOOBAR amd64 > foobar [uname -a] ~/ > 15-04-03 > 3:33PM > foobar# pkg --version > 1.4.99.15 > foobar [pkg --version] ~/ > 15-04-03 > 3:33PM > foobar# pkg version > Child process pid=3D41119 terminated abnormally: Segmentation fault > foobar [pkg version] ~/ > 15-04-03 > 3:33PM > foobar# pkg version -t 0.2.o.git20150311 0.2.o.20150402 > < > foobar [pkg version -t 0.2.o.git20150311 0.2.o.20150402] ~/ > 15-04-03 > 3:33PM > pd# Let me fix that :) Best regards, Bapt --ohWw6IXhY39HKnGA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUepPkACgkQ8kTtMUmk6EwSpwCdGFKpk1xhzMoKLCy6elFTDM4P cvEAnjwvWkUzrx6DXoczN0ZocpVFbiIj =rktF -----END PGP SIGNATURE----- --ohWw6IXhY39HKnGA-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 3 17:06:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14FFD3E6 for ; Fri, 3 Apr 2015 17:06:40 +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 D7E0F659 for ; Fri, 3 Apr 2015 17:06:39 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-255-201.lns20.per4.internode.on.net [121.45.255.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t33H6ZLQ036576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 3 Apr 2015 10:06:38 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <551EC895.7000700@freebsd.org> Date: Sat, 04 Apr 2015 01:06:29 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Bazaaring the cathedral (Lowering the Barrier to Entry) References: <551D05DE.3070200@selasky.org> <551D19E6.8080405@selasky.org> In-Reply-To: <551D19E6.8080405@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.18-1 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, 03 Apr 2015 17:06:40 -0000 On 4/2/15 6:28 PM, Hans Petter Selasky wrote: > I hope this is not one more of those April fools :-) yep > > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Apr 4 00:51: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 D8247428; Sat, 4 Apr 2015 00:51:41 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::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 5B42EAF2; Sat, 4 Apr 2015 00:51:41 +0000 (UTC) Received: by lahf3 with SMTP id f3so87445767lah.2; Fri, 03 Apr 2015 17:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=RzL6vaoe6hchJMlTDkzetb29lFdW4SpopxIDG/3UjDA=; b=jDUcVZ1m9orp0sZtX56YLgpqIUw0l3BFfL4MX/Z9IYAUnmLrr20Sd7D9lOAvv8NbbT 9jI9CnC/Cu8RKODMp4D1vGx9yJS1Yse3QFPoprRKPGJ6YoyT4zQJUh9ezhmGlCqTRUdD BaUp7lpMGb6wrWHMTpyjVYj+9IMCr0Vtl/1MSle4IAG7V9lup3127Zi1H3e8nP1z9Cof lxqYbv7J3l7aTLkF0Kh6uv7nilw8T6LCu0O/jOqpwZrnrhCVtErymQQ1aSzHVjekVqIo pj9zwcU17hRH32lCKtym+SY3qnnqha7e9TW3rS/lQqGSHeZFL5N7jE8ATXPGFaePfHdA PQ6w== MIME-Version: 1.0 X-Received: by 10.112.50.38 with SMTP id z6mr4261404lbn.122.1428108699334; Fri, 03 Apr 2015 17:51:39 -0700 (PDT) Received: by 10.112.140.69 with HTTP; Fri, 3 Apr 2015 17:51:39 -0700 (PDT) Date: Fri, 3 Apr 2015 21:51:39 -0300 Message-ID: Subject: FreeBSD 11 is "kernel panic"ing when a vbox' machine stops (or starts if package version) From: Vinicius Abrahao To: freebsd-emulation@freebsd.org, vbox@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Apr 2015 00:51:42 -0000 Guys, I am testing some things in this environment. So i am happy to announce that I find something that you may like: I am using FreeBSD 11 as a host [r280928:GENERIC amd64 ]. So in '-current' Installed on it virtualbox 4.3.26 and tried to run a linux guest as the virtual machine. So, what is the trouble? 1) when I installed vbox from 'pkg install', the HOST machine exits by KERNEL PANIC at the exactly time that I 'power up' the guest machine. 2) when I installed vbox from 'make install', the HOST machine exits by KERNEL PANIC at the exactly time that I 'power down' the guest machine. Here is the crash.txt that I dumped at the kernel panic prompt. https://gist.github.com/vinnix/819c210986da439136ef Obs.: all these tests are reproducible here in my environment. and all times that i did the test, i also rebuild the kmod and reboot the machine. thank you in advance for your time, best regards, --=20 Vin=C3=ADcius Abrah=C3=A3o Bazana Schmidt [vinnix]=E2=84=A2 aka: Vin=C3=ADcius Abrah=C3=A3o Bazana Schmidt vischmidt.wordpress.com twitter.com/vischmidt