Your message dated Tue, 14 Sep 2010 23:49:29 +0200
with message-id <[email protected]>
and subject line Re: Bug#596865: dphys-swapfile: Memory calculation is wrong
for AMD 64bit systems
has caused the Debian Bug report #596865,
regarding dphys-swapfile: Memory calculation is wrong for AMD 64bit systems
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
596865: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596865
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dphys-swapfile
Version: 20061020-1
Severity: normal
As noted in bug 564466 on AMD 64 systems the /proc/kcore size is reported as
excessively large
due to the handling of vmalloc on that platform.
The kernel documentation was in error, claiming that kcore would be size of
memory with a small adjustment
when it is (now at least) more complex than that.
If we must rely on /proc interface then the second field of the first line of
/proc/meminfo contains
size of RAM. As per changes below, however I'm not sure if relying on /proc is
a good idea, I haven't checked kernel source to see if it is always the first
line, or if the unit field is hard coded. So probably wise to make a more
robust case than this.
I'm still trying to understand fully how AMD64 handles memory usage so probably
wise to run this past someone who does understand the topic better.
52c52
< KCORESIZE="`ls -l /proc/kcore | awk '{ print $5 }'`"
---
> # KCORESIZE="`ls -l /proc/kcore | awk '{ print $5 }'`"
54c54,55
< MEMSIZE="`expr "${KCORESIZE}" / 1048576 + 1`"
---
> KCORESIZE="`head -1 /proc/meminfo | awk '{ print $2 }'`"
> MEMSIZE="`expr "${KCORESIZE}" / 1024 + 1`"
--- End Message ---
--- Begin Message ---
Version: 20061020-3
Hi Simon,
On Tue, Sep 14, 2010 at 06:06:23PM +0100, Simon Waters wrote:
>> While the subject of your bug report suggests that you are reporting
>> the same issue as #564466, the fact that you seem to know about that
>> bug makes me wonder what kind of problem you really try to report, as
>> the remainder of your report just seems to document some details of
>> the already fixed issue of #564466 (http://bugs.debian.org/564466):
>
> I took it from description that the fix was just to put the 2GB limit
> back in place rather than fix the calculation.
Ah, this was done, too. The calculation was fixed, and the limit was
added again as additional safe-guard.
>> In 20061020-3 this is solved as follows:
>
>> MEMTOTAL="`grep '^MemTotal:' /proc/meminfo | awk '{ print $2 }'`"
>> # make MBytes which rounded down will be about 10 too few, so add 10
>> MEMSIZE="`expr "${MEMTOTAL}" / 1024 + 10`"
>
> Oops - sorry to report one that is fixed.
No problem, thanks for your effort anyway. I mark this bug report as
fixed in that version, too, and close it herewith.
Kind regards, Axel
--
,''`. | Axel Beckert <[email protected]>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--- End Message ---
