- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
Thu, Jun 13
Open question: when do we commit this? Now, in advance of 15.0? As soon as stable/15 branches, so that it will first arrive in 16.0?
Wed, Jun 12
Tue, Jun 11
Mon, Jun 10
Sat, Jun 8
Fri, Jun 7
Thu, Jun 6
Tue, Jun 4
This causes my Dell T640 boxes to use the mrsas driver without having to explicitly set the loader.conf variable (as I was doing previously), so as far as I'm concerned this is an improvement.
Fri, May 31
- Move driver changes into separate commits
- support 'vlan: trunk;', indicating there's no vlan filtering For this we pass vlan id 4096, which drivers translate into meaning 'no vlan acl'. This allows drivers that can handle it to use vlan id 0 to mean 'vlan header, but logically untagged'.
This version resolves the panic I saw.
Thu, May 30
I still see a panic (on the host) when I kldload if_cxgbev in a bhyve guest that has a VF passed to it:
Wed, May 29
I've not been able to test the mxl5 changes as I don't have access to the hardware.
Tue, May 28
Sun, May 26
Wed, May 22
Tue, May 21
In D45283#1033174, @zlei wrote:@kp I'm going to commit this if no objections.
No objection. Go ahead and commit.
I've fixed the other vlan issue in https://reviews.freebsd.org/D45285.
diff --git a/tests/sys/net/if_vlan.sh b/tests/sys/net/if_vlan.sh index 675ed0090e8c..4d5d70410898 100755 --- a/tests/sys/net/if_vlan.sh +++ b/tests/sys/net/if_vlan.sh @@ -37,7 +37,7 @@ basic_body() # And change back # Test changing the vlan ID atf_check -s exit:0 \ - jexec singsing ifconfig ${vlan1} vlandev ${epair_vlan}b vlan 42 + jexec singsing ifconfig ${vlan1} vlan 42 vlandev ${epair_vlan}b atf_check -s exit:0 -o ignore jexec singsing ping -c 1 10.0.0.1 }
Mon, May 20
Thu, May 16
May 15 2024
In D44488#1031012, @markj wrote:but with this change we are implicitly rewriting the source port. What explicit mechanism is the man page alluding to here?
That'd be things like rdr on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 port 8080, where we redirect incoming connections on port 80 to localhost port 8080.
When we're doing explicit rewrites it's always going to be the destination port, of course.
May 14 2024
I'm not sure I'd have bothered to make the nesting level configurable, but now that you've done the work it'd be silly to not use it.
The referenced commit (2b9600b4497b) seems to be relevant for the detach flow, but it doesn't guarantee there will an if_bpf pointer when a struct ifnet is created.
However, ether_ifattach() does an unconditional bpfattach(), so I think this is still correct (given that mlx* are Ethernet devices).
May 13 2024
May 12 2024
May 9 2024
May 8 2024
May 7 2024
In D44774#1028978, @lwhsu wrote:My personal suggestion: it's worth to mention it in carp(4), and perhaps even adding a link of vrrp(4)
Last call for objections. I intend to commit tomorrow.
May 6 2024
May 4 2024
In D44774#1028213, @bz wrote:In D44774#1027883, @kp wrote:In D44774#1027778, @bz wrote:(2) We are adding to but not fixing the problem of the conflicting version number; it's easy to say I can add v3 but ... see (1).
As in carpv3? That seems entirely unlikely to ever happen, given that carp's entire reason for existing is now moot.
No, as in carp getting an official version number.
I'm not sure I follow. Do you mean carp might be officially designated vrrp version 9 (let's say)? That seems both very unlikely, and something that wouldn't actually be a problem to deal with. We already distinguish vrrpv3 from carp by the version number, so looking for version 9 would, if anything, make things easier.