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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

--- Comment #7 from Konstantin Belousov  ---
Do you have any third-party modules loaded?
Are there any changes in src comparing to stock git?
Were there unmounts of devfs mounts?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 180885] [panic] panic: kmem_map too small at heavy packet traffic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180885

Jesse  changed:

   What|Removed |Added

 CC||mikasaackerma...@outlook.co
   ||m

--- Comment #6 from Jesse  ---
I also encounter this bug where I receive the error message "panic: kmem_map
too small" during heavy packet traffic. https://wordleunlimited.online/

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273431] No PCP (priority code point) on outbound traffic via em(4) when PCP and hardware VLAN tag insertion is disabled

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273431

Zhenlei Huang  changed:

   What|Removed |Added

  Flags||mfc-stable13?,
   ||mfc-stable12?
   Assignee|b...@freebsd.org|z...@freebsd.org
 Status|New |In Progress
URL||https://reviews.freebsd.org
   ||/D39536

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273431] No PCP (priority code point) on outbound traffic via em(4) when PCP and hardware VLAN tag insertion is disabled

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273431

Bug ID: 273431
   Summary: No PCP (priority code point) on outbound traffic via
em(4) when PCP and hardware VLAN tag insertion is
disabled
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: z...@freebsd.org

This is a crafted bug from WIP fix https://reviews.freebsd.org/D39536.

A setup:

em0 <---> igc0

Steps to repeat:

Capture on igc0
```
# ifconfig igc0 up
# tcpdump -nevi igc0
```

Disable PCP and hardware VLAN tag insertion, then send packets with priority
```
# ifconfig em0 -vlanhwtag -pcp
# ifconfig em0 inet 192.0.2.1/24
# arp -s 192.0.2.2 0:1:2:3:4:5
# ping -c1 -C3 192.0.2.2
```

Packets captured on igc0:
```
09:53:57.397415 00:0c:29:73:4f:98 > 00:01:02:03:04:05, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 64, id 19249, offset 0, flags [none], proto ICMP (1),
length 84)
192.0.2.1 > 192.0.2.2: ICMP echo request, id 5382, seq 0, length 64
```

When either hardware VLAN tag insertion is enabled, or enable default PCP on
interface
```
# ifconfig em0 vlanhwtag
### or
# ifconfig em0 pcp 0
```

then the outbound packets looks good:
```
10:00:03.189436 00:0c:29:73:4f:98 > 00:01:02:03:04:05, ethertype 802.1Q
(0x8100), length 102: vlan 0, p 3, ethertype IPv4, (tos 0x0, ttl 64, id 33532,
offset 0, flags [none], proto ICMP (1), length 84)
192.0.2.1 > 192.0.2.2: ICMP echo request, id 6662, seq 0, length 64

10:02:17.070757 00:0c:29:73:4f:98 > 00:01:02:03:04:05, ethertype 802.1Q
(0x8100), length 102: vlan 0, p 3, ethertype IPv4, (tos 0x0, ttl 64, id 19250,
offset 0, flags [none], proto ICMP (1), length 84)
192.0.2.1 > 192.0.2.2: ICMP echo request, id 8198, seq 0, length 64
```


Expected behavior: outbound traffic should always have priority when
application requires.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273428] contrib/nvi: Fix "move forward paragraphs" (}) with numeric prefix

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273428

Craig Leres  changed:

   What|Removed |Added

 Attachment #244450||maintainer-approval?
  Flags||

--- Comment #1 from Craig Leres  ---
Created attachment 244450
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244450=edit
patch

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273428] contrib/nvi: Fix "move forward paragraphs" (}) with numeric prefix

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273428

Bug ID: 273428
   Summary: contrib/nvi: Fix "move forward paragraphs" (}) with
numeric prefix
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: le...@freebsd.org

There is a bug in the base nvi that was recently fixed in the github project
that the editors/nvi2 port tracks:

https://github.com/lichray/nvi2/pull/119

To reproduce:

% cat test
.PP
1
.PP
2
.PP
3
.PP
4
.PP
5
.PP
6

