Re: [BUG] atlantic: resume from S3 fails with -ENOMEM in aq_ring_alloc(), leaves unusable netdev

[Jonas Gorski <jonas.gorski@gmail.com>]

Hi,

On 26/09/2026 21:49, Stephan Hauser wrote:
> Hi,
> 
> The atlantic driver intermittently fails to resume an AQC107 from suspend-to-RAM.
> aq_nic_init() reallocates its per-ring software buffer arrays from the PM resume
> path, where the PM core has restricted allocations to GFP_NOIO. With the default
> ring sizes these are order-5 and order-6 requests (128 KiB and 256 KiB), which
> cannot reliably be satisfied in a context that can neither reclaim, compact, nor
> dip into reserves.
> 
> Resume then returns -ENOMEM and the device is left half-initialised: the netdev
> still exists and is still marked IFF_UP, but has no rings and no vectors. It
> passes no traffic, DHCP never completes, and bringing the link down hangs.
> 
> I have 3 occurrences in 60 suspend/resume cycles (5%) over 5.5 weeks of journal,
> across kernels 7.1.4 and 7.2.2. What makes this worth reporting rather than
> filing under "memory was tight": the three failures have three *different*
> proximate causes in the allocator, detailed below. The allocation is fragile in
> several independent ways at once, which is why no amount of tuning fixes it.
> 
> Two distinct problems:
> 
>   1. A >PAGE_ALLOC_COSTLY_ORDER kmalloc() on the resume path, for memory that
>      never needs to be physically contiguous.
>   2. atl_resume_common() does not unwind when aq_nic_init() fails, so an
>      allocation failure is converted into a wedged interface.
> 
> 
> Disclosure
> ----------
> 
> The analysis in this report, and the text of the report itself, were produced
> with the assistance of Claude (Anthropic). Please weigh it accordingly.
> 
> What is directly evidenced: the hardware is real and in front of me, and every
> log line, zone dump and free-page histogram quoted below is verbatim from my
> journal. The failure counts come from scanning all boots in that journal.
> 
> What is inference rather than measurement, and where I would welcome a second
> opinion:
> 
>   - The 64-byte element size is derived from the two reported allocation
>     orders, not read out of the source.
>   - The TX-before-RX ordering in aq_vec_ring_alloc(), and the claim that
>     aq_nic_init() aborts on first failure, are inferred from the backtrace and
>     from only ever seeing a single warning per event.
>   - The ZONE_DMA32 lowmem_reserve arithmetic in case 3 is hand-computed from
>     the zone dump.
>   - The aq_nic_stop() attribution for the link-down hang is a guess; I say so
>     again where it appears.
>   - The suggested fixes were not compiled or tested, and were written without
>     the source tree to hand. Treat them as a direction, not a patch.
> 
> I have read the whole thing and stand behind reporting it, but I have not
> personally verified the driver internals against the code.
> 
> 
> System
> ------
> 
>   Kernel:    7.1.4 and 7.2.2 (also running 7.2.7), x86_64, PREEMPT(lazy)
>   Hardware:  Micro-Star International Co., Ltd. MEG X570 UNIFY (MS-7C35),
>              BIOS A.80 01/22/2021
>   NIC:       Aquantia AQC107 NBase-T/IEEE 802.3an [Atlantic 10G] (rev 02)
>              PCI 0000:24:00.0, [1d6a:07b1], subsystem [1d6a:0001]
>   Driver:    atlantic, firmware-version 3.1.100
>   Rings:     rx 2048 / tx 4096 (driver defaults; maximum 8184), 8 vectors
>   Memory:    64 GB, no swap configured
This is also happening to me, at least since 6.18 (where I first noticed it)
with an AQC113 [1d6a:04c0 / sub 1043:889a]. Currently running 7.2(.4).

Looking at older boot logs I see the exact same allocation failures, then
(later) hangs.

For me the hang often happens at suspend. I don't use the card as an uplink
port, so most of the time it has no connection, and the issue only shows up
when trying to tear down the interface on suspend after the allocation
failed at the previous resume.

Best regards,
Jonas