Reproducible INITIAL_READ single-bit errors on RTX 3090 at recurring address suffix, while CUDA controls pass #89
Replies: 4 comments 1 reply
|
This looks like a hardware error. memtest_vulkan is not known to produce false-positives (except obvious cases when it crashes immediately due to some shader implementation errors). Reporting errors on same adderss ending is a sign of a hardware error on a single address within a specific VRAM IC. Most prpobably its only single bit. To analyze this better - make a similar table with buckets for TogglCnt and SingleIdx buckets based on original log. TogglCnt is excpected to have all values in bucket 0x1, SingleIdx - in a single bucket. And please attach the full log. For most GPU applications such 1-bit-from-20GB rare hardware error can be just ignored. Say "Games crashing once a year". For AIs inference - that would be "0.0001% more chance that it would be wrong". Tasks likes physics simulation maybe the kind of tasks when this is not acceptable/ The values-related table is not so useful (it becomes useful with another kind of hardware errors). |
|
@Olari-A Most other memtests use more predictable address access patterns, memtest_vulan is more intensive in this sense, so it found more rare errors |
|
Thanks — that explains why the other tests missed it. I had Codex go back through the original capture and aggregate every complete error record from the corrected 20 GiB stock-clock run. There are 13 in total:
So all 13 reports are single-bit errors, and all point to bit index 3. The complete original capture is included below. The normalized copy was byte-for-byte identical. Does that narrow it down to a particular VRAM chip, or only confirm that the same data bit is failing? Complete original memtest_vulkan log |
|
Same lower address bits + same Single bit idx confirms thats specific bit in a signble VRAM IC is failing.
No. Relating address data to specific chip is technically too coplex for NVIDIA GPUs, so that can be treated as "nearly impossible". And from memtest_vulkan output it is really impossible to get physical VRAM address (in theory it would require adding a lot of runtime inspection I thought about but failed to invent how to implement) |
Uh oh!
There was an error while loading. Please reload this page.
Reproducible
INITIAL_READsingle-bit errors on RTX 3090 at recurring address suffix, while CUDA controls passSummary
memtest_vulkan v0.5.0 repeatedly reports
INITIAL_READerrors with exactly 20 GiB allocated on an NVIDIA GeForce RTX 3090. The failures reproduce at stock clocks, with memory locked one supported step lower, and with both the lower memory clock and a reduced graphics clock. Across all runs, the reported address ranges have different prefixes but the sameB8D8..B8DBsuffix, and the bit-level table consistently reports one single-bit index and one toggle.In contrast, a comprehensive 20 GiB CUDA memory pass (tests 0–8 and 10) completed with zero errors, and a 600-second Tensor-Core gpu-burn run using about 20.2 GiB completed with zero calculation errors. No NVIDIA Xid was recorded in any of these runs.
Environment
10de:2204, Ampere94.02.26.88.3C595.84(open kernel module)13.21.4.3411.4.3297.0.0-29-genericv0.5.0 provenance
0e058c28b9d0d6eb04f5edeebce73e8106f88c4ea307d46e98c715da61117d52eb9d518170e43700e97abc5df4f14d3bfc31c79366ea0c311fd5581192664760Vulkan reproductions
All runs selected
NVIDIA GeForce RTX 3090,DevId=0x2204, allocated exactly21474836480bytes (20.0GBas printed by the tool), used the NVIDIA ICD, and had no Xid.0x18B72B8D8..=0x18B72B8DB, value0x1179E5AF0x18942B8D8..=0x18942B8DB, values0x40EF713A,0x3B10712B0x18711B8D8..=0x18711B8DB, value0xB430049B0x1ABC9B8D8..=0x1ABC9B8DBThe repeated low address suffix is therefore
B8D8(range endingB8DB) despite the differing high prefixes. Lowering the memory clock by 250 MHz and separately limiting graphics to 1200 MHz did not eliminate the report. Every record is modeINITIAL_READ, reports0x1error out of0x34000000(0.00000011%), hasFFFFFFFF-like count:0, and shows oneSinglIdxentry plusTogglCntof one.The final run exposed an output-buffering complication: multiple complete records accumulated before they became visible to the external supervisor. SIGINT was sent immediately when the buffered batch appeared.
Complete final-run error table
All rows use address range
0x1ABC9B8D8..=0x1ABC9B8DBand modeINITIAL_READ.values range1sInValubucket0x500F09FA..=0x500F09FA0xE0x207E2C0E..=0x207E2C0E0xD0x40B4B80A..=0x40B4B80A0xB0xC5B2141A..=0xC5B2141A0xD0xB09D2E0B..=0xB09D2E0B0xF0x07450C3B..=0x07450C3B0xD0x66D0120B..=0x66D0120B0xC0x13E385AA..=0x13E385AA0xF0x232E7C2A..=0x232E7C2A0xF0x7475012A..=0x7475012A0xD0x519E12AA..=0x519E12AA0xE0x32E5833A..=0x32E5833A0xF0x3658B6AB..=0x3658B6AB0x11The tool does not label separate expected and actual values in these records; it emits only
values range, so I have preserved that field without reinterpreting it.CUDA comparison
e94e1ee54e0689c9f154a8a08202554452552ec6sm_86gpu-burn also completed a 600-second Tensor-Core run at 90% available memory (20714 MB used by the test) with exit code 0,
GPU 0: OK, zero calculation errors, and zero Xid. Peak temperature was 79 C.Question
Do these results look like a real hardware error, or could the repeated
B8D8suffix be caused by the Vulkan shader or NVIDIA driver? The same card passes the complete CUDA memory test and gpu-burn, so what would you test next to separate those possibilities? I can run a modified build if that would help.All reactions