[Bug 1308760] Re: lshw doesn't deal w/ device-tree endianness

Chris J Arges 1308760 at bugs.launchpad.net
Mon Oct 20 19:24:48 UTC 2014


Hello dann, or anyone else affected,

Accepted lshw into trusty-proposed. The package will build now and be
available at http://launchpad.net/ubuntu/+source/lshw/02.16-2ubuntu1.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!

** Changed in: lshw (Ubuntu Trusty)
       Status: New => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to lshw in Ubuntu.
https://bugs.launchpad.net/bugs/1308760

Title:
  lshw doesn't deal w/ device-tree endianness

Status in lshw - Hardware Lister:
  Unknown
Status in “lshw” package in Ubuntu:
  Fix Released
Status in “lshw” source package in Trusty:
  Fix Committed
Status in “lshw” package in Debian:
  New

Bug description:
  [Impact]
  lshw parses /proc/device-tree to read system properties on device-tree-based platforms. But, on little endian systems like armhf and arm64, it doesn't properly convert the data, which should always be big endian. This can cause incorrect data to be reported. For instance, a 1GHz cpu might be reported as 13MHz because lshw reads a frequency of 0xca9a3b (13MHz) instead of 0x3b9aca00 (1GHz).
  [Test Case]
  Run lshw on an HP m800 cartridge and examine the cpu frequency.
  [Regression Potential]
  We're changing parsing code, so there's a possibility that we break that code on systems that currently work in trusty. I tested on a big endian system to make sure it didn't break things there (powerpc), and found the output to be byte-for-byte identical before and after the patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lshw/+bug/1308760/+subscriptions



More information about the foundations-bugs mailing list