[Bug 95277] fix IP Encapsulation mask_match() returning wrong results
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=95277 --- Comment #12 from Andrey V. Elsukov --- I think this PR is no longer relevant after https://reviews.freebsd.org/D15617 -- You are receiving this mail because: You are the assignee for the bug.
Re: CALL FOR TEST axgbe promisc mode
On Tue, Oct 01, 2024 at 12:46:07PM +, Franco Fichtner wrote: > Hi, > > > On 1. Oct 2024, at 02:47, Zhenlei Huang wrote: > > > > The test plan is simple, either of the following should suffice: > > > > • Do traffic sniffing on axgbe interface. The interface will enter promisc > > mode and should see packets not for us. > > I tested this with and without the patch and it's inconclusive: > > 1. tcpdump sees foreign packets with and without patch > 2. tcpdump -p sees foreign packets with and without patch That's somewhat surprising. > > This oddly enough matches my expectation that nobody raised issues about > promisc not working so far, but it leaves the question if we are/I am testing > the > right thing? I think you are. BPF uses ifpromisc() to enable promiscuous mode, and tcpdump uses that interface rather than setting IFF_PPROMISC directly, and without the patch I expect that that's a bit broken. There is perhaps an unrelated driver bug there. I wonder what flags get printed by ifconfig before and during your experiments. It'd also be useful to try enabling debug logging (sysctl dev.ax.0.axgbe_debug_level=1, I think) to see if axgbe_if_promisc_set() is getting executed as expected. > > > Cheers, > Franco > > ax0: mem > 0x8016-0x8017,0x8014-0x8015,0x80188000-0x80189fff at device > 0.4 on pci6 > ax0: Using 512 TX descriptors and 512 RX descriptors > ax0: Using 4 RX queues 4 TX queues > ax0: Using MSI-X interrupts with 8 vectors > ax0: Ethernet address: XX:XX:XX:XX:XX:XX > ax0: xgbe_config_sph_mode: SPH disabled in channel 0 > ax0: xgbe_config_sph_mode: SPH disabled in channel 1 > ax0: xgbe_config_sph_mode: SPH disabled in channel 2 > ax0: xgbe_config_sph_mode: SPH disabled in channel 3 > ax0: RSS Enabled > ax0: Receive checksum offload Enabled > ax0: VLAN filtering Enabled > ax0: VLAN Stripping Enabled > ax0: Checking GPIO expander validity > ax0: GPIO configuration valid > ax0: SFP detected: > ax0: vendor: FS ax0: part number:SFP-10G-Tax0: > revision level: Aax0: serial number: XXX ax0: netmap > queues/slots: TX 4/512, RX 4/512 > ax0: Link is UP - 10Gbps/Full - flow control off > ax0: link state changed to UP > ax0: xgbe_config_sph_mode: SPH disabled in channel 0 > ax0: xgbe_config_sph_mode: SPH disabled in channel 1 > ax0: xgbe_config_sph_mode: SPH disabled in channel 2 > ax0: xgbe_config_sph_mode: SPH disabled in channel 3 > ax0: RSS Enabled > ax0: Receive checksum offload Disabled > ax0: VLAN filtering Disabled > ax0: VLAN Stripping Disabled > ax0: promiscuous mode enabled > ax0: promiscuous mode disabled
[Bug 95277] fix IP Encapsulation mask_match() returning wrong results
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=95277 Mark Linimon changed: What|Removed |Added Keywords|patch | Summary|[netinet] [patch] IP|fix IP Encapsulation |Encapsulation mask_match() |mask_match() returning |returns wrong results |wrong results --- Comment #11 from Mark Linimon --- ^Triage: bring this PR up to modern standards. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 171228] [re] [patch] if_re - eeprom write issues
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171228 Mark Linimon changed: What|Removed |Added Keywords|patch | Assignee|b...@freebsd.org|n...@freebsd.org CC||bugmeis...@freebsd.org --- Comment #4 from Mark Linimon --- ^To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281560] gve (4) uma deadlock during high tcp throughput
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560 --- Comment #18 from shail...@google.com --- (In reply to Konstantin Belousov from comment #14) Although I do not have access to the VMs to do `show pcpu`, I checked my notes to find this `ps` entry: 100438 Run CPU 11 [gve0 txq 4 xmit] The packet transmitting thread is hogging the cpu and preventing iperf from ever running to release the uma lock. The "gve0 txq 4 xmit" is running forever because it is waiting on the tx cleanup thread to make room on the ring, and that thread is not doing anything because it is waiting on the uma zone lock. I did another repro, and the situation is similar: ``` db> show lockchain 100416 thread 100416 (pid 0, gve0 rxq 0) is blocked on lock 0xfe00df57a3d0 (sleep mutex) "mbuf" thread 100708 (pid 860, iperf) is on a run queue db> show lockchain 100423 thread 100423 (pid 0, gve0 rxq 7) is blocked on lock 0xf8010447daa0 (rw) "tcpinp" thread 100736 (pid 860, iperf) is blocked on lock 0xfe00df57a3d0 (sleep mutex) "mbuf" thread 100708 (pid 860, iperf) is on a run queue db> show lockchain 100452 thread 100452 (pid 0, gve0 txq 10) is blocked on lock 0xfe00df57a3d0 (sleep mutex) "mbuf" thread 100708 (pid 860, iperf) is on a run queue ``` Here 100708 is the offending iperf thread. Lets see its state: ``` db> show thread 100708 Thread 100708 at 0xf800a86bd000: proc (pid 860): 0xfe01a439bac0 name: iperf pcb: 0xf800a86bd520 stack: 0xfe01a4dc1000-0xfe01a4dc4fff flags: 0x5 pflags: 0x100 state: RUNQ priority: 4 container lock: sched lock 31 (0xfe001bee8440) last voluntary switch: 11510.470 s ago last involuntary switch: 11510.470 s ago ``` And now lets see whats happening on cpu 31: ``` db> show pcpu 31 cpuid= 31 dynamic pcpu = 0xfe009a579d80 curthread= 0xf800a8501740: pid 0 tid 100453 critnest 0 "gve0 txq 10 xmit" curpcb = 0xf800a8501c60 fpcurthread = none idlethread = 0xf80003b04000: tid 100034 "idle: cpu31" self = 0x8242f000 curpmap = 0x81b79c50 tssp = 0x8242f384 rsp0 = 0xfe01a4ca8000 kcr3 = 0x ucr3 = 0x scr3 = 0x0 gs32p= 0x8242f404 ldt = 0x8242f444 tss = 0x8242f434 curvnet = 0 spin locks held: ``` Sure enough a driver transmit thread is hogging the cpu. And to seal the loop, lets see what this queue's cleanup thread is doing: ``` db> show lockchain 100452 thread 100452 (pid 0, gve0 txq 10) is blocked on lock 0xfe00df57a3d0 (sleep mutex) "mbuf" thread 100708 (pid 860, iperf) is on a run queue ``` In summary this is the usual loop: iperf thread (with uma zone lock) ---sched---> gve tx xmit thread ---for room---> gve tx cleanup thread -uma zone lock> iperf thread There is clearly a problematic behavior in the driver transmit thread (gve_xmit_br): this taskqueue should not enqueue itself, and should rather let the cleanup taskqueue wake it up when room is made in the ring, so I'll work on that. But I also want to confirm that it is not problematic for an iperf thread to be knocked off the cpu with the zone lock held: is it not a critical enough lock to disallow that? (I am not very familiar with schedulers to know if this is a naive question). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281560] gve (4) uma deadlock during high tcp throughput
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560 --- Comment #19 from Konstantin Belousov --- (In reply to shailend from comment #18) Locks (except spinlocks) do not have any magic properties WRT disabling scheduling. So it is absolutely fine for a thread owning a lock to be put off CPU if there is another thread with higher priority. OTOH, for locks like mutexes and rwlocks (that use turnstiles) the system propagates priorities from lock contenders to lock owners to avoid priority inversion. Which raises the question, what is the priority of that running tx thread vs the priority of the lock owner? Could it be that the tx thread was assigned too high priority, causing this live-lock? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 237973] pf: implement egress keyword to simplify rules across different hardware
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237973 Mark Linimon changed: What|Removed |Added Flags|mfc-stable12?, | |mfc-stable11? | --- Comment #26 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 240944] em(4): Crash with Intel 82571EB NIC with AMD Piledriver and Steamroller APUs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240944 Mark Linimon changed: What|Removed |Added Flags|mfc-stable12?, | |mfc-stable11? | --- Comment #17 from Mark Linimon --- ^Triage: clear stale flags. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 256393] Issue with recreation of ppp/tun interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256393 Mark Linimon changed: What|Removed |Added CC|rgri...@freebsd.org | Flags|mfc-stable13?, | |mfc-stable12-, | |mfc-stable11- | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 238324] Add XG-C100C/AQtion AQC107 10GbE NIC driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238324 Mark Linimon changed: What|Removed |Added Flags|mfc-stable12?, | |mfc-stable11? | --- Comment #17 from Mark Linimon --- ^Triage: the latest upstream commit seems to be: https://github.com/Aquantia/aqtion-freebsd/commit/2751764d91c88a6766e3a54af0f560aa30912106 Jan 24, 2022 This is 3 years newer than the port. While here, clear stale flags. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 237072] netgraph(4): performance issue [on HardenedBSD]?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237072 Mark Linimon changed: What|Removed |Added Flags|mfc-stable12?, | |mfc-stable11? | --- Comment #16 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281560] gve (4) uma deadlock during high tcp throughput
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560 --- Comment #20 from shail...@google.com --- (In reply to Konstantin Belousov from comment #19) Thanks for the explanation. The iperf thread owning the lock and the driver thread looping on the cpu both have priority 4. The driver thread was created with `taskqueue_create_fast`. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 202510] [CARP] advertisements sourced from CARP IP cause double MASTER situations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202510 Mark Linimon changed: What|Removed |Added Flags|mfc-stable11?, | |mfc-stable10?, mfc-stable9? | CC|ko...@freebsd.org |bugmeis...@freebsd.org --- Comment #10 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 196944] [bge] [ipmi] regression IPMI access disabled when bge driver is loaded
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196944 Mark Linimon changed: What|Removed |Added Flags|mfc-stable10?, mfc-stable9? | --- Comment #13 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 204438] setsockopt() handling of kern.ipc.maxsockbuf limit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204438 Mark Linimon changed: What|Removed |Added Flags|mfc-stable10?, mfc-stable9? | Keywords|patch | --- Comment #20 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 206528] Emulex LPe 16002 FC HBA Not Recognized by oce(4) driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206528 Mark Linimon changed: What|Removed |Added Flags|mfc-stable10? | CC||bugmeis...@freebsd.org --- Comment #7 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 207261] netmap: Doesn't do TX sync with kqueue
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207261 Mark Linimon changed: What|Removed |Added Flags|maintainer-feedback?(vmaffi | |o...@freebsd.org), | |mfc-stable12?, | |mfc-stable11?, | |mfc-stable10? | --- Comment #10 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 281560] gve (4) uma deadlock during high tcp throughput
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560 --- Comment #21 from Konstantin Belousov --- (In reply to shailend from comment #20) Then, this is especially looks like a live-lock. User thread should not have the priority 4, it is in the range of priorities of the interrupt threads. Since the iperf thread owns the lock, and driver thread contends for the lock, most likely it is the result of priority propagation. In other words, iperf thread must drop the lock to allow the system to make a progress. Perhaps it should do so after processing some fixed amount of work. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 256579] arp(8) -S doesn't honour "blackhole" keyword
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256579 Mark Linimon changed: What|Removed |Added Flags|mfc-stable13?, | |mfc-stable12?, | |mfc-stable11- | --- Comment #3 from Mark Linimon --- ^Triage: clear stale flags. To assignee: is this aging PR still relevant? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 193452] Dell PowerEdge 210 II -- Kernel panic bce (broadcom)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193452 Mark Linimon changed: What|Removed |Added CC|sbr...@freebsd.org |bugmeis...@freebsd.org Flags|mfc-stable10?, mfc-stable9? | --- Comment #3 from Mark Linimon --- ^Triage: clear stale flags. To submitter: is this aging PR still relevant? -- You are receiving this mail because: You are the assignee for the bug.
