ONTAP: Integer-Divide Panic After About 994 Days of Uptime

Scope and symptoms in the source

The source lists ONTAP 9.4 and later on AFF A800, AFF A700, AFF A700s, FAS9000 and FAS8700. These are its historical scope examples, not a claim that every patch or every later system is affected.

Panic String: integer divide fault: num 18 code 0 cs:rip 0x20:0xffffffff9a995842 rflags 0x10246 in SK process callout on release 9.4P3 (C)

Another source example:

PANIC : integer divide fault: num 18 code 0 cs:rip 0x20:0xffffffffa09d74b9 rflags 0x10246
version: 9.5P3: Tue Apr 16 18:46:36 EDT 2019
conf : x86_64.optimize
cpuid = 15
KDB: stack backtrace:
vpanic() at vpanic+0x6d9/frame 0xfffff700000f7ef0
panic() at panic+0x43/frame 0xfffff700000f7f50
amd64_syscall() at amd64_syscall+0x13ce/frame 0xfffff700000f7fb0
trap() at trap+0x71d/frame 0xfffff700000f8170
calltrap() at calltrap+0x8/frame 0xfffff700000f8170
--- trap 0x12, rip = 0xffffffffa09d74b9, rsp = 0xfffff700000f8240, rbp = 0xfffff700000f8280 ---
lu_thread_update_all_thread_stats() at lu_thread_update_all_thread_stats+0x1c9/frame 0xfffff700000f8280
callout_main() at callout_main+0x96/frame 0xfffff700000f82e0
fork_exit() at fork_exit+0x12e/frame 0xfffff700000f8330
fork_trampoline_sk() at fork_trampoline_sk+0xe/frame 0xfffff700000f8330
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 994d4h59m49s

Cause and bug identification

The source describes a 32-bit counter advancing every 20 milliseconds and an integer-divide fault after about 994 days. Its links use CONTAP-269495 (one label is misspelled CONVA-269495).

The current vendor records distinguish the original long-uptime issue, CONTAP-58732, from CONTAP-269495, which describes a later recurrence associated with code changes in ONTAP 9.7 and later despite an earlier fix. Match the actual panic/release to the appropriate record.

Resolution and maintenance

Upgrade to a vendor-confirmed fixed release for the affected version and platform. The stored note suggests a planned takeover/giveback or reboot if upgrade is not yet possible, before 995 days. Because its own panic example is at 994d4h59m49s, do not treat day 995 as a safe deadline: arrange approved maintenance with support well before the affected threshold.

Inspect uptime

::> event log show -messagename kern.uptime.filer
::> system node show