From owner-freebsd-current@freebsd.org Sun Dec 24 09:49: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 B1173E820E5 for ; Sun, 24 Dec 2017 09:49:52 +0000 (UTC) (envelope-from devries.arno@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D39471DDE for ; Sun, 24 Dec 2017 09:49:52 +0000 (UTC) (envelope-from devries.arno@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id g130so30105296wme.0 for ; Sun, 24 Dec 2017 01:49:52 -0800 (PST) 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=HM+s0IPVxrRYFl9LOJU2cvOnYLwoDSE+TK8NePyPz60=; b=qXrpFuDmRQptO6+uMoDSI786id9+9juWZZHp+mt5eW6n1FjhEW8mA8DhmOeAjh70Zf Mrr3cXS/nm30fXaIb68X4trHA0rSFIWe67fwLoSYP4V2ArfpYpeSXzIiOg2XSsGFVay/ zgACub6Sbq7DfmmBgVf0QLgJUbRQQT1G3YOhik5K42L4gnSEFDgSK7p453/PM37qKlA8 uEoWdaQCWWhcqLofBFV0PYIWjm6M63RBJyYz4jZ18aann4X9RgwMHWwaFvLhW8ixearY 9Bi/BTTPcmXx3dbyKx1AQ3y12jTXi9jTJzBcRCKFY2M5BINwG604yCzW0UChlRtTXmIw 1X1A== 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=HM+s0IPVxrRYFl9LOJU2cvOnYLwoDSE+TK8NePyPz60=; b=KXpns91LMWvrYRZ0cWyy6TL/AVbMZ9tOU9eGlTPR2ziPwEp5XbpfWpMhLN5qaYhzCv jQ/xeqVZZXBJK6C9SrISSb2N8LKWgK2OTIThJo4Yau0/eUS+NPyQFM7XZmSNTq3flAXq 3Yrk61ctoAn2iEp0SSNaKSRr0GjBU9bJVrwqosAk4SA5jHOOQhVOlTVyibG87HaRhC+e DCM6WMvxK6kbnLhOC7hpqg66+bFDe7d0FZCOM2/m/2IaEFa+yBqO3ecY86MkiC1GbQC+ FUBUd/ZbXG9/LyCriLGYztwjOkpY4/0nSWWEe5xtS7+6ZyD0EBNdwLsN0hct6w3MuQCz E3vw== X-Gm-Message-State: AKGB3mLTj0c7gkQT5RPprUXYa2qsHoOlsjzEmt9/WogKsUWD0PYKv27x mzhbx4mR12ALFj1AS/CpCo2Y9vOtZ8PDgKahtBHzyRGK X-Google-Smtp-Source: ACJfBouLMVdjVN8QhXINws3pmYVI0WMuMFkYNonXzqdAJBlGpLp9bBT1bQ+NNmta5P2uewJqQugRquV4N0HKs0IaFXg= X-Received: by 10.80.150.194 with SMTP id z2mr22744137eda.156.1514108989850; Sun, 24 Dec 2017 01:49:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.186.71 with HTTP; Sun, 24 Dec 2017 01:49:48 -0800 (PST) In-Reply-To: References: From: Arno de Vries Date: Sun, 24 Dec 2017 10:49:48 +0100 Message-ID: Subject: Re: UEFI booting survey To: Warner Losh Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 09:49:52 -0000 On Sun, Dec 17, 2017 at 8:52 PM, Warner Losh wrote: > Greetings > > If you are booting off UEFI and have a bit of an unusual setup, I'd like > you to drop me a line. > > The setup that I'm looking for is any case where you load boot1.efi off one > drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that > drive, but on a different drive on the system. > > An example of this may be loading boot1.efi off what FreeBSD would call > /dev/ada0p1, but having root come from /dev/ada1p1. > > It's my belief that due to the fragility of this setup, few, if any, people > have this setup. If you do, please take a minute to reply to this message. > In the coming months, we're looking at dropping boot1.efi and instead > installing /boot/loader.efi onto the ESP (most likely as > \efi\freebsd\loader.efi). As part of the move to fully support the UEFI > Boot Manager, we're dropping the 'search every device in the system' part > of the current boot1 algorithm. It will be possible to configure the system > to continue booting (either via the new efibootmgr which will allow any > imaginable combination, or possibly via a fallback mechanism needed for the > embedded EFIs that have poor UEFI Variable support at the moment), but as > part of an upgrade to a future FreeBSD 12, some intervention will be > necessary. > > Please let me know if you have an unusual setup like this. > > Warner > I use something similar in FreeBSD 11.1 . I boot from an USB drive with an EFI partition and an UFS partition containing only a modified loader.efi, loader.help,loader.conf and loader.rc The reason is I came from a BIOS system with a root raidz pool on raw disks. and my new motherboard no longer supported legacy boot. I had to modify loader.efi because it only probes partitions for zfs pools, not disks (also see bug report 220105). For those interested: comment out the 'continue' on line 123 in /sys/boot/efi/libefi/efipart.c (r 313355) I used info form https://lists.freebsd.org/pipermail/freebsd-hackers/2015-August/048141.html to get it booting. Arno Virusvrij. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> From owner-freebsd-current@freebsd.org Sun Dec 24 13:27: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 B1C34E8E5EE for ; Sun, 24 Dec 2017 13:27:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 99C737995D for ; Sun, 24 Dec 2017 13:27:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 95E1CE8E5ED; Sun, 24 Dec 2017 13:27: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 9424FE8E5EC for ; Sun, 24 Dec 2017 13:27:12 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.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 5E1787995C for ; Sun, 24 Dec 2017 13:27:11 +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 vBODRBWH003491 for ; Sun, 24 Dec 2017 13:27:11 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id vBODRAxQ003490 for current@freebsd.org; Sun, 24 Dec 2017 05:27:10 -0800 (PST) (envelope-from david) Date: Sun, 24 Dec 2017 05:27:10 -0800 From: David Wolfskill To: current@freebsd.org Subject: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 Message-ID: <20171224132710.GN1555@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ie5iOtK4e9kgqh2F" Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 13:27:12 -0000 --Ie5iOtK4e9kgqh2F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Had this on the laptop; fotunately, also got it on the build machine (as it's a lot easier to work with the serial console of the latter for this -- and it runs a GENERIC kernel): =2E.. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT #51 r327140M/327142:1200054: Sun Dec 24 05:11:03 PST = 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GE= NERIC amd64 FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM = 5.0.1) WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xde3c1b98 Table 'APIC' at 0xde3c1ca8 Table 'FPDT' at 0xde3c1d40 Table 'ASF!' at 0xde3c1d88 Table 'SLIC' at 0xde3c1e30 Table 'SSDT' at 0xde3c1fa8 Table 'SSDT' at 0xde3c24e8 Table 'MCFG' at 0xde3c2fc0 Table 'HPET' at 0xde3c3000 Table 'SSDT' at 0xde3c3038 Table 'SSDT' at 0xde3c33a8 Table 'MSDM' at 0xde3c6688 Table 'DMAR' at 0xde3c66e0 ACPI: No SRAT table found PPIM 0: PA=3D0xa0000, VA=3D0xffffffff82410000, size=3D0x10000, mode=3D0 =2E.. VT(vga): resolution 640x480 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff82278000. Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff822810d8. Preloaded elf obj module "/boot/kernel/filemon.ko" at 0xffffffff82281130. Calibrating TSC clock ... TSC clock: 3591758700 Hz CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (3591.76-MHz K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x306c3 Family=3D0x6 Model=3D0x3c Steppi= ng=3D3 Features=3D0xbfebfbff Features2=3D0x7ffafbff AMD Features=3D0x2c100800 AMD Features2=3D0x21 Structured Extended Features=3D0x2fbb XSAVE Features=3D0x1 VT-x: Basic Features=3D0xda0400 Pin-Based Controls=3D0x7f Primary Processor Controls=3D0xfff9fffe Secondary Processor Controls=3D0x7cff Exit Controls=3D0xda0400 Entry Controls=3D0xda0400 EPT Features=3D0x6334141 VPID Features=3D0xf01 TSC: P-state invariant, performance statistics Data TLB: 2 MByte or 4 MByte pages, 4-way set associative, 32 entries and a= separate array with 1 GByte pages, 4-way set associative, 4 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M pages, fully associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associative, 64 entries 64-Byte prefetching Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries L2 cache: 256 kbytes, 8-way associative, 64 bytes/line real memory =3D 34359738368 (32768 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000099fff, 565248 bytes (138 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x00000000022c4000 - 0x00000000cd1d3fff, 3404791808 bytes (831248 pages) 0x00000000cd1db000 - 0x00000000cda2cfff, 8724480 bytes (2130 pages) 0x00000000cdcaa000 - 0x00000000de036fff, 272158720 bytes (66445 pages) 0x00000000de0c1000 - 0x00000000de2a4fff, 1982464 bytes (484 pages) 0x00000000defff000 - 0x00000000deffffff, 4096 bytes (1 pages) 0x0000000100000000 - 0x00000007eb4e2fff, 29717573632 bytes (7255267 pages) avail memory =3D 33300434944 (31757 MB) =2E.. ACPI: Enabled 5 GPEs in block 00 to 3F random: harvesting attach, 8 bytes (4 bits) from acpi0 random: harvesting attach, 8 bytes (4 bits) from apic0 acpi0: wakeup code va 0xfffffe009b189000 pa 0x99000 random: harvesting attach, 8 bytes (4 bits) from nexus0 ahc_isa_identify 0: ioport 0xc00 alloc failed ahc_isa_identify 1: ioport 0x1c00 alloc failed ahc_isa_identify 2: ioport 0x2c00 alloc failed ahc_isa_identify 3: ioport 0x3c00 alloc failed ahc_isa_identify 4: ioport 0x4c00 alloc failed ahc_isa_identify 5: ioport 0x5c00 alloc failed ahc_isa_identify 6: ioport 0x6c00 alloc failed ahc_isa_identify 7: ioport 0x7c00 alloc failed ahc_isa_identify 8: ioport 0x8c00 alloc failed ahc_isa_identify 9: ioport 0x9c00 alloc failed ahc_isa_identify 10: ioport 0xac00 alloc failed ahc_isa_identify 11: ioport 0xbc00 alloc failed ahc_isa_identify 12: ioport 0xcc00 alloc failed ahc_isa_identify 13: ioport 0xdc00 alloc failed ahc_isa_identify 14: ioport 0xec00 alloc failed pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 =2E.. pcib0: allocated type 3 (0xe7000-0xe77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xe7800-0xe7fff) for rid 0 of orm0 Fatal trap 9: general protection fault while in kernel mode cpuid =3D 2; apic id =3D 02 instruction pointer =3D 0x20:0xffffffff81066968 stack pointer =3D 0x28:0xffffffff82286a90 frame pointer =3D 0x28:0xffffffff82286ad0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (swapper) [ thread pid 0 tid 100000 ] Stopped at orm_identify+0x308: movq (%r14),%rax db> bt Tracing pid 0 tid 100000 td 0xffffffff81e94340 orm_identify() at orm_identify+0x308/frame 0xffffffff82286ad0 bus_generic_probe() at bus_generic_probe+0x74/frame 0xffffffff82286b00 isa_probe_children() at isa_probe_children+0x19/frame 0xffffffff82286b50 mi_startup() at mi_startup+0x9c/frame 0xffffffff82286b70 btext() at btext+0x2c db>=20 I can afford to leave this machine as-is for a while, and can poke at it, given suitable clues as to where to poke & how hard. :-) Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org If Trump is "taking names" re: the UN Jerusalem vote, he can add mine. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Ie5iOtK4e9kgqh2F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJaP6suXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XHqMIAKz2Ol0y1MuI/Zur5ABtagun 6xZGmRyQsC27qeWK7ckLkZdsKEROe2xqoNJJXA/v60yPFv6Tm0YX6DNiddS/LrPc nHQICdZP4BXixPwsE9JHdGq4R/rt9UKW5Lhk19deoxPwam/ENyPxYUVwDysj2o+C b/CXVGp+7fLxwVYDui3PzXKFLCzEknoFKXxkIqEgTxvFvfj7lFyArKksG4zJztO4 lgC6o/vl52OrZLe+bjDfjGKM1rIMVXW+nteZaKgNm0GuMmmNU2j0vbzswJE/UVL0 aGbbmj0FSj3qJTqVYIxda74IBuIITM7jrVoPj7PkdOnNpMdOL3t8ze11sPjzVio= =Wl7b -----END PGP SIGNATURE----- --Ie5iOtK4e9kgqh2F-- From owner-freebsd-current@freebsd.org Sun Dec 24 14:04: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 43452E90714 for ; Sun, 24 Dec 2017 14:04:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 222E97B02B for ; Sun, 24 Dec 2017 14:04:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1E8D0E90713; Sun, 24 Dec 2017 14:04:20 +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 1E26BE90712 for ; Sun, 24 Dec 2017 14:04:20 +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 8DB9B7B029 for ; Sun, 24 Dec 2017 14:04:18 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.146.175]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LxMgg-1f3qKk09Jy-0170DG; Sun, 24 Dec 2017 15:04:04 +0100 Date: Sun, 24 Dec 2017 15:03:33 +0100 From: "O. Hartmann" To: David Wolfskill Cc: current@freebsd.org Subject: Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 Message-ID: <20171224150400.31717e7e@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171224132710.GN1555@albert.catwhisker.org> References: <20171224132710.GN1555@albert.catwhisker.org> 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_/U7I4UA+DNF.fHpO2E5L+akR"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:1SYVQpw8RrZmhq9etZVmTE1vHzAe6SH+HF6Qbd3YXNoLdD54FH1 VEUPrwe7goevX/tLpgBWtfgoRGr8446r9Fsd2JNm5Rx8IjjsahGWVFupIg9Sh8Iau8H8zWd uBVljwoI02yBOPoZlHj3EYt+Dvuksy/18V71B4EccvLGYf1rOk+PjxEnQzfbIKoQXz1TngC CZEjX9elJ0ThzaLgHbIFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:/el8y7x/3bc=:SSw10qWW8uMuOPd/cpkYY9 aTdMxzmgXO1PccAA1vu6lWKUNR1qeiGdgU2xB2OIB/1GTiAKf3ipVuhwW0ihOcnnug3GZ49xe /U1dsAtH3/UDMry3JSS1rRBO92r5I3CKjKZa0T7YVxAsyo+aaMsc1dAmZydb0gXUl7+Qfgcit CNhhoK4hnIAXt1weoCRqmwlM9V00C36rRXvvipxDgOQdKFJpZ3fuqrQ7ZUk9SmFSyPTCdbH4h wB6+7r3qdw9+GKxEs117znUr3ItP4iAzC7sjNE/7bmt8cJylVF2jqh9o20cLa7biPQMLuuVfr VvUb3OUOZRtNh0ffQGVqduPyNjDfYWQ75MhwchVySeIQaSA1h7oU5o2GA4D2C5p0wCqL/evi2 3WMTEZ3UHm7Q41nXmkRxUnAyej05tGlzCbYFE/WhQWb1Yw/pZMEb3ijkHn5qwQI0y09aZ1tgt 8fg4SpNTYExITJHTuvfqTKEtrTMc/yAuYBZ1BVs2jGTcFqhQqxdne+NmSF1ncHOjTFjdI3NvS GbhsM3vD9vitFUjnYFUnm93m9XqmQGEZOgx2OPGCwAJhzXwXh5uCIUe8bTe8ew/rCYxMGkHAd OxhsD1FZZHx8UuImrg/zTW2/2tH2uQVzfmN8VZqRx2JVV9JWzO/BdNUKHQmtYif/RZUF5f6iS arExv2GoqY5vuyWby1ffxd7AqnQuvhecmYdGuI9DXFYeA2KxUqq9nVTbJxebB2xkhXQTbZObJ u+A+Y7NF9sw2JW0b4TyCpgFRnvZxu15TNQCEKiyK/IS4dY8kvkibO8G5LPowZtzTaop/arpoM fvsBmG1NGVUGsEG+cuho4ODW7g8sw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 14:04:20 -0000 --Sig_/U7I4UA+DNF.fHpO2E5L+akR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sun, 24 Dec 2017 05:27:10 -0800 David Wolfskill schrieb: > Had this on the laptop; fotunately, also got it on the build machine (as > it's a lot easier to work with the serial console of the latter for > this -- and it runs a GENERIC kernel): >=20 > ... > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT #51 r327140M/327142:1200054: Sun Dec 24 05:11:03 PS= T 2017 > root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/= GENERIC amd64 > FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLV= M 5.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > Table 'FACP' at 0xde3c1b98 > Table 'APIC' at 0xde3c1ca8 > Table 'FPDT' at 0xde3c1d40 > Table 'ASF!' at 0xde3c1d88 > Table 'SLIC' at 0xde3c1e30 > Table 'SSDT' at 0xde3c1fa8 > Table 'SSDT' at 0xde3c24e8 > Table 'MCFG' at 0xde3c2fc0 > Table 'HPET' at 0xde3c3000 > Table 'SSDT' at 0xde3c3038 > Table 'SSDT' at 0xde3c33a8 > Table 'MSDM' at 0xde3c6688 > Table 'DMAR' at 0xde3c66e0 > ACPI: No SRAT table found > PPIM 0: PA=3D0xa0000, VA=3D0xffffffff82410000, size=3D0x10000, mode=3D0 > ... > VT(vga): resolution 640x480 > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff82278000. > Preloaded boot_entropy_cache "/boot/entropy" at 0xffffffff822810d8. > Preloaded elf obj module "/boot/kernel/filemon.ko" at 0xffffffff82281130. > Calibrating TSC clock ... TSC clock: 3591758700 Hz > CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (3591.76-MHz K8-class CPU) > Origin=3D"GenuineIntel" Id=3D0x306c3 Family=3D0x6 Model=3D0x3c Step= ping=3D3 > Features=3D0xbfebfbff > Features2=3D0x7ffafbff > AMD Features=3D0x2c100800 > AMD Features2=3D0x21 > Structured Extended > Features=3D0x2fbb XSAVE > Features=3D0x1 VT-x: Basic Features=3D0xda0400 > Pin-Based Controls=3D0x7f > Primary Processor > Controls=3D0xfff9fffe > Secondary Processor > Controls=3D0x7cff > Exit Controls=3D0xda0400 Entry Controls=3D0xda040= 0 EPT > Features=3D0x6334141 VPID > Features=3D0xf01 TSC: P-sta= te invariant, > performance statistics Data TLB: 2 MByte or 4 MByte pages, 4-way set asso= ciative, 32 > entries and a separate array with 1 GByte pages, 4-way set associative, 4= entries Data > TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M= pages, fully > associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associati= ve, 64 entries > 64-Byte prefetching > Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entri= es > L2 cache: 256 kbytes, 8-way associative, 64 bytes/line > real memory =3D 34359738368 (32768 MB) > Physical memory chunk(s): > 0x0000000000010000 - 0x0000000000099fff, 565248 bytes (138 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x00000000022c4000 - 0x00000000cd1d3fff, 3404791808 bytes (831248 pages) > 0x00000000cd1db000 - 0x00000000cda2cfff, 8724480 bytes (2130 pages) > 0x00000000cdcaa000 - 0x00000000de036fff, 272158720 bytes (66445 pages) > 0x00000000de0c1000 - 0x00000000de2a4fff, 1982464 bytes (484 pages) > 0x00000000defff000 - 0x00000000deffffff, 4096 bytes (1 pages) > 0x0000000100000000 - 0x00000007eb4e2fff, 29717573632 bytes (7255267 pages) > avail memory =3D 33300434944 (31757 MB) > ... > ACPI: Enabled 5 GPEs in block 00 to 3F > random: harvesting attach, 8 bytes (4 bits) from acpi0 > random: harvesting attach, 8 bytes (4 bits) from apic0 > acpi0: wakeup code va 0xfffffe009b189000 pa 0x99000 > random: harvesting attach, 8 bytes (4 bits) from nexus0 > ahc_isa_identify 0: ioport 0xc00 alloc failed > ahc_isa_identify 1: ioport 0x1c00 alloc failed > ahc_isa_identify 2: ioport 0x2c00 alloc failed > ahc_isa_identify 3: ioport 0x3c00 alloc failed > ahc_isa_identify 4: ioport 0x4c00 alloc failed > ahc_isa_identify 5: ioport 0x5c00 alloc failed > ahc_isa_identify 6: ioport 0x6c00 alloc failed > ahc_isa_identify 7: ioport 0x7c00 alloc failed > ahc_isa_identify 8: ioport 0x8c00 alloc failed > ahc_isa_identify 9: ioport 0x9c00 alloc failed > ahc_isa_identify 10: ioport 0xac00 alloc failed > ahc_isa_identify 11: ioport 0xbc00 alloc failed > ahc_isa_identify 12: ioport 0xcc00 alloc failed > ahc_isa_identify 13: ioport 0xdc00 alloc failed > ahc_isa_identify 14: ioport 0xec00 alloc failed > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > ... > pcib0: allocated type 3 (0xe7000-0xe77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xe7800-0xe7fff) for rid 0 of orm0 >=20 >=20 > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 2; apic id =3D 02 > instruction pointer =3D 0x20:0xffffffff81066968 > stack pointer =3D 0x28:0xffffffff82286a90 > frame pointer =3D 0x28:0xffffffff82286ad0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 0 (swapper) > [ thread pid 0 tid 100000 ] > Stopped at orm_identify+0x308: movq (%r14),%rax > db> bt =20 > Tracing pid 0 tid 100000 td 0xffffffff81e94340 > orm_identify() at orm_identify+0x308/frame 0xffffffff82286ad0 > bus_generic_probe() at bus_generic_probe+0x74/frame 0xffffffff82286b00 > isa_probe_children() at isa_probe_children+0x19/frame 0xffffffff82286b50 > mi_startup() at mi_startup+0x9c/frame 0xffffffff82286b70 > btext() at btext+0x2c > db> =20 >=20 > I can afford to leave this machine as-is for a while, and can poke > at it, given suitable clues as to where to poke & how hard. :-) >=20 > Thanks! >=20 > Peace, > david So, it is dangerous to update beyond r327121? I'm running on most of our ma= chines now r327121 and it does not show nay anomalies so far ... Regards, Oliver --=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_/U7I4UA+DNF.fHpO2E5L+akR Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWj+z0AAKCRDS528fyFhY lFD3AgCJuCEseYmNELzAA2+BdFq6zvaNreLp0h2WKRpZVmKfNuQm7b+cdqtVkWMz eF02PK5/5bJUhSJoEE4TZzIWI3jeAf9T/0gPw60qfdoj/2hSWaNDTKZqqUYqbePw qaxComm7aUcbisQfc8sUCTo3bo6WJuNfv+9ZSg6ZR8PwysdJJ3lg =Duta -----END PGP SIGNATURE----- --Sig_/U7I4UA+DNF.fHpO2E5L+akR-- From owner-freebsd-current@freebsd.org Sun Dec 24 14:17:09 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 51165E91672 for ; Sun, 24 Dec 2017 14:17:09 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3880F7C1BC for ; Sun, 24 Dec 2017 14:17:09 +0000 (UTC) (envelope-from dimitry@andric.com) Received: by mailman.ysv.freebsd.org (Postfix) id 34B01E91671; Sun, 24 Dec 2017 14:17:09 +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 34384E91670 for ; Sun, 24 Dec 2017 14:17:09 +0000 (UTC) (envelope-from dimitry@andric.com) 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 EAA7B7C1BB for ; Sun, 24 Dec 2017 14:17:08 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (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 5AA4E10C04; Sun, 24 Dec 2017 15:17:00 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6A706B5A-3D91-4423-817B-719E0E1EC4D5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 Date: Sun, 24 Dec 2017 15:16:59 +0100 In-Reply-To: <20171224132710.GN1555@albert.catwhisker.org> Cc: current , Warner Losh To: David Wolfskill References: <20171224132710.GN1555@albert.catwhisker.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 14:17:09 -0000 --Apple-Mail=_6A706B5A-3D91-4423-817B-719E0E1EC4D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Dec 2017, at 14:27, David Wolfskill wrote: >=20 > Had this on the laptop; fotunately, also got it on the build machine = (as > it's a lot easier to work with the serial console of the latter for > this -- and it runs a GENERIC kernel): ... > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 2; apic id =3D 02 > instruction pointer =3D 0x20:0xffffffff81066968 > stack pointer =3D 0x28:0xffffffff82286a90 > frame pointer =3D 0x28:0xffffffff82286ad0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 0 (swapper) > [ thread pid 0 tid 100000 ] > Stopped at orm_identify+0x308: movq (%r14),%rax > db> bt > Tracing pid 0 tid 100000 td 0xffffffff81e94340 > orm_identify() at orm_identify+0x308/frame 0xffffffff82286ad0 > bus_generic_probe() at bus_generic_probe+0x74/frame 0xffffffff82286b00 > isa_probe_children() at isa_probe_children+0x19/frame = 0xffffffff82286b50 > mi_startup() at mi_startup+0x9c/frame 0xffffffff82286b70 > btext() at btext+0x2c Since there is "isa" in the backtrace, I would consider r327120 ("Warn when nonPNP ISA devices are attached in GENERIC that they are being removed from GENERIC in 12") by Warner suspect... Specifically, this change: = https://svnweb.freebsd.org/base/head/sys/x86/isa/orm.c?r1=3D327120&r2=3D32= 7119&pathrev=3D327120 -Dimitry --Apple-Mail=_6A706B5A-3D91-4423-817B-719E0E1EC4D5 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.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWj+22wAKCRCwXqMKLiCW o4THAKDf4FGaImqP9nh+YpO1NHyPJTyixwCaA7yLv3QulxUJeMmpHTHJPnDA0DU= =sUyi -----END PGP SIGNATURE----- --Apple-Mail=_6A706B5A-3D91-4423-817B-719E0E1EC4D5-- From owner-freebsd-current@freebsd.org Sun Dec 24 14:19: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 92D36E91922 for ; Sun, 24 Dec 2017 14:19:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 79C3D7C374 for ; Sun, 24 Dec 2017 14:19:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7523BE91921; Sun, 24 Dec 2017 14:19: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 7333EE9191F for ; Sun, 24 Dec 2017 14:19:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.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 26DB87C373 for ; Sun, 24 Dec 2017 14:19:10 +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 vBOEJ9DZ003780; Sun, 24 Dec 2017 14:19:09 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id vBOEJ9eU003779; Sun, 24 Dec 2017 06:19:09 -0800 (PST) (envelope-from david) Date: Sun, 24 Dec 2017 06:19:09 -0800 From: David Wolfskill To: "O. Hartmann" Cc: current@freebsd.org Subject: Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 Message-ID: <20171224141909.GQ1555@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "O. Hartmann" , current@freebsd.org References: <20171224132710.GN1555@albert.catwhisker.org> <20171224150400.31717e7e@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qnK4RqISe3HuYx1/" Content-Disposition: inline In-Reply-To: <20171224150400.31717e7e@thor.intern.walstatt.dynvpn.de> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 14:19:11 -0000 --qnK4RqISe3HuYx1/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 24, 2017 at 03:03:33PM +0100, O. Hartmann wrote: > ... > So, it is dangerous to update beyond r327121? I'm running on most of our = machines now > r327121 and it does not show nay anomalies so far ... >=20 > Regards, > Oliver > ..... Hmm... Well, reviewing the output from "svn log", I see that the next commit to head after r327121 is r327140 -- a change to head/sbin/ipfw. I have a hard time imagining how that could possibly affect anything during the kernel device probes prior to the transition from single- to multi-user mode. So at this stage, I have no indication that what I observed in both of my machines that track head will necessarily be seen by others. I could try r327121, perhaps... Peace, david --=20 David H. Wolfskill david@catwhisker.org If Trump is "taking names" re: the UN Jerusalem vote, he can add mine. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --qnK4RqISe3HuYx1/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJaP7ddXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XVJoH/jm5KHYmUsNboEpPsrrt9DOP fGQ0jopxb4P7Tl91bMXwEONPy4jenRAJftNRfMjdHkIADJQqGsacadY9jylc4d+p kOrXUMvjl0ZCB7FmkiKC9a84RWOPnx+nOY7txg9eB5Tmx+mxMmoHemcaTTnc8Wd2 EDuK0imub6o54EVDI7WbXIG5tKabZO8R+ANoAY9P7eoI6ShTF3OqpZwJG1rsPF6q 8QlQ2rwu8EQcxNOY6NMA1U/cZEyfIPJqY0dgopwLZMZExj2Gqu2ya4Lfl/qlWBep Ab+vBhocLjFQFPi2u3A8h2WSiP4Lb6y0DvtStwNwNavXz6/M5MF8rpA2X3iPeGE= =K4HS -----END PGP SIGNATURE----- --qnK4RqISe3HuYx1/-- From owner-freebsd-current@freebsd.org Sun Dec 24 14:44: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 6F18EE93021 for ; Sun, 24 Dec 2017 14:44:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 53C057D410 for ; Sun, 24 Dec 2017 14:44:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 53061E93020; Sun, 24 Dec 2017 14:44:44 +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 52B2CE9301F for ; Sun, 24 Dec 2017 14:44:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.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 267717D40F for ; Sun, 24 Dec 2017 14:44:43 +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 vBOEibkO004259; Sun, 24 Dec 2017 14:44:37 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id vBOEiaXL004258; Sun, 24 Dec 2017 06:44:36 -0800 (PST) (envelope-from david) Date: Sun, 24 Dec 2017 06:44:36 -0800 From: David Wolfskill To: Dimitry Andric Cc: current , Warner Losh Subject: Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 Message-ID: <20171224144436.GS1555@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Dimitry Andric , current , Warner Losh References: <20171224132710.GN1555@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wnBGVoaGQwxWUIo6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 14:44:44 -0000 --wnBGVoaGQwxWUIo6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 24, 2017 at 03:16:59PM +0100, Dimitry Andric wrote: > ... > > Fatal trap 9: general protection fault while in kernel mode > > cpuid =3D 2; apic id =3D 02 > > instruction pointer =3D 0x20:0xffffffff81066968 > > stack pointer =3D 0x28:0xffffffff82286a90 > > frame pointer =3D 0x28:0xffffffff82286ad0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 0 (swapper) > > [ thread pid 0 tid 100000 ] > > Stopped at orm_identify+0x308: movq (%r14),%rax > > db> bt > > Tracing pid 0 tid 100000 td 0xffffffff81e94340 > > orm_identify() at orm_identify+0x308/frame 0xffffffff82286ad0 > > bus_generic_probe() at bus_generic_probe+0x74/frame 0xffffffff82286b00 > > isa_probe_children() at isa_probe_children+0x19/frame 0xffffffff82286b50 > > mi_startup() at mi_startup+0x9c/frame 0xffffffff82286b70 > > btext() at btext+0x2c >=20 > Since there is "isa" in the backtrace, I would consider r327120 ("Warn > when nonPNP ISA devices are attached in GENERIC that they are being > removed from GENERIC in 12") by Warner suspect... >=20 > Specifically, this change: > https://svnweb.freebsd.org/base/head/sys/x86/isa/orm.c?r1=3D327120&r2=3D3= 27119&pathrev=3D327120 >=20 > -Dimitry >=20 And, indeed that seems to be the case: After 'svn merge -c -r327120 .' --- Reverse-merging r327120 into '.': U sys/isa/isa_common.c U sys/isa/pnp.c U sys/isa/vga_isa.c U sys/x86/isa/orm.c --- Recording mergeinfo for reverse merge of r327120 into '.': U . and a kernel rebuild/re-install, the machine boots OK: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #52 r32= 7140M/327142:1200054: Sun Dec 24 06:36:43 PST 2017 root@freebeast.catwh= isker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Peace, david --=20 David H. Wolfskill david@catwhisker.org If Trump is "taking names" re: the UN Jerusalem vote, he can add mine. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --wnBGVoaGQwxWUIo6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJaP71UXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4Xb8cIAMrG1/rZCpbbvzufTc3T4SZS LQe9S7gSgP+A9SeVnYzQPproyZQlRV4p/QaVoB4AgQA8XB/dv85sqeNch+QojY5y Lp3ykkXW2DEKmGQtBohKqVVRJY2ZXrQ//aAuKddA5zOpeNRafE5vHE+DCLJt7O24 LmQtlkup/ftutVMXx9Qzsb2fCH+VuHCWeQNeCdX/YhadoaE03PAT6aJNEEeE6S08 eFOmt9c7q8eUMp7r6ocK9CEzs8eZL7Uo1Rs0YJnJFIPtmVSnYKN2e5dp57gpdzVc 2dqJEgv/BMkqBh04HSZ53+tNgkCIvsDkG+PhNNFpT1Hv8Fr7b+TjPO/oLc+5BUE= =QCOE -----END PGP SIGNATURE----- --wnBGVoaGQwxWUIo6-- From owner-freebsd-current@freebsd.org Sun Dec 24 16:39:26 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 255C3E9BBED for ; Sun, 24 Dec 2017 16:39:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F338E1029 for ; Sun, 24 Dec 2017 16:39:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id EF993E9BBEC; Sun, 24 Dec 2017 16:39:25 +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 EEDC1E9BBEB for ; Sun, 24 Dec 2017 16:39:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 C611F1027 for ; Sun, 24 Dec 2017 16:39:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id t196so29078068iof.0 for ; Sun, 24 Dec 2017 08:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=90w3cIn+A2V/YhSON0kUMH3Tms+Pa+YGnhjagGR6EMo=; b=cXRCSWRT3pms37bSEiegzZ3T336WvPa6cT9ICSW173GjFMF+nWWAKlrEB4nORha1sw ysTi0jNopKXJ2kfv/+vuQlDHLrLd5G3HYVumAKOd9a+dPO7IOEtOyIn3gR7pXU4rafx6 Gx+SslEj1/iXrtccEpPbcJ5Q4ACGq6i7E86RbJPjnTLK7kVQTt13fqnR4xRbkguce927 W0tCcxBJuVFgdYjssovciY+719ik2A91RLWHpig2dwNZnw/yJughEJCZtz3/MlZ68yG0 6Ru3+kPytwpJ8o+hKuRc8FuWWxlBVPvrmulu1xZxpGymvDUJMYZbYo9R6Vx4drAH3iwm chWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=90w3cIn+A2V/YhSON0kUMH3Tms+Pa+YGnhjagGR6EMo=; b=SUIOHNO7pkw7EscyE4x4VTUyjFlOMN1ieaW/M5+3uQp61WUbsdmrwbT/ezUZqyUzv8 z3Ah8AZ2ByUIHLbsn/UF9ykUdkEUmc2Z7Gbt98lGJF5ksU0C1Zdy4MScXNvu1bHrjVOI 9U77/mB1ageX3qzDG3MUGfViKHbwW78ERmROm6X66zrvGrmiHrrdNIKGata3LiBVcgzG O9nhFfWe59bg6LE8BuopHn5uNGIe5bEm4ko3OFX49kb1+aaSfhHbospVnhOHFRO6BBUl YeT9rWMyMU5IT2t6dJM6KXRUY9BEOpOT3YX7WfJ8dNAxdiOkJL+7/rxgbHTvewK2EVEO NYNg== X-Gm-Message-State: AKGB3mKKON8lnoaU4CXCWFzl7r7AinzZ1UIH/3JgNIIUaTsm2jh6a9UI 8KWjf7d/29BkgY2Y+DQivsNSRNE/LuIU47qoyWY3Ag== X-Google-Smtp-Source: ACJfBouwGxQYJQqlNM1mPK/P/O5m2M4rEhiqFY48MXmoXr2uo9Rzwj1dTAIJ8XoS0pGz/xnb/f9Va0j1j1ouW1Qansg= X-Received: by 10.107.149.5 with SMTP id x5mr22435474iod.136.1514133564929; Sun, 24 Dec 2017 08:39:24 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 24 Dec 2017 08:39:24 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171224132710.GN1555@albert.catwhisker.org> References: <20171224132710.GN1555@albert.catwhisker.org> From: Warner Losh Date: Sun, 24 Dec 2017 09:39:24 -0700 X-Google-Sender-Auth: GH3sjJJW3nT5E-Wy0STItuwLLzg Message-ID: Subject: Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 To: David Wolfskill , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 16:39:26 -0000 On Sun, Dec 24, 2017 at 6:27 AM, David Wolfskill wrote: > Had this on the laptop; fotunately, also got it on the build machine (as > it's a lot easier to work with the serial console of the latter for > this -- and it runs a GENERIC kernel): That may be my fault somehow. I changed orm yesterday, but it worked for me :(. Since time is short, I'm commenting out the line I added at the end of orm_identify. r327162 has the change. After the holidays I'll be in touch to sort out why you're seeing this and I'm not. I can afford to leave this machine as-is for a while, and can poke > at it, given suitable clues as to where to poke & how hard. :-) Nah, go ahead and reboot. This will be easy to recreate. Warner From owner-freebsd-current@freebsd.org Sun Dec 24 16:40:43 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 4C81CE9BEC7 for ; Sun, 24 Dec 2017 16:40:43 +0000 (UTC) (envelope-from wlosh@bsdimp.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 2642E1336 for ; Sun, 24 Dec 2017 16:40:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2570CE9BEC0; Sun, 24 Dec 2017 16:40:43 +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 24F39E9BEBC for ; Sun, 24 Dec 2017 16:40:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 DD2471334 for ; Sun, 24 Dec 2017 16:40:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id 14so22603667iou.2 for ; Sun, 24 Dec 2017 08:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HaS5aqxsKLmcaAvrpDu0VnyyFZPYFMbwFBuCxWfaW10=; b=bp18QhQPzm1NatRD6scU+Aw9uu0vXYI2488NCGUm2fhU7tjmzH3A9HtTUcy/8yNV3p N6hALY68reaxo5X+R+fYsCUYRFwGZCDO33He2nvFYgGG6epANN7RTSGqwlhqNbUp9de0 hm+qVCc/0j50UgXptv6SFCJyNssNR0XZG/5Ge6ksAShWuPrzBTjbT3OAfG6JdrKtfezJ yQ3pLb7rdoOFIS/3Id2VtN8jpo4Dc0U56sbiE2TDE8+ZA1pRFklSEYtCZ0EDwR8sOOnk 7I8zYwvLSEg7FxlSqZuGe3MCsioArkhsjgX8+FTzH8R7KKuBQtDSDKiWmh9wAzmfEsma ikFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HaS5aqxsKLmcaAvrpDu0VnyyFZPYFMbwFBuCxWfaW10=; b=PyaLU4BNW4AVv5mm3fazBBd0o+iMGnyVqfT+LRPYID0LT4BG/QoPmJVP/6FCln9ROM LXK6/F3YDu1FvugrHyDR8lPAkYjQdQ6NNlG5i2uEH3Mnatfz6Qo9PL2+8J2A2NFImmug hKGsV2Y3N7e+DLS7ftA0em8fMEgD7Mxs/Lm1o3V1SlqFQBlkphvBqIKZicjhpmHSxSmB 6x8Nq401T8c1WMKVw0SRjo2Xzmb043XbCweQsQvPzyTNOIP8HGE21LKonx/ymUsVnSyQ +APIqvweVgtHacnqGnthl6m9QbKz2BtaYqoCibBKUIWHvmBiL9R7vPE9c6wLuhWyK1EI r75Q== X-Gm-Message-State: AKGB3mJHGERxeMMc9oGcBSYzDejp2ieeyX8l2kNPXqXux4+7c2Q4m3dZ a9X39U6Qk6CN0MgcL3hGo7NL/TMcniw6z9CAZrtzSw== X-Google-Smtp-Source: ACJfBouADIuudC7GiyGmT8TRIPFV8giZJl9TQN1NgpJgor1UMQzH2TVjiTNEPPrZqnKTPef36IzCGuiGihvf+brSNKY= X-Received: by 10.107.142.145 with SMTP id q139mr8984886iod.63.1514133642236; Sun, 24 Dec 2017 08:40:42 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 24 Dec 2017 08:40:41 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20171224132710.GN1555@albert.catwhisker.org> From: Warner Losh Date: Sun, 24 Dec 2017 09:40:41 -0700 X-Google-Sender-Auth: fYpnM7JapulqFrGAL4CYxF-BEgY Message-ID: Subject: Re: Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140 To: Dimitry Andric Cc: David Wolfskill , current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 24 Dec 2017 16:40:43 -0000 On Sun, Dec 24, 2017 at 7:16 AM, Dimitry Andric wrote: > On 24 Dec 2017, at 14:27, David Wolfskill wrote: > > > > Had this on the laptop; fotunately, also got it on the build machine (as > > it's a lot easier to work with the serial console of the latter for > > this -- and it runs a GENERIC kernel): > ... > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 2; apic id = 02 > > instruction pointer = 0x20:0xffffffff81066968 > > stack pointer = 0x28:0xffffffff82286a90 > > frame pointer = 0x28:0xffffffff82286ad0 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 0 (swapper) > > [ thread pid 0 tid 100000 ] > > Stopped at orm_identify+0x308: movq (%r14),%rax > > db> bt > > Tracing pid 0 tid 100000 td 0xffffffff81e94340 > > orm_identify() at orm_identify+0x308/frame 0xffffffff82286ad0 > > bus_generic_probe() at bus_generic_probe+0x74/frame 0xffffffff82286b00 > > isa_probe_children() at isa_probe_children+0x19/frame 0xffffffff82286b50 > > mi_startup() at mi_startup+0x9c/frame 0xffffffff82286b70 > > btext() at btext+0x2c > > Since there is "isa" in the backtrace, I would consider r327120 ("Warn > when nonPNP ISA devices are attached in GENERIC that they are being > removed from GENERIC in 12") by Warner suspect... > > Specifically, this change: > https://svnweb.freebsd.org/base/head/sys/x86/isa/orm.c? > r1=327120&r2=327119&pathrev=327120 Yea, I just partially reverted it. It worked when I test booted it, but there must be something different in David's machine than mine that I hand't considered. Warner From owner-freebsd-current@freebsd.org Mon Dec 25 15:13: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 19676E9091F; Mon, 25 Dec 2017 15:13:41 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A133567CFF; Mon, 25 Dec 2017 15:13:36 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.179.219.206]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LdKs1-1fBNmY2vFh-00iS6D; Mon, 25 Dec 2017 16:13:27 +0100 Date: Mon, 25 Dec 2017 16:12:54 +0100 From: "O. Hartmann" To: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org Subject: BUG: LLVM: : CommandLine Error: Option 'enable-value-profiling' registered more than once! Message-ID: <20171225161321.52613f60@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: 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_/Ze6z_0og.4QZ2NhNKG7uuvI"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:5AJ81/SHMKtTcRiSHtw24Z5V+OVvIGOhmtI5UqCNaFPqyqmd+qJ q8bpm1D0VQdIY9OmhJ8rMo27Jn5jt5k6vx+7j8cah8d70AAHnQkwtnevR2BonMYQtKevpaC twTKqgrr/Nn25n9xfFn9ixR1XRmz4VBMH3szUBsjRp6eUJtX4CcTJzEGeEnwZJWQ2R0+tbI YV519tM2FNZ/yK2J/t5Lg== X-UI-Out-Filterresults: notjunk:1;V01:K0:fMWYCBAEjaA=:j72S2d/sqrIYCr/9JpzsVQ 4Xh6sYWeAWMmAVAe4cfyStssTIpesJr8UcKf+TqQ6WADcMGv3vtjukK5uZw7Q2Xq/+ks4fmq5 X+qwkwqg1uz+nBdEa6G4pAINITRuaUMpIdX4IpgzK38vi+GHwu6TLivY/syFloMndhPYrNSSu UJLs7hcEgNEKpAXQ0PE0rRW9/QejitdpXBAObTp/V9g4MxOeOkeLVbqAXseTVULepR12qIi5e f3V70bepFPK39TQ0ZrBXAar34l6b1Es1b1rFKyvxvKoM76Jv1B89ClfXAYpSPtWOLm71ni8YO ZUS7N6Fyilxnfui3FZ3/66gYEKXq1lwFNwX5FKu0KcD3dQFyoee/Ld1LooSnuXbjNTwffSaGw +ZGucizfIZhEdd0jjhedVmEG4c5XZHfQqkZxkd5uMCi2rcOzDYtSGdH9JY2yc40z08KK7v6oh XJy1rfKSu+P3cST7BYo9/+1a36AonWi+j34vL9RZbT0CserSAMP/Ab2u7NhYWtv7NWvT3msJM As2HKz6cxipfPvHN3jC7F8q9AD9zaXCvR7a8gBC9aZjIUYAl7r+t7atpYFp9q31VnxrERC69L Ia7CPJfmmGiCykFZRCRfg709aP2YBQ0XvnpMBdeNVL1AOqanAWtJzbPDoswRoq9U2R2jQwyXC c7tez4BQbyNuvIiI8IS2qJ35fO6Fo1CEUcuhbNIE0MUKD4lVeaG4pmT1l3b6K4hI0SSPRPOxV 0kE5+/fgNZLtZg25hQTi858xsN+LP4pqGCUdq9oI1Ew4grnckzCkz768xH4CrSOVycKqRfbF/ ht7MkKXG+hb3QwDO5ZmvIkbEmcOJw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 15:13:41 -0000 --Sig_/Ze6z_0og.4QZ2NhNKG7uuvI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not a compiler expert and I have some serious trouble getting port lang= /pocl to work properly. I'm on CURRENT (FreeBSD 12.0-CURRENT #79 r327170: Mon Dec 25 03:3= 5:27 CET 2017 amd64). The problem persits on both LLD_IS_LD set or not. Whenever lang/pocl in combination with devel/ocl-icd is installed and more = than one OpenCL ICD is installed with lang/pocl, any client (compiled with lang/pocl) or po= rt/package utilising OpenCL in any way (see graphics/blender PR23879 or devel/clinfo, = bails out with: : CommandLine Error: Option 'enable-value-profiling' registered more than o= nce! LLVM ERROR: inconsistency in registered CommandLine options Looking at the POCL repo at github gives noch much help about this, they cl= osed an error report stating it isn't POCL related, but a long-standig LLVM issue, please= see https://github.com/pocl/pocl/issues/474. Searching the net for this sepcific error reveals this bug at llvm.org's bu= g report: [...] Don't link ObjCARCOpts twice. Fixes PR22543 https://reviews.llvm.org/rL240104 Taken that information, the "bug" is considered solved - but it is lldb rel= ated, not lld or whatever is causing the error for POCL!=20 I also found this one, still open: [...] Bug 22952 - cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken=20 https://bugs.llvm.org/show_bug.cgi?id=3D22952 I do not have the experience, brains and resources to look into this matter= any deeper, so I'd appreciate someone with insight into LLVM could take a look at this. When I look what OpenCL ICDs are installed apart from lang/pocl on my boxes= , I see this installation: 5618138 -rw-r--r-- 1 root wheel - 33B Dec 25 03:35 intel-beignet.icd 5618040 -rw-r--r-- 1 root wheel - 19B Dec 17 15:48 mesa.icd [5617930 -rw-r--r-- 1 root wheel - 31B Dec 23 11:21 pocl.icd] Testing with port devel/clinfo and with(!) lang/pocl installed, gives the e= rror I stated initially. Deleting lang/pocl, devel/clinfo dies any way with this error: [...] Unable to find symbol pthread_mutexattr_setkind_np version (null). Aborting. Abort or it simply hangs [Ctrl-T]: load: 0.12 cmd: clinfo 82286 [uwait] 46.78r 0.02u 0.00s 0% 50964k Something isn't right here. A far more serious port is graphics/blender. With usage of OpenCL and havin= g lang/pocl installed, I receive the error initially mentioned.=20 I've provided a DIFF to to the (marked broken) lang/pocl version 0.14 (for = this sepcific PR see Bug 223032 - [PATCH] lang/pocl: pkg-static fails due to wrong pkg-pl= ist entries, look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223032): POCL 1.0: Bug 224584 - [PATCH] lang/pocl: fix pkg-plist and update to POCL 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224584 Hopefully,someone has the time to have a look into this. Kind regards, Oliver --=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_/Ze6z_0og.4QZ2NhNKG7uuvI Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkEVkQAKCRDS528fyFhY lJcaAgCC6Mrr0eOaS1TSpLLHOumzAh1xcocrmo84fIHk4tF10mtzuMe8h6CE03P6 YI9DR8Ukk6f3INhzdUsM8riaEee1Af9XsQoukj/dxzTl/Mg4bprLIB3z1VFSXWWd 9Dq5Azzxo19qQUDxAIg/BKKd6nuuLJ+Lo0usmCB9tejNclv8cI8f =7laV -----END PGP SIGNATURE----- --Sig_/Ze6z_0og.4QZ2NhNKG7uuvI-- From owner-freebsd-current@freebsd.org Mon Dec 25 20:16: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 A7F2AEA40AC for ; Mon, 25 Dec 2017 20:16:23 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 415A0719E6; Mon, 25 Dec 2017 20:16:22 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id vBPKG7l0079885 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=OK); Tue, 26 Dec 2017 07:16:14 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id vBPKG1cf000309 (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Tue, 26 Dec 2017 07:16:01 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id vBPKG1g3000308; Tue, 26 Dec 2017 07:16:01 +1100 (AEDT) (envelope-from peter) Date: Tue, 26 Dec 2017 07:16:01 +1100 From: Peter Jeremy To: Dimitry Andric Cc: freebsd-current@FreeBSD.org Subject: Re: Unable to build 12-current/amd64 Message-ID: <20171225201601.GD5042@server.rulingia.com> References: <20171223095633.GA52398@server.rulingia.com> <962D6B67-8D38-4483-B8D3-933FA483C364@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vEao7xgI/oilGqZ+" Content-Disposition: inline In-Reply-To: <962D6B67-8D38-4483-B8D3-933FA483C364@FreeBSD.org> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 20:16:23 -0000 --vEao7xgI/oilGqZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Dec-23 13:42:40 +0100, Dimitry Andric wrote: >On 23 Dec 2017, at 10:56, Peter Jeremy wrote: >>=20 >> Since r326496, buildworld on my 12-current/amd64 system has consistently >> died as follows. >... >> /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: f= atal error: 'emmintrin.h' file not found >> #include >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >>=20 >> Stop. >> make[4]: stopped in /usr/src/lib/clang/libclang >>=20 >> I'm building on a 12.0-CURRENT VirtualBox guest at r326430. I've checked >> that my /usr/src is clean and deleted /usr/obj to no effect. I have dug >> into SourceManager.cpp and the #include is protected by a #if __SSE2__, >> which is relying on clang internal checks to define (and my CPU supports >> SSE2). Does anyone have any ideas to explain what is going on? > >First of all, does your host system have emmintrin.h? E.g. what is the >output of "find /usr/lib/clang -name emmintrin.h" ? Aha. Somehow my entire /usr/lib/clang/5.0.0 tree was missing. I'm not sure if that was an installworld glitch or something I accidently did. In any case, restoring it has fixed the problem. Thanks for the pointer. --=20 Peter Jeremy --vEao7xgI/oilGqZ+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJaQVyBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0tOkP/2qmAq3fkkWIW6Viv8nDvoUj xGkZc0sdO+cC5mFc+jfjNoLoQz0iwsGt6EjZs0jE/tnYCdq+fnty9HYLUBV7nDWQ GMhC2bLbBK4CAaqurk9er6SP8AqeQQNjWhgNsuNPMb27YQbCxnbo00klMIuQDphu crmNfSxlxlpFKHp5dw18NpM7Z7LkoWOnAF1hO/MZztLAAbVZx4huwK2bqgerBOCy 59NfxF7aqOYOahEyLgZC6d8kfWh1cPbDsQaySyZ7Mw+38T6UKnNFbHtSODnxS4m9 cvMeU+QjqdszrXDEY4HAEkMrxVLBqq/khkflE9lUFlihMrBNlNTF/ZKhmLkJP2Ke WPvE5slzucLYD6MzuDQa98zlQSH55PPpszJkr2V3A/VmukeBMSXodQfOBMS8PMnn B982UMqaYV/i0y4N7+D2xO2GnFO9KzFhw8Boze+5cxqE4ghPFlADiH8t8GhZTtZ2 72eEqDnI2jaMJdG85/Ya+T21tkqBWVqhzHd1MrOvW6QopYOtPSXleBqYpgql/ltJ rO2JTANZEQtBcrktlHelX/pJdqvHC3MSAaGVsJ4RuLNFx2sM4Z1rt60YhVwzkHMo OhIt0p2//DnjzP+oQrl8cDMLUCE+7lIt0EhBKLtTvkQS24YAapHXvNpgLaDdIgY9 9Rtt3i59i9bhSQTTZD2i =SmdT -----END PGP SIGNATURE----- --vEao7xgI/oilGqZ+-- From owner-freebsd-current@freebsd.org Mon Dec 25 20:16:56 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 62DD4EA41AD for ; Mon, 25 Dec 2017 20:16:56 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 BE2F271B25 for ; Mon, 25 Dec 2017 20:16:55 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPZuP-1eXfuP40kD-004ha9 for ; Mon, 25 Dec 2017 21:16:53 +0100 Date: Mon, 25 Dec 2017 21:16:24 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: LLD: man pages missing? Message-ID: <20171225211651.7e865c84@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_/FWlE9yL25mDl/eRwbc9.z1s"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:DJZV9aXdMoJESJNddx7jkfCRYXB+TyZhRd7pyzhQPM0cFXf3iWv ye0W9UtzHhrKCZ8iTuFqpJS+dXL7y1B53NcRix3g5kgxTnHwjF64n1hZlum/IarVh6t+8nB HzERfztkhHBr0+nvEKEzQfJwffpSmS17na2ExvT0F5kIRxU88c+QiPy9OvEKxVNHEVTUvkj 2raH7jval+wvbhD3q/liw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SlWkX/ulB7I=:86hBiBQ+O7rfPs8/9Emk4P WSIPI6/lrSZ/+D4WEQRl0gilOUHaawPkOtiOWGRREoK+H0RM75QGtI+1tnddli2Ghb9OptuR0 5kmMTGJ6vFiEDOyr13TetLegin7ZDzp63aWB+1xe7ZLmfzjmL5150QMgF/89Ql2wvKLtXX3/Q 5ukFws64Sv2uxJNB0Dpdp9zAk/THK+OlLIY8ajS4GrbdqBDDDUJfzmQsRAnsrmJf+jZnCeOYC 6yfAUBnVNibt1TtLySeIrlEqrH4QdTTjz8VIVhv6u7FYBrfIaYiggCmaMwXEdTpKQ0/DCOY/8 /1L+AkqnMUPuWkUauuiusxUsB+OGwKDQArEwuwNFH5d0Cx2wHznwh62vHEZQSnBa7CbpwfnVM dN/xqI3H2TsRipAvGFg7illAZuR/PEnH2JAC0qb1Qj7spnYag6fvu9eSXK6RRQh9TtNSXOpXX 2vkdeQWOo0xoi90XxOqXwexIj/KR2sK1WKabyJpDCPYDAuecd359+sPl5ao8GcDhQYV/juSZ1 l3xJf+vRE76d4aWeb2N7QEH65sTV97lS+XNkLmWZIYviyWlFRw93B3q6kIyyUz/jeNcXgD8vJ /rMH4c1oaql66bAFqkUVOfF67NBLodABaB1WpXiPbgjuoSJljyz2NlSBn4L0OOpMAQYUq2lc0 nxFrO7nsm8Q/XM0QvNvVSA3Zbp76kUGdzDLR4HqhFZ178D3n7m7jtr6ZpK2Clhy/lBJDsdRjq t76mycXsr8XSKTjhoP856ovuc1WFPOkI3QnybwjRTsVoo8w1keSfdnAyg0HnpLiey3wtjS1tB KFY8FvNFwM4RAofBkJkMLQUFEElHQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 20:16:56 -0000 --Sig_/FWlE9yL25mDl/eRwbc9.z1s Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have installed most recent CURRENT as of r327219 with LLD_IS_LD=3DYES set via /etc/src.conf. I try to find some options and tried "man ld", "man lld" and "ld.lld". In t= he the latter two cases there can nothing be found on the system and man ld always seems = to refer to the GNU linker - which is, I believe, the linker reached by /usr/bin/ld.bfd= . There is also a linker "ld" in /usr/local/bin/ld from binutils-2.28,1. Can someone help? Thnaks, 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_/FWlE9yL25mDl/eRwbc9.z1s Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkFcswAKCRDS528fyFhY lP5UAf9sz0+IiBFHkQuYRPw7a3m2/HMIaliENfHEd90/hXzFaqjtZdnR4iY/rRjW bGDFZ677UATP2jRzdxZfxAaSQIBPAgClThz+iqfhZXm0YxqNi/Fo6iu5Pp0ZhI82 zU4r/dmeJo/CWLL9p6JuegeqEBS7AdKRzEDOpY7jKIwSbb8m/Ae8 =VpUK -----END PGP SIGNATURE----- --Sig_/FWlE9yL25mDl/eRwbc9.z1s-- From owner-freebsd-current@freebsd.org Mon Dec 25 20:25: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 246F4EA491A for ; Mon, 25 Dec 2017 20:25:13 +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 D8E9E721F4; Mon, 25 Dec 2017 20:25:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (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 7612310CD9; Mon, 25 Dec 2017 21:25:03 +0100 (CET) From: Dimitry Andric Message-Id: <803F0529-9A47-4627-B9B0-B75BC45556AD@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_00766397-16A7-4F9C-9907-1D2ECCA580AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: LLD: man pages missing? Date: Mon, 25 Dec 2017 21:25:02 +0100 In-Reply-To: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> Cc: FreeBSD CURRENT , Ed Maste , Rafael Avila de Espindola To: "O. Hartmann" References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 20:25:13 -0000 --Apple-Mail=_00766397-16A7-4F9C-9907-1D2ECCA580AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Dec 2017, at 21:16, O. Hartmann wrote: >=20 > I have installed most recent CURRENT as of r327219 with LLD_IS_LD=3DYES = set > via /etc/src.conf. >=20 > I try to find some options and tried "man ld", "man lld" and "ld.lld". = In the the latter > two cases there can nothing be found on the system and man ld always = seems to refer to > the GNU linker - which is, I believe, the linker reached by = /usr/bin/ld.bfd. There is > also a linker "ld" in /usr/local/bin/ld from binutils-2.28,1. There is no manpage yet. Upstream provides a bit of Sphinx-based documentation (e.g. in .rst format), but there is no specific manpage. Since lld is now approaching a quite usable state, maybe it is time for a request to upstream to provide one. ;) -Dimitry --Apple-Mail=_00766397-16A7-4F9C-9907-1D2ECCA580AA 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.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWkFengAKCRCwXqMKLiCW owT8AJ9C6vgDEjO2mDSDdSe0DfDtCsCffwCgwP81KGiZyYuz47GhuCZDBV5yTJY= =op3d -----END PGP SIGNATURE----- --Apple-Mail=_00766397-16A7-4F9C-9907-1D2ECCA580AA-- From owner-freebsd-current@freebsd.org Mon Dec 25 20:46: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 19E99EA5A32 for ; Mon, 25 Dec 2017 20:46:58 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 A068372C88 for ; Mon, 25 Dec 2017 20:46:57 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-wm0-x22a.google.com with SMTP id b199so32999912wme.1 for ; Mon, 25 Dec 2017 12:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VO51WDC01D6VihthjnRx803u67cfOZBs/h5t5WHTjsc=; b=aSieIdSZ4xGQfplN4xXbRvIBLg7vQ6laPdq4bcihvt7VID77P46JHBfgtAGAlsmvno /qqaUOvWA3K9utueXLBXu5Z6+/i/fYb4C/Q6tvOipcRxTDTfTM3Ri9SpJkF3fCw1QOaI AOb+4IQN+5gidld5gO33cDiO9xAMbKnhtXq7t8iMKCzI627mlFCB+crgT5rIlXQQ6BQS JFvFFIgjqVbb2LlhDwFp+s7t7shZSsIaj5Y5ywab/URWylKhEpvnAvrooh79F9wLNFP6 sYsckqz66uoEr4a2EIiWxPCuHpwaEFoLmAv7zv5C+oEtM7srMwWVS/Z6geutPI8DQytZ FTMg== 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=VO51WDC01D6VihthjnRx803u67cfOZBs/h5t5WHTjsc=; b=UjbZumJyel7+ydGKR+YpBKYd6KjCTWsc+5f96BF0GEcPBwgIBM4TD6I+L2uXwKnK7T kM8aYQ//R9lGiPZZ7ISh2GBaW1IMKsMKqeWD/jjWDx+Qgf/M5rOWozc5mlYT8Kh2Bj9m N4ICdWofV8jmME8YxLyn3IxiS693XuYcA+aDT+XWd10v2UFWBbzIUESgBQAdOklnEuES d8DlbWznxz7RN7UtdwOg3GBxaeos620ogdEiLCGjLJhpbUMoLIGWv92tVuRIphlMmMxq avQcJB4CY6xxXqk9R5ZpWpE8s9eAmkc74RUYFNtqXUxdDJjsACTwj84Izfh8eVTgVOC7 gDmQ== X-Gm-Message-State: AKGB3mLOPiiNaAgtE5p7cq9VctbawwYo3hzgHfXGOMok79PZSOmjN1kR D6XzduiIcA2BSeeZDfWw7FSxJA19noo1CjXKT49OuA== X-Google-Smtp-Source: ACJfBosZCGOGWaSmaU4zn8KNjcl/Lwg/Wu9yM3wfpj06NKbkQCjQoQaeqm3SmkCplS1L5+4GSWGprr4xUa0ksG9TPso= X-Received: by 10.80.224.198 with SMTP id j6mr28078339edl.0.1514234815675; Mon, 25 Dec 2017 12:46:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.149.174 with HTTP; Mon, 25 Dec 2017 12:46:55 -0800 (PST) In-Reply-To: <803F0529-9A47-4627-B9B0-B75BC45556AD@FreeBSD.org> References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> <803F0529-9A47-4627-B9B0-B75BC45556AD@FreeBSD.org> From: Oliver Pinter Date: Mon, 25 Dec 2017 21:46:55 +0100 Message-ID: Subject: Re: LLD: man pages missing? To: Dimitry Andric Cc: "O. Hartmann" , FreeBSD CURRENT , Ed Maste , Rafael Avila de Espindola Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 20:46:58 -0000 On Monday, December 25, 2017, Dimitry Andric wrote: > On 25 Dec 2017, at 21:16, O. Hartmann wrote: > > > > I have installed most recent CURRENT as of r327219 with LLD_IS_LD=YES set > > via /etc/src.conf. > > > > I try to find some options and tried "man ld", "man lld" and "ld.lld". > In the the latter > > two cases there can nothing be found on the system and man ld always > seems to refer to > > the GNU linker - which is, I believe, the linker reached by > /usr/bin/ld.bfd. There is > > also a linker "ld" in /usr/local/bin/ld from binutils-2.28,1. > > There is no manpage yet. Upstream provides a bit of Sphinx-based > documentation (e.g. in .rst format), but there is no specific manpage. > > Since lld is now approaching a quite usable state, maybe it is time for > a request to upstream to provide one. ;) The same would be nice for clang too. Its default man page is poor. > > -Dimitry > > From owner-freebsd-current@freebsd.org Mon Dec 25 21:01: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 95845EA65F4 for ; Mon, 25 Dec 2017 21:01:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 664B2735D7 for ; Mon, 25 Dec 2017 21:01:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id vBPKX3ZM089823 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Dec 2017 12:33:03 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id vBPKX3m0089822; Mon, 25 Dec 2017 12:33:03 -0800 (PST) (envelope-from sgk) Date: Mon, 25 Dec 2017 12:33:03 -0800 From: Steve Kargl To: "O. Hartmann" Cc: FreeBSD CURRENT Subject: Re: LLD: man pages missing? Message-ID: <20171225203303.GB89519@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 21:01:20 -0000 On Mon, Dec 25, 2017 at 09:16:24PM +0100, O. Hartmann wrote: > > Can someone help? > There isn't a lld.1 manpage. grep MAN /usr/src/usr.bin/clang/lld/Makefile MAN= google 'man lld' eventually get one to https://lld.llvm.org/#using-lld which leads one to assume that there is no documentation for lld. -- Steve From owner-freebsd-current@freebsd.org Mon Dec 25 23:56: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 9CCBDE82C7B; Mon, 25 Dec 2017 23:56:25 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 EE51079001; Mon, 25 Dec 2017 23:56:21 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-c8dff70000003990-47-5a41901c401c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A1.1E.14736.C10914A5; Mon, 25 Dec 2017 18:56:12 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id vBPNuAGT021437; Mon, 25 Dec 2017 18:56:11 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBPNu6hN017279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Dec 2017 18:56:09 -0500 Date: Mon, 25 Dec 2017 17:56:07 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2017 Message-ID: <20171225235606.GE59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsUixCmqrCszwTHKYEe7gsWua6fZLea8+cBk sX3zP0aLw81CDiweMz7NZwlgjOKySUnNySxLLdK3S+DK+Nw3naXg9T6mip0n/zM3MD79ydjF yMkhIWAiceXka7YuRi4OIYHFTBIrf/xihXA2Mko8+j2fHcK5yiRxZs1sNpAWFgFViWs/v4HZ bAJqEutXXGMGsUUE5CX2Nb1nB7GZBawl/j1oBIsLC9hK9H9dClbPC7Su6/lcKFtQ4uTMJywQ 9WUSL243AtkcQLa0xPJ/HCBhUQFlib19h9gnMPLNQtIxC0nHLIQOiLCOxM6td9gwhLUlli18 zQxh20qsW/eeZQEj+ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzgAJfk38E4 p8H7EKMAB6MSD++BCMcoIdbEsuLK3EOMkhxMSqK8ZdMcooT4kvJTKjMSizPii0pzUosPMaoA 7Xq0YfUFRimWvPy8VCURXmeQOt6UxMqq1KJ8mDJpDhYlcV53E+0oIYH0xJLU7NTUgtQimKwM B4eSBK9rP9BOwaLU9NSKtMycEoQ0EwfnIUYJDh6g4fNBaniLCxJzizPTIfKnGMM5jm26/IeJ 48CEK0Dy1MPbQPLRjbtAcsX/e0Dy2czXDcwc845/a2LmOPT7UCuzENitUuK8e0DGCYCMyyjN g9sISoIS2ftrXjGKAwNDmLcapIoHmEDhdr4COocJ6Jx0T3uQc0oSEVJSDYw7L+lxTmlL/9p/ POBp35/AsDXidwJNYstW/tSO+Frc0rvo1M3J52YvOnunkPfTqe5FSXov2yI6ziyO1l5ioMrc 9FPgQ+u2Rbm+1VW5Z5z3nVx+YmOHdbCL962FvfNa1otMTFjn80j43t6///tbf9b/VFY0LjRd VzRN7czE1becllQ3CdlsPMyuxFKckWioxVxUnAgAhkbwcV0DAAA= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 25 Dec 2017 23:56:25 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - 3rd Quarter 2017 This quarter's FreeBSD developments continue to provide excitement and promise for further developments. I myself have a soft spot for manual pages, so it is especially good to see that we have gained some documentation for writing them (and I hope that this will translate to more and improved manual pages in the future!). The core@ entry is also of particular note, with the introduction of the FCP process and the recognition of the first non-committer FreeBSD Project Member (and more). Read on to find out more about these, as well as improved support for the AMD Zen family of processors (e.g., Ryzen), and a whole lot more! --Benjamin Kaduk __________________________________________________________________ The deadline for submissions covering the period from October to December 2017 is January 14, 2017. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Release Engineering Team * Ports Collection * The FreeBSD Core Team * The FreeBSD Foundation Projects * FreeBSD CI Kernel * Intel 10G iflib Driver Update * Intel iWARP Support * pNFS Server Plan B Architectures * AMD Zen (family 17h) support Userland Programs * Updates to GDB Ports * FreeBSDDesktop * OpenJFX 8 * Puppet Documentation * Absolute FreeBSD, 3rd Edition * Manual Pages Third-Party Projects * The nosh Project __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Release Engineering Team Links FreeBSD 11.1-RELEASE Announcement URL: https://www.FreeBSD.org/releases/11.1R/announce.html FreeBSD 10.4-RELEASE Schedule URL: https://www.FreeBSD.org/releases/10.4R/schedule.html FreeBSD Development Snapshots URL: https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes, and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team continued finalizing the 11.1-RELEASE cycle, with the final release builds starting on July 21 and the official release announcement email sent on July 26. Thank you to everyone who helped test 11.1-RELEASE, ensuring its quality and stability. [1] FreeBSD 11.1-RELEASE is the second release from the stable/11 branch. Additionally, the FreeBSD Release Engineering Team started the 10.4-RELEASE cycle, with the code slush starting on July 28. With the final release build expected to start on September 29 and the official announcement overlapping the end of the quarter, everything is on schedule as of this writing. [2] FreeBSD 10.4-RELEASE will be the fifth release from the stable/10 branch, and is planned to be the final release of the 10.x series. This project was sponsored by The FreeBSD Foundation [1]. This project was sponsored in part by The FreeBSD Foundation [2]. __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team Website URL: https://www.freebsd.org/portmgr/index.html FreeBSD portmgr on Twitter (@freebsd_portmgr) URL: https://twitter.com/freebsd_portmgr/ FreeBSD Ports Management Team on Facebook URL: https://www.facebook.com/portmgr FreeBSD Ports Management Team on Google+ URL: https://plus.google.com/communities/108335846196454338383 Contact: Ren=E9 Ladan Contact: FreeBSD Ports Management Team The Ports Collection now features over 31,600 ports. There are currently 2671 problem reports, of which 718 are unassigned. This quarter saw almost 5,900 commits from 175 committers. The number of open PRs grew compared to last quarter, and outpaced the number of changes. This quarter, we welcomed Zach Leslie (zleslie@), Luca Pizzamiglio (pizzamig@), Craig Leres (leres@), Adriaan de Groot (adridg@), and Dave Cottlehuber (dch@) as new committers. The commit bits of the following committers were taken in for safekeeping: alonso@ after 19 months of inactivity, rpaulo@ per his request, and ache@ after he passed away. Despite several tries and changing mentors, kami@ lacked interest in completing his mentorship, so his commit bit was also taken in for safekeeping. On the infrastructure side, two USES values were removed because they outlived their usefulness: * execinfo: libexecinfo is now available in the base system of all supported FreeBSD versions * twisted: there is only one Twisted port left The default version of GCC was bumped from 5 to 6. Firefox was updated to version 56.0 and Chromium to version 61.0.3163.100. The version of pkg itself was updated to 1.10.1. During this quarter, antoine@ performed 28 exp-runs to test version updates of major ports, improving USE_GITHUB and SHEBANG_FILES, and API changes to the base system. This quarter, the foundation for ports "flavors" was committed, though more development and testing will be performed in the coming quarter before it goes live. Open tasks: 1. The PR load needs more attention, as the number of open PRs has started to increase again. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The new "FreeBSD Community Process" was drafted during BSDCan earlier this year. The first such document, FCP 0, defines how the whole process works. After some time for discussion and revision, FCP 0 was voted on and accepted by core, following the procedure laid down within that document. Currently the use of FCPs is entirely optional; we shall see how the community begins to adopt their usage and evolve the process based on experience. A draft update to the Code of Conduct has been prepared by the advisory committee. Core is currently reviewing the text, and will soon vote on accepting it. Core is keen to avoid the trap of "rules lawyering". At the moment, the feeling is that we need to add a preamble to the CoC to articulate the goals of the project and to act as a general guide to the exercise of the code. This quarter has been quite a busy one concerning changes to the roster of committers and project members. We have elected our first new Project Member: John Hixson, who will be familiar from many conferences where he has given presentations and ably represented iXsystems. A second proposed Project Member was not accepted by core, but only because core felt that Fedor Uporov really deserved a commit bit instead. In addition to Fedor Uporov, please also welcome (in no particular order) Matt Joras, Marcin Wojtas, Chuck Tuffli, Ilya Bakulin and Alex Richardson as brand-new committers. We have also awarded Steven Hurd and Eugene Grosbein src commit bits to go with their existing ports bits. Welcome back Gordon Tetlow as a src committer, essential for his new role within secteam. Eric Davis and Rui Paulo have both decided to hang up their commit bits: we wish them well in their future endeavours. Finally, we must report the sad death of Andrey Chernov, who will be sorely missed by his colleagues and collaborators. Andrey's death has highlighted another question which is only going to become more complex over time. Keeping track of copyrights is already hard enough within a mature source tree with many contributors, such as the FreeBSD sources. Now we need to consider trying to keep track of the heirs and beneficiaries of contributors who have sadly passed away. Core will consult with the Foundation legal team to discuss possible approaches to alleviate this. There have been complaints that the workings of Core are being kept overly confidential, and that consequently the majority of the project has too little idea of what is going on. This is certainly not intentional by Core, and we are keen to open up Core's business to more general community scrutiny as far as seems reasonable. Core dealt with a number of licensing questions: * When upstreaming patches and other original works to VirtualBox or other Oracle properties, pragmatically it works best to provide them under the terms of the MIT license (one of two opensource licenses accepted by Oracle). Of course, this only applies to work upstreamed by or with the permission of the original author. * The Viking software license is sufficiently BSD-like that magic constants from their drivers can be used in FreeBSD code. * There is no separate register of deviations from the allowed BSD-like licenses in the source tree: any code in the tree under other than BSD-like license terms can be assumed to have been approved by core. * At the moment the FreeBSD copyright requirement to include the copyright notice in redistributions in binary form is satisfied by making the FreeBSD sources, with all of the detailed copyright information included in the different source code files, available alongside pre-compiled system images. However, this does not necessarily meet the needs of downstream projects based on FreeBSD, and given the new "packaged base", adding per-package licensing metadata in a way similar to how the Ports Collection works is under consideration as an alternative mechanism. Concerns were raised regarding the pending HardenedBSD entry in the previous quarterly report prior to publication. The FreeBSD project welcomes reports from separate (but derived) projects in quarterly reports and has included similar reports in the past from other projects (such as TrueOS and pfSense). The HardenedBSD report was edited for length and to concentrate on activities during the quarter in question. Amazon is proposing to set up mirrors of the freebsd-update and pkg servers within AWS in order to provide faster access for EC2 users. These mirrors will be publicly accessible, but the expectation is that use will primarily be from within EC2. FreeBSD AMIs will have a preset configuration that references the Amazon servers. The old, long-deprecated, and insecure "r-commands" (rsh, rlogin, rcp) are being removed from the base system for 12.0-RELEASE. Notice of this was added to the man pages and release notes in time for 11.1-RELEASE and 10.4-RELEASE. Anyone requiring these commands for backwards compatibility can use the new net/bsdrcmds port. Work to replace Heimdal Kerberos in base with the more widely compatible MIT Kerberos has begun in a new projects/krb5 branch. This should not fall afoul of any US cryptography export regulations: the project is required to notify the US government that cryptographic software can be downloaded from FreeBSD servers, and this already covers MIT Kerberos, already available within ports. A number of Bay Area FreeBSD User Group-related domain names are being given up by their original owner. The current BAFUG organisers have been made aware. Core has voted on a change to the Doceng voting rules to provide for a "did not vote" status during doceng voting similar to how portmgr and core voting operates. The current requirement for all five members of doceng to register a vote on issues was proving to be a significant bottleneck. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Website URL: https://www.FreeBSDFoundation.org/ FreeBSD Foundation Quarterly Newsletter URL: https://www.FreeBSDfoundation.org/wp-content/uploads/2017/08/FreeB= SD-Foundation-July-August-2017-Update.pdf Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides full-time Release Engineering support; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts Our work is 100% funded by your donations. This year we have raised over $860,000 from over 500 donors. Our 2017 fundraising goal is $1,250,00 and we are continuing to work hard to meet and exceed this goal! Please consider making a donation to help us continue and increase our support for FreeBSD: https://www.FreeBSDfoundation.org/donate/. We also have a new Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation improves the FreeBSD operating system by employing our technical staff to maintain and improve critical kernel subsystems, add features and functionality, and fix problems. This also includes funding separate project grants like the arm64 port, blacklistd access control daemon, and the integration of VIMAGE support, to make sure that FreeBSD remains a viable solution for research, education, computing, products and more. We kicked off or continued the following projects last quarter: * OpenZFS RAID-Z Expansion project * Broadcom Wi-Fi infrastructural improvements (bhnd(4) driver) * Headless mode out-of-the-box for the Beaglebone Black * Extending bhyve/ARMv7 features * Porting bhyve/ARM to an ARMv8 platform Having software developers on staff has allowed us to jump in and work directly on projects to improve FreeBSD like: * ZFS improvements * New Intel server support * kqueue(2) updates * 64-bit inode support * Stack guard * Kernel Undefined Behavior Sanitizer * Toolchain projects * i915 driver investigation * NVDIMM support in acpiconf(8) * Continuous integration dashboard (web page and physical hardware) * FAT filesystem support in makefs(8) Staff and board members continued hosting bi-weekly conference calls to facilitate efforts for individuals to collaborate on different technologies. Release Engineering The Foundation provides a full-time staff member to lead the release engineering efforts. This has provided timely and reliable releases over the last few years. Last quarter, our full-time staff member worked with the FreeBSD Release Engineering and Security Teams to finalize 11.1-RELEASE. He also supported the 10.4 release effort, and has continued producing 10-STABLE, 11-STABLE, and 12-CURRENT development snapshot builds throughout the quarter. At the vBSDCon Developer Summit, he gave a presentation on the state of the release engineering team. You can find out more about the support we provided to the Release Engineering Team by reading their status update in this report. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Here is a list highlighting some of the advocacy and education work we did last quarter: * Organized and ran the Essen FreeBSD Hackathon in Essen Germany * Sponsored and participated in the FreeBSD Developer Summit BSDCam, in Cambridge, England * Represented FreeBSD at the ARM Partner Meeting * Presented and taught about FreeBSD at SdNOG 4 in Khartoum, Sudan * Sponsored and gave presentations and tutorials at EuroBSDCon in Paris, France * Organized and ran the Paris FreeBSD Developer Summit * Organized and ran the FreeBSD Developer Summit at vBSDCon * Sponsored and attended vBSDCon * Proved travel grants to FreeBSD contributors to attend the above events. * Sponsored the 2017 USENIX Security Symposium in Vancouver BC as an Industry Partner * Provided FreeBSD advocacy material * Sponsored the 2017 USENIX Annual Technical Conference in Santa Clara, CA as an Industry Partner We continued producing FreeBSD advocacy material to help people promote FreeBSD around the world. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. Last quarter we published the July/August issue that you can find at https://www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https://www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org to find out how we support FreeBSD and how we can help you! __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD CI Links freebsd-ci Repository URL: https://github.com/freebsd/freebsd-ci freebsd-testing Mailing List URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing FreeBSD Jenkins Instance URL: http://ci.FreeBSD.org Contact: Jenkins Admins The FreeBSD CI team runs various continuous integration solutions for FreeBSD, regularly checking that the current state of the Subversion repository can successfully build, and performing various tests and analysis upon the build results. We have introduced a DTrace test pipeline, with the results and artifacts available at: * https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/ * https://artifact.ci.FreeBSD.org/dtrace-test/ We had team meetings at two developer summits during Q3: * BSDcam * EuroBSDCon Open tasks: 1. Fix the failing test cases and builds. 2. Create builds for additional architectures. 3. Add more tests. 4. The additional TODO items listed at https://wiki.FreeBSD.org/Jenkins/TODO . __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. Intel 10G iflib Driver Update Links ixgbe iflib Conversion URL: https://reviews.FreeBSD.org/D11727 Contact: Chris Galazka Contact: Piotr Pietruszewski The ix and ixv network interface drivers support a variety of Intel network interfaces, with line speeds at 10 Gbit/second. This quarter, with the help of Matt Macy and Sean Bruno (among others), we have submitted a review in Phabricator for the conversion of the ixgbe driver to use the new (and evolving) iflib framework. Stay tuned for the conversion of the 40G driver (ixl), as it is currently being ported to use iflib. Open tasks: 1. Additional testing. __________________________________________________________________ Intel iWARP Support Links iWARP for ixl URL: https://reviews.FreeBSD.org/D11378 Contact: Bartosz Sobczak iWARP is a protocol suite that enables efficient movement of data across the network, building on Remote Direct Memory Access, Direct Data Placement, and Marker PDU Aligned Framing. It endeavors to avoid unnecessary (local) data copies and to offload work from the main CPU to dedicated hardware. An initial commit adding iWARP support for the Intel X722 family of network adapters is under review. This is an important step towards introducing full iWARP support on systems equipped with Intel C620 Series Chipsets. Currently, with the iw_ixl driver, only the kVerbs API is supported. Open tasks: 1. Additional testing. __________________________________________________________________ pNFS Server Plan B Links Instructions for Testing URL: http://people.FreeBSD.org/~rmacklem/pnfs-planb-setup.txt Contact: Rick Macklem A pNFS server allows an NFS service to be spread over multiple servers, separating the MetaData operations from the Data operations (Read and Write). This project will add the ability to use FreeBSD systems to create a pNFS service consisting of a single MetaData Server plus a set of Data Servers. The Data Servers can be mirrored, so that redundant copies of the file data are maintained. The support for non-mirrored Data Servers is now believed to be complete. Support for mirrored Data Servers using the Flexible File Layout, which will soon be published as an RFC, is implemented. However, there is still significant work to be done, since the current implementation of mirrored Data Servers does not handle failed Data Servers or their resilvering/recovery. It is hoped that support for failure/recovery of Data Servers will be implemented in the next six months. The patched FreeBSD sources may now be accessed for testing via either Subversion or downloading a gzipped tarball. They consist of a patched kernel and nfsd and can be used on any FreeBSD 11 or later system. The installation procedure is covered in the linked document. Open tasks: 1. Testing by others will be needed, now that the implementation is available. 2. Implementation and testing of mirror failure/recovery. __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. AMD Zen (family 17h) support Contact: Conrad Meyer cem@FreeBSD.org <> This quarter, a bit of work was done to enhance platform support for AMD Zen (Ryzen, Threadripper, Epyc) processors: * The CPU topology detection code was enhanced to properly detect Zen dies and CPU Complexes. This gives the scheduler more locality information to use when making scheduling decisions. * The x86 topology analysis was enhanced to report dies and CPU Complexes, in addition to the existing reporting on packages, cores, and threads. An example of the new output is FreeBSD/SMP: 1 package(s) x 2 groups x 2 cache groups x 4 core(s) x 2 hardware threads. * The amdsmn(4) driver for accessing SMN (System Management Network) registers was added. * CPU temperature monitoring support for Zen was added to amdtemp(4). * In cpufreq(4): + Added support for decoding Zen P-state information from Machine State Registers (which is usually not necessary, since it is largely redundant with ACPI P-state information, but is potentially useful) + Work around the apparent Ryzen inability to achieve the P1 state by not busying cores waiting to transition to it * The intpm(4) smbus driver was fixed to attach to the AMD FCH (Fusion Controller Hub). * All MCA banks are now enabled and monitored on Zen CPUs. * Feature-bit decoding was added for: CLZERO, SVM features, and RAS capabilities. * SHA intrinsic support was added to the aesni(4) driver. Ryzen is currently the only desktop processor to feature these intrinsics. Support for these intrinsics is also present in Intel's Goldmont line of low-end SoCs. Overall, Zen is now a very usable platform for x86 workstations and servers. This project was sponsored by Dell EMC Isilon. Open tasks: 1. Add HWPMC support for the new performance counters avilable on the Zen architecture. 2. Add support for the CCP (Crypto Co-Processor). __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. Updates to GDB Contact: John Baldwin Contact: Luca Pizzamiglio The devel/gdb port has been updated to GDB 8.0.1. Support for FreeBSD/aarch64 userland binaries has been committed upstream. These patches, along with support for debugging FreeBSD/aarch64 kernels, have been committed to the port. Upstream patches adding improved support for FreeBSD/arm userland binaries are currently in review. FreeBSD 12 has recently grown support for debugging VFP registers via ptrace() and core dumps as part of this work. Support for FreeBSD/arm kernels will be added to the port after the upstream patches are added to the port. Support for $_siginfo has been committed upstream. This uses the recently added NT_LWPINFO note to extract signal information from process cores. Hangs that occured when GDB's kill command was used were fixed in FreeBSD in r313992. Open tasks: 1. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 2. Test support for sparc64 binaries and kernels. 3. Add support for debugging powerpc vector registers. 4. Implement info proc commands. 5. Implement info os commands. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. FreeBSDDesktop Links FreeBSDDesktop on GitHub URL: https://github.com/FreeBSDDesktop/ Contact: Johannes Dieterich Contact: Mark Johnston Contact: Hans Petter Selasky Contact: Matthew Macy The FreeBSDDesktop team is happy to announce the availability of graphics/drm-next-kmod. This port for FreeBSD-CURRENT (amd64) provides support for the amdgpu, i915, and radeon DRM modules using the linuxkpi compatibility framework. The port currently corresponds to the DRM from Linux 4.9 and is in an experimental state. It works reliably for many testers with modern GPU hardware (AMD HD7000 series/Tahiti to Polaris and Intel HD3000/Sandy Bridge to Skylake). Broader testing and reporting/fixing of bugs is appreciated. Open tasks: 1. Resolve issues that cause radeonkms and amdgpu to fail with EFI boot (though there is a workaround available). 2. Upgrade to Linux 4.10 and higher DRM versions. 3. Get feedback from broader testing. __________________________________________________________________ OpenJFX 8 Links OpenJFX Wiki URL: https://wiki.openjdk.java.net/display/OpenJFX/Main java/openjfx8-devel URL: https://www.freshports.org/java/openjfx8-devel java/openjfx8-scenebuilder URL: https://www.freshports.org/java/openjfx8-scenebuilder AsciidocFX URL: https://github.com/asciidocfx/AsciidocFX Contact: Tobias Kortkamp OpenJFX is an open source, next generation, client application platform for desktop and embedded systems, based on JavaSE. This quarter, the OpenJFX port was reworked and has received some significant improvements. More modules are being built. With the new web module we gain support for applications that have their own builtin web browser such as AsciidocFX. The new media module allows JavaFX applications to play audio and video files. A port of the JavaFX scenebuilder, a RAD tool for building JavaFX scenes, was added to the ports tree. The OpenGL Prism backend for GPU acceleration was enabled by default. From a mainainer's and contributor's perspective, the port was simplified by moving all FreeBSD-local patches to the ports tree and fetching the upstream sources directly, instead of using a separate repository for them. Open tasks: 1. Upstream some of the patches in the Ports Collection. __________________________________________________________________ Puppet Links Puppetlab's FreeBSD Slack Channel URL: https://puppetcommunity.slack.com/messages/C6CK0UGB1/ Contact: Puppet Team This summer has seen the creation of a puppet@ team to help maintain the approximately 30 Puppet-related ports in the FreeBSD Ports Collection. These ports were previously maintained by various committers, and from time to time the distributed maintainership introduced some delays when updating a port, due to the need to wait for a maintainer's approval for a related change to a different port. Puppet 5 is now in the ports tree (as sysutils/puppet5). The C++ version of Facter (sysutils/facter) got a lot of attention and is now a drop-in replacement for the previous Ruby version (sysutils/rubygem-facter); it is the default facts source for the Puppet 5 port. Work continues on bringing in Puppetserver 5 to the ports tree, and on keeping all the ports up-to-date. Open tasks: 1. The pkg package provider has some minor issues (it breaks things when no repos are configured, and is not working properly from the context of the MCollective package agent). 2. The databases/puppetdb[345] and sysutils/puppetserver[45] ports rely on Clojure and Java, and download compiled jar files instead of building them from source. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree or new external books/documents. Absolute FreeBSD, 3rd Edition Links Official Announcement URL: https://blather.michaelwlucas.com/archives/3020 Contact: Michael Lucas The first draft of the third edition of Absolute FreeBSD is finished. It is 220,200 words, or roughly enough to stun a medium-sized ox. It's on target to be in print before BSDCan 2018. Open tasks: 1. Stare at the wall blankly for a few days. 2. Fix all the problems pointed out by dozens of community reviewers. 3. Fix all the problems pointed out by John Baldwin, tech reviewer extraordinaire. 4. Editing. Copyediting. Page layout. Page editing. Re-editing. Indexing. Edits discovered by indexer. 5. Pre-orders should open some time next year. 6. Restrain myself from strangling people who ask when the fourth edition is coming. __________________________________________________________________ Manual Pages Links FreeBSD Documentation Project Primer URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Contact: Warren Block Over the last year, interest has increased in manual pages, in large part due to excellent infrastructure work by Baptiste Daroussin and others, and promotion by George Neville-Neil and others. This increased interest has been both gratifying and problematic. Our man pages are underappreciated gems, but we have sadly lacked any substantial documentation on how to write new ones. In September, I added a new chapter to the FreeBSD Documentation Project Primer describing the basics of creating a man page. It includes descriptions of the markup, section structure, recommended optional material such as examples, and sample templates for the most common types of man pages. The Resources section includes links to several external resources, including the excellent Practical UNIX Manuals: mdoc. While this chapter is not a full tutorial, it does begin to fill in a large gap in our documentation resources and provide a starting point from which to grow. Open tasks: 1. Add more explanation and examples of markup usage. 2. Expand the sample templates with additional desired standard features, like an EXAMPLES section. 3. Add more sample templates. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. The nosh Project Links Introduction URL: http://jdebp.eu./Softwares/nosh/ FreeBSD Binary Packages URL: http://jdebp.eu./Softwares/nosh/freebsd-binary-packages.html Installation How-To URL: http://jdebp.eu./Softwares/nosh/timorous-admin-installation-how-to= =2Ehtml Roadmap URL: http://jdebp.eu./Softwares/nosh/roadmap.html A Slightly Outdated User Guide URL: http://jdebp.eu./Softwares/nosh/guide/index.html Archnosh URL: http://framagit.org/taca/archnosh Contact: Jonathan de Boyne Pollard The nosh project is a suite of system-level utilities for initializing, running, and shutting down BSD systems; and for managing daemons, terminals, and logging. It attempts to supersede BSD init, the Mewburn rc.d system, and OpenRC as used on FreeBSD and TrueOS, drawing inspiration from Solaris SMF for named milestones, daemontools-encore for service control/status mechanisms, UCSPI, and IBM AIX for separated service and system management. It includes a range of compatibility mechanisms, including shims for familiar commands from other systems, and an automatic import mechanism that takes existing configuration data from /etc/fstab, /etc/rc.conf{,.local}, /etc/ttys, and elsewhere, applying them to its native service definitions and creating additional native services. It is portable (including to Linux) and composable, it provides a migration path from the world of systemd Linux, and it does not require new kernel APIs. It provides clean service environments, orderings and dependencies between services, parallelized startup and shutdown (including fsck), strictly size-capped and autorotated logging, the service manager as a "subreaper", and uses kevent(2) for event-driven parallelism. Since the last status report, in December 2015, the project has seen: restructured and finer-grained packaging that has fewer conflicts with other toolsets; the addition of zsh completion files; improvements to the virtual terminal subsystem, keyboard map, mouse support, and ugen and DECSCUSR support; RFC 5424/5426 remote logging support; replacement of libkqueue and the C library's environment handling functions; several new helper commands; support for Java VM autolocation; improved socket-passing code; an extended status API and "one-shot" service support; additional pre-supplied service bundles; support for service aliases; improved handling of per-user D-Bus services; improved importing of MySQL, MariaDB, Percona, and OpenVPN services; improved configuration import support; and extensive additions to the nosh Guide. On the recently updated roadmap you can see plans for even more documentation, continuing the work to extend the capabilities of the networking subsystem, and the scant handful of rc.d-related items remaining. There are also some ideas still in the speculative or planning phases, including work that may depend on incorporating nosh support into other software. Open tasks: 1. Improve Ansible and SaltStack integration (the maintainer of the Arch Linux nosh integration has some ideas). 2. Command-line completions are still needed for bash, csh, and fish. 3. Document convert-systemd-units for use by port maintainers in making packaged service bundles from systemd unit files. 4. nosh could take advantage of several proposed features for the base system: + the boot loader signaling "emergency" and "rescue" modes of operation + adding machine-readable status output to fsck + adding runtime support for more clang-compilable languages in the early bootstrap stage + adding hooks for invoking external configuration import mechanisms __________________________________________________________________ --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpBkBAACgkQKNmm82Tr dRJOgwwg5WCG7cNAQURqjmTzoc7Uc9JwYnksJ6dJzrod9rV0ToAqPJzMD+G2TEKX L7IX2yB2IMGFKb6pLRZ9UF6Z3EasSXDwq4H2G8qxe12mK9Oc/yV8rY1YZu6DYLoV czpgzhZbpvDOkjXl7/z4x7NI097Rrh9gj9SO8jZ5g/ufAzfo/qPtt9tNlcxarNI3 TGjN4jFadgbqohI12NO9AnsJO2sKfgDOO5UKbk8r2pcBoQBns2GkftjEiX0xKMc6 ZWxht72aVUtI6gaWLVq2yDSAg8hR86NB+0mib28QXBPL7jGg6cYYwXHRVKYTYMS7 BTqdQMQVva2xDg5KLZA20D+OWb+G4HEAjvMmB7TZeINbFJuLl6NWw/cDJAAR7gxF Z6pyAPSmadkXRlJ4TPzCm8LGJflEOozafv/4bsN6s3v+Fq1SpYVF/v9VwtqL/JxT NsfTzHnE3ZSujXmPM9bAD87VPO5vsrK2G4lYBx8MoVsLpD5asNvPbvJ/Z8nip+Ov dtbK8avd2FqQFQ== =5EQJ -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-current@freebsd.org Tue Dec 26 00:32: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 1CEF7E85D6E; Tue, 26 Dec 2017 00:32:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 85A6A7ACCE; Tue, 26 Dec 2017 00:32:32 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-2d1ff70000001b18-ed-5a4197681a50 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id BD.2C.06936.967914A5; Mon, 25 Dec 2017 19:27:21 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id vBQ0RJJs027833; Mon, 25 Dec 2017 19:27:20 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vBQ0RGMC023187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Dec 2017 19:27:18 -0500 Date: Mon, 25 Dec 2017 18:27:16 -0600 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Call for 2017Q4 quarterly status reports Message-ID: <20171226002716.GG59505@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Rgf3q3z9SdmXC6oT" Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IR4hTV1s2c7hhl8O2ztsWcNx+YLLZv/sfo wOQx49N8lgDGKC6blNSczLLUIn27BK6MW1MmMRa0CVdM/PONsYHxkEAXIyeHhICJxPW+O6wg tpDAYiaJ9cdFuxi5gOyNjBIz785jhHCuMkl8Of4ZrIpFQFXi5M+XLCA2m4CKREP3ZWYQW0RA XmJf03t2EJsZyP61tQnMFhYwlNizuh2snhdo299Dl1khbEGJkzOfsEDUl0lcm3mXrYuRA8iW llj+jwMkLCqgLLG37xD7BEa+WUg6ZiHpmIXQARHWkrjx7yUThrCtxLp171kWMLKtYpRNya3S zU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECApYdhflHYwv+7wPMQpwMCrx8B6IcIwSYk0s K67MPcQoycGkJMpbNs0hSogvKT+lMiOxOCO+qDQntfgQowrQrkcbVl9glGLJy89LVRLhdQap 401JrKxKLcqHKZPmYFES5/Uw0Y4SEkhPLEnNTk0tSC2CycpwcChJ8J6aBrRTsCg1PbUiLTOn BCHNxMF5iFGCgwdo+GuQGt7igsTc4sx0iPwpRl2OZzNfNzALgV0gJc57ZCpQkQBIUUZpHtwc UAKSyN5f84pRHOhFYd5gkFE8wOQFN+kV0BImoCXpnvYgS0oSEVJSDYwe2i+z+wSXPLW8xq19 56LJxiM1fOrtUkk7guRnZu5Km12+adr8p680f5QHOk4w5++wab+0PiMg6cLvhbscNyh33cmZ f0T0gAfvLi3PyFt/PfLXa2tvzxaymBn4ZAdPapH171P1B/nLPznJWAvzh8hbBAasqW+fVLxj ekPEjDXZeeqtLtNixZVYijMSDbWYi4oTAffbTSsbAwAA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 00:32:33 -0000 --Rgf3q3z9SdmXC6oT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is January 14, 2018, for work done in October through December. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q4 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-07-2017-09.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html --Rgf3q3z9SdmXC6oT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlpBl14ACgkQKNmm82Tr dRLa5Awfb5Vk9nkQodZiZS9vWE+/mkfOEoT70yAhxCPlds+gzuny94jgLk4N7teL bQgojMiLG8XWge4aIlFVQkjtnCKzmJUO9Y5bxekCvLoJWDKwmCEVzM62PnQFYCi0 HoF/DP/9+bt3Dn3MX+Vya02+Dm/3NFQIXZlfelH9LSbfTfa7XrLF1ve0tQSYLf9H HXLJbNkVI4nB/FoTRWAerQkG9OHvZuyHD7XJAGIcpf1HlJUj8k3SZIDxczuhs2bx PHCkZvZ3oJzAVnqh5TMY6KrQI2gsgvLGM/Qyd8ZMg8lpO7rJ13NXlFElwrZnfSoH Q6uhg9mVbRm2STZGUbJT+lo61X5l83NOMAOOKDMrhdSanqZKUqpwN+nWYplgJ/5U h8VA3jkFz3ksK4lTH9xZT46hl3ibLAHcWkcRKEpYqMOUnkW7CoY4OFk3dEW/hlWC 4vS6+sFIMokqOOXy4aNsjZzC/lZ2Ru4yqUJU+rZFdEOrKtTFJdtfuI9IqCCngEE3 8/po3rEWFiMejQ== =jdpn -----END PGP SIGNATURE----- --Rgf3q3z9SdmXC6oT-- From owner-freebsd-current@freebsd.org Tue Dec 26 10:37:09 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 A134DE83C88 for ; Tue, 26 Dec 2017 10:37:09 +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 07AEA6EC7E for ; Tue, 26 Dec 2017 10:37:08 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MTeVY-1eL1A42ulk-00QVrx for ; Tue, 26 Dec 2017 11:37:00 +0100 Date: Tue, 26 Dec 2017 11:36:27 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: LLD_IS_LD: error compiling world after switch: incompatible with /usr/lib/crt1.o ... Message-ID: <20171226113654.114f9031@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_/jQEJ9=icPFqjVtRiuE8_X/E"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:uPigE2l0u/jXAlFTlwLgFt4t/SWWKW/SpIzqi96qp01FBB2wJlk o8vpIXDxYrceyyhwEhijLu34pTrkTAYdQggkBLnh2WY2hIvGmEVZUNNUQZmRE0EG/9qprbl h87Fln2/T5ic6C2VJGdQgvCaLiAqwBJjCxze1qUYffv6i0JEc5NAl4lU+uEo9isajKLEWmz Vg9vGtwfQOxwx7/r2SFMA== X-UI-Out-Filterresults: notjunk:1;V01:K0:+0E9t8ODB2Y=:/1JdOmKpwEbflQGf4GZKHI EMnEcQTCIJnkHmqnc1cpGKUkDpMfQAxW84kZdgkmmQYd2RYa6BRQlAqotqSgDkRRn1qWW9NEh jBxUA6IqAgb7IpWsdqU1bGLgYsnc6vQUrLq4HxXlITb/WnvKBLdMItC3JlJ0cUuoKoHSW1l1/ hYTYyFsDxaDXWwi9E3DaH7F4B5yYCDfQj6QPFygcajB4PRPTAtTgpOU2i/Ys1jD4VEJC2Kv4+ WP0YQfkMjbCxakZ9yqfdINT18gEPRAyV93YGvJu7wgMPcqHgvrebLhF3j4KmJta4x0pC81nXe 48QtnbUafciikHoY5UONacFk0cz1HjVLTa20/lNzS+ZxkRVs37m1/QR08698LfDYitZoeVuSg Y6ajv1FcZ9vozXPKyAKajLAvlxp8Ecq8n95Fbv9j9DQFU54JJ3l7bEj/6a7zqiTb2a0LJFZ82 wmRjXcsWqXjM4dA1ZZapMoe1nYCDB81n9JnaVWbqIjOJlID3LUYnXn0lmyNFZXstafpKSuW0R ODcaCevFLHnDpv0KSu3rhUrSICHP1gdJpTMZY8qZBwQIh8L2i5PX+zd36vPo1069U7MYp1KVv 7yUqrMf7XuZr79GgG1+DKmjX4WVHGoQWXwYWnusUzXsoe39FTN9evITc/YHwk9VNeyMyNe7PG qbbQQT6X2P/UrzDD2DF1NZkfr/rl8yRLycXf8GNSwkPyYWnL02rs/LproiyvQz2HxL609sSU8 TItaMmn6on4xef9WkJU3+ThDGrU1o0Z8h/AEHKy/DnH5zTMBikI9gfcgOkUy/6nOHfklb/UTL RJZaSU9lkYI9NDZfXeRzuzMcqdsZQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 10:37:09 -0000 --Sig_/jQEJ9=icPFqjVtRiuE8_X/E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On to boxes running almost the same CURRENT (non-working is at FreeBSD 12.0= -CURRENT #241 r327182: Mon Dec 25 22:45:06 CET 2017 amd64; the working one is at r327183)= I dared, again, to flip the switch LLD_IS_LD=3DYES. On the box in question building world magically stops and dumping an error = sometimes, see below. The other one is performing well and build world without problems. I= build, due to resource limitations, on both systems kernel and world with META_MODE. When I switched over to LLD again, I didn't clear the whole obj tree - I do= not want this since my resources are, as said, limited and build times of 90 minutes is a= bit a burden at the moment. So, is there probably a workaround to this? Thanks in adavnce, Oliver [...] Building /usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libmagic/mkmagic --- mkmagic --- /usr/bin/ld: error: /usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libz/libz.so= is incompatible with /usr/lib/crt1.o cc: error: linker command failed with exi= t code 1 (use -v to see invocation) *** [mkmagic] Error code 1 make[2]: stopped in /usr/src/lib/libmagic .ERROR_TARGET=3D'mkmagic' .ERROR_META_FILE=3D'/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libmagic/mkm= agic.meta' --=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_/jQEJ9=icPFqjVtRiuE8_X/E Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkImRgAKCRDS528fyFhY lDVoAf9BacAI+CCaSi8L5QpH4yqxtlLP3LuF4kB6hIQ3e8iimJAjCUEkNVBjfW6n VySvUxyfJHv42d+Nx6SBDeGf+xzLAf93V4P73sZhh5tYuN5ktSczX5eeCg54DpMB YXTwzl1BAYnlpsSF/qhn2N6lb5fblNaeDBz0ts9td4QVpR8Jz8hf =9aqo -----END PGP SIGNATURE----- --Sig_/jQEJ9=icPFqjVtRiuE8_X/E-- From owner-freebsd-current@freebsd.org Tue Dec 26 16:25:36 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 9C339E9FDA2 for ; Tue, 26 Dec 2017 16:25:36 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 080CB7C591 for ; Tue, 26 Dec 2017 16:25:35 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MF5FT-1eiwr5084Z-00GJrL for ; Tue, 26 Dec 2017 17:25:28 +0100 Date: Tue, 26 Dec 2017 17:24:54 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: ZFS: alignment/boundary for partition type freebsd-zfs Message-ID: <20171226172521.611a89b0@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_/jKXLHRS+IdygrMXg69tM9FV"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:tNa7hKt7Sk5JVS8yBiI7kzf35OAtNh1QcaZt+z7UkqXrXPEwH5Z ah0H3WW7kCb6B8PmYaMPPStngmoQ0r7SsnecWcJ6mvgf+20dEdcQsht4kmKp/U7hZpxNE9B PU6/ZUzMto4cJw4asCioDiOB0jzz55ROpVHuRwjnsSnekNzc/UoZTfTxJ9BTjn4A0/hp11p i6d47MZg4RGTJPmdfAK+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:8gUKjXP0488=:ydhajyvvcjyHL6QiU0NUEv jYEvKQgWzdWzObIDgWueSt0UBrHXw46NcjtS/swj6xT0e7P7Iw3zS8XDXSdyH99Vgvo2Pi9BY jq9QFVDEk8Jydzou6j8dmuZc6QvLjg7KHAt5rVaT2V51kdhfY5rJRKEFi/eNxbwbR8aHtAyjQ FSTIGcIifGif5vA58h+YAqglDhm/qSZRAyWRP9LvzQRjlsY39teI+cGV/u9JKPro6nEWjjvax h0IRGB/+r9rl44jCR711qW5Dovi2e1A3RPoqWe+C0zXHNUSJ5lpy2vyZ8cvtQP1ntd4dwcgXU fMf2vmv6+KRfMMTCZtTn0zkxqUEvoUaWvhPFSHazt+fblaXuH/FsOqD1JtZg+tFPDBsjG7CPJ m05SK3U4m/SyVL7nZD6u34022ndpotKI+huPfEJfCl3RgMXcbNaG6ZkHoDMNtoyohj0y3+MA0 FaT17mGiw7y90HFdTjgsd/E2OvKdDn9kFJ4EeGO1nYikpyyy87C1hK9OvzBI21zfdvY2V1vwl bwGtZCDjJQ01aE8Usogg8IvgotMLDYWOdqU9u/JCQSLDGcBklljZvM+JSOZKocjtBHicKa9e8 tNdjD8fv5GgMbcZo19lbOMFIsnlDv/WUskMsb7GBJ4m+F5w27y2CweUkGLXAgDYlS/5bOKsMN OocnE3ibCZcL7U3t/1yVh6wTe3mRJSaI5XEW61uQz2zMWclgBHQztXaGTro+8nkEGiAo8WEBe lhTRT5s3euqauH3AJqjYpKZhfb2dLXGFYII5M2LMLSsvQNZCL1+8D9nWIoIe+OOd7yoXMUnqi xfbC/ADiP2vX6XCViRwWeyAQz2Lqg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 16:25:36 -0000 --Sig_/jKXLHRS+IdygrMXg69tM9FV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Running recent CURRENT on most of our lab's boxes, I was in need to replace= and restore a ZFS RAIDZ pool. Doing so, I was in need to partition the disks I was about = to replace. Well, the drives in question are 4k block size drives with 512b emulation -= as most of them today. I've created the only and sole partiton on each 4 TB drive via = the command sequence gpart create -s GPT adaX gpart add -t freebsd-zfs -a 4k -l nameXX adaX After doing this on all drives I was about to replace, something drove me t= o check on the net and I found a lot of websites giving "advices", how to prepare larg= e, modern drives for ZFS. I think the GNOP trick is not necessary any more, but many = blogs recommend to perform gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX to put the partition boundary at the 1 Megabytes boundary. I didn't do that= . My partitions all start now at block 40. My question is: will this have severe performance consequences or is that n= egligible? Since most of those websites I found via "zfs freebsd alignement" are from = years ago, I'm a bit confused now an consideration performing all this days-taking resilve= ring process let me loose some more hair as the usual "fallout" ... Thanks in advance, Oliver --=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_/jKXLHRS+IdygrMXg69tM9FV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkJ38QAKCRDS528fyFhY lHkfAf0XiTMZQorYLpmQLb9cJUfMk5BOD+KG88vGNH4Wl69LnC+IcivLe61Q/rNs CXu+AWozrcq0obUnwp9ryQ4mtl8vAgCepXbfFpMo6YLz18ilrCXLh6Uc+a4p3t5f CzuigwBNDLC75vtMob44wAzYtIJkkkkwgwE1lnRX2rgxO25p22lW =cusG -----END PGP SIGNATURE----- --Sig_/jKXLHRS+IdygrMXg69tM9FV-- From owner-freebsd-current@freebsd.org Tue Dec 26 16:50:59 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 8D78CEA19F1 for ; Tue, 26 Dec 2017 16:50:59 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 5A1377D8BB for ; Tue, 26 Dec 2017 16:50:59 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1383C13F84 for ; Tue, 26 Dec 2017 16:44:30 +0000 (UTC) Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs To: freebsd-current@freebsd.org References: <20171226172521.611a89b0@thor.intern.walstatt.dynvpn.de> From: Allan Jude Message-ID: Date: Tue, 26 Dec 2017 11:44:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171226172521.611a89b0@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 16:50:59 -0000 On 2017-12-26 11:24, O. Hartmann wrote: > Running recent CURRENT on most of our lab's boxes, I was in need to replace and restore a > ZFS RAIDZ pool. Doing so, I was in need to partition the disks I was about to replace. > Well, the drives in question are 4k block size drives with 512b emulation - as most of > them today. I've created the only and sole partiton on each 4 TB drive via the command > sequence > > gpart create -s GPT adaX > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > After doing this on all drives I was about to replace, something drove me to check on > the net and I found a lot of websites giving "advices", how to prepare large, modern > drives for ZFS. I think the GNOP trick is not necessary any more, but many blogs > recommend to perform > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > to put the partition boundary at the 1 Megabytes boundary. I didn't do that. My > partitions all start now at block 40. > > My question is: will this have severe performance consequences or is that negligible? > > Since most of those websites I found via "zfs freebsd alignement" are from years ago, I'm > a bit confused now an consideration performing all this days-taking resilvering process > let me loose some more hair as the usual "fallout" ... > > Thanks in advance, > > Oliver > The 1mb alignment is not required. It is just what I do to leave room for the other partition types before the ZFS partition. However, the replacement for the GNOP hack, is separate. In addition to aligning the partitions to 4k, you have to tell ZFS that the drive is 4k: sysctl vfs.zfs.min_auto_ashift=12 (2^12 = 4096) Before you create the pool, or add additional vdevs. -- Allan Jude From owner-freebsd-current@freebsd.org Tue Dec 26 16:53: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 DED53EA1DFB for ; Tue, 26 Dec 2017 16:53:04 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 5E56F7DD4F for ; Tue, 26 Dec 2017 16:53:04 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MZkic-1eEwcK11Hq-00LUnr for ; Tue, 26 Dec 2017 17:53:02 +0100 Date: Tue, 26 Dec 2017 17:52:26 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [SOLVED] Re: LLD_IS_LD: error compiling world after switch: incompatible with /usr/lib/crt1.o ... Message-ID: <20171226175253.23e98feb@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171226113654.114f9031@thor.intern.walstatt.dynvpn.de> References: <20171226113654.114f9031@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_/1ocePRefVZKYXgWAkE=bOqS"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:3Pt1zejEtsT+/92qD/lJHPr4AzWk5XLmSJo4T+V0cW1v9xQlO0G zpHXkbi1DEl5Sed0a1c8//B5yuf0NAJBCQ7oiTIz6wRiV+sFRIYUN/QLawmFnEnIn/KlpOr degA2SpIixi//49zSkt/ATdo8k+QM1BKoMabGPkAf6NJJygQ5PVk00BHIUQRLOG8zN/gngS erf3QqExzLXKQWafe+MEw== X-UI-Out-Filterresults: notjunk:1;V01:K0:YSnzCVQU8/4=:Xg11NIdHsyjueiF70KHetq R6QtK/pAEq6qnw7FZw6QZlQSbbwpV7w+ZUC58/tOsQdY23bC6a0NISLIsobnjry9wkjsLP8YY qUexvR2cVY8ppF3MZXibd1Jo9hQXb1amqacmAzjv7NVWmY6UXcqSh/tZiqXg+giaAel6lrTsf I7bDLwiEpu5BXYX0Y80RkMrBMSa/ViJCbiFlIaDv7ivcNYrTWFf6kNUotgn8QcxsXfCEkW+BR Z/H/IxNncLDp6RL2WfqxzdDEIl8SfOllwJDMnaDuQDFH7ysxRFYCEz5jW7ki/0kdtWVl3jCSa yC5WoYeCP8ShJXaq4S0YJhDQfkwkUE3C83m8OqAydKsimgqEQ2f79xYvXFVBkO3AZByK4TIDV in3sk1/vO8vI+nx1B0RAAw97PK9hYrOLzl1S8oB0ubcQnegJZBgSQWerVhBNynm7Ge+g9PJMx htFlbhDmXtOZ9qijRSQyEX8+c3QTphnVc1/qQIp/R6YHs0VOLpawax6ahxzXnpOKFZHcHGfcB MzTTv3NAdM7fOGxQEXsz3gNdEDEJPCtDJ8JR/2GB+QyheOBc/dm2tF1pIkO4kuQx78nMPmGoO 1PHiOpLOHpwSZNpmR/3QHnXftR8QP80aQq6+9lLebHFiq21DF+nKPgzigDJ26Iilles1aCE3m QgvmCtrCC/JYCAGIYsUNHjTscaO9iueR9jvty0HgeCl4LMLOlrhDKjjsFPdd9kJGo4rFdw0U5 wTldxe/XcCI14fyzXRAYZmWXbsqqkQDze6CLnv/QTvfhYx99zX0aZOUsFmVe97dRYR2XAyZLt JN20jhjOkAxXvWcUnKKjsvbedIVcg== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 16:53:05 -0000 --Sig_/1ocePRefVZKYXgWAkE=bOqS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 26 Dec 2017 11:36:27 +0100 "O. Hartmann" schrieb: > On to boxes running almost the same CURRENT (non-working is at FreeBSD 12= .0-CURRENT #241 > r327182: Mon Dec 25 22:45:06 CET 2017 amd64; the working one is at r32718= 3) I dared, > again, to flip the switch LLD_IS_LD=3DYES. >=20 > On the box in question building world magically stops and dumping an erro= r sometimes, > see below. The other one is performing well and build world without probl= ems. I build, > due to resource limitations, on both systems kernel and world with META_M= ODE. >=20 > When I switched over to LLD again, I didn't clear the whole obj tree - I = do not want > this since my resources are, as said, limited and build times of 90 minut= es is a bit a > burden at the moment. So, is there probably a workaround to this? >=20 > Thanks in adavnce, > Oliver >=20 >=20 > [...] > Building /usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libmagic/mkmagic > --- mkmagic --- > /usr/bin/ld: error: /usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libz/libz.= so is > incompatible with /usr/lib/crt1.o cc: error: linker command failed with e= xit code 1 (use > -v to see invocation) *** [mkmagic] Error code 1 >=20 > make[2]: stopped in /usr/src/lib/libmagic > .ERROR_TARGET=3D'mkmagic' > .ERROR_META_FILE=3D'/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libmagic/m= kmagic.meta' >=20 Deleting "/usr/obj/usr/src/amd64.amd64/obj-lib32/lib/libz/libz.so" solved t= he problem. --=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_/1ocePRefVZKYXgWAkE=bOqS Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkJ+ZQAKCRDS528fyFhY lKzwAf99PCMufjlPSFT8wpZb9W6h6Tu14csThWd/oRTi24hSpiZLIFZjwkbbTw6V UF0JxaxI+NXRNBajrv1lR2axE34KAgCpXpnEBub9jmIDJV4IPO9TZ5GTX2b9A1UA CNUVnkRaV1B2Pid55L3h/9MwsQs3WI4ccJTc9vrEIwyTTUNfDEn9 =E5e0 -----END PGP SIGNATURE----- --Sig_/1ocePRefVZKYXgWAkE=bOqS-- From owner-freebsd-current@freebsd.org Tue Dec 26 17:05: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 283A5EA2B06 for ; Tue, 26 Dec 2017 17:05:21 +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 96C947E81D; Tue, 26 Dec 2017 17:05:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MOBOi-1eZOyf34TM-005ZPQ; Tue, 26 Dec 2017 18:05:17 +0100 Date: Tue, 26 Dec 2017 18:04:44 +0100 From: "O. Hartmann" To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs Message-ID: <20171226180511.4d7d422e@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171226172521.611a89b0@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_/GflVNx9FQAYEcP..BDCX8zP"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:25AvfdidlJURc46YfdC4SDF14N5JcxjkYwl5hIzhViWTQ8Mq3sA 2I/bdfi8eNxuscupzjtlHkKBk1wqMc51cQ2SVzwrrKn3qOWBG5duaiVVUNKXliXrow0yoFt e2yyFSoqqJep/mAc/0AF25MlcWqqQ+Iq6ksX/liYz3DZW1XFyWfgCqU1MSjmTu2nDpcZ9Md 6jxz6LKEFr6kdMXs5JSeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:i/BaTaLp3v0=:aN71KENyeY6G+fTdt9NMFE Q45pqdXDN6iFb3m6KaRX2JeUdgrdIm29zXvWPOlzsNGnIOV7ILuYxNd0MqIOd7q+Klw4ann7g YWON+uMGyy8oSto6oTN/ASDr7RhL9XFPQCOQFkqDfIFPWQbMZ39nNKaDylzG+exiu1ZHoHxfQ r4JyVbh7GA+86rhzdckno24sKbKkpf/sRoaJ0sZABoCT9SkvcolGtw38YhJ7W/CU8zReHKAMC HDnvcEebj817OZHvjR7hcIiZmFsX+5yMvjJI9/EKR5pGhKBIfGjTTj4ljI8Rw5IUVx0InbUiH Jzki70IDyzEhHfgN5FIhoanfhpewtZ4+fV3wbnX0ftyceDbbVmtorkEULDWaQuRn5SbczuunC 4RpcYdE/Cp6qD8zntYjIO3mmWDgUCMQig+J9TYBuFWyzAvSwRTotL+qdSeBS8BYlraeAIgztg O761Bk2mezyaWs/TQUBUhlZvEJ1MMYjoTqIx6vNa086RftTLhH5NDWO6MGn1KJsksvz5XM6yD NBaAy6ApVWhIKSc1LQPjPCMrBIKbWb/BYL6CtbM58X9bswDx6ziclEME2LGLDh7webAFKktzq bnRFgAUcyLA78JhX3Emw044l3b0AaPRJFd/cObv7qmAMLwaEGDwdApqpoc9N2mQ/c0FfMJ19a AvxlqI+v3zkSJZdLLctCDtEBP224UAtORNI9tUxzIW2/PSuXYljj1on5YACuSk22+kCiY/1Xn FP9NjsaGmRm6h42h4c1RBpDSXe/uNTDFHEH4nmgoDcUowffVJvlkw8MMYIz3fQ0nqxQJtuANz JoLi6XhqRZRHX5rh3O91pLiF44AVQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 17:05:21 -0000 --Sig_/GflVNx9FQAYEcP..BDCX8zP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 26 Dec 2017 11:44:29 -0500 Allan Jude schrieb: > On 2017-12-26 11:24, O. Hartmann wrote: > > Running recent CURRENT on most of our lab's boxes, I was in need to rep= lace and > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition the disk= s I was about > > to replace. Well, the drives in question are 4k block size drives with = 512b emulation > > - as most of them today. I've created the only and sole partiton on eac= h 4 TB drive > > via the command sequence > >=20 > > gpart create -s GPT adaX > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > >=20 > > After doing this on all drives I was about to replace, something drove = me to check on > > the net and I found a lot of websites giving "advices", how to prepare = large, modern > > drives for ZFS. I think the GNOP trick is not necessary any more, but m= any blogs > > recommend to perform > >=20 > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > >=20 > > to put the partition boundary at the 1 Megabytes boundary. I didn't do = that. My > > partitions all start now at block 40. > >=20 > > My question is: will this have severe performance consequences or is th= at negligible? > >=20 > > Since most of those websites I found via "zfs freebsd alignement" are f= rom years ago, > > I'm a bit confused now an consideration performing all this days-taking= resilvering > > process let me loose some more hair as the usual "fallout" ... > >=20 > > Thanks in advance, > >=20 > > Oliver > > =20 >=20 > The 1mb alignment is not required. It is just what I do to leave room > for the other partition types before the ZFS partition. >=20 > However, the replacement for the GNOP hack, is separate. In addition to > aligning the partitions to 4k, you have to tell ZFS that the drive is 4k: >=20 > sysctl vfs.zfs.min_auto_ashift=3D12 >=20 > (2^12 =3D 4096) >=20 > Before you create the pool, or add additional vdevs. >=20 I didn't do the sysctl vfs.zfs.min_auto_ashift=3D12 :-(( when I created the= vdev. What is the consequence for that for the pool? I lived under the impression that th= is is necessary for "native 4k" drives. How can I check what ashift is in effect for a specific vdev? --=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_/GflVNx9FQAYEcP..BDCX8zP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkKBRwAKCRDS528fyFhY lNE/AgCP/mI7TEfhdTPDYjVAny5DGWXylgPb4BpzzPcYSWBOAg+2nIdT9ySrwIq2 pLtsY9iAUqb9mmNDEVnn7LAkSQ0DAf9OdpNlKh+bcU8SAsmxNflih9NScl8djrdb 7Hsc1MFS1crG8Wwvwv8KFpZnfcPAyB6AjV3M4hKYNb+DwduO61Fu =gHOZ -----END PGP SIGNATURE----- --Sig_/GflVNx9FQAYEcP..BDCX8zP-- From owner-freebsd-current@freebsd.org Tue Dec 26 17:13: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 88E69EA33CE for ; Tue, 26 Dec 2017 17:13:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1F017EEAB; Tue, 26 Dec 2017 17:13:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id m20so26996279lfi.6; Tue, 26 Dec 2017 09:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=U9onzC+Cvc9K8TuspE1RPf8Ud+mdzimjNoVq0gr+Fwo=; b=bk+ebrdIPC1lsgbEUOwJUreu6tIUz75BvPMqJ2u/a/UjsZXeGaXOTut9jjJMORNG4Q wnPDZbJaOR1JBKHArKiIu85wJDHarKjLiNyUf5KJYTWqEz07+lzLERUpcsyoUYv9TxE7 QnDDAgNaDMJ5pQs8zBoOpK6WlCnYlaN4K5otsxJ8OT4SSre06Wig3CP1cHkG1fIOS7ee CNcdJM3fynnVMnsfZyzLPGjFolzLDo8P8pzHoZ1iMiIBnPkB7w4FZiwDJpyUzhuE5zxZ Qdqgnqn+MWqLIhEh/YffWDGA4B39xiS9jJXDPz9+lkuLNP29MZT4P0utRvYszWgfwric +7aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=U9onzC+Cvc9K8TuspE1RPf8Ud+mdzimjNoVq0gr+Fwo=; b=rplFQV+T9nfwciEJpJLwTazNA9/hmXmcSQVl4h5djejyk7WZ6p9/I026fCSzCAcZTi 8hpXm8KvHufNKGl2dVJ5fUHynEnJ4KPTyT25HhGb1HpKsLIlwc8+GkdKL5MAtiZUqPQ0 qt5oKXc5SzdnzUPQh/S79QX0FRAY0rJ7TqqtGXW0C0WZgBxrkEQWicPo+8FCNgx/y6Gs 1vddFce7oZgPFX440/qd26hA9cb1LvKk8K9zoazuFt9vpY78Wmjd0AwPLpleZFgfOVIr 5Ov0anv2GzN8KT31JxmGyvotW5K67dYYrpbpRnKkm8s+EPCaRT1kfH+a3bMmWLNkNpUr Efqw== X-Gm-Message-State: AKGB3mLt43mE1r6QpDHC8MmOMwnsgGfbi4GRfsdu+N0FW6PZQQZsoMIY wQ22c7JO40IBd1LXMs76v92fLdEhSnMAvn/zXX8= X-Google-Smtp-Source: ACJfBotGDRU4wmnW+nl+JbF5uE/aZs5HxXjjjlMPEKBu+rF+aISN3zm15Omrv2zCXjITpmoT54Q/tvm0mJuEoyAIFT8= X-Received: by 10.25.225.153 with SMTP id l25mr8935568lfk.110.1514308390458; Tue, 26 Dec 2017 09:13:10 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 26 Dec 2017 09:13:09 -0800 (PST) In-Reply-To: <20171226180511.4d7d422e@thor.intern.walstatt.dynvpn.de> References: <20171226172521.611a89b0@thor.intern.walstatt.dynvpn.de> <20171226180511.4d7d422e@thor.intern.walstatt.dynvpn.de> From: Alan Somers Date: Tue, 26 Dec 2017 10:13:09 -0700 X-Google-Sender-Auth: 6TsfdigCNAZ0fpkbc_l00i8MF4o Message-ID: Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs To: "O. Hartmann" Cc: Allan Jude , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 17:13:13 -0000 On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann wrote: > Am Tue, 26 Dec 2017 11:44:29 -0500 > Allan Jude schrieb: > > > On 2017-12-26 11:24, O. Hartmann wrote: > > > Running recent CURRENT on most of our lab's boxes, I was in need to > replace and > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition the > disks I was about > > > to replace. Well, the drives in question are 4k block size drives with > 512b emulation > > > - as most of them today. I've created the only and sole partiton on > each 4 TB drive > > > via the command sequence > > > > > > gpart create -s GPT adaX > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > After doing this on all drives I was about to replace, something drove > me to check on > > > the net and I found a lot of websites giving "advices", how to prepare > large, modern > > > drives for ZFS. I think the GNOP trick is not necessary any more, but > many blogs > > > recommend to perform > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > to put the partition boundary at the 1 Megabytes boundary. I didn't do > that. My > > > partitions all start now at block 40. > > > > > > My question is: will this have severe performance consequences or is > that negligible? > > > > > > Since most of those websites I found via "zfs freebsd alignement" are > from years ago, > > > I'm a bit confused now an consideration performing all this > days-taking resilvering > > > process let me loose some more hair as the usual "fallout" ... > > > > > > Thanks in advance, > > > > > > Oliver > > > > > > > The 1mb alignment is not required. It is just what I do to leave room > > for the other partition types before the ZFS partition. > > > > However, the replacement for the GNOP hack, is separate. In addition to > > aligning the partitions to 4k, you have to tell ZFS that the drive is 4k: > > > > sysctl vfs.zfs.min_auto_ashift=12 > > > > (2^12 = 4096) > > > > Before you create the pool, or add additional vdevs. > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=12 :-(( when I created the > vdev. What is > the consequence for that for the pool? I lived under the impression that > this is necessary > for "native 4k" drives. > > How can I check what ashift is in effect for a specific vdev? > It's only necessary if your drive stupidly fails to report its physical sector size correctly, and no other FreeBSD developer has already written a quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the partitions in the ZFS raid group in question. It should print either "ashift: 12" or "ashift: 9". -Alan From owner-freebsd-current@freebsd.org Tue Dec 26 17:22:18 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 D3E72EA3C75 for ; Tue, 26 Dec 2017 17:22:18 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 4D5D57F4F1; Tue, 26 Dec 2017 17:22:18 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MRXzM-1eNOTJ2p2m-00Sbhw; Tue, 26 Dec 2017 18:09:29 +0100 Date: Tue, 26 Dec 2017 18:09:01 +0100 From: "O. Hartmann" To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs Message-ID: <20171226180928.21654d9d@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171226172521.611a89b0@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_/Cvz1M0mb_N7h_yf_B8_YDGc"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:2p0KzLIxfYyOsXdPIuCc/iSdmjKQVPz9ZpuqSijda5NA33KZK6P tW8RmEf2TWtuVbdDd/Z2qYJ2Tql6/TUFmIFtyH/CSx9hdq3Lk9p10fSLuO0bUt22n7tE42C lOzdPQO4bMXT7MK9hFe0CAwkTtXkTicQb/vyP9opsd4XAEKHEdBad+NwrXiaL8f8OMYBJd1 fCG7z9sJvHK2tFUhKZj+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:YhaFB/9UOYM=:zIQzOGpxzoTqNNsksYPCAV 037L9+6ZwQkOffCuWb92mFRxQp+jN/c1JnxL2L/PsXbFt4p0Q6XGcPv6M0lCONC9fK2HixQt1 e8D66T/68AVTAd5uMqvDEA52aDz441cJX4Y5rx+oAy0btV8rjB/EcFgJIBGzukLpBeQ7kocgn ZejnbvizLMvVNX+Mzan8/DIxfnRTGW4TIg2w6m3YRvLhvuXKolYZ2LH9rfP5N699eG+HRaIAQ MnOcEALgWoASPbBmfgn4Mk+lU7PqRuUGoTKpo+TQbIOpl1U9TqDP/CN77Fs9aIK4PjT16LfFo rKj7qThLLRXB8jjRi+QftSSnCkvGNaHcvD+ROyq6iPnyV3K+MW4iRz2+CxAPo3k4uxxpfL4Ea in2YrsEoQ7P6jlCbFjHNnNxGcTS+Ihafgm886K2S1LMN0UyTOm7YpmpuNX+uhZfa+UhdU7zT4 cOdQ5tf1He3CqUkoDiKECu/O3AMN0FGRBIjTVJHYUbVxraehXSwNCih9ugY7zWRdQvEJIn6vz M/tgnDxI7iljZt+o5X4TkRVNECVhrSzkyLmESEM/0MTeU/No4S3AvkyxWUakE6nG/NqOXUXP8 i6i3//a998s2OJeSHq+vi0JdOzBBQD5E5rjf6vfzlDFM17v0OqjiRA9lDNTZ5fN9xIDGmoIcF GCNwjBBBf6bYvw3Zf1njcUzOUN1sAiPdFW9H38zp8FMg87K/rJ7GubDPh0JojmA1+r9JGNkKk thDs8CtfK+oQGCJBs0/oxU6J6gZMa9HPVZkhMJJ4mCUwgJU1/e0b6iY5kDODXtJTMQiXSBOh5 Gnssn9m5BWaLoiE7iwUpn15qHPljw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 17:22:18 -0000 --Sig_/Cvz1M0mb_N7h_yf_B8_YDGc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 26 Dec 2017 11:44:29 -0500 Allan Jude schrieb: > On 2017-12-26 11:24, O. Hartmann wrote: > > Running recent CURRENT on most of our lab's boxes, I was in need to rep= lace and > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition the disk= s I was about > > to replace. Well, the drives in question are 4k block size drives with = 512b emulation > > - as most of them today. I've created the only and sole partiton on eac= h 4 TB drive > > via the command sequence > >=20 > > gpart create -s GPT adaX > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > >=20 > > After doing this on all drives I was about to replace, something drove = me to check on > > the net and I found a lot of websites giving "advices", how to prepare = large, modern > > drives for ZFS. I think the GNOP trick is not necessary any more, but m= any blogs > > recommend to perform > >=20 > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > >=20 > > to put the partition boundary at the 1 Megabytes boundary. I didn't do = that. My > > partitions all start now at block 40. > >=20 > > My question is: will this have severe performance consequences or is th= at negligible? > >=20 > > Since most of those websites I found via "zfs freebsd alignement" are f= rom years ago, > > I'm a bit confused now an consideration performing all this days-taking= resilvering > > process let me loose some more hair as the usual "fallout" ... > >=20 > > Thanks in advance, > >=20 > > Oliver > > =20 >=20 > The 1mb alignment is not required. It is just what I do to leave room > for the other partition types before the ZFS partition. >=20 > However, the replacement for the GNOP hack, is separate. In addition to > aligning the partitions to 4k, you have to tell ZFS that the drive is 4k: >=20 > sysctl vfs.zfs.min_auto_ashift=3D12 >=20 > (2^12 =3D 4096) >=20 > Before you create the pool, or add additional vdevs. >=20 I just checked with "zdb" what ashift is reported to my pool(s) and the res= ult claims to be "ashift: 12". --=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_/Cvz1M0mb_N7h_yf_B8_YDGc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkKCSAAKCRDS528fyFhY lF/0Af97Krwtkr9sM6lX8PzFBTBHQI+guJHkdZcViQDHRRH8nKJXf6F9MZj0lpKA FCVn1DkzpzRoIirwi/Dkwhl46Pr8AgCI7huGnhXuXOK6d8lurtr25A5nRAC6/LQJ Q/fzs/y6FGlr+2Q9gsNgMKu9C3qyxA4i+jOvbxlO3EZoBDw54CkS =5gGp -----END PGP SIGNATURE----- --Sig_/Cvz1M0mb_N7h_yf_B8_YDGc-- From owner-freebsd-current@freebsd.org Tue Dec 26 17:31: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 DBB51EA4377 for ; Tue, 26 Dec 2017 17:31:47 +0000 (UTC) (envelope-from o.hartmann@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 573F37F89B; Tue, 26 Dec 2017 17:31:46 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.225.232]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lb90f-1fEGR93i0H-00kdvT; Tue, 26 Dec 2017 18:31:39 +0100 Date: Tue, 26 Dec 2017 18:31:05 +0100 From: "O. Hartmann" To: Alan Somers Cc: Allan Jude , FreeBSD CURRENT Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs Message-ID: <20171226183132.2a6c6c2f@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171226172521.611a89b0@thor.intern.walstatt.dynvpn.de> <20171226180511.4d7d422e@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_/rsOg3mkGZcS/8+G946gbr2v"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:00++uoAB90BBKi98wFd9tc0VCOBVKdWFV2zlZ5Im5OB1MNj4PK2 KyUv9H9uN50Q7uCG7dz75oBLWKslU6vonEy3ZO6kE1TppndXXNtN7y04AWP29PfRSwpR3ur 7UERNAK3UgjSxjRWwQYqhMY2M78nzn4hfr3shyk64lUpdJW/eIpYz6qdKNJKxEM9eFRZgK+ oFvR0GRWhQai1CPSfUaFw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ViJ1WjoWJL0=:4iuAgJigD4/RBFJZwEieSJ LwhKpJtfMczVEIk00xe+BukFFYjs4EWj0+DCN5+dLGw4Wl78R69IuLp5bKcUzNKD/otEdSg1q 59aVSRpVht0LF/W+gC5Gqlt7O3NGLIustyQ6nwFUYyMQtRu2te3bCrCoaE3iWV9yU0qNxwybF CchRXvi7YboB6yS/51thzDHEqFSRVdQwa70qFkOf94iboZ/sVk6P3z1EgwxaMgizJa/NmRFWz zIFJp5orSPDKFn+Bfb2DT6AZwQFdl6VposKFMMY9hn6yR9RDhg0cAaYHnzHQDnbSoou05G0sc bNGiNJFVltmxTKYVq/749T94yH7dIPZSgWPx6nXDxCNuFSs7/+995ZQs8Vj3mAia5mIs00L5t Q5oyeJf9LlOqj70WtubnSP1zz93hMF/TXv4aWZtgVFe1VdSlcQsNYMP5IK9kxQb3GKkICfDN0 L1hV2VTPUiXLfzw5tk4MvPdG48YtcNE3invvG+O/FxnbqzaoW6mGK0+R0dTyZIzxYELY3ntV6 AI26VpJFLiJ87SNXZ4tvQEeG4SA9J+3afSzF8Si1U8kibpU42onTaFbVDkWyrgdZzNNvAN8JS 3jBOnKYbI5K8ggP+5ODc+FU/NJSdb929Xywvi5i5Fxi5WhUmtpquu3eC7WtL2TulmS6qPGkUy MgYRNYhFgDeHon3gy7R3FoIb/8xHHUUQz7iVREOzxfFJHYVYLfWVIK9DGe/6ftIe5q4CrIRjc WSZyqwMGdDwKPLoO2MAiozIoVGP1+2ZtcGSYBSAs5XVlwZRYdzFIWpG3CaItkuCi3Il8UPWI+ ETSlq/N5BTIS2KIL1L5mVG+yMSG4g== X-Mailman-Approved-At: Tue, 26 Dec 2017 19:32:29 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 17:31:48 -0000 --Sig_/rsOg3mkGZcS/8+G946gbr2v Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 26 Dec 2017 10:13:09 -0700 Alan Somers schrieb: > On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann > wrote: >=20 > > Am Tue, 26 Dec 2017 11:44:29 -0500 > > Allan Jude schrieb: > > =20 > > > On 2017-12-26 11:24, O. Hartmann wrote: =20 > > > > Running recent CURRENT on most of our lab's boxes, I was in need to= =20 > > replace and =20 > > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition the = =20 > > disks I was about =20 > > > > to replace. Well, the drives in question are 4k block size drives w= ith =20 > > 512b emulation =20 > > > > - as most of them today. I've created the only and sole partiton on= =20 > > each 4 TB drive =20 > > > > via the command sequence > > > > > > > > gpart create -s GPT adaX > > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > > > After doing this on all drives I was about to replace, something dr= ove =20 > > me to check on =20 > > > > the net and I found a lot of websites giving "advices", how to prep= are =20 > > large, modern =20 > > > > drives for ZFS. I think the GNOP trick is not necessary any more, b= ut =20 > > many blogs =20 > > > > recommend to perform > > > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > > > to put the partition boundary at the 1 Megabytes boundary. I didn't= do =20 > > that. My =20 > > > > partitions all start now at block 40. > > > > > > > > My question is: will this have severe performance consequences or i= s =20 > > that negligible? =20 > > > > > > > > Since most of those websites I found via "zfs freebsd alignement" a= re =20 > > from years ago, =20 > > > > I'm a bit confused now an consideration performing all this =20 > > days-taking resilvering =20 > > > > process let me loose some more hair as the usual "fallout" ... > > > > > > > > Thanks in advance, > > > > > > > > Oliver > > > > =20 > > > > > > The 1mb alignment is not required. It is just what I do to leave room > > > for the other partition types before the ZFS partition. > > > > > > However, the replacement for the GNOP hack, is separate. In addition = to > > > aligning the partitions to 4k, you have to tell ZFS that the drive is= 4k: > > > > > > sysctl vfs.zfs.min_auto_ashift=3D12 > > > > > > (2^12 =3D 4096) > > > > > > Before you create the pool, or add additional vdevs. > > > =20 > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=3D12 :-(( when I created= the > > vdev. What is > > the consequence for that for the pool? I lived under the impression that > > this is necessary > > for "native 4k" drives. > > > > How can I check what ashift is in effect for a specific vdev? > > =20 >=20 > It's only necessary if your drive stupidly fails to report its physical > sector size correctly, and no other FreeBSD developer has already written= a > quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the > partitions in the ZFS raid group in question. It should print either > "ashift: 12" or "ashift: 9". >=20 > -Alan > _______________________________________________ > 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" I checked as suggested and all partitions report ashift: 12. So I guess I'm save and sound and do not need to rebuild the pools ...?=20 --=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_/rsOg3mkGZcS/8+G946gbr2v Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkKHdAAKCRDS528fyFhY lPCeAgCM+lZW4RBGwzSNFTLLBWTATh/jI9zeMG49nlelrQjPZDaq0GUmZcUjufVN 2bmyLvYHxjk+MXfHtDi1l2s2lO2SAf9j/8T2zk0KR6iqWOLS7vOLux3JP5z0qrCU wMA0sZ4/JeHw1QU6XLHQOWbROHgF0jBUm/ktCzT/jsMcvL1p5icz =0rVe -----END PGP SIGNATURE----- --Sig_/rsOg3mkGZcS/8+G946gbr2v-- From owner-freebsd-current@freebsd.org Tue Dec 26 17:31: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 6BBA5EA43B3 for ; Tue, 26 Dec 2017 17:31:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E6FA7F9C6; Tue, 26 Dec 2017 17:31:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBQHVs2v057228; Tue, 26 Dec 2017 09:31:54 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBQHVr7d057227; Tue, 26 Dec 2017 09:31:53 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs In-Reply-To: To: Alan Somers Date: Tue, 26 Dec 2017 09:31:53 -0800 (PST) CC: "O. Hartmann" , Allan Jude , FreeBSD CURRENT X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 26 Dec 2017 20:14:59 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 17:31:57 -0000 > On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann > wrote: > > > Am Tue, 26 Dec 2017 11:44:29 -0500 > > Allan Jude schrieb: > > > > > On 2017-12-26 11:24, O. Hartmann wrote: > > > > Running recent CURRENT on most of our lab's boxes, I was in need to > > replace and > > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition the > > disks I was about > > > > to replace. Well, the drives in question are 4k block size drives with > > 512b emulation > > > > - as most of them today. I've created the only and sole partiton on > > each 4 TB drive > > > > via the command sequence > > > > > > > > gpart create -s GPT adaX > > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > > > After doing this on all drives I was about to replace, something drove > > me to check on > > > > the net and I found a lot of websites giving "advices", how to prepare > > large, modern > > > > drives for ZFS. I think the GNOP trick is not necessary any more, but > > many blogs > > > > recommend to perform > > > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > > > to put the partition boundary at the 1 Megabytes boundary. I didn't do > > that. My > > > > partitions all start now at block 40. > > > > > > > > My question is: will this have severe performance consequences or is > > that negligible? > > > > > > > > Since most of those websites I found via "zfs freebsd alignement" are > > from years ago, > > > > I'm a bit confused now an consideration performing all this > > days-taking resilvering > > > > process let me loose some more hair as the usual "fallout" ... > > > > > > > > Thanks in advance, > > > > > > > > Oliver > > > > > > > > > > The 1mb alignment is not required. It is just what I do to leave room > > > for the other partition types before the ZFS partition. > > > > > > However, the replacement for the GNOP hack, is separate. In addition to > > > aligning the partitions to 4k, you have to tell ZFS that the drive is 4k: > > > > > > sysctl vfs.zfs.min_auto_ashift=12 > > > > > > (2^12 = 4096) > > > > > > Before you create the pool, or add additional vdevs. > > > > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=12 :-(( when I created the > > vdev. What is > > the consequence for that for the pool? I lived under the impression that > > this is necessary > > for "native 4k" drives. > > > > How can I check what ashift is in effect for a specific vdev? > > > > It's only necessary if your drive stupidly fails to report its physical > sector size correctly, and no other FreeBSD developer has already written a > quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the > partitions in the ZFS raid group in question. It should print either > "ashift: 12" or "ashift: 9". And more than likely if you used the bsdinstall from one of the distributions to setup the system you created the ZFS pool from it has the sysctl in /boot/loader.conf as the default for all? recent? bsdinstall's is that the 4k default is used and the sysctl gets written to /boot/loader.conf at install time so from then on all pools you create shall also be 4k. You have to change a default during the system install to change this to 512. > -aLAn > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Dec 26 20:20:14 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 1391FEACE6D for ; Tue, 26 Dec 2017 20:20:14 +0000 (UTC) (envelope-from steven@multiplay.co.uk) 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 863EF65918 for ; Tue, 26 Dec 2017 20:20:13 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22b.google.com with SMTP id f3so4337156lfe.4 for ; Tue, 26 Dec 2017 12:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QGm/ff1gGpeEnquOqLTeKU9ZJQykFSO9CRWbonxtvgI=; b=v7NF4VtK+L+sUzUGtN6SZpfB98oFhPbAhRLunePD9gPiJgVvfCoJTe8Vf7BJhLT9nJ DPakfHAoE0PJNWJz+WdkKbR8FWi8/sVq8JZ0V8IXWvEl5zdc1BGDaNGzdC/W+5ia/49Q cRKkafEKdjTa53dvAkk/sVcUwGwxVua+M2gqnkSHFnHTqSnJnH3DT0zt8NfHpfk9y7kQ VvgEyYkrDQaq474z3gMh+e+Lcv0nv4adI6KAr+nQHNxvnu5K5H7tQhoWlz+JgoSwF6GA LxLIN873dPFCo4k6AvH86yf3VnboaOBQp0pR34YT6XOndlMRbxFHHYDHTIwOkKAC4bw2 5V8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QGm/ff1gGpeEnquOqLTeKU9ZJQykFSO9CRWbonxtvgI=; b=eJrn1Q1gUgPYv78bVual3caMinD55uFajGjfqesYZssQLpCOCOeKk/kQk/XgsQWch/ DapriDxEIBUOM1cVashRLlAn/WYKCalKYc/N0ovyykxlG8OSKHEkMFyRW/ZTUPXMIuNH vx1/dttl4zdPOIlmqoCB7BPLNjtcU/1rNMf/tydNcwgqoyyuDzmznXPovypjlW/0dD7b XNJBbw97YyfyRigx5TFlDfWWJf6jdMjeVN74Tzm8c9EAqu0U0/ogArKYmt0DET2xlVUI RHzl8FgTdYiSDR9h4Nt3rrDqgAb3Dvt4RI8vAVUmUhc0wgMWCBX/5PBliPJiPd4/Sy1r TU3Q== X-Gm-Message-State: AKGB3mInFgFmTjRSOm8t8FachSgKNlbvSzXEI+jP1vyGPeZAvQJKa1hW 5LBetm8gK2n4kW5mFzVlyKI9d1Cxk/Gn1lR9/2BznQ== X-Google-Smtp-Source: ACJfBov0AlsnckCtbyqY5ueY0abQ5idP5HFf6chdHashO9DHi4lCXa6YQoDBS+aLuo2bC+OP3a4f/irs6EbRkX6cydU= X-Received: by 10.25.235.220 with SMTP id f89mr1347377lfk.14.1514319611246; Tue, 26 Dec 2017 12:20:11 -0800 (PST) MIME-Version: 1.0 References: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> From: Steven Hartland Date: Tue, 26 Dec 2017 20:20:00 +0000 Message-ID: Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs To: "Rodney W. Grimes" Cc: Alan Somers , Allan Jude , FreeBSD CURRENT , "O. Hartmann" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 20:20:14 -0000 You only need to set the min if the drives hide their true sector size, as Allan mentioned. camcontrol identify is one of the easiest ways to check this. If the pool reports ashift 12 then zfs correctly detected the drives as 4K so that part is good On Tue, 26 Dec 2017 at 20:15, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann > > wrote: > > > > > Am Tue, 26 Dec 2017 11:44:29 -0500 > > > Allan Jude schrieb: > > > > > > > On 2017-12-26 11:24, O. Hartmann wrote: > > > > > Running recent CURRENT on most of our lab's boxes, I was in need to > > > replace and > > > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition the > > > disks I was about > > > > > to replace. Well, the drives in question are 4k block size drives > with > > > 512b emulation > > > > > - as most of them today. I've created the only and sole partiton on > > > each 4 TB drive > > > > > via the command sequence > > > > > > > > > > gpart create -s GPT adaX > > > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > > > > > After doing this on all drives I was about to replace, something > drove > > > me to check on > > > > > the net and I found a lot of websites giving "advices", how to > prepare > > > large, modern > > > > > drives for ZFS. I think the GNOP trick is not necessary any more, > but > > > many blogs > > > > > recommend to perform > > > > > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > > > > > to put the partition boundary at the 1 Megabytes boundary. I > didn't do > > > that. My > > > > > partitions all start now at block 40. > > > > > > > > > > My question is: will this have severe performance consequences or > is > > > that negligible? > > > > > > > > > > Since most of those websites I found via "zfs freebsd alignement" > are > > > from years ago, > > > > > I'm a bit confused now an consideration performing all this > > > days-taking resilvering > > > > > process let me loose some more hair as the usual "fallout" ... > > > > > > > > > > Thanks in advance, > > > > > > > > > > Oliver > > > > > > > > > > > > > The 1mb alignment is not required. It is just what I do to leave room > > > > for the other partition types before the ZFS partition. > > > > > > > > However, the replacement for the GNOP hack, is separate. In addition > to > > > > aligning the partitions to 4k, you have to tell ZFS that the drive > is 4k: > > > > > > > > sysctl vfs.zfs.min_auto_ashift=12 > > > > > > > > (2^12 = 4096) > > > > > > > > Before you create the pool, or add additional vdevs. > > > > > > > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=12 :-(( when I created > the > > > vdev. What is > > > the consequence for that for the pool? I lived under the impression > that > > > this is necessary > > > for "native 4k" drives. > > > > > > How can I check what ashift is in effect for a specific vdev? > > > > > > > It's only necessary if your drive stupidly fails to report its physical > > sector size correctly, and no other FreeBSD developer has already > written a > > quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the > > partitions in the ZFS raid group in question. It should print either > > "ashift: 12" or "ashift: 9". > > And more than likely if you used the bsdinstall from one of > the distributions to setup the system you created the ZFS > pool from it has the sysctl in /boot/loader.conf as the > default for all? recent? bsdinstall's is that the 4k default > is used and the sysctl gets written to /boot/loader.conf > at install time so from then on all pools you create shall > also be 4k. You have to change a default during the > system install to change this to 512. > > > -aLAn > > > _______________________________________________ > > 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" > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > 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 Dec 26 20:25: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 D120FE8048B for ; Tue, 26 Dec 2017 20:25:01 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 516DE65E73; Tue, 26 Dec 2017 20:25:00 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.120.247]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MZU7V-1eFzQr03Lh-00LJCq; Tue, 26 Dec 2017 21:24:48 +0100 Date: Tue, 26 Dec 2017 21:24:12 +0100 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: Alan Somers , "O. Hartmann" , Allan Jude , FreeBSD CURRENT Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs Message-ID: <20171226212355.76494782@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> References: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> 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_/ByRKJ_/QgjWtRXJGudvkA5U"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:pGn6GVhw/UnEl4E+yXIx1vjTHJKYWBRfNPfWqVt7FnAxGc/9UpZ k9TznibqFJuGUrX13c2bal/pscDYVm9sdElGqY4MovGw57iUnoVeqnxkdMeECR75clmpiwe 3ujuM+Xo1veoWYxcNI+mK6WQLWUIBzvWCaKBvBagJmKTCS5TehSx5SYcJ2ljhF5Nkm9gMoi ++IoinI+F1KAH7wR5B20Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:BS6Y4+FRS8Q=:ChofiQpZrPpIjwq8GAd36S I8tXN+u7pzuNABwdLX+xyWdvciim6mimB1HoLtNt99CrVPj5dw61zr+JYBAKHD0nmXzqobSpD hZIPEM2VKP5DcNvuNwPHx78ZzrkBZjqtDykd0Ie8xmrjczaFLe9UzYfXHjUKqsL/HcUIn1Ev2 0eZO/qDtf8jwCyOz7bPoEH8W9pKR5gZpUj9rxoeXj0nSnHXEAFd/0/jMOrbVqT7PvFOSSCGSn HYVf5aLdRi+Fi4T3oTz6hg6MKgdv22XAFcTNKaqbkIwRJ7n/SgmLGBpjZSopK54HYqJ3S0HZS My8qX11Z+nlbeMWgKM15DN+zIUw08XBOpyWAK1IEzv0PIVx8/glSePpKW1h7z9zgMYG7k2QIz klXyqLfYa2B0WsPtXmKF3pY3HI3CIbsmrOTCGngmnvOhOdE54y5aAa5/IPFsMnJIwC1xemy9N kkpHTqGubf3bvQD+NhVHfTxV2r64kqj8ep3bWb2Cvy0D6AZXR5yBuaL2kopuQYun2to2u67Fa uqwOpEiMC9IqzBC/eFEk2YuDjttQdwa49Bvg3W5lVkgZxtTMD15R1oPjLhryRvfy1cbwUcIU4 hZ+3hMs4EBiEUxIALvvqkTAUkpCzhpyrxhWMa2r2wGXrM+l60qssb5z548PcIvvLxLqI+UgNQ G9ZB1Gc/Z7+xdHmxD7RLr4hMcwzJWob1kgoJR6BWKw17VUmQ61Jjw81ZTKzQHwma8CWyxRaPc Ji/ygIY+LBTlG+tM3UqlcUgEBqOkqW0NKTCWpUW+2ZEmxMnFIdsJnvcE+zdoyFG2AMQETe0wp AqX12iVKRmBzcM8EM8cKlZh5A+wgTsqOb9L3DOrdH5U+7IhTCfzETEHwKavl2Owg7lsgvNJSo HVj+JZYkTgKyySF4Xd0MAwzDdxlWp/SElNrbT+SuHXtyLyYQPtv3YSZVDddqlroX8cb+oSILt KIp+pZThp3ckBJ5Z3y6OdFMZbLLMylcn3JYRsCvTFKrxNLtOy3S3h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 20:25:01 -0000 --Sig_/ByRKJ_/QgjWtRXJGudvkA5U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 26 Dec 2017 09:31:53 -0800 (PST) "Rodney W. Grimes" schrieb: > > On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann > > wrote: > > =20 > > > Am Tue, 26 Dec 2017 11:44:29 -0500 > > > Allan Jude schrieb: > > > =20 > > > > On 2017-12-26 11:24, O. Hartmann wrote: =20 > > > > > Running recent CURRENT on most of our lab's boxes, I was in need = to =20 > > > replace and =20 > > > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition th= e =20 > > > disks I was about =20 > > > > > to replace. Well, the drives in question are 4k block size drives= with =20 > > > 512b emulation =20 > > > > > - as most of them today. I've created the only and sole partiton = on =20 > > > each 4 TB drive =20 > > > > > via the command sequence > > > > > > > > > > gpart create -s GPT adaX > > > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > > > > > After doing this on all drives I was about to replace, something = drove =20 > > > me to check on =20 > > > > > the net and I found a lot of websites giving "advices", how to pr= epare =20 > > > large, modern =20 > > > > > drives for ZFS. I think the GNOP trick is not necessary any more,= but =20 > > > many blogs =20 > > > > > recommend to perform > > > > > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > > > > > to put the partition boundary at the 1 Megabytes boundary. I didn= 't do =20 > > > that. My =20 > > > > > partitions all start now at block 40. > > > > > > > > > > My question is: will this have severe performance consequences or= is =20 > > > that negligible? =20 > > > > > > > > > > Since most of those websites I found via "zfs freebsd alignement"= are =20 > > > from years ago, =20 > > > > > I'm a bit confused now an consideration performing all this =20 > > > days-taking resilvering =20 > > > > > process let me loose some more hair as the usual "fallout" ... > > > > > > > > > > Thanks in advance, > > > > > > > > > > Oliver > > > > > =20 > > > > > > > > The 1mb alignment is not required. It is just what I do to leave ro= om > > > > for the other partition types before the ZFS partition. > > > > > > > > However, the replacement for the GNOP hack, is separate. In additio= n to > > > > aligning the partitions to 4k, you have to tell ZFS that the drive = is 4k: > > > > > > > > sysctl vfs.zfs.min_auto_ashift=3D12 > > > > > > > > (2^12 =3D 4096) > > > > > > > > Before you create the pool, or add additional vdevs. > > > > =20 > > > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=3D12 :-(( when I creat= ed the > > > vdev. What is > > > the consequence for that for the pool? I lived under the impression t= hat > > > this is necessary > > > for "native 4k" drives. > > > > > > How can I check what ashift is in effect for a specific vdev? > > > =20 > >=20 > > It's only necessary if your drive stupidly fails to report its physical > > sector size correctly, and no other FreeBSD developer has already writt= en a > > quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the > > partitions in the ZFS raid group in question. It should print either > > "ashift: 12" or "ashift: 9". =20 >=20 > And more than likely if you used the bsdinstall from one of > the distributions to setup the system you created the ZFS > pool from it has the sysctl in /boot/loader.conf as the > default for all? recent? bsdinstall's is that the 4k default > is used and the sysctl gets written to /boot/loader.conf > at install time so from then on all pools you create shall > also be 4k. You have to change a default during the > system install to change this to 512. I never used any installation scripts so far. Before I replaced the pool's drives, I tried to search for informations on = how-to. This important tiny fact must have slipped through - or it is very bad documente= d. I didn't find a hint in tuning(7), which is the man page I consulted first. Luckily, as Allan Jude stated, the disk recognition was correct (I guess st= ripesize instead of blocksize is taken?).=20 > =20 > > -aLAn =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.o= rg" > > =20 >=20 --=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_/ByRKJ_/QgjWtRXJGudvkA5U Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkKwBwAKCRDS528fyFhY lI+tAf4u8+6gJtpqUEWxg8OjpvGQwqAsQpm9pVuCbMqKOxOsI8wc6HPktHoGhmBS eGjLioiS1p+l5z3pcoUEuWbvMrmjAf4rewz64tN4GvwE/6+P+D1F0TbRqIY9suNK Q201KNarBKuZ787hiZOcGADXyKrkVxY/hBXRlTrXzGyZHzL4uJdJ =/oUt -----END PGP SIGNATURE----- --Sig_/ByRKJ_/QgjWtRXJGudvkA5U-- From owner-freebsd-current@freebsd.org Tue Dec 26 22:44:22 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 38BDDE87E9F for ; Tue, 26 Dec 2017 22:44:22 +0000 (UTC) (envelope-from steven@multiplay.co.uk) 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 AAC896AB9C for ; Tue, 26 Dec 2017 22:44:21 +0000 (UTC) (envelope-from steven@multiplay.co.uk) Received: by mail-lf0-x22b.google.com with SMTP id f18so40699386lfg.8 for ; Tue, 26 Dec 2017 14:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nTLoASJvOeeknc/nOPNJ7K/xOyi0QdS+RIR5lVxOIW8=; b=Skpv5hlsaI/hwfSGN6DaYSRoAk45TUd6xfxh8zID2pgA9dn/dv+29oUhfhabSancHj 36ESvKXUYV/7j3tL5ER8eCyrnla21/7j4uB1rxp0tRfOdf713yu9mUhOx+lcXqMy95tT 4d44FSaqBeIc+9xf+oOxWYnawUZpxkImmX9leYFdZBYkmf5XwupswN1c6/T/BzgV8G/V ZDGk3FkccmLPrfJHIX/eaaViyiXkLecBRovKLMOIrgnfYyiTC8XK0aNQi1BZOHYyNxOI vJJO4VnzqM6KoaWvkSHrMJDmRBgiKhmFKKkrmfP4iohVE3qFkpkyu7/nZ9kg6Lb9Gg2c 3Nxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nTLoASJvOeeknc/nOPNJ7K/xOyi0QdS+RIR5lVxOIW8=; b=gOmg8eByz0g6p59CYDkM+WP24csZMwBOcVP3RW7VDGJooe9EKKub7nA4bD2w7eHou3 k3KBnExWLchadYTqMOw2bmz0+kktRcjB1MBlYVchrXjn14AlDdsX4zJA5Y+26UNOvbFt PxPPQqQahxdzVf608VrmiTQMf6oz0PDuvkAs+IwucPAdigXe3BgyrJqj9zJLq0FtsYZO JM7890NHx1qh5JXljw15QB2v+AL2k4lUXiJJaNTU9aefZi4UBkvRwp1ZaaHgO5D3Gx+k 1B9HrAUQt8O3KLOidsJNlN0bAQ7qd+hgx7cMwBh0TrRx4SSetFAHKY76tsynIziHlVYE fO9g== X-Gm-Message-State: AKGB3mLqDtL0aTeMB5O9L+WYgJlFJBD36LZTyEk3TEw2Qgew5ccUEEHr hTYxZCtMH8vXoL0wbMMDtFvndp07pX8dv7tegA85Ww== X-Google-Smtp-Source: ACJfBosPXwd8/HvjUSbQz0ipp2NRVSz/d6O0Ay1fRtswMkxGHllrCiCgY/nuHeCsR8HhGT5E5rigpepndEyUZ8RvIDw= X-Received: by 10.25.44.195 with SMTP id s186mr2764621lfs.19.1514328258935; Tue, 26 Dec 2017 14:44:18 -0800 (PST) MIME-Version: 1.0 References: <201712261731.vBQHVr7d057227@pdx.rh.CN85.dnsmgr.net> <20171226212355.76494782@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171226212355.76494782@thor.intern.walstatt.dynvpn.de> From: Steven Hartland Date: Tue, 26 Dec 2017 22:44:08 +0000 Message-ID: Subject: Re: ZFS: alignment/boundary for partition type freebsd-zfs To: "O. Hartmann" Cc: Alan Somers , Allan Jude , FreeBSD CURRENT , "Rodney W. Grimes" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 26 Dec 2017 22:44:22 -0000 Yes it does know how to figure out based on stripe size On Tue, 26 Dec 2017 at 20:25, O. Hartmann wrote: > Am Tue, 26 Dec 2017 09:31:53 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > > On Tue, Dec 26, 2017 at 10:04 AM, O. Hartmann > > > wrote: > > > > > > > Am Tue, 26 Dec 2017 11:44:29 -0500 > > > > Allan Jude schrieb: > > > > > > > > > On 2017-12-26 11:24, O. Hartmann wrote: > > > > > > Running recent CURRENT on most of our lab's boxes, I was in nee= d > to > > > > replace and > > > > > > restore a ZFS RAIDZ pool. Doing so, I was in need to partition > the > > > > disks I was about > > > > > > to replace. Well, the drives in question are 4k block size > drives with > > > > 512b emulation > > > > > > - as most of them today. I've created the only and sole partito= n > on > > > > each 4 TB drive > > > > > > via the command sequence > > > > > > > > > > > > gpart create -s GPT adaX > > > > > > gpart add -t freebsd-zfs -a 4k -l nameXX adaX > > > > > > > > > > > > After doing this on all drives I was about to replace, somethin= g > drove > > > > me to check on > > > > > > the net and I found a lot of websites giving "advices", how to > prepare > > > > large, modern > > > > > > drives for ZFS. I think the GNOP trick is not necessary any > more, but > > > > many blogs > > > > > > recommend to perform > > > > > > > > > > > > gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX > > > > > > > > > > > > to put the partition boundary at the 1 Megabytes boundary. I > didn't do > > > > that. My > > > > > > partitions all start now at block 40. > > > > > > > > > > > > My question is: will this have severe performance consequences > or is > > > > that negligible? > > > > > > > > > > > > Since most of those websites I found via "zfs freebsd > alignement" are > > > > from years ago, > > > > > > I'm a bit confused now an consideration performing all this > > > > days-taking resilvering > > > > > > process let me loose some more hair as the usual "fallout" ... > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > Oliver > > > > > > > > > > > > > > > > The 1mb alignment is not required. It is just what I do to leave > room > > > > > for the other partition types before the ZFS partition. > > > > > > > > > > However, the replacement for the GNOP hack, is separate. In > addition to > > > > > aligning the partitions to 4k, you have to tell ZFS that the driv= e > is 4k: > > > > > > > > > > sysctl vfs.zfs.min_auto_ashift=3D12 > > > > > > > > > > (2^12 =3D 4096) > > > > > > > > > > Before you create the pool, or add additional vdevs. > > > > > > > > > > > > > I didn't do the sysctl vfs.zfs.min_auto_ashift=3D12 :-(( when I > created the > > > > vdev. What is > > > > the consequence for that for the pool? I lived under the impression > that > > > > this is necessary > > > > for "native 4k" drives. > > > > > > > > How can I check what ashift is in effect for a specific vdev? > > > > > > > > > > It's only necessary if your drive stupidly fails to report its physic= al > > > sector size correctly, and no other FreeBSD developer has already > written a > > > quirk for that drive. Do "zdb -l /dev/adaXXXpY" for any one of the > > > partitions in the ZFS raid group in question. It should print either > > > "ashift: 12" or "ashift: 9". > > > > And more than likely if you used the bsdinstall from one of > > the distributions to setup the system you created the ZFS > > pool from it has the sysctl in /boot/loader.conf as the > > default for all? recent? bsdinstall's is that the 4k default > > is used and the sysctl gets written to /boot/loader.conf > > at install time so from then on all pools you create shall > > also be 4k. You have to change a default during the > > system install to change this to 512. > > > I never used any installation scripts so far. > > Before I replaced the pool's drives, I tried to search for informations o= n > how-to. This > important tiny fact must have slipped through - or it is very bad > documented. I didn't > find a hint in tuning(7), which is the man page I consulted first. > > Luckily, as Allan Jude stated, the disk recognition was correct (I guess > stripesize > instead of blocksize is taken?). > > > > > > -aLAn > > > > > _______________________________________________ > > > 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" > > > > > > > > > -- > 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 Ab= s. 4 BDSG). > From owner-freebsd-current@freebsd.org Wed Dec 27 03:10: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 1A4E6E9D3CF for ; Wed, 27 Dec 2017 03:10:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D912C73DA2; Wed, 27 Dec 2017 03:10:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id 68so24299972ite.4; Tue, 26 Dec 2017 19:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XVMGf3klY06gZSZ/5rYB/Le02/0IuXWf1Bz5n6+W/Nw=; b=ss9sQRJmtY5RJVNCKo5IVH1L3hWpDy4IrjZdNtUZ8BnBIKLTQvE5wF9Wb/oTsZZwcq pn0rChicIiYSHhitjoHqfjwCK7Hj7kz7bAi7jGXNayTQzPEVve0K7bDPmLjs9Swk4ZbL YDAI/pp1unKz4ulEOn/tG1eeCNPNgsYg8olA96rDidE7foptwN6TnrxgRoLPxenB1DNj 4l6iduI1oMZ+ih/FcFusdazKzTPi9kRFly96OcOeEIss6d+2GHMgfez/x+E8zERUubQv Fo0WSGzctVdMs1FrqVA5mlB86UYws1/jN+5b7CcMWCnm4xu1IDvqsagOeNUBPGisZJW3 R4Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XVMGf3klY06gZSZ/5rYB/Le02/0IuXWf1Bz5n6+W/Nw=; b=iUI7xAeFgB447dwMItJ4KWR8JBhpvoW9+kG2Y5O1caN7Ebh43Q+lL9ltJkynV9Pt4h GX9tTSojl5TIbAeB8QaMm/xrrTY/INnDIoOXk0HVFNjpIbqx0XURNpfPJ3j1kmMNzN3O pzBOyGhdYz+cXL8DSq+wdCtgYLKCc4yIGyQzmGiM2LiW2uHdmbgVeB6mRC3HHvlentdf K++a5QxoMgVHEJxVlfIabPWym0ugOF1A7rHbimnDBKU3FdXBSRKvmG+5czIHpTejx64s 9lY7uRdVl7kQ56zIJ8c6j4EVB+kJIgARA8OqXRu1hqzRBZFnXSmKMWTAw5s23yxFSJdi btiA== X-Gm-Message-State: AKGB3mJJYgywATffJ9WselKa6r1CMWZhRpKKxC368gxQyrZf3tkfBGwj Sh67m8LwuWpG4qHM5MO5cm+WMwEP1MU7Qcfdf85mog== X-Google-Smtp-Source: ACJfBotQs06WL+TTm9pUn6vpPSi8zKQKV568nsHD6T+HJCrIZyLIilF61kHv2JKSoURaBYGgNHreOUCd3XnKXdFMlzQ= X-Received: by 10.36.89.149 with SMTP id p143mr35019689itb.96.1514344249000; Tue, 26 Dec 2017 19:10:49 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.131.163 with HTTP; Tue, 26 Dec 2017 19:10:28 -0800 (PST) In-Reply-To: <803F0529-9A47-4627-B9B0-B75BC45556AD@FreeBSD.org> References: <20171225211651.7e865c84@thor.intern.walstatt.dynvpn.de> <803F0529-9A47-4627-B9B0-B75BC45556AD@FreeBSD.org> From: Ed Maste Date: Tue, 26 Dec 2017 22:10:28 -0500 X-Google-Sender-Auth: h8RDxRAfNsA97MRhmjURLs8MvFk Message-ID: Subject: Re: LLD: man pages missing? To: Dimitry Andric Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 27 Dec 2017 03:10:50 -0000 On 25 December 2017 at 15:25, Dimitry Andric wrote: > > Since lld is now approaching a quite usable state, maybe it is time for > a request to upstream to provide [a manpage]. ;) Yes, it would've been nice if an upstream man page was created early on and had been kept up to date as features were added. In any case, lld is otherwise close to being ready to be installed as /usr/bin/ld on FreeBSD/amd64, and I suspect we might have to just create the man page (and send it upstream). Other than the man page I'm aware of some issues with ifunc support discovered by kib@ while working on kernel ifunc. This doesn't affect FreeBSD-HEAD yet (as we don't use ifunc today) but will soon be important. There's also additional work needed for the ports tree, although right now ~99.5 of the ports collection builds when lld is /usr/bin/ld. Most ports that were failing with lld have either been fixed, or worked around via LLD_UNSAFE so that the port continues using ld.bfd. From owner-freebsd-current@freebsd.org Wed Dec 27 15:39:49 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 9FED2E96913 for ; Wed, 27 Dec 2017 15:39:49 +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 799A26A264; Wed, 27 Dec 2017 15:39:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBRFdZrX002258 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Dec 2017 07:39:39 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current To: Konstantin Belousov , Wolfram Schneider Cc: David Wolfskill , freebsd-current References: <20171215120243.GB1179@albert.catwhisker.org> <20171215183928.GO2272@kib.kiev.ua> From: Julian Elischer Message-ID: Date: Wed, 27 Dec 2017 23:39:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171215183928.GO2272@kib.kiev.ua> 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.25 Precedence: 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, 27 Dec 2017 15:39:49 -0000 On 16/12/17 2:39 am, Konstantin Belousov wrote: > Put the following into /etc/src.conf: This brings up two questions: when to use make.conf and when to use src.conf, and.. > WITHOUT_PROFILE=yes > WITHOUT_DEBUG_FILES=yes > WITHOUT_TESTS=yes which of the following is correct and why? WITH_DEBUG_FILES=no WITHOUT_DEBUG_FILES=yes > _______________________________________________ > 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 Wed Dec 27 15:48: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 C16B1E9D231 for ; Wed, 27 Dec 2017 15:48:47 +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 807F36A7D0; Wed, 27 Dec 2017 15:48:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (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 AD0A0C101; Wed, 27 Dec 2017 16:48:43 +0100 (CET) From: Dimitry Andric Message-Id: <364A159B-ACE7-4842-BAD9-E8D407F7429B@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F5C8CD1B-D1FE-48F0-A1B0-007C3176B7D0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current Date: Wed, 27 Dec 2017 16:48:43 +0100 In-Reply-To: Cc: Konstantin Belousov , Wolfram Schneider , David Wolfskill , freebsd-current To: Julian Elischer References: <20171215120243.GB1179@albert.catwhisker.org> <20171215183928.GO2272@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 27 Dec 2017 15:48:47 -0000 --Apple-Mail=_F5C8CD1B-D1FE-48F0-A1B0-007C3176B7D0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 27 Dec 2017, at 16:39, Julian Elischer wrote: > > On 16/12/17 2:39 am, Konstantin Belousov wrote: >> Put the following into /etc/src.conf: > > This brings up two questions: > when to use make.conf and when to use src.conf, make.conf is for building everything, so ports, or your own programs. src.conf is for building and installing /usr/src. WITH_, WITHOUT_ or MK_ settings go in here. > and.. > >> WITHOUT_PROFILE=yes >> WITHOUT_DEBUG_FILES=yes >> WITHOUT_TESTS=yes > which of the following is correct and why? > > WITH_DEBUG_FILES=no > WITHOUT_DEBUG_FILES=yes Since r265399, the WITHOUT_ setting wins. Note that the value of the WITH_ or WITHOUT_ setting does not matter, so WITH_DEBUG_FILES=no still means that DEBUG_FILES is turned on. If you want less ambiguity, spell your settings in src.conf like: MK_FOO=yes MK_BAR=no -Dimitry --Apple-Mail=_F5C8CD1B-D1FE-48F0-A1B0-007C3176B7D0 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.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWkPA2wAKCRCwXqMKLiCW o87xAJ0fOfm8ESEPbC2TS0104AeuYzu00ACeJuHFL/StNq78jseqACVIKICqOvA= =JLAW -----END PGP SIGNATURE----- --Apple-Mail=_F5C8CD1B-D1FE-48F0-A1B0-007C3176B7D0-- From owner-freebsd-current@freebsd.org Wed Dec 27 20:34: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 29514EABABA for ; Wed, 27 Dec 2017 20:34:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D120276EA2; Wed, 27 Dec 2017 20:34:12 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9D34B2E5BB; Wed, 27 Dec 2017 21:34:09 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IjNtDFGCcSq; Wed, 27 Dec 2017 21:34:08 +0100 (CET) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 3B8182E5BA; Wed, 27 Dec 2017 21:34:08 +0100 (CET) Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error To: "O. Hartmann" Cc: "Rodney W. Grimes" , Cy Schubert , FreeBSD CURRENT , Freddie Cash , Alan Somers , Daniel Kalchev References: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> <4d58b06a-0dbe-af05-1bd2-e87929e3b7a5@digiware.nl> <20171223122608.4ea4f097@thor.intern.walstatt.dynvpn.de> From: Willem Jan Withagen Message-ID: Date: Wed, 27 Dec 2017 21:34:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20171223122608.4ea4f097@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 27 Dec 2017 20:34:13 -0000 On 23/12/2017 12:25, O. Hartmann wrote: > Am Thu, 14 Dec 2017 12:05:20 +0100 > Willem Jan Withagen schrieb: > >> On 13/12/2017 17:47, Rodney W. Grimes wrote: >>>> On Tue, 12 Dec 2017 14:58:28 -0800 >>>> Cy Schubert wrote: >>>> I think people responding to my thread made it clear that the WD Green >>>> isn't the first-choice-solution for a 20/6 (not 24/7) duty drive and >>>> the fact, that they have serviced now more than 25000 hours, it would >>>> be wise to replace them with alternatives. >>> >>> I think someone had an apm command that turns off the head park, >>> that would do wonders for drive life. On the other hand, I think >>> if it was my data and I saw that the drive had 2M head load cycles >>> I would be looking to get out of that driv with any data I could >>> not easily replace. If it was well backed up or easily replaced >>> my worries would be less. >> >> WD made their first series of Green disks green by aggressively turning >> them into sleep state. Like when few secs there was nog activity they >> would park the head, spin it down, and sleep the disk... >> Access would need to undo the whole series of command. >> >> This could be reset by writing in one of the disks registers. I remember >> doing that for my 1,5G WDs (WD15EADS from 2009). That saved a lot of >> startups. I still have 'm around, but only use them for things that are >> not valuable at all. Some have died over time, but about half of them >> still seem to work without much trouble. >> >> WD used to have a .exe program to actually do this. But that did not >> work on later disks. And turning things of on those disks was >> impossible/a lot more complex. >> >> This type of disk worked quite a long time in my ZFS setup. Like a few >> years, but I turned parking of as soon as there was a lot of turmoil >> about this in the community. >> Now I using WD reds for small ZFS systems, and WD red Pro for large >> private storage servers. Professional server get HGST He disks, a bit >> more expensive, but very little fallout. >> >> --WjW > > Hello fellows. > > First of all, I managed it over the past week+ to replace all(!) drives with new ones. I > decided to use this time HGST 4TB Deskstar NAS (HGST HDN726040ALE614) instead of WD RED > 4TB (WDC WD40EFRX-68N32N0). The one WD RED is about to be replaced in the next days. > > Apart from the very long resilvering time (the first drive, the Western Digital WD RED > 4TB with 64MB cache and 5400 rpm) took 11 h, all HGST drives, although considered faster > (7200 rpm, 128 MB cache) took 15 - 16 h), everything ran smoothly - except, as mentioned, > the exorbitant times of recovery. > > A very interesting point in this story is: as you could see, the WD Caviar Green 3TB > drives suffered from a high "193 Load_Cycle_Count" - almost 85 per hour. When replacing > the drives, I figured out, that one of the four drives was already a Western Digital RED > 3TB NAS drive, but investigating its "193 Load_Cycle_Count" revealed, that this drive > also had a unusual high reload count - see "smartctl -x" output attached. It seems, as > you already stated, that the APM feature responsible for this isn't available. The drive > has been purchased Q4/2013. > > The HGST drives are very(!) noisy, th ehead movement induces a notable ringing, while the > WD drive(s) are/were really silent. The power consumption of the HGST drives is higher. > But apart from that, I'm disappointed about the fact that WD has also implemented this > "timebomb" Load_Cycle_Count issue. Oliver, I would think there is something really off at your end... I have the same type of disks as your RED 3T, and it gives 10 load-cycle_counts in 38258 hours and 28 off-on cycles.... Different model, but same firmware. --WjW === START OF INFORMATION SECTION === Model Family: Western Digital Red Device Model: WDC WD30EFRX-68AX9N0 Serial Number: WD-WMC1T4089783 LU WWN Device Id: 5 0014ee 6ae226f02 Firmware Version: 80.00A80 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Wed Dec 27 21:25:23 2017 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (38940) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 391) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x70bd) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 186 178 021 Pre-fail Always - 5675 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 28 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 048 048 000 Old_age Always - 38258 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 28 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 17 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 10 194 Temperature_Celsius 0x0022 119 110 000 Old_age Always - 31 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged From owner-freebsd-current@freebsd.org Thu Dec 28 07:28:17 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 1AF3FEAC500 for ; Thu, 28 Dec 2017 07:28:17 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 E020C6F89A for ; Thu, 28 Dec 2017 07:28:16 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x232.google.com with SMTP id j7so22461181ybl.3 for ; Wed, 27 Dec 2017 23:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6ILkVC98AIsX90tPQapbjlkd2UEsmuheuq5U4MtG3zQ=; b=OSC6kkF5uL96Pe5aSkU7aEdnqSKl39zQknnPefVFLdGy5YCQw8h+hakgX1lATqOYqo UB5Ein2WUivRJIoqjP+Bk8kWNtGKOMZPEKYfcGd6e31Hh1MPPQGUTouaZAQXrBLwj9C/ E+7eDHWUxAOb/iS8AXt+bHTF6geWBvkXAqun0= 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=6ILkVC98AIsX90tPQapbjlkd2UEsmuheuq5U4MtG3zQ=; b=p0ceF9FTG5mChOL4p9A+e4ViEP0pTWTR5uDVajnDE/hcRSVJPvx0jb6P2Sufu98uZj ng8XF6lPlsrj0bC/fWpzMwCQaSsSHQbln/xkqwzMtqCTkLNvXX5SZaw49HmqnszCKTmo ggPdvgrdY3p/wVn11iqO66rfkaDLnG9eEjBlbBNACfjdMaTumwwG6xFFJn0KvuzvAYLu NHNQbuZ4SmSor1qnx9SSPfGqWQI29SZSBskVIqOqjb3MasbFLkRiuObYBAsvFBRjRI7a AntP2i874heyOR+SlgrfwrDrTA96bBUy15ZYWevpHjR89cjIORUbHejBjZ7tqY5MnJlA H47g== X-Gm-Message-State: AKGB3mJNmykCb6UQNZjlXYLiSu4gTyL1gkJl/tMSN1WdE1G3x2WAcV+e WbrPepS31okSDnEd8Qnmi0szt9mhW30Y7SCVibnK0Q== X-Google-Smtp-Source: ACJfBosEPb5qUc/dV/KgoGWBs1Eo6X2RgJ+7wC8EJc0z0n/NMWhO7JDLOwiJPoDoThReNhCBhiF6rnuJOR9I4mh8I4A= X-Received: by 10.37.210.216 with SMTP id j207mr13472344ybg.517.1514446095841; Wed, 27 Dec 2017 23:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.21 with HTTP; Wed, 27 Dec 2017 23:27:45 -0800 (PST) In-Reply-To: <8D8CFFA3-ADE9-402F-B9A1-C311E4244FCB@dsl-only.net> References: <8D8CFFA3-ADE9-402F-B9A1-C311E4244FCB@dsl-only.net> From: Eitan Adler Date: Wed, 27 Dec 2017 23:27:45 -0800 Message-ID: Subject: Re: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/) To: Mark Millard Cc: FreeBSD Hackers , 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.25 Precedence: 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, 28 Dec 2017 07:28:17 -0000 On 16 December 2017 at 20:34, Mark Millard wrote: > > On 2017-Dec-16, at 8:23 PM, Eitan Adler wrote: > >> On 16 December 2017 at 10:47, Mark Millard wrot= e: >>> I got a "swap_pager: indefinite wait buffer" notice and looked >>> it up. (This was on a rpi2 booted (kernel and world) from a >>> USB SSD, swap partition in use instead of a swap file. It >>> was building devel/cmake via poudriere-devel .) >>> >>> https://www.freebsd.org/doc/faq/troubleshoot.html#indefinite-wait-buffe= r >>> reads like it is for page-out to disk: >>> >>> >>> QUOTE >>> 5.9. >>> >>> What does the error swap_pager: indefinite wait buffer: mean? >>> >>> This means that a process is trying to page memory to disk, and the pag= e attempt has hung trying to access the disk for more than 20 seconds. It m= ight be caused by bad blocks on the disk drive, disk wiring, cables, or any= other disk I/O-related hardware. If the drive itself is bad, disk errors w= ill appear in /var/log/messages and in the output of dmesg. Otherwise, chec= k the cables and connections. >>> ENDQUOTE >>> >>> >>> But the code containing the message is for "swread": >>> (head -r326888) >> >> If I understand correctly this is fixed by change "trying to page to" >> to "trying to page from" ? In other words this happens on swap-in, >> not swap-out. > > That is my understanding of what I reported. Sorry about the delay: Sending faq/book.xml Transmitting file data .done Committing transaction... Committed revision 51344. Fixed. --=20 Eitan Adler From owner-freebsd-current@freebsd.org Fri Dec 29 19:15: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 39238EABE3A for ; Fri, 29 Dec 2017 19:15:45 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC25E77D24 for ; Fri, 29 Dec 2017 19:15:44 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x22f.google.com with SMTP id t8so49618144wmc.3 for ; Fri, 29 Dec 2017 11:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=AeIknZE8WuzRdPyVpReDBOjZ1ydkH9FGMMpdbLmtqGs=; b=GSIFEWLZvOMy9VkFEgRryMBSXx0TT+akb2TNkXpJDbIhz65LR8Wxdelm1i3Z4TPuKB 87tkCswpkwOCrKwo34BZMwK6iO8tffjTefEvsm3buszu9ys/AJ7rgnndbFThCof4XFdQ k7h2VXD9psD3TrZ4uX5MQUlP9XTZ2xwaojOuzpwSH8eRE8BW/QMUt0XBAXgbWp4NJP39 wXsgvKmgycH/HWgpWkLrpBDzyAZ0CmKdaFDkOXEI3W2rTLXInk1QWzLXpC6c8oVF7pyA mm8Vkbb+GxANoJ7A3fPEvEh6/ANRf3wA80gCdBqEK+6AqqWjyVsNLZYhV2rGdl2A0FjC FQAA== 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=AeIknZE8WuzRdPyVpReDBOjZ1ydkH9FGMMpdbLmtqGs=; b=guLWwmyPoa/aOfogcTl4gpBg2o00ZvNmFq9lHBJBhP1GQH4YMs/g7/80/dz+GaO63u xNCMf+qvwDoZxFuR4SU01Q62EDKzbSjeqwM93sYU7CAhPLUkFrQU9MdyKxIXWHwitpvN nSD30W3Jej/NEsa9ZrWXkZMVu1CQGyiR1+leycWdNL0oE+TvfSVzUyLOMpk7SPYOqThm +4LC/Jl5EoR6wL+TczAbI1FlEnfahsHH5w/oavUuzliZjToqRVdRoF2mDYsXY//62vGc IIHtlmpm3g1TVTgRbq010vu4vryLWbP7hwNpiqb4Z1xlZtC6ryCrsJbEjW3fni2KgNHa sDeA== X-Gm-Message-State: AKGB3mJMyDBS20BON4CLCJ7gK3C8mGEORHpveNbqJsqNjvcPtd8bhKfR 88ZqF6W6A+2g226GaixJ8HwJm9wQOD4labsAAkgD32PSsTL/bZ8bhWUZhWqcdCcbvQKKxNmc+WZ wC4fHSsuXAxdn74FY40a8u8o3ihF/H0cuu2tFsKCW9Yf7Wl9YJK4ZdtR4Ynb6RH1yBTdG5RtV+Q iX39H+/Y0= X-Google-Smtp-Source: ACJfBouMdGTJMMhUS/wo6sAPPY+cJZ9Aq39Uw3uB/mst+TFbm05z31HIG+9WZYFNYcQIZ3DemSmbzw== X-Received: by 10.28.112.1 with SMTP id l1mr30723947wmc.139.1514574942061; Fri, 29 Dec 2017 11:15:42 -0800 (PST) Received: from mutt-hbsd ([193.90.12.118]) by smtp.gmail.com with ESMTPSA id m69sm5211957wma.3.2017.12.29.11.15.38 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Dec 2017 11:15:40 -0800 (PST) Date: Fri, 29 Dec 2017 14:15:16 -0500 From: Shawn Webb To: freebsd-current@freebsd.org Subject: evdev broken Message-ID: <20171229191516.a4aooetcwrwqndxe@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qjw2hjlnagpw6f6f" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171208 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 29 Dec 2017 19:15:45 -0000 --qjw2hjlnagpw6f6f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey All, It looks like evdev support in the kernel is broken. sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to different evdev-related symbols. I have the following options in my kernel config: options EVDEV_SUPPORT options EVDEV_DEBUG options UINPUT_DEBUG Here's the build failure log: linking kernel.full = = =20 ld: error: undefined symbol: evdev_rcpt_mask = = =20 >>> referenced by kbdmux.c:1190 (/usr/src/sys/dev/kbdmux/kbdmux.c:1190) = = =20 >>> kbdmux.o:(kbdmux_init) = = =20 = = =20 ld: error: undefined symbol: evdev_push_leds = = =20 >>> referenced by kbdmux.c:1191 (/usr/src/sys/dev/kbdmux/kbdmux.c:1191) = = =20 >>> kbdmux.o:(kbdmux_init) = = =20 = = =20 ld: error: undefined symbol: evdev_alloc = = =20 >>> referenced by kbdmux.c:492 (/usr/src/sys/dev/kbdmux/kbdmux.c:492) = = =20 >>> kbdmux.o:(kbdmux_init) ld: error: undefined symbol: evdev_set_name=20 >>> referenced by kbdmux.c:493 (/usr/src/sys/dev/kbdmux/kbdmux.c:493) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_set_phys =20 >>> referenced by kbdmux.c:495 (/usr/src/sys/dev/kbdmux/kbdmux.c:495) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_set_id = =20 >>> referenced by kbdmux.c:496 (/usr/src/sys/dev/kbdmux/kbdmux.c:496) >>> kbdmux.o:(kbdmux_init) ld: error: undefined symbol: evdev_set_methods =20 >>> referenced by kbdmux.c:497 (/usr/src/sys/dev/kbdmux/kbdmux.c:497) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_support_event >>> referenced by kbdmux.c:498 (/usr/src/sys/dev/kbdmux/kbdmux.c:498) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_support_event >>> referenced by kbdmux.c:499 (/usr/src/sys/dev/kbdmux/kbdmux.c:499) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_support_event >>> referenced by kbdmux.c:500 (/usr/src/sys/dev/kbdmux/kbdmux.c:500) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_support_event >>> referenced by kbdmux.c:501 (/usr/src/sys/dev/kbdmux/kbdmux.c:501) >>> kbdmux.o:(kbdmux_init) = = =20 = =20 ld: error: undefined symbol: evdev_support_all_known_keys >>> referenced by kbdmux.c:502 (/usr/src/sys/dev/kbdmux/kbdmux.c:502) >>> kbdmux.o:(kbdmux_init) =20 =20 ld: error: undefined symbol: evdev_support_led >>> referenced by kbdmux.c:503 (/usr/src/sys/dev/kbdmux/kbdmux.c:503) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_support_led >>> referenced by kbdmux.c:504 (/usr/src/sys/dev/kbdmux/kbdmux.c:504) >>> kbdmux.o:(kbdmux_init) = = =20 = = =20 ld: error: undefined symbol: evdev_support_led >>> referenced by kbdmux.c:505 (/usr/src/sys/dev/kbdmux/kbdmux.c:505) >>> kbdmux.o:(kbdmux_init) =20 ld: error: undefined symbol: evdev_register =20 >>> referenced by kbdmux.c:507 (/usr/src/sys/dev/kbdmux/kbdmux.c:507) >>> kbdmux.o:(kbdmux_init) =20 = = =20 ld: error: undefined symbol: evdev_free = = =20 >>> referenced by kbdmux.c:508 (/usr/src/sys/dev/kbdmux/kbdmux.c:508) = = =20 >>> kbdmux.o:(kbdmux_init) =20 =20 ld: error: undefined symbol: evdev_free = =20 >>> referenced by kbdmux.c:583 (/usr/src/sys/dev/kbdmux/kbdmux.c:583) >>> kbdmux.o:(kbdmux_term) =20 =20 ld: error: undefined symbol: evdev_rcpt_mask =20 >>> referenced by kbdmux.c:750 (/usr/src/sys/dev/kbdmux/kbdmux.c:750) = = =20 >>> kbdmux.o:(kbdmux_read_char) = = =20 = = =20 ld: error: undefined symbol: evdev_scancode2key = = =20 >>> referenced by kbdmux.c:751 (/usr/src/sys/dev/kbdmux/kbdmux.c:751) = = =20 >>> kbdmux.o:(kbdmux_read_char) Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --qjw2hjlnagpw6f6f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlpGlEAACgkQaoRlj1JF bu4T3A//caLqvj3mhJ2WijGdOYHs378wv3VCYD0z3eWXCrqNTdlQ6ueTwaDwpOnX TKoPbYEyAyuvaaexJd0ZD3SRyvuvVwdU0cAu41LaYB3DfHedAWzR2vJLOrJoa9DD fn3JY9N+0aAZeh4BO56geqickccBj7rR9p8g3ceEE7y63dHInvcZul8aqPNmef+2 4Il4ouEmuDJI5MsBVuwwWOQ4SjGMd1Aho7HYt2TAqMhCn60ZzC1DZPnWd7AY956S arFtxJD7H8Xq9CpOCyHD7lBSbPEWB995xNn0S60qRCzSt9bVi7xheNit8lzGpxLm /yKK9SIfNbSw3+L0J7n6nLd/kkyzQk+33+d+VKT3sdJeujN08l5Ox3eUxijAHJ3/ z7fD27RX+FSd9PnPGa9WwPcw37ev7WQ07N7UMzC5ur1Oo14KPKdiHrwYQeHhfOKq dgEjnMQzqKaXByvv+4IrLxuBj7dRkXfjC+WAGhKu7USMyxxifFTUawel6pMvLXtw 877aQutpda3qRZ9EKLNSxrmHUCkaDoFJunEkXIXN/6akxm9yqez95qbb+KNLehZ6 jUDEdvMVyu0Wbjfqi+fT2lcnDrbjRzOelLRrDc9qLWg+RUok6zlhck+lEYXNfmz6 7yh+djCrqEM0STdI/PSyB2kktFJq7bjg/LI9NA8v58t3LeujalI= =USCn -----END PGP SIGNATURE----- --qjw2hjlnagpw6f6f-- From owner-freebsd-current@freebsd.org Fri Dec 29 19:36: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 A5E6AEACBCF for ; Fri, 29 Dec 2017 19:36:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 368B27884D for ; Fri, 29 Dec 2017 19:36:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x22c.google.com with SMTP id f140so49347608wmd.2 for ; Fri, 29 Dec 2017 11:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=g1GZzw3FgZpgmHzR5LPY10KnpgByuJYfz3IhgAinsRg=; b=Q/E6diltWZn9l7NH17DuiS03LMLtwhKogzd+fOZCZ2iSvvK4A/iqp0hbf3DUxogs51 1joClA/ErOt8pVqcsC5gDKCNFBvP/C9PpAmLWRSG2YY2pqY3M+4dI1qdt1vp0NymypiI jNyn3aA/biyXM0IpwLG/CmIXXz7HKRHGyWHL+PAdz3ZGkAZILOFsBBSOzcpmcGxzTPAs mnF3fL3SWGaofePucA++1vBUQQOnk9vZ1rTAmGrmp8R77kA6nJCosADe0wdk7/ZsrIZ+ eYVdiM0N+/KKfZSXIR1kIhbYfjaQGkRiwRCtPnR2EZ3r0g5iC45cxxa/utQgf0xkaI6v QWJQ== 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=g1GZzw3FgZpgmHzR5LPY10KnpgByuJYfz3IhgAinsRg=; b=OX9Zw3NSypuG08TUZC5XHsZ0QwefcXDRHEQvZpgDbqV2X8RJVnuxQSBYSMdkhpWgH/ dm5WhOsxVxjMF5qqiGvrpUFkHQ530o1HNVnPGf9AmQ9ajCFV5AN2LsWwubzkBySk79BP 2SELu/PWIrppfXZgkFDUd9kWLrUibBYwpd+GpKJvmUBN8lMHWhYRffcMxzIksmjB8opM N4AYoOTTKuJuzqSt3nyj7w9jHlYWNXzn08594xOa0ucwbJkM+JBiMkqFFeY6eiBwq0f/ vduIQ2jBzJdrSPVwhbJCfeBFdFnY0xx0twGJxLAck1YAYuxVWu1OPiG7ltH86gxYNBHU M2iw== X-Gm-Message-State: AKGB3mKZkIF2AYWLBtX8VhBEsDkl1VyXXqPrwp18ChF/wkeWzIaaHa+F Nap+61obCYcfM94YwOX4AyWGhTaBY+w= X-Google-Smtp-Source: ACJfBouwDOEH0xWz8GZfS90pVjJ0pZtKUHLVty4W4ncqhF/P5iEyCRJaAHK1y2H8GFQJnRA+OfcFZg== X-Received: by 10.28.66.138 with SMTP id k10mr31109545wmi.88.1514576206520; Fri, 29 Dec 2017 11:36:46 -0800 (PST) Received: from mutt-hbsd ([5.188.86.30]) by smtp.gmail.com with ESMTPSA id e8sm17771570wmc.1.2017.12.29.11.36.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Dec 2017 11:36:45 -0800 (PST) Date: Fri, 29 Dec 2017 14:36:34 -0500 From: Shawn Webb To: Michael Gmelin Cc: freebsd-current@freebsd.org Subject: Re: evdev broken Message-ID: <20171229193634.thukzyt73emvcexs@mutt-hbsd> References: <20171229191516.a4aooetcwrwqndxe@mutt-hbsd> <586A0CCB-76A8-4101-9D60-005DD563B4AB@grem.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qut6ozu373ltih4m" Content-Disposition: inline In-Reply-To: <586A0CCB-76A8-4101-9D60-005DD563B4AB@grem.de> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171208 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 29 Dec 2017 19:36:48 -0000 --qut6ozu373ltih4m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2017 at 08:33:15PM +0100, Michael Gmelin wrote: >=20 >=20 > > On 29. Dec 2017, at 20:15, Shawn Webb wrot= e: > >=20 > > Hey All, > >=20 > > It looks like evdev support in the kernel is broken. > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > different evdev-related symbols. > >=20 > > I have the following options in my kernel config: > >=20 > > options EVDEV_SUPPORT > > options EVDEV_DEBUG > > options UINPUT_DEBUG >=20 > Did you add "device evdev"? Good catch! I did not. Adding now and I'll report back when buildkernel finishes. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --qut6ozu373ltih4m Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlpGmT8ACgkQaoRlj1JF bu4oGRAArA9VakLYELN/baUZRRPQv/uEP6DdhHbdgiG5H5KI58JbxUrSPSIVz2/H w+tcThIIKzFhZOCZsRDrXPYRKQcqFkElse8+auoGQYDSY+oc6BlpiMsZ0pHXDcVO RMQetebvoJgkBpVqfVNY2GhvPS1SkN+kzzl/r/D0gtygPZMzHyjlQ/PsGBJ37guz 7OJLJo3collYHrPcR3E7ib3/YxpM4s7ULH53N/2fWinEJ8FNJjXHQnqme8fpdoQ0 fvjC/VdkxdRAe30vI198eiVPN6yT5sa0uB7H/EaxJNXGr09ZnxXDpBdQpxdDHdTL yhNzQuOBmjXsyecKFEZilDrXXklnSHXpvjefCzKUxdHH2r9KIla+5QD5YMFFwcYA pcRm4gxE1aXfFJCUrl5HRXBTXC14gNs/78A9uYxj7PVLtN2Klssvjyr/dVBtKcc0 BO8LFqc1ymTbclGmIqLJBgpZMDRI2fMeEN1aKylVTJaxwEv/t2YKnh178OBCd36/ VN4XWfUDog+dDjn82BkO7LdIUsOI0k2K+GLY1RoGY5pKp5GXuF1A+zR4PW0Jz7j9 Hr0KSUnjpmUjhYaKYZpz0sMamW0ip9k2st0vetVflZyQKd/Wu4UqCwhVjqRONLD3 1L8HWcbYJTg8RYYQHz1BjcIzCrJB7MVDZo0NMWOQq0IPy0R/zBo= =MYgN -----END PGP SIGNATURE----- --qut6ozu373ltih4m-- From owner-freebsd-current@freebsd.org Fri Dec 29 19:40: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 0F568EACE1A for ; Fri, 29 Dec 2017 19:40:07 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 5CD1B78A24 for ; Fri, 29 Dec 2017 19:40:05 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 16940 invoked by uid 89); 29 Dec 2017 19:33:16 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@93.104.64.114) by mail.grem.de with ESMTPA; 29 Dec 2017 19:33:16 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: evdev broken From: Michael Gmelin X-Mailer: iPhone Mail (14G60) In-Reply-To: <20171229191516.a4aooetcwrwqndxe@mutt-hbsd> Date: Fri, 29 Dec 2017 20:33:15 +0100 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <586A0CCB-76A8-4101-9D60-005DD563B4AB@grem.de> References: <20171229191516.a4aooetcwrwqndxe@mutt-hbsd> To: Shawn Webb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 29 Dec 2017 19:40:07 -0000 > On 29. Dec 2017, at 20:15, Shawn Webb wrote: >=20 > Hey All, >=20 > It looks like evdev support in the kernel is broken. > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > different evdev-related symbols. >=20 > I have the following options in my kernel config: >=20 > options EVDEV_SUPPORT > options EVDEV_DEBUG > options UINPUT_DEBUG Did you add "device evdev"? -m >=20 > Here's the build failure log: >=20 > linking kernel.full = = =20 > ld: error: undefined symbol: evdev_rcpt_mask = = =20 >>>> referenced by kbdmux.c:1190 (/usr/src/sys/dev/kbdmux/kbdmux.c:1190) = = =20 >>>> kbdmux.o:(kbdmux_init) = = =20 >=20 > ld: error: undefined symbol: evdev_push_leds = = =20 >>>> referenced by kbdmux.c:1191 (/usr/src/sys/dev/kbdmux/kbdmux.c:1191) >>>> kbdmux.o:(kbdmux_init) = = =20 >=20 > ld: error: undefined symbol: evdev_alloc = = =20 >>>> referenced by kbdmux.c:492 (/usr/src/sys/dev/kbdmux/kbdmux.c:492) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_set_name=20 >>>> referenced by kbdmux.c:493 (/usr/src/sys/dev/kbdmux/kbdmux.c:493) >>>> kbdmux.o:(kbdmux_init) =20 >=20 > ld: error: undefined symbol: evdev_set_phys =20 >>>> referenced by kbdmux.c:495 (/usr/src/sys/dev/kbdmux/kbdmux.c:495) >>>> kbdmux.o:(kbdmux_init) =20 >=20 > ld: error: undefined symbol: evdev_set_id = =20 >>>> referenced by kbdmux.c:496 (/usr/src/sys/dev/kbdmux/kbdmux.c:496) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_set_methods =20 >>>> referenced by kbdmux.c:497 (/usr/src/sys/dev/kbdmux/kbdmux.c:497) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_support_event >>>> referenced by kbdmux.c:498 (/usr/src/sys/dev/kbdmux/kbdmux.c:498) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_support_event >>>> referenced by kbdmux.c:499 (/usr/src/sys/dev/kbdmux/kbdmux.c:499) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_support_event >>>> referenced by kbdmux.c:500 (/usr/src/sys/dev/kbdmux/kbdmux.c:500) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_support_event >>>> referenced by kbdmux.c:501 (/usr/src/sys/dev/kbdmux/kbdmux.c:501) >>>> kbdmux.o:(kbdmux_init) = = =20 >=20 > ld: error: undefined symbol: evdev_support_all_known_keys >>>> referenced by kbdmux.c:502 (/usr/src/sys/dev/kbdmux/kbdmux.c:502) >>>> kbdmux.o:(kbdmux_init) =20 >=20 > ld: error: undefined symbol: evdev_support_led >>>> referenced by kbdmux.c:503 (/usr/src/sys/dev/kbdmux/kbdmux.c:503) >>>> kbdmux.o:(kbdmux_init) >=20 > ld: error: undefined symbol: evdev_support_led >>>> referenced by kbdmux.c:504 (/usr/src/sys/dev/kbdmux/kbdmux.c:504) >>>> kbdmux.o:(kbdmux_init) = = =20 >=20 > ld: error: undefined symbol: evdev_support_led >>>> referenced by kbdmux.c:505 (/usr/src/sys/dev/kbdmux/kbdmux.c:505) >>>> kbdmux.o:(kbdmux_init) =20 >=20 > ld: error: undefined symbol: evdev_register =20 >>>> referenced by kbdmux.c:507 (/usr/src/sys/dev/kbdmux/kbdmux.c:507) >>>> kbdmux.o:(kbdmux_init) =20 >=20 > ld: error: undefined symbol: evdev_free = = =20 >>>> referenced by kbdmux.c:508 (/usr/src/sys/dev/kbdmux/kbdmux.c:508) >>>> kbdmux.o:(kbdmux_init) =20 >=20 > ld: error: undefined symbol: evdev_free = =20 >>>> referenced by kbdmux.c:583 (/usr/src/sys/dev/kbdmux/kbdmux.c:583) >>>> kbdmux.o:(kbdmux_term) =20 >=20 > ld: error: undefined symbol: evdev_rcpt_mask =20 >>>> referenced by kbdmux.c:750 (/usr/src/sys/dev/kbdmux/kbdmux.c:750) = = =20 >>>> kbdmux.o:(kbdmux_read_char) = = =20 >=20 > ld: error: undefined symbol: evdev_scancode2key = = =20 >>>> referenced by kbdmux.c:751 (/usr/src/sys/dev/kbdmux/kbdmux.c:751) = = =20 >>>> kbdmux.o:(kbdmux_read_char) >=20 > Thanks, >=20 > --=20 > Shawn Webb > Cofounder and Security Engineer > HardenedBSD >=20 > Tor-ified Signal: +1 443-546-8752 > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE From owner-freebsd-current@freebsd.org Fri Dec 29 20:12: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 28007EAE2CB for ; Fri, 29 Dec 2017 20:12:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 9C8EC79BD9 for ; Fri, 29 Dec 2017 20:12:22 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-lf0-x242.google.com with SMTP id m20so35895684lfi.6 for ; Fri, 29 Dec 2017 12:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=l2RV1qBkcL7P3ypjZmBbJqQDFRBlY9VxwGeVpxTqz2s=; b=vF3c+yUWqU607cBVE4ofAWJZzxZyi9H7ffSRbEWEZIC0nTv6wytLPDOr5+zyaGtdwD 98CiAMijYTf/MPmiIwUtijM2Fkn83G2RTwNQQuM1nc0GcZgPndxZVjsZDzv0ipAGARDN 4QIbFkzLpQQfQWOl/dOtI6A9YjkT1fayMCNFvmiYyov2Eboo5SgKX6Mpg/joOjsVSvRr 54yeW9z2CH/p6g9eRYquiNAY/gRTYEKT1sygj9vS/f74PZm3olvJ4seOqKH9wWWX1NPI WjRpiGO+AnPevS6xA3z03ewyhRXT+aUSSRKG2k3IuYlO3mqUn+8USSl6Ei/3ExzDtuvX 53Ww== 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=l2RV1qBkcL7P3ypjZmBbJqQDFRBlY9VxwGeVpxTqz2s=; b=pgwzCuc4EskOGWdrYwaDZlSB4S9OArqHhoTfCDHCWNqY95ctoq/UvU95vV6Vakhp7f 8bBhuyyJ/nqyRRGUQFtymhiKewtVYuptM+b3i+6/ZRnX9YE8ZUqkpzRBW6kPk8CBYU1u JENJCvgHme2CFUwif0AOFFFRWGgo8c0sR4XGvjpVOMCmX833NeovY0NHmquzexy8sAMo +0Oftt/bumKHYwGV8PJ1GfZYkakXmrKTfQhb8kJgxLp9bU8NmMdRCN7AYZGhK6RQMcb7 1KHSLUNULjv9+vaKTcCgJ1A0GuaclDTonUOL1bSqiN6VXFxBeVevDzr6vXqnkXLnvluu pYuw== X-Gm-Message-State: AKGB3mLGABTwcwG3cr1ISs5QkN0JaIDK+HMhmoTzq4r+KgOI/HL5OADs 4Z4s1o7ueDEsjFtUxcBkuc8zDQ== X-Google-Smtp-Source: ACJfBotSuLpcJ71L1BR/9GidkKe9nf8Ce4LIg4E0alKqX8beBZiD2RVW4k3jhIOGsV3hJaa9/Xe3DA== X-Received: by 10.46.82.132 with SMTP id n4mr19700371lje.31.1514578340400; Fri, 29 Dec 2017 12:12:20 -0800 (PST) Received: from mutt-hbsd ([62.102.148.67]) by smtp.gmail.com with ESMTPSA id a7sm5394749lfh.10.2017.12.29.12.12.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Dec 2017 12:12:19 -0800 (PST) Date: Fri, 29 Dec 2017 15:12:07 -0500 From: Shawn Webb To: Michael Gmelin Cc: freebsd-current@freebsd.org Subject: Re: evdev broken Message-ID: <20171229201207.hh7ghu2b7ca7ome4@mutt-hbsd> References: <20171229191516.a4aooetcwrwqndxe@mutt-hbsd> <586A0CCB-76A8-4101-9D60-005DD563B4AB@grem.de> <20171229193634.thukzyt73emvcexs@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="axya3pjyvq3g4gd4" Content-Disposition: inline In-Reply-To: <20171229193634.thukzyt73emvcexs@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171208 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 29 Dec 2017 20:12:23 -0000 --axya3pjyvq3g4gd4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2017 at 02:36:34PM -0500, Shawn Webb wrote: > On Fri, Dec 29, 2017 at 08:33:15PM +0100, Michael Gmelin wrote: > >=20 > >=20 > > > On 29. Dec 2017, at 20:15, Shawn Webb wr= ote: > > >=20 > > > Hey All, > > >=20 > > > It looks like evdev support in the kernel is broken. > > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > > different evdev-related symbols. > > >=20 > > > I have the following options in my kernel config: > > >=20 > > > options EVDEV_SUPPORT > > > options EVDEV_DEBUG > > > options UINPUT_DEBUG > >=20 > > Did you add "device evdev"? >=20 > Good catch! I did not. Adding now and I'll report back when > buildkernel finishes. That did the trick. Thanks! Seems like evdev doesn't have a manpage, which is why I didn't know to include it in my kernel config. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --axya3pjyvq3g4gd4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlpGoZQACgkQaoRlj1JF bu67DQ/9FKSqfIvfKxProcLILL6CgvAjIe6Z/X/1xeyAGTEx4NxGcGYALsI8P3sU ESr2lJwF8xrYO2O7tszt46r51pGR4DDoL1R4B6HCk5mPWSq12yIJjyWLBv2CEVA6 kVF33VtdsWM0vpscLoChTG3RAxkO+fOWxbjBLS5lAH3HI/Bm3T8X9TF2w005ipRK 2nI/isxRBYOhbMNVLuqOZo0ouW/tH8u/NfnzpyaD49SbCVuP8YgFGxL6+PqECvt6 KrFHCKqJkw9q4CqPsOJ3A2rU8EvMjSyWQETjnOrTvOQQraZ69Z/y6sihk7Y6eHHj HALRfuZKU80DVIRbl8BBnsMmccw9Xtl2bzTqpHX3WwQkLcAKZc6BFcGKWw9yqdjF ZR658n7IeWeDKXsrsMlTDnJEj+S70Uqf42d7MZi57GkLulPq7bhsjkIDXJaxpgpF vSaCsvHFWMUSY5mdwIHUThVovkmh0dpRiBicPyTEbakQNsVzbeJBQUcuR657FQyk rODQwJI/2e9hDYx/DkPjYHjpuiYbVfpWXtPShwri+U78rj46LZj9BpYkxkDKM11R RPe7CjHQEO/4rRd3oLIzIohRk0QVGT9zyWlTJX0apHAP1Ht0pzWzqj0wmUwKAEwl MB+Ulmf49eDaGRYBG9+2KRDblEwhHovjqLj4iGLkt5lTHk1oRi4= =jAqI -----END PGP SIGNATURE----- --axya3pjyvq3g4gd4-- From owner-freebsd-current@freebsd.org Fri Dec 29 23:47: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 83B00E80FFD for ; Fri, 29 Dec 2017 23:47:30 +0000 (UTC) (envelope-from 01010160a4ac5f03-b7b69fa3-f430-4695-ac50-a27304437eeb-000000@us-west-2.amazonses.com) Received: from a27-158.smtp-out.us-west-2.amazonses.com (a27-158.smtp-out.us-west-2.amazonses.com [54.240.27.158]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6963315ED for ; Fri, 29 Dec 2017 23:47:29 +0000 (UTC) (envelope-from 01010160a4ac5f03-b7b69fa3-f430-4695-ac50-a27304437eeb-000000@us-west-2.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=hsbnp7p3ensaochzwyq5wwmceodymuwv; d=amazonses.com; t=1514591248; h=Content-Type:From:To:Subject:Message-ID:Date:Content-Transfer-Encoding:MIME-Version:Feedback-ID; bh=FcH8haH+dbqeX80l5WpUNPK45ofsj3wIj4+OJ/qI4bc=; b=Jz+U4sXY1SkLmpAmdudHKOcznssmWddUm1qjxQQuzEmRvB4U5xeZgkndEsKmPVqR dnhsmNBRmypewCj9xgxLWXiA7qiThzkyp+Ns8EQn3hLeLres6maVatsRkgQYnHk+qrC URz85mxC89+OodpCaoEiLVtdCBvbKeiY3TSN7Khg= Content-Type: text/plain From: mqudsi@neosmart.net To: freebsd-current@freebsd.org Subject: Allowing local console root login on PAM initialization failure Message-ID: <01010160a4ac5f03-b7b69fa3-f430-4695-ac50-a27304437eeb-000000@us-west-2.amazonses.com> Date: Fri, 29 Dec 2017 23:47:28 +0000 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SES-Outgoing: 2017.12.29-54.240.27.158 Feedback-ID: 1.us-west-2.PCEy91/Vd+GU67P48MglE9FKtQG6qQD9MhgwC/YKQRM=:AmazonSES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 29 Dec 2017 23:47:30 -0000 Hello all, I have a question regarding the behavior of the PAM module, in = particular pertaining to the default behavior wherein root login is = completely disabled (even from the physical console) when the permissions = on the PAM configuration files in `/etc/pam.d/` are incorrect (anything = other than `600`). It absolutely makes sense for the PAM mechanism to fail= to initialize for safety reasons under these circumstances, and activities= such as remote login, ssh authentication, su/sudo, etc. all make sense to = be blocked. But given that the PAM configuration can be reset from the = local machine in single user mode, is there a benefit to blocking root = login at the tty when PAM fails to initialize? For reference, attempting = to log in at the console when the permissions on `/etc/pam.d/` are = incorrect gives the following error: ``` freebsd login: in = openpam_check_desc_owner_perms(): /etc/pam.d/login: insecure ownership or permissions freebsd login: pam_start(): system error ``` Just wondering if this behavior is intentional or if patches to allow login at the local console upon PAM failure would be welcomed. Thank you, Mahmoud Al-Qudsi NeoSmart Technologies From owner-freebsd-current@freebsd.org Sat Dec 30 07:50:31 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 9B974EAF871 for ; Sat, 30 Dec 2017 07:50:31 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 66FB172F1F for ; Sat, 30 Dec 2017 07:50:31 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x229.google.com with SMTP id f190so33492491ita.5 for ; Fri, 29 Dec 2017 23:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8CgvAbGCMWDZqqEAIeRm/u/bOUxDxB/7wf94SzD0c3E=; b=cKI+KSxMVXe5dZIxMFDjFcK5aWtUKodwI3imDasfv8ir8gkF2SYHq8/1lirkTZOFD1 YJd9qBWvwt9ky+EjXoCDUZVn/xKJragamMm/FMDUPNI5m1AQhdVvpyt2zdIqfGdQGRVu yZHq8JcCckTxjQMGY484CAk1B6Fw/lQWkv1InYP3PREVCUyCd2bfCsbgYpRLOCE9hn/0 oRtVPERXZl/XdaYd6uUyr7UduC7aRffWuugzyQGuT0/QdUA7dtjPha/xkWC9qHIvXDRL djAuGMyf7xoUldKA3PkP7hZaoxrLHUqSnsuDh5Wiol7UppVwGohsp3JaPzJx8w1EnE4o LLgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8CgvAbGCMWDZqqEAIeRm/u/bOUxDxB/7wf94SzD0c3E=; b=nK9zNn1JzB93AsdK1dodOvAFRE694unt4ZjqmhJxiLJFnGxsucoVzLdf9Z2958rP70 FqQSShGHYrPScSR53aNnrqVv0yNhr1opm3gOv9NRxIR9dg5JZdGJRmNkGZst9SO3TQp1 o20w0IMdmmK2PTwwyEsx4XUdSZ39Oiw6j/+CuoUAABvg/5vTzOgv9yvXVGk6rRtsX65e nAs2n7BXIKN07eClIyCNkiaP+DrbHfZtWhx7dgvhO3u9trbxBfencV5mUeTgKhb+iATj AtZeL4EvEUrPBJ+2FGbq6h/ohIbm7NgavhSiz4IG96ef7/4Prr6Uo956ioiW0yENTeNH QzJw== X-Gm-Message-State: AKGB3mIhZs2PpwH/biBuPy8UflrM/M0euck8ssUH56oGdiYlNIhKwc0+ iH0wyGjPia9GYMCfEeT/37/f5n0kNemmP9YZ9J4pzQ== X-Google-Smtp-Source: ACJfBoujc9D4w+e1T9NBdr4wGFm5dgc3fLLizBK0AtAji1V0sltZpJ9hv/pBptQ2OV+C6eH7nAfEXxD7IX3NcyKULzQ= X-Received: by 10.36.116.135 with SMTP id o129mr45360974itc.119.1514620230534; Fri, 29 Dec 2017 23:50:30 -0800 (PST) MIME-Version: 1.0 From: blubee blubeeme Date: Sat, 30 Dec 2017 07:50:19 +0000 Message-ID: Subject: Programmatically cache line To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 07:50:31 -0000 Is there some way to programmatically get the CPU cache line sizes on FreeBSD? From owner-freebsd-current@freebsd.org Sat Dec 30 08:28: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 40808EB13B4 for ; Sat, 30 Dec 2017 08:28:21 +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 CBE5B745E1 for ; Sat, 30 Dec 2017 08:28:20 +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 vBU8SCEF066990 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Dec 2017 10:28:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBU8SCEF066990 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBU8SC76066989; Sat, 30 Dec 2017 10:28:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Dec 2017 10:28:12 +0200 From: Konstantin Belousov To: blubee blubeeme Cc: FreeBSD current Subject: Re: Programmatically cache line Message-ID: <20171230082812.GL1684@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) 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.25 Precedence: 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, 30 Dec 2017 08:28:21 -0000 On Sat, Dec 30, 2017 at 07:50:19AM +0000, blubee blubeeme wrote: > Is there some way to programmatically get the CPU cache line sizes on > FreeBSD? There are, all of them are MD. On x86, the CPUID instruction leaf 0x1 returns the information in %ebx register. From owner-freebsd-current@freebsd.org Sat Dec 30 15:03:29 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 E03C9E89739 for ; Sat, 30 Dec 2017 15:03:29 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 320DA7F245 for ; Sat, 30 Dec 2017 15:03:28 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 28555 invoked by uid 89); 30 Dec 2017 15:03:27 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.104.64.114) by mail.grem.de with ESMTPA; 30 Dec 2017 15:03:27 -0000 Date: Sat, 30 Dec 2017 15:58:57 +0100 From: Michael Gmelin To: "freebsd-current@freebsd.org" , "freebsd-x11@freebsd.org" , "freebsd-mobile@freebsd.org" Subject: Running FreeBSD on the Lenovo Thinkpad T470s (success) Message-ID: <20171230155857.3ba51994@bsd64.grem.de> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 15:03:30 -0000 Hi, I found some time to play with FreeBSD on a Lenovo Thinkpad T470s and I'm quite happy with the results, as all important features work, especially essentials like graphics, touchpad and suspend to RAM. The configuration is pretty straightforward, but a few things required research (like evdev, udev and libinput), that's why I documented my setup here, hoping that it might help others: https://blog.grem.de/pages/t470s.html Best and Happy New Year, Michael p.s. Sorry for cross-posting. -- Michael Gmelin From owner-freebsd-current@freebsd.org Sat Dec 30 15:47: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 520B3E8BA5E; Sat, 30 Dec 2017 15:47:25 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36FC980D7A; Sat, 30 Dec 2017 15:47:24 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBUFlN26076449; Sat, 30 Dec 2017 07:47:23 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBUFlNIf076448; Sat, 30 Dec 2017 07:47:23 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712301547.vBUFlNIf076448@pdx.rh.CN85.dnsmgr.net> Subject: Re: Running FreeBSD on the Lenovo Thinkpad T470s (success) In-Reply-To: <20171230155857.3ba51994@bsd64.grem.de> To: Michael Gmelin Date: Sat, 30 Dec 2017 07:47:23 -0800 (PST) CC: "freebsd-current@freebsd.org" , "freebsd-x11@freebsd.org" , "freebsd-mobile@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 30 Dec 2017 17:00:52 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 15:47:25 -0000 > Hi, > > I found some time to play with FreeBSD on a Lenovo Thinkpad T470s and > I'm quite happy with the results, as all important features work, > especially essentials like graphics, touchpad and suspend to RAM. > > The configuration is pretty straightforward, but a few things required > research (like evdev, udev and libinput), that's why I documented my > setup here, hoping that it might help others: > > https://blog.grem.de/pages/t470s.html Would you care to document it here: https://wiki.freebsd.org/Laptops and add https://wiki.freebsd.org/Laptops/Thinkpad_T470s > Best and Happy New Year, > Michael > > p.s. Sorry for cross-posting. > > -- > Michael Gmelin > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sat Dec 30 20:03: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 ABA05EA9EA5 for ; Sat, 30 Dec 2017 20:03:27 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 6E9206A4F2 for ; Sat, 30 Dec 2017 20:03:27 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.209.229.136] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVNLi-0005Q5-Ox; Sat, 30 Dec 2017 21:03:18 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id vBUK3IBs074607 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Dec 2017 21:03:18 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id vBUK3Hor074606; Sat, 30 Dec 2017 21:03:17 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Dec 2017 21:03:17 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: panic: invalid bcd 194 Message-ID: <20171230200317.GA74180@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.209.229.136 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 20:03:27 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I've got an older Acer C720 with r314251, which was not booted for some tim= e, and now panics on boot, also in single user mode, saying: =2E.. Dec 30 19:54:26 c720-r314251 kernel: ada0: Command Queueing enabled Dec 30 19:54:26 c720-r314251 kernel: ada0: 244198MB (500118192 512 byte sec= tors) Dec 30 19:54:26 c720-r314251 kernel: WARNING: WITNESS option enabled, expec= t reduced performance. Dec 30 19:54:26 c720-r314251 kernel: Trying to mount root from ufs:/dev/ada= 0p2 [rw,noatime]... panic: invalid bcd 194 =2E.. The message comes from=20 $ find * -type f -exec fgrep "invalid bcd" {} /dev/null \; sys/sys/libkern.h: ("invalid bcd %d", bcd)); $ vim sys/sys/libkern.h =2E.. #define LIBKERN_LEN_BCD2BIN 154 #define LIBKERN_LEN_BIN2BCD 100 #define LIBKERN_LEN_HEX2ASCII 36 static inline u_char bcd2bin(int bcd) { KASSERT(bcd >=3D 0 && bcd < LIBKERN_LEN_BCD2BIN, ("invalid bcd %d", bcd)); return (bcd2bin_data[bcd]); } Any idea what could be damaged the system and what to do or check before re-setup? Thanks matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --wac7ysb48OaltWcw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpH8QIACgkQR8z35Hb+ nRFTThAAh9D2ANmelr072ySVT4+CBysxZONDB3RcsWj3fk4sq2t+EY6aXf5xUiCw X+ezqZBC7BoJCJJg/jl7wXylWVgd17XqulGUGPGpyeLuVlyHdM4OVJmtCdNumEz4 UTy3n9NyPrK4wooU/TSnyBU1x1e+LwRKtVjQwCSbNHV/CksrG4qDXK/efOof2V3B BYxEsQDcybLFa7QEGCugcntLziALGCnU1PDjt0hPdXHF50i6AuD4lX7pvUlMcx8C Lz3CnMal1Eh4opVC6o2QssjnlBMnNIVwJc3u3ooKukaMPCKV56IlZznaD5IxaQLs zuBmvZGcpGXR6RMHaSm2Ak+STV+bue7C9hjYV88Z/nhOMQBjcvTgNcJtO9Z9lWda gssD66s7MYPmBdrCTZD+uXspuG9CBkOL07LD9OLe7H2lTf7Mi1HRrCeIXwHrSn8T dZ7Bw6ApfY3uMKsyflpdrBOuic1VDJ0BNfSoSLd+nuKJFCEijeL8QQEKCzmACtyS fXAP11NTPEvIdR6oPfptanOzqGTTrAlS+b3YORr8PONO8lhzpBISdPE1EPq/vkNr 4U8ozkW4zyOl9CrqmBNC8pnyHOMpiDSmEVwECng/3P2a6/qz+Dkix4ajOQtqS0Dd rQgmlUBNoBSWgyjO2a8McHZ5Q40XLRai5S1V6KrhTil0TCiPNnM= =v9VN -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-current@freebsd.org Sat Dec 30 20:53: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 E8222EAC12B for ; Sat, 30 Dec 2017 20:53:39 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 69DB66C86E for ; Sat, 30 Dec 2017 20:53:39 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id h5so7311894lfj.2 for ; Sat, 30 Dec 2017 12:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r3Zfc9ilB+3cGXko5H+/JIAseUACVbqF3omiCs2hO5Q=; b=dcZJ708w27BW2Df1eTVlNRwfMhDNAt4aZGuJfxOvQoDNTM7xD+k/6/AqPJHniK+CEA eTaVmdtX6gc3W20LnDVE/thIthiT5ts5mgLHb10filHkt+ejVpxNNwd4FLfYdO6m70qs hcmswRXGCWG8HpIh24fRrwTCL38L6dL1ym9kMf3pRFr+iTSVu1LSU5roJOcLX7ts+gD3 oqTeUY3pZ6uN8FqIeK9Arbc8E+yne6m+VfGZGNNMhRppMmyzJbzEAV74pmJZ95B8bWy3 a/bHZoyIXZ+toyRGzyFS7hQqZG23WykRYy18Jf0pGoa0o/MqPCi9YxMeNI5Gq0u+carA QJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=r3Zfc9ilB+3cGXko5H+/JIAseUACVbqF3omiCs2hO5Q=; b=BDe4HvPKmQ3Bienx95DTp+ANUVZNKY3Z0Um6gcTJR815UEG0CG3vxrdm3gEoM9tJMb dTuCoPCzveeOr/vEyYMo9xY063jrWNEDrSqDHVZviGjn+7gYRMti/pJeDeh4BAGsbk8o 8+MHgt4bQB6HTk4mWtT9WMD7YV/CstPoym2ZdBdqqlOLIPkUyw6ktC39nV8OKhl2FQ1y +WOZ3no4FYv1tFmvy3RryFVzCAMSxmsalDIup4m+W0A3ktyrxXCH4aXKfoD44IOHtHyv d/GipK/MrRxqJcyR6Eb2X0699tUE/PKVGQHGwo35tydUTPcU7MJnkMFtgaftaaGA9Sn/ zoFA== X-Gm-Message-State: AKGB3mIBtmrhxhKdVUgVcE/4/VwaBtXNFBwRgMAwcrgT8CXl1oUGa0ke xxKhv9rCsrlrSOzqvI3sc/OUCDLe X-Google-Smtp-Source: ACJfBouxBt3rItf9IS4Fcl/uVy3wABYUBk8yvqEA4m263NHqrGn23jm/RlSvoBZ2t/0w43okQvlyYg== X-Received: by 10.46.21.79 with SMTP id 15mr11373607ljv.27.1514667217231; Sat, 30 Dec 2017 12:53:37 -0800 (PST) Received: from [10.145.247.211] (apn-31-0-36-176.dynamic.gprs.plus.pl. [31.0.36.176]) by smtp.gmail.com with ESMTPSA id u10sm7681425lju.25.2017.12.30.12.53.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Dec 2017 12:53:36 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: getfsstat / nullsfs / automount bug? From: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: iPhone Mail (15C114) In-Reply-To: <201711201639.vAKGdA0m099455@donotpassgo.dyslexicfish.net> Date: Sat, 30 Dec 2017 21:53:35 +0100 Cc: freebsd-current@freebsd.org, jamie@catflap.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A781022-9D2B-4731-BD60-7B8D45F53879@FreeBSD.org> References: <201711201639.vAKGdA0m099455@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 20:53:40 -0000 > On 20 Nov 2017, at 17:39, Jamie Landeg-Jones wrot= e: >=20 > There appears to be a bug in the system call related to getmntinfo(3) / ge= tfsstat(2) > , when if the "automount" flag is set on "nullfs" mounts, it is not return= ed on > a getfsstat "WAIT" call. The non-refreshed, non-blocking "MNT_NOWAIT" prod= uces the > correct result. Hi. Could you submit a PR for this? Thanks! From owner-freebsd-current@freebsd.org Sat Dec 30 21:07: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 ABBFBEACB99 for ; Sat, 30 Dec 2017 21:07:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 577ED6D37D for ; Sat, 30 Dec 2017 21:07:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.209.229.136] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVOLY-0000NV-92 for freebsd-current@freebsd.org; Sat, 30 Dec 2017 22:07:12 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id vBUL7BGK076004 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 30 Dec 2017 22:07:11 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id vBUL7BU7076003 for freebsd-current@freebsd.org; Sat, 30 Dec 2017 22:07:11 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Dec 2017 22:07:11 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20171230210711.GA75976@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.209.229.136 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 21:07:15 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa s=C3=A1bado, diciembre 30, 2017 a las 10:44:57p. m. +0200, Kons= tantin Belousov escribi=C3=B3: > On Sat, Dec 30, 2017 at 09:03:17PM +0100, Matthias Apitz wrote: > >=20 > > Hello, > >=20 > > I've got an older Acer C720 with r314251, which was not booted for some= time, > > and now panics on boot, also in single user mode, saying: > >=20 > > ... > > Dec 30 19:54:26 c720-r314251 kernel: ada0: Command Queueing enabled > > Dec 30 19:54:26 c720-r314251 kernel: ada0: 244198MB (500118192 512 byte= sectors) > > Dec 30 19:54:26 c720-r314251 kernel: WARNING: WITNESS option enabled, e= xpect reduced performance. > > Dec 30 19:54:26 c720-r314251 kernel: Trying to mount root from ufs:/dev= /ada0p2 [rw,noatime]... > > panic: invalid bcd 194 > > ... > >=20 > > The message comes from=20 > >=20 > > $ find * -type f -exec fgrep "invalid bcd" {} /dev/null \; > > sys/sys/libkern.h: ("invalid bcd %d", bcd)); > >=20 > > $ vim sys/sys/libkern.h > > ... > > #define LIBKERN_LEN_BCD2BIN 154 > > #define LIBKERN_LEN_BIN2BCD 100 > > #define LIBKERN_LEN_HEX2ASCII 36 > >=20 > > static inline u_char > > bcd2bin(int bcd) > > { > >=20 > > KASSERT(bcd >=3D 0 && bcd < LIBKERN_LEN_BCD2BIN, > > ("invalid bcd %d", bcd)); > > return (bcd2bin_data[bcd]); > > } > >=20 > > Any idea what could be damaged the system and what to do or check before > > re-setup? >=20 > Show the backtrace. Thanks, here we have it as photo: http://www.unixarea.de/download_238222137= _147226.jpg matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpH//wACgkQR8z35Hb+ nRFBJw/+Mq2p0aj+rM3vSnfKTzrT8nZpEbmT7eBtpIXm1lS+GCM1GvQEuFngkFPR FhlGIiJ4buuL3Xb8oEHnKp426PfYPdW+STn0YuBHrP2kWlc+sBSgmFNkhJ+4jFJi EfXkdYECdW8/ujU3cCD/+CuPyDieOszcJ3lic3uzBrGQTVpMhsvqDH1abELmx5u9 UYqhSxcr80P+FPIKFptFZDvCctiDP4kQEgBINtw04FwvpZQI4G7nm/t4XjNQPyua XY21SHoQej57J15nxAtzZXdcOKmS3KGHiKNS4qntZjflbmG9f7C0hVKbeiwErvkK JRzjFIUduuLx+1SxzdYwrfYlphs0zbGKlwyo1dj8QIV6gTCDbL9t3+IfeJ5lenff KZO6Q5B96WS2a50r+UcQ/XKZtlXZRfRODqKRyIwed6d7ymFCu8lFeG4sg4BSGxPr jSSXhG4pIkUaY7EPeLnJGIRy89PADka39PG3/w8DgNprisDhTcmOYMZtXN394jsJ sO9x16VWsSCP20PjUGNd3NQnoW/T9CN6dtXJisSr31TKUQ5kkvcWgZAylPbGYrmX abOZSSB/y4eSiXlePwwPvaZImxdn+aA1xWhzIoGlkJ2IzD/A4e1W6juYvF0xa25w Acz1bTREZr9j/9sUAd0pLwMOtFADcoYrwvJofd6XJHmhv54HEq4= =YUp1 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@freebsd.org Sat Dec 30 21:12:03 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 C6B6AEACE8E for ; Sat, 30 Dec 2017 21:12:03 +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 5EA436D7E4 for ; Sat, 30 Dec 2017 21:12:03 +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 vBULBspd041139 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Dec 2017 23:11:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBULBspd041139 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBULBsm6041138; Sat, 30 Dec 2017 23:11:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 30 Dec 2017 23:11:54 +0200 From: Konstantin Belousov To: Matthias Apitz , freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20171230211154.GT1684@kib.kiev.ua> References: <20171230210711.GA75976@c720-r314251> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171230210711.GA75976@c720-r314251> User-Agent: Mutt/1.9.2 (2017-12-15) 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.25 Precedence: 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, 30 Dec 2017 21:12:03 -0000 On Sat, Dec 30, 2017 at 10:07:11PM +0100, Matthias Apitz wrote: > El d??a s??bado, diciembre 30, 2017 a las 10:44:57p. m. +0200, Konstantin Belousov escribi??: > > > On Sat, Dec 30, 2017 at 09:03:17PM +0100, Matthias Apitz wrote: > > > > > > Hello, > > > > > > I've got an older Acer C720 with r314251, which was not booted for some time, > > > and now panics on boot, also in single user mode, saying: > > > > > > ... > > > Dec 30 19:54:26 c720-r314251 kernel: ada0: Command Queueing enabled > > > Dec 30 19:54:26 c720-r314251 kernel: ada0: 244198MB (500118192 512 byte sectors) > > > Dec 30 19:54:26 c720-r314251 kernel: WARNING: WITNESS option enabled, expect reduced performance. > > > Dec 30 19:54:26 c720-r314251 kernel: Trying to mount root from ufs:/dev/ada0p2 [rw,noatime]... > > > panic: invalid bcd 194 > > > ... > > > > > > The message comes from > > > > > > $ find * -type f -exec fgrep "invalid bcd" {} /dev/null \; > > > sys/sys/libkern.h: ("invalid bcd %d", bcd)); > > > > > > $ vim sys/sys/libkern.h > > > ... > > > #define LIBKERN_LEN_BCD2BIN 154 > > > #define LIBKERN_LEN_BIN2BCD 100 > > > #define LIBKERN_LEN_HEX2ASCII 36 > > > > > > static inline u_char > > > bcd2bin(int bcd) > > > { > > > > > > KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN, > > > ("invalid bcd %d", bcd)); > > > return (bcd2bin_data[bcd]); > > > } > > > > > > Any idea what could be damaged the system and what to do or check before > > > re-setup? > > > > Show the backtrace. > > Thanks, here we have it as photo: http://www.unixarea.de/download_238222137_147226.jpg For an immediate relief, enter the BIOS setup and set up the date. Try to change it even if the BIOS date looks fine. artc(4) should do more validation of the date read from CMOS, but this is a known issue. From owner-freebsd-current@freebsd.org Sat Dec 30 21:48: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 50258EAE4E6 for ; Sat, 30 Dec 2017 21:48:24 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (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 10CFA6F163 for ; Sat, 30 Dec 2017 21:48:23 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [88.217.108.151] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eVOzM-0007zb-Gw; Sat, 30 Dec 2017 22:48:20 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id vBULmJ8n002269 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Dec 2017 22:48:19 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id vBULmJ66002268; Sat, 30 Dec 2017 22:48:19 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Sat, 30 Dec 2017 22:48:19 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: Re: panic: invalid bcd 194 Message-ID: <20171230214819.GA2191@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org References: <20171230210711.GA75976@c720-r314251> <20171230211154.GT1684@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20171230211154.GT1684@kib.kiev.ua> X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 88.217.108.151 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 21:48:24 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa s=C3=A1bado, diciembre 30, 2017 a las 11:11:54p. m. +0200, Kons= tantin Belousov escribi=C3=B3: > > > > static inline u_char > > > > bcd2bin(int bcd) > > > > { > > > >=20 > > > > KASSERT(bcd >=3D 0 && bcd < LIBKERN_LEN_BCD2BIN, > > > > ("invalid bcd %d", bcd)); > > > > return (bcd2bin_data[bcd]); > > > > } > > > >=20 > > > > Any idea what could be damaged the system and what to do or check b= efore > > > > re-setup? > > >=20 > > > Show the backtrace. > >=20 > > Thanks, here we have it as photo: http://www.unixarea.de/download_23822= 2137_147226.jpg >=20 > For an immediate relief, enter the BIOS setup and set up the date. Try to > change it even if the BIOS date looks fine. >=20 > artc(4) should do more validation of the date read from CMOS, but this is > a known issue. The problem with this hardware (Acer C720 Chromebook) is, there is no BIOS setup, only somekind of SeaBIOS w/o any setup. Btw: An older CURRENT from an USB key r285885 boots fine. Any hints? matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpICZwACgkQR8z35Hb+ nRFApw/9GONGr8+CDbTDV8scHjCFZtvV6XBw2ZzTc/gg8sT5j70SwzhHL0Z04nTD DYOo4ACBEDH8T+X/4BbcwG03u8hyGDPIuVAytZTMiCU5w+ux3F0lzmkfV0X0fWAw 8exRHwI78WLN5YL++qSxZoYO0H8ymKeo83dz/S+0lRlysgKxS/51BtMZatZ2klxB paWqapyUIMe4L+FriYfRAImv0rYUfQq1YQTK5HRv46zbAFoFQW3lGIA9cc3YltHS 2zmqrc8sVtzisAcAVNg9BvashLzQkTkbEBY8jfrI6SrKFKb8g4BIpXBM03C8XfL3 a2oOulXwU06wh1jVfH0g12+40r6RP81dWP9/u1Sa7m8AXi7tvY+9dGI+9kgBV0LI aW64wRVBvft7d6Ig3RqI6ffW+To41Wy6rr1OZSJWzDIt5JHjKKhjByH2cDVSB+eX ZtGjxrUrBJkHZpRYbhHOzjnYD4iDVUD0EcvG4sZf6xcgkkHSAnf5R3SFZz5Pxq2W drnJvDv4ehasW/p5xR+RLwafKaNHunNjKddh9wpmgohRUfHh/5AWzVAjvKXijGBI 37FR1kBeaDHcs6KxZE4XyIgLWd2nfLZJ3vnxnIQ64b8EQKvi/adA9uBDqrXlcxY8 lcHwmqlT4nQAHxqlBCyXzfaSy2bNuVqEgCPggnGgVfKqZ0PoUZU= =ORdz -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@freebsd.org Sat Dec 30 23:41: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 A09A7EB25C8 for ; Sat, 30 Dec 2017 23:41:42 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 050AA73321 for ; Sat, 30 Dec 2017 23:41:41 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.181.45.37]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LjrDd-1f2qpm0GYD-00bwbm for ; Sun, 31 Dec 2017 00:41:39 +0100 Date: Sun, 31 Dec 2017 00:41:10 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Message-ID: <20171231004137.4f9ad496@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_/I4FGFXqjP4jWLr345mifm9X"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:fbecknDcwqLtfuoT0NJ+K/qMKPRp+QtKtSnSbkNpAIuzG3hcDLd 9hVJPn3b/gMQ+yjFwZloezOdMTsRbrd5npGK+/AXmQyk3HUprl/W5sW3LE/ox7ZA+NT6rUA Dr5geFseIu4kVXl/D1lKxo+mkuQcQGcTw/utd8PtPihX5xzXcTDVy7oPyXK7Yfj6oR66bPC BI9FDSInEX/c1XhDP1WCA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Qa4Sk/7JN/4=:jcSzippCxoEcvNpa6tCG61 rKVcDpkAu7aOPWKeoN/7uMw0QOrogzqUH7zUkzgPiFc9oK8GawaLCBI1tl7JqgJPQ6TZYVxVz w3VAIJK/QoXvSjRSd8lO1qhJzByvt9T0r6SWYYMwVB7SpOHEZeYEcFfp9pUsKbx3Gfhqlx20D P0NFJAbGtiFHTP4kcdmIA7jKVN8VYgssKJlFxmq4si+sJMHSKUXJN9lsiEBhyf02802BeVNCx 1U1vX45mgfHihmCLotLlYqtvf1nqJ0fxtNfPAm6L6JKSf7nVg1AIYH0QyuFZEqqommIjyUkc6 W8IKtpmEHGDuAiPAMecWR08dnOki7usxF/X3jGywrtqLnH4n0Dg3AP6HPMe4uxP2ClFbTL5lM D/3Y+3bMIWPWgGHvx+TINzdetsxHnwOnXPCDOK/1n2v9rtltZjLWTA+cwHJqcZymyG2oI03eY PofP+/OHQbqXTByOuf8ERqatGOFo4205EC7Jn4XtS8g8GtMngegLoGbaP0yCSIEqvGtFFwn5X giF7bOkw7J2Sctx4yZr3RWgRfTc/ITKfZess5tQKGijeh8UK71VOuuXlAi54IfXO4VHtWGd73 lWDABCfrvW8LvvseeEZDOzkx3m7b1rM4XLLokMCrXuKf0zKOQCoRA/gScoi7Y2mqkkVcMgnbN WlH5d9DJAKfSzyCqwj3i/5s+NztUkWsYPnDRQ/kWnFnpWV0Swe96YTZ6E+Earfz1c0HMX66nD a3H4PK95yQPw2KKFJLaIECBGjVBedkr1HT2NKNDCrZs5F3i2M1RS9w/C4mcmmxJ5M7ok9ai1K nZNjliFpcvDhSopZe6UD4gdWL+eUA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: 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, 30 Dec 2017 23:41:42 -0000 --Sig_/I4FGFXqjP4jWLr345mifm9X Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On most recent CURRENT I face the error shwon below on /tmp filesystem (UFS= 2) residing on a Samsung 850 Pro SSD: =20 UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != =3D bp: 0xd9fba319 handle_workitem_freefile: got error 5 while accessing filesystem UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != =3D bp: 0xd9fba319 handle_workitem_freefile: got error 5 while accessing filesystem UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != =3D bp: 0xd9fba319 handle_workitem_freefile: got error 5 while accessing filesystem UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != =3D bp: 0xd9fba319 handle_workitem_freefile: got error 5 while accessing filesystem UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 != =3D bp: 0xd9fba319 handle_workitem_freefile: got error 5 while accessing filesystem I've already formatted the /tmp filesystem, but obviously without any succe= ss. Since I face such strange errors also on NanoBSD images dd'ed to SD cards, = I guess there is something fishy ... Kind regards, Oliver --=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_/I4FGFXqjP4jWLr345mifm9X Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWkgkMQAKCRDS528fyFhY lNOXAf0fmJldlbfThC3sbeRwtkg/UCBaVfkhtktq9+nYbjXQP9gwsEOcwRYl0GmX qeZY7ihPMYgSTUySESsU9pJFbjGHAgCAEwRCjLMiX9Mh01vK9f5zNZKenI58Tm9H 5cZLkbSnedFhcgjQA57Py9LA8Z1sIiaWqc0FwGJuLmNvzfNCN1x0 =TQse -----END PGP SIGNATURE----- --Sig_/I4FGFXqjP4jWLr345mifm9X--