[Bug 243523] The default size of tmpmfs is not sufficient for pkg operation

[bugzilla-noreply]

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

Wolfram Schneider  changed:

   What|Removed |Added

 CC||wo...@freebsd.org
 Status|New |In Progress
   Assignee|b...@freebsd.org|wo...@freebsd.org

--- Comment #3 from Wolfram Schneider  ---
I think it is save to give the temp filesystem 1/10 or 1/4 of your available
RAM. Given that most if not all FreeBSD users will have 512MB for a VM I
suggest to increase the default value to 128MB.

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

[Bug 268711] 20 m default for /tmp – tmpmfs="YES" in rc.conf(5) – is too little for things such as ports-mgmt/pkg pkg-update(8) and Electron-based applications

[bugzilla-noreply]

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

Wolfram Schneider  changed:

   What|Removed |Added

 CC||wo...@freebsd.org
 Depends on||243523


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243523
[Bug 243523] The default size of tmpmfs is not sufficient for pkg operation
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268827] Network-related manual pages: promote use of sysrc(8) to safely edit system rc files

[bugzilla-noreply]

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

Bug ID: 268827
   Summary: Network-related manual pages: promote use of sysrc(8)
to safely edit system rc files
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: grahamper...@freebsd.org
CC: d...@freebsd.org

At pages such as

(currently for 13.1-RELEASE) and

(currently for 14.0-CURRENT):  

> … place the following lines in rc.conf(5) to manually load the driver 
> as a module at boot   time:
> 
>  kld_list="${kld_list} if_iwlwifi"

Instead, a command: 

   sysrc kld_list+=if_iwlwifi

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

[Bug 178113] tmpmfs rc.conf setting ignored

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@freebsd.org
Summary|[rc.conf] tmpmfs rc.conf|tmpmfs rc.conf setting
   |setting ignored |ignored

--- Comment #3 from Graham Perrin  ---
Triage: removing [tagging] from the summary line. 



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

[Bug 268711] 20 m default for /tmp – tmpmfs="YES" in rc.conf(5) – is too little for things such as ports-mgmt/pkg pkg-update(8) and Electron-based applications

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|grahamper...@freebsd.org
 Resolution|--- |DUPLICATE
 Depends on|243523  |
 Status|Open|Closed

--- Comment #8 from Graham Perrin  ---
Closing as a duplicate – OK'd with Wolfram (assignee of bug 243523). 

My bad. It should have been easy for me to find 243523. 

(Privately, I do know what caused me to not search properly on this occasion …
lesson learnt.)

*** This bug has been marked as a duplicate of bug 243523 ***


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243523
[Bug 243523] The default size of tmpmfs is not sufficient for pkg operation
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268828] panic: main-n259921-17f2b12a3877 panicked (Fatal trap 12: page fault while in kernel mode)

[bugzilla-noreply]

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

Bug ID: 268828
   Summary: panic: main-n259921-17f2b12a3877 panicked (Fatal trap
12: page fault while in kernel mode)
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: i...@amail.plala.or.jp

