scripts/memory_compare gives bad results on systems with more than one memory device
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Checkbox |
Fix Released
|
Undecided
|
Daniel Manrique |
Bug Description
This bug has been around since a fix for bug 1023220 got merged, on rev 1497 from July 11th. Previously, the script would iterate over all the memory devices in the system (i.e. each memory module and so on), and add each size to an accumulator. On an apparent oversight, rev 1497 turns the addition into a direct assignment to the accumulator variable. As a consequence, if a system has more than one memory module, the DMI memory size will erroneously be reported as the size of the *last* processed module.
On my laptop which has two 2-GB modules, running memory_compare returns this:
PASS: Difference is -1776906240 bytes (-82.74%) and less than the 10% threshold.
/proc/meminfo reports: 3924389888 kB
dmi reports: 2147483648 kB
While the test passes, it does so for the wrong reasons.
Once I apply a fix (see the soon-to-be-attached merge request), the result is this instead:
PASS: Difference is 370577408 bytes (8.63%) and less than the 10% threshold.
/proc/meminfo reports: 3924389888 kB
dmi reports: 4294967296 kB
The dmi reported size is correct (4 GB).
This bug explains all those weird memory_compare test results with wildly varying values and negative differences.
Related branches
- Zygmunt Krynicki (community): Approve
-
Diff: 24 lines (+3/-1)2 files modifieddebian/changelog (+2/-0)
scripts/memory_compare (+1/-1)
Changed in checkbox: | |
status: | New → In Progress |
assignee: | nobody → Daniel Manrique (roadmr) |
Changed in checkbox: | |
status: | In Progress → Fix Committed |
Changed in checkbox: | |
status: | Fix Committed → Fix Released |