Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1213688

Summary: [RFE] lshw should report physical memory size on POWER systems which expose it in device tree
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: inventoryAssignee: Dan Callaghan <dcallagh>
Status: CLOSED CURRENTRELEASE QA Contact: Dan Callaghan <dcallagh>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: aigao, dcallagh, ebaak, mjia
Target Milestone: 21.0Keywords: FutureFeature, Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-26 06:17:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 541294    

Description Dan Callaghan 2015-04-21 04:50:07 UTC
On POWER the lshw version of beaker-system-scan is reporting the identical amount of memory as the smolt version did -- which appears to be just the free memory reported by the kernel, not the amount of memory physically installed.

For example 15790 MB for a P8 LPAR that (presumably) has 16GB allocated.

Comment 4 Dan Callaghan 2015-06-16 06:08:18 UTC
The bug is that it's 15790MB but it should be 16384MB. (Actually I'm just guessing about that, but I doubt that the LPAR was defined as having 15790MB of memory, it was more likely 16GB = 16384MB.)

Comment 5 Dan Callaghan 2015-06-16 06:11:33 UTC
Anyway this is really just a low-priority RFE since the current data produced by lshw is no worse than smolt.

The task here is to figure out how much actual "physical" memory is allocated to the LPAR (16384MB? something else?) and then figure out what in the kernel is reserving it and see if we can make lshw account for that, so that the amount of memory reported more closely matches how much is actually allocated.

This is essentially the same bug or closely related to bug 1223961.

Comment 6 Dan Callaghan 2015-06-19 02:18:55 UTC
There are some IBM-specific properties under memory-controller in the device tree which we can use to grab DIMM info.

Comment 7 Dan Callaghan 2015-07-13 06:56:31 UTC
We can get most of the way there by looking at the hotplug info in /sys/devices/system/memory:

http://gerrit.beaker-project.org/4290

In particular, that gives us better info on S/390 guests where we have no other means of checking memory size.

We can also grab DIMM info from the /memory-controller node in device tree although that seems to only exist on the JS20.

http://gerrit.beaker-project.org/4291

Comment 9 Dan Callaghan 2015-08-26 06:17:47 UTC
Beaker 21.0 has been released.