Edit the test file then type "}" 3 times and notice that the cursor correctly
advances three paragraphs. Next go home ("H") then type "3}" and notice that
the cursor (incorrectly) advances fives paragraphs ((2 * N) - 1.

Here's a patch to fix this in the base system version of nvi.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 212716] recv() with MSG_WAITALL doesn't always unblock on EOF

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212716

--- Comment #4 from Lewis Donzis  ---
This bug still occurs in FreeBSD 13.2, seven years since it was first reported.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 212716] recv() with MSG_WAITALL doesn't always unblock on EOF

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212716

Lewis Donzis  changed:

   What|Removed |Added

Version|12.2-RELEASE|13.2-RELEASE

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 253119] Loss of deep CPU throttling after upgrade from 12-STABLE to 13-STABLE

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253119

--- Comment #3 from jakub_l...@mailplus.pl ---
(In reply to jakub_lach from comment #0)

FWIW, 14-STABLE changed increments and scales to dev.cpu.0.freq: 349 with
P9700.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273373] fails to build in POSIX mode due to namespace pollution

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273373

--- Comment #9 from Jake Freeland  ---
(In reply to Jake Freeland from comment #8)
Chromium successfully compiled with this change. I'll update review D41600 to
include sys/time.h in timerfd.h.

Thanks for reporting this, Jan.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273196] xargs(1): remove the limitation on the length of strings with replacements

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273196

--- Comment #9 from Fernando Apesteguía  ---
(In reply to Andrew "RhodiumToad" Gierth from comment #8)
I see.

So the problem is not that there wasn't a limit before f058359ba5 and after
f058359ba5 there is one.

The problem f058359ba5 fixed was that the output of xargs was broken for very
long substitution strings and after f058359ba5 an error is reported.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

--- Comment #6 from Eugene Grosbein  ---
I'm not familiar with the code and locking schema. But I'm ready to test
patches :-) Could you provide some?

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

--- Comment #5 from Mateusz Guzik  ---
So cdp is backed by dev, but freeing dev is decoupled from unlinking it from
the global cdp list and it may be some of the frees happen when they should
not. There is very funky refcount scheme in there which pins cdp in a way which
does not pin dev(???).

That said I would start with adding a bool to dev indicating that cdp is
hanging out on the list (or not). Then assert it is not when freeing.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268393] system always reboots once from a powered off state

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268393

Warner Losh  changed:

   What|Removed |Added

 CC||i...@freebsd.org

--- Comment #54 from Warner Losh  ---
So what happens if you just revert the locking part of the commit that created
the problem? Eg aff just the 0x check?

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

