User Details
- User Since
- Jun 6 2015, 10:46 PM (458 w, 2 d)
Sep 21 2023
Aug 24 2023
Don't toggle vmxnet3
Sweep the drivers
Aug 23 2023
Aug 22 2023
Aug 18 2023
Makes sense to me to get these in and continue the audit/additions
@bofh do you know if this was something you had to mark BROKEN or work around?
Aug 16 2023
What is triggering this for you?
I see the optional assignment so I guess that part is fine. Ultimately it's not my port but if danfe is not going to comment I have no objections.
It is not necessary to do it like this. There is an implied version contract with this port and x11/linux-nvidia-libs as well. If it is centralized, it needs to accommodate the entire nvidia-driver situation because this will cause build failures.
I think you should remove the distversion thing, that will break the legacy ports and seems unnecessary.
Aug 13 2023
@erj can you post the draft driver update, I'd like to see how it intends to use this patch stack before commentary
Aug 9 2023
Aside from some research notes there is nothing to do here.
Aug 4 2023
Jul 31 2023
rebase after committed changes
Jul 29 2023
@shurd updated automask to not require the iflib internal change.
I've found a way to do this without modifying iflib.
Jul 28 2023
@shurd I added some smarts to the TSO automask. Also added a sysctl for people that want to opt out of.
Jul 27 2023
Jul 26 2023
Don't try TSO on 10/100 for lem(4)/em(4)
Jul 25 2023
Jun 27 2023
Jun 9 2023
May 11 2023
I think it's probably fine but can you elaborate situations where vlan 0 is "tagged"
May 8 2023
Apr 29 2023
Use a bool
Apr 25 2023
Feb 9 2023
Dec 20 2022
Oct 17 2022
The problem is what you submitted is logically inconsistent in the e1000 code. Other consumers of this code (i.e. Linux, DPDK) have not plugged the holes either (for the record they do not implement this improvement). I've provided a starting pointer in the phy code. You will find at least one more issue in the lem(4) phy code. This is via ripgrep and code inspection, you don't need any hardware to see it.
Oct 12 2022
I can see where the "shared code" (e1000 api) is not ready in general and for lem(4). For the submitter, if you want to try and chase that down e1000_setup_copper_link_generic() in e1000_phy.c.. maybe try modifying the conditional. I'm going to revert this.
Oct 10 2022
Jun 22 2022
May 15 2022
May 10 2022
May 4 2022
Apr 19 2022
Apr 13 2022
Committed as 395cc55d8966
Committed as 07ede751612f
I think hw->phy.autoneg_wait_to_complete is also set to false in the driver earlier in em_if_attach_pre() and never changes.
Feb 3 2022
Dec 20 2021
Dec 18 2021
I'm less optimistic about the ifp seeing the change required in all drivers, @gallatin odes anyone have any idea on the impact of the ifp pointer chase and fetch versus grabbing it from the already fetched scctx in these hot paths? How would we sync scctx_capenable with ifnet, that seems to be a critical missing implementation from the outset.
Dec 14 2021
Dec 10 2021
Dec 1 2021
Nov 1 2021
Oct 27 2021
Oct 22 2021
Oct 20 2021
Oct 10 2021
It was pointed out to me there is still an issue in that we pick up a new sx within the epoch, both in create and timeout with my patch as is For some reason the epoch _preempt variety doesn't produce a diagnostic so I will look into that code.
Oct 9 2021
Thanks @markj what do you think of this approach using epoch?
Jose submitted a variant where the driver (e1000 in this case) calls the iflib_led_create() function in its post attach. I am open to either approach if anyone has any thoughts one way or the other.
Oct 7 2021
Ping. Awaiting approval
Oct 6 2021
@gallatin can you have another look? The locking model on the e1000 is tricky due to the HW so I stashed the info on attach. There's a separate KASSERT fix for em_print_nvm_info for review as well.