From owner-freebsd-current@freebsd.org Tue Jun 6 12:22: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 D285EB9440A for ; Tue, 6 Jun 2017 12:22:49 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::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 A0C8365CC3 for ; Tue, 6 Jun 2017 12:22:49 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-pg0-x22b.google.com with SMTP id v18so24531299pgb.1 for ; Tue, 06 Jun 2017 05:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MHwxV0HDnXd6Vhn9wy71Sp600gkPvLfzw34y6Pdv3tM=; b=b3U4jJf9EeqYxIiNfaq9PvEqVvxscXB1XQBOvdOHV4xuu9pSjFj5/FJMNjzCdh9/hx IZ5RK006us+NYm8ly0L7TAl90uGebr84cILTRp1W4FDjV4b0rIneS3Np336kO6LrnJd3 phgidKKxFpg7XuZo4iE7rs2h1t4BU0kTvqh5fOW1an6iFEoTthpz3MUMH3kQMy/4iQvG SaWV4kPMefFr0Md4HcOozrVp/YZTB8+ffBWi+2ahNCvi/aMvGJ4Svy+V/tQcCYHrikK1 vK88PMpv0WEJTlAwf303ysMovHCpCiHmJPNB4xGcJ8qFQQO/VALHiJeuHbv5DpGmTNSR DwAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MHwxV0HDnXd6Vhn9wy71Sp600gkPvLfzw34y6Pdv3tM=; b=nwAsGpYnnahMeJsCHaky1/4HMfavrkfsHDsJEPkQ5lUAic0EiudrTXydrT0sP7/eCh bEC7GpqDPCUhrC8+HyidLVdqeg/B5tF8E7NI5PAH9J5aZdxayO3dPem7vXaEqJWm8i2g ZXUU8amPUBDOkxMsiPh65xSNQHt06gg5y6hs1Q6fXTveqlhF6pE6X76esNXD11lRGC59 jHnXhdVrJou2MjgR0H4C8TK60fLQQO4qvo2bk3UMTiFnlLpbr7B12vqw4Z4DhS98bYSi nR+d3UU7ZpAWYQr82BXbHk19ghMeDsPfMycH3qFFPs99NlzfOs7OX/J5Q568aPkrR0ku CwOQ== X-Gm-Message-State: AODbwcCRr4uVn2ZPoAuv99TVjjV6gmrYyt3QJZri2AXuaq8vq1dTmbGg PIwZHpIVsLhNb3VJyGzQGwkQqgKJGQ== X-Received: by 10.98.163.25 with SMTP id s25mr24966800pfe.217.1496751768971; Tue, 06 Jun 2017 05:22:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: blubee blubeeme Date: Tue, 06 Jun 2017 12:22:38 +0000 Message-ID: Subject: Re: freebsd-current Digest, Vol 711, Issue 2 To: Brandon Kastning , "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 12:22:50 -0000 I was able to sort this out by installing rust from pkg. The pkg and ports version was the same when I did it a lil while ago. Try that, then running the Firefox build again. Best, Owen On Tue, Jun 6, 2017, 20:18 Brandon Kastning wrote: > FreeBSD 12-Current Community and Developers, > > Regarding Issue #8; I too am having issues. I removed Firefox because it > was randomly closing. And upon reinstall, I was receiving the python rust > build error. > > What is the proper syntax for a build with the "--format=ustar" ? > > I apologize if I am participating incorrectly. As I am new to the > community and unix. > > Best Regards, > > Brandon Kastning > AKA. StreetDancer (IRC & Forums) > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > -------- Original Message -------- > Subject: freebsd-current Digest, Vol 711, Issue 2 > Local Time: June 6, 2017 5:00 AM > UTC Time: June 6, 2017 12:00 PM > From: freebsd-current-request@freebsd.org > To: freebsd-current@freebsd.org > > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org > > You can reach the person managing the list at > freebsd-current-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > Today's Topics: > > 1. Re: old syslog (jail) and new kernel = 100% CPU (Bryan Drewery) > 2. Re: old syslog (jail) and new kernel = 100% CPU > (Ngie Cooper (yaneurabeya)) > 3. Re: Time to increase MAXPHYS? (Kenneth D. Merry) > 4. Boot CURRENT without efi (Andy Neustadter) > 5. Re: Boot CURRENT without efi (Allan Jude) > 6. Re: Time to increase MAXPHYS? (Edward Tomasz Napiera?a) > 7. Re: Boot CURRENT without efi (Toomas Soome) > 8. Re: firefox/ rust failed to install on FreeBSD 12-CURRENT > (Jean-S?bastien P?dron) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Jun 2017 08:20:47 -0700 > From: Bryan Drewery > To: Alexander Leidinger > Cc: current@freebsd.org > Subject: Re: old syslog (jail) and new kernel = 100% CPU > Message-ID: > Content-Type: text/plain; charset="utf-8" > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > > > > Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > > -0700): > > > >> On 6/4/17 5:09 AM, Alexander Leidinger wrote: > >>> Hi, > >>> > >>> new kernel (surely r318877 and later) and old syslog in a jail = NOK. > >>> > >> > >> What branch and revision is the syslogd? From my understanding the bug > >> exists in a head version of syslogd only, maybe MFC'd to stable/11, but > >> not released. If it was MFC'd we need to fix it before the 11.1 release. > > > > This was a syslogd from head for sure. > > > > So the issue was that for an intermediate period of time a bug was in > > syslogd in head which was causing this, and if I would have upgraded a > > system were the jail would have been head from before the or after the > > bug, then I wouldn't have noticed it? > > > > Yes, that's my understanding. So it's ultimately a non-issue for > releases since it is just a temporary issue on head. > > -- > Regards, > Bryan Drewery > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 473 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/6435eaef/attachment-0001.sig > > > > ------------------------------ > > Message: 2 > Date: Mon, 5 Jun 2017 08:53:50 -0700 > From: "Ngie Cooper (yaneurabeya)" > To: Bryan Drewery > Cc: Alexander Leidinger , current@freebsd.org > Subject: Re: old syslog (jail) and new kernel = 100% CPU > Message-ID: <55114361-9212-49AE-A3FF-7691CADB2367@gmail.com> > Content-Type: text/plain; charset="utf-8" > > > On Jun 5, 2017, at 08:20, Bryan Drewery wrote: > > > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > >> > >> Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > >> -0700): > >> > >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote: > >>>> Hi, > >>>> > >>>> new kernel (surely r318877 and later) and old syslog in a jail = NOK. > >>>> > >>> > >>> What branch and revision is the syslogd? From my understanding the bug > >>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but > >>> not released. If it was MFC'd we need to fix it before the 11.1 > release. > >> > >> This was a syslogd from head for sure. > >> > >> So the issue was that for an intermediate period of time a bug was in > >> syslogd in head which was causing this, and if I would have upgraded a > >> system were the jail would have been head from before the or after the > >> bug, then I wouldn't have noticed it? > >> > > > > Yes, that's my understanding. So it's ultimately a non-issue for > > releases since it is just a temporary issue on head. > > Yes. syslogd was refactored on ^/head. Some of the refactoring caused the > issue Alexander brought up. The changes were never backported though, so > the concern you had in the previous message isn?t something to be worried > about, since the code hasn?t seen the changes the ^/head copy has. > Cheers! > -Ngie > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 842 bytes > Desc: Message signed with OpenPGP using GPGMail > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/2630dac2/attachment-0001.sig > > > > ------------------------------ > > Message: 3 > Date: Mon, 5 Jun 2017 12:02:53 -0400 > From: "Kenneth D. Merry" > To: Hans Petter Selasky > Cc: Tomoaki AOKI , > freebsd-current@freebsd.org > Subject: Re: Time to increase MAXPHYS? > Message-ID: <20170605160253.GA17376@mithlond.kdm.org> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jun 04, 2017 at 09:52:36 +0200, Hans Petter Selasky wrote: > > On 06/04/17 09:39, Tomoaki AOKI wrote: > > > Hi > > > > > > One possibility would be to make it MD build-time OTIONS, > > > defaulting 1M on regular systems and 128k on smaller systems. > > > > > > Of course I guess making it a tunable (or sysctl) would be best, > > > though. > > > > > > > Hi, > > > > A tunable sysctl would be fine, but beware that commonly used firmware > > out there produced in the millions might hang in a non-recoverable way > > if you exceed their "internal limits". Conditionally lowering this > > definition is fine, but increasing it needs to be carefully verified. > > > > For example many USB devices are only tested with OS'es like Windows and > > MacOS and if these have any kind of limitation on the SCSI transfer > > sizes, it is very likely many devices out there do not support any > > larger transfer sizes either. > > I agree that I'd like to see a tunable. We've been using a MAXPHYS value > slightly larger than 1MB at Spectra for years with no problems, but then > again, we're only running on newer hardware. > > If we keep DFLTPHYS the same (64K) or come up with another constant that is > defined to 64K, the way the da(4) and sa(4) handle things will keep most > older controllers working properly. Here is what da(4) does: > > if (cpi.maxio == 0) > softc->maxio = DFLTPHYS; /* traditional default */ > else if (cpi.maxio > MAXPHYS) > softc->maxio = MAXPHYS; /* for safety */ > else > softc->maxio = cpi.maxio; > softc->disk->d_maxsize = softc->maxio; > > cpi is the XPT_PATH_INQ CCB. The maxio field was added later, so older, > unmodified drivers that haven't set the maxio field default to a 64K I/O > size. > > Drivers for some of the more common SAS and FC hardware set maxio to a > value that is correct for the hardware. (e.g. mpt(4), mps(4), mpr(4), > and isp(4) all set it correctly.) > > As Warner pointed out, the way ahci(4) works is that it sets its maximum > I/O size to MAXPHYS. The question is, does all AHCI hardware support > arbitrary transfer sizes? Is there a way to figure out what the hardware > supports, and if not, we should probably default it to 128K instead of > MAXPHYS. > > Tape drives are another related issue. Tape block sizes up to 1MB are > pretty common. LTFS allows for blocksizes up to 1MB. You can't currently > read a tape with a 1MB blocksize on FreeBSD without bumping MAXPHYS and > having a controller and tape drive that can handle the larger blocksize. > > The sa(4) driver has the same logic as the da(4) driver for limiting > transfer sizes to the smaller of MAXPHYS and cpi.maxio. > > The sa(4) driver gives the user some tools for figuring things out: > > {sm4u-1-mgmt:/root:!:1} mt status -v > Drive: sa0: Serial Number: 101500520A > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x58:LTO-5 variable 384607 enabled (0x1) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > Residual: 0 Reported File Number: 0 Reported Record Number: 0 > Flags: BOP > --------------------------------- > Tape I/O parameters: > Maximum I/O size allowed by driver and controller (maxio): 1048576 bytes > Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes > Maximum block size supported by tape drive and media (max_blk): 8388608 > bytes > Minimum block size supported by tape drive and media (min_blk): 1 bytes > Block granularity supported by tape drive and media (blk_gran): 0 bytes > Maximum possible I/O size (max_effective_iosize): 1048576 bytes > > On this particular FreeBSD/head machine, I have MAXPHYS set to 1MB. The > controller (isp(4)) supports ~5MB I/O sizes and the drive (IBM LTO-5) > supports ~8MB I/O, but MAXPHYS is set to 1MB, so that is the limit. > > I have considered changing the sa(4) driver to not use physio(9), and > instead use a custom allocator to allow reading and writing tapes with > blocksizes up to what the hardware (combination of tape drive and > controller) allows. I haven't gotten around to it yet, because bumping > MAXPHYS works well enough in most cases. It also has a nice side effect of > allowing unmapped I/O. > > The pass(4) driver limits I/O sizes in the same way as the da(4) and sa(4) > drivers for CCBs sent via the blocking (CAMIOCOMMAND) ioctl, but for CCBs > sent via the asynchronous API, the only limit is the controller (cpi.maxio) > limit. The latter is because the buffers for the asynchronous interface > are malloced. If it were possible to send arbitrary sized, unmapped S/G > lists, then we could convert the asynchronous pass(4) interface to do > unmapped I/O. > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG > > ------------------------------ > > Message: 4 > Date: Mon, 5 Jun 2017 13:31:10 -0400 > From: Andy Neustadter > To: freebsd-current@freebsd.org > Subject: Boot CURRENT without efi > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Hi: > > I have an older HP desktop that does not support USB boot or UEFI. Is > it possible to use this machine with 12-current using GPT? Any help > or pointers to info would be greatly appreciated. Thanks in advance. > > ------------------------------ > > Message: 5 > Date: Mon, 5 Jun 2017 13:53:20 -0400 > From: Allan Jude > To: freebsd-current@freebsd.org > Subject: Re: Boot CURRENT without efi > Message-ID: <5040e292-aedd-2fe3-67e7-9b0e440fc662@freebsd.org> > Content-Type: text/plain; charset="utf-8" > > On 2017-06-05 13:31, Andy Neustadter wrote: > > Hi: > > > > I have an older HP desktop that does not support USB boot or UEFI. Is > > it possible to use this machine with 12-current using GPT? Any help > > or pointers to info would be greatly appreciated. Thanks in advance. > > _______________________________________________ > > 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" > > > > If your BIOS does not actively interfere, then yes, you can boot from a > GPT partitioned disk in legacy mode, without UEFI. > > If it doesn't work, the installer still supports MBR. > > -- > Allan Jude > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 834 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/ab5d2bf6/attachment-0001.sig > > > > ------------------------------ > > Message: 6 > Date: Mon, 5 Jun 2017 18:49:30 +0100 > From: Edward Tomasz Napiera?a > To: Hans Petter Selasky > Cc: Tomoaki AOKI , > freebsd-current@freebsd.org > Subject: Re: Time to increase MAXPHYS? > Message-ID: <20170605174930.GA6259@brick> > Content-Type: text/plain; charset=us-ascii > > On 0604T0952, Hans Petter Selasky wrote: > > On 06/04/17 09:39, Tomoaki AOKI wrote: > > > Hi > > > > > > One possibility would be to make it MD build-time OTIONS, > > > defaulting 1M on regular systems and 128k on smaller systems. > > > > > > Of course I guess making it a tunable (or sysctl) would be best, > > > though. > > > > > > > Hi, > > > > A tunable sysctl would be fine, but beware that commonly used firmware > > out there produced in the millions might hang in a non-recoverable way > > if you exceed their "internal limits". Conditionally lowering this > > definition is fine, but increasing it needs to be carefully verified. > > > > For example many USB devices are only tested with OS'es like Windows and > > MacOS and if these have any kind of limitation on the SCSI transfer > > sizes, it is very likely many devices out there do not support any > > larger transfer sizes either. > > FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed > that both issue 1MB requests. I wouldn't be surprised if they avoided > doing that for older devices, depending on eg the SCSI version reported > by device. > > ------------------------------ > > Message: 7 > Date: Mon, 05 Jun 2017 20:34:33 +0300 > From: Toomas Soome > To: Andy Neustadter > Cc: freebsd-current@freebsd.org > Subject: Re: Boot CURRENT without efi > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On 5. juuni 2017, at 20:31, Andy Neustadter wrote: > > > > Hi: > > > > I have an older HP desktop that does not support USB boot or UEFI. Is > > it possible to use this machine with 12-current using GPT? Any help > > or pointers to info would be greatly appreciated. Thanks in advance. > > GPT does not require UEFI, BIOS boot will read the pmbr and should behave > just as with MBR partitioning. > > rgds, > toomas > > ------------------------------ > > Message: 8 > Date: Mon, 5 Jun 2017 23:31:22 +0200 > From: Jean-S?bastien P?dron > To: Tim Kientzle > Cc: FreeBSD current > Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT > Message-ID: > Content-Type: text/plain; charset="utf-8" > > On 03.06.2017 08:26, Tim Kientzle wrote: > > You could add --format=ustar to the existing command line; that > > would force bsdtar to use the older "ustar" format (without any > > extensions that might confuse Python's tar file module). > > Even better! Thank you :) > > >> This will use GNU tar instead of BSD tar to recreate the bootstrap and > >> GNU tar doesn't seem to produce sparse file entries in the archive. > > > > How ironic; using GNU tar in order to avoid having GNU sparse file > entries. ;-) > > Yes :) > > -- > Jean-S?bastien P?dron > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 963 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/88c1d566/attachment-0001.sig > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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" > > ------------------------------ > > End of freebsd-current Digest, Vol 711, Issue 2 > *********************************************** > _______________________________________________ > 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" >