--- Comment #4 from Eugene Grosbein  ---
(In reply to Mateusz Guzik from comment #3)

cdp has lots of 0xdeadc0dedeadc0de :

(kgdb) frame 7
#7  devfs_populate_loop (dm=dm@entry=0xf8044020a000,
cleanup=cleanup@entry=0)
at /data/src/sys/fs/devfs/devfs_devs.c:533
533 cdp->cdp_dirents[dm->dm_idx] != NULL) {
(kgdb) p *cdp
$1 = {cdp_c = {si_spare0 = 0xdeadc0dedeadc0de, si_flags = 3735929054, si_atime
= {
  tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}, si_ctime
= {
  tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}, si_mtime
= {
  tv_sec = -2401050962867404578, tv_nsec = -2401050962867404578}, si_uid =
3735929054,
si_gid = 3735929054, si_mode = 49374, si_cred = 0xdeadc0dedeadc0de, si_drv0
= -559038242,
si_refcount = -559038242, si_list = {le_next = 0xdeadc0dedeadc0de,
  le_prev = 0xdeadc0dedeadc0de}, si_clone = {le_next = 0xdeadc0dedeadc0de,
  le_prev = 0xdeadc0dedeadc0de}, si_children = {lh_first =
0xdeadc0dedeadc0de},
si_siblings = {le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de},
si_parent = 0xdeadc0dedeadc0de, si_mountpt = 0xdeadc0dedeadc0de,
si_drv1 = 0xdeadc0dedeadc0de, si_drv2 = 0xdeadc0dedeadc0de, si_devsw =
0xdeadc0dedeadc0de,
si_iosize_max = -559038242, si_usecount = 16045693110842147038,
si_threadcount = 16045693110842147038, __si_u = {__sid_snapdata =
0xdeadc0dedeadc0de},
si_name =
"\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336"...},
cdp_list = {tqe_next = 0xdeadc0dedeadc0de,
tqe_prev = 0xdeadc0dedeadc0de}, cdp_inode = 3735929054, cdp_flags =
3735929054,
  cdp_inuse = 3735929053, cdp_maxdirent = 3735929054, cdp_dirents =
0xdeadc0dedeadc0de,
  cdp_dirent0 = 0xdeadc0dedeadc0de, cdp_dtr_list = {tqe_next =
0xdeadc0dedeadc0de,
tqe_prev = 0xdeadc0dedeadc0de}, cdp_dtr_cb = 0xdeadc0dedeadc0de,
  cdp_dtr_cb_arg = 0xdeadc0dedeadc0de, cdp_fdpriv = {lh_first =
0xdeadc0dedeadc0de},
  cdp_threadlock = {lock_object = {
  lo_name = 0xdeadc0dedeadc0de ,
  lo_flags = 3735929054, lo_data = 3735929054, lo_witness =
0xdeadc0dedeadc0de},
mtx_lock = 16045693110842147038}}

(kgdb) p cdp->cdp_dirents
$2 = (struct devfs_dirent **) 0xdeadc0dedeadc0de

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

--- Comment #3 from Mateusz Guzik  ---
What exactly is freed here? Since this is in a multi-line if statement I would
not trust the line number.

As in can you print cdp itself and then cdp->cdp_dirent if the former is not
bogus? cdp in fact should be dumped to check the refcount on it

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

Eugene Grosbein  changed:

   What|Removed |Added

 CC||c...@freebsd.org,
   ||k...@freebsd.org,
   ||m...@freebsd.org,
   ||tr...@freebsd.org

--- Comment #2 from Eugene Grosbein  ---
Adding several people that might have a clue to CC:

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

Eugene Grosbein  changed:

   What|Removed |Added

   Keywords||crash

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

--- Comment #1 from Eugene Grosbein  ---
Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 14
instruction pointer = 0x20:0x80a9a1a1
stack pointer   = 0x28:0xfe0152e8d750
frame pointer   = 0x28:0xfe0152e8d7b0
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 = 2031 (syslogd)
trap number = 9
panic: general protection fault
cpuid = 3
time = 1693170002
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0152e8d570
vpanic() at vpanic+0x152/frame 0xfe0152e8d5c0
panic() at panic+0x43/frame 0xfe0152e8d620
trap_fatal() at trap_fatal+0x387/frame 0xfe0152e8d680
calltrap() at calltrap+0x8/frame 0xfe0152e8d680
--- trap 0x9, rip = 0x80a9a1a1, rsp = 0xfe0152e8d750, rbp =
0xfe0152e8d7b0 ---
devfs_populate_loop() at devfs_populate_loop+0x91/frame 0xfe0152e8d7b0
devfs_populate() at devfs_populate+0x4a/frame 0xfe0152e8d7d0
devfs_populate_vp() at devfs_populate_vp+0x88/frame 0xfe0152e8d810
devfs_lookup() at devfs_lookup+0x2b/frame 0xfe0152e8d9e0
lookup() at lookup+0x491/frame 0xfe0152e8da80
namei() at namei+0x332/frame 0xfe0152e8db30
vn_open_cred() at vn_open_cred+0x4a0/frame 0xfe0152e8dca0
kern_openat() at kern_openat+0x298/frame 0xfe0152e8de00
amd64_syscall() at amd64_syscall+0x143/frame 0xfe0152e8df30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0152e8df30
--- syscall (499, FreeBSD ELF64, openat), rip = 0x1fc80cc4504a, rsp =
0x1fc80b443d58, rbp = 0x1fc80b443e40 ---
Uptime: 23h58m28s
Dumping 9723 out of 32715 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418

Bug ID: 273418
   Summary: [panic] Repeating kernel panic on open(/dev/console)
   Product: Base System
   Version: 13.2-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: eu...@freebsd.org

A 13.2-STABLE/amd64 server sometimes runs flawlessly for several weeks, but
sometimes panices with same backtrace at midnight after newsyslog rotates and
compresses logs then sends SIGHUP to the syslogd that closes and reopens all
channels including /dev/console. The kernel panices on open(/dev/console)
system call sometimes. The system was source-updated from 12.4-STABLE/amd64 to
the commit https://cgit.freebsd.org/src/commit/?h=stable/13=8711fd210

This is regression since 12.4-STABLE.

# conscontrol
Configured: ttyv0
 Available: uart,ttyv0,gdb
Muting: off
# sysctl kern.vty
kern.vty: vt
# last | grep boot | head -5
boot time  Mon Aug 28 00:08
boot time  Sun Aug 27 00:07
boot time  Sat Aug 26 00:09
boot time  Tue Aug 22 00:08
boot time  Mon Aug 21 00:09

And I have 5 crashdumps with same backtrace. Custom kernel has debugging
options that point to use-after-free (0xdeadc0dedeadc0de, see below).

options KDB # Enable kernel debugger support.
options KDB_UNATTENDED
options KDB_TRACE
options DDB # Support DDB.
options GDB # Support remote GDB.
optionsINVARIANTS  # Enable calls of extra sanity checkin
optionsINVARIANT_SUPPORT   # Extra sanity checks of internal
structures, required by IN
optionsWITNESS # Enable checks to detect deadlocks and
cycles
optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for
speedoptions

The backtrace:

#0  __curthread () at /data/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=textdump@entry=1) at
/data/src/sys/kern/kern_shutdown.c:396
#2  0x80c0dd43 in kern_reboot (howto=260) at
/data/src/sys/kern/kern_shutdown.c:484
#3  0x80c0e1af in vpanic (fmt=,
ap=ap@entry=0xfe0152e8d600)
at /data/src/sys/kern/kern_shutdown.c:923
#4  0x80c0df33 in panic (fmt=) at
/data/src/sys/kern/kern_shutdown.c:847
#5  0x811178b7 in trap_fatal (frame=0xfe0152e8d690, eva=0)
at /data/src/sys/amd64/amd64/trap.c:942
#6  
#7  devfs_populate_loop (dm=dm@entry=0xf8044020a000,
cleanup=cleanup@entry=0)
at /data/src/sys/fs/devfs/devfs_devs.c:533
#8  0x80a9a0fa in devfs_populate (dm=dm@entry=0xf8044020a000)
at /data/src/sys/fs/devfs/devfs_devs.c:677
#9  0x80a9f318 in devfs_populate_vp (vp=0xf804401d9988)
at /data/src/sys/fs/devfs/devfs_vnops.c:359
#10 0x80a9d61b in devfs_lookup (ap=0xfe0152e8da30)
at /data/src/sys/fs/devfs/devfs_vnops.c:1187
#11 0x80cecbb1 in VOP_LOOKUP (dvp=0xf804401d9988,
vpp=0xfe0152e8dd10,
cnp=0xfe0152e8dd38) at ./vnode_if.h:69
#12 lookup (ndp=ndp@entry=0xfe0152e8dcb8) at
/data/src/sys/kern/vfs_lookup.c:1092
#13 0x80cebba2 in namei (ndp=ndp@entry=0xfe0152e8dcb8)
at /data/src/sys/kern/vfs_lookup.c:617
#14 0x80d11f90 in vn_open_cred (ndp=ndp@entry=0xfe0152e8dcb8,
flagp=flagp@entry=0xfe0152e8ddd4, cmode=cmode@entry=0,
vn_open_flags=vn_open_flags@entry=16, cred=0xf80440282500,
fp=0xf8005a296af0)
at /data/src/sys/kern/vfs_vnops.c:328
#15 0x80d08c58 in kern_openat (td=0xfe003753b000, fd=-100,
path=0x1fc80b443e60 ,
pathseg=UIO_USERSPACE, flags=6, mode=)
at /data/src/sys/kern/vfs_syscalls.c:1158
#16 0x81118283 in syscallenter (td=)
at /data/src/sys/amd64/amd64/../../kern/subr_syscall.c:190
#17 amd64_syscall (td=0xfe003753b000, traced=0) at
/data/src/sys/amd64/amd64/trap.c:1183
#18 
#19 0x1fc80cc4504a in ?? ()
Backtrace stopped: Cannot access memory at address 0x1fc80b443d58

