https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
--- Comment #8 from Franco Fichtner ---
Well, if the assumption is correct a non-TBI ifmedia_init() call with existing
no-op functions passed should work around the issue from the driver side, but
it would be nicer to straighten out the act
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
--- Comment #7 from Franco Fichtner ---
Since we found another one in sfxge(4) just now I've looked at this again. TBI
mode seems to have the right ordering but I don't have the hardware. Is this
bug for non-TBI perhaps? This never calls i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
Franco Fichtner changed:
What|Removed |Added
CC||fra...@opnsense.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
--- Comment #5 from Zhenlei Huang ---
(In reply to Martin Matuska from comment #2)
> with unpopulated ifm:
> ifm->ifm_mask = 0
> ifm->ifm_media = 0
> ifm->ifm_cur = 0x0
> ifm->ifm_change = 0x0
> ifm->ifm_status = 0x0
That looks weird.
>Fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
--- Comment #4 from Martin Matuska ---
Created attachment 249689
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249689&action=edit
Workarounbd patch
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
--- Comment #3 from Martin Matuska ---
I can confirm that this workaround avoids the panic makes the network card
operate:
--- a/sys/net/if_media.c
+++ b/sys/net/if_media.c
@@ -272,19 +272,19 @@ ifmedia_ioctl(struct ifnet *ifp, struct ifre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277849
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keywords
