[Bug 240658] iflib: if_igb(4) and some if_em(4) devices don't recognize/report carrier loss.

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240658

--- Comment #5 from Harald Schmalzbauer <bugzilla.freebsd at omnilan.de> ---
(In reply to John Delano from comment #16) in Bug 239240

Thanks for your details.  Besides the link state issue and the initial issue
reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240658 we are
referring a third issue/fix with your latest comment – the first-packet
completion issue.
Since you mention that you didn't apply the proposed fix for the real 240658
issue, I use this bug report for my comment, which describes one of the issues
you addressed and to which your feedback corresponds better.

Regarding the 1st-packet-fix:
Thanks to the very detailed commit log in r343369 from erj@, he explains why
r343369 replaces r341156, r340310 and r341156.

This new fix (r343369) was MFCd in 344097 by marius, back in february.
How/why do you apply https://reviews.freebsd.org/D18545?


Regarding the topic (and link-state-fix https://reviews.freebsd.org/D21769):
I cannot reproduce this odd 1st-linkdetection-failure in my ESXi passthrough
environment!  But I intentionally took the plain iron and packed all intel NICs
I have into it, to do the test without any hypervisor/passthrough in between.
I did the test twice, since it seemed very odd to me too: After cold-start
booting from ISO with latest 12.1-BETA1 with https://reviews.freebsd.org/D21769
applied, the link state still reports the last state/speed before unplugging,
and does not catch the line drop, which changes when I once bring the interface
down/up.
In this scenario, rc(8) hasn't configured the NICs!  Mabye that's the
difference to your setup.
Will see to find time in the evening to further isolate the special condition.

Thanks,

-harry

-- 
You are receiving this mail because:
You are on the CC list for the bug.