last weekend.
>
> A possible candidate could be
>
> https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=0fc7bdc978366abb4351b0b76b50a5848cc5d982
>
> since the other, younger, seem innocent. I try to revert the patch mentioned
> and see ...
Try to only revert the ip_fw_nat.c part at first.
—
Juraj Lutter
o...@freebsd.org
ork.
>
> Scp also seems to work fine if I replace the statefull firewall rules with
> stateless "pass all from any to any".
Have you tried to allow ICMP in both directions explicitly, in case of stateful
rules?
—
Juraj Lutter
o...@freebsd.org
pools vanish
> unless I import them and deal with them one by one.
>
Are there any differences in each pool’s properties? (zpool get all …)
otis
—
Juraj Lutter
o...@freebsd.org
; zfsd_unittest.o:(_GLOBAL__sub_I_zfsd_unittest.cc)
> >>> referenced 19 more times
>
> i've copied sjg@ in case this is a make issue.
FWIW, Cleaning up poudriere jail’s src and obj did fix this for me.
—
Juraj Lutter
o...@freebsd.org
bs.mk" line 45:
@ 1730276561 [2024-10-30 09:22:41] Start buildworld-jobs buildkernel-jobs
tee: /usr/buildworld.log: Permission denied
JOB_LOGDIR seems to need to be set to a directory writable by non-root user in
this case
or it defaults to ${SRCTOP}/..
—
Juraj Lutter
o...@freebsd.org
nel: psm: keyboard controller failed" in
> /var/log/messages.
>
> Reverting to boot the old kernel main-n266238-03e2fc4c4446 makes keyboard and
> system working again.
Did you try to git bisect between the working and non-working commits?
—
Juraj Lutter
o...@freebsd.org
ind that file? I'm lost
Under ${MAKEOBJDIRPREFIX}/$(SRCDIR) (in case you do the build yourself).
MAKEOBJDIRPREFIX is normally /usr/obj and SRCDIR is /usr/src (in case you don’t
use any other).
—
Juraj Lutter
o...@freebsd.org
n doesn't work in this case:
>
> root@beer:/usr/src# sysctl vfs.zfs.arc.max=8589934592
> vfs.zfs.arc.max: 0
> sysctl: vfs.zfs.arc.max=8589934592: Invalid argument
Set also vfs.zfs.arc.min to some value higher than zero.
—
Juraj Lutter
o...@freebsd.org
cript.d -o out” line).
—
Juraj Lutter
o...@freebsd.org
ne.
>
> Should I simply update to ?
> Assuming a known issue with 7addfafe73e0
Recent c941b82e1c31 boots and runs fine (as a bhyve guest)
otis
—
Juraj Lutter
o...@freebsd.org
> On 13 Aug 2023, at 23:13, Mark Millard wrote:
>
> On Aug 13, 2023, at 14:01, Mark Millard wrote:
>
>> On Aug 13, 2023, at 13:19, Juraj Lutter wrote:
>>
>>>> On 13 Aug 2023, at 21:13, Mark Millard wrote:
>>>>
>>>>
ir has `main’ checked out, without any
modifications (git status reports clean workdir)
otis
—
Juraj Lutter
o...@freebsd.org
e
> gcc does. "bootstrap" means for getting version differences early
> on in this context, not the targeting.
See the other thread. After backing out
f1d5183124d3e18d410ded61e45adb9a23b23c83, cross tools started to build again.
otis
—
Juraj Lutter
o...@freebsd.org
> On 13 Aug 2023, at 17:22, Juraj Lutter wrote:
>
>
>
>> On 13 Aug 2023, at 17:17, Mike Karels wrote:
>>
>>
>> On 13 Aug 2023, at 10:00, Juraj Lutter wrote:
>>
>>>> On 13 Aug 2023, at 16:55, Mike Karels wrote:
>>>>
>
t; triple "armv7-unknown-freebsd14.0-gnueabihf"'
> 1 error generated.
>
True, exactly the same error I’m getting.
>
> I doubt that "make package" was tested for being able to handle
> the lib32 addition to aarch64 builds for SYSTEM_COMPILER or
> SYSTEM_LINKER bootstrap cases.
>
I’m getting it in buildworld, not in packages (it does not come to packages
target)
otis
—
Juraj Lutter
o...@freebsd.org
> On 13 Aug 2023, at 17:17, Mike Karels wrote:
>
>
> On 13 Aug 2023, at 10:00, Juraj Lutter wrote:
>
>>> On 13 Aug 2023, at 16:55, Mike Karels wrote:
>>>
>>>
>>> lib32 is not built until stage 4.3.1, after build and cross tools. I teste
h64 native-xtools”, cross tools
>> are
>> being built and lib32 is built, in turn, also.
>
> I don't see native-xtools built either. but the build worked.
>
> Have you checked src.conf?
Yes, I only have KERNCONF there. I will try with
eafd028327cee688b54bc526e088c
> On 13 Aug 2023, at 14:42, Juraj Lutter wrote:
>
> Hi,
>
>> On 13 Aug 2023, at 00:17, Mike Karels wrote:
>>
>> On 12 Aug 2023, at 15:32, Juraj Lutter wrote:
>>
>> Did the buildworld start out by building a cross-compiler?
>>
>> Hav
Hi,
> On 13 Aug 2023, at 00:17, Mike Karels wrote:
>
> On 12 Aug 2023, at 15:32, Juraj Lutter wrote:
>
> Did the buildworld start out by building a cross-compiler?
>
> Have you tried without meta mode? With a clean objdir, I don't see how
> it would matter, b
n hw.ncpu` WITH_META_MODE=1 TARGET=arm64 TARGET_ARCH=aarch64
buildworld buildkernel
The build runs in clean objdir, src git hash
220427da0e9b2c1d8e964120becc17eb7524e46f
Host runs 14.0-CURRENT 28d2e3b5dedf
Am I missing something obvious?
Thanks.
—
Juraj Lutter
o...@freebsd.org
ync+0x44
—
Juraj Lutter
o...@freebsd.org
> On 4 Jul 2023, at 17:01, Chuck Tuffli wrote:
>
> On Thu, Jun 29, 2023 at 12:47 PM Juraj Lutter wrote:
>>
>> With recent -current, following occured:
>>
>> db> bt
>> Tracing pid 0 tid 100063 td 0xfe00c5c35e40
>> kdb_enter() at kdb_en
running under tmux to see if
the error re-occurs.
—
Juraj Lutter
o...@freebsd.org
> On 29 Jun 2023, at 22:01, Warner Losh wrote:
>
> What's the panic string?
I don’t have any, even savecore did not worked.
I’ve left a “cu” session to the VM’s console running under tmux and should it
reappear, I can grab it.
otis
—
Juraj Lutter
o...@freebsd.org
oop+0xc2/frame 0xfe00c5e31ef0
fork_exit() at fork_exit+0x7d/frame 0xfe00c5e31f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00c5e31f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 —
machine is a bhyve guest.
otis
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 14 Jun 2023, at 11:12, Juraj Lutter wrote:
>
>
>
>> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote:
>> I compiled gbd under /usr/ports and it now works, although it's emitting
>> some weird errors.
>>
>> -O0 -g3 removes too much and gdb
> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote:
> I compiled gbd under /usr/ports and it now works, although it's emitting
> some weird errors.
>
> -O0 -g3 removes too much and gdb shows no useful information.
Build it with:
WITH_DEBUG=1 DEBUG_FLAGS=“-O3 -g3”
ot
g
and test whether the problem will persist).
I’d be very thankful for any pointers.
Thanks!
otis
—
Juraj Lutter
o...@freebsd.org
an provide a bhyve VM on some of my hosts. We can discuss it off-list.
jl
—
Juraj Lutter
o...@freebsd.org
13 there is also infiniband/byteswap.h that does:
#include
#include
#define bswap_16bswap16
#define bswap_32bswap32
#define bswap_64bswap64
otis
—
Juraj Lutter
o...@freebsd.org
ing configuration in the old destination... And it looks like a POLA
> violation - I can imagine lot's of users might have configs in /var/unbound
I’ve opened a https://reviews.freebsd.org/D38106
<https://reviews.freebsd.org/D38106> to see whether this can be fixed.
—
Juraj Lutter
o...@freebsd.org
with netflow input module (and stored into elastic indexes),
visualized by kibana or other tools.
—
Juraj Lutter
o...@freebsd.org
> On 24 Nov 2022, at 15:16, Juraj Lutter wrote:
>>
>> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR. You could try adding
>> that to your list.
>>
>
> PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into
> src-env.conf instea
LES
>> PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver
>>
>
> bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR. You could try adding
> that to your list.
>
PORTS_MODULES are being built from within kern.post.mk. I’d put PORTSDIR into
src-env.conf instead of /etc/src.conf, for that purpose.
—
Juraj Lutter
o...@freebsd.org
them back on?
> Isn't this facilitated in periodic(8)
Moreover, there was a switch from sendmail to dma very recently.
Isn’t this the case? Difficult to judge without knowing more details (like,
snippets from logs, etc…)
—
Juraj Lutter
o...@freebsd.org
ne of those PR: clamd creates file in two locations:
- PidFile
- LocalSocket
Both the locations could be checked by rc.d script in clamd.conf (also
freshclam eventually) and respective directories can be created from within
start_precmd()
otis
—
Juraj Lutter
o...@freebsd.org
roach.
otis
>
> commit 1b7a2680fba589daf6f700565214919cb941ab56
> Author: Jung-uk Kim
> Date: Thu Sep 30 16:23:21 2021 -0400
>
>Import ACPICA 20210930
>
>(cherry picked from commit c509b6ab0d7e5bafc5348b08653b8738bd40716e)
>
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 23 Sep 2021, at 19:52, Konstantin Belousov wrote:
>
> If you do not load nvidia-modeset.ko at all, does the boot proceed?
>
> When the boot hangs, can you enter into ddb?
That also brings up a question: Does nvidia kmods (and probably also drm kmod)
match the kernel?
g FreeBSD 14.0-RELEASE (not MFCed)
>
Thanks for this!
What I miss a bit is a completion triggered by delete-char-or-list-or-eof (^D)
as it was in (t)csh.
otis
—
Juraj Lutter
o...@freebsd.org
is, and I am 95% certain it has worked in the past.
According to Makefile.inc1:
make installkernel KERNCONF=“KERN1 KERN2”
should install KERN1 and KERN2. Similar goes for buildkernel.
Or is there something I am missing?
—
Juraj Lutter
o...@freebsd.org
signature.asc
Description: Message signed with OpenPGP
vendor/openzfs/zfs-2.1-release ->
> freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref)
>
> Is this a problem at my end, or the server's end?
This already has been documented, as the old openzfs branch has been
renamed/moved.
$ git remote prune freebsd
$ git pull
See: https://lists.freebsd.org/archives/freebsd-git/2021-June/15.html
otis
—
Juraj Lutter
o...@freebsd.org
.
`uu_avl.c' is up to date.
`uu_dprintf.c' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags
REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)!
…
The build is performed with pristine /usr/obj
Any hints, please?
Thanks
otis
—
Juraj Lutter
o...@freebsd.org
/fstab:2: Inappropriate file type or format
Bacause swap entry is in inapropriate format.
The line should read:
/dev/gpt/Sea1-18 noneswapsw 0 0
otis
—
Juraj Lutter
o...@freebsd.org
nterfaces serving the NFS traffic, it
also might have added up to the stability.
There is some more work going on in Phabricator (D29690) that we also want to
test.
otis
—
Juraj Lutter
o...@freebsd.org
___
freebsd-current@freebsd.org mailing list
> On 19 Apr 2021, at 17:03, Rick Macklem wrote:
>
> Olav Gjerde wrote:
>> I have tried D29690 patch and reverting back to r367492 this weekend.
>> Neither made any difference for my system.
For me, reverting the patch in r367492, solved all the problems.
In addition, I also turned off LRO and
> On 15 Apr 2021, at 23:09, Juraj Lutter wrote:
>
> The machine it’s running on is definitely a slow or weak one (it’s dell
> r740xd with 2x CPU, 256GB RAM, 22xNVMe data zpool).
Is definitely *NOT* a slow or weak one :-)
otis
___
fre
> On 15 Apr 2021, at 22:47, Rick Macklem wrote:
>
> Allan Jude wrote:
>> On 4/15/2021 9:22 AM, Chris Roose wrote:
>>> I posted this in -questions and someone suggested I post here as well.
>>>
>>> I'm having NFS availability issues between my Proxmox client and FreeBSD
>>> server (10G link) si
> On 31 Mar 2021, at 15:53, Henric Jungheim wrote:
>
>>
>> Knowing that would help me see whether the problem is faulty initialization
>> from libtextstyle (i.e., the SCREEN pointer is null, making the path via
>> the static structure), or some ifdef-combination in ncurses that I've
>> neglecte
> On 31 Mar 2021, at 15:53, Henric Jungheim wrote:
>
>>
>> So... the question I have is what is $TERM in this case,
>> and where is the related terminal description (in terminfo or termcap).
>
> In the example in my original email, $TERM was "xterm-256color"
> (connected through "Windows Term
Hi,
very similar behavior is observed in editors/poke, on recent 13.0-STABLE
(stable/13-85ad493677a2):
(lldb) bt
* thread #1, name = 'poke', stop reason = signal SIGSEGV: invalid address
(fault address: 0x0)
* frame #0: 0x
frame #1: 0x0008009ed30a
libncursesw.so.9`del
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>
> Can you dump 'struct componentname *cnp'? This should do the trick:
> f 12
> p cnp
>
> Most notably I want to know if the name to added is a literal dot.
>
Yes, it is a dot (the directory itself):
cn_nameptr = 0xfe0011428018 ".", cn_
I am now running a patched kernel, without problems.
I can boot to unpatched one and see the output of these ddb commands.
otis
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 27 Feb 2021, at 21:49, Mateusz Guzik wrote:
>
> Can you dump 'struct componentna
0x80d0b18b at kern_getdirentries+0x1fb
#16 0x80d0b399 at sys_getdirentries+0x29
#17 0x810bd00e at amd64_syscall+0x12e
kernel is GENERIC, stock config.
otis
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
_
Hi,
thank you for the swift reaction. This patch fixed my problem.
otis
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 27 Feb 2021, at 16:53, Rick Macklem wrote:
>
> I reproduced the problem and the attached trivial patch
> seems to fix it. Please test the patc
0x7fffd928
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 27 Feb 2021, at 15:18, Juraj Lutter wrote:
>
> Reliably reproducible:
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/lis
fast_syscall_common+0xf8/frame 0xfe00d01c4af0
--- syscall (554, FreeBSD ELF64, sys_getdirentries), rip = 0x8012a83fa, rsp =
0x7fffd928, rbp = 0x7fffd960 ---
KDB: enter: panic
[ thread pid 1879 tid 101207 ]
Stopped at kdb_enter+0x37: movq$0,0x128bdde(%rip)
db>
—
Juraj Lutter
X
...@b14.builder.wilbury.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
Panic String: condition dvp != vp not met at
/usr/src/sys/kern/vfs_cache.c:2269 (cache_enter_time)
Dump Parity: 1481068399
Bounds: 0
Dump Status: good
—
Juraj Lutter
XMPP: juraj (at) lutter.sk
GSM: +421907986576
> On 15 Jan 2021, at 18:26, Freddie Cash wrote:
>
>
> /var/run/dmesg.boot includes all output from dmesg for the current boot. No
> need to manually redirect dmesg output to a file or play with buffer sizes.
> :) Just upload that file.
On boot, dmesg is saved to dmesg.boot quite lately and
> On 15 Jan 2021, at 12:10, Yasuhiro Kimura wrote:
>
> From: Jakob Alvermark
> Subject: Waiting for bufdaemon
> Date: Fri, 15 Jan 2021 11:26:47 +0100
>
>> When rebooting my thinkpad the 'bufdaemon' times out:
>>
>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop
>> ... timed o
> On 18 Dec 2020, at 14:02, Miroslav Lachman <000.f...@quip.cz> wrote:
>
> On 25/11/2020 06:54, Thomas Mueller wrote:
>
>> NetBSD users face a similar problem with their upcoming switch from cvs to
>> hg (Mercurial).
>
> Do anybody have a link to some documents stating why FreeBSD chose Git
60 matches
Mail list logo
