[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 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 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 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 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 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 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 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 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 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 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 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 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 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 --- 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 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 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.
