On 08/21/2018 23:29, Manfred Antar wrote:
>
>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote:
>>
>> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:
>>> Перенаправленное сообщение
>>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
>>> Дата: Tue,
> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote:
>
> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:
>>
>> Перенаправленное сообщение
>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
>> Дата: Tue, 21 Aug 2018 16:41:42 +0700
>> От: Alex V.
On Aug 21, 2018, at 8:11 PM, Alan Somers wrote:
> The last time I looked (which was a long time ago), Oracle's ZFS encryption
> looked extremely vulnerable to watermarking attacks. Did anybody ever fix
> that?
This isn’t Oracle’s implementation, but I don’t know how compatible or not it
is
On 2018-08-21 23:16, Alan Somers wrote:
> On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote:
>
>> On Aug 21, 2018, at 8:11 PM, Alan Somers wrote:
>>> The last time I looked (which was a long time ago), Oracle's ZFS
>> encryption looked extremely vulnerable to watermarking attacks. Did
>>
On Tue, Aug 21, 2018 at 20:22 Alan Somers wrote:
> On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote:
>
>> On Aug 21, 2018, at 8:11 PM, Alan Somers wrote:
>> > The last time I looked (which was a long time ago), Oracle's ZFS
>> encryption looked extremely vulnerable to watermarking attacks.
On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote:
> On Aug 21, 2018, at 8:11 PM, Alan Somers wrote:
> > The last time I looked (which was a long time ago), Oracle's ZFS
> encryption looked extremely vulnerable to watermarking attacks. Did
> anybody ever fix that?
>
> This isn’t Oracle’s
The last time I looked (which was a long time ago), Oracle's ZFS encryption
looked extremely vulnerable to watermarking attacks. Did anybody ever fix
that?
-Alan
On Tue, Aug 21, 2018 at 8:28 PM Matthew Macy wrote:
> On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote:
>
> > To anyone with an
On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote:
> To anyone with an interest in native encryption in ZFS please test the
> projects/zfs-crypto-merge-0820 branch in my freebsd repo:
> https://github.com/mattmacy/networking.git
>
>
Oh and I neglected to state that this work is being supported
On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote:
>
> Перенаправленное сообщение
> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
> Дата: Tue, 21 Aug 2018 16:41:42 +0700
> От: Alex V. Petrov
> Кому: FreeBSD Ports
Should be fixed as of r477761.
Brooks Davis brooks at freebsd.org wrote on
Tue Aug 21 20:29:45 UTC 2018 :
> On Mon, Aug 20, 2018 at 07:33:32PM +0200, Dimitry Andric wrote:
> > . . .
> >
> > I have attached a patch for most of the llvm ports, which sets the
> > LLVM_PARALLEL_LINK_JOBS CMake flag during the configure phase.
>
To anyone with an interest in native encryption in ZFS please test the
projects/zfs-crypto-merge-0820 branch in my freebsd repo:
https://github.com/mattmacy/networking.git
( git clone https://github.com/mattmacy/networking.git -b
projects/zfs-crypto-merge-0820 )
The UI is quite close to the
Just in case anyone misses the change to UPDATING:
20180821:
drm and drm2 have been removed. Users on powerpc, 32-bit hardware,
or with GPUs predating Radeon and i915 will need to install the
graphics/drm-legacy-kmod. All other users should be able to use
one
bob prohaska fbsd at www.zefox.net wrote on
Wed Aug 22 00:48:33 UTC 2018 :
> On Mon, Aug 20, 2018 at 12:40:56PM -0700, Kirk McKusick wrote:
> > . . .
> >
> > To enable TRIM consolodation either use `sysctl vfs.ffs.dotrimcons=1'
> > or just set the `dotrimcons' variable in sys/ufs/ffs/ffs_alloc.c
On Tuesday, August 21, 2018 17:48:43 Bob Prohaska wrote:
> Will the new feature be active on a Raspberry Pi 3 using flash
> on microSD and USB for file systems and swap?
>
It will work on any UFS file system, as long as the underlying medium supports
TRIM. It will not work for swap because
On Mon, Aug 20, 2018 at 12:40:56PM -0700, Kirk McKusick wrote:
> I have recently added TRIM consolodation support for the UFS/FFS
> filesystem. This feature consolodates large numbers of TRIM commands
> into a much smaller number of commands covering larger blocks of
> disk space. Best described
Matthew Macy wrote:
[stuff snipped]
>I don't know what's special in this case, but I did revamp the locking there
>several >months back so I'll take a look next weekend.
Thanks but don't worry about it for now. I think I figured out how the panic()
occurred. If the nfsd was accessing
> And probably running ZFS, which ate all your memory and
> put you in a memory contrained environment.
That's exactly why I keep the following in my /boot/loader.rc:
# vfs.zfs.arc_max=1073741824
vfs.zfs.arc_max=2147483648
# vfs.zfs.arc_max=4294967296
On Mon, Aug 20, 2018 at 07:33:32PM +0200, Dimitry Andric wrote:
> On 20 Aug 2018, at 16:26, Rodney W. Grimes
> wrote:
> >
> >> On 20 Aug 2018, at 05:01, blubee blubeeme wrote:
> >>>
> >>> I am running current compiling LLVM60 and when it comes to linking
> >>> basically all the processes on
In my testing 338129 fixed the issue. Seems like the problem is that
bsd.crunchgen.mk iterates over all directories to do a make obj when
it does the bootstrap-tools phase.
On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
>
>
>
> On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
>>
>> On
Перенаправленное сообщение
Тема: nvidia-driver build error (last ports, FreeBSD-HEAD)
Дата: Tue, 21 Aug 2018 16:41:42 +0700
От: Alex V. Petrov
Кому: FreeBSD Ports
cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\"
-D__KERNEL__ -DNVRM -Wno-unused-function
I think relaxing the check to just avoid includes of "${SRCTOP}/sys" is
probably the best solution. It would be nice to also handle the
${.CURDIR}/../../sys case but since it's just there to prevent ABI issues
that's probably fine.
Alex
On Tue, 21 Aug 2018 at 15:19 Warner Losh wrote:
> On Tue,
On Tue, 21 Aug 2018 13:15:04 +
"Bjoern A. Zeeb" wrote:
...
> From the backtrace it seems like VNET_PCPUSTAT_SYSINIT() or the
> kernel linker, or possible pcpu things. People have recently been
> touching almost all of this :(
>
> Do you have a last-good revision?
Perhaps the PCPU area is
On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh wrote:
> There's a half a dozen special targets, however. clean comes to mind...
>
>
> However, this test is needlessly restrictive:
>
> .if !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:
> N*${SRCTOP}/sys/crypto*)
>
> since it matches
>
There's a half a dozen special targets, however. clean comes to mind...
However, this test is needlessly restrictive:
.if
!empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*)
since it matches
CFLAGS+=-I${SRCTOP}/sys/sys/disk
which is totally legit. It's
On Tue, Aug 21, 2018 at 7:49 AM, Warner Losh wrote:
>
>
> On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
>
>> On 8/20/18 9:00 PM, O. Hartmann wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA512
>> >
>> > Am Mon, 20 Aug 2018 21:24:21 +0200
>> > "O. Hartmann" schrieb:
>> >
>>
On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
> On 8/20/18 9:00 PM, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Am Mon, 20 Aug 2018 21:24:21 +0200
> > "O. Hartmann" schrieb:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >>
On 21 Aug 2018, at 12:31, Olivier Cochard-Labbé wrote:
On Tue, Aug 21, 2018 at 11:29 AM Marko Zec wrote:
On Mon, 20 Aug 2018 16:26:29 +0200
Olivier Cochard-Labbé wrote:
Just loading carp kernel module is enough to panic it:
[root@router]~# uname -a
FreeBSD router.bsdrp.net 12.0-ALPHA2
On Tue, Aug 21, 2018 at 11:29 AM Marko Zec wrote:
> On Mon, 20 Aug 2018 16:26:29 +0200
> Olivier Cochard-Labbé wrote:
>
> > Just loading carp kernel module is enough to panic it:
> >
> > [root@router]~# uname -a
> > FreeBSD router.bsdrp.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 r338100M
> > i386
On Mon, 20 Aug 2018 16:26:29 +0200
Olivier Cochard-Labbé wrote:
> Just loading carp kernel module is enough to panic it:
>
> [root@router]~# uname -a
> FreeBSD router.bsdrp.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 r338100M
> i386 [root@router]~# kldload carp
> Fatal trap 12: page fault while in
On 8/21/18 4:19 AM, Kyle Evans wrote:
> On Mon, Aug 20, 2018 at 4:27 PM, Brett Gmoser
> wrote:
>> Hi there,
>>
>> I was told to e-mail these addresses with this.
>>
>> I did an `svn update` on /usr/src last night, build world and kernel as
>> usual. This morning I installed the kernel, booted
On 8/20/18 9:00 PM, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Mon, 20 Aug 2018 21:24:21 +0200
> "O. Hartmann" schrieb:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Building NanoBSD world on CURRENT r338113 fails due to:
>>
>> [...]
>> cd
When I discovered that you were building debug versions
of devel/llvm60 that also meant that my Pine64+ 2GB
specifics do not make a useful comparison (do not
show how small an environment can be for a build).
Last I tried such a debug build was on a powerpc64
with 16 MiBytes RAM and it took
32 matches
Mail list logo
