Just fyi, rpc.lockd isn't NFS. It is a separate protocol Sun called NLM and
I didn't ever implement it for what I believed were good reasons.
Hopefully someone who works with the code can help.
Btw, if you don't the locks visible to multiple clients concurrently, you can
just do your mounts with "n
Hans Petter Selasky hps at selasky.org write on Sun Jun 4 16:09:25 UTC 2017:
> I recently found a
> piece of code in a header file, which works with GCC and causes a
> panic() when compiled with clang. I reported it to one of the Linux
> kernel team members and they didn't care about it. Even i
On 4/6/17 7:07 pm, blubee blubeeme wrote:
Hello
Is there anyone on either of these lists that have experience with both
linux low level data structures and their equivalents on FreeBSD?
For instance the linux header file:
which includes the header file:
Then looking at that file:
You
＠Hans
I've noticed these things about Linux. A lot of stuff relies on knowing
the internals of the data structures instead of working with the API but I
don't want to start all that stuff up.
The goal is to lift up FreeBSD w/o tearing down Linux and as u know needing
to be glued to the Linux data
Hi Owen,
The most comprehensive open-source wrappers for Linux kernel APIs in the
FreeBSD kernel is found at:
https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-next/sys/compat/linuxkpi
The most comprehensive open-source wrappers for Linux kernel APIs in
FreeBSD user-space is f
Hi Julian
My goals are to port the Linux graphics stack over to FreeBSD w/o relying
too heavily on the linuxkpi stuff. That's cool for a lot of use cases but
it just seems a bit too brittle.
It is a very large I understand the task will not be easy but I am willing
to do the work, even from scrat
> On 4. juuni 2017, at 15:28, Alexander Leidinger
> wrote:
>
> Hi,
>
> I have a zfsloader which hangs directly after "Booting". First I attributed
> it to maybe a bug in meta-mode/ccache + ino64 (easy assumption without
> knowing if ino64 is involved in zfsloader), but after ccache -C, remov
On Sat, Jun 03, 2017 at 11:49:01PM -0600, Warner Losh wrote:
> > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be
> > sure, especially on memory limited systems. Lots of hardware can't do this
> > big an I/O, and some drivers can't cope, even if the underlying hardware
>
On Sat, Jun 03, 2017 at 11:55:51PM -0400, Allan Jude wrote:
> On 2017-06-03 22:35, Julian Elischer wrote:
> > On 4/6/17 4:59 am, Colin Percival wrote:
> >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@
> >> wrote:
> >>> Add better support for larger I/O clusters, includin
It seems that {rpc.}lockd no longer runs after the ino64 changes on any
of my systems after a full rebuild of src and ports. No log entries
offer any insight as to why :-(
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org
Hi.
Possibly setting CPUTYPE in make.conf (or src.conf) can cause problem
for loaders.
I have below in make.conf. (amd64)
.if !${.CURDIR:M/usr/src/sys/boot*}
CPUTYPE?= corei7-avx
.endif
Additionally, for something above doesn't work:
.if ${.CURDIR:M/usr/ports/games/rubix}
CPUTYPE=
There is an array in aio.h sized on MAXPHYS as well.
A simpler possibility might be to leave MAXPHYS as a compile
time setting, but allow it to be set "per arch" and make it bigger
for amd64.
Good luck with it, rick
From: owner-freebsd-curr...@freebsd.org
Hi,
I have a zfsloader which hangs directly after "Booting". First I
attributed it to maybe a bug in meta-mode/ccache + ino64 (easy
assumption without knowing if ino64 is involved in zfsloader), but
after ccache -C, removing /usr/obj and running 2x "make cleanworld"
and 2x "make clean" be
Hi,
new kernel (surely r318877 and later) and old syslog in a jail = NOK.
I remember some mails about syslog going 100% COU some weeks ago, but
thought it was solved. As we have the goal to keep backward
compatibility, what is the issue here? I have this in the kernel:
---snip---
options
Hello
Is there anyone on either of these lists that have experience with both
linux low level data structures and their equivalents on FreeBSD?
For instance the linux header file:
which includes the header file:
Then looking at that file:
I'll be doing a lot of work trying to find these
Thanks a lot! I'll give it a shot in a bit.
Best,
Owen
On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI wrote:
> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
>
> But beware! Sometimes upstream changes make any of FreeBSD patches not
> applicable (incorporating any of these, inc
Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual.
But beware! Sometimes upstream changes make any of FreeBSD patches not
applicable (incorporating any of these, incompatible modifies, ...).
For 381.22, current patchset applies and builds fine for me.
On Sun, 04 Jun 2017 08:
On Sun, 4 Jun 2017 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 sysc
On Sat, Jun 03, 2017 at 11:28:23PM -0600, Warner Losh wrote:
> On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote:
>
> > On 2017-06-03 22:35, Julian Elischer wrote:
> > > On 4/6/17 4:59 am, Colin Percival wrote:
> > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@
> > >> w
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 comm
Hi.
Not in ports tree, but easily overridden by adding
DISTVERSION=381.22 -DNO_CHECKSUM
on make command line. Makefile of x11/nvidia-driver has a mechanism
to do so for someone requires newer version (newer GPU support, etc.).
If you're using portupgrade,
portupgrade -m 'DISTVERSION=381.22
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.
On Sat, 3 Jun 2017 23:49:01 -0600
Warner Losh wrote:
> On Sat, Jun 3, 2017 at 11:28 PM, Warner Lo
thanks for the two great pieces of advice.
Best,
Owen
On Sat, Jun 3, 2017 at 2:26 PM, Tim Kientzle wrote:
>
> > On Jun 1, 2017, at 11:37 PM, Jean-Sébastien Pédron
> wrote:
> >
> > On 28.05.2017 19:21, blubee blubeeme wrote:
> >> ===> Building for rust-1.17.0
> >> ...
> >> extracting
> >> ru
Hi @tomoaki
Is that version of nvidia drivers currently in the ports tree? I just
checked but it seems not to be.
@jeffrey
I just generated a new xorg based on the force composition setting. I
merged it with my previous xorg I'll reboot, see if it gives better
performance.
It seems like my system
24 matches
Mail list logo