Created attachment 239342
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239342&action=edit
textdump.tar.1.xz

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address   = 0x1ac
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x80ce3c7c
stack pointer   = 0x28:0xfe00edb6fce0
frame pointer   = 0x28:0xfe00edb6fce0
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 = 1782 (nfsd: master)
rdi:0 rsi:0 rdx:0
rcx: fe0093c7c3c0  r8:   80  r9:1
rax:  rbx: fe00edb701a8 rbp: fe00edb6fce0
r10:1 r11:1 r12: fe00edb6ff78
r13:0 r14:1 r15: fe00edb6ffd0
trap number = 12
panic: page fault
cpuid = 1
time = 1673187203
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00edb6faa0
vpanic() at vpanic+0x151/frame 0xfe00edb6faf0
panic() at panic+0x43/frame 0xfe00edb6fb50
trap_fatal() at trap_fatal+0x409/frame 0xfe00edb6fbb0
trap_pfault() at trap_pfault+0xab/frame 0xfe00edb6fc10
calltrap() at calltrap+0x8/frame 0xfe00edb6fc10
--- trap 0xc, rip = 0x80ce3c7c, rsp = 0xfe00edb6fce0, rbp =
0xfe00edb6fce0 ---
vrele() at vrele+0xc/frame 0xfe00edb6fce0
nfsvno_open() at nfsvno_open+0x1c7/frame 0xfe00edb6fd70
nfsrvd_open() at nfsrvd_open+0xe51/frame 0xfe00edb701f0
nfsrvd_dorpc() at nfsrvd_dorpc+0x1386/frame 0xfe00edb70400
nfssvc_program() at nfssvc_program+0x5e2/frame 0xfe00edb705e0
svc_run_internal() at svc_run_internal+0xa42/frame 0xfe00edb70710
svc_run() at svc_run+0x250/frame 0xfe00edb70770
nfsrvd_nfsd() at nfsrvd_nfsd+0x338/frame 0xfe00edb708d0
nfssvc_nfsd() at nfssvc_nfsd+0x524/frame 0xfe00edb70de0
sys_nfssvc() at sys_nfssvc+0xb0/frame 0xfe00edb70e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe00edb70f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe00edb70f30
--- syscall (155, FreeBSD ELF64, nfssvc), rip = 0x28e1eabcef2a, rsp =
0x28e1e8317598, rbp = 0x28e1e8317830 ---
KDB: enter: panic

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

[Bug 268828] panic: main-n259921-17f2b12a3877 panicked (Fatal trap 12: page fault while in kernel mode)

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

 Status|New |Open
 CC||grahamper...@freebsd.org
   Keywords||crash

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

[Bug 268827] Network-related manual pages: promote use of sysrc(8) to safely edit system rc files

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|wirel...@freebsd.org
 Status|New |Open

