[Bug 262457] "zfs-list -v" duplicates most of the output; lack of "device" property to use with "-o" option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262457 free...@bitter-almonds.com changed: What|Removed |Added CC||free...@bitter-almonds.com Status|New |Closed Resolution|--- |Feedback Timeout -- You are receiving this mail because: You are the assignee for the bug.
[Bug 231768] [request] Disable COMPAT_FREEBSD4/5/6/7/9 as default kernel option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768 --- Comment #10 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=87bf0aaba8f1bd743d4df24ae422dd8075260d45 commit 87bf0aaba8f1bd743d4df24ae422dd8075260d45 Author: Henrich Hartzer AuthorDate: 2024-05-10 23:03:14 + Commit: Warner Losh CommitDate: 2024-05-23 20:30:57 + Remove COMPAT_FREEBSD4/5/6/7/9 from MINIMAL and FIRECRACKER kernel configurations FIRECRACKER is not a legacy config, so remove the really old FreeBSD versions from it. MINIMAL has a similar history, and limited target audience which has little to no overlap with really old binaries. Either of these is really easy to get additional binary compat with the include directive, so balance things better. Leave GENERIC alone. PR: 231768 Signed-off-by: Henrich Hartzer Reviewed by: imp (MINIMAL), cperciva (FIRECRACKER) Pull Request: https://github.com/freebsd/freebsd-src/pull/1228 sys/amd64/conf/FIRECRACKER | 5 - sys/amd64/conf/MINIMAL | 5 - sys/i386/conf/MINIMAL | 5 - 3 files changed, 15 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279261] i2c -sv reports stack garbage in message
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279261 Bug ID: 279261 Summary: i2c -sv reports stack garbage in message Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: j...@mit.edu Created attachment 250908 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250908=edit Initialize i2c_opt.addr to 0 # i2c -sv dev: /dev/iic0, addr: 0x6cfb7d5c, r/w: r, offset: 0x00, width: 8, count: 1 Hardware may not support START/STOP scanning; trying less-reliable read method. Scanning I2C devices on /dev/iic0: 11 # i2c -f /dev/iic1 -rv dev: /dev/iic1, addr: 0x1903955c, r/w: r, offset: 0x00, width: 8, count: 1 Resetting I2C controller on /dev/iic1 The address 0x6cfb7d5c or 0x1903955c is an uninitialized field in variable i2c_opt and varies from run to run. It is not actually relevant when scanning or resetting. The attached patch avoids printing the "dev:" line when verbose in scan or reset mode. The bus name is printed elsewhere and the rest of the fields are not relevant. It also initializes the address to 0 just in case it gets used somehow now or in the future. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 221151] panic: tdsendsignal(): invalid signal 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221151 Bob Prohaska changed: What|Removed |Added CC||f...@www.zefox.net --- Comment #11 from Bob Prohaska --- Here's another example, from an armv7 Raspberry Pi 2 v1.1 running: FreeBSD 14.0-RELEASE-p6 #51 releng/14.0-n265417-d338712beb16: Sat Apr 6 23:48:20 PDT 2024 b...@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm May 22 17:46:00 www sshd[5112]: error: PAM: Authentication error for root from innovexportsv.com May 22 17:46:50 www sshd[5115]: error: PAM: Authentication error for root from innovexportsv.com May 22 17:47:43 www sshd[5118]: error: PAM: Authentication error for root from innovexportsv.com panic: tdsendsignal(): invalid signal 0 cpuid = 1 time = 1716425284 KDB: stack backtrace: #0 0xc0362488 at kdb_backtrace+0x40 #1 0xc0309cf4 at vpanic+0x140 #2 0xc0309bb4 at vpanic+0 #3 0xc03121c0 at tdsendsignal+0xe40 #4 0xc0311098 at trapsignal+0x310 #5 0xc0654db4 at abort_handler+0x1a4 #6 0xc0633b98 at exception_exit+0 #7 0x203c8074 at _binary_sdma_imx6q_bin_size+0x203c77e0 Uptime: 45d7h10m56s Resetting system ... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 --- Comment #2 from Andriy Gapon --- (In reply to Vladimir Druzenko from comment #1) nvidia driver is only a victim here, it simply allocates memory and the allocator sees that the memory has been tampered with. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279249] quotactl(2) out of date w.r.t. ZFS, and missing information
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279249 Bug ID: 279249 Summary: quotactl(2) out of date w.r.t. ZFS, and missing information Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: g...@nxg.name CC: d...@freebsd.org The quotactl(2) manpage states bluntly that ‘Currently quotas are supported only for the "ufs" file system.’ But (a) bug #234413 from 2019/12.0, states that ‘ZFS implements quotactl(2) as of r336017; the man page needs to be updated.’ Also (b) quotactl does seem to work when called on a ZFS filesystem. Though it seems to work, does this work only by accident? (ie, is it going to stop working unexpectedly?). It would be good for the manpage to be explicit about this. Separately, the manpage doesn't give, or point to, relevant information on how to interpret the results of the call. I can call quotactl(2) on a ZFS filesystem and it produces numbers, which quota.h tells me are in units of disk blocks, and which are right if the block-size is 512B. But I can find nothing, neither in quotactl() nor in ufs/ufs/quota.h, which tells me that unequivocally, and in a way which I'm confident will work on a pool with a different ashift value. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 Vladimir Druzenko changed: What|Removed |Added CC||v...@freebsd.org --- Comment #1 from Vladimir Druzenko --- Did you install the nvidia driver from ports or from packages? How do you load it? Have you tried another load options? Have you tried other driver versions? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 Mark Linimon changed: What|Removed |Added Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279245] igc(4) I226 (and I225) TX hangups
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245 Mark Linimon changed: What|Removed |Added Keywords||IntelNetworking Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279245] igc(4) I226 (and I225) TX hangups
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245 Dr. Uwe Meyer-Gruhl changed: What|Removed |Added Summary|igc(4) I226 (and I225) |igc(4) I226 (and I225) TX |hangups |hangups -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279245] igc(4) I226 (and I225) hangups
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245
Bug ID: 279245
Summary: igc(4) I226 (and I225) hangups
Product: Base System
Version: 13.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: freebsd_em...@congenio.de
When using an I226 under OpnSense (FreeBSD 13.2-RELEASE kernel - I also tried
FreeBSD 14.0-RELEASE), I experience connection hangups about once per day under
no specific circumstances (maximum was 3 times within one hour, I also had none
in three days).
This problem manifests in a dead connection (no packets are received, note are
sent), but the low-level counters (dev.igc.0.mac_stats) still increase.
The conditon can be cleard up by bringing the interface down and up again or by
shortly disconnecting the cable.
There are reports on this and other related problems all over the internet for
different OSes, see:
Windows:
https://forums.evga.com/PSA-Intel-I226V-25GbE-on-Raptor-Lake-Motherboards-Has-a-Connection-Drop-Issue-No-Fix-m3595279.aspx
OpnSense (FreeBSD):
https://forum.opnsense.org/index.php?topic=40404.msg199288#msg199288
pfSense (FreeBSD):
https://forum.netgate.com/topic/181571/chinese-i226-v-on-23-05-1-problems
My specific variant is an I226-V, rev.4, built into a Minisforum MS-01:
igc0@pci0:87:0:0: class=0x02 rev=0x04 hdr=0x00 vendor=0x8086
device=0x125c subvendor=0x8086 subdevice=0x
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-V'
class = network
subclass = ethernet
However, there are reports of the I226-LM connected to the same machine showing
the same behaviour, see: https://forum.opnsense.org/index.php?topic=40556
igc1@pci0:88:0:0: class=0x02 rev=0x04 hdr=0x00 vendor=0x8086
device=0x125b subvendor=0x8086 subdevice=0x
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-LM'
class = network
subclass = ethernet
This seems to indicate that at least the I226 family (which is a successor to
the problem-ridden I225 using the same driver module) is affected by this
problem.
I tried all possible settings I could think of to make this go away, like
reducing the speed from 2.5 to 1 Gbps, disabling EEE (which is off by default
anyway) to no avail.
Interestingly, the Minisforum-MS01 has gained much interest in the last few
months and there was a specific review on Youtube were the creator states in a
comment that he is not seeing this problem
(https://www.youtube.com/watch?v=_wgX1sDab-M). However, he uses OpnSense under
a Proxmox hypervisor, thus using the Linux driver modules (OpnSense itself uses
the virtualized virtio NICs).
This and the reports of gamers stating they had "micro-hangs" manifesting as
short lags in online games got me thinking.
So I compared the Linux and FreeBSD drivers and found, that the Linux driver
has a specific routine to catch, protocol and clear "TX hang" conditions, see
from line 3150 here:
https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/intel/igc/igc_main.c,
which reads:
if (test_bit(IGC_RING_FLAG_TX_DETECT_HANG, _ring->flags)) {
struct igc_hw *hw = >hw;
/* Detect a transmit hang in hardware, this serializes the
* check with the clearing of time_stamp and movement of i
*/
clear_bit(IGC_RING_FLAG_TX_DETECT_HANG, _ring->flags);
if (tx_buffer->next_to_watch &&
time_after(jiffies, tx_buffer->time_stamp +
(adapter->tx_timeout_factor * HZ)) &&
!(rd32(IGC_STATUS) & IGC_STATUS_TXOFF) &&
(rd32(IGC_TDH(tx_ring->reg_idx)) != readl(tx_ring->tail))
&&
!tx_ring->oper_gate_closed) {
/* detected Tx unit hang */
netdev_err(tx_ring->netdev,
"Detected Tx Unit Hang\n"
" Tx Queue <%d>\n"
" TDH <%x>\n"
" TDT <%x>\n"
" next_to_use <%x>\n"
" next_to_clean<%x>\n"
"buffer_info[next_to_clean]\n"
" time_stamp <%lx>\n"
" next_to_watch<%p>\n"
" jiffies <%lx>\n"
" desc.status <%x>\n",
tx_ring->queue_index,
rd32(IGC_TDH(tx_ring->reg_idx)),
readl(tx_ring->tail),
[Bug 279243] panic: Memory modified after free, Most recently used by solaris
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279243 Bug ID: 279243 Summary: panic: Memory modified after free, Most recently used by solaris Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: a...@freebsd.org This happens on every other boot for me. When it happens it always happens when loading nvidia driver. <118>Mounting local filesystems:. <118>Mounting ZFS filesystems: (354/354) <118>Loading kernel modules: nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io <6>nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 550.54.14 Thu Feb 22 01:05:40 UTC 2024 sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! <6>[drm] [nvidia-drm] [GPU ID 0x0100] Loading driver Memory modified after free 0xf800207cf900(376) val=101 @ 0xf800207cf900 panic: Most recently used by solaris cpuid = 2 time = 1716443221 KDB: stack backtrace: db_trace_self_wrapper() at 0x80614c2b = db_trace_self_wrapper+0x2b/frame 0xfe01985cc060 kdb_backtrace() at 0x8094a037 = kdb_backtrace+0x37/frame 0xfe01985cc110 vpanic() at 0x808fba29 = vpanic+0x169/frame 0xfe01985cc250 panic() at 0x808fb803 = panic+0x43/frame 0xfe01985cc2b0 mtrash_ctor() at 0x80bb25ee = mtrash_ctor+0x7e/frame 0xfe01985cc2d0 item_ctor() at 0x80bb1818 = item_ctor+0x108/frame 0xfe01985cc320 uma_zalloc_arg() at 0x80baac3b = uma_zalloc_arg+0x10b/frame 0xfe01985cc360 malloc() at 0x808d4f60 = malloc+0x70/frame 0xfe01985cc3a0 os_alloc_mem() at 0x857de5f7 = os_alloc_mem+0x37/frame 0xfe01985cc3c0 _nv013606rm() at 0x854fc874 = _nv013606rm+0x34/frame 0xfe01a322fc00 Uptime: 42s "Most recently used by solaris" makes me think that the problem is in ZFS. Also, because the module loading happens right after mounting ZFS filesystems. The zone is "malloc-384". 24 initial bytes are affected: (kgdb) x/48a item 0xf800207cf900: 0x101 0x0 0xf800207cf910: 0x0 0xdeadc0dedeadc0de 0xf800207cf920: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf930: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf940: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf950: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf960: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf970: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf980: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf990: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9a0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9b0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9c0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9d0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9e0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cf9f0: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa00: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa10: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa20: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa30: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa40: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa50: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa60: 0xdeadc0dedeadc0de 0xdeadc0dedeadc0de 0xf800207cfa70: 0xdeadc0dedeadc0de 0x8121a800 -- You are receiving this mail because: You are the assignee for the bug.
