From owner-freebsd-stable@freebsd.org Sun Jul 10 01:19:12 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4027AB837B9 for ; Sun, 10 Jul 2016 01:19:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 E73F7115F for ; Sun, 10 Jul 2016 01:19:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22629 invoked from network); 10 Jul 2016 01:19:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Jul 2016 01:19:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 09 Jul 2016 21:19:04 -0400 (EDT) Received: (qmail 4456 invoked from network); 10 Jul 2016 01:19:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Jul 2016 01:19:04 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 5D7F11C4394; Sat, 9 Jul 2016 18:18:43 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format Date: Sat, 9 Jul 2016 18:19:07 -0700 Message-Id: Cc: FreeBSD Toolchain To: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 01:19:12 -0000 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953 > > > Bug ID: 210953 > Summary: 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to > build: dev/ahci/ahci.c:288:22: error: unknown > conversion type character 'b' in format; too many > arguments for format > Product: Base System > Version: 11.0-BETA1 > Hardware: ppc > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: bin > Assignee: > freebsd-bugs at FreeBSD.org > > Reporter: > markmi at dsl-only.net > > > --- all_subdir_ahci --- > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_attach': > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:288:22: error: unknown > conversion type character 'b' in format [-Werror=format=] > device_printf(dev, "quirks=0x%b\n", ctlr->quirks, > ^ > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:288:22: error: too many > arguments for format [-Werror=format-extra-args] I omit the other supporting material. === Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sun Jul 10 02:30:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE072B854E4 for ; Sun, 10 Jul 2016 02:30:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 6F611198D for ; Sun, 10 Jul 2016 02:30:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24300 invoked from network); 10 Jul 2016 02:30:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Jul 2016 02:30:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 09 Jul 2016 22:30:06 -0400 (EDT) Received: (qmail 16186 invoked from network); 10 Jul 2016 02:30:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Jul 2016 02:30:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 098411C405F; Sat, 9 Jul 2016 19:29:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format From: Mark Millard In-Reply-To: Date: Sat, 9 Jul 2016 19:29:59 -0700 Cc: FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 02:30:03 -0000 [Top post of probable "already fixed" status.] It looks like -r320441 on stable/11 reverted a kern.mk change = controlling what formats are (un)available for some compilers. I'm rebuilding things based on -r302457 instead of -r302412 and will = close the defect if things work. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jul-9, at 6:19 PM, Mark Millard wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210953 >=20 >=20 > Bug ID: 210953 > Summary: 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to > build: dev/ahci/ahci.c:288:22: error: unknown > conversion type character 'b' in format; too many > arguments for format > Product: Base System > Version: 11.0-BETA1 > Hardware: ppc > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: bin > Assignee:=20 > freebsd-bugs at FreeBSD.org >=20 > Reporter:=20 > markmi at dsl-only.net >=20 >=20 > --- all_subdir_ahci --- > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function = 'ahci_attach': > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:288:22: error: unknown > conversion type character 'b' in format [-Werror=3Dformat=3D] > device_printf(dev, "quirks=3D0x%b\n", ctlr->quirks, > ^ > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:288:22: error: too = many > arguments for format [-Werror=3Dformat-extra-args] I omit the other supporting material. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sun Jul 10 04:43:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCB83B84617; Sun, 10 Jul 2016 04:43:40 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B547C1844; Sun, 10 Jul 2016 04:43:40 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 6D0E215AA; Sun, 10 Jul 2016 04:43:40 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Sun, 10 Jul 2016 04:43:38 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Cc: re@FreeBSD.org Subject: FreeBSD 11.0-BETA1 Now Available Message-ID: <20160710044338.GI43678@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 04:43:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The first BETA build of the 11.0-BETA1 release cycle is now available. Installation images are available for: o 11.0-BETA1 amd64 GENERIC o 11.0-BETA1 i386 GENERIC o 11.0-BETA1 powerpc GENERIC o 11.0-BETA1 powerpc64 GENERIC64 o 11.0-BETA1 sparc64 GENERIC o 11.0-BETA1 armv6 BANANAPI o 11.0-BETA1 armv6 BEAGLEBONE o 11.0-BETA1 armv6 CUBIEBOARD o 11.0-BETA1 armv6 CUBIEBOARD2 o 11.0-BETA1 armv6 CUBOX-HUMMINGBOARD o 11.0-BETA1 armv6 GUMSTIX o 11.0-BETA1 armv6 RPI-B o 11.0-BETA1 armv6 RPI2 o 11.0-BETA1 armv6 PANDABOARD o 11.0-BETA1 armv6 WANDBOARD o 11.0-BETA1 aarch64 GENERIC Installer images and memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/11" branch. A list of changes since 10.0-RELEASE are available on the 11-CURRENT release notes: https://www.freebsd.org/relnotes/CURRENT/relnotes/article.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 11.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-BETA1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. The file can be found here, for now, until various patches are available upstream: http://people.FreeBSD.org/~gjb/QEMU_EFI.fd The checksums for this file are: SHA256 (QEMU_EFI.fd) = a35335a418781fc0963c80ab12d548b6972d2c0b955f45664a4b780f4e5f48a2 MD5 (QEMU_EFI.fd) = ec03d51a3c4374a515cf32ab0c2721cf To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-fdf87eea us-west-1 region: ami-092b6d69 us-west-2 region: ami-3c82415c sa-east-1 region: ami-b0ea7edc eu-west-1 region: ami-eda5c29e eu-central-1 region: ami-e407ed8b ap-northeast-1 region: ami-57cc3136 ap-northeast-2 region: ami-67a06a09 ap-southeast-1 region: ami-a12ef3c2 ap-southeast-2 region: ami-3cb19a5f === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-BETA1 % vagrant up === Upgrading === Note to freebsd-update(8) consumers: A last-minute issue was discovered which causes the freebsd-update(8) utility to refuse to upgrade the system. The cause and solution are being investigated, and we hope to have it resolved before 11.0-BETA2. Our apologies for the inconvenience. == ISO CHECKSUMS == o 11.0-BETA1 amd64 GENERIC: SHA512 (FreeBSD-11.0-BETA1-amd64-bootonly.iso) = 8b0ed0056dd8d1d8a5d70635e0e986c6e8d9cd455428909d0feb46589bf64c2295963f7ab7d67516e6bef7d54de566214229e502d5c0607e5c42a040fb2942b2 SHA512 (FreeBSD-11.0-BETA1-amd64-bootonly.iso.xz) = c0df232985b8f77d3d61c724406aabe5c76e40d720beadcef634302228cb41efbe123f67e0e50ae798aedf3f2af7ee2c8bae1b2f3d8078978e71345cf0c935d2 SHA512 (FreeBSD-11.0-BETA1-amd64-disc1.iso) = 0eef19895e14f2cb7f74c8975f0372becced17c2f81f51dfdd29f6c77a35e7679d8da94c150bc61dfc38df704156e6aaaa58c1ef162db0022082a2b0c9465835 SHA512 (FreeBSD-11.0-BETA1-amd64-disc1.iso.xz) = c4e3b6e16bb5e0c6eda321cdab0e30eb9922277c917c0aac016bd7ed88c56fb47d73ee6dfe7532848f9fb0fe57a81dcd96f87790921c7330d07034e16e2a9194 SHA512 (FreeBSD-11.0-BETA1-amd64-dvd1.iso) = 935864146456461c7c152f0e161c7ed0eb79c6aa55296c373cf2062f2b950fa8688ebef80e40f3609af8e38446b1c5d72cee68d7ed39fa03e8eb9fb007b477c4 SHA512 (FreeBSD-11.0-BETA1-amd64-dvd1.iso.xz) = 702e598e30e5e68bfdf7e8ac62002552dff0c9644b0343dd921b26afb2473a978c487b5f4aa11378b94b2c67ecd5df2a54478799ea9773b2c727c19b7ef3bd1c SHA512 (FreeBSD-11.0-BETA1-amd64-memstick.img) = 5147587109a07a8965cbd2adde796aebc19d77a64a64da17641f751311e1f067b1466c66e5947b4f4c63ecac5f96a458cfee9e06586cb351b58789053554ac74 SHA512 (FreeBSD-11.0-BETA1-amd64-memstick.img.xz) = 71536d55654ee440b0853a589cd96d1eb5dc84e0206ccca15c3a33e8f04d5c5bb90c613a5984e6c4f93b76edc9d1e56ef0b81c22ce6013d8901506ffec258da7 SHA512 (FreeBSD-11.0-BETA1-amd64-mini-memstick.img) = ec84823e6f84903c6085a6e287ed96909df570a067e765c49b5aa5dfac8aaa55d1b0441a30eba1ae87e235304a2dc1d4698740cbd588730e41ea3fa245918d24 SHA512 (FreeBSD-11.0-BETA1-amd64-mini-memstick.img.xz) = b03d2f26552ea6715b882620f7b30739fc5c0c39fdc8aeea03eb219b42fdfbdb881f327a0ca06904608f6abec866d4978995afade27dda8f1c11ef27235907bb SHA256 (FreeBSD-11.0-BETA1-amd64-bootonly.iso) = 644bd5a9e86072021e0ae8104d3292828e80aea8f2d240c62152e317c76a0863 SHA256 (FreeBSD-11.0-BETA1-amd64-bootonly.iso.xz) = 86e7aff3ca39102c0ea87120a0d3d038c796da7e693984f002eee7cae483454d SHA256 (FreeBSD-11.0-BETA1-amd64-disc1.iso) = f5612ae83832a3627d99df383ed3e75ca4d978dcae10c25b03179593f46ade4b SHA256 (FreeBSD-11.0-BETA1-amd64-disc1.iso.xz) = 3655753eb41ef33b4a8cdeb1ad8c71e84de44c54d23361624bef251fa41f0a93 SHA256 (FreeBSD-11.0-BETA1-amd64-dvd1.iso) = f8a484ec477c967546048e76c7f3fe3d34996ead477ab0e7f3e1f0a22a1f2e73 SHA256 (FreeBSD-11.0-BETA1-amd64-dvd1.iso.xz) = 9d1acb4c3424d73c0ae2592a749c79624ff1b19c736cf598b44430a89f65c2d8 SHA256 (FreeBSD-11.0-BETA1-amd64-memstick.img) = e3ee413597141d11557daabdc5fa343ba82f1799e8037449f45b9f7baadc44d0 SHA256 (FreeBSD-11.0-BETA1-amd64-memstick.img.xz) = fbb17784dff310d60d6a9500da60cf147e9f28c1201784c267cc2cda33cee28f SHA256 (FreeBSD-11.0-BETA1-amd64-mini-memstick.img) = 5ea8243f69241fee439aadf1cbca3028dcf764e080e3242dbe1c46e0b9030622 SHA256 (FreeBSD-11.0-BETA1-amd64-mini-memstick.img.xz) = 07d62369e042ec6fafa69f72ce047051cdc9914f254b2fe724b243fe9eb6c0db o 11.0-BETA1 i386 GENERIC: SHA512 (FreeBSD-11.0-BETA1-i386-bootonly.iso) = 8330217dd5a18de91b8cb60092dd609b078337f23804932795efeee60fa460ad25a59f046fab8ac1c93cd1399be5bafdd64fc192a8af239d86cc174d7011e77d SHA512 (FreeBSD-11.0-BETA1-i386-bootonly.iso.xz) = 26748d2718b1966b903d66aa44738a80311005cae166e4786aa48ad45de664bb7dbe78f569f6bc9cfb16e0acd656fce8b7af8013813d27ef615ef6d8ce77de6e SHA512 (FreeBSD-11.0-BETA1-i386-disc1.iso) = 7cf0f0f1a347d9f84ece53809e08a286a90bc422f18113e74cf54a46f0c7b144060803b8abf0f98e3f800e600bfc0262e29218b7d531ee3e6b2f2a2c4d0e362c SHA512 (FreeBSD-11.0-BETA1-i386-disc1.iso.xz) = 147e929a9f5d90c5c26d066bbb5326c13120edc00d057ca889d4329ab44d8f1d8347aa08d818d0cbbf04d9a295df11f6c59139713d3f6e834f0443b72ef47abb SHA512 (FreeBSD-11.0-BETA1-i386-dvd1.iso) = 10f187bc18d3a9ab85d9cbcf665e595c67326050ba478f71aea1dc9e47ee2d55b99bc7fb56daecef09e75e2c2fb740678e4225ff91939c0b16aa65b7296aa242 SHA512 (FreeBSD-11.0-BETA1-i386-dvd1.iso.xz) = e21f9403929d9e952ea5a334cf03e7b699e2078635f9d76b92681a592b70db143ebea26c4c0d05625cfcf6bc12c1da0aa509fa981b32ba326a8344f6b4c587c2 SHA512 (FreeBSD-11.0-BETA1-i386-memstick.img) = 130c75136767aae6cc0fd562853d0c7e5965e77e2055533d6ffe47bc1de59d5bdf1be0aacb7f2b9987710eaaf6dc1b3e03b165575f3bdc59f2d41f5bf5161159 SHA512 (FreeBSD-11.0-BETA1-i386-memstick.img.xz) = bfac919c6e91ed0fa802c72b300e75aab953fe342a26b9bff51be07243181e8dc56234922ac90e34a33d7148dd39113a283bcab8a6bd65f33c8a351f93b934a2 SHA512 (FreeBSD-11.0-BETA1-i386-mini-memstick.img) = f32149a9d658fa983af7b09f7b96d25cd526b21f03efaad6cab491f870285670341e98de50ea78fef96621eb2c3754d8aba0d4df5f8f3b0e1ae45ec2f4173bbf SHA512 (FreeBSD-11.0-BETA1-i386-mini-memstick.img.xz) = 0a3aa5c97023b5f7d1e5c49ad51d6d9bf05db445f93936c3597f842e8cdfe333da614781cb2adb01df3904e9b49bebaea52d7475ee420e63142b9f6b29581616 SHA256 (FreeBSD-11.0-BETA1-i386-bootonly.iso) = 465b2cd98a86650d11c15155c4bc6c44a93411a9521790a031952481e3d35390 SHA256 (FreeBSD-11.0-BETA1-i386-bootonly.iso.xz) = e0f1f22a9d8ff4477755a3533d5803221b927bdbd2dc4140fcef184ba7594ad0 SHA256 (FreeBSD-11.0-BETA1-i386-disc1.iso) = d28a539663b94f1c088fb4f1c6c635fc909c133c84ecddb54df938fd99f562c7 SHA256 (FreeBSD-11.0-BETA1-i386-disc1.iso.xz) = 0a9965a6bddf86b1b44115115e806667597b788085a63596bf780601e90f7278 SHA256 (FreeBSD-11.0-BETA1-i386-dvd1.iso) = 6472d4799ff72e994bcf2e5eeebf3debdc4eec61b7ca0ee98c7f3c4608834120 SHA256 (FreeBSD-11.0-BETA1-i386-dvd1.iso.xz) = 4a53c02386b5782df6a1da475006d4f7a4dd815cd70183d981aefb5697cd1328 SHA256 (FreeBSD-11.0-BETA1-i386-memstick.img) = 8927f0e41ab7c4313e8922b9ef44c3e4eeb91cec3b1861b37fd356caffb5c0d4 SHA256 (FreeBSD-11.0-BETA1-i386-memstick.img.xz) = cc016ce034cabae4dcbfe7bae6cdb2089c0b72899a0b018491beb43c01d2b6fe SHA256 (FreeBSD-11.0-BETA1-i386-mini-memstick.img) = 12792ebd36ef19017500f20ea39b1b040cdf3a8710c7c9af29ff2ef8d85b91ef SHA256 (FreeBSD-11.0-BETA1-i386-mini-memstick.img.xz) = 29aca523cb4be880dc55e46325bf5c972233e18267cb9bf52b2a799069286f2d o 11.0-BETA1 powerpc GENERIC: SHA512 (FreeBSD-11.0-BETA1-powerpc-bootonly.iso) = febb5568b74ed7d1067f7dac11424bbb302733b678b0f60dc35d396b21fbddcbe84f03e0a3c5d99fcf86ba461c1624082ff1105e2ea467d6e93ed06bbd34a5f7 SHA512 (FreeBSD-11.0-BETA1-powerpc-bootonly.iso.xz) = 1312129ec1ded71d12bdc8ccf8f7242bb6de22f8c7fd398d31d68bef514310f1e882e562063af69add930f59ca08e38bd4059d3f73876a77c357c633003edfd9 SHA512 (FreeBSD-11.0-BETA1-powerpc-disc1.iso) = 9329c9e428ba110b9e0b04f48a198c1e21006139575a311cdfd3c8c881a05a0eb05103b3863be414a0c9a025d4b1bd0a1064127ff3859387ce8839de2c9165af SHA512 (FreeBSD-11.0-BETA1-powerpc-disc1.iso.xz) = c3926d9b3a63b8ad08bf39132258a1c9bd3eaa506bf70878c447139b61df068d0506d1880f30e04400b9570dc26a653562a9ddd5982a84cd9d2b9271862ef92d SHA512 (FreeBSD-11.0-BETA1-powerpc-memstick.img) = 9157d47bf76fc37a7e4697c0c561e7c5cae6dcb9fb9d7645620d8807eacf623b0b54fb924b3ce6e0c6e6a1570d8cc9771a3dbd0baf5542f686ce49b4300faddb SHA512 (FreeBSD-11.0-BETA1-powerpc-memstick.img.xz) = f2f6dd44855a0d64011a335d29fe0483d90cb14cb752105a8fd02f897f74bd481c1a3da73a964525b5412bcbfd6b7fbc8c06183a30651b2f7ed847421d9e34ae SHA512 (FreeBSD-11.0-BETA1-powerpc-mini-memstick.img) = 86d40dccca21bb617c6c253a981a6fbe86b97d70d122b88f09b1481b70d567b2d997994fc68c76f12532392d89d4bbdcf305e0444212961046fe45ab60f4a04d SHA512 (FreeBSD-11.0-BETA1-powerpc-mini-memstick.img.xz) = bd3bd1ca07b3a87d222533712676760d72559702b0e7da2fb87f59751c917d58b2e6683c71c523898c6f5cc49db18cc8a164d12b4a263528d3e279bb74c0d0e5 SHA256 (FreeBSD-11.0-BETA1-powerpc-bootonly.iso) = 3822d725cf3e110658cd18602fba5aae7562cf3e93ac920c44cbbd07f3ae18c6 SHA256 (FreeBSD-11.0-BETA1-powerpc-bootonly.iso.xz) = 6628ac30f5c221081ce94ff017264770859da70d16d6fb09d6cbd5962342e528 SHA256 (FreeBSD-11.0-BETA1-powerpc-disc1.iso) = 16e9d188800c1fc2dea17a0d08be0aef289fdef25c00b1a73477a091ffe1b431 SHA256 (FreeBSD-11.0-BETA1-powerpc-disc1.iso.xz) = 26949d11f7a2249b10045921173005b45647f584bf6b3b77cd1dc444728e47bf SHA256 (FreeBSD-11.0-BETA1-powerpc-memstick.img) = c7a0e67b8d99f56b633eb1220736c8b53afd2683ea876b451a490f69fc028cd7 SHA256 (FreeBSD-11.0-BETA1-powerpc-memstick.img.xz) = 8714a077343b5428331167a306a8c9e2282bab33980affa8619c743bc29cccde SHA256 (FreeBSD-11.0-BETA1-powerpc-mini-memstick.img) = b2dd7a210a2bf64d5c36d2add30d31ead22cfc4d111ffce96d69e99193496ab3 SHA256 (FreeBSD-11.0-BETA1-powerpc-mini-memstick.img.xz) = 4256ac5836afa33c408d7f9275f3e1c4443edf00e760bf4e6b6f74a5dcd0edfd o 11.0-BETA1 powerpc64 GENERIC64: SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-bootonly.iso) = 85977d579208e5a7f5247542260b462c68958c404f2e09d3c7f3ddaf4a9e26c55d479748d256ee1ec31d4c13f2eb53e590119f54cbfcba52071002177ddf060b SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-bootonly.iso.xz) = b82cd3292a0f1a51e5651262d3af42aa6e823da50e4e60b069499d40088dd9ec60567e40738fe2ec0af357bca7a1404fdd7210bfce951c7aa7434899747dd662 SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-disc1.iso) = 3f1d414ccebb39c65b15fc569b370ed1d92a90b18da5ed9b669cdb36fe27bf4fc57ad5f1d9fa956b8dc8e9bf9eef2edd7280cd0e081480cf0904afa5e5fcff59 SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-disc1.iso.xz) = af35a498d70e3421e913a1190f5099bb6feb3c41f7e49978986b3415a30970eb5100c95448ad9f00fe8c5900ab469f8d3ae91ebefa6d8c35f498d7dcd3697fe9 SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-memstick.img) = 4f32996a3a2c06a9a41d493e743a53fb805962adbe8243ff96ccf545acf81072faee8a7569e081ed010bb19e1835f8842977d71d09f8bfc58f605364e9cb7191 SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-memstick.img.xz) = 8bec5849202cecc432879c987b6f28713c54f2f1258ff1119fd1883d56579f0da10447f84ba53cb8ca9ef2b770c51e424eac8a1b855215ea3358729bde01530d SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-mini-memstick.img) = b0c2e41ed3e2186d7020bbee530af15e75daf1c676f048d4c9b28139c3393407a1c6413f582ff2404b7bd0d476b387f204214aa1fb71689fa7e4ec48911a4855 SHA512 (FreeBSD-11.0-BETA1-powerpc-powerpc64-mini-memstick.img.xz) = 29b3751f1cff842e3797a8bd33279c43546856d51a6af08cec185ec9a65464d6be4b01fb2369994b96f697289bdb37ffc08cab6863d71b16a41979a1b43f6810 SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-bootonly.iso) = e44304c938ee0a28ff286c637e5a4c49dde4f4df60f018e3214000faecbcbfb5 SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-bootonly.iso.xz) = 110282baff285ea7417ea6e9a72a64d90671845e12fd2d90b02706d796d8b554 SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-disc1.iso) = ca18f87b5691a437242f411a06728c1135ad610db7f249c26cf4f4662dddb04e SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-disc1.iso.xz) = 96337bfbfc34b10601cb41cf3fa8f6212656677461871f64134b2a9eb85ff42b SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-memstick.img) = 26c3f282f3cf7bfff6972e40820e7bf47a7284e75d8f67df073bcb287c17527a SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-memstick.img.xz) = eae17f25df65d8da6049330427bbff4c4d4ba9d9b785dcb4e937507da5c2a9d5 SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-mini-memstick.img) = eddbbedbeb016a50d968f572fa2b5a88bb5ac2da86a4c3440c656dc516d2084c SHA256 (FreeBSD-11.0-BETA1-powerpc-powerpc64-mini-memstick.img.xz) = 41f8a631313514ee31319d951aeebcf5fc4f5ffe9c071743e9914b2b97985a37 o 11.0-BETA1 sparc64 GENERIC: SHA512 (FreeBSD-11.0-BETA1-sparc64-bootonly.iso) = 83e090fec7dcab172be5c0d4730ed8b81579be996f1c89965f70ebbf5264360a644aadca64f31af3d6510073b96e0539afdcb7a068ea23451b46685517c9161d SHA512 (FreeBSD-11.0-BETA1-sparc64-bootonly.iso.xz) = 4ce31bf1614e716e11c56fcdf5e50f3ebd97b147aaabde85de1db24e36d7eaec6f24c8ac28682ada8c18e92fe10b1527a8304430759b9062e2476eee8bdef42b SHA512 (FreeBSD-11.0-BETA1-sparc64-disc1.iso) = fae95f01a27e470804a5638959015ef9d550195b32e38d76d71211a0a236dc60bdc92cbfacf9fcc0cf9adf8b92878c305789f6a9accbd5205f07d3ea5c2f4e26 SHA512 (FreeBSD-11.0-BETA1-sparc64-disc1.iso.xz) = eef5d1f0c0ae816facca0c6f830f862b4225b01e393267599594225a99fb77fe1694cc294445c1eb16d47b5e444ea927e1cf4ee106445fd75c2a35fff98b3da9 SHA256 (FreeBSD-11.0-BETA1-sparc64-bootonly.iso) = 169a56a0c751169c1fb326e077d8a98a3aed86703f53a5f0cbcdfb0cf97dd639 SHA256 (FreeBSD-11.0-BETA1-sparc64-bootonly.iso.xz) = 7d4a5819e5305bf84cd1250c487fece933a99b40dac450fd821b5c7ed8224be7 SHA256 (FreeBSD-11.0-BETA1-sparc64-disc1.iso) = 5062a9f6b5f6fb81f97db97211285ece84432e7180652268efc213247f1f662d SHA256 (FreeBSD-11.0-BETA1-sparc64-disc1.iso.xz) = 61e22a5de52add32a96cdd8fe7988caa276f01ffea5b39fbc9570bcee6d5b329 o 11.0-BETA1 armv6 BANANAPI: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-BANANAPI.img.xz) = d66d350a7d3d4dddf4c72609e5c53b369677996067594066576ef70d9cad82d8daa6cd3ccee5fae43584008db532e411396afe1fe4a6d5b69c49c2baae49d519 SHA256 (FreeBSD-11.0-BETA1-arm-armv6-BANANAPI.img.xz) = a5900fddc93b6b8f703fccf962af31d4ca7fab6bd03560e57031ce3051b94380 o 11.0-BETA1 armv6 BEAGLEBONE: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-BEAGLEBONE.img.xz) = 6939e926b286104693435ad1cf9a38d011c599478067a9b265a1cc7dbeb642c2adcd60503296141e67ced8fd8e7e20894d989070fef12c216d1a4b123a3e3c3d SHA256 (FreeBSD-11.0-BETA1-arm-armv6-BEAGLEBONE.img.xz) = b45e3144de069a5f66ab8fc0847792caba06c6eb27d3352b7d752ecef366b59b o 11.0-BETA1 armv6 CUBIEBOARD: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-CUBIEBOARD.img.xz) = bc254a3b9c3dfbe83a6917960dca90f3b8619680186a8846a8b2f57dff68b59de2ddf45296baeb5c915a9c4aef52ddcd6275ce4bd2f111967559e29792a16a4b SHA256 (FreeBSD-11.0-BETA1-arm-armv6-CUBIEBOARD.img.xz) = 9a15f48f38529748e424a83e1510d53c29fb7609c384d3414443d1258f185b93 o 11.0-BETA1 armv6 CUBIEBOARD2: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-CUBIEBOARD2.img.xz) = a3fd0ef94b4e4becb971dbb2093ff2514094a51e6738a582165f9edecb217c627aac96acafdfe9f4c29e0ba95b3c6aa80c7c31bfd7d8d06fb3d3105d801646e4 SHA256 (FreeBSD-11.0-BETA1-arm-armv6-CUBIEBOARD2.img.xz) = 8c2ae19f973ae30e2f1af2327d53f7683ccce144bb868899216e6456fcd814b1 o 11.0-BETA1 armv6 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = 18693bb047e37e3a6399ce2ce55c156d5624b1fedd4711ccfd8a5c79dc4b93d724339ba4fa7623d9d56c4090d8e9364f6ae67916b3db015c9aea5869beab27da SHA256 (FreeBSD-11.0-BETA1-arm-armv6-CUBOX-HUMMINGBOARD.img.xz) = ad13a384d2d0981a2c7468a333125ab3222dd506c8d6a014e69264d928880efe o 11.0-BETA1 armv6 GUMSTIX: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-GUMSTIX.img.xz) = bb0d2b8dd2093d00377069039139bb3701c1d43593a0b1a19f4d9a910f2f3dcd7045400f30d4a537a7e2a3659f0488ba01a82f81950971122beea705a9075809 SHA256 (FreeBSD-11.0-BETA1-arm-armv6-GUMSTIX.img.xz) = 93d3c59f49f4bf619acd12c6a3906510313530bf1bb9c017a1dfa2b82b11aef2 o 11.0-BETA1 armv6 RPI-B: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-RPI-B.img.xz) = fc9bf54bc599ae313ccc7b8f3f772c8c5e598cb6364ea5173c91194a3eb3486642fb25019221020701c9a2f59c99db52e890e3a8656352f91d8966e56ba958c7 SHA256 (FreeBSD-11.0-BETA1-arm-armv6-RPI-B.img.xz) = 79ec71d62c07032d87d74cb1f7b5c1f8443c7ec79583e72772697e8997dca1a0 o 11.0-BETA1 armv6 RPI2: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-RPI2.img.xz) = f84f1786f58a31aaddf0f6595e4eeba9bef5e9f5d5dc9ab099ea173d7813faaf1b693e9a68fb6d4661502aed1793314ef59db41c41f4a84c7dedcd7b6083eb8b SHA256 (FreeBSD-11.0-BETA1-arm-armv6-RPI2.img.xz) = 015c7763c19aa17a9b4537ea9448e24f6bb2b1da911fca5f222eb0f300c3aa98 o 11.0-BETA1 armv6 PANDABOARD: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-PANDABOARD.img.xz) = 7ad3e265a707a544bb245b265b40e57f06226a70d38c01b1e364e5093dcb62d08ed091f736a9693e759f71f530de8b2eedffb53b23e3db888f5867195af4d918 SHA256 (FreeBSD-11.0-BETA1-arm-armv6-PANDABOARD.img.xz) = 078dbaf8c500b77508a665e8d617927a2722269b01e8a9420a7112153c3083ff o 11.0-BETA1 armv6 WANDBOARD: SHA512 (FreeBSD-11.0-BETA1-arm-armv6-WANDBOARD.img.xz) = 9026665dab5562260ee9df98ac39b6adf5b0e3d9865da6c93d99a6ebed88c310399587ab353c8fe3d9545e26c8f614a26fc3509c76bce52ed405f537d8db3bf2 SHA256 (FreeBSD-11.0-BETA1-arm-armv6-WANDBOARD.img.xz) = cb4592ce1f00106a65ab99a2b9ef0ecf0566108eab41f2d67090ec46fab93bf3 o 11.0-BETA1 aarch64 GENERIC: SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64-memstick.img) = 72aaa33030881d0733d283cdded9a93ce9676c0bf6b496dc351cdf158314539eb5e3d62704ce1e4bce677ca8a4121dd6ce603a30430de46eae51fc0ba793000a SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64-memstick.img.xz) = 7f5f67ee6f0edf72dbba4b6a51e8f07c6ac6c1fd88891a5622a4aad07f0bb387df4ad16d74e03cf5de8f2b72bfbdd1decaddda6a42076b43d02e4a3d3256f504 SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64-mini-memstick.img) = e647d1be5d7a7c42c2c2a60b2c4f69b8129d3e4f1942d094000ff292138b2b338d42589dba4cdc9879e82c7b82bc0d24e41a0722e7e111eb6bcf301cbcb806ff SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64-mini-memstick.img.xz) = 77a665a7b0a73baa4a6f5595d5cd27133a91153c2dc7ffcff88ebd3b9bbf48541e558e63b08133a291c3b835fd8ce1fe470c2b28d507613c164d0879f3586271 SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64-memstick.img) = b8ae988e401aa677812c3e7661b6d242cb361622a3bdcb84abd4e67dcd2d63c1 SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64-memstick.img.xz) = b5e902e4be6d23ac4203c453b0d8727162cac7c1853557573cda5f16f1bc473f SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64-mini-memstick.img) = 57baa182d6125ee055f508509a790d06c2b35fe35ef3d72098943ea0343d857b SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64-mini-memstick.img.xz) = 076e27472af1847933065301ccfa9435071e98cfd423acf3ec3f1bb6ee179cc0 == VM IMAGE CHECKSUMS == o 11.0-BETA1 amd64: SHA512 (FreeBSD-11.0-BETA1-amd64.qcow2.xz) = 490487e7e5bb77a893ffb120c61bb88c24b47762c0c025476f627c89d2363f61549d00abd43beee92577d6fcb23916e23b25bc485f2bcdb4e40cd8308793f86a SHA512 (FreeBSD-11.0-BETA1-amd64.raw.xz) = 07771c9050829f0e8c8dd319ce62928498fc3ff4b648033dab9a0bf6f1c5a795d6097e1c414c00f997b265464c0467d3c59a4a1389645fc138fdfccbe902b395 SHA512 (FreeBSD-11.0-BETA1-amd64.vhd.xz) = ade93a1535eb640b927b33b50e933a6e97c5f8888c3726432d3035d590cf1ed7f3fadd789e314b00acf49641c9928313aaa2dd300339a241ec2ac8601a229438 SHA512 (FreeBSD-11.0-BETA1-amd64.vmdk.xz) = 798234299c3582f99d8db40f270c71e2b0fb478097320ec437cc744164adc89119d45be3bb59dff9dfb6ae796c5db4fc36bec4d9261fc8550d7a18e4eb928cd4 SHA256 (FreeBSD-11.0-BETA1-amd64.qcow2.xz) = e7825b87eba4d87203b54cdb7e4087965e14d176694d815f86b11fd19553acee SHA256 (FreeBSD-11.0-BETA1-amd64.raw.xz) = 45dfef99953f4bfa18f625539f9aeb404558996c50873d4a33c0cf04ff39c6b9 SHA256 (FreeBSD-11.0-BETA1-amd64.vhd.xz) = 4835a19f6ef6847901575bb7e69aeb1012bd1917627a8a0fb3c015188c711edc SHA256 (FreeBSD-11.0-BETA1-amd64.vmdk.xz) = 401865ca14de8ef501e2c5205b95e357569c0fbcab03927d02c12f9179944ce0 o 11.0-BETA1 i386: SHA512 (FreeBSD-11.0-BETA1-i386.qcow2.xz) = 9bbb3b1bfced776ffeb6bbd5b01f39b8bfcd9c9ed5845fb8aec0a9ba90ae2c497ac17d75f891c8258cd9924ac8536e2fbd9d95ceb7e7f4311fba4b4c084df398 SHA512 (FreeBSD-11.0-BETA1-i386.raw.xz) = 84ea2f2dfecd488adb989b99bcf7ed9962d6a30d291a93ea64b3bba0717d9d4a865ce227e2ebb869826f64386a6de5fc86a1ce56a38f52fd4c6aea5d2c9e7c26 SHA512 (FreeBSD-11.0-BETA1-i386.vhd.xz) = 3dda4e40681d950616661ea104ceefc0239fa31f0faa372278e896300f9fd3d336c796630b5ed78ace266e6a98edba6b2e5f446c5768603dfa22fc326587690a SHA512 (FreeBSD-11.0-BETA1-i386.vmdk.xz) = 6852126469738ca407310c14e52234a409609e19a43f7b01ebba65da4ddf0626b6f64d44eb700d1ed8aeaebe87e8a8efbe8a1ae1a008b2c61158d0d182f07200 SHA256 (FreeBSD-11.0-BETA1-i386.qcow2.xz) = 22294efa97c2b56e861e63b1979534afa9c4466bb63e084890465926f9174e80 SHA256 (FreeBSD-11.0-BETA1-i386.raw.xz) = c9939f43a35f4050364b88f9e931fe7966d548a0265a700d97b799e9ecec7124 SHA256 (FreeBSD-11.0-BETA1-i386.vhd.xz) = f7339205247e034ffa389f3410ce9cc214e385bae7fbdbb2682c838144aafffe SHA256 (FreeBSD-11.0-BETA1-i386.vmdk.xz) = 01e15d2da3879e5fb1e8e303f1407afe53a285f98768ca4caee3f6eecf5c5294 o 11.0-BETA1 aarch64: SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64.qcow2.xz) = be2c9150fba527bf0e9915601114dca62785089724894ace9e7baa040a6101573d9d6e7b287173af65a8a9c28b7dfb0894134b8f80118e4695b064801d64c9b8 SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64.raw.xz) = ec88d3652131cfd7e8ee1e0161709f72fa0b9d45ddde287ec9590611b57d1987870b37f243de5d45be74f804fd505b849d84c86049d03c4ad218f705f0c71f75 SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64.vhd.xz) = b13ce4825669f622e6383a263e05425980da93a6594264db5b734e5a10c156e348449fc1b712212224b373433be0039cc498cc5c1143e62453b69f0a76139709 SHA512 (FreeBSD-11.0-BETA1-arm64-aarch64.vmdk.xz) = 76db133703e9e1808cb06f5f62f01f676ad645da80563c9198343ea52a290184b1c23af00fd98f577f4db43a39a084add4ad635fe3fdd67d3cb1bccc9c6771c2 SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64.qcow2.xz) = 5c4ce60c94fe08dfeff1047137db3cd0a53b345d4e2991507abaab23ea47b100 SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64.raw.xz) = 9101550cd9b29fc367dba9bcf5cb2c14b86a2ea73c64b8b150e111b9b5e4b9af SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64.vhd.xz) = cd59c243a251239fa1a5fc9719c2487ba9541207d7d7821f0c6647a489e8b205 SHA256 (FreeBSD-11.0-BETA1-arm64-aarch64.vmdk.xz) = bf33739cdd277270f5a864ef09da3476342bf6cc2ee2caad0d87f7a1503fa5e9 Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgdJ6AAoJEAMUWKVHj+KTBQYP/RPeZmKeo/jnYsMABJvQmRLV qaiwTcO/QNfWDBo2zB7Mfwped4aj1ZlX6BWx0gabyvWGXpslZ2f/gTKwuZ7YUyDk BANs3+A8gd0QfhFOcGuCPOs5loJvs5rsYFHJ1/da77v+np1KAWNx3Do+vhAqbGEh Bs2I5OG4KOmss0CxeilPSM0i6/Y30jLGGa2NlE66St7CiALvZb7WQ/Py3x2zzasx zQ3cWwEFRirURGxUrpDuDdfBY5hJ5Wu8M6MLlefiFFwD4/QG7uYtmGwVB4tOuxy+ 8+ksV+x/YjP5joNqcnHdPbTK80LjCXOzB2Qtgk7v4CCtWO8+jnWqrUuEraKwPqvc 37E/YY0vxEQd1Wcl2JPiL+6k2hO6Ql8+ABmeloGld0T3d9E7Wm8+t+rZD28l3OkB sNWg7nMthAcwjpdw0IPEdJUxv9RfonhuChZW8oLytiYjpDUoPc/y3H7nhaUqEBhZ wbc3TWNwSdcUEKzYgjPnmJ8TI14JWrpI6mmY6T6yWyTUe4HEO+O0+KY9MXASULCB 54V8hrxEcXo4yn+DbKGg3rOvepcG0NCg7jIoT6Y9HlilMM0Ah9vbSpidKX7r+i3w tRaTcJClqmtBtNtdzyYbpVB3qk+nsEdaWXeQvcyU2dOYvUPrsPQ7EC3OwV0jmFb4 4keB7i1guENoBKjdSb0C =oD4g -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Sun Jul 10 06:03:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA6F6B8308A for ; Sun, 10 Jul 2016 06:03:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 86EF91658 for ; Sun, 10 Jul 2016 06:03:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31680 invoked from network); 10 Jul 2016 06:03:16 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Jul 2016 06:03:16 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 10 Jul 2016 02:03:27 -0400 (EDT) Received: (qmail 4567 invoked from network); 10 Jul 2016 06:03:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Jul 2016 06:03:26 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 6D2D71C43CA; Sat, 9 Jul 2016 23:02:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format From: Mark Millard In-Reply-To: <8E57EB70-814D-4849-8E56-95A769AA40D3@gmail.com> Date: Sat, 9 Jul 2016 23:03:19 -0700 Cc: freebsd-bugs@FreeBSD.org, FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E57EB70-814D-4849-8E56-95A769AA40D3@gmail.com> To: Ngie Cooper X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 06:03:24 -0000 On 2016-Jul-9, at 8:53 PM, Ngie Cooper wrote: >> On Jul 9, 2016, at 18:52, bugzilla-noreply@freebsd.org wrote: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210953 >>=20 >> Mark Millard changed: >=20 > I accidentally committed this regression to kern.mk. I don't have = bugzilla login right now. Please assign the bug to me and I'll mark it = fixed for the rev I did it in with head and stable/10. >=20 > Thanks! > -Ngie So far as I know I've no control over the Assignee field for any bug via = bugzilla. Someone that has such can do what Ngie requested and assign = 210953 to him. A rebuild based on -r302457 completed fine for the powerpc64-gcc use, = confirming Ngie's note, at least for 11.0-STABLE. I've no stable/10 context and so have not tested there. Otherwise I = might have just classified the report as "Overcome By Events" myself. I have added a comment to 210953 about my rebuild test and Ngie's = material above. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Sun Jul 10 07:59:22 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD630B852FF for ; Sun, 10 Jul 2016 07:59:22 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id AFB091C8A; Sun, 10 Jul 2016 07:59:22 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F4172133; Sun, 10 Jul 2016 07:59:22 +0000 (UTC) Date: Sun, 10 Jul 2016 07:59:22 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <62698937.11.1468018652840.JavaMail.jenkins@jenkins-9.freebsd.org> References: <62698937.11.1468018652840.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #302 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 07:59:22 -0000 See From owner-freebsd-stable@freebsd.org Sun Jul 10 10:30:43 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6299B84525 for ; Sun, 10 Jul 2016 10:30:43 +0000 (UTC) (envelope-from jshevland@calm-horizons.net) Received: from relay.ox.registrar-servers.com (relay.ox.registrar-servers.com [199.188.203.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.registrar-servers.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 852821DDF for ; Sun, 10 Jul 2016 10:30:43 +0000 (UTC) (envelope-from jshevland@calm-horizons.net) Received: from MTA-06-3.privateemail.com (mta-06-3.privateemail.com [198.54.127.59]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay.ox.registrar-servers.com (Postfix) with ESMTPS id BEFCAB00AB for ; Sun, 10 Jul 2016 06:30:35 -0400 (EDT) Received: from [10.10.10.2] (unknown [10.20.151.233]) by MTA-06.privateemail.com (Postfix) with ESMTPA id 5F26E60030 for ; Sun, 10 Jul 2016 10:30:27 +0000 (UTC) Subject: Re: Jenkins build is still unstable: FreeBSD_stable_10 #302 To: freebsd-stable@FreeBSD.org References: <62698937.11.1468018652840.JavaMail.jenkins@jenkins-9.freebsd.org> <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> From: Joe Shevland Message-ID: <49883f29-9ee1-d8c4-85c1-4d18a1ea8416@calm-horizons.net> Date: Sun, 10 Jul 2016 20:30:09 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 10:30:43 -0000 I'm wondering if it's my build process where I'm seeing issues. I have been tracking -stable on a spare machine lately, and I've had about 60% success rate on a full build world/kernel etc. (following UPDATING instructions) on the times I do it. Been a few foot-shooting moments, but those aside, still what look to be a few just broken builds. Typically to resolve this, I'd just 'svnlite -up' in /usr/src, and rebuild, and it works fine (this little Atom/Shuttle doesn't compile things too quickly, so that's a window of 6 hours at least). Normally, I'm used to a gated commit system i.e. you commit changes, the change/s in question compiles successfully (with any other changes that have been committed by others), and only then those changes are promoted to another branch or tag (where they should compile w/o problems). Is that what happens, or am I doing things wrong? I follow that little chunk down the bottom of UPDATING normally to do a full world/kernel build. Cheers, Joe On 10/07/2016 5:59 PM, jenkins-admin@FreeBSD.org wrote: > See > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sun Jul 10 11:18:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34E1DB85683 for ; Sun, 10 Jul 2016 11:18:02 +0000 (UTC) (envelope-from jshevland@calm-horizons.net) Received: from relay.ox.registrar-servers.com (relay.ox.registrar-servers.com [199.188.203.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.registrar-servers.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 138B21AAA for ; Sun, 10 Jul 2016 11:18:01 +0000 (UTC) (envelope-from jshevland@calm-horizons.net) Received: from MTA-08-3.privateemail.com (mta-08-3.privateemail.com [198.54.127.61]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay.ox.registrar-servers.com (Postfix) with ESMTPS id E2CA5B00AD for ; Sun, 10 Jul 2016 07:17:59 -0400 (EDT) Received: from [10.10.10.2] (unknown [10.20.151.209]) by MTA-08.privateemail.com (Postfix) with ESMTPA id 4D71760033 for ; Sun, 10 Jul 2016 11:17:52 +0000 (UTC) Subject: Re: Jenkins build is still unstable: FreeBSD_stable_10 #302 To: freebsd-stable@FreeBSD.org References: <62698937.11.1468018652840.JavaMail.jenkins@jenkins-9.freebsd.org> <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> <49883f29-9ee1-d8c4-85c1-4d18a1ea8416@calm-horizons.net> From: Joe Shevland Message-ID: <4902c651-0f1b-23ec-02c1-7911f27b5986@calm-horizons.net> Date: Sun, 10 Jul 2016 21:17:34 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <49883f29-9ee1-d8c4-85c1-4d18a1ea8416@calm-horizons.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 11:18:02 -0000 (My foot-shooting moments have involved LibreSSL and tomcat-native. I've removed them since). On 10/07/2016 8:30 PM, Joe Shevland wrote: > I'm wondering if it's my build process where I'm seeing issues. I have > been tracking -stable on a spare machine lately, and I've had about > 60% success rate on a full build world/kernel etc. (following UPDATING > instructions) on the times I do it. Been a few foot-shooting moments, > but those aside, still what look to be a few just broken builds. > > Typically to resolve this, I'd just 'svnlite -up' in /usr/src, and > rebuild, and it works fine (this little Atom/Shuttle doesn't compile > things too quickly, so that's a window of 6 hours at least). > > Normally, I'm used to a gated commit system i.e. you commit changes, > the change/s in question compiles successfully (with any other changes > that have been committed by others), and only then those changes are > promoted to another branch or tag (where they should compile w/o > problems). > > Is that what happens, or am I doing things wrong? I follow that little > chunk down the bottom of UPDATING normally to do a full world/kernel > build. > > Cheers, > Joe > > > > On 10/07/2016 5:59 PM, jenkins-admin@FreeBSD.org wrote: >> See >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Sun Jul 10 11:28:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 264E9B85A26 for ; Sun, 10 Jul 2016 11:28:10 +0000 (UTC) (envelope-from jshevland@calm-horizons.net) Received: from relay.ox.registrar-servers.com (relay.ox.registrar-servers.com [199.188.203.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.registrar-servers.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 054D51F97 for ; Sun, 10 Jul 2016 11:28:09 +0000 (UTC) (envelope-from jshevland@calm-horizons.net) Received: from MTA-09-3.privateemail.com (mta-09-3.privateemail.com [68.65.122.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay.ox.registrar-servers.com (Postfix) with ESMTPS id D0448B00B0 for ; Sun, 10 Jul 2016 07:28:08 -0400 (EDT) Received: from [10.10.10.2] (unknown [10.20.151.237]) by MTA-09.privateemail.com (Postfix) with ESMTPA id 3EA3660034 for ; Sun, 10 Jul 2016 11:27:59 +0000 (UTC) Subject: Re: Jenkins build is still unstable: FreeBSD_stable_10 #302 To: freebsd-stable@FreeBSD.org References: <62698937.11.1468018652840.JavaMail.jenkins@jenkins-9.freebsd.org> <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> <49883f29-9ee1-d8c4-85c1-4d18a1ea8416@calm-horizons.net> <4902c651-0f1b-23ec-02c1-7911f27b5986@calm-horizons.net> From: Joe Shevland Message-ID: <0c9f51a7-1dea-a746-66a1-76a594fa566c@calm-horizons.net> Date: Sun, 10 Jul 2016 21:27:41 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <4902c651-0f1b-23ec-02c1-7911f27b5986@calm-horizons.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 11:28:10 -0000 Small qualifier, I have had trouble with that. But not since, my build issues have been without that. https://www.youtube.com/watch?v=I9MZNEXrElw On 10/07/2016 9:17 PM, Joe Shevland wrote: > (My foot-shooting moments have involved LibreSSL and tomcat-native. > I've removed them since). > > On 10/07/2016 8:30 PM, Joe Shevland wrote: >> I'm wondering if it's my build process where I'm seeing issues. I >> have been tracking -stable on a spare machine lately, and I've had >> about 60% success rate on a full build world/kernel etc. (following >> UPDATING instructions) on the times I do it. Been a few foot-shooting >> moments, but those aside, still what look to be a few just broken >> builds. >> >> Typically to resolve this, I'd just 'svnlite -up' in /usr/src, and >> rebuild, and it works fine (this little Atom/Shuttle doesn't compile >> things too quickly, so that's a window of 6 hours at least). >> >> Normally, I'm used to a gated commit system i.e. you commit changes, >> the change/s in question compiles successfully (with any other >> changes that have been committed by others), and only then those >> changes are promoted to another branch or tag (where they should >> compile w/o problems). >> >> Is that what happens, or am I doing things wrong? I follow that >> little chunk down the bottom of UPDATING normally to do a full >> world/kernel build. >> >> Cheers, >> Joe >> >> >> >> On 10/07/2016 5:59 PM, jenkins-admin@FreeBSD.org wrote: >>> See >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sun Jul 10 14:16:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 878E0B8399C for ; Sun, 10 Jul 2016 14:16:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 4FE2D14E9 for ; Sun, 10 Jul 2016 14:16:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bMFXg-000LLk-Ng for freebsd-stable@FreeBSD.org; Sun, 10 Jul 2016 17:17:08 +0300 Date: Sun, 10 Jul 2016 17:17:08 +0300 From: Slawa Olhovchenkov To: freebsd-stable@FreeBSD.org Subject: pkg: dup2(rootfd): Invalid argument Message-ID: <20160710141708.GE20831@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 14:16:59 -0000 I am trying to install xtrabackup on FreeBSD 9.1. pkg enforce to upgrade: ===== Installed packages to be UPGRADED: pkg: 1.5.2 -> 1.8.7 ===== After upgrade pkg will be broken: ===== # pkg install qpress Updating FreeBSD1 repository catalogue... FreeBSD1 repository is up-to-date. All repositories are up-to-date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: qpress: 1.1 Number of packages to be installed: 1 Proceed with this action? [y/N]: y [1/1] Installing qpress-1.1... pkg: dup2(rootfd): Invalid argument [1/1] Extracting qpress-1.1: 0% pkg: Fail to create /usr: Bad file descriptor [1/1] Extracting qpress-1.1: 100% ===== Now I am try to downgrade: ==== # pkg add /var/cache/pkg/pkg-1.5.2.txz Installing pkg-1.5.2... the most recent version of pkg-1.8.7 is already installed # pkg add -f /var/cache/pkg/pkg-1.5.2.txz Installing pkg-1.5.2... package pkg is already installed, forced install pkg: dup2(rootfd): Invalid argument Extracting pkg-1.5.2: 0% pkg: Fail to create /usr: Bad file descriptor Extracting pkg-1.5.2: 100% Failed to install the following 1 package(s): /var/cache/pkg/pkg-1.5.2.txz ==== Nice result. And for pkg-base niced. ==== # mkdir pkg # cd !$ # tar xvf /var/cache/pkg/pkg-1.5.2.txz # ./usr/local/sbin/pkg-static add -f /var/cache/pkg/pkg-1.5.2.txz pkg-static: warning: database version 33 is newer than libpkg(3) version 31, but still compatible Installing pkg-1.5.2... package pkg is already installed, forced install Extracting pkg-1.5.2: 100% Message for pkg-1.5.2: If you are upgrading from the old package format, first run: # pkg2ng ==== This is realy right way?! This is like linux disorder. From owner-freebsd-stable@freebsd.org Sun Jul 10 16:39:26 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FF6CB84525; Sun, 10 Jul 2016 16:39:26 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) 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 3DB271C13; Sun, 10 Jul 2016 16:39:26 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pa0-x234.google.com with SMTP id hu1so14536113pad.3; Sun, 10 Jul 2016 09:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E1+9l8ay1udNeJknuDYDszcFYroISAY/aDDRCjYmBaU=; b=0L1canahkA4B4ROamuVBS/zQkd+AW7WVOArNgC1yH++8srSGvisXFdkLdLNZa0qywy gV6UXH8Dt9XdJuc4CkpeRNLSxpkuyClXARil6SFu7ZKNwHp8poyMruCFFpVLJKwwoAcN G31IRVZwBSRE4lNO4a0YzNZZESFQaVVl8hveUNiliOTC7rJA+hJHEuQcye+rRpzA37J6 w98RHEGlmtY2Gq36A+YzOz+kj21P8Sp7q5kT9NuvMJ/FsoycShEDm/Q3H/Yx+MNy2sXA ldswyA+eHXKV+CSknOUEJTudPeH95/rzsHgm9UttVqo/PbJ8Go0cFYQqfV6laPUIFeHL n0cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E1+9l8ay1udNeJknuDYDszcFYroISAY/aDDRCjYmBaU=; b=gxRWchkP3Rr6wUyWmaUcdOWMO9w3TMVvaQZqBaQbZljz7gyIZOBvc02jTB8pYYbpOj yQIBwdpb/9RZa9B0lcePGvS51Jf2MXZrzGkZiRJhVcKffylhEwrbTNlHsIEACMKaWzrj H+JiQ5d3obXxKkn4GM63KZRJwTiM7lImoYbrQI+3z7n+RBa69P23o0tM3+qq62lZosxX UX4ejW83AILL3jhdg56ejXgBgsODnvyJh91qZooi7TVKPKeJJKbH+aCsJ4kqU3AWX5SY 9iBbaC6Qt2hrAezWmaWHkZ00rd9pMcL8KW08XJ3Pi6YMKAoZQyX61aGC2Me8wpehiKSO pmCw== X-Gm-Message-State: ALyK8tLhy/uWM17oHXO1Njjsi6HharxusXOD5pmrcEfg5dsitIXB9Kx6SIYButCsOOJRtg== X-Received: by 10.67.7.199 with SMTP id de7mr27373442pad.94.1468168765028; Sun, 10 Jul 2016 09:39:25 -0700 (PDT) Received: from [29.138.229.192] ([172.58.40.198]) by smtp.gmail.com with ESMTPSA id 75sm3461394pfy.32.2016.07.10.09.39.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 10 Jul 2016 09:39:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format From: Ngie Cooper X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sun, 10 Jul 2016 09:39:23 -0700 Cc: freebsd-bugs@FreeBSD.org, FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <0F02EEBB-30B4-40C4-876C-FD099802A77E@gmail.com> References: <8E57EB70-814D-4849-8E56-95A769AA40D3@gmail.com> To: Mark Millard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 16:39:26 -0000 > On Jul 9, 2016, at 23:03, Mark Millard wrote: >=20 > On 2016-Jul-9, at 8:53 PM, Ngie Cooper wrote: >=20 >>> On Jul 9, 2016, at 18:52, bugzilla-noreply@freebsd.org wrote: >>>=20 >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210953 >>>=20 >>> Mark Millard changed: >>=20 >> I accidentally committed this regression to kern.mk. I don't have bugzill= a login right now. Please assign the bug to me and I'll mark it fixed for th= e rev I did it in with head and stable/10. >>=20 >> Thanks! >> -Ngie >=20 > So far as I know I've no control over the Assignee field for any bug via b= ugzilla. Someone that has such can do what Ngie requested and assign 210953 t= o him. >=20 > A rebuild based on -r302457 completed fine for the powerpc64-gcc use, conf= irming Ngie's note, at least for 11.0-STABLE. >=20 > I've no stable/10 context and so have not tested there. Otherwise I might h= ave just classified the report as "Overcome By Events" myself. >=20 > I have added a comment to 210953 about my rebuild test and Ngie's material= above. stable/10 was a typo. I meant stable/11. No worries.. I'll take care of it when I get home soon. Thanks! >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 From owner-freebsd-stable@freebsd.org Sun Jul 10 21:29:58 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A668CB83E23 for ; Sun, 10 Jul 2016 21:29:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 6BBE71CDD for ; Sun, 10 Jul 2016 21:29:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17439 invoked from network); 10 Jul 2016 21:30:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Jul 2016 21:30:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 10 Jul 2016 17:30:45 -0400 (EDT) Received: (qmail 19291 invoked from network); 10 Jul 2016 21:30:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Jul 2016 21:30:45 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 22AF21C405F; Sun, 10 Jul 2016 14:29:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: amd64 -> armv6 [and powerpc64] -r302331 -> -r302412 re-cross-build (update): got "sh: ./make_keys: Exec format error" again for init_ketry.h in ncursesw From: Mark Millard In-Reply-To: <0394F424-484D-43B3-9C7D-8C6A8E8709F0@dsl-only.net> Date: Sun, 10 Jul 2016 14:29:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0394F424-484D-43B3-9C7D-8C6A8E8709F0@dsl-only.net> To: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Current , freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 21:29:58 -0000 On 2016-Jul-8, at 12:23 AM, Mark Millard wrote = --but with a few []'d notes added: > [Before the below cross build/update attempt I updated my amd64 from = -r302331 -> -r302412.] >=20 > Summary: It appears that WITHOUT_META_MODE=3D still needs to be forced = for cross compiles at least sometimes in order to avoid "Exec format = error". man src.conf only mentions WITHOUT_META_MODE=3D in one place: >=20 >> WITH_DIRDEPS_BUILD > . . . >> WITH_META_MODE (unless WITHOUT_META_MODE is set = explicitly) > . . . >> This must be set in the environment, make command line, = or >> /etc/src-env.conf, not /etc/src.conf. >=20 >=20 > In attempting to update my cross build (amd64 -> armv6 [or powerpc64]) = from -r302331 to -r302412 it failed with [armv6 example]: >=20 >> --- init_keytry.h --- >> sh: ./make_keys: Exec format error >> *** [init_keytry.h] Error code 126 >>=20 >> make[4]: stopped in /usr/src/lib/ncurses/ncursesw >> .ERROR_TARGET=3D'init_keytry.h' >> = .ERROR_META_FILE=3D'/usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw/= init_keytry.h.meta' >> .MAKE.LEVEL=3D'4' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> .CURDIR=3D'/usr/src/lib/ncurses/ncursesw' >> .MAKE=3D'make' >> .OBJDIR=3D'/usr/obj/clang/arm.armv6/usr/src/lib/ncurses/ncursesw' >> .TARGETS=3D'all' >> DESTDIR=3D'/usr/obj/clang/arm.armv6/usr/src/tmp' >> LD_LIBRARY_PATH=3D'' >> MACHINE=3D'arm' >> MACHINE_ARCH=3D'armv6' >> MAKEOBJDIRPREFIX=3D'/usr/obj/clang/arm.armv6' >> MAKESYSPATH=3D'/usr/src/share/mk' >> MAKE_VERSION=3D'20160606' >> = PATH=3D'/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/clan= g/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/arm.armv6/usr/src/tm= p/legacy/bin:/usr/obj/clang/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/clang/= arm.armv6/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' >> SRCTOP=3D'/usr/src' >> OBJTOP=3D'/usr/obj/clang/arm.armv6/usr/src' >> .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /root/src.configs/make.conf = /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk = /etc/src.conf /usr/src/lib/ncurses/ncursesw/Makefile = /usr/src/lib/ncurses/ncursesw/../ncurses/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/lib/ncurses/ncursesw/../config.mk /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk = /usr/src/lib/ncurses/ncursesw/../Makefile.inc = /usr/src/lib/ncurses/ncursesw/../../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' >> .PATH=3D'. /usr/src/lib/ncurses/ncursesw = /usr/src/lib/ncurses/ncursesw/../ncurses = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/base = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tty = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/widechar = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/trace = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/man' >> 1 error >=20 > again. >=20 > This was based on: >=20 >> # more = ~/sys_build_scripts.amd64-host/make_rpi2_nodebug_clang_bootstrap-amd64-hos= t.sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-= $(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host= " \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/clang" \ >> make $* >=20 > and. . . >=20 >> # more ~/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host=20 >> TO_TYPE=3Darmv6 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >> # >> #CPUTYPE=3Dsoft >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> WITHOUT_LIBSOFT=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> #WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG_FILES=3D >> # >> XCFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >> XCXXFLAGS+=3D -march=3Darmv7-a -mcpu=3Dcortex-a7 >=20 > make.conf was empty. >=20 > The earlier -r302331 cross build had WITH_LIBSOFT=3D in use. -r302412 = is my first testing of WITHOUT_LIBSOFT=3D after rebuilding all ports to = avoid libsoft. [Does not apply to the powerpc64 example.] I should have mentioned the alternative of keeping WITH_META_MODE=3Dyes = but doing a cleanworld before doing a separate buildworld. This is = generally handier if one is to keep using WITH_META_MODE=3Dyes . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Jul 11 00:55:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03E69B84D44 for ; Mon, 11 Jul 2016 00:55:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 C60AA1294 for ; Mon, 11 Jul 2016 00:55:04 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 4E36940643D for ; Sun, 10 Jul 2016 19:55:03 -0500 (CDT) To: freebsd-stable@freebsd.org From: Karl Denninger Subject: Not-so stable if you take a CAM error.... Message-ID: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> Date: Sun, 10 Jul 2016 19:54:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030305070203070503020907" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 00:55:05 -0000 This is a cryptographically signed message in MIME format. --------------ms030305070203070503020907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Got a (nasty) surprise this afternoon on my sandbox machine. I was updating some Raspberry Pi2 machines which involved taking the sd card out, sticking it in an adapter and plugging it into the sandbox, then mounting the partition and using rsync. Unfortunately one of the cards was, unknown to me, bad and returned a write error during the update. The machine panic'd immediately after the CAM write error popped up. I was quite surprised by this, since (1) the SD card was (of course) mounted as a UFS filesystem; it shows up as a CAM device, (2) the machine itself is running off a ZFS root on a normal host-adapter and thus there is no comingling of the buffer cache and (3) there were no images being run from (can't, wrong architecture!) nor any system I/O (e.g. pagefile) going to the SD card. I certainly understand that under some circumstances (maybe even most circumstances) taking a hard I/O error to a system device is going to hose you and a panic() is arguably "least astonishment" when the price of being wrong might be a corrupted system file or worse (e.g. corrupted paged-out RSS, etc.) But I didn't expect a panic out a failed write to a device that is mounted and being used purely for data. I don't have a crash dump but can almost-certainly reproduce this if it's something that shouldn't happen and thus merits investigation. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030305070203070503020907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTEwMDU0MzhaME8GCSqGSIb3DQEJBDFCBEDg hNeXBG8Jy+zcfTFHIA0hRLUJ+aQoX3F9BIr4c0+B3MazFzQylrvg1AdNlUpkhTYX86aN8qFo 6ssBe7YwdUMLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIABoHHcnqn oKhFVdel2KUIy820CRTHryO7orfQNwTa4DDKm/8J4o39KkcQWDlPcolo7Xq/oQT601LDm8TX Ry/MirI/GmCsmSt8e/ct/n451r+YfhLX3x+xzBfLV4Xr09QBvj/SsdVfUhvvKxW+ywQLybfb aCQpyB5K27IPujCxMdpcVpQzijsngc/OiSgQp0la9doju5H6DSHA1Kb9yhX9PvgwdpBm4IpQ /Gtnqa73lhEH96xkFkgCHoHVhhNooUgL9D8K07CCNwJh+ZW5pHN4DmlX/UDfRlCBfxL6yw2p m82GiWFdHdBgrU5fdgqnRhVa+qKcAoXkOUEBeNH9p+nnrHSZipJmBd9D0vSbdpZwVaq8Dpib 1Pv4zwKODsc/WLDdtxBfE1+AUCYR4wPnpp0u4LdveUUr7xvnDJspU5i3bScfUtkvXw5ETSKf gAaXjR3AFuBKyGW5SHEEvMhBJ1yPxjI0iAgq7wHhEQ1DL3YBX43D5o0dQC6aMs2BRjujdOtj gSHIN7sBBOwkAc7WWBi+ZWjev7RLNkVT7rEG3nwaXyP4nIcdFz6OiqbPt7DAd/+bKPoXlmI+ cDwY9YvEI88AWfv4hASez7l4ujIgHRPhxX7UfRXOX8rnfrNGVU2BXkmg2f4ctnlgyBHdIUP0 1IjqZoQGAH0zNd/bnDOY+5uP+nEAAAAAAAA= --------------ms030305070203070503020907-- From owner-freebsd-stable@freebsd.org Mon Jul 11 02:11:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55CEBB8F264 for ; Mon, 11 Jul 2016 02:11:15 +0000 (UTC) (envelope-from office@events-science.info) Received: from events-science.info (events-science.info [46.10.218.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DEC11A78 for ; Mon, 11 Jul 2016 02:11:14 +0000 (UTC) (envelope-from office@events-science.info) dkim-signature: v=1; a=rsa-sha256; d=events-science.info; s=selector; c=relaxed/relaxed; q=dns/txt; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=DWIE4KSjQRz2RZQHuBVq2SssmBYIiRlOcKdxottzJac=; b=R2NIA4Jy+tysXxSpnJgJ+67zU1op6+NnEoiaK7yKBttPjW0LyAtTf3azusDf5rva5JWMWdhXRqWi4koMZQwo0BNWAECRMcXraPfLQgA9+Y0tgiqOFsUbPggwNVqq90QVXHaI4DX1HLaqrEMcNj9ee9K2Vq50P0mHrcTIm0xHPgE= Received: from events-science.info (events-science.info [46.10.218.247]) by events-science.info with ESMTPA ; Mon, 11 Jul 2016 05:11:09 +0300 MIME-Version: 1.0 From: "International Scientific Events" Reply-To: office@events-science.info To: freebsd-stable@freebsd.org Subject: Conference Invitation, Bulgaria 2016 Date: Mon, 11 Jul 2016 05:11:09 +0300 Message-ID: <36203754332321751929674@Athena-PC> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 02:11:15 -0000 Dear Colleague, We have the pleasure of inviting you to participate in conferences, part of= International Scientific Events 2016, to be held in Hotel "Royal Castle", = Elenite on the Bulgarian Black Sea Coast (EU). Economy & Business, 15th International Conference (1-5 September) http://www.sciencebg.net/en/conferences/economy-and-business/ Education, Research & Development, 7th International Conference (4-8 Septem= ber) http://www.sciencebg.net/en/conferences/education-research-and-development/ Language, Individual & Society, 10th International Conference (7-11 Septemb= er) http://www.sciencebg.net/en/conferences/language-individual-and-society/ Annually our events connect scientists and researchers from over 40 countri= es. The papers presented will be published in open-access journals, part of Int= ernational Scientific Publications. Certificate of publication and presentation will be provided. Organized by Bulgarian Academy of Sciences, Union of Scientists in Bulgaria= , Science & Education Foundation and partners. Please note: registration deadline extension applies when registering from = this address. Best regards, International Scientific Events, Bulgaria www.sciencebg.net -- Not interested=3F Visit http://unsubscribe.sciencebg.net/ to unsubscribe. This message is unsolicited commercial communication. From owner-freebsd-stable@freebsd.org Mon Jul 11 07:56:45 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18B31B9073E for ; Mon, 11 Jul 2016 07:56:45 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0ABF71580; Mon, 11 Jul 2016 07:56:45 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 68C75152; Mon, 11 Jul 2016 07:56:45 +0000 (UTC) Date: Mon, 11 Jul 2016 07:56:45 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1154227897.17.1468223805198.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1604686759.16.1468137562842.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #303 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 07:56:45 -0000 See From owner-freebsd-stable@freebsd.org Mon Jul 11 08:12:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC98B910E3 for ; Mon, 11 Jul 2016 08:12:19 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6381011F6 for ; Mon, 11 Jul 2016 08:12:18 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1bMW5S-0000RO-Ho for freebsd-stable@freebsd.org; Mon, 11 Jul 2016 09:57:06 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Not-so stable if you take a CAM error.... References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> Date: Mon, 11 Jul 2016 09:57:05 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: ba572e8a3bde05b4b19613c12a9e49fc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 08:12:19 -0000 On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger wrote: > Got a (nasty) surprise this afternoon on my sandbox machine. > > I was updating some Raspberry Pi2 machines which involved taking the sd > card out, sticking it in an adapter and plugging it into the sandbox, > then mounting the partition and using rsync. > > Unfortunately one of the cards was, unknown to me, bad and returned a > write error during the update. > > The machine panic'd immediately after the CAM write error popped up. > > I was quite surprised by this, since (1) the SD card was (of course) > mounted as a UFS filesystem; it shows up as a CAM device, (2) the > machine itself is running off a ZFS root on a normal host-adapter and > thus there is no comingling of the buffer cache and (3) there were no > images being run from (can't, wrong architecture!) nor any system I/O > (e.g. pagefile) going to the SD card. > > I certainly understand that under some circumstances (maybe even most > circumstances) taking a hard I/O error to a system device is going to > hose you and a panic() is arguably "least astonishment" when the price > of being wrong might be a corrupted system file or worse (e.g. corrupted > paged-out RSS, etc.) But I didn't expect a panic out a failed write to > a device that is mounted and being used purely for data. > > I don't have a crash dump but can almost-certainly reproduce this if > it's something that shouldn't happen and thus merits investigation. > Hi, I understand you are surprised by this. I don't think it is the way it should work. Is there _any_ debugging information for people to use and try to help you? Like which FreeBSD version are you running? Which FreeBSD version was used to create the UFS fs? Does it use softupdates (SU) or also journaling (SU+J)? Maybe some output of dmesg? Or type of SD-card and reader. Other people might have similar problems with similar hardware. Regards, Ronald. From owner-freebsd-stable@freebsd.org Mon Jul 11 10:56:03 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47B24B834DD for ; Mon, 11 Jul 2016 10:56:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 F1BEF1762 for ; Mon, 11 Jul 2016 10:56:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5859 invoked from network); 11 Jul 2016 10:56:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Jul 2016 10:56:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 06:56:06 -0400 (EDT) Received: (qmail 24827 invoked from network); 11 Jul 2016 10:56:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jul 2016 10:56:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 01E101C407E; Mon, 11 Jul 2016 03:55:58 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: stable/11 question: kboot vs. powerpc: only powerpc64? Message-Id: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> Date: Mon, 11 Jul 2016 03:55:59 -0700 To: Nathan Whitehorn , FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 10:56:03 -0000 Is the following something that should be updated something like is = indicated below for 11.0-BETA1? Is kboot powerpc64 specific? # svnlite diff /usr/src/sys/boot/powerpc/Makefile Index: /usr/src/sys/boot/powerpc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) +++ /usr/src/sys/boot/powerpc/Makefile (working copy) @@ -1,5 +1,9 @@ # $FreeBSD$ =20 -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot +SUBDIR=3D boot1.chrp +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +SUBDIR+=3D kboot +.endif +SUBDIR+=3D ofw ps3 uboot =20 .include I ask because I'd submitted 206303 back on 2016-jan-16 reporting that = TARGET_ARCH=3Dpowerpc WITH_BOOT=3D was stopped by getting a = -Wc,-mppc64bride and a -mcpu=3Dpowerpc64 (one of the = base/head/sys/boot/powerpc/kboot/Makefile SRCS being = ppc64_elf_freebsd.c). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Jul 11 10:57:01 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13964B8368F for ; Mon, 11 Jul 2016 10:57:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 060141A80; Mon, 11 Jul 2016 10:57:01 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 7199F156; Mon, 11 Jul 2016 10:57:01 +0000 (UTC) Date: Mon, 11 Jul 2016 10:57:01 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1440611393.18.1468234621318.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1154227897.17.1468223805198.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1154227897.17.1468223805198.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #304 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 10:57:01 -0000 See From owner-freebsd-stable@freebsd.org Mon Jul 11 11:30:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C90FDB8494E for ; Mon, 11 Jul 2016 11:30:41 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 9D07E1CB4 for ; Mon, 11 Jul 2016 11:30:41 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 63B2C407261 for ; Mon, 11 Jul 2016 06:30:32 -0500 (CDT) Subject: Re: Not-so stable if you take a CAM error.... To: freebsd-stable@freebsd.org References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> From: Karl Denninger Message-ID: <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> Date: Mon, 11 Jul 2016 06:30:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060303020901030402080803" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 11:30:41 -0000 This is a cryptographically signed message in MIME format. --------------ms060303020901030402080803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 02:57, Ronald Klop wrote: > On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger > wrote: > >> Got a (nasty) surprise this afternoon on my sandbox machine. >> >> I was updating some Raspberry Pi2 machines which involved taking the s= d >> card out, sticking it in an adapter and plugging it into the sandbox, >> then mounting the partition and using rsync. >> >> Unfortunately one of the cards was, unknown to me, bad and returned a >> write error during the update. >> >> The machine panic'd immediately after the CAM write error popped up. >> >> I was quite surprised by this, since (1) the SD card was (of course) >> mounted as a UFS filesystem; it shows up as a CAM device, (2) the >> machine itself is running off a ZFS root on a normal host-adapter and >> thus there is no comingling of the buffer cache and (3) there were no >> images being run from (can't, wrong architecture!) nor any system I/O >> (e.g. pagefile) going to the SD card. >> >> I certainly understand that under some circumstances (maybe even most >> circumstances) taking a hard I/O error to a system device is going to >> hose you and a panic() is arguably "least astonishment" when the price= >> of being wrong might be a corrupted system file or worse (e.g. corrupt= ed >> paged-out RSS, etc.) But I didn't expect a panic out a failed write t= o >> a device that is mounted and being used purely for data. >> >> I don't have a crash dump but can almost-certainly reproduce this if >> it's something that shouldn't happen and thus merits investigation. >> > > Hi, > > I understand you are surprised by this. I don't think it is the way it > should work. > Is there _any_ debugging information for people to use and try to help > you? Like which FreeBSD version are you running? Which FreeBSD version > was used to create the UFS fs? Does it use softupdates (SU) or also > journaling (SU+J)? > Maybe some output of dmesg? Or type of SD-card and reader. Other > people might have similar problems with similar hardware. > > Regards, > Ronald. > FreeBSD 11.0-BETA1 #0 r302489: Sat Jul 9 10:15:24 CDT 2016 =20 karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP and FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 =20 karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/s= rc/sys/RPI2 Both blew up in the same way when stimulated with same I/O error. The filesystem in question does have softupdates enabled (the RPI images have it turned on by default) but no journaling. It's not card/reader dependent no architecture dependent; when it occurred the first time I stuck the card and reader into one of my Pis and attempted to update it there (thinking that perhaps my sandbox machine's USB port was wonky) and it blew up the Pi2 in the exact same way. This isn't (obviously, given both Intel-style and ARM machines being involved) architecture dependent. It's been a good long while since I took an actual hard I/O error that was 'visible' at the OS level (I've had plenty of disks die on ZFS over last few years but no "double failures" on a mirror or similar, and I on my servers I haven't had a UFS-based system for a while. This definitely looks like some sort of regression in the code; I've run FreeBSD for a hell of a long time and have had plenty of instances where disks have failed without having the machine go out from under me. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060303020901030402080803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExMTMwMDZaME8GCSqGSIb3DQEJBDFCBEB0 OgwSeUrXutPC7pzq5DMn/071IKJpRCJRqcR8g94BCNrB+Adc5Ug6JAHsHzMyVcKxT7gBMCHn FRsrQltpmD4LMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAjZQ/vklQ 9EnK2B0wXuNA0wHMhl2lNFpYRjgTHQFDwhpe/lAkgzrS8CAp1bsPBbZAxeFWOt9TM9u/mB5O vFQ4fPERKDg2lB3utERCzzGz0K4fPwVgAbqveglmlGsHvBD8HVcuOsFhyPUeytOVFrhkzRJ/ 9D+nPQN5WnRwLX8+FAdIV8wHdRuQ99QpEcqRzIrcgsdrUOUInVUPNll1LDZJSDc7FR1ideY1 XOqR8/84LG8dvVyVs0NhLEJ9uPfwAgSXKorJkXIMP8vbGsHQOKPVgowAEgd7L9APbVOlfMVP 6tSqJkrAJwW45xo2xXVLmKDJo74dUPhWPcULwJ+60gYutBIRa7fxp6/vdOHPI7kBycuAapJj uazBMpINpTtJNAgJ1noOXfkZpcTGsIHHuJ3bJ63qYGqIBgC3Dh4bzOypBArRAkQ4sdQ9m8Y/ sL6Q9VimF+wgpcDWeU/ItG9XYAx0J2AmnjIfyXI2f6WAQc0vBsdkUNA6pfLerEIiBfWZL1fU 5l6VNhRxx8hhZOvThAX9tJLaJQHGKVAyGE7hN0H/6uxVGbkTiqXZ1Dr6x1kBZcUNmmugc/op qCMayQhMx+2DIGVA+7dbu56rEJsph7HuG6LuTrN+peThFs/gsF7iFDybGkCFKIvwvpQEpxhW 1PmDXvKifdrM9K9jCqCh94u77CMAAAAAAAA= --------------ms060303020901030402080803-- From owner-freebsd-stable@freebsd.org Mon Jul 11 12:54:38 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D55B83146 for ; Mon, 11 Jul 2016 12:54:38 +0000 (UTC) (envelope-from 9214d67c.AEoAAEY-nZAAAAIiJlsAAAJpQ8QAAAABLf0AAElOAAbDmABXg5XK@bnc3.mailjet.com) Received: from o144.p8.mailjet.com (o144.p8.mailjet.com [87.253.233.144]) (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 2056E16DC for ; Mon, 11 Jul 2016 12:54:37 +0000 (UTC) (envelope-from 9214d67c.AEoAAEY-nZAAAAIiJlsAAAJpQ8QAAAABLf0AAElOAAbDmABXg5XK@bnc3.mailjet.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; q=dns/txt; d=bnc3.mailjet.com; i=sandrine=3Dinfos-crepes.com@bnc3.mailjet.com; s=mailjet; h=message-id:mime-version:from:to:subject:date:list-id:list-unsubscribe: precedence:x-csa-complaints:x-mj-mid:content-type; bh=bi9sYxNrobWamlvc7wwx24qdlRk=; b=elEL8MhF7CasWarUjYX2oVw8MQNqfPOT5islOtNZTYf1RfX3s//Vg/a4H tLmKo3Ps3HWSzxtuy6gjHTaKJn+zzN20AkS3eoV59ULbVdTaIRzK4/QEIsmL DYbxgvJfzPL9sZ2uALuqbTe/eghFKnE63vRLIHQii4UOWKnoRciIDM= Message-Id: <9214d67c.AEoAAEY-nZAAAAIiJlsAAAJpQ8QAAAABLf0AAElOAAbDmABXg5XK@mailjet.com> MIME-Version: 1.0 From: Sandrine =?iso-8859-1?q?Cr=EApes?= de France To: freebsd-stable@freebsd.org Subject: Amazon nous ouvre ses portes, soyez les bienvenus Date: Mon, 11 Jul 2016 12:49:15 +0000 Precedence: bulk X-CSA-Complaints: whitelist-complaints@eco.de X-MJ-Mid: AEoAAEY-nZAAAAIiJlsAAAJpQ8QAAAABLf0AAElOAAbDmABXg5XKmtkx9VrZQG2yd9XA58L48wAGeHc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:54:38 -0000 D=C3=A9couvrez la boutique Cr=C3=AApes de France sur AmazonVoir la version = en ligne http://v5vp.mjt.lu/nl2/v5vp/qqn.html?m=3DAEoAAEY-nZAAAAIiJlsAAAJpQ= 8QAAAABLf0AAElOAAbDmABXg5XKmtkx9VrZQG2yd9XA58L48wAGeHc&b=3D9214d67c&e=3D6f2= 46577&email=3Dfreebsd-stable@freebsd.org[http://v5vp.mjt.lu/img/v5vp/b/qhw/= m2qh.jpeg][https://www.amazon.fr/s/ref=3Dbl_dp_s_web_57004031?ie=3DUTF8&nod= e=3D57004031&field-brandtextbin=3DCr%C3%AApes+de+France][http://v5vp.mjt.lu= /img/v5vp/b/qhw/m2qi.jpeg] [http://v5vp.mjt.lu/img/v5vp/b/qhw/m2qj.jpeg][ht= tps://www.amazon.fr/s/ref=3Dbl_dp_s_web_57004031?ie=3DUTF8&node=3D57004031&= field-brandtextbin=3DCr%C3%AApes+de+France] [http://v5vp.mjt.lu/img/v5vp/b/= qhw/mp0u.jpeg][https://www.amazon.fr/Cr%C3%AApes-France-Triangulaire-Pr%C3%= A9d%C3%A9coup%C3%A9-Impression/dp/B01HS2EIKA/ref=3Daag_m_pw_dp?ie=3DUTF8&m= =3DATETND52DI4I0] [http://v5vp.mjt.lu/img/v5vp/b/qhw/mp5w.jpeg][https://www= .amazon.fr/Cr%C3%AApes-France-Distributeur-Thermom%C3%A8tre-Pr%C3%A9paratio= ns/dp/B01HS2CUQ4/ref=3Daag_m_pw_dp?ie=3DUTF8&m=3DATETND52DI4I0] [http://v5v= p.mjt.lu/img/v5vp/b/qhw/mp53.jpeg][https://www.amazon.fr/Cr%C3%AApes-France= -Pr%C3%A9paration-Froment-Sachets/dp/B01HS2ISQ0/ref=3Daag_m_pw_dp?ie=3DUTF8= &m=3DATETND52DI4I0] [http://v5vp.mjt.lu/img/v5vp/b/qhw/mpsu.jpeg][https://w= ww.amazon.fr/KRAMPOUZ-Gaufrier-simple-220-churros/dp/B00T5TWJ6A/ref=3Daag_m= _pw_dp?ie=3DUTF8&m=3DATETND52DI4I0] [http://v5vp.mjt.lu/img/v5vp/b/qhw/mpsp= .jpeg][https://www.amazon.fr/Roller-Grill-Cr%C3%AApi%C3%A8re-%C3%A9lectriqu= e-%C3%89maill%C3%A9e/dp/B01HS2ISKG/ref=3Daag_m_pw_dp?ie=3DUTF8&m=3DATETND52= DI4I0] [http://v5vp.mjt.lu/img/v5vp/b/qhw/mps5.jpeg][https://www.amazon.fr/= Cr%C3%AApes-France-Cr%C3%AAperie-Chassis-Equipement/dp/B01HS2GVOQ/ref=3Daag= _m_pw_dp?ie=3DUTF8&m=3DATETND52DI4I0] [http://v5vp.mjt.lu/img/v5vp/b/qhw/mp= um.jpeg][https://www.amazon.fr/s/ref=3Dsr_pg_2?me=3DATETND52DI4I0&rh=3Di%3A= merchant-items&page=3D2&ie=3DUTF8&qid=3D1467969794]Cet email a =C3=A9t=C3= =A9 envoy=C3=A9 =C3=A0 freebsd-stable@freebsd.org, cliquez ici pour vous d= =C3=A9sabonnerhttp://v5vp.mjt.lu/unsub2?hl=3Dfr&m=3DAEoAAEY-nZAAAAIiJlsAAAJ= pQ8QAAAABLf0AAElOAAbDmABXg5XKmtkx9VrZQG2yd9XA58L48wAGeHc&b=3D9214d67c&e=3D6= f246577&email=3Dfreebsd-stable@freebsd.org .Cr=C3=AApes de France 11 avenue= des Vieux Moulins 74000 Annecy FR= From owner-freebsd-stable@freebsd.org Mon Jul 11 13:33:05 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0006DB83DB0 for ; Mon, 11 Jul 2016 13:33:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 C7C9A1EF1 for ; Mon, 11 Jul 2016 13:33:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 19c7d111-476c-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 11 Jul 2016 13:33:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6BDWvaC003436; Mon, 11 Jul 2016 07:32:57 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468243977.72182.118.camel@freebsd.org> Subject: Re: Not-so stable if you take a CAM error.... From: Ian Lepore To: Karl Denninger , freebsd-stable@freebsd.org Date: Mon, 11 Jul 2016 07:32:57 -0600 In-Reply-To: <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:33:05 -0000 On Mon, 2016-07-11 at 06:30 -0500, Karl Denninger wrote: > On 7/11/2016 02:57, Ronald Klop wrote: > > On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger > > wrote: > > > > > Got a (nasty) surprise this afternoon on my sandbox machine. > > > > > > I was updating some Raspberry Pi2 machines which involved taking > > > the sd > > > card out, sticking it in an adapter and plugging it into the > > > sandbox, > > > then mounting the partition and using rsync. > > > > > > Unfortunately one of the cards was, unknown to me, bad and > > > returned a > > > write error during the update. > > > > > > The machine panic'd immediately after the CAM write error popped > > > up. > > > > > > I was quite surprised by this, since (1) the SD card was (of > > > course) > > > mounted as a UFS filesystem; it shows up as a CAM device, (2) the > > > machine itself is running off a ZFS root on a normal host-adapter > > > and > > > thus there is no comingling of the buffer cache and (3) there > > > were no > > > images being run from (can't, wrong architecture!) nor any system > > > I/O > > > (e.g. pagefile) going to the SD card. > > > > > > I certainly understand that under some circumstances (maybe even > > > most > > > circumstances) taking a hard I/O error to a system device is > > > going to > > > hose you and a panic() is arguably "least astonishment" when the > > > price > > > of being wrong might be a corrupted system file or worse (e.g. > > > corrupted > > > paged-out RSS, etc.) But I didn't expect a panic out a failed > > > write to > > > a device that is mounted and being used purely for data. > > > > > > I don't have a crash dump but can almost-certainly reproduce this > > > if > > > it's something that shouldn't happen and thus merits > > > investigation. > > > > > > > Hi, > > > > I understand you are surprised by this. I don't think it is the way > > it > > should work. > > Is there _any_ debugging information for people to use and try to > > help > > you? Like which FreeBSD version are you running? Which FreeBSD > > version > > was used to create the UFS fs? Does it use softupdates (SU) or also > > journaling (SU+J)? > > Maybe some output of dmesg? Or type of SD-card and reader. Other > > people might have similar problems with similar hardware. > > > > Regards, > > Ronald. > > > FreeBSD 11.0-BETA1 #0 r302489: Sat Jul 9 10:15:24 CDT 2016 > karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP > > and > > FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 > karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBui > ld/src/sys/RPI2 > > Both blew up in the same way when stimulated with same I/O error. > > The filesystem in question does have softupdates enabled (the RPI > images > have it turned on by default) but no journaling. It's not > card/reader > dependent no architecture dependent; when it occurred the first time > I > stuck the card and reader into one of my Pis and attempted to update > it > there (thinking that perhaps my sandbox machine's USB port was wonky) > and it blew up the Pi2 in the exact same way. > > This isn't (obviously, given both Intel-style and ARM machines being > involved) architecture dependent. > > It's been a good long while since I took an actual hard I/O error > that > was 'visible' at the OS level (I've had plenty of disks die on ZFS > over > last few years but no "double failures" on a mirror or similar, and I > on > my servers I haven't had a UFS-based system for a while. This > definitely looks like some sort of regression in the code; I've run > FreeBSD for a hell of a long time and have had plenty of instances > where > disks have failed without having the machine go out from under me. > Unfortunately, this is "just the way it works". A hard IO error while writing to a ufs filesystem with softupdates enabled will cause a panic, because the softupdates code doesn't handle that sort of failure, and the failure means that filesystem integrity is lost. The code has no idea how important the data is to the functioning of the system, no basis on which to decide whether to panic or not. -- Ian From owner-freebsd-stable@freebsd.org Mon Jul 11 13:47:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02AB6B844EB for ; Mon, 11 Jul 2016 13:47:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 9AEFE1BCF for ; Mon, 11 Jul 2016 13:47:01 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 6A2E5408CEC for ; Mon, 11 Jul 2016 08:46:59 -0500 (CDT) Subject: Re: Not-so stable if you take a CAM error.... To: freebsd-stable@freebsd.org References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> From: Karl Denninger Message-ID: <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> Date: Mon, 11 Jul 2016 08:46:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468243977.72182.118.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020802060606020801040803" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:47:02 -0000 This is a cryptographically signed message in MIME format. --------------ms020802060606020801040803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 08:32, Ian Lepore wrote: > On Mon, 2016-07-11 at 06:30 -0500, Karl Denninger wrote: >> On 7/11/2016 02:57, Ronald Klop wrote: >>> On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger >>> wrote: >>> >>>> Got a (nasty) surprise this afternoon on my sandbox machine. >>>> >>>> I was updating some Raspberry Pi2 machines which involved taking >>>> the sd >>>> card out, sticking it in an adapter and plugging it into the >>>> sandbox, >>>> then mounting the partition and using rsync. >>>> >>>> Unfortunately one of the cards was, unknown to me, bad and >>>> returned a >>>> write error during the update. >>>> >>>> The machine panic'd immediately after the CAM write error popped >>>> up. >>>> >>>> I was quite surprised by this, since (1) the SD card was (of >>>> course) >>>> mounted as a UFS filesystem; it shows up as a CAM device, (2) the >>>> machine itself is running off a ZFS root on a normal host-adapter >>>> and >>>> thus there is no comingling of the buffer cache and (3) there >>>> were no >>>> images being run from (can't, wrong architecture!) nor any system >>>> I/O >>>> (e.g. pagefile) going to the SD card. >>>> >>>> I certainly understand that under some circumstances (maybe even >>>> most >>>> circumstances) taking a hard I/O error to a system device is >>>> going to >>>> hose you and a panic() is arguably "least astonishment" when the >>>> price >>>> of being wrong might be a corrupted system file or worse (e.g. >>>> corrupted >>>> paged-out RSS, etc.) But I didn't expect a panic out a failed >>>> write to >>>> a device that is mounted and being used purely for data. >>>> >>>> I don't have a crash dump but can almost-certainly reproduce this >>>> if >>>> it's something that shouldn't happen and thus merits >>>> investigation. >>>> >>> Hi, >>> >>> I understand you are surprised by this. I don't think it is the way >>> it >>> should work. >>> Is there _any_ debugging information for people to use and try to >>> help >>> you? Like which FreeBSD version are you running? Which FreeBSD >>> version >>> was used to create the UFS fs? Does it use softupdates (SU) or also >>> journaling (SU+J)? >>> Maybe some output of dmesg? Or type of SD-card and reader. Other >>> people might have similar problems with similar hardware. >>> >>> Regards, >>> Ronald. >>> >> FreeBSD 11.0-BETA1 #0 r302489: Sat Jul 9 10:15:24 CDT 2016 =20 >> karl@NewFS.denninger.net:/usr/obj/usr/src/sys/KSD-SMP >> >> and >> >> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016 =20 >> karl@NewFS.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBui >> ld/src/sys/RPI2 >> >> Both blew up in the same way when stimulated with same I/O error. >> >> The filesystem in question does have softupdates enabled (the RPI >> images >> have it turned on by default) but no journaling. It's not >> card/reader >> dependent no architecture dependent; when it occurred the first time >> I >> stuck the card and reader into one of my Pis and attempted to update >> it >> there (thinking that perhaps my sandbox machine's USB port was wonky) >> and it blew up the Pi2 in the exact same way. >> >> This isn't (obviously, given both Intel-style and ARM machines being >> involved) architecture dependent. >> >> It's been a good long while since I took an actual hard I/O error >> that >> was 'visible' at the OS level (I've had plenty of disks die on ZFS >> over >> last few years but no "double failures" on a mirror or similar, and I >> on >> my servers I haven't had a UFS-based system for a while. This >> definitely looks like some sort of regression in the code; I've run >> FreeBSD for a hell of a long time and have had plenty of instances >> where >> disks have failed without having the machine go out from under me. >> > Unfortunately, this is "just the way it works". A hard IO error while > writing to a ufs filesystem with softupdates enabled will cause a > panic, because the softupdates code doesn't handle that sort of > failure, and the failure means that filesystem integrity is lost. The > code has no idea how important the data is to the functioning of the > system, no basis on which to decide whether to panic or not. > > -- Ian > Here's the backtrace ... sounds like expected behavior, which is not-so good all-in for a situation like this. I guess the strategy is to turn off softupdates before attempting such an update so as not to crash the host machine if there's a problem with the card. root@Dbms2:/var/crash # kgdb /boot/kernel/kernel vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: initiate_write_inodeblock_ufs2: already started cpuid =3D 14 KDB: stack backtrace: #0 0xffffffff80b1f357 at kdb_backtrace+0x67 #1 0xffffffff80ad6ec2 at vpanic+0x182 #2 0xffffffff80ad6d33 at panic+0x43 #3 0xffffffff80dc16ad at softdep_disk_io_initiation+0x159d #4 0xffffffff80de61eb at ffs_geom_strategy+0x13b #5 0xffffffff80b872f7 at bufwrite+0x267 #6 0xffffffff80b8ac6a at vfs_bio_awrite+0x3ca #7 0xffffffff80b96b77 at vop_stdfsync+0x277 #8 0xffffffff80983766 at devfs_fsync+0x26 #9 0xffffffff81101f7d at VOP_FSYNC_APV+0x8d #10 0xffffffff80baf1ae at sched_sync+0x3be #11 0xffffffff80a8dcb5 at fork_exit+0x85 #12 0xffffffff80f7f85e at fork_trampoline+0xe Uptime: 27m9s (kgdb) where #0 doadump (textdump=3D) at pcpu.h:221 #1 0xffffffff80ad6949 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff80ad6efb in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff80ad6d33 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff80dc16ad in softdep_disk_io_initiation (bp=3D) at /usr/src/sys/ufs/ffs/ffs_softdep.c:10301 #5 0xffffffff80de61eb in ffs_geom_strategy (bo=3D, bp=3D) at buf.h:412 #6 0xffffffff80b872f7 in bufwrite (bp=3D0xfffffe02e8629b30) at buf.h:405= #7 0xffffffff80b8ac6a in vfs_bio_awrite (bp=3D) at buf.h:393 #8 0xffffffff80b96b77 in vop_stdfsync (ap=3D0xfffffe034f481b68) at /usr/src/sys/kern/vfs_default.c:692 #9 0xffffffff80983766 in devfs_fsync (ap=3D0xfffffe034f481b68) at /usr/src/sys/fs/devfs/devfs_vnops.c:702 #10 0xffffffff81101f7d in VOP_FSYNC_APV (vop=3D, a=3D) at vnode_if.c:1331 #11 0xffffffff80baf1ae in sched_sync () at vnode_if.h:549 #12 0xffffffff80a8dcb5 in fork_exit (callout=3D0xffffffff80baedf0 , arg=3D0x0, frame=3D0xfffffe034f481c00) at /usr/src/sys/kern/kern_fork= =2Ec:1038 #13 0xffffffff80f7f85e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #14 0x0000000000000000 in ?? () (kgdb) FreeBSD 11.0-BETA1 #0 r302439: Fri Jul 8 14:37:27 CDT 2016 =20 karl@Dbms2.denninger.net:/usr/obj/usr/src/sys/GENERIC The offending code line: static void initiate_write_inodeblock_ufs2(inodedep, bp) struct inodedep *inodedep; struct buf *bp; /* The inode block */ { struct allocdirect *adp, *lastadp; struct ufs2_dinode *dp; struct ufs2_dinode *sip; struct inoref *inoref; struct ufsmount *ump; struct fs *fs; ufs_lbn_t i; #ifdef INVARIANTS ufs_lbn_t prevlbn =3D 0; #endif int deplist; * if (inodedep->id_state & IOSTARTED)** ** panic("initiate_write_inodeblock_ufs2: already started"= );* inodedep->id_state |=3D IOSTARTED; --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020802060606020801040803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExMzQ2MzNaME8GCSqGSIb3DQEJBDFCBEAX noBAQXaUoBaO0aw54Bts0nIIp/PSE/465xMN36fzeqITV2T6iUHINIZxlPZRvqxW5qLj4RXD x/UE1JptbJKGMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAk2bSzDng ehDbyKQj1GkDrMkK5V7isdI7H5xwDyKvZJVNys43RkRJGQd7H1Q+m4wi8XFOlyCV7lESi4fA W+ucHniCiGtHrdltCTCNXSJ2hvdDyfu9Wf6T2d3dtHERwsXu7jmzFQ0YJg0Kn2jPAN1NTZyq FdzBDbsv1sM+1BJ2zMQbyexqKEjfFD8voqXhAYDhI1JqYthWS35gP31KfWWhhzRgYgGk1IdM wykFyyJKul4v9ALosaAv3mr0WNq0ZQQNrVTqS0hevRTblidcjSPytQ3GhYneDICrXVpxYrFn uNxW0Vv0V2vmMJYKpRNqPwkHIWVlGN3g+gRdL4LdspPZevDHOdzhfeGtH0QtZn1HrdG3DdSn +PuUCjE0iZmXvvcA9JARgGEen5OE+XcMwNSvEN2Sga6/u8EX6195h9wXHTq7Q0Ujp0TR4KTy ANpCNKDwomy4sY8o2q2lhMCNQ0ggetz0X5j92eIwymn83JvQcsUu8qsxO0nJUrx0/ZBOcy8u WaNLy591ap2jHxqHSzVBRMGmo5GjeIMH84v2E92AAhmi5VjEiDPhaT1nTx3cySbHkCcDHs13 MHPV/H7cGdqGAcSc4gCCW77u3rbcZNoySef4pU1K6SbMsbd1O6+BJwQadIkQu/z8/4qyauhA cygJCsjvfMq2pmoC4qhjcPvqoy0AAAAAAAA= --------------ms020802060606020801040803-- From owner-freebsd-stable@freebsd.org Mon Jul 11 13:49:50 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7103FB84716; Mon, 11 Jul 2016 13:49:50 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA6E1DBC; Mon, 11 Jul 2016 13:49:50 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6BDnfp1026711 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 06:49:41 -0700 Subject: Re: stable/11 question: kboot vs. powerpc: only powerpc64? To: Mark Millard , FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current References: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> From: Nathan Whitehorn Message-ID: <5783A3F5.2030301@freebsd.org> Date: Mon, 11 Jul 2016 06:49:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb0oc0MfEW05YlVH6NTuJCMpUbxrsZPGN8pd4QQ90yYPS7xaD1qQlHlsd7x8CmG0g+mXz+KCSe6qIEaKtptK34dbDNLg8HRjvY= X-Sonic-ID: C;po4YUW5H5hG9V5NwxPCmMQ== M;8PxVUW5H5hG9V5NwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:49:50 -0000 It is not 64-bit only; like the normal loader, it can load both 32-bit and 64-bit kernels. Those two flags are probably obsolete at this point and were for compatibility with pre-2.17.5 versions of binutils. Can you do a test build with the -CFLAGS+= -Wa,-mppc64bridge line removed? -Nathan On 07/11/16 03:55, Mark Millard wrote: > Is the following something that should be updated something like is indicated below for 11.0-BETA1? Is kboot powerpc64 specific? > > # svnlite diff /usr/src/sys/boot/powerpc/Makefile > Index: /usr/src/sys/boot/powerpc/Makefile > =================================================================== > --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) > +++ /usr/src/sys/boot/powerpc/Makefile (working copy) > @@ -1,5 +1,9 @@ > # $FreeBSD$ > > -SUBDIR= boot1.chrp kboot ofw ps3 uboot > +SUBDIR= boot1.chrp > +.if ${MACHINE_ARCH} == "powerpc64" > +SUBDIR+= kboot > +.endif > +SUBDIR+= ofw ps3 uboot > > .include > > > > I ask because I'd submitted 206303 back on 2016-jan-16 reporting that TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride and a -mcpu=powerpc64 (one of the base/head/sys/boot/powerpc/kboot/Makefile SRCS being ppc64_elf_freebsd.c). > > === > Mark Millard > markmi at dsl-only.net > > From owner-freebsd-stable@freebsd.org Mon Jul 11 13:50:39 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A7E2B849E2 for ; Mon, 11 Jul 2016 13:50:39 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 D5F2E11BF for ; Mon, 11 Jul 2016 13:50:38 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-qt0-x234.google.com with SMTP id w38so14826257qtb.0 for ; Mon, 11 Jul 2016 06:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8FIu9qNGP1ds/j0e3d9SKfWdmucAvuQe2PULVeRfBu0=; b=VqZ2GBDal8AWRWQrwOQZeJDC50/58uEscCEttwiqj9T4o6hnPjSJfFjWgJfsdxKZQp 4/0KJFOt333LjHnw5bKmDwAPZ9luhFQwT/TscUhiaNFiWi8ecSZ5/0NZuu3YUibYenZF iaIrLaXn8XE5TdgWGvi40d5LxIHtdbAAWwYaMSQHLLAdl78n+ncxE5jlvoUZssprcHTJ q9wkdpsQCD+DDhwjzXhPcChZYQ6eNCNLYuaYQPm3FJ1+ReuqlYIsQdiAuNArAyQlfViq jWWn/4LWRckP+4Y7MYgeeF6k+OMZTrWUouAH63WFu0bcmfBkD0oBg+O2G2MsHMxLyey+ zACQ== 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; bh=8FIu9qNGP1ds/j0e3d9SKfWdmucAvuQe2PULVeRfBu0=; b=Y+vUa8FuSSPL35i8wE5lrCEx0Zs/9UhuxP6Hd/F5/Tbny+Jmlah1LqfJbU1KXs5gF3 6u/eWiRFkFsPOhe9DZZ01pWE1JBWJ2NeJPV++84ATU/m0x6cN9Fjrrg1r2aPq0vNXB+6 oTSDIKKqi9i5ECPbeXE1mS0/NSiq8UVTrvL7rtyelsRen/dlJvqMXP33c2IclzJ7uDh9 x6cJpgMWurEBiivTWrOxtMwj/zo4hYTHyc+bj1DolIc4WTwaoBmvIFcTm/TJzssIb1Kp 4udqAIzIr0uJlmDg6GKBb4oupzVl/tcsO88Ec1gBJZP5d4YLGZaA/5yh8r12SEtS7Ipv DSDw== X-Gm-Message-State: ALyK8tJF45uqzidrBi7l0HxXHLcCuYXkwIX5XUaF/LMbgmZcRq/G59lncqNPDp3gyeCClLNCueRayuJkx8zb6g== X-Received: by 10.237.55.168 with SMTP id j37mr29169340qtb.102.1468245037893; Mon, 11 Jul 2016 06:50:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.42.8 with HTTP; Mon, 11 Jul 2016 06:50:37 -0700 (PDT) In-Reply-To: <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> From: Brandon Allbery Date: Mon, 11 Jul 2016 09:50:37 -0400 Message-ID: Subject: Re: Not-so stable if you take a CAM error.... To: Karl Denninger Cc: freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:50:39 -0000 On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger wrote: > Here's the backtrace ... sounds like expected behavior, which is not-so > good all-in for a situation like this. I guess the strategy is to turn > off softupdates before attempting such an update so as not to crash the > host machine if there's a problem with the card. > I would tend to assume that removable media should not have softupdates enabled. Even with properly working media, it's practically begging for corruption. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@freebsd.org Mon Jul 11 13:53:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA0D6B84D19 for ; Mon, 11 Jul 2016 13:53:06 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.alogis.com [212.184.102.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 5438F15C2 for ; Mon, 11 Jul 2016 13:53:05 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from msx3.exchange.alogis.com (msxcn2.exchange.alogis.com [10.1.1.22]) by alogis.com (8.13.4/8.13.1) with ESMTP id u6BDnxRn046414 for ; Mon, 11 Jul 2016 15:49:59 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([10.1.1.26]) by msxcn2.exchange.alogis.com ([fe80::11b6:f5c4:b8ee:4a89%15]) with mapi id 14.03.0279.002; Mon, 11 Jul 2016 15:49:58 +0200 From: Holger Kipp To: "freebsd-stable@freebsd.org" Subject: freebsd-update fetch/install for 10.2-RELEASE => different kernel/userland patch versions? Thread-Topic: freebsd-update fetch/install for 10.2-RELEASE => different kernel/userland patch versions? Thread-Index: AQHR23scotIlkPFI60y92vCwfuSpcg== Date: Mon, 11 Jul 2016 13:49:58 +0000 Message-ID: <542C2199-309E-456E-B6D5-C49620EE76DA@alogis.com> Accept-Language: de-DE, en-GB, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.184.101.130] Content-Type: text/plain; charset="us-ascii" Content-ID: <39723895B08163489732E278F9F41048@exchange.alogis.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:53:06 -0000 Hi all, I currently issued=20 freebsd-update fetch freebsd-update install and after reboot have freebsd-version -ku 10.2-RELEASE-p18 10.2-RELEASE-p19 Please note that kernel version is p18, userland p19. Is this intended behavior or is something broken with freebsd-update? System in question is a vanilla 10.2-RELEASE on amd64 (out of the box). Many thanks and best regards, Holger From owner-freebsd-stable@freebsd.org Mon Jul 11 13:57:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B94EEB84F2F for ; Mon, 11 Jul 2016 13:57:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 720C817B7 for ; Mon, 11 Jul 2016 13:57:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 12AA9408E06 for ; Mon, 11 Jul 2016 08:57:06 -0500 (CDT) Subject: Re: Not-so stable if you take a CAM error.... To: freebsd-stable@freebsd.org References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> From: Karl Denninger Message-ID: <155d322e-01c9-ef36-bc68-5c3a58835bb6@denninger.net> Date: Mon, 11 Jul 2016 08:56:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070808020806030501060403" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:57:10 -0000 This is a cryptographically signed message in MIME format. --------------ms070808020806030501060403 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 08:50, Brandon Allbery wrote: > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger wr= ote: > >> Here's the backtrace ... sounds like expected behavior, which is not-s= o >> good all-in for a situation like this. I guess the strategy is to tur= n >> off softupdates before attempting such an update so as not to crash th= e >> host machine if there's a problem with the card. >> > I would tend to assume that removable media should not have softupdates= > enabled. Even with properly working media, it's practically begging for= > corruption. But it's not normally "removable media" -- which is the point. The operation in question occurs when you take a storage device out of an embedded machine (where softupdates has a material positive performance impact in that it obviates the need for most fsck-on-boot operations before the system comes up) and mount it temporarily to update it on a second device. It appears, however, that to prevent crashing the updating machine you first need to make sure softupdates is off (tunefs it) and then turn it back on when done -- otherwise you risk this outcome in the event there is an unknown write error lurking around. Oh, and for flash-based media those errors are *frequently* going to be unknown in advance -- I suspect the reason it occurred is that the card in question ran out of reallocation blocks and took a write error which would normally cause it to use a spare, but it has no spares left and thus returns a hard error. The existing data on the card at that point is still readable, but you can't make changes since a write on such a card invokes a read/erase/write cycle. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070808020806030501060403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExMzU2NDFaME8GCSqGSIb3DQEJBDFCBECc LA+fEoxkLDlcT/x4evG5cPw51yMilI1xAOVj4aWmEOD7uIDT7cNTvpEPoKO4AB+JBYOl51Kx qD9ozUBMo/J+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAOFgw2rhz pCg3/C75OEJ9YSEgUoO1ttPUWGtHPT5uEFR0+A+K30j3JvNo79NI/5jkkFjlD4GUdxAMAu05 qJ+TmmPJZ4uTRdh6lIVCzUxCgiqszkcxusSM5VH4YBKefuCIU5AO7K6NnmTJAwGaO8/xl02k J7x+CciTh5TPGjmRl6toM2X20oDVGXjoTSuZ+uuCKOKnQ2XqlQJFJHChBfs9hLoxJewlONEf ri3nUz/K1v9rkrF+T/3wNMjnqsW9EDE0PFlI9NrlLaWe3UcWlEaI/L/N97IdO9N8pv58pO8c OfZb97ArYoJmsuhpz0WtC7oF9DFSrVIjwPq8fcBIkRDWSbFCt9XLWYSBS7Ze7wL+V+rnwa0F XXhIb03y5p19TAlThkGJApCqTtvoojELwM3lFYfwRbdf/0D4bBkR0By1jxwTP8yfFsKtH2ay b/95OFwDgF6SKMJ7zHYzzNo6q5ZyUJB7FIl4xOSOVOeHJ8g09zQWvQDwqY5xfLKmuhP/xV1X s+gvIcvveKu9kCQWdgu+N8SrCPCOPp5YBT5Mr77Do+cOdHzF9jtek0pkV+D3GKywNHzsPInJ T8CPTUdrhY9rRoC/d8iGppw7AXTHjpkRsczxR5+buYQ9T4H8KTQ81DTHnbVvmrV8xVIQI2g/ djKgSQO04vLw4OMF2B+A1Zs5cfoAAAAAAAA= --------------ms070808020806030501060403-- From owner-freebsd-stable@freebsd.org Mon Jul 11 13:58:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89987B851B0 for ; Mon, 11 Jul 2016 13:58:44 +0000 (UTC) (envelope-from lists@opsec.eu) 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 4F93019B6 for ; Mon, 11 Jul 2016 13:58:44 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bMbjQ-0006bs-6J; Mon, 11 Jul 2016 15:58:44 +0200 Date: Mon, 11 Jul 2016 15:58:44 +0200 From: Kurt Jaeger To: Holger Kipp Cc: "freebsd-stable@freebsd.org" Subject: Re: freebsd-update fetch/install for 10.2-RELEASE => different kernel/userland patch versions? Message-ID: <20160711135844.GC95302@home.opsec.eu> References: <542C2199-309E-456E-B6D5-C49620EE76DA@alogis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542C2199-309E-456E-B6D5-C49620EE76DA@alogis.com> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:58:44 -0000 Hi! > I currently issued > > freebsd-update fetch > freebsd-update install > > and after reboot have > > freebsd-version -ku > 10.2-RELEASE-p18 > 10.2-RELEASE-p19 > > Please note that kernel version is p18, userland p19. > > Is this intended behavior or is something broken with freebsd-update? This is the intended behaviour. p19 is a userland-only patch, see https://www.freebsd.org/security/advisories/FreeBSD-SA-16:24.ntp.asc for details. -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-stable@freebsd.org Mon Jul 11 16:32:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 746F8B92357 for ; Mon, 11 Jul 2016 16:32:29 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 395F01AEE for ; Mon, 11 Jul 2016 16:32:28 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 2cfef368-4785-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 11 Jul 2016 16:33:19 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6BGWQFY003772; Mon, 11 Jul 2016 10:32:26 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468254746.72182.121.camel@freebsd.org> Subject: Re: Not-so stable if you take a CAM error.... From: Ian Lepore To: Brandon Allbery , Karl Denninger Cc: freebsd-stable Date: Mon, 11 Jul 2016 10:32:26 -0600 In-Reply-To: References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:32:29 -0000 On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote: > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger > wrote: > > > Here's the backtrace ... sounds like expected behavior, which is > > not-so > > good all-in for a situation like this. I guess the strategy is to > > turn > > off softupdates before attempting such an update so as not to crash > > the > > host machine if there's a problem with the card. > > > > I would tend to assume that removable media should not have > softupdates > enabled. Even with properly working media, it's practically begging > for > corruption. > Writing to an sdcard without softupdates enabled will be an exercise in patience. Like, come back next week and maybe it'll be done. The only thing that comes to mind with this is maybe some sort of mount flag to say you're willing to live with any amount of filesystem corruption in lieu of panicking. I'm not sure how easy/practical that would be to implement, though. -- Ian From owner-freebsd-stable@freebsd.org Mon Jul 11 16:54:16 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22948B921FB for ; Mon, 11 Jul 2016 16:54:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 14CD316A8; Mon, 11 Jul 2016 16:54:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 98E93163; Mon, 11 Jul 2016 16:54:16 +0000 (UTC) Date: Mon, 11 Jul 2016 16:54:16 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <458683891.31.1468256056555.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1440611393.18.1468234621318.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1440611393.18.1468234621318.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #305 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:54:16 -0000 See From owner-freebsd-stable@freebsd.org Mon Jul 11 17:31:02 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2DB4B9214C for ; Mon, 11 Jul 2016 17:31:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 747AF1ABD for ; Mon, 11 Jul 2016 17:31:02 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 40B293A7A09 for ; Mon, 11 Jul 2016 12:31:00 -0500 (CDT) Subject: Re: Not-so stable if you take a CAM error.... To: freebsd-stable@freebsd.org References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <1468254746.72182.121.camel@freebsd.org> From: Karl Denninger Message-ID: Date: Mon, 11 Jul 2016 12:30:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468254746.72182.121.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000401070808090703050005" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:31:02 -0000 This is a cryptographically signed message in MIME format. --------------ms000401070808090703050005 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 11:32, Ian Lepore wrote: > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote: >> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger >> wrote: >> >>> Here's the backtrace ... sounds like expected behavior, which is >>> not-so >>> good all-in for a situation like this. I guess the strategy is to >>> turn >>> off softupdates before attempting such an update so as not to crash >>> the >>> host machine if there's a problem with the card. >>> >> I would tend to assume that removable media should not have >> softupdates >> enabled. Even with properly working media, it's practically begging >> for >> corruption. >> > Writing to an sdcard without softupdates enabled will be an exercise in= > patience. Like, come back next week and maybe it'll be done. > > The only thing that comes to mind with this is maybe some sort of mount= > flag to say you're willing to live with any amount of filesystem > corruption in lieu of panicking. I'm not sure how easy/practical that > would be to implement, though. > > -- Ian Why not force-detach the volume that takes the error instead of a panic()= ? That would lead to a panic if the detached volume was the system volume (obviously) but for a data volume it would simply result in it being forcibly unmounted (and dirty, so if it's corrupt it will get caught when reattached.) It seems that the current paradigm of saying "screw you, panic the machine" violates the principle of least astonishment and is overly punitive vis-a-vis necessity. Refusing further I/O because the volume may now have a corrupt filesystem appears to be facially reasonable, but that doesn't necessarily wind up being fatal the system itself -- it is if that's the system volume and is not covered by some sort of redundancy, obviously, but it's not in all cases. (Note that you can't just unmount the filesystem involved in the error; it has to be the volume that gets forcibly detached and whatever flows through from that you have to live with. The reason is that on any sort of solid-state media the OS has zero control over zoning and write amplification means far more the data you were actually modifying may have been lost -- it's entirely possible that *several megabytes* of data just got trashed by the write error, and it's even possible that the block(s) involved cross a filesystem boundary!) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000401070808090703050005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExNzMwMzRaME8GCSqGSIb3DQEJBDFCBEDH Qy1FGuM+xAOz8QWBpciX4ePDH5YyCuUiezPkD0mP8bSNkytkbPxwoPy+/g4r7mXFXj6CIFct rl0df6CCNhkLMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAEPUTZAFp R5cSZXtJAvCW0JlQaXbsbAfgyuqFAW2oVMqXxVmB0OJU2fAxqldx7H5QlbrfqblT/Fzs83PT Ewvl4dp95arDch5dYavuig2bgkh2YTeR+qM8x+Rog73V+OZlnxoeBLIMWcNvtECiJYVO969y tFUh6rrhI//54FFP+AB553ly2e335rC8xnbu9yCXZboyhn49X5+ptaQfmnWMPHOvJcYllZCf 4OWkUV5f3bfIHtN+PRbhbW707YMCP6Ty4Cw/Ot3qhekGZKnK/VmXRdl+7sLyD3ALgYt6bTrw JDVVrPjN7LhFUyNst/cjuZChJES31JHyQYeC8DCcaRjxirtHbfoLO0SkU8TT02no7vPBD72h uxU94tTSA9OE3OTvMncfdhvCSGlmHHFsH3vBl0IBwLQYFQKFbF+t9NLo9W46THXvj+dUkhTx fYw1kAp/jTBx4IgaC62Aq+TGYlL0m4hDIpqUx+W8D/YVvKxWvKn1KBUr4giscqSbEF2ONpXg IcAaxY6e/6/pWQ5cvvLcDmQPRJwLvCa8jFZZG2sqSBn6+OFZnTWu4Q6P3F8i99/oV7dbSqo8 z1HU8KCbSCgeX4jcsxv1GlB60GTJwvbXRVe1xC9xJpS4G5b8ocNO8VcVoAs5yJCl+L0P/dSw WNK3SfXD5xUfO8iVLiy8aUJHjD8AAAAAAAA= --------------ms000401070808090703050005-- From owner-freebsd-stable@freebsd.org Mon Jul 11 17:39:52 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD584B925FD for ; Mon, 11 Jul 2016 17:39:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 B0ACC15AD for ; Mon, 11 Jul 2016 17:39:52 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 96b3331b-478e-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 11 Jul 2016 17:40:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6BHdnKC003908; Mon, 11 Jul 2016 11:39:49 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468258789.72182.122.camel@freebsd.org> Subject: Re: Not-so stable if you take a CAM error.... From: Ian Lepore To: Karl Denninger , freebsd-stable@freebsd.org Date: Mon, 11 Jul 2016 11:39:49 -0600 In-Reply-To: References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <1468254746.72182.121.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:39:52 -0000 On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote: > On 7/11/2016 11:32, Ian Lepore wrote: > > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote: > > > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger < > > > karl@denninger.net> > > > wrote: > > > > > > > Here's the backtrace ... sounds like expected behavior, which > > > > is > > > > not-so > > > > good all-in for a situation like this. I guess the strategy is > > > > to > > > > turn > > > > off softupdates before attempting such an update so as not to > > > > crash > > > > the > > > > host machine if there's a problem with the card. > > > > > > > I would tend to assume that removable media should not have > > > softupdates > > > enabled. Even with properly working media, it's practically > > > begging > > > for > > > corruption. > > > > > Writing to an sdcard without softupdates enabled will be an > > exercise in > > patience. Like, come back next week and maybe it'll be done. > > > > The only thing that comes to mind with this is maybe some sort of > > mount > > flag to say you're willing to live with any amount of filesystem > > corruption in lieu of panicking. I'm not sure how easy/practical > > that > > would be to implement, though. > > > > -- Ian > Why not force-detach the volume that takes the error instead of a > panic()? > Patches welcome. -- Ian > That would lead to a panic if the detached volume was the system > volume > (obviously) but for a data volume it would simply result in it being > forcibly unmounted (and dirty, so if it's corrupt it will get caught > when reattached.) > > It seems that the current paradigm of saying "screw you, panic the > machine" violates the principle of least astonishment and is overly > punitive vis-a-vis necessity. Refusing further I/O because the > volume > may now have a corrupt filesystem appears to be facially reasonable, > but > that doesn't necessarily wind up being fatal the system itself -- it > is > if that's the system volume and is not covered by some sort of > redundancy, obviously, but it's not in all cases. > > (Note that you can't just unmount the filesystem involved in the > error; > it has to be the volume that gets forcibly detached and whatever > flows > through from that you have to live with. The reason is that on any > sort > of solid-state media the OS has zero control over zoning and write > amplification means far more the data you were actually modifying may > have been lost -- it's entirely possible that *several megabytes* of > data just got trashed by the write error, and it's even possible that > the block(s) involved cross a filesystem boundary!) > From owner-freebsd-stable@freebsd.org Mon Jul 11 17:44:52 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23E47B9286F for ; Mon, 11 Jul 2016 17:44:52 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 CB38619D3 for ; Mon, 11 Jul 2016 17:44:51 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 7D3BC3A7AEB for ; Mon, 11 Jul 2016 12:44:50 -0500 (CDT) Subject: Re: Not-so stable if you take a CAM error.... To: freebsd-stable@freebsd.org References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <1468254746.72182.121.camel@freebsd.org> <1468258789.72182.122.camel@freebsd.org> From: Karl Denninger Message-ID: <21f3f685-4618-e258-0538-75602608cf9b@denninger.net> Date: Mon, 11 Jul 2016 12:44:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1468258789.72182.122.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000506080103070206030702" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:44:52 -0000 This is a cryptographically signed message in MIME format. --------------ms000506080103070206030702 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/11/2016 12:39, Ian Lepore wrote: > On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote: >> On 7/11/2016 11:32, Ian Lepore wrote: >>> On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote: >>>> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger < >>>> karl@denninger.net> >>>> wrote: >>>> >>>>> Here's the backtrace ... sounds like expected behavior, which >>>>> is >>>>> not-so >>>>> good all-in for a situation like this. I guess the strategy is >>>>> to >>>>> turn >>>>> off softupdates before attempting such an update so as not to >>>>> crash >>>>> the >>>>> host machine if there's a problem with the card. >>>>> >>>> I would tend to assume that removable media should not have >>>> softupdates >>>> enabled. Even with properly working media, it's practically >>>> begging >>>> for >>>> corruption. >>>> >>> Writing to an sdcard without softupdates enabled will be an >>> exercise in >>> patience. Like, come back next week and maybe it'll be done. >>> >>> The only thing that comes to mind with this is maybe some sort of >>> mount >>> flag to say you're willing to live with any amount of filesystem >>> corruption in lieu of panicking. I'm not sure how easy/practical >>> that >>> would be to implement, though. >>> >>> -- Ian >> Why not force-detach the volume that takes the error instead of a >> panic()? >> > Patches welcome. > > -- Ian Any hints on where the routine(s) live that would forcibly detach a volume? (I'll go digging as well but shortening the time would help :)) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000506080103070206030702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTExNzQ0MjRaME8GCSqGSIb3DQEJBDFCBEBt 3sYxGYuEP50jJ65rZWVHQadVt5SR8mRz4ANG/1xRIo5HxUbvI8w0rxq14ILjMWC0MPaHqqj/ Xc+VXMmaRGEsMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAPFGn4Soz yhTS66S8uaBtAe1g2ClhhDKg4U75Kqh7CtO1VObBD9xkbA9NizpToC04nTAfe0b+91TQsaVa kvSHgdUHXetw26D32Bcvezk4Gm5DfxfE4gyQrvRj2FHTA4UYMX497sCvuxUe/dDAonCAiOvQ ZTZLPHoSsHOcWBeildXLRY5VV4C6n23Mtg07Y9kv2JChr42SY1oDFmxZekn/mB/tnU8CuTfJ 1oTUonZhhGFZpyLvtSCtpjCZ48d3JG/JVPlXaT7MHf9wFKIiWU1HABz773+lo0MrtD9I9l+y Z2NJiYD/E4Xl7zQWbRM/LeyeSktsb8q3EH376EkYxLqPOuWS3Q1ymOWmRUQpwwRpS+crh+gU YSsttdoOGp+3eiHas0++i4UhWUgjKpIEn0rzUBh2/sRquQUel52vsdX5KjlrkxnuZpF1os4x F3LhYOA1nMdgz/GaxuvpZFH7LATVucizkXPvV3ZxmWQYikGrzUOuwOWKbBasmxZyAiVXFrf7 hRzQMal3G2PHRFN/u+G1R64aedXrk33UM/HMgJLOSwkDFC8YzBoPaZVaJ9lH/RVkiAtw0OTB HJpzg/JdpCGR96NALOt2jDhFna+Xt3RXdvi3wxEdSQ/N5WcT080EmXgQcufyKtnXVUTjUaLH re4b7hu+9r6WfQ1NFNb9x5a3mL0AAAAAAAA= --------------ms000506080103070206030702-- From owner-freebsd-stable@freebsd.org Mon Jul 11 18:04:27 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6EB8B92DA8 for ; Mon, 11 Jul 2016 18:04:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 9A6EE16E9 for ; Mon, 11 Jul 2016 18:04:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5928 invoked from network); 11 Jul 2016 18:04:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Jul 2016 18:04:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 14:04:28 -0400 (EDT) Received: (qmail 31841 invoked from network); 11 Jul 2016 18:04:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jul 2016 18:04:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 96FDFB1E001; Mon, 11 Jul 2016 11:04:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: stable/11 question: kboot vs. powerpc: only powerpc64? From: Mark Millard In-Reply-To: <5783A3F5.2030301@freebsd.org> Date: Mon, 11 Jul 2016 11:04:20 -0700 Cc: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <73A6C8D3-6733-4E75-9C5C-59F8A5BB5039@dsl-only.net> References: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> <5783A3F5.2030301@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 18:04:28 -0000 On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn = wrote: >=20 > It is not 64-bit only; like the normal loader, it can load both 32-bit = and 64-bit kernels. Those two flags are probably obsolete at this point = and were for compatibility with pre-2.17.5 versions of binutils. Can you = do a test build with the -CFLAGS+=3D -Wa,-mppc64bridge line removed? > -Nathan >=20 > On 07/11/16 03:55, Mark Millard wrote: >> Is the following something that should be updated something like is = indicated below for 11.0-BETA1? Is kboot powerpc64 specific? >>=20 >> # svnlite diff /usr/src/sys/boot/powerpc/Makefile >> Index: /usr/src/sys/boot/powerpc/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) >> +++ /usr/src/sys/boot/powerpc/Makefile (working copy) >> @@ -1,5 +1,9 @@ >> # $FreeBSD$ >> -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot >> +SUBDIR=3D boot1.chrp >> +.if ${MACHINE_ARCH} =3D=3D "powerpc64" >> +SUBDIR+=3D kboot >> +.endif >> +SUBDIR+=3D ofw ps3 uboot >> .include >>=20 >>=20 >>=20 >> I ask because I'd submitted 206303 back on 2016-jan-16 reporting that = TARGET_ARCH=3Dpowerpc WITH_BOOT=3D was stopped by getting a = -Wc,-mppc64bride and a -mcpu=3Dpowerpc64 (one of the = base/head/sys/boot/powerpc/kboot/Makefile SRCS being = ppc64_elf_freebsd.c). >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net I do not have access to powerpc's currently so I'm just going to be = doing cross-build tests for TARGET_ARCH=3Dpowerpc and = TARGET_ARCH=3Dpowerpc64 (from amd64) based on the below updates. You initially mention "two flags" but then only explicitly request = removal of one (the -CFLAGS+=3D -Wa,-mppc64bridge line). I'm assuming that the -mcpu=3Dpowerpc64 is also to be removed if powerpc = (non-64) is to be covered. See my intended test below. Let me know if it = is not what you want.=20 > # svnlite diff sys/boot/powerpc/kboot/Makefile > Index: sys/boot/powerpc/kboot/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/boot/powerpc/kboot/Makefile (revision 302457) > +++ sys/boot/powerpc/kboot/Makefile (working copy) > @@ -71,7 +71,7 @@ > # Avoid the open-close-dance for every file access as some firmwares = perform > # an auto-negotiation on every open of the network interface and thus = causes > # netbooting to take horribly long. > -CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE -mcpu=3Dpowerpc64 > +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE > =20 > # Always add MI sources > .PATH: ${.CURDIR}/../../common = ${.CURDIR}/../../../libkern > @@ -88,9 +88,6 @@ > =20 > LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc > =20 > -# 64-bit bridge extensions > -CFLAGS+=3D -Wa,-mppc64bridge > - > # Pull in common loader code > #.PATH: ${.CURDIR}/../../ofw/common > #.include "${.CURDIR}/../../ofw/common/Makefile.inc" > # svnlite diff sys/boot/powerpc/Makefile > #=20 (I.e., I reverted sys/boot/powerpc/Makefile.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Jul 11 18:30:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D33FAB926A7 for ; Mon, 11 Jul 2016 18:30:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 63689198E for ; Mon, 11 Jul 2016 18:30:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4419 invoked from network); 11 Jul 2016 18:31:25 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Jul 2016 18:31:25 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 14:31:37 -0400 (EDT) Received: (qmail 7704 invoked from network); 11 Jul 2016 18:31:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jul 2016 18:31:37 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 13A981C4388; Mon, 11 Jul 2016 11:30:44 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: stable/11 question: kboot vs. powerpc: only powerpc64? From: Mark Millard In-Reply-To: <73A6C8D3-6733-4E75-9C5C-59F8A5BB5039@dsl-only.net> Date: Mon, 11 Jul 2016 11:30:46 -0700 Cc: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <341B3611-39DD-4359-9A26-CE4781445D02@dsl-only.net> References: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> <5783A3F5.2030301@freebsd.org> <73A6C8D3-6733-4E75-9C5C-59F8A5BB5039@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 18:30:54 -0000 On 2016-Jul-11, at 11:04 AM, Mark Millard wrote: > On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn = wrote: >>=20 >> It is not 64-bit only; like the normal loader, it can load both = 32-bit and 64-bit kernels. Those two flags are probably obsolete at this = point and were for compatibility with pre-2.17.5 versions of binutils. = Can you do a test build with the -CFLAGS+=3D -Wa,-mppc64bridge line = removed? >> -Nathan >>=20 >> On 07/11/16 03:55, Mark Millard wrote: >>> Is the following something that should be updated something like is = indicated below for 11.0-BETA1? Is kboot powerpc64 specific? >>>=20 >>> # svnlite diff /usr/src/sys/boot/powerpc/Makefile >>> Index: /usr/src/sys/boot/powerpc/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) >>> +++ /usr/src/sys/boot/powerpc/Makefile (working copy) >>> @@ -1,5 +1,9 @@ >>> # $FreeBSD$ >>> -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot >>> +SUBDIR=3D boot1.chrp >>> +.if ${MACHINE_ARCH} =3D=3D "powerpc64" >>> +SUBDIR+=3D kboot >>> +.endif >>> +SUBDIR+=3D ofw ps3 uboot >>> .include >>>=20 >>>=20 >>>=20 >>> I ask because I'd submitted 206303 back on 2016-jan-16 reporting = that TARGET_ARCH=3Dpowerpc WITH_BOOT=3D was stopped by getting a = -Wc,-mppc64bride and a -mcpu=3Dpowerpc64 (one of the = base/head/sys/boot/powerpc/kboot/Makefile SRCS being = ppc64_elf_freebsd.c). >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >=20 > I do not have access to powerpc's currently so I'm just going to be = doing cross-build tests for TARGET_ARCH=3Dpowerpc and = TARGET_ARCH=3Dpowerpc64 (from amd64) based on the below updates. >=20 > You initially mention "two flags" but then only explicitly request = removal of one (the -CFLAGS+=3D -Wa,-mppc64bridge line). >=20 > I'm assuming that the -mcpu=3Dpowerpc64 is also to be removed if = powerpc (non-64) is to be covered. See my intended test below. Let me = know if it is not what you want.=20 >=20 >> # svnlite diff sys/boot/powerpc/kboot/Makefile >> Index: sys/boot/powerpc/kboot/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/boot/powerpc/kboot/Makefile (revision 302457) >> +++ sys/boot/powerpc/kboot/Makefile (working copy) >> @@ -71,7 +71,7 @@ >> # Avoid the open-close-dance for every file access as some firmwares = perform >> # an auto-negotiation on every open of the network interface and thus = causes >> # netbooting to take horribly long. >> -CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE -mcpu=3Dpowerpc64 >> +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE >>=20 >> # Always add MI sources >> .PATH: ${.CURDIR}/../../common = ${.CURDIR}/../../../libkern >> @@ -88,9 +88,6 @@ >>=20 >> LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc >>=20 >> -# 64-bit bridge extensions >> -CFLAGS+=3D -Wa,-mppc64bridge >> - >> # Pull in common loader code >> #.PATH: ${.CURDIR}/../../ofw/common >> #.include "${.CURDIR}/../../ofw/common/Makefile.inc" >=20 >> # svnlite diff sys/boot/powerpc/Makefile >> #=20 >=20 > (I.e., I reverted sys/boot/powerpc/Makefile.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net The TARGET_ARCH=3Dpowerpc build completed with the following messages = (from grep'ing for kboot in the typescript file): > =3D=3D=3D> sys/boot/powerpc/kboot (all) > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o > /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' = is uninitialized when used here [-Wuninitialized] > /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the = variable 'sp' to silence this warning > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_fr= eebsd.o > /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' is invalid in C99 = [-Wimplicit-function-declaration] > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall= .o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.= o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o > --- kbootfdt.o --- > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = 'const char *' to parameter of type 'char *' discards qualifiers = [-Wincompatible-pointer-types-discards-qualifiers] > /usr/src/sys/boot/powerpc/kboot/host_syscall.h:36:21: note: passing = argument to parameter 'path' here > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ucmpdi2.o > In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/ucmpdi2.c:37: > In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/quad.h:59: > /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: "No user-serviceable parts inside." [-W#warnings] > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/boot.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/commands.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/console.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/devopen.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_backs= lash.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_parse= .o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ls.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/misc.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/module.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/panic.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf32.o= > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf32.= o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf64.o= > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf64.= o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/dev_net.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/disk.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/part.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/crc32.o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_forth= .o > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.kboot= > Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.help The compiler involved was clang 3.8.0 . (This was a WITH_META_MODE=3Dyes = build.) The TARGET_ARCH=3Dpowerpc64 build also completed. The compiler involved = was powerpc64-gcc. (This was a WITH_META_MODE=3Dyes build.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Jul 11 18:43:10 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C253BB92D79 for ; Mon, 11 Jul 2016 18:43:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 8679B173D for ; Mon, 11 Jul 2016 18:43:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30358 invoked from network); 11 Jul 2016 18:43:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Jul 2016 18:43:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 14:43:58 -0400 (EDT) Received: (qmail 19273 invoked from network); 11 Jul 2016 18:43:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jul 2016 18:43:57 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 7D6F81C438F; Mon, 11 Jul 2016 11:43:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: stable/11 question: kboot vs. powerpc: only powerpc64? From: Mark Millard In-Reply-To: <341B3611-39DD-4359-9A26-CE4781445D02@dsl-only.net> Date: Mon, 11 Jul 2016 11:43:06 -0700 Cc: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5B3BC302-70DE-4FDA-A442-AC317E146B46@dsl-only.net> References: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> <5783A3F5.2030301@freebsd.org> <73A6C8D3-6733-4E75-9C5C-59F8A5BB5039@dsl-only.net> <341B3611-39DD-4359-9A26-CE4781445D02@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 18:43:10 -0000 On 2016-Jul-11, at 11:30 AM, Mark Millard wrote: > On 2016-Jul-11, at 11:04 AM, Mark Millard wrote: >=20 >> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn = wrote: >>>=20 >>> It is not 64-bit only; like the normal loader, it can load both = 32-bit and 64-bit kernels. Those two flags are probably obsolete at this = point and were for compatibility with pre-2.17.5 versions of binutils. = Can you do a test build with the -CFLAGS+=3D -Wa,-mppc64bridge line = removed? >>> -Nathan >>>=20 >>> On 07/11/16 03:55, Mark Millard wrote: >>>> Is the following something that should be updated something like is = indicated below for 11.0-BETA1? Is kboot powerpc64 specific? >>>>=20 >>>> # svnlite diff /usr/src/sys/boot/powerpc/Makefile >>>> Index: /usr/src/sys/boot/powerpc/Makefile >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) >>>> +++ /usr/src/sys/boot/powerpc/Makefile (working copy) >>>> @@ -1,5 +1,9 @@ >>>> # $FreeBSD$ >>>> -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot >>>> +SUBDIR=3D boot1.chrp >>>> +.if ${MACHINE_ARCH} =3D=3D "powerpc64" >>>> +SUBDIR+=3D kboot >>>> +.endif >>>> +SUBDIR+=3D ofw ps3 uboot >>>> .include >>>>=20 >>>>=20 >>>>=20 >>>> I ask because I'd submitted 206303 back on 2016-jan-16 reporting = that TARGET_ARCH=3Dpowerpc WITH_BOOT=3D was stopped by getting a = -Wc,-mppc64bride and a -mcpu=3Dpowerpc64 (one of the = base/head/sys/boot/powerpc/kboot/Makefile SRCS being = ppc64_elf_freebsd.c). >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>=20 >> I do not have access to powerpc's currently so I'm just going to be = doing cross-build tests for TARGET_ARCH=3Dpowerpc and = TARGET_ARCH=3Dpowerpc64 (from amd64) based on the below updates. >>=20 >> You initially mention "two flags" but then only explicitly request = removal of one (the -CFLAGS+=3D -Wa,-mppc64bridge line). >>=20 >> I'm assuming that the -mcpu=3Dpowerpc64 is also to be removed if = powerpc (non-64) is to be covered. See my intended test below. Let me = know if it is not what you want.=20 >>=20 >>> # svnlite diff sys/boot/powerpc/kboot/Makefile >>> Index: sys/boot/powerpc/kboot/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/boot/powerpc/kboot/Makefile (revision 302457) >>> +++ sys/boot/powerpc/kboot/Makefile (working copy) >>> @@ -71,7 +71,7 @@ >>> # Avoid the open-close-dance for every file access as some firmwares = perform >>> # an auto-negotiation on every open of the network interface and = thus causes >>> # netbooting to take horribly long. >>> -CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE -mcpu=3Dpowerpc64 >>> +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE >>>=20 >>> # Always add MI sources >>> .PATH: ${.CURDIR}/../../common = ${.CURDIR}/../../../libkern >>> @@ -88,9 +88,6 @@ >>>=20 >>> LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc >>>=20 >>> -# 64-bit bridge extensions >>> -CFLAGS+=3D -Wa,-mppc64bridge >>> - >>> # Pull in common loader code >>> #.PATH: ${.CURDIR}/../../ofw/common >>> #.include "${.CURDIR}/../../ofw/common/Makefile.inc" >>=20 >>> # svnlite diff sys/boot/powerpc/Makefile >>> #=20 >>=20 >> (I.e., I reverted sys/boot/powerpc/Makefile.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > The TARGET_ARCH=3Dpowerpc build completed with the following messages = (from grep'ing for kboot in the typescript file): >=20 >> =3D=3D=3D> sys/boot/powerpc/kboot (all) >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o >> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' = is uninitialized when used here [-Wuninitialized] >> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the = variable 'sp' to silence this warning >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_fr= eebsd.o >> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' is invalid in C99 = [-Wimplicit-function-declaration] >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall= .o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.= o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o >> --- kbootfdt.o --- >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = 'const char *' to parameter of type 'char *' discards qualifiers = [-Wincompatible-pointer-types-discards-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/host_syscall.h:36:21: note: passing = argument to parameter 'path' here >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ucmpdi2.o >> In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/ucmpdi2.c:37: >> In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/quad.h:59: >> /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: "No user-serviceable parts inside." [-W#warnings] >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/boot.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/commands.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/console.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/devopen.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_backs= lash.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_parse= .o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ls.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/misc.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/module.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/panic.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf32.o= >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf32.= o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf64.o= >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf64.= o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/dev_net.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/disk.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/part.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/crc32.o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_forth= .o >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.kboot= >> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.help >=20 > The compiler involved was clang 3.8.0 . (This was a WITH_META_MODE=3Dyes= build.) >=20 > The TARGET_ARCH=3Dpowerpc64 build also completed. The compiler = involved was powerpc64-gcc. (This was a WITH_META_MODE=3Dyes build.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I just noticed at least one additional warning (for hostdisk.c) from the = TARGET_ARCH=3Dpowerpc64 so here is the list via grep for that context: > # grep kboot = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch= ain-amd64-host-2016-07-11:11:02:56 | grep -i warning: > /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' = [-Wimplicit-function-declaration] > /usr/src/sys/boot/powerpc/kboot/hostdisk.c:96:10: warning: format '%s' = expects argument of type 'char *', but argument 2 has type 'void *' = [-Wformat=3D] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = argument 1 of 'host_open' discards 'const' qualifier from pointer target = type [-Wdiscarded-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] > /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] > /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: #warning "No user-serviceable parts inside." [-Wcpp] > /usr/src/sys/boot/powerpc/kboot/../../common/ls.c:142:18: warning: = variable 'tail' set but not used [-Wunused-but-set-variable] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Mon Jul 11 19:54:09 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 239A9B9201B for ; Mon, 11 Jul 2016 19:54:09 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 15F12115D; Mon, 11 Jul 2016 19:54:09 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5A217167; Mon, 11 Jul 2016 19:54:09 +0000 (UTC) Date: Mon, 11 Jul 2016 19:54:07 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <765301092.32.1468266847895.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <458683891.31.1468256056555.JavaMail.jenkins@jenkins-9.freebsd.org> References: <458683891.31.1468256056555.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #306 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 19:54:09 -0000 See From owner-freebsd-stable@freebsd.org Mon Jul 11 20:51:35 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 149EDB92A82 for ; Mon, 11 Jul 2016 20:51:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 CC81D11DE for ; Mon, 11 Jul 2016 20:51:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7500 invoked from network); 11 Jul 2016 20:52:12 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Jul 2016 20:52:12 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 16:52:22 -0400 (EDT) Received: (qmail 27552 invoked from network); 11 Jul 2016 20:52:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jul 2016 20:52:22 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 0503C1C4075; Mon, 11 Jul 2016 13:51:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: stable/11 question: kboot vs. powerpc: only powerpc64? From: Mark Millard In-Reply-To: <5B3BC302-70DE-4FDA-A442-AC317E146B46@dsl-only.net> Date: Mon, 11 Jul 2016 13:51:31 -0700 Cc: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <43415D81-F83A-445A-9409-5771D2B858C4@dsl-only.net> References: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> <5783A3F5.2030301@freebsd.org> <73A6C8D3-6733-4E75-9C5C-59F8A5BB5039@dsl-only.net> <341B3611-39DD-4359-9A26-CE4781445D02@dsl-only.net> <5B3BC302-70DE-4FDA-A442-AC317E146B46@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 20:51:35 -0000 Quick top-post just to indicate that I just did gcc 4.2.1 based = cross-builds for TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 and = they completed. They had analogous warnings to what clang (powerpc) and = powerpc64-gcc (powerpc64) produced. I do not have a context to test powerpc64 or powerpc kboot in. I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change = that I tried. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jul-11, at 11:43 AM, Mark Millard = wrote: > On 2016-Jul-11, at 11:30 AM, Mark Millard = wrote: >=20 >> On 2016-Jul-11, at 11:04 AM, Mark Millard = wrote: >>=20 >>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn = wrote: >>>>=20 >>>> It is not 64-bit only; like the normal loader, it can load both = 32-bit and 64-bit kernels. Those two flags are probably obsolete at this = point and were for compatibility with pre-2.17.5 versions of binutils. = Can you do a test build with the -CFLAGS+=3D -Wa,-mppc64bridge line = removed? >>>> -Nathan >>>>=20 >>>> On 07/11/16 03:55, Mark Millard wrote: >>>>> Is the following something that should be updated something like = is indicated below for 11.0-BETA1? Is kboot powerpc64 specific? >>>>>=20 >>>>> # svnlite diff /usr/src/sys/boot/powerpc/Makefile >>>>> Index: /usr/src/sys/boot/powerpc/Makefile >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) >>>>> +++ /usr/src/sys/boot/powerpc/Makefile (working copy) >>>>> @@ -1,5 +1,9 @@ >>>>> # $FreeBSD$ >>>>> -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot >>>>> +SUBDIR=3D boot1.chrp >>>>> +.if ${MACHINE_ARCH} =3D=3D "powerpc64" >>>>> +SUBDIR+=3D kboot >>>>> +.endif >>>>> +SUBDIR+=3D ofw ps3 uboot >>>>> .include >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I ask because I'd submitted 206303 back on 2016-jan-16 reporting = that TARGET_ARCH=3Dpowerpc WITH_BOOT=3D was stopped by getting a = -Wc,-mppc64bride and a -mcpu=3Dpowerpc64 (one of the = base/head/sys/boot/powerpc/kboot/Makefile SRCS being = ppc64_elf_freebsd.c). >>>>>=20 >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> markmi at dsl-only.net >>>=20 >>> I do not have access to powerpc's currently so I'm just going to be = doing cross-build tests for TARGET_ARCH=3Dpowerpc and = TARGET_ARCH=3Dpowerpc64 (from amd64) based on the below updates. >>>=20 >>> You initially mention "two flags" but then only explicitly request = removal of one (the -CFLAGS+=3D -Wa,-mppc64bridge line). >>>=20 >>> I'm assuming that the -mcpu=3Dpowerpc64 is also to be removed if = powerpc (non-64) is to be covered. See my intended test below. Let me = know if it is not what you want.=20 >>>=20 >>>> # svnlite diff sys/boot/powerpc/kboot/Makefile >>>> Index: sys/boot/powerpc/kboot/Makefile >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/boot/powerpc/kboot/Makefile (revision 302457) >>>> +++ sys/boot/powerpc/kboot/Makefile (working copy) >>>> @@ -71,7 +71,7 @@ >>>> # Avoid the open-close-dance for every file access as some = firmwares perform >>>> # an auto-negotiation on every open of the network interface and = thus causes >>>> # netbooting to take horribly long. >>>> -CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE -mcpu=3Dpowerpc64 >>>> +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE >>>>=20 >>>> # Always add MI sources >>>> .PATH: ${.CURDIR}/../../common = ${.CURDIR}/../../../libkern >>>> @@ -88,9 +88,6 @@ >>>>=20 >>>> LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc >>>>=20 >>>> -# 64-bit bridge extensions >>>> -CFLAGS+=3D -Wa,-mppc64bridge >>>> - >>>> # Pull in common loader code >>>> #.PATH: ${.CURDIR}/../../ofw/common >>>> #.include "${.CURDIR}/../../ofw/common/Makefile.inc" >>>=20 >>>> # svnlite diff sys/boot/powerpc/Makefile >>>> #=20 >>>=20 >>> (I.e., I reverted sys/boot/powerpc/Makefile.) >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> The TARGET_ARCH=3Dpowerpc build completed with the following messages = (from grep'ing for kboot in the typescript file): >>=20 >>> =3D=3D=3D> sys/boot/powerpc/kboot (all) >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o >>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable = 'sp' is uninitialized when used here [-Wuninitialized] >>> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the = variable 'sp' to silence this warning >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_fr= eebsd.o >>> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' is invalid in C99 = [-Wimplicit-function-declaration] >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall= .o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.= o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o >>> --- kbootfdt.o --- >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = 'const char *' to parameter of type 'char *' discards qualifiers = [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/host_syscall.h:36:21: note: passing = argument to parameter 'path' here >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ucmpdi2.o >>> In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/ucmpdi2.c:37: >>> In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/quad.h:59: >>> /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: "No user-serviceable parts inside." [-W#warnings] >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/boot.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/commands.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/console.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/devopen.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_backs= lash.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_parse= .o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ls.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/misc.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/module.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/panic.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf32.o= >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf32.= o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf64.o= >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf64.= o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/dev_net.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/disk.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/part.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/crc32.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_forth= .o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.kboot= >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.help >>=20 >> The compiler involved was clang 3.8.0 . (This was a = WITH_META_MODE=3Dyes build.) >>=20 >> The TARGET_ARCH=3Dpowerpc64 build also completed. The compiler = involved was powerpc64-gcc. (This was a WITH_META_MODE=3Dyes build.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > I just noticed at least one additional warning (for hostdisk.c) from = the TARGET_ARCH=3Dpowerpc64 so here is the list via grep for that = context: >=20 >> # grep kboot = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch= ain-amd64-host-2016-07-11:11:02:56 | grep -i warning: >> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' = [-Wimplicit-function-declaration] >> /usr/src/sys/boot/powerpc/kboot/hostdisk.c:96:10: warning: format = '%s' expects argument of type 'char *', but argument 2 has type 'void *' = [-Wformat=3D] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = argument 1 of 'host_open' discards 'const' qualifier from pointer target = type [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: #warning "No user-serviceable parts inside." [-Wcpp] >> /usr/src/sys/boot/powerpc/kboot/../../common/ls.c:142:18: warning: = variable 'tail' set but not used [-Wunused-but-set-variable] >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-stable@freebsd.org Mon Jul 11 21:10:16 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17AC7B92221 for ; Mon, 11 Jul 2016 21:10:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 CE6281165 for ; Mon, 11 Jul 2016 21:10:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14883 invoked from network); 11 Jul 2016 21:10:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Jul 2016 21:10:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 17:10:09 -0400 (EDT) Received: (qmail 29898 invoked from network); 11 Jul 2016 21:10:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Jul 2016 21:10:09 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 515451C4075; Mon, 11 Jul 2016 14:10:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: stable/11 question: kboot vs. powerpc: only powerpc64? From: Mark Millard In-Reply-To: <43415D81-F83A-445A-9409-5771D2B858C4@dsl-only.net> Date: Mon, 11 Jul 2016 14:10:12 -0700 Cc: FreeBSD PowerPC ML , freebsd-stable@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <07312336-F627-4372-AEF2-5FA93CF6E4CD@dsl-only.net> <5783A3F5.2030301@freebsd.org> <73A6C8D3-6733-4E75-9C5C-59F8A5BB5039@dsl-only.net> <341B3611-39DD-4359-9A26-CE4781445D02@dsl-only.net> <5B3BC302-70DE-4FDA-A442-AC317E146B46@dsl-only.net> <43415D81-F83A-445A-9409-5771D2B858C4@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:10:16 -0000 On 2016-Jul-11, at 1:51 PM, Mark Millard wrote: > Quick top-post just to indicate that I just did gcc 4.2.1 based = cross-builds for TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 and = they completed. They had analogous warnings to what clang (powerpc) and = powerpc64-gcc (powerpc64) produced. >=20 > I do not have a context to test powerpc64 or powerpc kboot in. >=20 > I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change = that I tried. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I've updated 206303 ( = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206303 ) with = Comment 2 and 206303's Version is now set to 11.0-BETA1 since the odd = powerpc64 options are present in 11.0-BETA1 (-r302457 is where I'm = currently synchronized to). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jul-11, at 11:43 AM, Mark Millard = wrote: > On 2016-Jul-11, at 11:30 AM, Mark Millard = wrote: >=20 >> On 2016-Jul-11, at 11:04 AM, Mark Millard = wrote: >>=20 >>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn = wrote: >>>>=20 >>>> It is not 64-bit only; like the normal loader, it can load both = 32-bit and 64-bit kernels. Those two flags are probably obsolete at this = point and were for compatibility with pre-2.17.5 versions of binutils. = Can you do a test build with the -CFLAGS+=3D -Wa,-mppc64bridge line = removed? >>>> -Nathan >>>>=20 >>>> On 07/11/16 03:55, Mark Millard wrote: >>>>> Is the following something that should be updated something like = is indicated below for 11.0-BETA1? Is kboot powerpc64 specific? >>>>>=20 >>>>> # svnlite diff /usr/src/sys/boot/powerpc/Makefile >>>>> Index: /usr/src/sys/boot/powerpc/Makefile >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- /usr/src/sys/boot/powerpc/Makefile (revision 302457) >>>>> +++ /usr/src/sys/boot/powerpc/Makefile (working copy) >>>>> @@ -1,5 +1,9 @@ >>>>> # $FreeBSD$ >>>>> -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot >>>>> +SUBDIR=3D boot1.chrp >>>>> +.if ${MACHINE_ARCH} =3D=3D "powerpc64" >>>>> +SUBDIR+=3D kboot >>>>> +.endif >>>>> +SUBDIR+=3D ofw ps3 uboot >>>>> .include >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I ask because I'd submitted 206303 back on 2016-jan-16 reporting = that TARGET_ARCH=3Dpowerpc WITH_BOOT=3D was stopped by getting a = -Wc,-mppc64bride and a -mcpu=3Dpowerpc64 (one of the = base/head/sys/boot/powerpc/kboot/Makefile SRCS being = ppc64_elf_freebsd.c). >>>>>=20 >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> markmi at dsl-only.net >>>=20 >>> I do not have access to powerpc's currently so I'm just going to be = doing cross-build tests for TARGET_ARCH=3Dpowerpc and = TARGET_ARCH=3Dpowerpc64 (from amd64) based on the below updates. >>>=20 >>> You initially mention "two flags" but then only explicitly request = removal of one (the -CFLAGS+=3D -Wa,-mppc64bridge line). >>>=20 >>> I'm assuming that the -mcpu=3Dpowerpc64 is also to be removed if = powerpc (non-64) is to be covered. See my intended test below. Let me = know if it is not what you want.=20 >>>=20 >>>> # svnlite diff sys/boot/powerpc/kboot/Makefile >>>> Index: sys/boot/powerpc/kboot/Makefile >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/boot/powerpc/kboot/Makefile (revision 302457) >>>> +++ sys/boot/powerpc/kboot/Makefile (working copy) >>>> @@ -71,7 +71,7 @@ >>>> # Avoid the open-close-dance for every file access as some = firmwares perform >>>> # an auto-negotiation on every open of the network interface and = thus causes >>>> # netbooting to take horribly long. >>>> -CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE -mcpu=3Dpowerpc64 >>>> +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE >>>>=20 >>>> # Always add MI sources >>>> .PATH: ${.CURDIR}/../../common = ${.CURDIR}/../../../libkern >>>> @@ -88,9 +88,6 @@ >>>>=20 >>>> LDFLAGS=3D -nostdlib -static -T ${.CURDIR}/ldscript.powerpc >>>>=20 >>>> -# 64-bit bridge extensions >>>> -CFLAGS+=3D -Wa,-mppc64bridge >>>> - >>>> # Pull in common loader code >>>> #.PATH: ${.CURDIR}/../../ofw/common >>>> #.include "${.CURDIR}/../../ofw/common/Makefile.inc" >>>=20 >>>> # svnlite diff sys/boot/powerpc/Makefile >>>> #=20 >>>=20 >>> (I.e., I reverted sys/boot/powerpc/Makefile.) >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> The TARGET_ARCH=3Dpowerpc build completed with the following messages = (from grep'ing for kboot in the typescript file): >>=20 >>> =3D=3D=3D> sys/boot/powerpc/kboot (all) >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o >>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable = 'sp' is uninitialized when used here [-Wuninitialized] >>> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the = variable 'sp' to silence this warning >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_fr= eebsd.o >>> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' is invalid in C99 = [-Wimplicit-function-declaration] >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall= .o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.= o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o >>> --- kbootfdt.o --- >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = 'const char *' to parameter of type 'char *' discards qualifiers = [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/host_syscall.h:36:21: note: passing = argument to parameter 'path' here >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assigning = to 'uint64_t *' (aka 'unsigned long long *') from 'const void *' = discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assigning = to 'uint32_t *' (aka 'unsigned int *') from 'const void *' discards = qualifiers [-Wincompatible-pointer-types-discards-qualifiers] >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ucmpdi2.o >>> In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/ucmpdi2.c:37: >>> In file included from = /usr/src/sys/boot/powerpc/kboot/../../../libkern/quad.h:59: >>> /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: "No user-serviceable parts inside." [-W#warnings] >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/boot.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/commands.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/console.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/devopen.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_backs= lash.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_parse= .o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ls.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/misc.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/module.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/panic.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf32.o= >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf32.= o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/load_elf64.o= >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/reloc_elf64.= o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/dev_net.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/disk.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/part.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/crc32.o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/interp_forth= .o >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.kboot= >>> Building = /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/loader.help >>=20 >> The compiler involved was clang 3.8.0 . (This was a = WITH_META_MODE=3Dyes build.) >>=20 >> The TARGET_ARCH=3Dpowerpc64 build also completed. The compiler = involved was powerpc64-gcc. (This was a WITH_META_MODE=3Dyes build.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > I just noticed at least one additional warning (for hostdisk.c) from = the TARGET_ARCH=3Dpowerpc64 so here is the list via grep for that = context: >=20 >> # grep kboot = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolch= ain-amd64-host-2016-07-11:11:02:56 | grep -i warning: >> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: = implicit declaration of function 'md_load64' = [-Wimplicit-function-declaration] >> /usr/src/sys/boot/powerpc/kboot/hostdisk.c:96:10: warning: format = '%s' expects argument of type 'char *', but argument 2 has type 'void *' = [-Wformat=3D] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing = argument 1 of 'host_open' discards 'const' qualifier from pointer target = type [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:123:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:125:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:134:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:135:8: warning: assignment = discards 'const' qualifier from pointer target type = [-Wdiscarded-qualifiers] >> /usr/src/sys/boot/powerpc/kboot/../../../sys/syslimits.h:41:2: = warning: #warning "No user-serviceable parts inside." [-Wcpp] >> /usr/src/sys/boot/powerpc/kboot/../../common/ls.c:142:18: warning: = variable 'tail' set but not used [-Wunused-but-set-variable] >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-stable@freebsd.org Mon Jul 11 21:45:14 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 762DBB92EAC for ; Mon, 11 Jul 2016 21:45:14 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 587621C9B for ; Mon, 11 Jul 2016 21:45:14 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ddb98150-47b0-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 11 Jul 2016 21:46:03 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6BLjBKD004380; Mon, 11 Jul 2016 15:45:11 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468273511.72182.131.camel@freebsd.org> Subject: Re: Not-so stable if you take a CAM error.... From: Ian Lepore To: Karl Denninger , freebsd-stable@freebsd.org Date: Mon, 11 Jul 2016 15:45:11 -0600 In-Reply-To: <21f3f685-4618-e258-0538-75602608cf9b@denninger.net> References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <1468254746.72182.121.camel@freebsd.org> <1468258789.72182.122.camel@freebsd.org> <21f3f685-4618-e258-0538-75602608cf9b@denninger.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:45:14 -0000 On Mon, 2016-07-11 at 12:44 -0500, Karl Denninger wrote: > On 7/11/2016 12:39, Ian Lepore wrote: > > On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote: > > > On 7/11/2016 11:32, Ian Lepore wrote: > > > > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote: > > > > > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger < > > > > > karl@denninger.net> > > > > > wrote: > > > > > > > > > > > Here's the backtrace ... sounds like expected behavior, > > > > > > which > > > > > > is > > > > > > not-so > > > > > > good all-in for a situation like this. I guess the > > > > > > strategy is > > > > > > to > > > > > > turn > > > > > > off softupdates before attempting such an update so as not > > > > > > to > > > > > > crash > > > > > > the > > > > > > host machine if there's a problem with the card. > > > > > > > > > > > I would tend to assume that removable media should not have > > > > > softupdates > > > > > enabled. Even with properly working media, it's practically > > > > > begging > > > > > for > > > > > corruption. > > > > > > > > > Writing to an sdcard without softupdates enabled will be an > > > > exercise in > > > > patience. Like, come back next week and maybe it'll be done. > > > > > > > > The only thing that comes to mind with this is maybe some sort > > > > of > > > > mount > > > > flag to say you're willing to live with any amount of > > > > filesystem > > > > corruption in lieu of panicking. I'm not sure how > > > > easy/practical > > > > that > > > > would be to implement, though. > > > > > > > > -- Ian > > > Why not force-detach the volume that takes the error instead of a > > > panic()? > > > > > Patches welcome. > > > > -- Ian > Any hints on where the routine(s) live that would forcibly detach a > volume? (I'll go digging as well but shortening the time would help > :)) > Your question assumes the existance of code that I don't know actually exists. Plug in any removable drive (like a usb thumb drive) and mount a ufs filesystem with softupdates enabled, then remove the drive while writing to it. Panic. I've always assumed that if this was easily fixable it would have been fixed long ago, and if it was fixable at all it would have been fixed by now. (Although increasingly it seems that ufs has transitioned to second-class citizenship, and lately I've even seen people mocked for using it instead of zfs). -- Ian From owner-freebsd-stable@freebsd.org Tue Jul 12 01:58:18 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBEC9B8473E for ; Tue, 12 Jul 2016 01:58:18 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DE29D19FC; Tue, 12 Jul 2016 01:58:18 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1E0DB171; Tue, 12 Jul 2016 01:58:19 +0000 (UTC) Date: Tue, 12 Jul 2016 01:58:19 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1633372231.37.1468288699039.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <765301092.32.1468266847895.JavaMail.jenkins@jenkins-9.freebsd.org> References: <765301092.32.1468266847895.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #307 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 01:58:19 -0000 See From owner-freebsd-stable@freebsd.org Tue Jul 12 02:44:32 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08CB8B85CD6 for ; Tue, 12 Jul 2016 02:44:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (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 B299B100F for ; Tue, 12 Jul 2016 02:44:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28097 invoked from network); 12 Jul 2016 02:45:06 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Jul 2016 02:45:06 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 11 Jul 2016 22:44:35 -0400 (EDT) Received: (qmail 9173 invoked from network); 12 Jul 2016 02:44:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Jul 2016 02:44:35 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 864B81C405F; Mon, 11 Jul 2016 19:44:23 -0700 (PDT) From: Mark Millard Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly] Date: Mon, 11 Jul 2016 19:44:28 -0700 Message-Id: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> Cc: Bruce Evans To: svn-src-head@freebsd.org, ache@FreeBSD.org, FreeBSD Current , freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 02:44:32 -0000 https://lists.freebsd.org/pipermail/svn-src-head/2016-July/088998.html = shows: > Modified: head/sys/arm/include/_types.h > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/arm/include/_types.h Mon Jul 11 23:15:54 2016 = (r302600) > +++ head/sys/arm/include/_types.h Tue Jul 12 00:37:48 2016 = (r302601) > @@ -107,7 +107,7 @@ typedef __uint32_t __vm_size_t; > =20 > typedef unsigned int ___wchar_t; > #define __WCHAR_MIN 0 /* min value for a = wchar_t */ > -#define __WCHAR_MAX __UINT_MAX /* max value for a = wchar_t */ > +#define __WCHAR_MAX __INT_MAX /* max for a wchar_t <=3D = WINT_MAX */ > =20 > /* > * Unusual type definitions. >=20 > Modified: head/sys/arm64/include/_types.h > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/arm64/include/_types.h Mon Jul 11 23:15:54 2016 = (r302600) > +++ head/sys/arm64/include/_types.h Tue Jul 12 00:37:48 2016 = (r302601) > @@ -95,7 +95,7 @@ typedef __uint64_t __vm_size_t; > typedef unsigned int ___wchar_t; > =20 > #define __WCHAR_MIN 0 /* min value for a = wchar_t */ > -#define __WCHAR_MAX __UINT_MAX /* max value for a = wchar_t */ > +#define __WCHAR_MAX __INT_MAX /* max for a wchar_t <=3D = WINT_MAX */ > =20 > /* > * Unusual type definitions. My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of = ___wchar_t (if that is distinct). B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not = necessarily a valid char value C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not = necessarily a valid char value (A) and (C) seem to be violated here for __WHAR_MAX if I'm right about = (A)-(C). [I'm not sure sure that (A)'s violation for __WCHAR_MIN here = matters much if I got that combination right.] As far as I know arm FreeBSD uses unsigned character types (of whatever = width). There is also at least one past example of Bruce Evans not objecting to = __UINT_MAX for __WCHAR_MAX for arm: https://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012721.html = has his only comment being. . . > % +#ifdef __ARM_EABI__ > % +#define __WCHAR_MIN (0) >=20 > Bogus parentheses. >=20 > % +#define __WCHAR_MAX __UINT_MAX (The definitions were in a different file back then, leading to the = ifdef use.) You may want to check with Bruce Evans. He has good coverage of the = various standards to be covered (that may not all agree and how/what = FreeBSD then picks). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Tue Jul 12 03:58:08 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 591F2B925E7 for ; Tue, 12 Jul 2016 03:58:08 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB64015C3 for ; Tue, 12 Jul 2016 03:58:07 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f54.google.com with SMTP id b199so2388592lfe.0 for ; Mon, 11 Jul 2016 20:58:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0nhk2KkMaPDyZ2vaCh68ir713TZduRu8jgFYJ3rUklI=; b=E8Ku5ElFxp7V/z+NLTk7dHRBYkzA2SwaMzajvCAqRpKtQDyFcBdhWjVrF1ArZWwHno nkVxhOHJBSUgo+/MoxBuHdVE2MSFsNBGFMrEC40KxpilT69lcishjmZb5+u35WqjFvnq RvIBnZXUWYw34ra45WKuO6IOvtNEWr68mZjWNmKqQ1yymcwqRHaRBt/uvL11KQoCFFQv r7qFfm4LtLrMqOI+2LeUWp9tVb41dSgYsDvAWzh2yH/SMY83EsFLt2Q2k2YYIWF1jdmc /q/d9enTx+1fJ7BtxQB1r5FSleiRdJHAb0F+TQ/kSEEnlvHY0MJDODytSuCCC7r9kxuv HaPQ== X-Gm-Message-State: ALyK8tIALrrfaVltEymENnM+aGqWTw6zlX5G+EJZ5re6nxvEA2Dztbx2V4MtFo/9SPpn5g== X-Received: by 10.25.38.213 with SMTP id m204mr22723lfm.107.1468295880295; Mon, 11 Jul 2016 20:58:00 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id r190sm1279323lfg.49.2016.07.11.20.57.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 20:57:59 -0700 (PDT) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly] To: Mark Millard , svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> Cc: Bruce Evans From: Andrey Chernov Message-ID: Date: Tue, 12 Jul 2016 06:57:58 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 03:58:08 -0000 On 12.07.2016 5:44, Mark Millard wrote: > My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: > > A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of > ___wchar_t (if that is distinct). > B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not > necessarily a valid char value > C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not > necessarily a valid char value It seems you are right about "not a valid char value", I'll back this change out. > As far as I know arm FreeBSD uses unsigned character types (of whatever > width). Probably it should be unsigned for other architectures too, clang does not generate negative values with L'' literals and locale use only positive values too. From owner-freebsd-stable@freebsd.org Tue Jul 12 08:08:07 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 068A7B9385D for ; Tue, 12 Jul 2016 08:08:07 +0000 (UTC) (envelope-from bounce_FokWuZ8rV5rX7obd_4UqrJjwkknMQ2VWX_759c263328e4df83_3@yomoko-mail.com) Received: from s2.mtb-3.com (s2.mtb-3.com [69.63.148.88]) (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 83C2B19FC for ; Tue, 12 Jul 2016 08:08:06 +0000 (UTC) (envelope-from bounce_FokWuZ8rV5rX7obd_4UqrJjwkknMQ2VWX_759c263328e4df83_3@yomoko-mail.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mykey2; d=mtb-3.com; h=Reply-To:List-Unsubscribe:From:To:Subject:MIME-Version:Date:Message-Id:Content-Type; bh=jmCSUvI4gHOKk1zv2hKTQYz2pAE=; b=GQ6XehcVPII8jTbYRvEZ73EbbWt6Qi2dVlVkmTRNphaI4E1YHkZ3+304wt4dE5eyaFt0yWkdgNFW ntHH+sXntHoqX1fYiBQnQp+9tfevVVkuNfcWE6wqsTedlsHjeOP+z2wd5Ypvy3QtDTXVI60MPktV Jilxl+Q8D+ZeCfKqxVv57x5/SkL0MxH+5eyV02f7hbEyK4AHYhL9Pt4BlPuSiUZwB/Lvhz3oKjWD 6ojLA0x7UvETrE4TuL/cquYld4eHQvpyKbq+6ahMHyYXjbhNMAwKnlLCdjRUh8pYm0ishwopYHSj bi9TG9z+eQC5oStK4snWB0FPsF8vaBgGErBSZQ== Received: from localhost (10.10.204.18) by s2.mtb-3.com id hgiimc27la89 for ; Tue, 12 Jul 2016 09:12:36 +0200 (envelope-from ) Reply-To: mala.augustine@educor.co.za X-Priority: 3 X-Report-Abuse: X-Data: 4UqrJjwkknMQ2VWX.759c263328e4df83 X-Data-EUID: 60fc35abe270e6bd870760efc7821468 X-Data-Rating: -2 From: Damelin To: freebsd-stable@freebsd.org Subject: Join the School of Business Professionals MIME-Version: 1.0 Date: Tue, 12 Jul 2016 09:12:02 +0200 Message-Id: <201607129091236.29478.1163@dcc.edu.za> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:08:07 -0000 School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) School of Business Professionals ( https://www.dcc.edu.za/mailer-campaign/business-professionals ) From owner-freebsd-stable@freebsd.org Tue Jul 12 14:23:06 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A694BB92B25 for ; Tue, 12 Jul 2016 14:23:06 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9174E1159 for ; Tue, 12 Jul 2016 14:23:06 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: by mailman.ysv.freebsd.org (Postfix) id 90CF7B92B24; Tue, 12 Jul 2016 14:23:06 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 907DEB92B22 for ; Tue, 12 Jul 2016 14:23:06 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0501156 for ; Tue, 12 Jul 2016 14:23:06 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from lowell-desk.lan (router.lan [172.30.250.2]) by be-well.ilk.org (Postfix) with ESMTP id 3284D33C1E for ; Tue, 12 Jul 2016 10:22:53 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id E771139819; Tue, 12 Jul 2016 10:22:52 -0400 (EDT) From: Lowell Gilbert To: stable@freebsd.org Subject: Re: Not-so stable if you take a CAM error.... References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <1468254746.72182.121.camel@freebsd.org> Date: Tue, 12 Jul 2016 10:22:52 -0400 In-Reply-To: (Karl Denninger's message of "Mon, 11 Jul 2016 12:30:34 -0500") Message-ID: <447fcrdjgj.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:23:06 -0000 Karl Denninger writes: > Why not force-detach the volume that takes the error instead of a panic()? > > That would lead to a panic if the detached volume was the system volume > (obviously) but for a data volume it would simply result in it being > forcibly unmounted (and dirty, so if it's corrupt it will get caught > when reattached.) > > It seems that the current paradigm of saying "screw you, panic the > machine" violates the principle of least astonishment and is overly > punitive vis-a-vis necessity. Refusing further I/O because the volume > may now have a corrupt filesystem appears to be facially reasonable, but > that doesn't necessarily wind up being fatal the system itself -- it is > if that's the system volume and is not covered by some sort of > redundancy, obviously, but it's not in all cases. How do you find the processes with pages mapped from the filesystem's vnodes? UFS is *very* tightly tied to the VM system, and intentionally so. Recall that "umount -f" isn't exactly safe... From owner-freebsd-stable@freebsd.org Tue Jul 12 14:30:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6467BB92E00 for ; Tue, 12 Jul 2016 14:30:21 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 20073168E for ; Tue, 12 Jul 2016 14:30:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 8C0A9224D7D for ; Tue, 12 Jul 2016 09:30:13 -0500 (CDT) Subject: Re: Not-so stable if you take a CAM error.... To: freebsd-stable@freebsd.org References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <1468254746.72182.121.camel@freebsd.org> <447fcrdjgj.fsf@lowell-desk.lan> From: Karl Denninger Message-ID: Date: Tue, 12 Jul 2016 09:29:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <447fcrdjgj.fsf@lowell-desk.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020403070605050607000501" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:30:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020403070605050607000501 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/12/2016 09:22, Lowell Gilbert wrote: > Karl Denninger writes: > >> Why not force-detach the volume that takes the error instead of a pani= c()? >> >> That would lead to a panic if the detached volume was the system volum= e >> (obviously) but for a data volume it would simply result in it being >> forcibly unmounted (and dirty, so if it's corrupt it will get caught >> when reattached.) >> >> It seems that the current paradigm of saying "screw you, panic the >> machine" violates the principle of least astonishment and is overly >> punitive vis-a-vis necessity. Refusing further I/O because the volume= >> may now have a corrupt filesystem appears to be facially reasonable, b= ut >> that doesn't necessarily wind up being fatal the system itself -- it i= s >> if that's the system volume and is not covered by some sort of >> redundancy, obviously, but it's not in all cases. > How do you find the processes with pages mapped from the filesystem's > vnodes? UFS is *very* tightly tied to the VM system, and intentionally > so. Recall that "umount -f" isn't exactly safe... > _______________________________________________ You don't. If you wind up detaching something with open RSS pages (or worse, page file pages) you're going to take a panic. So what? You're no worse off than you are with what is done now. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020403070605050607000501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTIxNDI5NDZaME8GCSqGSIb3DQEJBDFCBECw 8o6XFpSa/et/b8mFFdbDPSvC0EGARmLYkOTfr+FW3r6kSKhL9KXGMPLERNn2z8yPLhOeadO9 jeSEc061WlAzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAY1u8ncC+ DFOtk51eL2Bf/7hqbkXx+b2hkoYsTsDYic5fmW36seHm52u3Vb/9klXVsoCR+Yw4wJIEEPqE Gvlk92Bta9qJNvMI8DhomeW7YluacrkqSZJ/ZdoqFl0FLr1o58jXG7YYTUXIy+sDwO5yXuRu S8KilZQPEgru4ZGP0Hc4qmKc8WDDx2isqGJ8VeMA3mdePjeU7EUyqOU7cU7QEztEgAWf71Bb xcawRBJ6vgSLlToYuLzXUKwdypg+40kwrqmuL+2H8D/N+/H1SngJRojOL1oxmkp3EfX5vT9X KbyozhfgS74b+vrTAzIjpw+8cw/RS12jimwogvzKMvKHHMBMIw9wBkTcqXb98FvLpsQY+hQx 4/U3jpf4fbrdNv3IkwmAanNOc2dKmt6j0OruE7YoG260VyUhYvCAbfEgXeRXqpAiAecoKE7M nDl+IyKvRPzRqNewTc63U6CKUWUtwD+kRF8etVUPwyjt0w7NSsMvHOTpOEhWHeEn67frqDvV Ugt1wa4NydrUXlsaLKdl3IFESnd7xFve1f6A33mM3M88TBC7CJs5lLw0Nb4kU1OQbgHDs+uY gX1p4gOP9moGC7+TynRbHajkHQ8lHPhU4iYWFJlII+V6JsRFoXk7uXJfhK6IAE8nNM+o/baq He0PTFrspLkrxiSWfkfG/g8dJ88AAAAAAAA= --------------ms020403070605050607000501-- From owner-freebsd-stable@freebsd.org Tue Jul 12 20:02:29 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42D21B93F29 for ; Tue, 12 Jul 2016 20:02:29 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [67.213.65.194]) (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 CB37516E2 for ; Tue, 12 Jul 2016 20:02:28 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (localhost [127.0.0.1]) by mail.intertainservices.com (Postfix) with ESMTP id 820E256491 for ; Tue, 12 Jul 2016 15:52:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intertainservices.com; s=mail; t=1468353177; bh=qOeMy29l5cy/N+L9x9ylhFyVIaKJLJgyMfZjjBjLLQs=; h=Date:From:To:Subject; b=mbhk529TC7nsQQ2cK3/Ywoy729zDqv0WpBSJymcQwyDL86bXsK/9I/GwKzpT8A/nf DhXqJCynYzWzHJU2ZVFla4+yjmuYLmgBI7y69ffROEGS2uCsVCLQPR03JZainwgutJ qJVklen1jV3HViEFysYxy7ANJuG9uz/O7azaewQ4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Jul 2016 15:52:57 -0400 From: Mike Jakubik To: freebsd-stable@freebsd.org Subject: r302669 GENERIC panicking on Amazon EC2 Organization: Intertainservices Message-ID: <7fd09035be22e5f8b76d2f9e29a04fd6@intertainservices.com> X-Sender: mike.jakubik@intertainservices.com User-Agent: Roundcube Webmail/1.1.5 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 820E256491.AEC27 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 20:02:29 -0000 Hello, I just did a svn update to stable/10 recompiled world/kernel using GENERIC kernel and i am unable to boot this kernel on Amazon EC2 now. Thanks. Booting [/boot/kernel/kernel]... |/-\|Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.3-STABLE #0 r302669: Tue Jul 12 15:42:24 EDT 2016 ec2-user@webmail.xxx.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 XEN: Hypervisor version 4.2 detected. CPU: Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (2400.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Features=0x1783fbff Features2=0xfffa3203 AMD Features=0x28100800 AMD Features2=0x21 Structured Extended Features=0x728 XSAVE Features=0x1 Hypervisor: Origin = "XenVMMXenVMM" real memory = 8589934592 (8192 MB) avail memory = 8284352512 (7900 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 random: initialized ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard kernel trap 9 with interrupts disabled kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80e8b5cb stack pointer = 0x28:0xffffffff819de6c0 frame pointer = 0x28:0xffffffff819de740 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 (swapper) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80991970 at kdb_backtrace+0x60 #1 0xffffffff809545b7 at vpanic+0x127 #2 0xffffffff80954483 at panic+0x43 #3 0xffffffff80d5d6d9 at trap_fatal+0x379 #4 0xffffffff80d5d9dd at trap_pfault+0x2ed #5 0xffffffff80d5d04a at trap+0x47a #6 0xffffffff80d4317c at calltrap+0x8 #7 0xffffffff80d43e9c at Xxen_intr_upcall+0x8c #8 0xffffffff80d4317c at calltrap+0x8 #9 0xffffffff80e85fa4 at apic_setup_io+0x54 #10 0xffffffff808fac48 at mi_startup+0x108 #11 0xffffffff802e225c at btext+0x2c Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort From owner-freebsd-stable@freebsd.org Wed Jul 13 01:10:53 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA2F6B92D1A for ; Wed, 13 Jul 2016 01:10:53 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8F367159E; Wed, 13 Jul 2016 01:10:53 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8F77E1A6; Wed, 13 Jul 2016 01:10:53 +0000 (UTC) Date: Wed, 13 Jul 2016 01:10:53 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1283381284.53.1468372253526.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1633372231.37.1468288699039.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1633372231.37.1468288699039.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #308 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 01:10:53 -0000 See ------------------------------------------ [...truncated 316499 lines...] Etc/GMT+5 Etc/GMT+6 Etc/GMT+7 Etc/GMT+8 Etc/GMT+9 Etc/GMT-0 Etc/GMT-1 Etc/GMT-10 Etc/GMT-11 Etc/GMT-12 Etc/GMT-13 Etc/GMT-14 Etc/GMT-2 Etc/GMT-3 Etc/GMT-4 Etc/GMT-5 Etc/GMT-6 Etc/GMT-7 Etc/GMT-8 Etc/GMT-9 Etc/GMT0 Etc/Greenwich Etc/UCT Etc/UTC Etc/Universal Etc/Zulu Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Busingen Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Guernsey Europe/Helsinki Europe/Isle_of_Man Europe/Istanbul Europe/Jersey Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/Ljubljana Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Mariehamn Europe/Minsk Europe/Monaco Europe/Moscow Europe/Nicosia Europe/Oslo Europe/Paris Europe/Podgorica Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/San_Marino Europe/Sarajevo Europe/Simferopol Europe/Skopje Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Uzhgorod Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Vilnius Europe/Volgograd Europe/Warsaw Europe/Zagreb Europe/Zaporozhye Europe/Zurich Factory HST Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion MET MST MST7MDT PST8PDT Pacific/Apia Pacific/Auckland Pacific/Bougainville Pacific/Chatham Pacific/Chuuk Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Johnston Pacific/Kiritimati Pacific/Kosrae Pacific/Kwajalein Pacific/Majuro Pacific/Marquesas Pacific/Midway Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Pohnpei Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Wake Pacific/Wallis UTC WET posixrules install -o root -g wheel -m 444 /builds/workspace/FreeBSD_stable_10/src/sh= are/zoneinfo/../../contrib/tzdata//zone.tab /builds/workspace/FreeBSD_stabl= e_10/package/src/usr/share/zoneinfo/ Run tzsetup(8) manually to update /etc/localtime. =3D=3D=3D> sys (install) =3D=3D=3D> sys/boot (install) =3D=3D=3D> sys/boot/ficl (install) =3D=3D=3D> sys/boot/forth (install) install -o root -g wheel -m 444 beastie.4th.8.gz /builds/workspace/FreeBSD= _stable_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 brand.4th.8.gz /builds/workspace/FreeBSD_s= table_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 check-password.4th.8.gz /builds/workspace/= FreeBSD_stable_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 color.4th.8.gz /builds/workspace/FreeBSD_s= table_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 delay.4th.8.gz /builds/workspace/FreeBSD_s= table_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 loader.conf.5.gz /builds/workspace/FreeBSD= _stable_10/package/src/usr/share/man/man5 install -o root -g wheel -m 444 loader.4th.8.gz /builds/workspace/FreeBSD_= stable_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 menu.4th.8.gz /builds/workspace/FreeBSD_st= able_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 menusets.4th.8.gz /builds/workspace/FreeBS= D_stable_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 version.4th.8.gz /builds/workspace/FreeBSD= _stable_10/package/src/usr/share/man/man8 =3D=3D=3D> sys/boot/efi (install) =3D=3D=3D> sys/boot/efi/libefi (install) =3D=3D=3D> sys/boot/efi/loader (install) install -o root -g wheel -m 555 loader.efi /builds/workspace/FreeBSD_sta= ble_10/package/src/boot/loader.efi install -o root -g wheel -m 444 loader.8.gz /builds/workspace/FreeBSD_stab= le_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 zfsloader.8.gz /builds/workspace/FreeBSD_s= table_10/package/src/usr/share/man/man8 =3D=3D=3D> sys/boot/efi/boot1 (install) install -o root -g wheel -m 555 boot1.efi /builds/workspace/FreeBSD_stab= le_10/package/src/boot/boot1.efi install -o root -g wheel -m 444 boot1.efifat /builds/workspace/FreeBSD_sta= ble_10/package/src/boot =3D=3D=3D> sys/boot/libstand32 (install) =3D=3D=3D> sys/boot/zfs (install) =3D=3D=3D> sys/boot/userboot (install) =3D=3D=3D> sys/boot/userboot/ficl (install) =3D=3D=3D> sys/boot/userboot/libstand (install) =3D=3D=3D> sys/boot/userboot/test (install) =3D=3D=3D> sys/boot/userboot/zfs (install) =3D=3D=3D> sys/boot/userboot/userboot (install) install -o root -g wheel -m 444 userboot.so /builds/workspace/FreeBSD_= stable_10/package/src/boot install -o root -g wheel -m 444 loader.8.gz /builds/workspace/FreeBSD_stab= le_10/package/src/usr/share/man/man8 install -o root -g wheel -m 444 zfsloader.8.gz /builds/workspace/FreeBSD_s= table_10/package/src/usr/share/man/man8 =3D=3D=3D> sys/boot/ficl32 (install) =3D=3D=3D> sys/boot/i386 (install) =3D=3D=3D> sys/boot/i386/mbr (install) install -o root -g wheel -m 444 mbr /builds/workspace/FreeBSD_stable_10/= package/src/boot/mbr =3D=3D=3D> sys/boot/i386/pmbr (install) install -o root -g wheel -m 444 pmbr /builds/workspace/FreeBSD_stable_10= /package/src/boot/pmbr =3D=3D=3D> sys/boot/i386/boot0 (install) install -o root -g wheel -m 444 boot0 /builds/workspace/FreeBSD_stable_1= 0/package/src/boot/boot0 =3D=3D=3D> sys/boot/i386/boot0sio (install) install -o root -g wheel -m 444 boot0 /builds/workspace/FreeBSD_stable_1= 0/package/src/boot/boot0sio =3D=3D=3D> sys/boot/i386/btx (install) =3D=3D=3D> sys/boot/i386/btx/btx (install) =3D=3D=3D> sys/boot/i386/btx/btxldr (install) =3D=3D=3D> sys/boot/i386/btx/lib (install) =3D=3D=3D> sys/boot/i386/boot2 (install) install -o root -g wheel -m 444 boot boot1 boot2 /builds/workspace/FreeBSD= _stable_10/package/src/boot =3D=3D=3D> sys/boot/i386/cdboot (install) install -o root -g wheel -m 444 cdboot /builds/workspace/FreeBSD_stable_= 10/package/src/boot/cdboot =3D=3D=3D> sys/boot/i386/gptboot (install) install -o root -g wheel -m 444 gptboot /builds/workspace/FreeBSD_stable_1= 0/package/src/boot install -o root -g wheel -m 444 gptboot.8.gz /builds/workspace/FreeBSD_sta= ble_10/package/src/usr/share/man/man8 =3D=3D=3D> sys/boot/i386/kgzldr (install) install -o root -g wheel -m 444 kgzldr.o /builds/workspace/FreeBSD_stabl= e_10/package/src/usr/lib/kgzldr.o =3D=3D=3D> sys/boot/i386/libi386 (install) =3D=3D=3D> sys/boot/i386/libfirewire (install) =3D=3D=3D> sys/boot/i386/loader (install) cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/builds/workspace/FreeBS= D_stable_10/src/sys/boot/i386/loader/../../ficl -I/builds/workspace/FreeBSD= _stable_10/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -= DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -I/builds/wo= rkspace/FreeBSD_stable_10/src/sys/boot/i386/loader/../../common -I. -Wall -= I/builds/workspace/FreeBSD_stable_10/src/sys/boot/i386/loader/.. -I/builds/= workspace/FreeBSD_stable_10/src/sys/boot/i386/loader/../btx/lib -march=3Di3= 86 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-f= loat -m32 -std=3Dgnu99 -Qunused-arguments -DLOADER_PREFER_AMD64 -static = -Ttext 0x0 -nostdlib -o loader.sym /builds/workspace/FreeBSD_stable_10/obj/= builds/workspace/FreeBSD_stable_10/src/sys/boot/i386/loader/../btx/lib/crt0= .o main.o conf.o vers.o boot.o commands.o console.o devopen.o interp.o inte= rp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o loa= d_elf32_obj.o reloc_elf32.o load_elf64.o load_elf64_obj.o reloc_elf64.o dis= k.o part.o crc32.o bcache.o isapnp.o pnp.o interp_forth.o /builds/workspace= /FreeBSD_stable_10/obj/builds/workspace/FreeBSD_stable_10/src/sys/boot/i386= /loader/../../ficl32/libficl.a /builds/workspace/FreeBSD_stable_10/obj/bu= ilds/workspace/FreeBSD_stable_10/src/sys/boot/i386/loader/../libi386/libi38= 6.a /builds/workspace/FreeBSD_stable_10/obj/builds/workspace/FreeBSD_stable= _10/src/sys/boot/i386/loader/../../libstand32/libstand.a cp loader.sym loader.bin make[7]: exec(cp) failed (No such file or directory) *** Error code 1 Stop. make[7]: stopped in /builds/workspace/FreeBSD_stable_10/src/sys/boot/i386/l= oader *** Error code 1 Stop. make[6]: stopped in /builds/workspace/FreeBSD_stable_10/src/sys/boot/i386 *** Error code 1 Stop. make[5]: stopped in /builds/workspace/FreeBSD_stable_10/src/sys/boot *** Error code 1 Stop. make[4]: stopped in /builds/workspace/FreeBSD_stable_10/src/sys *** Error code 1 Stop. make[3]: stopped in /builds/workspace/FreeBSD_stable_10/src *** Error code 1 Stop. make[2]: stopped in /builds/workspace/FreeBSD_stable_10/src *** Error code 1 Stop. make[1]: stopped in /builds/workspace/FreeBSD_stable_10/src *** Error code 1 Stop. make: stopped in /builds/workspace/FreeBSD_stable_10/src [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // dir [Pipeline] } [Pipeline] // node [Pipeline] node Running on master in /usr/local/jenkins/workspace/FreeBSD_stable_10 [Pipeline] { [Pipeline] step From owner-freebsd-stable@freebsd.org Wed Jul 13 08:53:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E5C6B97080 for ; Wed, 13 Jul 2016 08:53:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 402051D47 for ; Wed, 13 Jul 2016 08:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23126 invoked from network); 13 Jul 2016 08:54:08 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Jul 2016 08:54:08 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 13 Jul 2016 04:54:18 -0400 (EDT) Received: (qmail 15942 invoked from network); 13 Jul 2016 08:54:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Jul 2016 08:54:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 3F1AA1C405F; Wed, 13 Jul 2016 01:53:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc has odd mix of signed wchar_t and unsigned char] From: Mark Millard In-Reply-To: Date: Wed, 13 Jul 2016 01:53:27 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , Bruce Evans , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:53:36 -0000 [The below does note that TARGET=3Dpowerpc has a mix of signed wchar_t = and unsigned char types and most architectures have both being signed = types.] On 2016-Jul-11, at 8:57 PM, Andrey Chernov wrote: > On 12.07.2016 5:44, Mark Millard wrote: >> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>=20 >> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of >> ___wchar_t (if that is distinct). >> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; = not >> necessarily a valid char value >> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; = not >> necessarily a valid char value >=20 > It seems you are right about "not a valid char value", I'll back this > change out. >=20 >> As far as I know arm FreeBSD uses unsigned character types (of = whatever >> width). >=20 > Probably it should be unsigned for other architectures too, clang does > not generate negative values with L'' literals and locale use = only > positive values too. Looking around: # grep -i wchar sys/*/include/_types.h sys/arm/include/_types.h:typedef unsigned int ___wchar_t; sys/arm/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; sys/arm64/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ sys/mips/include/_types.h:typedef int ___wchar_t; sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/powerpc/include/_types.h:typedef int ___wchar_t; sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/riscv/include/_types.h:typedef int ___wchar_t; sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/sparc64/include/_types.h:typedef int ___wchar_t; sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ sys/x86/include/_types.h:typedef int ___wchar_t; sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ So only arm and arm64 have unsigned wchar_t types. [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in C++11 = terms char16_t is like std::uint_least16_t and char32_t is like = std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and = __CHAR32_TYPE__ are ignored below.] The clang 3.8.0 compiler output has an odd mix for TARGET_ARCH=3Dpowerpc = and TARGET_ARCH=3Dpowerpc64 . . . armv6 has unsigned types for both char and __WCHAR_TYPE__. aarch64 has unsigned types for both char and __WCHAR_TYPE__. powerpc has unsigned for char but signed for __WCHAR_TYPE__. powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. amd64 has signed types for both char and __WCHAR_TYPE__. i386 has signed types for both char and __WCHAR_TYPE__. mips has signed types for both char and __WCHAR_TYPE__. sparc64 has signed types for both char and __WCHAR_TYPE__. (riscv is not covered by clang as I understand) The details via compiler #define's. . . # clang --target=3Darmv6-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 4294967295U #define __WCHAR_TYPE__ unsigned int #define __WCHAR_UNSIGNED__ 1 #define __WCHAR_WIDTH__ 32 . . . # clang --target=3Daarch64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 4294967295U #define __WCHAR_TYPE__ unsigned int #define __WCHAR_UNSIGNED__ 1 #define __WCHAR_WIDTH__ 32 . . . # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . Is powerpc wrong? # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 #define __CHAR_UNSIGNED__ 1 . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . Is powerpc64 wrong? # clang --target=3Damd64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . # clang --target=3Di386-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . # clang --target=3Dmips-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . # clang --target=3Dsparc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ . . . #define __CHAR_BIT__ 8 . . . (note the lack of __CHAR_UNSIGNED__) . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . (note the lack of __WCHAR_UNSIGNED__) . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Wed Jul 13 09:38:28 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 593E2B970AF for ; Wed, 13 Jul 2016 09:38:28 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 47EDD1EE7; Wed, 13 Jul 2016 09:38:28 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 454351BD; Wed, 13 Jul 2016 09:38:28 +0000 (UTC) Date: Wed, 13 Jul 2016 09:38:27 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1910583580.56.1468402707270.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1283381284.53.1468372253526.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1283381284.53.1468372253526.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is unstable: FreeBSD_stable_10 #309 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:38:28 -0000 See From owner-freebsd-stable@freebsd.org Wed Jul 13 12:36:15 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11650B9345F for ; Wed, 13 Jul 2016 12:36:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0341D1A3B; Wed, 13 Jul 2016 12:36:15 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2A70D1C1; Wed, 13 Jul 2016 12:36:15 +0000 (UTC) Date: Wed, 13 Jul 2016 12:36:14 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <2113121114.57.1468413374833.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1910583580.56.1468402707270.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1910583580.56.1468402707270.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #310 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 12:36:15 -0000 See From owner-freebsd-stable@freebsd.org Wed Jul 13 15:27:16 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98FFFB97AE9 for ; Wed, 13 Jul 2016 15:27:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 83E6212AD; Wed, 13 Jul 2016 15:27:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 6A1FE1C4; Wed, 13 Jul 2016 15:27:15 +0000 (UTC) Date: Wed, 13 Jul 2016 15:27:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <632002364.58.1468423635012.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2113121114.57.1468413374833.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2113121114.57.1468413374833.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #311 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:27:16 -0000 See From owner-freebsd-stable@freebsd.org Wed Jul 13 15:37:21 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23045B97F15; Wed, 13 Jul 2016 15:37:21 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [67.213.65.194]) (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 0057A197C; Wed, 13 Jul 2016 15:37:20 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (localhost [127.0.0.1]) by mail.intertainservices.com (Postfix) with ESMTP id EFBBF56491; Wed, 13 Jul 2016 11:37:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intertainservices.com; s=mail; t=1468424238; bh=iUZqr78VCfF1UTN2QyQsJ+v7GomLIvZfTB7L/kTs3H0=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=xpLBy28vIg6aGf/Q8VM+vJha/e++bIWYaa+FsrRJvIKmjVTfOJHvVuLtfwa/iH1nK u8HuNEat7P7o/w0loiDN5bvfDcz9IAorE/4q1nKvBylrFDfpHxv6smeRVTsUeYdsfT xY612+RyAmhzAx1Rdsf/lOSCmfc8/iFLyDZ6QI5A= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 11:37:17 -0400 From: Mike Jakubik To: freebsd-stable@freebsd.org Cc: owner-freebsd-stable@freebsd.org Subject: Re: r302669 GENERIC panicking on Amazon EC2 (Solved) Organization: Intertainservices In-Reply-To: <7fd09035be22e5f8b76d2f9e29a04fd6@intertainservices.com> References: <7fd09035be22e5f8b76d2f9e29a04fd6@intertainservices.com> Message-ID: X-Sender: mike.jakubik@intertainservices.com User-Agent: Roundcube Webmail/1.1.5 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: EFBBF56491.A25EB X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:37:21 -0000 On 2016-07-12 03:52 PM, Mike Jakubik wrote: > Hello, > > I just did a svn update to stable/10 recompiled world/kernel using > GENERIC kernel and i am unable to boot this kernel on Amazon EC2 now. > > Thanks. > I took the following flags out of make.conf CPUTYPE?=native CFLAGS+=-maes -mavx And i recompiled without using -j4, all is well now. From owner-freebsd-stable@freebsd.org Wed Jul 13 19:54:04 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26A6AB98DE7 for ; Wed, 13 Jul 2016 19:54:04 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 18DC2156D; Wed, 13 Jul 2016 19:54:04 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 28BE81CC; Wed, 13 Jul 2016 19:54:04 +0000 (UTC) Date: Wed, 13 Jul 2016 19:54:03 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <325715429.59.1468439643458.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <632002364.58.1468423635012.JavaMail.jenkins@jenkins-9.freebsd.org> References: <632002364.58.1468423635012.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #312 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:54:04 -0000 See From owner-freebsd-stable@freebsd.org Wed Jul 13 20:32:04 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2CBDB986EA for ; Wed, 13 Jul 2016 20:32:04 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D261418D0 for ; Wed, 13 Jul 2016 20:32:04 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id C75C3B986E9; Wed, 13 Jul 2016 20:32:04 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6F52B986E8 for ; Wed, 13 Jul 2016 20:32:04 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91E0818CD for ; Wed, 13 Jul 2016 20:32:04 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22a.google.com with SMTP id f6so53748319ith.0 for ; Wed, 13 Jul 2016 13:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=/sKzQy+BldOPKqgVzPmN7UUSa0ZxpmVt09ljmA8jsbc=; b=qiHZhcPeZorvXDhbuZYGcv7Hy3aP1Teb2j7mgGRuUlzG1UrfrKeuT32bCmt4tnv1Z6 us455THN13dXEkO3xeD4chfwur94gX55Io6pw/bKY7sj1sKWVKHgOOIo0Nt4RrnxvzlG AL6PvarP3vy2oK5MngAfYkQlX2hUj6DxfgBoqAu0USSRVInCAJgo8RYrkm7qs8wsZFz3 VA0jIXDIDTI2SdkeC67d0YSEfqtt2PQBAwHgv24Euy7SP3O9JpedwN8X7KggLTn2v/cu 3d/UEBaB5LBh7v+QxBUyzxL2gepI58jgl9Wfo+Kshlpvk1JQw132cKYRmFNrctke2QJ+ kYJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=/sKzQy+BldOPKqgVzPmN7UUSa0ZxpmVt09ljmA8jsbc=; b=QTULb1qx5S9WzmpGxmZXMTKBVi3AZgqTpqF+yadshqzhvUApnREKJmMoUvE+o0zIY/ wbSmSqSvAIh4xVhFjILw4VXZI+CMUyn/1O+f+GCv0TXuNNcXsBul8untowpIKwNly3P/ 9GnzUh7cyal4C5GWLbDKZJMrZ9E7NXQp7C8RznS0c6JswBTTfOT1Gss9zikcT/XJgn9E loSNouFW3dpc1TG3opZ2ASlZZjIeIcNmrjxT8DNePWS3v0UMNdDPQ8ueHKe1t/7RcEid 56WUDJSypYMECBqMPDOyTmqlCTEv63Dof7zZFyCQHjtAP1ZXnx9RnS6eCuCEBx4EbC9R /iMA== X-Gm-Message-State: ALyK8tKNgJH5vmk8ll2hzKumiNmqQ9Z+cpZabzri57q0HMM+0KcNVOm070rKBRwfds/iPZFaivECWYo4ZgUnZJm2 X-Received: by 10.36.122.129 with SMTP id a123mr23172099itc.44.1468441923827; Wed, 13 Jul 2016 13:32:03 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.59.193 with HTTP; Wed, 13 Jul 2016 13:32:03 -0700 (PDT) From: Maxim Sobolev Date: Wed, 13 Jul 2016 13:32:03 -0700 X-Google-Sender-Auth: gkshRdIOj6qWI8WubTmfOAaD0ag Message-ID: Subject: 11.0-BETA1 'ifconfig igb0 media auto' causes panic in llentry_free() To: stable@freebsd.org, FreeBSD Release Engineering Team Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:32:05 -0000 Hi, we are seeing consistent crash doing 'ifconfig igb0 media auto' after interface has been provisioned by the dhcpclient. This is stable/11 sources from svn revision 302593. That problem did not happen to us before the upgrade from from 11.0-ALPHA3, svn revision 301898 from head. Sreenshot of the backtrace is here: http://sobomax.sippysoft.com/DSC00012.JPG -Maxim From owner-freebsd-stable@freebsd.org Wed Jul 13 20:46:36 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92E57B98CA8 for ; Wed, 13 Jul 2016 20:46:36 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7696A13E0 for ; Wed, 13 Jul 2016 20:46:36 +0000 (UTC) (envelope-from ler@lerctr.org) Received: by mailman.ysv.freebsd.org (Postfix) id 724B6B98CA5; Wed, 13 Jul 2016 20:46:36 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F3BDB98CA4; Wed, 13 Jul 2016 20:46:36 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CF5C13DF; Wed, 13 Jul 2016 20:46:36 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pJu3ND5N+6vGJYl/iH06zOAK/7S9xYL1PbJWB533mZQ=; b=FkKAiEOJxx45CqXf1FsKQM9VNQ A3iBuAS4CGkB10tSDEEkd6dJDB/TZuJiiMslpyZ5ftRShdzhFgu+Kt4hMdGMHnYSWSsfjtpj5P4VM CzxcvW+2DJuHyqILig/bwdpCA8ayQhYJ+IRY9V40/ZKkoBYJkEoCH+SXaV2ifGwBMcIU=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:19112 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bNR3D-000NiH-Na; Wed, 13 Jul 2016 15:46:35 -0500 Received: from proxy.na.alcatel-lucent.com ([135.245.48.82]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 15:46:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 13 Jul 2016 15:46:35 -0500 From: Larry Rosenman To: Maxim Sobolev Cc: stable@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Net , owner-freebsd-stable@freebsd.org Subject: Re: 11.0-BETA1 'ifconfig igb0 media auto' causes panic in llentry_free() In-Reply-To: References: Message-ID: <94f16de461db3e04d5f2f882cce34aec@thebighonker.lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.2.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:46:36 -0000 On 2016-07-13 15:32, Maxim Sobolev wrote: > Hi, we are seeing consistent crash doing 'ifconfig igb0 media auto' > after > interface has been provisioned by the dhcpclient. This is stable/11 > sources > from svn revision 302593. > > That problem did not happen to us before the upgrade from from > 11.0-ALPHA3, > svn revision 301898 from head. > > Sreenshot of the backtrace is here: > http://sobomax.sippysoft.com/DSC00012.JPG > > -Maxim see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-stable@freebsd.org Wed Jul 13 20:57:48 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A563B98F9F for ; Wed, 13 Jul 2016 20:57:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 266621C46 for ; Wed, 13 Jul 2016 20:57:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id 25B22B98F9A; Wed, 13 Jul 2016 20:57:48 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2555AB98F99 for ; Wed, 13 Jul 2016 20:57:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 E1D481C44 for ; Wed, 13 Jul 2016 20:57:47 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x235.google.com with SMTP id f6so54309558ith.0 for ; Wed, 13 Jul 2016 13:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DxXdf3AO7WUS9Zx7GL6BRIaL2ThFthVX8N26+Z4TnJI=; b=dTM8hthKKej5q4gRkhnKXoAhMUFji5l0oUvi0rdiWZtcgNITymJ+8WiVJnM3/qN6oa wyYdwaHbE3LspBJ50JOIroTNXvP0qOuMrWiUB+Nl/G8UG8RiYGVKl8kNatqaur9JULnu ZvxZaJhL1r9JGE5EiOYACEUJW5mt9tAHQJa8j0GeWfyYMYEow2jC8qDTiFz8e+6OF8ye hfpqsYMwDHaSUm5ZVV+7AxSGGz1FyMRaQ3FN0avbax5gbSOQOesu9rDv+8CyxNp7TEQC qep0t7/WfuNSYkvAHFOWCfJPeYbTk6EwuEBJPkf8z1ZoEfgdlBhATdIec4ALqB30ha+A Zu8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DxXdf3AO7WUS9Zx7GL6BRIaL2ThFthVX8N26+Z4TnJI=; b=kOM+0eRjLW8ss8ZQQlgQ5EW04Ithdk8MYRs+Hunws1/4MJpHLauBBgT1+Xi9EFzIDS ahrIaeULLp+jyBfYmnMEtnYC5MhJBCRzutJYdp5VHgGS5ZyhLkff76Y7SCX/7PTA7bZh 7zIPv7LHcIIJ/W2klYT8fpHs+XvSW7sWQr34u7S3RCvWTWzsjXkjp5vbd2lT2WjW+IO9 ssscrVVzpl7dzu8OvgiWuwHnKw8WWsKLWsYl51UqIzTupAZF1DfoDTr64hzc6wPxstgE 4z2RMWSIS++im23Pguj2QuqbJ19aRqPOhb4ao9lqAgCezFp/TMylVMyIKZbdY4TL1/jG 7LXw== X-Gm-Message-State: ALyK8tJhKGVyGt/o/fxubtj1F+8WcvOvqIAHHhBPmTQ7pEwZcv3ufxocv0dNXqcHS5dvNBqicxj52GY5RB5NA2t3 X-Received: by 10.36.90.79 with SMTP id v76mr10668336ita.16.1468443467374; Wed, 13 Jul 2016 13:57:47 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.59.193 with HTTP; Wed, 13 Jul 2016 13:57:46 -0700 (PDT) In-Reply-To: <94f16de461db3e04d5f2f882cce34aec@thebighonker.lerctr.org> References: <94f16de461db3e04d5f2f882cce34aec@thebighonker.lerctr.org> From: Maxim Sobolev Date: Wed, 13 Jul 2016 13:57:46 -0700 X-Google-Sender-Auth: sqeBDKxoRDW6eHIX6JwXhZGnjZM Message-ID: Subject: Re: 11.0-BETA1 'ifconfig igb0 media auto' causes panic in llentry_free() To: Larry Rosenman Cc: stable@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Net , owner-freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 20:57:48 -0000 Thanks, looks like the same issue. I'll try the patch from ticket. -Max On Wed, Jul 13, 2016 at 1:46 PM, Larry Rosenman wrote: > On 2016-07-13 15:32, Maxim Sobolev wrote: > >> Hi, we are seeing consistent crash doing 'ifconfig igb0 media auto' after >> interface has been provisioned by the dhcpclient. This is stable/11 >> sources >> from svn revision 302593. >> >> That problem did not happen to us before the upgrade from from >> 11.0-ALPHA3, >> svn revision 301898 from head. >> >> Sreenshot of the backtrace is here: >> http://sobomax.sippysoft.com/DSC00012.JPG >> >> -Maxim >> > see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884 > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > > From owner-freebsd-stable@freebsd.org Wed Jul 13 21:00:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76976B97170 for ; Wed, 13 Jul 2016 21:00:57 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 550651EEB for ; Wed, 13 Jul 2016 21:00:57 +0000 (UTC) (envelope-from ler@lerctr.org) Received: by mailman.ysv.freebsd.org (Postfix) id 50804B9716D; Wed, 13 Jul 2016 21:00:57 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D406B9716C; Wed, 13 Jul 2016 21:00:57 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22F841EE9; Wed, 13 Jul 2016 21:00:57 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Type:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GfCdEvo8V43al0EiYXZ/CQkXSHFNBUOeDTHLzVQkNM0=; b=bzqGDxvshjw8ONH+p9sf/k9E0u o7ry41zlFoCeIEwoU5BHV8cvKQ/kEirMNv8eDN3tavm5wp8+VAXVuvAGZKXOkj27UhayvJ3DwX3g6 idlKNqyBRHKlneYVBx1ou3RQcxAX+9cYzmg7h+nRgIK2t2VBrojJXy+XloIVUUTSsiBU=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:59000 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bNRH6-000OEU-Hh; Wed, 13 Jul 2016 16:00:56 -0500 Received: from proxy.na.alcatel-lucent.com ([135.245.48.82]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Wed, 13 Jul 2016 16:00:56 -0500 MIME-Version: 1.0 Date: Wed, 13 Jul 2016 16:00:56 -0500 From: Larry Rosenman To: Maxim Sobolev Cc: stable@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Net , owner-freebsd-stable@freebsd.org, sobomax@sippysoft.com Subject: Re: 11.0-BETA1 'ifconfig igb0 media auto' causes panic in llentry_free() In-Reply-To: References: <94f16de461db3e04d5f2f882cce34aec@thebighonker.lerctr.org> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.2.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 21:00:57 -0000 NOTE: I get an insta-panic on boot :( I'm waiting for Gleb to respond. On 2016-07-13 15:57, Maxim Sobolev wrote: > Thanks, looks like the same issue. I'll try the patch from ticket. > > -Max > > On Wed, Jul 13, 2016 at 1:46 PM, Larry Rosenman wrote: > > On 2016-07-13 15:32, Maxim Sobolev wrote: > Hi, we are seeing consistent crash doing 'ifconfig igb0 media auto' after > interface has been provisioned by the dhcpclient. This is stable/11 sources > from svn revision 302593. > > That problem did not happen to us before the upgrade from from 11.0-ALPHA3, > svn revision 301898 from head. > > Sreenshot of the backtrace is here: > http://sobomax.sippysoft.com/DSC00012.JPG > > -Maxim see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884 > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 [1] E-Mail: ler@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 Links: ------ [1] tel:%2B1%20214-642-9640 From owner-freebsd-stable@freebsd.org Wed Jul 13 23:10:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D4D4B98685; Wed, 13 Jul 2016 23:10:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0FDB61BC0; Wed, 13 Jul 2016 23:10:19 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id B0EC519E8; Wed, 13 Jul 2016 23:10:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 13 Jul 2016 23:10:17 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: 11.0-BETA2 may be delayed Message-ID: <20160713231017.GA95249@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 23:10:19 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As I am sure you have already seen, there is an issue in 11.0-BETA1 that has caused some headaches for people. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884 The issue is actively being investigated, and despite the KBI freeze, the fix may need to break KBI in stable/11, at least as far as I am aware at the moment. That said, 11.0-BETA2 may be delayed, while this is properly resolved. If KBI is changed between 11.0-BETA1 and 11.0-BETA2, it will be noted in the announcement. Sorry for the delay in advance. Glen On behalf of: re@ --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXhspZAAoJEAMUWKVHj+KT3joQAIa2wBlPItZgyqExRsHPqnIm EiEC5kBRQ15owl9tt1eMqVZbw4nHV1gsUWHfgJ7PssLDIbe4sUpl/NcMExPo2Lw2 gquF1D/hkyJibrSPYRg10cacATIMEOy8uxTPdhd/7bxL7fiGl/ndKxVaLbXHRDjR rye7ufXxEjD8wEH3WzZszI+MzMkf7ozT6KCwE9ilyFOAei+f0H4HSy1F1sNCGkgN plOL/fXHAEEN/aZ0xvSVxRRExLXngeyQ7fcslfX1jYeQjagZtsURBKt0alBCWVYR 5Jo9ps+PK846kA+tBGqjlFD1L9xHG5H6fPTgllG69Uqze7EUWd2Niw69xfGJfEL8 VtuRapSBPRoLSIa7Rxd/IEa+kVpr4fW0ou4HyJ9FEEUJ564HtfHtGgJ8CpY2acqu YrNm7E6TJ3azKbWYYZluG0hRYuesYPN62vbL5JrwJ6qKYZnz9nUgwQl3m6ewWXp4 5GyqvcritvyVecyLOcaqG7G83Cp1Cyp6BOpNJV2b/izwvqHXfKmjgRkWNpKoXT26 LfFOzLy5UTsJSvq3mAMRRjJxlLw6VOUj33NNOz1ZNHKKTOppfqv/hhyTfJU3DIuL oB0fesT5oKnrawzd1pwxxdLiUMPAD6IuQzQvqAGVPyb6D0mOhsr5xHwZwSwD6+f3 wr2P9doOnUOAMpOvNjbu =SXfj -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-stable@freebsd.org Thu Jul 14 01:00:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7261AB97652 for ; Thu, 14 Jul 2016 01:00:34 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E140213C4 for ; Thu, 14 Jul 2016 01:00:33 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f48.google.com with SMTP id b199so51309457lfe.0 for ; Wed, 13 Jul 2016 18:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GaZX3Zul7amFxu9OXBSO+o+VbSL2HHuNJ57ZuUh8dXA=; b=lrTIz38Pf+vGMbQnExl0EAozu5dujCWbJ86l1n9GA3nDVIv/e4ifL74yf53jlk/hqm YGOUKHJcfSSQOaFXPT2qqPzQqysdpj+G+7pV5gLwhJNEbhH4MzQhVBujoMkz7XoLqTBg utnGAKmDgr9+86on39EAr5isdvQJoziIr9Y+RqHf+Ly5paL/Ql6UZutYL2GGplop7k4+ pxzUHcGwOMo8e/XQn2hjIQ6onWmAtyUPrYHLLdDdbqXyDXmrKFXfBe811nSxH3U0FeDI 1uSHau5xbVMiDc7jUE+vT5/a9FHSdz/Kr4CKy5rZxNQLsbT85yb+x3CiIOQIA6uCt1so YgjA== X-Gm-Message-State: ALyK8tIEPe4FJLm4fXeUlV0ebkmHvgIi76eD61C3rYMfTJ/jcWvc7tNWI1kXcUR0UCq3Bg== X-Received: by 10.25.154.136 with SMTP id c130mr5564967lfe.87.1468458026291; Wed, 13 Jul 2016 18:00:26 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id o10sm2456631lfo.47.2016.07.13.18.00.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 18:00:25 -0700 (PDT) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc has odd mix of signed wchar_t and unsigned char] To: Mark Millard References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , Bruce Evans , FreeBSD Toolchain From: Andrey Chernov Message-ID: Date: Thu, 14 Jul 2016 04:00:24 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 01:00:34 -0000 On 13.07.2016 11:53, Mark Millard wrote: > [The below does note that TARGET=powerpc has a mix of signed wchar_t and unsigned char types and most architectures have both being signed types.] POSIX says nothing about wchar_t and char should be the same (un)signed. It is arm ABI docs may say so only. They are different entities differently encoded and cross assigning between wchar_t and char is not recommended. > > On 2016-Jul-11, at 8:57 PM, Andrey Chernov wrote: > >> On 12.07.2016 5:44, Mark Millard wrote: >>> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>> >>> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of >>> ___wchar_t (if that is distinct). >>> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not >>> necessarily a valid char value >>> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not >>> necessarily a valid char value >> >> It seems you are right about "not a valid char value", I'll back this >> change out. >> >>> As far as I know arm FreeBSD uses unsigned character types (of whatever >>> width). >> >> Probably it should be unsigned for other architectures too, clang does >> not generate negative values with L'' literals and locale use only >> positive values too. > > Looking around: > > # grep -i wchar sys/*/include/_types.h > sys/arm/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm/include/_types.h:#define __WCHAR_MIN 0 /* min value for a wchar_t */ > sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX /* max value for a wchar_t */ > sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm64/include/_types.h:#define __WCHAR_MIN 0 /* min value for a wchar_t */ > sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX /* max value for a wchar_t */ > sys/mips/include/_types.h:typedef int ___wchar_t; > sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/powerpc/include/_types.h:typedef int ___wchar_t; > sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/riscv/include/_types.h:typedef int ___wchar_t; > sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/sparc64/include/_types.h:typedef int ___wchar_t; > sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > sys/x86/include/_types.h:typedef int ___wchar_t; > sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN /* min value for a wchar_t */ > sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX /* max value for a wchar_t */ > > So only arm and arm64 have unsigned wchar_t types. > > [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in C++11 terms char16_t is like std::uint_least16_t and char32_t is like std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and __CHAR32_TYPE__ are ignored below.] > > The clang 3.8.0 compiler output has an odd mix for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 . . . > > armv6 has unsigned types for both char and __WCHAR_TYPE__. > aarch64 has unsigned types for both char and __WCHAR_TYPE__. > powerpc has unsigned for char but signed for __WCHAR_TYPE__. > powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. > amd64 has signed types for both char and __WCHAR_TYPE__. > i386 has signed types for both char and __WCHAR_TYPE__. > mips has signed types for both char and __WCHAR_TYPE__. > sparc64 has signed types for both char and __WCHAR_TYPE__. > (riscv is not covered by clang as I understand) > > The details via compiler #define's. . . > > # clang --target=armv6-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . > > # clang --target=aarch64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . > > # clang --target=powerpc-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > Is powerpc wrong? > > # clang --target=powerpc64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > Is powerpc64 wrong? > > > # clang --target=amd64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > # clang --target=i386-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > > # clang --target=mips-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > # clang --target=sparc64-freebsd11 -std=c99 -E -dM - < /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . > > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . > > > > === > Mark Millard > markmi at dsl-only.net > From owner-freebsd-stable@freebsd.org Thu Jul 14 04:59:07 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE17EB98DD4 for ; Thu, 14 Jul 2016 04:59:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC561AEB; Thu, 14 Jul 2016 04:59:07 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id ED56C1E3; Thu, 14 Jul 2016 04:59:07 +0000 (UTC) Date: Thu, 14 Jul 2016 04:59:07 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1467601303.64.1468472347260.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <325715429.59.1468439643458.JavaMail.jenkins@jenkins-9.freebsd.org> References: <325715429.59.1468439643458.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #313 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 04:59:07 -0000 See From owner-freebsd-stable@freebsd.org Thu Jul 14 05:04:27 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79E14B97053 for ; Thu, 14 Jul 2016 05:04:27 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5525D1165 for ; Thu, 14 Jul 2016 05:04:27 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mailman.ysv.freebsd.org (Postfix) id 54888B97050; Thu, 14 Jul 2016 05:04:27 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 542FDB9704F for ; Thu, 14 Jul 2016 05:04:27 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 1D9251162 for ; Thu, 14 Jul 2016 05:04:27 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x232.google.com with SMTP id f6so38404380ith.1 for ; Wed, 13 Jul 2016 22:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/sRVhxILLUy/G7kLiaZzamiOBP0e7fCAmW/7f6hg1NM=; b=DF4F3BguTVBKdPqz9VBi7jGRhX3x092H6b6US7A9a6LuJkOtrNEAvB/ELl8RXHwMPl b2RaRABFxQRT3K+APBv1jALtjLX7DAHuH3EHxxRvc24l6lbRhGy5VkgWS+VKKUMEo1gs MRutY4Oa7lDr0a+Ea+FiTE/Z8I7DFPeqIoCQMDTOu7unWYklkff+4kLfJ0jeplgrcv8W j3kwFy5AgwrseJNKXizAXYLxL5CPx+E0K+nr0sc8HNiWIIe1Tt4b8kzdrAjBwsIMIk1K m1EIGzrUPLUEoDPSstZMVZPz1RA73XdhmoOQ3zLuxqWpgJdl0jY2iH3Er2kumY6ADp3l iDKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/sRVhxILLUy/G7kLiaZzamiOBP0e7fCAmW/7f6hg1NM=; b=Pwx4Q/+JO0JToOs+owoU4kPChrpTEncBiVpGFUlUj2ez8oTZWyzsUaqtXIjWmP+esa LOZTCAywIhEUbUZFfx1WncLyBWlG93GfLXExk4QlpFHjl/N7G0UoST6dmmA1+zDyfLZN IYNqviAS3mhBHtcexFSUspI0AOQqa4b+jHlNDpidKuI4fwBHBmqCZpPv5UDOV1TGrYfg 4pnDgM2aNCz5okkDtksMZBzCOQ6zgPqvrN3q5Ke3cdoi40S4mcPjnD3Coevuj+tilcx2 VtPnpwFEufn5MUQ9E8N0NU7IY7CtcGP8v6VdAMBG51eSXsGhQZHij2cAM1tVpAhCyn1h B0Xw== X-Gm-Message-State: ALyK8tKgyBg+ylflOQ7nwDDpHfnHYBJKosKgUbYzR0FTTDwLwGKspfbZ9fONi1EuiWTBahbeS51YHBvHQMnPVPRe X-Received: by 10.36.188.65 with SMTP id n62mr26735385ite.61.1468472666497; Wed, 13 Jul 2016 22:04:26 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.59.193 with HTTP; Wed, 13 Jul 2016 22:04:26 -0700 (PDT) In-Reply-To: References: <94f16de461db3e04d5f2f882cce34aec@thebighonker.lerctr.org> From: Maxim Sobolev Date: Wed, 13 Jul 2016 22:04:26 -0700 X-Google-Sender-Auth: wBdr6ttK4IHn-WlpMJE1NFe1upw Message-ID: Subject: Re: 11.0-BETA1 'ifconfig igb0 media auto' causes panic in llentry_free() To: Larry Rosenman Cc: stable@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Net , owner-freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 05:04:27 -0000 Larry, thanks for the pointer. Patch in the PR fixed the issue for me. Added comment in there. -Max On Wed, Jul 13, 2016 at 2:00 PM, Larry Rosenman wrote: > NOTE: I get an insta-panic on boot :( > > I'm waiting for Gleb to respond. > > > > On 2016-07-13 15:57, Maxim Sobolev wrote: > > Thanks, looks like the same issue. I'll try the patch from ticket. > > -Max > > > > On Wed, Jul 13, 2016 at 1:46 PM, Larry Rosenman wrote: > >> On 2016-07-13 15:32, Maxim Sobolev wrote: >> >>> Hi, we are seeing consistent crash doing 'ifconfig igb0 media auto' after >>> interface has been provisioned by the dhcpclient. This is stable/11 >>> sources >>> from svn revision 302593. >>> >>> That problem did not happen to us before the upgrade from from >>> 11.0-ALPHA3, >>> svn revision 301898 from head. >>> >>> Sreenshot of the backtrace is here: >>> http://sobomax.sippysoft.com/DSC00012.JPG >>> >>> -Maxim >> >> see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884 >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 214-642-9640 E-Mail: ler@lerctr.org >> US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 >> >> > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: ler@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > From owner-freebsd-stable@freebsd.org Thu Jul 14 06:53:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06B03B98402 for ; Thu, 14 Jul 2016 06:53:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 BBDD51A6A for ; Thu, 14 Jul 2016 06:53:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6419 invoked from network); 14 Jul 2016 06:46:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Jul 2016 06:46:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 14 Jul 2016 02:46:42 -0400 (EDT) Received: (qmail 29570 invoked from network); 14 Jul 2016 06:46:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Jul 2016 06:46:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 3C1BDB1E001; Wed, 13 Jul 2016 23:46:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long] From: Mark Millard In-Reply-To: Date: Wed, 13 Jul 2016 23:46:35 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , Bruce Evans , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <3DFF1DC9-2AE6-498A-9FE0-4970E76F8AB5@dsl-only.net> References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 06:53:19 -0000 On 2016-Jul-13, at 6:00 PM, Andrey Chernov wrote: > On 13.07.2016 11:53, Mark Millard wrote: >> [The below does note that TARGET=3Dpowerpc has a mix of signed = wchar_t and unsigned char types and most architectures have both being = signed types.] >=20 > POSIX says nothing about wchar_t and char should be the same = (un)signed. > It is arm ABI docs may say so only. They are different entities > differently encoded and cross assigning between wchar_t and char is = not > recommended. [My "odd" would better have been the longer phrase "unusual for FreeBSD" = for the signed type mismatch point.] C11 (9899:2011[2012]) and C++11 (14882:2011(E)) agree with your POSIX = note: no constraint to have the same signed type status as char. But when I then looked at the "System V Application Binary Interface = PowerpC Processor Supplement" (1995-Sept SunSoft document) that I = believe FreeBSD uses for powerpc (32-bit only: TARGET_ARCH=3Dpowerpc) it = has: typedef long wchar_t; as part of: Figure 6-39 (page labeled 6-38). While agreeing about the signed-type status for wchar_t this does not = agree with FreeBSD 11.0's use of int as the type: sys/powerpc/include/_types.h:typedef int ___wchar_t; sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . I'm not as sure of which document is official for TARGET_ARCH=3Dpowerpc64 = but using "Power Architecture 64-bit ELF V2 ABI Specification" (Open = POWER ABI for Linux Supplement) as an example of what likely is common = for that context: 5.1.3 Types Defined in Standard header lists: typedef long wchar_t; which again does not agree with FreeBSD 11.0's use of int as the type: # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more . . . #define __WCHAR_MAX__ 2147483647 #define __WCHAR_TYPE__ int #define __WCHAR_WIDTH__ 32 . . . =3D=3D=3D Mark Millard markmi at dsl-only.net >=20 > On 2016-Jul-11, at 8:57 PM, Andrey Chernov = wrote: >=20 >> On 12.07.2016 5:44, Mark Millard wrote: >>> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>>=20 >>> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion = of >>> ___wchar_t (if that is distinct). >>> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; = not >>> necessarily a valid char value >>> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; = not >>> necessarily a valid char value >>=20 >> It seems you are right about "not a valid char value", I'll back this >> change out. >>=20 >>> As far as I know arm FreeBSD uses unsigned character types (of = whatever >>> width). >>=20 >> Probably it should be unsigned for other architectures too, clang = does >> not generate negative values with L'' literals and locale use = only >> positive values too. >=20 > Looking around: >=20 > # grep -i wchar sys/*/include/_types.h > sys/arm/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ > sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ > sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; > sys/arm64/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ > sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ > sys/mips/include/_types.h:typedef int ___wchar_t; > sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/powerpc/include/_types.h:typedef int ___wchar_t; > sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/riscv/include/_types.h:typedef int ___wchar_t; > sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/sparc64/include/_types.h:typedef int ___wchar_t; > sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ > sys/x86/include/_types.h:typedef int ___wchar_t; > sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >=20 > So only arm and arm64 have unsigned wchar_t types. >=20 > [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in = C++11 terms char16_t is like std::uint_least16_t and char32_t is like = std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and = __CHAR32_TYPE__ are ignored below.] >=20 > The clang 3.8.0 compiler output has an odd mix for TARGET_ARCH=3Dpowerpc= and TARGET_ARCH=3Dpowerpc64 . . . >=20 > armv6 has unsigned types for both char and __WCHAR_TYPE__. > aarch64 has unsigned types for both char and __WCHAR_TYPE__. > powerpc has unsigned for char but signed for __WCHAR_TYPE__. > powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. > amd64 has signed types for both char and __WCHAR_TYPE__. > i386 has signed types for both char and __WCHAR_TYPE__. > mips has signed types for both char and __WCHAR_TYPE__. > sparc64 has signed types for both char and __WCHAR_TYPE__. > (riscv is not covered by clang as I understand) >=20 > The details via compiler #define's. . . >=20 > # clang --target=3Darmv6-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . >=20 > # clang --target=3Daarch64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 4294967295U > #define __WCHAR_TYPE__ unsigned int > #define __WCHAR_UNSIGNED__ 1 > #define __WCHAR_WIDTH__ 32 > . . . >=20 > # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > Is powerpc wrong? >=20 > # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < = /dev/null | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > #define __CHAR_UNSIGNED__ 1 > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > Is powerpc64 wrong? >=20 >=20 > # clang --target=3Damd64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > # clang --target=3Di386-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 >=20 > # clang --target=3Dmips-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 > # clang --target=3Dsparc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > . . . > #define __CHAR_BIT__ 8 > . . . (note the lack of __CHAR_UNSIGNED__) . . . >=20 > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . (note the lack of __WCHAR_UNSIGNED__) . . . >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 From owner-freebsd-stable@freebsd.org Thu Jul 14 07:52:49 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41CAFB989F5 for ; Thu, 14 Jul 2016 07:52:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0571AE6; Thu, 14 Jul 2016 07:52:49 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2AE201E8; Thu, 14 Jul 2016 07:52:49 +0000 (UTC) Date: Thu, 14 Jul 2016 07:52:48 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <794432070.66.1468482768252.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1467601303.64.1468472347260.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1467601303.64.1468472347260.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #314 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 07:52:49 -0000 See From owner-freebsd-stable@freebsd.org Thu Jul 14 09:53:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01E46B92D6D for ; Thu, 14 Jul 2016 09:53:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 B3B0D1A63 for ; Thu, 14 Jul 2016 09:53:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13244 invoked from network); 14 Jul 2016 09:54:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Jul 2016 09:54:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 14 Jul 2016 05:53:37 -0400 (EDT) Received: (qmail 1143 invoked from network); 14 Jul 2016 09:53:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Jul 2016 09:53:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id BC0BEB1E001; Thu, 14 Jul 2016 02:53:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long] From: Mark Millard In-Reply-To: <3DFF1DC9-2AE6-498A-9FE0-4970E76F8AB5@dsl-only.net> Date: Thu, 14 Jul 2016 02:53:29 -0700 Cc: svn-src-head@freebsd.org, FreeBSD Current , freebsd-stable@freebsd.org, freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Bruce Evans Content-Transfer-Encoding: quoted-printable Message-Id: <580A746B-3F02-44FA-AB2E-20CC71A1E9D2@dsl-only.net> References: <46153340-D2F4-48BD-B738-4792BC25FA3F@dsl-only.net> <38CF2C28-3BD1-4D09-939F-4DD0C2E8B58F@dsl-only.net> <3DFF1DC9-2AE6-498A-9FE0-4970E76F8AB5@dsl-only.net> To: Andrey Chernov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 09:53:40 -0000 [Top post of a history note for powerpc and wchar_t's type in FreeBSD. = The history is from looking around in svn.] [The below is not a complaint or a request for a change. It just looks = like int for wchar_t for powerpc was a choice made long ago for simpler = code given FreeBSD's pre-existing structure.] int being used for powerpc wchar_t on FreeBSD goes back to at least = 2001-Jan-1. [FYI: "27 February, 2008: FreeBSD 7.0 is the first release = to officially support the FreeBSD/ppc port". So long before official = support.] wchar_t's type is one place where FreeBSD choose to override the powerpc = (and powerpc64) ABI standards (that indicate long, not int). I'm not = sure if this was implicit vs. explicitly realizing the ABI mismatch. = [The SYSVR4 32-bit powerpc ABI goes back to 1995.] I first traced the history back to 2002-Aug-23: -r102315 of = sys/sys/_types.h standardized FreeBSD on the following until the ARM = change: typedef int __ct_rune_t; typedef __ct_rune_t __rune_t; typedef __ct_rune_t __wchar_t; typedef __ct_rune_t __wint_t; Prior to this there was 2002-Aug-21's -r102227 = sys/powerpc/include/_types.h that used __int32_t. Prior to that had ansi.h and types.h instead of _types.h --and ansi.h = had: #define _BSD_WCHAR_T_ _BSD_CT_RUNE_T_ /* wchar_t (see below) = */ . . . #define _BSD_CT_RUNE_T_ int /* arg type for ctype = funcs */ Going back to sys/powerpc/include/ansi.h's -r70571 (2001-Jan-1 creation = in svn): #define _BSD_WCHAR_T_ int /* wchar_t */ And the comments back then say: . . . It is not * unsigned so that EOF (-1) can be naturally assigned to it and used. . . . The reason an int was * chosen over a long is that the is*() and to*() routines take ints = (says * ANSI C), but they use __ct_rune_t instead of int. I've decided to not go any farther back in time (if there is prior = history for wchar_t for powerpc). Ignoring the temporary __int32_t use: FreeBSD has had its own powerpc = wchar_t type (int) for at least the last 15 years, at least when viewed = just relative to the powerpc ABI(s) FreeBSD is based on for powerpc. Modern gcc versions even have the FreeBSD wchar_t type correct for = powerpc variants in recent times: int. Previously some notation (L based = notation) used the wrong type for one of the powerpc variants (32-bit = vs. 64-bit), causing lots of false-positive compiler notices. gcc had = followed the ABI involved (long int) until the correction. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jul-13, at 11:46 PM, Mark Millard = wrote: > On 2016-Jul-13, at 6:00 PM, Andrey Chernov = wrote: >=20 >> On 13.07.2016 11:53, Mark Millard wrote: >>> [The below does note that TARGET=3Dpowerpc has a mix of signed = wchar_t and unsigned char types and most architectures have both being = signed types.] >>=20 >> POSIX says nothing about wchar_t and char should be the same = (un)signed. >> It is arm ABI docs may say so only. They are different entities >> differently encoded and cross assigning between wchar_t and char is = not >> recommended. >=20 > [My "odd" would better have been the longer phrase "unusual for = FreeBSD" for the signed type mismatch point.] >=20 > C11 (9899:2011[2012]) and C++11 (14882:2011(E)) agree with your POSIX = note: no constraint to have the same signed type status as char. >=20 > But when I then looked at the "System V Application Binary Interface = PowerpC Processor Supplement" (1995-Sept SunSoft document) that I = believe FreeBSD uses for powerpc (32-bit only: TARGET_ARCH=3Dpowerpc) it = has: >=20 > typedef long wchar_t; >=20 > as part of: Figure 6-39 (page labeled 6-38). >=20 > While agreeing about the signed-type status for wchar_t this does not = agree with FreeBSD 11.0's use of int as the type: >=20 > sys/powerpc/include/_types.h:typedef int ___wchar_t; > sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ > sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >=20 > # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . >=20 > I'm not as sure of which document is official for = TARGET_ARCH=3Dpowerpc64 but using "Power Architecture 64-bit ELF V2 ABI = Specification" (Open POWER ABI for Linux Supplement) as an example of = what likely is common for that context: 5.1.3 Types Defined in Standard = header lists: >=20 > typedef long wchar_t; >=20 > which again does not agree with FreeBSD 11.0's use of int as the type: >=20 > # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < = /dev/null | more > . . . > #define __WCHAR_MAX__ 2147483647 > #define __WCHAR_TYPE__ int > #define __WCHAR_WIDTH__ 32 > . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >>=20 >> On 2016-Jul-11, at 8:57 PM, Andrey Chernov = wrote: >>=20 >>> On 12.07.2016 5:44, Mark Millard wrote: >>>> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX: >>>>=20 >>>> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion = of >>>> ___wchar_t (if that is distinct). >>>> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; = not >>>> necessarily a valid char value >>>> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; = not >>>> necessarily a valid char value >>>=20 >>> It seems you are right about "not a valid char value", I'll back = this >>> change out. >>>=20 >>>> As far as I know arm FreeBSD uses unsigned character types (of = whatever >>>> width). >>>=20 >>> Probably it should be unsigned for other architectures too, clang = does >>> not generate negative values with L'' literals and locale use = only >>> positive values too. >>=20 >> Looking around: >>=20 >> # grep -i wchar sys/*/include/_types.h >> sys/arm/include/_types.h:typedef unsigned int ___wchar_t; >> sys/arm/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ >> sys/arm/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ >> sys/arm64/include/_types.h:typedef unsigned int ___wchar_t; >> sys/arm64/include/_types.h:#define __WCHAR_MIN 0 = /* min value for a wchar_t */ >> sys/arm64/include/_types.h:#define __WCHAR_MAX __UINT_MAX = /* max value for a wchar_t */ >> sys/mips/include/_types.h:typedef int ___wchar_t; >> sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/powerpc/include/_types.h:typedef int ___wchar_t; >> sys/powerpc/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/powerpc/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/riscv/include/_types.h:typedef int ___wchar_t; >> sys/riscv/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/riscv/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/sparc64/include/_types.h:typedef int ___wchar_t; >> sys/sparc64/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/sparc64/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >> sys/x86/include/_types.h:typedef int ___wchar_t; >> sys/x86/include/_types.h:#define __WCHAR_MIN __INT_MIN = /* min value for a wchar_t */ >> sys/x86/include/_types.h:#define __WCHAR_MAX __INT_MAX = /* max value for a wchar_t */ >>=20 >> So only arm and arm64 have unsigned wchar_t types. >>=20 >> [NOTE: __CHAR16_TYPE__ and __CHAR32_TYPE__ are always unsigned: in = C++11 terms char16_t is like std::uint_least16_t and char32_t is like = std::uint_least32_t despite being distinct types. So __CHAR16_TYPE__ and = __CHAR32_TYPE__ are ignored below.] >>=20 >> The clang 3.8.0 compiler output has an odd mix for = TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 . . . >>=20 >> armv6 has unsigned types for both char and __WCHAR_TYPE__. >> aarch64 has unsigned types for both char and __WCHAR_TYPE__. >> powerpc has unsigned for char but signed for __WCHAR_TYPE__. >> powerpc64 has unsigned for char but signed for __WCHAR_TYPE__. >> amd64 has signed types for both char and __WCHAR_TYPE__. >> i386 has signed types for both char and __WCHAR_TYPE__. >> mips has signed types for both char and __WCHAR_TYPE__. >> sparc64 has signed types for both char and __WCHAR_TYPE__. >> (riscv is not covered by clang as I understand) >>=20 >> The details via compiler #define's. . . >>=20 >> # clang --target=3Darmv6-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 4294967295U >> #define __WCHAR_TYPE__ unsigned int >> #define __WCHAR_UNSIGNED__ 1 >> #define __WCHAR_WIDTH__ 32 >> . . . >>=20 >> # clang --target=3Daarch64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 4294967295U >> #define __WCHAR_TYPE__ unsigned int >> #define __WCHAR_UNSIGNED__ 1 >> #define __WCHAR_WIDTH__ 32 >> . . . >>=20 >> # clang --target=3Dpowerpc-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> Is powerpc wrong? >>=20 >> # clang --target=3Dpowerpc64-freebsd11 -std=3Dc99 -E -dM - < = /dev/null | more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> #define __CHAR_UNSIGNED__ 1 >> . . . >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> Is powerpc64 wrong? >>=20 >>=20 >> # clang --target=3Damd64-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> # clang --target=3Di386-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >>=20 >> # clang --target=3Dmips-freebsd11 -std=3Dc99 -E -dM - < /dev/null | = more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >> # clang --target=3Dsparc64-freebsd11 -std=3Dc99 -E -dM - < /dev/null = | more >> . . . >> #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ >> . . . >> #define __CHAR_BIT__ 8 >> . . . (note the lack of __CHAR_UNSIGNED__) . . . >>=20 >> #define __WCHAR_MAX__ 2147483647 >> #define __WCHAR_TYPE__ int >> #define __WCHAR_WIDTH__ 32 >> . . . (note the lack of __WCHAR_UNSIGNED__) . . . >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net From owner-freebsd-stable@freebsd.org Thu Jul 14 15:07:12 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C053FB973EE for ; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9B44C1EA6 for ; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 96ECCB973EC; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91F32B973EB; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) 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 601881EA5; Thu, 14 Jul 2016 15:07:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: by mail-pa0-x232.google.com with SMTP id ks6so29581313pab.0; Thu, 14 Jul 2016 08:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=5PofZBAjQPsf29zDC0ldF6TNt6C4W2cSYcs9f8dQEsM=; b=UP91dJB9mvIQzm34CGJ31f18tB5sxR4zFBp6hKb3yAkKTXIc0zU6P02acvbHkedqHP CmzURlpREtNpPzHDUyJtufGG6v/alhWKFLheFxZ8Ka64zdIs0QkNhA6HwyM8kEZKGIJV O/zwHiWwE1zASw1u29fWBSkF5H/QnTbVyfj91MasyTO5AP0Lp3rgCRsNmN9pkJmj0WlO TsvrrfJLosf1/QavMDeXzujyUjlGFwaG9JHohUgC/5nBoI115Hdhahsx274INVft/2vO wBwnFZrKIP9NYlh2Q3jBW2MYdk8i4rkzufgGDPZm7eJd9A73cLpg684RO2TzplXWeUkd hjvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=5PofZBAjQPsf29zDC0ldF6TNt6C4W2cSYcs9f8dQEsM=; b=LPhVb+Wa0s0KIfO2RQ2ruZynSzDJdyVqGWKZ8k9mjKCU81jLpKi1oWtj7Gl2mSdLR6 oLjhFJWUBvvG8byPzkf0Gi8e90Vjya/sedybJwXLtQwPUpA3M8vfF/6Lzo4kx/xxass6 sCUsIW96exE0NX185PPhQg3E+XHeWCPOSyYVbDSik9xX/Tel1r6E3APdEqgZtIyXtqF9 2OUg5sobfbwQXwTzlx4JFkTJKATD9i9yhlr8Pq51nq2f8aqGNdOTtxveD+kqLXbiWntq bUUpClFfGib1FtwLIsAx4Xp2UwOfJWzFd02q61Thp4s+pWmOsjGTU4p641WUr4fifZxt wWzg== X-Gm-Message-State: ALyK8tKyNvEJO7XkODF/G8qjljMXarNDSyP3TUZg+owlgzhB3r3BIJmBoXq2ftq55kmzhA== X-Received: by 10.66.242.166 with SMTP id wr6mr23420413pac.147.1468508831752; Thu, 14 Jul 2016 08:07:11 -0700 (PDT) Received: from [192.168.20.9] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 9sm2424257pfo.74.2016.07.14.08.07.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jul 2016 08:07:10 -0700 (PDT) From: Ngie Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: LINT tinderbox failure on ^/stable/10 with arm Date: Thu, 14 Jul 2016 08:07:09 -0700 Message-Id: Cc: stable@freebsd.org To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:07:12 -0000 Hi, I=E2=80=99ve been running =E2=80=9Cmake tinderbox=E2=80=9D = periodically on ^/stable/10 and noticed that arm.LINT has been failing = recently with kbdmux(4) at link time. I=E2=80=99ve included the failing = context below (this also can be found at = https://people.freebsd.org/~ngie/tinderbox-arm-LINT-failure.txt ). Could someone please look in to this issue? Thanks, -Ngie kbdmux.o: In function `kbdmux_modevent': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x18): undefined = reference to `kbd_get_switch' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x34): undefined = reference to `kbd_find_keyboard' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x38): undefined = reference to `kbd_get_keyboard' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x58): undefined = reference to `kbd_detach' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x74): undefined = reference to `kbd_delete_driver' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x94): undefined = reference to `kbd_add_driver' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xa8): undefined = reference to `kbd_get_switch' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x118): undefined = reference to `kbd_delete_driver' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x134): undefined = reference to `kbd_attach' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x190): undefined = reference to `kbd_detach' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1a8): undefined = reference to `kbd_delete_driver' kbdmux.o: In function `kbdmux_init': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x284): undefined = reference to `kbd_init_struct' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x2f8): undefined = reference to `kbd_set_maps' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x408): undefined = reference to `kbd_register' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x618): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_term': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x6c4): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x6f4): undefined = reference to `kbd_unregister' kbdmux.o: In function `kbdmux_read_char': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xcbc): undefined = reference to `genkbd_keyaction' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xdec): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_ioctl': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1024): undefined = reference to `kbd_allocate' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1028): undefined = reference to `kbd_get_keyboard' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1104): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1304): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1600): undefined = reference to `genkbd_commonioctl' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1694): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_poll': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x17c4): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_kbd_event': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1810): undefined = reference to `kbd_release' /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x197c): undefined = reference to `kbdsw' kbdmux.o: In function `kbdmux_kbd_intr': /scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x19d4): undefined = reference to `kbdsw' kbdmux.o:(.data+0x24cc): undefined reference to `genkbd_get_fkeystr' kbdmux.o:(.data+0x24d4): undefined reference to `genkbd_diag' --- kernel --- *** [kernel] Error code 1= From owner-freebsd-stable@freebsd.org Thu Jul 14 16:11:09 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEF6FB98C1E for ; Thu, 14 Jul 2016 16:11:09 +0000 (UTC) (envelope-from lists@opsec.eu) 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 7362A1BFE for ; Thu, 14 Jul 2016 16:11:09 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bNjED-000F5V-Uq; Thu, 14 Jul 2016 18:11:09 +0200 Date: Thu, 14 Jul 2016 18:11:09 +0200 From: Kurt Jaeger To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F Message-ID: <20160714161109.GA36995@home.opsec.eu> References: <577282AA.5080803@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577282AA.5080803@quip.cz> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:11:09 -0000 Hi! > I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It > sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2. > > The booting is painfully slow from BTX to menu to kernel loading. I have the same problem on a Supermicro X11SSH-LN4F. > Progress indicated by \ | / - characters is changing by speed of 1 > character per 2 seconds. > The whole boot process takes about 10 minutes. > > I found this blog post solving the same problem > http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/ I'll test that solution. Thanks for the pointer! -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-stable@freebsd.org Thu Jul 14 16:59:13 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 366DDB99BBA for ; Thu, 14 Jul 2016 16:59:13 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF0931562 for ; Thu, 14 Jul 2016 16:59:12 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 2E0A128411; Thu, 14 Jul 2016 18:53:17 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1873328416; Thu, 14 Jul 2016 18:53:16 +0200 (CEST) Message-ID: <5787C37B.1050100@quip.cz> Date: Thu, 14 Jul 2016 18:53:15 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: Kurt Jaeger CC: freebsd-stable@freebsd.org Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F References: <577282AA.5080803@quip.cz> <20160714161109.GA36995@home.opsec.eu> In-Reply-To: <20160714161109.GA36995@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:59:13 -0000 Kurt Jaeger wrote on 07/14/2016 18:11: > Hi! > >> I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It >> sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2. >> >> The booting is painfully slow from BTX to menu to kernel loading. > > I have the same problem on a Supermicro X11SSH-LN4F. > >> Progress indicated by \ | / - characters is changing by speed of 1 >> character per 2 seconds. >> The whole boot process takes about 10 minutes. >> >> I found this blog post solving the same problem >> http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/ > > I'll test that solution. Thanks for the pointer! If there will not be 10.4 Release, there is nothing to fix, because 11.0 works, I know... But still - is this something already known and fixed in 11 loader or is it something fixed by coincidence? Can it be covered by some regression test? Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Jul 14 18:36:38 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3544B99725 for ; Thu, 14 Jul 2016 18:36:38 +0000 (UTC) (envelope-from lists@opsec.eu) 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 6A0151AB5 for ; Thu, 14 Jul 2016 18:36:38 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bNlV2-000FMT-LF; Thu, 14 Jul 2016 20:36:40 +0200 Date: Thu, 14 Jul 2016 20:36:40 +0200 From: Kurt Jaeger To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F Message-ID: <20160714183640.GB36995@home.opsec.eu> References: <577282AA.5080803@quip.cz> <20160714161109.GA36995@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160714161109.GA36995@home.opsec.eu> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:36:38 -0000 Hi! > > I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It > > sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2. > > > > The booting is painfully slow from BTX to menu to kernel loading. > > I have the same problem on a Supermicro X11SSH-LN4F. > > I found this blog post solving the same problem > > http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/ > > I'll test that solution. Thanks for the pointer! Tested, works -- I took the 12.0-CURRENT boot files: gpart bootcode -b pmbr ada0 gpart -p gptzfsboot -i 1 ada0 cp zfsloader /boot/zfsloader Before: ca. 660 seconds to reboot, now 77 seconds to reboot. Now, if someone could explain, why... -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-stable@freebsd.org Thu Jul 14 18:38:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E686B9989D; Thu, 14 Jul 2016 18:38:57 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thebighonker.lerctr.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F19D31DCC; Thu, 14 Jul 2016 18:38:56 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5SHJyHjq/To9kHFPY0001gkHBoc42AcAgbSGL8IPkcA=; b=JejMhWH0Piey56YBN72mtmoot8 V4u8sNfh//WO7hKiE4ROmp0PXQ+ULigegG2I8zb0M8snAN4CkyC8F6UGXD5+VnXCY3NgYwehcGPqj 0sBtx6gBNmG6k0O7priIQZks+4EViRYvLx1pk45t5g+DS8FOQfYTBkUzl7eXe2x0itc4=; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:223:7dff:fe9e:6e8a]:55532 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bNlXA-000CxY-Ca; Thu, 14 Jul 2016 13:38:52 -0500 Received: from proxy.na.alcatel-lucent.com ([135.245.48.74]) by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 14 Jul 2016 13:38:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 14 Jul 2016 13:38:52 -0500 From: Larry Rosenman To: Kurt Jaeger Cc: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org, owner-freebsd-stable@freebsd.org Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F In-Reply-To: <20160714183640.GB36995@home.opsec.eu> References: <577282AA.5080803@quip.cz> <20160714161109.GA36995@home.opsec.eu> <20160714183640.GB36995@home.opsec.eu> Message-ID: X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.2.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:38:57 -0000 On 2016-07-14 13:36, Kurt Jaeger wrote: > Hi! > >> > I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It >> > sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2. >> > >> > The booting is painfully slow from BTX to menu to kernel loading. >> >> I have the same problem on a Supermicro X11SSH-LN4F. > >> > I found this blog post solving the same problem >> > http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/ >> >> I'll test that solution. Thanks for the pointer! > > Tested, works -- I took the 12.0-CURRENT boot files: > > gpart bootcode -b pmbr ada0 > gpart -p gptzfsboot -i 1 ada0 > cp zfsloader /boot/zfsloader > > Before: ca. 660 seconds to reboot, now 77 seconds to reboot. > > Now, if someone could explain, why... there were some buffering changes and other stuff in the boot blocks/loader. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 From owner-freebsd-stable@freebsd.org Thu Jul 14 18:39:11 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F066BB998F0 for ; Thu, 14 Jul 2016 18:39:10 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA1CC1EC6 for ; Thu, 14 Jul 2016 18:39:10 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id p74so80727409qka.0 for ; Thu, 14 Jul 2016 11:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GDZLG2vy8UKiBKhDuiUvuSSk3cbVdSAV6XOpq438xpQ=; b=OWRopQkPTujXdQIEeWxnCAuc/DIJMJRbSLCzM3LvkIxcXkrIeFAhCUSrD1CTWXKltK fJwyOnR58xP0y86764HfgPc06QfKI/T17Zw411oB5EjSbcSsflqTIjbhHkHgkDZdtAvv 2orV6QQIkq2XljkpilQWERkCO5nb/tA5sk93iORn6BVnlvLUpQn+ymx5eX1MqS1LKWyM u4ILT4B13T8jPRWjUMOfU7T1+nKsR0n8bCMucazppRTqH7D+CI1Gy6LCxsWgu6gCEUst CNP0EiMQ/CMmoaRz1GSQiDIpDvjs9uULWrRxBtK7FR1xjjevRlhTdW7SvNNU0CEmbXf7 bO7g== 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; bh=GDZLG2vy8UKiBKhDuiUvuSSk3cbVdSAV6XOpq438xpQ=; b=KkYcU3BFGvI5wNrIb6wanxMDQKCR2zrDRlu0ijtTqQJurcyG+1L9FWiOtBwJLhBRi7 3tZD7c3cpxc5lSwB1mW4p40UM8AoG+BydO7FWiBzCIhAwOdFh8IXeNy1lGTXdb49r8YW jfhIc8bzqI85xSYWE5xdIZ/U42Hbbw/72W42Rz07q/6susKWEhazA0QU+bNUn1sOQZxR NdkPXbsJSSky0q3UQjfWncjZqWnI0IXutp3sWqrOECAq3BttW3fJz941fzwjUI5Yysk4 G/e+eWGaxDt4zv8yCDfFsG+pof6Q38/AiMN0e7Lx711WAoRoU5u0Tzjo94GnoBy9Atk1 yJVQ== X-Gm-Message-State: ALyK8tIrNtWKt2ypeqlnjcyMRyujchDfyx/i/4/QyUoPWJunChuS76B8XtdTAJyKO2JT9nWgh6PXQz6krMb1aw== X-Received: by 10.55.113.197 with SMTP id m188mr15614183qkc.90.1468521549832; Thu, 14 Jul 2016 11:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.42.8 with HTTP; Thu, 14 Jul 2016 11:39:09 -0700 (PDT) In-Reply-To: <20160714183640.GB36995@home.opsec.eu> References: <577282AA.5080803@quip.cz> <20160714161109.GA36995@home.opsec.eu> <20160714183640.GB36995@home.opsec.eu> From: Brandon Allbery Date: Thu, 14 Jul 2016 14:39:09 -0400 Message-ID: Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F To: Kurt Jaeger Cc: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:39:11 -0000 On Thu, Jul 14, 2016 at 2:36 PM, Kurt Jaeger wrote: > Before: ca. 660 seconds to reboot, now 77 seconds to reboot. > Now, if someone could explain, why... > https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865.html -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-stable@freebsd.org Thu Jul 14 18:42:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEBEEB99C1E for ; Thu, 14 Jul 2016 18:42:19 +0000 (UTC) (envelope-from lists@opsec.eu) 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 90E9614BD for ; Thu, 14 Jul 2016 18:42:19 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.87 (FreeBSD)) (envelope-from ) id 1bNlaY-000FO7-Dk; Thu, 14 Jul 2016 20:42:22 +0200 Date: Thu, 14 Jul 2016 20:42:22 +0200 From: Kurt Jaeger To: Brandon Allbery Cc: freebsd-stable Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F Message-ID: <20160714184222.GC36995@home.opsec.eu> References: <577282AA.5080803@quip.cz> <20160714161109.GA36995@home.opsec.eu> <20160714183640.GB36995@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 18:42:19 -0000 Hi! > > Before: ca. 660 seconds to reboot, now 77 seconds to reboot. > > Now, if someone could explain, why... > https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865.html Any pointer to a commit or three that fixed it ? -- pi@opsec.eu +49 171 3101372 4 years to go ! From owner-freebsd-stable@freebsd.org Thu Jul 14 19:18:47 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 861BAB996FC for ; Thu, 14 Jul 2016 19:18:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 49DBD1B9E for ; Thu, 14 Jul 2016 19:18:46 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: bc73dd3a-49f7-11e6-a0ff-e511cd071b9b X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 14 Jul 2016 19:18:24 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6EJHagl007110; Thu, 14 Jul 2016 13:17:36 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468523856.72182.221.camel@freebsd.org> Subject: Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F From: Ian Lepore To: Kurt Jaeger , Brandon Allbery Cc: freebsd-stable Date: Thu, 14 Jul 2016 13:17:36 -0600 In-Reply-To: <20160714184222.GC36995@home.opsec.eu> References: <577282AA.5080803@quip.cz> <20160714161109.GA36995@home.opsec.eu> <20160714183640.GB36995@home.opsec.eu> <20160714184222.GC36995@home.opsec.eu> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 19:18:47 -0000 On Thu, 2016-07-14 at 20:42 +0200, Kurt Jaeger wrote: > Hi! > > > > Before: ca. 660 seconds to reboot, now 77 seconds to reboot. > > > Now, if someone could explain, why... > > > https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865 > > .html > > Any pointer to a commit or three that fixed it ? > I think this is the one... https://svnweb.freebsd.org/base?view=revision&revision=298230 -- Ian From owner-freebsd-stable@freebsd.org Thu Jul 14 19:59:25 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB02DB99160 for ; Thu, 14 Jul 2016 19:59:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id BCE2812EA; Thu, 14 Jul 2016 19:59:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BEDA71F7; Thu, 14 Jul 2016 19:59:25 +0000 (UTC) Date: Thu, 14 Jul 2016 19:59:24 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <2020493537.70.1468526364836.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <794432070.66.1468482768252.JavaMail.jenkins@jenkins-9.freebsd.org> References: <794432070.66.1468482768252.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #315 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 19:59:25 -0000 See From owner-freebsd-stable@freebsd.org Fri Jul 15 00:08:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DE5AB99D65; Fri, 15 Jul 2016 00:08:59 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F37FD1D5C; Fri, 15 Jul 2016 00:08:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 9E9C31662; Fri, 15 Jul 2016 00:08:58 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 15 Jul 2016 00:08:57 +0000 From: Glen Barber To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Cc: FreeBSD Release Engineering Team Subject: Re: 11.0-BETA2 may be delayed Message-ID: <20160715000857.GT4690@FreeBSD.org> References: <20160713231017.GA95249@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tbn31orTZdSAVHoc" Content-Disposition: inline In-Reply-To: <20160713231017.GA95249@FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 00:08:59 -0000 --tbn31orTZdSAVHoc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2016 at 11:10:17PM +0000, Glen Barber wrote: > As I am sure you have already seen, there is an issue in 11.0-BETA1 that > has caused some headaches for people. >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210884 >=20 > The issue is actively being investigated, and despite the KBI freeze, > the fix may need to break KBI in stable/11, at least as far as I am > aware at the moment. >=20 > That said, 11.0-BETA2 may be delayed, while this is properly resolved. > If KBI is changed between 11.0-BETA1 and 11.0-BETA2, it will be noted in > the announcement. >=20 The latest patch for this issue seems promising so far, but for the sake of being cautious, 11.0-BETA2 is going to be delayed by a few days. The rationale is that we want to see the affected machines survive uptime of at least 48 hours. At this point, we are looking at the fix being committed in just over one day, followed by the normal 3-day MFC timeframe. If this changes, an update will be emailed. Apologies again for the delay with 11.0-BETA2, and thank you for your patience. Glen On behalf of: re@ --tbn31orTZdSAVHoc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXiCmZAAoJEAMUWKVHj+KTqdoQAJ0kOIrG4o7Je/nR9lCSaEUL 3t496ej9OLPHXoM6h6Ldn8QvfPb37Co4PuCmlwXItyN04Jxb5bfhYFMwiszMqwjL VdLQ9cBgTR4JPuXd2pFBmo/6Vwkr+cPfGg69+ety80S9yyEdmvoNc0HjYrPizfj9 M7DkVJaW4L2vlvmdMz82Z/dD3jsX/ZcXJDL1/XNlK3P+Fb/RnPh6Du9CsRCkTft1 mOQwRZ28kbnXl1+VrfM5Kk1k/2bThJBbbvZItkHCVxI3bNoUlv3+CsrKGgPYiiZw UHKA56JPBjQcbkPICvW8HrdlU/1GlwMDRjxlw0YXL7qhO3PCGefYy5pMt7JQG8fd I2qv5Oc/vBSAJkVmF5kKc3e1jbw3fWDDEsY0IU80aT68M3g9EZ8vA9fDQPUppIwJ //DU0X8ICqbLr47yGeiJom+CmodcecuTmqA8cETqe+drBbDqRtkgO6P/f/28yLGx aLSpXbixhqCvj4q+6PlHyZ31MUEmwjiwAKEydCsK3aUuvHzJPMuYVJWv3x9yVU05 cr+lECOsKt8Y7U3DV6ikGmgmhvnBnvKYigSbhPsl+PCvOKliIk7WsqIAmQkLAF6l 8oMGJPb66xOhINTsVTgDlo5jQSMlnEm1d7MlTsjZ1qRpLHKR0ZH7QoIegu886AP1 zslJ2KTZg0t0QaHricBa =eNmW -----END PGP SIGNATURE----- --tbn31orTZdSAVHoc-- From owner-freebsd-stable@freebsd.org Fri Jul 15 04:57:19 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4CE7B97981 for ; Fri, 15 Jul 2016 04:57:19 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id D3E641F80; Fri, 15 Jul 2016 04:57:19 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id F396F207; Fri, 15 Jul 2016 04:57:19 +0000 (UTC) Date: Fri, 15 Jul 2016 04:57:19 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1910762865.71.1468558639329.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2020493537.70.1468526364836.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2020493537.70.1468526364836.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #316 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 04:57:20 -0000 See From owner-freebsd-stable@freebsd.org Fri Jul 15 12:12:38 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0B14B9A9A0 for ; Fri, 15 Jul 2016 12:12:38 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from nm50.bullet.mail.gq1.yahoo.com (nm50.bullet.mail.gq1.yahoo.com [67.195.87.86]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B95101789 for ; Fri, 15 Jul 2016 12:12:38 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468584752; bh=BK48L79zbvE4ZOnrlWPGDWgvsCdB02PI7X3VFyMMXE4=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=dRCv7MX+MAZmqYjOKDgU8t5iEgr7Gp4N72uiLtWYk7JyPNPx5Skdy4JWC8nSWqX0QT9JD1coizeDB37EFoS4BA5DRV8ZvsDXnijNUEj0SL/oBe2IEoCtjMgUE7uv0G4y3lkZAQXo14pHvmT2U+C9Al7rx8MYvn1EhYZpAN9xJCPc0566/ghIOjnHH2iwQpZUKZ/b+L8m4i37Ti75sSUCpY2D3USFXkqS9bXSZrNLvW0ac8CugjMGB/wmqhVkBsJmuUxroF3ZQYwXByDGmnxHSEMEZko0oeVfhez7WBIbVHo+lJmn+PnSUIw57wzFk81fwx+7d7oWnfmRB32xaWSiVQ== Received: from [127.0.0.1] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2016 12:12:32 -0000 Received: from [98.137.12.174] by nm50.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2016 12:09:49 -0000 Received: from [66.196.81.170] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 15 Jul 2016 12:09:49 -0000 Received: from [98.139.212.221] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jul 2016 12:09:48 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 15 Jul 2016 12:09:48 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 854094.49419.bm@omp1030.mail.bf1.yahoo.com X-YMail-OSG: LB3G_UwVM1nPYfXoGr6rJLYkdHGLPyUp9YxUn4q2r50rMIIGJiOawaAu4UEbWvx y0AVCzK7NHqLHXltnV5x9OGF81lV7dPnzhYdmtg4GJocaLUz3UGOD_2luh9qbbmnmWqEYJOJ85OG aErzm_XRhHKwoExtni5p94JGbyIpeuUHkXD33YMx0qtm37eG5VOD59AScxFxc.0Bk4G1ehyF7gci m8qkPnBymezeB_OyLOxhwbSqH_zfLGG4gOnQ0ulxxfak3hXwrXHf5qUBlKZla760XAE1wJ0PJ9ZE 9aQhaXLfj2A4QALVUIXtnWLj_R3cB_rlRhPblTijCJLxe5VMDUfeoVYkeL0P2gum.6mHwE2vgxwV x.c8Vlk55tJ8n3z2tFLXcjlE6XS3lh00oIpVzjjMP2weW3P0Wy6LWp0dWiHHS5t4l6LBvCg2Su0b Cz04lA5cuMWIEbeiyl8B5iXNyRFPYBnhazi1CxYSiPzY1KNDvF1Wlf4LB_UYr5zlT_h1LtKicMvs AzST_dp2kZ2YDHMfiVWU_LRWQ3GsMZcTZoQ-- Received: from jws106223.mail.bf1.yahoo.com by sendmailws129.mail.bf1.yahoo.com; Fri, 15 Jul 2016 12:09:48 +0000; 1468584588.388 Date: Fri, 15 Jul 2016 12:09:44 +0000 (UTC) From: Filippo Moretti Reply-To: Filippo Moretti To: "freebsd-stable@FreeBSD.org" Message-ID: <1167694931.3702710.1468584584907.JavaMail.yahoo@mail.yahoo.com> Subject: Problem with FreeBSD-11.0-Beta1 MIME-Version: 1.0 References: <1167694931.3702710.1468584584907.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 12:12:39 -0000 I have the following problem when I start the system:Unknown user name "ava= hi"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in message bus confi= guration fileUnknown user name "polkitd" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in me= ssage bus configuration file Unknown user name "polkitd" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in message = bus configuration fileUnknown user name "colord" =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 in message bus configuration file Unknown user name "pulse" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in= message bus configuration fileUnknown user name "polkit" =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in message bus configuration fileUnknown use= r name "haldaemon" =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 in message bus configuration fileFailed to start message bus:Could n= ot get VID and GID for username "messagebus"/etc/rc:Warning:failed to start= dbusOn the same computer I have a disk with 10.3_STABLE with the same conf= iguration files and everything is working properly.When in X=C2=A0 I launch= firefox I get the following errorLibGL error: failed to open drm device:Pe= rmission deniedLibGL error :failed to load driver: r 300This is verylikely = due to failure to start dbus.sincerelyFilippo From owner-freebsd-stable@freebsd.org Fri Jul 15 13:55:50 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1D6FB9963B for ; Fri, 15 Jul 2016 13:55:50 +0000 (UTC) (envelope-from sneakywumpus@gmail.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 3532811B0 for ; Fri, 15 Jul 2016 13:55:50 +0000 (UTC) (envelope-from sneakywumpus@gmail.com) Received: by mail-wm0-x241.google.com with SMTP id x83so2249249wma.3 for ; Fri, 15 Jul 2016 06:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=VI2QEilAZagi7+GOVC7wScAWFF0+wNqMUDswX0QT0oU=; b=V8GUThXPHOwASIxdSXVDHQPCfSPj1ZGD2AUe+AJneYd211OG93UlPnE02Qnmb90wBV aXONsp1wivS/GOOBTpdBPBt5Z4Jn75HjBdisT2kCnCPPHVRw8Jk6e4M43y/Cap95uCUm eVE1Ud5aysaEzLCqU8fZL5bPTp7DAR9+P7RIrcJslsdcQQC/pBI4zLf8nZj4D7GpkMps hJmbCsbgLJpmhlryCnOyYLPv6TfTVTU5qdL5AqrZtG9DHQ50EvvYquMt+QBdfwRN+81N C+DY2tE+LdCL1YcdRfqjwBStSNTtKT+l6dCUkvgCqCu88pUMznf2xRcr32WvyfV+7W46 yzXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=VI2QEilAZagi7+GOVC7wScAWFF0+wNqMUDswX0QT0oU=; b=A1edj95oC6HZaq1UwgUg3L+owZr4YW1NHQ0IGCN4NhjRn4Bqdm8lPKQ+vvgfHDPzLS kgsJVYwN6m8u6JtnWeaqrLz1qRzplpRb6Eng+0v1wrxFDYsgs+dHf9qGyjgPzxeMluHU TpJ7UKgy0tR3VYNQCzR81QHBgkXczOCPnoMBM3J+t+NXlqP4EUfUKkSQ9+p0by6EF6gS HbjZP1yAKaJu0heG27ki0ZRUkgxLGM3+bFhjqXeFx+MUQ7GNZmpoomtJLCtTnc3sXX/l 4Ui5LtT6oB6miDhz3JgiYUo299w98lZrk8HqXCPrK/I7mOMVFn1lEZ+mI8Tuchmf99yS ApWg== X-Gm-Message-State: ALyK8tKteG4o9YKN8UlrWj3IV62aghZcKSHiyBs9x8yUwlA1slQ3iw9UuOLFO+6q7KOF+w== X-Received: by 10.28.32.15 with SMTP id g15mr34516573wmg.25.1468590947991; Fri, 15 Jul 2016 06:55:47 -0700 (PDT) Received: from ed209.ocp.lan (ip4d1669a4.dynamic.kabel-deutschland.de. [77.22.105.164]) by smtp.gmail.com with ESMTPSA id q203sm6026579wmd.24.2016.07.15.06.55.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jul 2016 06:55:47 -0700 (PDT) From: Thomas Eberhardt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: stable/11 Problems with Unicode character and ls(1) sorting Message-Id: Date: Fri, 15 Jul 2016 15:55:46 +0200 To: freebsd-stable@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 13:55:50 -0000 % uname -a FreeBSD clarence.ocp.lan 11.0-BETA1 FreeBSD 11.0-BETA1 #0 r302457: Sat = Jul 9 10:41:40 CEST 2016 = thomas@clarence.ocp.lan:/usr/obj/usr/src/sys/GENERIC amd64 % locale LANG=3Den_US.UTF-8 LC_CTYPE=3D"en_US.UTF-8" LC_COLLATE=3D"en_US.UTF-8" LC_TIME=3D"en_US.UTF-8" LC_NUMERIC=3D"en_US.UTF-8" LC_MONETARY=3D"en_US.UTF-8" LC_MESSAGES=3D"en_US.UTF-8" LC_ALL=3D % mkdir x % touch x/=C3=86on1 % ls x =C3=86on1 % touch x/=C3=86on2 % ls -f x=20 . .. =C3=86on1 =C3=86on2 % ls -f x | hd 00000000 2e 0a 2e 2e 0a c3 86 6f 6e 31 0a c3 86 6f 6e 32 = |.......on1...on2| 00000010 0a |.| 00000011 % ls x [hangs and consumes 100% CPU] ^C % gdb /bin/ls [=E2=80=A6] (gdb) run x Starting program: /bin/ls x [hangs] ^C Program received signal SIGINT, Interrupt. 0x0000000800ffa9dd in _collate_lookup (table=3D, = t=3D,=20 len=3D, pri=3D, = which=3D, state=3D) at /usr/src/lib/libc/locale/collate.c:340 340 *pri =3D table->char_pri_table[*t].pri[which]; Current language: auto; currently minimal (gdb) bt #0 0x0000000800ffa9dd in _collate_lookup (table=3D, t=3D,=20 len=3D, pri=3D, = which=3D, state=3D) at /usr/src/lib/libc/locale/collate.c:340 #1 0x0000000800fdc38a in wcscoll_l (ws1=3D, = ws2=3D,=20 locale=3D) at = /usr/src/lib/libc/string/wcscoll.c:158 #2 0x0000000800fd9071 in strcoll_l (s=3D, = s2=3D, locale=3D0x80124f338) at /usr/src/lib/libc/string/strcoll.c:101 #3 0x0000000800fee253 in qsort (a=3D, n=3D, es=3D,=20 cmp=3D0x800f28530 ) at = /usr/src/lib/libc/stdlib/qsort.c:130 #4 0x0000000800f27397 in fts_sort (sp=3D, = head=3D, nitems=3D) at /usr/src/lib/libc/gen/fts.c:995 #5 0x0000000800f2848e in fts_children (sp=3D, = instr=3DError accessing memory address 0x2: Bad address. ) at /usr/src/lib/libc/gen/fts.c:570 #6 0x00000000004030df in traverse (argc=3D, = argv=3D,=20 options=3D) at /usr/src/bin/ls/ls.c:576 #7 0x0000000000402eeb in main (argc=3D, = argv=3D) at /usr/src/bin/ls/ls.c:498 #8 0x00000000004020cf in _start () #9 0x0000000800629000 in ?? () #10 0x0000000000000000 in ?? () (gdb) br strcoll.c:101 Breakpoint 1 at 0x800fd9063: file /usr/src/lib/libc/string/strcoll.c, = line 101. (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /bin/ls x [=E2=80=A6] Breakpoint 1, strcoll_l (s=3D, s2=3D, locale=3D0x80124f338) at /usr/src/lib/libc/string/strcoll.c:101 101 ret =3D wcscoll_l(w1, w2, locale); (gdb) n [wcscoll_l never returns] Does anybody know what=E2=80=99s going on? This is on a ZFS filesystem = if that matters. Regards, Thomas Eberhardt From owner-freebsd-stable@freebsd.org Fri Jul 15 15:38:27 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3134B9954A for ; Fri, 15 Jul 2016 15:38:27 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 575A2188D; Fri, 15 Jul 2016 15:38:27 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: stable/11 Problems with Unicode character and ls(1) sorting To: Thomas Eberhardt , freebsd-stable@FreeBSD.org References: Cc: Baptiste Daroussin From: Jung-uk Kim Message-ID: Date: Fri, 15 Jul 2016 11:38:22 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EHAhWNSRlEopsxoJ6afFHvVWNgr0dCtO9" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 15:38:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EHAhWNSRlEopsxoJ6afFHvVWNgr0dCtO9 Content-Type: multipart/mixed; boundary="fGi1SI2nssCwtSl8pmgd2W25sg5kBhp0b" From: Jung-uk Kim To: Thomas Eberhardt , freebsd-stable@FreeBSD.org Cc: Baptiste Daroussin Message-ID: Subject: Re: stable/11 Problems with Unicode character and ls(1) sorting References: In-Reply-To: --fGi1SI2nssCwtSl8pmgd2W25sg5kBhp0b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/15/16 09:55 AM, Thomas Eberhardt wrote: > % uname -a > FreeBSD clarence.ocp.lan 11.0-BETA1 FreeBSD 11.0-BETA1 #0 r302457: Sat = Jul 9 10:41:40 CEST 2016 thomas@clarence.ocp.lan:/usr/obj/usr/src/sy= s/GENERIC amd64 >=20 > % locale > LANG=3Den_US.UTF-8 > LC_CTYPE=3D"en_US.UTF-8" > LC_COLLATE=3D"en_US.UTF-8" > LC_TIME=3D"en_US.UTF-8" > LC_NUMERIC=3D"en_US.UTF-8" > LC_MONETARY=3D"en_US.UTF-8" > LC_MESSAGES=3D"en_US.UTF-8" > LC_ALL=3D >=20 > % mkdir x > % touch x/=C3=86on1 > % ls x > =C3=86on1 > % touch x/=C3=86on2 > % ls -f x=20 > . .. =C3=86on1 =C3=86on2 > % ls -f x | hd > 00000000 2e 0a 2e 2e 0a c3 86 6f 6e 31 0a c3 86 6f 6e 32 |.......on1= =2E..on2| > 00000010 0a |.| > 00000011 > % ls x > [hangs and consumes 100% CPU] > ^C >=20 > % gdb /bin/ls > [=E2=80=A6] > (gdb) run x > Starting program: /bin/ls x > [hangs] > ^C > Program received signal SIGINT, Interrupt. > 0x0000000800ffa9dd in _collate_lookup (table=3D, t= =3D,=20 > len=3D, pri=3D, which=3D<= value optimized out>, state=3D) > at /usr/src/lib/libc/locale/collate.c:340 > 340 *pri =3D table->char_pri_table[*t].pri[which]; > Current language: auto; currently minimal > (gdb) bt > #0 0x0000000800ffa9dd in _collate_lookup (table=3D, t=3D,=20 > len=3D, pri=3D, which=3D<= value optimized out>, state=3D) > at /usr/src/lib/libc/locale/collate.c:340 > #1 0x0000000800fdc38a in wcscoll_l (ws1=3D, ws2=3D= ,=20 > locale=3D) at /usr/src/lib/libc/string/wcscoll= =2Ec:158 > #2 0x0000000800fd9071 in strcoll_l (s=3D, s2=3D, locale=3D0x80124f338) > at /usr/src/lib/libc/string/strcoll.c:101 > #3 0x0000000800fee253 in qsort (a=3D, n=3D, es=3D,=20 > cmp=3D0x800f28530 ) at /usr/src/lib/libc/stdlib/qsort.c= :130 > #4 0x0000000800f27397 in fts_sort (sp=3D, head=3D= , nitems=3D) > at /usr/src/lib/libc/gen/fts.c:995 > #5 0x0000000800f2848e in fts_children (sp=3D, ins= tr=3DError accessing memory address 0x2: Bad address. > ) at /usr/src/lib/libc/gen/fts.c:570 > #6 0x00000000004030df in traverse (argc=3D, argv=3D= ,=20 > options=3D) at /usr/src/bin/ls/ls.c:576 > #7 0x0000000000402eeb in main (argc=3D, argv=3D) at /usr/src/bin/ls/ls.c:498 > #8 0x00000000004020cf in _start () > #9 0x0000000800629000 in ?? () > #10 0x0000000000000000 in ?? () > (gdb) br strcoll.c:101 > Breakpoint 1 at 0x800fd9063: file /usr/src/lib/libc/string/strcoll.c, l= ine 101. > (gdb) run > The program being debugged has been started already. > Start it from the beginning? (y or n) y > Starting program: /bin/ls x > [=E2=80=A6] >=20 > Breakpoint 1, strcoll_l (s=3D, s2=3D, locale=3D0x80124f338) > at /usr/src/lib/libc/string/strcoll.c:101 > 101 ret =3D wcscoll_l(w1, w2, locale); > (gdb) n > [wcscoll_l never returns] >=20 >=20 > Does anybody know what=E2=80=99s going on? This is on a ZFS filesystem = if that matters. Yes, it is a known problem and bapt is working on it. If you're in hurry, reverting r302324 will fix the regression for now. https://svnweb.freebsd.org/changeset/base/302324 FYI, this problem is tracked as PR211135. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211135 Jung-uk Kim --fGi1SI2nssCwtSl8pmgd2W25sg5kBhp0b-- --EHAhWNSRlEopsxoJ6afFHvVWNgr0dCtO9 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 iQEcBAEBCAAGBQJXiQNzAAoJEHyflib82/FGKcAH/jXYOsFMkhBzU1TW1O7yyQ1A ZWtFXyUT7xtUfzI3bl+Sd89Qadby7BpJ8uFNks0vm53xRWrXlxlUC1BwtNgURHKm KB7DNopZ5dzcBcJNCK2Ce1Hz0d7ZnuRZZ1vnnYBzHqx28ubZ5Vtbi4df7w9tGiSJ UAnaaQChkFiV8nHbxvRPWYUMbiz+aDclLt3kySpU2SI0oTvVxpJm0Cbvwp4oDJmu QNFPpHLm+2APnPS6KXgoYFt0Kkpp92jTOVfTFGkTS7gSf6f9n6oHr3UwGMRs43Ca UxfGuRY5Za+gCuE3h3AkXOBp+BDg9rjosbz1Xhu5WFRzeLLl5N8fzZ35RxxSQq4= =Wa/e -----END PGP SIGNATURE----- --EHAhWNSRlEopsxoJ6afFHvVWNgr0dCtO9-- From owner-freebsd-stable@freebsd.org Fri Jul 15 16:17:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8EBC4B9AAD5 for ; Fri, 15 Jul 2016 16:17:54 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 553D01B96 for ; Fri, 15 Jul 2016 16:17:54 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-io0-x229.google.com with SMTP id m101so108311805ioi.2 for ; Fri, 15 Jul 2016 09:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0eX2mKYD+LCY4HqwfIhQkXj/v+hvFrwppRjWMa6Yfsw=; b=OFF8wl5f04BLwiC2k8Tfjrt9tXl9ptvthIjohxlYTCHhYNKuQSpXepNiHSl/Q3MUII nsRHrAtLguaZKYhvBpxhyD+HrplDJZ0rkoYlQUYFlw3k4ZdEcSGcQiCsGY1sFIWaNtIm jBa1m4u6kzmMM1xAM3squTjhpMkj1taGjoBghuc6RQLgH4gvmU+oB6Z2h1lBWe8+k1iK eGasbrNND+Fn8i7U66gzSBGQYz5ypI/UwYK4mbM69V2V03bBfl3UvAaX1ZIlMGHxW7P1 uegCFrd4GoO/kMVtNRs2RUt84tNxhmRzYEzHVyXKR9PDOWu63Wyix4syAEkvZrNJocB2 VSMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0eX2mKYD+LCY4HqwfIhQkXj/v+hvFrwppRjWMa6Yfsw=; b=XT0Zex4VdIZOqftT2WUeWjj0MMo7NXbcLV8x2rFp3ydXw+Oxff48wWiCYlPao1PjcW T4pdG5eznAOA7etrFGuW4AT8rPLcP60mXe7fSMiPQKNxpudoVW8U4GHhydjO3QZ2EQdT qXVo26rEDp5q0psNCWhkTJ3iI7o4yoOnBZzF0bBl7Ne76UuRo5+DDqj0KQsdW5XKtE8e ynEj9JAF1c9FFjEWN4nmfVgTkagd14YjGFdzsbR8425PRqHo6VPt1NvEoit6IC33o62d 6/4tj2xb/IE4uyX2hTKjuS5xVKfUISbBDIO8cgUe2Z2cQcaknhRxLH6zIWQWchwn4avR CYUw== X-Gm-Message-State: ALyK8tLRxqiKvbtas9VT79F6yRmrLnU8bktEv6o6vfWOBkbnfBGpW2hFsVyX1thSZjYpFjtL37sSXz6d0130Zg== X-Received: by 10.107.129.152 with SMTP id l24mr17476717ioi.179.1468599473693; Fri, 15 Jul 2016 09:17:53 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.78.213 with HTTP; Fri, 15 Jul 2016 09:17:53 -0700 (PDT) In-Reply-To: <1167694931.3702710.1468584584907.JavaMail.yahoo@mail.yahoo.com> References: <1167694931.3702710.1468584584907.JavaMail.yahoo.ref@mail.yahoo.com> <1167694931.3702710.1468584584907.JavaMail.yahoo@mail.yahoo.com> From: Kevin Oberman Date: Fri, 15 Jul 2016 09:17:53 -0700 X-Google-Sender-Auth: RkwgZRp3PhK0IK4DAb04Rq56I2A Message-ID: Subject: Re: Problem with FreeBSD-11.0-Beta1 To: Filippo Moretti Cc: "freebsd-stable@FreeBSD.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 16:17:54 -0000 11.0 has not been released. You are much more likely to get a useful response from current@. On Fri, Jul 15, 2016 at 5:09 AM, Filippo Moretti via freebsd-stable < freebsd-stable@freebsd.org> wrote: > I have the following problem when I start the system: > Unknown user name "avahi" in message bus > configuration fileUnknown user name "polkitd" in message > bus configuration file > Unknown user name "polkitd" in message bus > configuration fileUnknown user name "colord" in message > bus configuration file > Unknown user name "pulse" in message bus > configuration fileUnknown user name "polkit" in > message bus configuration file Unknown user name "haldaemon" in message bus configuration file Failed to start message bus: Could not get VID and GID for username "messagebus" /etc/rc:Warning:failed to start dbus On the same computer I have a disk with 10.3_STABLE with the same > configuration files and everything is working properly.When in X I launch > firefox I get the following errorLibGL error: failed to open drm device:Permission denied LibGL error :failed to load driver: r 300 This is very likely due to failure to start dbus sincerely Filippo Note: I have tried to recover the mail format above. Whatever mail tool you used totally garbled things by removing line breaks. First, how did 11.0Beta-1 get installed? How sis your ports (X11, dbus, pulseaudio, etc.) get installed? When moving from one major release to another (10 to 11), you need to reinstall all ports/packages. The installation process is what creates these"users". It looks like you are just trying to run the things in /usr/local from your 10.3 system. This simply will not work. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-stable@freebsd.org Fri Jul 15 16:31:12 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93A9FB9AE51 for ; Fri, 15 Jul 2016 16:31:12 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.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 350901782 for ; Fri, 15 Jul 2016 16:31:11 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id CDB3044CF76 for ; Fri, 15 Jul 2016 11:31:10 -0500 (CDT) Subject: Re: Problem with FreeBSD-11.0-Beta1 To: freebsd-stable@freebsd.org References: <1167694931.3702710.1468584584907.JavaMail.yahoo.ref@mail.yahoo.com> <1167694931.3702710.1468584584907.JavaMail.yahoo@mail.yahoo.com> From: Karl Denninger Message-ID: <93bd3635-7be0-0fad-35e2-2a202b990a90@denninger.net> Date: Fri, 15 Jul 2016 11:31:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090108080407020705030204" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 16:31:12 -0000 This is a cryptographically signed message in MIME format. --------------ms090108080407020705030204 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/15/2016 11:17, Kevin Oberman wrote: > 11.0 has not been released. You are much more likely to get a useful > response from current@. > > On Fri, Jul 15, 2016 at 5:09 AM, Filippo Moretti via freebsd-stable < > freebsd-stable@freebsd.org> wrote: > >> I have the following problem when I start the system: > > >> Unknown user name "avahi" in message bus >> configuration fileUnknown user name "polkitd" in mes= sage >> bus configuration file >> Unknown user name "polkitd" in message bus >> configuration fileUnknown user name "colord" in me= ssage >> bus configuration file >> Unknown user name "pulse" in message bus >> configuration fileUnknown user name "polkit" in >> message bus configuration file > Unknown user name "haldaemon" in message bus configuration f= ile > > Failed to start message bus: > > Could not get VID and GID for username "messagebus" > > /etc/rc:Warning:failed to start dbus > > On the same computer I have a disk with 10.3_STABLE with the same >> configuration files and everything is working properly.When in X I la= unch >> firefox I get the following errorLibGL error: > failed to open drm device:Permission denied > > LibGL error :failed to load driver: r 300 > > This is very likely due to failure to start dbus > > sincerely > > Filippo > > > Note: I have tried to recover the mail format above. Whatever mail tool= you > used totally garbled things by removing line breaks. > > First, how did 11.0Beta-1 get installed? How sis your ports (X11, dbus,= > pulseaudio, etc.) get installed? When moving from one major release to > another (10 to 11), you need to reinstall all ports/packages. The > installation process is what creates these"users". > > It looks like you are just trying to run the things in /usr/local from = your > 10.3 system. This simply will not work. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Actually it SHOULD work unless you deleted the old libraries (in which case it definitely won't!); the dynamic loader is smart enough to do the right thing and load the correct (older) version of the shared libraries required. If this has been broken in recent releases IMHO that's not so good.=20 There *are* instances where an older binary is all there is for a given application (e.g. from a vendor!) and thus backward compatibility when you roll forward the operating system is something that a lot of people (myself included) have both used and relied on for a very long time. Yes, I understand that you can't *count* on that working, particularly if the app in question makes explicit reference to things in the kernel environment. But absent that they certainly should run. One instance where they didn't was with the armv6/armv6hf case where the floating point format changed, but that happened in the -CURRENT environment where ABI breakage is a known (and thus accepted) risk of running -CURRENT. (That particular one manifested in some nasty ways too in that going the "wrong way" would result in a binary that executed, did not produce any exceptions or traps, but produced incorrect floating-point results! I have code "in the wild" that checks for this specific circumstance on startup "just in case"....) Now if you do perform a merge and only accept part of it you can get in a lot of trouble with user and group IDs and similar, which is what appears to have happened here. It's pretty easy to get bit by that if you have local changes in your passwd and group files (and most people do), "leave them for later" and then don't go back and merge the new entries by hand. That sounds like what's occurred here; check in /var/tmp, assuming you told mergemaster to keep it when done. Since the svn repo for stable/11 is now there and when checked out builds BETA1 this IMHO appears to be the right place to discuss it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090108080407020705030204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxNjMxMDhaME8GCSqGSIb3DQEJBDFCBEC5 BCRGiNabyxtoJOhzxyvSxBFLvnIIGxQwLvvLK8TuJ/NLchX0ojgiu8KMWp5DW8dxptSy3JSs tOcD4HsWOEs7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIANR3KnK8Q BV6v2dpGbqm4MZa6Fki7IeGiFyGsxCXG27PChadhQmy16LmZUF3T8SGG+K1Kx+Pe4HW49zGr OH6U6DSTKNjP/Kzxo34UUnzFWiMhIOfcL3/lZbgrUZdS3/HmOdWNREmm203mmsvTdASVqqZ9 +W4IEzFztFwBoZlwHR8zq671qcgQSrpcd6zwzTqGBIpr/VWx3+1RFzT2zNiYbRSiVA53z6n1 XcVH9FqGFnlVOnJpbjr5FjI4LBq7ufHMP51iJ2CClQb47hNv1VlRqQ0znOlRSUERzdjU/KyO arNUa9hxa8mLh1Pg51bynNHK4H/oJLhNG7dyuv9FPNiM66Pd3FWaV9BHQi+Scp0CfB4dySyD CIjTncHlwCNEwWUv8bjAntOxiwRKdUrzR2qRs4GbJljGHA6ipo5d9sU2G5zEXvkadDRQsmQn vyG7SScNjxAVDMnoeNiGq2QFlaV/cR+8rNqdNW+1FSMuoiRuEzX/1sTqN14Lp7blRnYB8bvf lWBF5UPfSjwxAsfOSS+u1kOYVE1+0jrImoidT0/WzcclcIXu87PcUDa/5IZ0+Vc38UW5hjn3 AmMuSvXIjeylXvnBgHAkYVAdC+yknbxUAapYMPX2o1he64/eSVC5RqVuZOV7RxaG61wApzEq O2nSejxCed+uqJHGwfLk2KUsj3kAAAAAAAA= --------------ms090108080407020705030204-- From owner-freebsd-stable@freebsd.org Fri Jul 15 19:05:49 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF5F3B9A786 for ; Fri, 15 Jul 2016 19:05:49 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from nm45-vm4.bullet.mail.ne1.yahoo.com (nm45-vm4.bullet.mail.ne1.yahoo.com [98.138.121.68]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE0AF1499 for ; Fri, 15 Jul 2016 19:05:49 +0000 (UTC) (envelope-from filippomore@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1468609543; bh=ggt8eigVxDRaHMWnaBZJGVTlKEzL1uOKmpxZgtlwiDE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=NmqZPp+WSb3qG4IYAsEi2AvSVfLz7B/qKmT8FbkjdJD6n40YXbY+A+vCH4zvYM/jcX3QIUlWL9hUYg09RFtiG7sM45WguVGA9lZyn2yfKVw4J/1ZkU8qVNqJQPXlr/5E4/L4ekx6s/QUgDyhk7I2MJzJ2xZ8FfFcbY+V0haHuhHFGJJInGXdIey04jcQxSiv5QdASVzxn63Ojh08WiOlf3NWrdfWg57s1SzI7IJnBbpvhqJ8LGNtbjUMJYzlHHneDsY1LXs63aF/zkKomdkATB1SxisJGdT/UavG1sdERzjEgd0xB9doYkGlOGlWEZPc7uT/YoL/ceLmc9GjOc/l1g== Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2016 19:05:43 -0000 Received: from [98.138.100.102] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2016 19:02:55 -0000 Received: from [98.139.170.181] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jul 2016 19:01:55 -0000 Received: from [98.139.212.244] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jul 2016 19:01:55 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 15 Jul 2016 19:01:55 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 222810.25039.bm@omp1053.mail.bf1.yahoo.com X-YMail-OSG: rUIzrYsVM1l2Zy6al4fOc_LPkPOy1Srl_YJJ7Pug0pNyHlGSlenewzsvaVcllWT P0Uc.Vt58ECU3CmT02x6QEa_amdq0aTRX5AB_aI0aHRll.gUxqinvABfcH3b5RNHSceZkA4KEMxZ nLGcOV.MgFcUMKhP2jeRRRZnYimLegWLFPMyNvNTkAjajZP40nq8Ks25SztoyE8bMBuFL16asAkQ T0TG7XeU_S1Baf.KowOotwVYJqGBXvDnCrZ4CHPTtuMWeXzD3OK2ntKBsF9eSM5BYC5.EmB7DDdo H71VFcNe7HFqhvc7maN__4mlujXuiIcVyDxa.aXR_K9J93CNWtGLpc6TO1h5Vtly58_roHtS1ZR4 EA3q7p9npXSP3R4SgnCwrWG7x.4dBbMWsJ1wfrm10vxjT.PfpVC9DrHQFU0zDC7Y_crGekzzxstN HwxIdma70HaXCR.xRfNwYv.JyWxbsw0jfWi_t8FqQ4jC5ubotokdlw9aF_Ni2S0jH1mrNpur9djx O68iAOQIu_.9gLvDhIyeKHDJFC.C8YjKnulPYVsY- Received: from jws10692.mail.bf1.yahoo.com by sendmailws131.mail.bf1.yahoo.com; Fri, 15 Jul 2016 19:01:54 +0000; 1468609314.760 Date: Fri, 15 Jul 2016 19:01:54 +0000 (UTC) From: Filippo Moretti Reply-To: Filippo Moretti To: Karl Denninger , "freebsd-stable@freebsd.org" Message-ID: <516799068.3859323.1468609314427.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <93bd3635-7be0-0fad-35e2-2a202b990a90@denninger.net> References: <1167694931.3702710.1468584584907.JavaMail.yahoo.ref@mail.yahoo.com> <1167694931.3702710.1468584584907.JavaMail.yahoo@mail.yahoo.com> <93bd3635-7be0-0fad-35e2-2a202b990a90@denninger.net> Subject: Re: Problem with FreeBSD-11.0-Beta1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:05:50 -0000 The system was installed as 11_CURRENT and I did not have any issue until A= LPHA-4.I did install everything from portsand I did install all of the /etc= during mergemaster and mergemaster -p.I do have a another disk with 10.3-S= TABLE butI never tried to run applications from current in stable or the ot= her way.Filippops I did delete an old library I rebuilt windowmaker and I h= ave no complaint about it=20 On Friday, July 15, 2016 6:31 PM, Karl Denninger w= rote: =20 On 7/15/2016 11:17, Kevin Oberman wrote: > 11.0 has not been released. You are much more likely to get a useful > response from current@. > > On Fri, Jul 15, 2016 at 5:09 AM, Filippo Moretti via freebsd-stable < > freebsd-stable@freebsd.org> wrote: > >> I have the following problem when I start the system: > > >> Unknown user name "avahi"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in message bus >> configuration fileUnknown user name "polkitd"=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in message >> bus configuration file >> Unknown user name "polkitd"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 in message bus >> configuration fileUnknown user name "colord"=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in message >> bus configuration file >> Unknown user name "pulse"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in message bus >> configuration fileUnknown user name "polkit"=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in >> message bus configuration file > Unknown user name "haldaemon"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in= message bus configuration file > > Failed to start message bus: > > Could not get VID and GID for username "messagebus" > > /etc/rc:Warning:failed to start dbus > > On the same computer I have a disk with 10.3_STABLE with the same >> configuration files and everything is working properly.When in X=C2=A0 I= launch >> firefox I get the following errorLibGL error: > failed to open drm device:Permission denied > > LibGL error :failed to load driver: r 300 > > This is very likely due to failure to start dbus > > sincerely > > Filippo > > > Note: I have tried to recover the mail format above. Whatever mail tool y= ou > used totally garbled things by removing line breaks. > > First, how did 11.0Beta-1 get installed? How sis your ports (X11, dbus, > pulseaudio, etc.) get installed? When moving from one major release to > another (10 to 11), you need to reinstall all ports/packages. The > installation process is what creates these"users". > > It looks like you are just trying to run the things in /usr/local from yo= ur > 10.3 system. This simply will not work. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Actually it SHOULD work unless you deleted the old libraries (in which case it definitely won't!); the dynamic loader is smart enough to do the right thing and load the correct (older) version of the shared libraries required. If this has been broken in recent releases IMHO that's not so good.=20 There *are* instances where an older binary is all there is for a given application (e.g. from a vendor!) and thus backward compatibility when you roll forward the operating system is something that a lot of people (myself included) have both used and relied on for a very long time. Yes, I understand that you can't *count* on that working, particularly if the app in question makes explicit reference to things in the kernel environment.=C2=A0 But absent that they certainly should run. One instance where they didn't was with the armv6/armv6hf case where the floating point format changed, but that happened in the -CURRENT environment where ABI breakage is a known (and thus accepted) risk of running -CURRENT.=C2=A0 (That particular one manifested in some nasty ways too in that going the "wrong way" would result in a binary that executed, did not produce any exceptions or traps, but produced incorrect floating-point results!=C2=A0 I have code "in the wild" that chec= ks for this specific circumstance on startup "just in case"....) Now if you do perform a merge and only accept part of it you can get in a lot of trouble with user and group IDs and similar, which is what appears to have happened here.=C2=A0 It's pretty easy to get bit by that if you have local changes in your passwd and group files (and most people do), "leave them for later" and then don't go back and merge the new entries by hand.=C2=A0 That sounds like what's occurred here; check in /var/tmp, assuming you told mergemaster to keep it when done. Since the svn repo for stable/11 is now there and when checked out builds BETA1 this IMHO appears to be the right place to discuss it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ From owner-freebsd-stable@freebsd.org Fri Jul 15 19:56:56 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 410FBB986D2 for ; Fri, 15 Jul 2016 19:56:56 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 335511639; Fri, 15 Jul 2016 19:56:56 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 81A6B218; Fri, 15 Jul 2016 19:56:56 +0000 (UTC) Date: Fri, 15 Jul 2016 19:56:56 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1132313545.74.1468612616124.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1910762865.71.1468558639329.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1910762865.71.1468558639329.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #317 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:56:56 -0000 See From owner-freebsd-stable@freebsd.org Fri Jul 15 22:51:57 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC4D5B993AB for ; Fri, 15 Jul 2016 22:51:57 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id DEA3812D2; Fri, 15 Jul 2016 22:51:57 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2223021E; Fri, 15 Jul 2016 22:51:58 +0000 (UTC) Date: Fri, 15 Jul 2016 22:51:57 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <1845126257.79.1468623117975.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1132313545.74.1468612616124.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1132313545.74.1468612616124.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #318 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 22:51:58 -0000 See From owner-freebsd-stable@freebsd.org Fri Jul 15 23:10:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90C94B997E7 for ; Fri, 15 Jul 2016 23:10:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04A011B04; Fri, 15 Jul 2016 23:10:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id b199so97786711lfe.0; Fri, 15 Jul 2016 16:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xWZXpuuZ3E0/y9y0ZwFoijBovr4cq7rqeg86PZJGugY=; b=x0n5HNIo/ugHeAkPMldWnFHRgkdLH0Jjbu1QEPIuDNyVEG//Mv4dOgyR/PQD5O3uPp GVtcw7ZYOKazWN5YNenJn2okBxXmIAccE0zx2HBv5VXD839Je1OLl2AmxXSivQZtZmGp JmzcO2w9X5Z0R27bL+xdSTcjXYHGI0ZFZDtoMZaeKlaITh0aLJ3J1C45XVKYqk5Iq9xa spG4YeVBZt8yU+PNPb6vz73KqGVq/aZqf6uzcndLrh+Iy1VvS5WZ4sZg/l5EyggS7tJf WZoa+DxnOuy9Zyst3yQyNo1upLJFx5tEuimXADBDo9mVtrLc6nNc7GV+mH8usXAH4OsT vqqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=xWZXpuuZ3E0/y9y0ZwFoijBovr4cq7rqeg86PZJGugY=; b=mjWWtsuw0PDUfnAlNBcuNQexnDcPCkHu1qnIEMXe2znFCZTAJGfMZ8nKM+WdaSadcE XNA6ObA2cQR5ligPmvN4cfW85mgTY28MD23X0WkhbVU+1HZpTYue5ohQUsGYigv8O4nZ Q4m9ZVYKQhIZKW0qdhfRnxwkK2qfXMtIIAQlQrKrf4eFUDD1llt4e1iBEcWM5E87AnpA w3MBh/5CyF9y+MgGIUinYGhHTHB7SbyQQLzEJXS9eDxYsqSV+t0MkBk6zQmcDEZ3s4Xa kwyDBv/gm7ksCty7reO8ZJiLEIbB9Jm7aAZtgK+cy/7vL+yCDvYmV0CpYlgCsjtiPfWV UQqQ== X-Gm-Message-State: ALyK8tLEZ8Lbz0jPa5iXaX103MuDQOX4opv6YFX79acH47Mphqdwag8n+88rMGJ35Qlmhw== X-Received: by 10.25.35.9 with SMTP id j9mr11218890lfj.6.1468624232130; Fri, 15 Jul 2016 16:10:32 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id h9sm403464lfe.8.2016.07.15.16.10.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jul 2016 16:10:31 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 16 Jul 2016 01:10:30 +0200 From: Baptiste Daroussin To: Jung-uk Kim Cc: Thomas Eberhardt , freebsd-stable@FreeBSD.org Subject: Re: stable/11 Problems with Unicode character and ls(1) sorting Message-ID: <20160715231030.k6ywbzdgi43lom33@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kdm5ptxooynwc6ol" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1-neo (2016-06-11) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 23:10:34 -0000 --kdm5ptxooynwc6ol Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2016 at 11:38:22AM -0400, Jung-uk Kim wrote: > On 07/15/16 09:55 AM, Thomas Eberhardt wrote: > > % uname -a > > FreeBSD clarence.ocp.lan 11.0-BETA1 FreeBSD 11.0-BETA1 #0 r302457: Sat = Jul 9 10:41:40 CEST 2016 thomas@clarence.ocp.lan:/usr/obj/usr/src/sys/= GENERIC amd64 > >=20 > > % locale > > LANG=3Den_US.UTF-8 > > LC_CTYPE=3D"en_US.UTF-8" > > LC_COLLATE=3D"en_US.UTF-8" > > LC_TIME=3D"en_US.UTF-8" > > LC_NUMERIC=3D"en_US.UTF-8" > > LC_MONETARY=3D"en_US.UTF-8" > > LC_MESSAGES=3D"en_US.UTF-8" > > LC_ALL=3D > >=20 > > % mkdir x > > % touch x/=C3=86on1 > > % ls x > > =C3=86on1 > > % touch x/=C3=86on2 > > % ls -f x=20 > > . .. =C3=86on1 =C3=86on2 > > % ls -f x | hd > > 00000000 2e 0a 2e 2e 0a c3 86 6f 6e 31 0a c3 86 6f 6e 32 |.......on1= =2E..on2| > > 00000010 0a |.| > > 00000011 > > % ls x > > [hangs and consumes 100% CPU] > > ^C > >=20 > > % gdb /bin/ls > > [=E2=80=A6] > > (gdb) run x > > Starting program: /bin/ls x > > [hangs] > > ^C > > Program received signal SIGINT, Interrupt. > > 0x0000000800ffa9dd in _collate_lookup (table=3D, t= =3D,=20 > > len=3D, pri=3D, which=3D<= value optimized out>, state=3D) > > at /usr/src/lib/libc/locale/collate.c:340 > > 340 *pri =3D table->char_pri_table[*t].pri[which]; > > Current language: auto; currently minimal > > (gdb) bt > > #0 0x0000000800ffa9dd in _collate_lookup (table=3D, t=3D,=20 > > len=3D, pri=3D, which=3D<= value optimized out>, state=3D) > > at /usr/src/lib/libc/locale/collate.c:340 > > #1 0x0000000800fdc38a in wcscoll_l (ws1=3D, ws2= =3D,=20 > > locale=3D) at /usr/src/lib/libc/string/wcscoll= =2Ec:158 > > #2 0x0000000800fd9071 in strcoll_l (s=3D, s2=3D, locale=3D0x80124f338) > > at /usr/src/lib/libc/string/strcoll.c:101 > > #3 0x0000000800fee253 in qsort (a=3D, n=3D, es=3D,=20 > > cmp=3D0x800f28530 ) at /usr/src/lib/libc/stdlib/qsort.c= :130 > > #4 0x0000000800f27397 in fts_sort (sp=3D, head=3D= , nitems=3D) > > at /usr/src/lib/libc/gen/fts.c:995 > > #5 0x0000000800f2848e in fts_children (sp=3D, ins= tr=3DError accessing memory address 0x2: Bad address. > > ) at /usr/src/lib/libc/gen/fts.c:570 > > #6 0x00000000004030df in traverse (argc=3D, argv= =3D,=20 > > options=3D) at /usr/src/bin/ls/ls.c:576 > > #7 0x0000000000402eeb in main (argc=3D, argv=3D) at /usr/src/bin/ls/ls.c:498 > > #8 0x00000000004020cf in _start () > > #9 0x0000000800629000 in ?? () > > #10 0x0000000000000000 in ?? () > > (gdb) br strcoll.c:101 > > Breakpoint 1 at 0x800fd9063: file /usr/src/lib/libc/string/strcoll.c, l= ine 101. > > (gdb) run > > The program being debugged has been started already. > > Start it from the beginning? (y or n) y > > Starting program: /bin/ls x > > [=E2=80=A6] > >=20 > > Breakpoint 1, strcoll_l (s=3D, s2=3D, locale=3D0x80124f338) > > at /usr/src/lib/libc/string/strcoll.c:101 > > 101 ret =3D wcscoll_l(w1, w2, locale); > > (gdb) n > > [wcscoll_l never returns] > >=20 > >=20 > > Does anybody know what=E2=80=99s going on? This is on a ZFS filesystem = if that matters. >=20 > Yes, it is a known problem and bapt is working on it. If you're in > hurry, reverting r302324 will fix the regression for now. >=20 > https://svnweb.freebsd.org/changeset/base/302324 >=20 > FYI, this problem is tracked as PR211135. >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211135 >=20 > Jung-uk Kim >=20 Fixed by: r302916. I'll merge it in 2 days in stable/11 if re@ agrees Best regards, Bapt --kdm5ptxooynwc6ol Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXiW1jAAoJEGOJi9zxtz5apRQQAJAhIf4pBa2IRoHkm6o/rjPI ZlsLUyolmloeCXrp8RnWcCKONku0kPpu+Ew1q3qCAc0sT8usL56Hcg05Vk0Igj0k tZ55pWRrIPhPhOdzZY06K8crKRJBKERCe4K/hCWsUq5iHBBLMzwDPtO4FfBB+mF/ Vrg8232FgqcNKwV2hSjkLjRT3ymYbl4Uqm/GlQlOmi9hQBXN2SdbswOexG4rSvZR ofgVXjles+D3Z+3kg5hyONsZbvjeKJ+i5TdEoQYEb7dy1G1+/tl3Ww9/fCzqRTeU +q4zQUfTkp4PQshqdxMZ5UtIufRXSzfLrv8FqMqga1F0c+qPCwi9JyOQP39aVMHr XwgcrWoXim4Z1QOKgjcnyP7ZAxbZXIL9OxrL1r2up0aGDzRCAhpjsoLx0sbVUANS zeDnTD9vSfguM6pfF0mQDhrB9n4hJt3yoADhoLPoAYqWpnoSCTY8EeIbzSdnk4P1 bbAEpDlo0Upj0lua2zfrwqL+mc38Uq793NtJgQgMseR3kTC60ffS5m/efEBCFgdZ pkox4e8iQb0Z3ZxYDwPpo+YlylK1FrUlv/gwg094JoAGm9BoCqa8fM18djYp+mbg 1zzZMnuUIuKL6I8EIVUIe3oPi4jaZhx0//mHu2Xjo98yl6iJGY15Dixd9SMHQDvc o8SUzDXNssLUEpf3H1wI =iwYb -----END PGP SIGNATURE----- --kdm5ptxooynwc6ol-- From owner-freebsd-stable@freebsd.org Fri Jul 15 23:20:35 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A456B99BB1 for ; Fri, 15 Jul 2016 23:20:35 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 F25B81394 for ; Fri, 15 Jul 2016 23:20:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-it0-x230.google.com with SMTP id h190so31579116ith.1 for ; Fri, 15 Jul 2016 16:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2kzyNrz889MZVqGLycd9yreiSm9BtfEEb9fK9J+VTrE=; b=PuCBk3Ii9bsgSVmdkHxk9dRY8xRLebg7PX1ZsG6lKn3/ZkG+dK3EQslD/Q3LxbPxD1 sEZ9ExJluo/0Eah/EqUp4O/JJQYdFkWsUfLDlp2aVGuVgA7sxds7XYsISocJY806Eo3k m7IKgpNVcwn9LeL552n7aJ/WOxkdg7Fb2UiFx5aSILzlBOjyOwU2vs0SOCkNT8NmUHvY ZjoqctpdEh2eIuaP1CaTJfPryfc2rf/9DqoQ2fg0s+SzqHTpkeT5Zg6QLaM5CjsYQOcz RrWc4sVRdLX+tEbXL1qblsQx4VseQ58rpXcSkv/x6QjykkZLyqXTf4rjpj7x0lDx7Bdo cW6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2kzyNrz889MZVqGLycd9yreiSm9BtfEEb9fK9J+VTrE=; b=Af7q8VNMqscPLOSAJFD8+p4CzPb3qmEHxua+GztQvZ44dQIsIOTZy3BqY62Eo1sV59 f3gmIifBz4y+Er60cSaf7ReHK6wlVnt5ZWyF90RzFK8nd/1JVJ2MOomB24IIU+T6wAIx wueLz4vORjwctyy5dE6K4WaAoPNYGNCXMAegt269Y7V+wuIjrGglMKAnNzVCPrmWWXqh NYF09VUiv9Q1lUKgFiBBk/sUNpY6YFvWZMxryFa6rX6o9SHckwNwvqq2HYkDOH5jDhM3 aKuEamhuCDPKjJPWMUZ28EL9UamjNJlbacCtVA0lM/DC+ivt+mHI5S1u4pMjkUdYF4CQ Q3/Q== X-Gm-Message-State: ALyK8tK67VN8xUGd9jTrKlkLzm0PxwZmMIXv3Gn2p+vn3KlkJYyl7WTVlrNVH9vuqN1CNwfZxJ4k/7QXn7CE/A== X-Received: by 10.36.64.3 with SMTP id n3mr34652588ita.53.1468624834294; Fri, 15 Jul 2016 16:20:34 -0700 (PDT) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.79.78.213 with HTTP; Fri, 15 Jul 2016 16:20:33 -0700 (PDT) In-Reply-To: <516799068.3859323.1468609314427.JavaMail.yahoo@mail.yahoo.com> References: <1167694931.3702710.1468584584907.JavaMail.yahoo.ref@mail.yahoo.com> <1167694931.3702710.1468584584907.JavaMail.yahoo@mail.yahoo.com> <93bd3635-7be0-0fad-35e2-2a202b990a90@denninger.net> <516799068.3859323.1468609314427.JavaMail.yahoo@mail.yahoo.com> From: Kevin Oberman Date: Fri, 15 Jul 2016 16:20:33 -0700 X-Google-Sender-Auth: reRBJnyp-HIl91xd1IM_r-w1WcE Message-ID: Subject: Re: Problem with FreeBSD-11.0-Beta1 To: Filippo Moretti Cc: Karl Denninger , "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 23:20:35 -0000 On Fri, Jul 15, 2016 at 12:01 PM, Filippo Moretti via freebsd-stable < freebsd-stable@freebsd.org> wrote: > The system was installed as 11_CURRENT and I did not have any issue until > ALPHA-4.I did install everything from portsand I did install all of the > /etc during mergemaster and mergemaster -p.I do have a another disk with > 10.3-STABLE but I never tried to run applications from current in stable or > the other way.Filippops I did delete an old library I rebuilt windowmaker > and I have no complaint about it > > And, how did you go from ALPHA-4 to BETA-1? If you updated sources and rebuilt world and kernel, it should have been fine. If you tried freebsd-update, that might explain it as that method is documented as broken in BETA-1. I am uncertain what might happen if you tried this. I'd expect that the BETA-1 update files would have been removed. Somehow your password file seems to have lost all of the users since the move from ALPHA-4. I suspect /etc/group might have done the same, but I am not sure. You might merge all users from the 10.3 system using vipw(8) and do the same with your preferred to /etc/group. I have no idea what other things might be broken, though, nor how it happened (assuming you did not use freebsd-update). -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Friday, July 15, 2016 6:31 PM, Karl Denninger > wrote: > > > On 7/15/2016 11:17, Kevin Oberman wrote: > > 11.0 has not been released. You are much more likely to get a useful > > response from current@. > > > > On Fri, Jul 15, 2016 at 5:09 AM, Filippo Moretti via freebsd-stable < > > freebsd-stable@freebsd.org> wrote: > > > >> I have the following problem when I start the system: > > > > > >> Unknown user name "avahi" in message bus > >> configuration fileUnknown user name "polkitd" in > message > >> bus configuration file > >> Unknown user name "polkitd" in message bus > >> configuration fileUnknown user name "colord" in > message > >> bus configuration file > >> Unknown user name "pulse" in message bus > >> configuration fileUnknown user name "polkit" in > >> message bus configuration file > > Unknown user name "haldaemon" in message bus configuration > file > > > > Failed to start message bus: > > > > Could not get VID and GID for username "messagebus" > > > > /etc/rc:Warning:failed to start dbus > > > > On the same computer I have a disk with 10.3_STABLE with the same > >> configuration files and everything is working properly.When in X I > launch > >> firefox I get the following errorLibGL error: > > failed to open drm device:Permission denied > > > > LibGL error :failed to load driver: r 300 > > > > This is very likely due to failure to start dbus > > > > sincerely > > > > Filippo > > > > > > Note: I have tried to recover the mail format above. Whatever mail tool > you > > used totally garbled things by removing line breaks. > > > > First, how did 11.0Beta-1 get installed? How sis your ports (X11, dbus, > > pulseaudio, etc.) get installed? When moving from one major release to > > another (10 to 11), you need to reinstall all ports/packages. The > > installation process is what creates these"users". > > > > It looks like you are just trying to run the things in /usr/local from > your > > 10.3 system. This simply will not work. > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkoberman@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > Actually it SHOULD work unless you deleted the old libraries (in which > case it definitely won't!); the dynamic loader is smart enough to do the > right thing and load the correct (older) version of the shared libraries > required. > > If this has been broken in recent releases IMHO that's not so good. > There *are* instances where an older binary is all there is for a given > application (e.g. from a vendor!) and thus backward compatibility when > you roll forward the operating system is something that a lot of people > (myself included) have both used and relied on for a very long time. > > Yes, I understand that you can't *count* on that working, particularly > if the app in question makes explicit reference to things in the kernel > environment. But absent that they certainly should run. > > One instance where they didn't was with the armv6/armv6hf case where the > floating point format changed, but that happened in the -CURRENT > environment where ABI breakage is a known (and thus accepted) risk of > running -CURRENT. (That particular one manifested in some nasty ways > too in that going the "wrong way" would result in a binary that > executed, did not produce any exceptions or traps, but produced > incorrect floating-point results! I have code "in the wild" that checks > for this specific circumstance on startup "just in case"....) > > Now if you do perform a merge and only accept part of it you can get in > a lot of trouble with user and group IDs and similar, which is what > appears to have happened here. It's pretty easy to get bit by that if > you have local changes in your passwd and group files (and most people > do), "leave them for later" and then don't go back and merge the new > entries by hand. That sounds like what's occurred here; check in > /var/tmp, assuming you told mergemaster to keep it when done. > > Since the svn repo for stable/11 is now there and when checked out > builds BETA1 this IMHO appears to be the right place to discuss it. > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Sat Jul 16 02:47:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6225B9AE20; Sat, 16 Jul 2016 02:47:41 +0000 (UTC) (envelope-from nathan.bosley@gmail.com) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A07D514AE; Sat, 16 Jul 2016 02:47:41 +0000 (UTC) (envelope-from nathan.bosley@gmail.com) Received: by mail-yw0-x22e.google.com with SMTP id w127so118906817ywf.3; Fri, 15 Jul 2016 19:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=epGyUwcpRR2JJHDG8Z4Ew1hrlhNpn5KMO1g0kEYjB40=; b=CpBIjTgo8MBNt1nzDNB0dfW+ei9cU93cyli/CYfya5iUyDpFOU70ycaWLA/THRCOfF sE5RbMPEJrLQJ8s0amjvhw5ptGRR19YdgjPV5fltANMAIn9GIY7F4d8UJfBF0lQtJFCd EDOBUP6J7Y6tCvWd1GntziPkE0QA45kfQMvKGVxU8aU4NP2rgtpUsFSVawMOfos60wPN uqf93fl63qjr6OL7C1KUZQ61dP/8b16lta3V28ia20xwD/a8LgrG4xapQJ5he3pUew+g yTyzdklWrUw2G8SQ85fFPIKv6QspHgd4EquhYYWHiDL4QQkxWrD80mwDgr+gvOKnu1xO 301w== 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; bh=epGyUwcpRR2JJHDG8Z4Ew1hrlhNpn5KMO1g0kEYjB40=; b=dl3K0HNOycoLVRxw06uKhYGZFZNCvCrwha9F7kp9NvfP/cKUIWlkg1aEz6uNRXbGIf 6TnfYgEICCFVhwLeJLLJRp7JfuXkB/XRqhiYgk2D2O9S+UF3oTIq6Gl6JU/Ih8ZBVRKS cE9PApGyODsQEZsmaYpOpXAEkeTOs6rQMgD/xWg8XzPE3WvYgJ6Nkv7K64SjiL+dZ//A dQu08SPawj1lhycDMwYdfMzyMZFHZ4K0ssqp0o9mjfJAxq2UgHBemAu9iwXbEanIGkMT EVl83eY2SiHh8R/jeKYkhN7zUR+Bj6gWueo0bzwW+OTsJP6rd6EYwGOlxoFrLpL9ykan enBw== X-Gm-Message-State: ALyK8tJfjQZ94EmiX8Rj62jQLE1AmMsEVmPeVrohldaEmDk6pCLMfHGkGsTkTyJVem9YWHK6Hr693NBJ3MQd9Q== X-Received: by 10.37.204.72 with SMTP id l69mr15129729ybf.133.1468637260694; Fri, 15 Jul 2016 19:47:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.97.11 with HTTP; Fri, 15 Jul 2016 19:47:40 -0700 (PDT) From: Nathan Bosley Date: Fri, 15 Jul 2016 22:47:40 -0400 Message-ID: Subject: Missing links on 10.3 Installation Instructions page To: freebsd-doc@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 02:47:42 -0000 Hello, I had a glance at https://www.freebsd.org/releases/10.3R/installation.html. I believe this line is missing a couple of links: "The procedure for doing a source code based update is described in and ." My guess is that that line should be: "The procedure for doing a source code based update is described in Synchronizing Source and Rebuilding world ." Thanks. From owner-freebsd-stable@freebsd.org Sat Jul 16 04:59:44 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F28EB9A8D7 for ; Sat, 16 Jul 2016 04:59:44 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0168D154F; Sat, 16 Jul 2016 04:59:44 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id DB3EF22F; Sat, 16 Jul 2016 04:59:43 +0000 (UTC) Date: Sat, 16 Jul 2016 04:59:43 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <2044455430.84.1468645183660.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1845126257.79.1468623117975.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1845126257.79.1468623117975.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #319 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 04:59:44 -0000 See From owner-freebsd-stable@freebsd.org Sat Jul 16 10:54:41 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C38E8B9B3AC for ; Sat, 16 Jul 2016 10:54:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B59DD1E5C; Sat, 16 Jul 2016 10:54:41 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id ADE0E236; Sat, 16 Jul 2016 10:54:41 +0000 (UTC) Date: Sat, 16 Jul 2016 10:54:41 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jenkins-admin@FreeBSD.org, freebsd-stable@FreeBSD.org Message-ID: <425650879.85.1468666481007.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <2044455430.84.1468645183660.JavaMail.jenkins@jenkins-9.freebsd.org> References: <2044455430.84.1468645183660.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is still unstable: FreeBSD_stable_10 #320 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: UNSTABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 10:54:41 -0000 See From owner-freebsd-stable@freebsd.org Sat Jul 16 13:47:54 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D0B9B9B0AB for ; Sat, 16 Jul 2016 13:47:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 283B6135E for ; Sat, 16 Jul 2016 13:47:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 23E7EB9B0AA; Sat, 16 Jul 2016 13:47:54 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2391FB9B0A9 for ; Sat, 16 Jul 2016 13:47:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDD39135D for ; Sat, 16 Jul 2016 13:47:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u6GDlkw2090288 for ; Sat, 16 Jul 2016 13:47:46 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u6GDlkbq090287 for stable@freebsd.org; Sat, 16 Jul 2016 06:47:46 -0700 (PDT) (envelope-from david) Date: Sat, 16 Jul 2016 06:47:46 -0700 From: David Wolfskill To: stable@freebsd.org Subject: Building "extra" kernels in stable/11...? Message-ID: <20160716134746.GN1261@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uJNs2SB8W1DcCqdE" Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 13:47:54 -0000 --uJNs2SB8W1DcCqdE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For the paast few years, up through stable/10, I've had a dedicated "build machine" at home where I build the role-specific kernels for a couple of "production" machines (they "only" at home, but my spouse & I depend on them), and update the production machines by (temporarily) mounting /usr/src and /usr/obj from the build machine onto each production machine (via NFS), then performing (essentially) make installkernel, make installworld, mergemaster (with the usual additional steps). This has worked quite well, and has been nearly trouble-free. It's described in rather more detail in .) Now, the build machine itself runs a GENERIC kernel (and has minimal ports installed); I told it to build the additional kernels by appending the line: KERNCONF?=3DGENERIC ALBERT BATS to /etc/src.conf -- and that has been working (as above). Today, as part of my gradual ramp-up toward getting readyto test stable/11 on more than just the above build machine and my laptop, I figured I'd start building those extra kernels (along with GENERIC) when the build machine updated its stable/11. Accordingly, I appended KERNCONF?=3DGENERIC ALBERT BATS to /etc/src.conf -- but the only kernel even attempted was GENERIC. In reviewing the typescript (as I do all builds within script(1)), there was no indication that the kernel-building process had any awareness that anything other than GENERIC was wanted. Have I managed to overlook something obvious (again)? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uJNs2SB8W1DcCqdE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXijsCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XK/AH/ii4gWSS5cRtAO4nEtcT75Lu XalPu36aTsQl45+o6Ohe8GOO/P9lDMvMo74iU61ACbo7055ZjfUI8mceHfnPaghT FEtkGXyWSUtNgV0vgSytE+zuV7GdwLCz5R15E0/C4hCUIfSyBKvMOxgLhwyAB7JJ LKquS7MhwPjau0D8s0JE5cwHKasmFLdB2+uJGf7/XAXcBypm3Mw1gBuWLBTpoxGt tmuRiLTof+WGJCpvqLLoTTWx/iHHtrZfi1gV/MlbskdQ+aNCp3FB9e8FGEZnY4FC jPurJ+t/gDvsuHk78D+bteBKS6NmjoEJZ+SJAq3SlA8uHLeMTET/gqShBufDD8k= =GXI6 -----END PGP SIGNATURE----- --uJNs2SB8W1DcCqdE-- From owner-freebsd-stable@freebsd.org Sat Jul 16 15:45:23 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C595B9BDFF for ; Sat, 16 Jul 2016 15:45:23 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3252B149A for ; Sat, 16 Jul 2016 15:45:23 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2E040B9BDFD; Sat, 16 Jul 2016 15:45:23 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DA7DB9BDFC for ; Sat, 16 Jul 2016 15:45:23 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from mx1.mailbox.org (mx1.mailbox.org [80.241.60.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.mailbox.org", Issuer "SwissSign Server Silver CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5F3E1499 for ; Sat, 16 Jul 2016 15:45:22 +0000 (UTC) (envelope-from herbert@mailbox.org) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id DFBEA4252E; Sat, 16 Jul 2016 17:45:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:references:in-reply-to :subject:subject:from:from:message-id:date:date:received; s= mail20150812; t=1468683912; bh=tmXKwmf79eBBfQjQZgbq2u7q+rSabJCGo dKDeNyhRJo=; b=ZZrxkoR1g3t9KnSUeKW5x47XPrqY++MaLGVdrPvLPpp+YXa0B mKSo0ybOJz+CTHZXiSGVoosPxrbNkSYecPnC3QpqXOI2/xWyVO5bfwnsSnLQq371 4WqhO7ykB1SNF4rVM6pTwKeI8PnXzGA14S1C39v1PlY0yCuhWimj61elabwKn/kQ UY5v+lIWb8Bg1/vdG/OPzuYoE9VQLidgWCy1KtU0bIg/dHeHmXBlnQ4+bJFdAKt6 PMXlWWej/7DS/JoRE/M2Zv/toojF6Rjmwd+8qq9w/MUHLxdtC6yzwT9ZL+7eXzNS GZmzIp5zwnkcfMhBdk1amnnhSlH5il3pYO7uQ== X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id muCf5jmrui1d; Sat, 16 Jul 2016 17:45:12 +0200 (CEST) Date: Sat, 16 Jul 2016 17:45:11 +0200 Message-ID: <86mvlh7fjs.wl-herbert@mailbox.org> From: "Herbert J. Skuhra" To: David Wolfskill , stable@freebsd.org Subject: Re: Building "extra" kernels in stable/11...? In-Reply-To: <20160716134746.GN1261@albert.catwhisker.org> References: <20160716134746.GN1261@albert.catwhisker.org> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 15:45:23 -0000 David Wolfskill skrev: > > For the paast few years, up through stable/10, I've had a dedicated > "build machine" at home where I build the role-specific kernels for > a couple of "production" machines (they "only" at home, but my > spouse & I depend on them), and update the production machines by > (temporarily) mounting /usr/src and /usr/obj from the build machine > onto each production machine (via NFS), then performing (essentially) > make installkernel, make installworld, mergemaster (with the usual > additional steps). > > This has worked quite well, and has been nearly trouble-free. It's > described in rather more detail in > .) > > Now, the build machine itself runs a GENERIC kernel (and has minimal > ports installed); I told it to build the additional kernels by appending > the line: > > KERNCONF?=GENERIC ALBERT BATS > > to /etc/src.conf -- and that has been working (as above). > > > Today, as part of my gradual ramp-up toward getting readyto test > stable/11 on more than just the above build machine and my laptop, I > figured I'd start building those extra kernels (along with GENERIC) when > the build machine updated its stable/11. > > Accordingly, I appended > > KERNCONF?=GENERIC ALBERT BATS > > to /etc/src.conf -- but the only kernel even attempted was GENERIC. In > reviewing the typescript (as I do all builds within script(1)), there > was no indication that the kernel-building process had any awareness > that anything other than GENERIC was wanted. > > Have I managed to overlook something obvious (again)? 1. Are you sure that you don't have KERNCONF defined in /etc/make.conf? 2. Have you tried to set 'KERNCONF=GENERIC ALBERT BATS' instead? Well, I cannot reproduce this issue on my stable/11 machine. -- Herbert From owner-freebsd-stable@freebsd.org Sat Jul 16 20:56:51 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D6D4B9BB5B for ; Sat, 16 Jul 2016 20:56:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 26CD41190 for ; Sat, 16 Jul 2016 20:56:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 22730B9BB5A; Sat, 16 Jul 2016 20:56:51 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2219AB9BB59 for ; Sat, 16 Jul 2016 20:56:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CACAA118F for ; Sat, 16 Jul 2016 20:56:49 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id u6GKulxq093429; Sat, 16 Jul 2016 20:56:47 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id u6GKulpG093428; Sat, 16 Jul 2016 13:56:47 -0700 (PDT) (envelope-from david) Date: Sat, 16 Jul 2016 13:56:47 -0700 From: David Wolfskill To: "Herbert J. Skuhra" Cc: stable@freebsd.org Subject: Re: Building "extra" kernels in stable/11...? Message-ID: <20160716205647.GW1261@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Herbert J. Skuhra" , stable@freebsd.org References: <20160716134746.GN1261@albert.catwhisker.org> <86mvlh7fjs.wl-herbert@mailbox.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gk+8k/uvCZGfROPj" Content-Disposition: inline In-Reply-To: <86mvlh7fjs.wl-herbert@mailbox.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 20:56:51 -0000 --Gk+8k/uvCZGfROPj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2016 at 05:45:11PM +0200, Herbert J. Skuhra wrote: > .... > Well, I cannot reproduce this issue on my stable/11 machine. > .... For good reason. It turns out that I was so *sure* I had my kernel config files (for ALBERT & BATS) in place thta I didn't even check to verify that. And when I did: freebeast(11.0)[1] ls -lT /usr/src/sys/amd64/conf/{GENERIC,ALBERT,BATS} ls: /usr/src/sys/amd64/conf/ALBERT: No such file or directory ls: /usr/src/sys/amd64/conf/BATS: No such file or directory -rw-r--r-- 1 david wheel 14315 Jul 8 04:00:47 2016 /usr/src/sys/amd64/c= onf/GENERIC freebeast(11.0)[2] cd Oops. :-( sorry for the noise. Once I corrected that & re-tested... well, GENERIC built; ALBERT is building as I type.... Thanks for the reality check! :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who would murder in the name of God or prophet are blasphemous coward= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Gk+8k/uvCZGfROPj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXip+OXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4Xvw4H/RbC4i735W3SG+NvtyShU4yy fywZge+bJtiq8zjHqaRAagIIIH4s5K2IFP1BAHtfwEyc5t3aIANelvXtLvj9Cuni WbHWnARKjDJaTcQBBmrSHJTlSp05HiRd4llNl7YHKTbdD/f5LohaycYU1LPgTjd1 JJvMTSH4tge55KK4sTq1W8p0njsr4yyAbGv3JPCE7ZmN6TN/Qff/IoftPvIA4Fcz KHqBkTjJLTN++KtLH9eZTYBXexOHUVZOnGMHLmmKmzYaDAhsdhwZw6BcTMQQpm6M KEgTEOxaZORCtVXN7f5ETbxBxtdJOS/ufqAlT/AQS6gYJq82IlLVHeQ8WP6LCFo= =Fhu/ -----END PGP SIGNATURE----- --Gk+8k/uvCZGfROPj-- From owner-freebsd-stable@freebsd.org Sat Jul 16 20:57:40 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A558EB9BBE0 for ; Sat, 16 Jul 2016 20:57:40 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 7E6C012AB for ; Sat, 16 Jul 2016 20:57:40 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CA7A0202F7 for ; Sat, 16 Jul 2016 16:57:33 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute3.internal (MEProxy); Sat, 16 Jul 2016 16:57:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qr5fJRvcg0JxL9EO7lxV7oBVCNA=; b=G6BIRk pYZbvzmYqA4zvps9THShuQSLZPqT9iAg+/2/uNvkV0DGhjjXd+fai79bt+VU2Msw 1jdvsJNyzvgnY/wYHQQL35XUSg/jL/XUoawipUAlPerDONPlF8zRdbvUqeEnQUuK u4B8KPiBsNw0GqgKPwhTn5PF92UHw81JurHp8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qr5fJRvcg0JxL9E O7lxV7oBVCNA=; b=E1/eDGyjjdLYwaBI08c+ph4slg1YZllJckZ+L3NUzKllR+7 UVtQvSdGrloQvu5pLVomn2+UxvkImkRyUmMuaF+xtddgXHIZyectFSPpPNq6mvgu apIPZNeCi8gTUSHU0sDjNC5x36Ca4WoQ2pgtUjbMjCMqlRRlu+q56hI9YuwQ= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9B6AED05AD; Sat, 16 Jul 2016 16:57:33 -0400 (EDT) Message-Id: <1468702653.2439899.668236153.3FCCA4ED@webmail.messagingengine.com> X-Sasl-Enc: g6AUmI4vVSMmzL52Gsk1VTqGvbaeHoaIE3xPKnUAyaI0 1468702653 From: John To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bf4e2c8f In-Reply-To: <20160716134746.GN1261@albert.catwhisker.org> References: <20160716134746.GN1261@albert.catwhisker.org> Subject: Re: Building "extra" kernels in stable/11...? Date: Sat, 16 Jul 2016 21:57:33 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 20:57:40 -0000 On Sat, 16 Jul 2016, at 14:47, David Wolfskill wrote: > Today, as part of my gradual ramp-up toward getting readyto test > stable/11 on more than just the above build machine and my laptop, I > figured I'd start building those extra kernels (along with GENERIC) when > the build machine updated its stable/11. > > Accordingly, I appended > > KERNCONF?=GENERIC ALBERT BATS > > to /etc/src.conf -- but the only kernel even attempted was GENERIC. In > reviewing the typescript (as I do all builds within script(1)), there > was no indication that the kernel-building process had any awareness > that anything other than GENERIC was wanted. > > Have I managed to overlook something obvious (again)? Hi, I noticed this stopped working a couple of months ago. I don't put it in src.conf though - mine goes in make.conf like this: KERNCONF=CUSTOMKERNEL1 GENERIC which means that both kernels would be built and installed with no special parameters to the buildkernel and installkernel commands. Less typing! I first noticed it when after building and installing a new world, the kernel came up with the warning that WITNESS was enabled (it's disabled in the custom kernel). So I had to build and install another kernel with the KERNCONF=CUSTOMKERNEL1 parameter. The problem happened at around the time I noticed GENERIC-NODEBUG appearing in /sys/amd64/conf - though this might be entirely coincidental. This was a month or so ago. I'll re-enable KERNCONF= in my make.conf, run another build and get back to you. -- John tech-lists@zyxst.net From owner-freebsd-stable@freebsd.org Sat Jul 16 21:04:34 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D83D5B9BFAB for ; Sat, 16 Jul 2016 21:04:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 B060E19F6 for ; Sat, 16 Jul 2016 21:04:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8837F20231 for ; Sat, 16 Jul 2016 17:04:33 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute4.internal (MEProxy); Sat, 16 Jul 2016 17:04:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Nvnlw3BsIlzA3bv8jU9jmrkiw1s=; b=Ivjqg9 Vn0EVqlWXYlnyndk6+wlKgCmEtCZF8iwVz+mqvL7N0IvN7p1fOqIRoaGgo/D9mZ3 6BbrvUqNPQzxhJBOWKlHK1n3W3o1ThNIKVP97UNcAfgvEUG2Y0oRrBjdqghTKkSt wFhf5UoWN2KEANxnfFsv1U9lz1Llf04Pkc298= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Nvnlw3BsIlzA3bv 8jU9jmrkiw1s=; b=cya/prFGXgMU0vPPB+BexzvfZP5jnC/O28i6lcyM0pTuJug mHYIB/cnRt8iENitG8lG3BoMde8w+990j5bIwBXCZ/L24i/EzmzlXZi/cZiTUtdg WS4mVUnciMI7WqtieQoFkFEPbODAoywhcddU1QxazNYkce+HrSaqfaYUYrVM= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 51A57D05B1; Sat, 16 Jul 2016 17:04:33 -0400 (EDT) Message-Id: <1468703073.2440830.668243017.7418A4E8@webmail.messagingengine.com> X-Sasl-Enc: d+x4EcIGyMFJMLtEbMpahuarq7CS2QQEX/HOjc1F5OSc 1468703073 From: John To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bf4e2c8f Subject: Re: Building "extra" kernels in stable/11...? Date: Sat, 16 Jul 2016 22:04:33 +0100 In-Reply-To: <20160716205647.GW1261@albert.catwhisker.org> References: <20160716134746.GN1261@albert.catwhisker.org> <86mvlh7fjs.wl-herbert@mailbox.org> <20160716205647.GW1261@albert.catwhisker.org> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 21:04:34 -0000 On Sat, 16 Jul 2016, at 21:56, David Wolfskill wrote: > On Sat, Jul 16, 2016 at 05:45:11PM +0200, Herbert J. Skuhra wrote: > > .... > > Well, I cannot reproduce this issue on my stable/11 machine. > > .... > > For good reason. It turns out that I was so *sure* I had my kernel > config files (for ALBERT & BATS) in place thta I didn't even check to > verify that. > > And when I did: > > freebeast(11.0)[1] ls -lT /usr/src/sys/amd64/conf/{GENERIC,ALBERT,BATS} > ls: /usr/src/sys/amd64/conf/ALBERT: No such file or directory > ls: /usr/src/sys/amd64/conf/BATS: No such file or directory > -rw-r--r-- 1 david wheel 14315 Jul 8 04:00:47 2016 > /usr/src/sys/amd64/conf/GENERIC > freebeast(11.0)[2] cd > > Oops. :-( sorry for the noise. > > Once I corrected that & re-tested... well, GENERIC built; ALBERT > is building as I type.... Hmm, your problem was different to mine then, because my config file was in the expected place. Otherwise the KERNCONF= option when manually applied wouldn't have worked. -- John tech-lists@zyxst.net