From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 07:03:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B57AE482; Sun, 7 Sep 2014 07:03:33 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 6FA061B1A; Sun, 7 Sep 2014 07:03:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XQWVX-002nIf-7C>; Sun, 07 Sep 2014 09:03:31 +0200 Received: from g225191163.adsl.alicedsl.de ([92.225.191.163] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XQWVX-000ozV-56>; Sun, 07 Sep 2014 09:03:31 +0200 Date: Sun, 7 Sep 2014 09:03:21 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD Ports Subject: service doen't get started at boottime, but can start manually Message-ID: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/vz.hDHtedE63rUYwGb1uV_G"; protocol="application/pgp-signature" X-Originating-IP: 92.225.191.163 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: Sun, 07 Sep 2014 07:03:33 -0000 --Sig_/vz.hDHtedE63rUYwGb1uV_G Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I use a service (textprox/refdb from ports, refdb_enable=3D"YES" in /etc/rc= .conf.local) that is supposed to startup at boottime. On one CURRENT system, running FreeBSD 11.0-CURRENT #3 r271210: Sat Sep 6 22:39:59 CEST 2014 amd64 the service is not started at boottime, but I can start the service manuall= y via service refdb start I tried enabling rc_debug=3DYES in /etc/rc.conf but I do not see any failur= e of the start attempt of that specific service in the logs or on the console.=20 Is there an elegant way to debug rc.d and the startup procedure without hav= ing the system reboot (I do not have jails or VM, sorry)? oh --Sig_/vz.hDHtedE63rUYwGb1uV_G Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUDANCAAoJEOgBcD7A/5N8dx8IALcg6eLn0rclq3essnBWQ9VB TuE/5lakXPOsKxXnHkRSvU1+yh3KIaWkrPJjVbL7SIIiI2cvoAHfgcIEaabHU/te Iu0gB7q5Am2w8q/9kXDDSAAGNeOVGkTSJGVcXpvKSocDliZnVEji9CNexLwKWV3P j80X8liUETsXtUNwaT4TIen149j+F0NYCwE6EjADQnGXInVgUZM/APWgHJo6uPMc Ngw4/Zf7TlaXN04aK5G9wdsWg24eJoez32uBReZ/gEW4IzmEZrDEuZRp9YuOiwYM ZmWJKE+Bp3uoRkvU+me3ope1tngOWQThTJUf6rboZ2uKrGWy0v6u/XqxfgeC64k= =NRNT -----END PGP SIGNATURE----- --Sig_/vz.hDHtedE63rUYwGb1uV_G-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 07:43:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A5DCEE5; Sun, 7 Sep 2014 07:43:15 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 218731E27; Sun, 7 Sep 2014 07:43:14 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XQX7x-002uIH-9s>; Sun, 07 Sep 2014 09:43:13 +0200 Received: from g226177160.adsl.alicedsl.de ([92.226.177.160] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XQX7x-000sVV-66>; Sun, 07 Sep 2014 09:43:13 +0200 Date: Sun, 7 Sep 2014 09:43:08 +0200 From: "O. Hartmann" To: Erich Dollansky Subject: Re: service doen't get started at boottime, but can start manually Message-ID: <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140907153342.2366ad8b@X220.alogt.com> References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/aElRYB/xA1rFHRA3VWWg0s_"; protocol="application/pgp-signature" X-Originating-IP: 92.226.177.160 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , FreeBSD Ports 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, 07 Sep 2014 07:43:15 -0000 --Sig_/aElRYB/xA1rFHRA3VWWg0s_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 7 Sep 2014 15:33:42 +0800 Erich Dollansky schrieb: > Hi, >=20 > On Sun, 7 Sep 2014 09:03:21 +0200 > "O. Hartmann" wrote: >=20 > >=20 > > I use a service (textprox/refdb from ports, refdb_enable=3D"YES" > > in /etc/rc.conf.local) that is supposed to startup at boottime. On > > one CURRENT system, running > >=20 > > FreeBSD 11.0-CURRENT #3 r271210: Sat Sep 6 22:39:59 CEST 2014 amd64 > >=20 > > the service is not started at boottime, but I can start the service > > manually via > >=20 > > service refdb start > >=20 > > I tried enabling rc_debug=3DYES in /etc/rc.conf but I do not see any > > failure of the start attempt of that specific service in the logs or > > on the console.=20 > >=20 > > Is there an elegant way to debug rc.d and the startup procedure > > without having the system reboot (I do not have jails or VM, sorry)? > >=20 > could it be that the spelling in either rc.conf and the spelling in the > actual script differ so that FreeBSD does not start it? >=20 > Erich No. If it would be the case, I guess starting it manually wouldn't work eit= her. The fact is that the port textproc/refdb uses a startup script named "refdb.sh" and = by maintaining the port and on the way to make it more CURRENT compliant, I started with r= enaming it to "refdb" and it seems this is the culprit. The script textproc/refdb uses is a bit awkward since it targets both *BSD = and Linux init/rc scripts and the initial rc.d/refddb scripts gives control to anothe= r script called refdbctl which seems to perform all the stuff FreeBSD's /etc/rc.subr= is providing. I renamed the script back to "refdb.sh" by now and the service starts again= as expected. I guess the spawning into a subshell fails somehow at that point= when booting the box. Oliver=20 --Sig_/aElRYB/xA1rFHRA3VWWg0s_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUDAyQAAoJEOgBcD7A/5N8P64H/0ZC3REJHXrlgjpMIOZmr/qb CgRFAKNfk81aBKjh4TRU9uwQKYMjTwIPSI18XrNN8+vZrrIsMbzZvZHJbbuO9aMp q0I6EYTvgOpLIZf1RtQZU+jY1gJktnr6RspRJAgzSGDMbFGmkyxLnQ37UTj9xLPm CdAYac7geZUL1vtzgUgnpO0AoSSitxNz9xAmwB40Zs/RCcXHzgVjUyVdoeMRGVsA fAR4+WFaFa82vUrBOBu14f90aDHOYAyVmr7+Wr+8as3HjoGQX6k30gSs3U5qQKDn e0v+cBHrSz69RrF+F1UOpNMdyn5mMYzXWmT0+sFyR68EUXJWVLUatnaPNAYvw6M= =od7S -----END PGP SIGNATURE----- --Sig_/aElRYB/xA1rFHRA3VWWg0s_-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 08:39:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 925E4396; Sun, 7 Sep 2014 08:39:25 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57DD21376; Sun, 7 Sep 2014 08:39:25 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id rd18so16421014iec.27 for ; Sun, 07 Sep 2014 01:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K42ay01j0gpFXL4XrvoGVlL4oHdrKgTuW6sCTD/Lj4A=; b=VX7MGTNzlu5nXJpPfASB9REhAo2ADUC6onUhzj1tb3+sJIKn+D50qjiCLdgflL1drT apqDINVr2rp4KaBuIbCetaX1RiMBpg7SZOweC/03QXDFlAvha1nwZbPRY0Jn39wHMj2x 0KqXysqTPLN9an2URx2mA2NJb2WDJJpsoAioAPLRKB/nYyBxzUCrmogqo4jqsX5MFojB cBiDX45TH/gX1lD2eeFcXf4QtEeSA6zs8LCCUggEXj0+rXy2YCin15Hpgl+stowpa9PT X/HAA/PvMfxDIyByzYphqJYzuCh8/A7AsE7fp6VHAGsJWpCU07dgkluH13/OJxhY5BBV O+xw== MIME-Version: 1.0 X-Received: by 10.43.96.8 with SMTP id ce8mr19387909icc.14.1410079164723; Sun, 07 Sep 2014 01:39:24 -0700 (PDT) Received: by 10.50.122.42 with HTTP; Sun, 7 Sep 2014 01:39:24 -0700 (PDT) In-Reply-To: <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> Date: Sun, 7 Sep 2014 03:39:24 -0500 Message-ID: Subject: Re: service doen't get started at boottime, but can start manually From: Scot Hetzel To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , FreeBSD Ports , Erich Dollansky 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, 07 Sep 2014 08:39:25 -0000 On Sun, Sep 7, 2014 at 2:43 AM, O. Hartmann wrote: > Am Sun, 7 Sep 2014 15:33:42 +0800 > Erich Dollansky schrieb: > >> Hi, >> >> On Sun, 7 Sep 2014 09:03:21 +0200 >> "O. Hartmann" wrote: >> >> > >> > I use a service (textprox/refdb from ports, refdb_enable="YES" >> > in /etc/rc.conf.local) that is supposed to startup at boottime. On >> > one CURRENT system, running >> > >> > FreeBSD 11.0-CURRENT #3 r271210: Sat Sep 6 22:39:59 CEST 2014 amd64 >> > >> > the service is not started at boottime, but I can start the service >> > manually via >> > >> > service refdb start >> > >> > I tried enabling rc_debug=YES in /etc/rc.conf but I do not see any >> > failure of the start attempt of that specific service in the logs or >> > on the console. >> > >> > Is there an elegant way to debug rc.d and the startup procedure >> > without having the system reboot (I do not have jails or VM, sorry)? >> > >> could it be that the spelling in either rc.conf and the spelling in the >> actual script differ so that FreeBSD does not start it? >> >> Erich > > No. If it would be the case, I guess starting it manually wouldn't work either. The fact > is that the port textproc/refdb uses a startup script named "refdb.sh" and by maintaining > the port and on the way to make it more CURRENT compliant, I started with renaming it to > "refdb" and it seems this is the culprit. > > The script textproc/refdb uses is a bit awkward since it targets both *BSD and Linux > init/rc scripts and the initial rc.d/refddb scripts gives control to another script > called refdbctl which seems to perform all the stuff FreeBSD's /etc/rc.subr is providing. > > I renamed the script back to "refdb.sh" by now and the service starts again as > expected. I guess the spawning into a subshell fails somehow at that point when booting > the box. > I had a look at scripts/refdb.in, it is not a proper rc script for FreeBSD, as it is missing several keywords: # PROVIDE: <- all scripts need this # REQUIRE: # BEFORE: # KEYWORD: <- optional Which tells rcorder where to put refdb in the startup order. Since these are missing, rcorder doesn't place it in the startup list. The following will show you the order that your startup scripts run, refdb may not be listed: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* Some one will have to create a proper rc script by looking at what both scripts/refdb.in and scripts/refdbctl.in do. The reason that you are able to use service to start refdb, is due to service doesn't check the scripts header for the keywords. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 09:03:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CB0E8A8; Sun, 7 Sep 2014 09:03:27 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D49711752; Sun, 7 Sep 2014 09:03:26 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id a13so1372656igq.15 for ; Sun, 07 Sep 2014 02:03:26 -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=u8iA3YJLTESzRYZTO/x1m1Z68BlfjUP0Bb/IAAMmQ2M=; b=MOqYw8y4bq/zBoY+E38SCRRAn8Bz5pbAubCI/KxfGPgmL0DHyPD5QKw1vvzicHrB8s l9LmwF07JA79hbzOM6RJW0xJxwam+TLCK9cNpMmX8+pBeQA+acymYhphpNPCeDJfiAEf xvQEdK9jqCrVgcMSYdKn9kPsU3FxECfQDuP+jaQqvPuBQ8E5F2Sd/KNiwm/jUCILIFSL jOeGjy84O4itMPlp/aI+ywIsKSZVYzrVwjneT27jxTKw0gz8R24X1wbdORTfOO0sXwYP v9G1kAe4CqPmtKAXKlzGRU0ydi2svkMRaohrsMa4oJQDosRXoSMeHs6H1j5dKx58EEtf I6xQ== MIME-Version: 1.0 X-Received: by 10.42.82.6 with SMTP id b6mr24616662icl.51.1410080605990; Sun, 07 Sep 2014 02:03:25 -0700 (PDT) Received: by 10.50.122.42 with HTTP; Sun, 7 Sep 2014 02:03:25 -0700 (PDT) In-Reply-To: References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> Date: Sun, 7 Sep 2014 04:03:25 -0500 Message-ID: Subject: Re: service doen't get started at boottime, but can start manually From: Scot Hetzel To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , FreeBSD Ports , Erich Dollansky 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, 07 Sep 2014 09:03:27 -0000 On Sun, Sep 7, 2014 at 3:39 AM, Scot Hetzel wrote: > I had a look at scripts/refdb.in, it is not a proper rc script for > FreeBSD, as it is missing several keywords: > > # PROVIDE: <- all scripts need this > # REQUIRE: > # BEFORE: > # KEYWORD: <- optional > > Which tells rcorder where to put refdb in the startup order. Since > these are missing, rcorder doesn't place it in the startup list. > I looked again, and it is not rcorder, it's /etc/rc and /etc/rc.subr that determine which script to run. /etc/rc calls find_local_scripts_new from /etc/rc.subr. find_local_scripts_new checks each rc script to make sure that they have at least a "# PROVIDE: " keyword. If it does, then it adds that script to ${local_rc}. Then /etc/rc runs: files=`rcorder /etc/rc.d/* ${local_rc}` to get the startup order for these scripts. Then /etc/rc starts the scripts in the proper order. Since, /usr/local/etc/rc.d/refdb{,.sh.dist} is missing the "# PROVIDE: ", the script is skipped on startup. Since, rc.d/refdb is not a proper rc script, adding refdb_enable=YES to /etc/rc.conf{,.local} will not control the starting of this script. Someone should fix service, so that it checks the rc script has a "# PROVIDE: ", and displays an error message if it doesn't. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 09:28:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DC0BD27; Sun, 7 Sep 2014 09:28:16 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A6F6218D6; Sun, 7 Sep 2014 09:28:15 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XQYlY-003BRU-Sh>; Sun, 07 Sep 2014 11:28:12 +0200 Received: from g226177160.adsl.alicedsl.de ([92.226.177.160] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XQYlY-0010Px-Ok>; Sun, 07 Sep 2014 11:28:12 +0200 Date: Sun, 7 Sep 2014 11:28:11 +0200 From: "O. Hartmann" To: Scot Hetzel Subject: Re: service doen't get started at boottime, but can start manually Message-ID: <20140907112811.5570fc85.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Ojp/xHrD0bzl6YWtKo1LaOY"; protocol="application/pgp-signature" X-Originating-IP: 92.226.177.160 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , FreeBSD Ports , Erich Dollansky 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, 07 Sep 2014 09:28:16 -0000 --Sig_/Ojp/xHrD0bzl6YWtKo1LaOY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 7 Sep 2014 04:03:25 -0500 Scot Hetzel schrieb: > On Sun, Sep 7, 2014 at 3:39 AM, Scot Hetzel wrote: > > I had a look at scripts/refdb.in, it is not a proper rc script for > > FreeBSD, as it is missing several keywords: > > > > # PROVIDE: <- all scripts need this > > # REQUIRE: > > # BEFORE: > > # KEYWORD: <- optional > > > > Which tells rcorder where to put refdb in the startup order. Since > > these are missing, rcorder doesn't place it in the startup list. > > > I looked again, and it is not rcorder, it's /etc/rc and /etc/rc.subr > that determine which script to run. >=20 > /etc/rc calls find_local_scripts_new from /etc/rc.subr. > find_local_scripts_new checks each rc script to make sure that they > have at least a "# PROVIDE: " keyword. If it does, then it adds that > script to ${local_rc}. Then /etc/rc runs: >=20 > files=3D`rcorder /etc/rc.d/* ${local_rc}` >=20 > to get the startup order for these scripts. Then /etc/rc starts the > scripts in the proper order. >=20 > Since, /usr/local/etc/rc.d/refdb{,.sh.dist} is missing the "# PROVIDE: > ", the script is skipped on startup. >=20 > Since, rc.d/refdb is not a proper rc script, adding refdb_enable=3DYES > to /etc/rc.conf{,.local} will not control the starting of this script. >=20 > Someone should fix service, so that it checks the rc script has a "# > PROVIDE: ", and displays an error message if it doesn't. Hello Scott, as the new maintainer of this port, I'm working on a solution, but first, I= have to understand the way this obscure rc-script system works. Thanks for your goo= d explanation. I tried to put PROVIDE/REQUIRE in the script, but I also changed refdb.sh -= > refdb which, in the end, didn't work. The service IS started with refdb.sh in rc.= d/.=20 Since the original refdb.sh init script targets both Linux and *BSD and del= egates the starting, stopping et cetera to a script called refdbctl, the latter script= needs to be examinded and as far as I understand, most of its functionality is covered by /etc/rc.cubr, except the part where refdbctl searches for the path of th= e PID file and replaces the init/default path its configuration counterpart found in /etc/refdb/refdbdrc. I guess, at the end FreeBSD doen't need the templated refdbctl/refdb.in (to= be found in the sources in scripts/). If you'd like to have a look at it, I can send you the sekelton I've alread= y prepared for the refurbishment of the port. Oliver --Sig_/Ojp/xHrD0bzl6YWtKo1LaOY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUDCUsAAoJEOgBcD7A/5N8nckH/A8VZt5HQq58Bh7+lY01rs47 2/7jBCn8N9hKerIeqygYRTODHn+OD2IWStm0tdESF5wrrl8U754rgPoa7G2gqQvV 8Bsw3F4c1ZpEzDni1MZs3c0lmUNcPY34DZjm4Cs9Jur5hgWm4qdpTZNBt992tXdS PIiqmKVS2whgSU/wFiXD+qEVnNhyEFmyfCAZS5sZ10SN+Wy/bLXXIhbnJUaxkz7T nImNMoHvW8NAEqjA00yf1Vz1vMuOtYQojL0nCdPs2AsWkAYa4GdNli7BO/o0isq3 6Op39Zz6/XIbO7oYO3XTuBpm6qjpGNtMoKmyQ5ywZu1fDC6B1HEKVa2FDd1bjag= =Gq/G -----END PGP SIGNATURE----- --Sig_/Ojp/xHrD0bzl6YWtKo1LaOY-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 13:02:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60C1C3DD for ; Sun, 7 Sep 2014 13:02:31 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 B2C141D64 for ; Sun, 7 Sep 2014 13:02:29 +0000 (UTC) Received: from [87.79.252.204] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1XQc6k-0003XZ-Vt for freebsd-current@freebsd.org; Sun, 07 Sep 2014 15:02:19 +0200 Date: Sun, 7 Sep 2014 15:02:19 +0200 From: Fabian Keil To: FreeBSD Current Subject: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock Message-ID: <492dbacb.5942cc9b@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/RF=29s9FFtRhTIQX5d+=r1I"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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, 07 Sep 2014 13:02:31 -0000 --Sig_/RF=29s9FFtRhTIQX5d+=r1I Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the following panic yesterday: [...] Unread portion of the kernel message buffer: [6880] panic: deadlkres: possible deadlock detected for 0xfffff80015289490,= blocked for 1800503 ticks [6880]=20 [6880] cpuid =3D 1 [6880] KDB: stack backtrace: [6880] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe= 009432e9e0 [6880] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe009432ea90 [6880] panic() at panic+0x1c1/frame 0xfffffe009432eb50 [6880] deadlkres() at deadlkres+0x588/frame 0xfffffe009432ebb0 [6880] fork_exit() at fork_exit+0x9a/frame 0xfffffe009432ebf0 [6880] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe009432ebf0 [6880] --- trap 0, rip =3D 0, rsp =3D 0xfffffe009432ecb0, rbp =3D 0 --- [6880] KDB: enter: panic [6880] Uptime: 1h54m40s [6880] Dumping 354 out of 1973 MB:..5%..14%..23%..32%..41%..55%..64%..73%..= 82%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. [...] Loaded symbols for /boot/kernel/profile.ko.symbols #0 doadump (textdump=3D1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=3D1) at pcpu.h:219 #1 0xffffffff80597bad in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:447 #2 0xffffffff80598100 in panic (fmt=3D) at /usr/src/s= ys/kern/kern_shutdown.c:746 #3 0xffffffff80539b98 in deadlkres () at /usr/src/sys/kern/kern_clock.c:240 #4 0xffffffff8055e8da in fork_exit (callout=3D0xffffffff80539610 , arg=3D0x0, frame=3D0xfffffe009432ec00) at /usr/src/sys/kern/kern_fork.c= :977 #5 0xffffffff8083fb5e in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:605 #6 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) set $td=3D(struct thread *)0xfffff80015289490 (kgdb) tid $td->td_tid [Switching to thread 1184 (Thread 101428)]#0 sched_switch (td=3D0xfffff800= 15289490, newtd=3D, flags=3D) at = /usr/src/sys/kern/sched_ule.c:1932 1932 cpuid =3D PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=3D0xfffff80015289490, newtd=3D, f= lags=3D) at /usr/src/sys/kern/sched_ule.c:1932 #1 0xffffffff805a23c1 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/= sys/kern/kern_synch.c:493 #2 0xffffffff805e4bca in sleepq_wait (wchan=3D0x0, pri=3D0) at /usr/src/sy= s/kern/subr_sleepqueue.c:631 #3 0xffffffff805a12b2 in _sx_xlock_hard (sx=3D0xfffff800062ed820, tid=3D18= 446735277971510416, opts=3D, file=3D0x0, line=3D0) at = /usr/src/sys/kern/kern_sx.c:676 #4 0xffffffff805a0add in _sx_xlock (sx=3D0x0, opts=3D0, file=3D, line=3D0) at sx.h:154 #5 0xffffffff8114a691 in spa_get_errlog_size (spa=3D0xfffff800062ed000) at= /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:142 #6 0xffffffff8113f549 in spa_get_stats (name=3D0xfffffe0006126000 "spacelo= op", config=3D0xfffffe00950e58e8, altroot=3D0xfffffe0006126430 "", buflen= =3D2048) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 #7 0xffffffff81189a45 in zfs_ioc_pool_stats (zc=3D0xfffffe0006126000) at /= usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656 #8 0xffffffff81187290 in zfsdev_ioctl (dev=3D, zcmd= =3D, arg=3D, flag=3D, td=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:= 6136 #9 0xffffffff80464a55 in devfs_ioctl_f (fp=3D0xfffff80017107f50, com=3D322= 2821381, data=3D0xfffff8004fb4b740, cred=3D, td=3D0xff= fff80015289490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #10 0xffffffff805f3c3d in kern_ioctl (td=3D0xfffff80015289490, fd=3D, com=3D0) at file.h:311 #11 0xffffffff805f381c in sys_ioctl (td=3D0xfffff80015289490, uap=3D0xfffff= e00950e5b80) at /usr/src/sys/kern/sys_generic.c:702 #12 0xffffffff8085c2db in amd64_syscall (td=3D0xfffff80015289490, traced=3D= 0) at subr_syscall.c:133 #13 0xffffffff8083f90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:390 #14 0x00000008019fc3da in ?? () (kgdb) f 3 #3 0xffffffff805a12b2 in _sx_xlock_hard (sx=3D0xfffff800062ed820, tid=3D18= 446735277971510416, opts=3D, file=3D0x0, line=3D0) at = /usr/src/sys/kern/kern_sx.c:676 676 sleepq_wait(&sx->lock_object, 0); (kgdb) p sx->lock_object $14 =3D {lo_name =3D 0xffffffff81202163 "spa->spa_errlog_lock", lo_flags = =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0} This happened several minutes after a couple of zpool processes stopped responding while accessing information about the following pool: fk@r500 ~ $zpool status -v spaceloop pool: spaceloop state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub repaired 2.98M in 16h27m with 0 errors on Sun Sep 7 12:25:36= 2014 config: NAME STATE READ WRITE CKSUM spaceloop ONLINE 0 0 0 label/spaceloop.eli ONLINE 0 0 26 errors: No known data errors Dump time was 21:58:48, the vdev disappeared a while before that, therefore I believe the "possible" deadlock is a real one: Sep 6 21:18:09 r500 kernel: [4441] GEOM_ELI: g_eli_write_done() failed (er= ror=3D5) label/spaceloop.eli[WRITE(offset=3D2235700736, length=3D16384)] Sep 6 21:18:09 r500 kernel: [4441] GEOM_ELI: g_eli_read_done() failed (err= or=3D5) label/spaceloop.eli[READ(offset=3D4008976384, length=3D8192)] Sep 6 21:18:09 r500 kernel: [4441] GEOM_ELI: g_eli_read_done() failed (err= or=3D5) label/spaceloop.eli[READ(offset=3D4009238528, length=3D8192)] Sep 6 21:18:09 r500 kernel: [4441] GEOM_ELI: g_eli_read_done() failed (err= or=3D5) label/spaceloop.eli[READ(offset=3D270336, length=3D8192)] Sep 6 21:18:27 r500 kernel: [4459] (da1:umass-sim1:1:0:0): WRITE(10). CDB:= 2a 00 00 60 65 0c 00 00 40 00=20 Sep 6 21:18:27 r500 kernel: [4459] (da1:umass-sim1:1:0:0): CAM status: CCB= request completed with an error Sep 6 21:18:27 r500 kernel: [4459] (da1:umass-sim1:1:0:0): Retrying command Sep 6 21:18:45 r500 kernel: [4477] (da1:umass-sim1:1:0:0): WRITE(10). CDB:= 2a 00 00 60 65 0c 00 00 40 00=20 Sep 6 21:18:45 r500 kernel: [4477] (da1:umass-sim1:1:0:0): CAM status: CCB= request completed with an error Sep 6 21:18:45 r500 kernel: [4477] (da1:umass-sim1:1:0:0): Retrying command Sep 6 21:19:03 r500 kernel: [4495] (da1:umass-sim1:1:0:0): WRITE(10). CDB:= 2a 00 00 60 65 0c 00 00 40 00=20 Sep 6 21:19:03 r500 kernel: [4495] (da1:umass-sim1:1:0:0): CAM status: CCB= request completed with an error Sep 6 21:19:03 r500 kernel: [4495] (da1:umass-sim1:1:0:0): Retrying command Sep 6 21:19:21 r500 kernel: [4514] (da1:umass-sim1:1:0:0): WRITE(10). CDB:= 2a 00 00 60 65 0c 00 00 40 00=20 Sep 6 21:19:21 r500 kernel: [4514] (da1:umass-sim1:1:0:0): CAM status: CCB= request completed with an error Sep 6 21:19:21 r500 kernel: [4514] (da1:umass-sim1:1:0:0): Retrying command Sep 6 21:19:40 r500 kernel: [4532] (da1:umass-sim1:1:0:0): WRITE(10). CDB:= 2a 00 00 60 65 0c 00 00 40 00=20 Sep 6 21:19:40 r500 kernel: [4532] (da1:umass-sim1:1:0:0): CAM status: CCB= request completed with an error Sep 6 21:19:40 r500 kernel: [4532] (da1:umass-sim1:1:0:0): Error 5, Retrie= s exhausted Sep 6 21:19:40 r500 kernel: [4532] GEOM_ELI: g_eli_write_done() failed (er= ror=3D5) label/spaceloop.eli[WRITE(offset=3D3234469888, length=3D32768)] [...] Sep 6 21:29:46 r500 kernel: [5138] GEOM_ELI: Device label/takems.eli destr= oyed. Sep 6 21:29:52 r500 kernel: [5144] ugen0.3: at usbus0 (d= isconnected) Sep 6 21:29:52 r500 kernel: [5144] umass2: at uhub0, port 1, addr 3 (disco= nnected) Sep 6 21:29:52 r500 kernel: [5144] da2 at umass-sim2 bus 2 scbus4 target 0= lun 0 Sep 6 21:29:52 r500 kernel: [5144] da2: s/n AA04012= 900007508 detached Sep 6 21:29:52 r500 kernel: [5144] pass4 at umass-sim2 bus 2 scbus4 target= 0 lun 0 Sep 6 21:29:52 r500 kernel: [5144] pass4: s/n AA040= 12900007508 detached Sep 6 21:29:52 r500 kernel: [5144] (pass4:umass-sim2:2:0:0): Periph destro= yed Sep 6 21:29:52 r500 kernel: [5144] (da2:umass-sim2:2:0:0): Periph destroyed Sep 6 21:44:56 r500 kernel: [6049] umass1: at uhub1, port 1, addr 3 (disco= nnected) Sep 6 21:44:56 r500 kernel: [6049] da1 at umass-sim1 bus 1 scbus3 target 0= lun 0 Sep 6 21:44:56 r500 kernel: [6049] da1: s/n 0= 000000000002511 detached Sep 6 21:44:56 r500 kernel: [6049] pass3 at umass-sim1 bus 1 scbus3 target= 0 lun 0 Sep 6 21:44:56 r500 kernel: [6049] pass3: s/n= 0000000000002511 detached Sep 6 21:44:56 r500 kernel: [6049] (pass3:umass-sim1:1:0:0): Periph destro= yed Sep 6 21:44:56 r500 kernel: [6049] GEOM_ELI: Device label/spaceloop.eli de= stroyed. Sep 6 21:44:56 r500 kernel: [6049] GEOM_ELI: Detached label/spaceloop.eli = on last close. Sep 6 21:44:56 r500 kernel: [6049] (da1:umass-sim1:1:0:0): Periph destroyed Sep 6 21:44:57 r500 ZFS: vdev is removed, pool_guid=3D13593515477493551420= vdev_guid=3D2311923824790456307 Sep 6 21:44:57 r500 kernel: [6049] umass1: on usbus1 Sep 6 21:44:57 r500 kernel: [6049] umass1: SCSI over Bulk-Only; quirks = =3D 0x4101 Sep 6 21:44:57 r500 kernel: [6049] umass1:3:1: Attached to scbus3 Sep 6 21:46:10 r500 kernel: [6122] (probe0:umass-sim1:1:0:0): INQUIRY. CDB= : 12 00 00 00 24 00=20 Sep 6 21:46:10 r500 kernel: [6122] (probe0:umass-sim1:1:0:0): CAM status: = CCB request completed with an error Sep 6 21:46:10 r500 kernel: [6122] (probe0:umass-sim1:1:0:0): Retrying com= mand Sep 6 21:46:45 r500 kernel: [6157] ugen1.3: at usbus1 (disconnec= ted) Sep 6 21:46:45 r500 kernel: [6157] umass1: at uhub1, port 1, addr 3 (disco= nnected) Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): INQUIRY. CDB= : 12 00 00 00 24 00=20 Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): CAM status: = CCB request completed with an error Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): Retrying com= mand Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): INQUIRY. CDB= : 12 00 00 00 24 00=20 Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): CAM status: = CCB request completed with an error Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): Retrying com= mand Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): INQUIRY. CDB= : 12 00 00 00 24 00=20 Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): CAM status: = CCB request completed with an error Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): Retrying com= mand Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): INQUIRY. CDB= : 12 00 00 00 24 00=20 Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): CAM status: = CCB request completed with an error Sep 6 21:46:45 r500 kernel: [6157] (probe0:umass-sim1:1:0:0): Error 5, Ret= ries exhausted Two other pools, one using USB as well, were unaffected until the panic was triggered. A pleasant surprise was that the system entered ddb from Xorg and dumping on /dev/ada0s1b worked despite /dev/ada0s1b.eli being configured as swap device. I wasn't aware that this was working now. Fabian --Sig_/RF=29s9FFtRhTIQX5d+=r1I Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQMV1sACgkQBYqIVf93VJ30SwCggvna+u5WCWCr2ysP3JaM0sP6 xdEAoIPZ7NS8C3Pua3cW1cFYAG1IQY/Z =2tkT -----END PGP SIGNATURE----- --Sig_/RF=29s9FFtRhTIQX5d+=r1I-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 14:07:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D617B85 for ; Sun, 7 Sep 2014 14:07:52 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 046221AF2 for ; Sun, 7 Sep 2014 14:07:51 +0000 (UTC) Received: from delphij-macbook.local (unknown [10.64.64.51]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 47DC2F91D; Sun, 7 Sep 2014 07:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1410098864; x=1410113264; bh=WhzvOTtjQThYtY2KsO2SA/7XsZo/n1lP3umTsVzzJ9k=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=zZxd9QujYlUVeL0a5U/K4TSa3fbR42qAZVCz31Xgmmjy8r3D0JGpleZBqEtWKf3Ur UsM5jVUncZt9JoxVxMTI5y8VNa+rwOakv/i8PYgbTLu9XXJsZ+Yk93EvWueMDnT9pi TUiEpGtDZJp3hO1/33Cv6PnPaM8ceThS4r9BzTBQ= Message-ID: <540C66AC.8070809@delphij.net> Date: Sun, 07 Sep 2014 22:07:40 +0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock References: <492dbacb.5942cc9b@fabiankeil.de> In-Reply-To: <492dbacb.5942cc9b@fabiankeil.de> 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: Sun, 07 Sep 2014 14:07:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 9/7/14 9:02 PM, Fabian Keil wrote: > Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the > following panic yesterday: > > [...] Unread portion of the kernel message buffer: [6880] panic: > deadlkres: possible deadlock detected for 0xfffff80015289490, > blocked for 1800503 ticks Any chance to get all backtraces (e.g. thread apply all bt full 16)? I think a different thread that held the lock have been blocked, probably related to your disconnected vdev. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUDGarAAoJEJW2GBstM+nsU+AP/0CjAmk3p/j/HD3lOCRYRiyV JkajIcSI8FFgAfLuiULclnEziBT+XEgYDisoABd7FVaP890mL/Mp52RSLMYlr8VJ RP9Qv+KePNGVn52djSOPxnNdUNqgNGHiDEllUIZbBu28k/flV4EcSfm799iA9HES o84LPUUc1pm+NJTtgoT6QKWZ+kfuztfY3/vlwJEluJqSuoZkN8DII1jT3pE55R6h f++bqSD/eKOd/3EJ5qZ38glXhmeSPEJ+VJlVumuRMwQoe3II7nIrZZBYVMY1sRZ8 qqmi4mUU1EOGvQWYjZ+J+1TYDTQgO9PP/aEPhz39tyJxP4d/VNDbJqPvAw+ez9ZU jT7n9xuaFXr3WdJSexSFsDOJts9op6kytqnZScPTgVUi2AbUQwBu3wV9v9XKjqBa YlcHoGFlpUmlc8I9NXdTks0oyORct0K5E/5x00S9QUGw3EtokDVCBQ63n9L1usmd mRG7F5xgDoTtl6UQSdW+DLhYF0cS08zG6TBDBx630Bdbtye2j5rRVn/bmonZJpOd Mx0lUyYGKnJFnMaeJe2BsFkrMyUej1JuI0plLVe/QyZ/GBPKsXCIV1R/EC2+2rUF xgrJl18H5hnwyNpBxjjrBodz1zgbpntijcH301lxRYlJYDBBwUTk3WBxLs/HISTe itcqBb/VIO33cjBHn3qJ =QPRD -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 15:24:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1F10295 for ; Sun, 7 Sep 2014 15:24:14 +0000 (UTC) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) (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 449A5127F for ; Sun, 7 Sep 2014 15:24:13 +0000 (UTC) Received: from [87.79.252.204] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1XQeJx-0006rI-3g for freebsd-current@freebsd.org; Sun, 07 Sep 2014 17:24:05 +0200 Date: Sun, 7 Sep 2014 17:23:16 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock Message-ID: <4fa875ba.3cc970d7@fabiankeil.de> In-Reply-To: <540C66AC.8070809@delphij.net> References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/WvIg7bSSG29Dx92rRK+fj0F"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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, 07 Sep 2014 15:24:14 -0000 --Sig_/WvIg7bSSG29Dx92rRK+fj0F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Xin Li wrote: > On 9/7/14 9:02 PM, Fabian Keil wrote: > > Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got the > > following panic yesterday: > >=20 > > [...] Unread portion of the kernel message buffer: [6880] panic: > > deadlkres: possible deadlock detected for 0xfffff80015289490, > > blocked for 1800503 ticks >=20 > Any chance to get all backtraces (e.g. thread apply all bt full 16)? > I think a different thread that held the lock have been blocked, > probably related to your disconnected vdev. Output of "thread apply all bt full 16" is available at: http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.t= xt A lot of the backtraces prematurely end with "Cannot access memory at addre= ss", therefore I also added "thread apply all bt" output. Apparently there are at least two additional threads blocking below spa_get= _stats(): Thread 1182 (Thread 101989): #0 sched_switch (td=3D0xfffff800628cc490, newtd=3D, f= lags=3D) at /usr/src/sys/kern/sched_ule.c:1932 #1 0xffffffff805a23c1 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/= sys/kern/kern_synch.c:493 #2 0xffffffff805e4bca in sleepq_wait (wchan=3D0x0, pri=3D0) at /usr/src/sy= s/kern/subr_sleepqueue.c:631 #3 0xffffffff80539f10 in _cv_wait (cvp=3D0xfffff80025534a50, lock=3D0xffff= f80025534a30) at /usr/src/sys/kern/kern_condvar.c:139 #4 0xffffffff811721db in zio_wait (zio=3D) at /usr/sr= c/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1442 #5 0xffffffff81102111 in dbuf_read (db=3D, zio=3D, flags=3D) at /usr/src/sys/cddl/cont= rib/opensolaris/uts/common/fs/zfs/dbuf.c:649 #6 0xffffffff81108e6d in dmu_buf_hold (os=3D, object= =3D, offset=3D, tag=3D0x0, dbp=3D= 0xfffffe00955c6648, flags=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:172 #7 0xffffffff81163986 in zap_lockdir (os=3D0xfffff8002b7ab000, obj=3D92, t= x=3D0x0, lti=3DRW_READER, fatreader=3D1, adding=3D0, zapp=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:= 467 #8 0xffffffff811644ad in zap_count (os=3D0x0, zapobj=3D0, count=3D0xfffffe= 00955c66d8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_= micro.c:712 #9 0xffffffff8114a6dc in spa_get_errlog_size (spa=3D0xfffff800062ed000) at= /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:149 ---Type to continue, or q to quit--- #10 0xffffffff8113f549 in spa_get_stats (name=3D0xfffffe0044cac000 "spacelo= op", config=3D0xfffffe00955c68e8, altroot=3D0xfffffe0044cac430 "", buflen= =3D2048) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 #11 0xffffffff81189a45 in zfs_ioc_pool_stats (zc=3D0xfffffe0044cac000) at /= usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656 #12 0xffffffff81187290 in zfsdev_ioctl (dev=3D, zcmd= =3D, arg=3D, flag=3D, td=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:= 6136 #13 0xffffffff80464a55 in devfs_ioctl_f (fp=3D0xfffff80038bd00a0, com=3D322= 2821381, data=3D0xfffff800067b80a0, cred=3D, td=3D0xff= fff800628cc490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #14 0xffffffff805f3c3d in kern_ioctl (td=3D0xfffff800628cc490, fd=3D, com=3D0) at file.h:311 #15 0xffffffff805f381c in sys_ioctl (td=3D0xfffff800628cc490, uap=3D0xfffff= e00955c6b80) at /usr/src/sys/kern/sys_generic.c:702 #16 0xffffffff8085c2db in amd64_syscall (td=3D0xfffff800628cc490, traced=3D= 0) at subr_syscall.c:133 #17 0xffffffff8083f90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:390 #18 0x00000008019fc3da in ?? () Previous frame inner to this frame (corrupt stack?) Thread 1188 (Thread 102480): #0 sched_switch (td=3D0xfffff80015a63920, newtd=3D, f= lags=3D) at /usr/src/sys/kern/sched_ule.c:1932 #1 0xffffffff805a23c1 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/= sys/kern/kern_synch.c:493 #2 0xffffffff805e4bca in sleepq_wait (wchan=3D0x0, pri=3D0) at /usr/src/sy= s/kern/subr_sleepqueue.c:631 #3 0xffffffff805a12b2 in _sx_xlock_hard (sx=3D0xfffff800062ed820, tid=3D18= 446735277979744544, opts=3D, file=3D0x0, line=3D0) at = /usr/src/sys/kern/kern_sx.c:676 #4 0xffffffff805a0add in _sx_xlock (sx=3D0x0, opts=3D0, file=3D, line=3D0) at sx.h:154 #5 0xffffffff8114a691 in spa_get_errlog_size (spa=3D0xfffff800062ed000) at= /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:142 #6 0xffffffff8113f549 in spa_get_stats (name=3D0xfffffe0005d6c000 "spacelo= op", config=3D0xfffffe0095f708e8, altroot=3D0xfffffe0005d6c430 "", buflen= =3D2048) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 #7 0xffffffff81189a45 in zfs_ioc_pool_stats (zc=3D0xfffffe0005d6c000) at /= usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656 #8 0xffffffff81187290 in zfsdev_ioctl (dev=3D, zcmd= =3D, arg=3D, flag=3D, td=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:= 6136 #9 0xffffffff80464a55 in devfs_ioctl_f (fp=3D0xfffff8000631a320, com=3D322= 2821381, data=3D0xfffff800067b8d00, cred=3D, td=3D0xff= fff80015a63920) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #10 0xffffffff805f3c3d in kern_ioctl (td=3D0xfffff80015a63920, fd=3D, com=3D0) at file.h:311 #11 0xffffffff805f381c in sys_ioctl (td=3D0xfffff80015a63920, uap=3D0xfffff= e0095f70b80) at /usr/src/sys/kern/sys_generic.c:702 #12 0xffffffff8085c2db in amd64_syscall (td=3D0xfffff80015a63920, traced=3D= 0) at subr_syscall.c:133 #13 0xffffffff8083f90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:390 #14 0x00000008019fc3da in ?? () Previous frame inner to this frame (corrupt stack?) Fabian --Sig_/WvIg7bSSG29Dx92rRK+fj0F Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQMeGQACgkQBYqIVf93VJ1EEQCgvi1CN0qc8FR7Xaqdh2efO47s d3AAoMH3hR4Kqy+Zy4nbgGx4KbSFEhE2 =fwhH -----END PGP SIGNATURE----- --Sig_/WvIg7bSSG29Dx92rRK+fj0F-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 15:44:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 902DB81B; Sun, 7 Sep 2014 15:44:27 +0000 (UTC) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AA741481; Sun, 7 Sep 2014 15:44:27 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id i7so9968570oag.0 for ; Sun, 07 Sep 2014 08:44:26 -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=LM1qR5GIwoDBOUH+1P4CDCSa/KGdPCG/pBPeME5/6xM=; b=iCsKoiw0ZPGtXKpp3UfuiIxXfqEFzOaCIXKKHpMynS6fx0mbpFOd0q97d2d+L9eawB iom7bBsGT/uOxJ8RHiw+qmWTpH7SZZTSSXLddrCHiZvwdndFUMlBsgS78/4HPGuECzXi 7D/+BrbhI0/OFXvWbV3xepuESyLTl8ORcStR5LZ/OWKWcuoTyEt0tjNNVfCpQpoySutp SMffEGWiDZ3vbPZVjL7akCCf8A9mTRhhY1h3FOFs4sYbAwPnc0GVk5PXxkbKKiA40Hi6 0d2lUHWPB3lJbZd5757xkxHxE7qysZhUcUrP20eNfTaEGV2FkNbqIAL/BFqzUSt3aJrD Z+4A== MIME-Version: 1.0 X-Received: by 10.182.129.230 with SMTP id nz6mr26537317obb.16.1410104666494; Sun, 07 Sep 2014 08:44:26 -0700 (PDT) Received: by 10.202.176.4 with HTTP; Sun, 7 Sep 2014 08:44:26 -0700 (PDT) In-Reply-To: <20140907112811.5570fc85.ohartman@zedat.fu-berlin.de> References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> <20140907112811.5570fc85.ohartman@zedat.fu-berlin.de> Date: Sun, 7 Sep 2014 10:44:26 -0500 Message-ID: Subject: Re: service doen't get started at boottime, but can start manually From: Scot Hetzel To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , FreeBSD Ports , Erich Dollansky 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, 07 Sep 2014 15:44:27 -0000 On Sun, Sep 7, 2014 at 4:28 AM, O. Hartmann wrote: > Am Sun, 7 Sep 2014 04:03:25 -0500 > Scot Hetzel schrieb: > >> On Sun, Sep 7, 2014 at 3:39 AM, Scot Hetzel wrote: >> > I had a look at scripts/refdb.in, it is not a proper rc script for >> > FreeBSD, as it is missing several keywords: >> > >> > # PROVIDE: <- all scripts need this >> > # REQUIRE: >> > # BEFORE: >> > # KEYWORD: <- optional >> > >> > Which tells rcorder where to put refdb in the startup order. Since >> > these are missing, rcorder doesn't place it in the startup list. >> > >> I looked again, and it is not rcorder, it's /etc/rc and /etc/rc.subr >> that determine which script to run. >> >> /etc/rc calls find_local_scripts_new from /etc/rc.subr. >> find_local_scripts_new checks each rc script to make sure that they >> have at least a "# PROVIDE: " keyword. If it does, then it adds that >> script to ${local_rc}. Then /etc/rc runs: >> >> files=`rcorder /etc/rc.d/* ${local_rc}` >> >> to get the startup order for these scripts. Then /etc/rc starts the >> scripts in the proper order. >> >> Since, /usr/local/etc/rc.d/refdb{,.sh.dist} is missing the "# PROVIDE: >> ", the script is skipped on startup. >> >> Since, rc.d/refdb is not a proper rc script, adding refdb_enable=YES >> to /etc/rc.conf{,.local} will not control the starting of this script. >> >> Someone should fix service, so that it checks the rc script has a "# >> PROVIDE: ", and displays an error message if it doesn't. > > Hello Scott, > > as the new maintainer of this port, I'm working on a solution, but first, I have to > understand the way this obscure rc-script system works. Thanks for your good explanation. > I tried to put PROVIDE/REQUIRE in the script, but I also changed refdb.sh -> refdb > which, in the end, didn't work. The service IS started with refdb.sh in rc.d/. > > Since the original refdb.sh init script targets both Linux and *BSD and delegates the > starting, stopping et cetera to a script called refdbctl, the latter script needs to be > examinded and as far as I understand, most of its functionality is covered > by /etc/rc.cubr, except the part where refdbctl searches for the path of the PID file and > replaces the init/default path its configuration counterpart found in > /etc/refdb/refdbdrc. > > I guess, at the end FreeBSD doen't need the templated refdbctl/refdb.in (to be found in > the sources in scripts/). > > If you'd like to have a look at it, I can send you the sekelton I've already prepared for > the refurbishment of the port. > I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a few minor changes. This script (untested) should do what the scripts/refdb.in and scripts/refdbctl.in were doing: #!/bin/sh # # $FreeBSD$ # # PROVIDE: refdbd # REQUIRE: LOGIN # KEYWORD: shutdown . /etc/rc.subr name="refdbd" rcvar="refdbd_enable" command="%%PREFIX%%/bin/${name}" pidfile="/var/run/${name}.pid" required_files="/etc/${name}.conf" extra_commands="reload" load_rc_config $name run_rc_command "$1" Place the above in textproc/refdb/files/refdb.in, then add: USE_RC_SUBR= refdbd in textproc/refdb/Makefile. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 15:56:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B44B2B4C for ; Sun, 7 Sep 2014 15:56:44 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98FC915A1 for ; Sun, 7 Sep 2014 15:56:44 +0000 (UTC) Received: from delphij-macbook.local (unknown [10.64.64.51]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B3D08FE3D; Sun, 7 Sep 2014 08:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1410105403; x=1410119803; bh=kAMVrVRaCqGnwB6jFlvjehir4sgi4JLbxbIph3pMX+c=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=QujuUClYIEzRQX4Q9s1uZsuyTvl1e6H2mWEziZBNCVSbIoR+mzcJjX5sKnqzzfe/e 5Tj+guyZfMYVRRV9XOMCs3YdrYGriu5gVAW/jCaavnBYACwIrLr9pSQhn4t6IMYztU pUrGItCBI/eQdYP11wXxeNAoULeRJs5LVQ+U//nU= Message-ID: <540C8039.7010309@delphij.net> Date: Sun, 07 Sep 2014 23:56:41 +0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Fabian Keil , freebsd-current@freebsd.org Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> <4fa875ba.3cc970d7@fabiankeil.de> In-Reply-To: <4fa875ba.3cc970d7@fabiankeil.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Alexander Motin 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, 07 Sep 2014 15:56:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 9/7/14 11:23 PM, Fabian Keil wrote: > Xin Li wrote: > >> On 9/7/14 9:02 PM, Fabian Keil wrote: >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got >>> the following panic yesterday: >>> >>> [...] Unread portion of the kernel message buffer: [6880] >>> panic: deadlkres: possible deadlock detected for >>> 0xfffff80015289490, blocked for 1800503 ticks >> >> Any chance to get all backtraces (e.g. thread apply all bt full >> 16)? I think a different thread that held the lock have been >> blocked, probably related to your disconnected vdev. > > Output of "thread apply all bt full 16" is available at: > http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.txt > > A lot of the backtraces prematurely end with "Cannot access memory > at address", therefore I also added "thread apply all bt" output. > > Apparently there are at least two additional threads blocking below > spa_get_stats(): > > Thread 1182 (Thread 101989): #0 sched_switch > (td=0xfffff800628cc490, newtd=, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1932 #1 > 0xffffffff805a23c1 in mi_switch (flags=260, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:493 #2 0xffffffff805e4bca in > sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:631 #3 0xffffffff80539f10 in > _cv_wait (cvp=0xfffff80025534a50, lock=0xfffff80025534a30) at > /usr/src/sys/kern/kern_condvar.c:139 #4 0xffffffff811721db in > zio_wait (zio=) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1442 > #5 0xffffffff81102111 in dbuf_read (db=, > zio=, flags=) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:649 > #6 0xffffffff81108e6d in dmu_buf_hold (os=, > object=, offset=, > tag=0x0, dbp=0xfffffe00955c6648, flags=) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:172 > #7 0xffffffff81163986 in zap_lockdir (os=0xfffff8002b7ab000, > obj=92, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp= optimized out>) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:467 > > #8 0xffffffff811644ad in zap_count (os=0x0, zapobj=0, count=0xfffffe00955c66d8) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:712 > #9 0xffffffff8114a6dc in spa_get_errlog_size > (spa=0xfffff800062ed000) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:149 > > - ---Type to continue, or q to quit--- > #10 0xffffffff8113f549 in spa_get_stats (name=0xfffffe0044cac000 > "spaceloop", config=0xfffffe00955c68e8, altroot=0xfffffe0044cac430 > "", buflen=2048) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 > #11 0xffffffff81189a45 in zfs_ioc_pool_stats > (zc=0xfffffe0044cac000) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656 > > #12 0xffffffff81187290 in zfsdev_ioctl (dev=, zcmd=, arg=, flag=, td=) > at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:6136 > > #13 0xffffffff80464a55 in devfs_ioctl_f (fp=0xfffff80038bd00a0, com=3222821381, data=0xfffff800067b80a0, cred=, td=0xfffff800628cc490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #14 0xffffffff805f3c3d in kern_ioctl (td=0xfffff800628cc490, > fd=, com=0) at file.h:311 #15 > 0xffffffff805f381c in sys_ioctl (td=0xfffff800628cc490, > uap=0xfffffe00955c6b80) at /usr/src/sys/kern/sys_generic.c:702 #16 > 0xffffffff8085c2db in amd64_syscall (td=0xfffff800628cc490, > traced=0) at subr_syscall.c:133 #17 0xffffffff8083f90b in > Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #18 > 0x00000008019fc3da in ?? () Previous frame inner to this frame > (corrupt stack?) Yes, thread 1182 owned the lock and is waiting for the zio be done. Other threads that wanted the lock would have to wait. I don't have much clue why the system entered this state, however, as the operations should have errored out (the GELI device is gone on 21:44:56 based on your log, which suggests all references were closed) instead of waiting. Adding mav@ as he may have some idea. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUDIA5AAoJEJW2GBstM+nsdsgP/RT4nBT4mvOtpF2IEL7VFexJ OjipGsWIDmG9kc8CEEN+qh3Q4+prJO3IwHGTUPa0Vu13jRZ3T/uoZj/ncVAqnCyW s+SeEBjVVhZs/B08LqT2A8fZI9jVdqvFVWEL02z3ibWggoCnP60oag1OyvkNGqQU apWtXkjTnrFmOEcbB95viD8QEhfUzlQgBbeRuK8ADtK/jQNEl6A8xdE5HCT2DIN4 icIwoj9eXqyLB0/aGVIFycRID4hWAZaqPehXVtGhCdnlGut7itdufuXtfmTCEDWs z3vkGjTCJ3qsyKSxl/2ABGRgAH/lpR6J/N2yZOSNMRTt9PbjN1iLppu2IfD33OdY QlQrI2HhbwvoZmYe4f4B/1/8qzKag77hzYG2J2aN0OGn45zkThOwoQt854zm7OHq f3O3pysxUInTnIJrdBa53cT0arhQRtYn1xL5CYyvK4Nto74ht6g/AuBJbBWzWM/B t2fKuZmpGt32lf+vHjWS0O2VWdkc6I6s5rVZJsSLzAMfc1rWePIcokPdUk9RucyX qRrNDpMW53APWhPKGpkK+Utyx/OLKhO62d7iiYrGhVX0FU+trBV/6QdwPdkaM8Lx 6v51hDK6ZjF/K5ZCYFwQOPcSaSHiMIpQBQr0mFh2s/05p3/f7jNAthTx7npEIfYZ PZ7DoMna8cwC4vtfoR1t =Jxfg -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 16:16:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3395E4D3; Sun, 7 Sep 2014 16:16:38 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9DC018C9; Sun, 7 Sep 2014 16:16:37 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h15so1611988igd.14 for ; Sun, 07 Sep 2014 09:16:37 -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=pXQbwyo5Gk9dL2f65a/xrpExYJdxd0msydp1s5Ykq2c=; b=WZMNcY+Q2lvjtdbL+hSl2a5i/1Tmmc5n7Ae47ueNvdk2LijLWN9IPxkIPWBO93eu+n nPxix1jg3oVjz1Sl7Jn7Ym3N6NyxQl6cZxnnG1ttsWSyZK7XdRuVKoZEhj1a41+AaCBV 5gEmW0q30k59J0YJqfQ5Qka+E2wtJzBtsbUc+pXxIayoLgzimZkutAh4CvBqNjgYuoXH HGtAfejO38eWVnkBmiu5z2dEqepImzFgOXxCeph+juZVLbC0tqeWQxbBLmTRY3HDFSQJ eFMGB9TL33h8StCBedrDYtkSRaugLLaijhtyhO8amvIqbh9R/8vfMm5OKRolK2bi+jyG YBWw== MIME-Version: 1.0 X-Received: by 10.42.208.70 with SMTP id gb6mr18521icb.89.1410106597306; Sun, 07 Sep 2014 09:16:37 -0700 (PDT) Received: by 10.50.122.42 with HTTP; Sun, 7 Sep 2014 09:16:37 -0700 (PDT) In-Reply-To: References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> <20140907112811.5570fc85.ohartman@zedat.fu-berlin.de> Date: Sun, 7 Sep 2014 11:16:37 -0500 Message-ID: Subject: Re: service doen't get started at boottime, but can start manually From: Scot Hetzel To: "O. Hartmann" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD CURRENT , FreeBSD Ports , Erich Dollansky 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, 07 Sep 2014 16:16:38 -0000 On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel wrote: > I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a > few minor changes. > This script (untested) should do what the scripts/refdb.in and > scripts/refdbctl.in were doing: > > #!/bin/sh > # > # $FreeBSD$ > # > > # PROVIDE: refdbd > # REQUIRE: LOGIN > # KEYWORD: shutdown > > . /etc/rc.subr > > name="refdbd" > rcvar="refdbd_enable" > command="%%PREFIX%%/bin/${name}" > pidfile="/var/run/${name}.pid" > required_files="/etc/${name}.conf" I missed required_files in my editing of the original script. If refdbd does have a configuration file, changes this to point to the correct file, otherwise this can be removed. > extra_commands="reload" > > load_rc_config $name > run_rc_command "$1" > > Place the above in textproc/refdb/files/refdb.in, then add: > > USE_RC_SUBR= refdbd > > in textproc/refdb/Makefile. > -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 16:26:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A959B9 for ; Sun, 7 Sep 2014 16:26:53 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id BD55419C6 for ; Sun, 7 Sep 2014 16:26:52 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id A887120E7088A; Sun, 7 Sep 2014 16:26:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id CAD9620E70885; Sun, 7 Sep 2014 16:26:41 +0000 (UTC) Message-ID: <0950545417594BC0835F74EA5804300E@multiplay.co.uk> From: "Steven Hartland" To: , "Fabian Keil" , References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> <4fa875ba.3cc970d7@fabiankeil.de> <540C8039.7010309@delphij.net> Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock Date: Sun, 7 Sep 2014 17:26:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: Alexander Motin 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, 07 Sep 2014 16:26:53 -0000 ----- Original Message ----- From: "Xin Li" To: "Fabian Keil" ; Cc: "Alexander Motin" Sent: Sunday, September 07, 2014 4:56 PM Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 9/7/14 11:23 PM, Fabian Keil wrote: >> Xin Li wrote: >> >>> On 9/7/14 9:02 PM, Fabian Keil wrote: >>>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got >>>> the following panic yesterday: >>>> >>>> [...] Unread portion of the kernel message buffer: [6880] >>>> panic: deadlkres: possible deadlock detected for >>>> 0xfffff80015289490, blocked for 1800503 ticks >>> >>> Any chance to get all backtraces (e.g. thread apply all bt full >>> 16)? I think a different thread that held the lock have been >>> blocked, probably related to your disconnected vdev. >> >> Output of "thread apply all bt full 16" is available at: >> http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.txt >> >> A lot of the backtraces prematurely end with "Cannot access memory >> at address", therefore I also added "thread apply all bt" output. >> >> Apparently there are at least two additional threads blocking below >> spa_get_stats(): >> >> Thread 1182 (Thread 101989): #0 sched_switch >> (td=0xfffff800628cc490, newtd=, flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1932 #1 >> 0xffffffff805a23c1 in mi_switch (flags=260, newtd=0x0) at >> /usr/src/sys/kern/kern_synch.c:493 #2 0xffffffff805e4bca in >> sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:631 #3 0xffffffff80539f10 in >> _cv_wait (cvp=0xfffff80025534a50, lock=0xfffff80025534a30) at >> /usr/src/sys/kern/kern_condvar.c:139 #4 0xffffffff811721db in >> zio_wait (zio=) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1442 >> #5 0xffffffff81102111 in dbuf_read (db=, >> zio=, flags=) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:649 >> #6 0xffffffff81108e6d in dmu_buf_hold (os=, >> object=, offset=, >> tag=0x0, dbp=0xfffffe00955c6648, flags=) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:172 >> #7 0xffffffff81163986 in zap_lockdir (os=0xfffff8002b7ab000, >> obj=92, tx=0x0, lti=RW_READER, fatreader=1, adding=0, zapp=> optimized out>) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:467 >> >> > #8 0xffffffff811644ad in zap_count (os=0x0, zapobj=0, > count=0xfffffe00955c66d8) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:712 >> #9 0xffffffff8114a6dc in spa_get_errlog_size >> (spa=0xfffff800062ed000) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:149 >> >> > - ---Type to continue, or q to quit--- >> #10 0xffffffff8113f549 in spa_get_stats (name=0xfffffe0044cac000 >> "spaceloop", config=0xfffffe00955c68e8, altroot=0xfffffe0044cac430 >> "", buflen=2048) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 >> #11 0xffffffff81189a45 in zfs_ioc_pool_stats >> (zc=0xfffffe0044cac000) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656 >> >> > #12 0xffffffff81187290 in zfsdev_ioctl (dev=, > zcmd=, arg=, flag= optimized out>, td=) >> at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:6136 >> >> > #13 0xffffffff80464a55 in devfs_ioctl_f (fp=0xfffff80038bd00a0, > com=3222821381, data=0xfffff800067b80a0, cred=, > td=0xfffff800628cc490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 >> #14 0xffffffff805f3c3d in kern_ioctl (td=0xfffff800628cc490, >> fd=, com=0) at file.h:311 #15 >> 0xffffffff805f381c in sys_ioctl (td=0xfffff800628cc490, >> uap=0xfffffe00955c6b80) at /usr/src/sys/kern/sys_generic.c:702 #16 >> 0xffffffff8085c2db in amd64_syscall (td=0xfffff800628cc490, >> traced=0) at subr_syscall.c:133 #17 0xffffffff8083f90b in >> Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #18 >> 0x00000008019fc3da in ?? () Previous frame inner to this frame >> (corrupt stack?) > > Yes, thread 1182 owned the lock and is waiting for the zio be done. > Other threads that wanted the lock would have to wait. > > I don't have much clue why the system entered this state, however, as > the operations should have errored out (the GELI device is gone on > 21:44:56 based on your log, which suggests all references were closed) > instead of waiting. > > Adding mav@ as he may have some idea. We're seen a disk drop invalidating a pool before, which should fail all reads / writes but process have instead just wedged in the kernel. >From experience I'd say it happens ~5% of time, so its quite hard to catch. Unfortunately never managed to get a dump of it. Regards Steve From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 17:00:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7799399B for ; Sun, 7 Sep 2014 17:00:41 +0000 (UTC) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (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 06CBD1DD7 for ; Sun, 7 Sep 2014 17:00:40 +0000 (UTC) Received: from [87.79.252.204] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1XQfpI-0000Of-Cf for freebsd-current@freebsd.org; Sun, 07 Sep 2014 19:00:32 +0200 Date: Sun, 7 Sep 2014 19:00:33 +0200 From: Fabian Keil To: Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock Message-ID: <69f90aa2.5d2989ae@fabiankeil.de> In-Reply-To: <540C8039.7010309@delphij.net> References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> <4fa875ba.3cc970d7@fabiankeil.de> <540C8039.7010309@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/A5pQFSMRW5iUxcWMFYlZxJV"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 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, 07 Sep 2014 17:00:41 -0000 --Sig_/A5pQFSMRW5iUxcWMFYlZxJV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Xin Li wrote: > On 9/7/14 11:23 PM, Fabian Keil wrote: > > Xin Li wrote: > >=20 > >> On 9/7/14 9:02 PM, Fabian Keil wrote: > >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got > >>> the following panic yesterday: > >>>=20 > >>> [...] Unread portion of the kernel message buffer: [6880] > >>> panic: deadlkres: possible deadlock detected for > >>> 0xfffff80015289490, blocked for 1800503 ticks > >>=20 > >> Any chance to get all backtraces (e.g. thread apply all bt full > >> 16)? I think a different thread that held the lock have been > >> blocked, probably related to your disconnected vdev. > >=20 > > Output of "thread apply all bt full 16" is available at:=20 > > http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlo= ck.txt > > > > A lot of the backtraces prematurely end with "Cannot access memory > > at address", therefore I also added "thread apply all bt" output. > >=20 > > Apparently there are at least two additional threads blocking below > > spa_get_stats(): [...] > Yes, thread 1182 owned the lock and is waiting for the zio be done. > Other threads that wanted the lock would have to wait. >=20 > I don't have much clue why the system entered this state, however, as > the operations should have errored out (the GELI device is gone on > 21:44:56 based on your log, which suggests all references were closed) > instead of waiting. It occurred to me that I have relevant auth.log entries as well: Sep 6 20:54:31 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/geli attach -j - /dev/label/spaceloop Sep 6 20:54:44 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/geli attach -j - /dev/label/takems Sep 6 20:54:51 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zpool import -d /dev/label takems Sep 6 20:55:30 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zfs send -i @2014-08-13_23:10 tank/home/fk@2014-0= 9-06_19:56 Sep 6 20:55:30 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zfs receive -v -u -F spaceloop/backup/r500/tank/h= ome/fk Sep 6 20:55:46 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zfs send -i @2014-08-13_23:10 tank/home/fk@2014-0= 9-06_19:56 Sep 6 20:55:46 r500 sudo: fk : TTY=3Dpts/5 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zfs receive -v -u -F spaceloop/backup/r500/tank/h= ome/fk [...] Sep 6 21:28:47 r500 sudo: fk : TTY=3Dpts/6 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zpool status spaceloop Sep 6 21:29:43 r500 sudo: fk : TTY=3Dpts/9 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zpool export takems Sep 6 21:29:46 r500 sudo: fk : TTY=3Dpts/9 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/geli detach label/takems.eli Sep 6 21:30:08 r500 sudo: fk : TTY=3Dpts/10 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/sbin/zpool clear spaceloop Sep 6 21:44:16 r500 sudo: fk : TTY=3Dpts/11 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/usr/sbin/usbconfig Sep 6 21:44:56 r500 sudo: fk : TTY=3Dpts/11 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/usr/sbin/usbconfig -d 1.3 reset Sep 6 21:46:26 r500 sudo: fk : TTY=3Dpts/1 ; PWD=3D/home/fk ; USER= =3Droot ; COMMAND=3D/usr/sbin/usbconfig Sep 6 22:03:33 r500 login: login on ttyv0 as fk IIRC, I tried the USB reset because the "zfs receive ... spaceloop/*", "zpool status spaceloop" and "zpool clear spaceloop" processes (and some that weren't called with sudo and thus weren't logged) got stuck and while it caused the kernel to close label/spaceloop.eli as intended, it did not noticeable affect the deadlocked processes. I don't remember exactly why the same ZFS stream was sent twice, but the mo= st likely explanation seems to be that I aborted the operation before it was d= one and it's conceivable that this left the system in a state that caused the s= econd attempt to get stuck. Fabian --Sig_/A5pQFSMRW5iUxcWMFYlZxJV Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQMjzEACgkQBYqIVf93VJ3JhQCfYxpbckkuu4k0LhEBrdFEz+oe qVEAoJ+WeRJfPjfnVreyC/aMiUAzKNZg =tiZ7 -----END PGP SIGNATURE----- --Sig_/A5pQFSMRW5iUxcWMFYlZxJV-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 19:23:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86373126; Sun, 7 Sep 2014 19:23:36 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 36F8D103D; Sun, 7 Sep 2014 19:23:35 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XQi3b-000apw-Cx>; Sun, 07 Sep 2014 21:23:27 +0200 Received: from g225112056.adsl.alicedsl.de ([92.225.112.56] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XQi3b-001vBm-9m>; Sun, 07 Sep 2014 21:23:27 +0200 Date: Sun, 7 Sep 2014 21:23:22 +0200 From: "O. Hartmann" To: Scot Hetzel Subject: Re: service doen't get started at boottime, but can start manually Message-ID: <20140907212322.4f2d370f.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> <20140907112811.5570fc85.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/bqP79W9lE9.IooexXALO8p5"; protocol="application/pgp-signature" X-Originating-IP: 92.225.112.56 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , FreeBSD Ports , Erich Dollansky 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, 07 Sep 2014 19:23:36 -0000 --Sig_/bqP79W9lE9.IooexXALO8p5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 7 Sep 2014 11:16:37 -0500 Scot Hetzel schrieb: > On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel wrote: > > I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a > > few minor changes. > > This script (untested) should do what the scripts/refdb.in and > > scripts/refdbctl.in were doing: > > > > #!/bin/sh > > # > > # $FreeBSD$ > > # > > > > # PROVIDE: refdbd > > # REQUIRE: LOGIN > > # KEYWORD: shutdown > > > > . /etc/rc.subr > > > > name=3D"refdbd" > > rcvar=3D"refdbd_enable" > > command=3D"%%PREFIX%%/bin/${name}" > > pidfile=3D"/var/run/${name}.pid" > > required_files=3D"/etc/${name}.conf" >=20 > I missed required_files in my editing of the original script. >=20 > If refdbd does have a configuration file, changes this to point to the > correct file, otherwise this can be removed. >=20 > > extra_commands=3D"reload" > > > > load_rc_config $name > > run_rc_command "$1" > > > > Place the above in textproc/refdb/files/refdb.in, then add: > > > > USE_RC_SUBR=3D refdbd > > > > in textproc/refdb/Makefile. > > >=20 Scot, I already have a initial refdbd frameworked file, thanks for your considera= tions. I think the following code is suitable for a clean FreeBSD-style rc.d file = for the port. I managed it to restart, status and start/stop via this rc.d-init script an= d it is for the upcoming refdb-1.0.3 which is in preparation. I need to mimik the refdbctl code at the point where it is looking for the = configuration of the PID file via refdbdrc in %%PREFIX%%/etc/refdb/. I havn't tested the = code properly, yet, but it worked as far a I could test it. Regards, Oliver Hartmann [...] #!/bin/sh # # $FreeBSD$ # # O. Hartmann, Berlin, 2014 # # # PROVIDE: refdbd # REQUIRE: LOGIN # KEYWORD: shutdown # # To enable this service, place # # refdbd_enable=3D"YES" # # in /etc/rc.conf[.local] #=20 # and optionally set the the following variables upon your environment: # # Choose another PIDFILE as the configured and/or default one: # refdbd_pidfile=3D"/var/run/refdbd.pid" # # To make the refdbd daemon accessible local only (127.0.0.1): # refdbd_local=3D"YES" . /etc/rc.subr name=3D"refdbd" rcvar=3Drefdbd_enable # read settings, set defaults load_rc_config ${name} command=3D"%%PREFIX%%/bin/${name}" globalconfig=3D"%%PREFIX%%/etc/refdb/refdbdrc" pidfile=3D"/var/run/${name}.pid" extra_commands=3D"reload" load_rc_config ${name} : ${refdbd_enable:=3D"NO"} : ${refdbd_local:=3D"NO"} if checkyesno refdbd_local; then refdbd_local_flags=3D"-I" else refdbd_local_flags=3D"" fi start_precmd=3D"${name}_prestart" refdbd_prestart() { local refdbvar refdbval # Check whether we have configured a PID file if [ "x${refdbd_pidfile}" !=3D "x" ]; then pidfile=3D"${refdbd_pidfile}" # ... if not configured via rc.conf[.local], # read the settings in the configure file. We're only interested in # nonstandard PID file settings else for config in ${globalconfig}; do while read refdbvar refdbval; do if [ -n "${refdbvar}" ]; then if [ ${refdbvar}=3D"pidfile" ]; then pidfile=3D${refdbval} fi fi done < $config done fi piddir=3D`dirname ${pidfile}` mkdir -p ${piddir} refdbd_pid_flags=3D"-P ${pidfile}" } # Set command arguments upon configuration command_args=3D"${refdbd_local_flags} ${refdbd_pid_flags}" run_rc_command "$1" --Sig_/bqP79W9lE9.IooexXALO8p5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUDLCuAAoJEOgBcD7A/5N8aN8IAMbevzPk4U29a0a7PiJgJNKl Cb7PZEWYi3lkd//tOORJ+F7fKIeKgSj70DY7OoMN3xkF0uoECa6ql28R8Iwb/8w4 e2loMTF4JDxVT5nuMfY7eHD3emI+ru/27OlFhpW9RIOeD+DD7Fs/nLywlxzuebMm mmZBplY6waqWbS5tL0f97bREi0pAxBRe6Sl1hB/CLNXi71DDkR5q45X8Xo6FaSaR QTrXKC6tTt4/qDmW3gPOTDqZACZSR7JHjmWrQuwfs6vKKcprz3LLy3/CsDxH6NmO DnX9Qm9uGPSAhAPg0K56SUGuSxA+WkheI5qz9hRI9YW1TSdLt79xef3ChM7gqEw= =MqKS -----END PGP SIGNATURE----- --Sig_/bqP79W9lE9.IooexXALO8p5-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 21:03:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EEBDCE1 for ; Sun, 7 Sep 2014 21:03:37 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 103E61C28 for ; Sun, 7 Sep 2014 21:03:36 +0000 (UTC) Received: from [192.168.200.205] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 05505192906 for ; Sun, 7 Sep 2014 21:03:35 +0000 (UTC) Subject: NO INET6 warning From: Sean Bruno Reply-To: sbruno@freebsd.org To: freebsd-current@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Sep 2014 14:03:35 -0700 Message-ID: <1410123815.10027.18.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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: Sun, 07 Sep 2014 21:03:37 -0000 make[4]: "/home/sbruno/bsd/fbsd_head/sys/modules/if_gif/Makefile" line 12: warning: Couldn't read shell's output for "cat /home/sbruno/bsd/obj/mips/mips.mips/home/sbruno/bsd/fbsd_head/sys/WZR-300HP/opt_inet6.h" Shouldn't this cat be done in a saner way? sean From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 21:08:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F656E3C; Sun, 7 Sep 2014 21:08:07 +0000 (UTC) Date: Sun, 7 Sep 2014 17:08:02 -0400 From: Glen Barber To: sbruno@freebsd.org Subject: Re: NO INET6 warning Message-ID: <20140907210802.GA48287@hub.FreeBSD.org> References: <1410123815.10027.18.camel@bruno> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <1410123815.10027.18.camel@bruno> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) 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, 07 Sep 2014 21:08:08 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 07, 2014 at 02:03:35PM -0700, Sean Bruno wrote: > make[4]: "/home/sbruno/bsd/fbsd_head/sys/modules/if_gif/Makefile" line > 12: warning: Couldn't read shell's output for > "cat /home/sbruno/bsd/obj/mips/mips.mips/home/sbruno/bsd/fbsd_head/sys/WZ= R-300HP/opt_inet6.h" >=20 >=20 > Shouldn't this cat be done in a saner way? >=20 This is done quite often throughout the tree, and bmake(1) does not like it when there is no value assigned from the '!=3D' expansion. The fix I've seen most commonly done is to echo a newline after the assignment, such as: Index: sys/modules/if_gif/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/modules/if_gif/Makefile (revision 271215) +++ sys/modules/if_gif/Makefile (working copy) @@ -9,7 +9,7 @@ KMOD=3D if_gif SRCS=3D if_gif.c in_gif.c opt_inet.h opt_inet6.h opt_mrouting.h =20 .if defined(KERNBUILDDIR) -OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h +OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h; echo .if empty(OPT_INET6) MK_INET6_SUPPORT=3Dno .endif Glen --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUDMkyAAoJELls3eqvi17QyoAP/RnZ0kL8xEokW1Nr1D39CRQp Z8Ncjlh1dpbZhgvcYjO2Yfg4e6MZO170QTggh3qu6KoXio5CvJKzFUVjbMm4TP+Z yDnhqTNIZzRVLo4eQgDSaUckZWmJNlEaKeRKNfBur/fpfHT1klryOF/99mP+Jlck Kko9EG/9E+Rt4ZiHd3S5UQmrrt9crfaHIoT7F2zU3t3rH1S8VYo7RmbaKupxQY9n RSFii69up7QDJ1vj9J/V0436lX1aUJ8P9gTsN8r3nSkrf6OYzJEugfgWsCNKlao7 eTz933S7xyjZ8LRndqtkw/Ls7pz3biNsbpv5efKvO0ys2kQ2FVOeu35H6O4q4wNi ZvSPoeIAFcr5fYHXfXXVY8xZ6sFcoyXSl8yxXMjkGjothRV7r0SUvwXFSTHcqdvo aviyekvmJmfLJx5Y9rUv04CeeQwuxmxNLmpv0nTXKinjFu1MVUy869XN6c0EsHME Djio7vuVd2XbL3go33qPZ5QCV1yhdVyouauHB/rkMava5u9FZYlI0vSF3wQYc2Qh chWL+ynk7rQQhmW+AyhgrqjJsG2xBjijdmVf6OCutnlDuniY16/jqEIQcBBNouO6 RyKT0E6YjMZvSefUX1+pLhkNN6DaWp7V9Ckzx6VNGRFrgR7v/K8GZucYjjYqjdOy ew/LUFxbMlaexjGOE+eT =iDh7 -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 22:28:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A78F8439; Sun, 7 Sep 2014 22:28:37 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 873CF148F; Sun, 7 Sep 2014 22:28:36 +0000 (UTC) Received: from [192.168.200.205] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 65817192906; Sun, 7 Sep 2014 22:28:35 +0000 (UTC) Subject: Re: NO INET6 warning From: Sean Bruno Reply-To: sbruno@freebsd.org To: Glen Barber In-Reply-To: <20140907210802.GA48287@hub.FreeBSD.org> References: <1410123815.10027.18.camel@bruno> <20140907210802.GA48287@hub.FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 07 Sep 2014 15:28:33 -0700 Message-ID: <1410128913.10027.19.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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: Sun, 07 Sep 2014 22:28:37 -0000 On Sun, 2014-09-07 at 17:08 -0400, Glen Barber wrote: > On Sun, Sep 07, 2014 at 02:03:35PM -0700, Sean Bruno wrote: > > make[4]: "/home/sbruno/bsd/fbsd_head/sys/modules/if_gif/Makefile" line > > 12: warning: Couldn't read shell's output for > > "cat /home/sbruno/bsd/obj/mips/mips.mips/home/sbruno/bsd/fbsd_head/sys/WZR-300HP/opt_inet6.h" > > > > > > Shouldn't this cat be done in a saner way? > > > > This is done quite often throughout the tree, and bmake(1) does not like > it when there is no value assigned from the '!=' expansion. > > The fix I've seen most commonly done is to echo a newline after the > assignment, such as: > > Index: sys/modules/if_gif/Makefile > =================================================================== > --- sys/modules/if_gif/Makefile (revision 271215) > +++ sys/modules/if_gif/Makefile (working copy) > @@ -9,7 +9,7 @@ KMOD= if_gif > SRCS= if_gif.c in_gif.c opt_inet.h opt_inet6.h opt_mrouting.h > > .if defined(KERNBUILDDIR) > -OPT_INET6!= cat ${KERNBUILDDIR}/opt_inet6.h > +OPT_INET6!= cat ${KERNBUILDDIR}/opt_inet6.h; echo > .if empty(OPT_INET6) > MK_INET6_SUPPORT=no > .endif > > Glen > LGTM sean From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 22:34:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E08115CD; Sun, 7 Sep 2014 22:34:37 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A704A1563; Sun, 7 Sep 2014 22:34:37 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id v10so5432337pde.5 for ; Sun, 07 Sep 2014 15:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iO8D49qJwjKihLgznPl6QMufGY4CPAf4FJEihSzBSCA=; b=V5sCzidK5osSZ8niPaDUYtjnrmtiHn9belAHE65WdtawWRPjCxQ4u8791LH/h4wOcJ d1RbFzIE2AzJcQ0arnvYJOulTMLUSnmfc3vcT6WKhsvJ3r61j2K5ZIl3fJgf4uuPOT85 Rkrr2pjuMH6zoGV1b8GdPhWjZ5rFnqJpf35kecrggVGCdborkT9/oMWnyjPUojymoS5p GinMlrzX/JW/wm5KpxYkB1uLzGbXiVszmgzWSxj3+F1AQ+gxIN+RSQoHGi2PQr3uKQ86 32n8y19/5bfum8CJCZz51Dc3lF2VKhsmqaPh7GmI4O9YBSIZfsbNpS93Oqhbwr4LyZJ/ O7gQ== X-Received: by 10.68.89.36 with SMTP id bl4mr15114332pbb.17.1410129277122; Sun, 07 Sep 2014 15:34:37 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:644f:a9af:8645:807a? ([2601:8:ab80:7d6:644f:a9af:8645:807a]) by mx.google.com with ESMTPSA id om6sm7257801pdb.89.2014.09.07.15.34.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 15:34:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_526BD5B1-739A-4B03-9320-430430E6958A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: NO INET6 warning From: yaneurabeya@gmail.com In-Reply-To: <20140907210802.GA48287@hub.FreeBSD.org> Date: Sun, 7 Sep 2014 15:34:35 -0700 Message-Id: References: <1410123815.10027.18.camel@bruno> <20140907210802.GA48287@hub.FreeBSD.org> To: Glen Barber X-Mailer: Apple Mail (2.1878.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: Sun, 07 Sep 2014 22:34:38 -0000 --Apple-Mail=_526BD5B1-739A-4B03-9320-430430E6958A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 7, 2014, at 14:08, Glen Barber wrote: > On Sun, Sep 07, 2014 at 02:03:35PM -0700, Sean Bruno wrote: >> make[4]: "/home/sbruno/bsd/fbsd_head/sys/modules/if_gif/Makefile" = line >> 12: warning: Couldn't read shell's output for >> "cat = /home/sbruno/bsd/obj/mips/mips.mips/home/sbruno/bsd/fbsd_head/sys/WZR-300H= P/opt_inet6.h" >>=20 >>=20 >> Shouldn't this cat be done in a saner way? >>=20 >=20 > This is done quite often throughout the tree, and bmake(1) does not = like > it when there is no value assigned from the '!=3D' expansion. >=20 > The fix I've seen most commonly done is to echo a newline after the > assignment, such as: >=20 > Index: sys/modules/if_gif/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/modules/if_gif/Makefile (revision 271215) > +++ sys/modules/if_gif/Makefile (working copy) > @@ -9,7 +9,7 @@ KMOD=3D if_gif > SRCS=3D if_gif.c in_gif.c opt_inet.h opt_inet6.h opt_mrouting.h >=20 > .if defined(KERNBUILDDIR) > -OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h > +OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h; echo > .if empty(OPT_INET6) > MK_INET6_SUPPORT=3Dno > .endif Shouldn=92t this all be removed and replaced with equivalent = logic provided by kern.opts.mk? Thanks! -Garrett --Apple-Mail=_526BD5B1-739A-4B03-9320-430430E6958A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUDN17AAoJEMZr5QU6S73e2SgIAK5NsVZt3dNPCmKyBgs5VA7d kR4RJdabmdE3+oaMH6YY8IKOvwoXtgvuABSS07UN1HWauDzkl/O6E63axlmGxYYh B8T06rsPLUjTTROxuNssSV0B8upz5XC3Md/9K4dbYivTPWb2P9oFDX8HxNjQHkay JZYR229n05be6V3tvJfvvbN2jhbEvep1B8g8Bpoo+CiJcyHOKyN9cKkVtPDPIa4l JEqBzQb7bhXU6fIglMgmryYVQiLs7R17OVhQH73HVovoFdrFgQOP4qplgnNhV6Gm +awmrmE1VbP/q2ETNON3do16BfpeaZshv9fB2E80GciOXtVjOZJR7qbsZqdWLDg= =fa2Z -----END PGP SIGNATURE----- --Apple-Mail=_526BD5B1-739A-4B03-9320-430430E6958A-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 7 23:04:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BB40B89; Sun, 7 Sep 2014 23:04:02 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEB811909; Sun, 7 Sep 2014 23:04:01 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id ty20so4347153lab.21 for ; Sun, 07 Sep 2014 16:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=AAO5JHlBzZhftkDwVUoCAsjNVeSBbIFeLPD6GkCcq3k=; b=pyK3PCA13WbzYACOmaXYtJLUqF4rpN85Bao33QDsue9e/gEqHlAA7PLeSYH2u2nSv9 Uq82e0+gjh+inyY6ZOVcAalzkiaN1btCmJ5FrgoXTt+SKkT2CVbxwH6ibkoK6L+mL6Ld dxvXG8Blk5kCyvECeuS54l5NRqSccpZjC7k+khPV0L9/ukRrt9s48oELhyfvyUXDxSer 1beanSudDlb/npg+WG6tXd8HeMk7dtdmIifluKNl9wvrETymjWEnOG+BC/+4YAeSjP+0 x243XMTrKssDmzyu58m4oq2iDh44a177LszrkzZxokm+lOlM34ly2YZCnvLi+/WGaoGy tWXw== MIME-Version: 1.0 X-Received: by 10.152.37.5 with SMTP id u5mr10655235laj.65.1410131039395; Sun, 07 Sep 2014 16:03:59 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Sun, 7 Sep 2014 16:03:59 -0700 (PDT) Date: Sun, 7 Sep 2014 16:03:59 -0700 X-Google-Sender-Auth: 2v9jDX7WEFTeZfzOr_QcZwDJr9Q Message-ID: Subject: make -DNO_ROOT to create chroot, problem installing into chroot with pkg From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-pkg@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, 07 Sep 2014 23:04:02 -0000 Hi, I am using pkg 1.3.7. I did the following as a regular user, not root: rm -fr /tmp/package cd /usr/src make buildworld make buildkernel make -DNO_ROOT -DDB_FROM_SRC installworld DESTDIR=/tmp/package make -DNO_ROOT -DDB_FROM_SRC installkernel DESTDIR=/tmp/package make -DNO_ROOT -DDB_FROM_SRC distribution DESTDIR=/tmp/package This created an installed world under /tmp/package Then I did: pkg -c /tmp/package install -y devel/kyua I got: pkg: chroot failed! Then I tried the same command under sudo: sudo pkg -c /tmp/package install -y devel/kyua I got: pkg: /var/db/pkg wrong user or group ownership (expected 0/0 versus actual 818/0) Is there a way to install packages into chroot without being root? -- Craig From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 02:01:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 953D941F; Mon, 8 Sep 2014 02:01: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 81F0B19BD; Mon, 8 Sep 2014 02:01:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BE5932FA; Mon, 8 Sep 2014 02:01:12 +0000 (UTC) Date: Mon, 8 Sep 2014 02:01:08 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, andrew@FreeBSD.org, ngie@FreeBSD.org, alc@FreeBSD.org Message-ID: <253597358.0.1410141672421.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1405 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD 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: Mon, 08 Sep 2014 02:01:12 -0000 See Changes: [alc] Make two functions static and eliminate an unused #define. [ngie] Include src.opts.mk after SHLIBDIR has been defined so libnv is installed to /lib , not /usr/lib MFC after: 3 days Approved by: rpaulo (mentor) Submitted by: antoine Pointyhat to: me Phabric: D739 [andrew] When entering the kernel with the MMU off assume we are running from a va == pa map. I'm not sure the code would work if we are not running from the identity map as the ARM core may attempt to read the next instruction from an invalid memory location. ------------------------------------------ [...truncated 269430 lines...] --- kern_cons.o --- ctfconvert -L VERSION -g kern_cons.o --- kern_exit.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_conf.o --- ctfconvert -L VERSION -g kern_conf.o --- kern_fork.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_exec.o --- ctfconvert -L VERSION -g kern_exec.o --- kern_jail.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_exit.o --- ctfconvert -L VERSION -g kern_exit.o --- kern_ktrace.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_fork.o --- ctfconvert -L VERSION -g kern_fork.o --- kern_lockf.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_descrip.o --- ctfconvert -L VERSION -g kern_descrip.o --- kern_mib.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_ktrace.o --- ctfconvert -L VERSION -g kern_ktrace.o --- kern_proc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_mib.o --- ctfconvert -L VERSION -g kern_mib.o --- kern_shutdown.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_lockf.o --- ctfconvert -L VERSION -g kern_lockf.o --- kern_sig.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_shutdown.o --- ctfconvert -L VERSION -g kern_shutdown.o --- kern_time.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_jail.o --- ctfconvert -L VERSION -g kern_jail.o --- posix4_mib.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_proc.o --- ctfconvert -L VERSION -g kern_proc.o --- posix4_mib.o --- ctfconvert -L VERSION -g posix4_mib.o --- subr_acl_nfs4.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_acl_posix1e.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- kern_sig.o --- ctfconvert -L VERSION -g kern_sig.o --- subr_acl_posix1e.o --- ctfconvert -L VERSION -g subr_acl_posix1e.o --- subr_firmware.o --- --- kern_time.o --- ctfconvert -L VERSION -g kern_time.o --- subr_firmware.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_log.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_uio.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_acl_nfs4.o --- ctfconvert -L VERSION -g subr_acl_nfs4.o --- sys_generic.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_log.o --- ctfconvert -L VERSION -g subr_log.o --- subr_firmware.o --- ctfconvert -L VERSION -g subr_firmware.o --- sys_pipe.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_process.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- subr_uio.o --- ctfconvert -L VERSION -g subr_uio.o --- tty.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_process.o --- ctfconvert -L VERSION -g sys_process.o --- tty_tty.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_generic.o --- ctfconvert -L VERSION -g sys_generic.o --- tty_ttydisc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- sys_pipe.o --- ctfconvert -L VERSION -g sys_pipe.o --- uipc_shm.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- tty_tty.o --- ctfconvert -L VERSION -g tty_tty.o --- uipc_syscalls.o --- --- tty.o --- ctfconvert -L VERSION -g tty.o --- uipc_syscalls.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- uipc_usrreq.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- tty_ttydisc.o --- ctfconvert -L VERSION -g tty_ttydisc.o --- vfs_acl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- uipc_shm.o --- ctfconvert -L VERSION -g uipc_shm.o --- vfs_bio.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_acl.o --- ctfconvert -L VERSION -g vfs_acl.o --- vfs_cache.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- uipc_usrreq.o --- ctfconvert -L VERSION -g uipc_usrreq.o --- vfs_cluster.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- uipc_syscalls.o --- ctfconvert -L VERSION -g uipc_syscalls.o --- vfs_default.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_cluster.o --- ctfconvert -L VERSION -g vfs_cluster.o --- vfs_export.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_cache.o --- ctfconvert -L VERSION -g vfs_cache.o --- vfs_extattr.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_export.o --- ctfconvert -L VERSION -g vfs_export.o --- vfs_hash.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_default.o --- ctfconvert -L VERSION -g vfs_default.o --- vfs_init.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_bio.o --- ctfconvert -L VERSION -g vfs_bio.o --- vfs_hash.o --- ctfconvert -L VERSION -g vfs_hash.o --- vfs_lookup.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_mount.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_extattr.o --- ctfconvert -L VERSION -g vfs_extattr.o --- vfs_mountroot.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_init.o --- ctfconvert -L VERSION -g vfs_init.o --- vfs_subr.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_lookup.o --- ctfconvert -L VERSION -g vfs_lookup.o --- vfs_syscalls.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_mountroot.o --- ctfconvert -L VERSION -g vfs_mountroot.o --- vfs_vnops.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_mount.o --- ctfconvert -L VERSION -g vfs_mount.o --- nfs_fha.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g nfs_fha.o --- nfs_lock.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror ctfconvert -L VERSION -g nfs_lock.o --- vfs_subr.o --- ctfconvert -L VERSION -g vfs_subr.o --- nlm_advlock.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_vnops.o --- ctfconvert -L VERSION -g vfs_vnops.o --- nlm_prot_impl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- audit.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- vfs_syscalls.o --- ctfconvert -L VERSION -g vfs_syscalls.o --- audit_arg.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nlm_advlock.o --- ctfconvert -L VERSION -g nlm_advlock.o --- audit.o --- ctfconvert -L VERSION -g audit.o --- audit_bsm.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- audit_bsm_klib.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- audit_arg.o --- ctfconvert -L VERSION -g audit_arg.o --- audit_syscalls.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- audit_bsm_klib.o --- ctfconvert -L VERSION -g audit_bsm_klib.o --- audit_worker.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- nlm_prot_impl.o --- ctfconvert -L VERSION -g nlm_prot_impl.o --- mac_audit.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- audit_syscalls.o --- :306:39: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] (udata.au_qctrl64.aq64_minfree < 0) || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ 1 warning generated. ctfconvert -L VERSION -g audit_syscalls.o --- mac_audit.o --- ctfconvert -L VERSION -g mac_audit.o --- mac_cred.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- audit_worker.o --- ctfconvert -L VERSION -g audit_worker.o --- mac_pipe.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror --- mac_process.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -gdwarf-2 -mno-aes -mno-avx -Werror :366:4: error: implicit declaration of function 'vm_map_simplify_entry' is invalid in C99 [-Werror,-Wimplicit-function-declaration] vm_map_simplify_entry(map, vme); ^ 1 error generated. *** [mac_process.o] Error code 1 make[2]: stopped in /usr/obj --- mac_pipe.o --- ctfconvert -L VERSION -g mac_pipe.o --- mac_cred.o --- ctfconvert -L VERSION -g mac_cred.o --- audit_bsm.o --- ctfconvert -L VERSION -g audit_bsm.o 1 error make[2]: stopped in /usr/obj *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 02:34:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E268EBEB; Mon, 8 Sep 2014 02:34:29 +0000 (UTC) Date: Sun, 7 Sep 2014 22:34:25 -0400 From: Glen Barber To: yaneurabeya@gmail.com Subject: Re: NO INET6 warning Message-ID: <20140908023425.GF48287@hub.FreeBSD.org> References: <1410123815.10027.18.camel@bruno> <20140907210802.GA48287@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R6sEYoIZpp9JErk7" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mon, 08 Sep 2014 02:34:30 -0000 --R6sEYoIZpp9JErk7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 07, 2014 at 03:34:35PM -0700, yaneurabeya@gmail.com wrote: > On Sep 7, 2014, at 14:08, Glen Barber wrote: >=20 > > On Sun, Sep 07, 2014 at 02:03:35PM -0700, Sean Bruno wrote: > >> make[4]: "/home/sbruno/bsd/fbsd_head/sys/modules/if_gif/Makefile" line > >> 12: warning: Couldn't read shell's output for > >> "cat /home/sbruno/bsd/obj/mips/mips.mips/home/sbruno/bsd/fbsd_head/sys= /WZR-300HP/opt_inet6.h" > >>=20 > >>=20 > >> Shouldn't this cat be done in a saner way? > >>=20 > >=20 > > This is done quite often throughout the tree, and bmake(1) does not like > > it when there is no value assigned from the '!=3D' expansion. > >=20 > > The fix I've seen most commonly done is to echo a newline after the > > assignment, such as: > >=20 > > Index: sys/modules/if_gif/Makefile > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/modules/if_gif/Makefile (revision 271215) > > +++ sys/modules/if_gif/Makefile (working copy) > > @@ -9,7 +9,7 @@ KMOD=3D if_gif > > SRCS=3D if_gif.c in_gif.c opt_inet.h opt_inet6.h opt_mrouting.h > >=20 > > .if defined(KERNBUILDDIR) > > -OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h > > +OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h; echo > > .if empty(OPT_INET6) > > MK_INET6_SUPPORT=3Dno > > .endif >=20 > Shouldn=E2=80=99t this all be removed and replaced with equivalent logic = provided by kern.opts.mk? Probably. Glen --R6sEYoIZpp9JErk7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUDRWxAAoJELls3eqvi17QtBYQAMsa5gqje3unXKAgz+xZHzrV g0/6XQG45+XvG2lQPq7Qk4JR4ONSuGxTwmucIQhqRfh0rMxkDdBzQ8Xv/REON0O6 f0WmmTpS4w7jJUmRzjWm9bSvkOrFeGfvJEh2gFACXhtrpeYejRHvWXBlueyxeTcQ brHc4xo55X2FMpW4WddJcVsZHuM7j7+5bsOtkA7A+O4h9qpG7iqVNZE0RHpTO/Ht aM+BOLcmvuT1zx6YJyf/Us792NE/7l/JZYMgOE1tSydN2VwOK/X9koaOhb5JjF2j +v0lLBztq+NXJQdF9Le0B5uVpf5lhQvLY0XwMFAvBUY+qk5kxIr+SZbXB+zmpW1y QPE/bqCm9KbiGKqstwM1WSVLSB261F0LHUteCbXXrrMdj6f8SokWgOXrJrPs539o QEsq/f68rilQshCk+Zziqri6M34hjyAogHg8riItEIIksGDUq0sLAW1b8ChnvmlP BHYg89mgMoI87MDvRRDYe0yn6JqSo7ohBOW2QEPLkvOAdImr2dJGnYoxWqhd7d7A 60ADHrqbRae7wnl0dg36e2zVlkawRKdTqCv9Qgg2RT5FyzqE0mLP4EWyP2HwIXvY 3lSZ1dVKjbTsz3DdUeuFq/Y/Z3GPWJ10omFlBi51mrfAp2srGEFIkjTlzTo7IyEg xfm1JWK37P/gKORiUXTg =3gqA -----END PGP SIGNATURE----- --R6sEYoIZpp9JErk7-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 02:56:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 355E1F09; Mon, 8 Sep 2014 02:56:25 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA19A1DE7; Mon, 8 Sep 2014 02:56:24 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id dc16so9508850qab.1 for ; Sun, 07 Sep 2014 19:56:24 -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:content-transfer-encoding; bh=azzVFKWz4bugHg1z8jBN9P9JIY64imjrFXBs4xfhYL4=; b=ZzjoUwojumRGFhClzIJOPFZdvWKahWMAahrCRwVvOxlL4lzKq4zaZ1Q2ObQ7afyEOs lUudsBKgut9OfOtJ8xGetNWeG1Ns2ELUMtR5tXvj1TRyw18GwYwe3HXlNWQcDqYj+ZQa 5YrFGbfxsqWbNyEW1FbaEjy29QfcxofNrY4X258PzOnkPt+b2Fxim0vNZdMwntNfHdQB Q0VJec0WBJisWTeHzmuBlA7yIrP7UNfiF9qAsP3X5N22w7IM9yICYr3FO6LJZbfp5juA eLxIxJrYSXlbN16WH2AM1YM7hnBSIsCXv7r7ABDIFYqERKd3qzLgBWuphYA2Ecd6M6kj hUyw== MIME-Version: 1.0 X-Received: by 10.140.31.75 with SMTP id e69mr36324863qge.2.1410144983941; Sun, 07 Sep 2014 19:56:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Sun, 7 Sep 2014 19:56:23 -0700 (PDT) In-Reply-To: <20140908023425.GF48287@hub.FreeBSD.org> References: <1410123815.10027.18.camel@bruno> <20140907210802.GA48287@hub.FreeBSD.org> <20140908023425.GF48287@hub.FreeBSD.org> Date: Sun, 7 Sep 2014 19:56:23 -0700 X-Google-Sender-Auth: aOaJmBkyMpvt8Vv46DKX66mSccg Message-ID: Subject: Re: NO INET6 warning From: Adrian Chadd To: Glen Barber Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , Garrett Cooper 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, 08 Sep 2014 02:56:25 -0000 No, because I may end up building a kernel that has no INET6 for a cut down platform that has no src.conf option set. -a On 7 September 2014 19:34, Glen Barber wrote: > On Sun, Sep 07, 2014 at 03:34:35PM -0700, yaneurabeya@gmail.com wrote: >> On Sep 7, 2014, at 14:08, Glen Barber wrote: >> >> > On Sun, Sep 07, 2014 at 02:03:35PM -0700, Sean Bruno wrote: >> >> make[4]: "/home/sbruno/bsd/fbsd_head/sys/modules/if_gif/Makefile" lin= e >> >> 12: warning: Couldn't read shell's output for >> >> "cat /home/sbruno/bsd/obj/mips/mips.mips/home/sbruno/bsd/fbsd_head/sy= s/WZR-300HP/opt_inet6.h" >> >> >> >> >> >> Shouldn't this cat be done in a saner way? >> >> >> > >> > This is done quite often throughout the tree, and bmake(1) does not li= ke >> > it when there is no value assigned from the '!=3D' expansion. >> > >> > The fix I've seen most commonly done is to echo a newline after the >> > assignment, such as: >> > >> > Index: sys/modules/if_gif/Makefile >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > --- sys/modules/if_gif/Makefile (revision 271215) >> > +++ sys/modules/if_gif/Makefile (working copy) >> > @@ -9,7 +9,7 @@ KMOD=3D if_gif >> > SRCS=3D if_gif.c in_gif.c opt_inet.h opt_inet6.h opt_mrouting.h >> > >> > .if defined(KERNBUILDDIR) >> > -OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h >> > +OPT_INET6!=3D cat ${KERNBUILDDIR}/opt_inet6.h; echo >> > .if empty(OPT_INET6) >> > MK_INET6_SUPPORT=3Dno >> > .endif >> >> Shouldn=E2=80=99t this all be removed and replaced with equivalent logic= provided by kern.opts.mk? > > Probably. > > Glen > From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 04:48:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F280FBC8; Mon, 8 Sep 2014 04:48:09 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E0C8619CB; Mon, 8 Sep 2014 04:48:09 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 57FBB372; Mon, 8 Sep 2014 04:48:10 +0000 (UTC) Date: Mon, 8 Sep 2014 04:48:06 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, andrew@FreeBSD.org, gjb@FreeBSD.org, ngie@FreeBSD.org, adrian@FreeBSD.org, alc@FreeBSD.org Message-ID: <693120333.1.1410151690323.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <253597358.0.1410141672421.JavaMail.jenkins@jenkins-9.freebsd.org> References: <253597358.0.1410141672421.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1406 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS 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, 08 Sep 2014 04:48:10 -0000 See From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 05:53:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA1DC6F9; Mon, 8 Sep 2014 05:53:32 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4C071904; Mon, 8 Sep 2014 05:53:31 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 32B0E1FE027; Mon, 8 Sep 2014 07:53:23 +0200 (CEST) Message-ID: <540D444C.6090904@selasky.org> Date: Mon, 08 Sep 2014 07:53:16 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: [RFC] Patch to improve TSO limitation formula in general References: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca> In-Reply-To: <1762951742.33012989.1409954952800.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Eric Joyner , FreeBSD Current , Scott Long , Jack F Vogel 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, 08 Sep 2014 05:53:33 -0000 On 09/06/14 00:09, Rick Macklem wrote: > Hans Petter Selesky wrote: >> On 09/05/14 23:19, Eric Joyner wrote: >>> There are some concerns if we use this with devices that ixl >>> supports: >>> >>> - The maximum fragment size is 16KB-1, which isn't a power of 2. >>> >> >> Hi Eric, >> >> Multiplying by powers of two are more fast, than non-powers of two. >> So >> in this case you would have to use 8KB as a maximum. >> > Well, I'm no architecture expert, but I really doubt the CPU delay of a > non-power of 2 multiply/divide is significant related to doing smaller > TSO segments. Long ago (as in 1970s) I did work on machines where shifts > for power of 2 multiply/divide was preferable, but these days I doubt it > is going to matter?? > >>> - You can't get the maximum TSO size for ixl devices by multiplying >>> the >>> maximum number of fragments by the maximum size. >>> Instead the number of fragments is AFAIK unlimited, but a segment >>> can only >>> span 8 mbufs (including the [up to 3] mbufs containing the header), >>> and the >>> maximum TSO size is 256KB. Hi, Maybe that can be a separate parameter? I see that your patch assumes that a segment can be any-length. That is not always the case. Remember there are JUMBO mbufs too. With my patch, the maximum segment size is a separate parameter. The total number of TSO bytes is then not so useful. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 07:37:09 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CF4FA11; Mon, 8 Sep 2014 07:37:09 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 20D32125C; Mon, 8 Sep 2014 07:37:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id A0DE556403; Mon, 8 Sep 2014 11:37:07 +0400 (MSK) Date: Mon, 8 Sep 2014 11:37:04 +0400 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <764889423.20140908113704@serebryakov.spb.ru> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: [CFT] Autofs. In-Reply-To: <20140904124330.GB4152@pc5.home> References: <20140730071933.GA20122@pc5.home> <53F0878E.3000401@beastielabs.net> <20140817145059.GA5497@pc5.home> <5407FFB0.80203@beastielabs.net> <20140904124330.GB4152@pc5.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, Hans Ottevanger , freebsd-arch@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, 08 Sep 2014 07:37:09 -0000 Hello, Edward. You wrote 4 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., = 16:43:30: ETN> It's a bug. Or rather, a missing feature. The problem here is that ETN> the "/" export "shadows" the rest. To handle this correctly, automoun= td(8) ETN> would need to mount the "/" share, then mount autofs on "/usr" etc, and ETN> then call it done. This part is easy. The problem is: how to expire ETN> (automatically unmount) it? Because of autofs mounts, the "/" share ETN> will always be busy, and thus won't ever get automatically unmounted. ETN> So, for now, we don't even try to handle this situation. I have same problem with /usr + /usr/home, which make autofs pretty useless for me :( Looks like, "autofs" mounts should not be considered "busy" for other automounted filesystems and should be processed separately... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 08:04:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60752486 for ; Mon, 8 Sep 2014 08:04:47 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D72ED15DE for ; Mon, 8 Sep 2014 08:04:46 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id n15so6736110lbi.33 for ; Mon, 08 Sep 2014 01:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:message-id:date:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=COrXza2iuPPmZS+HrzsA47eb2jFfvhEuNuQ88HLEZvk=; b=DEQ/ZFQ8S1LKZ6gvT+f2i1e6Aj1llrufztiSO/UI2RZzDY+6mELvnPrxSp9jY7NGCx M594rIQV4CUmuLMkvZwHeKO4ZFPP9BKnktTwPQAsMcbHlEQDiVoqpbK90uyWCXivhIgs ZCU/MgO5dRoCG+76V0JpX7jmXBqrbUskYTb3vk4h5WUdz94GOR5j6PCQDgS5Leglwfzw /MB9+6PP3hxjN3qviEqux9HnRS8KpMH4SoqHZt1KrSLP7d16WrIX8LLIofhydMMD+Dod kdDsL00T2Y+/lLAi1Uu3p3JgMks6Ao3wdwCwDyNs53tSo5QKrwukr2Jhwwec6XZZWTFp 4+5Q== X-Received: by 10.112.163.103 with SMTP id yh7mr26078300lbb.73.1410163484678; Mon, 08 Sep 2014 01:04:44 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id k9sm3316491lbj.4.2014.09.08.01.04.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 01:04:43 -0700 (PDT) Sender: Alexander Motin From: Alexander Motin X-Google-Original-From: Alexander Motin Message-ID: <540D631A.8090700@ixsystems.com> Date: Mon, 08 Sep 2014 11:04:42 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: d@delphij.net, Fabian Keil , freebsd-current@freebsd.org Subject: Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock References: <492dbacb.5942cc9b@fabiankeil.de> <540C66AC.8070809@delphij.net> <4fa875ba.3cc970d7@fabiankeil.de> <540C8039.7010309@delphij.net> In-Reply-To: <540C8039.7010309@delphij.net> X-Enigmail-Version: 1.6 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: Mon, 08 Sep 2014 08:04:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07.09.2014 18:56, Xin Li wrote: > On 9/7/14 11:23 PM, Fabian Keil wrote: >> Xin Li wrote: > >>> On 9/7/14 9:02 PM, Fabian Keil wrote: >>>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got >>>> the following panic yesterday: >>>> >>>> [...] Unread portion of the kernel message buffer: [6880] >>>> panic: deadlkres: possible deadlock detected for >>>> 0xfffff80015289490, blocked for 1800503 ticks >>> >>> Any chance to get all backtraces (e.g. thread apply all bt >>> full 16)? I think a different thread that held the lock have >>> been blocked, probably related to your disconnected vdev. > >> Output of "thread apply all bt full 16" is available at: >> http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.txt > >> A lot of the backtraces prematurely end with "Cannot access >> memory at address", therefore I also added "thread apply all bt" >> output. > >> Apparently there are at least two additional threads blocking >> below spa_get_stats(): > >> Thread 1182 (Thread 101989): #0 sched_switch >> (td=0xfffff800628cc490, newtd=, >> flags=) at >> /usr/src/sys/kern/sched_ule.c:1932 #1 0xffffffff805a23c1 in >> mi_switch (flags=260, newtd=0x0) at >> /usr/src/sys/kern/kern_synch.c:493 #2 0xffffffff805e4bca in >> sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:631 #3 0xffffffff80539f10 >> in _cv_wait (cvp=0xfffff80025534a50, lock=0xfffff80025534a30) at >> /usr/src/sys/kern/kern_condvar.c:139 #4 0xffffffff811721db in >> zio_wait (zio=) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1442 >> #5 0xffffffff81102111 in dbuf_read (db=, >> zio=, flags=) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:649 >> #6 0xffffffff81108e6d in dmu_buf_hold (os=> out>, object=, offset=> out>, tag=0x0, dbp=0xfffffe00955c6648, flags=> out>) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:172 >> #7 0xffffffff81163986 in zap_lockdir (os=0xfffff8002b7ab000, >> obj=92, tx=0x0, lti=RW_READER, fatreader=1, adding=0, >> zapp=) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:467 > >> > > #8 0xffffffff811644ad in zap_count (os=0x0, zapobj=0, > count=0xfffffe00955c66d8) at > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:712 >> > #9 0xffffffff8114a6dc in spa_get_errlog_size >> (spa=0xfffff800062ed000) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c:149 > >> > > ---Type to continue, or q to quit--- >> #10 0xffffffff8113f549 in spa_get_stats (name=0xfffffe0044cac000 >> "spaceloop", config=0xfffffe00955c68e8, >> altroot=0xfffffe0044cac430 "", buflen=2048) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:3287 >> #11 0xffffffff81189a45 in zfs_ioc_pool_stats >> (zc=0xfffffe0044cac000) at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1656 > >> > > #12 0xffffffff81187290 in zfsdev_ioctl (dev=, > zcmd=, arg=, flag= optimized out>, td=) >> at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:6136 > >> > > #13 0xffffffff80464a55 in devfs_ioctl_f (fp=0xfffff80038bd00a0, > com=3222821381, data=0xfffff800067b80a0, cred= out>, td=0xfffff800628cc490) at > /usr/src/sys/fs/devfs/devfs_vnops.c:757 >> #14 0xffffffff805f3c3d in kern_ioctl (td=0xfffff800628cc490, >> fd=, com=0) at file.h:311 #15 >> 0xffffffff805f381c in sys_ioctl (td=0xfffff800628cc490, >> uap=0xfffffe00955c6b80) at /usr/src/sys/kern/sys_generic.c:702 >> #16 0xffffffff8085c2db in amd64_syscall (td=0xfffff800628cc490, >> traced=0) at subr_syscall.c:133 #17 0xffffffff8083f90b in >> Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #18 >> 0x00000008019fc3da in ?? () Previous frame inner to this frame >> (corrupt stack?) > > Yes, thread 1182 owned the lock and is waiting for the zio be > done. Other threads that wanted the lock would have to wait. > > I don't have much clue why the system entered this state, however, > as the operations should have errored out (the GELI device is gone > on 21:44:56 based on your log, which suggests all references were > closed) instead of waiting. > > Adding mav@ as he may have some idea. Some time ago I experimented with ZFS behavior in situation of disappearing disks. I fixed several most easily reproducible scenarios, but finally I've got to conclusion that ZFS in many places written in a way that simply does not expect errors. In such cases it just stucks, waiting for disk to reappear and I/O to complete. In some situations after disk reconnect it can now be recovered with `zpool clear ...`, but still not all, since sometimes code may stuck holding some lock required for recovery. - -- Alexander Motin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJUDWMaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFOThDRjNDNEU2OUNDM0NEMEU1NzlENTU4 MzE4QzM5NTVCQUIyMjdGAAoJEIMYw5VbqyJ/0CcIAJ6QegWMb1EOVqB3dJiUB8if LKanU3dx4WGhofJPiPtsW6Aa8UO+4NevS+zjApXpHWge+QiWiN4NKaMMYxLgk5Zs a6rv6L0m7i/jlKbAQKj+ewUSOzX2XF66ERhGfoWfmUpjZIJqKV4nPnJksg6iEEUN RgDQdxvc6CxKvczUjmMBDdMIWDPUZ1aOoNarRmhNA2g0SnN4dKjQVPpD5zdOL8LI 3yN2ReUvXj1vSAY6Drmsr3MjdY8+EdpKgFY8VZj7wiu+KVK5YVHx5Xbq0M+LJ/yj YsT1IB4KgoFfSJNzfm/78bvpXvFzGlbrm8RsqYoV00Y3YYd2ybes04Bb6yg+Qd0= =wxCp -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 12:05:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20C9016A; Mon, 8 Sep 2014 12:05:47 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id B7DFD1297; Mon, 8 Sep 2014 12:05:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAMCaDVSDaFve/2dsb2JhbABZg2BXBIJ4xm4KhnlTAYEneIQDAQEBAwEBAQEgKx0DCwUWEgYCAg0EFQIpAQkYDgYIBwQBHASIGQgNpWqVGAEXgSyNSgYBAQEaNAcKgm+BUwWVcIN/hGKTTYFnHoF4IS8HgQAIFyKBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,486,1406606400"; d="scan'208";a="152309133" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 08 Sep 2014 08:05:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BC45CB4035; Mon, 8 Sep 2014 08:05:39 -0400 (EDT) Date: Mon, 8 Sep 2014 08:05:39 -0400 (EDT) From: Rick Macklem To: Hans Petter Selasky Message-ID: <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> In-Reply-To: <540D444C.6090904@selasky.org> Subject: Re: [RFC] Patch to improve TSO limitation formula in general MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org, Eric Joyner , FreeBSD Current , Scott Long , Jack F Vogel 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, 08 Sep 2014 12:05:47 -0000 Hans Petter Selasky wrote: > On 09/06/14 00:09, Rick Macklem wrote: > > Hans Petter Selesky wrote: > >> On 09/05/14 23:19, Eric Joyner wrote: > >>> There are some concerns if we use this with devices that ixl > >>> supports: > >>> > >>> - The maximum fragment size is 16KB-1, which isn't a power of 2. > >>> > >> > >> Hi Eric, > >> > >> Multiplying by powers of two are more fast, than non-powers of > >> two. > >> So > >> in this case you would have to use 8KB as a maximum. > >> > > Well, I'm no architecture expert, but I really doubt the CPU delay > > of a > > non-power of 2 multiply/divide is significant related to doing > > smaller > > TSO segments. Long ago (as in 1970s) I did work on machines where > > shifts > > for power of 2 multiply/divide was preferable, but these days I > > doubt it > > is going to matter?? > > > >>> - You can't get the maximum TSO size for ixl devices by > >>> multiplying > >>> the > >>> maximum number of fragments by the maximum size. > >>> Instead the number of fragments is AFAIK unlimited, but a segment > >>> can only > >>> span 8 mbufs (including the [up to 3] mbufs containing the > >>> header), > >>> and the > >>> maximum TSO size is 256KB. > > Hi, > > Maybe that can be a separate parameter? > > I see that your patch assumes that a segment can be any-length. That > is > not always the case. Remember there are JUMBO mbufs too. > I thought JUMBO mbufs were only going to be used on the receive side, however I suppose if a packet is received into a JUMBO mbuf and then forwarded on another interface... > With my patch, the maximum segment size is a separate parameter. The > total number of TSO bytes is then not so useful. > Well, if you are referring to if_hw_tsomax, I'm not sure it was the best plan to begin with. It was implemented for xen and I'm not sure that any other driver uses it as of now. However... I'm not a network/hardware guy, but it seems some devices do have the IP_MAXPACKET limit (use the ip_len field in the ip header to know how large the TSO segment is). There is also at least one device (82598 chip for "ix" driver) that can handle more that IP_MAXPACKET, so it seems appropriate to have a value that the driver can set. Since the maximum size of the gather list for transmit does seem to vary a lot between devices, with several handling less than 35, it does seem appropriate to allow drivers to specify that. If devices can't handle a single gather entry over a certain size, I think that does need to be specified along with the max size of the gather list, since the driver will need to use multiple gather entries for a single mbuf and tcp_output() should take that into account. In summary, yep, I basically agree. rick ps: Who will look at your patch soon. > --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 Mon Sep 8 14:21:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1612BB4E; Mon, 8 Sep 2014 14:21:47 +0000 (UTC) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtp004.mac.com [17.172.81.3]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB1F0139C; Mon, 8 Sep 2014 14:21:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from andersbo-mac.local (ti0025a400-3490.bb.online.no [85.167.24.175]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBL0022K3RZL570@st11p00mm-asmtp004.mac.com>; Mon, 08 Sep 2014 13:21:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.27,0.0.0000 definitions=2014-09-08_02:2014-09-08,2014-09-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=18 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409080122 Message-id: <540DAD5F.3050902@icloud.com> Date: Mon, 08 Sep 2014 15:21:35 +0200 From: Anders Bolt Evensen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0 To: gjb@FreeBSD.org Subject: Re: UEFI display frozen on Retina MacBook Pro References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> In-reply-to: <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> 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: Mon, 08 Sep 2014 14:21:47 -0000 On 05.09.14 19:37, John Nielsen wrote: > On Sep 5, 2014, at 11:30 AM, Glen Barber wrote: > >> On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote: >>> I have a "MacBook Pro Retina, Mid 2012" (MacBookPro10,1) on which I'd like to be able to boot FreeBSD from an external USB drive. For testing I've been using the mini-memstick images from the -CURRENT snapshots, most recently the one from 20140903. >>> >>> I am able to select "EFI Boot" on the USB device from the Mac's boot menu, and it does _something_, but the screen never changes--the image of the boot menu is displayed indefinitely. I think it is actually booting since there is drive activity and the caps lock key indicator starts working a few seconds in, but the screen just stays the same. Thinking the resolution of the Retina display may have been an issue, I tried booting with it disabled (lid closed) and an external monitor and keyboard. The result was the same--Mac boot menu frozen on the external display. >>> >>> Is there anything I should try to troubleshoot or debug this issue? Anything else I should include in a PR? I can test patches if needed (probably after building an image including the patch from a VM). >>> >> To be clear, which boot menu do you see? If you see the FreeBSD loader >> menu, escape to the loader prompt and try: >> >> set kern.vty=vt >> set hw.vga.textmode=1 >> boot >> >> I am a bit unclear under which conditions 'hw.vga.textmode=1' is >> required, though. > No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac when you hold down the option (alt) key while booting--big disk icons representing the bootable disks/partitions in the system. In my case it was the "Macintosh HD" volume (Mac OS Mavericks), my Windows partition, and the USB stick with the FreeBSD memstick image on it, which the Mac just called "EFI Boot" (and the icon was that of a USB disk). There is also a little section at the bottom that allows wifi network booting (if you've done all the black magic (not PXE) to get that to happen). It shows a circular activity animation while it scans for wireless networks. That animation stops when I select the USB EFI icon and press enter (and that is the only visual indication I get that I made a selection). > > JN > > _______________________________________________ > 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" To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: 1) Download the rEFIt installer from here: http://downloads.sourceforge.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=http%3A%2F%2Frefit.sourceforge.net%2F&ts=1410181876&use_mirror=optimate 2) Open the downloaded file 3) Run the following command from the terminal: sudo installer -pkg /Volumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm using an HFS formatted memory stick). 4) Run the command "sudo /Volumes/memstick/efi/enable.sh" 5) When you reboot your Mac, when you hold down the alt key, choose rEFIt on the startup menu. Then, choose the "BOOTx64.efi from …" option If everything now goes as it should, you should see the FreeBSD loader. When the "Press enter to boot or any other key to go to loader in X seconds" (or whatever it says), press a random key. Then try to type the commands suggested by John Nielsen. Hope this helps. :) From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 15:48:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 978EDEDD; Mon, 8 Sep 2014 15:48:59 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 70F241F66; Mon, 8 Sep 2014 15:48:59 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id DA1B85A9F24; Mon, 8 Sep 2014 15:48:58 +0000 (UTC) Date: Mon, 8 Sep 2014 15:48:58 +0000 From: Brooks Davis To: Craig Rodrigues Subject: Re: make -DNO_ROOT to create chroot, problem installing into chroot with pkg Message-ID: <20140908154858.GB35236@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current Current , freebsd-pkg@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, 08 Sep 2014 15:48:59 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 07, 2014 at 04:03:59PM -0700, Craig Rodrigues wrote: > Hi, >=20 > I am using pkg 1.3.7. >=20 > I did the following as a regular user, not root: >=20 > rm -fr /tmp/package > cd /usr/src > make buildworld > make buildkernel > make -DNO_ROOT -DDB_FROM_SRC installworld DESTDIR=3D/tmp/package > make -DNO_ROOT -DDB_FROM_SRC installkernel DESTDIR=3D/tmp/package > make -DNO_ROOT -DDB_FROM_SRC distribution DESTDIR=3D/tmp/package >=20 > This created an installed world under /tmp/package >=20 > Then I did: >=20 > pkg -c /tmp/package install -y devel/kyua >=20 > I got: >=20 > pkg: chroot failed! >=20 > Then I tried the same command under sudo: >=20 > sudo pkg -c /tmp/package install -y devel/kyua >=20 > I got: >=20 > pkg: /var/db/pkg wrong user or group ownership (expected 0/0 versus actual > 818/0) >=20 > Is there a way to install packages into chroot without > being root? If you don't mind the ownership being wrong and there being a few extra +FOO files tar works. It would be great for someone to teach package to install without root and to update a METALOG file. That's not 100% of the solution, but it's a solid 80-90% solution. -- Brooks --s/l3CgOIzMHHjg/5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQNz+oACgkQXY6L6fI4GtRNUACffzeP9vzS7QmWYacey5k5lTkz 9xEAnRn3+AilINCx3AKv9GL6/UjfAljl =+qFI -----END PGP SIGNATURE----- --s/l3CgOIzMHHjg/5-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 16:33:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 289A96A8 for ; Mon, 8 Sep 2014 16:33:20 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D36951756 for ; Mon, 8 Sep 2014 16:33:19 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XR1sL-0003T6-3g for freebsd-current@freebsd.org; Mon, 08 Sep 2014 18:33:09 +0200 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Sep 2014 18:33:09 +0200 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Sep 2014 18:33:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Subject: Re: panic m_demote: m_nextpkt not NULL Date: Mon, 08 Sep 2014 09:32:56 -0700 Lines: 22 Message-ID: References: <20140905192429.GG17059@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <20140905192429.GG17059@FreeBSD.org> X-Enigmail-Version: 1.6 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, 08 Sep 2014 16:33:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/05/2014 12:24, Gleb Smirnoff wrote: > On Fri, Sep 05, 2014 at 08:38:10AM -0700, Mark Atkinson wrote: M> > r271093 GENERIC amd64. Received this panic in the tcp reassembly > code: M> Unread portion of the kernel message buffer: M> panic: > m_demote: m_nextpkt not NULL M> cpuid = 0 > > Sorry for that. Was fixed in r271123. Thank you and Jean-Sébastien for the pointer, I was able rebuild the kernel quickly on Fri with just this change and it's working fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQN2jgACgkQrDN5kXnx8yZjlgCfcIyo87hclmT7YPVws/X0DAap PK8AoKA7G9IQGO7Om0s0fXkwvzGtKZaR =HSx2 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 17:13:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA3253B4 for ; Mon, 8 Sep 2014 17:13:18 +0000 (UTC) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78B971CC9 for ; Mon, 8 Sep 2014 17:13:18 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id cm18so14526971qab.30 for ; Mon, 08 Sep 2014 10:13:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=hvMWQIVe8XIrt1q9NFWSf/7zkxjs//B9NIJv4iDmEo0=; b=H2ixqiebxwwoAjUwfGfgZ1lClyr4KYgk4DkniiQ+iQQDDlw49HyYE993F+n65tDg1U b7gCmyyB0Tp6cSDmZ/o2RSLA39ExIMV6bFZISQsf14KBJbg5MdUajUZpZJCydp9Ewxj5 ckiL6w9r7T0FyDc/XWfyHePc3TSVuc2bRRbBC/cqC8dWhhWXicRF+SoR+5HqmO9iDbY+ 7FE2TB4KsmFhhwiP1eoCPKjsQZelTRi1H8ntUhXZw5pMS3qnizaQ7906tsgyhm31j8O6 aHnJNQIetRNCZ6wA5MnHWGQ5jx7JgZQCw9rPxncLKKE/Iz2k2hC/rk96tBLLMIU/cZTe R0uQ== X-Gm-Message-State: ALoCoQlseYglRlCr6Sh0Np0j1/g4dQ616h2RMzCgvvhonCJYC/2DSW99PuLK+e7Bh5w2DfoFUdE2 X-Received: by 10.140.46.55 with SMTP id j52mr42060856qga.27.1410196018173; Mon, 08 Sep 2014 10:06:58 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Mon, 8 Sep 2014 10:06:38 -0700 (PDT) X-Originating-IP: [2620:0:1003:1007:a9d1:ae7:a174:f544] In-Reply-To: <20140908154858.GB35236@spindle.one-eyed-alien.net> References: <20140908154858.GB35236@spindle.one-eyed-alien.net> From: Julio Merino Date: Mon, 8 Sep 2014 13:06:38 -0400 X-Google-Sender-Auth: B-yQsKOtFDIrmrwa29N4_FAbpK8 Message-ID: Subject: Re: make -DNO_ROOT to create chroot, problem installing into chroot with pkg To: Brooks Davis Content-Type: text/plain; charset=UTF-8 Cc: Craig Rodrigues , freebsd-current Current , freebsd-pkg@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, 08 Sep 2014 17:13:18 -0000 On Mon, Sep 8, 2014 at 11:48 AM, Brooks Davis wrote: > > If you don't mind the ownership being wrong and there being a few extra > +FOO files tar works. It would be great for someone to teach package to > install without root and to update a METALOG file. That's not 100% of > the solution, but it's a solid 80-90% solution. (This is just my completely uninformed opinion as I don't know the internals of pkg.) There are other issues to be addressed. Teaching pkg to install without root means changing pkg to not use chroot: i.e. to make pkg be able to deal with the concept of a "destdir" for package installations. That is probably easy: just prefixing a bunch of destdir to the locations being touched. However, the tricky part here is dealing with any package-specific post-install scripts to ensure they understand destdir, which in turn means that any tools executed by the scripts must also be capable of dealing with a destdir. Also, the scripts (being potentially-untrusted code) cannot be guaranteed to behave correctly on the outside-of-the-chroot system. From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 17:15:04 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 722824CF for ; Mon, 8 Sep 2014 17:15:04 +0000 (UTC) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3731D1CDD for ; Mon, 8 Sep 2014 17:15:04 +0000 (UTC) Received: from mouf.net (swills@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id s88HEsEv034453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Sep 2014 17:14:59 GMT (envelope-from swills@mouf.net) Received: (from swills@localhost) by mouf.net (8.14.5/8.14.5/Submit) id s88HEsa5034452 for current@FreeBSD.org; Mon, 8 Sep 2014 17:14:54 GMT (envelope-from swills) Date: Mon, 8 Sep 2014 17:14:54 +0000 From: Steve Wills To: current@FreeBSD.org Subject: network hang using intel em nic Message-ID: <20140908171451.GB18604@mouf.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 (mouf.net [199.48.129.64]); Mon, 08 Sep 2014 17:14:59 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.98.1 at mouf.net X-Virus-Status: Clean 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, 08 Sep 2014 17:15:04 -0000 Hi, I've got some new hardware and have been experiencing lockups using the em driver. They seem to only happen on large downloads, smaller things like ssh and web browsing work OK. The hardware is: em0@pci0:0:25:0: class=0x020000 card=0x309f17aa chip=0x153a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection I217-LM' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf7c00000, size 131072, enabled bar [14] = type Memory, range 32, base 0xf7c3d000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0xf080, size 32, enabled I did have the vboxnet driver loaded, but tried unloading that and still saw the issue. One thing I notice is some garbage at the top of the screen when the hang happens, perhaps there's a conflict with the vesa video. (This system is Haswell, using the vga/vesa driver.) Any suggestions on how to debug? Thanks, Steve From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 17:29:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8966F89C for ; Mon, 8 Sep 2014 17:29:35 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 62EE81E1A for ; Mon, 8 Sep 2014 17:29:34 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5205547808 for ; Mon, 8 Sep 2014 17:29:27 +0000 (UTC) Message-ID: <540DE77B.2070704@freebsd.org> Date: Mon, 08 Sep 2014 13:29:31 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: network hang using intel em nic References: <20140908171451.GB18604@mouf.net> In-Reply-To: <20140908171451.GB18604@mouf.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2f2SSrPjuFSuSmS2eFCX3345hMHjvtrgk" 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, 08 Sep 2014 17:29:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2f2SSrPjuFSuSmS2eFCX3345hMHjvtrgk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-09-08 13:14, Steve Wills wrote: > Hi, >=20 > I've got some new hardware and have been experiencing lockups using the= em > driver. They seem to only happen on large downloads, smaller things lik= e ssh > and web browsing work OK. The hardware is: >=20 > em0@pci0:0:25:0: class=3D0x020000 card=3D0x309f17aa chip=3D0x153= a8086 rev=3D0x04 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Ethernet Connection I217-LM' > class =3D network > subclass =3D ethernet > bar [10] =3D type Memory, range 32, base 0xf7c00000, size 131072,= enabled > bar [14] =3D type Memory, range 32, base 0xf7c3d000, size 4096, e= nabled > bar [18] =3D type I/O Port, range 32, base 0xf080, size 32, enabl= ed >=20 > I did have the vboxnet driver loaded, but tried unloading that and stil= l saw > the issue. One thing I notice is some garbage at the top of the screen = when the > hang happens, perhaps there's a conflict with the vesa video. (This sys= tem is > Haswell, using the vga/vesa driver.) >=20 > Any suggestions on how to debug? >=20 > Thanks, > Steve > _______________________________________________ > 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 Try periodically setting dev.em.0.debug=3D1 it will dump a bunch of stats to syslog then set it self back to -1 there are also a bunch of useful stats under: dev.em.0 including things like: dev.em.0.mbuf_alloc_fail dev.em.0.watchdog_timeouts dev.em.0.mac_stats.collision_count etc that might provide some insight. I have a box with 4x of the i210 (but that shows up as igb(4)) I have one of the i217LM nics in this machine, but it is used for video production so it isn't running BSD at the moment. --=20 Allan Jude --2f2SSrPjuFSuSmS2eFCX3345hMHjvtrgk 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) iQIcBAEBAgAGBQJUDed+AAoJEJrBFpNRJZKfkaAP/0U9hD4UGOzddyjivjUvRSo+ BCpnKHG8uk9O5KjAvlDam7BdwhKETjZuHD8FzYfwVmjmNT1aPaAgxo3iW1lRxB4r mvXpLzNjXZB1+dIb2hf1QrwMW8DndBLOlY3h7U0pr7tg1csRudJYXEKazpmWTYpI oT51+ze8Hj9lcwrSIJTdQ5j0u9k5fkc3my4pj9LyuYTKXtRMB+NV59QZhnNAm1hX IwP+cs6OGEOc9aZG7Ars2UhYSngr3B/GgA9ZRRK7FLG+XbC3+LL6vaHsXrT9uRxi rQ2MLZKUDJQoZvpitjuzm6y9xbgH3Stn1vL/E2WCeCDGLF8C2O9HI30vmy7qHBV7 J3RJpMciBZa28NCWqtgWxAKfBO1fPdZz/k9Wk49WqrhryFcDJcDtKuvhdXMXlyzX q75VBbiITMkYAiXDx/t4aOLZc/ma3qOcNrqh99Zp4DV76tgpWMw9i6Scdt7kspc0 kV+dY0FmocuaH7V1idyGagEA8UFkXtlLtxuKarn18WYtkZUjWAoBBDs1L1Y+x+xF 4Uhhlq8YQKOKKGShxpXRBi1S/MLKyYfpK/vpZi9feXwso3h6b71e16/zeWxG2TB9 k61RCa4PzZLU7/XhiEGTMIdU4AsEcbG7xDAlti0GrkYQHw1qu9iBzoPcak7lFdNc AFH57XP0HYL8VZUDzNF0 =nAM5 -----END PGP SIGNATURE----- --2f2SSrPjuFSuSmS2eFCX3345hMHjvtrgk-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 18:31:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F1C9BE7; Mon, 8 Sep 2014 18:31:26 +0000 (UTC) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E450517A5; Mon, 8 Sep 2014 18:31:25 +0000 (UTC) Received: from mouf.net (swills@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id s88IVFO8035747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Sep 2014 18:31:20 GMT (envelope-from swills@mouf.net) Received: (from swills@localhost) by mouf.net (8.14.5/8.14.5/Submit) id s88IVFe8035746; Mon, 8 Sep 2014 18:31:15 GMT (envelope-from swills) Date: Mon, 8 Sep 2014 18:31:15 +0000 From: Steve Wills To: Allan Jude Subject: Re: network hang using intel em nic Message-ID: <20140908183114.GC18604@mouf.net> References: <20140908171451.GB18604@mouf.net> <540DE77B.2070704@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540DE77B.2070704@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Mon, 08 Sep 2014 18:31:21 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.98.1 at mouf.net X-Virus-Status: Clean 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: Mon, 08 Sep 2014 18:31:26 -0000 On Mon, Sep 08, 2014 at 01:29:31PM -0400, Allan Jude wrote: > > Try periodically setting dev.em.0.debug=1 > > it will dump a bunch of stats to syslog then set it self back to -1 > > there are also a bunch of useful stats under: > dev.em.0 including things like: > dev.em.0.mbuf_alloc_fail > dev.em.0.watchdog_timeouts > dev.em.0.mac_stats.collision_count > > etc > > that might provide some insight. > > I have a box with 4x of the i210 (but that shows up as igb(4)) > > I have one of the i217LM nics in this machine, but it is used for video > production so it isn't running BSD at the moment. Thanks for the suggestions, I think I may have solved it just by ensuring my kernel modules for vbox and cuse were in sync with the kernel. Steve From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 18:36:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8299016A; Mon, 8 Sep 2014 18:36:48 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 591C91820; Mon, 8 Sep 2014 18:36:48 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6D6A05A9F23; Mon, 8 Sep 2014 18:36:47 +0000 (UTC) Date: Mon, 8 Sep 2014 18:36:47 +0000 From: Brooks Davis To: Julio Merino Subject: Re: make -DNO_ROOT to create chroot, problem installing into chroot with pkg Message-ID: <20140908183647.GD35236@spindle.one-eyed-alien.net> References: <20140908154858.GB35236@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E/DnYTRukya0zdZ1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Craig Rodrigues , freebsd-current Current , freebsd-pkg@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, 08 Sep 2014 18:36:48 -0000 --E/DnYTRukya0zdZ1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 08, 2014 at 01:06:38PM -0400, Julio Merino wrote: > On Mon, Sep 8, 2014 at 11:48 AM, Brooks Davis wrote: > > > > If you don't mind the ownership being wrong and there being a few extra > > +FOO files tar works. It would be great for someone to teach package to > > install without root and to update a METALOG file. That's not 100% of > > the solution, but it's a solid 80-90% solution. >=20 > (This is just my completely uninformed opinion as I don't know the > internals of pkg.) There are other issues to be addressed. >=20 > Teaching pkg to install without root means changing pkg to not use > chroot: i.e. to make pkg be able to deal with the concept of a > "destdir" for package installations. That is probably easy: just > prefixing a bunch of destdir to the locations being touched. This should be pretty easy given that most of the process is extracting files from the tarball. > However, the tricky part here is dealing with any package-specific > post-install scripts to ensure they understand destdir, which in turn > means that any tools executed by the scripts must also be capable of > dealing with a destdir. Also, the scripts (being potentially-untrusted > code) cannot be guaranteed to behave correctly on the > outside-of-the-chroot system. I believe the majority of packages don't suffer from post-install scripts hence the suggestion that extracting in the right place without root would solve 80-90% of the problem (and probably take no more than 10% of the work). I could live with the pain of not having scripts run during install. The correct long term fix as proposed by bapt is the do anyway with most scripts in favor of common actions and if any significant scripts remain add the ability to run them on first boot. -- Brooks --E/DnYTRukya0zdZ1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQN9z4ACgkQXY6L6fI4GtTn6ACghIqbUMnugSjv0x5ahH6Yj1LG cD0AnRBkIvXDeI3RVq8dCmFGqVajFh6E =viv6 -----END PGP SIGNATURE----- --E/DnYTRukya0zdZ1-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 19:35:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EE1C8B3; Mon, 8 Sep 2014 19:35:38 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEF311F31; Mon, 8 Sep 2014 19:35:37 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id n15so7889561lbi.33 for ; Mon, 08 Sep 2014 12:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=M+E3Z+0e1IIOKcA8HBGLjLiW2e06Sa2vQJVUmoXnGes=; b=h/oyhOOKJseWa2vjgO5CO5TWCFKms2Le97/IpaH6NeIqjyHXMsXERvrixzWp1q0Cjo ok6dxlduj8h56hs1gZfvZOzl6p828YUtrRAy8PyBmvS5IXqfLoU7a3kxctEC1U+sdViZ DNr+BnpRxZ5HPASBij9YiUlkx6KIOpW0nRORJqS2PB3VBWG4Rt0UkccX+5nJygpiKReY pM9DrNNqYJIlcD428fk0UNiow70q0YjU+yjgewH0UwQcOH94EnqNBlBBZANOag+a+eba IKCnuNtiNFkEfP/4som4n4OJhyuSaltTUo2swVY622r21uCx0LkyWmQXUAL3b+ze+Lli pRrg== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr4890918laj.88.1410204935547; Mon, 08 Sep 2014 12:35:35 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Mon, 8 Sep 2014 12:35:35 -0700 (PDT) In-Reply-To: <20140908154858.GB35236@spindle.one-eyed-alien.net> References: <20140908154858.GB35236@spindle.one-eyed-alien.net> Date: Mon, 8 Sep 2014 12:35:35 -0700 X-Google-Sender-Auth: I6ZJu0C3oa6npmTwZjbRdGTy-6E Message-ID: Subject: Re: make -DNO_ROOT to create chroot, problem installing into chroot with pkg From: Craig Rodrigues To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current , freebsd-pkg@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, 08 Sep 2014 19:35:38 -0000 On Mon, Sep 8, 2014 at 8:48 AM, Brooks Davis wrote: > > If you don't mind the ownership being wrong and there being a few extra > +FOO files tar works. It would be great for someone to teach package to > install without root and to update a METALOG file. That's not 100% of > the solution, but it's a solid 80-90% solution. > > I've opened this feature request against pkg: https://github.com/freebsd/pkg/issues/1002 Please add any comments/suggestions there, since you have very valuable input. -- Craig From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 20:28:27 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D6F02F9; Mon, 8 Sep 2014 20:28:27 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C16817F0; Mon, 8 Sep 2014 20:28:26 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so6747443lam.14 for ; Mon, 08 Sep 2014 13:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=kaardGWx9llgO942CmQLZNq60BZk1Mbtq501/lNKuBc=; b=OwiUDzq3nrOdjPo2sbJ5MN6IKFe3Nj6o5/kSU6WG1ldfyNjxRLwdd7ZPZRo0O3PbWO WWkP4VwScQqBXSERCFOMnoK6jw2PBiJOEUgPH1pa5tBj/KZe6j3/A60PnXxCd+EthdFI /kxArFcQAEP1h4JnXrtwDCkWuyUGyK/S/sNCkLSQpdkYlIDnEUcfGmLP/R5J9hnVTDW9 plc5dnkAdtqQLO+YLIbKPWHBghbXSJ8o8gLW/Qq4xJ/Frs6IrKc26Pns5o2VFheRzMLy eg0EDcth1x4e/8xI4BZhqgmThXeq22upNEzjXh9hai2YyqVPOwuDWRHs+z38gymP8fpf oAEw== MIME-Version: 1.0 X-Received: by 10.112.14.33 with SMTP id m1mr30164019lbc.16.1410208104122; Mon, 08 Sep 2014 13:28:24 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.58.164 with HTTP; Mon, 8 Sep 2014 13:28:23 -0700 (PDT) Date: Mon, 8 Sep 2014 16:28:23 -0400 X-Google-Sender-Auth: ux8WdKMBnXOwaORB_88CXCGmcqQ Message-ID: Subject: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient From: Patrick Kelsey To: current@freebsd.org Content-Type: multipart/mixed; boundary=001a11c37b0a1b4cf9050293a9e1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil 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, 08 Sep 2014 20:28:27 -0000 --001a11c37b0a1b4cf9050293a9e1 Content-Type: text/plain; charset=UTF-8 In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the non-append, write-only path. Consequently, programs that use _ftello() (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, write-only files and that use capsicum to restrict capabilities on the associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and friends) calls on those files fail with ENOTCAPABLE due to lack of CAP_FCNTL rights. There appear to be only two affected programs in the tree - tcpdump and dhclient. This affects both CURRENT and 10-STABLE (including 10.1-PRERELEASE) tcpdump, when configured to write to capture files rotated by size, fails to rotate and captures indefinitely to the first file in the series. This can be reproduced by a command such as: tcpdump -i -C 1 -W 2 -w packets -v By inspection, dhclient will fail to trim old data from its client leases file when rewriting that file with a lesser amount of data than it currently contains. See the ftruncate() call in dhclient.c:rewrite_client_leases(). The attached patch adds CAP_FCNTL to the limited rights established for non-append, write-only files used by tcpdump and dhclient. It also restricts the fcntl rights to CAP_FCNTL_GETFL. The current need to have CAP_FCNTL rights in order to get or set the file position on non-append, write-only files is subtle. Perhaps part of the answer is to define a CAP_FSEEK right in sys/capability.h that resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in rights(4) to note the need for CAP_FCNTL when using ftell() and friends. -Patrick --001a11c37b0a1b4cf9050293a9e1 Content-Type: application/octet-stream; name="ftell_cap_rights.patch" Content-Disposition: attachment; filename="ftell_cap_rights.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hzu8nnfx0 SW5kZXg6IGNvbnRyaWIvdGNwZHVtcC90Y3BkdW1wLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29udHJpYi90 Y3BkdW1wL3RjcGR1bXAuYwkocmV2aXNpb24gMjcxMjgxKQorKysgY29udHJpYi90Y3BkdW1wL3Rj cGR1bXAuYwkod29ya2luZyBjb3B5KQpAQCAtMTU2NiwxMSArMTU2NiwxNSBAQAogCQlpZiAocCA9 PSBOVUxMKQogCQkJZXJyb3IoIiVzIiwgcGNhcF9nZXRlcnIocGQpKTsKICNpZmRlZiBfX0ZyZWVC U0RfXwotCQljYXBfcmlnaHRzX2luaXQoJnJpZ2h0cywgQ0FQX1NFRUssIENBUF9XUklURSk7CisJ CWNhcF9yaWdodHNfaW5pdCgmcmlnaHRzLCBDQVBfU0VFSywgQ0FQX0ZDTlRMLCBDQVBfV1JJVEUp OwogCQlpZiAoY2FwX3JpZ2h0c19saW1pdChmaWxlbm8ocGNhcF9kdW1wX2ZpbGUocCkpLCAmcmln aHRzKSA8IDAgJiYKIAkJICAgIGVycm5vICE9IEVOT1NZUykgewogCQkJZXJyb3IoInVuYWJsZSB0 byBsaW1pdCBkdW1wIGRlc2NyaXB0b3IiKTsKIAkJfQorCQlpZiAoY2FwX2ZjbnRsc19saW1pdChm aWxlbm8ocGNhcF9kdW1wX2ZpbGUocCkpLCBDQVBfRkNOVExfR0VURkwpIDwgMCAmJgorCQkgICAg ZXJybm8gIT0gRU5PU1lTKSB7CisJCQllcnJvcigidW5hYmxlIHRvIGxpbWl0IGR1bXAgZGVzY3Jp cHRvciBmY250bHMiKTsKKwkJfQogI2VuZGlmCiAJCWlmIChDZmxhZyAhPSAwIHx8IEdmbGFnICE9 IDApIHsKICNpZmRlZiBfX0ZyZWVCU0RfXwpAQCAtMTk5NCwxMSArMTk5OCwxNSBAQAogCQkJaWYg KGR1bXBfaW5mby0+cCA9PSBOVUxMKQogCQkJCWVycm9yKCIlcyIsIHBjYXBfZ2V0ZXJyKHBkKSk7 CiAjaWZkZWYgX19GcmVlQlNEX18KLQkJCWNhcF9yaWdodHNfaW5pdCgmcmlnaHRzLCBDQVBfU0VF SywgQ0FQX1dSSVRFKTsKKwkJCWNhcF9yaWdodHNfaW5pdCgmcmlnaHRzLCBDQVBfU0VFSywgQ0FQ X0ZDTlRMLCBDQVBfV1JJVEUpOwogCQkJaWYgKGNhcF9yaWdodHNfbGltaXQoZmlsZW5vKHBjYXBf ZHVtcF9maWxlKGR1bXBfaW5mby0+cCkpLAogCQkJICAgICZyaWdodHMpIDwgMCAmJiBlcnJubyAh PSBFTk9TWVMpIHsKIAkJCQllcnJvcigidW5hYmxlIHRvIGxpbWl0IGR1bXAgZGVzY3JpcHRvciIp OwogCQkJfQorCQkJaWYgKGNhcF9mY250bHNfbGltaXQoZmlsZW5vKHBjYXBfZHVtcF9maWxlKGR1 bXBfaW5mby0+cCkpLAorCQkJICAgIENBUF9GQ05UTF9HRVRGTCkgPCAwICYmIGVycm5vICE9IEVO T1NZUykgeworCQkJCWVycm9yKCJ1bmFibGUgdG8gbGltaXQgZHVtcCBkZXNjcmlwdG9yIGZjbnRs cyIpOworCQkJfQogI2VuZGlmCiAJCX0KIAl9CkBAIC0yMDU1LDExICsyMDYzLDE1IEBACiAJCWlm IChkdW1wX2luZm8tPnAgPT0gTlVMTCkKIAkJCWVycm9yKCIlcyIsIHBjYXBfZ2V0ZXJyKHBkKSk7 CiAjaWZkZWYgX19GcmVlQlNEX18KLQkJY2FwX3JpZ2h0c19pbml0KCZyaWdodHMsIENBUF9TRUVL LCBDQVBfV1JJVEUpOworCQljYXBfcmlnaHRzX2luaXQoJnJpZ2h0cywgQ0FQX1NFRUssIENBUF9G Q05UTCwgQ0FQX1dSSVRFKTsKIAkJaWYgKGNhcF9yaWdodHNfbGltaXQoZmlsZW5vKHBjYXBfZHVt cF9maWxlKGR1bXBfaW5mby0+cCkpLAogCQkgICAgJnJpZ2h0cykgPCAwICYmIGVycm5vICE9IEVO T1NZUykgewogCQkJZXJyb3IoInVuYWJsZSB0byBsaW1pdCBkdW1wIGRlc2NyaXB0b3IiKTsKIAkJ fQorCQlpZiAoY2FwX2ZjbnRsc19saW1pdChmaWxlbm8ocGNhcF9kdW1wX2ZpbGUoZHVtcF9pbmZv LT5wKSksCisJCSAgICBDQVBfRkNOVExfR0VURkwpIDwgMCAmJiBlcnJubyAhPSBFTk9TWVMpIHsK KwkJCWVycm9yKCJ1bmFibGUgdG8gbGltaXQgZHVtcCBkZXNjcmlwdG9yIGZjbnRscyIpOworCQl9 CiAjZW5kaWYKIAl9CiAKSW5kZXg6IHNiaW4vZGhjbGllbnQvZGhjbGllbnQuYwo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzYmluL2RoY2xpZW50L2RoY2xpZW50LmMJKHJldmlzaW9uIDI3MTI4MSkKKysrIHNiaW4v ZGhjbGllbnQvZGhjbGllbnQuYwkod29ya2luZyBjb3B5KQpAQCAtMTg0NiwxMSArMTg0NiwxNSBA QAogCQlpZiAoIWxlYXNlRmlsZSkKIAkJCWVycm9yKCJjYW4ndCBjcmVhdGUgJXM6ICVtIiwgcGF0 aF9kaGNsaWVudF9kYik7CiAJCWNhcF9yaWdodHNfaW5pdCgmcmlnaHRzLCBDQVBfRlNUQVQsIENB UF9GU1lOQywgQ0FQX0ZUUlVOQ0FURSwKLQkJICAgIENBUF9TRUVLLCBDQVBfV1JJVEUpOworCQkg ICAgQ0FQX1NFRUssIENBUF9GQ05UTCwgQ0FQX1dSSVRFKTsKIAkJaWYgKGNhcF9yaWdodHNfbGlt aXQoZmlsZW5vKGxlYXNlRmlsZSksICZyaWdodHMpIDwgMCAmJgogCQkgICAgZXJybm8gIT0gRU5P U1lTKSB7CiAJCQllcnJvcigiY2FuJ3QgbGltaXQgbGVhc2UgZGVzY3JpcHRvcjogJW0iKTsKIAkJ fQorCQlpZiAoY2FwX2ZjbnRsc19saW1pdChmaWxlbm8obGVhc2VGaWxlKSwgQ0FQX0ZDTlRMX0dF VEZMKSA8IDAgJiYKKwkJICAgIGVycm5vICE9IEVOT1NZUykgeworCQkJZXJyb3IoImNhbid0IGxp bWl0IGxlYXNlIGRlc2NyaXB0b3IgZmNudGxzOiAlbSIpOworCQl9CiAJfSBlbHNlIHsKIAkJZmZs dXNoKGxlYXNlRmlsZSk7CiAJCXJld2luZChsZWFzZUZpbGUpOwo= --001a11c37b0a1b4cf9050293a9e1-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 21:11:54 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9AD3827 for ; Mon, 8 Sep 2014 21:11:54 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E66D1D49 for ; Mon, 8 Sep 2014 21:11:53 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id v6so1761430lbi.27 for ; Mon, 08 Sep 2014 14:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ekR8K4xSDoEyykxnr01zWGUSY+vMPGLh8hBoh90oiPg=; b=k5Tlc/u/72AHsBopgXhBhQG2wiuj871Ib6wlje9J+n1zGy5WlIUnXkUi91RIiomsKg HCZPXN9b8oTeGl7BwU4IHxoAMjSWJj8QxgKgC8enaXLrj7Yqs/qYvtszdFsRzi569IIH x2j8kbnU2D458Q0r/bGi/NKzhwH+Wocx1fHWYbmuVQcqVIvxCpTJQ8wWKvwHGcnBUG/7 vWW+LiN+qpUVnxBLJeOouc5vK4zzlR61WeDH4BrXkUuqQ2oY6KmI7QXUd7dGz3LHma7j ylkdg0N326XrjmgfR51AGHFmj+B0h/tBwIlGMyAXcj54jVp+0a586NjQnqRu6eRiav6L RusQ== X-Gm-Message-State: ALoCoQmKiya0jh5nxWB7GRO124zVAqo7vAmnmlDBLcEaUphhSVjZq7Ep132R5QUAE8M1yR/ytX/9 X-Received: by 10.152.23.6 with SMTP id i6mr31616528laf.39.1410208966840; Mon, 08 Sep 2014 13:42:46 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id iq1sm3642953lac.9.2014.09.08.13.42.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 13:42:46 -0700 (PDT) Message-ID: <540E14C4.9080201@freebsd.org> Date: Tue, 09 Sep 2014 00:42:44 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Patrick Kelsey , current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: George Neville-Neil 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, 08 Sep 2014 21:11:54 -0000 On 09.09.2014 0:28, Patrick Kelsey wrote: > In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the > non-append, write-only path. Consequently, programs that use _ftello() > (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, > write-only files and that use capsicum to restrict capabilities on the > associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and > friends) calls on those files fail with ENOTCAPABLE due to lack of > CAP_FCNTL rights. There appear to be only two affected programs in the > tree - tcpdump and dhclient. This affects both CURRENT and 10-STABLE > (including 10.1-PRERELEASE) > > tcpdump, when configured to write to capture files rotated by size, > fails to rotate and captures indefinitely to the first file in the > series. This can be reproduced by a command such as: tcpdump -i > -C 1 -W 2 -w packets -v > > By inspection, dhclient will fail to trim old data from its client > leases file when rewriting that file with a lesser amount of data than > it currently contains. See the ftruncate() call in > dhclient.c:rewrite_client_leases(). > > The attached patch adds CAP_FCNTL to the limited rights established for > non-append, write-only files used by tcpdump and dhclient. It also > restricts the fcntl rights to CAP_FCNTL_GETFL. > > The current need to have CAP_FCNTL rights in order to get or set the > file position on non-append, write-only files is subtle. Perhaps part > of the answer is to define a CAP_FSEEK right in sys/capability.h that > resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in > rights(4) to note the need for CAP_FCNTL when using ftell() and friends. > > -Patrick Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(), freopen(). libc code in general use it in rpc code. According to your note, all that places are currently broken in anyway. I don't think that this read-only fcntl(F_GETFL) which doesn not modify anything deserves any special rights at all (i.e. can be just enabled by default in contrast to F_SETFL), but I am not capsicum expert. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 21:13:31 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C66029FE; Mon, 8 Sep 2014 21:13:31 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAF891D84; Mon, 8 Sep 2014 21:13:30 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id b8so6692810lan.39 for ; Mon, 08 Sep 2014 14:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jboPA95AMvrSw0D70a2hVHXkbFD3EalPXtWRsgpVf/E=; b=KNyMlhLBDQVV5JmR3A7Kcb9kvvIpQ6zACP9yi9bUBQFGeV3U4IqGGi+8iBaMl+Dnu/ AEwj7JMoNlwoMKOimVTv+oZyYVWko6S7JPk5VwJwKcN4CEfARSks+Y4MfC7JRnd5mkhH Wkw80D+J6P33buBdRGBDl7+Gv01KLabvIdc+ToBrKy6K0Njhz0xzC+kIc10SGZ20OgHA +i4yKtFv+L+zQJEs+KEsa40uS28CBliYEm3PH+rJpAnmWY2z4xDowo3mDBN5UvLJ7S9W 0oV/TOHzP+1MEumdAyp6QAP/TGaynoOklkqOSDobUwzICPQWlbNPPibR5FVfn09JQEM4 k9tQ== MIME-Version: 1.0 X-Received: by 10.152.18.199 with SMTP id y7mr16998706lad.0.1410210808641; Mon, 08 Sep 2014 14:13:28 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.58.164 with HTTP; Mon, 8 Sep 2014 14:13:28 -0700 (PDT) In-Reply-To: <540E14C4.9080201@freebsd.org> References: <540E14C4.9080201@freebsd.org> Date: Mon, 8 Sep 2014 17:13:28 -0400 X-Google-Sender-Auth: l4CvN6VbkxH8zev8ify5x4wum50 Message-ID: Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient From: Patrick Kelsey To: Andrey Chernov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , 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, 08 Sep 2014 21:13:31 -0000 On Mon, Sep 8, 2014 at 4:42 PM, Andrey Chernov wrote: > On 09.09.2014 0:28, Patrick Kelsey wrote: > > In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the > > non-append, write-only path. Consequently, programs that use _ftello() > > (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, > > write-only files and that use capsicum to restrict capabilities on the > > associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and > > friends) calls on those files fail with ENOTCAPABLE due to lack of > > CAP_FCNTL rights. There appear to be only two affected programs in the > > tree - tcpdump and dhclient. This affects both CURRENT and 10-STABLE > > (including 10.1-PRERELEASE) > > > > tcpdump, when configured to write to capture files rotated by size, > > fails to rotate and captures indefinitely to the first file in the > > series. This can be reproduced by a command such as: tcpdump -i > > -C 1 -W 2 -w packets -v > > > > By inspection, dhclient will fail to trim old data from its client > > leases file when rewriting that file with a lesser amount of data than > > it currently contains. See the ftruncate() call in > > dhclient.c:rewrite_client_leases(). > > > > The attached patch adds CAP_FCNTL to the limited rights established for > > non-append, write-only files used by tcpdump and dhclient. It also > > restricts the fcntl rights to CAP_FCNTL_GETFL. > > > > The current need to have CAP_FCNTL rights in order to get or set the > > file position on non-append, write-only files is subtle. Perhaps part > > of the answer is to define a CAP_FSEEK right in sys/capability.h that > > resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in > > rights(4) to note the need for CAP_FCNTL when using ftell() and friends. > > > > -Patrick > > Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(), > freopen(). libc code in general use it in rpc code. According to your > note, all that places are currently broken in anyway. > You make a godo point about the wider use of fcntl() in libc - aside from the rpc code, by my count there are 14 other entry points in libc that use fcntl in their implementation. To experience breakage, programs that use those entry points would also have to be supplying them fds with restricted rights that do not include CAP_FCNTL. By my count, there are currently only 12 programs in -current that call cap_rights_limit(). I don't think these counts inform us very well as to the presence and extent of any capsicum+libc issues similar to the one that I've raised. Those 12 programs mentioned above would have to be audited to determine if any of the 15 libc entry points (including fcntl) that use fcntl are being used on those restricted fds without being granted CAP_FCNTL rights, and whether there are overt or potential failures occurring as a result. Consider that the failure mode in tcpdump that I found requires that you be using multiple capture files with size-based rotation, otherwise all works fine. Also consider that the failure mode in dhclient only occurs when a rewritten client lease file is smaller than its predecessor. > > I don't think that this read-only fcntl(F_GETFL) which doesn not modify > anything deserves any special rights at all (i.e. can be just enabled by > default in contrast to F_SETFL), but I am not capsicum expert. > I don't think I am in a position to comment on the implications of permanent F_GETFL rights either. I do think that the point about wider use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK right in sys/capability.h, as it would appear users of capsicum and libc are more in need of a map of capsicum rights required by libc entry points than they are of convenience #defines. -Patrick From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 21:29:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1594B1B0; Mon, 8 Sep 2014 21:29:26 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E24F51EFF; Mon, 8 Sep 2014 21:29:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6C4B3217; Mon, 8 Sep 2014 21:29:26 +0000 (UTC) Date: Mon, 8 Sep 2014 21:29:25 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <333376879.0.1410211766131.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1411 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD 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: Mon, 08 Sep 2014 21:29:26 -0000 See ------------------------------------------ Started by an SCM change Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace Updating svn://svn.freebsd.org/base/head at revision '2014-09-08T21:28:38.587 +0000' U contrib/libc-vis/vis.c U contrib/libc-vis A contrib/llvm/patches/patch-r271282-clang-r200797-r200798-r200805-debug-info-crash.diff U contrib/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp U sys/boot/arm/uboot/help.uboot U sys/boot/uboot/common/main.c U sys/dev/ixgbe/ixgbe.c U sys/dev/ixgbe/ixv.c U crypto/heimdal/tools/krb5-config.in At revision 271289 hudson.util.IOException2: revision check failed on svn://svn.freebsd.org/base/head at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:178) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:113) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:654) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:815) at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530) at hudson.model.Run.execute(Run.java:1732) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: org.tmatesoft.svn.core.SVNException: svn: E210003: connection refused by the server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:85) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:69) at org.tmatesoft.svn.core.internal.io.svn.SVNPlainConnector.open(SVNPlainConnector.java:62) at org.tmatesoft.svn.core.internal.io.svn.SVNConnection.open(SVNConnection.java:77) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.openConnection(SVNRepositoryImpl.java:1252) at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.getLatestRevision(SVNRepositoryImpl.java:168) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:166) ... 11 more Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:546) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.connect(SVNSocketFactory.java:146) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:73) at org.tmatesoft.svn.core.internal.io.svn.SVNPlainConnector.open(SVNPlainConnector.java:53) ... 25 more From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 22:00:16 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520AFDEA for ; Mon, 8 Sep 2014 22:00:16 +0000 (UTC) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C87671364 for ; Mon, 8 Sep 2014 22:00:15 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so6855190lbv.14 for ; Mon, 08 Sep 2014 15:00:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=acFEZbNPLuwSnOHeMdXHr179bSYY0+PA+BJi8KElmaU=; b=dz7yioftksLUccjymM+E3nUvxwkBskkCoBJ8vjgLnkO4SqRvhlU5anoiuCP2aWBGOV mYLxctr39LOX9S5JLL1z70t2hqornl58JxoHZhHVfXOr2OD4JawN7cq9njhdHn/tJ6c1 SPDFdVmzdyBFgwgmef4zYDlGHCdAqG5AQIg/BYrh9uRWJMLlqCg48j5xRyVaYIJuMXLk KBtDwXV1uRwkkggOkITJm6LCxb5F7qf12lIcr5Uj5yndzb5pOKCISUDAHchMWBSYKmPs 6V4DfVRdiiZBHtRR51JEfXjy6n9db+rvgvoocutPdnhPed7Z57eLVdwWLOwtQC/ljbGQ K1fQ== X-Gm-Message-State: ALoCoQkQtimLt9vchbaPWygM4o8H7UYqxXUJlTZwJeAb6PJA3n+kVa0wGIYySNqSkWy0/aqWZQ0R X-Received: by 10.152.21.42 with SMTP id s10mr32190277lae.61.1410213607613; Mon, 08 Sep 2014 15:00:07 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id os7sm3909007lbb.42.2014.09.08.15.00.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 15:00:07 -0700 (PDT) Message-ID: <540E26E6.5070700@freebsd.org> Date: Tue, 09 Sep 2014 02:00:06 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Patrick Kelsey Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: <540E14C4.9080201@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , 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, 08 Sep 2014 22:00:16 -0000 On 09.09.2014 1:13, Patrick Kelsey wrote: > You make a godo point about the wider use of fcntl() in libc - aside > from the rpc code, by my count there are 14 other entry points in libc > that use fcntl in their implementation. To experience breakage, > programs that use those entry points would also have to be supplying > them fds with restricted rights that do not include CAP_FCNTL. By my > count, there are currently only 12 programs in -current that call > cap_rights_limit(). I don't think these counts inform us very well as > to the presence and extent of any capsicum+libc issues similar to the > one that I've raised. Those 12 programs mentioned above would have to > be audited to determine if any of the 15 libc entry points (including > fcntl) that use fcntl are being used on those restricted fds without > being granted CAP_FCNTL rights, and whether there are overt or potential > failures occurring as a result. Consider that the failure mode in > tcpdump that I found requires that you be using multiple capture files > with size-based rotation, otherwise all works fine. Also consider that > the failure mode in dhclient only occurs when a rewritten client lease > file is smaller than its predecessor. Just to note by quick glance: tcpdump use fdopen(), so in some cases probably already broken without F_GETFL rights. openssh use fdopen(), so suspicious about F_GETFL too, but I don't traverse the order in which fdopen() and cap_rights_* there are applied. > I don't think that this read-only fcntl(F_GETFL) which doesn not modify > anything deserves any special rights at all (i.e. can be just enabled by > default in contrast to F_SETFL), but I am not capsicum expert. > > I don't think I am in a position to comment on the implications of > permanent F_GETFL rights either. I do think that the point about wider > use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK > right in sys/capability.h, as it would appear users of capsicum and libc > are more in need of a map of capsicum rights required by libc entry > points than they are of convenience #defines. Theoretically it will be possible to get rid of fcntl(F_GETFL) in fseek(), but O_APPEND flag need to be stored somewhere in that case, and stdio _flags already have all bit occupied for 16bit short. So the price will be changing size of the main stdio structure __sFILE to add new space for flags, which is undesirable I think. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 23:33:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA14623A; Mon, 8 Sep 2014 23:33:12 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9347A6D5; Mon, 8 Sep 2014 23:33:12 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lj1so4892951pab.27 for ; Mon, 08 Sep 2014 16:33: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=GyaN/nDGqIp/YKJOHkCqeBf4ynQViDu25B9P/rD03v8=; b=GMnkyKufNt3tTvsYj5bILeiv0kKft7URJqI6VsODXwCX0pQrk/Ib3lw2CU5GXwsh6u 4cToEQKSPRV3pZ845Fi3TJTu+9H0/o5iGK/pvZC9dZVyHCnkH/tQUBvZre0gPesXfR99 ZVNS30HTsDqSHYcOwMgni+9y61dAcokPuiwNjbgqBxIvDk86RE747bvn3/RIkwkr7JUb q3aJwRpwzHZzsJWoxSWP41x4KUvgQpB1RshOV19yEbojgq5FLb+67J87Wgb6/XguqSAl M+hF3uwg9ueQ+Jz/hpJGknrvOy0B7P7HfCIL5Yu3vvEqPI3duxafa6XJGTfwaGet6SnG IKFA== X-Received: by 10.70.47.42 with SMTP id a10mr12368287pdn.14.1410219192067; Mon, 08 Sep 2014 16:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.55.162 with HTTP; Mon, 8 Sep 2014 16:32:31 -0700 (PDT) In-Reply-To: <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> References: <540D444C.6090904@selasky.org> <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> From: Eric Joyner Date: Mon, 8 Sep 2014 16:32:31 -0700 Message-ID: Subject: Re: [RFC] Patch to improve TSO limitation formula in general To: Rick Macklem Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , "freebsd-net@freebsd.org" , FreeBSD Current , Scott Long , Jack F Vogel 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, 08 Sep 2014 23:33:13 -0000 Let me remove my concerns earlier in the thread -- this patch won't negatively affect any of our drivers; and the problem I mentioned with ixl would require a change somewhere further up the stack. --- - Eric Joyner On Mon, Sep 8, 2014 at 5:05 AM, Rick Macklem wrote: > Hans Petter Selasky wrote: > > On 09/06/14 00:09, Rick Macklem wrote: > > > Hans Petter Selesky wrote: > > >> On 09/05/14 23:19, Eric Joyner wrote: > > >>> There are some concerns if we use this with devices that ixl > > >>> supports: > > >>> > > >>> - The maximum fragment size is 16KB-1, which isn't a power of 2. > > >>> > > >> > > >> Hi Eric, > > >> > > >> Multiplying by powers of two are more fast, than non-powers of > > >> two. > > >> So > > >> in this case you would have to use 8KB as a maximum. > > >> > > > Well, I'm no architecture expert, but I really doubt the CPU delay > > > of a > > > non-power of 2 multiply/divide is significant related to doing > > > smaller > > > TSO segments. Long ago (as in 1970s) I did work on machines where > > > shifts > > > for power of 2 multiply/divide was preferable, but these days I > > > doubt it > > > is going to matter?? > > > > > >>> - You can't get the maximum TSO size for ixl devices by > > >>> multiplying > > >>> the > > >>> maximum number of fragments by the maximum size. > > >>> Instead the number of fragments is AFAIK unlimited, but a segment > > >>> can only > > >>> span 8 mbufs (including the [up to 3] mbufs containing the > > >>> header), > > >>> and the > > >>> maximum TSO size is 256KB. > > > > Hi, > > > > Maybe that can be a separate parameter? > > > > I see that your patch assumes that a segment can be any-length. That > > is > > not always the case. Remember there are JUMBO mbufs too. > > > I thought JUMBO mbufs were only going to be used on the receive side, > however I suppose if a packet is received into a JUMBO mbuf and then > forwarded on another interface... > > > With my patch, the maximum segment size is a separate parameter. The > > total number of TSO bytes is then not so useful. > > > Well, if you are referring to if_hw_tsomax, I'm not sure it was the > best plan to begin with. It was implemented for xen and I'm not sure > that any other driver uses it as of now. > > However... > I'm not a network/hardware guy, but it seems some devices do have > the IP_MAXPACKET limit (use the ip_len field in the ip header to > know how large the TSO segment is). There is also at least one device > (82598 chip for "ix" driver) that can handle more that IP_MAXPACKET, > so it seems appropriate to have a value that the driver can set. > > Since the maximum size of the gather list for transmit does seem to > vary a lot between devices, with several handling less than 35, it > does seem appropriate to allow drivers to specify that. > > If devices can't handle a single gather entry over a certain size, > I think that does need to be specified along with the max size of > the gather list, since the driver will need to use multiple gather > entries for a single mbuf and tcp_output() should take that into > account. > > In summary, yep, I basically agree. > > rick > ps: Who will look at your patch soon. > > > --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 Tue Sep 9 01:41:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 909C8FE; Tue, 9 Sep 2014 01:41:49 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E310912A8; Tue, 9 Sep 2014 01:22:22 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id m19so243593oag.16 for ; Mon, 08 Sep 2014 18:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xB+VZYdZV1rusA+oKhoSDx1lw6szFQWBRQy74wM71EA=; b=YG4qVEfrdfRzxkQGV4Dwf6a9eRLa272WqySACKRA+DkR283LC6SaDRfCfkgFuQTpBo ubXxaYfh+ez7EN9T1DEW4BSQjyQle+5UyKFYWJNQr6uF9i72oFEgQuDfIAY/sEqVVuxj ZHvWZxlyn4sFUJgTRMKxy7+Y0JC5v81HhaySdNLoEA2aCyFg9S16JvvXEbjEV1IONj5i KAG4RM0DKuCjU2kOcW+h35ZkONfbAkJxgG/WX4oJiJyu1D93+az3jpGl7+uMkHIQXS2V u9DN+fr04CHjoLXUruE2wExMViOPZooTJcyeSc2GkQKoOIQkgYDr1abfpsQnDuX7CatM ziEA== MIME-Version: 1.0 X-Received: by 10.60.161.71 with SMTP id xq7mr17729308oeb.1.1410225742156; Mon, 08 Sep 2014 18:22:22 -0700 (PDT) Received: by 10.182.87.33 with HTTP; Mon, 8 Sep 2014 18:22:22 -0700 (PDT) Date: Mon, 8 Sep 2014 21:22:22 -0400 Message-ID: Subject: Any recent spam that states it is from me is not. From: Joe Nosay To: FreeBSD PowerPC ML , FreeBSD Mailing List , FreeBSD Hackers , freebsd-current 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: Tue, 09 Sep 2014 01:41:49 -0000 Please check the headers and then ask me. This is for those who may assume that I do such things. From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 01:42:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C1E73D8; Tue, 9 Sep 2014 01:42:46 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB48164D; Tue, 9 Sep 2014 01:42:46 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 14669261; Tue, 9 Sep 2014 01:42:46 +0000 (UTC) Date: Tue, 9 Sep 2014 01:42:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, adrian@FreeBSD.org Message-ID: <2015903001.1.1410226965820.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <333376879.0.1410211766131.JavaMail.jenkins@jenkins-9.freebsd.org> References: <333376879.0.1410211766131.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1412 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS 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, 09 Sep 2014 01:42:46 -0000 See From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 07:48:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 685A139C; Tue, 9 Sep 2014 07:48:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 55FC4E25; Tue, 9 Sep 2014 07:48:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6227434C; Tue, 9 Sep 2014 07:48:15 +0000 (UTC) Date: Tue, 9 Sep 2014 07:48:14 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, adrian@FreeBSD.org Message-ID: <34018407.2.1410248895371.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1414 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_HEAD 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: Tue, 09 Sep 2014 07:48:15 -0000 See Changes: [kevlo] Drop frames that have larger than MCLBYTES. [adrian] Add basic RSS awareness for the UDPv6 send path. This doesn't include the same kind of userland overriding that the IPv4 path has; nor does it yet know about 2-tuple versus 4-tuple hashing. That'll come later. Differential Revision:=09https://reviews.freebsd.org/D527 Reviewed by:=09grehan [adrian] Calculate the RSS hash for outbound UDPv4 frames. Differential Revision:=09https://reviews.freebsd.org/D527 Reviewed by:=09grehan [adrian] Update the IPv4 input path to handle reassembled frames and incomi= ng frames with no RSS hash. When doing RSS: * Create a new IPv4 netisr which expects the frames to have been verified; it just directly dispatches to the IPv4 input path. * Once IPv4 reassembly is done, re-calculate the RSS hash with the new IP and L3 header; then reinject it as appropriate. * Update the IPv4 netisr to be a CPU affinity netisr with the RSS hash function (rss_soft_m2cpuid) - this will do a software hash if the hardware doesn't provide one. NICs that don't implement hardware RSS hashing will now benefit from RSS distribution - it'll inject into the correct destination netisr. Note: the netisr distribution doesn't work out of the box - netisr doesn't query RSS for how many CPUs and the affinity setup. Yes, netisr likely shouldn't really be doing CPU stuff anymore and should be "some kind of 'thing' that is a workqueue that may or may not have any CPU affinity"; that's for a later commit. Differential Revision:=09https://reviews.freebsd.org/D527 Reviewed by:=09grehan [grehan] Add a callback to be notified about negotiated features. Submitted by:=09luigi Obtained from:=09Vincenzo Maffione, Universita` di Pisa MFC after:=093 days ------------------------------------------ [...truncated 207558 lines...] --- alias_util.po --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsyste= m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-st= rings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -= Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-poin= ter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c -o alias_util.po --- kerberos5/lib__L --- --- get_c.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o get_c.So --- cddl/lib__L --- --- space_map.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I -I -I -I -I -I -I -I -DWANTS_MUTEX_OWNED -I -I -I -g -DDEBUG=3D1 -DNEED_= SOLARIS_BOOLEAN -std=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wn= o-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit= y -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -W= no-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o space_map.So --- lib__L --- --- all_subdir_libbegemot --- --- rpoll.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -DUSE_SELECT -DQUADFMT=3D'"ll"= ' -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format= -y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpo= inter-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wu= nused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -W= redundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable= -declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unu= sed-const-variable -Qunused-arguments -c -o = rpoll.So --- all_subdir_libalias --- --- alias_mod.po --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -std=3Dgnu99 -fstack-protector -Wsyste= m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-st= rings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -= Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-poin= ter-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -W= no-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c -o alias_mod.po --- kerberos5/lib__L --- --- get_princs_c.o --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgn= u99 -fstack-protector -Qunused-arguments -c -o get_princs_c.o --- lib__L --- :130:28: warning: no previous= extern declaration for non-static variable 'dll_chain' [-Wmissing-variable= -declarations] SLIST_HEAD(dll_chain, dll) dll_chain =3D SLIST_HEAD_INITIALIZER(dll_chain); ^ --- all_subdir_libbegemot --- --- rpoll.o --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -O2 -pipe -DUSE_SELECT -DQUADFMT=3D'"ll"' -std=3Dgnu= 99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno= -unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parame= ter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-de= cls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declaration= s -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Qunused-arguments -c -o rpoll.o --- all_subdir_libalias --- 1 warning generated. --- alias.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -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 alias.So --- kerberos5/lib__L --- --- get_princs_c.po --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std= =3Dgnu99 -fstack-protector -Qunused-arguments -c -o get_princs_c.po --- lib__L --- :1234:8: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] pip =3D (struct ip *)ptr; ^~~~~~~~~~~~~~~~ :1253:8: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] pip =3D (struct ip *)ptr; ^~~~~~~~~~~~~~~~ :1279:8: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] pip =3D (struct ip *)ptr; ^~~~~~~~~~~~~~~~ :1280:9: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] fpip =3D (struct ip *)ptr_fragment; ^~~~~~~~~~~~~~~~~~~~~~~~~ :1322:8: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] pip =3D (struct ip *)ptr; ^~~~~~~~~~~~~~~~ :1453:8: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] pip =3D (struct ip *)ptr; ^~~~~~~~~~~~~~~~ :1546:8: warning: cast from 'char= *' to 'struct ip *' increases required alignment from 1 to 4 [-Wcast-align= ] pip =3D (struct ip *)ptr; ^~~~~~~~~~~~~~~~ --- all_subdir_libbegemot --- --- libbegemot_p.a --- building profiled begemot library --- cddl/lib__L --- --- space_reftree.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I -I -I -I -I -I -I -I -DWANTS_MUTEX_OWNED -I -I -I -g -DDEBUG=3D1 -DNEED_= SOLARIS_BOOLEAN -std=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wn= o-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit= y -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -W= no-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o space_ref= tree.So --- lib__L --- ranlib -D libbegemot_p.a --- libbegemot.so.4 --- building shared library libbegemot.so.4 --- libbegemot.a --- building static begemot library ranlib -D libbegemot.a --- kerberos5/lib__L --- --- get_princs_c.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o get_princs_c.So --- lib__L --- --- all_subdir_libblocksruntime --- =3D=3D=3D> lib/libblocksruntime (all) --- cddl/lib__L --- --- txg.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I -I -I -I -I -I -I -I -DWANTS_MUTEX_OWNED -I -I -I -g -DDEBUG=3D1 -DNEED_= SOLARIS_BOOLEAN -std=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wn= o-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit= y -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -W= no-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o txg.So --- lib__L --- --- all_subdir_libalias --- 7 warnings generated. --- all_subdir_libblocksruntime --- --- data.po --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -I -std=3Dgnu99 -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -Qunused-arguments -c -o data.po --- all_subdir_libalias --- --- alias_db.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -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 alias_db.So --- all_subdir_libblocksruntime --- --- runtime.po --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -I -std=3Dgnu99 -fstack-protector -= Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-point= er-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wn= o-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unu= sed-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-pro= moted-parameter -Qunused-arguments -c -o runtime.po --- kerberos5/lib__L --- --- init_c.o --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgn= u99 -fstack-protector -Qunused-arguments -c -o init_c.o --- lib__L --- --- all_subdir_libalias --- :2666:22: warning: cast from '= ipfw_insn *' (aka 'struct _ipfw_insn *') to 'ipfw_insn_ip *' (aka 'struct _= ipfw_insn_ip *') increases required alignment from 2 to 4 [-Wcast-align] ipfw_insn_ip *cmd =3D (ipfw_insn_ip *) cmd1; ^~~~~~~~~~~~~~~~~~~~~ :2698:18: warning: cast from '= ipfw_insn *' (aka 'struct _ipfw_insn *') to 'u_int32_t *' (aka 'unsigned in= t *') increases required alignment from 2 to 4 [-Wcast-align] rule->act_ofs =3D (u_int32_t *) cmd - (u_int32_t *) rule->cmd; ^~~~~~~~~~~~~~~~~ :2698:38: warning: cast from '= ipfw_insn *' (aka 'struct _ipfw_insn *') to 'u_int32_t *' (aka 'unsigned in= t *') increases required alignment from 2 to 4 [-Wcast-align] rule->act_ofs =3D (u_int32_t *) cmd - (u_int32_t *) rule->cmd; ^~~~~~~~~~~~~~~~~~~~~~~ :2701:18: warning: cast from '= ipfw_insn *' (aka 'struct _ipfw_insn *') to 'u_int32_t *' (aka 'unsigned in= t *') increases required alignment from 2 to 4 [-Wcast-align] rule->cmd_len =3D (u_int32_t *) cmd - (u_int32_t *) rule->cmd; ^~~~~~~~~~~~~~~~~ :2701:38: warning: cast from '= ipfw_insn *' (aka 'struct _ipfw_insn *') to 'u_int32_t *' (aka 'unsigned in= t *') increases required alignment from 2 to 4 [-Wcast-align] rule->cmd_len =3D (u_int32_t *) cmd - (u_int32_t *) rule->cmd; ^~~~~~~~~~~~~~~~~~~~~~~ --- all_subdir_libblocksruntime --- --- data.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-pro= tector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Qunused-arguments -c -o data.So --- runtime.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fstack-pro= tector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Qunused-arguments -c -o runtime.So --- kerberos5/lib__L --- --- init_c.po --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std= =3Dgnu99 -fstack-protector -Qunused-arguments -c -o init_c.po --- lib__L --- --- data.o --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-ta= utological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-= function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promote= d-parameter -Qunused-arguments -c -o data.o --- cddl/lib__L --- --- uberblock.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I -I -I -I -I -I -I -I -DWANTS_MUTEX_OWNED -I -I -I -g -DDEBUG=3D1 -DNEED_= SOLARIS_BOOLEAN -std=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wn= o-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit= y -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -W= no-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o uberblock.So --- lib__L --- --- runtime.o --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -O2 -pipe -I -std=3Dgnu99 -fstack-protector -Wsys= tem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-ta= utological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-= function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promote= d-parameter -Qunused-arguments -c -o runtime.o --- all_subdir_libalias --- 5 warnings generated. --- alias_proxy.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -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 alias_proxy.So --- all_subdir_libblocksruntime --- --- libBlocksRuntime_p.a --- building profiled BlocksRuntime library --- cddl/lib__L --- --- unique.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I -I -I -I -I -I -I -I -DWANTS_MUTEX_OWNED -I -I -I -g -DDEBUG=3D1 -DNEED_= SOLARIS_BOOLEAN -std=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wn= o-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-va= riable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit= y -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -W= no-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c -o unique.So --- kerberos5/lib__L --- --- init_c.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I. -DHAVE_CONFIG_H -I -std=3Dgnu99 -fstack-protector -Qunused-arguments -c -o init_c.So --- lib__L --- --- all_subdir_libalias --- :426:10: warning: cast from= 'u_char *' (aka 'unsigned char *') to 'u_short *' (aka 'unsigned short *')= increases required alignment from 1 to 2 [-Wcast-align] sptr =3D (u_short *) option; ^~~~~~~~~~~~~~~~~~ --- all_subdir_libblocksruntime --- ranlib -D libBlocksRuntime_p.a --- libBlocksRuntime.so.0 --- building shared library libBlocksRuntime.so.0 --- libBlocksRuntime.a --- building static BlocksRuntime library --- all_subdir_libalias --- 1 warning generated. --- all_subdir_libblocksruntime --- ranlib -D libBlocksRuntime.a --- all_subdir_libalias --- --- alias_util.So --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -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 alias_util.So --- cddl/lib__L --- --- vdev.So --- --- lib__L --- --- all_subdir_libbluetooth --- --- cddl/lib__L --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -I -I -I -I -I -I -I -I -I -I lib__L --- =3D=3D=3D> lib/libbluetooth (all) --- cddl/lib__L --- libzpool/../../lib/libumem -I -DWAN= TS_MUTEX_OWNED -I -I -I -g -DDEBUG=3D1 -DNEED_SOLARIS= _BOOLEAN -std=3Diso9899:1999 -fstack-protector -Wno-pointer-sign -Wno-unkno= wn-pragmas -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-switch -Wno-switch-enum -Wno-knr-= promoted-parameter -Wno-parentheses -Qunused-arguments -c -o vdev.So --- lib__L --- --- bluetooth.po --- --- all_subdir_libalias --- --- alias_mod.So --- --- all_subdir_libbluetooth --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -pg -O2 -pipe -I -I -std=3Dgnu99 -fstack-pro= tector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -W= no-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-vari= able -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno= -knr-promoted-parameter -Qunused-arguments -c -o bluetooth.po --- kerberos5/lib__L --- --- kadm5_err.o --- --- lib__L --- --- all_subdir_libalias --- cc -m32 -march=3Di686 -mmmx -msse -msse2 -DCOMPAT_32BIT -isystem /usr/obj<= https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib32/usr/include/>= -L/usr/obj -B/usr/obj -fpic -DPIC -O2 -pipe -std=3Dgnu99 -fstack-protector= -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -W= write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subs= cripts -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 alias_mod.So --- kerberos5/lib__L --- Cannot open "/lib/libedit.so.7" *** [kadm5_err.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 --- lib__L --- :130:28: warning: no previous= extern declaration for non-static variable 'dll_chain' [-Wmissing-variable= -declarations] SLIST_HEAD(dll_chain, dll) dll_chain =3D SLIST_HEAD_INITIALIZER(dll_chain); ^ 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 *** [all_subdir_libalias] Error code 2 make[4]: stopped in --- all_subdir_libbluetooth --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_libbluetooth] Error code 2 make[4]: stopped in 2 errors make[4]: stopped in --- cddl/lib__L --- 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 A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [build32] 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 Sep 9 08:57:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19AAF5F7; Tue, 9 Sep 2014 08:57:21 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id EF6976E1; Tue, 9 Sep 2014 08:57:20 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0231F86; Tue, 9 Sep 2014 08:57:20 +0000 (UTC) Date: Tue, 9 Sep 2014 08:57:20 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1009616638.0.1410253040788.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <34018407.2.1410248895371.JavaMail.jenkins@jenkins-9.freebsd.org> References: <34018407.2.1410248895371.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1415 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD 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: Tue, 09 Sep 2014 08:57:21 -0000 See ------------------------------------------ Started by user rodrigc Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace java.io.IOException: remote file operation failed: at hudson.remoting.Channel@7f30f143:jenkins-10.freebsd.org at hudson.FilePath.act(FilePath.java:918) at hudson.FilePath.act(FilePath.java:895) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786) at hudson.model.AbstractProject.checkout(AbstractProject.java:1254) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.remoting.Channel.call(Channel.java:748) at hudson.FilePath.act(FilePath.java:911) ... 11 more Caused by: java.lang.UnsatisfiedLinkError: no net in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709) at java.lang.Runtime.loadLibrary0(Runtime.java:844) at java.lang.System.loadLibrary(System.java:1051) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47) at java.security.AccessController.doPrivileged(Native Method) at sun.nio.ch.Util.load(Util.java:356) at sun.nio.ch.FileChannelImpl.(FileChannelImpl.java:1273) at java.io.RandomAccessFile.getChannel(RandomAccessFile.java:273) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFile.(SqlJetFile.java:181) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileSystem.open(SqlJetFileSystem.java:193) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.open(SqlJetPager.java:395) at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.open(SqlJetBtree.java:325) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.open(SqlJetEngine.java:195) at org.tmatesoft.sqljet.core.table.SqlJetDb.open(SqlJetDb.java:127) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.open(SVNSqlJetDb.java:114) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.openDb(SVNWCDb.java:3585) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1462) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.detectWcGeneration(SvnOperationFactory.java:1643) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.getImplementation(SvnOperationFactory.java:1307) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1227) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2423) at hudson.scm.subversion.UpdateUpdater$TaskImpl.parseSvnInfo(UpdateUpdater.java:125) at hudson.scm.subversion.UpdateUpdater$TaskImpl.getSvnCommandToUse(UpdateUpdater.java:87) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:130) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2492) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 08:58:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DC71848; Tue, 9 Sep 2014 08:58:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 6B51974F; Tue, 9 Sep 2014 08:58:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8D8F787; Tue, 9 Sep 2014 08:58:40 +0000 (UTC) Date: Tue, 9 Sep 2014 08:58:40 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1468344772.1.1410253120572.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1009616638.0.1410253040788.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1009616638.0.1410253040788.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1416 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD 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: Tue, 09 Sep 2014 08:58:40 -0000 See ------------------------------------------ Started by user rodrigc Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace java.io.IOException: remote file operation failed: at hudson.remoting.Channel@7f30f143:jenkins-10.freebsd.org at hudson.FilePath.act(FilePath.java:918) at hudson.FilePath.act(FilePath.java:895) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786) at hudson.model.AbstractProject.checkout(AbstractProject.java:1254) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.remoting.Channel.call(Channel.java:748) at hudson.FilePath.act(FilePath.java:911) ... 11 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class sun.nio.ch.FileChannelImpl at java.io.RandomAccessFile.getChannel(RandomAccessFile.java:273) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFile.(SqlJetFile.java:181) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileSystem.open(SqlJetFileSystem.java:193) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.open(SqlJetPager.java:395) at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.open(SqlJetBtree.java:325) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.open(SqlJetEngine.java:195) at org.tmatesoft.sqljet.core.table.SqlJetDb.open(SqlJetDb.java:127) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.open(SVNSqlJetDb.java:114) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.openDb(SVNWCDb.java:3585) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1462) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.detectWcGeneration(SvnOperationFactory.java:1643) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.getImplementation(SvnOperationFactory.java:1307) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1227) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2423) at hudson.scm.subversion.UpdateUpdater$TaskImpl.parseSvnInfo(UpdateUpdater.java:125) at hudson.scm.subversion.UpdateUpdater$TaskImpl.getSvnCommandToUse(UpdateUpdater.java:87) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:130) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2492) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 08:59:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F32A4963; Tue, 9 Sep 2014 08:59:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D65AC765; Tue, 9 Sep 2014 08:59:45 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0E43E88; Tue, 9 Sep 2014 08:59:46 +0000 (UTC) Date: Tue, 9 Sep 2014 08:59:45 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, adrian@FreeBSD.org Message-ID: <1298341391.2.1410253186051.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1468344772.1.1410253120572.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1468344772.1.1410253120572.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #1417 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD 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: Tue, 09 Sep 2014 08:59:46 -0000 See ------------------------------------------ Started by user rodrigc Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace java.io.IOException: remote file operation failed: at hudson.remoting.Channel@7f30f143:jenkins-10.freebsd.org at hudson.FilePath.act(FilePath.java:918) at hudson.FilePath.act(FilePath.java:895) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:848) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:786) at hudson.model.AbstractProject.checkout(AbstractProject.java:1254) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.remoting.Channel.call(Channel.java:748) at hudson.FilePath.act(FilePath.java:911) ... 11 more Caused by: java.lang.NoClassDefFoundError: Could not initialize class sun.nio.ch.FileChannelImpl at java.io.RandomAccessFile.getChannel(RandomAccessFile.java:273) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFile.(SqlJetFile.java:181) at org.tmatesoft.sqljet.core.internal.fs.SqlJetFileSystem.open(SqlJetFileSystem.java:193) at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.open(SqlJetPager.java:395) at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.open(SqlJetBtree.java:325) at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.open(SqlJetEngine.java:195) at org.tmatesoft.sqljet.core.table.SqlJetDb.open(SqlJetDb.java:127) at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.open(SVNSqlJetDb.java:114) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.openDb(SVNWCDb.java:3585) at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1462) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.detectWcGeneration(SvnOperationFactory.java:1643) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.getImplementation(SvnOperationFactory.java:1307) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1227) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2423) at hudson.scm.subversion.UpdateUpdater$TaskImpl.parseSvnInfo(UpdateUpdater.java:125) at hudson.scm.subversion.UpdateUpdater$TaskImpl.getSvnCommandToUse(UpdateUpdater.java:87) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:130) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2492) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 10:13:46 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60098C91; Tue, 9 Sep 2014 10:13:46 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B17DCEB6; Tue, 9 Sep 2014 10:13:45 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id u10so1992953lbd.1 for ; Tue, 09 Sep 2014 03:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=m2FKsg6E121Dg+TkIA7401URhE+G1ICTGfDLYm2Buqo=; b=SNEu+BJ5qcXOPLxlfk2A8hN/x1wz4D1qtRrPV3V5usjiFS0rBN635wmnSkmhgpDzr3 zvdOHPcUJoATb2L4bAXXJs+UU0Q80Dk4vmZNq2h02GhocsnG7KZmKn+WXE2hqadAms1H CYHJt3KoLu9eFvf8G8X1zL13olsrk5gw+mAyqT6b5v2HOmdYwdFRq28R5k58k+0NMqcT rVMmcNwX+3EB6SHROTK9opDa/9OqITLSjmUbO7M+fwWJPxc9rp3tnKCdFkzGSFXIIYN1 1yxBn09f+qS+BpJRgJdRoeTYnXTfUdMzsNqXBPVAUtEV9qd5tOA6afJFJMzR03GIpbNZ S+iQ== MIME-Version: 1.0 X-Received: by 10.152.42.136 with SMTP id o8mr3845300lal.71.1410257622956; Tue, 09 Sep 2014 03:13:42 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 9 Sep 2014 03:13:42 -0700 (PDT) Date: Tue, 9 Sep 2014 12:13:42 +0200 X-Google-Sender-Auth: HDOzditjs0cTwLo34WbzWQtqKIQ Message-ID: Subject: RFC: please put back spare fields in struct ifnet (removed in svn 270870) From: Luigi Rizzo To: FreeBSD Current , Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , Stefano Garzarella 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, 09 Sep 2014 10:13:46 -0000 hi, sorry if i just noticed it recently. svn 270870 removed all the if_*spare fields in struct ifnet. They are replaced with the following comment /* * Spare fields to be added before branching a stable branch, so * that structure can be enhanced without changing the kernel * binary interface. */ =E2=80=8Bwhich leaves me a bit unhappy. Having a stable ABI is useful not only for stable branches, but also (I would say even more) with head, so people can run experimental code with limited modifications to the sources. Cases in point: - we used one spare field extensively when experimenting with netmap, and being able to just build a module without having to recompile the whole kernel was a big win. - we are developing some software GSO and again it was great to have the spares in the tcpcb and in the ifnet so we could limit modifications to headers used by multiple sources. I would kindly suggest to put the spares back. I can't see how they can possibly harm. thanks luigi From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 10:35:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4ADF4F2; Tue, 9 Sep 2014 10:35: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 C3AE317D; Tue, 9 Sep 2014 10:35:43 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 35FEDDE; Tue, 9 Sep 2014 10:35:44 +0000 (UTC) Date: Tue, 9 Sep 2014 10:35:43 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, kevlo@FreeBSD.org, grehan@FreeBSD.org, adrian@FreeBSD.org Message-ID: <850318537.4.1410258944197.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1298341391.2.1410253186051.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1298341391.2.1410253186051.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD #1418 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: SUCCESS 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, 09 Sep 2014 10:35:43 -0000 See From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 10:37:24 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55542636 for ; Tue, 9 Sep 2014 10:37:24 +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 C7F091B2 for ; Tue, 9 Sep 2014 10:37:22 +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 s89AbJ8f044560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Sep 2014 14:37:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s89AbJJX044559; Tue, 9 Sep 2014 14:37:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 9 Sep 2014 14:37:19 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870) Message-ID: <20140909103719.GB17059@glebius.int.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: George Neville-Neil , FreeBSD Current , Stefano Garzarella 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, 09 Sep 2014 10:37:24 -0000 Luigi, On Tue, Sep 09, 2014 at 12:13:42PM +0200, Luigi Rizzo wrote: L> svn 270870 removed all the if_*spare fields in struct ifnet. L> They are replaced with the following comment L> L> /* L> * Spare fields to be added before branching a stable branch, so L> * that structure can be enhanced without changing the kernel L> * binary interface. L> */ L> L> ​which leaves me a bit unhappy. L> Having a stable ABI is useful not only for stable branches, L> but also (I would say even more) with head, so people can L> run experimental code with limited modifications to the sources. L> L> Cases in point: L> - we used one spare field extensively when experimenting L> with netmap, and being able to just build a module without having L> to recompile the whole kernel was a big win. L> - we are developing some software GSO and again it was great to have L> the spares in the tcpcb and in the ifnet so we could limit L> modifications to headers used by multiple sources. L> L> I would kindly suggest to put the spares back. L> I can't see how they can possibly harm. The harm is obvious: someone commits code that _uses_ spare field without assigning it a new name. Spare field is a placeholder. Of course you can use it while you experiment. However, I don't see problem with patching your source tree where you experiment. The ABI plan for 'struct ifnet' is that the struct becomes opaque for device drivers. So its size and alignment no longer matters. Those who want to add new fields to struct ifnet, would also need to add accessor methods. Bits of this plan are already committed by Marcel, but its only first step. I'm afraid that if fields are there back, the situation that happened with netmap (use of spare field) would repeat. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 11:01:17 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0047287; Tue, 9 Sep 2014 11:01:16 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39CE96E6; Tue, 9 Sep 2014 11:01:16 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id b17so19073911lan.22 for ; Tue, 09 Sep 2014 04:01: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=9MUqWfJJuxSQU/+IGUvDsJ/qX3Cj2/2bnC2WI3r/sns=; b=HdGEW46viOfcM+NFP/P7D6I+2WxfiJeQhfkcsZ5DCUxkFXiQIY3i0YXUhIjKTpW42J vheusx9JPa1EMDWHse03R58JanMxNsFkrAY+C8PPGA9V5QGDUA3gOVRgr+h5KVweQTQc 2ZxsJ9C5tKphdEAH3KXGWe9SFJ+qswQWvl35P7B0tehJ0QXeKIHW9HHfHDwQKooxMNDl q8DJidy6lf/bHKBfBGp2HJVxQu/Y3T138W50F2E4Yhe4kq4m0rRhY9z3GMTbdWkPgN7X L/Fb1Cw0oEJsveEZhciD4l7+fW8zg/kbM56bRaW0ycwMAx+2Wr/P8uVZE+1X7mNx/gEh tC8A== MIME-Version: 1.0 X-Received: by 10.112.130.101 with SMTP id od5mr33254511lbb.76.1410260473970; Tue, 09 Sep 2014 04:01:13 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 9 Sep 2014 04:01:13 -0700 (PDT) In-Reply-To: <20140909103719.GB17059@glebius.int.ru> References: <20140909103719.GB17059@glebius.int.ru> Date: Tue, 9 Sep 2014 13:01:13 +0200 X-Google-Sender-Auth: 51kn4HFxsS9QR60eJGrxZ4E5LyI Message-ID: Subject: Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870) From: Luigi Rizzo To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , FreeBSD Current , Stefano Garzarella 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, 09 Sep 2014 11:01:17 -0000 On Tue, Sep 9, 2014 at 12:37 PM, Gleb Smirnoff wrote: > Luigi, > > On Tue, Sep 09, 2014 at 12:13:42PM +0200, Luigi Rizzo wrote: > L> svn 270870 removed all the if_*spare fields in struct ifnet. > L> They are replaced with the following comment > L> > L> /* > L> * Spare fields to be added before branching a stable branch, so > L> * that structure can be enhanced without changing the kernel > L> * binary interface. > L> */ > L> > L> =E2=80=8Bwhich leaves me a bit unhappy. > L> Having a stable ABI is useful not only for stable branches, > L> but also (I would say even more) with head, so people can > L> run experimental code with limited modifications to the sources. > L> > L> Cases in point: > L> - we used one spare field extensively when experimenting > L> with netmap, and being able to just build a module without having > L> to recompile the whole kernel was a big win. > L> - we are developing some software GSO and again it was great to have > L> the spares in the tcpcb and in the ifnet so we could limit > L> modifications to headers used by multiple sources. > L> > L> I would kindly suggest to put the spares back. > L> I can't see how they can possibly harm. > > The harm is obvious: someone commits code that _uses_ spare field > without assigning it a new name. Spare field is a placeholder. Of > course you can use it while you experiment. However, I don't see > problem with patching your source tree where you experiment. > The problem with _not_ having spares is that you have to recompile everything after patching the headers. With the spares, i could make netmap a simple add-on kernel module with no dependencies. Same on linux for what matters (there wasn't a spare there, but nobody used ax25 and i could check and reuse it). Of course you can easily emulate extension fields for stuff that is not accessed frequently (tough a version number would help), but there are cases when you do need the extra info on a per-packet basis. > The ABI plan for 'struct ifnet' is that the struct becomes > opaque for device drivers. So its size and alignment no longer > matters. Those who want to add new fields to struct ifnet, > would also need to add accessor methods. Bits of this plan > are already committed by Marcel, but its only first step. > =E2=80=8Bspare fields <-> spare accessors=E2=80=8B > I'm afraid that if fields are there back, the situation that > happened with netmap (use of spare field) would repeat. > =E2=80=8Bthe spare pointer used by netmap was clearly indicated by a commen= t, and giving it a dedicated name instead of if_pspare[0] was expected to happen (hopefully together with a __FreeBSD_version bump, which has not happened). I am not worried that the name change was missed when deleting if_pspare[]. Mistakes happen and the error was promptly corrected (apart from the version bump). What worries me is losing some flexibility in dealing with out-of-tree kernel modules. =E2=80=8Bcheers luigi=E2=80=8B From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 11:49:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A203F7BA; Tue, 9 Sep 2014 11:49:23 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 56A67D62; Tue, 9 Sep 2014 11:49:23 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XRJv8-003DHv-DW>; Tue, 09 Sep 2014 13:49:14 +0200 Received: from f052132099.adsl.alicedsl.de ([78.52.132.99] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XRJv8-001ui9-9l>; Tue, 09 Sep 2014 13:49:14 +0200 Date: Tue, 9 Sep 2014 13:49:08 +0200 From: "O. Hartmann" To: FreeBSD Ports , FreeBSD CURRENT Subject: Re: [Bug 144203] textproc/refdb: network clients loop indefinitely when hitting Ctrl-D while client asks for passowrd Message-ID: <20140909134908.6d4cfc03.ohartman@zedat.fu-berlin.de> In-Reply-To: References: Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/.g6gqMSwNY8IhohOw9/_AIJ"; protocol="application/pgp-signature" X-Originating-IP: 78.52.132.99 X-ZEDAT-Hint: A Cc: marino@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, 09 Sep 2014 11:49:23 -0000 --Sig_/.g6gqMSwNY8IhohOw9/_AIJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 09 Sep 2014 06:35:29 +0000 bugzilla-noreply@freebsd.org schrieb: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D144203 >=20 > --- Comment #8 from John Marino --- > FYI, I'm removing this port tonight. We've waited long enough. >=20 In the strain of a bug I reported I also tried to fix this port, since the = prior maintainer seems to have abandonded this great port. I'm a bit pissed off about the rude tune I feel treated! The developer has patched the original sources to meet some FreeBSD require= ments regarding a readline issue now fixed and especially some serious bugs in bi= b2ris and a transforming/migrating tool using UTF-8 encodings for LaTeX codings. Since = not all patches are 100% tested (but they work graeat for me in a scientific enviro= nment), the upstream developer hestiates creating the new tarball.=20 As I documented with this PR, I'm wating for the developer to publish a new tarball. I spent lot of time to provide a workaround for fixing the lack of the new = tarball and some serious previously unresolved FreeBSD issues and the time I sacrificed= is not only "working time"! I mention this since I'm feeling put under pressure as the = note sent to me documents. What is the policy of FreeBSD's port system? There are lots of ports waitin= g to be fixed since they have serious issue, like silc-toolkit. Is this port also about t= o be deleted or isn't there a "lobby" preventing this? In a hurry, to prevent the destruction of the port textproc/refdb, I provid= ed a patch. The patch is a bit messy since I had to incorporate all changes made in the= meanwhile after creation of refdb-1.0.2.tar.gz (provided at: http://sourceforge.net/projects/refdb/files/latest/download).=20 Please see PR "Bug 193484 - [textproc/refdb] Update port". With regards, oh --Sig_/.g6gqMSwNY8IhohOw9/_AIJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUDuk5AAoJEOgBcD7A/5N8x5kH/iSz6SOmFojIWsSCQiq/pJlS HMlRZ5iGY2tx8UItUP1a8JChxyFZx+me52HPduJX12J+voCTWHJD+bOreSQvn9f5 VB2t8PkxRZ0RfQCZgagFDWk6ApI5Bg/Uo/xtfJojeFFEqKTnNt9AQoCqqky/xFWL icuR4wo0i4cThPevHZ4vHwceG158rjmYXNvL9p5MNyGh4zjBdDCnbSfaPrCEjJmd 3FN20OE6EN1/Skd5lwcYq72LNZUFCuEFktfo12q2cyOHtMG44dANcsWStJf/Yykn 4qI3vWsCl/oqsCptErI0SIC2iclmypo6zIN8UZn/cQLBAMtmvZCcElydZ/Bp8x0= =tEoM -----END PGP SIGNATURE----- --Sig_/.g6gqMSwNY8IhohOw9/_AIJ-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 12:17:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B66A11E9 for ; Tue, 9 Sep 2014 12:17:19 +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 2C508104 for ; Tue, 9 Sep 2014 12:17:18 +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 s89CH9LR045055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Sep 2014 16:17:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s89CH8FJ045054; Tue, 9 Sep 2014 16:17:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 9 Sep 2014 16:17:08 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870) Message-ID: <20140909121708.GE17059@glebius.int.ru> References: <20140909103719.GB17059@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: George Neville-Neil , FreeBSD Current , Stefano Garzarella 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, 09 Sep 2014 12:17:19 -0000 Luigi, On Tue, Sep 09, 2014 at 01:01:13PM +0200, Luigi Rizzo wrote: L> > The harm is obvious: someone commits code that _uses_ spare field L> > without assigning it a new name. Spare field is a placeholder. Of L> > course you can use it while you experiment. However, I don't see L> > problem with patching your source tree where you experiment. L> L> The problem with _not_ having spares is that you have to recompile L> everything after patching the headers. With the spares, i could L> make netmap a simple add-on kernel module with no dependencies. L> Same on linux for what matters (there wasn't a spare there, but L> nobody used ax25 and i could check and reuse it). What if another kernel hacker comes and also uses if_pspare[0] for his own super-duper feature? What would you do, if then a user reports that enabling netmap on his box instapanics if he had some other feature turned on? L> > The ABI plan for 'struct ifnet' is that the struct becomes L> > opaque for device drivers. So its size and alignment no longer L> > matters. Those who want to add new fields to struct ifnet, L> > would also need to add accessor methods. Bits of this plan L> > are already committed by Marcel, but its only first step. L> L> ​spare fields <-> spare accessors​ Let me repeat: in future device drivers will not be capable to dereference struct ifnet. So, any feature pointers would be accessed via functions, making struct ifnet no longer part of ABI. This hasn't yet happened, but one already can (and should!) use accessors in any new code. L> > I'm afraid that if fields are there back, the situation that L> > happened with netmap (use of spare field) would repeat. L> L> ​the spare pointer used by netmap was clearly indicated by a comment, L> and giving it a dedicated name instead of if_pspare[0] was L> expected to happen (hopefully together with a __FreeBSD_version bump, L> which has not happened). I don't agree that /* 1 netmap, 7 TDB */ is a clear comment. I understood as "in future one of those is to be used for netmap". Regarding __FreeBSD_version: the field should have been renamed in the commit that brought in netmap, not in my commit. My commit removed a field that must not be used, so it is not a reason to bump. If you need closest __FreeBSD_version for the change, then please use 1100030, it happened next day. L> I am not worried that the name change was missed when deleting if_pspare[]. L> Mistakes happen and the error was promptly corrected (apart from the L> version bump). L> L> What worries me is losing some flexibility in dealing with L> out-of-tree kernel modules. Just put a properly named placeholder for them as a quick solution. A nicer solution would be to add an API for storing vendor-specific pointers on ifnet, providing a cookie. I'm discussing that now with kmacy@, who also thinks in that direction. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 16:56:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7BF12E5 for ; Tue, 9 Sep 2014 16:56:22 +0000 (UTC) Received: from webmail2.jnielsen.net (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B9A5838 for ; Tue, 9 Sep 2014 16:56:22 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by webmail2.jnielsen.net (8.14.9/8.14.9) with ESMTP id s89GuIBD096442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Sep 2014 10:56:21 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host office.betterlinux.com [199.58.199.60] claimed to be [10.10.1.198] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: UEFI display frozen on Retina MacBook Pro From: John Nielsen In-Reply-To: <540DAD5F.3050902@icloud.com> Date: Tue, 9 Sep 2014 10:56:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> <540DAD5F.3050902@icloud.com> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1878.6) 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, 09 Sep 2014 16:56:22 -0000 On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen = wrote: > On 05.09.14 19:37, John Nielsen wrote: >> On Sep 5, 2014, at 11:30 AM, Glen Barber wrote: >>=20 >>> On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote: >>>> I have a "MacBook Pro Retina, Mid 2012" (MacBookPro10,1) on which = I'd like to be able to boot FreeBSD from an external USB drive. For = testing I've been using the mini-memstick images from the -CURRENT = snapshots, most recently the one from 20140903. >>>>=20 >>>> I am able to select "EFI Boot" on the USB device from the Mac's = boot menu, and it does _something_, but the screen never changes--the = image of the boot menu is displayed indefinitely. I think it is actually = booting since there is drive activity and the caps lock key indicator = starts working a few seconds in, but the screen just stays the same. = Thinking the resolution of the Retina display may have been an issue, I = tried booting with it disabled (lid closed) and an external monitor and = keyboard. The result was the same--Mac boot menu frozen on the external = display. >>>>=20 >>>> Is there anything I should try to troubleshoot or debug this issue? = Anything else I should include in a PR? I can test patches if needed = (probably after building an image including the patch from a VM). >>>>=20 >>> To be clear, which boot menu do you see? If you see the FreeBSD = loader >>> menu, escape to the loader prompt and try: >>>=20 >>> set kern.vty=3Dvt >>> set hw.vga.textmode=3D1 >>> boot >>>=20 >>> I am a bit unclear under which conditions 'hw.vga.textmode=3D1' is >>> required, though. >> No, I don't ever see the FreeBSD loader. I see the menu you get on a = Mac when you hold down the option (alt) key while booting--big disk = icons representing the bootable disks/partitions in the system. In my = case it was the "Macintosh HD" volume (Mac OS Mavericks), my Windows = partition, and the USB stick with the FreeBSD memstick image on it, = which the Mac just called "EFI Boot" (and the icon was that of a USB = disk). There is also a little section at the bottom that allows wifi = network booting (if you've done all the black magic (not PXE) to get = that to happen). It shows a circular activity animation while it scans = for wireless networks. That animation stops when I select the USB EFI = icon and press enter (and that is the only visual indication I get that = I made a selection). >=20 > To see the FreeBSD (U)EFI boot loader on the Mac, you need to install = an EFI shell like rEFIt on either your hard drive or a HFS formatted = memory stick: > 1) Download the rEFIt installer from here: = http://downloads.sourceforge.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r= =3Dhttp%3A%2F%2Frefit.sourceforge.net%2F&ts=3D1410181876&use_mirror=3Dopti= mate > 2) Open the downloaded file > 3) Run the following command from the terminal: sudo installer -pkg = /Volumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm = using an HFS formatted memory stick). > 4) Run the command "sudo /Volumes/memstick/efi/enable.sh" > 5) When you reboot your Mac, when you hold down the alt key, choose = rEFIt on the startup menu. Then, choose the "BOOTx64.efi from =85" = option > If everything now goes as it should, you should see the FreeBSD = loader. When the "Press enter to boot or any other key to go to loader = in X seconds" (or whatever it says), press a random key. Then try to = type the commands suggested by [Glen Barber]. Thanks all, made _some_ progress. I installed rEFInd on my internal hard drive and now I can get to (and = see!) the FreeBSD EFI loader. Unfortunately that's about as far as it = gets. Once I tell the loader to boot it displays the EFI framebuffer = information and then nothing else. This happens with 'kern.vty=3Dvt' set = and with or without 'hw.vga.textmode=3D1'. Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg What should the next troubleshooting steps be? JN From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:05:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6693C835; Tue, 9 Sep 2014 17:05:37 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B95BF938; Tue, 9 Sep 2014 17:05:36 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id gi9so7464648lab.24 for ; Tue, 09 Sep 2014 10:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Dp1cNsh83mVKctWZMqaAhHYNObecKyWb2NjJwnKgRpQ=; b=RNw6FTORZJgHoW4Q1n/c/B6Mc9irqpa9+mrPvl1GAJF6nJMkWvnEpROL+qTlohpm/T XAk4pwQMs9b1FbN3+NwQ1ZRgNC7bK1CixnSHz4gWZrBtT7yR0QkY4ZlhK3wq5hINSF+Y 1EHj4hhTkWZy1DBcECW7I4Z+ggbnEHa6WMdmpqQ2rQncrbrQhR96tnySmbDBXCWmapsl EclQ0MFbnyWIrO7jFAx36RUQKfItYWsZbfnxvDWt1KbM5iKT4Jt602sqU/sJzxM5Gzbl HB5k8SuMf9/VYJPUlVapURSAUI/LUqSWPJY8TtR7KEy3t0EjO9gtpUJ7RAlyLWU9JJTg 1I1g== MIME-Version: 1.0 X-Received: by 10.152.29.129 with SMTP id k1mr11058033lah.81.1410282334478; Tue, 09 Sep 2014 10:05:34 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Tue, 9 Sep 2014 10:05:34 -0700 (PDT) Date: Tue, 9 Sep 2014 10:05:34 -0700 X-Google-Sender-Auth: 6KtBhF2FRTIKgEtyKBKw98GO3OM Message-ID: Subject: Need help fixing tests in CURRENT From: Craig Rodrigues To: freebsd-current Current , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 09 Sep 2014 17:05:37 -0000 Hi, I did a buildworld/installworld of current in a bhyve VM, and then did the following. pkg install devel/kyua cd /usr/tests kyua test kyua report kyua report-html kyua report-junit I then published the results in Jenkins: The results are here: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/ There seem to be 31 test failures. Can folks look into those and see if the tests need to be fixed Right now I ran these steps manually, but hopefully over time we can automate more of this stuff. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:11:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 184DCB19 for ; Tue, 9 Sep 2014 17:11:20 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id E489CA08 for ; Tue, 9 Sep 2014 17:11:19 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 9F887424FF for ; Tue, 9 Sep 2014 17:11:17 +0000 (UTC) Message-ID: <540F34B1.7040103@freebsd.org> Date: Tue, 09 Sep 2014 13:11:13 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Need help fixing tests in CURRENT References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4vdNug78VMK8Fu78R2id6dS34VuHjmMJ0" 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, 09 Sep 2014 17:11:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4vdNug78VMK8Fu78R2id6dS34VuHjmMJ0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-09-09 13:05, Craig Rodrigues wrote: > Hi, >=20 > I did a buildworld/installworld of current in a bhyve VM, and then did = the > following. >=20 > pkg install devel/kyua > cd /usr/tests > kyua test > kyua report > kyua report-html > kyua report-junit >=20 > I then published the results in Jenkins: >=20 > The results are here: >=20 > https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastComplet= edBuild/testReport/ >=20 > There seem to be 31 test failures. Can folks look into those > and see if the tests need to be fixed >=20 > Right now I ran these steps manually, but hopefully over time > we can automate more of this stuff. >=20 > -- > Craig > _______________________________________________ > 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 Most of the errors (jot, m4, sed, etc) seems to be: kyua-tap-tester: Configuration variables not supported; ignoring 'has.cleanup=3Dfalse' kyua-tap-tester: Configuration variables not supported; ignoring 'unprivileged-user=3Dtests' while everything else about the test was successful. --=20 Allan Jude --4vdNug78VMK8Fu78R2id6dS34VuHjmMJ0 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) iQIcBAEBAgAGBQJUDzS6AAoJEJrBFpNRJZKfNJwQALS5RacXlqBdm7fZWMAUyTr+ J7SNILGzp0gh6cnO2y4IKT/n8LyOrnh2/xvc5ZAMTufjBqQKu2cKjEhoQkhM//nM qvy3QHA7AdTxcfQ2htB7KXrAWvlx5SouAxg0PE8BCXkcQvI8g0Jk59YtFfGuvdTx XnCAoJvR7kN4ErPApM+g53PAk7mPrJPWJo43/kl2/9RFfro28MVienLewqR1+ZH4 NPqivi6jSK7XZ9zXpIuRmuFXvQ0m1VQae8Dx8U+c/9IpxNOOkA0eSTfLG0CM5J8b WMGEM3ZQIqGg0TUKUbZMlBb1d8cfMcvsO5Am9GaBTLDzGJBszTOay5pGprghz4SN K/G1fbTrXWCRjiB0E8ZYXg+P0fus8FvX3VGPA/H28+KgrSmzv0wgvyD8n6qndQyC aPQdsUEyrKcCke35dmRIfgeuZ0kvEVuVbo+bIxpUjKt8mdJStNNSssKH9V/ccGCi sWnTuOm6xfcBRSm5RXUrUVjX4G/25PZOPzGtmIm8F+l6f4p8mxixZjfrB4uAOA+Z bUtTdkhcTjIRSyvGfHfaQLjjbYL6T1q/moHVubF14Ig0Nu3ZNUfsvdDczf4gLCz1 B3i8PFOIoXpHXZGsT8KIvnmkwwfJfzSRblooOyJ/iF+s4XU/0V8zl+eW0RDsPEsB E/oNk4KzrJrSlCueo7Yj =ZBJH -----END PGP SIGNATURE----- --4vdNug78VMK8Fu78R2id6dS34VuHjmMJ0-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:13:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2333ED3E; Tue, 9 Sep 2014 17:13:05 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1720A28; Tue, 9 Sep 2014 17:13:04 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id lj1so4538763pab.29 for ; Tue, 09 Sep 2014 10:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=9l/p0k6LSbnznnI2dQWI1vK++d1EG08KiOQrb9O+Q2w=; b=1Iai84xmV5nee8Llfs+0SlFXgX/oEddxx0Z8R5rU5fl9Vw4tyjx9/MQfRfKLxEfWv6 SxbKHroeqyMRIGrL/TdJABJGLYcj6DdhwB6fqo+prXCwu3TEl/4OoMuYBhDhg4tO5pFG T6kch+GKvwaOTuQEanRn0s0Wl844WuR8SNIyiK1y9BT7ucD/ZSSU5L4CPgZnMure9cpS hNKkynDrtpM4uBsiLgzqEVjCzp2uXm6U1hsCADBYubbx3euuTcWDQHk9W7ptz8ikuoID ymSH6AbfCYbL0qkdNdLAedl5dhlq7MfZOZhSuOigoEBxDtX1u9YmtbxFtQV1CuDqFOqI YDew== X-Received: by 10.70.47.2 with SMTP id z2mr60450171pdm.38.1410282784318; Tue, 09 Sep 2014 10:13:04 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:8dc3:2f93:9a63:ed06? ([2601:8:ab80:7d6:8dc3:2f93:9a63:ed06]) by mx.google.com with ESMTPSA id aj3sm12116633pbc.92.2014.09.09.10.13.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 10:13:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7CEFCC33-E217-406B-9D1E-9D706E2C59CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Need help fixing tests in CURRENT From: yaneurabeya@gmail.com In-Reply-To: <540F34B1.7040103@freebsd.org> Date: Tue, 9 Sep 2014 10:13:02 -0700 Message-Id: <0D9BBC19-3139-4E66-B9E3-263ACB1C056B@gmail.com> References: <540F34B1.7040103@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.1878.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: Tue, 09 Sep 2014 17:13:05 -0000 --Apple-Mail=_7CEFCC33-E217-406B-9D1E-9D706E2C59CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 9, 2014, at 10:11, Allan Jude wrote: > On 2014-09-09 13:05, Craig Rodrigues wrote: >> Hi, >>=20 >> I did a buildworld/installworld of current in a bhyve VM, and then = did the >> following. >>=20 >> pkg install devel/kyua >> cd /usr/tests >> kyua test >> kyua report >> kyua report-html >> kyua report-junit >>=20 >> I then published the results in Jenkins: >>=20 >> The results are here: >>=20 >> = https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedB= uild/testReport/ >>=20 >> There seem to be 31 test failures. Can folks look into those >> and see if the tests need to be fixed >>=20 >> Right now I ran these steps manually, but hopefully over time >> we can automate more of this stuff. >=20 > Most of the errors (jot, m4, sed, etc) seems to be: >=20 > kyua-tap-tester: Configuration variables not supported; ignoring > 'has.cleanup=3Dfalse' > kyua-tap-tester: Configuration variables not supported; ignoring > 'unprivileged-user=3Dtests=92 Not quite=85 > while everything else about the test was successful. Hi Craig, Taking a stab at the issues, most of the problems are because of = https://github.com/jmmv/kyua/issues/103 . The other issues with atf ( = https://github.com/jmmv/atf/issues/8 ) and kyua ( = https://github.com/jmmv/kyua/issues/109 ) are known (I=92m sure about = ATF, not 100% sure about kyua, but my gut instinct says yes). Thanks! -Garrett --Apple-Mail=_7CEFCC33-E217-406B-9D1E-9D706E2C59CB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUDzUeAAoJEMZr5QU6S73e91QH/1SGZmvhoiJgXNaPbBzO+u38 SVAQiRvh5dFcE1WTXbTDHAEv93liaDF5VWESn+mRhytMSOO8iUsERPqJkkQ6cyCF r4tj3akhdJQAws0dTi873IBGu6j6vrc4KoDJRDEG125PYXUT2dz2pextVC06xIzB dmRgJjx6KOXs37Ruo/uf8BnU5kGYgZ9xvIugikqYc8fEyZg6qf/vr8Myvw9tGtW6 Ak/lGbsJ5oXDu0bSQiJRSKGtQG3ZYDlEBK1zpkq4DW5Lgt6BoQ52cx6GTkshwuaQ fE77M6uaKpcaJxcFvjVVvmXDMHRl7JQeRbRMYy3Vi8COFxSep7TlZWxetf6KLo0= =Ic8H -----END PGP SIGNATURE----- --Apple-Mail=_7CEFCC33-E217-406B-9D1E-9D706E2C59CB-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:17:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFD4BF7C; Tue, 9 Sep 2014 17:17:19 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33685A63; Tue, 9 Sep 2014 17:17:19 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so2949558wgg.3 for ; Tue, 09 Sep 2014 10:17:17 -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:content-transfer-encoding; bh=NOIxnB5atevvMq2CqQCWzBRjbbD5T/bVMlN01nTqg+M=; b=OjVuzQtyyjtIwkPXKRtscy6efScvWwjBJTeXRqIbQ+jPKa8X0UMUs4QrHW+/U/LGqA QKj17TOReGB0OGDUzy4nkGgGHNmocpg1IAEzsZUJI7dcCkDuWhjM/PLkK9x/fAz4Ia/n mlfWicJKGvlzvXv7TBDsTH6Vh0iYHbw8rNgOOMW8er4J9aWaTqxpgDQgGe19kSIcSPiY 6CoQHGQUjuOB3JTEG4SSkCTTQdZyX8I01OjJUBS4VJAN27TUoYlpmLCDdBA2AZ5A+UR7 f1Uj8E4c981lrh0XzuOVQXXfzerRxJQ5cw5cQ8yFvRrabSYq4sv0MJje8cjFU+NAcnln qSGg== MIME-Version: 1.0 X-Received: by 10.194.60.240 with SMTP id k16mr6034606wjr.109.1410283037425; Tue, 09 Sep 2014 10:17:17 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.126.1 with HTTP; Tue, 9 Sep 2014 10:17:17 -0700 (PDT) In-Reply-To: <0D9BBC19-3139-4E66-B9E3-263ACB1C056B@gmail.com> References: <540F34B1.7040103@freebsd.org> <0D9BBC19-3139-4E66-B9E3-263ACB1C056B@gmail.com> Date: Tue, 9 Sep 2014 11:17:17 -0600 X-Google-Sender-Auth: lDZCV6lkK9U92wAQI6rP4TK-_AU Message-ID: Subject: Re: Need help fixing tests in CURRENT From: Alan Somers To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD CURRENT , Allan Jude 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, 09 Sep 2014 17:17:19 -0000 On Tue, Sep 9, 2014 at 11:13 AM, wrote: > On Sep 9, 2014, at 10:11, Allan Jude wrote: > >> On 2014-09-09 13:05, Craig Rodrigues wrote: >>> Hi, >>> >>> I did a buildworld/installworld of current in a bhyve VM, and then did = the >>> following. >>> >>> pkg install devel/kyua >>> cd /usr/tests >>> kyua test >>> kyua report >>> kyua report-html >>> kyua report-junit >>> >>> I then published the results in Jenkins: >>> >>> The results are here: >>> >>> https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastComplet= edBuild/testReport/ >>> >>> There seem to be 31 test failures. Can folks look into those >>> and see if the tests need to be fixed >>> >>> Right now I ran these steps manually, but hopefully over time >>> we can automate more of this stuff. >> >> Most of the errors (jot, m4, sed, etc) seems to be: >> >> kyua-tap-tester: Configuration variables not supported; ignoring >> 'has.cleanup=3Dfalse' >> kyua-tap-tester: Configuration variables not supported; ignoring >> 'unprivileged-user=3Dtests=E2=80=99 > > Not quite=E2=80=A6 > >> while everything else about the test was successful. > > Hi Craig, > Taking a stab at the issues, most of the problems are because of = https://github.com/jmmv/kyua/issues/103 . The other issues with atf ( https= ://github.com/jmmv/atf/issues/8 ) and kyua ( https://github.com/jmmv/kyua/i= ssues/109 ) are known (I=E2=80=99m sure about ATF, not 100% sure about kyua= , but my gut instinct says yes). > Thanks! > -Garrett There are still a few genuine failures. usr.bin.yacc.yacc_tests.main is failing for reasons that have nothing to do with ATF or Kyua. So are bin.pkill.pkill-j_test.main and bin.pkill.pgrep-j_test.main. From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:29:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 118A65F2; Tue, 9 Sep 2014 17:29:55 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C74B1B93; Tue, 9 Sep 2014 17:29:54 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq14so2820259pab.11 for ; Tue, 09 Sep 2014 10:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EUHcldLLedBcX4JjxGxFgQB1q8qNKh6TeT0y0TlVS4E=; b=gNrXWUxSX1YvAL65It18X1DvwVJlxr0LppW0DnK1oQyU0dsZ3+gw5Lj5yXyKTcvxxK xd4z6b8G6AR73tFKO++EShn++UNO5U0ssioc9SF5xvtJNNugtwcBrJSUUnM5G5x1u+A3 UaBuJCGN8qO0cHAH/EbQEuDD9OAaE8m5dDbmw/pH533yHMoKp3ROhnGZB6kNOeE6o+81 T65C68C7tlNtrgwtW0i6gyMaB3gm0OgkyEFzJ3Y5a2zq/mVSnmDEYhN/jiQrij5LXuyP bJMlBYyn0VS3vhXupTBjIWS/y/I9ZJqPppni6za88RD6XZpgjyrGP/K9I9uu+Lrx3cmE kC/w== X-Received: by 10.66.155.105 with SMTP id vv9mr58299342pab.61.1410283794288; Tue, 09 Sep 2014 10:29:54 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:8dc3:2f93:9a63:ed06? ([2601:8:ab80:7d6:8dc3:2f93:9a63:ed06]) by mx.google.com with ESMTPSA id b14sm12355683pdk.2.2014.09.09.10.29.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 10:29:53 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EC0D02CB-CBA7-4703-8A7D-C3B3234E3705"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Need help fixing tests in CURRENT From: yaneurabeya@gmail.com In-Reply-To: Date: Tue, 9 Sep 2014 10:29:52 -0700 Message-Id: References: <540F34B1.7040103@freebsd.org> <0D9BBC19-3139-4E66-B9E3-263ACB1C056B@gmail.com> To: Alan Somers X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD CURRENT , Allan Jude 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, 09 Sep 2014 17:29:55 -0000 --Apple-Mail=_EC0D02CB-CBA7-4703-8A7D-C3B3234E3705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 9, 2014, at 10:17, Alan Somers wrote: > On Tue, Sep 9, 2014 at 11:13 AM, wrote: >> On Sep 9, 2014, at 10:11, Allan Jude wrote: >>=20 >>> On 2014-09-09 13:05, Craig Rodrigues wrote: >>>> Hi, >>>>=20 >>>> I did a buildworld/installworld of current in a bhyve VM, and then = did the >>>> following. >>>>=20 >>>> pkg install devel/kyua >>>> cd /usr/tests >>>> kyua test >>>> kyua report >>>> kyua report-html >>>> kyua report-junit >>>>=20 >>>> I then published the results in Jenkins: >>>>=20 >>>> The results are here: >>>>=20 >>>> = https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedB= uild/testReport/ >>>>=20 >>>> There seem to be 31 test failures. Can folks look into those >>>> and see if the tests need to be fixed >>>>=20 >>>> Right now I ran these steps manually, but hopefully over time >>>> we can automate more of this stuff. >>>=20 >>> Most of the errors (jot, m4, sed, etc) seems to be: >>>=20 >>> kyua-tap-tester: Configuration variables not supported; ignoring >>> 'has.cleanup=3Dfalse' >>> kyua-tap-tester: Configuration variables not supported; ignoring >>> 'unprivileged-user=3Dtests=92 >>=20 >> Not quite=85 >>=20 >>> while everything else about the test was successful. >>=20 >> Hi Craig, >> Taking a stab at the issues, most of the problems are because = of https://github.com/jmmv/kyua/issues/103 . The other issues with atf ( = https://github.com/jmmv/atf/issues/8 ) and kyua ( = https://github.com/jmmv/kyua/issues/109 ) are known (I=92m sure about = ATF, not 100% sure about kyua, but my gut instinct says yes). >> Thanks! >> -Garrett >=20 > There are still a few genuine failures. usr.bin.yacc.yacc_tests.main > is failing for reasons that have nothing to do with ATF or Kyua. So > are bin.pkill.pkill-j_test.main and bin.pkill.pgrep-j_test.main. Ugh=85 the pgrep/pkill -j issue is back ( = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191019 )=85 it was = fixed for a few weeks, so I suspect it=92s related to the changes that = kib@ and others have been making to how the proc bits in the kernel are = handled. The yacc issue is new ( = https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedB= uild/testReport/usr.bin.yacc/yacc_tests/main/ ). It passes on my = CURRENT/i386 VM, but it=92s a bit out of date (2 weeks old). I=92ve = filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193499 to = track the issue. Thanks! -Garrett $ (cd /usr/tests/usr.bin/yacc/; sudo kyua debug yacc_tests:main) ... ...ok ./yacc/ok_syntax1.tab.c ...ok ./yacc/ok_syntax1.tab.h ** testing ./pure_calc.y ...ok ./yacc/pure_calc.error ...ok ./yacc/pure_calc.output ...ok ./yacc/pure_calc.tab.c ...ok ./yacc/pure_calc.tab.h ** testing ./pure_error.y ...ok ./yacc/pure_error.error ...ok ./yacc/pure_error.output ...ok ./yacc/pure_error.tab.c ...ok ./yacc/pure_error.tab.h ** testing ./quote_calc.y ...ok ./yacc/quote_calc.error ...ok ./yacc/quote_calc.output ...ok ./yacc/quote_calc.tab.c ...ok ./yacc/quote_calc.tab.h ...ok ./yacc/quote_calc-s.error ...ok ./yacc/quote_calc-s.output ...ok ./yacc/quote_calc-s.tab.c ...ok ./yacc/quote_calc-s.tab.h ** testing ./quote_calc2.y ...ok ./yacc/quote_calc2.error ...ok ./yacc/quote_calc2.output ...ok ./yacc/quote_calc2.tab.c ...ok ./yacc/quote_calc2.tab.h ...ok ./yacc/quote_calc2-s.error ...ok ./yacc/quote_calc2-s.output ...ok ./yacc/quote_calc2-s.tab.c ...ok ./yacc/quote_calc2-s.tab.h ** testing ./quote_calc3.y ...ok ./yacc/quote_calc3.error ...ok ./yacc/quote_calc3.output ...ok ./yacc/quote_calc3.tab.c ...ok ./yacc/quote_calc3.tab.h ...ok ./yacc/quote_calc3-s.error ...ok ./yacc/quote_calc3-s.output ...ok ./yacc/quote_calc3-s.tab.c ...ok ./yacc/quote_calc3-s.tab.h ** testing ./quote_calc4.y ...ok ./yacc/quote_calc4.error ...ok ./yacc/quote_calc4.output ...ok ./yacc/quote_calc4.tab.c ...ok ./yacc/quote_calc4.tab.h ...ok ./yacc/quote_calc4-s.error ...ok ./yacc/quote_calc4-s.output ...ok ./yacc/quote_calc4-s.tab.c ...ok ./yacc/quote_calc4-s.tab.h ** testing ./varsyntax_calc1.y ...ok ./yacc/varsyntax_calc1.error ...ok ./yacc/varsyntax_calc1.output ...ok ./yacc/varsyntax_calc1.tab.c ...ok ./yacc/varsyntax_calc1.tab.h yacc_tests:main -> passed $ uname -a FreeBSD isilon-fuji-current.local 11.0-CURRENT FreeBSD 11.0-CURRENT #7 = r270227+e6e86c2(isilon-atf)-dirty: Sat Aug 23 02:26:59 PDT 2014 = ngie@isilon-fuji-current.local:/usr/obj/usr/src/sys/FUJI i386 --Apple-Mail=_EC0D02CB-CBA7-4703-8A7D-C3B3234E3705 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUDzkQAAoJEMZr5QU6S73eXRQIAIILHF6brN+KVSSjUa+5fqH+ 0TeivLxmouvwrcxhrTrU/Yev2V1NIRe5zjJ7QvvgsVFudFzzJcl/NZE61Vqq9jm9 yJ31XDknBAOubRSVKjAmb6HeSvuHLRbhM7iSpi/IHYRBb5pDp29SlmjjVRC7GnF1 OoMUmVRH+IwDGlQym0U2R/TJ/5GbLp2IJDFcJXNIQ56IsPss6izLNmymxY0tu4M9 mujG/t1e2z+KW/TRRy3gA9SBa/hR7syWw2U+2zujnlPIVmq0QTLvswEyRJG5Njes CXnEjwtL3RRJKnuYHBRxb/Ov7CiDzGFHCa650RIQod+3UCLbhHaPho2wVqRP5rg= =YSg4 -----END PGP SIGNATURE----- --Apple-Mail=_EC0D02CB-CBA7-4703-8A7D-C3B3234E3705-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:52:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 277EA4F2 for ; Tue, 9 Sep 2014 17:52:27 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4A37E41 for ; Tue, 9 Sep 2014 17:52:26 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id b17so20183740lan.13 for ; Tue, 09 Sep 2014 10:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-transfer-encoding:content-type; bh=0wl5niKoNKRfnUFeWX5BneTCvugfdu5P6fhOum5oUuU=; b=NiBnccpUkofIrAkxUPiiWweyCs0CMRdKVSAJfuQNHoZdSBMws9rX2rb4DQ+vrj/D25 6iojcnJFs0mgbtHxxJ4YMjQ2A2llo/7W0a4T8VNZnzrsrRiFF43NrqQqa7US/Xt0nqCw vRTF0RXk7TW5fCraqbEc/y5LbWyC+oM4HQDzCPVFO049fZsLPeNbxWN9NFM382yMGPSK bC++HgqSMmZV2HAndt1eDwM/96zuZYEuTJkHWtv4jB+oRoq2zH9kuEmGcJw7OTk7PHiv +4SULshGwOmZvUpCartD34zRIaUL+XGufovBTbPQolnj6qvec5mc18kN+VchYBTBt+CB Stgw== X-Received: by 10.112.50.52 with SMTP id z20mr10529591lbn.87.1410285144686; Tue, 09 Sep 2014 10:52:24 -0700 (PDT) Received: from notebook.com (220-59-93-178.pool.ukrtel.net. [178.93.59.220]) by mx.google.com with ESMTPSA id os7sm4774930lbb.42.2014.09.09.10.52.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Sep 2014 10:52:24 -0700 (PDT) From: Artyom Mirgorodskiy To: freebsd-current@freebsd.org Subject: ath0: bb hang detected (0x1), resetting Date: Tue, 09 Sep 2014 20:52:32 +0300 Message-ID: <3416287.E2VGyHt0fc@notebook.com> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 09 Sep 2014 17:52:27 -0000 Hi. Sometime I receive this message on one of access point: ath0: bb hang detected (0x1), resetting After that connection restored only if I turn off wifi by hard button and turn on again. ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9287 mac 384.2 RF5133 phy 15.15 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 Do you have any ideas? What I can provide to solve this issue? -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:53:13 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88330729; Tue, 9 Sep 2014 17:53:13 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9967DE62; Tue, 9 Sep 2014 17:53:12 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id z11so5767739lbi.26 for ; Tue, 09 Sep 2014 10:53: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=EwV4PwReMn0nUKPx8jHc/FcafT612nTUR+DzZYJ4Fgw=; b=xoeWEkcAcSLGBRhAAILxtYhb+ZrtsuwHUHG2t8GgDsSQsukSekmEBxguNERrZjePlz HQeeqyIX0VcapjhzH2lXts7uq6zJsWGfGD9vV79suXlT7amOGyYZ8i5Z1TcoilFroZlG wDSGUaQTXb+jRts6Q164rOCbhIedaDZcJH477UlL4C1NxOdan/YzhlOlk9XZ67Kp6u85 8cDdooGO6ChALPo9L2ms8pGXh5ifD3c2QQp6SIXCCiLe3bbikAlRWSSnxdIWEpxhtLvF DRJe8RC4/6o7zP84sx4KgMPkNbhZ2OopQonZ95OArTF8JvaTLvqfV+Dc+mUZMXCFizNW hMgA== MIME-Version: 1.0 X-Received: by 10.112.14.33 with SMTP id m1mr35708393lbc.16.1410285190425; Tue, 09 Sep 2014 10:53:10 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.58.164 with HTTP; Tue, 9 Sep 2014 10:53:10 -0700 (PDT) In-Reply-To: <540E26E6.5070700@freebsd.org> References: <540E14C4.9080201@freebsd.org> <540E26E6.5070700@freebsd.org> Date: Tue, 9 Sep 2014 13:53:10 -0400 X-Google-Sender-Auth: sGFZB6RZ08KXS-MQ5tcwHF65eUc Message-ID: Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient From: Patrick Kelsey To: Andrey Chernov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , 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, 09 Sep 2014 17:53:13 -0000 On Mon, Sep 8, 2014 at 6:00 PM, Andrey Chernov wrote: > On 09.09.2014 1:13, Patrick Kelsey wrote: > > You make a godo point about the wider use of fcntl() in libc - aside > > from the rpc code, by my count there are 14 other entry points in libc > > that use fcntl in their implementation. To experience breakage, > > programs that use those entry points would also have to be supplying > > them fds with restricted rights that do not include CAP_FCNTL. By my > > count, there are currently only 12 programs in -current that call > > cap_rights_limit(). I don't think these counts inform us very well as > > to the presence and extent of any capsicum+libc issues similar to the > > one that I've raised. Those 12 programs mentioned above would have to > > be audited to determine if any of the 15 libc entry points (including > > fcntl) that use fcntl are being used on those restricted fds without > > being granted CAP_FCNTL rights, and whether there are overt or potential > > failures occurring as a result. Consider that the failure mode in > > tcpdump that I found requires that you be using multiple capture files > > with size-based rotation, otherwise all works fine. Also consider that > > the failure mode in dhclient only occurs when a rewritten client lease > > file is smaller than its predecessor. > > Just to note by quick glance: > tcpdump use fdopen(), so in some cases probably already broken without > F_GETFL rights. > openssh use fdopen(), so suspicious about F_GETFL too, but I don't > traverse the order in which fdopen() and cap_rights_* there are applied. > I have now looked at all of the programs in -current that call cap_rights_limit() (dhclient, hastd, ping, tcpdump, rwhod, ctld, iscsid, kdump, rwho, units, uniq, and sshd) and examined them to see which file descriptors cap_rights_limit() is invoked on, with what rights, and whether libc functions that require fcntl rights (fcntl, fdopendir, fdopen, freopen, fseek, ftell, popen, lockf, etc) are subsequently used on those descriptors. In most cases, the programs are simple and/or the application of cap_rights_limit() is otherwise limited in scope, and it is easy to see that they have sufficient rights on the restricted fds for the operations performed on those fds. This was a mostly manual inspection, and of course I may have missed something, but I did not find any further issues related to insufficient capsicum rights when using libc. In the case of tcpdump, fdopen() is not used on a file descriptor whose rights have been restricted via cap_rights_limit(). In the case of openssh, cap_rights_limit() is used by sshd to sandbox the unprivileged child process when using privilege separation by restricting the child's stdin, stdout, and stderr, the child's end of the socketpair used to communicate with the privileged parent and the child's end of the pipe used to log to the privileged parent. fdopen() is not used on any of those descriptors. > > I don't think that this read-only fcntl(F_GETFL) which doesn not > modify > > anything deserves any special rights at all (i.e. can be just > enabled by > > default in contrast to F_SETFL), but I am not capsicum expert. > > > > I don't think I am in a position to comment on the implications of > > permanent F_GETFL rights either. I do think that the point about wider > > use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK > > right in sys/capability.h, as it would appear users of capsicum and libc > > are more in need of a map of capsicum rights required by libc entry > > points than they are of convenience #defines. > > Theoretically it will be possible to get rid of fcntl(F_GETFL) in > fseek(), but O_APPEND flag need to be stored somewhere in that case, and > stdio _flags already have all bit occupied for 16bit short. So the price > will be changing size of the main stdio structure __sFILE to add new > space for flags, which is undesirable I think. > > I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as intended. I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event, the patch attached to my first message is seeming like the way to go. -Patrick From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 17:59:45 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 717689E2; Tue, 9 Sep 2014 17:59:45 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6895EAD; Tue, 9 Sep 2014 17:59:44 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id pv20so20022112lab.19 for ; Tue, 09 Sep 2014 10:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mD0Rid2F3C1x7UOP1UGEsDEu+GsToRa4VVbnS8+QS6s=; b=QgWSGNKOFG2TCGwK2Fk8ixPvFmn8ajyoAO3FxDfSuizDfYZivcuw8aqceRgvP2AD9W w8Xk8tt4ovIiB7vVQ2UdweY43Wip6X4dzkV3NNPfbX7fqW5AAwXS0vPdlCiLcJKxk42t qDUi7njCBI27gUXdxDoSzOeum0/2aNSnzwhXJs/MevrqmULZtj1wCJ0WaqXoFM93GIy8 GdDJTHxPO8n6Sv3S7N4Pps9T0U1UhY0PpH9DrcBMMvvwOdONV53AdRsXFCCB0jPYEFPF /fK1miaCLukju++0mPl3LQPNbmvAzHPDGWxiqnD2FI/KXdZBDbyfb01wUqMz1uF0/yjZ f3rQ== MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr11379115lab.79.1410285582415; Tue, 09 Sep 2014 10:59:42 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.26.37 with HTTP; Tue, 9 Sep 2014 10:59:42 -0700 (PDT) In-Reply-To: <20140909121708.GE17059@glebius.int.ru> References: <20140909103719.GB17059@glebius.int.ru> <20140909121708.GE17059@glebius.int.ru> Date: Tue, 9 Sep 2014 19:59:42 +0200 X-Google-Sender-Auth: KDyWyLqUEbugvxsa_Ggl2nyXhZM Message-ID: Subject: Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870) From: Luigi Rizzo To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , FreeBSD Current , Stefano Garzarella 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, 09 Sep 2014 17:59:45 -0000 On Tue, Sep 9, 2014 at 2:17 PM, Gleb Smirnoff wrote: > Luigi, > > On Tue, Sep 09, 2014 at 01:01:13PM +0200, Luigi Rizzo wrote: > L> > The harm is obvious: someone commits code that _uses_ spare field > L> > without assigning it a new name. Spare field is a placeholder. Of > L> > course you can use it while you experiment. However, I don't see > L> > problem with patching your source tree where you experiment. > L> > L> The problem with _not_ having spares is that you have to recompile > L> everything after patching the headers. With the spares, i could > L> make netmap a simple add-on kernel module with no dependencies. > L> Same on linux for what matters (there wasn't a spare there, but > L> nobody used ax25 and i could check and reuse it). > > What if another kernel hacker comes and also uses if_pspare[0] for > his own super-duper feature? What would you do, if then a user > reports that enabling netmap on his box instapanics if he had > some other feature turned on? > =E2=80=8Bi'll live with that if there is contention and the use of the pspare is not checked (in linux i do check that the pointer is not used before trying to use it). With the removal of the spares we remove the risk but also prevent people from loading the module without recompiling the whole kernel. That is a bit too radical as a path to safety. It's like saying that rather than seat belts and airbags we should not drive to reduce our chances of being involved in a car accident. > L> > The ABI plan for 'struct ifnet' is that the struct becomes > L> > opaque for device drivers. So its size and alignment no longer > L> > matters. Those who want to add new fields to struct ifnet, > L> > would also need to add accessor methods. Bits of this plan > L> > are already committed by Marcel, but its only first step. > L> > L> =E2=80=8Bspare fields <-> spare accessors=E2=80=8B > > Let me repeat: in future device drivers will not be capable > to dereference struct ifnet. So, any feature pointers would > be accessed via functions, making struct ifnet no longer part > of ABI. This hasn't yet happened, but one already can (and > should!) use accessors in any new code. > > let me repeat too :) My point is preserving support for out of tree modules, and spares (or spare accessors, or the ABI you mention below; something that gets you quickly a vendor specific pointer from an opaque ifnet) were useful for that. I think the removal of spares should have happened together with the commit of the new mechanism. If it is ready now, let's move with it and be done with this discussion. If not, I would like to bring back the pspares with a big note summarizing this discussion, and remove then when the new mechanism is ready. If i read correctly your comment below about the "properly named placeholder" you seem to be ok with that ? cheers luigi L> > I'm afraid that if fields are there back, the situation that > L> > happened with netmap (use of spare field) would repeat. > L> > L> =E2=80=8Bthe spare pointer used by netmap was clearly indicated by a c= omment, > L> and giving it a dedicated name instead of if_pspare[0] was > L> expected to happen (hopefully together with a __FreeBSD_version bump, > L> which has not happened). > > I don't agree that /* 1 netmap, 7 TDB */ is a clear comment. I > understood as "in future one of those is to be used for netmap". > > Regarding __FreeBSD_version: the field should have been renamed > in the commit that brought in netmap, not in my commit. My commit > removed a field that must not be used, so it is not a reason > to bump. > > If you need closest __FreeBSD_version for the change, then > please use 1100030, it happened next day. > > L> I am not worried that the name change was missed when deleting > if_pspare[]. > L> Mistakes happen and the error was promptly corrected (apart from the > L> version bump). > L> > L> What worries me is losing some flexibility in dealing with > L> out-of-tree kernel modules. > > Just put a properly named placeholder for them as a quick solution. > > A nicer solution would be to add an API for storing vendor-specific > pointers on ifnet, providing a cookie. I'm discussing that now with > kmacy@, who also thinks in that direction. > > -- > Totus tuus, Glebius. > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 18:01:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42F30B18; Tue, 9 Sep 2014 18:01:41 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 343BBF53; Tue, 9 Sep 2014 18:01:37 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id b8so8263578lan.39 for ; Tue, 09 Sep 2014 11:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IBJKvWY3YxxSoxuDdWVKUEPzhNSzLUNCIwTdZFucPDU=; b=EMkinmGd2rx1RDWtZdjbu6FseQiZi/OUy2pxrqEn6vmUDwiLbzQ0rxgCmRR2zHS+sf cz3I0hIxsJXP4SJPa3/bnUtcS5Uz4e2y8XrQk0u6ikTz8D8AROtSmh2kbDb+vurtUeZ8 UIjmyebZd62eqxyEtYIWSsa7W3iF1rJFMrZuHcsTAWm0sMCFEpQqk5puZ4SwGU5QHkNY XxzI6QJ2GbIzjK5NEr+0W4xgH+yHVKFT0Mhc+rp1DItx6dMza0bVnt1JgI8Bxo9X3zj1 +DzNreO7K0BNElcEkJZAQ8mOyB1v+aneHpAxMRJYQ3OwgAMo/buZfSAcT4peoAZMIIsA +10Q== MIME-Version: 1.0 X-Received: by 10.112.138.201 with SMTP id qs9mr32139556lbb.41.1410285695099; Tue, 09 Sep 2014 11:01:35 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Tue, 9 Sep 2014 11:01:35 -0700 (PDT) In-Reply-To: <540F34B1.7040103@freebsd.org> References: <540F34B1.7040103@freebsd.org> Date: Tue, 9 Sep 2014 11:01:35 -0700 X-Google-Sender-Auth: SjF_m5HoahqekZ4Kp8rpmnhGNS8 Message-ID: Subject: Re: Need help fixing tests in CURRENT From: Craig Rodrigues To: Allan Jude Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current , "freebsd-testing@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, 09 Sep 2014 18:01:41 -0000 On Tue, Sep 9, 2014 at 10:11 AM, Allan Jude wrote: > > > > > https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/ > > > Most of the errors (jot, m4, sed, etc) seems to be: > > kyua-tap-tester: Configuration variables not supported; ignoring > 'has.cleanup=false' > kyua-tap-tester: Configuration variables not supported; ignoring > 'unprivileged-user=tests' > > while everything else about the test was successful. > > "Configuration variables not supported" is a behavior of kyua. I filed an issue for it here: https://github.com/jmmv/kyua/issues/104 I'm not sure if that is the source of the test failures. -- Craig From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 20:37:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 478918E2 for ; Tue, 9 Sep 2014 20:37:46 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06B39344 for ; Tue, 9 Sep 2014 20:37:45 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id i13so1518346qae.22 for ; Tue, 09 Sep 2014 13:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qjM7urysF4DgawKrJ8S9vaScyrFlNWg2WwWFQ0GR4wg=; b=HVissw3H8IumC4wRFnOcrFmkyfviQeiwbV4sQrYQvMX59hUVshmw/Q1LgVltoVaXRD PQchn36bjuVee6Mww8rFK5rCtvG7LOpXSUvkl1w5AoLMAFjOv+6BveSIM9ii7Zwa58et Wo8vmcWpFpps6VRKBIR2mt1yJC7+VO8e8/BsQyunQLm/MRQReUb3SY+erF0ol5Ut/w7m ZvSBAXrXH2sdXMvDq8/Os5jDk/MtLQjZDzDx/gt8Uc7RGLKN44f7ADldn6wWp41Rh6qp vElU9THT0ILg5vl7AomaiPviJtpxY6MoilGlQvGZaYcczYRvTabPdVS6Bkz5LsgHdg8I CFXw== MIME-Version: 1.0 X-Received: by 10.229.140.70 with SMTP id h6mr54270428qcu.3.1410295065010; Tue, 09 Sep 2014 13:37:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 9 Sep 2014 13:37:44 -0700 (PDT) In-Reply-To: <3416287.E2VGyHt0fc@notebook.com> References: <3416287.E2VGyHt0fc@notebook.com> Date: Tue, 9 Sep 2014 13:37:44 -0700 X-Google-Sender-Auth: hazI6gQijGtoOvskhuGzsS2M0rU Message-ID: Subject: Re: ath0: bb hang detected (0x1), resetting From: Adrian Chadd To: Artyom Mirgorodskiy 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: Tue, 09 Sep 2014 20:37:46 -0000 Hi, please file a PR. There's been some other issues with the BB hanging on the AR9287 so I think I have to hard-reset the chip to solve it. -a On 9 September 2014 10:52, Artyom Mirgorodskiy wrote: > Hi. Sometime I receive this message on one of access point: > ath0: bb hang detected (0x1), resetting > After that connection restored only if I turn off wifi by hard button and turn on again. > > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 2 RX streams; 2 TX streams > ath0: AR9287 mac 384.2 RF5133 phy 15.15 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > > Do you have any ideas? What I can provide to solve this issue? > > > -- > Artyom Mirgorodskiy > _______________________________________________ > 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 Sep 9 20:48:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09A84E07; Tue, 9 Sep 2014 20:48:58 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52C8F69C; Tue, 9 Sep 2014 20:48:57 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id v6so3537966lbi.41 for ; Tue, 09 Sep 2014 13:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=ZrXuyAfVjbHl+P4ysSRozpQqgBY1eI+6FqOM2oFTcI8=; b=nLeBTtjUVwXN0H/Ey9poZAkewnuVN8Hau/bX73XsTGgbV/HLf3P3OOLvnQdQSQOtFP GqW1lXiPEIpHAK1tKXdbClvevcKngGJN1sxaGTc/j9IR6yBSqX9zAL4we+puIigs3GhU 3TZJkvyokvYwhqDjtJV1KNQY755MTGLar7HOY5PkHoIftm1Y38jrgw53QjikwTdgpcDK 5o1ZWWUtyHnyfQ4/Q7PIBoMdla5WbRH6KDomJfWD//z51gy++t50SMHar9z2DrT2JwNH F2WPzetB4uprVS8KncLFGJNe3kc/LwkQspoYUUNci7yDz0SneiPleLJ+CMmuVG2j9bVi RQpQ== X-Received: by 10.112.167.103 with SMTP id zn7mr36122851lbb.63.1410295735156; Tue, 09 Sep 2014 13:48:55 -0700 (PDT) Received: from notebook.com (124-56-93-178.pool.ukrtel.net. [178.93.56.124]) by mx.google.com with ESMTPSA id y9sm4621301lad.32.2014.09.09.13.48.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Sep 2014 13:48:54 -0700 (PDT) From: Artyom Mirgorodskiy To: Adrian Chadd Subject: Re: ath0: bb hang detected (0x1), resetting Date: Tue, 09 Sep 2014 23:49:02 +0300 Message-ID: <14104510.jMrFfPtWWL@notebook.com> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <3416287.E2VGyHt0fc@notebook.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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, 09 Sep 2014 20:48:58 -0000 What is PR? On Tuesday 09 September 2014 13:37:44 Adrian Chadd wrote: > Hi, > > please file a PR. > > There's been some other issues with the BB hanging on the AR9287 so I > think I have to hard-reset the chip to solve it. > > > -a > > > On 9 September 2014 10:52, Artyom Mirgorodskiy > wrote: > > Hi. Sometime I receive this message on one of access point: > > ath0: bb hang detected (0x1), resetting > > After that connection restored only if I turn off wifi by hard button and turn on again. > > > > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 > > ath0: [HT] enabling HT modes > > ath0: [HT] enabling short-GI in 20MHz mode > > ath0: [HT] 1 stream STBC receive enabled > > ath0: [HT] 1 stream STBC transmit enabled > > ath0: [HT] 2 RX streams; 2 TX streams > > ath0: AR9287 mac 384.2 RF5133 phy 15.15 > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > > > > > Do you have any ideas? What I can provide to solve this issue? > > > > > > -- > > Artyom Mirgorodskiy > > _______________________________________________ > > 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" -- Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 20:52:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75D18F63 for ; Tue, 9 Sep 2014 20:52:08 +0000 (UTC) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DD867B7 for ; Tue, 9 Sep 2014 20:52:07 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id w7so18140316qcr.32 for ; Tue, 09 Sep 2014 13:52:00 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=uDca9aPsdo7adfJRJ5zr9sh8wMNJJF3uRHHAmnRA3Ro=; b=CGUdgEJ5RCcaa+JhMqjHOYrUhiAj0KIUQyfE/K0/cBBXtaQNDqFmYGzcDW5RrjRDqC BG27ZU2LB7ZdvugZRjivpPqthMiktRKUjjjNz2gKfM4UghA2zGebCMvRGOAQ/mYimWUw yXmqucti1nHumEQSE7C1PpthETGGceXLelJBSViIIogcMQA3nbZEDxCleVvIer/tkiiz WfA3chzlw0by3Lb8JKssHTOlz27qUs4JsHKKivPou3mOp44I6zz7FppXQFoK2ho9GND3 rahdIof6YMPpGakYdoil33qH6XI/CdLjG4rXrrGHhP7BF6nwJbB8MygCEe8SVvO/+iAw MkSA== X-Gm-Message-State: ALoCoQnBn5R6Y+A2blfT6vzoyUYeBMSi+8UAFGYjsfp7p10f+CM/HBTrHCLmbhb5VYONjBz79VHV X-Received: by 10.140.105.138 with SMTP id c10mr53304296qgf.15.1410295920789; Tue, 09 Sep 2014 13:52:00 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.83.99 with HTTP; Tue, 9 Sep 2014 13:51:40 -0700 (PDT) X-Originating-IP: [2620:0:1003:1007:8800:5a44:a9e9:4c3c] In-Reply-To: <20140908183647.GD35236@spindle.one-eyed-alien.net> References: <20140908154858.GB35236@spindle.one-eyed-alien.net> <20140908183647.GD35236@spindle.one-eyed-alien.net> From: Julio Merino Date: Tue, 9 Sep 2014 16:51:40 -0400 X-Google-Sender-Auth: Y7S2rYXX5_y1GHmr31cLfajM9NY Message-ID: Subject: Re: make -DNO_ROOT to create chroot, problem installing into chroot with pkg To: Brooks Davis Content-Type: text/plain; charset=UTF-8 Cc: Craig Rodrigues , freebsd-current Current , freebsd-pkg@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, 09 Sep 2014 20:52:08 -0000 On Mon, Sep 8, 2014 at 2:36 PM, Brooks Davis wrote: > I believe the majority of packages don't suffer from post-install > scripts hence the suggestion that extracting in the right place without > root would solve 80-90% of the problem (and probably take no more than > 10% of the work). I could live with the pain of not having scripts run > during install. The correct long term fix as proposed by bapt is the do > anyway with most scripts in favor of common actions and if any > significant scripts remain add the ability to run them on first boot. Cool; glad to hear. This sounds like a good plan. From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 21:00:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFA9A389 for ; Tue, 9 Sep 2014 21:00:18 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B3A582A for ; Tue, 9 Sep 2014 21:00:18 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id cm18so16099036qab.2 for ; Tue, 09 Sep 2014 14:00:17 -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=4bNrL2lQEoQ2AEPGuw0+VttbcJS1303qISeyybG0S+I=; b=BTGB+i4c7cm9HaYDBFMjcPmxhzf+3GJdLZGnh7R8sEPG6mYRNsLZE5BxjISVGp6Urx y3hCoJFUL+yxNo8Zpm4Hqa2TKDXqqIctjEdBLfNl0eRtxYQclCzfTCkZdhMnebW+cyYw iXq8KKDi0PKgnRVJ8xUDpNHbS/QYa6gPzputrAqTnSIWhmHQEKtCWI9mYRHIILP+cNSD 0n60TFwl76uIquj8/4V72ij1VV+CnwwgEUtyBCwnAR/jColmmr8XX03qLmbhLZ6humEB lNrJRuppkEEWqqA70Rljv5K3fVRA47utfCu7wYdt/KM7wvnq0SfoeoiZVX9AbqvRAzUI jz2Q== MIME-Version: 1.0 X-Received: by 10.224.36.4 with SMTP id r4mr53926088qad.69.1410296417502; Tue, 09 Sep 2014 14:00:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Tue, 9 Sep 2014 14:00:17 -0700 (PDT) In-Reply-To: <14104510.jMrFfPtWWL@notebook.com> References: <3416287.E2VGyHt0fc@notebook.com> <14104510.jMrFfPtWWL@notebook.com> Date: Tue, 9 Sep 2014 14:00:17 -0700 X-Google-Sender-Auth: 2gSiiXQ3k2OL8TbBc-u-4xWDwtA Message-ID: Subject: Re: ath0: bb hang detected (0x1), resetting From: Adrian Chadd To: Artyom Mirgorodskiy 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: Tue, 09 Sep 2014 21:00:18 -0000 A problem report, sorry for not being clearer! http://bugs.freebsd.org/submit/ Thanks! -a On 9 September 2014 13:49, Artyom Mirgorodskiy wrote: > What is PR? > > On Tuesday 09 September 2014 13:37:44 Adrian Chadd wrote: >> Hi, >> >> please file a PR. >> >> There's been some other issues with the BB hanging on the AR9287 so I >> think I have to hard-reset the chip to solve it. >> >> >> -a >> >> >> On 9 September 2014 10:52, Artyom Mirgorodskiy >> wrote: >> > Hi. Sometime I receive this message on one of access point: >> > ath0: bb hang detected (0x1), resetting >> > After that connection restored only if I turn off wifi by hard button and turn on again. >> > >> > ath0: mem 0xe0500000-0xe050ffff irq 18 at device 0.0 on pci10 >> > ath0: [HT] enabling HT modes >> > ath0: [HT] enabling short-GI in 20MHz mode >> > ath0: [HT] 1 stream STBC receive enabled >> > ath0: [HT] 1 stream STBC transmit enabled >> > ath0: [HT] 2 RX streams; 2 TX streams >> > ath0: AR9287 mac 384.2 RF5133 phy 15.15 >> > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> > >> > >> > Do you have any ideas? What I can provide to solve this issue? >> > >> > >> > -- >> > Artyom Mirgorodskiy >> > _______________________________________________ >> > 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" > -- > Artyom Mirgorodskiy From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 22:29:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA7C3810 for ; Tue, 9 Sep 2014 22:29:27 +0000 (UTC) Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtp002.mac.com [17.172.204.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7968817C for ; Tue, 9 Sep 2014 22:29:27 +0000 (UTC) Received: from [10.0.0.12] (ti0025a400-3490.bb.online.no [85.167.24.175]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBN002ESKZTJ5A0@st11p01mm-asmtp002.mac.com> for freebsd-current@freebsd.org; Tue, 09 Sep 2014 21:28:44 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-09_07:2014-09-09,2014-09-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409090174 Subject: Re: UEFI display frozen on Retina MacBook Pro References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> <540DAD5F.3050902@icloud.com> From: Anders Bolt-Evensen Content-type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (11D257) In-reply-to: Message-id: <1E369C69-BF9F-4A0F-B1F1-77799342B627@me.com> Date: Tue, 09 Sep 2014 23:28:41 +0200 To: "freebsd-current@freebsd.org" Content-transfer-encoding: quoted-printable MIME-version: 1.0 (1.0) X-Mailman-Approved-At: Tue, 09 Sep 2014 22:43:42 +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, 09 Sep 2014 22:29:27 -0000 If you have an internal or external DVD burner, have you tried to download t= he ISO file and buen that to a DVD and boot from that DVD? That method works= on my MacBook Pro from 2011. Sent from my iPhone > On 09 Sep 2014, at 18:56, John Nielsen wrote: >=20 >> On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen w= rote: >>=20 >>> On 05.09.14 19:37, John Nielsen wrote: >>>> On Sep 5, 2014, at 11:30 AM, Glen Barber wrote: >>>>=20 >>>>> On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote: >>>>> I have a "MacBook Pro Retina, Mid 2012" (MacBookPro10,1) on which I'd l= ike to be able to boot FreeBSD from an external USB drive. For testing I've b= een using the mini-memstick images from the -CURRENT snapshots, most recentl= y the one from 20140903. >>>>>=20 >>>>> I am able to select "EFI Boot" on the USB device from the Mac's boot m= enu, and it does _something_, but the screen never changes--the image of the= boot menu is displayed indefinitely. I think it is actually booting since t= here is drive activity and the caps lock key indicator starts working a few s= econds in, but the screen just stays the same. Thinking the resolution of th= e Retina display may have been an issue, I tried booting with it disabled (l= id closed) and an external monitor and keyboard. The result was the same--Ma= c boot menu frozen on the external display. >>>>>=20 >>>>> Is there anything I should try to troubleshoot or debug this issue? An= ything else I should include in a PR? I can test patches if needed (probably= after building an image including the patch from a VM). >>>> To be clear, which boot menu do you see? If you see the FreeBSD loader= >>>> menu, escape to the loader prompt and try: >>>>=20 >>>> set kern.vty=3Dvt >>>> set hw.vga.textmode=3D1 >>>> boot >>>>=20 >>>> I am a bit unclear under which conditions 'hw.vga.textmode=3D1' is >>>> required, though. >>> No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac= when you hold down the option (alt) key while booting--big disk icons repre= senting the bootable disks/partitions in the system. In my case it was the "= Macintosh HD" volume (Mac OS Mavericks), my Windows partition, and the USB s= tick with the FreeBSD memstick image on it, which the Mac just called "EFI B= oot" (and the icon was that of a USB disk). There is also a little section a= t the bottom that allows wifi network booting (if you've done all the black m= agic (not PXE) to get that to happen). It shows a circular activity animatio= n while it scans for wireless networks. That animation stops when I select t= he USB EFI icon and press enter (and that is the only visual indication I ge= t that I made a selection). >>=20 >> To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an E= FI shell like rEFIt on either your hard drive or a HFS formatted memory stic= k: >> 1) Download the rEFIt installer from here: http://downloads.sourceforge.n= et/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=3Dhttp%3A%2F%2Frefit.sourceforg= e.net%2F&ts=3D1410181876&use_mirror=3Doptimate >> 2) Open the downloaded file >> 3) Run the following command from the terminal: sudo installer -pkg /Volu= mes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm using an H= FS formatted memory stick). >> 4) Run the command "sudo /Volumes/memstick/efi/enable.sh" >> 5) When you reboot your Mac, when you hold down the alt key, choose rEFIt= on the startup menu. Then, choose the "BOOTx64.efi from =E2=80=A6" option >> If everything now goes as it should, you should see the FreeBSD loader. W= hen the "Press enter to boot or any other key to go to loader in X seconds" (= or whatever it says), press a random key. Then try to type the commands sugg= ested by [Glen Barber]. >=20 > Thanks all, made _some_ progress. >=20 > I installed rEFInd on my internal hard drive and now I can get to (and see= !) the FreeBSD EFI loader. Unfortunately that's about as far as it gets. Onc= e I tell the loader to boot it displays the EFI framebuffer information and t= hen nothing else. This happens with 'kern.vty=3Dvt' set and with or without '= hw.vga.textmode=3D1'. >=20 > Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg >=20 > What should the next troubleshooting steps be? >=20 > JN >=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"= From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 06:37:42 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC43A6C0 for ; Wed, 10 Sep 2014 06:37:42 +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 2968EEEC for ; Wed, 10 Sep 2014 06:37:41 +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 s8A6bbdY049217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Sep 2014 10:37:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s8A6bbkL049216; Wed, 10 Sep 2014 10:37:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 10 Sep 2014 10:37:37 +0400 From: Gleb Smirnoff To: Luigi Rizzo Subject: Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870) Message-ID: <20140910063737.GI17059@glebius.int.ru> References: <20140909103719.GB17059@glebius.int.ru> <20140909121708.GE17059@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: George Neville-Neil , FreeBSD Current , Stefano Garzarella 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, 10 Sep 2014 06:37:42 -0000 Luigi, On Tue, Sep 09, 2014 at 07:59:42PM +0200, Luigi Rizzo wrote: L> My point is preserving support for out of tree modules, L> and spares (or spare accessors, or the ABI you mention below; L> something that gets you quickly a vendor specific pointer L> from an opaque ifnet) were useful for that. L> L> I think the removal of spares should have happened together L> with the commit of the new mechanism. If it is ready now, L> let's move with it and be done with this discussion. L> L> If not, I would like to bring back the pspares L> with a big note summarizing this discussion, L> and remove then when the new mechanism is ready. L> If i read correctly your comment below about L> the "properly named placeholder" you seem to be ok with that ? It would be absolutely okay if you commit right now a properly named placeholder for your new subsystem, that you work on right now. With the proper name no one will unintentionally hijack it. Would this be a satisfiable solution for you? The suggested ABI mechanism is still under discussion and development. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 07:00:26 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C50AE58E for ; Wed, 10 Sep 2014 07:00:26 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46C4D1A1 for ; Wed, 10 Sep 2014 07:00:25 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id l4so7523995lbv.36 for ; Wed, 10 Sep 2014 00:00:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4dAMvg0ge7yMv48AZKzF1wkiiOnYNtsxOxIkcZnJfKE=; b=ZgN7gx5RHv/HVJw5ceWrn0RHt3/OBvjCRfd2uhuWYg5EZGFBL86Al+OLgnAQu/7B7F XCSZVeOi+7noMXlmjLNXo6AByykFN/U9gU4K5/kuBQkZxQ+pR/ZqQ6lQxzAQJz+0k2wf xxEnbVRr5xJXaJXUF//GmdaQPZwvn3ILelY4nzQ4o11P87lwnptyuNZG04Ew9VgkJASH kyXLXHE0ulAOyX6FcatrhD+q9FzQD12GgPuUDZh4t2NuNauvGp4mIq0Mq886OM9B0Hqn QOE1bhF/mOFdlWUD01R5QsEbtIbFk1Sxv4Aaqt0ABptsOYrtfoS3u1XTu6wLjZktDMfE V/ZQ== X-Gm-Message-State: ALoCoQkZV2jMPAR2XPXj4T8WLF2k5tukMI6PipSX9OAqBS8XJFqe7zEsjLkXaqGDIVadp18llAiQ X-Received: by 10.152.116.80 with SMTP id ju16mr14307667lab.73.1410332423268; Wed, 10 Sep 2014 00:00:23 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id h9sm4993998lae.40.2014.09.10.00.00.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Sep 2014 00:00:22 -0700 (PDT) Message-ID: <540FF706.2050400@freebsd.org> Date: Wed, 10 Sep 2014 11:00:22 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Patrick Kelsey Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: <540E14C4.9080201@freebsd.org> <540E26E6.5070700@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , 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, 10 Sep 2014 07:00:26 -0000 On 09.09.2014 21:53, Patrick Kelsey wrote: > I don't think it is worth the trouble, as given the larger pattern of > libc routines requiring multiple capsicum rights, it seems one will in > general have to have libc implementation knowledge when using it in > concert with capsicum. For example, consider the limitfd() routine in > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > stdout so the eventual call to isatty() via printf() will work as intended. > > I think the above kdump example is a good one for the subtle issues that > can arise when using capsicum with libc. That call to isatty() is via a > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > to a tty is line buffered by default. It would appear that programs > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > could be disabling the normally default line buffering when stdout is a > tty. kdump goes the distance, but dhclient does not (restricting stdout > to CAP_WRITE only). > > In any event, the patch attached to my first message is seeming like the > way to go. Well, then commit it (if capsicum team agrees). -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 10:12:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2DD83F7; Wed, 10 Sep 2014 10:12:00 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59C5F1902; Wed, 10 Sep 2014 10:12:00 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward2l.mail.yandex.net (Yandex) with ESMTP id CFE641AC12A7; Wed, 10 Sep 2014 14:11:56 +0400 (MSK) Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 4B57D18A04CC; Wed, 10 Sep 2014 14:11:56 +0400 (MSK) Received: from 84.201.164.255-vpn.dhcp.yndx.net (84.201.164.255-vpn.dhcp.yndx.net [84.201.164.255]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id W7qZ6mZNhs-BtbebuhI; Wed, 10 Sep 2014 14:11:55 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 97ff11fe-854b-4cc9-bc82-8714e9974ff9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1410343915; bh=alWYVcv50pL47WcSWCwGzfD/bIq3iu21S758JW0d3OY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=VtM+8YfwYgGyckf7+x1Q3vx5H37zHKnGzVQebKBfFF7bdsm3R+oyE1Jqv9nTb5qj2 kCXWxiSMCEt9gg0LLLkhuVp/2pgul1UF2Zf/5XxY/3lpeS4kG18ico5kqArGcbrO1E h13I+Doqcr0n6sJDA3wZXlWio2QZAyQaLe6uhjxA= Authentication-Results: smtp18.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <541023A0.8000509@yandex.ru> Date: Wed, 10 Sep 2014 14:10:40 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kurt Lidl , freebsd-current@freebsd.org Subject: Re: ipv6 network aliases not set after upgrade to 9.3 References: <20140904141624.GA66403@hydra.pix.net> In-Reply-To: <20140904141624.GA66403@hydra.pix.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 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, 10 Sep 2014 10:12:00 -0000 On 04.09.2014 18:16, Kurt Lidl wrote: > Greetings all: > > I have a host that recently was upgraded from FreeBSD 9.1 > to FreeBSD 9.3. After the upgrade, the IPv6 aliases that > I was setting on vlan'd interfaces, no longer get set: > > The section of my /etc/rc.conf, which worked under 9.1: > > # inside network (gigabit connected) > ifconfig_bce1="up" > vlans_bce1="16 17" > ifconfig_bce1_16="192.168.16.4/24" > ifconfig_bce1_16_ipv6="inet6 accept_rtadv" > ifconfig_bce1_16_alias0="inet6 2001:470:e254:0010::4 prefixlen 64 alias" > ifconfig_bce1_17="192.168.17.4/24" > ifconfig_bce1_17_ipv6="inet6 accept_rtadv" > ifconfig_bce1_17_alias0="inet6 2001:470:e254:0011::4 prefixlen 64 alias" > > When I use the same configuration file under 9.3, I get the > vlan'd interfaces created, and they get an auto-assigned > IPv6 interface, but the aliases do not get assigned. > > If I manually run: > > ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias > ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias > > Then the aliased addresses get assigned. Did the syntax for > specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1? > > I did not see anything calling out this change in either the 9.2 or 9.3 > release notes. Hi, I can confirm this, please, fill a bug report. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 10:19:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7CF75B1; Wed, 10 Sep 2014 10:19:30 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 4E005195C; Wed, 10 Sep 2014 10:19:29 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XRezn-000Z1o-G8>; Wed, 10 Sep 2014 12:19:27 +0200 Received: from g226057167.adsl.alicedsl.de ([92.226.57.167] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XRezn-0000vN-CL>; Wed, 10 Sep 2014 12:19:27 +0200 Date: Wed, 10 Sep 2014 12:19:22 +0200 From: "O. Hartmann" To: Scot Hetzel Subject: Re: service doen't get started at boottime, but can start manually Message-ID: <20140910121922.32870017.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140907090321.12bbc428.ohartman@zedat.fu-berlin.de> <20140907153342.2366ad8b@X220.alogt.com> <20140907094308.6c466d9f.ohartman@zedat.fu-berlin.de> <20140907112811.5570fc85.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/tc5Ne3zdM1w3APHA8XJmZRU"; protocol="application/pgp-signature" X-Originating-IP: 92.226.57.167 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , Erich Dollansky , FreeBSD Ports 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, 10 Sep 2014 10:19:31 -0000 --Sig_/tc5Ne3zdM1w3APHA8XJmZRU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 7 Sep 2014 11:16:37 -0500 Scot Hetzel schrieb: > On Sun, Sep 7, 2014 at 10:44 AM, Scot Hetzel wrote: > > I created the rc.d/refdbd script by copying /etc/rc.d/inetd and make a > > few minor changes. > > This script (untested) should do what the scripts/refdb.in and > > scripts/refdbctl.in were doing: > > > > #!/bin/sh > > # > > # $FreeBSD$ > > # > > > > # PROVIDE: refdbd > > # REQUIRE: LOGIN > > # KEYWORD: shutdown > > > > . /etc/rc.subr > > > > name=3D"refdbd" > > rcvar=3D"refdbd_enable" > > command=3D"%%PREFIX%%/bin/${name}" > > pidfile=3D"/var/run/${name}.pid" > > required_files=3D"/etc/${name}.conf" >=20 > I missed required_files in my editing of the original script. >=20 > If refdbd does have a configuration file, changes this to point to the > correct file, otherwise this can be removed. >=20 > > extra_commands=3D"reload" > > > > load_rc_config $name > > run_rc_command "$1" > > > > Place the above in textproc/refdb/files/refdb.in, then add: > > > > USE_RC_SUBR=3D refdbd > > > > in textproc/refdb/Makefile. > > >=20 It seems to me, that when a port installs a script appended with "*.sh" in = etc/rc.d/, the script gets executed anyway - regardless wether the service is enabled in /etc/rc.conf[.local] or not. This is especially the case for the origina= l port textproc/refdb. The reason why especially one particular machine rejected the startup of th= e service was: I changed the script's name from refdb.sh to refdb and with the lack of the= correct syntax and definitions inside it, the system (11.0 CURRENT) did not start t= he service while the other systems running refdb used the oldstyle refdb.sh script. Just for the conclusion of the obscure (at least for me) behaviour. Thanks for your time, Oliver --Sig_/tc5Ne3zdM1w3APHA8XJmZRU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUECWuAAoJEOgBcD7A/5N8YbwH/3cD2RxASJONgP/r9IdH/99H WwPC/o+W/qLn4hwnQEkeIifd4ir4u3NWDWqSJ/XXyQ35XOSESV7JPi+qNR9eGaSs /uMrAvYKvGM8T8lLK/FWmBEy2z737Ltfo23feeZHuc4VPWJ0uOzkcH1xD1klsLxM nX1oMM37FFR3A14UJwuhaL2OxuxACMjm3MXwWze90yuRgQKI2FFbg+rn0qaYffTt dCodgrGXaH72w2ZrYIRQeDzlVmgghmZ/3sLV/MPOHdLngSAo5OWc7QL7fx6tXRSR ZpSIr+qHwgf770Z022TGZZ6XoutmPg631Q+GS6lPzSVMC01r96XZi4cVcGnWXRw= =vyx5 -----END PGP SIGNATURE----- --Sig_/tc5Ne3zdM1w3APHA8XJmZRU-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 06:08:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7EBFDDFA; Wed, 10 Sep 2014 06:08:26 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50362BF3; Wed, 10 Sep 2014 06:08:26 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NBO008O591SVK50@st11p02mm-asmtp001.mac.com>; Wed, 10 Sep 2014 06:08:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-10_01:2014-09-09,2014-09-09,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-1402240000 definitions=main-1409100071 Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1973.6\)) Subject: Re: UEFI display frozen on Retina MacBook Pro From: Rui Paulo In-reply-to: <540DAD5F.3050902@icloud.com> Date: Tue, 09 Sep 2014 23:08:15 -0700 Content-transfer-encoding: quoted-printable Message-id: <7F697DBF-71FA-4CF8-B75A-0B2641C2D27D@me.com> References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> <540DAD5F.3050902@icloud.com> To: Anders Bolt Evensen X-Mailer: Apple Mail (2.1973.6) X-Mailman-Approved-At: Wed, 10 Sep 2014 11:44:26 +0000 Cc: gjb@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: Wed, 10 Sep 2014 06:08:26 -0000 On Sep 8, 2014, at 06:21, Anders Bolt Evensen = wrote: >=20 > To see the FreeBSD (U)EFI boot loader on the Mac, you need to install = an EFI shell like rEFIt on either your hard drive or a HFS formatted = memory stick: I think this is just a problem with our EFI implementation, though. We = should be able to switch to text mode like rEFIt does. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 12:45:12 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA73D391 for ; Wed, 10 Sep 2014 12:45:12 +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 6C245D13 for ; Wed, 10 Sep 2014 12:45:12 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8ACj8lB058523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Sep 2014 12:45:09 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1410353109; bh=GfgfuMCOSTgoEasPtep+BcRxhLYhIApHixaiuO3cNZU=; h=Date:From:To:Subject; b=lvJgVDAJbc3PGFooMlRvuzaiUTfoVCWfsfmf5NbzGE4mG8yiUolNsYAXBnr0DQLUk xm9jtWeRh1uLeHbDAbehV/5Un4tTmmkHqgflSKMa1SPN1piRFsHK7k9E0gsQZ1PEzc wwbDIt+mkB+NMgffeEOZNb+aWgwy2lkOF2kBtMpw= Date: Wed, 10 Sep 2014 12:45:08 +0000 (UTC) From: Marcin Cieslak To: current@FreeBSD.org Subject: panic: resource_list_alloc: resource entry is busy Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 10 Sep 2014 12:45:12 -0000 On my CURRENT as of 6 Sep (r271197): What I did was that: - kldload i915 - startx During X server start I get the following: #10 0xffffffff808c2947 in resource_list_alloc (rl=, bus=, child=, type=, rid=, start=, end=, count=, flags=) at /usr/src/sys/kern/subr_bus.c:3304 #11 0xffffffff8061ddae in pci_alloc_resource (dev=, child=, type=, rid=, start=, end=, count=, flags=) at /usr/src/sys/dev/pci/pci.c:4604 #12 0xffffffff808c4420 in bus_alloc_resource (dev=0xfffff800026d8800, type=1, rid=0xffffffff811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #13 0xffffffff80626092 in vga_pci_alloc_resource (dev=0xfffff800026d8800, child=, type=1, rid=0xfffff80008c0b2d4, start=0, end=, count=18446744071580876744, flags=) at /usr/src/sys/dev/pci/vga_pci.c:318 #14 0xffffffff808c4420 in bus_alloc_resource (dev=0xfffff800026d7300, type=1, rid=0xffffffff811effc8, start=632, end=18446744071580876744, count=464, flags=100707968) at bus_if.h:284 #15 0xffffffff81e94f73 in drm_attach (kdev=0xfffff800026d7300, idlist=) at bus.h:416 #16 0xffffffff808c202f in device_attach (dev=0xfffff800026d7300) at device_if.h:180 #17 0xffffffff808c34c9 in bus_generic_driver_added (dev=, driver=) at /usr/src/sys/kern/subr_bus.c:2792 #18 0xffffffff808c022a in devclass_driver_added (dc=0xfffff80002504a80, driver=0xffffffff81e714c0) at bus_if.h:204 #19 0xffffffff808c018c in devclass_add_driver (dc=0xfffff80002504a80, driver=0xffffffff81e714c0, pass=, dcp=) at /usr/src/sys/kern/subr_bus.c:1136 #20 0xffffffff80873a12 in module_register_init (arg=0xffffffff81e714a8) at /usr/src/sys/kern/kern_module.c:123 #21 0xffffffff80866f24 in linker_load_module (kldname=, modname=0xfffff80002407400 "i915kms", parent=0x0, verinfo=0x0, lfpp=0xfffffe0096d05a80) at /usr/src/sys/kern/kern_linker.c:224 #22 0xffffffff80868a18 in kern_kldload (td=, file=, fileid=0xfffffe0096d05ac4) at /usr/src/sys/kern/kern_linker.c:1029 #23 0xffffffff80868b5b in sys_kldload (td=0xfffff80008911490, uap=) at /usr/src/sys/kern/kern_linker.c:1055 X -version: X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 11.0-CURRENT amd64 Current Operating System: FreeBSD radziecki.saper.info 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r271197M: Sat Sep 6 19:19:12 CEST 2014 root@radziecki.saper.info:/usr/obj/usr/src/sys/VAIO amd64 Build Date: 04 September 2014 01:06:53AM Devices: vgapci0@pci0:0:2:0: class=0x030000 card=0x81e6104d chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x81e6104d chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller' class = display (this laptop also has a possbility to switch to NVidia card on boot, not tested yet with this kernel). Kernel: # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode # vt is the new video console driver device vt device vt_vga device vt_efifb device agp # support several AGP chipsets Loader: kern.vty=vt By the way, how do I get a nicer FB console during boot (not just after starting X)? I have difficulty getting back to the console text printed when it was "vga" (in 640x480x16 mode) - no more output shown on the hires console (I've had "tail -f somelog") running on the text console 0 when starting X from another window. //Marcin From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 13:34:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 439231CB for ; Wed, 10 Sep 2014 13:34:46 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 17CEC1350 for ; Wed, 10 Sep 2014 13:34:45 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 2474624089 for ; Wed, 10 Sep 2014 09:34:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5cSKeIzTR8i for ; Wed, 10 Sep 2014 09:34:39 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <5410536E.8030508@egr.msu.edu> Date: Wed, 10 Sep 2014 09:34:38 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: UEFI display frozen on Retina MacBook Pro References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> <540DAD5F.3050902@icloud.com> <7F697DBF-71FA-4CF8-B75A-0B2641C2D27D@me.com> In-Reply-To: <7F697DBF-71FA-4CF8-B75A-0B2641C2D27D@me.com> 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, 10 Sep 2014 13:34:46 -0000 On 09/10/2014 02:08, Rui Paulo wrote: > On Sep 8, 2014, at 06:21, Anders Bolt Evensen wrote: >> >> To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: > > I think this is just a problem with our EFI implementation, though. We should be able to switch to text mode like rEFIt does. > > -- > Rui Paulo > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Please see http://www.mail-archive.com/freebsd-current@freebsd.org/msg155044.html for a patch. From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 14:05:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF3483B1 for ; Wed, 10 Sep 2014 14:05:40 +0000 (UTC) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::4]) (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 95AE41770 for ; Wed, 10 Sep 2014 14:05:40 +0000 (UTC) Received: from torb.pix.net (verizon.pix.net [71.178.232.3]) (authenticated bits=0) by hydra.pix.net (8.14.9/8.14.9) with ESMTP id s8AE5c73005430; Wed, 10 Sep 2014 10:05:38 -0400 (EDT) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host verizon.pix.net [71.178.232.3] claimed to be torb.pix.net Message-ID: <54105AB2.6020206@pix.net> Date: Wed, 10 Sep 2014 10:05:38 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-current@freebsd.org Subject: Re: ipv6 network aliases not set after upgrade to 9.3 References: <20140904141624.GA66403@hydra.pix.net> <541023A0.8000509@yandex.ru> In-Reply-To: <541023A0.8000509@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 10 Sep 2014 14:05:40 -0000 On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote: > On 04.09.2014 18:16, Kurt Lidl wrote: >> Greetings all: >> >> I have a host that recently was upgraded from FreeBSD 9.1 >> to FreeBSD 9.3. After the upgrade, the IPv6 aliases that >> I was setting on vlan'd interfaces, no longer get set: >> >> The section of my /etc/rc.conf, which worked under 9.1: >> >> # inside network (gigabit connected) >> ifconfig_bce1="up" >> vlans_bce1="16 17" >> ifconfig_bce1_16="192.168.16.4/24" >> ifconfig_bce1_16_ipv6="inet6 accept_rtadv" >> ifconfig_bce1_16_alias0="inet6 2001:470:e254:0010::4 prefixlen 64 alias" >> ifconfig_bce1_17="192.168.17.4/24" >> ifconfig_bce1_17_ipv6="inet6 accept_rtadv" >> ifconfig_bce1_17_alias0="inet6 2001:470:e254:0011::4 prefixlen 64 alias" >> >> When I use the same configuration file under 9.3, I get the >> vlan'd interfaces created, and they get an auto-assigned >> IPv6 interface, but the aliases do not get assigned. >> >> If I manually run: >> >> ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias >> ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias >> >> Then the aliased addresses get assigned. Did the syntax for >> specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1? >> >> I did not see anything calling out this change in either the 9.2 or 9.3 >> release notes. > > Hi, > > I can confirm this, please, fill a bug report. > This bug has already been fixed in stable/9, apparently: ------------------------------------------------------------------------ r269028 | dteske | 2014-07-23 18:10:34 -0400 (Wed, 23 Jul 2014) | 7 lines MFC r267812 (hrs): Fix ifname normalization. ifconfig_IF_alias{es,N} did not work if ifname has any of [.-/+]. PR: conf/191961 Spotted by: jhay MFC after: 3 days ------------------------------------------------------------------------ Personally, given that this a regression of prior behavior, I'd love to see it go into a patch release of 9.3. Since its not a security concern, I think this is unlikely to happen. I have tested the patch in that revision (kindly send to me by Hiroki Sato), and it resolves the issue I was seeing. -Kurt From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 14:48:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E85AAFC for ; Wed, 10 Sep 2014 14:48:30 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CFAC71D53 for ; Wed, 10 Sep 2014 14:48:29 +0000 (UTC) Received: from [192.168.1.2] (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id E2F5146449 for ; Wed, 10 Sep 2014 14:48:22 +0000 (UTC) Message-ID: <541064BD.9060509@freebsd.org> Date: Wed, 10 Sep 2014 10:48:29 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: ipv6 network aliases not set after upgrade to 9.3 References: <20140904141624.GA66403@hydra.pix.net> <541023A0.8000509@yandex.ru> <54105AB2.6020206@pix.net> In-Reply-To: <54105AB2.6020206@pix.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tR60JWfTx179kv5tcEqTV44tcuQCPvkrs" 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, 10 Sep 2014 14:48:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tR60JWfTx179kv5tcEqTV44tcuQCPvkrs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-09-10 10:05, Kurt Lidl wrote: > On 9/10/14, 6:10 AM, Andrey V. Elsukov wrote: >> On 04.09.2014 18:16, Kurt Lidl wrote: >>> Greetings all: >>> >>> I have a host that recently was upgraded from FreeBSD 9.1 >>> to FreeBSD 9.3. After the upgrade, the IPv6 aliases that >>> I was setting on vlan'd interfaces, no longer get set: >>> >>> The section of my /etc/rc.conf, which worked under 9.1: >>> >>> # inside network (gigabit connected) >>> ifconfig_bce1=3D"up" >>> vlans_bce1=3D"16 17" >>> ifconfig_bce1_16=3D"192.168.16.4/24" >>> ifconfig_bce1_16_ipv6=3D"inet6 accept_rtadv" >>> ifconfig_bce1_16_alias0=3D"inet6 2001:470:e254:0010::4 prefixlen 64 a= lias" >>> ifconfig_bce1_17=3D"192.168.17.4/24" >>> ifconfig_bce1_17_ipv6=3D"inet6 accept_rtadv" >>> ifconfig_bce1_17_alias0=3D"inet6 2001:470:e254:0011::4 prefixlen 64 a= lias" >>> >>> When I use the same configuration file under 9.3, I get the >>> vlan'd interfaces created, and they get an auto-assigned >>> IPv6 interface, but the aliases do not get assigned. >>> >>> If I manually run: >>> >>> ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias >>> ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias >>> >>> Then the aliased addresses get assigned. Did the syntax for >>> specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1?= >>> >>> I did not see anything calling out this change in either the 9.2 or 9= =2E3 >>> release notes. >> >> Hi, >> >> I can confirm this, please, fill a bug report. >> >=20 > This bug has already been fixed in stable/9, apparently: >=20 > -----------------------------------------------------------------------= - > r269028 | dteske | 2014-07-23 18:10:34 -0400 (Wed, 23 Jul 2014) | 7 lin= es >=20 > MFC r267812 (hrs): Fix ifname normalization. ifconfig_IF_alias{es,N} di= d > not > work if ifname has any of [.-/+]. >=20 > PR: conf/191961 > Spotted by: jhay > MFC after: 3 days >=20 > -----------------------------------------------------------------------= - >=20 > Personally, given that this a regression of prior behavior, > I'd love to see it go into a patch release of 9.3. Since its > not a security concern, I think this is unlikely to happen. >=20 > I have tested the patch in that revision (kindly send to me by > Hiroki Sato), and it resolves the issue I was seeing. >=20 > -Kurt >=20 >=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.o= rg" I think at least an Errata notice is called for. So users will more easily be able to find out what the problem is, and stand a reasonable chance of being aware of the issue before they upgrade, so they can either include the patch, or rename their interfaces. --=20 Allan Jude --tR60JWfTx179kv5tcEqTV44tcuQCPvkrs 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) iQIcBAEBAgAGBQJUEGTAAAoJEJrBFpNRJZKf3hQQAILebcuuQeo74JXwXZW+3AH4 7BtrxAiQdVSLzuJ6+aCY1f8V/0LxQzI/6bBVGx5oR3PVSw0Mb72nKdpkyG1tMpTI JAYkbk7EYPlu9ba4YCPg2mXQSKn4YQLdeClpyZTUSyLJxpvZehcS1CNlNXCpepPa PVoLTvSY2kFm4ExOqiBv0QH6TnPm4XijD+BEYllm9PIliHsdJErrEDrYIXDixkbA CAhieb8zQoj8Qw027Qt1UUjLIPFfwrjfXauAVqbji9PZlVlNC/tg7kJ1r02JDZDb NNWDGX0qw7ynewpzkmXUMqzinbyKprHBqMTf9c1S6cEDnZxf3eRGD4LBCli9Dh1v XUIOLP5N0/+W3giumSGcaYgCKG7ear6wdS6/yLOfzBwAELMnUYpZzEO4Livh9zuS QTBkVYH+bebSEzqp95Owyb1nGfXAz0nSSiFYxJ3AspAofwSwkRiEhdklVuFdxckC gi7faSSQHUvffXsdMRWgZKXkMSCts+9awMB67PQnEXsAbFj+2RWHyW6O2fcpr25T 88RRosOLFalTexnNhqYq2M111bIetupn9PXKyz6D/WHFs5F1UMFwiXsIy4uXGu21 0Vl0kiYwuC186HMSQGfb8nSo6iotEhFcREpRvT1rrEk+DRM0VpPVP0qYGCl0Vi7g WRVfyIsiS505woIHN7DD =nP7V -----END PGP SIGNATURE----- --tR60JWfTx179kv5tcEqTV44tcuQCPvkrs-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 15:03:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9104721B for ; Wed, 10 Sep 2014 15:03:48 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5E51F51 for ; Wed, 10 Sep 2014 15:03:48 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id r5so554947qcx.28 for ; Wed, 10 Sep 2014 08:03:47 -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=h1hOODJawurkTYTcmVEibxgnLNJY59frcJ4ESnQE/UE=; b=CWnlkng1yULTgZiNHdBvkdP2bMzdfSTKaH+NGE9w1/vi8de289+BR0vRosmcbVjMmx ghdeTC1g4LRRWXkMdm1XzgDh3L8HV6gla7qn+qtpuuQoJ9ZgJLieItcAbTMRWd6Hj3Ks ePpnrg12cF4VrlYgFDPdpxdpsuxR1+EZATXrtEQz0R52j9cEkI/42qEz02yGr6dD7yr5 va893RU7Y5RSjsXxdVCFgXHszhuDMtccmxc/xX2ChLPrMmueuV1URanWx3G9v8MhGDYM qHJTQuV0oMm7rynVbnBAcWkzyPYdHs2uJ7yxxy7Na3KFPZvJsbMreOvg9rwDpRT8uRK8 RHig== MIME-Version: 1.0 X-Received: by 10.140.42.77 with SMTP id b71mr2779398qga.52.1410361427405; Wed, 10 Sep 2014 08:03:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.39.139 with HTTP; Wed, 10 Sep 2014 08:03:47 -0700 (PDT) In-Reply-To: <5410536E.8030508@egr.msu.edu> References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> <540DAD5F.3050902@icloud.com> <7F697DBF-71FA-4CF8-B75A-0B2641C2D27D@me.com> <5410536E.8030508@egr.msu.edu> Date: Wed, 10 Sep 2014 08:03:47 -0700 X-Google-Sender-Auth: pcLv0GJTSIHFcDTwfGAvVeZb8dk Message-ID: Subject: Re: UEFI display frozen on Retina MacBook Pro From: Adrian Chadd To: Adam McDougall 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: Wed, 10 Sep 2014 15:03:48 -0000 Would you or someone else please file a PR with that patch? That way it doesn't get lost. https://bugs.freebsd.org/submit/ Thanks! -a On 10 September 2014 06:34, Adam McDougall wrote: > On 09/10/2014 02:08, Rui Paulo wrote: >> On Sep 8, 2014, at 06:21, Anders Bolt Evensen wrote: >>> >>> To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: >> >> I think this is just a problem with our EFI implementation, though. We should be able to switch to text mode like rEFIt does. >> >> -- >> Rui Paulo >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > Please see > http://www.mail-archive.com/freebsd-current@freebsd.org/msg155044.html > for a patch. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 15:59:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 333DC16D; Wed, 10 Sep 2014 15:59:03 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A4E6170C; Wed, 10 Sep 2014 15:59:03 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 48DE7B992; Wed, 10 Sep 2014 11:59:01 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: UEFI display frozen on Retina MacBook Pro Date: Wed, 10 Sep 2014 11:09:57 -0400 Message-ID: <4950626.XFRRneftH6@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <5410536E.8030508@egr.msu.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 10 Sep 2014 11:59:01 -0400 (EDT) Cc: Adrian Chadd , emaste@freebsd.org, Adam McDougall 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, 10 Sep 2014 15:59:03 -0000 On Wednesday, September 10, 2014 08:03:47 AM Adrian Chadd wrote: > Would you or someone else please file a PR with that patch? That way > it doesn't get lost. > > https://bugs.freebsd.org/submit/ > > Thanks! Please assign it to emaste@ as he had volunteered to commit the patch previously. Also, Ed, regarding the earlier thread about this, I think instead of hacking up the EFI headers, we should use the stock headers and adjust our code to use whatever naming contentions (CamelCase, etc.) those use. This is what we do with ACPICA for example. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 15:59:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5F05195 for ; Wed, 10 Sep 2014 15:59:03 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8DB85170D for ; Wed, 10 Sep 2014 15:59:03 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0007B9B8; Wed, 10 Sep 2014 11:59:02 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: panic: resource_list_alloc: resource entry is busy Date: Wed, 10 Sep 2014 11:06:36 -0400 Message-ID: <1749648.0eHaTPXHUy@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 10 Sep 2014 11:59:02 -0400 (EDT) Cc: Marcin Cieslak 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, 10 Sep 2014 15:59:03 -0000 On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: > On my CURRENT as of 6 Sep (r271197): > > What I did was that: > > - kldload i915 > > - startx > > During X server start I get the following: > > #10 0xffffffff808c2947 in resource_list_alloc (rl=, > bus=, child=, type= optimized out>, > rid=, start=, end= optimized out>, count=, flags=) > at /usr/src/sys/kern/subr_bus.c:3304 > #11 0xffffffff8061ddae in pci_alloc_resource (dev=, > child=, type=, rid= optimized out>, > start=, end=, count= optimized out>, flags=) at > /usr/src/sys/dev/pci/pci.c:4604 #12 0xffffffff808c4420 in > bus_alloc_resource (dev=0xfffff800026d8800, type=1, rid=0xffffffff811effc8, > start=632, end=18446744071580876744, count=464, flags=100707968) at > bus_if.h:284 > #13 0xffffffff80626092 in vga_pci_alloc_resource (dev=0xfffff800026d8800, > child=, type=1, rid=0xfffff80008c0b2d4, start=0, > end=, count=18446744071580876744, flags= optimized out>) at /usr/src/sys/dev/pci/vga_pci.c:318 Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 16:18:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 267BB429; Wed, 10 Sep 2014 16:18:27 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id EDBFB19ED; Wed, 10 Sep 2014 16:18:26 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id BB156283D0; Wed, 10 Sep 2014 12:18:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktb4wyvUxB6Z; Wed, 10 Sep 2014 12:18:25 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <541079D1.8090800@egr.msu.edu> Date: Wed, 10 Sep 2014 12:18:25 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: UEFI display frozen on Retina MacBook Pro References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <5410536E.8030508@egr.msu.edu> <4950626.XFRRneftH6@ralph.baldwin.cx> In-Reply-To: <4950626.XFRRneftH6@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: emaste@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, 10 Sep 2014 16:18:27 -0000 On 09/10/2014 11:09, John Baldwin wrote: > On Wednesday, September 10, 2014 08:03:47 AM Adrian Chadd wrote: >> Would you or someone else please file a PR with that patch? That way >> it doesn't get lost. >> >> https://bugs.freebsd.org/submit/ >> >> Thanks! > > Please assign it to emaste@ as he had volunteered to commit the patch > previously. > > Also, Ed, regarding the earlier thread about this, I think instead of hacking > up the EFI headers, we should use the stock headers and adjust our code to use > whatever naming contentions (CamelCase, etc.) those use. This is what we do > with ACPICA for example. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193524 From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 16:40:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39BFD96; Wed, 10 Sep 2014 16:40:35 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C6DD1C93; Wed, 10 Sep 2014 16:40:34 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so10323693lbv.28 for ; Wed, 10 Sep 2014 09:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=V5A2p3Y+a9YE0FVc/SvglzWfJ4YwSLDFmrPatFPbcMg=; b=015usbN9nnv4FGPknf4mV1FUZHBjaiMWMqAdxS+8xom++tFEEqVWRbYpmYBmnmH454 IG8F/vp2kNt3B5Jp/qecXGC/WQGflHwpLgAwozFKx53nzBbJdiw7L1IGcp62ZXQugi58 lml/idyGZRKaIZPVRoPZcunB/2+x7jsaIgthAM0bH0tERCxEd6e6sb9x6Ps9sxWtXYmF K7altTkJJG7dZfSfekE+bQSpHK2isCoGOJpU1XMdST61p7Hm3fHbE018GpLJLLMaMk1g ObHyFG5aNCBGTEFbtHrLj5uPzd3N9Bq/KBsC1Sk3t4q2pDM+Ke4H3n4r7Mxb9Ib41odh TfZA== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr3958996laj.88.1410367232389; Wed, 10 Sep 2014 09:40:32 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Wed, 10 Sep 2014 09:40:32 -0700 (PDT) Date: Wed, 10 Sep 2014 09:40:32 -0700 X-Google-Sender-Auth: oo8AlU6hSFHIdJn69P1ZikZ-Xis Message-ID: Subject: Need help fixing tests in CURRENT From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@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, 10 Sep 2014 16:40:35 -0000 Hi, Based on feedback from Garrett, it looks like there were some problems in kyua, causing test failures. I patched my local copy of the kyua port: https://github.com/rodrigc/kyua-port/ and re-ran the tests: cd /usr/tests kyua test kyua report kyua report-html kyua report-junit https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/lastCompletedBuild/testReport/ There are still 7 test failures which I don't understand. Can someone help fix these? -- Craig From owner-freebsd-current@FreeBSD.ORG Wed Sep 10 19:00:27 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 797F6C24 for ; Wed, 10 Sep 2014 19:00:27 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CDEADBA for ; Wed, 10 Sep 2014 19:00:27 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XRn7x-000FGM-1n for freebsd-current@FreeBSD.org; Wed, 10 Sep 2014 21:00:25 +0200 Message-ID: <54109FC4.70105@FreeBSD.org> Date: Wed, 10 Sep 2014 21:00:20 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: UEFI boot failure: BIOS smap did not include a basemem segment! Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Kmx1fQNxv0QuMfaFpTis0ro0OMxUnN53J" 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, 10 Sep 2014 19:00:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kmx1fQNxv0QuMfaFpTis0ro0OMxUnN53J Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! I tried the following FreeBSD snapshot on my Clevo W860CU with UEFI enabled: FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img The boot fails early with the following error: panic: BIOS smap did not include a basemem segment! The full picture of the panic is here: https://people.freebsd.org/~dumbbell/uefi/FreeBSD-Clevo-W860CU-UEFI-no-ba= semem-segment.jpg Here's a video of a verbose boot (the quality is really low, I can try to redo it if this one doesn't help): http://www.dumbbell.fr/~dumbbell/FreeBSD-Clevo-W860CU-UEFI-no-basemem-seg= ment.mov When I tried UEFI a couple years ago (with Windows 7), it could boot. --=20 Jean-S=C3=A9bastien P=C3=A9dron --Kmx1fQNxv0QuMfaFpTis0ro0OMxUnN53J 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 iQJ8BAEBCgBmBQJUEJ/IXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMLOIP/1Ps9BeQCYMoqcMYcWfXxlF6 kfjE8aXobENmBawB+50S1RaadNyDq1o5Fs+jB5vCfTh/00+xpCN+SuyAKqiH2UA8 FjjsN5av503hR/rnqpsOmu+NctCKk3/Y9UCzp9rV9pHUcots/EPGxSeMU4NOAyJz q6AazxJj6VvKJMV8V6rt0EhYtZt0hRxtR12Sd5rlQACVFnomWP0NBIGDotElrKm0 5m++w5WxFR1fHnXS0RU40NgVsQbED2VBCs9hKWNBQvVppwN5Ahc8Hc3zMx1d6GYN 3u2rAlDcF7Wq5UblDakPw7kR4Pqk0k+1p4/gU8qlJInPfTXo0fqLtSPNCxCQ+IVs 3lBJzgkekmSKbkqLgawg144i0y5a4uoL20NQK3H06+7uOXOA0aUIdhblqIWZqAwY 5hE2ghY/Z3Swe9prNgPnM22r77jN1weJl2voMZMNOYxcjdYDTLOPM1em+4gd1hYE bsT+BsT6g9lmp0MxD7nhrFRZ41YrpXjR3Ge1oN6uIuKWUKMiPXVUdV0dmO7tuOuo 7y8P/9dN1rACW9v00+I/91S4aJg62Jd4GmmQ6stiTB7XUiY197rJu+xWEqTXYsjr riEfIZ5NH2b+za0J5+8n39VIL/JkYu6x+Nzuiqa4d+LnQ60yb7bKDDotlIM0sKMr NhlmTHS5vCsAfxex6vru =ur36 -----END PGP SIGNATURE----- --Kmx1fQNxv0QuMfaFpTis0ro0OMxUnN53J-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 10:47:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FE09F3; Thu, 11 Sep 2014 10:47:54 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6728FD; Thu, 11 Sep 2014 10:47:53 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AEB6A1FE027; Thu, 11 Sep 2014 12:47:50 +0200 (CEST) Message-ID: <54117DCD.5090701@selasky.org> Date: Thu, 11 Sep 2014 12:47:41 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: [RFC] Patch to improve TSO limitation formula in general References: <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> In-Reply-To: <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Scott Long , Jack F Vogel 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, 11 Sep 2014 10:47:54 -0000 Hi Rick, Did you get a chance to look further at my patch? Is this something we can commit? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 13:23:14 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D45E6CCC for ; Thu, 11 Sep 2014 13:23:14 +0000 (UTC) Received: from valery.hibma.org (valery.hibma.org [IPv6:2a02:2308::216:3eff:fe79:3a6c]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD1AB5F for ; Thu, 11 Sep 2014 13:23:14 +0000 (UTC) Received: from [192.168.178.63] (546A718F.cm-12-3b.dynamic.ziggo.nl [84.106.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by valery.hibma.org (Postfix) with ESMTPSA id AC8646927C1; Thu, 11 Sep 2014 15:23:12 +0200 (CEST) From: Nick Hibma Subject: CDC-WDM driver (4G modems) Date: Thu, 11 Sep 2014 15:23:07 +0200 Message-Id: <2D4CF978-B2C2-4253-93C7-595DABAC00DD@van-laarhoven.org> To: freebsd-current@FreeBSD.ORG Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky 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, 11 Sep 2014 13:23:15 -0000 Folks, Hans-Petter, Is anyone aware of an effort to create support for QMI based 4G modems? = The following parts need to be implemented I think: - CDC-WDM support - Wrapper driver to access QMI devices as WDM? - libqmi port to FreeBSD This would support any modem from Telit, Sierra Wireless, Option, etc. = that works with the Qualcomm chipsets. If you look in the cdc-wdm qmi = driver in Linux, it is a long list. I could not find any mention of FreeBSD and QMI on the same page, so I = assume no one is working on it. Nick Hibma= From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 13:44:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0FBD842 for ; Thu, 11 Sep 2014 13:44:48 +0000 (UTC) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "unsane.co.uk", Issuer "unsane.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B044D9B for ; Thu, 11 Sep 2014 13:44:47 +0000 (UTC) Received: from vhoffman.lon.namesco.net (lon.namesco.net [195.7.254.102]) (authenticated bits=0) by unsane.co.uk (8.14.9/8.14.8) with ESMTP id s8BDiiO6040479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 11 Sep 2014 14:44:44 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <5411A74B.7090001@unsane.co.uk> Date: Thu, 11 Sep 2014 14:44:43 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: UEFI display frozen on Retina MacBook Pro References: <9C939A39-79DA-44A7-8C8C-48B6423B50D4@jnielsen.net> <20140905173019.GF36287@hub.FreeBSD.org> <97975F21-B733-4549-8ED8-8E86CBE6DEA7@jnielsen.net> <540DAD5F.3050902@icloud.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, 11 Sep 2014 13:44:48 -0000 On 09/09/2014 17:56, John Nielsen wrote: > On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen = wrote: > >> On 05.09.14 19:37, John Nielsen wrote: >>> On Sep 5, 2014, at 11:30 AM, Glen Barber wrote: >>> >>>> On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote: >>>>> I have a "MacBook Pro Retina, Mid 2012" (MacBookPro10,1) on which I= 'd like to be able to boot FreeBSD from an external USB drive. For testin= g I've been using the mini-memstick images from the -CURRENT snapshots, m= ost recently the one from 20140903. >>>>> >>>>> I am able to select "EFI Boot" on the USB device from the Mac's boo= t menu, and it does _something_, but the screen never changes--the image = of the boot menu is displayed indefinitely. I think it is actually bootin= g since there is drive activity and the caps lock key indicator starts wo= rking a few seconds in, but the screen just stays the same. Thinking the = resolution of the Retina display may have been an issue, I tried booting = with it disabled (lid closed) and an external monitor and keyboard. The r= esult was the same--Mac boot menu frozen on the external display. >>>>> >>>>> Is there anything I should try to troubleshoot or debug this issue?= Anything else I should include in a PR? I can test patches if needed (pr= obably after building an image including the patch from a VM). >>>>> >>>> To be clear, which boot menu do you see? If you see the FreeBSD loa= der >>>> menu, escape to the loader prompt and try: >>>> >>>> set kern.vty=3Dvt >>>> set hw.vga.textmode=3D1 >>>> boot >>>> >>>> I am a bit unclear under which conditions 'hw.vga.textmode=3D1' is >>>> required, though. >>> No, I don't ever see the FreeBSD loader. I see the menu you get on a = Mac when you hold down the option (alt) key while booting--big disk icons= representing the bootable disks/partitions in the system. In my case it = was the "Macintosh HD" volume (Mac OS Mavericks), my Windows partition, a= nd the USB stick with the FreeBSD memstick image on it, which the Mac jus= t called "EFI Boot" (and the icon was that of a USB disk). There is also = a little section at the bottom that allows wifi network booting (if you'v= e done all the black magic (not PXE) to get that to happen). It shows a c= ircular activity animation while it scans for wireless networks. That ani= mation stops when I select the USB EFI icon and press enter (and that is = the only visual indication I get that I made a selection). >> To see the FreeBSD (U)EFI boot loader on the Mac, you need to install = an EFI shell like rEFIt on either your hard drive or a HFS formatted memo= ry stick: >> 1) Download the rEFIt installer from here: http://downloads.sourceforg= e.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=3Dhttp%3A%2F%2Frefit.sour= ceforge.net%2F&ts=3D1410181876&use_mirror=3Doptimate >> 2) Open the downloaded file >> 3) Run the following command from the terminal: sudo installer -pkg /V= olumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm usin= g an HFS formatted memory stick). >> 4) Run the command "sudo /Volumes/memstick/efi/enable.sh" >> 5) When you reboot your Mac, when you hold down the alt key, choose rE= FIt on the startup menu. Then, choose the "BOOTx64.efi from =85" option >> If everything now goes as it should, you should see the FreeBSD loader= =2E When the "Press enter to boot or any other key to go to loader in X s= econds" (or whatever it says), press a random key. Then try to type the c= ommands suggested by [Glen Barber]. > Thanks all, made _some_ progress. > > I installed rEFInd on my internal hard drive and now I can get to (and = see!) the FreeBSD EFI loader. Unfortunately that's about as far as it get= s. Once I tell the loader to boot it displays the EFI framebuffer informa= tion and then nothing else. This happens with 'kern.vty=3Dvt' set and wit= h or without 'hw.vga.textmode=3D1'. > > Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg > > What should the next troubleshooting steps be? Just wanted to add a me too. I've finding exactly the same thing trying a usb or DVD 11-CURRENT snapshot. Hardware is MacBook Pro (15-inch, Mid 2010) Model Name: MacBook Pro Model Identifier: MacBookPro6,2 Processor Name: Intel Core i7 Processor Speed: 2.66 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 4 MB Memory: 8 GB Processor Interconnect Speed: 4.8 GT/s Boot ROM Version: MBP61.0057.B0F SMC Version (system): 1.58f17 Can upload a screenshot but its more or less identical to Johns. Vince > > JN > > _______________________________________________ > 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" > From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 13:48:57 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1F5DB2F for ; Thu, 11 Sep 2014 13:48:57 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6019BDD5 for ; Thu, 11 Sep 2014 13:48:57 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 429921FE027; Thu, 11 Sep 2014 15:48:49 +0200 (CEST) Message-ID: <5411A837.1010208@selasky.org> Date: Thu, 11 Sep 2014 15:48:39 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Nick Hibma , freebsd-current@FreeBSD.ORG Subject: Re: CDC-WDM driver (4G modems) References: <2D4CF978-B2C2-4253-93C7-595DABAC00DD@van-laarhoven.org> In-Reply-To: <2D4CF978-B2C2-4253-93C7-595DABAC00DD@van-laarhoven.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 11 Sep 2014 13:48:57 -0000 On 09/11/14 15:23, Nick Hibma wrote: > Folks, Hans-Petter, > > Is anyone aware of an effort to create support for QMI based 4G modems? The following parts need to be implemented I think: > > - CDC-WDM support > - Wrapper driver to access QMI devices as WDM? > - libqmi port to FreeBSD > > This would support any modem from Telit, Sierra Wireless, Option, etc. that works with the Qualcomm chipsets. If you look in the cdc-wdm qmi driver in Linux, it is a long list. > > I could not find any mention of FreeBSD and QMI on the same page, so I assume no one is working on it. > Hi, I'm not aware of any projects in that area. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 14:12:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59D5B795; Thu, 11 Sep 2014 14:12:58 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F8A9154; Thu, 11 Sep 2014 14:12:58 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id a13so1068091igq.17 for ; Thu, 11 Sep 2014 07:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=ectgD7PawcMtEDZlyjXCmLRVQBIiHuSsxMvDeRSIu6g=; b=0cQN3DAhswUq1JgGagGIR1zyFprGXbE74RmDURdIPRyG0W1E/uDU/o62LGaTFXNWOx W/YNb7HV4zJkOpdbwXnjUQEbZIZK7WI8ONfL1t1LL3iAnndCeRFZTKgWVVO69S6WOtcm DQSXlLIKBn7fx6sU2fgHNQ4ObUvkEBfB7M4F4rf/GwyCBNrEn/s5Dg4NkFRgR0gt0N8I Dqnqrwx5QGeAqLwRd5c6h62HlhxEt6/X1slMwbqZcmgZF+xtUzW54UPwey6xRuzdUUIE IUzAb/LxIphHc92k2Fcy5CjcOHHf8Lh6iHUhojPsHBeE6UtADt9zf2LFcCy4WK++Mkz3 WRSw== X-Received: by 10.50.6.77 with SMTP id y13mr2629613igy.21.1410444777540; Thu, 11 Sep 2014 07:12:57 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.1 with HTTP; Thu, 11 Sep 2014 07:12:37 -0700 (PDT) In-Reply-To: <54109FC4.70105@FreeBSD.org> References: <54109FC4.70105@FreeBSD.org> From: Ed Maste Date: Thu, 11 Sep 2014 10:12:37 -0400 X-Google-Sender-Auth: AtN-GwZQ5wdPMppkya3_hxWvHu4 Message-ID: Subject: Re: UEFI boot failure: BIOS smap did not include a basemem segment! To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 11 Sep 2014 14:12:58 -0000 On 10 September 2014 15:00, Jean-S=C3=A9bastien P=C3=A9dron wrote: > Hello! > > I tried the following FreeBSD snapshot on my Clevo W860CU with UEFI > enabled: > FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img Thanks for trying it out. > The boot fails early with the following error: > panic: BIOS smap did not include a basemem segment! This panic means the memory map does not include usable memory (for the kernel) with physaddr 0. if (physmap[i] =3D=3D 0x00000000) { basemem =3D physmap[i + 1] / 1024; basemem =3D=3D 0 produces the panic. The requirement for a usable memory range with physaddr 0 doesn't hold for UEFI, and the md startup hasn't yet been reworked to accommodate that. > Here's a video of a verbose boot (the quality is really low, I can try > to redo it if this one doesn't help): > http://www.dumbbell.fr/~dumbbell/FreeBSD-Clevo-W860CU-UEFI-no-basemem-seg= ment.mov Pausing the video immediately after the kernel starts confirms this: the UEFI firmware has RuntimeServicesData at physaddr 0, so not available for kernel use. Do you mind submitting a PR to keep track of this issue? From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 14:56:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03A472B4; Thu, 11 Sep 2014 14:56:19 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70BA1813; Thu, 11 Sep 2014 14:56:18 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id m15so6121998wgh.7 for ; Thu, 11 Sep 2014 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=D4jSv/rL8RcsBHl8JXvVT/WDhX9pgugUqyM3JGsYnds=; b=kwYoJLHVax2aNGjRmpMjjWeGHff4moq9JMeVfLbdQ+9181KdlbXLFH+l6cq/v2Khq8 WHHdkd2lh6deMvH2YT48oOUe6REzHS6v3wvzwMHrNAUZWzF3Kj4+p/rP1fnkjtZCdEVV mfimDOXcQLwollVjP7bHRwe/AuOthJfnoB1ERHNM//bvpwXJgJ81SnQY8X3VERnMVPPC HjZuR56uKNvtfnOm/dsTjRNd2U5eMKpgPz8CMexhpWuZ7wRLn/A8dPXoQ1mC1/HH//Qe x2ELHY6jnQ3fadySl5DBaOQE1x+2d4AW3iJ4wQzMwPrLSqk8lOWEmmy4p7TYzN7rQenr +OWg== MIME-Version: 1.0 X-Received: by 10.194.185.230 with SMTP id ff6mr2058063wjc.120.1410446970427; Thu, 11 Sep 2014 07:49:30 -0700 (PDT) Received: by 10.217.66.195 with HTTP; Thu, 11 Sep 2014 07:49:30 -0700 (PDT) Date: Thu, 11 Sep 2014 16:49:30 +0200 Message-ID: Subject: Intel i915 GPU hung From: "Ranjan1018 ." <214748mv@gmail.com> To: "freebsd-x11@freebsd.org" , FreeBSD CURRENT 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, 11 Sep 2014 14:56:19 -0000 Hello, I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated Intel HD Graphics 4000, to: FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep 10 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 Using Firefox, after some minutes, I receive the error: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state This error is not related to r271400, but I first saw it few months ago in current. The output of the command sysctl hw.dri.0.info.i915_error_state is: https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=sharing After the error I am not able to run mplayer for videos: the window is black. Regards, Maurizio From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 14:56:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B01C83DD; Thu, 11 Sep 2014 14:56:42 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 707D9822; Thu, 11 Sep 2014 14:56:42 +0000 (UTC) Received: from 2a02-8428-011b-e000-0290-f5ff-fe9d-b78c.rev.sfr.net ([2a02:8428:11b:e000:290:f5ff:fe9d:b78c] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1XS5nc-000814-5m; Thu, 11 Sep 2014 16:56:40 +0200 Message-ID: <5411B823.7060504@FreeBSD.org> Date: Thu, 11 Sep 2014 16:56:35 +0200 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ed Maste Subject: Re: UEFI boot failure: BIOS smap did not include a basemem segment! References: <54109FC4.70105@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ICOGJgskeGOi3C4sCGp8Jg2VEaB2FobtB" 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: Thu, 11 Sep 2014 14:56:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ICOGJgskeGOi3C4sCGp8Jg2VEaB2FobtB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11.09.2014 16:12, Ed Maste wrote: > The requirement for a usable memory range with physaddr 0 doesn't hold > for UEFI, and the md startup hasn't yet been reworked to accommodate > that. Thank you for the explanation! > Do you mind submitting a PR to keep track of this issue? Here it is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193564 --=20 Jean-S=C3=A9bastien P=C3=A9dron --ICOGJgskeGOi3C4sCGp8Jg2VEaB2FobtB 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 iQJ8BAEBCgBmBQJUEbgoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NzA4N0ZEMUFFQUUwRTEyREJDNkE2RjAz OUU5OTc2MUE1RkQ5NENDAAoJEDnpl2Gl/ZTMBcEP/iuv99vHcbwhQrle1elnzTZp +mBRZd0UlluC2qhSALn/x8IZ5aXn4psdDgrzVByEoov1DGbYwWnNYkPo+PqH+ypq otOB8rFm3rJ69WvYQOjvdvLkwNM6Iuz6hGFghYGajKVyNIBp3JhxHvs+TYLL91UT j5IRnO+DjSgmYAJxmiWdMYBCeB1hHM8G4CdAtwScLmlSLY8RNDiqqHikRPClsZT3 Fe+HVDJi6F1qMaUeNmJUHuafoFysSy5NcAxQ+rjEuC3QlILIU38s5M7kszOoqhYo L78xGvQHOlWVmNdWUli/Do43ccfG6Nbq/foAgcf3hhrjHd4vOOmO3LUYAX1pigtK 69c0FX6tASPyB+23ApvPYg0inaeEBWlN+C+HwC9SX68rTanJHvmk2rRKHXUsfrXH chUcUuRzIEpz1G+fZmQjabLig6fyoNe7M8/5hFA0282D3+50mYfEwpFPEvtS1Y7q zRc7xe1ORps36dtBQzqrN5Hb5KgJUq2SOdYThZ9EApWal1Qrx1TQmGZy5RGmMMPQ vMq/R4O6Jhtbl1an24U9ZKoBnjR38RLCyE+4d9GNZvpst9xFYx+ZBGRVtwYLjJs6 /8NuSguw5Tb+NwnEDenwT6ptuA1TfvFHGYiyRL4czQrlfYC/InD03omL5o7CE14C S3pmVCjTmG5AuqDama58 =bc0T -----END PGP SIGNATURE----- --ICOGJgskeGOi3C4sCGp8Jg2VEaB2FobtB-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 14:50:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5980C1E4 for ; Thu, 11 Sep 2014 14:50:26 +0000 (UTC) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E61FD6E6 for ; Thu, 11 Sep 2014 14:50:25 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id em10so4072411wid.4 for ; Thu, 11 Sep 2014 07:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=6Y/thzIAkb6pyC27H+Alx31TB0G+Hcx6uWE6bE+scQo=; b=VVFlaC1NZUu7pi6jMW+uYL4biZNticqJmYlYdhPDLxXS6wU+qKzn6NbtD/LQHyiSSl HFTAmpNohSfM2MpEM0A66g4PexIJ8KP+k/gAPIXcEcPNlDuAOxTzqDLz7ebd0ZdIRPjM mDaQtGYhEOapcZLwxK62RkznttZLsJzAhZO7KjnV2lzLpHrZEXfc0L41Q0XnemuzXldu 8B3yyP0/zHB13pfzWlctjXXsJ6E8gDGw4OXowb2NaXYZWt6MNcdGLN0jzY1wszf/Q872 nvNahfjBbknqsv5Z+dl+slJKE8+bFTfnYKQ+riWzUjXX6StxH7uNVYsrzQj+sHj1Y0CZ 9+7g== X-Received: by 10.180.93.99 with SMTP id ct3mr7908364wib.0.1410446534262; Thu, 11 Sep 2014 07:42:14 -0700 (PDT) Received: from [62.49.247.162] (pumpkin.growveg.org. [62.49.247.162]) by mx.google.com with ESMTPSA id gk17sm6162300wic.16.2014.09.11.07.42.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Sep 2014 07:42:13 -0700 (PDT) Message-ID: <5411B4C1.6080103@gmail.com> Date: Thu, 11 Sep 2014 15:42:09 +0100 From: John User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: FreeBSD Current Subject: UEFI cd boots, what it installs doesn't Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 11 Sep 2014 15:01:46 +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: Thu, 11 Sep 2014 14:50:26 -0000 Hello Currents, I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned it to disk then booted from it. It boots up fine, and it goes through the install routine fine. The problem is, after the install is finished, when I try to boot the installed system, it gives me the option to select 0 or 1. Whatever I select, I get a flashing cursor then nothing. If I leave it at nothing eventually the bios asks what the problem is. What am I doing wrong? The board is an Asus Z87-PRO and the disks are Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've tried ad0 ad2 and ad3 to no avail. PC-BSD will install if the default options are chosen. It installs GRUB. Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it imposes zfs, all I need is freebsd with ufs and gconcat and also /var and /tmp on the ssd. thanks, -- John From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 15:18:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F416F22B for ; Thu, 11 Sep 2014 15:17:59 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id C2969ACF for ; Thu, 11 Sep 2014 15:17:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 835D83806B; Thu, 11 Sep 2014 10:17:53 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id tiG4Nqfo9bAH; Thu, 11 Sep 2014 10:17:53 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 279CC3805E; Thu, 11 Sep 2014 10:17:53 -0500 (CDT) Message-ID: <5411BA23.6040707@freebsd.org> Date: Thu, 11 Sep 2014 08:05:07 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John , FreeBSD Current Subject: Re: UEFI cd boots, what it installs doesn't References: <5411B4C1.6080103@gmail.com> In-Reply-To: <5411B4C1.6080103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 11 Sep 2014 15:18:00 -0000 On 09/11/14 07:42, John wrote: > Hello Currents, > > I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned > it to disk then booted from it. It boots up fine, and it goes through > the install routine fine. The problem is, after the install is finished, > when I try to boot the installed system, it gives me the option to > select 0 or 1. Whatever I select, I get a flashing cursor then nothing. > If I leave it at nothing eventually the bios asks what the problem is. > > What am I doing wrong? The board is an Asus Z87-PRO and the disks are > Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've > tried ad0 ad2 and ad3 to no avail. > > PC-BSD will install if the default options are chosen. It installs GRUB. > Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it > imposes zfs, all I need is freebsd with ufs and gconcat and also /var > and /tmp on the ssd. > > thanks, Can you test the memstick image? That uses the same bootblocks as an installed system. -Nathan From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 16:26:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C3ECA01 for ; Thu, 11 Sep 2014 16:26:29 +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 487C929C for ; Thu, 11 Sep 2014 16:26:29 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8BGSe4K085528; Thu, 11 Sep 2014 09:28:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8BGSXAq085524; Thu, 11 Sep 2014 09:28:33 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 11 Sep 2014 09:28:35 -0700 (PDT) Message-ID: In-Reply-To: <5411B4C1.6080103@gmail.com> References: <5411B4C1.6080103@gmail.com> Date: Thu, 11 Sep 2014 09:28:35 -0700 (PDT) Subject: Re: UEFI cd boots, what it installs doesn't From: "Chris H" To: "John" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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: Thu, 11 Sep 2014 16:26:29 -0000 > Hello Currents, > > I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned > it to disk then booted from it. It boots up fine, and it goes through > the install routine fine. The problem is, after the install is finished, > when I try to boot the installed system, it gives me the option to > select 0 or 1. Whatever I select, I get a flashing cursor then nothing. > If I leave it at nothing eventually the bios asks what the problem is. > > What am I doing wrong? The board is an Asus Z87-PRO and the disks are > Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've > tried ad0 ad2 and ad3 to no avail. > > PC-BSD will install if the default options are chosen. It installs GRUB. > Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it > imposes zfs, all I need is freebsd with ufs and gconcat and also /var > and /tmp on the ssd. I've run into issues in the past, when attempting to install FreeBSD on a disk that grub had been put on from another OS. I found that blowing away the MBR, a couple of times, solved it. More specifically; Writing a generic MSDOS type MBR on the disk. I've forgotten the incantation. But it can be done from the live FreeBSD install media, or the GPARTD CD, if you have one. HTH --Chris > > thanks, > -- > John > _______________________________________________ > 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 Sep 11 16:38:05 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34385E64; Thu, 11 Sep 2014 16:38:05 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 567F83ED; Thu, 11 Sep 2014 16:38:04 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id w7so8177392lbi.31 for ; Thu, 11 Sep 2014 09:38:02 -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=UYKItcEII11XVL2KYlaHFNDRNPua4ftzn7R9y6Agpt4=; b=WC5aZV5vS8w3dADuyHoBKcYo3Pyc4bfoQsvdE5BcWoH+2k3j/Hn4ZR9q1mTzs98x7j Fz+H8VtVg2XuB9KWXBRO6YF1MOxPP+5R/bO+OHzHjALp/azMokoioyMJqIU0L+C5gqOK BQYRbtfUpD25yJjEihM64fc7KUmnPurL7UGgOVuwbwJxETts9UKU9rYEHJ3WCUV/3FZb hIqW0oiECQb2kQhsmrMo61WsKX1/q33bTPRm9QdfrqFeBRiFmRgag6Y4QDms8bMc7LM2 QTaKBoFpV2aKz63ANYNnUFhDZbZEYk9HGtPAN0+/h/YQARVwhQHSW+I0nCbJk6isuI4h WfUQ== MIME-Version: 1.0 X-Received: by 10.112.170.138 with SMTP id am10mr2486248lbc.74.1410453482116; Thu, 11 Sep 2014 09:38:02 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.112.58.164 with HTTP; Thu, 11 Sep 2014 09:38:02 -0700 (PDT) In-Reply-To: <540FF706.2050400@freebsd.org> References: <540E14C4.9080201@freebsd.org> <540E26E6.5070700@freebsd.org> <540FF706.2050400@freebsd.org> Date: Thu, 11 Sep 2014 12:38:02 -0400 X-Google-Sender-Auth: 2l82bd-dntFOVDrfMknr_62OqUk Message-ID: Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient From: Patrick Kelsey To: Andrey Chernov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , 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, 11 Sep 2014 16:38:05 -0000 On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > On 09.09.2014 21:53, Patrick Kelsey wrote: > > I don't think it is worth the trouble, as given the larger pattern of > > libc routines requiring multiple capsicum rights, it seems one will in > > general have to have libc implementation knowledge when using it in > > concert with capsicum. For example, consider the limitfd() routine in > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > stdout so the eventual call to isatty() via printf() will work as > intended. > > > > I think the above kdump example is a good one for the subtle issues that > > can arise when using capsicum with libc. That call to isatty() is via a > > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > > to a tty is line buffered by default. It would appear that programs > > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > > could be disabling the normally default line buffering when stdout is a > > tty. kdump goes the distance, but dhclient does not (restricting stdout > > to CAP_WRITE only). > > > > In any event, the patch attached to my first message is seeming like the > > way to go. > > Well, then commit it (if capsicum team agrees). > > > Will do - thanks for the feedback. -Patrick From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 20:29:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE88A417; Thu, 11 Sep 2014 20:29:20 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4D828FE8; Thu, 11 Sep 2014 20:29:19 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EABjPEVSDaFve/2dsb2JhbABfg2BXBIJ4xUIKhnlUAYEneIQDAQEBAwEBAQEgBCcgCwUWGAICDRkCKQEJJgYIBwQBHASIGQgNqTKVUQEXgSyNSQcBAQEaNAeCeYFTBZUeW4QAhGKTWoN9IS8HfwkXIoEHAQEB X-IronPort-AV: E=Sophos;i="5.04,507,1406606400"; d="scan'208";a="154629762" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 11 Sep 2014 16:29:12 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 85EA4B4090; Thu, 11 Sep 2014 16:29:12 -0400 (EDT) Date: Thu, 11 Sep 2014 16:29:12 -0400 (EDT) From: Rick Macklem To: Hans Petter Selasky Message-ID: <1658973011.35255303.1410467352538.JavaMail.root@uoguelph.ca> In-Reply-To: <54117DCD.5090701@selasky.org> Subject: Re: [RFC] Patch to improve TSO limitation formula in general MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: George Neville-Neil , FreeBSD Current , Scott Long , Jack F Vogel 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, 11 Sep 2014 20:29:20 -0000 Hans Petter Selasky wrote: > Hi Rick, > > Did you get a chance to look further at my patch? > Ok, I just took a quick look. (I didn't try and figure out if the code in tcp_output() looked correct.) > Is this something we can commit? > Well, I'd like to sound more positive, but here are a number of problems I see with the patch: 1 - if_hw_tsomax is already in use by at least one driver, so I think it would be a POLA violation to replace it and make it very difficult to MFC. --> I'd leave if_hw_tsomax as is and add your new stuff as separate fields so things don't get broken for drivers that don't support your new fields. 2 - As above, most drivers don't even set if_hw_tsomax, so it will take some time for drivers to be converted. --> As such, the defaults need to be such that an NFS mbuf list of 35 mbufs totalling just over 64K works. (The drivers that handle 32 mbufs in a list need to get an mbuf list with no more that 64K minus ethernet headers, so they can squeeze the TSO segment into 32 mclbyte mbuf clusters via m_defrag().) 3 - I don't think making the fields "log 2" is necessary or appropriate. Many current drivers support 35 mbufs in the fragment list. This is enough for NFS and is not a power of 2. I think each field should be just a u_int that can replace spares in "struct ifnet". --> I do not think that the size of ethernet headers needs to be specified if if_hw_tsomax still exists, since the driver can reduce the max size by that much. (It also varies depending on network type and whether or not VLAN headers are done by the hardware or driver.) In summary, I'd add two u_ints to "struct ifnet": 1 - for max size of a fragment 2 - for max # of transmit fragments then I'd set the defaults for these so that current code (ie. old drivers) don't break. This would probably mean a large default for both of these along with the current default value for if_hw_tsomax. Then the fun part..Make tcp_output() generate TSO segments that are limited by all three of the above. rick ps: Hopefully others will comment on this, since I'm not a networking guy. (I just ended up involved in this because NFS over TSO enabled net interfaces was badly broken and I got tired of telling people to disable TSO.) > --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 Thu Sep 11 23:18:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A99B4B5 for ; Thu, 11 Sep 2014 23:18:44 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5662B30E for ; Thu, 11 Sep 2014 23:18:44 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id hn15so93685igb.7 for ; Thu, 11 Sep 2014 16:18:37 -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:from:date :message-id:subject:to:cc:content-type; bh=KzpeN0WVAlNLyvcGHESNMHjx8Yzgp3nUKSB5H+DSP+0=; b=Fhmr9Gor9lsw6xHwTbcOvgJrZGvH+vyyg4Ics1vIP4ke/rRFMtz0y+c0XwQ9S00Ss6 HafspZO9v2MJolXf69mzSn0ruvUYYmPjm9fuIVCIryFE4TE3YIKzqMRE6HBrabv0o1bW y2ol6qPddax001HdM1RYBx8CZZLnpFFtCh2bNFf9OyfNw72YiQ3lJyrD3ZirWRHwlfzs tx2PBQwQkhJTvIVOEl39/3CzfIknFESY9nPC3FYYJ/u/IL8HmJ/a8QpZV8ChBsftbrR0 T+wYEM6kcqKa/1wwE5QvOxuWmAZSuv6weeOk6SgznbT/5B91sm46GvWIwevJMTSv64Ui O8jQ== X-Gm-Message-State: ALoCoQkJv2FB6idChyUSymcIu+sqT6jGR2clgxwkqcqLV93hwkftbeDzDaGclenP5+I89ciVgNrxaflwguNmVA6DSRBY0sbTOWDdJtjuOY2PbQHGAnP14aqsmUjv+5cYNI7zS6X+2BUr X-Received: by 10.43.79.135 with SMTP id zq7mr5844788icb.33.1410477517560; Thu, 11 Sep 2014 16:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.110.74 with HTTP; Thu, 11 Sep 2014 16:18:21 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Fri, 12 Sep 2014 08:18:21 +0900 Message-ID: Subject: Re: Intel i915 GPU hung To: "Ranjan1018 ." <214748mv@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-x11@freebsd.org" , 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: Thu, 11 Sep 2014 23:18:44 -0000 I often get this on HD3000 when I push the GPU too hard.. (Well not really hard at all, but the harder I push it the sooner I get GPU crash). After the crash the desktop works fine but pure OpenGL apps don't (ie nothing shows up on the screen). I assume it has switched to software rendering(?) I'll try to get the error_state next time and post it. This is the only problem I have running FreeBSD on my Intel laptop and it is quite annoying when computer (GPU) crashes during demo for visitors and potential customers.. Anyone have any clue on what the problem might be? On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . <214748mv@gmail.com> wrote: > Hello, > > I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated > Intel HD Graphics 4000, to: > > FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep = 10 > 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd6= 4 > > Using Firefox, after some minutes, I receive the error: > > error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > elapsed... GPU hung > info: [drm] capturing error event; look for more information in sysctl > hw.dri.0.info.i915_error_state > > This error is not related to r271400, but I first saw it few months ago i= n > current. > > The output of the command > sysctl hw.dri.0.info.i915_error_state > is: > > > https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=3Ds= haring > > After the error I am not able to run mplayer for videos: the window is > black. > > Regards, > Maurizio > _______________________________________________ > 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 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@FreeBSD.ORG Thu Sep 11 23:47:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64B08B07; Thu, 11 Sep 2014 23:47:04 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FBC37DC; Thu, 11 Sep 2014 23:47:04 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wm4so5809114obc.34 for ; Thu, 11 Sep 2014 16:47:03 -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=NPpellMEKipdrK30M8Id/kxpQQJr5f+cke6df+9B71Q=; b=X3x4GnZ5PbHOFmJn5L/Kib+lUXvYh+GZbuDArkmOQAOfdXaW5k3vh0i0ypMahu+rvp 3vHgbEPCvufDEchQ5saM5+FwlGk+w8B/fiGCcHMorW3/u5IlvAUCIpNdYDx0LxOYvh+s 22L1vJCjJ3P3rG6FqLGzAg61XWcZ/xFmXMzv0slMWJbh4xc+w3EFcj6hf6rVeAW4Z4J5 v/vl6kElX+vGfvjIkk0Eh9rbEhuKkL3OVWhkb0jfyUHQOm+MZL2nah7Ob5Uqyca7koF/ JRfiSdKuzSBvjdoO8WLXLbQ69Zq6d/3gJtHMB6+i3CbryjY7+NUeK3lS1cGRlvzdD6Kc IxVw== X-Received: by 10.60.179.163 with SMTP id dh3mr4719846oec.42.1410479223385; Thu, 11 Sep 2014 16:47:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.151.1 with HTTP; Thu, 11 Sep 2014 16:46:23 -0700 (PDT) In-Reply-To: References: From: Henry Hu Date: Thu, 11 Sep 2014 19:46:23 -0400 Message-ID: Subject: Re: Intel i915 GPU hung To: "Lundberg, Johannes" X-Mailman-Approved-At: Thu, 11 Sep 2014 23:53:51 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ranjan1018 ." <214748mv@gmail.com>, "freebsd-x11@freebsd.org" , 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: Thu, 11 Sep 2014 23:47:04 -0000 On Thu, Sep 11, 2014 at 7:18 PM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > I often get this on HD3000 when I push the GPU too hard.. (Well not reall= y > hard at all, but the harder I push it the sooner I get GPU crash). After > the crash the desktop works fine but pure OpenGL apps don't (ie nothing > shows up on the screen). I assume it has switched to software rendering(?= ) > > I'll try to get the error_state next time and post it. > > This is the only problem I have running FreeBSD on my Intel laptop and it > is quite annoying when computer (GPU) crashes during demo for visitors an= d > potential customers.. > > Anyone have any clue on what the problem might be? > If possible, have you tried the "SNA" acceleration method? Just add Option "AccelMethod" "sna" to your device section of xorg.conf. I had GPU hung before, and after I switched to SNA, it never happened. > > On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . <214748mv@gmail.com> wrote= : > > > Hello, > > > > I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated > > Intel HD Graphics 4000, to: > > > > FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Se= p > 10 > > 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS > amd64 > > > > Using Firefox, after some minutes, I receive the error: > > > > error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > > elapsed... GPU hung > > info: [drm] capturing error event; look for more information in sysctl > > hw.dri.0.info.i915_error_state > > > > This error is not related to r271400, but I first saw it few months ago > in > > current. > > > > The output of the command > > sysctl hw.dri.0.info.i915_error_state > > is: > > > > > > > https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=3Ds= haring > > > > After the error I am not able to run mplayer for videos: the window is > > black. > > > > Regards, > > Maurizio > > _______________________________________________ > > 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" > > > > -- > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6= =EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81= =97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98= =E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3= =82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 > =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96= =E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5= =A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5= =88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 > =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE= =E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8= =A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81= =84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C= =E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3= =81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 > --- > CONFIDENTIALITY NOTE: The information in this email is confidential > and intended solely for the addressee. > Disclosure, copying, distribution or any other action of use of this > email by person other than intended recipient, is prohibited. > If you are not the intended recipient and have received this email in > error, please destroy the original message. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > --=20 Cheers, Henry From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 00:15:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D8EB4C9 for ; Fri, 12 Sep 2014 00:15:16 +0000 (UTC) Received: from kefka.worrbase.com (kefka.csh.rit.edu [129.21.49.25]) (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 1D02FA5B for ; Fri, 12 Sep 2014 00:15:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]); by kefka.worrbase.com (OpenSMTPD) with ESMTP id e791c4bb; for ; Thu, 11 Sep 2014 17:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=worrbase.com; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=mail; t=1410480498; x=1412294899; bh=hpauiuPn9i4M/P Wfp26BBRjflNuDV5aArRtzow+xnyI=; b=q7ojQPQrpvQH2daGW+flXsyL+LboBB Cs6yzi1QRkY+ihpfjjByRTNIkOhzPEA74aGJ5zGK4HJK4aGw6qH9UF112qBWCv8X OyFrwF/T5kmf8DJpYVv+s86/kv+6JvZDsXwlRHg0NMqpHynvTWIiF/HIefsH1X6J vYzcWCpFnnORcTFx/BuFAgGhgen3o7y2dRbwcbcb/tygMIq9C8cTFyQQHeZGsNNS rHfo0CrwaCgitMIyK+TvrNpZN3sNzpbtXSWZExjfy7uDDzuk/UJ0kuEOuuXFk5Xq l2OUyJ9SJQ3ziCsNhFacgAbc/CJR5TmMfcYT7EpxaRxEBnWPeXfY8dmCEsOt6+2e 6M7n48Q4kdBnUhmDMi/yeLbH0O2WLsX8ilFmHEsmybpImvBziNRoIHU+p5R4fMTp q6jXARThY+uRq3BHSo6Q1gCZ05JCxEvaNZtQ511jLPeQRv9H1wMGtOKWAiD4buP8 m63r1cYDZXT/4ixMfwrWpNthO2OTlg5cin2rXt6xHs+LyNwuYcVo/jzSYd4m/UXQ l+2sknI6FfPyyuolFxBPJ6GPyQbY0nM/xayJkaqquYt+Xo8+0TvFz3rn0JduLpvr GS/GXaIG9lhAAbgTQtZPmRSU7aMXDKYb2caYTL9VJfixdJcuVdmZppxhWOtUDy6s csZPvilNgPE3g= X-Virus-Scanned: amavisd-new at worrbase.com Received: from kefka.worrbase.com ([IPv6:::1]) by localhost (kefka.worrbase.com [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id y_ewQ8z3mYgu for ; Thu, 11 Sep 2014 17:08:18 -0700 (PDT) Received: from [IPv6:2620:119:5001:2231:a94a:31cc:23c0:7ff2] (2620:119:5001:2231:a94a:31cc:23c0:7ff2 [IPv6:2620:119:5001:2231:a94a:31cc:23c0:7ff2]); by kefka.worrbase.com (OpenSMTPD) with ESMTPSA id c28fe682; TLS version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO; for ; Thu, 11 Sep 2014 17:08:18 -0700 (PDT) Message-ID: <5412396C.1070304@worrbase.com> Date: Thu, 11 Sep 2014 17:08:12 -0700 From: William Orr User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Inconsistent behavior with dd(1) References: <3C86F281-D618-4B93-BBA3-2DA33AC407EC@worrbase.com> <20140816173439.GZ83475@funkthat.com> <53F24D60.4080107@worrbase.com> <53FC11C8.5050803@worrbase.com> In-Reply-To: <53FC11C8.5050803@worrbase.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TtDSoreIoo6TL953mAev6FNls70kAmBdP" 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, 12 Sep 2014 00:15:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TtDSoreIoo6TL953mAev6FNls70kAmBdP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey, any thoughts on this? Does it need more work? Can it get merged? On 08/25/2014 09:49 PM, William Orr wrote: > On 8/18/14 12:00 PM, William Orr wrote: >> Reply inline. >> >> On 08/16/2014 10:34 AM, John-Mark Gurney wrote: >>> Alan Somers wrote this message on Fri, Aug 15, 2014 at 10:42 -0600: >>>> On Thu, Aug 14, 2014 at 11:55 PM, William Orr >>>> wrote: >>>>> Hey, >>>>> >>>>> I found some inconsistent behavior with dd(1) when it comes to >>>>> specifying arguments in -CURRENT. >>>>> >>>>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null >>>>> count=3D18446744073709551616 >>>>> dd: count: Result too large >>>>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null >>>>> count=3D18446744073709551617 >>>>> dd: count: Result too large >>>>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null >>>>> count=3D18446744073709551615 >>>>> dd: count cannot be negative >>>>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null >>>>> count=3D-18446744073709551615 >>>>> 1+0 records in >>>>> 1+0 records out >>>>> 512 bytes transferred in 0.000373 secs (1373071 bytes/sec) >>>>> [ worr on terra ] ( ~ ) % dd if=3D/dev/zero of=3D/dev/null count=3D= -1 >>>>> dd: count cannot be negative >>>>> >>>>> ??? >>>>> >>>>> Any chance someone has the time and could take a look? >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191263 >>>>> >>>>> Thanks, >>>>> William Orr >>>>> >>>>> ??? >>>> >>>> IMHO, this is a bug in strtouq(3), not in dd(1). Why should it pars= e >>>> negative numbers at all, when there is stroq(3) for that purpose? T= he >>>> standard is clear that it must, though. Oddly enough, stroq would >>>> probably not accept -18446744073709551615, even though strtouq does.= >>>> Specific comments on your patch below: >>>> >>>> >>>>> Here???s the patch: >>>>> >>>>> Index: bin/dd/args.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 >>>>> --- bin/dd/args.c (revision 267712) >>>>> +++ bin/dd/args.c (working copy) >>>>> @@ -186,46 +186,31 @@ >>>>> static void >>>>> f_bs(char *arg) >>>>> { >>>>> - uintmax_t res; >>>>> - >>>>> - res =3D get_num(arg); >>>>> - if (res < 1 || res > SSIZE_MAX) >>>>> - errx(1, "bs must be between 1 and %jd", >>>>> (intmax_t)SSIZE_MAX); >>>>> - in.dbsz =3D out.dbsz =3D (size_t)res; >>>>> + in.dbsz =3D out.dbsz =3D get_num(arg); >>>>> + if (in.dbsz < 1 || out.dbsz < 1) >>>> Why do you need to check both in and out? Aren't they the same? >>>> Also, you eliminated the check for overflowing SSIZE_MAX. That's no= t >>>> ok, because these values get passed to places that expect signed >>>> numbers, for example in dd.c:303. >>> The type of dbsz is size_t, so really: >>> >>>>> + errx(1, "bs must be between 1 and %ju", >>>>> (uintmax_t)-1); >>> This should be SIZE_MAX, except there isn't a define for this? So ma= ybe >>> the code really should be: >>> (uintmax_t)(size_t)-1 >>> >>> to get the correct value for SIZE_MAX... >>> >>> Otherwise on systems that uintmax_t is >32bits and size_t is 32bits, >>> the error message will be wrong... >> Yes, this should probably be SIZE_MAX rather than that cast. Same with= >> the others >> >>>>> } >>>>> >>>>> static void >>>>> f_cbs(char *arg) >>>>> { >>>>> - uintmax_t res; >>>>> - >>>>> - res =3D get_num(arg); >>>>> - if (res < 1 || res > SSIZE_MAX) >>>>> - errx(1, "cbs must be between 1 and %jd", >>>>> (intmax_t)SSIZE_MAX); >>>>> - cbsz =3D (size_t)res; >>>>> + cbsz =3D get_num(arg); >>>>> + if (cbsz < 1) >>>>> + errx(1, "cbs must be between 1 and %ju", >>>>> (uintmax_t)-1); >>>>> } >>>> Again, you eliminated the check for SSIZE_MAX, but cbsz must be sign= ed. >>> What do you mean by this? cbsz is size_t which is unsigned... >> I believe he's referring to this use of cbsz/in.dbsz/out.dbsz: >> >> https://svnweb.freebsd.org/base/head/bin/dd/dd.c?revision=3D265698&vie= w=3Dmarkup#l171 >> >> >> Really, this is more wrong since there is math inside of a malloc(3) >> call without any overflow handling. By virtue of making this max out a= t >> a ssize_t, it becomes more unlikely that you'll have overflow. >> >> This math should probably be done ahead of time with proper overflow >> handling. I'll include that in my next patch, if there's no objection.= >> >> I don't see any other reason why in.dbsz, out.dbsz or cbsz should be >> signed, but it's very possible that I didn't look hard enough. >> >>> Again, the cast above is wrong... Maybe we should add a SIZE_MAX >>> define so we don't have to see the double cast... >>> >>>>> static void >>>>> f_count(char *arg) >>>>> { >>>>> - intmax_t res; >>>>> - >>>>> - res =3D (intmax_t)get_num(arg); >>>>> - if (res < 0) >>>>> - errx(1, "count cannot be negative"); >>>>> - if (res =3D=3D 0) >>>>> - cpy_cnt =3D (uintmax_t)-1; >>>> This is a special case. See dd_in(). I think that eliminating this= >>>> special case will have the unintended effect of breaking count=3D0. >>>> >>>>> - else >>>>> - cpy_cnt =3D (uintmax_t)res; >>>>> + cpy_cnt =3D get_num(arg); >>>>> } >>>>> >>>>> static void >>>>> f_files(char *arg) >>>>> { >>>>> - >>> Don't eliminate these blank lines.. they are intentional per style(9)= : >>> /* Insert an empty line if the function has no local >>> variables. */ >>> >>>>> files_cnt =3D get_num(arg); >>>>> if (files_cnt < 1) >>>>> - errx(1, "files must be between 1 and %jd", >>>>> (uintmax_t)-1); >>>>> + errx(1, "files must be between 1 and %ju", >>>>> (uintmax_t)-1); >>>> Good catch. >>>> >>>>> } >>>>> >>>>> static void >>>>> @@ -241,14 +226,10 @@ >>>>> static void >>>>> f_ibs(char *arg) >>>>> { >>>>> - uintmax_t res; >>>>> - >>>>> if (!(ddflags & C_BS)) { >>>>> - res =3D get_num(arg); >>>>> - if (res < 1 || res > SSIZE_MAX) >>>>> - errx(1, "ibs must be between 1 and %jd", >>>>> - (intmax_t)SSIZE_MAX); >>>>> - in.dbsz =3D (size_t)res; >>>>> + in.dbsz =3D get_num(arg); >>>>> + if (in.dbsz < 1) >>>>> + errx(1, "ibs must be between 1 and %ju", >>>>> (uintmax_t)-1); >>>> Again, you eliminated the check for SSIZE_MAX, but dbsz must be sign= ed. >>> If dbsz must be signed, we should change it's definition to ssize_t >>> instead of size_t... Can you point to the line that says this? >>> >>> In investigating this, it looks like we may have a bug in ftruncate i= n >>> that out.offset * out.dbsz may overflow and return incorrect results.= =2E. >>> We should probably check that the output (cast to off_t) is greater t= han >>> both the inputs before calling ftruncate... This is safe as both are= >>> unsigned... >> Yeah, there probably ought to be integer overflow handling here as wel= l. >> >>>>> } >>>>> } >>>>> >>>>> @@ -262,14 +243,10 @@ >>>>> static void >>>>> f_obs(char *arg) >>>>> { >>>>> - uintmax_t res; >>>>> - >>>>> if (!(ddflags & C_BS)) { >>>>> - res =3D get_num(arg); >>>>> - if (res < 1 || res > SSIZE_MAX) >>>>> - errx(1, "obs must be between 1 and %jd", >>>>> - (intmax_t)SSIZE_MAX); >>>>> - out.dbsz =3D (size_t)res; >>>>> + out.dbsz =3D get_num(arg); >>>>> + if (out.dbsz < 1) >>>>> + errx(1, "obs must be between 1 and %ju", >>>>> (uintmax_t)-1); >>>>> } >>>>> } >>>> Again, you eliminated the check for SSIZE_MAX, but dbsz must be sign= ed. >>>> >>>>> @@ -378,11 +355,14 @@ >>>>> uintmax_t num, mult, prevnum; >>>>> char *expr; >>>>> >>>>> + if (val[0] =3D=3D '-') >>>>> + errx(1, "%s: cannot be negative", oper); >>>>> + >>>> In general, I like this part of the diff. Every user of get_num >>>> checks for negative values, so why not move the check into get_num >>>> itself? But you changed it from a numeric check to a text check, an= d >>>> writing text parsers makes me nervous. I can't see any problems, >>>> though. >> Funnily enough this part of the diff was wrong. I didn't account for >> spaces, so I'll add that in my upcoming diff. >> >>>>> errno =3D 0; >>>>> num =3D strtouq(val, &expr, 0); >>>>> if (errno !=3D 0) /* Overflow or >>>>> underflow. */ >>>>> err(1, "%s", oper); >>>>> - >>>>> + >>>>> if (expr =3D=3D val) /* No valid >>>>> digits. */ >>>>> errx(1, "%s: illegal numeric value", oper); >>>>> >>>>> Index: bin/dd/dd.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 >>>>> --- bin/dd/dd.c (revision 267712) >>>>> +++ bin/dd/dd.c (working copy) >>>>> @@ -284,8 +284,6 @@ >>>>> >>>>> for (;;) { >>>>> switch (cpy_cnt) { >>>>> - case -1: /* count=3D0 was >>>>> specified */ >>>>> - return; >>>> Again, I don't think this will do what you want it to do. Previousl= y, >>>> leaving count unspecified resulted in cpy_cnt being 0, and specifyin= g >>>> count=3D0 set cpy_cnt to -1. With your patch, setting count=3D0 wil= l have >>>> the same effect as leaving it unspecified. >> Nope. It didn't do what I wanted. I'll submit an updated diff with thi= s >> fixed as well as the other things I mentioned, provided there's no >> objection to my direction. >> >>>>> case 0: >>>>> break; >>>>> default: >>>>> >>>>> > Here is a new version of this patch. I've now changed the members of th= e > struct that are used as ssize_ts to ssize_ts, and have fixed casts > appropriately. I have also opted for strtoull over the deprecated > strtouq. I changed some struct members that were declared as uintmax_t'= s > to size_t's. >=20 > Any comments? Criticisms? Gross attacks on my character? >=20 > Index: args.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 > --- args.c (revision 270645) > +++ args.c (working copy) > @@ -41,6 +41,7 @@ >=20 > #include >=20 > +#include > #include > #include > #include > @@ -171,8 +172,7 @@ > */ > if (in.offset > OFF_MAX / (ssize_t)in.dbsz || > out.offset > OFF_MAX / (ssize_t)out.dbsz) > - errx(1, "seek offsets cannot be larger than %jd", > - (intmax_t)OFF_MAX); > + errx(1, "seek offsets cannot be larger than %jd", OFF_MAX); > } >=20 > static int > @@ -186,37 +186,28 @@ > static void > f_bs(char *arg) > { > - uintmax_t res; >=20 > - res =3D get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "bs must be between 1 and %jd", (intmax_t)SSIZE_MAX); > - in.dbsz =3D out.dbsz =3D (size_t)res; > + in.dbsz =3D out.dbsz =3D get_num(arg); > + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) > + errx(1, "bs must be between 1 and %jd", SSIZE_MAX); > } >=20 > static void > f_cbs(char *arg) > { > - uintmax_t res; >=20 > - res =3D get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "cbs must be between 1 and %jd", (intmax_t)SSIZE_MAX);= > - cbsz =3D (size_t)res; > + cbsz =3D get_num(arg); > + if (cbsz < 1 || cbsz > SSIZE_MAX) > + errx(1, "cbs must be between 1 and %jd", SSIZE_MAX); > } >=20 > static void > f_count(char *arg) > { > - intmax_t res; >=20 > - res =3D (intmax_t)get_num(arg); > - if (res < 0) > - errx(1, "count cannot be negative"); > - if (res =3D=3D 0) > - cpy_cnt =3D (uintmax_t)-1; > - else > - cpy_cnt =3D (uintmax_t)res; > + cpy_cnt =3D get_num(arg); > + if (cpy_cnt =3D=3D 0) > + cpy_cnt =3D -1; > } >=20 > static void > @@ -225,7 +216,7 @@ >=20 > files_cnt =3D get_num(arg); > if (files_cnt < 1) > - errx(1, "files must be between 1 and %jd", (uintmax_t)-1); > + errx(1, "files must be between 1 and %ju", SIZE_MAX); > } >=20 > static void > @@ -241,14 +232,11 @@ > static void > f_ibs(char *arg) > { > - uintmax_t res; >=20 > if (!(ddflags & C_BS)) { > - res =3D get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "ibs must be between 1 and %jd", > - (intmax_t)SSIZE_MAX); > - in.dbsz =3D (size_t)res; > + in.dbsz =3D get_num(arg); > + if (in.dbsz < 1 || in.dbsz > SSIZE_MAX) > + errx(1, "ibs must be between 1 and %ju", SSIZE_MAX); > } > } >=20 > @@ -262,14 +250,11 @@ > static void > f_obs(char *arg) > { > - uintmax_t res; >=20 > if (!(ddflags & C_BS)) { > - res =3D get_num(arg); > - if (res < 1 || res > SSIZE_MAX) > - errx(1, "obs must be between 1 and %jd", > - (intmax_t)SSIZE_MAX); > - out.dbsz =3D (size_t)res; > + out.dbsz =3D get_num(arg); > + if (out.dbsz < 1 || out.dbsz > SSIZE_MAX) > + errx(1, "obs must be between 1 and %jd", SSIZE_MAX); > } > } >=20 > @@ -378,11 +363,17 @@ > uintmax_t num, mult, prevnum; > char *expr; >=20 > + while (isspace(val[0])) > + val++; > + > + if (val[0] =3D=3D '-') > + errx(1, "%s: cannot be negative", oper); > + > errno =3D 0; > - num =3D strtouq(val, &expr, 0); > + num =3D strtoull(val, &expr, 0); > if (errno !=3D 0) /* Overflow or underflow. */ > err(1, "%s", oper); > - > + > if (expr =3D=3D val) /* No valid digits. */ > errx(1, "%s: illegal numeric value", oper); >=20 > Index: conv.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 > --- conv.c (revision 270645) > +++ conv.c (working copy) > @@ -133,7 +133,7 @@ > */ > ch =3D 0; > for (inp =3D in.dbp - in.dbcnt, outp =3D out.dbp; in.dbcnt;) { > - maxlen =3D MIN(cbsz, in.dbcnt); > + maxlen =3D MIN(cbsz, (size_t)in.dbcnt); > if ((t =3D ctab) !=3D NULL) > for (cnt =3D 0; cnt < maxlen && (ch =3D *inp++) !=3D '\n';= > ++cnt) > @@ -146,7 +146,7 @@ > * Check for short record without a newline. Reassemble the > * input block. > */ > - if (ch !=3D '\n' && in.dbcnt < cbsz) { > + if (ch !=3D '\n' && (size_t)in.dbcnt < cbsz) { > (void)memmove(in.db, in.dbp - in.dbcnt, in.dbcnt); > break; > } > @@ -228,7 +228,7 @@ > * translation has to already be done or we might not recognize th= e > * spaces. > */ > - for (inp =3D in.db; in.dbcnt >=3D cbsz; inp +=3D cbsz, in.dbcnt -=3D= cbsz) { > + for (inp =3D in.db; (size_t)in.dbcnt >=3D cbsz; inp +=3D cbsz, in.= dbcnt > -=3D cbsz) { > for (t =3D inp + cbsz - 1; t >=3D inp && *t =3D=3D ' '; --t) > ; > if (t >=3D inp) { > Index: dd.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 > --- dd.c (revision 270645) > +++ dd.c (working copy) > @@ -168,10 +168,10 @@ > * record oriented I/O, only need a single buffer. > */ > if (!(ddflags & (C_BLOCK | C_UNBLOCK))) { > - if ((in.db =3D malloc(out.dbsz + in.dbsz - 1)) =3D=3D NULL) > + if ((in.db =3D malloc((size_t)out.dbsz + in.dbsz - 1)) =3D=3D = NULL) > err(1, "input buffer"); > out.db =3D in.db; > - } else if ((in.db =3D malloc(MAX(in.dbsz, cbsz) + cbsz)) =3D=3D NU= LL || > + } else if ((in.db =3D malloc(MAX((size_t)in.dbsz, cbsz) + cbsz)) =3D= =3D > NULL || > (out.db =3D malloc(out.dbsz + cbsz)) =3D=3D NULL) > err(1, "output buffer"); >=20 > @@ -343,7 +343,7 @@ > ++st.in_full; >=20 > /* Handle full input blocks. */ > - } else if ((size_t)n =3D=3D in.dbsz) { > + } else if ((size_t)n =3D=3D (size_t)in.dbsz) { > in.dbcnt +=3D in.dbrcnt =3D n; > ++st.in_full; >=20 > @@ -493,7 +493,7 @@ > outp +=3D nw; > st.bytes +=3D nw; >=20 > - if ((size_t)nw =3D=3D n && n =3D=3D out.dbsz) > + if ((size_t)nw =3D=3D n && n =3D=3D (size_t)out.dbsz) > ++st.out_full; > else > ++st.out_part; > Index: dd.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- dd.h (revision 270645) > +++ dd.h (working copy) > @@ -38,10 +38,9 @@ > typedef struct { > u_char *db; /* buffer address */ > u_char *dbp; /* current buffer I/O address */ > - /* XXX ssize_t? */ > - size_t dbcnt; /* current buffer byte count */ > - size_t dbrcnt; /* last read byte count */ > - size_t dbsz; /* block size */ > + ssize_t dbcnt; /* current buffer byte count */ > + ssize_t dbrcnt; /* last read byte count */ > + ssize_t dbsz; /* block size */ >=20 > #define ISCHR 0x01 /* character device (warn on short= ) */ > #define ISPIPE 0x02 /* pipe-like (see position.c) */ > @@ -57,13 +56,13 @@ > } IO; >=20 > typedef struct { > - uintmax_t in_full; /* # of full input blocks */ > - uintmax_t in_part; /* # of partial input blocks */ > - uintmax_t out_full; /* # of full output blocks */ > - uintmax_t out_part; /* # of partial output blocks */ > - uintmax_t trunc; /* # of truncated records */ > - uintmax_t swab; /* # of odd-length swab blocks */ > - uintmax_t bytes; /* # of bytes written */ > + size_t in_full; /* # of full input blocks */ > + size_t in_part; /* # of partial input blocks */ > + size_t out_full; /* # of full output blocks */ > + size_t out_part; /* # of partial output blocks */ > + size_t trunc; /* # of truncated records */ > + size_t swab; /* # of odd-length swab blocks */ > + size_t bytes; /* # of bytes written */ > struct timespec start; /* start time of dd */ > } STAT; >=20 > Index: position.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 > --- position.c (revision 270645) > +++ position.c (working copy) > @@ -178,7 +178,7 @@ > n =3D write(out.fd, out.db, out.dbsz); > if (n =3D=3D -1) > err(1, "%s", out.name); > - if ((size_t)n !=3D out.dbsz) > + if (n !=3D out.dbsz) > errx(1, "%s: write failure", out.name); > } > break; >=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.o= rg" --TtDSoreIoo6TL953mAev6FNls70kAmBdP 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.14 (GNU/Linux) iQIcBAEBAgAGBQJUEjlxAAoJEOWIWopNkblksLIP/3qDVPRJBDFO0gO0+TG717IE ocee7AmUkjXxZz6+5TnB/ihA6JsY0A40kkQsbRId/Pe/lMz3wgx9SIckiX+oo3Xy Or625D8kbM6PjgepIQGBEb/HH/qqGeN/UQwF9OZMCPzEnGfeXXovD658rar5b4S6 FTIjdGJzAJGwjHnwM3XJJUcaWfJ1nRUF4gPlCl2TILnXf6fNNOV7X4CXGLklep/v ZIroeZjbWZjHDob3ZU7LCs2zhXgumyZXrT3bzAvxYgGQpo0IaMalSxd/7T9gG9/f GpFz9n7jGfbFW3hoeip58mHORXAW6vcWRFFFQnUiJNU10icugL/GIIPcp3IQ59aH K9G/gv26kSvvhmdYLVeAinvY3Bj9dwswqhUtVRFwHNeBM0xQPkGakZ0M8eJTepRk AIkMDQnb2r1UTwpUS+Vh++mSrgdMCUYkSaDb2jSCypVsDMV/ZJ6DHY/1NBuCELsu UYvWEw7zP47KTCCHgXY/SS7mwnRLsSkO525o39ugo+URXmLe1CQo5UgQEIAivHuU 8Ujn0WzkiTsJJh4+jdUXd/RaQFrDZTzQyfTZjNqSbIEwJ2savt/nT+weBiDxBJgj Vy98+cNrfLDfobAVe1ASDG/rQzfaxNBQgInCTXMQQQwAmvL6GfToC87fDNd5iift ldMTlZtREF1FVm3p8I/L =DLDx -----END PGP SIGNATURE----- --TtDSoreIoo6TL953mAev6FNls70kAmBdP-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 00:30:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA2A9A8A for ; Fri, 12 Sep 2014 00:30:10 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 92D10BF5 for ; Fri, 12 Sep 2014 00:30:10 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id rd18so7655064iec.25 for ; Thu, 11 Sep 2014 17:30:09 -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:from:date :message-id:subject:to:cc:content-type; bh=twSwU3/l3k5rhkqsWEJdf8gMssZkN7FDoxf/Ie+dDV4=; b=AQvPCucQTtTp7WnLboausAH0KOvERhdwxzQ3Fm6ZzocouGGQie3E0A5mYxnfHOWwq2 EOKr2eDd4DZtPR5IBieSJ0iTxvbZCLe4niufZoddBgHD7W69/fGT43lMuVLn6S4MS9SM DNF0bohK/dlBhJ8EHwVtQbBsKaGIoayiZ+bYSUVYxtqtE7AKYpK5OF+Z3ea2YkxKuCN9 KmdyQJlhdsP2drG5PAT1ALAppGEEbskVDaTfLaamXGSsRq2CVKlODdUeI4DFNBLrsPcp y4yPbdXlCEpVQ/JmIvpY4uY3NOM8C9tamwjunn/6aUGlTxKVUXBhKbT69j2NMZGzf54y Nwyg== X-Gm-Message-State: ALoCoQnWaAjulA6D+lzGZUZQ7z+laAdTq2sngzfEjzFJXXzMRfYt/jC1Qs10M/RVyp3jULVtckHLhn17gWa8J9yeL9rf9ccSi0/unhEWR+m9vkj1dTmBd4DlKf7M5fY2sQly3m6ShYcw X-Received: by 10.42.120.72 with SMTP id e8mr5978664icr.64.1410481809246; Thu, 11 Sep 2014 17:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.110.74 with HTTP; Thu, 11 Sep 2014 17:29:54 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Fri, 12 Sep 2014 09:29:54 +0900 Message-ID: Subject: Re: Intel i915 GPU hung To: Henry Hu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ranjan1018 ." <214748mv@gmail.com>, "freebsd-x11@freebsd.org" , 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: Fri, 12 Sep 2014 00:30:10 -0000 SSBoYXZlIGEgZmVlbGluZyBJIHRyaWVkIHRoYXQgYmVmb3JlIGJ1dCBJIHdpbGwgdHJ5IGl0IGFn YWluIGFuZCByZXBvcnQNCmJhY2sgdGhlIHJlc3VsdHMuDQoNCkkgd291bGQgYWxzbyBsaWtlIHRv IGVuYWJsZSB0ZWFyIGZyZWUgYnkgc2V0dGluZyBzd2FwYnVmZmVyc3dhaXQgYW5kDQp0ZWFyZnJl ZSB0byB0cnVlIGJ1dCB3aGVuIHRlc3Rpbmcgd2l0aCBnbHhnZWFycyBJIGdldCB2ZXJ5IHZhcmlh YmxlDQpmcmFtZXJhdGUgYW5kIGplcmt5IGFuaW1hdGlvbi4gSSBkb24ndCBrbm93IGlmIHRoaXMg aXMgYSBidWcgaW4gZ2x4Z2VhcnMgb3INCnNvbWV3aGVyZSBlbHNlLi4uIEFueSBleHBlcmllbmNl IHdpdGggdGhpcz8NCg0KLS0NCkpvaGFubmVzIEx1bmRiZXJnDQpCUklMTElBTlRTRVJWSUNFIENP LiwgTFRELg0KDQpPbiBGcmksIFNlcCAxMiwgMjAxNCBhdCA4OjQ2IEFNLCBIZW5yeSBIdSA8aGVu cnkuaHUuc2hAZ21haWwuY29tPiB3cm90ZToNCg0KPg0KPg0KPiBPbiBUaHUsIFNlcCAxMSwgMjAx NCBhdCA3OjE4IFBNLCBMdW5kYmVyZywgSm9oYW5uZXMgPA0KPiBqb2hhbm5lc0BicmlsbGlhbnRz ZXJ2aWNlLmNvLmpwPiB3cm90ZToNCj4NCj4+IEkgb2Z0ZW4gZ2V0IHRoaXMgb24gSEQzMDAwIHdo ZW4gSSBwdXNoIHRoZSBHUFUgdG9vIGhhcmQuLiAoV2VsbCBub3QgcmVhbGx5DQo+PiBoYXJkIGF0 IGFsbCwgYnV0IHRoZSBoYXJkZXIgSSBwdXNoIGl0IHRoZSBzb29uZXIgSSBnZXQgR1BVIGNyYXNo KS4gQWZ0ZXINCj4+IHRoZSBjcmFzaCB0aGUgZGVza3RvcCB3b3JrcyBmaW5lIGJ1dCBwdXJlIE9w ZW5HTCBhcHBzIGRvbid0IChpZSBub3RoaW5nDQo+PiBzaG93cyB1cCBvbiB0aGUgc2NyZWVuKS4g SSBhc3N1bWUgaXQgaGFzIHN3aXRjaGVkIHRvIHNvZnR3YXJlIHJlbmRlcmluZyg/KQ0KPj4NCj4+ IEknbGwgdHJ5IHRvIGdldCB0aGUgZXJyb3Jfc3RhdGUgbmV4dCB0aW1lIGFuZCBwb3N0IGl0Lg0K Pj4NCj4+IFRoaXMgaXMgdGhlIG9ubHkgcHJvYmxlbSBJIGhhdmUgcnVubmluZyBGcmVlQlNEIG9u IG15IEludGVsIGxhcHRvcCBhbmQgaXQNCj4+IGlzIHF1aXRlIGFubm95aW5nIHdoZW4gY29tcHV0 ZXIgKEdQVSkgY3Jhc2hlcyBkdXJpbmcgZGVtbyBmb3IgdmlzaXRvcnMgYW5kDQo+PiBwb3RlbnRp YWwgY3VzdG9tZXJzLi4NCj4+DQo+PiBBbnlvbmUgaGF2ZSBhbnkgY2x1ZSBvbiB3aGF0IHRoZSBw cm9ibGVtIG1pZ2h0IGJlPw0KPj4NCj4NCj4gSWYgcG9zc2libGUsIGhhdmUgeW91IHRyaWVkIHRo ZSAiU05BIiBhY2NlbGVyYXRpb24gbWV0aG9kPyBKdXN0IGFkZA0KPiAgICAgT3B0aW9uICJBY2Nl bE1ldGhvZCIgInNuYSINCj4gdG8geW91ciBkZXZpY2Ugc2VjdGlvbiBvZiB4b3JnLmNvbmYuDQo+ DQo+IEkgaGFkIEdQVSBodW5nIGJlZm9yZSwgYW5kIGFmdGVyIEkgc3dpdGNoZWQgdG8gU05BLCBp dCBuZXZlciBoYXBwZW5lZC4NCj4NCj4NCj4+DQo+PiBPbiBUaHUsIFNlcCAxMSwgMjAxNCBhdCAx MTo0OSBQTSwgUmFuamFuMTAxOCAuIDwyMTQ3NDhtdkBnbWFpbC5jb20+DQo+PiB3cm90ZToNCj4+ DQo+PiA+IEhlbGxvLA0KPj4gPg0KPj4gPiBJIGhhdmUganVzdCB1cGdyYWRlIG15IGxhcHRvcCwg YSBTYW1zdW5nIEF0aXYgQm9vayAyIHdpdGggYW4gaW50ZWdyYXRlZA0KPj4gPiBJbnRlbCBIRCBH cmFwaGljcyA0MDAwLCB0bzoNCj4+ID4NCj4+ID4gRnJlZUJTRCBhdGl2LmxvY2FsIDExLjAtQ1VS UkVOVCBGcmVlQlNEIDExLjAtQ1VSUkVOVCAjMCByMjcxNDAwOiBXZWQNCj4+IFNlcCAxMA0KPj4g PiAyMTo0MDo0OCBDRVNUIDIwMTQgICAgIHJvb3RAYXRpdi5sb2NhbDovdXNyL29iai91c3Ivc3Jj L3N5cy9ORVdDT05TDQo+PiBhbWQ2NA0KPj4gPg0KPj4gPiBVc2luZyBGaXJlZm94LCBhZnRlciBz b21lIG1pbnV0ZXMsIEkgcmVjZWl2ZSB0aGUgZXJyb3I6DQo+PiA+DQo+PiA+IGVycm9yOiBbZHJt OnBpZDEyOmk5MTVfaGFuZ2NoZWNrX2VsYXBzZWRdICpFUlJPUiogSGFuZ2NoZWNrIHRpbWVyDQo+ PiA+IGVsYXBzZWQuLi4gR1BVIGh1bmcNCj4+ID4gaW5mbzogW2RybV0gY2FwdHVyaW5nIGVycm9y IGV2ZW50OyBsb29rIGZvciBtb3JlIGluZm9ybWF0aW9uIGluIHN5c2N0bA0KPj4gPiBody5kcmku MC5pbmZvLmk5MTVfZXJyb3Jfc3RhdGUNCj4+ID4NCj4+ID4gVGhpcyBlcnJvciBpcyBub3QgcmVs YXRlZCB0byByMjcxNDAwLCBidXQgSSBmaXJzdCBzYXcgaXQgZmV3IG1vbnRocyBhZ28NCj4+IGlu DQo+PiA+IGN1cnJlbnQuDQo+PiA+DQo+PiA+IFRoZSBvdXRwdXQgb2YgdGhlIGNvbW1hbmQNCj4+ ID4gc3lzY3RsIGh3LmRyaS4wLmluZm8uaTkxNV9lcnJvcl9zdGF0ZQ0KPj4gPiBpczoNCj4+ID4N Cj4+ID4NCj4+ID4NCj4+IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ6b1dRb01x cTFzZmEwdHlWR0pWWVZCaFJuYy9lZGl0P3VzcD1zaGFyaW5nDQo+PiA+DQo+PiA+IEFmdGVyIHRo ZSBlcnJvciBJIGFtIG5vdCBhYmxlIHRvIHJ1biBtcGxheWVyIGZvciB2aWRlb3M6IHRoZSB3aW5k b3cgaXMNCj4+ID4gYmxhY2suDQo+PiA+DQo+PiA+IFJlZ2FyZHMsDQo+PiA+IE1hdXJpemlvDQo+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4+ID4gaHR0cDovL2xp c3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50DQo+PiA+IFRv IHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICINCj4+IGZyZWVic2QtY3VycmVudC11bnN1 YnNjcmliZUBmcmVlYnNkLm9yZyINCj4+ID4NCj4+DQo+PiAtLQ0KPj4gPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tDQo+PiDnp5jlr4bkv53mjIHj gavjgaTjgYTjgabvvJrjgZPjga7pm7vlrZDjg6Hjg7zjg6vjga/jgIHlkI3lrpvkurrjgavpgIHk v6HjgZfjgZ/jgoLjga7jgafjgYLjgorjgIHnp5jljL/nibnmqKnjga7lr77osaHjgajjgarjgovm g4XloLHjgpLlkKvjgpPjgafjgYTjgb7jgZnjgIINCj4+IOOCguOBl+OAgeWQjeWum+S6uuS7peWk luOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruODoeODvOODq+OBruegtOaj hOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4gOWIh+OBrumWi+ekuuOA gQ0KPj4g6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY 6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI 44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CCDQo+PiAtLS0NCj4+IENPTkZJREVOVElB TElUWSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRpYWwN Cj4+IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuDQo+PiBEaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgYW55IG90aGVyIGFjdGlvbiBvZiB1c2Ugb2YgdGhp cw0KPj4gZW1haWwgYnkgcGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBw cm9oaWJpdGVkLg0KPj4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQg aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluDQo+PiBlcnJvciwgcGxlYXNlIGRlc3Ryb3kgdGhl IG9yaWdpbmFsIG1lc3NhZ2UuDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gZnJlZWJzZC14MTFAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+ PiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXgxMQ0K Pj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QteDExLXVuc3Vic2Ny aWJlQGZyZWVic2Qub3JnIg0KPj4NCj4NCj4NCj4NCj4gLS0NCj4gQ2hlZXJzLA0KPiBIZW5yeQ0K Pg0KCi0tIAo9LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09 LT0tPS0K56eY5a+G5L+d5oyB44Gr44Gk44GE44Gm77ya44GT44Gu6Zu75a2Q44Oh44O844Or44Gv 44CB5ZCN5a6b5Lq644Gr6YCB5L+h44GX44Gf44KC44Gu44Gn44GC44KK44CB56eY5Yy/54m55qip 44Gu5a++6LGh44Go44Gq44KL5oOF5aCx44KS5ZCr44KT44Gn44GE44G+44GZ44CCCuOCguOBl+OA geWQjeWum+S6uuS7peWkluOBruaWueOBjOWPl+S/oeOBleOCjOOBn+WgtOWQiOOAgeOBk+OBruOD oeODvOODq+OBruegtOajhOOAgeOBiuOCiOOBs+OBk+OBruODoeODvOODq+OBq+mWouOBmeOCi+S4 gOWIh+OBrumWi+ekuuOAgQropIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHj gb7jgZ/jga/oqJjovInlhoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXj gozjgarjgYTjgojjgYbjgYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIIKLS0tCkNPTkZJREVO VElBTElUWSBOT1RFOiBUaGUgaW5mb3JtYXRpb24gaW4gdGhpcyBlbWFpbCBpcyBjb25maWRlbnRp YWwKYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4KRGlzY2xvc3VyZSwgY29w eWluZywgZGlzdHJpYnV0aW9uIG9yIGFueSBvdGhlciBhY3Rpb24gb2YgdXNlIG9mIHRoaXMKZW1h aWwgYnkgcGVyc29uIG90aGVyIHRoYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBpcyBwcm9oaWJpdGVk LgpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFuZCBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4KZXJyb3IsIHBsZWFzZSBkZXN0cm95IHRoZSBvcmlnaW5hbCBtZXNzYWdl Lgo= From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 01:09:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAB1D192 for ; Fri, 12 Sep 2014 01:09:06 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90E3FEA8 for ; Fri, 12 Sep 2014 01:09:06 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id lx4so31235iec.5 for ; Thu, 11 Sep 2014 18:09:05 -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:from:date :message-id:subject:to:cc:content-type; bh=Zd9k4pz3nz3171zyxAn+9vVOOZXYWNQI/kao0eG4bFU=; b=I7CiXz5KBRYZPiWSO9sULO5FWuRHxRvvLTzmP07y/9vMQNokqJ9nePM03zLCzXILUF wdHFZ504jOR9asGnRleHk6XOYfIu5nbFslvRXPCVW+JMA/DnQ14jhEg93vMuKjdOjmf2 519oy8yY8EWTtej2NKQa221UK1UZJeLtk4IwX+yak+18WnvO4rK7cseeZ4t9EqvukSfQ dm7aZkmA0wLe8LaDzB+nSUgYB9/RzbpAYXiU/i4qmoE6GQBjvPtkWjXTnre+EfD7w129 bSXOCXw8tptkjA8qSuFcKT9/8XWwjEDktF2WWhJjzzFXs9+vxNeYIKBJUQE4mNJczzgI 5vJQ== X-Gm-Message-State: ALoCoQkHrgli1m28+zITf14shQaYY3AUtB3IWPXevhv7mEIKCji1rzX7jyy7xebkc7b0OEVDX73/FBCjNwz6mOMkK94/R5odxf5lQr+3uRTHbgxzgluvcyezzJ1uizYXeKxKeZON+u4b X-Received: by 10.43.140.4 with SMTP id iy4mr6351485icc.23.1410484145469; Thu, 11 Sep 2014 18:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.110.74 with HTTP; Thu, 11 Sep 2014 18:08:50 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Fri, 12 Sep 2014 10:08:50 +0900 Message-ID: Subject: Re: Intel i915 GPU hung To: Henry Hu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ranjan1018 ." <214748mv@gmail.com>, "freebsd-x11@freebsd.org" , 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: Fri, 12 Sep 2014 01:09:06 -0000 First try with sna+swapbufferswait+tearfree gave me this after a while Xorg.log [ 1901.000] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:3 (pipe=3D0) [ 1901.365] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:5 (pipe=3D1) [ 1901.441] (EE) intel(0): Detected a hung GPU, disabling acceleration. [ 2841.578] (II) UnloadModule: "mouse" [ 2841.578] (II) UnloadModule: "kbd" [ 2841.579] (II) intel(0): switch to mode 1366x768@60.0 on pipe 0 using LVDS1, position (0, 0), rotation normal [ 2841.632] (EE) intel(0): failed to set mode: Unknown error: -22 [ 2841.632] (II) intel(0): switch to mode 1280x720@60.3 on pipe 1 using VGA1, position (0, 0), rotation normal [ 2841.683] (EE) intel(0): failed to set mode: Unknown error: -22 [ 2841.710] Server terminated successfully (0). Closing log file. messages log Sep 12 09:47:13 kernel: Sep 12 09:47:13 kernel: error: [drm:pid1488:intel_pipe_set_base] *ERROR* pin & fence failed Sep 12 09:47:13 kernel: error: [drm:pid1488:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3] Sep 12 09:47:13 kernel: error: [drm:pid1488:intel_pipe_set_base] *ERROR* pin & fence failed Sep 12 09:47:13 kernel: error: [drm:pid1488:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:5] Sep 12 09:47:14 syslogd: exiting on signal 15 Unfortunately I could not access the console after this so I could not get the intel error state. Now I'm trying another run without swapbufferswait and tearfree, only sna enabled. -- Johannes Lundberg On Fri, Sep 12, 2014 at 9:29 AM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > I have a feeling I tried that before but I will try it again and report > back the results. > > I would also like to enable tear free by setting swapbufferswait and > tearfree to true but when testing with glxgears I get very variable > framerate and jerky animation. I don't know if this is a bug in glxgears = or > somewhere else... Any experience with this? > > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > On Fri, Sep 12, 2014 at 8:46 AM, Henry Hu wrote: > >> >> >> On Thu, Sep 11, 2014 at 7:18 PM, Lundberg, Johannes < >> johannes@brilliantservice.co.jp> wrote: >> >>> I often get this on HD3000 when I push the GPU too hard.. (Well not >>> really >>> hard at all, but the harder I push it the sooner I get GPU crash). Afte= r >>> the crash the desktop works fine but pure OpenGL apps don't (ie nothing >>> shows up on the screen). I assume it has switched to software >>> rendering(?) >>> >>> I'll try to get the error_state next time and post it. >>> >>> This is the only problem I have running FreeBSD on my Intel laptop and = it >>> is quite annoying when computer (GPU) crashes during demo for visitors >>> and >>> potential customers.. >>> >>> Anyone have any clue on what the problem might be? >>> >> >> If possible, have you tried the "SNA" acceleration method? Just add >> Option "AccelMethod" "sna" >> to your device section of xorg.conf. >> >> I had GPU hung before, and after I switched to SNA, it never happened. >> >> >>> >>> On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . <214748mv@gmail.com> >>> wrote: >>> >>> > Hello, >>> > >>> > I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrat= ed >>> > Intel HD Graphics 4000, to: >>> > >>> > FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed >>> Sep 10 >>> > 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS >>> amd64 >>> > >>> > Using Firefox, after some minutes, I receive the error: >>> > >>> > error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer >>> > elapsed... GPU hung >>> > info: [drm] capturing error event; look for more information in sysct= l >>> > hw.dri.0.info.i915_error_state >>> > >>> > This error is not related to r271400, but I first saw it few months >>> ago in >>> > current. >>> > >>> > The output of the command >>> > sysctl hw.dri.0.info.i915_error_state >>> > is: >>> > >>> > >>> > >>> https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp= =3Dsharing >>> > >>> > After the error I am not able to run mplayer for videos: the window i= s >>> > black. >>> > >>> > Regards, >>> > Maurizio >>> > _______________________________________________ >>> > 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" >>> > >>> >>> -- >>> =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >>> =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81= =A6=EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB= =E3=81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3= =81=97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7= =98=E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA= =E3=82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3= =81=BE=E3=81=99=E3=80=82 >>> =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4= =96=E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F= =E5=A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81= =AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80= =E5=88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 >>> =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81= =AE=E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF= =E8=A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3= =81=84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82= =8C=E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3= =E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >>> --- >>> CONFIDENTIALITY NOTE: The information in this email is confidential >>> and intended solely for the addressee. >>> Disclosure, copying, distribution or any other action of use of this >>> email by person other than intended recipient, is prohibited. >>> If you are not the intended recipient and have received this email in >>> error, please destroy the original message. >>> _______________________________________________ >>> freebsd-x11@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-x11 >>> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" >>> >> >> >> >> -- >> Cheers, >> Henry >> > > --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 01:14:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E7D039C; Fri, 12 Sep 2014 01:14:47 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D49B3F6B; Fri, 12 Sep 2014 01:14:46 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id h18so1980355igc.13 for ; Thu, 11 Sep 2014 18:14:46 -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=TZITUqSsPKI47rAKXFYAoebUid9K2lgsN4VNEqvRMns=; b=GuN6XQK0m7XF+pU6GyguKW7koZ7lDtY7tvNJ35ZUvlkc5ooDOeW3ExOSVTlWgbUsDF NODZEvmP3u8J+Zm5s33zI1ogBgact7XJ82Su+9NuBvoc2iKWBoxObDxqU+IM+HnoqdrK PqlpB8DEYY5fmjsEFjcyl0GmOiOvt2huQNmh7baeWkfLnDLqavL7ZNqcDLO/gXo5QYIZ +/cIurkSufzf+3FdasLdlTIdWn8nZBLE3QT/kqmtTmUjk75ds1eL/U48xRu1jZ4idg8s zN/SWsH6Vbh6DkUsFmpFha1IjuLcB68y0lq+fdOigLLW0PKVHjV1O8Aa+xDcsO7qHRv9 JHpA== MIME-Version: 1.0 X-Received: by 10.50.82.98 with SMTP id h2mr7311570igy.26.1410484486231; Thu, 11 Sep 2014 18:14:46 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Thu, 11 Sep 2014 18:14:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Sep 2014 18:14:46 -0700 Message-ID: Subject: Re: Intel i915 GPU hung From: Garrett Cooper To: "Lundberg, Johannes" Content-Type: text/plain; charset=UTF-8 Cc: "Ranjan1018 ." <214748mv@gmail.com>, Henry Hu , FreeBSD CURRENT , "freebsd-x11@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, 12 Sep 2014 01:14:47 -0000 On Thu, Sep 11, 2014 at 6:08 PM, Lundberg, Johannes wrote: > First try with sna+swapbufferswait+tearfree gave me this after a while > > Xorg.log > > [ 1901.000] (EE) intel(0): sna_mode_redisplay: page flipping failed, > disabling CRTC:3 (pipe=0) > [ 1901.365] (EE) intel(0): sna_mode_redisplay: page flipping failed, > disabling CRTC:5 (pipe=1) > [ 1901.441] (EE) intel(0): Detected a hung GPU, disabling acceleration. > [ 2841.578] (II) UnloadModule: "mouse" > [ 2841.578] (II) UnloadModule: "kbd" > [ 2841.579] (II) intel(0): switch to mode 1366x768@60.0 on pipe 0 using > LVDS1, position (0, 0), rotation normal > [ 2841.632] (EE) intel(0): failed to set mode: Unknown error: -22 > [ 2841.632] (II) intel(0): switch to mode 1280x720@60.3 on pipe 1 using > VGA1, position (0, 0), rotation normal > [ 2841.683] (EE) intel(0): failed to set mode: Unknown error: -22 This looks off -- it's the Linux kernel error code for EINVAL (FreeBSD error codes in the kernel being positive). Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 02:16:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C70B3BCA; Fri, 12 Sep 2014 02:16:23 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F099C77C; Fri, 12 Sep 2014 02:16:22 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id pv20so84974lab.22 for ; Thu, 11 Sep 2014 19:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=IbUNS6cZRE+p8moAtd634IoJYbKEkdbQOr+JNM2Quxg=; b=l2O1ln2pmiZe8zzAbfW1kva6i209eHrMTG5q28JUApT7/1rhEuFdyKt0VgAfaVfPtS kVQdF9SKEAj13BdKkHAz+ezPiNowgSZKXhlMr7iqaXlggdxPNTiGPEmhwvXWHArqMWL/ Ys0H3YHOX5LcdwPu7ZOZfK0Ur2nJDn/cF0N02ptIOXPWo8vCWpeEkyK63INPlYA4O1DS vggBfgVOe7EIetEjjL4vXkgdREMRinb1bCd6tigEmXwp3iHz1TdUihGlaBeIv+ApWEmt UwyWxUgEJFlZKOYVk1hvkt22tEyvUn5AJiHOqMouJZMcCYDO1wV8Emj/lvi5YrlnlUrx JeLA== MIME-Version: 1.0 X-Received: by 10.152.88.97 with SMTP id bf1mr5353961lab.58.1410488180721; Thu, 11 Sep 2014 19:16:20 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.25.207.194 with HTTP; Thu, 11 Sep 2014 19:16:20 -0700 (PDT) Date: Thu, 11 Sep 2014 19:16:20 -0700 X-Google-Sender-Auth: FHHIG4dV154A-Tc4KmFtYIZhN5g Message-ID: Subject: [PATCH] Unbreak makefs -M From: Davide Italiano To: freebsd-current , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: jmallett@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, 12 Sep 2014 02:16:23 -0000 r258695 introduces a sanity check for makefs in order to verify that minimum image size specified is always less than maximum image size. If makefs(1) is invoked specifying minimum image size, but not maximum one, the program exits with an error. Example: # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the minimum and maximum sizes to bsize. I guess it's meaningful to assert that minsize < maxsize iff maxsize is actually specified. The following patch tries to fix the problem. Visual inspection of code also shows that maxsize == 0 is treated as maxsize not specified. I'm not by any means familiar with makefs(1) code, so I may miss something here. % git diff diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c index 92d5508..83e9eae 100644 --- a/usr.sbin/makefs/ffs.c +++ b/usr.sbin/makefs/ffs.c @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, fsinfo_t *fsopts) if (ffs_opts->avgfpdir == -1) ffs_opts->avgfpdir = AFPDIR; - if (roundup(fsopts->minsize, ffs_opts->bsize) > fsopts->maxsize) + if (fsopts->maxsize > 0 + && roundup(fsopts->minsize, ffs_opts->bsize) > fsopts->maxsize) errx(1, "`%s' minsize of %lld rounded up to ffs bsize of %d " "exceeds maxsize %lld. Lower bsize, or round the minimum " "and maximum sizes to bsize.", dir, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 02:26:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0318F7E; Fri, 12 Sep 2014 02:26:51 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5302886F; Fri, 12 Sep 2014 02:26:51 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id lx4so112302iec.26 for ; Thu, 11 Sep 2014 19:26:50 -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=+IPGGKUx7DJdoSJpfwe7G75RyUBaNLvSSarUmeD87c0=; b=ZmS4UTbtxssFInkk9iERMkYDeDyWsTTr5M91ndrgZ2pSjfw024XqYUY8nhSaDX89Lw sP7VVhGa0UePIA3JpfMjbtkEmBSzqG5SR8c7wRoLkqONoI8qMGApA8zk1g+yJXJz+ZVB 3uV5EycA1uADAqL9tdC0MsJ/Bf2K/Yr+I5mg79BU0TiJKBEZ71Uvtjg7cEn8Al+ovXAk nZDOWOa1rKceRuLTEICkBMSioRV7wPDRwqKB7y9bDkR1lZ2tcp/RsQhCgHPH+HKdyTnE YFC5dWfpL0MzpM0ulQFWFep6EZbSFdW0gTwqo0vBZiA+L7pVXF2Hdu6+JwQEm3bH/ruC BmUg== MIME-Version: 1.0 X-Received: by 10.50.127.145 with SMTP id ng17mr6727501igb.26.1410488810294; Thu, 11 Sep 2014 19:26:50 -0700 (PDT) Received: by 10.50.72.69 with HTTP; Thu, 11 Sep 2014 19:26:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Sep 2014 19:26:50 -0700 Message-ID: Subject: Re: [PATCH] Unbreak makefs -M From: Garrett Cooper To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-fs@freebsd.org" , jmallett@freebsd.org, 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: Fri, 12 Sep 2014 02:26:51 -0000 On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano wrote: > r258695 introduces a sanity check for makefs in order to verify that > minimum image size specified is always less than maximum image size. > > If makefs(1) is invoked specifying minimum image size, but not maximum > one, the program exits with an error. Example: > > # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR > makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up > to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the > minimum and maximum sizes to bsize. > > I guess it's meaningful to assert that minsize < maxsize iff maxsize > is actually specified. The following patch tries to fix the problem. > Visual inspection of code also shows that maxsize == 0 is treated as > maxsize not specified. I'm not by any means familiar with makefs(1) > code, so I may miss something here. > > % git diff > diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c > index 92d5508..83e9eae 100644 > --- a/usr.sbin/makefs/ffs.c > +++ b/usr.sbin/makefs/ffs.c > @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, > fsinfo_t *fsopts) > if (ffs_opts->avgfpdir == -1) > ffs_opts->avgfpdir = AFPDIR; > > - if (roundup(fsopts->minsize, ffs_opts->bsize) > fsopts->maxsize) > + if (fsopts->maxsize > 0 > + && roundup(fsopts->minsize, ffs_opts->bsize) > fsopts->maxsize) - Should roundup be used with fsopts->maxsize) ? - style(9): put the `&&` on the previous line. > errx(1, "`%s' minsize of %lld rounded up to ffs bsize of %d " > "exceeds maxsize %lld. Lower bsize, or round the minimum " > "and maximum sizes to bsize.", dir, This (and the other rev) should really be pushed back to NetBSD.. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 02:30:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 493471CA for ; Fri, 12 Sep 2014 02:30:09 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B272689A for ; Fri, 12 Sep 2014 02:30:08 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id w7so95514lbi.18 for ; Thu, 11 Sep 2014 19:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clockworksquid.com; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=TxoZSwR6PnILR/uRVhvltcAMeAHJdnwzMNglsPuD1C0=; b=TNxh6R6H5UKQbebm/l/uipYT+Yydu3BOl+XqK0gRupEMC+IqO0F0GYkF+VA+mHRj7O RkfuFSIe+yXDr5lnRa8Lz/Xbl7dpx59bVDzjmxRB/suNCWX0eE3LU5p3jFCYgCgnnzi4 ca2AMQTxL5cFnDpSAE2FT24TqQwDPawV3986w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=TxoZSwR6PnILR/uRVhvltcAMeAHJdnwzMNglsPuD1C0=; b=QsAmIAOqL/wvx8lRZneIT7wDkyKuDW+0ZRDo9F6O9zT/btuzNEnlW5wQl920X3CkzW r9wOyFj+ktCz1yC0r4owpYi7AtN++iHZHuSN3dNr+0UKok2emnU7NbEbhSMEs/JzkVGn hPPmAh2hy9ZfL0t0O0WXVs+Z495i2fJPywEQM6XlRDu+LLVjPPAAXnLKCIyHLTSKklZi Y7oUJwWMZTDA0qEJR5zTAx9qfVNZf1ZGkDO3xSQcP6O6EnKRwmriwbIEBKyq9YUNvbqM HJrFmHLOEg+9rtZZ9dOtzPLgAr4AdLh3yABIdpngTdCMcFrNhUgaRSzse8MNJ+iiZz4y 1vag== X-Gm-Message-State: ALoCoQmhfDqw5Vwp5xar6rDL9h5b4hl/eGAY5bBwBBOS8FY2KutQl0dhSMTPD/zqxGKqhUoGHIxY X-Received: by 10.112.44.129 with SMTP id e1mr5193710lbm.78.1410489006637; Thu, 11 Sep 2014 19:30:06 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.6.72 with HTTP; Thu, 11 Sep 2014 19:29:46 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Thu, 11 Sep 2014 19:29:46 -0700 X-Google-Sender-Auth: _AR2CszTUByP0E4yvvcE1fkqpVc Message-ID: Subject: Re: [PATCH] Unbreak makefs -M To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Davide Italiano , "freebsd-fs@freebsd.org" , 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: Fri, 12 Sep 2014 02:30:09 -0000 On Thu, Sep 11, 2014 at 7:26 PM, Garrett Cooper wrote: > On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano > wrote: > > r258695 introduces a sanity check for makefs in order to verify that > > minimum image size specified is always less than maximum image size. > > > > If makefs(1) is invoked specifying minimum image size, but not maximum > > one, the program exits with an error. Example: > > > > # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR > > makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up > > to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the > > minimum and maximum sizes to bsize. > > > > I guess it's meaningful to assert that minsize < maxsize iff maxsize > > is actually specified. The following patch tries to fix the problem. > > Visual inspection of code also shows that maxsize == 0 is treated as > > maxsize not specified. I'm not by any means familiar with makefs(1) > > code, so I may miss something here. > > > > % git diff > > diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c > > index 92d5508..83e9eae 100644 > > --- a/usr.sbin/makefs/ffs.c > > +++ b/usr.sbin/makefs/ffs.c > > @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, > > fsinfo_t *fsopts) > > if (ffs_opts->avgfpdir == -1) > > ffs_opts->avgfpdir = AFPDIR; > > > > - if (roundup(fsopts->minsize, ffs_opts->bsize) > fsopts->maxsize) > > + if (fsopts->maxsize > 0 > > + && roundup(fsopts->minsize, ffs_opts->bsize) > > fsopts->maxsize) > > - Should roundup be used with fsopts->maxsize) ? > No. Maxsize is a hard limit, while minsize is always rounded up to at least the bsize. If you attempt to specify an improperly-rounded quantity as both the minimum and the maximum (for instance, because the bsize makefs decides to use has increased between executions), you'll always produce an image which is too large. That's exactly what this check was added to catch (and make less obtuse.) > - style(9): put the `&&` on the previous line. > > > errx(1, "`%s' minsize of %lld rounded up to ffs bsize of > %d " > > "exceeds maxsize %lld. Lower bsize, or round the > minimum " > > "and maximum sizes to bsize.", dir, > > This (and the other rev) should really be pushed back to NetBSD.. > > Thanks! > -Garrett > From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 05:07:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E0185E5 for ; Fri, 12 Sep 2014 05:07:25 +0000 (UTC) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 208CC84E for ; Fri, 12 Sep 2014 05:07:24 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hn15so2194908igb.9 for ; Thu, 11 Sep 2014 22:07:23 -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:from:date :message-id:subject:to:cc:content-type; bh=0hiUOVkS8rD1p2hqWd/JRz5prs9thmRPvs1HongYObE=; b=DYE/YGZphoGf7GPt2yzG09d2lpf3RG/Vp66Qgc8BiFr2OQMBtVe0cm0T6BXW1xmzvP 2XFe0eHPVirdMe+sF/UVAgcdACTr4AESCgK0sqmfKEgOhfY7sZbIGwioQfluR1B3UWIc 9nXEuQe9Cjh083FJnoRifSkBbjE/fF6uicnMZkYCkzIzpsTRpnJtH3WVaSLKcxDATsiR AecNx3ZP4jIpMdCa0NaOrm5lqw0+uhpQYB07gloUrzqmhYqy1uLoKmGOoiHmp0EIJd9O qUKt00RPimjCzBQBDUhoAAnKqeg2Np4RANudCRbhwywNj09Y/bMDi/KElYCRu0qgI2ox S9qg== X-Gm-Message-State: ALoCoQlQEhJ2ldqz14paF0TsPTmdxEoEXxBrxD1mFBnF4oqJzyeONcXrZbpWZsFKtx0OYRbh43R1/bWXULRnHBUrVCRF3YbzLnrCFy41Yxr1HehatBhyQ8i5CitOoXQOsdmJrYPs0d8M X-Received: by 10.50.26.66 with SMTP id j2mr13787186igg.45.1410498443850; Thu, 11 Sep 2014 22:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.110.74 with HTTP; Thu, 11 Sep 2014 22:07:08 -0700 (PDT) In-Reply-To: References: From: "Lundberg, Johannes" Date: Fri, 12 Sep 2014 14:07:08 +0900 Message-ID: Subject: Re: Intel i915 GPU hung To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Ranjan1018 ." <214748mv@gmail.com>, Henry Hu , FreeBSD CURRENT , "freebsd-x11@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, 12 Sep 2014 05:07:25 -0000 Now with only "sna" enabled (which I think I read somewhere should be the default and that's why I didn't enable it before) I got GPU hung again. uname -a: FreeBSD bsd 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/ obj/usr/src/sys/GENERIC amd64 dmesg, error_state, pciconf, pkginfo and Xorg.0.log can be downloaded here https://dl.dropboxusercontent.com/u/10335306/GPU_hung_logs.zip -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Sep 12, 2014 at 10:14 AM, Garrett Cooper wrote: > On Thu, Sep 11, 2014 at 6:08 PM, Lundberg, Johannes > wrote: > > First try with sna+swapbufferswait+tearfree gave me this after a while > > > > Xorg.log > > > > [ 1901.000] (EE) intel(0): sna_mode_redisplay: page flipping failed, > > disabling CRTC:3 (pipe=3D0) > > [ 1901.365] (EE) intel(0): sna_mode_redisplay: page flipping failed, > > disabling CRTC:5 (pipe=3D1) > > [ 1901.441] (EE) intel(0): Detected a hung GPU, disabling acceleration= . > > [ 2841.578] (II) UnloadModule: "mouse" > > [ 2841.578] (II) UnloadModule: "kbd" > > [ 2841.579] (II) intel(0): switch to mode 1366x768@60.0 on pipe 0 usin= g > > LVDS1, position (0, 0), rotation normal > > [ 2841.632] (EE) intel(0): failed to set mode: Unknown error: -22 > > [ 2841.632] (II) intel(0): switch to mode 1280x720@60.3 on pipe 1 usin= g > > VGA1, position (0, 0), rotation normal > > [ 2841.683] (EE) intel(0): failed to set mode: Unknown error: -22 > > This looks off -- it's the Linux kernel error code for EINVAL > (FreeBSD error codes in the kernel being positive). > Cheers, > -Garrett > --=20 =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- =E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6=EF= =BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81=97= =E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98=E5= =8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3=82= =8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81=BE= =E3=81=99=E3=80=82 =E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0= =B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AE= =E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE=E3= =83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5=88= =87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 =E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE=E4= =BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8=A8= =98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81=84= =E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C=E3= =81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81= =97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 17:01:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCCF18CF for ; Fri, 12 Sep 2014 17:01:19 +0000 (UTC) Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (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 5749CB58 for ; Fri, 12 Sep 2014 17:01:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s2048; t=1410541277; bh=/gNxmyVfXx1So0Q3V0WSGk+3VJ83XWzkp1S+nZ9d+Ps=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:MIME-Version:X-Received:Received:Date:Message-ID:Subject:From:To:Content-Type:From:Subject; b=JgJyIpSLdU+GsQcZx5iVZTFoMHBk8uzePl7uHE9fhxG7FEVCiF3LOeEbTBnfa+X6LGbiolVgmtxgcenlHbUJGiHlRoxspXrzv0BqxMpK1YRIpTeHP7zHyxn/CLq/PbJ4TDzIBObqYsowgJ8YuZdRnAEdhkErnIOHS671LRPtPcr4ghDBoufF6qwJxMdDFxDQ35hCbZEE4QJNxmIvDqolK20ihLeo5frlQ6tYC5+BSU80YWcc/nKHRSna6dKqX0UVgz4DFzT5X5Tv+dYIRjeA4SUlUQAZZawNK21gc7JzHa1ZAiKmoiT9XJ7E02X1wA6WPVv43O4Jha6idV5A4OULVQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.ca; b=IRYbaQefQ/K1UAtgOYZKEpcoCFvtvQhO13x99qb/IGjUgcGTdZsSDO5+wSL1qdxzhFN0wWQ1qu6CixrdXePB5kKKk66DIdNNFWDjT6D519JOxDhT8Nlh1JvqpafTE5viAY4nlEd6RJxDpSZSs+ljA6hknwINJrCt0YA4FchMv8UuKsJcq/V787eqJ+fkuQbo05Txk72RxrKJQi57gaai+dAUDoAHOpv6DAl52xuUb773hFtZ4hUPGN6LBghFZXXCJjkB5ingucRKlvrS4j/OF0g4dewEFh2Uxr+DzPLuHxAVVrrVpvPBiYzgQb88tejLATPKdi6zCH2UKSUhSvk8JA==; Received: from [66.196.81.172] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 12 Sep 2014 17:01:17 -0000 Received: from [98.139.213.14] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 12 Sep 2014 17:01:17 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 12 Sep 2014 17:01:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1410541277; bh=/gNxmyVfXx1So0Q3V0WSGk+3VJ83XWzkp1S+nZ9d+Ps=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:MIME-Version:X-Received:Received:Date:Message-ID:Subject:From:To:Content-Type; b=DSIVNsn4FMZwBGtINHDKt7H+ho8kjiQWtTR3qAqlSkihIQzVStLwiSgRt91TkF6Ugym4DNMqYG49TcZJswjdWdeVjetj+jFn25Z9s3uEgkpCNf2ERaiX8PETH59RgHQn5mqLMyzrgc0r+j0QbJSr+uzyrgc6OmtSTL6c/k4kmtA= X-Yahoo-Newman-Id: 480249.66175.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ifhhXhgVM1mOqrz52mIOWZGQ4mAi2louUn2As3ZlwQz2rrW hxrkRv914VX6FjjjsRIivY24AgN_yE3Cj9pPHZ3CXlT1LJ41iTT4K4WqFYTm O8qQ4DtbMYeh2lj32wpRiBBN8Sqj4D07mghF0FhQkLzLQnBKjBrgMEBsZunV zlM8k5hxc.kOhyyBj.p1QSjNN35P8uJtQRkQgeeLGeemAGFN.OyEq.o6_TRm 0z8XJAAhEh0ixRT4dLqpUv3ckeqYJiz81m5MoTUbhoot81hWo_zKjqFQzRAT a64ji0wJ_ccMfeN50MOCarzsMrog4Y5rQVnflYNXZedgJRILaS9PtFphIVIt iU..ki9uctQAxXB0M.GIMr3DIklyVK5FQW9jCkJRJXgl4bWv13rKk7n0NYXT 4FLDeotC5_.pDt4e.shkFyfsinsfV54Dd7xZYwxZydQNDy5YAJhwo9YHplm8 .AhfdkvwxAxf_P775hihvuJ_TAZaSl3Q6yqyhSkAT5QOlsSlkfF7qjWxknK0 GdMGgmSeQMoDTPv__EOn3wJDm4FEHUyMR0M_Utw-- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: by mail-la0-f50.google.com with SMTP id ty20so1335753lab.37 for ; Fri, 12 Sep 2014 10:01:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.10.203 with SMTP id k11mr10551287lab.30.1410541275183; Fri, 12 Sep 2014 10:01:15 -0700 (PDT) Received: by 10.112.230.9 with HTTP; Fri, 12 Sep 2014 10:01:15 -0700 (PDT) Date: Fri, 12 Sep 2014 11:01:15 -0600 Message-ID: Subject: Re: CDC-WDM driver (4G modems) From: PseudoCylon To: Nick Hibma , freebsd-current@freebsd.org 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: Fri, 12 Sep 2014 17:01:19 -0000 > Message: 1 > Date: Thu, 11 Sep 2014 15:23:07 +0200 > From: Nick Hibma > To: freebsd-current@FreeBSD.ORG > Cc: Hans Petter Selasky > Subject: CDC-WDM driver (4G modems) > Message-ID: <2D4CF978-B2C2-4253-93C7-595DABAC00DD@van-laarhoven.org> > Content-Type: text/plain; charset=us-ascii > > Folks, Hans-Petter, > > Is anyone aware of an effort to create support for QMI based 4G modems? The following parts need to be implemented I think: > > - CDC-WDM support > - Wrapper driver to access QMI devices as WDM? > - libqmi port to FreeBSD > > This would support any modem from Telit, Sierra Wireless, Option, etc. that works with the Qualcomm chipsets. If you look in the cdc-wdm qmi driver in Linux, it is a long list. > > I could not find any mention of FreeBSD and QMI on the same page, so I assume no one is working on it. Actually, I'm working on it. Base part has been done. Currently, just adding more commands. But, I cannot release the code until 3 month after the release of the product. By the way, libqmi is just for QMI commands (controlling the modem). Tx/Rx data packets go though PPP. That's because qualcomm refused to release that part of information. > > > Nick Hibma > From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 17:45:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65A04299; Fri, 12 Sep 2014 17:45:36 +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 D866B10E; Fri, 12 Sep 2014 17:45:35 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8CHjVeO072475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 17:45:32 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1410543932; bh=JiHzqAvpKJ0SbFWA6Bb3nzBThI+hXI3Aww6qeJE9BQo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oQk2BpLiF2bqMN/J08Xd2ZwnxPQH7gbohM3HuCbbV5FFs+LTWFkERHo5FROi1thjM qw/sDyCqpgo/vt4yuXFqb3DelGQcHB1p+JfOBdVCymvlHKui4qG80oQnK5AdiGHfTY Ec9YRZYUvz/WLvp/C0WIQGHbh9PG+5U8/e/IS2ws= Date: Fri, 12 Sep 2014 17:45:31 +0000 (UTC) From: Marcin Cieslak To: John Baldwin Subject: Re: panic: resource_list_alloc: resource entry is busy In-Reply-To: <1749648.0eHaTPXHUy@ralph.baldwin.cx> Message-ID: References: <1749648.0eHaTPXHUy@ralph.baldwin.cx> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Fri, 12 Sep 2014 17:45:36 -0000 On Wed, 10 Sep 2014, John Baldwin wrote: > On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: >> On my CURRENT as of 6 Sep (r271197): >> >> What I did was that: >> >> - kldload i915 >> >> - startx >> >> During X server start I get the following: >> >> #10 0xffffffff808c2947 in resource_list_alloc (rl=, >> bus=, child=, type=> optimized out>, >> rid=, start=, end=> optimized out>, count=, flags=) >> at /usr/src/sys/kern/subr_bus.c:3304 >> #11 0xffffffff8061ddae in pci_alloc_resource (dev=, >> child=, type=, rid=> optimized out>, >> start=, end=, count=> optimized out>, flags=) at >> /usr/src/sys/dev/pci/pci.c:4604 #12 0xffffffff808c4420 in >> bus_alloc_resource (dev=0xfffff800026d8800, type=1, rid=0xffffffff811effc8, >> start=632, end=18446744071580876744, count=464, flags=100707968) at >> bus_if.h:284 >> #13 0xffffffff80626092 in vga_pci_alloc_resource (dev=0xfffff800026d8800, >> child=, type=1, rid=0xfffff80008c0b2d4, start=0, >> end=, count=18446744071580876744, flags=> optimized out>) at /usr/src/sys/dev/pci/vga_pci.c:318 > > Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? Sure, here it goes: (kgdb) f 13 #13 0xffffffff80626092 in vga_pci_alloc_resource ( dev=0xfffff800026d8800, child=, type=1, rid=0xfffff80008c0b2d4, start=0, end=, count=18446744071580876744, flags=) at /usr/src/sys/dev/pci/vga_pci.c:318 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); Current language: auto; currently minimal (kgdb) p *rid $1 = 0 //Marcin From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 20:35:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13EB87C6 for ; Fri, 12 Sep 2014 20:35:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF226638 for ; Fri, 12 Sep 2014 20:35:14 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D89EBB9B8; Fri, 12 Sep 2014 16:35:13 -0400 (EDT) From: John Baldwin To: Marcin Cieslak Subject: Re: panic: resource_list_alloc: resource entry is busy Date: Fri, 12 Sep 2014 14:37:18 -0400 Message-ID: <1584874.3FXdLuYUQI@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <1749648.0eHaTPXHUy@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Sep 2014 16:35:13 -0400 (EDT) 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: Fri, 12 Sep 2014 20:35:15 -0000 On Friday, September 12, 2014 05:45:31 PM Marcin Cieslak wrote: > On Wed, 10 Sep 2014, John Baldwin wrote: > > On Wednesday, September 10, 2014 12:45:08 PM Marcin Cieslak wrote: > >> On my CURRENT as of 6 Sep (r271197): > >> > >> What I did was that: > >> > >> - kldload i915 > >> > >> - startx > >> > >> During X server start I get the following: > >> > >> #10 0xffffffff808c2947 in resource_list_alloc (rl=, > >> bus=, child=, type= >> optimized out>, > >> > >> rid=, start=, end= >> > >> optimized out>, count=, flags=) > >> > >> at /usr/src/sys/kern/subr_bus.c:3304 > >> > >> #11 0xffffffff8061ddae in pci_alloc_resource (dev=, > >> child=, type=, rid= >> optimized out>, > >> > >> start=, end=, count= >> > >> optimized out>, flags=) at > >> /usr/src/sys/dev/pci/pci.c:4604 #12 0xffffffff808c4420 in > >> bus_alloc_resource (dev=0xfffff800026d8800, type=1, > >> rid=0xffffffff811effc8, > >> start=632, end=18446744071580876744, count=464, flags=100707968) at > >> bus_if.h:284 > >> #13 0xffffffff80626092 in vga_pci_alloc_resource (dev=0xfffff800026d8800, > >> child=, type=1, rid=0xfffff80008c0b2d4, start=0, > >> > >> end=, count=18446744071580876744, flags= >> > >> optimized out>) at /usr/src/sys/dev/pci/vga_pci.c:318 > > > > Can you load the core dump in kgdb and run 'f 13' and 'p *rid'? > > Sure, here it goes: > > (kgdb) f 13 > #13 0xffffffff80626092 in vga_pci_alloc_resource ( > dev=0xfffff800026d8800, child=, type=1, > rid=0xfffff80008c0b2d4, start=0, end=, > count=18446744071580876744, flags=) > at /usr/src/sys/dev/pci/vga_pci.c:318 > 318 return (bus_alloc_resource(dev, type, rid, start, end, count, flags)); > Current language: auto; currently minimal > (kgdb) p *rid > $1 = 0 Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. Oh, some other child of vgapci has already allocated the IRQ. That seems odd. Can you get 'devinfo -r' output before you kldload i915kms and again after doing the kldload? (No need to run startx) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 20:58:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 311DA3ED; Fri, 12 Sep 2014 20:58:00 +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 A960288B; Fri, 12 Sep 2014 20:57:59 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8CKvt7F072947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 20:57:56 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1410555476; bh=8G3lSa718mzr5UqFv7amgKWZ8fpHjgQOuNlyt+ePMo0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lwKD7+DQ/8KPrfoA1dNUw2TAW5cUlruvFg30t+VC46neyqll2GnM6Nl6UvKiczN3E mW4+vZCfMZJGnAfmF+52T+4phBg6OLPF4t2gE4rbkY5diEL6D5rNly+v0xjc4n93cV 1zA4Wh9QQfIS+VHtprKS0X0caxX3ueGghVccNbP4= Date: Fri, 12 Sep 2014 20:57:55 +0000 (UTC) From: Marcin Cieslak To: John Baldwin Subject: Re: panic: resource_list_alloc: resource entry is busy In-Reply-To: <1584874.3FXdLuYUQI@ralph.baldwin.cx> Message-ID: References: <1749648.0eHaTPXHUy@ralph.baldwin.cx> <1584874.3FXdLuYUQI@ralph.baldwin.cx> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1563967779-517861614-1410555476=:62150" 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: Fri, 12 Sep 2014 20:58:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1563967779-517861614-1410555476=:62150 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 12 Sep 2014, John Baldwin wrote: >> at /usr/src/sys/dev/pci/vga_pci.c:318 >> 318 return (bus_alloc_resource(dev, type, rid, start, end, count, > flags)); >> Current language: auto; currently minimal >> (kgdb) p *rid >> $1 = 0 > > Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. > > Oh, some other child of vgapci has already allocated the IRQ. That seems odd. > > Can you get 'devinfo -r' output before you kldload i915kms and again after > doing the kldload? (No need to run startx) Please note I originally loaded "i915.ko", not "i915kms.ko" Full output of the devinfo -r attached (no modules, w/i915 and w/i915kms), snippets: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd0000000-0xdfffffff 0xf8300000-0xf837ffff 0xf8400000-0xf843ffff agp0 I/O memory addresses: 0x80000000-0x80000fff acpi_video0 vgapci1 I/O memory addresses: 0xf8380000-0xf83fffff With i915.ko loaded: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 Interrupt request lines: 16 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd0000000-0xdfffffff 0xf8300000-0xf837ffff 0xf8400000-0xf843ffff agp0 I/O memory addresses: 0x80000000-0x80000fff acpi_video0 drm0 vgapci1 I/O memory addresses: 0xf8380000-0xf83fffff with i915kms.ko loaded: pcib0 I/O ports: 0xcf8-0xcff pci0 PCI domain 0 bus numbers: 0 hostb0 vgapci0 Interrupt request lines: 16 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xd0000000-0xdfffffff 0xf8300000-0xf837ffff 0xf8400000-0xf843ffff agp0 I/O memory addresses: 0x80000000-0x80000fff acpi_video0 drmn0 intel_iicbb0 iicbb0 iicbus0 iicsmb0 smbus0 smb0 iic0 intel_gmbus0 iicbus1 iicsmb1 smbus1 smb1 iic1 intel_iicbb1 iicbb1 iicbus2 iicsmb2 smbus2 smb2 iic2 intel_gmbus1 iicbus3 iicsmb3 smbus3 smb3 iic3 intel_iicbb2 iicbb2 iicbus4 iicsmb4 smbus4 smb4 iic4 intel_gmbus2 iicbus5 iicsmb5 smbus5 smb5 iic5 intel_iicbb3 iicbb3 iicbus6 iicsmb6 smbus6 smb6 iic6 intel_gmbus3 iicbus7 iicsmb7 smbus7 smb7 iic7 intel_iicbb4 iicbb4 iicbus8 iicsmb8 smbus8 smb8 iic8 intel_gmbus4 iicbus9 iicsmb9 smbus9 smb9 iic9 intel_iicbb5 iicbb5 iicbus10 iicsmb10 smbus10 smb10 iic10 intel_gmbus5 iicbus11 iicsmb11 smbus11 smb11 iic11 intel_iicbb6 iicbb6 iicbus12 iicsmb12 smbus12 smb12 iic12 intel_gmbus6 iicbus13 iicsmb13 smbus13 smb13 iic13 intel_iicbb7 iicbb7 iicbus14 iicsmb14 smbus14 smb14 iic14 intel_gmbus7 iicbus15 iicsmb15 smbus15 smb15 iic15 fbd0 vgapci1 I/O memory addresses: 0xf8380000-0xf83fffff Unfortunately, "kldunload i915kms" makes my screen blank and probably crashes the system (disk activity stops after a short while and there is no response to the keyboard input). //Marcin --1563967779-517861614-1410555476=:62150 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=00-devinfo-no-modules.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=00-devinfo-no-modules.txt bmV4dXMwDQogIGNyeXB0b3NvZnQwDQogIGFwaWMwDQogICAgICBJL08gbWVt b3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAweGZlYzAwMDAwLTB4ZmVjMDAw MWYNCiAgICAgICAgICAweGZlZTAwMDAwLTB4ZmVlMDAzZmYNCiAgcmFtMA0K ICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgMHgwLTB4 OWY3ZmYNCiAgICAgICAgICAweDEwMDAwMC0weDdmNjdmZmZmDQogIGFjcGkw DQogICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICA5 DQogICAgICBJL08gcG9ydHM6DQogICAgICAgICAgMHg0ZS0weDRmDQogICAg ICAgICAgMHg2MQ0KICAgICAgICAgIDB4NjMNCiAgICAgICAgICAweDY1DQog ICAgICAgICAgMHg2Nw0KICAgICAgICAgIDB4NzANCiAgICAgICAgICAweDgw DQogICAgICAgICAgMHg5Mg0KICAgICAgICAgIDB4YjItMHhiMw0KICAgICAg ICAgIDB4NjgwLTB4NmZmDQogICAgICAgICAgMHg4MDAtMHg4MGYNCiAgICAg ICAgICAweDEwMDAtMHgxMDdmDQogICAgICAgICAgMHgxMTgwLTB4MTFiZg0K ICAgICAgICAgIDB4MTY0MC0weDE2NGYNCiAgICAgICAgICAweGZlMDAtMHhm ZTAxDQogICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAw eGUwMDAwMDAwLTB4ZWZmZmZmZmYNCiAgICAgICAgICAweGZlZDE0MDAwLTB4 ZmVkMTdmZmYNCiAgICAgICAgICAweGZlZDE4MDAwLTB4ZmVkMThmZmYNCiAg ICAgICAgICAweGZlZDE5MDAwLTB4ZmVkMTlmZmYNCiAgICAgICAgICAweGZl ZDFjMDAwLTB4ZmVkMWZmZmYNCiAgICAgICAgICAweGZlZDIwMDAwLTB4ZmVk M2ZmZmYNCiAgICAgICAgICAweGZlZDQwMDAwLTB4ZmVkNDRmZmYNCiAgICAg ICAgICAweGZlZDQ1MDAwLTB4ZmVkOGZmZmYNCiAgICBjcHUwDQogICAgICAg IEFDUEkgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHgxMDE0DQogICAgICBl c3QwDQogICAgICBhY3BpX3BlcmYwDQogICAgICBjcHVmcmVxMA0KICAgIGNw dTENCiAgICAgICAgQUNQSSBJL08gcG9ydHM6DQogICAgICAgICAgICAweDEw MTQNCiAgICAgIGVzdDENCiAgICAgIGFjcGlfcGVyZjENCiAgICAgIGNwdWZy ZXExDQogICAgYWNwaV9saWQwDQogICAgYWNwaV9idXR0b24wDQogICAgcGNp YjANCiAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHhjZjgtMHhj ZmYNCiAgICAgIHBjaTANCiAgICAgICAgICBQQ0kgZG9tYWluIDAgYnVzIG51 bWJlcnM6DQogICAgICAgICAgICAgIDANCiAgICAgICAgaG9zdGIwDQogICAg ICAgIHZnYXBjaTANCiAgICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAg ICAgICAgICAweDE4MDAtMHgxODA3DQogICAgICAgICAgICBJL08gbWVtb3J5 IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAgICAweGQwMDAwMDAwLTB4ZGZm ZmZmZmYNCiAgICAgICAgICAgICAgICAweGY4MzAwMDAwLTB4ZjgzN2ZmZmYN CiAgICAgICAgICAgICAgICAweGY4NDAwMDAwLTB4Zjg0M2ZmZmYNCiAgICAg ICAgICBhZ3AwDQogICAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2Vz Og0KICAgICAgICAgICAgICAgICAgMHg4MDAwMDAwMC0weDgwMDAwZmZmDQog ICAgICAgICAgYWNwaV92aWRlbzANCiAgICAgICAgdmdhcGNpMQ0KICAgICAg ICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAg MHhmODM4MDAwMC0weGY4M2ZmZmZmDQogICAgICAgIGhkYWMwDQogICAgICAg ICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICAgICAg ICAyNTYNCiAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAg ICAgICAgICAgICAgIDB4Zjg0NDAwMDAtMHhmODQ0M2ZmZg0KICAgICAgICAg IGhkYWNjMA0KICAgICAgICAgICAgaGRhYTANCiAgICAgICAgICAgICAgcGNt MA0KICAgICAgICAgICAgICBwY20xDQogICAgICAgICAgaGRhY2MxDQogICAg ICAgIHBjaWIxDQogICAgICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAg ICAgICAgMHgyMDAwLTB4MjBmZg0KICAgICAgICAgICAgICAgIDB4MjQwMC0w eDI0ZmYNCiAgICAgICAgICAgICAgICAweDI4MDAtMHgyOGZmDQogICAgICAg ICAgICAgICAgMHgyYzAwLTB4MmNmZg0KICAgICAgICAgICAgSS9PIG1lbW9y eSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAgMHhmMDAwMDAwMC0weGYx ZmZmZmZmDQogICAgICAgICAgICAgICAgMHhmNDAwMDAwMC0weGY1ZmZmZmZm DQogICAgICAgICAgICBQQ0kgZG9tYWluIDAgYnVzIG51bWJlcnM6DQogICAg ICAgICAgICAgICAgMi01DQogICAgICAgICAgcGNpMg0KICAgICAgICAgICAg ICBwY2liMSBidXMgbnVtYmVyczoNCiAgICAgICAgICAgICAgICAgIDINCiAg ICAgICAgcGNpYjINCiAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2Vz Og0KICAgICAgICAgICAgICAgIDB4ZjgxMDAwMDAtMHhmODFmZmZmZg0KICAg ICAgICAgICAgUENJIGRvbWFpbiAwIGJ1cyBudW1iZXJzOg0KICAgICAgICAg ICAgICAgIDYNCiAgICAgICAgICBwY2k2DQogICAgICAgICAgICAgIHBjaWIy IGJ1cyBudW1iZXJzOg0KICAgICAgICAgICAgICAgICAgNg0KICAgICAgICAg ICAgd3BpMA0KICAgICAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxp bmVzOg0KICAgICAgICAgICAgICAgICAgICAxNw0KICAgICAgICAgICAgICAg IHBjaWIyIG1lbW9yeSB3aW5kb3c6DQogICAgICAgICAgICAgICAgICAgIDB4 ZjgxMDAwMDAtMHhmODEwMGZmZg0KICAgICAgICBwY2liMw0KICAgICAgICAg ICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgICAgIDB4MzAwMC0weDMwZmYN CiAgICAgICAgICAgICAgICAweDM0MDAtMHgzNGZmDQogICAgICAgICAgICAg ICAgMHgzODAwLTB4MzhmZg0KICAgICAgICAgICAgICAgIDB4M2MwMC0weDNj ZmYNCiAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAgICAg ICAgICAgICAgIDB4ZjgwMDAwMDAtMHhmODBmZmZmZg0KICAgICAgICAgICAg UENJIGRvbWFpbiAwIGJ1cyBudW1iZXJzOg0KICAgICAgICAgICAgICAgIDcN CiAgICAgICAgICBwY2k3DQogICAgICAgICAgICAgIHBjaWIzIGJ1cyBudW1i ZXJzOg0KICAgICAgICAgICAgICAgICAgNw0KICAgICAgICAgICAgbXNrYzAN CiAgICAgICAgICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAg ICAgICAgICAgICAgICAgICAgMjU3DQogICAgICAgICAgICAgICAgcGNpYjMg SS9PIHBvcnQgd2luZG93Og0KICAgICAgICAgICAgICAgICAgICAweDMwMDAt MHgzMGZmDQogICAgICAgICAgICAgICAgcGNpYjMgbWVtb3J5IHdpbmRvdzoN CiAgICAgICAgICAgICAgICAgICAgMHhmODAwMDAwMC0weGY4MDAzZmZmDQog ICAgICAgICAgICAgIG1zazANCiAgICAgICAgICAgICAgICBtaWlidXMwDQog ICAgICAgICAgICAgICAgICBlMTAwMHBoeTANCiAgICAgICAgcGNpYjQNCiAg ICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgICAgICAweDQwMDAt MHg0MGZmDQogICAgICAgICAgICAgICAgMHg0NDAwLTB4NDRmZg0KICAgICAg ICAgICAgICAgIDB4NDgwMC0weDQ4ZmYNCiAgICAgICAgICAgICAgICAweDRj MDAtMHg0Y2ZmDQogICAgICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoN CiAgICAgICAgICAgICAgICAweGYyMDAwMDAwLTB4ZjNmZmZmZmYNCiAgICAg ICAgICAgICAgICAweGY2MDAwMDAwLTB4ZjdmZmZmZmYNCiAgICAgICAgICAg IFBDSSBkb21haW4gMCBidXMgbnVtYmVyczoNCiAgICAgICAgICAgICAgICA4 DQogICAgICAgICAgcGNpOA0KICAgICAgICAgICAgICBwY2liNCBidXMgbnVt YmVyczoNCiAgICAgICAgICAgICAgICAgIDgNCiAgICAgICAgdWhjaTANCiAg ICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAg ICAgICAgIDE5DQogICAgICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAg ICAgICAgMHgxODIwLTB4MTgzZg0KICAgICAgICAgIHVzYnVzMA0KICAgICAg ICAgICAgdWh1YjANCiAgICAgICAgdWhjaTENCiAgICAgICAgICAgIEludGVy cnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgICAgIDE5DQogICAg ICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAgICAgMHgxODQwLTB4 MTg1Zg0KICAgICAgICAgIHVzYnVzMQ0KICAgICAgICAgICAgdWh1YjENCiAg ICAgICAgdWhjaTINCiAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxp bmVzOg0KICAgICAgICAgICAgICAgIDE5DQogICAgICAgICAgICBJL08gcG9y dHM6DQogICAgICAgICAgICAgICAgMHgxODYwLTB4MTg3Zg0KICAgICAgICAg IHVzYnVzMg0KICAgICAgICAgICAgdWh1YjINCiAgICAgICAgdWhjaTMNCiAg ICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAg ICAgICAgIDE5DQogICAgICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAg ICAgICAgMHgxODgwLTB4MTg5Zg0KICAgICAgICAgIHVzYnVzMw0KICAgICAg ICAgICAgdWh1YjMNCiAgICAgICAgZWhjaTANCiAgICAgICAgICAgIEludGVy cnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgICAgIDIzDQogICAg ICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAg ICAweGY4NjQ0MDAwLTB4Zjg2NDQzZmYNCiAgICAgICAgICB1c2J1czQNCiAg ICAgICAgICAgIHVodWI0DQogICAgICAgICAgICAgIHVtYXNzMA0KICAgICAg ICBwY2liNQ0KICAgICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQog ICAgICAgICAgICAgICAgMHhmODIwMDAwMC0weGY4MmZmZmZmDQogICAgICAg ICAgICBQQ0kgZG9tYWluIDAgYnVzIG51bWJlcnM6DQogICAgICAgICAgICAg ICAgOS0xMA0KICAgICAgICAgIHBjaTkNCiAgICAgICAgICAgICAgcGNpYjUg YnVzIG51bWJlcnM6DQogICAgICAgICAgICAgICAgICA5DQogICAgICAgICAg ICBjYmIwDQogICAgICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGlu ZXM6DQogICAgICAgICAgICAgICAgICAgIDIwDQogICAgICAgICAgICAgICAg cGNpYjUgYnVzIG51bWJlcnM6DQogICAgICAgICAgICAgICAgICAgIDEwDQog ICAgICAgICAgICAgICAgcGNpYjUgbWVtb3J5IHdpbmRvdzoNCiAgICAgICAg ICAgICAgICAgICAgMHhmODIwNjAwMC0weGY4MjA2ZmZmDQogICAgICAgICAg ICAgIGNhcmRidXMwDQogICAgICAgICAgICAgICAgICBjYmIwIGJ1cyBudW1i ZXJzOg0KICAgICAgICAgICAgICAgICAgICAgIDEwDQogICAgICAgICAgICAg IHBjY2FyZDANCiAgICAgICAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0 IGxpbmVzOg0KICAgICAgICAgICAgICAgICAgICAgIDIwDQogICAgICAgICAg ICAgICAgICBwY2liNSBtZW1vcnkgd2luZG93Og0KICAgICAgICAgICAgICAg ICAgICAgIDB4ZjgyMDcwMDAtMHhmODIwNzNmZg0KICAgICAgICAgICAgICAg IGNteDANCiAgICAgICAgICAgICAgICAgICAgSS9PIHBvcnRzOg0KICAgICAg ICAgICAgICAgICAgICAgICAgMHgxMDgwLTB4MTA4Nw0KICAgICAgICAgICAg ZndvaGNpMA0KICAgICAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxp bmVzOg0KICAgICAgICAgICAgICAgICAgICAyMQ0KICAgICAgICAgICAgICAg IHBjaWI1IG1lbW9yeSB3aW5kb3c6DQogICAgICAgICAgICAgICAgICAgIDB4 ZjgyMDAwMDAtMHhmODIwM2ZmZg0KICAgICAgICAgICAgICAgICAgICAweGY4 MjA1MDAwLTB4ZjgyMDU3ZmYNCiAgICAgICAgICAgICAgZmlyZXdpcmUwDQog ICAgICAgICAgICAgICAgZGNvbnNfY3JvbTANCiAgICAgICAgICAgICAgICBm d2UwDQogICAgICAgICAgICAgICAgZndpcDANCiAgICAgICAgICAgICAgICBz YnAwDQogICAgICAgIGlzYWIwDQogICAgICAgICAgaXNhMA0KICAgICAgICAg ICAgb3JtMA0KICAgICAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2Vz Og0KICAgICAgICAgICAgICAgICAgICAweGMwMDAwLTB4Y2ZmZmYNCiAgICAg ICAgICAgICAgICAgICAgMHhkYzAwMC0weGRmZmZmDQogICAgICAgIGF0YXBj aTANCiAgICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgICAgICAw eDE3MC0weDE3Nw0KICAgICAgICAgICAgICAgIDB4MWYwLTB4MWY3DQogICAg ICAgICAgICAgICAgMHgzNzYNCiAgICAgICAgICAgICAgICAweDNmNg0KICAg ICAgICAgICAgICAgIDB4MTgxMC0weDE4MWYNCiAgICAgICAgICBhdGEwDQog ICAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAg ICAgICAgICAgICAgMTQNCiAgICAgICAgYWhjaTANCiAgICAgICAgICAgIElu dGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgICAgIDI1OA0K ICAgICAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgICAgIDB4MThi MC0weDE4YmYNCiAgICAgICAgICAgICAgICAweDE4YzAtMHgxOGMzDQogICAg ICAgICAgICAgICAgMHgxOGM0LTB4MThjNw0KICAgICAgICAgICAgICAgIDB4 MThjOC0weDE4Y2YNCiAgICAgICAgICAgICAgICAweDE4ZDAtMHgxOGQ3DQog ICAgICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAg ICAgICAweGY4NjQ0NDAwLTB4Zjg2NDQ3ZmYNCiAgICAgICAgICBhaGNpY2gw DQogICAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAgICAg ICAgICAgICAgICAgMHhmODY0NDUwMC0weGY4NjQ0NTdmDQogICAgICAgICAg YWhjaWNoMg0KICAgICAgICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoN CiAgICAgICAgICAgICAgICAgIDB4Zjg2NDQ2MDAtMHhmODY0NDY3Zg0KICAg IGFjcGlfc3lzcmVzb3VyY2UwDQogICAgcGNpX2xpbmswDQogICAgcGNpX2xp bmsxDQogICAgcGNpX2xpbmsyDQogICAgcGNpX2xpbmszDQogICAgcGNpX2xp bms0DQogICAgcGNpX2xpbms1DQogICAgcGNpX2xpbms2DQogICAgcGNpX2xp bms3DQogICAgYWNwaV9lYzANCiAgICAgICAgSS9PIHBvcnRzOg0KICAgICAg ICAgICAgMHg2Mg0KICAgICAgICAgICAgMHg2Ng0KICAgIGJhdHRlcnkwDQog ICAgYWNwaV9hY2FkMA0KICAgIGF0ZG1hMA0KICAgICAgICBETUEgcmVxdWVz dCBsaW5lczoNCiAgICAgICAgICAgIDQNCiAgICAgICAgSS9PIHBvcnRzOg0K ICAgICAgICAgICAgMHgwLTB4MWYNCiAgICAgICAgICAgIDB4ODEtMHg5MQ0K ICAgICAgICAgICAgMHg5My0weDlmDQogICAgICAgICAgICAweGMwLTB4ZGYN CiAgICBocGV0MA0KICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoN CiAgICAgICAgICAgIDIwDQogICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2Vz Og0KICAgICAgICAgICAgMHhmZWQwMDAwMC0weGZlZDAwM2ZmDQogICAgZnB1 cG5wMA0KICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAweGYwDQog ICAgYWNwaV9zeXNyZXNvdXJjZTENCiAgICBhdHJ0YzANCiAgICAgICAgSW50 ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICA4DQogICAgYXR0 aW1lcjANCiAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAg ICAgICAgICAwDQogICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgIDB4 NDAtMHg0Mw0KICAgICAgICAgICAgMHg1MC0weDUzDQogICAgYWNwaV9zb255 MA0KICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAg ICAgIDYNCiAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHhjMDAw LTB4YzAxZg0KICAgIGFjcGlfc29ueTENCiAgICBhdGtiZGMwDQogICAgICAg IEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgMQ0KICAg ICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAweDYwDQogICAgICAgICAg ICAweDY0DQogICAgICBhdGtiZDANCiAgICAgIHBzbTANCiAgICAgICAgICBJ bnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICAgICAgMTINCiAg ICBwc21jcG5wMA0KICAgIGFjcGlfdHowDQogICAgYWNwaV90ejENCiAgICBh Y3BpX3R6Mg0KICAgIGFjcGlfdGltZXIwDQogICAgICAgIEFDUEkgSS9PIHBv cnRzOg0KICAgICAgICAgICAgMHgxMDA4LTB4MTAwYg0K --1563967779-517861614-1410555476=:62150 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=01-devinfo-i915.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=01-devinfo-i915.txt bmV4dXMwDQogIGNyeXB0b3NvZnQwDQogIGFwaWMwDQogICAgICBJL08gbWVt b3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAweGZlYzAwMDAwLTB4ZmVjMDAw MWYNCiAgICAgICAgICAweGZlZTAwMDAwLTB4ZmVlMDAzZmYNCiAgcmFtMA0K ICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgMHgwLTB4 OWY3ZmYNCiAgICAgICAgICAweDEwMDAwMC0weDdmNjdmZmZmDQogIGFjcGkw DQogICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICA5 DQogICAgICBJL08gcG9ydHM6DQogICAgICAgICAgMHg0ZS0weDRmDQogICAg ICAgICAgMHg2MQ0KICAgICAgICAgIDB4NjMNCiAgICAgICAgICAweDY1DQog ICAgICAgICAgMHg2Nw0KICAgICAgICAgIDB4NzANCiAgICAgICAgICAweDgw DQogICAgICAgICAgMHg5Mg0KICAgICAgICAgIDB4YjItMHhiMw0KICAgICAg ICAgIDB4NjgwLTB4NmZmDQogICAgICAgICAgMHg4MDAtMHg4MGYNCiAgICAg ICAgICAweDEwMDAtMHgxMDdmDQogICAgICAgICAgMHgxMTgwLTB4MTFiZg0K ICAgICAgICAgIDB4MTY0MC0weDE2NGYNCiAgICAgICAgICAweGZlMDAtMHhm ZTAxDQogICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAw eGUwMDAwMDAwLTB4ZWZmZmZmZmYNCiAgICAgICAgICAweGZlZDE0MDAwLTB4 ZmVkMTdmZmYNCiAgICAgICAgICAweGZlZDE4MDAwLTB4ZmVkMThmZmYNCiAg ICAgICAgICAweGZlZDE5MDAwLTB4ZmVkMTlmZmYNCiAgICAgICAgICAweGZl ZDFjMDAwLTB4ZmVkMWZmZmYNCiAgICAgICAgICAweGZlZDIwMDAwLTB4ZmVk M2ZmZmYNCiAgICAgICAgICAweGZlZDQwMDAwLTB4ZmVkNDRmZmYNCiAgICAg ICAgICAweGZlZDQ1MDAwLTB4ZmVkOGZmZmYNCiAgICBjcHUwDQogICAgICAg IEFDUEkgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHgxMDE0DQogICAgICBl c3QwDQogICAgICBhY3BpX3BlcmYwDQogICAgICBjcHVmcmVxMA0KICAgIGNw dTENCiAgICAgICAgQUNQSSBJL08gcG9ydHM6DQogICAgICAgICAgICAweDEw MTQNCiAgICAgIGVzdDENCiAgICAgIGFjcGlfcGVyZjENCiAgICAgIGNwdWZy ZXExDQogICAgYWNwaV9saWQwDQogICAgYWNwaV9idXR0b24wDQogICAgcGNp YjANCiAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHhjZjgtMHhj ZmYNCiAgICAgIHBjaTANCiAgICAgICAgICBQQ0kgZG9tYWluIDAgYnVzIG51 bWJlcnM6DQogICAgICAgICAgICAgIDANCiAgICAgICAgaG9zdGIwDQogICAg ICAgIHZnYXBjaTANCiAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxp bmVzOg0KICAgICAgICAgICAgICAgIDE2DQogICAgICAgICAgICBJL08gcG9y dHM6DQogICAgICAgICAgICAgICAgMHgxODAwLTB4MTgwNw0KICAgICAgICAg ICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAgMHhk MDAwMDAwMC0weGRmZmZmZmZmDQogICAgICAgICAgICAgICAgMHhmODMwMDAw MC0weGY4MzdmZmZmDQogICAgICAgICAgICAgICAgMHhmODQwMDAwMC0weGY4 NDNmZmZmDQogICAgICAgICAgYWdwMA0KICAgICAgICAgICAgICBJL08gbWVt b3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAgICAgIDB4ODAwMDAwMDAt MHg4MDAwMGZmZg0KICAgICAgICAgIGFjcGlfdmlkZW8wDQogICAgICAgICAg ZHJtMA0KICAgICAgICB2Z2FwY2kxDQogICAgICAgICAgICBJL08gbWVtb3J5 IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAgICAweGY4MzgwMDAwLTB4Zjgz ZmZmZmYNCiAgICAgICAgaGRhYzANCiAgICAgICAgICAgIEludGVycnVwdCBy ZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgICAgIDI1Ng0KICAgICAgICAg ICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAgMHhm ODQ0MDAwMC0weGY4NDQzZmZmDQogICAgICAgICAgaGRhY2MwDQogICAgICAg ICAgICBoZGFhMA0KICAgICAgICAgICAgICBwY20wDQogICAgICAgICAgICAg IHBjbTENCiAgICAgICAgICBoZGFjYzENCiAgICAgICAgcGNpYjENCiAgICAg ICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgICAgICAweDIwMDAtMHgy MGZmDQogICAgICAgICAgICAgICAgMHgyNDAwLTB4MjRmZg0KICAgICAgICAg ICAgICAgIDB4MjgwMC0weDI4ZmYNCiAgICAgICAgICAgICAgICAweDJjMDAt MHgyY2ZmDQogICAgICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAg ICAgICAgICAgICAgICAweGYwMDAwMDAwLTB4ZjFmZmZmZmYNCiAgICAgICAg ICAgICAgICAweGY0MDAwMDAwLTB4ZjVmZmZmZmYNCiAgICAgICAgICAgIFBD SSBkb21haW4gMCBidXMgbnVtYmVyczoNCiAgICAgICAgICAgICAgICAyLTUN CiAgICAgICAgICBwY2kyDQogICAgICAgICAgICAgIHBjaWIxIGJ1cyBudW1i ZXJzOg0KICAgICAgICAgICAgICAgICAgMg0KICAgICAgICBwY2liMg0KICAg ICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAg ICAgMHhmODEwMDAwMC0weGY4MWZmZmZmDQogICAgICAgICAgICBQQ0kgZG9t YWluIDAgYnVzIG51bWJlcnM6DQogICAgICAgICAgICAgICAgNg0KICAgICAg ICAgIHBjaTYNCiAgICAgICAgICAgICAgcGNpYjIgYnVzIG51bWJlcnM6DQog ICAgICAgICAgICAgICAgICA2DQogICAgICAgICAgICB3cGkwDQogICAgICAg ICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAg ICAgICAgICAgIDE3DQogICAgICAgICAgICAgICAgcGNpYjIgbWVtb3J5IHdp bmRvdzoNCiAgICAgICAgICAgICAgICAgICAgMHhmODEwMDAwMC0weGY4MTAw ZmZmDQogICAgICAgIHBjaWIzDQogICAgICAgICAgICBJL08gcG9ydHM6DQog ICAgICAgICAgICAgICAgMHgzMDAwLTB4MzBmZg0KICAgICAgICAgICAgICAg IDB4MzQwMC0weDM0ZmYNCiAgICAgICAgICAgICAgICAweDM4MDAtMHgzOGZm DQogICAgICAgICAgICAgICAgMHgzYzAwLTB4M2NmZg0KICAgICAgICAgICAg SS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAgMHhmODAw MDAwMC0weGY4MGZmZmZmDQogICAgICAgICAgICBQQ0kgZG9tYWluIDAgYnVz IG51bWJlcnM6DQogICAgICAgICAgICAgICAgNw0KICAgICAgICAgIHBjaTcN CiAgICAgICAgICAgICAgcGNpYjMgYnVzIG51bWJlcnM6DQogICAgICAgICAg ICAgICAgICA3DQogICAgICAgICAgICBtc2tjMA0KICAgICAgICAgICAgICAg IEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgICAgICAg ICAyNTcNCiAgICAgICAgICAgICAgICBwY2liMyBJL08gcG9ydCB3aW5kb3c6 DQogICAgICAgICAgICAgICAgICAgIDB4MzAwMC0weDMwZmYNCiAgICAgICAg ICAgICAgICBwY2liMyBtZW1vcnkgd2luZG93Og0KICAgICAgICAgICAgICAg ICAgICAweGY4MDAwMDAwLTB4ZjgwMDNmZmYNCiAgICAgICAgICAgICAgbXNr MA0KICAgICAgICAgICAgICAgIG1paWJ1czANCiAgICAgICAgICAgICAgICAg IGUxMDAwcGh5MA0KICAgICAgICBwY2liNA0KICAgICAgICAgICAgSS9PIHBv cnRzOg0KICAgICAgICAgICAgICAgIDB4NDAwMC0weDQwZmYNCiAgICAgICAg ICAgICAgICAweDQ0MDAtMHg0NGZmDQogICAgICAgICAgICAgICAgMHg0ODAw LTB4NDhmZg0KICAgICAgICAgICAgICAgIDB4NGMwMC0weDRjZmYNCiAgICAg ICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAgICAgICAgICAgICAg IDB4ZjIwMDAwMDAtMHhmM2ZmZmZmZg0KICAgICAgICAgICAgICAgIDB4ZjYw MDAwMDAtMHhmN2ZmZmZmZg0KICAgICAgICAgICAgUENJIGRvbWFpbiAwIGJ1 cyBudW1iZXJzOg0KICAgICAgICAgICAgICAgIDgNCiAgICAgICAgICBwY2k4 DQogICAgICAgICAgICAgIHBjaWI0IGJ1cyBudW1iZXJzOg0KICAgICAgICAg ICAgICAgICAgOA0KICAgICAgICB1aGNpMA0KICAgICAgICAgICAgSW50ZXJy dXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAgICAgMTkNCiAgICAg ICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgICAgICAweDE4MjAtMHgx ODNmDQogICAgICAgICAgdXNidXMwDQogICAgICAgICAgICB1aHViMA0KICAg ICAgICB1aGNpMQ0KICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGlu ZXM6DQogICAgICAgICAgICAgICAgMTkNCiAgICAgICAgICAgIEkvTyBwb3J0 czoNCiAgICAgICAgICAgICAgICAweDE4NDAtMHgxODVmDQogICAgICAgICAg dXNidXMxDQogICAgICAgICAgICB1aHViMQ0KICAgICAgICB1aGNpMg0KICAg ICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAg ICAgICAgMTkNCiAgICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAg ICAgICAweDE4NjAtMHgxODdmDQogICAgICAgICAgdXNidXMyDQogICAgICAg ICAgICB1aHViMg0KICAgICAgICB1aGNpMw0KICAgICAgICAgICAgSW50ZXJy dXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAgICAgMTkNCiAgICAg ICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgICAgICAweDE4ODAtMHgx ODlmDQogICAgICAgICAgdXNidXMzDQogICAgICAgICAgICB1aHViMw0KICAg ICAgICBlaGNpMA0KICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGlu ZXM6DQogICAgICAgICAgICAgICAgMjMNCiAgICAgICAgICAgIEkvTyBtZW1v cnkgYWRkcmVzc2VzOg0KICAgICAgICAgICAgICAgIDB4Zjg2NDQwMDAtMHhm ODY0NDNmZg0KICAgICAgICAgIHVzYnVzNA0KICAgICAgICAgICAgdWh1YjQN CiAgICAgICAgICAgICAgdW1hc3MwDQogICAgICAgIHBjaWI1DQogICAgICAg ICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAgICAw eGY4MjAwMDAwLTB4ZjgyZmZmZmYNCiAgICAgICAgICAgIFBDSSBkb21haW4g MCBidXMgbnVtYmVyczoNCiAgICAgICAgICAgICAgICA5LTEwDQogICAgICAg ICAgcGNpOQ0KICAgICAgICAgICAgICBwY2liNSBidXMgbnVtYmVyczoNCiAg ICAgICAgICAgICAgICAgIDkNCiAgICAgICAgICAgIGNiYjANCiAgICAgICAg ICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICAg ICAgICAgICAgMjANCiAgICAgICAgICAgICAgICBwY2liNSBidXMgbnVtYmVy czoNCiAgICAgICAgICAgICAgICAgICAgMTANCiAgICAgICAgICAgICAgICBw Y2liNSBtZW1vcnkgd2luZG93Og0KICAgICAgICAgICAgICAgICAgICAweGY4 MjA2MDAwLTB4ZjgyMDZmZmYNCiAgICAgICAgICAgICAgY2FyZGJ1czANCiAg ICAgICAgICAgICAgICAgIGNiYjAgYnVzIG51bWJlcnM6DQogICAgICAgICAg ICAgICAgICAgICAgMTANCiAgICAgICAgICAgICAgcGNjYXJkMA0KICAgICAg ICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAg ICAgICAgICAgICAgICAgMjANCiAgICAgICAgICAgICAgICAgIHBjaWI1IG1l bW9yeSB3aW5kb3c6DQogICAgICAgICAgICAgICAgICAgICAgMHhmODIwNzAw MC0weGY4MjA3M2ZmDQogICAgICAgICAgICAgICAgY214MA0KICAgICAgICAg ICAgICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAgICAgICAgICAg ICAweDEwODAtMHgxMDg3DQogICAgICAgICAgICBmd29oY2kwDQogICAgICAg ICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAg ICAgICAgICAgIDIxDQogICAgICAgICAgICAgICAgcGNpYjUgbWVtb3J5IHdp bmRvdzoNCiAgICAgICAgICAgICAgICAgICAgMHhmODIwMDAwMC0weGY4MjAz ZmZmDQogICAgICAgICAgICAgICAgICAgIDB4ZjgyMDUwMDAtMHhmODIwNTdm Zg0KICAgICAgICAgICAgICBmaXJld2lyZTANCiAgICAgICAgICAgICAgICBk Y29uc19jcm9tMA0KICAgICAgICAgICAgICAgIGZ3ZTANCiAgICAgICAgICAg ICAgICBmd2lwMA0KICAgICAgICAgICAgICAgIHNicDANCiAgICAgICAgaXNh YjANCiAgICAgICAgICBpc2EwDQogICAgICAgICAgICBvcm0wDQogICAgICAg ICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAg ICAgICAgIDB4YzAwMDAtMHhjZmZmZg0KICAgICAgICAgICAgICAgICAgICAw eGRjMDAwLTB4ZGZmZmYNCiAgICAgICAgYXRhcGNpMA0KICAgICAgICAgICAg SS9PIHBvcnRzOg0KICAgICAgICAgICAgICAgIDB4MTcwLTB4MTc3DQogICAg ICAgICAgICAgICAgMHgxZjAtMHgxZjcNCiAgICAgICAgICAgICAgICAweDM3 Ng0KICAgICAgICAgICAgICAgIDB4M2Y2DQogICAgICAgICAgICAgICAgMHgx ODEwLTB4MTgxZg0KICAgICAgICAgIGF0YTANCiAgICAgICAgICAgICAgSW50 ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAgICAgICAxNA0K ICAgICAgICBhaGNpMA0KICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3Qg bGluZXM6DQogICAgICAgICAgICAgICAgMjU4DQogICAgICAgICAgICBJL08g cG9ydHM6DQogICAgICAgICAgICAgICAgMHgxOGIwLTB4MThiZg0KICAgICAg ICAgICAgICAgIDB4MThjMC0weDE4YzMNCiAgICAgICAgICAgICAgICAweDE4 YzQtMHgxOGM3DQogICAgICAgICAgICAgICAgMHgxOGM4LTB4MThjZg0KICAg ICAgICAgICAgICAgIDB4MThkMC0weDE4ZDcNCiAgICAgICAgICAgIEkvTyBt ZW1vcnkgYWRkcmVzc2VzOg0KICAgICAgICAgICAgICAgIDB4Zjg2NDQ0MDAt MHhmODY0NDdmZg0KICAgICAgICAgIGFoY2ljaDANCiAgICAgICAgICAgICAg SS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAgICAweGY4 NjQ0NTAwLTB4Zjg2NDQ1N2YNCiAgICAgICAgICBhaGNpY2gyDQogICAgICAg ICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAgICAgICAgICAgICAg ICAgMHhmODY0NDYwMC0weGY4NjQ0NjdmDQogICAgYWNwaV9zeXNyZXNvdXJj ZTANCiAgICBwY2lfbGluazANCiAgICBwY2lfbGluazENCiAgICBwY2lfbGlu azINCiAgICBwY2lfbGluazMNCiAgICBwY2lfbGluazQNCiAgICBwY2lfbGlu azUNCiAgICBwY2lfbGluazYNCiAgICBwY2lfbGluazcNCiAgICBhY3BpX2Vj MA0KICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAweDYyDQogICAg ICAgICAgICAweDY2DQogICAgYmF0dGVyeTANCiAgICBhY3BpX2FjYWQwDQog ICAgYXRkbWEwDQogICAgICAgIERNQSByZXF1ZXN0IGxpbmVzOg0KICAgICAg ICAgICAgNA0KICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAweDAt MHgxZg0KICAgICAgICAgICAgMHg4MS0weDkxDQogICAgICAgICAgICAweDkz LTB4OWYNCiAgICAgICAgICAgIDB4YzAtMHhkZg0KICAgIGhwZXQwDQogICAg ICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgMjAN CiAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAw eGZlZDAwMDAwLTB4ZmVkMDAzZmYNCiAgICBmcHVwbnAwDQogICAgICAgIEkv TyBwb3J0czoNCiAgICAgICAgICAgIDB4ZjANCiAgICBhY3BpX3N5c3Jlc291 cmNlMQ0KICAgIGF0cnRjMA0KICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBs aW5lczoNCiAgICAgICAgICAgIDgNCiAgICBhdHRpbWVyMA0KICAgICAgICBJ bnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICAgIDANCiAgICAg ICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHg0MC0weDQzDQogICAgICAg ICAgICAweDUwLTB4NTMNCiAgICBhY3BpX3NvbnkwDQogICAgICAgIEludGVy cnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgNg0KICAgICAgICBJ L08gcG9ydHM6DQogICAgICAgICAgICAweGMwMDAtMHhjMDFmDQogICAgYWNw aV9zb255MQ0KICAgIGF0a2JkYzANCiAgICAgICAgSW50ZXJydXB0IHJlcXVl c3QgbGluZXM6DQogICAgICAgICAgICAxDQogICAgICAgIEkvTyBwb3J0czoN CiAgICAgICAgICAgIDB4NjANCiAgICAgICAgICAgIDB4NjQNCiAgICAgIGF0 a2JkMA0KICAgICAgcHNtMA0KICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0 IGxpbmVzOg0KICAgICAgICAgICAgICAxMg0KICAgIHBzbWNwbnAwDQogICAg YWNwaV90ejANCiAgICBhY3BpX3R6MQ0KICAgIGFjcGlfdHoyDQogICAgYWNw aV90aW1lcjANCiAgICAgICAgQUNQSSBJL08gcG9ydHM6DQogICAgICAgICAg ICAweDEwMDgtMHgxMDBiDQo= --1563967779-517861614-1410555476=:62150 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=02-devinfo-i915kms.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=02-devinfo-i915kms.txt bmV4dXMwDQogIGNyeXB0b3NvZnQwDQogIGFwaWMwDQogICAgICBJL08gbWVt b3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAweGZlYzAwMDAwLTB4ZmVjMDAw MWYNCiAgICAgICAgICAweGZlZTAwMDAwLTB4ZmVlMDAzZmYNCiAgcmFtMA0K ICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgMHgwLTB4 OWY3ZmYNCiAgICAgICAgICAweDEwMDAwMC0weDdmNjdmZmZmDQogIGFjcGkw DQogICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICA5 DQogICAgICBJL08gcG9ydHM6DQogICAgICAgICAgMHg0ZS0weDRmDQogICAg ICAgICAgMHg2MQ0KICAgICAgICAgIDB4NjMNCiAgICAgICAgICAweDY1DQog ICAgICAgICAgMHg2Nw0KICAgICAgICAgIDB4NzANCiAgICAgICAgICAweDgw DQogICAgICAgICAgMHg5Mg0KICAgICAgICAgIDB4YjItMHhiMw0KICAgICAg ICAgIDB4NjgwLTB4NmZmDQogICAgICAgICAgMHg4MDAtMHg4MGYNCiAgICAg ICAgICAweDEwMDAtMHgxMDdmDQogICAgICAgICAgMHgxMTgwLTB4MTFiZg0K ICAgICAgICAgIDB4MTY0MC0weDE2NGYNCiAgICAgICAgICAweGZlMDAtMHhm ZTAxDQogICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAw eGUwMDAwMDAwLTB4ZWZmZmZmZmYNCiAgICAgICAgICAweGZlZDE0MDAwLTB4 ZmVkMTdmZmYNCiAgICAgICAgICAweGZlZDE4MDAwLTB4ZmVkMThmZmYNCiAg ICAgICAgICAweGZlZDE5MDAwLTB4ZmVkMTlmZmYNCiAgICAgICAgICAweGZl ZDFjMDAwLTB4ZmVkMWZmZmYNCiAgICAgICAgICAweGZlZDIwMDAwLTB4ZmVk M2ZmZmYNCiAgICAgICAgICAweGZlZDQwMDAwLTB4ZmVkNDRmZmYNCiAgICAg ICAgICAweGZlZDQ1MDAwLTB4ZmVkOGZmZmYNCiAgICBjcHUwDQogICAgICAg IEFDUEkgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHgxMDE0DQogICAgICBl c3QwDQogICAgICBhY3BpX3BlcmYwDQogICAgICBjcHVmcmVxMA0KICAgIGNw dTENCiAgICAgICAgQUNQSSBJL08gcG9ydHM6DQogICAgICAgICAgICAweDEw MTQNCiAgICAgIGVzdDENCiAgICAgIGFjcGlfcGVyZjENCiAgICAgIGNwdWZy ZXExDQogICAgYWNwaV9saWQwDQogICAgYWNwaV9idXR0b24wDQogICAgcGNp YjANCiAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgMHhjZjgtMHhj ZmYNCiAgICAgIHBjaTANCiAgICAgICAgICBQQ0kgZG9tYWluIDAgYnVzIG51 bWJlcnM6DQogICAgICAgICAgICAgIDANCiAgICAgICAgaG9zdGIwDQogICAg ICAgIHZnYXBjaTANCiAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxp bmVzOg0KICAgICAgICAgICAgICAgIDE2DQogICAgICAgICAgICBJL08gcG9y dHM6DQogICAgICAgICAgICAgICAgMHgxODAwLTB4MTgwNw0KICAgICAgICAg ICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAgICAgICAgICAgICAgMHhk MDAwMDAwMC0weGRmZmZmZmZmDQogICAgICAgICAgICAgICAgMHhmODMwMDAw MC0weGY4MzdmZmZmDQogICAgICAgICAgICAgICAgMHhmODQwMDAwMC0weGY4 NDNmZmZmDQogICAgICAgICAgYWdwMA0KICAgICAgICAgICAgICBJL08gbWVt b3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAgICAgIDB4ODAwMDAwMDAt MHg4MDAwMGZmZg0KICAgICAgICAgIGFjcGlfdmlkZW8wDQogICAgICAgICAg ZHJtbjANCiAgICAgICAgICAgIGludGVsX2lpY2JiMA0KICAgICAgICAgICAg ICBpaWNiYjANCiAgICAgICAgICAgICAgICBpaWNidXMwDQogICAgICAgICAg ICAgICAgICBpaWNzbWIwDQogICAgICAgICAgICAgICAgICAgIHNtYnVzMA0K ICAgICAgICAgICAgICAgICAgICAgIHNtYjANCiAgICAgICAgICAgICAgICAg IGlpYzANCiAgICAgICAgICAgIGludGVsX2dtYnVzMA0KICAgICAgICAgICAg ICBpaWNidXMxDQogICAgICAgICAgICAgICAgaWljc21iMQ0KICAgICAgICAg ICAgICAgICAgc21idXMxDQogICAgICAgICAgICAgICAgICAgIHNtYjENCiAg ICAgICAgICAgICAgICBpaWMxDQogICAgICAgICAgICBpbnRlbF9paWNiYjEN CiAgICAgICAgICAgICAgaWljYmIxDQogICAgICAgICAgICAgICAgaWljYnVz Mg0KICAgICAgICAgICAgICAgICAgaWljc21iMg0KICAgICAgICAgICAgICAg ICAgICBzbWJ1czINCiAgICAgICAgICAgICAgICAgICAgICBzbWIyDQogICAg ICAgICAgICAgICAgICBpaWMyDQogICAgICAgICAgICBpbnRlbF9nbWJ1czEN CiAgICAgICAgICAgICAgaWljYnVzMw0KICAgICAgICAgICAgICAgIGlpY3Nt YjMNCiAgICAgICAgICAgICAgICAgIHNtYnVzMw0KICAgICAgICAgICAgICAg ICAgICBzbWIzDQogICAgICAgICAgICAgICAgaWljMw0KICAgICAgICAgICAg aW50ZWxfaWljYmIyDQogICAgICAgICAgICAgIGlpY2JiMg0KICAgICAgICAg ICAgICAgIGlpY2J1czQNCiAgICAgICAgICAgICAgICAgIGlpY3NtYjQNCiAg ICAgICAgICAgICAgICAgICAgc21idXM0DQogICAgICAgICAgICAgICAgICAg ICAgc21iNA0KICAgICAgICAgICAgICAgICAgaWljNA0KICAgICAgICAgICAg aW50ZWxfZ21idXMyDQogICAgICAgICAgICAgIGlpY2J1czUNCiAgICAgICAg ICAgICAgICBpaWNzbWI1DQogICAgICAgICAgICAgICAgICBzbWJ1czUNCiAg ICAgICAgICAgICAgICAgICAgc21iNQ0KICAgICAgICAgICAgICAgIGlpYzUN CiAgICAgICAgICAgIGludGVsX2lpY2JiMw0KICAgICAgICAgICAgICBpaWNi YjMNCiAgICAgICAgICAgICAgICBpaWNidXM2DQogICAgICAgICAgICAgICAg ICBpaWNzbWI2DQogICAgICAgICAgICAgICAgICAgIHNtYnVzNg0KICAgICAg ICAgICAgICAgICAgICAgIHNtYjYNCiAgICAgICAgICAgICAgICAgIGlpYzYN CiAgICAgICAgICAgIGludGVsX2dtYnVzMw0KICAgICAgICAgICAgICBpaWNi dXM3DQogICAgICAgICAgICAgICAgaWljc21iNw0KICAgICAgICAgICAgICAg ICAgc21idXM3DQogICAgICAgICAgICAgICAgICAgIHNtYjcNCiAgICAgICAg ICAgICAgICBpaWM3DQogICAgICAgICAgICBpbnRlbF9paWNiYjQNCiAgICAg ICAgICAgICAgaWljYmI0DQogICAgICAgICAgICAgICAgaWljYnVzOA0KICAg ICAgICAgICAgICAgICAgaWljc21iOA0KICAgICAgICAgICAgICAgICAgICBz bWJ1czgNCiAgICAgICAgICAgICAgICAgICAgICBzbWI4DQogICAgICAgICAg ICAgICAgICBpaWM4DQogICAgICAgICAgICBpbnRlbF9nbWJ1czQNCiAgICAg ICAgICAgICAgaWljYnVzOQ0KICAgICAgICAgICAgICAgIGlpY3NtYjkNCiAg ICAgICAgICAgICAgICAgIHNtYnVzOQ0KICAgICAgICAgICAgICAgICAgICBz bWI5DQogICAgICAgICAgICAgICAgaWljOQ0KICAgICAgICAgICAgaW50ZWxf aWljYmI1DQogICAgICAgICAgICAgIGlpY2JiNQ0KICAgICAgICAgICAgICAg IGlpY2J1czEwDQogICAgICAgICAgICAgICAgICBpaWNzbWIxMA0KICAgICAg ICAgICAgICAgICAgICBzbWJ1czEwDQogICAgICAgICAgICAgICAgICAgICAg c21iMTANCiAgICAgICAgICAgICAgICAgIGlpYzEwDQogICAgICAgICAgICBp bnRlbF9nbWJ1czUNCiAgICAgICAgICAgICAgaWljYnVzMTENCiAgICAgICAg ICAgICAgICBpaWNzbWIxMQ0KICAgICAgICAgICAgICAgICAgc21idXMxMQ0K ICAgICAgICAgICAgICAgICAgICBzbWIxMQ0KICAgICAgICAgICAgICAgIGlp YzExDQogICAgICAgICAgICBpbnRlbF9paWNiYjYNCiAgICAgICAgICAgICAg aWljYmI2DQogICAgICAgICAgICAgICAgaWljYnVzMTINCiAgICAgICAgICAg ICAgICAgIGlpY3NtYjEyDQogICAgICAgICAgICAgICAgICAgIHNtYnVzMTIN CiAgICAgICAgICAgICAgICAgICAgICBzbWIxMg0KICAgICAgICAgICAgICAg ICAgaWljMTINCiAgICAgICAgICAgIGludGVsX2dtYnVzNg0KICAgICAgICAg ICAgICBpaWNidXMxMw0KICAgICAgICAgICAgICAgIGlpY3NtYjEzDQogICAg ICAgICAgICAgICAgICBzbWJ1czEzDQogICAgICAgICAgICAgICAgICAgIHNt YjEzDQogICAgICAgICAgICAgICAgaWljMTMNCiAgICAgICAgICAgIGludGVs X2lpY2JiNw0KICAgICAgICAgICAgICBpaWNiYjcNCiAgICAgICAgICAgICAg ICBpaWNidXMxNA0KICAgICAgICAgICAgICAgICAgaWljc21iMTQNCiAgICAg ICAgICAgICAgICAgICAgc21idXMxNA0KICAgICAgICAgICAgICAgICAgICAg IHNtYjE0DQogICAgICAgICAgICAgICAgICBpaWMxNA0KICAgICAgICAgICAg aW50ZWxfZ21idXM3DQogICAgICAgICAgICAgIGlpY2J1czE1DQogICAgICAg ICAgICAgICAgaWljc21iMTUNCiAgICAgICAgICAgICAgICAgIHNtYnVzMTUN CiAgICAgICAgICAgICAgICAgICAgc21iMTUNCiAgICAgICAgICAgICAgICBp aWMxNQ0KICAgICAgICAgICAgZmJkMA0KICAgICAgICB2Z2FwY2kxDQogICAg ICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAg ICAweGY4MzgwMDAwLTB4ZjgzZmZmZmYNCiAgICAgICAgaGRhYzANCiAgICAg ICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAg ICAgIDI1Ng0KICAgICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQog ICAgICAgICAgICAgICAgMHhmODQ0MDAwMC0weGY4NDQzZmZmDQogICAgICAg ICAgaGRhY2MwDQogICAgICAgICAgICBoZGFhMA0KICAgICAgICAgICAgICBw Y20wDQogICAgICAgICAgICAgIHBjbTENCiAgICAgICAgICBoZGFjYzENCiAg ICAgICAgcGNpYjENCiAgICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAg ICAgICAgICAweDIwMDAtMHgyMGZmDQogICAgICAgICAgICAgICAgMHgyNDAw LTB4MjRmZg0KICAgICAgICAgICAgICAgIDB4MjgwMC0weDI4ZmYNCiAgICAg ICAgICAgICAgICAweDJjMDAtMHgyY2ZmDQogICAgICAgICAgICBJL08gbWVt b3J5IGFkZHJlc3NlczoNCiAgICAgICAgICAgICAgICAweGYwMDAwMDAwLTB4 ZjFmZmZmZmYNCiAgICAgICAgICAgICAgICAweGY0MDAwMDAwLTB4ZjVmZmZm ZmYNCiAgICAgICAgICAgIFBDSSBkb21haW4gMCBidXMgbnVtYmVyczoNCiAg ICAgICAgICAgICAgICAyLTUNCiAgICAgICAgICBwY2kyDQogICAgICAgICAg ICAgIHBjaWIxIGJ1cyBudW1iZXJzOg0KICAgICAgICAgICAgICAgICAgMg0K ICAgICAgICBwY2liMg0KICAgICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNz ZXM6DQogICAgICAgICAgICAgICAgMHhmODEwMDAwMC0weGY4MWZmZmZmDQog ICAgICAgICAgICBQQ0kgZG9tYWluIDAgYnVzIG51bWJlcnM6DQogICAgICAg ICAgICAgICAgNg0KICAgICAgICAgIHBjaTYNCiAgICAgICAgICAgICAgcGNp YjIgYnVzIG51bWJlcnM6DQogICAgICAgICAgICAgICAgICA2DQogICAgICAg ICAgICB3cGkwDQogICAgICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3Qg bGluZXM6DQogICAgICAgICAgICAgICAgICAgIDE3DQogICAgICAgICAgICAg ICAgcGNpYjIgbWVtb3J5IHdpbmRvdzoNCiAgICAgICAgICAgICAgICAgICAg MHhmODEwMDAwMC0weGY4MTAwZmZmDQogICAgICAgIHBjaWIzDQogICAgICAg ICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAgICAgMHgzMDAwLTB4MzBm Zg0KICAgICAgICAgICAgICAgIDB4MzQwMC0weDM0ZmYNCiAgICAgICAgICAg ICAgICAweDM4MDAtMHgzOGZmDQogICAgICAgICAgICAgICAgMHgzYzAwLTB4 M2NmZg0KICAgICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAg ICAgICAgICAgICAgMHhmODAwMDAwMC0weGY4MGZmZmZmDQogICAgICAgICAg ICBQQ0kgZG9tYWluIDAgYnVzIG51bWJlcnM6DQogICAgICAgICAgICAgICAg Nw0KICAgICAgICAgIHBjaTcNCiAgICAgICAgICAgICAgcGNpYjMgYnVzIG51 bWJlcnM6DQogICAgICAgICAgICAgICAgICA3DQogICAgICAgICAgICBtc2tj MA0KICAgICAgICAgICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0K ICAgICAgICAgICAgICAgICAgICAyNTcNCiAgICAgICAgICAgICAgICBwY2li MyBJL08gcG9ydCB3aW5kb3c6DQogICAgICAgICAgICAgICAgICAgIDB4MzAw MC0weDMwZmYNCiAgICAgICAgICAgICAgICBwY2liMyBtZW1vcnkgd2luZG93 Og0KICAgICAgICAgICAgICAgICAgICAweGY4MDAwMDAwLTB4ZjgwMDNmZmYN CiAgICAgICAgICAgICAgbXNrMA0KICAgICAgICAgICAgICAgIG1paWJ1czAN CiAgICAgICAgICAgICAgICAgIGUxMDAwcGh5MA0KICAgICAgICBwY2liNA0K ICAgICAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgICAgIDB4NDAw MC0weDQwZmYNCiAgICAgICAgICAgICAgICAweDQ0MDAtMHg0NGZmDQogICAg ICAgICAgICAgICAgMHg0ODAwLTB4NDhmZg0KICAgICAgICAgICAgICAgIDB4 NGMwMC0weDRjZmYNCiAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2Vz Og0KICAgICAgICAgICAgICAgIDB4ZjIwMDAwMDAtMHhmM2ZmZmZmZg0KICAg ICAgICAgICAgICAgIDB4ZjYwMDAwMDAtMHhmN2ZmZmZmZg0KICAgICAgICAg ICAgUENJIGRvbWFpbiAwIGJ1cyBudW1iZXJzOg0KICAgICAgICAgICAgICAg IDgNCiAgICAgICAgICBwY2k4DQogICAgICAgICAgICAgIHBjaWI0IGJ1cyBu dW1iZXJzOg0KICAgICAgICAgICAgICAgICAgOA0KICAgICAgICB1aGNpMA0K ICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAg ICAgICAgICAgMTkNCiAgICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAg ICAgICAgICAweDE4MjAtMHgxODNmDQogICAgICAgICAgdXNidXMwDQogICAg ICAgICAgICB1aHViMA0KICAgICAgICB1aGNpMQ0KICAgICAgICAgICAgSW50 ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAgICAgMTkNCiAg ICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgICAgICAweDE4NDAt MHgxODVmDQogICAgICAgICAgdXNidXMxDQogICAgICAgICAgICB1aHViMQ0K ICAgICAgICB1aGNpMg0KICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3Qg bGluZXM6DQogICAgICAgICAgICAgICAgMTkNCiAgICAgICAgICAgIEkvTyBw b3J0czoNCiAgICAgICAgICAgICAgICAweDE4NjAtMHgxODdmDQogICAgICAg ICAgdXNidXMyDQogICAgICAgICAgICB1aHViMg0KICAgICAgICB1aGNpMw0K ICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAg ICAgICAgICAgMTkNCiAgICAgICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAg ICAgICAgICAweDE4ODAtMHgxODlmDQogICAgICAgICAgdXNidXMzDQogICAg ICAgICAgICB1aHViMw0KICAgICAgICBlaGNpMA0KICAgICAgICAgICAgSW50 ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAgICAgMjMNCiAg ICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAgICAgICAgICAg ICAgIDB4Zjg2NDQwMDAtMHhmODY0NDNmZg0KICAgICAgICAgIHVzYnVzNA0K ICAgICAgICAgICAgdWh1YjQNCiAgICAgICAgICAgICAgdW1hc3MwDQogICAg ICAgIHBjaWI1DQogICAgICAgICAgICBJL08gbWVtb3J5IGFkZHJlc3NlczoN CiAgICAgICAgICAgICAgICAweGY4MjAwMDAwLTB4ZjgyZmZmZmYNCiAgICAg ICAgICAgIFBDSSBkb21haW4gMCBidXMgbnVtYmVyczoNCiAgICAgICAgICAg ICAgICA5LTEwDQogICAgICAgICAgcGNpOQ0KICAgICAgICAgICAgICBwY2li NSBidXMgbnVtYmVyczoNCiAgICAgICAgICAgICAgICAgIDkNCiAgICAgICAg ICAgIGNiYjANCiAgICAgICAgICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBs aW5lczoNCiAgICAgICAgICAgICAgICAgICAgMjANCiAgICAgICAgICAgICAg ICBwY2liNSBidXMgbnVtYmVyczoNCiAgICAgICAgICAgICAgICAgICAgMTAN CiAgICAgICAgICAgICAgICBwY2liNSBtZW1vcnkgd2luZG93Og0KICAgICAg ICAgICAgICAgICAgICAweGY4MjA2MDAwLTB4ZjgyMDZmZmYNCiAgICAgICAg ICAgICAgY2FyZGJ1czANCiAgICAgICAgICAgICAgICAgIGNiYjAgYnVzIG51 bWJlcnM6DQogICAgICAgICAgICAgICAgICAgICAgMTANCiAgICAgICAgICAg ICAgcGNjYXJkMA0KICAgICAgICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVl c3QgbGluZXM6DQogICAgICAgICAgICAgICAgICAgICAgMjANCiAgICAgICAg ICAgICAgICAgIHBjaWI1IG1lbW9yeSB3aW5kb3c6DQogICAgICAgICAgICAg ICAgICAgICAgMHhmODIwNzAwMC0weGY4MjA3M2ZmDQogICAgICAgICAgICAg ICAgY214MA0KICAgICAgICAgICAgICAgICAgICBJL08gcG9ydHM6DQogICAg ICAgICAgICAgICAgICAgICAgICAweDEwODAtMHgxMDg3DQogICAgICAgICAg ICBmd29oY2kwDQogICAgICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3Qg bGluZXM6DQogICAgICAgICAgICAgICAgICAgIDIxDQogICAgICAgICAgICAg ICAgcGNpYjUgbWVtb3J5IHdpbmRvdzoNCiAgICAgICAgICAgICAgICAgICAg MHhmODIwMDAwMC0weGY4MjAzZmZmDQogICAgICAgICAgICAgICAgICAgIDB4 ZjgyMDUwMDAtMHhmODIwNTdmZg0KICAgICAgICAgICAgICBmaXJld2lyZTAN CiAgICAgICAgICAgICAgICBkY29uc19jcm9tMA0KICAgICAgICAgICAgICAg IGZ3ZTANCiAgICAgICAgICAgICAgICBmd2lwMA0KICAgICAgICAgICAgICAg IHNicDANCiAgICAgICAgaXNhYjANCiAgICAgICAgICBpc2EwDQogICAgICAg ICAgICBvcm0wDQogICAgICAgICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNz ZXM6DQogICAgICAgICAgICAgICAgICAgIDB4YzAwMDAtMHhjZmZmZg0KICAg ICAgICAgICAgICAgICAgICAweGRjMDAwLTB4ZGZmZmYNCiAgICAgICAgYXRh cGNpMA0KICAgICAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAgICAg IDB4MTcwLTB4MTc3DQogICAgICAgICAgICAgICAgMHgxZjAtMHgxZjcNCiAg ICAgICAgICAgICAgICAweDM3Ng0KICAgICAgICAgICAgICAgIDB4M2Y2DQog ICAgICAgICAgICAgICAgMHgxODEwLTB4MTgxZg0KICAgICAgICAgIGF0YTAN CiAgICAgICAgICAgICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAg ICAgICAgICAgICAgICAxNA0KICAgICAgICBhaGNpMA0KICAgICAgICAgICAg SW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAgICAgMjU4 DQogICAgICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAgICAgMHgx OGIwLTB4MThiZg0KICAgICAgICAgICAgICAgIDB4MThjMC0weDE4YzMNCiAg ICAgICAgICAgICAgICAweDE4YzQtMHgxOGM3DQogICAgICAgICAgICAgICAg MHgxOGM4LTB4MThjZg0KICAgICAgICAgICAgICAgIDB4MThkMC0weDE4ZDcN CiAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2VzOg0KICAgICAgICAg ICAgICAgIDB4Zjg2NDQ0MDAtMHhmODY0NDdmZg0KICAgICAgICAgIGFoY2lj aDANCiAgICAgICAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNzZXM6DQogICAg ICAgICAgICAgICAgICAweGY4NjQ0NTAwLTB4Zjg2NDQ1N2YNCiAgICAgICAg ICBhaGNpY2gyDQogICAgICAgICAgICAgIEkvTyBtZW1vcnkgYWRkcmVzc2Vz Og0KICAgICAgICAgICAgICAgICAgMHhmODY0NDYwMC0weGY4NjQ0NjdmDQog ICAgYWNwaV9zeXNyZXNvdXJjZTANCiAgICBwY2lfbGluazANCiAgICBwY2lf bGluazENCiAgICBwY2lfbGluazINCiAgICBwY2lfbGluazMNCiAgICBwY2lf bGluazQNCiAgICBwY2lfbGluazUNCiAgICBwY2lfbGluazYNCiAgICBwY2lf bGluazcNCiAgICBhY3BpX2VjMA0KICAgICAgICBJL08gcG9ydHM6DQogICAg ICAgICAgICAweDYyDQogICAgICAgICAgICAweDY2DQogICAgYmF0dGVyeTAN CiAgICBhY3BpX2FjYWQwDQogICAgYXRkbWEwDQogICAgICAgIERNQSByZXF1 ZXN0IGxpbmVzOg0KICAgICAgICAgICAgNA0KICAgICAgICBJL08gcG9ydHM6 DQogICAgICAgICAgICAweDAtMHgxZg0KICAgICAgICAgICAgMHg4MS0weDkx DQogICAgICAgICAgICAweDkzLTB4OWYNCiAgICAgICAgICAgIDB4YzAtMHhk Zg0KICAgIGhwZXQwDQogICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVz Og0KICAgICAgICAgICAgMjANCiAgICAgICAgSS9PIG1lbW9yeSBhZGRyZXNz ZXM6DQogICAgICAgICAgICAweGZlZDAwMDAwLTB4ZmVkMDAzZmYNCiAgICBm cHVwbnAwDQogICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgIDB4ZjAN CiAgICBhY3BpX3N5c3Jlc291cmNlMQ0KICAgIGF0cnRjMA0KICAgICAgICBJ bnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAgICAgICAgICAgIDgNCiAgICBh dHRpbWVyMA0KICAgICAgICBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lczoNCiAg ICAgICAgICAgIDANCiAgICAgICAgSS9PIHBvcnRzOg0KICAgICAgICAgICAg MHg0MC0weDQzDQogICAgICAgICAgICAweDUwLTB4NTMNCiAgICBhY3BpX3Nv bnkwDQogICAgICAgIEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAg ICAgICAgNg0KICAgICAgICBJL08gcG9ydHM6DQogICAgICAgICAgICAweGMw MDAtMHhjMDFmDQogICAgYWNwaV9zb255MQ0KICAgIGF0a2JkYzANCiAgICAg ICAgSW50ZXJydXB0IHJlcXVlc3QgbGluZXM6DQogICAgICAgICAgICAxDQog ICAgICAgIEkvTyBwb3J0czoNCiAgICAgICAgICAgIDB4NjANCiAgICAgICAg ICAgIDB4NjQNCiAgICAgIGF0a2JkMA0KICAgICAgcHNtMA0KICAgICAgICAg IEludGVycnVwdCByZXF1ZXN0IGxpbmVzOg0KICAgICAgICAgICAgICAxMg0K ICAgIHBzbWNwbnAwDQogICAgYWNwaV90ejANCiAgICBhY3BpX3R6MQ0KICAg IGFjcGlfdHoyDQogICAgYWNwaV90aW1lcjANCiAgICAgICAgQUNQSSBJL08g cG9ydHM6DQogICAgICAgICAgICAweDEwMDgtMHgxMDBiDQo= --1563967779-517861614-1410555476=:62150-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 21:12:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0DD7939; Fri, 12 Sep 2014 21:12:48 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14304A5D; Fri, 12 Sep 2014 21:12:47 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id p9so1567280lbv.24 for ; Fri, 12 Sep 2014 14:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=BiwI8bxe6j61m6FQOT3xUVmkSeuyObqT4KvRoM4xEV0=; b=Xm+Yy5AYmw+G27Ixvgkqi1xuzk0A7I2I2Am0uEQv5/6fF3R1DjGzvEkwTWrdG3UYnI MUTKEN2uM+lhmamS17BuatBGH3V1CFHqVE1eikBGl5xuPKiaoIRWmx+uD6AQu0WuAzxs 6Ht2cvalrr9wJ+lNe0MVRYyyDfxllUEDUdE91z8DILkKRfJBnP9qpmFzG2u6ApZDVD68 aTlRnJfYe6BCQpUBSHtpPjkA7Oc9N6jv0RrQBF3XJtM40GkVJ7QwUWrLJItILRkhXEl2 b+o+oKP3CWeQZ1/XOE0KhA9TEt8KQOVyEHcfaALkm9Ae+PyxpqOWmw19AHUpY6irqyFD LiSg== MIME-Version: 1.0 X-Received: by 10.152.115.195 with SMTP id jq3mr6236387lab.90.1410556365871; Fri, 12 Sep 2014 14:12:45 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Fri, 12 Sep 2014 14:12:45 -0700 (PDT) Date: Fri, 12 Sep 2014 14:12:45 -0700 X-Google-Sender-Auth: TLYlDFDg3WuV0mS2IAteV2MTzv0 Message-ID: Subject: shells/bash port, add a knob which symlinks to /bin/bash ? From: Craig Rodrigues To: ports , Emanuel Haupt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: 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: Fri, 12 Sep 2014 21:12:49 -0000 Hi, In the last 3 jobs that I have worked at, there have been a mix of Linux machines and FreeBSD machines. When using an NIS or LDAP environment where there is a single login across multiple machines, it is useful to have a single shell setting. Since Linux and MacOS X have "/bin/bash" as the shell, in order to get the FreeBSD boxes to play in this environment, I have seen admins do the following on FreeBSD setups: ln -s /usr/local/bin/bash /bin/bash or ln /usr/local/bin/bash /bin/bash and then make sure that /etc/shells as: /usr/local/bin/bash /bin/bash Can we add an optional knob (turned off by default) which creates this symlink and updates /etc/shells? This would help with interoperability of FreeBSD hosts in environments mixed with Linux and MacOS X. -- Craig From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 21:38:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A6279D6 for ; Fri, 12 Sep 2014 21:38:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09592D06 for ; Fri, 12 Sep 2014 21:38:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8CLceS1058402 for ; Fri, 12 Sep 2014 21:38:40 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8CLceXc058401 for freebsd-current@freebsd.org; Fri, 12 Sep 2014 21:38:40 GMT (envelope-from bdrewery) Received: (qmail 74052 invoked from network); 12 Sep 2014 16:38:34 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 12 Sep 2014 16:38:34 -0500 Message-ID: <541367D1.8090002@FreeBSD.org> Date: Fri, 12 Sep 2014 16:38:25 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Craig Rodrigues , ports , Emanuel Haupt Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: In-Reply-To: OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F7FUAdP0V4vcjdqnOdPIBbe1OrETM8Sfo" Cc: 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: Fri, 12 Sep 2014 21:38:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F7FUAdP0V4vcjdqnOdPIBbe1OrETM8Sfo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "No" (as portmgr). Ports should not be touching the base system like this. Let's NOT go backwards and add a /bin/bash. In fact the /usr/bin/perl one will be removed soon as well. If we can actually eliminate ports touching /usr and / (not including /usr/local and /var) then we gain a very large memory optimization for package building by being able to ro null-mount these to the build jails.= There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. We install all packages to PREFIX=3D/usr/local by default. Why should a bin symlink be an exception? There's no suggestion for symlinking includes or libraries which also hit users often. On 9/12/2014 4:12 PM, Craig Rodrigues wrote: > Hi, >=20 > In the last 3 jobs that I have worked at, there have been > a mix of Linux machines and FreeBSD machines. > When using an NIS or LDAP environment where > there is a single login across multiple machines, it is useful to > have a single shell setting. >=20 > Since Linux and MacOS X have "/bin/bash" as the shell, > in order to get the FreeBSD boxes to play in this environment, > I have seen admins do the following on FreeBSD setups: > ln -s /usr/local/bin/bash /bin/bash >=20 > or >=20 > ln /usr/local/bin/bash /bin/bash >=20 > and then make sure that /etc/shells as: > /usr/local/bin/bash > /bin/bash >=20 > Can we add an optional knob (turned off by default) which creates this > symlink > and updates /etc/shells? >=20 > This would help with interoperability of FreeBSD hosts in environments = mixed > with Linux and MacOS X. >=20 > -- > Craig > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org= " >=20 --=20 Regards, Bryan Drewery --F7FUAdP0V4vcjdqnOdPIBbe1OrETM8Sfo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUE2fRAAoJEDXXcbtuRpfPxocH/2jJqFz0Ba3dJprTIAs7+qRR uUuD51jqElpSSL62kQZkrqPEIsReq2Y2cM7mAng3uArtbtP8s9GOYMT2fxVqxJOR 76OUz2F2EmXpIruOcu2/hSHS2FBQZGhb23CprLB6oncziByxiTJYvKIzthBlve7M xJ+oWZxHwOsIDFS+UhkVr2wutMf2oDfaRBbFNLIFpu5OmsCwXzH3YTgwuttFE5J6 OUcDYozWQcDY2a6hUMut+BQqPinKSvCtRrDoQ/HMY14aY2a0SeDz3DEHIufvuX/+ aqRr8KvB8JoVXQrqZwR+vmII2K5iEo+qL96XSwN5Js61vZCLvpBAYAjT6MipKvk= =1u+b -----END PGP SIGNATURE----- --F7FUAdP0V4vcjdqnOdPIBbe1OrETM8Sfo-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 21:40:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46EDBB73; Fri, 12 Sep 2014 21:40:11 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 636E1D21; Fri, 12 Sep 2014 21:40:10 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id k48so1357075wev.13 for ; Fri, 12 Sep 2014 14:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=xQJk2SoNiTsxGawWwWh//09pAb/0moDJ7QWI6giacGA=; b=w11lWyVkpnmXfebAiy/jdu3j5kNoh6WN6D+DdTJ7mLkoU+5BDP/dIZJeXm1DI9KsMW SP6oWejOpJyb/flJ2zOVPSdpeK4L8epgExrWF6Ykb0EgyPnHsUjhQLoX0T9OSwK4IcEU vyA1ofZGsvK8zWGs6qC8GW7VbUYBRPTLACo/jV5TAI5wS8mJ4vCb6VWzSX+ktk1lwoQO t9wNxg5Dx2hEK482A/SoGOzWSXWqoCyRO/cr5vH+hEQIfikpd5Fg/XU62hN9/9wRW00Z hOQpsbmndXdxTLbjhjUioa0zmBTN/W79E3dAqYrXXRg4zn6emOfXMA/bqflv5kBBB7ad 3LkQ== X-Received: by 10.180.95.68 with SMTP id di4mr5843075wib.60.1410558007840; Fri, 12 Sep 2014 14:40:07 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id gm2sm2986184wib.15.2014.09.12.14.40.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 14:40:06 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 12 Sep 2014 23:40:04 +0200 From: Baptiste Daroussin To: Craig Rodrigues Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? Message-ID: <20140912214004.GT6096@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uWCTLymdFNG0vGYZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current Current , Emanuel Haupt , ports 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, 12 Sep 2014 21:40:11 -0000 --uWCTLymdFNG0vGYZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 12, 2014 at 02:12:45PM -0700, Craig Rodrigues wrote: > Hi, >=20 > In the last 3 jobs that I have worked at, there have been > a mix of Linux machines and FreeBSD machines. > When using an NIS or LDAP environment where > there is a single login across multiple machines, it is useful to > have a single shell setting. >=20 > Since Linux and MacOS X have "/bin/bash" as the shell, > in order to get the FreeBSD boxes to play in this environment, > I have seen admins do the following on FreeBSD setups: > ln -s /usr/local/bin/bash /bin/bash >=20 > or >=20 > ln /usr/local/bin/bash /bin/bash >=20 > and then make sure that /etc/shells as: > /usr/local/bin/bash > /bin/bash >=20 > Can we add an optional knob (turned off by default) which creates this > symlink > and updates /etc/shells? >=20 > This would help with interoperability of FreeBSD hosts in environments mi= xed > with Linux and MacOS X. >=20 Please no, no and no! We are fighting for a very long time to prevent the ports to pollute base. We have added the shebangfix USES to be able to catch with up with cleanup = this properly as well as a qa test to discover it automatically. no interpreters at all have a symlink in base but perl and this one is goin= g to be removed. If you want interoperability just use /usr/bin/env bash as a shebang. Btw y= ou cannot get interoprability with OS-X in there because the bash they do prov= ide is the last GPL-2 recent bash have many incompatiblities with this old vers= ion. regards, Bapt --uWCTLymdFNG0vGYZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQTaDQACgkQ8kTtMUmk6EzmwwCfWF5BSfz6bt5fSCl5LLQBrq9a v4kAn3nBv0oc40nBTHESWTV7A6iGalb+ =x3Ob -----END PGP SIGNATURE----- --uWCTLymdFNG0vGYZ-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 21:49:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CA796D; Fri, 12 Sep 2014 21:49:41 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17FFADF7; Fri, 12 Sep 2014 21:49:40 +0000 (UTC) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8CLnc62032654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 17:49:38 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s8CLnc62032654 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1410558578; bh=5f1kPsawuxqpWnB1Ss6P0hOyheI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=d4gLZ3zQPuOkOcnPGipzGqIhwLGG+flIKeugn4XO6wV0MmUtCxpc0+54QmelmdLv7 wX4vZNkN1gwYWEMc+uJJUaEvYqLJJEtJbpeI6wJxFX6rRrdepBlxFoBA8fogeFpXiZ D76vaNankN7ZpklxM2iB6Y0fuiRvchw//D5B3wrE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s8CLnc62032654 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd01.lss.emc.com (RSA Interceptor); Fri, 12 Sep 2014 17:49:05 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8CLnKTc028493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 17:49:20 -0400 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub30.corp.emc.com (128.222.70.170) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 12 Sep 2014 17:49:20 -0400 Received: from MX104CL01.corp.emc.com ([169.254.7.35]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 17:49:19 -0400 From: "Rang, Anton" To: Baptiste Daroussin , Craig Rodrigues Subject: RE: shells/bash port, add a knob which symlinks to /bin/bash ? Thread-Topic: shells/bash port, add a knob which symlinks to /bin/bash ? Thread-Index: AQHPzs5VcZ+FDNlqm0u14gwbSgE0/Zv+SasA//+9vxA= Date: Fri, 12 Sep 2014 21:49:19 +0000 Message-ID: References: <20140912214004.GT6096@ivaldir.etoilebsd.net> In-Reply-To: <20140912214004.GT6096@ivaldir.etoilebsd.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.41.58] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Cc: freebsd-current Current , ports , Emanuel Haupt 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, 12 Sep 2014 21:49:41 -0000 > If you want interoperability just use /usr/bin/env bash as a shebang. That doesn't work for this use case -- the user shell coming from LDAP -- b= ut I agree that the port shouldn't be modifying /usr/bin. It's easy enough to add the symlink manually after installing the port if y= ou're in this situation, or there may be a way to configure the LDAP module= to map /bin/bash to /usr/local/bin/bash (I haven't looked to see what is s= upported here). Anton From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 21:53:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82476292; Fri, 12 Sep 2014 21:53:36 +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 09C84EAF; Fri, 12 Sep 2014 21:53:35 +0000 (UTC) X-AuditID: 1209190e-f79d46d000003643-bd-54136b576648 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id EB.4B.13891.75B63145; Fri, 12 Sep 2014 17:53:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s8CLrRi9008496; Fri, 12 Sep 2014 17:53:27 -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 s8CLrOdT026272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Sep 2014 17:53:26 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8CLrOls017928; Fri, 12 Sep 2014 17:53:24 -0400 (EDT) Date: Fri, 12 Sep 2014 17:53:24 -0400 (EDT) From: Benjamin Kaduk To: "Rang, Anton" Subject: RE: shells/bash port, add a knob which symlinks to /bin/bash ? In-Reply-To: Message-ID: References: <20140912214004.GT6096@ivaldir.etoilebsd.net> 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+NgFmplleLIzCtJLcpLzFFi42IRYrdT143IFg4x+PWNyeLQi+NMFnPefGCy 2HT4LaMDs8eMT/NZPL5/2MwWwBTFZZOSmpNZllqkb5fAlfFodlHBWbaKPTveMTYwrmLtYuTk kBAwkWj++ZMRwhaTuHBvPVsXIxeHkMBsJomOnzdYIJyNjBJ9z0A6QJxDTBKTtzRBZRoYJdZf vMUO0s8ioC0x8/tBFhCbTUBFYuabjWwgtoiApsSFBx/A4swCqRKv7q0Bs4UF3CVmPb4DtptT wE/i565NzCA2r4CjRPv8ZnaIBQcYJbbvWwR2rKiAjsTq/VNYIIoEJU7OfAI1VEti+fRtLBMY BWchSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gvN7NELzWldBMjKGw5Jfl2MH49 qHSIUYCDUYmHd6aucIgQa2JZcWXuIUZJDiYlUV71dKAQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed6oIKAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr2QWUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8MJMkOHFBYm5xZnpEPlTjMYcLU1ve5k41nV+62cSYsnLz0uVEudt ASkVACnNKM2DmwZLPa8YxYGeE+Y1BVnKA0xbcPNeAa1iAlr1bo4QyKqSRISUVAOj9rbOY0Ed In5blRMFF52YdLk1ep/BBva5257z9jLrT9Lr+vXZIcdArpnVqVp/+T2OBT5e/rU5h29FrhR/ rG/+Zurs3Qr3/S+EGjB6PeCQduuS6+dvOJKxJCX1xZL3LPKR0n82Xj/Sc2jz00tc15Zus7KX yHwjZjyR78SbL7fk9u+P+ywY84VZiaU4I9FQi7moOBEABLB2aBgDAAA= Cc: freebsd-current Current , ports 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, 12 Sep 2014 21:53:36 -0000 On Fri, 12 Sep 2014, Rang, Anton wrote: > > If you want interoperability just use /usr/bin/env bash as a shebang. > > That doesn't work for this use case -- the user shell coming from LDAP > -- but I agree that the port shouldn't be modifying /usr/bin. Here at MIT, where our Athena environment has a long history of providing a consistent experience across many different platforms, we ended up limiting the login shells a user could select, to a whitelist we provide (/bin/sh, /usr/athena/bin/bash, and /usr/athena/bin/tcsh). (The latter two are now symlinks to the normal system shells, but they used to be custom binaries.) Some people did not like being so restricted, and set their login shell to /bin/sh, with logic in their dotfiles to re-exec a different shell depending on the current runtime environment. -Ben From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 21:55:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A74D0465 for ; Fri, 12 Sep 2014 21:55:30 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DD33ED7 for ; Fri, 12 Sep 2014 21:55:30 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68361B968; Fri, 12 Sep 2014 17:55:29 -0400 (EDT) From: John Baldwin To: Marcin Cieslak Subject: Re: panic: resource_list_alloc: resource entry is busy Date: Fri, 12 Sep 2014 17:06:39 -0400 Message-ID: <3819796.R7BYA2qqa8@ralph.baldwin.cx> User-Agent: KMail/4.10.5 (FreeBSD/10.0-STABLE; KDE/4.10.5; amd64; ; ) In-Reply-To: References: <1584874.3FXdLuYUQI@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Sep 2014 17:55:29 -0400 (EDT) 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: Fri, 12 Sep 2014 21:55:30 -0000 On Friday, September 12, 2014 08:57:55 PM Marcin Cieslak wrote: > On Fri, 12 Sep 2014, John Baldwin wrote: > >> at /usr/src/sys/dev/pci/vga_pci.c:318 > >> > >> 318 return (bus_alloc_resource(dev, type, rid, start, end, count, > > > > flags)); > > > >> Current language: auto; currently minimal > >> (kgdb) p *rid > >> $1 = 0 > > > > Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. > > > > Oh, some other child of vgapci has already allocated the IRQ. That seems > > odd. > > > > Can you get 'devinfo -r' output before you kldload i915kms and again after > > doing the kldload? (No need to run startx) > > Please note I originally loaded "i915.ko", not "i915kms.ko" Oh, that is probably your problem. X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:02:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5692E8FD for ; Fri, 12 Sep 2014 22:02:06 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 42CE1FA7 for ; Fri, 12 Sep 2014 22:02:06 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 5558F346DE11 for ; Fri, 12 Sep 2014 15:02:00 -0700 (PDT) Message-ID: <54136D5D.3090905@mu.org> Date: Fri, 12 Sep 2014 15:02:05 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <20140912214004.GT6096@ivaldir.etoilebsd.net> In-Reply-To: <20140912214004.GT6096@ivaldir.etoilebsd.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, 12 Sep 2014 22:02:06 -0000 The correct thing is to make a port/pkg that installs the symlink and /etc/shells this for the user. There is no need for changes to 'base' nor do we need a change to the system port. -Alfred On 9/12/14 2:40 PM, Baptiste Daroussin wrote: > On Fri, Sep 12, 2014 at 02:12:45PM -0700, Craig Rodrigues wrote: >> Hi, >> >> In the last 3 jobs that I have worked at, there have been >> a mix of Linux machines and FreeBSD machines. >> When using an NIS or LDAP environment where >> there is a single login across multiple machines, it is useful to >> have a single shell setting. >> >> Since Linux and MacOS X have "/bin/bash" as the shell, >> in order to get the FreeBSD boxes to play in this environment, >> I have seen admins do the following on FreeBSD setups: >> ln -s /usr/local/bin/bash /bin/bash >> >> or >> >> ln /usr/local/bin/bash /bin/bash >> >> and then make sure that /etc/shells as: >> /usr/local/bin/bash >> /bin/bash >> >> Can we add an optional knob (turned off by default) which creates this >> symlink >> and updates /etc/shells? >> >> This would help with interoperability of FreeBSD hosts in environments mixed >> with Linux and MacOS X. >> > Please no, no and no! > > We are fighting for a very long time to prevent the ports to pollute base. > > We have added the shebangfix USES to be able to catch with up with cleanup this > properly as well as a qa test to discover it automatically. > > no interpreters at all have a symlink in base but perl and this one is going to > be removed. > > If you want interoperability just use /usr/bin/env bash as a shebang. Btw you > cannot get interoprability with OS-X in there because the bash they do provide > is the last GPL-2 recent bash have many incompatiblities with this old version. > > regards, > Bapt From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:03:30 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 424FAA18; Fri, 12 Sep 2014 22:03:30 +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 CE6CDFBF; Fri, 12 Sep 2014 22:03:29 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8CM3QQa073130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 22:03:27 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1410559407; bh=iEhoIDZveAkvqrEFJgF/NjFgGQS6zPYdzXzt78x/KOA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iy2hLuxnvKNbFRkLHlBrzC24ElajLiis7VAXKvIyw4jZf+tsyeawt6+opfBmeFOf3 5vhNQwGGah2Bi5cUo4ZQg/nRzTTDgWQ6l/bRT+hW+Y0Gm5PGAuNTJfTYE8fadkN3pC B9w0+rAoQWUzAEHbErD51XTiVPpMiGXhCpyL3kBg= Date: Fri, 12 Sep 2014 22:03:26 +0000 (UTC) From: Marcin Cieslak To: John Baldwin Subject: Re: panic: resource_list_alloc: resource entry is busy In-Reply-To: <3819796.R7BYA2qqa8@ralph.baldwin.cx> Message-ID: References: <1584874.3FXdLuYUQI@ralph.baldwin.cx> <3819796.R7BYA2qqa8@ralph.baldwin.cx> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Fri, 12 Sep 2014 22:03:30 -0000 On Fri, 12 Sep 2014, John Baldwin wrote: >> Please note I originally loaded "i915.ko", not "i915kms.ko" > > Oh, that is probably your problem. X loaded i915kms automatically and > i915 and i915kms do not get along. i915 had already allocated the IRQ > when i915kms tried to alloc the same IRQ causing the issue. Would that be possible to fail with EBUSY or something instead of panic? //Marcin From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:05:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C834B38; Fri, 12 Sep 2014 22:05:01 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34850FD2; Fri, 12 Sep 2014 22:05:01 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so2162581pab.33 for ; Fri, 12 Sep 2014 15:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hBPKsbPicBvp3ABzZBz7E1fgjn1pTioW6TH2F3e4AAY=; b=GbShbqVEKx3mI7UbfkPIwZCXVKnA4mEH8JoKguKHKr9e/gyxhPxzQipcGD5fjmlJxU I/5AkWKguVUjjbHXFDX8eA3A9PpHZrhWqUwp8O7ku1/Q1tpwWzH5h9lyasG1NlQTvmkC gU/gOEFB2C5xzMsFp3DK00zVCWu3Vi5yhZyrJjyki3DpvtmSEBsyEMdZiVtJ3xRaKMgZ lCjdkjSvmtwle6DvaDsmgvHUPJVkIoFEBs2GUmnxy9VQDUONWLb/pl4yIb1T5vqQJ+Uy 5eKnUQsXQ/DBvg/MnzGlEm+d9EN8S06vHHuYVj0cqCFndpKzs8ZeW3iVwrpQO9w3J6Gc PBFA== X-Received: by 10.66.229.8 with SMTP id sm8mr16398179pac.66.1410559500826; Fri, 12 Sep 2014 15:05:00 -0700 (PDT) Received: from [192.168.242.58] (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id x3sm4854476pdq.10.2014.09.12.15.04.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 15:04:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4ACC29B3-CA98-44F9-96A0-C0404FC6ACC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Garrett Cooper In-Reply-To: Date: Fri, 12 Sep 2014 15:04:57 -0700 Message-Id: <756A4BFA-6BFB-4008-8B5E-85A2EBBBA1BD@gmail.com> References: <20140912214004.GT6096@ivaldir.etoilebsd.net> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1878.6) Cc: "Rang, Anton" , freebsd-current Current , ports 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, 12 Sep 2014 22:05:01 -0000 --Apple-Mail=_4ACC29B3-CA98-44F9-96A0-C0404FC6ACC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2014, at 14:53, Benjamin Kaduk wrote: > On Fri, 12 Sep 2014, Rang, Anton wrote: >=20 >>> If you want interoperability just use /usr/bin/env bash as a = shebang. >>=20 >> That doesn't work for this use case -- the user shell coming from = LDAP >> -- but I agree that the port shouldn't be modifying /usr/bin. >=20 > Here at MIT, where our Athena environment has a long history of = providing > a consistent experience across many different platforms, we ended up > limiting the login shells a user could select, to a whitelist we = provide > (/bin/sh, /usr/athena/bin/bash, and /usr/athena/bin/tcsh). (The = latter > two are now symlinks to the normal system shells, but they used to be > custom binaries.) >=20 > Some people did not like being so restricted, and set their login = shell to > /bin/sh, with logic in their dotfiles to re-exec a different shell > depending on the current runtime environment. +1 user rc files (not that it would fix this particular case...): - = https://github.com/yaneurabeya/scratch/blob/master/bayonetta/home/ngie/dot= .bashrc - = https://github.com/yaneurabeya/scratch/blob/master/bayonetta/home/ngie/dot= .shrc-local Cheers, -Garrett --Apple-Mail=_4ACC29B3-CA98-44F9-96A0-C0404FC6ACC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUE24JAAoJEMZr5QU6S73e8HEH/18lYVZ57uiTR2G7dc/09dlI Pvhma7ktGMRmH5mD6Mk6zCUPM9jwc7ju8HZ4Kt7falB41Nvzb/9uGcY4SmwVJfXt h1491edCcpk0r51W/v5vEFGzYAlQ/LbLfZVTOQzelbJap+ktOKIQW7NxXZW9Ducs OdNzKpSJ5/Px1iP5PpgCC85Upcn7MARORJfmPGJnavPz7ltn0fszG1KJghWDqT+S TzoogdZPfAUtGtq3v7fpRivhlAWTaOL7lFm/Vo3ENmApEpLMGSl065SEppFxK+pJ L6IaWlPYe88YELWl3T/YQDo1FkQSyjEWN1XWvNXeTuZiWC0ynMu2L5i1CFJU6cU= =yJPB -----END PGP SIGNATURE----- --Apple-Mail=_4ACC29B3-CA98-44F9-96A0-C0404FC6ACC1-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:16:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B63BECE; Fri, 12 Sep 2014 22:16:32 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2975164; Fri, 12 Sep 2014 22:16:31 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id s8CM5WA6021315; Fri, 12 Sep 2014 18:05:32 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Fri, 12 Sep 2014 18:05:33 -0400 (EDT) Date: Fri, 12 Sep 2014 18:05:32 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: "Rang, Anton" Subject: RE: shells/bash port, add a knob which symlinks to /bin/bash ? In-Reply-To: Message-ID: References: <20140912214004.GT6096@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , Emanuel Haupt , ports 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, 12 Sep 2014 22:16:32 -0000 On Fri, 12 Sep 2014, Rang, Anton wrote: >> If you want interoperability just use /usr/bin/env bash as a shebang. > > That doesn't work for this use case -- the user shell coming from LDAP > -- but I agree that the port shouldn't be modifying /usr/bin. > > It's easy enough to add the symlink manually after installing the port > if you're in this situation, or there may be a way to configure the > LDAP module to map /bin/bash to /usr/local/bin/bash (I haven't looked > to see what is supported here). We have used LDAP on Solaris for years, and have mixed environments of Solaris, Linux, and FreeBSD. We use /usr/local/bin/bash in LDAP for shells, then either link that to the system /bin/bash or install more up-to-date bash in /usr/local/bin. This way you can always install a more up-to-date shell in /usr/local/bin without changing the base OS - you don't want base OS shell scripts to break by updating to a newer shell. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:22:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8196346D; Fri, 12 Sep 2014 22:22:46 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "orthanc.ca CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4621423E; Fri, 12 Sep 2014 22:22:46 +0000 (UTC) Received: from [192.168.42.6] (d66-183-211-183.bchsia.telus.net [66.183.211.183]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s8CMMgew096499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Sep 2014 15:22:44 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_AAB70746-F659-4E2E-962D-1C413044639C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Lyndon Nerenberg In-Reply-To: <20140912214004.GT6096@ivaldir.etoilebsd.net> Date: Fri, 12 Sep 2014 15:22:15 -0700 Message-Id: References: <20140912214004.GT6096@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1878.6) X-Spam-Status: No, score=0.4 required=5.0 tests=RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on orthanc.ca Cc: freebsd-current Current , ports 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, 12 Sep 2014 22:22:46 -0000 --Apple-Mail=_AAB70746-F659-4E2E-962D-1C413044639C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2014, at 2:40 PM, Baptiste Daroussin = wrote: > If you want interoperability just use /usr/bin/env bash as a shebang. = Btw you > cannot get interoprability with OS-X in there because the bash they do = provide > is the last GPL-2 recent bash have many incompatiblities with this old = version. The concern is not with shell scripts, it's with the contents of the = pw_shell field in 'struct passwd'. I run into this all the time, too, but with ksh. In my case I just cp a = static-linked version of whatever ksh variant I happened to build into = /bin/ksh and call it a day. It's not like the shell source code is = changing every other week, even for bash. --lyndon --Apple-Mail=_AAB70746-F659-4E2E-962D-1C413044639C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUE3IXAAoJEG8PnXiV/JnUZNMP/i/GYWZ7FBE1VxkQFeglQXKB Zws/F7N4o/6Y3p+z0Xrj5TjYy6V0p8b4Vr2VGTIO7lhq5gwYXSddKcUZuLe6rPU3 vNkRmzN9w5qYhpHQs99MbhX2P1AkSB60pvN2RZT5huoBk3B1a4/WJBFf7+oB6KIR HmrpUcmEW1NS3x6dOQjPt68IRtbQSg/n6LLu3x+Fxh2ah3XmFFhqn/0TrR6GAiHL Od5X+k9wlo8zGw2r0NXT/64NrjzAoikjHooEoi2wxH0+1b8nQ2vu+Db0TWeersOp TYTkcu3u0um+Fv4+33qyFN7QIu3U4TMsC98zcXd8nQt/d0eKc/fb+MTQhQAJYsbA /ujDzF9EtsXb0i6w8L9Ns0MfgPc4O+u281yOCIwKUXd4vTwncsoSaFXcS5CCAyBz NuPCamHtS6LubtTFivbHMsR79ajnEQdHBP+dwDuO5tzDeEVYU+c+6sCUz4LMaqyx cSf++x4ZnfbAtPL9MmUgN2Y05+wxflYMbqlSsJhzfdaH7g8H4au2Vw+gqR4Gof0k ONRfJNt/ZbdzriJlTn6+6ajLmnj/SWj5wkhH679KXSf/TS5x0DjopBDVH5jBjOlp SS29fD2EutOojQWttUMv8hQfw76P9sh/FqdrPr46yM7vtcvEPMaUceMyXKkIqU1D 7u77zXxlRgiYzS6h7R0K =yPAg -----END PGP SIGNATURE----- --Apple-Mail=_AAB70746-F659-4E2E-962D-1C413044639C-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:23:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0BE0668E for ; Fri, 12 Sep 2014 22:23:38 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74DAD255 for ; Fri, 12 Sep 2014 22:23:37 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id l4so1688033lbv.8 for ; Fri, 12 Sep 2014 15:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dBIPDfvmCr36+kp3XdX7YpTA17D75RgyJOHgVx9ZtO0=; b=pTwNSZ4crxQxMENn/I1ZagWYh4zHBAqtwMw4YRIdlR2ffNyxAzZ3PU7LT7dTL1m9Jr O8z1KSGp/35wcP7YAqVcneWMy3bOMDAUaxc1vrhCSSGQHLzJ0qYa3mr6K3cLPZ5b+D0s R3bIZBrZXyl7O9ugFBYihGARVPUZrkjUGEE5gW0wICcF/507wZbgdbuJzajrHrrzqIlC llai62eOkuv7nXpiP2iDEU8FdQFKu33rRlbjm9mj1cVnz317yZMRUMLC2I0RRCypskwX OHKbw3mjkHcPvDCszvQhFDLa5KTZiXoIm9Q3Ifyvl7SHf1NHbVtESmlHd6FzsmO309bA sK9w== MIME-Version: 1.0 X-Received: by 10.152.115.195 with SMTP id jq3mr6540984lab.90.1410560615373; Fri, 12 Sep 2014 15:23:35 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Fri, 12 Sep 2014 15:23:35 -0700 (PDT) In-Reply-To: <54136D5D.3090905@mu.org> References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> Date: Fri, 12 Sep 2014 15:23:35 -0700 X-Google-Sender-Auth: 5stqe1x8tOxcHQPlbM_iNBF_wII Message-ID: Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Craig Rodrigues To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: 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: Fri, 12 Sep 2014 22:23:38 -0000 Hi, I could live with this solution of additional port outside of the main bash port, which creates the symlink and updates /etc/shells. One other thing I am seeing is that many, many shell scripts are written assuming "#!/bin/bash". Forcing all upstream script writers to switch to "#!/usr/bin/env bash", or to convert their scripts to "#!/bin/sh" and remove all bash-specific behaviors, is getting harder and harder, since many people are exposed to MacOS X and Linux on desktops. -- Craig On Fri, Sep 12, 2014 at 3:02 PM, Alfred Perlstein wrote: > The correct thing is to make a port/pkg that installs the symlink and > /etc/shells this for the user. > > There is no need for changes to 'base' nor do we need a change to the > system port. > > -Alfred > > > On 9/12/14 2:40 PM, Baptiste Daroussin wrote: > >> On Fri, Sep 12, 2014 at 02:12:45PM -0700, Craig Rodrigues wrote: >> >>> Hi, >>> >>> In the last 3 jobs that I have worked at, there have been >>> a mix of Linux machines and FreeBSD machines. >>> When using an NIS or LDAP environment where >>> there is a single login across multiple machines, it is useful to >>> have a single shell setting. >>> >>> Since Linux and MacOS X have "/bin/bash" as the shell, >>> in order to get the FreeBSD boxes to play in this environment, >>> I have seen admins do the following on FreeBSD setups: >>> ln -s /usr/local/bin/bash /bin/bash >>> >>> or >>> >>> ln /usr/local/bin/bash /bin/bash >>> >>> and then make sure that /etc/shells as: >>> /usr/local/bin/bash >>> /bin/bash >>> >>> Can we add an optional knob (turned off by default) which creates this >>> symlink >>> and updates /etc/shells? >>> >>> This would help with interoperability of FreeBSD hosts in environments >>> mixed >>> with Linux and MacOS X. >>> >>> Please no, no and no! >> >> We are fighting for a very long time to prevent the ports to pollute base. >> >> We have added the shebangfix USES to be able to catch with up with >> cleanup this >> properly as well as a qa test to discover it automatically. >> >> no interpreters at all have a symlink in base but perl and this one is >> going to >> be removed. >> >> If you want interoperability just use /usr/bin/env bash as a shebang. Btw >> you >> cannot get interoprability with OS-X in there because the bash they do >> provide >> is the last GPL-2 recent bash have many incompatiblities with this old >> version. >> >> regards, >> Bapt >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:33:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F08E3895; Fri, 12 Sep 2014 22:33:58 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2D3535F; Fri, 12 Sep 2014 22:33:58 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id rd3so2175151pab.26 for ; Fri, 12 Sep 2014 15:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3j/ExDiEZlAlQS1DPQjSKqHm5XSm0kaOUVpA2ovzMeU=; b=gpdL4taI7uIPkJzSMsom9bIMC7bSxdcYJqdv7UntSFv87oAQ4pGA73ttqwJ9S9PZsZ gPKiMl3TcMxhLVU6IH8LI5yS7LDgUjQAHa2zfrsLmwLjwgrdnhPQeORFtMvp4zsX8im3 9tqItWWwT4/FGPuaYgnoTuefqRHOd0rLECp6GK8z0OcOC4q0v7P1mjdhV0lEKwkxDDZ1 0TGycQoXsV5HA9+awXKU26PHTuai229TEXuf8FB999Gmvcz5r0lkF3O8VAi/2JSJF/nQ mOC7zAm+pfDjDNP++sV7Gb9KzdDvcfBdhPF2Baih5FXtdwYj0wAtLi0brdO/7VERr50N iw+A== MIME-Version: 1.0 X-Received: by 10.68.197.65 with SMTP id is1mr16501630pbc.125.1410561238138; Fri, 12 Sep 2014 15:33:58 -0700 (PDT) Received: by 10.70.88.7 with HTTP; Fri, 12 Sep 2014 15:33:58 -0700 (PDT) In-Reply-To: References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> Date: Sat, 13 Sep 2014 02:33:58 +0400 Message-ID: Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Subbsd To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: Alfred Perlstein , 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: Fri, 12 Sep 2014 22:33:59 -0000 On Sat, Sep 13, 2014 at 2:23 AM, Craig Rodrigues wrote: > Hi, > > I could live with this solution of additional port outside of the main > bash port, which creates the symlink and updates /etc/shells. > > One other thing I am seeing is that many, many shell scripts are written > assuming "#!/bin/bash". > Forcing all upstream script writers to switch to "#!/usr/bin/env bash", or > to convert their scripts to "#!/bin/sh" and remove all bash-specific > behaviors, is getting harder and harder, > since many people are exposed to MacOS X and Linux on desktops. > > -- > Craig > > > > On Fri, Sep 12, 2014 at 3:02 PM, Alfred Perlstein wrote: > >> The correct thing is to make a port/pkg that installs the symlink and >> /etc/shells this for the user. >> >> There is no need for changes to 'base' nor do we need a change to the >> system port. >> >> -Alfred >> >> >> On 9/12/14 2:40 PM, Baptiste Daroussin wrote: >> >>> On Fri, Sep 12, 2014 at 02:12:45PM -0700, Craig Rodrigues wrote: >>> >>>> Hi, >>>> >>>> In the last 3 jobs that I have worked at, there have been >>>> a mix of Linux machines and FreeBSD machines. >>>> When using an NIS or LDAP environment where >>>> there is a single login across multiple machines, it is useful to >>>> have a single shell setting. >>>> >>>> Since Linux and MacOS X have "/bin/bash" as the shell, >>>> in order to get the FreeBSD boxes to play in this environment, >>>> I have seen admins do the following on FreeBSD setups: >>>> ln -s /usr/local/bin/bash /bin/bash >>>> >>>> or >>>> >>>> ln /usr/local/bin/bash /bin/bash >>>> >>>> and then make sure that /etc/shells as: >>>> /usr/local/bin/bash >>>> /bin/bash >>>> >>>> Can we add an optional knob (turned off by default) which creates this >>>> symlink >>>> and updates /etc/shells? >>>> >>>> This would help with interoperability of FreeBSD hosts in environments >>>> mixed >>>> with Linux and MacOS X. >>>> >>>> Please no, no and no! >>> >>> We are fighting for a very long time to prevent the ports to pollute base. >>> >>> We have added the shebangfix USES to be able to catch with up with >>> cleanup this >>> properly as well as a qa test to discover it automatically. >>> >>> no interpreters at all have a symlink in base but perl and this one is >>> going to >>> be removed. >>> >>> If you want interoperability just use /usr/bin/env bash as a shebang. Btw >>> you >>> cannot get interoprability with OS-X in there because the bash they do >>> provide >>> is the last GPL-2 recent bash have many incompatiblities with this old >>> version. >>> >>> regards, >>> Bapt >>> >> Looks like variant symlink is may be useful for solving this problem and it is not cluttered base https://wiki.freebsd.org/200808DevSummit?action=AttachFile&do=get&target=variant-symlinks-for-freebsd.pdf From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:46:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03B3C210; Fri, 12 Sep 2014 22:46:06 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id CED5B662; Fri, 12 Sep 2014 22:46:05 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 004005A9F0C; Fri, 12 Sep 2014 22:45:58 +0000 (UTC) Date: Fri, 12 Sep 2014 22:45:58 +0000 From: Brooks Davis To: Subbsd Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? Message-ID: <20140912224558.GA47936@spindle.one-eyed-alien.net> References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Craig Rodrigues , Alfred Perlstein , 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: Fri, 12 Sep 2014 22:46:06 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 13, 2014 at 02:33:58AM +0400, Subbsd wrote: > On Sat, Sep 13, 2014 at 2:23 AM, Craig Rodrigues wr= ote: > > Hi, > > > > I could live with this solution of additional port outside of the main > > bash port, which creates the symlink and updates /etc/shells. This is the approach I took at my previous employer. It's simple, works with packages, and people who hate adding things to /bin can avoid doing so. > Looks like variant symlink is may be useful for solving this problem > and it is not cluttered base >=20 > https://wiki.freebsd.org/200808DevSummit?action=3DAttachFile&do=3Dget&tar= get=3Dvariant-symlinks-for-freebsd.pdf As the person who ported variant symlinks to FreeBSD I can't image how they could be useful here. If you need a /bin/bash you need to put a file system object there (or I supposed hack namei). Variant symlinks only allow files to point to different things in different contexts. -- Brooks --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQTd6YACgkQXY6L6fI4GtQfYACeM/E2eEUEYlqdhW0GDEoL5UUX n0YAn3zeJ1ev4f6wsvUJv8jYb/VusYMp =DN3Y -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:46:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6CC632C; Fri, 12 Sep 2014 22:46:19 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "orthanc.ca CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B919669; Fri, 12 Sep 2014 22:46:19 +0000 (UTC) Received: from minnie.bitsea.ca (minnie.bitsea.ca [IPv6:2604:8800:137::7]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s8CMkEcO096855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Sep 2014 15:46:17 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_EC9F16AD-DF52-44F1-9EAE-AD8724093D3D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Lyndon Nerenberg In-Reply-To: Date: Fri, 12 Sep 2014 15:45:47 -0700 Message-Id: <3A3F0052-5F35-4381-93E3-EAAE0616D292@orthanc.ca> References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on orthanc.ca Cc: 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: Fri, 12 Sep 2014 22:46:19 -0000 --Apple-Mail=_EC9F16AD-DF52-44F1-9EAE-AD8724093D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2014, at 3:23 PM, Craig Rodrigues = wrote: > Forcing all upstream script writers to switch to "#!/usr/bin/env = bash", or > to convert their scripts to "#!/bin/sh" and remove all bash-specific > behaviors, is getting harder and harder, > since many people are exposed to MacOS X and Linux on desktops. Given the rigid nature of shebangs to begin with, it's really not that = hard to write a sed command that will capture all instances of = '#!.../bash[ foo]' and wire in an appropriate value of '...'. In fact, this case is a ripe candidate for a command = macro. --lyndon --Apple-Mail=_EC9F16AD-DF52-44F1-9EAE-AD8724093D3D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUE3ebAAoJEG8PnXiV/JnU17IQAKBXXGx1Nvp2hjEgjggNnuBh BlpfkVLWAl2WPpxAYlwOiC20OGitLPw+8uaj66o0a6kPr4+huQoo0/Slm7vjixiA 1bvUfrJhUO2av7X1GrI5b8cZVYVSQFOk4eG5pzscnCic/Oj15BlJ+gLOUosV1YH7 1QB8U2x+efZmb5gu3prQ0f8mn3T4Nl1cwf54oEiGSM9rUsCw0Dy2LF8Lq5dek4ig OswVHsGbXXsTTvwgOwdsJhU8KAYUxC9t9rQR+127Ky/VWGDp27yyuzlqD2weUzuQ W2FcWwBGZeDQPcadrLaK2MJ8hJ0cYDcQr6M/AF8AC19u5iiyD2dExJArKg7gLIoW 0LiApsILyztA+inY3FU9ydHjoOsOJw2wP2+tyCJ90+/6KzOpcGYC59O5qAqDI7KE qH2KAS08/yOVESkSvrPwOKen8Q4Hmch/t/ZcwxW263gYgqr8K0CpgbidNE5CREZA ODn4XM1EMFeNwPgDN+Ts5s+/WnVVVfE4juCQRCTQJ3dJnKwtR6mv2fIQ62WNZlTs kG+qjAdwX5H8dUAOmxXPEVPnUhwSEbWdeaTsjACuvUQbHD8JGQAIOPFcxWKIu1m4 //Sq/W4vhim9WrF2ETdKty2wzfVKzqES4mpCmAThrxAorvsAjthbDiF3iqDQdvPt ikYGgIsLhltkvljUz2Y5 =Q7Sg -----END PGP SIGNATURE----- --Apple-Mail=_EC9F16AD-DF52-44F1-9EAE-AD8724093D3D-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:55:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3809C682 for ; Fri, 12 Sep 2014 22:55:58 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F13B17A5 for ; Fri, 12 Sep 2014 22:55:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8CMtvM3084262 for ; Fri, 12 Sep 2014 22:55:57 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8CMtvmY084261 for freebsd-current@freebsd.org; Fri, 12 Sep 2014 22:55:57 GMT (envelope-from bdrewery) Received: (qmail 7493 invoked from network); 12 Sep 2014 17:55:53 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 12 Sep 2014 17:55:53 -0500 Message-ID: <541379F0.6030002@FreeBSD.org> Date: Fri, 12 Sep 2014 17:55:44 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Lyndon Nerenberg , Craig Rodrigues Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> <3A3F0052-5F35-4381-93E3-EAAE0616D292@orthanc.ca> In-Reply-To: <3A3F0052-5F35-4381-93E3-EAAE0616D292@orthanc.ca> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Mb27xDxPbDQjsBGpfFi4BgatDv9HD7utL" Cc: 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: Fri, 12 Sep 2014 22:55:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mb27xDxPbDQjsBGpfFi4BgatDv9HD7utL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/12/2014 5:45 PM, Lyndon Nerenberg wrote: >=20 > On Sep 12, 2014, at 3:23 PM, Craig Rodrigues wrot= e: >=20 >> Forcing all upstream script writers to switch to "#!/usr/bin/env bash"= , or >> to convert their scripts to "#!/bin/sh" and remove all bash-specific >> behaviors, is getting harder and harder, >> since many people are exposed to MacOS X and Linux on desktops. >=20 > Given the rigid nature of shebangs to begin with, it's really not that = hard to write a sed command that will capture all instances of '#!.../bas= h[ foo]' and wire in an appropriate value of '...'. >=20 > In fact, this case is a ripe candidate for a command macr= o. >=20 > --lyndon >=20 There already is one and ports requires using it! --=20 Regards, Bryan Drewery --Mb27xDxPbDQjsBGpfFi4BgatDv9HD7utL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUE3nwAAoJEDXXcbtuRpfPBJYIANKTM/ThK1u9fXo3t1XiJU9I ItU+Mag38mTFTtne1IA92XrRn+36RyKD4nB3oqI+yYfOIVqjrn7PKh9f5KoPaBWJ Ws5yZCPCWVKhkz0K7zbEcohTfa5GvAlmm0YsgFp9ODQpe5EuN7e24tRYepCqkFsS dx7V3GCQz86rWDkQziiyQZkI3TEmoipyyMeOCDPNDyEQscYnOTE5K6WjWKvyS4Hr DnDEUXqKZVac55jOXfvCxPrfEc1LCAYG7MvHZop65cCNB6KjoYA4eVOg8QxlXSGd M/P5Tto0WaCZRtP2FVu+w0Jd+jd/ocx4xlXigl3gGP1qAqb/LaXa2xQxzrDUSTg= =Gqp+ -----END PGP SIGNATURE----- --Mb27xDxPbDQjsBGpfFi4BgatDv9HD7utL-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 22:58:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55A187C5; Fri, 12 Sep 2014 22:58:16 +0000 (UTC) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "orthanc.ca CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 328A37C2; Fri, 12 Sep 2014 22:58:16 +0000 (UTC) Received: from minnie.bitsea.ca (minnie.bitsea.ca [IPv6:2604:8800:137::7]) (authenticated bits=0) by orthanc.ca (8.14.7/8.14.7) with ESMTP id s8CMwBdh097034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Sep 2014 15:58:14 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: multipart/signed; boundary="Apple-Mail=_855F2E33-2589-4B5E-9465-02D02BDAA363"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Lyndon Nerenberg In-Reply-To: <541379F0.6030002@FreeBSD.org> Date: Fri, 12 Sep 2014 15:57:43 -0700 Message-Id: References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> <3A3F0052-5F35-4381-93E3-EAAE0616D292@orthanc.ca> <541379F0.6030002@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.1878.6) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on orthanc.ca Cc: 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: Fri, 12 Sep 2014 22:58:16 -0000 --Apple-Mail=_855F2E33-2589-4B5E-9465-02D02BDAA363 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On Sep 12, 2014, at 3:55 PM, Bryan Drewery wrote: > There already is one and ports requires using it! Doh! --Apple-Mail=_855F2E33-2589-4B5E-9465-02D02BDAA363 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJUE3poAAoJEG8PnXiV/JnUDvIP/2SPsbihATLEmYKnyU6Nk9KF J/vUtzZZ7/zUxyG2vWkAOlPT7w2NlLqfdowcibGDohC8xpYdyD1oadR0Nvt9gt3b ISMV+L3Zn2w4/jfFAwt5uTr6dZxWNLJtOaYGMvlW8tVsZObLF+PbeooIfuWKw+qj n173GiLtmouHxJnP4kxhd6UKLe82ecRxYwDvdJfLW5dHjrUOX8T0riD9XcWthClk 2TKD5CxvbfBWdPSn2J49b+vU6GWjN1d9024dW7KnKM7Kwdes3zeSVNm8OeiTh2GM hmOyT9PwRqfxruQTCQSApRTsyxSPqrHWGz1HdrD/qTqFPjSXEaqR1rCbA+IJrile AwDrrYfa8AlJLgGX3gwIUfDc+oC7Ga5SskgvE4n7GiFUw+qCkul+Xy88ezzn9dU+ NKuaDjhIlwNAM1VsRaMyEogyEDnfOhZlWooULk3e7HirAzEeI5RPUvhdhhv/Mm0E K22x44kKQb0OAoD5u7qgBGZlbQXDbWzxWSRaZthQT5h3Xx7FVA7/DoYLBlT2Y8UL cIbgKVyFCF+YUqpXYpGlM6F09KlQ6TYfG5nMaK20nMZSgMYOhTMdAZ6vtOiu12t2 Mv76jMMwYQWJGt+ZdMu0BbrXMbKDkfwwmfG8wfanPatoBQbJfRn3yUKQDJK+h8ef YJ9ckErLXjeVPQaXS4sQ =tD10 -----END PGP SIGNATURE----- --Apple-Mail=_855F2E33-2589-4B5E-9465-02D02BDAA363-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 12 23:06:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09CABA69; Fri, 12 Sep 2014 23:06:50 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E91E9893; Fri, 12 Sep 2014 23:06:49 +0000 (UTC) Received: from u10-2-16-021.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 99B35346DE07; Fri, 12 Sep 2014 16:06:49 -0700 (PDT) Message-ID: <54137C8D.9020506@mu.org> Date: Fri, 12 Sep 2014 16:06:53 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <20140912214004.GT6096@ivaldir.etoilebsd.net> <54136D5D.3090905@mu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Fri, 12 Sep 2014 23:06:50 -0000 On 9/12/14 3:23 PM, Craig Rodrigues wrote: > Hi, > > I could live with this solution of additional port outside of the main > bash port, which creates the symlink and updates /etc/shells. > > One other thing I am seeing is that many, many shell scripts are > written assuming "#!/bin/bash". > Forcing all upstream script writers to switch to "#!/usr/bin/env bash", or > to convert their scripts to "#!/bin/sh" and remove all bash-specific > behaviors, is getting harder and harder, > since many people are exposed to MacOS X and Linux on desktops. > Lol, or we could hack the image activator. :) -Alfred From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 02:57:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCC16B94; Sat, 13 Sep 2014 02:57:13 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D568C80; Sat, 13 Sep 2014 02:57:13 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id a13so1540912igq.11 for ; Fri, 12 Sep 2014 19:57:12 -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=jZw6uz/F1E0AHsJCesPwp0/q2PzyQpuyjBe2os60n0Y=; b=rtf4Gt5vSzk6mdmvkztQnyfp5T29UGXCZVTUPtN3z4L+K5kRxmO5Ziffmf+DteuUAy VNYMPKKh0+DM60w2CYAytsoLlWhJ1msQHhpPmbzjtwug0XTAtWftwP1DY52RBsXbQbUO sBGKkPD5IWnZzZC36ahaq893r1uKL7Z4tuR2y7lwY5i+zy9jMro/npehEhLnYhJJ+xri 9EUsciixUoDk3O4G7EaVY1p0/qY8rfe2XojPa4h0vwXKlQ20lQvgD1b09coa2YjT3Cp5 I9YGQGjY4hD2gLy8bCdLjZPPnAH8QrpJ9pgf5f/cgznWx/7o1c/GP8lpP19faxcCh13A eNew== MIME-Version: 1.0 X-Received: by 10.50.79.232 with SMTP id m8mr7014448igx.0.1410577032873; Fri, 12 Sep 2014 19:57:12 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.148 with HTTP; Fri, 12 Sep 2014 19:57:12 -0700 (PDT) In-Reply-To: References: <1749648.0eHaTPXHUy@ralph.baldwin.cx> <1584874.3FXdLuYUQI@ralph.baldwin.cx> Date: Fri, 12 Sep 2014 19:57:12 -0700 X-Google-Sender-Auth: AiLGjEgADHtU7VgHQ6UWPjYC4oE Message-ID: Subject: Re: panic: resource_list_alloc: resource entry is busy From: Kevin Oberman To: Marcin Cieslak Content-Type: text/plain; charset=UTF-8 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: Sat, 13 Sep 2014 02:57:14 -0000 On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak wrote: > > > On Fri, 12 Sep 2014, John Baldwin wrote: > > at /usr/src/sys/dev/pci/vga_pci.c:318 >>> 318 return (bus_alloc_resource(dev, type, rid, start, end, >>> count, >>> >> flags)); >> >>> Current language: auto; currently minimal >>> (kgdb) p *rid >>> $1 = 0 >>> >> >> Hmm, type 1 is SYS_RES_IRQ. IRQ resources should not be marked reserved. >> >> Oh, some other child of vgapci has already allocated the IRQ. That seems >> odd. >> >> Can you get 'devinfo -r' output before you kldload i915kms and again after >> doing the kldload? (No need to run startx) >> > > Please note I originally loaded "i915.ko", not "i915kms.ko" > > > Unfortunately, "kldunload i915kms" makes my screen blank > and probably crashes the system (disk activity stops after > a short while and there is no response to the keyboard input). > > //Marcin > > That explains most of it. You need i915kms. It is conflicting with i915 which already has the IRQ allocated. The black screen is expected. Once KMS starts talking to the graphics system, syscons can no longer talk to the display, so you get a black screen. To have a working display, you must enable vt(4). Add "kern.vty=vt" to /boot/loader.conf to enable vt(4) which will keep the display alive. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 04:30:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A04AACCD; Sat, 13 Sep 2014 04:30:03 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BDE0806; Sat, 13 Sep 2014 04:30:03 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 6DECFE2F; Fri, 12 Sep 2014 21:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410582602; bh=F0cnKa2PuTWehaPeQ7WoVSrcydAoXu3qysvrmbieoNo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SAiY57UxBMalJzLsIJfGubr8CqAqGkZzQG7EbIMOh9P7mI/3lXBMsBRwETU81A4zo hwfL2B48XaP3Q/5RRoiYxImaDh0MEClhDC3SVJaYsxVcb+JY3AXH7iIpAVhBAu0Kg5 3hZg+J7aXwqmv3szT1mcy8e+jKbYgNM5p7Nf8TFg= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient Date: Fri, 12 Sep 2014 21:29:56 -0700 Message-ID: <4252906.DAHIEnKpIF@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <540FF706.2050400@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2842358.8oZ6Muxc0B"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Patrick Kelsey , George Neville-Neil 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, 13 Sep 2014 04:30:03 -0000 --nextPart2842358.8oZ6Muxc0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wr= ote: > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > I don't think it is worth the trouble, as given the larger patter= n of > > > libc routines requiring multiple capsicum rights, it seems one wi= ll in > > > general have to have libc implementation knowledge when using it = in > > > concert with capsicum. For example, consider the limitfd() routi= ne in > > > kdump.c, which provides rights for the TIOCGETA ioctl to be used = on > > > stdout so the eventual call to isatty() via printf() will work as= > >=20 > > intended. > >=20 > > > I think the above kdump example is a good one for the subtle issu= es that > > > can arise when using capsicum with libc. That call to isatty() i= s via a > > > widely-used internal libc routine __smakebuf(). __smakebuf() als= o calls > > > __swhatbuf(), which in turn calls _fstat(), all to make sure that= output > > > to a tty is line buffered by default. It would appear that progr= ams > > > that restrict rights on stdout without allowing CAP_IOCTL and CAP= _FSTAT > > > could be disabling the normally default line buffering when stdou= t is a > > > tty. kdump goes the distance, but dhclient does not (restricting= stdout > > > to CAP_WRITE only). > > >=20 > > > In any event, the patch attached to my first message is seeming l= ike the > > > way to go. > >=20 > > Well, then commit it (if capsicum team agrees). >=20 > Will do - thanks for the feedback. >=20 > -Patrick Is there any possibility that this is related to the problem we've rece= ntly=20 hit in the freebsd.org cluster with this month's refresh? After running for a while: Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator= Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch retu= rned=20 error -1, errno is Capabilities insufficient Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully= last=20 time (65258) Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator= Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch retu= rned=20 error -1, errno is Capabilities insufficient Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully= last=20 time (28213) Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator= Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch retu= rned=20 error -1, errno is Capabilities insufficient I believe this jail was started from the boot process. If I restart the= jail=20 by hand from a ssh session the problem goes away. This is unbound from ports and I don't have any more details than this.= This=20 is new this month. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2842358.8oZ6Muxc0B 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 iQEcBAABAgAGBQJUE8hJAAoJEDXWlwnsgJ4En5oH/3eQm+QHBJCffu3igIvxpIiX sWVfDoAvJ8XQNeY7rkE+EE8XOT4TeV/XZtJWfSQCir57x7P+SCLQgiMXc46gsuvg XDU3F+1Cb3P+y7jVx/vcuQZIo/42j8TiWZk5YVVHB+YkxP28wypUYIbZdCH/duCy nFm2zcH4bQHaYAp359jj1JhE1MkLUy4B9sg0reHJzuzzJ37+HBmZFds71cMXvShe LtRZBS06f9HPOuVO1+xNOPAHq5roVLT2str2qeS6rvW9LX9ZXeoqHWkzR2uXv6rj 7hGuUI1UL4HCLiylBHlqat0DHJMYBFlaGaY5Aps6waTon93HcXiS1wK4rHMGAPk= =xQCX -----END PGP SIGNATURE----- --nextPart2842358.8oZ6Muxc0B-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 07:04:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA1B63C6 for ; Sat, 13 Sep 2014 07:04:58 +0000 (UTC) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0671.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::671]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468BC670 for ; Sat, 13 Sep 2014 07:04:58 +0000 (UTC) Received: from DB4PR04MB0608.eurprd04.prod.outlook.com (10.242.195.156) by DB4PR04MB0605.eurprd04.prod.outlook.com (10.242.195.153) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 13 Sep 2014 07:04:32 +0000 Received: from DB4PR04MB0608.eurprd04.prod.outlook.com ([10.242.195.156]) by DB4PR04MB0608.eurprd04.prod.outlook.com ([10.242.195.156]) with mapi id 15.00.1024.012; Sat, 13 Sep 2014 07:04:32 +0000 From: jon.ruse To: "" Subject: Re: GNU LICENSING Thread-Topic: GNU LICENSING Thread-Index: AQHPzyD3bbOpZJzxH0y64WSlMAtoyg== Date: Sat, 13 Sep 2014 07:04:32 +0000 Message-ID: <88FF098E-0351-4D16-BEAB-60FA1219F3BF@thegarbagefile.org> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [82.132.239.200] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03333C607F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(27574002)(24454002)(189002)(54356999)(50986999)(76176999)(46102001)(4396001)(99396002)(90102001)(110136001)(101416001)(105586002)(21056001)(87936001)(106356001)(83322001)(77982001)(97736003)(64706001)(76482001)(85306004)(19580405001)(106116001)(74502001)(31966008)(20776003)(95666004)(19580395003)(74662001)(107886001)(33656002)(107046002)(85852003)(83072002)(79102001)(82746002)(83716003)(66066001)(2656002)(80022001)(81542001)(15202345003)(92566001)(86362001)(221733001)(92726001)(15975445006)(81342001)(36756003)(104396001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB0605; H:DB4PR04MB0608.eurprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: thegarbagefile.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, 13 Sep 2014 07:04:58 -0000 Hi I was wondering how to apply to the gnu licensing and how to sign and commi= t to the licensing laws.. Would you mind telling me how to assign to one pl= ease?? And one other thing in the license of most gnu licensing they go on = to mention the 'AS IS' commitment but I don't fully understand, as well cou= ld you give me five minutes of you busy time to explain please??=20 My regards MR jon ruse I do donate to the fsf donation station if that is anything meaning?? Sent from my iPhone > On 12 Sep 2014, at 23:46, "freebsd-current-request@freebsd.org" wrote: >=20 > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org >=20 > You can reach the person managing the list at > freebsd-current-owner@freebsd.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > Today's Topics: >=20 > 1. Re: CDC-WDM driver (4G modems) (PseudoCylon) > 2. Re: panic: resource_list_alloc: resource entry is busy > (Marcin Cieslak) > 3. Re: panic: resource_list_alloc: resource entry is busy > (John Baldwin) > 4. Re: panic: resource_list_alloc: resource entry is busy > (Marcin Cieslak) > 5. shells/bash port, add a knob which symlinks to /bin/bash ? > (Craig Rodrigues) > 6. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Bryan Drewery) > 7. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Baptiste Daroussin) > 8. RE: shells/bash port, add a knob which symlinks to /bin/bash > ? (Rang, Anton) > 9. RE: shells/bash port, add a knob which symlinks to /bin/bash > ? (Benjamin Kaduk) > 10. Re: panic: resource_list_alloc: resource entry is busy > (John Baldwin) > 11. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Alfred Perlstein) > 12. Re: panic: resource_list_alloc: resource entry is busy > (Marcin Cieslak) > 13. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Garrett Cooper) > 14. RE: shells/bash port, add a knob which symlinks to /bin/bash > ? (Daniel Eischen) > 15. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Lyndon Nerenberg) > 16. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Craig Rodrigues) > 17. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Subbsd) > 18. Re: shells/bash port, add a knob which symlinks to /bin/bash > ? (Brooks Davis) > > > > > > > > > > > > > > > > > > > _______________________________________________ > 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 Sep 13 07:41:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A414AE3; Sat, 13 Sep 2014 07:41:48 +0000 (UTC) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3917F999; Sat, 13 Sep 2014 07:41:48 +0000 (UTC) Received: from fwd41.aul.t-online.de (fwd41.aul.t-online.de [172.20.27.139]) by mailout07.t-online.de (Postfix) with SMTP id C7F952918E1; Sat, 13 Sep 2014 09:41:38 +0200 (CEST) Received: from [192.168.119.33] (VmYRHwZeQh9KN4Cb4Xp1A0FJ7JTqgL2rRc2jWQWYei5J3fpajWp5-di26zHgC63wGM@[84.154.101.219]) by fwd41.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1XShxi-2R2WXY0; Sat, 13 Sep 2014 09:41:38 +0200 Message-ID: <5413F526.2070207@freebsd.org> Date: Sat, 13 Sep 2014 09:41:26 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "jon.ruse" , "" Subject: Re: GNU LICENSING References: <88FF098E-0351-4D16-BEAB-60FA1219F3BF@thegarbagefile.org> In-Reply-To: <88FF098E-0351-4D16-BEAB-60FA1219F3BF@thegarbagefile.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ID: VmYRHwZeQh9KN4Cb4Xp1A0FJ7JTqgL2rRc2jWQWYei5J3fpajWp5-di26zHgC63wGM X-TOI-MSGID: 39d62b96-6d27-4683-ae04-37bc0087e2bf 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, 13 Sep 2014 07:41:48 -0000 Am 13.09.2014 um 09:04 schrieb jon.ruse: > I was wondering how to apply to the gnu licensing and how to sign and > commit to the licensing laws.. Would you mind telling me how to > assign to one please?? And one other thing in the license of most gnu > licensing they go on to mention the 'AS IS' commitment but I don't > fully understand, as well could you give me five minutes of you busy > time to explain please?? You just accept the GPL and act accordingly, there is nothing to sign. If you violate the license rules and somebody notices, you may be sued, though. But you really should ask a project that uses the GPL! The BSD projects use the much simpler BSD license for all internally developed code, which in its 2-clause form just requests that you do not remove the copyright mark from any source files and that you distribute a copy of the license with any binaries. And it excludes warranties (in the "PROVIDED ... AS-IS" sentence), as usual for such licenses. [...] > I do donate to the fsf donation station if that is anything meaning?? No it doesn't - donations do not affect what you are allowed to do under the GPL. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 08:00:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38390DFB for ; Sat, 13 Sep 2014 08:00:08 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F01E5A66 for ; Sat, 13 Sep 2014 08:00:07 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 564731598 for ; Sat, 13 Sep 2014 08:00:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s8D800HN076999 for ; Sat, 13 Sep 2014 08:00:00 GMT (envelope-from phk@phk.freebsd.dk) To: "" Subject: Re: GNU LICENSING In-reply-to: <88FF098E-0351-4D16-BEAB-60FA1219F3BF@thegarbagefile.org> From: "Poul-Henning Kamp" References: <88FF098E-0351-4D16-BEAB-60FA1219F3BF@thegarbagefile.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <76997.1410595200.1@critter.freebsd.dk> Date: Sat, 13 Sep 2014 08:00:00 +0000 Message-ID: <76998.1410595200@critter.freebsd.dk> 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, 13 Sep 2014 08:00:08 -0000 -------- >I was wondering how to apply to the gnu licensing [...] Don't feed the Troll please. PS: "John Ruse" -- Really ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 08:30:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEB79317; Sat, 13 Sep 2014 08:30:47 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B216D23; Sat, 13 Sep 2014 08:30:47 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 119E11FE027; Sat, 13 Sep 2014 10:30:39 +0200 (CEST) Message-ID: <541400A3.6060807@selasky.org> Date: Sat, 13 Sep 2014 10:30:27 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: [RFC] Patch to improve TSO limitation formula in general References: <1658973011.35255303.1410467352538.JavaMail.root@uoguelph.ca> In-Reply-To: <1658973011.35255303.1410467352538.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , FreeBSD Current , Scott Long , Jack F Vogel 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, 13 Sep 2014 08:30:48 -0000 Hi Rick, I've collected all input from this discussion and committed the following patch to -current. I would like to MFC this to 10-stable before the coming 10-branchout. Sorry I'm rushing this a bit, hence there is only 2 weeks left until the branching happens. http://svnweb.freebsd.org/changeset/base/271504 Thanks for all good input! --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 08:33:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80753444 for ; Sat, 13 Sep 2014 08:33:49 +0000 (UTC) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1785D3A for ; Sat, 13 Sep 2014 08:33:48 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so2135396lbv.0 for ; Sat, 13 Sep 2014 01:33:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=7vUaOuWoWDeqaZJ343Z/6qUGWX60mSc9GrscKlCUVFk=; b=D27rwvi/8u9ndLAfDNe6croTQMRLNQFNi1TLTgzYFQ339KCwFAPonzs+9dWCEYfn+/ U6b9OVfCX9t9Qo7JXh3tvXlks6Q230Tr0x8HlrNrmnFYqMer2xDzPDqN1ckKGEqI6nwc Z08jqwhgD8hL6hdDugvWFjNhNpM3o96ZHDUisiehE6ev38/dUk/HDaEDXOQIdaxGApRW iUSSJOQXEPSiOt+ACI1IQnCso2Bmwu5ekrD3Q3zzdXHi0OYsE8kX22XcNpYU+q/vJhWj xL1Yi+rkJ0m6xHvGCRG+zrD/Y1OBvwkASl+2Iyi0M1+kBM3U5quzl6SABDxHoP9Xeu1G pspQ== X-Gm-Message-State: ALoCoQlDIBCcJWWlLj6nk2olGProwxlJ1aoeWva/Z0Ki2MGC2WLSfbDiC2DGNF7JBmhuWFHTrEIk X-Received: by 10.152.44.162 with SMTP id f2mr14265979lam.84.1410595503522; Sat, 13 Sep 2014 01:05:03 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id rl6sm1992315lac.17.2014.09.13.01.05.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Sep 2014 01:05:02 -0700 (PDT) Message-ID: <5413FAA4.70406@freebsd.org> Date: Sat, 13 Sep 2014 12:04:52 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Peter Wemm , freebsd-current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: <540FF706.2050400@freebsd.org> <4252906.DAHIEnKpIF@overcee.wemm.org> In-Reply-To: <4252906.DAHIEnKpIF@overcee.wemm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv" Cc: Patrick Kelsey , George Neville-Neil 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, 13 Sep 2014 08:33:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 13.09.2014 8:29, Peter Wemm wrote: > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: >> On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wro= te: >>> On 09.09.2014 21:53, Patrick Kelsey wrote: >>>> I don't think it is worth the trouble, as given the larger pattern o= f >>>> libc routines requiring multiple capsicum rights, it seems one will = in >>>> general have to have libc implementation knowledge when using it in >>>> concert with capsicum. For example, consider the limitfd() routine = in >>>> kdump.c, which provides rights for the TIOCGETA ioctl to be used on >>>> stdout so the eventual call to isatty() via printf() will work as >>> >>> intended. >>> >>>> I think the above kdump example is a good one for the subtle issues = that >>>> can arise when using capsicum with libc. That call to isatty() is v= ia a >>>> widely-used internal libc routine __smakebuf(). __smakebuf() also c= alls >>>> __swhatbuf(), which in turn calls _fstat(), all to make sure that ou= tput >>>> to a tty is line buffered by default. It would appear that programs= >>>> that restrict rights on stdout without allowing CAP_IOCTL and CAP_FS= TAT >>>> could be disabling the normally default line buffering when stdout i= s a >>>> tty. kdump goes the distance, but dhclient does not (restricting st= dout >>>> to CAP_WRITE only). >>>> >>>> In any event, the patch attached to my first message is seeming like= the >>>> way to go. >>> >>> Well, then commit it (if capsicum team agrees). >> >> Will do - thanks for the feedback. >> >> -Patrick >=20 > Is there any possibility that this is related to the problem we've rece= ntly=20 > hit in the freebsd.org cluster with this month's refresh? >=20 > After running for a while: > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator= > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch retu= rned=20 > error -1, errno is Capabilities insufficient unbound itself does not use capsicum, just grep cap_, ldns too, so the problem can be somewhere else. --=20 http://ache.vniz.net/ --IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE/qtAAoJEKUckv0MjfbKTpUIAI4tTHUILv8yi07rD6VJq1P1 aJ0rxMpQgtTvWSOCCwWJyV07zalHIhV46lXKUoMh95MLxHASVvb6ACNxHjRXG0sC cmZSGuKfow0lmVJF0t1Qu8KNZ+WOsMV9nN1tg9SlGpW6OovmiYkRZB6a+beAjOkH SxSlihslbnRyJYwlezzG2eJPRzXk36Drs8B7X2dIkWIgSqbO7tRQyeabacpTvsXm zc1ex3A033+G9AIgHu2Sjbi0IdfhT4yunIqfFQdUW3xKFVQH2qOjSgu6f1Y0wm2R kDgmaaWQ/zrrbYe4eziTGtDr7tQTA3l3cIW1gA1bO19K9ODYvS2KAiEt4sccT08= =UGo1 -----END PGP SIGNATURE----- --IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 08:59:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BDC6AA8; Sat, 13 Sep 2014 08:59:42 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8088EFF; Sat, 13 Sep 2014 08:59:41 +0000 (UTC) Received: from [157.181.98.237] ([157.181.98.237]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0M7pUE-1YFLem3e1A-00vMQU; Sat, 13 Sep 2014 10:59:25 +0200 Message-ID: <54140711.7020001@gmx.com> Date: Sat, 13 Sep 2014 10:57:53 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29 MIME-Version: 1.0 To: John Baldwin , Marcin Cieslak Subject: Re: Xorg causes panics with "multiple" drivers (Was: panic: resource_list_alloc: resource entry is busy) References: <1584874.3FXdLuYUQI@ralph.baldwin.cx> <3819796.R7BYA2qqa8@ralph.baldwin.cx> In-Reply-To: <3819796.R7BYA2qqa8@ralph.baldwin.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:t3L2GnBA6jfdku/DPTjMuwrkOqhVtRl1zU1VRAfwsTYOJ9kif/N t8d/6bBnirATpFM1c88wEDL91QbugWQpsO4fxjEYevPkH7+1eVEbN2q68kJejQGzmkNN9zU wxaTaOY8h7Jtk+L/QMUOtel02X8fy2R65oQ1KhrmsfZLSKMKv2DrMfPzIISO0wkETdzJN8Y QeddO7GGL8RRjh7K7KbCg== X-UI-Out-Filterresults: notjunk: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, 13 Sep 2014 08:59:42 -0000 John Baldwin wrote on 09/12/2014 23:06: > X loaded i915kms automatically and > i915 and i915kms do not get along. i915 had already allocated the IRQ > when i915kms tried to alloc the same IRQ causing the issue. Who is to blame? The user who tried to manually load an unsupported combination of modules, or the system, which should have handled things gracefully (whether by automatically unloading the first driver, or producing a soft-error upon loading the 2nd driver)? On a side-note, I also had a "resource_list_alloc: resource entry is busy" panic right after switching from the 10.0-supported Xorg to the "new" Xorg; I exited Xorg, enabled "FreeBSD_new_Xorg", ran "pkg upgrade", then ran "startx", and got the panic. Surely this wasn't my fault! From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 09:01:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD2A0C7F for ; Sat, 13 Sep 2014 09:01:52 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44FD3F94 for ; Sat, 13 Sep 2014 09:01:51 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.78.13]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LmbZb-1Y2suS2pW7-00aHYj for ; Sat, 13 Sep 2014 11:01:43 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 9734123CF97 for ; Sat, 13 Sep 2014 11:01:42 +0200 (CEST) Message-ID: <541407F6.3020300@gmx.de> Date: Sat, 13 Sep 2014 11:01:42 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> In-Reply-To: <541367D1.8090002@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:T/Q8D8OS4h6zBilECChtS/iIbAYGuOmjNMkxDr6E67m3uXxWwU/ EI7qQzwqcPOXR/62et1ortVt8wJ5gAsHLZCe/MFMm2bTXG9QJ3YdTD4F7OIyreksR3JMti6 rTDsvSfJHRxPBJg2vzJDTvich2v1/IgOnBNx72E1PAMXFPIQ6PJCfLlBlZn8kUJFUK30Fed K3MyM//16/ilSaqpN9ttg== X-UI-Out-Filterresults: notjunk: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: Sat, 13 Sep 2014 09:01:52 -0000 Am 12.09.2014 um 23:38 schrieb Bryan Drewery: > The proper fix is to fix scripts to be portable and use #! /usr/bin/env > bash rather than /bin/bash. Proper portability means scripting for a POSIX sh, and /bin/sh can handle those scripts. In the majority of cases replacing == by = in test or [ commands suffices. > We install all packages to PREFIX=/usr/local by default. Why should a > bin symlink be an exception? There's no suggestion for symlinking > includes or libraries which also hit users often. We'd need something for fsck and thereabouts though... if /usr is on, for instance, an ext2 file system (which is part of the kernel after all), we need the tools early in the boot process, before /usr is there. From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 11:37:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2855A4D3 for ; Sat, 13 Sep 2014 11:37:29 +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 B2EBDDCE for ; Sat, 13 Sep 2014 11:37:28 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8DBbO7k075475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Sep 2014 11:37:25 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1410608245; bh=kp/ZZABGyCxwoj42KpF6xso8dPK/BoiY/UOn5od85d0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WywJt9TTHbKtzpO9lU2BTTMpQ9Syl5J1ZyODzHYqoq0byuG2p2ddMEqUt7hN3wNw0 iYOhbLyFUdCYzPrGgNKaXPYZbhxj28HAUkneHf8r1n6APAi2b0IXa61rIrpHvENYkT f9DrbpgvTrSSqYcHUW8w5YYRPRTzqOrQ08vSeddA= Date: Sat, 13 Sep 2014 11:37:24 +0000 (UTC) From: Marcin Cieslak To: Kevin Oberman Subject: Re: panic: resource_list_alloc: resource entry is busy In-Reply-To: Message-ID: References: <1749648.0eHaTPXHUy@ralph.baldwin.cx> <1584874.3FXdLuYUQI@ralph.baldwin.cx> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sat, 13 Sep 2014 11:37:29 -0000 On Fri, 12 Sep 2014, Kevin Oberman wrote: > On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak wrote: > >> Please note I originally loaded "i915.ko", not "i915kms.ko" >> >> >> Unfortunately, "kldunload i915kms" makes my screen blank >> and probably crashes the system (disk activity stops after >> a short while and there is no response to the keyboard input). >> >> //Marcin >> >> > That explains most of it. You need i915kms. It is conflicting with i915 > which already has the IRQ allocated. > > The black screen is expected. Once KMS starts talking to the graphics > system, syscons can no longer talk to the display, so you get a black > screen. To have a working display, you must enable vt(4). Add "kern.vty=vt" > to /boot/loader.conf to enable vt(4) which will keep the display alive. Yes, I do have "kern.vty=vt" enabled in the loader and without i915kms loaded my system boots correctly. I can load i915kms later per hand or when starting X, but it does not work with bootloader. I think it's a known problem as of September 2nd as stated on the http://wiki.freebsd.org/Newcons page. (My machine is Sony VAIO SZ5MN). //Marcin From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 14:05:45 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 771528DC for ; Sat, 13 Sep 2014 14:05:45 +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 22CFEC86 for ; Sat, 13 Sep 2014 14:05:44 +0000 (UTC) Received: from localhost (saper@localhost [127.0.0.1]) by m.saper.info (8.14.9/8.14.9) with ESMTP id s8DE5etd075816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 13 Sep 2014 14:05:41 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1410617142; bh=HWmod98+fGg7HLuxzuhZj3K34W5b8s7Jqo1jkTRVdcU=; h=Date:From:To:Subject; b=qSbV4GrS+SHyIV++KOYp0q7qUBL1AR6O8lBTnnKjHQ+gAAQswXOGH/XYq8hfpW6OO j5lxP4z4GdfHiL5gwvtv8BFpDmIy9xi66Bzw64M8sDGZtDHaRrEPcOBhDlTfR4149x IpfOGvXDaT9wyVtKnUrXioRq3pRXX0ydPShAw4Ic= Date: Sat, 13 Sep 2014 14:05:40 +0000 (UTC) From: Marcin Cieslak To: freebsd-current@FreeBSD.org Subject: Teach vidcontrol(1) and vt(4) to restore default font Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; 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: Sat, 13 Sep 2014 14:05:45 -0000 Hello, I tried loading gallant.fnt which I did not like and I was wondering how to come back to the nice default font. There does not seem to be the way to do this, so please find below a simple patch to add this functionality. It adds a new ioctl PIO_VDFFONT to the vt(4) driver. I hope I got the reference counting on the vt_font_default structure right. With this patch applied, "vidcontrol -f" restores the built-in font. //Marcin Index: sys/dev/vt/vt_core.c =================================================================== --- sys/dev/vt/vt_core.c (wersja 271197) +++ sys/dev/vt/vt_core.c (kopia robocza) @@ -1948,6 +1948,10 @@ vtfont_unref(vf); return (error); } + case PIO_VDFTFONT: { + error = vt_change_font(vw, &vt_font_default); + return (error); + } case GIO_SCRNMAP: { scrmap_t *sm = (scrmap_t *)data; Index: sys/sys/consio.h =================================================================== --- sys/sys/consio.h (wersja 271197) +++ sys/sys/consio.h (kopia robocza) @@ -239,6 +239,7 @@ #define GIO_FONT8x16 _IOR('c', 69, fnt16_t) #define PIO_VFONT _IOW('c', 70, vfnt_t) #define GIO_VFONT _IOR('c', 71, vfnt_t) +#define PIO_VDFTFONT _IO('c', 72) /* get video mode information */ struct colors { Index: usr.sbin/vidcontrol/vidcontrol.1 =================================================================== --- usr.sbin/vidcontrol/vidcontrol.1 (wersja 271197) +++ usr.sbin/vidcontrol/vidcontrol.1 (kopia robocza) @@ -26,9 +26,11 @@ .Op Fl c Ar appearance .Oo .Fl f +.Oo .Op Ar size .Ar file .Oc +.Oc .Op Fl g Ar geometry .Op Fl h Ar size .Op Fl i Cm adapter | mode @@ -136,8 +138,10 @@ Print out current output screen map. .It Xo .Fl f +.Oo .Op Ar size .Ar file +.Oc .Xc Load font .Ar file @@ -158,6 +162,14 @@ .Nm will try to guess it from the size of font file. .Pp +When using +.Xr vt 4 +both +.Ar size +and +.Ar font +can be omitted, and the default font will be loaded. +.Pp Note that older video cards, such as MDA and CGA, do not support software font. See also Index: usr.sbin/vidcontrol/vidcontrol.c =================================================================== --- usr.sbin/vidcontrol/vidcontrol.c (wersja 271197) +++ usr.sbin/vidcontrol/vidcontrol.c (kopia robocza) @@ -197,7 +197,7 @@ { if (vt4_mode) fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n", -"usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [size] file]", +"usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [[size] file]]", " [-g geometry] [-h size] [-i adapter | mode]", " [-M char] [-m on | off] [-r foreground background]", " [-S on | off] [-s number] [-T xterm | cons25] [-t N | off]", @@ -409,6 +409,19 @@ return (t); } +/* + * Set the default vt font. + */ + +static void +load_default_vt4font(void) +{ + if (ioctl(0, PIO_VDFTFONT) == -1) { + revert(); + errc(1, errno, "loading default vt font"); + } +} + static int load_vt4font(FILE *f) { @@ -1328,7 +1341,7 @@ dumpopt = DUMP_FBF; termmode = NULL; if (vt4_mode) - opts = "b:Cc:f:g:h:Hi:M:m:pPr:S:s:T:t:x"; + opts = "b:Cc:fg:h:Hi:M:m:pPr:S:s:T:t:x"; else opts = "b:Cc:df:g:h:Hi:l:LM:m:pPr:S:s:T:t:x"; @@ -1349,15 +1362,23 @@ print_scrnmap(); break; case 'f': - type = optarg; - font = nextarg(argc, argv, &optind, 'f', 0); + optarg = nextarg(argc, argv, &optind, 'f', 0); + if (optarg != NULL) { + font = nextarg(argc, argv, &optind, 'f', 0); - if (font == NULL) { - type = NULL; - font = optarg; + if (font == NULL) { + type = NULL; + font = optarg; + } else + type = optarg; + + load_font(type, font); + } else { + if (!vt4_mode) + usage(); /* Switch syscons to ROM? */ + + load_default_vt4font(); } - - load_font(type, font); break; case 'g': if (sscanf(optarg, "%dx%d", From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 18:32:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFF138C4; Sat, 13 Sep 2014 18:32:54 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91BC1A1D; Sat, 13 Sep 2014 18:32:53 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so2577200lbv.0 for ; Sat, 13 Sep 2014 11:32:51 -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=wsOJsUtR1/GmlRQ0Q0WJ4Z9A6MKMkh1GQAXtyiq+Yi0=; b=EEf0QKklupV8umqATZ31XWJ/dgHcG4XNf7bPrXxizMhVxHC6Umpy0V5MmeMSfiDh26 6WzO6Ra18i3HID3XCn7WWuodEIdFvKWn6iFjvTZ8H5wcdQsLRY8yjquMhtZoWeTwzxw3 /pcCJ6l+Kb4JCFNKiQSwIvqYvIkMbVFBRI6lmGgVLMUIgPQ8YUMpxMqwB/kpBShVe6km ovVQaijJEPMZmXpVoKN9sCH9S8GtXHqO0n6aienV45wqVdJYBWFKpeasZoj4kn13+ESE JjuUX8FprojrD72ckO2ROnBdI1XtoLG3k+tyaVFGPM5DgAwh/PVOKINVH9eRJFmKP63k R7+A== MIME-Version: 1.0 X-Received: by 10.152.36.73 with SMTP id o9mr4341534laj.88.1410633171386; Sat, 13 Sep 2014 11:32:51 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.22.72 with HTTP; Sat, 13 Sep 2014 11:32:51 -0700 (PDT) In-Reply-To: <541367D1.8090002@FreeBSD.org> References: <541367D1.8090002@FreeBSD.org> Date: Sat, 13 Sep 2014 11:32:51 -0700 X-Google-Sender-Auth: KkU98ryf733qcsczIyo02e2Tgkg Message-ID: Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Craig Rodrigues To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current Current , Emanuel Haupt , ports 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, 13 Sep 2014 18:32:54 -0000 On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery wrote: > > There's no reason for bash (and perl) to be exceptions to the 24000 > other ports that install to /usr/local/bin. I can think of dozens of > other ports that will fall into the same arguments being made here, but > it does not mean it is the right thing for FreeBSD. > > If you want to install the symlink on your system feel free to do it. I > install a static bash to /bin/bash on mine and only because I prefer > bash shell and want it in / for single-user mode. That's my personal > choice though. > > The proper fix is to fix scripts to be portable and use #! /usr/bin/env > bash rather than /bin/bash. > Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. The /bin/bash thing is relatively minor, but I brought it up, because I see it so much. I've seen it in the jobs that I've worked at. I've also seen it when dealing with Google Summer of Code students. I've seen it in blogs mentioned when Linux users evaluate FreeBSD. I've seen it when people design appliances based on FreeBSD, but want the device to be "familiar" enough for Linux-y devops people to interact with it. If there are minor things that we can do in FreeBSD to improve the out-of-box experience of FreeBSD to new users who may be used to Linux or MacOS X, that would be great. Telling people to change their shell scripts, or manually create symlinks to /bin/bash is doable, but why not have something in the system do this automatically, so that the average end-user does not even have to think about it? If adding an optional knob to the bash port which is OFF by default to do this is a no-go, would having an optional port like what Brooks Davis mentioned be allowed which creates the symlink and updates /etc/shells? -- Craig From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 18:39:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 548B0D4D for ; Sat, 13 Sep 2014 18:39:06 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 24D17A90 for ; Sat, 13 Sep 2014 18:39:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id E1B5038084 for ; Sat, 13 Sep 2014 13:39:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id tzW-rdAFG2NR for ; Sat, 13 Sep 2014 13:39:04 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 975D238083 for ; Sat, 13 Sep 2014 13:39:04 -0500 (CDT) Message-ID: <54148F47.4030000@freebsd.org> Date: Sat, 13 Sep 2014 11:39:03 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2014 18:39:06 -0000 On 09/13/14 11:32, Craig Rodrigues wrote: > On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery wrote: > >> There's no reason for bash (and perl) to be exceptions to the 24000 >> other ports that install to /usr/local/bin. I can think of dozens of >> other ports that will fall into the same arguments being made here, but >> it does not mean it is the right thing for FreeBSD. >> >> If you want to install the symlink on your system feel free to do it. I >> install a static bash to /bin/bash on mine and only because I prefer >> bash shell and want it in / for single-user mode. That's my personal >> choice though. >> >> The proper fix is to fix scripts to be portable and use #! /usr/bin/env >> bash rather than /bin/bash. >> > Technically, I agree with you that people should write portable shell > scripts, > and use #!/usr/bin/env bash rather than #!/bin/bash. > > Pushing that behavior upstream is not always practical these days, where > FreeBSD is in the minority, while Linux and MacOS X are in the vast > majority of where > people are doing development and learning how to write shell scripts these > days. > > The /bin/bash thing is relatively minor, but I brought it up, because I see > it so much. > I've seen it in the jobs that I've worked at. I've also seen it when > dealing with Google > Summer of Code students. I've seen it in blogs mentioned when Linux users > evaluate FreeBSD. > I've seen it when people design appliances based on FreeBSD, but want the > device to be > "familiar" enough for Linux-y devops people to interact with it. > > If there are minor things that we can do in FreeBSD to improve the > out-of-box experience > of FreeBSD to new users who may be used to Linux or MacOS X, that would be > great. > Telling people to change their shell scripts, or manually create symlinks > to /bin/bash is doable, > but why not have something in the system do this automatically, so that the > average end-user does > not even have to think about it? > > If adding an optional knob to the bash port which is OFF by default to do > this is a no-go, > would having an optional port like what Brooks Davis mentioned be allowed > which creates > the symlink and updates /etc/shells? > > -- > Craig > _______________________________________________ > 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" > I'd point out that the perl ports have exactly such an option already (putting links in /usr/bin, in this case). The CUPS port does too. -Nathan From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 19:42:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81B8CEA6; Sat, 13 Sep 2014 19:42:31 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCDA8A2; Sat, 13 Sep 2014 19:42:30 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id c11so2616085lbj.15 for ; Sat, 13 Sep 2014 12:42: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=JhmiM+829PAwQUNRWfdPqW9R9k3+3U+flhh9qKFGD04=; b=Xq54YQCSHam9NImPtUBmnmlFscQl81B4KhdN1kGuE8iDcfHVZVMpyJsTFP+lSifaZi blo98EVpcttCDIktsDAfYnCLXQ+AtgLDgIT81WY1YZbblg/SiC6TErMa5ZUgz2mLGLFz HdT7HqEYs8ngwTrlzkUfcFDbYynerH16whZJvTxS5C2Oxeix54KEWqrFf30vM8s24a/X TV72RqSCFm3Bwh0jpsMV3CuMZoEWBuQw01oeZup/LdR2smuLdJilyzfAarK5llFSho+3 IgRHMAc4ASWYVPscwW5hmFsMBcJEZ/rXigHPhDKcZlvH+nmhWAjYvWXR+DRfXOOAku1G GSdw== MIME-Version: 1.0 X-Received: by 10.112.72.10 with SMTP id z10mr11820247lbu.87.1410637348794; Sat, 13 Sep 2014 12:42:28 -0700 (PDT) Received: by 10.25.42.1 with HTTP; Sat, 13 Sep 2014 12:42:28 -0700 (PDT) In-Reply-To: <54148F47.4030000@freebsd.org> References: <541367D1.8090002@FreeBSD.org> <54148F47.4030000@freebsd.org> Date: Sat, 13 Sep 2014 21:42:28 +0200 Message-ID: Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? From: Andreas Nilsson To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Current FreeBSD 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, 13 Sep 2014 19:42:31 -0000 On Sat, Sep 13, 2014 at 8:39 PM, Nathan Whitehorn wrote: > On 09/13/14 11:32, Craig Rodrigues wrote: > >> On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery >> wrote: >> >> There's no reason for bash (and perl) to be exceptions to the 24000 >>> other ports that install to /usr/local/bin. I can think of dozens of >>> other ports that will fall into the same arguments being made here, but >>> it does not mean it is the right thing for FreeBSD. >>> >>> If you want to install the symlink on your system feel free to do it. I >>> install a static bash to /bin/bash on mine and only because I prefer >>> bash shell and want it in / for single-user mode. That's my personal >>> choice though. >>> >>> The proper fix is to fix scripts to be portable and use #! /usr/bin/env >>> bash rather than /bin/bash. >>> >>> Technically, I agree with you that people should write portable shell >> scripts, >> and use #!/usr/bin/env bash rather than #!/bin/bash. >> >> Pushing that behavior upstream is not always practical these days, where >> FreeBSD is in the minority, while Linux and MacOS X are in the vast >> majority of where >> people are doing development and learning how to write shell scripts these >> days. >> >> The /bin/bash thing is relatively minor, but I brought it up, because I >> see >> it so much. >> I've seen it in the jobs that I've worked at. I've also seen it when >> dealing with Google >> Summer of Code students. I've seen it in blogs mentioned when Linux users >> evaluate FreeBSD. >> I've seen it when people design appliances based on FreeBSD, but want the >> device to be >> "familiar" enough for Linux-y devops people to interact with it. >> >> If there are minor things that we can do in FreeBSD to improve the >> out-of-box experience >> of FreeBSD to new users who may be used to Linux or MacOS X, that would be >> great. >> Telling people to change their shell scripts, or manually create symlinks >> to /bin/bash is doable, >> but why not have something in the system do this automatically, so that >> the >> average end-user does >> not even have to think about it? >> >> If adding an optional knob to the bash port which is OFF by default to do >> this is a no-go, >> would having an optional port like what Brooks Davis mentioned be allowed >> which creates >> the symlink and updates /etc/shells? >> >> -- >> Craig >> _______________________________________________ >> 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 >> " >> >> > I'd point out that the perl ports have exactly such an option already > (putting links in /usr/bin, in this case). The CUPS port does too. > -Nathan > > Sorry Nathan, reply all is sometimes harder than it should be. Just for the uncomfortable stuff: How about systems where env is not in /usr/bin ? I had that fun episode on an opensolaris-system... Best regards Andreas Nilsson From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 21:28:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAAE5ECE; Sat, 13 Sep 2014 21:28:35 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82147BE4; Sat, 13 Sep 2014 21:28:35 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XSurq-000MwJ-3u; Sun, 14 Sep 2014 01:28:26 +0400 Date: Sun, 14 Sep 2014 01:28:26 +0400 From: Slawa Olhovchenkov To: Bryan Drewery Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? Message-ID: <20140913212826.GA11540@zxy.spb.ru> References: <541367D1.8090002@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541367D1.8090002@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Craig Rodrigues , freebsd-current Current , Emanuel Haupt , ports 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, 13 Sep 2014 21:28:35 -0000 On Fri, Sep 12, 2014 at 04:38:25PM -0500, Bryan Drewery wrote: > "No" (as portmgr). > > Ports should not be touching the base system like this. Let's NOT go > backwards and add a /bin/bash. In fact the /usr/bin/perl one will be > removed soon as well. This is (for perl) may break many 3rd party scripts. From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 21:33:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAF8A111; Sat, 13 Sep 2014 21:33:26 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 71477C88; Sat, 13 Sep 2014 21:33:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id EEC2338084; Sat, 13 Sep 2014 16:33:24 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id cub1bQMZjbC0; Sat, 13 Sep 2014 16:33:24 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 544E138083; Sat, 13 Sep 2014 16:33:24 -0500 (CDT) Message-ID: <5414B0F3.50109@freebsd.org> Date: Sat, 13 Sep 2014 14:02:43 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bryan Drewery , Craig Rodrigues , ports , Emanuel Haupt Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? References: <541367D1.8090002@FreeBSD.org> In-Reply-To: <541367D1.8090002@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: Sat, 13 Sep 2014 21:33:27 -0000 As a slight distraction from the topic, is this actually possible in general? I'm thinking in particular of ports that install kernel modules. Since LOCALBASE may be (and very often is) a different file system from /, such modules cannot be accessible to loader and so can't be loaded in early boot. This is potentially a problem for wireless driver firmware modules, for example. -Nathan On 09/12/14 14:38, Bryan Drewery wrote: > "No" (as portmgr). > > Ports should not be touching the base system like this. Let's NOT go > backwards and add a /bin/bash. In fact the /usr/bin/perl one will be > removed soon as well. > > If we can actually eliminate ports touching /usr and / (not including > /usr/local and /var) then we gain a very large memory optimization for > package building by being able to ro null-mount these to the build jails. > > There's no reason for bash (and perl) to be exceptions to the 24000 > other ports that install to /usr/local/bin. I can think of dozens of > other ports that will fall into the same arguments being made here, but > it does not mean it is the right thing for FreeBSD. > > If you want to install the symlink on your system feel free to do it. I > install a static bash to /bin/bash on mine and only because I prefer > bash shell and want it in / for single-user mode. That's my personal > choice though. > > The proper fix is to fix scripts to be portable and use #! /usr/bin/env > bash rather than /bin/bash. > > We install all packages to PREFIX=/usr/local by default. Why should a > bin symlink be an exception? There's no suggestion for symlinking > includes or libraries which also hit users often. > > On 9/12/2014 4:12 PM, Craig Rodrigues wrote: >> Hi, >> >> In the last 3 jobs that I have worked at, there have been >> a mix of Linux machines and FreeBSD machines. >> When using an NIS or LDAP environment where >> there is a single login across multiple machines, it is useful to >> have a single shell setting. >> >> Since Linux and MacOS X have "/bin/bash" as the shell, >> in order to get the FreeBSD boxes to play in this environment, >> I have seen admins do the following on FreeBSD setups: >> ln -s /usr/local/bin/bash /bin/bash >> >> or >> >> ln /usr/local/bin/bash /bin/bash >> >> and then make sure that /etc/shells as: >> /usr/local/bin/bash >> /bin/bash >> >> Can we add an optional knob (turned off by default) which creates this >> symlink >> and updates /etc/shells? >> >> This would help with interoperability of FreeBSD hosts in environments mixed >> with Linux and MacOS X. >> >> -- >> Craig >> _______________________________________________ >> freebsd-ports@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >> > From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 19:39:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2341E01; Sat, 13 Sep 2014 19:39:59 +0000 (UTC) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3958FF88; Sat, 13 Sep 2014 19:39:59 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id a3so682807oib.28 for ; Sat, 13 Sep 2014 12:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jlUSy5Ft26U9ZDFaXIAx+wm4JCcgX+R3vM15v6cUAXY=; b=qz0NoWTYo+PsvJOGJ3p+s5yCWuFZqLshP/FWYaVYgP8aD5Di3gdOYwA3fIxpOqfM1T lxugkNiiC5Mcb2wZIYll4NSt1n0UjdywmvBUD6E8C466XWTBYO6E3z/IeoUaIrEa1f1Z c5lOnbxKNLXuvFdzQjITqXt7nKf/lGacfniD+pX8xNnm1wo1r1CnAyluoAEXCfoGGtuO oNr7zBVG8+bJQGQ6jRIxpaz2wsO7LI2Pp+DidfDzFDQuP4vzNLXiOa5ibScEctGhpxeP NezFoEqBsX0wP3ZOaw+3cHYP4h+MjmBRihw7D7qyQEcyvImahGZSV/FTxxZh0S34FOph dT6g== X-Received: by 10.60.119.98 with SMTP id kt2mr17232538oeb.13.1410637198450; Sat, 13 Sep 2014 12:39:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.175.230 with HTTP; Sat, 13 Sep 2014 12:39:17 -0700 (PDT) In-Reply-To: References: <541367D1.8090002@FreeBSD.org> From: Dreamcat4 Date: Sat, 13 Sep 2014 20:39:17 +0100 Message-ID: Subject: Re: shells/bash port, add a knob which symlinks to /bin/bash ? To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 13 Sep 2014 22:50:07 +0000 Cc: freebsd-current Current , ports , Emanuel Haupt , Bryan Drewery 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, 13 Sep 2014 19:39:59 -0000 Right, well here is another one: The missing symlink for /etc/ssl/cert.pem There is no reason it should not be in ${prefix}/etc/ssl/cert.pem Except that the folder etc/ssl/ only exists in base. Without this symlink, then SSL certs aren't found by the 'fetch' command and many significant websites these days can't work without SSL. For example github.com (there are others). On Sat, Sep 13, 2014 at 7:32 PM, Craig Rodrigues wrote: > On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery wrote: > >> >> There's no reason for bash (and perl) to be exceptions to the 24000 >> other ports that install to /usr/local/bin. I can think of dozens of >> other ports that will fall into the same arguments being made here, but >> it does not mean it is the right thing for FreeBSD. >> >> If you want to install the symlink on your system feel free to do it. I >> install a static bash to /bin/bash on mine and only because I prefer >> bash shell and want it in / for single-user mode. That's my personal >> choice though. >> >> The proper fix is to fix scripts to be portable and use #! /usr/bin/env >> bash rather than /bin/bash. >> > > Technically, I agree with you that people should write portable shell > scripts, > and use #!/usr/bin/env bash rather than #!/bin/bash. > > Pushing that behavior upstream is not always practical these days, where > FreeBSD is in the minority, while Linux and MacOS X are in the vast > majority of where > people are doing development and learning how to write shell scripts these > days. > > The /bin/bash thing is relatively minor, but I brought it up, because I see > it so much. > I've seen it in the jobs that I've worked at. I've also seen it when > dealing with Google > Summer of Code students. I've seen it in blogs mentioned when Linux users > evaluate FreeBSD. > I've seen it when people design appliances based on FreeBSD, but want the > device to be > "familiar" enough for Linux-y devops people to interact with it. > > If there are minor things that we can do in FreeBSD to improve the > out-of-box experience > of FreeBSD to new users who may be used to Linux or MacOS X, that would be > great. > Telling people to change their shell scripts, or manually create symlinks > to /bin/bash is doable, > but why not have something in the system do this automatically, so that the > average end-user does > not even have to think about it? > > If adding an optional knob to the bash port which is OFF by default to do > this is a no-go, > would having an optional port like what Brooks Davis mentioned be allowed > which creates > the symlink and updates /etc/shells? > > -- > Craig > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"