[Bug 273418] [panic] Repeating kernel panic on open(/dev/console)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418 --- Comment #24 from Eugene Grosbein --- (In reply to Jason A. Harmening from comment #20) The patch applied cleanly to stable/13. However, panics are irregular. Current uptime is over 7 days but it paniced more often earlier this month:

[Bug 273418] [panic] Repeating kernel panic on open(/dev/console)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418 --- Comment #23 from Eugene Grosbein --- (In reply to Jason A. Harmening from comment #22) Yesterday I grabbed 13.2-RELEASE/amd64 stock installation DVD image, created bhyve virtual machine installing 13.2 from the image, built custom kern

[Bug 273953] panic: vfs_remount_ro: mp is not busied

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273953 Graham Perrin changed: What|Removed |Added Status|New |Open -- You are receiving this ma

[Bug 273956] KERN_PROC_VMMAP does not read all mapped files

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273956 --- Comment #1 from Paul Floyd --- Will try soon-ish 14.0-BETA2 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 273956] KERN_PROC_VMMAP does not read all mapped files

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273956 Bug ID: 273956 Summary: KERN_PROC_VMMAP does not read all mapped files Product: Base System Version: 14.0-CURRENT Hardware: Any OS: Any Status: New

[Bug 273953] panic: vfs_remount_ro: mp is not busied

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273953 --- Comment #2 from Gleb Smirnoff --- Thanks, Konstantin! I can't test it since don't have reproducer. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 273953] panic: vfs_remount_ro: mp is not busied

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273953 --- Comment #1 from Konstantin Belousov --- This is cosmetic issue. mnt_lockref should be asserted only after vfs_op_enter(). Patch below should be enough. commit 5a85fa192ec81998b723361028da21c5bcb4e66f Author: Konstantin Belousov Date:

[Bug 273953] panic: vfs_remount_ro: mp is not busied

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273953 Mark Linimon changed: What|Removed |Added Keywords||crash -- You are receiving this ma

[Bug 228538] [permissions] effective allow/deny ACLs incorrectly evaluated in some cases [reproducible]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228538 Emma Brown changed: What|Removed |Added CC||emmanbrown...@gmail.com --- Comment #

[Bug 198030] /usr/src/crypto/openssl/util/mkbuildinf.pl: No such file or directory on freebsd-update install

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198030 Emma Brown changed: What|Removed |Added CC||emmanbrown...@gmail.com --- Comment #

[Bug 273907] releng/14.0 on amd64 started failing to boot a couple of days ago

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273907 --- Comment #2 from o...@j.email.ne.jp --- I switched back to the branching point of releng/14.0, BETA2, and few other points. Somehow, all of versions failed to start. I only rebuilt the kernel cleanly; I wonder if I had to clean build th

[Bug 256252] freebsd-update rollback made system unbootable

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256252 Graham Perrin changed: What|Removed |Added CC|grahamper...@freebsd.org|grahamper...@gmail.com

[Bug 273950] freebsd-update rollback (from 14.0-BETA2 back to 13.2) fails

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273950 Graham Perrin changed: What|Removed |Added CC||grahamper...@gmail.com

[Bug 273953] panic: vfs_remount_ro: mp is not busied

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273953 Bug ID: 273953 Summary: panic: vfs_remount_ro: mp is not busied Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severit

[Bug 229689] freebsd-update shouldn't add system breaking comments to config files

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229689 Ed Maste changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress

[Bug 233988] freebsd-update: Improve progress output on terminals

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233988 --- Comment #2 from Ed Maste --- See also https://reviews.freebsd.org/D39761 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 271607] 14.0-RELEASE metabug

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271607 Ed Maste changed: What|Removed |Added Depends on||273950 Referenced Bugs: https://bugs.

[Bug 273950] freebsd-update rollback (from 14.0-BETA2 back to 13.2) fails

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273950 Ed Maste changed: What|Removed |Added Blocks||271607 Referenced Bugs: https://bugs.

[Bug 256252] freebsd-update rollback made system unbootable

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256252 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu

[Bug 273950] freebsd-update rollback (from 14.0-BETA2 back to 13.2) fails

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273950 Bug ID: 273950 Summary: freebsd-update rollback (from 14.0-BETA2 back to 13.2) fails Product: Base System Version: CURRENT Hardware: Any OS: Any

[Bug 273661] freebsd-update install: ///usr/include/c++/v1/__string exists but is not a directory

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273661 Ed Maste changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org -- You are receivin

[Bug 271607] 14.0-RELEASE metabug

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271607 Bug 271607 depends on bug 273506, which changed state. Bug 273506 Summary: main [so: 15] aarch64&amd64 kyua python use can fail with: "/usr/lib/ossl-modules/legacy.so: Undefined symbol \"MD4_Update\"", '\000' https://bugs.freebsd.org/bugz

[Bug 273720] x11/lightdm: tcsh doesn't expand "~" in $PATH upon login under X

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273720 Graham Perrin changed: What|Removed |Added Assignee|b...@freebsd.org|desk...@freebsd.org Seve

[Bug 273942] fusefs(5): read operation changes ctime on FUSE filesystems

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273942 Graham Perrin changed: What|Removed |Added Assignee|b...@freebsd.org|f...@freebsd.org Statu

[Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 Graham Perrin changed: What|Removed |Added Status|New |Open -- You are receiving this ma

[Bug 273601] freebsd-update fills up /var/db/freebsd-update/files and never cleans them

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273601 --- Comment #3 from Ed Maste --- (In reply to David Chisnall from comment #2) pkgbase packages will be provided from FreeBSD 14.0 on, as a sort of technology preview. They won't yet be used by the FreeBSD installer etc., but will be availab

[Bug 273418] [panic] Repeating kernel panic on open(/dev/console)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418 --- Comment #22 from Jason A. Harmening --- Will do. Testing on -current looks good so far, at least nothing blows up. Eugene, can you apply the patch on your machine and see if the new asserts catch the bad actor? It should apply cleanly

[Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 --- Comment #8 from David Chisnall --- (In reply to Kyle Evans from comment #7) I think if syscall entry copies x0 of x9 in the trap frame, then no other code needs to care. The calling convention for the syscall says that x9 is allowed to

[Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 --- Comment #7 from Kyle Evans --- (In reply to David Chisnall from comment #4) re: x10, I was mainly proposing its use within the kernel to decide what it needs to do with x0/x9, not something that an application can rely on. I'm not sure

[Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 --- Comment #6 from Kyle Evans --- (In reply to David Chisnall from comment #5) heh, sorry, yeah- that was a remnant from playing with other signal scenarios from a while ago where elr's not necessarily advanced (e.g., __builtin_trap()) -

[Bug 273720] tcsh doesn't expand "~" in $PATH upon login under X

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273720 Daniel Tameling changed: What|Removed |Added CC||tamelingdan...@gmail.com --- Com

[Bug 273942] [fusefs]Read operation changes ctime on FUSE filesystems.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273942 --- Comment #1 from jsml4thwwbid6...@protonmail.com --- I ran into this while doing git merge operations. It causes them to fail consistently. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 273942] [fusefs]Read operation changes ctime on FUSE filesystems.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273942 Bug ID: 273942 Summary: [fusefs]Read operation changes ctime on FUSE filesystems. Product: Base System Version: 13.2-RELEASE Hardware: Any OS: Any

[Bug 272434] Hangs with combined use of du and disk operations (like mv,cp,shutil.move/rmtree,os.rename)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272434 --- Comment #10 from shamsher --- do u have RAG for vn_lock_pair(...) (freebsd-src/sys/kern/vfs_vnops.c) ? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 --- Comment #5 from David Chisnall --- I'm not sure what the `mc->mc_gpregs.gp_elr` modification is for in the link register. The PC is set to the instruction after the syscall return in the signal handler and so you shouldn't need to skip

[Bug 273929] AArch64 machine-dependent code clobbers X0 in SIGTRAP from capsicum violations

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273929 --- Comment #4 from David Chisnall --- (In reply to Kyle Evans from comment #3) > I can't imagine a situation where the error (be it ENOSYS, ECAPMODE) really > matters that much, but if it did we could presumably also fence off x10 as >