On 30 May 2017 at 12:49, O. Hartmann wrote:
>
> I got a kind of confused, since libunwind seemingly compiles on one box with
> both ino64
> AND WITH_LLD_IS_LD, while it failed after an update of a bunch of systems
> towards ino64.
So was this just confusion over what was actually built? I belie
On 05/28/2017 08:54, Pete Wright wrote:
Hi all,
I can't imagine that this is related to INO64, but since upgrading my
world and kernel on drm-next (which merged upstream CURRENT as of May
27 which should include the ino64 work) I am having segfaults running
firefox. Previous to this firefo
Am Mon, 29 May 2017 14:45:16 -0400
Ed Maste schrieb:
> On 29 May 2017 at 04:59, O. Hartmann wrote:
> > After updating several boxes running CURRENT after introduction of ino64, I
> > have one box which persitently rejects compiling and installing
> > devel/libunwind, as you can finde below.
> >
On 29 May 2017 at 10:49, Ed Maste wrote:
> The ino64 project was committed to src last week[1][2] with
> UPDATING notes added shortly thereafter [3][4][5].
I've now added an anti-foot-shooting test[6] which invokes the new
rescue binary prior to proceeding with installworld. This should cause
the
Hi,
I just put a patch here:
https://reviews.freebsd.org/D10991
that makes the maximum size of a buffer cache block a tunable.
This allows the NFS client to use larger I/O sized RPCs.
By default, the NFS client will use the largest I/O size possible.
What is actually in use can be checked via "nf
