[V2] net/intel/e1000: reduce the optimization level for gcc > 11

[Thierry Herbelot]

On 10/8/25 12:10, Thomas Monjalon wrote:
> 08/10/2025 10:38, Bruce Richardson:
>> On Mon, Oct 06, 2025 at 03:02:57PM +0200, Thierry Herbelot wrote:
>>> The e1000 PMD stopped working under Ubuntu-24.04 (using gcc-13) when
>>> compiled with -O3 (default level for all DPDK code). There is a crash
>>> when starting testpmd:
>>>
>>>> (gdb) bt
>>>> #0  rte_read32_relaxed (addr=0x1100800e00) at ../sources/lib/eal/include/generic/rte_io.h:290
>>>> #1  rte_read32 (addr=0x1100800e00) at ../sources/lib/eal/include/generic/rte_io.h:345
>>>> #2  e1000_read_addr (addr=0x1100800e00) at ../sources/drivers/net/intel/e1000/base/e1000_osdep.h:106
>>>> #3  e1000_id_led_init_generic (hw=0x1586788c0) at ../sources/drivers/net/intel/e1000/base/e1000_mac.c:1844
>>>> #4  0x000062aaf653c85f in e1000_init_hw_82540 (hw=0x1586788c0)
>>>>      at ../sources/drivers/net/intel/e1000/base/e1000_82540.c:308
>>>> #5  0x000062aaf6db8227 in em_hardware_init (hw=hw at entry=0x1586788c0)
>>>>      at ../sources/drivers/net/intel/e1000/em_ethdev.c:920
>>>> #6  0x000062aaf65340ff in em_hw_init (hw=0x1586788c0) at ../sources/drivers/net/intel/e1000/em_ethdev.c:445
>>>> #7  eth_em_dev_init (eth_dev=eth_dev at entry=0x62aaff346000 <rte_eth_devices>)
>>>>      at ../sources/drivers/net/intel/e1000/em_ethdev.c:314
>>>> #8  0x000062aaf6db8b71 in rte_eth_dev_pci_generic_probe (private_data_size=11240,
>>>>      dev_init=0x62aaf6db8310 <eth_em_dev_init>, pci_dev=0x62ab2853dd90) at ../sources/lib/ethdev/ethdev_pci.h:150
>>>> #9  eth_em_pci_probe (pci_drv=<optimized out>, pci_dev=0x62ab2853dd90)
>>>>      at ../sources/drivers/net/intel/e1000/em_ethdev.c:365
>>>> #10 0x000062aaf646adf5 in rte_pci_probe_one_driver (dr=dr at entry=0x62aaf82d8020 <rte_em_pmd>,
>>>>      dev=dev at entry=0x62ab2853dd90) at ../sources/drivers/bus/pci/pci_common.c:299
>>>> #11 0x000062aaf6a15f7d in pci_probe_all_drivers (dev=0x62ab2853dd90) at ../sources/drivers/bus/pci/pci_common.c:383
>>>> #12 pci_probe () at ../sources/drivers/bus/pci/pci_common.c:410
>>>> #13 0x000062aaf7a485f3 in rte_bus_probe () at ../sources/lib/eal/common/eal_common_bus.c:84
>>>> #14 0x000062aaf670585d in rte_eal_init (argc=argc at entry=146, argv=argv at entry=0x7fffca468898)
>>>>      at ../sources/lib/eal/linux/eal.c:1253
>>>
>>> The crash is linked to the use of gcc-13: under Ubuntu-24.04 testpmd
>>> compiled with gcc-11 from the same DPDK tree works as expected.
>>>
>>> The perfect solution would be for someone to investigate why the
>>> PMD crashes. However, this depends on Maintainer availability.
>>>
>>> A less-perfect solution is to reduce the optimization level
>>> (like another proposal for net/qede: see Link).
>>>
>> Thanks for reporting the issue. I'd like to spend a little time trying to
>> really root cause the issue before applying this workaround patch. Can you
>> provide a bit more info about the setup you used when you hit this issue. I
>> expect a lot of use of e1000 driver is in virtualized setups, but can you
>> confirm if that was the case here, or were you using real hardware?

Hello Bruce, Thomas

Sorry for the missing info: the issue was indeed seen in qemu (in more 
than one version).

I'm not sure we have a real NIC lying around, for this PMD.

>>
>> If we do have to apply this workaround fix of reducing optimization level,
>> I see you reduce optimization for both the base code and the DPDK-specific
>> driver code. Is it necessary to reduce optimization on both, or can we get
>> away with just reducing it on the DPDK part alone?

As for net/qede, I did not take time to investigate which piece of code 
was concerned. I just checked that testpmd really works in an 
Ubuntu-24.04 VM, when DPDK is compiled with gcc-11 rather than the 
default gcc-13.

Then the crude workaround is to drop the optimization level for all of 
the PMD. As for net/qede, '-O1' is a compromise as the PMD seems to be 
working fine, and still the performance is acceptable.

> 
> We are not sure the workaround will work with every compilers to come.
> Of course it is better to fix the root cause.

Agreed !

Would it be possible to have a list of the PMDs which are known to be 
currently being tested (for example e810, i40e for Intel) ? (and then 
the list of PMDs which are "under lighter monitoring")

	Best regards

	Thierry

> If we cannot fix it in time, we can add this workaround in the release notes.
> But please, let's not apply it in the codebase.
> 
> 

-- 
Thierry Herbelot