Bug 55282
Summary: | /proc/meminfo reports incorrectly | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Jim Wright <jwright> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | ppokorny |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-10-29 16:16:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jim Wright
2001-10-29 06:39:26 UTC
we know the fix is trivial in theory, however some userland applications like top use this field blindly and often use 32 bit values ;( That's odd, because TOP is actually displaying the *correct* memory size of 6GB. I wonder if the problem isn't the limit of 8 digits on the field width. If that limit was increased to 10 or removed, the correct value might display? I may try testing that. The (unsigned long long) cast should eliminate the 32 bit limit on the "size" of memory. The B macro would suggest that "totalram" is actually in units of PAGES (2^PAGE_SHIFT bytes). With 4k pages, totalram should max out at 16 Terabytes of RAM. Nevermind. Already fixed in the 2.4.9-7 errata kernel. |