[Bug 224496] mpr and mps drivers seems to have issues with large seagate drives

[bugzilla-noreply]

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

--- Comment #57 from Michel Le Cocq  ---
no more trouble since upgrade to 14.0.

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

[Bug 276402] tmpfs: memory reserve does not account for ARC

[bugzilla-noreply]

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

Bug ID: 276402
   Summary: tmpfs: memory reserve does not account for ARC
   Product: Base System
   Version: 15.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: throwaway_vthg...@protonmail.com

When there is tmpfs entry in fstab without size specified, e.g.

none /var/run/user tmpfs rw

And ZFS ARC fills available memory fully, writes to tmpfs will fail with no
space left on device, ARC won't be reclaimed. This results in hangs when
switching browser tabs or spawning Wayland clients in e.g. x11-wm/sway which
uses XDG_RUNTIME_DIR on tmpfs.

Disabling memory reserve with

sysctl vfs.tmpfs.memory_percent=100

restores old behavior (ARC is reclaimed for tmpfs) and gets rid of hangs in
x11-wm/sway.

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

[Bug 276405] Panic: data storage interrupt trap

[bugzilla-noreply]

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

Bug ID: 276405
   Summary: Panic: data storage interrupt trap
   Product: Base System
   Version: 13.2-RELEASE
  Hardware: powerpc
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: luci...@vespaperitivo.it

On heavy io, kernel panics.

>From info.0:

Dump header from device: /dev/da1p1
  Architecture: powerpc64
  Architecture Version: 1
  Dump Length: 1728684032
  Blocksize: 512
  Compression: none
  Dumptime: 2024-01-17 14:30:06 +0100
  Hostname: ekaguaro
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 13.2-RELEASE-p9 releng/13.2-n254652-c78c31d2ef40
GENERIC
  Panic String: data storage interrupt trap
  Dump Parity: 816171299
  Bounds: 0
  Dump Status: good

core0.txt:
Unable to find a kernel debugger.
Please install the devel/gdb port or gdb package.

There is no gdb installed on this machine. I'll install it.

On another sibling I get:

info.1:

Dump header from device: /dev/vtbd0s2b
  Architecture: powerpc64
  Architecture Version: 1
  Dump Length: 903544832
  Blocksize: 512
  Compression: none
  Dumptime: 2024-01-16 11:36:57 +0100
  Hostname: numeron
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 13.2-RELEASE-p9 releng/13.2-n254652-c78c31d2ef40
GENERIC
  Panic String: data storage interrupt trap
  Dump Parity: 1018450777
  Bounds: 1
  Dump Status: good

core.txt.1:

umeron dumped core - see /var/crash/vmcore.1

Tue Jan 16 11:38:42 CET 2024

FreeBSD numeron 13.2-RELEASE-p9 FreeBSD 13.2-RELEASE-p9
releng/13.2-n254652-c78c31d2ef40 GENERIC  powerpc

panic: data storage interrupt trap

