[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 SJ changed: What|Removed |Added CC||sa...@rbrd.io --- Comment #24 from SJ --- Experiencing issues with the BCM57416 on new hardware, with a fresh install of FreeBSD 13.0. Firmware version shipped with card: 22.00.07.60 % uname -a FreeBSD foo 13.0-RELEASE-p11 FreeBSD 13.0-RELEASE-p11 On running `kldload /boot/kernel/if_bnxt.ko`, the following appears in /var/log/messages: May 19 10:37:17 foo kernel: bnxt0: mem 0xb8a1-0xb8a1,0xb890-0xb89f,0xb8a22000-0xb8a23fff at device 0.0 numa-domain 0 on pci9 May 19 10:37:17 foo kernel: bnxt0: Using 256 TX descriptors and 256 RX descriptors May 19 10:37:17 foo kernel: bnxt0: Using 0 RX queues 0 TX queues May 19 10:37:17 foo kernel: bnxt0: Using MSI-X interrupts with 1 vectors May 19 10:37:17 foo kernel: bnxt0: iflib_dma_alloc_align: bus_dma_tag_create failed: 22 May 19 10:37:17 foo kernel: bnxt0: Unable to allocate device TX queue May 19 10:37:17 foo kernel: bnxt0: Unable to allocate queue memory May 19 10:37:17 foo kernel: device_attach: bnxt0 attach returned 22 May 19 10:37:17 foo kernel: bnxt0: mem 0xb8a0-0xb8a0,0xb880-0xb88f,0xb8a2-0xb8a21fff at device 0.1 numa-domain 0 on pci9 May 19 10:37:17 foo kernel: bnxt0: Using 256 TX descriptors and 256 RX descriptors May 19 10:37:17 foo kernel: bnxt0: Using 0 RX queues 0 TX queues May 19 10:37:17 foo kernel: bnxt0: Using MSI-X interrupts with 1 vectors May 19 10:37:17 foo kernel: bnxt0: iflib_dma_alloc_align: bus_dma_tag_create failed: 22 May 19 10:37:17 foo kernel: bnxt0: Unable to allocate device TX queue May 19 10:37:17 foo kernel: bnxt0: Unable to allocate queue memory May 19 10:37:17 foo kernel: device_attach: bnxt0 attach returned 22 % pciconf -l -BbcevV ... vendor = 'Broadcom Inc. and subsidiaries' device = 'BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet Controller' class = network subclass = ethernet bar [10] = type Prefetchable Memory, range 64, base 0xb8a1, size 65536, enabled bar [18] = type Prefetchable Memory, range 64, base 0xb890, size 1048576, enabled bar [20] = type Prefetchable Memory, range 64, base 0xb8a22000, size 8192, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit cap 11[a0] = MSI-X supports 74 messages Table in map 0x20[0x0], PBA in map 0x20[0x4a0] cap 10[ac] = PCI-Express 2 endpoint max data 256(512) FLR RO NS max read 512 link x8(x8) speed 8.0(8.0) ClockPM disabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[13c] = Serial 1 f4ee08fffe25fabd ecap 0004[150] = Power Budgeting 1 ecap 0002[160] = VC 1 max VC0 ecap 000b[180] = Vendor [1] ID Rev 0 Length 32 ecap 0018[1b0] = LTR 1 ecap 000e[1b8] = ARI 1 ecap 0017[230] = TPH Requester 1 ecap 0019[300] = PCIe Sec 1 lane errors 0 ecap 001f[200] = Precision Time Measurement 1 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error VPD ident = 'Broadcom Adv. Dual 10GBASE-T Ethernet' VPD ro PN = 'BCM957416' VPD ro MN = '1028' VPD ro V0 = 'FFV22.00.07.60' VPD ro V1 = 'DSV1028VPDR.VER2.1' VPD ro V2 = 'NPY2' VPD ro V3 = 'PMT1' VPD ro V4 = 'NMVBroadcom Corp' VPD ro V5 = 'DTINIC' VPD ro V6 = 'DCM1001FF1202FF1403FF1604FF1805FF1A06FF1C07FF1E08FF2101FF2302FF2503FF2704FF2905FF2B06FF2D07FF2F08FF' VPD ro V7 = 'L1D0' none89@pci0:94:0:1: class=0x02 rev=0x01 hdr=0x00 vendor=0x14e4 device=0x16d8 subvendor=0x1028 subdevice=0x1fea vendor = 'Broadcom Inc. and subsidiaries' device = 'BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet Controller' class = network subclass = ethernet bar [10] = type Prefetchable Memory, range 64, base 0xb8a0, size 65536, enabled bar [18] = type Prefetchable Memory, range 64, base 0xb880, size 1048576, enabled bar [20] = type Prefetchable Memory, range 64, base 0xb8a2, size 8192, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit cap 11[a0] = MSI-X supports 74 messages Table in map 0x20[0x0], PBA in map 0x20[0x4a0] cap 10[ac] = PCI-Express 2 endpoint max data 256(512) FLR RO NS max read 512 link x8(x8) speed 8.0(8.0) ClockPM disabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[13c] = Serial 1 f4ee08fffe25fabd ecap 0004[150] = Power Budgeting 1 ecap 000b[180] = Vendor [1] ID
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #25 from Kurt Jaeger --- (In reply to SJ from comment #24) Can you update to 13.1, as it contains some fixes for bnxt ? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #26 from SJ --- (In reply to Kurt Jaeger from comment #25) Done! % uname -a FreeBSD foo 13.1-RELEASE FreeBSD 13.1-RELEASE % kldstat Id Refs AddressSize Name 1 27 0x8020 1f30590 kernel 21 0x82131000 5ec1d8 zfs.ko 31 0x8271e000 af68 cryptodev.ko 41 0x82c11000 3378 acpi_wmi.ko 51 0x82c15000 3250 ichsmb.ko 61 0x82c19000 2180 smbus.ko 71 0x82c1c000 2110 pchtherm.ko 81 0x82c1f000 2a08 mac_ntpd.ko % kldload /boot/kernel/if_bnxt.ko May 19 12:05:21 chlorine kernel: bnxt0: mem 0xb8a1-0xb8a1,0xb890-0xb89f,0xb8a22000-0xb8a23fff at device 0.0 numa-domain 0 on pci9 May 19 12:05:21 chlorine kernel: bnxt0: Using 256 TX descriptors and 256 RX descriptors May 19 12:05:21 chlorine kernel: bnxt0: Using 0 RX queues 0 TX queues May 19 12:05:21 chlorine kernel: bnxt0: Using MSI-X interrupts with 1 vectors May 19 12:05:21 chlorine kernel: bnxt0: iflib_dma_alloc_align: bus_dma_tag_create failed: 22 May 19 12:05:21 chlorine kernel: bnxt0: Unable to allocate device TX queue May 19 12:05:21 chlorine kernel: bnxt0: Unable to allocate queue memory May 19 12:05:21 chlorine kernel: device_attach: bnxt0 attach returned 22 May 19 12:05:21 chlorine kernel: Warning: failed attempt to remove oid fc with child autoneg May 19 12:05:21 chlorine kernel: pci0:94:0:0: Device leaked memory resources May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%desc)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%driver)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%location)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%pnpinfo)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%parent)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.%domain)! May 19 12:05:21 chlorine kernel: bnxt0: mem 0xb8a0-0xb8a0,0xb880-0xb88f,0xb8a2-0xb8a21fff at device 0.1 numa-domain 0 on pci9 May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.driver_version)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_ntxqs)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_nrxqs)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_qs_enable)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.disable_msix)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.rx_budget)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.tx_abdicate)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.core_offset)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.separate_txrx)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.use_logical_cores)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_ntxds)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.iflib.override_nrxds)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.mfg_id)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.device_id)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.sector_size)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.size)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.reserved_size)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.nvram.available_size)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.rss_key)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.rss_type)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.rx_stall)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.vlan_strip)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.if_name)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_usecs)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_frames)! May 19 12:05:21 chlorine kernel: sysctl_warn_reuse: can't re-use a leaf (dev.bnxt.0.intr_coal_rx_usecs_irq)! May 19 12:05:21 chlorine kernel: sys
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #27 from Kurt Jaeger --- (In reply to SJ from comment #26) If the interfaces can be made to appear, are they usable ? Is the performance appropriate ? Or do they show, but fail to work ? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #28 from SJ --- (In reply to Kurt Jaeger from comment #27) After some testing, I can confirm that they show, but fail to work. When configuring one of the interfaces to use DHCP, it doesn't obtain anything, showing the IP 0.0.0.0. bnxt0: flags=8863 metric 0 mtu 1500 options=4e527bb ether foo inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 media: Ethernet autoselect (10Gbase-T ) status: active nd6 options=29 No luck with a static configuration either. I've tried rebooting and reloading if_bnxt.ko after changes to see if there's any difference. % ping -I bnxt0 ... ping: invalid multicast interface: `bnxt0' Thanks! -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #29 from Kurt Jaeger --- I tested 13.1-RC1 with the BCM57414. I have no BCM57416 to test 8-( -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #30 from SJ --- (In reply to Kurt Jaeger from comment #29) As per #20, it seems like firmware version 21.65.33.33 may work. Whether or not it'll let me upgrade is a different thing altogether! It'll be tomorrow or Monday before I'll be able to test this out, but will report back. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 263986] IPv6 address gets detached when using multiple IPv6 routers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263986 Tatsuki Makino changed: What|Removed |Added CC||tatsuki_mak...@hotmail.com --- Comment #1 from Tatsuki Makino --- memorandum: RFC 4861 6.3.4. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263379] [regression] [ipsec] compatibility broken between stable/12 and stable/13 opencrypto in AEAD mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379 --- Comment #16 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6835ace580917ec512eb96cf9c456f4acc161247 commit 6835ace580917ec512eb96cf9c456f4acc161247 Author: John Baldwin AuthorDate: 2022-04-27 19:18:52 + Commit: John Baldwin CommitDate: 2022-05-20 00:35:34 + setkey(8): Clarify language around AEAD ciphers. AEAD ciphers for IPsec combine both encryption and authentication. As such, ESP configurations using an AEAD cipher should not use a seperate authentication algorithm via -A. However, this was not apparent from the setkey manpage and 12.x and earlier did not perform sufficient argument validation permitting users to pair an explicit -A such as SHA256-HMAC with AES-GCM. (The result was a non-standard combination of AES-CTR with the specified MAC, but with the wrong initial block counter (and thus different keystream) compared to using AES-CTR as the cipher.) Attempt to clarify this in the manpage by explicitly calling out AEAD ciphers (currently only AES-GCM) and noting that AEAD ciphers should not use -A. While here, explicitly note which authentication algorithms can be used with esp vs esp-old. Also add subsection headings for the different algorithm lists and tidy some language. I did not convert the tables to column lists (Bl -column) though that would probably be more correct than using literal blocks (Bd -literal). PR: 263379 Reviewed by:Pau Amma , markj Differential Revision: https://reviews.freebsd.org/D34947 (cherry picked from commit e6dede145616ed8f98c629c23a2ba206b812c921) sbin/setkey/setkey.8 | 58 +--- 1 file changed, 32 insertions(+), 26 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 263379] [regression] [ipsec] compatibility broken between stable/12 and stable/13 opencrypto in AEAD mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379 --- Comment #17 from commit-h...@freebsd.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6aaf8a8b1bcf500aa7342043d43007ff9c52cd65 commit 6aaf8a8b1bcf500aa7342043d43007ff9c52cd65 Author: John Baldwin AuthorDate: 2022-04-27 19:18:52 + Commit: John Baldwin CommitDate: 2022-05-20 00:42:24 + setkey(8): Clarify language around AEAD ciphers. AEAD ciphers for IPsec combine both encryption and authentication. As such, ESP configurations using an AEAD cipher should not use a seperate authentication algorithm via -A. However, this was not apparent from the setkey manpage and 12.x and earlier did not perform sufficient argument validation permitting users to pair an explicit -A such as SHA256-HMAC with AES-GCM. (The result was a non-standard combination of AES-CTR with the specified MAC, but with the wrong initial block counter (and thus different keystream) compared to using AES-CTR as the cipher.) Attempt to clarify this in the manpage by explicitly calling out AEAD ciphers (currently only AES-GCM) and noting that AEAD ciphers should not use -A. While here, explicitly note which authentication algorithms can be used with esp vs esp-old. Also add subsection headings for the different algorithm lists and tidy some language. I did not convert the tables to column lists (Bl -column) though that would probably be more correct than using literal blocks (Bd -literal). PR: 263379 Reviewed by:Pau Amma , markj Differential Revision: https://reviews.freebsd.org/D34947 (cherry picked from commit e6dede145616ed8f98c629c23a2ba206b812c921) sbin/setkey/setkey.8 | 74 1 file changed, 40 insertions(+), 34 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 193953] vlan(4) on LACP lagg(4) do not update if_baudrate value and thus SNMP daemons do not provide high capacity counters
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193953 --- Comment #15 from Marek Zarychta --- Committed to main https://cgit.freebsd.org/src/commit/?id=f2ab9160 Thanks, we are looking forward to MFC. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 193953] vlan(4) on LACP lagg(4) do not update if_baudrate value and thus SNMP daemons do not provide high capacity counters
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193953 Marek Zarychta changed: What|Removed |Added CC||w...@freebsd.org Flags||mfc-stable13?, ||mfc-stable12? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 263831] netinet6 in6_proto.c missing IPPROTO_ETHERIP entry at FreeBSD 13.1-RC5
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263831 Hiroki Sato changed: What|Removed |Added Status|New |In Progress Assignee|n...@freebsd.org |h...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264094] seting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Marek Zarychta changed: What|Removed |Added CC||n...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Marek Zarychta changed: What|Removed |Added Summary|seting |setting |net.inet.tcp.cc.algorithm |net.inet.tcp.cc.algorithm |to htcp triggers panic on |to htcp triggers panic on |the most recent CURRENT |the most recent CURRENT -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Michael Tuexen changed: What|Removed |Added CC||tue...@freebsd.org Status|New |In Progress Assignee|b...@freebsd.org|tue...@freebsd.org --- Comment #1 from Michael Tuexen --- I can reproduce the issue, will look into it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] [tcp] setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Michael Tuexen changed: What|Removed |Added Summary|setting |[tcp] setting |net.inet.tcp.cc.algorithm |net.inet.tcp.cc.algorithm |to htcp triggers panic on |to htcp triggers panic on |the most recent CURRENT |the most recent CURRENT -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 263756] igb interface not receiving vlan packets since 12.3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263756 Natalino Picone changed: What|Removed |Added CC||natalino.picone@nozominetwo ||rks.com --- Comment #3 from Natalino Picone --- (In reply to sec from comment #2) I had the same issue and I agree that 260468 should be merged on 12.3. Does anybody know why hwfiltering has been enabled by default? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264006] dwc: dwc interface is not able to send packets when changing the dwc interface's media from the auto-negotiation mode to the forced mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264006 --- Comment #1 from Jiahao LI --- Created attachment 234058 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=234058&action=edit Fix patch following other drivers code sequence Updating the previous patch. Following other drivers' implementation, smsc, axe, axge and re, to change the link-up state in dwc_softc struct. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Kubilay Kocak changed: What|Removed |Added Keywords||crash, needs-qa Severity|Affects Only Me |Affects Many People Summary|[tcp] setting |cc_htcp(4): Setting |net.inet.tcp.cc.algorithm |net.inet.tcp.cc.algorithm |to htcp triggers panic on |to htcp triggers panic on |the most recent CURRENT |the most recent CURRENT Flags||mfc-stable13?, ||mfc-stable12? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 224961] VLAN ID 0 Not Supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224961 demus...@gmail.com changed: What|Removed |Added CC||demus...@gmail.com --- Comment #6 from demus...@gmail.com --- More and more ISP's are using a tagged vlan0 on their interfaces now. I agree that it's time to incorporate this. It's starting to effect too many people and adding a managed switch between handoff and WAN is not a real solution. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 224961] VLAN ID 0 Not Supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224961 Hans Petter Selasky changed: What|Removed |Added CC||hsela...@freebsd.org --- Comment #7 from Hans Petter Selasky --- Look for "pcp" in "man ifconfig" --HPS -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 Kubilay Kocak changed: What|Removed |Added CC||n...@freebsd.org Assignee|b...@freebsd.org|de...@freebsd.org --- Comment #2 from Kubilay Kocak --- ^Triage: Assign to maintainer for coordination -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 --- Comment #3 from Nick Briggs --- It would be a much better UX if the wireguard kmod if_wg.ko were tagged such that the kernel module loader noticed that it was not compatible with the new kernel. The virtualbox module seems to be coded so that the module loader detects that situation, reports an error, and refuses to load. I much prefer that over having to deal with a system that panics each time someone tries establish a tunnel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 --- Comment #4 from Bernhard Froehlich --- Okay I keep this PR open to mark all future PRs as duplicates. The reason for the panic is that all packages are build on 13.0 which works fine for userland packages because they are compatible with 13.1. For kernel modules there is no such compatibility guarantee so you have to build kernel modules for exactly that kernel or you get panics like these. This has been the situation for ages. Nothing new. Virtual box has had such bug reports for years until all users were aware (removing module before reboot etc.). With vbox it was even more critical because we traditionally loaded it very early via loader which could result in a bootloop of panics. In a DevSummit in 2012 we talked about that problem in a session. Finally about two weeks ago jhb@ did send patches for virtualbox-kmod to address this. https://cgit.freebsd.org/ports/commit/?id=bc6d5725ed6c7b6538da70328d89afe901736a90 It will not take another 10 years to fix it for wireguard. For the moment if anyone experiences panics after an update (or fresh install from 13.1) please don't use the binary package but install from ports using "make install" to make sure it matches your kernel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 lb...@disroot.org changed: What|Removed |Added CC||lb...@disroot.org --- Comment #5 from lb...@disroot.org --- (In reply to Bernhard Froehlich from comment #4) Thanks. But it may takes a lot of time and space when doing port compiling on embedded system. It would be great if someone manages to resolve related package system drawbacks. Or someone adds some description in the Freebsd Handbook. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 Marek Zarychta changed: What|Removed |Added CC||zarych...@plan-b.pwste.edu. ||pl --- Comment #6 from Marek Zarychta --- Maybe it's high time to change the default policy of the Project? Instead of building all packages on approaching EoL minor version (13.0) in this case, the packages might be built on the upcoming minor version with some advance, let's say entering the RC phase could be the turning point. Such an approach definitely would improve the user experience. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 --- Comment #7 from Bernhard Froehlich --- (In reply to Marek Zarychta from comment #6) No that does not work. Compatibility only works in one direction. Packages are build with the oldest supported version on that branch which is correct. A possibility would be to have a small additional repository for all kmod ports and build that per release. I will drag this to portmgr@ to make them aware of the problem. I will let you all know if there are any news. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #2 from Michael Tuexen --- The panic happens on arm64, but not amd64. It does happen when using clang14 (most recent version in the main tree), it does not happen when using clang13. I also does not happen using clang14 when forcing htcp_recalc_beta() not to be inlined. The panic happens when accessing V_htcp_adaptive_backoff in https://cgit.freebsd.org/src/tree/sys/netinet/cc/cc_htcp.c#n471 I disassembled htcp_recalc_beta() when using clang14 and the function not being inlined. This is the relevant code: (kgdb) disassemble htcp_recalc_beta Dump of assembler code for function htcp_recalc_beta: 0x000113cc <+0>: stp x29, x30, [sp, #-16]! 0x000113d0 <+4>: mov x29, sp 0x000113d4 <+8>: ldr x8, [x0] ; x8 = ccv 0x000113d8 <+12>: ldr x9, [x18] ; x9 = curthread 0x000113dc <+16>: adrpx10, 0x21000 ; x10 = ??? 0x000113e0 <+20>: ldr x9, [x9, #1368] ; x9 = curthread->td_vnet 0x000113e4 <+24>: ldr x10, [x10, #2168] ; x10 = ??? 0x000113e8 <+28>: ldr x9, [x9, #40] ; x9 = curthread->td_vnet->vnet_data_base 0x000113ec <+32>: ldr w9, [x9, x10] ; w9 = V_htcp_adaptive_backoff ??? 0x000113f0 <+36>: cbz w9, 0x11428 I don't understand the computations in relation to x10, which is the offset used to get the relevant variable. However, this code works. Looking at the code generated by clang13 when htcp_recalc_beta() is inlined, one gets: 0x000150610f28 <+212>:ldr x10, [x0]; x10 = ccv 0x000150610f2c <+216>:ldr x11, [x18] ; x11 = curthread 0x000150610f30 <+220>:ldr x11, [x11, #1368]; x11 = curthread->td_vnet 0x000150610f34 <+224>:ldr x12, [x11, #40] ; x12 = curthread->td_vnet->vnet_data_base 0x000150610f38 <+228>:adrpx11, 0x000150621000 ; ??? 0x000150610f3c <+232>:ldr x11, [x11, #2256]; ??? 0x000150610f40 <+236>:ldr w12, [x12, x11] 0x000150610f44 <+240>:cbz w12, 0x000150610f7c It looks similar and it does work. Now comes the inlined code from clang14: 0x0001016acf28 <+212>:ldr x10, [x0] ; x10 = ccv 0x0001016acf2c <+216>:ldr x11, [x18]; x11 = curthread 0x0001016acf30 <+220>:ldr x12, [x11, #1368] ; x12 = curthread->td_vnet 0x0001016acf34 <+224>:nop 0x0001016acf38 <+228>:adr x11, 0x0001016bd520 0x0001016acf3c <+232>:ldr x12, [x12, #40] ; x12 = curthread->td_vnet->vnet_data_base ==>0x0001016acf40 <+236>: ldr w12, [x12, x11] 0x0001016acf44 <+240>:cbz w12, 0x0001016acf7c I reached out at arm-free...@freebsd.org for some help regarding the generated code. -- You are receiving this mail because: You are on the CC list for the bug.
Problem reports for n...@freebsd.org that need special attention
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 +---+--- In Progress |221146 | [ixgbe] Problem with second laggport New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New |213410 | [carp] service netif restart causes hang only whe Open| 7556 | ppp: sl_compress_init() will fail if called anyth Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open|202510 | [CARP] advertisements sourced from CARP IP cause Open|207261 | netmap: Doesn't do TX sync with kqueue Open|73 | igb(4): Kernel panic (fatal trap 12) due to netwo Open|225438 | panic in6_unlink_ifa() due to race Open|227720 | Kernel panic in ppp server Open|230807 | if_alc(4): Driver not working for Killer Networki Open|236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open|237072 | netgraph(4): performance issue [on HardenedBSD]? Open|237840 | Removed dummynet dependency on ipfw Open|237973 | pf: implement egress keyword to simplify rules ac Open|238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open|238707 | Lock order reversal: rtentry vs "nd6 list" Open|240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open|241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open|241162 | Panic in closefp() triggered by nginx (uwsgi with Open|241191 | route flush panic with RADIX_MPATH Open|243463 | ix0: Watchdog timeout Open|247111 | pxeboot very slow with i219LM Open|257709 | netinet6: Set net.inet6.icmp6.nodeinfo default to Open|118111 | rc: network.subr Add MAC address based interface 25 problems total for which you should take action.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #3 from Marek Zarychta --- Thank you for digging into this. It looks like a clang14 flaw. Please see: bug 264021 and probably also bug 264115. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Jessica Clarke changed: What|Removed |Added CC||jrt...@freebsd.org --- Comment #4 from Jessica Clarke --- This looks like it's caused by https://github.com/llvm/llvm-project/commit/8acc3b4ab0c76b9c2a54182e31a02f90ebb96329 given the loss of a LDR of the ADRP and the insertion of a NOP (ignoring the instruction rescheduling that changes register allocation slightly). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #5 from Jessica Clarke --- Well, that composed with https://github.com/llvm/llvm-project/commit/4450a2a23df0e7081ca7fee3ec641774afedc2bc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #6 from Jessica Clarke --- To confirm, you are using cc_htcp.ko rather than compiling it into your kernel? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #7 from Marek Zarychta --- (In reply to Jessica Clarke from comment #6) >To confirm, you are using cc_htcp.ko rather than compiling it into your kernel? Of course. Good idea. I didn't know it is even possible to build the kernel with cc_htpc support. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #8 from Jessica Clarke --- (In reply to Marek Zarychta from comment #7) In the kernel should work as it's prepared for those kinds of optimisations, but kernel modules should not, as they rely on the indirection persisting and being rewritten on load. Marking the special vnet and dpcpu symbols as weak might be sufficient to stop the relaxations, but I wouldn't like to say for sure, kernel modules get build with weird symbol interposition semantics that have always been asking for trouble. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 John F. Carr changed: What|Removed |Added CC||j...@mit.edu --- Comment #9 from John F. Carr --- The problem is introduced in the process of turning the .o into a .ko. Pinpointing the bug requires study of the exact definition of the ARM relocation types, in assembly and in ELF. If you change -c to -S in the command for building cc_htcp.o you get two consecutive lines of assembly adrpx11, :got:vnet_entry_htcp_adaptive_backoff ldr x11, [x11, :got_lo12:vnet_entry_htcp_adaptive_backoff] In cc_htcp.o these become (objdump --disassemble --reloc) 200: 900badrpx11, 0 200: R_AARCH64_ADR_GOT_PAGE vnet_entry_htcp_adaptive_backoff 204: f940016bldr x11, [x11] 204: R_AARCH64_LD64_GOT_LO12_NC vnet_entry_htcp_adaptive_backoff In cc_htcp.ko these are incorrectly optimized after the linker determines the variable is close to the instruction: 10f50: d503201fnop 10f54: 10082f6badr x11, 21540 This computes the address of the value instead of loading the value. The optimization would be correct if there were an adrp+adr pair but it is not correct for adrp+ld. So is :got_lo12: the wrong prefix, is R_AARCH64_LD64_GOT_LO12_NC the wrong binary relocation code, or did the linker forget to check the opcode of the instruction it rewrote? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 Kyle Evans changed: What|Removed |Added CC||kev...@freebsd.org --- Comment #8 from Kyle Evans --- I wish we had known this was an issue back in neta/rc... we put time into diagnosing an issue with binary compatible with the drm ports this cycle, we would have done the same for wireguard. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #10 from Jessica Clarke --- (In reply to John F. Carr from comment #9) The optimisation is correct for non-preemptible symbols. It's not correct for preemptible symbols (or hacks like vnet/dpcpu that rely on symbol and relocation abuse). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #11 from Michael Tuexen --- (In reply to Jessica Clarke from comment #6) I just tested that the problem does not show up if you build the CC module in the kernel using the CC_HTCP kernel option. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Michael Tuexen changed: What|Removed |Added Assignee|tue...@freebsd.org |b...@freebsd.org Status|In Progress |Open --- Comment #12 from Michael Tuexen --- Resigning as assignee since it is a clang issue, not a networking issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264059] mlx4en(4) Mellanox ConnectX-3 10g eth not working in 13.1: mlx4_core0: Unable to determine PCI device chain minimum BW
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 --- Comment #9 from Hans Petter Selasky --- Ping --HPS -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264059] mlx4en(4) Mellanox ConnectX-3 10g eth not working in 13.1: mlx4_core0: Unable to determine PCI device chain minimum BW
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 --- Comment #10 from crb --- Sorry, I thought I left a message and closed this. I was, indeed, missing the module you suggested. When I loaded that the machine started working. Thank you! -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264059] mlx4en(4) Mellanox ConnectX-3 10g eth not working in 13.1: mlx4_core0: Unable to determine PCI device chain minimum BW
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264059 Hans Petter Selasky changed: What|Removed |Added Resolution|--- |FIXED Status|Open|Closed --- Comment #11 from Hans Petter Selasky --- Thank you! Then I'll close this issue. --HPS -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 263824] genet(4): Driver interface may overwrite memory in a consecutive memory copy operations when parsing TX packet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263824 --- Comment #7 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7e6e22aab6b993e42328bafe0f64ee14a2b7c43c commit 7e6e22aab6b993e42328bafe0f64ee14a2b7c43c Author: Mike Karels AuthorDate: 2022-05-09 12:19:52 + Commit: Mike Karels CommitDate: 2022-05-23 11:53:01 + genet: fix output packet corruption in uncommon case The code for the "shift" block in the COPY macro set the pointer for the next copy block to the wrong value. In this case, the link-layer header would be overwritten by the network-layer header. This case is difficult or impossible to exercise in the current driver without changing the value of the hw.genet.tx_hdr_min sysctl. Correct the pointer. While here, remove a line in the macro that was marked "unneeded", which was actually wrong. PR: 263824 Submitted by: jiah...@blackberry.com (cherry picked from commit 1de9aa4d4f7938f36e6485dad817908a6e45bb32) sys/arm64/broadcom/genet/if_genet.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 263824] genet(4): Driver interface may overwrite memory in a consecutive memory copy operations when parsing TX packet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263824 Mike Karels changed: What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED --- Comment #8 from Mike Karels --- Fixed on main and stable/13 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 245981] bnxt(4): BCM57414 / BCM57416 not initializing: bnxt0: Unable to allocate device TX queue / queue memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245981 --- Comment #31 from SJ --- I couldn't find a version matching 21.65.33.33, but downgraded the NIC firmware to 21.60.22.11 and everything worked fine after loading the kernel module. Tried upgrading to 22.00.07.60 again after that and can confirm that now works as well. Bit of an odd one, but happy to report no further issues. Cheers! -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #13 from Michael Tuexen --- Just another data point: Disabling VNET also works around the problem. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #14 from Jessica Clarke --- Yes, it's a problem with how VNET (and DPCPU) are designed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264193] pf: scrub max-mss rule stops working (but still counts) after 13.1-RELEASE upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264193 Kubilay Kocak changed: What|Removed |Added Status|New |Open Flags||mfc-stable13?, ||mfc-stable12- Summary|Broken scrub max-mss|pf: scrub max-mss rule ||stops working (but still ||counts) after 13.1-RELEASE ||upgrade Blocks||264030 CC||n...@freebsd.org Assignee|b...@freebsd.org|p...@freebsd.org Keywords||needs-qa, regression Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264030 [Bug 264030] [tracking] 13.1-RELEASE issue reports -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264191] mbuf: debugnet panics with mbuf cache with multiple instances of the same driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264191 Kubilay Kocak changed: What|Removed |Added CC||hsela...@freebsd.org, ||n...@freebsd.org See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2589 ||23 Summary|debugnet panics with mbuf |mbuf: debugnet panics with |cache with multiple |mbuf cache with multiple |instances of the same |instances of the same |driver |driver Flags||maintainer-feedback?(cem@fr ||eebsd.org), ||maintainer-feedback?(markj@ ||FreeBSD.org), ||maintainer-feedback?(hselas ||k...@freebsd.org) Keywords||crash, needs-qa Assignee|b...@freebsd.org|n...@freebsd.org Status|New |Open Severity|Affects Only Me |Affects Some People --- Comment #1 from Kubilay Kocak --- ^Triage: Unsure of specific relevance, but see also src 5a7de2b42caf via 258923 given mlx mention here and mlx, panic, debugnet_mbuf_reinit() and debugnet activation there. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 258923] [mlx4en] Wrong mbuf cluster size in mlx4_en_debugnet_init leads to panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258923 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2641 ||91 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264191] mbuf: debugnet panics with mbuf cache with multiple instances of the same driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264191 --- Comment #2 from Kubilay Kocak --- See also base 5a7de2b42caf via bug 258923 apologies. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264179] Boot hangs up with Alderlake's intel GbE NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179 Mark Linimon changed: What|Removed |Added Keywords||IntelNetworking, regression Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264179] 13.1-RELEASE hands in boot with Intel Alderlake GbE NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179 Kubilay Kocak changed: What|Removed |Added Blocks||264030 Status|New |Open Summary|Boot hangs up with |13.1-RELEASE hands in boot |Alderlake's intel GbE NIC |with Intel Alderlake GbE ||NIC CC||n...@freebsd.org Keywords||needs-qa --- Comment #1 from Kubilay Kocak --- - Can you confirm boot behaviour is OK on 12.1-RELEASE ? - Is the system able to boot single user? (to obtain and attach pciconf -lv and usbconfig list output) - Does boot verbose show anything additional? - How does behaviour change without any USB devices connected? - How does behaviour change after disabling USB controllers in BIOS/UEFI? - How does behaviour change after disabling: - just onboard network controller - just pci network controller - both network controllers Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264030 [Bug 264030] [tracking] 13.1-RELEASE issue reports -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Kubilay Kocak changed: What|Removed |Added Severity|Affects Many People |Affects Some People CC||toolch...@freebsd.org Assignee|b...@freebsd.org|toolch...@freebsd.org Flags||maintainer-feedback?(toolch ||a...@freebsd.org) --- Comment #15 from Kubilay Kocak --- (In reply to Michael Tuexen from comment #12) Any details on that isolation that could help toolchain@ with root causing and resolution Michael? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264191] mbuf: debugnet panics with mbuf cache with multiple instances of the same driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264191 --- Comment #3 from Bryan Drewery --- (In reply to Kubilay Kocak from comment #2) None of this is a recent regression. It is design flaws. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 --- Comment #16 from Michael Tuexen --- (In reply to Kubilay Kocak from comment #15) I think I gave all information I can provide. I'm not familiar with the internals for clang... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264094] cc_htcp(4): Setting net.inet.tcp.cc.algorithm to htcp triggers panic on the most recent CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264094 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2640 ||21, ||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2641 ||15 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 264179] 13.1-RELEASE hands in boot with Intel Alderlake GbE NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179 --- Comment #2 from Yasuhiro Kimura --- (In reply to Kubilay Kocak from comment #1) > - Can you confirm boot behaviour is OK on 12.1-RELEASE ? Do you mean 12.3-RELEASE? If so, same hangup happens with it. > - Is the system able to boot single user? (to obtain and attach pciconf -lv > and usbconfig list output) No. Hangup happens before reaching single user shell. But on 13.0-RELEASE `pciconf -lv` gets following result. yasu@maybe[1002]% pciconf -lv ~ hostb0@pci0:0:0:0: class=0x06 rev=0x05 hdr=0x00 vendor=0x8086 device=0x4630 subvendor=0x1458 subdevice=0x5000 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 rev=0x05 hdr=0x01 vendor=0x8086 device=0x460d subvendor=0x1458 subdevice=0x5000 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 device=0x4692 subvendor=0x1458 subdevice=0xd000 vendor = 'Intel Corporation' class = display subclass = VGA none0@pci0:0:10:0: class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x467d subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = dasp xhci0@pci0:0:20:0: class=0x0c0330 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ae0 subvendor=0x1458 subdevice=0x5007 vendor = 'Intel Corporation' class = serial bus subclass = USB none1@pci0:0:20:2: class=0x05 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7aa7 subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = memory subclass = RAM none2@pci0:0:21:0: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7acc subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none3@pci0:0:21:1: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7acd subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none4@pci0:0:21:2: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ace subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none5@pci0:0:21:3: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7acf subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none6@pci0:0:22:0: class=0x078000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ae8 subvendor=0x1458 subdevice=0x1c3a vendor = 'Intel Corporation' class = simple comms ahci0@pci0:0:23:0: class=0x010601 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ae2 subvendor=0x1458 subdevice=0xb005 vendor = 'Intel Corporation' class = mass storage subclass = SATA none7@pci0:0:25:0: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7afc subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none8@pci0:0:25:1: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7afd subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus pcib2@pci0:0:28:0: class=0x060400 rev=0x11 hdr=0x01 vendor=0x8086 device=0x7ab8 subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:4: class=0x060400 rev=0x11 hdr=0x01 vendor=0x8086 device=0x7abc subvendor=0x1458 subdevice=0x5001 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7a87 subvendor=0x1458 subdevice=0x5001 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA hdac0@pci0:0:31:3: class=0x040300 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ad0 subvendor=0x1458 subdevice=0xa194 vendor = 'Intel Corporation' class = multimedia subclass = HDA none9@pci0:0:31:4: class=0x0c0500 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7aa3 subvendor=0x1458 subdevice=0x5001 vendor = 'Intel Corporation' class = serial bus subclass = SMBus none10@pci0:0:31:5: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7aa4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none11@pci0:0:31:6: class=0x02 rev=0x11 hdr=0x00 vendor=0x8086 device=0x1a1d subvendor=0x1458 subdevice=0xe000 vendor = 'Intel Corporation' device = 'Ethernet Connection (17) I219-V' class = network subclass = ethernet em0@pci0:1:0:0: class=0x02 rev=0x00 hdr=0x00 vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network
[Bug 264179] 13.1-RELEASE hands in boot with Intel Alderlake GbE NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179 --- Comment #3 from Yasuhiro Kimura --- According to the suggestion in freebsd-stable ML, I added 'hint.em.1.disabled=1' to /boot/loader.conf and then 13.1-RELEASE boots successfully. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 263756] igb interface not receiving vlan packets since 12.3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263756 Ryan Steinmetz changed: What|Removed |Added CC||z...@freebsd.org --- Comment #4 from Ryan Steinmetz --- I ran into this as well. This resolved my issue: ifconfig igb0 -vlanhwfilter -vlanhwtag -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263756] igb interface not receiving vlan packets since 12.3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263756 --- Comment #5 from Natalino Picone --- (In reply to Ryan Steinmetz from comment #4) This is not working as the 12.3 intel driver contains a bug. ifconfig reports that features have been disabled, but they are not. See https://reviews.freebsd.org/D33154 which I think should also be merged on 12.3 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 263756] igb interface not receiving vlan packets since 12.3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263756 --- Comment #6 from Ryan Steinmetz --- (In reply to Natalino Picone from comment #5) My use case is closer to what s...@42.org described--where I have vlan interfaces created. I don't think my situation is identical to what you reported, but, seems related. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264248] ib_cm: Fix a resource leak in ib_cm_insert_listen()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264248 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 264248] ib_cm: Fix a resource leak in ib_cm_insert_listen()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264248 --- Comment #1 from Hans Petter Selasky --- Have you checked if a fix exist in Linux? -- You are receiving this mail because: You are the assignee for the bug.
maintainer-feedback requested: [Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
Kubilay Kocak has asked freebsd-net (Nobody) for maintainer-feedback: Bug 264257: Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 Kubilay Kocak changed: What|Removed |Added CC||hsela...@freebsd.org, ||j...@freebsd.org, ||ma...@freebsd.org, ||n...@freebsd.org Summary|[panic] Fatal trap 12: page |Panic: Fatal trap 12: page |fault while in kernel mode |fault while in kernel mode |(if_io_tqg_4) |(if_io_tqg_4) - m_copydata ||... at ||/usr/src/sys/kern/uipc_mbuf ||.c:659 Blocks||264030 Assignee|b...@freebsd.org|n...@freebsd.org Keywords||crash, needs-qa Flags||maintainer-feedback?(net@Fr ||eeBSD.org), ||maintainer-feedback?(hselas ||k...@freebsd.org), ||maintainer-feedback?(markj@ ||FreeBSD.org), ||maintainer-feedback?(jhb@Fr ||eeBSD.org), mfc-stable13? Status|New |Open Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264030 [Bug 264030] [tracking] 13.1-RELEASE issue reports -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 Michael Tuexen changed: What|Removed |Added CC||tue...@freebsd.org --- Comment #2 from Michael Tuexen --- Can you provide information how to reproduce it? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #3 from iron.ud...@gmail.com --- (In reply to Michael Tuexen from comment #2) Unfortunately I don't know how to reproduce this bug. The server was working a week or so without any problem. Today it suddenly panicked and restarted. Workload is typical: web-server, postgresql, S3 (minio). -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #4 from iron.ud...@gmail.com --- (In reply to Michael Tuexen from comment #2) Do you need all of my sysctls from /etc/sysctl.conf and /boot/loader.conf? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264179] 13.1-RELEASE hands in boot with Intel Alderlake GbE NIC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264179 --- Comment #4 from Yasuhiro Kimura --- Now boot succeeds with 13.1-RELEASE and `pciconf -lv` gets following result. yasu@maybe[1028]% pciconf -lv hostb0@pci0:0:0:0: class=0x06 rev=0x05 hdr=0x00 vendor=0x8086 device=0x4630 subvendor=0x1458 subdevice=0x5000 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 rev=0x05 hdr=0x01 vendor=0x8086 device=0x460d subvendor=0x1458 subdevice=0x5000 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI vgapci0@pci0:0:2:0: class=0x03 rev=0x0c hdr=0x00 vendor=0x8086 device=0x4692 subvendor=0x1458 subdevice=0xd000 vendor = 'Intel Corporation' class = display subclass = VGA none0@pci0:0:10:0: class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x467d subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = dasp xhci0@pci0:0:20:0: class=0x0c0330 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ae0 subvendor=0x1458 subdevice=0x5007 vendor = 'Intel Corporation' class = serial bus subclass = USB none1@pci0:0:20:2: class=0x05 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7aa7 subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = memory subclass = RAM ig4iic0@pci0:0:21:0:class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7acc subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus ig4iic1@pci0:0:21:1:class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7acd subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus ig4iic2@pci0:0:21:2:class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ace subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus ig4iic3@pci0:0:21:3:class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7acf subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus none2@pci0:0:22:0: class=0x078000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ae8 subvendor=0x1458 subdevice=0x1c3a vendor = 'Intel Corporation' class = simple comms ahci0@pci0:0:23:0: class=0x010601 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ae2 subvendor=0x1458 subdevice=0xb005 vendor = 'Intel Corporation' class = mass storage subclass = SATA ig4iic4@pci0:0:25:0:class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7afc subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus ig4iic5@pci0:0:25:1:class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7afd subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus pcib2@pci0:0:28:0: class=0x060400 rev=0x11 hdr=0x01 vendor=0x8086 device=0x7ab8 subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:4: class=0x060400 rev=0x11 hdr=0x01 vendor=0x8086 device=0x7abc subvendor=0x1458 subdevice=0x5001 vendor = 'Intel Corporation' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7a87 subvendor=0x1458 subdevice=0x5001 vendor = 'Intel Corporation' class = bridge subclass = PCI-ISA hdac0@pci0:0:31:3: class=0x040300 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7ad0 subvendor=0x1458 subdevice=0xa194 vendor = 'Intel Corporation' class = multimedia subclass = HDA ichsmb0@pci0:0:31:4:class=0x0c0500 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7aa3 subvendor=0x1458 subdevice=0x5001 vendor = 'Intel Corporation' class = serial bus subclass = SMBus none3@pci0:0:31:5: class=0x0c8000 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7aa4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' class = serial bus em1@pci0:0:31:6:class=0x02 rev=0x11 hdr=0x00 vendor=0x8086 device=0x1a1d subvendor=0x1458 subdevice=0xe000 vendor = 'Intel Corporation' device = 'Ethernet Connection (17) I219-V' class = network subclass = ethernet em0@pci0:1:0:0: class=0x02 rev=0x00 hdr=0x00 vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f vendor = 'Intel Corporation' device = '82574L Gigabit Network Connection' class = network subclass = ethernet nvme0@pci0:3:0:0: class=0x010802 rev=0x00 hdr=0x00 vendor=0x15b7 device=0x5006 subvendor=0x15b7 subdevice=0x5006 vendor = 'Sandisk Corp' device = 'WD Black SN750 / PC SN730 NVMe SSD' class = mass storage subclass = NVM -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #5 from John Baldwin --- Looks like it walked off the end of the mbuf chain as it tried to copy one byte too many. You could try going up to frame 8 (tcp_output) to see if the arguments passed to m_copydata() are still around (looks like we know the mbuf chain via m@entry for frame 9, but knowing the original length and offset and confirming it walked off the end would be good). You'd have to figure out why the length was wrong though and that might need more digging in the tp or the like. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #6 from iron.ud...@gmail.com --- (In reply to John Baldwin from comment #5) Oh...I'm not sure that I can do it by myself. I'm not so expirianced in debugging. Can I send you compressed core dump file? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #7 from John Baldwin --- Hmm, unfortunately it would need to be the contents of /boot/kernel and /usr/lib/debug/boot/kernel along with the vmcore. However, if you can stick those all in a tarball I can take a look at them. It might be simpler to store them at a URL and mail that to me directly. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #8 from iron.ud...@gmail.com --- (In reply to John Baldwin from comment #7) Emailed you link on archive. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 234073] ixl: SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 --- Comment #18 from benoitc --- is there anything that can be done for it ? Any update needed? It's kind of suprising nobody came with a solution in 3 years on such obvious issue. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 234073] ixl: SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 --- Comment #19 from benoitc --- is there anything that can be done for it ? Any update needed? It's kind of suprising nobody came with a solution in 3 years on such obvious issue. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #9 from Michael Tuexen --- (In reply to iron.udjin from comment #8) You might also send the link to me (tue...@freebsd.org) and Richard (rsch...@freebsd.org), if you are willing to do so. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #10 from iron.ud...@gmail.com --- (In reply to Michael Tuexen from comment #9) Done. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264257] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264257 --- Comment #11 from Michael Tuexen --- (In reply to iron.udjin from comment #10) Thanks! I could download the tarball and will also have a look at it. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 264114] net/wireguard-kmod: Crashes on 13.1-RELEASE: panic: vm_fault_lookup: fault on nofault entry, addr: 0 (wireguard)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264114 --- Comment #9 from Bernhard Froehlich --- So far no response from portmgr@ but I have created a patch similar to what was done in virtualbox-ose-kmod to avoid that the kernel module can be loaded on a kernel with a different minor version. https://reviews.freebsd.org/D35341 -- You are receiving this mail because: You are on the CC list for the bug.
Problem reports for n...@freebsd.org that need special attention
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 +---+--- In Progress |221146 | [ixgbe] Problem with second laggport New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New |213410 | [carp] service netif restart causes hang only whe Open| 7556 | ppp: sl_compress_init() will fail if called anyth Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open|202510 | [CARP] advertisements sourced from CARP IP cause Open|207261 | netmap: Doesn't do TX sync with kqueue Open|73 | igb(4): Kernel panic (fatal trap 12) due to netwo Open|225438 | panic in6_unlink_ifa() due to race Open|227720 | Kernel panic in ppp server Open|230807 | if_alc(4): Driver not working for Killer Networki Open|236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open|237072 | netgraph(4): performance issue [on HardenedBSD]? Open|237840 | Removed dummynet dependency on ipfw Open|237973 | pf: implement egress keyword to simplify rules ac Open|238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open|238707 | Lock order reversal: rtentry vs "nd6 list" Open|240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open|241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open|241162 | Panic in closefp() triggered by nginx (uwsgi with Open|241191 | route flush panic with RADIX_MPATH Open|243463 | ix0: Watchdog timeout Open|247111 | pxeboot very slow with i219LM Open|257709 | netinet6: Set net.inet6.icmp6.nodeinfo default to Open|118111 | rc: network.subr Add MAC address based interface 25 problems total for which you should take action.
[Bug 264191] mbuf: debugnet panics with mbuf cache with multiple instances of the same driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264191 Conrad Meyer changed: What|Removed |Added Flags|maintainer-feedback?(cem@fr | |eebsd.org) | -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 234073] ixl(4): SR-IOV causes "Malicious Driver Detection event" when not all VFs are in passthrough mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234073 Kubilay Kocak changed: What|Removed |Added Status|New |Open CC||free...@intel.com, ||n...@freebsd.org Severity|Affects Some People |Affects Many People Summary|ixl: SR-IOV causes |ixl(4): SR-IOV causes |"Malicious Driver Detection |"Malicious Driver Detection |event" when not all VFs are |event" when not all VFs are |in passthrough mode |in passthrough mode Flags||maintainer-feedback?(krzysz ||tof.gala...@intel.com), ||maintainer-feedback?(freebs ||d...@intel.com), ||mfc-stable13?, ||mfc-stable12? Keywords||needs-qa Priority|--- |Normal -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 211062] ix(4): SR-IOV virtual function driver fails to attach (Intel 10-Gigabit X540-AT2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211062 Kubilay Kocak changed: What|Removed |Added Summary|ix(4): sr-iov virtual |ix(4): SR-IOV virtual |function driver fails to|function driver fails to |attach |attach (Intel 10-Gigabit ||X540-AT2) Priority|--- |Normal Severity|Affects Some People |Affects Many People CC||free...@intel.com Flags|maintainer-feedback?(rstone |maintainer-feedback?(freebs |@FreeBSD.org) |d...@intel.com) See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2298 ||52 Version|CURRENT |12.2-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 211062] ix(4): SR-IOV virtual function driver fails to attach (Intel 10-Gigabit X540-AT2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211062 Kubilay Kocak changed: What|Removed |Added CC||n...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 263568] ix(4): SR-IOV connection lost after loading VM with a passthrough device (Intel X520-DAA2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263568 Kubilay Kocak changed: What|Removed |Added Keywords||IntelNetworking Priority|--- |Normal CC||free...@intel.com, ||n...@freebsd.org Flags||maintainer-feedback?(freebs ||d...@intel.com) Assignee|b...@freebsd.org|n...@freebsd.org Summary|ix(4): sr-iov: connection |ix(4): SR-IOV connection |lost after loading vm with |lost after loading VM with |a passthrough device|a passthrough device (Intel ||X520-DAA2) Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 200836] iovctl(8): Return descriptions in the returned schema reported by iovctl -S
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200836 Kubilay Kocak changed: What|Removed |Added Component|kern|bin CC||n...@freebsd.org Summary|SR-IOV support should |iovctl(8): Return |include config option |descriptions in the |description |returned schema reported by ||iovctl -S Flags||maintainer-feedback?(rstone ||@FreeBSD.org), ||mfc-stable13?, ||mfc-stable12? Assignee|b...@freebsd.org|n...@freebsd.org Keywords||feature --- Comment #6 from Kubilay Kocak --- ^Triage: Update summary to accurately reflect feature request. Request feedback from Ryan re resolution (work-on or close) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 232472] ixgbe(4): Hyper-V Guest FreeBSD-current and Intel X540 SR-IOV passthru not working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232472 Kubilay Kocak changed: What|Removed |Added Assignee|virtualizat...@freebsd.org |n...@freebsd.org CC||free...@intel.com, ||n...@freebsd.org Flags||maintainer-feedback?(whu@Fr ||eeBSD.org), ||maintainer-feedback?(freebs ||d...@intel.com), ||mfc-stable13?, ||mfc-stable12? Summary|Hyper-V Guest |ixgbe(4): Hyper-V Guest |FreeBSD-current and Intel |FreeBSD-current and Intel |X540 SR-IOV pass-thru not |X540 SR-IOV passthru not |working |working Keywords||needs-qa Version|CURRENT |13.0-RELEASE -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 232472] ixgbe(4): SR-IOV passthru not workingon Hyper-V 13-CURRENT guest with Intel X540
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232472 Kubilay Kocak changed: What|Removed |Added Summary|ixgbe(4): Hyper-V Guest |ixgbe(4): SR-IOV passthru |FreeBSD-current and Intel |not workingon Hyper-V |X540 SR-IOV passthru not|13-CURRENT guest with Intel |working |X540 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 239849] ixgbe(4): SR-IOV does not work on Intel x710 and Windows Server 2019 (Hyper-V) and 13.0-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239849 Kubilay Kocak changed: What|Removed |Added Resolution|--- |DUPLICATE Summary|INTEL X710, WINDOWS SERVER |ixgbe(4): SR-IOV does not |2019 HYPER-V, FreeBSD |work on Intel x710 and |Current, iavf |Windows Server 2019 ||(Hyper-V) and 13.0-CURRENT CC||free...@intel.com, ||n...@freebsd.org Version|CURRENT |13.0-RELEASE Status|Open|Closed --- Comment #4 from Kubilay Kocak --- ^Triage: Close duplicate of bug 232472. Both issues have the same patch attached. *** This bug has been marked as a duplicate of bug 232472 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 232472] ixgbe(4): SR-IOV passthru not workingon Hyper-V 13-CURRENT guest with Intel X540
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232472 --- Comment #5 from Kubilay Kocak --- *** Bug 239849 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 253620] Calling route delete with an invalid gateway deletes the route
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253620 --- Comment #2 from Alexander V. Chernikov --- I'll close this PR on Jun 5 if there are no other questions. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 258528] [fib_algo][routing] crash after switch algo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258528 --- Comment #1 from Alexander V. Chernikov --- Sorry for the belated reply. Were there any other similar crashes after this one? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 264248] ib_cm: Fix a resource leak in ib_cm_insert_listen()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264248 Hans Petter Selasky changed: What|Removed |Added Assignee|n...@freebsd.org |hsela...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 232472] ixgbe(4): SR-IOV passthru not working on Hyper-V 13-CURRENT guest with Intel X540 (0x152E)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232472 Kubilay Kocak changed: What|Removed |Added Keywords||feature Summary|ixgbe(4): SR-IOV passthru |ixgbe(4): SR-IOV passthru |not workingon Hyper-V |not working on Hyper-V |13-CURRENT guest with Intel |13-CURRENT guest with Intel |X540|X540 (0x152E) --- Comment #6 from Kubilay Kocak --- (In reply to Wei Hu from comment #4) Is this a backport of changes committed to later (> 11.x) or a direct patch for 11.x? If the latter, are we able to produce a patch for CURRENT for user testing? @Intel Could you review attachment 219194 and provide advice on getting these changes into base and upstream versions of the driver -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 232472] ixgbe(4): SR-IOV passthru not working on Hyper-V 13-CURRENT guest with Intel X540 (0x152E)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232472 Kubilay Kocak changed: What|Removed |Added Attachment #219194||maintainer-approval?(freebs Flags||d...@intel.com) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 263568] ix(4): SR-IOV connection lost after loading VM with a passthrough device (Intel X520-DAA2)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263568 Kubilay Kocak changed: What|Removed |Added CC||e...@freebsd.org, ||kbowl...@freebsd.org, ||krzysztof.gala...@intel.com Flags||maintainer-feedback?(kbowli ||n...@freebsd.org), ||maintainer-feedback?(krzysz ||tof.gala...@intel.com), ||maintainer-feedback?(erj@fr ||eebsd.org) --- Comment #4 from Kubilay Kocak --- ^Triage: Request feedback from folks that play in the sys/dev/ixgbe area -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 232472] ixgbe(4): SR-IOV passthru not working on Hyper-V 13-CURRENT guest with Intel X540 (0x152E)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232472 Kubilay Kocak changed: What|Removed |Added Flags||maintainer-feedback?(kbowli ||n...@freebsd.org), ||maintainer-feedback?(erj@fr ||eebsd.org), ||maintainer-feedback?(krzysz ||tof.gala...@intel.com) CC||e...@freebsd.org, ||kbowl...@freebsd.org, ||krzysztof.gala...@intel.com --- Comment #7 from Kubilay Kocak --- ^Triage: Request feedback from folks that play in the sys/dev/ixgbe area -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
