Re: New command ts(1)

On Sun, May 25, 2025, 11:50 AM Juraj Lutter wrote: > Hi, > > I’ve opened a diff https://reviews.freebsd.org/D35694 with ts(1) imported > from OpenBSD. > > If someone could have a look and eventually do a review, I’d be thankful. > I think this would make a great addi

New command ts(1)

Hi, I’ve opened a diff https://reviews.freebsd.org/D35694 with ts(1) imported from OpenBSD. If someone could have a look and eventually do a review, I’d be thankful. Cheers, — Juraj Lutter Fediverse: otis@bsd.network <mailto:otis@bsd.network> BlueSky: @wilbury.net <https://bsky.ap

Re: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1

itness exhausted >>> >>> Looking at https://cgit.freebsd.org/src/tree/sys/kern/subr_witness.c it >>> seems that the comment at line 370 is very clear : >>> >>> /* >>> * If set to 0, lock order checking is disabled. If set to -1, >>> * witnes

Re: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1

line 370 is very clear : /* * If set to 0, lock order checking is disabled. If set to -1, * witness is completely disabled. Otherwise witness performs full * lock order checking for all locks. At runtime, lock order checking * may be toggled. However, witness cannot be reenabled once

RE: Just a question about sys/kern/subr_witness.c where witness_watch may be flipped to -1

370 is very clear : > > /* > * If set to 0, lock order checking is disabled. If set to -1, > * witness is completely disabled. Otherwise witness performs full > * lock order checking for all locks. At runtime, lock order checking > * may be toggled. However, witness cannot be r

Re: grep(1) bug - duplicate output lines

Kyle Evans wrote: > > Which would have revealed: > > > > Standard output: > > Executing command [ zgrep -e  test ] > > > > Standard error: > > Fail: incorrect exit status: 134, expected: 0 > > stdout: > > > > stderr: > > Assertion failed: (pc->matchidx > 0), function procmatch_match, file / >

Re: grep(1) bug - duplicate output lines

est for details  [0.047s] ===> Summary Results read from /root/.kyua/store/ results.usr_obj_usr_src_arm64.aarch64_usr.bin_grep_tests_checkdir_usr_tests_usr.bin_grep.20250312-025551-841462.db Test cases: 56 total, 0 skipped, 1 expected failures, 0 broken, 5 failed Start time: 2025-03-12T02:55:51.9062

Re: grep(1) bug - duplicate output lines

om /root/.kyua/store/results.usr_obj_usr_src_arm64.aarch64_usr.bin_grep_tests_checkdir_usr_tests_usr.bin_grep.20250312-025551-841462.db Test cases: 56 total, 0 skipped, 1 expected failures, 0 broken, 5 failed Start time: 2025-03-12T02:55:51.906277Z End time: 2025-03-12T02:55:55.435279Z Total time

Re: grep(1) bug - duplicate output lines

Jamie Landeg-Jones wrote: > I've been running with these two patches since you posted them. I notice > that they haven't been commited, and the bug reported in the thread still > exists in current, so I'm replying to the original thread, both in the hope > that this specific problem can be fixed,

Re: grep(1) bug - duplicate output lines

Kyle Evans wrote: > On 9/29/23 15:37, Kyle Evans wrote: > > On 9/29/23 13:25, Jamie Landeg-Jones wrote: > >> Jamie Landeg-Jones wrote: > >> > >>> Brilliant! Thanks for the quick response and fix. It works fine for me - > >>> I've not managed to break it again :-) > >> > >> Famous last words

Re: No working interface bce0 after updating to CURRENT of March 1

I've had since ages these two lines in /etc/rc.conf: ifconfig_bce0="inet 192.168.178.5 netmask 255.255.255.0" ifconfig_bce1="inet 192.168.178.6 netmask 255.255.255.0" defaultrouter="192.168.178.1" The box has two RJ-45 ports and the only used one was the first, bce0. I changed the lines now to

Re: No working interface bce0 after updating to CURRENT of March 1

he new kernel. matthias El día domingo, marzo 02, 2025 a las 10:45:24a. m. +0100, Matthias Apitz escribió: > Hello, > > > Last night I updated a server from a > > 14.0-CURRENT amd64 1400094 #2 main-n264568-1d7ffb373c9d-dirty: Wed Sep 6 > 07:13:22 CEST 2023 > >

Re: No working interface bce0 after updating to CURRENT of March 1

Hi You wrote : -- # netstat -rn Routing tables Internet: DestinationGatewayFlags Netif Expire default192.168.178.1 UGS*bce0* 127.0.0.1 link#3 UH lo0 192.168.178.0/24 link#2

No working interface bce0 after updating to CURRENT of March 1

Hello, Last night I updated a server from a 14.0-CURRENT amd64 1400094 #2 main-n264568-1d7ffb373c9d-dirty: Wed Sep 6 07:13:22 CEST 2023 to the CURRENT of March 1, 2025. All went fine. # git clone https://git.freebsd.org/src.git /usr/src # cd /usr/src # make -j8 buildworld

Re: Empty structures have sizeof(1) in C++ now ?

On 2/20/25 12:03, David Chisnall wrote: No, that’s always been the case in C++. It comes from the rule that two allocations must have unique addresses. If a structure could have size zero, an array of these structures would have size zero and the two elements in the array would have the sa

Re: Empty structures have sizeof(1) in C++ now ?

; return (0); >> } >> critter phk> cc -o /tmp/a.out /tmp/_.c >> critter phk> /tmp/a.out >> 0 0 >> critter phk> c++ -o /tmp/a.out /tmp/_.c >> c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is >> deprecated [-Wdeprecated] >> critter phk> /tmp/a.out >> 1 1 >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> p...@freebsd.org | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. >> >> > >

Re: Empty structures have sizeof(1) in C++ now ?

gt; critter phk> /tmp/a.out > 0 0 > critter phk> c++ -o /tmp/a.out /tmp/_.c > c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is > deprecated [-Wdeprecated] > critter phk> /tmp/a.out > 1 1 > > -- > Poul-Henning Ka

Re: Empty structures have sizeof(1) in C++ now ?

tmp/_.c > c++: warning: treating 'c' input as 'c++' when in C++ mode, > this behavior is deprecated [-Wdeprecated] critter phk> /tmp/a.out > 1 1 > AFAIK it has always been like that, see https://www.stroustrup.com/bs_faq2.html#sizeof-empty : To ensure t

Empty structures have sizeof(1) in C++ now ?

return (0); } critter phk> cc -o /tmp/a.out /tmp/_.c critter phk> /tmp/a.out 0 0 critter phk> c++ -o /tmp/a.out /tmp/_.c c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]

#263076108 EFI RT page fault in init pid = 1

Support Team [#ID-263076108] Saturday, January 4, 2025 6:52 AM, owner-freebsd-curr...@freebsd.org: > On 1/4/25 06:45, Konstantin Belousov wrote: > > On Fri, Jan 03, 2025 at 06:43:55PM -0500, Dennis Clarke wrote: > >> > >> I wonder if anyone else has seen

Re: EFI RT page fault in init pid = 1

On 1/4/25 06:45, Konstantin Belousov wrote: On Fri, Jan 03, 2025 at 06:43:55PM -0500, Dennis Clarke wrote: I wonder if anyone else has seen such a message at shutdown : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code

Re: EFI RT page fault in init pid = 1

= supervisor read data, page not present > instruction pointer = 0x20:0x7c38f87a > stack pointer = 0x28:0xfe035500bba8 > frame pointer = 0x28:0x5 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1,

Re: EFI RT page fault in init pid = 1

ervisor read data, page not present > instruction pointer = 0x20:0x7c38f87a > stack pointer = 0x28:0xfe035500bba8 > frame pointer = 0x28:0x5 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1,

EFI RT page fault in init pid = 1

= 0x28:0xfe035500bba8 frame pointer = 0x28:0x5 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) rdi

"iozone -w -i 1 -l 512 -r 4k -s 1g" against ZFS (without compression) can be a denial of service attack on a 32 GiByte RAM system

Brooks Davis For reference: # ~/pkgbase-snapshot-list.sh Via pkg-static info -C -x '^FreeBSD-' . . . 352 FreeBSD-*-15.snap20241023235252 1 FreeBSD-*-15.snap20241022122410 1 FreeBSD-*-15.snap20241020224518 1 FreeBSD-*-15.snap20241020094723 7 FreeBSD-*-15.snap20241015203742 1 Fr

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

> > Please create a PR for this and include at least > > one backtrace. I will try and figure out how > > locallocks could cause it. > > > > I suspect few use locallocks=1. > > > > rick > > > > On Wed, Aug 21, 2024 at 7:29 AM Matthew L. Dailey

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

Hi Rick, Done - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280978 Thanks! -Matt On 8/21/24 10:45 AM, Rick Macklem wrote: > Please create a PR for this and include at least > one backtrace. I will try and figure out how > locallocks could cause it. > > I suspect few u

Re: Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

Please create a PR for this and include at least one backtrace. I will try and figure out how locallocks could cause it. I suspect few use locallocks=1. rick On Wed, Aug 21, 2024 at 7:29 AM Matthew L. Dailey < matthew.l.dai...@dartmouth.edu> wrote: > Hi all, > > I posted messa

Kernel panics with vfs.nfsd.enable_locallocks=1 and nfs clients doing hdf5 file operations

summer and have found the cause - the vfs.nfsd.enable_locallocks sysctl. When this is set to 1, we can induce either a panic or hung nfs server (more rarely) usually within a few hours, but sometimes within several days to a week. We have replicated this on 13.0 through 15.0-CURRENT (20240725

Re: pax(1) looping infinitely

On 6/22/24 08:19, Warner Losh wrote: The last core team announced one. But you can add Approved by: imp Thanks Warner! I've just committed the change. Have a nice week-end, Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://w

Re: pax(1) looping infinitely

The last core team announced one. But you can add Approved by: imp Warner On Sat, Jun 22, 2024, 12:16 AM Ganael Laplanche < ganael.laplan...@martymac.org> wrote: > > > On 6/21/24 23:41, Yuri Pankov wrote: > > > .mailmap > > Thanks Yuri! > > I cannot see any blanket approval for a ports committ

Re: pax(1) looping infinitely

On 6/21/24 23:41, Yuri Pankov wrote: .mailmap Thanks Yuri! I cannot see any blanket approval for a ports committer modifying that file within the src repo. Can a src committer approve (or commit) the following change please ? : diff --git a/.mailmap b/.mailmap index 0d0231a3da68..3d33a

Re: pax(1) looping infinitely

Ganael Laplanche wrote: > > > Le 21/06/2024 à 18:58, Warner Losh a écrit : > >> My apologies...  I didn't check, but. it's in your sig so I should >> have. > > Hey, no pb :) > >> There's a mapping file that can be updated for cases like this. > > Hmmm, I could add my address there. Can you p

Re: pax(1) looping infinitely

Le 21/06/2024 à 18:58, Warner Losh a écrit : My apologies...  I didn't check, but. it's in your sig so I should have. Hey, no pb :) There's a mapping file that can be updated for cases like this. Hmmm, I could add my address there. Can you point me to that file, I can't find it in the

Re: pax(1) looping infinitely

On Fri, Jun 21, 2024 at 10:55 AM Ganael Laplanche < ganael.laplan...@martymac.org> wrote: > On 6/21/24 18:44, Warner Losh wrote: > > Hi Warner, > > > Fixed. > > > > commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main) > > Author: Ganael Laplanche > Thanks! > > > Wrote the commit messag

Re: pax(1) looping infinitely

On 6/21/24 18:44, Warner Losh wrote: Hi Warner, Fixed. > commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main) Author: Ganael Laplanche Thanks! Wrote the commit message and had to guess at the right email to use. But it looked like bz and the mail here were the same. You could

Re: pax(1) looping infinitely

ail here were the same. In the future, simple patches like this might work better as a github pull request, though, since that would resolve all that ambiguity. Warner On Fri, Jun 21, 2024 at 4:51 AM Ganael Laplanche < ganael.laplan...@martymac.org> wrote: > Hello, > > Our pax(1) im

pax(1) looping infinitely

Hello, Our pax(1) implementation has a small bug triggered when it is fed with a directory containing a trailing slash. Could a src committer have a look at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277060 ? I've submitted a small patch that fixes the problem. Thanks! C

Re: NLNet Labs Ending Dev of drill(1)

On 2024-02-20 10:09, Pete Wright wrote: I just came across this blog post which seems to indicate that the drill(1) utility from NLNet is ending development in favor of a rust based tool: https://blog.nlnetlabs.nl/domain-dns-building-blocks-for-rust-application-developers/ https

NLNet Labs Ending Dev of drill(1)

I just came across this blog post which seems to indicate that the drill(1) utility from NLNet is ending development in favor of a rust based tool: https://blog.nlnetlabs.nl/domain-dns-building-blocks-for-rust-application-developers/ https://fosstodon.org/@nlnetlabs/111964417192522741 I was

Re: segfault in ld-elf.so.1

t) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730 > to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would > have been fixed by changes to libc/libsys since 2024-02-10-144617). The > issue shows up when I try to do an IMAP login. A successful authen

segfault in ld-elf.so.1

Hi, dovecot (and no other program I use on this machine... at least not that I notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730 to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would have been fixed by changes to libc/libsys since 2024-02-10-144617

Re: "options MAXMEMDOM=2" vs. amd64 DBG kernel booting: 3000+ "kernel: Process (pid 1) got signal 5" notices during booting

or problem investigation. >> >> I recently had reason to use the DBG kernel and found it got the >> oddity of 3000+ instances of "kernel: Process (pid 1) got signal 5" >> during booting, as reported in /var/log/messages . An example is: >> >> . . . >>

Re: "options MAXMEMDOM=2" vs. amd64 DBG kernel booting: 3000+ "kernel: Process (pid 1) got signal 5" notices during booting

ernel and found it got the > oddity of 3000+ instances of "kernel: Process (pid 1) got signal 5" > during booting, as reported in /var/log/messages . An example is: > > . . . > Nov 20 23:13:09 7950X3D-UFS shutdown[20174]: reboot by root: > Nov 20 23:13:09 7950X3D-UFS s

"options MAXMEMDOM=2" vs. amd64 DBG kernel booting: 3000+ "kernel: Process (pid 1) got signal 5" notices during booting

ocess (pid 1) got signal 5" during booting, as reported in /var/log/messages . An example is: . . . Nov 20 23:13:09 7950X3D-UFS shutdown[20174]: reboot by root: Nov 20 23:13:09 7950X3D-UFS syslogd: exiting on signal 15 Nov 20 23:14:21 7950X3D-UFS syslogd: kernel boot file is /boot/kernel/kernel

Re: grep(1) bug - duplicate output lines

Kyle Evans wrote: > Alright, fine, be that way. :-) Try this on top of the existing patch: Sorry! I have this knack of (accidentally) stumbling upon weird-case bugs that usually don't affect anyone! :-) > https://people.freebsd.org/~kevans/grep-color-addition.diff Brilliant That all seems

Re: grep(1) bug - duplicate output lines

On 9/29/23 15:37, Kyle Evans wrote: On 9/29/23 13:25, Jamie Landeg-Jones wrote: Jamie Landeg-Jones wrote: Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. :

Re: grep(1) bug - duplicate output lines

On 9/29/23 13:25, Jamie Landeg-Jones wrote: Jamie Landeg-Jones wrote: Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : Alright, fine, be that way. :-) Try t

Re: grep(1) bug - duplicate output lines

Jamie Landeg-Jones wrote: > Brilliant! Thanks for the quick response and fix. It works fine for me - > I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : | % grep -v sdjdjdjd /COPYRIGHT|head | # @(#)COPYRIGHT 8.2 (Berkeley) 3/2

Re: grep(1) bug - duplicate output lines

Kyle Evans wrote: > I think this is what we want: > > https://people.freebsd.org/~kevans/grep-color.diff Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) > Basically, for --color with . we actually get each individual character > r

Re: grep(1) bug - duplicate output lines

On 9/27/23 22:34, Greg 'groggy' Lehey wrote: On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote: On 9/27/23 21:40, Jamie Landeg-Jones wrote: When using color=always and a regex of '.' (for example), output lines are duplicated. $ grep --version grep (BSD grep, GNU compatible)

Re: grep(1) bug - duplicate output lines

On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote: > On 9/27/23 21:40, Jamie Landeg-Jones wrote: >> When using color=always and a regex of '.' (for example), output lines >> are duplicated. >> >> $ grep --version >> grep (BSD grep, GNU compatible) 2.6.0-FreeBSD >> >> E.G.: >> >> $

Re: grep(1) bug - duplicate output lines

On 9/27/23 21:40, Jamie Landeg-Jones wrote: When using color=always and a regex of '.' (for example), output lines are duplicated. $ grep --version grep (BSD grep, GNU compatible) 2.6.0-FreeBSD E.G.: $ grep --color=always . /etc/fstab Cheers, Jamie I think this is what we want: https://pe

grep(1) bug - duplicate output lines

When using color=always and a regex of '.' (for example), output lines are duplicated. $ grep --version grep (BSD grep, GNU compatible) 2.6.0-FreeBSD E.G.: $ grep --color=always . /etc/fstab Cheers, Jamie

(some?) armv7 time issues fixed with hw.userspace_allow_phys_counter=1

i found issue, but this needs more testing and i only have allwinner h3 here with hw.userspace_allow_phys_counter=1 time doesn't jump forward and back (!) anymore i tracked this down to this commit here: 7ad28b73ec1f - arm: Add a userspace physical timer check perhaps there are more peopl

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

: 34588 Built: 7473 Failed: 23Skipped: 798 Ignored: 335 Fetched: 0 Tobuild: 25959 Time: 13:08:26 [13:08:30] Logs: /usr/local/poudriere/data/logs/bulk/main-amd64-bulk_a-default/2023-09-08_19h51m52s [13:08:31] Cleaning up [13:17:10] Unmounting file systems Exiting with status 1 In part

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

kipped: 179 Ignored: 335 Fetched: 0 >> Tobuild: 32059 Time: 01:42:47 >> >> and still going. (FYI: The failures are expected.) >> >> After a while I might stop it and start over with a non-debug >> kernel installed instead. > > I did ^C afte

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

Fetched: 0 > Tobuild: 32059 Time: 01:42:47 > > and still going. (FYI: The failures are expected.) > > After a while I might stop it and start over with a non-debug > kernel installed instead. I did ^C after 2.5 hr (with 2447 built): ^C[02:30:05] Error: Signal SIGINT c

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Fri, 8 Sep 2023 17:03:07 -0700 Mark Millard wrote: > On Sep 8, 2023, at 15:30, Martin Matuska wrote: > > > I can confirm that the patch fixes the panic caused by the provided script > > on my test systems. > > Mark, would it be possible to try poudriere on your system with a patched > > ke

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Sep 8, 2023, at 17:03, Mark Millard wrote: > On Sep 8, 2023, at 15:30, Martin Matuska wrote: > >> I can confirm that the patch fixes the panic caused by the provided script >> on my test systems. >> Mark, would it be possible to try poudriere on your system with a patched >> kernel? > > .

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On 9/8/23 15:09, Alexander Motin wrote: Thank you, Martin.  I was able to reproduce the issue with your script and found the cause. I first though the issue is triggered by the `cp`, but it appeared to be triggered by `cat`.  It also got copy_file_range() support, but later than `cp`.  That i

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Sep 8, 2023, at 15:30, Martin Matuska wrote: > I can confirm that the patch fixes the panic caused by the provided script on > my test systems. > Mark, would it be possible to try poudriere on your system with a patched > kernel? . . . On 9. 9. 2023 0:09, Alexander Motin wrote: > On 08.09.

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

digged a little and was able to reproduce the panic without poudriere with a shell script. #!/bin/sh nl=' ' sed_script=s/aaa/b/ for ac_i in 1 2 3 4 5 6 7; do sed_script="$sed_script$nl$sed_script" done

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On 08.09.2023 09:52, Martin Matuska wrote: I digged a little and was able to reproduce the panic without poudriere with a shell script. #!/bin/sh nl=' ' sed_script=s/aaa/b/ for ac_i in 1 2 3 4 5 6 7; do    

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

> with the cat command on 9th iteration. > > Here is the script: > > #!/bin/sh > nl=' > ' > sed_script=s/aaa/b/ > for ac_i in 1 2 3 4 5 6 7; do > sed_script="$sed_script$nl$sed_s

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

/bin/sh nl=' ' sed_script=s/aaa/bbbbb/ for ac_i in 1 2 3 4 5 6 7; do     sed_script="$sed_script$nl$sed_script" done echo "$sed_script" 2>/dev/null | sed 99q >conftest.sed repeats=8 count=0 echo -n 0123456789

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

no problems. > > Note: the earlier snapshot from my first setup was > still in place since it was made just before the > original checkpoint used above. > > However, the rewind did remove the /var/crash/ > material that had been added. > > I did the appropriate z

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

ount. I installed a debug kernel and world to the import. Again, no problems reported. I did the appropriate zfs umount. I did the appropriate zpool export. I rebooted with the test media. # sysctl vfs.zfs.bclone_enabled vfs.zfs.bclone_enabled: 1 # zpool trim -w zamd64 # zpool checkpoint zam

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

Thanks, Mark. On 07.09.2023 15:40, Mark Millard wrote: On Sep 7, 2023, at 11:48, Glen Barber wrote: On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: When I next have time, should I retry based on a more recent vintage of main that includes 969071be938c ? Yes, please, if you ca

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Sep 7, 2023, at 11:48, Glen Barber wrote: > On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: >> When I next have time, should I retry based on a more recent >> vintage of main that includes 969071be938c ? >> > > Yes, please, if you can. As stands, I rebooted that machine into m

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: > When I next have time, should I retry based on a more recent > vintage of main that includes 969071be938c ? > Yes, please, if you can. Glen signature.asc Description: PGP signature

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

to do a test with vfs.zfs.bclone_enabled=1 and > the bulk -a build paniced (having stored 128 *.pkg files in > .building/ first): Unfortunately, rerunning my tests with this set was testing a context predating: Wed, 06 Sep 2023 . . . • git: 969071be938c - main - vfs: copy_file_range() be

main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

I was requested to do a test with vfs.zfs.bclone_enabled=1 and the bulk -a build paniced (having stored 128 *.pkg files in .building/ first): # more /var/crash/core.txt.3 . . . Unread portion of the kernel message buffer: panic: Solaris(panic): zfs: accessing past end of object 422/1108c16 (size

Re: ps(1) bugs and problems

On 2023-08-15 13:28:07, Jamie Landeg-Jones wrote: The old -d and the new -D'$^' would be the best in that -d would go back to what it was and -D would provide the much needed feature in two variants (possibly more in the future, if needed) while only taking one option-letter. The only problem is

Re: ps(1) bugs and problems

"Piotr P. Stefaniak" wrote: > On 2023-08-11 12:32:02, Jamie Landeg-Jones wrote: > >How about reverting '-d', and adding "-D" for descending, and "-A" for > >ascending? > > I don't like that, because it would take three option-letters in total > to implement the same function in different variant

Re: ps(1) bugs and problems

On 2023-08-11 12:32:02, Jamie Landeg-Jones wrote: How about reverting '-d', and adding "-D" for descending, and "-A" for ascending? I don't like that, because it would take three option-letters in total to implement the same function in different variants. The old -d and the new -D'$^' would

Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch)

On Aug 13, 2023, at 15:33, bob prohaska wrote: > On Sun, Aug 13, 2023 at 12:45:12PM -0700, Mark Millard wrote: >> >> Wow. I'm going to suggest doing a clone (to a temporary >> place) on one or more different types of system, such >> as aarch64 or amd64. If, say, aarch64 works but armv7 >> does n

Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch)

On Sun, Aug 13, 2023 at 12:45:12PM -0700, Mark Millard wrote: > > Wow. I'm going to suggest doing a clone (to a temporary > place) on one or more different types of system, such > as aarch64 or amd64. If, say, aarch64 works but armv7 > does not, then the corruption may well be in some armv7 > Free

Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch)

On Aug 13, 2023, at 12:26, bob prohaska wrote: > On Sat, Aug 12, 2023 at 08:45:54PM -0700, Mark Millard wrote: >> >> You might need to use the ssh alternative if your >> context allows it: >> >> ssh://anon...@git.freebsd.org/src.git >> >> There was a time when git fetch proved unreliable >> in

Re: alpha-1 armv7 git failed: fatal: pack is corrupted (SHA1 mismatch)

On Sat, Aug 12, 2023 at 08:45:54PM -0700, Mark Millard wrote: > > You might need to use the ssh alternative if your > context allows it: > > ssh://anon...@git.freebsd.org/src.git > > There was a time when git fetch proved unreliable > in my context and I got around it via ssh use. It > also took

Re: ps(1) bugs and problems

"Piotr P. Stefaniak" wrote: > I thought about this more and the change I proposed in > https://reviews.freebsd.org/D41231 seems unnecessarily complicated, > regardless of which characters will be chosen to denote going up and > down the process tree. ps -D'^$' suggests there are possibly more > c

Re: ps(1) bugs and problems

I thought about this more and the change I proposed in https://reviews.freebsd.org/D41231 seems unnecessarily complicated, regardless of which characters will be chosen to denote going up and down the process tree. ps -D'^$' suggests there are possibly more characters to use and maybe even some ki

Re: ps(1) bugs and problems

On 2023-07-29 00:07:37, Jamie Landeg-Jones wrote: I have a program that produces a list of PIDS, that are supplied via '-p' to /bin/ps and are sorted with '-d'. What language is it written in? What is the use case? After a late upgrade on a particular machine, I've just been bitten by the mod

ps(1) bugs and problems

I have a program that produces a list of PIDS, that are supplied via '-p' to /bin/ps and are sorted with '-d'. After a late upgrade on a particular machine, I've just been bitten by the modifications to "ps" to unconditionaly add recurive descendancy PID lookups to the '-d' option when a pid is sp

Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?

On 21/06/2023 01:29, Graham Perrin wrote: … Thanks, people. A few hours ago I took a hint from one of the pages linked from , added a line to my sysctl.conf(5). … % grep ipc /etc/sysctl.conf kern.ipc.soacceptqueue=256 % I found n

Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

30622-b95d2237af40-263748-bootonly.iso> > > and upgraded to cab2d43b83b (amd64). > > > > Did a magnific delete-old and delete-old-libs and now a lot of packages > > complain about "ld-elf.so.1: Shared object "libssl.so.111" not found, > > required by...&q

Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

domingo, 2/07/2023 à(s) 08:57: > On Sun, 02 Jul 2023 14:41:55 +0900 (JST) > Yasuhiro Kimura wrote: > > > From: Nuno Teixeira > > Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required > by "pkg" and others > > Date: Sun, 2 Jul 2023 0

Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

SD-14.0-CURRENT-amd64-20230622-b95d2237af40-263748-bootonly.iso > > > > and upgraded to cab2d43b83b (amd64). > > > > Did a magnific delete-old and delete-old-libs and now a lot of packages > > complain about "ld-elf.so.1: Shared object "libssl.so.111" no

RE: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

otonly.iso> > and upgraded to cab2d43b83b (amd64). > > Did a magnific delete-old and delete-old-libs and now a lot of packages > complain about "ld-elf.so.1: Shared object "libssl.so.111" not found, > required by..." > > To fix it I rebooted with BE f

Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

On Sun, 02 Jul 2023 14:41:55 +0900 (JST) Yasuhiro Kimura wrote: > From: Nuno Teixeira > Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required by > "pkg" and others > Date: Sun, 2 Jul 2023 06:22:48 +0100 > > > Hello all, > >

Re: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

From: Nuno Teixeira Subject: ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others Date: Sun, 2 Jul 2023 06:22:48 +0100 > Hello all, > > I'm returning to current and installed from > 20230622-b95d2237af40-263748-bootonly.i

ld-elf.so.1: Shared object "libssl.so.111" not found, required by "pkg" and others

ific delete-old and delete-old-libs and now a lot of packages complain about "ld-elf.so.1: Shared object "libssl.so.111" not found, required by..." To fix it I rebooted with BE from first instalation since I used beinstall.sh for upgrade. I know that a lot of things happened in th

debug.verbose_sysinit=1 and kern.msgbufsize=196608

On 25/06/2023 21:32, David Wolfskill wrote: On Sun, Jun 25, 2023 at 09:20:40PM +0100, Graham Perrin wrote: When debug.verbose_sysinit=1 is set in loader.conf(5), is normal to _not_ have BOOT and copyright messages? It's normal (in that situation) to require a higher value in kern.msgbufsi

Re: debug.verbose_sysinit=1

On Sun, Jun 25, 2023 at 09:20:40PM +0100, Graham Perrin wrote: > When debug.verbose_sysinit=1 is set in loader.conf(5), is normal to _not_ > have BOOT and copyright messages? It's normal (in that situation) to require a higher value in kern.msgbufsize if you want the entire dmesg outp

debug.verbose_sysinit=1

When debug.verbose_sysinit=1 is set in loader.conf(5), is normal to _not_ have BOOT and copyright messages? Boot began with: Jun 25 06:49:31 mowa219-gjp4-8570p-freebsd syslogd: kernel boot file is /boot/kernel/kernel – then (timestamps etc. trimmed): DEP)... done.    malloc_init(&M_JAD

Re: panic: ASan: Invalid access, 1-byte read at ...

On Wed, Jun 21, 2023 at 10:06:28AM -0400, Mark Johnston wrote: > On Wed, Jun 21, 2023 at 11:53:44AM +0200, Peter Holm wrote: > > Just got this panic: > > > > 20230621 11:15:23 all (37/912): linux.sh > > panic: ASan: Invalid access, 1-byte read at 0xfe020bd7

Re: panic: ASan: Invalid access, 1-byte read at ...

On Wed, Jun 21, 2023 at 11:53:44AM +0200, Peter Holm wrote: > Just got this panic: > > 20230621 11:15:23 all (37/912): linux.sh > panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, > RedZonePartial(2) > cpuid = 1 > time = 1687338930 > KDB: stack backtrace:

panic: ASan: Invalid access, 1-byte read at ...

Just got this panic: 20230621 11:15:23 all (37/912): linux.sh panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, RedZonePartial(2) cpuid = 1 time = 1687338930 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfe01f16abc10 kdb_backtrace() at

Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?

Quoting Gary Jennejohn (from Tue, 20 Jun 2023 14:41:41 +): On Tue, 20 Jun 2023 12:04:13 +0200 Alexander Leidinger wrote: "listen X backlog=y" and "sysctl kern.ipx.somaxconn=X" for FreeBSD On my FreeBSD14 system these things are all under kern.ipc. Typo on my side... it was supposed

Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?

14 system these things are all under kern.ipc. maxconn seems to be an alias for soacceptqueue, which is set to 128 on my machine. However, the software he's using may have set backlog to 1. Hard to say based on the trace he provided. Thanks, people. A few hours ago I took a hint from o

  1   2   3   4   5   6   7   8   9   10   >