GNU gdb (GDB) 13.2 [GDB v13.2 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-portbld-freebsd13.2".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...
Failed to open vmcore: invalid corefile
(kgdb) 

Fatal signal: Segmentation fault
- Backtrace -
0x107c795f ???
0x10931e0f ???
0x10932a8b ???
0x812d05187 handle_signal
/usr/src/lib/libthr/thread/thr_sig.c:303
0x812d04343 thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:246
-
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
.

Segmentation fault (core dumped)



ps -axlww

ps: invalid corefile


vmstat -s

vmstat: kvm_openfiles: invalid corefile


vmstat -m

vmstat: kvm_openfiles: invalid corefile


vmstat -z

vmstat: kvm_openfiles: invalid corefile


vmstat -i

vmstat: kvm_openfiles: invalid corefile


pstat -T

pstat: kvm_openfiles: invalid corefile


pstat -s

pstat: kvm_openfiles: invalid corefile


iostat

iostat: kvm_openfiles: invalid corefile


ipcs -a

ipcs: kvm_openfiles: invalid corefile


ipcs -T

ipcs: kvm_openfiles: invalid corefile


netstat -s

netstat: kvm not available: invalid corefile


netstat -m

netstat: kvm not available: invalid corefile
netstat: kvm not available: invalid corefile


netstat -anA

netstat: kvm not available: invalid corefile


netstat -aL

netstat: kvm not available: invalid corefile

[Bug 276405] Panic: data storage interrupt trap

[bugzilla-noreply]

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

Luciano Mannucci  changed:

   What|Removed |Added

 CC||luci...@vespaperitivo.it

--- Comment #1 from Luciano Mannucci  ---
Of course vmcore are a bit big; I can upload them somewhere if needed.

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

[Bug 276406] arm64 ddb: x/hx truncates value to 32bit

[bugzilla-noreply]

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

Bug ID: 276406
   Summary: arm64 ddb: x/hx truncates value to 32bit
   Product: Base System
   Version: 14.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: d...@rabson.org

Note: the high bits of this value should be 0x as seen in the x/x
output.

Stopped at  kdb_sysctl_enter+0x98:  str xzr, [x19, #256]
db> x/x preload_metadata
preload_metadata:   1874000
db>
preload_metadata+0x4:   
db> x/gx preload_metadata
preload_metadata:   1874000

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

[Bug 276406] arm64 ddb: x/hx truncates value to 32bit

[bugzilla-noreply]

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

Mitchell Horne  changed:

   What|Removed |Added

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

--- Comment #1 from Mitchell Horne  ---
I managed to find the issue fairly quickly. Thanks for the report.

https://reviews.freebsd.org/D43479

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

[Bug 276392] if_wg: Fix noise_remote_alloc() to acquire 'l_identity_lock' lock

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

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

[Bug 276402] tmpfs: memory reserve does not account for ARC

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|f...@freebsd.org

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

[Bug 276405] Panic: data storage interrupt trap

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Keywords||crash

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

[Bug 276376] arm64 ddb: the disassembler does not recognise STP instructions

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

  Component|kern|arm
   Assignee|b...@freebsd.org|freebsd-...@freebsd.org

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

[Bug 276379] snd_hda: Intel 700 Series Chipset not supported (pci_id 8086:7a50)

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|multime...@freebsd.org

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

[Bug 276408] panic: Assertion error == EJUSTRETURN failed at msdosfs_vnops.c:1195

[bugzilla-noreply]

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

Bug ID: 276408
   Summary: panic: Assertion error == EJUSTRETURN failed at
msdosfs_vnops.c:1195
   Product: Base System
   Version: 13.2-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: j...@mit.edu

I used rsync to copy data to a FAT32 filesystem.  My system
crashed with an assertion failure in msdosfs_rename.

I think the problem is bad error recovery.  The first three lines of
the core.txt below were in the message buffer but were not copied to
/var/log/messages.  They must have all happened in quick succession.
So the kernel marked the filesystem read-only due to an error and
the rename failed in an impossible way as a result.

My kernel is 13.2-STABLE up through commit 4c4633fdffbe.

The filesystem was mounted with -L zh_CN.UTF-8.  This probably does
not matter.  The data is on ~10 year old USB drive that was mostly
used with Windows.  I am trying to clone the disk to reproduce the
crash.

/mnt: Freeing unused sector 7185542 6 f001
/dev/da13s1: remounting read-only due to corruption
panic: Assertion error == EJUSTRETURN failed at
/usr/home/jfc/freebsd/src/sys/fs/msdosfs/msdosfs_vnops.c:1195
cpuid = 1
time = 1705507114
KDB: stack backtrace:
#0 0x80c1a1d5 at kdb_backtrace+0x65
#1 0x80bcf522 at vpanic+0x152
#2 0x80bcf323 at panic+0x43
#3 0x80a78775 at msdosfs_rename+0xc45
#4 0x8115c81d at VOP_RENAME_APV+0x3d
#5 0x80cc02de at kern_renameat+0x3ee
#6 0x8108aec0 at amd64_syscall+0x140
#7 0x810601eb at fast_syscall_common+0xf8

[...]

#4  0x80bcf323 in panic (fmt=)
at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:845
ap = {{gp_offset = 32, fp_offset = 48, 
overflow_arg_area = 0xfe05a6054a90, 
reg_save_area = 0xfe05a6054a30}}
#5  0x80a78775 in msdosfs_rename (ap=)
at /usr/home/jfc/freebsd/src/sys/fs/msdosfs/msdosfs_vnops.c:1195
toname = "2014VA~1JPG"
oldname = "2014VA~1NRU"
tdvp = 0xf806c7001000
fdvp = 0xf806c7001000
fvp = 0xf806791725b8
tvp = 0x0
tcnp = 0xfe05a6054c48
fcnp = 0xfe05a6054d20
pmp = 0xf8123e23de00
error = 
checkpath_locked = 
newparent = 
doingdirectory = 
blkoff = 2720
scn = 146065
nip = 
vp = 
fdip = 0xf8144ffc0400
fip = 0xf825f2a81d00
tdip = 0xf8144ffc0400
tip = 
to_diroffset = 2720
wait_scn = 
cn = 
bn = 
bp = 
dotdotp = 
pcl = 
#6  0x8115c81d in VOP_RENAME_APV (
vop=0x81aaf600 , a=a@entry=0xfe05a6054d78)
at vnode_if.c:1672
rc = 
#7  0x80cc02de in VOP_RENAME (fdvp=, 
fvp=, tdvp=, tvp=, 
fcnp=, tcnp=) at ./vnode_if.h:853
a = {a_gen = {a_desc = 0x81b4ed70 }, 
  a_fdvp = 0xf806c7001000, a_fvp = 0xf806791725b8, 
  a_fcnp = 0xfe05a6054d20, a_tdvp = 0xf806c7001000, 
  a_tvp = 0xf806a87c9000, a_tcnp = 0xfe05a6054c48}
