Quoting Rick Macklem (from Tue, 4 Jan 2022
03:18:36 +):
Konstantin Belousov wrote:
[good stuff snipped]
The v4 NFS is very different from v3, it is not an upgrade, it is rather
a different network filesystem with some (significant) similarities to v3.
That said, it should be fine changi
Hi,
Currently, mount_nfs will attempt to use NFSv3 and fallback to NFSv2.
The manual page says:
nfsv2 Use the NFS Version 2 protocol (the default is to try
version 3 first then version 2). Note that NFS version 2
has a file size limit of 2 gigabytes.
And the
On 2021-Dec-31, at 18:18, Mark Millard wrote:
> On 2021-Dec-31, at 17:46, Mark Millard wrote:
>
>> On 2021-Dec-31, at 15:04, John Baldwin wrote:
>>
>>> On 12/31/21 2:59 PM, Mark Millard wrote:
On 2021-Dec-31, at 14:28, Mark Millard wrote:
> On 2021-Dec-30, at 14:04, John Baldwin
On 2021-Dec-31, at 17:46, Mark Millard wrote:
> On 2021-Dec-31, at 15:04, John Baldwin wrote:
>
>> On 12/31/21 2:59 PM, Mark Millard wrote:
>>> On 2021-Dec-31, at 14:28, Mark Millard wrote:
On 2021-Dec-30, at 14:04, John Baldwin wrote:
> On 12/30/21 1:09 PM, Mark Millard wrote:
On 2021-Dec-31, at 15:04, John Baldwin wrote:
> On 12/31/21 2:59 PM, Mark Millard wrote:
>> On 2021-Dec-31, at 14:28, Mark Millard wrote:
>>> On 2021-Dec-30, at 14:04, John Baldwin wrote:
>>>
On 12/30/21 1:09 PM, Mark Millard wrote:
> On 2021-Dec-30, at 13:05, Mark Millard wrote:
On 2021-Dec-31, at 14:28, Mark Millard wrote:
> On 2021-Dec-30, at 14:04, John Baldwin wrote:
>
>> On 12/30/21 1:09 PM, Mark Millard wrote:
>>> On 2021-Dec-30, at 13:05, Mark Millard wrote:
This asks a question in a different direction that my prior
reports about my builds vs. Cy's r
On 2021-Dec-30, at 14:04, John Baldwin wrote:
> On 12/30/21 1:09 PM, Mark Millard wrote:
>> On 2021-Dec-30, at 13:05, Mark Millard wrote:
>>> This asks a question in a different direction that my prior
>>> reports about my builds vs. Cy's reported build.
>>>
>>> Background:
>>>
>>> /usr/obj
On 2021-Dec-30, at 19:15, Mark Millard wrote:
>
>> On 2021-Dec-30, at 15:14, Cy Schubert wrote:
>>
>> In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard
>> write
>> s:
>>> On 2021-Dec-30, at 11:52, Mark Millard wrote:
>> . . .
>> It was a NO_CLEAN build. A CLEAN build r
On 2021-Dec-30, at 13:27, Mark Millard wrote:
>> Dear all,
>>
>> on a system updated yesterday I get
>>
>> tuexen_at_head:~/freebsd-src % git branch
>> * main
>> tuexen_at_head:~/freebsd-src % git pull
>> Already up to date.
>> tuexen_at_head:~/freebsd-src % uname -a
>> FreeBSD head 14.0-CURREN
> On 2021-Dec-30, at 15:14, Cy Schubert wrote:
>
> In message <3140c5f6-495f-441c-aa6b-542f3bc53...@yahoo.com>, Mark Millard
> write
> s:
>> On 2021-Dec-30, at 11:52, Mark Millard wrote:
>>
This commit results in a different error.
ld: error: /export/obj/opt/src/git-src/amd64.a
> Dear all,
>
> on a system updated yesterday I get
>
> tuexen_at_head:~/freebsd-src % git branch
> * main
> tuexen_at_head:~/freebsd-src % git pull
> Already up to date.
> tuexen_at_head:~/freebsd-src % uname -a
> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd:
> Thu
On 2021-Dec-30, at 13:05, Mark Millard wrote:
> This asks a question in a different direction that my prior
> reports about my builds vs. Cy's reported build.
>
> Background:
>
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
> ( /lib/libc++.so.1
This asks a question in a different direction that my prior
reports about my builds vs. Cy's reported build.
Background:
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
( /lib/libc++.so.1 /usr/lib/libcxxrt.so
and:
lrwxr-xr-x 1 root wheel23 De
On 2021-Dec-30, at 11:52, Mark Millard wrote:
>> This commit results in a different error.
>>
>> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:
>> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64.am
>> d64/tmp
> GROUP ( /usr/lib/libc++.s
> This commit results in a different error.
>
> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64.am
> d64/tmp
> >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
> >>> ^
> c++: err
Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing
and rebooting did not put in place a /lib/libc++.so.1 but
delete-old-libs removed the /usr/lib/libc++.so.1 .
(Luckily my environment has sufficient recent near-redundancy
to recover easily by putting in place a /usr/lib/libc++.so.1 .)
In order to avoid the following for WITH_ASAN= WITH_UBSAN= (both used),
so also WITH_LLVM_BINUTILS= in use:
--- all_subdir_usr.bin/clang ---
--- llvm-as.full ---
ld: error: undefined symbol: compressBound
>>> referenced by Compression.cpp:51
>>> (/usr/main-src/contrib/llvm-project/llvm/lib/Suppor
Timecounter "TSC" frequency 701570048 Hz quality 800
.. but before initializing ipfw as it used to,
Michael
On 12/21/21 12:01, Michael Butler via freebsd-current wrote:
I have an old pentium-3 that also won't boot kernels built after Dec 6th.
I suspect the commits l
I have an old pentium-3 that also won't boot kernels built after Dec 6th.
I suspect the commits listed below but, with the device being remote and
having no DRAC, I'm struggling to test this theory.
The relevant commits ..
commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston
On 2021-Dec-18, at 09:30, Ed Maste wrote:
> On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote:
>>
>> I'm confused, beyond just LGPL claims in the (fairly
>> current) source code, but GPL more generally:
>>
>> # grep -rl "SPDX.*GPL" /usr/main-src/
>
> You need to exclude the ones with SPDX tags
From: Ed Maste wrote on
Date: Fri, 17 Dec 2021 08:42:49 -0500 :
> On Fri, 17 Dec 2021 at 05:12, Baptiste Daroussin wrote:
> >
> > > -gnu Various commands and libraries under the GNU Public License.
> > > - Please see gnu/COPYING* for more information.
> > > +gnu Var
Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for
readability):
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-
From: FreeBSD User wrote on
Date: Wed, 15 Dec 2021 18:55:09 +0100 :
> . . .
>
> It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole
> box even if
> the essential operating system stuff is isolated on a dedicated UFS
> filesystem.
I would guess that, for ZFS being in u
thing like this will improve things.
if (0 == print "test\015\012") {
return;
}
Regards and happy hacking,
Ronald.
PS: I think this does not have to do a lot with freebsd-current. Might move it
to https://lists.freebsd.org/subscription/freebsd-perl or some
uot; and "man 2 socket" for a lot more information.
So it depends a bit on the type of socket you created.
Regards and happy hacking,
Ronald.
Van: Piper H
Datum: woensdag, 15 december 2021 07:52
Aan: freebsd-current@freebsd.org
Onderwerp: question on socket server
Hello
I have litt
se to have a match: it was not obvious from my
background knowledge.
(From what you have reported, I'd not expect stable/* or
main to have such links.)
Thanks for the information. I know better what to do now.
>>> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
&g
at would have the final
version?
> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
>> I just noticed that main reports that my pools were created
>> implicitly matching openzfs-2.1-freebsd (and without
>> an explicit compatibility assignment) but, under main, zp
On 2021-Dec-14, at 16:36, Mark Millard wrote:
> I just noticed that main reports that my pools were created
> implicitly matching openzfs-2.1-freebsd (and without
> an explicit compatibility assignment) but, under main, zpool
> import and zpool status for those pools report a new, disabled
> feat
I just noticed that main reports that my pools were created
implicitly matching openzfs-2.1-freebsd (and without
an explicit compatibility assignment) but, under main, zpool
import and zpool status for those pools report a new, disabled
feature. Turns out the issue matches what the diff below shows
> On 9. Dec 2021, at 20:54, Sergey Dyatko wrote:
>
> tiger@dl:~ % gpart show
>
> |
> =>40 3907029088 da4 GPT (1.8T)
> 4010241 freebsd-boot (512K)
>1064 984 - free - (492K)
>2048 3907026944
> On 17 Nov 2021, at 09:00, Marcin Wojtas wrote:
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.
Firstly, thank your for your efforts here, it is appreciated :)
I am finding that the lang/sdcc port is crash
> On 25 Nov 2021, at 18:50, FreeBSD User wrote:
>
> Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov
> 22 18:17:54
> CET 2021 amd64) troubles me with our DNS server/service.
> Aproximately the same time we switched on CURRENT to the CURRENT LLVM13
> version and als
> On 9. Dec 2021, at 20:06, Sergey Dyatko wrote:
>
> I was sure the installer did it when I reinstalled the system from scratch. I
> can load 14-current successfully after boot via PXE and installworld with
> 13-current
> now I did the following:
> 1) boot from HDDs FreeBSD 14.0-CURRENT #0 mai
[ Note: w...@freebsd.org is only a guess, based on:
https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html
]
Attempting to update to:
main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021
resulted in boot failure (showing some boot -v output):
. . .
mmc0: Pro
As of my update to (some line splitting applied):
# uname -apKU
FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aar
On 2021-Dec-6, at 14:19, Mark Millard wrote:
> This broke building lang/gcc11 so may be a exp run is appropriate:
>
> In file included from /usr/include/sys/cpuset.h:39,
> from /usr/include/sched.h:36,
> from /usr/include/pthread.h:48,
> from
> /w
This broke building lang/gcc11 so may be a exp run is appropriate:
In file included from /usr/include/sys/cpuset.h:39,
from /usr/include/sched.h:36,
from /usr/include/pthread.h:48,
from
/wrkdirs/usr/ports/lang/gcc11/work/gcc-11.2.0/gcc/jit/libgcc
> dropping https://github.com/DankBSD/ports/commit/56cb9dc72 and
Err, the right commit: https://github.com/DankBSD/base/commit/52ff26f21
> It appears that your build environment does not have the b366ee486 version
> of /usr/src/sys/ufs/ffs/fs.h installed in /usr/include/ufs/ffs/fs.h.
>
> That would normally happen after your did a buildworld and installworld.
> You should be able to fix your current compile failure by doing:
>
>
I was updating from
commit 20aa359773befc8182f6b5dcb5aad7390cab6c26
Author: Dimitry Andric
Date: Sat Nov 13 21:02:29 2021 +0100
Bump __FreeBSD_version for llvm-project 13.0.0 merge
PR: 258209
MFC after: 2 weeks
to
commit b366ee4868bca2b3ebe4bb29c9590a29b6cecc29
/usr/obj/DESTDIRs/main-amd64-poud/ is a buildworld installation
for poudriere-devel use that I've been updating on occasion for
a while.
Despite:
>>> Checking for old files
>>> Checking for old libraries
>>> Checking for old directories
To remove old files and directories run 'make delete-old'.
T
On 11/29/21 06:22, Jamie Landeg-Jones wrote:
> Dennis Clarke via freebsd-current wrote:
>
>> europa# xz -dc /var/backups/pkg.sql.xz.3 > /var/db/pkg/local.sqlite.dump
>>
>> europa#
>> europa# pkg backup -r /var/db/pkg/local.sqlite.dump
>> Restoring data
I had another kernel panic on an AMD64 server. This has resulted in the
pkg database being messed up. Also I was running a QEMU instance for
aarch64 and that ended up with a messed up pkg database also.
I saw some docs in section 4.4.8. Restoring the Package Database here:
https://docs.free
On 11/22/21 12:55 PM, Warner Losh wrote:
On Mon, Nov 22, 2021 at 10:51 AM Chuck Tuffli wrote:
On Mon, Nov 22, 2021 at 9:34 AM Chris wrote:
On 2021-11-22 08:47, Chuck Tuffli wrote:
Running on a recent-ish -current
# uname -a
FreeBSD stargate.tuffli.net 14.0-CURRENT FreeBSD 14.0-CURRENT
ma
On 2021-Nov-21, at 07:50, Mark Millard wrote:
> On 2021-Nov-20, at 11:54, Mark Millard wrote:
>
>> On 2021-Nov-19, at 22:20, Mark Millard wrote:
>>
>>> On 2021-Nov-18, at 12:15, Mark Millard wrote:
>>>
On 2021-Nov-17, at 11:17, Mark Millard wrote:
> On 2021-Nov-15, at 15:43,
On 2021-Nov-20, at 11:54, Mark Millard wrote:
> On 2021-Nov-19, at 22:20, Mark Millard wrote:
>
>> On 2021-Nov-18, at 12:15, Mark Millard wrote:
>>
>>> On 2021-Nov-17, at 11:17, Mark Millard wrote:
>>>
On 2021-Nov-15, at 15:43, Mark Millard wrote:
> On 2021-Nov-15, at 13:
I've seen it on an arm64 system:
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
do_el1h_sync() at do_el1h_sync+0x184
handle_el1h_sync() at handle_el1h_sync+0x78
--- exception, esr 0x20
On 2021-Nov-19, at 22:20, Mark Millard wrote:
> On 2021-Nov-18, at 12:15, Mark Millard wrote:
>
>> On 2021-Nov-17, at 11:17, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 15:43, Mark Millard wrote:
>>>
On 2021-Nov-15, at 13:13, Mark Millard wrote:
> On 2021-Nov-15, at 12:51,
On 2021-Nov-18, at 12:15, Mark Millard wrote:
> On 2021-Nov-17, at 11:17, Mark Millard wrote:
>
>> On 2021-Nov-15, at 15:43, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 13:13, Mark Millard wrote:
>>>
On 2021-Nov-15, at 12:51, Mark Millard wrote:
> On 2021-Nov-15, at 11:31,
On 2021-Nov-13, at 03:40, Mark Millard wrote:
> On 2021-Nov-13, at 03:20, Mark Millard wrote:
>
>
>> While attempting to see if I could repeat a bugzilla report in a
>> somewhat different context, I has the system hang up to the
>> point that ^C and ^Z did not work and ^T did not echo out what
On 2021-Nov-18, at 15:54, Mark Millard wrote:
> The ThreadRipper 1950X FreeBSD system is reporting a message at
> 03:01:10 or so for the last 3 days. The .148 is a aarch64 system
> (HoneyComb). None of the other systems (aarch64 Small Board
> Computers and a armv7 SBC) are reporting such.
>
> No
The ThreadRipper 1950X FreeBSD system is reporting a message at
03:01:10 or so for the last 3 days. The .148 is a aarch64 system
(HoneyComb). None of the other systems (aarch64 Small Board
Computers and a armv7 SBC) are reporting such.
Nov 16 03:01:10 amd64_ZFS kernel: newnfs: server '192.168.1.14
> On 2021-Nov-18, at 12:31, tue...@freebsd.org wrote:
>
>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current
>> wrote:
>>
>> I've not noticed the ertt message before in:
>>
>> . . .
>> Waiting (max 60 seconds) for system thr
On 2021-Nov-17, at 11:17, Mark Millard wrote:
> On 2021-Nov-15, at 15:43, Mark Millard wrote:
>
>> On 2021-Nov-15, at 13:13, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>>>
On 2021-Nov-15, at 11:31, Mark Millard wrote:
> I updated from (shown a s
I've not noticed the ertt message before in:
. . .
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done
All buffers synced.
Uptime: 1d9h57m18s
Khelp module "ertt" can't unload until its refcount drops from 1 to 0.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net wen
On 2021-Nov-15, at 15:43, Mark Millard wrote:
> On 2021-Nov-15, at 13:13, Mark Millard wrote:
>
>> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>>
>>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>>
I updated from (shown a system that I've not updated yet):
# uname -apKU
9:35 PM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:
Haven't had time to identify which change caused this yet but I now get ..
===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===>
Haven't had time to identify which change caused this yet but I now get ..
===> lib/libsbuf (obj,all,install)
===> cddl/lib/libumem (obj,all,install)
===> cddl/lib/libnvpair (obj,all,install)
===> cddl/lib/libavl (obj,all,install)
ld: error: /usr/obj/usr/src/i386.i386/tmp/usr/lib/libspl.a(assert.
On 2021-Nov-15, at 13:13, Mark Millard wrote:
> On 2021-Nov-15, at 12:51, Mark Millard wrote:
>
>> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>>
>>> I updated from (shown a system that I've not updated yet):
>>>
>>> # uname -apKU
>>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURR
On 2021-Nov-15, at 12:51, Mark Millard wrote:
> On 2021-Nov-15, at 11:31, Mark Millard wrote:
>
>> I updated from (shown a system that I've not updated yet):
>>
>> # uname -apKU
>> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
>> main-n250455-890cae197737-dirty: Thu Nov 4 13:43
On 2021-Nov-15, at 11:31, Mark Millard wrote:
> I updated from (shown a system that I've not updated yet):
>
> # uname -apKU
> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
> main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs
I updated from (shown a system that I've not updated yet):
# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #18
main-n250455-890cae197737-dirty: Thu Nov 4 13:43:17 PDT 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-N
In my update sequence to install FreeBSD with the clang 13
related materials, the first -j32 installworld attempt got:
. . .
--- realinstall_subdir_lib/libc/tests/hash ---
install -o root -g wheel -m 444
/usr/main-src/contrib/netbsd-tests/lib/libc/hash/data/md5test-out
/usr/tests/lib/libc/has
On 2021-Nov-13, at 03:20, Mark Millard wrote:
> While attempting to see if I could repeat a bugzilla report in a
> somewhat different context, I has the system hang up to the
> point that ^C and ^Z did not work and ^T did not echo out what
> would be expected for poudriere (or even the kernel
While attempting to see if I could repeat a bugzilla report in a
somewhat different context, I has the system hang up to the
point that ^C and ^Z did not work and ^T did not echo out what
would be expected for poudriere (or even the kernel backtrace).
I was able to escape to ddb.
The context was
I confirm, the attached patch fixes ports mentioned in my previous mail.
Ports graphics/cairo, multimedia/ffmpeg, www/firefox are also affected.
On November 2, 2021 5:16:35 PM GMT+03:00, Michael Butler via freebsd-current
wrote:
>On current as of this morning (I haven't tried to bisect yet) ..
>
> .. with either graphics/drm-devel-kmod or graphics/drm-current-kmod,
>trying to start a VirtualBox VM triggers this
On current as of this morning (I haven't tried to bisect yet) ..
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
14.0-CURRENT #42 main-a670e1c13a: Tue Nov 2 09:29:28 EDT 2021
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
amd64
.. with eit
On 2021-Oct-27, at 15:21, Mark Millard wrote:
> Unfortunately(?) this update added the .so.10 to mk/OptionalObsoleteFiles.inc
> :
>
> diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
> b/tools/build/mk/OptionalObsoleteFiles.inc
> index a8b0329104c4..91822aac492a 100644
> --- a/tools/bu
Unfortunately(?) this update added the .so.10 to mk/OptionalObsoleteFiles.inc :
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index a8b0329104c4..91822aac492a 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObso
But kernel failed to install. I will include log tomorrow, I'm doing a
clean build with /usr/obj/.. deleted.
Michael Butler via freebsd-current <mailto:freebsd-current@freebsd.org>> escreveu no dia quinta, 21/10/2021
à(s) 20:14:
Well this is different .. I did a full rebu
e the changes, there by not matching
old programs built under releng/13.0 or stable/13 .
Turns out that this explains the crashes I get when I attempt
to use a releng/13 based dialog4ports under main [so: 14]. For
a particular example, see:
https://lists.freebsd.org/archives/freebsd-current/2021-Oc
On 2021-Oct-21, at 16:24, Mark Millard wrote:
> On 2021-Oct-21, at 11:53, Mark Millard wrote:
>
>> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>>
>>> On Thu, 21 Oct 2021 07:40:36 -0700
>>> Mark Millard via freebsd-current wrote:
>>>
&g
On 2021-Oct-21, at 11:53, Mark Millard wrote:
> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>
>> On Thu, 21 Oct 2021 07:40:36 -0700
>> Mark Millard via freebsd-current wrote:
>>
>>>
>>>
>>> On 2021-Oct-21, at 06:14, Gary Jennejohn
Well this is different .. I did a full rebuild (after "rm -rf
/usr/obj/*") this morning and now see ..
===> linux_common (install)
install -T release -o root -g wheel -m 555 linux_common.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555 linux_common.ko.debug
/usr/lib/debug/boot/kernel
On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
> On Thu, 21 Oct 2021 07:40:36 -0700
> Mark Millard via freebsd-current wrote:
>
>>
>>
>> On 2021-Oct-21, at 06:14, Gary Jennejohn wrote:
>>
>>> On Thu, 21 Oct 2021 01:34:47 -0700
>>> Mark
On 2021-Oct-21, at 06:14, Gary Jennejohn wrote:
> On Thu, 21 Oct 2021 01:34:47 -0700
> Mark Millard via freebsd-current wrote:
>
>> I get the following crash (amd64 example shown), as reported
>> via gdb afterwards. (devel/llvm13 is just an example context.)
>>
I get the following crash (amd64 example shown), as reported
via gdb afterwards. (devel/llvm13 is just an example context.)
gdb `which dialog4ports` devel/llvm13/dialog4ports.core
. . .
Core was generated by `/usr/local/bin/dialog4ports'.
Program terminated with signal SIGSEGV, Segmentation fault.
On 12/10/21 14:21, Gary Jennejohn wrote:
On Tue, 12 Oct 2021 06:59:00 -0400
grarpamp wrote:
No. The system shell is supposed to make the system usable
by the users. Actually, the real problem is that the easiest way
to shoot one's own foot is by changing the language (say, the
shell) spoken by
red *active_cred __unused, struct thread *td __unused)
+#endif
{
/* XXX need to define flags for st_mode */
On 10/11/21, Michael Butler via freebsd-current
wrote:
After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..
--- dma-bu
After the latest freebsd version bump in param.h, I tried to rebuild the
DRM modules. It failed with ..
--- dma-buf.o ---
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1:
error: conflicting types for 'dma_buf_stat'
dma_buf_stat(struct file *fp, s
On 10-10-2021 07:57, Rick Macklem wrote:
This leads me to a couple of questions:
- Is there a good reason for not using vop_stdallocate() for ZFS?
Yes. posix_fallocate is supposed to guarantee that subsequent writes
to the file will not fail with ENOSPC. But ZFS, being a copy-on-write
file s
On 10/7/21 20:19, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:
On 10/7/21 16:52, Mark Johnston wrote:
On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
wrote:
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07
On 10/7/21 16:52, Mark Johnston wrote:
On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
wrote:
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
While building a local release bundle
On 10/7/21 15:39, Konstantin Belousov wrote:
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
While building a local release bundle, I sometimes get bsdtar failing (and
dumping core) as follows below. Worse, as can be seen below, it doesn't stop
the
While building a local release bundle, I sometimes get bsdtar failing
(and dumping core) as follows below. Worse, as can be seen below, it
doesn't stop the build unless I happen to notice and it yields an
incomplete package.
a usr/src/sys/netgraph/ng_checksum.h
a usr/src/sys/netgraph/ng_messag
On 2021-Sep-25, at 23:25, Mark Millard wrote:
> I get odd time reports from poudriere on an armv7 under main [so: 14]:
>
>
>
> # poudriere bulk -jmain-CA7 lang/rust
> [00:00:00] Creating the reference jail... done
> . . .
> [00:00:00] Balancing pool
> [main-CA7-default] [2021-09-25_23h11m13s]
Will history/completion continue to work the same way? (for example
typing part of the command, pressing UP and having it complete based on
history)
On 9/22/2021 4:36 AM, Baptiste Daroussin wrote:
Hello,
TL;DR: this is not a proposal to deorbit csh from base!!!
For years now, csh is the defa
On 2021-Sep-16, at 16:27, Freddie Cash wrote:
>
> [message chopped and butchered, don't follow the quotes, it's just to show
> some bits together from different messages]
>
> On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current
> wrote:
> >
On 2021-Sep-16, at 15:16, Alan Somers wrote:
> On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote:
>
>
> On 2021-Sep-16, at 13:39, Alan Somers wrote:
>
> > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current
> > wrote:
> > What do I go
> j...@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
>
>
>> On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current
>> wrote:
>>
>> What do I go about:
>>
>> QUOTE
>> # zpool import
>> pool:
On 2021-Sep-16, at 13:39, Alan Somers wrote:
> On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current
> wrote:
> What do I go about:
>
> QUOTE
> # zpool import
>pool: zopt0
> id: 18166787938870325966
> state: FAULTED
> status: One or m
On 2021-Sep-16, at 13:01, Mark Millard wrote:
> What do I go about:
>
> QUOTE
> # zpool import
> pool: zopt0
> id: 18166787938870325966
> state: FAULTED
> status: One or more devices contains corrupted data.
> action: The pool cannot be imported due to damaged devices or data.
> see: ht
What do I go about:
QUOTE
# zpool import
pool: zopt0
id: 18166787938870325966
state: FAULTED
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E
config:
After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to
recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set.
For example ..
imb@vm01:/home/imb> date
Tue Sep 14 01:25:57 2021
Every other daemon also thinks it's running in UTC+0 :-(
When libc is recompiled with
On 14/09/21 00:12, Konstantin Belousov wrote:
On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote:
On 13/09/21 19:08, Konstantin Belousov wrote:
On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote:
Hi,
I updated head recently and today I noticed a
On 13/09/21 19:08, Konstantin Belousov wrote:
On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote:
Hi,
I updated head recently and today I noticed a difference which looks wrong.
At boodt the new head shows signifcantly less avail memory than before,
around 3 GiB
On 13/09/21 20:17, Ryan Stone wrote:
On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current
wrote:
I'm not sure how to get the verbose data for the old boot, since I've
been unable to revert the machine to the old state. I'll try anyway though.
Do you have physica
On 13/09/21 19:08, Konstantin Belousov wrote:
On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote:
Hi,
I updated head recently and today I noticed a difference which looks wrong.
At boodt the new head shows signifcantly less avail memory than before,
around 3 GiB
1 - 100 of 345 matches
Mail list logo
