From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 09:13:10 2015 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9AD4D17 for ; Sun, 1 Feb 2015 09:13:10 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 86AFBB2B for ; Sun, 1 Feb 2015 09:13:10 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id E5B2C6A6072; Sun, 1 Feb 2015 10:13:06 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t119D6oQ038258; Sun, 1 Feb 2015 10:13:06 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t119D6mc037280; Sun, 1 Feb 2015 10:13:06 +0100 (CET) (envelope-from lars) Date: Sun, 1 Feb 2015 10:13:06 +0100 From: Lars Engels To: Konstantin Belousov , current@FreeBSD.org Subject: Re: Suspend/resume with i915. Message-ID: <20150201091305.GM41565@e-new.0x20.net> References: <20150122110201.GA3996@brick.home> <20150123084057.GD42409@kib.kiev.ua> <20150130221248.GA8489@brick.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OGW1Z2JKiS9bXo17" Content-Disposition: inline In-Reply-To: <20150130221248.GA8489@brick.home> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:13:11 -0000 --OGW1Z2JKiS9bXo17 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 30, 2015 at 11:12:48PM +0100, Edward Tomasz Napiera=C5=82a wrot= e: > On 0123T1040, Konstantin Belousov wrote: > > On Thu, Jan 22, 2015 at 12:02:01PM +0100, Edward Tomasz Napiera??a wrot= e: > > > I'm trying to fix resume on my T61, broken by some change several > > > months ago; according to pciconf it's 'Mobile GM965/GL960 Integrated > > > Graphics Controller (primary)'. It's running current CURRENT and > > > up to date packages. > > >=20 > > > Suspend and resume makes Xorg do something weird - there is screen > > > corruption, or rather window corruption. The GNOME 3 desktop looks > > > pretty normal, except that gnome-terminal (launched before suspend) > > > window looks as if the buffer layout changed underneath it; for examp= le, > > > instead of one flashing cursor there are several, horizontally, across > > > the window. New windows are simply black. No segv. > > >=20 > > > Setting kern.vt.suspendswitch=3D0 makes the behaviour disappear, repl= aced > > > by segmentation faults of gnome-shell. With stock gdb it looks like = this: > >=20 > > At least one big known issue with suspend is that userspace activity > > is not stopped, which makes the driver suspend code operating on the > > non-steady state of devices. > >=20 > > I committed the facility to stop userspace before suspend, and avg prom= ised > > to integrate this into suspend path, but he did not. You might try to > > search mailing lists for reference to his earlier patch. >=20 > Unfortunately stuff was committed before I could test it. Fortunately, > it's all fixed now, and works perfectly, on 11-CURRENT. Thanks! :-) I can add that suspend/resume now works reliable again on my X230. --OGW1Z2JKiS9bXo17 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUze4hXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tJ2oH/RjIai5Qtq/7mVlRPHhkChcW 9UTADtg/utVYuCYtQr1R+ejTPfuCR6BF3TQpt0msiwAFvgTBxzTD080tUexaqifd S4C6gASX8RqgajR8YSiM1LDUMkpmYyWc5yHkC0sKM+sjNN7GYOSKkOdCEmMOiFNL VNJzZCd+8T0KbYKfZ3/mpBhAQn/UojONB1NkRqVTQ8/mO2g3a2F5vwfZiRES2rVc 6t25Z2j8G/e9lLzv5nH7sIBq5gMa/Gw+V0QGEizi1qmG2lnplGeMOeXSIfGkgADb lFx4/91QYDGRiV8BLDr/9wMLwknOwWntfGzYah1SVmQ8oqPpnW7mJoHWpmb4nEM= =SD17 -----END PGP SIGNATURE----- --OGW1Z2JKiS9bXo17-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 09:18:26 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0304BF95 for ; Sun, 1 Feb 2015 09:18:26 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 8B565B7E for ; Sun, 1 Feb 2015 09:18:25 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 8E56E6A6072; Sun, 1 Feb 2015 10:18:23 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t119INCa073197; Sun, 1 Feb 2015 10:18:23 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t119ILe5072307; Sun, 1 Feb 2015 10:18:21 +0100 (CET) (envelope-from lars) Date: Sun, 1 Feb 2015 10:18:21 +0100 From: Lars Engels To: Miguel Clara Subject: Re: drm2 regression: backlight adjustment on ivybridge no longer works Message-ID: <20150201091821.GN41565@e-new.0x20.net> Mail-Followup-To: Lars Engels , Miguel Clara , Alexandr Krivulya , freebsd-current References: <000e01d039fb$d5959930$80c0cb90$@Wilcox-Tech.com> <009501d03acb$4f380d70$eda82850$@Wilcox-Tech.com> <54CA7949.6060202@shurik.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mkHYMT4O8DyWoHkb" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Alexandr Krivulya , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:18:26 -0000 --mkHYMT4O8DyWoHkb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 31, 2015 at 07:11:23AM +0000, Miguel Clara wrote: > On the laptop I'm running current, if relevant >=20 > Loading acpi_video doesn't do much.... I don't see any sysctl related to > "lcd0" or "birightness", this is one of those computers with "hybrid" > graphics, intel + ATI card, so not sure if that's somewhat related. >=20 >=20 > Anyway, I've just tested the drm patches (both) and intelbacklight ( > https://github.com/grembo/intel_backlight_fbsd) compiles, installs and ru= ns > fine! >=20 > So thanks both for the patches. On my X230 I also lost the ability to control brightness with Fn+F8 / Fn+F9. With acpi_video I get some interesting sysctl: hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 I guess it should not be 100 100 0 ... 100? Changing brightness with hw.acpi.video.lcd0.brightness doesn't work. --mkHYMT4O8DyWoHkb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUze9dXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tQ+gH/jEBM3TQ5zrAsvhYKSsYQDVB JMN8//93h62LFwb+Q4GAPlJ1xrQ36X32KAcu1h2ib3dcWYJoU780FP9Q1Nzc7q+D J3TwZ21rLJ2Mzjwgr67UgF2MGAywcRo+HYxbYHUh5ehUzdFFlIXQJ9l0PLfrM7Fg CwGo1AJgqYIONa+ty6/ET05mrgzAQppjaPOc/paR4K3ya9eW9eYQ+Fej4T/b8GbX i6OP4DrcJOMG1Iy8JX5dq35YZjfbF3UX2mg/c8s+hiO5wvRG/jjKUf7/OTkGnqTF en6edSbQwAGsIy8o31cRIlyjjc7wH0zZ38TgG693v+tIhFZIkXU2mq4T6rAkutI= =PvwB -----END PGP SIGNATURE----- --mkHYMT4O8DyWoHkb-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 09:35:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 804791DD for ; Sun, 1 Feb 2015 09:35:23 +0000 (UTC) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.99.209.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "mail.wilcox-tech.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 30DCCD0B for ; Sun, 1 Feb 2015 09:35:22 +0000 (UTC) Received: (qmail 15237 invoked from network); 1 Feb 2015 09:36:39 -0000 Received: from c-71-57-141-247.hsd1.fl.comcast.net (HELO Todd) (AWilcox@Wilcox-Tech.com@71.57.141.247) by mail.foxkit.us with ESMTPA; 1 Feb 2015 09:36:39 -0000 From: "Andrew Wilcox" To: "'Lars Engels'" References: <000e01d039fb$d5959930$80c0cb90$@Wilcox-Tech.com> <009501d03acb$4f380d70$eda82850$@Wilcox-Tech.com> <54CA7949.6060202@shurik.kiev.ua> <20150201091821.GN41565@e-new.0x20.net> In-Reply-To: <20150201091821.GN41565@e-new.0x20.net> Subject: RE: drm2 regression: backlight adjustment on ivybridge no longer works Date: Sun, 1 Feb 2015 03:35:15 -0600 Message-ID: <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIkD3QRswOKHk1/aLD21PpFfsdgwgGR9mCRAv4GIYoBQ/0CWQFVsuEzAdu6yxICF+RyFwHU1tELAhApZbkBHhSMQQFipJRdm6fJWEA= Content-Language: en-gb Cc: 'freebsd-current' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:35:23 -0000 Lars Engels sent: 01 February 2015 03:18: > With acpi_video I get some interesting sysctl: > hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 = 15 > 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 = 39 > 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 = 63 > 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 = 87 > 88 89 90 91 92 93 94 95 96 97 98 99 100 >=20 > I guess it should not be 100 100 0 ... 100? Actually, the "standard" internal ACPI brightness level struct (BRTN in = the DSDT) is laid out as: * "Full power" value (one byte, the value at which the brightness should = be set on AC by default) * "Economy" value (one byte, the value at which the brightness should be = set on battery by default) * Actual values (N bytes, up to Max but frequently not) So, no, that value indeed sounds correct. On my laptop the value is: 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 What revision of -CURRENT are you running? What is the outcome of = trying the patch posted Saturday morning (UTC) from Elizabeth Myers = (message ID <54CC5311.9070604@interlinked.me>)? Andrew -- Andrew Wilcox, C/C++/Python developer, kernel hacker Blog: http://blog.foxkit.us/ WWW: http://foxkit.us/ GitHub: https://github.com/awilfox From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 09:41:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFDA92FB for ; Sun, 1 Feb 2015 09:41:27 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 51294D2E for ; Sun, 1 Feb 2015 09:41:27 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 41A586A605C; Sun, 1 Feb 2015 10:41:25 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t119fPn5083402; Sun, 1 Feb 2015 10:41:25 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t119fPih082702; Sun, 1 Feb 2015 10:41:25 +0100 (CET) (envelope-from lars) Date: Sun, 1 Feb 2015 10:41:25 +0100 From: Lars Engels To: Andrew Wilcox Subject: Re: drm2 regression: backlight adjustment on ivybridge no longer works Message-ID: <20150201094124.GO41565@e-new.0x20.net> Mail-Followup-To: Lars Engels , Andrew Wilcox , 'freebsd-current' References: <000e01d039fb$d5959930$80c0cb90$@Wilcox-Tech.com> <009501d03acb$4f380d70$eda82850$@Wilcox-Tech.com> <54CA7949.6060202@shurik.kiev.ua> <20150201091821.GN41565@e-new.0x20.net> <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uX2tiToO0oGq+LKk" Content-Disposition: inline In-Reply-To: <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: 'freebsd-current' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 09:41:27 -0000 --uX2tiToO0oGq+LKk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 01, 2015 at 03:35:15AM -0600, Andrew Wilcox wrote: > Lars Engels sent: 01 February 2015 03:18: > > With acpi_video I get some interesting sysctl: > > hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > > 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 > > 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 > > 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 > > 88 89 90 91 92 93 94 95 96 97 98 99 100 > >=20 > > I guess it should not be 100 100 0 ... 100? >=20 > Actually, the "standard" internal ACPI brightness level struct (BRTN in t= he DSDT) is laid out as: >=20 > * "Full power" value (one byte, the value at which the brightness should = be set on AC by default) > * "Economy" value (one byte, the value at which the brightness should be = set on battery by default) > * Actual values (N bytes, up to Max but frequently not) >=20 > So, no, that value indeed sounds correct. On my laptop the value is: > 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 Thank you for the explanation. FWIW, here is the full output from sysctl hw.acpi.video.lcd0: hw.acpi.video.lcd0.active: 1 hw.acpi.video.lcd0.brightness: 11 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 100 hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 hw.acpi.video.crt0.active: 1 hw.acpi.video.ext0.active: 1 hw.acpi.video.ext1.active: 1 hw.acpi.video.ext2.active: 1 hw.acpi.video.ext3.active: 1 hw.acpi.video.ext4.active: 1 hw.acpi.video.ext5.active: 1 >=20 > What revision of -CURRENT are you running? What is the outcome of > trying the patch posted Saturday morning (UTC) from Elizabeth Myers > (message ID <54CC5311.9070604@interlinked.me>)? >=20 I'm currently running r277858 and haven't tried the patch, yet. But will do now and report back. --uX2tiToO0oGq+LKk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUzfTEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tTfIH/jyGKz9vMp/r7CwYPY7lIdMg fbIqONFl/LlKt6oiriVEgljSwKP0hi39hmtjgQGd+zWWEKfGVPyNlUshpDUxJvos GjrwGH913UB3PLFuGG/h6rhcr8Qkt+e73uYS5Rav/N6WIQY6tsQ7DSS67z0hBEKI s0eMV3JdGpztk0mf6+MkiGJiOdfKXxK2A5BK/7hbzK+C/LvYux9Z+ubFElQL/rv8 Y7wRhXv2ty5vh7Ho37+JoC4aZ7uZxZZlGhbxl4U+9VdP2k6OaWVBqGqVkahe97l4 ld98X1GbrksfUGAuJkC95C5zkvAbeIK4X351YtLzBzJolJZqOhO3c5ukF+o4juU= =DgRi -----END PGP SIGNATURE----- --uX2tiToO0oGq+LKk-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 10:12:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05863EB3 for ; Sun, 1 Feb 2015 10:12:04 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 877B3101 for ; Sun, 1 Feb 2015 10:12:03 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 794306A6064; Sun, 1 Feb 2015 11:12:01 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t11AC1i4011845; Sun, 1 Feb 2015 11:12:01 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t11AC18x010697; Sun, 1 Feb 2015 11:12:01 +0100 (CET) (envelope-from lars) Date: Sun, 1 Feb 2015 11:12:01 +0100 From: Lars Engels To: Andrew Wilcox , "'freebsd-current'" Subject: Re: drm2 regression: backlight adjustment on ivybridge no longer works Message-ID: <20150201101201.GP41565@e-new.0x20.net> Mail-Followup-To: Lars Engels , Andrew Wilcox , 'freebsd-current' References: <009501d03acb$4f380d70$eda82850$@Wilcox-Tech.com> <54CA7949.6060202@shurik.kiev.ua> <20150201091821.GN41565@e-new.0x20.net> <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> <20150201094124.GO41565@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tjOMJDssiV0CZSJH" Content-Disposition: inline In-Reply-To: <20150201094124.GO41565@e-new.0x20.net> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 10:12:04 -0000 --tjOMJDssiV0CZSJH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 01, 2015 at 10:41:25AM +0100, Lars Engels wrote: > On Sun, Feb 01, 2015 at 03:35:15AM -0600, Andrew Wilcox wrote: > > Lars Engels sent: 01 February 2015 03:18: > > > With acpi_video I get some interesting sysctl: > > > hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14= 15 > > > 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 = 39 > > > 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 = 63 > > > 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 = 87 > > > 88 89 90 91 92 93 94 95 96 97 98 99 100 > > >=20 > > > I guess it should not be 100 100 0 ... 100? > >=20 > > Actually, the "standard" internal ACPI brightness level struct (BRTN in= the DSDT) is laid out as: > >=20 > > * "Full power" value (one byte, the value at which the brightness shoul= d be set on AC by default) > > * "Economy" value (one byte, the value at which the brightness should b= e set on battery by default) > > * Actual values (N bytes, up to Max but frequently not) > >=20 > > So, no, that value indeed sounds correct. On my laptop the value is: > > 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 >=20 > Thank you for the explanation. > FWIW, here is the full output from sysctl hw.acpi.video.lcd0: >=20 > hw.acpi.video.lcd0.active: 1 > hw.acpi.video.lcd0.brightness: 11 > hw.acpi.video.lcd0.fullpower: 100 > hw.acpi.video.lcd0.economy: 100 > hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 > 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 > 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 > 88 89 90 91 92 93 94 95 96 97 98 99 100 > hw.acpi.video.crt0.active: 1 > hw.acpi.video.ext0.active: 1 > hw.acpi.video.ext1.active: 1 > hw.acpi.video.ext2.active: 1 > hw.acpi.video.ext3.active: 1 > hw.acpi.video.ext4.active: 1 > hw.acpi.video.ext5.active: 1 >=20 > >=20 > > What revision of -CURRENT are you running? What is the outcome of > > trying the patch posted Saturday morning (UTC) from Elizabeth Myers > > (message ID <54CC5311.9070604@interlinked.me>)? > >=20 >=20 > I'm currently running r277858 and haven't tried the patch, yet. But will > do now and report back. >=20 So now I have a new sysctl hw.dri.0.i915_backlight. But no matter what value I pass to it, the brightness doesn't change. It's a Ivy Brigde notebook where drm shows some errors in dmesg. Please see: http://pastie.org/9877917 --tjOMJDssiV0CZSJH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUzfvxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1th8MH/j/ll532EWkGPuJ+A4fMIs3z rD7kyFhdtFKnBeNBf1W43aFhWu8FHYpJGv4pjd57EtHfrUFeepO+temxIQ5RSHnn LkvG3UQr/2FBqTa0wf03+xYXexxoFARu7aBmJjzRAJaU4oJ+l2wc46K7L+8CNZYw Bpf19qSq7thjaUbby5sRfz8WlUbL9nhEdAsYce0zKU/ZmhJoB6qeXf0Ny1g5bNqP y61GzSMIwBqYzrvLRzQYEIUmwuLskg6fsyCui+69zuX4t7FHSH72/33Sh26RSbeM TcLfnNtnoxTNbBMgitjVeKF3mlPLWAioUjtZ/fw7J+PyNZXXrmIhrpHU1zmZBPE= =cKMF -----END PGP SIGNATURE----- --tjOMJDssiV0CZSJH-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 10:20:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A244378 for ; Sun, 1 Feb 2015 10:20:32 +0000 (UTC) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) (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 547AD1E1 for ; Sun, 1 Feb 2015 10:20:31 +0000 (UTC) Received: from [46.164.154.106] (helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpa (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YHrdi-00048I-PZ; Sun, 01 Feb 2015 12:20:26 +0200 Message-ID: <54CDFDEA.2010209@shurik.kiev.ua> Date: Sun, 01 Feb 2015 12:20:26 +0200 From: Alexandr Krivulya User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Lars Engels , Andrew Wilcox , 'freebsd-current' Subject: Re: drm2 regression: backlight adjustment on ivybridge no longer works References: <009501d03acb$4f380d70$eda82850$@Wilcox-Tech.com> <54CA7949.6060202@shurik.kiev.ua> <20150201091821.GN41565@e-new.0x20.net> <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> <20150201094124.GO41565@e-new.0x20.net> <20150201101201.GP41565@e-new.0x20.net> In-Reply-To: <20150201101201.GP41565@e-new.0x20.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 46.164.154.106 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-SA-Exim-Scanned: No (on graal.it-profi.org.ua); SAEximRunCond expanded to false 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, 01 Feb 2015 10:20:32 -0000 01.02.2015 12:12, Lars Engels пишет: > On Sun, Feb 01, 2015 at 10:41:25AM +0100, Lars Engels wrote: >> On Sun, Feb 01, 2015 at 03:35:15AM -0600, Andrew Wilcox wrote: >>> Lars Engels sent: 01 February 2015 03:18: >>>> With acpi_video I get some interesting sysctl: >>>> hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >>>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 >>>> 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 >>>> 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 >>>> 88 89 90 91 92 93 94 95 96 97 98 99 100 >>>> >>>> I guess it should not be 100 100 0 ... 100? >>> Actually, the "standard" internal ACPI brightness level struct (BRTN in the DSDT) is laid out as: >>> >>> * "Full power" value (one byte, the value at which the brightness should be set on AC by default) >>> * "Economy" value (one byte, the value at which the brightness should be set on battery by default) >>> * Actual values (N bytes, up to Max but frequently not) >>> >>> So, no, that value indeed sounds correct. On my laptop the value is: >>> 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 >> Thank you for the explanation. >> FWIW, here is the full output from sysctl hw.acpi.video.lcd0: >> >> hw.acpi.video.lcd0.active: 1 >> hw.acpi.video.lcd0.brightness: 11 >> hw.acpi.video.lcd0.fullpower: 100 >> hw.acpi.video.lcd0.economy: 100 >> hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 >> 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 >> 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 >> 88 89 90 91 92 93 94 95 96 97 98 99 100 >> hw.acpi.video.crt0.active: 1 >> hw.acpi.video.ext0.active: 1 >> hw.acpi.video.ext1.active: 1 >> hw.acpi.video.ext2.active: 1 >> hw.acpi.video.ext3.active: 1 >> hw.acpi.video.ext4.active: 1 >> hw.acpi.video.ext5.active: 1 >> >>> What revision of -CURRENT are you running? What is the outcome of >>> trying the patch posted Saturday morning (UTC) from Elizabeth Myers >>> (message ID <54CC5311.9070604@interlinked.me>)? >>> >> I'm currently running r277858 and haven't tried the patch, yet. But will >> do now and report back. >> > So now I have a new sysctl hw.dri.0.i915_backlight. But no matter what > value I pass to it, the brightness doesn't change. > > It's a Ivy Brigde notebook where drm shows some errors in dmesg. Please > see: http://pastie.org/9877917 > > Please try to boot with acpi_ibm and without acpi_video. This way all works for me. From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 10:23:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE8641A9 for ; Sun, 1 Feb 2015 10:23:52 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 5D4ED1FA for ; Sun, 1 Feb 2015 10:23:51 +0000 (UTC) Received: from [IPV6:2001:67c:1810:f0ff:fd75:299c:2c8a:4c28] (unknown [IPv6:2001:67c:1810:f0ff:fd75:299c:2c8a:4c28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPSA id BE98B6A6064; Sun, 1 Feb 2015 11:23:49 +0100 (CET) User-Agent: Kaiten Mail In-Reply-To: <54CDFDEA.2010209@shurik.kiev.ua> References: <009501d03acb$4f380d70$eda82850$@Wilcox-Tech.com> <54CA7949.6060202@shurik.kiev.ua> <20150201091821.GN41565@e-new.0x20.net> <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> <20150201094124.GO41565@e-new.0x20.net> <20150201101201.GP41565@e-new.0x20.net> <54CDFDEA.2010209@shurik.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: drm2 regression: backlight adjustment on ivybridge no longer works From: Lars Engels Date: Sun, 01 Feb 2015 11:23:47 +0100 To: Alexandr Krivulya , Andrew Wilcox , 'freebsd-current' Message-ID: <3bafb094-e87c-4c3b-adfe-a36f1cf89302@email.android.com> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 10:23:53 -0000 On 1. Februar 2015 11:20:26 MEZ, Alexandr Krivulya wrote: >01.02.2015 12:12, Lars Engels пишет: >> On Sun, Feb 01, 2015 at 10:41:25AM +0100, Lars Engels wrote: >>> On Sun, Feb 01, 2015 at 03:35:15AM -0600, Andrew Wilcox wrote: >>>> Lars Engels sent: 01 February 2015 03:18: >>>>> With acpi_video I get some interesting sysctl: >>>>> hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 >14 15 >>>>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 >38 39 >>>>> 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 >62 63 >>>>> 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 >86 87 >>>>> 88 89 90 91 92 93 94 95 96 97 98 99 100 >>>>> >>>>> I guess it should not be 100 100 0 ... 100? >>>> Actually, the "standard" internal ACPI brightness level struct >(BRTN in the DSDT) is laid out as: >>>> >>>> * "Full power" value (one byte, the value at which the brightness >should be set on AC by default) >>>> * "Economy" value (one byte, the value at which the brightness >should be set on battery by default) >>>> * Actual values (N bytes, up to Max but frequently not) >>>> >>>> So, no, that value indeed sounds correct. On my laptop the value >is: >>>> 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 >>> Thank you for the explanation. >>> FWIW, here is the full output from sysctl hw.acpi.video.lcd0: >>> >>> hw.acpi.video.lcd0.active: 1 >>> hw.acpi.video.lcd0.brightness: 11 >>> hw.acpi.video.lcd0.fullpower: 100 >>> hw.acpi.video.lcd0.economy: 100 >>> hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 >14 15 >>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 >39 >>> 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 >63 >>> 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 >87 >>> 88 89 90 91 92 93 94 95 96 97 98 99 100 >>> hw.acpi.video.crt0.active: 1 >>> hw.acpi.video.ext0.active: 1 >>> hw.acpi.video.ext1.active: 1 >>> hw.acpi.video.ext2.active: 1 >>> hw.acpi.video.ext3.active: 1 >>> hw.acpi.video.ext4.active: 1 >>> hw.acpi.video.ext5.active: 1 >>> >>>> What revision of -CURRENT are you running? What is the outcome of >>>> trying the patch posted Saturday morning (UTC) from Elizabeth Myers >>>> (message ID <54CC5311.9070604@interlinked.me>)? >>>> >>> I'm currently running r277858 and haven't tried the patch, yet. But >will >>> do now and report back. >>> >> So now I have a new sysctl hw.dri.0.i915_backlight. But no matter >what >> value I pass to it, the brightness doesn't change. >> >> It's a Ivy Brigde notebook where drm shows some errors in dmesg. >Please >> see: http://pastie.org/9877917 >> >> > >Please try to boot with acpi_ibm and without acpi_video. This way all >works for me. That‘s already what I do. Also tried it with acpi_video without luck. From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 14:47:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 969F2A82; Sun, 1 Feb 2015 14:47:56 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54A9ED1E; Sun, 1 Feb 2015 14:47:56 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id a13so12943979igq.0; Sun, 01 Feb 2015 06:47:55 -0800 (PST) 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=E7Hm/P0MbbxIhVFNk939yyRW5oiixwf8CiryAh/OEAw=; b=KCeCTv8LuZ8PG3e6PeOqHn1BvdpTonCkDoTxFvoXYvyPsXC47+kqRdpj2i560rHNUS rENu8d9P6n3uX1rhbJcpS1MP2DvUeZiRof/ojMlnqPq4w3xPTLreJ1OOdpPyY/X8Ck/M OMJPp9vwfq9KtZl1KSPXcnOi9rMBSJAdVPploWmvYXE5s/5zPxumlCDyEAIzWAeU0SnW qPTs4zuzth8nCVltuZkiwMudxyKnxJSxYo8NDWFTKIPP+K1U122EZVasHOu32m0mIcLC c2VWMWwQagKqX6fihIbBSWNqNb3xPyIO4UH0XkCxqtJaM4MW+TcyxmWyGeN2ZyfZt5rX F2IA== X-Received: by 10.50.142.38 with SMTP id rt6mr7097212igb.39.1422802075840; Sun, 01 Feb 2015 06:47:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.236.106 with HTTP; Sun, 1 Feb 2015 06:47:35 -0800 (PST) In-Reply-To: <54CD555E.9060101@shurik.kiev.ua> References: <54C883E7.4000300@interlinked.me> <54CC57CE.2080001@interlinked.me> <54CC7288.3040409@interlinked.me> <54CC8FF7.4020507@interlinked.me> <54CD555E.9060101@shurik.kiev.ua> From: Miguel Clara Date: Sun, 1 Feb 2015 14:47:35 +0000 Message-ID: Subject: Re: Questions on adding backlight support for the i915 driver To: Alexandr Krivulya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , freebsd-current , Konstantin Belousov , Justin Hibbits , Elizabeth Myers 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, 01 Feb 2015 14:47:56 -0000 On Sat, Jan 31, 2015 at 10:21 PM, Alexandr Krivulya wrote: > 31.01.2015 10:30, Miguel Clara =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Sat, Jan 31, 2015 at 8:19 AM, Elizabeth Myers < > elizabeth@interlinked.me> > > wrote: > > > >> On 01/31/15 02:15, Miguel Clara wrote: > >>> Working fine on a HP running current as I've noted in the other threa= d > >>> as for the keys. > >>> This one (and most HP Pavillion models) use the Fn+F(2/3) but the key= s, > >>> and my Acer (and I think not all are like this) use "Fn+<-/->" > >> If your keys work (as in, they do things in FreeBSD), does sysctl and > >> the keys work together just fine with no weird effects? > >> > >> The only weird problem I could possibly think of that could come up is > >> that the keys do a simple add/subtract to the PCM values, and so the > >> brightness ends up wrong. See if that happens. > >> > >> > > Well, in the HP the keys don't do nothing it seems not even "xev" repor= ts > > anything when I use them, but they could be wrongly mapped maybe... > > > > On the acer I do see keycodes from xev, but Im using lumina and If I tr= y > to > > map them to anything it doesn't work... I'll see what happens after > reboot > > though. > > > > > All works fine (sysctl and Fn-keys) on my Thinkpad E530 with IvyBridge! > I my case it seems the issue wih the keys is that FreeBSD doesn't really "know about them". In the Acer laptop, it compiled and installed fine, and after reboot the sysctl works awesome, but I add to map the keycodes in fluxbox: None 239 :Exec intel_backlight decr None 123 :Exec intel_backlight incr I use the intel_backlight program still cause its easier to send the "decr" and "incr". From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 14:49:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87074B85; Sun, 1 Feb 2015 14:49:10 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 439D0D2C; Sun, 1 Feb 2015 14:49:10 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id l13so12078872iga.0; Sun, 01 Feb 2015 06:49:09 -0800 (PST) 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=S2CTWcvncS8rZY7aPmdyp4xuBhBTAyql4IXyfg1KiY8=; b=wGdnXGC1qicltNCVQk3i+4lmWKmx+nWBxiCJ/LB82b2tyaoMnPUzi5Io+c4nGhVogD l5Nq4IgsSb6xVr0Zod6N5d95pJ7sJhorz0NCDu7Y/L8o6xqq/QsHAKpMEobZTSCGs4lV //LDT0t41FfJakptqTZ3SDbtlDdHihK+MiwClm1bSsVGtn6usvplKonvn5/Lpqb71L7E EvniUCX38mleXUnexgnp21eJKfsDkd/GVI/Qm48Z84P2Nu7QPeUSKQ6hxwQ6nWoI3Qxg a4M6S1brkBmR4RnDummhdLp02HLzHRL/V2MBSVLBELeGNSebl3GNQTEgeUcHq+QbvV4N PN8Q== X-Received: by 10.50.108.108 with SMTP id hj12mr6979584igb.47.1422802149743; Sun, 01 Feb 2015 06:49:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.236.106 with HTTP; Sun, 1 Feb 2015 06:48:49 -0800 (PST) In-Reply-To: References: <54C883E7.4000300@interlinked.me> <54CC57CE.2080001@interlinked.me> <54CC7288.3040409@interlinked.me> <54CC8FF7.4020507@interlinked.me> <54CD555E.9060101@shurik.kiev.ua> From: Miguel Clara Date: Sun, 1 Feb 2015 14:48:49 +0000 Message-ID: Subject: Re: Questions on adding backlight support for the i915 driver To: Alexandr Krivulya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , freebsd-current , Konstantin Belousov , Justin Hibbits , Elizabeth Myers 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, 01 Feb 2015 14:49:10 -0000 On Sun, Feb 1, 2015 at 2:47 PM, Miguel Clara wrote= : > > On Sat, Jan 31, 2015 at 10:21 PM, Alexandr Krivulya < > shuriku@shurik.kiev.ua> wrote: > >> 31.01.2015 10:30, Miguel Clara =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> > On Sat, Jan 31, 2015 at 8:19 AM, Elizabeth Myers < >> elizabeth@interlinked.me> >> > wrote: >> > >> >> On 01/31/15 02:15, Miguel Clara wrote: >> >>> Working fine on a HP running current as I've noted in the other thre= ad >> >>> as for the keys. >> >>> This one (and most HP Pavillion models) use the Fn+F(2/3) but the >> keys, >> >>> and my Acer (and I think not all are like this) use "Fn+<-/->" >> >> If your keys work (as in, they do things in FreeBSD), does sysctl and >> >> the keys work together just fine with no weird effects? >> >> >> >> The only weird problem I could possibly think of that could come up i= s >> >> that the keys do a simple add/subtract to the PCM values, and so the >> >> brightness ends up wrong. See if that happens. >> >> >> >> >> > Well, in the HP the keys don't do nothing it seems not even "xev" >> reports >> > anything when I use them, but they could be wrongly mapped maybe... >> > >> > On the acer I do see keycodes from xev, but Im using lumina and If I >> try to >> > map them to anything it doesn't work... I'll see what happens after >> reboot >> > though. >> > >> > >> All works fine (sysctl and Fn-keys) on my Thinkpad E530 with IvyBridge! >> > > I my case it seems the issue wih the keys is that FreeBSD doesn't really > "know about them". > > In the Acer laptop, it compiled and installed fine, and after reboot the > sysctl works awesome, but I add to map the keycodes in fluxbox: > None 239 :Exec intel_backlight decr > None 123 :Exec intel_backlight incr > > I use the intel_backlight program still cause its easier to send the > "decr" and "incr". > > Forgot to add The acer is running FreeBSD 10 (stable/10) so eventually this could be merged! From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 20:13:39 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62D3E453 for ; Sun, 1 Feb 2015 20:13:39 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 2211FE66 for ; Sun, 1 Feb 2015 20:13:37 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id DA9593B8B7; Sun, 1 Feb 2015 20:13:30 +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 t11KDTf5001873; Sun, 1 Feb 2015 20:13:30 GMT (envelope-from phk@phk.freebsd.dk) To: Marcin Cieslak Subject: Re: Bug-report of sorts... In-reply-to: From: "Poul-Henning Kamp" References: <2533.1422656690@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1871.1422821609.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 01 Feb 2015 20:13:29 +0000 Message-ID: <1872.1422821609@critter.freebsd.dk> Cc: 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, 01 Feb 2015 20:13:39 -0000 -------- In message , Marcin Cies= lak w rites: >On Fri, 30 Jan 2015, Poul-Henning Kamp wrote: > >> But the point is I never get to the webpage, local_unbound just doesn't >> seem to be able to resolve anything through the DHCP appointed server, >> despite the fact that dig(1) does so just fine. So I finally had a chance to dig into this. Commenting out the root.key fil in unbound.conf did it, with it unbound seems to insist on validating the rootkey and to do nothing else until that happens. The DNS server in the meantime ignores DNSKEY queries... -- = 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 Sun Feb 1 20:23:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 804568D6 for ; Sun, 1 Feb 2015 20:23:04 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e: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 4D9A5F6F for ; Sun, 1 Feb 2015 20:23:04 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id fb1so73774244pad.10 for ; Sun, 01 Feb 2015 12:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=8d1eu1GQtmCTBXw2p1cIkB+/Y4DsFwsudoQ+vss2oSI=; b=Rxc+g7M5F0pko9VAhauTuqN4M5cPxGF3NJqNEMqB1kwwJ2BluPlYo5L6DRdmf4HDUS Px5j4Q9tTu494rC+dK+0+tMjEjeKx3yAl2+lKLbXBIr26bvkM/tbs6ApsJLNWHgMLmk2 XpHGo8uBpj1Hp65ZH4xE7mTEx93BIM3xGqfH63UbYeMQmNuKsPfdx1Xo/0A1akCDR8Zh WwUi3lfJi0p8yG2NqhDh3+yEWUPBvrplZVA5a101aCmjSdRutsPFMyMHTvKz/g6+p81X S5wRVaVYBxrr+N1qFEo7gof/lLZt2TYa6MOVbo9X9S72tayuvqrkrdO5pu02Ii98vElj K5ig== X-Received: by 10.70.10.100 with SMTP id h4mr24742450pdb.10.1422822183423; Sun, 01 Feb 2015 12:23:03 -0800 (PST) Received: from localhost (c-76-21-76-83.hsd1.ca.comcast.net. [76.21.76.83]) by mx.google.com with ESMTPSA id om9sm16717085pbb.34.2015.02.01.12.23.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 12:23:02 -0800 (PST) Sender: Gleb Kurtsou Date: Sun, 1 Feb 2015 12:24:13 -0800 From: Gleb Kurtsou To: freebsd-current@freebsd.org Subject: libc.so dependency on libssp_nonshared.a Message-ID: <20150201202413.GA2132@reks> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 20:23:04 -0000 I came across some build issues in libc.so and SSP. libc.ldscript (aka libc.so) unconditionally includes @@LIBDIR@@/libssp_nonshared.a libssp* are not built if WITHOUT_SSP defined. ObsoleteFiles.inc doesn't mention libssp*. Consider WITHOUT_SSP=yes case. As soon as one does clean installworld and/or removes stale libssp_nonshared.a ld fails to link anything because of missing libssp_nonshared.a libc.so during buildworld (as found under /usr/obj) is symlink to the actual shared library, but not ldscript. Is it intentional? I wouldn't expect make -C /usr/src/bin/cat to match buildworld result closely assuming src and world are in sync, but they seem to have different idea of what libc is.. From owner-freebsd-current@FreeBSD.ORG Sun Feb 1 20:52:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D636242; Sun, 1 Feb 2015 20:52:49 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2C5D27E; Sun, 1 Feb 2015 20:52:48 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id bs8so12865837wib.3; Sun, 01 Feb 2015 12:52:47 -0800 (PST) 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=x10NE3sP+Jheh8gW/A2BFTdD21ezekrJO3UcGq451Gw=; b=ITOW+dna9xoQJqBAIoubsX3SMbONFUR3Bj1Ke6VvEaC/9ojEvhG/60yeI8oDT5arjq yta3SiYZsNsPFppZ4PnbRgf2iidbYNZHOAGA2sfjcnzKr8E5pqtUTk4F6m71wvyw9mDK vBZh9WinqsLkEOqCNH4cuXiDddPeP2qsg+LOUBsjcoTPjDxHLnGlFEq5wpHvJMQAHjRc JoVufvuRc9QhTEg/ZoL1J7OwCDEXCi+yKaGoTIYLXCnNVG3+IDOJdCsJVWn78ky8jQOb KJOYMCbCLC+O7CZ0eqaiqGlSFQNDZ0VA1Iu8K3jLYp0NQRJ672TXtRH/rN87ZAVgspGV dPQQ== MIME-Version: 1.0 X-Received: by 10.194.61.145 with SMTP id p17mr36223880wjr.35.1422823967354; Sun, 01 Feb 2015 12:52:47 -0800 (PST) Received: by 10.217.64.10 with HTTP; Sun, 1 Feb 2015 12:52:47 -0800 (PST) In-Reply-To: <54CC5311.9070604@interlinked.me> References: <54C883E7.4000300@interlinked.me> <54CBA0A4.30708@FreeBSD.org> <54CC0999.90500@interlinked.me> <3595567.zVLW9tlg0N@ralph.baldwin.cx> <54CC2981.3040909@interlinked.me> <54CC5311.9070604@interlinked.me> Date: Sun, 1 Feb 2015 21:52:47 +0100 Message-ID: Subject: Re: Questions on adding backlight support for the i915 driver From: "Ranjan1018 ." <214748mv@gmail.com> To: Elizabeth Myers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 20:52:49 -0000 > I have a sort of "rough draft" of this. I've tested all the percentages > (Ivy Bridge) and they do seem to correlate linearly (and to the > intel_backlight userland program used by a lot of people). I haven't > been able to test on any other hardware as I don't have it, and I don't > know what chipsets require the value to be inverted, so I've not > implemented that. > > If anyone else would like to help test, it'd be nice. > > Thank you Elizabeth for the patch. It works on my Samsung Ativ Book 2 with Ivy Bridge. I have modified the patch for 11-CURRENT and corrected these little bugs: 1) is possible to specify a percentage greater than 100% eg. with the command: =E2=80=98sysctl hw.dri.0.i915_backlight=3D111=E2=80= =99 is possible to set the hardware register above the maximum allowed. 2) the percentage values are truncated instead of rounded: if I set 10% with the intel_backlight program is reported as 9% with the command =E2=80=98sysctl hw.dri.0.i915_backlight=E2=80=99: # intel_backlight 10 current backlight value: 20% (976/4882) set backlight to 10% (488/4882) # sysctl hw.dri.0.i915_backlight hw.dri.0.i915_backlight: 9 but 488/4882 is more near to 10% than 9% I have tested the patch with: # uname -a FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r277961: Sat Jan 31 06:03:15 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC amd64 The patch is available at: http://pastebin.com/vKK7026H Regards, Maurizio From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 02:38:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3F0DE7A for ; Mon, 2 Feb 2015 02:38:44 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id B40418CB for ; Mon, 2 Feb 2015 02:38:43 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C779F3572D for ; Sun, 1 Feb 2015 21:38:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Wle0+J1Oak9g AVYTkamD+gSpG14=; b=BUVZFdlOMo5VAkdhdsioLSM0smykBcG+PGQaEE8783Dj 62GDubLFHDyy7VahebtnKCekxcs5tVOQXezggHz6lB6n/0B8msNyTZuDbyKWa/Hn LdDTkTeDI+/u/rP6NOIonwL1gaTwLH6BcWLfL2yeVEH4T0rU2GcfhkSLnaBtYnY= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id BDBF93572A for ; Sun, 1 Feb 2015 21:38:37 -0500 (EST) Received: from [192.168.1.103] (unknown [73.164.1.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 5AAE435729 for ; Sun, 1 Feb 2015 21:38:36 -0500 (EST) Message-ID: <54CEE325.4040903@badgerio.us> Date: Sun, 01 Feb 2015 20:38:29 -0600 From: Eric Badger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Filepaths in VM map for tmpfs files References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> In-Reply-To: <20150131153621.GH42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9706C262-AA84-11E4-BC6A-7BA29F42C9D4-46178211!pb-smtp1.pobox.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 02:38:45 -0000 On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; I'd opine that it is better to be transparent than make it look like there is an OBJT_VNODE object there. It may be that some programs would be confused by VNODE info returned on a SWAP type mapping, though I know that dtrace handles it OK. > Second, note that it is possible that the vnode is recycled, so > OBJ_TMPFS flag is cleared for tmpfs swap object. The OBJ_TMPFS_NODE > flag is still set then. I am not sure what to do in this case, > should the type changed to KVME_TYPE_VNODE still, but kve_vn_* > fields left invalid ? I think if we changed to KVME_TYPE_VNODE in some cases, it should be done in all cases, even if the vnode has been recycled (but leave vp == NULL in that case). Though if it is left as KVME_TYPE_SWAP, then that concern goes away on its own. Eric From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 04:24:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 392C4A06 for ; Mon, 2 Feb 2015 04:24:42 +0000 (UTC) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.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 EEBA464A for ; Mon, 2 Feb 2015 04:24:41 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id l6so28563295qcy.13 for ; Sun, 01 Feb 2015 20:24:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=k2kWwMR1/gr/qM4gDYm4+xG0nyVfyWNY/h2FNM4PkkE=; b=RVVgzUFxL0ej8w3k++GyMaDGnrKBihnE3UlcDL+e1/6WBQfIsY/nW1gCHmN+cqD6PZ pKvuzuDElmDr8YzU6dDoawiwXRh3a+jhWCv6zIL28IuZh14ZeO6NjA68Tdt8S6juGZ5a zUp/qLMwFZPUuOJr3CayxX0/7GZn58Ko0tC/ao4VVKmeVhzEBHzbmA56CiEwGilOW3uz 3767IPA216fDlpktJ9I5vKdfSkJQXGa8NOWULpKlwiIJJbj1BLoDAayUKS1c6fTRbVut eI96dVsSZ+FWTavAsyefog96LK+8ReVwsh9aDxJ7RbIJbrLRmIo6avAVzzhqkQtzWn17 ubyg== X-Gm-Message-State: ALoCoQkHeT/3OahE44HIdqWPCqATnX2hUrCwzf4rRlLfpwjVaMUfReTOgoaIuwou/0RVD2wCNUnBoN3TuGT/a6Qb52kwfY7OEBOHL2EH1TllMM780/RWS2btnibh0Caifpj2kX/6PTzv X-Received: by 10.224.28.198 with SMTP id n6mr37792042qac.15.1422851073940; Sun, 01 Feb 2015 20:24:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Sun, 1 Feb 2015 20:24:18 -0800 (PST) From: "Lundberg, Johannes" Date: Mon, 2 Feb 2015 13:24:18 +0900 Message-ID: Subject: TI WiLink 6.0 (WL1271) To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 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: Mon, 02 Feb 2015 04:24:42 -0000 SGkNCg0KRG9lcyBhbnlvbmUgd2l0aCBpbnNpZ2h0cyBpbnRvIHRoZSBXaUZpIHdvcmxkIGtub3cg dGhlIHBvcnRpbmcgc3RhdHVzIG9mDQp0aGlzIGRyaXZlcj8NClRoZXJlIHNlZW0gdG8gYmUgYSBM aW51eCBkcml2ZXIgYXZhaWxhYmxlLiBXaGF0IGtpbmQgb2YgcHJvYmxlbXMgd291bGQgd2UNCmZh Y2UgZm9yIGNyZWF0aW5nIGEgRnJlZUJTRCBkcml2ZXI/IElzIGl0IGp1c3QgYSBtYXR0ZXIgb2Yg c29tZW9uZSBzaXR0aW5nDQpkb3duIGRvaW5nIGl0IG9yIGFyZSB0aGVyZSBhbnkgb3RoZXIgb2Jz dGFjbGVzPw0KDQpUaGFua3MhDQotLQ0KSm9oYW5uZXMgTHVuZGJlcmcNCgotLSAKPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tCuenmOWvhuS/neaM geOBq+OBpOOBhOOBpu+8muOBk+OBrumbu+WtkOODoeODvOODq+OBr+OAgeWQjeWum+S6uuOBq+mA geS/oeOBl+OBn+OCguOBruOBp+OBguOCiuOAgeenmOWMv+eJueaoqeOBruWvvuixoeOBqOOBquOC i+aDheWgseOCkuWQq+OCk+OBp+OBhOOBvuOBmeOAggrjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbj ga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/loLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4Tj gIHjgYrjgojjgbPjgZPjga7jg6Hjg7zjg6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIEK 6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW44Gu5Yip55So44CB44G+44Gf44Gv6KiY6LyJ5YaF 5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL6KGM5YuV44KC44GV44KM44Gq44GE44KI44GG44GK 6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CCCi0tLQpDT05GSURFTlRJQUxJVFkgTk9URTogVGhl IGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMgY29uZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuCkRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlv biBvciBhbnkgb3RoZXIgYWN0aW9uIG9mIHVzZSBvZiB0aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhl ciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwgaXMgcHJvaGliaXRlZC4KSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVy cm9yLCBwbGVhc2UgZGVzdHJveSB0aGUgb3JpZ2luYWwgbWVzc2FnZS4K From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 05:00:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE0F23EF for ; Mon, 2 Feb 2015 05:00:21 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 B46BC96A for ; Mon, 2 Feb 2015 05:00:21 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id ar1so15251027iec.6 for ; Sun, 01 Feb 2015 21:00:21 -0800 (PST) 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=maf83EgMkj3BNV3bvAa32mmWh9S+WT4aEPJ7CDR+Dcg=; b=wnSEpi+x/CGbLi2ecs32jHVDUszjBkQe22glNDPMnZmwNu3pw5t3VVtyReX5hSW/vI ELkmnDmV27hEEBRw7oz4krIPymrPWdJW+2JenvrBRx/PvE4rIkw8Z+XASis4+69f2vNS aBh0IRpDDGnHIRsUgLKX9IVXtIiDyZso97EcowOxrJhJ8U7grazdzgnOmfukPTc2BLnZ kRjVD2GqqUvTigrHVCRuKsSPJ36x/moPknG0Esn7kPPdpe5yoG1+PZBy3aLYQBZXLCbU 36b0FxeXJkCZTE9rwKeDokwMGp40bCw5qu7USEzXKzJGr0Gg8/ZKSCnyLzmPxBr6aBrP 7sqQ== MIME-Version: 1.0 X-Received: by 10.42.54.5 with SMTP id p5mr17100602icg.37.1422853215714; Sun, 01 Feb 2015 21:00:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Sun, 1 Feb 2015 21:00:15 -0800 (PST) In-Reply-To: References: Date: Sun, 1 Feb 2015 21:00:15 -0800 X-Google-Sender-Auth: _7Ralr97sbt9oTessNyXZ7kbjHk Message-ID: Subject: Re: TI WiLink 6.0 (WL1271) From: Adrian Chadd To: "Lundberg, Johannes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 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: Mon, 02 Feb 2015 05:00:22 -0000 SGksDQoNCll1cCwgc29tZW9uZSBoYXMgdG8gcG9ydCB0aGUgZHJpdmVyIGFuZCBidXMgZnJhbWV3 b3JrLg0KDQoNCg0KLWFkcmlhbg0KDQoNCk9uIDEgRmVicnVhcnkgMjAxNSBhdCAyMDoyNCwgTHVu ZGJlcmcsIEpvaGFubmVzDQo8am9oYW5uZXNAYnJpbGxpYW50c2VydmljZS5jby5qcD4gd3JvdGU6 DQo+IEhpDQo+DQo+IERvZXMgYW55b25lIHdpdGggaW5zaWdodHMgaW50byB0aGUgV2lGaSB3b3Js ZCBrbm93IHRoZSBwb3J0aW5nIHN0YXR1cyBvZg0KPiB0aGlzIGRyaXZlcj8NCj4gVGhlcmUgc2Vl bSB0byBiZSBhIExpbnV4IGRyaXZlciBhdmFpbGFibGUuIFdoYXQga2luZCBvZiBwcm9ibGVtcyB3 b3VsZCB3ZQ0KPiBmYWNlIGZvciBjcmVhdGluZyBhIEZyZWVCU0QgZHJpdmVyPyBJcyBpdCBqdXN0 IGEgbWF0dGVyIG9mIHNvbWVvbmUgc2l0dGluZw0KPiBkb3duIGRvaW5nIGl0IG9yIGFyZSB0aGVy ZSBhbnkgb3RoZXIgb2JzdGFjbGVzPw0KPg0KPiBUaGFua3MhDQo+IC0tDQo+IEpvaGFubmVzIEx1 bmRiZXJnDQo+DQo+IC0tDQo+ID0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LQ0KPiDnp5jlr4bkv53mjIHjgavjgaTjgYTjgabvvJrjgZPjga7pm7vl rZDjg6Hjg7zjg6vjga/jgIHlkI3lrpvkurrjgavpgIHkv6HjgZfjgZ/jgoLjga7jgafjgYLjgorj gIHnp5jljL/nibnmqKnjga7lr77osaHjgajjgarjgovmg4XloLHjgpLlkKvjgpPjgafjgYTjgb7j gZnjgIINCj4g44KC44GX44CB5ZCN5a6b5Lq65Lul5aSW44Gu5pa544GM5Y+X5L+h44GV44KM44Gf 5aC05ZCI44CB44GT44Gu44Oh44O844Or44Gu56C05qOE44CB44GK44KI44Gz44GT44Gu44Oh44O8 44Or44Gr6Zai44GZ44KL5LiA5YiH44Gu6ZaL56S644CBDQo+IOikh+WGmeOAgemFjeW4g+OAgeOB neOBruS7luOBruWIqeeUqOOAgeOBvuOBn+OBr+iomOi8ieWGheWuueOBq+WfuuOBpeOBj+OBhOOB i+OBquOCi+ihjOWLleOCguOBleOCjOOBquOBhOOCiOOBhuOBiumhmOOBhOeUs+OBl+S4iuOBkuOB vuOBmeOAgg0KPiAtLS0NCj4gQ09ORklERU5USUFMSVRZIE5PVEU6IFRoZSBpbmZvcm1hdGlvbiBp biB0aGlzIGVtYWlsIGlzIGNvbmZpZGVudGlhbA0KPiBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgYWRkcmVzc2VlLg0KPiBEaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgYW55 IG90aGVyIGFjdGlvbiBvZiB1c2Ugb2YgdGhpcw0KPiBlbWFpbCBieSBwZXJzb24gb3RoZXIgdGhh biBpbnRlbmRlZCByZWNpcGllbnQsIGlzIHByb2hpYml0ZWQuDQo+IElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgYW5kIGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbg0KPiBl cnJvciwgcGxlYXNlIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGZyZWVic2QtY3VycmVudEBm cmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxt YW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50DQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBt YWlsIHRvICJmcmVlYnNkLWN1cnJlbnQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo= From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 05:33:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B917EFF; Mon, 2 Feb 2015 05:33:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 4A41BCEA; Mon, 2 Feb 2015 05:33:30 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B5FCF506; Mon, 2 Feb 2015 05:33:30 +0000 (UTC) Date: Mon, 2 Feb 2015 05:33:30 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <1203660337.33.1422855210717.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <310329792.32.1422853293343.JavaMail.jenkins@jenkins-9.freebsd.org> References: <310329792.32.1422853293343.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1014 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 05:33:30 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#662 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision a270e9097d7c7f1630d3cdd922ab6a496f7bb4ab (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f a270e9097d7c7f1630d3cdd922ab6a496f7bb4ab > git rev-list a270e9097d7c7f1630d3cdd922ab6a496f7bb4ab # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson3888297789722542382.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.0m7Hg6lS progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.0m7Hg6lS cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.0m7Hg6lS/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.0m7Hg6lS LD_LIBRARY_PATH=3D/tmp/install.0m7Hg6lS PATH_LOCALE=3D/tmp= /install.0m7Hg6lS/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.0m7Hg6lS/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.0m7Hg6lS LD_LIBRARY_PATH=3D/tmp/install.0m7Hg6lS PATH_LOCALE=3D/t= mp/install.0m7Hg6lS/locale rm -rf /tmp/install.0m7Hg6lS make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 06:32:03 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 751B2901 for ; Mon, 2 Feb 2015 06:32:03 +0000 (UTC) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.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 3292F278 for ; Mon, 2 Feb 2015 06:32:02 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id p6so28788319qcv.8 for ; Sun, 01 Feb 2015 22:32:01 -0800 (PST) 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=1de6cVpej88ezfMAQLVozAbVB9Pi1/X2Fsp4ExtNZ/4=; b=WEPQ+WuJJMrgxbqcSdYXdoNs6sYo62OFZsU0aX9fBC9HPEQF4yEhzgx0/mc8peoLhk gEJyZDL79ocpjJiWEP2SHNRo4eRc15KfNQllV5Ir05Luc9YJhOnUIm7yIOxdoTz/8CoT oSeMsq8LDIDFzE5CzdDsxhx9AR79wd4duaamplLNSholwOoplmVrSHyKWIGjDX+v9ScZ MKuYf5P5R5M7ZNme+eC9FC6JAlGJyLsRxEogPzjZfArfdyBDG7i8VY/Jozijmzmoq2tj qFE/Q2PTW5loPY28U6bsTappNOZfoXEAWPf5OvCo8xhxscIkYhYzRg2+BYqqvxrZYIYv THwg== X-Gm-Message-State: ALoCoQn7H3nnllQpGiHJfV+zmmMCr3bmCtQXlVYmIt75q/B27KxZYzTSGcQcdBBv24donagUyAHtGoim5Ky0wv+uXa9tH7V147mbu+jD/i6w7b3nz5vdH5H/dHBmH1iFOingb8sCrcu1 X-Received: by 10.229.25.200 with SMTP id a8mr38368494qcc.22.1422858721456; Sun, 01 Feb 2015 22:32:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Sun, 1 Feb 2015 22:31:46 -0800 (PST) In-Reply-To: References: From: "Lundberg, Johannes" Date: Mon, 2 Feb 2015 15:31:46 +0900 Message-ID: Subject: Re: TI WiLink 6.0 (WL1271) To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 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: Mon, 02 Feb 2015 06:32:03 -0000 V291bGQgeW91IGJlIGFibGUgdG8gZXN0aW1hdGUgcm91Z2hseSB0aGUgYW1vdW50IG9mIHRpbWUg bmVlZGVkPw0KDQotLQ0KSm9oYW5uZXMgTHVuZGJlcmcNCkJSSUxMSUFOVFNFUlZJQ0UgQ08uLCBM VEQuDQoNCk9uIE1vbiwgRmViIDIsIDIwMTUgYXQgMjowMCBQTSwgQWRyaWFuIENoYWRkIDxhZHJp YW5AZnJlZWJzZC5vcmc+IHdyb3RlOg0KDQo+IEhpLA0KPg0KPiBZdXAsIHNvbWVvbmUgaGFzIHRv IHBvcnQgdGhlIGRyaXZlciBhbmQgYnVzIGZyYW1ld29yay4NCj4NCj4NCj4NCj4gLWFkcmlhbg0K Pg0KPg0KPiBPbiAxIEZlYnJ1YXJ5IDIwMTUgYXQgMjA6MjQsIEx1bmRiZXJnLCBKb2hhbm5lcw0K PiA8am9oYW5uZXNAYnJpbGxpYW50c2VydmljZS5jby5qcD4gd3JvdGU6DQo+ID4gSGkNCj4gPg0K PiA+IERvZXMgYW55b25lIHdpdGggaW5zaWdodHMgaW50byB0aGUgV2lGaSB3b3JsZCBrbm93IHRo ZSBwb3J0aW5nIHN0YXR1cyBvZg0KPiA+IHRoaXMgZHJpdmVyPw0KPiA+IFRoZXJlIHNlZW0gdG8g YmUgYSBMaW51eCBkcml2ZXIgYXZhaWxhYmxlLiBXaGF0IGtpbmQgb2YgcHJvYmxlbXMgd291bGQg d2UNCj4gPiBmYWNlIGZvciBjcmVhdGluZyBhIEZyZWVCU0QgZHJpdmVyPyBJcyBpdCBqdXN0IGEg bWF0dGVyIG9mIHNvbWVvbmUNCj4gc2l0dGluZw0KPiA+IGRvd24gZG9pbmcgaXQgb3IgYXJlIHRo ZXJlIGFueSBvdGhlciBvYnN0YWNsZXM/DQo+ID4NCj4gPiBUaGFua3MhDQo+ID4gLS0NCj4gPiBK b2hhbm5lcyBMdW5kYmVyZw0KPiA+DQo+ID4gLS0NCj4gPiA9LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0NCj4gPiDnp5jlr4bkv53mjIHjgavjgaTj gYTjgabvvJrjgZPjga7pm7vlrZDjg6Hjg7zjg6vjga/jgIHlkI3lrpvkurrjgavpgIHkv6HjgZfj gZ/jgoLjga7jgafjgYLjgorjgIHnp5jljL/nibnmqKnjga7lr77osaHjgajjgarjgovmg4XloLHj gpLlkKvjgpPjgafjgYTjgb7jgZnjgIINCj4gPiDjgoLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7m lrnjgYzlj5fkv6HjgZXjgozjgZ/loLTlkIjjgIHjgZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHj gYrjgojjgbPjgZPjga7jg6Hjg7zjg6vjgavplqLjgZnjgovkuIDliIfjga7plovnpLrjgIENCj4g PiDopIflhpnjgIHphY3luIPjgIHjgZ3jga7ku5bjga7liKnnlKjjgIHjgb7jgZ/jga/oqJjovInl hoXlrrnjgavln7rjgaXjgY/jgYTjgYvjgarjgovooYzli5XjgoLjgZXjgozjgarjgYTjgojjgYbj gYrpoZjjgYTnlLPjgZfkuIrjgZLjgb7jgZnjgIINCj4gPiAtLS0NCj4gPiBDT05GSURFTlRJQUxJ VFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMgY29uZmlkZW50aWFsDQo+ ID4gYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZS4NCj4gPiBEaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgYW55IG90aGVyIGFjdGlvbiBvZiB1c2Ugb2YgdGhp cw0KPiA+IGVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwgaXMg cHJvaGliaXRlZC4NCj4gPiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGFu ZCBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4NCj4gPiBlcnJvciwgcGxlYXNlIGRlc3Ryb3kg dGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGlu ZyBsaXN0DQo+ID4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJl ZWJzZC1jdXJyZW50DQo+ID4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gIg0KPiBm cmVlYnNkLWN1cnJlbnQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo+DQoKLS0gCj0tPS09LT0t PS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LQrnp5jlr4bkv53m jIHjgavjgaTjgYTjgabvvJrjgZPjga7pm7vlrZDjg6Hjg7zjg6vjga/jgIHlkI3lrpvkurrjgavp gIHkv6HjgZfjgZ/jgoLjga7jgafjgYLjgorjgIHnp5jljL/nibnmqKnjga7lr77osaHjgajjgarj govmg4XloLHjgpLlkKvjgpPjgafjgYTjgb7jgZnjgIIK44KC44GX44CB5ZCN5a6b5Lq65Lul5aSW 44Gu5pa544GM5Y+X5L+h44GV44KM44Gf5aC05ZCI44CB44GT44Gu44Oh44O844Or44Gu56C05qOE 44CB44GK44KI44Gz44GT44Gu44Oh44O844Or44Gr6Zai44GZ44KL5LiA5YiH44Gu6ZaL56S644CB Cuikh+WGmeOAgemFjeW4g+OAgeOBneOBruS7luOBruWIqeeUqOOAgeOBvuOBn+OBr+iomOi8ieWG heWuueOBq+WfuuOBpeOBj+OBhOOBi+OBquOCi+ihjOWLleOCguOBleOCjOOBquOBhOOCiOOBhuOB iumhmOOBhOeUs+OBl+S4iuOBkuOBvuOBmeOAggotLS0KQ09ORklERU5USUFMSVRZIE5PVEU6IFRo ZSBpbmZvcm1hdGlvbiBpbiB0aGlzIGVtYWlsIGlzIGNvbmZpZGVudGlhbAphbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgYWRkcmVzc2VlLgpEaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRp b24gb3IgYW55IG90aGVyIGFjdGlvbiBvZiB1c2Ugb2YgdGhpcwplbWFpbCBieSBwZXJzb24gb3Ro ZXIgdGhhbiBpbnRlbmRlZCByZWNpcGllbnQsIGlzIHByb2hpYml0ZWQuCklmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYW5kIGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbgpl cnJvciwgcGxlYXNlIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuCg== From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 08:24:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4915051B; Mon, 2 Feb 2015 08:24:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 370CBF03; Mon, 2 Feb 2015 08:24:58 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6BED9534; Mon, 2 Feb 2015 08:24:58 +0000 (UTC) Date: Mon, 2 Feb 2015 08:24:58 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <982550113.35.1422865498413.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1999751993.34.1422863181264.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1999751993.34.1422863181264.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1016 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 08:24:58 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#663 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f > git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson5450948256060626682.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.4nPUw6vj progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.4nPUw6vj cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.4nPUw6vj/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.4nPUw6vj LD_LIBRARY_PATH=3D/tmp/install.4nPUw6vj PATH_LOCALE=3D/tmp= /install.4nPUw6vj/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.4nPUw6vj/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.4nPUw6vj LD_LIBRARY_PATH=3D/tmp/install.4nPUw6vj PATH_LOCALE=3D/t= mp/install.4nPUw6vj/locale rm -rf /tmp/install.4nPUw6vj make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 09:30:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84AEB346 for ; Mon, 2 Feb 2015 09:30:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAF35810 for ; Mon, 2 Feb 2015 09:30:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t129URem037378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 11:30:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t129URem037378 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t129URPV037377; Mon, 2 Feb 2015 11:30:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Feb 2015 11:30:27 +0200 From: Konstantin Belousov To: Eric Badger Subject: Re: Filepaths in VM map for tmpfs files Message-ID: <20150202093027.GL42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CEE325.4040903@badgerio.us> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: 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, 02 Feb 2015 09:30:42 -0000 On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: > > On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > > First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? > My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; > I'd opine that it is better to be transparent than make it look like > there is an OBJT_VNODE object there. It may be that some programs would > be confused by VNODE info returned on a SWAP type mapping, though I know > that dtrace handles it OK. kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. So this is in fact a bug in whatever used the API to access kve_path for KVE_TYPE_SWAP. > > > Second, note that it is possible that the vnode is recycled, so > > OBJ_TMPFS flag is cleared for tmpfs swap object. The OBJ_TMPFS_NODE > > flag is still set then. I am not sure what to do in this case, > > should the type changed to KVME_TYPE_VNODE still, but kve_vn_* > > fields left invalid ? > I think if we changed to KVME_TYPE_VNODE in some cases, it should be > done in all cases, even if the vnode has been recycled (but leave vp == > NULL in that case). Though if it is left as KVME_TYPE_SWAP, then that > concern goes away on its own. Concern is not vp == NULL, but the fact that kve_vn* cannot be filled, there is simply no (easy) way to fetch this information. From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 11:26:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 078E1CFA; Mon, 2 Feb 2015 11:26:16 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::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 BE348644; Mon, 2 Feb 2015 11:26:15 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id tr6so16787659ieb.2; Mon, 02 Feb 2015 03:26:15 -0800 (PST) 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=on8+KnYE8XiRMZto3IeRwDW8SsxOMB10VBYhnE9OIYM=; b=AScrljR1YpuI1TvuM6sGNuslHwGssQ5xmkc9HTi4wzGkqQOkG1VcV4rxHMfCzjFwnP KcVD3DrXjcpm99ILloB7F/u/w9MpeNU6tZ/L6MFKYdJEKDhG0xJmiuCUVQOXSDTTxEuY fCaE2iIlKxQL28DpOkOwuFT50Dlfr7sGPBCTNu2OQeWm5xi9RsvaP7eHzxQv6Nl08FRn 6SiF8WksjT3AYHkhJLUJNDN/fxnu17skJnol345/BIKI6awb1boAht+z45oBMMbKxAzl T5F8sVYLmqTtOtIhG5qw/xO+N8NOFqWf8w6wNBQqocPbR9m2ZBTkmJWw8wldvNY/LFDw Danw== X-Received: by 10.50.142.38 with SMTP id rt6mr11025991igb.39.1422876375132; Mon, 02 Feb 2015 03:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.175.4 with HTTP; Mon, 2 Feb 2015 03:25:43 -0800 (PST) In-Reply-To: References: <20150129195230.5dd7078f.ohartman@zedat.fu-berlin.de> <20150129235613.6abe495a.ohartman@zedat.fu-berlin.de> From: Jia-Shiun Li Date: Mon, 2 Feb 2015 19:25:43 +0800 Message-ID: Subject: Re: i915kms.ko: when loaded with Haswell HD4600, display goes blank To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT , "O. Hartmann" , NGie 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, 02 Feb 2015 11:26:16 -0000 On Fri, Jan 30, 2015 at 7:26 AM, Adrian Chadd wrote: > wait a sec - before the dri2 update, what exactly were you doing? What > happened when you loaded i915kms? Nothing should've been found and no > i915 driver should've been running > > There's no haswell support for i915kms, so it shouldn't have worked > /at all/. You should've just gotten either vt(4) or sc(4) + vesa as a > console, and VESA graphics. > > As a workaround, you can just not load i915kms, or patch i915kms to > not detect your haswell chipset. > Haswell device IDs were added in r277487 too. So does it mean people should start to test and report bugs regarding Haswell? -Jia-Shiun. From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 11:26:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10AD6DF8; Mon, 2 Feb 2015 11:26:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id F36E964C; Mon, 2 Feb 2015 11:26:24 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8FBE0577; Mon, 2 Feb 2015 11:26:25 +0000 (UTC) Date: Mon, 2 Feb 2015 11:26:25 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <786259643.37.1422876385563.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1761945244.36.1422874115732.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1761945244.36.1422874115732.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1018 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 11:26:25 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#664 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f > git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson5109923532021584220.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.LtIG7hfa progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.LtIG7hfa cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.LtIG7hfa/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.LtIG7hfa LD_LIBRARY_PATH=3D/tmp/install.LtIG7hfa PATH_LOCALE=3D/tmp= /install.LtIG7hfa/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.LtIG7hfa/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.LtIG7hfa LD_LIBRARY_PATH=3D/tmp/install.LtIG7hfa PATH_LOCALE=3D/t= mp/install.LtIG7hfa/locale rm -rf /tmp/install.LtIG7hfa make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 12:21:29 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ED01F5D; Mon, 2 Feb 2015 12:21:29 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c: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 2DE43C69; Mon, 2 Feb 2015 12:21:29 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id w55so33324287wes.5; Mon, 02 Feb 2015 04:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=ZbhmI9OqXr03rNHGFaGM+zFnYAXJNnSScT2iZ7dUYfg=; b=BF5UhFVR73brVRF/P2TQ+iiLsMmSu8wyeCSWqpGLZRV/oc3Wt/r+nX/Wk/Zj4R4RL8 67XuBAhjylPI9HRil+5iFBbrmpnN5FG1MfpKPdvYFLtrM8jtzQC6IisqxgkNRTEgxIuZ GuvbSh0ff4mdC/bWX+gHQcexxnmrKxGNdRMMyjtkVkGQSPdky+y59MUk/wvZRLiZz20Y iSg8fXyBNZOz5QN3SOtewwoFRCHLewH/e40gNf+MtqHjhtIJWPq0GdF8xZyLxKTdldvo XXt0q25vtmNKMqbWoGZvdLfFM2E/PikNhCGLifVybMuw1cPU4lozwrJpENRCnIPZmcpn ijWA== X-Received: by 10.194.175.202 with SMTP id cc10mr44051031wjc.27.1422879687515; Mon, 02 Feb 2015 04:21:27 -0800 (PST) Received: from MacBook-Air-de-Roger.local ([185.25.64.249]) by mx.google.com with ESMTPSA id fm10sm19630790wib.7.2015.02.02.04.21.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 04:21:26 -0800 (PST) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <54CF6BBF.9050906@FreeBSD.org> Date: Mon, 02 Feb 2015 12:21:19 +0000 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD CURRENT , hrs@FreeBSD.org Subject: [RFC] load network config file from netif init script Content-Type: multipart/mixed; boundary="------------060704030308040407010706" 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, 02 Feb 2015 12:21:29 -0000 This is a multi-part message in MIME format. --------------060704030308040407010706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello, r272959 broke compatibility with mfsBSD that stores the default network config file in /etc/rc.conf.d/network. In order to fix that load the network config file from netif also. I'm attaching a patch to restore previous functionality, but since I'm not an expert on rc.d init scripts I would like some feedback on whether this is the right approach or not. Thanks, Roger. --------------060704030308040407010706 Content-Type: text/plain; charset=UTF-8; name="0001-rc.d-load-the-network-config-file-for-netif.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-rc.d-load-the-network-config-file-for-netif.patch" RnJvbSA3ZmYxYjQyN2YzMWQ5MmZmNTVmMzIwMjFiNzhiYWU1NzZkNzVjMGM3IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBjaXRy aXguY29tPgpEYXRlOiBUdWUsIDI3IEphbiAyMDE1IDE0OjAxOjE2ICswMTAwClN1YmplY3Q6 IFtQQVRDSF0gcmMuZDogbG9hZCB0aGUgbmV0d29yayBjb25maWcgZmlsZSBmb3IgbmV0aWYK CnIyNzI5NTkgYnJva2UgY29tcGF0aWJpbGl0eSB3aXRoIG1mc0JTRCB0aGF0IHN0b3JlcyB0 aGUgZGVmYXVsdCBuZXR3b3JrCmNvbmZpZyBmaWxlIGluIC9ldGMvcmMuY29uZi5kL25ldHdv cmsuIEluIG9yZGVyIHRvIGZpeCB0aGF0IGxvYWQgdGhlIG5ldHdvcmsKY29uZmlnIGZpbGUg ZnJvbSBuZXRpZiBhbHNvLgotLS0KIGV0Yy9yYy5kL25ldGlmIHwgMyArKysKIDEgZmlsZSBj aGFuZ2VkLCAzIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9ldGMvcmMuZC9uZXRpZiBi L2V0Yy9yYy5kL25ldGlmCmluZGV4IGRkMGRkZTIuLjYyYWQzMWYgMTAwNzU1Ci0tLSBhL2V0 Yy9yYy5kL25ldGlmCisrKyBiL2V0Yy9yYy5kL25ldGlmCkBAIC0yNTIsNSArMjUyLDggQEAg bmV0aWZfY29tbW9uKCkKIAlkZWJ1ZyAiVGhlIGZvbGxvd2luZyBpbnRlcmZhY2VzIHdlcmUg bm90IGNvbmZpZ3VyZWQ6ICRfZmFpbCIKIH0KIAorIyBMb2FkIHRoZSBvbGQgIm5ldHdvcmsi IGNvbmZpZyBmaWxlIGFsc28gZm9yIGNvbXBhdGliaWxpdHkuCisjIFRoaXMgaXMgbmVlZGVk IGZvciBtZnNCU0QgYXQgbGVhc3QuCitsb2FkX3JjX2NvbmZpZyBuZXR3b3JrCiBsb2FkX3Jj X2NvbmZpZyAkbmFtZQogcnVuX3JjX2NvbW1hbmQgJCoKLS0gCjEuOS4zIChBcHBsZSBHaXQt NTApCgo= --------------060704030308040407010706-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 14:25:15 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B8C36F7; Mon, 2 Feb 2015 14:25: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 89BF0B6F; Mon, 2 Feb 2015 14:25:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id CD0985A5; Mon, 2 Feb 2015 14:25:15 +0000 (UTC) Date: Mon, 2 Feb 2015 14:25:15 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <555016291.39.1422887115772.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <175992644.38.1422884852611.JavaMail.jenkins@jenkins-9.freebsd.org> References: <175992644.38.1422884852611.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1020 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 14:25:15 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#665 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f > git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson5718139100353304300.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.fyluOstP progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.fyluOstP cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.fyluOstP/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.fyluOstP LD_LIBRARY_PATH=3D/tmp/install.fyluOstP PATH_LOCALE=3D/tmp= /install.fyluOstP/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.fyluOstP/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.fyluOstP LD_LIBRARY_PATH=3D/tmp/install.fyluOstP PATH_LOCALE=3D/t= mp/install.fyluOstP/locale rm -rf /tmp/install.fyluOstP make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 16:06:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43631455 for ; Mon, 2 Feb 2015 16:06:08 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::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 BB876980 for ; Mon, 2 Feb 2015 16:06:07 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id q1so42395936lam.2 for ; Mon, 02 Feb 2015 08:06:05 -0800 (PST) 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:content-type; bh=tptjADN+ysE9LAneXtVUMuE657XCIpjyGhoEWL5xD3M=; b=iIqBYkGePBkgXQYe8Q3l6Lgch5y5GRImL25oS3wnFv6qzkx9BlDIWieeVaKBWtrEFF 2evB5jRvLnIpeea90TiH07VXn8t6Eycdp1aBlZpXAA76c1eVwyRDq/GQ3vOCTRc6UOYT Bs9n/1Ah2iaZhaXy977+1+dGgMJHsvsn9Z+Co6GMmLFfXrtlLWZyymnD5fxVgA8SoEBe 88Fo/CC5k7r1jMy57YnYxw8pC5skB6CLyeXb2XEOYv7M/LwXmloOk+JZ+1gRBdOdjcsu aApJJxTsl92EPW1PPrZG2uOJemtfeX9xnhHHRKGTMBKzEFRTWbL7TeQQlQUC+Cu2OR8T SLvQ== MIME-Version: 1.0 X-Received: by 10.152.26.98 with SMTP id k2mr20466114lag.53.1422893165740; Mon, 02 Feb 2015 08:06:05 -0800 (PST) Sender: jlehen@gmail.com Received: by 10.114.80.4 with HTTP; Mon, 2 Feb 2015 08:06:05 -0800 (PST) In-Reply-To: <20150201202413.GA2132@reks> References: <20150201202413.GA2132@reks> Date: Mon, 2 Feb 2015 17:06:05 +0100 X-Google-Sender-Auth: ZS8a-RskMofwk_NxAoh1XrPyJVk Message-ID: Subject: Re: libc.so dependency on libssp_nonshared.a From: Jeremie Le Hen To: 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: Mon, 02 Feb 2015 16:06:08 -0000 Hi Gleb, On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou wrote: > I came across some build issues in libc.so and SSP. > > libc.ldscript (aka libc.so) unconditionally includes @@LIBDIR@@/libssp_nonshared.a > > libssp* are not built if WITHOUT_SSP defined. > > ObsoleteFiles.inc doesn't mention libssp*. > > Consider WITHOUT_SSP=yes case. As soon as one does clean installworld > and/or removes stale libssp_nonshared.a ld fails to link anything > because of missing libssp_nonshared.a I think nowadays it would make sense to get it of WITHOUT_SSP altogether. This will turn this into a non-issue. > libc.so during buildworld (as found under /usr/obj) is symlink to the > actual shared library, but not ldscript. Is it intentional? I wouldn't > expect make -C /usr/src/bin/cat to match buildworld result closely > assuming src and world are in sync, but they seem to have different idea > of what libc is.. I don't remember the details except this was pretty twisted :). I don't work enough on this subject to keep it warm in my head and each time I need to go back to it, it takes me hours. The code is here if you want to give a try: http://svnweb.freebsd.org/base/head/share/mk/bsd.lib.mk?view=annotate#l335 -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 17:22:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74B36DE5; Mon, 2 Feb 2015 17:22: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 62FC43DE; Mon, 2 Feb 2015 17:22:40 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 62B345E7; Mon, 2 Feb 2015 17:22:40 +0000 (UTC) Date: Mon, 2 Feb 2015 17:22:40 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <986371289.41.1422897760374.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1029071850.40.1422895476747.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1029071850.40.1422895476747.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1022 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:22:40 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#666 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f > git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson3992881941358600580.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.L4hHMoki progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.L4hHMoki cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.L4hHMoki/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.L4hHMoki LD_LIBRARY_PATH=3D/tmp/install.L4hHMoki PATH_LOCALE=3D/tmp= /install.L4hHMoki/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.L4hHMoki/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.L4hHMoki LD_LIBRARY_PATH=3D/tmp/install.L4hHMoki PATH_LOCALE=3D/t= mp/install.L4hHMoki/locale rm -rf /tmp/install.L4hHMoki make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 17:59:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C574E60 for ; Mon, 2 Feb 2015 17:59:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 721A1A82 for ; Mon, 2 Feb 2015 17:59:48 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t12Hxehl000913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 2 Feb 2015 09:59:40 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t12HxeEr000912 for freebsd-current@freebsd.org; Mon, 2 Feb 2015 09:59:40 -0800 (PST) (envelope-from sgk) Date: Mon, 2 Feb 2015 09:59:40 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: panic in sys_fstatat (?) Message-ID: <20150202175940.GA898@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:59:48 -0000 Not sure if the panmic is initiated in sys_fstatat, but here's the trace. troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.1 Mon Feb 2 09:38:44 PST 2015 FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r278102M: Mon Feb 2 09:15:48 PST 2015 kargl@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 panic: general protection fault Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 12 instruction pointer = 0x20:0xffffffff80754567 stack pointer = 0x28:0xfffffe0469290560 frame pointer = 0x28:0xfffffe04692905a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 62150 (rm) trap number = 9 panic: general protection fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0469290220 panic() at panic+0x1c1/frame 0xfffffe04692902e0 trap_fatal() at trap_fatal+0x380/frame 0xfffffe0469290340 trap() at trap+0x6d1/frame 0xfffffe04692904a0 calltrap() at calltrap+0x8/frame 0xfffffe04692904a0 --- trap 0x9, rip = 0xffffffff80754567, rsp = 0xfffffe0469290560, rbp = 0xfffffe04692905a0 --- ufs_getattr() at ufs_getattr+0x87/frame 0xfffffe04692905a0 VOP_GETATTR_APV() at VOP_GETATTR_APV+0x7a/frame 0xfffffe04692905d0 vn_stat() at vn_stat+0x62/frame 0xfffffe04692906c0 kern_statat() at kern_statat+0xe4/frame 0xfffffe0469290880 sys_fstatat() at sys_fstatat+0x2c/frame 0xfffffe0469290920 amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe0469290a30 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0469290a30 --- syscall (493, FreeBSD ELF64, sys_fstatat), rip = 0x2008b3e9a, rsp = 0x7fffffffdc88, rbp = 0x7fffffffdd30 --- Uptime: 10m14s #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 ) at pcpu.h:219 #1 0xffffffff80559f47 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff8055a3b0 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:747 #3 0xffffffff807a85c0 in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:861 #4 0xffffffff807a8221 in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:201 #5 0xffffffff8078d843 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:235 #6 0xffffffff80754567 in ufs_getattr (ap=) at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 #7 0xffffffff808074fa in VOP_GETATTR_APV (vop=, a=) at vnode_if.c:731 #8 0xffffffff80607e62 in vn_stat (vp=0xfffff80088086000, sb=0xfffffe0469290710, active_cred=0xfffff8000b07d800, file_cred=0x1, td=0xfffff801b5063000) at vnode_if.h:309 #9 0xffffffff806017e4 in kern_statat (td=0xfffff801b5063000, flag=, fd=, path=, pathseg=UIO_USERSPACE, sbp=0xfffffe04692908a0, hook=0xfefff80034ba0700) at /usr/src/sys/kern/vfs_syscalls.c:2241 #10 0xffffffff80601acc in sys_fstatat (td=0xfffff802dbc03dc8, uap=0xfffffe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 #11 0xffffffff807a8db9 in amd64_syscall (td=0xfffff801b5063000, traced=0) at subr_syscall.c:133 #12 0xffffffff8078db2b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #13 0x00000002008b3e9a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 18:10:55 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78380148 for ; Mon, 2 Feb 2015 18:10:55 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 41A95BD8 for ; Mon, 2 Feb 2015 18:10:54 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id F3DA256467; Mon, 2 Feb 2015 12:10:47 -0600 (CST) Message-ID: <54CFBDA7.8050309@vangyzen.net> Date: Mon, 02 Feb 2015 13:10:47 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steve Kargl , freebsd-current@freebsd.org Subject: Re: panic in sys_fstatat (?) References: <20150202175940.GA898@troutmask.apl.washington.edu> In-Reply-To: <20150202175940.GA898@troutmask.apl.washington.edu> 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, 02 Feb 2015 18:10:55 -0000 On 02/02/2015 12:59, Steve Kargl wrote: > FreeBSD troutmask.apl.washington.edu 11.0-CURRENT FreeBSD 11.0-CURRENT > #0 r278102M: Mon Feb 2 09:15:48 PST 2015 > kargl@troutmask.apl.washington.edu:/data/obj/usr/src/sys/SPEW amd64 > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 2; apic id = 12 > instruction pointer = 0x20:0xffffffff80754567 > stack pointer = 0x28:0xfffffe0469290560 > frame pointer = 0x28:0xfffffe04692905a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 62150 (rm) > trap number = 9 > panic: general protection fault > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0469290220 > panic() at panic+0x1c1/frame 0xfffffe04692902e0 > trap_fatal() at trap_fatal+0x380/frame 0xfffffe0469290340 > trap() at trap+0x6d1/frame 0xfffffe04692904a0 > calltrap() at calltrap+0x8/frame 0xfffffe04692904a0 > --- trap 0x9, rip = 0xffffffff80754567, rsp = 0xfffffe0469290560, rbp = 0xfffffe04692905a0 --- > ufs_getattr() at ufs_getattr+0x87/frame 0xfffffe04692905a0 > VOP_GETATTR_APV() at VOP_GETATTR_APV+0x7a/frame 0xfffffe04692905d0 > vn_stat() at vn_stat+0x62/frame 0xfffffe04692906c0 > kern_statat() at kern_statat+0xe4/frame 0xfffffe0469290880 > sys_fstatat() at sys_fstatat+0x2c/frame 0xfffffe0469290920 > amd64_syscall() at amd64_syscall+0x289/frame 0xfffffe0469290a30 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0469290a30 > --- syscall (493, FreeBSD ELF64, sys_fstatat), rip = 0x2008b3e9a, rsp = 0x7fffffffdc88, rbp = 0x7fffffffdd30 --- > Uptime: 10m14s > > > (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > ) at pcpu.h:219 > #1 0xffffffff80559f47 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff8055a3b0 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:747 > #3 0xffffffff807a85c0 in trap_fatal (frame=, > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > #4 0xffffffff807a8221 in trap (frame=) > at /usr/src/sys/amd64/amd64/trap.c:201 > #5 0xffffffff8078d843 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:235 > #6 0xffffffff80754567 in ufs_getattr (ap=) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > #7 0xffffffff808074fa in VOP_GETATTR_APV (vop=, > a=) at vnode_if.c:731 > #8 0xffffffff80607e62 in vn_stat (vp=0xfffff80088086000, > sb=0xfffffe0469290710, active_cred=0xfffff8000b07d800, file_cred=0x1, > td=0xfffff801b5063000) at vnode_if.h:309 > #9 0xffffffff806017e4 in kern_statat (td=0xfffff801b5063000, > flag=, fd=, > path=, pathseg=UIO_USERSPACE, > sbp=0xfffffe04692908a0, hook=0xfefff80034ba0700) > at /usr/src/sys/kern/vfs_syscalls.c:2241 > #10 0xffffffff80601acc in sys_fstatat (td=0xfffff802dbc03dc8, > uap=0xfffffe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 > #11 0xffffffff807a8db9 in amd64_syscall (td=0xfffff801b5063000, traced=0) > at subr_syscall.c:133 > #12 0xffffffff8078db2b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:395 I probably can't help debug this, but someone who _can_ will likely ask for this from kgdb: f 6 x/i $rip info reg Eric From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 18:22:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A70546C0 for ; Mon, 2 Feb 2015 18:22:37 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ADAEDB0 for ; Mon, 2 Feb 2015 18:22:37 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t12IMaUL066882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Feb 2015 10:22:36 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t12IMa13066881; Mon, 2 Feb 2015 10:22:36 -0800 (PST) (envelope-from sgk) Date: Mon, 2 Feb 2015 10:22:36 -0800 From: Steve Kargl To: Eric van Gyzen Subject: Re: panic in sys_fstatat (?) Message-ID: <20150202182236.GA66843@troutmask.apl.washington.edu> References: <20150202175940.GA898@troutmask.apl.washington.edu> <54CFBDA7.8050309@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54CFBDA7.8050309@vangyzen.net> 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, 02 Feb 2015 18:22:37 -0000 On Mon, Feb 02, 2015 at 01:10:47PM -0500, Eric van Gyzen wrote: > On 02/02/2015 12:59, Steve Kargl wrote: > > (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > > ) at pcpu.h:219 > > #1 0xffffffff80559f47 in kern_reboot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:448 > > #2 0xffffffff8055a3b0 in panic (fmt=) > > at /usr/src/sys/kern/kern_shutdown.c:747 > > #3 0xffffffff807a85c0 in trap_fatal (frame=, > > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > > #4 0xffffffff807a8221 in trap (frame=) > > at /usr/src/sys/amd64/amd64/trap.c:201 > > #5 0xffffffff8078d843 in calltrap () > > at /usr/src/sys/amd64/amd64/exception.S:235 > > #6 0xffffffff80754567 in ufs_getattr (ap=) > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > > #7 0xffffffff808074fa in VOP_GETATTR_APV (vop=, > > a=) at vnode_if.c:731 > > #8 0xffffffff80607e62 in vn_stat (vp=0xfffff80088086000, > > sb=0xfffffe0469290710, active_cred=0xfffff8000b07d800, file_cred=0x1, > > td=0xfffff801b5063000) at vnode_if.h:309 > > #9 0xffffffff806017e4 in kern_statat (td=0xfffff801b5063000, > > flag=, fd=, > > path=, pathseg=UIO_USERSPACE, > > sbp=0xfffffe04692908a0, hook=0xfefff80034ba0700) > > at /usr/src/sys/kern/vfs_syscalls.c:2241 > > #10 0xffffffff80601acc in sys_fstatat (td=0xfffff802dbc03dc8, > > uap=0xfffffe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 > > #11 0xffffffff807a8db9 in amd64_syscall (td=0xfffff801b5063000, traced=0) > > at subr_syscall.c:133 > > #12 0xffffffff8078db2b in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:395 > > I probably can't help debug this, but someone who _can_ will likely ask > for this from kgdb: > > f 6 > x/i $rip > info reg (kgdb) f 6 #6 0xffffffff80754567 in ufs_getattr (ap=) at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 463 vap->va_atime.tv_sec = ip->i_din2->di_atime; (kgdb) x/i $rip 0xffffffff80754567 : mov 0x20(%rax),%rax (kgdb) info reg rax 0xfefff80034ba0700 -72066389246343424 rbx 0xfffff802dbc03dc8 -8783816278584 rcx 0x1 1 rdx 0xfffff8000b07d800 -8795907958784 rsi 0xfffffe0469290688 -2180079090040 rdi 0xfffff802dbc03dc8 -8783816278584 rbp 0xfffffe04692905a0 0xfffffe04692905a0 rsp 0xfffffe0469290570 0xfffffe0469290570 r8 0xfffff801b5063000 -8788760973312 r9 0x33 51 r10 0x0 0 r11 0x0 0 r12 0xfffff801b5063000 -8788760973312 r13 0xfffffe04692905e0 -2180079090208 r14 0xfffff80088086000 -8793810771968 r15 0xfffff800880860b0 -8793810771792 rip 0xffffffff80754567 0xffffffff80754567 eflags 0x10202 66050 cs 0x20 32 ss 0x28 40 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 18:29:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C44C999E for ; Mon, 2 Feb 2015 18:29:47 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8E71AE09 for ; Mon, 2 Feb 2015 18:29:47 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 6DEC756467; Mon, 2 Feb 2015 12:29:46 -0600 (CST) Message-ID: <54CFC219.9040001@vangyzen.net> Date: Mon, 02 Feb 2015 13:29:45 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Steve Kargl Subject: Re: panic in sys_fstatat (?) References: <20150202175940.GA898@troutmask.apl.washington.edu> <54CFBDA7.8050309@vangyzen.net> <20150202182236.GA66843@troutmask.apl.washington.edu> In-Reply-To: <20150202182236.GA66843@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252 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: Mon, 02 Feb 2015 18:29:48 -0000 On 02/02/2015 13:22, Steve Kargl wrote: > On Mon, Feb 02, 2015 at 01:10:47PM -0500, Eric van Gyzen wrote: >> On 02/02/2015 12:59, Steve Kargl wrote: >>> (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 >>> ) at pcpu.h:219 >>> #1 0xffffffff80559f47 in kern_reboot (howto=260) >>> at /usr/src/sys/kern/kern_shutdown.c:448 >>> #2 0xffffffff8055a3b0 in panic (fmt=) >>> at /usr/src/sys/kern/kern_shutdown.c:747 >>> #3 0xffffffff807a85c0 in trap_fatal (frame=, >>> eva=) at /usr/src/sys/amd64/amd64/trap.c:861 >>> #4 0xffffffff807a8221 in trap (frame=) >>> at /usr/src/sys/amd64/amd64/trap.c:201 >>> #5 0xffffffff8078d843 in calltrap () >>> at /usr/src/sys/amd64/amd64/exception.S:235 >>> #6 0xffffffff80754567 in ufs_getattr (ap=) >>> at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 >>> #7 0xffffffff808074fa in VOP_GETATTR_APV (vop=, >>> a=) at vnode_if.c:731 >>> #8 0xffffffff80607e62 in vn_stat (vp=0xfffff80088086000, >>> sb=0xfffffe0469290710, active_cred=0xfffff8000b07d800, file_cred=0x1, >>> td=0xfffff801b5063000) at vnode_if.h:309 >>> #9 0xffffffff806017e4 in kern_statat (td=0xfffff801b5063000, >>> flag=, fd=, >>> path=, pathseg=UIO_USERSPACE, >>> sbp=0xfffffe04692908a0, hook=0xfefff80034ba0700) >>> at /usr/src/sys/kern/vfs_syscalls.c:2241 >>> #10 0xffffffff80601acc in sys_fstatat (td=0xfffff802dbc03dc8, >>> uap=0xfffffe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 >>> #11 0xffffffff807a8db9 in amd64_syscall (td=0xfffff801b5063000, traced=0) >>> at subr_syscall.c:133 >>> #12 0xffffffff8078db2b in Xfast_syscall () >>> at /usr/src/sys/amd64/amd64/exception.S:395 >> I probably can't help debug this, but someone who _can_ will likely ask >> for this from kgdb: >> >> f 6 >> x/i $rip >> info reg > (kgdb) f 6 > #6 0xffffffff80754567 in ufs_getattr (ap=) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > 463 vap->va_atime.tv_sec = ip->i_din2->di_atime; > (kgdb) x/i $rip > 0xffffffff80754567 : mov 0x20(%rax),%rax > (kgdb) info reg > rax 0xfefff80034ba0700 -72066389246343424 This looks very similar to the GPF panic you reported a week ago. A single bit has been flipped in the %rax register. It should begin with 0xff, not 0xfe. I would strongly suspect that you have some failing hardware, most commonly memory. > rbx 0xfffff802dbc03dc8 -8783816278584 > rcx 0x1 1 > rdx 0xfffff8000b07d800 -8795907958784 > rsi 0xfffffe0469290688 -2180079090040 > rdi 0xfffff802dbc03dc8 -8783816278584 > rbp 0xfffffe04692905a0 0xfffffe04692905a0 > rsp 0xfffffe0469290570 0xfffffe0469290570 > r8 0xfffff801b5063000 -8788760973312 > r9 0x33 51 > r10 0x0 0 > r11 0x0 0 > r12 0xfffff801b5063000 -8788760973312 > r13 0xfffffe04692905e0 -2180079090208 > r14 0xfffff80088086000 -8793810771968 > r15 0xfffff800880860b0 -8793810771792 > rip 0xffffffff80754567 0xffffffff80754567 > eflags 0x10202 66050 > cs 0x20 32 > ss 0x28 40 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 > From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 18:29:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BEBAAA1 for ; Mon, 2 Feb 2015 18:29:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9F83E13 for ; Mon, 2 Feb 2015 18:29:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t12ITqbH058095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2015 20:29:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t12ITqbH058095 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t12ITqQO058094; Mon, 2 Feb 2015 20:29:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Feb 2015 20:29:52 +0200 From: Konstantin Belousov To: Steve Kargl Subject: Re: panic in sys_fstatat (?) Message-ID: <20150202182952.GR42409@kib.kiev.ua> References: <20150202175940.GA898@troutmask.apl.washington.edu> <54CFBDA7.8050309@vangyzen.net> <20150202182236.GA66843@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202182236.GA66843@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Eric van Gyzen , 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, 02 Feb 2015 18:29:58 -0000 On Mon, Feb 02, 2015 at 10:22:36AM -0800, Steve Kargl wrote: > On Mon, Feb 02, 2015 at 01:10:47PM -0500, Eric van Gyzen wrote: > > On 02/02/2015 12:59, Steve Kargl wrote: > > > (kgdb) #0 doadump (textdump=Unhandled dwarf expression opcode 0x93 > > > ) at pcpu.h:219 > > > #1 0xffffffff80559f47 in kern_reboot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:448 > > > #2 0xffffffff8055a3b0 in panic (fmt=) > > > at /usr/src/sys/kern/kern_shutdown.c:747 > > > #3 0xffffffff807a85c0 in trap_fatal (frame=, > > > eva=) at /usr/src/sys/amd64/amd64/trap.c:861 > > > #4 0xffffffff807a8221 in trap (frame=) > > > at /usr/src/sys/amd64/amd64/trap.c:201 > > > #5 0xffffffff8078d843 in calltrap () > > > at /usr/src/sys/amd64/amd64/exception.S:235 > > > #6 0xffffffff80754567 in ufs_getattr (ap=) > > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > > > #7 0xffffffff808074fa in VOP_GETATTR_APV (vop=, > > > a=) at vnode_if.c:731 > > > #8 0xffffffff80607e62 in vn_stat (vp=0xfffff80088086000, > > > sb=0xfffffe0469290710, active_cred=0xfffff8000b07d800, file_cred=0x1, > > > td=0xfffff801b5063000) at vnode_if.h:309 > > > #9 0xffffffff806017e4 in kern_statat (td=0xfffff801b5063000, > > > flag=, fd=, > > > path=, pathseg=UIO_USERSPACE, > > > sbp=0xfffffe04692908a0, hook=0xfefff80034ba0700) > > > at /usr/src/sys/kern/vfs_syscalls.c:2241 > > > #10 0xffffffff80601acc in sys_fstatat (td=0xfffff802dbc03dc8, > > > uap=0xfffffe04692909c0) at /usr/src/sys/kern/vfs_syscalls.c:2215 > > > #11 0xffffffff807a8db9 in amd64_syscall (td=0xfffff801b5063000, traced=0) > > > at subr_syscall.c:133 > > > #12 0xffffffff8078db2b in Xfast_syscall () > > > at /usr/src/sys/amd64/amd64/exception.S:395 > > > > I probably can't help debug this, but someone who _can_ will likely ask > > for this from kgdb: > > > > f 6 > > x/i $rip > > info reg > > (kgdb) f 6 > #6 0xffffffff80754567 in ufs_getattr (ap=) > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > 463 vap->va_atime.tv_sec = ip->i_din2->di_atime; > (kgdb) x/i $rip > 0xffffffff80754567 : mov 0x20(%rax),%rax > (kgdb) info reg > rax 0xfefff80034ba0700 -72066389246343424 Note the single-bit error in the 0xf_e_fff8... address above. Is this the same machine you reported the panic in pmap ? May be, run memtest ? > rbx 0xfffff802dbc03dc8 -8783816278584 > rcx 0x1 1 > rdx 0xfffff8000b07d800 -8795907958784 > rsi 0xfffffe0469290688 -2180079090040 > rdi 0xfffff802dbc03dc8 -8783816278584 > rbp 0xfffffe04692905a0 0xfffffe04692905a0 > rsp 0xfffffe0469290570 0xfffffe0469290570 > r8 0xfffff801b5063000 -8788760973312 > r9 0x33 51 > r10 0x0 0 > r11 0x0 0 > r12 0xfffff801b5063000 -8788760973312 > r13 0xfffffe04692905e0 -2180079090208 > r14 0xfffff80088086000 -8793810771968 > r15 0xfffff800880860b0 -8793810771792 > rip 0xffffffff80754567 0xffffffff80754567 > eflags 0x10202 66050 > cs 0x20 32 > ss 0x28 40 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 > > -- > 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.org" From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 18:39:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C267E134 for ; Mon, 2 Feb 2015 18:39:44 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A0923F3A for ; Mon, 2 Feb 2015 18:39:44 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t12Idiw7066817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Feb 2015 10:39:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t12IdhWu066816; Mon, 2 Feb 2015 10:39:43 -0800 (PST) (envelope-from sgk) Date: Mon, 2 Feb 2015 10:39:43 -0800 From: Steve Kargl To: Konstantin Belousov Subject: Re: panic in sys_fstatat (?) Message-ID: <20150202183943.GA12198@troutmask.apl.washington.edu> References: <20150202175940.GA898@troutmask.apl.washington.edu> <54CFBDA7.8050309@vangyzen.net> <20150202182236.GA66843@troutmask.apl.washington.edu> <20150202182952.GR42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150202182952.GR42409@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Eric van Gyzen , 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, 02 Feb 2015 18:39:44 -0000 On Mon, Feb 02, 2015 at 08:29:52PM +0200, Konstantin Belousov wrote: > On Mon, Feb 02, 2015 at 10:22:36AM -0800, Steve Kargl wrote: > > (kgdb) f 6 > > #6 0xffffffff80754567 in ufs_getattr (ap=) > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > > 463 vap->va_atime.tv_sec = ip->i_din2->di_atime; > > (kgdb) x/i $rip > > 0xffffffff80754567 : mov 0x20(%rax),%rax > > (kgdb) info reg > > rax 0xfefff80034ba0700 -72066389246343424 > Note the single-bit error in the 0xf_e_fff8... address above. > Is this the same machine you reported the panic in pmap ? > > May be, run memtest ? > Yep, same hardware. And, yes, I'm beginning to think it is hardware as no one else is reporting a problem. The system is less than 2 month old. :( -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 19:29:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 831D54ED for ; Mon, 2 Feb 2015 19:29:00 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 DBC4B7B1 for ; Mon, 2 Feb 2015 19:28:59 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id E9C476A6077; Mon, 2 Feb 2015 20:28:55 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t12JSt8G098705; Mon, 2 Feb 2015 20:28:55 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t12JStgH098491; Mon, 2 Feb 2015 20:28:55 +0100 (CET) (envelope-from lars) Date: Mon, 2 Feb 2015 20:28:54 +0100 From: Lars Engels To: Alexandr Krivulya , Andrew Wilcox , "'freebsd-current'" Subject: Re: drm2 regression: backlight adjustment on ivybridge no longer works Message-ID: <20150202192854.GV41565@e-new.0x20.net> Mail-Followup-To: Lars Engels , Alexandr Krivulya , Andrew Wilcox , 'freebsd-current' References: <54CA7949.6060202@shurik.kiev.ua> <20150201091821.GN41565@e-new.0x20.net> <004001d03e02$62d7f040$2887d0c0$@Wilcox-Tech.com> <20150201094124.GO41565@e-new.0x20.net> <20150201101201.GP41565@e-new.0x20.net> <54CDFDEA.2010209@shurik.kiev.ua> <3bafb094-e87c-4c3b-adfe-a36f1cf89302@email.android.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D/26AIznG/rf8cgR" Content-Disposition: inline In-Reply-To: <3bafb094-e87c-4c3b-adfe-a36f1cf89302@email.android.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:29:00 -0000 --D/26AIznG/rf8cgR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 01, 2015 at 11:23:47AM +0100, Lars Engels wrote: > On 1. Februar 2015 11:20:26 MEZ, Alexandr Krivulya wrote: > >01.02.2015 12:12, Lars Engels =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Sun, Feb 01, 2015 at 10:41:25AM +0100, Lars Engels wrote: > >>> On Sun, Feb 01, 2015 at 03:35:15AM -0600, Andrew Wilcox wrote: > >>>> Lars Engels sent: 01 February 2015 03:18: > >>>>> With acpi_video I get some interesting sysctl: > >>>>> hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 > >14 15 > >>>>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 > >38 39 > >>>>> 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 > >62 63 > >>>>> 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 > >86 87 > >>>>> 88 89 90 91 92 93 94 95 96 97 98 99 100 > >>>>> > >>>>> I guess it should not be 100 100 0 ... 100? > >>>> Actually, the "standard" internal ACPI brightness level struct > >(BRTN in the DSDT) is laid out as: > >>>> > >>>> * "Full power" value (one byte, the value at which the brightness > >should be set on AC by default) > >>>> * "Economy" value (one byte, the value at which the brightness > >should be set on battery by default) > >>>> * Actual values (N bytes, up to Max but frequently not) > >>>> > >>>> So, no, that value indeed sounds correct. On my laptop the value > >is: > >>>> 80 47 0 7 13 20 27 33 40 47 53 60 67 73 80 87 93 100 > >>> Thank you for the explanation. > >>> FWIW, here is the full output from sysctl hw.acpi.video.lcd0: > >>> > >>> hw.acpi.video.lcd0.active: 1 > >>> hw.acpi.video.lcd0.brightness: 11 > >>> hw.acpi.video.lcd0.fullpower: 100 > >>> hw.acpi.video.lcd0.economy: 100 > >>> hw.acpi.video.lcd0.levels: 100 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 > >14 15 > >>> 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 > >39 > >>> 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 > >63 > >>> 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 > >87 > >>> 88 89 90 91 92 93 94 95 96 97 98 99 100 > >>> hw.acpi.video.crt0.active: 1 > >>> hw.acpi.video.ext0.active: 1 > >>> hw.acpi.video.ext1.active: 1 > >>> hw.acpi.video.ext2.active: 1 > >>> hw.acpi.video.ext3.active: 1 > >>> hw.acpi.video.ext4.active: 1 > >>> hw.acpi.video.ext5.active: 1 > >>> > >>>> What revision of -CURRENT are you running? What is the outcome of > >>>> trying the patch posted Saturday morning (UTC) from Elizabeth Myers > >>>> (message ID <54CC5311.9070604@interlinked.me>)? > >>>> > >>> I'm currently running r277858 and haven't tried the patch, yet. But > >will > >>> do now and report back. > >>> > >> So now I have a new sysctl hw.dri.0.i915_backlight. But no matter > >what > >> value I pass to it, the brightness doesn't change. > >> > >> It's a Ivy Brigde notebook where drm shows some errors in dmesg. > >Please > >> see: http://pastie.org/9877917 > >> > >> > > > >Please try to boot with acpi_ibm and without acpi_video. This way all > >works for me. >=20 > That=E2=80=98s already what I do. Also tried it with acpi_video without l= uck. For the records: With r278102 brightness controls are working again. Thanks all for helping. --D/26AIznG/rf8cgR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUz8/2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tv4MH/0nYGYxljw3fZ3xQDsL9URe9 gbymcJN6V7tyQh4OsyxMptIzyOjC+40dS7RZZ7KT0A1PjxUv1qnzc+AGpPQ5E7c9 IwnAAZkUR23XFZpIy8MTiOwEjUnoNXtPJtZPQdxedXllFF/IcWe3mfiKCt3IwPUd D9J2CRkgO9CLXTopjIrk8BTule/BihMM9NKa/y4Ya+Zpl/CP3eqFYPOoO/Ic+MIO JhSmRANTzCE9RxWuO1n9TjBxmOrNR0pmpYyeRLpP+5BDokk/hOT+6kChT1iBEGue ddW+jE5gD67H0JXtZG41/034JAO9gdKZVPwPU9r4CUvAwrjB171NCCdSxu82Lpg= =o35U -----END PGP SIGNATURE----- --D/26AIznG/rf8cgR-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 20:30:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DDC4D4B for ; Mon, 2 Feb 2015 20:30:35 +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 6EA0BE26 for ; Mon, 2 Feb 2015 20:30:35 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id t12KW1Ud019395; Mon, 2 Feb 2015 12:32:01 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Konstantin Belousov , Steve Kargl In-Reply-To: <20150202183943.GA12198@troutmask.apl.washington.edu> References: <20150202175940.GA898@troutmask.apl.washington.edu> <54CFBDA7.8050309@vangyzen.net> <20150202182236.GA66843@troutmask.apl.washington.edu> <20150202182952.GR42409@kib.kiev.ua>, <20150202183943.GA12198@troutmask.apl.washington.edu> From: "Chris H" Subject: Re: panic in sys_fstatat (?) Date: Mon, 02 Feb 2015 12:32:02 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <171bfc9d01d3315b35d5e10376550469@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: Eric van Gyzen , 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, 02 Feb 2015 20:30:35 -0000 On Mon, 2 Feb 2015 10:39:43 -0800 Steve Kargl wrote > On Mon, Feb 02, 2015 at 08:29:52PM +0200, Konstantin Belousov wrote: > > On Mon, Feb 02, 2015 at 10:22:36AM -0800, Steve Kargl wrote: > > > (kgdb) f 6 > > > #6 0xffffffff80754567 in ufs_getattr (ap=) > > > at /usr/src/sys/ufs/ufs/ufs_vnops.c:463 > > > 463 vap->va_atime.tv_sec = ip->i_din2->di_atime; > > > (kgdb) x/i $rip > > > 0xffffffff80754567 : mov 0x20(%rax),%rax > > > (kgdb) info reg > > > rax 0xfefff80034ba0700 -72066389246343424 > > Note the single-bit error in the 0xf_e_fff8... address above. > > Is this the same machine you reported the panic in pmap ? > > > > May be, run memtest ? > > > > Yep, same hardware. And, yes, I'm beginning to think it > is hardware as no one else is reporting a problem. > > The system is less than 2 month old. :( FWIW given the system is so young, you might want to consider BUS/CPU timing, or PSU (power supply) before giving up on the board/CPU/RAM. I had [apparent] CPU cache failures that ultimately turned out to be the PSU. So thought it worth mentioning. :) --Chris > > -- > 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.org" From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 20:39:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35B4928E; Mon, 2 Feb 2015 20:39:25 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::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 EA52EF36; Mon, 2 Feb 2015 20:39:24 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id s11so32257026qcv.2; Mon, 02 Feb 2015 12:39:24 -0800 (PST) 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=3kg5CrJFgE5wG0jik/Knc3v4IyDnzIxHr93YRmMTPUw=; b=Vu5xNpZOGe2DXkQmY/78Wtcog/RT/RYstWf8HhopAlY4E0diP8eacKP8jdmtX4BqzN 8AvQYEgEdzBzvYMW8YhiFstSXOUcopQtsn314wCWhmdOuKqleXMODfIHB3peL7h9JMgF 8v/xCK30MHfQbjCr0pahzvvGurCbaRUKKpcKsknhd6qY6vxBz24uDG3eLvectQmS5yB/ Qbkl8wXqdAkFm2a6iJoP1VAGFlSoQ3UWt2O5Mvc2X+hmhVObqnoWSe4x9qX/EAcs9yIH lxjG27Jy9h4vYhMCofc7BKxlmjOqHmBGNStTx4SQCRkbT4Sd0aXXIEFDEDnosNrgeW9l MW0w== X-Received: by 10.140.44.34 with SMTP id f31mr32561666qga.3.1422909563941; Mon, 02 Feb 2015 12:39:23 -0800 (PST) Received: from rama-hkr.org (c-71-226-13-107.hsd1.ga.comcast.net. [71.226.13.107]) by mx.google.com with ESMTPSA id d3sm19318837qaf.13.2015.02.02.12.39.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 12:39:23 -0800 (PST) Message-ID: <54CFE09B.3060006@gmail.com> Date: Mon, 02 Feb 2015 15:39:55 -0500 From: R0B_ROD User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-mobile@freebsd.org, freebsd-amd64@freebsd.org, freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: HP 2B19WM PCI-E SD Reader Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:39:25 -0000 Thank you for the time you took to help. According to: http://lists.freebsd.org/pipermail/ \ \ freebsd-current/2013-July/042788.html \ freebsd-questions/2014-August/259843.html % uname -a FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Is the Realtek RTS5229 PCI-E SD Card Reader supported yet??? I have these kernel drivers compiled & loaded mmc mmcsd sdhci As previous posters have said, NO dmesg output from inserting SD card; NO boot output while SD card inserted. 8 Hrs of work to get here; now I'm burned out. PS: Not very talented at solving problems because I don't define them properly at the step 1. -- > Roberto > ^ > /"\ /33.2947° N, 82.2006° W > \ / ASCII REBEL CAMPAIGN / (1) 4044743997 > -X- AGAINST HTML EMAIL / witchdoctor.mdf at gmail.COM > / \ AND POSTINGS / http://mdf0.blogspot.com > \_/ From owner-freebsd-current@FreeBSD.ORG Mon Feb 2 21:12:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40371C62 for ; Mon, 2 Feb 2015 21:12:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A4DD3D5 for ; Mon, 2 Feb 2015 21:12:05 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id t12LBwjO074416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Feb 2015 13:11:58 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id t12LBwFL074415; Mon, 2 Feb 2015 13:11:58 -0800 (PST) (envelope-from sgk) Date: Mon, 2 Feb 2015 13:11:58 -0800 From: Steve Kargl To: Chris H Subject: Re: panic in sys_fstatat (?) Message-ID: <20150202211158.GA1312@troutmask.apl.washington.edu> References: <20150202175940.GA898@troutmask.apl.washington.edu> <54CFBDA7.8050309@vangyzen.net> <20150202182236.GA66843@troutmask.apl.washington.edu> <20150202182952.GR42409@kib.kiev.ua> <20150202183943.GA12198@troutmask.apl.washington.edu> <171bfc9d01d3315b35d5e10376550469@ultimatedns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <171bfc9d01d3315b35d5e10376550469@ultimatedns.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Konstantin Belousov , Eric van Gyzen , 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, 02 Feb 2015 21:12:05 -0000 On Mon, Feb 02, 2015 at 12:32:02PM -0800, Chris H wrote: > On Mon, 2 Feb 2015 10:39:43 -0800 Steve Kargl > > > > Yep, same hardware. And, yes, I'm beginning to think it > > is hardware as no one else is reporting a problem. > > > > The system is less than 2 month old. :( > FWIW given the system is so young, you might want to > consider BUS/CPU timing, or PSU (power supply) before > giving up on the board/CPU/RAM. > I had [apparent] CPU cache failures that ultimately turned > out to be the PSU. So thought it worth mentioning. :) > memtest86+ indicates that it is indeed a memory module. Sorry about the seemingly bogus kernel panic emails. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 03:50:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D160891 for ; Tue, 3 Feb 2015 03:50:39 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id 372407BA for ; Tue, 3 Feb 2015 03:50:37 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 73F3236ACB for ; Mon, 2 Feb 2015 22:50:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=8/dfXEt/5ZPh z0TtleyTkcl9X/c=; b=IMefyyscx/DtOKjVX4fBiO6Brvn8LjtTuQFFhTSgl7me WJOLRJvla732SRo8KCbaD0vaXqUdVI3A0GCgsUctVpzIA3s5eMc46YiVsT5Ffbae tflCQiiodQpfXOaJ89u+Jk/tQ8+vQczAGhEbW3PbumP+oBONJAdoPn+RguSNIWc= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6A9E536ACA for ; Mon, 2 Feb 2015 22:50:30 -0500 (EST) Received: from [192.168.1.103] (unknown [73.164.1.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 0D6FC36AC9 for ; Mon, 2 Feb 2015 22:50:28 -0500 (EST) Message-ID: <54D0457E.90006@badgerio.us> Date: Mon, 02 Feb 2015 21:50:22 -0600 From: Eric Badger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Filepaths in VM map for tmpfs files References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> <20150202093027.GL42409@kib.kiev.ua> In-Reply-To: <20150202093027.GL42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CB68411A-AB57-11E4-BEE7-7BA29F42C9D4-46178211!pb-smtp1.pobox.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 03:50:39 -0000 On 02/02/2015 03:30 AM, Konstantin Belousov wrote: > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: >>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? >> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; >> I'd opine that it is better to be transparent than make it look like >> there is an OBJT_VNODE object there. It may be that some programs would >> be confused by VNODE info returned on a SWAP type mapping, though I know >> that dtrace handles it OK. > kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. > So this is in fact a bug in whatever used the API to access kve_path > for KVE_TYPE_SWAP. Hmm, is that documented anywhere? I think it's fair to assume that kve_vn* applies only to the VNODE type, but I know there are several in-tree users that reference kve_path regardless of type (ostensibly relying on the default of an empty string). Maybe one could determine the validity of the kve_vn* fields by inspecting the kve_vn_type (not sure of all the consequences of that)? Or change it to KVME_TYPE_VNODE and deal with the below problem... > >>> Second, note that it is possible that the vnode is recycled, so >>> OBJ_TMPFS flag is cleared for tmpfs swap object. The OBJ_TMPFS_NODE >>> flag is still set then. I am not sure what to do in this case, >>> should the type changed to KVME_TYPE_VNODE still, but kve_vn_* >>> fields left invalid ? >> I think if we changed to KVME_TYPE_VNODE in some cases, it should be >> done in all cases, even if the vnode has been recycled (but leave vp == >> NULL in that case). Though if it is left as KVME_TYPE_SWAP, then that >> concern goes away on its own. > Concern is not vp == NULL, but the fact that kve_vn* cannot be filled, > there is simply no (easy) way to fetch this information. Right; by leaving vp == NULL, I meant "don't populate the kve_vn* fields", which admittedly isn't a great solution. But as you say, the information is not really available once the vnode has been reclaimed. There is some inherent difficultly in the duality of the vm object here; it would be nice if it could be treated uniformly with other vnodes, but I think I lack the expertise to approach a more involved solution that would achieve this. Incidentally Konstantin, thanks for the feedback and advice. Eric From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 07:46:00 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEB05DEF; Tue, 3 Feb 2015 07:45:59 +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 A8E59FE9; Tue, 3 Feb 2015 07:45:59 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id lj1so92999101pab.5; Mon, 02 Feb 2015 23:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=S56aGp0HIC6FHoHWgzvsYwUTFXyryncWkmQYV2S/350=; b=dWD8tk905IKzXNq6eFRUNbfTCWO7+4k7RESP39dxTdZfpxzjfXg9ezM7LvVvmCEimo Am/8aOxmNfhG+K8thZ6rxDLLeRFaUocNQQkDngNhmFRCEJh9bIsJ6EUvKRLV1hJrhqGt 0lHyrz/LriZ7OBIe8N9XHgyIpLDt4hKBCHN2FReXOVanq8zm+MALGXHrdAHNwRIL3qZO g0jYb/8bUDNQj6IMfngSGB6PAwIN+010Xr4ndQHWed4h0b8SJvrzq2JiQzeXPj7nUk7h BFCYHMdM5i8yUEqx6ncEmIlBh1mpZVzC6qiw5hK2XKaI/JU+5sMlAx+ZMuR0XWaMxuAr RVeg== X-Received: by 10.68.189.71 with SMTP id gg7mr1353331pbc.21.1422949559283; Mon, 02 Feb 2015 23:45:59 -0800 (PST) Received: from localhost (c-76-21-76-83.hsd1.ca.comcast.net. [76.21.76.83]) by mx.google.com with ESMTPSA id nw6sm1180842pbb.94.2015.02.02.23.45.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 23:45:58 -0800 (PST) Sender: Gleb Kurtsou Date: Mon, 2 Feb 2015 23:47:09 -0800 From: Gleb Kurtsou To: Jeremie Le Hen Subject: Re: libc.so dependency on libssp_nonshared.a Message-ID: <20150203074709.GA1091@reks> Mail-Followup-To: Jeremie Le Hen , freebsd-current@freebsd.org References: <20150201202413.GA2132@reks> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: Tue, 03 Feb 2015 07:46:00 -0000 On (02/02/2015 17:06), Jeremie Le Hen wrote: > Hi Gleb, > On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou wrote: > > I came across some build issues in libc.so and SSP. > > > > libc.ldscript (aka libc.so) unconditionally includes @@LIBDIR@@/libssp_nonshared.a > > > > libssp* are not built if WITHOUT_SSP defined. > > > > ObsoleteFiles.inc doesn't mention libssp*. > > > > Consider WITHOUT_SSP=yes case. As soon as one does clean installworld > > and/or removes stale libssp_nonshared.a ld fails to link anything > > because of missing libssp_nonshared.a > > I think nowadays it would make sense to get it of WITHOUT_SSP > altogether. This will turn this into a non-issue. Do you mean building libssp_nonshared unconditionally? It makes perfect sense. The library is a single stub function. By building libssp* conditionally we may expect that -fstack-protector complier option won't work. I wasn't able to reproduce this potential problem. libc provides __stack_chk_fail and __stack_chk_guard. And I failed to create a test case that would generate code using anything like __memcpy_chk. Perhaps we should change MK_SSP to operate as documented (add -fstack-protector to CFLAGS) and consider adding MK_SSP_SUPPORT option for libraries. Although there is no reason to have MK_SSP_SUPPORT if that would imply failure to run binaries or compile with -fstack-protector. > > libc.so during buildworld (as found under /usr/obj) is symlink to the > > actual shared library, but not ldscript. Is it intentional? I wouldn't > > expect make -C /usr/src/bin/cat to match buildworld result closely > > assuming src and world are in sync, but they seem to have different idea > > of what libc is.. > > I don't remember the details except this was pretty twisted :). I > don't work enough on this subject to keep it warm in my head and each > time I need to go back to it, it takes me hours. > > The code is here if you want to give a try: > http://svnweb.freebsd.org/base/head/share/mk/bsd.lib.mk?view=annotate#l335 indeed. From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 08:27:32 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FED6B0D; Tue, 3 Feb 2015 08:27:32 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5846BC; Tue, 3 Feb 2015 08:27:32 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5205E790; Tue, 3 Feb 2015 08:27:32 +0000 (UTC) Date: Tue, 3 Feb 2015 08:27:31 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <1278281201.42.1422952051923.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <986371289.41.1422897760374.JavaMail.jenkins@jenkins-9.freebsd.org> References: <986371289.41.1422897760374.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1023 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 08:27:32 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#672 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f > git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson1789453341986571460.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.x4bdyHst progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.x4bdyHst cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.x4bdyHst/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.x4bdyHst LD_LIBRARY_PATH=3D/tmp/install.x4bdyHst PATH_LOCALE=3D/tmp= /install.x4bdyHst/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.x4bdyHst/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.x4bdyHst LD_LIBRARY_PATH=3D/tmp/install.x4bdyHst PATH_LOCALE=3D/t= mp/install.x4bdyHst/locale rm -rf /tmp/install.x4bdyHst make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 08:32:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59D13C81; Tue, 3 Feb 2015 08:32:48 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 478237DF; Tue, 3 Feb 2015 08:32:48 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 9A70F791; Tue, 3 Feb 2015 08:32:48 +0000 (UTC) Date: Tue, 3 Feb 2015 08:32:48 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <1863411260.43.1422952368603.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1278281201.42.1422952051923.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1278281201.42.1422952051923.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: Build-UFS-image #1024 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: Build-UFS-image X-Jenkins-Result: FAILURE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 08:32:48 -0000 See ------------------------------------------ Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#673 Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace > git rev-parse --is-inside-work-tree # timeout=3D10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci # tim= eout=3D10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci > git --version # timeout=3D10 > git fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/= heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=3D10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=3D10 Checking out Revision c4076363048e3727a9772acffc651bb19bebdb4f (refs/remote= s/origin/master) > git config core.sparsecheckout # timeout=3D10 > git checkout -f c4076363048e3727a9772acffc651bb19bebdb4f > git rev-list c4076363048e3727a9772acffc651bb19bebdb4f # timeout=3D10 [Build-UFS-image] $ /bin/sh -xe /tmp/hudson7937943411931952350.sh + freebsd-ci/scripts/build/build-ufs-image.sh + [ -z ] + [ -z /builds/FreeBSD_HEAD ] + [ -z '' ] + export MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj + [ -z '' ] + basename /builds/FreeBSD_HEAD + PACKAGE_ROOT=3D + [ -z '' ] + basename /builds/FreeBSD_HEAD + IMAGE_ROOT=3D + [ -n '' ] + [ -z /builds/FreeBSD_HEAD/obj ] + cd /builds/FreeBSD_HEAD + [ -z '' ] + [ -f /builds/FreeBSD_HEAD/make.conf ] + __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf + sudo rm -fr + mkdir -p + sudo env MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj make installworld NO= _FSCHG=3Dyes DESTDIR=3D __MAKE_CONF=3D/builds/FreeBSD_HEAD/make.conf mkdir -p /tmp/install.tyXk6tEX progs=3D$(for prog in [ awk cap_mkdb cat chflags chmod chown date echo egr= ep find grep id install ln lockf make mkdir mtree mv pwd_mkdb rm sed ser= vices_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do = if progpath=3D`which $prog`; then echo $progpath; else echo "Required t= ool $prog not found in PATH." >&2; exit 1; fi; done); libs=3D$(ldd -f "= %o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do = set -- $line; if [ "$2 $3" !=3D "not found" ]; then echo $2; else echo = "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $prog= s /tmp/install.tyXk6tEX cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.tyXk6tEX/locale cd /builds/FreeBSD_HEAD; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACHIN= E_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds/F= reeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF_T= MAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/shar= e/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/s= bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBSD_= HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/builds= /FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp= /usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/in= stall.tyXk6tEX LD_LIBRARY_PATH=3D/tmp/install.tyXk6tEX PATH_LOCALE=3D/tmp= /install.tyXk6tEX/locale make -f Makefile.inc1 __MAKE_SHELL=3D/tmp/insta= ll.tyXk6tEX/sh reinstall; MAKEOBJDIRPREFIX=3D/builds/FreeBSD_HEAD/obj MACH= INE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D GROFF_BIN_PATH=3D/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin GROFF_FONT_PATH=3D/builds= /FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/share/groff_font GROFF= _TMAC_PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/sh= are/tmac PATH=3D/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr= /sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/bin:/buil= ds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/usr/games:/builds/FreeBS= D_HEAD/obj/builds/FreeBSD_HEAD/tmp/legacy/bin:/builds/FreeBSD_HEAD/obj/buil= ds/FreeBSD_HEAD/tmp/usr/sbin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/t= mp/usr/bin:/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/tmp/usr/games:/tmp/= install.tyXk6tEX LD_LIBRARY_PATH=3D/tmp/install.tyXk6tEX PATH_LOCALE=3D/t= mp/install.tyXk6tEX/locale rm -rf /tmp/install.tyXk6tEX make[2]: "/builds/FreeBSD_HEAD/share/mk/bsd.compiler.mk" line 42: Unable to= determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make[1]: stopped in /builds/FreeBSD_HEAD *** Error code 1 Stop. make: stopped in /builds/FreeBSD_HEAD Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 11:24:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6ED628F; Tue, 3 Feb 2015 11:24:38 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0EABB9; Tue, 3 Feb 2015 11:24:38 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5972F7E5; Tue, 3 Feb 2015 11:24:37 +0000 (UTC) Date: Tue, 3 Feb 2015 11:24:36 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org, rodrigc@FreeBSD.org Message-ID: <873151901.44.1422962676899.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1863411260.43.1422952368603.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1863411260.43.1422952368603.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : Build-UFS-image #1025 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: Build-UFS-image 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, 03 Feb 2015 11:24:38 -0000 See From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 05:09:09 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E724D364 for ; Tue, 3 Feb 2015 05:09:09 +0000 (UTC) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id D4ACAE7B for ; Tue, 3 Feb 2015 05:09:09 +0000 (UTC) Received: from akips.com (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id 2278327DB6 for ; Tue, 3 Feb 2015 15:09:02 +1000 (EST) Date: Tue, 3 Feb 2015 15:08:38 +1000 From: Paul Koch To: freebsd-current@freebsd.org Subject: tzsetup - UTC user question Message-ID: <20150203150838.5bcde9a9@akips.com> Organization: AKIPS X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on host1.akips.com X-Mailman-Approved-At: Tue, 03 Feb 2015 12:18:25 +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, 03 Feb 2015 05:09:10 -0000 Since the default option for "Select local or UTC clock" changed from "No" to "Yes", we are seeing many customers who incorrectly answer this question! This screws up things in our app because we store all data in UTC. A few observations... Most people don't know what "CMOS clock" is. Maybe change the wording to "BIOS clock" or "Hardware Clock" ?? The person doing the install may not know what the clock is currently set to, especially when installing in a VM. Perhaps the screen should display the current machine time so they can correctly answer the question. Why was the default changed from "No" to "Yes" ? Paul. -- Paul Koch | Founder, CEO AKIPS Network Monitor http://www.akips.com Brisbane, Australia From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 12:21:54 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 224543B0 for ; Tue, 3 Feb 2015 12:21:54 +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 D0CBD31F for ; Tue, 3 Feb 2015 12:21:53 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YIcUH-000A3u-M5; Tue, 03 Feb 2015 15:21:49 +0300 Date: Tue, 3 Feb 2015 15:21:49 +0300 From: Slawa Olhovchenkov To: Paul Koch Subject: Re: tzsetup - UTC user question Message-ID: <20150203122149.GA29901@zxy.spb.ru> References: <20150203150838.5bcde9a9@akips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150203150838.5bcde9a9@akips.com> 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: 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, 03 Feb 2015 12:21:54 -0000 On Tue, Feb 03, 2015 at 03:08:38PM +1000, Paul Koch wrote: > > Since the default option for "Select local or UTC clock" changed from > "No" to "Yes", we are seeing many customers who incorrectly answer this > question! > > This screws up things in our app because we store all data in UTC. > > A few observations... > > Most people don't know what "CMOS clock" is. Maybe change the wording > to "BIOS clock" or "Hardware Clock" ?? > > The person doing the install may not know what the clock is currently set > to, especially when installing in a VM. Perhaps the screen should display > the current machine time so they can correctly answer the question. > > Why was the default changed from "No" to "Yes" ? or change ntpd_sync_on_start="YES" to force correct time. in most case for hardware platform CMOS time contains garbage. From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 12:25:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DA184F0 for ; Tue, 3 Feb 2015 12:25:50 +0000 (UTC) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (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 1BBE4348 for ; Tue, 3 Feb 2015 12:25:50 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YIcY7-000K9p-U0; Tue, 03 Feb 2015 13:25:47 +0100 Date: Tue, 3 Feb 2015 13:25:47 +0100 From: Kurt Jaeger To: Paul Koch Subject: Re: tzsetup - UTC user question Message-ID: <20150203122547.GM44537@home.opsec.eu> References: <20150203150838.5bcde9a9@akips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150203150838.5bcde9a9@akips.com> 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, 03 Feb 2015 12:25:50 -0000 Hi! > The person doing the install may not know what the clock is currently set > to, especially when installing in a VM. Perhaps the screen should display > the current machine time so they can correctly answer the question. Yes, this would help tremendously! -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 14:35:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7878924B for ; Tue, 3 Feb 2015 14:35:45 +0000 (UTC) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 3AE3A7CE for ; Tue, 3 Feb 2015 14:35:45 +0000 (UTC) Received: from m4800.rlwinm.de (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 82C4015679 for ; Tue, 3 Feb 2015 15:35:34 +0100 (CET) Message-ID: <54D0DCB6.9080104@rlwinm.de> Date: Tue, 03 Feb 2015 15:35:34 +0100 From: Crest User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: tzsetup - UTC user question References: <20150203150838.5bcde9a9@akips.com> <20150203122547.GM44537@home.opsec.eu> In-Reply-To: <20150203122547.GM44537@home.opsec.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 14:35:45 -0000 On 03.02.2015 13:25, Kurt Jaeger wrote: > Hi! > >> The person doing the install may not know what the clock is currently set >> to, especially when installing in a VM. Perhaps the screen should display >> the current machine time so they can correctly answer the question. > Yes, this would help tremendously! > Showing both would help a lot e.g. You selected %Z as local time zone. Local time is: %T %Z UTC time is: %T UTC Is this what you expected? Please bypass this screen if the user selected UTC as local time. I prefer to run my systems with UTC and a login group with :setenv=TZ=Foo/Bar,...: This avoids trouble with daylight saving and servers spread over multiple timezones. From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 20:33:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 950396F4 for ; Tue, 3 Feb 2015 20:33:44 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36DF6A80 for ; Tue, 3 Feb 2015 20:33:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t13KXa1Q037773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2015 22:33:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t13KXa1Q037773 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t13KXaAn037772; Tue, 3 Feb 2015 22:33:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Feb 2015 22:33:36 +0200 From: Konstantin Belousov To: Eric Badger Subject: Re: Filepaths in VM map for tmpfs files Message-ID: <20150203203336.GB42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> <20150202093027.GL42409@kib.kiev.ua> <54D0457E.90006@badgerio.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D0457E.90006@badgerio.us> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: 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, 03 Feb 2015 20:33:44 -0000 On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: > > On 02/02/2015 03:30 AM, Konstantin Belousov wrote: > > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: > >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > >>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? > >> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; > >> I'd opine that it is better to be transparent than make it look like > >> there is an OBJT_VNODE object there. It may be that some programs would > >> be confused by VNODE info returned on a SWAP type mapping, though I know > >> that dtrace handles it OK. > > kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. > > So this is in fact a bug in whatever used the API to access kve_path > > for KVE_TYPE_SWAP. > > Hmm, is that documented anywhere? I think it's fair to assume that > kve_vn* applies only to the VNODE type, > but I know there are several in-tree users that reference kve_path > regardless of type (ostensibly relying > on the default of an empty string). Maybe one could determine the > validity of the kve_vn* fields by > inspecting the kve_vn_type (not sure of all the consequences of that)? > Or change it to KVME_TYPE_VNODE > and deal with the below problem... There is no useful documentation for the kern.proc. sysctls. My word (and statements from other involved developers) could be considered as close to the truth as it can be. Somebody taking the efforts to document the stuff would make very valuable contribution. > > > > >>> Second, note that it is possible that the vnode is recycled, so > >>> OBJ_TMPFS flag is cleared for tmpfs swap object. The OBJ_TMPFS_NODE > >>> flag is still set then. I am not sure what to do in this case, > >>> should the type changed to KVME_TYPE_VNODE still, but kve_vn_* > >>> fields left invalid ? > >> I think if we changed to KVME_TYPE_VNODE in some cases, it should be > >> done in all cases, even if the vnode has been recycled (but leave vp == > >> NULL in that case). Though if it is left as KVME_TYPE_SWAP, then that > >> concern goes away on its own. > > Concern is not vp == NULL, but the fact that kve_vn* cannot be filled, > > there is simply no (easy) way to fetch this information. > > Right; by leaving vp == NULL, I meant "don't populate the kve_vn* > fields", which admittedly isn't a great solution. > But as you say, the information is not really available once the vnode > has been reclaimed. > > There is some inherent difficultly in the duality of the vm object here; > it would be nice if it could be treated > uniformly with other vnodes, but I think I lack the expertise to > approach a more involved solution that > would achieve this. From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 21:33:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9475D8BD for ; Tue, 3 Feb 2015 21:33:17 +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 7A36DF3 for ; Tue, 3 Feb 2015 21:33:17 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 24360A6A for ; Tue, 3 Feb 2015 13:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1422999196; bh=Av+Bk9/8YGF0Fz1pOBJnPd8cPtmBYKyEam0JeULzjYI=; h=From:To:Subject:Date; b=pXrvqHgiyvn5oRpbuKvwo0giDDBMMaFqDlEACOz8pWs4wmVLznj6cXkltv4SaXCP5 oAa0tuPJn0QQcnZKIXh5u2HnyJw311IWpUGRcTdtwUyi1oIO8RT8EiGgdMa9DcNwkD wK7niVvrNTLw8t6Ws2/OUA4nORiOHqRcx2tpXnec= From: Peter Wemm To: 'freebsd-current' Subject: PSA: If you run -current, beware! Date: Tue, 03 Feb 2015 13:33:15 -0800 Message-ID: <8089702.oYScRm8BTN@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart27906425.LkZgOZNVXH"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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, 03 Feb 2015 21:33:17 -0000 --nextPart27906425.LkZgOZNVXH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Sometime in the Dec 10th through Jan 7th timeframe a timing bug has bee= n=20 introduced to 11.x/head/-current. With HZ=3D1000 (the default for ba= re metal,=20 not for a vm); the clocks stop just after 24 days of uptime. This mean= s=20 things like cron, sleep, timeouts etc stop working. TCP/IP won't time = out or=20 retransmit, etc etc. It can get ugly. The problem is NOT in 10.x/-stable. We hit this in the freebsd.org cluster, the builds that we used are: FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken If you are running -current in a situation where it'll accumulate uptim= e, you=20 may want to take precautions. A reboot prior to 24 days uptime (as hor= rible a=20 workaround as that is) will avoid it. Yes, this is being worked on. =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 --nextPart27906425.LkZgOZNVXH 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 iQEcBAABCAAGBQJU0T6bAAoJEDXWlwnsgJ4EAQEH/Aj28f1VBcmC1KWeOnyn64U1 buR0bSWsxT//Vw+TJEtIG7K+olNFHbCzE9u1iBGbCZbIE/KSy8XfBEDZizTbIUmG +2jlSqv/DIN2GKza/X+ada9qy24Lg1LC4HaYjPE2kT3L44W0xilXW/C+ltlWaqcW p1rQ7Q0Uaew3wq6fd33FyiZ3edW0Gs1PMPmJS2naWjXf/VyBr7BuJZskJozwwt9B kMsBSniOf8hA9mHSZNDbSY2+nLKQcxJ4iG7MOaEdTMaG/hGE+JEtdob1c7hA3K5C dPo1PJZi/nW6IFiuPoWXMuUp5t3mFAyTO/hxEw4nv1eyItXfWHin6HMJIn6Hvbo= =Q3xS -----END PGP SIGNATURE----- --nextPart27906425.LkZgOZNVXH-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 22:02:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79D8A143 for ; Tue, 3 Feb 2015 22:02:43 +0000 (UTC) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 ED622690 for ; Tue, 3 Feb 2015 22:02:42 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id 10so41221566lbg.6 for ; Tue, 03 Feb 2015 14:02:41 -0800 (PST) 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=hK8Br/jFJHpzeEt9IGgRzxwcFcmYGQsrDHUNLFDDehQ=; b=iptM3Tub9hbaDvap2LURJCl0N6hVexrtp8gL6ndy6aBHCCmHOPOTrcXNhtPVpxZCyk Q+4kGHLkhjWYxtOLgK/O4rp+4DJXIFsN69ehxUEuqZLP3N5dW3tIVojRkUOXcjcPArJG DG7TR5Rq/KeizmfejSmRM34M+0SnrvXFnYx02oicPn6tZVUjFK9BtFBHlU+THAyCPD26 67+oLgd3MbK75QN03HpaZqFNa8JyXFWjuyivd9yR5iwlgFToIdMoXTjw/LIK3LSeNTxc g6UWJsXpu5qTXp24F/JPZP1dokcSHG0ZNP+ZNVTlPkjghWHx7HpynMpJ8Z9wybdQLwWf UcTw== MIME-Version: 1.0 X-Received: by 10.152.43.18 with SMTP id s18mr27335825lal.26.1423000961078; Tue, 03 Feb 2015 14:02:41 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.19.206 with HTTP; Tue, 3 Feb 2015 14:02:41 -0800 (PST) In-Reply-To: <8089702.oYScRm8BTN@overcee.wemm.org> References: <8089702.oYScRm8BTN@overcee.wemm.org> Date: Tue, 3 Feb 2015 23:02:41 +0100 X-Google-Sender-Auth: 3KCX1xfnoY36E6u0Accd7BkLgvw Message-ID: Subject: Re: PSA: If you run -current, beware! From: Luigi Rizzo To: Peter Wemm 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: Tue, 03 Feb 2015 22:02:43 -0000 On Tuesday, February 3, 2015, Peter Wemm wrote: > Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been > introduced to 11.x/head/-current. With HZ=1000 (the default for bare > metal, > not for a vm); the clocks stop just after 24 days of uptime. This means > Signed 32 bit overflow it seems from the numbers ? Wasn't that a windows feature in the old days ? :) Cheers Luigi -- -----------------------------------------+------------------------------- 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 Feb 3 22:17:09 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F018046C for ; Tue, 3 Feb 2015 22:17:09 +0000 (UTC) Received: from smtp1.ore.mailhop.org (smtp1.ore.mailhop.org [54.68.34.165]) (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 D0ED9800 for ; Tue, 3 Feb 2015 22:17:09 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp1.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YIlO5-0005Ja-Cx; Tue, 03 Feb 2015 21:52:01 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t13LprVa001928; Tue, 3 Feb 2015 14:51:58 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18gR2940urrfYlZErtqPmwT Message-ID: <1423000313.15718.354.camel@freebsd.org> Subject: Re: PSA: If you run -current, beware! From: Ian Lepore To: Peter Wemm Date: Tue, 03 Feb 2015 14:51:53 -0700 In-Reply-To: <8089702.oYScRm8BTN@overcee.wemm.org> References: <8089702.oYScRm8BTN@overcee.wemm.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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, 03 Feb 2015 22:17:10 -0000 On Tue, 2015-02-03 at 13:33 -0800, Peter Wemm wrote: > Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been > introduced to 11.x/head/-current. With HZ=1000 (the default for bare metal, > not for a vm); the clocks stop just after 24 days of uptime. This means > things like cron, sleep, timeouts etc stop working. TCP/IP won't time out or > retransmit, etc etc. It can get ugly. > > The problem is NOT in 10.x/-stable. > > We hit this in the freebsd.org cluster, the builds that we used are: > FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine > FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken > > If you are running -current in a situation where it'll accumulate uptime, you > may want to take precautions. A reboot prior to 24 days uptime (as horrible a > workaround as that is) will avoid it. > > Yes, this is being worked on. FWIW, 24.8 days is the point at which an int32_t variable counting ticks at 1khz rolls over from positive to negative numbers. -- Ian From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 00:04:29 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72D83D78; Wed, 4 Feb 2015 00:04:29 +0000 (UTC) Received: from mail-gw12.york.ac.uk (mail-gw12.york.ac.uk [144.32.129.162]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39E3B39D; Wed, 4 Feb 2015 00:04:29 +0000 (UTC) Received: from ury.york.ac.uk ([144.32.64.162]:30694) by mail-gw12.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1YInS9-0004sG-FK; Wed, 04 Feb 2015 00:04:21 +0000 Date: Wed, 4 Feb 2015 00:04:21 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: R0B_ROD Subject: Re: HP 2B19WM PCI-E SD Reader In-Reply-To: <54CFE09B.3060006@gmail.com> Message-ID: References: <54CFE09B.3060006@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, freebsd-mobile@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, 04 Feb 2015 00:04:29 -0000 On Mon, 2 Feb 2015, R0B_ROD wrote: > Thank you for the time you took to help. > > According to: > http://lists.freebsd.org/pipermail/ \ > \ freebsd-current/2013-July/042788.html > \ freebsd-questions/2014-August/259843.html > > Is the Realtek RTS5229 PCI-E SD Card Reader > supported yet??? Unfortunately, we don't have a driver for this card reader yet. It is worth checking to make sure that you do indeed have this drvice though. Can you give the output of both "pciconf -lv" and "usbconfig list" please? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 00:14:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6163CF7 for ; Wed, 4 Feb 2015 00:14: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 518CA677 for ; Wed, 4 Feb 2015 00:14:12 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7C63A11E for ; Wed, 4 Feb 2015 00:14:12 +0000 (UTC) Date: Wed, 4 Feb 2015 00:14:12 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1226377723.2.1423008852482.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #638 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 04 Feb 2015 00:14:12 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 01:05:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BBCD434 for ; Wed, 4 Feb 2015 01:05:18 +0000 (UTC) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8953ABBA for ; Wed, 4 Feb 2015 01:05:18 +0000 (UTC) Received: from [10.1.8.7] (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id 51D91276A4 for ; Wed, 4 Feb 2015 11:05:17 +1000 (EST) Message-ID: <54D1704B.8050900@akips.com> Date: Wed, 04 Feb 2015 11:05:15 +1000 From: Nick Frampton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: tzsetup chroot Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on host1.akips.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 01:05:18 -0000 We have our own FreeBSD 10.1 installation script in which we call tzsetup. I'm seeing different behaviour in tzsetup between these two invocations: tzsetup -C /mnt chroot /mnt /usr/sbin/tzsetup With the -C option, no matter which time zone I select, it asks: Does the abbreviation 'UTC' look reasonable? Using chroot, I get the expected behaviour, e.g. selecting America/New_York: Does the abbreviation 'EST' look reasonable? /mnt contains the contents of base.txz, so it looks like all the zoneinfo files are there. -Nick -- Founder, CTO www.akips.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 02:11:04 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66E68CCB; Wed, 4 Feb 2015 02:11:04 +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 4BC9E2AE; Wed, 4 Feb 2015 02:11:04 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 3D8572C0B; Tue, 3 Feb 2015 18:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1423015863; x=1423030263; bh=DhfDeQ91bYpr9U8b1UdIoEnish7b0D2EAKhOMZPmMVs=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=uUgWK9sXhgGOW2Yr40waAUzpe4bfYVzeM+OlajgbKLLDjqtbBBbtyn95ysOQP8rRL BZaIKGrwcj+e34d5wc+Lb7bxDzxIHMRuvFj3DSUGfc4lSVTOXFdZjnkB9BhttnEx79 gStTACGD0VZXCkRtmjDIVkfpuB/KPv5ce8VVAOmo= Message-ID: <54D17FB6.1080400@delphij.net> Date: Tue, 03 Feb 2015 18:11:02 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Nick Frampton , freebsd-current@freebsd.org Subject: Re: tzsetup chroot References: <54D1704B.8050900@akips.com> In-Reply-To: <54D1704B.8050900@akips.com> Content-Type: multipart/mixed; boundary="------------050606050705040702090400" Cc: edwin@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, 04 Feb 2015 02:11:04 -0000 This is a multi-part message in MIME format. --------------050606050705040702090400 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/03/15 17:05, Nick Frampton wrote: > We have our own FreeBSD 10.1 installation script in which we call > tzsetup. > > I'm seeing different behaviour in tzsetup between these two > invocations: > > tzsetup -C /mnt chroot /mnt /usr/sbin/tzsetup > > With the -C option, no matter which time zone I select, it asks: > > Does the abbreviation 'UTC' look reasonable? > > Using chroot, I get the expected behaviour, e.g. selecting > America/New_York: > > Does the abbreviation 'EST' look reasonable? > > /mnt contains the contents of base.txz, so it looks like all the > zoneinfo files are there. Could you please submit a bug ticket for this? It looks like what happens is that tzsetup does not really do a chroot(2) system call. Instead, it simulated the effect by prefixing all paths with the chroot environment. The problem is that when tzsetup is going to verify your configuration, it would use tzset(3), which does not respect the simulated chroot effect. When no zoneinfo data is present, everything would be considered as UTC. Attached is an dirty hack (ugly enough that I don't wish to commit) that changes tzsetup to use chroot instead, which should fix the problem. I'm not very satisfied with it as it does chroot() before doing init_dialog, which may well fail as the devfs is not necessarily mounted in the chroot, and on the other hand all termcap related data would be sourced from the chroot, which is probably an undesirable side effect. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.1 (FreeBSD) iQIcBAEBCgAGBQJU0X+zAAoJEJW2GBstM+nsfpwQAIwPBj11lzJS662RPBPQR6dB vb3gCGJjqRANCD+Sr8EqxzPlKOcC4UiBB5Khy39lidC+d4qgGQ3Mz3qIwjCdl3Aw KUzkFfhvspGzE25tIwsPJ3A00NjXNJGqGqcDMitfls4SdYZWzCgs+gwa3zGq+yO3 /pPMQVVhhBz2pgkqxCtznFqY9paN5lzwaOqp9HepNz1g99Q4u+KpIUI93BMcMdMD 9HtY7YQYzDCnhi4OskdIB2BrLm1NSFPMkALASTMuCplFwtyI+emYD/GzOwUF5zay Vk4QQ33Z9G1pw6jU730kFl/FU5tps35leUYUMcgiz2CG9DTz/wFRJ4SjwD4b1NYx 35nwbrhnp5TV4g94zFfY1NejSwmCpdzq5fvSYwu73yQ+pzwqA2xjXGMwICEo95Tj Zop/T9gU3g2Hglmz6zTe7m4EXdruFZrADlI6K6cPg/52HosSi7iLnkebwX0nClbQ HQeCdved38nzRBDZGaJmrDebHD3Uy+qrP5dxTaDe49JZZ+lnkceqy5s+OLQb78S3 Wt9q6GgdKLwa157K74ci/T3rSnty+dJlOXlaq2Bhbru8O7GGmIcmMtsAYzI7+C0z 0cuqsI2sXvT6i/XSjt2VK0D/aQfJ0NfpWDJ6rtlAnFc0g5UBncd8MrAfWo/KOPdH nIdamgVfmtHcglu07fBq =0pwZ -----END PGP SIGNATURE----- --------------050606050705040702090400 Content-Type: text/plain; charset=UTF-8; name="tzsetup.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="tzsetup.diff" Index: tzsetup.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 --- tzsetup.c (revision 278173) +++ tzsetup.c (working copy) @@ -40,6 +40,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include =20 @@ -944,24 +945,19 @@ main(int argc, char **argv) if (argc - optind > 1) usage(); =20 - if (chrootenv =3D=3D NULL) { - strcpy(path_zonetab, _PATH_ZONETAB); - strcpy(path_iso3166, _PATH_ISO3166); - strcpy(path_zoneinfo, _PATH_ZONEINFO); - strcpy(path_localtime, _PATH_LOCALTIME); - strcpy(path_db, _PATH_DB); - strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK); - } else { - sprintf(path_zonetab, "%s/%s", chrootenv, _PATH_ZONETAB); - sprintf(path_iso3166, "%s/%s", chrootenv, _PATH_ISO3166); - sprintf(path_zoneinfo, "%s/%s", chrootenv, _PATH_ZONEINFO); - sprintf(path_localtime, "%s/%s", chrootenv, _PATH_LOCALTIME); - sprintf(path_db, "%s/%s", chrootenv, _PATH_DB); - sprintf(path_wall_cmos_clock, "%s/%s", chrootenv, - _PATH_WALL_CMOS_CLOCK); + strcpy(path_zonetab, _PATH_ZONETAB); + strcpy(path_iso3166, _PATH_ISO3166); + strcpy(path_zoneinfo, _PATH_ZONEINFO); + strcpy(path_localtime, _PATH_LOCALTIME); + strcpy(path_db, _PATH_DB); + strcpy(path_wall_cmos_clock, _PATH_WALL_CMOS_CLOCK); + + if (chrootenv !=3D NULL) { + rv =3D chroot(chrootenv); + if (rv !=3D 0) + err(EX_OSERR, "chroot to %s", chrootenv); } =20 - /* Override the user-supplied umask. */ (void)umask(S_IWGRP | S_IWOTH); =20 --------------050606050705040702090400-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 03:01:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8139C694 for ; Wed, 4 Feb 2015 03:01:56 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 704C1AE4 for ; Wed, 4 Feb 2015 03:01:56 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 578D3153 for ; Wed, 4 Feb 2015 03:01:55 +0000 (UTC) Date: Wed, 4 Feb 2015 03:01:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1186408988.4.1423018915432.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1226377723.2.1423008852482.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1226377723.2.1423008852482.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #639 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 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: Wed, 04 Feb 2015 03:01:56 -0000 See From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 06:21:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAB4F1B7; Wed, 4 Feb 2015 06:21:17 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 A1C5FF22; Wed, 4 Feb 2015 06:21:17 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id et14so106398359pad.4; Tue, 03 Feb 2015 22:21:17 -0800 (PST) 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=xsxypjR3vT0ULde1tdSZLTMubQsu6HtJW7jaMfggxkU=; b=IeuEo1sdsdw+0F8ag7pETlPHQ8rFuOkgQHUc2jwPRcnH/0M3DtWh2xntCNnKByI9AZ jnnwiyEeC+6mKCV9kCgvlnyxZ/Wimpj8tl+2I4y5XcoHRWHy19Yda3RTSqiSqmGXGkuF Ox39A2Q+H0bywT4Z1UcxpyQg1ZJf64zIozBFsNubGKb/Un2psC5CrClbYFXN2WV9VgKN d/d7ssPoLt4vKqxEBEf5tzWZnTmPE2WYYkQv2P5WjVzRJhk35nSAarEQgZCAnheM0CPN ojY0aP27Pu2qs+MX79hba7rAMRUuJG87rxGNIk+7pXo5BL1AWo8jgmad7EPXhK383CVJ AaGQ== X-Received: by 10.70.15.2 with SMTP id t2mr43491290pdc.47.1423030876856; Tue, 03 Feb 2015 22:21:16 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:ed1d:c80e:52ee:11f? ([2601:8:ab80:7d6:ed1d:c80e:52ee:11f]) by mx.google.com with ESMTPSA id oq2sm779333pbb.60.2015.02.03.22.21.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 22:21:16 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3BB99CA0-506E-49B2-BFF5-F2CCFE22528E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libc.so dependency on libssp_nonshared.a From: Garrett Cooper In-Reply-To: <20150203074709.GA1091@reks> Date: Tue, 3 Feb 2015 22:21:14 -0800 Message-Id: <3DB0C643-31FE-44D6-8AB4-4CE007062C55@gmail.com> References: <20150201202413.GA2132@reks> <20150203074709.GA1091@reks> To: Gleb Kurtsou X-Mailer: Apple Mail (2.1878.6) Cc: Jeremie Le Hen , 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, 04 Feb 2015 06:21:18 -0000 --Apple-Mail=_3BB99CA0-506E-49B2-BFF5-F2CCFE22528E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 2, 2015, at 23:47, Gleb Kurtsou wrote: > On (02/02/2015 17:06), Jeremie Le Hen wrote: >> Hi Gleb, >> On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou = wrote: >>> I came across some build issues in libc.so and SSP. >>>=20 >>> libc.ldscript (aka libc.so) unconditionally includes = @@LIBDIR@@/libssp_nonshared.a >>>=20 >>> libssp* are not built if WITHOUT_SSP defined. >>>=20 >>> ObsoleteFiles.inc doesn't mention libssp*. >>>=20 >>> Consider WITHOUT_SSP=3Dyes case. As soon as one does clean = installworld >>> and/or removes stale libssp_nonshared.a ld fails to link anything >>> because of missing libssp_nonshared.a >>=20 >> I think nowadays it would make sense to get it of WITHOUT_SSP >> altogether. This will turn this into a non-issue. >=20 > Do you mean building libssp_nonshared unconditionally? It makes = perfect > sense. The library is a single stub function. >=20 > By building libssp* conditionally we may expect that -fstack-protector > complier option won't work. I wasn't able to reproduce this potential > problem. libc provides __stack_chk_fail and __stack_chk_guard. And I > failed to create a test case that would generate code using anything > like __memcpy_chk. >=20 > Perhaps we should change MK_SSP to operate as documented (add > -fstack-protector to CFLAGS) and consider adding MK_SSP_SUPPORT option > for libraries. Although there is no reason to have MK_SSP_SUPPORT if > that would imply failure to run binaries or compile with > -fstack-protector. Silly question: shouldn=92t libc.ldscript be built, conditionally with = libssp_nonshared.a? Doing that would be trivial=85 Are there any = concerns with doing this? --Apple-Mail=_3BB99CA0-506E-49B2-BFF5-F2CCFE22528E 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 iQEcBAEBCgAGBQJU0bpaAAoJEMZr5QU6S73erTcH/0PNYosODssohyO77gp6bgTQ DI5cfSwxdDlsCXzm/atsyIkFR/vxn1qAaE2dGZ0y5NYsxwGXyEkdLQ0QPY2Xy1/Q tcZnmHY6P40DitVQLg35BwB+kOIMRgGA8rt50AuW2KswXrGkTWjzRjPOqU0uypSB GTe4fBlq2W4nEBQb4oHBipmi97dT949KvveR4t5wOGURn4zREm4JfyjQfdPX2hg7 px/+jmn4X5w/4H6ZhMUPA4yg2LBaxtAQqva6NuJ3nbWMmb4P/pXVudfNHF7G6SLv gZR7WuCUDmUwL2etoAhwXAvmuSIyPOY2eJxDCuel5HEXj6B80WkMKuyyfoVfZCI= =atbj -----END PGP SIGNATURE----- --Apple-Mail=_3BB99CA0-506E-49B2-BFF5-F2CCFE22528E-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 09:06:21 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0B4FAB2; Wed, 4 Feb 2015 09:06:21 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (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 658B1135; Wed, 4 Feb 2015 09:06:21 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 212BA6A6050; Wed, 4 Feb 2015 10:06:18 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t1496HXS095055; Wed, 4 Feb 2015 10:06:17 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t1496H5b094310; Wed, 4 Feb 2015 10:06:17 +0100 (CET) (envelope-from lars) Date: Wed, 4 Feb 2015 10:06:17 +0100 From: Lars Engels To: Gavin Atkinson Subject: Re: HP 2B19WM PCI-E SD Reader Message-ID: <20150204090617.GC41565@e-new.0x20.net> Mail-Followup-To: Lars Engels , Gavin Atkinson , R0B_ROD , freebsd-current@freebsd.org, freebsd-mobile@freebsd.org References: <54CFE09B.3060006@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xShVoZav8KYWC5Dk" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org, R0B_ROD 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, 04 Feb 2015 09:06:21 -0000 --xShVoZav8KYWC5Dk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 2015 at 12:04:21AM +0000, Gavin Atkinson wrote: > On Mon, 2 Feb 2015, R0B_ROD wrote: > > Thank you for the time you took to help. > >=20 > > According to: > > http://lists.freebsd.org/pipermail/ \ > > \ freebsd-current/2013-July/042788.html > > \ freebsd-questions/2014-August/259843.html > >=20 > > Is the Realtek RTS5229 PCI-E SD Card Reader > > supported yet??? >=20 > Unfortunately, we don't have a driver for this card reader yet. It is=20 > worth checking to make sure that you do indeed have this drvice though. = =20 > Can you give the output of both "pciconf -lv" and "usbconfig list" please? >=20 Wouldn't it be possible to pass the PCI device to a bhyve VM running Linux like Shawn did here with his wireless card? http://0xfeedface.org/2014/12/11/FreeBSD-Intel-wifi-via-bhyve.html And then share the Filesystem with CIFS or NFS... :) --xShVoZav8KYWC5Dk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU0eEIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tQiMIALmOyLNU/Vj2bSMaL44URKU0 m44+deG4MuBZrNpLqzf5AdLU2MIJCr63XDalN9j1xAcq3oLsiFPatbyWvO325mgY S/rouPbNra0uMgr+GBWrjmlvuZR5Gau+KwGr1bg3d+N6+SazUohV94GVpCtSNeV2 z1aJaE2EuFFYtH7wYqJRkRG3TzUJ8lzq/PSYibF3h4710ukLBR4xWvFUFXBTrS32 3g2oqIh2OLFC0xEKpgc43tBgWHUm5QEi0tXkxmK0JYX10y65w+0DTovt4PEP80Q+ kLUMd2ge5vgJdYNPhw/maMuIZwqlXKxg4PBNEumlcNToN/1ty+dNxNFHJ0lsI+E= =dyUE -----END PGP SIGNATURE----- --xShVoZav8KYWC5Dk-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 13:48:14 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D965FBDE; Wed, 4 Feb 2015 13:48:14 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9B4D86F; Wed, 4 Feb 2015 13:48:14 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id at20so1998831iec.7; Wed, 04 Feb 2015 05:48:14 -0800 (PST) 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=tXnPiKBTtpWfmZ0H3eqUbMq3r29XcosBOuVx22Qixf4=; b=uLV1v8L1mKsVBJC9pb8sXRFkJxwP94RIiUqcbhw/EW07Qjnl2jR1e79njOE+K7fQVs CC1aDj3kecZEMoWByokmbBAW/OA0DNYujYj6GOxR90lMKc9eW9X8tOujqq+GmluWmAwR m6cMnTKuCDEkKClT0aG4QVAlMcVBdjWqNhXIGlwEcdGyzhGm55Cku/nLbzJlEuQ0yDEd +6F2F3ip6J75iN/pC+RKaVwXRSozP6GKuPTfeuNzFviUm2A7YElgIYXiUE4kmmTWJP24 Z2dTIt+R9p+qnbYj2TR1yiEPPMCMbjd7Y8hBuSG8oVPa6nLjz4PtFIMeGLPABDyfuYRc XzWQ== X-Received: by 10.107.27.76 with SMTP id b73mr20122774iob.64.1423057694121; Wed, 04 Feb 2015 05:48:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.91.193 with HTTP; Wed, 4 Feb 2015 05:47:53 -0800 (PST) In-Reply-To: References: From: Luca Pizzamiglio Date: Wed, 4 Feb 2015 14:47:53 +0100 Message-ID: Subject: Re: UEFI boot hangs with MINNOWBOARD To: Ed Maste Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers , 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, 04 Feb 2015 13:48:15 -0000 Hi Ed, I've got a running MinnowBoard. All problems are not FreeBSD related, but with DVI display. Setting a fixed resolution instead of a "Auto" solved the problem. Thanks for the help Best regards, pizzamig PS I'll try to get a GetMemoryMap() / ExitBootServices() retry next week On Fri, Jan 30, 2015 at 6:35 PM, Ed Maste wrote: > On 30 January 2015 at 10:57, Luca Pizzamiglio > wrote: >> Hi, >> I'm testing CURRENT on a MINNOWBOARD >> (http://www.elinux.org/Minnowboard:MinnowMax): >> >> Dual-core atom E3825 CPU >> EFI Version: 2.4.0 >> EFI: EDK II >> >> boot1.efi starts, it can found the ufs partition with loader.efi >> loader.efi fails at BT->ExitBootServices() (elf64_exec() of >> sys/boot/amd64/efi/elf64_freebsd.c) > > Which revision are you testing, and do you have any local changes? > > I built a plain -current USB stick image a while back and had no > trouble, when using the HDMI output. I don't recall the revision at > the moment, but will try again soon. Serial console won't work because > the UARTs are not quite 16550-compatible. > > We do need a GetMemoryMap() / ExitBootServices() retry though. From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 14:14:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 683C57E6 for ; Wed, 4 Feb 2015 14:14:42 +0000 (UTC) Received: from smtprelay-h22.telenor.se (smtprelay-h22.telenor.se [195.54.99.197]) (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 DE8F3C76 for ; Wed, 4 Feb 2015 14:14:41 +0000 (UTC) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h22.telenor.se (Postfix) with ESMTP id 7254FDF3F for ; Wed, 4 Feb 2015 14:51:01 +0100 (CET) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BOBQAjI9JUPD5e5VVagwZSuFBKAYlzhXUCgRJEAQEBAQEBBQEBAQExBzuEDAEBAQECATocKAsjLi0MChSIPgwB1j4BAQEBBgEBAQEBAQEbjyFegxaBEwWNKYwghUiGBoV6giQcgVGBcYE/AQEB X-IPAS-Result: A2BOBQAjI9JUPD5e5VVagwZSuFBKAYlzhXUCgRJEAQEBAQEBBQEBAQExBzuEDAEBAQECATocKAsjLi0MChSIPgwB1j4BAQEBBgEBAQEBAQEbjyFegxaBEwWNKYwghUiGBoV6giQcgVGBcYE/AQEB X-IronPort-AV: E=Sophos;i="5.09,518,1418079600"; d="scan'208";a="814676804" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb3.telenor.se with ESMTP; 04 Feb 2015 14:04:12 +0100 Received: from gw.inter-sonic.com ([212.247.8.97] helo=[192.168.171.125]) by sigyn.alvermark.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1YIzcq-000CJD-5G for freebsd-current@freebsd.org; Wed, 04 Feb 2015 14:04:12 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: UEFI boot fail on higher resolutions (Re: Acer E3-112 and UEFI) From: Jakob Alvermark In-Reply-To: <42818.213.113.68.53.1420039470.squirrel@webmail.alvermark.net> Date: Wed, 4 Feb 2015 14:04:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20876.213.113.68.53.1419950410.squirrel@webmail.alvermark.net> <54A2CC2D.3040105@freebsd.org> <42818.213.113.68.53.1420039470.squirrel@webmail.alvermark.net> To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.1085) 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, 04 Feb 2015 14:14:42 -0000 On 31 dec 2014, at 16:24, Jakob Alvermark wrote: > On Tue, December 30, 2014 17:00, Nathan Whitehorn wrote: >>=20 >=20 >> On 12/30/14 06:40, Jakob Alvermark wrote: >>=20 >>> Hi, >>>=20 >>>=20 >>> Have been playing with this machine for a while now. >>> It is a quad core Pentium N3540 (ValleyView/Bay Trail), 8 GB RAM. It >>> came with a Broadcom WiFi card which I swapped for an Intel which is >>> supported by FreeBSD. Also swapped the hard drive for an SSD. >>>=20 >>> When first trying to boot FreeBSD with UEFI it would not boot. >>> It stops after the loader is trying to start the kernel. >>> My workaround now is using refind, http://www.rodsbooks.com/refind/ >>> to set the screen resolution to 800x600. (Native is 1366x768) Only = then >>> will it boot using UEFI. I tried setting it to 1024x768, then it >>> crashes. If it helps I can get the backtrace. >>=20 >> [Not sure what's going on here] >>=20 A follow up on this: I tried this on my desktop machine (AMD FX-8350, Radeon HD 5450) to see = if it has the issue, and it has! I went on to try it on my desktop machine at work (Core i3-4130, Radeon = HD 4350) and it boots! On the Acer, resolution set to 1024x768: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0x7502f000 EFI version: 2.40 EFI Firmware: INSYDE Corp. (rev 21522.39) --- Start @ 0xffffffff802e1000 ... EFI framebuffer information: addr, size 0x80000000, 0x300000 dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 --- kernel trap12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x13 fault code =3D supervisor read data, page not = present instruction pointer =3D 0x20:0xffffffff80a20834 stack pointer =3D 0x28:0xffffffff81604170 frame pointer =3D 0x28:0xffffffff81604290 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 = 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 0 () [ thread pid 0 tid 0] Stopped at kvprintf+0xd4: movzbl (%r14),%eax .... On the home desktop resolution 1024x768: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0xb08ac000 EFI version: 2.31 EFI Firmware: American Megatrends (rev 4.653) --- Start @ 0xffffffff802e1000 ... EFI framebuffer information: addr, size 0xc0000000, 0x300000 dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 --- kernel trap12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x13 fault code =3D supervisor read data, page not = present instruction pointer =3D 0x20:0xffffffff80a20654 stack pointer =3D 0x28:0xffffffff81603d70 frame pointer =3D 0x28:0xffffffff81603e90 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 = 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 0 () [ thread pid 0 tid 0] Stopped at kvprintf+0xd4: movzbl (%r14),%eax ---- On the work desktop: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Consoles: EFI console Image base: 0xbb7aa000 EFI version: 2.31 EFI Firmware: American Megatrends (rev 4.654) --- Start @ 0xffffffff802e1000 ... EFI framebuffer information: addr, size 0xe0000000, 0x300000 dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 And then it boots normally. Does anyone have any clues on what's going on here? (This all typed manually from screenshots taken with my phone, there = might be typos.) Thanks, Jakob From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 14:25:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A519A2D for ; Wed, 4 Feb 2015 14:25:18 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id DA0FAD92 for ; Wed, 4 Feb 2015 14:25:17 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AC1B833645; Wed, 4 Feb 2015 09:25:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=CUgpV+6HCLiP f/9Dl9UhM4pQvBs=; b=RRMprvPCF8aoOmMYZnsaAq+E59VK4wp6JpKshTrlld4g B89Ap3b9H8PJog/fAKvuQgHIV4jw+waQ5CO2yfhxNNoGw1tQ55z7ygOXoKdokHhv 3UBax/ldBNWSbgTAPyZ5CMzcD8SQI4wrDtSQnUiqZ0q87mhKxE8fKDcxF1iZ+g8= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 965DA33644; Wed, 4 Feb 2015 09:25:10 -0500 (EST) Received: from [192.168.1.103] (unknown [73.164.1.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 0C16133643; Wed, 4 Feb 2015 09:25:09 -0500 (EST) Message-ID: <54D22BC1.7030202@badgerio.us> Date: Wed, 04 Feb 2015 08:25:05 -0600 From: Eric Badger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Filepaths in VM map for tmpfs files References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> <20150202093027.GL42409@kib.kiev.ua> <54D0457E.90006@badgerio.us> <20150203203336.GB42409@kib.kiev.ua> In-Reply-To: <20150203203336.GB42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9FE23802-AC79-11E4-A630-7BA29F42C9D4-46178211!pb-smtp1.pobox.com Cc: kostikbel@gmail.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 14:25:18 -0000 On 02/03/2015 02:33 PM, Konstantin Belousov wrote: > On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: >> On 02/02/2015 03:30 AM, Konstantin Belousov wrote: >>> On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: >>>> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: >>>>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? >>>> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; >>>> I'd opine that it is better to be transparent than make it look like >>>> there is an OBJT_VNODE object there. It may be that some programs would >>>> be confused by VNODE info returned on a SWAP type mapping, though I know >>>> that dtrace handles it OK. >>> kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE kve_type. >>> So this is in fact a bug in whatever used the API to access kve_path >>> for KVE_TYPE_SWAP. >> Hmm, is that documented anywhere? I think it's fair to assume that >> kve_vn* applies only to the VNODE type, >> but I know there are several in-tree users that reference kve_path >> regardless of type (ostensibly relying >> on the default of an empty string). Maybe one could determine the >> validity of the kve_vn* fields by >> inspecting the kve_vn_type (not sure of all the consequences of that)? >> Or change it to KVME_TYPE_VNODE >> and deal with the below problem... > There is no useful documentation for the kern.proc. sysctls. > My word (and statements from other involved developers) could be > considered as close to the truth as it can be. > Somebody taking the efforts to document the stuff would make very > valuable contribution. Ok. If I can get a solution figured, I'll plan to include some documentation updates. This problem is somewhat important to me, so I'm going to do some additional digging and see if I can't come up with a solution that takes into account your notes. Thanks for the help, Eric From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 14:29:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29DBFB96 for ; Wed, 4 Feb 2015 14:29:49 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EE12DD5 for ; Wed, 4 Feb 2015 14:29:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t14EThqi077740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2015 16:29:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t14EThqi077740 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t14ETfsi077739; Wed, 4 Feb 2015 16:29:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 4 Feb 2015 16:29:41 +0200 From: Konstantin Belousov To: Peter Wemm Subject: Re: PSA: If you run -current, beware! Message-ID: <20150204142941.GE42409@kib.kiev.ua> References: <8089702.oYScRm8BTN@overcee.wemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8089702.oYScRm8BTN@overcee.wemm.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: '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, 04 Feb 2015 14:29:49 -0000 On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote: > Sometime in the Dec 10th through Jan 7th timeframe a timing bug has been > introduced to 11.x/head/-current. With HZ=1000 (the default for bare metal, > not for a vm); the clocks stop just after 24 days of uptime. This means > things like cron, sleep, timeouts etc stop working. TCP/IP won't time out or > retransmit, etc etc. It can get ugly. > > The problem is NOT in 10.x/-stable. > > We hit this in the freebsd.org cluster, the builds that we used are: > FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine > FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken > > If you are running -current in a situation where it'll accumulate uptime, you > may want to take precautions. A reboot prior to 24 days uptime (as horrible a > workaround as that is) will avoid it. > > Yes, this is being worked on. So the issue is reproducable in 3 minutes after boot with the following change in kern_clock.c: volatile int ticks = INT_MAX - (/*hz*/1000 * 3 * 60); It is fixed (in the proper meaning of the word, not like worked around, covered by paper) by the patch at the end of the mail. We already have a story trying to enable much less ambitious option -fno-strict-overflow, see r259045 and the revert in r259422. I do not see other way than try one more time. Too many places in kernel depend on the correctly wrapping 2-complement arithmetic, among others are callweel and scheduler. diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk index c031b3a..eb7ce2f 100644 --- a/sys/conf/kern.mk +++ b/sys/conf/kern.mk @@ -158,6 +158,11 @@ INLINE_LIMIT?= 8000 CFLAGS+= -ffreestanding # +# Make signed arithmetic wrap. +# +CFLAGS+= -fwrapv + +# # GCC SSP support # .if ${MK_SSP} != "no" && \ From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 15:11:47 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0279C910 for ; Wed, 4 Feb 2015 15:11:47 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB5113F0 for ; Wed, 4 Feb 2015 15:11:46 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wo20so1808357obc.5 for ; Wed, 04 Feb 2015 07:11:46 -0800 (PST) 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=FoRn1eFnbSuhCirs6bbXeUN03Qe6++4Ab9i4aOlQt1M=; b=FmZ00HB8wEg+j6yDYtdMNyfZuOj7nrsA39Jd44f1dKxEYFZz6WlVPlwqKDaDTRxUib xs0Rt9wkQYT/Qb7cspeRgSCflWNQwLNBp30PLo1gmQJH4fTmgcXHHN2N+NOgw7cwm53R DIm67vYV31koK4wzNSRGYe5kD3TVoSlOZhNwp3f4W8Gi02GhMkzp5aHIibYOQ5hRIX0E 6S6OciUEkMxhUdvhCaxHzqRmaQ+/Z1Nj6CU/DM50su6UJ7Hf0mlqWVOiZ+5IBMXPmY5m tL66OyClQcDofJETrmAQM02/XwUmJ7OojsKDkYvyVkNsvpqYpLBT1gQIhAiEe2Y7ayDU DGmg== MIME-Version: 1.0 X-Received: by 10.202.214.206 with SMTP id n197mr18381392oig.2.1423062706080; Wed, 04 Feb 2015 07:11:46 -0800 (PST) Received: by 10.60.54.40 with HTTP; Wed, 4 Feb 2015 07:11:46 -0800 (PST) Date: Wed, 4 Feb 2015 23:11:46 +0800 Message-ID: Subject: Freebsd-current Virtualbox crashes when enable Vt-x/AMD Virtualization From: Claudius Chan To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:11:47 -0000 Hi, this is my first post in this mailing list. I hope this is the correct way to post it here. I have issue when enable the Vt-x/AMD in Virtuabox, after the virtual machine boot up. kernel panic happened. I currently using Virtualbox version: $ pkg info |grep virtual virtualbox-ose-4.3.20_4 General-purpose full virtualizer for x86 hardware virtualbox-ose-kmod-4.3.20 VirtualBox kernel module for FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 15:46:34 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2849F6C for ; Wed, 4 Feb 2015 15:46:34 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96A2D9A6 for ; Wed, 4 Feb 2015 15:46:34 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id j5so1753470qga.5 for ; Wed, 04 Feb 2015 07:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vdFp6GcvKfddS8bDGlmAq8XcLo9P9bvf6iAP+YGSSow=; b=AwfNtHclTJnCJGHRzi8WTn0N/F5mI2o5UvXfQ8RS/Fiq8G3Q7ypKPiXge4jlzGQQQ/ lCw0FT8z70ZEKeDP2jU6R5KGZy4V6h+WpPG6+rhvJkSiZ9uBCFX/2OHGBAu/g3W/haHk k0yOZoC10xA0l/Xtrc87lew1rWSMPDA5Ip0O5bQLWy9ndgb2rRB92lqg1vz0pEfdHuwz Ctbal90vuvwAYWDtPIz2fdUWUEJ0y1tGfZ1hktaDOpG4fJVjFh1GVrpKvS/2LdmpXEGG 6jkYBsCyAfmKMpwNqrFZg5i8iq/QBC4BOdGedvVvMYtPY/iMWpkTTBWfvBzQthbacwl/ uf0g== X-Received: by 10.224.46.132 with SMTP id j4mr64588147qaf.16.1423064793776; Wed, 04 Feb 2015 07:46:33 -0800 (PST) Received: from [192.168.15.4] (c-71-226-13-107.hsd1.ga.comcast.net. [71.226.13.107]) by mx.google.com with ESMTPSA id z79sm2009251qge.48.2015.02.04.07.46.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 07:46:33 -0800 (PST) Message-ID: <54D23EE3.1010909@gmail.com> Date: Wed, 04 Feb 2015 10:46:43 -0500 From: R0B_ROD User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Freebsd-current Virtualbox crashes when enable Vt-x/AMD Virtualization References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 04 Feb 2015 15:46:35 -0000 On 02/04/2015 10:11 AM, Claudius Chan wrote: > Hi, > this is my first post in this mailing list. I hope this is the correct way > to post it here. > > I have issue when enable the Vt-x/AMD in Virtuabox, after the virtual > machine boot up. kernel panic happened. > > I currently using Virtualbox version: > $ pkg info |grep virtual > virtualbox-ose-4.3.20_4 General-purpose full virtualizer for x86 > hardware > virtualbox-ose-kmod-4.3.20 VirtualBox kernel module for FreeBSD > _______________________________________________ > 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" > Welcome. Make sure your email client puts a reply as above, this makes it easier to read in console email clients like mutt. Please post you@bsd-host:~ % cat /var/run/dmesg.boot | grep Features This may tell you if your CPU is capable of virtualization. I learned I could run bhyve by checking this file. Also please post the CPU information in same file. -- > Roberto > ^ > /"\ / 33.2947° N, 82.2006° W > \ / ASCII REBEL CAMPAIGN / (1) 4044743997 > -X- AGAINST HTML EMAIL / witchdoctor.mdf at gmail.COM > / \ AND POSTINGS / http://mdf0.blogspot.com > \_/ From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 15:47:16 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2747C11E for ; Wed, 4 Feb 2015 15:47:16 +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 EC0B99BF for ; Wed, 4 Feb 2015 15:47:15 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C8864B945; Wed, 4 Feb 2015 10:47:13 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Filepaths in VM map for tmpfs files Date: Wed, 04 Feb 2015 10:15:04 -0500 Message-ID: <1601131.aIB9RoRbLs@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150203203336.GB42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <54D0457E.90006@badgerio.us> <20150203203336.GB42409@kib.kiev.ua> 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, 04 Feb 2015 10:47:13 -0500 (EST) Cc: Konstantin Belousov , Eric Badger 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, 04 Feb 2015 15:47:16 -0000 On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote: > On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: > > On 02/02/2015 03:30 AM, Konstantin Belousov wrote: > > > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: > > >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > > >>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? > > >> > > >> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; > > >> I'd opine that it is better to be transparent than make it look like > > >> there is an OBJT_VNODE object there. It may be that some programs would > > >> be confused by VNODE info returned on a SWAP type mapping, though I > > >> know > > >> that dtrace handles it OK. > > > > > > kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE > > > kve_type. > > > So this is in fact a bug in whatever used the API to access kve_path > > > for KVE_TYPE_SWAP. > > > > Hmm, is that documented anywhere? I think it's fair to assume that > > kve_vn* applies only to the VNODE type, > > but I know there are several in-tree users that reference kve_path > > regardless of type (ostensibly relying > > on the default of an empty string). Maybe one could determine the > > validity of the kve_vn* fields by > > inspecting the kve_vn_type (not sure of all the consequences of that)? > > Or change it to KVME_TYPE_VNODE > > and deal with the below problem... > > There is no useful documentation for the kern.proc. sysctls. > My word (and statements from other involved developers) could be > considered as close to the truth as it can be. > Somebody taking the efforts to document the stuff would make very > valuable contribution. I think that kve_path should be valid for all types (e.g. shm_open() is not a vnode but has a pathname, and that should be fixed to display if possible). In the equivalent for files (kinfo_file), the pathname is type-independent and always valid. That said, I think tmpfs nodes should be exposed as files. It is an implementation detail of tmpfs that they are swap-backed, but from a user's perspective these are files, and if you want to expose other vnode-specific fields than just the path, KVME_TYPE_VNODE would be more correct. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 16:21:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D11C7C17; Wed, 4 Feb 2015 16:21:45 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97133E15; Wed, 4 Feb 2015 16:21:45 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id tr6so3205002ieb.4; Wed, 04 Feb 2015 08:21:45 -0800 (PST) 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:content-type; bh=723QR4N+y119zyJhmGNLWWNDee9gXe3dNHwZGA/xIVY=; b=bMRmbC5+ptewDeSOhINC6GBjLXUhGoIy7pTYsJD7yM8N0cj56l4n6vHiPBl/Zv690T 5rQwOtNsZwckLWHFizbwtw92hefvjUI6yNedrLwQ5j82KNtLI0a8OXf3sJGeyocOTZ1f wV1BdbdGrkhhzOKMiGqm6HRwWF+4GnMz3SskDfsRFfKuY4fBsEIInPA6laGjVT35OTZS 5BFlFQBTem0U09u+INsRtIb7zU5hnxoMOT+0z4og7Yw96r4CoUCwm2RC723LPNiR913j T/X3HIksrdkR6SyOYjyLSup5aXh45K368cYcHaTcInFbtpPjNF46Gw72JfkD4FXi2Y2u +Ikw== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr3066201igl.6.1423066904999; Wed, 04 Feb 2015 08:21:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Wed, 4 Feb 2015 08:21:44 -0800 (PST) In-Reply-To: <20150204090617.GC41565@e-new.0x20.net> References: <54CFE09B.3060006@gmail.com> <20150204090617.GC41565@e-new.0x20.net> Date: Wed, 4 Feb 2015 08:21:44 -0800 X-Google-Sender-Auth: Am0eft8_jBF0tBY56ZH7lJrRdzg Message-ID: Subject: Re: HP 2B19WM PCI-E SD Reader From: Adrian Chadd To: Lars Engels , Gavin Atkinson , R0B_ROD , freebsd-current , "freebsd-mobile@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: Wed, 04 Feb 2015 16:21:45 -0000 ... god, people go through a lot of work to not have to write a wifi driver. :) -a On 4 February 2015 at 01:06, Lars Engels wrote: > On Wed, Feb 04, 2015 at 12:04:21AM +0000, Gavin Atkinson wrote: >> On Mon, 2 Feb 2015, R0B_ROD wrote: >> > Thank you for the time you took to help. >> > >> > According to: >> > http://lists.freebsd.org/pipermail/ \ >> > \ freebsd-current/2013-July/042788.html >> > \ freebsd-questions/2014-August/259843.html >> > >> > Is the Realtek RTS5229 PCI-E SD Card Reader >> > supported yet??? >> >> Unfortunately, we don't have a driver for this card reader yet. It is >> worth checking to make sure that you do indeed have this drvice though. >> Can you give the output of both "pciconf -lv" and "usbconfig list" please? >> > > Wouldn't it be possible to pass the PCI device to a bhyve VM running > Linux like Shawn did here with his wireless card? > http://0xfeedface.org/2014/12/11/FreeBSD-Intel-wifi-via-bhyve.html > > And then share the Filesystem with CIFS or NFS... :) From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 16:36:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C15D1EF for ; Wed, 4 Feb 2015 16:36:12 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 752F9F72 for ; Wed, 4 Feb 2015 16:36:12 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id j5so1999511qga.9 for ; Wed, 04 Feb 2015 08:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Sw5GGkDVS9JCwIt2D7N4GMimcpelCIcBkwVfQiRkkMg=; b=xfRzHycZv9G+K5+CSvX9J09nq1MsEUjMbbiKTAY3Qb9tvPOkGbeEvDmNf4JAUJGG1/ HFj8DxTvz+EI02Q9Wd7GxJOyhm0YjfdXvbORbiAsAEcMfijfTk/xMv+JGhtPALLdD300 GlDHcFcltsRshMKFLAlloaYgCns2ni6gS71u1iBra12aYvSN66jfmku1X61KCeuPojZi nOAqWjgPGJ1NXiBzmykaUr89OmysVmeZJol8lvKtoZuySF50kPfqLRG1gRJL77oqnDzQ pYJivOZBGEeKFCqk55QHe7uHjrzY2pE2LZF/aYZnmYfyVn44eGSv2vm1TfsjwaUniWGT /j1w== X-Received: by 10.229.80.3 with SMTP id r3mr22778388qck.23.1423067771562; Wed, 04 Feb 2015 08:36:11 -0800 (PST) Received: from [192.168.15.4] (c-71-226-13-107.hsd1.ga.comcast.net. [71.226.13.107]) by mx.google.com with ESMTPSA id u91sm2157472qgd.29.2015.02.04.08.36.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 08:36:10 -0800 (PST) Message-ID: <54D24A85.6000004@gmail.com> Date: Wed, 04 Feb 2015 11:36:21 -0500 From: R0B_ROD User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Claudius Chan , freebsd-current@freebsd.org Subject: Re: Freebsd-current Virtualbox crashes when enable Vt-x/AMD Virtualization References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 04 Feb 2015 16:36:12 -0000 On 02/04/2015 10:11 AM, Claudius Chan wrote: > Hi, > this is my first post in this mailing list. I hope this is the correct way > to post it here. > > I have issue when enable the Vt-x/AMD in Virtuabox, after the virtual > machine boot up. kernel panic happened. > > I currently using Virtualbox version: > $ pkg info |grep virtual > virtualbox-ose-4.3.20_4 General-purpose full virtualizer for x86 > hardware > virtualbox-ose-kmod-4.3.20 VirtualBox kernel module for FreeBSD > _______________________________________________ > 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" > Also try Enabling the CPU Virtualization Setting at UEFI/BIOS Setup. -- > Roberto > ^ > /"\ / 33.2947° N, 82.2006° W > \ / ASCII REBEL CAMPAIGN / (1) 4044743997 > -X- AGAINST HTML EMAIL / witchdoctor.mdf at gmail.COM > / \ AND POSTINGS / http://mdf0.blogspot.com > \_/ From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 16:41:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 588004EC for ; Wed, 4 Feb 2015 16:41:07 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26D22F2 for ; Wed, 4 Feb 2015 16:41:07 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id vy18so3368909iec.5 for ; Wed, 04 Feb 2015 08:41:06 -0800 (PST) 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=AzjFyhBLNf/xSdRKn4dI+5CqPOSSojy4MvtRb0n93Wo=; b=cQGVP2kJHsrsFl2homGyO6Ag753vkqwfoqcuU5hfZCToyb9K69g7yhAareNk0u0e01 haqFRo1PEpd5g9iLxB7QkWWW0np5DkzvjN1eWyeJgPuGZpRWeTaLn65bySC9TTjMY7GM 92kfe0STvstP/ZB0J2tmPF9nnTq/dx7Q7HQ4YXRGyFewLL2Gj4y6Rogqmd5HzJsTcaB1 PIk5l4UN31QIeCL16L0nmLJPzxj1blSReUnbMPEl5J2C3lJ/q+UB4bFXBoHDGf9YQJKE 6gz6RvLu2AOqQiGmm0XPuNuFkehdLkDxxmg1+EARq7DrKW85kt2UZ6DPe5dl1JD9pjkl DNrA== X-Received: by 10.107.132.165 with SMTP id o37mr27833003ioi.10.1423068066502; Wed, 04 Feb 2015 08:41:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.91.193 with HTTP; Wed, 4 Feb 2015 08:40:46 -0800 (PST) In-Reply-To: References: <20876.213.113.68.53.1419950410.squirrel@webmail.alvermark.net> <54A2CC2D.3040105@freebsd.org> <42818.213.113.68.53.1420039470.squirrel@webmail.alvermark.net> From: Luca Pizzamiglio Date: Wed, 4 Feb 2015 17:40:46 +0100 Message-ID: Subject: Re: UEFI boot fail on higher resolutions (Re: Acer E3-112 and UEFI) To: Jakob Alvermark 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, 04 Feb 2015 16:41:07 -0000 On a Minnowboard I've the same behavior, 800x600 it boots, at 1024x768 it crash, using a DVI display. best regards, pizzamig On Wed, Feb 4, 2015 at 2:04 PM, Jakob Alvermark wrote: > > On 31 dec 2014, at 16:24, Jakob Alvermark wrote: > >> On Tue, December 30, 2014 17:00, Nathan Whitehorn wrote: >>> >> >>> On 12/30/14 06:40, Jakob Alvermark wrote: >>> >>>> Hi, >>>> >>>> >>>> Have been playing with this machine for a while now. >>>> It is a quad core Pentium N3540 (ValleyView/Bay Trail), 8 GB RAM. It >>>> came with a Broadcom WiFi card which I swapped for an Intel which is >>>> supported by FreeBSD. Also swapped the hard drive for an SSD. >>>> >>>> When first trying to boot FreeBSD with UEFI it would not boot. >>>> It stops after the loader is trying to start the kernel. >>>> My workaround now is using refind, http://www.rodsbooks.com/refind/ >>>> to set the screen resolution to 800x600. (Native is 1366x768) Only then >>>> will it boot using UEFI. I tried setting it to 1024x768, then it >>>> crashes. If it helps I can get the backtrace. >>> >>> [Not sure what's going on here] >>> > > > A follow up on this: > > I tried this on my desktop machine (AMD FX-8350, Radeon HD 5450) to see if it has the issue, and it has! > I went on to try it on my desktop machine at work (Core i3-4130, Radeon HD 4350) and it boots! > > On the Acer, resolution set to 1024x768: > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0x7502f000 > EFI version: 2.40 > EFI Firmware: INSYDE Corp. (rev 21522.39) > > --- > Start @ 0xffffffff802e1000 ... > EFI framebuffer information: > addr, size 0x80000000, 0x300000 > dimensions 1024 x 768 > stride 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > --- > > kernel trap12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x13 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80a20834 > stack pointer = 0x28:0xffffffff81604170 > frame pointer = 0x28:0xffffffff81604290 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > [ thread pid 0 tid 0] > Stopped at kvprintf+0xd4: movzbl (%r14),%eax > > .... > > > > On the home desktop resolution 1024x768: > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0xb08ac000 > EFI version: 2.31 > EFI Firmware: American Megatrends (rev 4.653) > > --- > Start @ 0xffffffff802e1000 ... > EFI framebuffer information: > addr, size 0xc0000000, 0x300000 > dimensions 1024 x 768 > stride 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > --- > kernel trap12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x13 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80a20654 > stack pointer = 0x28:0xffffffff81603d70 > frame pointer = 0x28:0xffffffff81603e90 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > [ thread pid 0 tid 0] > Stopped at kvprintf+0xd4: movzbl (%r14),%eax > > ---- > > On the work desktop: > >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > Consoles: EFI console > Image base: 0xbb7aa000 > EFI version: 2.31 > EFI Firmware: American Megatrends (rev 4.654) > > --- > Start @ 0xffffffff802e1000 ... > EFI framebuffer information: > addr, size 0xe0000000, 0x300000 > dimensions 1024 x 768 > stride 1024 > masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 > > And then it boots normally. > > > Does anyone have any clues on what's going on here? > > (This all typed manually from screenshots taken with my phone, there might be typos.) > > > Thanks, > Jakob > > _______________________________________________ > 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 Feb 4 17:06:58 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B1C5AF1 for ; Wed, 4 Feb 2015 17:06:58 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 34508608 for ; Wed, 4 Feb 2015 17:06:57 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 0ADEC9208F for ; Wed, 4 Feb 2015 17:06:50 +0000 (UTC) Message-ID: <54D251B9.4060307@freebsd.org> Date: Wed, 04 Feb 2015 12:07:05 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Freebsd-current Virtualbox crashes when enable Vt-x/AMD Virtualization References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JFhwwgVHfcn1whsE0gMqn7pbidIfJqojc" 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, 04 Feb 2015 17:06:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JFhwwgVHfcn1whsE0gMqn7pbidIfJqojc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-02-04 10:11, Claudius Chan wrote: > Hi, > this is my first post in this mailing list. I hope this is the correct = way > to post it here. >=20 > I have issue when enable the Vt-x/AMD in Virtuabox, after the virtual > machine boot up. kernel panic happened. >=20 > I currently using Virtualbox version: > $ pkg info |grep virtual > virtualbox-ose-4.3.20_4 General-purpose full virtualizer for x86= > hardware > virtualbox-ose-kmod-4.3.20 VirtualBox kernel module for FreeBSD > _______________________________________________ > 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 did the kernel panic include output that might explain what the problem w= as? --=20 Allan Jude --JFhwwgVHfcn1whsE0gMqn7pbidIfJqojc 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) iQIcBAEBAgAGBQJU0lG7AAoJEJrBFpNRJZKf7bUP/1XdnrsrVWkS1+x1QNPSmgn2 TXBJr4qyaPqJB/Blk8AKlHZKDfXBbKdKcgbHfpInei5IcO2k3hB0/hlV/kSnHjcK LacU+NzKDKFQtm2NFs0cPonMc5b+tDx1A6y2+Gkpsd402X5dgCb64FmHCe7lSH6u 0yvJK52Ui7wRUEan7dwT+GW0QhFns3gWwtLQdOmw4Rwsm3Uje6ezkLmogSpMDPBm MkpgPaBr+DsQgYSNz5fVDvskcbaaEQWxn59Jd4fW10IOHOCtnUU+via3VidNy4tH +HdlaT8h1R5yLE16WNgaymC0Nf6KRGyj9CH5y881FjwdNJbN2/7e8CDBq5MPoTCu EIR2RI8XsU7iylNuhUWgEk8V1qDnzAWb0zDrwPQS4MhVmxQ0AJaQlMvYWhMKsNAT dmfWyiwSTjnXQ027SPijxQQxNzrv3odBaj6tl6udD8Kzir2jQzMWz3xQD7ApQh77 EgmsuogdMqnhHl+I1tFg3H4gHBlg7gW2ufWQk3jUIEpp0+t7ayHSUle7pjo3tB2V xD5m2oUtCO9/RDpnV/aq57sRrnVfCUKZrZcx+wFU2EdEkK5qFAUdtezSaiM9Ioxr mXCzN76Fsj2xvYgTWMvUf80emIZhVMw7besaOB7UGGkkWP8YRXr1Vld1aKwsI5iI 0xPgeg0+JyclUOFA1wWd =9NkK -----END PGP SIGNATURE----- --JFhwwgVHfcn1whsE0gMqn7pbidIfJqojc-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 17:41:52 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48A975A2 for ; Wed, 4 Feb 2015 17:41:52 +0000 (UTC) Received: from dd16522.kasserver.com (dd16522.kasserver.com [85.13.137.124]) (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 09E81ABC for ; Wed, 4 Feb 2015 17:41:51 +0000 (UTC) Received: from mx12.chaot.net (62.65.196.213.cable.starman.ee [62.65.196.213]) by dd16522.kasserver.com (Postfix) with ESMTPSA id BD19245601F for ; Wed, 4 Feb 2015 18:41:49 +0100 (CET) Received: from localhost (1001@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 32c5a412; for ; Wed, 4 Feb 2015 19:41:48 +0200 (EET) Date: Wed, 4 Feb 2015 19:41:48 +0200 From: Johannes Meixner To: current@freebsd.org Subject: i915kms.ko regression? Message-ID: <20150204174148.GB2715@mx12.chaot.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 17:41:52 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So it seems that some change between 10 and 4 days ago to the i915kms subsy= stem introduced a regression with which loading i915kms through either console, = or Xorg, blanks the screen and makes the system unresponsive in that changing = to another tty, or from Xorg back to tty, does not yield any un-blanking. =20 I don't currently have another machine to ssh in and read logfiles (so neit= her Xorg, messages or dmesg outputs can be had. =20 Is there any way I could go about debugging this issue? =20 The Laptop contains both an NVIDIA GPU as well as a Sandy/IvyBridge one, sp= ecs here: https://wiki.freebsd.org/Laptops/ASUS_UX32VD =20 Best -Johannes [ originally posted to hackers@ then swills pointed out it should be here. ] --=20 Johannes Meixner | FreeBSD Committer xmj@FreeBSD.org | http://people.freebsd.org/~xmj --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJU0lncAAoJEPyeKTcbGw0LIJYH/jQFVY1lFAiCaVANp3YQx+HN Lv/YDj3f3Uh9ppET1YhWez9B7W/KzvBNvEdQyeuyNz0rlEgaKng1Mam57ONv8nQ+ 15MWyeZmKtjUvlsAB6VP332m1ZxFQDH/wqoDLN1/tavzEC7AOKNaTmY6nBixjSTx Y/N2pcw5hrIVBK6rb4FRJVVLzcA8NMZzlos5jzGSG+UZmEYSJx6jdY2n3ZCCDjtf lO8WD/W/jyJW7GAVu4Hxe+lB9tecHjjlTomBMfbNmXTs5XYEPFUVeOm3jFRm0fdQ IIVxC3S9P4C+HwDHVtokvpIO4wZZT45jAr/kT1AeLE3DN+eJbEevT2bwhi6HApQ= =76Ek -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 17:45:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 766E7764 for ; Wed, 4 Feb 2015 17:45:23 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FC5EAE0 for ; Wed, 4 Feb 2015 17:45:23 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so2332505qge.12 for ; Wed, 04 Feb 2015 09:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=SsRX0x/2d5uV2Sy0BZrTf2opiG1ETYxVJKG3C+LKZF4=; b=ufeCW6+Q35vMFRKzPXq/lq9EDqVLNxzCnALKwdoeOdIMr4QRPndCB6MiYnSPzbT8np pndA8KPkxfHTiEk156Ke+EjLNB9b/YJ4iNhlUXO9P05cZZB2gdK8IszByWhLW/FzQzsd 980ND0275KxWQg0JBm7apczLebHkwBH7XrSDwA/R3Ol2hIVEGVSt1lUiX94Ekccpn45F Et61giZ6w7QgJi2Ou+AZXIJo3FofdrGeqH2MCxw+1IEyHw1l3AC2YN8I5kowc3Jrt0Ub 59KhNKMFa9MwsiCMG9MySxwZ0+6Upa/uhzBzSZq358A8Z3tTiUeWlFT1a7MDNiKap6PQ 5Rjg== X-Received: by 10.140.37.39 with SMTP id q36mr61385070qgq.89.1423071921745; Wed, 04 Feb 2015 09:45:21 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.140.39.209 with HTTP; Wed, 4 Feb 2015 09:45:00 -0800 (PST) In-Reply-To: <20150204142941.GE42409@kib.kiev.ua> References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150204142941.GE42409@kib.kiev.ua> From: Ed Maste Date: Wed, 4 Feb 2015 12:45:00 -0500 X-Google-Sender-Auth: ZC_67nJh9spgCrBBje9HtNAtU4c Message-ID: Subject: Re: PSA: If you run -current, beware! To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Peter Wemm 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, 04 Feb 2015 17:45:23 -0000 On 4 February 2015 at 09:29, Konstantin Belousov wrote: > > So the issue is reproducable in 3 minutes after boot with the following > change in kern_clock.c: > volatile int ticks = INT_MAX - (/*hz*/1000 * 3 * 60); > > It is fixed (in the proper meaning of the word, not like worked around, > covered by paper) by the patch at the end of the mail. > > We already have a story trying to enable much less ambitious option > -fno-strict-overflow, see r259045 and the revert in r259422. Note that -fno-strict-overflow and -fwrapv are equivalent as far as Clang is concerned: | // -fno-strict-overflow implies -fwrapv if it isn't disabled, but | // -fstrict-overflow won't turn off an explicitly enabled -fwrapv. | if (Arg *A = Args.getLastArg(options::OPT_fwrapv, | options::OPT_fno_wrapv)) { | if (A->getOption().matches(options::OPT_fwrapv)) | CmdArgs.push_back("-fwrapv"); | } else if (Arg *A = Args.getLastArg(options::OPT_fstrict_overflow, | options::OPT_fno_strict_overflow)) { | if (A->getOption().matches(options::OPT_fno_strict_overflow)) | CmdArgs.push_back("-fwrapv"); | } > I do not see other way than try one more time. Agreed. As you noted elsewhere the original issue that triggered the revert was fixed by r259609, so we should be able to just re-apply r259045. From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 20:27:37 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A5401B0 for ; Wed, 4 Feb 2015 20:27:37 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 CB827FC2 for ; Wed, 4 Feb 2015 20:27:36 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 72E8A6A61F5 for ; Wed, 4 Feb 2015 21:27:33 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t14KRXZa070634 for ; Wed, 4 Feb 2015 21:27:33 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t14KRX5U070223 for current@freebsd.org; Wed, 4 Feb 2015 21:27:33 +0100 (CET) (envelope-from lars) Date: Wed, 4 Feb 2015 21:27:33 +0100 From: Lars Engels To: current@freebsd.org Subject: Battery life with the latest drm Message-ID: <20150204202733.GN41565@e-new.0x20.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nfvf/JXVyOeI7XiA" Content-Disposition: inline X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:27:37 -0000 --nfvf/JXVyOeI7XiA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just a quick report that from my completely unscientific observations it seems that battery life is extended with the latest drm import on my Thinkpad X230. I should probably get some numbers first, but my gut feeling is that it is better. By the way on the X230 (IvyBridge i7) the loader.conf setting "drm.i915.enable_rc6=3D7" makes a huge difference. For some other reason I removed it from loader.conf and hw.acpi.battery.time showed 160 minutes. After re-adding it battery time went up to 230 minutes.=20 Lars --nfvf/JXVyOeI7XiA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU0oC1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tsmQIAMEYzJvxdnTqcZaGuBNtBqfO 3Kg9xVm2gbk6iXTu5u+YIp/0d4H5ok9M9rGFJ9jtOVkFsD4/vH620Q/eS2KBS6zm /JbAIpo1YOOo+kl9r9eVcukqsstOE++/XoATYXy9mo9u3lEgyT2Umbgh/7uPMmRi HEffqHkIUzi4kjFD/NiovH3Y64pm+QuR82jJaSkugehlecoiXVJdxN8PerK9WFPY 61Y0Xo/6uaCVxWw8SI7QNoEktmL6TjG7ejzpnMsgd3ZWqP1aMeceX3P5H5QoaOKr c7P6PXva3rWJu9rYXHZXJcgx/Ufq/J5G0mj1M8Gja0mWzZ3889C11ViSFddbQV4= =lhqn -----END PGP SIGNATURE----- --nfvf/JXVyOeI7XiA-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 21:57:11 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC0C6F7C for ; Wed, 4 Feb 2015 21:57:11 +0000 (UTC) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 560D4C70 for ; Wed, 4 Feb 2015 21:57:10 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id bs8so35073160wib.3 for ; Wed, 04 Feb 2015 13:57:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:date:organization :content-type:mime-version:content-transfer-encoding; bh=mVUDFkg4viyDo0WS0m25KgDCXzBBBFo3QVZUrrZmbcA=; b=HMvZULxaUVkn9Z9yDUm+ms2zoBQmmTgSjfmgKaYLNPuDdpKcf9uzU34O5cwQcB+bYU Li0gyu2S01uzv6usV26rFSInwUWJPpfRN/HhIl6kAi0AWt7DjzQXTj+Jfr7yKaiuBOpX /P+Z4bhbuZC17WMSmulr3RR4mJgPhayLG+YVAjpiIBeiK6ELps5NOYKSPTzyGPPf0mw7 BysSn5uq6ZnwRIU0yCpddPS0y/W/1+d5hLYHENKBQVNHOKERZTzqqAvFIqSj9OaeP1tL 4/eMCZPZ65HIS9RMYE0gkpQRKefJ7PluZD2V+QlaPi8iKq9UnKAgqs9uHAP4r2ItB8pA LPLA== X-Gm-Message-State: ALoCoQmTpLMx1KoyhaIhxQD4wdhMkBbWnxDWB3VqnYYKw8V6Q9CYurXRK+J4bt5gWNHj+XZJz2fD X-Received: by 10.195.13.168 with SMTP id ez8mr1173995wjd.30.1423087029147; Wed, 04 Feb 2015 13:57:09 -0800 (PST) Received: from xenon (105.42.broadband6.iol.cz. [88.101.42.105]) by mx.google.com with ESMTPSA id dz10sm4991206wib.17.2015.02.04.13.57.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Feb 2015 13:57:08 -0800 (PST) Message-ID: <1423087017.854.20.camel@stonehenge.sk> Subject: vt(4) sysctl inconsistency question From: Michal Varga To: current@freebsd.org Date: Wed, 04 Feb 2015 22:56:57 +0100 Organization: Stonehenge Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.10 Mime-Version: 1.0 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, 04 Feb 2015 21:57:11 -0000 I have a quick question regarding the vt driver which hopefully someone involved in its design could answer for me. Roughly 4 months ago, vt gained the ability to listen to a set of keyboard combinations controlling power/debug situations and the ability to control (or more precisely, turn off) their behavior via sysctls: http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381& Interestingly, two cases in particular (excluding SPSC which isn't implemented yet) were left out of this configuration, namely the standby and suspend modes (STBY, SUSP), making use of those keys completely non-optional. If anyone could tell me, what was the reason for not including sysctls for those two modes? m. -- Michal Varga, Stonehenge From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 23:16:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C58E17F for ; Wed, 4 Feb 2015 23:16:02 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::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 4EE3A7F1 for ; Wed, 4 Feb 2015 23:16:02 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 74570126; Wed, 4 Feb 2015 15:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1423091761; bh=4GQfQI4DAfXi221girZvkUQe0cnntESHnuZNKZnDgfc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Su3KnwcIsUrEbOun9pacU+QkFd65/ocMI4SKlq96nRNk/h//M8+7nbiUSC9aNxi5x Zw+jUhK/2WZacx46zqLuyToft5kzzb7/xxoLmX/+q8awXyb8tNISZtgtmqUICw4hKa XKCMQOLJPOug4ig9KZjJRz0QkHnKuS71TLFUQcG4= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: PSA: If you run -current, beware! Date: Wed, 04 Feb 2015 15:15:57 -0800 Message-ID: <2509923.ondFvsFdql@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150204142941.GE42409@kib.kiev.ua> References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150204142941.GE42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2822483.AiuhAghUd7"; micalg="pgp-sha256"; protocol="application/pgp-signature" Cc: Konstantin Belousov 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, 04 Feb 2015 23:16:02 -0000 --nextPart2822483.AiuhAghUd7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote: > On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote: > > Sometime in the Dec 10th through Jan 7th timeframe a timing bug has= been > > introduced to 11.x/head/-current. With HZ=3D1000 (the default fo= r bare > > metal, not for a vm); the clocks stop just after 24 days of uptime.= This > > means things like cron, sleep, timeouts etc stop working. TCP/IP w= on't > > time out or retransmit, etc etc. It can get ugly. > >=20 > > The problem is NOT in 10.x/-stable. > >=20 > > We hit this in the freebsd.org cluster, the builds that we used are= : > > FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fin= e > > FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - bro= ken > >=20 > > If you are running -current in a situation where it'll accumulate u= ptime, > > you may want to take precautions. A reboot prior to 24 days uptime= (as > > horrible a workaround as that is) will avoid it. > >=20 > > Yes, this is being worked on. >=20 > So the issue is reproducable in 3 minutes after boot with the followi= ng > change in kern_clock.c: > volatile int=09ticks =3D INT_MAX - (/*hz*/1000 * 3 * 60); >=20 > It is fixed (in the proper meaning of the word, not like worked aroun= d, > covered by paper) by the patch at the end of the mail. >=20 > We already have a story trying to enable much less ambitious option > -fno-strict-overflow, see r259045 and the revert in r259422. I do no= t > see other way than try one more time. Too many places in kernel > depend on the correctly wrapping 2-complement arithmetic, among other= s > are callweel and scheduler. Ugh. I believe I have a smoking gun that suggests that the clock-stop proble= m is=20 caused by the clang-3.5 import on Dec 31st. Backstory: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://www.airs.com/blog/archives/120 I suspect that what has happened is that clang's optimizer got better a= t=20 seeing the direct or indirect effects of integer overflow and clang (an= d gcc)=20 take advantage of that. I have used a slightly different change for about 10 years: =2D-- kern/kern_clock.c=092014-12-01 15:42:21.707911656 -0800 +++ kern/kern_clock.c=092014-12-01 15:42:21.707911656 -0800 @@ -410,6 +415,11 @@ #ifdef SW_WATCHDOG =09EVENTHANDLER_REGISTER(watchdog_list, watchdog_config, NULL, 0); #endif +=09/* +=09 * Arrange for ticks to go negative just 5 minutes after boot +=09 * to help catch sign problems sooner. +=09 */ +=09ticks =3D INT_MAX - (hz * 5 * 60); } =20 /* This came about from when we had problems with integer overflow arithme= tic in=20 the tcp stack. In any case, I'm in the process of adding -fwrapv and the early wraparo= und to=20 the freebsd.org cluster builds to give it some wider exercise. =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 --nextPart2822483.AiuhAghUd7 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 iQEcBAABCAAGBQJU0qgtAAoJEDXWlwnsgJ4ECaoH/2oGq9kp+gdyF3xCjtluy3Po y172XTnGQNIv2Z5/gVDU6i9hgFQxVHnYlUolpB1cs/B7YV/lfjUKYts1FBZrpd7c y4THM7QdUdDccSZoHTWFWQVi7cdJW8IUR6cQwke/lpwX9fcudknwBE56iYYlIDSB 6/DaAAfC1mWHagXDmaTOIBhPT6JVBCoK9SeCITNIW9unyFMAqNGqRDr0KTeFRzo7 M3aKIIzwWKpgIIIbwwu56t0VwBNfqbEjM27Yjfm1wvJTc0FF2njpm+1JnP4ivD7Q f7jFfOPPtBzC1Snge8CVnb4TdcamqAAYLPlUAjpg8e5Ey60ad+1UMom1YXPtGhY= =vo+W -----END PGP SIGNATURE----- --nextPart2822483.AiuhAghUd7-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 00:37:42 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1393AD4 for ; Thu, 5 Feb 2015 00:37:42 +0000 (UTC) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 812D62DA for ; Thu, 5 Feb 2015 00:37:41 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id l89so4041676qgf.6 for ; Wed, 04 Feb 2015 16:37:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=iwpgY0cBy9lFMwmbuJXvKqJ3LwC8qA05PXXaPPbjutg=; b=cUFN3tLt4wQyM5S16cLjzQcZb64sGf/L1gT15igBZ57M4Zt6j4wQFOI0EgsFVx5ZQW P1xBbCJCNPznGhxKqHKulDplli8L+E5oSzeGuUN2OhlCrpeLac69LASdLnfXxo9Usr2U X2kCaT+W8vjYKZd2t9RosS7ESANU/nN1uOaF3OdsKjRuowSoipc2CHqv3/PvOlqfjBna 2ZmesVHhKBM6XUd9l0/hZ/k+8gaTQDPmYN+TjaCDYsxQuXjoXDb2PvhHZtbYxNC0unaK aqoeTo6VWA52LNbgbxxsYNuPLE36rHdTicYHTVrxl1MiqxD3KzBYNzKAwuNRysTd2TfL ZlQA== X-Gm-Message-State: ALoCoQlbSgwLFq/CjWv8st7XYqhCj71NL4A+xYQUIFV9QeXoyAVjc70KLDm774Jq5QQzP9IW26RypEJbMDzGGPW/p8tCt0WhEXjAQ24g5zw+/lsUBJjkOAk7U73JH47RTmSi5umaarv9 X-Received: by 10.224.98.143 with SMTP id q15mr2256248qan.29.1423096168232; Wed, 04 Feb 2015 16:29:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Wed, 4 Feb 2015 16:29:13 -0800 (PST) From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 09:29:13 +0900 Message-ID: Subject: Weird behavior writing to SSD on 2013 MacBook To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 05 Feb 2015 00:37:42 -0000 Hi I'm thought I was gonna do some test runs with HEAD on a 2013 Macbook Air and noticed some weird behavior regarding disk I/O. This happens both when doing portsnap extract and clone from git repository= . For example portsnap extract, the extraction process (the output of it) suddenly stops, for seconds or maybe even minutes, quite many times during the whole extraction process. iostat reports ~200 MB/s on ada0 the whole time during freeze. pciconf: ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x91831b4b rev=3D0x14 hdr=3D0x00 vendor =3D 'Marvell Technology Group Ltd.' class =3D mass storage subclass =3D SATA dmesg (relevant lines?): ahci0: port 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101f mem 0xb0700000-0xb07001ff at device 0.0 on pci4 ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 GEOM: ada0: enabling Boot Camp GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling Boot Camp gpart: =3D> 34 236978109 ada0 GPT (113G) 34 6 - free - (3.0K) 40 409600 1 efi (200M) 409640 174519128 2 apple-hfs (83G) 174928768 1269536 3 apple-boot (620M) 176198304 1376 - free - (688K) 176199680 29782016 4 linux-data (14G) 205981696 2097152 5 linux-swap (1.0G) 208078848 1600 6 efi (800K) 208080448 27261368 7 freebsd-ufs (13G) 235341816 1445888 8 freebsd-swap (706M) 236787704 190439 - free - (93M) One other weird thing is that FreeBSD does not show up in the refind boot menu by default, only OSX and Linux. I have to press ESC once to reload for FreeBSD boot option to show up.. Any clues? Is my partition configuration wrong in some way? Thanks! -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. --=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 Feb 5 01:13:50 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39ACAEA0 for ; Thu, 5 Feb 2015 01:13:50 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id EB49A877 for ; Thu, 5 Feb 2015 01:13:49 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 5497393F5C for ; Thu, 5 Feb 2015 01:13:48 +0000 (UTC) Message-ID: <54D2C3DA.4060205@freebsd.org> Date: Wed, 04 Feb 2015 20:14:02 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Weird behavior writing to SSD on 2013 MacBook References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="35nTCpU7rNIWHDPAS2hDBLTF4CvlTMTHt" 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, 05 Feb 2015 01:13:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --35nTCpU7rNIWHDPAS2hDBLTF4CvlTMTHt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-02-04 19:29, Lundberg, Johannes wrote: > Hi >=20 > I'm thought I was gonna do some test runs with HEAD on a 2013 Macbook A= ir > and noticed some weird behavior regarding disk I/O. >=20 > This happens both when doing portsnap extract and clone from git reposi= tory. >=20 > For example portsnap extract, the extraction process (the output of it)= > suddenly stops, for seconds or maybe even minutes, quite many times dur= ing > the whole extraction process. > iostat reports ~200 MB/s on ada0 the whole time during freeze. >=20 >=20 > pciconf: >=20 > ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x91831b= 4b > rev=3D0x14 hdr=3D0x00 > vendor =3D 'Marvell Technology Group Ltd.' > class =3D mass storage > subclass =3D SATA >=20 >=20 > dmesg (relevant lines?): >=20 > ahci0: port > 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101f m= em > 0xb0700000-0xb07001ff at device 0.0 on pci4 > ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 >=20 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 3.x device > ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 >=20 > GEOM: ada0: enabling Boot Camp > GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling Boot C= amp >=20 >=20 > gpart: >=20 > =3D> 34 236978109 ada0 GPT (113G) > 34 6 - free - (3.0K) > 40 409600 1 efi (200M) > 409640 174519128 2 apple-hfs (83G) > 174928768 1269536 3 apple-boot (620M) > 176198304 1376 - free - (688K) > 176199680 29782016 4 linux-data (14G) > 205981696 2097152 5 linux-swap (1.0G) > 208078848 1600 6 efi (800K) > 208080448 27261368 7 freebsd-ufs (13G) > 235341816 1445888 8 freebsd-swap (706M) > 236787704 190439 - free - (93M) >=20 >=20 > One other weird thing is that FreeBSD does not show up in the refind bo= ot > menu by default, only OSX and Linux. I have to press ESC once to reload= for > FreeBSD boot option to show up.. Any clues? Is my partition configurati= on > wrong in some way? >=20 > Thanks! > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. >=20 For the disk io bit, try running 'gstat' instead of iostat, and see what it says. --=20 Allan Jude --35nTCpU7rNIWHDPAS2hDBLTF4CvlTMTHt 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) iQIcBAEBAgAGBQJU0sPdAAoJEJrBFpNRJZKfzRsQALf9AtRhrV1+5E1VNVAFWzew 6JDXNSPXxkHeJcMvpluBYyQXBUiRUNj61PVe1JAEPbUAZVVsaQmQ9k2YOUJJ9h+4 n1marzP5yMXEJTFy8Nzod1s3gosW7FIR0dloNCWgaSI1WI9dp3XRjufB348tdVg+ Gyw8K2K1fHOu8iCPoJYqbmwfE4XZ4fN0s6fYE3y7SZxN2UrutS2xYp2QfPF+mhQm mLbygptl/k5yYlWQb0qbGivNwfeixd57twmWB5NlxgJIEJBFydUogSK/9DODkfNk c27rPXI5sOELU+UPm4Aj0r2R1/t7pE4ITzMrw2iNhBBik3C+T8dlghJLWSGBDGgb /aovVuM4yhrlTOf/WkFDHrJJuBSDsmHLZwoTYqJMIKLVyRaGsZHfpkiqP9PSLt2f dv+qz0tuaMToXoXIkOkRIvFGfZNppsBxxiOYOx4YDthhuXzmnguRzOQ+FhmFyE0H BWqD2ueyWoWYKWPgmtmQUxwZmuiYAG45mYg0Ytr9Lm+jpLcl5oJyLBG5J2BxieDo l7KYRYNJNjWC83c7J2QkRRYJHaZi8QKvynU2j4a1UD0+M76JS7y5p5YEnr6zw/b3 v0xcFaI9v78TfF24l+pLds/6tL8jztMZNjYR4qgmPiONmum82c0lms5Pq0wRouwM ADHy1DJy/u9Lq2lFWTt7 =qpJL -----END PGP SIGNATURE----- --35nTCpU7rNIWHDPAS2hDBLTF4CvlTMTHt-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 01:38:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05DDD596 for ; Thu, 5 Feb 2015 01:38:52 +0000 (UTC) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B80D7A9C for ; Thu, 5 Feb 2015 01:38:51 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id w8so3958889qac.3 for ; Wed, 04 Feb 2015 17:38:50 -0800 (PST) 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=sISoIavmJj8EeQbPqFLkSn5iPrTT9Kz3EqCxRfXF6oI=; b=GJ+OyCuGBxgDquAygEAvjKfWwVTYjfrhMg5jDlGylz5VgVqMmMELPa+VC+BTzrSvJK QpJwR34T2vRnhz3bm5qgZDut4ZaIEVsTOdpplrSn318j86axPZgqo10SrBx46ISVGSuA Sbs0UXsf3E0dr1rAEjwee11nWhclqliQuic5jM4MsokVzhw157PUIuYdRg8uz8Lp01gr Tkj39h+4WxnsJb0o+B++GeXM53Fmo0G4syFEGC63K0rMfl60r8Q5U8G4hbWEiPIZM/69 MdIodnsFSRUrtq1sbJ/DmtefXUxPh4E27IujQvd2Z1Wx2xmhEx3N9LQBaeb5YJS1DoJu QdHg== X-Gm-Message-State: ALoCoQnLtlbqcdSN4pDS1Tg/CJPrmPfrhotozKV7cz7NfDPeF5yEXxFt9bZKT+2BIJVP6JrfhHWFguOIpqiyppw5P9VJpcVkha9e54PWPpo2waC+druFCJgrrNsK64FQjMKCSBYCkM0l X-Received: by 10.229.68.202 with SMTP id w10mr3078855qci.13.1423100330606; Wed, 04 Feb 2015 17:38:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Wed, 4 Feb 2015 17:38:35 -0800 (PST) In-Reply-To: <54D2C3DA.4060205@freebsd.org> References: <54D2C3DA.4060205@freebsd.org> From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 10:38:35 +0900 Message-ID: Subject: Re: Weird behavior writing to SSD on 2013 MacBook To: Allan Jude Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 01:38:52 -0000 I deleted /usr/ports and did a new portsnap extract portsnap stopped at /usr/ports/editors/teco that folder is empty and the previous folder (editors/tea) is populated with files. portsnap stopped for about 2-3 minutes and during the whole time gstat showed values like this: (disc io load was constantly fluctuating around 200 MB/s, not static) dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0 0 0 0 0 0.0 0 0 0.0 0.0| ada0p1 0 0 0 0 0.0 0 0 0.0 0.0| ada0p2 0 0 0 0 0.0 0 0 0.0 0.0| ada0p3 0 0 0 0 0.0 0 0 0.0 0.0| ada0p4 0 0 0 0 0.0 0 0 0.0 0.0| ada0p5 0 0 0 0 0.0 0 0 0.0 0.0| ada0p6 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0p7 0 0 0 0 0.0 0 0 0.0 0.0| ada0p8 0 0 0 0 0.0 0 0 0.0 0.0| gpt/EFI%20System%20Partition 0 0 0 0 0.0 0 0 0.0 0.0| gptid/ca33c17c-0ef4-4d9b-b2bb-cb37a907504b 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/EFI 0 0 0 0 0.0 0 0 0.0 0.0| gpt/Untitled 0 0 0 0 0.0 0 0 0.0 0.0| gptid/319461e8-0310-47d5-b4d1-6ba5a92cf9a9 0 0 0 0 0.0 0 0 0.0 0.0| gpt/Recovery%20HD 0 0 0 0 0.0 0 0 0.0 0.0| gptid/cb9530b7-8872-46d0-b36c-fca667b4e541 0 0 0 0 0.0 0 0 0.0 0.0| gptid/6ac11466-21c5-4420-85bc-eb1c3c7fa616 0 0 0 0 0.0 0 0 0.0 0.0| gptid/0047cc59-6b75-4508-98d0-842beafd3164 0 0 0 0 0.0 0 0 0.0 0.0| gptid/ddebb168-ac18-11e4-8f9e-283737012e32 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/NO_NAME That is, 100% busy and 200 MB/s... top shows last pid: 13709; load averages: 1.18, 0.98, 0.58 up 0+00:28:36 10:35:38 27 processes: 1 running, 26 sleeping CPU: 0.0% user, 0.0% nice, 12.3% system, 11.1% interrupt, 76.6% idle Mem: 25M Active, 651M Inact, 587M Wired, 30M Cache, 411M Buf, 2566M Free Swap: 706M Total, 706M Free I have used FreeBSD with SSD plenty and never seen this behavior before. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Thu, Feb 5, 2015 at 10:14 AM, Allan Jude wrote: > On 2015-02-04 19:29, Lundberg, Johannes wrote: > > Hi > > > > I'm thought I was gonna do some test runs with HEAD on a 2013 Macbook A= ir > > and noticed some weird behavior regarding disk I/O. > > > > This happens both when doing portsnap extract and clone from git > repository. > > > > For example portsnap extract, the extraction process (the output of it) > > suddenly stops, for seconds or maybe even minutes, quite many times > during > > the whole extraction process. > > iostat reports ~200 MB/s on ada0 the whole time during freeze. > > > > > > pciconf: > > > > ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x91831b= 4b > > rev=3D0x14 hdr=3D0x00 > > vendor =3D 'Marvell Technology Group Ltd.' > > class =3D mass storage > > subclass =3D SATA > > > > > > dmesg (relevant lines?): > > > > ahci0: port > > 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101f m= em > > 0xb0700000-0xb07001ff at device 0.0 on pci4 > > ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supported > > ahcich0: at channel 0 on ahci0 > > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-8 SATA 3.x device > > ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > > ada0: Command Queueing enabled > > ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad4 > > > > GEOM: ada0: enabling Boot Camp > > GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling Boot > Camp > > > > > > gpart: > > > > =3D> 34 236978109 ada0 GPT (113G) > > 34 6 - free - (3.0K) > > 40 409600 1 efi (200M) > > 409640 174519128 2 apple-hfs (83G) > > 174928768 1269536 3 apple-boot (620M) > > 176198304 1376 - free - (688K) > > 176199680 29782016 4 linux-data (14G) > > 205981696 2097152 5 linux-swap (1.0G) > > 208078848 1600 6 efi (800K) > > 208080448 27261368 7 freebsd-ufs (13G) > > 235341816 1445888 8 freebsd-swap (706M) > > 236787704 190439 - free - (93M) > > > > > > One other weird thing is that FreeBSD does not show up in the refind bo= ot > > menu by default, only OSX and Linux. I have to press ESC once to reload > for > > FreeBSD boot option to show up.. Any clues? Is my partition configurati= on > > wrong in some way? > > > > Thanks! > > -- > > Johannes Lundberg > > BRILLIANTSERVICE CO., LTD. > > > > For the disk io bit, try running 'gstat' instead of iostat, and see what > it says. > > -- > Allan Jude > > --=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 Feb 5 01:40:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFD156A5; Thu, 5 Feb 2015 01:40:17 +0000 (UTC) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id CE295AAF; Thu, 5 Feb 2015 01:40:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id F3F545607B; Wed, 4 Feb 2015 19:40:16 -0600 (CST) Date: Wed, 4 Feb 2015 19:40:16 -0600 From: Mark Linimon To: Adrian Chadd Subject: Re: HP 2B19WM PCI-E SD Reader Message-ID: <20150205014016.GA12219@lonesome.com> References: <54CFE09B.3060006@gmail.com> <20150204090617.GC41565@e-new.0x20.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Gavin Atkinson , "freebsd-mobile@freebsd.org" , Lars Engels , freebsd-current , R0B_ROD 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, 05 Feb 2015 01:40:18 -0000 On Wed, Feb 04, 2015 at 08:21:44AM -0800, Adrian Chadd wrote: > ... god, people go through a lot of work to not have to write a wifi driver. :) we're just concerned about you... ...r sanity. mcl From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 01:40:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 071557D6 for ; Thu, 5 Feb 2015 01:40:23 +0000 (UTC) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2894AB3 for ; Thu, 5 Feb 2015 01:40:22 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id z60so272004qgd.10 for ; Wed, 04 Feb 2015 17:40:16 -0800 (PST) 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=kcTkOd6MTjmKG5tVZZPEK9gKZypwOhV6DQU0L2kvhTg=; b=MQ41NoF57H/d6vdM2ETZcbUPknG3Jvb7zCzOLYyAE7Gy43AnCLFnhMhz9CSLarPzCL yAeOLljG36y24YonOhMMuZVDShgIeQOWZHZnTKEttDPc6CfXMCtiqZj1PROT8cemKQII MhgvoOVV1t0yzDFOgliH0UB2vhANVwQmK/RFhyAMNHkhS9hBfN4IQ18WXBvWe9sqGhs9 g8HDbBHRaFFVl9DmMRqVeUxPZd/Mg9JyOKTPnFnMv6LAxLvRnY3Suf4lCne/VSnZBXtn RswudTTa5YstFXpUiarix59AjDEdSjk/3lYz7Hbv4yooUpvXHnnb8npVmCnk5uw30S8G ZKIQ== X-Gm-Message-State: ALoCoQlQIgmY2VwYFCp3UZOceAKnk7RLegAJbhAncAjhR9A/WvRqQx6wMb5lGEiw5gaG+hCE8o2IvQqJKnJiP7uUSPentAhVGS8ch366FS5YXf76K26Mgi+gp58NFC4pfsL8VJJTpSSL X-Received: by 10.224.98.143 with SMTP id q15mr2822866qan.29.1423100415993; Wed, 04 Feb 2015 17:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Wed, 4 Feb 2015 17:40:00 -0800 (PST) In-Reply-To: References: <54D2C3DA.4060205@freebsd.org> From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 10:40:00 +0900 Message-ID: Subject: Re: Weird behavior writing to SSD on 2013 MacBook To: Allan Jude Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 01:40:23 -0000 By the way, For the second test I first ran portsnap extract without removing the old /usr/ports folder and it ran through quickly without any halts.. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Thu, Feb 5, 2015 at 10:38 AM, Lundberg, Johannes < johannes@brilliantservice.co.jp> wrote: > I deleted /usr/ports and did a new portsnap extract > > portsnap stopped at /usr/ports/editors/teco > > that folder is empty and the previous folder (editors/tea) is populated > with files. > > portsnap stopped for about 2-3 minutes and during the whole time gstat > showed values like this: (disc io load was constantly fluctuating around > 200 MB/s, not static) > > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p1 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p2 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p3 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p4 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p5 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p6 > 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0p7 > 0 0 0 0 0.0 0 0 0.0 0.0| ada0p8 > 0 0 0 0 0.0 0 0 0.0 0.0| > gpt/EFI%20System%20Partition > 0 0 0 0 0.0 0 0 0.0 0.0| > gptid/ca33c17c-0ef4-4d9b-b2bb-cb37a907504b > 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/EF= I > 0 0 0 0 0.0 0 0 0.0 0.0| gpt/Untitl= ed > 0 0 0 0 0.0 0 0 0.0 0.0| > gptid/319461e8-0310-47d5-b4d1-6ba5a92cf9a9 > 0 0 0 0 0.0 0 0 0.0 0.0| > gpt/Recovery%20HD > 0 0 0 0 0.0 0 0 0.0 0.0| > gptid/cb9530b7-8872-46d0-b36c-fca667b4e541 > 0 0 0 0 0.0 0 0 0.0 0.0| > gptid/6ac11466-21c5-4420-85bc-eb1c3c7fa616 > 0 0 0 0 0.0 0 0 0.0 0.0| > gptid/0047cc59-6b75-4508-98d0-842beafd3164 > 0 0 0 0 0.0 0 0 0.0 0.0| > gptid/ddebb168-ac18-11e4-8f9e-283737012e32 > 0 0 0 0 0.0 0 0 0.0 0.0| > msdosfs/NO_NAME > > > That is, 100% busy and 200 MB/s... > > top shows > > last pid: 13709; load averages: 1.18, 0.98, > 0.58 > up 0+00:28:36 10:35:38 > 27 processes: 1 running, 26 sleeping > CPU: 0.0% user, 0.0% nice, 12.3% system, 11.1% interrupt, 76.6% idle > Mem: 25M Active, 651M Inact, 587M Wired, 30M Cache, 411M Buf, 2566M Free > Swap: 706M Total, 706M Free > > > I have used FreeBSD with SSD plenty and never seen this behavior before. > > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. > > On Thu, Feb 5, 2015 at 10:14 AM, Allan Jude wrote= : > >> On 2015-02-04 19:29, Lundberg, Johannes wrote: >> > Hi >> > >> > I'm thought I was gonna do some test runs with HEAD on a 2013 Macbook >> Air >> > and noticed some weird behavior regarding disk I/O. >> > >> > This happens both when doing portsnap extract and clone from git >> repository. >> > >> > For example portsnap extract, the extraction process (the output of it= ) >> > suddenly stops, for seconds or maybe even minutes, quite many times >> during >> > the whole extraction process. >> > iostat reports ~200 MB/s on ada0 the whole time during freeze. >> > >> > >> > pciconf: >> > >> > ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x91831= b4b >> > rev=3D0x14 hdr=3D0x00 >> > vendor =3D 'Marvell Technology Group Ltd.' >> > class =3D mass storage >> > subclass =3D SATA >> > >> > >> > dmesg (relevant lines?): >> > >> > ahci0: port >> > 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101f >> mem >> > 0xb0700000-0xb07001ff at device 0.0 on pci4 >> > ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supported >> > ahcich0: at channel 0 on ahci0 >> > >> > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> > ada0: ATA-8 SATA 3.x device >> > ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T >> > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >> > ada0: Command Queueing enabled >> > ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) >> > ada0: Previously was known as ad4 >> > >> > GEOM: ada0: enabling Boot Camp >> > GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling Boot >> Camp >> > >> > >> > gpart: >> > >> > =3D> 34 236978109 ada0 GPT (113G) >> > 34 6 - free - (3.0K) >> > 40 409600 1 efi (200M) >> > 409640 174519128 2 apple-hfs (83G) >> > 174928768 1269536 3 apple-boot (620M) >> > 176198304 1376 - free - (688K) >> > 176199680 29782016 4 linux-data (14G) >> > 205981696 2097152 5 linux-swap (1.0G) >> > 208078848 1600 6 efi (800K) >> > 208080448 27261368 7 freebsd-ufs (13G) >> > 235341816 1445888 8 freebsd-swap (706M) >> > 236787704 190439 - free - (93M) >> > >> > >> > One other weird thing is that FreeBSD does not show up in the refind >> boot >> > menu by default, only OSX and Linux. I have to press ESC once to reloa= d >> for >> > FreeBSD boot option to show up.. Any clues? Is my partition >> configuration >> > wrong in some way? >> > >> > Thanks! >> > -- >> > Johannes Lundberg >> > BRILLIANTSERVICE CO., LTD. >> > >> >> For the disk io bit, try running 'gstat' instead of iostat, and see what >> it says. >> >> -- >> Allan Jude >> >> > --=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 Feb 5 07:17:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDA33C7A; Thu, 5 Feb 2015 07:17:56 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 991EDB84; Thu, 5 Feb 2015 07:17:56 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d66:7769:9ca9:807e] (unknown [IPv6:2001:7b8:3a7:0:d66:7769:9ca9:807e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 352195C2E; Thu, 5 Feb 2015 08:17:50 +0100 (CET) Subject: Re: Weird behavior writing to SSD on 2013 MacBook Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E005B683-8384-4AA1-9DD3-9C04C3D968F7"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 (c621b2a+) From: Dimitry Andric In-Reply-To: Date: Thu, 5 Feb 2015 08:17:41 +0100 Message-Id: References: <54D2C3DA.4060205@freebsd.org> To: "Lundberg, Johannes" X-Mailer: Apple Mail (2.2070.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: Thu, 05 Feb 2015 07:17:57 -0000 --Apple-Mail=_E005B683-8384-4AA1-9DD3-9C04C3D968F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 05 Feb 2015, at 02:38, Lundberg, Johannes = wrote: >=20 > I deleted /usr/ports and did a new portsnap extract >=20 > portsnap stopped at /usr/ports/editors/teco >=20 > that folder is empty and the previous folder (editors/tea) is = populated > with files. >=20 > portsnap stopped for about 2-3 minutes and during the whole time gstat > showed values like this: (disc io load was constantly fluctuating = around > 200 MB/s, not static) Which version of head is this? Do you see any processes in top in "flswai" state? -Dimitry --Apple-Mail=_E005B683-8384-4AA1-9DD3-9C04C3D968F7 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----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlTTGR0ACgkQsF6jCi4glqON6wCghRX/1zOQd+6VCR819fr3n7Dn yXEAnj/EFa+FBBj00j56GENUsyLabhD4 =S5xy -----END PGP SIGNATURE----- --Apple-Mail=_E005B683-8384-4AA1-9DD3-9C04C3D968F7-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 07:20:56 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8B4CEED for ; Thu, 5 Feb 2015 07:20:56 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7F769BAD for ; Thu, 5 Feb 2015 07:20:56 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id AF7E4922FE for ; Thu, 5 Feb 2015 07:20:54 +0000 (UTC) Message-ID: <54D319EA.5020709@freebsd.org> Date: Thu, 05 Feb 2015 02:21:14 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Weird behavior writing to SSD on 2013 MacBook References: <54D2C3DA.4060205@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5kBMP7fdi6oovWjAbowPKfnxWqsCgx2hj" 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, 05 Feb 2015 07:20:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5kBMP7fdi6oovWjAbowPKfnxWqsCgx2hj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-02-04 20:40, Lundberg, Johannes wrote: > By the way, >=20 > For the second test I first ran portsnap extract without removing the o= ld > /usr/ports folder and it ran through quickly without any halts.. >=20 > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. >=20 > On Thu, Feb 5, 2015 at 10:38 AM, Lundberg, Johannes < > johannes@brilliantservice.co.jp> wrote: >=20 >> I deleted /usr/ports and did a new portsnap extract >> >> portsnap stopped at /usr/ports/editors/teco >> >> that folder is empty and the previous folder (editors/tea) is populate= d >> with files. >> >> portsnap stopped for about 2-3 minutes and during the whole time gstat= >> showed values like this: (disc io load was constantly fluctuating arou= nd >> 200 MB/s, not static) >> >> dT: 1.002s w: 1.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p1 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p2 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p3 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p4 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p5 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p6 >> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0p7 >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p8 >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gpt/EFI%20System%20Partition >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gptid/ca33c17c-0ef4-4d9b-b2bb-cb37a907504b >> 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs= /EFI >> 0 0 0 0 0.0 0 0 0.0 0.0| gpt/Unt= itled >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gptid/319461e8-0310-47d5-b4d1-6ba5a92cf9a9 >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gpt/Recovery%20HD >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gptid/cb9530b7-8872-46d0-b36c-fca667b4e541 >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gptid/6ac11466-21c5-4420-85bc-eb1c3c7fa616 >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gptid/0047cc59-6b75-4508-98d0-842beafd3164 >> 0 0 0 0 0.0 0 0 0.0 0.0| >> gptid/ddebb168-ac18-11e4-8f9e-283737012e32 >> 0 0 0 0 0.0 0 0 0.0 0.0| >> msdosfs/NO_NAME >> >> >> That is, 100% busy and 200 MB/s... >> >> top shows >> >> last pid: 13709; load averages: 1.18, 0.98, >> 0.58 >> up 0+00:28:36 10:35:38 >> 27 processes: 1 running, 26 sleeping >> CPU: 0.0% user, 0.0% nice, 12.3% system, 11.1% interrupt, 76.6% idle= >> Mem: 25M Active, 651M Inact, 587M Wired, 30M Cache, 411M Buf, 2566M Fr= ee >> Swap: 706M Total, 706M Free >> >> >> I have used FreeBSD with SSD plenty and never seen this behavior befor= e. >> >> -- >> Johannes Lundberg >> BRILLIANTSERVICE CO., LTD. >> >> On Thu, Feb 5, 2015 at 10:14 AM, Allan Jude wr= ote: >> >>> On 2015-02-04 19:29, Lundberg, Johannes wrote: >>>> Hi >>>> >>>> I'm thought I was gonna do some test runs with HEAD on a 2013 Macboo= k >>> Air >>>> and noticed some weird behavior regarding disk I/O. >>>> >>>> This happens both when doing portsnap extract and clone from git >>> repository. >>>> >>>> For example portsnap extract, the extraction process (the output of = it) >>>> suddenly stops, for seconds or maybe even minutes, quite many times >>> during >>>> the whole extraction process. >>>> iostat reports ~200 MB/s on ada0 the whole time during freeze. >>>> >>>> >>>> pciconf: >>>> >>>> ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x918= 31b4b >>>> rev=3D0x14 hdr=3D0x00 >>>> vendor =3D 'Marvell Technology Group Ltd.' >>>> class =3D mass storage >>>> subclass =3D SATA >>>> >>>> >>>> dmesg (relevant lines?): >>>> >>>> ahci0: port >>>> 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101= f >>> mem >>>> 0xb0700000-0xb07001ff at device 0.0 on pci4 >>>> ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supported >>>> ahcich0: at channel 0 on ahci0 >>>> >>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>> ada0: ATA-8 SATA 3.x device >>>> ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T >>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>> ada0: Command Queueing enabled >>>> ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) >>>> ada0: Previously was known as ad4 >>>> >>>> GEOM: ada0: enabling Boot Camp >>>> GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling Boo= t >>> Camp >>>> >>>> >>>> gpart: >>>> >>>> =3D> 34 236978109 ada0 GPT (113G) >>>> 34 6 - free - (3.0K) >>>> 40 409600 1 efi (200M) >>>> 409640 174519128 2 apple-hfs (83G) >>>> 174928768 1269536 3 apple-boot (620M) >>>> 176198304 1376 - free - (688K) >>>> 176199680 29782016 4 linux-data (14G) >>>> 205981696 2097152 5 linux-swap (1.0G) >>>> 208078848 1600 6 efi (800K) >>>> 208080448 27261368 7 freebsd-ufs (13G) >>>> 235341816 1445888 8 freebsd-swap (706M) >>>> 236787704 190439 - free - (93M) >>>> >>>> >>>> One other weird thing is that FreeBSD does not show up in the refind= >>> boot >>>> menu by default, only OSX and Linux. I have to press ESC once to rel= oad >>> for >>>> FreeBSD boot option to show up.. Any clues? Is my partition >>> configuration >>>> wrong in some way? >>>> >>>> Thanks! >>>> -- >>>> Johannes Lundberg >>>> BRILLIANTSERVICE CO., LTD. >>>> >>> >>> For the disk io bit, try running 'gstat' instead of iostat, and see w= hat >>> it says. >>> >>> -- >>> Allan Jude >>> >>> >> >=20 Is the disk nearly full? very random guess, but maybe it is the SSD running its garbage collection when it runs out of space. Do you have TRIM enabled? --=20 Allan Jude --5kBMP7fdi6oovWjAbowPKfnxWqsCgx2hj 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) iQIcBAEBAgAGBQJU0xnqAAoJEJrBFpNRJZKfKmEP/2TgcLmxBf+mO1Bf7wYFiyDi 6z+2WYtLO1c5Pg9Z3PSLYtlG83u/cmqRqWqR2RsSAeBBLg3Mm/Mn/rTn3WorycrA QXBmBtGP/vXVubUqKxhHJm7rtmpU6Lt0OY8JPH7ny8JCrKVtCrT6uweUDfMEXnEr /V8lhqYVvUBbuzCXorPy2vmOsKbS7tmr9z6zqMcJoPPNiS2Rg2NZQtvDmUfB2mfq 78q47XW31ScDeOji30qPCD8cPKbZrTeye8D+yc67RsSEhP9GKbDskWE1BYCiCMlu sJo/g3iaPx6ja+L6SLjrYdkhciskEQfFh49uV846/nTEENsG4myIwsWV2o5UqZGO zfingrGAJvw0Wba0hwH0YPSC7GWQUllFZCxYKygTr5hpJdbU9y0lii90s84lTVvg 8Mjup7ko5zdzGMVSEH7OVsznvwQwa2bYWzRh/qM62dSVxXYWzk8iK8cj49UpPE1A dQRq/n8ZscSbo+eMsBdsmBGh+4U95q6f6U2KMes+jq9oL1AEmFR2+QwGptK6Vnu0 X2yUxlzZcarftSHNMzurbAf85MAgJwJcQNAF15MNE9B5JeF4o4/iOU3Rd4JNBemj 9ukwyA4RstkwiMsdxQFaXCyaes8KcrB/xzITEugWJJATjnlJ5nOp969kncxY4LJU iA1u4ck7lw10vzHfIReT =4XXa -----END PGP SIGNATURE----- --5kBMP7fdi6oovWjAbowPKfnxWqsCgx2hj-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 07:33:05 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 316AE5DD for ; Thu, 5 Feb 2015 07:33:05 +0000 (UTC) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF3A3E34 for ; Thu, 5 Feb 2015 07:33:04 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id l89so5053150qgf.6 for ; Wed, 04 Feb 2015 23:33:03 -0800 (PST) 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=tAkEL152yL9LWe7JNcbKJ2tK/yCcAQJ8zNhvLSnwYI0=; b=l7/LmaiPi4X6AHEStywq2aTiCrUDiRU213Q2X5qvDDLNd5C3ckw5jirv5+Qr5S4x3H NCOk5/48DBD/ob2TKHNplsVfs/XE5mhMYFy9XUKZ2z2Fk+5KE17bgHpMH3R6Y9kvB1dG C8XdnEeIAv5LmRxdSzLaxaGf4pg/qh8LZgS/cFeyyI5Onj6+xluDFgD6DU8FP+Cf7ioS i0UsAMQVDSdnAzmcNbICoowW0whcMVt0J7zFGsbGkvewGdp6jhD6iAqHTvLtJEYxHn56 PiuTSvI+0LS/lBnT5iefT2M0mlZkrIAfO4lJojdsIbvklLF5MjiiyYcYviqFLHpjCu7B D47Q== X-Gm-Message-State: ALoCoQnepKFo3ddPN3XEObzXgWRTkAVSjRR5FNYFM5f5CAWY+sE5vJbUwbbBCqwEQxMtYa60MN/grIomltamUgjvmMiwPO8YvLJEtnK4FcfbjTK7vxIa9EuccDb7wUs7zBNyWNsAnbB9 X-Received: by 10.224.12.19 with SMTP id v19mr5449436qav.22.1423121582947; Wed, 04 Feb 2015 23:33:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Wed, 4 Feb 2015 23:32:47 -0800 (PST) In-Reply-To: <54D319EA.5020709@freebsd.org> References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 16:32:47 +0900 Message-ID: Subject: Re: Weird behavior writing to SSD on 2013 MacBook To: Allan Jude Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 07:33:05 -0000 The release is the latest snapshot memstick image and kernel is from https://github.com/dumbbell/freebsd/tree/kms-drm-update-38. I think this problem existed before I changed kernel. I haven't changed any settings on the filesystem so I assume TRIM is off. When stopped "bsdtar" is in state "flswai". What does this mean? / is 13 GB and 80% full. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Thu, Feb 5, 2015 at 4:21 PM, Allan Jude wrote: > On 2015-02-04 20:40, Lundberg, Johannes wrote: > > By the way, > > > > For the second test I first ran portsnap extract without removing the o= ld > > /usr/ports folder and it ran through quickly without any halts.. > > > > -- > > Johannes Lundberg > > BRILLIANTSERVICE CO., LTD. > > > > On Thu, Feb 5, 2015 at 10:38 AM, Lundberg, Johannes < > > johannes@brilliantservice.co.jp> wrote: > > > >> I deleted /usr/ports and did a new portsnap extract > >> > >> portsnap stopped at /usr/ports/editors/teco > >> > >> that folder is empty and the previous folder (editors/tea) is populate= d > >> with files. > >> > >> portsnap stopped for about 2-3 minutes and during the whole time gstat > >> showed values like this: (disc io load was constantly fluctuating arou= nd > >> 200 MB/s, not static) > >> > >> dT: 1.002s w: 1.000s > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > >> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p1 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p2 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p3 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p4 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p5 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p6 > >> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0p7 > >> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p8 > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gpt/EFI%20System%20Partition > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gptid/ca33c17c-0ef4-4d9b-b2bb-cb37a907504b > >> 0 0 0 0 0.0 0 0 0.0 0.0| > msdosfs/EFI > >> 0 0 0 0 0.0 0 0 0.0 0.0| > gpt/Untitled > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gptid/319461e8-0310-47d5-b4d1-6ba5a92cf9a9 > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gpt/Recovery%20HD > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gptid/cb9530b7-8872-46d0-b36c-fca667b4e541 > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gptid/6ac11466-21c5-4420-85bc-eb1c3c7fa616 > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gptid/0047cc59-6b75-4508-98d0-842beafd3164 > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gptid/ddebb168-ac18-11e4-8f9e-283737012e32 > >> 0 0 0 0 0.0 0 0 0.0 0.0| > >> msdosfs/NO_NAME > >> > >> > >> That is, 100% busy and 200 MB/s... > >> > >> top shows > >> > >> last pid: 13709; load averages: 1.18, 0.98, > >> 0.58 > >> up 0+00:28:36 10:35:38 > >> 27 processes: 1 running, 26 sleeping > >> CPU: 0.0% user, 0.0% nice, 12.3% system, 11.1% interrupt, 76.6% idle > >> Mem: 25M Active, 651M Inact, 587M Wired, 30M Cache, 411M Buf, 2566M Fr= ee > >> Swap: 706M Total, 706M Free > >> > >> > >> I have used FreeBSD with SSD plenty and never seen this behavior befor= e. > >> > >> -- > >> Johannes Lundberg > >> BRILLIANTSERVICE CO., LTD. > >> > >> On Thu, Feb 5, 2015 at 10:14 AM, Allan Jude > wrote: > >> > >>> On 2015-02-04 19:29, Lundberg, Johannes wrote: > >>>> Hi > >>>> > >>>> I'm thought I was gonna do some test runs with HEAD on a 2013 Macboo= k > >>> Air > >>>> and noticed some weird behavior regarding disk I/O. > >>>> > >>>> This happens both when doing portsnap extract and clone from git > >>> repository. > >>>> > >>>> For example portsnap extract, the extraction process (the output of > it) > >>>> suddenly stops, for seconds or maybe even minutes, quite many times > >>> during > >>>> the whole extraction process. > >>>> iostat reports ~200 MB/s on ada0 the whole time during freeze. > >>>> > >>>> > >>>> pciconf: > >>>> > >>>> ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x918= 31b4b > >>>> rev=3D0x14 hdr=3D0x00 > >>>> vendor =3D 'Marvell Technology Group Ltd.' > >>>> class =3D mass storage > >>>> subclass =3D SATA > >>>> > >>>> > >>>> dmesg (relevant lines?): > >>>> > >>>> ahci0: port > >>>> 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101= f > >>> mem > >>>> 0xb0700000-0xb07001ff at device 0.0 on pci4 > >>>> ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supported > >>>> ahcich0: at channel 0 on ahci0 > >>>> > >>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > >>>> ada0: ATA-8 SATA 3.x device > >>>> ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T > >>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > >>>> ada0: Command Queueing enabled > >>>> ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) > >>>> ada0: Previously was known as ad4 > >>>> > >>>> GEOM: ada0: enabling Boot Camp > >>>> GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling Boo= t > >>> Camp > >>>> > >>>> > >>>> gpart: > >>>> > >>>> =3D> 34 236978109 ada0 GPT (113G) > >>>> 34 6 - free - (3.0K) > >>>> 40 409600 1 efi (200M) > >>>> 409640 174519128 2 apple-hfs (83G) > >>>> 174928768 1269536 3 apple-boot (620M) > >>>> 176198304 1376 - free - (688K) > >>>> 176199680 29782016 4 linux-data (14G) > >>>> 205981696 2097152 5 linux-swap (1.0G) > >>>> 208078848 1600 6 efi (800K) > >>>> 208080448 27261368 7 freebsd-ufs (13G) > >>>> 235341816 1445888 8 freebsd-swap (706M) > >>>> 236787704 190439 - free - (93M) > >>>> > >>>> > >>>> One other weird thing is that FreeBSD does not show up in the refind > >>> boot > >>>> menu by default, only OSX and Linux. I have to press ESC once to > reload > >>> for > >>>> FreeBSD boot option to show up.. Any clues? Is my partition > >>> configuration > >>>> wrong in some way? > >>>> > >>>> Thanks! > >>>> -- > >>>> Johannes Lundberg > >>>> BRILLIANTSERVICE CO., LTD. > >>>> > >>> > >>> For the disk io bit, try running 'gstat' instead of iostat, and see > what > >>> it says. > >>> > >>> -- > >>> Allan Jude > >>> > >>> > >> > > > > Is the disk nearly full? very random guess, but maybe it is the SSD > running its garbage collection when it runs out of space. Do you have > TRIM enabled? > > -- > Allan Jude > > --=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 Feb 5 07:48:38 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11FFF9FA for ; Thu, 5 Feb 2015 07:48:38 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FF7FF6A for ; Thu, 5 Feb 2015 07:48:37 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id gd6so4540962lab.11 for ; Wed, 04 Feb 2015 23:48:33 -0800 (PST) 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=ZXPTc5CrPKh+JvGSSLwOW/XZBZqMrkV5F5Hlub8CPko=; b=uviYlPXRRsCBH9eTiJcnj/Yu8/SFHCvVtB2QHxaVwWSsh8Tlz0/Gcjh1G7q4mfb+WS 17UU/ClhCvGikRUIV0jePxFGL1mYc3wKJLiZ3CJjvtdbG9qaHFUKx7phYn7ivyBKxLxS HWB+GwieE657jZpvdsYCbC1DG90WElrCR6a6FjHoGDTi7SapBNRjjUA8ChbNccUQ9lgS RqyHG7dXhUed6ck0ic5xt+pPvKpQ08+wFb18bGVrARItqD5Zl5yAFISYuv52sEz1Gd2t eKokB/tK4Tmys6GxJ5S/LGOLlJCYKdwDAVnQR1T8CuKybyycm5qy3/0drCigvhlaa1h7 9a0A== MIME-Version: 1.0 X-Received: by 10.112.55.199 with SMTP id u7mr1948836lbp.74.1423122513837; Wed, 04 Feb 2015 23:48:33 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.19.206 with HTTP; Wed, 4 Feb 2015 23:48:33 -0800 (PST) In-Reply-To: <2509923.ondFvsFdql@overcee.wemm.org> References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150204142941.GE42409@kib.kiev.ua> <2509923.ondFvsFdql@overcee.wemm.org> Date: Thu, 5 Feb 2015 08:48:33 +0100 X-Google-Sender-Auth: co1yx-97K2UJ5OTeWkq1wHgFWBo Message-ID: Subject: Re: PSA: If you run -current, beware! From: Luigi Rizzo To: Peter Wemm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Konstantin Belousov , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 07:48:38 -0000 On Thursday, February 5, 2015, Peter Wemm wrote: > On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote: > > On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote: > > > Sometime in the Dec 10th through Jan 7th timeframe a timing bug has > been > > > introduced to 11.x/head/-current. With HZ=1000 (the default for bare > > > metal, not for a vm); the clocks stop just after 24 days of uptime. > This > > > means things like cron, sleep, timeouts etc stop working. TCP/IP won't > > > time out or retransmit, etc etc. It can get ugly. > > > > > > The problem is NOT in 10.x/-stable. > > > > > > We hit this in the freebsd.org cluster, the builds that we used are: > > > FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine > > > FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken > > > > > > If you are running -current in a situation where it'll accumulate > uptime, > > > you may want to take precautions. A reboot prior to 24 days uptime (as > > > horrible a workaround as that is) will avoid it. > > > > > > Yes, this is being worked on. > > > > So the issue is reproducable in 3 minutes after boot with the following > > change in kern_clock.c: > > volatile int ticks = INT_MAX - (/*hz*/1000 * 3 * 60); > > > > It is fixed (in the proper meaning of the word, not like worked around, > > covered by paper) by the patch at the end of the mail. > > > > We already have a story trying to enable much less ambitious option > > -fno-strict-overflow, see r259045 and the revert in r259422. I do not > > see other way than try one more time. Too many places in kernel > > depend on the correctly wrapping 2-complement arithmetic, among others > > are callweel and scheduler. > > Rather than depending on a compiler option, wouldn't it be better/more robust to change ticks to unsigned, which has specified wrapping behavior? Cheers Luigi Ugh. > > I believe I have a smoking gun that suggests that the clock-stop problem is > caused by the clang-3.5 import on Dec 31st. > > Backstory: > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html > http://www.airs.com/blog/archives/120 > > I suspect that what has happened is that clang's optimizer got better at > seeing the direct or indirect effects of integer overflow and clang (and > gcc) > take advantage of that. > > I have used a slightly different change for about 10 years: > > --- kern/kern_clock.c 2014-12-01 15:42:21.707911656 -0800 > +++ kern/kern_clock.c 2014-12-01 15:42:21.707911656 -0800 > @@ -410,6 +415,11 @@ > #ifdef SW_WATCHDOG > EVENTHANDLER_REGISTER(watchdog_list, watchdog_config, NULL, 0); > #endif > + /* > + * Arrange for ticks to go negative just 5 minutes after boot > + * to help catch sign problems sooner. > + */ > + ticks = INT_MAX - (hz * 5 * 60); > } > > /* > > This came about from when we had problems with integer overflow arithmetic > in > the tcp stack. > > In any case, I'm in the process of adding -fwrapv and the early wraparound > to > the freebsd.org cluster builds to give it some wider exercise. > > -- > Peter Wemm - peter@wemm.org ; peter@FreeBSD.org; > peter@yahoo-inc.com ; KI6FJV > UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 -- -----------------------------------------+------------------------------- 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 Thu Feb 5 07:57:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 248BDCFB; Thu, 5 Feb 2015 07:57:10 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B99B4122; Thu, 5 Feb 2015 07:57:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::d66:7769:9ca9:807e] (unknown [IPv6:2001:7b8:3a7:0:d66:7769:9ca9:807e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 054735C2E; Thu, 5 Feb 2015 08:57:05 +0100 (CET) Subject: Re: Weird behavior writing to SSD on 2013 MacBook Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F0CA1BB8-6CFF-40A4-8926-D637EA990818"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 (c621b2a+) From: Dimitry Andric In-Reply-To: Date: Thu, 5 Feb 2015 08:56:59 +0100 Message-Id: References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> To: "Lundberg, Johannes" X-Mailer: Apple Mail (2.2070.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: Thu, 05 Feb 2015 07:57:10 -0000 --Apple-Mail=_F0CA1BB8-6CFF-40A4-8926-D637EA990818 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If you let bsdtar continue, and press control-T a few times, does the user time (u) increase at all? Does it ever go any further, if you let it run for a very long time? I believe a problem may have been introduced by r277922, leading to filesystem hangs in some scenarios. It looks like this commit is also in dumbbell's github fork: = https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a810= 86899f521 -Dimitry > On 05 Feb 2015, at 08:32, Lundberg, Johannes = wrote: >=20 > The release is the latest snapshot memstick image and kernel is from > https://github.com/dumbbell/freebsd/tree/kms-drm-update-38. >=20 > I think this problem existed before I changed kernel. >=20 > I haven't changed any settings on the filesystem so I assume TRIM is = off. >=20 > When stopped "bsdtar" is in state "flswai". What does this mean? >=20 > / is 13 GB and 80% full. >=20 >=20 > -- > Johannes Lundberg > BRILLIANTSERVICE CO., LTD. >=20 > On Thu, Feb 5, 2015 at 4:21 PM, Allan Jude = wrote: >=20 >> On 2015-02-04 20:40, Lundberg, Johannes wrote: >>> By the way, >>>=20 >>> For the second test I first ran portsnap extract without removing = the old >>> /usr/ports folder and it ran through quickly without any halts.. >>>=20 >>> -- >>> Johannes Lundberg >>> BRILLIANTSERVICE CO., LTD. >>>=20 >>> On Thu, Feb 5, 2015 at 10:38 AM, Lundberg, Johannes < >>> johannes@brilliantservice.co.jp> wrote: >>>=20 >>>> I deleted /usr/ports and did a new portsnap extract >>>>=20 >>>> portsnap stopped at /usr/ports/editors/teco >>>>=20 >>>> that folder is empty and the previous folder (editors/tea) is = populated >>>> with files. >>>>=20 >>>> portsnap stopped for about 2-3 minutes and during the whole time = gstat >>>> showed values like this: (disc io load was constantly fluctuating = around >>>> 200 MB/s, not static) >>>>=20 >>>> dT: 1.002s w: 1.000s >>>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >>>> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p1 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p2 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p3 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p4 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p5 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p6 >>>> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| = ada0p7 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| = ada0p8 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gpt/EFI%20System%20Partition >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gptid/ca33c17c-0ef4-4d9b-b2bb-cb37a907504b >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >> msdosfs/EFI >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >> gpt/Untitled >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gptid/319461e8-0310-47d5-b4d1-6ba5a92cf9a9 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gpt/Recovery%20HD >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gptid/cb9530b7-8872-46d0-b36c-fca667b4e541 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gptid/6ac11466-21c5-4420-85bc-eb1c3c7fa616 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gptid/0047cc59-6b75-4508-98d0-842beafd3164 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> gptid/ddebb168-ac18-11e4-8f9e-283737012e32 >>>> 0 0 0 0 0.0 0 0 0.0 0.0| >>>> msdosfs/NO_NAME >>>>=20 >>>>=20 >>>> That is, 100% busy and 200 MB/s... >>>>=20 >>>> top shows >>>>=20 >>>> last pid: 13709; load averages: 1.18, 0.98, >>>> 0.58 >>>> up 0+00:28:36 10:35:38 >>>> 27 processes: 1 running, 26 sleeping >>>> CPU: 0.0% user, 0.0% nice, 12.3% system, 11.1% interrupt, 76.6% = idle >>>> Mem: 25M Active, 651M Inact, 587M Wired, 30M Cache, 411M Buf, 2566M = Free >>>> Swap: 706M Total, 706M Free >>>>=20 >>>>=20 >>>> I have used FreeBSD with SSD plenty and never seen this behavior = before. >>>>=20 >>>> -- >>>> Johannes Lundberg >>>> BRILLIANTSERVICE CO., LTD. >>>>=20 >>>> On Thu, Feb 5, 2015 at 10:14 AM, Allan Jude >> wrote: >>>>=20 >>>>> On 2015-02-04 19:29, Lundberg, Johannes wrote: >>>>>> Hi >>>>>>=20 >>>>>> I'm thought I was gonna do some test runs with HEAD on a 2013 = Macbook >>>>> Air >>>>>> and noticed some weird behavior regarding disk I/O. >>>>>>=20 >>>>>> This happens both when doing portsnap extract and clone from git >>>>> repository. >>>>>>=20 >>>>>> For example portsnap extract, the extraction process (the output = of >> it) >>>>>> suddenly stops, for seconds or maybe even minutes, quite many = times >>>>> during >>>>>> the whole extraction process. >>>>>> iostat reports ~200 MB/s on ada0 the whole time during freeze. >>>>>>=20 >>>>>>=20 >>>>>> pciconf: >>>>>>=20 >>>>>> ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b = chip=3D0x91831b4b >>>>>> rev=3D0x14 hdr=3D0x00 >>>>>> vendor =3D 'Marvell Technology Group Ltd.' >>>>>> class =3D mass storage >>>>>> subclass =3D SATA >>>>>>=20 >>>>>>=20 >>>>>> dmesg (relevant lines?): >>>>>>=20 >>>>>> ahci0: port >>>>>> = 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101f >>>>> mem >>>>>> 0xb0700000-0xb07001ff at device 0.0 on pci4 >>>>>> ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not = supported >>>>>> ahcich0: at channel 0 on ahci0 >>>>>>=20 >>>>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>>>> ada0: ATA-8 SATA 3.x device >>>>>> ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T >>>>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>>>> ada0: Command Queueing enabled >>>>>> ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) >>>>>> ada0: Previously was known as ad4 >>>>>>=20 >>>>>> GEOM: ada0: enabling Boot Camp >>>>>> GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling = Boot >>>>> Camp >>>>>>=20 >>>>>>=20 >>>>>> gpart: >>>>>>=20 >>>>>> =3D> 34 236978109 ada0 GPT (113G) >>>>>> 34 6 - free - (3.0K) >>>>>> 40 409600 1 efi (200M) >>>>>> 409640 174519128 2 apple-hfs (83G) >>>>>> 174928768 1269536 3 apple-boot (620M) >>>>>> 176198304 1376 - free - (688K) >>>>>> 176199680 29782016 4 linux-data (14G) >>>>>> 205981696 2097152 5 linux-swap (1.0G) >>>>>> 208078848 1600 6 efi (800K) >>>>>> 208080448 27261368 7 freebsd-ufs (13G) >>>>>> 235341816 1445888 8 freebsd-swap (706M) >>>>>> 236787704 190439 - free - (93M) >>>>>>=20 >>>>>>=20 >>>>>> One other weird thing is that FreeBSD does not show up in the = refind >>>>> boot >>>>>> menu by default, only OSX and Linux. I have to press ESC once to >> reload >>>>> for >>>>>> FreeBSD boot option to show up.. Any clues? Is my partition >>>>> configuration >>>>>> wrong in some way? >>>>>>=20 >>>>>> Thanks! >>>>>> -- >>>>>> Johannes Lundberg >>>>>> BRILLIANTSERVICE CO., LTD. >>>>>>=20 >>>>>=20 >>>>> For the disk io bit, try running 'gstat' instead of iostat, and = see >> what >>>>> it says. >>>>>=20 >>>>> -- >>>>> Allan Jude >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> Is the disk nearly full? very random guess, but maybe it is the SSD >> running its garbage collection when it runs out of space. Do you have >> TRIM enabled? >>=20 >> -- >> Allan Jude >>=20 >>=20 >=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. > _______________________________________________ > 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" --Apple-Mail=_F0CA1BB8-6CFF-40A4-8926-D637EA990818 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----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlTTIlEACgkQsF6jCi4glqNVwACgoPSJ+0o8rZ5EZLigH/iHKF2d 2MoAn1oSOG5r/3ySG79qE2sdaRK/MX+1 =F2vu -----END PGP SIGNATURE----- --Apple-Mail=_F0CA1BB8-6CFF-40A4-8926-D637EA990818-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 08:08:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6295E98 for ; Thu, 5 Feb 2015 08:08:12 +0000 (UTC) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87BD71FB for ; Thu, 5 Feb 2015 08:08:12 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id j5so5115633qga.5 for ; Thu, 05 Feb 2015 00:08:11 -0800 (PST) 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=sbiiP23qUb6pIlMn64G+LUF5T3YbTR6yc3CZu6ptSo4=; b=MW52OlRBVkMQAp6WjefhHQw3aLzkg9c/L6Smn19DJv6Ha1UTz09LNQmwt8a5CNnoYe UJdcaGaPGhP6uLREeVigFSJRzXH4ToH0AJvzg4Ud7Y2pcP8trw4Hk45DOJFpO6X8xxqW 5+3JHpiJ2ms8VOkE8IqqQQF1vspwXjO4pmfpmT2/xx2V8dU0GcGiiuHFDADwoUSNjNib nM4tBp1pJXBeS+yopW/OrobcSkT0uNrg9qOnc2jqLfQjqZ7MTk00sZNGrQuIqXiFmOHt Sy6BqBVNOKlGe9S9IBOCpDA7TPCDzS5vvSBnv544rN9/z0iluKeteGeuK6+sn3UbIuNf xkmg== X-Gm-Message-State: ALoCoQkUHtQNcr80sdkurdcQOl3zh0JvOChNQT/mZ8FtHNPW61VWpXVQbrgNXAL28WML13rY+p8HRy/RfQzHZgoh0/lF8ra9cAScQIiWQjEdDgQAkHuT8Ef5ZUjbV6RLDHwT+ZMABgYZ X-Received: by 10.140.36.239 with SMTP id p102mr5704006qgp.8.1423123690981; Thu, 05 Feb 2015 00:08:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.215.36 with HTTP; Thu, 5 Feb 2015 00:07:55 -0800 (PST) In-Reply-To: References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 17:07:55 +0900 Message-ID: Subject: Re: Weird behavior writing to SSD on 2013 MacBook To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current , 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: Thu, 05 Feb 2015 08:08:12 -0000 The only values that change are "load" and "r". "u" and "s" are 0.00. If I wait long enough it always continues but might be several minutes. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Thu, Feb 5, 2015 at 4:56 PM, Dimitry Andric wrote: > If you let bsdtar continue, and press control-T a few times, does the > user time (u) increase at all? Does it ever go any further, if you let > it run for a very long time? > > I believe a problem may have been introduced by r277922, leading to > filesystem hangs in some scenarios. It looks like this commit is also > in dumbbell's github fork: > > > https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81= 086899f521 > > -Dimitry > > > On 05 Feb 2015, at 08:32, Lundberg, Johannes < > johannes@brilliantservice.co.jp> wrote: > > > > The release is the latest snapshot memstick image and kernel is from > > https://github.com/dumbbell/freebsd/tree/kms-drm-update-38. > > > > I think this problem existed before I changed kernel. > > > > I haven't changed any settings on the filesystem so I assume TRIM is of= f. > > > > When stopped "bsdtar" is in state "flswai". What does this mean? > > > > / is 13 GB and 80% full. > > > > > > -- > > Johannes Lundberg > > BRILLIANTSERVICE CO., LTD. > > > > On Thu, Feb 5, 2015 at 4:21 PM, Allan Jude > wrote: > > > >> On 2015-02-04 20:40, Lundberg, Johannes wrote: > >>> By the way, > >>> > >>> For the second test I first ran portsnap extract without removing the > old > >>> /usr/ports folder and it ran through quickly without any halts.. > >>> > >>> -- > >>> Johannes Lundberg > >>> BRILLIANTSERVICE CO., LTD. > >>> > >>> On Thu, Feb 5, 2015 at 10:38 AM, Lundberg, Johannes < > >>> johannes@brilliantservice.co.jp> wrote: > >>> > >>>> I deleted /usr/ports and did a new portsnap extract > >>>> > >>>> portsnap stopped at /usr/ports/editors/teco > >>>> > >>>> that folder is empty and the previous folder (editors/tea) is > populated > >>>> with files. > >>>> > >>>> portsnap stopped for about 2-3 minutes and during the whole time gst= at > >>>> showed values like this: (disc io load was constantly fluctuating > around > >>>> 200 MB/s, not static) > >>>> > >>>> dT: 1.002s w: 1.000s > >>>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > >>>> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p1 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p2 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p3 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p4 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p5 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p6 > >>>> 1240 43523 0 0 0.0 43523 220158 24.1 99.5| ada0p7 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| ada0p8 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gpt/EFI%20System%20Partition > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gptid/ca33c17c-0ef4-4d9b-b2bb-cb37a907504b > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >> msdosfs/EFI > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >> gpt/Untitled > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gptid/319461e8-0310-47d5-b4d1-6ba5a92cf9a9 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gpt/Recovery%20HD > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gptid/cb9530b7-8872-46d0-b36c-fca667b4e541 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gptid/6ac11466-21c5-4420-85bc-eb1c3c7fa616 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gptid/0047cc59-6b75-4508-98d0-842beafd3164 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> gptid/ddebb168-ac18-11e4-8f9e-283737012e32 > >>>> 0 0 0 0 0.0 0 0 0.0 0.0| > >>>> msdosfs/NO_NAME > >>>> > >>>> > >>>> That is, 100% busy and 200 MB/s... > >>>> > >>>> top shows > >>>> > >>>> last pid: 13709; load averages: 1.18, 0.98, > >>>> 0.58 > >>>> up 0+00:28:36 10:35:38 > >>>> 27 processes: 1 running, 26 sleeping > >>>> CPU: 0.0% user, 0.0% nice, 12.3% system, 11.1% interrupt, 76.6% id= le > >>>> Mem: 25M Active, 651M Inact, 587M Wired, 30M Cache, 411M Buf, 2566M > Free > >>>> Swap: 706M Total, 706M Free > >>>> > >>>> > >>>> I have used FreeBSD with SSD plenty and never seen this behavior > before. > >>>> > >>>> -- > >>>> Johannes Lundberg > >>>> BRILLIANTSERVICE CO., LTD. > >>>> > >>>> On Thu, Feb 5, 2015 at 10:14 AM, Allan Jude > >> wrote: > >>>> > >>>>> On 2015-02-04 19:29, Lundberg, Johannes wrote: > >>>>>> Hi > >>>>>> > >>>>>> I'm thought I was gonna do some test runs with HEAD on a 2013 > Macbook > >>>>> Air > >>>>>> and noticed some weird behavior regarding disk I/O. > >>>>>> > >>>>>> This happens both when doing portsnap extract and clone from git > >>>>> repository. > >>>>>> > >>>>>> For example portsnap extract, the extraction process (the output o= f > >> it) > >>>>>> suddenly stops, for seconds or maybe even minutes, quite many time= s > >>>>> during > >>>>>> the whole extraction process. > >>>>>> iostat reports ~200 MB/s on ada0 the whole time during freeze. > >>>>>> > >>>>>> > >>>>>> pciconf: > >>>>>> > >>>>>> ahci0@pci0:4:0:0: class=3D0x010601 card=3D0x91831b4b chip=3D0x9= 1831b4b > >>>>>> rev=3D0x14 hdr=3D0x00 > >>>>>> vendor =3D 'Marvell Technology Group Ltd.' > >>>>>> class =3D mass storage > >>>>>> subclass =3D SATA > >>>>>> > >>>>>> > >>>>>> dmesg (relevant lines?): > >>>>>> > >>>>>> ahci0: port > >>>>>> > 0x1028-0x102f,0x1034-0x1037,0x1020-0x1027,0x1030-0x1033,0x1000-0x101f > >>>>> mem > >>>>>> 0xb0700000-0xb07001ff at device 0.0 on pci4 > >>>>>> ahci0: AHCI v1.00 with 1 6Gbps ports, Port Multiplier not supporte= d > >>>>>> ahcich0: at channel 0 on ahci0 > >>>>>> > >>>>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > >>>>>> ada0: ATA-8 SATA 3.x device > >>>>>> ada0: Serial Number 1325A5401681 \^T\^T\^T\^T\^T\^T\^T > >>>>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > >>>>>> ada0: Command Queueing enabled > >>>>>> ada0: 115712MB (236978176 512 byte sectors: 16H 63S/T 16383C) > >>>>>> ada0: Previously was known as ad4 > >>>>>> > >>>>>> GEOM: ada0: enabling Boot Camp > >>>>>> GEOM: diskid/DISK-1325A5401681%20%14%14%14%14%14%14%14: enabling > Boot > >>>>> Camp > >>>>>> > >>>>>> > >>>>>> gpart: > >>>>>> > >>>>>> =3D> 34 236978109 ada0 GPT (113G) > >>>>>> 34 6 - free - (3.0K) > >>>>>> 40 409600 1 efi (200M) > >>>>>> 409640 174519128 2 apple-hfs (83G) > >>>>>> 174928768 1269536 3 apple-boot (620M) > >>>>>> 176198304 1376 - free - (688K) > >>>>>> 176199680 29782016 4 linux-data (14G) > >>>>>> 205981696 2097152 5 linux-swap (1.0G) > >>>>>> 208078848 1600 6 efi (800K) > >>>>>> 208080448 27261368 7 freebsd-ufs (13G) > >>>>>> 235341816 1445888 8 freebsd-swap (706M) > >>>>>> 236787704 190439 - free - (93M) > >>>>>> > >>>>>> > >>>>>> One other weird thing is that FreeBSD does not show up in the refi= nd > >>>>> boot > >>>>>> menu by default, only OSX and Linux. I have to press ESC once to > >> reload > >>>>> for > >>>>>> FreeBSD boot option to show up.. Any clues? Is my partition > >>>>> configuration > >>>>>> wrong in some way? > >>>>>> > >>>>>> Thanks! > >>>>>> -- > >>>>>> Johannes Lundberg > >>>>>> BRILLIANTSERVICE CO., LTD. > >>>>>> > >>>>> > >>>>> For the disk io bit, try running 'gstat' instead of iostat, and see > >> what > >>>>> it says. > >>>>> > >>>>> -- > >>>>> Allan Jude > >>>>> > >>>>> > >>>> > >>> > >> > >> Is the disk nearly full? very random guess, but maybe it is the SSD > >> running its garbage collection when it runs out of space. Do you have > >> TRIM enabled? > >> > >> -- > >> Allan Jude > >> > >> > > > > -- > > =3D-=3D-=3D-=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-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 Feb 5 08:30:48 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A5FD1C8; Thu, 5 Feb 2015 08:30:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C6A567D; Thu, 5 Feb 2015 08:30:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t158Uajx027803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 10:30:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t158Uajx027803 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t158Ua8R027792; Thu, 5 Feb 2015 10:30:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Feb 2015 10:30:36 +0200 From: Konstantin Belousov To: Dimitry Andric Subject: Re: Weird behavior writing to SSD on 2013 MacBook Message-ID: <20150205083035.GF42409@kib.kiev.ua> References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Current , "Lundberg, Johannes" , 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: Thu, 05 Feb 2015 08:30:48 -0000 On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: > If you let bsdtar continue, and press control-T a few times, does the > user time (u) increase at all? Does it ever go any further, if you let > it run for a very long time? > > I believe a problem may have been introduced by r277922, leading to > filesystem hangs in some scenarios. It looks like this commit is also > in dumbbell's github fork: > > https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81086899f521 > Would be nice if you mailed me with your findings. Please try this. diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c index 79783c8..700854e 100644 --- a/sys/ufs/ffs/ffs_softdep.c +++ b/sys/ufs/ffs/ffs_softdep.c @@ -1393,7 +1393,7 @@ softdep_flush(addr) VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) kthread_suspend_check(); ACQUIRE_LOCK(ump); - while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, "sdflush", hz / 2); ump->softdep_flags &= ~FLUSH_CLEANUP; @@ -1423,10 +1423,9 @@ worklist_speedup(mp) ump = VFSTOUFS(mp); LOCK_OWNED(ump); - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) { + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) ump->softdep_flags |= FLUSH_CLEANUP; - wakeup(&ump->softdep_flushtd); - } + wakeup(&ump->softdep_flushtd); } static int @@ -1471,11 +1470,10 @@ softdep_speedup(ump) TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); FREE_GBLLOCK(&lk); if ((altump->softdep_flags & - (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) { + (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) altump->softdep_flags |= FLUSH_CLEANUP; - altump->um_softdep->sd_cleanups++; - wakeup(&altump->softdep_flushtd); - } + altump->um_softdep->sd_cleanups++; + wakeup(&altump->softdep_flushtd); FREE_LOCK(altump); } } From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 08:38:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5FA042D; Thu, 5 Feb 2015 08:38:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 675106DD; Thu, 5 Feb 2015 08:38:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t158bumH029288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 10:37:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t158bumH029288 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t158btIw029287; Thu, 5 Feb 2015 10:37:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Feb 2015 10:37:55 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Filepaths in VM map for tmpfs files Message-ID: <20150205083755.GG42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <54D0457E.90006@badgerio.us> <20150203203336.GB42409@kib.kiev.ua> <1601131.aIB9RoRbLs@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1601131.aIB9RoRbLs@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Eric Badger , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 08:38:09 -0000 On Wed, Feb 04, 2015 at 10:15:04AM -0500, John Baldwin wrote: > On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote: > > On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: > > > On 02/02/2015 03:30 AM, Konstantin Belousov wrote: > > > > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: > > > >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > > > >>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? > > > >> > > > >> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; > > > >> I'd opine that it is better to be transparent than make it look like > > > >> there is an OBJT_VNODE object there. It may be that some programs would > > > >> be confused by VNODE info returned on a SWAP type mapping, though I > > > >> know > > > >> that dtrace handles it OK. > > > > > > > > kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE > > > > kve_type. > > > > So this is in fact a bug in whatever used the API to access kve_path > > > > for KVE_TYPE_SWAP. > > > > > > Hmm, is that documented anywhere? I think it's fair to assume that > > > kve_vn* applies only to the VNODE type, > > > but I know there are several in-tree users that reference kve_path > > > regardless of type (ostensibly relying > > > on the default of an empty string). Maybe one could determine the > > > validity of the kve_vn* fields by > > > inspecting the kve_vn_type (not sure of all the consequences of that)? > > > Or change it to KVME_TYPE_VNODE > > > and deal with the below problem... > > > > There is no useful documentation for the kern.proc. sysctls. > > My word (and statements from other involved developers) could be > > considered as close to the truth as it can be. > > Somebody taking the efforts to document the stuff would make very > > valuable contribution. > > I think that kve_path should be valid for all types (e.g. shm_open() > is not a vnode but has a pathname, and that should be fixed to display > if possible). In the equivalent for files (kinfo_file), the pathname > is type-independent and always valid. Well, this means that it should be valid for vnodes and shm. My point is that kvme_vn_path should be used only after the check for type. We can and do set it to nul string, but using the path unconditionally is a bug in the user code. > > That said, I think tmpfs nodes should be exposed as files. It is an > implementation detail of tmpfs that they are swap-backed, but from a > user's perspective these are files, and if you want to expose other > vnode-specific fields than just the path, KVME_TYPE_VNODE would be > more correct. I agree, but doing it is not easy, since there might be no vnode to get the required information from. We do know that this swap object is for tmpfs node, but currently we only store pointer to object in the node, not pointer to node from the object. When the vnode exists, pointer to vnode is stored in the object. To fix the issue, we should store pointer to node. Code was not done this way, because VM code which handles special-case for OBJT_TMPFS, would need to know tmpfs internals. Right now, code knows about vnodes anyway, so object->vnode does not bring tmpfs internals into vm. From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 08:45:18 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E06B641; Thu, 5 Feb 2015 08:45:18 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2601C83F; Thu, 5 Feb 2015 08:45:17 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id F18DA341F912; Thu, 5 Feb 2015 00:45:15 -0800 (PST) Message-ID: <54D32DC3.6020409@mu.org> Date: Thu, 05 Feb 2015 00:45:55 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov , Dimitry Andric Subject: Re: Weird behavior writing to SSD on 2013 MacBook References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> <20150205083035.GF42409@kib.kiev.ua> In-Reply-To: <20150205083035.GF42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , "Lundberg, Johannes" , 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: Thu, 05 Feb 2015 08:45:18 -0000 On 2/5/15 12:30 AM, Konstantin Belousov wrote: > On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: >> If you let bsdtar continue, and press control-T a few times, does the >> user time (u) increase at all? Does it ever go any further, if you let >> it run for a very long time? >> >> I believe a problem may have been introduced by r277922, leading to >> filesystem hangs in some scenarios. It looks like this commit is also >> in dumbbell's github fork: >> >> https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81086899f521 >> > > Would be nice if you mailed me with your findings. > > Please try this. > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > index 79783c8..700854e 100644 > --- a/sys/ufs/ffs/ffs_softdep.c > +++ b/sys/ufs/ffs/ffs_softdep.c > @@ -1393,7 +1393,7 @@ softdep_flush(addr) > VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) > kthread_suspend_check(); > ACQUIRE_LOCK(ump); > - while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, > "sdflush", hz / 2); > ump->softdep_flags &= ~FLUSH_CLEANUP; > @@ -1423,10 +1423,9 @@ worklist_speedup(mp) > > ump = VFSTOUFS(mp); > LOCK_OWNED(ump); > - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) { > + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > ump->softdep_flags |= FLUSH_CLEANUP; > - wakeup(&ump->softdep_flushtd); > - } > + wakeup(&ump->softdep_flushtd); > } > > static int > @@ -1471,11 +1470,10 @@ softdep_speedup(ump) > TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); > FREE_GBLLOCK(&lk); > if ((altump->softdep_flags & > - (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) { > + (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > altump->softdep_flags |= FLUSH_CLEANUP; > - altump->um_softdep->sd_cleanups++; > - wakeup(&altump->softdep_flushtd); > - } > + altump->um_softdep->sd_cleanups++; > + wakeup(&altump->softdep_flushtd); > FREE_LOCK(altump); > } > } > _______________________________________________ Why the conversion of while() to if()? The reason for a while() when doing msleep/wakeup is typically to prevent superfluous wakeups from signalling early. -Alfred From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 09:03:35 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57417CA6; Thu, 5 Feb 2015 09:03:35 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3DAEA07; Thu, 5 Feb 2015 09:03:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t1593OEk034937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 11:03:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t1593OEk034937 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t1593OPp034936; Thu, 5 Feb 2015 11:03:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Feb 2015 11:03:24 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: Weird behavior writing to SSD on 2013 MacBook Message-ID: <20150205090324.GI42409@kib.kiev.ua> References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> <20150205083035.GF42409@kib.kiev.ua> <54D32DC3.6020409@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D32DC3.6020409@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Current , Dimitry Andric , "Lundberg, Johannes" , 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: Thu, 05 Feb 2015 09:03:35 -0000 On Thu, Feb 05, 2015 at 12:45:55AM -0800, Alfred Perlstein wrote: > > > On 2/5/15 12:30 AM, Konstantin Belousov wrote: > > On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: > >> If you let bsdtar continue, and press control-T a few times, does the > >> user time (u) increase at all? Does it ever go any further, if you let > >> it run for a very long time? > >> > >> I believe a problem may have been introduced by r277922, leading to > >> filesystem hangs in some scenarios. It looks like this commit is also > >> in dumbbell's github fork: > >> > >> https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81086899f521 > >> > > > > Would be nice if you mailed me with your findings. > > > > Please try this. > > > > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > > index 79783c8..700854e 100644 > > --- a/sys/ufs/ffs/ffs_softdep.c > > +++ b/sys/ufs/ffs/ffs_softdep.c > > @@ -1393,7 +1393,7 @@ softdep_flush(addr) > > VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) > > kthread_suspend_check(); > > ACQUIRE_LOCK(ump); > > - while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > > + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > > msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, > > "sdflush", hz / 2); > > ump->softdep_flags &= ~FLUSH_CLEANUP; > > @@ -1423,10 +1423,9 @@ worklist_speedup(mp) > > > > ump = VFSTOUFS(mp); > > LOCK_OWNED(ump); > > - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) { > > + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > > ump->softdep_flags |= FLUSH_CLEANUP; > > - wakeup(&ump->softdep_flushtd); > > - } > > + wakeup(&ump->softdep_flushtd); > > } > > > > static int > > @@ -1471,11 +1470,10 @@ softdep_speedup(ump) > > TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); > > FREE_GBLLOCK(&lk); > > if ((altump->softdep_flags & > > - (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) { > > + (FLUSH_CLEANUP | FLUSH_EXIT)) == 0) > > altump->softdep_flags |= FLUSH_CLEANUP; > > - altump->um_softdep->sd_cleanups++; > > - wakeup(&altump->softdep_flushtd); > > - } > > + altump->um_softdep->sd_cleanups++; > > + wakeup(&altump->softdep_flushtd); > > FREE_LOCK(altump); > > } > > } > > _______________________________________________ > > Why the conversion of while() to if()? > > > The reason for a while() when doing msleep/wakeup is typically to > prevent superfluous wakeups from signalling early. if()->while() was one of the changes in r277922, and I suspect that it is the cause of the issue. I.e. my thought right now is that softdep_process_worklist() does not keep up with the requests. If this is true, then real fix is somewhere else, but restoring pre-r277922 behaviour should get rid of immediate pain. From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 09:19:57 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 563C9EFE; Thu, 5 Feb 2015 09:19:57 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 340ECB2E; Thu, 5 Feb 2015 09:19:56 +0000 (UTC) Received: from [100.114.11.106] (156.sub-70-211-79.myvzw.com [70.211.79.156]) by elvis.mu.org (Postfix) with ESMTPSA id 2BD3A341F912; Thu, 5 Feb 2015 01:19:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Weird behavior writing to SSD on 2013 MacBook From: Alfred Perlstein X-Mailer: iPhone Mail (12B440) In-Reply-To: <20150205090324.GI42409@kib.kiev.ua> Date: Thu, 5 Feb 2015 01:19:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> <20150205083035.GF42409@kib.kiev.ua> <54D32DC3.6020409@mu.org> <20150205090324.GI42409@kib.kiev.ua> To: Konstantin Belousov Cc: FreeBSD Current , Dimitry Andric , "Lundberg, Johannes" , 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: Thu, 05 Feb 2015 09:19:57 -0000 It's possible original intent of that construct was just a pause/throttle if= it used to be an if(). Makes sense although should investigate further.=20 Sent from my iPhone > On Feb 5, 2015, at 1:03 AM, Konstantin Belousov wrot= e: >=20 >> On Thu, Feb 05, 2015 at 12:45:55AM -0800, Alfred Perlstein wrote: >>=20 >>=20 >>> On 2/5/15 12:30 AM, Konstantin Belousov wrote: >>>> On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: >>>> If you let bsdtar continue, and press control-T a few times, does the >>>> user time (u) increase at all? Does it ever go any further, if you let= >>>> it run for a very long time? >>>>=20 >>>> I believe a problem may have been introduced by r277922, leading to >>>> filesystem hangs in some scenarios. It looks like this commit is also >>>> in dumbbell's github fork: >>>>=20 >>>> https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a= 81086899f521 >>>=20 >>> Would be nice if you mailed me with your findings. >>>=20 >>> Please try this. >>>=20 >>> diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c >>> index 79783c8..700854e 100644 >>> --- a/sys/ufs/ffs/ffs_softdep.c >>> +++ b/sys/ufs/ffs/ffs_softdep.c >>> @@ -1393,7 +1393,7 @@ softdep_flush(addr) >>> VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) >>> kthread_suspend_check(); >>> ACQUIRE_LOCK(ump); >>> - while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D= 0) >>> + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0= ) >>> msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, >>> "sdflush", hz / 2); >>> ump->softdep_flags &=3D ~FLUSH_CLEANUP; >>> @@ -1423,10 +1423,9 @@ worklist_speedup(mp) >>>=20 >>> ump =3D VFSTOUFS(mp); >>> LOCK_OWNED(ump); >>> - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) {= >>> + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) >>> ump->softdep_flags |=3D FLUSH_CLEANUP; >>> - wakeup(&ump->softdep_flushtd); >>> - } >>> + wakeup(&ump->softdep_flushtd); >>> } >>>=20 >>> static int >>> @@ -1471,11 +1470,10 @@ softdep_speedup(ump) >>> TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); >>> FREE_GBLLOCK(&lk); >>> if ((altump->softdep_flags & >>> - (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { >>> + (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) >>> altump->softdep_flags |=3D FLUSH_CLEANUP; >>> - altump->um_softdep->sd_cleanups++; >>> - wakeup(&altump->softdep_flushtd); >>> - } >>> + altump->um_softdep->sd_cleanups++; >>> + wakeup(&altump->softdep_flushtd); >>> FREE_LOCK(altump); >>> } >>> } >>> _______________________________________________ >>=20 >> Why the conversion of while() to if()? >>=20 >>=20 >> The reason for a while() when doing msleep/wakeup is typically to=20 >> prevent superfluous wakeups from signalling early. >=20 > if()->while() was one of the changes in r277922, and I suspect that it > is the cause of the issue. I.e. my thought right now is that > softdep_process_worklist() does not keep up with the requests. >=20 > If this is true, then real fix is somewhere else, but restoring > pre-r277922 behaviour should get rid of immediate pain. >=20 From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 09:29:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DFD91B0 for ; Thu, 5 Feb 2015 09:29:31 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53309C23 for ; Thu, 5 Feb 2015 09:29:30 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.14.9) with ESMTPSA id t159T4GN062227 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 09:29:18 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: PSA: If you run -current, beware! From: David Chisnall In-Reply-To: Date: Thu, 5 Feb 2015 09:29:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150204142941.GE42409@kib.kiev.ua> <2509923.ondFvsFdql@overcee.wemm.org> To: Luigi Rizzo X-Mailer: Apple Mail (2.2070.6) Cc: Konstantin Belousov , "freebsd-current@freebsd.org" , Peter Wemm 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, 05 Feb 2015 09:29:31 -0000 On 5 Feb 2015, at 07:48, Luigi Rizzo wrote: >=20 > Rather than depending on a compiler option, wouldn't it be better/more > robust to change ticks to unsigned, which has specified wrapping = behavior? Especially if we want to extend support for external toolchains. gcc = and clang support -fwrapv (though occasionally versions of both will not = fully support it), but other compilers may well not have an equivalent. Translating the code into C is a far more robust solution than the = band-aid of telling the compiler to accept a language that is a bit like = C and hoping that this will keep working across compiler implementations = and versions. Adding -fwrapv also defeats a number of compiler optimisations, so we = are going to generate worse code for places where people used signed = types correctly to work around places where they were used incorrectly. David From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 11:43:25 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90F9778D for ; Thu, 5 Feb 2015 11:43:25 +0000 (UTC) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44D49D2B for ; Thu, 5 Feb 2015 11:43:24 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id im6so1256124vcb.9 for ; Thu, 05 Feb 2015 03:43:23 -0800 (PST) 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=lnea0gkrqzi+yqwiteErtxf18Xq3uMt/YC339HXyS7E=; b=T87rGDck7fx8QtGONPGz2Rr3Lau0R8tgySfAYKWeGROhXd4/JgrrMNnSDWPLGNyvF/ 9af47HvQ5rT9lB+VgI04jrP42IAoauV4CElFoS0K88W6lmd+jPQx003k1mp486hzw6Bg C+RF5QRY1V5jQFRdlGU8NE0mTAHlqFyPT9EnVUQX7udIi01r3WUsl5xH/cRLsL3BpFSM Vsh5DJczRBOWBs6zqPAn+zp8U3dfT81pVcX4ql6JrO2RmKbt7uIlprWx0/As1N8bw10i AUNbIeFA7mVhlZ1o6aPihsupu7Od3i0F/tkjzrjBb66rRNYgn9aGXWBi0uKAG1qWzNk0 YXGw== X-Gm-Message-State: ALoCoQmoJN0eFjw7JX/aXNXpxiQbBA3K0zjKvTzTfjbpjfZAlHrD3ufg0oaLFzUenM0nOUmnF+hiVFH8K64Wph5Pajgm+THqhBpkApqrGGayXtu8nHM3Cicm2HOdstaUinPXNvyqfxEM X-Received: by 10.52.136.98 with SMTP id pz2mr1473350vdb.26.1423130654280; Thu, 05 Feb 2015 02:04:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.128.165 with HTTP; Thu, 5 Feb 2015 02:03:57 -0800 (PST) In-Reply-To: References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> <20150205083035.GF42409@kib.kiev.ua> <54D32DC3.6020409@mu.org> <20150205090324.GI42409@kib.kiev.ua> From: "Lundberg, Johannes" Date: Thu, 5 Feb 2015 19:03:57 +0900 Message-ID: Subject: Re: Weird behavior writing to SSD on 2013 MacBook To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Konstantin Belousov , FreeBSD Current , Dimitry Andric , 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: Thu, 05 Feb 2015 11:43:25 -0000 It seems like the patch solved my problem. No more freezing of the filesystem. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Thu, Feb 5, 2015 at 6:19 PM, Alfred Perlstein wrote: > It's possible original intent of that construct was just a pause/throttle > if it used to be an if(). Makes sense although should investigate further= . > > Sent from my iPhone > > > On Feb 5, 2015, at 1:03 AM, Konstantin Belousov > wrote: > > > >> On Thu, Feb 05, 2015 at 12:45:55AM -0800, Alfred Perlstein wrote: > >> > >> > >>> On 2/5/15 12:30 AM, Konstantin Belousov wrote: > >>>> On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: > >>>> If you let bsdtar continue, and press control-T a few times, does th= e > >>>> user time (u) increase at all? Does it ever go any further, if you > let > >>>> it run for a very long time? > >>>> > >>>> I believe a problem may have been introduced by r277922, leading to > >>>> filesystem hangs in some scenarios. It looks like this commit is al= so > >>>> in dumbbell's github fork: > >>>> > >>>> > https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a81= 086899f521 > >>> > >>> Would be nice if you mailed me with your findings. > >>> > >>> Please try this. > >>> > >>> diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c > >>> index 79783c8..700854e 100644 > >>> --- a/sys/ufs/ffs/ffs_softdep.c > >>> +++ b/sys/ufs/ffs/ffs_softdep.c > >>> @@ -1393,7 +1393,7 @@ softdep_flush(addr) > >>> VFSTOUFS(mp)->softdep_jblocks->jb_suspended)) > >>> kthread_suspend_check(); > >>> ACQUIRE_LOCK(ump); > >>> - while ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) = =3D=3D > 0) > >>> + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D= =3D 0) > >>> msleep(&ump->softdep_flushtd, LOCK_PTR(ump), PVM, > >>> "sdflush", hz / 2); > >>> ump->softdep_flags &=3D ~FLUSH_CLEANUP; > >>> @@ -1423,10 +1423,9 @@ worklist_speedup(mp) > >>> > >>> ump =3D VFSTOUFS(mp); > >>> LOCK_OWNED(ump); > >>> - if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0= ) { > >>> + if ((ump->softdep_flags & (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0= ) > >>> ump->softdep_flags |=3D FLUSH_CLEANUP; > >>> - wakeup(&ump->softdep_flushtd); > >>> - } > >>> + wakeup(&ump->softdep_flushtd); > >>> } > >>> > >>> static int > >>> @@ -1471,11 +1470,10 @@ softdep_speedup(ump) > >>> TAILQ_INSERT_TAIL(&softdepmounts, sdp, sd_next); > >>> FREE_GBLLOCK(&lk); > >>> if ((altump->softdep_flags & > >>> - (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) { > >>> + (FLUSH_CLEANUP | FLUSH_EXIT)) =3D=3D 0) > >>> altump->softdep_flags |=3D FLUSH_CLEANUP; > >>> - altump->um_softdep->sd_cleanups++; > >>> - wakeup(&altump->softdep_flushtd); > >>> - } > >>> + altump->um_softdep->sd_cleanups++; > >>> + wakeup(&altump->softdep_flushtd); > >>> FREE_LOCK(altump); > >>> } > >>> } > >>> _______________________________________________ > >> > >> Why the conversion of while() to if()? > >> > >> > >> The reason for a while() when doing msleep/wakeup is typically to > >> prevent superfluous wakeups from signalling early. > > > > if()->while() was one of the changes in r277922, and I suspect that it > > is the cause of the issue. I.e. my thought right now is that > > softdep_process_worklist() does not keep up with the requests. > > > > If this is true, then real fix is somewhere else, but restoring > > pre-r277922 behaviour should get rid of immediate pain. > > > --=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 Feb 5 12:22:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 042818F5; Thu, 5 Feb 2015 12:22:37 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD009221; Thu, 5 Feb 2015 12:22:36 +0000 (UTC) Received: from coleburn.avinity.tv (unknown [77.243.161.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9EAC15C2E; Thu, 5 Feb 2015 13:22:31 +0100 (CET) Subject: Re: Weird behavior writing to SSD on 2013 MacBook Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_937B856C-ACDD-41B2-96B9-02A5C152A499"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 (c621b2a+) From: Dimitry Andric In-Reply-To: <20150205083035.GF42409@kib.kiev.ua> Date: Thu, 5 Feb 2015 13:22:27 +0100 Message-Id: <95526D8E-6C34-43BA-BB18-35B1764A7108@FreeBSD.org> References: <54D2C3DA.4060205@freebsd.org> <54D319EA.5020709@freebsd.org> <20150205083035.GF42409@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Current , "Lundberg, Johannes" , 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: Thu, 05 Feb 2015 12:22:37 -0000 --Apple-Mail=_937B856C-ACDD-41B2-96B9-02A5C152A499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 05 Feb 2015, at 09:30, Konstantin Belousov = wrote: >=20 > On Thu, Feb 05, 2015 at 08:56:59AM +0100, Dimitry Andric wrote: >> If you let bsdtar continue, and press control-T a few times, does the >> user time (u) increase at all? Does it ever go any further, if you = let >> it run for a very long time? >>=20 >> I believe a problem may have been introduced by r277922, leading to >> filesystem hangs in some scenarios. It looks like this commit is = also >> in dumbbell's github fork: >>=20 >> = https://github.com/dumbbell/freebsd/commit/83723416a6bb8695d60c6573722a810= 86899f521 >>=20 >=20 > Would be nice if you mailed me with your findings. >=20 > Please try this. >=20 > diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c Hi Kostik, Yes, this works: it survived 20 simultaneous svn checkouts of a large repository, while before the fix just 1 checkout could be enough to let it get stuck in flswai state. Thanks for the quick fix. -Dimitry --Apple-Mail=_937B856C-ACDD-41B2-96B9-02A5C152A499 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----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlTTYIYACgkQsF6jCi4glqNbfACeMz0QMkd+HFPHa3JjbNDAZWij XykAnjtBAwPkWcjRMISzx3C7uDqqxwHx =XjCZ -----END PGP SIGNATURE----- --Apple-Mail=_937B856C-ACDD-41B2-96B9-02A5C152A499-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 09:46:24 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E4186E7; Thu, 5 Feb 2015 09:46:24 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D9EFFE0F; Thu, 5 Feb 2015 09:46:23 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id k11so6641569wes.2; Thu, 05 Feb 2015 01:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OfD3KZBT9zq8cUU1g5eMFrKQf1SWUixSaHCR2mTmZ28=; b=iF4/QkqJ/VfosmVnu8tz0jj05ipOcnY1jKcXwNIZnzWuPIWKuAPaXZvE+bWTDMsYoO epC5fFtYwpa4yi62bhe6rkIhG7zAQ4PPdLRpXm/lAT47N10jsrmEIyK6C2ObaTBek1L+ OXaKIH3V/165/mmvUbZSTII63dcSUrCdGfE9VUaeIz+BhbvXaNUn4B6iwX+JBD7vEEzX TElZLk2NuZSscOs2DI12OqiN6oA7mcA4ABCjUbGRCozzE42VthUP4cec3eDntGVMRenA vsjoa1VCXgMxYj9AI/F+HPT1Klt5uKPzMPCrCnALm6TURsLItjicOhwFtJnh/0rX7gmL sRVA== MIME-Version: 1.0 X-Received: by 10.194.23.39 with SMTP id j7mr5737824wjf.9.1423129582375; Thu, 05 Feb 2015 01:46:22 -0800 (PST) Received: by 10.27.220.1 with HTTP; Thu, 5 Feb 2015 01:46:22 -0800 (PST) Date: Thu, 5 Feb 2015 10:46:22 +0100 Message-ID: Subject: Re: i915kms.ko regression? From: Lutz Bichler To: current@freebsd.org X-Mailman-Approved-At: Thu, 05 Feb 2015 12:22:56 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: xmj@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 09:46:24 -0000 Hi Johannes, i am experiencing a similar behavior on an Asus UX31A. The display is active but brightness seems to be near 0 and unchangeable. Reverting https://svnweb.freebsd.org/changeset/base/277959 made me get full brightness again. Unfortunately, brightness changing does not work. Regards, Lutz From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 13:03:23 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C5915B5; Thu, 5 Feb 2015 13:03:23 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F03C892; Thu, 5 Feb 2015 13:03:22 +0000 (UTC) Received: by pdbft15 with SMTP id ft15so7672887pdb.5; Thu, 05 Feb 2015 05:03:22 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=NdcQFxTvXOSWjgX8X2UKBIxC3Web3gtwZ7RV1pDfL5s=; b=JBN65qky/CbLpzNfN1J44S92mqjc/imRSWpvDtUZiBkIOLXX6r+A4zzDB7WwTTpNvR 0ypppu6D+LeKBZdGOTjTnPhA+zMdF73o5i61WnSQeItSVjq9RQIhmdV0udtfvrYH23I+ vVVCHdV/ak4ux8eXvIipRd3y2Lr8qPsWJlEAJGyeo3tBpSaa8aSaYyk6xKZ1HKktawXV LXDcXGKtdGXf8R+3NZyAm1Dt0eB6MYcIlkBbScMVS5LLOyqEATeUqj7ChoyW/gnQSvuF bkHp6URBlI7L1RJ6GBTGcdsnmG+1WdkWq3YVeaVc8eM3ax8QJmLsKHgav1YQeeGvPAiP /mpg== X-Received: by 10.68.237.2 with SMTP id uy2mr5573615pbc.72.1423141081041; Thu, 05 Feb 2015 04:58:01 -0800 (PST) Received: from [192.168.100.3] ([202.160.36.109]) by mx.google.com with ESMTPSA id ej9sm5093376pdb.1.2015.02.05.04.57.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 04:58:00 -0800 (PST) Mime-Version: 1.0 (1.0) Subject: Re: Freebsd-current Virtualbox crashes when enable Vt-x/AMD Virtualization From: Ccs189 X-Mailer: iPhone Mail (12B440) In-Reply-To: <54D251B9.4060307@freebsd.org> Date: Thu, 5 Feb 2015 20:57:59 +0800 Message-Id: <50689A5C-D6BD-4824-B672-DC3F4F31207C@gmail.com> References: <54D251B9.4060307@freebsd.org> To: Allan Jude Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:03:23 -0000 Hi Alan,=20 I have put the screen capture after kernel panic. I not sure if that helps. I= f you need more testing pls let me know.=20 https://docs.google.com/file/d/0B54HQrZQWnfnRW1teTFHNG5PNW8/edit?usp=3Ddocsl= ist_api https://docs.google.com/file/d/0B54HQrZQWnfnR3JwS0xfQ3QxVW8/edit?usp=3Ddocsl= ist_api My hardware is thinkpad X1 carbon i7 3444 first generation.=20 I use custom kernel which I only disable VESA and WITNESS options to allow t= he laptop suspend to sleep mode. =20 > On 5 Feb 2015, at 1:07 am, Allan Jude wrote: >=20 >> On 2015-02-04 10:11, Claudius Chan wrote: >> Hi, >> this is my first post in this mailing list. I hope this is the correct wa= y >> to post it here. >>=20 >> I have issue when enable the Vt-x/AMD in Virtuabox, after the virtual >> machine boot up. kernel panic happened. >>=20 >> I currently using Virtualbox version: >> $ pkg info |grep virtual >> virtualbox-ose-4.3.20_4 General-purpose full virtualizer for x86 >> hardware >> virtualbox-ose-kmod-4.3.20 VirtualBox kernel module for FreeBSD >> _______________________________________________ >> 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 > did the kernel panic include output that might explain what the problem wa= s? >=20 > --=20 > Allan Jude >=20 From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 13:57:53 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FDED2C6 for ; Thu, 5 Feb 2015 13:57:53 +0000 (UTC) Received: from dd16522.kasserver.com (dd16522.kasserver.com [85.13.137.124]) (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 5F7F6E53 for ; Thu, 5 Feb 2015 13:57:52 +0000 (UTC) Received: from mx12.chaot.net (62.65.196.213.cable.starman.ee [62.65.196.213]) by dd16522.kasserver.com (Postfix) with ESMTPSA id 25AB2456023; Thu, 5 Feb 2015 14:57:49 +0100 (CET) Received: from localhost (1001@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 8e8a7126; Thu, 5 Feb 2015 15:57:47 +0200 (EET) Date: Thu, 5 Feb 2015 15:57:47 +0200 From: Johannes Meixner To: Lutz Bichler Subject: Re: i915kms.ko regression? Message-ID: <20150205135747.GA1155@mx12.chaot.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:57:53 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Lutz, backing out that change fixed it, apart from the brightness regression. I h= ave a hunch that the brightness regressed earler, I remember noticing that load= ing acpi_video and setting hw.acpi.video.lcd1.brightness didn't have any effect sometime after the i915 import. Best -Johannes On Thu, Feb 05, 2015 at 10:46:22AM +0100, Lutz Bichler wrote: > Hi Johannes, >=20 > i am experiencing a similar behavior on an Asus UX31A. The display is > active but brightness seems to be near 0 and unchangeable. >=20 > Reverting https://svnweb.freebsd.org/changeset/base/277959 made me get fu= ll > brightness again. Unfortunately, brightness changing does not work. >=20 > Regards, Lutz --=20 Johannes Meixner | FreeBSD Committer xmj@FreeBSD.org | http://people.freebsd.org/~xmj --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJU03bXAAoJEPyeKTcbGw0LvoUIAMFXQJT0jp3NeG2A+l2jeXIA QVleiIlf4VgcyZ8orqYl2/pHfz62cM6AOynZ8Npin7vhPecfTkCZAHS6/7sWQXno vCpL/Laz4h6rXbOGPTusBAeFefdKf43ee4jpMV9xgswJEs7wciqJm1uf+yVXNYKs TzghktCNorra/u/MdRPK8VtfzTA92JdCJSu93foGBmDNEYYqPtni/pNv901/2Zh3 T/LnbEITps4DGcyzBpS6YxcnGrn/fKWdjo3LPatQToG3rPHJ5h0V2qVMFizU2Q73 4m9/q4a4OWW4B6w82XoBK6o1Rr/KAzGDG2c2TZGD9q4zCbxFtG6MUJ+/rEwXxJ0= =9+PK -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 13:59:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A3703C7 for ; Thu, 5 Feb 2015 13:59:07 +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 307C6E61 for ; Thu, 5 Feb 2015 13:59:07 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9B143B915; Thu, 5 Feb 2015 08:59:05 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: Filepaths in VM map for tmpfs files Date: Thu, 05 Feb 2015 08:25:41 -0500 Message-ID: <14469498.JC5CzcnZkB@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150205083755.GG42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <1601131.aIB9RoRbLs@ralph.baldwin.cx> <20150205083755.GG42409@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Feb 2015 08:59:05 -0500 (EST) Cc: Eric Badger , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:59:07 -0000 On Thursday, February 05, 2015 10:37:55 AM Konstantin Belousov wrote: > On Wed, Feb 04, 2015 at 10:15:04AM -0500, John Baldwin wrote: > > On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote: > > > On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: > > > > On 02/02/2015 03:30 AM, Konstantin Belousov wrote: > > > > > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: > > > > >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > > > > >>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? > > > > >> > > > > >> My thinking is no, because KVME_TYPE_SWAP is in fact the correct > > > > >> type; > > > > >> I'd opine that it is better to be transparent than make it look > > > > >> like > > > > >> there is an OBJT_VNODE object there. It may be that some programs > > > > >> would > > > > >> be confused by VNODE info returned on a SWAP type mapping, though I > > > > >> know > > > > >> that dtrace handles it OK. > > > > > > > > > > kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE > > > > > kve_type. > > > > > So this is in fact a bug in whatever used the API to access kve_path > > > > > for KVE_TYPE_SWAP. > > > > > > > > Hmm, is that documented anywhere? I think it's fair to assume that > > > > kve_vn* applies only to the VNODE type, > > > > but I know there are several in-tree users that reference kve_path > > > > regardless of type (ostensibly relying > > > > on the default of an empty string). Maybe one could determine the > > > > validity of the kve_vn* fields by > > > > inspecting the kve_vn_type (not sure of all the consequences of that)? > > > > Or change it to KVME_TYPE_VNODE > > > > and deal with the below problem... > > > > > > There is no useful documentation for the kern.proc. sysctls. > > > My word (and statements from other involved developers) could be > > > considered as close to the truth as it can be. > > > Somebody taking the efforts to document the stuff would make very > > > valuable contribution. > > > > I think that kve_path should be valid for all types (e.g. shm_open() > > is not a vnode but has a pathname, and that should be fixed to display > > if possible). In the equivalent for files (kinfo_file), the pathname > > is type-independent and always valid. > > Well, this means that it should be valid for vnodes and shm. My point > is that kvme_vn_path should be used only after the check for type. > We can and do set it to nul string, but using the path unconditionally > is a bug in the user code. The problem is that shm's can have different types (DEFAULT vs SWAP vs PHYS). :) For kinfo_file, tools like fstat always print kf_path regardless of type. I do think it would be more consistent if the path in a kvme worked the same way. Then you don't have to update all the tools each time a type starts populating the path. > > That said, I think tmpfs nodes should be exposed as files. It is an > > implementation detail of tmpfs that they are swap-backed, but from a > > user's perspective these are files, and if you want to expose other > > vnode-specific fields than just the path, KVME_TYPE_VNODE would be > > more correct. > > I agree, but doing it is not easy, since there might be no vnode > to get the required information from. We do know that this swap > object is for tmpfs node, but currently we only store pointer to > object in the node, not pointer to node from the object. When the > vnode exists, pointer to vnode is stored in the object. > > To fix the issue, we should store pointer to node. Code was not done > this way, because VM code which handles special-case for OBJT_TMPFS, > would need to know tmpfs internals. Right now, code knows about vnodes > anyway, so object->vnode does not bring tmpfs internals into vm. I'm more arguing in support of your original proposal. Doing a best effort if the vnode exists would certainly be an improvement over what we have now. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 13:59:07 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A28E33C8 for ; Thu, 5 Feb 2015 13:59:07 +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 786B0E62 for ; Thu, 5 Feb 2015 13:59:07 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84974B91E; Thu, 5 Feb 2015 08:59:06 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: PSA: If you run -current, beware! Date: Thu, 05 Feb 2015 08:21:45 -0500 Message-ID: <2613155.3ZBxDvY16q@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <8089702.oYScRm8BTN@overcee.wemm.org> <2509923.ondFvsFdql@overcee.wemm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Feb 2015 08:59:06 -0500 (EST) Cc: Konstantin Belousov , Luigi Rizzo , Peter Wemm 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, 05 Feb 2015 13:59:07 -0000 On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: > On Thursday, February 5, 2015, Peter Wemm wrote: > > On Wednesday, February 04, 2015 04:29:41 PM Konstantin Belousov wrote: > > > On Tue, Feb 03, 2015 at 01:33:15PM -0800, Peter Wemm wrote: > > > > Sometime in the Dec 10th through Jan 7th timeframe a timing bug has > > > > been > > > > > > introduced to 11.x/head/-current. With HZ=1000 (the default for > > > > bare > > > > metal, not for a vm); the clocks stop just after 24 days of uptime. > > > > This > > > > > > means things like cron, sleep, timeouts etc stop working. TCP/IP > > > > won't > > > > time out or retransmit, etc etc. It can get ugly. > > > > > > > > The problem is NOT in 10.x/-stable. > > > > > > > > We hit this in the freebsd.org cluster, the builds that we used are: > > > > FreeBSD 11.0-CURRENT #0 r275684: Wed Dec 10 20:38:43 UTC 2014 - fine > > > > FreeBSD 11.0-CURRENT #0 r276779: Wed Jan 7 18:47:09 UTC 2015 - broken > > > > > > > > If you are running -current in a situation where it'll accumulate > > > > uptime, > > > > > > you may want to take precautions. A reboot prior to 24 days uptime > > > > (as > > > > horrible a workaround as that is) will avoid it. > > > > > > > > Yes, this is being worked on. > > > > > > So the issue is reproducable in 3 minutes after boot with the following > > > change in kern_clock.c: > > > volatile int ticks = INT_MAX - (/*hz*/1000 * 3 * 60); > > > > > > It is fixed (in the proper meaning of the word, not like worked around, > > > covered by paper) by the patch at the end of the mail. > > > > > > We already have a story trying to enable much less ambitious option > > > -fno-strict-overflow, see r259045 and the revert in r259422. I do not > > > see other way than try one more time. Too many places in kernel > > > depend on the correctly wrapping 2-complement arithmetic, among others > > > are callweel and scheduler. > > Rather than depending on a compiler option, wouldn't it be better/more > robust to change ticks to unsigned, which has specified wrapping behavior? Yes, but non-trivial. It's also not limited to ticks. Since the compiler knows when it would apply these optimizations, it would be nice if it could warn instead (GCC apparently has a warning, but clang does not). Having people do a manual audit of every signed integer expression in the tree will take a long time. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 13:59:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3797570C for ; Thu, 5 Feb 2015 13:59:52 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E17D5E83 for ; Thu, 5 Feb 2015 13:59:51 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id bm13so5896763qab.0 for ; Thu, 05 Feb 2015 05:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=vMTwXDlPwWXTHoGEGdnzA0agg3BhFQUEa11N9R4AiXY=; b=wcZcdB7UccHQHs8BNL9pdwXxGG63CG3t+0/rmiDOWMMA34uOm7aBldWNKVqIMXoZ0m 5KQuNos43rW9lF41+EAQk8nDmIlEhqu+Yq4P0TWsloAv5BUOmVx07hvReP4q70qhXJdh SB/kqR2aoRJ93dcFnOKwNSaNqIfQzpNEOKceUpIRw5C5qeX4DAqQc8zmfmCrFV5frAJV BwC4jkDtBzvjmSKznQ405NsOvyBTHQDa5MpUvXEsU5lO+UoWgsWsfzpu546WTK4zQV8J xU+Q/943qDFdiBp087UBD0NDLIXzud7CAai18/beBx6mzewEuMSlqVy3VLTh8WRLzYU4 uNJQ== X-Received: by 10.140.37.39 with SMTP id q36mr7929438qgq.89.1423144791014; Thu, 05 Feb 2015 05:59:51 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.140.39.209 with HTTP; Thu, 5 Feb 2015 05:59:30 -0800 (PST) In-Reply-To: References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150204142941.GE42409@kib.kiev.ua> <2509923.ondFvsFdql@overcee.wemm.org> From: Ed Maste Date: Thu, 5 Feb 2015 08:59:30 -0500 X-Google-Sender-Auth: Yb-Ddq00qPOQ69p1SHCyvrFwz2U Message-ID: Subject: Re: PSA: If you run -current, beware! To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , "freebsd-current@freebsd.org" , Peter Wemm 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, 05 Feb 2015 13:59:52 -0000 On 5 February 2015 at 02:48, Luigi Rizzo wrote: > > Rather than depending on a compiler option, wouldn't it be better/more > robust to change ticks to unsigned, which has specified wrapping behavior? I believe there are cases other than ticks that rely on 2s complement signed wrap. We'd want to make sure we find such cases. Newer GCC can help with that. The -Wstrict-overflow flag causes the compiler to warn when implementing an optimization based on undefined behaviour from signed overflow. Correct C code should work with or without -fwrapv, so we can do both: enable -fwrapv, and make changes to stop relying on undefined behaviour. For ticks specifically we have many examples over time of incorrect calculations so we'll benefit from some work here, independent of signed overflow. From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 15:22:20 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D7BCE3; Thu, 5 Feb 2015 15:22:20 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id F19B1B92; Thu, 5 Feb 2015 15:22:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B45177300A; Thu, 5 Feb 2015 16:22:23 +0100 (CET) Date: Thu, 5 Feb 2015 16:22:23 +0100 From: Luigi Rizzo To: John Baldwin Subject: Re: PSA: If you run -current, beware! Message-ID: <20150205152223.GA59664@onelab2.iet.unipi.it> References: <8089702.oYScRm8BTN@overcee.wemm.org> <2509923.ondFvsFdql@overcee.wemm.org> <2613155.3ZBxDvY16q@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2613155.3ZBxDvY16q@ralph.baldwin.cx> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Konstantin Belousov , freebsd-current@freebsd.org, Peter Wemm 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, 05 Feb 2015 15:22:20 -0000 On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: ... > > > > It is fixed (in the proper meaning of the word, not like worked around, > > > > covered by paper) by the patch at the end of the mail. > > > > > > > > We already have a story trying to enable much less ambitious option > > > > -fno-strict-overflow, see r259045 and the revert in r259422. I do not > > > > see other way than try one more time. Too many places in kernel > > > > depend on the correctly wrapping 2-complement arithmetic, among others > > > > are callweel and scheduler. > > > > Rather than depending on a compiler option, wouldn't it be better/more > > robust to change ticks to unsigned, which has specified wrapping behavior? > > Yes, but non-trivial. It's also not limited to ticks. Since the compiler > knows when it would apply these optimizations, it would be nice if it could > warn instead (GCC apparently has a warning, but clang does not). Having > people do a manual audit of every signed integer expression in the tree will > take a long time. I think I misunderstood the problem as being limited to ticks, which is probably only one symptom of a fundamental change in behaviour of the compiler. Still, it might be worthwhile start looking at ints that ought to be implemented as u_int cheers luigi From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 16:19:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD2FA31E for ; Thu, 5 Feb 2015 16:19:10 +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 8582F1FF for ; Thu, 5 Feb 2015 16:19:10 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 192ECB91E; Thu, 5 Feb 2015 11:19:07 -0500 (EST) From: John Baldwin To: Luigi Rizzo Subject: Re: PSA: If you run -current, beware! Date: Thu, 05 Feb 2015 10:48:54 -0500 Message-ID: <8273349.HE1luBF2tk@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20150205152223.GA59664@onelab2.iet.unipi.it> References: <8089702.oYScRm8BTN@overcee.wemm.org> <2613155.3ZBxDvY16q@ralph.baldwin.cx> <20150205152223.GA59664@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 05 Feb 2015 11:19:07 -0500 (EST) Cc: Konstantin Belousov , freebsd-current@freebsd.org, Peter Wemm 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, 05 Feb 2015 16:19:10 -0000 On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: > On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: > > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: > ... > > > > > > It is fixed (in the proper meaning of the word, not like worked > > > > > around, > > > > > covered by paper) by the patch at the end of the mail. > > > > > > > > > > We already have a story trying to enable much less ambitious option > > > > > -fno-strict-overflow, see r259045 and the revert in r259422. I do > > > > > not > > > > > see other way than try one more time. Too many places in kernel > > > > > depend on the correctly wrapping 2-complement arithmetic, among > > > > > others > > > > > are callweel and scheduler. > > > > > > Rather than depending on a compiler option, wouldn't it be better/more > > > robust to change ticks to unsigned, which has specified wrapping > > > behavior? > > > > Yes, but non-trivial. It's also not limited to ticks. Since the compiler > > knows when it would apply these optimizations, it would be nice if it > > could > > warn instead (GCC apparently has a warning, but clang does not). Having > > people do a manual audit of every signed integer expression in the tree > > will take a long time. > > I think I misunderstood the problem as being limited to ticks, > which is probably only one symptom of a fundamental change in behaviour > of the compiler. > Still, it might be worthwhile start looking at ints that ought to be > implemented as u_int I actually agree, I just think we are stuck with -fwrapv in the interval, but it's probably not a short interval. I think converting ticks to unsigned would be a good first start. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 17:15:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E467DD4; Thu, 5 Feb 2015 17:15:17 +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 2779EB2C; Thu, 5 Feb 2015 17:15:17 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 92DA35A9F27; Thu, 5 Feb 2015 17:08:05 +0000 (UTC) Date: Thu, 5 Feb 2015 17:08:05 +0000 From: Brooks Davis To: John Baldwin Subject: Re: PSA: If you run -current, beware! Message-ID: <20150205170805.GA19463@spindle.one-eyed-alien.net> References: <8089702.oYScRm8BTN@overcee.wemm.org> <2613155.3ZBxDvY16q@ralph.baldwin.cx> <20150205152223.GA59664@onelab2.iet.unipi.it> <8273349.HE1luBF2tk@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <8273349.HE1luBF2tk@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Konstantin Belousov , freebsd-current@freebsd.org, Luigi Rizzo , Peter Wemm 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, 05 Feb 2015 17:15:17 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 05, 2015 at 10:48:54AM -0500, John Baldwin wrote: > On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: > > On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: > > > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: > > ... > >=20 > > > > > > It is fixed (in the proper meaning of the word, not like worked > > > > > > around, > > > > > > covered by paper) by the patch at the end of the mail. > > > > > >=20 > > > > > > We already have a story trying to enable much less ambitious op= tion > > > > > > -fno-strict-overflow, see r259045 and the revert in r259422. I= do > > > > > > not > > > > > > see other way than try one more time. Too many places in kernel > > > > > > depend on the correctly wrapping 2-complement arithmetic, among > > > > > > others > > > > > > are callweel and scheduler. > > > >=20 > > > > Rather than depending on a compiler option, wouldn't it be better/m= ore > > > > robust to change ticks to unsigned, which has specified wrapping > > > > behavior? > > >=20 > > > Yes, but non-trivial. It's also not limited to ticks. Since the com= piler > > > knows when it would apply these optimizations, it would be nice if it > > > could > > > warn instead (GCC apparently has a warning, but clang does not). Hav= ing > > > people do a manual audit of every signed integer expression in the tr= ee > > > will take a long time. > >=20 > > I think I misunderstood the problem as being limited to ticks, > > which is probably only one symptom of a fundamental change in behaviour > > of the compiler. > > Still, it might be worthwhile start looking at ints that ought to be > > implemented as u_int >=20 > I actually agree, I just think we are stuck with -fwrapv in the interval,= but=20 > it's probably not a short interval. I think converting ticks to unsigned= =20 > would be a good first start. In principle MIT's KINT tool should help here. Unfortunatly, it's based on LLVM 3.1 and appears to be unmaintained. -- Brooks --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTTo3QACgkQXY6L6fI4GtQIVgCfaOa98qizfggqoDYC010pj5pk mUoAniE3N7MSvxyjC02sNG4cSSktyOB9 =5e3p -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 18:32:17 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F6157CD; Thu, 5 Feb 2015 18:32:17 +0000 (UTC) Received: from mail.eeeit.de (mail.eeeit.de [37.120.160.187]) (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 D32BB6DE; Thu, 5 Feb 2015 18:32:16 +0000 (UTC) Received: from mail.eeeit.de (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eeeit.de (Postfix) with ESMTPS id AAA441642; Thu, 5 Feb 2015 19:32:07 +0100 (CET) Received: (from www@localhost) by mail.eeeit.de (8.14.9/8.14.9/Submit) id t15IW7j7098587; Thu, 5 Feb 2015 19:32:07 +0100 (CET) (envelope-from mike@reifenberger.com) X-Authentication-Warning: mail.eeeit.de: www set sender to mike@reifenberger.com using -f To: Lutz Bichler Subject: Re: i915kms.ko =?UTF-8?Q?regression=3F?= X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Feb 2015 18:32:07 +0000 From: mike@reifenberger.com In-Reply-To: References: Message-ID: X-Sender: mike@reifenberger.com User-Agent: Roundcube Webmail/1.0.5 Cc: xmj@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 18:32:17 -0000 Am 2015-02-05 09:46, schrieb Lutz Bichler: > Hi Johannes, > > i am experiencing a similar behavior on an Asus UX31A. The display is > active but brightness seems to be near 0 and unchangeable. > > Reverting https://svnweb.freebsd.org/changeset/base/277959 made me get > full > brightness again. Unfortunately, brightness changing does not work. > Me too for my Asus UX32VD Notebook. Greetings --- Michael Reifenberger From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 18:47:15 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADE9CC0D for ; Thu, 5 Feb 2015 18:47: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 9E4B1867 for ; Thu, 5 Feb 2015 18:47:15 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id EEBE011C for ; Thu, 5 Feb 2015 18:47:15 +0000 (UTC) Date: Thu, 5 Feb 2015 18:47:14 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1485278053.0.1423162035250.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #644 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 05 Feb 2015 18:47:15 -0000 See From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 19:00:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22F1616F; Thu, 5 Feb 2015 19:00:52 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::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 056D59BF; Thu, 5 Feb 2015 19:00:52 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 4AE9047D; Thu, 5 Feb 2015 11:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1423162851; bh=0s417lVfzt9tPugZNQlBK7yV5r3tSUk7qHeG0ZDm/Ko=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nbXE0lzSNlkmlOgWxyGWT7fLH/HADl63wnLmqilSAeg0xby0vwXoSq9HDVZTUBFXm 5zzDcEBVR9WDm3zWfVOzElF4bGMSG4VeHQ2RJFuOyTf5cI4k2go/mRlCbRaloI5KZi xH4+2CTO5ARzwul0IbekrSh9pDmWc4OK0+X5eGw8= From: Peter Wemm To: John Baldwin Subject: Re: PSA: If you run -current, beware! Date: Thu, 05 Feb 2015 11:00:46 -0800 Message-ID: <14095201.eEMelRF1IS@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <8273349.HE1luBF2tk@ralph.baldwin.cx> References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150205152223.GA59664@onelab2.iet.unipi.it> <8273349.HE1luBF2tk@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8577750.dkiWEzYNTH"; micalg="pgp-sha256"; protocol="application/pgp-signature" Cc: Konstantin Belousov , freebsd-current@freebsd.org, Luigi Rizzo 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, 05 Feb 2015 19:00:52 -0000 --nextPart8577750.dkiWEzYNTH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote: > On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: > > On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: > > > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: > > ... > >=20 > > > > > > It is fixed (in the proper meaning of the word, not like wo= rked > > > > > > around, > > > > > > covered by paper) by the patch at the end of the mail. > > > > > >=20 > > > > > > We already have a story trying to enable much less ambitiou= s > > > > > > option > > > > > > -fno-strict-overflow, see r259045 and the revert in r259422= . I do > > > > > > not > > > > > > see other way than try one more time. Too many places in k= ernel > > > > > > depend on the correctly wrapping 2-complement arithmetic, a= mong > > > > > > others > > > > > > are callweel and scheduler. > > > >=20 > > > > Rather than depending on a compiler option, wouldn't it be bett= er/more > > > > robust to change ticks to unsigned, which has specified wrappin= g > > > > behavior? > > >=20 > > > Yes, but non-trivial. It's also not limited to ticks. Since the= > > > compiler > > > knows when it would apply these optimizations, it would be nice i= f it > > > could > > > warn instead (GCC apparently has a warning, but clang does not). = Having > > > people do a manual audit of every signed integer expression in th= e tree > > > will take a long time. > >=20 > > I think I misunderstood the problem as being limited to ticks, > > which is probably only one symptom of a fundamental change in behav= iour > > of the compiler. > > Still, it might be worthwhile start looking at ints that ought to b= e > > implemented as u_int >=20 > I actually agree, I just think we are stuck with -fwrapv in the inter= val, > but it's probably not a short interval. I think converting ticks to > unsigned would be a good first start. For the record, I agree. However, I suspect that attempts to do so wil= l have=20 a non trivial number of bugs introduced. We have a track record of rec= urring=20 problems with tcp sequence number space arithmetic and tcp timing, part= ly=20 because the wraparounds happens infrequently. In the mean time, I feel that telling the compiler that it's OK to let = it=20 behave the way we expect (vs actively sabotaging it) is a viable stopga= p. =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 --nextPart8577750.dkiWEzYNTH 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 iQEcBAABCAAGBQJU073eAAoJEDXWlwnsgJ4EJbUIAJHyUd7B5SIb1Kh40OBbxnqx +qH8tvo+KFNie5R7IaLL+JmcOuliyycFO32Fen5vXhW/Eiu0iXFQseRFDPme5/yd BSEfd/NrkLCgjlKJmuzmGR+P4l+8V0Xj8Aa1l/I/73Veuev8qGPHsO5gyhDHKTcY y9MEvTVGj/I4FGRlUVdO8Cr9veKASQuTtzu2i53ZVqUPMTtn1M6GgYHdF2i+xvn6 uKUsOByoXf+YaeLYfcPv5W8AZJ0AHXF6OMYnte7fqJkQXG/jUMNxgidYTw8oMns0 GEnwn/AimtoE7bFgiQr+gpesEWtoBqbfmn+OSf2A9tE/1PpiczSmcZg3pLXsK4k= =69Dg -----END PGP SIGNATURE----- --nextPart8577750.dkiWEzYNTH-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 19:20:06 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAA72D00; Thu, 5 Feb 2015 19:20:05 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::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 CD0D1C1A; Thu, 5 Feb 2015 19:20:05 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 954824AB; Thu, 5 Feb 2015 11:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1423164005; bh=eXLWDGya+qs/d+L0zV69lILVrQJ5XxwaLZoVOWF5fhU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KrVU8PpHyGiv5hZg0mMrgJoh17H/3qMYnucraQIVmrGTg6rja72wOWMrQZ0G6+bSJ CWDZ4MbZalwUNWVaMO0THiyZCNsSYinMlEUY778P7FCPE6/o0yF3c6pBtJOuROfo2u ULdXRbVypG7/RRkGSykHrk7y71/HuUc39rTNkIEk= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: PSA: If you run -current, beware! Date: Thu, 05 Feb 2015 11:20:01 -0800 Message-ID: <2082091.ZYtQ1zroo8@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <14095201.eEMelRF1IS@overcee.wemm.org> References: <8089702.oYScRm8BTN@overcee.wemm.org> <8273349.HE1luBF2tk@ralph.baldwin.cx> <14095201.eEMelRF1IS@overcee.wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1943395.5bLfEGhhdO"; micalg="pgp-sha256"; protocol="application/pgp-signature" Cc: Konstantin Belousov , Luigi Rizzo 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, 05 Feb 2015 19:20:06 -0000 --nextPart1943395.5bLfEGhhdO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thursday, February 05, 2015 11:00:46 AM Peter Wemm wrote: > On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote: > > On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: > > > On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: > > > > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: > > > ... > > >=20 > > > > > > > It is fixed (in the proper meaning of the word, not like = worked > > > > > > > around, > > > > > > > covered by paper) by the patch at the end of the mail. > > > > > > >=20 > > > > > > > We already have a story trying to enable much less ambiti= ous > > > > > > > option > > > > > > > -fno-strict-overflow, see r259045 and the revert in r2594= 22. I > > > > > > > do > > > > > > > not > > > > > > > see other way than try one more time. Too many places in= kernel > > > > > > > depend on the correctly wrapping 2-complement arithmetic,= among > > > > > > > others > > > > > > > are callweel and scheduler. > > > > >=20 > > > > > Rather than depending on a compiler option, wouldn't it be > > > > > better/more > > > > > robust to change ticks to unsigned, which has specified wrapp= ing > > > > > behavior? > > > >=20 > > > > Yes, but non-trivial. It's also not limited to ticks. Since t= he > > > > compiler > > > > knows when it would apply these optimizations, it would be nice= if it > > > > could > > > > warn instead (GCC apparently has a warning, but clang does not)= .=20 > > > > Having > > > > people do a manual audit of every signed integer expression in = the > > > > tree > > > > will take a long time. > > >=20 > > > I think I misunderstood the problem as being limited to ticks, > > > which is probably only one symptom of a fundamental change in beh= aviour > > > of the compiler. > > > Still, it might be worthwhile start looking at ints that ought to= be > > > implemented as u_int > >=20 > > I actually agree, I just think we are stuck with -fwrapv in the int= erval, > > but it's probably not a short interval. I think converting ticks t= o > > unsigned would be a good first start. >=20 > For the record, I agree. However, I suspect that attempts to do so w= ill > have a non trivial number of bugs introduced. We have a track record= of > recurring problems with tcp sequence number space arithmetic and tcp > timing, partly because the wraparounds happens infrequently. BTW; anybody working on this will want to run with kern.hz=3D"100000" = in=20 loader.conf (or higher). Having the clock tick 100 times faster speeds= the=20 rollover up from every ~25 days to every ~6 hours. I don't know what t= he=20 practical limit is but at some point it will cause sufficient pain due = to=20 contention that it won't be useful. =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 --nextPart1943395.5bLfEGhhdO 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 iQEcBAABCAAGBQJU08JhAAoJEDXWlwnsgJ4EFpMIANIQPgj0aqZ/ul32WsXUJPrt qz1qkeL6eOC1cP2GQdkGOHY99voNY7CLcvoAqGFsGO/VTLGqKbjoNQhvX3Mn9zTx lMYVAUvQiC0XJLH+HG92ZPEhDpFSRcYyti4DZdrCj018eAA6b95UDe36ee0C37jl Rmtu2zEV/qPVtr1iwgFY6XEi5qZaiXfVGIjvEZy0RRX2cgvZJEvIkm44Bgf3zoFo dZw1ttz8p9lB67TKCuhRUA3OE7MnnwITI2Ak9nqXOTwc5Nbnzc/dB7fGDe2NVGPt nA2FvqfGGTmfSLXFB3AC99U6QRJrXeVUp/t2otRIi9w0hPZB2HIhXq8Gtt20daI= =99Le -----END PGP SIGNATURE----- --nextPart1943395.5bLfEGhhdO-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 19:29:21 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AD8FAD; Thu, 5 Feb 2015 19:29:21 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31697D12; Thu, 5 Feb 2015 19:29:21 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id z20so25496igj.4; Thu, 05 Feb 2015 11:29:20 -0800 (PST) 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=DrA19ysc2j9zurqG+3U7qP8QNoE3vb4TbXy+iYYaRXM=; b=tZtuje9s5bH1qaPeVICPNsojkm1mb+eW0BoC82hiPjuEn8U0iRJMkEHbTIoUX4Fb21 cyA03EmlPi6TS3Sw/TYJjhP1/3UKLFthsquigGFg0pVnmZlpTf5wua1lrpwKG5YgqELc H1ofmmFx6bALpl6fe7SxLCGTxwcy3xFDh1l9BpL45OG12ovsy/OTSF+X89mgG+Q+sYdE HBGCydqynxVp2bGPlUjP48nfdWypOuJCDBkhfsn62yfR+iOFm+x8hM0DVk3uwx20E2Xw MgcusdZYShcMejF8eA3cv2TDveln+0Pl7sgVGINfnZXFb3oVkgNJBXlgH2Y5akDUxQrh 9T/Q== MIME-Version: 1.0 X-Received: by 10.107.31.16 with SMTP id f16mr6457618iof.88.1423164560584; Thu, 05 Feb 2015 11:29:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Thu, 5 Feb 2015 11:29:20 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 11:29:20 -0800 X-Google-Sender-Auth: stqJU9fdMYxWNtIFOqx-QY4NSNg Message-ID: Subject: Re: i915kms.ko regression? From: Adrian Chadd To: Michael Reifenberger Content-Type: text/plain; charset=UTF-8 Cc: Johannes Meixner , "current@freebsd.org" , Lutz Bichler 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, 05 Feb 2015 19:29:21 -0000 There's a backlight_invert tunable/hint that you can set in /boot/loader.conf . Try setting it to 1 and rebooting. -a On 5 February 2015 at 10:32, wrote: > Am 2015-02-05 09:46, schrieb Lutz Bichler: >> >> Hi Johannes, >> >> i am experiencing a similar behavior on an Asus UX31A. The display is >> active but brightness seems to be near 0 and unchangeable. >> >> Reverting https://svnweb.freebsd.org/changeset/base/277959 made me get >> full >> brightness again. Unfortunately, brightness changing does not work. >> > > Me too for my Asus UX32VD Notebook. > > Greetings > --- > Michael Reifenberger > > _______________________________________________ > 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 Feb 5 19:37:40 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DC8F962; Thu, 5 Feb 2015 19:37:40 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE1B9E28; Thu, 5 Feb 2015 19:37:39 +0000 (UTC) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id E3CAD41082; Thu, 5 Feb 2015 19:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1423165052; bh=0MIri+1ZeRZL9JvINJPYYZK/8NtqWybqLvLu45WnczA=; h=Date:From:To:Subject:From; b=PCDBJD0GrAiI1c1eIw0at0AG7jjY+muflH28J4UKGysK/X/T+glKw6LyklyqwaEIr sZEkCnxxFs558vDYMTS3xg3t23PIhK36A2dMGDcPci1I28AwOXjDusBOcEmoYJcYoN bR5gaIMp/9kdVoOGu+T3deMhE3295GD9varYOW3w= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 2B2BC40E73 Message-ID: <54D3C673.70205@riseup.net> Date: Thu, 05 Feb 2015 20:37:23 +0100 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="28U9wtcWcOXLe36DJhUKaEbOtRaTB0jAO" X-Virus-Scanned: clamav-milter 0.98.5 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 05 Feb 2015 19:47:15 +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, 05 Feb 2015 19:37:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --28U9wtcWcOXLe36DJhUKaEbOtRaTB0jAO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I'm trying to set up FreeBSD on MSI X99S SLI Plus. BIOS compatibility mode doesn't work, so I need to use the new UEFI boot. All is well after installing FreeBSD, but when I do buildworld/kernel/installworld cycle I get: >> FreeBSD Boot Block Loader: /boot/loader.efi The same happens on both 10.1-RELEASE and 11.0-CURRENT. I haven't modified the kernel or anything else. --28U9wtcWcOXLe36DJhUKaEbOtRaTB0jAO 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 iQIcBAEBCAAGBQJU08Z5AAoJEC9nKukRsfY+FpkP/RNbeRTmejzkmkzS8nNhAOtV Pq730nOxPlAcYzY9M5S9+obKdnOI+7VZKBj+bsh39K7mzWXsAv5KFPeNxLUBCdYR TG+ws48/zmLLIw/OgziabeCP/8YZyzZHeubVCmE/bKn3At3DYRJxGd890gQ5BNCi uVckMICo11gv+m8MpPp6zn2kBcwibsiOZGzWNLCZAKB9gpAdWg6K0k9K4L+BNieM umW3FdL3YHoewB1LpSt4661m4oktXkO8QO4HdWVLrXhmPCQ9D86/EAvpG9Ct85mE tsqAhFqRnU92uuocIryP/ljlV3bWME5sYztNGk0d+0LXJ/Pt9nc7E3w2B92BeAI5 xBdBosXhJclNqErB4FmNYYKgKpbC+w/vtgD9Q5LXS4rNiqb8arSgqD+JgnRnODzZ 6uKEOAVSqYvhCz7XCNXiETwzvijDEXpn2c2wQ4xilOYzoAwxtpK+LNgC5HDdBe7j y1PbuP+qo3tHbkIJ/Dxgvcjc9+cVzT5/tYAyNSvvu5zMga7WNGIIO8NwHB2gk5Sy FImao1iQlMK74DUrorYu7xLisui5CFFsBHKzFnzpk3FMKuDjmitbe36mmDNGKW6o F9lmWEdgFRWgl5Tufma+G9MtIGv2kHcEqyTcdk/VIVdu/Gzyjv1AdRf0Gxw4OqPA lNu4vaZp8jUBxt0/x1Gv =Demr -----END PGP SIGNATURE----- --28U9wtcWcOXLe36DJhUKaEbOtRaTB0jAO-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 20:22:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 811E6CB8 for ; Thu, 5 Feb 2015 20:22:52 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33DFF663 for ; Thu, 5 Feb 2015 20:22:52 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id id10so3530406vcb.4 for ; Thu, 05 Feb 2015 12:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ckmPKlAQJ7vaMzp17eaWnNWfa1J7zRZ1VXSyteNZm+s=; b=WFtzhheT1VNI497TzM2ab+Q2YwSYUS9CPu9ANx2m9Tq5oN56X9w9qM1KglMyQMOBzi o/CLUqFy9SpHkcmY3EXtbk8SEU6gbizQdZASN401Be9X4w5SkJhYuiYNynUpaEGhedOL D3KoqkU/5eHzbkPIUHud9QuVAfXgdOBBc6qJPfDOvQSpNKoXqsH1aoIlfnL60DvkzWfn Yi+cjKQd35koPa/ucHLyNQwpWTEMOXoOvto8N8UynqwcjaELts/cr/aARkRb3YYQKm+K AW5EI1qxRZvp0hBybGnSfM1zDw1UMYdV/ub6LaZaI4APsTSXBseq5ylPs9z5x74DcXwJ qQew== X-Received: by 10.220.72.1 with SMTP id k1mr4093169vcj.16.1423167771263; Thu, 05 Feb 2015 12:22:51 -0800 (PST) Received: from ?IPv6:2001:470:1f15:b1f:60f8:32ff:c590:9338? ([2001:470:1f15:b1f:60f8:32ff:c590:9338]) by mx.google.com with ESMTPSA id bb5sm40250vdc.8.2015.02.05.12.22.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 12:22:50 -0800 (PST) Message-ID: <54D3D119.7030807@gmail.com> Date: Thu, 05 Feb 2015 21:22:49 +0100 From: =?UTF-8?B?SmFuIEtva2Vtw7xsbGVy?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Battery life with the latest drm References: <20150204202733.GN41565@e-new.0x20.net> In-Reply-To: <20150204202733.GN41565@e-new.0x20.net> Content-Type: text/plain; charset=utf-8; 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, 05 Feb 2015 20:22:52 -0000 On 04.02.2015 21:27, Lars Engels wrote: > By the way on the X230 (IvyBridge i7) the loader.conf setting > "drm.i915.enable_rc6=7" makes a huge difference. > For some other reason I removed it from loader.conf and > hw.acpi.battery.time showed 160 minutes. After re-adding it battery time > went up to 230 minutes. I've been using the same setting for a while now and can confirm the increase of battery life. It also makes a huge difference in fan noise on my T420. Can you suspend/resume with rc6 on? I had to patch around a deadlock in i915_irq.c: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183859 I haven't checked yet if this still occurs after the recent drm import. From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 20:46:30 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A25A1673; Thu, 5 Feb 2015 20:46:30 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 8D705936; Thu, 5 Feb 2015 20:46:30 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 4E366341F90C; Thu, 5 Feb 2015 12:46:30 -0800 (PST) Message-ID: <54D3D6CF.6000903@mu.org> Date: Thu, 05 Feb 2015 12:47:11 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Wemm , John Baldwin Subject: Re: PSA: If you run -current, beware! References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150205152223.GA59664@onelab2.iet.unipi.it> <8273349.HE1luBF2tk@ralph.baldwin.cx> <14095201.eEMelRF1IS@overcee.wemm.org> In-Reply-To: <14095201.eEMelRF1IS@overcee.wemm.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-current@freebsd.org, Luigi Rizzo 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, 05 Feb 2015 20:46:30 -0000 On 2/5/15 11:00 AM, Peter Wemm wrote: > On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote: >> On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: >>> On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: >>>> On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: >>> ... >>> >>>>>>> It is fixed (in the proper meaning of the word, not like worked >>>>>>> around, >>>>>>> covered by paper) by the patch at the end of the mail. >>>>>>> >>>>>>> We already have a story trying to enable much less ambitious >>>>>>> option >>>>>>> -fno-strict-overflow, see r259045 and the revert in r259422. I do >>>>>>> not >>>>>>> see other way than try one more time. Too many places in kernel >>>>>>> depend on the correctly wrapping 2-complement arithmetic, among >>>>>>> others >>>>>>> are callweel and scheduler. >>>>> >>>>> Rather than depending on a compiler option, wouldn't it be better/more >>>>> robust to change ticks to unsigned, which has specified wrapping >>>>> behavior? >>>> >>>> Yes, but non-trivial. It's also not limited to ticks. Since the >>>> compiler >>>> knows when it would apply these optimizations, it would be nice if it >>>> could >>>> warn instead (GCC apparently has a warning, but clang does not). Having >>>> people do a manual audit of every signed integer expression in the tree >>>> will take a long time. >>> >>> I think I misunderstood the problem as being limited to ticks, >>> which is probably only one symptom of a fundamental change in behaviour >>> of the compiler. >>> Still, it might be worthwhile start looking at ints that ought to be >>> implemented as u_int >> >> I actually agree, I just think we are stuck with -fwrapv in the interval, >> but it's probably not a short interval. I think converting ticks to >> unsigned would be a good first start. > > For the record, I agree. However, I suspect that attempts to do so will have > a non trivial number of bugs introduced. We have a track record of recurring > problems with tcp sequence number space arithmetic and tcp timing, partly > because the wraparounds happens infrequently. > > In the mean time, I feel that telling the compiler that it's OK to let it > behave the way we expect (vs actively sabotaging it) is a viable stopgap. > Seems like it would make sense to move these functions into files that can be easily compiled outside of kernel and then adding unit tests. I've done this before, to prove that larger pcb hashes help performance on large workloads. -Alfred From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 21:28:53 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 026D2343; Thu, 5 Feb 2015 21:28:53 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 893AEE4D; Thu, 5 Feb 2015 21:28:52 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id h11so640487wiw.5; Thu, 05 Feb 2015 13:28:51 -0800 (PST) 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=Eq2Zmp3/S5el1jmwltE/E/77++2ZY4OiXjLT+X4j/y0=; b=Jaboc13TGEEzfsf5V6ELeBvQAeAgNWLkgWfpU63AEQxUXQKHwvUlY+AZpWOsCmnv2P D9OuxNhfzYCjZCew3j665SaU+6kqp3MvBIcPV9vqJxn2opFd0/hKE5YVvs+fDNpwAlxO UKGzqNbCSR94/Q4nj4qZcPT8wvXXfft4lQmAI/I+UjDr2FwRadMqDHPNTq86DGG70w2e 5N5yIfPMw31Y6+Of271iaGJXjiD5zkXfhlm10VSW0PG5vE50ySb0VO3jJezCEpsfL5gg nh2eGvZa3+AwNWD3+Lbewxbs9OXQjnEM5vKtUhCK8XRWNb1jBkB1xTcxCrXI3OTRYdsJ Nv6A== MIME-Version: 1.0 X-Received: by 10.194.93.134 with SMTP id cu6mr384814wjb.79.1423171730992; Thu, 05 Feb 2015 13:28:50 -0800 (PST) Received: by 10.27.8.17 with HTTP; Thu, 5 Feb 2015 13:28:50 -0800 (PST) In-Reply-To: <54D3C673.70205@riseup.net> References: <54D3C673.70205@riseup.net> Date: Thu, 5 Feb 2015 15:28:50 -0600 Message-ID: Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT From: "Sam Fourman Jr." To: Piotr Kubaj Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current , freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:28:53 -0000 On Thu, Feb 5, 2015 at 1:37 PM, Piotr Kubaj wrote: > Hi all, > > I'm trying to set up FreeBSD on MSI X99S SLI Plus. BIOS compatibility > mode doesn't work, so I need to use the new UEFI boot. All is well after > installing FreeBSD, but when I do buildworld/kernel/installworld cycle I > get: > >> FreeBSD Boot Block > Loader: /boot/loader.efi > The same happens on both 10.1-RELEASE and 11.0-CURRENT. I haven't > modified the kernel or anything else. > > I can confirm this, a straight USB image for current doesn't boot, 10.0 boots fine but nothing after. I have a Lenovo B570 uefi -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 21:33:43 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 350126AF; Thu, 5 Feb 2015 21:33:43 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E1D0F52; Thu, 5 Feb 2015 21:33:42 +0000 (UTC) Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id A37BE4199D; Thu, 5 Feb 2015 21:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1423172021; bh=8tQ60Xd7V9bqHIS1bVLtOGE78fRxxxxOzreeDDS4kU8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ReoD1ojxRe8ieS2APhORy6/PT1UT4tf0qepNDRSzKnSUcrddDKWyvS82RpeWq+0KK 16BdjJKobkTtXgIoBh7UWjNXYA1Re76Z4XP4Sct6T2hlWVtNfRg/VIpZ/D0H9dLDsi CZDSIK9chTjzz6MMJiL/6HGXYTq3Fhm6dFD3Bw+8= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id A23B020090 Message-ID: <54D3E1B1.6040701@riseup.net> Date: Thu, 05 Feb 2015 22:33:37 +0100 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Sam Fourman Jr." , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT References: <54D3C673.70205@riseup.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="efAHboGSbsxpKP7BBMl47RCHu1rgO0hCV" X-Virus-Scanned: clamav-milter 0.98.5 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 05 Feb 2015 22:00:13 +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, 05 Feb 2015 21:33:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --efAHboGSbsxpKP7BBMl47RCHu1rgO0hCV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/05/15 22:28, Sam Fourman Jr. wrote: >=20 >=20 > On Thu, Feb 5, 2015 at 1:37 PM, Piotr Kubaj > wrote: >=20 > Hi all, >=20 > I'm trying to set up FreeBSD on MSI X99S SLI Plus. BIOS compatibili= ty > mode doesn't work, so I need to use the new UEFI boot. All is well = after > installing FreeBSD, but when I do buildworld/kernel/installworld cy= cle I > get: > >> FreeBSD Boot Block > Loader: /boot/loader.efi > The same happens on both 10.1-RELEASE and 11.0-CURRENT. I haven't > modified the kernel or anything else. >=20 >=20 >=20 >=20 > I can confirm this, a straight USB image for current doesn't boot, 10.0= > boots fine but nothing after. >=20 > I have a Lenovo B570 uefi > --=20 >=20 > Sam Fourman Jr. UEFI USB images (10.1/11.0) work as well as booting after installation. It's just that after upgrading from source it can't boot anymore. --efAHboGSbsxpKP7BBMl47RCHu1rgO0hCV 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 iQIcBAEBCAAGBQJU0+GyAAoJEC9nKukRsfY+qukP/3OajzMgJqLNUaLkynB6aBDp EnqTkcI2aNHmwcdAx/gMR3oLbTX8UukPnfznEHEMKR6SAx6zCuKdwGUmJJJDPHXT G5Zw0xyBwemutjzkX3tZg88WWKG2WGEpwQ65fjgPcup6Agkg1/Y19gs1FIcw8ax8 0XGwp73R37mdybOmXxhrUX/7ZJmORgoDf5o2KBLtWZ29jgrNrk11ljv1v09wD0p4 5iODx75lJn8OTY0cjHRo850zbxlQynGeTtdyeiMmh8Xaw1ic8oa9vae4c4gFYf94 +HecFMywqKqV/a+F6Fp/SGE05ZgUk6hn/taINr9FWm3ewkx/N2o5jgVOVLhTS9mC 4e6eF/c9MTL7VGZk5BAOfV0c2rwtq4jV54rv5OhH0G2VBCv5wPjUMzPOcF/wFjkE DyenwGgL3eULY948xbhRUjkpM3VuKfGNa8gHwDTx+Z5yGE4zGg4d9iaysLipvv8v Cb5sebtwTjFicVGJ2L2/SLCGL03sDtTmWN++qgVctjxjurW2ULEv76iAD8sDU33i 7Ley6qZkf8sernmWyGLie/tDxQgZaaW6aOJhKB6GzP0YVIg9DJttkIPC9VvU0t5Z zL90j9nOaB8kvaitEmgPPjYW2YQLPewXw/2O1MMk0KvuWBbi0PpmpZ0K5SEWQ+YD wJw/z5bfpIoW3VNreUrU =kbXC -----END PGP SIGNATURE----- --efAHboGSbsxpKP7BBMl47RCHu1rgO0hCV-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 23:03:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BCED4A4 for ; Thu, 5 Feb 2015 23:03:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 1A67FC73 for ; Thu, 5 Feb 2015 23:03:17 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B828117A for ; Thu, 5 Feb 2015 23:03:16 +0000 (UTC) Date: Thu, 5 Feb 2015 23:03:16 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1829748120.1.1423177396292.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1485278053.0.1423162035250.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1485278053.0.1423162035250.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to stable : FreeBSD_HEAD-tests2 #645 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 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: Thu, 05 Feb 2015 23:03:17 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 00:21:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E20961C4 for ; Fri, 6 Feb 2015 00:21:22 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 610C05E3 for ; Fri, 6 Feb 2015 00:21:22 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id f15so13212803lbj.5 for ; Thu, 05 Feb 2015 16:21:20 -0800 (PST) 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=umsu7qEbu43R0wAx8m7PQvlwIDeQbyZoKUDvpSDE15k=; b=IUKKK+6ug0GGp6JfYSaKjdGjORJXxNJ9w2sDLUQiV0qNDWypdYjqCXAEHiDlu9Q4eW IcJ4oY6HKb3mWjjQCrZXjU/G+0YQHH2x8dUV24sSa49Fm3MAj+ZViRigk2Tvokkcr8B8 bV318viXlVbH0nLOIDE1h84sCLHVOUQBe9zweNdYd6FXz7oRYy9GxVhEhMkqfdt8Zhko L9XjTtGUHLQL6Gk5hkbRt6fnlNw+nflrh5rIbFNaykoLip7G79eIGug6XWqNoqeUH4Rg SL4LRqfxjdEyMb97HbNJUTJGl0pUe71r7jrSnNUXwJ0DJuhsFvYHxb2m2ojJzAy0imMR b40g== MIME-Version: 1.0 X-Received: by 10.112.182.72 with SMTP id ec8mr565274lbc.122.1423182080431; Thu, 05 Feb 2015 16:21:20 -0800 (PST) Received: by 10.114.78.131 with HTTP; Thu, 5 Feb 2015 16:21:20 -0800 (PST) In-Reply-To: <2509923.ondFvsFdql@overcee.wemm.org> References: <8089702.oYScRm8BTN@overcee.wemm.org> <20150204142941.GE42409@kib.kiev.ua> <2509923.ondFvsFdql@overcee.wemm.org> Date: Thu, 5 Feb 2015 19:21:20 -0500 Message-ID: Subject: Re: PSA: If you run -current, beware! From: Ryan Stone To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , 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, 06 Feb 2015 00:21:23 -0000 On Wed, Feb 4, 2015 at 6:15 PM, Peter Wemm wrote: > --- kern/kern_clock.c 2014-12-01 15:42:21.707911656 -0800 > +++ kern/kern_clock.c 2014-12-01 15:42:21.707911656 -0800 > @@ -410,6 +415,11 @@ > #ifdef SW_WATCHDOG > EVENTHANDLER_REGISTER(watchdog_list, watchdog_config, NULL, 0); > #endif > + /* > + * Arrange for ticks to go negative just 5 minutes after boot > + * to help catch sign problems sooner. > + */ > + ticks = INT_MAX - (hz * 5 * 60); > } Should we just commit this under #ifdef INVARIANTS? From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 02:29:52 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94090AB2; Fri, 6 Feb 2015 02:29:52 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D62813D; Fri, 6 Feb 2015 02:29:52 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id fb4so1807931wid.2; Thu, 05 Feb 2015 18:29:50 -0800 (PST) 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=/1hFyj1Miqyx38hxJKvphaDwOPFC4QQdLz0UOJrcQiY=; b=c513tfLsp5onXWG4ME6Nu/q8QlsgTl70T1hSHckyvp6+YQaLLIBKr/PsY3qlR7LagB +VnxmzfjRGomkPtA1jbuM66Sf1T+SwMkxi1Kstj7OmqXxixLO4UIxXO5NiC13HZRcKFB IagYUnax0WN6+l/ar9Drg5JdoR7sVrTrCJLI8YNCD16eOQJnMAnKR1vI3pfauzASkiMG sGUg99pfK4dbVJkRPn8eEaaDZN3JxW7AqTVbedO2d1Rg5S+8eQw/uCr74lIX0t25GiZ0 8N2akfbHyD4p4DzZH90YhefxBmIaOxlefIGJjN1nY/zTvnxgP6U6lkpWJOH/nS3fff23 Armw== MIME-Version: 1.0 X-Received: by 10.194.192.98 with SMTP id hf2mr2624580wjc.52.1423189790658; Thu, 05 Feb 2015 18:29:50 -0800 (PST) Received: by 10.27.8.17 with HTTP; Thu, 5 Feb 2015 18:29:50 -0800 (PST) In-Reply-To: <392DFE0A-C1D2-4674-8B85-202050D0157D@me.com> References: <54D3C673.70205@riseup.net> <54D3E1B1.6040701@riseup.net> <392DFE0A-C1D2-4674-8B85-202050D0157D@me.com> Date: Thu, 5 Feb 2015 20:29:50 -0600 Message-ID: Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT From: "Sam Fourman Jr." To: Rui Paulo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current , freebsd-stable@freebsd.org, Piotr Kubaj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 02:29:52 -0000 > > Can you tell us which version of CURRENT you tried? > > I tried, r278209 on my lenovo B570, then very early in the boot process it locks up and stops. > -- > Rui Paulo > > > > -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 03:02:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 217EFB4; Fri, 6 Feb 2015 03:02:59 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E793E828; Fri, 6 Feb 2015 03:02:58 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NJB002FNXRP9H30@st11p02mm-asmtp001.mac.com>; Fri, 06 Feb 2015 03:02:16 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-06_01:2015-02-06,2015-02-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502060028 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT From: Rui Paulo In-reply-to: Date: Thu, 05 Feb 2015 19:02:12 -0800 Content-transfer-encoding: quoted-printable Message-id: <283D8F90-9EB1-4B69-A501-88DF907A674E@me.com> References: <54D3C673.70205@riseup.net> <54D3E1B1.6040701@riseup.net> <392DFE0A-C1D2-4674-8B85-202050D0157D@me.com> To: "Sam Fourman Jr." X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Fri, 06 Feb 2015 03:35:51 +0000 Cc: FreeBSD Current , freebsd-stable@freebsd.org, Piotr Kubaj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 03:02:59 -0000 On Feb 5, 2015, at 18:29, Sam Fourman Jr. wrote: >=20 >> Can you tell us which version of CURRENT you tried? >>=20 >> I tried, r278209 on my lenovo B570, then very early in the boot = process it > locks up and stops. If it stops in boot1, then it's because it couldn't find the UFS = partition with loader.efi. Did you test the memstick or your own = installation? -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 03:08:59 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F36A5AB9; Fri, 6 Feb 2015 03:08:58 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6505860; Fri, 6 Feb 2015 03:08:58 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NJB000IGV8RLP00@st11p02mm-asmtp001.mac.com>; Fri, 06 Feb 2015 02:07:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-06_01:2015-02-06,2015-02-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1502060019 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT From: Rui Paulo In-reply-to: <54D3E1B1.6040701@riseup.net> Date: Thu, 05 Feb 2015 18:07:39 -0800 Content-transfer-encoding: quoted-printable Message-id: <392DFE0A-C1D2-4674-8B85-202050D0157D@me.com> References: <54D3C673.70205@riseup.net> <54D3E1B1.6040701@riseup.net> To: Piotr Kubaj X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Fri, 06 Feb 2015 04:51:31 +0000 Cc: "Sam Fourman Jr." , freebsd-current@freebsd.org, freebsd-stable@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, 06 Feb 2015 03:08:59 -0000 On Feb 5, 2015, at 13:33, Piotr Kubaj wrote: >=20 > On 02/05/15 22:28, Sam Fourman Jr. wrote: >>=20 >>=20 >> On Thu, Feb 5, 2015 at 1:37 PM, Piotr Kubaj > > wrote: >>=20 >> Hi all, >>=20 >> I'm trying to set up FreeBSD on MSI X99S SLI Plus. BIOS = compatibility >> mode doesn't work, so I need to use the new UEFI boot. All is well = after >> installing FreeBSD, but when I do buildworld/kernel/installworld = cycle I >> get: >>>> FreeBSD Boot Block >> Loader: /boot/loader.efi >> The same happens on both 10.1-RELEASE and 11.0-CURRENT. I haven't >> modified the kernel or anything else. >>=20 >>=20 >>=20 >>=20 >> I can confirm this, a straight USB image for current doesn't boot, = 10.0 >> boots fine but nothing after. >>=20 >> I have a Lenovo B570 uefi >> --=20 >>=20 >> Sam Fourman Jr. > UEFI USB images (10.1/11.0) work as well as booting after = installation. > It's just that after upgrading from source it can't boot anymore. Can you tell us which version of CURRENT you tried? -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 06:04:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D57CCF55; Fri, 6 Feb 2015 06:04:41 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65D3AAEF; Fri, 6 Feb 2015 06:04:41 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id k48so11657335wev.12; Thu, 05 Feb 2015 22:04:39 -0800 (PST) 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=NHyniAIdeIHvcU0melHgbIJjMn8FgNcyAPT4tAptbV8=; b=ktm1NVR2hWW5FGm86YOCWNUKgQYtGvE4NyEP69DVggCsenyadMQqvD/LAq8Z6rCMON HPwyU0VD2osubHaa23hN3sMEMT0gKeHAiOcmi3LeKpJ8veYMSyRZwYq7ctGMEc9iUlOL xKg1r489LWmT5p+4On9dgjY+qS/yldL7lXJs72z9098uuKaDzE9TQM6ihytCUpHi+SQc ZpFfsad/akZZk+2xh//9FDDxHsm7mKMiaQYfenWYfJ18HTu49ZzKM+rAhQA1uOXadjD6 RNsgn8xEDGXdxAeqK1FozyIsIJAdHmT8J3u0P0E6yEvhlD1XoPTkjB5HPscgMEebXgpf H5tg== MIME-Version: 1.0 X-Received: by 10.180.73.170 with SMTP id m10mr1302156wiv.72.1423202679856; Thu, 05 Feb 2015 22:04:39 -0800 (PST) Received: by 10.27.8.17 with HTTP; Thu, 5 Feb 2015 22:04:39 -0800 (PST) In-Reply-To: <283D8F90-9EB1-4B69-A501-88DF907A674E@me.com> References: <54D3C673.70205@riseup.net> <54D3E1B1.6040701@riseup.net> <392DFE0A-C1D2-4674-8B85-202050D0157D@me.com> <283D8F90-9EB1-4B69-A501-88DF907A674E@me.com> Date: Fri, 6 Feb 2015 00:04:39 -0600 Message-ID: Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT From: "Sam Fourman Jr." To: Rui Paulo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current , freebsd-stable@freebsd.org, Piotr Kubaj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 06:04:42 -0000 On Thu, Feb 5, 2015 at 9:02 PM, Rui Paulo wrote: > On Feb 5, 2015, at 18:29, Sam Fourman Jr. wrote: > > > >> Can you tell us which version of CURRENT you tried? > >> > >> I tried, r278209 on my lenovo B570, then very early in the boot process > it > > locks up and stops. > > If it stops in boot1, then it's because it couldn't find the UFS partition > with loader.efi. Did you test the memstick or your own installation? > > it was memstick > -- > Rui Paulo > > > > -- Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 08:07:37 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DF4D4FB for ; Fri, 6 Feb 2015 08:07:37 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb: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 589B28E8 for ; Fri, 6 Feb 2015 08:07:37 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id A169E6A61CE; Fri, 6 Feb 2015 09:07:33 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id t1687XQR022812; Fri, 6 Feb 2015 09:07:33 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id t1687Wov021210; Fri, 6 Feb 2015 09:07:32 +0100 (CET) (envelope-from lars) Date: Fri, 6 Feb 2015 09:07:32 +0100 From: Lars Engels To: Jan =?utf-8?Q?Kokem=C3=BCller?= Subject: Re: Battery life with the latest drm Message-ID: <20150206080732.GP41565@e-new.0x20.net> Mail-Followup-To: Lars Engels , Jan =?utf-8?Q?Kokem=C3=BCller?= , freebsd-current@freebsd.org References: <20150204202733.GN41565@e-new.0x20.net> <54D3D119.7030807@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/OC9VIUhC1tLvmgX" Content-Disposition: inline In-Reply-To: <54D3D119.7030807@gmail.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 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: Fri, 06 Feb 2015 08:07:37 -0000 --/OC9VIUhC1tLvmgX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 05, 2015 at 09:22:49PM +0100, Jan Kokem=C3=BCller wrote: >=20 > On 04.02.2015 21:27, Lars Engels wrote: > > By the way on the X230 (IvyBridge i7) the loader.conf setting > > "drm.i915.enable_rc6=3D7" makes a huge difference. > > For some other reason I removed it from loader.conf and > > hw.acpi.battery.time showed 160 minutes. After re-adding it battery time > > went up to 230 minutes. >=20 > I've been using the same setting for a while now and can confirm the=20 > increase of battery life. It also makes a huge difference in fan noise=20 > on my T420. >=20 > Can you suspend/resume with rc6 on? I had to patch around a deadlock in= =20 > i915_irq.c: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183859 > I haven't checked yet if this still occurs after the recent drm import. Yes, I can suspend and resume several times. I haven't seen a broken s/r cycle since the latest drm import. --/OC9VIUhC1tLvmgX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJU1HZEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t9fUIAITktbINGfxOocj77xlhnkpo OspTfJiFKpP7z7oq21Q0C/17a5+hTOQgfzv+JKIVFyvjpFty2ZSBdRPGlXL43Wio q62vPpNUD+jNYNFDEkCYCCB5eDV3udiVN+D+P3aXJmcwInahkSF80Vnh5FSS4knQ brPXXLsbRrQ5Nt9TmFA5pb0S3YQt/VWCz5ogxBQxZnqnKQ8LGI0D80+0vEfOSBvf O9vivlDZLClfUBL2buxD8XHEsBWy+NcW17bwB13PxXXIdYE5zt7jz7uJqlsNtlad kR53/kSAHUfSlVD+ngYdjtMLckBwhw0b0yUisleCCce0BV2QFxPJw97EHd4R8Ps= =WF7j -----END PGP SIGNATURE----- --/OC9VIUhC1tLvmgX-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 12:28:17 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0D767CF for ; Fri, 6 Feb 2015 12:28:17 +0000 (UTC) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 67E81A5C for ; Fri, 6 Feb 2015 12:28:17 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPA id 6ED1EC493D; Fri, 6 Feb 2015 14:22:50 +0200 (EET) Date: Fri, 6 Feb 2015 14:23:12 +0200 From: Aleksandr Rybalko To: Michal Varga Subject: Re: vt(4) sysctl inconsistency question Message-Id: <20150206142312.2a9935dc58796e88be92205f@freebsd.org> In-Reply-To: <1423087017.854.20.camel@stonehenge.sk> References: <1423087017.854.20.camel@stonehenge.sk> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: 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, 06 Feb 2015 12:28:17 -0000 On Wed, 04 Feb 2015 22:56:57 +0100 Michal Varga wrote: > I have a quick question regarding the vt driver which hopefully someone > involved in its design could answer for me. > > Roughly 4 months ago, vt gained the ability to listen to a set of > keyboard combinations controlling power/debug situations and the ability > to control (or more precisely, turn off) their behavior via sysctls: > > http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381& > > Interestingly, two cases in particular (excluding SPSC which isn't > implemented yet) were left out of this configuration, namely the standby > and suspend modes (STBY, SUSP), making use of those keys completely > non-optional. > > If anyone could tell me, what was the reason for not including sysctls > for those two modes? > > m. > > > -- > Michal Varga, > Stonehenge > > > > > _______________________________________________ > 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" Hi Michal! When I was work on vt(4) due to lack of knowledge about kbd(4) internals I decide to not touch it a lot, so I mostly just copy sc(4) things :) IIRC support of such keys/combinations will require some updates to kbd(4). Think, if somebody will prepare patch for such things, guys and maybe me, will be happy to review and possibly commit it. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 13:06:07 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D34E477 for ; Fri, 6 Feb 2015 13:06:07 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E5CD8E98 for ; Fri, 6 Feb 2015 13:06:06 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id F28F03B8B5 for ; Fri, 6 Feb 2015 13:06:04 +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 t16D63md001265 for ; Fri, 6 Feb 2015 13:06:03 GMT (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org Subject: unbound crashes on bootup From: Poul-Henning Kamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1263.1423227963.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Feb 2015 13:06:03 +0000 Message-ID: <1264.1423227963@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: Fri, 06 Feb 2015 13:06:07 -0000 I just updated my -current to r278283, and unbound (still) croaks during bootup: Feb 6 13:00:54 critter dhclient: New Broadcast Address (wlan0): 192.168.6= 0.255 Feb 6 13:00:54 critter dhclient: New Routers (wlan0): 192.168.60.1 Feb 6 13:00:54 critter kernel: pid 515 (unbound), uid 59: exited on signa= l 11 Feb 6 13:00:58 critter ntpd_initres[769]: host name not found: pool.ntp.o= rg No core file... -- = 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 Fri Feb 6 17:10:27 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86E7A389 for ; Fri, 6 Feb 2015 17:10:27 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 49F7DE42 for ; Fri, 6 Feb 2015 17:10:27 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9F4B53B8A2 for ; Fri, 6 Feb 2015 17:10:25 +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 t16HAOhV001939 for ; Fri, 6 Feb 2015 17:10:24 GMT (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org Subject: Weird ACPI/DRM messages on -current From: Poul-Henning Kamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1937.1423242624.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 06 Feb 2015 17:10:24 +0000 Message-ID: <1938.1423242624@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: Fri, 06 Feb 2015 17:10:27 -0000 Thinkpad T430s: 11.0-CURRENT #15 r278283: Thu Feb 5 22:45:26 UTC 2015 Anybody know what this means ? Feb 6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 000700= 00, was 19070000 Feb 6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 00000000 Feb 6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 Feb 6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERR= OR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 190700= 00, was 19000000 -- = 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 Fri Feb 6 17:39:31 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0F08B89; Fri, 6 Feb 2015 17:39:31 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 96ADF1F4; Fri, 6 Feb 2015 17:39:31 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 08A9D7300A; Fri, 6 Feb 2015 18:44:53 +0100 (CET) Date: Fri, 6 Feb 2015 18:44:53 +0100 From: Luigi Rizzo To: freebsd-x11@freebsd.org Subject: howto: nvidia geforce210 and 4k display Message-ID: <20150206174452.GA75454@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Luigi Rizzo , 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, 06 Feb 2015 17:39:31 -0000 Thought this might be useful to others: I have managed to use the nvidia geforce210 card with a 4k display and am attaching below the relevant xorg.conf info: -------------- # ... Section "Monitor" Identifier "seiki39u" Modeline "4k25" 225 3840 3900 3950 4000 2160 2168 2178 2250 # this is the one Modeline "4k30" 297 3840 4040 4240 4400 2160 2168 2178 2250 EndSection Section "Device" Identifier "geforce210" Driver "nvidia" # need nvidia-driver 340 or earlier BusID "PCI:1:0:0" # depends on your card EndSection Section "Screen" Identifier "Screen0" Device "geforce210" Monitor "seiki39u" Option "ModeValidation" "NoVertRefreshCheck, NoMaxPClkCheck, AllowNonEdidModes" SubSection "Display" Viewport 0 0 Depth 24 Modes "4k25" # "1920x1080_30" EndSubSection EndSection --------- Some comments: - you need the nvidia-driver 340 or earlier, newer versions do not support the GeForce 210 - the card itself is not rated for 4k, and appears to have a maximum pixel clock frequency of 225 MHz (sometimes negotiating even just 165 MHz with the monitor). I am using the HDMI port. - the Modeline "4k25" can be used to run at 4k/25Hz (which is the most you can get with such a pixel clock). Not that you are losing much, since HDMI 1.3 can only to 4k/30Hz at most. - you need to specify the Modeline because the monitor does not return a compatible mode through EDID (mine is a seiki TV se39uy01 - the very poor UK model; but i suspect others have the same issue): the modeline supplied by the tv uses a 297 MHz clock even at 50 Hz. - finally, in the "Screen" section you need some options to tell the driver to omit certain checks: Option "ModeValidation" "NoVertRefreshCheck, NoMaxPClkCheck, AllowNonEdidModes" And that's all. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 18:51:23 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88927650 for ; Fri, 6 Feb 2015 18:51:23 +0000 (UTC) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39176C8B for ; Fri, 6 Feb 2015 18:51:23 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id bs8so4600079wib.1 for ; Fri, 06 Feb 2015 10:51:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:content-type:mime-version :content-transfer-encoding; bh=VZcN45tz6hAloZAvgAa5kCY1QsbCv5xQisbokZZC7eM=; b=jeaUZALr6isaEhx1aoUME8qd/clhRyoAc5HSkvM6LALTuPaWC0XVI1CEEyW+72Vx0S aNxwAqACRWfaVJTiXvSaOJF6m/ymJkV07lySOWYtSCSAHtQbigqr0FHy4SyMhCzOjsWL djgyRiHzR2jQjizetldGGkboglYrGuYZRQto5sGNDySXy8XqRJ4ACjaRC534EVoR6PUO i4M9p9gZXv9yt5VKQxqP4PMH7mFf8GkEAIADx2YzKV1Io7qjhMa6NWlKo+Fut3zSGhBN qcM7XXdusYewwC2GNwu5E2vF9HGhJV28Po2vFfFGrTFwL5qizjHUzuNmmpaZT2WmT7WZ qoSg== X-Gm-Message-State: ALoCoQkEKeobgLRolmW+UIvb5E2Yz2zlcs9/Cx1owBCTnB2lex8qC2FlDDjHLPC7qjLi/I3QT9Jr X-Received: by 10.194.175.202 with SMTP id cc10mr10461930wjc.27.1423248177241; Fri, 06 Feb 2015 10:42:57 -0800 (PST) Received: from xenon (105.42.broadband6.iol.cz. [88.101.42.105]) by mx.google.com with ESMTPSA id bv6sm4421826wjb.30.2015.02.06.10.42.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 10:42:56 -0800 (PST) Message-ID: <1423248174.885.30.camel@stonehenge.sk> Subject: Re: vt(4) sysctl inconsistency question From: Michal Varga To: Aleksandr Rybalko Date: Fri, 06 Feb 2015 19:42:54 +0100 In-Reply-To: <20150206142312.2a9935dc58796e88be92205f@freebsd.org> References: <1423087017.854.20.camel@stonehenge.sk> <20150206142312.2a9935dc58796e88be92205f@freebsd.org> Organization: Stonehenge Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.10 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: 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, 06 Feb 2015 18:51:23 -0000 On Fri, 2015-02-06 at 14:23 +0200, Aleksandr Rybalko wrote: > On Wed, 04 Feb 2015 22:56:57 +0100 > Michal Varga wrote: >> [...] > > Interestingly, two cases in particular (excluding SPSC which isn't > > implemented yet) were left out of this configuration, namely the standby > > and suspend modes (STBY, SUSP), making use of those keys completely > > non-optional. > > > > If anyone could tell me, what was the reason for not including sysctls > > for those two modes? > > > > m. > > > Hi Michal! > > When I was work on vt(4) due to lack of knowledge about kbd(4) > internals I decide to not touch it a lot, so I mostly just copy sc(4) > things :) > > IIRC support of such keys/combinations will require some updates to > kbd(4). > > Think, if somebody will prepare patch for such things, guys and maybe > me, will be happy to review and possibly commit it. > > Thanks! Hello Aleksandr, I think you misunderstood what I meant. The code in question is already there, just that some particular cases are not configurable via sysctl: http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381& At lines 500-528, all cases got their own sysctls so you can easily turn their behavior on/off: case SPCLKEY | XXXX: if (vt_XXXX) ... The other three cases (l. 530-540), one of them unfinished though, are missing sysctls, so vt will always execute those actions no matter what. Now that you mentioned copying sc(4) stuff, I cross-checked it with sc sources and you're right, even sc is missing configuration in cases like suspend and standby (which is kinda puzzling, to me). So now the question stands - can we have the rest of this behavior configurable, or is there any opposition to it? Which would mean adding another set of: VT_SYSCTL_INT(kbd_saver, 1, "Enable screen saver keyboard combination." VT_SYSCTL_INT(kbd_standby, 1, "Enable PM standby keyboard combination." VT_SYSCTL_INT(kbd_suspend, 1, "Enable PM suspend keyboard combination." and ading the corresponding 'if (vt_' to those cases that are missing them. If that's ok with you and you're interested, I could submit a patch via PR for review... m. -- Michal Varga, Stonehenge From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 20:10:17 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C189CF8 for ; Fri, 6 Feb 2015 20:10:17 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14F69671 for ; Fri, 6 Feb 2015 20:10:16 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1YJpAM-002WHY-VM>; Fri, 06 Feb 2015 21:06:14 +0100 Received: from g225116137.adsl.alicedsl.de ([92.225.116.137] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1YJpAM-001nuU-Sg>; Fri, 06 Feb 2015 21:06:14 +0100 Date: Fri, 6 Feb 2015 21:06:07 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r278328: fails to build kernel due to /usr/src/sys/kern/subr_bus.c: undefined reference to `memchr' Message-ID: <20150206210607.4a39a75d.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/z1e3Q9i22oo8C0GT0oEUcVC"; protocol="application/pgp-signature" X-Originating-IP: 92.225.116.137 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 20:10:17 -0000 --Sig_/z1e3Q9i22oo8C0GT0oEUcVC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recent sources seem to fail in buildkernel with [...] --- kernel --- linking kernel subr_bus.o: In function `devctl2_ioctl': /usr/src/sys/kern/subr_bus.c:(.text+0x6284): undefined reference to `memchr' *** [kernel] Error code 1 Regards, oh --Sig_/z1e3Q9i22oo8C0GT0oEUcVC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU1R6vAAoJEOgBcD7A/5N8/tkIALNrgazm2hHp1VtiuKbQ681r LJye5r6tcR8Ffge9B2hDEEftj6V+IByTAVgoGQtwko+7cWYlI4Re2RMDPSK023iR K6+UAYbz1Vke1ADD5OdtuflOBjP7K7GjPIl2ceIZUo0SC52gNA5Rop5EXNDKkzy1 mdrFYT/p310ak1EJILrtWnuwsRs7Ul5j7+rmhvOAef/n2a+pnEK9cHRPiOPCpcTw oHrFB8skNCz+BylnRh0GMNzP8p09x3IxycclqxtROl0OoizgrDqx13cNQxirkvvc YoWMztcuLaZM8wKlWL5scjk7dDFrlcD0euEc9B0cqdwXZiw03RK7dEi80HbN7eM= =SgAM -----END PGP SIGNATURE----- --Sig_/z1e3Q9i22oo8C0GT0oEUcVC-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 20:49:46 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86BF1BB3 for ; Fri, 6 Feb 2015 20:49:46 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 589A0B11 for ; Fri, 6 Feb 2015 20:49:46 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so17000357pdb.4 for ; Fri, 06 Feb 2015 12:49:45 -0800 (PST) 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=MbjlBLvjurHvFOK3LpHphU4oJ8EppRhTNKwPYhlzOls=; b=Jd8vR5Lc+zfhDEpT9Rk6NeiPxksJrSCjT2+NDZjJTX5kcel5hCHGPLal28QQabaanv 0B+Sdq5TqXLrTGsVkK2aJcljhco7O1z9eodd7a60HJxbpJfWzJbbVUNVfJbqJmc1YnoF 3fMX1orF2PFm9o0CAwn4ItNGbJRgfDhvo1JtU/v1KqXZ6Ilxl7N1aEd1mwnpht2E3hqX RvxMfRtgXzbHiQPJX1BJE7qQHAsqGpyv5Tq/1L3s8LtFm+7EaCFqsG9JnwSQ66ijpbSW nV0eQPL/B6o2Ldo+0XkQJmDcOsDzyT/NYOxNAxtMX406S6m0Xs7+EJif3D2UDk2P5Hxd f/sw== X-Received: by 10.66.157.5 with SMTP id wi5mr8586348pab.37.1423255785448; Fri, 06 Feb 2015 12:49:45 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:e47d:5c02:fe5f:40fa? ([2601:8:ab80:7d6:e47d:5c02:fe5f:40fa]) by mx.google.com with ESMTPSA id qy3sm8940836pbc.4.2015.02.06.12.49.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 12:49:44 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5CCA599D-8D81-4C75-A260-9713A948FA09"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Weird ACPI/DRM messages on -current From: Garrett Cooper In-Reply-To: <1938.1423242624@critter.freebsd.dk> Date: Fri, 6 Feb 2015 12:49:42 -0800 Message-Id: <4BF9B60F-D4B4-43A3-A8F4-0341DBEEF1AE@gmail.com> References: <1938.1423242624@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.1878.6) Cc: 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, 06 Feb 2015 20:49:46 -0000 --Apple-Mail=_5CCA599D-8D81-4C75-A260-9713A948FA09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 6, 2015, at 9:10, Poul-Henning Kamp wrote: > Thinkpad T430s: >=20 > 11.0-CURRENT #15 r278283: Thu Feb 5 22:45:26 UTC 2015 >=20 > Anybody know what this means ? >=20 > Feb 6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 00070000, was 19070000 > Feb 6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 00000000 > Feb 6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 > Feb 6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] = *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected = 19070000, was 19000000 Please file a bug for the logspam. Thanks! --Apple-Mail=_5CCA599D-8D81-4C75-A260-9713A948FA09 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 iQEcBAEBCgAGBQJU1SjnAAoJEMZr5QU6S73eaVgH/jk3vryExwRhF20dJZFJTCYU vEy0cPIsWIi0UWouh1fGby6pKpJgX3QMcP05F08LVvnjBNRbt8xbMHa6ClJ7qkWI hCkJJK1WG+DjvsFpFSeiY+SyQXiEPAvpTGu24tG6tIVn6e6QStB3QBM9zQkEpn1N /w11im2xYqlI39ngnf41Nl0uBYX0QkCYq+BqOYXhXJ5rjYt0Y6fCxbdgeRHH7vAq EBWDhT9B4TUjgV/f23oDYCEcKwswtQV8yZBJrzrcK1x0RC1pajmNpCGNdNyLBmxd E4uhSRKufozBXl8RNO8JRARnnaTGFVS0U6h185QEIviuTJEjmkPHjydaTnAbvB4= =G0nt -----END PGP SIGNATURE----- --Apple-Mail=_5CCA599D-8D81-4C75-A260-9713A948FA09-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 21:05:44 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 167D122C; Fri, 6 Feb 2015 21:05:44 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CBFC0D51; Fri, 6 Feb 2015 21:05:43 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id DDE7693847; Fri, 6 Feb 2015 21:05:41 +0000 (UTC) Message-ID: <54D52CBC.80507@freebsd.org> Date: Fri, 06 Feb 2015 16:06:04 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Weird ACPI/DRM messages on -current References: <1938.1423242624@critter.freebsd.dk> In-Reply-To: <1938.1423242624@critter.freebsd.dk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PCjmenqQU6wKnfji1kBJpSK8xSfcJfEOM" Cc: kib@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, 06 Feb 2015 21:05:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PCjmenqQU6wKnfji1kBJpSK8xSfcJfEOM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-02-06 12:10, Poul-Henning Kamp wrote: > Thinkpad T430s: >=20 > 11.0-CURRENT #15 r278283: Thu Feb 5 22:45:26 UTC 2015 >=20 > Anybody know what this means ? >=20 > Feb 6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 00= 070000, was 19070000 > Feb 6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 00000000 > Feb 6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 > Feb 6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *= ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19= 070000, was 19000000 >=20 >=20 I am pretty sure this is specific to the new drm code I saw similar messages when testing the drm patch before it was committed= --=20 Allan Jude --PCjmenqQU6wKnfji1kBJpSK8xSfcJfEOM 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) iQIcBAEBAgAGBQJU1Sy/AAoJEJrBFpNRJZKf7nsP/Rd20hYKWZ3ElGRX6yNmNPb8 MaA8jJ9xjT1aHBgyQG5XyytIissGza75Ps82bANl1Bv+R3kXCenDL/1uy31a4+8y kVho2s1oH0iXSgGcbD81HXZEBXH9fKrlxIMIrIhgNAGhU1v5JBsqwxXwtxUaXnFT c/o6EIn0iiR0JCmnRwyJC4CnGlTHonNIHfYMWnBNzEmR8s1b4sDib49PvIDeQJcr 3Gm95vUsyUMzhxEqQ9q6wTsdMkN6ASJxqM3oPc3RBvkjpsArKQF7f6jRud661vVN 00DeAuTPRECt5Ws4RbB5atkOx5BFjAcdTbC6FlpmtT3pLrDiu3RiKnAdgKhj4nQ2 ITFXQyAV9e0/+04IJMatphM0WW3JllMZCo1tny90KaoPqc1YmEIt9WqTEU/g7gHE 3JE0wQIe6SkF9/uNcgkba0h87RrFOPgwO6gxvvNtLty3a8oA4cffz4wjSt/IJBT6 rW6Mpicx0nRrTezN+lWf3bFnQ6KLH/RSFIp5il901rtU6SaU7Ls3iqgir0mwsR92 z36S8rLK+csvPa4K0/9ZUozwt47yfaTUZdO78DC1Q9uzqzE+/HIjqQe3DfIDgAbT MScuHV45BZZtCHTLLArbs103joWaDJMPbb0kyyCtd2nkCr8oilYJIWSLfRXs+48Q tx6pqJRXziFpphWn/YHH =qBH1 -----END PGP SIGNATURE----- --PCjmenqQU6wKnfji1kBJpSK8xSfcJfEOM-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 22:00:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3287AA9; Fri, 6 Feb 2015 22:00:27 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03853302; Fri, 6 Feb 2015 22:00:26 +0000 (UTC) Received: by iecrl12 with SMTP id rl12so4689015iec.11; Fri, 06 Feb 2015 14:00:20 -0800 (PST) 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=bn4P6EPp+GmftcLoqzWq62pYLoP+VahQ3SZaWanis5I=; b=RWS1K7v9uh1TJQKHxbMI4RvKF/sDN0yJU9MWVek5vvq1wQPFi7JNNWZPhKErLEEpCe L8u1s+GlePQIqAhncfaLk2r4Bu3KUK1083Pd7vRuhC8yId9s8eTcI7qyNK+agOKcv1wW vmZlb02XWhv1bjQ00qLVX4tTJMFtSIwNqKlud+tuxgv3x5wksSXtx0T4FYz+eYmNVaZ+ Dk7t4Wufm0StlF0iEbduUs90BLseEEC/kIzhgGytNi4hUbrssSmuZ2rM241DFKbGRcuf yB+1SMeiYxUOcDg0Smpnsesl6hTZsPANnqgYZ6ZTVONbZ7jQi4oxC6Ktm55MYFN5/go2 MAzw== MIME-Version: 1.0 X-Received: by 10.107.136.143 with SMTP id s15mr13467829ioi.8.1423260020161; Fri, 06 Feb 2015 14:00:20 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.7 with HTTP; Fri, 6 Feb 2015 14:00:20 -0800 (PST) In-Reply-To: <54D52CBC.80507@freebsd.org> References: <1938.1423242624@critter.freebsd.dk> <54D52CBC.80507@freebsd.org> Date: Fri, 6 Feb 2015 14:00:20 -0800 X-Google-Sender-Auth: GcYIuc4QcPBtosnYhrl53zqOlzM Message-ID: Subject: Re: Weird ACPI/DRM messages on -current From: Adrian Chadd To: Allan Jude Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current , Konstantin Belousov 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, 06 Feb 2015 22:00:27 -0000 Can someone just go digging through the include files to see what the difference in bits are? This may be related to increased power usage that's been reported. -a On 6 February 2015 at 13:06, Allan Jude wrote: > On 2015-02-06 12:10, Poul-Henning Kamp wrote: >> Thinkpad T430s: >> >> 11.0-CURRENT #15 r278283: Thu Feb 5 22:45:26 UTC 2015 >> >> Anybody know what this means ? >> >> Feb 6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 00070000, was 19070000 >> Feb 6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 00000000 >> Feb 6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> Feb 6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 >> >> > > I am pretty sure this is specific to the new drm code > > I saw similar messages when testing the drm patch before it was committed > > -- > Allan Jude > From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 22:09:45 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC30C4D8 for ; Fri, 6 Feb 2015 22:09:45 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B02425F7 for ; Fri, 6 Feb 2015 22:09:45 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 514B460; Fri, 6 Feb 2015 17:09:43 -0500 (EST) Message-ID: <54D53BA2.6080406@protected-networks.net> Date: Fri, 06 Feb 2015 17:09:38 -0500 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "O. Hartmann" , FreeBSD CURRENT Subject: Re: r278328: fails to build kernel due to /usr/src/sys/kern/subr_bus.c: undefined reference to `memchr' References: <20150206210607.4a39a75d.ohartman@zedat.fu-berlin.de> In-Reply-To: <20150206210607.4a39a75d.ohartman@zedat.fu-berlin.de> OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t2Aehhc4ptI2qBSt5CKIrc5DHjRMAgx61" 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, 06 Feb 2015 22:09:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t2Aehhc4ptI2qBSt5CKIrc5DHjRMAgx61 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/06/15 15:06, O. Hartmann wrote: > Recent sources seem to fail in buildkernel with >=20 > [...] > --- kernel --- > linking kernel > subr_bus.o: In function `devctl2_ioctl': > /usr/src/sys/kern/subr_bus.c:(.text+0x6284): undefined reference to `me= mchr' > *** [kernel] Error code 1 It seems that this function in libkern was conditionally compiled. You might try this: *** sys/conf/files~ Sat Jan 31 10:44:44 2015 --- sys/conf/files Fri Feb 6 17:05:37 2015 *************** *** 3193,3199 **** libkern/murmur3_32.c standard libkern/mcount.c optional profiling-routine libkern/memcchr.c standard ! libkern/memchr.c optional fdt | gdb libkern/memcmp.c standard libkern/memmem.c optional gdb libkern/qsort.c standard --- 3193,3199 ---- libkern/murmur3_32.c standard libkern/mcount.c optional profiling-routine libkern/memcchr.c standard ! libkern/memchr.c standard libkern/memcmp.c standard libkern/memmem.c optional gdb libkern/qsort.c standard --t2Aehhc4ptI2qBSt5CKIrc5DHjRMAgx61 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 iEYEARECAAYFAlTVO6UACgkQQv9rrgRC1JJbUwCguzUYH+pZ+TR57budqrZm1q9I fY4AniGua0K/ACe5VJEQ+Vn1SWIa9goX =7rEF -----END PGP SIGNATURE----- --t2Aehhc4ptI2qBSt5CKIrc5DHjRMAgx61-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 22:49:13 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C3F25EA for ; Fri, 6 Feb 2015 22:49:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 69076A6E for ; Fri, 6 Feb 2015 22:49:13 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2D2023F3 for ; Fri, 6 Feb 2015 22:49:12 +0000 (UTC) Date: Fri, 6 Feb 2015 22:49:08 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <698115300.2.1423262948983.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build became unstable: FreeBSD_HEAD-tests2 #651 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 06 Feb 2015 22:49:13 -0000 See From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 23:35:13 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B13A53AB; Fri, 6 Feb 2015 23:35:13 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 802B8F72; Fri, 6 Feb 2015 23:35:13 +0000 (UTC) Received: by pdjg10 with SMTP id g10so11595696pdj.1; Fri, 06 Feb 2015 15:35:12 -0800 (PST) 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=5oAp4hrBVQmraJCLZrAZhDBrCN8m8RewdFhMR021hH4=; b=UwuD/gWl6q36DCT0tpnmUJJtVgBEq1cFPfsb0Sc0OJpbZVsC+N15Li5YEDv2L92J6x MHA7/B42GCBQ9CP4ST8pobfsbh1yrehvGR/rzbxzGD3mrddoPOj9ysHu4nz7wnW7IOYe JTuE7q9oqsrkIfZKNFx3WpN2JCm0bRafURLjG9F8efizyhSs6yRyQkdRA/AgUUGWEAN6 e6JS1ZJl3uQ39h+35byhPcV3RfTX3A5nCDVrH1P0LJzSwVx6lrLOYHYEf7UP7ghBwCv8 rczXAXVHH44rLDv/4g1bI+uy+SomTYID+h07FA6eRkvYyEn+VxHkK3i5hXyQGBgDcJ65 Nm3A== X-Received: by 10.66.62.229 with SMTP id b5mr9696455pas.30.1423265712714; Fri, 06 Feb 2015 15:35:12 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:e47d:5c02:fe5f:40fa? ([2601:8:ab80:7d6:e47d:5c02:fe5f:40fa]) by mx.google.com with ESMTPSA id pn2sm9111409pbb.42.2015.02.06.15.35.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 15:35:11 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_6C251643-B355-4B5F-944B-F593FB249550"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: r278328: fails to build kernel due to /usr/src/sys/kern/subr_bus.c: undefined reference to `memchr' From: Garrett Cooper In-Reply-To: <54D53BA2.6080406@protected-networks.net> Date: Fri, 6 Feb 2015 15:35:10 -0800 Message-Id: References: <20150206210607.4a39a75d.ohartman@zedat.fu-berlin.de> <54D53BA2.6080406@protected-networks.net> To: Michael Butler X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD CURRENT , "O. Hartmann" 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, 06 Feb 2015 23:35:13 -0000 --Apple-Mail=_6C251643-B355-4B5F-944B-F593FB249550 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 6, 2015, at 14:09, Michael Butler = wrote: > On 02/06/15 15:06, O. Hartmann wrote: >> Recent sources seem to fail in buildkernel with >>=20 >> [...] >> --- kernel --- >> linking kernel >> subr_bus.o: In function `devctl2_ioctl': >> /usr/src/sys/kern/subr_bus.c:(.text+0x6284): undefined reference to = `memchr' >> *** [kernel] Error code 1 >=20 > It seems that this function in libkern was conditionally compiled. You > might try this: >=20 >=20 > *** sys/conf/files~ Sat Jan 31 10:44:44 2015 > --- sys/conf/files Fri Feb 6 17:05:37 2015 > *************** > *** 3193,3199 **** > libkern/murmur3_32.c standard > libkern/mcount.c optional profiling-routine > libkern/memcchr.c standard > ! libkern/memchr.c optional fdt | gdb > libkern/memcmp.c standard > libkern/memmem.c optional gdb > libkern/qsort.c standard > --- 3193,3199 ---- > libkern/murmur3_32.c standard > libkern/mcount.c optional profiling-routine > libkern/memcchr.c standard > ! libkern/memchr.c standard > libkern/memcmp.c standard > libkern/memmem.c optional gdb > libkern/qsort.c standard Thank you for the report. The issue has been fixed in r278336. --Apple-Mail=_6C251643-B355-4B5F-944B-F593FB249550 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 iQEcBAEBCgAGBQJU1U+uAAoJEMZr5QU6S73eFNIH/RYDKzjzNUM8/CKR5sx3EH6R dHkdg1hcbQUP6xURHWZAtL3yDgHQCMBMsJ4dlahGBBFHxaiTlmIxQn//Qto/xASy FDVCwmQGpWja4XWyRpknrH/ttcvlpSiNDSuou0gIKMdjXH1BFMLfvApXcvz4uYa+ gnYqa/pTo0bZb0JglYrK6yIniZUBvtfN/oys8V1K8v+do5d8Flx6asC56X5zmFbV EukDKbpMCSmtjXY4L24pY/mESZdtVx9+qMm2APGoHe/vpE8gtRNGRuUnFWyW+IJQ qFKcHKOD4L3imNU07plV438O1SDOama1Sjm55W6DOjfxJcXpW0SbiVYHVXjGTas= =ieVm -----END PGP SIGNATURE----- --Apple-Mail=_6C251643-B355-4B5F-944B-F593FB249550-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 01:48:39 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 245BAE22; Sat, 7 Feb 2015 01:48:39 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2815E16; Sat, 7 Feb 2015 01:48:38 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq14so13294175pab.11; Fri, 06 Feb 2015 17:48:38 -0800 (PST) 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=InKPSzcQBuTE3wXKxpTs0ZnAdgr6lfg09QQ/uQ8nG3E=; b=BFe/aw8McPyf/1wRoCzyoLArb4O9mTP0yVhnVX9kFidV6exJsEb+OZQ9PN6oP+DrDl quXYle4W0FgHse/vPIv9UUm8P7XeDAcdHTPQ8aZ3uDqSgZBpjHWdQh3bjipxDzd2iKZP f5PxRZYYFz+FcJmcwzHNQwjP6FVBlg9YHe87tmLk5jnwrEsGVeRjnQhswSbwi5DCCPxq MkeFEBNQlNEEbnrK2TjbMWMEWtXyCJYd11LodKM+RfLv2wQQ3sR4Qujs/p3l1rstiQ6Y DQkB5ZWCcAOl92olXkvTBIqSloqtYCf2XKTlKdfaz2bASi3I4I//sfyiN9JKqHXDdGEJ KZ5A== MIME-Version: 1.0 X-Received: by 10.68.68.131 with SMTP id w3mr10283571pbt.132.1423273717429; Fri, 06 Feb 2015 17:48:37 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.22.231 with HTTP; Fri, 6 Feb 2015 17:48:37 -0800 (PST) In-Reply-To: References: <1938.1423242624@critter.freebsd.dk> <54D52CBC.80507@freebsd.org> Date: Fri, 6 Feb 2015 17:48:37 -0800 X-Google-Sender-Auth: k5VxvkfWkpo31wmN4IKtlE5ayQQ Message-ID: Subject: Re: Weird ACPI/DRM messages on -current From: Kevin Oberman To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Konstantin Belousov , 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: Sat, 07 Feb 2015 01:48:39 -0000 On Fri, Feb 6, 2015 at 2:00 PM, Adrian Chadd wrote: > Can someone just go digging through the include files to see what the > difference in bits are? > > This may be related to increased power usage that's been reported. > > > -a > It's defined in /sys/dev/drm2/i915/i915_reg.h. Unfortunately, no breakdown is shown. In i915_irq.c and intel_display I see: I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, 18 << 24 | 6 << 16); The exact same code appears in both and these are the only references to that I can find. This leaves my with no more idea than I had before I looked. maybe someone has more of a clue. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 01:56:19 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EFD6129 for ; Sat, 7 Feb 2015 01:56:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF00EF2 for ; Sat, 7 Feb 2015 01:56:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3F55A429 for ; Sat, 7 Feb 2015 01:56:19 +0000 (UTC) Date: Sat, 7 Feb 2015 01:56:18 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1286782134.3.1423274178582.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <698115300.2.1423262948983.JavaMail.jenkins@jenkins-9.freebsd.org> References: <698115300.2.1423262948983.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #652 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 07 Feb 2015 01:56:19 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 02:35:31 2015 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 535BB5CD; Sat, 7 Feb 2015 02:35:31 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D65D2AD; Sat, 7 Feb 2015 02:35:27 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t172ZQXc059415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2015 18:35:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t172ZP7F059414; Fri, 6 Feb 2015 18:35:25 -0800 (PST) (envelope-from jmg) Date: Fri, 6 Feb 2015 18:35:25 -0800 From: John-Mark Gurney To: security@FreeBSD.org, current@FreeBSD.org Subject: request for crypto hardware... Message-ID: <20150207023525.GC58410@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 06 Feb 2015 18:35:26 -0800 (PST) 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, 07 Feb 2015 02:35:31 -0000 I have some plans to improve the opencrypto framework in FreeBSD later this year. This will require invasive changes to the various drivers. So, I'd like to line up hardware/volunteers before then. If you would like to see your hardware tested and verified to work with the new changes, please contact me w/ either a donation of hardware, money to purchase hardware, or if you have hardware, that you volunteer to test changes. I currently have the following hardware: aesni I do not have the following hardware: hifn ubsec padlock (VIA C3, C7 and Eden) cesa (Marvell, missing man page) glxsb (AMD Geode LX, such as Sokris Net5501, missing man page) safe (SafeNet) sec (Freescale, missing man page) cryptocteon (Cavium Octeon, missing man page) nlmsec (mips/nlm/dev/sec/nlmsec.c, missing man page) rmisec (mips/rmi/dev/sec/rmisec.c, missing man page) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 02:41:42 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5D70929; Sat, 7 Feb 2015 02:41:42 +0000 (UTC) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B25BA3B6; Sat, 7 Feb 2015 02:41:42 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id rd3so20953640pab.9; Fri, 06 Feb 2015 18:41:42 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=29hKjzDc7Wqe8QxT2YTtUnq2MCAJFLm3YZayPjpZ1bo=; b=L/sYEzZdnS8H6oUcSnpyUEvaPFMZXyzuFnyDD+bDFDlSFT/AvD/iNY5YnUfDUIzXop DiSALLZpFYj44VHAJMK4y0+n43yKb5LN6A50CMHkSFI5xQf0YbQZEhPldiy8wLdNWEzh 5UKuOUFu4DBGNYVt2clvmgBO5aeGVis0+CFlw/FIfSmxZ5aBgMXWc0Z//S7gLs+uljz9 UIHJRiydmrsG3ZbS1HqngsS5FhOmzqpsa1QcjBDVho3SoTltem//CgxW/4UtA5RKjtfq okfaazFP4e/Xs+lvT2JVN866Q8TUkttmM/1lcN8QAG2eL+6t2Oavft+Ba2iFU5p4QQzl WsBA== X-Received: by 10.70.93.97 with SMTP id ct1mr10521178pdb.71.1423276902016; Fri, 06 Feb 2015 18:41:42 -0800 (PST) Received: from neil.creepingfur.org (tessier.creepingfur.is. [70.36.196.188]) by mx.google.com with ESMTPSA id hr3sm480356pbb.13.2015.02.06.18.41.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Feb 2015 18:41:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: request for crypto hardware... From: Benjamin Perrault In-Reply-To: <20150207023525.GC58410@funkthat.com> Date: Fri, 6 Feb 2015 18:41:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <775F9DB7-A493-48CF-8B77-30A71693FD98@gmail.com> References: <20150207023525.GC58410@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2070.6) Cc: current@FreeBSD.org, security@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, 07 Feb 2015 02:41:43 -0000 I have a Soekris Net5501 ( glxsb ) w/ a vpn1411 card in it ( which is a = hifn based crypto board ) that you can have. And they are in SF, so, I = believe, fairly local for you.=20 Let me know if they are of interest. cheers, -bp > On Feb 6, 2015, at 6:35 PM, John-Mark Gurney wrote: >=20 > I have some plans to improve the opencrypto framework in FreeBSD later > this year. This will require invasive changes to the various drivers. > So, I'd like to line up hardware/volunteers before then. >=20 > If you would like to see your hardware tested and verified to work > with the new changes, please contact me w/ either a donation of > hardware, money to purchase hardware, or if you have hardware, that > you volunteer to test changes. >=20 > I currently have the following hardware: > aesni >=20 > I do not have the following hardware: > hifn > ubsec > padlock (VIA C3, C7 and Eden) > cesa (Marvell, missing man page) > glxsb (AMD Geode LX, such as Sokris Net5501, missing man page) > safe (SafeNet) > sec (Freescale, missing man page) > cryptocteon (Cavium Octeon, missing man page) > nlmsec (mips/nlm/dev/sec/nlmsec.c, missing man page) > rmisec (mips/rmi/dev/sec/rmisec.c, missing man page) >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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 Feb 7 04:55:09 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA284CDA for ; Sat, 7 Feb 2015 04:55: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 987C1399 for ; Sat, 7 Feb 2015 04:55:09 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3BB7C479 for ; Sat, 7 Feb 2015 04:55:09 +0000 (UTC) Date: Sat, 7 Feb 2015 04:55:09 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1286251311.4.1423284909039.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1286782134.3.1423274178582.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1286782134.3.1423274178582.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #653 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 07 Feb 2015 04:55:09 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 04:59:01 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 185B9DEC; Sat, 7 Feb 2015 04:59:01 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CC8003B8; Sat, 7 Feb 2015 04:59:00 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t174wxMI060196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2015 20:58:59 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t174wxpb060195; Fri, 6 Feb 2015 20:58:59 -0800 (PST) (envelope-from jmg) Date: Fri, 6 Feb 2015 20:58:59 -0800 From: John-Mark Gurney To: Benjamin Perrault Subject: Re: request for crypto hardware... Message-ID: <20150207045859.GF58410@funkthat.com> References: <20150207023525.GC58410@funkthat.com> <775F9DB7-A493-48CF-8B77-30A71693FD98@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <775F9DB7-A493-48CF-8B77-30A71693FD98@gmail.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 06 Feb 2015 20:58:59 -0800 (PST) Cc: freebsd-security@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 04:59:01 -0000 Benjamin Perrault wrote this message on Fri, Feb 06, 2015 at 18:41 -0800: > I have a Soekris Net5501 ( glxsb ) w/ a vpn1411 card in it ( which is a hifn based crypto board ) that you can have. And they are in SF, so, I believe, fairly local for you. > > Let me know if they are of interest. Thanks, I've taken this offer off list. > > On Feb 6, 2015, at 6:35 PM, John-Mark Gurney wrote: > > > > I have some plans to improve the opencrypto framework in FreeBSD later > > this year. This will require invasive changes to the various drivers. > > So, I'd like to line up hardware/volunteers before then. > > > > If you would like to see your hardware tested and verified to work > > with the new changes, please contact me w/ either a donation of > > hardware, money to purchase hardware, or if you have hardware, that > > you volunteer to test changes. > > > > I currently have the following hardware: > > aesni > > > > I do not have the following hardware: > > hifn > > ubsec > > padlock (VIA C3, C7 and Eden) > > cesa (Marvell, missing man page) > > glxsb (AMD Geode LX, such as Sokris Net5501, missing man page) > > safe (SafeNet) > > sec (Freescale, missing man page) > > cryptocteon (Cavium Octeon, missing man page) > > nlmsec (mips/nlm/dev/sec/nlmsec.c, missing man page) > > rmisec (mips/rmi/dev/sec/rmisec.c, missing man page) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 08:38:27 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4614B7B8 for ; Sat, 7 Feb 2015 08:38:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3480AABA for ; Sat, 7 Feb 2015 08:38:27 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id B75884F4 for ; Sat, 7 Feb 2015 08:38:27 +0000 (UTC) Date: Sat, 7 Feb 2015 08:38:27 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1020340459.5.1423298307660.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1286251311.4.1423284909039.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1286251311.4.1423284909039.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #654 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 07 Feb 2015 08:38:27 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 10:22:53 2015 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFEEFE0A for ; Sat, 7 Feb 2015 10:22:53 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7EAF76AA for ; Sat, 7 Feb 2015 10:22:53 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t17AMmsD099809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Feb 2015 12:22:48 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t17AMmsD099809 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t17AMl1s099808; Sat, 7 Feb 2015 12:22:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Feb 2015 12:22:47 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Subject: Re: Weird ACPI/DRM messages on -current Message-ID: <20150207102247.GX42409@kib.kiev.ua> References: <1938.1423242624@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1938.1423242624@critter.freebsd.dk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org 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, 07 Feb 2015 10:22:54 -0000 On Fri, Feb 06, 2015 at 05:10:24PM +0000, Poul-Henning Kamp wrote: > Thinkpad T430s: > > 11.0-CURRENT #15 r278283: Thu Feb 5 22:45:26 UTC 2015 > > Anybody know what this means ? There is no public documentation about renderer power and clock management. It seems that NDA'ed doc does not contain it either, but I am not sure if I am allowed to publically state what NDA doc does not contain. > > Feb 6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 00070000, was 19070000 > Feb 6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 00000000 > Feb 6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 > Feb 6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 19070000, was 19000000 These are mostly informational messages, code was taken verbosely from the Linux kernel. It seems that later Linux code reorganized code and get rid of the message. Some next import will shut down the warnings. From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 14:35:10 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 273CAC4D for ; Sat, 7 Feb 2015 14:35:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 158B6E8A for ; Sat, 7 Feb 2015 14:35:10 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 455AF583 for ; Sat, 7 Feb 2015 14:35:10 +0000 (UTC) Date: Sat, 7 Feb 2015 14:35:10 +0000 (GMT) From: jenkins-admin@freebsd.org To: freebsd-current@freebsd.org Message-ID: <1246533071.6.1423319710222.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1020340459.5.1423298307660.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1020340459.5.1423298307660.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #655 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_HEAD-tests2 X-Jenkins-Result: UNSTABLE 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, 07 Feb 2015 14:35:10 -0000 See From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 16:34:41 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29BE4C0E for ; Sat, 7 Feb 2015 16:34:41 +0000 (UTC) Received: from smtp.rlwinm.de (smtp.rlwinm.de [148.251.233.239]) (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 98DEAB24 for ; Sat, 7 Feb 2015 16:34:40 +0000 (UTC) Received: from hexe.rlwinm.de (unknown [172.22.228.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 0E54C15CB0 for ; Sat, 7 Feb 2015 17:34:37 +0100 (CET) Message-ID: <54D63E9C.3010606@rlwinm.de> Date: Sat, 07 Feb 2015 17:34:36 +0100 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: request for crypto hardware... References: <20150207023525.GC58410@funkthat.com> In-Reply-To: <20150207023525.GC58410@funkthat.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: Sat, 07 Feb 2015 16:34:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07.02.2015 03:35, John-Mark Gurney wrote: > I have some plans to improve the opencrypto framework in FreeBSD > later this year. This will require invasive changes to the various > drivers. So, I'd like to line up hardware/volunteers before then. > > If you would like to see your hardware tested and verified to work > with the new changes, please contact me w/ either a donation of > hardware, money to purchase hardware, or if you have hardware, > that you volunteer to test changes. > > I currently have the following hardware: aesni > > I do not have the following hardware: hifn ubsec padlock (VIA C3, > C7 and Eden) cesa (Marvell, missing man page) glxsb (AMD Geode LX, > such as Sokris Net5501, missing man page) safe (SafeNet) sec > (Freescale, missing man page) cryptocteon (Cavium Octeon, missing > man page) nlmsec (mips/nlm/dev/sec/nlmsec.c, missing man page) > rmisec (mips/rmi/dev/sec/rmisec.c, missing man page) I can send you some VIA C7 padlock hardware and test changes on a VIA Nano. Would an IGEL Thinclient with a 1GHz VIA C7 CPU, 256MiB DDR2 SO-DIMM RAM, a CF slot, 2.5" PATA and PXE capable 100Mb/s Ethernet NIC help? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU1j6VAAoJEL3T4KNA/nyDfuIP/1WPXyTbEq1sLEmGpYwUqlRm GvYypRCbd1YitMUHOHVApUt19JznPNM72TpECUwacpUySfPj8DjErBMRWROd8WBv mWCyA7OJ665NCIBiq/EZLkHPu0/ftDE78xfPYkVy69i+2nriqZdUTh2wOh5SH6hl fm2ibph75fCbAB9ttUG+bdgU2wY+2xOVeSnv5AihwphvuRR89eWHHeyIGrKPH5b8 W3YwbNOQp4tPeZg6I5MokB5LMZsHV4DIfmSWzLq4Rd2h89ZsH83Kfe3k9bKJlLVc Ft+w197G5rz0cq7dszWV+jcWbAOF4frzWLGrzIThEucic1tjeetkLAvSjp9xOK30 pmPgMN/UrfWGBScRnWvhC5nwXz2NQlRbXvLhI2345tMqYZMgPSYTwA9yyj6ME17V aAlR9asnTLU1Xa5YbAl+U9mMD19ejyf09q1BCJWr4oSVQUHLF1MEF/Pht73rk1kU VLdjvDgt/vDartFmygzbYA2CiHxkGqWa8e6+4upnuoirIK49mzQz0oa5RXLAvuJ2 Pwt1VD4d2YDlv6KfI6f2sItk7LiXISpK9exl2fyLD1nYCHSOYsHmBTPoJjwcKiAb SKeQwm9xfib5Py4FJEosKsAod2X8Dhbiox0iDfJIf9cs0ivlWmNzTv9VZuN8kz91 Zbwrxw/0/kJQcMh2fv8h =ghNW -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 16:51:55 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79ADAF32; Sat, 7 Feb 2015 16:51:55 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 68230CF9; Sat, 7 Feb 2015 16:51:55 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5900C5B3; Sat, 7 Feb 2015 16:51:55 +0000 (UTC) Date: Sat, 7 Feb 2015 16:51:52 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org, dim@FreeBSD.org, trasz@FreeBSD.org, mav@FreeBSD.org Message-ID: <450287559.7.1423327915095.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD #2329 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: Sat, 07 Feb 2015 16:51:55 -0000 See Changes: [trasz] Make hccontrol(8) and sdpcontrol(8) appear in "man -k bluetooth" ou= tput. MFC after:=091 month Sponsored by:=09The FreeBSD Foundation [trasz] Tidy up; no functional changes. MFC after:=091 month Sponsored by:=09The FreeBSD Foundation [mav] Teach ctld(8) to control non-iSCSI CTL ports. This change introduces new target option "port", that assigns current targe= t to specified CTL port. On config application ctld(8) will apply LUN mappin= g according to target configuration to specified port and bring the port up. On shutdown cltd(8) will remove the mapping and put the port down. This change allows to configure both iSCSI and FibreChannel targets in the same configuration file in alike way. Kernel side support was added earlier at r278037. MFC after:=092 weeks Relnotes:=09yes Sponsored by:=09iXsystems, Inc. [trasz] Remove useless comment. MFC after:=091 month Sponsored by:=09The FreeBSD Foundation [dim] Add llvm patch corresponding to r278349. [dim] Pull in r224884 from upstream llvm trunk (by Keno Fischer): [FastIsel][X86] Fix invalid register replacement for bool args Summary: Consider the following IR: %3 =3D load i8* undef %4 =3D trunc i8 %3 to i1 %5 =3D call %jl_value_t.0* @foo(..., i1 %4, ...) ret %jl_value_t.0* %5 Bools (that are the result of direct truncs) are lowered as whatever the argument to the trunc was and a "and 1", causing the part of the MBB responsible for this argument to look something like this: %vreg8 =3D AND8ri %vreg7, 1, %EFLAGS; GR= 8:%vreg8,%vreg7 Later, when the load is lowered, it will insert %vreg15 =3D MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR= 8:%vreg15 GR64:%vreg14 but remember to (at the end of isel) replace vreg7 by vreg15. Now for the bug. In fast isel lowering, we mistakenly mark vreg8 as the result of the load instead of the trunc. This adds a fixup to have vreg8 replaced by whatever the result of the load is as well, so we end up with %vreg15 =3D AND8ri %vreg15, 1, %EFLAGS; = GR8:%vreg15 which is an SSA violation and causes problems later down the road. This fixes PR21557. Test Plan: Test test case from PR21557 is added to the test suite. Reviewers: ributzka Reviewed By: ributzka Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6245 This fixes a possible assertion failure when compiling toolbox.cxx from LibreOffice 4.3.5. Reported by:=09kwm ------------------------------------------ [...truncated 269935 lines...] =3D=3D=3D> hpt27xx (all) --- all_subdir_geom --- ctfconvert -L VERSION -g pkcs5v2.o --- g_eli.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_hpt27xx --- --- hpt27xx_lib.o --- uudecode -p < > hpt27xx_lib.o --- all_subdir_drm2 --- --- radeon_cp.o --- ctfconvert -L VERSION -g radeon_cp.o --- psopinfo.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-e= rror-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ= ality -Wno-error-unused-function -Wno-error-pointer-sign -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-unknown-pragmas -W= no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses= -equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mn= o-avx -std=3Diso9899:1999 -Werror --- modules-all --- --- all_subdir_hpt27xx --- --- hpt27xx_os_bsd.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_drm2 --- --- radeon_irq.o --- ctfconvert -L VERSION -g radeon_irq.o --- radeon_mem.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdi= nc -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -= fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-= asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf= -2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parent= heses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -W= redundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex= tensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pr= agmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa= rentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mn= o-aes -mno-avx -std=3Diso9899:1999 -c --- psopinfo.o --- ctfconvert -L VERSION -g psopinfo.o --- modules-all --- --- radeon_state.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdi= nc -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -= fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-= asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf= -2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parent= heses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -W= redundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex= tensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pr= agmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa= rentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mn= o-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_geom --- ctfconvert -L VERSION -g g_eli.o --- g_eli_integrity.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_hpt27xx --- ctfconvert -L VERSION -g hpt27xx_os_bsd.o --- hpt27xx_osm_bsd.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_drm2 --- --- radeon_mem.o --- ctfconvert -L VERSION -g radeon_mem.o --- psparse.o --- cc -c -O2 -pipe -fno-strict-aliasing -g -Wall -Wredundant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-inclu= de-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautolo= gical-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-e= rror-unused-function -Wno-error-pointer-sign -nostdinc -I. -I -I -I -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inc= lude opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mc= model=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchron= ous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-e= rror-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ= ality -Wno-error-unused-function -Wno-error-pointer-sign -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-unknown-pragmas -W= no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses= -equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mn= o-avx -std=3Diso9899:1999 -Werror --- modules-all --- --- all_subdir_geom --- ctfconvert -L VERSION -g g_eli_integrity.o --- g_eli_privacy.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- psparse.o --- ctfconvert -L VERSION -g psparse.o --- modules-all --- --- all_subdir_drm2 --- --- r300_cmdbuf.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdi= nc -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -= fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-= asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf= -2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parent= heses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -W= redundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex= tensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pr= agmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa= rentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mn= o-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_geom --- ctfconvert -L VERSION -g g_eli_privacy.o --- geom_eli.ko.debug --- ld -d -warn-common -r -d -o geom_eli.ko.debug g_eli.o g_eli_crypto.o g_eli_= ctl.o g_eli_integrity.o g_eli_key.o g_eli_key_cache.o g_eli_privacy.o pkcs5= v2.o ctfmerge -L VERSION -g -o geom_eli.ko.debug g_eli.o g_eli_crypto.o g_eli_ct= l.o g_eli_integrity.o g_eli_key.o g_eli_key_cache.o g_eli_privacy.o pkcs5v2= .o :> export_syms awk -f geom_eli.ko.debug export_syms | xargs -J% objcopy % geom_eli.ko.debug --- geom_eli.ko.symbols --- objcopy --only-keep-debug geom_eli.ko.debug geom_eli.ko.symbols --- geom_eli.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dgeom_eli.ko.symbols geom_eli.ko= .debug geom_eli.ko =3D=3D=3D> geom/geom_gate (all) --- g_gate.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_hpt27xx --- ctfconvert -L VERSION -g hpt27xx_osm_bsd.o --- hpt27xx_config.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c ctfconvert -L VERSION -g hpt27xx_config.o --- hpt27xx.ko.debug --- ld -d -warn-common -r -d -o hpt27xx.ko.debug hpt27xx_lib.o hpt27xx_os_bsd.o= hpt27xx_osm_bsd.o hpt27xx_config.o ctfmerge -L VERSION -g -o hpt27xx.ko.debug hpt27xx_lib.o hpt27xx_os_bsd.o h= pt27xx_osm_bsd.o hpt27xx_config.o :> export_syms awk -f hpt27xx.ko.debug export_syms | xargs -J% objcopy % hpt27xx.ko.debug --- hpt27xx.ko.symbols --- objcopy --only-keep-debug hpt27xx.ko.debug hpt27xx.ko.symbols --- hpt27xx.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dhpt27xx.ko.symbols hpt27xx.ko.d= ebug hpt27xx.ko --- all_subdir_hptiop --- =3D=3D=3D> hptiop (all) --- hptiop.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_geom --- ctfconvert -L VERSION -g g_gate.o --- geom_gate.ko.debug --- ld -d -warn-common -r -d -o geom_gate.ko.debug g_gate.o ctfmerge -L VERSION -g -o geom_gate.ko.debug g_gate.o :> export_syms awk -f geom_gate.ko.debug export_syms | xargs -J% objcopy % geom_gate.ko.deb= ug --- geom_gate.ko.symbols --- objcopy --only-keep-debug geom_gate.ko.debug geom_gate.ko.symbols --- geom_gate.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dgeom_gate.ko.symbols geom_gate.= ko.debug geom_gate.ko =3D=3D=3D> geom/geom_journal (all) --- g_journal.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_drm2 --- ctfconvert -L VERSION -g r300_cmdbuf.o --- all_subdir_hptmv --- =3D=3D=3D> hptmv (all) --- hptmvraid.o --- uudecode -p < > hptmvraid.o --- mv.o --- cc -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADER= S -include -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-p= ointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -mso= ft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-pr= otector -gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -W= no-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointe= r-sign -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss= ing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-s= ign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body= -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-po= inter-sign -mno-aes -mno-avx -std=3Diso9899:1999 -c ctfconvert -L VERSION -g mv.o --- ioctl.o --- cc -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADER= S -include -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-p= ointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -mso= ft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-pr= otector -gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -W= no-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointe= r-sign -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss= ing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-s= ign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body= -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-po= inter-sign -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_drm2 --- --- radeon_state.o --- ctfconvert -L VERSION -g radeon_state.o --- r600_blit.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdi= nc -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -= fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-= asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf= -2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parent= heses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -W= redundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex= tensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pr= agmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa= rentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mn= o-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_hptmv --- ctfconvert -L VERSION -g ioctl.o --- hptproc.o --- cc -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADER= S -include -I. -I -I -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-p= ointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -mso= ft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-pr= otector -gdwarf-2 -Wno-error-tautological-compare -Wno-error-empty-body -W= no-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointe= r-sign -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmiss= ing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-s= ign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body= -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-po= inter-sign -mno-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_hptiop --- ctfconvert -L VERSION -g hptiop.o --- hptiop.ko.debug --- ld -d -warn-common -r -d -o hptiop.ko.debug hptiop.o ctfmerge -L VERSION -g -o hptiop.ko.debug hptiop.o :> export_syms awk -f hptiop.ko.debug export_syms | xargs -J% objcopy % hptiop.ko.debug --- hptiop.ko.symbols --- objcopy --only-keep-debug hptiop.ko.debug hptiop.ko.symbols --- hptiop.ko --- objcopy --strip-debug --add-gnu-debuglink=3Dhptiop.ko.symbols hptiop.ko.deb= ug hptiop.ko --- all_subdir_geom --- --- g_journal_ufs.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c ctfconvert -L VERSION -g g_journal_ufs.o --- all_subdir_hptmv --- Cannot emit physreg copy instruction UNREACHABLE executed at :3176! --- all_subdir_hptnr --- --- all_subdir_hptmv --- Stack dump: 0.=09Program arguments: -cc1 -triple x86_64-unknown-freebsd11= .0 -emit-obj -mrelax-all -disable-free -main-file-name hptproc.c -mrelocati= on-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -mcod= e-model kernel -target-cpu x86-64 -target-feature -mmx -target-feature -sse= -target-feature -aes -target-feature -avx -disable-red-zone -no-implicit-f= loat -gdwarf-2 -dwarf-column-info -coverage-file -nostdsysteminc -nobuiltininc -res= ource-dir -include -D= _KERNEL -D KLD_MODULE -D HAVE_KERNEL_OPTION_HEADERS -I . -I -I -I -isysroot -Werror -Wno-= error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ= ality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -Wredundant-= decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -Wmissing-include-dirs = -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body = -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-point= er-sign -std=3Diso9899:1999 -fdebug-compilation-dir -ferror-limit 19 -fmessage-length 0 -ffre= estanding -fformat-extensions -fwrapv -stack-protector 1 -mstackrealign -fo= bjc-runtime=3Dgnustep -fno-common -fdiagnostics-show-option -o hptproc.o -x= c =20 1.=09 parser at end of file 2.=09Code generation 3.=09Running pass 'Function Pass Manager' on module ' --- all_subdir_hptnr --- =3D=3D=3D> hptnr (all) --- all_subdir_hptmv --- 4.=09Running pass 'Post-RA pseudo instruction expansion pass' on function '= @hpt_proc_in' --- all_subdir_drm2 --- ctfconvert -L VERSION -g r600_blit.o --- all_subdir_hptnr --- --- hptnr_lib.o --- uudecode -p < > hptnr_lib.o --- all_subdir_drm2 --- --- r600_blit_shaders.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdi= nc -I -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -= fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-= asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf= -2 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parent= heses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wall -W= redundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex= tensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pr= agmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-pa= rentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mn= o-aes -mno-avx -std=3Diso9899:1999 -c --- all_subdir_hptmv --- cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invoc= ation) FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 Target: x86_64-unknown-freebsd11.0 Thread model: posix cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebs= d.org/submit/ and include the crash backtrace, preprocessed source, and ass= ociated run script. --- all_subdir_hptnr --- --- hptnr_os_bsd.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdin= c -DHAVE_KERNEL_OPTION_HEADERS -include -I. -I -I -fno-common -g -fno-omit-frame= -pointer -mno-omit-leaf-frame-pointer -I -mcmodel=3Dkernel -mno-= red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -f= freestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-error-tautological-co= mpare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unu= sed-function -Wno-error-pointer-sign -Wall -Wredundant-decls -Wnested-exte= rns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wca= st-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-d= irs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautologica= l-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error= -unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=3Diso989= 9:1999 -c --- all_subdir_geom --- --- g_journal.o --- ctfconvert -L VERSION -g g_journal.o --- geom_journal.ko.debug --- ld -d -warn-common -r -d -o geom_journal.ko.debug g_journal.o g_journal_ufs= .o --- all_subdir_hptmv --- cc: note: diagnostic msg:=20 ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/hptproc-997e1f.c cc: note: diagnostic msg: /tmp/hptproc-997e1f.sh cc: note: diagnostic msg:=20 ******************** *** [hptproc.o] Error code 254 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_hptmv] Error code 2 make[3]: stopped in --- all_subdir_geom --- ctfmerge -L VERSION -g -o geom_journal.ko.debug g_journal.o g_journal_ufs.o :> export_syms awk -f geom_journal.ko.debug export_syms | xargs -J% objcopy % geom_journal.= ko.debug A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_geom] Error code 2 make[3]: stopped in --- all_subdir_drm2 --- ctfconvert -L VERSION -g r600_blit_shaders.o A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_drm2] Error code 2 make[3]: stopped in --- all_subdir_hptnr --- ctfconvert -L VERSION -g hptnr_os_bsd.o A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_hptnr] Error code 2 make[3]: stopped in 4 errors make[3]: stopped in *** [modules-all] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [buildkernel] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildkernel] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 18:03:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61B777C0 for ; Sat, 7 Feb 2015 18:03:22 +0000 (UTC) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 8640367D for ; Sat, 7 Feb 2015 18:03:20 +0000 (UTC) Received: (qmail 52848 invoked by uid 89); 7 Feb 2015 17:56:38 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@88.217.180.225) by mail.grem.de with ESMTPA; 7 Feb 2015 17:56:38 -0000 Date: Sat, 7 Feb 2015 18:56:31 +0100 From: Michael Gmelin To: "freebsd-current@freebsd.org" Subject: Call for testers, change BIOS memory detection Message-ID: <20150207185631.5766c2e9@bsd64.grem.de> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Adrian Chadd 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, 07 Feb 2015 18:03:22 -0000 The patch to CURRENT below is an extended version of a patch originally done by Adrian and accomplishes the following: * Add a quirks table based on BIOS vendor / maker / product (NULL matches any), making use of the new smbios_match function * pass in an smap+acpi entry size for e820; like what biossmap.c does; * don't blindly believe e820 if it doesn't give us enough memory to successfully load things, but ONLY if the machine is listed as BQ_DISTRUST_E820_EXTMEM in the quirks table (in this patch this is only the Acer C720 aka Peppy, since it was the reason to write this patch). There are probably other models out there with these issues, but without data it's probably best to add them one at a time. * don't blindly concat cx/dx with e801 - ensure that cx indicates there's no hole and there's a full 15mb of ram before concat'ing; * truncate how much RAM we probe for via e801 (which adrian doesn't entirely think is needed) * if we use e801, don't use the heap as-is; use the end of bios_extmem instead as if we didn't get anything from E820; * add a boot loader command "biosmem" which give details about how memory was detected The code has already been reviewed and more details can be found here: https://reviews.freebsd.org/D1741 It would be great, if a few more people could take a look at this and test it before it's committed to HEAD. Thanks, Michael Index: sys/boot/i386/libi386/biosmem.c =================================================================== diff --git a/head/sys/boot/i386/libi386/biosmem.c b/head/sys/boot/i386/libi386/biosmem.c --- a/head/sys/boot/i386/libi386/biosmem.c (revision 277957) +++ b/head/sys/boot/i386/libi386/biosmem.c (working copy) @@ -32,6 +32,7 @@ */ #include #include +#include "bootstrap.h" #include "libi386.h" #include "btxv86.h" @@ -38,13 +39,56 @@ vm_offset_t memtop, memtop_copyin, high_heap_base; uint32_t bios_basemem, bios_extmem, high_heap_size; -static struct bios_smap smap; +static struct bios_smap_xattr smap; /* + * Used to track which method was used to set BIOS memory + * regions. + */ +static uint8_t b_bios_probed; +#define B_BASEMEM_E820 0x1 +#define B_BASEMEM_12 0x2 +#define B_EXTMEM_E820 0x4 +#define B_EXTMEM_E801 0x8 +#define B_EXTMEM_8800 0x10 + +/* * The minimum amount of memory to reserve in bios_extmem for the heap. */ #define HEAP_MIN (3 * 1024 * 1024) +/* + * Products in this list need quirks to detect + * memory correctly. You need both maker and product as + * reported by smbios. + */ +#define BQ_DISTRUST_E820_EXTMEM 0x1 /* e820 might not return useful + extended memory */ +struct bios_getmem_quirks { + const char* bios_vendor; + const char* maker; + const char* product; + int quirk; +}; + +static struct bios_getmem_quirks quirks[] = { + {"coreboot", "Acer", "Peppy", BQ_DISTRUST_E820_EXTMEM}, + {NULL, NULL, NULL, 0} +}; + +static int +bios_getquirks(void) +{ + int i; + + for (i=0; quirks[i].quirk != 0; ++i) + if (smbios_match(quirks[i].bios_vendor, quirks[i].maker, + quirks[i].product)) + return (quirks[i].quirk); + + return (0); +} + void bios_getmem(void) { @@ -56,7 +100,7 @@ v86.ctl = V86_FLAGS; v86.addr = 0x15; /* int 0x15 function 0xe820*/ v86.eax = 0xe820; - v86.ecx = sizeof(struct bios_smap); + v86.ecx = sizeof(struct bios_smap_xattr); v86.edx = SMAP_SIG; v86.es = VTOPSEG(&smap); v86.edi = VTOPOFF(&smap); @@ -65,11 +109,17 @@ break; /* look for a low-memory segment that's large enough */ if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0) && - (smap.length >= (512 * 1024))) + (smap.length >= (512 * 1024))) { bios_basemem = smap.length; + b_bios_probed |= B_BASEMEM_E820; + } /* look for the first segment in 'extended' memory */ - if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0x100000)) { + /* we need it to be at least 32MiB or -HEAD won't load */ + if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0x100000) && + (smap.length >= (32 * 1024 * 1024) || + !(bios_getquirks() & BQ_DISTRUST_E820_EXTMEM))) { bios_extmem = smap.length; + b_bios_probed |= B_EXTMEM_E820; } /* @@ -100,6 +150,7 @@ v86int(); bios_basemem = (v86.eax & 0xffff) * 1024; + b_bios_probed |= B_BASEMEM_12; } /* Fall back through several compatibility functions for extended memory */ @@ -109,7 +160,29 @@ v86.eax = 0xe801; v86int(); if (!(V86_CY(v86.efl))) { - bios_extmem = ((v86.ecx & 0xffff) + ((v86.edx & 0xffff) * 64)) * 1024; + /* + * Clear high_heap; it may end up overlapping + * with the segment we're determining here. + * Let the default "steal stuff from top of + * bios_extmem" code below pick up on it. + */ + high_heap_size = 0; + high_heap_base = 0; + /* + * cx is the number of 1KiB blocks between 1..16MiB. + * It can only be up to 0x3c00; if it's smaller then + * there's a PC AT memory hole so we can't treat + * it as contiguous. + */ + bios_extmem = (v86.ecx & 0xffff) * 1024; + if (bios_extmem == (1024 * 0x3c00)) + bios_extmem += (v86.edx & 0xffff) * 64 * 1024; + + /* truncate bios_extmem */ + if (bios_extmem > 0x3ff00000) + bios_extmem = 0x3ff00000; + + b_bios_probed |= B_EXTMEM_E801; } } if (bios_extmem == 0) { @@ -118,6 +191,7 @@ v86.eax = 0x8800; v86int(); bios_extmem = (v86.eax & 0xffff) * 1024; + b_bios_probed |= B_EXTMEM_8800; } /* Set memtop to actual top of memory */ @@ -132,4 +206,36 @@ high_heap_size = HEAP_MIN; high_heap_base = memtop - HEAP_MIN; } -} +} + +static int +command_biosmem(int argc, char *argv[]) +{ + int bq = bios_getquirks(); + + printf("bios_basemem: 0x%llx\n", (unsigned long long) bios_basemem); + printf("bios_extmem: 0x%llx\n", (unsigned long long) bios_extmem); + printf("memtop: 0x%llx\n", (unsigned long long) memtop); + printf("high_heap_base: 0x%llx\n", (unsigned long long) high_heap_base); + printf("high_heap_size: 0x%llx\n", (unsigned long long) high_heap_size); + printf("bios_quirks: 0x%02x", bq); + if (bq & BQ_DISTRUST_E820_EXTMEM) + printf(" BQ_DISTRUST_E820_EXTMEM"); + printf("\n"); + printf("b_bios_probed: 0x%02x", (int) b_bios_probed); + if (b_bios_probed & B_BASEMEM_E820) + printf(" B_BASEMEM_E820"); + if (b_bios_probed & B_BASEMEM_12) + printf(" B_BASEMEM_12"); + if (b_bios_probed & B_EXTMEM_E820) + printf(" B_EXTMEM_E820"); + if (b_bios_probed & B_EXTMEM_E801) + printf(" B_EXTMEM_E801"); + if (b_bios_probed & B_EXTMEM_8800) + printf(" B_EXTMEM_8800"); + printf("\n"); + + return (CMD_OK); +} + +COMMAND_SET(smap, "biosmem", "show BIOS memory setup", command_biosmem); -- Michael Gmelin From owner-freebsd-current@FreeBSD.ORG Sat Feb 7 19:43:31 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45D414A6; Sat, 7 Feb 2015 19:43:31 +0000 (UTC) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1ED88EF1; Sat, 7 Feb 2015 19:43:30 +0000 (UTC) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 8086441500; Sat, 7 Feb 2015 19:43:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1423338204; bh=1AUENVkdw8m6n/DufS68kOssV2NWyq28/kpKZ3fMzO0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=MfYZWHAErlK20QkFtM/iBf+MoBP3R8mWzoCkW3lJ0cb5AomlRn9sSoZ30/l1Xf9+3 D1AofJR8Jz0LI/qnfEhriJJiFOHMcxHtqTZqLpEwBEA636st4/dlXzRKnpe+1j/slv yXxLw2cvJaDrqzNifq5exJdwcAs6WDrpDnOfBAsY= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: pkubaj) with ESMTPSA id 6B62A40052 Message-ID: <54D66AD5.9070301@riseup.net> Date: Sat, 07 Feb 2015 20:43:17 +0100 From: Piotr Kubaj User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Sam Fourman Jr." , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: UEFI boot doesn't work on 10.1-RELEASE/11.0-CURRENT References: <54D3C673.70205@riseup.net> <54D3E1B1.6040701@riseup.net> <392DFE0A-C1D2-4674-8B85-202050D0157D@me.com> <283D8F90-9EB1-4B69-A501-88DF907A674E@me.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.5 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Sat, 07 Feb 2015 21:38:45 +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: Sat, 07 Feb 2015 19:43:31 -0000 On 02/06/2015 07:04, Sam Fourman Jr. wrote: > > > On Thu, Feb 5, 2015 at 9:02 PM, Rui Paulo > wrote: > > On Feb 5, 2015, at 18:29, Sam Fourman Jr. > wrote: > > > >> Can you tell us which version of CURRENT you tried? > >> > >> I tried, r278209 on my lenovo B570, then very early in the boot process it > > locks up and stops. > > If it stops in boot1, then it's because it couldn't find the UFS > partition with loader.efi. Did you test the memstick or your own > installation? > > it was memstick > > -- > Rui Paulo > > > > > > > -- > > Sam Fourman Jr. Hi again, it seems the problem was caused by setting CPUTYPE in make.conf. On Haswell CPU's it breakes /boot/loader.efi.