Re: firefox/ rust failed to install on FreeBSD 12-CURRENT

[Jean-Sébastien Pédron]

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



signature.asc
Description: OpenPGP digital signature

Re: Boot CURRENT without efi

[Toomas Soome]

> 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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Time to increase MAXPHYS?

[Edward Tomasz Napierała]

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.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot CURRENT without efi

[Allan Jude]

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-unsubscr...@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



signature.asc
Description: OpenPGP digital signature

Boot CURRENT without efi

[Andy Neustadter]

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-unsubscr...@freebsd.org"

Re: Time to increase MAXPHYS?

[Kenneth D. Merry]

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
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 

Re: old syslog (jail) and new kernel = 100% CPU

[Ngie Cooper (yaneurabeya)]

> 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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: old syslog (jail) and new kernel = 100% CPU

[Bryan Drewery]

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



signature.asc
Description: OpenPGP digital signature

Re: old syslog (jail) and new kernel = 100% CPU

[Alexander Leidinger]

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?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp2kvZESRNjH.pgp
Description: Digitale PGP-Signatur

Re: [Help] Linux low level data structures < - > FreeBSD low level data structures

[Hans Petter Selasky]

Hi Mark,

Mandriva was a really god hint. Let's see how it goes:

https://issues.openmandriva.org/show_bug.cgi?id=2176

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"