Wrong RAM memory size

[Dimitrios Ntoulas]

[Impact]
lshw is not using smbios to obtain hardware information. This is causing lshw to report incorrect information to user. For example I have a machine which has one physical CPU with 8 cores and 32G of RAM. lshw is reporting the machine has only one physical CPU with 0 cores and 32162MiB of RAM.

[Test case]
Run lshw and compare its reported values with what you know the physical system has. To help simplify testing I use this script http://paste.ubuntu.com/16900290/ which can be run with the command `sudo lshw -xml | ./parse_lshw`

[Regression Potential]
smbios-noscan.patch was introduced to prevent ARM systems from locking up when lshw is being run. We are replacing this patch with cherry picked commit(8237f8ebb92ebf684c0e6715cc6c28a3b2bb93b8) from https://ezix.org/src/pkg/lshw which was released with lshw-B.02.18. Potentially this could bring back https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740034 however upstream considers it fixed with the previously mentioned cherry pick.

[Andreas Hasenack (ahasenack)]

1542260 kB is 1506 Mb (1542260 / 024 = 1506.11328)

So free and /proc/meminfo agree. I don't know where you grabbed the 2GiB figure from. Maybe the rest is being used by an onboard video card?

Anyway, not a landscape-client problem, because we grab that information from /proc/meminfo.

[Dimitrios Ntoulas (ntoulasd)]

Something is grabbed wrong from client, I suppose.

[Dimitrios Ntoulas (ntoulasd)]

Also vga has 128MB ram

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon Mobility X700 (PCIE) (prog-if 00 [VGA controller])
 Subsystem: Toshiba America Info Systems Device ff01
 Flags: bus master, fast devsel, latency 0, IRQ 43
 Memory at c8000000 (32-bit, prefetchable) [size=128M]
 I/O ports at 3000 [size=256]
 Memory at b8100000 (32-bit, non-prefetchable) [size=64K]
 [virtual] Expansion ROM at b8120000 [disabled] [size=128K]
 Capabilities: <access denied>
 Kernel driver in use: radeon
 Kernel modules: radeon

I bought laptop with 512MB and I upgraded myself adding 1GB. So its definitely 1.5GB !

[Andreas Hasenack (ahasenack)]

Can you please run sudo lshw -xml > hardware.xml and attach that to this bug? I can mark it as private if you prefer

[Dimitrios Ntoulas (ntoulasd)]

I attach the requested file

[Andreas Hasenack (ahasenack)]

Hm, looks like lshw is giving us wrong information:
<node id="memory" claimed="true" class="memory" handle="DMI:000F">
<description>System Memory</description>
<physid>f</physid>
<slot>System board or motherboard</slot>
<size units="bytes">2147483648</size>
<capacity units="bytes">3221225472</capacity>

That tells us you have 2GiB (2147483648)

Further down, it says you have bank0 with 512Mb and bank1 with 1.5Gb:
<node id="bank:0" claimed="true" class="memory" handle="DMI:0010">
<description>SODIMM DDR Synchronous</description>
<physid>0</physid>
<slot>M1</slot>
<size units="bytes">536870912</size>
<width units="bits">32</width>
</node>
<node id="bank:1" claimed="true" class="memory" handle="DMI:0011">
<description>SODIMM DDR Synchronous</description>
<physid>1</physid>
<slot>M2</slot>
<size units="bytes">1610612736</size>
<width units="bits">32</width>
</node>

Can you run it without -xml and check the memory information it reports about your system? It's more human readable that way.

[Andreas Hasenack (ahasenack)]

It's a bug in lshw, it clearly says that you have 2GiB installed ("size: 2GiB"). One bank with 1536MiB and the other with 512MiB even.

[Dimitrios Ntoulas (ntoulasd)]

I fill a report for lshw, thanks

[Andreas Hasenack (ahasenack)]

I retasked this bug against lshw, I think it's better because it contains the history, discussion and debugging

[Lee Trager (ltrager)]

We're seeing this in MAAS as well. If you commission a machine with 2GB of RAM using Trusty lshw reports 2GB if you commission with Xenial you get 2000 Mb. This causes the MAAS UI to report 1GB of RAM because when we convert 2000 Mb to GB we get 1.9 which is shown as 1GB as we convert to an integer.

https://bugs.launchpad.net/maas/+bug/1539739

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Lee Trager (ltrager)]

B.02.18 was recently released which fixes this problem and displays the correct amount of physical RAM.

[Lee Trager (ltrager)]

I was mistaken that this is fixed in B.02.18. What is actually causing this is the smbios-noscan.patch.

[Lee Trager (ltrager)]

smbios-noscan.patch was introduced upstream in this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740034

[dann frazier (dannf)]

I've tested the proposed fix on two different ARM systems (APM Mustang and Cavium ThunderX). The output is identical, and there is no system crash. strace shows that no attempt is made to open /dev/mem, which was the original issue in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740034.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lshw - 02.17-1.1ubuntu4

---------------
lshw (02.17-1.1ubuntu4) yakkety; urgency=medium

  * Use upstream solution for avoiding /dev/mem accesses on !x86,
    fixing a memory size detection regression (LP: #1039701):
     - Drop: smbios-noscan.patch
     - Add: use-sysfs-for-DMI-info-when-available-696-666-664.patch

 -- dann frazier <email address hidden> Wed, 01 Jun 2016 15:01:29 -0600

[Amr Ibrahim (amribrahim1987)]

Is this related Bug #1477729?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[dann frazier (dannf)]

On Wed, Jun 1, 2016 at 6:49 PM, Amr Ibrahim <email address hidden> wrote:
> Is this related Bug #1477729?

Possibly; does the package in yakkety resolve it?

[Brian Murray (brian-murray)]

Hello Dimitrios, or anyone else affected,

Accepted lshw into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/lshw/02.17-1.1ubuntu3.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Lee Trager (ltrager)]

Verified that 02.17-1.1ubuntu3.1 fixes the issue and the proper amount of RAM is shown.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lshw - 02.17-1.1ubuntu3.1

---------------
lshw (02.17-1.1ubuntu3.1) xenial; urgency=medium

  * Use upstream solution for avoiding /dev/mem accesses on !x86,
    fixing a memory size detection regression (LP: #1039701):
     - Drop: smbios-noscan.patch
     - Add: use-sysfs-for-DMI-info-when-available-696-666-664.patch

 -- dann frazier <email address hidden> Wed, 01 Jun 2016 15:46:02 -0600

[Adam Conrad (adconrad)]

The verification of the Stable Release Update for lshw has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Amr Ibrahim (amribrahim1987)]

This bug was reported in 2012. I think trusty is also affected.

I can't install the package from xenial or yakkety on trusty because of a dependency issue.

[Dimitrios Ntoulas (ntoulasd)]

I cannot verify the bug. The laptop is out of order.

[dann frazier (dannf)]

On Fri, Jun 10, 2016 at 8:05 AM, Amr Ibrahim <email address hidden> wrote:
> This bug was reported in 2012. I think trusty is also affected.
>
> I can't install the package from xenial or yakkety on trusty because of
> a dependency issue.

This fix is now in xenial-updates, so you should be able to install it.

  -dann

[dann frazier (dannf)]

@Amr, sorry - my brain replaced "trusty" with "xenial" when I read your reply. I've pushed a straight backport of the yakkety package to trusty to ppa:dannf/test if you want to test that.