Date: Fri, 02 May 2025 17:14:25 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 286530] panic during kldload if network drivers (if_vr, if_re) in ether_ifattach -> rtnl_handle_ifevent -> ifmedia_ioctl -> NULL ifm_status Message-ID: <bug-286530-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-286530-227>