--- Comment #1 from Graham Perrin  ---
(The two pages above drew attention after I found a spelling mistake, which
I'll correct separately.)

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

[Bug 268830] After 12.3 to 13.1 upgrade, failed to mount zfs filesystems

[bugzilla-noreply]

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

Bug ID: 268830
   Summary: After 12.3 to 13.1 upgrade, failed to mount zfs
filesystems
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: l...@ofwilsoncreek.com

13.1 (and possibly 13.0) appears unable to mount a filesystem by the name of
"tank/.". My pattern has been to set mountpoint=/ and canmount=off for tank.
Then I create a descendent filesystem called "tank/." and let it inherit the
mountpoint. Why? Using "tank" for / is troublesome because it cannot be
renamed, and any special properties get inherited by all others (which some
would argue is appropriate but I find necessitates override settings on all
other filesystems). Having the mountpoint inherit instead of explicitly setting
it to / allows such a rename to be performed without a "tripping hazard" of
forgetting to update the mountpoint property.

I totally understand if there's a new reason this can't be supported. I can
endure losing my clever trick. However, I believe there at least needs to be a
path to recovery, short of using 12.3 boot media; that is, `zfs rename` needs
to work. Everything I could think of post-upgrade has failed.

Here are details of what happened.

After upgrading from 12.3 to 13.1, the kernel successfully mounted the root
filesystem and booted, but rc failed to mount any other ZFS filesystems, such
as tank/home.

  # mount
  tank/. on / (zfs, local, noatime, nfsv4acls)
  devfs on /dev (devfs)
  fdescfs on /dev/fd (fdescfs)
  procfs on /proc (procfs, local)

Baffled as to what was going on, I wondered if the other filesystems were
intact:

  # zfs list
  internal error: cannot iterate filesystems: Invalid argument
  Abort trap (core dumped)

I was able to mount them explicitly:

  # zfs mount tank/home 
  # ls /home
  [correct output, redacted]

Wondering if something in the upgrade failed, I tried rollback:

  # zfs rollback -r tank/.@2023-01-07.12.3-RELEASE-p5
  cannot open 'tank/.': self reference, '.' is found in name

This thankfully told me the problem with a correct error message, so I figured
I needed to rename from my clever name of `tank/.` to something else, but I
couldn't:

  # zfs rename -u tank/. tank/_
  cannot open 'tank/.': self reference, '.' is found in name
  # zfs set mountpoint=/ tank/.
  cannot open 'tank/.': self reference, '.' is found in name

My only recourse appears to be booting 12.3 media and renaming the filesystem.
Happily I was able to rename it using 12.3 and set the explicit mountpoint
without rollback or other hassle.

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

Problem reports for b...@freebsd.org that need special attention

[bugzilla-noreply]

To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status  |Bug Id | Description
+---+---
New |197876 | [devfs] an error in devfs leads to data loss and  
New |198797 | [PATCH] Added an option to install BSDstats to bs 
New |202362 | ntp: restore refclocks selection (10.2-RELEASE re 
New |202740 | vi/ex string substitution problem when there is m 
New |204097 | witness_initialize() does not perform bound check 
New |206336 | [patch] usr.sbin/freebsd-update allow proxy confi 
New |209213 | UEFI Loader shows only black screen with Nvidia G 
New |210804 | installerconfig - using ZFS create in custom scri 
New |223470 | freebsd-update: Cannot identify running kernel (/ 
New |230620 | "install -d" issue
New |235085 | [PATCH] Option to make rc.d/sysctl more verbose ( 
New |252123 | fetch(3): Fix wrong usage of proxy when request i 
Open|177821 | sysctl: Some security.jail nodes are funky, dupli 
Open|182466 | [headers] [patch] make  self-contained  
Open|183618 | [panic] Dell PowerEdge R620 -- PERC H710 Mini (mf 
Open|192573 | Add ps(1) option: Print process start time in sec 
Open|194925 | [pf] [ifconfig] interface group keywords do not w 
Open|197921 | scheduler: Allow non-migratable threads to bind t 
Open|206528 | Emulex LPe 16002 FC HBA Not Recognized by oce(4)  
Open|206649 | cyapa(4): Add common gestures for Cypress APA I2C 
Open|212608 | sockstat(1) and lsof(8) can not identity the owne 
Open|220246 | syslogd does not send RFC3164-conformant messages 
Open|221305 | Mouse cursor loss when moving cursor while loadin 
Open|221550 | kern.bootfile returns only /kernel on mips64 (ERL 
Open|221854 | makefs: Reject UFS labels that are too long to fi 
Open|226893 | freebsd-update: Support patchlevel argument for f 
Open|231810 | [build] release always fails with "mkimg: partiti 
Open|233578 | Unprivileged local user can prevent other users l 
Open|233988 | freebsd-update: Improve progress output on termin 
Open|236718 | system panics with message: vm_fault_hold: fault  
Open|237287 | moused(8) ignores button release events in virtua 
Open|237924 | Possible infinite loop in function empty_aux_buff 
Open|238183 | cam/scsi/scsi_sa.c: warnings issued by static ana 
Open|238486 | Possible buffer overflow bug in sc_allocate_keybo 
Open|238550 | Touchpad (via SMBus) not working: Synaptics (SYN1 
Open|238638 | mfi: Remove unnecessary pointer printing in mfi.c 
Open|238837 | init: Remove P_SYSTEM flag from PID 1 to allow ea 
Open|241697 | i915kms: Kernel panic loading module on custom ke 
Open|247132 | Fix build error: use of undeclared identifier 'cp 
Open|248352 | mfi(4): Remove RAID map sync functionality
Open|257149 | CFLAGS not passed to whole build  

41 problems total for which you should take action.

[Bug 268830] After 12.3 to 13.1 upgrade, with a ZFS dataset named 'tank/.': mount failures

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|f...@freebsd.org
 CC||grahamper...@freebsd.org
   Keywords||needs-qa
Summary|After 12.3 to 13.1 upgrade, |After 12.3 to 13.1 upgrade,
   |failed to mount zfs |with a ZFS dataset named
   |filesystems |'tank/.': mount failures
 Status|New |Open

--- Comment #1 from Graham Perrin  ---
Consider this, from : 

[A-Za-z_.:/ -]


Was bectl(8) in 12.3 used before the attempted upgrade?



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

[Bug 268832] panics in check_uidgid() for outgoing packets

[bugzilla-noreply]

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

Bug ID: 268832
   Summary: panics in check_uidgid() for outgoing packets
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: nik...@druba.su

Created attachment 239348
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239348&action=edit
kgdb -n last; bt

Hi!
Several days ago I was update of my FreeBSD from 12.3 to 13.1 and got the next
trouble:
After boot fully updated OS(with packages), the OS freeze without any comments.
I didn't have a chance to get some information about error or safely power off
the system. It was fully freezed. 
OS was binary updated by freebsd-update. Freezing also repeated after switching
to 13.1-RELENG kernel, builded from sources. 
After some time of troubleshooting and help from colleagues, got some idea
about the reasons of this error.
Presumably, it was some component of ipfw. In attachments is ipfw show output,
There a few lines at the beginning of rules is a counts, automatically added by
cbsdd. In FreeBSD 12.3 they worked without errors, but after upgrade led to the
described problem. When I disabling this cbsdd function, OS working well and
dont try to freeze. 
To be more specific, I will describe the well-reproducing event, where I get an
freezing. After compiling kernel with debug options I got a possibility to saw
a reason of freeze. With debug kernel system stopped freezing, showed me kernel
panic message and rebooted OS. In attachments I will rest backtrace of this
event. 
Sequencing: 
Booting updated OS (without jails and any VMs, only primitive service apps), 
starting jail with a postgres (its can stable work a long time)
starting jail with a zabbix-server (that start to interact with a postgres
jail)
after 10-60 seconds after launch of zabbix jail I get kernel panic.

I can easily repeat sequencing and get panic again to collect more information,
if it needed.

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

[Bug 268832] panics in check_uidgid() for outgoing packets

[bugzilla-noreply]

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

--- Comment #1 from nik...@druba.su  ---
Created attachment 239349
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239349&action=edit
ipfw show

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

[Bug 268835] Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma

[bugzilla-noreply]

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

Bug ID: 268835
   Summary: Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma
   Product: Base System
   Version: CURRENT
  Hardware: arm64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: marklmi26-f...@yahoo.com
CC: m...@freebsd.org

Created attachment 239352
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239352&action=edit
main [so: 14]: Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma

Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma
for both main [so: 14] and stable/13 .

I'll also be adding an attachment for the stable/13 case
since stable/13 and main do not match in the very few lines
involved.

This avoids crashes for booting with newer RPi* firmware
than is in sysutils/rpi-firmware . But this is not a proposal
for updating sysutils/rpi-firmware at all.

I've my own interest in testing something with newer firmware.
I've also seen reports about *.dtb files that do not exist
in sysutils/rpi-firmware . At some point someone might put in
the work to add support for such RPi* devices. If anyone does,
they likely would like to avoid the stage if dealing with the
boot-crash that now happens.

My test context had:

"C0T" 8 GiByte Rev1.5 RPi4B
"B0T" 8 GiByte Rev1.4 and 4 GiByte Rev1.1 RPI4Bs
RPi3B
RPi2B v1.2
RPi2B v1.1 (so: armv7)

and some non-RPi*'s:

ThreadRipper 1950X (so an amd64)
HoneyComb
MACCHIATObin Double Shot
Rock64
OrangePi+2ed (so: armv7)

For aarch64 and armv7, I test the same boot media both
on RPi*'s and at least one non-RPi*  My testing spanned
main and stable/13 examples.

I've tried multiple tagged RPI* firmware releases and none
lead to a crash with the change in place. The non-RPI*'s
continued to work normally.

For reference, all the boot media are now at (picking an
example system):

# uname -apKU # Long output line split for readability
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #75
main-n259950-5723e5ac6d76-dirty: Fri Jan  6 01:50:53 PST 2023
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400077 1400077

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

[Bug 268835] Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma

[bugzilla-noreply]

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

--- Comment #1 from Mark Millard  ---
Created attachment 239353
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239353&action=edit
stable/13: Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma

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

[Bug 267782] AMD Ryzen 5 hangs on 13.1, fine on 12.3

[bugzilla-noreply]

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

krone...@gmail.com changed:

   What|Removed |Added

 CC||krone...@gmail.com

--- Comment #1 from krone...@gmail.com ---
I believe I have a similar problem with OpnSense 22.7 (13.1) under LibVirt/QEMU
on a Gigabyte Aorus Motherboard (Gigabyte Technology Co., Ltd. X570 AORUS
MASTER/X570 AORUS MASTER, BIOS F30 09/07/2020)

FreeBSD 13.0-RELEASE works fine, as does OpnSense 22.1 (13.0 also). FreeBSD
13.1-RELEASE crashes in weird ways but OpnSense freezes during kernel init. I
haven't been able to capture a screenshot - it flies by quickly.

The host is a Fedora 36 system.

CPU Info:
Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 43 bits physical, 48 bits virtual
  Byte Order:Little Endian
CPU(s):  24
  On-line CPU(s) list:   0-23
Vendor ID:   AuthenticAMD
  Model name:AMD Ryzen 9 3900XT 12-Core Processor
CPU family:  23
Model:   113
Thread(s) per core:  2
Core(s) per socket:  12
Socket(s):   1
Stepping:0
Frequency boost: enabled
CPU(s) scaling MHz:  46%
CPU max MHz: 4775.9761
CPU min MHz: 2200.
BogoMIPS:7599.92
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush
  mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm constant_tsc
  rep_good nopl nonstop_tsc cpuid extd_apicid
aperfmperf rapl pni pclmulqdq moni
 tor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes
xsave avx f16c rdrand lahf_lm
  cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs
  skinit wdt tce topoext perfctr_core perfctr_nb bpext
perfctr_llc mwaitx cpb ca
 t_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall
fsgsbase bmi1 avx2 smep bmi2 
 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni
xsaveopt xsavec xgetbv1 xsaves
  cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local
clzero irperf xsaveerptr rdp
 ru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clean flushbyasid d
 ecodeassists pausefilter pfthreshold avic
v_vmsave_vmload vgif v_spec_ctrl umip
  rdpid overflow_recov succor smca sev sev_es
Virtualization features: 
  Virtualization:AMD-V
Caches (sum of all): 
  L1d:   384 KiB (12 instances)
  L1i:   384 KiB (12 instances)
  L2:6 MiB (12 instances)
  L3:64 MiB (4 instances)
NUMA:
  NUMA node(s):  1
  NUMA node0 CPU(s): 0-23
Vulnerabilities: 
  Itlb multihit: Not affected
  L1tf:  Not affected
  Mds:   Not affected
  Meltdown:  Not affected
  Mmio stale data:   Not affected
  Retbleed:  Mitigation; untrained return thunk; SMT enabled with
STIBP protection
  Spec store bypass: Mitigation; Speculative Store Bypass disabled via
prctl
  Spectre v1:Mitigation; usercopy/swapgs barriers and __user
pointer sanitization
  Spectre v2:Mitigation; Retpolines, IBPB conditional, STIBP
always-on, RSB filling, PBRSB-e
 IBRS Not affected
  Srbds: Not affected
  Tsx async abort:   Not affected

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

[Bug 268828] panic: main-n259921-17f2b12a3877 panicked (Fatal trap 12: page fault while in kernel mode)

[bugzilla-noreply]

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

Rick Macklem  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|rmack...@freebsd.org

--- Comment #1 from Rick Macklem  ---
Created attachment 239354
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239354&action=edit
revert removal of a check for ni_startdir being non-NULL

This patch reverts a small part of 65127e982b94,
which I think caused this crash.

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