#8  kern_renameat (td=0xfe03b0400020, oldfd=-100, 
old=0x820c39d00 , 
newfd=-100, 
new=0x820c3a500 , 
pathseg=UIO_USERSPACE)
at /usr/home/jfc/freebsd/src/sys/kern/vfs_syscalls.c:3732
fromnd = {
  ni_dirp = 0x820c39d00 , ni_segflg = UIO_USERSPACE, 
  ni_rightsneeded = 0x81a016b8 , 
  ni_startdir = 0xf806c7001000, ni_rootdir = 0xf801429aa1e8, 
  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 = 0xf806791725b8, 
  ni_dvp = 0xf806c7001000, ni_resflags = 0, ni_debugflags = 3, 
  ni_loopcnt = 0, ni_pathlen = 1, ni_next = 0xf80175e1441d "", 
  ni_cnd = {cn_origflags = 264208, cn_flags = 285476880, 
cn_thread = 0xfe03b0400020, cn_cred = 0xf80d38c6cd00, 
cn_nameiop = DELETE, cn_lkflags = 2097152, 
cn_pnbuf = 0xf80175e14400 ".2014ValentineBack.JPG.NrU9fM", 
cn_nameptr = 0xf80175e14400 ".2014ValentineBack.JPG.NrU9fM", 
cn_namelen = 29}, ni_cap_tracker = {tqh_first = 0x0, 
tqh_last = 0xfe05a6054d60}, ni_dvp_seqc = 1977697309, 
  ni_vp_seqc = 4294965249}
