[Bug 286530] panic during kldload if network drivers (if_vr, if_re) in ether_ifattach -> rtnl_handle_ifevent -> ifmedia_ioctl -> NULL ifm_status

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

            Bug ID: 286530
           Summary: panic during kldload if network drivers (if_vr, if_re)
                    in ether_ifattach -> rtnl_handle_ifevent ->
                    ifmedia_ioctl -> NULL ifm_status
           Product: Base System
           Version: 15.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: adrian@freebsd.org

Created attachment 260090
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=260090&action=edit
diff to add debugging / work around panic

I'm doing some testing on older hardware (single core K8) to test older
ethernet NICs and my vendor realtek ethernet driver.

However, when trying to do this, I discovered that loading network devices as
kernel modules after initial boot causes a panic.

It looks like the following occurs:

* kldload
* vr or re_attach
* ether_ifattach
* if_attach_internal
* rtnl_handle_ifattach
* rtnl_handle_ifevent
* dump_iface
* get_operstate_ether
* ifmedia_ioctl
* null pointer deref, ifm_status / ifm_media is NULL

These happen before the miibus finishes being initialised. Here's some debug
output with a NULL check and panic avoidance:

re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet> port
0xd000-0xd0ff mem 0xf6022000-0xf60220ff irq 16 at device 8.0 on pci0
re0: Chip rev. 0x10000000
re0: MAC rev. 0x00000000
re0: mii_attach: called
re0: mii_attach: first
re0: Using defaults for TSO: 65518/35/2048
ifmedia_ioctl: re0: ifm_status = NULL; erroring
re0: Ethernet address: 00:e0:4c:69:2f:16
re0: netmap queues/slots: TX 1/256, RX 1/256
miibus2: <MII bus> on re0
miibus2: miibus_attach: called
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus2
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX,
1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto,
auto-flow
re0: link state changed to DOWN

Note this doesn't happen for a USB device with an miibus/phy, it looks like the
miibus is probed/attached here first before the rest of the ethernet path is
brought up:

axe0 on uhub4
axe0: <Apple Inc. Apple USB Ethernet Adapter, rev 2.00/0.01, addr 2> on usbus4
uhid0 on uhub1
uhid0: <vendor 0x04d9 USB Keyboard, class 0/0, rev 1.10/3.10, addr 2> on usbus1
axe0: mii_attach: called
axe0: mii_attach: first
miibus0: <MII bus> on axe0
miibus0: miibus_attach: called
ukphy0: <Generic IEEE 802.3u media interface> PHY 16 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <USB Ethernet> on axe0
ue0: Ethernet address: dc:9b:9c:ed:a2:df
ue0: link state changed to DOWN

-- 
You are receiving this mail because:
You are the assignee for the bug.