From owner-freebsd-current@freebsd.org Sun Dec 10 00:04: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 B0015E9C96B for ; Sun, 10 Dec 2017 00:04:59 +0000 (UTC) (envelope-from lausts@laus.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67E657AEDC for ; Sun, 10 Dec 2017 00:04:58 +0000 (UTC) (envelope-from lausts@laus.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id Np70eE2nzdX1SNp72eAPSz; Sun, 10 Dec 2017 00:04:57 +0000 Received: from mail.laus.org (localhost [127.0.0.1]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id vBA04rER001607 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Dec 2017 19:04:54 -0500 (EST) (envelope-from lausts@laus.org) Received: (from lausts@localhost) by mail.laus.org (8.15.2/8.15.2/Submit) id vBA04rgK001606; Sat, 9 Dec 2017 19:04:53 -0500 (EST) (envelope-from lausts) Date: Sat, 9 Dec 2017 19:04:53 -0500 From: Thomas Laus To: Warner Losh Cc: FreeBSD Current Subject: Re: GPTZFSBOOT in Current r326622 has problems Message-ID: <20171210000453.GA1596@mail.laus.org> Reply-To: lausts@acm.org References: <20171206222155.GA1792@mail.laus.org> <20171207001720.GA2058@mail.laus.org> <20171209023153.GA9904@mail.laus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.1-RELEASE-p6 on an amd64 User-Agent: Mutt/1.9.1 (2017-09-22) X-CMAE-Envelope: MS4wfLvW1sSzQd3akWNpgWJdvD0JGldHJPgoUUOE/u/RKBeS0R/yJlAubEY/IKx9K30dxewXh7XS7qb309I81smOSSU+NHol0KvXUiL38lUkMqOgjc9bIARY sMRUF0w+nNZBvDehwG10m9Qygl86X77My5vx3vf1AjzKOgWu2MQ6R9Mk+04WxReXjgSaFKGgtpFccTPxIhsvhjQaYHniOaIzBw8= 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, 10 Dec 2017 00:04:59 -0000 Warner Losh [imp@bsdimp.com] wrote: > OK. I don't recall seeing a screen shot of the entire boot. Can you send > that too (privately if you like) so I know exactly what's failing? Is it > gptzfsboot loading /boot/loader? Is it early in /boot/laoder or ???? > It is failing with a hex dump with a BTX halt even before I get prompted for my Geli password. I suspect that it fails while loading gptzfsboot and even before /boot/loader is read. I'll make a screen shot but all it shows is a hex dump of all of the CPU registers with a message at the bottom of the screen indicating BTX Halt. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Sun Dec 10 00:07: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 D58ECE9CDCE for ; Sun, 10 Dec 2017 00:07:13 +0000 (UTC) (envelope-from lausts@laus.org) Received: from cdptpa-cmomta03.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C5CE7B16D for ; Sun, 10 Dec 2017 00:07:12 +0000 (UTC) (envelope-from lausts@laus.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id NpAVeOeI8mG8pNpAYeTspc; Sun, 10 Dec 2017 00:08:35 +0000 Received: from mail.laus.org (localhost [127.0.0.1]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id vBA078Z6001615 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Dec 2017 19:07:08 -0500 (EST) (envelope-from lausts@laus.org) Received: (from lausts@localhost) by mail.laus.org (8.15.2/8.15.2/Submit) id vBA078LM001614; Sat, 9 Dec 2017 19:07:08 -0500 (EST) (envelope-from lausts) Date: Sat, 9 Dec 2017 19:07:08 -0500 From: Thomas Laus To: Toomas Soome Cc: FreeBSD Current , Warner Losh Subject: Re: GPTZFSBOOT in Current r326622 has problems Message-ID: <20171210000708.GB1596@mail.laus.org> Reply-To: lausts@acm.org References: <20171207001720.GA2058@mail.laus.org> <20171209023153.GA9904@mail.laus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.1-RELEASE-p6 on an amd64 User-Agent: Mutt/1.9.1 (2017-09-22) X-CMAE-Envelope: MS4wfCm/xVjiE0g7gOIkG/CQd/T76t6WTDc9XIXSBrkkI74coIXE5AdaLEdVGo71Wet/hCrMg6jJL2z73U8LepAAZYTa6WS1a6RH4K0HTPQyQLhnP1fDSMYm avQ9/aNWhJg6xcOPduM2ffIxEYtoMsnA+FVCXqwHORjFRpVWqEzcopdmsGLw+2k01D0h0Xm2KBiTKRYg0lcA1CvzWR4wSPe59ho= 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, 10 Dec 2017 00:07:13 -0000 Toomas Soome [tsoome@me.com] wrote: > > > With BIOS boot you can try to press key (space or anything else except enter) - if boot1 is good, you will get boot: prompt. > BTX fails a long time before boot1 is read. I don't even get a prompt for my Geli password. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Sun Dec 10 02:10:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36EF8EA058C for ; Sun, 10 Dec 2017 02:10:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04C827EB4C for ; Sun, 10 Dec 2017 02:10:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x244.google.com with SMTP id f143so9692513itb.0 for ; Sat, 09 Dec 2017 18:10:04 -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=3axZrjyvqrmh2evKhqzB/ckLpZguMsPm0LCdJKeIQkQ=; b=2EYZdR1lg6ApMkudqm87ZsdKdWDN6nFs2Le/FOJ0wMBl9nIhHlvMgCZg/eI9+Rlbl8 Le5zvLMp/QsGsGZ7pv2UiIq9+qaxp6HFtyqi9zbabd0iJknmYVz++K/K5D9Zi9LEyUKS zYRwMmc8EnJ5ZWS5kE4QGxxs6712E4Bl79iyOzzb6JAKn+B5z4p+3nPlTvHFIFu9JUzi YLNuSjP9oaLG3kd5F1U0kkFjhHbRNAza7wZpFwSJE1v/8QF9QD1s/LpJIG3EVsq7fnYn dEr6d37KOFov43pEorX/QolXQp0yKtbUPt6sn9vaE2udYfRIbAP7YCiWiuKMCpHkO62x 2qiQ== 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=3axZrjyvqrmh2evKhqzB/ckLpZguMsPm0LCdJKeIQkQ=; b=UUNUIjmrm6d5dAuOpZRMVQ0K01RoIwpCdcsJ3LpoHwT7k+UBuyO+67PkB6eHhF2Exc 1OemM2CJDW2W+gQG3PPOdEQTgPby92mh314YmM5ut+U62u/cI+N1UuvIK7uWVgy1tTN8 /lqf8re+9bhMztbYH7fEEh4p9qi37FESBEE3jo7BSbrkmSyP1dsUaRdNKB5pOdSYAJN6 2KSzI38RYjVsqeq4O2j5PJWpmQ1IDtnIKSfGTPt9LXGcERM2BqxxJMz2SgF6OAdndq9W RXWFcbzCUaJW583+xguO1wK5T04bu+sxiQ6XqxKSx2Bk93Y/Ie/K64caKfLOgGyC0aoH DMnw== X-Gm-Message-State: AKGB3mJ+7Iwti7p/scAeanF7jFjjZjY7uLWpHxSyZDPT03izlxa2zoTL RkJoaTZpWq4BW+Dzl6AV9RXRZjxNcziWdfS8aEuMMA== X-Google-Smtp-Source: AGs4zMbwsR9xkCloqgZ6vK8Wx142Ane1TfeGHoKA7xTHWs3+4jlpemBI/K5z1k89fA2j7WxnNQye3i5cvoO+QP3w9Mg= X-Received: by 10.36.133.135 with SMTP id r129mr13218137itd.69.1512871803998; Sat, 09 Dec 2017 18:10:03 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sat, 9 Dec 2017 18:10:03 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de> References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Sat, 9 Dec 2017 19:10:03 -0700 X-Google-Sender-Auth: OnRm6Go7QzbPikBKK04PoSkaXdw Message-ID: Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard To: "O. Hartmann" Cc: Michael Tuexen , "O. Hartmann" , FreeBSD CURRENT 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: Sun, 10 Dec 2017 02:10:05 -0000 On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann wrote= : > Am Sat, 9 Dec 2017 14:30:38 -0700 > Warner Losh schrieb: > > > On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann > wrote: > > > > > Am Sat, 9 Dec 2017 13:00:12 -0700 > > > Warner Losh schrieb: > > > > > > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen > > > wrote: > > > > > > > > > > On 9. Dec 2017, at 19:41, O. Hartmann > > > wrote: > > > > > > > > > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails > to > > > boot, > > > > > it gets stuck at > > > > > > the very first messages on the serial console prompting > > > > > > > > > > > > Consoles: internal video/keyboard > > > > > > > > > > > > and then nothing more. > > > > > I don't think it is a general problem with r326734. I'm running o= n > the > > > > > same hardware > > > > > that revision (with some modifications to the TCP I'm testing): > > > > > > uname -a > > > > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 > r326734M: Sat > > > > > Dec 9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/ > > > > > tuexen/head/sys/amd64/compile/TCP amd64 > > > > > > > > > > > > > Hi Michael, > > > > > > > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? > > > Plants > > > > vs Zombies? And did you update your boot blocks or not? > > > > > > > > Warner > > > > > > All right, I got your point here, my bad, my apaologies. > > > > > > I boot from a NanoBSD-prepared image residing on a SD card. The > partiton > > > scheme is GPT, > > > non UEFI (the SeaBIOS, latest version available for the APU2C2 > available) > > > doesn't support > > > UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our > requests. > > > > > > The modifications target at most the creation of a GPT partition sche= me > > > layout, > > > installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot > > > partition as well as > > > boot/boot1.efifat onto a dedicated efi-type partition. The UEFI > partition > > > is usually > > > created before(!) the freebsd-boot partition, but in this specific > > > version, there is NO > > > EFI partition, only the gptboot containing partition. The binaries of > the > > > above mentioned > > > bootcode/efi code images are taken from the newly build world. I do n= ot > > > use boot0sio, the > > > portion where it is installed is excluded by some "if GPT; then" > clause. > > > > > > The last known-good version I reported in working is the image I > backuped > > > last time. I > > > lost the USB 2.0 flash device today containing the last version, that > was > > > not far from > > > r326218, the version that corrupted FreeBSD, I guess it was r326184, > but I > > > really do not > > > know and I havn't a backup of that image. > > > > > > The buildworld process is maintained by a bunch of WITHOUT_ statement= s > in > > > a file driving > > > NanoBSD. This just for the record just in case FreeBSD build system > changed > > > something significantly. > > > > > > > Should, but if you could share what those all are, I can tell you if an= y > > might cause an issue that would help us root cause. > > > > > > > Building a world takes 90 minutes or more, so bi-secting the problem > would > > > be a pain in > > > the arse (that said, I imply that world and kernel need to be in sync= ). > > > > > > I would appreciate hints or tipps where to look after or how to > increase > > > verbosity > > > especially at the first boot stage. > > > > > > > OK. So you are booting with gptboot off an SD card on the PC Engines > system > > via legacy methods for a UFS root partition. GELI is not involved, > correct? > > I do not use GELI. GEOM_GELI is in ther kernel compiled in. No modules ar= e > allowed to be > loaded. > > The disk image created and mounted via md0 (mdconfig -a -t vndo -f > filename.img) looks > like: > > =3D> 40 5175704 md0 GPT (2.5G) > 40 1024 2 boot0 (512K) > 1064 2059464 3 dsks1a (1.0G) > 2060528 2063643 4 dsks2a (1.0G) > 4124171 1048576 5 dsks3 (512M) > 5172747 2997 - free - (1.5M) > > This is the image type without UEFI partition, legacy boot only via > gptboot. > > > > > Sadly, there's no easy way to increase the verbosity of the early boot > > since the boot blocks have to live in such a constrained environment > > there's a strong bias against including debug code. > > > > But what we know is encouraging. We know that gptboot properly loaded, > and > > that it found /boot/loader, loaded it, and then we had the issue. This > > helps us constrain things somewhat in testing. For the moment, we'll > assume > > that gptboot is good, and concentrate on when /boot/loader went south. > > Before we do that, can I get any loader.conf and /boot.config > /boot/config > > files you have? > > boot.config/loader.conf are non existent. > > [loader.conf.local] > boot_serial=3D"YES" > comconsole_speed=3D"115200" > console=3D"comconsole" > > autoboot_delay=3D"5" > > verbose_loading=3D"YES" > loader_logo=3D"none" > beastie_disable=3D"NO" > > kern.geom.label.gptid.enable=3D0 > hw.physmem=3D1073741824 > # Da mehr als 1 igb NIC an Bord! Siehe man igb(4) > kern.ipc.nmbclusters=3D757350 > hw.intrbalance=3D1 > hw.em.max_interrupt_rate=3D16000 > net.fibs=3D6 > net.add_addr_allfibs=3D0 Thanks! This is about what I'd expect, but in these weird things it's always good to be explicit... > src/stand is easily buildable standalone these days, so my thought is > > trying to build it at r326550 and putting that onto into your image. > > src/stand stakes 1 minute to build on my box, so 5 on yours max :). You > can > > even build it standalone in a separate tree if that would help keep > > whatever world you're using to do the builds purer. If we can't get > > satisfaction doing that, then we'll drop back to plan B: if you give me > all > > the WITH/WITHOUT you are using, I could send you a tarball with about t= wo > > dozen /boot/loaders to try which should make bisecting not a total pain > in > > the arse. I'd likely toss in gptboot as well, since it's small. Let me > know > > :) > > Well, that is a kind offer, thanks. Tomorrow morning, I'll try r326550. > For now, I spent > too much time trying to rid of this. > I'm with you on this. I'm just trying to figure out what, exactly, I need to try to setup since this isn't quite my env. So you don't load GELI since you have it in your kernel. Does this mean that gptboot loading from a GELI partition? Warner > Kind regards, > > Oliver > > > > > Since this is very early in /boot/loader's purview, I don't think > > kernel/world matter at all (apart from the fact that loader is built as > > part of world). > > > > The PCengines APU with the most recent SeaBIOS isn't capable of booting > > > FreeBSD from USB > > > 3.0 devices. Even from USB 2.0 flashdrives working images fail at the > boot > > > loader with > > > "failed with error 19". > > > > > > OK. I assume this is a different issue. :) > > > > Warner > > > > > > > > > > > > > > > > > > > > > Best regards > > > > > Michael > > > > > > > > > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct 3 > 11:00:53 > > > > > CEST 2017 amd64 > > > > > > works fine. > > > > > > > > > > > > What the heck has changed? > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > oh > > > > > > > > > > > > -- > > > > > > O. Hartmann > > > > > > > > > > > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Date= n f=C3=BCr > > > > > > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (= =C2=A7 28 > Abs. 4 > > > > > BDSG). > > > > > > > > > > _______________________________________________ > > > > > 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" > > > > > > > > > _______________________________________________ > > > > 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 2= 8 Abs. 4 > BDSG). > > > > > > > -- > 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 Sat Dec 9 20:48: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 49AA2E97DA2 for ; Sat, 9 Dec 2017 20:48:04 +0000 (UTC) (envelope-from o.hartmann@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 C084975172; Sat, 9 Dec 2017 20:48:03 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.223.140]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M0QAP-1fBblf1MIX-00uY1b; Sat, 09 Dec 2017 21:47:54 +0100 Date: Sat, 9 Dec 2017 21:47:46 +0100 From: "O. Hartmann" To: Warner Losh Cc: Michael Tuexen , "O. Hartmann" , FreeBSD CURRENT Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard Message-ID: <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.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_/PP.mSn=08Gpc/um65A/e0xy"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:TEJgSnx3YrOlwbFZMODXwQdQaF27FeOr9uq7bgb4wmH35R7yQuq vkrLKVeHmFgrXg9DsSW6QJCmc5/dqnyBOhQV3e1t/t9sTl2Yvkl+1ncUStjLhTf6JwWRYDy X0s/8xahqWVBAQl8g6MBVVEpdPpfViVhYBbYHp/b2wjPJXQAxbYmPzNiSwElHu72YHg0LBs yLP0+nfmXW/w+fSR7b2Eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:lLD6oW/9r2A=:bwJ3nBWAGh78jLcFpPO9u5 xyxWexEjgKSF+y3K2Ka7Yz6RzHaz+k7x3zP3cL8Sp8ABCkZZqwc/6zSPYUzKju3TGUE0MgiUX 4U7cFvRRO/XP6RhCjeZUagzXaf7k8CsLeDWuCf/4rXdVqMGbBkwqX99lCvRn/4B4sjqbcN4lV 9LdSPUzkLGKWbH2NS/JBaAXu+TI1qHgoKi8lEH0dA9lTcunxcCDfr9wzkK+i6wL8mmlXijQpo HgJdI9FqR2WG8lOSBmljf37njeBxHYynbcf61qRFEom2kZ5yua0nl7Ad15a0P7bGOduMEoqdO 5pVU8K1XQHKfOhFVrrt8yKy2TrJbRIGSnLjkIIZgsODr7qTGRZRpvOCoU3i3u1R/DrWPQ/Cw1 H8MlCFqmjShm/xR6lzt+z768jZj3o1UzhykVTNy7eZ4DGTsi0cjli9/72j+tsrgRsAFe2u8M/ XgPQjPphYCdcZv93GtX+PTlJAQHkYZuwW8tacQA+SpR8Z9Lau8LnaN4ixUqtw70oo68oNbvzF tG1cFJ1rlrgEAUJHK6Z/fXT4igb6/PquEtDkdB8/1BHPNOzagNBZarTtRBoJgZiZz2T9QK6pE wHjH4OLKrZbSfZQ2JLwCo2V8vvlNp3tcVCeOTyDKxEL6/I38Z8Z4oyOdjKyaw82gDfVp9LsjJ 0n6pIcR1bw1KR2A/IEf3VPDWsYX6bVUDMexXWy01yT0h1agoyNu10DIkik3VITfhEvZtna2Lk /W1lUv4CV0p7nsaApCvfuQMy5kF9iGy+GENQ1qdGrOUzdW177ZOojXa2ioVCMJ3UBeCwI36tm 0UUbqF8KHydb83sXGAyq1G5IEulsg== X-Mailman-Approved-At: Sun, 10 Dec 2017 02:43:11 +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, 09 Dec 2017 20:48:04 -0000 --Sig_/PP.mSn=08Gpc/um65A/e0xy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Sat, 9 Dec 2017 13:00:12 -0700 Warner Losh schrieb: > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen wrot= e: >=20 > > > On 9. Dec 2017, at 19:41, O. Hartmann wrote: > > > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails to bo= ot, =20 > > it gets stuck at =20 > > > the very first messages on the serial console prompting > > > > > > Consoles: internal video/keyboard > > > > > > and then nothing more. =20 > > I don't think it is a general problem with r326734. I'm running on the > > same hardware > > that revision (with some modifications to the TCP I'm testing): =20 > > > uname -a =20 > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M: Sat > > Dec 9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/ > > tuexen/head/sys/amd64/compile/TCP amd64 > > =20 >=20 > Hi Michael, >=20 > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? Plants > vs Zombies? And did you update your boot blocks or not? >=20 > Warner All right, I got your point here, my bad, my apaologies. I boot from a NanoBSD-prepared image residing on a SD card. The partiton sc= heme is GPT, non UEFI (the SeaBIOS, latest version available for the APU2C2 available) d= oesn't support UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our requests. The modifications target at most the creation of a GPT partition scheme lay= out, installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot partiti= on as well as boot/boot1.efifat onto a dedicated efi-type partition. The UEFI partition i= s usually created before(!) the freebsd-boot partition, but in this specific version,= there is NO EFI partition, only the gptboot containing partition. The binaries of the a= bove mentioned bootcode/efi code images are taken from the newly build world. I do not use= boot0sio, the portion where it is installed is excluded by some "if GPT; then" clause. The last known-good version I reported in working is the image I backuped l= ast time. I lost the USB 2.0 flash device today containing the last version, that was n= ot far from r326218, the version that corrupted FreeBSD, I guess it was r326184, but I = really do not know and I havn't a backup of that image. The buildworld process is maintained by a bunch of WITHOUT_ statements in a= file driving NanoBSD. This just for the record just in case FreeBSD build system changed something significantly. Building a world takes 90 minutes or more, so bi-secting the problem would = be a pain in the arse (that said, I imply that world and kernel need to be in sync). I would appreciate hints or tipps where to look after or how to increase ve= rbosity especially at the first boot stage. The PCengines APU with the most recent SeaBIOS isn't capable of booting Fre= eBSD from USB 3.0 devices. Even from USB 2.0 flashdrives working images fail at the boot = loader with "failed with error 19". >=20 >=20 >=20 > > Best regards > > Michael =20 > > > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct 3 11:00:53= =20 > > CEST 2017 amd64 =20 > > > works fine. > > > > > > What the heck has changed? > > > > > > Kind regards, > > > > > > oh > > > > > > -- > > > 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 2= 8 Abs. 4 =20 > > BDSG). > > > > _______________________________________________ > > 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 > _______________________________________________ > 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" --=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_/PP.mSn=08Gpc/um65A/e0xy Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWixL8gAKCRDS528fyFhY lBKrAgCOm0dSEWsaeuAnkJDcQYsEDIwllj1ywDS9jDpujRmVTsIOtGqz0u/yV5Lp YAfOHoq1m+9yEBJtIdio+6torB50Af0W0C7MYtEnUyEWWvJKxdPDelJotY1YE3IX cE3x/sprmtybyYunOPuJbxziN16Gf3GNrOtal5rk5xxbVpmT2VRQ =Irk4 -----END PGP SIGNATURE----- --Sig_/PP.mSn=08Gpc/um65A/e0xy-- From owner-freebsd-current@freebsd.org Sun Dec 10 01:35: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 12D37E9EEE8 for ; Sun, 10 Dec 2017 01:35:15 +0000 (UTC) (envelope-from o.hartmann@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 836FE7D9BC; Sun, 10 Dec 2017 01:35:14 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.113.15]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lcjgd-1enrLd3SHn-00kAHv; Sun, 10 Dec 2017 02:35:10 +0100 Date: Sun, 10 Dec 2017 02:35:03 +0100 From: "O. Hartmann" To: Warner Losh Cc: Michael Tuexen , "O. Hartmann" , FreeBSD CURRENT Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard Message-ID: <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <20171209214746.1debb72e@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_/_7FdIqd=XeBdf5_wWJbqJ0u"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:KzGp3VtzLK/gqwRFUVnuQcxaSgO5OTMWCrhwXF4FuYWG0wIVfPp qScWiRhMGJ++RTDZKCDVThRjO1uUYvGCCdORD6aZo7kLo7zAmyngQCsLQ8WKrAsx/duiRyO NNrZzFA8peOCJjOf3YNiwHLHVZKSbLNRpV5hkBiqxknw19m0NWd8SwxPlaoidaS4sjPPz+o hUYl4SvLZztInQb0xhAgA== X-UI-Out-Filterresults: notjunk:1;V01:K0:boZW5xqbmLI=:0Mu0faMWRUzSRpcqVkKTV+ pFWFI4Jw3ndL8rjKv7NSviTnuhd7w1PRmHXxUrQok+lbPt3ZnRHdTYoxENgA2WewnrpL+e4Qi XjzH/WcMi0DIOuFNvY6MG+zV8gHLfp3+CB6tX7x41wPvLuBW6G7kv1SxkuTslYC6yH5Wr4LAW 1Jwg3HTH5homMQrzDB5aYDWhlBQCKj3n7YoEv2GqbzgntLqo4EXbmP2i9dzljzh3ML2ViZXV1 EXqSwY8pOXAJ0OxopCC2DBfbwMapa/cFod4mtANsY4DhOD44aHkMDQHAlw4tJ+iFlknzfMmBY zvgOGv1kd3G7tPIYdJ2rLovvVIJ6bon06LrJtN4W/Og7YgkALivJFIaxVC9/+vrnuderH1gtL +xBGSCRgx5Q3eS6Dt5g+aV3H8u2XIPKC3U6WEtm9PjrVkYQXHDQ/ajR+E9BqNcL5lXcnb/gWq KFIgFfg8aOzV/n6+zCRDmORycn+N8QdFX1/740sGjs7W8qTb/r3nOCT0qJB+aYjShoTG+ENns uL1ujRbb3dJjg2W1BnHKwFYLLf90+8IDt5XajroWEADJqi2aKiGQEAhF87I3wXg/no5UyJqYt mrJxz0JNEXGRlAa7gBazTsJzttiqGvQtZr9s6IjCs5RO0PFiCpg/PNRMEtHgev2IXe3fO+pqv /81w0T5C5n1ZzON0OPq6P3mtxufpHdCLYFKi8kiyI7XZAzTXrHEYEZ5mosAUv8+mdjn2uOyWI M/iuo7GC2by8cGbaNnHj/u+jFFtqgVTyEiVgLRk9ZPY/nPUxXQrTpAggfQjksNd9OUFUaZ1kB X7W2dhlf36RpTZaLZQmHA/VsO9DWw== X-Mailman-Approved-At: Sun, 10 Dec 2017 02:58:04 +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: Sun, 10 Dec 2017 01:35:15 -0000 --Sig_/_7FdIqd=XeBdf5_wWJbqJ0u Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sat, 9 Dec 2017 14:30:38 -0700 Warner Losh schrieb: > On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann wro= te: >=20 > > Am Sat, 9 Dec 2017 13:00:12 -0700 > > Warner Losh schrieb: > > =20 > > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen = =20 > > wrote: =20 > > > =20 > > > > > On 9. Dec 2017, at 19:41, O. Hartmann =20 > > wrote: =20 > > > > > > > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails t= o =20 > > boot, =20 > > > > it gets stuck at =20 > > > > > the very first messages on the serial console prompting > > > > > > > > > > Consoles: internal video/keyboard > > > > > > > > > > and then nothing more. =20 > > > > I don't think it is a general problem with r326734. I'm running on = the > > > > same hardware > > > > that revision (with some modifications to the TCP I'm testing): =20 > > > > > uname -a =20 > > > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 r326734M:= Sat > > > > Dec 9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/ > > > > tuexen/head/sys/amd64/compile/TCP amd64 > > > > =20 > > > > > > Hi Michael, > > > > > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? = =20 > > Plants =20 > > > vs Zombies? And did you update your boot blocks or not? > > > > > > Warner =20 > > > > All right, I got your point here, my bad, my apaologies. > > > > I boot from a NanoBSD-prepared image residing on a SD card. The partiton > > scheme is GPT, > > non UEFI (the SeaBIOS, latest version available for the APU2C2 availabl= e) > > doesn't support > > UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our requests. > > > > The modifications target at most the creation of a GPT partition scheme > > layout, > > installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot > > partition as well as > > boot/boot1.efifat onto a dedicated efi-type partition. The UEFI partiti= on > > is usually > > created before(!) the freebsd-boot partition, but in this specific > > version, there is NO > > EFI partition, only the gptboot containing partition. The binaries of t= he > > above mentioned > > bootcode/efi code images are taken from the newly build world. I do not > > use boot0sio, the > > portion where it is installed is excluded by some "if GPT; then" clause. > > > > The last known-good version I reported in working is the image I backup= ed > > last time. I > > lost the USB 2.0 flash device today containing the last version, that w= as > > not far from > > r326218, the version that corrupted FreeBSD, I guess it was r326184, bu= t I > > really do not > > know and I havn't a backup of that image. > > > > The buildworld process is maintained by a bunch of WITHOUT_ statements = in > > a file driving > > NanoBSD. This just for the record just in case FreeBSD build system cha= nged > > something significantly. > > =20 >=20 > Should, but if you could share what those all are, I can tell you if any > might cause an issue that would help us root cause. >=20 >=20 > > Building a world takes 90 minutes or more, so bi-secting the problem wo= uld > > be a pain in > > the arse (that said, I imply that world and kernel need to be in sync). > > > > I would appreciate hints or tipps where to look after or how to increase > > verbosity > > especially at the first boot stage. > > =20 >=20 > OK. So you are booting with gptboot off an SD card on the PC Engines syst= em > via legacy methods for a UFS root partition. GELI is not involved, correc= t? I do not use GELI. GEOM_GELI is in ther kernel compiled in. No modules are = allowed to be loaded. The disk image created and mounted via md0 (mdconfig -a -t vndo -f filename= .img) looks like: =3D> 40 5175704 md0 GPT (2.5G) 40 1024 2 boot0 (512K) 1064 2059464 3 dsks1a (1.0G) 2060528 2063643 4 dsks2a (1.0G) 4124171 1048576 5 dsks3 (512M) 5172747 2997 - free - (1.5M) This is the image type without UEFI partition, legacy boot only via gptboot. >=20 > Sadly, there's no easy way to increase the verbosity of the early boot > since the boot blocks have to live in such a constrained environment > there's a strong bias against including debug code. >=20 > But what we know is encouraging. We know that gptboot properly loaded, and > that it found /boot/loader, loaded it, and then we had the issue. This > helps us constrain things somewhat in testing. For the moment, we'll assu= me > that gptboot is good, and concentrate on when /boot/loader went south. > Before we do that, can I get any loader.conf and /boot.config /boot/config > files you have? boot.config/loader.conf are non existent. [loader.conf.local] boot_serial=3D"YES" comconsole_speed=3D"115200" console=3D"comconsole" autoboot_delay=3D"5" verbose_loading=3D"YES" loader_logo=3D"none" beastie_disable=3D"NO" kern.geom.label.gptid.enable=3D0 hw.physmem=3D1073741824 # Da mehr als 1 igb NIC an Bord! Siehe man igb(4) kern.ipc.nmbclusters=3D757350 hw.intrbalance=3D1 hw.em.max_interrupt_rate=3D16000 net.fibs=3D6 net.add_addr_allfibs=3D0 >=20 > src/stand is easily buildable standalone these days, so my thought is > trying to build it at r326550 and putting that onto into your image. > src/stand stakes 1 minute to build on my box, so 5 on yours max :). You c= an > even build it standalone in a separate tree if that would help keep > whatever world you're using to do the builds purer. If we can't get > satisfaction doing that, then we'll drop back to plan B: if you give me a= ll > the WITH/WITHOUT you are using, I could send you a tarball with about two > dozen /boot/loaders to try which should make bisecting not a total pain in > the arse. I'd likely toss in gptboot as well, since it's small. Let me kn= ow > :) Well, that is a kind offer, thanks. Tomorrow morning, I'll try r326550. For= now, I spent too much time trying to rid of this. Kind regards, Oliver >=20 > Since this is very early in /boot/loader's purview, I don't think > kernel/world matter at all (apart from the fact that loader is built as > part of world). >=20 > The PCengines APU with the most recent SeaBIOS isn't capable of booting > > FreeBSD from USB > > 3.0 devices. Even from USB 2.0 flashdrives working images fail at the b= oot > > loader with > > "failed with error 19". =20 >=20 >=20 > OK. I assume this is a different issue. :) >=20 > Warner >=20 >=20 > > > > > > > > > =20 > > > > Best regards > > > > Michael =20 > > > > > > > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct 3 11:0= 0:53 =20 > > > > CEST 2017 amd64 =20 > > > > > works fine. > > > > > > > > > > What the heck has changed? > > > > > > > > > > Kind regards, > > > > > > > > > > oh > > > > > > > > > > -- > > > > > 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 =20 > > > > BDSG). > > > > > > > > _______________________________________________ > > > > freebsd-current@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ =20 > > freebsd.org" =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@ =20 > > 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 = Abs. 4 BDSG). > > =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_/_7FdIqd=XeBdf5_wWJbqJ0u Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWiyPRwAKCRDS528fyFhY lIveAf9Lnv1D/mqhs6LiaHu1azCv4fF21LVcc2bhwEz4Qcul1/pJOtnR1U+85S1k Q+p0THIeagWCOUndlGTxNkukiRMFAgCY2nfHuI1NXhs/vG0Uoj12x1lxtdxzSKc/ hnwZUQXyFVVBI0k/riMZweqntC0hyw04vYgUJ4u8FCl9eUAUBzXn =UNvD -----END PGP SIGNATURE----- --Sig_/_7FdIqd=XeBdf5_wWJbqJ0u-- From owner-freebsd-current@freebsd.org Sun Dec 10 06:07: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 DA712E83500; Sun, 10 Dec 2017 06:07:48 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 AD3F765072; Sun, 10 Dec 2017 06:07:48 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x234.google.com with SMTP id m11so8781628iti.1; Sat, 09 Dec 2017 22:07:48 -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=D2dXfAhJbKGLKvyhewSzbtPuYYGL1JZ/VdqWI28RSco=; b=kLKTtHsdnoXngFGT719LMVHR16JbOj7rfhOZbXGZ8HA5E4qkXc+BXTYxVGa1IN7Tv/ sqeQ0yq8sri50bgiTvTvvlIqyPnMr9z2WyoHowgSFWIeK6qvoxbiSBFbsjLcQ1A2OSgr 58P1BPruaaR2jahtxRJC66L+S6WvGguifhVoTzs20ef+iAVxNT83tolCszkfOPHya7ow x1AfcgQTqUSPDzOjMW8dA/qrec1JZJkX1324EszxHPx2Sxm/Y9mCZPbBpym6bZKjdrit fpNcqowqM+2ztPiSuACJvP0Mb/7ZNwQTAmku+Y3+rBWWhaUfTiOquhbmOQKdmuLWGs/E 9ZJg== 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=D2dXfAhJbKGLKvyhewSzbtPuYYGL1JZ/VdqWI28RSco=; b=Pzu+xRT38vMcmSfM+tVNpB3VYq4VgccEZKP8ZSnSUkxsA5ufCd2Y4LfTh+mg2uvAd+ 44J+qLiySlog5XSVPQ+slouTD1W5fayBcoAN6bow65JaxLGXH67yIhlZzjmgiT8a3GJV 2gBlK6hpiU/27srd8JV+8UIcZXdmQWX+3wGtx2ngmCF+IlX5wa5EfOsysYV9xbG0+sVr 79zzLSAP3CCKRwr5qSLWAtb5UBdk1zH2VhZnPUU5KfWJuxNfj7vlk1YWOztTA9EKUkYm YAAgPZy2u+ITWfscu9V67zhoQ3bebHP5QPKI4rGSLYRDPtdsuLXJ8RgeGJTcazQ+bkyc jOSg== X-Gm-Message-State: AKGB3mLNltCGsLCpjmPD8geYQJxVYt7mSA6PjrfoYEta4AQOUibwKz5j D+f8Hjc/HnoAofFNpPp7P+xQMRRVwWfcVtu85Uc= X-Google-Smtp-Source: AGs4zMa5mgW/bbb0z48GQ+NEE9EgiLnOfZGtG7T/GKfdGlPXnNY128IAKmE/HP8DrpgOA144wxc+lSf0Y/9kv7csdXw= X-Received: by 10.36.116.135 with SMTP id o129mr11601221itc.119.1512886067524; Sat, 09 Dec 2017 22:07:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Sat, 9 Dec 2017 22:07:47 -0800 (PST) From: blubee blubeeme Date: Sun, 10 Dec 2017 14:07:47 +0800 Message-ID: Subject: Makefile show all flags To: FreeBSD current , freebsd-questions@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, 10 Dec 2017 06:07:49 -0000 When porting software FreeBSD has a lot of internal makefiles that gets pulled in that setup the build environment: /usr/ports/Mk/* Is there a way to print out the env during the make process so that I can see what knobs, switches and flags were set before the build is run? From owner-freebsd-current@freebsd.org Sun Dec 10 08:49:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1DC9E86238 for ; Sun, 10 Dec 2017 08:49:35 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4849F68B56 for ; Sun, 10 Dec 2017 08:49:35 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id n138so9370244wmg.2 for ; Sun, 10 Dec 2017 00:49:35 -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=11ut9dutHcowSDcurtNJMGlfuBBeoy7TKtQMawQQlXo=; b=CYxCT1iSmHwSKQ/CgHeIiM8MGcaUIZZxwfMfMeTfm4cjHwL5KeHThK1+S0TmjbtiB+ lDYVutPqlMZxDrjhGYGmTSsB4qKE6Jm/QsR0IM87gMjyarbZRiIl6TaGaigt3IBSoSLO oLOLhASHrLq/u529RDR1cmAz4INEU6ean6Wrh3j5GKlaEOO6nZ+gYq+sSJSA4fxBFpyp 4kva+RDK9RgvrvyGy0Nq0gpK6v6qgoCmgo0fj7sQ/wqb7Zu02Tj435aRPtUz8EIYEB6w xb3O6wmAP2teGteo3kGt7LxaHVnzXZQNNtEr1RpaJj1QlSMaVVGyLf2jnwhQBeAiLX/J lZRg== 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=11ut9dutHcowSDcurtNJMGlfuBBeoy7TKtQMawQQlXo=; b=FEdTjPskmP81WbhX+qYa18+6Hr640k1zhoZ9GZmge4LShhh1CqM5kjjyCvfygAIgdz 8ckg8eQ7RkpkMCnbrDNBVEZDzLmBGzkKpNCeUU1KGOuQPxOxO6ZBjhSKn+pVmDoFvQDP 0w4s46me9p4BPlWvPsRUQX8WPZh8pb8Xq0rMCqQ+ziz6iV23BiIfrM3aRPw8dmLtYFFm I57haShLstdYqOU0Z7vC04YHGoA+Kdr+UoeaZ3A5W9pXG8wufEU7IT6WKOqVfwYL+6Wr 2Qnwze4ZztoVwY65SD2t4v4UtrpNdEnvCUJm9kbvbran0adqlP9I50MKUJ59wrZZhUj/ M3hA== X-Gm-Message-State: AKGB3mJCZ0h82niLzT+TsgodY+beuo9Wsd7/mv7X+PFtgv9DKByarL+/ 0QTQMda8U/vCfcz4x2hfFaG1uaLcWs+7ixj3Bc4YMQ== X-Google-Smtp-Source: AGs4zMYwWdfdkOxnICOtoPU1crgNSK8IQRUC0FaZsufkFwsI7TjwGHRaujgTwTWgteFxibcVCyTtJcj6FfSgKBf5xBw= X-Received: by 10.28.157.7 with SMTP id g7mr7008841wme.99.1512895773536; Sun, 10 Dec 2017 00:49:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.197.68 with HTTP; Sun, 10 Dec 2017 00:48:53 -0800 (PST) From: Johannes Lundberg Date: Sun, 10 Dec 2017 09:48:53 +0100 Message-ID: Subject: Advice regarding sync_file implementation To: 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: Sun, 10 Dec 2017 08:49:35 -0000 Hi I'm working on getting drm-next graphics parts up to Linux 4.11. After current drm-next version drm start using sync_file to synchronize access to shared dma buffers between userland and kernel. sync_file is using anon_inode, both which currently are missing from linuxkpi. http://elixir.free-electrons.com/linux/v4.11/source/drivers/dma-buf/sync_file.c#L31 https://elixir.free-electrons.com/linux/v4.11/source/fs/anon_inodes.c#L70 This will be used by both kernel (drm and graphics drivers) and userland (libdrm). What would be the best solution to implement this on FreeBSD? Do we have anything equivalent that we can use or is it best to make a similar implementation as done in Linux? We want to reduce the need of patching upstream and Linux code as much as possible and implement things in linuxkpi to make further updates more smooth. Cheers! /Johannes From owner-freebsd-current@freebsd.org Sun Dec 10 10:15:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92C11E8811E for ; Sun, 10 Dec 2017 10:15:32 +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 12B6F6B382; Sun, 10 Dec 2017 10:15:31 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.113.15]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M3i8r-1fEhke0rnF-00rDf0; Sun, 10 Dec 2017 11:15:21 +0100 Date: Sun, 10 Dec 2017 11:14:51 +0100 From: "O. Hartmann" To: Warner Losh Cc: Michael Tuexen , "O. Hartmann" , FreeBSD CURRENT Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard Message-ID: <20171210111456.15fe1693@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> <20171210023503.6d8e02b3@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_/4mYKGKJVW43qSbN5JQYs41U"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Wv08WAz4+R/KHVLKrWBlaCXwkHkFqyWOg4rWoRUCRAHNC5w8Hqn RN+IXtV9KJfIOknbzu5R5SsfNi1tCuKY6BI5rcFSmRBNpe6Oa9MB2ZQ9tGuce+FSMFK/iWr 9pS8uQn8bINLGmRbJ4ZDoW+dynMxgsGvy658Es7ZqceHRI5+Y/OqLMcnHMoDwEFYzOjwMvF gLyfJsSrhpE7U/HnmTAKA== X-UI-Out-Filterresults: notjunk:1;V01:K0:F0Vwl2NPgdI=:u90UPcEU2uQV0Zp/H/FSx3 zN7+ZjcpUWa2WM4+l7hlp05oouneQQj4yVTIe+mnSNUTJlOGiJ7VxPIB+QUTJsYC/k5k6SAJZ YqPRozWyviZXImloEJyWqZb71XO32Iaem+7c68/jFMuVgbPGIFcSluxBXpa9tR/NkuY1lH1EJ Uro8Gza9fORG7vFJN1W+tvtlOoEFPcgT+osa2ZDKWtVJACmZtny/bjDzKTPNEmkwUM2NT4TFR 7b/5nR6q5r0+bUcTLUGt/GCQYAsgPHSQSKy6zHeLpxJKrUkz6c3+peh2I1KLKK/2g3vtP0gWQ TSD9fyDoDnvhdT1IdvPvj2l2nG2eaqmzMI/pQ89qemUNtubN5pTxuWjzpHP93UMIetTsr0PX7 oOwQO42aNTw4NWyCuhl1TecrRkpPtv0FVz2wIXgzs/X7+Kko4eczsmTBNDVzLXv5/N8+jyyma rDiiJOT9elMyDdAGnUTahE1PeXvvMsm1M38H5aJH/37/3B1IbagGXeHCyflrQFgGqq1+BisZ0 9CeMx3GBptA1Gn9aVYZIX4hOWuRVG2CrlVptHMe7WrlW5X/uXAYRNPVtvFeya5MfHQkuufk7B QClkzCZbgRL9oIIxTdSgSgm8gnPWp1X9h6zgK9QL7sQfR4wXV7QW06D0BZxIiL2jkO+bNc2ev j77sjEKSbdg5/BQD8JzreHnqHsQNiKYnmGwCSK2E/hHK8tZCvWyeWXfctZSe/nfMCoB7bT+09 c5eoy34PqAsA50vniOTT4S2JIsBPyf+G+bs2zkDh6vvIStviL+9ZCtse5pKd4sTfFTVuda6dr OYiPCWiZpiV2P/IBII3K386eD4JFw== 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, 10 Dec 2017 10:15:32 -0000 --Sig_/4mYKGKJVW43qSbN5JQYs41U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sat, 9 Dec 2017 19:10:03 -0700 Warner Losh schrieb: > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann wro= te: >=20 > > Am Sat, 9 Dec 2017 14:30:38 -0700 > > Warner Losh schrieb: > > =20 > > > On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann = =20 > > wrote: =20 > > > =20 > > > > Am Sat, 9 Dec 2017 13:00:12 -0700 > > > > Warner Losh schrieb: > > > > =20 > > > > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen =20 > > > > wrote: =20 > > > > > =20 > > > > > > > On 9. Dec 2017, at 19:41, O. Hartmann =20 > > > > wrote: =20 > > > > > > > > > > > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fai= ls =20 > > to =20 > > > > boot, =20 > > > > > > it gets stuck at =20 > > > > > > > the very first messages on the serial console prompting > > > > > > > > > > > > > > Consoles: internal video/keyboard > > > > > > > > > > > > > > and then nothing more. =20 > > > > > > I don't think it is a general problem with r326734. I'm running= on =20 > > the =20 > > > > > > same hardware > > > > > > that revision (with some modifications to the TCP I'm testing):= =20 > > > > > > > uname -a =20 > > > > > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 =20 > > r326734M: Sat =20 > > > > > > Dec 9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/ > > > > > > tuexen/head/sys/amd64/compile/TCP amd64 > > > > > > =20 > > > > > > > > > > Hi Michael, > > > > > > > > > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MB= R? =20 > > > > Plants =20 > > > > > vs Zombies? And did you update your boot blocks or not? > > > > > > > > > > Warner =20 > > > > > > > > All right, I got your point here, my bad, my apaologies. > > > > > > > > I boot from a NanoBSD-prepared image residing on a SD card. The =20 > > partiton =20 > > > > scheme is GPT, > > > > non UEFI (the SeaBIOS, latest version available for the APU2C2 =20 > > available) =20 > > > > doesn't support > > > > UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our =20 > > requests. =20 > > > > > > > > The modifications target at most the creation of a GPT partition sc= heme > > > > layout, > > > > installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot > > > > partition as well as > > > > boot/boot1.efifat onto a dedicated efi-type partition. The UEFI =20 > > partition =20 > > > > is usually > > > > created before(!) the freebsd-boot partition, but in this specific > > > > version, there is NO > > > > EFI partition, only the gptboot containing partition. The binaries = of =20 > > the =20 > > > > above mentioned > > > > bootcode/efi code images are taken from the newly build world. I do= not > > > > use boot0sio, the > > > > portion where it is installed is excluded by some "if GPT; then" =20 > > clause. =20 > > > > > > > > The last known-good version I reported in working is the image I =20 > > backuped =20 > > > > last time. I > > > > lost the USB 2.0 flash device today containing the last version, th= at =20 > > was =20 > > > > not far from > > > > r326218, the version that corrupted FreeBSD, I guess it was r326184= , =20 > > but I =20 > > > > really do not > > > > know and I havn't a backup of that image. > > > > > > > > The buildworld process is maintained by a bunch of WITHOUT_ stateme= nts =20 > > in =20 > > > > a file driving > > > > NanoBSD. This just for the record just in case FreeBSD build system= =20 > > changed =20 > > > > something significantly. > > > > =20 > > > > > > Should, but if you could share what those all are, I can tell you if = any > > > might cause an issue that would help us root cause. > > > > > > =20 > > > > Building a world takes 90 minutes or more, so bi-secting the proble= m =20 > > would =20 > > > > be a pain in > > > > the arse (that said, I imply that world and kernel need to be in sy= nc). > > > > > > > > I would appreciate hints or tipps where to look after or how to =20 > > increase =20 > > > > verbosity > > > > especially at the first boot stage. > > > > =20 > > > > > > OK. So you are booting with gptboot off an SD card on the PC Engines = =20 > > system =20 > > > via legacy methods for a UFS root partition. GELI is not involved, =20 > > correct? > > > > I do not use GELI. GEOM_GELI is in ther kernel compiled in. No modules = are > > allowed to be > > loaded. > > > > The disk image created and mounted via md0 (mdconfig -a -t vndo -f > > filename.img) looks > > like: > > =20 > > =3D> 40 5175704 md0 GPT (2.5G) =20 > > 40 1024 2 boot0 (512K) > > 1064 2059464 3 dsks1a (1.0G) > > 2060528 2063643 4 dsks2a (1.0G) > > 4124171 1048576 5 dsks3 (512M) > > 5172747 2997 - free - (1.5M) > > > > This is the image type without UEFI partition, legacy boot only via > > gptboot. > > =20 > > > > > > Sadly, there's no easy way to increase the verbosity of the early boot > > > since the boot blocks have to live in such a constrained environment > > > there's a strong bias against including debug code. > > > > > > But what we know is encouraging. We know that gptboot properly loaded= , =20 > > and =20 > > > that it found /boot/loader, loaded it, and then we had the issue. Th= is > > > helps us constrain things somewhat in testing. For the moment, we'll = =20 > > assume =20 > > > that gptboot is good, and concentrate on when /boot/loader went south. > > > Before we do that, can I get any loader.conf and /boot.config =20 > > /boot/config =20 > > > files you have? =20 > > > > boot.config/loader.conf are non existent. > > > > [loader.conf.local] > > boot_serial=3D"YES" > > comconsole_speed=3D"115200" > > console=3D"comconsole" > > > > autoboot_delay=3D"5" > > > > verbose_loading=3D"YES" > > loader_logo=3D"none" > > beastie_disable=3D"NO" > > > > kern.geom.label.gptid.enable=3D0 > > hw.physmem=3D1073741824 > > # Da mehr als 1 igb NIC an Bord! Siehe man igb(4) > > kern.ipc.nmbclusters=3D757350 > > hw.intrbalance=3D1 > > hw.em.max_interrupt_rate=3D16000 > > net.fibs=3D6 > > net.add_addr_allfibs=3D0 =20 >=20 >=20 > Thanks! This is about what I'd expect, but in these weird things it's > always good to be explicit... >=20 > > src/stand is easily buildable standalone these days, so my thought is = =20 > > > trying to build it at r326550 and putting that onto into your image. > > > src/stand stakes 1 minute to build on my box, so 5 on yours max :). Y= ou =20 > > can =20 > > > even build it standalone in a separate tree if that would help keep > > > whatever world you're using to do the builds purer. If we can't get > > > satisfaction doing that, then we'll drop back to plan B: if you give = me =20 > > all =20 > > > the WITH/WITHOUT you are using, I could send you a tarball with about= two > > > dozen /boot/loaders to try which should make bisecting not a total pa= in =20 > > in =20 > > > the arse. I'd likely toss in gptboot as well, since it's small. Let m= e =20 > > know =20 > > > :) =20 > > > > Well, that is a kind offer, thanks. Tomorrow morning, I'll try r326550. > > For now, I spent > > too much time trying to rid of this. > > =20 >=20 > I'm with you on this. I'm just trying to figure out what, exactly, I need > to try to setup since this isn't quite my env. I have to wait until my box has built r326550 ... >=20 > So you don't load GELI since you have it in your kernel. Does this mean > that gptboot loading from a GELI partition? I have a static kernel. Some regulations say, that the kernel is not allowe= de to dynamically load modules at any time, so I just built GEOM_ELI into the ker= nel - I wanted to make that clear for the record.=20 The rest is simple and vanilla, I guess.=20 >=20 > Warner >=20 >=20 >=20 > > Kind regards, > > > > Oliver > > =20 > > > > > > Since this is very early in /boot/loader's purview, I don't think > > > kernel/world matter at all (apart from the fact that loader is built = as > > > part of world). > > > > > > The PCengines APU with the most recent SeaBIOS isn't capable of booti= ng =20 > > > > FreeBSD from USB > > > > 3.0 devices. Even from USB 2.0 flashdrives working images fail at t= he =20 > > boot =20 > > > > loader with > > > > "failed with error 19". =20 > > > > > > > > > OK. I assume this is a different issue. :) > > > > > > Warner > > > > > > =20 > > > > > > > > > > > > > > > =20 > > > > > > Best regards > > > > > > Michael =20 > > > > > > > > > > > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct 3 = =20 > > 11:00:53 =20 > > > > > > CEST 2017 amd64 =20 > > > > > > > works fine. > > > > > > > > > > > > > > What the heck has changed? > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > oh > > > > > > > > > > > > > > -- > > > > > > > O. Hartmann > > > > > > > > > > > > > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Da= ten f=C3=BCr > > > > > > > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (= =C2=A7 28 =20 > > Abs. 4 =20 > > > > > > BDSG). > > > > > > > > > > > > _______________________________________________ > > > > > > freebsd-current@freebsd.org mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ = =20 > > > > freebsd.org" =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@ =20 > > > > 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 Abs. 4 =20 > > BDSG). =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). > > =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_/4mYKGKJVW43qSbN5JQYs41U Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWi0JNwAKCRDS528fyFhY lBeeAf9fh/SkVZbTYf4Zt2yhY+hCErugyrvnZrqvfLYA412ox1okhOHGBfNuGucM e4nRY+zbIjOT8jl0gCoWfuyDxVczAf9JXBVDrOr5eRKxMCd8RQoLvm5vuQ2nt78E 5y72lO7CIEd1ndjIkM/DgzZrRWGGHMiJDEjwpGm6kRvFC+BJoWoy =EOuW -----END PGP SIGNATURE----- --Sig_/4mYKGKJVW43qSbN5JQYs41U-- From owner-freebsd-current@freebsd.org Sun Dec 10 12:54:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55F5CE8BE20 for ; Sun, 10 Dec 2017 12:54:51 +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 C5EF86FF50; Sun, 10 Dec 2017 12:54:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.179.112.209]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MbOoG-1eea4j1DwC-00IkLS; Sun, 10 Dec 2017 13:54:41 +0100 Date: Sun, 10 Dec 2017 13:54:06 +0100 From: "O. Hartmann" To: "O. Hartmann" Cc: Warner Losh , Michael Tuexen , FreeBSD CURRENT Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard Message-ID: <20171210135433.7b36c9f1@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171210111456.15fe1693@thor.intern.walstatt.dynvpn.de> References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de> <20171210111456.15fe1693@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_/eknyGm+sysIwXLPaTjTAlmZ"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:cw4Hv5SqBNcwd5LHZHWNqTO82bDqZElJlv0kHld5udkiqdMAB91 Y54ufPqMfX7iAUCVSOTUSuA1O4OPcgQnIPGG1ZQHURj0pUsj9GqgeznH69tiFJBGpHM2bRj LuDShACmrs7zNwETTJhYz+L/CrOScvkPMkiEHyhn6mRod1+Cg6kXvyNlrCsLVPhI0KmF4xT /3GPbtrMs9OG4tuC6j4gA== X-UI-Out-Filterresults: notjunk:1;V01:K0:40Avsbgc9mI=:2XRi58+3tNx0jDr/NpB8RW FB0AfMti7wBsSfitSWbrnxHaKozxdTlxWOxWBCFowty1jqTV0rQ2JTrUyTbDfm4NUXtE7g7zp 1XXQUdAp1vRUeIaIQ91RWNxauG455l/g1bOkMvps+M8K4ElRgydDhPmiQo5M+QQRELVyeKKA3 yb387MmpMDnjnRA5PtpDTCh22fBWepXpl94n0Z455yteBSoAmTUXL/haaLWYnsBQ0Yo5OgEnR FD9HPr8mY+zOD8Tps7myrS2P2Sl5dBD/v9r3ylDI2PaXW6TTNgiXVPvGY30i0yW7SD+2YkZ3c 8OM1nbDUO1QV8u+tVmdkkrCqzLjzA1kaypw+evYJ/Tcvd72r/794qIVVg7+a3ItbBmG+04TAi TFMwyCforzzYpO/8fjgXGlBQNGBNAu0yIB+2wRdxxjGC2LZzCmwiXLl77BCjqy4EkSJsqaPlR 1HaWsSlDG3GnrCniL1GbfiDaq3/QLKbkVKO1Ved5El2XPwxkZcnWQ9sT+DrthDpKV/l7yKvw7 eljQUGFoA0mbiqchQwI4jVFXTBU9vBQW7dyieZzkXoOF1nq3GO72hTAehlJi6W17CaaTkN/lg K0U19rQk0wr/O/43RbkX2NC8c2nxkegWYHwyLtLByXVqkqEDPpS34DqNchig60YLUVMpKBACe UEimz8cgUUVz0lbxOZLPwIOWWDfq10efLMzpOldOxGktOHEk/y3KEgcyAzwSIFCjZFz3L6CLt k9Moy2F8p3/4I9MRDGGrbUone0cT5rAvZ55mgYwEF2SeOc3mD9x1AyTALFmZSeiSKsLenj7wj ILYiM4nu2xRcpa+bfhIP1zRev0lbw== 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, 10 Dec 2017 12:54:51 -0000 --Sig_/eknyGm+sysIwXLPaTjTAlmZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sun, 10 Dec 2017 11:14:51 +0100 "O. Hartmann" schrieb: > Am Sat, 9 Dec 2017 19:10:03 -0700 > Warner Losh schrieb: >=20 > > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann w= rote: [schnipp] > > =20 > >=20 > > I'm with you on this. I'm just trying to figure out what, exactly, I ne= ed > > to try to setup since this isn't quite my env. =20 >=20 > I have to wait until my box has built r326550 ... I just built r326550, installed the usual way without changes the NanoBSD i= mage and it worked! >=20 > >=20 > > So you don't load GELI since you have it in your kernel. Does this mean > > that gptboot loading from a GELI partition? =20 >=20 > I have a static kernel. Some regulations say, that the kernel is not allo= wede to > dynamically load modules at any time, so I just built GEOM_ELI into the k= ernel - I > wanted to make that clear for the record.=20 >=20 > The rest is simple and vanilla, I guess.=20 >=20 > >=20 > > Warner > >=20 > >=20 > > =20 > > > Kind regards, > > > > > > Oliver > > > =20 > > > > > > > > Since this is very early in /boot/loader's purview, I don't think > > > > kernel/world matter at all (apart from the fact that loader is buil= t as > > > > part of world). > > > > > > > > The PCengines APU with the most recent SeaBIOS isn't capable of boo= ting =20 > > > > > FreeBSD from USB > > > > > 3.0 devices. Even from USB 2.0 flashdrives working images fail at= the =20 > > > boot =20 > > > > > loader with > > > > > "failed with error 19". =20 > > > > > > > > > > > > OK. I assume this is a different issue. :) > > > > > > > > Warner > > > > > > > > =20 > > > > > > > > > > > > > > > > > > =20 > > > > > > > Best regards > > > > > > > Michael =20 > > > > > > > > > > > > > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct = 3 =20 > > > 11:00:53 =20 > > > > > > > CEST 2017 amd64 =20 > > > > > > > > works fine. > > > > > > > > > > > > > > > > What the heck has changed? > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > oh > > > > > > > > > > > > > > > > -- > > > > > > > > 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 =20 > > > Abs. 4 =20 > > > > > > > BDSG). > > > > > > > > > > > > > > _______________________________________________ > > > > > > > freebsd-current@freebsd.org mailing list > > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe= @ =20 > > > > > freebsd.org" =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@ = =20 > > > > > 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 Abs. 4 =20 > > > BDSG). =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 2= 8 Abs. 4 BDSG). > > > =20 >=20 >=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_/eknyGm+sysIwXLPaTjTAlmZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWi0uigAKCRDS528fyFhY lDkQAf4/hVeJxdnvfdK0UmPn9K4tM5Tcq1nP8W5BJsT+erYCWW5jsLDcbBjYDLAI 9jaPkk7YWQAnW1kpOaMDerXW0SfwAf9H2Rh0iEYkYisOvK04wgA7ePamObfRZ3pn 8zo1r5Snv4cgmkOnMzsQA1VUAAMBfWlLresMZed4XeYAo45T7WdJ =UOZo -----END PGP SIGNATURE----- --Sig_/eknyGm+sysIwXLPaTjTAlmZ-- From owner-freebsd-current@freebsd.org Sun Dec 10 13:34: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 07333E8CC9D; Sun, 10 Dec 2017 13:34:23 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 C876771603; Sun, 10 Dec 2017 13:34:22 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vBADYLIM079285; Sun, 10 Dec 2017 13:34:21 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vBADYLgI079284; Sun, 10 Dec 2017 13:34:21 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712101334.vBADYLgI079284@donotpassgo.dyslexicfish.net> Date: Sun, 10 Dec 2017 13:34:21 +0000 Organization: Dyslexic Fish To: gurenchan@gmail.com, freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: Makefile show all flags References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 10 Dec 2017 13:34:22 +0000 (GMT) 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, 10 Dec 2017 13:34:23 -0000 blubee blubeeme wrote: > When porting software FreeBSD has a lot of internal makefiles that gets > pulled in that setup the build environment: /usr/ports/Mk/* > > Is there a way to print out the env during the make process so that I can > see what knobs, switches and flags were set before the build is run? Is this any use? make -dA .... It's pretty verbose. I'd suggest running it through "script" or redirecting stderr to a file! cheers, jamie From owner-freebsd-current@freebsd.org Sun Dec 10 16:44: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 E5E9AE90579; Sun, 10 Dec 2017 16:44:42 +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 A9730768CA; Sun, 10 Dec 2017 16:44:42 +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 1B9AD29A2; Sun, 10 Dec 2017 17:44:34 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1F6BB22A-1372-43C0-A58C-E065490740ED"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] Document powl and tgammal kludges Date: Sun, 10 Dec 2017 17:44:33 +0100 In-Reply-To: <20171209010205.GA42226@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org To: sgk@troutmask.apl.washington.edu References: <20171209010205.GA42226@troutmask.apl.washington.edu> 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, 10 Dec 2017 16:44:43 -0000 --Apple-Mail=_1F6BB22A-1372-43C0-A58C-E065490740ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Dec 2017, at 02:02, Steve Kargl = wrote: >=20 > The following patch documents the remaining kludges that > theraven@ committed in r255294 on 2013-09-06. I have > cleaned up all of the others, but powl and tgammal remain. > ngie@ seems to have documented the existence of powl with > r290605, but did not document the rather poor numerical > accuracy of the result. tgammal remains undocumented. As it > is unlikely that theraven@ will document the nature of his > kludge nor the existence of tgammal, I have have prepared > a patch that documents the expected numerical accuracy in BUGS > sections, and have also documented tgammal. Thanks, committed in r326748. -Dimitry --Apple-Mail=_1F6BB22A-1372-43C0-A58C-E065490740ED 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWi1kcQAKCRCwXqMKLiCW oxQ6AKCPnLnE5VzWlJMkdnUoh0OPDvq/sgCgqm4/QkV28BFCKdQOaGEN/at51hA= =du+c -----END PGP SIGNATURE----- --Apple-Mail=_1F6BB22A-1372-43C0-A58C-E065490740ED-- From owner-freebsd-current@freebsd.org Sun Dec 10 17:12: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 20D60E91393; Sun, 10 Dec 2017 17:12:29 +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 022FB77A7C; Sun, 10 Dec 2017 17:12:28 +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 vBAHCSx0048766 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Dec 2017 09:12:28 -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 vBAHCSDE048765; Sun, 10 Dec 2017 09:12:28 -0800 (PST) (envelope-from sgk) Date: Sun, 10 Dec 2017 09:12:28 -0800 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [PATCH] Document powl and tgammal kludges Message-ID: <20171210171228.GB48536@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20171209010205.GA42226@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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, 10 Dec 2017 17:12:29 -0000 On Sun, Dec 10, 2017 at 05:44:33PM +0100, Dimitry Andric wrote: > On 9 Dec 2017, at 02:02, Steve Kargl wrote: > > > > The following patch documents the remaining kludges that > > theraven@ committed in r255294 on 2013-09-06. I have > > cleaned up all of the others, but powl and tgammal remain. > > ngie@ seems to have documented the existence of powl with > > r290605, but did not document the rather poor numerical > > accuracy of the result. tgammal remains undocumented. As it > > is unlikely that theraven@ will document the nature of his > > kludge nor the existence of tgammal, I have have prepared > > a patch that documents the expected numerical accuracy in BUGS > > sections, and have also documented tgammal. > > Thanks, committed in r326748. > Thanks for the quick commit. -- Steve From owner-freebsd-current@freebsd.org Sun Dec 10 19:43: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 3F0E1E98A84 for ; Sun, 10 Dec 2017 19:43:03 +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 B9C527F13A; Sun, 10 Dec 2017 19:43:02 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.226.211.39]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMYZG-1ePlvw1QFS-008KGp; Sun, 10 Dec 2017 20:42:58 +0100 Date: Sun, 10 Dec 2017 20:42:21 +0100 From: "O. Hartmann" To: "O. Hartmann" Cc: Warner Losh , Michael Tuexen , FreeBSD CURRENT Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard Message-ID: <20171210204248.7295296d@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171210135433.7b36c9f1@thor.intern.walstatt.dynvpn.de> References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de> <20171210111456.15fe1693@thor.intern.walstatt.dynvpn.de> <20171210135433.7b36c9f1@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_/FWjOLcItFuD1frviV8+jKyG"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:mnSYVHrDlac3b5T8QbigQkJAU+H72wMbyPIuXOqGU2DLwfO6UhK 6HBQzNBsAAS0f2rcauv/btT2XW2FGAWKKsyZmiTxv/WGWnZWQUiaMxhvLAnOiNm6XLnPL4q 3A1b1WYnAOX/Ubpt9upBJqCdEi0IgT2JYMsTfywm2pghW61kVuk+H8Qr8QE5BggR6jnmZwQ P5ulM2H1WbLEdC0HlkP+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:NK3Pf+SDkQU=:ZFv7u6nQ/wl/EEcfARvD9k VEuIJkw2i32+7aKZ7K/WvE4EgGcEC82PYmzSIyrWaUEHs6JR1Wg+5uz5y/E7AqawFTuMu8KnG gA9T7tl+sSEFtafKvsAGkA9xU1iXNyXrDnnvOXitT5f+9hDxlYX8xeE2jujk8bSjiFw5cK6w6 F+9PWWETHvf8ESmhOMAbeDxGVZSc1y3+8dRrHlUpaKpBoAeDCr9+NVQM0uTD/v9GvIl5vtai4 f3nUiQeVXEdQ88ZEqPXALgb/sW7KlGLUCAe8VxY7OhF4jHn4q5v187wnc3P9aR7ubAiluDsaT BQL79H8UOYYY5qpiqfVH6Xwb96pHNoL6s2fVAazENLgtZr2I6ZRnHThuRzN8It4KeOHXFsy+2 q0vjak0XCEr9gUl5fuQQZ+ZgX7XpbcJaIrDMgChoqx3IBL5eN3vOU8a7Z8q9aLDmNCnnGCtSw f6iliEz77WmKSaUnCEZLkykelxLaPyOKQ+E/peXi9qfBDWfchHJie8lsXharUZQ8bGzlAPsnr Zw2Nmb3BykgWnVkaMVXteO72lh1FMxliEtgtsQevauuKfXKlF1o+IPoxqdHqB4p39WIWC0QM7 NJ8ifcK3lVoAzzaPhH07LFeQxpjX5afCQ960XxXsWb/fHO7MoprCUyZgHAbgg75VA3MthPPuk L4vvOGks0H06/JF87cn4FPYGO7tnu9LfHR5NNJrCx2abkxwgLdlXiX7xh6Ds21JHY5HC3M3eU LP69/qFjVbVjZs3eFwRACyq7wO/C7wzx+rBVRLQB/ha+pvFpaQQBD2LKHjBx/LmKhskHBV+uC GHbqJUWseK1BYpan/C0ftyd34v+nQ== 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, 10 Dec 2017 19:43:03 -0000 --Sig_/FWjOLcItFuD1frviV8+jKyG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sun, 10 Dec 2017 13:54:06 +0100 "O. Hartmann" schrieb: > Am Sun, 10 Dec 2017 11:14:51 +0100 > "O. Hartmann" schrieb: >=20 > > Am Sat, 9 Dec 2017 19:10:03 -0700 > > Warner Losh schrieb: > > =20 > > > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann = wrote: =20 >=20 > [schnipp] >=20 > > > =20 > > >=20 > > > I'm with you on this. I'm just trying to figure out what, exactly, I = need > > > to try to setup since this isn't quite my env. =20 > >=20 > > I have to wait until my box has built r326550 ... =20 >=20 > I just built r326550, installed the usual way without changes the NanoBSD= image and it > worked! >=20 [...] r326583 works, too, r32684 has a compilation failure due to sys/geom/eli/g_= eli_hmac.c --=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_/FWjOLcItFuD1frviV8+jKyG Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWi2OOAAKCRDS528fyFhY lF+vAf9JICIN+gtZaEeYl3tb08bqMF4Mt8emFyiT1J4V8CwMIA6BV7Qlpjg0iMeB rF+m9D1rSHPN89yHI9k9Ml9bEPWhAf9qSUN3TNqvYbjVNqJzJ7Wp1i8V8ce3MUSM kcy4fyWkh1fv5mZr0q9WFr1qIfpM5dj0juT1iBnDA+A3La8/1bqa =3Dvf -----END PGP SIGNATURE----- --Sig_/FWjOLcItFuD1frviV8+jKyG-- From owner-freebsd-current@freebsd.org Mon Dec 11 09:35:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DE4FE8BA16 for ; Mon, 11 Dec 2017 09:35:05 +0000 (UTC) (envelope-from stefan.wendler@tngtech.com) Received: from proxy.tng.vnc.biz (zimbra-vnc.tngtech.com [83.144.240.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5048B79875 for ; Mon, 11 Dec 2017 09:35:03 +0000 (UTC) (envelope-from stefan.wendler@tngtech.com) Received: from proxy.tng.vnc.biz (localhost [127.0.0.1]) by proxy.tng.vnc.biz (Postfix) with ESMTPS id 4D4041E2112 for ; Mon, 11 Dec 2017 10:26:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by proxy.tng.vnc.biz (Postfix) with ESMTP id 337811E210A for ; Mon, 11 Dec 2017 10:26:58 +0100 (CET) Received: from proxy.tng.vnc.biz ([127.0.0.1]) by localhost (proxy.tng.vnc.biz [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mc-Gwn50MxyU for ; Mon, 11 Dec 2017 10:26:58 +0100 (CET) Received: from [10.1.2.115] (fire.tngtech.com [212.204.93.100]) by proxy.tng.vnc.biz (Postfix) with ESMTPSA id 0DD711E19A8 for ; Mon, 11 Dec 2017 10:26:58 +0100 (CET) To: freebsd-current From: Stefan Wendler Subject: NFSv4.2 Message-ID: <880022c0-75f5-161b-1ca3-1d934ba598e9@tngtech.com> Date: Mon, 11 Dec 2017 10:27:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Mon, 11 Dec 2017 09:35:05 -0000 Hi, I was wondering when and if FreeBSD will support NFSv4.2 Is there anything planned yet? Thx and Cheers, Stefan From owner-freebsd-current@freebsd.org Mon Dec 11 12:15: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 35A48E904FB for ; Mon, 11 Dec 2017 12:15:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0088.outbound.protection.outlook.com [104.47.42.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB45435FB for ; Mon, 11 Dec 2017 12:15:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 11 Dec 2017 12:15:19 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0302.013; Mon, 11 Dec 2017 12:15:19 +0000 From: Rick Macklem To: Stefan Wendler , freebsd-current Subject: Re: NFSv4.2 Thread-Topic: NFSv4.2 Thread-Index: AQHTcmNW1+T+k60C3EqOZfJE2BqD/aM+DP81 Date: Mon, 11 Dec 2017 12:15:19 +0000 Message-ID: References: <880022c0-75f5-161b-1ca3-1d934ba598e9@tngtech.com> In-Reply-To: <880022c0-75f5-161b-1ca3-1d934ba598e9@tngtech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2172; 6:ZpwXY+Q9M+9eemD7yC3mWodEnApFVkW5Tabz26MCCdOqbr9IDdRSWRMhAH+ahHt0FJkp0IgIMRwfjRlanyi3bS8zQcpLizLtqabnvyCY2nFdlFKF93qIyEa0K4w+u/oljdWd3EM6nAwfRLBuUO5Vk2r9clTa5tPIYFBZGs249DQB1tAE0NyRdwvglU252YvlJ06MfHLnUYk51K9BBuEMkIix6cJuLmHoUhYmeeK8cnjyPJfl3362KAYQ2LMvjvq673VsDwzZFWp3Sb1H18Ly0I2ezil3hgl2/ZE5hJsP2Tj6NE0s+HwiLfTVYdwZPRAWTpuLjCGjCpHz0aIyrlC06dx6gAVsoohY/d5uxLzH0rc=; 5:PCaGzHV3RkTGwbe64GAmzp+wK10VJSxTXoE4rKMcnVCkzNEobkejivEODbdeO07O4pQHNRBqdAKMAnBVBuepy9+3k6V7013YZ9WWs29sWnV5fEGjV9DsHbmS4NyqUhFt0W29dNlBdXq2ccQpi2riJh9pgrdjDM/TqE1EK4tc/lc=; 24:s//DRbVlrvySajaCSGG76UcXmHb+oH922sq8FTWXr8m1JUiBNp6kC2e8uk056OO0l1oLVPR9JhcQlpAKjFVeTNiyC6ypRqsF5TPPx9EZQR0=; 7:P4n0u5Sz2vPYo+/xdjJpmMvxZ7lBklPiNNqoOixuShKUWRAUSAYz863yDElvi3ejHDRYnMgck9kAzcZIgow2Fj812NcsSEIIJkfxNiQvC+vobbcxmhal431sm4v1zvE1HHIOxLAbP+Lu6svXmqr25jzrCw8H0FgXCbyUfPbawqEQhlOLExUPxQ8Ey/f4WlhsOyx5+JPUuf9fKNyEp02gQLKxAmYEExNNaAJUMLSpoc0oyTKCHvkhPCZmXvdfT/Lp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c46b7772-0fc2-4f89-eb8e-08d54090d87a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603307); SRVR:YTOPR0101MB2172; x-ms-traffictypediagnostic: YTOPR0101MB2172: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:YTOPR0101MB2172; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2172; x-forefront-prvs: 0518EEFB48 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(24454002)(189003)(199004)(106356001)(8676002)(5660300001)(2950100002)(2906002)(110136005)(68736007)(786003)(53936002)(76176011)(86362001)(102836003)(316002)(8936002)(9686003)(7696005)(55016002)(25786009)(99286004)(2900100001)(97736004)(305945005)(6436002)(478600001)(6506006)(6246003)(74316002)(14454004)(229853002)(3660700001)(81156014)(74482002)(81166006)(3280700002)(5250100002)(33656002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2172; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: c46b7772-0fc2-4f89-eb8e-08d54090d87a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2017 12:15:19.3102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2172 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, 11 Dec 2017 12:15:23 -0000 Stefan Wendler wrote: > I was wondering when and if FreeBSD will support NFSv4.2 > Is there anything planned yet? Someday, but no specific plans at this point. Is there some specific feature in NFSv4.2 that you are looking for? I ask because there isn't a lot of new features in NFSv4.2 that aren't in NFSv4.1. As such, I didn't see much reason to worry about it. (I think there are some high end server features like server->server file copy, which would only be worth having in the client if you had high end NFS servers that supported this stuff.) NFSv4.1 was a big change from NFSv4.0, but most of the NFSv4.1->NFSv4.2 changes are minor. One of the biggest is a way to incrementally add feature= s without creating a new (NFSv4.3 or ??) version of the protocol. Probably a good idea, but only useful when incremental features are being implemented. rick From owner-freebsd-current@freebsd.org Mon Dec 11 12:37: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 CA21DE90B3B for ; Mon, 11 Dec 2017 12:37:13 +0000 (UTC) (envelope-from stefan.wendler@tngtech.com) Received: from proxy.tng.vnc.biz (zimbra-vnc.tngtech.com [83.144.240.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88A6563429 for ; Mon, 11 Dec 2017 12:37:12 +0000 (UTC) (envelope-from stefan.wendler@tngtech.com) Received: from proxy.tng.vnc.biz (localhost [127.0.0.1]) by proxy.tng.vnc.biz (Postfix) with ESMTPS id 12FAF1E2118; Mon, 11 Dec 2017 13:37:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by proxy.tng.vnc.biz (Postfix) with ESMTP id EA34C1E21CD; Mon, 11 Dec 2017 13:37:04 +0100 (CET) Received: from proxy.tng.vnc.biz ([127.0.0.1]) by localhost (proxy.tng.vnc.biz [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G3g1j5Qel3PG; Mon, 11 Dec 2017 13:37:04 +0100 (CET) Received: from [10.1.2.115] (fire.tngtech.com [212.204.93.100]) by proxy.tng.vnc.biz (Postfix) with ESMTPSA id C2B031E2118; Mon, 11 Dec 2017 13:37:04 +0100 (CET) Subject: Re: NFSv4.2 To: Rick Macklem , freebsd-current References: <880022c0-75f5-161b-1ca3-1d934ba598e9@tngtech.com> From: Stefan Wendler Message-ID: Date: Mon, 11 Dec 2017 13:37:09 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: Mon, 11 Dec 2017 12:37:13 -0000 On 12/11/2017 13:15, Rick Macklem wrote: > Stefan Wendler wrote: >> I was wondering when and if FreeBSD will support NFSv4.2 >> Is there anything planned yet? > Someday, but no specific plans at this point. >=20 > Is there some specific feature in NFSv4.2 that you are looking for? > I ask because there isn't a lot of new features in NFSv4.2 that aren't > in NFSv4.1. As such, I didn't see much reason to worry about it. > (I think there are some high end server features like server->server > file copy, which would only be worth having in the client if you had > high end NFS servers that supported this stuff.) >=20 > NFSv4.1 was a big change from NFSv4.0, but most of the NFSv4.1->NFSv4.2 > changes are minor. One of the biggest is a way to incrementally add fea= tures > without creating a new (NFSv4.3 or ??) version of the protocol. Probabl= y a > good idea, but only useful when incremental features are being implemen= ted. >=20 We would like to use the file copy and the sparse features of 4.2 in our Setup. Do you know if any of the two has been implemented yet? The sparse feature would be more important than the file copy feature though. Cheers, Stefan From owner-freebsd-current@freebsd.org Mon Dec 11 22:03: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 58E5AEA026D for ; Mon, 11 Dec 2017 22:03:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 D3F917B9AF for ; Mon, 11 Dec 2017 22:03:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id c140so14093512lfg.7 for ; Mon, 11 Dec 2017 14:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=ZOKdaJU+2PHZg6mDg1W/AAq4H3j1ounju2OhBUJKI4Y=; b=VawMt80M6jj7+PfxEiJfzuJnUx3RZ0u2B8W7aGmjPSc+PIygzqH4a5AzHFJSQnKKeh iMoEr1PonxR8exG81OPwWVou3OP1N1Tk+N++JVOXWIgkoPsA/+UubP7KMMcBHoXqYmc0 TaZGWG8zI2xWGMYojm0doSkT1LVthJTFN3Stl/pu4CG5pd4xk+QX4V8cpoSZL5jj2ITr fYnUWejYDDPn4mLQCn7PBmuQeSgeq2/13wfGb3Hh+ztX/6NNXD7O5hSa0TI1GBKkiSh5 2HFzGMDWGKNUVRjg3HpmZUSuzi+dayeAHPeTPxv/QeUt1Yi7JOe0j5W7bjR1SGDLSqfH 8+aA== 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:from:date:message-id:subject :to; bh=ZOKdaJU+2PHZg6mDg1W/AAq4H3j1ounju2OhBUJKI4Y=; b=oQ0L9iojVuDJ/Nd5seplDEpa3nEQ+Cvv0K/bHsW2g1TurivWilzPKuuMk4QMNpx1an njrGCNJE3NWtkFHwp8uNlwFhhQhX6ubE4ucmIvE7DlJDqk4dw76CjNvkVwof1f7XyU+9 ese1Z6sbngM1gLNdqGLny65WSxoaz5E2NtlybLNdhdn5If6XFrMzbT7u5z9congYRCMs iJvlSKmssn7qPvEclBrFeC8P+msYhH5m/VhY0bWZI34Mxc86LYONRt6M+/lwqngtY3iy pbP4CsyX6+zAtq8YBCF1+bRTfMk6xF8TqPz26QGON9s9ZyokkpVURe1ilrF0wSmCxVnU JHQg== X-Gm-Message-State: AKGB3mI8V32/GdYb2c8J/p34CGyt8zGIRXUwyj5M3pfyG1cibGhV7+kA 7jbu0zAmk+5DkYc0MT/y8tdfOUHNFGH8wETEQao7dw== X-Google-Smtp-Source: ACJfBou9DoS5/mWk4wKi0GfQVLslzYq/a6yUwIKCI+0lfwfh6mV0hyQ+mAAJNTIq33tsygfO8nAyEomsrznrMneTwso= X-Received: by 10.25.121.10 with SMTP id u10mr752883lfc.50.1513029825514; Mon, 11 Dec 2017 14:03:45 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Mon, 11 Dec 2017 14:03:44 -0800 (PST) From: Alan Somers Date: Mon, 11 Dec 2017 15:03:44 -0700 X-Google-Sender-Auth: Lh0Pq8u8skSxvS86GKG0i09U_bU Message-ID: Subject: don't know how to load module '/boot/loader' 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: Mon, 11 Dec 2017 22:03:49 -0000 I just upgraded my head machine to r326772. Now, boot2 can't find the loader. Instead, it tries to boot the kernel directly, which fails because the ZFS module isn't loaded. If I break into boot2 and type "boot /boot/loader" I get the error "don't know how to load module '/boot/loader'". I last updated on 30-Nov, so this bug must've been introduced since then. Any ideas? BTW, I can successfully boot with the following commands: unload load /boot/kernel/kernel load zfs boot http://bayimg.com/iAKmFaAgl -Alan From owner-freebsd-current@freebsd.org Mon Dec 11 22:19:54 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D9D4EA0908 for ; Mon, 11 Dec 2017 22:19:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E50537C21F for ; Mon, 11 Dec 2017 22:19:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id u62so19760347ita.2 for ; Mon, 11 Dec 2017 14:19:53 -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=axktQCbDtOXgSWfh2A3F4AFK8Kt8qvdvQ+sIBkwhJYo=; b=qzqYQxiG6X07fAeJuWVXP60y/QcAYq8ykZpoEkabQDnYzPfAepOueJwL4Btvfit7NT NdxWLYx+epkKB6AfQYGlYCaQlC9GP1FRDXkmZ+AKXTGbV5jlwcFvmZltRKXLprwpGMmG 6Ry8vkkz7zbIMqiQSzTeIZ///C9MCmxIdCwklqoEM7rOeLGnZQrxZHUc/uxZcKFmEGdm n4ZqJUNu1i2Wb5VMOjlEdpEuKA0PPrgEKX1EymnPcl2vuW7JYROLEzMLDn68qbHVdlfw wU7yf8FRMjr2GmbffjMhWCy0CuKdtsHvrnY2ltVHrDef9Uav4HMijcJ+jl/c3oHqU5Iw Eb8Q== 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=axktQCbDtOXgSWfh2A3F4AFK8Kt8qvdvQ+sIBkwhJYo=; b=tPiNU88YO0T8qawwjqQmvifQortpWXb5UnU/2pMk7heO6BaiiDUmoMt8oOT3UP/puO ZiUL5PfoeeFUk3tY5yweUJbhMK3ZPAjsuevpFpOc2YhDG6nIULQ2cRVcaNilsIvLlWi6 eXSn91UKdaZaJ92L6PGFAHAHRFXoF8+34tIYFSk/te99fbVgTIb6MqyuJTXIjv08s841 0XwOKKGV7CatAv+6TsNh92s5Mq73mR4aCPNp4BvFOr0Tbc+P6W+tjPOVLPcXzEqlxnFR fNkENHaHjliwfOg645POgG6SpErUTGV0vv1mhkS9pcJvGUL50xFaG2zFk4oc2YupVyNy sU4g== X-Gm-Message-State: AKGB3mIhTS1Z85IjpmQEsN3ogg260n7NwEma39yajiOC1P+ixbf6iD4D NvAxjQCfbN4cLcHp/YvnnJuzpjHcbq8tI0SF2FrwHs1W X-Google-Smtp-Source: ACJfBou0b1zXMtdVzBuDKlbWtMgo/2mBdkwAa2XHxdFWZaG1n61tT9uO5Ac1JLYA/wP5g9dNStc0l//1SqbC+9HGoVA= X-Received: by 10.36.164.13 with SMTP id z13mr3275163ite.115.1513030793076; Mon, 11 Dec 2017 14:19:53 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 14:19:52 -0800 (PST) X-Originating-IP: [75.104.71.74] In-Reply-To: References: From: Warner Losh Date: Mon, 11 Dec 2017 15:19:52 -0700 X-Google-Sender-Auth: G-OOXc5M5PTtHDWQ4OgztwmOqFA Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Alan Somers Cc: 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: Mon, 11 Dec 2017 22:19:54 -0000 On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers wrote: > I just upgraded my head machine to r326772. Now, boot2 can't find the > loader. Instead, it tries to boot the kernel directly, which fails because > the ZFS module isn't loaded. If I break into boot2 and type "boot > /boot/loader" I get the error "don't know how to load module > '/boot/loader'". I last updated on 30-Nov, so this bug must've been > introduced since then. Any ideas? > > BTW, I can successfully boot with the following commands: > unload > load /boot/kernel/kernel > load zfs > boot > > http://bayimg.com/iAKmFaAgl I'd bisect :) However, try to update to just before this commit: Author: imp Date: Fri Dec 8 19:57:16 2017 +0000 Create interp class. Create an interp class. Use it to separate out the different types of interpreters: forth and simple with function pointers rather than via #ifdefs. Obtained from: lua boot loader project (via https://bsdimp@github.com/bsdimp/freebsd.git lua-bootloader) Sponsored by: Netflix git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f would be a good place to start. It's a shame we can't create zpool images with an unpriv'd user command. Would help out the ZFS testing of the boot loader refinement. Warner From owner-freebsd-current@freebsd.org Mon Dec 11 22:25: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 999EEEA0E00 for ; Mon, 11 Dec 2017 22:25:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0043.outbound.protection.outlook.com [104.47.40.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 326E57C854 for ; Mon, 11 Dec 2017 22:25:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM (52.132.46.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 11 Dec 2017 22:25:46 +0000 Received: from YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8]) by YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM ([fe80::f072:85d3:769:e6f8%13]) with mapi id 15.20.0302.014; Mon, 11 Dec 2017 22:25:46 +0000 From: Rick Macklem To: Stefan Wendler , freebsd-current Subject: Re: NFSv4.2 Thread-Topic: NFSv4.2 Thread-Index: AQHTcmNW1+T+k60C3EqOZfJE2BqD/aM+DP81gAAHv4CAAKOA2g== Date: Mon, 11 Dec 2017 22:25:46 +0000 Message-ID: References: <880022c0-75f5-161b-1ca3-1d934ba598e9@tngtech.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB2172; 6:n/OtST/XnljNkhpj2KM2/vjEXk/jQCb2p10tlxPw5+gcVq8feu9MTTAfpLjymBJE4nWMdMud6cWTjMF5h2UVCUE+Yzl9k3L1GD7nF0AQpkiS0XYrHfqgFjGSG4kgndRYHEHcS7Q8bZM1cleDuww/XJbR2EhUIb6I95XuQe54Ywk9pzIKUeYh0MnksXeZiqdUb3fdwyJ8bVTdNLe/wkpbKjlOMkWQpG2M7wgL2geEuMwnNuJwEyvAEEhL8Itq4Fzqrk91lvVl0jJfjMjOb+ouORy9RleFQCvwAECc+9BepXq4pl/YlSzTVnL8gJqjc1vJdptUBv4aZh4y1NZVFUa+S1kKMhAauZG7ibeZdZjQQLc=; 5:zSGwRpVKiYIGw4OWMzS7YsWUJHFYC3WOIKRVCNb/CuhiQGP3s+6ILevaN9w8n/GYhRaKPxmeSOOk3xp/H6jvvadIM/ripZO5xc10Agcyp8Q7h/JIcYRWqOzAn7fa+lR5A1lt+kTmeU5eqaydFikTitTUmKuTgGd/tggRKuO6qAM=; 24:YqemAicctTl27nOzQE5N2G8qoKR+Yr2ZnLzKfsQozoCOT/XYjuBw1/iPBbUBXPwUgjPRyVV2uL0lNq9FoYIMGWu80GzJXUHcESXbKIKOSIE=; 7:kIr5AgMynLZOEr66JYBq7KbY0imyCJffCnEgqCthEtfxbsBYAn2fr20aaU3j7UTOgsAry53ubaJa7VDOGfCv9YCVaadqaV6h/PeluaxmHVnbDMkt5+VChALFMfNtaG6lLct4qa63h+EliJJbm/O9KMw5DKjurq9ETx7zSiVhyEpEf8aBWDXQE/2M15W3tHGruutEzhuILfuMKeAOx6e2FiLSrcMHYDIj69/N301WvIlwvf97qtaoCMoQatdMposM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a2e5bd80-4d53-4a8e-d2e4-08d540e61fd7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603307); SRVR:YTOPR0101MB2172; x-ms-traffictypediagnostic: YTOPR0101MB2172: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:YTOPR0101MB2172; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:YTOPR0101MB2172; x-forefront-prvs: 0518EEFB48 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(24454002)(199004)(189003)(74482002)(74316002)(106356001)(305945005)(8676002)(81156014)(81166006)(5250100002)(478600001)(25786009)(55016002)(105586002)(14454004)(6246003)(53936002)(33656002)(8936002)(9686003)(68736007)(99286004)(2900100001)(110136005)(786003)(316002)(5660300001)(59450400001)(76176011)(97736004)(7696005)(2950100002)(3660700001)(6506006)(229853002)(6436002)(86362001)(3280700002)(2906002)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB2172; H:YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: a2e5bd80-4d53-4a8e-d2e4-08d540e61fd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2017 22:25:46.3061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2172 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, 11 Dec 2017 22:25:48 -0000 Stefan Wendler wrote: > We would like to use the file copy and the sparse features of 4.2 in our > Setup. Do you know if any of the two has been implemented yet? The > sparse feature would be more important than the file copy feature though. No idea (except that NFSv4.2 isn't in FreeBSD which implies "not in FreeBSD= "). rick= From owner-freebsd-current@freebsd.org Mon Dec 11 22:26: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 91957EA0F61 for ; Mon, 11 Dec 2017 22:26:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 126397C9D0 for ; Mon, 11 Dec 2017 22:26:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id 74so21026630lfs.0 for ; Mon, 11 Dec 2017 14:26:22 -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=+d549exlJb2cHkOXn9bZSRjz0ZZ6JvO68w8V+73CsvM=; b=HRkXgtK29fj4t8y8dfSXvIdlaaWjQkWCSmKsUGUxo2xpMy8RkQIEui++O2OC1da/y6 6Sjm4YHrReeAHdkk9/SbytOGh+YyOg44P8QyT3B9jx6mAnxuArRfCHeh+LwSDkmVUmAJ Gg+nmbBivkwt+1NIEb7vOWLSuErL/JB2dsg6JrOzgfQtFu6D/FHTFJVFMx1GOwQnHWd/ WsGgIO5D2O5WJ6q/uEVv91FNPX90E3mqUCpZzkOS69q+qx8hs1GhuYDFflsKRariiyvq eUVCFYRx2CMr/owHjkiOSFpSCA61JEcImYfj1UZ3CqK1uFPvh2FQPtzmWSFirvJNOifr b/3w== 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=+d549exlJb2cHkOXn9bZSRjz0ZZ6JvO68w8V+73CsvM=; b=izr+mPfhQA0MWs+iD2L0N450DAyW/wohYRnC41Tvcl+irmv8snLa5EHsky55lKet5J NdGqDr2OqGwOZlQ9oRKH3EoD5+ycQJpAGOembMmVrJ6AQfWVtmadj4dqtxxZIz9oZg/l XevT9f2h++69hqWRY9c/8QNtpeFOqzbPlTtX+i1dtHBm4obMtElsPXGwAFNuG/ZQYvZ7 Brk0Ifv2gHUEHPYjy5kTdumVOuV3W1juxd1KOH982oRT1YEhyTHEzfouS7TwJqNBZWvv 7IeTUJvO3O4CRdsoBxAJQRCag4SVcg/YmpzJFGucOl5CzEdX8O6ruDcRHSSSG4nOOJQU QDCg== X-Gm-Message-State: AKGB3mKOzR4x6BubrOprBUVWDkdPq42e4X9ih4lY8gW+Mr9QXBEm+DM+ AuvOQYHpo6txLyVG0/GQSUD7ipEg/EX1fCNZwAo= X-Google-Smtp-Source: ACJfBos44/CaX2mTOYhb5Ie+k4lYSMYFwrDI2erJ+uq9TkmxGk97lEywas83zv06QeFaiyPACf8aakrQDKTqxc9sxJc= X-Received: by 10.46.48.5 with SMTP id w5mr840529ljw.99.1513031180977; Mon, 11 Dec 2017 14:26:20 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Mon, 11 Dec 2017 14:26:20 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Mon, 11 Dec 2017 15:26:20 -0700 X-Google-Sender-Auth: 3cEPqKQhTzS8-3DO18loKJ4bJhc Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Warner Losh Cc: 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: Mon, 11 Dec 2017 22:26:23 -0000 On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: > > > On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers wrote: > >> I just upgraded my head machine to r326772. Now, boot2 can't find the >> loader. Instead, it tries to boot the kernel directly, which fails >> because >> the ZFS module isn't loaded. If I break into boot2 and type "boot >> /boot/loader" I get the error "don't know how to load module >> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >> introduced since then. Any ideas? >> >> BTW, I can successfully boot with the following commands: >> unload >> load /boot/kernel/kernel >> load zfs >> boot >> >> http://bayimg.com/iAKmFaAgl > > > I'd bisect :) > > However, try to update to just before this commit: > > Author: imp > Date: Fri Dec 8 19:57:16 2017 +0000 > > Create interp class. > > Create an interp class. Use it to separate out the different types of > interpreters: forth and simple with function pointers rather than > via #ifdefs. > > Obtained from: lua boot loader project > (via https://bsdimp@github.com/bsdimp/freebsd.git lua-bootloader) > Sponsored by: Netflix > > > git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 > ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > would be a good place to start. > > It's a shame we can't create zpool images with an unpriv'd user command. > Would help out the ZFS testing of the boot loader refinement. > > Warner > If I bisect this, what parts do I need to reinstall each time? A full buildworld would be too slow. Is it sufficient to reinstall stand? -Alan From owner-freebsd-current@freebsd.org Mon Dec 11 22:30: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 06379EA11BA for ; Mon, 11 Dec 2017 22:30:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 BE98B7CC13 for ; Mon, 11 Dec 2017 22:30:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id b5so19794730itc.3 for ; Mon, 11 Dec 2017 14:30:14 -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=IFAeoXRX4GfGl12suF3pexSHx2V5jBNg+pZe5Y+B14o=; b=xsbAtjQNrpgkQgoGTvlK8Q7nQQAHmDWg7M/E1LH97CNAhfrUiQO4SBjTUoFM0MANmJ wVA8bE16CyB/xee1anKSsv+DLXLdHLe4XRrb7Ck1iGDwtf9vsnewoCpoU1c5G2lznZXx 6g7QJC15r+ZVt7ltgRNG4A88wQwfkextNOgnqC2AkB0noCb6XlzLHhSRRdPTrafH9fSM RKV3hq/Vpzy5DjFDHAhHLltReKXznz6iRsY1JV7eI6qw8H2rMog8voWJIhxIHDiM5zLl bQHAojSIHrMEqThzLdXc2RIuOABo53dp7kV2tV0WiDWNegHT675PR+i+H64GIk8yM0eK T9dQ== 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=IFAeoXRX4GfGl12suF3pexSHx2V5jBNg+pZe5Y+B14o=; b=VESVsho8c9HknGGmNRGRl4wrhC8yf7CWPOg7G0BVMnKN7SHQjwsXl3xZiFSQ7rpiws 1u6umW6SpnbyThSvai4xubRN/QVUfQYCQBdTQ+L6plq6IkDR7vDUgsoRTi1WNXkFIdes AYFwU1X7NguolEgzmAvCEKC/QyhwFjNtgMy8FNoTkU4FVAHB9NJjpXuhNwt/OiG49nQs yj8VsFP/CQ8RiV0gXiVrQoVxgYXsblWh+dhnoYjpdJ7JpHAtub2RYaq5m7oHQNMDyIvT IjtWoFSDPQBby7meNTdlADwOaRPjV6OqeLWis1x9fUo+PZXqdvxjFhPw+zD+pIR9J2Pi WVeA== X-Gm-Message-State: AKGB3mKU+5O89BGg2f2xliRky83yREln3giPps+KDfOdK7BUaV+yBl45 QwtZKd3pDwJsJfuEzuSXCtYaW7YI4nO/amesVj1A9w== X-Google-Smtp-Source: ACJfBosJp3PpyrD8d5KlAZOP6GVv9OSY0LFA6dyx70QIUW4b5av+dQ3dDmLcDZrnNJnNFAGGY+53GdeZIvGG8KxZ2Z8= X-Received: by 10.36.131.200 with SMTP id d191mr3252261ite.97.1513031413903; Mon, 11 Dec 2017 14:30:13 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 14:30:13 -0800 (PST) X-Originating-IP: [75.104.71.74] In-Reply-To: References: From: Warner Losh Date: Mon, 11 Dec 2017 15:30:13 -0700 X-Google-Sender-Auth: wRXiaDeVfNFZ1sKiMpb60ecXuE4 Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Alan Somers Cc: 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: Mon, 11 Dec 2017 22:30:15 -0000 On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers wrote: > On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: > >> >> >> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers wrote: >> >>> I just upgraded my head machine to r326772. Now, boot2 can't find the >>> loader. Instead, it tries to boot the kernel directly, which fails >>> because >>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>> /boot/loader" I get the error "don't know how to load module >>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>> introduced since then. Any ideas? >>> >>> BTW, I can successfully boot with the following commands: >>> unload >>> load /boot/kernel/kernel >>> load zfs >>> boot >>> >>> http://bayimg.com/iAKmFaAgl >> >> >> I'd bisect :) >> >> However, try to update to just before this commit: >> >> Author: imp >> Date: Fri Dec 8 19:57:16 2017 +0000 >> >> Create interp class. >> >> Create an interp class. Use it to separate out the different types of >> interpreters: forth and simple with function pointers rather than >> via #ifdefs. >> >> Obtained from: lua boot loader project >> (via https://bsdimp@github.com/bsdimp/freebsd.git lua-bootloader) >> Sponsored by: Netflix >> >> >> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> >> would be a good place to start. >> >> It's a shame we can't create zpool images with an unpriv'd user command. >> Would help out the ZFS testing of the boot loader refinement. >> >> Warner >> > > If I bisect this, what parts do I need to reinstall each time? A full > buildworld would be too slow. Is it sufficient to reinstall stand? > Just rebuild stand, reinstall it and reboot. Also, why are you trying to load /boot/loader from /boot/zfsloader? That has me confused. The screen shot looks like it found the kernel OK and was going to boot it, but then you interrupted it, unloaded it and tried to load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or something like that? OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the real bug here is that the menu has stopped working leading to your confusion... Warner From owner-freebsd-current@freebsd.org Mon Dec 11 22:37: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 19331EA14FB for ; Mon, 11 Dec 2017 22:37:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 843F47D270 for ; Mon, 11 Dec 2017 22:37:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id f13so20998366lff.12 for ; Mon, 11 Dec 2017 14:37:19 -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=0HOgl/8Qg2WcuO0yDhjFf8pqP1kaGT5XRdPKjk6wnNM=; b=XHXe5E/T/WUiuCJcuA0QM8vHMgFP/IOqzyM0iv5wac0+lmKJOoBUA0LI0wQ6cSPLW3 bFnomvhDDcW3VYs7e+xq9AOF2FujMx4BnYwsdC2S7WFwC72Fi0JzgPNm1N12cXodiKsi JO8+t/NZF5rVo3p3RwZ3SYHjg4Y3OCyjt6JkKQSqk1j3q1s8okaKUf/GultXXtpp0bpL gFf5Nnwhnkkr09cxnzU0v2JZRVBH87tWxrCBa29w5Sv3jZ8YjjRcqXkpKWKPL8vI4X90 raTlE9WxDJB2fKg09rEmHyDoDkDrk1HCxVxf7bNa57tBvN3m7+Dbard58QFbI8PmfXyT VinQ== 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=0HOgl/8Qg2WcuO0yDhjFf8pqP1kaGT5XRdPKjk6wnNM=; b=rtF2+Q2gAnjwTkPzf25/1pZwM16czK7re2FLXm9ibRjF7M0rt12Mn7t5WiO/sjFnjx WFkgsrMc06lF7LZHlkHi4FM5YrZ5bvD4WhF+EqqqI93Lt4jw1+ywcpY4+a4FNTzunlN0 D4R7zD2GYDa+nAnGU8hLrcfkS2d4P4hjjnQMspm6r4I9kHVGEiEjzRaV6qXO+72RhvVK vTpCv1GknAhkw0ZZW3X5qFt89ku5zT/xhTUC+hZa0q9gVlmqPbpoU3lJxgx+Sf3u9OFq wHStqhIGEChy5C45yAptBXH3K/za0dYoys0rfiRETyfZSpmhuk/kuOTZt0tzTwlUk+t4 Ya3w== X-Gm-Message-State: AKGB3mI36hwwADUFsP6GWyL649ec8CXCJHMtw1jZvBh515xSdp4Ni68n CYDjjyvZF2C/mFF1BwjJ6xHbvgluOe4RL+gwh5c= X-Google-Smtp-Source: ACJfBouJQqG/U4SuYUYNL281Ct4VQkI8rNrW4quCXHxCLEMJt6oMgb6Q6lpi42rnRUGPGnHVD9NZpkjsSMmU7XAa4oM= X-Received: by 10.46.88.4 with SMTP id m4mr925793ljb.15.1513031837520; Mon, 11 Dec 2017 14:37:17 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Mon, 11 Dec 2017 14:37:16 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Mon, 11 Dec 2017 15:37:16 -0700 X-Google-Sender-Auth: UhonA1bzO-ch9RNeFss2oJyq-mM Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Warner Losh Cc: 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: Mon, 11 Dec 2017 22:37:20 -0000 On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh wrote: > > > On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers wrote: > >> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: >> >>> >>> >>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers >>> wrote: >>> >>>> I just upgraded my head machine to r326772. Now, boot2 can't find the >>>> loader. Instead, it tries to boot the kernel directly, which fails >>>> because >>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>> /boot/loader" I get the error "don't know how to load module >>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>> introduced since then. Any ideas? >>>> >>>> BTW, I can successfully boot with the following commands: >>>> unload >>>> load /boot/kernel/kernel >>>> load zfs >>>> boot >>>> >>>> http://bayimg.com/iAKmFaAgl >>> >>> >>> I'd bisect :) >>> >>> However, try to update to just before this commit: >>> >>> Author: imp >>> Date: Fri Dec 8 19:57:16 2017 +0000 >>> >>> Create interp class. >>> >>> Create an interp class. Use it to separate out the different types of >>> interpreters: forth and simple with function pointers rather than >>> via #ifdefs. >>> >>> Obtained from: lua boot loader project >>> (via https://bsdimp@github.com/bsdimp/freebsd.git >>> lua-bootloader) >>> Sponsored by: Netflix >>> >>> >>> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>> >>> would be a good place to start. >>> >>> It's a shame we can't create zpool images with an unpriv'd user command. >>> Would help out the ZFS testing of the boot loader refinement. >>> >>> Warner >>> >> >> If I bisect this, what parts do I need to reinstall each time? A full >> buildworld would be too slow. Is it sufficient to reinstall stand? >> > > Just rebuild stand, reinstall it and reboot. > > Also, why are you trying to load /boot/loader from /boot/zfsloader? That > has me confused. The screen shot looks like it found the kernel OK and was > going to boot it, but then you interrupted it, unloaded it and tried to > load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or > something like that? > > OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the real > bug here is that the menu has stopped working leading to your confusion... > > Warner > It certainly could be a bug in the menu. I'm definitely confused, because this is a domain I've seldom dealt with, since it usually just works. If I'm actually in /boot/loader, then there are two problems: 1) The menu isn't working 2) The loader isn't reading /boot/loader.conf. From owner-freebsd-current@freebsd.org Mon Dec 11 22:56: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 D11B4EA1BB4 for ; Mon, 11 Dec 2017 22:56:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91B057DDF2 for ; Mon, 11 Dec 2017 22:56:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id d137so19782489itc.2 for ; Mon, 11 Dec 2017 14:56:52 -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=Vgb6L/RmzcHJNMSC0h+1BAq2Uun0MaSys/0OP3k93wo=; b=mepfKcnGgMtVOYpQSDhnKjNwxKnrWBVQYhkWOZm37sgen32MJiydR+2oP46jxpungC Wx9eBtF2O40ioai+lpfdfgZKPeVNdXjUcJQM/86o9Y2/HNbmKRm6ifs+qBuBkdRH3SLr L621Mmkmqs/sGe5RlYCz7jEQM0r7PRRfsIg0mpfIYGymN2o7TfDI+OkhoTeJYEZ0h7ZO QuE4pkr+HV62sr0Epttq5WRIbhXymEwSIBd5D+Q41Ine9MGlgK82CCy/QDoWlLCDpKRB yuWNEvphy3QHL44m/+A7/XPgug6NfuXyUdCvyYdL0PJ+q5Q8usCjcqCdEgjB3WvOWGPU ckAQ== 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=Vgb6L/RmzcHJNMSC0h+1BAq2Uun0MaSys/0OP3k93wo=; b=QLTh2uBG84EymEQJcQlpyed+TsPuUxcF1X+6ZHGJwInsW9swQVY8R4mkwwYJVpyAnX 4PmWJT/OwvJW09J9nzsLXAW4e+1EL1WwfADHUrh38glp50qGNsw8sDKLwZV0lnyEEuC+ L43lTIo8XQLt2t+2+5tTXxHg9Q3DxoqrJV1ywdVL85lOCgdiRWZURj0jm548z5R9H9O7 wMtnm0EYWINwULgMEsCL+zY4sEDMGyRyAZah2pWvCEmfVInN7S17N7lgEiyPM/gs4Lj0 /+JPF1078zWR4mIa79TNtoSqs93EY031wwWISAkuvL8bmMYNoFonQm8zidCpvxZpYaz/ O1uw== X-Gm-Message-State: AKGB3mLBnpShRAutt45bqe6YiEyUxlN4XEdUUdOoDav5cQ3GfgIt2Y4h wmZM92Kvq7MnOJnEa2XZvZkxhTEz/vJyg4i0G55J77xk X-Google-Smtp-Source: ACJfBotOUKm0ZJXg1YOODx+5/K05pV1mtIxY08nLFoTkK6pKHecUUPbZKmUOQ9IGOKV9RIVQDqYTcJyfVW7+HvBdn+A= X-Received: by 10.36.147.193 with SMTP id y184mr3055964itd.64.1513033011793; Mon, 11 Dec 2017 14:56:51 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 14:56:51 -0800 (PST) X-Originating-IP: [75.104.71.74] In-Reply-To: References: From: Warner Losh Date: Mon, 11 Dec 2017 15:56:51 -0700 X-Google-Sender-Auth: jEtdecLe_2wjjkn9KKcLpyxX0mY Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Alan Somers Cc: 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: Mon, 11 Dec 2017 22:56:52 -0000 On Mon, Dec 11, 2017 at 3:37 PM, Alan Somers wrote: > On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh wrote: > >> >> >> On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers wrote: >> >>> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: >>> >>>> >>>> >>>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers >>>> wrote: >>>> >>>>> I just upgraded my head machine to r326772. Now, boot2 can't find the >>>>> loader. Instead, it tries to boot the kernel directly, which fails >>>>> because >>>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>>> /boot/loader" I get the error "don't know how to load module >>>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>>> introduced since then. Any ideas? >>>>> >>>>> BTW, I can successfully boot with the following commands: >>>>> unload >>>>> load /boot/kernel/kernel >>>>> load zfs >>>>> boot >>>>> >>>>> http://bayimg.com/iAKmFaAgl >>>> >>>> >>>> I'd bisect :) >>>> >>>> However, try to update to just before this commit: >>>> >>>> Author: imp >>>> Date: Fri Dec 8 19:57:16 2017 +0000 >>>> >>>> Create interp class. >>>> >>>> Create an interp class. Use it to separate out the different types >>>> of >>>> interpreters: forth and simple with function pointers rather than >>>> via #ifdefs. >>>> >>>> Obtained from: lua boot loader project >>>> (via https://bsdimp@github.com/bsdimp/freebsd.git >>>> lua-bootloader) >>>> Sponsored by: Netflix >>>> >>>> >>>> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> >>>> would be a good place to start. >>>> >>>> It's a shame we can't create zpool images with an unpriv'd user >>>> command. Would help out the ZFS testing of the boot loader refinement. >>>> >>>> Warner >>>> >>> >>> If I bisect this, what parts do I need to reinstall each time? A full >>> buildworld would be too slow. Is it sufficient to reinstall stand? >>> >> >> Just rebuild stand, reinstall it and reboot. >> >> Also, why are you trying to load /boot/loader from /boot/zfsloader? That >> has me confused. The screen shot looks like it found the kernel OK and was >> going to boot it, but then you interrupted it, unloaded it and tried to >> load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or >> something like that? >> >> OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the real >> bug here is that the menu has stopped working leading to your confusion... >> > >> Warner >> > > It certainly could be a bug in the menu. I'm definitely confused, because > this is a domain I've seldom dealt with, since it usually just works. If > I'm actually in /boot/loader, then there are two problems: > 1) The menu isn't working > 2) The loader isn't reading /boot/loader.conf. > Those re related, so it makes sense they are both broken. Back up one rev (r326771) and see if that works. IT was supposed to fix some regressions from the lua import, but appears to have introduced a new regression. Warner From owner-freebsd-current@freebsd.org Mon Dec 11 23:06:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCF06EA1E82 for ; Mon, 11 Dec 2017 23:06:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DACB7E2E3 for ; Mon, 11 Dec 2017 23:06:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id u62so20008139ita.2 for ; Mon, 11 Dec 2017 15:06:10 -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=YtrEjVLerwfbX8+DyTjhdUSf629Eevus+MZqa0kPdD4=; b=YjnME80Gd9rfM8mMLjCNUHe7tadCLC3U3gb8gixzx9jkmN5eKxnbhi+B3GvVPzYAWN n/19Izb85VPoSyaLbJZbCgxOfuOgavoakCzY7weEwa/JMPxEpQVVTDZ3xKjIinvPqs2m E7qxJQjuuPKB+ZNE6PmmPrNV9rMST392+cbkVyveISL0uVl1grZJPfqv9sLNzKY++wLW 0lNK+UPmUzHVHDUR+y1LQ89uyx0yOXtK2Yj+KDCn6tiN0fs1vqurY8fT5lxF2PzNe9nT 8EasM+zWhvz8UJtmYwZLpo5NTopQmxtEUNxOrZQ1w3pHt3pePHY0lPwTKQ93sqW6QS8h 9YDg== 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=YtrEjVLerwfbX8+DyTjhdUSf629Eevus+MZqa0kPdD4=; b=nISrVzL+UxzF1L/xlEClRq08oGFqrNGBPbkIM+ZF7INm2CP8Oyko2v2slB5LNC0PIx v5BkGU5FlJAqYnCNjRfdbqKwT0adf4sroTL4BkKunPhnkPdSj0uDYECkTs6U9Wb//VoT JRrX+cyjfGV8HdrGx+UfcJpBkIeqROdviMzPQuyxo/VrARvT1OKIAIOPoHwjuFU6e07Q ZoQfOoH0sUY86AHyBBZCpeTmFJ2EXp6JhK8RP/TEWjFvm0T56o8xkoIj7pw+39ZKneIT 7M6vzIONjNUukEDL2H2FGjnKHl3X0VHyTnAX0pWeeCy5IR9723Hss/CEeQojVGRLzOre PC9w== X-Gm-Message-State: AKGB3mJNokat6FEQGJgi/SFTCxvhcUGxtPIxLVzcfnAR3DjMpPl3TwPA /5U3SzEWsI24/OV7pbIOo/uc2QFKfb+odXaddqT5cA== X-Google-Smtp-Source: ACJfBoup2OmRVHIQEWO6CLGam9+MAVsSRneMiSRFpiSKkqaCIY/XZu9RUJDmHiJEM7eWPO/iIuDqAHahz5tO4MCueK0= X-Received: by 10.36.131.200 with SMTP id d191mr3386255ite.97.1513033569823; Mon, 11 Dec 2017 15:06:09 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 15:06:09 -0800 (PST) X-Originating-IP: [75.104.71.74] In-Reply-To: References: From: Warner Losh Date: Mon, 11 Dec 2017 16:06:09 -0700 X-Google-Sender-Auth: oJJh5FyjL4CknjTciQ5dw0aW2sQ Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Alan Somers Cc: 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: Mon, 11 Dec 2017 23:06:10 -0000 I'm seeing the same bug in my qemu VM setup. I'm about to land, so won't likely be able to fix this until I get to the hotel, but I'm pretty sure that I know what caused it. I didn't notice it before the commit (I gotta get a better regression suite in place for this stuff, rather than the ad-hoc testing I've been able to do). Warner On Mon, Dec 11, 2017 at 3:37 PM, Alan Somers wrote: > On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh wrote: > >> >> >> On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers wrote: >> >>> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: >>> >>>> >>>> >>>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers >>>> wrote: >>>> >>>>> I just upgraded my head machine to r326772. Now, boot2 can't find the >>>>> loader. Instead, it tries to boot the kernel directly, which fails >>>>> because >>>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>>> /boot/loader" I get the error "don't know how to load module >>>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>>> introduced since then. Any ideas? >>>>> >>>>> BTW, I can successfully boot with the following commands: >>>>> unload >>>>> load /boot/kernel/kernel >>>>> load zfs >>>>> boot >>>>> >>>>> http://bayimg.com/iAKmFaAgl >>>> >>>> >>>> I'd bisect :) >>>> >>>> However, try to update to just before this commit: >>>> >>>> Author: imp >>>> Date: Fri Dec 8 19:57:16 2017 +0000 >>>> >>>> Create interp class. >>>> >>>> Create an interp class. Use it to separate out the different types >>>> of >>>> interpreters: forth and simple with function pointers rather than >>>> via #ifdefs. >>>> >>>> Obtained from: lua boot loader project >>>> (via https://bsdimp@github.com/bsdimp/freebsd.git >>>> lua-bootloader) >>>> Sponsored by: Netflix >>>> >>>> >>>> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> >>>> would be a good place to start. >>>> >>>> It's a shame we can't create zpool images with an unpriv'd user >>>> command. Would help out the ZFS testing of the boot loader refinement. >>>> >>>> Warner >>>> >>> >>> If I bisect this, what parts do I need to reinstall each time? A full >>> buildworld would be too slow. Is it sufficient to reinstall stand? >>> >> >> Just rebuild stand, reinstall it and reboot. >> >> Also, why are you trying to load /boot/loader from /boot/zfsloader? That >> has me confused. The screen shot looks like it found the kernel OK and was >> going to boot it, but then you interrupted it, unloaded it and tried to >> load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or >> something like that? >> >> OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the real >> bug here is that the menu has stopped working leading to your confusion... >> > >> Warner >> > > It certainly could be a bug in the menu. I'm definitely confused, because > this is a domain I've seldom dealt with, since it usually just works. If > I'm actually in /boot/loader, then there are two problems: > 1) The menu isn't working > 2) The loader isn't reading /boot/loader.conf. > From owner-freebsd-current@freebsd.org Mon Dec 11 23:16: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 079E1EA22FA for ; Mon, 11 Dec 2017 23:16:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCBEB7EAD9 for ; Mon, 11 Dec 2017 23:16:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id u62so20061540ita.2 for ; Mon, 11 Dec 2017 15:16:47 -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=pxQksAHfjINePI9GPfh1mFHW9aDF1OEDS7vPo7k8zSI=; b=OKv3MxMctwVUwuGCU+gIglwZkN1me7XzOBqX+FbAuL3YpyEtc4vp7pwYiJJIkA4mjp L3Ncz09wsOalGcsCuIDxU8Z0gm74uIWCiCQRRq96BFy3ipOgOudk/GZbpQt/HC44IYi8 rYMtF7hvjarAO/RPruZY9TOCfACmyv3/4uMSmi/apW7+lhB43TWfDZPZzcWAg0dfwNMG tS7Kxpr4Etsl2VcyUuoHeC8JonG69KQCkhum4fEDBTQNmdVhkiUxkicL/ydEq/7QPHqG /k+iYrriKJbarxFcaYpkxLqzSm3p3/R/Eow2lLjR0CuTPD1suuYwT1SeFjGU113SaQZ9 kCxQ== 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=pxQksAHfjINePI9GPfh1mFHW9aDF1OEDS7vPo7k8zSI=; b=YFcPI9Vt7SBVVC8F1GqF11+VwgAQbln6y26/YhfiSeejlP9GmS744U1cyfReSdDluJ DWfvcl8oMAi+UjrNfJx7KhuSRu23Daxb9Pv5WrjrO0shxFckWZ3lhuJJ2M3akl0Fpe3C lYX8KaO+eFx7MzGA9HCj3T4eUco7hB1QBBY90MuE+O0ey+VKTYYOMl/QwzL9/Qn3htfM vPC0Pw13DFNx1EHx4gmislYrLHzuMtXRtrADc0JJRHNvgVmz7LPr1LHt7GGdcJKmeTv5 Cy3zeJRwOWZ9S5Uqog39H2mHM6PhOlr91/fHzuubLLAB7qKm2xfCWPvy3w6IBepHdRI4 CVjQ== X-Gm-Message-State: AKGB3mJDOlDKAF6O1y4UawkjqEB5VfVTYEM4An9AmvoEY2dVYeb1L4DG kiQKwyWHGiM5qb1KOE7eHxGSoG16pa1zbKegqqC+WA== X-Google-Smtp-Source: ACJfBouDWWH5LoOrn1sv+GlNna9iiWWV74jT3Gzwh7r+WDipblfZitQxmib/gqiKJsy1HqUOT+GHzqQrVwQkw8lfQRI= X-Received: by 10.36.164.13 with SMTP id z13mr3494615ite.115.1513034207035; Mon, 11 Dec 2017 15:16:47 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 15:16:46 -0800 (PST) X-Originating-IP: [75.104.71.74] In-Reply-To: References: From: Warner Losh Date: Mon, 11 Dec 2017 16:16:46 -0700 X-Google-Sender-Auth: MTMH5QCLOuG_nW9tzw8Ynq-PHzU Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Alan Somers Cc: 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: Mon, 11 Dec 2017 23:16:48 -0000 Ooops I lied. r326784 should fix it. Now I have flight attendants yelling at me to put this computer away.... Warner On Mon, Dec 11, 2017 at 4:06 PM, Warner Losh wrote: > I'm seeing the same bug in my qemu VM setup. I'm about to land, so won't > likely be able to fix this until I get to the hotel, but I'm pretty sure > that I know what caused it. I didn't notice it before the commit (I gotta > get a better regression suite in place for this stuff, rather than the > ad-hoc testing I've been able to do). > > Warner > > On Mon, Dec 11, 2017 at 3:37 PM, Alan Somers wrote: > >> On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh wrote: >> >>> >>> >>> On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers >>> wrote: >>> >>>> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: >>>> >>>>> >>>>> >>>>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers >>>>> wrote: >>>>> >>>>>> I just upgraded my head machine to r326772. Now, boot2 can't find the >>>>>> loader. Instead, it tries to boot the kernel directly, which fails >>>>>> because >>>>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>>>> /boot/loader" I get the error "don't know how to load module >>>>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>>>> introduced since then. Any ideas? >>>>>> >>>>>> BTW, I can successfully boot with the following commands: >>>>>> unload >>>>>> load /boot/kernel/kernel >>>>>> load zfs >>>>>> boot >>>>>> >>>>>> http://bayimg.com/iAKmFaAgl >>>>> >>>>> >>>>> I'd bisect :) >>>>> >>>>> However, try to update to just before this commit: >>>>> >>>>> Author: imp >>>>> Date: Fri Dec 8 19:57:16 2017 +0000 >>>>> >>>>> Create interp class. >>>>> >>>>> Create an interp class. Use it to separate out the different types >>>>> of >>>>> interpreters: forth and simple with function pointers rather than >>>>> via #ifdefs. >>>>> >>>>> Obtained from: lua boot loader project >>>>> (via https://bsdimp@github.com/bsdimp/freebsd.git >>>>> lua-bootloader) >>>>> Sponsored by: Netflix >>>>> >>>>> >>>>> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >>>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>> >>>>> would be a good place to start. >>>>> >>>>> It's a shame we can't create zpool images with an unpriv'd user >>>>> command. Would help out the ZFS testing of the boot loader refinement. >>>>> >>>>> Warner >>>>> >>>> >>>> If I bisect this, what parts do I need to reinstall each time? A full >>>> buildworld would be too slow. Is it sufficient to reinstall stand? >>>> >>> >>> Just rebuild stand, reinstall it and reboot. >>> >>> Also, why are you trying to load /boot/loader from /boot/zfsloader? That >>> has me confused. The screen shot looks like it found the kernel OK and was >>> going to boot it, but then you interrupted it, unloaded it and tried to >>> load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or >>> something like that? >>> >>> OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the >>> real bug here is that the menu has stopped working leading to your >>> confusion... >>> >> >>> Warner >>> >> >> It certainly could be a bug in the menu. I'm definitely confused, >> because this is a domain I've seldom dealt with, since it usually just >> works. If I'm actually in /boot/loader, then there are two problems: >> 1) The menu isn't working >> 2) The loader isn't reading /boot/loader.conf. >> > > From owner-freebsd-current@freebsd.org Mon Dec 11 23:33:28 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 D1B08EA2904 for ; Mon, 11 Dec 2017 23:33:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E26C7F443 for ; Mon, 11 Dec 2017 23:33:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id x204so21112715lfa.11 for ; Mon, 11 Dec 2017 15:33:28 -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=/pKKM24/nRkI96zpuV4QHAG+yerDvb3NzsfvVcaw7R4=; b=st2XiVJ8PA6ouwKxLYIrqsug4O/kP26mQxdLcooFcPlVsouJ95fWjKRImaHuXodg37 gqjKLVuuT97RKW+i44eM8B3lrdUnpyhiBso2RuchCDMv8xbXdTUlx5eepeMmQ8KhdJOO T8FlT+vMXgdsf3Uyr/Yr3j3T9Ltyjph7vQ+kuvQKHTwfe6+LvBhLD70jyLOSVPl0m4tz vZOS0jMIpeEbmx5Wp9nVbmePqImrioXp3S2JsdOoiPa0qhS/KBNzUsbUI3ms8erkjQ8p 22QXkD1ugY3nobj/mfUTuq5WEDK4W5uP1rALMjdJ98rgdWBrQRLruqk6he+wotdLMKPx HfZA== 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=/pKKM24/nRkI96zpuV4QHAG+yerDvb3NzsfvVcaw7R4=; b=P6i8NbpgyMyscmadZSxskVD5hwMCpTH9kbD4ds9VhQ7ITaBWnk8eQeKZDaTxxLTETe 00H1eq/yQvbVK0wSqdpCi+bSFgNWpNuPdUJM1qXJtaNT4dHZlbyWz7A5FtRwWxANv0xJ 1YzKOHwmnvAlv0Nvb2tvVlym72wszcmjncQi5dDUqcjr1Vb5KNTHM7qOSYm4lQRiGSF5 jgyyguWhpkC9kibNqyYOV1DHl3UMshyPBp6y1QTMztzXv1/HfN5in6673qYmYn+91FJY zpA/5mPO5PLmY826biOnY8mcbg8Xe8Nh4d8Zn5Pt/8Dv20am25974BD4aZhbhXTsJ9ts 7cPA== X-Gm-Message-State: AKGB3mIecZbqlGE3BtBPC3n5eqoC67PQqZKxh9qkTCHPnsqVt4Ie3oEi Yr3hEqKgtlnWDlRYGhY8n3mSidpJtM+lP9J28JU= X-Google-Smtp-Source: ACJfBotceu2tO+aTsOMUUr+/sQxUPsAT4+XSrLuME8YvikluLdAFPAz5OpGsRKJ2+AG1aVtAyaNt7ft3eRv/f4osy+M= X-Received: by 10.25.198.147 with SMTP id w141mr790138lff.84.1513035205028; Mon, 11 Dec 2017 15:33:25 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Mon, 11 Dec 2017 15:33:24 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Mon, 11 Dec 2017 16:33:24 -0700 X-Google-Sender-Auth: a3RoW0UcZu8-rvxeTkMHyPZIWRo Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Warner Losh Cc: 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: Mon, 11 Dec 2017 23:33:28 -0000 Yep, I can confirm that r326772 introduced the bug, and it is fixed by r326784. Thanks for the quick turnaround. -Alan On Mon, Dec 11, 2017 at 4:16 PM, Warner Losh wrote: > Ooops I lied. r326784 should fix it. Now I have flight attendants yelling > at me to put this computer away.... > > Warner > > On Mon, Dec 11, 2017 at 4:06 PM, Warner Losh wrote: > >> I'm seeing the same bug in my qemu VM setup. I'm about to land, so won't >> likely be able to fix this until I get to the hotel, but I'm pretty sure >> that I know what caused it. I didn't notice it before the commit (I gotta >> get a better regression suite in place for this stuff, rather than the >> ad-hoc testing I've been able to do). >> >> Warner >> >> On Mon, Dec 11, 2017 at 3:37 PM, Alan Somers wrote: >> >>> On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh wrote: >>> >>>> >>>> >>>> On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers >>>> wrote: >>>> >>>>> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers >>>>>> wrote: >>>>>> >>>>>>> I just upgraded my head machine to r326772. Now, boot2 can't find >>>>>>> the >>>>>>> loader. Instead, it tries to boot the kernel directly, which fails >>>>>>> because >>>>>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>>>>> /boot/loader" I get the error "don't know how to load module >>>>>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>>>>> introduced since then. Any ideas? >>>>>>> >>>>>>> BTW, I can successfully boot with the following commands: >>>>>>> unload >>>>>>> load /boot/kernel/kernel >>>>>>> load zfs >>>>>>> boot >>>>>>> >>>>>>> http://bayimg.com/iAKmFaAgl >>>>>> >>>>>> >>>>>> I'd bisect :) >>>>>> >>>>>> However, try to update to just before this commit: >>>>>> >>>>>> Author: imp >>>>>> Date: Fri Dec 8 19:57:16 2017 +0000 >>>>>> >>>>>> Create interp class. >>>>>> >>>>>> Create an interp class. Use it to separate out the different >>>>>> types of >>>>>> interpreters: forth and simple with function pointers rather than >>>>>> via #ifdefs. >>>>>> >>>>>> Obtained from: lua boot loader project >>>>>> (via https://bsdimp@github.com/bsdimp/freebsd.git >>>>>> lua-bootloader) >>>>>> Sponsored by: Netflix >>>>>> >>>>>> >>>>>> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >>>>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>>> >>>>>> would be a good place to start. >>>>>> >>>>>> It's a shame we can't create zpool images with an unpriv'd user >>>>>> command. Would help out the ZFS testing of the boot loader refinement. >>>>>> >>>>>> Warner >>>>>> >>>>> >>>>> If I bisect this, what parts do I need to reinstall each time? A full >>>>> buildworld would be too slow. Is it sufficient to reinstall stand? >>>>> >>>> >>>> Just rebuild stand, reinstall it and reboot. >>>> >>>> Also, why are you trying to load /boot/loader from /boot/zfsloader? >>>> That has me confused. The screen shot looks like it found the kernel OK and >>>> was going to boot it, but then you interrupted it, unloaded it and tried to >>>> load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or >>>> something like that? >>>> >>>> OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the >>>> real bug here is that the menu has stopped working leading to your >>>> confusion... >>>> >>> >>>> Warner >>>> >>> >>> It certainly could be a bug in the menu. I'm definitely confused, >>> because this is a domain I've seldom dealt with, since it usually just >>> works. If I'm actually in /boot/loader, then there are two problems: >>> 1) The menu isn't working >>> 2) The loader isn't reading /boot/loader.conf. >>> >> >> > From owner-freebsd-current@freebsd.org Tue Dec 12 00:07:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A458EE80A79 for ; Tue, 12 Dec 2017 00:07:08 +0000 (UTC) (envelope-from wlosh@bsdimp.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 552EF80607 for ; Tue, 12 Dec 2017 00:07:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id d16so20144411itj.1 for ; Mon, 11 Dec 2017 16:07:08 -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=/9mn3zlGiLk8W6nlmojznpnei1mCEDNbtQoLygRo9hI=; b=0roBF8tpc+kTlQRUiIXbxF2YjLp4aYfP+gNXqUvXXwPqZ5VcGJpucZeUAbYcmeXM1d mqOTMMYDFgOOFvNEhKk0LsXHckb6/Gs0U6FgJPFedbOfSkjnAV1/vCgsu+k9db4c4Aw0 Hqp5y24/hY7rqnQUO3nX8rlcpVTLSUOohGx29eP73g8tgVcjvTjbUPTb3CAK0KG3Vqv7 tY3mrAkGhopWW6PJFRC1Kmz6iOrjHfT1Xa1OvUX3+g82r5hD/QCuc34JnAlXMtXZ1+Om GmLr2SkfePjPz9wCr+rOLj6yT6JCX8Vm0bE8b0Dkary4UXKs3Eagv/dCW17ToRWwPdby usRQ== 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=/9mn3zlGiLk8W6nlmojznpnei1mCEDNbtQoLygRo9hI=; b=rUQarztSMARqMdlnfQFOfg33mxvr0yz9Z4ExUBM/lyVjY1f7eKL4NNm8AHdMWkpGm0 hwDaUtKrG735VdEI3j5kDVYplc8hB5RsPa1wlJ6Suybvd4eajF4/727mom2K6ouQpl3X EwJD4ktGMTJ8/Ifpb+VTjGx7kpsakjuuRJFV4p86quW0tl3xAdDRA54gZXBYCmK5E82P ny/OzTwiBRSeUF4dqUB5U0ktu1x7npS2DFo0M3i7mcqGes73Vc46o5zOu6xOxpef2xS6 HWVyvv+Rofd2e8N2/E7OjAGFCMG/uxW1NWlpsyLOr/J+TDQx/Pikq2FROALVpKgDepjj kenw== X-Gm-Message-State: AKGB3mL2NO7bu1rHXTx5AP60uCCSSp81f/ubqDFMS1i6d1dsRueMmgJM pIJAoB/z1U3W7gZZML/gL3WvKp/oi/NP3d812cKDvw== X-Google-Smtp-Source: ACJfBovhgwpj+AsXCVV7+wMsGdFb0Z0EEJALOlebmPJ7WbPFXtD028mNeNbwWKiWeu1IC5imrxan+DZsfMW5oJ7J5AM= X-Received: by 10.107.81.24 with SMTP id f24mr2809650iob.63.1513037227564; Mon, 11 Dec 2017 16:07:07 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 16:07:06 -0800 (PST) X-Originating-IP: [107.77.211.234] In-Reply-To: References: From: Warner Losh Date: Mon, 11 Dec 2017 17:07:06 -0700 X-Google-Sender-Auth: un32tS0i_HC-CEBuyyqGodkM-PQ Message-ID: Subject: Re: don't know how to load module '/boot/loader' To: Alan Somers Cc: 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, 12 Dec 2017 00:07:08 -0000 You're welcome. Sorry for the hassle. Warner On Mon, Dec 11, 2017 at 4:33 PM, Alan Somers wrote: > Yep, I can confirm that r326772 introduced the bug, and it is fixed by > r326784. Thanks for the quick turnaround. > > -Alan > > > On Mon, Dec 11, 2017 at 4:16 PM, Warner Losh wrote: > >> Ooops I lied. r326784 should fix it. Now I have flight attendants yelling >> at me to put this computer away.... >> >> Warner >> >> On Mon, Dec 11, 2017 at 4:06 PM, Warner Losh wrote: >> >>> I'm seeing the same bug in my qemu VM setup. I'm about to land, so won't >>> likely be able to fix this until I get to the hotel, but I'm pretty sure >>> that I know what caused it. I didn't notice it before the commit (I gotta >>> get a better regression suite in place for this stuff, rather than the >>> ad-hoc testing I've been able to do). >>> >>> Warner >>> >>> On Mon, Dec 11, 2017 at 3:37 PM, Alan Somers >>> wrote: >>> >>>> On Mon, Dec 11, 2017 at 3:30 PM, Warner Losh wrote: >>>> >>>>> >>>>> >>>>> On Mon, Dec 11, 2017 at 3:26 PM, Alan Somers >>>>> wrote: >>>>> >>>>>> On Mon, Dec 11, 2017 at 3:19 PM, Warner Losh wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 11, 2017 at 3:03 PM, Alan Somers >>>>>>> wrote: >>>>>>> >>>>>>>> I just upgraded my head machine to r326772. Now, boot2 can't find >>>>>>>> the >>>>>>>> loader. Instead, it tries to boot the kernel directly, which fails >>>>>>>> because >>>>>>>> the ZFS module isn't loaded. If I break into boot2 and type "boot >>>>>>>> /boot/loader" I get the error "don't know how to load module >>>>>>>> '/boot/loader'". I last updated on 30-Nov, so this bug must've been >>>>>>>> introduced since then. Any ideas? >>>>>>>> >>>>>>>> BTW, I can successfully boot with the following commands: >>>>>>>> unload >>>>>>>> load /boot/kernel/kernel >>>>>>>> load zfs >>>>>>>> boot >>>>>>>> >>>>>>>> http://bayimg.com/iAKmFaAgl >>>>>>> >>>>>>> >>>>>>> I'd bisect :) >>>>>>> >>>>>>> However, try to update to just before this commit: >>>>>>> >>>>>>> Author: imp >>>>>>> Date: Fri Dec 8 19:57:16 2017 +0000 >>>>>>> >>>>>>> Create interp class. >>>>>>> >>>>>>> Create an interp class. Use it to separate out the different >>>>>>> types of >>>>>>> interpreters: forth and simple with function pointers rather than >>>>>>> via #ifdefs. >>>>>>> >>>>>>> Obtained from: lua boot loader project >>>>>>> (via https://bsdimp@github.com/bsdimp/freebsd.git >>>>>>> lua-bootloader) >>>>>>> Sponsored by: Netflix >>>>>>> >>>>>>> >>>>>>> git-svn-id: svn+ssh://svn.freebsd.org/base/head@326712 >>>>>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>>>> >>>>>>> would be a good place to start. >>>>>>> >>>>>>> It's a shame we can't create zpool images with an unpriv'd user >>>>>>> command. Would help out the ZFS testing of the boot loader refinement. >>>>>>> >>>>>>> Warner >>>>>>> >>>>>> >>>>>> If I bisect this, what parts do I need to reinstall each time? A >>>>>> full buildworld would be too slow. Is it sufficient to reinstall stand? >>>>>> >>>>> >>>>> Just rebuild stand, reinstall it and reboot. >>>>> >>>>> Also, why are you trying to load /boot/loader from /boot/zfsloader? >>>>> That has me confused. The screen shot looks like it found the kernel OK and >>>>> was going to boot it, but then you interrupted it, unloaded it and tried to >>>>> load /boot/loader. Shouldn't that be /boot/kernel or /boot/kernel.old or >>>>> something like that? >>>>> >>>>> OK is /boot/loader's prompt (boot2 has no such prompt).... maybe the >>>>> real bug here is that the menu has stopped working leading to your >>>>> confusion... >>>>> >>>> >>>>> Warner >>>>> >>>> >>>> It certainly could be a bug in the menu. I'm definitely confused, >>>> because this is a domain I've seldom dealt with, since it usually just >>>> works. If I'm actually in /boot/loader, then there are two problems: >>>> 1) The menu isn't working >>>> 2) The loader isn't reading /boot/loader.conf. >>>> >>> >>> >> > From owner-freebsd-current@freebsd.org Tue Dec 12 05:31: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 656CBE8DFD6 for ; Tue, 12 Dec 2017 05:31:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 254DB6CD64 for ; Tue, 12 Dec 2017 05:31:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id t1so21536654ite.5 for ; Mon, 11 Dec 2017 21:31:14 -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=B6JbqOA5VJBCtT0lWrj88jl3oM7eEcniYUafyoE9N7k=; b=c23/t+S1wlxRkGwg6gbIoOX3T1eJ242FRkdXD8uqLQAo5Zuu6UQjNI+ZE8BxXIXzcp dY+PMixzndBalqh5zEmB/gA0axOYO0n+zpoYk1S43/sZF05k/PqdywLtJUfGUx0nXkwl tNesHnnsRwi2bClYr+bHYsOa+tGtlf00AdPcHL7azRXpiOO3+GfG4x6FYkNPFsyUgW4F /Zzi33S8D7A15L8M0D2bgqHHo8lKcE7cflAgZkqtFJiDRITucdom/CAPm/8HRJd172Ky TN4Vgc7t6bN+yXSiNLLTEI5sQwecmrW0hOP9ybDA7jmxSZ9Dlo/atlvzF6wObsMA5hGi I1hw== 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=B6JbqOA5VJBCtT0lWrj88jl3oM7eEcniYUafyoE9N7k=; b=lNiI4uEdbVFQdzaJQEF50pfVXk/BFMEq8VPFDvVz0M9YU4bag6sdJNpLo2MBvgIalE LuGF/yzWqTch9VoT4NIGlAZiGDofQy9w8zK2neGlzd1o+O692wHHmaPLHJJccKBckYKE ait5tcfTbo/+Yd6guQ0d7ExxWwXWHOwbkyDpMSoEohFM+qJGJhD3r87rfWmBXUFSjXFW MzGsV2hdAWXq4Ufpy8LHSeBQhefu71VmVdL5gMWIX3NGaQxdV1oU7BLwRFifUH8P1AzX ivPQzc/JqfX0mLLKlxP8eIymPiugnLbE9o0juX8WWku26AgPR0kegF6cPF/Ba8VTqCeW pfiw== X-Gm-Message-State: AKGB3mLFtj0npCHX3j7m/f265Y2/u3GTM8ofSbO7bfKxAoIyz+iXYMFZ uMUEATrNYNmEn01Drf0kXNt/ZHFBtePja7i1sKYkIA== X-Google-Smtp-Source: ACJfBossYrl0xDtyLp/qLL0vNwLkSoLXeuK/iVZpps4RgVrsmVkLXI7l0yiigjslIDuN20Dq2mlUh1kmT2zvoxJJQsc= X-Received: by 10.36.131.200 with SMTP id d191mr1055360ite.97.1513056673380; Mon, 11 Dec 2017 21:31:13 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 11 Dec 2017 21:31:12 -0800 (PST) X-Originating-IP: [12.227.204.186] In-Reply-To: <20171210204248.7295296d@thor.intern.walstatt.dynvpn.de> References: <20171209194129.53977a63@thor.intern.walstatt.dynvpn.de> <728FB521-24EE-4628-9816-EB3DF0ACA14E@freebsd.org> <20171209214746.1debb72e@thor.intern.walstatt.dynvpn.de> <20171210023503.6d8e02b3@thor.intern.walstatt.dynvpn.de> <20171210111456.15fe1693@thor.intern.walstatt.dynvpn.de> <20171210135433.7b36c9f1@thor.intern.walstatt.dynvpn.de> <20171210204248.7295296d@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Mon, 11 Dec 2017 22:31:12 -0700 X-Google-Sender-Auth: GGfBp5kxSPzwh3M9-DVR9nL_i8s Message-ID: Subject: Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard To: "O. Hartmann" Cc: Michael Tuexen , 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, 12 Dec 2017 05:31:14 -0000 On Sun, Dec 10, 2017 at 12:42 PM, O. Hartmann wrote: > Am Sun, 10 Dec 2017 13:54:06 +0100 > "O. Hartmann" schrieb: > > > Am Sun, 10 Dec 2017 11:14:51 +0100 > > "O. Hartmann" schrieb: > > > > > Am Sat, 9 Dec 2017 19:10:03 -0700 > > > Warner Losh schrieb: > > > > > > > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann > wrote: > > > > [schnipp] > > > > > > > > > > > > > > I'm with you on this. I'm just trying to figure out what, exactly, I > need > > > > to try to setup since this isn't quite my env. > > > > > > I have to wait until my box has built r326550 ... > > > > I just built r326550, installed the usual way without changes the > NanoBSD image and it > > worked! > > > > [...] > > r326583 works, too, r32684 has a compilation failure due to > sys/geom/eli/g_eli_hmac.c Good to know. Will look into the compile issue. And somehow making a geli partition from a non-geli one w/o priv... Warner From owner-freebsd-current@freebsd.org Tue Dec 12 07:34: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 2FD96E9061D for ; Tue, 12 Dec 2017 07:34:42 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDEDE7060E for ; Tue, 12 Dec 2017 07:34:41 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id f143so22115207itb.0 for ; Mon, 11 Dec 2017 23:34:41 -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=q+w+cu023nLnthVy4nPqXJMd6c/F+UzAkp2hsmGfTc0=; b=ppts/efd5+PKRxetfoF4PjvWOleb+M3S6qmF7no4JYRYeGVcJt+WVQ8UpT//06fhpq oLuWK5ppP3a35ZIup5R3tSjgkso4ifOg3w8ApJi+aT51QBBm0io1DLGXwkpRkim4z/rI gXQknxUV8ZJPbNzRmz16HmZ0A1fOOykFBkaA7+96XIGzsz2YVDgBEEy3Pv9m39iEWH3e hmupDY3q/+Ztbo45bF7JPDUGnDIs1Yunr8frj39mBIpP67nmlkPKqIrFwuFeCCZOGlIv BP11ifzaGw4ncbMqL2zdbRYMjMg3hHBf8BLPusPGS9kZ71ElX8EmDn4Y4/IIU1V2qL6q NZuA== 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=q+w+cu023nLnthVy4nPqXJMd6c/F+UzAkp2hsmGfTc0=; b=pKSsUXTB6UwwTxR3oHrZ06Y1OcKmKgGdzw2b8E4zNLHHMqzYqExFTILj3QdI+kOCbi dR73KVuud+FvpmWiPDUjjMl0PtGb4nSRP6g2K91a+kmeQL8NjZycU1jtcM2WPJ1I+Y8O pqaPJmNynBr5NX7h7JWzl6zYhPgxd4sqWEJSWg4KvXxc4roahy0MfAoFJ2w2py40z9RH CVkXC2lYfoyLIfZFk3Jm3eTaooiKu8nBHw1hg7PqUN57wavotzY5FC9113bsOP6JW4jO dxWH4OYndw7ZVzkxX0vitxj909vSb7lg6uTuRydKixZH8bIaTPBuaPzwPd8YF1lrrsBN gvwg== X-Gm-Message-State: AKGB3mIBQA46xwog+p4uWuol3IcReoBVGC2eFuGWog0ypWqzYUlTj4Fh IP47N4g4bVME+ceOi4CFKfUq5BnFIGU7MVvxz+LhYA== X-Google-Smtp-Source: ACJfBovw9p6tczSEwLbpu2qlNWSlzvKdifpOrQR0TGAo8LBIQTCjN5jRknG85V0hDAQXzKbPQoaux0A5uxaOi7QOl7c= X-Received: by 10.107.24.198 with SMTP id 189mr1905442ioy.213.1513064080772; Mon, 11 Dec 2017 23:34:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Mon, 11 Dec 2017 23:34:40 -0800 (PST) From: blubee blubeeme Date: Tue, 12 Dec 2017 15:34:40 +0800 Message-ID: Subject: get_swap_pager(x) failed 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: Tue, 12 Dec 2017 07:34:42 -0000 I am seeing tons of these messages while running tail -f /var/log/messages ============ Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(22): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(11): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(8): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(6): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(21): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(19): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed ========== running top and sorting by size I have this output: =========== last pid: 15976; load averages: 0.62, 0.92, 0.94 up 1+03:41:32 15:31:28 119 processes: 1 running, 117 sleeping, 1 stopped CPU: 1.5% user, 1.8% nice, 1.5% system, 0.4% interrupt, 94.8% idle Mem: 3442M Active, 293M Inact, 4901M Laundry, 22G Wired, 1057M Free ARC: 18G Total, 1488M MFU, 15G MRU, 4003K Anon, 178M Header, 1171M Other 16G Compressed, 23G Uncompressed, 1.41:1 Ratio Swap: 2048M Total, 2028M Used, 20M Free, 99% Inuse, 36K In PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1118 blubee 1 20 0 24756M 102M select 3 122:30 2.62% Xorg 15960 blubee 1 20 0 22693M 248M select 0 0:01 0.65% urxvt 2369 blubee 1 20 0 11411M 10152K select 5 0:02 0.00% urxvt 13251 blubee 1 20 0 11405M 245M select 0 0:03 0.00% urxvt 1545 blubee 1 20 0 11405M 244M select 3 0:03 0.00% urxvt 4182 blubee 1 20 0 11405M 248M select 1 0:12 0.00% urxvt 3826 blubee 1 20 0 11405M 246M select 6 0:03 0.00% urxvt 1165 blubee 1 20 0 11401M 15244K select 1 0:03 0.00% urxvt 15316 blubee 63 20 0 2067M 630M select 5 15:39 0.02% firefox 1419 blubee 18 20 0 1989M 263M uwait 4 5:29 0.00% chrome 15392 blubee 37 20 0 1934M 572M select 7 7:47 1.41% firefox 15320 blubee 40 20 0 1829M 440M select 6 3:30 0.00% firefox 15323 blubee 37 20 0 1797M 418M select 7 1:05 0.02% firefox 1543 blubee 17 25 5 1695M 794M uwait 1 38:13 0.93% chrome 1370 blubee 6 23 0 1482M 982M select 6 57:09 7.78% chrome 1368 blubee 30 22 0 1307M 468M select 4 78:18 7.79% chrome 2338 blubee 14 20 0 1137M 334M uwait 3 10:38 0.52% chrome 2481 blubee 21 26 5 1090M 345M uwait 6 7:14 16.00% chrome 3646 blubee 13 25 5 889M 294M uwait 2 0:20 0.00% chrome 2679 blubee 13 25 5 840M 268M uwait 4 9:24 1.30% chrome 2707 blubee 14 25 5 835M 127M uwait 2 3:07 0.02% chrome 3661 blubee 13 25 5 796M 244M uwait 7 0:20 0.06% chrome 2755 blubee 14 25 5 770M 84492K uwait 0 0:39 0.02% chrome 1661 blubee 15 20 0 766M 166M uwait 5 1:06 0.00% chrome 1418 blubee 13 20 0 753M 147M uwait 5 1:24 0.00% chrome 3850 blubee 13 25 5 747M 176M uwait 5 1:58 0.05% chrome 13392 blubee 13 25 5 746M 161M uwait 1 0:30 0.00% chrome 13329 blubee 13 25 5 741M 146M uwait 0 0:18 0.00% chrome 2352 blubee 13 25 5 727M 98888K uwait 0 2:34 0.00% chrome 13389 blubee 13 25 5 726M 169M uwait 1 0:10 0.00% chrome 3600 blubee 14 25 5 713M 124M uwait 0 0:22 0.00% chrome 1415 blubee 12 20 0 704M 127M uwait 2 0:17 0.01% chrome 13346 blubee 13 25 5 688M 123M uwait 4 0:06 0.00% chrome 13368 blubee 13 25 5 686M 142M uwait 7 0:09 0.00% chrome 15394 blubee 13 25 5 685M 161M uwait 7 0:44 0.00% chrome 2501 blubee 13 25 5 684M 83776K uwait 3 0:11 0.00% chrome 1662 blubee 13 20 0 684M 128M uwait 5 0:31 0.01% chrome 3586 blubee 13 25 5 677M 89896K uwait 5 0:21 0.01% chrome 13327 blubee 13 25 5 673M 129M uwait 4 0:05 0.00% chrome 3961 blubee 13 25 5 670M 118M uwait 1 0:05 0.00% chrome 15956 blubee 13 20 0 670M 169M uwait 6 0:03 0.00% chrome 13359 blubee 13 25 5 667M 129M uwait 7 0:14 0.01% chrome 13274 blubee 13 25 5 663M 118M uwait 5 0:11 0.00% chrome 3848 blubee 13 25 5 662M 115M uwait 6 0:03 0.00% chrome 4166 blubee 13 25 5 661M 118M uwait 7 0:18 0.00% chrome 1673 blubee 13 25 5 659M 128M uwait 1 17:48 1.19% chrome 13387 blubee 12 25 5 658M 123M uwait 1 0:08 0.00% chrome 1417 blubee 14 20 0 658M 107M uwait 0 0:15 0.01% chrome 1416 blubee 13 20 0 642M 106M uwait 4 0:12 0.00% chrome 3587 blubee 13 25 5 642M 93292K uwait 3 0:12 0.00% chrome 13364 blubee 13 25 5 626M 96468K uwait 7 0:02 0.00% chrome 3851 blubee 13 25 5 625M 94508K uwait 4 0:01 0.00% chrome 13540 blubee 12 25 5 618M 94384K uwait 3 0:03 0.00% chrome 1231 blubee 12 20 0 576M 44900K uwait 7 0:01 0.00% chrome 1159 blubee 5 20 0 149M 56876K select 6 1:05 0.00% ibus-engine-chewing =========== What's with all the swap errors? I am running ZFS and I have 16GB of ram, how could I be having swap space errors? From owner-freebsd-current@freebsd.org Tue Dec 12 11:04: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 D2241E94428 for ; Tue, 12 Dec 2017 11:04:58 +0000 (UTC) (envelope-from madpilot@FreeBSD.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 BA2A0765BC for ; Tue, 12 Dec 2017 11:04:58 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id B9865E94427; Tue, 12 Dec 2017 11:04:58 +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 B92D0E94426 for ; Tue, 12 Dec 2017 11:04:58 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 80C15765BB for ; Tue, 12 Dec 2017 11:04:57 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3ywxml4VTFzZvq; Tue, 12 Dec 2017 12:04:55 +0100 (CET) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id YINGeXk250yE; Tue, 12 Dec 2017 12:04:50 +0100 (CET) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.madpilot.net (Postfix) with ESMTPSA; Tue, 12 Dec 2017 12:04:50 +0100 (CET) Subject: Re: XBOX/i386 and xlint removal To: Konstantin Belousov , current@freebsd.org References: <20171109135221.GB4550@kib.kiev.ua> From: Guido Falsi Message-ID: <95fe7a83-c464-a0dd-5b78-5d0b6e89cec4@FreeBSD.org> Date: Tue, 12 Dec 2017 12:04:49 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171109135221.GB4550@kib.kiev.ua> 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, 12 Dec 2017 11:04:58 -0000 On 11/09/2017 14:52, Konstantin Belousov wrote: > Hello, > I created two reviews to axe two features which I personally find of > little use in modern FreeBSD. > > https://reviews.freebsd.org/D13015 xlint Hi, I just discovered that this change brakes building a pre change system (using nanobsd scripts for example) from head. The sources before this change expect lint to be present and actually use it I have worked around this by commenting out xlint from the build in the 11.1 sources, since I don't need it. Maybe simply defining LINT="" would work too. (I'll test this approach later) I have no need for xlint and have no objection to it's removal, but loosing the ability to build older source trees from head looks wrong. Don't know if modifying older branches to cope with the lint command not being present is a viable option. -- Guido Falsi From owner-freebsd-current@freebsd.org Tue Dec 12 11:10: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 9B460E946C0 for ; Tue, 12 Dec 2017 11:10:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-169.reflexion.net [208.70.210.169]) (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 5C09876985 for ; Tue, 12 Dec 2017 11:10:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2325 invoked from network); 12 Dec 2017 11:10:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 11:10:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 06:10:36 -0500 (EST) Received: (qmail 11924 invoked from network); 12 Dec 2017 11:10:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 11:10:36 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D0258EC8B7B; Tue, 12 Dec 2017 03:10:35 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot Message-Id: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> Date: Tue, 12 Dec 2017 03:10:34 -0800 To: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current 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: Tue, 12 Dec 2017 11:10:44 -0000 I initially jumped from -r326192 to -r326726 and ended up with a rpi2 that would normally hang somewhere around release APs being displayed. (I have had a couple of completed boots but many dozens of hung-up attempts.) Both a debug kernel and a non-debug kernel hang the same way. Bisecting the kernel (holding world -r326726 constant) showed: -r326346 did not hang (nor did before) -r326347 and later hung. Conclusion: -r326347 changes are involved in the boot hangups. Context: head -r326726 based (from before I did the bisect). My knowledge is limited so I may not have picked optimal material to get from the db> prompt. It appears that the messages about "random" occur during the hang (indefinite wait). As I remember, I have seen examples where the "Trying to mount" did not show up --but normally it did. And example from a hung boot: . . . Release APs Trying to mount root from ufs:/dev/ufs/RPI2rootfs [rw,noatime]... random: unblocking device. arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache The hang never seems to time out but just sits there, even for hours. It allows the ~^B sequence to get to the db> prompt. I've looked around a little a couple of times. One common point is that show allchains has everything listed as sleeping except: chain 32: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100077 (pid 23, uma) is on a run queue chain 33: (Note: uma's thread number has varied, as has the one for [pagedaemon].) bd> ps pid ppid pgrp uid state wmesg wchan cmd 28 0 0 0 DL syncer 0xc095a31c [syncer] 27 0 0 0 DL vlruwt 0xd7417730 [vnlru] 26 0 0 0 DL psleep 0xc0959c00 [bufdaemon] 25 0 0 0 RL [bufspacedaemon] 24 0 0 0 DL psleep 0xc095e8f8 [vmdaemon] 23 0 0 0 RL (threaded) [pagedaemon] 100065 RunQ [pagedaemon] 100076 D launds 0xc095e804 [laundry: dom0] 100077 RunQ [uma] . . . 1 0 0 0 DL umadrai 0xc095e528 [kernel] 0 0 0 0 RLs (threaded) [kernel] 100000 D swapin 0xc09673c8 [swapper] . . . 100072 D - 0xd75b7e80 [if_io_tqg_1] 100073 RunQ [if_io_tqg_2] 100074 D - 0xd75b7d80 [if_io_tqg_3] 100075 D - 0xd75b7d00 [if_config_tqg_0] 100078 D - 0xd83dc100 [softirq_0] 100079 D - 0xd75b7c00 [softirq_1] 100080 RunQ [softirq_2] 100081 D - 0xd75b7b00 [softirq_3] (Which if_io_tqg_ and softirq_ pair has RunQ varies.) All RunQ's are shown above. One or two [idle: CPU]'s have state CanRun and the other [idle: CPU]'s have state RUN. They are the only items with those states. Example from the same hangup: 10 0 0 0 RL (threaded) [idle] 100002 Run CPU 0 [idle: cpu0] 100003 Run CPU 1 [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 CanRun [idle: cpu3] db> show lock 0xc095e528 class: sx name: umadrain state: XLOCK: 0xd6cbe740 (tid 100077, pid 23, "uma") waiters: shared db> show thread 100001 Thread 100001 at 0xd40a7000: proc (pid 1): 0xd40a3000 name: kernel stack: 0xd40ac000-0xd40adfff flags: 0x4 pflags: 0x20000000 state: INHIBITED: {SLEEPING} wmesg: umadrain wchan: 0xc095e528 sleeptimo 0. 0 (curr 51d. = 5eac6a0400000000) priority: 84 container lock: sleepq chain (0xc0957244) last voluntary switch: 1297717 ms ago last involuntary switch: 1297809 ms ago db> show thread 100077 Thread 100077 at 0xd6cbe740: proc (pid 23): 0xd6cab000 name: uma stack: 0xd83ca000-0xd83cbfff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 84 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297815 ms ago last involuntary switch: 1297815 ms ago db> show thread 100073 Thread 100073 at 0xd7406740: proc (pid 0): 0xc09673c8 name: if_io_tqg_2 stack: 0xd742a000-0xd742bfff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 24 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297818 ms ago db> show thread 100080 Thread 100080 at 0xd7431ae0: proc (pid 0): 0xc09673c8 name: softirq_2 stack: 0xd83f5000-0xd83f6fff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 24 container lock: sched lock 2 (0xc0952640) last voluntary switch: 1297816 ms ago db> show lock 0xc0952640 class: spin mutex name: sched lock 2 flags: {SPIN, RECURSE} state: {UNOWNED} db> show lock 0xc0957244 class: spin mutex name: sleepq chain flags: {SPIN, RECURSE} state: {UNOWNED} db> show thread 100065 Thread 100065 at 0xd6cbb000: proc (pid 23): 0xd6cab000 name: pagedaemon stack: 0xd7403000-0xd7404fff flags: 0x14 pflags: 0x20200000 state: RUNQ priority: 84 container lock: sched lock 1 (0xc0951f80) last voluntary switch: 1029 ms ago last involuntary switch: 28606 ms ago db> show lock 0xc0951f80 class: spin mutex name: sched lock 1 flags: {SPIN, RECURSE} state: {UNOWNED} =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Dec 12 15:58:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7A6AE9CF75 for ; Tue, 12 Dec 2017 15:58:19 +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 7E21A39E0 for ; Tue, 12 Dec 2017 15:58:19 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x229.google.com with SMTP id r6so25345076itr.3 for ; Tue, 12 Dec 2017 07:58:19 -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; bh=L4bGfW6Reo44xyGE7EwmXus97N9RESkstlNUcShTEj8=; b=osEJS2th41xOjbhZ4JSnZ+vXlFilt4KoUcVAJhqtNwyaZGZh4imh4kAE5IYpSh+gbK ifYjOXuUi9bXi1ft9DQ9J+SjmBtDUxLvtW+I76qLDjVft29iXsvJqvZ9wsvW3nvnNQ0T 0cH/gzYajZG6tR+pRuywD54xjRFDiP80+MqDMhcF4nCNMFeAVjdUWWjiBzr8aPFpa+G+ AeBFhydmhEadKpBsotzPp3ay2958+02Rkysed/5z5tYW4gJF0VmUhq+wGrYN1r3NsTYs gTDgk8rNSA6mvRjq7uEo3zJb6WT//KHFNk5DJCKUmzBFZfGNtzKJEEdSxSvet0m6MvEZ 4Uxw== 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; bh=L4bGfW6Reo44xyGE7EwmXus97N9RESkstlNUcShTEj8=; b=C6GToBOxsydKh42Qyx8R6hsz2frOrnnMOJZXm2dII4ZoUn2SdsjdrMBbGh6Ysme+cu bhC4W/QcFLt+NXbuCA6HYlcx2sPmssGFKPVr/kvaRAonvrDrKmODVo829BxMOze2Wguc Ui6E/DzZCaDPSw7tHDupL01o9kMfG1U+R1B5RiQ8NkQskD69x35eC4XPh9+OEk12M0WV ZrTY7kF0Aahim0Pq5p2YF4w7YwMo8VdEMWmkyA2jnHjfqCr4QgCzTNxHdYlQ+ANUMgAP VJi8UBBJjWeqkVNTHhFyTXYvkj4OVhSEcivdCisKH2/oMUm0KQ6ChFgIScEu87mCHcZo E/rg== X-Gm-Message-State: AKGB3mLOmNIpXw16Gi+3dWKwwHara8SvIpCOg8f0NM6Txmf/bsSlXzKL Kbz9xipWD82Xa47KNbCZQf9md5XEgZNaQCvLfPk+4Q== X-Google-Smtp-Source: ACJfBos3e4lG+CEy6Q/NCGXqshELSPIywSmEfnJNf3qiWAQZeZbVDijVrOJpwYaLrFTOn1Kw29MXHbThkCMzjxEOuyM= X-Received: by 10.36.67.141 with SMTP id s135mr76417itb.149.1513094298316; Tue, 12 Dec 2017 07:58:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Tue, 12 Dec 2017 07:58:17 -0800 (PST) In-Reply-To: References: From: blubee blubeeme Date: Tue, 12 Dec 2017 23:58:17 +0800 Message-ID: Subject: Re: get_swap_pager(x) failed 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: Tue, 12 Dec 2017 15:58:19 -0000 On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme wrote: > I am seeing tons of these messages while running tail -f /var/log/messages > ============ > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(22): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(11): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(8): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(6): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(21): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(19): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(32): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(18): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(9): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(3): failed > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(20): failed > ========== > > running top and sorting by size I have this output: > =========== > last pid: 15976; load averages: 0.62, 0.92, 0.94 > > > up 1+03:41:32 15:31:28 > 119 processes: 1 running, 117 sleeping, 1 stopped > CPU: 1.5% user, 1.8% nice, 1.5% system, 0.4% interrupt, 94.8% idle > Mem: 3442M Active, 293M Inact, 4901M Laundry, 22G Wired, 1057M Free > ARC: 18G Total, 1488M MFU, 15G MRU, 4003K Anon, 178M Header, 1171M Other > 16G Compressed, 23G Uncompressed, 1.41:1 Ratio > Swap: 2048M Total, 2028M Used, 20M Free, 99% Inuse, 36K In > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 1118 blubee 1 20 0 24756M 102M select 3 122:30 2.62% Xorg > 15960 blubee 1 20 0 22693M 248M select 0 0:01 0.65% urxvt > 2369 blubee 1 20 0 11411M 10152K select 5 0:02 0.00% urxvt > 13251 blubee 1 20 0 11405M 245M select 0 0:03 0.00% urxvt > 1545 blubee 1 20 0 11405M 244M select 3 0:03 0.00% urxvt > 4182 blubee 1 20 0 11405M 248M select 1 0:12 0.00% urxvt > 3826 blubee 1 20 0 11405M 246M select 6 0:03 0.00% urxvt > 1165 blubee 1 20 0 11401M 15244K select 1 0:03 0.00% urxvt > 15316 blubee 63 20 0 2067M 630M select 5 15:39 0.02% > firefox > 1419 blubee 18 20 0 1989M 263M uwait 4 5:29 0.00% > chrome > 15392 blubee 37 20 0 1934M 572M select 7 7:47 1.41% > firefox > 15320 blubee 40 20 0 1829M 440M select 6 3:30 0.00% > firefox > 15323 blubee 37 20 0 1797M 418M select 7 1:05 0.02% > firefox > 1543 blubee 17 25 5 1695M 794M uwait 1 38:13 0.93% > chrome > 1370 blubee 6 23 0 1482M 982M select 6 57:09 7.78% > chrome > 1368 blubee 30 22 0 1307M 468M select 4 78:18 7.79% > chrome > 2338 blubee 14 20 0 1137M 334M uwait 3 10:38 0.52% > chrome > 2481 blubee 21 26 5 1090M 345M uwait 6 7:14 16.00% > chrome > 3646 blubee 13 25 5 889M 294M uwait 2 0:20 0.00% > chrome > 2679 blubee 13 25 5 840M 268M uwait 4 9:24 1.30% > chrome > 2707 blubee 14 25 5 835M 127M uwait 2 3:07 0.02% > chrome > 3661 blubee 13 25 5 796M 244M uwait 7 0:20 0.06% > chrome > 2755 blubee 14 25 5 770M 84492K uwait 0 0:39 0.02% > chrome > 1661 blubee 15 20 0 766M 166M uwait 5 1:06 0.00% > chrome > 1418 blubee 13 20 0 753M 147M uwait 5 1:24 0.00% > chrome > 3850 blubee 13 25 5 747M 176M uwait 5 1:58 0.05% > chrome > 13392 blubee 13 25 5 746M 161M uwait 1 0:30 0.00% > chrome > 13329 blubee 13 25 5 741M 146M uwait 0 0:18 0.00% > chrome > 2352 blubee 13 25 5 727M 98888K uwait 0 2:34 0.00% > chrome > 13389 blubee 13 25 5 726M 169M uwait 1 0:10 0.00% > chrome > 3600 blubee 14 25 5 713M 124M uwait 0 0:22 0.00% > chrome > 1415 blubee 12 20 0 704M 127M uwait 2 0:17 0.01% > chrome > 13346 blubee 13 25 5 688M 123M uwait 4 0:06 0.00% > chrome > 13368 blubee 13 25 5 686M 142M uwait 7 0:09 0.00% > chrome > 15394 blubee 13 25 5 685M 161M uwait 7 0:44 0.00% > chrome > 2501 blubee 13 25 5 684M 83776K uwait 3 0:11 0.00% > chrome > 1662 blubee 13 20 0 684M 128M uwait 5 0:31 0.01% > chrome > 3586 blubee 13 25 5 677M 89896K uwait 5 0:21 0.01% > chrome > 13327 blubee 13 25 5 673M 129M uwait 4 0:05 0.00% > chrome > 3961 blubee 13 25 5 670M 118M uwait 1 0:05 0.00% > chrome > 15956 blubee 13 20 0 670M 169M uwait 6 0:03 0.00% > chrome > 13359 blubee 13 25 5 667M 129M uwait 7 0:14 0.01% > chrome > 13274 blubee 13 25 5 663M 118M uwait 5 0:11 0.00% > chrome > 3848 blubee 13 25 5 662M 115M uwait 6 0:03 0.00% > chrome > 4166 blubee 13 25 5 661M 118M uwait 7 0:18 0.00% > chrome > 1673 blubee 13 25 5 659M 128M uwait 1 17:48 1.19% > chrome > 13387 blubee 12 25 5 658M 123M uwait 1 0:08 0.00% > chrome > 1417 blubee 14 20 0 658M 107M uwait 0 0:15 0.01% > chrome > 1416 blubee 13 20 0 642M 106M uwait 4 0:12 0.00% > chrome > 3587 blubee 13 25 5 642M 93292K uwait 3 0:12 0.00% > chrome > 13364 blubee 13 25 5 626M 96468K uwait 7 0:02 0.00% > chrome > 3851 blubee 13 25 5 625M 94508K uwait 4 0:01 0.00% > chrome > 13540 blubee 12 25 5 618M 94384K uwait 3 0:03 0.00% > chrome > 1231 blubee 12 20 0 576M 44900K uwait 7 0:01 0.00% > chrome > 1159 blubee 5 20 0 149M 56876K select 6 1:05 0.00% > ibus-engine-chewing > > =========== > > What's with all the swap errors? I am running ZFS and I have 16GB of ram, > how could I be having swap space errors? > Well I added 4GB of extra swap in /var/tmp/swap0 then added that to my /etc/fstab: md99 none swap sw,file=/var/tmp/swap0,late 0 0 and those errors went away. From owner-freebsd-current@freebsd.org Tue Dec 12 17:26: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 353B0E9FBD1 for ; Tue, 12 Dec 2017 17:26:14 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BD9966ED9 for ; Tue, 12 Dec 2017 17:26:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x244.google.com with SMTP id e137so24056166lfg.5 for ; Tue, 12 Dec 2017 09:26: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:cc; bh=ivnxDIb0KvPok8UQ87ad5w8OwgarUADE0ae7afdo7Vw=; b=kgxbY5ySwzJQvV4B6PovWfcdGsHzLSWQDcpNSD51cg6aktL1D04drT/goqEZxhG9XE n26IYCfCrafe6Bj0MttTK66m7i+g63JtWYuA65qYS0KqaeKoZHqz3x41F5FstsJHkI2Z SilfgK6OHE+WWT5WQQDiRbz5ja2SSgzQVE9i+E8bWNxLNSHmZl16+q4pAe++qVeokuen PtIBxTNQ9OTOGF7zIbuDRM2elct+m+3o6MYZx3xQImO+c8v+T6nPI+IO9sioWC3nPor2 xpjgCGY334yrHCeOg9bKu3LxJPmzOYZgnC+mDFdsZ/IGHsSQknAoGm+rnpZl09/uFGdv w31w== 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:cc; bh=ivnxDIb0KvPok8UQ87ad5w8OwgarUADE0ae7afdo7Vw=; b=QejYYieF9Utu5eCMA3vekB+IgfH0U3bPn01MuKLwDJe+/hl63bUShJXrnBauDe7eD+ ZAO4ymtC4jNadtFo9Q8/qv5bRUgSazmfRTodQGEId4VqeuVP2v1JlZZTEQ8w5fGf0T4G IQrB9w9V/YG6Co4SP4+lUQcejoVRIzNmcayATlqWlHIf2sJckKk+HLexA2Op6Jex7p26 90URhxxfHwK6H4roJH9ZAc6hC/2i2VjySAA9tjOl/XSNxhE3AzRN4X9eSGrdDdFDATm0 IRv6Zjm/iHT+tPjfrbkBRe5DLtFhPpR2ygjPRyp6PI/FAmqjSSm7/EVjGJTH+tgYYndt Cc0A== X-Gm-Message-State: AKGB3mKCS1KYZcywMejYuFQhBAQN5xRoayA5oEEmO42r1vRG2CC5u2Ly 0MvVJIWF3DUki7y96j5pbJWX+VubkrbYPFJyjvBI3A== X-Received: by 10.46.84.86 with SMTP id y22mt2765681ljd.89.1513099570809; Tue, 12 Dec 2017 09:26:10 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 09:26:10 -0800 (PST) In-Reply-To: References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> <201712062235.vB6MZlQv034650@donotpassgo.dyslexicfish.net> From: Alan Somers Date: Tue, 12 Dec 2017 10:26:10 -0700 X-Google-Sender-Auth: DA9PJwQPopD53BO7SVWR3aVGm-M Message-ID: Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] Cc: Jamie Landeg-Jones , "freebsd-hackers@freebsd.org" , FreeBSD CURRENT , by@meetlost.com 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, 12 Dec 2017 17:26:14 -0000 On Wed, Dec 6, 2017 at 3:53 PM, Alan Somers wrote: > On Wed, Dec 6, 2017 at 3:35 PM, Jamie Landeg-Jones > wrote: > >> Alan Somers wrote: >> >> > How about just setting MANPAGER=less in your environment? >> >> Because some of us prefer "more"? >> >> And as I said, it's related to searching using the more(1) command >> generally. >> >> I was under the impression that fixing bugs in existing commands was a >> better >> solution than telling someone to simply use something else. >> > > Yes, it certainly is. Are you sure this is actually a bug in less, or is > it just weird-but-intended behavior when less is emulating some old version > of more? It would be worth comparing our less sources to upstream's to see > what differences have crept in, and svn blaming them to see why. > I finally traced down the origin of this weird behavior. It dates from FreeBSD r60816, which imported NetBSD's r1.6 (from CVS), which fixed NetBSD PR 227. While your patch fixes the problem by@meetlost.com reported, it regresses the problem described by PR 227. So I don't think we can commit it as-is. http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/less/less/Attic/forwback.c.diff?r1=1.5&r2=1.6&only_with_tag=MAIN&f=h https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=227 For reference, I'll restate a reproduction case for PR 227: 1) Size your terminal to 25 lines 2) jot 20 > ~/tmp/20lines.txt 3) jot 100 120 1 > /tmp/20lines.2.txt 4) more /tmp/20lines.* 5) At the prompt, press spacebar to display the second file. The first file should remain in the scrollback buffer. -Alan From owner-freebsd-current@freebsd.org Tue Dec 12 18:04: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 5781BEA0C71 for ; Tue, 12 Dec 2017 18:04:03 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCE706899E for ; Tue, 12 Dec 2017 18:04:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id 74so24216583lfs.0 for ; Tue, 12 Dec 2017 10:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=amPeodn3QOcccWlyYYp3V3EftoTGZ4irs9nPArgMt0I=; b=p5KKdI8l+UJKgQ6kN0FoFsv3dB5FhUoC7xmPGzseNutcdw0c5VZiQoBFH/B8G8E3DK 8aEHjhT1r/7usGCrv6f0i0dVGeXty004i7iTBQ2EAFYgxZTfuIkqMfliwIXoC23JDH5c /ZB9RE60PkQh6Qw/6egLdmgO0LC+qDNTIaIrA9NzETTzXxeqBGVGeCTE2xKMhgaB17Tk YubWWHaUaVVhSnlb/dVwglTVORjDoyl3HxV5N8ftnmHPmQsG0WwNo6ma5Hkh4+KBmTD2 Pk7KwJQE09aUO4IjtlNHf4urt30iAMVc4fzAnPFeFmMEvlaljVaGAmT/dzYiUb/abhWI HGpg== 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:from:date:message-id:subject :to:cc; bh=amPeodn3QOcccWlyYYp3V3EftoTGZ4irs9nPArgMt0I=; b=NJzaHBb6YTIgrpNh1RvdAE6tVuI0Evvn9MsaZraZxDFm0w4sGxm0YJRl0cR+csLQw7 p3Yl+EnLcIfN5WctKvgc3i3EiVEX5+CjCY6UXXNfWGVRWhGJBRA1lCZZZIaoqDEsP0vh ZwMxBzBOQhHEs/fypvF5G+imxwJCC1sxXb//UP+jV56vVhxKjkHEexxdTWU5n8SuUQs4 761g02AfP5aLRmVRHt/tULfozGPtkAsKhdySZBoKiJnnuXHIdK6mJUvzP9BgQzxf41zj qokK8BodtqMK8OXY6Pbzv96AE2SJc2UFoxRsGtdHHIhHpG8TiosMPlCZO5efptVRcDKN CWPQ== X-Gm-Message-State: AKGB3mJi5CZHGwAgv6diVAzWBjsuCGW3tYKELy7gQtQURBBn32ABT6Bo cIBHHSfN0kpkCvf7WpdYg2vYFs+6o6SA0KfE1HkT/g== X-Google-Smtp-Source: ACJfBouTJNjCw7R9v/61LDklWWbZoTlUyoqGfkYwtYxVDBi4qg2KX8tRAXiNi2o0QD9d96xbuKUGwl8NmKELRWyXYIw= X-Received: by 10.25.16.206 with SMTP id 75mr2387914lfq.66.1513101835302; Tue, 12 Dec 2017 10:03:55 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 10:03:54 -0800 (PST) From: Alan Somers Date: Tue, 12 Dec 2017 11:03:54 -0700 X-Google-Sender-Auth: sDSe6_QgPytsVdxEYKpjGb5119I Message-ID: Subject: Poll: should man(1)'s default pager change to "less -s"? To: FreeBSD CURRENT Cc: Jamie Landeg-Jones , by@meetlost.com 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, 12 Dec 2017 18:04:03 -0000 Should man(1)'s default pager change to "less -s"? Vote and flame at the Phabricator link below. https://reviews.freebsd.org/V7 -Alan From owner-freebsd-current@freebsd.org Tue Dec 12 18:15:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E1E0EA1680 for ; Tue, 12 Dec 2017 18:15:35 +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 6E73969646; Tue, 12 Dec 2017 18:15:35 +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 vBCIFAGi074271 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Dec 2017 10:15:10 -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 vBCIFAC4074270; Tue, 12 Dec 2017 10:15:10 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Dec 2017 10:15:10 -0800 From: Steve Kargl To: Alan Somers Cc: FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com Subject: Re: Poll: should man(1)'s default pager change to "less -s"? Message-ID: <20171212181510.GA74215@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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, 12 Dec 2017 18:15:35 -0000 On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: > Should man(1)'s default pager change to "less -s"? Vote and flame at the > Phabricator link below. > > https://reviews.freebsd.org/V7 > Does not work. Unhandled Exception ("AphrontMalformedRequestException") Your browser did not submit a "phcid" cookie with client state information in the request. Check that cookies are enabled. If this problem persists, you may need to clear your cookies. Of course, I don't have an account on https://reviews.freebsd.org/ -- Steve From owner-freebsd-current@freebsd.org Tue Dec 12 18:19: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 8AD5DEA19A9 for ; Tue, 12 Dec 2017 18:19:24 +0000 (UTC) (envelope-from asomers@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 0CB3A69ABB for ; Tue, 12 Dec 2017 18:19:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id r143so24226255lfe.13 for ; Tue, 12 Dec 2017 10:19:23 -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=Mc56nnlJpHahjiEjOUPPMhU8Sbjrif1IobC8n/wEaIY=; b=Kmy4fbnY+wOB3+qetY5eEgKsgHFfvgsAUwMaYMAPnMiYjeidyQB1i/mqMmd4rQUXAY CXdV17HZnDNXXdTNR6JBBgiV8MqgzgrTawCx9HwHTYW7jsuB6G75TsALEI8O92quxxU4 /2rqLx39ksZ1P0/cPijmR3o/ctIHPsZARlpc0uGrpN3ts6dxRxxHD3rJuRxTTY/uzZ/T 2Qt02N/SFmUUxrcmsn1IEfIUTyJoD+LX0e0owKRMGxoxV0B9CgxW6mICCnDsjr4Z+PyC b+nJyTk9GSmiysh/F6IC8SG4PWlZOqYx+IVDTnoVc/nGHZY0jb0GGZiiERaOa77ufLqi gN7Q== 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=Mc56nnlJpHahjiEjOUPPMhU8Sbjrif1IobC8n/wEaIY=; b=Xm2lyL0TGi7ljnFy+SrHtqzfIM3w842Xnq2xsPXc+C7F+XrCMtcR2wQXzTTb+HKKKp +WViNWrHTPzkCJbhDmmTt/+jyOruZ3kR+LqLL5l8Lwq1Bj5lOaxjfMSCgPXNgFrC4lgP 4cFPKNdm2rlYBrDCR4+MhpKwB96TgJJQj/6VsQt6//R6Xz2XlHg77Nr7UVzcgK6GkWDt AWCmOsurUSe2PinqOftrgorOFuN+QXKZKvEVahluTCXvGZ4YlB3fvY5MwZ3AfmmWh9IN /5EDJlS5XIrAnKg/6AQmdoWdjltl4cY88G61iIdw6H83XBOT+1ePJ+O00XdojKMXPcEL MqKg== X-Gm-Message-State: AKGB3mL28EDyd4ynZWOb1Ju1r+3sfE1pBtUijHf+rtUW6+cUCbLCJi8b cHl8ktHtgAPvXIdxiwH6IrzT5dDBdwdFiEteQus= X-Google-Smtp-Source: ACJfBotT44MT2YmnRawOCM8D+0zxF7GfkwbnYBUVoEqXUhLYbfPuxnrOXCIDg4ioDGIr4akcIbj3TuZDqftIyqZbzgQ= X-Received: by 10.46.84.86 with SMTP id y22mr2652682ljd.89.1513102762031; Tue, 12 Dec 2017 10:19:22 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 10:19:21 -0800 (PST) In-Reply-To: <20171212181510.GA74215@troutmask.apl.washington.edu> References: <20171212181510.GA74215@troutmask.apl.washington.edu> From: Alan Somers Date: Tue, 12 Dec 2017 11:19:21 -0700 X-Google-Sender-Auth: IxBVezahdPKqo9Fh2be6QQmporA Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: sgk@troutmask.apl.washington.edu Cc: FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com 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, 12 Dec 2017 18:19:24 -0000 On Tue, Dec 12, 2017 at 11:15 AM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: > > Should man(1)'s default pager change to "less -s"? Vote and flame at the > > Phabricator link below. > > > > https://reviews.freebsd.org/V7 > > > > Does not work. > > Unhandled Exception ("AphrontMalformedRequestException") > Your browser did not submit a "phcid" cookie with client state > information in the request. Check that cookies are enabled. > If this problem persists, you may need to clear your cookies. > > Of course, I don't have an account on https://reviews.freebsd.org/ > > -- > Steve > You can direct questions like this to phabric-admin@FreeBSD.org . From owner-freebsd-current@freebsd.org Tue Dec 12 18:22: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 9E721EA1D2C for ; Tue, 12 Dec 2017 18:22:36 +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 17B3469FED for ; Tue, 12 Dec 2017 18:22:35 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.182.112.82]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Me8di-1efuU12t2M-00PwKX for ; Tue, 12 Dec 2017 19:22:27 +0100 Date: Tue, 12 Dec 2017 19:21:53 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error Message-ID: <20171212192220.119ca2d3@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_/MAPZTDQbOAZbQS7jpzj0YDm"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:lDNfAEM+uLEY3ncTXOUdlBMDhDGn0Gi5BGy68q5qxW1hRN8rDwJ 3mFuIaXSa8af+C2e8FhXE05PpkaNNFe9NbVfHEA2PyEFgSRtWUbp++Pr1QCQt+MOtVO6RKS I1amIj9klTliQGSJXOUMfgs2TOuRa7bjYf9xO8oFc/1UYdcuUWZW9ob+i5uA2f851sarql1 63R1dXZLvGAJ6y0ZJIOLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:hoSxMlyodDI=:HC0HtVJ0PdftgKyzQn18TF gFEyXS5yciZ7AxB62uaHMJmPZS4VfSmTIiZOHN86A6GjdRFGZADOpaZSIiUajG66VZpQwtuB+ r7TaEJZIrEqzhepfa5sUKnAQy+UsHWPbJ7+jiADRYcrtHNp2NTFryFIBiEamv63zAKxnyKu/q l6tGug6EzntCU9ByatFziTAvpCW/Vbw9fNuL0NiNnf9kllOJxeBbRzCfLkOCouXvwnT9S+r3m i89ZXEmaNEG6V+K0uPlTQEUFJfG1bB54yBiKfveGBHiRuLLaY/d07e0qWbVUIpEp4VrmWqrbo UdeFWewavpnDj6OI7yizlKiw4sBqK00P2mKAn7zydvtGfW7M2S0fwQnK3/l9QHE8C8ZzrQ9Ef l4SFKBhJQiVumuczxmlNe5lm8ihiYNJkpZCUzjoAJd5fOMHwTAlHa9/Z8QIDTECIkUhC64wgf y5QZZ9dA9r8vdb64PrXwKe5/PNBWryFawZhD1AZkSZXYUf3jJswUmwDonlS21Zrl3i9hHMrVE IXKKVem091QcfFHkgeiHpYqCyEljYL/HNPA3YgVhSiGeLdEme2bBsM+GpIb1GhRwlhgbd2VVg NgSQj6kyvP2DQ5lIpfOAesagWmIxq1BMnssuIimd3N9z/iEVaxJvXNVjJidPv8JU2Mi89V4pp F6ZoP5zRvikCC5HdCmRMN7tqBs3NcfHxmIpxD9UVYlzLeDmXc6LWQap8bmnswGaWLk/34Mgvp yrPSLa3mA9N4bMC+k68S5F58RLkoiQnTbur96jb3vJdhZbLXVXGxO5KFboQaWcecoV0bAQXoL xXSgkKWSMd73665zzcp3FSz1F/rKg== 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, 12 Dec 2017 18:22:36 -0000 --Sig_/MAPZTDQbOAZbQS7jpzj0YDm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, running CURRENT (recent r326769), I realised that smartmond sends out some = console messages when booting the box: [...] Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currently un= readable (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ad= a6, 1 Offline uncorrectable sectors [...] Checking the drive's SMART log with smartctl (it is one of four 3TB disk dr= ives), I gather these informations: [... smartctl -x /dev/ada6 ...] Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 days + = 15 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc27a7298 = =3D 3262804632 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA QUEUED 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA QUEUED 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA QUEUED [...] and [...] SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 3 Spin_Up_Time POS--K 178 170 021 - 6075 4 Start_Stop_Count -O--CK 098 098 000 - 2406 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 9 Power_On_Hours -O--CK 066 066 000 - 25339 10 Spin_Retry_Count -O--CK 100 100 000 - 0 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 194 Temperature_Celsius -O---K 122 109 000 - 28 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 1 198 Offline_Uncorrectable ----CK 200 200 000 - 1 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning [...] The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one WD RED 3 TB= HDD. The failure occured is on one of the WD Green 3 TB HDD. The pool is marked as "resilvered" - I do scrubbing on a regular basis and = the "resilvering" message has now aapeared the second time in row. Searching th= e net recommend on SMART attribute 197 errors, in my case it is one, and in combi= nation with the problems occured that I should replace the disk. Well, here comes the problem. The box is comprised from "electronical waste= " made by ASRock - it is a Socket 1150/IvyBridge board, which has its last Firmware/B= IOS update got in 2013 and since then UEFI booting FreeBSD from a HDD isn't possible (just= to indicate that I'm aware of having issues with crap, but that is some other issue rig= ht now). The board's SATA connectors are all populated. So: Due to the lack of adequate backup space I can only selectively backup = portions, most of the space is occupied by scientific modelling data, which I had worked o= n. So backup exists! In one way or the other. My concern is how to replace the faulty HD= D! Most HowTo's indicate a replacement disk being prepared and then "replaced" via = ZFS's replace command. This isn't applicable here. Question: is it possible to simply pull the faulty disk (implies I know exa= ctly which one to pull!) and then prepare and add the replacement HDD and let the system d= o its job resilvering the pool? Next question is: I'm about to replace the 3 TB HDD with a more recent and = modern 4 TB HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the oth= er disks are 3 TB, but I'd like to know whether FreeBSD's ZFS is capable of handling it?=20 This is the first time I have issues with ZFS and a faulty drive, so if som= e of my questions sound naive, please forgive me. 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_/MAPZTDQbOAZbQS7jpzj0YDm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjAeXAAKCRDS528fyFhY lI+BAf0XT3r8xc0Q7Sk907xI7WlEieVKtoQAGh675oWEUMMSDXWHhTpJNjcqfLfJ 8L1cerPxaJs935Kx9HO/pPDB1chdAf9QExo1rzvExWa7LKU0xKLig3Z9+kCytwdh avY+STsj2LSW7DJZqUq7H74oLv5wA4XVWakchMR8ffTux93f124p =ZXU2 -----END PGP SIGNATURE----- --Sig_/MAPZTDQbOAZbQS7jpzj0YDm-- From owner-freebsd-current@freebsd.org Tue Dec 12 18:27: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 96073EA1F76 for ; Tue, 12 Dec 2017 18:27:31 +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 777A66A222; Tue, 12 Dec 2017 18:27:31 +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 vBCIRJDM074534 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Dec 2017 10:27:19 -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 vBCIRJOK074533; Tue, 12 Dec 2017 10:27:19 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Dec 2017 10:27:19 -0800 From: Steve Kargl To: Alan Somers Cc: FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com Subject: Re: Poll: should man(1)'s default pager change to "less -s"? Message-ID: <20171212182719.GA74524@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20171212181510.GA74215@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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, 12 Dec 2017 18:27:31 -0000 On Tue, Dec 12, 2017 at 11:19:21AM -0700, Alan Somers wrote: > On Tue, Dec 12, 2017 at 11:15 AM, Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > > > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: > > > Should man(1)'s default pager change to "less -s"? Vote and flame at the > > > Phabricator link below. > > > > > > https://reviews.freebsd.org/V7 > > > > > > > Does not work. > > > > Unhandled Exception ("AphrontMalformedRequestException") > > Your browser did not submit a "phcid" cookie with client state > > information in the request. Check that cookies are enabled. > > If this problem persists, you may need to clear your cookies. > > > > Of course, I don't have an account on https://reviews.freebsd.org/ > > > > You can direct questions like this to phabric-admin@FreeBSD.org . There isn't a question. I'm pointing out your poll apparently is limited to a select few individuals that use FreeBSD. -- Steve From owner-freebsd-current@freebsd.org Tue Dec 12 18:38:46 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 3C046EA2520 for ; Tue, 12 Dec 2017 18:38:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A51316ABDB for ; Tue, 12 Dec 2017 18:38:45 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id 74so24329294lfs.0 for ; Tue, 12 Dec 2017 10:38:45 -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=OtGSpkgV7o/2q46GAthKy0l2ir4tnxxOBm3g9dogjlA=; b=eUytXJSa5/xAd3K+eG+NslNKwoedXKf+pR358MaIipkXBK6T9nGWBeugaCbXQvCN2P 9ht8NXmNlPELLBLbcdtCb2thZwcX+xgjUgW2a6ZWgO9xju+t0+9kVjI9erlxEaS1QAKV vGdQg43kmU2dsWa+tuzglgQDNjz9LLrn/8Eb+MxA2mCk7GlwBx/YtzhHnYBKrMa8xuVf CKoGRxEYJsORCQT11ERptaj7nSJ0OnM2hk9iofqmAuB4J8EzOqsALFTdqfFqSNB3c85I QYEns4FcVWahAJ1sIXoNPsmv+Pz2vKwHUHPyeizg7Hr4BPmMlRpJq3YfwO/SHKMATcl+ bcOg== 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=OtGSpkgV7o/2q46GAthKy0l2ir4tnxxOBm3g9dogjlA=; b=UG7gGD9gJco04lMqKVQaU3c7j5q9ESEdKcu4Iy/x/pqqEf2UBaRs/fSQmYpXI0Rf1M Ye+Fds47OF/mUvLXsEw6GfpMoItjqKh1TUTGkyZI174S+xeYkhnI8xHq6vG/A01meVPO oVEYEcysuTLaucuyBaSNoeAcGDqLXFbzZai7xiDjP7cW6QRjneZE68HXVy61y1sTZOK8 yhBcJGyQPEbHhpDw7QKYqS4MnngBD7J9+fEvk18vfevNTejVTeS/aFO4KHfH6/D3fNY8 jzAtqFbi2MgFn6vXOidlwFaF3InwfC2/VKYxxh+GoqjLXQT8X+19u6fx+XtUnaFkKQgg jNBA== X-Gm-Message-State: AKGB3mIBrhbc8mHdvAVoWlHyMYJ7BiJBTZ5tnkYgUxxUeN38TUyMaMZf d/xNR8Odoc3SVnBLS0abWuKE4tYKyYOoxCFw7iM= X-Google-Smtp-Source: ACJfBos+PpgCpU1oup1QJ17gbsQgehkV3j56/7hA2TWxH59pSWh6/m1f6M5nGLxK/582oLokZ1na4igToS9CNdfi5+I= X-Received: by 10.25.16.206 with SMTP id 75mr2443027lfq.66.1513103923665; Tue, 12 Dec 2017 10:38:43 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 10:38:43 -0800 (PST) In-Reply-To: <20171212192220.119ca2d3@thor.intern.walstatt.dynvpn.de> References: <20171212192220.119ca2d3@thor.intern.walstatt.dynvpn.de> From: Alan Somers Date: Tue, 12 Dec 2017 11:38:43 -0700 X-Google-Sender-Auth: DULHzvuvKe6aD5Z_lFRx8xzZZT4 Message-ID: Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error To: "O. Hartmann" Cc: 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, 12 Dec 2017 18:38:46 -0000 On Tue, Dec 12, 2017 at 11:21 AM, O. Hartmann wrote: > Hello, > > running CURRENT (recent r326769), I realised that smartmond sends out some > console > messages when booting the box: > > [...] > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currently > unreadable > (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: > /dev/ada6, 1 > Offline uncorrectable sectors > [...] > > Checking the drive's SMART log with smartctl (it is one of four 3TB disk > drives), I > gather these informations: > > [... smartctl -x /dev/ada6 ...] > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 days + > 15 hours) > When the command that caused the error occurred, the device was active > or idle. > > After command completion occurred, registers were: > ER -- ST COUNT LBA_48 LH LM LL DV DC > -- -- -- == -- == == == -- -- -- -- -- > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = > 3262804632 > > Commands leading to the command that caused the error were: > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time > Command/Feature_Name > -- == -- == -- == == == -- -- -- -- -- --------------- > -------------------- > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA > QUEUED > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA > QUEUED > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA > QUEUED > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA > QUEUED > [...] > > and > > [...] > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > 194 Temperature_Celsius -O---K 122 109 000 - 28 > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning > > [...] > > The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one WD RED 3 > TB HDD. The > failure occured is on one of the WD Green 3 TB HDD. > > The pool is marked as "resilvered" - I do scrubbing on a regular basis and > the > "resilvering" message has now aapeared the second time in row. Searching > the net > recommend on SMART attribute 197 errors, in my case it is one, and in > combination with > the problems occured that I should replace the disk. > > Well, here comes the problem. The box is comprised from "electronical > waste" made by > ASRock - it is a Socket 1150/IvyBridge board, which has its last > Firmware/BIOS update got > in 2013 and since then UEFI booting FreeBSD from a HDD isn't possible > (just to indicate > that I'm aware of having issues with crap, but that is some other issue > right now). The > board's SATA connectors are all populated. > > So: Due to the lack of adequate backup space I can only selectively backup > portions, most > of the space is occupied by scientific modelling data, which I had worked > on. So backup > exists! In one way or the other. My concern is how to replace the faulty > HDD! Most > HowTo's indicate a replacement disk being prepared and then "replaced" via > ZFS's replace > command. This isn't applicable here. > > Question: is it possible to simply pull the faulty disk (implies I know > exactly which one > to pull!) and then prepare and add the replacement HDD and let the system > do its job > resilvering the pool? > Absolutely. If you don't know which disk to pull, then it's better to power down and check serial numbers. After you power back on, you can replace the disk with a command like this: zpool replace The missing disk guid can be obtained, after removing the old disk, by "zpool status". > > Next question is: I'm about to replace the 3 TB HDD with a more recent and > modern 4 TB > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the > other disks are 3 > TB, but I'd like to know whether FreeBSD's ZFS is capable of handling it? > Yes. ZFS will have no problem using the first 3TB of a 4TB drive. However, you ought to check the disk's physical sector size. If the old disks had 512B physical sectors and the new disk has 4096B physical sectors, then performance will suffer. You can check by using the command "diskinfo -v /dev/daXXX". Look for the "stripesize" row. > > This is the first time I have issues with ZFS and a faulty drive, so if > some of my > questions sound naive, please forgive me. > > Thanks in advance, > > Oliver > -Alan From owner-freebsd-current@freebsd.org Tue Dec 12 18:41:28 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 DE6A0EA284A for ; Tue, 12 Dec 2017 18:41:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 666976B00B for ; Tue, 12 Dec 2017 18:41:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id f20so24342605lfe.3 for ; Tue, 12 Dec 2017 10:41:28 -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=XKQnMla8PyfElv4IJp2z4Zcr5/wIxDhiDA4VTNQd6mg=; b=RiN9vwy7CnMEPrfos9j9Dnc0kNVw0FJiBfGIub3ICpXV3/2JvLgcmq+x71Bj54YJ3M xoMKyI2pnO7b3nYRw+5bkb5Vp1YYawcJElpMj9yy43wDRV6EaWyqcVGS0ulpO0fa6ixn vrLTws93XQUZOe7/fIvPGR+hfhHBbpAf4zRSH9o+J/FURzNggsQctnazyZU6s6O0X75V 5ebOYXml5x6k/sXf1fb3Wb+rAuCyTQsiwfvuQKx2lMupSocl7VIgHOxIfbZI2i8WjsD9 Vp+GBMje3lYTYkMmFawJXDc1ndoDO64r7c0ITBhb/FAgltpCWQj3PbthfPhFJpsms+yC ZZNg== 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=XKQnMla8PyfElv4IJp2z4Zcr5/wIxDhiDA4VTNQd6mg=; b=WLUuNsDPZ2R6QXTluv5SWa7dTfWiMjlL5bvxgwEnyfKVY60vA0pORMqaF0tMFjWJdj n7GrKJfx0gAPTxujGN3BsiioFSApPz1bLAzdXaJ9rwG4H5kX9vqyJSUXtEYifmiBO/rr En1IvVd4SDFcP3pe1I1H21+hFcivPzGm3eZdwF+mQWLYVbfsBzgaUdsSg8/bOeujvsZ/ AL3Md+t3paMy8j9kS8kpa+8C/rj4av/preY0VUgPIvAbBAEOpNPMeff/My64h9tQ1KbY jaKLcCUOqcqwsQPxNtxoF3U4U7WlSYougU3S2lEiHzG6aXCWTXaxbG5vmR/mdvTb0rPO Cb4Q== X-Gm-Message-State: AKGB3mJr22tS4zyz17PDV0MFiP4fANWgigVM9FvumSs0KTIijwcvtLwF 4TqxD8kGApNKE1/ov4dOB2+Zp79fMe+aNL8Td2A20g== X-Google-Smtp-Source: ACJfBov7IdEqSYEl5b+aDIh6Zy9jQq+X7XXLeXlFEhHbzEX1jAJUilYkXK0HJNNib88GJRBZHBQtCFu5iOBSXu2ts+c= X-Received: by 10.25.16.206 with SMTP id 75mr2447056lfq.66.1513104086330; Tue, 12 Dec 2017 10:41:26 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 10:41:25 -0800 (PST) In-Reply-To: <20171212182719.GA74524@troutmask.apl.washington.edu> References: <20171212181510.GA74215@troutmask.apl.washington.edu> <20171212182719.GA74524@troutmask.apl.washington.edu> From: Alan Somers Date: Tue, 12 Dec 2017 11:41:25 -0700 X-Google-Sender-Auth: pl4uSmKvUeeVG8GM-nDnzdSwaUM Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: sgk@troutmask.apl.washington.edu Cc: FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com 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, 12 Dec 2017 18:41:29 -0000 On Tue, Dec 12, 2017 at 11:27 AM, Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Tue, Dec 12, 2017 at 11:19:21AM -0700, Alan Somers wrote: > > On Tue, Dec 12, 2017 at 11:15 AM, Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: > > > > Should man(1)'s default pager change to "less -s"? Vote and flame > at the > > > > Phabricator link below. > > > > > > > > https://reviews.freebsd.org/V7 > > > > > > > > > > Does not work. > > > > > > Unhandled Exception ("AphrontMalformedRequestException") > > > Your browser did not submit a "phcid" cookie with client state > > > information in the request. Check that cookies are enabled. > > > If this problem persists, you may need to clear your cookies. > > > > > > Of course, I don't have an account on https://reviews.freebsd.org/ > > > > > > > You can direct questions like this to phabric-admin@FreeBSD.org . > > There isn't a question. I'm pointing out your poll apparently > is limited to a select few individuals that use FreeBSD. > > -- > Steve > Accounts are not limited to FreeBSD committers. Any member of the community may create one. Just fill out the form here. I'm not sure whether new account requests are moderated or not. https://reviews.freebsd.org/auth/ -Alan From owner-freebsd-current@freebsd.org Tue Dec 12 18:41: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 3EFACEA28A6 for ; Tue, 12 Dec 2017 18:41:57 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (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 0B8B06B14F for ; Tue, 12 Dec 2017 18:41:56 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f181.google.com with SMTP id t196so28752iof.0 for ; Tue, 12 Dec 2017 10:41:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Wjuj+CAAKLL/o+8kH2TvP3bnV8KPXEwKcGkk4GQkxaE=; b=sg8R83xf6OJw0Scpv/LaxTwxSsHpwQixXe/BQ8EIEolr8xHic0J4Yc0obKoJRfxftW UDxFY4lkzTgVt7fQtcnWd+LaOBCxVAlJ+Za3S3qg5TB2E1X65xEwrCDo7MwwNQmoLt+z 2ih6p/5+doXdmaSXjFqcFg33PSKjbn88jBC6LcwbF2kyeH+wuYaoeB3M/F7CHNndmcJa Q1Otep+rUfiPhzRRye87XHoe2rLYMjD9aJGHlZg5U7tbtp95BM4YbQvHw1WMR5KEW6Yp i1Q84Cvr+OdPacKViqPAxCKrxXu6m4bBl0FNv490xB2eiXRILz/yUjAHXENvy5+YtTZJ srPg== X-Gm-Message-State: AKGB3mL34GObd/dZUadCzpBSdK2bFWjN7gAgbIW0X75MqsEmUyEzFN8r VJAw9Mzjtqw1qvpQ/yBCN1ARlZjH X-Google-Smtp-Source: ACJfBotgYXwhJPz1J9F6gkRuKuSSQQ+ALoCP6V0Iy0jc8spckuLHnXxda2GP1mgOu6nB3VL5BikB5w== X-Received: by 10.107.172.4 with SMTP id v4mr6049931ioe.234.1513104110542; Tue, 12 Dec 2017 10:41:50 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com. [209.85.223.170]) by smtp.gmail.com with ESMTPSA id h101sm7802357ioi.63.2017.12.12.10.41.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 10:41:50 -0800 (PST) Received: by mail-io0-f170.google.com with SMTP id o2so28934ioe.8 for ; Tue, 12 Dec 2017 10:41:50 -0800 (PST) X-Received: by 10.107.131.99 with SMTP id f96mr6299123iod.215.1513104110010; Tue, 12 Dec 2017 10:41:50 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.165.150 with HTTP; Tue, 12 Dec 2017 10:41:49 -0800 (PST) In-Reply-To: <20171212182719.GA74524@troutmask.apl.washington.edu> References: <20171212181510.GA74215@troutmask.apl.washington.edu> <20171212182719.GA74524@troutmask.apl.washington.edu> From: Conrad Meyer Date: Tue, 12 Dec 2017 10:41:49 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: sgk@troutmask.apl.washington.edu 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: Tue, 12 Dec 2017 18:41:57 -0000 On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl wrote: > There isn't a question. I'm pointing out your poll apparently > is limited to a select few individuals that use FreeBSD. The select few individuals being "literally anyone that wants to participate?" https://reviews.freebsd.org/auth/register/ From owner-freebsd-current@freebsd.org Tue Dec 12 18:43:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AE23EA2A30 for ; Tue, 12 Dec 2017 18:43:51 +0000 (UTC) (envelope-from fjwcash@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 806086B3AA for ; Tue, 12 Dec 2017 18:43:50 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id a12so24318712lfe.4 for ; Tue, 12 Dec 2017 10:43:50 -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=psRah4aVW1AfgNCFUsryHGLjYyYCiHhm8M/LaIe3iQ0=; b=edP1dG3EUpdzwPRa2T8tb/Nrgu1hdABdi/jieEDuydYyL3DH/dZUwPH8AxxLarnvRU MliPS/fQtE3uS4XJCbgXRX4XVjQoVMENsbdI7DrrEBgCs4x8g4Q4cf91z0ypqrPudIGg K6YeR1Z6XoOkMJo0Ev/9yn6jYZmKNZg/kUiqZowcuoB8uD1dYr0QEfh1qN2J+EcJZbsD Wjl4JYX5wNpC29xDTcgdusR4a9hEJ8sOkwGAH4qBH0PXb0DDv34gONRuExYJnw/EJXh+ 2aVh/aVwFGMVpcwUY5IJ1ngyQoQ+v1Vnxm6m9vsTRJxoydFb1Ke/Yc566FUuktqNVrh7 984Q== 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=psRah4aVW1AfgNCFUsryHGLjYyYCiHhm8M/LaIe3iQ0=; b=PJgFc9e3cFy3y1zCZ2iMa4pH7QHz8QWF1vZTh7RDka1DzbAR1V6sAGYplZGLLGv/+g fd582rtPvKNA+XfOJSkRr6/GKqG0Wo0qjTDkuB+rwZmp3jIsnw0Kakc7lH/+hb1Z0LmH d3ssIktblGKhX74GYXJQBn0K2HxS8dyB3CprTMcovvcaoV0/TammCInwk4PS5jDX9beb U/g9sQW/GpqIQynfmAnibOHslj/LXwcq0s4Ej47YNmOXAtK4fXbzOJ+9uaYhvSP9dJc1 LrOjLL2RjXLYJOmHMcgqnrfAeavzONmf6Vjw3LGhVNVH+d/biZT4kHfl97bktdhYN5Gt KykQ== X-Gm-Message-State: AKGB3mI5HgJFlalKb38Ub0B+bEfrW1TEYiUKsiEch8vHokphzcSlP1Nh hsqVxOcVR2VdmtheEE4nGbpg+hzLzb9AiUl2OG4= X-Google-Smtp-Source: ACJfBouiXwX+yW+22G3yOlWukFEGV/kb1nKha6hDSWYorT6jRVrTHxPXh0BlM/64TvmyfrujrehLMkmlVt+0d1rpa+I= X-Received: by 10.25.202.14 with SMTP id a14mr2117203lfg.83.1513104228494; Tue, 12 Dec 2017 10:43:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.145 with HTTP; Tue, 12 Dec 2017 10:43:47 -0800 (PST) In-Reply-To: <20171212192220.119ca2d3@thor.intern.walstatt.dynvpn.de> References: <20171212192220.119ca2d3@thor.intern.walstatt.dynvpn.de> From: Freddie Cash Date: Tue, 12 Dec 2017 10:43:47 -0800 Message-ID: Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error To: "O. Hartmann" Cc: FreeBSD CURRENT 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, 12 Dec 2017 18:43:51 -0000 On Tue, Dec 12, 2017 at 10:21 AM, O. Hartmann wrote: > > Question: is it possible to simply pull the faulty disk (implies I know > exactly which one > to pull!) and then prepare and add the replacement HDD and let the system > do its job > resilvering the pool? > =E2=80=8Bzpool offline Do that first. That will mark the drive as offline, put the pool into a degraded mode, and generally be less harmful to the system. Then figure out which disk to pull and remove it (doing it from a powered off state if needed). Install the new drive, configure it however it's needed, then use: zpool replace =E2=80=8B > Next question is: I'm about to replace the 3 TB HDD with a more recent an= d > modern 4 TB > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the > other disks are 3 > TB, but I'd like to know whether FreeBSD's ZFS is capable of handling it? > =E2=80=8BYes, it can handle it just fine. And it will keep the extra space= as "usable in the future", so if you replace all the drives with 4 TB ones, the extra space will be added to the pool. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@freebsd.org Tue Dec 12 19:01: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 575E5E800DD for ; Tue, 12 Dec 2017 19:01:07 +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 38BA76BE1D; Tue, 12 Dec 2017 19:01:07 +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 vBCJ159m075071 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Dec 2017 11:01:05 -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 vBCJ15ov075070; Tue, 12 Dec 2017 11:01:05 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Dec 2017 11:01:04 -0800 From: Steve Kargl To: Conrad Meyer Cc: FreeBSD CURRENT Subject: Re: Poll: should man(1)'s default pager change to "less -s"? Message-ID: <20171212190104.GB74766@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20171212181510.GA74215@troutmask.apl.washington.edu> <20171212182719.GA74524@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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, 12 Dec 2017 19:01:07 -0000 On Tue, Dec 12, 2017 at 10:41:49AM -0800, Conrad Meyer wrote: > On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl > wrote: > > There isn't a question. I'm pointing out your poll apparently > > is limited to a select few individuals that use FreeBSD. > > The select few individuals being "literally anyone that wants to > participate?" https://reviews.freebsd.org/auth/register/ Ah, yeah, I know. I have kargl@freebsd.org and a FreeBSD bugzilla account. Adding yet another FreeBSD account to my collection of 30 or so other accounts seems to be overkill to simply prevent the silliness of change man(1). In particular, 'man man' shows MANPAGER Program used to display files. If unset, and color support is enabled, “less -sR” is used. If unset, and color support is disabled, then PAGER is used. If that has no value either, “more -s” is used. If someone wants to use 'less -s', then someone only needs to set PAGER correctly. -- Steve From owner-freebsd-current@freebsd.org Tue Dec 12 19:09: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 E4038E8066E for ; Tue, 12 Dec 2017 19:09:09 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA4F86C6F0; Tue, 12 Dec 2017 19:09:09 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id OpsreCgTWGvLHOpsse92Yr; Tue, 12 Dec 2017 12:06:31 -0700 X-Authority-Analysis: v=2.2 cv=a9pAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=ocR9PWop10UA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=LHpq0KAhAhs02azsk7oA:9 a=-y7GNMjh2uAf7EsT:21 a=zfkuBy_OiWt_srKw:21 a=CjuIK1q_8ugA:10 a=-ccphe-5PDHynm8l4EAA:9 a=_JjttZsQbNxi5NwX:21 a=f3YL8JQAAy2HAoYG:21 a=DwUIbyRmg3eV9zfz:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.81.38.66] (S0106d4ca6d8943b0.gv.shawcable.net [24.68.134.59]) by spqr.komquats.com (Postfix) with ESMTPSA id ECF18569; Tue, 12 Dec 2017 11:06:28 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Poll: should man(1)'s default pager change to "less -s"? Date: Tue, 12 Dec 2017 11:06:33 -0800 To: "cem@freebsd.org" , "sgk@troutmask.apl.washington.edu" CC: FreeBSD CURRENT Message-Id: <20171212190628.ECF18569@spqr.komquats.com> X-CMAE-Envelope: MS4wfDzW+rvMITKuSNfKvEPmxHbdcSgHWPliRGEOfvo5dg0AeXWhnz2kX465bzwUpFeQel14mFI0pMK0cf+x5uDcITMdK7GoiALGSaeQajaGSpDxJ6ANZpef 1pHGQmocoaoOrnGR09odlcdYY9ftdFKjEoyji8VC62wlWYW6kjOKlj+ycmPdq8cmTb/d/nwdE36AY50MrvV5XXqt/JJPRNYdxyej5DuO8274qq4n7OAGLQkP PLaXlKCOrLQ+bBq7kElPanfCofODfFE/MICsYZVm7zY= Content-Type: text/plain; charset="us-ascii" 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, 12 Dec 2017 19:09:10 -0000 What about those of us who want multiple accounts? Just kidding but you get my point. What's to stop someone from having more than one vote? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Conrad Meyer Sent: 12/12/2017 10:42 To: sgk@troutmask.apl.washington.edu Cc: FreeBSD CURRENT Subject: Re: Poll: should man(1)'s default pager change to "less -s"? On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl wrote: > There isn't a question. I'm pointing out your poll apparently > is limited to a select few individuals that use FreeBSD. The select few individuals being "literally anyone that wants to participate?" https://reviews.freebsd.org/auth/register/ _______________________________________________ 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 12 19:16:40 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 6103BE80D17 for ; Tue, 12 Dec 2017 19:16:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6D536D109; Tue, 12 Dec 2017 19:16:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x232.google.com with SMTP id 74so24449774lfs.0; Tue, 12 Dec 2017 11:16:39 -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=SSpzVPYPaE3eGD5iZBE/iWAQUhr+5R6Df0dbnIkRxKM=; b=AmCy43Cqu8j2rwDz/+Y8P2BMHAPzEISU3E9bo05WYAy3bce2bu6BfcG6svGke2GJlj XoMnUm+1UFcqe1lNYShSA1y2oceLMFSKXS9s+ili8t6GCBm5XfqeG6ELKUsOKZMnQq7i WQQy4IZ5HiWjT8YqygzRZRzOM2KnBsgvqJIAIh5AbrRPiS4xkOeoChKXS/scZXHg91w/ FKXcU3Hp5mCSBnjzsiHfRdKlyGwbijNYFCYNXGmdtMNEsOc9vrxCcj3+wUtO2GXlX+dA f4c8oXYEFr2zlUL08GbD5l2dk3j/I5EtlYfO2CJadFNLgHBJGPt61KwufdPk3ihl7mo5 zWrw== 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=SSpzVPYPaE3eGD5iZBE/iWAQUhr+5R6Df0dbnIkRxKM=; b=LFNTdqOYQHoz+ttsl1LPCNcKZpPZW/uMRSlwinySBDjgPd6VK6ofC0ZvUAftauTtxY SwAKHoy9eQroyRv7RuBzRq8TWBnzXwYaV57v5U5yzDCZA+GKOPpsj8USfrs7DfHMoWZ+ 1aQIofwkywiX6eQm6jq9WUm636hcwOpbq6NKbRuXml3P54dkaIUGZ92cmjPAuWoZEcIg wRBJivek6zIfbyco+q/t5pcDDGJQ+AwBMv5IdDbvg4GqkniBt655m5a58xyM3+ewONrE dprNPOAL+GDyIzY5vK89xfm3HjZQl/Sq0ZpDXbteY2Oc5Z3zznCeOTalGiAKWzxPoAYX VL5Q== X-Gm-Message-State: AKGB3mJFzdMWoGlM1gqb3F2ISt6SQcT+OCLqV56q0JH3S/npWM7QihF0 MRChe4NJ9akUj82n9qZAazlxdnbWmds6Viy4L/c= X-Google-Smtp-Source: ACJfBov0E7xC1ThiQJwdJUijwV0x2N9/XrW0azmfqQ9HqPQajVwHp5u0vV2ODa6/PhL6P9ykyjo7ng1g5P4dtNtPJos= X-Received: by 10.25.16.206 with SMTP id 75mr2501410lfq.66.1513106197216; Tue, 12 Dec 2017 11:16:37 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 11:16:36 -0800 (PST) In-Reply-To: <20171212190628.ECF18569@spqr.komquats.com> References: <20171212190628.ECF18569@spqr.komquats.com> From: Alan Somers Date: Tue, 12 Dec 2017 12:16:36 -0700 X-Google-Sender-Auth: xvsAVfShWhxbcixZfnpETXvXMU0 Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: Cy Schubert Cc: "cem@freebsd.org" , "sgk@troutmask.apl.washington.edu" , 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, 12 Dec 2017 19:16:40 -0000 The vote isn't secret; if you vote as both cy@freebsd.org and cy@github.com it'll be obvious. On Tue, Dec 12, 2017 at 12:06 PM, Cy Schubert wrote: > What about those of us who want multiple accounts? > > Just kidding but you get my point. > > What's to stop someone from having more than one vote? > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -----Original Message----- > From: Conrad Meyer > Sent: 12/12/2017 10:42 > To: sgk@troutmask.apl.washington.edu > Cc: FreeBSD CURRENT > Subject: Re: Poll: should man(1)'s default pager change to "less -s"? > > On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl > wrote: > > There isn't a question. I'm pointing out your poll apparently > > is limited to a select few individuals that use FreeBSD. > > The select few individuals being "literally anyone that wants to > participate?" https://reviews.freebsd.org/auth/register/ > _______________________________________________ > 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" > > _______________________________________________ > 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 12 19:22:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70744E81162 for ; Tue, 12 Dec 2017 19:22:51 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (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 17CD26D7C2; Tue, 12 Dec 2017 19:22:50 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f45.google.com with SMTP id f190so744649ita.5; Tue, 12 Dec 2017 11:22:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=qFh7y8hWFUeeeIe6v9ic3pDHU+KKTuLvWoy39QRN78s=; b=l4h5BmJXe0nu+X/uYrWVUyr53Ua4mAR+0ixM5txsUerA3Z2m8dXuHx8jMfHgeZNVsl 1flGcxrH5OLgZqQoYN473gbrGfEBrUE/nM6UGuJRXjfdeJvFs+9n0OQbXoPok5SRZ4El WYCIwoyb4zR/IrTXEeSIIrX5tGo+lPna0oRK0ey4SLawLUG9cTk6RjjndOlqUmz/vCoh qGl0T8vxneJp+imxoBiH/YO750AsACL3wfJh+wmP3BhyiaAy+H1BGSWWCKVHQJ3mwiIi 9qAdx16XSq9wSu8JXmzaGSswBRqxxCWQxesADcWI4JyeOC701dL0lIY1H+HCWuxrk4qd mxdA== X-Gm-Message-State: AKGB3mJwBFYcVEWaxvuc2LjFRKMEin7gZ2qEbV6JPn7LCmvqR+7NzJH5 PDFuRj4BS+ITblEidvvlw1kbNVjJ X-Google-Smtp-Source: ACJfBotwKGacCAlMdAmCEYLB+4rdTlHsz0B41fIvJq1WsfYRItixQ9Netx27nhsIK3etcHTsZJGrJg== X-Received: by 10.36.41.137 with SMTP id p131mr939771itp.68.1513106136786; Tue, 12 Dec 2017 11:15:36 -0800 (PST) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com. [209.85.214.45]) by smtp.gmail.com with ESMTPSA id 25sm7897703iol.79.2017.12.12.11.15.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 11:15:36 -0800 (PST) Received: by mail-it0-f45.google.com with SMTP id d137so761013itc.2; Tue, 12 Dec 2017 11:15:36 -0800 (PST) X-Received: by 10.36.0.209 with SMTP id 200mr866772ita.55.1513106136484; Tue, 12 Dec 2017 11:15:36 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.165.150 with HTTP; Tue, 12 Dec 2017 11:15:35 -0800 (PST) In-Reply-To: <20171212190628.ECF18569@spqr.komquats.com> References: <20171212190628.ECF18569@spqr.komquats.com> From: Conrad Meyer Date: Tue, 12 Dec 2017 11:15:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: Cy Schubert Cc: "cem@freebsd.org" , 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: Tue, 12 Dec 2017 19:22:51 -0000 Ordinary human decency. On Tue, Dec 12, 2017 at 11:06 AM, Cy Schubert wrote: > What about those of us who want multiple accounts? > > Just kidding but you get my point. > > What's to stop someone from having more than one vote? > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > ________________________________ > From: Conrad Meyer > Sent: 12/12/2017 10:42 > To: sgk@troutmask.apl.washington.edu > Cc: FreeBSD CURRENT > Subject: Re: Poll: should man(1)'s default pager change to "less -s"? > > On Tue, Dec 12, 2017 at 10:27 AM, Steve Kargl > wrote: >> There isn't a question. I'm pointing out your poll apparently >> is limited to a select few individuals that use FreeBSD. > > The select few individuals being "literally anyone that wants to > participate?" https://reviews.freebsd.org/auth/register/ > _______________________________________________ > 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 12 19:36:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3A60E81BB0 for ; Tue, 12 Dec 2017 19:36:05 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 C3D556ED21 for ; Tue, 12 Dec 2017 19:36:05 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBCJbR2I070597 for ; Tue, 12 Dec 2017 11:37:33 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: 12-r326622 install won't boot Date: Tue, 12 Dec 2017 11:37:33 -0800 Message-Id: <4e8bbcf2496318359fca6a76bd20b5a1@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Tue, 12 Dec 2017 19:36:06 -0000 Hello all, I just blew away a old RELENG_11, to start working with current=2E I must admit I had several disappointments regarding the installer=2E But that's for another topic, and another time=2E To the point; I completed the install=2E The only event(s) that might be notable during the install=2E Was early on during (boot?) I saw a "dumped core" race past on the screen=2E I also experienced at least 1 LOR=2E But the install continued, seemingly un(interrupted|affected)=2E That said, I chose the reboot option after completion=2E Ejected the DVD during POST, and I'm stuck at: BTX loader 1=2E00 BTX version is 1=2E02 Consoles: internal video/keyboard followed by 2 gibberish characters; 1 appears as a right pointing arrow, the other, kind of like a battlestar galactca spaceship=2E NOTE: those 2 characters did not show up on the initial reboot from the install (just the 2 lines above)=2E But after I attempted a hard reset after the first fail=2E Thank you for all your time, and consideration=2E --Chris From owner-freebsd-current@freebsd.org Tue Dec 12 20:00:40 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 04748E82B45 for ; Tue, 12 Dec 2017 20:00:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 C16106FB79; Tue, 12 Dec 2017 20:00:38 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBCK1ume073889; Tue, 12 Dec 2017 12:02:02 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD CURRENT" , "Jamie Landeg-Jones" , , "Alan Somers" In-Reply-To: <20171212181510.GA74215@troutmask.apl.washington.edu> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? Date: Tue, 12 Dec 2017 12:02:02 -0800 Message-Id: <8bb0ed7e67013fe3e665350da191c27c@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Tue, 12 Dec 2017 20:00:40 -0000 On Tue, 12 Dec 2017 10:15:10 -0800 said > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: > > Should man(1)'s default pager change to "less -s"? Vote and flame at t= he > > Phabricator link below=2E > >=20 > > https://reviews=2Efreebsd=2Eorg/V7 > >=20 >=20 > Does not work=2E >=20 > Unhandled Exception ("AphrontMalformedRequestException") > Your browser did not submit a "phcid" cookie with client state > information in the request=2E Check that cookies are enabled=2E > If this problem persists, you may need to clear your cookies=2E >=20 > Of course, I don't have an account on https://reviews=2Efreebsd=2Eorg/ Hah! I got the same (alarming) feedback too=2E I then tried to just log in, and it worked=2E Guess you'll need, or create an account? :-) --Chris >=20 > --=20 > Steve > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Tue Dec 12 20:27: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 B8D78E83A63 for ; Tue, 12 Dec 2017 20:27:39 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7885A712DF; Tue, 12 Dec 2017 20:27:39 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x22e.google.com with SMTP id p33so84272uag.9; Tue, 12 Dec 2017 12:27:39 -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=tsQILGaKJaHWqa692+T3DqN/ohYu5XijvRqYUCf52b0=; b=tJGnd/7IaEOlYKHYvxOvUP03UrQkfPFelZJssMPcAc5FjTHV81bo706ShGyCJaRFlK qVuzVAwpS7u0q1BtQRLV19od6dg+4n+FjGoJbgVbzxNc7YObulEMJsgQ0CMHE/Y/9GWZ 6SgGtRCbmH7jZAJAtZ5/wzHT3Gog3n4zi0j5gpM1NTKyxkFaJM1otUzKYn6ciqqJWt82 NezezP42TifO7esR5VAYactKcCFVrOlvu46a53dbt59aZGsycKQxj3k7F1mblk4/NlLn EmDdtOOLyF8wVy+jiSqlWvzeIc6vHUIqcifpE4ieEd3h2OdBODfIF5z1uCF9kZkGD3dn NcgQ== 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=tsQILGaKJaHWqa692+T3DqN/ohYu5XijvRqYUCf52b0=; b=bg0RLGB9QXvo8mSTZWyultgVae+Uz2DXQfmLbSc9d7xfkYHNj9iE8bjUobQ+aSdMMM TCg8C1O11/NgVQzEmoKrRaeKJdqnpmzwnQ5jVa10ev6SELWwE9tOjeH/HdHLE0KKmmXJ +pt0hW6IZ1v3hNQ5rHUa0cU1W9PQUB67VEALCmxlVKffCeVZpAeGb+H7wnQwN3SRS4fT 08GCDXMbDaJP3h3gr6fJuwBQOV0hpr8P096BTxoEnOmLxdSGRSADcrv5wDueYfFCT6k2 7fdFjnJiJTCh9vXS4NWFfoJ+/QOaOX7Ubqd7rzBwcbp9yGoreMQHjP+QnKF2kIBAJ5lG 8KFw== X-Gm-Message-State: AKGB3mJPrnjc12Qcwg749owzwMLzFxzosOz3EQUeuQ7/2jDgQpMwrgpj wU4Hhl5lmUSUwFgOIVlG9fOyMRbO1Z0UwxOnm5g5n0fX X-Google-Smtp-Source: ACJfBouCYRagj2P7JZxDv35e4vv18S1IGGTmrJuXEUiQo+dy8Jwb7qO84EWR60rktNqbGHaXZi0zKVee3pDVM5adkV0= X-Received: by 10.176.112.174 with SMTP id q14mr5863070ual.3.1513110458292; Tue, 12 Dec 2017 12:27:38 -0800 (PST) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.147.156 with HTTP; Tue, 12 Dec 2017 12:27:37 -0800 (PST) In-Reply-To: <8bb0ed7e67013fe3e665350da191c27c@udns.ultimatedns.net> References: <20171212181510.GA74215@troutmask.apl.washington.edu> <8bb0ed7e67013fe3e665350da191c27c@udns.ultimatedns.net> From: Kevin Oberman Date: Tue, 12 Dec 2017 12:27:37 -0800 X-Google-Sender-Auth: P0T0mPPQ8bpys1OOIrNe0DNv6Aw Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: Chris H Cc: Steve Kargl , FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com, Alan Somers 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, 12 Dec 2017 20:27:39 -0000 On Tue, Dec 12, 2017 at 12:02 PM, Chris H wrote: > On Tue, 12 Dec 2017 10:15:10 -0800 said > > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: >> > Should man(1)'s default pager change to "less -s"? Vote and flame at >> the >> > Phabricator link below. >> > > https://reviews.freebsd.org/V7 >> > >> Does not work. >> >> Unhandled Exception ("AphrontMalformedRequestException") >> Your browser did not submit a "phcid" cookie with client state >> information in the request. Check that cookies are enabled. >> If this problem persists, you may need to clear your cookies. >> >> Of course, I don't have an account on https://reviews.freebsd.org/ >> > Hah! I got the same (alarming) feedback too. I then tried to just log in, > and it worked. Guess you'll need, or create an account? :-) > > --Chris > > >> -- >> Steve >> > I have not used those ancient, very limited pagers for years, but I am sure that almost nobody has even heard of the much more powerful sysutils/most. While newer than more or less, it is hardly new in most senses as I first used it on VMS systems at least a quarter century ago, probably longer. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Tue Dec 12 20:37: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 1F9ECE8403D for ; Tue, 12 Dec 2017 20:37:41 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 F03AB71969 for ; Tue, 12 Dec 2017 20:37:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBCKd3vI078144; Tue, 12 Dec 2017 12:39:09 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "Steve Kargl" , "FreeBSD CURRENT" , " Jamie Landeg-Jones" , , " Alan Somers" , "Chris H" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Kevin Oberman" Subject: Re: Poll: should man(1)'s default pager change to "less -s"? Date: Tue, 12 Dec 2017 12:39:09 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Tue, 12 Dec 2017 20:37:41 -0000 On Tue, 12 Dec 2017 12:27:37 -0800 "Kevin Oberman" sa= id > On Tue, Dec 12, 2017 at 12:02 PM, Chris H wrote: >=20 > > On Tue, 12 Dec 2017 10:15:10 -0800 s= aid > > > > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: > >> > Should man(1)'s default pager change to "less -s"? Vote and flame a= t > >> the > >> > Phabricator link below=2E > >> > > https://reviews=2Efreebsd=2Eorg/V7 > >> > > >> Does not work=2E > >> > >> Unhandled Exception ("AphrontMalformedRequestException") > >> Your browser did not submit a "phcid" cookie with client state > >> information in the request=2E Check that cookies are enabled=2E > >> If this problem persists, you may need to clear your cookies=2E > >> > >> Of course, I don't have an account on https://reviews=2Efreebsd=2Eorg/ > >> > > Hah! I got the same (alarming) feedback too=2E I then tried to just log i= n, > > and it worked=2E Guess you'll need, or create an account? :-) > > > > --Chris > > > > > >> -- > >> Steve > >> > > > I have not used those ancient, very limited pagers for years, but I am su= re > that almost nobody has even heard of the much more powerful sysutils/most= =2E Ooo=2E=2E=2E I may have voted too soon=2E :-O Thanks for the pointer, Kevin! --Chris >=20 > While newer than more or less, it is hardly new in most senses as I first > used it on VMS systems at least a quarter century ago, probably longer=2E > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail=2Ecom > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Tue Dec 12 20:39: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 D3438E84146 for ; Tue, 12 Dec 2017 20:39:27 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 95B6971B0D for ; Tue, 12 Dec 2017 20:39:27 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-io0-x235.google.com with SMTP id w127so402740iow.11 for ; Tue, 12 Dec 2017 12:39:27 -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=m/tMIt3wzihKmKeo/9JXlhSWxxMg/TgUeDeSfZXl3VM=; b=silPm7u6SsZ9qkSE6lkXbm29+jdWga1vB5ddIYvBvlVdsazQG+5X3r1unMNemVkygW 4GRVvyL7W0JJkECOS807fL8172szZBsAiwyZDN8Ph4ab/hFyaNl6W5jv3X0Q6Uk4J2Ix uykeX5bez6J/RyQd0FQf3eZuyk/YoldSlxgYuc6og+87Elz66IEZoxIsrAVhIM0ifv5v 2LMXDcUz8WgpyuEujSOIbV51gqWDGRNsKN0tu3b78DzWpx8kwVFxjneJOyO+QzLPqExK UhbPXI4VSvTPT2FFQqHOZ3XnwOzXt3S363z7HUPR/bO2mV351FWv2lLg0dHL/tebxRnG gZMg== 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=m/tMIt3wzihKmKeo/9JXlhSWxxMg/TgUeDeSfZXl3VM=; b=G4jIhIgWSCqDUSlcN058lORlucRW5wDoJ87ryLYJTdse2qka7Y/bFzntkQ3cGlGQdY G016V8YAtfJfEVp06VDlYW9nmO8yhekBijbgMLjn40u+0vlhU2+4vSlytmVEgV+fBJ1O VYHC7Qatb6qLiupxwcF22J+W62VQUlhdjFasD1xLEr4V5pAs89Fs3fTPuGLt8UotnPO5 k4RqNzupHdmAu+SEkHKtaEUYAIktKW8qXfkUpBIefAIgJeXqQ6n2jqfnxw1rW4KgXl46 FEdFYjpcaHDuhNKZ3TsSncsGtPQjqUWu/l61VmRYPglisEXwP04546v3gtR8XN//NUY6 ezFw== X-Gm-Message-State: AKGB3mJhzFGHwaOzF8zYpnfY7aXl6CdTDL4OUKkO0PS17fvZkAdVv+ao loItkno94KyDAs9Ou4qAlfk9rA== X-Google-Smtp-Source: ACJfBosNoG24EQ2JtSkAK9fqPdUwoun15d1LS5YKNjpBLRArEDVkFeBmNjR1KRrRWA1mFiQnAVAj4A== X-Received: by 10.107.151.142 with SMTP id z136mr191911iod.248.1513111166741; Tue, 12 Dec 2017 12:39:26 -0800 (PST) Received: from mutt-hbsd (politkovskaja.torservers.net. [77.247.181.165]) by smtp.gmail.com with ESMTPSA id e12sm17001iod.4.2017.12.12.12.39.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Dec 2017 12:39:25 -0800 (PST) Date: Tue, 12 Dec 2017 15:38:59 -0500 From: Shawn Webb To: Thomas Laus Cc: FreeBSD Current Subject: Re: GPTZFSBOOT in Current r326622 has problems Message-ID: <20171212203859.3sarr4y6rjwmw7gu@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s6b36qfc5545zpk6" Content-Disposition: inline In-Reply-To: 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/20171027 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, 12 Dec 2017 20:39:27 -0000 --s6b36qfc5545zpk6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 06, 2017 at 10:35:37AM -0500, Thomas Laus wrote: > Group: >=20 > I updated my amd64 computer today to r326622 and copied the > /boot/gptzfsboot file to each of my ZFS hard drives p1 partition. The > BTX loader stopped and could not load. This rendered my system > 'un-bootable'. I copied this file from an earlier live filesystem CD, > which restored my computer and enabled me to boot. >=20 > I also see the problem with the loader logs dumping core that others > have reported recently. I'm seeing the same issue with recent HardenedBSD 12-CURRENT/amd64 memstick images. Booting in UEFI mode works, however. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --s6b36qfc5545zpk6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlowPl4ACgkQaoRlj1JF bu7TZg//V0z91ajfw/UOGTMN0B+cw5V4uu0hOufvuetLPmMzDeoVKlqdPuij1OWW q/8QCnH05R0UrhYqjt5GKtPDfdrivFsUDQjPWt+wnWR08G8dKvHnliYtk/lEpkHk Ocfd6zdqPqtQPVaGL+FIxImW34Lrzu1AyD6SmytgRUBHpmE3ObpQaoUT3zy3NLsl c88DHBq+acBdGKtYH4xdHVucIaPBUjfd1l5YsALVp+KSWd01Rg5LM2RW1/jHJWae 8V6IqQ0YeNz/mdH4qMk6hSCZB/+l3a7m+/bh1HRPzs23cYMyXqC5vxClkTT7xYYn L7JNl6upc4B8l5xeleyZKmaexn0CM4zYC9OH9/lc7PRRywxXyE/NpuGAGMQKIppM NnwzYI/dfpP+3BNmB+iSbQa5NLwp+DxIz71bUxsSBJNX9aQiLQCwKFSLPUYrR4Pt 2zW+W1/Db3GomLz4dxljCVaWffVLDLXNiXeOqDXb6mNezqSMAkg84YGIvszRGtLY 6X7Bq1aj5/iMAZLFc2qYNopQkS1Ts10v9+q7A/kqkUa7joCR3S0yPZL2PJPgGIOr BqSyFwbRdyMLw2YrAzma9zAI/65HN/oNTfajlnBlsH3IJ3IPnj6nG0jbmi4/rVVU ncGyAf2gIGOqWFy2xoTvnSbCOJLFyDtnfYodyCXpnwkjXfl5L7U= =7GmZ -----END PGP SIGNATURE----- --s6b36qfc5545zpk6-- From owner-freebsd-current@freebsd.org Tue Dec 12 20:40: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 CA299E842D8 for ; Tue, 12 Dec 2017 20:40:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ABC471DDD for ; Tue, 12 Dec 2017 20:40:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id x204so159413lfa.11 for ; Tue, 12 Dec 2017 12:40:41 -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=gUCLL+CdtFWpqTBsml8KOj0IQyuk7EhdpElWs9mevSI=; b=O6AuIaY2XDrXH7ZjxsBJrBiCFmeBejnTDXNrhKeo3Ei7vT9vact7lBbnbWpCwVH8V9 mgwmB3Dwh6G0FzaQUEpXoAErpUZ+YGUVTfWB8EvMREzj5Vqro0kk0HM23IQc36X4Zgs7 ayiVGvqkLIZGtaJ49T4dW4Rxr+dRJ/l11jmt8Zyzfiq9Gc/K5GUb//tepWcNoHMiOkMX wdCen+lHAg1Miv0/50weU4RNgaePBTcMA7r8iUMVUQ+CAWGL49AhjOqCq0+3kKmRB7F5 TXQn0aY9JNv38iqF/w/15p7YEZ29f5CKyx6ZjFJBS25E25neACR9YMyZGD2cuSsN2DYc Qosg== 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=gUCLL+CdtFWpqTBsml8KOj0IQyuk7EhdpElWs9mevSI=; b=ATIaALpFErbdc7gf4JNvFrA8I4oRWzOsRzkPxVMbpkseS9mMu7OHFHtFYml41BpVq3 chZnweFeVt1aIO8LqNyhg3th7XSuX0VJklGRUIJJ86Ahd4BFQugvWD/KnvB4dMjJtCXf ULIQ+HK7lOyTh96vt66RDqJyOfyZ5hAYeCYpWIzPUbvWwyDAn/K2EzgC7VDF5keX26tg 9vuF3QdCcTtMAbP3x3dg/qNGTzxTJhW49G1DCOANaEFTz/R4tsXkejIZ2Qt6pyTdffFg 1z0+5t/snqFAAc/Aqdk7k6+uSlPBW9g0SKmkc7osBF6g+sr9qIkLYZtFByT3r53ToW7Z 9TsA== X-Gm-Message-State: AKGB3mJpam5tvCXfG/lMZbV3qG4RBj2KiTSvU6ZovpOanjaUVPCrPFKs 6TRy953IaVXGKIkOj/zRLGNziMqGN82zxxTYDeU= X-Google-Smtp-Source: ACJfBovdgt2PbW6E9WIMpIzO5JUhLXCc/ZKCn/WUxAMxty9wmJlNBnrE2s5PJFOQLAUJXrZ+eW72JYmsTxlKqT5trWo= X-Received: by 10.46.19.1 with SMTP id 1mr50626ljt.91.1513111239317; Tue, 12 Dec 2017 12:40:39 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.76.19 with HTTP; Tue, 12 Dec 2017 12:40:38 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Tue, 12 Dec 2017 13:40:38 -0700 X-Google-Sender-Auth: KBiXh0EEYdtJZI8M598NvnBLNaw Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: Chris H Cc: Kevin Oberman , Steve Kargl , FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com 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, 12 Dec 2017 20:40:41 -0000 On Tue, Dec 12, 2017 at 1:39 PM, Chris H wrote: > On Tue, 12 Dec 2017 12:27:37 -0800 "Kevin Oberman" > said > > On Tue, Dec 12, 2017 at 12:02 PM, Chris H wrote: >> >> > On Tue, 12 Dec 2017 10:15:10 -0800 >> said >> > >> > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: >> >> > Should man(1)'s default pager change to "less -s"? Vote and flame at >> >> the >> >> > Phabricator link below. >> >> > > https://reviews.freebsd.org/V7 >> >> > >> >> Does not work. >> >> >> >> Unhandled Exception ("AphrontMalformedRequestException") >> >> Your browser did not submit a "phcid" cookie with client state >> >> information in the request. Check that cookies are enabled. >> >> If this problem persists, you may need to clear your cookies. >> >> >> >> Of course, I don't have an account on https://reviews.freebsd.org/ >> >> >> > Hah! I got the same (alarming) feedback too. I then tried to just log >> in, >> > and it worked. Guess you'll need, or create an account? :-) >> > >> > --Chris >> > >> > >> >> -- >> >> Steve >> >> >> > >> I have not used those ancient, very limited pagers for years, but I am >> sure >> that almost nobody has even heard of the much more powerful sysutils/most. >> > Ooo... I may have voted too soon. :-O > Thanks for the pointer, Kevin! > > --Chris > most looks pretty cool. The only probably I noticed in my brief inspection was that it doesn't support the Home and End keys. From owner-freebsd-current@freebsd.org Tue Dec 12 21:27:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E235E85526 for ; Tue, 12 Dec 2017 21:27:08 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 34D267386A for ; Tue, 12 Dec 2017 21:27:07 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBCLSUVl085756 for ; Tue, 12 Dec 2017 13:28:36 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 In-Reply-To: <4e8bbcf2496318359fca6a76bd20b5a1@udns.ultimatedns.net> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: Re: 12-r326622 install won't boot Date: Tue, 12 Dec 2017 13:28:36 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Tue, 12 Dec 2017 21:27:08 -0000 On Tue, 12 Dec 2017 11:37:33 -0800 said > Hello all, > I just blew away a old RELENG_11, to start working with current=2E I > must admit I had several disappointments regarding the installer=2E > But that's for another topic, and another time=2E > To the point; > I completed the install=2E The only event(s) that might be notable > during the install=2E Was early on during (boot?) I saw a "dumped core" > race past on the screen=2E I also experienced at least 1 LOR=2E But the > install continued, seemingly un(interrupted|affected)=2E That said, I > chose the reboot option after completion=2E Ejected the DVD during POST, > and I'm stuck at: >=20 > BTX loader 1=2E00 BTX version is 1=2E02 > Consoles: internal video/keyboard >=20 > followed by 2 gibberish characters; 1 appears as a right pointing arrow, > the other, kind of like a battlestar galactca spaceship=2E > NOTE: those 2 characters did not show up on the initial reboot from > the install (just the 2 lines above)=2E But after I attempted a hard > reset after the first fail=2E OK tried the installation again, and nothings changed=2E Still left with the 2 lines listed above=2E Guess I'll have to wait until 12-CURRENT becomes a usable version=2E Sigh=2E=2E=2E I was really hoping to run 12, so I could better develop 11=2E Oh well=2E Guess I'll grab a copy of 11 off one of the ftp servers, and spin = it up=2E Thanks anyway! :-) --Chris >=20 > Thank you for all your time, and consideration=2E >=20 > --Chris >=20 >=20 > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Tue Dec 12 21:33: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 3B8DDE858EB for ; Tue, 12 Dec 2017 21:33:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 00FB973EC3 for ; Tue, 12 Dec 2017 21:33:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id f143so1241565itb.0 for ; Tue, 12 Dec 2017 13:33:11 -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=0p3tLqKWbuoT82QXjIcbQ2zHBqvCIXj/1dE9c2oYVbo=; b=CoTQer817UM8bSsZX3VMbX9lRzDnXfYoxvIf3H21yXgoDmh+viHcOZ5l8RllFumQ8Y sIXgdZieUU8NPEjyg2Wf0+U0tdhEHFQRM0snxhR5dXxAMvVU3B4bmi4kcxtc2jf66QG2 qnldgxc2R1nsikTwrmmGajsDGAeiTNGuN45oXiudnDewW6r2vl7q1BxhGCmh9SM09AAT XgqWlOEPjmnLoZ7IepSP3LBlXBahZhUkINDuOGnk341BDwfe3LdfP4+oNFQpGn7C4c7c Kpos3qFkpdQNAOET9m1Y2j1Wq3QBAtMzIG2Jh6yyucefzMSB0GoRBaE1Cr4j4ikypmlZ zf2g== 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=0p3tLqKWbuoT82QXjIcbQ2zHBqvCIXj/1dE9c2oYVbo=; b=F8Y9EJQGF/3whqaaZtdN8pMOLfJwVIOgwHku619ZcL/nxqw3bKnMyxuEVqknUtG7Lx gCXgYsih/kRI4711XofrOOVm6cOiXLtspQBy2gCFSeA1WOyaV8HT8QLhY6OSCfvpVx9I kjc4Y8b6kspbQymcbfYeJ+s6zdhn1aKnw+seBgL1pCVzG593dpoUw0SkODqhxn9c8/P6 8qL6KKidex46s1jkfKctA1C34hoilxMnnaXYqYaw4QxRiLls760w8L2qMR46ELJC5yym fX79wS6Zq4BYB5+DZqVSfEzTc8mKByqp0yUIkKIVw+c8ESzN0IjXlqObevPmRy0Ln3+6 zG4A== X-Gm-Message-State: AKGB3mIuwHXtvD02c+rsa255/bYvOaODwbftneflS3pgnhRgvyD7wF1y eGxvxZg5kzfsvMiAlJKrOtwh0j+TLp/H/QqmsyDffQ== X-Google-Smtp-Source: ACJfBounXwVOT2x3HXbdZvb2PyyLo57XX9VQpLFuaW84QHHCaD6oqrZqtbrJpsafl29TrL8NIzaPmfDPy5zRMsarQ3I= X-Received: by 10.36.147.193 with SMTP id y184mr285549itd.64.1513114391160; Tue, 12 Dec 2017 13:33:11 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 12 Dec 2017 13:33:10 -0800 (PST) X-Originating-IP: [12.227.204.186] In-Reply-To: References: <4e8bbcf2496318359fca6a76bd20b5a1@udns.ultimatedns.net> From: Warner Losh Date: Tue, 12 Dec 2017 14:33:10 -0700 X-Google-Sender-Auth: PGy_uPxUhIJskicgtDM7CA_4sYM Message-ID: Subject: Re: 12-r326622 install won't boot To: Chris H Cc: 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, 12 Dec 2017 21:33:12 -0000 On Tue, Dec 12, 2017 at 2:28 PM, Chris H wrote: > On Tue, 12 Dec 2017 11:37:33 -0800 said > > Hello all, >> I just blew away a old RELENG_11, to start working with current. I >> must admit I had several disappointments regarding the installer. >> But that's for another topic, and another time. >> To the point; >> I completed the install. The only event(s) that might be notable >> during the install. Was early on during (boot?) I saw a "dumped core" >> race past on the screen. I also experienced at least 1 LOR. But the >> install continued, seemingly un(interrupted|affected). That said, I >> chose the reboot option after completion. Ejected the DVD during POST, >> and I'm stuck at: >> >> BTX loader 1.00 BTX version is 1.02 >> Consoles: internal video/keyboard >> >> followed by 2 gibberish characters; 1 appears as a right pointing arrow, >> the other, kind of like a battlestar galactca spaceship. >> NOTE: those 2 characters did not show up on the initial reboot from >> the install (just the 2 lines above). But after I attempted a hard >> reset after the first fail. >> > OK tried the installation again, and nothings changed. > Still left with the 2 lines listed above. > > Guess I'll have to wait until 12-CURRENT becomes a usable version. > Sigh... > I was really hoping to run 12, so I could better develop 11. > Oh well. Guess I'll grab a copy of 11 off one of the ftp servers, and spin > it > up. > > Thanks anyway! :-) I think a two-week old snapshot would work a lot better if you wanted to make the jump to -current. I've botched something in my boot loader cleanup and it's taking a little time to get sorted out... Warner > > --Chris > > >> Thank you for all your time, and consideration. >> >> --Chris >> >> >> _______________________________________________ >> 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 >> " >> > > > _______________________________________________ > 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 12 21:55: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 3F701E862FA for ; Tue, 12 Dec 2017 21:55:29 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 140AF74B4E for ; Tue, 12 Dec 2017 21:55:28 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBCLuo5W087009; Tue, 12 Dec 2017 13:56:56 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD Current" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Warner Losh" Subject: Re: 12-r326622 install won't boot Date: Tue, 12 Dec 2017 13:56:56 -0800 Message-Id: <4bf0ab6fe9f034b9ec007f13c72092af@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Tue, 12 Dec 2017 21:55:29 -0000 On Tue, 12 Dec 2017 14:33:10 -0700 "Warner Losh" said > On Tue, Dec 12, 2017 at 2:28 PM, Chris H wrote: >=20 > > On Tue, 12 Dec 2017 11:37:33 -0800 said > > > > Hello all, > >> I just blew away a old RELENG_11, to start working with current=2E I > >> must admit I had several disappointments regarding the installer=2E > >> But that's for another topic, and another time=2E > >> To the point; > >> I completed the install=2E The only event(s) that might be notable > >> during the install=2E Was early on during (boot?) I saw a "dumped core" > >> race past on the screen=2E I also experienced at least 1 LOR=2E But the > >> install continued, seemingly un(interrupted|affected)=2E That said, I > >> chose the reboot option after completion=2E Ejected the DVD during POST, > >> and I'm stuck at: > >> > >> BTX loader 1=2E00 BTX version is 1=2E02 > >> Consoles: internal video/keyboard > >> > >> followed by 2 gibberish characters; 1 appears as a right pointing arro= w, > >> the other, kind of like a battlestar galactca spaceship=2E > >> NOTE: those 2 characters did not show up on the initial reboot from > >> the install (just the 2 lines above)=2E But after I attempted a hard > >> reset after the first fail=2E > >> > > OK tried the installation again, and nothings changed=2E > > Still left with the 2 lines listed above=2E > > > > Guess I'll have to wait until 12-CURRENT becomes a usable version=2E > > Sigh=2E=2E=2E > > I was really hoping to run 12, so I could better develop 11=2E > > Oh well=2E Guess I'll grab a copy of 11 off one of the ftp servers, and s= pin > > it > > up=2E > > > > Thanks anyway! :-) >=20 >=20 >=20 > I think a two-week old snapshot would work a lot better if you wanted to > make the jump to -current=2E I've botched something in my boot loader clean= up > and it's taking a little time to get sorted out=2E=2E=2E OH, thank you *very* much, Warner! Whew! Just in time, too=2E I had almost slipped the 11 DVD into the box=2E Thanks again, Warner=2E Hope the things go well for you=2E --Chris >=20 > Warner >=20 >=20 > > > > --Chris > > > > > >> Thank you for all your time, and consideration=2E > >> > >> --Chris > >> > >> From owner-freebsd-current@freebsd.org Tue Dec 12 22:00: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 DCC3AE865F6 for ; Tue, 12 Dec 2017 22:00:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-133.reflexion.net [208.70.210.133]) (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 8B51874FC7 for ; Tue, 12 Dec 2017 22:00:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10070 invoked from network); 12 Dec 2017 21:53:28 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 21:53:28 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 16:53:28 -0500 (EST) Received: (qmail 20349 invoked from network); 12 Dec 2017 21:53:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 21:53:28 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ED2ABEC9296; Tue, 12 Dec 2017 13:53:27 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: get_swap_pager(x) failed Message-Id: Date: Tue, 12 Dec 2017 13:53:27 -0800 To: gurenchan@gmail.com, FreeBSD Current 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: Tue, 12 Dec 2017 22:00:16 -0000 blubee blubeeme gurenchan at gmail.com wrote on Tue Dec 12 15:58:19 UTC 2017 : > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme >wrote: > > I am seeing tons of these messages while running tail -f = /var/log/messages > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed > . . . > > 1159 blubee 5 20 0 149M 56876K select 6 1:05 = 0.00% > > ibus-engine-chewing > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > What's with all the swap errors? I am running ZFS and I have 16GB of = ram, > > how could I be having swap space errors? > > >=20 > Well I added 4GB of extra swap in /var/tmp/swap0 > then added that to my /etc/fstab: md99 none swap > sw,file=3D/var/tmp/swap0,late 0 0 >=20 > and those errors went away. I recommend reviewing bugzilla 206048 (title in part "swapfile usage hangs; swap partition works"): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 before using file-system based swap spaces. They have lots of problems with deadlocks. See especially comments #7 and #8 quoting Konstantin Belousov. #8 is just a reference to: = https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern= eldebug-deadlocks.html Comment #3 shows a way to test for the problematical behavior. Using swap partitions avoids the issue. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Dec 12 22:19: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 0AFEDE86E89 for ; Tue, 12 Dec 2017 22:19:21 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 8162675CEB; Tue, 12 Dec 2017 22:19:19 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.182.112.82]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M4nYT-1fEuTX3iPt-00z0Ah; Tue, 12 Dec 2017 23:19:07 +0100 Date: Tue, 12 Dec 2017 23:18:31 +0100 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error Message-ID: <20171212231858.294a2cb5@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201712121852.vBCIqRuZ087701@pdx.rh.CN85.dnsmgr.net> References: <20171212192220.119ca2d3@thor.intern.walstatt.dynvpn.de> <201712121852.vBCIqRuZ087701@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_/QYT9Wra0yqX6hyEFFfRyrQZ"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:myZB9N9JH20ktU2ZApBhXaPRneJSvtUIg7Yd9z104q/XOonLeMW 7H1eN+d9xFexlwvihp0EHldiD6VcT/abgMkDnr9NENB2Jg/7NzI8mPYVC/wpq0rApHZ7XeG zQ9eAf7+50yjUbMoh8KlGjCSxyHj8RQOEj2Gm9TbcduEQGhjFWlQ6B+db4SyxJqGZkDCD0/ 3tcFk6A3oBF9VM5jfP69g== X-UI-Out-Filterresults: notjunk:1;V01:K0:MH2zaT0Ottg=:Enqb5Wvr8CV8Sx2X5vDXRI YpipOXa/gMqCo9tzQeC0RZH6BJOMYV8Dnri9VzrGnXnnk8DEziS0jp+u/9mfyXhkmSo8Qvth2 oZMJth04QZxjbAFe5T3tIJBVsaC+wLhIT6HBF6P1yytSC2r/rs7KXiBJEPKpt71qv29/4NaJP CHn8y00PIOhM86awgSIwUwdjKpUQw9OcqiVUmvnezME8VPeKOyMlO6xOi3HXgjk0692T8NWvU 7B/a4wZb7tk/boolVlu/tY6+aConXomITz6Vslbdbfdzu8zgs6n8FGCeEUH1pSRVdPtk+LX7A dFn0GH8ohiOMaO+5vwKJ2IFXwsJoi5f4nheEjzYqLRUeHWLvUAHvB83MovK8Pkq+K2qWQP0+U EH1KNSfCPH5A4znSFeIvLhcwd69dzmsTOLt5AGvsiX0UcvQ7C1YONhyhgp5LE5lRxCtqyfekx jn2YqIun+pRFG2oBXQ5qMnF6EglWyTAsxEeRsEyG5uQlmFvJvaem1MWLCqmFxKIv2/MTdT24R maoG1rAsUlSGPxuJtaUsdC0Q7WYj4aJTtcjcT+81NfGXAZDHuAjAPud3PIBRyMuIn8JQ9zqtF R9E7XmnimZBQQMnnSbfZIBiWTTXnb1xNMI0ouoxejEfapyGUlIk0xlPcpDJu3mzF73C9CBHZd CKABTkzsMCrbc1zT2ImiAMGAPcH8oczmigy5Y74gsPBcE/6rqLEaUj7AXZlySMWjq5xkcfx50 sIjQXK5hs22ZI0COa8gv7u+EOCCzvu/VZ9FSCom+NSbrDn8TwlsyLzuqGrUXv6Kbeo+D2Lhal X3+YfWHa6DSUevXJVvPaDq07sm/0w== 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, 12 Dec 2017 22:19:21 -0000 --Sig_/QYT9Wra0yqX6hyEFFfRyrQZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 12 Dec 2017 10:52:27 -0800 (PST) "Rodney W. Grimes" schrieb: Thank you for answering that fast! > > Hello, > >=20 > > running CURRENT (recent r326769), I realised that smartmond sends out s= ome console > > messages when booting the box: > >=20 > > [...] > > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currentl= y unreadable > > (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /de= v/ada6, 1 > > Offline uncorrectable sectors > > [...] > >=20 > > Checking the drive's SMART log with smartctl (it is one of four 3TB dis= k drives), I > > gather these informations: > >=20 > > [... smartctl -x /dev/ada6 ...] > > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 day= s + 15 hours) > > When the command that caused the error occurred, the device was activ= e or idle. > >=20 > > After command completion occurred, registers were: > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- > > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc27a7= 298 =3D 3262804632 > >=20 > > Commands leading to the command that caused the error were: > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feat= ure_Name > > -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- ---------= ------ -------------------- > > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA Q= UEUED > > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA Q= UEUED > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT > > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA Q= UEUED > > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA Q= UEUED > > [...] > >=20 > > and > >=20 > > [...] > > SMART Attributes Data Structure revision number: 16 > > Vendor Specific SMART Attributes with Thresholds: > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > ||||||_ K auto-keep > > |||||__ C event count > > ||||___ R error rate > > |||____ S speed/performance > > ||_____ O updated online > > |______ P prefailure warning > >=20 > > [...] =20 >=20 > The data up to this point informs us that you have 1 bad sector > on a 3TB drive, that is actually an expected event given the data > error rate on this stuff is such that your gona have these now > and again. >=20 > Given you have 1 single event I would not suspect that this drive > is dying, but it would be prudent to prepare for that possibility. Hello. Well, I copied simply "one single event" that has been logged so far. As you (and I) can see, it is error #42. After I posted here, a reboot has = taken place because the "repair" process on the Pool suddenly increased time and now I'= m with error #47, but interestingly, it is a new block that is damaged, but the SMART at= tribute fields show this for now: [...] SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 3 Spin_Up_Time POS--K 178 170 021 - 6075 4 Start_Stop_Count -O--CK 098 098 000 - 2406 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 9 Power_On_Hours -O--CK 066 066 000 - 25343 10 Spin_Retry_Count -O--CK 100 100 000 - 0 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 194 Temperature_Celsius -O---K 122 109 000 - 28 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 0 198 Offline_Uncorrectable ----CK 200 200 000 - 1 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning [...] 197 Current_Pending_Sector decreased to zero so far, but with every reboot,= the error count seems to increase: [...] Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 d0 00 00 c2 19 da 28 40 08 1d+07:12:34.336 READ FPDMA QUEUED 60 00 b0 00 c8 00 00 c2 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUED 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUED I think this is watching a HDD dying, isn't it? I'd say, a broken cabling would produce different errors, wouldn't it? The Western Digital Green series HDD is a useful fellow when the HDD is use= d as a single drive. I think there might be an issue with paring 4 HDDs, 3 of them "GREEN= ", in a RAIDZ and physically sitting next to each other. Maybe it is time to replace them= one by one ... >=20 >=20 > >=20 > > The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one WD RED = 3 TB HDD. The > > failure occured is on one of the WD Green 3 TB HDD. =20 > Ok, so the data is redundantly protected. This helps a lot. >=20 > > The pool is marked as "resilvered" - I do scrubbing on a regular basis = and the > > "resilvering" message has now aapeared the second time in row. Searchin= g the net > > recommend on SMART attribute 197 errors, in my case it is one, and in c= ombination with > > the problems occured that I should replace the disk. =20 >=20 > It is probably putting the RAIDZ in that state as the scrub is finding a = block > it can not read. >=20 > >=20 > > Well, here comes the problem. The box is comprised from "electronical w= aste" made by > > ASRock - it is a Socket 1150/IvyBridge board, which has its last Firmwa= re/BIOS update > > got in 2013 and since then UEFI booting FreeBSD from a HDD isn't possib= le (just to > > indicate that I'm aware of having issues with crap, but that is some ot= her issue > > right now). The board's SATA connectors are all populated. > >=20 > > So: Due to the lack of adequate backup space I can only selectively bac= kup portions, > > most of the space is occupied by scientific modelling data, which I had= worked on. So > > backup exists! In one way or the other. My concern is how to replace th= e faulty HDD! > > Most HowTo's indicate a replacement disk being prepared and then "repla= ced" via ZFS's > > replace command. This isn't applicable here. > >=20 > > Question: is it possible to simply pull the faulty disk (implies I know= exactly which > > one to pull!) and then prepare and add the replacement HDD and let the = system do its > > job resilvering the pool? =20 >=20 > That may work, but I think I have a simpler solution. >=20 > >=20 > > Next question is: I'm about to replace the 3 TB HDD with a more recent = and modern 4 TB > > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the= other disks > > are 3 TB, but I'd like to know whether FreeBSD's ZFS is capable of hand= ling it? =20 >=20 > Someone else? >=20 > >=20 > > This is the first time I have issues with ZFS and a faulty drive, so if= some of my > > questions sound naive, please forgive me. =20 >=20 > One thing to try is to see if we can get the drive to fix itself, first o= rder > of business is can you take this server out of service? If so I would > simply try to do a > repeat 100 dd if=3D/dev/whicheverhdisbad of=3D/dev/null conv=3Dnoerror, s= ync iseek=3D3262804632 >=20 > That is trying to read that block 100 times, if it successful even 1 time > smart should remap the block and you are all done. Given the fact, that this errorneous block is like a moving target, it this= solution still the favorite one? I'll try, but I already have the replacement 4 TB H= DD at hand. >=20 > If that fails we can try to zero the block, there is a risk here, but rai= dz should just > handle this as a data corruption of a block. This could possibly lead to= data loss, > so USE AT YOUR OWN RISK ASSESMENT. > dd if=3D/dev/zero of=3D/dev/whateverdrivehasissues bs=3D512 count=3D1 ose= ek=3D3262804632 I would then be oseek=3D3256473992, too. >=20 > That should forceable overwrite the bad block with 0's, the smart firmware > well see this in the pending list, write the data, read it back, if succe= ssful > remove it from the pending list, if failed reallocate the block and write > the 0's to the reallocation and add 1 to the remapped block count. >=20 > You might google for "how to fix a pending reallocation" >=20 > > Thanks in advance, > > Oliver > > --=20 > > O. Hartmann =20 >=20 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_/QYT9Wra0yqX6hyEFFfRyrQZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjBV0gAKCRDS528fyFhY lOZDAf0fajjJMeGcTKvmMoTlc8AoxCH1Sh8FOWqMdhgMplaEctPUYNd0KeXfoXX3 Pah6/Rs1N1Ypzj7BM/wybCGSbrf4Af9asahtCJ66Qnr+HydE4hby6aJcLLehGpqc URxnHDu0kanXce95f2+/1q7smr0Mdf28dVj0qccN5vIkGEn4Nkh3 =Irs3 -----END PGP SIGNATURE----- --Sig_/QYT9Wra0yqX6hyEFFfRyrQZ-- From owner-freebsd-current@freebsd.org Tue Dec 12 22:58: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 84DD3E87D57 for ; Tue, 12 Dec 2017 22:58:39 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 42F5C77117; Tue, 12 Dec 2017 22:58:38 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id OtVNesatfp2osOtVOeJiDv; Tue, 12 Dec 2017 15:58:32 -0700 X-Authority-Analysis: v=2.2 cv=KLEqNBNo c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=ocR9PWop10UA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=iKhvJSA4AAAA:8 a=QaFPDjgRRQkh4GSrB6QA:9 a=6pCtFBtut8bTVypo:21 a=3ge-KubrqmnXQUf8:21 a=QEXdDO2ut3YA:10 a=jkd8HGfWraxzm8Cd1awA:9 a=8gwv1ZuDhNe8EdX7:21 a=JIcB6NhWvQbpWVuT:21 a=PIwEOpKiG8dlj1kq:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=odh9cflL3HIXMm4fY7Wr:22 Received: from [25.81.38.66] (S0106d4ca6d8943b0.gv.shawcable.net [24.68.134.59]) by spqr.komquats.com (Postfix) with ESMTPSA id CBCF2266; Tue, 12 Dec 2017 14:58:27 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error Date: Tue, 12 Dec 2017 14:58:28 -0800 To: "O. Hartmann" , "Rodney W. Grimes" CC: FreeBSD CURRENT , Freddie Cash , Alan Somers Message-Id: <20171212225827.CBCF2266@spqr.komquats.com> X-CMAE-Envelope: MS4wfMQ/99Ijn4dNclK4c5aRGAeJ4QabyKPCe7xwxg22MiZJ3/OuyKL7f2vFvTj7fkUv3kX/DA5ktphEkRVDepFc+UmVZgZPD8iGy+7c7KQz4jKxKTd7/VBv hBl0hSGk7oWk61jPS/HT3O6cgnYt1ke2jUjbfvPPCwvMj8ScjDqtVL4jbtdqugQLHtQpE5Ppg+AVtsYdYu7/KSMmluLEBwbq9XWqVpQ68391zUrzHQfTLO2P bGhc1OvI2GBXGGbAF2JoR2JUmYLXtoLK8AfnR2XaC/ytHaiEWLnaQthiCnNoJg/IbU9ob54XTM2fLgr/A5Rp0ZcG4KAZ3d1c1k9G6X2KmiY= 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, 12 Dec 2017 22:58:39 -0000 There are a couple of ways you can address this. You'll need to offline the= vdev first. If you've done a smartcrl -t long and if the test failed, smar= tcrl -a will tell you which block it had an issue with. You can use dd, ddr= escue or dd_rescue to dd the block over itself. The drive may rewrite the (= weak) block or if it fails to it will remap it (subsequently showing as rea= llocated). Of course there is a risk. If the sector is any of the boot blocks there is= a good chance the server will hang. You have to be *absolutely* sure which the bad sector is. And, there may be= more. There is a risk of data loss. I've used this technique many times. Most times it works perfectly. Other t= imes the affected file is lost but the rest of the file system is recovered= . And again there is always the risk. Replace the disk immediately if you experience a growing succession of pend= ing sectors. Otherwise replace the disk at your earliest convenience. If using a zfs mirror (not in your case) detatch and attach will rewrite an= y weakly written sectors and reallocate pending sectors. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: O. Hartmann Sent: 12/12/2017 14:19 To: Rodney W. Grimes Cc: O. Hartmann; FreeBSD CURRENT; Freddie Cash; Alan Somers Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM= status: ATA Status Error Am Tue, 12 Dec 2017 10:52:27 -0800 (PST) "Rodney W. Grimes" schrieb: Thank you for answering that fast! > > Hello, > >=20 > > running CURRENT (recent r326769), I realised that smartmond sends out s= ome console > > messages when booting the box: > >=20 > > [...] > > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currentl= y unreadable > > (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /de= v/ada6, 1 > > Offline uncorrectable sectors > > [...] > >=20 > > Checking the drive's SMART log with smartctl (it is one of four 3TB dis= k drives), I > > gather these informations: > >=20 > > [... smartctl -x /dev/ada6 ...] > > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 day= s + 15 hours) > > When the command that caused the error occurred, the device was activ= e or idle. > >=20 > > After command completion occurred, registers were: > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- > > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc27a7= 298 =3D 3262804632 > >=20 > > Commands leading to the command that caused the error were: > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feat= ure_Name > > -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- ---------= ------ -------------------- > > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA Q= UEUED > > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA Q= UEUED > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT > > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA Q= UEUED > > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA Q= UEUED > > [...] > >=20 > > and > >=20 > > [...] > > SMART Attributes Data Structure revision number: 16 > > Vendor Specific SMART Attributes with Thresholds: > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > ||||||_ K auto-keep > > |||||__ C event count > > ||||___ R error rate > > |||____ S speed/performance > > ||_____ O updated online > > |______ P prefailure warning > >=20 > > [...] =20 >=20 > The data up to this point informs us that you have 1 bad sector > on a 3TB drive, that is actually an expected event given the data > error rate on this stuff is such that your gona have these now > and again. >=20 > Given you have 1 single event I would not suspect that this drive > is dying, but it would be prudent to prepare for that possibility. Hello. Well, I copied simply "one single event" that has been logged so far. As you (and I) can see, it is error #42. After I posted here, a reboot has = taken place because the "repair" process on the Pool suddenly increased time and now I'= m with error #47, but interestingly, it is a new block that is damaged, but the SMART at= tribute fields show this for now: [...] SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 3 Spin_Up_Time POS--K 178 170 021 - 6075 4 Start_Stop_Count -O--CK 098 098 000 - 2406 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 9 Power_On_Hours -O--CK 066 066 000 - 25343 10 Spin_Retry_Count -O--CK 100 100 000 - 0 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 194 Temperature_Celsius -O---K 122 109 000 - 28 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 0 198 Offline_Uncorrectable ----CK 200 200 000 - 1 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning [...] 197 Current_Pending_Sector decreased to zero so far, but with every reboot,= the error count seems to increase: [...] Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 d0 00 00 c2 19 da 28 40 08 1d+07:12:34.336 READ FPDMA QUEUE= D 60 00 b0 00 c8 00 00 c2 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA QUEUE= D 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUE= D 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUE= D I think this is watching a HDD dying, isn't it? I'd say, a broken cabling would produce different errors, wouldn't it? The Western Digital Green series HDD is a useful fellow when the HDD is use= d as a single drive. I think there might be an issue with paring 4 HDDs, 3 of them "GREEN= ", in a RAIDZ and physically sitting next to each other. Maybe it is time to replace them= one by one ... >=20 >=20 > >=20 > > The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one WD RED = 3 TB HDD. The > > failure occured is on one of the WD Green 3 TB HDD. =20 > Ok, so the data is redundantly protected. This helps a lot. >=20 > > The pool is marked as "resilvered" - I do scrubbing on a regular basis = and the > > "resilvering" message has now aapeared the second time in row. Searchin= g the net > > recommend on SMART attribute 197 errors, in my case it is one, and in c= ombination with > > the problems occured that I should replace the disk. =20 >=20 > It is probably putting the RAIDZ in that state as the scrub is finding a = block > it can not read. >=20 > >=20 > > Well, here comes the problem. The box is comprised from "electronical w= aste" made by > > ASRock - it is a Socket 1150/IvyBridge board, which has its last Firmwa= re/BIOS update > > got in 2013 and since then UEFI booting FreeBSD from a HDD isn't possib= le (just to > > indicate that I'm aware of having issues with crap, but that is some ot= her issue > > right now). The board's SATA connectors are all populated. > >=20 > > So: Due to the lack of adequate backup space I can only selectively bac= kup portions, > > most of the space is occupied by scientific modelling data, which I had= worked on. So > > backup exists! In one way or the other. My concern is how to replace th= e faulty HDD! > > Most HowTo's indicate a replacement disk being prepared and then "repla= ced" via ZFS's > > replace command. This isn't applicable here. > >=20 > > Question: is it possible to simply pull the faulty disk (implies I know= exactly which > > one to pull!) and then prepare and add the replacement HDD and let the = system do its > > job resilvering the pool? =20 >=20 > That may work, but I think I have a simpler solution. >=20 > >=20 > > Next question is: I'm about to replace the 3 TB HDD with a more recent = and modern 4 TB > > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the= other disks > > are 3 TB, but I'd like to know whether FreeBSD's ZFS is capable of hand= ling it? =20 >=20 > Someone else? >=20 > >=20 > > This is the first time I have issues with ZFS and a faulty drive, so if= some of my > > questions sound naive, please forgive me. =20 >=20 > One thing to try is to see if we can get the drive to fix itself, first o= rder > of business is can you take this server out of service? If so I would > simply try to do a > repeat 100 dd if=3D/dev/whicheverhdisbad of=3D/dev/null conv=3Dnoerror, s= ync iseek=3D3262804632 >=20 > That is trying to read that block 100 times, if it successful even 1 time > smart should remap the block and you are all done. Given the fact, that this errorneous block is like a moving target, it this= solution still the favorite one? I'll try, but I already have the replacement 4 TB H= DD at hand. >=20 > If that fails we can try to zero the block, there is a risk here, but rai= dz should just > handle this as a data corruption of a block. This could possibly lead to= data loss, > so USE AT YOUR OWN RISK ASSESMENT. > dd if=3D/dev/zero of=3D/dev/whateverdrivehasissues bs=3D512 count=3D1 ose= ek=3D3262804632 I would then be oseek=3D3256473992, too. >=20 > That should forceable overwrite the bad block with 0's, the smart firmwar= e > well see this in the pending list, write the data, read it back, if succe= ssful > remove it from the pending list, if failed reallocate the block and write > the 0's to the reallocation and add 1 to the remapped block count. >=20 > You might google for "how to fix a pending reallocation" >=20 > > Thanks in advance, > > Oliver > > --=20 > > O. Hartmann =20 >=20 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). From owner-freebsd-current@freebsd.org Tue Dec 12 23:19:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F3D9E88649 for ; Tue, 12 Dec 2017 23:19:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (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 0A83E77C29 for ; Tue, 12 Dec 2017 23:19:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18503 invoked from network); 12 Dec 2017 23:19:24 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Dec 2017 23:19:24 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 18:19:24 -0500 (EST) Received: (qmail 9279 invoked from network); 12 Dec 2017 23:19:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 12 Dec 2017 23:19:24 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 14E6FEC814E; Tue, 12 Dec 2017 15:19:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot From: Mark Millard In-Reply-To: <4b2420e8899.5992ee2b@mail.schwarzes.net> Date: Tue, 12 Dec 2017 15:19:23 -0800 Cc: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> To: Andreas Schwarz 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: Tue, 12 Dec 2017 23:19:32 -0000 On 2017-Dec-12, at 2:02 PM, Andreas Schwarz = wrote: > On 12.12.17, Mark Millard wrote: >=20 >> I initially jumped from -r326192 to -r326726 and >> ended up with a rpi2 that would normally hang >> somewhere around release APs being displayed. >> (I have had a couple of completed boots but many >> dozens of hung-up attempts.) Both a debug kernel >> and a non-debug kernel hang the same way. >>=20 >> Bisecting the kernel (holding world -r326726 >> constant) showed: >>=20 >> -r326346 did not hang (nor did before) >> -r326347 and later hung. >=20 > JFYI, the latest kernel (and world) running at one of my=20 > RPI2-B is r326631, without any issues. Interesting. (By the way: My context is with a V1.1 Cortex-A7 based rpi2, not V1.2 and Cortex-A53.) I've almost always run the root file system being on a USB SSD instead of on mmcsd0 . I wonder if that is somehow involved since it may be unusual. UFS file system. The USB SSD is on a powered hub that is in turn plugged into the rpi2. [I had the hang problem before the following and after.] The mechanism for holding mmcsd0 in failed recently but the ejection mechanism still works. So I hold in mmcsd0 until after I get a USB SSD boot now. (Interrupt boot, unload, boot/autoboot, picks up the kernel from the USB SSD.) This means that I effectively can not avoid the USB SSD any more unless I get my hands on a different V1.1 rpi2. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Tue Dec 12 18:52:28 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 E420CEA2D65 for ; Tue, 12 Dec 2017 18:52:28 +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 AB7D26B9B9 for ; Tue, 12 Dec 2017 18:52:28 +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 vBCIqRGm087702; Tue, 12 Dec 2017 10:52:27 -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 vBCIqRuZ087701; Tue, 12 Dec 2017 10:52:27 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712121852.vBCIqRuZ087701@pdx.rh.CN85.dnsmgr.net> Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error In-Reply-To: <20171212192220.119ca2d3@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" Date: Tue, 12 Dec 2017 10:52:27 -0800 (PST) CC: 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, 12 Dec 2017 23:22:04 +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, 12 Dec 2017 18:52:29 -0000 > Hello, > > running CURRENT (recent r326769), I realised that smartmond sends out some console > messages when booting the box: > > [...] > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currently unreadable > (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 > Offline uncorrectable sectors > [...] > > Checking the drive's SMART log with smartctl (it is one of four 3TB disk drives), I > gather these informations: > > [... smartctl -x /dev/ada6 ...] > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 days + 15 hours) > When the command that caused the error occurred, the device was active or idle. > > After command completion occurred, registers were: > ER -- ST COUNT LBA_48 LH LM LL DV DC > -- -- -- == -- == == == -- -- -- -- -- > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = 3262804632 > > Commands leading to the command that caused the error were: > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name > -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA QUEUED > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA QUEUED > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA QUEUED > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA QUEUED > [...] > > and > > [...] > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > 194 Temperature_Celsius -O---K 122 109 000 - 28 > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning > > [...] The data up to this point informs us that you have 1 bad sector on a 3TB drive, that is actually an expected event given the data error rate on this stuff is such that your gona have these now and again. Given you have 1 single event I would not suspect that this drive is dying, but it would be prudent to prepare for that possibility. > > The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one WD RED 3 TB HDD. The > failure occured is on one of the WD Green 3 TB HDD. Ok, so the data is redundantly protected. This helps a lot. > The pool is marked as "resilvered" - I do scrubbing on a regular basis and the > "resilvering" message has now aapeared the second time in row. Searching the net > recommend on SMART attribute 197 errors, in my case it is one, and in combination with > the problems occured that I should replace the disk. It is probably putting the RAIDZ in that state as the scrub is finding a block it can not read. > > Well, here comes the problem. The box is comprised from "electronical waste" made by > ASRock - it is a Socket 1150/IvyBridge board, which has its last Firmware/BIOS update got > in 2013 and since then UEFI booting FreeBSD from a HDD isn't possible (just to indicate > that I'm aware of having issues with crap, but that is some other issue right now). The > board's SATA connectors are all populated. > > So: Due to the lack of adequate backup space I can only selectively backup portions, most > of the space is occupied by scientific modelling data, which I had worked on. So backup > exists! In one way or the other. My concern is how to replace the faulty HDD! Most > HowTo's indicate a replacement disk being prepared and then "replaced" via ZFS's replace > command. This isn't applicable here. > > Question: is it possible to simply pull the faulty disk (implies I know exactly which one > to pull!) and then prepare and add the replacement HDD and let the system do its job > resilvering the pool? That may work, but I think I have a simpler solution. > > Next question is: I'm about to replace the 3 TB HDD with a more recent and modern 4 TB > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the other disks are 3 > TB, but I'd like to know whether FreeBSD's ZFS is capable of handling it? Someone else? > > This is the first time I have issues with ZFS and a faulty drive, so if some of my > questions sound naive, please forgive me. One thing to try is to see if we can get the drive to fix itself, first order of business is can you take this server out of service? If so I would simply try to do a repeat 100 dd if=/dev/whicheverhdisbad of=/dev/null conv=noerror, sync iseek=3262804632 That is trying to read that block 100 times, if it successful even 1 time smart should remap the block and you are all done. If that fails we can try to zero the block, there is a risk here, but raidz should just handle this as a data corruption of a block. This could possibly lead to data loss, so USE AT YOUR OWN RISK ASSESMENT. dd if=/dev/zero of=/dev/whateverdrivehasissues bs=512 count=1 oseek=3262804632 That should forceable overwrite the bad block with 0's, the smart firmware well see this in the pending list, write the data, read it back, if successful remove it from the pending list, if failed reallocate the block and write the 0's to the reallocation and add 1 to the remapped block count. You might google for "how to fix a pending reallocation" > Thanks in advance, > Oliver > -- > O. Hartmann -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Dec 12 22:03: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 AB0F7E868BF; Tue, 12 Dec 2017 22:03:20 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 4EE08753D8; Tue, 12 Dec 2017 22:03:19 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dba65d2.dyn.telefonica.de [77.186.101.210]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vBCM2iHt062687; Tue, 12 Dec 2017 23:02:44 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Mark Millard CC: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 12 Dec 2017 23:02:44 +0100 (CET) Message-ID: <4b2420e8899.5992ee2b@mail.schwarzes.net> In-Reply-To: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Tue, 12 Dec 2017 23:02:45 +0100 (CET) X-Mailman-Approved-At: Tue, 12 Dec 2017 23:22:25 +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, 12 Dec 2017 22:03:20 -0000 On 12.12.17, Mark Millard wrote: > I initially jumped from -r326192 to -r326726 and > ended up with a rpi2 that would normally hang > somewhere around release APs being displayed. > (I have had a couple of completed boots but many > dozens of hung-up attempts.) Both a debug kernel > and a non-debug kernel hang the same way. > > Bisecting the kernel (holding world -r326726 > constant) showed: > > -r326346 did not hang (nor did before) > -r326347 and later hung. JFYI, the latest kernel (and world) running at one of my RPI2-B is r326631, without any issues. -asc From owner-freebsd-current@freebsd.org Tue Dec 12 22:55:53 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 8534BE87CFF for ; Tue, 12 Dec 2017 22:55:53 +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 49BB2770D6; Tue, 12 Dec 2017 22:55:53 +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 vBCMtnVN088890; Tue, 12 Dec 2017 14:55:49 -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 vBCMtnfZ088889; Tue, 12 Dec 2017 14:55:49 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712122255.vBCMtnfZ088889@pdx.rh.CN85.dnsmgr.net> Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error In-Reply-To: <20171212231858.294a2cb5@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" Date: Tue, 12 Dec 2017 14:55:49 -0800 (PST) CC: FreeBSD CURRENT , Freddie Cash , Alan Somers 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, 12 Dec 2017 23:23:06 +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, 12 Dec 2017 22:55:53 -0000 > Am Tue, 12 Dec 2017 10:52:27 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > Thank you for answering that fast! > > > > Hello, > > > > > > running CURRENT (recent r326769), I realised that smartmond sends out some console > > > messages when booting the box: > > > > > > [...] > > > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currently unreadable > > > (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 > > > Offline uncorrectable sectors > > > [...] > > > > > > Checking the drive's SMART log with smartctl (it is one of four 3TB disk drives), I > > > gather these informations: > > > > > > [... smartctl -x /dev/ada6 ...] > > > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 days + 15 hours) > > > When the command that caused the error occurred, the device was active or idle. > > > > > > After command completion occurred, registers were: > > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > > -- -- -- == -- == == == -- -- -- -- -- > > > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = 3262804632 > > > > > > Commands leading to the command that caused the error were: > > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name > > > -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- > > > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA QUEUED > > > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA QUEUED > > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT > > > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA QUEUED > > > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA QUEUED > > > [...] > > > > > > and > > > > > > [...] > > > SMART Attributes Data Structure revision number: 16 > > > Vendor Specific SMART Attributes with Thresholds: > > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > > ||||||_ K auto-keep > > > |||||__ C event count > > > ||||___ R error rate > > > |||____ S speed/performance > > > ||_____ O updated online > > > |______ P prefailure warning > > > > > > [...] > > > > The data up to this point informs us that you have 1 bad sector > > on a 3TB drive, that is actually an expected event given the data > > error rate on this stuff is such that your gona have these now > > and again. > > > > Given you have 1 single event I would not suspect that this drive > > is dying, but it would be prudent to prepare for that possibility. > > Hello. > > Well, I copied simply "one single event" that has been logged so far. > > As you (and I) can see, it is error #42. After I posted here, a reboot has taken place > because the "repair" process on the Pool suddenly increased time and now I'm with error > #47, but interestingly, it is a new block that is damaged, but the SMART attribute fields > show this for now: Can you send the complete output of smartctl -a /dev/foo, I somehow missed that 40+ other errors had occured. > [...] > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 Interesting, no reallocation has occured.... > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > 9 Power_On_Hours -O--CK 066 066 000 - 25343 > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 Hum, just noticed this. 25k hours power on, 2M load cycles, this is very hard on a hard drive. Your drive is going into power save mode and unloading the heads. Infact at a rate of 81 times per hour? Oh, I can not believe that. Either way we need to get this stopped, it shall wear your drives out. > 194 Temperature_Celsius -O---K 122 109 000 - 28 > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > 197 Current_Pending_Sector -O--CK 200 200 000 - 0 > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning > [...] > > > 197 Current_Pending_Sector decreased to zero so far, but with every reboot, the error > count seems to increase: Ok, some drive firmware well at the power on even try to test the pending sector list and clear it if it can actually read the sector. > > [...] > Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 days + 23 hours) > When the command that caused the error occurred, the device was active or idle. > > After command completion occurred, registers were: > ER -- ST COUNT LBA_48 LH LM LL DV DC > -- -- -- == -- == == == -- -- -- -- -- > 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 > > Commands leading to the command that caused the error were: > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name > -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- > 60 00 b0 00 d0 00 00 c2 19 da 28 40 08 1d+07:12:34.336 READ FPDMA QUEUED > 60 00 b0 00 c8 00 00 c2 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA QUEUED > 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT > 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUED > 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUED > > > I think this is watching a HDD dying, isn't it? It could be, need to see as many of the other 46 errors as we can to make a decision on that. Probably only 5 in the log though. > I'd say, a broken cabling would produce different errors, wouldn't it? Yes, there is a CRC error that would occur on cabling error. > The Western Digital Green series HDD is a useful fellow when the HDD is used as a single > drive. I think there might be an issue with paring 4 HDDs, 3 of them "GREEN", in a RAIDZ > and physically sitting next to each other. Maybe it is time to replace them one by one ... I am more suspecioius of them loading and unloading the head at a rate of more than once per minute! > > > > > > > > > > The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one WD RED 3 TB HDD. The > > > failure occured is on one of the WD Green 3 TB HDD. > > Ok, so the data is redundantly protected. This helps a lot. > > > > > The pool is marked as "resilvered" - I do scrubbing on a regular basis and the > > > "resilvering" message has now aapeared the second time in row. Searching the net > > > recommend on SMART attribute 197 errors, in my case it is one, and in combination with > > > the problems occured that I should replace the disk. > > > > It is probably putting the RAIDZ in that state as the scrub is finding a block > > it can not read. > > > > > > > > Well, here comes the problem. The box is comprised from "electronical waste" made by > > > ASRock - it is a Socket 1150/IvyBridge board, which has its last Firmware/BIOS update > > > got in 2013 and since then UEFI booting FreeBSD from a HDD isn't possible (just to > > > indicate that I'm aware of having issues with crap, but that is some other issue > > > right now). The board's SATA connectors are all populated. > > > > > > So: Due to the lack of adequate backup space I can only selectively backup portions, > > > most of the space is occupied by scientific modelling data, which I had worked on. So > > > backup exists! In one way or the other. My concern is how to replace the faulty HDD! > > > Most HowTo's indicate a replacement disk being prepared and then "replaced" via ZFS's > > > replace command. This isn't applicable here. > > > > > > Question: is it possible to simply pull the faulty disk (implies I know exactly which > > > one to pull!) and then prepare and add the replacement HDD and let the system do its > > > job resilvering the pool? > > > > That may work, but I think I have a simpler solution. > > > > > > > > Next question is: I'm about to replace the 3 TB HDD with a more recent and modern 4 TB > > > HDD (WD RED 4TB). I'm aware of the fact that I can only use 3 TB as the other disks > > > are 3 TB, but I'd like to know whether FreeBSD's ZFS is capable of handling it? > > > > Someone else? > > > > > > > > This is the first time I have issues with ZFS and a faulty drive, so if some of my > > > questions sound naive, please forgive me. > > > > One thing to try is to see if we can get the drive to fix itself, first order > > of business is can you take this server out of service? If so I would > > simply try to do a > > repeat 100 dd if=/dev/whicheverhdisbad of=/dev/null conv=noerror, sync iseek=3262804632 > > > > That is trying to read that block 100 times, if it successful even 1 time > > smart should remap the block and you are all done. > > Given the fact, that this errorneous block is like a moving target, it this solution > still the favorite one? I'll try, but I already have the replacement 4 TB HDD at hand. It could also be experince a problem I have with one of my 500G western digital drives. It has a sector that is marginal, it fails to read now and then, so ends up in the pending list. As soon as I write to that sector the drive decides it is fine and removes it from the pending list. This has been repeating for 10 uears now. If I have ufs on the drive I used old badsect tools to hide it away, but eventually I wipe the drive and end up back in this situation. > > > > If that fails we can try to zero the block, there is a risk here, but raidz should just > > handle this as a data corruption of a block. This could possibly lead to data loss, > > so USE AT YOUR OWN RISK ASSESMENT. > > dd if=/dev/zero of=/dev/whateverdrivehasissues bs=512 count=1 oseek=3262804632 > > I would then be oseek=3256473992, too. Maybe do A dd READ over a range of blocks 100k blocks on each side of these suspect areas: dd if=/dev/FOO of=/dev/null bs=512 iseek=3262704632 count=200k dd if=/dev/FOO of=/dev/null bs=512 iseek=3256473992 count=200k I have tools that do this type of operation but record the time to complete the operation, I look over that list for outliers indicating the drive has done retries. OHHHH.. um.. there is a sysctl to turn off ata retries, probalby should hit that too. kern.cam.ada.retry_count: 4 Do not attempt to write the sector unless it reproducable gives a read error as it wont do any good. > > > > That should forceable overwrite the bad block with 0's, the smart firmware > > well see this in the pending list, write the data, read it back, if successful > > remove it from the pending list, if failed reallocate the block and write > > the 0's to the reallocation and add 1 to the remapped block count. > > > > You might google for "how to fix a pending reallocation" > > > > > Thanks in advance, > > > Oliver > > > -- > > > O. Hartmann > > > > Kind regards, > Oliver > -- > O. Hartmann -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Dec 12 23:23:06 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 98185E88BEC for ; Tue, 12 Dec 2017 23:23:06 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 5B47C785D0 for ; Tue, 12 Dec 2017 23:23:05 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBCNOSds089279; Tue, 12 Dec 2017 15:24:34 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD Current" In-Reply-To: <4bf0ab6fe9f034b9ec007f13c72092af@udns.ultimatedns.net> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Warner Losh" Subject: Re: 12-r326622 install won't boot Date: Tue, 12 Dec 2017 15:24:34 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Tue, 12 Dec 2017 23:23:06 -0000 On Tue, 12 Dec 2017 13:56:56 -0800 said > On Tue, 12 Dec 2017 14:33:10 -0700 "Warner Losh" said >=20 > > On Tue, Dec 12, 2017 at 2:28 PM, Chris H wrote= : > >=20 > > > On Tue, 12 Dec 2017 11:37:33 -0800 said > > > > > > Hello all, > > >> I just blew away a old RELENG_11, to start working with current=2E I > > >> must admit I had several disappointments regarding the installer=2E > > >> But that's for another topic, and another time=2E > > >> To the point; > > >> I completed the install=2E The only event(s) that might be notable > > >> during the install=2E Was early on during (boot?) I saw a "dumped core= " > > >> race past on the screen=2E I also experienced at least 1 LOR=2E But the > > >> install continued, seemingly un(interrupted|affected)=2E That said, I > > >> chose the reboot option after completion=2E Ejected the DVD during POS= T, > > >> and I'm stuck at: > > >> > > >> BTX loader 1=2E00 BTX version is 1=2E02 > > >> Consoles: internal video/keyboard > > >> > > >> followed by 2 gibberish characters; 1 appears as a right pointing ar= row, > > >> the other, kind of like a battlestar galactca spaceship=2E > > >> NOTE: those 2 characters did not show up on the initial reboot from > > >> the install (just the 2 lines above)=2E But after I attempted a hard > > >> reset after the first fail=2E > > >> > > > OK tried the installation again, and nothings changed=2E > > > Still left with the 2 lines listed above=2E > > > > > > Guess I'll have to wait until 12-CURRENT becomes a usable version=2E > > > Sigh=2E=2E=2E > > > I was really hoping to run 12, so I could better develop 11=2E > > > Oh well=2E Guess I'll grab a copy of 11 off one of the ftp servers, and= spin > > > it > > > up=2E > > > > > > Thanks anyway! :-) > >=20 > >=20 > >=20 > > I think a two-week old snapshot would work a lot better if you wanted t= o > > make the jump to -current=2E I've botched something in my boot loader cle= anup > > and it's taking a little time to get sorted out=2E=2E=2E > OH, thank you *very* much, Warner! > Whew! Just in time, too=2E I had almost slipped the 11 DVD into the box=2E >=20 > Thanks again, Warner=2E Hope the things go well for you=2E >=20 > --Chris Spot on, Warner! r326056 gave me a working 12-CURRENT=2E Including all the LORs=2E :-) Thank you! --Chris > >=20 > > Warner > >=20 > >=20 > > > > > > --Chris > > > > > > > > >> Thank you for all your time, and consideration=2E > > >> > > >> --Chris > > >> > > >> >=20 >=20 > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Tue Dec 12 23:26:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E024E88F48 for ; Tue, 12 Dec 2017 23:26:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4ABA78A12; Tue, 12 Dec 2017 23:26:09 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id f20so600230lfe.3; Tue, 12 Dec 2017 15:26:09 -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=IbuabOlbZfKjrZdrteHLdVk2hRXlWPXUW61Ncm9u+X0=; b=Ono8mkMUZ/QYESPf1eY6UBypeYKkKZ0fMxnh0lVZExxWqRon8TF5ibF9yb9PqBiegA ZUlR2Pc6uEbVMe3XQ8J2Cwe7lQonLKw0ku8+XkzHhjV68oRTDOFOLeAGHRa+Ji1tKbLq 1KJ5P0ZQKmV1zyFAe8KqUmBr+wQCr/yyCW/Rek3YZmF4spp3p8QmjKAlpoCZLbyN2wMF 0SCHYT1f5Z8cRabQejrljJBrAs8PbCEsxsbZ6siXvRLBblA1E5CzJ1NrKo1/bP2JH9PE Q1YBtvJl8RkfoJr8HBzA47y3yCkOxys87d9ZQloLV2LDkLewlPxgkJlr1LYTkDR4l05W Vzmg== 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=IbuabOlbZfKjrZdrteHLdVk2hRXlWPXUW61Ncm9u+X0=; b=nDGFdQfaqefSuqFtLjikfq2vT4EOq7xNVyLAiC1TATKaThACdJ1zA9VHHLIeHBfG/o s1AcJU31vVM3gra6FTxGx0NuDMfklShT9CLHfMpACeyWHnnDvisi4Sezi5GMV8MMTf45 uxjmRiQ6sAAkuSknws1XSStLqZw/FyXz8RbOqupAsEVENdwRedWXJRYNXFXyN8Ptv8r+ E3pJIGYQh11eq3BdXa8p+t19Mg60VAl9HSqTCj9a3rnA7MqVe3ayARy8hYrddk6Kczul JzVjgnzzcvqfQw80BP1kugjuRbzNXDNk0MGZRmCGGjYIhCZanWCDP8jFSgdvyue2k/6w NP6w== X-Gm-Message-State: AKGB3mJMPoPFnQbypn8OZiD2uQxqQj2D5h/3xFjl6J1AzoHg7dfj6cF5 uZAR5RMDhHoycbjmRygOvgE1Ll55sKQCuOJatvg= X-Google-Smtp-Source: ACJfBosBVVooPd11w0VoYruWgz0TCOBVggdDJy165z/CJe3PZbnkNSZl52/nAuosi3h4dmOodRz5CJC0HIXeJCfW5Xg= X-Received: by 10.25.181.193 with SMTP id g62mr267444lfk.43.1513121167756; Tue, 12 Dec 2017 15:26:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.145 with HTTP; Tue, 12 Dec 2017 15:26:07 -0800 (PST) In-Reply-To: <201712122255.vBCMtnfZ088889@pdx.rh.CN85.dnsmgr.net> References: <20171212231858.294a2cb5@thor.intern.walstatt.dynvpn.de> <201712122255.vBCMtnfZ088889@pdx.rh.CN85.dnsmgr.net> From: Freddie Cash Date: Tue, 12 Dec 2017 15:26:07 -0800 Message-ID: Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error To: "Rodney W. Grimes" Cc: "O. Hartmann" , FreeBSD CURRENT , Alan Somers 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, 12 Dec 2017 23:26:10 -0000 On Tue, Dec 12, 2017 at 2:55 PM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > Hum, just noticed this. 25k hours power on, 2M load cycles, this is > very hard on a hard drive. Your drive is going into power save mode > and unloading the heads. Infact at a rate of 81 times per hour? > Oh, I can not believe that. Either way we need to get this stopped, > it shall wear your drives out. > =E2=80=8BBelieve it. :) The WD Green drives have a head parking timeout o= f 15 seconds, and no way to disable that anymore. You used to be able to boot into DOS and run the tler.exe program from WD to disable the auto-parking feature, but they removed that ability fairly quickly. The Green drives are meant to be used in systems that spend most of their time idle. Trying to use them in an always-on RAID array is just asking for trouble. They are only warrantied for a couple hundred thousand head parkings or something ridiculous like that. 2 million puts it way out of the warranty coverage. :( We had 24 of them in a ZFS pool back when they were first released as they were very inexpensive. They lead to more downtime and replacement costs than any other drive we've used since (or even before). Just don't use them in any kind of RAID array or always-on system. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-current@freebsd.org Tue Dec 12 23:46:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31E04E89726 for ; Tue, 12 Dec 2017 23:46:35 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D38AE793F3; Tue, 12 Dec 2017 23:46:34 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x22e.google.com with SMTP id i92so413442uad.7; Tue, 12 Dec 2017 15:46:34 -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=jgCWTvqJSLlLXY4NmCkLYwckqJKH2OgMCeDQvJXFTYU=; b=NXjQvAd6iaAefL9+eHkhpToLxfcQHIqAUl7tkmkcMCvELJgxUdr1MyUS+8Yp/wXYxL DAWpOuHehZun4p3jetM7LTkzvSA+xFDBKEHoHCZvBuquWXOQ12NOKacrSwbgF2Pajjwn 4BvIxeru1vBXMKGVRVAjbVWOyQUsPwn0GhrqbH7Ug9llI1cIbBsBqsjHwcR3KqJjPD5G TzX6DfUCiToNFppG76L4/p5xr0q4FVh3IINy7fqbnf73e6S3+4HNiKKxljcj8hcsZwPX kP4DWYXkDUHMGYpfkMfLkuDaw8yiqlD0G9EcVzTqhSZ84YncuAxvbEGz1hMfPO3FLKyI HXdg== 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=jgCWTvqJSLlLXY4NmCkLYwckqJKH2OgMCeDQvJXFTYU=; b=q08qiKCa/3GOLHAaGt8XhjRuYTQIDzEzkAYwE6Cz/yIF8c4cH4z00VCyd7gOYHYSlJ AeKm4lwmJoS5tcX+kbHPAmLpCOBnBHaFX5o6xYW7yD/McDaesKut7Pgxi/AczW0+0k60 D4d3m61mMiYLVIntoqKb0H71bmRKewpgROvWupHzRy9DQkeBCa3fGWwDwhBNMey7EM34 X6NPllQcQsxu3yxzL0dg4UrdGTiUkWXYuOoTTEJbdwKt3hAertMM613DxgTcoX+/hva5 K6GXWzR1HWJz8CfnOFzsC/xWyo+so0jCBSfVGCfRZiBWt8pcG5yyz130GvdQptrccWMF QqLQ== X-Gm-Message-State: AKGB3mK8PoK4QmWYHKE3cGNmvm5gGBLJ5tXx39YKut81tC0I9NicXK4b /zzI/Q9bCahvX8ANs5u6+G9mzbqkCgNFP7vhNx7U0dO4 X-Google-Smtp-Source: ACJfBotYNcfmBY0VRYpoXsOv5CJTUunQ1jn9fqj1DBsdYkhVEnHeulyLyp8ryUYwhnVa83TBt599nUGM/e2vDbdN7bk= X-Received: by 10.176.8.71 with SMTP id b7mr5872920uaf.168.1513122393538; Tue, 12 Dec 2017 15:46:33 -0800 (PST) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.147.156 with HTTP; Tue, 12 Dec 2017 15:46:33 -0800 (PST) In-Reply-To: References: From: Kevin Oberman Date: Tue, 12 Dec 2017 15:46:33 -0800 X-Google-Sender-Auth: yVVHygwiF5J3XyWg7RV-H6xOZYg Message-ID: Subject: Re: Poll: should man(1)'s default pager change to "less -s"? To: Alan Somers Cc: Chris H , Steve Kargl , FreeBSD CURRENT , Jamie Landeg-Jones , by@meetlost.com 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, 12 Dec 2017 23:46:35 -0000 On Tue, Dec 12, 2017 at 12:40 PM, Alan Somers wrote: > On Tue, Dec 12, 2017 at 1:39 PM, Chris H wrote: > >> On Tue, 12 Dec 2017 12:27:37 -0800 "Kevin Oberman" >> said >> >> On Tue, Dec 12, 2017 at 12:02 PM, Chris H wrote: >>> >>> > On Tue, 12 Dec 2017 10:15:10 -0800 >>> said >>> > >>> > On Tue, Dec 12, 2017 at 11:03:54AM -0700, Alan Somers wrote: >>> >> > Should man(1)'s default pager change to "less -s"? Vote and flame >>> at >>> >> the >>> >> > Phabricator link below. >>> >> > > https://reviews.freebsd.org/V7 >>> >> > >>> >> Does not work. >>> >> >>> >> Unhandled Exception ("AphrontMalformedRequestException") >>> >> Your browser did not submit a "phcid" cookie with client state >>> >> information in the request. Check that cookies are enabled. >>> >> If this problem persists, you may need to clear your cookies. >>> >> >>> >> Of course, I don't have an account on https://reviews.freebsd.org/ >>> >> >>> > Hah! I got the same (alarming) feedback too. I then tried to just log >>> in, >>> > and it worked. Guess you'll need, or create an account? :-) >>> > >>> > --Chris >>> > >>> > >>> >> -- >>> >> Steve >>> >> >>> > >>> I have not used those ancient, very limited pagers for years, but I am >>> sure >>> that almost nobody has even heard of the much more powerful >>> sysutils/most. >>> >> Ooo... I may have voted too soon. :-O >> Thanks for the pointer, Kevin! >> >> --Chris >> > > most looks pretty cool. The only probably I noticed in my brief > inspection was that it doesn't support the Home and End keys. > Having started with most(1) in days before we had and (VT220s), my fingers are trained for t (top) and b (bottom). Adding support for those keys should be pretty trivial. I'll drop the author a note asking if they might be added for 5.1. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Wed Dec 13 00:20:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71767E8A9AF; Wed, 13 Dec 2017 00:20:08 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 B00867A1EB; Wed, 13 Dec 2017 00:20:07 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dba65d2.dyn.telefonica.de [77.186.101.210]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vBD0K2mT063453; Wed, 13 Dec 2017 01:20:02 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Mark Millard CC: jeff@FreeBSD.org, Freebsd-arm , FreeBSD Hackers , FreeBSD Current Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Wed, 13 Dec 2017 01:20:01 +0100 (CET) Message-ID: <4b24414033.695511f0@mail.schwarzes.net> In-Reply-To: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Wed, 13 Dec 2017 01:20:02 +0100 (CET) X-Mailman-Approved-At: Wed, 13 Dec 2017 01:38:57 +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: Wed, 13 Dec 2017 00:20:08 -0000 On 12.12.17, Mark Millard wrote: > On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >> JFYI, the latest kernel (and world) running at one of my >> RPI2-B is r326631, without any issues. > > Interesting. (By the way: My context > is with a V1.1 Cortex-A7 based rpi2, > not V1.2 and Cortex-A53.) Same here. The RPI2-B (not V1.2) is the most stable system of all my SBCs running FreeBSD. > I've almost always run the root file > system being on a USB SSD instead of > on mmcsd0 . I wonder if that is > somehow involved since it may be > unusual. UFS file system. > > The USB SSD is on a powered hub that > is in turn plugged into the rpi2. Ok, I don't use an USB HDD, the limited USB bridge is the weakest point at the whole rpi, so there are probably not much users with this setup. I understand that you are forced to use ist -asc From owner-freebsd-current@freebsd.org Wed Dec 13 01:46: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 4D074E8CBEA for ; Wed, 13 Dec 2017 01:46:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-128.reflexion.net [208.70.210.128]) (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 0BFB37CAAA for ; Wed, 13 Dec 2017 01:46:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32280 invoked from network); 13 Dec 2017 01:46:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Dec 2017 01:46:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 20:46:00 -0500 (EST) Received: (qmail 1238 invoked from network); 13 Dec 2017 01:46:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Dec 2017 01:46:00 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD280EC86EF; Tue, 12 Dec 2017 17:45:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot [backtraces added] From: Mark Millard In-Reply-To: Date: Tue, 12 Dec 2017 17:45:59 -0800 Cc: FreeBSD Hackers , Freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <21626363-B6F9-44CE-82C2-91BF0A9F5E4F@dsl-only.net> References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> To: jeff@FreeBSD.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: Wed, 13 Dec 2017 01:46:07 -0000 [Just adding back traces. ffs_mount use of uma_zcreate is involved in the kernel thread, as is uma_reclaim_worker's use of uma_reclaim_locked in the uma thread.] On 2017-Dec-12, at 4:20 PM, Mark Millard wrote: > On 2017-Dec-12, at 3:19 PM, Mark Millard = wrote: >=20 >> On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >>=20 >>> On 12.12.17, Mark Millard wrote: >>>=20 >>>> I initially jumped from -r326192 to -r326726 and >>>> ended up with a rpi2 that would normally hang >>>> somewhere around release APs being displayed. >>>> (I have had a couple of completed boots but many >>>> dozens of hung-up attempts.) Both a debug kernel >>>> and a non-debug kernel hang the same way. >>>>=20 >>>> Bisecting the kernel (holding world -r326726 >>>> constant) showed: >>>>=20 >>>> -r326346 did not hang (nor did before) >>>> -r326347 and later hung. >>>=20 >>> JFYI, the latest kernel (and world) running at one of my=20 >>> RPI2-B is r326631, without any issues. >>=20 >> Interesting. (By the way: My context >> is with a V1.1 Cortex-A7 based rpi2, >> not V1.2 and Cortex-A53.) >>=20 >> I've almost always run the root file >> system being on a USB SSD instead of >> on mmcsd0 . I wonder if that is >> somehow involved since it may be >> unusual. UFS file system. >>=20 >> The USB SSD is on a powered hub that >> is in turn plugged into the rpi2. >>=20 >> [I had the hang problem before the >> following and after.] >>=20 >> The mechanism for holding mmcsd0 in >> failed recently but the ejection >> mechanism still works. So I hold >> in mmcsd0 until after I get a USB >> SSD boot now. (Interrupt boot, unload, >> boot/autoboot, picks up the kernel >> from the USB SSD.) >>=20 >> This means that I effectively can >> not avoid the USB SSD any more >> unless I get my hands on a different >> V1.1 rpi2. >=20 > Looks like I'll get my hands on a different > rpi2 V1.1 in a few days. So I should then > be able to do reasonable mmcsd0-only > experiments. At least once I find the time. >=20 > FYI, in case boot details are involved > in reproducing the problem. . . >=20 > On the mmcsd0 I have /boot/loader.conf with: >=20 > kern.cam.boot_delay=3D"10000" > vfs.mountroot.timeout=3D"10" >=20 > and /etc/fstab with: >=20 > /dev/ufs/RPI2rootfs / ufs rw,noatime 1 1 > /dev/label/RPI2Aswap none swap sw 0 0 > /dev/label/RPI2Aboot /boot/msdos msdosfs rw,noatime 0 0 >=20 > where the /dev/ufs/RPI2rootfs was the USB SSD. >=20 > However, I interrupt the loader and unload and > then boot or autoboot. (But the hangs started > before this extra sequence was involved.) >=20 > On the USB SSD I have /boot/loader.conf with: >=20 > kern.cam.boot_delay=3D"10000" > vfs.mountroot.timeout=3D"10" >=20 > and /etc/fstab with: >=20 > /dev/da0p1 / ufs rw,noatime 1 1 > /dev/da0p2 none swap sw 0 0 >=20 >=20 > What db> showed does point to things that > -r326347 involve: >=20 > chain 32: > thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK > thread 100077 (pid 23, uma) is on a run queue >=20 > But for all I know -r326347 could be depending > on something required to be true but not correct > elsewhere in the rpi2 support. I'm not claiming > that -r326347 is wrong, just that it is involved. > I've way to little knowledge to claim to know > what is wrong on the evidence that I have. >=20 > I've not yet tried a bpi-m3 Cortex-A7 context or > a pine64+ 2GB or rpi3 Cortex-A53 context. Nor > powerpc64 nor powerpc. At some point I'll get the > time for one or more of these. I've not had amd64 > problems in this area. >=20 > I may not be able to test the bpi-m3: its barrel > connector for power seems flaky and it is > difficult to keep the board powered for long > periods in recent times. For this new example -r326347 kernel based boot-hang: chain 35: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100073 (pid 23, uma) is on a run queue db> bt Tracing pid 1 tid 100001 td 0xd429f000 cpu_switch() at cpu_switch+0x18 pc =3D 0xc0584f80 lr =3D 0xc0299ad8 (sched_switch+0x5c0) sp =3D 0xd42a56b8 fp =3D 0xd42a56e8 sched_switch() at sched_switch+0x5c0 pc =3D 0xc0299ad8 lr =3D 0xc0275f28 (mi_switch+0x258) sp =3D 0xd42a56f0 fp =3D 0xd42a5718 r4 =3D 0x0001f0f5 r5 =3D 0x00000000 r6 =3D 0xd429f000 r7 =3D 0x0006612d r8 =3D 0x00000000 r9 =3D 0x00000104 r10 =3D 0xc08073f0 mi_switch() at mi_switch+0x258 pc =3D 0xc0275f28 lr =3D 0xc02c1508 (sleepq_switch+0x1c0) sp =3D 0xd42a5720 fp =3D 0xd42a5748 r4 =3D 0xd429f000 r5 =3D 0xc0947dc4 r6 =3D 0xc09a9c68 r7 =3D 0xc0947dc0 r8 =3D 0x00000000 r9 =3D 0xc09440c0 r10 =3D 0x000000f4 sleepq_switch() at sleepq_switch+0x1c0 pc =3D 0xc02c1508 lr =3D 0xc02c1308 (sleepq_wait+0x48) sp =3D 0xd42a5750 fp =3D 0xd42a5760 r4 =3D 0xd429f000 r5 =3D 0x00000000 r6 =3D 0xc09a9c68 r7 =3D 0xc06b415c r8 =3D 0x00000001 r9 =3D 0xc09a9c78 r10 =3D 0x00000000 sleepq_wait() at sleepq_wait+0x48 pc =3D 0xc02c1308 lr =3D 0xc02748b0 (_sx_slock_hard+0x298) sp =3D 0xd42a5768 fp =3D 0xd42a57c8 r4 =3D 0xc09a9c68 r5 =3D 0xc0823ac0 r6 =3D 0xc06ae146 r7 =3D 0x00000000 _sx_slock_hard() at _sx_slock_hard+0x298 pc =3D 0xc02748b0 lr =3D 0xc027457c (_sx_slock_int+0x140) sp =3D 0xd42a57d0 fp =3D 0xd42a57f8 r4 =3D 0x00000078 r5 =3D 0x00000765 r6 =3D 0xc09a9c68 r7 =3D 0x00000765 r8 =3D 0xc09a9c78 r9 =3D 0xd7ad8740 r10 =3D 0x00000000 _sx_slock_int() at _sx_slock_int+0x140 pc =3D 0xc027457c lr =3D 0xc052b024 (uma_zcreate+0x10c) sp =3D 0xd42a5800 fp =3D 0xd42a5850 r4 =3D 0x00000078 r5 =3D 0xc09a9c68 r6 =3D 0xc06df86e r7 =3D 0xc06dd153 r8 =3D 0x00000000 r9 =3D 0x00000000 r10 =3D 0x00000000 uma_zcreate() at uma_zcreate+0x10c pc =3D 0xc052b024 lr =3D 0xc050cc90 (ffs_mount+0x80) sp =3D 0xd42a5858 fp =3D 0xd42a5980 r4 =3D 0xd7844000 r5 =3D 0x00000000 r6 =3D 0x00000003 r7 =3D 0xc09a99c0 r8 =3D 0x00000000 r9 =3D 0xd429f000 r10 =3D 0xd828c400 ffs_mount() at ffs_mount+0x80 pc =3D 0xc050cc90 lr =3D 0xc032e1d4 (vfs_donmount+0xeec) sp =3D 0xd42a5988 fp =3D 0xd42a5b38 r4 =3D 0xffffffff r5 =3D 0xd74ec120 r6 =3D 0xd429f000 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc425acd0 r10 =3D 0xd828c400 vfs_donmount() at vfs_donmount+0xeec pc =3D 0xc032e1d4 lr =3D 0xc0330ea8 (kernel_mount+0x70) sp =3D 0xd42a5b40 fp =3D 0xd42a5b78 r4 =3D 0xd82a9000 r5 =3D 0x00000000 r6 =3D 0x00004000 r7 =3D 0x00000000 r8 =3D 0xd87e2050 r9 =3D 0xd87e2040 r10 =3D 0x00000000 kernel_mount() at kernel_mount+0x70 pc =3D 0xc0330ea8 lr =3D 0xc03335dc (parse_mount+0x458) sp =3D 0xd42a5b80 fp =3D 0xd42a5c60 r4 =3D 0xd4263500 r5 =3D 0xd87e2054 r6 =3D 0xd82a9000 r7 =3D 0x00000000 parse_mount() at parse_mount+0x458 pc =3D 0xc03335dc lr =3D 0xc0331a44 ($a.2+0x28) sp =3D 0xd42a5c68 fp =3D 0xd42a5dc8 r4 =3D 0xd7845018 r5 =3D 0x00000000 r6 =3D 0xd7845018 r7 =3D 0xd78404da r8 =3D 0xc06bfbd4 r9 =3D 0xfffffff7 r10 =3D 0xd7836380 $a.2() at $a.2+0x28 pc =3D 0xc0331a44 lr =3D 0xc020a82c (start_init+0x5c) sp =3D 0xd42a5dd0 fp =3D 0xd42a5e20 r4 =3D 0xc06a370c r5 =3D 0xc0823ad0 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0xd42a5e48 r9 =3D 0x00000000 r10 =3D 0xd429b000 start_init() at start_init+0x5c pc =3D 0xc020a82c lr =3D 0xc0230f10 (fork_exit+0xa0) sp =3D 0xd42a5e28 fp =3D 0xd42a5e40 r4 =3D 0xd429f000 r5 =3D 0xd429b000 r6 =3D 0xc020a7d0 r7 =3D 0x00000000 r8 =3D 0xd42a5e48 r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0xa0 pc =3D 0xc0230f10 lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd42a5e48 fp =3D 0x00000000 r4 =3D 0xc020a7d0 r5 =3D 0x00000000 r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r10 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc0564c8c lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd42a5e48 fp =3D 0x00000000 db> bt Tracing pid 23 tid 100073 td 0xd7ad8740 cpu_switch() at cpu_switch+0x18 pc =3D 0xc0584f80 lr =3D 0xc0299ad8 (sched_switch+0x5c0) sp =3D 0xd87dad58 fp =3D 0xd87dad88 sched_switch() at sched_switch+0x5c0 pc =3D 0xc0299ad8 lr =3D 0xc0275f28 (mi_switch+0x258) sp =3D 0xd87dad90 fp =3D 0xd87dadb8 r4 =3D 0x00000025 r5 =3D 0x00000000 r6 =3D 0xd7ad8740 r7 =3D 0x000240ea r8 =3D 0x00000000 r9 =3D 0x00000100 r10 =3D 0xc08073f0 mi_switch() at mi_switch+0x258 pc =3D 0xc0275f28 lr =3D 0xc052d9f8 (uma_reclaim_locked+0x200) sp =3D 0xd87dadc0 fp =3D 0xd87dade8 r4 =3D 0x00000003 r5 =3D 0xc08073f0 r6 =3D 0xc08073f0 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc0824310 r10 =3D 0xc06df86e uma_reclaim_locked() at uma_reclaim_locked+0x200 pc =3D 0xc052d9f8 lr =3D 0xc052de70 (uma_reclaim_worker+0x4c) sp =3D 0xd87dadf0 fp =3D 0xd87dae20 r4 =3D 0xc09a9c68 r5 =3D 0xc4242d80 r6 =3D 0xc06df86e r7 =3D 0x00000000 r8 =3D 0x00000100 r9 =3D 0xc09b3d08 r10 =3D 0xc09a9c7c uma_reclaim_worker() at uma_reclaim_worker+0x4c pc =3D 0xc052de70 lr =3D 0xc0230f10 (fork_exit+0xa0) sp =3D 0xd87dae28 fp =3D 0xd87dae40 r4 =3D 0xd7ad8740 r5 =3D 0xd70ce000 r6 =3D 0xc052de24 r7 =3D 0x00000000 r8 =3D 0xd87dae48 r9 =3D 0xd7ada3a0 r10 =3D 0xc0824e8c fork_exit() at fork_exit+0xa0 pc =3D 0xc0230f10 lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd87dae48 fp =3D 0x00000000 r4 =3D 0xc052de24 r5 =3D 0x00000000 r6 =3D 0x7ff6d83f r7 =3D 0xd6f583a0 r8 =3D 0xc0824dcc r10 =3D 0xc0824e8c swi_exit() at swi_exit pc =3D 0xc0564c8c lr =3D 0xc0564c8c (swi_exit) sp =3D 0xd87dae48 fp =3D 0x00000000 db> show thread 100001 Thread 100001 at 0xd429f000: proc (pid 1): 0xd429b000 name: kernel stack: 0xd42a4000-0xd42a5fff flags: 0x4 pflags: 0x20000000 state: INHIBITED: {SLEEPING} wmesg: umadrain wchan: 0xc09a9c68 sleeptimo 0. 0 (curr 26. = e3fd787f00000000) priority: 84 container lock: sleepq chain (0xc0947dc4) last voluntary switch: 26523 ms ago last involuntary switch: 26695 ms ago db> show thread 100073 Thread 100073 at 0xd7ad8740: proc (pid 23): 0xd70ce000 name: uma stack: 0xd87d9000-0xd87dafff flags: 0x4 pflags: 0x200000 state: RUNQ priority: 84 container lock: sched lock 3 (0xc0942ec0) last voluntary switch: 26694 ms ago db> show lock 0xc0942ec0 class: spin mutex name: sched lock 3 flags: {SPIN, RECURSE} state: {UNOWNED} =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Dec 13 01:56:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75CD0E8D0A2 for ; Wed, 13 Dec 2017 01:56:01 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 2DD6D7D2CA for ; Wed, 13 Dec 2017 01:56:00 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBD1vNIp009170 for ; Tue, 12 Dec 2017 17:57:29 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "FreeBSD Current" Subject: Replacing OpenSSL in base -- does it work? Date: Tue, 12 Dec 2017 17:57:29 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Wed, 13 Dec 2017 01:56:01 -0000 Hi all, I just fired off a fresh build on a new 12-CURRENT install=2E But forgot to add WITHOUT_OPENSSL to src=2Econf(5), as I had intended to=2E :-( Anyway, I'd like to remove OpenSSL from base=2E Any recommendations on the best approach, and best alternatives? Thanks! --Chris From owner-freebsd-current@freebsd.org Wed Dec 13 01:58: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 32C4DE8D245 for ; Wed, 13 Dec 2017 01:58:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 F0C307D491 for ; Wed, 13 Dec 2017 01:58:48 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-pf0-x235.google.com with SMTP id l24so653085pfj.6 for ; Tue, 12 Dec 2017 17:58: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=wQV8DxuYiBN+jZL5BuW367i2y2JMEHde1Qbh7iRhreM=; b=tvINqpMcCzGxca/gFGvD5t/Eki93QmAZ4lLLajWMiPtuj/axYgt6GN/EQKMAzdmJz0 8LMvVFQsO3gRvO+/gzNgWGwZR3wsusFyEo/Ks9fjXmR1GN79P7f8cV8Dc4t0lQU+uedw 1/5r2rm2A6ZzyKtP8qY6Lask4qE720bD0xPwd2HxEqyc7T+bKcsjkJsF5s4ulDR1vZRd Hqs4Z4HmmFMUgOJZMND2iqal4wYm6BXT6RtPM9Z7E/Aln1qv8MIF4kq0lQ46j3IJvR77 27Z8HLTG2IOMvA1knN6OkoW7Cv81rikKo28O7MFzIg2shx4mXvgNcjz0vkgVWOwQ4B/M 96Og== 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=wQV8DxuYiBN+jZL5BuW367i2y2JMEHde1Qbh7iRhreM=; b=C8Uvwfv6EHtIsI+WsSof0DIXp45+cupMWHMLvbTnxSvHaVMhoIZZ+sPswtR6/M8CMZ OiJHKnpRbS4VIqVQlrGImseJIeJF1Gm0j14xZ3bdk87Za4cgYJNkSOnBMAQFRRocjDal YOO+H7J1uiKc0mv91mmirS1DlhsdpKgi1bWe9EgZ+/CTs0MdznDkR3icH9UaV6qlya/R IQtF+xuLg+lIcafRBFoSK5IAlI+lwE/CDKWK4yl4VQKFoskxcXB3MU4buTiHgBzwLlkD rNrKkr9JJw2oeueb51iOBb6OOVnxC1eXOqx0rrPJFE7bUmvwRLN3wdV7equRBw50SW6Y rPpw== X-Gm-Message-State: AKGB3mLUrSi8QceU1/+WEQCXHc+qR35IEEaDo35ME8QCQ+zjK5nDufeE ItWRNay9eCG/pl/JBTbFaDdPAw77LPE= X-Google-Smtp-Source: ACJfBosJLDBxBk2Rboc4B94HDb0G6Dv9oTmPOEACqy7HQhJmyjESvFjfAHe1mvPbKznN0Yq71Z/mLw== X-Received: by 10.98.20.74 with SMTP id 71mr4322479pfu.77.1513130328338; Tue, 12 Dec 2017 17:58:48 -0800 (PST) Received: from mutt-hbsd (tor01.telenet.unc.edu. [204.85.191.31]) by smtp.gmail.com with ESMTPSA id q74sm551373pfd.134.2017.12.12.17.58.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Dec 2017 17:58:47 -0800 (PST) Date: Tue, 12 Dec 2017 20:58:26 -0500 From: Shawn Webb To: Chris H Cc: FreeBSD Current Subject: Re: Replacing OpenSSL in base -- does it work? Message-ID: <20171213015826.36qor4ecm3kprnu4@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t6z4k7d7gqcgnkkx" Content-Disposition: inline In-Reply-To: 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/20171027 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, 13 Dec 2017 01:58:49 -0000 --t6z4k7d7gqcgnkkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 12, 2017 at 05:57:29PM -0800, Chris H wrote: > Hi all, > I just fired off a fresh build on a new 12-CURRENT install. But forgot > to add WITHOUT_OPENSSL to src.conf(5), as I had intended to. :-( > Anyway, I'd like to remove OpenSSL from base. Any recommendations on the > best approach, and best alternatives? Both HardenedBSD and TrueOS use LibreSSL in base. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --t6z4k7d7gqcgnkkx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlowiT8ACgkQaoRlj1JF bu4kxxAAlmOZRO6zI13vMA9cqnnX/NIImCT60SiZ7ZFB3KqDUa3bIwP23xbIwlwO J8FYD4vMIvT1ex9TYrgi1rgjjKTEXPcefkcqAOsLGf/CRLdfMB93200rOYwfPAbI dptyuZ9s0WLPNaYiQcu07dH28WTHiiUKkmvkUeKoQh6f+wquwz04B36PP6/huPW1 F3/JMXuH5zRI2a4nxz/bCbqv1f2B0/XYFlv/PszgmABQJYLL/dSl32UcPu7Jd8Yn VTSpayeCkssiu+XQ3U35EaNFkc4DlL54Aze/cQmtVldWZVf9HkjSr4eR129T5fEB 32G/Sm7MoX1EsGG+SJOgviX9G7x6jlMIS/9T8b3VVuGQkUxstMT0eDC04jboYWSj X3CNkQ2biyuVCSDhfDzsCv6YXQ78tRIahByTqXQq9OAvEV7iHSdrRWpIUOtz7Tdz nxxB0gTNrN2u914If6h0WkG/zm6xPYOtSyhGtWAyhnCAkSha1JikICSK+JIwtG+o 2uliZCZIT0y544sSqRodzvvYCBwOIB+iEYdbTTQWbv8CmRLdV4+tsrspmDWsdkRd u/81+vY631cysAUualYRMJTH+4+Z/pU0To/iC4iHLahVbHhjVhIb2ZcbXx4MtNMO g37k+50AYKiMipSN297/ygv2Yb6KerMLzQl42xQ3Koc/HDV+zds= =93wt -----END PGP SIGNATURE----- --t6z4k7d7gqcgnkkx-- From owner-freebsd-current@freebsd.org Wed Dec 13 02:05: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 05F5BE8D558 for ; Wed, 13 Dec 2017 02:05:11 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 970A47D90A for ; Wed, 13 Dec 2017 02:05:10 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBD26WY3009452; Tue, 12 Dec 2017 18:06:38 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD Current" In-Reply-To: <20171213015826.36qor4ecm3kprnu4@mutt-hbsd> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Shawn Webb" Subject: Re: Replacing OpenSSL in base -- does it work? Date: Tue, 12 Dec 2017 18:06:38 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Wed, 13 Dec 2017 02:05:11 -0000 On Tue, 12 Dec 2017 20:58:26 -0500 "Shawn Webb" said > On Tue, Dec 12, 2017 at 05:57:29PM -0800, Chris H wrote: > > Hi all, > > I just fired off a fresh build on a new 12-CURRENT install=2E But forgot > > to add WITHOUT_OPENSSL to src=2Econf(5), as I had intended to=2E :-( > > Anyway, I'd like to remove OpenSSL from base=2E Any recommendations on th= e > > best approach, and best alternatives? >=20 > Both HardenedBSD and TrueOS use LibreSSL in base=2E WOW=2E Thanks for the fast reply, Shawn! I had already considered that might be a good direction=2E Nice to hear it works! Thanks again, Shawn! --Chris >=20 > Thanks, >=20 > --=20 > Shawn Webb > Cofounder and Security Engineer > HardenedBSD >=20 > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE From owner-freebsd-current@freebsd.org Wed Dec 13 02:07: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 602A0E8D6C1 for ; Wed, 13 Dec 2017 02:07:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-134.reflexion.net [208.70.210.134]) (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 0FE717DA9C for ; Wed, 13 Dec 2017 02:07:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7106 invoked from network); 13 Dec 2017 00:20:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Dec 2017 00:20:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 19:20:31 -0500 (EST) Received: (qmail 13273 invoked from network); 13 Dec 2017 00:20:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Dec 2017 00:20:31 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 30083EC814E; Tue, 12 Dec 2017 16:20:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot From: Mark Millard In-Reply-To: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> Date: Tue, 12 Dec 2017 16:20:29 -0800 Cc: FreeBSD Hackers , FreeBSD Current , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> To: Andreas Schwarz , jeff@FreeBSD.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: Wed, 13 Dec 2017 02:07:18 -0000 On 2017-Dec-12, at 3:19 PM, Mark Millard wrote: > On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >=20 >> On 12.12.17, Mark Millard wrote: >>=20 >>> I initially jumped from -r326192 to -r326726 and >>> ended up with a rpi2 that would normally hang >>> somewhere around release APs being displayed. >>> (I have had a couple of completed boots but many >>> dozens of hung-up attempts.) Both a debug kernel >>> and a non-debug kernel hang the same way. >>>=20 >>> Bisecting the kernel (holding world -r326726 >>> constant) showed: >>>=20 >>> -r326346 did not hang (nor did before) >>> -r326347 and later hung. >>=20 >> JFYI, the latest kernel (and world) running at one of my=20 >> RPI2-B is r326631, without any issues. >=20 > Interesting. (By the way: My context > is with a V1.1 Cortex-A7 based rpi2, > not V1.2 and Cortex-A53.) >=20 > I've almost always run the root file > system being on a USB SSD instead of > on mmcsd0 . I wonder if that is > somehow involved since it may be > unusual. UFS file system. >=20 > The USB SSD is on a powered hub that > is in turn plugged into the rpi2. >=20 > [I had the hang problem before the > following and after.] >=20 > The mechanism for holding mmcsd0 in > failed recently but the ejection > mechanism still works. So I hold > in mmcsd0 until after I get a USB > SSD boot now. (Interrupt boot, unload, > boot/autoboot, picks up the kernel > from the USB SSD.) >=20 > This means that I effectively can > not avoid the USB SSD any more > unless I get my hands on a different > V1.1 rpi2. Looks like I'll get my hands on a different rpi2 V1.1 in a few days. So I should then be able to do reasonable mmcsd0-only experiments. At least once I find the time. FYI, in case boot details are involved in reproducing the problem. . . On the mmcsd0 I have /boot/loader.conf with: kern.cam.boot_delay=3D"10000" vfs.mountroot.timeout=3D"10" and /etc/fstab with: /dev/ufs/RPI2rootfs / ufs rw,noatime 1 1 /dev/label/RPI2Aswap none swap sw 0 0 /dev/label/RPI2Aboot /boot/msdos msdosfs rw,noatime 0 0 where the /dev/ufs/RPI2rootfs was the USB SSD. However, I interrupt the loader and unload and then boot or autoboot. (But the hangs started before this extra sequence was involved.) On the USB SSD I have /boot/loader.conf with: kern.cam.boot_delay=3D"10000" vfs.mountroot.timeout=3D"10" and /etc/fstab with: /dev/da0p1 / ufs rw,noatime 1 1 /dev/da0p2 none swap sw 0 0 What db> showed does point to things that -r326347 involve: chain 32: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100077 (pid 23, uma) is on a run queue But for all I know -r326347 could be depending on something required to be true but not correct elsewhere in the rpi2 support. I'm not claiming that -r326347 is wrong, just that it is involved. I've way to little knowledge to claim to know what is wrong on the evidence that I have. I've not yet tried a bpi-m3 Cortex-A7 context or a pine64+ 2GB or rpi3 Cortex-A53 context. Nor powerpc64 nor powerpc. At some point I'll get the time for one or more of these. I've not had amd64 problems in this area. I may not be able to test the bpi-m3: its barrel connector for power seems flaky and it is difficult to keep the board powered for long periods in recent times. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Dec 13 02:34: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 563DFE8E1E7 for ; Wed, 13 Dec 2017 02:34:04 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D16B7E91C for ; Wed, 13 Dec 2017 02:34:04 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x233.google.com with SMTP id r13so1223774iod.2 for ; Tue, 12 Dec 2017 18:34:04 -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=QxU0bPBZnA3Cjms6Nx/fh9jfoOmcmdvzSTuAXYMqMfw=; b=LVIKVRhj5qja39lwpqALOhC8pC+Jgaapx0zjGMi/9BbeugfxiTsL5Lprl0eoWnpVct xsNxNdjjQXAJV8xjC20qlyU1WUqP0uVkNhtrlNhFjx/KgSNtUwZ0szQXHqs12g4W3yQ2 dH13rETtprA/xl5/ivnHG5gPB6EZpvhx+yfReoQCP0M9DqUJj0jNXSvbbViddrWn3rdP w8i+M+8FMc4df4JIfqXy6ynilv9mZhwhezzU17HYIbw+JLdOzbVt6TZJSYvtE5PKE7YA Srh39TxqZYr9nQ3BhuO0Myxl4lju1t8pzkebpYYBCCrrfzNEJ7t6Wn3C+PgbhA/TTqMi gPvQ== 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=QxU0bPBZnA3Cjms6Nx/fh9jfoOmcmdvzSTuAXYMqMfw=; b=U0KpGN+ihJRgo12ypjMt58N3TqmCL5QybP6TLNfzL43LKIwvI3B8Kyttd8zflaKD/j lK62U6LxG9Wbf0GkUvehwPXeNa4c7fu2Oan4VhJe/m/ya2RyeBAsu1/xZIa99ZfJOUHG 60Obhj/VfXVaOCr+hJbAXZ698G2aEPKVWxSdz62UlT2jjyzab3fpoQov1oCvb98zwC7E TYLTRM8Ti/qLADZS4sOQml9jC4vLPGCOmakAb2/aqAY4hg6akV7U4MrCdoAAnDfKUsSU eLvF7gouqf5hiYJkNuJzt5GzkelyBJH6fCp4F4irU/zaai9FMzQwWgMuB+kjL0ohm/cH BMMA== X-Gm-Message-State: AKGB3mILXPdrlWIdL3luLPGnLKXbWC4B6txVUokDhcj0EefakO/2P58q ZmObXEwryE2LxeRbZKdxdKVlym1NofEli32V5wY= X-Google-Smtp-Source: ACJfBos+HxEv8cunsgUc5SV2p/f9E1gMKZOAN5LN+aL4vVZ3wgmgaSPzlHEEcLlQrumZR2KIvGuAwC+AQdADRZWcrEU= X-Received: by 10.107.24.198 with SMTP id 189mr1142208ioy.213.1513132443353; Tue, 12 Dec 2017 18:34:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Tue, 12 Dec 2017 18:34:02 -0800 (PST) In-Reply-To: References: From: blubee blubeeme Date: Wed, 13 Dec 2017 10:34:02 +0800 Message-ID: Subject: Re: get_swap_pager(x) failed To: Mark Millard Cc: 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: Wed, 13 Dec 2017 02:34:04 -0000 On Wed, Dec 13, 2017 at 5:53 AM, Mark Millard wrote: > blubee blubeeme gurenchan at gmail.com wrote on > Tue Dec 12 15:58:19 UTC 2017 : > > > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme > >wrote: > > > I am seeing tons of these messages while running tail -f > /var/log/messages > > > ============ > > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed > > . . . > > > 1159 blubee 5 20 0 149M 56876K select 6 1:05 0.00% > > > ibus-engine-chewing > > > > > > =========== > > > > > > What's with all the swap errors? I am running ZFS and I have 16GB of > ram, > > > how could I be having swap space errors? > > > > > > > Well I added 4GB of extra swap in /var/tmp/swap0 > > then added that to my /etc/fstab: md99 none swap > > sw,file=/var/tmp/swap0,late 0 0 > > > > and those errors went away. > > I recommend reviewing bugzilla 206048 (title in part > "swapfile usage hangs; swap partition works"): > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 > > before using file-system based swap spaces. They have > lots of problems with deadlocks. See especially comments > #7 and #8 quoting Konstantin Belousov. #8 is just a > reference to: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ > kerneldebug-deadlocks.html > > Comment #3 shows a way to test for the problematical > behavior. > > Using swap partitions avoids the issue. > > === > Mark Millard > markmi at dsl-only.net > > Thanks for the info, why would I be getting swap errors like that when I have 32GB of ram? sysctl hw.physmem hw.physmem: 34253692928 That really doesn't make any sense to me... Is it Chromium eating up 32GB+ of ram? From owner-freebsd-current@freebsd.org Wed Dec 13 03:58: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 D84F4E90100 for ; Wed, 13 Dec 2017 03:58:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-109.reflexion.net [208.70.210.109]) (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 9CD9D146B for ; Wed, 13 Dec 2017 03:58:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31957 invoked from network); 13 Dec 2017 03:58:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 13 Dec 2017 03:58:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 22:58:09 -0500 (EST) Received: (qmail 27325 invoked from network); 13 Dec 2017 03:58:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Dec 2017 03:58:08 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5716CEC8F8E; Tue, 12 Dec 2017 19:58:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: get_swap_pager(x) failed From: Mark Millard In-Reply-To: Date: Tue, 12 Dec 2017 19:58:07 -0800 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <50AD451C-ED04-4D04-A777-99579FA5465B@dsl-only.net> References: To: blubee blubeeme 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, 13 Dec 2017 03:58:11 -0000 On 2017-Dec-12, at 6:34 PM, blubee blubeeme = wrote: > On Wed, Dec 13, 2017 at 5:53 AM, Mark Millard = wrote: >> blubee blubeeme gurenchan at gmail.com wrote on >> Tue Dec 12 15:58:19 UTC 2017 : >>=20 >> > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme > > >wrote: >> > > I am seeing tons of these messages while running tail -f = /var/log/messages >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): = failed >> > . . . >> > > 1159 blubee 5 20 0 149M 56876K select 6 1:05 = 0.00% >> > > ibus-engine-chewing >> > > >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > >> > > What's with all the swap errors? I am running ZFS and I have 16GB = of ram, >> > > how could I be having swap space errors? >> > > >> > >> > Well I added 4GB of extra swap in /var/tmp/swap0 >> > then added that to my /etc/fstab: md99 none = swap >> > sw,file=3D/var/tmp/swap0,late 0 0 >> > >> > and those errors went away. >>=20 >> I recommend reviewing bugzilla 206048 (title in part >> "swapfile usage hangs; swap partition works"): >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 >>=20 >> before using file-system based swap spaces. They have >> lots of problems with deadlocks. See especially comments >> #7 and #8 quoting Konstantin Belousov. #8 is just a >> reference to: >>=20 >> = https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern= eldebug-deadlocks.html >>=20 >> Comment #3 shows a way to test for the problematical >> behavior. >>=20 >> Using swap partitions avoids the issue. >=20 >=20 > Thanks for the info, why would I be getting swap errors like that when = I have 32GB of ram? > sysctl hw.physmem > hw.physmem: 34253692928 >=20 > That really doesn't make any sense to me... Is it Chromium eating up = 32GB+ of ram? I'm not familiar with the memory use of the software that you use. But if swap space is put to use then file-based swap space is a bad idea from what I understand. Having no swap space configured is allowed but may not be sufficient for your context. In a separate shell window you could monitor what is going on with something like: top -Cawores (You may want a large window.) That will show something like following in an updating display: last pid: 49403; load averages: 0.13, 0.03, 0.01 = up 3+19:28:56 19:33:58 43 processes: 1 running, 42 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 1808K Active, 98G Inact, 45M Laundry, 4912M Wired, 1544M Buf, 2462M = Free Swap: 15G Total, 15G Free PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 625 root 1 20 0 55588K 15440K 0K select 15 0:01 = 0.00% /usr/sbin/mountd -r 627 root 1 52 0 54024K 14348K 0K select 27 0:00 = 0.00% nfsd: master (nfsd) . . . (Some of the detail above is tied to it being a UFS context instead of a zfs context. There will be zfs information as well if you are using zfs.) The SIZE, RES, and SWAP for various processes will give a clue. Avoid over interpreting: as I understand, these days swapped-out really means the kernel-stacks for the process are not resident. The activity is mostly paging activity otherwise. Top does not track such detailed changes in how it presents information. RES being zero might not mean what one might expect. Still, the figures are useful for seeing what is using RAM and the swapspace. I'm not aware of a way to find the maximum swapspace in-use-so-far figure or any estimate of it. Top will display an active in-use figure if it is in use (not just Total and Free). Of source the figure is based on periodic sampling. Top does not display the maximum-observed-so-far of its periodic sampling. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Wed Dec 13 07:42: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 0B138E94520 for ; Wed, 13 Dec 2017 07:42:47 +0000 (UTC) (envelope-from gljennjohn@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 8ED2E66556 for ; Wed, 13 Dec 2017 07:42:46 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id n138so3046106wmg.2 for ; Tue, 12 Dec 2017 23:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=3pqIMHds08agQO82RkFHkCkRbuOqtDUutkP2UYj/qmg=; b=fBHMo34R/i5BXpaQa/WMWImbejgEoCDtUAv/uKKmCB0PsEM5eejASsry3+pVaan6+5 U7vRQ4PQEACiRbTURr7EBesx/GCCkNcRvGcv8XLwScQACzbikg1RcJcFu8QOa6giqlCv XhFBDrm668iNWEwKuUrbmg5OjBU02c43qUn6z2AqUP5trk/R4V9ef/MXL/GpO83fT4VC 4nz68kVd50QfKe7KC2TF7u9a3PV9YRHA0As9IFHT4TW9jrj6JvaBgpVU/QXWWDkZ6N7J XBJdvMBJxMpY1vP/iOz7qzyMVBbIYd/9grTOaLkL9HErNm7GEkViqckdqN3rt0TcoN0Y zUYQ== 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:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=3pqIMHds08agQO82RkFHkCkRbuOqtDUutkP2UYj/qmg=; b=ax4dXYnqeJ/FAnmuSDOrefN39LNwaT9Dd1D4hMDivlmKQ/rf9VZ2id2ZSdcTLk2PjY JmxaSWFsYy1tQfwreLUISlnk0iBUa28vWuJpna6fSUhX9dtth2OMe6+Hpsq4Rxhtc7qi AeFsbNFicTc/Gbv2GuhVsAJ8tq2uuncxkDtnTCfmdXIOqi8oQepNjjcVoeTd8eyN0EJd 6Qgn+z1UFK89+841mrmy0RSaeGDQggh3b7DAhm/x+4su+iOSkykOzqnULmLr2IwW+sRN jz8q+DidBL42rexgpAE2173+D+fy4y3AzRzo2s0PJVt6kg+Tt9wOurzJKpNf/dDQiDsA WMHw== X-Gm-Message-State: AKGB3mKJX9r1fNuJxmdDQcktLbn9w9u5jYWVnvd9XQWnRVeLY2xb9TOe Dn9kWpAP0KCbZREWBAqcGVE= X-Google-Smtp-Source: ACJfBouDQ9/wtPPEN54iXOznXVO9IKAMysZiYSbde6ZOnTdoMBwuRSKc6GIsdt7h60/VHm48Ww+Rmg== X-Received: by 10.28.213.2 with SMTP id m2mr1007655wmg.141.1513150964349; Tue, 12 Dec 2017 23:42:44 -0800 (PST) Received: from ernst.home (p5B0238CC.dip0.t-ipconnect.de. [91.2.56.204]) by smtp.gmail.com with ESMTPSA id e124sm737682wmg.34.2017.12.12.23.42.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Dec 2017 23:42:43 -0800 (PST) Date: Wed, 13 Dec 2017 08:42:42 +0100 From: Gary Jennejohn To: blubee blubeeme Cc: Mark Millard , FreeBSD Current Subject: Re: get_swap_pager(x) failed Message-ID: <20171213084242.13a64c19@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) 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: Wed, 13 Dec 2017 07:42:47 -0000 On Wed, 13 Dec 2017 10:34:02 +0800 blubee blubeeme wrote: > On Wed, Dec 13, 2017 at 5:53 AM, Mark Millard wrote: > > > blubee blubeeme gurenchan at gmail.com wrote on > > Tue Dec 12 15:58:19 UTC 2017 : > > > > > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme > > >wrote: > > > > I am seeing tons of these messages while running tail -f > > /var/log/messages > > > > ============ > > > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed > > > . . . > > > > 1159 blubee 5 20 0 149M 56876K select 6 1:05 0.00% > > > > ibus-engine-chewing > > > > > > > > =========== > > > > > > > > What's with all the swap errors? I am running ZFS and I have 16GB of > > ram, > > > > how could I be having swap space errors? > > > > > > > > > > Well I added 4GB of extra swap in /var/tmp/swap0 > > > then added that to my /etc/fstab: md99 none swap > > > sw,file=/var/tmp/swap0,late 0 0 > > > > > > and those errors went away. > > > > I recommend reviewing bugzilla 206048 (title in part > > "swapfile usage hangs; swap partition works"): > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 > > > > before using file-system based swap spaces. They have > > lots of problems with deadlocks. See especially comments > > #7 and #8 quoting Konstantin Belousov. #8 is just a > > reference to: > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ > > kerneldebug-deadlocks.html > > > > Comment #3 shows a way to test for the problematical > > behavior. > > > > Using swap partitions avoids the issue. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > > Thanks for the info, why would I be getting swap errors like that when I > have 32GB of ram? > sysctl hw.physmem > hw.physmem: 34253692928 > > That really doesn't make any sense to me... Is it Chromium eating up 32GB+ > of ram? > I've asked myself that question also. alc@ gave me a hint. Try this: sysctl vm.pageout_update_period=0 If it helps, put vm.pageout_update_period=0 into /etc/sysctl.conf. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Wed Dec 13 11:23: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 07843E9A6CA for ; Wed, 13 Dec 2017 11:23:49 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 C6C5A6C798 for ; Wed, 13 Dec 2017 11:23:48 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.89_1 (FreeBSD)) (envelope-from ) id 1eP58c-0000Yp-WA; Wed, 13 Dec 2017 11:23:47 +0000 Date: Wed, 13 Dec 2017 11:23:46 +0000 From: Gary Palmer To: blubee blubeeme Cc: Mark Millard , FreeBSD Current Subject: Re: get_swap_pager(x) failed Message-ID: <20171213112346.GA27816@in-addr.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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, 13 Dec 2017 11:23:49 -0000 On Wed, Dec 13, 2017 at 10:34:02AM +0800, blubee blubeeme wrote: > On Wed, Dec 13, 2017 at 5:53 AM, Mark Millard wrote: > > > blubee blubeeme gurenchan at gmail.com wrote on > > Tue Dec 12 15:58:19 UTC 2017 : > > > > > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme > > >wrote: > > > > I am seeing tons of these messages while running tail -f > > /var/log/messages > > > > ============ > > > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed > > > . . . > > > > 1159 blubee 5 20 0 149M 56876K select 6 1:05 0.00% > > > > ibus-engine-chewing > > > > > > > > =========== > > > > > > > > What's with all the swap errors? I am running ZFS and I have 16GB of > > ram, > > > > how could I be having swap space errors? > > > > > > > > > > Well I added 4GB of extra swap in /var/tmp/swap0 > > > then added that to my /etc/fstab: md99 none swap > > > sw,file=/var/tmp/swap0,late 0 0 > > > > > > and those errors went away. > > > > I recommend reviewing bugzilla 206048 (title in part > > "swapfile usage hangs; swap partition works"): > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 > > > > before using file-system based swap spaces. They have > > lots of problems with deadlocks. See especially comments > > #7 and #8 quoting Konstantin Belousov. #8 is just a > > reference to: > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ > > kerneldebug-deadlocks.html > > > > Comment #3 shows a way to test for the problematical > > behavior. > > > > Using swap partitions avoids the issue. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > > Thanks for the info, why would I be getting swap errors like that when I > have 32GB of ram? > sysctl hw.physmem > hw.physmem: 34253692928 > > That really doesn't make any sense to me... Is it Chromium eating up 32GB+ > of ram? Your top output from the first message in the thread gives a hint: Mem: 3442M Active, 293M Inact, 4901M Laundry, 22G Wired, 1057M Free ARC: 18G Total, 1488M MFU, 15G MRU, 4003K Anon, 178M Header, 1171M Other 16G Compressed, 23G Uncompressed, 1.41:1 Ratio Swap: 2048M Total, 2028M Used, 20M Free, 99% Inuse, 36K In You have 22GB RAM used by the kernel, and 18GB of that is used by ZFS. As you can see from the last line, 99% of your small swap space is used and paging was happening at the time of the snapshot ("36K In"). First I would suggest limiting ARC and seeing if that helps. Unless you are doing a lot of fileserver type work or working with lots of files you want to keep around that ARC size is a bit big. My desktop with 32GB RAM has ARC limited to 4GB. Definitely do NOT swap to a file on a filesystem, especially if the filesystem is ZFS. That will eventually lead to a deadlock. An open question would be why ARC is not reducing if the system is under memory pressure. It's meant to, but there have been various bugs in that implementation. Regards, Gary From owner-freebsd-current@freebsd.org Wed Dec 13 11:42: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 D8149E9B05D for ; Wed, 13 Dec 2017 11:42:24 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 76CE16D5F4; Wed, 13 Dec 2017 11:42:24 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.15.2/8.15.2) with ESMTPSA id vBDBPK4U015922 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Dec 2017 13:25:20 +0200 (EET) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error From: Daniel Kalchev In-Reply-To: Date: Wed, 13 Dec 2017 13:25:20 +0200 Cc: "Rodney W. Grimes" , "O. Hartmann" , FreeBSD CURRENT , Alan Somers Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171212231858.294a2cb5@thor.intern.walstatt.dynvpn.de> <201712122255.vBCMtnfZ088889@pdx.rh.CN85.dnsmgr.net> To: Freddie Cash X-Mailer: Apple Mail (2.3445.5.20) 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, 13 Dec 2017 11:42:24 -0000 > On 13 Dec 2017, at 1:26, Freddie Cash wrote: >=20 > On Tue, Dec 12, 2017 at 2:55 PM, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: >=20 >> Hum, just noticed this. 25k hours power on, 2M load cycles, this is >> very hard on a hard drive. Your drive is going into power save mode >> and unloading the heads. Infact at a rate of 81 times per hour? >> Oh, I can not believe that. Either way we need to get this stopped, >> it shall wear your drives out. >>=20 >=20 > =E2=80=8BBelieve it. :) The WD Green drives have a head parking = timeout of 15 > seconds, and no way to disable that anymore. You used to be able to = boot > into DOS and run the tler.exe program from WD to disable the = auto-parking > feature, but they removed that ability fairly quickly. >=20 > The Green drives are meant to be used in systems that spend most of = their > time idle. Trying to use them in an always-on RAID array is just = asking > for trouble. They are only warrantied for a couple hundred thousand = head > parkings or something ridiculous like that. 2 million puts it way out = of > the warranty coverage. :( >=20 > We had 24 of them in a ZFS pool back when they were first released as = they > were very inexpensive. They lead to more downtime and replacement = costs > than any other drive we've used since (or even before). Just don't = use > them in any kind of RAID array or always-on system. >=20 In order to handle drives like this and in general to get rid of load = cycles, I use smartd on all my ZFS pools with this piece of config: DEVICESCAN -a -o off -e apm,off=20 Might not be the best solution, but as it is activated during boot, = S.M.A.R.T. attribute 193 Load_Cycle_Count does not increase anymore. Not = fan of WD drives, but have few tens of them=E2=80=A6 all of them = =E2=80=9Cbehave=E2=80=9D in some way or another. For the original question, if I do not have spare disk to replace, on a = raidz1/raidz2 pool I would typically do: zpool offline poolname disk dd if=3D/dev/zero of=3D/dev/disk bs=3D1m zpool replace poolname disk This effectively fills the disk with zeros, forcing any suspected = unreadable blocks to be replaced. After this operation, no more pending = blocks etc. But, on large drives/pools requires few days to complete = (the last part). Over the years, I have used this procedure on many = drives, sometimes more than once on the same drive and that posponed = having to replace the drive and the annoying S.M.A.R.T. message: which = by itself might not be major problem, but better not have the logs = filled with warnings all the time. I feel more confident doing this on raidz2 vdevs anyway.. If I had spare disk and spare port, just zpool replace poolname disk Daniel= From owner-freebsd-current@freebsd.org Wed Dec 13 08:55:28 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 2FD1DE9680D for ; Wed, 13 Dec 2017 08:55:28 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7A34468644; Wed, 13 Dec 2017 08:55:26 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.182.112.82]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MAyVY-1eHJZr2PO0-00A0Wz; Wed, 13 Dec 2017 09:55:19 +0100 Date: Wed, 13 Dec 2017 09:54:43 +0100 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error Message-ID: <20171213095510.4f025922@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201712122255.vBCMtnfZ088889@pdx.rh.CN85.dnsmgr.net> References: <20171212231858.294a2cb5@thor.intern.walstatt.dynvpn.de> <201712122255.vBCMtnfZ088889@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_/mvP06IJ4=8CV0Ve8YnW_1hQ"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Z5wMo1fuH2N4OuGeAxOPYYNtcQoLBIrIBJIBk2iiyd24HjrEUID 1VFBmU4YMcMUO0CjPl8rZQJfiZsztdmi103qI/fjnq5UwbkZqaVgDcGnG5VFiq0yXxua2tj dgR8ttQ+pmnK2uOM33PPCIg18ScRwF9fahA0zS9/PPnq+gz9qnYZBwZ0Z/woqu6P2VUDVB5 hUR48xVOSpci+/JwMLFtQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:HlE2Wt29r9I=:g3FnFL0JD+fe21wBsQG2ox q8uDmvm+nd4fGfNtUbkGzlPygJJKYfJOnyYzRPbTwYASMPGGCfJWC61rm4oWiu9OWAvi3Ez3N R20fHRZy4VcJ1lPN8eDO9QBupsCvfLcYUqAv7gN9F9Kt0+U2RzqUHyn3sTEgeqbX0OE40pWkP iKBL8ijE7cFjh9m3aMxawUSPl9vXwNgQeKJCpAcpvExGoWwyB6CwHutHeZBLeHkEHf2/Rh0lG phttNw4JqmgnngCcZFR2hhrKQTWmayMx8ebcjC4WKRQsTAD2m2+FRzqHJttINg24Vgu58x86N kSUmY7yUY6b3SsaVrNVlP7EIEdVcA+wkVwMfmmh+UiBOu2unaRNyWbBv7BqQqMr2j0oPaYVO3 Ib1jRqAd76tUf9okoISa4eZrLuN+sYIiQk5f9jHh/8RDJbPDEj71g0OK1KgBuoC5ed3HfyCFx hD6yUr9bACoQJFfNbaECZoKMbnH9iU1uZtzuV63Tg6M1/ooPXff8fI3/BruFz9RjJ93dSgqnL BeRkEd9cdhLMs9zytUJNs9TJw6OlcRCSlz6Kw51QRYLVCtafPiNeAjwf5KTPMh2pecfItbqTw 8rnNds9t6VXwwWZZ5L/HBxHl7sKQD516HjuloVyuTrGjXGqoFQe15vn4YUig40vZ2EJAukQP/ ZunjIvohFlvRnosShtsaZVEnjbda5Hf970AVgZTxd40H69O97CykLuEyslkHZFUuOPNNhU/Wh qVh+LMzUlWs1Z+RG79BXEyRcMpRwkfJEIYVUHGO1YTyBaSOSzy0bT7U/Zr7adjoHn2eGO7ZgQ yiZrahuz7HQqWSbEjaJTquptDSKcA== X-Mailman-Approved-At: Wed, 13 Dec 2017 15:12:54 +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: Wed, 13 Dec 2017 08:55:28 -0000 --Sig_/mvP06IJ4=8CV0Ve8YnW_1hQ Content-Type: multipart/mixed; boundary="MP_/Dd35P6LvSzBZKm5JLE2mpNQ" --MP_/Dd35P6LvSzBZKm5JLE2mpNQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Tue, 12 Dec 2017 14:55:49 -0800 (PST) "Rodney W. Grimes" schrieb: > > Am Tue, 12 Dec 2017 10:52:27 -0800 (PST) > > "Rodney W. Grimes" schrieb: > >=20 > >=20 > > Thank you for answering that fast! > > =20 > > > > Hello, > > > >=20 > > > > running CURRENT (recent r326769), I realised that smartmond sends o= ut some console > > > > messages when booting the box: > > > >=20 > > > > [...] > > > > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Curr= ently > > > > unreadable (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[6842= 6]: > > > > Device: /dev/ada6, 1 Offline uncorrectable sectors > > > > [...] > > > >=20 > > > > Checking the drive's SMART log with smartctl (it is one of four 3TB= disk drives), > > > > I gather these informations: > > > >=20 > > > > [... smartctl -x /dev/ada6 ...] > > > > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055= days + 15 > > > > hours) When the command that caused the error occurred, the device = was active or > > > > idle. > > > >=20 > > > > After command completion occurred, registers were: > > > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > > > -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- > > > > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc= 27a7298 =3D > > > > 3262804632 > > > >=20 > > > > Commands leading to the command that caused the error were: > > > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/= Feature_Name > > > > -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -----= ---------- -------------------- > > > > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPD= MA QUEUED > > > > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPD= MA QUEUED > > > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG= EXT > > > > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPD= MA QUEUED > > > > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPD= MA QUEUED > > > > [...] > > > >=20 > > > > and > > > >=20 > > > > [...] > > > > SMART Attributes Data Structure revision number: 16 > > > > Vendor Specific SMART Attributes with Thresholds: > > > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VA= LUE > > > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > > > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > > > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > > > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > > > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > > > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > > > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > > > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > > > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > > > ||||||_ K auto-keep > > > > |||||__ C event count > > > > ||||___ R error rate > > > > |||____ S speed/performance > > > > ||_____ O updated online > > > > |______ P prefailure warning > > > >=20 > > > > [...] =20 > > >=20 > > > The data up to this point informs us that you have 1 bad sector > > > on a 3TB drive, that is actually an expected event given the data > > > error rate on this stuff is such that your gona have these now > > > and again. > > >=20 > > > Given you have 1 single event I would not suspect that this drive > > > is dying, but it would be prudent to prepare for that possibility. =20 > >=20 > > Hello. > >=20 > > Well, I copied simply "one single event" that has been logged so far. > >=20 > > As you (and I) can see, it is error #42. After I posted here, a reboot = has taken place > > because the "repair" process on the Pool suddenly increased time and no= w I'm with > > error #47, but interestingly, it is a new block that is damaged, but th= e SMART > > attribute fields show this for now: =20 >=20 > Can you send the complete output of smartctl -a /dev/foo, I somehow missed > that 40+ other errors had occured. Yes, here it is, but please do not beat me due to its size ;-). It is "smar= tctl -x", that shows me the errors. See file attached named "smart_ada.txt". It is everyth= ing of interest about the drive, I guess. >=20 > > [...] > > SMART Attributes Data Structure revision number: 16 > > Vendor Specific SMART Attributes with Thresholds: > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 =20 >=20 > Interesting, no reallocation has occured.... >=20 > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > 9 Power_On_Hours -O--CK 066 066 000 - 25343 > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 =20 >=20 > Hum, just noticed this. 25k hours power on, 2M load cycles, this is > very hard on a hard drive. Your drive is going into power save mode > and unloading the heads. Infact at a rate of 81 times per hour? > Oh, I can not believe that. Either way we need to get this stopped, > it shall wear your drives out. >=20 > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > 197 Current_Pending_Sector -O--CK 200 200 000 - 0 > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > ||||||_ K auto-keep > > |||||__ C event count > > ||||___ R error rate > > |||____ S speed/performance > > ||_____ O updated online > > |______ P prefailure warning > > [...] > >=20 > >=20 > > 197 Current_Pending_Sector decreased to zero so far, but with every reb= oot, the error > > count seems to increase: =20 >=20 > Ok, some drive firmware well at the power on even try to test the > pending sector list and clear it if it can actually read the sector. >=20 > >=20 > > [...] > > Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 day= s + 23 hours) > > When the command that caused the error occurred, the device was activ= e or idle. > >=20 > > After command completion occurred, registers were: > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- > > 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d= 988 =3D 3256473992 > >=20 > > Commands leading to the command that caused the error were: > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feat= ure_Name > > -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- ---------= ------ -------------------- > > 60 00 b0 00 d0 00 00 c2 19 da 28 40 08 1d+07:12:34.336 READ FPDMA Q= UEUED > > 60 00 b0 00 c8 00 00 c2 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA Q= UEUED > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT > > 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA Q= UEUED > > 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA Q= UEUED > >=20 > >=20 > > I think this is watching a HDD dying, isn't it? =20 >=20 > It could be, need to see as many of the other 46 errors as we can to make > a decision on that. Probably only 5 in the log though. As said above, see attached file ;-) >=20 > > I'd say, a broken cabling would produce different errors, wouldn't it? = =20 > Yes, there is a CRC error that would occur on cabling error. >=20 > > The Western Digital Green series HDD is a useful fellow when the HDD is= used as a > > single drive. I think there might be an issue with paring 4 HDDs, 3 of = them "GREEN", > > in a RAIDZ and physically sitting next to each other. Maybe it is time = to replace > > them one by one ... =20 >=20 > I am more suspecioius of them loading and unloading the head at a rate of > more than once per minute! >=20 [ ... schnipp ... ] --=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). --MP_/Dd35P6LvSzBZKm5JLE2mpNQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=smart_ada.txt smartctl 6.6 2017-11-05 r4594 [FreeBSD 12.0-CURRENT amd64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D Model Family: Western Digital Green Device Model: WDC WD30EZRX-00DC0B0 Serial Number: WD-SERIALNUMBER LU WWN Device Id: 5 0014ee 0ae168a02 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 13 09:42:51 2017 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled AAM feature is: Unavailable APM feature is: Unavailable Rd look-ahead is: Enabled Write cache is: Enabled DSN feature is: Unavailable ATA Security is: Disabled, frozen [SEC2] Wt Cache Reorder: Enabled =3D=3D=3D START OF READ SMART DATA SECTION =3D=3D=3D SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine comp= leted without error or no self-test has ever=20 been run. Total time to complete Offline=20 data collection: (38160) 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=20 recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 383) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x70b5) SCT Status 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 FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 3 Spin_Up_Time POS--K 178 170 021 - 6058 4 Start_Stop_Count -O--CK 098 098 000 - 2407 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 9 Power_On_Hours -O--CK 066 066 000 - 25344 10 Spin_Retry_Count -O--CK 100 100 000 - 0 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 12 Power_Cycle_Count -O--CK 098 098 000 - 2405 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 193 Load_Cycle_Count -O--CK 001 001 000 - 2055747 194 Temperature_Celsius -O---K 130 109 000 - 20 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 0 198 Offline_Uncorrectable ----CK 200 200 000 - 1 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning General Purpose Log Directory Version 1 SMART Log Directory Version 1 [multi-sector log support] Address Access R/W Size Description 0x00 GPL,SL R/O 1 Log Directory 0x01 SL R/O 1 Summary SMART error log 0x02 SL R/O 5 Comprehensive SMART error log 0x03 GPL R/O 6 Ext. Comprehensive SMART error log 0x06 SL R/O 1 SMART self-test log 0x07 GPL R/O 1 Extended self-test log 0x09 SL R/W 1 Selective self-test log 0x10 GPL R/O 1 NCQ Command Error log 0x11 GPL R/O 1 SATA Phy Event Counters log 0x80-0x9f GPL,SL R/W 16 Host vendor specific log 0xa0-0xa7 GPL,SL VS 16 Device vendor specific log 0xa8-0xb7 GPL,SL VS 1 Device vendor specific log 0xbd GPL,SL VS 1 Device vendor specific log 0xc0 GPL,SL VS 1 Device vendor specific log 0xc1 GPL VS 93 Device vendor specific log 0xe0 GPL,SL R/W 1 SCT Command/Status 0xe1 GPL,SL R/W 1 SCT Data Transfer SMART Extended Comprehensive Error Log Version: 1 (6 sectors) Device Error Count: 47 (device log contains only the most recent 24 errors) CR =3D Command Register FEATR =3D Features Register COUNT =3D Count (was: Sector Count) Register LBA_48 =3D Upper bytes of LBA High/Mid/Low Registers ] ATA-8 LH =3D LBA High (was: Cylinder High) Register ] LBA LM =3D LBA Mid (was: Cylinder Low) Register ] Register LL =3D LBA Low (was: Sector Number) Register ] DV =3D Device (was: Device/Head) Register DC =3D Device Control Register ER =3D Error register ST =3D Status register Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=3Ddays, hh=3Dhours, mm=3Dminutes, SS=3Dsec, and sss=3Dmillisec. It "wraps" after 49.710 days. Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 d0 00 00 c2 19 da 28 40 08 1d+07:12:34.336 READ FPDMA QUEUED 60 00 b0 00 c8 00 00 c2 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUED 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUED Error 46 [21] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUED 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:31.483 READ LOG EXT 60 00 b0 00 a0 00 00 c2 19 da 28 40 08 1d+07:12:28.631 READ FPDMA QUEUED 60 00 b0 00 98 00 00 c2 19 d9 78 40 08 1d+07:12:28.631 READ FPDMA QUEUED Error 45 [20] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 a0 00 00 c2 19 da 28 40 08 1d+07:12:28.631 READ FPDMA QUEUED 60 00 b0 00 98 00 00 c2 19 d9 78 40 08 1d+07:12:28.631 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:28.630 READ LOG EXT 60 00 b0 00 88 00 00 c2 19 da 28 40 08 1d+07:12:25.767 READ FPDMA QUEUED 60 00 b0 00 80 00 00 c2 19 d9 78 40 08 1d+07:12:25.767 READ FPDMA QUEUED Error 44 [19] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 88 00 00 c2 19 da 28 40 08 1d+07:12:25.767 READ FPDMA QUEUED 60 00 b0 00 80 00 00 c2 19 d9 78 40 08 1d+07:12:25.767 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:25.767 READ LOG EXT 60 00 b0 00 70 00 00 c2 19 da 28 40 08 1d+07:12:22.936 READ FPDMA QUEUED 60 00 b0 00 68 00 00 c2 19 d9 78 40 08 1d+07:12:22.936 READ FPDMA QUEUED Error 43 [18] occurred at disk power-on lifetime: 25343 hours (1055 days + = 23 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA =3D 0xc219d988 = =3D 3256473992 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 70 00 00 c2 19 da 28 40 08 1d+07:12:22.936 READ FPDMA QUEUED 60 00 b0 00 68 00 00 c2 19 d9 78 40 08 1d+07:12:22.936 READ FPDMA QUEUED 60 00 a8 00 60 00 00 c2 19 d8 b8 40 08 1d+07:12:22.934 READ FPDMA QUEUED 60 01 00 00 58 00 00 c2 19 d7 58 40 08 1d+07:12:22.934 READ FPDMA QUEUED 60 01 00 00 50 00 00 c2 19 d6 50 40 08 1d+07:12:22.926 READ FPDMA QUEUED Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 days + = 15 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc27a7298 = =3D 3262804632 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA QUEUED 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA QUEUED 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA QUEUED Error 41 [16] occurred at disk power-on lifetime: 25335 hours (1055 days + = 15 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc27a7298 = =3D 3262804632 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA QUEUED 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:09.342 READ LOG EXT 60 00 b0 00 58 00 00 c2 7a 73 20 40 08 23:38:06.490 READ FPDMA QUEUED 60 00 b0 00 50 00 00 c2 7a 72 70 40 08 23:38:06.490 READ FPDMA QUEUED Error 40 [15] occurred at disk power-on lifetime: 25335 hours (1055 days + = 15 hours) When the command that caused the error occurred, the device was active or= idle. After command completion occurred, registers were: ER -- ST COUNT LBA_48 LH LM LL DV DC -- -- -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA =3D 0xc27a7298 = =3D 3262804632 Commands leading to the command that caused the error were: CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_= Name -- =3D=3D -- =3D=3D -- =3D=3D =3D=3D =3D=3D -- -- -- -- -- -------------= -- -------------------- 60 00 b0 00 58 00 00 c2 7a 73 20 40 08 23:38:06.490 READ FPDMA QUEUED 60 00 b0 00 50 00 00 c2 7a 72 70 40 08 23:38:06.490 READ FPDMA QUEUED 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:06.489 READ LOG EXT 60 00 b0 00 40 00 00 c2 7a 73 20 40 08 23:38:03.637 READ FPDMA QUEUED 60 00 b0 00 38 00 00 c2 7a 72 70 40 08 23:38:03.637 READ FPDMA QUEUED SMART Extended Self-test Log Version: 1 (1 sectors) Num Test_Description Status Remaining LifeTime(hours)= LBA_of_first_error # 1 Short offline Completed without error 00% 22725 = - # 2 Short offline Completed without error 00% 7313 = - # 3 Extended offline Completed without error 00% 4465 = - # 4 Extended offline Interrupted (host reset) 10% 4045 = - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. SCT Status Version: 3 SCT Version (vendor specific): 258 (0x0102) SCT Support Level: 1 Device State: Active (0) Current Temperature: 20 Celsius Power Cycle Min/Max Temperature: 13/20 Celsius Lifetime Min/Max Temperature: 10/41 Celsius Under/Over Temperature Limit Count: 0/0 Vendor specific: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SCT Temperature History Version: 2 Temperature Sampling Period: 1 minute Temperature Logging Interval: 1 minute Min/Max recommended Temperature: 0/60 Celsius Min/Max Temperature Limit: -41/85 Celsius Temperature History Size (Index): 478 (311) Index Estimated Time Temperature Celsius 312 2017-12-13 01:45 27 ******** ... ..( 98 skipped). .. ******** 411 2017-12-13 03:24 27 ******** 412 2017-12-13 03:25 28 ********* ... ..( 67 skipped). .. ********* 2 2017-12-13 04:33 28 ********* 3 2017-12-13 04:34 ? - 4 2017-12-13 04:35 13 - 5 2017-12-13 04:36 13 - 6 2017-12-13 04:37 14 - 7 2017-12-13 04:38 15 - 8 2017-12-13 04:39 16 - 9 2017-12-13 04:40 16 - 10 2017-12-13 04:41 16 - 11 2017-12-13 04:42 17 - 12 2017-12-13 04:43 17 - 13 2017-12-13 04:44 17 - 14 2017-12-13 04:45 18 - 15 2017-12-13 04:46 18 - 16 2017-12-13 04:47 19 - 17 2017-12-13 04:48 19 - 18 2017-12-13 04:49 19 - 19 2017-12-13 04:50 20 * ... ..( 7 skipped). .. * 27 2017-12-13 04:58 20 * 28 2017-12-13 04:59 27 ******** ... ..( 13 skipped). .. ******** 42 2017-12-13 05:13 27 ******** 43 2017-12-13 05:14 28 ********* ... ..(163 skipped). .. ********* 207 2017-12-13 07:58 28 ********* 208 2017-12-13 07:59 27 ******** ... ..(102 skipped). .. ******** 311 2017-12-13 09:42 27 ******** SCT Error Recovery Control command not supported Device Statistics (GP/SMART Log 0x04) not supported Pending Defects log (GP Log 0x0c) not supported SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x0001 2 0 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 3 Transition from drive PhyRdy to drive PhyNRdy 0x000a 2 3 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x8000 4 1448 Vendor specific --MP_/Dd35P6LvSzBZKm5JLE2mpNQ-- --Sig_/mvP06IJ4=8CV0Ve8YnW_1hQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjDq7gAKCRDS528fyFhY lOt0AgCqmkPxxiiFp2RkDZmV2t90nbKYwRnVnmz83MaldwiNyETz+55wofCczcns MYyhctct6YaelwcFIdObYop8FjkIAfoD01lTN8no2E6SSlOqSsV34S1lALB9sEPP /6GirQ6nDF5jBO78vreiWlgB9Dl/fd5H/9EawF1GbP+CaMHHZt8I =GUQW -----END PGP SIGNATURE----- --Sig_/mvP06IJ4=8CV0Ve8YnW_1hQ-- From owner-freebsd-current@freebsd.org Wed Dec 13 13:23: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 A6DC4E9DDD2 for ; Wed, 13 Dec 2017 13:23:27 +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 6526670625; Wed, 13 Dec 2017 13:23:26 +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 vBDDNOvJ091809; Wed, 13 Dec 2017 05:23:24 -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 vBDDNOL6091808; Wed, 13 Dec 2017 05:23:24 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712131323.vBDDNOL6091808@pdx.rh.CN85.dnsmgr.net> Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAM status: ATA Status Error In-Reply-To: <20171213095510.4f025922@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" Date: Wed, 13 Dec 2017 05:23:24 -0800 (PST) CC: "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers 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: Wed, 13 Dec 2017 16:52:14 +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: Wed, 13 Dec 2017 13:23:27 -0000 > Am Tue, 12 Dec 2017 14:55:49 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > Am Tue, 12 Dec 2017 10:52:27 -0800 (PST) > > > "Rodney W. Grimes" schrieb: > > > > > > Thank you for answering that fast! Not so fast this time, had to sleep :) > > > > > Hello, > > > > > > > > > > running CURRENT (recent r326769), I realised that smartmond sends out some console > > > > > messages when booting the box: > > > > > > > > > > [...] > > > > > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 Currently > > > > > unreadable (pending) sectors Dec 12 14:14:33 <3.2> box1 smartd[68426]: > > > > > Device: /dev/ada6, 1 Offline uncorrectable sectors > > > > > [...] > > > > > > > > > > Checking the drive's SMART log with smartctl (it is one of four 3TB disk drives), > > > > > I gather these informations: > > > > > > > > > > [... smartctl -x /dev/ada6 ...] > > > > > Error 42 [17] occurred at disk power-on lifetime: 25335 hours (1055 days + 15 > > > > > hours) When the command that caused the error occurred, the device was active or > > > > > idle. > > > > > > > > > > After command completion occurred, registers were: > > > > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > > > > -- -- -- == -- == == == -- -- -- -- -- > > > > > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = > > > > > 3262804632 > > > > > > > > > > Commands leading to the command that caused the error were: > > > > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name > > > > > -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- > > > > > 60 00 b0 00 88 00 00 c2 7a 73 20 40 08 23:38:12.195 READ FPDMA QUEUED > > > > > 60 00 b0 00 80 00 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA QUEUED > > > > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT > > > > > 60 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA QUEUED > > > > > 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 READ FPDMA QUEUED > > > > > [...] > > > > > > > > > > and > > > > > > > > > > [...] > > > > > SMART Attributes Data Structure revision number: 16 > > > > > Vendor Specific SMART Attributes with Thresholds: > > > > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > > > > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 64 > > > > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > > > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > > > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > > > > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > > > > 9 Power_On_Hours -O--CK 066 066 000 - 25339 > > > > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > > > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > > > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > > > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > > > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > > > > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > > > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > > > > 197 Current_Pending_Sector -O--CK 200 200 000 - 1 > > > > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 Note here, we have a pending and we have an offline uncorrectable, an offline uncorrectable needs to end up in the remap, that should never end up cleared and back in the good blocks iirc, but then again firmware gets changed so maybe it is possible to return this to a good sector, either way it looks as if at this point in time we infact may have 2 seperate blocks that are bad. I have some long use heavily worn drives that have 10's of remapped sectors and they are still running fine. I would not use them for mission critical or in a high heavy use situation, but they are good for cold storage and other non critical use. A total of 2 reallocates I would not worry much about. Unless I am seeing a growth rate. Note that when these drives are shipped brand now for the first N Power On Hours they are in a special mode that is very quick to simply remap a "weak" sector. Ie, any sector that gets requires some threshold of M bits of error, the ECC already corrected the data but they vendor has decided that these are weak sectors and it should just remap them. Some firmware does not even call them Reallocated sectors, and adds them to the manaufactures P list. > > > > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > > > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > > > > ||||||_ K auto-keep > > > > > |||||__ C event count > > > > > ||||___ R error rate > > > > > |||____ S speed/performance > > > > > ||_____ O updated online > > > > > |______ P prefailure warning > > > > > > > > > > [...] > > > > > > > > The data up to this point informs us that you have 1 bad sector > > > > on a 3TB drive, that is actually an expected event given the data > > > > error rate on this stuff is such that your gona have these now > > > > and again. > > > > > > > > Given you have 1 single event I would not suspect that this drive > > > > is dying, but it would be prudent to prepare for that possibility. > > > > > > Hello. > > > > > > Well, I copied simply "one single event" that has been logged so far. > > > > > > As you (and I) can see, it is error #42. After I posted here, a reboot has taken place > > > because the "repair" process on the Pool suddenly increased time and now I'm with > > > error #47, but interestingly, it is a new block that is damaged, but the SMART > > > attribute fields show this for now: > > > > Can you send the complete output of smartctl -a /dev/foo, I somehow missed > > that 40+ other errors had occured. > > > Yes, here it is, but please do not beat me due to its size ;-). It is "smartctl -x", that > shows me the errors. See file attached named "smart_ada.txt". It is everything of > interest about the drive, I guess. This was not that large: 358 2901 17940 smart_ada.txt > > > [...] > > > SMART Attributes Data Structure revision number: 16 > > > Vendor Specific SMART Attributes with Thresholds: > > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > > > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 > > > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > > > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > > > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > > > > Interesting, no reallocation has occured.... > > > > > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > > > 9 Power_On_Hours -O--CK 066 066 000 - 25343 > > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > > > > Hum, just noticed this. 25k hours power on, 2M load cycles, this is > > very hard on a hard drive. Your drive is going into power save mode > > and unloading the heads. Infact at a rate of 81 times per hour? > > Oh, I can not believe that. Either way we need to get this stopped, > > it shall wear your drives out. > > > > > 194 Temperature_Celsius -O---K 122 109 000 - 28 > > > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > > > 197 Current_Pending_Sector -O--CK 200 200 000 - 0 > > > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > > > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > > > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > > > ||||||_ K auto-keep > > > |||||__ C event count > > > ||||___ R error rate > > > |||____ S speed/performance > > > ||_____ O updated online > > > |______ P prefailure warning > > > [...] > > > > > > > > > 197 Current_Pending_Sector decreased to zero so far, but with every reboot, the error > > > count seems to increase: > > > > Ok, some drive firmware well at the power on even try to test the > > pending sector list and clear it if it can actually read the sector. > > > > > > > > [...] > > > Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 days + 23 hours) > > > When the command that caused the error occurred, the device was active or idle. > > > > > > After command completion occurred, registers were: > > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > > -- -- -- == -- == == == -- -- -- -- -- > > > 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 > > > > > > Commands leading to the command that caused the error were: > > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name > > > -- == -- == -- == == == -- -- -- -- -- --------------- -------------------- > > > 60 00 b0 00 d0 00 00 c2 19 da 28 40 08 1d+07:12:34.336 READ FPDMA QUEUED > > > 60 00 b0 00 c8 00 00 c2 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA QUEUED > > > 2f 00 00 00 01 00 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT > > > 60 00 b0 00 b8 00 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUED > > > 60 00 b0 00 b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUED > > > > > > > > > I think this is watching a HDD dying, isn't it? > > > > It could be, need to see as many of the other 46 errors as we can to make > > a decision on that. Probably only 5 in the log though. > > As said above, see attached file ;-) I see 2 LBA's that have come up, and as I suspected only the last few errors are in the log: 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = 0xc219d988 = 3256473992 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = 3262804632 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = 3262804632 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = 0xc27a7298 = 3262804632 > > > I'd say, a broken cabling would produce different errors, wouldn't it? > > Yes, there is a CRC error that would occur on cabling error. > > > > > The Western Digital Green series HDD is a useful fellow when the HDD is used as a > > > single drive. I think there might be an issue with paring 4 HDDs, 3 of them "GREEN", > > > in a RAIDZ and physically sitting next to each other. Maybe it is time to replace > > > them one by one ... > > > > I am more suspecioius of them loading and unloading the head at a rate of > > more than once per minute! > > > [ ... schnipp ... ] At this point I woould turn one of tne ddrecover/ddrescue type tools loose on just those 2 blocks, let them try say 100 times to read the blocks, if either tool can read the block use dd to write it back to the same place and that should let the drive do a repair. If the block can not be read back at 100 tries I would just nuke the block with a dd oseek=N bs=512 count=1 if=/dev/zero of=/dev/FOO. Check to see if the drive added a reallocation, and then check that you can now read the block back with dd. If those are both true I would run a zfs scrub to get the correct data in the zero'ed block(s). -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Dec 13 15:11:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1645AEA11D8 for ; Wed, 13 Dec 2017 15:11:35 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 8D58F746EA; Wed, 13 Dec 2017 15:11:33 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from hermann ([141.89.176.204]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MUZG7-1eYAzw0sy3-00RKqM; Wed, 13 Dec 2017 16:11:23 +0100 Date: Wed, 13 Dec 2017 16:11:20 +0100 From: "Hartmann, O." To: Cy Schubert Cc: "O. Hartmann" , "Rodney W. Grimes" , FreeBSD CURRENT , Freddie Cash , Alan Somers Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error Message-ID: <20171213161116.1889f178@hermann> In-Reply-To: <20171212225827.CBCF2266@spqr.komquats.com> References: <20171212225827.CBCF2266@spqr.komquats.com> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:W7SxeZxrjputuurE6MhHNOkYUfgrMy2gi72pm5f0wjVLqkgTOca kGGEurQKby8cd3/cqoR5+YL2ouXqAidI6xtRT1aClynj+Cx5YY5sEvXTSuYiaDcUhW+9N6l CKe78MVITtYgCUHI8y18alvF0Mc+OKYtniLdREB1D+j92QZRjrPmk+JUGKw8AHIJ0cCwKVQ TbyVlhDilgMsxV/bvXMWQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:WKfHCmA0MhI=:w/lKmZt6y5l4/CMkGIITzR H2W6SQ2hdUEcXibxYJMLYDOEhG4q89KpHSoohI2HeQKeAShhaSUeLSo1pAFIxwk9ii8539gcd lvWtXAvNclkdTLoiWpLkcByRb0Y2k9za2XPm4yR+GjMXUtR6pD6CzXms+lSxKHrgNP7Bh24K+ rWdJGmHAcqNVyWGUGFB3UhuzhmlG+JJ6eIfz2cuu9zs4c4srSqMpBMZXOe4V2g2EfdU8zzj2+ pNwhS/cufX9Ig6KdS3PP8qEIPnhzW+daBSTayHV+cGhyHR+djY1gWoRWo3bpyv/d+Y6mFplUD vflCKlMJJwsY+dvkCmMl5yZuobE7WSw8+1cLQqg6XwdB2BWmoTX6QQlsW5epv+5XoR98/prC5 6GKJUnqzY+8d9mCxSlWdyPkIAIWlSIaI5dQ4JzN4hhEfDJ65d2iGtBlUYD+tXC39TfOpuZKh4 FvJ0hv16XvOaaTz7TCVQO39gD+7SH2PMMuxdQ1kg/EDu+7p11pj+PlUP9KYAulHo089qoEpu6 mYlz9XxcRCs508iEUYhJWeSI6lXtOTFs4FC9ZGKB6TCkLkP/J80BOMHjdv0w5YSnKg6GOrzWR DmywHgSBMgqIyC9fWtMTIqfbK7icAjNrs2xzYSiF5meCGcpPzOis63uJDFBeBw0GH7ngMpmMY HctC6UdVTpikVjhxRUamVuksdMDLmZz6x1NtvKe3Q413buTq4CVwel6HYlhdBLDwD8yrfYCD4 71+ciBdlvLejrJqDo1gS+uCdKf+HqmTvumVN9tolmT8RTiY4gTSEZBP6HnJucFWv06X+FdbkO a7hKvhD2Smb432FujSL/XARAjLUAYzdk8RoGf4OHJghn9wklIE= X-Mailman-Approved-At: Wed, 13 Dec 2017 16:53:46 +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: Wed, 13 Dec 2017 15:11:35 -0000 On Tue, 12 Dec 2017 14:58:28 -0800 Cy Schubert wrote: > There are a couple of ways you can address this. You'll need to > offline the vdev first. If you've done a smartcrl -t long and if the > test failed, smartcrl -a will tell you which block it had an issue > with. You can use dd, ddrescue or dd_rescue to dd the block over > itself. The drive may rewrite the (weak) block or if it fails to it > will remap it (subsequently showing as reallocated). > > Of course there is a risk. If the sector is any of the boot blocks > there is a good chance the server will hang. The drive is part of a dedicated storage-only pool. The boot drive is a fast SSD. So I do not care about this - well, to say it more politely: I do not have to take care of that aspect. > > You have to be *absolutely* sure which the bad sector is. And, there > may be more. There is a risk of data loss. > > I've used this technique many times. Most times it works perfectly. > Other times the affected file is lost but the rest of the file system > is recovered. And again there is always the risk. > > Replace the disk immediately if you experience a growing succession > of pending sectors. Otherwise replace the disk at your earliest > convenience. The ZFS scrubbing of the volume ended this morning, leaving the pool in a healthy state. After reboot, there was no sign of CAM errors again. But there is something else I'm worried about. The mainboard I use is a ASRock Z77 Pro4-M. The board has a cripple Intel MCP with 6 SATA ports from the chipset, two of them SATA 6GB, 4 SATA II, and one additional chip with two SATA 6GB ports: [...] ahci0@pci0:2:0:0: class=0x010601 card=0x06121849 chip=0x06121b21 rev=0x01 hdr=0x00 vendor = 'ASMedia Technology Inc.' device = 'ASM1062 Serial ATA Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xe050, size 8, enabled bar [14] = type I/O Port, range 32, base 0xe040, size 4, enabled bar [18] = type I/O Port, range 32, base 0xe030, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xe020, size 4, enabled bar [20] = type I/O Port, range 32, base 0xe000, size 32, enabled bar [24] = type Memory, range 32, base 0xf7b00000, size 512, enabled [...] Attached to that ASM1062 SATA chip, is a backup drive via eSATA connector, a WD 4 TB RED drive. It seems, whenever I attach this drive and it is online, I experience problems on the ZFS pool, which is attached to the MCP SATA ports. Is this possible? I mean, as I asked before, a weird/defect cabling would trigger different error schemes (CRC errors). Due to the fact that the external drive is physically decoupled and is not capable of coupling in vibrations, bad sector errors seem to me unlikely. But this is simply a though of someone without special knowledge about physics of HDDs. 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. > > If using a zfs mirror (not in your case) detatch and attach will > rewrite any weakly written sectors and reallocate pending sectors. > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -----Original Message----- > From: O. Hartmann > Sent: 12/12/2017 14:19 > To: Rodney W. Grimes > Cc: O. Hartmann; FreeBSD CURRENT; Freddie Cash; Alan Somers > Subject: Re: SMART: disk problems on RAIDZ1 pool: > (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error > > Am Tue, 12 Dec 2017 10:52:27 -0800 (PST) > "Rodney W. Grimes" schrieb: > > > Thank you for answering that fast! > > > > Hello, > > > > > > running CURRENT (recent r326769), I realised that smartmond sends > > > out some console messages when booting the box: > > > > > > [...] > > > Dec 12 14:14:33 <3.2> box1 smartd[68426]: Device: /dev/ada6, 1 > > > Currently unreadable (pending) sectors Dec 12 14:14:33 <3.2> box1 > > > smartd[68426]: Device: /dev/ada6, 1 Offline uncorrectable sectors > > > [...] > > > > > > Checking the drive's SMART log with smartctl (it is one of four > > > 3TB disk drives), I gather these informations: > > > > > > [... smartctl -x /dev/ada6 ...] > > > Error 42 [17] occurred at disk power-on lifetime: 25335 hours > > > (1055 days + 15 hours) When the command that caused the error > > > occurred, the device was active or idle. > > > > > > After command completion occurred, registers were: > > > ER -- ST COUNT LBA_48 LH LM LL DV DC > > > -- -- -- == -- == == == -- -- -- -- -- > > > 40 -- 51 00 00 00 00 c2 7a 72 98 40 00 Error: UNC at LBA = > > > 0xc27a7298 = 3262804632 > > > > > > Commands leading to the command that caused the error were: > > > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time > > > Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- > > > --------------- -------------------- 60 00 b0 00 88 00 00 c2 7a > > > 73 20 40 08 23:38:12.195 READ FPDMA QUEUED 60 00 b0 00 80 00 > > > 00 c2 7a 72 70 40 08 23:38:12.195 READ FPDMA QUEUED 2f 00 00 > > > 00 01 00 00 00 00 00 10 40 08 23:38:12.195 READ LOG EXT 60 > > > 00 b0 00 70 00 00 c2 7a 73 20 40 08 23:38:09.343 READ FPDMA > > > QUEUED 60 00 b0 00 68 00 00 c2 7a 72 70 40 08 23:38:09.343 > > > READ FPDMA QUEUED [...] > > > > > > and > > > > > > [...] > > > SMART Attributes Data Structure revision number: 16 > > > Vendor Specific SMART Attributes with Thresholds: > > > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL > > > RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 > > > - 64 3 Spin_Up_Time POS--K 178 170 021 > > > - 6075 4 Start_Stop_Count -O--CK 098 098 000 > > > - 2406 5 Reallocated_Sector_Ct PO--CK 200 200 140 > > > - 0 7 Seek_Error_Rate -OSR-K 200 200 000 - > > > 0 9 Power_On_Hours -O--CK 066 066 000 - 25339 > > > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > > > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > > > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > > > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > > > 193 Load_Cycle_Count -O--CK 001 001 000 - > > > 2055746 194 Temperature_Celsius -O---K 122 109 000 > > > - 28 196 Reallocated_Event_Count -O--CK 200 200 000 > > > - 0 197 Current_Pending_Sector -O--CK 200 200 000 > > > - 1 198 Offline_Uncorrectable ----CK 200 200 000 > > > - 1 199 UDMA_CRC_Error_Count -O--CK 200 200 000 > > > - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 > > > - 5 ||||||_ K auto-keep > > > |||||__ C event count > > > ||||___ R error rate > > > |||____ S speed/performance > > > ||_____ O updated online > > > |______ P prefailure warning > > > > > > [...] > > > > The data up to this point informs us that you have 1 bad sector > > on a 3TB drive, that is actually an expected event given the data > > error rate on this stuff is such that your gona have these now > > and again. > > > > Given you have 1 single event I would not suspect that this drive > > is dying, but it would be prudent to prepare for that possibility. > > Hello. > > Well, I copied simply "one single event" that has been logged so far. > > As you (and I) can see, it is error #42. After I posted here, a > reboot has taken place because the "repair" process on the Pool > suddenly increased time and now I'm with error #47, but > interestingly, it is a new block that is damaged, but the SMART > attribute fields show this for now: > > [...] > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE > 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 69 > 3 Spin_Up_Time POS--K 178 170 021 - 6075 > 4 Start_Stop_Count -O--CK 098 098 000 - 2406 > 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 > 7 Seek_Error_Rate -OSR-K 200 200 000 - 0 > 9 Power_On_Hours -O--CK 066 066 000 - 25343 > 10 Spin_Retry_Count -O--CK 100 100 000 - 0 > 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 > 12 Power_Cycle_Count -O--CK 098 098 000 - 2404 > 192 Power-Off_Retract_Count -O--CK 200 200 000 - 154 > 193 Load_Cycle_Count -O--CK 001 001 000 - 2055746 > 194 Temperature_Celsius -O---K 122 109 000 - 28 > 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 > 197 Current_Pending_Sector -O--CK 200 200 000 - 0 > 198 Offline_Uncorrectable ----CK 200 200 000 - 1 > 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 > 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 5 > ||||||_ K auto-keep > |||||__ C event count > ||||___ R error rate > |||____ S speed/performance > ||_____ O updated online > |______ P prefailure warning > [...] > > > 197 Current_Pending_Sector decreased to zero so far, but with every > reboot, the error count seems to increase: > > > [...] > Error 47 [22] occurred at disk power-on lifetime: 25343 hours (1055 > days + 23 hours) When the command that caused the error occurred, the > device was active or idle. > > After command completion occurred, registers were: > ER -- ST COUNT LBA_48 LH LM LL DV DC > -- -- -- == -- == == == -- -- -- -- -- > 40 -- 51 00 00 00 00 c2 19 d9 88 40 00 Error: UNC at LBA = > 0xc219d988 = 3256473992 > > Commands leading to the command that caused the error were: > CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time > Command/Feature_Name -- == -- == -- == == == -- -- -- -- -- > --------------- -------------------- 60 00 b0 00 d0 00 00 c2 19 da > 28 40 08 1d+07:12:34.336 READ FPDMA QUEUED 60 00 b0 00 c8 00 00 c2 > 19 d9 78 40 08 1d+07:12:34.336 READ FPDMA QUEUED 2f 00 00 00 01 00 > 00 00 00 00 10 40 08 1d+07:12:34.336 READ LOG EXT 60 00 b0 00 b8 00 > 00 c2 19 da 28 40 08 1d+07:12:31.484 READ FPDMA QUEUED 60 00 b0 00 > b0 00 00 c2 19 d9 78 40 08 1d+07:12:31.483 READ FPDMA QUEUED > > > I think this is watching a HDD dying, isn't it? > > I'd say, a broken cabling would produce different errors, wouldn't it? > > The Western Digital Green series HDD is a useful fellow when the HDD > is used as a single drive. I think there might be an issue with > paring 4 HDDs, 3 of them "GREEN", in a RAIDZ and physically sitting > next to each other. Maybe it is time to replace them one by one ... > > > > > > > > > > > The ZFS pool is RAIDZ1, comprised of 3 WD Green 3TB HDD and one > > > WD RED 3 TB HDD. The failure occured is on one of the WD Green 3 > > > TB HDD. > > Ok, so the data is redundantly protected. This helps a lot. > > > > > The pool is marked as "resilvered" - I do scrubbing on a regular > > > basis and the "resilvering" message has now aapeared the second > > > time in row. Searching the net recommend on SMART attribute 197 > > > errors, in my case it is one, and in combination with the > > > problems occured that I should replace the disk. > > > > It is probably putting the RAIDZ in that state as the scrub is > > finding a block it can not read. > > > > > > > > Well, here comes the problem. The box is comprised from > > > "electronical waste" made by ASRock - it is a Socket > > > 1150/IvyBridge board, which has its last Firmware/BIOS update got > > > in 2013 and since then UEFI booting FreeBSD from a HDD isn't > > > possible (just to indicate that I'm aware of having issues with > > > crap, but that is some other issue right now). The board's SATA > > > connectors are all populated. > > > > > > So: Due to the lack of adequate backup space I can only > > > selectively backup portions, most of the space is occupied by > > > scientific modelling data, which I had worked on. So backup > > > exists! In one way or the other. My concern is how to replace the > > > faulty HDD! Most HowTo's indicate a replacement disk being > > > prepared and then "replaced" via ZFS's replace command. This > > > isn't applicable here. > > > > > > Question: is it possible to simply pull the faulty disk (implies > > > I know exactly which one to pull!) and then prepare and add the > > > replacement HDD and let the system do its job resilvering the > > > pool? > > > > That may work, but I think I have a simpler solution. > > > > > > > > Next question is: I'm about to replace the 3 TB HDD with a more > > > recent and modern 4 TB HDD (WD RED 4TB). I'm aware of the fact > > > that I can only use 3 TB as the other disks are 3 TB, but I'd > > > like to know whether FreeBSD's ZFS is capable of handling it? > > > > Someone else? > > > > > > > > This is the first time I have issues with ZFS and a faulty drive, > > > so if some of my questions sound naive, please forgive me. > > > > One thing to try is to see if we can get the drive to fix itself, > > first order of business is can you take this server out of > > service? If so I would simply try to do a > > repeat 100 dd if=/dev/whicheverhdisbad of=/dev/null conv=noerror, > > sync iseek=3262804632 > > > > That is trying to read that block 100 times, if it successful even > > 1 time smart should remap the block and you are all done. > > Given the fact, that this errorneous block is like a moving target, > it this solution still the favorite one? I'll try, but I already have > the replacement 4 TB HDD at hand. > > > > > If that fails we can try to zero the block, there is a risk here, > > but raidz should just handle this as a data corruption of a block. > > This could possibly lead to data loss, so USE AT YOUR OWN RISK > > ASSESMENT. dd if=/dev/zero of=/dev/whateverdrivehasissues bs=512 > > count=1 oseek=3262804632 > > I would then be oseek=3256473992, too. > > > > > That should forceable overwrite the bad block with 0's, the smart > > firmware well see this in the pending list, write the data, read it > > back, if successful remove it from the pending list, if failed > > reallocate the block and write the 0's to the reallocation and add > > 1 to the remapped block count. > > > > You might google for "how to fix a pending reallocation" > > > > > Thanks in advance, > > > Oliver > > > -- > > > O. Hartmann > > > > Kind regards, > > Oliver > > From owner-freebsd-current@freebsd.org Wed Dec 13 16:48: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 600EBEA37A4 for ; Wed, 13 Dec 2017 16:48:01 +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 48DC27844B; Wed, 13 Dec 2017 16:48:00 +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 vBDGlsWh092529; Wed, 13 Dec 2017 08:47: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 vBDGlrf2092528; Wed, 13 Dec 2017 08:47:53 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error In-Reply-To: <20171213161116.1889f178@hermann> To: "Hartmann, O." Date: Wed, 13 Dec 2017 08:47:53 -0800 (PST) CC: Cy Schubert , "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers 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: Wed, 13 Dec 2017 18:37: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: Wed, 13 Dec 2017 16:48:01 -0000 > On Tue, 12 Dec 2017 14:58:28 -0800 > Cy Schubert wrote: > > > There are a couple of ways you can address this. You'll need to > > offline the vdev first. If you've done a smartcrl -t long and if the > > test failed, smartcrl -a will tell you which block it had an issue > > with. You can use dd, ddrescue or dd_rescue to dd the block over > > itself. The drive may rewrite the (weak) block or if it fails to it > > will remap it (subsequently showing as reallocated). > > > > Of course there is a risk. If the sector is any of the boot blocks > > there is a good chance the server will hang. > > The drive is part of a dedicated storage-only pool. The boot drive is a > fast SSD. So I do not care about this - well, to say it more politely: > I do not have to take care of that aspect. > > > > > You have to be *absolutely* sure which the bad sector is. And, there > > may be more. There is a risk of data loss. > > > > I've used this technique many times. Most times it works perfectly. > > Other times the affected file is lost but the rest of the file system > > is recovered. And again there is always the risk. > > > > Replace the disk immediately if you experience a growing succession > > of pending sectors. Otherwise replace the disk at your earliest > > convenience. > > The ZFS scrubbing of the volume ended this morning, leaving the pool in > a healthy state. After reboot, there was no sign of CAM errors again. > > But there is something else I'm worried about. The mainboard I use is a > > ASRock Z77 Pro4-M. > The board has a cripple Intel MCP with 6 SATA ports from the chipset, > two of them SATA 6GB, 4 SATA II, and one additional chip with two SATA > 6GB ports: > > [...] > ahci0@pci0:2:0:0: class=0x010601 card=0x06121849 chip=0x06121b21 > rev=0x01 hdr=0x00 vendor = 'ASMedia Technology Inc.' > device = 'ASM1062 Serial ATA Controller' > class = mass storage > subclass = SATA > bar [10] = type I/O Port, range 32, base 0xe050, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xe040, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xe030, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xe020, size 4, enabled > bar [20] = type I/O Port, range 32, base 0xe000, size 32, enabled > bar [24] = type Memory, range 32, base 0xf7b00000, size 512, > enabled > [...] > > Attached to that ASM1062 SATA chip, is a backup drive via eSATA > connector, a WD 4 TB RED drive. It seems, whenever I attach this drive > and it is online, I experience problems on the ZFS pool, which is > attached to the MCP SATA ports. How does this external drive get its power? Are the earth grounds of both the system and the external drive power supply closely tied togeather? A plug/unplug event with a slight ground creep can wreck havioc with device operation. > Is this possible? I mean, as I asked before, a weird/defect cabling > would trigger different error schemes (CRC errors). Due to the fact > that the external drive is physically decoupled and is not capable of > coupling in vibrations, bad sector errors seem to me unlikely. But this > is simply a though of someone without special knowledge about physics > of HDDs. Even if left cabled, does this drive get powered up/down? > 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. ... 275 lines removes ... -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Dec 13 19:39:55 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 8CF59E84899 for ; Wed, 13 Dec 2017 19:39:55 +0000 (UTC) (envelope-from o.hartmann@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 05AE27F875; Wed, 13 Dec 2017 19:39:54 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.180.147.251]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGXV6-1eC3iR2PK4-00DG9l; Wed, 13 Dec 2017 20:39:43 +0100 Date: Wed, 13 Dec 2017 20:39:08 +0100 From: "O. Hartmann" To: "Rodney W. Grimes" Cc: Cy Schubert , "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error Message-ID: <20171213203935.270e5f65@thor.intern.walstatt.dynvpn.de> In-Reply-To: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> References: <20171213161116.1889f178@hermann> <201712131647.vBDGlrf2092528@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_/yQe_re/+qDm74aywZGbTQDl"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:ZtkQeU+OjVWQTcHst0+pbKwKVE9QHuN2NVpz9xW1hhGhCTfJjAx SU70yIdKf2cvQjJc8QEbBX+Gu6wQDGG0U+O8FwWOTLcFHa2ONzhKVOiCDxRZNFkhUpVe6u4 nbNcO7n56sxgS8rc7D9635L7RJQHos4pJsAl4E8l71r/TAOXLCPjDL3JRDExGLaPXMEOyIM h9b2e39i+h0s5kcj6AEMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:g/vcj7G7/8Q=:jngaQIdk/hBkzgw+Wr1jqI 9DgCSamLNviwkrFldwjYKOHpB+FtIhh6Omce0g2rqoErOiQCcMjmY754F3LM5RI9ssGpsbABP JR1qxR/ncsvpJssYF8RoFGyfWU0KJx/e+2hqPry41BRUW1FVn6Hv4t2zqdsN+yMrQ1Uj6oVGV TAtibN0oZXb/mEepWamZskSGp55+A8eganZME9C0bmCKTSrdIsh5tG3vS2GrXA3aH16rds0FW dypM8fIDiiMD4x68N99f7vsHiB1lWppv68U486qMByl2rnHM+pjgjcsw5y2KxKMMooAnND+8d W2JYuJalkAB6IlEE/IirGwKUx6JFPQQcLtZUQGOZHa+xCSJFSZw4SVx/xDfL6C8fDudmCsqKM 5r36XxPUAO7H8aA/fP4Ep4r+OjmDArM8BQ+860ZLwSUYiVL4SSMWyqPtkRBZYyDtGYGLtZO0L 8vISy0gLyKWwAtt1Z4Z1hIr2O7R9XdVKJc8TriTXMjV/92SU3G0qQv9D5BxLIf3qIeX3MZb++ 1a2AYCbfTXCobWfx0om2gUs7KO0f+hfITfR9yQL3cUb6+tgBXZQzsduuHJD8hKpX4Xp+hpNmE gqDSK4uigdqRi3nFYAtfJ6NSzSPd64+aBPu9GN5ZY+7Oze2EP2mr34oYmzrrvVd1eAVx/5Ps2 Sa3E/a1f6YnMszbHIJYL2mBtCbvB6z0fGY6CVFj2yO8dPW8/PM1E1XHKdiqcTAZhe/GIXj3RA h+1/YPRSxgo8mdyHCkgQc5LrIlKPhB1UIwaxtZM6hef087KeRvlJrKL3m1AL/TBBdBKmpkTSN 7m+Q42x7If47HwX+W9gYPt+UH6jPg== X-Mailman-Approved-At: Wed, 13 Dec 2017 21:19:51 +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: Wed, 13 Dec 2017 19:39:55 -0000 --Sig_/yQe_re/+qDm74aywZGbTQDl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 13 Dec 2017 08:47:53 -0800 (PST) "Rodney W. Grimes" schrieb: > > On Tue, 12 Dec 2017 14:58:28 -0800 > > Cy Schubert wrote: > > =20 > > > There are a couple of ways you can address this. You'll need to > > > offline the vdev first. If you've done a smartcrl -t long and if the > > > test failed, smartcrl -a will tell you which block it had an issue > > > with. You can use dd, ddrescue or dd_rescue to dd the block over > > > itself. The drive may rewrite the (weak) block or if it fails to it > > > will remap it (subsequently showing as reallocated). > > >=20 > > > Of course there is a risk. If the sector is any of the boot blocks > > > there is a good chance the server will hang. =20 > >=20 > > The drive is part of a dedicated storage-only pool. The boot drive is a > > fast SSD. So I do not care about this - well, to say it more politely: > > I do not have to take care of that aspect. > > =20 > > >=20 > > > You have to be *absolutely* sure which the bad sector is. And, there > > > may be more. There is a risk of data loss. > > >=20 > > > I've used this technique many times. Most times it works perfectly. > > > Other times the affected file is lost but the rest of the file system > > > is recovered. And again there is always the risk. > > >=20 > > > Replace the disk immediately if you experience a growing succession > > > of pending sectors. Otherwise replace the disk at your earliest > > > convenience. =20 > >=20 > > The ZFS scrubbing of the volume ended this morning, leaving the pool in > > a healthy state. After reboot, there was no sign of CAM errors again. > >=20 > > But there is something else I'm worried about. The mainboard I use is a= =20 > >=20 > > ASRock Z77 Pro4-M. > > The board has a cripple Intel MCP with 6 SATA ports from the chipset, > > two of them SATA 6GB, 4 SATA II, and one additional chip with two SATA > > 6GB ports: > >=20 > > [...] > > ahci0@pci0:2:0:0: class=3D0x010601 card=3D0x06121849 chip=3D0x061= 21b21 > > rev=3D0x01 hdr=3D0x00 vendor =3D 'ASMedia Technology Inc.' > > device =3D 'ASM1062 Serial ATA Controller' > > class =3D mass storage > > subclass =3D SATA > > bar [10] =3D type I/O Port, range 32, base 0xe050, size 8, enabled > > bar [14] =3D type I/O Port, range 32, base 0xe040, size 4, enabled > > bar [18] =3D type I/O Port, range 32, base 0xe030, size 8, enabled > > bar [1c] =3D type I/O Port, range 32, base 0xe020, size 4, enabled > > bar [20] =3D type I/O Port, range 32, base 0xe000, size 32, enabl= ed > > bar [24] =3D type Memory, range 32, base 0xf7b00000, size 512, > > enabled > > [...] > >=20 > > Attached to that ASM1062 SATA chip, is a backup drive via eSATA > > connector, a WD 4 TB RED drive. It seems, whenever I attach this drive > > and it is online, I experience problems on the ZFS pool, which is > > attached to the MCP SATA ports. =20 >=20 > How does this external drive get its power? Are the earth grounds of > both the system and the external drive power supply closely tied > togeather? A plug/unplug event with a slight ground creep can > wreck havioc with device operation. The external drive is housed in a external casing. Its PSU is de facto with= the same "grounding" (earth ground) as the server's PSU, they share the same power p= lug at its point were the plug is comeing out of the wall - so to speak. >=20 > > Is this possible? I mean, as I asked before, a weird/defect cabling > > would trigger different error schemes (CRC errors). Due to the fact > > that the external drive is physically decoupled and is not capable of > > coupling in vibrations, bad sector errors seem to me unlikely. But this > > is simply a though of someone without special knowledge about physics > > of HDDs. =20 >=20 > Even if left cabled, does this drive get powered up/down? =20 The drive is cabled (eSATA) all the time, but is switched off for long time= s (4 - 8 weeks or 2 months, it depends, I switch it on for scrubbing or performing backups= of important data). >=20 > > 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. =20 >=20 > 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. >=20 > ... 275 lines removes ... I'm prepared already, as stated, to change the drive(s), one by one.=20 Hopefully, ZFS is as reliable to me as it has been reliable for others ;-) 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_/yQe_re/+qDm74aywZGbTQDl Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjGB9wAKCRDS528fyFhY lB3dAgCYHFdXDKgsrVXMr313TCddH11w6D9DtHlTEuOljeylnMlZrq8bcII+Vtpb xFyj8Kgd8leRan64U5NKr5obOSPWAf9mUXR2PcHX+n8LwCoG4oKD0911LDBk523r vUUc5uwGO3WdO9c4qDHlu8bywV1DQPh0Q3OIXLFuIIDjct8WYpdm =Hlgc -----END PGP SIGNATURE----- --Sig_/yQe_re/+qDm74aywZGbTQDl-- From owner-freebsd-current@freebsd.org Wed Dec 13 22:07:37 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 0BB9DE88EB1 for ; Wed, 13 Dec 2017 22:07:37 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A5B5E664CB for ; Wed, 13 Dec 2017 22:07:35 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [10.182.63.93] (85-118-79-108.mtel.net [85.118.79.108]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.15.2/8.15.2) with ESMTPSA id vBDM7Qdn032751 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Dec 2017 00:07:27 +0200 (EET) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error From: Daniel Kalchev X-Mailer: iPhone Mail (15C114) In-Reply-To: <20171213203935.270e5f65@thor.intern.walstatt.dynvpn.de> Date: Thu, 14 Dec 2017 00:07:24 +0200 Cc: "Rodney W. Grimes" , Cy Schubert , "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171213161116.1889f178@hermann> <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> <20171213203935.270e5f65@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" 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, 13 Dec 2017 22:07:37 -0000 > On 13 Dec 2017, at 21:39, O. Hartmann wrote: >=20 > Am Wed, 13 Dec 2017 08:47:53 -0800 (PST) > "Rodney W. Grimes" schrieb: >=20 >>> On Tue, 12 Dec 2017 14:58:28 -0800 >>> Cy Schubert wrote: >>>=20 >>>> There are a couple of ways you can address this. You'll need to >>>> offline the vdev first. If you've done a smartcrl -t long and if the >>>> test failed, smartcrl -a will tell you which block it had an issue >>>> with. You can use dd, ddrescue or dd_rescue to dd the block over >>>> itself. The drive may rewrite the (weak) block or if it fails to it >>>> will remap it (subsequently showing as reallocated). >>>>=20 >>>> Of course there is a risk. If the sector is any of the boot blocks >>>> there is a good chance the server will hang. =20 >>>=20 >>> The drive is part of a dedicated storage-only pool. The boot drive is a >>> fast SSD. So I do not care about this - well, to say it more politely: >>> I do not have to take care of that aspect. >>>=20 >>>>=20 >>>> You have to be *absolutely* sure which the bad sector is. And, there >>>> may be more. There is a risk of data loss. >>>>=20 >>>> I've used this technique many times. Most times it works perfectly. >>>> Other times the affected file is lost but the rest of the file system >>>> is recovered. And again there is always the risk. >>>>=20 >>>> Replace the disk immediately if you experience a growing succession >>>> of pending sectors. Otherwise replace the disk at your earliest >>>> convenience. =20 >>>=20 >>> The ZFS scrubbing of the volume ended this morning, leaving the pool in >>> a healthy state. After reboot, there was no sign of CAM errors again. >>>=20 >>> But there is something else I'm worried about. The mainboard I use is a=20= >>>=20 >>> ASRock Z77 Pro4-M. >>> The board has a cripple Intel MCP with 6 SATA ports from the chipset, >>> two of them SATA 6GB, 4 SATA II, and one additional chip with two SATA >>> 6GB ports: >>>=20 >>> [...] >>> ahci0@pci0:2:0:0: class=3D0x010601 card=3D0x06121849 chip=3D0x0612= 1b21 >>> rev=3D0x01 hdr=3D0x00 vendor =3D 'ASMedia Technology Inc.' >>> device =3D 'ASM1062 Serial ATA Controller' >>> class =3D mass storage >>> subclass =3D SATA >>> bar [10] =3D type I/O Port, range 32, base 0xe050, size 8, enabled >>> bar [14] =3D type I/O Port, range 32, base 0xe040, size 4, enabled >>> bar [18] =3D type I/O Port, range 32, base 0xe030, size 8, enabled >>> bar [1c] =3D type I/O Port, range 32, base 0xe020, size 4, enabled >>> bar [20] =3D type I/O Port, range 32, base 0xe000, size 32, enabled= >>> bar [24] =3D type Memory, range 32, base 0xf7b00000, size 512, >>> enabled >>> [...] >>>=20 >>> Attached to that ASM1062 SATA chip, is a backup drive via eSATA >>> connector, a WD 4 TB RED drive. It seems, whenever I attach this drive >>> and it is online, I experience problems on the ZFS pool, which is >>> attached to the MCP SATA ports. =20 >>=20 >> How does this external drive get its power? Are the earth grounds of >> both the system and the external drive power supply closely tied >> togeather? A plug/unplug event with a slight ground creep can >> wreck havioc with device operation. >=20 > The external drive is housed in a external casing. Its PSU is de facto wit= h the same > "grounding" (earth ground) as the server's PSU, they share the same power p= lug at its > point were the plug is comeing out of the wall - so to speak. Most external drive power supplies are not grounded. At least none I ever sa= w had grounded plugs for the mains cable. Might be, yours has it... Worth checking anyway. Daniel From owner-freebsd-current@freebsd.org Thu Dec 14 05:43: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 A37F0E9632C for ; Thu, 14 Dec 2017 05:43:47 +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 42EFD746B4; Thu, 14 Dec 2017 05:43:46 +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 vBE5hVnT064629 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=OK); Thu, 14 Dec 2017 16:43:38 +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 vBE5hK56014828 (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Thu, 14 Dec 2017 16:43:21 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id vBE5hKJD014827; Thu, 14 Dec 2017 16:43:20 +1100 (AEDT) (envelope-from peter) Date: Thu, 14 Dec 2017 16:43:20 +1100 From: Peter Jeremy To: Gary Palmer Cc: blubee blubeeme , Mark Millard , FreeBSD Current Subject: Re: get_swap_pager(x) failed Message-ID: <20171214054320.GA3198@server.rulingia.com> References: <20171213112346.GA27816@in-addr.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <20171213112346.GA27816@in-addr.com> 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: Thu, 14 Dec 2017 05:43:47 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Dec-13 11:23:46 +0000, Gary Palmer wrote: >An open question would be why ARC is not reducing if the system is >under memory pressure. It's meant to, but there have been various >bugs in that implementation. The OP doesn't say what version of -current he is running but I would point the finger at r325851. I have discovered that, in 11-stable, r326619 (which is the MFC of r325851) stops ARC responding to memory backpressure. --=20 Peter Jeremy --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJaMg94XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs08LgP/0MzWSqmuUyLOrKCx2loajZI 8oNLxEB+FdD07n4RlzuwK4+vWhB/fgIguTsQ876H4XjTz79a9SZTlL+0xH7wiYks iA67NwwY+RJ1cjr0wTwuUtzdx7BVEP2ZuUGvkw3vbpWf9g7UO9ShgWnY7weOUa1G ax7hIZDpqUVmP4oxn72bKdPwqDTkuq80oP+NoD2HxR8AdLPHl0gpK9X0VrnoJPA2 py+SDYhGvQaGY6AwqhAZT2E/1b1cp7cjalES6gRyniMaTrDoupI/Rzhs2wD81Y4j RBYPnh4u8VXSxv0ocMNzwYhLqhHDBjb/JCkF4Riy31AMuw8W52tO08CdmDncdHXc UAo9Uktehd74SXt0PeBBLAHS79/hJdLEXQG5BbbMVA357SyzfHaCoyUkP3Hr+GU1 qdeTmS6A31+ge2lvvQq2ZlY5C4rAIvdbSR2ojZwEClnMb9UT3pPwl0nHgUA39kZG dnvyiGhU8irgoJm6zCXVh8zHyDzvDb8v7Nb3anoajG6egtF50Qe4nTOdoiYSwRLP 4YlA8nzfk/tdSRO8hZcljTYnHs8Guo2BlkNi0YSQv2D5Aeq5h+ibzjvXvJQ4JtGo Crm/e5Ns73HRVpTDBA+YlIJHPDnH3wFaVQOfEGufCRPcI7P7lDD4Jm606l9gWTPw 6WpX43UtOVV9e9QCObG3 =X/KS -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-current@freebsd.org Thu Dec 14 05:47: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 032DAE96627 for ; Thu, 14 Dec 2017 05:47:15 +0000 (UTC) (envelope-from gurenchan@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 C09207497F for ; Thu, 14 Dec 2017 05:47:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22d.google.com with SMTP id d137so8340586itc.2 for ; Wed, 13 Dec 2017 21:47:14 -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=BAF5cWbBxN/CnmxNATDaeecZbJJOB5g8by3YwX/c9ts=; b=qc3uFMj+vE53uv3/9h2fCWx2kbNc/CzfDaULBGurZly6KQXupI5SISFwq2l8p8xchf waIDSMy17hjtAb6bR/NBGaPCgYuOeiT14xhMaH83chFJD5f8c2nj8TbEdKKdrsOtzeTN sv3LXyiyrea1i9Ps6PGoFtOrSMzxL2tslohqR3WrLGPeord3jNv/R/t8KLIdDSDChk4A ba8ImtEwkwu2gfPLKJsVhuYB4zwBQzmb+YGrPUKjaJVo+CzPxzc6D4BmFHGD+iSAVZcC frU1bXbTtjKRHvsPNC7sWMRSzR7jh35dtRhIBp4ZFFW0QqqoqF49RVpZ/i+PjtbSd/ci w8Gg== 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=BAF5cWbBxN/CnmxNATDaeecZbJJOB5g8by3YwX/c9ts=; b=LUr5OXvhu3uIghJS68oEJ7XKiQSGS0mfab4qH8P9fZueBmf6J1wFoSh9LM0dJBATi0 PlumkM/E+07GDQfZC+gXuGen4wQFp2luXIn8Z0x0DFgDi1myr69HV0f0DjW3VRyUwR5s uArUMycCL1doaMKj3U1quzxwywyjGeXmL0zVMdOVkZyem+kueXS2y+6nIMr8K8stFnG2 T7AtfaMAgklTgW3Tv+uW34HDuJJUsjyjoDn3DjkgmCdU1m90ZJ3AuDO9ba+6Dk17UiKD Xm5YunLUP/hYb/K9uonevwh1IiAEjeHB5TgIBGlcS45ytW82ClGv406aQOEL8TC1Mnpt rLvA== X-Gm-Message-State: AKGB3mL0U8HyyNc4JDmOjYjnEsCTKHnIGBsIb2iG964pVgSh+3HOJR7K SFMIaZplLcPNnZXcTX2Zi+/75+ac8jjwRmPzVCwueQ== X-Google-Smtp-Source: ACJfBothhEsMZ+KwYdFsPMFJADfABApdoep/bl0wPC6zPYhOmQoRK1fEycyaHtlJxKMuIGwDNsrMJBbWbTgrSe3K4GM= X-Received: by 10.36.67.141 with SMTP id s135mr1744689itb.149.1513230433878; Wed, 13 Dec 2017 21:47:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Wed, 13 Dec 2017 21:47:13 -0800 (PST) From: blubee blubeeme Date: Thu, 14 Dec 2017 13:47:13 +0800 Message-ID: Subject: kernel names 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: Thu, 14 Dec 2017 05:47:15 -0000 When you boot into FreeBSD and you can select kernels, there's only 2 options: default and kernel.old Is there a way to have better output and support multiple kernels without having to login to the system and running uname -v or something like that? Would it be possible to add options for more kernels from that boot menu? From owner-freebsd-current@freebsd.org Thu Dec 14 05: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 BAB19E967A4 for ; Thu, 14 Dec 2017 05:48:47 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F29E74B19; Thu, 14 Dec 2017 05:48:47 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x241.google.com with SMTP id f143so8374324itb.0; Wed, 13 Dec 2017 21:48:47 -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=gWOWlTOT1tl1AbtDkuMiqZw2zKnU5aeRtdN9L8KBQM0=; b=icU+BTSMLv3oc0NUtOlBdzmfw+ml8CflMZhxEY7VxJBwJA8WfaHzSPRy0Qc/L+bbck q0d1gvMncE8bxQ1eeBMIwap+prk3HuXOuRl6/tE07OtAtU7TBbnnaLxV3ZltdSdFdcD0 cRXONctVnLcw2m2s80tJHBigP++RZBmfj20JKGxE3jYlsnLHfHd+yBLw8UnWFRkECLyj fhtTvoYGTm2zLq2fjLPq+KpmD/8NexwA3SSTbuNt/5omIS39AW6v5GhuNxig6fztTNkK B32C2ij2YH8ZxS1s0RQx0ypAQjKAEJe7YI1YEuz7pIPo5mDFB6PqgPtnLjZNC0fABNUj 2ZYg== 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=gWOWlTOT1tl1AbtDkuMiqZw2zKnU5aeRtdN9L8KBQM0=; b=aLeyvQ7dsqJ86aSBoTsTYgxM+CC7nKZcSrhTtE32CFcMbqeIdLQBMY9S0fqzavSq22 hX1q+S7osjG24CQqU4oVau1DA7uCgn7lfajZ/GUQFhQFu0d+0xyW4k2otaLj+i126frj hhgZRS4hBX38ltA5Ny9ugDIsf438e9TFzqEoU3okNKq5aL3hJM5MvKGpYuUFL75Hog5N ThGvIJXHqTN5etaC/L3lbOwLRlctMZw1+dvmJBvAq1mgUhf9Hr4s0qVqr2/BhlgAnq97 wdUKFnPnySJxEzz5yUsTJrqoVrRVRA1MZFWmwvSYSTTAVtwOJip0qdwHB2II+Dte1bY9 QTKw== X-Gm-Message-State: AKGB3mJTHFXAOQlqxaY10DMKK8MbGXXN67S94rLokWHyQUmE77K+w/9c RVzon25/hS9Immqja+PeAxevcjJxT+xk0WyJgPHkooUY X-Google-Smtp-Source: ACJfBouoe9Qtln8+eIkE4idYt0cIpSR3n8BKsdSrowJ7N/2YrmvHKNaUsybCxeepZDWgi2hEvfaEJp6WWm1tOsopOWY= X-Received: by 10.36.67.141 with SMTP id s135mr1747837itb.149.1513230526877; Wed, 13 Dec 2017 21:48:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Wed, 13 Dec 2017 21:48:46 -0800 (PST) In-Reply-To: <20171214054320.GA3198@server.rulingia.com> References: <20171213112346.GA27816@in-addr.com> <20171214054320.GA3198@server.rulingia.com> From: blubee blubeeme Date: Thu, 14 Dec 2017 13:48:46 +0800 Message-ID: Subject: Re: get_swap_pager(x) failed To: Peter Jeremy Cc: Gary Palmer , Mark Millard , 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: Thu, 14 Dec 2017 05:48:47 -0000 On Thu, Dec 14, 2017 at 1:43 PM, Peter Jeremy wrote: > On 2017-Dec-13 11:23:46 +0000, Gary Palmer wrote: > >An open question would be why ARC is not reducing if the system is > >under memory pressure. It's meant to, but there have been various > >bugs in that implementation. > > The OP doesn't say what version of -current he is running but I would > point the finger at r325851. I have discovered that, in 11-stable, > r326619 (which is the MFC of r325851) stops ARC responding to memory > backpressure. > > -- > Peter Jeremy > I just did a new install world and kernel so I'm but this is uname -v FreeBSD 12.0-CURRENT #0 r326839: Thu Dec 14 13:34:47 CST 2017 root@blubee:/usr/obj/usr/src/amd64.amd64/sys/OSS_GENERIC The previous was with GENERIC kernel and maybe ports & src from two weeks ago. From owner-freebsd-current@freebsd.org Thu Dec 14 05:52:02 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 63794E96AE9 for ; Thu, 14 Dec 2017 05:52:02 +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 45BD974ED7 for ; Thu, 14 Dec 2017 05:52:02 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from Ticonderoga.HML3.ScaleEngine.net (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3419E140A6 for ; Thu, 14 Dec 2017 05:51:55 +0000 (UTC) Subject: Re: kernel names To: freebsd-current@freebsd.org References: From: Allan Jude Message-ID: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> Date: Thu, 14 Dec 2017 00:51:54 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 14 Dec 2017 05:52:02 -0000 On 12/14/2017 00:47, blubee blubeeme wrote: > When you boot into FreeBSD and you can select kernels, there's only 2 > options: > default and kernel.old > > Is there a way to have better output and support multiple kernels without > having to login to the system and running uname -v or something like that? > > Would it be possible to add options for more kernels from that boot menu? > _______________________________________________ > 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" > The list is controlled by the /boot/loader.conf variable kernels= which defaults to "kernel kernel.old" I have a patch almost ready to land that will search all subdirectories of /boot for a file named 'kernel' and add the names of those directories to the list, such that the list will basically be autogenerated. It currently contains too much copy/pasted code, and I just need to clean it up a bit: https://reviews.freebsd.org/D11886 It was originally designed as part of my contributions towards packaged base, where pkg will keep the last N (default to 5 I think) kernel packages you have installed around, incase an upgrade goes bad. This feature will work on any filesystem supported by the loader. -- Allan Jude From owner-freebsd-current@freebsd.org Thu Dec 14 06:24:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 183FEE97DBC for ; Thu, 14 Dec 2017 06:24:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-125.reflexion.net [208.70.210.125]) (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 B79197606A for ; Thu, 14 Dec 2017 06:24:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13497 invoked from network); 14 Dec 2017 05:57:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Dec 2017 05:57:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 14 Dec 2017 00:57:47 -0500 (EST) Received: (qmail 31705 invoked from network); 14 Dec 2017 05:57:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Dec 2017 05:57:47 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 92681EC9464; Wed, 13 Dec 2017 21:57:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: get_swap_pager(x) failed From: Mark Millard In-Reply-To: <20171214054320.GA3198@server.rulingia.com> Date: Wed, 13 Dec 2017 21:57:46 -0800 Cc: Gary Palmer , blubee blubeeme , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <1DBEABD8-91C8-430B-A15A-9DEAC1FE8B12@dsl-only.net> References: <20171213112346.GA27816@in-addr.com> <20171214054320.GA3198@server.rulingia.com> To: Peter Jeremy 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: Thu, 14 Dec 2017 06:24:35 -0000 On 2017-Dec-13, at 9:43 PM, Peter Jeremy wrote: > On 2017-Dec-13 11:23:46 +0000, Gary Palmer wrote: >> An open question would be why ARC is not reducing if the system is >> under memory pressure. It's meant to, but there have been various >> bugs in that implementation. > > The OP doesn't say what version of -current he is running but I would > point the finger at r325851. I have discovered that, in 11-stable, > r326619 (which is the MFC of r325851) stops ARC responding to memory > backpressure. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224080 (bugzialla 224080 ) about problems with zfs from head -r326347 . bugzilla 224330 is another -r326347 problem report (based on some list reports) but that are for problems in some non-zfs contexts. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Dec 14 07:15:06 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 62734E996A0 for ; Thu, 14 Dec 2017 07:15:06 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2874877D23; Thu, 14 Dec 2017 07:15:06 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x244.google.com with SMTP id m11so23903909iti.1; Wed, 13 Dec 2017 23:15:06 -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=mzDTfgE4MZGh7mt2oxUQ+s9zdha4Sbm2wovnQL9Qij0=; b=jQEjIuAo/KEZkIN+SaolAImEbL0MZ2LN3tm5h2gP3z2hy/MsJGFJSZbPl3PbYn99RN PQXgy/7JYbzbRsOTt6cSQ5W1EjyygnWkSJz5Vw/hCeHiyMO/XRnDbHh4FjG0sFJIfIGs bULqy6FCgBzTXhko37LJkHTFBPP1FrOM4nc/OC0nsKCQsEDFejSW1M4mDMPkit/xbs5H 0if6fTqNtJtxfDrzYtLLhTZpRdzgbXgZ1VnUbtiEr7uN2QPw7qklAWa6AzGXWScujtzw ltBiOvj2i8hC0iGldNexG65I9goFSsPqmd1w7AsoDxVg0ADM77WR8IWoSpo30NcOMDyd 0/dg== 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=mzDTfgE4MZGh7mt2oxUQ+s9zdha4Sbm2wovnQL9Qij0=; b=feMsl22NqbHeNfztdrrMe2GZSUZEfugmrRaEFTKIHKuShbG5cofrwoqMlsiUoJuX5m u2hui2CpQ3EeNQE3Go+Ca2HGz7pn6gWEU7n97cYkjH7gs/8/27Jvgs+f/Qj6DiDcmGgF eo8OgyxycPZ9qHSZV4hjH3mvZlE0S1TdE5SmNsByJm5CZF9DiBEXXK8G1l6allADtadV Y00GfOjdWP6pJOAEBqExeBzTFvtRHpxMZgZHQ2D0gK8sy9UoiaVnmn5RqzjPRQXM5nVc x0TIkE3vnwfyaQmCLgjxb5FAJ7c3H5Fkej58fk7/OQIkYFdJxyGKunqX7SnmbrPquZLE baig== X-Gm-Message-State: AKGB3mK7k7KgmRP6qOWf1vnWePZT4/bRl9arJksgJpP4wgtqtjwfoVPX TM4AMIuG4KJuUPkqy2VK/3/m26yAA18cmvA9gx8/4w== X-Google-Smtp-Source: ACJfBotctFxF+92G5SKNH7UDj3TuflImj0DSUaFVQT7aRNdq4yOGN3wnNDN0JKNxan25X0rtTXuQ/BUZYeJEmdytNiY= X-Received: by 10.107.24.198 with SMTP id 189mr6013368ioy.213.1513235705095; Wed, 13 Dec 2017 23:15:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.11.31 with HTTP; Wed, 13 Dec 2017 23:15:04 -0800 (PST) In-Reply-To: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> References: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> From: blubee blubeeme Date: Thu, 14 Dec 2017 15:15:04 +0800 Message-ID: Subject: Re: kernel names To: Allan Jude Cc: 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: Thu, 14 Dec 2017 07:15:06 -0000 On Thu, Dec 14, 2017 at 1:51 PM, Allan Jude wrote: > On 12/14/2017 00:47, blubee blubeeme wrote: > > When you boot into FreeBSD and you can select kernels, there's only 2 > > options: > > default and kernel.old > > > > Is there a way to have better output and support multiple kernels without > > having to login to the system and running uname -v or something like > that? > > > > Would it be possible to add options for more kernels from that boot menu? > > _______________________________________________ > > 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" > > > > The list is controlled by the /boot/loader.conf variable kernels= > which defaults to "kernel kernel.old" > > I have a patch almost ready to land that will search all subdirectories > of /boot for a file named 'kernel' and add the names of those > directories to the list, such that the list will basically be > autogenerated. > > It currently contains too much copy/pasted code, and I just need to > clean it up a bit: https://reviews.freebsd.org/D11886 > > It was originally designed as part of my contributions towards packaged > base, where pkg will keep the last N (default to 5 I think) kernel > packages you have installed around, incase an upgrade goes bad. > > This feature will work on any filesystem supported by the loader. > > -- > Allan Jude > _______________________________________________ > 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" > Allen, thanks for the great work. I'll test it out but I can't wait to have it merged in. From owner-freebsd-current@freebsd.org Thu Dec 14 07:53: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 4C238E9AB30 for ; Thu, 14 Dec 2017 07:53:56 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 2C45079324 for ; Thu, 14 Dec 2017 07:53:55 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBE7tN1K069813; Wed, 13 Dec 2017 23:55:29 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "FreeBSD current" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "blubee blubeeme" Subject: Re: kernel names Date: Wed, 13 Dec 2017 23:55:29 -0800 Message-Id: <557f416fc12e0af38cc7da5c7a57932a@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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, 14 Dec 2017 07:53:56 -0000 On Thu, 14 Dec 2017 13:47:13 +0800 "blubee blubeeme" = said > When you boot into FreeBSD and you can select kernels, there's only 2 > options: > default and kernel=2Eold >=20 > Is there a way to have better output and support multiple kernels without > having to login to the system and running uname -v or something like that= ? >=20 > Would it be possible to add options for more kernels from that boot menu? There sure is! How's your forth? Honestly, it's an extremely simple, yet powerful language=2E All the old Macintoshes used it (think BIOS)=2E You could then simply add as many kernel entries as you felt you needed=2E OTOH You could simply break to the boot loader, and pick any kernel you wanted=2E :-) All of this also assumes you're manually making copies of the kernel(s) your interested in saving=2E As a default install kernel only backs up the previous one -- but you already knew that=2E :-) HTH --Chris From owner-freebsd-current@freebsd.org Thu Dec 14 07:57: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 066C4E9AE25 for ; Thu, 14 Dec 2017 07:57:20 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 D921779675; Thu, 14 Dec 2017 07:57:18 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBE7wl5D070026; Wed, 13 Dec 2017 23:58:53 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: In-Reply-To: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Allan Jude" Subject: Re: kernel names Date: Wed, 13 Dec 2017 23:58:53 -0800 Message-Id: <633b2131f2701fdcc17de870b74de077@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed 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, 14 Dec 2017 07:57:20 -0000 On Thu, 14 Dec 2017 00:51:54 -0500 "Allan Jude" sai= d > On 12/14/2017 00:47, blubee blubeeme wrote: > > When you boot into FreeBSD and you can select kernels, there's only 2 > > options: > > default and kernel=2Eold > >=20 > > Is there a way to have better output and support multiple kernels witho= ut > > having to login to the system and running uname -v or something like th= at? > >=20 > > Would it be possible to add options for more kernels from that boot men= u? > > _______________________________________________ > > freebsd-current@freebsd=2Eorg mailing list > > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eo= rg" > >=20 >=20 > The list is controlled by the /boot/loader=2Econf variable kernels=3D > which defaults to "kernel kernel=2Eold" >=20 > I have a patch almost ready to land that will search all subdirectories > of /boot for a file named 'kernel' and add the names of those > directories to the list, such that the list will basically be autogenerat= ed=2E >=20 > It currently contains too much copy/pasted code, and I just need to > clean it up a bit: https://reviews=2Efreebsd=2Eorg/D11886 >=20 > It was originally designed as part of my contributions towards packaged > base, where pkg will keep the last N (default to 5 I think) kernel > packages you have installed around, incase an upgrade goes bad=2E >=20 > This feature will work on any filesystem supported by the loader=2E >=20 Outstanding, Allan! Well done=2E I eagerly await it's arrival=2E I've often thought about whipping something like this up=2E But something else always seemed to get in the way=2E Thanks, Allan=2E --Chris > --=20 > Allan Jude From owner-freebsd-current@freebsd.org Thu Dec 14 08:16: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 D50DDE9B9CC for ; Thu, 14 Dec 2017 08:16:49 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from mx6-out9.antispamcloud.com (mx6-out9.antispamcloud.com [95.211.2.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84EE279F57 for ; Thu, 14 Dec 2017 08:16:49 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from [153.92.8.106] (helo=srv31.niagahoster.com) by mx26.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ePNxN-0007JI-Fz for freebsd-current@freebsd.org; Thu, 14 Dec 2017 08:29:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sumeritec.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fiJIOneEwbUSw1WEJuohgl9iLQfURcziHoSQ0ZMx+hU=; b=kogTqKdJwRTTF33aQwMl+iMFW/ BetTmFAymUCIoVabI3dbR+tuiWrJa4vsbOx+5xnG3Pg6M+um8EGdR0G2lbDk+m6VP4gfsGA3rjNTe dgp0tNaYS9sGjudBkMGmp7YXDVY/u6tD7F/QVFJm+8gdv7aEWe+9c9dSv4oQPtMeNbvO1ulRFKOvf /b/iAiVMaTyPcdApnuySgV6YYBdRFsG8PC1HJtC4a0qXWQz4YnY8HZKiGYo2fyJZktOc/81CB5kPW Zoz0GvktNGR6eiJ5Lrak/kMqR+sRyHYcjCcjFL/2QCSZaVxehORN4hK8Oo28ye19ym9kNU0Ogj1Sv smUDs20g==; Received: from subs12-223-255-228-88.three.co.id ([223.255.228.88]:28117 helo=X220.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ePNwY-0009MA-Id; Thu, 14 Dec 2017 14:28:34 +0700 Date: Thu, 14 Dec 2017 15:28:32 +0800 From: Erich Dollansky To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: kernel names Message-ID: <20171214152832.52b535a6.freebsd.ed.lists@sumeritec.com> In-Reply-To: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> References: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AuthUser: freebsd.ed.lists@sumeritec.com X-Originating-IP: 153.92.8.106 X-AntiSpamCloud-Domain: out.niagahoster.com X-AntiSpamCloud-Username: niaga Authentication-Results: antispamcloud.com; auth=pass (login) smtp.auth=niaga@out.niagahoster.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5uqY2+aLM/XbTIr1LZe49wIXv9krsgRhBn0ayn6qsUc7x6IOtttBWgPY za5Lun6B7MZ9NiEFz7X+CPcCDaS7lz7GTeieozC56kHupXsZOaDGssoDdp5Vw0BJBgDdip9qfjtV rcXiG3jVvyh9GTF9XU5DYuzvEeD4KUSNOVTDBXT8IRFsicyJMEhQFtD8PLointjahN0MK8ps8x/C 1qhkdZsMkTeZFNNR/WIpfQ2B3lFj1RtWIyKxUSoREjE/7VNQ8fiB2gGa4NbpRZ4pLIy2KmcXRuWz sGtazoE/vPfv1xaxiyi1TFE9uh6dOpTA08b6wDAs69FQbooXBmqDtpFld11brrwCZzWKieIk7R94 5NtYJWc6Hvk2XXh9/cAOBIKwOHz2xktCmqEq1+cTDToG9TPXXZAqrzYNzV3jEETifN/XfJomEqwE svuvXyGt8JcfF1EP5ysm/cbFtsaIamM3d2CAAuzz2dRpmmBV1pWxSApcaIfVaCHpEB6cFH6WJxE4 ZqmNQns4G4Lu1Z0qkp77KGV6tBzjT2SgBpw0u3YvKwGjTic+ruhBJOMhfuxk1oHBSDl4lidU1b80 J2t/rYe9m+T+DoqBsC/uQMsclP8aiBJ2SSzm7P5LFQTh7xAIEq/JAOP/OUUiyoxKCnwuNYv1rN7p +nI9BJabHELBkggad3WQI0XM/3rJu2YIAzVDXCTszSsavtI/BpoTTR0m9vx748g+ePukY31yweyg GiaBPV1Kfqb5R4VemuUI6bcEARsm0ASAg3ACsLVYcMwnzM6V4gQ3iiZtVhbV1vIcdJN0W2QuBIdw bMEc9U7OFQR0XkTUr1ss+n2ffnQxt6aJ7klZab+otuHJEaECIIhJNxMS+c0bF+8gN8ax9LqntRCm aHw627KnGFLUSfQxoCgjbv9bX5I= X-Report-Abuse-To: spam@quarantine1.antispamcloud.com 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, 14 Dec 2017 08:16:49 -0000 Hi, On Thu, 14 Dec 2017 00:51:54 -0500 Allan Jude wrote: > On 12/14/2017 00:47, blubee blubeeme wrote: > > When you boot into FreeBSD and you can select kernels, there's only > > 2 options: > > default and kernel.old > > > > Is there a way to have better output and support multiple kernels > > without having to login to the system and running uname -v or > > something like that? > > > > Would it be possible to add options for more kernels from that boot > > menu? _______________________________________________ > > 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" > > The list is controlled by the /boot/loader.conf variable kernels= > which defaults to "kernel kernel.old" > > I have a patch almost ready to land that will search all > subdirectories of /boot for a file named 'kernel' and add the names > of those directories to the list, such that the list will basically > be autogenerated. > > It currently contains too much copy/pasted code, and I just need to > clean it up a bit: https://reviews.freebsd.org/D11886 > > It was originally designed as part of my contributions towards > packaged base, where pkg will keep the last N (default to 5 I think) > kernel packages you have installed around, incase an upgrade goes bad. > > This feature will work on any filesystem supported by the loader. > this is a cool feature. Testing will become a lot easier then. Erich From owner-freebsd-current@freebsd.org Thu Dec 14 09:23: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 722B7E9DA9E for ; Thu, 14 Dec 2017 09:23:39 +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 E96BD7C2DB; Thu, 14 Dec 2017 09:23:38 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.51.216.133]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LlpJU-1eykYa02Ma-00ZLSg; Thu, 14 Dec 2017 10:23:36 +0100 Date: Thu, 14 Dec 2017 10:22:53 +0100 From: "O. Hartmann" To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: kernel names Message-ID: <20171214102320.4e4ef169@thor.intern.walstatt.dynvpn.de> In-Reply-To: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> References: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.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_/BhYvmmDC3B/b+Om0QHIXkyw"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:9hJ8sAA5L+YxcndTHCAZVGbfmg3giMq3VmCWVTpOeqZD35qJ7K8 aoiodEZ9JCUvBCMVwjp44N6pXWJFEhL1LmRVyN0BFJPCWHs2W9AwLVbmkiqg2S2qN9ZULjm ksqHYtH50nv7ROevEZSEuzU7IDiyRhDbEcyh6RwXBkDlOm+OaS0h6BEf6XwHiEFae1hOyu7 8cHXsAkT2hL3YWwihDipw== X-UI-Out-Filterresults: notjunk:1;V01:K0:fP31z/RPT9I=:xTAgLIWXzY8d10Ih7Sq/8B 0sgg0h3z/Kk7+hsffPjL1zwsUPPVBIawfJJwiMklNhKuh4jhcVoD/2GdK+oebgO3DQUSy8qLu ofV/qQuYc66AoUX26z3SBSx/w5Jy01GOBeg0m8m23Fo1K8OwqVGwsxlV5YBXLzpWtFW2XWu6N EkjA1zF7QyZgmEnDs8Xd/DOqGkIBt0eWErwtFYVHEpC+Yle9VonPHzDO/3CnCBDdkHjNYPRym Yy9YflwmAszOaJkuBgYWmagY2QsdKN73b7ZeAyk+jGt6GqGG2xJOCvLNhq+z6kHAtqNasGczx S0fRpN/bk5XLqTSFh7v5q14ljWi9B0sr+TwJ9o11aP5TTSGlX5Ts4fQXGync0ShdqInbIreMG qp8/oIiOxDpkVY2uYhUDa6jWSQxTvGzcg5VDwaHFjpOd1NeaNiYfqTcIW5CTBYrFiCtOTU3Vo 9Nl4Ymgjbb8+S47orPkRa9gVtkfGNMA+d1qXk6Xkjkqkv3r35Hg/zxIRNGEjTzqIX6PjJUTrT xZiwHI30QYInF2PtnNy03U7RJdcHO6byRxWP8x6nJQwtpqAVqyOIk8kAqWbfIURv8c/9BlB7b MioXhY6BigenJO9dg1ZVp8DBIqSbeQASV64i0peAqoA/VLFxP0Z6c07ll2vhkf80+9VjXtQkY kbDoCDcGF80QMPrIWeP54FBXFoaBhiQCKC2XR+cJ4FwWhpe8eKDzWCKUrpTfSUEcTHS5d42oz ZlRFc+0q5S3XyqtWDNKNmXxL02bIDBOPzHw/MXZ2+i2Cz7/HEfc1kixHbNbspvQotP20NHqHm QYOKcI8bq7sZabkcaCoXQmAGDYMJg== 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, 14 Dec 2017 09:23:39 -0000 --Sig_/BhYvmmDC3B/b+Om0QHIXkyw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Thu, 14 Dec 2017 00:51:54 -0500 Allan Jude schrieb: > On 12/14/2017 00:47, blubee blubeeme wrote: > > When you boot into FreeBSD and you can select kernels, there's only 2 > > options: > > default and kernel.old > >=20 > > Is there a way to have better output and support multiple kernels witho= ut > > having to login to the system and running uname -v or something like th= at? > >=20 > > Would it be possible to add options for more kernels from that boot men= u? > > _______________________________________________ > > 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 > The list is controlled by the /boot/loader.conf variable kernels=3D > which defaults to "kernel kernel.old" >=20 > I have a patch almost ready to land that will search all subdirectories > of /boot for a file named 'kernel' and add the names of those > directories to the list, such that the list will basically be autogenerat= ed. Ahh ... great! I can't await it for your approach to land in CURRENT ;-) Th= anks. Oliver >=20 > It currently contains too much copy/pasted code, and I just need to > clean it up a bit: https://reviews.freebsd.org/D11886 >=20 > It was originally designed as part of my contributions towards packaged > base, where pkg will keep the last N (default to 5 I think) kernel > packages you have installed around, incase an upgrade goes bad. >=20 > This feature will work on any filesystem supported by the loader. >=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_/BhYvmmDC3B/b+Om0QHIXkyw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjJDCAAKCRDS528fyFhY lKCLAgCJQvBFpm+fmREHBjn66Y5aeVspqLzR5KMxn+3P3BjaCBWGPLC0ii6a3rSh SlgfSjk5pv3isTPOG7YcNf1U9EwwAf0Y3ohbdPluZ7b3Z3ZOyoEWW2cVzH6X1xlQ RLITHkTEL8k4fLm6qXL0+7MhjUZk3Si9KUhTpXMj0KmK/RLOQvtK =F/LV -----END PGP SIGNATURE----- --Sig_/BhYvmmDC3B/b+Om0QHIXkyw-- From owner-freebsd-current@freebsd.org Thu Dec 14 11:05: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 29BB7E9FF73 for ; Thu, 14 Dec 2017 11:05:20 +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 E41677EFF6; Thu, 14 Dec 2017 11:05:19 +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 927892E31A; Thu, 14 Dec 2017 12:05:15 +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 48Op80c8slMq; Thu, 14 Dec 2017 12:05:14 +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 5268C2E306; Thu, 14 Dec 2017 12:05:14 +0100 (CET) Subject: Re: SMART: disk problems on RAIDZ1 pool: (ada6:ahcich6:0:0:0): CAMstatus: ATA Status Error To: "Rodney W. Grimes" , "Hartmann, O." Cc: Cy Schubert , "O. Hartmann" , FreeBSD CURRENT , Freddie Cash , Alan Somers References: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> From: Willem Jan Withagen Message-ID: <4d58b06a-0dbe-af05-1bd2-e87929e3b7a5@digiware.nl> Date: Thu, 14 Dec 2017 12:05:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <201712131647.vBDGlrf2092528@pdx.rh.CN85.dnsmgr.net> 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: Thu, 14 Dec 2017 11:05:20 -0000 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 From owner-freebsd-current@freebsd.org Thu Dec 14 11:49: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 98EF7EA0EF4 for ; Thu, 14 Dec 2017 11:49:15 +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 F4105803F9 for ; Thu, 14 Dec 2017 11:49:14 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.51.216.133]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M9s8K-1eIpER0mE4-00B2JZ for ; Thu, 14 Dec 2017 12:49:07 +0100 Date: Thu, 14 Dec 2017 12:48:33 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... Message-ID: <20171214124900.64211bd9@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_/VsbDYHS9F7SJap/dAyzdh_s"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Oh0gCEeW2aKkr18dM7eioemmvdD5kIQjcCsIP28qiGFGa9Z2WXL EOG+5uYBaBZT52bHb+IYUx4inKBsoXr1goEkrl6Gb9InxvfmtMhXiS4iIvZuqlz0QIZzF+X 0Rqt1dN6U+eQgtA0EiREDpvQEYBwO8SZ5Nh+CjkzLZ+TwrhV8BN3eD3wqWQNGQxdFyq2MBX ntZb532OJEhaNArqb86Ug== X-UI-Out-Filterresults: notjunk:1;V01:K0:daV3dJwSULw=:0JjlFCdZ/tB4EhM//csMFa njw6SSk0E2nvUr4J+sVwp5EvY7iCUYVR8/ggjslkZIQ31LJWjYc9bsouz4b0lcKM9oUNTmSIy DrUa9rQ+pB/kZlUJBs0ocJORvnflK2o8RE9dOv8d8e3Yzy8Cfr7qmGHX2oVj2998raYNwcSuM ti39ZcVqq0GByPB6ZKf/o6/yoY0OHpaN74fBJnqJu+GAyqH6TpWGddduZofahg90sjgG7VoEO o23NQhKOBIz+YD9GselI09ZJ797JZN96GcrH/GRG+Ma+j8GlanSxzTt+6+v12vZ9ycqylPXJE H6PPpSWHl2ItojVqjqWPGlQGjMW66oENNd21n30Ff+wXmMCcs+1wXf67uo2u+SRcsbOmBxa3N 3v/pdGB+1tV2GX9rzXf6170OzyQMydscxEb2OfYRIdMdqybrmu7f4KX6eJGS+9CscH5NFZO9y GuyHP52rnnPcOVThEEBsb0YPdOAorbBfXbE195f5KtMj6iw0aPqGEpkRXmxBigZP0tv4mgb98 G8zTLpzuhD2WNIY4xkfN0DhkbEVVTp3WSZN18TpKDzjjUpQtlDGNYjaCEE7YRcsxlbWGayXAw WYzh6h6B2w5F97C4KayRavyM4fejIgN9K0unKl4/yRBBsUA5ooU4X9d5LiZPSbbRR2xf4RJcA jlUgb4ws2pgmD7lPBAl4j9BHUnnejuawUdhZYzmX7H2/1CwmL7uTu22ujFBbromnjE6rC+L3q zZOzEUALSs/hUuCqatA1U2wj4F6nSm2kYhKsTyu8FOfT8rLAB7t73m27+bl0BYYOvB9ttv5fS k6ybm3PnmRZwLfdIsDGKYkt6roB0Q== 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, 14 Dec 2017 11:49:15 -0000 --Sig_/VsbDYHS9F7SJap/dAyzdh_s Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello out there, I had to replace a HDD on a RAIDZ1 pool comprised from 4 HDDs, each 3 TB (n= etto size of the pool is about 8-9 TB, the used amount is reported to be ~ 6TB). I just started the rebuild/resilvering process and watch the pool crwaling = at ~ 18 MB/s. At the moment, there is no load on the array, the host is a IvyBridge XEON = with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to a on-board S= ATA II (300 MB/s max) Intel chip - this just for the record. Recently, I switch on the "sync" attribute on most of the defined pools's z= fs filesystems - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused recentl= y in FreeBSD CURRENT's ZFS - this from a observers perspective only. When scrubbing, I see recently also reduced performance on the pool, so I'm= wondering about the low throughput at the very moment when resilvering is in progress. If the "perspective" of "zpool status" is correct, then I have to wait afte= r two hours for another 100 hours - ~ 4 days? Ups ... I think there is something badly = misconfigured or missing. The pool is not "tuned" in any very sophisticated way, since I trust the ke= rnels ability to scale automatically - if I'm not wrong for amd64 ... Are there any aspects to look at? 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_/VsbDYHS9F7SJap/dAyzdh_s Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjJlLAAKCRDS528fyFhY lOueAf0V9/0DfpjuMjR+Zaqs2P2bkD1/AMsPjDwtOBgp29Dgjl0qOX1Vf7AKFmVj HE82ZqxG/TpMu5zw7M8PhiLnqRYWAf0QzIIQVr7fv4WmTfYRLBsSwBFzrOwZrpli H/nwaAn1ZJV96wrvmCgYoqspbRWw/R2zN9gGCGRUjUhzFlM/bJsH =HMQZ -----END PGP SIGNATURE----- --Sig_/VsbDYHS9F7SJap/dAyzdh_s-- From owner-freebsd-current@freebsd.org Thu Dec 14 12:47: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 B5CAEEA2CE4 for ; Thu, 14 Dec 2017 12:47:17 +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 33A9E28C7 for ; Thu, 14 Dec 2017 12:47:16 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.48.220.8]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MaIw0-1ejCgu0P3g-00Jrxr; Thu, 14 Dec 2017 13:47:00 +0100 Date: Thu, 14 Dec 2017 13:46:25 +0100 From: "O. Hartmann" To: "Chris H" Cc: "Warner Losh" , "FreeBSD Current" Subject: Re: 12-r326622 install won't boot Message-ID: <20171214134652.052afeb1@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <4bf0ab6fe9f034b9ec007f13c72092af@udns.ultimatedns.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_/QOEk59Z45J9Qq07YmK8pd8A"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Q2fGkAZ/OcsZzuOwW7Yfu3PFg3AbMAmeFOFLsRQDy9OXbqO0ORV dPUXKpbTI81MBJu2SLOS9MzupLYY2MMfiJtHOoRLUvVcT9cnxD3qOoTt19hRnP9MxL8Xa8l wIpsM1Al+O3VdPaiokLWf8gqL2BxagJieBcjAocqswKYDt/Zb8gMrixlWmGZtjQn49bUgK+ aUNjJhJVN+rzgF2/imuJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:8t8CWBV3Nqg=:Xa6JHMSHNA3b6tEV6mtlyB emLKgBQRtqYvkvhEphKsZI9T+dNEhnupjHsUs+lCTGemjxD7MVtuWGISgSSsvXf9ei3LQrYf5 8uGrd8GbDcnkIu1isPXMaXoE5BcZtqp2me0IshzHw8BJZNRnitJYFQ57yahhv4bV7VhlgSekY eapFvW/O7Tg9jayTUMCpCIz1ufETx97NZ6LEZEZeT3EBDYvfWm5OJnmC17ERirsNqQ5hVcMR3 pG6Q7febnr2Euh+YjiSvLjhpMiKhfQjWY5IDQwUv9I9yxb6I1Ua/SOB0eJx9IzicfHWShx0TJ oPiU2sO67dEbUrb7hdv1OCqqT0LkYEWDcYj58WYI8De5hbhvYLLUqjrDQfT8a2A+MrF1WXjMw mc/d68KWZawUlefgGaS6X0lpSnhcbl/ogCsgi0lqaogDD8V+GGTYsSpEyN1bNdfrjW67q0dMq iWuKpjj0ElQWDzVQIzhDvlzO26HEF126X/m3iBW9B/Z7vSK4vmxwl81XKdmQDPhWkHqsQXhjg OiSnORoqJNSolJIkYezC7pISnaDvEaN8s9Zr+lpveQqqcNg/MiWQW8I4KFIcB6H83t7MS+gJ+ 953kT/xYRLlJtPmbalw2CN9lm8/EPX6w1m07qnxGcsi1qCBXeSV5MOlHYxhUn7n/++MNqXDC4 2ggvcRe0UZUi5S78LIDYqDt1OkHlap429rb3Eyvm8MWh5qkowr8zMZZU4b2JZn0NxzSUgrkBf qPvZWA+5b6FIfuJ3eyS+c3Q2v1ksCDZ2GzZFZz/8/JOdKN9BKhLmMhOLY8GxzU9heSOhAwoAx VzpWWk7q7pEl+uz/OV6EoKnxqjoIQ== 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, 14 Dec 2017 12:47:17 -0000 --Sig_/QOEk59Z45J9Qq07YmK8pd8A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 12 Dec 2017 15:24:34 -0800 "Chris H" schrieb: > On Tue, 12 Dec 2017 13:56:56 -0800 said >=20 > > On Tue, 12 Dec 2017 14:33:10 -0700 "Warner Losh" said > > =20 > > > On Tue, Dec 12, 2017 at 2:28 PM, Chris H wro= te: > > > =20 > > > > On Tue, 12 Dec 2017 11:37:33 -0800 said > > > > > > > > Hello all, =20 > > > >> I just blew away a old RELENG_11, to start working with current. I > > > >> must admit I had several disappointments regarding the installer. > > > >> But that's for another topic, and another time. > > > >> To the point; > > > >> I completed the install. The only event(s) that might be notable > > > >> during the install. Was early on during (boot?) I saw a "dumped co= re" > > > >> race past on the screen. I also experienced at least 1 LOR. But the > > > >> install continued, seemingly un(interrupted|affected). That said, I > > > >> chose the reboot option after completion. Ejected the DVD during P= OST, > > > >> and I'm stuck at: > > > >> > > > >> BTX loader 1.00 BTX version is 1.02 > > > >>=20 > > > >> > > > >> followed by 2 gibberish characters; 1 appears as a right pointing = arrow, > > > >> the other, kind of like a battlestar galactca spaceship. > > > >> NOTE: those 2 characters did not show up on the initial reboot from > > > >> the install (just the 2 lines above). But after I attempted a hard > > > >> reset after the first fail. > > > >> =20 > > > > OK tried the installation again, and nothings changed. > > > > Still left with the 2 lines listed above. > > > > > > > > Guess I'll have to wait until 12-CURRENT becomes a usable version. > > > > Sigh... > > > > I was really hoping to run 12, so I could better develop 11. > > > > Oh well. Guess I'll grab a copy of 11 off one of the ftp servers, a= nd spin > > > > it > > > > up. > > > > > > > > Thanks anyway! :-) =20 > > >=20 > > >=20 > > >=20 > > > I think a two-week old snapshot would work a lot better if you wanted= to > > > make the jump to -current. I've botched something in my boot loader c= leanup > > > and it's taking a little time to get sorted out... =20 > > OH, thank you *very* much, Warner! > > Whew! Just in time, too. I had almost slipped the 11 DVD into the box. > >=20 > > Thanks again, Warner. Hope the things go well for you. > >=20 > > --Chris =20 > Spot on, Warner! r326056 gave me a working 12-CURRENT. Including all > the LORs. :-) >=20 > Thank you! >=20 [ ... deleted line ...] I have the same here. I just tried on a APU2C4 r326846 and, as I reported i= n another thread earlier, it gives me on a serial console the same: Consoles: internal video/keyboard Nothing more. The last known-good version is r326583. r326584 won't build, the same with = r326586 (bails out with some errors in geli related stuff, I believe) and then the subsequ= ent versions start to fail. I realised the issues on the serial console driven APU with = r326734 and I tried to "bi-sect", unsuccessfully due to lack of time and resources down t= o r326583. Obviously I'm not alone having issues with loader/boot loader and it would = be wise to put out a warning for all the other brave CURRENT testers out ... 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_/QOEk59Z45J9Qq07YmK8pd8A Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjJyvAAKCRDS528fyFhY lBnkAf9KYYZlIlYTWE9eqA2ZhI/Tf+NaoGtwClz5/7qSswLoIIWuQ7ny5sVnoHZZ 4/XeVenidkLd/Q10rLYTXHHO4oMcAf9/uBLb0nDe6HSO6GAQja5jqm5/ErXWFAcD 5I6BXjBhD2DHSetSuO1X7K7kzOc3mkqsv8YN2mmAZVmAQnPwdjUE =ZNSt -----END PGP SIGNATURE----- --Sig_/QOEk59Z45J9Qq07YmK8pd8A-- From owner-freebsd-current@freebsd.org Thu Dec 14 13:09: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 3CAF3EA3810 for ; Thu, 14 Dec 2017 13:09:41 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 EA991365E for ; Thu, 14 Dec 2017 13:09:40 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id b123so6121934qkg.7 for ; Thu, 14 Dec 2017 05:09:40 -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:content-transfer-encoding; bh=s/qlsSOdeAO5goqkCxOA2aCZ9tGYoaGQzBXVAt3IQ/w=; b=gB0Ve7nhEh+tT85IJFVHjBO4ggE/1mSgCnZhQ4TXDjJtRnbX0aPSkHNOInLGcU/kS/ zxsvajErucJAkCpE+XFVPwjBmxGCseDnT47ic6OszVcSpCK5PUvJ/LP7l2Iw6nSuX30U dt5e3dyZiOFxyHwWVFfZNj3kHWS12pJ+926XJCccvyG1AGQb648abu2r6cqs2H9mkD6w 8EQ9+uHemNuqB15lsD8B0lWmk1dA8cy2VUVYDYIQyHcuG00EZKHW3J9CJGtTISSfnbru GlFNqZBM4zOirygwOuJ3//X2j0cwG9sWerdhuMO1u9ZMMglMOBP6tZ0eOmPBSxKj17mp vAqw== 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=s/qlsSOdeAO5goqkCxOA2aCZ9tGYoaGQzBXVAt3IQ/w=; b=Xv24cLbBRqn1qFho8xFsLq3FbSMBHroYEu9WPzdHxXgL4TIEcY8EYAOA7Z5JEISU2a 6KvK2gXxU52DwByf/KL+TlEU6p4D6LIlpCc3QfnGjXtaII18blmy9I0oRTnhP/8VELXT dY2jsDIB/WiWiavcAz3U8erG8UdsRN+ZKqnIybyOUybIH1u7ZHfRH4vf9SvCOr355ilU f5v1z3Bsbv07nKY1yL4aAEwgzxLTARHgRY6IeZBB3yzHFq21iTf2AGqwsFld159zvZZ6 ReDVzySLlrDSpFhb/8TR1eQMnVgc5lfYTTV/iiR0myb87sqt/lt/Rww1FCr44xnPvSG/ gSSQ== X-Gm-Message-State: AKGB3mK0uGGl3FdZaHzGalPzISOVg3nkG2ZwQxOleZcz/NHgfWryZmgj R2rCMre659YHD7gqEQT36nBeBWyLzhJR1mBP8WDjng== X-Google-Smtp-Source: ACJfBov7TjVld/IAyv9gblQV+fUdeSx+oieHATTAWdMtoCdtHd/F9OAatjSivabek/B3wzwKkFnXdmOGt920sPIKwGI= X-Received: by 10.233.220.199 with SMTP id q190mr16362503qkf.72.1513256979878; Thu, 14 Dec 2017 05:09:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.108.9 with HTTP; Thu, 14 Dec 2017 05:09:39 -0800 (PST) In-Reply-To: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> References: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> From: Daniel Nebdal Date: Thu, 14 Dec 2017 14:09:39 +0100 Message-ID: Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.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, 14 Dec 2017 13:09:41 -0000 On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann wrot= e: > Hello out there, > > I had to replace a HDD on a RAIDZ1 pool comprised from 4 HDDs, each 3 TB = (netto size of > the pool is about 8-9 TB, the used amount is reported to be ~ 6TB). > > I just started the rebuild/resilvering process and watch the pool crwalin= g at ~ 18 MB/s. > At the moment, there is no load on the array, the host is a IvyBridge XEO= N with 4 core/8 > threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to a on-board= SATA II (300 > MB/s max) Intel chip - this just for the record. > > Recently, I switch on the "sync" attribute on most of the defined pools's= zfs filesystems > - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused recen= tly in FreeBSD > CURRENT's ZFS - this from a observers perspective only. > > When scrubbing, I see recently also reduced performance on the pool, so I= 'm wondering > about the low throughput at the very moment when resilvering is in progre= ss. > > If the "perspective" of "zpool status" is correct, then I have to wait af= ter two hours > for another 100 hours - ~ 4 days? Ups ... I think there is something badl= y misconfigured > or missing. > > The pool is not "tuned" in any very sophisticated way, since I trust the = kernels ability > to scale automatically - if I'm not wrong for amd64 ... > > Are there any aspects to look at? > > Thanks in advance, > > Oliver > > -- > 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). This is kind of to be expected - for whatever reason, resilvers seem to go super slow at first and then speed up significantly. Just don't ask me how long "at first" is - I'd give it several (more) hours. I don't _think_ sync affects resilver speed (since that's a filesystem level setting and the resilver happens at the block level), but that's pure speculation. The Tuning guide at https://wiki.freebsd.org/ZFSTuningGuide also suggests a list of sysctls you can tweak, which could be worth a try: ### wiki If you're getting horrible performance during a scrub or resilver, the following sysctls can be set: vfs.zfs.scrub_delay=3D0 vfs.zfs.top_maxinflight=3D128 vfs.zfs.resilver_min_time_ms=3D5000 vfs.zfs.resilver_delay=3D0 Setting those sysctls to those values increased my (Shawn Webb's) resilver performance from 7MB/s to 230MB/s. ### --=20 Daniel Nebdal From owner-freebsd-current@freebsd.org Thu Dec 14 13:44: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 1EAAAE8081C for ; Thu, 14 Dec 2017 13:44: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 9396764532 for ; Thu, 14 Dec 2017 13:44:00 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.48.220.8]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0ME33j-1eFNBq19LD-00HNiU; Thu, 14 Dec 2017 14:43:57 +0100 Date: Thu, 14 Dec 2017 14:43:24 +0100 From: "O. Hartmann" To: Daniel Nebdal Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... Message-ID: <20171214144351.24a81faa@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171214124900.64211bd9@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_/a4HkXQOB3xxRloK4i/oe82M"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:v9bZkWyrPl196DjFcNxQOJT8ssGobQIK3/hVTIEG5GvIMzsq55g CpAcY98288F1gUpNGiA8r+abUMeIMGOti0WdWRZLtThrtbqYHDgykg15JJv1QpGEsXY5n+s KhjyVdRsiYLUhmKXic+8vTIGVAp7FZFzMqFL6D3xMhM75eXbtZ2jlQpxyZdwp4JIQN5YkV7 RfJvK/QgIbhZoZ8OO70JA== X-UI-Out-Filterresults: notjunk:1;V01:K0:qEmG3QqU6/U=:BRQ7v7GbEk3xJSZQ6/j6dR xczTKkxDOaMzDei9zIA3bBviW+pzm7ESwRWusOaN8F1AK9l3U/iwCX+uEKo+ov0MpJe7X+7aN RYNslULshJY2odUSL8b8LkAW9UfQu+RzxH2WTRUW1spbIVjC3GC0/Tyr1MSi12+IUcRhARrO+ jaWhdZUT9EFHJwa8O3z7+0pLo9Pqhe1rAAHc2G86YUDME0fZdEYqiG0KuYvvojzeZm5IURpmG lJHfn0zosajvZTCCNDBr3TZ+qkVWU6PpCKRrTLfeDiquoqaElMV/iGj5g3GunvaTDN2LuI8Jy pnSdF+aya3FfKB773Gtpi2CQh2LbNvbZGKl5Fg7e8+TO0AMIsKWqS9Ewh7XyNwIf5Vhz9VUKl A0dZY5BTLT05PZBPFYmbCQh0dG2Pj7ZYyvzzmLShrIfXisGsD7hVpkmuOjzXFf4JLxI5leFDm ztxXSbENAYWy+UlbZ5fFQDfIY6uOZcIa2UuNuczH5WDrv5TOUYFcG7RqlI04Tqc8zSU2nVFy2 lPUwSwh2F0VHl20KLOT5rdPGqj8hLeMm2MmxQthd6nMhTN6N1OrM5vO3r5HeAvDPqZZCQYqfC wzbokq7SUu8YwKwJa4HkYh4DO9OAXAhgx8yovwhg9ykts9OTPEF0Kh3rbbTaNIdDBnLw/e1TJ cKB1qkYBT5d5+r1noIb9lchu/8T6ixJtFb/Nuaqfsj9adrBz/fRdZnrX93W83vEX7wFFzZYAb SRL54/Ioys8055CmJthvmDSwB4GryexMSZKMDTo1Ufr1WE4nOx1runC58nlV2chH6YCqA4uL/ DduSlx29/FQ/8fmJ10jC6XCzSo/wA== 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, 14 Dec 2017 13:44:01 -0000 --Sig_/a4HkXQOB3xxRloK4i/oe82M Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Thu, 14 Dec 2017 14:09:39 +0100 Daniel Nebdal schrieb: > On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann wr= ote: > > Hello out there, > > > > I had to replace a HDD on a RAIDZ1 pool comprised from 4 HDDs, each 3 T= B (netto size > > of the pool is about 8-9 TB, the used amount is reported to be ~ 6TB). > > > > I just started the rebuild/resilvering process and watch the pool crwal= ing at ~ 18 > > MB/s. At the moment, there is no load on the array, the host is a IvyBr= idge XEON with > > 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to= a on-board > > SATA II (300 MB/s max) Intel chip - this just for the record. > > > > Recently, I switch on the "sync" attribute on most of the defined pools= 's zfs > > filesystems > > - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused rec= ently in > > FreeBSD CURRENT's ZFS - this from a observers perspective only. > > > > When scrubbing, I see recently also reduced performance on the pool, so= I'm wondering > > about the low throughput at the very moment when resilvering is in prog= ress. > > > > If the "perspective" of "zpool status" is correct, then I have to wait = after two hours > > for another 100 hours - ~ 4 days? Ups ... I think there is something ba= dly > > misconfigured or missing. > > > > The pool is not "tuned" in any very sophisticated way, since I trust th= e kernels > > ability to scale automatically - if I'm not wrong for amd64 ... > > > > Are there any aspects to look at? > > > > Thanks in advance, > > > > Oliver > > > > -- > > 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). =20 >=20 >=20 > This is kind of to be expected - for whatever reason, resilvers seem > to go super slow at first and then speed up significantly. Just don't > ask me how long "at first" is - I'd give it several (more) hours. > I don't _think_ sync affects resilver speed (since that's a filesystem > level setting and the resilver happens at the block level), but that's > pure speculation. > The Tuning guide at https://wiki.freebsd.org/ZFSTuningGuide also > suggests a list of sysctls you can tweak, which could be worth a try: >=20 > ### wiki > If you're getting horrible performance during a scrub or resilver, the > following sysctls can be set: >=20 > vfs.zfs.scrub_delay=3D0 > vfs.zfs.top_maxinflight=3D128 > vfs.zfs.resilver_min_time_ms=3D5000 > vfs.zfs.resilver_delay=3D0 >=20 > Setting those sysctls to those values increased my (Shawn Webb's) > resilver performance from 7MB/s to 230MB/s. > ### >=20 >=20 >=20 I had already set those tuning parameters, shortly after I sent the mail to= the list, but there wasn't any sign of increasing performance since then. Now, after roughly 4 hours of running resilvering, it seems that the speed/= throughput is increasing: from initially 12 - 17 MB/s its now at ~ 90 MBytes/s - sounds m= ore promising. I remember that I whitnessed this also when I checked the last time scrubbi= ng: a non linear gradient in throughput while time shifts forward ... So, everything seems to be all right ... 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_/a4HkXQOB3xxRloK4i/oe82M Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjKAFwAKCRDS528fyFhY lKbnAf9kPSkE5QQPzBcIJIRC+CCQbf4Sggo8Te4DkufQR4z70UqaWlDGYZ+Rg1QE Pe9Xdfw2BUSuzYcKf2t1Kn8HjDDtAf9UubfzRat+MI96OqkwT4fmuDxfa3DIxURW xry6hFJ6/cKmSsrw0T//PYv9HoWofvVc/OUe+DplawUpwSjbdusB =6mYM -----END PGP SIGNATURE----- --Sig_/a4HkXQOB3xxRloK4i/oe82M-- From owner-freebsd-current@freebsd.org Thu Dec 14 14: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 50F88E82D5C for ; Thu, 14 Dec 2017 14:46:58 +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 0C90766E57 for ; Thu, 14 Dec 2017 14:46:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (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 CD94DDC24; Thu, 14 Dec 2017 15:46:16 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0B389644-E165-49B5-B164-D2414AC648AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... Date: Thu, 14 Dec 2017 15:46:17 +0100 In-Reply-To: <20171214144351.24a81faa@thor.intern.walstatt.dynvpn.de> Cc: Daniel Nebdal , FreeBSD CURRENT To: "O. Hartmann" References: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> <20171214144351.24a81faa@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: Thu, 14 Dec 2017 14:46:58 -0000 --Apple-Mail=_0B389644-E165-49B5-B164-D2414AC648AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Dec 2017, at 14:43, O. Hartmann wrote: >=20 > Am Thu, 14 Dec 2017 14:09:39 +0100 > Daniel Nebdal schrieb: >> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann = wrote: >>> I just started the rebuild/resilvering process and watch the pool = crwaling at ~ 18 >>> MB/s. At the moment, there is no load on the array, the host is a = IvyBridge XEON with >>> 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached = to a on-board >>> SATA II (300 MB/s max) Intel chip - this just for the record. >>>=20 >>> Recently, I switch on the "sync" attribute on most of the defined = pools's zfs >>> filesystems >>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused = recently in >>> FreeBSD CURRENT's ZFS - this from a observers perspective only. >>>=20 >>> When scrubbing, I see recently also reduced performance on the pool, = so I'm wondering >>> about the low throughput at the very moment when resilvering is in = progress. >>>=20 >>> If the "perspective" of "zpool status" is correct, then I have to = wait after two hours >>> for another 100 hours - ~ 4 days? Ups ... I think there is something = badly >>> misconfigured or missing. ... >> This is kind of to be expected - for whatever reason, resilvers seem >> to go super slow at first and then speed up significantly. Just don't >> ask me how long "at first" is - I'd give it several (more) hours. Hopefully this will get better in the future, please read: http://open-zfs.org/wiki/Scrub/Resilver_Performance -Dimitry --Apple-Mail=_0B389644-E165-49B5-B164-D2414AC648AA 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWjKOuQAKCRCwXqMKLiCW o4v2AJ4gJHlALMaEYIrmfkOEuLLTT9napACgy7miWUltzHHT7tor9utycJLTb2w= =cokX -----END PGP SIGNATURE----- --Apple-Mail=_0B389644-E165-49B5-B164-D2414AC648AA-- From owner-freebsd-current@freebsd.org Thu Dec 14 14:53: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 05918E8326B for ; Thu, 14 Dec 2017 14:53:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7C60B6766D; Thu, 14 Dec 2017 14:53:09 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.48.220.8]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwaMR-1f65I20H79-018NuT; Thu, 14 Dec 2017 15:53:01 +0100 Date: Thu, 14 Dec 2017 15:52:27 +0100 From: "O. Hartmann" To: Dimitry Andric Cc: "O. Hartmann" , Daniel Nebdal , FreeBSD CURRENT Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... Message-ID: <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> <20171214144351.24a81faa@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_/hyN6twzUHfYMOSMxkitjlQ_"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Ab+suqM924IoWVld3mpkOV5wu9tftOmpcO9Gi9+xbMKBXeAUzLb MPKA5EBYNTmM2c2THx1puHWTFsQYJy3ESOdZeOw+QpSKfFI/HGbO6c1IImr7xAaB5CvDx5E 0QknE/P6B9d78FV/J/7TlMMrwk2x1L8/pLpgx5pYJBQMFvEZZPkUva6WMFQUqTyVO9t+1jH KhlaLGktdg3eXEUD/kySg== X-UI-Out-Filterresults: notjunk:1;V01:K0:EmUVKKZv2Js=:5klgAcOt8/fSm5B6wfTmtv KDmHIh8rdf94wJkVdZ2KvPBaJfRDoh5VpM+ivzpSVEGUMYnq2/CkFQJESVTr+FO5hURwIQO1/ yWMH32JsWzRdaTRfwymue0VIvOY1z14EMz32/3y6RwezIs+shPZ5hhp8yNiFW+khc2/Pryu/O G2HmsDUvrVL8K0k2FYvNbL44haPEJ6unOhsiy8OJn8RslqDd68b5GOvzSSmf8rRm105tKJiSY OorTMA0cktY/znyHSV2BbsdP1YroJT11fL1Ytzdmx01Hq7HW60Sm3b+VSRqckSq9YG8ewUsXn 5Q5tDOTop0pI25KZaDXzkDW33C0Ln0DOEaCP9s/Ux9kySbf5WsiAhBsHjHCiy7f2i1VY45QHi Dh2sSXQoYcLM7vUJAV2jp6xmtF7UbmtXcTK6oxt0uZy4wHLq0Q+D4WGyN9H55gYcOXjz52ZRf 1LFh+JoBbzcB+j7a3TyQB0Xg6Yz8dbSrsYIDvkhEfYqfouvz8YpRY+3L64qk6HgD2ga/rVXW2 oL/pMCZGSIQEPBfVZX75qMX8gEJn368nL+fT67RN5DtKPlvSp4xBEbUE+hg/0/gJbiNzhw6pm R/atHFLrKSHurJfS8Ud8JBadMZ+ciXDW2FopQ1WW7dihl3WRtmMzYZ52pfus4svqUkoy/+beu 4c69Azx6/4ttj0AbCLE14Yk4In1r4siCmD8P5EAFUZW8tZgtu//iPifqALTseoki+7hg53qbb 3OZT2Pb6j1fO9mxFZyEGVv51qCM6OgXI/rSLmlgli82k307dZ0Mybv7lriuwQx3vbO/O8eYr1 DUpVG47Z4e0TS1JL22Lfg1JlMGafQ== 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, 14 Dec 2017 14:53:11 -0000 --Sig_/hyN6twzUHfYMOSMxkitjlQ_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Thu, 14 Dec 2017 15:46:17 +0100 Dimitry Andric schrieb: > On 14 Dec 2017, at 14:43, O. Hartmann wrote: > >=20 > > Am Thu, 14 Dec 2017 14:09:39 +0100 > > Daniel Nebdal schrieb: =20 > >> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann = wrote: =20 > >>> I just started the rebuild/resilvering process and watch the pool crw= aling at ~ 18 > >>> MB/s. At the moment, there is no load on the array, the host is a Ivy= Bridge XEON > >>> with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are atta= ched to a > >>> on-board SATA II (300 MB/s max) Intel chip - this just for the record. > >>>=20 > >>> Recently, I switch on the "sync" attribute on most of the defined poo= ls's zfs > >>> filesystems > >>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused r= ecently in > >>> FreeBSD CURRENT's ZFS - this from a observers perspective only. > >>>=20 > >>> When scrubbing, I see recently also reduced performance on the pool, = so I'm > >>> wondering about the low throughput at the very moment when resilverin= g is in > >>> progress. > >>>=20 > >>> If the "perspective" of "zpool status" is correct, then I have to wai= t after two > >>> hours for another 100 hours - ~ 4 days? Ups ... I think there is some= thing badly > >>> misconfigured or missing. =20 > ... > >> This is kind of to be expected - for whatever reason, resilvers seem > >> to go super slow at first and then speed up significantly. Just don't > >> ask me how long "at first" is - I'd give it several (more) hours. =20 >=20 > Hopefully this will get better in the future, please read: >=20 > http://open-zfs.org/wiki/Scrub/Resilver_Performance >=20 > -Dimitry >=20 It has already been started to become better ;-) After a while now, the throughput is at 128 MBytes/s and the estimated time= decreased to ~ 8 h now - that is much more appreciable than 4 days ;-) 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_/hyN6twzUHfYMOSMxkitjlQ_ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWjKQRgAKCRDS528fyFhY lOuBAgCgcbPikxGm+GdgGbMMdcsdrfuJdmrSheWxSPX5GdkinEQcPaaU4RPGMU1i duPVxun6h2CZOiTdfNEvqHYT8G7KAgCqY598Sbqk+5gXsoRVM9whewSbplC9MEF4 O9+2zS9fNUM9Ky8LryHsQKw/LlpJrzXBPhRBc8dRcl63IQDZE32D =XJAm -----END PGP SIGNATURE----- --Sig_/hyN6twzUHfYMOSMxkitjlQ_-- From owner-freebsd-current@freebsd.org Thu Dec 14 15:28:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D6C2E83F74 for ; Thu, 14 Dec 2017 15:28:10 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 1060B687AC; Thu, 14 Dec 2017 15:28:10 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id d137so11940600itc.2; Thu, 14 Dec 2017 07:28:10 -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=gq3L/IY0ReiDeImXhNdCxyXgVcL11/hv3Wfuv8Sjepk=; b=uIZoJm7VT3M+eOjsDRLOn+ZwZ5y7rs2CzHrYzCTf3iNeXu6YsuATwrgGJnSsShpAfs D7RlyimbwJ3u8pzJIzwrfYZLLBmzcTYf8mmGcPpQ9MMUGqJGM7Rt8PdaoQImf4zXuT6j M+GcQ6vA1K58zZnse+lbRm6WN1k3qpNX0YvUEd5BVoZy5HxG3g4FzR6LPJIkGZqJEW4C OWOO6kZ2SKDyIi8RzmEPsHjVqj7g6kooRR02H+Pu/aO7XPIFNii2DntZmoe5jtlpcSmJ +oddsBNYa7FGCc+2yOiMcxoFNPmZGgtbBhQJLpQhEk2wRm+cKMePdjW2q28ONgAxTcHv 9kjg== 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=gq3L/IY0ReiDeImXhNdCxyXgVcL11/hv3Wfuv8Sjepk=; b=d3DEz07ciCsP1tpOa4lnmm4rlZo/TUyWBGCvtncQ1ZLJmIQ/s0qjY1HPD+JkpWA6/h GB4qQNVrvmov1Voa1fsK8uCDEQ7+FVFjNP7F66Ft6TWBpc9tZkpxGbSgQt6W6K/79DTZ envS/r2WRusvXTucQ/e001WzotCewVdmHKYU5ErEmrgQVSf4TsCQFzNadX/E6/Fhl8kT 4QFwMJJPWPwr3BbBk+Q9/kxlHRHXZTNkKJbvKMae3xPJ9AoNNG8IOx9lrwn3W18QieeZ w3JfydJAN5c12OPT7gosoDjO1ojc7IcE6T2JoyE2g0W9EIeGLs/Gd0gO0y3G4z9KfI7q g4Ww== X-Gm-Message-State: AKGB3mLfm1cVi6Ha/7DH1+yhIMjvVIqFr0vS/mEk/pa5V2fDmm2uP5SO A+51JKBynYWoFQJp9ffN9RzfFB3fn6Q45+Voc4g= X-Google-Smtp-Source: ACJfBouL3I2Xf/gHFfugbyzi0Nv2xskmPPGzbnoQHgN9wlB9H59yel2oVGHq2pkw9JiSVi2CYRrQ++5EEfIzqEQykjU= X-Received: by 10.107.112.26 with SMTP id l26mr7596372ioc.230.1513265289250; Thu, 14 Dec 2017 07:28:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.138.114 with HTTP; Thu, 14 Dec 2017 07:28:08 -0800 (PST) In-Reply-To: <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> References: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> <20171214144351.24a81faa@thor.intern.walstatt.dynvpn.de> <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> From: Adam Vande More Date: Thu, 14 Dec 2017 09:28:08 -0600 Message-ID: Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... To: "O. Hartmann" Cc: Dimitry Andric , Daniel Nebdal , 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: Thu, 14 Dec 2017 15:28:10 -0000 On Thu, Dec 14, 2017 at 8:52 AM, O. Hartmann wrote: > Am Thu, 14 Dec 2017 15:46:17 +0100 > Dimitry Andric schrieb: > > > On 14 Dec 2017, at 14:43, O. Hartmann wrote: > > > > > > Am Thu, 14 Dec 2017 14:09:39 +0100 > > > Daniel Nebdal schrieb: > > >> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann > wrote: > > >>> I just started the rebuild/resilvering process and watch the pool > crwaling at ~ 18 > > >>> MB/s. At the moment, there is no load on the array, the host is a > IvyBridge XEON > > >>> with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are > attached to a > > >>> on-board SATA II (300 MB/s max) Intel chip - this just for the > record. > > >>> > > >>> Recently, I switch on the "sync" attribute on most of the defined > pools's zfs > > >>> filesystems > > >>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused > recently in > > >>> FreeBSD CURRENT's ZFS - this from a observers perspective only. > > >>> > > >>> When scrubbing, I see recently also reduced performance on the pool, > so I'm > > >>> wondering about the low throughput at the very moment when > resilvering is in > > >>> progress. > > >>> > > >>> If the "perspective" of "zpool status" is correct, then I have to > wait after two > > >>> hours for another 100 hours - ~ 4 days? Ups ... I think there is > something badly > > >>> misconfigured or missing. > > ... > > >> This is kind of to be expected - for whatever reason, resilvers seem > > >> to go super slow at first and then speed up significantly. Just don't > > >> ask me how long "at first" is - I'd give it several (more) hours. > > > > Hopefully this will get better in the future, please read: > > > > http://open-zfs.org/wiki/Scrub/Resilver_Performance > > > > -Dimitry > > > > It has already been started to become better ;-) > > After a while now, the throughput is at 128 MBytes/s and the estimated > time decreased to > ~ 8 h now - that is much more appreciable than 4 days ;-) > If you are viewing the rate with zpool status, I don't think that is a close to realtime rate. I don't know of a way to check that either. -- Adam From owner-freebsd-current@freebsd.org Thu Dec 14 15:35:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C350FE8441B for ; Thu, 14 Dec 2017 15:35:19 +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 9A4AB68DB1 for ; Thu, 14 Dec 2017 15:35:19 +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 B6C6A14AC1 for ; Thu, 14 Dec 2017 15:35:17 +0000 (UTC) Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... To: freebsd-current@freebsd.org References: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> <20171214144351.24a81faa@thor.intern.walstatt.dynvpn.de> <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> From: Allan Jude Message-ID: Date: Thu, 14 Dec 2017 10:35:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UW0wOunc2jpg5Ln7xrlefCBUM5FSFqNnf" 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, 14 Dec 2017 15:35:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UW0wOunc2jpg5Ln7xrlefCBUM5FSFqNnf Content-Type: multipart/mixed; boundary="ECtoMPAcH8o2t9S21tcRHMfvbn84vVfXx"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ... References: <20171214124900.64211bd9@thor.intern.walstatt.dynvpn.de> <20171214144351.24a81faa@thor.intern.walstatt.dynvpn.de> <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20171214155254.4736ebe5@thor.intern.walstatt.dynvpn.de> --ECtoMPAcH8o2t9S21tcRHMfvbn84vVfXx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-12-14 09:52, O. Hartmann wrote: > Am Thu, 14 Dec 2017 15:46:17 +0100 > Dimitry Andric schrieb: >=20 >> On 14 Dec 2017, at 14:43, O. Hartmann wrote: >>> >>> Am Thu, 14 Dec 2017 14:09:39 +0100 >>> Daniel Nebdal schrieb: =20 >>>> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann wrote: =20 >>>>> I just started the rebuild/resilvering process and watch the pool c= rwaling at ~ 18 >>>>> MB/s. At the moment, there is no load on the array, the host is a I= vyBridge XEON >>>>> with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are at= tached to a >>>>> on-board SATA II (300 MB/s max) Intel chip - this just for the reco= rd. >>>>> >>>>> Recently, I switch on the "sync" attribute on most of the defined p= ools's zfs >>>>> filesystems >>>>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused= recently in >>>>> FreeBSD CURRENT's ZFS - this from a observers perspective only. >>>>> >>>>> When scrubbing, I see recently also reduced performance on the pool= , so I'm >>>>> wondering about the low throughput at the very moment when resilver= ing is in >>>>> progress. >>>>> >>>>> If the "perspective" of "zpool status" is correct, then I have to w= ait after two >>>>> hours for another 100 hours - ~ 4 days? Ups ... I think there is so= mething badly >>>>> misconfigured or missing. =20 >> ... >>>> This is kind of to be expected - for whatever reason, resilvers seem= >>>> to go super slow at first and then speed up significantly. Just don'= t >>>> ask me how long "at first" is - I'd give it several (more) hours. =20 >> >> Hopefully this will get better in the future, please read: >> >> http://open-zfs.org/wiki/Scrub/Resilver_Performance >> >> -Dimitry >> >=20 > It has already been started to become better ;-) >=20 > After a while now, the throughput is at 128 MBytes/s and the estimated = time decreased to > ~ 8 h now - that is much more appreciable than 4 days ;-) >=20 > Kind regards, > Oliver >=20 >=20 The time estimate is a pure average over the entire length of the scrub or resilver operation. The very start of the operation is quite slow, because it involves a lot of random seeks, and the read-ahead is not very smart (patches are in progress). And yes, after you adjust the resilver_delay, it will take time for its impact to be visible in 'zpool status'. At times, you are better off looking at 'gstat', to see how busy the disks actually are. You will likely notice the bottleneck is IOPS, you will be at the limit of at least one the entire duration of the resilver, unless your resilver_delay is high enough to leave some available IOPS. --=20 Allan Jude --ECtoMPAcH8o2t9S21tcRHMfvbn84vVfXx-- --UW0wOunc2jpg5Ln7xrlefCBUM5FSFqNnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJaMpo1AAoJEBmVNT4SmAt+pC0QAIiNDb3StSEJmZKi7e3bghQ1 BJfJCq/viywF5jQ4rggY4gvVEQhWPkejAff/yFxJRc6Nc1wQ35Rc/tosQW96QuSK Cg/8hOKsSaTmB+0l2dq5dnp77kQ4L54lepxaawvIaVFErJRjhYs7ZgVrNG0i3wYk pTjFGrdC+Wpg+X20yI555I+17ep9TRTY0HZEjUnGjZTElf1hrXfy8HiYnax51qk/ 6WFLa9AIK+ZhfRRKEi1gf2sS7k0U0WZiJJHf0ObiEt1jWybGk556YneD+w1SuGI5 kAQ33pL7+zYKn74DO9DiBZ9eUnfCqSuNJIj00ITneY+Aek6e/nJNAimzoVcIFW6j KCQWzZ8T33BQwSdCAdeJetPkDFWL/CHtz3phRMjls3/30o66xr5nNNLEuz3Sl7Rn 98ssr6vtvD2mKbFT/MjLd/Zlz6znM2Of6SMVsw+wLeULpjZmr4APRZFq61o8tTdF lbk67PJE5HO4mtldz/5plG+80vASJSjSu3Tidsgl3l4iPTebpYKQiDVks8T0BY+1 rbHPvm2JRH0mSrxLQlBLI+V66m9npWyBZkrV/YyzcXymZHLEp3b9MTCKesH+jVv/ uulfc84CzDajwaCn0ibLr6QrnA49me6Ri06PXh8rDGoECxGwDC4q1303k3XvIEvV ei3O3CinMTTUrOp/RESi =4yon -----END PGP SIGNATURE----- --UW0wOunc2jpg5Ln7xrlefCBUM5FSFqNnf-- From owner-freebsd-current@freebsd.org Thu Dec 14 16:24:28 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 92358E85B9A for ; Thu, 14 Dec 2017 16:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EC436AFE9 for ; Thu, 14 Dec 2017 16:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id r6so12361790itr.3 for ; Thu, 14 Dec 2017 08:24:28 -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=FBz+CUxLX4JKlrDDd9jR/6F//2LdHtJn684UtS3e4e4=; b=GAyfW/Y+JgBij7JQey4nr/xTz8+UVF+D27R3bfBXUKs75Gse/jFs9R5mgnt9DT3eUi tD0jDNX+XsMKwgCtGH4Bc2TdXVrvzeZd9IvW1YWxGENnxe3GrGpnpzeEOh9jJdwfoMSh XZP2YBejSHyx1pqeGJSdWFiWOjNiRzDqaJS3QRGCWcwMPahZpGH/nRphYdUn95xx++0s u1xEGsgZykdZ8HGmk9B8yOG1coulCf364zm06EnQ9vNPuLaA19QJrbZMfc1n7Kl9UUzi 3xN0Qy6BkbNvSG9fo0l7Xhyjm/g5Wdpls6EEAVmSnPNkKlV5AyIq86fcWVYJR8YTjLrc pLOA== 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=FBz+CUxLX4JKlrDDd9jR/6F//2LdHtJn684UtS3e4e4=; b=Q30iratKhFAEO2cG7wUTpHDirh4nuF27dw07nviSkZZ7nKY11unQeLfOr3bjppzFgE gIa+7z6b5R4BIK+4905Cqqb29/YDLMVZRu/tlc1Yv/O5xdp5ZITjLD1JvcnrMGhi1lHr qPBapfCwdwy5GINqhTMzgpQMVFoMBWPGVIDWVFXB71EqDo8Lt1rg1eFkUf3C1lpiauvX UFfupSRpvKMMtziafpLV/hMXfIRxVIvrZ8TQhDGPPOMtjwbX21CYpursWdffnuNWfuZq ikfwLzknm16Ox8sGRjg81ipJQn48nkYpxSEKUb9hM+O2RdDC/q6cImHyAOGCKe7H8E0S ujDA== X-Gm-Message-State: AKGB3mJHKpm5uzoDrRSrJTzfEqVdEEBHgTvd644622gtPfJAeLaNoTss 0Bj3mM3FcIAH8tiyBC3639sieR5f/ItHRdwCjJViNA== X-Google-Smtp-Source: ACJfBoubR/TUlc1aIQERMDT8um9tXE8D/ZUqFoU+BAZzY+DyXpmLcQV4wnhAsDFEp9XrAvv97ugbnL/7hl+TnNnBX9Y= X-Received: by 10.107.30.81 with SMTP id e78mr7621060ioe.130.1513268667339; Thu, 14 Dec 2017 08:24:27 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Thu, 14 Dec 2017 08:24:26 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171214134652.052afeb1@thor.intern.walstatt.dynvpn.de> References: <4bf0ab6fe9f034b9ec007f13c72092af@udns.ultimatedns.net> <20171214134652.052afeb1@thor.intern.walstatt.dynvpn.de> From: Warner Losh Date: Thu, 14 Dec 2017 16:24:26 +0000 X-Google-Sender-Auth: UXHEBeJa7VPoJlxjyWfyvp3_Dxs Message-ID: Subject: Re: 12-r326622 install won't boot To: "O. Hartmann" Cc: Chris H , 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: Thu, 14 Dec 2017 16:24:28 -0000 On Thu, Dec 14, 2017 at 12:46 PM, O. Hartmann wrote: > Am Tue, 12 Dec 2017 15:24:34 -0800 > "Chris H" schrieb: > > > On Tue, 12 Dec 2017 13:56:56 -0800 said > > > > > On Tue, 12 Dec 2017 14:33:10 -0700 "Warner Losh" said > > > > > > > On Tue, Dec 12, 2017 at 2:28 PM, Chris H > wrote: > > > > > > > > > On Tue, 12 Dec 2017 11:37:33 -0800 said > > > > > > > > > > Hello all, > > > > >> I just blew away a old RELENG_11, to start working with current. I > > > > >> must admit I had several disappointments regarding the installer. > > > > >> But that's for another topic, and another time. > > > > >> To the point; > > > > >> I completed the install. The only event(s) that might be notable > > > > >> during the install. Was early on during (boot?) I saw a "dumped > core" > > > > >> race past on the screen. I also experienced at least 1 LOR. But > the > > > > >> install continued, seemingly un(interrupted|affected). That said, > I > > > > >> chose the reboot option after completion. Ejected the DVD during > POST, > > > > >> and I'm stuck at: > > > > >> > > > > >> BTX loader 1.00 BTX version is 1.02 > > > > >> > > > > > > >> > > > > >> followed by 2 gibberish characters; 1 appears as a right pointing > arrow, > > > > >> the other, kind of like a battlestar galactca spaceship. > > > > >> NOTE: those 2 characters did not show up on the initial reboot > from > > > > >> the install (just the 2 lines above). But after I attempted a hard > > > > >> reset after the first fail. > > > > >> > > > > > OK tried the installation again, and nothings changed. > > > > > Still left with the 2 lines listed above. > > > > > > > > > > Guess I'll have to wait until 12-CURRENT becomes a usable version. > > > > > Sigh... > > > > > I was really hoping to run 12, so I could better develop 11. > > > > > Oh well. Guess I'll grab a copy of 11 off one of the ftp servers, > and spin > > > > > it > > > > > up. > > > > > > > > > > Thanks anyway! :-) > > > > > > > > > > > > > > > > I think a two-week old snapshot would work a lot better if you > wanted to > > > > make the jump to -current. I've botched something in my boot loader > cleanup > > > > and it's taking a little time to get sorted out... > > > OH, thank you *very* much, Warner! > > > Whew! Just in time, too. I had almost slipped the 11 DVD into the box. > > > > > > Thanks again, Warner. Hope the things go well for you. > > > > > > --Chris > > Spot on, Warner! r326056 gave me a working 12-CURRENT. Including all > > the LORs. :-) > > > > Thank you! > > > [ ... deleted line ...] > > I have the same here. I just tried on a APU2C4 r326846 and, as I reported > in another > thread earlier, it gives me on a serial console the same: > > Consoles: internal video/keyboard > Nothing more. > > The last known-good version is r326583. r326584 won't build, the same with > r326586 (bails > out with some errors in geli related stuff, I believe) and then the > subsequent versions > start to fail. I realised the issues on the serial console driven APU with > r326734 and I > tried to "bi-sect", unsuccessfully due to lack of time and resources down > to r326583. > The problem is with r326593. If you hack r326584 to build right then roll forward, you'll get md5 identical .o's until 93. I'm investigating. > Obviously I'm not alone having issues with loader/boot loader and it would > be wise to put > out a warning for all the other brave CURRENT testers out ... > That's a good idea. Warner From owner-freebsd-current@freebsd.org Thu Dec 14 16:39: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 4CA85E86806; Thu, 14 Dec 2017 16:39:29 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 16BB06BCB6; Thu, 14 Dec 2017 16:39:28 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vBEGdQ1T068839; Thu, 14 Dec 2017 16:39:27 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vBEGdQYx068838; Thu, 14 Dec 2017 16:39:26 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712141639.vBEGdQYx068838@donotpassgo.dyslexicfish.net> Date: Thu, 14 Dec 2017 16:39:26 +0000 Organization: Dyslexic Fish To: asomers@freebsd.org Cc: jamie@catflap.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, by@meetlost.com Subject: Re: Strange behavior about pattern matching on manual pages [FIXED] References: <620CD9B7-201A-46FD-8C9D-DD8DDA3A05C3@meetlost.com> <201712062204.vB6M4B03026339@donotpassgo.dyslexicfish.net> <201712062235.vB6MZlQv034650@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Thu, 14 Dec 2017 16:39:27 +0000 (GMT) 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, 14 Dec 2017 16:39:29 -0000 Alan Somers wrote: > > Yes, it certainly is. Are you sure this is actually a bug in less, or is > > it just weird-but-intended behavior when less is emulating some old version > > of more? It would be worth comparing our less sources to upstream's to see > > what differences have crept in, and svn blaming them to see why. Firstly, apologies for the delay in replying - I've been away. I was planning on investigating further, which is why I hadn't yet formally submitted it. Your info would have been a useful next step to follow, so cheers. > I finally traced down the origin of this weird behavior. It dates from > FreeBSD r60816, which imported NetBSD's r1.6 (from CVS), which fixed NetBSD > PR 227. While your patch fixes the problem by@meetlost.com reported, it > regresses the problem described by PR 227. So I don't think we can commit > it as-is. Thanks for doing that. Of course, it's fine to not apply the patch as in this case. > http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/less/less/Attic/forwback.c.diff?r1=1.5&r2=1.6&only_with_tag=MAIN&f=h > https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=227 > > For reference, I'll restate a reproduction case for PR 227: > 1) Size your terminal to 25 lines > 2) jot 20 > ~/tmp/20lines.txt > 3) jot 100 120 1 > /tmp/20lines.2.txt > 4) more /tmp/20lines.* > 5) At the prompt, press spacebar to display the second file. The first > file should remain in the scrollback buffer. Thanks again. I'll check the PR's, other patches, and your test-case will help greatly. I'll post again when I find a better overall solution. Cheers! Jamie From owner-freebsd-current@freebsd.org Thu Dec 14 16:50:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E0CDE87079 for ; Thu, 14 Dec 2017 16:50:05 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (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 1BFE96C877; Thu, 14 Dec 2017 16:50:05 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id vBEGo3iO071390; Thu, 14 Dec 2017 16:50:03 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id vBEGo3lm071389; Thu, 14 Dec 2017 16:50:03 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201712141650.vBEGo3lm071389@donotpassgo.dyslexicfish.net> Date: Thu, 14 Dec 2017 16:50:03 +0000 Organization: Dyslexic Fish To: freebsd-current@freebsd.org, asomers@freebsd.org Cc: jamie@catflap.org, by@meetlost.com Subject: Re: Poll: should man(1)'s default pager change to "less -s"? References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Thu, 14 Dec 2017 16:50:04 +0000 (GMT) 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, 14 Dec 2017 16:50:05 -0000 Alan Somers wrote: > Should man(1)'s default pager change to "less -s"? Vote and flame at the > Phabricator link below. > > https://reviews.freebsd.org/V7 It's probably too late to suggest a "don't mind either way" option, to at least give a better idea on who bothers to vote. But anyway, despite seeming to be "flying the flag" for "more", I actually don't mind either way. It's not because the changes won't affect me. I humbly like to think my responses to such questions are for the overall good. In this case, "less" is similar enough to "more" (and arguably better) that it's not a bad change to make. Old farts like me who prefer the old "more" can continue to set it - those who don't care, or don't know, will not be negatively effected. I know I'm just some random guy on the internet, but I thought I'd throw in my 2 cents as there may be others with a similar philosophy on these types of changes. Cheers, Jamie From owner-freebsd-current@freebsd.org Thu Dec 14 17:15: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 D5497E87E9A; Thu, 14 Dec 2017 17:15:21 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 975046E1FE; Thu, 14 Dec 2017 17:15:20 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id PX6EeVRmUZ8gBPX6FeEDdQ; Thu, 14 Dec 2017 10:15:13 -0700 X-Authority-Analysis: v=2.2 cv=M/g9E24s c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=ocR9PWop10UA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=ag-Oz_82AAAA:8 a=y7kuYUb7n4ZtsMVESh4A:9 a=-XGfW9zKAOz1BphD:21 a=yamhFKWKcW2d2CGF:21 a=mFyHDrcPJccA:10 a=EiQzijv-fp3qqrEWvpUA:9 a=MgieDgEhSvx3FaOa:21 a=OOLWG9eCQyoiPi5M:21 a=2upJ1smRiR5NLq4u:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=4IXIeQpRH-eFAbtnDlMd:22 Received: from [25.81.38.66] (S0106d4ca6d8943b0.gv.shawcable.net [70.66.132.207]) by spqr.komquats.com (Postfix) with ESMTPSA id 31B3F2D9; Thu, 14 Dec 2017 09:15:10 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: Strange behavior about pattern matching on manual pages [FIXED] Date: Thu, 14 Dec 2017 09:15:13 -0800 To: by , Alan Somers CC: "freebsd-hackers@freebsd.org" , Jamie Landeg-Jones , FreeBSD CURRENT Message-Id: <20171214171510.31B3F2D9@spqr.komquats.com> X-CMAE-Envelope: MS4wfCnVh+dANOvqXBUhqHOZjZodHkUq6ZQgorvk18W9PruxCa5yVekepkZ0pk5703LCPAZ6ogBOjZGKoajewLEtSHti6cU7rDwUOzwcehVP18ttG3oWIF3l O2IE5922MvzkX1d5pvJ4BA2c0RrakYJh6yeSfdfmg0uDaQHlmB5puTnl7rWwtQTZHjvlyKz7BLtf/cpChjme9tZW5KMIFZkkCm26jqzsNRasqqYbzQUubIOM GfA7PT797snt7DR018+94+A0hxgbX3UqRWKk+hiGmtk= Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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: Thu, 14 Dec 2017 17:15:21 -0000 SUlSQywgYXMgSSBzY3JpcHRlZCB0aGlzIGFuZCBoYXZlbid0IGxvb2tlZCBhdCBpdCBmb3IgYSBs b25nIHRpbWU6IExFU1M9LU1Ncw0KDQotLS0NClNlbnQgdXNpbmcgYSB0aW55IHBob25lIGtleWJv YXJkLg0KQXBvbG9naWVzIGZvciBhbnkgdHlwb3MgYW5kIGF1dG9jb3JyZWN0Lg0KQWxzbywgdGhp cyBvbGQgcGhvbmUgb25seSBzdXBwb3J0cyB0b3AgcG9zdC4gQXBvbG9naWVzLg0KDQpDeSBTY2h1 YmVydA0KPEN5LlNjaHViZXJ0QGNzY2h1YmVydC5jb20+IG9yIDxjeUBmcmVlYnNkLm9yZz4NClRo ZSBuZWVkIG9mIHRoZSBtYW55IG91dHdlaWdocyB0aGUgZ3JlZWQgb2YgdGhlIGZldy4NCi0tLQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYnkNClNlbnQ6IDA2LzEyLzIwMTcg MTU6MDMNClRvOiBBbGFuIFNvbWVycw0KQ2M6IGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZzsg SmFtaWUgTGFuZGVnLUpvbmVzOyBGcmVlQlNEIENVUlJFTlQNClN1YmplY3Q6IFJlOiBTdHJhbmdl IGJlaGF2aW9yIGFib3V0IHBhdHRlcm4gbWF0Y2hpbmcgb24gbWFudWFsIHBhZ2VzIFtGSVhFRF0N Cg0KCj4g1NogMjAxN8TqMTLUwjfI1aOsMDY6NTOjrEFsYW4gU29tZXJzIDxhc29tZXJzQGZyZWVi c2Qub3JnPiDQtLXAo7oKPiAKPiBPbiBXZWQsIERlYyA2LCAyMDE3IGF0IDM6MzUgUE0sIEphbWll IExhbmRlZy1Kb25lcyA8amFtaWVAY2F0ZmxhcC5vcmcgPG1haWx0bzpqYW1pZUBjYXRmbGFwLm9y Zz4+IHdyb3RlOgo+IEFsYW4gU29tZXJzIDxhc29tZXJzQGZyZWVic2Qub3JnIDxtYWlsdG86YXNv bWVyc0BmcmVlYnNkLm9yZz4+IHdyb3RlOgo+IAo+ID4gSG93IGFib3V0IGp1c3Qgc2V0dGluZyBN QU5QQUdFUj1sZXNzIGluIHlvdXIgZW52aXJvbm1lbnQ/Cj4gCj4gQmVjYXVzZSBzb21lIG9mIHVz IHByZWZlciAibW9yZSI/Cj4gCj4gQW5kIGFzIEkgc2FpZCwgaXQncyByZWxhdGVkIHRvIHNlYXJj aGluZyB1c2luZyB0aGUgbW9yZSgxKSBjb21tYW5kIGdlbmVyYWxseS4KPiAKPiBJIHdhcyB1bmRl ciB0aGUgaW1wcmVzc2lvbiB0aGF0IGZpeGluZyBidWdzIGluIGV4aXN0aW5nIGNvbW1hbmRzIHdh cyBhIGJldHRlcgo+IHNvbHV0aW9uIHRoYW4gdGVsbGluZyBzb21lb25lIHRvIHNpbXBseSB1c2Ug c29tZXRoaW5nIGVsc2UuCj4gCj4gWWVzLCBpdCBjZXJ0YWlubHkgaXMuICBBcmUgeW91IHN1cmUg dGhpcyBpcyBhY3R1YWxseSBhIGJ1ZyBpbiBsZXNzLCBvciBpcyBpdCBqdXN0IHdlaXJkLWJ1dC1p bnRlbmRlZCBiZWhhdmlvciB3aGVuIGxlc3MgaXMgZW11bGF0aW5nIHNvbWUgb2xkIHZlcnNpb24g b2YgbW9yZT8gIEl0IHdvdWxkIGJlIHdvcnRoIGNvbXBhcmluZyBvdXIgbGVzcyBzb3VyY2VzIHRv IHVwc3RyZWFtJ3MgdG8gc2VlIHdoYXQgZGlmZmVyZW5jZXMgaGF2ZSBjcmVwdCBpbiwgYW5kIHN2 biBibGFtaW5nIHRoZW0gdG8gc2VlIHdoeS4KPiAKPiAtQWxhbgoKSSBqdXN0IHRlc3QgaXQgaW4g RnJlZUJTRCAxMS4xLVJFTEVBU0UtcDUKCkl0IHdvcmtzIHdlbGwgd2hlbiBJIGNoYW5nZSBQQUdF Uj1tb3JlIHRvIFBBR0VSPWxlc3MgYmVmb3JlIG1hbigxKS4KCkFuZCBJIGZvdW5kIG1vcmUoMSkg YW5kIGxlc3MoMSkgaXMgdGhlIHNhbWUgdGhpbmcodGhleSBoYXZlIHRoZSBzYW1lIGlub2RlIG51 bWJlciBsYXlpbmcgaW4gZnMpLCBtYXkgYmUganVzdCBkaWZmZXJlbnQgY29tbWFuZCBuYW1lLCBk aWZmZXJlbnQgYmVoYXZpb3IuCgpJZiBpdCBpcyBlbXVsYXRpbmcgbW9yZSgxKSBiZWhhdmlvciBi eSBsZXNzKDEpLCB3aHkgbm90IGp1c3QgcmVwbGFjZSBkZWZhdWx0IFBBR0VSPWxlc3MgPwoKCmJ5 Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmZyZWVic2Qt aGFja2Vyc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QKaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtaGFja2VycwpUbyB1bnN1YnNjcmliZSwgc2VuZCBh bnkgbWFpbCB0byAiZnJlZWJzZC1oYWNrZXJzLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIgo= From owner-freebsd-current@freebsd.org Thu Dec 14 17:26: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 5BD03E8845D for ; Thu, 14 Dec 2017 17:26:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34F4A6E9FD for ; Thu, 14 Dec 2017 17:26:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBEHHb04065896 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Dec 2017 09:17:37 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBEHHanc065895; Thu, 14 Dec 2017 09:17:36 -0800 (PST) (envelope-from fbsd) Date: Thu, 14 Dec 2017 09:17:36 -0800 From: bob prohaska To: blubee blubeeme Cc: FreeBSD current Subject: Re: kernel names Message-ID: <20171214171736.GA65768@www.zefox.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 14 Dec 2017 17:26:39 -0000 On Thu, Dec 14, 2017 at 01:47:13PM +0800, blubee blubeeme wrote: > When you boot into FreeBSD and you can select kernels, there's only 2 > options: > default and kernel.old > > Is there a way to have better output and support multiple kernels without > having to login to the system and running uname -v or something like that? > > Would it be possible to add options for more kernels from that boot menu? Unless I've been fooling myself, it's possible now. Just stop the boot loader during loading by hitting the spacebar and type boot kernelname at the loader prompt This requires that you have saved the /boot/kernelname subdirectory beforehand, for example cp -r /boot/kernel.old /boot/kernel.spare and, on an RPI2, that you have serial console access. It would be very convenient if this were possible on the video console, I gather it's a non-trivial modification. I'm unclear on the situation with other architectures. hth, bob prohaska From owner-freebsd-current@freebsd.org Thu Dec 14 17:46:40 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 4BCF1E88E70 for ; Thu, 14 Dec 2017 17:46:40 +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 E8A346F6DB for ; Thu, 14 Dec 2017 17:46:39 +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 vBEHkbgi063211; Thu, 14 Dec 2017 17:46:37 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id vBEHkbLv063210; Thu, 14 Dec 2017 09:46:37 -0800 (PST) (envelope-from david) Date: Thu, 14 Dec 2017 09:46:37 -0800 From: David Wolfskill To: bob prohaska Cc: blubee blubeeme , FreeBSD current Subject: Re: kernel names Message-ID: <20171214174637.GQ1179@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, bob prohaska , blubee blubeeme , FreeBSD current References: <20171214171736.GA65768@www.zefox.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yBpClG5lv0ksn6ne" Content-Disposition: inline In-Reply-To: <20171214171736.GA65768@www.zefox.net> 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: Thu, 14 Dec 2017 17:46:40 -0000 --yBpClG5lv0ksn6ne Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2017 at 09:17:36AM -0800, bob prohaska wrote: > On Thu, Dec 14, 2017 at 01:47:13PM +0800, blubee blubeeme wrote: > > When you boot into FreeBSD and you can select kernels, there's only 2 > > options: > > default and kernel.old > >=20 > > Is there a way to have better output and support multiple kernels witho= ut > > having to login to the system and running uname -v or something like th= at? > >=20 > > Would it be possible to add options for more kernels from that boot men= u? >=20 > Unless I've been fooling myself, it's possible now. Just stop the boot > loader during loading by hitting the spacebar and type=20 > boot kernelname > at the loader prompt > .... As Allan Jude pointed out earlier in the thread, it's a lot easier than that: just set the "kernels" variable in /boot/loader.conf. For example, I update, build, boot, and run FreeBSD on my laptop daily. That process installs /boot/kernel (after moving the previous one to /boot/kernel.old). I like to keep a "recent known-working" kernel around that isn't automagically replaced, so: g1-252(11.1-S)[1] grep kernel /boot/loader.conf=20 # Experiment to see if kernel.save can be an option from the boot menu kernels=3D"kernel kernel.old kernel.save" g1-252(11.1-S)[2]=20 (And yes, it does work -- verified empirically.) Peace, david --=20 David H. Wolfskill david@catwhisker.org The US "cannot afford" Trump as President or Roy Moore in the Senate. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --yBpClG5lv0ksn6ne Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJaMrj9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XfSsH/i9yATqqZ0g/8Q5x5uaarUGN DpRbI/fLAdpok6tBH/0Fu7YalFOJbPtJPlDMoVZbiIZfBeEp/JQguW2BVq+Bh/vi hO9g8UPpOUnxhUSVBPpDbYMSTy3fMecbYB/sOpuj99sogtB7XGnbykfqP4966Utr OpsOaeXDx3ez3ZCFol+IO7WBiQnU+IX0Pem5NhDjEDdXCZrTbc2gFnpKm5RTRtsy NGB+DXz3giuMfgT82po5ow+YeiOFBnwf2U7FrcLP4Uwp/NthWUA5IYbDE9sFfFeB Tu2FkJFsBZUYXjB+Y10eG/ZSWBTHlwilRfu4ginaYbA4pHQ47JJbAjxCF5WPbBM= =koOc -----END PGP SIGNATURE----- --yBpClG5lv0ksn6ne-- From owner-freebsd-current@freebsd.org Thu Dec 14 18: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 435B8E8A047 for ; Thu, 14 Dec 2017 18:19:11 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) 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 2CF3471564 for ; Thu, 14 Dec 2017 18:19:11 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 28CC6E8A045; Thu, 14 Dec 2017 18: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 28461E8A044; Thu, 14 Dec 2017 18:19:11 +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 0927771563; Thu, 14 Dec 2017 18:19:10 +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 vBEIJ955098154; Thu, 14 Dec 2017 10:19:09 -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 vBEIJ9fL098153; Thu, 14 Dec 2017 10:19:09 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712141819.vBEIJ9fL098153@pdx.rh.CN85.dnsmgr.net> Subject: Re: kernel names In-Reply-To: <20171214174637.GQ1179@albert.catwhisker.org> To: current@freebsd.org Date: Thu, 14 Dec 2017 10:19:09 -0800 (PST) CC: bob prohaska , blubee blubeeme , 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: Thu, 14 Dec 2017 18:36:15 +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: Thu, 14 Dec 2017 18:19:11 -0000 > On Thu, Dec 14, 2017 at 09:17:36AM -0800, bob prohaska wrote: > > On Thu, Dec 14, 2017 at 01:47:13PM +0800, blubee blubeeme wrote: > > > When you boot into FreeBSD and you can select kernels, there's only 2 > > > options: > > > default and kernel.old > > > > > > Is there a way to have better output and support multiple kernels without > > > having to login to the system and running uname -v or something like that? > > > > > > Would it be possible to add options for more kernels from that boot menu? > > > > Unless I've been fooling myself, it's possible now. Just stop the boot > > loader during loading by hitting the spacebar and type > > boot kernelname > > at the loader prompt > > .... > > As Allan Jude pointed out earlier in the thread, it's a lot easier than > that: just set the "kernels" variable in /boot/loader.conf. > > For example, I update, build, boot, and run FreeBSD on my laptop daily. > That process installs /boot/kernel (after moving the previous one to > /boot/kernel.old). I like to keep a "recent known-working" kernel > around that isn't automagically replaced, so: > > g1-252(11.1-S)[1] grep kernel /boot/loader.conf > # Experiment to see if kernel.save can be an option from the boot menu > kernels="kernel kernel.old kernel.save" > g1-252(11.1-S)[2] > > (And yes, it does work -- verified empirically.) And you can also do an ls /boot while at a loader prompt to see all the kernels you have laying around you might want to choose from. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Dec 15 09:12: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 7D599EA0692 for ; Fri, 15 Dec 2017 09:12:26 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 433566E1B2 for ; Fri, 15 Dec 2017 09:12:26 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yb0-x236.google.com with SMTP id x83so5581683ybg.8 for ; Fri, 15 Dec 2017 01:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Fa93K9VSQvujslFueTrIS66h5LId5nZqgfvo8Yz+ysA=; b=flG6U0+IoX1ZNzqqX/fLx7g9B8fYHKAyYZKERwuLcwZJ3ybnCrQwopD0waMYPVV9qO TC7aF0u/Er4xoVCNTFQWpBj3/VsGaAVqXdpop0+7vYige3Whi9Kdh5ZQ7PlsRycEjhxt RKf3qNrtOmAbyX6fssvb62T4AtTaacrdxdkrXO5LvsNVZCdhIkW/b3A5dqrhc8YM/021 nN4fQHAkHZ58a4wjn7WRboLtsqiWBDj/QJNiqGN3TS/gcGhpwpV522z6xrZEsDL9dieR UijCaluagKKstoDXPKgGLzusCMobzAvs6dLl6g7kvYsBhZzwCnyfit2gVUtUbZYZXGay DwZg== 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:from:date:message-id:subject :to; bh=Fa93K9VSQvujslFueTrIS66h5LId5nZqgfvo8Yz+ysA=; b=DjUvGqGr8nUki+opEQuOajn6hgLAFnogMlWHHBFX9GzdTBRneUDSB/gpjOdCJABVrm pFYu9uuR9ZQLlFbFt9sUGnbRypGSngvHdOSd05DbaD8PlUIEBqxGOhare6tjPI6BVI75 wcFYq/XmwJpIjpoH6UG4ld6wPblvf+LB+Os77W8mPPf+EshEMnhfX2AlOvrOEWJSKeCc H/ZDjRYTpqc9G9IxRIpTLNsf/ifQ6xo1Jcsxt3WZXTGxG1HkzyrdL3vgaA9KSbhNSXDp lLKFxLf19VazRXvSq8XnHRKpSGNdHwXBa1bvP/mwvJ8e+RuZ4aXmiL9c1aPoBwzwJpsB F8xA== X-Gm-Message-State: AKGB3mIGSSMXNnm602RW4oXcX45LS2RlcuiA42/eJdXR8TX7suOWz6eT p7JUaP5bbMzPBKfk3EhKadLYaLxhjw0f/DknCISUPw== X-Google-Smtp-Source: ACJfBov5fGqmkrRL+on9Nx3DfHRlkWv/VNEUAJ0hccJi+AHhQTu0T5lql6fdLoCpu4P7usjHu6fkF7ZZzvbzsNZNyaM= X-Received: by 10.13.244.66 with SMTP id d63mr6743587ywf.400.1513329145107; Fri, 15 Dec 2017 01:12:25 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.9.80 with HTTP; Fri, 15 Dec 2017 01:12:09 -0800 (PST) From: Wolfram Schneider Date: Fri, 15 Dec 2017 10:12:09 +0100 X-Google-Sender-Auth: tfe_qopA_K989XeSH2_YIvjl61w Message-ID: Subject: /usr/obj is 11GB huge on FreeBSD 12-current To: 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: Fri, 15 Dec 2017 09:12:26 -0000 Hi, I upgraded a machine from 11-stable to 12-current. The /usr/obj tree is now 11GB huge: FreeBSD 12-current $ du -hs /usr/obj 11G /usr/obj on FreeBSD 11-stable it was less the size: $ du -hs /usr/obj 5.6G /usr/obj this is a problem when you have a small VM with 20GB disk space or less. Is there a way to use less /usr/obj disk space during build? I know that we have to do some bootstrapping for newer compiler tools, but does we need to keep all temp files during the build? # FreeBSD 12-current $ du -ks * | sort -n 4 compiler-metadata.mk 4 host-osreldate.h 112 etc 216 include 9972 tests 15324 libexec 17188 bin 34964 stand 57424 rescue 65280 share 80312 sbin 118616 cddl 146792 kerberos5 175244 secure 192340 gnu 251784 usr.sbin 1269916 obj-lib32 1737908 usr.bin 1863716 sys 2528160 lib 2892776 tmp # FreeBSD 11-stable $ du -ks * |sort -n 4 compiler-metadata.mk 116 etc 216 include 8860 tests 14212 libexec 16260 bin 36276 rescue 63300 sbin 67224 share 85268 cddl 86868 kerberos5 107672 gnu 110360 secure 172352 lib32 222200 usr.sbin 518908 world32 668756 tmp 979040 lib 989640 usr.bin 1721096 sys -Wolfram -- Wolfram Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Fri Dec 15 09:59: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 5C693EA144D for ; Fri, 15 Dec 2017 09:59:12 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id A384D6F32F; Fri, 15 Dec 2017 09:59:11 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp121-45-66-21.bras1.adl6.internode.on.net (HELO leader.local) ([121.45.66.21]) by ipmail06.adl6.internode.on.net with ESMTP; 15 Dec 2017 20:29:09 +1030 Subject: Re: kernel names To: Allan Jude , freebsd-current@freebsd.org References: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> From: Shane Ambler Message-ID: Date: Fri, 15 Dec 2017 20:29:07 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <2f54bb9d-b7e0-9f4a-b894-6d72c7470b24@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-AU 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: Fri, 15 Dec 2017 09:59:12 -0000 On 14/12/2017 16:21, Allan Jude wrote: > On 12/14/2017 00:47, blubee blubeeme wrote: >> When you boot into FreeBSD and you can select kernels, there's only 2 >> options: >> default and kernel.old >> >> Is there a way to have better output and support multiple kernels without >> having to login to the system and running uname -v or something like that? >> >> Would it be possible to add options for more kernels from that boot menu? > > The list is controlled by the /boot/loader.conf variable kernels= > which defaults to "kernel kernel.old" > > I have a patch almost ready to land that will search all subdirectories > of /boot for a file named 'kernel' and add the names of those > directories to the list, such that the list will basically be autogenerated. > > It currently contains too much copy/pasted code, and I just need to > clean it up a bit: https://reviews.freebsd.org/D11886 > > It was originally designed as part of my contributions towards packaged > base, where pkg will keep the last N (default to 5 I think) kernel > packages you have installed around, incase an upgrade goes bad. > > This feature will work on any filesystem supported by the loader. > Thanks Allen, that's much better than manually setting the list. A nice addition to this would be having make installkernel automatically install multiple kernels. Currently we can add KERNCONF to make.conf and have multiple kernels build with one buildkernel command. Then we have to manually run installkernel for each kernel by setting KERNCONF and KODIR for each one. Maybe the kernel config file can have a kodir variable that specifies the kernel name that it should be installed into, unless overridden by KODIR in the installkernel command. Another option might be to have KODIR in make.conf, where each item provides a KODIR for each KERNCONF Normally I build and install two kernels with each system update, one is GENERIC, the other is a debug kernel with things like WITNESS and INVARIANTS enabled. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@freebsd.org Fri Dec 15 12:02:46 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 9CE02EA47A0 for ; Fri, 15 Dec 2017 12:02:46 +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 4F4AA73775; Fri, 15 Dec 2017 12:02:45 +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 vBFC2itp072324; Fri, 15 Dec 2017 12:02:44 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id vBFC2iFi072323; Fri, 15 Dec 2017 04:02:44 -0800 (PST) (envelope-from david) Date: Fri, 15 Dec 2017 04:02:43 -0800 From: David Wolfskill To: Wolfram Schneider Cc: freebsd-current Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current Message-ID: <20171215120243.GB1179@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Wolfram Schneider , freebsd-current References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q6krFlhYnjrU02zP" Content-Disposition: inline In-Reply-To: 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: Fri, 15 Dec 2017 12:02:46 -0000 --Q6krFlhYnjrU02zP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: > Hi, >=20 > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > is now 11GB huge: >=20 > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj >=20 > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj > 5.6G /usr/obj >=20 > this is a problem when you have a small VM with 20GB disk space or less. >=20 > Is there a way to use less /usr/obj disk space during build? I know > that we have to do some bootstrapping for newer compiler tools, but > does we need to keep all temp files during the build? There was a change near the beginning of November; please see UPDATING entry 20171101 -- you probably have several no-longer-used subdirectories under /usr/obj/usr/src/. Once those are cleared out, my experience (tracking stable/11 & head in different slices on the same machines) is that stbale/11 is using about 5.0G, while head uses about 6.1G. > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org The US "cannot afford" Trump as President or Roy Moore in the Senate. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Q6krFlhYnjrU02zP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJaM7njXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X4Z8H/iieWbI/tx2lhxurfGN4tOIK vta2aAPS/xcjFS8jH1iR0bnfezbwxvc6wv4MksXYlPrYbumGAxw2paSowTdRb8Ye yGAAXP2xLBzfTAG5XLii551PTX6gHGyGJrz+IiosQ2+b6jiSZiKVY/bFU7m8lsSB JSMc3ajcud5qxpnjQ9FjvNgy1PvVFOoCVxEdZDTu3nG65NpRlVEpWcar55qmdIMy 8P/F3EoXRxJsyDISzRj7zvNfF5Sijub9M/EIFXJ41Fovwbn9uIKin1NWGikG7C0v H0wXnORxSND4NkCQMCvR9UzZRJw/m7OXVFu/E8Xnk5F5jzlPdahkyFncCb6i3rM= =F++T -----END PGP SIGNATURE----- --Q6krFlhYnjrU02zP-- From owner-freebsd-current@freebsd.org Fri Dec 15 16:51: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 B1260E8614A for ; Fri, 15 Dec 2017 16:51:23 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::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 661AD7C9EF; Fri, 15 Dec 2017 16:51:23 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yb0-x242.google.com with SMTP id 69so6533493ybc.6; Fri, 15 Dec 2017 08:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=gwx5aALDenRVcKw6ZBggNDpllHElq34prCw5TMl0mw4=; b=T/z/9efBuTjBn7Ud++Rpv2NArMqoWNVN6hXRliBJITdoPV8/pQPmi0OR2oOESaTw9w +ACjFoZD6qNtOEZrW2iqVExaof9ZTDID/d+EYNeG8l+zBs8xucQZRV0bPb7y8NlAHI0P r62fqtHKW6ljj3NrEEPXndKRYDD49wIc+nhspizqR5sFVbNolh1P3sgKq3i3kNhQblIP q/SeEPJNmikAzR7UocU0nQCzvVGQk7DGnBoxTePmV6O9waC5CVY2sopaQMh79IJuqKjW o8HDO6MSDFuNWvUSGizRKF0VuITrdydEGkN6wzRmAEqB3W48cwRgsLA3ZJ8Yvm+oah01 dwTQ== 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=gwx5aALDenRVcKw6ZBggNDpllHElq34prCw5TMl0mw4=; b=NJfmOxzFsnFNoeJfihR0FFC3cwhtjd/ZJV6g5ngcP1o+Cn//NsJ8bGC1+CEYB7deTa RXmooMKXVi2zrECUjIT4gCiSX44/bc4pwz36+GnTafSbFqQHJeCgHUGeYWOrXVrU8V3j qf1jYS0JjcqYVofY50oHGrged4euL/QUIzUveoSrJ2lyAgFvKksXXEHOpQqbNKM/zrO3 z3cER7RHbb6qKG1EIzahK9GJxjLJjBDLHEpTiv+3/pYvKUj+iMP8uC77dbeVwuPOr5Xh Gkiow+yZlvLWy8gpMQY2OZN+SFYPA+xOtlFzxgoMaOe9Fd7Oq5NZ8ggxSKJo35dEOjrt oGmA== X-Gm-Message-State: AKGB3mJ1ifbe6yD/KE+bk9FVM5NR5VR0wl55nGifixWGQGDNqXdPCn5k Plu2tTcz8ohibOt55d125IwASMfX/iaeHJcyRy4= X-Google-Smtp-Source: ACJfBouOJockYJ1Vqy8+X+QtIy8Aj7Uhp5n5MT2jOtFEvL5v/dsUIEkxlWd7OIdH9mbrfBY6xPxvYt44sDO5EF7bkSQ= X-Received: by 10.129.87.2 with SMTP id l2mr1687757ywb.228.1513356682535; Fri, 15 Dec 2017 08:51:22 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.9.80 with HTTP; Fri, 15 Dec 2017 08:51:07 -0800 (PST) In-Reply-To: <20171215120243.GB1179@albert.catwhisker.org> References: <20171215120243.GB1179@albert.catwhisker.org> From: Wolfram Schneider Date: Fri, 15 Dec 2017 17:51:07 +0100 X-Google-Sender-Auth: QR0f4sU32klC_sJhWTSWXTiGQ9I Message-ID: Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current To: David Wolfskill , Wolfram Schneider , 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: Fri, 15 Dec 2017 16:51:23 -0000 On 15 December 2017 at 13:02, David Wolfskill wrote: > On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >> Hi, >> >> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >> is now 11GB huge: >> >> FreeBSD 12-current >> $ du -hs /usr/obj >> 11G /usr/obj >> >> on FreeBSD 11-stable it was less the size: >> $ du -hs /usr/obj >> 5.6G /usr/obj >> >> this is a problem when you have a small VM with 20GB disk space or less. >> >> Is there a way to use less /usr/obj disk space during build? I know >> that we have to do some bootstrapping for newer compiler tools, but >> does we need to keep all temp files during the build? > > There was a change near the beginning of November; please see UPDATING > entry 20171101 -- you probably have several no-longer-used > subdirectories under /usr/obj/usr/src/. > > Once those are cleared out, my experience (tracking stable/11 & head in > different slices on the same machines) is that stbale/11 is using about > 5.0G, while head uses about 6.1G. I think the suspect directories are "tmp" and "obj-lib32", together they are 4.1GB huge. I will run a build of current again with a clean obj tree (-current on a recent -current). Let's see. Can we agree that the obj tree should not grow from 5GB to 10GB for the next release? -Wolfram -- Wolfram Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Fri Dec 15 17:39:05 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32234E875FF for ; Fri, 15 Dec 2017 17:39:05 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::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 E1E727E7A3; Fri, 15 Dec 2017 17:39:04 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yb0-x242.google.com with SMTP id r4so6633451ybd.12; Fri, 15 Dec 2017 09:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=b/FO0Qp+/evd9cnQGamFEiBwYOtqD2+277qPODlIOFI=; b=na3vjUJQ2GgcV4gkO5SSB2nUnSfoxXm8u98X7OXvt2FmbKfleXioJYFJBmn8tn4yEQ AYVdPF03ogoXg9slHy9W8l/SqylYTiBTy2sDwoQCGqT2ZNV2ao1MO4vHTTzAfeT8nLg+ 6N4zUhXJskPwWpOR8RsS7Byd3XXNzAWTG4ghlwnwqLKP8XRtk5yvwpG2TLdTEmT/ZF8W 5b5rUGyLyh6CQC8VF3oDKtmMf/qorYreFCpjdCpSRixm6UaKm4WtSqp55b1bV8Y2A+d1 nuqJI2yYDagH4NCPyCRweo70lBeEsUyASqFZT6Ef5I6ya4p0BeX9bZxt36eDC2PyJqma J1+w== 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=b/FO0Qp+/evd9cnQGamFEiBwYOtqD2+277qPODlIOFI=; b=SERqS2gfbY5Np0k74WyXO6IBK/wnjxqTpGIzQsf5Gi/Z9RWP8CFmKel4cndo1xOw13 AZ2K1mIdNWIamdihujJtOqHPT3nATlc0E8wLkCujso5g+jh2K/oehgvYkW2+afFAhEfO H0z7K4peMaNy+CaLznsbTRLGldRWd/3G0RQZkpRaF8l3IaxDt+ForsuCv4A2YH2Vn63Y /i5BLaGVQaLQl8xN9b2KciKXpXBFY+X1QK5f5nHY6Vmr2QsXVzI0J0xx33YDlaptCEMe Q94H/tJQFuMThIEU7DquveO33vO1hwxdca3m2rrSwWjv02aVr2hkghXzZ8jvKIPUMx0o o4bg== X-Gm-Message-State: AKGB3mLnfIf6K+OqGSd0c6yBydVUAnESB8DZxriwCENDSyKI/5un9tjV n35PmBW7Q2YybH/9yvZ9XsC6bmQjrTq97ls1BgI= X-Google-Smtp-Source: ACJfBou+DPU2LlfywPbRz3A/EQT5dRyTZE1DriB7KDlacCc6hz7xyVHLbVn59kABFyOK5UjGXBm297JtTYeGbp9kTX4= X-Received: by 10.37.57.10 with SMTP id g10mr7763555yba.438.1513359544063; Fri, 15 Dec 2017 09:39:04 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.9.80 with HTTP; Fri, 15 Dec 2017 09:38:48 -0800 (PST) In-Reply-To: References: <20171215120243.GB1179@albert.catwhisker.org> From: Wolfram Schneider Date: Fri, 15 Dec 2017 18:38:48 +0100 X-Google-Sender-Auth: SgwO2sbeXxAMPAFRINbM9ESn8Bs Message-ID: Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current To: David Wolfskill , Wolfram Schneider , 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: Fri, 15 Dec 2017 17:39:05 -0000 On 15 December 2017 at 17:51, Wolfram Schneider wrote: > On 15 December 2017 at 13:02, David Wolfskill wrote: >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >>> Hi, >>> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >>> is now 11GB huge: >>> >>> FreeBSD 12-current >>> $ du -hs /usr/obj >>> 11G /usr/obj >>> >>> on FreeBSD 11-stable it was less the size: >>> $ du -hs /usr/obj >>> 5.6G /usr/obj >>> >>> this is a problem when you have a small VM with 20GB disk space or less. >>> >>> Is there a way to use less /usr/obj disk space during build? I know >>> that we have to do some bootstrapping for newer compiler tools, but >>> does we need to keep all temp files during the build? >> >> There was a change near the beginning of November; please see UPDATING >> entry 20171101 -- you probably have several no-longer-used >> subdirectories under /usr/obj/usr/src/. >> >> Once those are cleared out, my experience (tracking stable/11 & head in >> different slices on the same machines) is that stbale/11 is using about >> 5.0G, while head uses about 6.1G. > > I think the suspect directories are "tmp" and "obj-lib32", together > they are 4.1GB huge. > > I will run a build of current again with a clean obj tree (-current on > a recent -current). Let's see. I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov 5) with an empty obj directory. `make buildworld' creates 9.7GB of obj data. After running `make buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my original report was on UFS) -Wolfram > Can we agree that the obj tree should not grow from 5GB to 10GB for > the next release? > > -Wolfram > > -- > Wolfram Schneider https://wolfram.schneider.org -- Wolfram Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Fri Dec 15 18:39: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 49542E88F26 for ; Fri, 15 Dec 2017 18:39:44 +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 D2328809E5; Fri, 15 Dec 2017 18:39:43 +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 vBFIdS1n018253 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Dec 2017 20:39:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBFIdS1n018253 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBFIdSen018252; Fri, 15 Dec 2017 20:39:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Dec 2017 20:39:28 +0200 From: Konstantin Belousov To: Wolfram Schneider Cc: David Wolfskill , freebsd-current Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current Message-ID: <20171215183928.GO2272@kib.kiev.ua> References: <20171215120243.GB1179@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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: Fri, 15 Dec 2017 18:39:44 -0000 On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: > On 15 December 2017 at 17:51, Wolfram Schneider wrote: > > On 15 December 2017 at 13:02, David Wolfskill wrote: > >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: > >>> Hi, > >>> > >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > >>> is now 11GB huge: > >>> > >>> FreeBSD 12-current > >>> $ du -hs /usr/obj > >>> 11G /usr/obj > >>> > >>> on FreeBSD 11-stable it was less the size: > >>> $ du -hs /usr/obj > >>> 5.6G /usr/obj > >>> > >>> this is a problem when you have a small VM with 20GB disk space or less. > >>> > >>> Is there a way to use less /usr/obj disk space during build? I know > >>> that we have to do some bootstrapping for newer compiler tools, but > >>> does we need to keep all temp files during the build? > >> > >> There was a change near the beginning of November; please see UPDATING > >> entry 20171101 -- you probably have several no-longer-used > >> subdirectories under /usr/obj/usr/src/. > >> > >> Once those are cleared out, my experience (tracking stable/11 & head in > >> different slices on the same machines) is that stbale/11 is using about > >> 5.0G, while head uses about 6.1G. > > > > I think the suspect directories are "tmp" and "obj-lib32", together > > they are 4.1GB huge. > > > > I will run a build of current again with a clean obj tree (-current on > > a recent -current). Let's see. > > I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov > 5) with an empty obj directory. > > `make buildworld' creates 9.7GB of obj data. After running `make > buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my > original report was on UFS) Most likely reason of the bump is generation of debugging data, turned on for 12. Another not usable thing to disable are tests and profile libraries. Put the following into /etc/src.conf: WITHOUT_PROFILE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_TESTS=yes From owner-freebsd-current@freebsd.org Fri Dec 15 19:21:08 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC269E89FCD for ; Fri, 15 Dec 2017 19:21:08 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002: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 5CF1D281F; Fri, 15 Dec 2017 19:21:08 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yb0-x22f.google.com with SMTP id h202so6051022ybg.10; Fri, 15 Dec 2017 11:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=B7pEDrcHYb/SJ6L+niknjC2bPvPOkEIyH6d7tyWdnc4=; b=J+7n7CBAlrCyJD3mGyg4Uf2BJT9Smfma1VJh4/e4crXwKh3M87CEzPEBTu/KjkwZU+ UwqWetxF6ut2CjRQyu7Z1C4SNhgCRdDfqxmXCPByI/rFKtCzqat94orDnEvu1uwOBW6E wxAAWe0zmr148AILILmTqZwMenYXSl0F7hnhGvzopgtvUvDoovKlu7/3aSvrTjrW9M6z om9dhp5Fgfum2nbwcuBb0yUkq1EyY4APvrBAkyAxwzLtGURhqjVtWeZCTZL4+dptABpM eJbsoFQ5VdOb3qiakn+dwqY9RSFFqTgu+rdmmQDhwVAPc/1UuXpdN2WcdTs/zKOoSr6C O1LQ== 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=B7pEDrcHYb/SJ6L+niknjC2bPvPOkEIyH6d7tyWdnc4=; b=J+cvfBDGwu43cUqH4x3xVyqn5ua0Le6IlN14nWYqnjGfvdk79ItGZUynRlmgMe05p5 uCMOd3NrqcaLP1+Wk+nLIP+tjvgoySeXup1LvjHKzswXSB1JoTFVvsQ/bmkomckVbTio 8FvBXsEX47rAq+AR7eTuHCU7zRWLVU+E+QXOKvYCWrJMuSL/48q5KQ7Kf7Lh5hwi+Jbc jQw60OgbbwciCth6mLNk8ZXbNx1Y8a+vSTJVxG3TEKTCDBQ+Mx92WFyeXUk1hcHNDOS1 Py3p6uoFoHoIR0rRNEqdcMQ7paq1hjSRKZCAmJ7knZ3pBQE7tt3/bzgL1A/w8bBwhVtn c0MA== X-Gm-Message-State: AKGB3mIcmB71EoP5pWGbmXfRZvSbSAP6XZdJO7GCLPZtfwdXqeWV7/DT hRGfWbmUgM1s3YylOjdePA0y/I1k9azO86w0e4JETw== X-Google-Smtp-Source: ACJfBovWOYrZxrPqp2vwdmGvPfLofeChrpEAPJvXgk9KVNQF6BF6/GQ3sbT+Oanaiygx/UiYK7OQhhzckFGiQ/xyhp4= X-Received: by 10.37.113.87 with SMTP id m84mr7972957ybc.201.1513365667486; Fri, 15 Dec 2017 11:21:07 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.9.80 with HTTP; Fri, 15 Dec 2017 11:20:52 -0800 (PST) In-Reply-To: <20171215183928.GO2272@kib.kiev.ua> References: <20171215120243.GB1179@albert.catwhisker.org> <20171215183928.GO2272@kib.kiev.ua> From: Wolfram Schneider Date: Fri, 15 Dec 2017 20:20:52 +0100 X-Google-Sender-Auth: -QzsgY-eytaj74LZw4bFaczVLgY Message-ID: Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current To: Konstantin Belousov , Wolfram Schneider Cc: David Wolfskill , 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: Fri, 15 Dec 2017 19:21:08 -0000 On 15 December 2017 at 19:39, Konstantin Belousov wrote: > On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: >> On 15 December 2017 at 17:51, Wolfram Schneider wrote: >> > On 15 December 2017 at 13:02, David Wolfskill wrote: >> >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >> >>> Hi, >> >>> >> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >> >>> is now 11GB huge: >> >>> >> >>> FreeBSD 12-current >> >>> $ du -hs /usr/obj >> >>> 11G /usr/obj >> >>> >> >>> on FreeBSD 11-stable it was less the size: >> >>> $ du -hs /usr/obj >> >>> 5.6G /usr/obj >> >>> >> >>> this is a problem when you have a small VM with 20GB disk space or less. >> >>> >> >>> Is there a way to use less /usr/obj disk space during build? I know >> >>> that we have to do some bootstrapping for newer compiler tools, but >> >>> does we need to keep all temp files during the build? >> >> >> >> There was a change near the beginning of November; please see UPDATING >> >> entry 20171101 -- you probably have several no-longer-used >> >> subdirectories under /usr/obj/usr/src/. >> >> >> >> Once those are cleared out, my experience (tracking stable/11 & head in >> >> different slices on the same machines) is that stbale/11 is using about >> >> 5.0G, while head uses about 6.1G. >> > >> > I think the suspect directories are "tmp" and "obj-lib32", together >> > they are 4.1GB huge. >> > >> > I will run a build of current again with a clean obj tree (-current on >> > a recent -current). Let's see. >> >> I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov >> 5) with an empty obj directory. >> >> `make buildworld' creates 9.7GB of obj data. After running `make >> buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my >> original report was on UFS) > > Most likely reason of the bump is generation of debugging data, turned on > for 12. Another not usable thing to disable are tests and profile libraries. > Put the following into /etc/src.conf: > WITHOUT_PROFILE=yes > WITHOUT_DEBUG_FILES=yes > WITHOUT_TESTS=yes Hi Konstantin, I tried these 3 variables and the results looks much better, down to 5.1GB from 12GB. Many thanks! $ du -hs obj* 12G obj-debug 5.1G obj-nodebug -Wolfram -- Wolfram Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Fri Dec 15 18:52:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E44F6E89431 for ; Fri, 15 Dec 2017 18:52:10 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 ADA6C119D for ; Fri, 15 Dec 2017 18:52:09 +0000 (UTC) (envelope-from roberthuff@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=HapWdWM8 c=1 sm=1 tr=0 a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=KGjhK52YXX0A:10 a=L9H7d07YOLsA:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=ocR9PWop10UA:10 a=48faUk6PgeAA:10 a=zipkaEB5OJc0MB2qEq4A:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=roberthuff; auth=pass (PLAIN) Received-SPF: softfail (smtp01.rcn.cmh.synacor.com: transitional domain rcn.com does not designate 209.6.230.48 as permitted sender) Received: from [209.6.230.48] ([209.6.230.48:37888] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id A1/13-25893-8D9143A5; Fri, 15 Dec 2017 13:52:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23092.6616.143849.788035@jerusalem.litteratus.org> Date: Fri, 15 Dec 2017 13:52:08 -0500 To: Wolfram Schneider Cc: freebsd-current Subject: /usr/obj is 11GB huge on FreeBSD 12-current In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.3.1 (amd64-portbld-freebsd12.0) X-Mailman-Approved-At: Fri, 15 Dec 2017 19:28:16 +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: Fri, 15 Dec 2017 18:52:11 -0000 Wolfram Schneider writes: > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > is now 11GB huge: > > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj > > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj > 5.6G /usr/obj Mine - also 12-current - reports 7.6G. May we see your kernel config file, src.conf, and make.conf? Respectfully, Robert Huff From owner-freebsd-current@freebsd.org Fri Dec 15 19:42: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 1A33DE8AC35 for ; Fri, 15 Dec 2017 19:42:13 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBF253A4E; Fri, 15 Dec 2017 19:42:12 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To: References:Message-ID:CC:To:From:Subject:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=x3YfHl9MaA8TS3Ualawf4W1JOiVGnUboWjJbLJrc5LI=; b=qRuVC1fTV/kVc8sBqRnWRbVy+3 wMs3Nniv4CRTCSa4l207vc6ko4cipVNeoLHv+l2aVpk9IpaiwPh5YVB4bUSGARwzs+cmbtivlRGPW End5opmpwkBdhB40flKXJ/RzDj9F8yXIJWXQRkPD/MIPG2tIrw8961IzaVovlnPI8C9Q=; Received: from [74.203.163.58] (port=17673 helo=[10.106.10.50]) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1 (FreeBSD)) (envelope-from ) id 1ePvs3-000BmQ-KU; Fri, 15 Dec 2017 13:42:11 -0600 User-Agent: Microsoft-MacOutlook/10.9.0.171212 Date: Fri, 15 Dec 2017 13:41:40 -0600 Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current From: Larry Rosenman To: Wolfram Schneider CC: freebsd-current Message-ID: Thread-Topic: /usr/obj is 11GB huge on FreeBSD 12-current References: <23092.6616.143849.788035@jerusalem.litteratus.org> In-Reply-To: <23092.6616.143849.788035@jerusalem.litteratus.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" 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: Fri, 15 Dec 2017 19:42:13 -0000 On 12/15/17, 1:28 PM, "owner-freebsd-current@freebsd.org" wrote: Wolfram Schneider writes: > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > is now 11GB huge: > > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj > > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj > 5.6G /usr/obj Mine - also 12-current - reports 7.6G. May we see your kernel config file, src.conf, and make.conf? Respectfully, Robert Huff For the record: borg.lerctr.org /usr/obj $ du -shA 30G . borg.lerctr.org /usr/obj $ borg.lerctr.org /usr/obj $ cat /etc/src.conf WITH_CLANG_EXTRAS=yes WITH_CLANG_FULL=yes WITH_LLDB=yes WITH_GCC=yes WITH_GNUCXX=yes WITH_CCACHE_BUILD=yes CCACHE_DIR=/var/cache/ccache borg.lerctr.org /usr/obj $ cat /etc/make.conf DEVELOPER=yes SVN=/usr/local/bin/svn SVN_UPDATE=yes # DTRACE KERNEL, Stripped of unnecessary devices #KERNCONF=BORG-DTRACE KERNCONF=VT-LER # USERLAND DTRACE #STRIP= #CFLAGS+=-fno-omit-frame-pointer #WITH_CTF=1 # #__EXIM__ LOG_FILE_PATH="syslog:${LOGDIR}/%slog" LOGDIR=/var/log/exim # WITH_POSTGRES=yes #WITH_APACHE2=yes #CUPS is the default WITH_CUPS=YES CUPS_OVERWRITE_BASE=YES WITHOUT_LPR=YES WITH_JADETEX=yes WITH_PKGNG=yes #PORTS_MODULES+=emulators/virtualbox-ose-kmod #PORTS_MODULES+=x11/nvidia-driver #MALLOC_PRODUCTION=yes DEFAULT_VERSIONS=pgsql=9.6 apache=2.4 php=7.0 linux=c7 ##### borg.lerctr.org /usr/obj $ Doesn't bother me much. (this might also be because of bdrewery@'s changes with meta-mode, and not clearing /usr/obj in a while, so there may be stale/old directories). _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Dec 15 23:37: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 0B736E8F6A6 for ; Fri, 15 Dec 2017 23:37:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C544D69F36 for ; Fri, 15 Dec 2017 23:37:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id r6so21843123itr.3 for ; Fri, 15 Dec 2017 15:37:11 -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=xpMC3BMXSRA+1CsSLheafS2cRGg6hlPhr8c64+j7u7U=; b=xDYyfhP2xa7oeDCGQkHIemz9jZIIKqHjihbN/7YLNKWCtNnEGYoHW490yUTFaR85nX /fFZ7UhqjzHO8qeMOwSkhIgz+C3kBMX0Ip6KtZvWNmkeNvlUd+3k6q+gWAfMnqZECd+R XrINAhhCIBC30hcUsBOlpAwwL1SqNSdrA2naLJ1u1ANAmXkcp3YZNSozdxco4+MP0oGQ KgcWgcGvvU+TMv2yjQRse4kqoKKtM6weuOOBm219obN9HwDj/4yTYfeN9rMN7xb/2Fi/ XQ+385BE5nLmvkHYju27WQ528X8tQcyh2DGXSlJn9PMHbh2ThIFnKZuXsolhemuYot1D 5xcA== 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=xpMC3BMXSRA+1CsSLheafS2cRGg6hlPhr8c64+j7u7U=; b=m/k8rrK4BiMDc24Jayqu9zYolNZn5rGEmOShEEQTOuYiIFCuohE6hupU7PCIf8NQq2 x8JnlFhj58uILYs0Ja7sJ2xvSSTpNFvobfhubAu5v/dci19BhO3HJYQtyWVehS/unB3J GdAid5bAt9StBPaFwRe5YACXjslol57bm5lowvRI9lBUqoyGp0IT9kqIeShaL/G2jbdd z+0K/yJfRfF8CS/89S54yiefiTYV6zAjuN4uXt7ASgL5OrPqigPFO6KaX72qaPSZUtLb yBrbetqqLhPzDRD1n36T4rT29KmLgVuVCjeeqxYE3qINzHVWhM2Iygq+DopxrioPDPRk rLtg== X-Gm-Message-State: AKGB3mJiASuxW19SMjCweDwbeomClFSWcbimvWDJtIXCdxbD/4ir0NGv T7V0gbhBXdBYk39BH6q8wH/QawUDeit1X4Vz8lBaYg== X-Google-Smtp-Source: ACJfBoun0xdrirf3LL20BKnS/A4W+ieDJVTZeEX/omhWyngoVeDrxoIJpgn87jxHN0YyOeF7X7HkrrEDKGlxslbfddQ= X-Received: by 10.36.133.135 with SMTP id r129mr11730035itd.69.1513381031022; Fri, 15 Dec 2017 15:37:11 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Fri, 15 Dec 2017 15:37:10 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Fri, 15 Dec 2017 16:37:10 -0700 X-Google-Sender-Auth: 62jHFTDiIiyOKzwPXgvUYFtG_P4 Message-ID: Subject: Re: GPTZFSBOOT in Current r326622 has problems To: lausts@acm.org Cc: 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: Fri, 15 Dec 2017 23:37:12 -0000 On Wed, Dec 6, 2017 at 8:54 AM, Warner Losh wrote: > > > On Wed, Dec 6, 2017 at 8:35 AM, Thomas Laus wrote: > >> Group: >> >> I updated my amd64 computer today to r326622 and copied the >> /boot/gptzfsboot file to each of my ZFS hard drives p1 partition. The >> BTX loader stopped and could not load. This rendered my system >> 'un-bootable'. I copied this file from an earlier live filesystem CD, >> which restored my computer and enabled me to boot. >> > > Any chance you can bisect when this happened? I think I'll need more > details to see what happened. What was your old loader that world based on? > I believe that these issues have been corrected in r326888. My refactoring to make it easier to bring in the lua boot loader in r326593 (after breaking the build in r326584 accidentally) uncovered some latent subtle ordering issues. This cause GELI-enabled (but not even using) ZFS boot loaders to fail. This was related to an odd interaction between zfs and geli implementation files in gptzfsboot (and zfsboot) which caused us to have two different implementations of malloc, with all the fun you'd expect when the second one got called. If you have issues after r326888, please let me know. Warner From owner-freebsd-current@freebsd.org Sat Dec 16 01:23:34 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F16AE92ABC for ; Sat, 16 Dec 2017 01:23:34 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msa04y.plala.or.jp (msa04.plala.or.jp [58.93.240.4]) by mx1.freebsd.org (Postfix) with ESMTP id 242276EDA6 for ; Sat, 16 Dec 2017 01:23:33 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc02.plala.or.jp ([172.23.12.32]) by msa01y.plala.or.jp with ESMTP id <20171216012210.DTZS9031.msa01y.plala.or.jp@msc02.plala.or.jp> for ; Sat, 16 Dec 2017 10:22:10 +0900 Received: from localhost ([2400:4050:9320:7a00::8]) by msc02.plala.or.jp with ESMTP id <20171216012210.YEAZ6556.msc02.plala.or.jp@localhost> for ; Sat, 16 Dec 2017 10:22:10 +0900 Date: Sat, 16 Dec 2017 10:22:00 +0900 (JST) Message-Id: <20171216.102200.92810826001482189.ish@amail.plala.or.jp> To: freebsd-current@freebsd.org Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current From: Masachika ISHIZUKA In-Reply-To: <20171215120243.GB1179@albert.catwhisker.org> References: <20171215120243.GB1179@albert.catwhisker.org> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; msa01m; Sat, 16 Dec 2017 10:22:10 +0900 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, 16 Dec 2017 01:23:34 -0000 >> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >> is now 11GB huge: >> [snip] > > There was a change near the beginning of November; please see UPDATING > entry 20171101 -- you probably have several no-longer-used > subdirectories under /usr/obj/usr/src/. > > Once those are cleared out, my experience (tracking stable/11 & head in > different slices on the same machines) is that stbale/11 is using about > 5.0G, while head uses about 6.1G. Hi David. Thank you very much for good information. I was in trouble and removed no-longer-used subdirectories under /usr/obj/usr/src/. Now, I have enought space to 'make -j4 buildworld && make -j4 kernel'. -- Masachika ISHIZUKA From owner-freebsd-current@freebsd.org Sat Dec 16 04:02: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 E754DE9B207 for ; Sat, 16 Dec 2017 04:02:41 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (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 A0DC67563F; Sat, 16 Dec 2017 04:02:40 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id vBG44BJd090023; Fri, 15 Dec 2017 20:04:17 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: UDNSMS MIME-Version: 1.0 Cc: "freebsd-current" In-Reply-To: From: "Chris H" Reply-To: bsd-lists@BSDforge.com To: "Wolfram Schneider" Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current Date: Fri, 15 Dec 2017 20:04:17 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed 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: Sat, 16 Dec 2017 04:02:42 -0000 On Fri, 15 Dec 2017 10:12:09 +0100 "Wolfram Schneider" = said > Hi, >=20 > I upgraded a machine from 11-stable to 12-current=2E The /usr/obj tree > is now 11GB huge: >=20 > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj >=20 > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj > 5=2E6G /usr/obj >=20 FWIW on a fresh: FreeBSD dev-box 12=2E0-CURRENT FreeBSD 12=2E0-CURRENT #0: Wed Dec 13 06:07:59 P= ST 2017 root@dev-box:/usr/obj/usr/src/amd64=2Eamd64/sys/DEVBOX amd64 (r326056) I show 4=2E5Gb on /usr/obj --Chris From owner-freebsd-current@freebsd.org Sat Dec 16 09:57: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 3E6C6EA2DC6 for ; Sat, 16 Dec 2017 09:57:14 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yb0-x243.google.com (mail-yb0-x243.google.com [IPv6:2607:f8b0:4002:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00DD07EF8B; Sat, 16 Dec 2017 09:57:13 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yb0-x243.google.com with SMTP id j7so7891135ybl.3; Sat, 16 Dec 2017 01:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Yv6jt8qOToYw5UWOK7am3IQy0qXl/1hrxtiJpGSor1k=; b=KMbZXjYemYDQGCIK/1bY7itDE33hn7sCVG8CUpG2Tb0a+/Jq4YEGuowOUm4T3lCNK2 IbA0BxrGuJzzAtIROR5pilLahnoAjOtDJ0TCxSLqfVQSKnfIkH4gaPIrWbwbBNP+6pVS yRztJtA2SrppylnybNV4n9sPixpSsIHk3qZFSWqRZXTJcfTG6sX99O18vCfL4KOahzSd KtY/paCC4unSuVrilNC8VwgSX97sfDe6OudyC2XKqmZID1E1Y1fQkXz7PJs7sX674j2f mgv0gLow+wmCnMBRWMByc43t/pkNt9qr+urqpE6kXe/gsF1HTC+6cvszNUNtcrq4KxT6 Gpew== 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=Yv6jt8qOToYw5UWOK7am3IQy0qXl/1hrxtiJpGSor1k=; b=h8OHv/OuDXa6nG/G5Z50QYvXo2fajQfu6CZPN1XZ3cW+p8jFBkQnsCPLBjD1bcp0RD yiPJjuegMsLjxAfAiJn1fYBm9fwzChwqACUsgjvUE6qtrTC2zS1aOip1o6U/S9zLlcYp TqaYX+ijPNfxiVxTnMPDiliiOAzOl60xLGiGXoKcZQibMOLScgeXKpktp8Y73nuGvgje 7z5FkTxGyWKTYaB9qfihj8u2NU6SfHHCZJkPD0JAxWD42GifWCOmNoAhzO4u7odQleAM UHj9rcyh5bVzVqtmj6FYC3+jz0nhItkb7P+cAGDCVZS2EDwp1SBgoqiu4UmrtN3VQsXP 6tmg== X-Gm-Message-State: AKGB3mJGRtkX55K+ArFimVbhQeZrkf4HZHjSBSwZaoQPqhTU+G/9ByzU 8dFBoRm2eV+24s5kJMTb+zMvT+OMn4C9nD23JSs= X-Google-Smtp-Source: ACJfBovgG4a7ZGRkaJHBKXbG7BjFjl7liNS4gqctAk2EwWNslsbBgW6X+f0i0BoNfAZqIX5sPZwe9ZSuFrTB+HT5RUI= X-Received: by 10.129.87.2 with SMTP id l2mr3317622ywb.228.1513418233055; Sat, 16 Dec 2017 01:57:13 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.9.80 with HTTP; Sat, 16 Dec 2017 01:56:57 -0800 (PST) In-Reply-To: References: <23092.6616.143849.788035@jerusalem.litteratus.org> From: Wolfram Schneider Date: Sat, 16 Dec 2017 10:56:57 +0100 X-Google-Sender-Auth: P5zC0llcWv5hGoWikqneUo86c3M Message-ID: Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current To: Larry Rosenman , Wolfram Schneider 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: Sat, 16 Dec 2017 09:57:14 -0000 On 15 December 2017 at 20:41, Larry Rosenman wrote: > On 12/15/17, 1:28 PM, "owner-freebsd-current@freebsd.org" wrote: > > > Wolfram Schneider writes: > > > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > > is now 11GB huge: > > > > FreeBSD 12-current > > $ du -hs /usr/obj > > 11G /usr/obj > > > > on FreeBSD 11-stable it was less the size: > > $ du -hs /usr/obj > > 5.6G /usr/obj > > Mine - also 12-current - reports 7.6G. > May we see your kernel config file, src.conf, and make.conf? I'm running a fresh installed FreeBSD without modifications. There is no src.conf or make.conf on the machine. -Wolfram -- Wolfram Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Sat Dec 16 16:50:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6084E87B89 for ; Sat, 16 Dec 2017 16:50:10 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A6F36A3EE; Sat, 16 Dec 2017 16:50:10 +0000 (UTC) (envelope-from wschnr@googlemail.com) Received: by mail-yb0-x230.google.com with SMTP id w1so521859ybe.10; Sat, 16 Dec 2017 08:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yxo3lbVn3n+rxr1FSHGVxWy64cb4iDt9cnRACEm+m3w=; b=W1Fcw2iyIv3X8P3AReX/XGX2HxuUMTNUQlnm5BUnHabOCsoCi/5w72wuNRw0B1v8Tu EUjigyNQeuFRDaIczAazNyJau8GgP/mvUnWlM5cFsIefybM7yxmmbzYG68jsbywLjbxa USFWSl16RV1gG5uS+iT8P2atpp3vJ4Sgoy+ARqG3suVkj26tWQSbYFgyvabkgBpgMqdJ D8R15HhSI1Vob0Ljt0RDmfOQByGKeTsKZTEQYtY/4o2HYR34lDTE8VFHfK9MBNF+PaHa 2yFXPzJYlEW8xqzucdYe41vNuAPjX4THQ7CM1ScF1B1Khi44qjqeXO9nN2YlI9Zvp5Wi 758g== 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=yxo3lbVn3n+rxr1FSHGVxWy64cb4iDt9cnRACEm+m3w=; b=qNl3s3I0HOskVK5t89GtbvA2JyuLQnLMZKuo1nFWD/elkhcVHOefKZqLHBNXqOpMbw rEeE/D/OxzGmeDutjXxiZg2GekwSyan9leHWedTAiziVljG5H372d9DfaUyOdjNkAyrv dHxQoEq/jNNJg+udGK0ohPSMrcfY9dGIBbYq5OVjttMn9i3PZSoNwEiktTegJUf6eXFs UjEnEymMbopWazNZwsBnoaAJTAgMGDPajjQNMCL39K4BBRGODit1gLisau5k9p9Ji9M8 wKjIBlEoJLVm8eom/kRYLRzgVQGWLcKM+BLcYJJRZL3Aqb+36/Lzy5aOarDcuEig3Hnd iR1g== X-Gm-Message-State: AKGB3mKaIr7PmO6W56b1hQTtyroBFtdFcOKUBE+Sejj9Z0wOt8cD1hU7 4c0MjxyOtAKZWxt0jSgIcfGVj/xpl4sxrIh6rsS86w== X-Google-Smtp-Source: ACJfBovWI7BRyHhh0tG3PRTe4NLOw9QD6xAE4V9hNkkWHN/jUa3orG6daHpaW3kG654YFy3B6Qa7W+srSB1ankii4UU= X-Received: by 10.13.248.2 with SMTP id i2mr10413498ywf.448.1513443009320; Sat, 16 Dec 2017 08:50:09 -0800 (PST) MIME-Version: 1.0 Sender: wschnr@googlemail.com Received: by 10.37.9.80 with HTTP; Sat, 16 Dec 2017 08:49:53 -0800 (PST) In-Reply-To: References: <20171215120243.GB1179@albert.catwhisker.org> <20171215183928.GO2272@kib.kiev.ua> From: Wolfram Schneider Date: Sat, 16 Dec 2017 17:49:53 +0100 X-Google-Sender-Auth: j4bS5yZifqateXMef8hzOMlVhtg Message-ID: Subject: Re: /usr/obj is 11GB huge on FreeBSD 12-current To: Konstantin Belousov , Wolfram Schneider Cc: David Wolfskill , 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: Sat, 16 Dec 2017 16:50:10 -0000 On 15 December 2017 at 20:20, Wolfram Schneider wrote: > On 15 December 2017 at 19:39, Konstantin Belousov wrote: >> On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: >>> On 15 December 2017 at 17:51, Wolfram Schneider wrote: >>> > On 15 December 2017 at 13:02, David Wolfskill wrote: >>> >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >>> >>> Hi, >>> >>> >>> >>> I upgraded a machine from 11-stable to 12-current. The /usr/obj tree >>> >>> is now 11GB huge: >>> >>> >>> >>> FreeBSD 12-current >>> >>> $ du -hs /usr/obj >>> >>> 11G /usr/obj >>> >>> >>> >>> on FreeBSD 11-stable it was less the size: >>> >>> $ du -hs /usr/obj >>> >>> 5.6G /usr/obj >>> >>> >>> >>> this is a problem when you have a small VM with 20GB disk space or less. >>> >>> >>> >>> Is there a way to use less /usr/obj disk space during build? I know >>> >>> that we have to do some bootstrapping for newer compiler tools, but >>> >>> does we need to keep all temp files during the build? >>> >> >>> >> There was a change near the beginning of November; please see UPDATING >>> >> entry 20171101 -- you probably have several no-longer-used >>> >> subdirectories under /usr/obj/usr/src/. >>> >> >>> >> Once those are cleared out, my experience (tracking stable/11 & head in >>> >> different slices on the same machines) is that stbale/11 is using about >>> >> 5.0G, while head uses about 6.1G. >>> > >>> > I think the suspect directories are "tmp" and "obj-lib32", together >>> > they are 4.1GB huge. >>> > >>> > I will run a build of current again with a clean obj tree (-current on >>> > a recent -current). Let's see. >>> >>> I run a test on universe12b (FreeBSD 12.0-CURRENT #0 r325426: Sun Nov >>> 5) with an empty obj directory. >>> >>> `make buildworld' creates 9.7GB of obj data. After running `make >>> buildkernel' it will grow to 12GB. This is on a ZFS filesystem (my >>> original report was on UFS) >> >> Most likely reason of the bump is generation of debugging data, turned on >> for 12. Another not usable thing to disable are tests and profile libraries. >> Put the following into /etc/src.conf: >> WITHOUT_PROFILE=yes >> WITHOUT_DEBUG_FILES=yes >> WITHOUT_TESTS=yes > > Hi Konstantin, > > I tried these 3 variables and the results looks much better, down to > 5.1GB from 12GB. Many thanks! > > $ du -hs obj* > 12G obj-debug > 5.1G obj-nodebug I did another test which of the WITHOUT_* variables saves most of the space 5.5G obj-WITHOUT_DEBUG_FILES (6.5GB less) 10G obj-WITHOUT_LIB32 (2GB less) 11G obj-WITHOUT_PROFILE (1GB less) 12G obj-WITHOUT_TESTS if you are short on disk space (e.g. a small VM with SSD drive), you should compile with $ export WITHOUT_DEBUG_FILES=YES; make buildworld -Wolfram -- Wolfram Schneider https://wolfram.schneider.org From owner-freebsd-current@freebsd.org Sat Dec 16 17:05: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 EDE08E8889D for ; Sat, 16 Dec 2017 17:05:56 +0000 (UTC) (envelope-from lausts@acm.org) Received: from cdptpa-cmomta01.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B86B96B0BE for ; Sat, 16 Dec 2017 17:05:55 +0000 (UTC) (envelope-from lausts@acm.org) Received: from mail.laus.org ([65.29.112.189]) by cmsmtp with ESMTP id QFuEenOlocClJQFuGeocXm; Sat, 16 Dec 2017 17:05:49 +0000 Received: from [192.168.1.100] (presario [192.168.1.100]) by mail.laus.org (8.15.2/8.15.2) with ESMTPS id vBGH5j7U036899 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 16 Dec 2017 12:05:46 -0500 (EST) (envelope-from lausts@acm.org) X-Authentication-Warning: mail.laus.org: Host presario [192.168.1.100] claimed to be [192.168.1.100] Reply-To: lausts@acm.org Subject: Re: GPTZFSBOOT in Current r326622 has problems - FIXED To: Warner Losh Cc: FreeBSD Current References: From: Thomas Laus Message-ID: <79db33b4-c422-cc2c-d6ba-9192c783e3d5@acm.org> Date: Sat, 16 Dec 2017 12:05:45 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCJ7j8bRNsaUA5uQm5WOaX1isix+9OHN9c9xWZl8mDOKkbE//kAQUHzuJgMynip7zGyxh4zySLpmBqooUQdafLClsEyjeEozo0rDy1Fxzv0OHeZoMsQ4 tvGcXE7mcpttTz4YQt6HKxtXOrVR44iWU41sLqAVVKAbcDWqLZb3DJEBp3139zEU9CmSUEDP7B1t00ZkpUM36e9VEME/9hP1vIo= 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, 16 Dec 2017 17:05:57 -0000 On 12/15/17 18:37, Warner Losh wrote: > > I believe that these issues have been corrected in r326888. My > refactoring to make it easier to bring in the lua boot loader in r326593 > (after breaking the build in r326584 accidentally) uncovered some latent > subtle ordering issues. This cause GELI-enabled (but not even using) ZFS > boot loaders to fail. This was related to an odd interaction between zfs > and geli implementation files in gptzfsboot (and zfsboot) which caused > us to have two different implementations of malloc, with all the fun > you'd expect when the second one got called. > > If you have issues after r326888, please let me know. > Warner & Group I updated my system this morning to r326897 and can confirm that this problem has been solved. Good work Warner! Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Sat Dec 16 18:54:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2B1BE8B245 for ; Sat, 16 Dec 2017 18:54:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-104.reflexion.net [208.70.210.104]) (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 83E276E769 for ; Sat, 16 Dec 2017 18:54:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19077 invoked from network); 16 Dec 2017 18:47:51 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Dec 2017 18:47:51 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 16 Dec 2017 13:47:51 -0500 (EST) Received: (qmail 22848 invoked from network); 16 Dec 2017 18:47:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Dec 2017 18:47:51 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C2D4CEC7848; Sat, 16 Dec 2017 10:47:50 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: faq/troubleshoot.html#indefinite-wait-buffer has the direction of transfer wrong (head -r326888 /usr/src/) Message-Id: Date: Sat, 16 Dec 2017 10:47:50 -0800 To: FreeBSD Hackers , FreeBSD Current 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: Sat, 16 Dec 2017 18:54:38 -0000 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-buffer 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 page = attempt has hung trying to access the disk for more than 20 seconds. It = might 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 will appear in /var/log/messages and in the output of dmesg. = Otherwise, check the cables and connections. ENDQUOTE But the code containing the message is for "swread": (head -r326888) # grep -r "indefinite wait buffer" /usr/src/sys/ | more /usr/src/sys/vm/swap_pager.c:"swap_pager: indefinite wait buffer: = bufobj: %p, blkno: %jd, size: %ld\n", Looking there. . . static int swap_pager_getpages(vm_object_t object, vm_page_t *m, int count, int = *rbehind, int *rahead) { . . . VM_OBJECT_WLOCK(object); while ((m[0]->oflags & VPO_SWAPINPROG) !=3D 0) { m[0]->oflags |=3D VPO_SWAPSLEEP; VM_CNT_INC(v_intrans); if (VM_OBJECT_SLEEP(object, &object->paging_in_progress, = PSWP, "swread", hz * 20)) { printf( "swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: = %ld\n", bp->b_bufobj, (intmax_t)bp->b_blkno, = bp->b_bcount); } } . . . =3D=3D=3D Mark Millard markmi at dsl-only.net