[Bug 2165864] [NEW] Ethernet MAC address not set correctly after Thunderbolt dock hot-plug on Dell systems

Public bug reported: [Impact] On Dell systems (CID: 202512-38196) with a Thunderbolt dock's Intel I225/I226 (igc) ethernet port, hot-plugging the dock can leave the ethernet interface non-functional or using the wrong MAC address. The dock's BIOS exposes a system MAC address through ACPI (\_SB.AMAC or \MACA objects) meant to override the NIC's own address, but the igc driver never reads it. The driver falls back to reading the MAC from NVM, which can race with the dock's own MAC copy timing or simply not match what the dock/BIOS expect, so the interface comes up with a stale or wrong MAC and networking fails. Failure rate on affected hardware: about 1 in 3 hot-plug cycles. Suspend/resume or cable bounce (CB/WB) works around it because the driver re-probes and picks up the right value on a later attempt. [Fix] Add ACPI-based MAC passthrough support to the igc driver. On probe, if the platform doesn't already hand the driver a MAC address, look up the \_SB.AMAC or \MACA ACPI objects. If a valid Ethernet MAC is found there, use it (mark it NET_ADDR_STOLEN) instead of falling back to the NVM read. If the objects don't exist or don't contain a valid MAC, the existing NVM read path is used unchanged, so unaffected hardware sees no behavior change. This also lets us drop two previous SAUCE patches that tried to fix the same failure by inserting a fixed delay (600ms, then 1000ms) before reading the NVM MAC on Thunderbolt-attached devices. Those were timing guesses and never fully closed the race; the ACPI passthrough reads the correctMAC directly instead of guessing how long to wait. Patches, in order: 1. Revert "UBUNTU: SAUCE: igc: Increase Thunderbolt MAC passthrough delay to 1000ms" 2. Revert "UBUNTU: SAUCE: igc: wait for the MAC copy when enabled MAC passthrough" 3. igc: Support ACPI-based MAC passthrough Patch 3 is posted upstream on the intel-wired-lan list (not yet merged): https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260823061006.344040-1-dima.ruinskiy@intel.com/ Or https://patchwork.ozlabs.org/project/intel-wired-lan/list?state=%2A&archive=both (search "igc: Support ACPI-based MAC passthrough") Note: the version carried in this branch is an earlier draft of the upstream patch (v1). The latest posted version (v3, dated 2026-08-22) additionally scopes the ACPI lookup to the I225/I226 device IDs used in docking stations only (via a new board_dock/is_dock flag), so it does not touch onboard I225/I226 NICs at all. We should pick up v3 once it lands, or apply the same device-ID scoping locally, to avoid the ACPI lookup running on non-dock onboard NICs. [Test Plan] 1. Connect an Ethernet cable to the Thunderbolt dock's ethernet port. 2. Boot the system with the dock disconnected. 3. Connect the dock to the system (hot-plug). 4. Check the ethernet interface comes up and has a stable, correct MAC address: $ ip link show <iface> $ dmesg | grep -i "igc.*MAC" 5. Repeat the hot-plug cycle at least 10 times. Without the patch: ethernet fails to come up or gets a wrong MAC on about 1 in 3 hot-plugs; recovers only after suspend/resume or an unplug/replug cycle. With the patch: dmesg shows "Using ACPI pass-thru MAC addr ..." on each hot-plug, and the interface consistently comes up with the correct MAC every time. [Where problems could occur] This touches the igc driver's probe path, which runs for every I225/I226 device, not only docked ones (the version currently in this branch does not yet limit the ACPI lookup to dock device IDs). If the ACPI object parsing is wrong, or if a system unrelated to docks happens to expose a \_SB.AMAC or \MACA object with data that passes the length/format check, the driver could pick up an unintended MAC address on any I225/I226 NIC, including onboard ones. That would show up as a network interface with a wrong MAC address, causing it to be unreachable at its expected address orto collide with another device on the network. The ACPI object parsing itself (string length checks, hex2bin conversion) is also new code in the probe path; a bug there could misparse a valid ACPI buffer and either wrongly reject a valid dock MAC (falling back to the old NVM path, low risk) or wrongly accept malformed data as a MAC (higher risk, described above). ** Affects: linux (Ubuntu) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux-oem-7.0 (Ubuntu) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Noble) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-7.0 (Ubuntu Noble) Importance: Undecided Status: Invalid ** Affects: linux (Ubuntu Resolute) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: Invalid ** Affects: linux-oem-7.0 (Ubuntu Resolute) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux (Ubuntu Stonking) Importance: Undecided Assignee: AceLan Kao (acelankao) Status: In Progress ** Affects: linux-oem-6.17 (Ubuntu Stonking) Importance: Undecided Status: Invalid ** Affects: linux-oem-7.0 (Ubuntu Stonking) Importance: Undecided Status: Invalid ** Description changed: [Impact] On Dell systems (CID: 202512-38196) with a Thunderbolt dock's Intel I225/I226 (igc) ethernet port, hot-plugging the dock can leave the ethernet interface non-functional or using the wrong MAC address. The dock's BIOS exposes a system MAC address through ACPI (\_SB.AMAC or \MACA objects) meant to override the NIC's own address, but the igc driver never reads it. The driver falls back to reading the MAC from NVM, which can race with the dock's own MAC copy timing or simply not match what the dock/BIOS expect, so the interface comes up with a stale or wrong MAC and networking fails. Failure rate on affected hardware: about 1 in 3 hot-plug cycles. Suspend/resume or cable bounce (CB/WB) works around it because the driver re-probes and picks up the right value on a later attempt. [Fix] Add ACPI-based MAC passthrough support to the igc driver. On probe, if the platform doesn't already hand the driver a MAC address, look up the \_SB.AMAC or \MACA ACPI objects. If a valid Ethernet MAC is found there, use it (mark it NET_ADDR_STOLEN) instead of falling back to the NVM read. If the objects don't exist or don't contain a valid MAC, the existing NVM read path is used unchanged, so unaffected hardware sees no behavior change. This also lets us drop two previous SAUCE patches that tried to fix the same failure by inserting a fixed delay (600ms, then 1000ms) before reading the NVM MAC on Thunderbolt-attached devices. Those were timing guesses and never fully closed the race; the ACPI passthrough reads the correctMAC directly instead of guessing how long to wait. Patches, in order: 1. Revert "UBUNTU: SAUCE: igc: Increase Thunderbolt MAC passthrough delay to 1000ms" 2. Revert "UBUNTU: SAUCE: igc: wait for the MAC copy when enabled MAC passthrough" 3. igc: Support ACPI-based MAC passthrough Patch 3 is posted upstream on the intel-wired-lan list (not yet merged): + https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260823061006.344040-1-dima.ruinskiy@intel.com/ + Or https://patchwork.ozlabs.org/project/intel-wired-lan/list?state=%2A&archive=both (search "igc: Support ACPI-based MAC passthrough") Note: the version carried in this branch is an earlier draft of the upstream patch (v1). The latest posted version (v3, dated 2026-08-22) additionally scopes the ACPI lookup to the I225/I226 device IDs used in docking stations only (via a new board_dock/is_dock flag), so it does not touch onboard I225/I226 NICs at all. We should pick up v3 once it lands, or apply the same device-ID scoping locally, to avoid the ACPI lookup running on non-dock onboard NICs. [Test Plan] 1. Connect an Ethernet cable to the Thunderbolt dock's ethernet port. 2. Boot the system with the dock disconnected. 3. Connect the dock to the system (hot-plug). 4. Check the ethernet interface comes up and has a stable, correct MAC address: $ ip link show <iface> $ dmesg | grep -i "igc.*MAC" 5. Repeat the hot-plug cycle at least 10 times. Without the patch: ethernet fails to come up or gets a wrong MAC on about 1 in 3 hot-plugs; recovers only after suspend/resume or an unplug/replug cycle. With the patch: dmesg shows "Using ACPI pass-thru MAC addr ..." on each hot-plug, and the interface consistently comes up with the correct MAC every time. [Where problems could occur] This touches the igc driver's probe path, which runs for every I225/I226 device, not only docked ones (the version currently in this branch does not yet limit the ACPI lookup to dock device IDs). If the ACPI object parsing is wrong, or if a system unrelated to docks happens to expose a \_SB.AMAC or \MACA object with data that passes the length/format check, the driver could pick up an unintended MAC address on any I225/I226 NIC, including onboard ones. That would show up as a network interface with a wrong MAC address, causing it to be unreachable at its expected address orto collide with another device on the network. The ACPI object parsing itself (string length checks, hex2bin conversion) is also new code in the probe path; a bug there could misparse a valid ACPI buffer and either wrongly reject a valid dock MAC (falling back to the old NVM path, low risk) or wrongly accept malformed data as a MAC (higher risk, described above). ** Also affects: linux-oem-6.17 (Ubuntu Resolute) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: linux-oem-7.0 (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-oem-6.17 (Ubuntu Stonking) Importance: Undecided Status: New ** Also affects: linux-oem-7.0 (Ubuntu Stonking) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Noble) Status: New => In Progress ** Changed in: linux (Ubuntu Noble) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux (Ubuntu Resolute) Status: New => In Progress ** Changed in: linux (Ubuntu Resolute) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux (Ubuntu Stonking) Status: New => In Progress ** Changed in: linux (Ubuntu Stonking) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-6.17 (Ubuntu Noble) Status: New => In Progress ** Changed in: linux-oem-6.17 (Ubuntu Noble) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-6.17 (Ubuntu Resolute) Status: New => Invalid ** Changed in: linux-oem-6.17 (Ubuntu Stonking) Status: New => Invalid ** Changed in: linux-oem-7.0 (Ubuntu Noble) Status: New => Invalid ** Changed in: linux-oem-7.0 (Ubuntu Resolute) Status: New => In Progress ** Changed in: linux-oem-7.0 (Ubuntu Resolute) Assignee: (unassigned) => AceLan Kao (acelankao) ** Changed in: linux-oem-7.0 (Ubuntu Stonking) Status: New => Invalid -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165864 Title: Ethernet MAC address not set correctly after Thunderbolt dock hot-plug on Dell systems Status in linux package in Ubuntu: In Progress Status in linux-oem-6.17 package in Ubuntu: Invalid Status in linux-oem-7.0 package in Ubuntu: Invalid Status in linux source package in Noble: In Progress Status in linux-oem-6.17 source package in Noble: In Progress Status in linux-oem-7.0 source package in Noble: Invalid Status in linux source package in Resolute: In Progress Status in linux-oem-6.17 source package in Resolute: Invalid Status in linux-oem-7.0 source package in Resolute: In Progress Status in linux source package in Stonking: In Progress Status in linux-oem-6.17 source package in Stonking: Invalid Status in linux-oem-7.0 source package in Stonking: Invalid Bug description: [Impact] On Dell systems (CID: 202512-38196) with a Thunderbolt dock's Intel I225/I226 (igc) ethernet port, hot-plugging the dock can leave the ethernet interface non-functional or using the wrong MAC address. The dock's BIOS exposes a system MAC address through ACPI (\_SB.AMAC or \MACA objects) meant to override the NIC's own address, but the igc driver never reads it. The driver falls back to reading the MAC from NVM, which can race with the dock's own MAC copy timing or simply not match what the dock/BIOS expect, so the interface comes up with a stale or wrong MAC and networking fails. Failure rate on affected hardware: about 1 in 3 hot-plug cycles. Suspend/resume or cable bounce (CB/WB) works around it because the driver re-probes and picks up the right value on a later attempt. [Fix] Add ACPI-based MAC passthrough support to the igc driver. On probe, if the platform doesn't already hand the driver a MAC address, look up the \_SB.AMAC or \MACA ACPI objects. If a valid Ethernet MAC is found there, use it (mark it NET_ADDR_STOLEN) instead of falling back to the NVM read. If the objects don't exist or don't contain a valid MAC, the existing NVM read path is used unchanged, so unaffected hardware sees no behavior change. This also lets us drop two previous SAUCE patches that tried to fix the same failure by inserting a fixed delay (600ms, then 1000ms) before reading the NVM MAC on Thunderbolt-attached devices. Those were timing guesses and never fully closed the race; the ACPI passthrough reads the correctMAC directly instead of guessing how long to wait. Patches, in order: 1. Revert "UBUNTU: SAUCE: igc: Increase Thunderbolt MAC passthrough delay to 1000ms" 2. Revert "UBUNTU: SAUCE: igc: wait for the MAC copy when enabled MAC passthrough" 3. igc: Support ACPI-based MAC passthrough Patch 3 is posted upstream on the intel-wired-lan list (not yet merged): https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260823061006.344040-1-dima.ruinskiy@intel.com/ Or https://patchwork.ozlabs.org/project/intel-wired-lan/list?state=%2A&archive=both (search "igc: Support ACPI-based MAC passthrough") Note: the version carried in this branch is an earlier draft of the upstream patch (v1). The latest posted version (v3, dated 2026-08-22) additionally scopes the ACPI lookup to the I225/I226 device IDs used in docking stations only (via a new board_dock/is_dock flag), so it does not touch onboard I225/I226 NICs at all. We should pick up v3 once it lands, or apply the same device-ID scoping locally, to avoid the ACPI lookup running on non-dock onboard NICs. [Test Plan] 1. Connect an Ethernet cable to the Thunderbolt dock's ethernet port. 2. Boot the system with the dock disconnected. 3. Connect the dock to the system (hot-plug). 4. Check the ethernet interface comes up and has a stable, correct MAC address: $ ip link show <iface> $ dmesg | grep -i "igc.*MAC" 5. Repeat the hot-plug cycle at least 10 times. Without the patch: ethernet fails to come up or gets a wrong MAC on about 1 in 3 hot-plugs; recovers only after suspend/resume or an unplug/replug cycle. With the patch: dmesg shows "Using ACPI pass-thru MAC addr ..." on each hot-plug, and the interface consistently comes up with the correct MAC every time. [Where problems could occur] This touches the igc driver's probe path, which runs for every I225/I226 device, not only docked ones (the version currently in this branch does not yet limit the ACPI lookup to dock device IDs). If the ACPI object parsing is wrong, or if a system unrelated to docks happens to expose a \_SB.AMAC or \MACA object with data that passes the length/format check, the driver could pick up an unintended MAC address on any I225/I226 NIC, including onboard ones. That would show up as a network interface with a wrong MAC address, causing it to be unreachable at its expected address orto collide with another device on the network. The ACPI object parsing itself (string length checks, hex2bin conversion) is also new code in the probe path; a bug there could misparse a valid ACPI buffer and either wrongly reject a valid dock MAC (falling back to the old NVM path, low risk) or wrongly accept malformed data as a MAC (higher risk, described above). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165864/+subscriptions