(kgdb) frame 15
#15 0x80d08c58 in kern_openat (td=0xfe003753b000, fd=-100,
path=0x1fc80b443e60 ,
pathseg=UIO_USERSPACE, flags=6, mode=)
at /data/src/sys/kern/vfs_syscalls.c:1158
1158error = vn_open_cred(, , cmode, VN_OPEN_WANTIOCTLCAPS,

(kgdb) p nd
$4 = {ni_dirp = 0x1fc80b443e60 ,
  ni_segflg = UIO_USERSPACE, ni_rightsneeded = 0xfe0152e8ddb0, ni_startdir
= 0x0,
  ni_rootdir = 0xf80003f36000, ni_topdir = 0x0, ni_dirfd = -100, ni_lcf =
0, ni_filecaps = {
fc_rights = {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = -1,
fc_fcntls = 0},
  ni_vp = 0x0, ni_dvp = 0xf804401d9988, ni_resflags = 1, ni_debugflags = 3,
ni_loopcnt = 0,
  ni_pathlen = 1, ni_next = 

[Bug 269568] strip(1) creates an executable which crashes in ld-elf.so.1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269568

--- Comment #6 from Konstantin Belousov  ---
Limiting the size of the stack is done by kernel before even ld-elf.so.1
has the chance to run.  If the stack is too small, userspace must fail.

[From the PT_GNU_STACK phdr, only the size and protection are used]

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273414] linuxulator regression in symlinks under zfs

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273414

--- Comment #2 from Dmitry Chagin  ---
here it rather makes sense to speak about regression in vfs/namecache/ufs due
to the fact that:
1. starting from
https://cgit.freebsd.org/src/commit/sys/kern/vfs_cache.c?id=739ecbcf1c4fd22b5f6ee0bb180a67644046a3e0
file systems should cache symbolic link targets on their own. This method is
not implemented for UFS, so the described bug does not occur for UFS.

2. UFS currently does not use namecache at all, so this bug does not occur. See
here: https://reviews.freebsd.org/D41337, https://reviews.freebsd.org/D41338

I think it would be correct to modify the algorithm of the namei() and
cache_fplookup() functions so that file systems are not responsible for caching
symlink targets, ie, cache_fplookup() should stop its loop and return PARTIAL
in case of a symbolic link, and namei() should resolve the symlink and go to
the cache lookup starting from the current directory.

As a temporary fix, try this patch, please:
https://people.freebsd.org/~dchagin/vfs.patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 272878] hdac driver panics on boot on -CURRENT

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272878

Graham Perrin  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2643
   ||05
 CC||grahamper...@gmail.com
 Status|New |Open
   Severity|Affects Only Me |Affects Some People

--- Comment #2 from Graham Perrin  ---
Bug 268393 might be strictly (chronologically) a duplicate of earlier bug
264305. 

Triage team to decide which one of those two to keep open.

My feeling is to also make the remaining open bug a block of bug 271607. If not
for a fix, then a release note (or known issue listing) may be appropriate.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 264305] Crash on first boot

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264305

Graham Perrin  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2728
   ||78

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268393] system always reboots once from a powered off state

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268393

Graham Perrin ◐  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #53 from Graham Perrin ◐  ---
For convenience

(In reply to Jonathan Vasquez from comment #39)

> … my hw-probe …

Three hdac detected lines under
.
Condensed: 

1002:1640:1043:8877
AMD Rembrandt Radeon High Definition Audio Controller

1002:ab28:1002:ab28
AMD Navi 21/23 HDMI/DP Audio Controller

1022:15e3:1043:886d
AMD Family 17h/19h HD Audio Controller


(In reply to Alexander Sherikov from comment #52)

Two hdac detected lines under
.
Condensed: 

1002:1637:1d05:109f
AMD Renoir Radeon High Definition Audio Controller

1022:15e3:1d05:109f
AMD Family 17h/19h HD Audio Controller

-- 
You are receiving this mail because:
You are the assignee for the bug.