A memory event in the event log names a label the board vendor chose, not a module. dmidecode -t 17 maps that label to a physical slot with a part number and a serial number you can read off the stick in your hand.
The event log gives you a label, not a stick. DIMM_B2 is a string the board vendor burned into the BMC. dmidecode -t 17 is where that label meets hardware: find the Memory Device whose Locator matches, then read its Serial Number and match it against the module in your hand.
Two machines appear below, both named every time so you never mistake this for one incident. The log came from the Camp's BMC emulator on its memory-fault scenario. Every dmidecode block came from a real 24-socket bare-metal server on RHEL 9.5, except the last, which is an EC2 instance shown as the contrast. The EDAC and rasdaemon lines are quoted from documentation.
The log tells you which sensor complained and how often. That is all it knows. Here is the failure story, six records, one slot:
1 07/12/2026 03:11:04 | System_Power | Informational | System boot completed
2 07/12/2026 09:47:19 | DIMM_B2 | Warning | Correctable memory error rate exceeded for DIMM_B2
3 07/12/2026 14:02:51 | DIMM_B2 | Warning | Correctable memory error rate exceeded for DIMM_B2
4 07/13/2026 01:36:08 | DIMM_B2 | Warning | Persistent correctable memory errors detected on DIMM_B2
5 07/13/2026 01:36:12 | DIMM_B2 | Critical | Multi-bit memory errors detected on a memory device at location DIMM_B2
6 07/13/2026 01:36:14 | DIMM_B2 | Critical | Memory device at location DIMM_B2 is criticalBe clear about where that came from. It is the Camp's BMC emulator, a teaching device that plays a Dell-style controller, and it was read through the BMC's own shell with getsel, not with ipmitool sel list against physical hardware. It has to be read that way for two reasons worth knowing: the scenario log is served only by that shell, and the emulator's IPMI side defines no memory sensors, so nothing exists for a sensor lookup to name. On the day of the capture the IPMI path did not even open.
Error: Unable to establish IPMI v2 / RMCP+ sessionOn real hardware, ipmitool sel list gives the raw records, ipmitool sel elist resolves sensor numbers to names, and ipmitool sel get <id> prints one record in full. elist is slower for a reason: it reads the Sensor Data Record repository as well as the log, so it can print the ID string the vendor stored there. That string is where a name like DIMM_B2 comes from. It is not in the event.
The arc matters more than any one line: two rate warnings hours apart, a persistent-error warning, then a multi-bit critical four seconds later. Correctable errors are a rate. Uncorrectable errors are an event.
Sixteen bytes, and only two of them can carry a module identity. Layout is IPMI v2.0 Table 32-1; field names are the ones ipmitool declares in include/ipmitool/ipmi_sel.h.
| Bytes | Field | What it tells you |
|---|---|---|
| 1-2 | Record ID | The 6 in the list above. The BMC assigns it. |
| 3 | Record Type | 02h is a standard event, C0h and above are OEM. |
| 4-7 | Timestamp | Seconds since the epoch. Logged before the clock is set, it renders as 1970. |
| 8-9 | Generator ID | Who reported it. 0x0020 is the BMC itself. |
| 10 | EvM Rev | Format revision. Constant, ignore it. |
| 11 | Sensor Type | 0Ch is Memory. This byte makes it a memory event. |
| 12 | Sensor Number | An index into the SDR, the hook elist uses to print a name. |
| 13 | Event Dir / Type | Bit 7 is assertion or deassertion. 6Fh is sensor specific. |
| 14 | Event Data 1 | Low nibble selects which memory event. Top bits declare what data 2 and 3 hold. |
| 15-16 | Event Data 2, 3 | Where a DIMM identity rides, when the BMC puts one there. |
Sensor type 0Ch is Memory in the IPMI sensor type table, and that is the honest whole of the standard. What sits in bytes 15 and 16 is vendor specific, which is why ipmitool carries per-vendor decoders in ipmi_sel.c and prints a DIMM string only for manufacturers it recognises. Everywhere else the location stays hex. The record carries a number, the SDR turns it into whatever a vendor typed, and you hold a label.
Type 16 answers two questions at once: how many sockets exist, and whether this machine does ECC at all.
professorlinux@L:~$ sudo dmidecode -t 16
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x1000, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 3 TB
Error Information Handle: Not Provided
Number Of Devices: 24Error Correction Type: Multi-bit ECC is the line that says a correctable memory error is even a concept here. Number Of Devices: 24 says 24 Type 17 structures follow, populated or not, so you can count sockets without opening the lid. Handle 0x1000 is what every module points back at.
Note Error Information Handle: Not Provided. That field can point at a structure holding error detail, and on servers it almost never does. The firmware will not hand you the failing slot.
Type 17 is one structure per socket, and this is the table that turns a label into a part number. The first module on the same host:
professorlinux@L:~$ sudo dmidecode -t 17
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x1100, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x1000
Total Width: 72 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Locator: A1
Bank Locator: Not Specified
Type: DDR4
Type Detail: Synchronous Registered (Buffered)
Speed: 2400 MT/s
Manufacturer: 01980632002C
Serial Number: ED18E63D
Part Number: KCPC7G-MIA
Rank: 2
Configured Memory Speed: 1866 MT/sTotal Width 72 bits against Data Width 64 bits is the ECC tell. Sixty-four bits carry data, the spare eight carry check bits. A module reporting 64 and 64 has no ECC, and nothing will ever log a correctable error for it because nothing is checking.
Locator is the field. SMBIOS defines it as the physically labelled socket or board position, meaning it is supposed to be the silkscreen beside the slot. Here it is a bare A1. On a Dell it might be DIMM_A1.
Bank Locator is not the slot, and this is the confusion worth ending. The specification assigns it the physically labelled bank, a grouping, not the socket. All 24 structures on this server read Bank Locator: Not Specified. Match the event label against Locator, and treat Bank Locator as a hint.
Serial Number is the ground truth. The manufacturer sets it and it is not meant to change. Labels get retyped between firmware revisions; serials do not. Part Number carries trailing spaces, as KCPC7G-MIA does above, so trim before comparing or a string match fails for no visible reason.
Speed is what the module can do and Configured Memory Speed is what it is running: these advertise 2400 MT/s and all run at 1866, a mixed population clocking down to its slowest member. Manufacturer prints an identifier rather than a name, so the part number is what you order from. Empty sockets appear too, carrying Size: No Module Installed.
They descend from the same silkscreen through two different firmware teams, so match on the slot coordinate and never on the whole string. Real strings from production hardware:
Dell PowerEdge R720, event text:
Correctable memory rate exceeded for DIMM A1
Source: Dell PowerEdge community report, https://www.dell.com/community/en/conversations/poweredge-hardware-general/dell-poweredge-r720-correctable-memory-rate-exceeded-for-dimm-a1/64f60f2acc5f623928952659
Supermicro X10SRH-cF, event text:
Failing DIMM: DIMM location. (Correctable memory component found) (DIMMC1)
Source: TrueNAS community thread, https://www.truenas.com/community/threads/failing-dimm-dimm-location-correctable-memory-component-found-dimmc1.85123/
HPE ProLiant DL380 Gen10, IML text:
Uncorrectable Memory Error Threshold Exceeded (Processor 2, DIMM 6). The DIMM is mapped out
Source: Wikimedia incident T261405, https://phabricator.wikimedia.org/T261405The Locator strings those same vendor families write into SMBIOS:
Dell R420 Locator: DIMM_A1 Bank Locator: Not Specified
Dell R930 Locator: A1 Bank Locator: Not Specified
HPE ProLiant Locator: PROC 1 DIMM 2A Bank Locator: Not Specified
Supermicro Locator: P1-DIMMA1 Bank Locator: P0_Node0_Channel0_Dimm0
Source: Dell PowerEdge community, https://www.dell.com/community/PowerEdge-Hardware-General/How-to-verify-the-installed-memory-type-ECC-or-no/td-p/5061163 ; HPE community, https://community.hpe.com/t5/BladeSystem-Server-Blades/How-to-detect-serial-number-of-DIMMs-for-RHEL-OS-Proliant/td-p/5300509 ; TrueNAS community, https://www.truenas.com/community/threads/finding-bad-memory-chip-location-on-supermicro-x10drl-i-mb.78078/The rule that survives all of them: strip DIMM, strip punctuation, fold case, compare what is left. DIMM_B2, DIMM.B2, DIMMB2 and B2 are one socket. HPE prose maps to PROC n DIMM m.
Take the label, normalise it, find the Locator, read the serial. On the bare-metal host the coordinate B2 resolves to exactly one structure:
Handle 0x110D, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x1000
Total Width: 72 bits
Data Width: 64 bits
Size: 32 GB
Locator: B2
Bank Locator: Not Specified
Type: DDR4
Manufacturer: 00CE063200CE
Serial Number: 235A3F29
Part Number: M393A4K40BB1-CRC | Step | Source | Value |
|---|---|---|
| Label in the log | BMC emulator, getsel | DIMM_B2 |
| Normalised coordinate | you, by hand | B2 |
| Matching structure | bare-metal host, dmidecode -t 17 | Handle 0x110D |
| Serial Number | same structure | 235A3F29 |
| Part Number | same structure | M393A4K40BB1-CRC |
| What you carry to the rack | both | 32 GB DDR4 module, socket B2 |
Plainly: the label came from the emulator, the table from a different real machine. That is the method, not one incident, and it works because both halves key on the same silkscreen coordinate. The emulator also publishes that coordinate through Redfish, which spells out what a bare B2 compresses:
"DeviceLocator": "DIMM.Socket.B2",
"MemoryLocation": {
"Channel": "B",
"MemoryController": 1,
"Slot": "2",
"Socket": 1
},The event log is the out-of-band witness: the BMC sees it on standby power and survives the operating system dying. EDAC is the in-band witness, counting per module while the machine runs. A diagnosis holding both is not arguable.
/sys/devices/system/edac/mc/mc0/ce_count
/sys/devices/system/edac/mc/mc0/dimm0/dimm_ce_count
/sys/devices/system/edac/mc/mc0/dimm0/dimm_label
/sys/devices/system/edac/mc/mc0/dimm0/dimm_location
Source: Linux kernel RAS admin guide, https://www.kernel.org/doc/html/v6.6/admin-guide/ras.htmlThose paths are quoted from the kernel documentation, not captured: the Camp's lab machines expose no ECC memory controller, so that directory is empty on them, and inventing counters would be worse than printing nothing.
The label problem repeats in-band, which is the tidy part. dimm_label is only as good as what userspace registered into it, and rasdaemon's control tool is what registers it:
--error-count
Shows the corrected and uncorrected error counts using sysfs.
--guess-labels
Print DMI labels, when bank locator is available in the DMI table.
Source: ras-mc-ctl(8), https://www.mankier.com/8/ras-mc-ctlRead --guess-labels closely. It derives labels from DMI when bank locator data is available: the same table, the same unreliable field, arbitrating the same question. Both planes ask SMBIOS in the end.
Nothing you can correlate, and the fields lie convincingly. Same dmidecode version, an EC2 instance:
root@storage-01:~# dmidecode -t 16
Handle 0x0008, DMI type 16, 23 bytes
Physical Memory Array
Error Correction Type: Unknown
Maximum Capacity: 4 GB
Number Of Devices: 1
root@storage-01:~# dmidecode -t 17
Handle 0x0009, DMI type 17, 34 bytes
Memory Device
Total Width: 72 bits
Data Width: 64 bits
Size: 4 GB
Locator: Not Specified
Bank Locator: Not Specified
Type: DDR4
Speed: 3200 MT/s
Manufacturer: Not Specified
Serial Number: Not Specified
Part Number: Not SpecifiedOne device, 4 GB, on an instance with far more memory than that. The array reports Error Correction Type: Unknown while the device still claims 72 against 64 bits. Locator, Manufacturer, Serial Number and Part Number are all Not Specified. The hypervisor wrote a table shaped like a memory subsystem because software expects one; there is no socket behind it. That is also your answer when Type 17 looks strangely empty on a machine somebody told you was physical.
Run dmidecode -t 17 again and read one field. The Serial Number under that Locator must have changed, and the old serial must appear nowhere else in the table. The second half is the check people skip, and it is the one that catches the classic failure: pulling the neighbouring module, reseating it in a different socket, and watching the same event return at three in the morning.
If the diagnosis is not certain, move the suspect module to another socket first. Errors that follow the module condemn the module. Errors that stay with the socket point at the socket, the board, or the memory controller.
Do not replace on a single correctable error. The log records a threshold crossing, and modern platforms can repair a failing row without a technician: Dell documents Post Package Repair running at the next reboot after messages of the "correctable memory error rate exceeded" family, with replacement only when retraining fails, the repair fails, or errors recur afterwards. Save the log before you clear it. ipmitool sel save writes the records out; ipmitool sel clear cannot be undone.
The Camp's bmc-memory-fault lab at /learn/bmc-ipmi runs this diagnosis against a live BMC emulator, shell and Redfish planes included.
| Command | What it answers | ||
|---|---|---|---|
ipmitool sel list | Every record, sensor shown as a number | ||
ipmitool sel elist | Same records, sensor names resolved from the SDR | ||
ipmitool sel get <id> | One record, all fields, raw event data bytes included | ||
ipmitool sel save <file> | Preserve the log before clearing it | ||
dmidecode -t 16 | Socket count, and whether the array does ECC | ||
dmidecode -t 17 | Every socket, with Locator, Serial Number, Part Number | ||
| `dmidecode -t 17 \ | grep -E 'Locator:\ | Serial Number:'` | Label-to-serial pairing in one screen |
ras-mc-ctl --error-count | Live per-module counters from EDAC sysfs |
Verified on dmidecode 3.6 reading SMBIOS 2.8 on Red Hat Enterprise Linux 9.5, kernel 5.14.0-503.40.1.el9_5.x86_64, a 24-socket bare-metal server; dmidecode 3.6 reading SMBIOS 2.7 on Amazon Linux 2023, kernel 6.1.163-186.299.amzn2023.x86_64; and the Camp's BMC emulator on the memory-fault scenario, read through its own shell. EDAC and rasdaemon lines come from the kernel documentation and the ras-mc-ctl man page.
The log says DIMM_B2 but dmidecode has no DIMM_B2. Which one is wrong? Neither. That machine's Locator is probably the bare coordinate B2, or P1-DIMMB2, or PROC 1 DIMM 2B. Strip the word DIMM and the punctuation, then match what is left.
Is Bank Locator the physical slot? No. The specification gives Locator the socket and Bank Locator a bank, which is a grouping. On all 24 sockets captured above it reads Not Specified. Match on Locator.
One correctable error appeared. Do I replace the DIMM? Not on one. It is a rate question, the controller is already correcting it, and modern platforms can repair the affected row at the next reboot. Replace on an uncorrectable error, a failed repair, or recurrence after a repair that reported success. Do not ignore it either: correctable errors are the best early warning of an uncorrectable one.
Can I identify the failing module without taking the server down? Yes. dmidecode reads a table the firmware left in memory, so it runs live and hands you the serial and part number to order against. Where EDAC is present, its counters localise the fault too. The outage is only for the swap.
More from the Field Manual, or work through the training tracks.