memory_compare should be more strict about which devices it chooses to consider 'RAM' chips

Bug #960087 reported by Brendan Donegan
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Checkbox
Fix Released
Medium
Brendan Donegan

Bug Description

The memory_compare script was failing on one system like so:

Meminfo total: 3990004 kB
DMI total: 8192000 kB
Accuracy: 48.00
Memory totals not close enough

Trying to figure out why 4GB of memory was missing I looked at the dmidecode output and found:

Handle 0x0042, DMI type 17, 28 bytes
Memory Device
        Array Handle: 0x003C
        Error Information Handle: Not Provided
        Total Width: 2 bits
        Data Width: 2 bits
        Size: 4096 kB
        Form Factor: Chip
        Set: None
        Locator: SYSTEM ROM
        Bank Locator: Not Specified
        Type: Flash
        Type Detail: Non-Volatile
        Speed: Unknown
        Manufacturer: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified

First of all, this is not even a RAM chip (it says 'SYSTEM ROM' right there). Second of all, the size is only 4096 *Kb*. Two things need to be done to make the memory_compare script more robust

1.) Check the unit value of the size
2.) Make sure the memory unit in question is RAM and not something else

Related branches

Revision history for this message
Jeff Lane  (bladernr) wrote :

1.) Check the unit value of the size

Until seeing this, I would have said that's unnecessary, but apparently, it may well be. what machine is giving you this? I've never seen a ROM chip appear as "Memory" according to DMI. That type, AFAIK, is reserved for RAM information, and a ROM chip should never appear there. I'm looking a bit more into that though, because i'm intrigued.

2.) Make sure the memory unit in question is RAM and not something else

Same as above, before this, I would laugh at the notion, but just goes to show, you never know what wacky things are going to happen.

Changed in checkbox:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

Well, the snippet above is directly from 'dmidecode -t 17' so you better believe it! I'm going to up the priority of this as well because I can't be dealing with constantly checking up on these sorts of false positives.

Changed in checkbox:
importance: Low → Medium
Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

The first part might not be too necessary as I'm not even sure they manufacture < 1GB RAM sticks these days

Revision history for this message
Jeff Lane  (bladernr) wrote :

I believe it! :) Actually after looking through the DMI spec, there's a LOT of stuff that can be thrown into Type 17, and that includes ROM and EEPROMs :(

I'd say it would be sufficient to just look for RAM, but here's what COULD appear in there:

01h Other
02h Unknown
03h DRAM
04h EDRAM
05h VRAM
06h SRAM
07h RAM
08h ROM
09h FLASH
0Ah EEPROM
0Bh FEPROM
0Ch EPROM
0Dh CDRAM
0Eh 3DRAM
0Fh SDRAM
10h SGRAM
11h RDRAM
12h DDR
13h DDR2
14h DDR2 FB-DIMM
15h-17h Reserved
18h DDR3
19h FBD2

It would be easy if we could just look for RAM, but unfortunately, I think we'd also have to look for DDR, DDR2 and DDR3, and maybe there's memory out there that would show up as Unknown...

I wonder if point 1 would be a more reliable thing... I think we can assume that you aren't going to find ROMs showing up more than 1MB. Those should stay in the < 1MB range, right, and more likely in the 4 to 32K range, right? Maybe just looking at size and the descriptor following would be better. I haven't seen memory, that I remember at least, that is listed in dmi as XX GB, it's always MB.

This is one of the sticks on my Alienware... note that it's 2GB but displayed as 2048MB. Also note that it is listed as Type: DDR3, not RAM :(

Handle 0x001A, DMI type 17, 28 bytes
Memory Device
 Array Handle: 0x0019
 Error Information Handle: No Error
 Total Width: 64 bits
 Data Width: 64 bits
 Size: 2048 MB
 Form Factor: SODIMM
 Set: 1
 Locator: M1
 Bank Locator: Bank 0
 Type: DDR3
 Type Detail: Synchronous
 Speed: 1333 MHz
 Manufacturer: 02FE
 Serial Number: DFD80ADC
 Asset Tag: 1001
 Part Number: EBJ21UE8BDS0-DJ-F
 Rank: Unknown

Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

I was going to use the Form Factor field actually - should be limited to 'SODIMM', 'DIMM' and 'SIMM' shouldn't it? Though I've only seen 'DIMM' and 'SODIMM' so far

Revision history for this message
Jeff Lane  (bladernr) wrote :

FB-DIMM is possible on servers... Heh... does anyone even still make SIMMs? That could be more reliable. There's still the chance for "Unknown" or "Other" but that's probably a low enough chance that it can be ignored. I'm not even that sure about FB-DIMMs to be honest... just that they're more of a possibility than "Unknown" or "Other".

Jeff Lane  (bladernr)
Changed in checkbox:
milestone: none → 0.13.x
tags: added: cert-sru-issue
Changed in checkbox:
status: Confirmed → In Progress
assignee: nobody → Brendan Donegan (brendan-donegan)
Revision history for this message
Brendan Donegan (brendan-donegan) wrote :

Seems to be reliable to assume that 'IMM' (in-line memory module) will be in the Form Factor field - I haven't seen evidence otherwise. That's what the attached branch looks at, let's hope it makes things better.

Changed in checkbox:
status: In Progress → Fix Committed
Changed in checkbox:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.