patch that makes max buffer cache block size tunable for review
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 "nfsstat -m". Anyone interested in reviewing and/or testing this, please do so, rick ___ 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: ino64 status update and upgrade caution
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 installation to abort if make installworld is attempted prior to the reboot into the new kernel. [6] https://svnweb.freebsd.org/changeset/base/319219 ___ 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: After ino64 update: devel/libunwind failure: cannot preempt symbol '_Ux86_64_local_addr_space' defined
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. > > > > The box in question is running FreeBSD 12.0-CURRENT #22 r319083: Sun May 28 > > 21:18:52 CEST 2017 amd64, WITH_LLD_IS_LD=yes set. > > What's the difference between this and the report in PR 219524? AFAICT > this is just a known issue with the libunwind port and LLD, and will > need a change in libunwind to fix. There is none, so far, it is due to WITH_LLD_IS_LD. 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. Kind regards, oh -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpsEiv7BjJRF.pgp Description: OpenPGP digital signature
Re: INO64 Effecting Firefox
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 firefox was very stable for work/personal daily use. The error I'm seeing is: Full message: TypeError: malformed UTF-8 character sequence at offset 0 Firefox does start and I can load a page or two before it sefaults. The full console output is here: https://gist.github.com/anonymous/555202b1452503ad9e26750168f87d5f Posting this here in the off chance that it's either related to ino64, or some other recent change has caused this problem. Just to close the loop on this. It looks like after upgrading to the latest official packages available i can now run Firefox w/o crashing. I am still getting the UTF-8 error mentioned above, but have not segfaulted yet. So apparently that error was a red herring. Interesting enough, firefox was *not* on the packages that was upgraded - so i assume a shared library was updated that trigger the fault. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: After ino64 update: devel/libunwind failure: cannot preempt symbol '_Ux86_64_local_addr_space' defined
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 believe libunwind should always fail with LLD. ___ 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"