tond = {
  ni_dirp = 0x820c3a500 , ni_segflg = UIO_USERSPACE, 
  ni_rightsneeded = 0x81a016c8 , 
  ni_startdir = 0xf806c7001000, ni_rootdir = 0xf801429aa1e8, 
  ni_topdir = 0x0, ni_dirfd = -100, ni_lcf = 0, ni_filecaps = {
fc_rights = 

[Bug 276408] panic: Assertion error == EJUSTRETURN failed at msdosfs_vnops.c:1195

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|f...@freebsd.org

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

[Bug 268653] /src/sys/dev/hyperv/input/hv_kbd.c error: use of undeclared identifier 'keycode'

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

 CC|grahamper...@freebsd.org|
   Assignee|b...@freebsd.org|virtualizat...@freebsd.org

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

[Bug 224496] mpr and mps drivers seems to have issues with large seagate drives

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|bugmeis...@freebsd.org
 Resolution|--- |Overcome By Events
 Status|New |Closed

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

[Bug 237653] LUA loader cannot choose ZFS pool to boot

[bugzilla-noreply]

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

Warner Losh  changed:

   What|Removed |Added

 CC||i...@freebsd.org

--- Comment #4 from Warner Losh  ---
I've been switching between zpools and BEs on my 14.x and 15.x based boxes.

Is this bug still relevant in 13 or newer?

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

[Bug 263171] add loader(8) and boot loader menu support for boot with OpenZFS-encrypted ROOT

[bugzilla-noreply]

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

Warner Losh  changed:

   What|Removed |Added

 CC||i...@freebsd.org

--- Comment #1 from Warner Losh  ---
Is there a patch?

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

[Bug 268866] tcsh: Segmentation fault

[bugzilla-noreply]

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

wilkinsonwilfrid  changed:

   What|Removed |Added

 CC||wilkinsonwilfri...@gmail.co
   ||m

--- Comment #13 from wilkinsonwilfrid  ---
The accompanying configuration file should work for you. Under 13.1-RELEASE,
you might just hit crash.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268866
https://geometry-dash.io/

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

[Bug 276413] The disk size for VM-IMAGES/14.0-RELEASE is unreasonable

[bugzilla-noreply]

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

Bug ID: 276413
   Summary: The disk size for VM-IMAGES/14.0-RELEASE is
unreasonable
   Product: Base System
   Version: 14.0-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: dcla...@blastwave.org

Merely a comment that the vm disk images provided at : 

https://download.freebsd.org/releases/VM-IMAGES/14.0-RELEASE/amd64/Latest/

are too small to even do a trivial update ...

.
.
.

root@freebsd:~ # uname -apKU 
FreeBSD freebsd 14.0-RELEASE FreeBSD 14.0-RELEASE #0
releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
amd64 1400097 1400097
root@freebsd:~ # 
root@freebsd:~ # freebsd-update fetch   
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.   
Fetching metadata signature for 14.0-RELEASE from update2.freebsd.org... done.  
Fetching metadata index... done.
Fetching 2 metadata files... done.  
Inspecting system... done.  
Preparing to download files... done.
Fetching 296
patches.102030405060708090100110120130140150...
160170180190200210220230240250260...270280290...
done.
Applying patches... 
/: write failed, filesystem is full


Yikes.


-- 
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

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

[Bug 276414] rtnetlink: destroying an interface generates spurious RTM_NEWLINKs

[bugzilla-noreply]

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

Bug ID: 276414
   Summary: rtnetlink: destroying an interface generates spurious
RTM_NEWLINKs
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: lexi.free...@le-fay.org

tested on FreeBSD 15.0-CURRENT #8 main-n267554-c8328f1a7b6e

when an interface is destroyed, an rtnetlink socket monitoring RTNLGRP_LINK
will get 1 or more spurious RTM_NEWLINKS, followed by the actual RTM_DELLINK.

this can be observed with 'route monitor' which uses netlink:

# ifconfig bridge1 create

03:49:47.538 PID 10747 add/repl iface iface#8 bridge1 admin DOWN oper DOWN mtu
1500

# ifconfig bridge1 destroy

03:50:14.124 PID 10747 add/repl iface iface#8 bridge1 admin DOWN oper DOWN mtu
1500
03:50:14.124 PID 10747 delete iface iface#8 bridge1 admin DOWN oper DOWN mtu
1500

with wg(4) interfaces, there are several spurious RTM_NEWLINKs after destroy:

03:50:44.607 PID 10747 add/repl iface iface#8 wg1 admin DOWN oper DOWN mtu 1420
03:50:44.607 PID0 add/repl iface iface#8 wg1 admin DOWN oper DOWN mtu 1420
03:50:44.654 PID 10747 add/repl iface iface#8 wg1 admin DOWN oper DOWN mtu 1420
03:50:44.654 PID0 delete iface iface#8 wg1 admin DOWN oper DOWN mtu 1420

i'm not particularly familiar with the netlink API, but from reading the
documentation, this isn't the behaviour i'd expect.

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

[Bug 276414] rtnetlink: destroying an interface generates spurious RTM_NEWLINKs

[bugzilla-noreply]

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

Kyle Evans  changed:

   What|Removed |Added

 CC||b...@freebsd.org,
   ||kev...@freebsd.org
   Assignee|b...@freebsd.org|melif...@freebsd.org

--- Comment #1 from Kyle Evans  ---
Let's send it to melifaro@ for comment to start with

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