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_at_freebsd.org To: freebsd-current_at_freebsd.org Send freebsd-current mailing list submissions to freebsd-current_at_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_at_freebsd.org You can reach the person managing the list at freebsd-current-owner_at_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 <bdrewery_at_FreeBSD.org> To: Alexander Leidinger <Alexander_at_leidinger.net> Cc: current_at_freebsd.org Subject: Re: old syslog (jail) and new kernel = 100% CPU Message-ID: <b0be1be3-4aa7-a768-6102-3c776f0537f6_at_FreeBSD.org> Content-Type: text/plain; charset="utf-8" On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > > Quoting Bryan Drewery <bryan_at_shatow.net> (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)" <yaneurabeya_at_gmail.com> To: Bryan Drewery <bdrewery_at_FreeBSD.org> Cc: Alexander Leidinger <Alexander_at_leidinger.net>, current_at_freebsd.org Subject: Re: old syslog (jail) and new kernel = 100% CPU Message-ID: <55114361-9212-49AE-A3FF-7691CADB2367_at_gmail.com> Content-Type: text/plain; charset="utf-8" > On Jun 5, 2017, at 08:20, Bryan Drewery <bdrewery_at_FreeBSD.org> wrote: > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: >> >> Quoting Bryan Drewery <bryan_at_shatow.net> (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" <ken_at_FreeBSD.ORG> To: Hans Petter Selasky <hps_at_selasky.org> Cc: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>, freebsd-current_at_freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170605160253.GA17376_at_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: <IBM ULTRIUM-HH5 G9N1> 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_at_FreeBSD.ORG ------------------------------ Message: 4 Date: Mon, 5 Jun 2017 13:31:10 -0400 From: Andy Neustadter <a.n.us_at_ieee.org> To: freebsd-current_at_freebsd.org Subject: Boot CURRENT without efi Message-ID: <CA+2zecwbqWawbR0Nf75Aqw04q8JzYimxrxqevMbhTAjCJXsmYg_at_mail.gmail.com> 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 <allanjude_at_freebsd.org> To: freebsd-current_at_freebsd.org Subject: Re: Boot CURRENT without efi Message-ID: <5040e292-aedd-2fe3-67e7-9b0e440fc662_at_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_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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 <trasz_at_FreeBSD.org> To: Hans Petter Selasky <hps_at_selasky.org> Cc: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>, freebsd-current_at_freebsd.org Subject: Re: Time to increase MAXPHYS? Message-ID: <20170605174930.GA6259_at_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 <tsoome_at_me.com> To: Andy Neustadter <a.n.us_at_ieee.org> Cc: freebsd-current_at_freebsd.org Subject: Re: Boot CURRENT without efi Message-ID: <A71EB96E-A404-442D-952C-DF6774CDC5C2_at_me.com> Content-Type: text/plain; charset=us-ascii > On 5. juuni 2017, at 20:31, Andy Neustadter <a.n.us_at_ieee.org> 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 <dumbbell_at_FreeBSD.org> To: Tim Kientzle <tim_at_kientzle.com> Cc: FreeBSD current <freebsd-current_at_freebsd.org> Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT Message-ID: <e449e1f8-19b0-04a8-f9a7-3eab1fe3657b_at_FreeBSD.org> 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_at_freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" ------------------------------ End of freebsd-current Digest, Vol 711, Issue 2 ***********************************************Received on Tue Jun 06 2017 - 10:18:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC