From owner-freebsd-current@freebsd.org Sun Apr 30 01:02:32 2017 Return-Path: Delivered-To: freebsd-current@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 2C4C5D4B3EE for ; Sun, 30 Apr 2017 01:02:32 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 DA8501FC4; Sun, 30 Apr 2017 01:02:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-ua0-x22e.google.com with SMTP id 110so54262846uas.3; Sat, 29 Apr 2017 18:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/3jkVzrLazdhkGm5vHo7jaXdi7euqbZbtpIEW/F7Q64=; b=qC4Q416S8Z9szRpw6k5wHR68te5W8aRF8ie96Hmf29D9vnPiqIRv43RC6xrtongEA6 /0SIyVZiyUDm6IXB7G7tCvVTX6v58z4dFDRpVUDg8C4nSWmtmvzbKIfUzsyCK5JhxrjT M9QWTrk/eT2SYZWIZb+c0FgjvB5zNgvllFexHwZoVveVWVdBtjlju9Dzln3+jYTOLWWA Gcb70PME1ndlBr6bs+k2uh9+8Ov2zxfShtvdpq2Fgag8gUEccUeubx4Y6I/6bVtdrA+I lbJeZWAoAslf7BfZOI8xsIb7+c+4UhPwNS6PrmLqaczAPMIRGtIzppeL7sqbQulk3uOJ Pqzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/3jkVzrLazdhkGm5vHo7jaXdi7euqbZbtpIEW/F7Q64=; b=oWhKGklmqxxtczKBX+9eMheeigjZqAvTqb3rWoywyDYFR+gYE4qnGSnmWHfuHN/Klv H88wb3Mkb2aA2WrCbwFwaBB9At8ZYUQLCHbZDSICDIL4Eb7852H6zHaBExrHh/nWJqjo mPyAbFLRvnSWE/TdFAvScjHajYacBz9HaqWKLSqPZSMm3pTL78+OmeKQDea+n8v8SdAk R8Joeethcc3QUYPPAXbrpeaxlzpKDyeLruh8o6y9Sn9UESwuex1hybM2+uB1mErNpcwA kDSjboCwFScgHkOlHiP8ojQxIfMbuHwFN6DVfEEjTD+dVKsjEIIOLAU2BeDlnoOMpj7J CNLg== X-Gm-Message-State: AN3rC/50hFWGT2MQU5jdC5Zsq7+vYMS/c9blfjMlKFtria/Mzylmy2wx 09X8LC9mTo1u+J49ZFAiNr1QhckzKw== X-Received: by 10.176.16.85 with SMTP id g21mr10180461uab.77.1493514150927; Sat, 29 Apr 2017 18:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.97 with HTTP; Sat, 29 Apr 2017 18:02:30 -0700 (PDT) In-Reply-To: <1737882.TJdaAP1hO8@ralph.baldwin.cx> References: <3727893.2519smPuKm@ralph.baldwin.cx> <1737882.TJdaAP1hO8@ralph.baldwin.cx> From: Sepherosa Ziehau Date: Sun, 30 Apr 2017 09:02:30 +0800 Message-ID: Subject: Re: Add support for ACPI Module Device ACPI0004? To: John Baldwin Cc: Dexuan Cui , "freebsd-current@freebsd.org" , Jung-uk Kim , Yanmin Qiao Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 01:02:32 -0000 On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin wrote: > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote: >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote: >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote: >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote: >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote: >> >> >> > From: John Baldwin [mailto:jhb@freebsd.org] >> >> >> > Sent: Thursday, April 20, 2017 02:34 >> >> >> > > Can we add the support of "ACPI0004" with the below one-line change? >> >> >> > > >> >> >> > > acpi_sysres_probe(device_t dev) >> >> >> > > { >> >> >> > > - static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL }; >> >> >> > > + static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL }; >> >> >> > > >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though we >> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since historically >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things like the >> >> >> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in the ACPI >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that? In particular, it >> >> >> > seems that 004 should only allow direct children to suballocate? This >> >> >> > change might work, but it will allow more devices to allocate the ranges in >> >> >> > _CRS than otherwise. >> >> >> > >> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004 >> >> >> > node that you can share? >> >> >> > >> >> >> > John Baldwin >> >> >> >> >> >> Hi John, >> >> >> Thanks for the help! >> >> >> >> >> >> Please see the attached file, which is got by >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz" >> >> >> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of >> >> >> "VMBus" (VMBS). >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't >> >> >> see the length of the MMIO range in the dumped asl code, it does have >> >> >> a 512MB MMIO range [0xFE0000000, 0xFFFFFFFFF]. >> >> >> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically. >> >> >> With the above one-line change, I can first find the child device >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range. >> >> >> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus >> >> >> driver as a child device of acpi0? >> >> > >> >> > Hmmm, so looking at this, the "right" thing is probably to have a device >> >> > driver for the ACPI0004 device that parses its _CRS and then allows its >> >> > child devices to sub-allocate resources from the ranges in _CRS. However, >> >> > this would mean make VMBus be a child of the ACPI0004 device. Suppose >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device >> >> > would need to create a child device for all of its child devices. Right >> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0 >> >> > creates child devices anywhere in its namespace that have a valid _HID). >> >> > You can find those duplicates and remove them during acpi_module0's attach >> >> > routine before creating its own child device_t devices. (We associate >> >> > a device_t with each Handle when creating device_t's for ACPI handles >> >> > which is how you can find the old device that is a direct child of acpi0 >> >> > so that it can be removed). >> >> >> >> The remove/reassociate vmbus part seems kinda "messy" to me. I'd just >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what >> >> we did to the hyper-v's pcib0. >> > >> > The acpi_pci driver used to do the remove/reassociate part. What acpi0 >> > should probably be doing is only creating device_t nodes for immediate >> > children. This would require an ACPI-aware isa0 for LPC devices below >> > the ISA bus in the ACPI namespace. We haven't done that in part because >> > BIOS vendors are not always consistent in placing LPC devices under an >> > ISA bus. However, you otherwise have no good way to find your parent >> > ACPI0004 device. You could perhaps find your ACPI handle, ask for its >> > parent handle, then ask for the device_t of that handle to find the >> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource >> > calls go to that device, not your "real" parent of acpi0, which means >> > you can't use any of the standard bus_alloc_resource() methods like >> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE >> > with the ACPI0004 device as the explicit first argument. It is primarily >> > the ability to let ACPI0004's driver transparently intercept all the >> > resource allocation so it can manage that is the reason for "VMBus" >> > to be a child of ACPI0004 rather than its sibling. >> >> Well, there could be more then one ACPI0004 typed devices, which could >> not form a device tree for vmbus. > > Are you saing a vmbus would need resources from multiple ACPI0004 devices? ACPI0004 (and several other PNP ids, see dexuan's submission) is something just like the acpi_sysresource. Not directly related to the vmbus at all. Thanks, sephe -- Tomorrow Will Never Die From owner-freebsd-current@freebsd.org Sun Apr 30 03:29:12 2017 Return-Path: Delivered-To: freebsd-current@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 9406CD56912 for ; Sun, 30 Apr 2017 03:29:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 4BCE5364 for ; Sun, 30 Apr 2017 03:29:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1711 invoked from network); 30 Apr 2017 03:30:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Apr 2017 03:30:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 29 Apr 2017 23:29:04 -0400 (EDT) Received: (qmail 9438 invoked from network); 30 Apr 2017 03:29:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Apr 2017 03:29:04 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5E720EC8029; Sat, 29 Apr 2017 20:29:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! Message-Id: Date: Sat, 29 Apr 2017 20:29:02 -0700 To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 03:29:12 -0000 With: = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd for QEMU_EFI.fd and with: = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/12.0-CURRENT/aarch= 64/20170420/FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw.xz for FreeBSD's .raw file (after unxz) I tried: qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 on an odroid-c2 running UbuntuMate: # uname -a Linux odroidc2UbMate 3.14.79-110 #1 SMP PREEMPT Tue Apr 11 20:16:54 BRT = 2017 aarch64 aarch64 aarch64 GNU/Linux The result was: . . . Booting [/boot/kernel/kernel]... =20 No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! . . . generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 In full detail: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 5 block devices.......* done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0x763b1000 EFI version: 2.60 EFI Firmware: EDK II (rev 1.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Thu Apr 20 16:51:44 UTC 2017 root@releng3.nyi.freebsd.org) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7b6848 data=3D0xa0578+0x43b3be = syms=3D[0x8+0x106938+0x8+0xfb67b] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 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 12.0-CURRENT #0 r317181: Thu Apr 20 16:54:23 UTC 2017 = root@releng3.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC = arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 acpi0: acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) psci0: on acpi0 generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff0000005db8a0 lr =3D 0xffff000000088910 sp =3D 0xffff0000000102a0 fp =3D 0xffff0000000104b0 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000088910 lr =3D 0xffff00000030a774 sp =3D 0xffff0000000104c0 fp =3D 0xffff000000010540 vpanic() at panic+0x48 pc =3D 0xffff00000030a774 lr =3D 0xffff00000030a800 sp =3D 0xffff000000010550 fp =3D 0xffff0000000105d0 panic() at intr_map_copy_map_data+0x164 pc =3D 0xffff00000030a800 lr =3D 0xffff000000616600 sp =3D 0xffff0000000105e0 fp =3D 0xffff000000010630 intr_map_copy_map_data() at intr_activate_irq+0xd8 pc =3D 0xffff000000616600 lr =3D 0xffff000000616280 sp =3D 0xffff000000010640 fp =3D 0xffff000000010690 intr_activate_irq() at nexus_activate_resource+0xb8 pc =3D 0xffff000000616280 lr =3D 0xffff0000005e77b8 sp =3D 0xffff0000000106a0 fp =3D 0xffff0000000106d0 nexus_activate_resource() at nexus_alloc_resource+0x10c pc =3D 0xffff0000005e77b8 lr =3D 0xffff0000005e76cc sp =3D 0xffff0000000106e0 fp =3D 0xffff000000010730 nexus_alloc_resource() at resource_list_alloc+0x1d4 pc =3D 0xffff0000005e76cc lr =3D 0xffff00000033bf94 sp =3D 0xffff000000010740 fp =3D 0xffff000000010790 resource_list_alloc() at acpi_alloc_resource+0x17c pc =3D 0xffff00000033bf94 lr =3D 0xffff0000000924fc sp =3D 0xffff0000000107a0 fp =3D 0xffff000000010850 acpi_alloc_resource() at bus_alloc_resources+0xd8 pc =3D 0xffff0000000924fc lr =3D 0xffff00000033dfa4 sp =3D 0xffff000000010860 fp =3D 0xffff0000000108b0 bus_alloc_resources() at arm_tmr_attach+0xc8 pc =3D 0xffff00000033dfa4 lr =3D 0xffff0000005ca394 sp =3D 0xffff0000000108c0 fp =3D 0xffff0000000108f0 arm_tmr_attach() at device_attach+0x404 pc =3D 0xffff0000005ca394 lr =3D 0xffff00000033b60c sp =3D 0xffff000000010900 fp =3D 0xffff000000010950 device_attach() at bus_generic_attach+0x50 pc =3D 0xffff00000033b60c lr =3D 0xffff00000033c808 sp =3D 0xffff000000010960 fp =3D 0xffff000000010980 bus_generic_attach() at acpi_attach+0xd44 pc =3D 0xffff00000033c808 lr =3D 0xffff000000091b98 sp =3D 0xffff000000010990 fp =3D 0xffff000000010a40 acpi_attach() at device_attach+0x404 pc =3D 0xffff000000091b98 lr =3D 0xffff00000033b60c sp =3D 0xffff000000010a50 fp =3D 0xffff000000010aa0 device_attach() at bus_generic_new_pass+0x120 pc =3D 0xffff00000033b60c lr =3D 0xffff00000033ced0 sp =3D 0xffff000000010ab0 fp =3D 0xffff000000010ae0 bus_generic_new_pass() at bus_generic_new_pass+0xe4 pc =3D 0xffff00000033ced0 lr =3D 0xffff00000033ce94 sp =3D 0xffff000000010af0 fp =3D 0xffff000000010b20 bus_generic_new_pass() at bus_set_pass+0x8c pc =3D 0xffff00000033ce94 lr =3D 0xffff000000339114 sp =3D 0xffff000000010b30 fp =3D 0xffff000000010b60 bus_set_pass() at mi_startup+0xc8 pc =3D 0xffff000000339114 lr =3D 0xffff0000002a8c34 sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002a8c34 lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x40: undefined d4200000 db>=20 Historical note: I last tried this sort of thing was back in 2016-September with 11-RELEASE and it booted but there were later problems. I tried the above because of the two recent fixes that remove aarch64-specific problems that were happening during fork. (There is no snapshot of stable/11 that has both of those fixes yet --and I've been using CURRENT anyway.) Some notes from back in 2016-August through 2016-October by other folks are at: https://forum.odroid.com/viewtopic.php?t=3D23356 The Odroid-C2 has also had various software updates since my earlier attempt so nothing has a known-good status for the purpose as far as my history goes. I can not lay blame as stands. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Apr 30 08:58:24 2017 Return-Path: Delivered-To: freebsd-current@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 C7F17D572F3; Sun, 30 Apr 2017 08:58:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 97318839; Sun, 30 Apr 2017 08:58:24 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31] (unknown [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 0EADF4E79B; Sun, 30 Apr 2017 08:57:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Andrew Turner In-Reply-To: Date: Sun, 30 Apr 2017 09:57:44 +0100 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 08:58:24 -0000 > On 30 Apr 2017, at 04:29, Mark Millard wrote: > ... > acpi0: > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) ACPI is not fully supported on arm64. Andrew From owner-freebsd-current@freebsd.org Sun Apr 30 11:02:30 2017 Return-Path: Delivered-To: freebsd-current@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 AAD06D571C4 for ; Sun, 30 Apr 2017 11:02:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 591521CF for ; Sun, 30 Apr 2017 11:02:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14710 invoked from network); 30 Apr 2017 11:03:36 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Apr 2017 11:03:36 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 30 Apr 2017 07:02:28 -0400 (EDT) Received: (qmail 21096 invoked from network); 30 Apr 2017 11:02:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Apr 2017 11:02:27 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3AC79EC7ED7; Sun, 30 Apr 2017 04:02:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Mark Millard In-Reply-To: Date: Sun, 30 Apr 2017 04:02:26 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> References: To: Andrew Turner X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 11:02:30 -0000 On 2017-Apr-30, at 1:57 AM, Andrew Turner wrote: >> On 30 Apr 2017, at 04:29, Mark Millard wrote: >> ... >> acpi0: >> acpi0: Power Button (fixed) >> acpi0: Sleep Button (fixed) > > ACPI is not fully supported on arm64. Good to know. Thanks. But the messages: No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! were well before the acpi0 messages so I'd expect that the lack of a "device tree blob" is a separate, earlier issue, likely to do with the content of: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw My old 2016-Sep. notes showed no such notifications for the 11-RELEASE attempt I made back then. (After the acpi0 messages:) I guessed that the "29"s in: generic_timer0: irq 29,30,27 on acpi0 panic: Attempt to copy invalid resource id: 29 were the same "29"s: i.e., that the "resource id" was the generic_time0: 29 irq number. But being after the acpi0 messages and after the notice of a lack of a "device tree blob" may be things are already messed up by that point --or may be my guess about the "29"s is just wrong and "resource id" 29 is something else, possibly related to the acpi0 notices. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Apr 30 16:41:01 2017 Return-Path: Delivered-To: freebsd-current@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 8721CD577E9; Sun, 30 Apr 2017 16:41:01 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5409D1C40; Sun, 30 Apr 2017 16:41:01 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31] (unknown [IPv6:2a02:c7f:1e13:cf00:4f9:7787:8c3e:8b31]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id CBA114EB9A; Sun, 30 Apr 2017 16:40:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Andrew Turner In-Reply-To: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> Date: Sun, 30 Apr 2017 17:40:57 +0100 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 16:41:01 -0000 > On 30 Apr 2017, at 12:02, Mark Millard wrote: >=20 > On 2017-Apr-30, at 1:57 AM, Andrew Turner = wrote: >=20 >>> On 30 Apr 2017, at 04:29, Mark Millard = wrote: >>> ... >>> acpi0: >>> acpi0: Power Button (fixed) >>> acpi0: Sleep Button (fixed) >>=20 >> ACPI is not fully supported on arm64. >=20 > Good to know. Thanks. >=20 > But the messages: >=20 > No valid device tree blob found! > WARNING! Trying to fire up the kernel, but no device tree blob found! >=20 > were well before the acpi0 messages so I'd expect > that the lack of a "device tree blob" is a separate, > earlier issue, likely to do with the content of: >=20 > FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw No, the device tree blob comes from UEFI. It seems the current UEFI only = provides the ACPI tables, and not a DTB. Andrew From owner-freebsd-current@freebsd.org Sun Apr 30 17:15:51 2017 Return-Path: Delivered-To: freebsd-current@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 C8D18D573F1 for ; Sun, 30 Apr 2017 17:15:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 8DE1F9F for ; Sun, 30 Apr 2017 17:15:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 868 invoked from network); 30 Apr 2017 17:15:49 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Apr 2017 17:15:49 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 30 Apr 2017 13:15:49 -0400 (EDT) Received: (qmail 27732 invoked from network); 30 Apr 2017 17:15:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Apr 2017 17:15:48 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 40CB3EC771C; Sun, 30 Apr 2017 10:15:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw under qemu-system-aarch64 on odroid-c2 under UbuntuMate : No valid device tree blob found! From: Mark Millard In-Reply-To: <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> Date: Sun, 30 Apr 2017 10:15:47 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> To: Andrew Turner X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 17:15:51 -0000 On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>=20 >> On 2017-Apr-30, at 1:57 AM, Andrew Turner = wrote: >>=20 >>>> On 30 Apr 2017, at 04:29, Mark Millard = wrote: >>>> ... >>>> acpi0: >>>> acpi0: Power Button (fixed) >>>> acpi0: Sleep Button (fixed) >>>=20 >>> ACPI is not fully supported on arm64. >>=20 >> Good to know. Thanks. >>=20 >> But the messages: >>=20 >> No valid device tree blob found! >> WARNING! Trying to fire up the kernel, but no device tree blob found! >>=20 >> were well before the acpi0 messages so I'd expect >> that the lack of a "device tree blob" is a separate, >> earlier issue, likely to do with the content of: >>=20 >> FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw >=20 > No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. So you are expecting that the older QEMU_EFI.fd I had used before provided some sort of fairly generic dtb (relative to qemu, fairly independent of the host that was running qemu). Interesting. Thanks again. It turns out that if I put the odroid-c2's dtb in where I can load it from the loader prompt (e.g., in /boot/dtb/ ) I get a little farther, although with notices for: Failed to start CPU 1 (1) Failed to start CPU 2 (2) Failed to start CPU 3 (3) pmu0: could not allocate resources device_attach: pmu0 attach returned 6 gpioled0: failed to map pin usb_needs_explore_all: no devclass The details of the sequence are: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK load -t dtb /boot/dtb/meson64_odroidc2.dtb /boot/dtb/meson64_odroidc2.dtb size=3D0x746c OK boot ?[37m?[44mBooting...?[m Using DTB from loaded file '/boot/dtb/meson64_odroidc2.dtb'. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 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 12.0-CURRENT r317015M arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Failed to start CPU 1 (1) Starting CPU 2 (2) Failed to start CPU 2 (2) Starting CPU 3 (3) Failed to start CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs arc4random: no preloaded entropy cache random: entropy device external interface kbd0 at kbdmux0 ofwbus0: psci0: on ofwbus0 gic0: mem = 0xc4301000-0xc4301fff,0xc4302000-0xc4303fff,0xc4304000-0xc4305fff,0xc43060= 00-0xc4307fff irq 18 on ofwbus0 gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 32 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 pmu0: irq 4,5,6,7 on ofwbus0 pmu0: could not allocate resources device_attach: pmu0 attach returned 6 gpioled0: on ofwbus0 gpioled0: failed to map pin cryptosoft0: Timecounters tick every 1.000 msec usb_needs_explore_all: no devclass As of that it hangs. Using something like pine64_plus.dtb did not get far at all compared to the above. It is possible that for "-enable-kvm -cpu host" that the dtb needs to match the host machine's dtb. Still, it is not like what I thought I remembered from back in 2016-September: I did no dtb manipulations back then since I was unaware of the issue. The above is console output is for. . . qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 based on: = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd but this time based on my build of head -r317015 . I first got to the point of replicating what I'd reported for: FreeBSD-12.0-CURRENT-arm64-aarch64-20170420-r317181.raw then I added the 2 .dtb files to try loading. The Odroid-C2 one worked better on the Odroid-C2. It seems that qemu does not have a general dtb emulation capability. (No surprise there?) But I did not find anything saying what was required. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Mon May 1 01:31:07 2017 Return-Path: Delivered-To: freebsd-current@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 9E478D58715 for ; Mon, 1 May 2017 01:31:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 5E7E3F10 for ; Mon, 1 May 2017 01:31:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26050 invoked from network); 1 May 2017 01:31:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 May 2017 01:31:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 30 Apr 2017 21:31:05 -0400 (EDT) Received: (qmail 8158 invoked from network); 1 May 2017 01:31:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 May 2017 01:31:05 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 66802EC8FFF; Sun, 30 Apr 2017 18:31:04 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mkimg okay; "cp -p" generates the bad context] Date: Sun, 30 Apr 2017 18:31:03 -0700 References: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> <302D1255-4D34-4C1B-8F3A-9180A6AF8768@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current In-Reply-To: <302D1255-4D34-4C1B-8F3A-9180A6AF8768@dsl-only.net> Message-Id: <7C5C4725-984C-4461-B76C-9A6BE052BA00@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 01:31:07 -0000 On 2017-Apr-27, at 10:26 PM, Mark Millard = wrote: > [As the text does not really follow from the earlier text > I'd sent directly I'm top posting a hypothesis about where > so much active memory came from to be so low in available > memory to get an reclaim_pv_chunk attempt.] >=20 > My hypothesis is that the "mdconfig -d"s from vm_copy_base > (from /usr/src/release/tools/vmimage.subr ) did not actually > release the memory resources involved (from vnode backed > mdconfig use): I watched with "vmstat 1" and "mdconfig -d" did release memory (including RAM) each time. > . . . > =46rom the prior top report for the failure, > partially repeated here: >=20 > . . . > Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free > Swap: 6144M Total, 34M Used, 6110M Free, 348K Out >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT- > . . . >=20 > The combination 1618M Mem:Active but 34M Swap:Used > and 651M xz:SIZE but 27M xz:RES and 0K xz:SWAP just > seems very odd, like it should not happen. The 17M > Mem:Inact is odd for the context as well. (Mem:Wired, > Mem:Buf, and Mem:Free look normal.) >=20 > An alternate hypothesis would be the memory "leak" > is from mkimg not having it memory-use cleaned up. > This happens after vm_copy_base but before the cp/xz > sequence and is what produces vm.raw. mkimg also release its memory (including RAM) each time. But the later "cp -p" of the large vm.raw that I was producing ended up without leaving the free memory that is expected after it finished. I worked around the issue with (just a personal workaround that helps in other respects as well): Index: Makefile.vm =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Makefile.vm (revision 317015) +++ Makefile.vm (working copy) @@ -119,15 +119,20 @@ vm-install: .if defined(WITH_VMIMAGES) && !empty(WITH_VMIMAGES) mkdir -p ${DESTDIR}/vmimages -. for FORMAT in ${VMFORMATS} - cp -p ${VMBASE}.${FORMAT} \ - ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT} -. endfor . if defined(WITH_COMPRESSED_VMIMAGES) && = !empty(WITH_COMPRESSED_VMIMAGES) . for FORMAT in ${VMFORMATS} - # Don't keep the originals. There is a copy in ${.OBJDIR} if = needed. - ${XZ_CMD} ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT} + # Tradeoff "cp -p" property for less memory, I/O, and time use. + # Also: -3 got > 30 MiByte/sec effective (source file) for 32 = GiByte, mostly-zero image + # on a Pine64+ 2GB and used about 600 MiBytes of "active virtual = memory". The about 16 + # minutes was vastly faster than the "cp -p" --and the sha512 = and sha256 are vastly + # faster on the compressed file as well. + ${XZ_CMD} -T 0 -3 --stdout --memlimit-compress=3D50% -v = ${VMBASE}.${FORMAT} > ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT}.xz . endfor +. else +. for FORMAT in ${VMFORMATS} + cp -p ${VMBASE}.${FORMAT} \ + ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT} +. endfor . endif cd ${DESTDIR}/vmimages && sha512 ${OSRELEASE}* > \ ${DESTDIR}/vmimages/CHECKSUM.SHA512 and using WITH_COMPRESSED_VMIMAGES to avoid a "cp -p" based copy of the large file. Prior reports from capturing text: On 2017-Apr-27, at 7:31 PM, Mark Millard wrote: > [Another example panic. Again no dump. But I have what > a top -PCwaopid froze at this time.] >=20 > On 2017-Apr-27, at 4:22 PM, Mark Millard = wrote: >=20 >> Unfortunately for this FYI the attempt to produce a dump >> failed and so all the information that I have is what I >> first captured from the console output: a backtrace. >>=20 >> The context was head -r317015 on a Pine64+ 2GB. At the >> time I was experimenting with trying to build a vm.raw >> from my own build of FreeBSD. The (root) file system >> is on a USB SSD off of a powered USB hub. >>=20 >> panic: ARM64TODO: reclaim_pv_chunk >> cpuid =3D 1 >> time =3D 1493332968 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >> sp =3D 0xffff000083ba4f00 fp =3D 0xffff000083ba5110 >>=20 >> db_trace_self_wrapper() at vpanic+0x164 >> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >> sp =3D 0xffff000083ba5120 fp =3D 0xffff000083ba5190 >>=20 >> vpanic() at panic+0x4c >> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >> sp =3D 0xffff000083ba51a0 fp =3D 0xffff000083ba5220 >>=20 >> panic() at reclaim_pv_chunk+0x10 >> pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 >> sp =3D 0xffff000083ba5230 fp =3D 0xffff000083ba5230 >>=20 >> reclaim_pv_chunk() at get_pv_entry+0x240 >> pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 >> sp =3D 0xffff000083ba5240 fp =3D 0xffff000083ba5260 >>=20 >> get_pv_entry() at pmap_enter+0x694 >> pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 >> sp =3D 0xffff000083ba5270 fp =3D 0xffff000083ba5300 >>=20 >> pmap_enter() at vm_fault_hold+0x28c >> pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 >> sp =3D 0xffff000083ba5310 fp =3D 0xffff000083ba5460 >>=20 >> vm_fault_hold() at vm_fault+0x70 >> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >> sp =3D 0xffff000083ba5470 fp =3D 0xffff000083ba54a0 >>=20 >> vm_fault() at data_abort+0xe0 >> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >> sp =3D 0xffff000083ba54b0 fp =3D 0xffff000083ba5560 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >> sp =3D 0xffff000083ba5570 fp =3D 0xffff000083ba5680 >>=20 >> handle_el1h_sync() at kern_select+0x9fc >> pc =3D 0xffff000000607870 lr =3D 0xffff00000037db3c >> sp =3D 0xffff000083ba5690 fp =3D 0xffff000083ba58f0 >>=20 >> kern_select() at sys_select+0x5c >> pc =3D 0xffff00000037db3c lr =3D 0xffff00000037dc58 >> sp =3D 0xffff000083ba5900 fp =3D 0xffff000083ba5930 >>=20 >> sys_select() at do_el0_sync+0xa48 >> pc =3D 0xffff00000037dc58 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000083ba5940 fp =3D 0xffff000083ba5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000083ba5a80 fp =3D 0xffff000083ba5b90 >>=20 >> handle_el0_sync() at 0x4948c >> pc =3D 0xffff0000006079e8 lr =3D 0x000000000004948c >> sp =3D 0xffff000083ba5ba0 fp =3D 0x0000ffffffffd960 >=20 >=20 > This time I got to record from top: > (swap is on a swap partition) > (pid 49888's SIZE vs. RES and SWAP might be interesting) > (as might the Active figure) >=20 > last pid: 48988; load averages: 0.64, 0.44, 0.38 = = up 0+04:21:01 19:19:50 > 32 processes: 2 running, 30 sleeping > CPU 0: 13.2% user, 0.0% nice, 23.2% system, 0.3% interrupt, 63.3% = idle > CPU 1: 4.6% user, 0.0% nice, 23.9% system, 0.0% interrupt, 71.5% = idle > CPU 2: 2.1% user, 0.0% nice, 23.2% system, 0.0% interrupt, 74.8% = idle > CPU 3: 3.3% user, 0.0% nice, 23.8% system, 0.0% interrupt, 72.8% = idle > Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free > Swap: 6144M Total, 34M Used, 6110M Free, 348K Out >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw > 11983 root 1 22 0 5068K 0K 0K wait 3 0:00 = 0.00% make vm-image vm-install DESTDIR=3D/usr/obj/DESTDIRs/vmimage-aarch64= () > 11981 root 1 42 0 7320K 0K 1516K wait 1 0:00 = 0.00% sh = /root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_b= ootstrap-aarch64-host.sh vm-image vm-install=20 > 11980 root 1 20 0 6656K 1548K 0K select 0 0:02 = 0.00% [script] > 11977 root 1 30 0 7320K 0K 1516K wait 3 0:00 = 0.00% /bin/sh = /root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-= aarch64-host.sh vm-image vm-install DEST > 2694 root 1 20 0 8804K 2072K 0K CPU2 2 0:07 = 0.17% top -PCwaopid > 827 root 1 20 0 7320K 0K 360K wait 0 0:00 = 0.00% su () > 826 markmi 1 22 0 10372K 0K 1532K wait 3 0:00 = 0.00% su () > 820 markmi 1 24 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 819 markmi 1 20 0 18416K 1152K 0K select 1 0:21 = 0.00% sshd: markmi@pts/1 (sshd) > 816 root 1 20 0 18416K 3276K 0K select 0 0:00 = 0.00% sshd: markmi [priv] (sshd) > 765 root 1 20 0 7320K 0K 224K wait 2 0:00 = 0.00% su () > 764 markmi 1 23 0 10372K 0K 1532K wait 0 0:00 = 0.00% su () > 758 markmi 1 31 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 757 markmi 1 20 0 18416K 228K 904K select 3 0:01 = 0.01% sshd: markmi@pts/0 (sshd) > 754 root 1 25 0 18416K 3276K 0K select 1 0:00 = 0.00% sshd: markmi [priv] (sshd) > 746 root 1 27 0 7320K 1532K 0K ttyin 0 0:00 = 0.00% -sh (sh) > 745 root 1 20 0 10372K 0K 1532K wait 1 0:00 = 0.00% login [pam] () > 700 root 1 20 0 6948K 0K 168K nanslp 1 0:00 = 0.00% /usr/sbin/cron -s () > 696 smmsp 1 20 0 10460K 0K 184K pause 0 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = () > 693 root 1 20 0 10460K 1392K 0K select 1 0:00 = 0.03% sendmail: accepting connections (sendmail) > 690 root 1 20 0 15800K 968K 0K select 2 0:00 = 0.00% /usr/sbin/sshd > 661 root 1 20 0 6656K 344K 0K select 2 0:01 = 0.00% /usr/sbin/powerd > 658 root 2 20 0 12788K 12672K 0K select 0 0:02 = 0.01% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > 620 root 32 52 0 6384K 1100K 0K rpcsvc 1 0:00 = 0.00% nfsd: server (nfsd) > 619 root 1 52 0 6384K 704K 0K select 1 0:00 = 0.00% nfsd: master (nfsd) > 617 root 1 20 0 6684K 688K 0K select 1 0:00 = 0.00% /usr/sbin/mountd -r > 478 root 1 20 0 6676K 596K 0K select 3 0:00 = 0.00% /usr/sbin/rpcbind > 469 root 1 20 0 6680K 572K 0K select 2 0:00 = 0.00% /usr/sbin/syslogd -s > 396 root 1 20 0 9580K 32K 0K select 0 0:00 = 0.00% /sbin/devd > 308 _dhcp 1 20 0 6800K 532K 0K select 2 0:00 = 0.00% dhclient: awg0 (dhclient) > 307 root 1 52 0 6800K 424K 0K select 2 0:00 = 0.00% dhclient: awg0 [priv] (dhclient) >=20 > And here is the backtrace: >=20 > timeout stopping cpus > panic: ARM64TODO: reclaim_pv_chunk > cpuid =3D 0 > time =3D 1493345992 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000083d301d0 fp =3D 0xffff000083d303e0 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000083d303f0 fp =3D 0xffff000083d30460 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000083d30470 fp =3D 0xffff000083d304f0 >=20 > panic() at reclaim_pv_chunk+0x10 > pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 > sp =3D 0xffff000083d30500 fp =3D 0xffff000083d30500 >=20 > reclaim_pv_chunk() at get_pv_entry+0x240 > pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 > sp =3D 0xffff000083d30510 fp =3D 0xffff000083d30530 >=20 > get_pv_entry() at pmap_enter+0x694 > pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 > sp =3D 0xffff000083d30540 fp =3D 0xffff000083d305d0 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000083d305e0 fp =3D 0xffff000083d30730 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000083d30740 fp =3D 0xffff000083d30770 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000083d30780 fp =3D 0xffff000083d30830 >=20 > data_abort() at handle_el0_sync+0x6c > pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 > sp =3D 0xffff000083d30840 fp =3D 0xffff000083d30950 >=20 > handle_el0_sync() at 0x400a3de4 > pc =3D 0xffff0000006079e8 lr =3D 0x00000000400a3de4 > sp =3D 0xffff000083d30960 fp =3D 0x0000ffffbfdfcd30 >=20 > KDB: enter: panic > [ thread pid 48988 tid 100230 ] > Stopped at kdb_enter+0x44: undefined d4200000 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon May 1 11:24:01 2017 Return-Path: Delivered-To: freebsd-current@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 96675D58DD0; Mon, 1 May 2017 11:24:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F870DCA; Mon, 1 May 2017 11:24:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::2556:429f:1cfe:ff62] (unknown [IPv6:2001:470:7a58:0:2556:429f:1cfe:ff62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A677B3910D; Mon, 1 May 2017 13:23:51 +0200 (CEST) From: Dimitry Andric Message-Id: <956017AF-5AF8-498F-A55F-8F29A986E12E@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_898E15BF-6399-499F-BAA3-3E2485A04006"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm Date: Mon, 1 May 2017 13:23:43 +0200 In-Reply-To: Cc: "freebsd-mips@freebsd.org" , freebsd-current , Gerald Pfeifer To: Adrian Chadd References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 11:24:01 -0000 --Apple-Mail=_898E15BF-6399-499F-BAA3-3E2485A04006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Mar 2017, at 08:00, Adrian Chadd wrote: >=20 > =3D=3D=3D> lib/clang (all) > =3D=3D=3D> lib/clang/libllvm (all) > In file included from > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/math.h:309:0= , > from > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/cmath:305, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/lib/clang/include/llvm/Sup= port/DataTypes.h:34, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= ADT/Hashing.h:48, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= ADT/ArrayRef.h:13, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= ADT/DenseMapInfo.h:17, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= ADT/DenseMap.h:17, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= IR/ValueMap.h:29, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= Transforms/Utils/ValueMapper.h:18, > from > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transform= s/Utils/ValueMapper.cpp:15: > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= > In substitution of 'template static > std::__1::true_type > std::__1::__is_constructible_helper::__test_nary(int) [with _Tp =3D > {anonymous}::MDNodeMapper::Data; _Args =3D {}; = > =3D ]': > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= 2993:59: > required from 'struct > std::__1::__is_default_constructible<{anonymous}::MDNodeMapper::Data, > false>' > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= 3015:8: > required from 'struct > std::__1::__libcpp_is_constructible<{anonymous}::MDNodeMapper::Data>' > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= 3043:29: > required from 'struct > std::__1::is_constructible<{anonymous}::MDNodeMapper::Data>' > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= 3229:29: > required from 'struct > std::__1::is_default_constructible<{anonymous}::MDNodeMapper::Data>' > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:352:= 15: > required from 'static constexpr bool std::__1::pair<_T1, > _T2>::_CheckArgs::__enable_default() [with _U1 =3D const > llvm::Metadata*; _U2 =3D {anonymous}::MDNodeMapper::Data; _T1 =3D = const > llvm::Metadata*; _T2 =3D {anonymous}::MDNodeMapper::Data]' > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/utility:403:= 71: > required by substitution of 'template std::__1::enable_if std::__1::pair {anonymous}::MDNodeMapper::Data>::_CheckArgs, > std::__1::__check_tuple_constructor_fail>::type:: > __enable_default(), bool>::type > > constexpr std::__1::pair<_T1, _T2>::pair() [with bool _Dummy =3D true; > typename std::__1::enable_if std::__1::conditional<_MaybeEnable, std::__1::pair llvm::Metadata*, {anonymous}::MDNodeMapper::Data>::_CheckArgs, > std::__1::__check_tuple_constructor_fail>::type:: > __enable_default(), bool>::type =3D > ]' > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= ADT/DenseMap.h:39:8: > required from 'struct llvm::detail::DenseMapPair llvm::Metadata*, {anonymous}::MDNodeMapper::Data>' > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= Support/AlignOf.h:111:6: > required from 'class > llvm::detail::AlignerImpl llvm::Metadata*, {anonymous}::MDNodeMapper::Data> [32], > llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>::LargeRep, char, char, char, > char, char, char, char, char>' > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= Support/AlignOf.h:138:8: > required from 'struct > llvm::AlignedCharArrayUnion llvm::Metadata*, {anonymous}::MDNodeMapper::Data> [32], > llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>::LargeRep, char, char, char, > char, char, char, char, char>' > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/include/llvm/= ADT/DenseMap.h:759:59: > required from 'class llvm::SmallDenseMap {anonymous}::MDNodeMapper::Data, 32u>' > = /usr/home/adrian/work/freebsd/head-embedded/src/contrib/llvm/lib/Transform= s/Utils/ValueMapper.cpp:182:47: > required from here > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= 2980:9: > error: constructor required before non-static data member for > '{anonymous}::MDNodeMapper::Data::HasChanged' has been parsed > class =3D decltype(_Tp(_VSTD::declval<_Args>()...))> > ^ > = /usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/mips.mips/usr/home= /adrian/work/freebsd/head-embedded/src/tmp/usr/include/c++/v1/type_traits:= 2980:9: > error: constructor required before non-static data member for > '{anonymous}::MDNodeMapper::Data::ID' has been parsed > *** Error code 1 FWIW, I finally took some time to look at this properly, and it turns out it is a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D70528 The fix, https://gcc.gnu.org/viewcvs/gcc?view=3Drevision&revision=3D235002= , has not been merged to the gcc 5.x branch, even though it seems fairly trivial. We might want to apply this one manually to our gcc 5 ports, for the mean time, while prodding upstream to merge it. -Dimitry --Apple-Mail=_898E15BF-6399-499F-BAA3-3E2485A04006 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkHGscACgkQsF6jCi4glqOPpACbBJBHudZVrJeAteKgMb6RZDHl 13gAoJO0Q8IzhpOEOqUuoG/9KL3J9lTp =Mn9V -----END PGP SIGNATURE----- --Apple-Mail=_898E15BF-6399-499F-BAA3-3E2485A04006-- From owner-freebsd-current@freebsd.org Mon May 1 13:00:01 2017 Return-Path: Delivered-To: freebsd-current@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 6C7C9D58CF9 for ; Mon, 1 May 2017 13:00:01 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 43EA89B5 for ; Mon, 1 May 2017 13:00:00 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 402C920890 for ; Mon, 1 May 2017 08:59:54 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 01 May 2017 08:59:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; 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-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VmQjZV DhedN0NDAqfcEO/GMLAsERcPIF8dZOaS+Yga8=; b=GSZJM7uTuC+yVgb0C//yuY MIWHPF9yxy0rrTcpvYYS06tXIBzio1/LgOSYQaxuRT0/N++vumN7xQ+lgItUZ9Gg F7Fr1hDm84V+VOPrGWCoGAGLoR6Pd7wotX9g2oRBJcEIPuZHGIRxoObnR2kaK83f 18Pcctew1lqUgyqt65Jc3ZSCkPQFcWNOp8oHjczdlcuBWWobt2oVFqfXTlszkWfy I0vB9w2ssRsEiqM9TUxVcn33mNgy93mvidxDtqxeC+tGK+ZooCZeI8UKhzKwghNW W3XarlizfM65EG1sgv5eOS4L+IsKgTcH1eeKzo1W4vYdTaX+cLZcFtO2PGjRo6Hw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1B99B9ED4B; Mon, 1 May 2017 08:59:54 -0400 (EDT) Message-Id: <1493643594.1405264.961730960.75BB4F83@webmail.messagingengine.com> From: Josh Paetzel To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-88a795dc References: <32c84a1f-1377-e0a1-1c8b-d22eea80d871@FreeBSD.org> <19ac2524eba83333063822c063c6af3e@mikej.com> <75e7cde3-b064-5754-192d-00f8a65788b8@FreeBSD.org> Subject: Re: Panic String: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) != 0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631 Date: Mon, 01 May 2017 07:59:54 -0500 In-Reply-To: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 13:00:01 -0000 > Andriy: > > I am happy to report that the system no longer panics. As requested I > removed > the remaining logs (34G worth) and punished the file system as hard as I > could. > > A scrub of the pool completed without error > > Will the change be committed or do I need to open a PR? > > Please let me know if I can supply additional information or if there > are any > further tests you would like me to perform. > > Thanks again for you prompt reply and apparent solution. > > Regards, > > Michael Jung > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Great news. I committed the fix this morning. Thanks for reporting the problem and testing the fix. -- Thanks, Josh Paetzel From owner-freebsd-current@freebsd.org Mon May 1 18:43:07 2017 Return-Path: Delivered-To: freebsd-current@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 85233D59E85 for ; Mon, 1 May 2017 18:43:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60679637; Mon, 1 May 2017 18:43:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id AC75D10A82D; Mon, 1 May 2017 14:43:05 -0400 (EDT) From: John Baldwin To: Sepherosa Ziehau Cc: Dexuan Cui , "freebsd-current@freebsd.org" , Jung-uk Kim , Yanmin Qiao Subject: Re: Add support for ACPI Module Device ACPI0004? Date: Mon, 01 May 2017 09:25:44 -0700 Message-ID: <6993108.fO6lomHkak@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <1737882.TJdaAP1hO8@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 01 May 2017 14:43:05 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 18:43:07 -0000 On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote: > On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin wrote: > > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote: > >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote: > >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote: > >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote: > >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote: > >> >> >> > From: John Baldwin [mailto:jhb@freebsd.org] > >> >> >> > Sent: Thursday, April 20, 2017 02:34 > >> >> >> > > Can we add the support of "ACPI0004" with the below one-line change? > >> >> >> > > > >> >> >> > > acpi_sysres_probe(device_t dev) > >> >> >> > > { > >> >> >> > > - static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL }; > >> >> >> > > + static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL }; > >> >> >> > > > >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though we > >> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since historically > >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things like the > >> >> >> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in the ACPI > >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that? In particular, it > >> >> >> > seems that 004 should only allow direct children to suballocate? This > >> >> >> > change might work, but it will allow more devices to allocate the ranges in > >> >> >> > _CRS than otherwise. > >> >> >> > > >> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004 > >> >> >> > node that you can share? > >> >> >> > > >> >> >> > John Baldwin > >> >> >> > >> >> >> Hi John, > >> >> >> Thanks for the help! > >> >> >> > >> >> >> Please see the attached file, which is got by > >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz" > >> >> >> > >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of > >> >> >> "VMBus" (VMBS). > >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't > >> >> >> see the length of the MMIO range in the dumped asl code, it does have > >> >> >> a 512MB MMIO range [0xFE0000000, 0xFFFFFFFFF]. > >> >> >> > >> >> >> It looks FreeBSD can't detect ACPI0004 automatically. > >> >> >> With the above one-line change, I can first find the child device > >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get > >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range. > >> >> >> > >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess > >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus > >> >> >> driver as a child device of acpi0? > >> >> > > >> >> > Hmmm, so looking at this, the "right" thing is probably to have a device > >> >> > driver for the ACPI0004 device that parses its _CRS and then allows its > >> >> > child devices to sub-allocate resources from the ranges in _CRS. However, > >> >> > this would mean make VMBus be a child of the ACPI0004 device. Suppose > >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device > >> >> > would need to create a child device for all of its child devices. Right > >> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0 > >> >> > creates child devices anywhere in its namespace that have a valid _HID). > >> >> > You can find those duplicates and remove them during acpi_module0's attach > >> >> > routine before creating its own child device_t devices. (We associate > >> >> > a device_t with each Handle when creating device_t's for ACPI handles > >> >> > which is how you can find the old device that is a direct child of acpi0 > >> >> > so that it can be removed). > >> >> > >> >> The remove/reassociate vmbus part seems kinda "messy" to me. I'd just > >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what > >> >> we did to the hyper-v's pcib0. > >> > > >> > The acpi_pci driver used to do the remove/reassociate part. What acpi0 > >> > should probably be doing is only creating device_t nodes for immediate > >> > children. This would require an ACPI-aware isa0 for LPC devices below > >> > the ISA bus in the ACPI namespace. We haven't done that in part because > >> > BIOS vendors are not always consistent in placing LPC devices under an > >> > ISA bus. However, you otherwise have no good way to find your parent > >> > ACPI0004 device. You could perhaps find your ACPI handle, ask for its > >> > parent handle, then ask for the device_t of that handle to find the > >> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource > >> > calls go to that device, not your "real" parent of acpi0, which means > >> > you can't use any of the standard bus_alloc_resource() methods like > >> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE > >> > with the ACPI0004 device as the explicit first argument. It is primarily > >> > the ability to let ACPI0004's driver transparently intercept all the > >> > resource allocation so it can manage that is the reason for "VMBus" > >> > to be a child of ACPI0004 rather than its sibling. > >> > >> Well, there could be more then one ACPI0004 typed devices, which could > >> not form a device tree for vmbus. > > > > Are you saing a vmbus would need resources from multiple ACPI0004 devices? > > ACPI0004 (and several other PNP ids, see dexuan's submission) is > something just like the acpi_sysresource. Not directly related to the > vmbus at all. In the acpidump, the "vmbus" device was a direct child of ACPI0004. This is quite different from acpi_sysresource0 which can be in random places in the namespace (sometimes it is off of isab0, sometimes it is a child of isab0 or of _SB_), and thus devices that suballocate ranges it reserves (like ipmi0 or acpi_ec0) are sometimes siblings, etc. That doesn't seem to be true for ACPI004 as it is explicitly described as a container object. -- John Baldwin From owner-freebsd-current@freebsd.org Mon May 1 21:31:07 2017 Return-Path: Delivered-To: freebsd-current@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 388C8D59F4D for ; Mon, 1 May 2017 21:31:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0611230 for ; Mon, 1 May 2017 21:31:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id l50so68769324wrc.3 for ; Mon, 01 May 2017 14:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pSk6UeYZ12EZpaJmoem4RtLHHn0n8ELhhgK5je/6YH0=; b=BwfynnaF0bgNNOGRowlV3meRabqW+nmUsw5CCviBal8Yf3ir4oSlT9eUCi3pEbXl16 fEOR6rwfkoBl7U4dCebCeTBn2p3TKbV/Ul+LQHaRqjK1h33dZe/Sv5OKDPYXvTgyMV2F dEO508p5T22Ood/6M/qXGvb23/KNsasL2LW9zT5SlRnPByDHdyb1HBAf8obVvHD+83p6 lOfAa0Gpf2Y8tylZnOlB+L0MY9yX4z05UxDvgQpiIlWljmFFHqxr+3rApMBxGey3PVcB 6ZuNRklxqFdgYw3HdR4DCawZ+ni+4zNTRmsjkkruB2/4RBb6ovTx1rnLijnQOZigqI4Y bytw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pSk6UeYZ12EZpaJmoem4RtLHHn0n8ELhhgK5je/6YH0=; b=FUF/+0Cy96ASvlhUdIfIfw9uIKtLJu2FFkqeh7G4GVY7AifkDl+2P2ID6PBI7uVbjj l1/n17UlhDXCRNiY9IYGZaHJ6xq9UkmHXH9iV4j2t0vN7bV2cFvs2/Dh//mW9u525mzJ 3Z6I/mTUWmq1xu/WXbftdKa6/EM/3RuaUHhRWXc+xJ3iJITFLRoyhQ+6h1PIiSUwqz/m GYx25+XKHpvd5dkyHpgVo38zIQd3gtt0MSwvJ9ZkAYqhG8TIC6hFJieuwpB8K3DQWC2A 7jqaTkn5sPjJqyIz7tNu1OiaKE/t08UMoabeKDFDge8mdFYgeneTLJLnpmj3y/i0mLbg zWhA== X-Gm-Message-State: AN3rC/4s9UbVy7cmyijRTl3ThoiK7Pk5zN5C5Rvll1GqbRrfiEAE8Y/r SaHj9DS0Rt30AHsnpFTa/6RtQdst9Q== X-Received: by 10.223.164.148 with SMTP id g20mr17342574wrb.89.1493674265031; Mon, 01 May 2017 14:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.209.197 with HTTP; Mon, 1 May 2017 14:31:04 -0700 (PDT) In-Reply-To: <20170429115017.GA98553@freebsd-t420.fritz.box> References: <20170429115017.GA98553@freebsd-t420.fritz.box> From: Adrian Chadd Date: Mon, 1 May 2017 14:31:04 -0700 Message-ID: Subject: Re: regression suspend/resume on Lenovo T420 To: =?UTF-8?Q?Manuel_St=C3=BChn?= Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 21:31:07 -0000 There were lots of commits that could break things. :-) Can you compile up some intermediary versions between 315141 and r317559 to find which commit range broke things? That'll make chasing it down much quicker! Thanks! -a On 29 April 2017 at 04:50, Manuel St=C3=BChn wro= te: > Hi, > I'd been sucessfully running CURRENT on my Lenovo T420 with functional > suspend/resume since some time. But after updating to CURRENT r317032 > respectively r317559 suspend/resume does not work anymore. Putting it int= o > suspend results only in a black screen, but no further action is possible > (only pressing the powerbutton for some time to switch it off completely)= . > The LEDs are not indicating any suspend mode. > If i try to suspend it with X (intel-driver) stopped, the laptop does swi= tch > into suspend, but does not resume. It runs into some kind of resuming > endless loop, where it tries to start the laptop again but at a certain > point it restarts again. The screen stays dark all the time. > > I tried this with and without the following options but the same result. > hw.acpi.reset_video=3D1 > dev.acpi_ibm.0.handlerevents=3D'0x04' > > Booting a Bootenvironment with an older CURRENT(r315141), all is working. > Was there any change between these commits concerning suspend/resume? > > BR > Manuel > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Tue May 2 03:28:38 2017 Return-Path: Delivered-To: freebsd-current@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 04904D58F93 for ; Tue, 2 May 2017 03:28:38 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 BC461252; Tue, 2 May 2017 03:28:37 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-ua0-x235.google.com with SMTP id e55so45637529uaa.2; Mon, 01 May 2017 20:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4v2K/j6FeSMWC+plDczqTJm4QOnAe8GffsWZ/BvYeoo=; b=usio0RL4js+GyqO/nss88VoUssVL3yi0yBQaacvd7GQS3bYeSukVbL5P9cx7ff4q6w zD9HlfY8Iu0GyMoEF00Fj4WW7yjNMDk4GhiW3EV54m1EuZTejzHC6DnR1JiA/D9SBgwk iKiuwPbTZBeiKwQmyERvvYOL4GeMY1BFEowGnArnlPjngcCM73a7Qvd3q1MsTKk6loLK 8MWRfNIaWoJrdq09KS+wTQ7T/id8eiwYPMp8wqzYA+MZwL2AqmiubmTysPfzqjJ1OdWf pyC4nSQvNroX4ErdPaaZpICbHMoB096d0E4ywFiGObR1k2Yba6/ltuB7tpR2V4jpUl0f jg7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4v2K/j6FeSMWC+plDczqTJm4QOnAe8GffsWZ/BvYeoo=; b=KsHAiSwfZn+H1UsEaX3ZQA0CQHGbTk+TygsySJSG63cFNQxmWbqN1HEfWbEEjRNksu 91fwbg2UUMnCSij+s57X9Xw8A2NBqI5NmQPHpvyG5YsbrAHkQcmups3tuS/2PLfSyWVM sNcnUwfdDrthdgTFQ0dA5DP43BToh2LskPXDn2UMzeUg3Wfr90NzNMawM7zTNvXfOt9m T50aiMvi4lVY88GN0Q3fODuM0vYWx6HL+dJxs8gxktZHVpoEgWNWnDssUnfSjv0K9uh5 1oFHHs4kxl0D0wKX5ilwdbI4ID1jwWs9TQYj2/oM+xOtyznumrQN22aLNfGQXiJWdqPE MAzQ== X-Gm-Message-State: AN3rC/79uT6GURXZlWQSg31J9plDlastQgCh37huzc+kFUZ/GdPfJ1vA PmKKYzbrNsXanqd8u4D1ETP/as1AIA== X-Received: by 10.159.48.144 with SMTP id j16mr2644160uab.131.1493695716229; Mon, 01 May 2017 20:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.43 with HTTP; Mon, 1 May 2017 20:28:35 -0700 (PDT) In-Reply-To: <6993108.fO6lomHkak@ralph.baldwin.cx> References: <1737882.TJdaAP1hO8@ralph.baldwin.cx> <6993108.fO6lomHkak@ralph.baldwin.cx> From: Sepherosa Ziehau Date: Tue, 2 May 2017 11:28:35 +0800 Message-ID: Subject: Re: Add support for ACPI Module Device ACPI0004? To: John Baldwin Cc: Dexuan Cui , "freebsd-current@freebsd.org" , Jung-uk Kim , Yanmin Qiao Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 03:28:38 -0000 On Tue, May 2, 2017 at 12:25 AM, John Baldwin wrote: > On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote: >> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin wrote: >> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote: >> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote: >> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote: >> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote: >> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote: >> >> >> >> > From: John Baldwin [mailto:jhb@freebsd.org] >> >> >> >> > Sent: Thursday, April 20, 2017 02:34 >> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line change? >> >> >> >> > > >> >> >> >> > > acpi_sysres_probe(device_t dev) >> >> >> >> > > { >> >> >> >> > > - static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL }; >> >> >> >> > > + static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL }; >> >> >> >> > > >> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though we >> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since historically >> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things like the >> >> >> >> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in the ACPI >> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that? In particular, it >> >> >> >> > seems that 004 should only allow direct children to suballocate? This >> >> >> >> > change might work, but it will allow more devices to allocate the ranges in >> >> >> >> > _CRS than otherwise. >> >> >> >> > >> >> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004 >> >> >> >> > node that you can share? >> >> >> >> > >> >> >> >> > John Baldwin >> >> >> >> >> >> >> >> Hi John, >> >> >> >> Thanks for the help! >> >> >> >> >> >> >> >> Please see the attached file, which is got by >> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz" >> >> >> >> >> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of >> >> >> >> "VMBus" (VMBS). >> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't >> >> >> >> see the length of the MMIO range in the dumped asl code, it does have >> >> >> >> a 512MB MMIO range [0xFE0000000, 0xFFFFFFFFF]. >> >> >> >> >> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically. >> >> >> >> With the above one-line change, I can first find the child device >> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get >> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range. >> >> >> >> >> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess >> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus >> >> >> >> driver as a child device of acpi0? >> >> >> > >> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a device >> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows its >> >> >> > child devices to sub-allocate resources from the ranges in _CRS. However, >> >> >> > this would mean make VMBus be a child of the ACPI0004 device. Suppose >> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device >> >> >> > would need to create a child device for all of its child devices. Right >> >> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0 >> >> >> > creates child devices anywhere in its namespace that have a valid _HID). >> >> >> > You can find those duplicates and remove them during acpi_module0's attach >> >> >> > routine before creating its own child device_t devices. (We associate >> >> >> > a device_t with each Handle when creating device_t's for ACPI handles >> >> >> > which is how you can find the old device that is a direct child of acpi0 >> >> >> > so that it can be removed). >> >> >> >> >> >> The remove/reassociate vmbus part seems kinda "messy" to me. I'd just >> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what >> >> >> we did to the hyper-v's pcib0. >> >> > >> >> > The acpi_pci driver used to do the remove/reassociate part. What acpi0 >> >> > should probably be doing is only creating device_t nodes for immediate >> >> > children. This would require an ACPI-aware isa0 for LPC devices below >> >> > the ISA bus in the ACPI namespace. We haven't done that in part because >> >> > BIOS vendors are not always consistent in placing LPC devices under an >> >> > ISA bus. However, you otherwise have no good way to find your parent >> >> > ACPI0004 device. You could perhaps find your ACPI handle, ask for its >> >> > parent handle, then ask for the device_t of that handle to find the >> >> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource >> >> > calls go to that device, not your "real" parent of acpi0, which means >> >> > you can't use any of the standard bus_alloc_resource() methods like >> >> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE >> >> > with the ACPI0004 device as the explicit first argument. It is primarily >> >> > the ability to let ACPI0004's driver transparently intercept all the >> >> > resource allocation so it can manage that is the reason for "VMBus" >> >> > to be a child of ACPI0004 rather than its sibling. >> >> >> >> Well, there could be more then one ACPI0004 typed devices, which could >> >> not form a device tree for vmbus. >> > >> > Are you saing a vmbus would need resources from multiple ACPI0004 devices? >> >> ACPI0004 (and several other PNP ids, see dexuan's submission) is >> something just like the acpi_sysresource. Not directly related to the >> vmbus at all. > > In the acpidump, the "vmbus" device was a direct child of ACPI0004. This is > quite different from acpi_sysresource0 which can be in random places in the > namespace (sometimes it is off of isab0, sometimes it is a child of isab0 or > of _SB_), and thus devices that suballocate ranges it reserves (like ipmi0 > or acpi_ec0) are sometimes siblings, etc. That doesn't seem to be true for > ACPI004 as it is explicitly described as a container object. Thanks for the suggestion. We are reorganizing the tree. The original ACPI device (VMBUS) is left as a resource device, instead of moving it around. Thanks, sephe -- Tomorrow Will Never Die From owner-freebsd-current@freebsd.org Tue May 2 06:35:10 2017 Return-Path: Delivered-To: freebsd-current@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 F3980D5A97C for ; Tue, 2 May 2017 06:35:10 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABFC8782; Tue, 2 May 2017 06:35:10 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-vk0-x22c.google.com with SMTP id i65so28681885vkh.0; Mon, 01 May 2017 23:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SbNF0rUQuYKIXNYzux63scILX+czJ/LfntDPiVHQ2Xw=; b=gdFwQOEuEOWfyxXSUTbmj7A7Nv+jAFPgtaLEflfEjmQ3vjmgxRLiSEVpsFacJmbSew A+obkK/QxA1MsRaulbgfHWWHqEfnbB2yOuHtnw4+h/tImsjv2O1ou/T3HgUDctrWAxAE qy0JQKUBY+APM1F/ER0xzBAPOakl43/nEEF/FSFHy54oJRyhDXzCIrfrpJeyK70hu6YU atvtpV71qPq8KWb6ynPQPS+upAzrbmBiGAAa4WSHZuPDdhu8ip/iurTmFHB2sQQKWYUX Y4vF9pqQjRYjPr2b8h+FW/D/go1iMP2l9SgrdLm4ttuqa5Tz2QtR/KnHQ1wsur971OhR Anaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SbNF0rUQuYKIXNYzux63scILX+czJ/LfntDPiVHQ2Xw=; b=hbH7kTASgXSapwcL6HeI4irIwGeIDCN4pxCE0lhx9PYDf4x1QoSiGDZe7VtloEX00c pxX2ArtUJOxWGazMRuNNo+QY6LFz7f6A6S5DkSgad/cPFZBsxBa8cdXFy+jK2sYk1xJ7 xMMP09UgQlWREXh29sfZHUecZHE6AJQadmgOzqi141u31f61EAKW/CBFnNRRMB1BexqA 8b/X/iiVGyv1Lxyas+KOr6cZfOMzQ63lP1EoMMe4pV3o/S35TvRLq325EPZrnOISE2EY OIFhwvm/HodsSzjUGwFEZsEnrs25uQlnIOm2TkatkT37eLpKoRdQRMEE4o2Ux1NsnHdM YmxQ== X-Gm-Message-State: AN3rC/6hBfb1EPYCEQHgvdXuF9WWKzIdYjdyahHYYUDaI5CE/2Ejn1am /SoloRZrJ00odFt6AI41N43Q+XAwUQ== X-Received: by 10.31.201.65 with SMTP id z62mr11685094vkf.16.1493706909488; Mon, 01 May 2017 23:35:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.43 with HTTP; Mon, 1 May 2017 23:35:08 -0700 (PDT) In-Reply-To: References: <1737882.TJdaAP1hO8@ralph.baldwin.cx> <6993108.fO6lomHkak@ralph.baldwin.cx> From: Sepherosa Ziehau Date: Tue, 2 May 2017 14:35:08 +0800 Message-ID: Subject: Re: Add support for ACPI Module Device ACPI0004? To: John Baldwin Cc: Dexuan Cui , "freebsd-current@freebsd.org" , Jung-uk Kim , Yanmin Qiao Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 06:35:11 -0000 On Tue, May 2, 2017 at 11:28 AM, Sepherosa Ziehau wrote: > On Tue, May 2, 2017 at 12:25 AM, John Baldwin wrote: >> On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote: >>> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin wrote: >>> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote: >>> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin wrote: >>> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote: >>> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote: >>> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote: >>> >> >> >> > From: John Baldwin [mailto:jhb@freebsd.org] >>> >> >> >> > Sent: Thursday, April 20, 2017 02:34 >>> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line change? >>> >> >> >> > > >>> >> >> >> > > acpi_sysres_probe(device_t dev) >>> >> >> >> > > { >>> >> >> >> > > - static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL }; >>> >> >> >> > > + static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL }; >>> >> >> >> > > >>> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though we >>> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since historically >>> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things like the >>> >> >> >> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in the ACPI >>> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that? In particular, it >>> >> >> >> > seems that 004 should only allow direct children to suballocate? This >>> >> >> >> > change might work, but it will allow more devices to allocate the ranges in >>> >> >> >> > _CRS than otherwise. >>> >> >> >> > >>> >> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004 >>> >> >> >> > node that you can share? >>> >> >> >> > >>> >> >> >> > John Baldwin >>> >> >> >> >>> >> >> >> Hi John, >>> >> >> >> Thanks for the help! >>> >> >> >> >>> >> >> >> Please see the attached file, which is got by >>> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz" >>> >> >> >> >>> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of >>> >> >> >> "VMBus" (VMBS). >>> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't >>> >> >> >> see the length of the MMIO range in the dumped asl code, it does have >>> >> >> >> a 512MB MMIO range [0xFE0000000, 0xFFFFFFFFF]. >>> >> >> >> >>> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically. >>> >> >> >> With the above one-line change, I can first find the child device >>> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get >>> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range. >>> >> >> >> >>> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess >>> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus >>> >> >> >> driver as a child device of acpi0? >>> >> >> > >>> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a device >>> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows its >>> >> >> > child devices to sub-allocate resources from the ranges in _CRS. However, >>> >> >> > this would mean make VMBus be a child of the ACPI0004 device. Suppose >>> >> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device >>> >> >> > would need to create a child device for all of its child devices. Right >>> >> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0 >>> >> >> > creates child devices anywhere in its namespace that have a valid _HID). >>> >> >> > You can find those duplicates and remove them during acpi_module0's attach >>> >> >> > routine before creating its own child device_t devices. (We associate >>> >> >> > a device_t with each Handle when creating device_t's for ACPI handles >>> >> >> > which is how you can find the old device that is a direct child of acpi0 >>> >> >> > so that it can be removed). >>> >> >> >>> >> >> The remove/reassociate vmbus part seems kinda "messy" to me. I'd just >>> >> >> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what >>> >> >> we did to the hyper-v's pcib0. >>> >> > >>> >> > The acpi_pci driver used to do the remove/reassociate part. What acpi0 >>> >> > should probably be doing is only creating device_t nodes for immediate >>> >> > children. This would require an ACPI-aware isa0 for LPC devices below >>> >> > the ISA bus in the ACPI namespace. We haven't done that in part because >>> >> > BIOS vendors are not always consistent in placing LPC devices under an >>> >> > ISA bus. However, you otherwise have no good way to find your parent >>> >> > ACPI0004 device. You could perhaps find your ACPI handle, ask for its >>> >> > parent handle, then ask for the device_t of that handle to find the >>> >> > ACPI0004 device, but then you'd need to have all your bus_alloc_resource >>> >> > calls go to that device, not your "real" parent of acpi0, which means >>> >> > you can't use any of the standard bus_alloc_resource() methods like >>> >> > bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE >>> >> > with the ACPI0004 device as the explicit first argument. It is primarily >>> >> > the ability to let ACPI0004's driver transparently intercept all the >>> >> > resource allocation so it can manage that is the reason for "VMBus" >>> >> > to be a child of ACPI0004 rather than its sibling. >>> >> >>> >> Well, there could be more then one ACPI0004 typed devices, which could >>> >> not form a device tree for vmbus. >>> > >>> > Are you saing a vmbus would need resources from multiple ACPI0004 devices? >>> >>> ACPI0004 (and several other PNP ids, see dexuan's submission) is >>> something just like the acpi_sysresource. Not directly related to the >>> vmbus at all. >> >> In the acpidump, the "vmbus" device was a direct child of ACPI0004. This is >> quite different from acpi_sysresource0 which can be in random places in the >> namespace (sometimes it is off of isab0, sometimes it is a child of isab0 or >> of _SB_), and thus devices that suballocate ranges it reserves (like ipmi0 >> or acpi_ec0) are sometimes siblings, etc. That doesn't seem to be true for >> ACPI004 as it is explicitly described as a container object. > > Thanks for the suggestion. We are reorganizing the tree. The > original ACPI device (VMBUS) is left as a resource device, instead of > moving it around. We have reorganized the vmbus tree: https://reviews.freebsd.org/D10565 Thanks, sephe -- Tomorrow Will Never Die From owner-freebsd-current@freebsd.org Tue May 2 08:26:21 2017 Return-Path: Delivered-To: freebsd-current@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 8B553D5A4B4 for ; Tue, 2 May 2017 08:26:21 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from valery.hibma.org (valery.hibma.org [IPv6:2a02:2308::216:3eff:fe79:3a6c]) by mx1.freebsd.org (Postfix) with ESMTP id 582C9373 for ; Tue, 2 May 2017 08:26:21 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from [IPv6:2001:980:530a:1:f971:3b91:5cc3:9c3e] (unknown [IPv6:2001:980:530a:1:f971:3b91:5cc3:9c3e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by valery.hibma.org (Postfix) with ESMTPSA id 28CE96E0A17 for ; Tue, 2 May 2017 10:26:18 +0200 (CEST) From: Nick Hibma Content-Type: multipart/signed; boundary="Apple-Mail=_798E884E-DB27-415E-BDBA-9EE6FE0E19FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Compiler optimisation bug Message-Id: <3626A28E-9DF5-4775-BAAB-CC6C36D2CD01@van-laarhoven.org> Date: Tue, 2 May 2017 10:26:17 +0200 To: FreeBSD Current Mailing List X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:26:21 -0000 --Apple-Mail=_798E884E-DB27-415E-BDBA-9EE6FE0E19FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There is a bug in sbin/dhclient.c for large expiry values on 32 bit = platforms where time_t is a uint32_t (bug #218980, = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218980). It is = caused by a compiler optimisation that removes an if-statement. The code = below shows the following output, clearly showing that the optimised = case provides a different answer: % cc -O2 main.c -o main.a && ./main.a no opt: 0x7fffffff with opt: 0xfffffffe rephrased: 0x7fffffff The code is as follows: % cat main.c #include #include #define TIME_MAX 2147483647 time_t a =3D TIME_MAX; time_t b =3D TIME_MAX; time_t add_noopt(time_t a, time_t b) __attribute__((optnone)) { a +=3D b; if (a < b) a =3D TIME_MAX; return a; } time_t add_withopt(time_t a, time_t b) { a +=3D b; if (a < b) a =3D TIME_MAX; return a; } time_t add_rephrased(time_t a, time_t b) { if (a < 0 || a > TIME_MAX - b) a =3D TIME_MAX; else a +=3D b; return a; } int main(int argc, char **argv) { printf("no opt: 0x%08x\n", add_noopt(a, b)); printf("with opt: 0x%08x\n", add_withopt(a, b)); printf("rephrased: 0x%08x\n", add_rephrased(a, b)); } Should this be reported to the clang folks? Or is this to be expected = when abusing integer overflows this way? Also: The underlying problem is the fact that time_t is a 32 bit signed = int. Any pointers as to a general method of resolving these time_t = issues? Regards, Nick Hibma nick@van-laarhoven.org -- Open Source: We stand on the shoulders of giants. --Apple-Mail=_798E884E-DB27-415E-BDBA-9EE6FE0E19FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZCEKpAAoJEB9yHO7GNHbg0ikP/1Ogp7+cmoBQs938GAuI4n1w 9x+f1MHGa4wx4EuJbMRXpjMvnlENuddvLasSQeKoFK+k5exOyd08zkXSIAn7uUix hqwfCPGkgU/Iyan/UGmG4NaS4CgMA4vvdYj0IxMmqNbHW9nBPKtt3NYlcxe/AXfS dR16JJQHjmizSLlSksPFX1/x2g6X26n6ltKTy5KtQ5o1Cr79gVqd3n5YheNfBbF8 FKHmjEadSdAD9j2NUi3pZenGYME7/o11Ptt5V96gORFRQWDFXIs6C2vBTOFFyVy2 LllSe5p77qUk6wd4ZRXbor4C+JJDGzTfRYzT1m+VKM/xuO9lYA4IK9i27EgsyIoA Mfyf5Hof+T7tAczfJUinxYOvSy0fWcdYZ7vZvVcZ4b4d3FQ/J4yo5vaU1BD9Xmz5 x4MfmGgvzlt/IsbaRv0XhF4KbyRAwEYcSDksEGhh3GGkKLNacP5wLgFFLo+DIdPs frluMKpppoH9wwU8nkVJ1VwWzrANyihg9fU+ydkKHtOVpJPeBruWPidUGtQl8cpH SyH+GU+xBQTipV2Dv++XWagsbdJLeMMScKRM7KYlAcygWch7H5B8TbCCSLfn7Jwz 13EJIuCaTcMf1FZntpGqepcUfBCgJCQ3EupC1GjYmQWcSU07jle/4M4llvvz/KKN 8poY2TjRPQjcWDVrp5eD =K/a9 -----END PGP SIGNATURE----- --Apple-Mail=_798E884E-DB27-415E-BDBA-9EE6FE0E19FD-- From owner-freebsd-current@freebsd.org Tue May 2 08:34:45 2017 Return-Path: Delivered-To: freebsd-current@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 93A49D5A73F for ; Tue, 2 May 2017 08:34:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 3ABD3B11 for ; Tue, 2 May 2017 08:34:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v428Ycu4026143 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 May 2017 11:34:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v428Ycu4026143 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v428YcWP026142; Tue, 2 May 2017 11:34:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 May 2017 11:34:38 +0300 From: Konstantin Belousov To: Nick Hibma Cc: FreeBSD Current Mailing List Subject: Re: Compiler optimisation bug Message-ID: <20170502083438.GA1622@kib.kiev.ua> References: <3626A28E-9DF5-4775-BAAB-CC6C36D2CD01@van-laarhoven.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3626A28E-9DF5-4775-BAAB-CC6C36D2CD01@van-laarhoven.org> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:34:45 -0000 On Tue, May 02, 2017 at 10:26:17AM +0200, Nick Hibma wrote: > There is a bug in sbin/dhclient.c for large expiry values on 32 bit platforms where time_t is a uint32_t (bug #218980, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218980). It is caused by a compiler optimisation that removes an if-statement. The code below shows the following output, clearly showing that the optimised case provides a different answer: > > > % cc -O2 main.c -o main.a && ./main.a > no opt: 0x7fffffff > with opt: 0xfffffffe > rephrased: 0x7fffffff > > The code is as follows: > > % cat main.c > #include > #include > #define TIME_MAX 2147483647 > > time_t a = TIME_MAX; > time_t b = TIME_MAX; > > time_t > add_noopt(time_t a, time_t b) __attribute__((optnone)) > { > a += b; > if (a < b) > a = TIME_MAX; This is a canonical example of the undefined behaviour. Compiler authors consider that they have a blanket there, because the C standard left signed integer overflow as undefined behaviour, to allow implementation using native signed representation. Instead, they abuse the permit to gain 0.5% in some unimportant benchmarks. > return a; > } > > time_t > add_withopt(time_t a, time_t b) > { > a += b; > if (a < b) > a = TIME_MAX; > return a; > } > > time_t > add_rephrased(time_t a, time_t b) > { > if (a < 0 || a > TIME_MAX - b) > a = TIME_MAX; > else > a += b; > return a; > } > > int > main(int argc, char **argv) > { > printf("no opt: 0x%08x\n", add_noopt(a, b)); > printf("with opt: 0x%08x\n", add_withopt(a, b)); > printf("rephrased: 0x%08x\n", add_rephrased(a, b)); > } > > Should this be reported to the clang folks? Or is this to be expected when abusing integer overflows this way? You will get an answer that this is expected. Add -fwrapv compiler flag to make signed arithmetic behave in a way different from the mine-field, or remove the code. For kernel, we use -fwrapv. > > Also: The underlying problem is the fact that time_t is a 32 bit signed int. Any pointers as to a general method of resolving these time_t issues? > > Regards, > > Nick Hibma > nick@van-laarhoven.org > > -- Open Source: We stand on the shoulders of giants. > > > From owner-freebsd-current@freebsd.org Tue May 2 09:34:54 2017 Return-Path: Delivered-To: freebsd-current@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 31BB3D5A8E0 for ; Tue, 2 May 2017 09:34:54 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from valery.hibma.org (valery.hibma.org [IPv6:2a02:2308::216:3eff:fe79:3a6c]) by mx1.freebsd.org (Postfix) with ESMTP id F3CDB10F3 for ; Tue, 2 May 2017 09:34:53 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from [IPv6:2001:980:530a:1:f971:3b91:5cc3:9c3e] (unknown [IPv6:2001:980:530a:1:f971:3b91:5cc3:9c3e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by valery.hibma.org (Postfix) with ESMTPSA id DD4D16E0A15; Tue, 2 May 2017 11:34:45 +0200 (CEST) From: Nick Hibma Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_45DF1E72-342F-4E90-93F0-95CC15E5CDE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Compiler optimisation bug Date: Tue, 2 May 2017 11:34:45 +0200 In-Reply-To: <20170502083438.GA1622@kib.kiev.ua> Cc: FreeBSD Current Mailing List To: Konstantin Belousov References: <3626A28E-9DF5-4775-BAAB-CC6C36D2CD01@van-laarhoven.org> <20170502083438.GA1622@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 09:34:54 -0000 --Apple-Mail=_45DF1E72-342F-4E90-93F0-95CC15E5CDE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Should this be reported to the clang folks? Or is this to be expected = when abusing integer overflows this way? >=20 > You will get an answer that this is expected. Add -fwrapv compiler = flag > to make signed arithmetic behave in a way different from the = mine-field, > or remove the code. For kernel, we use -fwrapv. Thanks, that was what I expected. I searched for -fwrapv and found = similar comments. The code has been rewritten to not depend on overflow for its checks, so = it works properly with any sized time_t (assuming that it is an integer = though :). I'll commit it after feedback. Nick --Apple-Mail=_45DF1E72-342F-4E90-93F0-95CC15E5CDE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZCFK1AAoJEB9yHO7GNHbgAsMQAMwyWY9sYIVKv1rjV/MOisj6 4SZEh638XN5cN5d7XpgwlTqyFyVhcKgutIhI5EC2wvMB1cWRdeXkcI2QyZs1rlZU mhnJHPZBtspGYF9lzY9bU5yEnepVUsoqD5/ztDXNxWfzSJLPazVAksYUcBFMsq+d pKJn/xZIGOnB1rFvLScm5Z/+40cCp4c3UDGUuLLS1JFefllCrY4ydq91H1k91bm3 qd6ULuoEwfIb72NdJ2zaXzjrAvWWffnr9ZzC01JoovKmlKMJi3MKHzE1RR+gxv8x QHn8KK2gXbUjbCmfhUEtLUha58uBN/r0NAl/FoPksHM/Voaew3/w4ozL15VvdeAT M2MHoyHw4eBGBqArp/bITZhsJZtfceOYhaj9YywTYuQ13vVm7DPJDasMXU2z6Lu7 H6RW7RogO6jlxoBSy/ywIrjxkiqgRDJ23koT3PGy5H1KlQvEookICF14qs6ZxLjA VXntqfnt1NVAMmYK5vFae2dcdMrW0GGLzM4eV133N+O/gBBABBjAdk0+zcsoNJwp bDqaCXLiqrTPixjGBGn0yQbhnWw9zX2X7sXaD8KoHnoWtas4MbZzN3dVUpLRXL47 UuHyKsHXFbuwwIENFctXAwNnQYFXFJVSxoxeLmriUwYZrGKm4ghf5lq6lTCEFSNb 67HOdmHl8zS3AlioEKMl =2gg6 -----END PGP SIGNATURE----- --Apple-Mail=_45DF1E72-342F-4E90-93F0-95CC15E5CDE1-- From owner-freebsd-current@freebsd.org Tue May 2 09:53:51 2017 Return-Path: Delivered-To: freebsd-current@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 4DE6FD5AE2A for ; Tue, 2 May 2017 09:53:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 006001B1E for ; Tue, 2 May 2017 09:53:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26655 invoked from network); 2 May 2017 09:57:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 09:57:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 05:53:43 -0400 (EDT) Received: (qmail 24095 invoked from network); 2 May 2017 09:53:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 09:53:43 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C98FDEC7E18; Tue, 2 May 2017 02:53:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots] From: Mark Millard In-Reply-To: <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> Date: Tue, 2 May 2017 02:53:42 -0700 Cc: freebsd-arm , FreeBSD Current , Tom Vijlbrief , "O. Hartmann" Content-Transfer-Encoding: quoted-printable Message-Id: <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> To: Andrew Turner X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 09:53:51 -0000 On 2017-Apr-30, at 10:15 AM, Mark Millard wrote: > On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >=20 >>> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>> . . . >>=20 >> No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. >=20 > So you are expecting that the older QEMU_EFI.fd I had > used before provided some sort of fairly generic dtb > (relative to qemu, fairly independent of the host > that was running qemu). Interesting. Thanks again. > . . . > qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ > -bios QEMU_EFI.fd -nographic \ > -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ > -device virtio-blk-device,drive=3Dhd0 \ > -device virtio-net-device,netdev=3Dnet0 \ > -netdev user,id=3Dnet0 \ > -smp cpus=3D4 >=20 > based on: >=20 > = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd Using the following instead lead to booting all the way and being able to login: = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd So you were definitely correct. > but this time based on my build of head -r317015 . This combination seemed more stable than the one from back in 2016-Sept. I strongly expect that the official snapshot would boot based on this alternate QEMU_EFI.fd as well, but I've not tried that combination. The boot still gets: usb_needs_explore_all: no devclass during the boot but it does not hang after that message. I have not gotten networking going in FreeBSD in the quick try that I made. So I still do not have a /usr/src in place to try with a buildworld buildkernel . Here is a boot log: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 6 block devices.......*. done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0x79c13000 EFI version: 2.60 EFI Firmware: EDK II (rev 1.00) FreeBSD/arm64 EFI loader, Revision 1.1 EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7ba068 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] /boot/entropy size=3D0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x7ffdd000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 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 12.0-CURRENT r317015M arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 clk_fixed0: on ofwbus0 psci0: on ofwbus0 gic0: mem = 0x8000000-0x800ffff,0x8010000-0x801ffff on ofwbus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 288 gicv2m0: mem = 0x8020000-0x8020fff on gic0 generic_timer0: irq 34,35,36,37 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 virtio_mmio0: mem 0xa000000-0xa0001ff irq 0 on = ofwbus0 virtio_mmio1: mem 0xa000200-0xa0003ff irq 1 on = ofwbus0 virtio_mmio2: mem 0xa000400-0xa0005ff irq 2 on = ofwbus0 virtio_mmio3: mem 0xa000600-0xa0007ff irq 3 on = ofwbus0 virtio_mmio4: mem 0xa000800-0xa0009ff irq 4 on = ofwbus0 virtio_mmio5: mem 0xa000a00-0xa000bff irq 5 on = ofwbus0 virtio_mmio6: mem 0xa000c00-0xa000dff irq 6 on = ofwbus0 virtio_mmio7: mem 0xa000e00-0xa000fff irq 7 on = ofwbus0 virtio_mmio8: mem 0xa001000-0xa0011ff irq 8 on = ofwbus0 virtio_mmio9: mem 0xa001200-0xa0013ff irq 9 on = ofwbus0 virtio_mmio10: mem 0xa001400-0xa0015ff irq 10 on = ofwbus0 virtio_mmio11: mem 0xa001600-0xa0017ff irq 11 on = ofwbus0 virtio_mmio12: mem 0xa001800-0xa0019ff irq 12 on = ofwbus0 virtio_mmio13: mem 0xa001a00-0xa001bff irq 13 on = ofwbus0 virtio_mmio14: mem 0xa001c00-0xa001dff irq 14 on = ofwbus0 virtio_mmio15: mem 0xa001e00-0xa001fff irq 15 on = ofwbus0 virtio_mmio16: mem 0xa002000-0xa0021ff irq 16 on = ofwbus0 virtio_mmio17: mem 0xa002200-0xa0023ff irq 17 on = ofwbus0 virtio_mmio18: mem 0xa002400-0xa0025ff irq 18 on = ofwbus0 virtio_mmio19: mem 0xa002600-0xa0027ff irq 19 on = ofwbus0 virtio_mmio20: mem 0xa002800-0xa0029ff irq 20 on = ofwbus0 virtio_mmio21: mem 0xa002a00-0xa002bff irq 21 on = ofwbus0 virtio_mmio22: mem 0xa002c00-0xa002dff irq 22 on = ofwbus0 virtio_mmio23: mem 0xa002e00-0xa002fff irq 23 on = ofwbus0 virtio_mmio24: mem 0xa003000-0xa0031ff irq 24 on = ofwbus0 virtio_mmio25: mem 0xa003200-0xa0033ff irq 25 on = ofwbus0 virtio_mmio26: mem 0xa003400-0xa0035ff irq 26 on = ofwbus0 virtio_mmio27: mem 0xa003600-0xa0037ff irq 27 on = ofwbus0 virtio_mmio28: mem 0xa003800-0xa0039ff irq 28 on = ofwbus0 virtio_mmio29: mem 0xa003a00-0xa003bff irq 29 on = ofwbus0 virtio_mmio30: mem 0xa003c00-0xa003dff irq 30 on = ofwbus0 vtnet0: on virtio_mmio30 vtnet0: Ethernet address: 52:54:00:12:34:56 virtio_mmio31: mem 0xa003e00-0xa003fff irq 31 on = ofwbus0 vtblk0: on virtio_mmio31 vtblk0: 32768MB (67110465 512 byte sectors) pcib0: mem 0x3f000000-0x3fffffff on = ofwbus0 pci0: on pcib0 uart0: mem 0x9000000-0x9000fff irq 33 on = ofwbus0 uart0: console (9600,n,8,1) cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cryptosoft0: Timecounters tick every 10.000 msec usb_needs_explore_all: no devclass Release APs CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set = accurately Setting hostuuid: 5f6ed2d1-2dcc-11e7-b81e-f171534e5634. Setting hostid: 0x9f2fff5d. Starting file system checks: /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 6154717 free (4485 frags, 768779 blocks, 0.1% = fragmentation) Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat Setting hostname: ODC2FBSD. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . Starting Network: lo0 vtnet0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 vtnet0: flags=3D8802 metric 0 mtu 1500 options=3D80028 ether 52:54:00:12:34:56 media: Ethernet 10Gbase-T status: active nd6 options=3D29 Starting devd. Starting Network: vtnet0. vtnet0: flags=3D8802 metric 0 mtu 1500 options=3D80028 ether 52:54:00:12:34:56 media: Ethernet 10Gbase-T status: active nd6 options=3D29 add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Sun Apr 30 18:41:18 UTC 2017 FreeBSD/arm64 (ODC2FBSD) (ttyu0) login:=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 2 10:37:11 2017 Return-Path: Delivered-To: freebsd-current@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 C690DD57E98 for ; Tue, 2 May 2017 10:37:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 84688ABF for ; Tue, 2 May 2017 10:37:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8439 invoked from network); 2 May 2017 10:37:04 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 10:37:04 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 06:37:04 -0400 (EDT) Received: (qmail 6270 invoked from network); 2 May 2017 10:37:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 10:37:04 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 95795EC7D48; Tue, 2 May 2017 03:37:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots] From: Mark Millard In-Reply-To: <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> Date: Tue, 2 May 2017 03:37:03 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:37:11 -0000 On 2017-May-2, at 2:53 AM, Mark Millard wrote: > On 2017-Apr-30, at 10:15 AM, Mark Millard wrote: >=20 >> On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >>=20 >>>> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>>> . . . >>>=20 >>> No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. >>=20 >> So you are expecting that the older QEMU_EFI.fd I had >> used before provided some sort of fairly generic dtb >> (relative to qemu, fairly independent of the host >> that was running qemu). Interesting. Thanks again. >> . . . >> qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ >> -bios QEMU_EFI.fd -nographic \ >> -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ >> -device virtio-blk-device,drive=3Dhd0 \ >> -device virtio-net-device,netdev=3Dnet0 \ >> -netdev user,id=3Dnet0 \ >> -smp cpus=3D4 >>=20 >> based on: >>=20 >> = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd >=20 > Using the following instead lead to booting > all the way and being able to login: >=20 > = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd >=20 > So you were definitely correct. >=20 >> but this time based on my build of head -r317015 . >=20 > This combination seemed more stable than the one > from back in 2016-Sept. >=20 > I strongly expect that the official snapshot would > boot based on this alternate QEMU_EFI.fd as well, > but I've not tried that combination. >=20 > The boot still gets: >=20 > usb_needs_explore_all: no devclass >=20 > during the boot but it does not hang after > that message. >=20 > I have not gotten networking going in > FreeBSD in the quick try that I made. >=20 > So I still do not have a /usr/src in place > to try with a buildworld buildkernel . >=20 > Here is a boot log: >=20 >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 6 block devices.......*. done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console =20 > Command line arguments: loader.efi > Image base: 0x79c13000 > EFI version: 2.60 > EFI Firmware: EDK II (rev 1.00) >=20 > FreeBSD/arm64 EFI loader, Revision 1.1 > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x7ba068 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] > /boot/entropy size=3D0x1000 >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x7ffdd000. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 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 12.0-CURRENT r317015M arm64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) > VT: init without driver. > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on ofwbus0 > clk_fixed0: on ofwbus0 > psci0: on ofwbus0 > gic0: mem = 0x8000000-0x800ffff,0x8010000-0x801ffff on ofwbus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 288 > gicv2m0: mem = 0x8020000-0x8020fff on gic0 > generic_timer0: irq 34,35,36,37 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > virtio_mmio0: mem 0xa000000-0xa0001ff irq 0 on = ofwbus0 > virtio_mmio1: mem 0xa000200-0xa0003ff irq 1 on = ofwbus0 > virtio_mmio2: mem 0xa000400-0xa0005ff irq 2 on = ofwbus0 > virtio_mmio3: mem 0xa000600-0xa0007ff irq 3 on = ofwbus0 > virtio_mmio4: mem 0xa000800-0xa0009ff irq 4 on = ofwbus0 > virtio_mmio5: mem 0xa000a00-0xa000bff irq 5 on = ofwbus0 > virtio_mmio6: mem 0xa000c00-0xa000dff irq 6 on = ofwbus0 > virtio_mmio7: mem 0xa000e00-0xa000fff irq 7 on = ofwbus0 > virtio_mmio8: mem 0xa001000-0xa0011ff irq 8 on = ofwbus0 > virtio_mmio9: mem 0xa001200-0xa0013ff irq 9 on = ofwbus0 > virtio_mmio10: mem 0xa001400-0xa0015ff irq 10 on = ofwbus0 > virtio_mmio11: mem 0xa001600-0xa0017ff irq 11 on = ofwbus0 > virtio_mmio12: mem 0xa001800-0xa0019ff irq 12 on = ofwbus0 > virtio_mmio13: mem 0xa001a00-0xa001bff irq 13 on = ofwbus0 > virtio_mmio14: mem 0xa001c00-0xa001dff irq 14 on = ofwbus0 > virtio_mmio15: mem 0xa001e00-0xa001fff irq 15 on = ofwbus0 > virtio_mmio16: mem 0xa002000-0xa0021ff irq 16 on = ofwbus0 > virtio_mmio17: mem 0xa002200-0xa0023ff irq 17 on = ofwbus0 > virtio_mmio18: mem 0xa002400-0xa0025ff irq 18 on = ofwbus0 > virtio_mmio19: mem 0xa002600-0xa0027ff irq 19 on = ofwbus0 > virtio_mmio20: mem 0xa002800-0xa0029ff irq 20 on = ofwbus0 > virtio_mmio21: mem 0xa002a00-0xa002bff irq 21 on = ofwbus0 > virtio_mmio22: mem 0xa002c00-0xa002dff irq 22 on = ofwbus0 > virtio_mmio23: mem 0xa002e00-0xa002fff irq 23 on = ofwbus0 > virtio_mmio24: mem 0xa003000-0xa0031ff irq 24 on = ofwbus0 > virtio_mmio25: mem 0xa003200-0xa0033ff irq 25 on = ofwbus0 > virtio_mmio26: mem 0xa003400-0xa0035ff irq 26 on = ofwbus0 > virtio_mmio27: mem 0xa003600-0xa0037ff irq 27 on = ofwbus0 > virtio_mmio28: mem 0xa003800-0xa0039ff irq 28 on = ofwbus0 > virtio_mmio29: mem 0xa003a00-0xa003bff irq 29 on = ofwbus0 > virtio_mmio30: mem 0xa003c00-0xa003dff irq 30 on = ofwbus0 > vtnet0: on virtio_mmio30 > vtnet0: Ethernet address: 52:54:00:12:34:56 > virtio_mmio31: mem 0xa003e00-0xa003fff irq 31 on = ofwbus0 > vtblk0: on virtio_mmio31 > vtblk0: 32768MB (67110465 512 byte sectors) > pcib0: mem 0x3f000000-0x3fffffff on = ofwbus0 > pci0: on pcib0 > uart0: mem 0x9000000-0x9000fff irq 33 on = ofwbus0 > uart0: console (9600,n,8,1) > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > cryptosoft0: > Timecounters tick every 10.000 msec > usb_needs_explore_all: no devclass > Release APs > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <0> > Processor Features 0 =3D > Processor Features 1 =3D <0> > Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> > Memory Model Features 1 =3D <> > Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> > Debug Features 1 =3D <0> > Auxiliary Features 0 =3D <0> > Auxiliary Features 1 =3D <0> > CPU 1: ARM Cortex-A53 r0p4 affinity: 1 > CPU 2: ARM Cortex-A53 r0p4 affinity: 2 > CPU 3: ARM Cortex-A53 r0p4 affinity: 3 > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > warning: no time-of-day clock registered, system time will not be set = accurately > Setting hostuuid: 5f6ed2d1-2dcc-11e7-b81e-f171534e5634. > Setting hostid: 0x9f2fff5d. > Starting file system checks: > /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/ufs/rootfs: clean, 6154717 free (4485 frags, 768779 blocks, 0.1% = fragmentation) > Mounting local filesystems:. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat > Setting hostname: ODC2FBSD. > Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED > Feeding entropy: . > Starting Network: lo0 vtnet0. > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 > inet 127.0.0.1 netmask 0xff000000=20 > groups: lo=20 > nd6 options=3D21 > vtnet0: flags=3D8802 metric 0 mtu 1500 > options=3D80028 > ether 52:54:00:12:34:56 > media: Ethernet 10Gbase-T > status: active > nd6 options=3D29 > Starting devd. > Starting Network: vtnet0. > vtnet0: flags=3D8802 metric 0 mtu 1500 > options=3D80028 > ether 52:54:00:12:34:56 > media: Ethernet 10Gbase-T > status: active > nd6 options=3D29 > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Creating and/or trimming log files. > Starting syslogd. > No core dumps found. > Clearing /tmp (X related). > Updating motd:. > Mounting late filesystems:. > Starting sendmail_submit. > Starting sendmail_msp_queue. > Starting cron. > Starting background file system checks in 60 seconds. >=20 > Sun Apr 30 18:41:18 UTC 2017 >=20 > FreeBSD/arm64 (ODC2FBSD) (ttyu0) >=20 > login:=20 FYI: I do sometimes get things like: System shutdown time has arrived Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock KDB: stack backtrace of thread 100093: sched_switch() at mi_switch+0x100 pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 mi_switch() at sleepq_wait+0x3c pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 sleepq_wait() at _sleep+0x29c pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 _sleep() at vm_page_sleep_if_busy+0xb0 pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 handle_el1h_sync() at pmap_enter+0x678 pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 pmap_enter() at vm_fault_hold+0x17c0 pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 handle_el1h_sync() at pmap_remove_pages+0x2a8 pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 pmap_remove_pages() at vmspace_exit+0xb0 pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 vmspace_exit() at exit1+0x604 pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 exit1() at sys_sys_exit+0x10 pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 sys_sys_exit() at do_el0_sync+0xa48 pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 do_el0_sync() at handle_el0_sync+0x6c pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 handle_el0_sync() at 0x38cc0 pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 panic: sleeping thread cpuid =3D 2 time =3D 1493581440 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 vpanic() at panic+0x4c pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 panic() at propagate_priority+0x2d0 pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 propagate_priority() at turnstile_wait+0x340 pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 turnstile_wait() at __rw_wlock_hard+0x208 pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 __rw_wlock_hard() at pmap_enter+0xe98 pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 pmap_enter() at vm_fault_hold+0x28c pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 data_abort() at handle_el0_sync+0x6c pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 handle_el0_sync() at 0x40040070 pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 KDB: enter: panic [ thread pid 709 tid 100086 ] Stopped at kdb_enter+0x44: undefined d4200000 db> =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 2 12:24:27 2017 Return-Path: Delivered-To: freebsd-current@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 8A486D5AEC0 for ; Tue, 2 May 2017 12:24:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 4948012E0 for ; Tue, 2 May 2017 12:24:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15158 invoked from network); 2 May 2017 12:24:25 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 12:24:25 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 08:24:25 -0400 (EDT) Received: (qmail 15998 invoked from network); 2 May 2017 12:24:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 12:24:24 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1DAEEEC7D48; Tue, 2 May 2017 05:24:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 05:24:23 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> To: freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:24:27 -0000 On 2017-May-2, at 3:37 AM, Mark Millard wrote: > On 2017-May-2, at 2:53 AM, Mark Millard wrote: >=20 >> On 2017-Apr-30, at 10:15 AM, Mark Millard = wrote: >>=20 >>> On 2017-Apr-30, at 9:40 AM, Andrew Turner = wrote: >>>=20 >>>>> On 30 Apr 2017, at 12:02, Mark Millard = wrote: >>>>> . . . >>>>=20 >>>> No, the device tree blob comes from UEFI. It seems the current UEFI = only provides the ACPI tables, and not a DTB. >>>=20 >>> So you are expecting that the older QEMU_EFI.fd I had >>> used before provided some sort of fairly generic dtb >>> (relative to qemu, fairly independent of the host >>> that was running qemu). Interesting. Thanks again. >>> . . . >>> qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \ >>> -bios QEMU_EFI.fd -nographic \ >>> -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64-20170420-= r317181.raw,id=3Dhd0 \ >>> -device virtio-blk-device,drive=3Dhd0 \ >>> -device virtio-net-device,netdev=3Dnet0 \ >>> -netdev user,id=3Dnet0 \ >>> -smp cpus=3D4 >>>=20 >>> based on: >>>=20 >>> = http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upst= ream/1917/QEMU-AARCH64/RELEASE_CLANG35/QEMU_EFI.fd >>=20 >> Using the following instead lead to booting >> all the way and being able to login: >>=20 >> = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd >>=20 >> So you were definitely correct. >>=20 >>> but this time based on my build of head -r317015 . >>=20 >> This combination seemed more stable than the one >> from back in 2016-Sept. >>=20 >> I strongly expect that the official snapshot would >> boot based on this alternate QEMU_EFI.fd as well, >> but I've not tried that combination. >>=20 >> The boot still gets: >>=20 >> usb_needs_explore_all: no devclass >>=20 >> during the boot but it does not hang after >> that message. >>=20 >> I have not gotten networking going in >> FreeBSD in the quick try that I made. >>=20 >> So I still do not have a /usr/src in place >> to try with a buildworld buildkernel . >>=20 >> Here is a boot log: >>=20 >>=20 >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >>=20 >> Initializing modules: ZFS UFS >> Probing 6 block devices.......*. done >> ZFS found no pools >> UFS found 1 partition >> Consoles: EFI console =20 >> Command line arguments: loader.efi >> Image base: 0x79c13000 >> EFI version: 2.60 >> EFI Firmware: EDK II (rev 1.00) >>=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >> EFI boot environment >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x7ba068 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] >> /boot/entropy size=3D0x1000 >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... =20 >> Using DTB provided by EFI at 0x7ffdd000. >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2017 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 12.0-CURRENT r317015M arm64 >> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) >> VT: init without driver. >> Starting CPU 1 (1) >> Starting CPU 2 (2) >> Starting CPU 3 (3) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: unblocking device. >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0: >> simplebus0: on ofwbus0 >> clk_fixed0: on ofwbus0 >> psci0: on ofwbus0 >> gic0: mem = 0x8000000-0x800ffff,0x8010000-0x801ffff on ofwbus0 >> gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 288 >> gicv2m0: mem = 0x8020000-0x8020fff on gic0 >> generic_timer0: irq 34,35,36,37 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 >> Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality = 1000 >> virtio_mmio0: mem 0xa000000-0xa0001ff irq 0 on = ofwbus0 >> virtio_mmio1: mem 0xa000200-0xa0003ff irq 1 on = ofwbus0 >> virtio_mmio2: mem 0xa000400-0xa0005ff irq 2 on = ofwbus0 >> virtio_mmio3: mem 0xa000600-0xa0007ff irq 3 on = ofwbus0 >> virtio_mmio4: mem 0xa000800-0xa0009ff irq 4 on = ofwbus0 >> virtio_mmio5: mem 0xa000a00-0xa000bff irq 5 on = ofwbus0 >> virtio_mmio6: mem 0xa000c00-0xa000dff irq 6 on = ofwbus0 >> virtio_mmio7: mem 0xa000e00-0xa000fff irq 7 on = ofwbus0 >> virtio_mmio8: mem 0xa001000-0xa0011ff irq 8 on = ofwbus0 >> virtio_mmio9: mem 0xa001200-0xa0013ff irq 9 on = ofwbus0 >> virtio_mmio10: mem 0xa001400-0xa0015ff irq 10 = on ofwbus0 >> virtio_mmio11: mem 0xa001600-0xa0017ff irq 11 = on ofwbus0 >> virtio_mmio12: mem 0xa001800-0xa0019ff irq 12 = on ofwbus0 >> virtio_mmio13: mem 0xa001a00-0xa001bff irq 13 = on ofwbus0 >> virtio_mmio14: mem 0xa001c00-0xa001dff irq 14 = on ofwbus0 >> virtio_mmio15: mem 0xa001e00-0xa001fff irq 15 = on ofwbus0 >> virtio_mmio16: mem 0xa002000-0xa0021ff irq 16 = on ofwbus0 >> virtio_mmio17: mem 0xa002200-0xa0023ff irq 17 = on ofwbus0 >> virtio_mmio18: mem 0xa002400-0xa0025ff irq 18 = on ofwbus0 >> virtio_mmio19: mem 0xa002600-0xa0027ff irq 19 = on ofwbus0 >> virtio_mmio20: mem 0xa002800-0xa0029ff irq 20 = on ofwbus0 >> virtio_mmio21: mem 0xa002a00-0xa002bff irq 21 = on ofwbus0 >> virtio_mmio22: mem 0xa002c00-0xa002dff irq 22 = on ofwbus0 >> virtio_mmio23: mem 0xa002e00-0xa002fff irq 23 = on ofwbus0 >> virtio_mmio24: mem 0xa003000-0xa0031ff irq 24 = on ofwbus0 >> virtio_mmio25: mem 0xa003200-0xa0033ff irq 25 = on ofwbus0 >> virtio_mmio26: mem 0xa003400-0xa0035ff irq 26 = on ofwbus0 >> virtio_mmio27: mem 0xa003600-0xa0037ff irq 27 = on ofwbus0 >> virtio_mmio28: mem 0xa003800-0xa0039ff irq 28 = on ofwbus0 >> virtio_mmio29: mem 0xa003a00-0xa003bff irq 29 = on ofwbus0 >> virtio_mmio30: mem 0xa003c00-0xa003dff irq 30 = on ofwbus0 >> vtnet0: on virtio_mmio30 >> vtnet0: Ethernet address: 52:54:00:12:34:56 >> virtio_mmio31: mem 0xa003e00-0xa003fff irq 31 = on ofwbus0 >> vtblk0: on virtio_mmio31 >> vtblk0: 32768MB (67110465 512 byte sectors) >> pcib0: mem 0x3f000000-0x3fffffff on = ofwbus0 >> pci0: on pcib0 >> uart0: mem 0x9000000-0x9000fff irq 33 on = ofwbus0 >> uart0: console (9600,n,8,1) >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu1: on cpulist0 >> cpu2: on cpulist0 >> cpu3: on cpulist0 >> cryptosoft0: >> Timecounters tick every 10.000 msec >> usb_needs_explore_all: no devclass >> Release APs >> CPU 0: ARM Cortex-A53 r0p4 affinity: 0 >> Instruction Set Attributes 0 =3D >> Instruction Set Attributes 1 =3D <0> >> Processor Features 0 =3D >> Processor Features 1 =3D <0> >> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> >> Memory Model Features 1 =3D <> >> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> >> Debug Features 1 =3D <0> >> Auxiliary Features 0 =3D <0> >> Auxiliary Features 1 =3D <0> >> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 >> CPU 2: ARM Cortex-A53 r0p4 affinity: 2 >> CPU 3: ARM Cortex-A53 r0p4 affinity: 3 >> Trying to mount root from ufs:/dev/ufs/rootfs [rw]... >> warning: no time-of-day clock registered, system time will not be set = accurately >> Setting hostuuid: 5f6ed2d1-2dcc-11e7-b81e-f171534e5634. >> Setting hostid: 0x9f2fff5d. >> Starting file system checks: >> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/ufs/rootfs: clean, 6154717 free (4485 frags, 768779 blocks, 0.1% = fragmentation) >> Mounting local filesystems:. >> ELF ldconfig path: /lib /usr/lib /usr/lib/compat >> Setting hostname: ODC2FBSD. >> Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED >> Feeding entropy: . >> Starting Network: lo0 vtnet0. >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D600003 >> inet6 ::1 prefixlen 128=20 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 >> inet 127.0.0.1 netmask 0xff000000=20 >> groups: lo=20 >> nd6 options=3D21 >> vtnet0: flags=3D8802 metric 0 mtu 1500 >> options=3D80028 >> ether 52:54:00:12:34:56 >> media: Ethernet 10Gbase-T >> status: active >> nd6 options=3D29 >> Starting devd. >> Starting Network: vtnet0. >> vtnet0: flags=3D8802 metric 0 mtu 1500 >> options=3D80028 >> ether 52:54:00:12:34:56 >> media: Ethernet 10Gbase-T >> status: active >> nd6 options=3D29 >> add host 127.0.0.1: gateway lo0 fib 0: route already in table >> add host ::1: gateway lo0 fib 0: route already in table >> add net fe80::: gateway ::1 >> add net ff02::: gateway ::1 >> add net ::ffff:0.0.0.0: gateway ::1 >> add net ::0.0.0.0: gateway ::1 >> Creating and/or trimming log files. >> Starting syslogd. >> No core dumps found. >> Clearing /tmp (X related). >> Updating motd:. >> Mounting late filesystems:. >> Starting sendmail_submit. >> Starting sendmail_msp_queue. >> Starting cron. >> Starting background file system checks in 60 seconds. >>=20 >> Sun Apr 30 18:41:18 UTC 2017 >>=20 >> FreeBSD/arm64 (ODC2FBSD) (ttyu0) >>=20 >> login:=20 >=20 > FYI: >=20 > I do sometimes get things like: >=20 >=20 > System shutdown time has arrived > Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 > Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock > KDB: stack backtrace of thread 100093: > sched_switch() at mi_switch+0x100 > pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 > sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >=20 > mi_switch() at sleepq_wait+0x3c > pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 > sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >=20 > sleepq_wait() at _sleep+0x29c > pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c > sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >=20 > _sleep() at vm_page_sleep_if_busy+0xb0 > pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 > sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >=20 > vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 > pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c > sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 > sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >=20 > data_abort() at handle_el1h_sync+0x70 > pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 > sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >=20 > handle_el1h_sync() at pmap_enter+0x678 > pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 > sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >=20 > pmap_enter() at vm_fault_hold+0x17c0 > pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 > sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >=20 > data_abort() at handle_el1h_sync+0x70 > pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 > sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >=20 > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 > sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >=20 > pmap_remove_pages() at vmspace_exit+0xb0 > pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c > sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >=20 > vmspace_exit() at exit1+0x604 > pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 > sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >=20 > exit1() at sys_sys_exit+0x10 > pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 > sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >=20 > sys_sys_exit() at do_el0_sync+0xa48 > pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c > sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >=20 > do_el0_sync() at handle_el0_sync+0x6c > pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 > sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >=20 > handle_el0_sync() at 0x38cc0 > pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 > sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >=20 > panic: sleeping thread > cpuid =3D 2 > time =3D 1493581440 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >=20 > panic() at propagate_priority+0x2d0 > pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 > sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >=20 > propagate_priority() at turnstile_wait+0x340 > pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c > sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >=20 > turnstile_wait() at __rw_wlock_hard+0x208 > pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 > sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >=20 > __rw_wlock_hard() at pmap_enter+0xe98 > pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 > sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >=20 > data_abort() at handle_el0_sync+0x6c > pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 > sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >=20 > handle_el0_sync() at 0x40040070 > pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 > sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >=20 > KDB: enter: panic > [ thread pid 709 tid 100086 ] > Stopped at kdb_enter+0x44: undefined d4200000 > db> Another example failure is: Fatal data abort: x0: 400a9000 x1: 1000 x2: 0 x3: 40 x4: 3f x5: fffffd00304e5000 x6: 2b52 x7: c x8: b x9: fffffd000076d5d0 x10: 68 x11: 40000000 x12: 704c5000 x13: 42b42003 x14: 42b42003 x15: 40000000 x16: c x17: ffffffffffffffff x18: ffff000065dd5310 x19: 800000000000000 x20: 1 x21: fffffd0002b43000 x22: 12000004556478b x23: f000000000000000 x24: fffffd0002b41bc8 x25: 40 x26: fffffd0002b42548 x27: 7b x28: 3 x29: ffff000065dd53c0 sp: ffff000065dd5310 lr: ffff0000006175d8 elr: ffff00000060589c spsr: 60000345 far: 400a9000 esr: 96000147 [ thread pid 715 tid 100078 ] Stopped at arm64_dcache_wb_range+0x18: undefined d50b7a20 db> bt Tracing pid 715 tid 100078 td 0xfffffd00007849c0 db_trace_self() at db_stack_trace+0xf0 pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 db_stack_trace() at db_command+0x23c pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 db_command() at db_command_loop+0x60 pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 db_command_loop() at db_trap+0xf4 pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 db_trap() at kdb_trap+0x180 pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 =20 kdb_trap() at data_abort+0x1a0 pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 handle_el1h_sync() at pmap_remove_pages+0x2a8 pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 pmap_remove_pages() at exec_new_vmspace+0x1a4 pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 exec_new_vmspace() at exec_elf64_imgact+0xa70 pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 =20 exec_elf64_imgact() at kern_execve+0x664 pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 kern_execve() at sys_execve+0x54 pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 sys_execve() at do_el0_sync+0xa48 pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 do_el0_sync() at handle_el0_sync+0x6c pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 handle_el0_sync() at 0x24a90 pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 =20 db>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 2 17:49:30 2017 Return-Path: Delivered-To: freebsd-current@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 24793D5B260 for ; Tue, 2 May 2017 17:49:30 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DF0C17DC for ; Tue, 2 May 2017 17:49:29 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.135.177] (nat-192-187-90-116.nat.tribpub.com [192.187.90.116]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 8277d048 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Tue, 2 May 2017 10:49:28 -0700 (PDT) Subject: Re: regression suspend/resume on Lenovo T420 To: freebsd-current@freebsd.org References: <20170429115017.GA98553@freebsd-t420.fritz.box> From: Pete Wright Message-ID: Date: Tue, 2 May 2017 10:49:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:49:30 -0000 On 05/01/2017 14:31, Adrian Chadd wrote: > There were lots of commits that could break things. :-) > > > Can you compile up some intermediary versions between 315141 and > r317559 to find which commit range broke things? That'll make chasing > it down much quicker! > > Thanks! FWIW I'm seeing this on the drm-next repository after the latest merge from upstream which happened on April 30th. I'll try to put some cycles into trying to find a range of potential commits that is causing this. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Tue May 2 19:23:54 2017 Return-Path: Delivered-To: freebsd-current@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 03901D5B30B for ; Tue, 2 May 2017 19:23:54 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E257B191D for ; Tue, 2 May 2017 19:23:53 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id E1B8FD5B30A; Tue, 2 May 2017 19:23:53 +0000 (UTC) Delivered-To: current@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 E163CD5B309 for ; Tue, 2 May 2017 19:23:53 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 A9314191C for ; Tue, 2 May 2017 19:23:52 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v42JFV0I010329 for ; Tue, 2 May 2017 15:15:31 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v42JFVdO010328 for current@freebsd.org; Tue, 2 May 2017 15:15:31 -0400 (EDT) (envelope-from mwlucas) Date: Tue, 2 May 2017 15:15:31 -0400 From: "Michael W. Lucas" To: current@freebsd.org Subject: old snapshot install images? Message-ID: <20170502191531.GA10288@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Tue, 02 May 2017 15:15:32 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 19:23:54 -0000 Hi, About a year ago, I did a clean install on my desktop. No problems. I tried a clean install now, and it dies with: gtpzfsboot: error 1 lba 32 error 1 gptzfsboot: error 1 lba 4294967288 gptzfsboot: error 1 lba 1 gptzfsboot: no ZFS pools located, can't boot The pool is visible in the live CD, and I can import it. I want to file a PR. The sensible thing for me to do is to use old snapshot installers to determine when this machine could no longer install. Unfortunately, the FTP servers only keep a month or so of snapshots. ftp-archive doesn't have the old snapshots. Does anyone have an archive of -current install media, either CD or ISO? I need to get this box back fairly quickly, but I don't mind burning a couple days to nail it down. Thanks, ==ml -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Tue May 2 21:29:08 2017 Return-Path: Delivered-To: freebsd-current@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 DF913D5A670 for ; Tue, 2 May 2017 21:29:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 9E64E17E7 for ; Tue, 2 May 2017 21:29:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18929 invoked from network); 2 May 2017 21:22:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 May 2017 21:22:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 17:22:27 -0400 (EDT) Received: (qmail 13728 invoked from network); 2 May 2017 21:22:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 21:22:26 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 11BC0EC7A6F; Tue, 2 May 2017 14:22:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 14:22:25 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: 7bit Message-Id: <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> To: freebsd-arm , FreeBSD Current , Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:29:09 -0000 It turns out that the bt's from the example panics are repeatable for the pc and lr sequence involved (but not the specific sp's and fp's involved). I report this in case it suggests anything. I'll note that the build had a production style kernel for a build of -r317015 . The first type of panic actually a back to back sequence of two bt's, this is the sleeping-thread type pf example. The second type is just one bt by itself. There is one variable lr in the bt for the sleeping-thread type of example (the first type of panic of the two shown later, the one with back-to-back bt's): 131,133c131,133 < handle_el0_sync() at 0x40040070 < pc = 0xffff0000006079e8 lr = 0x0000000040040070 < sp = 0xffff000065dfdba0 fp = 0x0000ffffffffeb00 --- > handle_el0_sync() at 0x40044490 > pc = 0xffff0000006079e8 lr = 0x0000000040044490 > sp = 0xffff000040229ba0 fp = 0x0000ffffffffe3d0 Otherwise the two bt's in the example match for the pc/lr sequence. I only have the two examples of this type to compare so far (one diff). I have 3 examples of the second type and they had no such variation. One thing in common to all 5 of these examples is the sequence: data_abort() at handle_el1h_sync+0x70 lr = 0xffff000000607870 handle_el1h_sync() at pmap_remove_pages+0x2a8 pc = 0xffff000000607870 lr = 0xffff0000006175d4 pmap_remove_pages() being involved in each example. I'm not saying that I can cause any panics at will, but when either of the two types happen the bt is (mostly) stable for the pc and lr sequence and that short sequence above is involved. I have seen one other type of panic but I did not manage to record a bt for it yet. It involved the instruction cache instead of arm64_dcache_wb_range . I quote the prior reported example bt's below. On 2017-May-2, at 5:24 AM, Mark Millard wrote: > On 2017-May-2, at 3:37 AM, Mark Millard wrote: > >> On 2017-May-2, at 2:53 AM, Mark Millard wrote: >> >> . . . >> FYI: >> >> I do sometimes get things like: >> >> >> System shutdown time has arrived >> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root: >> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >> KDB: stack backtrace of thread 100093: >> sched_switch() at mi_switch+0x100 >> pc = 0xffff000000347d44 lr = 0xffff000000327358 >> sp = 0xffff000040237e00 fp = 0xffff000040237e20 >> >> mi_switch() at sleepq_wait+0x3c >> pc = 0xffff000000327358 lr = 0xffff00000036c174 >> sp = 0xffff000040237e30 fp = 0xffff000040237e50 >> >> sleepq_wait() at _sleep+0x29c >> pc = 0xffff00000036c174 lr = 0xffff000000326c7c >> sp = 0xffff000040237e60 fp = 0xffff000040237ee0 >> >> _sleep() at vm_page_sleep_if_busy+0xb0 >> pc = 0xffff000000326c7c lr = 0xffff0000005cfcf4 >> sp = 0xffff000040237ef0 fp = 0xffff000040237f10 >> >> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >> pc = 0xffff0000005cfcf4 lr = 0xffff0000005ba17c >> sp = 0xffff000040237f20 fp = 0xffff000040238070 >> >> vm_fault_hold() at vm_fault+0x70 >> pc = 0xffff0000005ba17c lr = 0xffff0000005b9464 >> sp = 0xffff000040238080 fp = 0xffff0000402380b0 >> >> vm_fault() at data_abort+0xe0 >> pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 >> sp = 0xffff0000402380c0 fp = 0xffff000040238170 >> >> data_abort() at handle_el1h_sync+0x70 >> pc = 0xffff00000061ad94 lr = 0xffff000000607870 >> sp = 0xffff000040238180 fp = 0xffff000040238290 >> >> handle_el1h_sync() at pmap_enter+0x678 >> pc = 0xffff000000607870 lr = 0xffff000000615684 >> sp = 0xffff0000402382a0 fp = 0xffff0000402383b0 >> >> pmap_enter() at vm_fault_hold+0x17c0 >> pc = 0xffff000000615684 lr = 0xffff0000005bac74 >> sp = 0xffff0000402383c0 fp = 0xffff000040238510 >> >> vm_fault_hold() at vm_fault+0x70 >> pc = 0xffff0000005bac74 lr = 0xffff0000005b9464 >> sp = 0xffff000040238520 fp = 0xffff000040238550 >> >> vm_fault() at data_abort+0xe0 >> pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 >> sp = 0xffff000040238560 fp = 0xffff000040238610 >> >> data_abort() at handle_el1h_sync+0x70 >> pc = 0xffff00000061ad94 lr = 0xffff000000607870 >> sp = 0xffff000040238620 fp = 0xffff000040238730 >> >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc = 0xffff000000607870 lr = 0xffff0000006175d4 >> sp = 0xffff000040238740 fp = 0xffff000040238870 >> >> pmap_remove_pages() at vmspace_exit+0xb0 >> pc = 0xffff0000006175d4 lr = 0xffff0000005c020c >> sp = 0xffff000040238880 fp = 0xffff0000402388b0 >> >> vmspace_exit() at exit1+0x604 >> pc = 0xffff0000005c020c lr = 0xffff0000002db5e0 >> sp = 0xffff0000402388c0 fp = 0xffff000040238920 >> >> exit1() at sys_sys_exit+0x10 >> pc = 0xffff0000002db5e0 lr = 0xffff0000002dafd8 >> sp = 0xffff000040238930 fp = 0xffff000040238930 >> >> sys_sys_exit() at do_el0_sync+0xa48 >> pc = 0xffff0000002dafd8 lr = 0xffff00000061b91c >> sp = 0xffff000040238940 fp = 0xffff000040238a70 >> >> do_el0_sync() at handle_el0_sync+0x6c >> pc = 0xffff00000061b91c lr = 0xffff0000006079e8 >> sp = 0xffff000040238a80 fp = 0xffff000040238b90 >> >> handle_el0_sync() at 0x38cc0 >> pc = 0xffff0000006079e8 lr = 0x0000000000038cc0 >> sp = 0xffff000040238ba0 fp = 0x0000ffffffffed00 >> >> panic: sleeping thread >> cpuid = 2 >> time = 1493581440 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc = 0xffff000000605cc0 lr = 0xffff0000000869cc >> sp = 0xffff000065dfd320 fp = 0xffff000065dfd530 >> >> db_trace_self_wrapper() at vpanic+0x164 >> pc = 0xffff0000000869cc lr = 0xffff00000031d464 >> sp = 0xffff000065dfd540 fp = 0xffff000065dfd5b0 >> >> vpanic() at panic+0x4c >> pc = 0xffff00000031d464 lr = 0xffff00000031d2fc >> sp = 0xffff000065dfd5c0 fp = 0xffff000065dfd640 >> >> panic() at propagate_priority+0x2d0 >> pc = 0xffff00000031d2fc lr = 0xffff000000374558 >> sp = 0xffff000065dfd650 fp = 0xffff000065dfd690 >> >> propagate_priority() at turnstile_wait+0x340 >> pc = 0xffff000000374558 lr = 0xffff00000037503c >> sp = 0xffff000065dfd6a0 fp = 0xffff000065dfd6e0 >> >> turnstile_wait() at __rw_wlock_hard+0x208 >> pc = 0xffff00000037503c lr = 0xffff000000319138 >> sp = 0xffff000065dfd6f0 fp = 0xffff000065dfd770 >> >> __rw_wlock_hard() at pmap_enter+0xe98 >> pc = 0xffff000000319138 lr = 0xffff000000615ea4 >> sp = 0xffff000065dfd780 fp = 0xffff000065dfd810 >> >> pmap_enter() at vm_fault_hold+0x28c >> pc = 0xffff000000615ea4 lr = 0xffff0000005b9740 >> sp = 0xffff000065dfd820 fp = 0xffff000065dfd970 >> >> vm_fault_hold() at vm_fault+0x70 >> pc = 0xffff0000005b9740 lr = 0xffff0000005b9464 >> sp = 0xffff000065dfd980 fp = 0xffff000065dfd9b0 >> >> vm_fault() at data_abort+0xe0 >> pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 >> sp = 0xffff000065dfd9c0 fp = 0xffff000065dfda70 >> >> data_abort() at handle_el0_sync+0x6c >> pc = 0xffff00000061ad94 lr = 0xffff0000006079e8 >> sp = 0xffff000065dfda80 fp = 0xffff000065dfdb90 >> >> handle_el0_sync() at 0x40040070 >> pc = 0xffff0000006079e8 lr = 0x0000000040040070 >> sp = 0xffff000065dfdba0 fp = 0x0000ffffffffeb00 >> >> KDB: enter: panic >> [ thread pid 709 tid 100086 ] >> Stopped at kdb_enter+0x44: undefined d4200000 >> db> > > Another example failure is: > > Fatal data abort: > x0: 400a9000 > x1: 1000 > x2: 0 > x3: 40 > x4: 3f > x5: fffffd00304e5000 > x6: 2b52 > x7: c > x8: b > x9: fffffd000076d5d0 > x10: 68 > x11: 40000000 > x12: 704c5000 > x13: 42b42003 > x14: 42b42003 > x15: 40000000 > x16: c > x17: ffffffffffffffff > x18: ffff000065dd5310 > x19: 800000000000000 > x20: 1 > x21: fffffd0002b43000 > x22: 12000004556478b > x23: f000000000000000 > x24: fffffd0002b41bc8 > x25: 40 > x26: fffffd0002b42548 > x27: 7b > x28: 3 > x29: ffff000065dd53c0 > sp: ffff000065dd5310 > lr: ffff0000006175d8 > elr: ffff00000060589c > spsr: 60000345 > far: 400a9000 > esr: 96000147 > [ thread pid 715 tid 100078 ] > Stopped at arm64_dcache_wb_range+0x18: undefined d50b7a20 > db> bt > Tracing pid 715 tid 100078 td 0xfffffd00007849c0 > db_trace_self() at db_stack_trace+0xf0 > pc = 0xffff000000605cc0 lr = 0xffff0000000840e0 > sp = 0xffff000065dd4cb0 fp = 0xffff000065dd4ce0 > > db_stack_trace() at db_command+0x23c > pc = 0xffff0000000840e0 lr = 0xffff000000083d58 > sp = 0xffff000065dd4cf0 fp = 0xffff000065dd4dd0 > > db_command() at db_command_loop+0x60 > pc = 0xffff000000083d58 lr = 0xffff000000083b00 > sp = 0xffff000065dd4de0 fp = 0xffff000065dd4e00 > > db_command_loop() at db_trap+0xf4 > pc = 0xffff000000083b00 lr = 0xffff000000086b34 > sp = 0xffff000065dd4e10 fp = 0xffff000065dd5030 > > db_trap() at kdb_trap+0x180 > pc = 0xffff000000086b34 lr = 0xffff00000035f650 > sp = 0xffff000065dd5040 fp = 0xffff000065dd50a0 > > kdb_trap() at data_abort+0x1a0 > pc = 0xffff00000035f650 lr = 0xffff00000061ae54 > sp = 0xffff000065dd50b0 fp = 0xffff000065dd5160 > > data_abort() at handle_el1h_sync+0x70 > pc = 0xffff00000061ae54 lr = 0xffff000000607870 > sp = 0xffff000065dd5170 fp = 0xffff000065dd5280 > > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc = 0xffff000000607870 lr = 0xffff0000006175d4 > sp = 0xffff000065dd5290 fp = 0xffff000065dd53c0 > > pmap_remove_pages() at exec_new_vmspace+0x1a4 > pc = 0xffff0000006175d4 lr = 0xffff0000002d9da0 > sp = 0xffff000065dd53d0 fp = 0xffff000065dd5430 > > exec_new_vmspace() at exec_elf64_imgact+0xa70 > pc = 0xffff0000002d9da0 lr = 0xffff0000002b7c14 > sp = 0xffff000065dd5440 fp = 0xffff000065dd5550 > > exec_elf64_imgact() at kern_execve+0x664 > pc = 0xffff0000002b7c14 lr = 0xffff0000002d8730 > sp = 0xffff000065dd5560 fp = 0xffff000065dd58b0 > > kern_execve() at sys_execve+0x54 > pc = 0xffff0000002d8730 lr = 0xffff0000002d7d90 > sp = 0xffff000065dd58c0 fp = 0xffff000065dd5930 > > sys_execve() at do_el0_sync+0xa48 > pc = 0xffff0000002d7d90 lr = 0xffff00000061b91c > sp = 0xffff000065dd5940 fp = 0xffff000065dd5a70 > > do_el0_sync() at handle_el0_sync+0x6c > pc = 0xffff00000061b91c lr = 0xffff0000006079e8 > sp = 0xffff000065dd5a80 fp = 0xffff000065dd5b90 > > handle_el0_sync() at 0x24a90 > pc = 0xffff0000006079e8 lr = 0x0000000000024a90 > sp = 0xffff000065dd5ba0 fp = 0x0000ffffffffe7d0 > > db> === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 2 21:30:08 2017 Return-Path: Delivered-To: freebsd-current@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 A65E7D5A7BC for ; Tue, 2 May 2017 21:30:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 64AFB19F4 for ; Tue, 2 May 2017 21:30:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13149 invoked from network); 2 May 2017 21:31:16 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 21:31:16 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 17:30:07 -0400 (EDT) Received: (qmail 24247 invoked from network); 2 May 2017 21:30:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 21:30:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 217C4EC8552; Tue, 2 May 2017 14:30:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> Date: Tue, 2 May 2017 14:30:05 -0700 Cc: "O. Hartmann" , Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> To: freebsd-arm , FreeBSD Current , Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:30:08 -0000 On 2017-May-2, at 2:22 PM, Mark Millard wrote: > It turns out that the bt's from the example panics are > repeatable for the pc and lr sequence involved (but not > the specific sp's and fp's involved). I report this in > case it suggests anything. I'll note that the build had > a production style kernel for a build of -r317015 . >=20 > The first type of panic actually a back to back > sequence of two bt's, this is the sleeping-thread type > pf example. The second type is just one bt by itself. >=20 > There is one variable lr in the bt for the sleeping-thread > type of example (the first type of panic of the two shown > later, the one with back-to-back bt's): >=20 > 131,133c131,133 > < handle_el0_sync() at 0x40040070 > < pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 > < sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 > --- >> handle_el0_sync() at 0x40044490 >> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040044490 >> sp =3D 0xffff000040229ba0 fp =3D 0x0000ffffffffe3d0 >=20 > Otherwise the two bt's in the example match for the pc/lr > sequence. >=20 > I only have the two examples of this type to compare so > far (one diff). >=20 > I have 3 examples of the second type and they had no such > variation. >=20 > One thing in common to all 5 of these examples is the > sequence: >=20 > data_abort() at handle_el1h_sync+0x70 > lr =3D 0xffff000000607870 > handle_el1h_sync() at pmap_remove_pages+0x2a8 > pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 > pmap_remove_pages() >=20 > being involved in each example. >=20 >=20 > I'm not saying that I can cause any panics at will, but > when either of the two types happen the bt is (mostly) > stable for the pc and lr sequence and that short > sequence above is involved. >=20 > I have seen one other type of panic but I did not manage > to record a bt for it yet. It involved the instruction > cache instead of arm64_dcache_wb_range . >=20 > I quote the prior reported example bt's below. >=20 > On 2017-May-2, at 5:24 AM, Mark Millard = wrote: >=20 >> On 2017-May-2, at 3:37 AM, Mark Millard = wrote: >>=20 >>> On 2017-May-2, at 2:53 AM, Mark Millard = wrote: >>>=20 >>> . . . >>> FYI: >>>=20 >>> I do sometimes get things like: >>>=20 >>>=20 >>> System shutdown time has arrived >>> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 >>> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >>> KDB: stack backtrace of thread 100093: >>> sched_switch() at mi_switch+0x100 >>> pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 >>> sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >>>=20 >>> mi_switch() at sleepq_wait+0x3c >>> pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 >>> sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >>>=20 >>> sleepq_wait() at _sleep+0x29c >>> pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c >>> sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >>>=20 >>> _sleep() at vm_page_sleep_if_busy+0xb0 >>> pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 >>> sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >>>=20 >>> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >>> pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c >>> sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >>>=20 >>> handle_el1h_sync() at pmap_enter+0x678 >>> pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 >>> sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >>>=20 >>> pmap_enter() at vm_fault_hold+0x17c0 >>> pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 >>> sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >>>=20 >>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>> sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >>>=20 >>> pmap_remove_pages() at vmspace_exit+0xb0 >>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c >>> sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >>>=20 >>> vmspace_exit() at exit1+0x604 >>> pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 >>> sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >>>=20 >>> exit1() at sys_sys_exit+0x10 >>> pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 >>> sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >>>=20 >>> sys_sys_exit() at do_el0_sync+0xa48 >>> pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c >>> sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >>>=20 >>> do_el0_sync() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >>>=20 >>> handle_el0_sync() at 0x38cc0 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 >>> sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >>>=20 >>> panic: sleeping thread >>> cpuid =3D 2 >>> time =3D 1493581440 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self_wrapper+0x28 >>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >>> sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >>>=20 >>> db_trace_self_wrapper() at vpanic+0x164 >>> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >>> sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >>>=20 >>> vpanic() at panic+0x4c >>> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >>> sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >>>=20 >>> panic() at propagate_priority+0x2d0 >>> pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 >>> sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >>>=20 >>> propagate_priority() at turnstile_wait+0x340 >>> pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c >>> sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >>>=20 >>> turnstile_wait() at __rw_wlock_hard+0x208 >>> pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 >>> sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >>>=20 >>> __rw_wlock_hard() at pmap_enter+0xe98 >>> pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 >>> sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >>>=20 >>> pmap_enter() at vm_fault_hold+0x28c >>> pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 >>> sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >>>=20 >>> vm_fault_hold() at vm_fault+0x70 >>> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >>> sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >>>=20 >>> vm_fault() at data_abort+0xe0 >>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>> sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >>>=20 >>> data_abort() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >>>=20 >>> handle_el0_sync() at 0x40040070 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >>> sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >>>=20 >>> KDB: enter: panic >>> [ thread pid 709 tid 100086 ] >>> Stopped at kdb_enter+0x44: undefined d4200000 >>> db> >>=20 >> Another example failure is: >>=20 >> Fatal data abort: >> x0: 400a9000 >> x1: 1000 >> x2: 0 >> x3: 40 >> x4: 3f >> x5: fffffd00304e5000 >> x6: 2b52 >> x7: c >> x8: b >> x9: fffffd000076d5d0 >> x10: 68 >> x11: 40000000 >> x12: 704c5000 >> x13: 42b42003 >> x14: 42b42003 >> x15: 40000000 >> x16: c >> x17: ffffffffffffffff >> x18: ffff000065dd5310 >> x19: 800000000000000 >> x20: 1 >> x21: fffffd0002b43000 >> x22: 12000004556478b >> x23: f000000000000000 >> x24: fffffd0002b41bc8 >> x25: 40 >> x26: fffffd0002b42548 >> x27: 7b >> x28: 3 >> x29: ffff000065dd53c0 >> sp: ffff000065dd5310 >> lr: ffff0000006175d8 >> elr: ffff00000060589c >> spsr: 60000345 >> far: 400a9000 >> esr: 96000147 >> [ thread pid 715 tid 100078 ] >> Stopped at arm64_dcache_wb_range+0x18: undefined = d50b7a20 >> db> bt >> Tracing pid 715 tid 100078 td 0xfffffd00007849c0 >> db_trace_self() at db_stack_trace+0xf0 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 >> sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 >>=20 >> db_stack_trace() at db_command+0x23c >> pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 >> sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 >>=20 >> db_command() at db_command_loop+0x60 >> pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 >> sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 >>=20 >> db_command_loop() at db_trap+0xf4 >> pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 >> sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 >>=20 >> db_trap() at kdb_trap+0x180 >> pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 >> sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 >>=20 >> kdb_trap() at data_abort+0x1a0 >> pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 >> sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 >> sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 >>=20 >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >> sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 >>=20 >> pmap_remove_pages() at exec_new_vmspace+0x1a4 >> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 >> sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 >>=20 >> exec_new_vmspace() at exec_elf64_imgact+0xa70 >> pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 >> sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 >>=20 >> exec_elf64_imgact() at kern_execve+0x664 >> pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 >> sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 >>=20 >> kern_execve() at sys_execve+0x54 >> pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 >> sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 >>=20 >> sys_execve() at do_el0_sync+0xa48 >> pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 >>=20 >> handle_el0_sync() at 0x24a90 >> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 >> sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 >>=20 >> db>=20 Because Konstanin B. was not Cc'd/To'd previously I should have included the following background information about how this was run on a Odroid-C2 under UbuntuMate: qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -machine virt \ -bios QEMU_EFI.fd -nographic \ -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64.raw,id=3D= hd0 \ -device virtio-blk-device,drive=3Dhd0 \ -device virtio-net-device,netdev=3Dnet0 \ -netdev user,id=3Dnet0 \ -smp cpus=3D4 based on: = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd and my build of head -r317015 turned into a .raw file. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue May 2 21:59:58 2017 Return-Path: Delivered-To: freebsd-current@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 9C2E1D5B7EA for ; Tue, 2 May 2017 21:59:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 5AF6D181 for ; Tue, 2 May 2017 21:59:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 540 invoked from network); 2 May 2017 21:59:56 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 May 2017 21:59:56 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 17:59:56 -0400 (EDT) Received: (qmail 24629 invoked from network); 2 May 2017 21:59:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 May 2017 21:59:56 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CA13CEC913D; Tue, 2 May 2017 14:59:55 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] Date: Tue, 2 May 2017 14:59:55 -0700 References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov , FreeBSD Current , freebsd-arm In-Reply-To: <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:59:58 -0000 On 2017-May-2, at 2:30 PM, Mark Millard wrote: > On 2017-May-2, at 2:22 PM, Mark Millard = wrote: >=20 >> It turns out that the bt's from the example panics are >> repeatable for the pc and lr sequence involved (but not >> the specific sp's and fp's involved). I report this in >> case it suggests anything. I'll note that the build had >> a production style kernel for a build of -r317015 . >>=20 >> The first type of panic actually a back to back >> sequence of two bt's, this is the sleeping-thread type >> pf example. The second type is just one bt by itself. >>=20 >> There is one variable lr in the bt for the sleeping-thread >> type of example (the first type of panic of the two shown >> later, the one with back-to-back bt's): >>=20 >> 131,133c131,133 >> < handle_el0_sync() at 0x40040070 >> < pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >> < sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >> --- >>> handle_el0_sync() at 0x40044490 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040044490 >>> sp =3D 0xffff000040229ba0 fp =3D 0x0000ffffffffe3d0 >>=20 >> Otherwise the two bt's in the example match for the pc/lr >> sequence. >>=20 >> I only have the two examples of this type to compare so >> far (one diff). >>=20 >> I have 3 examples of the second type and they had no such >> variation. >>=20 >> One thing in common to all 5 of these examples is the >> sequence: >>=20 >> data_abort() at handle_el1h_sync+0x70 >> lr =3D 0xffff000000607870 >> handle_el1h_sync() at pmap_remove_pages+0x2a8 >> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >> pmap_remove_pages() >>=20 >> being involved in each example. >>=20 >>=20 >> I'm not saying that I can cause any panics at will, but >> when either of the two types happen the bt is (mostly) >> stable for the pc and lr sequence and that short >> sequence above is involved. >>=20 >> I have seen one other type of panic but I did not manage >> to record a bt for it yet. It involved the instruction >> cache instead of arm64_dcache_wb_range . >>=20 >> I quote the prior reported example bt's below. >>=20 >> On 2017-May-2, at 5:24 AM, Mark Millard = wrote: >>=20 >>> On 2017-May-2, at 3:37 AM, Mark Millard = wrote: >>>=20 >>>> On 2017-May-2, at 2:53 AM, Mark Millard = wrote: >>>>=20 >>>> . . . >>>> FYI: >>>>=20 >>>> I do sometimes get things like: >>>>=20 >>>>=20 >>>> System shutdown time has arrived >>>> Apr 30 19:43:15 ODC2FBSD shutdown: power-down by root:=20 >>>> Sleeping thread (tid 100093, pid 708) owns a non-sleepable lock >>>> KDB: stack backtrace of thread 100093: >>>> sched_switch() at mi_switch+0x100 >>>> pc =3D 0xffff000000347d44 lr =3D 0xffff000000327358 >>>> sp =3D 0xffff000040237e00 fp =3D 0xffff000040237e20 >>>>=20 >>>> mi_switch() at sleepq_wait+0x3c >>>> pc =3D 0xffff000000327358 lr =3D 0xffff00000036c174 >>>> sp =3D 0xffff000040237e30 fp =3D 0xffff000040237e50 >>>>=20 >>>> sleepq_wait() at _sleep+0x29c >>>> pc =3D 0xffff00000036c174 lr =3D 0xffff000000326c7c >>>> sp =3D 0xffff000040237e60 fp =3D 0xffff000040237ee0 >>>>=20 >>>> _sleep() at vm_page_sleep_if_busy+0xb0 >>>> pc =3D 0xffff000000326c7c lr =3D 0xffff0000005cfcf4 >>>> sp =3D 0xffff000040237ef0 fp =3D 0xffff000040237f10 >>>>=20 >>>> vm_page_sleep_if_busy() at vm_fault_hold+0xcc8 >>>> pc =3D 0xffff0000005cfcf4 lr =3D 0xffff0000005ba17c >>>> sp =3D 0xffff000040237f20 fp =3D 0xffff000040238070 >>>>=20 >>>> vm_fault_hold() at vm_fault+0x70 >>>> pc =3D 0xffff0000005ba17c lr =3D 0xffff0000005b9464 >>>> sp =3D 0xffff000040238080 fp =3D 0xffff0000402380b0 >>>>=20 >>>> vm_fault() at data_abort+0xe0 >>>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>>> sp =3D 0xffff0000402380c0 fp =3D 0xffff000040238170 >>>>=20 >>>> data_abort() at handle_el1h_sync+0x70 >>>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>>> sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 >>>>=20 >>>> handle_el1h_sync() at pmap_enter+0x678 >>>> pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 >>>> sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 >>>>=20 >>>> pmap_enter() at vm_fault_hold+0x17c0 >>>> pc =3D 0xffff000000615684 lr =3D 0xffff0000005bac74 >>>> sp =3D 0xffff0000402383c0 fp =3D 0xffff000040238510 >>>>=20 >>>> vm_fault_hold() at vm_fault+0x70 >>>> pc =3D 0xffff0000005bac74 lr =3D 0xffff0000005b9464 >>>> sp =3D 0xffff000040238520 fp =3D 0xffff000040238550 >>>>=20 >>>> vm_fault() at data_abort+0xe0 >>>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>>> sp =3D 0xffff000040238560 fp =3D 0xffff000040238610 >>>>=20 >>>> data_abort() at handle_el1h_sync+0x70 >>>> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >>>> sp =3D 0xffff000040238620 fp =3D 0xffff000040238730 >>>>=20 >>>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>>> sp =3D 0xffff000040238740 fp =3D 0xffff000040238870 >>>>=20 >>>> pmap_remove_pages() at vmspace_exit+0xb0 >>>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000005c020c >>>> sp =3D 0xffff000040238880 fp =3D 0xffff0000402388b0 >>>>=20 >>>> vmspace_exit() at exit1+0x604 >>>> pc =3D 0xffff0000005c020c lr =3D 0xffff0000002db5e0 >>>> sp =3D 0xffff0000402388c0 fp =3D 0xffff000040238920 >>>>=20 >>>> exit1() at sys_sys_exit+0x10 >>>> pc =3D 0xffff0000002db5e0 lr =3D 0xffff0000002dafd8 >>>> sp =3D 0xffff000040238930 fp =3D 0xffff000040238930 >>>>=20 >>>> sys_sys_exit() at do_el0_sync+0xa48 >>>> pc =3D 0xffff0000002dafd8 lr =3D 0xffff00000061b91c >>>> sp =3D 0xffff000040238940 fp =3D 0xffff000040238a70 >>>>=20 >>>> do_el0_sync() at handle_el0_sync+0x6c >>>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>>> sp =3D 0xffff000040238a80 fp =3D 0xffff000040238b90 >>>>=20 >>>> handle_el0_sync() at 0x38cc0 >>>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000038cc0 >>>> sp =3D 0xffff000040238ba0 fp =3D 0x0000ffffffffed00 >>>>=20 >>>> panic: sleeping thread >>>> cpuid =3D 2 >>>> time =3D 1493581440 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self_wrapper+0x28 >>>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >>>> sp =3D 0xffff000065dfd320 fp =3D 0xffff000065dfd530 >>>>=20 >>>> db_trace_self_wrapper() at vpanic+0x164 >>>> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >>>> sp =3D 0xffff000065dfd540 fp =3D 0xffff000065dfd5b0 >>>>=20 >>>> vpanic() at panic+0x4c >>>> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >>>> sp =3D 0xffff000065dfd5c0 fp =3D 0xffff000065dfd640 >>>>=20 >>>> panic() at propagate_priority+0x2d0 >>>> pc =3D 0xffff00000031d2fc lr =3D 0xffff000000374558 >>>> sp =3D 0xffff000065dfd650 fp =3D 0xffff000065dfd690 >>>>=20 >>>> propagate_priority() at turnstile_wait+0x340 >>>> pc =3D 0xffff000000374558 lr =3D 0xffff00000037503c >>>> sp =3D 0xffff000065dfd6a0 fp =3D 0xffff000065dfd6e0 >>>>=20 >>>> turnstile_wait() at __rw_wlock_hard+0x208 >>>> pc =3D 0xffff00000037503c lr =3D 0xffff000000319138 >>>> sp =3D 0xffff000065dfd6f0 fp =3D 0xffff000065dfd770 >>>>=20 >>>> __rw_wlock_hard() at pmap_enter+0xe98 >>>> pc =3D 0xffff000000319138 lr =3D 0xffff000000615ea4 >>>> sp =3D 0xffff000065dfd780 fp =3D 0xffff000065dfd810 >>>>=20 >>>> pmap_enter() at vm_fault_hold+0x28c >>>> pc =3D 0xffff000000615ea4 lr =3D 0xffff0000005b9740 >>>> sp =3D 0xffff000065dfd820 fp =3D 0xffff000065dfd970 >>>>=20 >>>> vm_fault_hold() at vm_fault+0x70 >>>> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >>>> sp =3D 0xffff000065dfd980 fp =3D 0xffff000065dfd9b0 >>>>=20 >>>> vm_fault() at data_abort+0xe0 >>>> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >>>> sp =3D 0xffff000065dfd9c0 fp =3D 0xffff000065dfda70 >>>>=20 >>>> data_abort() at handle_el0_sync+0x6c >>>> pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 >>>> sp =3D 0xffff000065dfda80 fp =3D 0xffff000065dfdb90 >>>>=20 >>>> handle_el0_sync() at 0x40040070 >>>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000040040070 >>>> sp =3D 0xffff000065dfdba0 fp =3D 0x0000ffffffffeb00 >>>>=20 >>>> KDB: enter: panic >>>> [ thread pid 709 tid 100086 ] >>>> Stopped at kdb_enter+0x44: undefined d4200000 >>>> db> >>>=20 >>> Another example failure is: >>>=20 >>> Fatal data abort: >>> x0: 400a9000 >>> x1: 1000 >>> x2: 0 >>> x3: 40 >>> x4: 3f >>> x5: fffffd00304e5000 >>> x6: 2b52 >>> x7: c >>> x8: b >>> x9: fffffd000076d5d0 >>> x10: 68 >>> x11: 40000000 >>> x12: 704c5000 >>> x13: 42b42003 >>> x14: 42b42003 >>> x15: 40000000 >>> x16: c >>> x17: ffffffffffffffff >>> x18: ffff000065dd5310 >>> x19: 800000000000000 >>> x20: 1 >>> x21: fffffd0002b43000 >>> x22: 12000004556478b >>> x23: f000000000000000 >>> x24: fffffd0002b41bc8 >>> x25: 40 >>> x26: fffffd0002b42548 >>> x27: 7b >>> x28: 3 >>> x29: ffff000065dd53c0 >>> sp: ffff000065dd5310 >>> lr: ffff0000006175d8 >>> elr: ffff00000060589c >>> spsr: 60000345 >>> far: 400a9000 >>> esr: 96000147 >>> [ thread pid 715 tid 100078 ] >>> Stopped at arm64_dcache_wb_range+0x18: undefined = d50b7a20 >>> db> bt >>> Tracing pid 715 tid 100078 td 0xfffffd00007849c0 >>> db_trace_self() at db_stack_trace+0xf0 >>> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000840e0 >>> sp =3D 0xffff000065dd4cb0 fp =3D 0xffff000065dd4ce0 >>>=20 >>> db_stack_trace() at db_command+0x23c >>> pc =3D 0xffff0000000840e0 lr =3D 0xffff000000083d58 >>> sp =3D 0xffff000065dd4cf0 fp =3D 0xffff000065dd4dd0 >>>=20 >>> db_command() at db_command_loop+0x60 >>> pc =3D 0xffff000000083d58 lr =3D 0xffff000000083b00 >>> sp =3D 0xffff000065dd4de0 fp =3D 0xffff000065dd4e00 >>>=20 >>> db_command_loop() at db_trap+0xf4 >>> pc =3D 0xffff000000083b00 lr =3D 0xffff000000086b34 >>> sp =3D 0xffff000065dd4e10 fp =3D 0xffff000065dd5030 >>>=20 >>> db_trap() at kdb_trap+0x180 >>> pc =3D 0xffff000000086b34 lr =3D 0xffff00000035f650 >>> sp =3D 0xffff000065dd5040 fp =3D 0xffff000065dd50a0 >>>=20 >>> kdb_trap() at data_abort+0x1a0 >>> pc =3D 0xffff00000035f650 lr =3D 0xffff00000061ae54 >>> sp =3D 0xffff000065dd50b0 fp =3D 0xffff000065dd5160 >>>=20 >>> data_abort() at handle_el1h_sync+0x70 >>> pc =3D 0xffff00000061ae54 lr =3D 0xffff000000607870 >>> sp =3D 0xffff000065dd5170 fp =3D 0xffff000065dd5280 >>>=20 >>> handle_el1h_sync() at pmap_remove_pages+0x2a8 >>> pc =3D 0xffff000000607870 lr =3D 0xffff0000006175d4 >>> sp =3D 0xffff000065dd5290 fp =3D 0xffff000065dd53c0 >>>=20 >>> pmap_remove_pages() at exec_new_vmspace+0x1a4 >>> pc =3D 0xffff0000006175d4 lr =3D 0xffff0000002d9da0 >>> sp =3D 0xffff000065dd53d0 fp =3D 0xffff000065dd5430 >>>=20 >>> exec_new_vmspace() at exec_elf64_imgact+0xa70 >>> pc =3D 0xffff0000002d9da0 lr =3D 0xffff0000002b7c14 >>> sp =3D 0xffff000065dd5440 fp =3D 0xffff000065dd5550 >>>=20 >>> exec_elf64_imgact() at kern_execve+0x664 >>> pc =3D 0xffff0000002b7c14 lr =3D 0xffff0000002d8730 >>> sp =3D 0xffff000065dd5560 fp =3D 0xffff000065dd58b0 >>>=20 >>> kern_execve() at sys_execve+0x54 >>> pc =3D 0xffff0000002d8730 lr =3D 0xffff0000002d7d90 >>> sp =3D 0xffff000065dd58c0 fp =3D 0xffff000065dd5930 >>>=20 >>> sys_execve() at do_el0_sync+0xa48 >>> pc =3D 0xffff0000002d7d90 lr =3D 0xffff00000061b91c >>> sp =3D 0xffff000065dd5940 fp =3D 0xffff000065dd5a70 >>>=20 >>> do_el0_sync() at handle_el0_sync+0x6c >>> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >>> sp =3D 0xffff000065dd5a80 fp =3D 0xffff000065dd5b90 >>>=20 >>> handle_el0_sync() at 0x24a90 >>> pc =3D 0xffff0000006079e8 lr =3D 0x0000000000024a90 >>> sp =3D 0xffff000065dd5ba0 fp =3D 0x0000ffffffffe7d0 >>>=20 >>> db>=20 >=20 > Because Konstanin B. was not Cc'd/To'd previously > I should have included the following background > information about how this was run on a > Odroid-C2 under UbuntuMate: >=20 > qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -machine virt \ > -bios QEMU_EFI.fd -nographic \ > -drive = format=3Draw,if=3Dnone,file=3DFreeBSD-12.0-CURRENT-arm64-aarch64.raw,id=3D= hd0 \ > -device virtio-blk-device,drive=3Dhd0 \ > -device virtio-net-device,netdev=3Dnet0 \ > -netdev user,id=3Dnet0 \ > -smp cpus=3D4 >=20 > based on: >=20 > = https://releases.linaro.org/components/kernel/uefi-linaro/16.02/release/qe= mu64/QEMU_EFI.fd >=20 > and my build of head -r317015 turned into a .raw file. The code around handle_el1h_sync+0x70 : ffff000000607804 sub sp, sp, #0x80 ffff000000607808 sub sp, sp, #0x120 ffff00000060780c stp x29, x30, [sp,#272] ffff000000607810 stp x28, x29, [sp,#256] ffff000000607814 stp x26, x27, [sp,#240] ffff000000607818 stp x24, x25, [sp,#224] ffff00000060781c stp x22, x23, [sp,#208] ffff000000607820 stp x20, x21, [sp,#192] ffff000000607824 stp x18, x19, [sp,#176] ffff000000607828 stp x16, x17, [sp,#160] ffff00000060782c stp x14, x15, [sp,#144] ffff000000607830 stp x12, x13, [sp,#128] ffff000000607834 stp x10, x11, [sp,#112] ffff000000607838 stp x8, x9, [sp,#96] ffff00000060783c stp x6, x7, [sp,#80] ffff000000607840 stp x4, x5, [sp,#64] ffff000000607844 stp x2, x3, [sp,#48] ffff000000607848 stp x0, x1, [sp,#32] ffff00000060784c mrs x10, elr_el1 ffff000000607850 mrs x11, spsr_el1 ffff000000607854 mrs x12, esr_el1 ffff000000607858 str x10, [sp,#16] ffff00000060785c stp w11, w12, [sp,#24] ffff000000607860 stp x18, x30, [sp] ffff000000607864 mrs x18, tpidr_el1 ffff000000607868 add x29, sp, #0x110 ffff00000060786c mov x0, sp ffff000000607870 bl ffff00000061aad8 = ffff000000607874 msr daifset, #0x2 ffff000000607878 ldp x18, x30, [sp] ffff00000060787c ldp x10, x11, [sp,#16] ffff000000607880 msr spsr_el1, x11 ffff000000607884 msr elr_el1, x10 ffff000000607888 ldp x0, x1, [sp,#32] ffff00000060788c ldp x2, x3, [sp,#48] ffff000000607890 ldp x4, x5, [sp,#64] ffff000000607894 ldp x6, x7, [sp,#80] ffff000000607898 ldp x8, x9, [sp,#96] ffff00000060789c ldp x10, x11, [sp,#112] ffff0000006078a0 ldp x12, x13, [sp,#128] ffff0000006078a4 ldp x14, x15, [sp,#144] ffff0000006078a8 ldp x16, x17, [sp,#160] ffff0000006078ac ldr x29, [sp,#264] ffff0000006078b0 mov sp, x18 ffff0000006078b4 mrs x18, tpidr_el1 ffff0000006078b8 eret So the bl to do_el1h_sync apparently gets the data_abort. The code around pmap_remove_pages+0x2a8 : ffff000000617570 bl ffff0000005cf83c = ffff000000617574 ldr x9, [sp,#80] ffff000000617578 adrp x8, ffff000000bbd000 = ffff00000061757c add x8, x8, #0x848 ffff000000617580 str x0, [sp,#48] ffff000000617584 cmp x9, x8 ffff000000617588 b.eq ffff0000006175a4 = ffff00000061758c ldr x8, [x18] ffff000000617590 ldr x8, [x8,#8] ffff000000617594 ldr x8, [x8,#512] ffff000000617598 ldr x8, [x8,#224] ffff00000061759c cmp x8, x9 ffff0000006175a0 b.ne ffff0000006175d8 = ffff0000006175a4 and x8, x22, #0x1f ffff0000006175a8 cmp x28, #0x3 ffff0000006175ac b.ne ffff0000006175c4 = ffff0000006175b0 cmp x8, #0xb ffff0000006175b4 b.ne ffff0000006175d8 = ffff0000006175b8 ldr x0, [x24] ffff0000006175bc orr w1, wzr, #0x1000 ffff0000006175c0 b ffff0000006175d4 = ffff0000006175c4 cmp x8, #0x9 ffff0000006175c8 b.ne ffff0000006175d8 = ffff0000006175cc ldr x0, [x24] ffff0000006175d0 orr w1, wzr, #0x200000 ffff0000006175d4 bl ffff000000605884 = ffff0000006175d8 mov x8, xzr ffff0000006175dc orr w1, wzr, #0x8 ffff0000006175e0 mov x0, x26 ffff0000006175e4 ldxr x9, [x26] ffff0000006175e8 stxr w10, x8, [x26] ffff0000006175ec cbnz w10, ffff0000006175e4 = ffff0000006175f0 bl ffff000000605884 = So this happens to involve arm64_dcache_wb_range (that has not started yet). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed May 3 01:53:35 2017 Return-Path: Delivered-To: freebsd-current@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 D6EC4D5B88E for ; Wed, 3 May 2017 01:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 982431046 for ; Wed, 3 May 2017 01:53:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15178 invoked from network); 3 May 2017 01:53:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 May 2017 01:53:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 02 May 2017 21:53:33 -0400 (EDT) Received: (qmail 8830 invoked from network); 3 May 2017 01:53:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 01:53:33 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9E834EC7ED9; Tue, 2 May 2017 18:53:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 18:53:32 -0700 Cc: FreeBSD Current , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 01:53:35 -0000 On 2017-May-2, at 2:59 PM, Mark Millard wrote: > The code around handle_el1h_sync+0x70 : >=20 > ffff000000607804 sub sp, sp, #0x80 > ffff000000607808 sub sp, sp, #0x120 > ffff00000060780c stp x29, x30, [sp,#272] > ffff000000607810 stp x28, x29, [sp,#256] > ffff000000607814 stp x26, x27, [sp,#240] > ffff000000607818 stp x24, x25, [sp,#224] > ffff00000060781c stp x22, x23, [sp,#208] > ffff000000607820 stp x20, x21, [sp,#192] > ffff000000607824 stp x18, x19, [sp,#176] > ffff000000607828 stp x16, x17, [sp,#160] > ffff00000060782c stp x14, x15, [sp,#144] > ffff000000607830 stp x12, x13, [sp,#128] > ffff000000607834 stp x10, x11, [sp,#112] > ffff000000607838 stp x8, x9, [sp,#96] > ffff00000060783c stp x6, x7, [sp,#80] > ffff000000607840 stp x4, x5, [sp,#64] > ffff000000607844 stp x2, x3, [sp,#48] > ffff000000607848 stp x0, x1, [sp,#32] > ffff00000060784c mrs x10, elr_el1 > ffff000000607850 mrs x11, spsr_el1 > ffff000000607854 mrs x12, esr_el1 > ffff000000607858 str x10, [sp,#16] > ffff00000060785c stp w11, w12, [sp,#24] > ffff000000607860 stp x18, x30, [sp] > ffff000000607864 mrs x18, tpidr_el1 > ffff000000607868 add x29, sp, #0x110 > ffff00000060786c mov x0, sp > ffff000000607870 bl ffff00000061aad8 = > ffff000000607874 msr daifset, #0x2 > ffff000000607878 ldp x18, x30, [sp] > ffff00000060787c ldp x10, x11, [sp,#16] > ffff000000607880 msr spsr_el1, x11 > ffff000000607884 msr elr_el1, x10 > ffff000000607888 ldp x0, x1, [sp,#32] > ffff00000060788c ldp x2, x3, [sp,#48] > ffff000000607890 ldp x4, x5, [sp,#64] > ffff000000607894 ldp x6, x7, [sp,#80] > ffff000000607898 ldp x8, x9, [sp,#96] > ffff00000060789c ldp x10, x11, [sp,#112] > ffff0000006078a0 ldp x12, x13, [sp,#128] > ffff0000006078a4 ldp x14, x15, [sp,#144] > ffff0000006078a8 ldp x16, x17, [sp,#160] > ffff0000006078ac ldr x29, [sp,#264] > ffff0000006078b0 mov sp, x18 > ffff0000006078b4 mrs x18, tpidr_el1 > ffff0000006078b8 eret >=20 > So the bl to do_el1h_sync apparently gets the data_abort. It turns out that in the first type of example there is also a: data_abort() at handle_el1h_sync+0x70 pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 sp =3D 0xffff000040238180 fp =3D 0xffff000040238290 handle_el1h_sync() at pmap_enter+0x678 pc =3D 0xffff000000607870 lr =3D 0xffff000000615684 sp =3D 0xffff0000402382a0 fp =3D 0xffff0000402383b0 in what I showed. And around pmap_enter+0x678 happens to be: ffff00000061566c b ffff000000615688 = ffff000000615670 and x8, x28, #0x1f ffff000000615674 cmp x8, #0xb ffff000000615678 b.ne ffff000000615688 = ffff00000061567c ldr x0, [sp,#32] ffff000000615680 orr w1, wzr, #0x1000 ffff000000615684 bl ffff000000605884 = ffff000000615688 ldrb w8, [x22,#93] ffff00000061568c tbnz w8, #2, ffff0000006157a4 = ffff000000615690 add x1, sp, #0x38 ffff000000615694 mov x0, x19 ffff000000615698 mov x24, x23 ffff00000061569c orr x23, x23, #0x100000000000000 ffff0000006156a0 bl ffff000000615f44 So again handle_el1h_sync happens at a bl to arm64_dcache_wb_range and ends up with a data_abort at handle_el1h_sync+0x70 . The context is pmap_enter instead of pmap_remove_pages. But an example of a pmap_remove_pages+0x2a8 context for handle_el1h_sync is also in the call chain for the first type of example that I originally showed. > The code around pmap_remove_pages+0x2a8 : >=20 > ffff000000617570 bl ffff0000005cf83c = > ffff000000617574 ldr x9, [sp,#80] > ffff000000617578 adrp x8, ffff000000bbd000 = > ffff00000061757c add x8, x8, #0x848 > ffff000000617580 str x0, [sp,#48] > ffff000000617584 cmp x9, x8 > ffff000000617588 b.eq ffff0000006175a4 = > ffff00000061758c ldr x8, [x18] > ffff000000617590 ldr x8, [x8,#8] > ffff000000617594 ldr x8, [x8,#512] > ffff000000617598 ldr x8, [x8,#224] > ffff00000061759c cmp x8, x9 > ffff0000006175a0 b.ne ffff0000006175d8 = > ffff0000006175a4 and x8, x22, #0x1f > ffff0000006175a8 cmp x28, #0x3 > ffff0000006175ac b.ne ffff0000006175c4 = > ffff0000006175b0 cmp x8, #0xb > ffff0000006175b4 b.ne ffff0000006175d8 = > ffff0000006175b8 ldr x0, [x24] > ffff0000006175bc orr w1, wzr, #0x1000 > ffff0000006175c0 b ffff0000006175d4 = > ffff0000006175c4 cmp x8, #0x9 > ffff0000006175c8 b.ne ffff0000006175d8 = > ffff0000006175cc ldr x0, [x24] > ffff0000006175d0 orr w1, wzr, #0x200000 > ffff0000006175d4 bl ffff000000605884 = > ffff0000006175d8 mov x8, xzr > ffff0000006175dc orr w1, wzr, #0x8 > ffff0000006175e0 mov x0, x26 > ffff0000006175e4 ldxr x9, [x26] > ffff0000006175e8 stxr w10, x8, [x26] > ffff0000006175ec cbnz w10, ffff0000006175e4 = > ffff0000006175f0 bl ffff000000605884 = >=20 > So this happens to involve arm64_dcache_wb_range (that has > not started yet). I still have not replicated the example that involved instruction-cache related code. I'm going to give up on directly attempting to get examples of that. But if I happen to see it again I'll try to remember to get a backtrace (bt) for it. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed May 3 04:13:00 2017 Return-Path: Delivered-To: freebsd-current@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 C8152D5BB5C for ; Wed, 3 May 2017 04:13:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 59B487BE for ; Wed, 3 May 2017 04:12:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8887 invoked from network); 3 May 2017 04:12:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 May 2017 04:12:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 03 May 2017 00:12:58 -0400 (EDT) Received: (qmail 1132 invoked from network); 3 May 2017 04:12:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 04:12:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6C86FEC7E18; Tue, 2 May 2017 21:12:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: [My FreeBSD-12.0-CURRENT-arm64-aarch64.raw ] under qemu-system-aarch64 on odroid-c2 under UbuntuMate : [A combination that boots but gets some panics] From: Mark Millard In-Reply-To: Date: Tue, 2 May 2017 21:12:56 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <04D483DF-56BA-4A49-9DA9-6EE0AD9C38D8@dsl-only.net> References: <47F6A67D-2D97-4992-96CE-45751190CA86@dsl-only.net> <61C08AFE-0BE8-4BDE-B50C-09268850AE21@fubar.geek.nz> <9D0414D3-7A48-4C37-8710-1AFAA5E2874E@dsl-only.net> <85D4E274-07FC-4E92-8A23-99712FB50707@dsl-only.net> <9E66D0B3-3682-49DD-A792-95E29F9DC55C@dsl-only.net> <934E8CA3-A100-47F8-B6F7-F49C83AA8EF0@dsl-only.net> To: Andrew Turner , Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 04:13:00 -0000 FYI: differences in FreeBSD's code vs.: = http://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.den0024a/BAB= JDBHI.html and its "Example 11.5. Cleaning by Virtual Address". . . (I do not claim to know that the differences point to any error. But I note them in case they prompt something. A couple of points do seem odd to me for the FreeBSD code.) The ARM example code does: DSB ISH DSB ISH ISB This has the property of forcing visibility only after everything is available to be visible (DSB ISH being referenced here). (The FreeBSD code does not have this property, but enforces visibility of a mix of old and new as it goes along.) It is point-of-unification code (data and instruction) for its purpose. The FreeBSD arm64_dcache__range code always pairs: DC CAVAC (or CIVAC or IVAC) DSB ISH inside it loop, forcing visibility of its intermediate state as it goes along. It is also point-of-coherency instead of point of unification (because of its purpose). The FreeBSD arm64_idcache_wbinv_range code always does the sequence of 4: DC CIVAC DSB ISH IC IVAU DSB ISH inside its loop and after the loop does one: ISB This is is a mix of point-of-coherency and point of unification code that forces visibility (DSB ISH) as it goes along, not just after the overall loop. To me the mix of point-of-coherency and point-of-unification seems strange. The FreeBSD arm64_icache_sync_range code always does the sequence of 4: DC CIVAU DSB ISH IC IVAU DSB ISH inside its loop and after the loop does one: ISB This is the closest to the "Example 11.5. Cleaning by Virtual Address" code and its purpose. It is all point-of-unification code that forces visibility (DSB ISH) as it goes long, not just after the overall loop. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed May 3 08:01:13 2017 Return-Path: Delivered-To: freebsd-current@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 1287CD5B597 for ; Wed, 3 May 2017 08:01:13 +0000 (UTC) (envelope-from yaneurabeya@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 E44ABC41 for ; Wed, 3 May 2017 08:01:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E35CBD5B596; Wed, 3 May 2017 08:01:12 +0000 (UTC) Delivered-To: current@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 E2FA1D5B595 for ; Wed, 3 May 2017 08:01:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::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 B39B8C40 for ; Wed, 3 May 2017 08:01:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x241.google.com with SMTP id v1so27047892pgv.3 for ; Wed, 03 May 2017 01:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KvhHxLjBeQsayuTdu2h6LIWJT9yperni+AhV/FHQjDQ=; b=cuZkQS+4Y3lFOB1mR4y/giHqcLGueBEMZLA+K4aeCQFPtdpYweb3Z+xuAQkMsbv1B1 Du4cntpojGKXQYe4H2q7c66lIcBZ7yufxsUfLD6a/4dOJMky++cw6M9aRrBfwKzLw2jk D2MLlirQAYB0cBAVlZyP62Zp2E8pbPlKT8lV6QRb0UYe5pVYemZo+HQm3tznISM0xS3P tWA7qdR7ddoKoWeMK4qVJPgtXYV1Obj1WxsRPqzGQIoVuDDdVWaFzdIQ5bZqC+jSnbsx RQjCDo+OEx9ubYsSuL+wpje0LU4EW/ueh6bcM2+rD2M8Mip8lFp/v80cCbVmHcFuSXdG yhaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KvhHxLjBeQsayuTdu2h6LIWJT9yperni+AhV/FHQjDQ=; b=AJewd3nlXcjDeMDFmnKtlpgwZ2GDJVXiumIwJNq0WoaisXjRilhkFbe+UomXla77/F 0xxcJsB3CCN/IJ3Y7uhPuSYCH5VyZtePtvc/W+Ls1+QoMvxXPcnnxt7Om4RZZm4U0IcB T/Avb2aLBAsHD3deENpcuSU/7WgcQbNsou9Jyzn6HBKqyp34CgPdiGISKhn6aptpqzNB XfIz5enU5B8ae/dDhJvRaaq31AYBKXJ3RobdECeTjdykBPX75Map4sQOKAQWUoKUdOtH u8UnnsGZmp386QvyGbWube2u7wXRwfXS4jOzRHZ9GcV4yMJEZTkngwKheXSF2Ie2e1RU HRcQ== X-Gm-Message-State: AN3rC/6iQ3eeDPhwYoo2P7+NmrjTO5vCEhHY5OZ5IeyJ3C6XZITC5FpI 3ajoR7sp+9jrHQ== X-Received: by 10.99.167.71 with SMTP id w7mr38420244pgo.138.1493798471710; Wed, 03 May 2017 01:01:11 -0700 (PDT) Received: from [192.168.20.13] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id t71sm3134976pfk.29.2017.05.03.01.01.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 01:01:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: old snapshot install images? From: Ngie Cooper X-Mailer: iPhone Mail (14E304) In-Reply-To: <20170502191531.GA10288@mail.michaelwlucas.com> Date: Wed, 3 May 2017 01:01:10 -0700 Cc: current@freebsd.org, Toomas Soome Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170502191531.GA10288@mail.michaelwlucas.com> To: "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 08:01:13 -0000 Hi Michael! > On May 2, 2017, at 12:15, Michael W. Lucas wro= te: >=20 > Hi, >=20 > About a year ago, I did a clean install on my desktop. No problems. >=20 > I tried a clean install now, and it dies with: >=20 > gtpzfsboot: error 1 lba 32 > error 1 > gptzfsboot: error 1 lba 4294967288 > gptzfsboot: error 1 lba 1 > gptzfsboot: no ZFS pools located, can't boot >=20 > The pool is visible in the live CD, and I can import it. I want to > file a PR. >=20 > The sensible thing for me to do is to use old snapshot installers to > determine when this machine could no longer install. >=20 > Unfortunately, the FTP servers only keep a month or so of snapshots. >=20 > ftp-archive doesn't have the old snapshots. >=20 > Does anyone have an archive of -current install media, either CD or > ISO? I need to get this box back fairly quickly, but I don't mind > burning a couple days to nail it down. - What sources are you using/revision are you at? - Are your drives the 512 byte/sector or 4kB/sector variety? Thanks, -Ngie= From owner-freebsd-current@freebsd.org Wed May 3 11:47:34 2017 Return-Path: Delivered-To: freebsd-current@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 4383AD5B5C0 for ; Wed, 3 May 2017 11:47:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net [208.70.210.63]) (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 E77BEC8B for ; Wed, 3 May 2017 11:47:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31750 invoked from network); 3 May 2017 11:50:49 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 May 2017 11:50:49 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 03 May 2017 07:47:32 -0400 (EDT) Received: (qmail 500 invoked from network); 3 May 2017 11:47:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 May 2017 11:47:31 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 33690EC7E18; Wed, 3 May 2017 04:47:31 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r317659 - head/sys/dev/uart [head -r317729 for armv6/7: ns8250_drain : error: implicit declaration of function 'ns8250_drain' is invalid in C99] Message-Id: Date: Wed, 3 May 2017 04:47:30 -0700 To: mav@FreeBSD.org, svn-src-head@freebsd.org, freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 11:47:34 -0000 > Author: mav > Date: Mon May 1 19:47:10 2017 > New Revision: 317659 > URL:=20 > https://svnweb.freebsd.org/changeset/base/317659 >=20 >=20 > Log: > Make some UART consoles to not spin wait for data to be sent. > =20 > At least with Tx FIFO enabled it shows me ~10% reduction of verbose = boot > time with serial console at 115200 baud. > =20 > Reviewed by: marcel > MFC after: 2 weeks >=20 > Modified: > head/sys/dev/uart/uart_dev_lpc.c > head/sys/dev/uart/uart_dev_ns8250.c After building head -r317729 for amd64 and aarch64, when I tried armv6 I instead got the following failure: --- uart_dev_lpc.o --- /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: implicit declaration = of function 'ns8250_drain' is invalid in C99 = [-Werror,-Wimplicit-function-declaration] ns8250_drain(bas, UART_DRAIN_TRANSMITTER); ^ /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: note: did you mean = 'lpc_ns8250_drain'? /usr/src/sys/dev/uart/uart_dev_lpc.c:140:1: note: 'lpc_ns8250_drain' = declared here lpc_ns8250_drain(struct uart_bas *bas, int what) ^ /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: this function = declaration is not a prototype [-Werror,-Wstrict-prototypes] ns8250_drain(bas, UART_DRAIN_TRANSMITTER); ^ 2 errors generated. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed May 3 16:34:27 2017 Return-Path: Delivered-To: freebsd-current@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 B7D96D5CF7A for ; Wed, 3 May 2017 16:34:27 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.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 9A873EAB for ; Wed, 3 May 2017 16:34:27 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id 99DA1D5CF79; Wed, 3 May 2017 16:34:27 +0000 (UTC) Delivered-To: current@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 9985ED5CF78 for ; Wed, 3 May 2017 16:34:27 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 5F27AEA3 for ; Wed, 3 May 2017 16:34:27 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v43GYOv1018349; Wed, 3 May 2017 12:34:24 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v43GYOcu018348; Wed, 3 May 2017 12:34:24 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 3 May 2017 12:34:24 -0400 From: "Michael W. Lucas" To: Ngie Cooper Cc: "Michael W. Lucas" , current@freebsd.org, Toomas Soome Subject: Re: old snapshot install images? Message-ID: <20170503163424.GA18325@mail.michaelwlucas.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Wed, 03 May 2017 12:34:25 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:34:27 -0000 On Wed, May 03, 2017 at 01:01:10AM -0700, Ngie Cooper wrote: > Hi Michael! > - What sources are you using/revision are you at? Using r311461 amd64 install memstick at the moment. Uname says built "Thu Jan 5 22:46:38 UTC 2017" > - Are your drives the 512 byte/sector or 4kB/sector variety? They all claim to be 512 byte/sector. FWIW. ;-) ==ml -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Wed May 3 16:37:08 2017 Return-Path: Delivered-To: freebsd-current@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 0EF9ED5C0DF for ; Wed, 3 May 2017 16:37:08 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id DCDD71210 for ; Wed, 3 May 2017 16:37:07 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D94E1D5C0DE; Wed, 3 May 2017 16:37:07 +0000 (UTC) Delivered-To: current@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 D856CD5C0DD for ; Wed, 3 May 2017 16:37:07 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::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 9C3F7120F for ; Wed, 3 May 2017 16:37:07 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-io0-x241.google.com with SMTP id x86so35933971ioe.3 for ; Wed, 03 May 2017 09:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=M9a1A8/+TL6zX8iqqF234mzVx+YOPX3BTVNK+yq+PZw=; b=cU9lkPBohVQTxSHnWqfiP6/bBJu0ROivnbrtjC1Jlj066zSQJ4aSVJpVBNAP8nQu6e eWibKCncx35ZE99qPjNpFOzoDUCSXtFJ1ugsp5j9KjbuTqHFpz4e8eD5BM8P6cIId/dH suE0IJqM9JB9C716GmqZq+TiNg4Hh5CJpRWyQmZWKLLcM/2uSAWJOgBPb9R7OB8zwg5K 4I8rP77n3b7oQ922YOq6GsHuAcCKT55fAYwzeEoAsWK3Ul0e9tb8HymDRELAgtyJ2m5I JTm9cWpTm3wvTsILF+VBukJHMpzobBiD2iG5ZjtQu/hZoT798rmg8NnUUaHgd2h/napV k2LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=M9a1A8/+TL6zX8iqqF234mzVx+YOPX3BTVNK+yq+PZw=; b=MbRrQUooqDDCaXg/vZymEf0UC9dUEU1nf0LdgVhuB0EqB5hF5BzpgwtfS8xVGTG76z M17CUidWL8pHSbH5y+IXTVQNOyjTLdxlW1KcYr1sVJstZ2GND4nmSQTWsNoyGeekgd2K wHAcceSsjPJ0ZN6EmhFsuNZciYCP22cvIczgVRFu3CaqVnBKeift2YC9YMcSMaFEunSO 4KaP+VY/iVa8mpPvHWlOw9s+h2bp+/H2Hg1TdCXv6zk4rUZcwnhI2j1RdsZe51RpttMC sxEgUuBDz2uKl526MaQy/juHtWyjdc++TDnRVWJzaYvirUAPJzbI/k73N++yrDXnPs9Z ddGw== X-Gm-Message-State: AN3rC/7FwoRP5PfnzUb7MNGN4gv5riRmLatdwSV7wxisRA7pkvVFZz7E 83a1rsOkz9IYvVh8AZ8= X-Received: by 10.107.32.6 with SMTP id g6mr14958431iog.67.1493829426964; Wed, 03 May 2017 09:37:06 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id f16sm2626237itc.29.2017.05.03.09.37.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 May 2017 09:37:06 -0700 (PDT) Subject: Re: old snapshot install images? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A5582B7B-850F-468B-851A-0D178CDA9FFE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170503163424.GA18325@mail.michaelwlucas.com> Date: Wed, 3 May 2017 09:37:04 -0700 Cc: current@freebsd.org, Toomas Soome Message-Id: <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> To: "Michael W. Lucas" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:37:08 -0000 --Apple-Mail=_A5582B7B-850F-468B-851A-0D178CDA9FFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 3, 2017, at 09:34, Michael W. Lucas = wrote: >=20 > On Wed, May 03, 2017 at 01:01:10AM -0700, Ngie Cooper wrote: >> Hi Michael! >> - What sources are you using/revision are you at? >=20 > Using r311461 amd64 install memstick at the moment. Uname says built > "Thu Jan 5 22:46:38 UTC 2017=E2=80=9D Ok. What version were you going to? >> - Are your drives the 512 byte/sector or 4kB/sector variety? >=20 > They all claim to be 512 byte/sector. FWIW. ;-) Ok. I was curious because there has been a period of time when = 512b/sector disks have been broken and vice versa. I=E2=80=99m going to operate under the impression that one of tsoome=E2=80= =99s recent changes to zfsboot fixed things (there was some breakage = over the past couple months based on posts to current@ and svn-src-*@), = but I can=E2=80=99t count on it 100%. HTH, -Ngie --Apple-Mail=_A5582B7B-850F-468B-851A-0D178CDA9FFE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZCgcxAAoJEPWDqSZpMIYVCDMP/2cPPNhUve6QXR9uakuad5NB eTF2EWEqhD957gjUX1lmAhUrX3w3loqpuTRTezPYk7hnVZHX2Qz0MOGa0AIRhEq7 I8t2A5+QT06mZFLc76qsZP/oOXU/9gI5G+ZXS/eqxPm1rU0tgzle9P69gvg5lk6L jfscDc5U+sjk/2J1ua6NvWEeZ8/8UwcG6uGAp1PWnRmxtg5lVJaPMkCaPMyMwS7V lP2pgjBl9NC/Ni8fdZDhMQVMC4UAaOcm3xiTsy463rSXzGI+poUL/cXaFq36/Haa 02XPc0itC404k3kGscmYD3V47+DbwesXSc9vvmvonjIRmYUL0x5l3dygSGMeFkWr F2OjBZY4QR+9Um33XC0IZPkDQNTga8OwIvaNOXRPLDOXMQmg3VsBgXsDzTURaHEo plepqwFRl9kxd4gYe06yQtYidSjrsvJGA3zqC17mKQGnhTjUGzl+eMYq90pdZSPK a/aMXjr+A+IThW0DnbCf1qvEwiTVqfwhcEcqxWehkwJZdwPs74QHHwyYGe6DFFzj dyowpmmllM6VOV11gemkdaiPa7wLA1nKrvnZ3WrINsh95l5X8Ei8E1dX/K5OT8qu DRcj0XAxOzZ0ewYIxGabWdoCx+t1LdR4GJI3ywIxntnbunzb4woo9WE7qrr67SIg aNVio+SfFmXLxqdOHJqZ =u0gV -----END PGP SIGNATURE----- --Apple-Mail=_A5582B7B-850F-468B-851A-0D178CDA9FFE-- From owner-freebsd-current@freebsd.org Wed May 3 16:41:52 2017 Return-Path: Delivered-To: freebsd-current@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 9DE17D5C362 for ; Wed, 3 May 2017 16:41:52 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.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 84F0715F0 for ; Wed, 3 May 2017 16:41:52 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id 844FDD5C361; Wed, 3 May 2017 16:41:52 +0000 (UTC) Delivered-To: current@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 83FD3D5C360 for ; Wed, 3 May 2017 16:41:52 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 490C315ED for ; Wed, 3 May 2017 16:41:52 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v43GfoFZ018383; Wed, 3 May 2017 12:41:50 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v43GfoFI018382; Wed, 3 May 2017 12:41:50 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 3 May 2017 12:41:50 -0400 From: "Michael W. Lucas" To: "Ngie Cooper (yaneurabeya)" Cc: current@freebsd.org, Toomas Soome Subject: Re: old snapshot install images? Message-ID: <20170503164150.GB18325@mail.michaelwlucas.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Wed, 03 May 2017 12:41:51 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:41:52 -0000 On Wed, May 03, 2017 at 09:37:04AM -0700, Ngie Cooper (yaneurabeya) wrote: > Ok. I was curious because there has been a period of time when 512b/sector disks have been broken and vice versa. > > I’m going to operate under the impression that one of tsoome’s recent changes to zfsboot fixed things (there was some breakage over the past couple months based on posts to current@ and svn-src-*@), but I can’t count on it 100%. The most recent installer snapshot has the exact same problem. Every installer snapshot on the FTP site has the exact same problem. I've gotten some installer snapshots from October and from mid-2015. Trying those. My goal is to find out when the problem appeared and include the time window in the PR. ==ml -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Wed May 3 16:52:12 2017 Return-Path: Delivered-To: freebsd-current@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 35F2DD5C6AB for ; Wed, 3 May 2017 16:52:12 +0000 (UTC) (envelope-from yaneurabeya@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 11BF01E14 for ; Wed, 3 May 2017 16:52:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 110F0D5C6AA; Wed, 3 May 2017 16:52:12 +0000 (UTC) Delivered-To: current@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 1082DD5C6A9 for ; Wed, 3 May 2017 16:52:12 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 CB3861E13 for ; Wed, 3 May 2017 16:52:11 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-io0-x244.google.com with SMTP id x86so36028385ioe.3 for ; Wed, 03 May 2017 09:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJRCfN7erOERsiYvw5EewWqwz9D2zIU5kQ6Qj34n0/c=; b=qnwtltUSlV/XGac5GUCR7pZo8CLrem8Lzi6aGGYaPm5kNu4kBwcqn0GkDWT6InjgSj H6vVGq3PQBgNVMbD6YwWykBNF7h6ctGt1kQ55DFvehPtoBaG+D5219QU1JR0VEGow5td jm2k/ElbQP+v7d3cYllB1xB7vjvv2bXne+7ocUebSRDQxQle53gPkt1wvS23cTLxvfVb AS5lsgJnD5+kzyL8dt0iPVMYYD8qhZonmapspHVnRTn+1mlmKTh/j6iZeeTSFNa+fgXx n+hmF/44toan0BFaOyL+taffJerpfLGAKonqLZdkNZ2920Ee0w8kqjDGzJlaEhyg+Tee Ev3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJRCfN7erOERsiYvw5EewWqwz9D2zIU5kQ6Qj34n0/c=; b=qcxjhwReHzDVYRwkjMuBQ9ygqzLOVsFk0lN2nJ+2z7xvMBKPGIsvEh7MjlsEOHq6LZ UOmzGHMMweQDMteK0klbmtogyC3b3ae3rwoGGaLaNn/m6EGYzOnWZwNucBjSAwGM8Ubc ow/j+dlzXYjca3EWkXu64pshcdHRlcelrO32/RQHpD0YSU44ocuObvjZaYSTBHrXFKCy DQxUvb7sE0UeTLhy9f50S3FWh0sYpSVeCfGapH2c6PX4DLRYfLQymhO7iMEC5I4tWca4 5wn7QT8ZDmpLUf14z62ZkzX/SQxl2/ilqjay/vtTQfKs6RdjHPsmXBfrSr8TGNpguyRt ro4Q== X-Gm-Message-State: AN3rC/4O1jvPlEuL3xFZOC5hi+fLZY9gcOWZwlFndSV3XKsecUWv+sru /3QyPmQsaZIw3z5ofnA= X-Received: by 10.107.24.132 with SMTP id 126mr2963944ioy.118.1493830330978; Wed, 03 May 2017 09:52:10 -0700 (PDT) Received: from [192.168.20.13] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id l136sm2724764itb.15.2017.05.03.09.52.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2017 09:52:10 -0700 (PDT) Content-Type: text/plain; charset=cp932 Mime-Version: 1.0 (1.0) Subject: Re: old snapshot install images? From: Ngie Cooper X-Mailer: iPhone Mail (14E304) In-Reply-To: <20170503164150.GB18325@mail.michaelwlucas.com> Date: Wed, 3 May 2017 09:52:09 -0700 Cc: current@freebsd.org, Toomas Soome Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> To: "Michael W. Lucas" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:52:12 -0000 > On May 3, 2017, at 09:41, Michael W. Lucas wro= te: >=20 >> On Wed, May 03, 2017 at 09:37:04AM -0700, Ngie Cooper (yaneurabeya) wrote= : >> Ok. I was curious because there has been a period of time when 512b/secto= r disks have been broken and vice versa. >>=20 >> I=81fm going to operate under the impression that one of tsoome=81fs rece= nt changes to zfsboot fixed things (there was some breakage over the past co= uple months based on posts to current@ and svn-src-*@), but I can=81ft count= on it 100%. >=20 >=20 > The most recent installer snapshot has the exact same problem. >=20 > Every installer snapshot on the FTP site has the exact same problem. >=20 > I've gotten some installer snapshots from October and from > mid-2015. Trying those. >=20 > My goal is to find out when the problem appeared and include the time > window in the PR. Ok. How big is your freebsd-boot partition? Thanks, -Ngie >=20 >=20 > --=20 > Michael W. Lucas Twitter @mwlauthor=20 > nonfiction: https://www.michaelwlucas.com/ > fiction: https://www.michaelwarrenlucas.com/ > blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Wed May 3 17:30:30 2017 Return-Path: Delivered-To: freebsd-current@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 C22D7D5C20F for ; Wed, 3 May 2017 17:30:30 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB6EBD4B for ; Wed, 3 May 2017 17:30:30 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [10.44.135.177] (nat-192-187-90-116.nat.tribpub.com [192.187.90.116]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id b2094294 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Wed, 3 May 2017 10:30:29 -0700 (PDT) Subject: Re: regression suspend/resume on Lenovo T420 To: freebsd-current@freebsd.org References: <20170429115017.GA98553@freebsd-t420.fritz.box> From: Pete Wright Message-ID: Date: Wed, 3 May 2017 10:30:28 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:30:30 -0000 On 05/01/2017 14:31, Adrian Chadd wrote: > There were lots of commits that could break things. :-) > > > Can you compile up some intermediary versions between 315141 and > r317559 to find which commit range broke things? That'll make chasing > it down much quicker! > > Thanks! > Hey Adrian - I was looking through the drm-next commit logs and was wondering if this commit could be the root cause of the issues i'm seeing? https://github.com/FreeBSDDesktop/freebsd-base-graphics/commit/2750ce9b17ee373b6d46e6d15d21d2e6c63f6d4d my hardware is a Kabylake Dell Inspiron 2in1. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Wed May 3 17:39:42 2017 Return-Path: Delivered-To: freebsd-current@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 95BD9D5C5D9 for ; Wed, 3 May 2017 17:39:42 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC281611 for ; Wed, 3 May 2017 17:39:42 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id 78C42D5C5D8; Wed, 3 May 2017 17:39:42 +0000 (UTC) Delivered-To: current@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 786E8D5C5D7 for ; Wed, 3 May 2017 17:39:42 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 403591610 for ; Wed, 3 May 2017 17:39:41 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v43HddXa018565; Wed, 3 May 2017 13:39:39 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v43HddD7018564; Wed, 3 May 2017 13:39:39 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 3 May 2017 13:39:39 -0400 From: "Michael W. Lucas" To: Ngie Cooper Cc: current@freebsd.org, Toomas Soome Subject: Re: old snapshot install images? Message-ID: <20170503173939.GA18468@mail.michaelwlucas.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Wed, 03 May 2017 13:39:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:39:42 -0000 On Wed, May 03, 2017 at 09:52:09AM -0700, Ngie Cooper wrote: > Ok. How big is your freebsd-boot partition? The size created by the installer. ;) I've run another install, this one with the r317181 snapshot (20 April.) gpart show ada4 shows this (hand-copied) 40 125045344 ada4 GPT (60G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 120848384 3 freebsd-zfs (58G) 125044736 648 - free - (324K) ada5 is identical. It's a two-satadom mirror. I used the guided install, had it blow the disks away. ==ml -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Wed May 3 17:45:51 2017 Return-Path: Delivered-To: freebsd-current@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 67574D5C83C for ; Wed, 3 May 2017 17:45:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3F88E1BBE for ; Wed, 3 May 2017 17:45:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3BFC8D5C83A; Wed, 3 May 2017 17:45:51 +0000 (UTC) Delivered-To: current@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 3B9A8D5C839 for ; Wed, 3 May 2017 17:45:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 F21ED1BBD for ; Wed, 3 May 2017 17:45:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-io0-x243.google.com with SMTP id v34so3175379iov.2 for ; Wed, 03 May 2017 10:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ztRYUXZVS4b7xC2S4CFCstZipQ5O5JgUsgLRwfDQ2qY=; b=POlnhC7UDfvnfvX7/C2jdAmETRi21aNIgfdZQLjbkEiOR97A0P7hXXW7WHKm1AFUb4 4C1+Fs3GmmB8mQUEyOxrPhzAfBCfW5ITLqanVlaiitjJc9o6cfRcilUWhDVwLGyLY0zM in5WFwzSMLGgl1hnBmjDz0tboc5EddLbi4shPhOO1XKxCgZkAHdT0M2oobLPGDAbbNIZ KjVpj/nEPVMiTTaXYkDosxwCq41qZmzbrAYowIhu2euhOzraPe4FjivRjmlMquT0v/Vz 8Osn9BQWLVBahkabVyfuAOPSwI+1OleWpveSCZXj2LwOqFyAB5hnRrI9HdDYMotg8D5r +qgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ztRYUXZVS4b7xC2S4CFCstZipQ5O5JgUsgLRwfDQ2qY=; b=d6b81kj8p8PqHhdcjZmgJ4a+YB0ZYD2f6B46S7ggDtw00UESl7L4/DrUpaIYHn5CvA D4B67BFcZL6zNGSZoQHNmQ90+m/F53EpvJMIWsMpkQW/GkhnEM0uHY60Qyg7Kq7MldHa yC79G4pkM8LJOKMGUMxUJ7jNwkMj2YLRK+HvjTXZz2coKZ9NNDJF1hm4pZMPPKt1L0i+ ZIpqloO6L6zak3NXsy5Ax9lLkVqov6cVzEC+u3Ayaz44hQCGWmEWEfP6sCFvYWbdcnD4 PI8teGa2CfkgxX3vqdL5XieuTolMtPXLxuuNHVWlQFXUr+gcYbLxYtQ4oAyIVywv+h4H Qs3g== X-Gm-Message-State: AN3rC/4zgVPJoW7AlktpWzkrnbZntHDPqhqQ9kryUMWEfbXqTSyDm6CR dW9xSLls5x25DQ== X-Received: by 10.107.10.24 with SMTP id u24mr4794403ioi.82.1493833550402; Wed, 03 May 2017 10:45:50 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id o73sm703869ioi.42.2017.05.03.10.45.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 May 2017 10:45:49 -0700 (PDT) Subject: Re: old snapshot install images? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_44A24597-0D0F-4AE8-B9A9-4D2F2AED28E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <20170503173939.GA18468@mail.michaelwlucas.com> Date: Wed, 3 May 2017 10:45:48 -0700 Cc: current@freebsd.org, Toomas Soome Message-Id: <889C032E-D491-4CA9-B67A-D49AB12A8594@gmail.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> <20170503173939.GA18468@mail.michaelwlucas.com> To: "Michael W. Lucas" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 17:45:51 -0000 --Apple-Mail=_44A24597-0D0F-4AE8-B9A9-4D2F2AED28E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 3, 2017, at 10:39, Michael W. Lucas = wrote: >=20 > On Wed, May 03, 2017 at 09:52:09AM -0700, Ngie Cooper wrote: >> Ok. How big is your freebsd-boot partition? >=20 > The size created by the installer. ;) >=20 > I've run another install, this one with the r317181 snapshot (20 > April.) >=20 > gpart show ada4 shows this (hand-copied) >=20 > 40 125045344 ada4 GPT (60G) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 120848384 3 freebsd-zfs (58G) > 125044736 648 - free - (324K) >=20 > ada5 is identical. It's a two-satadom mirror. >=20 > I used the guided install, had it blow the disks away. Ok. You aren=E2=80=99t afflicted by the =E2=80=9Cfreebsd-boot=E2=80=9D = partition is too small issue that many legacy users will have to suffer = with coming from 8.x/9.x. Cheers! -Ngie --Apple-Mail=_44A24597-0D0F-4AE8-B9A9-4D2F2AED28E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZChdMAAoJEPWDqSZpMIYVdSEP/icp5/x7d/AqTXQ8riYM0YsY +ZD/32nEBvaSz8FG0PDbMH3Ne2zntLPJMLk2wWf3aJI7CKBHuMnVy6v92p22QnHU p9pVU9Q7KCJK6XIJxMS8MxtyRU+5F8K6tQ+GgfKmEBzF/skrzvP3M1o40Co2YW15 DTprhzhCY/O6oRVmRIOKYOtGuun67hsXia+VDQz2CyuV71lZBSTmmcF3BPculvgP 1TdjHLBmgGaQwVuHKw7AZMujnXrVtBxZCR2ueCxE0GzRhM2tOijsAVhBB55XHb+x C/haOg88VPcOCS1AstHb9rI2xUP2kTNPRCl2yOOi/VXm30WS0CdNn2rWG5qV9uZa sj0WDl3zFWQIag+r7ZHYDEAjV/wCieHa0025go7rIf/Lv3TSeaIKYRZ49/bLBkJQ Fq0bG7mmaAD+nGshMSlMpuH53gEEvhVery9zDm2jrgZMA5odqn3t2QF3tHDDtE1u Fr+DnVfrpYFGfIjMjiFiZZngloMZNQpKPhZ3fldNXzatWc43Nd5iGSRBRakU1iV8 d9LJV6uUqjiFMmXXqAIeWaoo9lJYENOlWcJoUwVgn+ef2U+DOiNexi39H+Xbh1YZ t+LU8syL1oxeoC/9HaSmmI3xC0ZYJYVODJ74rWkIptER6qvElSTgckt6mDzyXZ/i nA8ODiz5o2GHa/cJ1nJ3 =QWZe -----END PGP SIGNATURE----- --Apple-Mail=_44A24597-0D0F-4AE8-B9A9-4D2F2AED28E6-- From owner-freebsd-current@freebsd.org Wed May 3 18:03:39 2017 Return-Path: Delivered-To: freebsd-current@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 B481FD5CCF8 for ; Wed, 3 May 2017 18:03:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 954268A8 for ; Wed, 3 May 2017 18:03:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 91E01D5CCF7; Wed, 3 May 2017 18:03:39 +0000 (UTC) Delivered-To: current@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 8FD23D5CCF6 for ; Wed, 3 May 2017 18:03:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 60B038A7 for ; Wed, 3 May 2017 18:03:39 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPD00N00YZRYO00@st13p35im-asmtp001.me.com> for current@freebsd.org; Wed, 03 May 2017 17:03:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1493831004; bh=PUKFzj/6u3Luy+PHtFNfQ4w16828xvNvCnsipF2Lb80=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=PR9KvnBXds2h25JIRfTgpgvZgxdpRsSgXZ7w90M/TsEmV4YGuFAXTr7wfj3MxsJX6 mTkyEirNyx5Xgt9b6p7eZjTqmzongudGmqjpv0cCwT6BSlZfe8rIUfXAXM81YQBY2d wF+lqfNKBVtHRjoaaw0Df8K861B+YkfpyV5yOgbguVheBPn3/5c6axLmikwZNMzSLR yZ9zjvwg9MyUO624W9ZMfJtestO13Azl1/pTBfelet8b04/yP8HhGnNAlhg21osi9G gIn0Bw6ArIewlDN1+sFnl9sND1zUndYSTLuWAwxEaouW55dC63B7DwLQQB+U0MXKvm fv0Lc9uIHCDkw== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPD002XUZDLE210@st13p35im-asmtp001.me.com>; Wed, 03 May 2017 17:03:24 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-03_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705030309 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: old snapshot install images? From: Toomas Soome In-reply-to: Date: Wed, 03 May 2017 20:03:21 +0300 Cc: "Michael W. Lucas" , current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> To: Ngie Cooper X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:03:39 -0000 > On 3. mai 2017, at 19:52, Ngie Cooper wrote: >=20 >=20 >> On May 3, 2017, at 09:41, Michael W. Lucas = wrote: >>=20 >>> On Wed, May 03, 2017 at 09:37:04AM -0700, Ngie Cooper (yaneurabeya) = wrote: >>> Ok. I was curious because there has been a period of time when = 512b/sector disks have been broken and vice versa. >>>=20 >>> I=E2=80=99m going to operate under the impression that one of = tsoome=E2=80=99s recent changes to zfsboot fixed things (there was some = breakage over the past couple months based on posts to current@ and = svn-src-*@), but I can=E2=80=99t count on it 100%. >>=20 >>=20 >> The most recent installer snapshot has the exact same problem. >>=20 >> Every installer snapshot on the FTP site has the exact same problem. >>=20 >> I've gotten some installer snapshots from October and from >> mid-2015. Trying those. >>=20 >> My goal is to find out when the problem appeared and include the time >> window in the PR. >=20 > Ok. How big is your freebsd-boot partition? > Thanks, > -Ngie There was many issues fixed step by step and some fixes for particular = problem did reveal next one (at least in some systems), and indeed, it = can cause some problems if you are caught in middle of updates. =46rom = my point of view, the most important question is if the current = =E2=80=9Ccurrent=E2=80=9D is ok:) rgds, toomas= From owner-freebsd-current@freebsd.org Wed May 3 18:06:05 2017 Return-Path: Delivered-To: freebsd-current@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 422A1D5CE56 for ; Wed, 3 May 2017 18:06:05 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 28943B19 for ; Wed, 3 May 2017 18:06:05 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id 24E4CD5CE55; Wed, 3 May 2017 18:06:05 +0000 (UTC) Delivered-To: current@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 248E8D5CE54 for ; Wed, 3 May 2017 18:06:05 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 E16B3B16 for ; Wed, 3 May 2017 18:06:04 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v43I62tn018711; Wed, 3 May 2017 14:06:03 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v43I62u8018710; Wed, 3 May 2017 14:06:02 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 3 May 2017 14:06:02 -0400 From: "Michael W. Lucas" To: Toomas Soome Cc: Ngie Cooper , current@freebsd.org Subject: Re: old snapshot install images? Message-ID: <20170503180602.GA18700@mail.michaelwlucas.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Wed, 03 May 2017 14:06:03 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:06:05 -0000 On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote: > There was many issues fixed step by step and some fixes for particular problem did reveal next one (at least in some systems), and indeed, it can cause some problems if you are caught in middle of updates. From my point of view, the most important question is if the current “current†is ok:) Agreed 500%. The latest snapshot is NOT ok. ==ml -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Wed May 3 18:11:10 2017 Return-Path: Delivered-To: freebsd-current@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 EE2FCD5C001 for ; Wed, 3 May 2017 18:11:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CE23E151 for ; Wed, 3 May 2017 18:11:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id CA611D5D000; Wed, 3 May 2017 18:11:10 +0000 (UTC) Delivered-To: current@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 CA046D5CFFF for ; Wed, 3 May 2017 18:11:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 9F427150 for ; Wed, 3 May 2017 18:11:10 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPE003002G3ZR00@st13p35im-asmtp001.me.com> for current@freebsd.org; Wed, 03 May 2017 18:11:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1493835068; bh=2jzuMYoOhJ8Q6FP9ivSVTPgvLIzUQAp4kcyro69ayUU=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=QYkZigyTTm5VfvFDMAlwOdQZuAJ3BkGY7+ArkkrsNyr4h0cNifNNwe3+tqwvT2zVc EwYlApg38Hnz3Gek284BpRRK/ZYjyeFUbbk4jZ/TP0eJr1s0YrEpHVmpIEtml2kVdR WWp97nUPYJNO20DTJTaWeSTNPOHyf/ExG+s1jnWU7ihx9XQAluDy12EyBijtE/dE3i PnlAsp96bsmo7C0xKd61E9frIulT2PhFfv70Ilx59IW7bbjwrdVdB95JTXfme4tfoj DR4DSHu289p+PAUhPgK39n2GnEo1yFlqdOcmcmrDHuPMI1yrv6c5QxoX/THu3cttcE vqqyN/wneRz6g== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPE00MK72IHXN00@st13p35im-asmtp001.me.com>; Wed, 03 May 2017 18:11:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-03_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705030325 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: old snapshot install images? From: Toomas Soome In-reply-to: <20170503180602.GA18700@mail.michaelwlucas.com> Date: Wed, 03 May 2017 21:11:05 +0300 Cc: Ngie Cooper , current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <828E5321-056C-4ABC-BBBB-B28CCD1079C9@me.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> <20170503180602.GA18700@mail.michaelwlucas.com> To: "Michael W. Lucas" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:11:11 -0000 > On 3. mai 2017, at 21:06, Michael W. Lucas = wrote: >=20 > On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote: >> There was many issues fixed step by step and some fixes for = particular problem did reveal next one (at least in some systems), and = indeed, it can cause some problems if you are caught in middle of = updates. =46rom my point of view, the most important question is if the = current =E2=80=9Ccurrent=E2=80=9D is ok:) >=20 >=20 > Agreed 500%. >=20 > The latest snapshot is NOT ok. >=20 What is the error there? rgds, toomas From owner-freebsd-current@freebsd.org Wed May 3 18:23:04 2017 Return-Path: Delivered-To: freebsd-current@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 E4590D5C685 for ; Wed, 3 May 2017 18:23:04 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.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 C8E8B28 for ; Wed, 3 May 2017 18:23:04 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id C851ED5C684; Wed, 3 May 2017 18:23:04 +0000 (UTC) Delivered-To: current@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 C800DD5C683 for ; Wed, 3 May 2017 18:23:04 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 710C012 for ; Wed, 3 May 2017 18:23:04 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v43IN1qO018802; Wed, 3 May 2017 14:23:01 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v43IN1fP018801; Wed, 3 May 2017 14:23:01 -0400 (EDT) (envelope-from mwlucas) Date: Wed, 3 May 2017 14:23:01 -0400 From: "Michael W. Lucas" To: Toomas Soome Cc: "Michael W. Lucas" , Ngie Cooper , current@freebsd.org Subject: Re: old snapshot install images? Message-ID: <20170503182301.GA18781@mail.michaelwlucas.com> References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> <20170503180602.GA18700@mail.michaelwlucas.com> <828E5321-056C-4ABC-BBBB-B28CCD1079C9@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <828E5321-056C-4ABC-BBBB-B28CCD1079C9@me.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Wed, 03 May 2017 14:23:02 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:23:05 -0000 On Wed, May 03, 2017 at 09:11:05PM +0300, Toomas Soome wrote: > > > On 3. mai 2017, at 21:06, Michael W. Lucas wrote: > > > > On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote: > >> There was many issues fixed step by step and some fixes for particular problem did reveal next one (at least in some systems), and indeed, it can cause some problems if you are caught in middle of updates. From my point of view, the most important question is if the current “current†is ok:) > > > > > > Agreed 500%. > > > > The latest snapshot is NOT ok. > > > > What is the error there? error 1 error 1 gptzfsboot: error 1 lba 4294967288 gptzfsboot: error 1 lba 1 gptzfsboot: no ZFS pools located, can't boot My first thought was that the BIOS was looking at a different drive, not the SATADOMs, so I disabled booting from all the spinning drives in the BIOS. On a related note: my script at http://www-old.michaelwlucas.com/zm.sh also gives the same error at boot. -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-current@freebsd.org Wed May 3 18:54:11 2017 Return-Path: Delivered-To: freebsd-current@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 82BD0D571A5 for ; Wed, 3 May 2017 18:54:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBB8167F for ; Wed, 3 May 2017 18:54:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5F0DED571A4; Wed, 3 May 2017 18:54:11 +0000 (UTC) Delivered-To: current@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 5EA29D571A0 for ; Wed, 3 May 2017 18:54:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (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 315A0167E for ; Wed, 3 May 2017 18:54:11 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPE0080049UG300@st13p35im-asmtp001.me.com> for current@freebsd.org; Wed, 03 May 2017 18:53:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1493837600; bh=VSeffGjY/RtzhOohTBA8YDj69b5+DX0kN0rzdwbaPgM=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=X9rh6beAdK4hhJhaynd/LOmR3LBZ9PAIhNqknCR6/Z+dNImwzGupL//2MxAh17mjT OPfiKoAnSeynBwE7p9kGu9eq63xcBNLOP7W1AHqgzlYsRveL1NXv3JtHzVT+F3jzZ9 BASJs4I/C/n3TUH+QIWrE2omBWztk641QJIXXEjxpo9ZMHOssTq7sqY0GPGUkLQGps jm8AzmZhigK0vCN8ASeigezLYXN9TnLF3rkV9m1bZoyWtTNUmxfXOLouVkm1aMsCfY zWX4oqDMgIjau/ERK14U8uhQckBMR7IXkGyJ6AFXQGPd75R2teNSC8uASwflbpkSrz X6q9em8YHuCng== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPE00C4R4GUBX50@st13p35im-asmtp001.me.com>; Wed, 03 May 2017 18:53:20 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-03_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705030333 From: Toomas Soome Message-id: <2C0A4513-FDC4-440E-A5DD-E6F15F9F7EF2@me.com> MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: old snapshot install images? Date: Wed, 03 May 2017 21:53:17 +0300 In-reply-to: <20170503182301.GA18781@mail.michaelwlucas.com> Cc: Ngie Cooper , current@freebsd.org To: "Michael W. Lucas" References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> <20170503180602.GA18700@mail.michaelwlucas.com> <828E5321-056C-4ABC-BBBB-B28CCD1079C9@me.com> <20170503182301.GA18781@mail.michaelwlucas.com> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 18:54:11 -0000 > On 3. mai 2017, at 21:23, Michael W. Lucas = wrote: >=20 > On Wed, May 03, 2017 at 09:11:05PM +0300, Toomas Soome wrote: >>=20 >>> On 3. mai 2017, at 21:06, Michael W. Lucas = wrote: >>>=20 >>> On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote: >>>> There was many issues fixed step by step and some fixes for = particular problem did reveal next one (at least in some systems), and = indeed, it can cause some problems if you are caught in middle of = updates. =46rom my point of view, the most important question is if the = current =E2=80=9Ccurrent=E2=80=9D is ok:) >>>=20 >>>=20 >>> Agreed 500%. >>>=20 >>> The latest snapshot is NOT ok. >>>=20 >>=20 >> What is the error there? >=20 >=20 > error 1 > error 1 > gptzfsboot: error 1 lba 4294967288 > gptzfsboot: error 1 lba 1 > gptzfsboot: no ZFS pools located, can't boot >=20 > My first thought was that the BIOS was looking at a different drive, > not the SATADOMs, so I disabled booting from all the spinning drives > in the BIOS. >=20 > On a related note: my script at http://www-old.michaelwlucas.com/zm.sh = > also gives the same error at boot. >=20 well, yea, i know what it is. sigh. Welcome to the x86 hell. error 1 is: Invalid command. And it is resulting firstly from drvsize() = (the lone =E2=80=9Cerror 1=E2=80=9D messages) and then from drvread(). = Now the question is, did you do the install from usb stick or cd, and = has this system booted fbsd from the disk before? The question is up because, the boot2 is only using INT13 extended read = (INT13 EAX=3D0x4200) and INT13 EAX=3D0x4800 to get disk size; if the = read is now getting error but was working before, it is pointing towards = the error from 0x4800 (drvsize) is triggering the error with read - = meaning we should probably attempt the disk reset on error. As an first take on possible fix, I think we need to address the = drvsize() to get size from INT13 0x800 as biosdisk.c bd_int13probe() = does, and reset the disk on error. And if this is not enough, then check = further. However, since you have the system to test with, the testing is all on = you;) So if you are up to the task, poke me in private (mail or irc) and = we can work it out - no need to kill the list with all that noise;) rgds, toomas=20 From owner-freebsd-current@freebsd.org Wed May 3 20:15:15 2017 Return-Path: Delivered-To: freebsd-current@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 57088D5C2AC for ; Wed, 3 May 2017 20:15:15 +0000 (UTC) (envelope-from tsoome@me.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 330D7125B for ; Wed, 3 May 2017 20:15:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2F9A2D5C2AB; Wed, 3 May 2017 20:15:15 +0000 (UTC) Delivered-To: current@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 2D843D5C2A9 for ; Wed, 3 May 2017 20:15:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 E834A125A for ; Wed, 3 May 2017 20:15:14 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPE00D007XVRI00@st13p35im-asmtp002.me.com> for current@freebsd.org; Wed, 03 May 2017 20:14:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1493842489; bh=qKpbPKnRXudINIffLCk16KLz3HxHRl+nCtl22SWzZoo=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=DTpnR+nUoX2MvJ2JnoZGvtT9wJykTGcUBKRjV6QM68bEOcG12rVQYLag+7LLL5vpZ CUFAOp6Cjma8YY2AmTm6YlY0gNa8ypX/VPyr/Gd/WJhh4XYe91Ja2AO0TW4x4NelxA i4rT/wQYvN7Hl5DG9AgKrg6XFWdpoD+L0rJlD3ouwSZ6QtEHa2YPCsgomXyduuO3FS Uq/ApVUK7fGVqbcDgbi7k3ZHaJXs/nctM4PnePIzDiG5a+XkCWfMS3i3B83q2x1igS nvIQ+RWTTkwS5Nl0RK5D7/ev+lbCDMIZYanIQNU4QoiuS7sU/1nJyuI78oHT3Gm1bR 4nUgRyHV9gmBQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPE00BSZ88L5030@st13p35im-asmtp002.me.com>; Wed, 03 May 2017 20:14:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-03_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705030355 From: Toomas Soome Message-id: <12E2AF60-DB90-484B-A62A-38A84FD5F942@me.com> MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: old snapshot install images? Date: Wed, 03 May 2017 23:14:44 +0300 In-reply-to: <2C0A4513-FDC4-440E-A5DD-E6F15F9F7EF2@me.com> Cc: Ngie Cooper , current@freebsd.org To: "Michael W. Lucas" References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> <20170503180602.GA18700@mail.michaelwlucas.com> <828E5321-056C-4ABC-BBBB-B28CCD1079C9@me.com> <20170503182301.GA18781@mail.michaelwlucas.com> <2C0A4513-FDC4-440E-A5DD-E6F15F9F7EF2@me.com> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:15:15 -0000 > On 3. mai 2017, at 21:53, Toomas Soome wrote: >=20 >=20 >> On 3. mai 2017, at 21:23, Michael W. Lucas > wrote: >>=20 >> On Wed, May 03, 2017 at 09:11:05PM +0300, Toomas Soome wrote: >>>=20 >>>> On 3. mai 2017, at 21:06, Michael W. Lucas = > wrote: >>>>=20 >>>> On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote: >>>>> There was many issues fixed step by step and some fixes for = particular problem did reveal next one (at least in some systems), and = indeed, it can cause some problems if you are caught in middle of = updates. =46rom my point of view, the most important question is if the = current =E2=80=9Ccurrent=E2=80=9D is ok:) >>>>=20 >>>>=20 >>>> Agreed 500%. >>>>=20 >>>> The latest snapshot is NOT ok. >>>>=20 >>>=20 >>> What is the error there? >>=20 >>=20 >> error 1 >> error 1 >> gptzfsboot: error 1 lba 4294967288 >> gptzfsboot: error 1 lba 1 >> gptzfsboot: no ZFS pools located, can't boot >>=20 >> My first thought was that the BIOS was looking at a different drive, >> not the SATADOMs, so I disabled booting from all the spinning drives >> in the BIOS. >>=20 >> On a related note: my script at = http://www-old.michaelwlucas.com/zm.sh = >> also gives the same error at boot. >>=20 >=20 > well, yea, i know what it is. sigh. Welcome to the x86 hell. >=20 > error 1 is: Invalid command. And it is resulting firstly from = drvsize() (the lone =E2=80=9Cerror 1=E2=80=9D messages) and then from = drvread(). Now the question is, did you do the install from usb stick or = cd, and has this system booted fbsd from the disk before? >=20 > The question is up because, the boot2 is only using INT13 extended = read (INT13 EAX=3D0x4200) and INT13 EAX=3D0x4800 to get disk size; if = the read is now getting error but was working before, it is pointing = towards the error from 0x4800 (drvsize) is triggering the error with = read - meaning we should probably attempt the disk reset on error. >=20 > As an first take on possible fix, I think we need to address the = drvsize() to get size from INT13 0x800 as biosdisk.c bd_int13probe() = does, and reset the disk on error. And if this is not enough, then check = further. >=20 > However, since you have the system to test with, the testing is all on = you;) So if you are up to the task, poke me in private (mail or irc) and = we can work it out - no need to kill the list with all that noise;) >=20 > rgds, > toomas=20 >=20 FYI: This is the first take on the issue: = https://reviews.freebsd.org/D10591 As this is system specific problem, the testing on that system will be = needed (wont hurt to test on others as well;) Also it is still very = likely we need to extend the drvread as well, but lets have small steps = here. rgds, toomas= From owner-freebsd-current@freebsd.org Wed May 3 20:31:27 2017 Return-Path: Delivered-To: freebsd-current@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 7975AD5CB0F for ; Wed, 3 May 2017 20:31:27 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DEE0D7B for ; Wed, 3 May 2017 20:31:27 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.85 #1) id 1d60vj-0006PE-Ay for freebsd-current@freebsd.org; Wed, 03 May 2017 22:31:23 +0200 Received: from localhost ([::1]:58768 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1d60vi-0006mk-VW for freebsd-current@freebsd.org; Wed, 03 May 2017 22:31:23 +0200 Received: from mx13.freenet.de ([195.4.92.23]:33044) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1d60t7-0003bG-Q1 for freebsd-current@freebsd.org; Wed, 03 May 2017 22:28:41 +0200 Received: from web2.emo.freenet-rz.de ([194.97.107.235]:61684) by mx13.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 587) (Exim 4.85 #1) id 1d60t7-0005DE-Tj for freebsd-current@freebsd.org; Wed, 03 May 2017 22:28:42 +0200 Received: from localhost ([127.0.0.1] helo=emo.freenet.de) by web2.emo.freenet-rz.de with esmtpa (Exim 4.84_2 2 (Panther_1)) id 1d60t7-0004GU-O9 for ; Wed, 03 May 2017 22:28:41 +0200 Date: Wed, 03 May 2017 22:28:41 +0200 From: freebsdnewbie@freenet.de Subject: RE: Re: regression suspend/resume on Lenovo T420 To: freebsd-current X-Priority: 3 MIME-Version: 1.0 X-Abuse: 306382964 / 91.37.76.27 Message-Id: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> User-Agent: freenetMail Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originated-At: 91.37.76.27!41288 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 20:31:27 -0000 =20 > Von: Adrian Chadd=20 > Gesendet: Mo. 01.05.2017 23:31 > An: Manuel St=C3=BChn ,=20 > Kopie: freebsd-current ,=20 > Betreff: Re: regression suspend/resume on Lenovo T420 > > There were lots of commits that could break things. :-) > > > Can you compile up some intermediary versions between 315141 and > r317559 to find which commit range broke things? That'll make chasing > it down much quicker! > I'm following your advice and building some intermediary versions. This wil= l take some time... Nevertheless, I've discovered some things already: 1. It seems to me, that a plain freebsd r315141 does not resume completely. The display is still staying black after resume but the laptop is acces= sible via ssh.=20 2. After installing xorg and starting X on r315141, resume works correctly.= =20 Not having a running X results in not resuming the LCD. 3. setting the value hw.acpi.reset_video=3D1 results in continously resetti= ng the machine. Only pressing the powerbutton for a long period of time di= srupts this cycle. 4. r317559 with X running does not suspend at all. Stopping x and try to su= spend then results in similar behaviour as described in 1. Mit freenetmail sicher kommunizieren!=0A[https://email.freenet.de/emig/inde= x.html?utm_medium=3DText&utm_source=3DFootersatz&utm_campaign=3DFootersatz_= Sicherheit170207&epid=3De9900000699&utm_content=3DText]=0AWir garantieren I= hnen verschl=C3=BCsselte Daten=C3=BCbertragung &=0ADatenspeicherung auf deu= tschen Servern - E-Mail made in Germany!=0A From owner-freebsd-current@freebsd.org Thu May 4 04:58:57 2017 Return-Path: Delivered-To: freebsd-current@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 B305BD5D674 for ; Thu, 4 May 2017 04:58:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-62.reflexion.net [208.70.210.62]) (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 66D8F12AD for ; Thu, 4 May 2017 04:58:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24421 invoked from network); 4 May 2017 04:58:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 May 2017 04:58:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 04 May 2017 00:58:50 -0400 (EDT) Received: (qmail 8901 invoked from network); 4 May 2017 04:58:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 May 2017 04:58:50 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8562EEC91E3; Wed, 3 May 2017 21:58:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r317659 - head/sys/dev/uart [head -r317729 for armv6/7: ns8250_drain : error: implicit declaration of function 'ns8250_drain' is invalid in C99] From: Mark Millard In-Reply-To: Date: Wed, 3 May 2017 21:58:48 -0700 Cc: svn-src-head@freebsd.org, freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <8F563A38-A8E1-4008-9BFA-D71103E9223F@dsl-only.net> References: To: mav@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 04:58:57 -0000 On 2017-May-3, at 4:47 AM, Mark Millard wrote: >> Author: mav >> Date: Mon May 1 19:47:10 2017 >> New Revision: 317659 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/317659 >>=20 >>=20 >> Log: >> Make some UART consoles to not spin wait for data to be sent. >>=20 >> At least with Tx FIFO enabled it shows me ~10% reduction of verbose = boot >> time with serial console at 115200 baud. >>=20 >> Reviewed by: marcel >> MFC after: 2 weeks >>=20 >> Modified: >> head/sys/dev/uart/uart_dev_lpc.c >> head/sys/dev/uart/uart_dev_ns8250.c >=20 >=20 > After building head -r317729 for amd64 and aarch64, > when I tried armv6 I instead got the following failure: >=20 > --- uart_dev_lpc.o --- > /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: implicit = declaration of function 'ns8250_drain' is invalid in C99 = [-Werror,-Wimplicit-function-declaration] > ns8250_drain(bas, UART_DRAIN_TRANSMITTER); > ^ > /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: note: did you mean = 'lpc_ns8250_drain'? > /usr/src/sys/dev/uart/uart_dev_lpc.c:140:1: note: 'lpc_ns8250_drain' = declared here > lpc_ns8250_drain(struct uart_bas *bas, int what) > ^ > /usr/src/sys/dev/uart/uart_dev_lpc.c:892:4: error: this function = declaration is not a prototype [-Werror,-Wstrict-prototypes] > ns8250_drain(bas, UART_DRAIN_TRANSMITTER); > ^ > 2 errors generated. head -r317752 appears to have fixed this: a rebuild based on -r317784 completed for armv6. Thanks. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu May 4 05:01:51 2017 Return-Path: Delivered-To: freebsd-current@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 B34BDD5D9DF for ; Thu, 4 May 2017 05:01:51 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17A63168C for ; Thu, 4 May 2017 05:01:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lm6IP-1dfTa33jaj-00Zd4V for ; Thu, 04 May 2017 07:01:42 +0200 Date: Thu, 4 May 2017 07:01:36 +0200 From: "O. Hartmann" To: freebsd-current Subject: arm64.aarch64: cross-compiling ports on AMD64 possible? Message-ID: <20170504070136.3717d2a7@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:9o77fvM97mcx/DM0P7zrwUdbTAIZN8LxgsVHvu0fwUXX6QaOVyf 88rhGYcKWRxToy74kR+QrjU1Zy1KeWFELIc8n+olVCr0nnYBg0EK7S8eWskp0bJE4n98kV/ 4SkjgSqBkW7WxvdMv76+d7kZlDNHONa8M5+2I8s9HCWSCKLq5sDscJ5MJKl3dcKR9luEKvl sYHXQ4fH6bqufuQxkZ6yA== X-UI-Out-Filterresults: notjunk:1;V01:K0:fpW4d1CR9+o=:vxRot2PwPkO4Jvj8ON9oTQ ROZGL1VsZMcwQTaHgvOypkqXINi0sReVLENHEGJOO4lkI42B/0fuJZ/ANR/bY5xdw2DWkq7AZ 3B/9PO5HRWPIv41saDtV3/ikPaRARUmjYRqWYxhWLi0QyrQrapf1RWd2v39ivLi4zloe4KOyF vXIuaxT4dPNBh7tO1kLVNpQfeyqqZVvOKAjRfC0/NjKcmU0+WjojU08tlveIs/BMVsXQmLrvI /51pcHnCmjOYlctvv4HYgTKp0AMc0Z502zJuA91LWWm9LKJ4kGV+UZLxb5ZgfuoprJInlxR6b YukSxX1l7dsp4mP9lKY26vDheswXMY5BOIZGRg/HplLhNAmDsyG5n+4BWxRaQh1zAfwCJj1mE 32T/esOFwkT5Ddwph806TRU1NAiVRquXmtJEyMwbS5LMra4NSxHmz8JNOD2v4SmmJHG14OGsu bUgQaA1BLrmTG1+yZNjY+R9MH/SS+iCZvuulwUjOw6I205M3HHQUu81xGAe6Ojdmts5ZfTs02 5FLWLbirj1uVtP2QRjUoBt6Ut0wamG+NpNVN8gE6/+doOur/kSDE6PkYitQco7kusxw4T9YxL D7yhCNyjR5KvT5EK9IETHxjH4r0aX4g73c/vSi56HHBSU0QTlno9LlEotDPigTX6IiVnZvm3y E/xlbkLxo4hMge7pnDRnzDIvIhj8w2gUEjrT4wTXfLKFREbrLC3K7BRolrDQOT7lvsIlcqteG IQn1THe+PldHrcoFaAifG9Iz4/q0YPPE9na4IgYvVTo/lU6zlCtqa8gLGvH6ZPVkKtKTSYccm UA19P92 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 05:01:51 -0000 Hello, I've already successfully built a "world" and "kernel" on AMD64 (ath this place a thank-you for the developers!) using the port emulators/qemu_usr_static. /usr/src and /usr/ports are up to date on a daily basis. I use poudriere with a great success (and here again, thank-you towards those who develop and maintain this nice tool!) for building the set of software we need in the department for amd64. Having a jail of arch type aarch64: JAILNAME VERSION ARCH METHOD head-arm64 12.0-CURRENT arm64.aarch64 src=/pool/sources/CURRENT/src (date of jail is 2017-05-03 18:13:59) This jail fails all the time initially starting to build package ports-mgmt/pkg which is the prerequisite and root of all ports due to a configure_error and this configure error states that CC isn't capable of producing working binaries! The host as well as the jail use "WITH_LLD_IS_LD=yes" (which is the default for the ARM64 architecture, so unnecessary to mention) on 12-CURRENT (updated on a daily basis). Well, I live under the impression that the FreeBSD ports folks do compile the ports-tree for ARM64 as the product of fast cross compiling machines. As recommended, I use the LLVM/CLANG/LLD 4.0.0 environment, no GCC. Just for the record. Checking installed ports, I have aarch64-binutils-2.28,1 installed. So, the big question is: what am I doing wrong here or is there a general issue with the ports and crosscompiling on amd64 for aarch64? I'm pretty new to this cross compiling stuff. Please CC me, I'm not a subscriber of this channel. Thanks al lot in advance, Oliver From owner-freebsd-current@freebsd.org Thu May 4 16:18:23 2017 Return-Path: Delivered-To: freebsd-current@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 691CAD5D6F7 for ; Thu, 4 May 2017 16:18:23 +0000 (UTC) (envelope-from tsoome@me.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 44F21F3F for ; Thu, 4 May 2017 16:18:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.ysv.freebsd.org (Postfix) id 415CFD5D6F4; Thu, 4 May 2017 16:18:23 +0000 (UTC) Delivered-To: current@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 40EBED5D6F3 for ; Thu, 4 May 2017 16:18:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 128E9F3E for ; Thu, 4 May 2017 16:18:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPF00I00RPISQ00@st13p35im-asmtp002.me.com> for current@freebsd.org; Thu, 04 May 2017 16:18:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1493914698; bh=/hxAjKCL4RVB9QNzWCpqGh/OE1Z72DdPnSDzu5k/bqw=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=HGXchBVEIbe1DeXnOW8v7PB7mbP4bPcimI18xnEWrB4BxVuwLAJkmmxpoWQd/sP/2 KY0X8rbCJFAJ0zoZKfkmQhnTwCi3q2XkdcT2GpD8nzNPRDfQJS2JLER4AvTuc47MyH 1PCq/qA1PoJnBIAnG5iBUT7K1iBiOf2E8DN+8fTCjg4ikGu7U6viynpdhJqw/zEld0 rBe7XEF1q2kasbOU0kfFf9ajiZMfM0tiW6TQjM8rWBNB24vNSJNOCL4CbvQtb6Fz48 OI+efXVZvzWGv9IaU1laMiQdogPEBAtzfIappawDIdJwED3RMVqzQ+rzSAObH+zh6H dD//z9BFM0lAw== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPF00JMURYF8N40@st13p35im-asmtp002.me.com>; Thu, 04 May 2017 16:18:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-04_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=17 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705040249 From: Toomas Soome Message-id: <46A1AE01-8534-4093-8C95-0ED88209B8FC@me.com> MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: old snapshot install images? Date: Thu, 04 May 2017 19:18:13 +0300 In-reply-to: <2C0A4513-FDC4-440E-A5DD-E6F15F9F7EF2@me.com> Cc: Ngie Cooper , "Michael W. Lucas" To: current@freebsd.org References: <20170502191531.GA10288@mail.michaelwlucas.com> <20170503163424.GA18325@mail.michaelwlucas.com> <80F20120-06DF-4BC9-B317-F77B54512A8F@gmail.com> <20170503164150.GB18325@mail.michaelwlucas.com> <20170503180602.GA18700@mail.michaelwlucas.com> <828E5321-056C-4ABC-BBBB-B28CCD1079C9@me.com> <20170503182301.GA18781@mail.michaelwlucas.com> <2C0A4513-FDC4-440E-A5DD-E6F15F9F7EF2@me.com> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:18:23 -0000 just for an update: apparently this was buggy BIOS and the BIOS update = did fix it. The curious fact was that the gptzfsboot INT13 calls were = failing, while pmbr INT13 calls were doing OK also the usb stick boot = had no apparent problems. rgds, toomas > On 3. mai 2017, at 21:53, Toomas Soome wrote: >=20 >>=20 >> On 3. mai 2017, at 21:23, Michael W. Lucas > wrote: >>=20 >> On Wed, May 03, 2017 at 09:11:05PM +0300, Toomas Soome wrote: >>>=20 >>>> On 3. mai 2017, at 21:06, Michael W. Lucas = wrote: >>>>=20 >>>> On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote: >>>>> There was many issues fixed step by step and some fixes for = particular problem did reveal next one (at least in some systems), and = indeed, it can cause some problems if you are caught in middle of = updates. =46rom my point of view, the most important question is if the = current =E2=80=9Ccurrent=E2=80=9D is ok:) >>>>=20 >>>>=20 >>>> Agreed 500%. >>>>=20 >>>> The latest snapshot is NOT ok. >>>>=20 >>>=20 >>> What is the error there? >>=20 >>=20 >> error 1 >> error 1 >> gptzfsboot: error 1 lba 4294967288 >> gptzfsboot: error 1 lba 1 >> gptzfsboot: no ZFS pools located, can't boot >>=20 >> My first thought was that the BIOS was looking at a different drive, >> not the SATADOMs, so I disabled booting from all the spinning drives >> in the BIOS. >>=20 >> On a related note: my script at = http://www-old.michaelwlucas.com/zm.sh = = > >> also gives the same error at boot. >>=20 >=20 > well, yea, i know what it is. sigh. Welcome to the x86 hell. >=20 > error 1 is: Invalid command. And it is resulting firstly from = drvsize() (the lone =E2=80=9Cerror 1=E2=80=9D messages) and then from = drvread(). Now the question is, did you do the install from usb stick or = cd, and has this system booted fbsd from the disk before? >=20 > The question is up because, the boot2 is only using INT13 extended = read (INT13 EAX=3D0x4200) and INT13 EAX=3D0x4800 to get disk size; if = the read is now getting error but was working before, it is pointing = towards the error from 0x4800 (drvsize) is triggering the error with = read - meaning we should probably attempt the disk reset on error. >=20 > As an first take on possible fix, I think we need to address the = drvsize() to get size from INT13 0x800 as biosdisk.c bd_int13probe() = does, and reset the disk on error. And if this is not enough, then check = further. >=20 > However, since you have the system to test with, the testing is all on = you;) So if you are up to the task, poke me in private (mail or irc) and = we can work it out - no need to kill the list with all that noise;) >=20 > rgds, > toomas=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current = > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Fri May 5 09:31:45 2017 Return-Path: Delivered-To: freebsd-current@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 BE062D5DEB4 for ; Fri, 5 May 2017 09:31:45 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E8D4EE2 for ; Fri, 5 May 2017 09:31:45 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id 99so394083lfu.1 for ; Fri, 05 May 2017 02:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=MT5An1Y0DJdQgIzd38CX+d13cqWDSHMuXkzz2v5TXhU=; b=kPZws3F0N4oSoOlra+oiLdnnVD4L/tCpGUcF9bCZE4DtXBcsi8c2BXGOuykNMxh2CM viDZfx4vcHRYQAdy+povXNh/j8+LUl76LA2v/fSoyrZeSYutvJiIVPrM2OqxMqBjW0hx OOa3qPvcg5+sL9ewIlWnkZEQE3vVMWywz4k5QTMtvusA4jLkkJA/PRnLiQOnJ8LlY4n1 B8h9g1Fe/oS4cAdCFS7OFvievEMCt+HcZ+4J6G1iL8lM4Allcs+blsAUb+4qdcrWccuG x4xsp6xQ1WeITbh+DAHwNQwVpbo08PeMMzmw5n4OU80jyS2zPSn2iGZphEggR64QsipO ZrXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=MT5An1Y0DJdQgIzd38CX+d13cqWDSHMuXkzz2v5TXhU=; b=Ewe06tPV1wHYd0D8B3gDPKbpbxK3i9ths2NjZcm8fSaKgAuqoon9LciZwhK24aIvDH eWv1ZUEPpp38crLwYtTAG2xXWRmItmOsw5jzEcXufhgVYEXHinlXLZYsJLGJep7BywOg Wvfve3755xfJYJaJXjrBQJEpL9fknNWCSyrkxOnhyGzGyW0IkfRuFuBFMQIfGHhjcwMX /9ynGBkYHizmUYADB57oWsqSBQ2Mf0X+zcK8lDpD/r8cNqBdlZQJhGHMYGPRKvATVrC1 odk9brfHrO2beFbGKnJbP8UsxTO9KfzEEQn6WTAblLRc9Uw2SvwWYQaMUucbjdXH0u/i 6MGw== X-Gm-Message-State: AODbwcD1HBicp2ssDlmiDVZ1YWQlStU4DXSrkulZXeDXtbUDbHP93bL8 Mnf7ZXM43Ue/71JSO44= X-Received: by 10.25.181.80 with SMTP id e77mr2115753lff.98.1493976702836; Fri, 05 May 2017 02:31:42 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id 9sm929841ljg.53.2017.05.05.02.31.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 02:31:42 -0700 (PDT) Date: Fri, 5 May 2017 12:31:41 +0300 From: Vladimir Zakharov To: freebsd-current@freebsd.org Subject: make buildworld broken at r317821 (libsysdecode) Message-ID: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 09:31:45 -0000 Hello! Cannot build world due to error in compiling lib/libsysdecode. Cleaning (make clean, make cleandepend and wiping out ccache data) does not help. $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel ... --- all_subdir_lib/libstand --- --- strcat.o --- /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/obj/usr/src/tmp -B/home/obj/usr/src/tmp/usr/bin -O2 -pipe -march=native -I/usr/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -D_STANDALONE -msoft-float -fPIC -mno-red-zone -MD -MF.depend.strcat.o -MTstrcat.o -std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libstand/../libc/string/strcat.c -o strcat.o --- all_subdir_lib/libsysdecode --- ioctl.c:30:10: fatal error: 'cam/cam_compat.h:#define' file not found #include ^~~~~~~~~~~~~~~~~~~~~~~~~~ --- all_subdir_lib/libsmb --- --- nb_net.pico --- /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/obj/usr/src/tmp -B/home/obj/usr/src/tmp/usr/bin -fpic -DPIC -g -O2 -pipe -march=native -DSMB_CFG_FILE=\"/etc/nsmb.conf\" -I/usr/src/contrib/smbfs/include -DHAVE_ICONV=1 -MD -MF.depend.nb_net.pico -MTnb_net.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/contrib/smbfs/lib/smb/nb_net.c -o nb_net.pico --- all_subdir_lib/libstand --- --- strchr.o --- /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/obj/usr/src/tmp -B/home/obj/usr/src/tmp/usr/bin -O2 -pipe -march=native -I/usr/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -D_STANDALONE -msoft-float -fPIC -mno-red-zone -MD -MF.depend.strchr.o -MTstrchr.o -std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libstand/../libc/string/strchr.c -o strchr.o --- all_subdir_lib/libsysdecode --- --- signal.o --- /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/obj/usr/src/tmp -B/home/obj/usr/src/tmp/usr/bin -O2 -pipe -march=native -I/home/obj/usr/src/lib/libsysdecode -I/usr/src/sys -I/usr/src/libexec/rtld-elf -DPF -MD -MF.depend.signal.o -MTsignal.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/lib/libsysdecode/signal.c -o signal.o --- all_subdir_lib/libstand --- --- strcmp.o --- /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/obj/usr/src/tmp -B/home/obj/usr/src/tmp/usr/bin -O2 -pipe -march=native -I/usr/src/lib/libstand -DBZ_NO_STDIO -DBZ_NO_COMPRESS -DHAVE_MEMCPY -I/usr/src/lib/libstand/../../contrib/zlib -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -D_STANDALONE -msoft-float -fPIC -mno-red-zone -MD -MF.depend.strcmp.o -MTstrcmp.o -std=gnu99 -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/libstand/../libc/string/strcmp.c -o strcmp.o --- all_subdir_lib/libsmb --- --- nbns_rq.pico --- /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/home/obj/usr/src/tmp -B/home/obj/usr/src/tmp/usr/bin -fpic -DPIC -g -O2 -pipe -march=native -DSMB_CFG_FILE=\"/etc/nsmb.conf\" -I/usr/src/contrib/smbfs/include -DHAVE_ICONV=1 -MD -MF.depend.nbns_rq.pico -MTnbns_rq.pico -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/contrib/smbfs/lib/smb/nbns_rq.c -o nbns_rq.pico --- all_subdir_lib/libsysdecode --- --- ioctl.o --- 1 error generated. *** [ioctl.o] Error code 1 make[5]: stopped in /usr/src/lib/libsysdecode 1 error make[5]: stopped in /usr/src/lib/libsysdecode *** [all_subdir_lib/libsysdecode] Error code 2 make[4]: stopped in /usr/src/lib --- all_subdir_lib/libstand --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libstand *** [all_subdir_lib/libstand] Error code 2 make[4]: stopped in /usr/src/lib --- all_subdir_lib/libsmb --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/lib/libsmb *** [all_subdir_lib/libsmb] Error code 2 make[4]: stopped in /usr/src/lib 3 errors make[4]: stopped in /usr/src/lib *** [lib__L] Error code 2 make[3]: stopped in /usr/src 1 error make[3]: stopped in /usr/src *** [libraries] Error code 2 make[2]: stopped in /usr/src 1 error make[2]: stopped in /usr/src *** [_libraries] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error $ cat /etc/src.conf WITHOUT_ACCT= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ATM= WITHOUT_AUTHPF= WITHOUT_BLUETOOTH= WITHOUT_BOOTPD= WITHOUT_BSNMP= WITHOUT_CCD= WITHOUT_CROSS_COMPILER= WITHOUT_CTM= WITHOUT_CUSE= WITHOUT_EE= WITHOUT_FDT= WITHOUT_FINGER= WITHOUT_FLOPPY= WITHOUT_FTP= WITHOUT_GDB= WITHOUT_GNU_GREP_COMPAT= WITHOUT_HAST= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_IPFILTER= WITHOUT_ISCSI= WITHOUT_KVM= WITHOUT_LEGACY_CONSOLE= #WITHOUT_LIB32= WITHOUT_LPR= WITHOUT_NDIS= WITHOUT_PC_SYSINSTALL= WITHOUT_PPP= WITHOUT_QUOTAS= WITHOUT_RADIUS_SUPPORT= WITHOUT_RBOOTD= WITHOUT_RCMDS= WITHOUT_SHAREDOCS= # commented out for docproj to build # WITHOUT_SYSCONS= WITHOUT_TALK= WITHOUT_TFTP= WITHOUT_TIMED= # WITHOUT_ZFS= WITH_BSD_GREP= WITH_CCACHE_BUILD= WITH_CLANG_EXTRAS= # WITH_CTF= WITH_DTRACE_TESTS= WITH_SORT_THREADS= WITH_SVN= -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri May 5 11:05:19 2017 Return-Path: Delivered-To: freebsd-current@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 9505CD5FA8E for ; Fri, 5 May 2017 11:05:19 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 5744F17DB for ; Fri, 5 May 2017 11:05:18 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3533920834; Fri, 5 May 2017 07:05:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 05 May 2017 07:05:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=npvK/EZFD6ftJ2eAKr OU0dkqcLrFIss0Y/auqWpnuMM=; b=SsSGCMN9CA6gmaIbHvodmo5dkaPJNXWVW3 ZCtmMOZLT0usWQFS9M186k334ldNDIExTHpF1OaTDIhsYD8nD+qeEu2Z7hyzqbJN m7SBw+k/rd2lt7BBB17qHHo3iwsWQc7/RImrRuq9LnLUH3Cgg77TCPg+M2RRQLu/ DbOlQNsMXcdkFkNFQWQNxcYWwi4UxvZZ13OaVd47PI033EAGweAGMJIYFJtBTz0d DcWtJQmI2P4edc5uL81f+Jq81kbfYgptvBhddO3txZMtuX++LM8nPBsMY3fFBZic OQwRd7KSU4MAkLuw5cMMqY3Om9y8tTPek5WADhEOYT7SS/P/hAiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=npvK/EZFD6ftJ2eAKrOU0dkqcLrFIss0Y/auqWpnuMM=; b=Ou/J3528 9MJgrsRYdcR5hoouBD8EZEtNpc1uGgYz2vrSf6DzMxso+Jf2r0HixmztBrBxYOw2 J/w4T5D41ca1gIwzXqv9cyq4p3SQfdv2zsHx+igRarBf3qoK3kd1n35m1r16xjCd TaYGyCQjeURc9SHsRWEcunpb6vYR4V87zIADXo74LrYYBSEVs2kfUCJ6Xdxm9QHg RVhsePYn7LV75BNbodtwst2BQAGOyBDqPVF5Dagd75RHMiJ3Tro320WNW0oabc13 VXZyhiSXx/rOSBucRmKfs+g+qrUMrM6rUDNriwYzNRsmB7RjSo9UC/RvAqfBcg9t xKs1LWA3IXg9Lg== X-ME-Sender: X-Sasl-enc: WtHxE/1F2MkISAeqqtnxNwaUfWk31ZkET6I4HwiS1ZhX 1493982316 Received: from madcat.local. (220-253-229-104.dyn.iinet.net.au [220.253.229.104]) by mail.messagingengine.com (Postfix) with ESMTPA id A3B502415E; Fri, 5 May 2017 07:05:16 -0400 (EDT) From: Alastair Hogge To: freebsd-current@freebsd.org Cc: Vladimir Zakharov Subject: Re: make buildworld broken at r317821 (libsysdecode) Date: Fri, 05 May 2017 19:05:14 +0800 Message-ID: <8841634.JFc2NN01aG@madcat.local.> User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.10; amd64; ; ) In-Reply-To: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 11:05:19 -0000 On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote: > Hello! > > Cannot build world due to error in compiling lib/libsysdecode. Cleaning > (make clean, make cleandepend and wiping out ccache data) does not help. > > $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel > ... [removed build log & host configs] I am having observing the same problem too. I updated to r317713 & rebooted the r317713 host, then I tried to build a release & it failed with the same errors. I checked out a clean copy of src at r317713 into /tmp, removed /etc/make.conf & /etc/src.conf & tried again, tho, still the same problem. I have also tried buildworld on a r317820 check out, however, this also results in the same failure. My host r317713 was built with: $ cat /etc/make.conf ALWAYS_CHECK_MAKE= YES CPUTYPE?= bdver2 DEFAULT_VERSIONS= bdb=5 gcc=6 linux=c7_64 perl5=5.24 ssl=openssl LOADER_FIREWIRE_SUPPORT= KERNCONF= DIREWOLF MALLOC_PRODUCTION= MODULES_OVERRIDE= linux linux_common linprocfs linuxkpi linux64 QT4_OPTIONS= CUPS TEX_DEFAULT= texlive WITH_NVIDIA_GL= WITH_PKG= devel WITH_SSP_PORTS= $ cat /etc/src.conf WITH_BSD_GREP= WITH_CLANG_EXTRAS= WITH_PIE= #WITH_SORT_THREADS= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ATM= WITHOUT_BOOTPARAMD= WITHOUT_BOOTPD= WITHOUT_BLUETOOTH= WITHOUT_BSNMP= WITHOUT_CDDL= WITHOUT_CTM= WITHOUT_CUSE= WITHOUT_DEBUG_FILES= WITHOUT_FDT= WITHOUT_FLOPPY= WITHOUT_FMTREE= WITHOUT_FREEBSD_UPDATE= WITHOUT_FTP= WITHOUT_GCOV= WITHOUT_GDB= WITHOUT_GPL_DTC= WITHOUT_GROFF= WITHOUT_HAST= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_INFO= WITHOUT_IPFILTER= WITHOUT_ISCSI= WITHOUT_LEGACY_CONSOLE= WITHOUT_LPR= WITHOUT_NDIS= WITHOUT_NTP= WITHOUT_PC_SYSINSTALL= WITHOUT_PF= WITHOUT_PORTSNAP= WITHOUT_PPP= WITHOUT_PROFILE= WITHOUT_RBOOTD= WITHOUT_RCMDS= WITHOUT_RCS= WITHOUT_SENDMAIL= WITHOUT_SHAREDOCS= WITHOUT_SVNLITE= WITHOUT_SYSCONS= WITHOUT_SYSINSTALL= WITHOUT_TEXINFO= WITHOUT_TESTS= WITHOUT_TFTP= WITHOUT_WIRELESS= WITHOUT_WPA_SUPPLICANT_EAPOL= From owner-freebsd-current@freebsd.org Fri May 5 11:15:52 2017 Return-Path: Delivered-To: freebsd-current@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 7185FD5FE98 for ; Fri, 5 May 2017 11:15:52 +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 1F9F11E9C for ; Fri, 5 May 2017 11:15:51 +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 v45BFeA2070239; Fri, 5 May 2017 11:15:40 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v45BFeva070238; Fri, 5 May 2017 04:15:40 -0700 (PDT) (envelope-from david) Date: Fri, 5 May 2017 04:15:40 -0700 From: David Wolfskill To: Alastair Hogge Cc: freebsd-current@freebsd.org, Vladimir Zakharov Subject: Re: make buildworld broken at r317821 (libsysdecode) Message-ID: <20170505111540.GC1168@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Alastair Hogge , freebsd-current@freebsd.org, Vladimir Zakharov References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> <8841634.JFc2NN01aG@madcat.local.> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mw++YNDjOnI+tSxv" Content-Disposition: inline In-Reply-To: <8841634.JFc2NN01aG@madcat.local.> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 11:15:52 -0000 --mw++YNDjOnI+tSxv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 05, 2017 at 07:05:14PM +0800, Alastair Hogge wrote: > On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote: > > Hello! > >=20 > > Cannot build world due to error in compiling lib/libsysdecode. Cleaning > > (make clean, make cleandepend and wiping out ccache data) does not help. > >=20 > > $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel > > ... >=20 > [removed build log & host configs] >=20 > I am having observing the same problem too. I updated to r317713 & reboo= ted =20 > the r317713 host, then I tried to build a release & it failed with the sa= me=20 > errors. > .... I had no issues updating from r317789 to r317824 on my build machine (amd64). Peace, david --=20 David H. Wolfskill david@catwhisker.org Does "conflict of interest" mean anything in the Trump administration? See http://www.catwhisker.org/~david/publickey.gpg for my public key. --mw++YNDjOnI+tSxv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZDF7cXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XE5oH/icv3uZb3KDD/LUsjEwVdPTF 89B4eKIV0raI9I/C2NqbDP+8Rn/QfGG0l7qSw3YIKVtK2liaUC54jllJMHx3mXbE Mqa1tlWVihWoalRh8MiY9BUNwV91DxB6mAWuBEwxz4jP8fz4hHQmmwzLC1ZqthAj Jwx9i2/kJ+e9g/Jw5cLcplUE50G01y/KRnwzxbd/1TlkiEw/tfjYkbKHwXWGoJPJ JLlob4Rnpe9yISU5gjHpjPIvshLh2HZbBFLhV6eTyZJD9kzEdJhZ7VZWxBtXCoe5 RqTBmcRWCEb7T6jKMEASorgL9rhOs1KqQeLzDZAy53fJuJSuNI5PTyZ6sprP/Rg= =EbZh -----END PGP SIGNATURE----- --mw++YNDjOnI+tSxv-- From owner-freebsd-current@freebsd.org Fri May 5 11:56:01 2017 Return-Path: Delivered-To: freebsd-current@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 22190D5EA28 for ; Fri, 5 May 2017 11:56:01 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 96962C28 for ; Fri, 5 May 2017 11:56:00 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id j1so2126818lfh.2 for ; Fri, 05 May 2017 04:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iKeR/M9SJKHV8MkPjYdzfZDYLL4diQLU/+H9iEStLWY=; b=lfP46ej1WlQUMXFArgCin+1Jc/LzQQay6c9Kox/+1vox1jkSHcWe1VM7IaUceC9Vgp tizhzsGMZiXkIdSFNvE7GZN2WzAFrrUT4AdefziwMBxx1lJWYfULVy0AFHQjv0rd1XPk L6NxY82kGEoim78G99eUy4hZbM2Xl5RRpK++gynZ5iGjLdnzFw2GqdtfYHIGBwk22QOz aUdHaQX3muv+PKx2SQt5+AZRqPQM+dn/Hg5O0VtBNqwFxKfnEOHd80l45ukVKCkiE/D0 ULwIp1xWQSrBK691UDjgVegdcVgSt5mHoRTF5BBUBN4ILEbkGNepQzElSFufWL2vBmCK x2zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iKeR/M9SJKHV8MkPjYdzfZDYLL4diQLU/+H9iEStLWY=; b=lkm2wFe0stccOKCQIbnj3s9T3FopMbTQ8vjzaCR2eqHRANA/3vi0NzHXdMYtQGsZJY LjKvfhOyyS+W14v7XxUt+WJxR58THz4NMfx4TOUInSiWSbmc7PFEQ1VFS0IjjrM9gi+q mAxC8qM7/jCiJVWjUCX+vzCGM8/z5T3yz+rn1PoHB/x3AvW5PxBvMqdQjjXXTrC4vF58 TldMmPUNMsePBEoJGvOmAsakFxGs9Qo6po+F11EdGx+m/E+qhf4Sd908pVjJq0pJCl3B pmmbKjNXzCV+9VuAM4ELv7sU/OkgLcLo7lWHf48ZMK2Fe8yx6gBX6yUre7ughYrIJwxn k3gQ== X-Gm-Message-State: AN3rC/79W+AgJP9m0JOAqvomb40UOr5izBqrBLxZABc1AXF7OVJtnGlL seDmcfPtZQsIvRixAzw= X-Received: by 10.25.225.11 with SMTP id y11mr4699111lfg.34.1493985358279; Fri, 05 May 2017 04:55:58 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id g17sm999485ljd.23.2017.05.05.04.55.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 04:55:57 -0700 (PDT) Date: Fri, 5 May 2017 14:55:56 +0300 From: Vladimir Zakharov To: David Wolfskill , Alastair Hogge , freebsd-current@freebsd.org Subject: Re: make buildworld broken at r317821 (libsysdecode) Message-ID: <20170505115556.hk25stipbhuhbdwn@vzakharov> References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> <8841634.JFc2NN01aG@madcat.local.> <20170505111540.GC1168@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170505111540.GC1168@albert.catwhisker.org> X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 11:56:01 -0000 On Fri, May 05, 2017, David Wolfskill wrote: > On Fri, May 05, 2017 at 07:05:14PM +0800, Alastair Hogge wrote: > > On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote: > > > Hello! > > > > > > Cannot build world due to error in compiling lib/libsysdecode. Cleaning > > > (make clean, make cleandepend and wiping out ccache data) does not help. > > > > > > $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel > > > ... > > > > [removed build log & host configs] > > > > I am having observing the same problem too. I updated to r317713 & rebooted > > the r317713 host, then I tried to build a release & it failed with the same > > errors. > > .... I'm trying to update from r317729. Previous update was from r317481. > > I had no issues updating from r317789 to r317824 on my build machine > (amd64). -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Fri May 5 13:39:41 2017 Return-Path: Delivered-To: freebsd-current@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 4B795D54882 for ; Fri, 5 May 2017 13:39:41 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 174819DB; Fri, 5 May 2017 13:39:41 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::4dc9:3418:c61e:b581] (unknown [IPv6:2001:470:7a58:0:4dc9:3418:c61e:b581]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B428E3ACF5; Fri, 5 May 2017 15:39:38 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_ABB39161-4836-4987-AA8E-E0A6E26FF92C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: make buildworld broken at r317821 (libsysdecode) Date: Fri, 5 May 2017 15:39:25 +0200 In-Reply-To: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> Cc: freebsd-current , Ed Maste , Kyle Evans To: Vladimir Zakharov References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 13:39:41 -0000 --Apple-Mail=_ABB39161-4836-4987-AA8E-E0A6E26FF92C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 May 2017, at 11:31, Vladimir Zakharov wrote: > > Cannot build world due to error in compiling lib/libsysdecode. ... > --- all_subdir_lib/libsysdecode --- > ioctl.c:30:10: fatal error: 'cam/cam_compat.h:#define' file not found > #include > ^~~~~~~~~~~~~~~~~~~~~~~~~~ ... > $ cat /etc/src.conf ... > WITH_BSD_GREP= This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode uses a shell script, mkioctls, to generate a ioctl.c file at build time. This script contains the following fragment: ioctl_includes=$( cd $includedir find -H -s * -name '*.h' | \ egrep -v '(.*disk.*|net/pfvar|net/if_pfsync)\.h' | \ xargs egrep -l \ '^#[ ]*define[ ]+[A-Za-z_][A-Za-z0-9_]*[ ]+_IO[^a-z0-9_]' | awk '{printf("#include <%s>\\n", $1)}' ) The idea is that all headers are searched for defines of ioctl macros, which start with _IO. The -l option to egrep is used to print only the matching filenames, not the matched content itself. However, this option seems to be broken in bsdgrep, as it *does* display the matched content: $ gnugrep -l printf /usr/include/stdio.h /usr/include/stdio.h $ bsdgrep -l printf /usr/include/stdio.h #define __SSTR 0x0200 /* this is an sprintf/snprintf string */ /usr/include/stdio.h I did a quick check, and this option seems to have been accidentally broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty pattern"). Ed, Kyle, any idea where the problem might be? -Dimitry [1] https://svnweb.freebsd.org/base?view=revision&revision=317703 --Apple-Mail=_ABB39161-4836-4987-AA8E-E0A6E26FF92C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkMgJoACgkQsF6jCi4glqNu8ACg/a0QYIURmpY723bJxwEkS9xM KJ8An0wvccC+Ef45e+ZhG/fwFyLSbJwM =Vtxa -----END PGP SIGNATURE----- --Apple-Mail=_ABB39161-4836-4987-AA8E-E0A6E26FF92C-- From owner-freebsd-current@freebsd.org Fri May 5 14:31:10 2017 Return-Path: Delivered-To: freebsd-current@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 BF477D5EBDD for ; Fri, 5 May 2017 14:31:10 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0081.outbound.protection.outlook.com [104.47.38.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3988314C3; Fri, 5 May 2017 14:31:09 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F2V3nN/+g0pTZq7kLb2xG8k5YH29EJZOsfGunj95kTM=; b=L1K8FPWzISSm8oU2+H97t/hbH8vH6yxp2/NTW3GJeT3H8Prhe5ZaX3VOMWQ8ppi7pqpIQgujnaWfQsGCQWwDwewE6xWPcppgggyX+xLDJQDk10WYX7pq6c98BhroT/imyNXvik0VcRV6tyDrMq+WlrIVmhCN0MxUmtLEPwGd7IQ= Received: from CO2PR05CA038.namprd05.prod.outlook.com (10.141.241.166) by DM2PR0501MB826.namprd05.prod.outlook.com (10.242.115.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 5 May 2017 14:31:07 +0000 Received: from CY1NAM02FT049.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::208) by CO2PR05CA038.outlook.office365.com (2a01:111:e400:1429::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Fri, 5 May 2017 14:31:07 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by CY1NAM02FT049.mail.protection.outlook.com (10.152.75.83) with Microsoft SMTP Server id 15.1.1047.9 via Frontend Transport; Fri, 5 May 2017 14:31:06 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v45EV65s000769; Fri, 5 May 2017 09:31:06 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id 1A394248322; Fri, 5 May 2017 09:31:06 -0500 (CDT) Received: from mail-wr0-f178.google.com (mail-wr0-f178.google.com [209.85.128.178]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id BCC24248317; Fri, 5 May 2017 09:31:03 -0500 (CDT) Received: by mail-wr0-f178.google.com with SMTP id w50so4959431wrc.0; Fri, 05 May 2017 07:31:03 -0700 (PDT) X-Gm-Message-State: AN3rC/6sTkfKtNPH7xPmBbd5k1mjPGMhyjf5OXUziol3SD9GaFbJAlm0 clXBE4SD9kle3/3qM5UjHRFVEYf+Nw== X-Received: by 10.223.154.100 with SMTP id z91mr31008268wrb.76.1493994662565; Fri, 05 May 2017 07:31:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.63.134 with HTTP; Fri, 5 May 2017 07:31:01 -0700 (PDT) Received: by 10.28.63.134 with HTTP; Fri, 5 May 2017 07:31:01 -0700 (PDT) In-Reply-To: References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> From: Kyle Evans Date: Fri, 5 May 2017 09:31:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: make buildworld broken at r317821 (libsysdecode) To: Dimitry Andric CC: Ed Maste , , "Vladimir Zakharov" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(979002)(39400400002)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(2980300002)(438002)(377454003)(24454002)(189002)(199003)(478600001)(356003)(8676002)(55446002)(84326002)(59536001)(6246003)(229853002)(512874002)(42186005)(106466001)(6306002)(2950100002)(606005)(54906002)(9686003)(236005)(6916009)(246002)(38730400002)(107886003)(110136004)(45336002)(8576002)(90966002)(46386002)(498394004)(53546009)(189998001)(61726006)(75432002)(88552002)(450100002)(98316002)(4326008)(8936002)(5660300001)(61266001)(305945005)(54356999)(63696999)(76176999)(50986999)(2906002)(86362001)(93516999)(7906003)(55456009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0501MB826; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; MLV:ovrnspm; MX:1; A:1; PTR:ip-18-151.net.ksu.edu; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1NAM02FT049; 1:/RYOtAky5r3Q6ukPGMjD6HLXDsgE9g3QpvF2Jj/4+MecFs/8+E88SuOETvedykRuRuETA841x9YrI8/5yGGsbc35zVptApBwMkLKPPdy9DkCb1eDTho9QMEBgrg/fyo22/QLWSOGBfiiv9sxwFdeEhP4zrmi9GknlzjL+Ft7QiPWIXSDt6atMzycMkSQParU+AAsAYe3gCrHf6W4lhqG7VgwbTre04GtOubBAqxo6rW8dtJaW+igMVvslC0GHz/CrcJR1KJcI4iOBo8ZwLe+9tWe5uSbgorCHTSBLWDqqOWhUx4Pr9HWbzVvBFHUtldlHQdWA5h8loMo0+36kNHt6SOlL5FVxpZ4P6Qp89qYe+71AZWz92WkwTtuIxCR5LirUTcSo9B7x6a1uftXLys1gswhe1EXcPRh5VUyhGgLkS00O4pO8WWRsw9y/W3NO0xYwsjOjhiocyW9cm4CvLHOYZeqA4x/ch2Ba3X/uOgtvu/UWQ24Hn0AYvi3uoEtAyyhCh52lAoQRGCmoCgbG+d8Q0xgohm2uWGHkIg0zAKif++Dplk4q4zNxRXCKS5dp6pH X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c547c4b-392b-45bb-0e27-08d493c35dc9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081); SRVR:DM2PR0501MB826; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB826; 3:dTIo00irSo4pJ7ck3MaJ5fjuOvo/u2iCqzfGUt5TcupmOrL7heMS23Zf+XXN0rX0PUYc6CndZYJAx40UYi7yAfUU3toRYtDq+ai6iQ/yZXwfA84gNFDRI4KdhsAWMw3tVftH2vgpwLA2ncAK8OyArYnetBFHjJCkNoPHhhePNTXfdIKIyUqppFx20rT5XmDsuSCtl0iSSC2aWc9RXagh15gHAVSAw1JDcgI4uQzX48gHjk73hg9w0F3J5/fd7iYGfnGfVYrUwAQjB4cc7uIKPX5i4a2xyF+52gT8QPEc7nsYpE/nW/+GkB7yfIxJ60eIFUpTz6uvtZM1X05p8VyMsNw1EN+W+br3o6/E1qvssMPpNXqriX9RLAF/1uW3mGXnY8psZAC0QWdQg3I8XO4/mIcwyANIJg5h6CzI6VShpMoL0yX8cJwcz7RloNLPXLJ3jYaqm7NH5BO8BnxiTTHgsTluamxuzn9HiiiUAyqUqcJAUzbHWMhYJjErYU8VvjzC X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB826; 25:QGll6926Q6ajjeoW1eyVRHamYt5AfApsmVpdJ9cMK5TgUyn35TLAetJnqStsgskGPvr2zb1JygAeXBU5V+2kmpaSdGgKTNBBgkQYbzWaVCR19nj6SgtnEtMjMkWY+mAU3My2Vfc52kENruOWJsHDoRfU+VRJMCsv9gRh4wUoqtBQdjGgaqxhssRGoXVEqia1mBFRfjH3UHH2hbLqOcmjMGr7uU2UbHq9RJTyA0anqx4xVWQ0JvXPCWPkvAlN9Br2r1HA42SB+lGh0GtB6Z5I1V67opF50jhbGJwFiD09tJMQ7fqfMZt4iwyxbO//CzsEYrJc1cvX2hKvhKCSK4fY93M/Xwpfbff+9bNeIpl0euArbJ22PxKkBfpD7b8piOTLLtI/QYBZG87fqW59t8KTqZsiykvff6KK429MbkcV6LK7220/yr5BoA/KNYOLXvLwoDWwzulxd8GkfAmTZaRYt1SdjEAL/wOwljzIq7mtwok=; 31:QuWtG5BdmutVagPRzO/SVM7xUP/FY1+xiD37Dxbn2PD3zboAQRko8ZsaNze9be8RN5+P9tEkW/c+U73TxJ/MTj1QpQCkPZjzhdnRNhAj8aXa8Wb09jr8hIlsYRaDnF1nk2aEuyR8M9cjDHZQecuOlN6K7FyTeOfMARsFeeC7PV5kOeT/np4/2l9gaKKPx6r4yLvGOsMy4I8S5r41Y0CGaF/K6KkAf+1uhapCO+0mLbTEelpa6k8quTE80//n8dfcMVTOsq4ah0VoN/RJfUpyra1Gnixhn7k6PC+l5JDYG0U= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB826; 20:ivEek1PTYd7thzJkpeWzBfEqjyrklzua8JrDLR7oPObVYv4s0eQhQYCWRq4FG+JOvndrALVx9xw7gKkX41r44+DC0UiXL4CmE2Yi8zQEqo8cuOJfICOPJ/bCsBlK5+b/MF++Rth8HgLkFHejU6rhY1D2JEIpcNZ5C3bCp2CK+Bapb+/YQW5qMSTk4vG526AhZRH6+jOiDK17Aqqp/v3Xgrvo/f+kCvkjBI3SBTJBBfDXdx4SF3DwFpjN+ZVyoTUPS0rmYGRw+gwoo1sdPFTyfI0jqmyJKDJxSwrzycKUHHJx55GMVq3eV5Qk+xLstIN+MMTVoSsjvPiRNjxse3d3pmPcYZWBkz0UDvNVZPTMlBEnX41jcFVrPKnfnMNzUpQr2g0+h6u7HHGxUvRvQ9JBNgn0NM3nIAJIBWCnmRs06OdvSWhiFxdnIZJi0gS4XetZc0pBofpIdHJD+n70oBUzZsxgCjY2+FyXrsvouI5aurPepPCwMTVZUyXRpn6rWNaQ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(56005881305849); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(13015025)(13017025)(13018025)(13023025)(13024025)(93006095)(93004095)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:DM2PR0501MB826; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB826; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB826; 4:0IHJCCODM6Qva/h6FLE8ZH/Sarf878Lh/RDBd5ogl?= =?us-ascii?Q?C6M/EPbC9xk+i2wPIFQOjadEN5QEHAellOW+UArXEV/3OcPY2xFSfoYF1+CS?= =?us-ascii?Q?5V/IMW8DWTmDssYhf7nOidtsKHw8K7QpYKKfFHxOJQcudXuuGeaKqCAuxFSV?= =?us-ascii?Q?wcrRdL8o274I4L8d3hLARucEaV6FJl/pIn8GIXLpR/D/yL/5ZVuh1C6/opz1?= =?us-ascii?Q?Yrb2XoLNuSo0zYPsSJ5EVoko7up4Pw8LGV9f7Q7MVzYfPOLtpPkPCWYewcjB?= =?us-ascii?Q?iClGr7+PURRTGo++TwqGH0rHy4AVx/r4JfDYFC/Eq4BmgDrEky29vAZIz5NN?= =?us-ascii?Q?l1hlpnxm91jcQt/MA6s+1ELleZ0Rg9bLCWu2Cz9vOAabB2T7/uy5d3lIQoKI?= =?us-ascii?Q?nBiIrrfbV36Wcp+X7bSlcR4my5FMobWuVxcEpI0fIk6aP6ptEG9fZ5oaiutO?= =?us-ascii?Q?PotEFLdlyYjIfDzv8+R/fziHR1nZvL6wyVMo5L5wv+Z3jPvDUdahkVYsCsX/?= =?us-ascii?Q?tjy4F/6JhiIwaFZHxyFvOZpUXMmyQkYE+T8zV6u8hdQtuaV8IO3ZcRj7ypFu?= =?us-ascii?Q?Pv5x8NkPkoVD2PMgzNlNrqA7HruMTaZVFgXGTo7rx/GgjQskhLqDKntK4iVb?= =?us-ascii?Q?wjXrWHgcCPoCygS1Uq8Oi3pwe8Qf+0sTP7g79hHAtLy3lbsIZPrwhQUmBcO7?= =?us-ascii?Q?KogVhlcQFBd7zfNyZTsZw1RnMotWXMoGtSdJq3OwHpUhSS3VZNHYPVbRn+6S?= =?us-ascii?Q?j2dUs8dYiq+kmjm+VL5fDi+ZIQIgdsIy5SccOYiMWYDaxatPxzWGwgv6gcaZ?= =?us-ascii?Q?dw7HRmhwGLooh2NUX3Nza9y13D2w7M0sKlt0bHF27s2X/fkLgP4NeCfc+Xba?= =?us-ascii?Q?i0O23rTMPGcXQz9MSI3+DxUcX1IOzWNOpP0bM2Oi1s3f60m673CWly4otr3X?= =?us-ascii?Q?+VyWCLCSIlW+0OmSsmHDLOCiU2zj3K+4HHWN70lkA=3D=3D?= X-Forefront-PRVS: 02981BE340 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB826; 23:zGya97JSu0DLhatnERF9Lj65F6nSg7tm/L4zw+kt?= =?us-ascii?Q?/hR2mi51F/TK5QHLld2s0BEkDY/ATyrvBAncNpqJ44tmoF/YeUK/QhJajyfN?= =?us-ascii?Q?NTttaJS/B0MNJhUbDdOssccI4iv9CTsL/gclHzfhoCSGReD1uFwXyBWqtkvj?= =?us-ascii?Q?5uDN9tHG4ykk47s3qCraFCJZp42p3EUj2fSFP9EK5Ed3wDuN2Q7IUDu4ZQ1o?= =?us-ascii?Q?JhAAsqxiH/RlYZ+QBjbdgBRovlpdme0iKP7MM8sPJL1xg/jJKBRSOQIPu/fK?= =?us-ascii?Q?96wYSRw3tFfmhwePtFY7HnvMb3kHbSs15xDYQeQMY+uVl0trKZ/1h5Dr2cCV?= =?us-ascii?Q?mJWey49dNTheFsvv/8Es3F+AsDquNvX3+B2veizYP4OtTCbd8wR3B5xnzYwc?= =?us-ascii?Q?jH8afXmXkGx1QDdCc5Y9AhxcB9ZjevR8SD4S1zKo2HDSfvg/KVpett9RAQb+?= =?us-ascii?Q?T1XY/efCLRuJ7v46NLcW4NwXq8NPICHazKexj2ivFwcrfFybxkObYFfVo2/Q?= =?us-ascii?Q?lsu/vHQW0DBXQ5f97XxzwdJ4Ix65n2+HjGW2OnCqHvw6TeEyxmXnUiV+YsEa?= =?us-ascii?Q?Aj+38UPq5g030xfru/jupDdyYiMu29eXF2Raim0LIO5VaPo26ukqa8iSnmER?= =?us-ascii?Q?DYw9EFH9CoVO5Z6s4Z6Bjlc3Udd3Hvty/nCADYR3hx6bWWHg/Yrjjew8ETdk?= =?us-ascii?Q?wrKvQ1oUvvk2b9C0oHR4yxsGgcSjBrGuaEzwx+M1fWukCCxzkjiuPmpVY8KY?= =?us-ascii?Q?IqikoXd80iw3burYTJDovj0bkNxSWVKsrwIX9wjY4LSdEYdX/1a7o2ZvsjXg?= =?us-ascii?Q?LRmKibZq0c444oqsuBjzIz7wkbCW2zhygJQt9+SLu8cr78rw3yPvp1uMO7yd?= =?us-ascii?Q?TzvUoUYcMhhBY5x2o0RBfUniK/SKr/ReCSHAHYv+iH+CyhGT2krPQIFeCHFV?= =?us-ascii?Q?BWk5A9Dcv77tuqHXCepqi3o4cHwY0Ts69b9AIEW1EiVAQ21nXQePkbJSdsAx?= =?us-ascii?Q?QmR251NmW1T7iz7+OzwhbAN20+0qdUiAZPpykf2uDIW+GR43uDXxyEIjtH5x?= =?us-ascii?Q?SRvM09KNUi/RUOLjEvQOQ58XZpNx/O713+wUtTyAfszrDehNVRK986g+HrZe?= =?us-ascii?Q?IyYIXMQetb0EkwpowrejllbNfugfSUIE0GhNgE+DV/E3i9Ajh6WgWokITzC7?= =?us-ascii?Q?dD917K6qn78l688I2zdA2Ex9UDyOfRfwNlMG2RuUVj93hYnD3Uafgrv/NnXs?= =?us-ascii?Q?gmuyc4YGWxk2F18N6uCwZTuFYBzvsjY20qGbEkE/RKA7pwSR99YcuSHiWyVh?= =?us-ascii?Q?ZxGORB9XPehpms9U+8uP0zcKr3FVTQfJLfgKoTxK1CW2uxlM5Z3jvbpeSeRQ?= =?us-ascii?Q?yUli9KBl2XQ8SNbes6Frq6TgziVTlXaeAVbg7xaUqPdEXxT+yOW8hAiihHHp?= =?us-ascii?Q?h+B+pY5x2wk0tLYMe2bUka38o9vEvfpb+/34iQP4wwZgx9Nmmq4zKCqIw2/3?= =?us-ascii?Q?rsLcrqFps+tas+nGFFPHGD9YovqZYW/g+GHdBLFy+bcs3wmVnFKbuWit?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB826; 6:6BlUuTk2GuJcVwquq49QP1Y1jxbazQoMzoiAURzxK+6PzZVrKJyiUrxFzCP8TO+zVggEFYQZvfNYa/e++uSE1Gn6Ap4WTp7z7VHgZzr+aZEe1tmB9/e3nC8ZSDHVdqp9vw4t4556wfy5yzVfJCDIBwRqvaPrFyIX0kbaDDeBaFkS6zJrKiwttUANK+pGR8L/WLI46v2sqdv/tK60bRn14f9qsIh5XcWYqyQO9lD/og1+EHvk0fw2QPxlw90pZCUuJzHomSU86yOnuAwT5wooRLKtOBMlpt7xmv2g4QtYlIghzzBoOxy+pw1A878IIXCvDUB8CoseFvAbZq+zDaLN6qmp6U+5CyZJB877Ok55o+MAVHlIqO2GY4hg2hmd2twTXwhPd/zc1tyg0+kg5C90oZuIujiJmVSWKL2XU5u5ui1DHmHhGsj3YfzNgUIizbS24V9c/8EeCewRlir+gQSJ69eG2okd4EPc1ptXGcONFAgM4ns8oZ6tkXKIDn6BQM64XyBdINqkvaz0hUd0LU0Aug==; 5:9aEEjZc7AecIcUXAHj4bydZbAGrPrkCvNAvvlSrYiui00Cc7l8p1/feSrrBzxSlUbJXIJG4N2aJ4ZsPh0Oq93+5aoYuTdsHasDn4moeKaAHXpV3i4fV89eZEixYvVzBc8bqEwSP1PCUX+aVoJYGWlw==; 24:z9x6ABFCbEQqHF9/h62Nmz2tvGXKK5UyyEjNKl7smSt0k0CXUvLaLrkf6sZoY8S6gUhS246rgA/PFbt2nW7ZTYA4KmrRlbqniuErVPS2Zig= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB826; 7:6OCFlVIsJYnOF1WHFB9ci4oLiranz72JnpeXyjLIhrWEoFUvj9oQ7X4uOaCCmc+XistqFAWgOww5StSGssN+rLXXk2qWVd3sSz0ZyMy942fu2wgDmr3naEv9Nq7tG2/AkPgRLhkc2T0+JIrDn/nnYKwvK7Uvu6KKv0+0zqIBdR9cxpprolyjRAYoXy7Niq5zWqZibpOsv1FxoNvVTrPC+c0Ae80bPJNzpTU+9wztWvRwFwKbAhG1RVliYnJjGaAqscRkPXOf4AbS5Cw/2jWoVtHpFn1KMMFbz1LfhxNczc8hd8XotM4gyGpRaHBKAN34LvqDPihPLNkizcmE695LOg==; 20:VH1QhnpXJ1sJwJ7JTw5oSNgo9LX1eXN6uUL27RP5fubZ8GAx9qXNZ72Xsc6/wtUpPYMTUCaW9b20Md3gXXDGYhdXr8eAKYdRnegKA2lOvp2WKCbbYKsGYMrC15jT9NBeRmcKHLmYGENyOfN8OneuE/j0CjURCMnLC+AziLt7+sQ= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2017 14:31:06.4945 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB826 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:31:10 -0000 On May 5, 2017 8:39 AM, "Dimitry Andric" wrote: On 5 May 2017, at 11:31, Vladimir Zakharov wrote: > > Cannot build world due to error in compiling lib/libsysdecode. ... > --- all_subdir_lib/libsysdecode --- > ioctl.c:30:10: fatal error: 'cam/cam_compat.h:#define' file not found > #include > ^~~~~~~~~~~~~~~~~~~~~~~~~~ ... > $ cat /etc/src.conf ... > WITH_BSD_GREP= This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode uses a shell script, mkioctls, to generate a ioctl.c file at build time. This script contains the following fragment: ioctl_includes=$( cd $includedir find -H -s * -name '*.h' | \ egrep -v '(.*disk.*|net/pfvar|net/if_pfsync)\.h' | \ xargs egrep -l \ '^#[ ]*define[ ]+[A-Za-z_][A-Za-z0-9_]*[ ]+_IO[^a-z0-9_]' | awk '{printf("#include <%s>\\n", $1)}' ) The idea is that all headers are searched for defines of ioctl macros, which start with _IO. The -l option to egrep is used to print only the matching filenames, not the matched content itself. However, this option seems to be broken in bsdgrep, as it *does* display the matched content: $ gnugrep -l printf /usr/include/stdio.h /usr/include/stdio.h $ bsdgrep -l printf /usr/include/stdio.h #define __SSTR 0x0200 /* this is an sprintf/snprintf string */ /usr/include/stdio.h I did a quick check, and this option seems to have been accidentally broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty pattern"). Ed, Kyle, any idea where the problem might be? -Dimitry [1] https://svnweb.freebsd.org/base?view=revision&revision=317703 Hi, This is addressed by https://reviews.freebsd.org/D10607 Thanks! Kyle Evans From owner-freebsd-current@freebsd.org Fri May 5 17:41:58 2017 Return-Path: Delivered-To: freebsd-current@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 30CAED5F376 for ; Fri, 5 May 2017 17:41:58 +0000 (UTC) (envelope-from kevans91@ksu.edu) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0046.outbound.protection.outlook.com [104.47.33.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EC246F; Fri, 5 May 2017 17:41:56 +0000 (UTC) (envelope-from kevans91@ksu.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ksu.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/Zm/WXP0NIWLvIWGkQYIkkZ4jGz9SBatmz4klHWz5AA=; b=UX4CUdtnS5Mo6LY0WNVLQk+eVYOUaWeIeWQTGfOSEyBxfRyuYDeeogkn6u8bD29qIpIw4PJN1LpF4ZLINWYN25YSpJb8WoXHdbtPM1T5JQ7ouK5ouoYq4QL/sAed18yMeCKM9jEbGo8CRLqyl1dNwo9a25FhNiGbrqzNgyxlrF0= Received: from MWHPR05CA0011.namprd05.prod.outlook.com (10.168.242.149) by DM2PR0501MB825.namprd05.prod.outlook.com (10.242.115.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 5 May 2017 17:41:54 +0000 Received: from SN1NAM02FT019.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::202) by MWHPR05CA0011.outlook.office365.com (2603:10b6:300:59::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7 via Frontend Transport; Fri, 5 May 2017 17:41:54 +0000 Authentication-Results: spf=pass (sender IP is 129.130.18.151) smtp.mailfrom=ksu.edu; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=ksu.edu; Received-SPF: Pass (protection.outlook.com: domain of ksu.edu designates 129.130.18.151 as permitted sender) receiver=protection.outlook.com; client-ip=129.130.18.151; helo=ome-vm-smtp2.campus.ksu.edu; Received: from ome-vm-smtp2.campus.ksu.edu (129.130.18.151) by SN1NAM02FT019.mail.protection.outlook.com (10.152.72.130) with Microsoft SMTP Server id 15.1.1047.9 via Frontend Transport; Fri, 5 May 2017 17:41:52 +0000 Received: from calypso.engg.ksu.edu (calypso.engg.ksu.edu [129.130.43.181]) by ome-vm-smtp2.campus.ksu.edu (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id v45HfpvQ030754; Fri, 5 May 2017 12:41:51 -0500 Received: by calypso.engg.ksu.edu (Postfix, from userid 110) id 9B4EF248324; Fri, 5 May 2017 12:41:51 -0500 (CDT) Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by calypso.engg.ksu.edu (Postfix) with ESMTPA id 48CD624831F; Fri, 5 May 2017 12:41:49 -0500 (CDT) Received: by mail-wr0-f176.google.com with SMTP id l50so7693988wrc.3; Fri, 05 May 2017 10:41:49 -0700 (PDT) X-Gm-Message-State: AN3rC/4UODI5X0tNj7YlZQKXuDvH81ezZNXj/sXfXBK68X96AQuZslxW qtHALWGD7ALb0LiqmUz6qlod3qgI7g== X-Received: by 10.223.151.13 with SMTP id r13mr32411031wrb.6.1494006108144; Fri, 05 May 2017 10:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.63.134 with HTTP; Fri, 5 May 2017 10:41:27 -0700 (PDT) In-Reply-To: References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> From: Kyle Evans Date: Fri, 5 May 2017 12:41:27 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: make buildworld broken at r317821 (libsysdecode) To: Alastair Hogge , Vladimir Zakharov CC: Ed Maste , , "Dimitry Andric" X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:129.130.18.151; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(39860400002)(39840400002)(39400400002)(39850400002)(39410400002)(39450400003)(2980300002)(438002)(69234005)(24454002)(189002)(199003)(51914003)(377454003)(512874002)(90966002)(75432002)(59536001)(478600001)(9896002)(38730400002)(356003)(6246003)(55446002)(42186005)(106466001)(8676002)(8576002)(8936002)(5660300001)(189998001)(46386002)(45336002)(2950100002)(88552002)(305945005)(2906002)(606005)(6306002)(9686003)(63696999)(7906003)(54356999)(450100002)(4326008)(93516999)(236005)(54906002)(86362001)(50986999)(76176999)(53546009)(498394004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0501MB825; H:ome-vm-smtp2.campus.ksu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM02FT019; 1:09r2mK3uidd6mn5OMH/3FhuFFZBkqjk6WGsRhHTFLgTkUYafnX0pXokptp83W2c9tA3Y3WGiiuAV7QOOgq8XWUZBgWSVFAyQ2b8KwgZysjzrJ/o3IslXAH44HjghjoEmQwttEV/nXP2gt9KXTmAiaPwclfok9oN6SSsHs/1nz6ERBvciYRru+VduN4SXs9F1/4H6LQa5Am9UUFVo7ts/cM7+bRsEaYAwHPeQMen7pJRiHhgejpgQdV/5vkp87reuRVcM+iAvmuCuyYjy7DoT3nYZm2K26QC/VraaOjizF+jqoVIpzN6mfQ6t4fTyf1jrgCn+QX0Oa3xdHiiKQuNkw5oLjnowMxz6kdcCOT4KV01DFd4Taz+oU8tWe4q+uN8texcS6UUHMho5SwRlu9ujfFtzixxFOLlEZlFOTCYrdiduPJipe7XLDzbFW3B/HSDuMVPC+AgDmkC3foAjMxArtqEw7ywPl8wTc3QUXAN4y9dYFF2RazUdi+eiuQaL77vG8unCKY5i9sEIhXaOVLJXcLt3qRNkBAIcS6+pC6RiYOdn9XaG0fTM90hSQPsM+4kmO6C+YQl/m+uif50fWuPDkW/zzqkKj4nHteWZJ8wdvJw= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: db58f087-6329-47db-b1c5-08d493de04c7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002)(2017030254075)(201703131423075)(201703031133081); SRVR:DM2PR0501MB825; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB825; 3:p73J2GldRrAI9L8go9qLUqN1qaHX7Vjrz9QuySkCYlSLvoLsaTg8TtOuTxGl+YjS7ydH1DSL8+yFKLYLd+w1SdykjWyL5PDsD6k1CwMvJBZwqkKOE1RFwP5qFgjcTm+eyzF22YIZYuT52xAuC11eFsUYvhNL4XV2JzSqqYSJ/prnnUsP4vagzjNzYK/Okyt2ey2l5X0aQIKrW0YPl2+lW94tbrs84BI/ltSkAZwvbgWsMUH6Ktrxx2sQzxNFUCUm3St/hbz5zoYgcpnZy4EN+tEunR4yiKAOtsdVB8KzmU9sRYTHfUeVEJaRwG49H3GLknkQ2t3HqyNOMKaE0RVQzgEmeToqZIgCpUZApgcnA5BF+4fJ2p4Imy8cB6mP3ByvAHa37fVz/N0Olpaodhp6JX7LItxDOEzZnOPqkFzOwy2cn8Znf/0EOPz4GrjxkPrH+mmHzJDBjfy+pUOnEukw8K+YSsQ16A1VTdaFk7bADsHeF0/SOddcknslyPo+2MxO X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB825; 25:o6Bl9sX12O0COtam4PcbqYdQJYEFYeCu4OwLtjAdmTU/8XEGytkiXeK6neLvNxhh9lHnnsjVMHD1gzAZZJ8C/Y3AkjN707SQt8mMCxceCLoIHp6gbE5WxBc0kTkTleymlYOa8oipiWGom1Mk0qivfz793B+nqlCtqaadSEFiODbwuQl9IagxTJbX953c609xCPX14Z1m/eDMmo9MKzkc0GAyoVk5VYnZp/U92NcayRdOWd7ZsaqTcG6NHrOp0PDpmGNPLKABN/S+3EHzM+y+C8NG4alKhC6JN6jGMcFugTf1Ine6M6urYFQHf9yMv3L+nNvimd9rdkMubeOrDdnMUqWK/eid/mPjTkYI8NEO+eRglVtJYEjlsYQiRRo0UxCfqrLhBColmLj+SqcUd268py7DbRzSWyriIOXpudn9+mvd4kymT5mK7Q/hL8mfzS0Vb7RKzY//teCFvkZx7ohhPg8nDd7/BaWFMUNhXDUJHYM=; 31:u7pyLZDlS3VmC2JkON9aewSXtNAgOZNksfRewAbErMQvYsWggOnJSwtkols09bwGdwRr18o3PtJ1uLxx3d71hg4qnXbC22RqlR5hbPyV3t3TCyFZlaqHJ5iZI5ixS/a7d9loLP7ea3I45uV7oWUwP7Z+3LZ01p6B45RplHSD43TNC49ycq1S9sPG0rrJUXk/CBJgLjENHvtUHypNXZLxtSfE/pkTckNnfzUMS54jek03Nw712Z4R4YR4u7e4/iGlU7RYtnGOgpsAlhTRIwG+8lv312T4kItiZyTI4eNbJxw= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB825; 20:UbbJtYZr8RYNdiE6e5Yzn6ZCOvpSRSMI60PR/V2ceykTgWZhkC63WLV3K//S4af343+488xaM4P8zh3H9lCxiESQXOgUMGAwKtg/fLHTcez8xZWkZtByHu/pvRLKdgcTvP7R36rrxKG+/WCJ25TEUQZeTEWH/XgS3VkU++AXEBxHRQSq4tYnx16pMd1AdDjgwehMiJLVeEWByendx7QiwDqAqC2Gmg3majsPjq2CYlb09yJEU08zOFhxAyDeAKVJiN8wELs9GVEK8c7l++yIhvGodS+hvK3gUJgeQbE1NrVrDL06XyOxdin1qIIgH7HQwVKlXHHfKUe7WRWgkuBMQPataTfcjw0k8409VqZIoKRU1B3I87c0AewvzNSAcBcl3WK6Zf6ySuCwysh27V9QTiD/1wR0AonEM1ZzThrqIc0lNa5G+Pm6pCqakRYNnuCgjUauCmEkH1FzNygA4pKVhsbMe5gYqie2odeUMFZipeal/7WoLTXN3DQVKYLRAa1J X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(56005881305849)(20558992708506)(112903893386949); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(8121501046)(5005006)(13015025)(13023025)(13024025)(13018025)(3002001)(10201501046)(93006095)(93004095)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:DM2PR0501MB825; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB825; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB825; 4:aoPiKk3AFkXTtx+xIOBVWpW3evj+5gnIyBFtb2ZuT?= =?us-ascii?Q?PO3iBT7Jww+yO9dhzGac9TeLC2mZNFe5W5O5iPkmSOut5p/2Rj6PwB5KVOgJ?= =?us-ascii?Q?HBpTGDoaBnebfLBRu/fd+aQaD0Vc5ztnWNITrsPW5LtJAR8OLDvwBH6YStWy?= =?us-ascii?Q?uMdIDcBCW/y/Mk8NWyr3AV5zNjCSdkgqit5c1LCHsVUqMox5gTwYJ7g+ISPT?= =?us-ascii?Q?IPRtniwXa9lrNzDW4SN9MaRYR9VUf6jBNnh7zMo/hZe5dA6AKknLBsYlIefP?= =?us-ascii?Q?mWJZr/otfEe277Du14yyRvDMbQ9r3lN8PKBpxSlCza8NFVQNrXmTFe2tfNYh?= =?us-ascii?Q?VbdJXEdqxCUvb/lf1iQbppoDdWK869usXjOGoK7Aiu8eD1wSqxWaDva696sA?= =?us-ascii?Q?o1OiIxxVEkJ3c5wuSaBF/3G6Qo2858qVUcE/EcsgweF4G6jm2NV5ZHD+rWuJ?= =?us-ascii?Q?HzWjpgo1ctTRdzrcULXdrFUtD+IXwZL1P9ybSl9xwm4hQuUhqcw7o5G8gFdr?= =?us-ascii?Q?glmUIzjTldhybpNnQ0rvG9nStOGhFzzGCu6Wghnr9lP9AeDchvIigqU4GpKp?= =?us-ascii?Q?70zvHQaHyD7SXlsNocdX+e0/LU75iRlQs3LgvESfgjcY0xVJ9ETn11P5gzMF?= =?us-ascii?Q?va3x4L8Cs+m8feag5z8Th7ySgl5NCe5gmxwOlk1or53PBMtZ/1bnMd+8dqS6?= =?us-ascii?Q?ByPE2/rnqO+4H0LvtKBa2d2n6FB9gf6DzOq6H2OeIL4fYfWr+JpZYj5PiMyB?= =?us-ascii?Q?EmK3A1G8sLLQyHAOMtDY8wbOf0tcr+h7IWGfjq6BEyW7sjvQ9Tzivx6nS090?= =?us-ascii?Q?EwwpjQKFST4O+y0XgEAjS/Pc5dwRSXt2cFtm3K7gfHmIks5zWt9qjKYTb10A?= =?us-ascii?Q?lrX0aN34e3YYulYojQwUAeqMyO0+y5Ir40zTZpoTJgYiTspb4kTN/HHgupAO?= =?us-ascii?Q?aTKwlFHA0sdGjN7xyxbv9Lu+3mYL8vBurojm7E2wlBf7PftLjqJhXeqBDK39?= =?us-ascii?Q?1z5PgfCGzri/ZSMeK5Sh51kImBRjDrpw2DTKCfcuFNMIA=3D=3D?= X-Forefront-PRVS: 02981BE340 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0501MB825; 23:UOjgm9jTE4/f+bQxRWYDu4nGhT3WyRlAHJuwLAeH?= =?us-ascii?Q?O5w6/5I6vp6G1IUzN1ZAy80C+/rMK+YzcHWoURo1c9AqhnovdBEPOXNc8zRy?= =?us-ascii?Q?TKU4mnEw3/AIUJclrowInimpRBw/Y5ZwOJc1/8rk05yppYB7BjVyy2y5WCxd?= =?us-ascii?Q?LybPR+lu2FqcrpqUNautwpAln3nDxxaH789aoih4jRiUBjwS93pq50XJ3zxO?= =?us-ascii?Q?1MMTOkYjoSp+fUmj5y8Zwy0LlEe4QMlQRYTpzKRRz3n0U1c3+RML9gvO7xjZ?= =?us-ascii?Q?ur7rZ2PZnSUyRwPgMA1Oy2uzv9oKref9eOi1W75lkW3QMGXFXLxwKJlpR2Ys?= =?us-ascii?Q?LhXT4Lt/JdWsmPHZXjbx2a2eNlSoJ4xN14p4yRihpxxOW4pQcAYBS7awtPe4?= =?us-ascii?Q?GhOsu3kEljjhvFY3Xe/YrxOaDs6bkO/DKJFVBjUZ8EXhFShZv1WgPQCdZTC4?= =?us-ascii?Q?v2wvlGg3W9inhy/aUv/UWpZwGpm4kxqV7mUithqD3AO05aqf7CX3y46krI4G?= =?us-ascii?Q?MM4vShEi3t1sFJjoVzJpsasiosHdQNA0Y4yfaenM3VqZ0pZotqsoi4ZyyLqF?= =?us-ascii?Q?4KcZz4lJbGO8bSjfJ20QWbnFmbe5EZY9+dA2vSz5/4aIIrNCTZxxbFURPqku?= =?us-ascii?Q?oxlJ/iuktzX8NEbdIP89CpcMquxcw1AIp2iJv/91P2fJhTa/Qyp+1SkXysdr?= =?us-ascii?Q?GaWxOi475QVcoX7sd9wOcWwTpVh+egbTbnDlf+WQ15GmGGL/0LihLwG3ao8u?= =?us-ascii?Q?UAf+P1hHm0qAO2Co9AXIOF+s2NtToXIlN6pqh+BXVo0ImT2RY/+4L6ejg6vm?= =?us-ascii?Q?qoFRkUmjFGlLxeMpRvKuo3TRzybcqagCtq02YCVyBUwt2tw7/F7EaMRq+5Lg?= =?us-ascii?Q?wBpm2tpfv67I3iLIFBPOeUXrRQXvr2EY79mWGcBjeHob5z+JVAHwxEYlddl5?= =?us-ascii?Q?BzoxLQdREXeo0fSExvvrVK6RoFcZX5CsUWP/XnTfXR4IrxjcoXbXjS3voWOq?= =?us-ascii?Q?/FdcgBPODvH+xK/VEPS+3x+iwcUu0fnx3r1WRO1vXThacV/848yXCeKw61/V?= =?us-ascii?Q?XpNR74dBgPkJ2l8/jpOG4LLttR4eniPVK7UXLGXnQ3vk23J+3MiL0T63sx1H?= =?us-ascii?Q?0YgnacCNyHEk91X4d8BOveq9Onv5pFSRCX1DbvdQbFaQb4b9lUXWJlHQBNv1?= =?us-ascii?Q?Xf2Nzlv/wPWI1qSIvgsZSedUjPD6nKTRBd9GMdkaFHlrlonqVkLOsKWcCrY+?= =?us-ascii?Q?t4l/QjLv7usmYthf0GVHDTlepfg1peaZx2bDL5eLiR/Gn9b5icFOa099NNAk?= =?us-ascii?Q?bg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB825; 6:qVKkkrNb8ocWbp7ttbJCapBKFOV+tEx4pgy7aeXXVnl5kxHOeCHX9YVmjrFQDLZUofivIfmzzzKJFEF2Sz+ZLl+seYleJRj9pwbdsdlzpyzPgoXhUSjDXw33zLwr40/JIXtRlFvqDXzpjo+8ucwC6jFZP9Pb/omb6A0gfxm5KzoQpmGI5srgHc/PD/RYy95DN5XAiV+2FHLTG91GnJv4bh5AgYZIcTF1/0JvWXmqK+kyb8Qbr9MHqIjZOIvEk5gsyjtnPoh5R+6aeM57qwlUcoa6BaZ1urqYjkdxyIRA8zlTxrpMrjNUADHZ2Bp2V49Mk+noHbdrJmV9S1itHOI6kFBSKZJaJFUof9B81LfWbR5MnNAdAFswJse/jVYuu+7QMP//t2Q80lDdwxZdPuunlZtFO/0geKPM87d78MiwRGyzVAeubMFyn7peg9PhA6kwryHrfqa1g29292U7bm6lpuNwCgBHs7dsn3Bb0UbZ2tSm4Cv4UCXRZVgmqaH8ap3fHjnYvL3UimIUEKSG/kyuQw==; 5:VyYYjwcD1WCr7ObLQo35wxe5McgLga3nhKUe2NWejZeih9gQ5Om4FiGKykrDWaemzxbzbOgbsn/ahfTVDO03fmriaDyfqED9z7TMeckFZLpqk4XlNGZoa0GiOkLzGXcsmQXYJVTr3SV1z7XlKKpt5g==; 24:S51rdOL8Le15ciJkfDQla68we4YAIA2b2aUcY6MUZyXkQfrnlSpaz5DYgxZfZL8bZAoYQpbIbpmLb8RemPK2sdHA/VLhTd/faVW7rLCpjqQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB825; 7:hz7ormzOOw+VSWaXsTgcPH/SfJSq8fRganhn6cmPuZSJ3tcR2OheUQKrRG3dHBwS6IYKFRYB5hwqiL864EIFcRgSozGadFWLGwzYM8U9tOxwpyNdi0sRoJwIMxNz86/NvdLtwcoi8Wx/4iU/cjhPs8v5q6Ykcsvzzam9ahMzCZVogyfztgvyFmv8UOSKGyhCkAstCwJ/Bmugr2eZSzgiC6WWkVJUXakBs/oBdNjmEboY5ZxxQWMYmhopLjVHpzIzLeGPbt1UK/BWV917EMTl9uCcTnP/EV2fWq5ysSb0o1MdvZFCuuMsf91L70nILqOx/HbUppu8rwepyUUBBNXykw==; 20:eQLh0oRoWbALLc8nKa5EEz5+HZntto8VjyPK7JkQlIa9Sz4KaPpV8TVq7NjyUOW9/gXR2ArXF/GlDoFpejmMEdLON9eHJfe19FJflsVbJX8EK+hgPmqZ292QJSJOLAclAcVmDFNkDXecjy2u5WvC5Xb8kBlZNMHHoITp6DL+Gu4= X-OriginatorOrg: ksu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2017 17:41:52.6426 (UTC) X-MS-Exchange-CrossTenant-Id: d9a2fa71-d67d-4cb6-b541-06ccaa8013fb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d9a2fa71-d67d-4cb6-b541-06ccaa8013fb; Ip=[129.130.18.151]; Helo=[ome-vm-smtp2.campus.ksu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB825 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 17:41:58 -0000 On Fri, May 5, 2017 at 9:31 AM, Kyle Evans wrote: > On May 5, 2017 8:39 AM, "Dimitry Andric" wrote: > > > This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode > uses a shell script, mkioctls, to generate a ioctl.c file at build time. > This script contains the following fragment: > > ioctl_includes=$( > cd $includedir > find -H -s * -name '*.h' | \ > egrep -v '(.*disk.*|net/pfvar|net/if_pfsync)\.h' | \ > xargs egrep -l \ > '^#[ ]*define[ ]+[A-Za-z_][A-Za-z0-9_]*[ ]+_IO[^a-z0-9_]' | > awk '{printf("#include <%s>\\n", $1)}' > ) > > The idea is that all headers are searched for defines of ioctl macros, > which start with _IO. The -l option to egrep is used to print only the > matching filenames, not the matched content itself. > > However, this option seems to be broken in bsdgrep, as it *does* display > the matched content: > > $ gnugrep -l printf /usr/include/stdio.h > /usr/include/stdio.h > > $ bsdgrep -l printf /usr/include/stdio.h > #define __SSTR 0x0200 /* this is an sprintf/snprintf string */ > /usr/include/stdio.h > > I did a quick check, and this option seems to have been accidentally > broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty > pattern"). > > Ed, Kyle, any idea where the problem might be? > > -Dimitry > > [1] https://svnweb.freebsd.org/base?view=revision&revision=317703 > > > Hi, > > This is addressed by https://reviews.freebsd.org/D10607 > FYI- This has now been committed as r317842. Apologies for the breakage, and thanks for the reports! From owner-freebsd-current@freebsd.org Fri May 5 18:02:07 2017 Return-Path: Delivered-To: freebsd-current@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 CF085D5F975 for ; Fri, 5 May 2017 18:02:07 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 65831113C; Fri, 5 May 2017 18:02:07 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id k74so11781192qke.1; Fri, 05 May 2017 11:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cP2ykIdhM0UJyLGKu0/EkQZNpFYrdKujRw2tqISGZ2I=; b=ERzyYkf0Z3/QYHuu2guQjq2Kp2DZptpgxzV0kDsHPSGPnWLttLW8g1xU3Y7FMGx4V4 YBMxFa73holnFr5hgNBTByp5TWZ/CSBhcUH5n1xIx2dzHMrqOQs6JFJaQTLcK7ZIUFl1 LRgKyf+tDlupLyjyvl94Rogw+w7L90pRNOjXXqsXTxWowXzDPESvmsj0Vw4jTvX0TTGW sgAZ6wnYrRQBpM4TZy4Y1yNxpcpO51VmH5oJpg3c/FgcNIati550pxCF77GaKqBbghLq phH4+Td65MMXRqiP5Gte/6Vnn8q4fYYBUJF1R7t3vxdKdpKQDBmQ8ACEl6EePnVeJ0Cc s49w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cP2ykIdhM0UJyLGKu0/EkQZNpFYrdKujRw2tqISGZ2I=; b=WCRHk6eSNewwqbR0F0GeqKYrhflOmauPwoN5a/b2PvrZ0U2r/6HVI+igW0PXnj+6DW QUz6Bvf9FTdGw+w/gdSsw+VCbgimO3+vfxzkZiI6jm/nNOQR4wEPNmdwUqM25yvPsV1n Fap9fPpju+fYIRPiVOuZ03F2Vll9a4ogmDCOHH3wFKv66wzgAMFgnfgfHWqJI4iyK4jY H7NhA+i8fGsvZwJ+Hde1cr06qJKBzq1xkrOesTwAN1fccXwheotMhs5wHLNXtlaQDfSf GOggUi02dQR2wAtPtLHa8+sSa5+gfgmffNhPFfSPmCnWWTJEBCWEbqdbAYJz1SQNHPy7 x9Mg== X-Gm-Message-State: AODbwcA/dIiR4SrFwUGM8kmc7X6xVm4CZ35kuznEtk4F2kOAx70hXF/a oEPU2PmS7QXWFsYx3Gq/Xezj0HVS2A== X-Received: by 10.55.42.225 with SMTP id q94mr13734999qkq.178.1494007325297; Fri, 05 May 2017 11:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.163.74 with HTTP; Fri, 5 May 2017 11:02:04 -0700 (PDT) In-Reply-To: References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> From: Andrey Fesenko Date: Fri, 5 May 2017 21:02:04 +0300 Message-ID: Subject: Re: make buildworld broken at r317821 (libsysdecode) To: Kyle Evans Cc: Alastair Hogge , Vladimir Zakharov , Ed Maste , freebsd-current , Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 18:02:07 -0000 On Fri, May 5, 2017 at 8:41 PM, Kyle Evans wrote: > On Fri, May 5, 2017 at 9:31 AM, Kyle Evans wrote: > >> On May 5, 2017 8:39 AM, "Dimitry Andric" wrote: >> >> >> This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode >> uses a shell script, mkioctls, to generate a ioctl.c file at build time. >> This script contains the following fragment: >> >> ioctl_includes=$( >> cd $includedir >> find -H -s * -name '*.h' | \ >> egrep -v '(.*disk.*|net/pfvar|net/if_pfsync)\.h' | \ >> xargs egrep -l \ >> '^#[ ]*define[ ]+[A-Za-z_][A-Za-z0-9_]*[ ]+_IO[^a-z0-9_]' | >> awk '{printf("#include <%s>\\n", $1)}' >> ) >> >> The idea is that all headers are searched for defines of ioctl macros, >> which start with _IO. The -l option to egrep is used to print only the >> matching filenames, not the matched content itself. >> >> However, this option seems to be broken in bsdgrep, as it *does* display >> the matched content: >> >> $ gnugrep -l printf /usr/include/stdio.h >> /usr/include/stdio.h >> >> $ bsdgrep -l printf /usr/include/stdio.h >> #define __SSTR 0x0200 /* this is an sprintf/snprintf string */ >> /usr/include/stdio.h >> >> I did a quick check, and this option seems to have been accidentally >> broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty >> pattern"). >> >> Ed, Kyle, any idea where the problem might be? >> >> -Dimitry >> >> [1] https://svnweb.freebsd.org/base?view=revision&revision=317703 >> >> >> Hi, >> >> This is addressed by https://reviews.freebsd.org/D10607 >> > > FYI- This has now been committed as r317842. Apologies for the breakage, > and thanks for the reports! Build not fixed (but is built slightly, a little more) :( # uname -a FreeBSD des.local 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r317592: Sat Apr 29 21:32:04 MSK 2017 root@des.local:/usr/obj/usr/src/sys/DES amd64 # svnlite info Path: . Working Copy Root Path: /usr/src URL: https://svn0.eu.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.eu.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 317842 Node Kind: directory Schedule: normal Last Changed Author: emaste Last Changed Rev: 317842 Last Changed Date: 2017-05-05 20:35:05 +0300 (Fri, 05 May 2017) # make -j1 buildworld make[1]: "/usr/src/Makefile.inc1" line 160: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. ... ===> lib/clang/libllvmminimal (obj,all,install) /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal created for /usr/src/lib/clang/libllvmminimal /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/Support created for /usr/src/lib/clang/libllvmminimal /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/TableGen created for /usr/src/lib/clang/libllvmminimal c++ -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_M ACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknow n-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -ffunction-sections -fdata-sections -MD -MF.depend.Support_APInt.o -MTSupport/APInt.o -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdli b=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o c++: error: unable to execute command: Segmentation fault (core dumped) c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, p$ eprocessed source, and associated run script. ... From owner-freebsd-current@freebsd.org Fri May 5 19:07:47 2017 Return-Path: Delivered-To: freebsd-current@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 18BB7D5FBA6 for ; Fri, 5 May 2017 19:07:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4A44AA; Fri, 5 May 2017 19:07:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-94-137.dyn.iinet.net.au [58.7.94.137]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v45J7YvB096711 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 May 2017 12:07:38 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current , Toomas Soome From: Julian Elischer Subject: bootcode capable of booting both UFS and ZFS? Message-ID: <963c5c97-2f92-9983-cf90-ec9d59d87bba@freebsd.org> Date: Sat, 6 May 2017 03:07:29 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:07:47 -0000 Subject says it all really, is this an option at this time? we'd like to try boot the main zfs root partition and then fall back to a small UFS based recovery partition.. is that possible? I know we could use grub but I'd prefer keep it in the family. From owner-freebsd-current@freebsd.org Fri May 5 19:16:20 2017 Return-Path: Delivered-To: freebsd-current@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 3FB9FD5FE03 for ; Fri, 5 May 2017 19:16:20 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B5D293E for ; Fri, 5 May 2017 19:16:19 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id k74so13458092qke.1 for ; Fri, 05 May 2017 12:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=GUHnDR9X6swXMs2c1rFxssxxfJnZwdtLmv6Pm9kCY08=; b=J3+6H6I6Kciv8DffpHsPgsqVj4ef7lpB6Rg8LyOUV5+NnkT3MikgaJR4EIL8RopNeI mA+IjtEn4ocSrJCEUZ9kLC/Vbo6PlPzqLwvGJYSaIXd8wk+A/MUT41i1kBB1RF9J9ZMc eTHJB6mF24D6nj7rK64sfFWJSibxhh7Vii0BNfE3mYDvq0FAQnSueAcoc2VdEV7sy2pS kwd+So/6eEs855vlOXb0JDtBuclq2izHGcOSFlDgEQZXb2KS+xQVxAI1VhPYuCPuQl6q 817vhuic/xJuhWVVPa2S/C+TfXL/cg0z/AkAX+PMzBh43MwqsKWw2PWOg+6hGqLAdtNP vXBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GUHnDR9X6swXMs2c1rFxssxxfJnZwdtLmv6Pm9kCY08=; b=X1kF9FPiG6v5/l4+YHv8AGlBKB8yb6iaHCSvE0V28HHMhteD6G+n4xu3sU7trlcn5j 00stkgXKwQDwgQPWAP9pKWzb1Pj68mmqRAhMY6cDDaH/kg1LQqm2OJ3cjedIz4or4MAv I8D6nfH/pQEyLI9GyC7bVsVbdiNKGlhnn2LFW9GpwiHPQU3SXyKTrKS+Yo7ebn1xuSsK QrT7BIxRbyjIbPg7QUlFbZBMkAaneJJdWwNVty63JHjiyHKtEWPxBusbUz7ztc3XVEow aw5OEz2Oslcpa9t67JIGH0Y0vA3WG7+iXzotvICFLeXQfWJ+E5v9R2hYGdtJM180LZRk UDvQ== X-Gm-Message-State: AODbwcDh0FW4N6UxQnn5BOlYoNngJhbSLHp58yZ1xoC85vKpUUYwdwpX jO/jsgPR8WyFZz7BHKA= X-Received: by 10.55.156.11 with SMTP id f11mr15483369qke.8.1494011778844; Fri, 05 May 2017 12:16:18 -0700 (PDT) Received: from mbp-eth.home (201-77-127-155.desktop.com.br. [201.77.127.155]) by smtp.gmail.com with ESMTPSA id j14sm4110529qtj.51.2017.05.05.12.16.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 12:16:18 -0700 (PDT) Sender: Renato Botelho Subject: Re: make check-old warnings To: freebsd-current@FreeBSD.org References: <4635f49c-243f-4efb-7095-c93f0b02d2a0@FreeBSD.org> From: Renato Botelho Message-ID: Date: Fri, 5 May 2017 16:16:15 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4635f49c-243f-4efb-7095-c93f0b02d2a0@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:16:20 -0000 On 21/04/17 15:58, Renato Botelho wrote: > I've updated my laptop to r317256 and started to see some warnings when > I run make check-old: > > ⯠make check-old > make warning: $5bZ� > : No such file or directory. > make warning: $5bZ� > : No such file or directory. >>>> Checking for old files > make warning: $5bZ� > : No such file or directory. This warning is not exclusive from check-old. IF I just run: # make -V ANY_VARIABLE_HERE make warning: $5bZ : No such file of directory VALUE_OF_ANY_VARIABLE_HERE -- Renato Botelho From owner-freebsd-current@freebsd.org Fri May 5 20:01:13 2017 Return-Path: Delivered-To: freebsd-current@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 07DBFD5FC15 for ; Fri, 5 May 2017 20:01:13 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 D2DB876D; Fri, 5 May 2017 20:01:12 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPH00G00WJH8N00@st13p35im-asmtp002.me.com>; Fri, 05 May 2017 20:01:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494014466; bh=wPhizSINz9okwXcyNa4C46OMSt7LGcBg+mDT766qlRw=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=paSru6t7cj/gvfCnSn8Z0FIp3+UJu0nxQzhyiC/lK190mvC4dXJijCrKF16S0SpWK 2MIlghCpReVeXK+z4R0cBiMv4EHiP9duwh9NOY2d7u3rmvyFIIYv3A2bG6arPtHGVo ztc7U8Z+9l2yR0vFlBBUBAow6hFxL0/6vJoVFUqlKUiVfyCpUtLvSy3BdXQ7Sl51/c Xj0OgZMN6+7IVul6yr5jQnJbIAmwSZW5h3eeee8Lfp51qVXNRRUayNFPQ73gndZqqF J6mNvdzM+BdTa3z+DD2s1wqP6SAlBPDj15q3t5DHZH0/4BAg306ZD2N7uwfq2daQk6 gtwDgDp/BUvgw== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPH00355WXRKP30@st13p35im-asmtp002.me.com>; Fri, 05 May 2017 20:01:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-05_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705050189 From: Toomas Soome Message-id: <053354DF-651F-423C-8057-494496DA3B91@me.com> MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: bootcode capable of booting both UFS and ZFS? Date: Fri, 05 May 2017 23:01:03 +0300 In-reply-to: <963c5c97-2f92-9983-cf90-ec9d59d87bba@freebsd.org> Cc: freebsd-current , Toomas Soome To: Julian Elischer References: <963c5c97-2f92-9983-cf90-ec9d59d87bba@freebsd.org> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:01:13 -0000 > On 5. mai 2017, at 22:07, Julian Elischer wrote: >=20 > Subject says it all really, is this an option at this time? >=20 > we'd like to try boot the main zfs root partition and then fall back = to a small UFS based recovery partition.. is that possible? >=20 > I know we could use grub but I'd prefer keep it in the family. >=20 >=20 >=20 it is, sure. but there is an compromise to be made for it. Lets start with what I have done in illumos port, as the idea there is = exactly about having as =E2=80=9Cuniversal=E2=80=9D binaries as possible = (just the binaries are listed below to get the size): -r-xr-xr-x 1 root sys 171008 apr 30 19:55 bootia32.efi -r-xr-xr-x 1 root sys 148992 apr 30 19:55 bootx64.efi -r--r--r-- 1 root sys 1255 okt 25 2015 cdboot -r--r--r-- 1 root sys 154112 apr 30 19:55 gptzfsboot -r-xr-xr-x 1 root sys 482293 mai 2 21:10 loader32.efi -r-xr-xr-x 1 root sys 499218 mai 2 21:10 loader64.efi -r--r--r-- 1 root sys 512 okt 15 2015 pmbr -r--r--r-- 1 root sys 377344 mai 2 21:10 pxeboot -r--r--r-- 1 root sys 376832 mai 2 21:10 zfsloader the loader (bios/efi) is built with full complement - zfs, ufs, dosfs, = cd9660, nfs, tftp + gzipfs. The cdboot is starting zfsloader (thats = trivial string change). The gptzfsboot in illumos case is only built with zfs, dosfs and ufs - = as it has to support only disk based media to read out the loader. Also = I am building gptzfsboot with libstand and libi386 to get as much shared = code as possible - which has both good and bad sides, as usual;) The gptzfsboot size means that with ufs the dedicated boot partition is = needed (freebsd-boot), with zfs the illumos port is always using the = 3.5MB boot area after first 2 labels (as there is no geli, the illumos = does not need dedicated boot partition with zfs). As the freebsd-boot is currently created 512k, the size is not an issue. = Also using common code does allow the generic partition code to be used, = so GPT/MBR/BSD (VTOC in illumos case) labels are not problem. So, even just with cd boot (iso), starting zfsloader (which in fbsd has = built in ufs, zfs etc), you already can get rescue capability.=20 Now, even with just adding ufs reader to gptzfsboot, we can use gpt + = freebsd-boot and ufs root but loading zfsloader on usb image, so it can = be used for both live/install and rescue, because zfsloader itself has = support for all file systems + partition types. I have kept myself a bit off from freebsd gptzfsboot because of simple = reason - the older setups have smaller size for freebsd boot, and not = everyone is necessarily happy about size changes:D also in freebsd case = there is another factor called geli - it most certainly does contribute = some bits, but also needs to be properly addressed on IO call stack (as = we have seen with zfsbootcfg bits). But then again, here also the shared = code can help to reduce the complexity. Yea, the zfsloader/loader*.efi in that listing above is actually built = with framebuffer code and compiled in 8x16 default font (lz4 compressed = ascii+boxdrawing basically - because zfs has lz4, the decompressor is = always there), and ficl 4.1, so thats a bit of difference from fbsd = loader. Also note that we can still build the smaller dedicated blocks like = boot2, just that we can not use those blocks for more universal cases = and eventually those special cases will diminish. rgds, toomas From owner-freebsd-current@freebsd.org Fri May 5 22:19:48 2017 Return-Path: Delivered-To: freebsd-current@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 883F0D5F20E for ; Fri, 5 May 2017 22:19:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 438CB30F; Fri, 5 May 2017 22:19:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::4dc9:3418:c61e:b581] (unknown [IPv6:2001:470:7a58:0:4dc9:3418:c61e:b581]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D8A663AD40; Sat, 6 May 2017 00:19:45 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_43CF8173-904A-4600-B195-12A11C9DDA84"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: make buildworld broken at r317821 (libsysdecode) Date: Sat, 6 May 2017 00:19:37 +0200 In-Reply-To: Cc: Kyle Evans , Alastair Hogge , Vladimir Zakharov , Ed Maste , freebsd-current To: Andrey Fesenko References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:19:48 -0000 --Apple-Mail=_43CF8173-904A-4600-B195-12A11C9DDA84 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 5 May 2017, at 20:02, Andrey Fesenko wrote: > > On Fri, May 5, 2017 at 8:41 PM, Kyle Evans wrote: ... > >> FYI- This has now been committed as r317842. Apologies for the breakage, >> and thanks for the reports! > > Build not fixed (but is built slightly, a little more) :( ... > c++ -O2 -pipe -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD > -D__STDC_LIMIT_M > ACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknow > n-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" > -ffunction-sections -fdata-sections -MD -MF.depend.Support_APInt.o > -MTSupport/APInt.o -Qunused-arguments > -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions > -fno-rtti -stdli > b=libc++ -Wno-c++11-extensions -c > /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o > c++: error: unable to execute command: Segmentation fault (core > dumped) This crash is completely unrelated to the problem the OP was seeing, e.g. the libsysdecode problem with bsdgrep. Is this crash repeatable, and if not, is your hardware OK? -Dimitry --Apple-Mail=_43CF8173-904A-4600-B195-12A11C9DDA84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkM+oEACgkQsF6jCi4glqMI8gCgwwR0AiE1YUOuq72sAyjDQwd3 wQEAoOMYCvHB44amHBNvxZS8QytbXH6f =OTZp -----END PGP SIGNATURE----- --Apple-Mail=_43CF8173-904A-4600-B195-12A11C9DDA84-- From owner-freebsd-current@freebsd.org Fri May 5 23:44:08 2017 Return-Path: Delivered-To: freebsd-current@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 E4920D5F50F for ; Fri, 5 May 2017 23:44:08 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE91143C; Fri, 5 May 2017 23:44:08 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 6mtBdrDJHETFp6mtCduct5; Fri, 05 May 2017 17:44:00 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=tJ8p9aeEuA8A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=Rq28YkthQPViCLEV6AIA:9 a=CjuIK1q_8ugA:10 a=CVUIqAa21KwA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 7C712BC5; Fri, 5 May 2017 16:43:57 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v45Nhsxq082981; Fri, 5 May 2017 16:43:55 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201705052343.v45Nhsxq082981@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Andrey Fesenko cc: Kyle Evans , Alastair Hogge , Vladimir Zakharov , Ed Maste , freebsd-current , Dimitry Andric Subject: Re: make buildworld broken at r317821 (libsysdecode) In-Reply-To: Message from Andrey Fesenko of "Fri, 05 May 2017 21:02:04 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 May 2017 16:43:54 -0700 X-CMAE-Envelope: MS4wfGPGlK5MgRkHVOQBSEtcsHCNrx+DUVlSqObAZU8Z9C4ZH/AXoxc/XIOUZnoty5T8umjZAZLZJFLPQd5RojQTh1qjNWet80wpRyA+3AgIOy2kEio0/sAi 29dgUN4MhXm2Mc59BGoUchGLvDxW3mb3hLptnfeYEy8wlhA76MqRxCL88/n8GGIu8F7KrsEnoPmNO8OafQKfojj5hPtV2uWeNvMtscNvEsPdZzICR1Fll/g8 l7E8FSBQjF5vE8adG3njM3pWeGsZi2GYF4hyj2JB7OfZexq1jyy6Q6r7Vcn9Ipo8ZxBq6cMgLKf7S4P0cik9Txa105e7/4Sd4Vd1cNj3cB4DdUNNVRYHakDZ 1wlBNCQj X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:44:09 -0000 In message , Andrey Fesenko writes: > On Fri, May 5, 2017 at 8:41 PM, Kyle Evans wrote: > > On Fri, May 5, 2017 at 9:31 AM, Kyle Evans wrote: > > > >> On May 5, 2017 8:39 AM, "Dimitry Andric" wrote: > >> > >> > >> This appears to be caused by bsdgrep. :-/ The build for lib/libsysdecode > >> uses a shell script, mkioctls, to generate a ioctl.c file at build time. > >> This script contains the following fragment: > >> > >> ioctl_includes=$( > >> cd $includedir > >> find -H -s * -name '*.h' | \ > >> egrep -v '(.*disk.*|net/pfvar|net/if_pfsync)\.h' | \ > >> xargs egrep -l \ > >> '^#[ ]*define[ ]+[A-Za-z_][A-Za-z0-9_]*[ ]+_IO[^a-z0-9_]' | > >> awk '{printf("#include <%s>\\n", $1)}' > >> ) > >> > >> The idea is that all headers are searched for defines of ioctl macros, > >> which start with _IO. The -l option to egrep is used to print only the > >> matching filenames, not the matched content itself. > >> > >> However, this option seems to be broken in bsdgrep, as it *does* display > >> the matched content: > >> > >> $ gnugrep -l printf /usr/include/stdio.h > >> /usr/include/stdio.h > >> > >> $ bsdgrep -l printf /usr/include/stdio.h > >> #define __SSTR 0x0200 /* this is an sprintf/snprintf string */ > >> /usr/include/stdio.h > >> > >> I did a quick check, and this option seems to have been accidentally > >> broken by r317703 [1] ("bsdgrep: fix -w flag matching with an empty > >> pattern"). > >> > >> Ed, Kyle, any idea where the problem might be? > >> > >> -Dimitry > >> > >> [1] https://svnweb.freebsd.org/base?view=revision&revision=317703 > >> > >> > >> Hi, > >> > >> This is addressed by https://reviews.freebsd.org/D10607 > >> > > > > FYI- This has now been committed as r317842. Apologies for the breakage, > > and thanks for the reports! > > Build not fixed (but is built slightly, a little more) :( > > # uname -a > FreeBSD des.local 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r317592: Sat > Apr 29 21:32:04 MSK 2017 root@des.local:/usr/obj/usr/src/sys/DES > amd64 > > # svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.eu.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.eu.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 317842 > Node Kind: directory > Schedule: normal > Last Changed Author: emaste > Last Changed Rev: 317842 > Last Changed Date: 2017-05-05 20:35:05 +0300 (Fri, 05 May 2017) > > # make -j1 buildworld > make[1]: "/usr/src/Makefile.inc1" > line 160: SYSTEM_COMPILER: Determined that CC=cc matches the source > tree. Not bootstrapping a cross-compiler. > ... > ===> lib/clang/libllvmminimal (obj,all,install) > /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal created for > /usr/src/lib/clang/libllvmminimal > /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/Support created > for /usr/src/lib/clang/libllvmminimal > /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/TableGen created > for /usr/src/lib/clang/libllvmminimal > c++ -O2 -pipe -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD > -D__STDC_LIMIT_M > ACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknow > n-freebsd12.0\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" > -ffunction-sections -fdata-sections -MD -MF.depend.Support_APInt.o > -MTSupport/APInt.o -Qunused-arguments > -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions > -fno-rtti -stdli > b=libc++ -Wno-c++11-extensions -c > /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o > c++: error: unable to execute command: Segmentation fault (core > dumped) > c++: error: clang frontend command failed due to signal (use -v to see > invocation) > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: note: diagnostic msg: PLEASE submit a bug report to > https://bugs.freebsd.org/submit/ and include the crash backtrace, p$ > eprocessed source, and associated run script. > ... You have a bad DIMM. I had this same problem on my laptop but not on my servers downstairs. That suggested that since all four machines were running the same software the difference between them was hardware. Replacing the memory in my laptop made this problem go away. I have a question for you. Do you use ZFS? ZFS exercises memory quite aggressively. I also had this problem when I replaced my UFS filesystems with ZFS on my testbed many moons ago. It even suffered random kernel panics. Here again, replacing the memory resolved the issue. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri May 5 23:52:50 2017 Return-Path: Delivered-To: freebsd-current@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 D7E25D5F786 for ; Fri, 5 May 2017 23:52:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 8DB3219BE; Fri, 5 May 2017 23:52:50 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qt0-x22a.google.com with SMTP id t26so1510143qtg.0; Fri, 05 May 2017 16:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lVtndwq5m2gOxafYx0djncEplBCyOEm1F65sIkaYL9o=; b=vP3sX74n6kZflLfRwrrELYNyPItI2j3f0qJx3jc8fawJtxbmAlywlAsVZvKSSyd4u2 mSZoBrQ+HkQkD2Xtnz4zbJBJOlJzY5iRx4Ht15O9aCxQ/zChq+tNMNZojzLO0sQ2/HcY JrbUdX3JlzUaAqWtcetMbEc1V5MNIxY8fmx/ZcOBTuJ0U/uMF1G18EU4wJ5hx7vfhzr9 a85L/5RGYsxSq9SzJSHTBbDSWiNm5R7PBSyfcR4hFDY9rcFhRawe4YRMJspo1lLSrbdB WxQAnDY+qZ0cj70SMWe8Y2OT0nSzMBS8GpFJ+UgGc3E47g9KpoB8wKPT7pgHD1EzF4eM 2FAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lVtndwq5m2gOxafYx0djncEplBCyOEm1F65sIkaYL9o=; b=rb3O+Kv1zCQOr65r6nPoTrCwXz4YjAWMJro7c9+G59/N36iYcvWd8EzJ90bh5WU2sa Vf/vsAAneC2IVQ88MTx9D3xgolKjzSnX1RYxYE1dHY5oleSSnF0O8qQtwEkV/FQRPFtv bUuRttkF/s4EqjrUj3Bmd+QPf0y3h+Unz+0Ab4AF8/1yW24LtZFq3PHlsKA23S3lGim/ Xr96I+QKZUSPLRXnXu1pyxAqUdxFL7OgNZnUr5jHn07mRPNRrAc9zqldlTfbS67Gzql1 tdsZS7ihxH8/0wkBJ7TmX76q3SzlFgnKwjHEk8MT8iU3G0qnc1f5RsN6e/lImWGn62rp u3AA== X-Gm-Message-State: AODbwcCd2Nx7KyNaYs1QFPfup0E4oETUcvlIML4wKvvHuGVJgb45vLHT 6h0pH8QYQW1/Sh5hhlnUS0+m9oaDRw== X-Received: by 10.200.38.251 with SMTP id 56mr5100140qtp.244.1494028369536; Fri, 05 May 2017 16:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.93.48 with HTTP; Fri, 5 May 2017 16:52:48 -0700 (PDT) In-Reply-To: <201705052343.v45Nhsxq082981@slippy.cwsent.com> References: <201705052343.v45Nhsxq082981@slippy.cwsent.com> From: Ngie Cooper Date: Fri, 5 May 2017 16:52:48 -0700 Message-ID: Subject: Re: make buildworld broken at r317821 (libsysdecode) To: Cy Schubert Cc: Andrey Fesenko , Kyle Evans , Alastair Hogge , Vladimir Zakharov , Ed Maste , freebsd-current , Dimitry Andric Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:52:50 -0000 On Fri, May 5, 2017 at 4:43 PM, Cy Schubert wrote: ... > You have a bad DIMM. I had this same problem on my laptop but not on my > servers downstairs. That suggested that since all four machines were > running the same software the difference between them was hardware. > Replacing the memory in my laptop made this problem go away. > > I have a question for you. Do you use ZFS? ZFS exercises memory quite > aggressively. I also had this problem when I replaced my UFS filesystems > with ZFS on my testbed many moons ago. It even suffered random kernel > panics. Here again, replacing the memory resolved the issue. We need more information first before saying "bad hardware" -- in particular, was the machine overtaxed, were the input files proper, etc? I'm asking because clang has a number of bugs in bugzilla where the host ran out of memory trying to compile things and clang didn't fail gracefully when allocating memory, handling inputs, etc. Thanks, -Ngie From owner-freebsd-current@freebsd.org Fri May 5 23:58:10 2017 Return-Path: Delivered-To: freebsd-current@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 5A85CD5FBAD for ; Fri, 5 May 2017 23:58:10 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 D1B241CC7; Fri, 5 May 2017 23:58:09 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id j1so10967706lfh.2; Fri, 05 May 2017 16:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=r+Tf33XGt8reaUz5k3W4hjEjwVl7+ljIcWvUeqwY2gw=; b=eMUsVzZTOtFritB9z/qpPRI2D/Gr8fG3qAT9y8tOb3/5A/Sd7qNV+e9VBhkQO5QiXz 6b/dNGNX2l4ZqujSTzOoxzwo4wfBxn/M2Vm5zbW4N5QqjsMdQwpbSuIxEWRpz6OPy+nz LS9gai+Sbogjca5b+vAr8JkCt7tyDNTOzYU+4dHWLtYWv9lMZT5BFO6crSczhL0B9Cjh BSceE3FwFmIUWhZjHcSJi1dhgeJq62eoJcgpbHDlZJ7IQBI8giX6vS4H/ZoV0ZC9prj5 LVPJYTOXthuzVhH1b+yDXaG6Cxlrrpwd6gxQDcA56Xw5TqrRMT//EE/OHfAPWa4anOS7 4HBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=r+Tf33XGt8reaUz5k3W4hjEjwVl7+ljIcWvUeqwY2gw=; b=rTEt2G66XaBDWKgHslEVlmkJCx+Sm0ZRVzkcQPxvhUnaOEntvBKB27/qbGtOYaO4t9 94H3vaoTJeMqo+UAFmExvNNdNmzQYkmXpbF1744O9nvs/6g9gtm8yhkMRq1948UMU2Jy h1kfNpdS8OMxGKDhXDWxTPzABMlg+iYQrfSUXRtFK43rba3Ol2iSqeRnRwWplb4Ti2cM TstIwnxNOMeogrqmu6zeIv8ruew7/5Ne6Xna/l7AWPlZtbtRAZdjFrykzhcXvHh/qLTn 3zQ6vhTyrTavbKi4cp12rnuTCYdmm7zshgEo+Lcvc54f0oXexvv+tJalLKNubq8UjQm4 zDHg== X-Gm-Message-State: AODbwcC/eX5cqjcIPywRb4FbHeuMTCX8Pi7lRq7mSDHrh0wMIRMbsorn 3dptJlZfnjdjaA== X-Received: by 10.46.20.67 with SMTP id 3mr598756lju.14.1494028687446; Fri, 05 May 2017 16:58:07 -0700 (PDT) Received: from localhost ([91.246.84.217]) by smtp.gmail.com with ESMTPSA id 97sm633692lfs.9.2017.05.05.16.58.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 16:58:06 -0700 (PDT) Date: Sat, 6 May 2017 02:58:06 +0300 From: Vladimir Zakharov To: Kyle Evans Cc: Alastair Hogge , Ed Maste , freebsd-current@freebsd.org, Dimitry Andric Subject: Re: make buildworld broken at r317821 (libsysdecode) Message-ID: <20170505235806.spbffyx22igu44ak@vzakharov> References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170428 (1.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:58:10 -0000 On Fri, May 05, 2017, Kyle Evans wrote: > FYI- This has now been committed as r317842. Apologies for the > breakage, and thanks for the reports! Fixed for me after reinstalling usr.bin/grep. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Sat May 6 01:21:39 2017 Return-Path: Delivered-To: freebsd-current@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 DA696D5F00D for ; Sat, 6 May 2017 01:21:39 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 A9DF9622 for ; Sat, 6 May 2017 01:21:39 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 811C620AAF; Fri, 5 May 2017 21:21:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 05 May 2017 21:21:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=v2xwMoumDFfGYsInDT ojEwYS4592X3flPi1Nzk7Ryqc=; b=c4MCXB2VQagLsNVAFzYngTrMUToK4mzzi/ 8xZJzlOCPC5Uq3pUmZ8lAq1GrJaP7kAkwFHjkLnO4ZMXiw8YndVzMDJVsuML89Sq 2v4o803EDGrLJEiaWDlAj0kclLUYHSbo8f8M2dB679Pq21TrC7HNCvJBiNlk1lEA dHezQd2sZhFGRgw0cpm+2+7iccGr4VpMOEdg+1iGd9bofmDLW84pXsTx497431o3 WhH82ChOKM+eBhr7zAJfmY7X90oqCT+OpzGmUm2iwlWz12E1NRlUr5ZnlvJeu/si itM9SNKlt3mxba/CVtbbxvsnL9G4Wbt19ou0Gth46RvCLS558BtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=v2xwMoumDFfGYsInDTojEwYS4592X3flPi1Nzk7Ryqc=; b=BdxddfS/ whLxRuDNh6ZYrJPMuICNOtndLqgbKYXs45clfEWGtR9IEzQsJwMVlk+XL8+Ckj8H xiwLmMmBl23XtwBfWpvmHpjWM1OQ8K9tMBCiRCBfBQBVeFmuaYlZuxZgnmzvhgYT RaI07hXnK1ww9rSDRs7h0nwUhqrkdnAb1Lk1DA9d6fH1DgVAobZZ43hJMnasYHWT GJLgm8AxSQcXDrFI94TxN10p6HS9DesqYYzDYLUwecXzliU5u+HYf2nJ2VESYc+d 7GA5593phZ6fLPYUN8FIw+DG3e4H92ZUjHD0b4paUqxigozMPetPlqjxprgLensT OVmzfpGT1lmo8w== X-ME-Sender: X-Sasl-enc: 2IuiTXxnVNk0j2PcpHix6myNPPe5mEOn+T+QRKkPhe+O 1494033698 Received: from madcat.local. (220-253-229-104.dyn.iinet.net.au [220.253.229.104]) by mail.messagingengine.com (Postfix) with ESMTPA id 0B2702415E; Fri, 5 May 2017 21:21:38 -0400 (EDT) From: Alastair Hogge To: freebsd-current@freebsd.org Cc: Kyle Evans Subject: Re: make buildworld broken at r317821 (libsysdecode) Date: Sat, 06 May 2017 09:21:35 +0800 Message-ID: <4998128.39LrbzrdiC@madcat.local.> User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20170505093141.ulbr7j65gxvzyz6i@vzakharov> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 01:21:40 -0000 On Fri, 5 May 2017 12:41:27 PM Kyle Evans wrote: [...] > FYI- This has now been committed as r317842. Apologies for the breakage, > and thanks for the reports! Thanks :-) From owner-freebsd-current@freebsd.org Sat May 6 02:26:44 2017 Return-Path: Delivered-To: freebsd-current@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 0187ED5F0A0 for ; Sat, 6 May 2017 02:26:44 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6A17A53; Sat, 6 May 2017 02:26:43 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id 6pQYds1m1ETFp6pQZdv0Fw; Fri, 05 May 2017 20:26:36 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=tJ8p9aeEuA8A:10 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=G-sPGT8-Nt-BkWzT0vMA:9 a=CjuIK1q_8ugA:10 a=oappaISLdyUA:10 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id E2E111497; Fri, 5 May 2017 19:26:33 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v462QWOw095138; Fri, 5 May 2017 19:26:32 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201705060226.v462QWOw095138@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ngie Cooper cc: Cy Schubert , Andrey Fesenko , Kyle Evans , Alastair Hogge , Vladimir Zakharov , Ed Maste , freebsd-current , Dimitry Andric Subject: Re: make buildworld broken at r317821 (libsysdecode) In-Reply-To: Message from Ngie Cooper of "Fri, 05 May 2017 16:52:48 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 May 2017 19:26:32 -0700 X-CMAE-Envelope: MS4wfMolBlvv0QRGvQRmK9RA2hUfL6xoK7ljcIRUl1+QraXJaV5BW8IhsSqx3kWXb6s7Yy+zZshDOiI21pOA5gyBTE3uX43zwkKQHcFjo7/misRTz5mSwW/T MZPtSzdMYgaeavbUUl8KO0127wve65QYveWfYPMr1re/xjJtNWpz1FxaW3wiatt8QtyHRVHskTRElJKvxgvan0ca5V65UkKLlvctR8wWUe/GQ0jW58GLEHgj 4VGpplzMkVbAXE6H6RQ5W+CMq6GaTAYly7CtfbpGbcpS70iEEye9p4CBKs/gw0DjXm4dKyJB5SYQLE6/CCy8CcNwGsLunf7KpQrrMOl6bfdGv+z5CAXuWW0G +5Wo6dYASmziwnHGONuZV1+pmmU9wVVyi1/+jVO+LKyGodscG+Y= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 02:26:44 -0000 In message , Ngie Cooper writes: > On Fri, May 5, 2017 at 4:43 PM, Cy Schubert wrote: > > ... > > > You have a bad DIMM. I had this same problem on my laptop but not on my > > servers downstairs. That suggested that since all four machines were > > running the same software the difference between them was hardware. > > Replacing the memory in my laptop made this problem go away. > > > > I have a question for you. Do you use ZFS? ZFS exercises memory quite > > aggressively. I also had this problem when I replaced my UFS filesystems > > with ZFS on my testbed many moons ago. It even suffered random kernel > > panics. Here again, replacing the memory resolved the issue. > > We need more information first before saying "bad hardware" -- in > particular, was the machine overtaxed, were the input files proper, > etc? > > I'm asking because clang has a number of bugs in bugzilla where the > host ran out of memory trying to compile things and clang didn't fail > gracefully when allocating memory, handling inputs, etc. Running out of memory (physical RAM + swap) would invoke OOM. That would result in the process receiving SIGKILL not SIGSEGV. Per process limits? Possible. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sat May 6 04:56:01 2017 Return-Path: Delivered-To: freebsd-current@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 131BED60C76 for ; Sat, 6 May 2017 04:56:01 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (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 DAD2C1295 for ; Sat, 6 May 2017 04:56:00 +0000 (UTC) (envelope-from agh@fastmail.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 232A12092B; Sat, 6 May 2017 00:55:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sat, 06 May 2017 00:55:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=6hy9tFbJEaml4nhlCB+CCg2csYg9/Dz8MjJf5cvGK ZE=; b=XnPpLVEqQyG4WD/NN5qtBmK894jXkwz3DdrNiZa55wE2g40wD2mFv6jyp rpRqXuc7rcSZcgU8LDgFNIouosu3fPML9b3B2Ar8cUrExw17zfMYelRQaxkzI9Rv 6Mh7h/36EHdaBMrgSmczdMS7kGTmJF+iwtbsDLKKhCawkJYyZSRNso18rWA8omuV ERpMfxBHSocl39bUp/EO7TB40HL1sRVv0C3+i7zh/lHk3ShvOsXP8r38rFCZ4Mw+ 9nD1w7VFoFti+lj8mMhe3jCm0a+nbSZet4yt+mC17UE2rMzX5qPUa+i+rlP2dE28 YlDESvfdCYp/290apVy/2HARqw4dA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=6hy9tFbJEaml4nhlCB +CCg2csYg9/Dz8MjJf5cvGKZE=; b=Rjc0k8zKD4la3JMUVBkuzpj4RCndIqkYZs 2IvFa/R4/SEtLY3SYe03N4WUjyIfKhWsMFfBX/g40Hrn9LQd4suMa+xENKGoi6H/ ozHkxPR5Qj7PK8nzYSEukEk/ZlaiUpT42qmADDUAS7ut09zLOXiiUJ2bJEj0hzAj k+0OqwECuJAYM4gmusZ28oD8yNgIWeyaklkQG52r6Kd1Zku5fZZywnodXZYBDruZ 8xNd6I4LAl5exm8QeLoGlBO+F4SJGJT/yzbSsB2RiHQ82z6GIbkrhUmwHg5/jwAi Qk/AnXlmHVMjNgGoEUTXli/NhKP+2s8TOzq1VZmTLoqM9+ViM++g== X-ME-Sender: X-Sasl-enc: SuUluVYDPKDre9khyzt6G6f2+d5hZ7cra8JnT3ymQgIg 1494046557 Received: from madcat.local. (220-253-229-104.dyn.iinet.net.au [220.253.229.104]) by mail.messagingengine.com (Postfix) with ESMTPA id F1E01240A5 for ; Sat, 6 May 2017 00:55:57 -0400 (EDT) From: Alastair Hogge To: freebsd-current Subject: ${src}/release/release.sh fails at makefs state Date: Sat, 06 May 2017 12:55:55 +0800 Message-ID: <1572386.JF4Y4n8hXg@madcat.local.> User-Agent: KMail/4.14.10 (FreeBSD/12.0-CURRENT; KDE/4.14.10; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 04:56:01 -0000 Hi, On a r317857 amd64 host, the release.sh build fails: # cd /usr/src/release && ./release.sh [...] ===> usr.sbin/yp_mkdb (installconfig) ===> usr.sbin/yppoll (installconfig) ===> usr.sbin/yppush (installconfig) ===> usr.sbin/ypserv (installconfig) ===> usr.sbin/ypset (installconfig) ===> usr.sbin/keyserv (installconfig) ===> usr.sbin/pkg (installconfig) ===> usr.sbin/pmcannotate (installconfig) ===> usr.sbin/pmccontrol (installconfig) ===> usr.sbin/pmcstat (installconfig) ===> usr.sbin/pmcstudy (installconfig) ===> usr.sbin/edquota (installconfig) ===> usr.sbin/quotaon (installconfig) ===> usr.sbin/repquota (installconfig) ===> usr.sbin/tcpdchk (installconfig) ===> usr.sbin/tcpdmatch (installconfig) ===> usr.sbin/timed (installconfig) ===> usr.sbin/timed/timed (installconfig) ===> usr.sbin/timed/timedc (installconfig) ===> usr.sbin/unbound (installconfig) ===> usr.sbin/unbound/daemon (installconfig) ===> usr.sbin/unbound/anchor (installconfig) ===> usr.sbin/unbound/checkconf (installconfig) ===> usr.sbin/unbound/control (installconfig) ===> usr.sbin/unbound/local-setup (installconfig) ===> usr.sbin/uathload (installconfig) ===> usr.sbin/uhsoctl (installconfig) ===> usr.sbin/usbconfig (installconfig) ===> usr.sbin/usbdump (installconfig) ===> usr.sbin/ac (installconfig) ===> usr.sbin/lastlogin (installconfig) ===> usr.sbin/utx (installconfig) ===> etc (installconfig) ===> etc/newsyslog.conf.d (installconfig) mkdir -p bootonly/usr/freebsd-dist cp MANIFEST bootonly/usr/freebsd-dist ln -fs /tmp/bsdinstall_etc/resolv.conf bootonly/etc/resolv.conf echo sendmail_enable=\"NONE\" > bootonly/etc/rc.conf echo hostid_enable=\"NO\" >> bootonly/etc/rc.conf echo debug.witness.trace=0 >> bootonly/etc/sysctl.conf echo vfs.mountroot.timeout=\"10\" >> bootonly/boot/loader.conf cp /usr/src/release/rc.local bootonly/etc sh /usr/src/release/amd64/mkisoimages.sh -b 12_0_CURRENT_amd64_BO bootonly.iso bootonly 200+0 records in 200+0 records out 819200 bytes transferred in 0.000558 secs (1468442469 bytes/sec) newfs_msdos: cannot get number of sectors per track: Operation not supported newfs_msdos: cannot get number of heads: Operation not supported /dev/md0: 1557 sectors in 1557 FAT12 clusters (512 bytes/cluster) BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=1600 Media=0xf8 FATsecs=5 SecPerTrack=63 Heads=1 HiddenSecs=0 sh /usr/src/release/amd64/make-memstick.sh disc1 memstick.img Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes Extent size set to 8192 memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment size 1024 using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, 890912, Populating `memstick.img.part' makefs: bread: read 8192 (684294144) returned 0: No error: 0 makefs failed *** Error code 1 Stop. make[1]: stopped in /usr/src/release *** Error code 1 Stop. make: stopped in /usr/src/release To good health, Alastair From owner-freebsd-current@freebsd.org Sat May 6 06:26:45 2017 Return-Path: Delivered-To: freebsd-current@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 C9F1BD61D78 for ; Sat, 6 May 2017 06:26:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 961E01BD; Sat, 6 May 2017 06:26:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id v14so3129896pfd.3; Fri, 05 May 2017 23:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=Ag5h3+eG8BnES+3MYV5GX3/IMuaDdI8uPJHmDWnQ3KQ=; b=fu0q/8x1GwdT3uwtT3wr/qg9UVeB92n35fo2bdOYlu272u+yyJhY0nDkIS4T/GlLr0 klD5QtTdUsF1DVlLYjcuTbYV4tRHWSEFXrAuthARzqzqfayGsO2eI9rz2L+SCnKjPLbi qCGEP3IfPoWRVTNDMWEa0k2+PDiqj9DcULvD185ehk1KB3YdUsVoQXY80ugft+7LJz11 0CDBDMEEKAr/+Sa8tJTSIszRd0kTe06nhq/PJwfC67Q9vdJU4f0RqSCHjgCrj8p9nXzS qK5ttp3Zp4dHfYa8D3wQm4AjohFQ3QU7fP1IsmlYi1J9nzKjVmEVuT8RJrmaXSVjpKKJ UpTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=Ag5h3+eG8BnES+3MYV5GX3/IMuaDdI8uPJHmDWnQ3KQ=; b=nD1O8F434TB4DeUqRgJ+C2GlitB/RB5BY1/52AOv/BvvevKc/ySgPNE4STe7hbqCJN ykTZPEeQsJbYpEP/ZHTc63gDrm19gHp/w9t3zm2R7joirqCO2Xn6bzQyKh0mcaiuf/RT MU4W0pfgZXjp1HagfCezTeusFE3SOfbZxG9O42Kbm7OPhPYMegTwvcE7VnD1ke3c6HxK 7Y/r5XFSfl6xHprvhnhll/YS2x/zk6dFmaQa0VlP16YxPsMLibP29GBsjg0AE62PBNIw JypAabpDZdYr3yDF+NsDI4kpcGVqH8yD5A0tQaqeqvptDHKrPTdg/f18ze8B4dPw7gW2 TXOQ== X-Gm-Message-State: AN3rC/7hoGSDHXa4ipzJzKFT8GDcDgiDQbUODOEeIU0SnHxOkp+5zXVJ YNmK5uEqXB4fioO5AJo= X-Received: by 10.84.131.1 with SMTP id 1mr69590627pld.40.1494052005130; Fri, 05 May 2017 23:26:45 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id e5sm10188728pga.13.2017.05.05.23.26.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 05 May 2017 23:26:44 -0700 (PDT) Subject: Re: ${src}/release/release.sh fails at makefs state Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_21D63968-80FC-4967-B747-0E5273D4F878"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <590d576d.053aed0a.239ed.3885SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 5 May 2017 23:26:44 -0700 Cc: freebsd-current , Ed Maste Message-Id: <912E7862-7AFB-4B40-863C-0205FEF2AFB0@gmail.com> References: <590d576d.053aed0a.239ed.3885SMTPIN_ADDED_BROKEN@mx.google.com> To: Alastair Hogge X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 06:26:45 -0000 --Apple-Mail=_21D63968-80FC-4967-B747-0E5273D4F878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (CCing emaste) > On May 5, 2017, at 21:55, Alastair Hogge wrote: =E2=80=A6 > Calculated size of `memstick.img.part': 485474304 bytes, 9435 inodes > Extent size set to 8192 > memstick.img.part: 463.0MB (948192 sectors) block size 8192, fragment = size > 1024 > using 9 cylinder groups of 54.38MB, 6960 blks, 1152 inodes. > super-block backups (for fsck -b #) at: > 32, 111392, 222752, 334112, 445472, 556832, 668192, 779552, = 890912, > Populating `memstick.img.part' > makefs: bread: read 8192 (684294144) returned 0: No error: 0 > makefs failed > *** Error code 1 Cheers, -Ngie --Apple-Mail=_21D63968-80FC-4967-B747-0E5273D4F878 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZDWykAAoJEPWDqSZpMIYVS+cP/Am2JweclOfJT7FL1rKdGOs+ 59AQyXNbBtiZUKo2xalbvHGePVoNFajPljsutiystVNpZDAQEBbvjObmq7qL+VUb VuEcL0AI6O7t/gTa17SEoEZA8i0lOoBKvNUNxwgRsEZFtRCx8QMvcu5/A+J7Bwv9 Q8YZMYnC6EdmdHeGATVe1IjDlE3qXRRVCMFIlzCA7TmLbC/T9YH/qCrsL4Uax753 IfIGcpkfT3khXzV1R8nMcIW56AiQNJnFLl1u+DB4Rk8CGDouRK/LBdNtsTK2vefa md/0WW/NHAKVIWMpR63j3M3hM4uvB5rK2B9emCg+dyIDpFQr9J9rQ66ekc0oQjRg KmQiVnY7a6I3fnyAvvZrU9Cy0PQqtAtsQt+LZMR7Bum8GyiBc/v+yhbjgR4bJ5UJ EhmQD94Ens64LfGtfD8HldR+/qgaQqxAi24rQhPXlolRkzE2iF6GBkAszIJCOSTS 3SrX9m3vVm78hl86ZUxM6016JJN+duC1kzbY8OlNAH0zjeaw2CaDp0o4XP9kHu5J KPjXq7qhuG3z+DPQxf9T5QuqdIIxFmoEj1S7CgoPYtSABPy32H6tqkFlddLohkuT Lp7QwnqRRaXfEZ10GF2cwWYYY7JaiWAtMejtdsCYM7mu3aKB5k/KA1ccKIj9O0Hf e65i0TUgGQOZLv0wSmJu =Tb3B -----END PGP SIGNATURE----- --Apple-Mail=_21D63968-80FC-4967-B747-0E5273D4F878-- From owner-freebsd-current@freebsd.org Sat May 6 07:23:12 2017 Return-Path: Delivered-To: freebsd-current@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 D839FD6059A for ; Sat, 6 May 2017 07:23:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59EB6DFF for ; Sat, 6 May 2017 07:23:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.52.9.80]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGEv5-1dJEOl06jv-00FBwO for ; Sat, 06 May 2017 09:23:04 +0200 Date: Sat, 6 May 2017 09:22:55 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: filemon: weird full-time build although filemon enabled Message-ID: <20170506092255.083828f8@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/9J_=qNI8RJioVhIfM/fyoHl"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:4BoPqNfUg22JdxZKdHnUiVhA+NmW1V4G7fsf31P4JS829uYSvaL wPxRfVCAfrEcVFtdxSvn8TC2ynV6c9hwj8rI6M2tiles92kz42W/CRR87Wgl1QhiB2O4pXs V0HtHFY9aWRg9lnVdcGIm02exi1dB+MJ4h4LZ8DZ8PXGhrmmTaSH4FzMCThhAdCshZmS26b pyXuIhvZYH57nba8C7bYw== X-UI-Out-Filterresults: notjunk:1;V01:K0:M3IpgT3XcVQ=:6bFjJOrblHWGiJWb16gTUx DpAQ5uZPlmvjMhTtg9QHnZNXbo4LxzjK/r6vJVhqDn8ZdbysAX/fapOwFAhaBoy78nxGSXamx /6Lj7/YTUqfbmcnm5I05Wca2be6wdZjuualN49OFLwcN8gAVLxyAJixKX3Rh5DqY+mB4vzSxV KuqPoEew/h7/1mihu/bSGxkS8eYP0MqANjte99x3CwdUH8p7ew1yYzH31DXhYc+IRRFLtqfi6 DtaAbY+uZV99G8HtFajBQ2a1kEMN4dVs+1BgU3rnUu1nIN6aj2/bmPpucF3ZB9LcdV4TuxFLC wQfOv0wrDKQbOwEiBimmpMV5M99D3KpF/DdWyMP4g5gXIH88WBFrJe98WGY/A2Xk1Rf0b8qTj M2/Op0YZnWJ5XjoVvVtka3U6oFv2WKTy+rBOxAqqDBnqNOD7OFq9LeRAqpP27d60WjIJB2Vhm 7UCrdxvBhEeF8GrsKtUK6OK65KIrk8zk38BiErLcVAywWjDDdNfaz/Nu6OruhbEWvLX7iYtPf z2SKY5L3eybZ1IKW6hPs+OrTIusgUX1ug1GVAvaulR9jRat9LY1s79zK6WW1CCZMEo3rckLF7 ExC7wbPFjTgSzmxcbXB5X/danfsDpf/4XVK8n/CafTyoIYPSJra+F3aAsxl1Ao8+IbH94drlL /3Nq1bglebBLYPSpXmDt9E6BGHzwQ66N7fG45a5+acruC4CHweCzfiDZgAHYWV1Df79gP4vsG gAK8N+OFKtoSp6QG+rfxbQOqX4SQOF0jRStGHoTD7v2CHGsWoTqy5lLWpWg= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 07:23:13 -0000 --Sig_/9J_=qNI8RJioVhIfM/fyoHl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I build CURRENT on two technically similar systems on a almost daily basis.= Therefore, it was a great relief having WITH_META_MODE=3Dyes set in /etc/src-env.conf for= incremental builds. To make my understanding of this clear (just in case I'm wrong): se= tting WITH_META_MODE builds only portions that does not need to be build in the m= ake context. Well, the reason writing this email is: on one system, I run almost every r= eboot into a "full build" and this puzzles me a bit. The long-lasting and time exhaustin= g builds are within the LLVM/CLANG tree. They consume a lot of time. The box in question= does have a weak CPU, only two physical cores, four threads, 8GB of RAM and builds the = /usr/obj residing on a SSD. The reference machine does have the same motherboard, al= so a SSD, but has 16 GB RAM and a 4-core/8 threads XEON CPU - but both are "IvyBridge". T= he XEON usually needs 30 - 40 minutes to compile a full world/kernel from a clean /= usr/obj, the "weak" box takes approximately 120 minutes - it is understandable that a sh= ortage of the build time is appreciated. Well, having said this, I need to mention that both systems use almost identical /etc/src.conf setting - except the order of appearance of the WIT= H_ tags. In fact, they are identical except the KERNCONF (naming of the kernel) and POR= TS_MODULES=3D, the "weak" box incorporates x11/nvidia-driver and emulators/virtualbox-ose-= kmod, so these modules are build every time the system gets rebuild, but the time taken by= those is negligible. The problem: to make my point clear: the "weak" box starts compiling almost= everytime now the LLVM/CLANG tree while the XEON box does not. This is spooky. I deleted on both systems recently /usr/obj completely from its content an= d restarted a buildworld again to hope, that the problem was introduced due to some files necessary for the BSD make environment to indicate the incremental build. B= ut no success. Even more spooky is the fact, that after a build on the "weak" box and a bu= ild again, the box bevaves as expected not rebuilding everything again, but in some cases = after a reboot, a rebuild the hits again the build of LLVM/CLANG tree, while the XE= ON box does not. I think there is something missing an I'd like to ask what is the suggested= way to initially restart a full build to ensure that WITH_META_MODE gets initialis= ed correctly. Well, I'm not a developer, so please be patient with my naive report. Thanks in advance, oh --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/9J_=qNI8RJioVhIfM/fyoHl Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWQ15zwAKCRDS528fyFhY lNYvAgCaD2n+iXxVq/ul/WKGHeI3p/00HXfttEJ3zJujP3HEARdHjXKX8f7XeGyW Ku8M+x8Ih0RJOdeiIi0q9NLgYu4nAf957MiLjuPJJ4Z0g3DppX8AEzAK/RkXaKPT CNp/JtS1icp9ubf6AUso7RKSAJAV9klRyr3d+RHtS4eRVI5Us7ZD =SROU -----END PGP SIGNATURE----- --Sig_/9J_=qNI8RJioVhIfM/fyoHl-- From owner-freebsd-current@freebsd.org Sat May 6 08:55:34 2017 Return-Path: Delivered-To: freebsd-current@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 06617D60369 for ; Sat, 6 May 2017 08:55:34 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5678D29 for ; Sat, 6 May 2017 08:55:33 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.141] (helo=mjail1.freenet.de) by mout0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.85 #1) id 1d6vUt-0004a9-UE for freebsd-current@freebsd.org; Sat, 06 May 2017 10:55:27 +0200 Received: from localhost ([::1]:56686 helo=mjail1.freenet.de) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1d6vUt-0000HL-QC for freebsd-current@freebsd.org; Sat, 06 May 2017 10:55:27 +0200 Received: from mx4.freenet.de ([195.4.92.14]:47012) by mjail1.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1d6vST-0005qx-Le for freebsd-current@freebsd.org; Sat, 06 May 2017 10:52:57 +0200 Received: from p5b254991.dip0.t-ipconnect.de ([91.37.73.145]:65103 helo=[192.168.178.45]) by mx4.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:DHE-RSA-AES128-SHA:128) (port 587) (Exim 4.85 #1) id 1d6vST-0007iq-IR for freebsd-current@freebsd.org; Sat, 06 May 2017 10:52:57 +0200 Subject: Re: regression suspend/resume on Lenovo T420 From: =?UTF-8?Q?Manuel_St=c3=bchn?= To: freebsd-current@freebsd.org References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> Message-ID: Date: Sat, 6 May 2017 10:52:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originated-At: 91.37.73.145!65103 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 08:55:34 -0000 On Wed, 03 May 2017 22:28:41 +0200, Freebsdnewbie wrote > >> Von: Adrian Chadd >> Gesendet: Mo. 01.05.2017 23:31 >> An: Manuel Stühn , >> Kopie: freebsd-current , >> Betreff: Re: regression suspend/resume on Lenovo T420 >> >> There were lots of commits that could break things. :-) >> >> >> Can you compile up some intermediary versions between 315141 and >> r317559 to find which commit range broke things? That'll make chasing >> it down much quicker! >> > > I'm following your advice and building some intermediary versions. This will take some time... So, after keep building some more worlds i've discovered the commit after which resume does not work anymore. r316736 is the last working one, r316737 breaks it for me (There is also no mouse cursor on the console anymore after this commit). Any hints? Thanks. From owner-freebsd-current@freebsd.org Sat May 6 09:06:33 2017 Return-Path: Delivered-To: freebsd-current@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 57100D60955 for ; Sat, 6 May 2017 09:06:33 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2523173C for ; Sat, 6 May 2017 09:06:32 +0000 (UTC) (envelope-from freebsdnewbie@freenet.de) Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.85 #1) id 1d6vfY-0006eG-Ll for freebsd-current@freebsd.org; Sat, 06 May 2017 11:06:28 +0200 Received: from localhost ([::1]:47898 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1d6vfY-00029I-Hr for freebsd-current@freebsd.org; Sat, 06 May 2017 11:06:28 +0200 Received: from mx7.freenet.de ([195.4.92.17]:57884) by mjail0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.85 #1) id 1d6vct-0007AN-Ma for freebsd-current@freebsd.org; Sat, 06 May 2017 11:03:43 +0200 Received: from p5b254991.dip0.t-ipconnect.de ([91.37.73.145]:62284 helo=freebsd-t420.fritz.box) by mx7.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (port 587) (Exim 4.85 #1) id 1d6vct-0005o0-GK for freebsd-current@freebsd.org; Sat, 06 May 2017 11:03:43 +0200 Date: Sat, 6 May 2017 11:03:41 +0200 From: Manuel =?iso-8859-15?Q?St=FChn?= To: freebsd-current@freebsd.org Subject: Re: regression suspend/resume on Lenovo T420 Message-ID: <20170506090341.GA12163@freebsd-t420.fritz.box> References: <5746a37cd73e062c963512df1a6d24c6@email.freenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Originated-At: 91.37.73.145!62284 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 09:06:33 -0000 On Sat, May 06, 2017 at 10:52:56AM +0200, Manuel Stühn wrote: >On Wed, 03 May 2017 22:28:41 +0200, Freebsdnewbie wrote >> >>> Von: Adrian Chadd >>> Gesendet: Mo. 01.05.2017 23:31 >>> An: Manuel Stühn , >>> Kopie: freebsd-current , >>> Betreff: Re: regression suspend/resume on Lenovo T420 >>> >>> There were lots of commits that could break things. :-) >>> >>> >>> Can you compile up some intermediary versions between 315141 and >>> r317559 to find which commit range broke things? That'll make chasing >>> it down much quicker! >>> >> >> I'm following your advice and building some intermediary versions. This will take some time... > >So, after keep building some more worlds i've discovered the commit >after which resume does not work anymore. r316736 is the last working >one, r316737 breaks it for me (There is also no mouse cursor on the >console anymore after this commit). Sorry, my fault: r316734 was the last working revision!! From owner-freebsd-current@freebsd.org Sat May 6 21:41:25 2017 Return-Path: Delivered-To: freebsd-current@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 313C8D60737 for ; Sat, 6 May 2017 21:41:25 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 DCCD6D5C for ; Sat, 6 May 2017 21:41:24 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OPJ00800W6HQN00@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Sat, 06 May 2017 21:41:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494106878; bh=e47ZRFoXdWXkMuw/ZWZEqfOa1ABXEQyWwzj/QfrZ20E=; h=From:Content-type:MIME-version:Subject:Message-id:Date:To; b=WltitAPIMogtkRHO2vLuy2o+wJlT78M+SUU6aF5Vs/xIPrG/P2js+WqWwMutUjAsG x3L8+B6lSftimRsm+zf0keWKaw/UN6EX7C4Cleitr0y5c22d1LiNJjhqNc7PLjk+xH NDzarG7xqkjemY5lDc4F+3BS4wjZHnOIy4+yd0qphzms/U09GKmh4FL7oV8PWBkBL2 l4szG+vxw425OOQwOPwiIR4tY396kSvHTobgabH9GDYbJ1HYIBe8839f9BNJJBXWtM lkzdecx587CT9Jp0ZWZ5y49LLEFsS6Y/HGghk9qkGZteGylC2vQo+It5j+Ldz112Nh azS0dVfGKDPxQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OPJ00CQQW8S8C30@st13p35im-asmtp002.me.com> for freebsd-current@freebsd.org; Sat, 06 May 2017 21:41:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-06_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705060184 From: Toomas Soome Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: loader: network code update Message-id: <3F407D68-E80F-4F53-B3FD-573CFC8B7B11@me.com> Date: Sun, 07 May 2017 00:41:15 +0300 To: freebsd-current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 21:41:25 -0000 hi! After pushing the network code update, there is review up: = https://reviews.freebsd.org/D10631 For testing it, you would also like to increase the read sizes like: tftp.blksize=3D=E2=80=9C8196=E2=80=9D nfs.read_size=3D=E2=80=9C4096" for nfs, the 4k is currently max value, we probably would like to rise = the allowed max to 8-16k. rgds, toomas=