Created attachment 249353 [details] Coredump text I have a panic when attaching if_bge on a Supermicro H13SSL-N The board has BCM7520 onboard LAN.
Created attachment 249354 [details] Backtrace
The panic actually happens when calling SIOCGIFMEDIA in ifmedia_ioctl() in sys/net/if_media.c from get_operstate_ether() in /usr/src/sys/netlink/route/iface.c (*ifm->ifm_status)(ifp, ifmr); with unpopulated ifm: ifm->ifm_mask = 0 ifm->ifm_media = 0 ifm->ifm_cur = 0x0 ifm->ifm_change = 0x0 ifm->ifm_status = 0x0
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 ifreq *ifr, struct ifmedia *ifm, /* * Get list of available media and current media on interface. */ case SIOCGIFMEDIA: case SIOCGIFXMEDIA: { struct ifmedia_entry *ep; int i; - if (ifmr->ifm_count < 0) + if (ifmr->ifm_count < 0 || ifm->ifm_status == NULL) return (EINVAL); if (cmd == SIOCGIFMEDIA) { ifmr->ifm_active = ifmr->ifm_current = ifm->ifm_cur ? compat_media(ifm->ifm_cur->ifm_media) : IFM_NONE; } else { ifmr->ifm_active = ifmr->ifm_current = ifm->ifm_cur ? ifm->ifm_cur->ifm_media : IFM_NONE; }
Created attachment 249689 [details] Workarounbd patch
(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. From line 3821 to 3842, either TBI mode or not the ifmedia data is initialized correctly. For if_bge, the ifp->if_ioctl should be bge_ioctl(). Can you get that frame ( if possible ), and examine `sc->bge_flags`, `sc->bge_ifmedia` and `sc->bge_miibus->softc->mii_media` ? sc == ifp->if_softc .
Sounds like https://cgit.freebsd.org/src/commit/?id=f2daf89954a we recently came across.
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 ifmedia_init() which could cause the issue. Judging from bug appearing in at least 3 drivers shouldn't we rather safeguard the internal function pointers in the ifmedia internals and/or provide a no-op function there by default? It seems brittle as it is now. Cheers, Franco
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 actual desired behaviour in the subsystem instead of letting it run into NULL function pointers.