Hi all,
Recent Linux kernels have had a minor bug in that the amount of memory
reported in /proc/meminfo is incorrect. I'm trying to find a way to
determine whether the amount reported is correct or not.
I need some means of reliably knowing whether this value is accurate
or not. Does anyone h
On Wed, 2008-07-16 at 15:20 -0400, Paul Lussier wrote:
> Hi all,
>
> Recent Linux kernels have had a minor bug in that the amount of memory
> reported in /proc/meminfo is incorrect. I'm trying to find a way to
> determine whether the amount reported is correct or not.
>
> I need some means of r
> /proc/meminfo is incorrect. I'm trying to find a way to
> determine whether the amount reported is correct
Ick. You might be able to write (or find) something that'll use
DMI data to compute a total from everything currently marked as
being a Memory Device (type 17). The dmidecode tool can
On Wed, Jul 16, 2008 at 3:20 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
> Recent Linux kernels have had a minor bug in that the amount of memory
> reported in /proc/meminfo is incorrect.
Got details?
Depending on how the bug manifests, it might be enough to compare
with the output of free(1)
> it might be enough to compare with the output of free(1)
According to an strace I just ran on "free":
.
.
.
open("/proc/meminfo", O_RDONLY) = 3
lseek(3, 0, SEEK_SET) = 0
read(3, "MemTotal: 2010264 kB\nMemFre"..., 1023) = 728
.
On Wed, 2008-07-16 at 15:57 -0400, Ben Scott wrote:
> On Wed, Jul 16, 2008 at 3:20 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
> > Recent Linux kernels have had a minor bug in that the amount of memory
> > reported in /proc/meminfo is incorrect.
>
> Got details?
/me curious too
> Depending o
Stephen Ryan writes:
>
> On Wed, 2008-07-16 at 15:20 -0400, Paul Lussier wrote:
> > Hi all,
> >
> > Recent Linux kernels have had a minor bug in that the amount of memory
> > reported in /proc/meminfo is incorrect. I'm trying to find a way to
> > determine whether the amount reported is correct
Dave Johnson writes:
> The e820 info from the BIOS can help too (provided your BIOS is
> bug-free), get it from dmesg or /var/log/dmesg
>
> system 3
>
>
> BIOS-provided physical RAM map:
> BIOS-e820: - 0009fc00 (usable)
> BIOS-e820: 0009fc00 - 00
On Wed, Jul 16, 2008 at 5:07 PM, Dave Johnson <[EMAIL PROTECTED]>
wrote:
> Dave Johnson writes:
> > The e820 info from the BIOS can help too (provided your BIOS is
> > bug-free), get it from dmesg or /var/log/dmesg
> >
> > system 3
> >
> >
> > BIOS-provided physical RAM map:
> > BIOS-e82
On Wed, Jul 16, 2008 at 3:20 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Recent Linux kernels have had a minor bug in that the amount of memory
> reported in /proc/meminfo is incorrect. I'm trying to find a way to
> determine whether the amount reported is correct or not.
>
> I ne
"Ben Scott" <[EMAIL PROTECTED]> writes:
> On Wed, Jul 16, 2008 at 3:20 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
>> Recent Linux kernels have had a minor bug in that the amount of memory
>> reported in /proc/meminfo is incorrect.
>
> Got details?
Not currently, and given I'm going on vacation
"Kenny Lussier" <[EMAIL PROTECTED]> writes:
> What kind of systems are these? Most systems today have some sort of
> IPMI-based interface that is independent of the OS and can give you a
> physical hardware inventory (and usually a whole lot more).
Yes, there's an IPMI interface, but no IPMI modu
Thanks for all the responses so far. Once I've gotten back from
vacation, I'll write up a summary on which approaches were tried,
used/discarded and why.
If you have any more idea, please keep them coming, and I'll check
them when I get back this webinet interclicky thing connected to my
compute
On Wed, Jul 16, 2008 at 11:11 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
> I believe free reads /proc/meminfo.
Yah, and so, apparently, does the sysconf(3) POSIX library function. :-/
Why are you looking to find out how much memory there is? Hardware
asset inventory, system requirements ch
On Wed, Jul 16, 2008 at 11:16 PM, Paul Lussier <[EMAIL PROTECTED]>
wrote:
> "Kenny Lussier" <[EMAIL PROTECTED]> writes:
>
> > What kind of systems are these? Most systems today have some sort of
> > IPMI-based interface that is independent of the OS and can give you a
> > physical hardware invento
Paul Lussier writes:
>
> Hi all,
>
> Recent Linux kernels have had a minor bug in that the amount of memory
> reported in /proc/meminfo is incorrect. I'm trying to find a way to
> determine whether the amount reported is correct or not.
>
> I need some means of reliably knowing whether this val
> Paul Lussier writes:
> >
> > Hi all,
> >
> > Recent Linux kernels have had a minor bug in that the amount of memory
> > reported in /proc/meminfo is incorrect. I'm trying to find a way to
> > determine whether the amount reported is correct or not.
> >
> > I need some means of reliably knowin
On 7/16/08, Paul Lussier <[EMAIL PROTECTED]> wrote:
> Hi all,
> Recent Linux kernels have had a minor bug in that the amount of memory
> reported in /proc/meminfo is incorrect. I'm trying to find a way to
> determine whether the amount reported is correct or not.
> I need some means of reliably kn
"Ben Scott" <[EMAIL PROTECTED]> writes:
> On Wed, Jul 16, 2008 at 11:11 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
>> I believe free reads /proc/meminfo.
>
> Yah, and so, apparently, does the sysconf(3) POSIX library function. :-/
>
> Why are you looking to find out how much memory there is?
"Kenny Lussier" <[EMAIL PROTECTED]> writes:
> Where you have 400+ servers, it's well worth the investment.
Ahh, the cost-sensitivity isn't for out 400+ systems in-house. The
cost-sensitivity is "what's the customer willing to pay for our
solution". Adding one of these cards into each system the
"Thomas Charron" <[EMAIL PROTECTED]> writes:
> Are you talking about a real bug, or the fact that meminfo only
> reports non kernel memory?
A real bug.
--
Seeya,
Paul
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org
Dave Johnson <[EMAIL PROTECTED]> writes:
> $ sensors
> eeprom-i2c-0-52
> Adapter: SMBus I801 adapter at e8a0
> Memory type:DDR2 SDRAM DIMM
> Memory size (MB): 2048
>
> eeprom-i2c-0-50
> Adapter: SMBus I801 adapter at e8a0
> Memory type:DDR2 SDRAM DIMM
> Memory size (M
On Tue, Jul 29, 2008 at 12:42 PM, Paul Lussier <[EMAIL PROTECTED]> wrote:
> If they don't match, the test fails, and we know we have a bad kernel.
Ah, so your actual goal is to test if the the kernel is reporting
memory properly. So much for workarounds. :)
Did you have any luck scrounging
> the amount of memory reported is not equal to the amount of memory
> physcicall in the system. Since this is a known kernel bug
Which kernels/platforms/situations does this bug show up in?
Can you point us to a description somewhere?
___
gnhlug-di
On 7/29/08, Paul Lussier <[EMAIL PROTECTED]> wrote:
> "Thomas Charron" <[EMAIL PROTECTED]> writes:
> > Are you talking about a real bug, or the fact that meminfo only
> > reports non kernel memory?
> A real bug.
A bug in that /proc/meminfo doesn't report the amount of physical
memory uder MemTot
"Thomas Charron" <[EMAIL PROTECTED]> writes:
> On 7/29/08, Paul Lussier <[EMAIL PROTECTED]> wrote:
>> "Thomas Charron" <[EMAIL PROTECTED]> writes:
>> > Are you talking about a real bug, or the fact that meminfo only
>> > reports non kernel memory?
>> A real bug.
>
> A bug in that /proc/meminfo d
On 7/29/08, Paul Lussier <[EMAIL PROTECTED]> wrote:
> "Thomas Charron" <[EMAIL PROTECTED]> writes:
> >> A real bug.
> > A bug in that /proc/meminfo doesn't report the amount of physical
> > memory uder MemTotal?
> Yes, and that possibly, over time, the amount of memory in
> /proc/meminfo actually
Paul Lussier writes:
> "Thomas Charron" <[EMAIL PROTECTED]> writes:
>
> > On 7/29/08, Paul Lussier <[EMAIL PROTECTED]> wrote:
> >> "Thomas Charron" <[EMAIL PROTECTED]> writes:
> >> > Are you talking about a real bug, or the fact that meminfo only
> >> > reports non kernel memory?
> >> A real bug.
On Wed, Jul 30, 2008 at 8:10 AM, Dave Johnson
<[EMAIL PROTECTED]> wrote:
> Paul Lussier writes:
>> "Thomas Charron" <[EMAIL PROTECTED]> writes:
>> > A bug in that /proc/meminfo doesn't report the amount of physical
>> > memory uder MemTotal?
>> Yes, and that possibly, over time, the amount of mem
On Jul 30, 2008, at 10:03, Thomas Charron wrote:
> MemTotal can change. MemTotal doesn't show memory utilized by the
> kernel binaries themselves in memory, however there are situations
> where modules can leak memory which also removes from MemTotal. I
> don't recall the specifics of this hap
As Steve mentioned, dmidecode provides information on physical
> memory. Here's a quickie to dump memory sizes:
>
> sudo dmidecode -t 6 | grep Installed | grep -v Not | cut -f 2 -d :
> | cut -f 2,3 -d ' '
>
I was curious and gave this a run on my Dell Precision desktop here at work.
"-t 6" (ty
Bill McGonigle <[EMAIL PROTECTED]> writes:
> As Steve mentioned, dmidecode provides information on physical
> memory. Here's a quickie to dump memory sizes:
>
>sudo dmidecode -t 6 | grep Installed | grep -v Not | cut -f 2 -d :
> | cut -f 2,3 -d ' '
Interestingly, I have to use -t 17, not
On 7/30/08, Bill McGonigle <[EMAIL PROTECTED]> wrote:
> On Jul 30, 2008, at 10:03, Thomas Charron wrote:
> > MemTotal can change. MemTotal doesn't show memory utilized by the
> > kernel binaries themselves in memory, however there are situations
> > where modules can leak memory which also remov
On Wed, Jul 30, 2008 at 10:34 AM, Bill McGonigle <[EMAIL PROTECTED]> wrote:
> sudo dmidecode -t 6 | grep Installed | grep -v Not | cut -f 2 -d :
> | cut -f 2,3 -d ' '
Some more datapoints:
On a Gateway "server" running CentOS 5.x with current updates
(kernel 2.6.18-92.1.6.el5), that tells m
On Aug 3, 2008, at 13:50, Ben Scott wrote:
> Situation seems to be getting murkier by the minute. :)
The difference in Memtotal? This can at least be affected by shared
RAM, etc.
I found a few (older) machines that needed -t 6 and some (newer)
servers that needed -t 17.
Here's a quick s
Bill McGonigle wrote:
> On Aug 3, 2008, at 13:50, Ben Scott wrote:
>
>> Situation seems to be getting murkier by the minute. :)
>
> The difference in Memtotal? This can at least be affected by shared
> RAM, etc.
>
> I found a few (older) machines that needed -t 6 and some (newer)
> ser
On Sun, Aug 3, 2008 at 2:52 PM, Bill McGonigle <[EMAIL PROTECTED]> wrote:
>> Situation seems to be getting murkier by the minute. :)
>
> The difference in Memtotal? This can at least be affected by shared RAM,
> etc.
Right; point was just that deciding if the MemTotal value is
"correct" or no
On Sun, Aug 3, 2008 at 2:52 PM, Bill McGonigle <[EMAIL PROTECTED]>wrote:
> On Aug 3, 2008, at 13:50, Ben Scott wrote:
>
> > Situation seems to be getting murkier by the minute. :)
>
> The difference in Memtotal? This can at least be affected by shared
> RAM, etc.
>
> I found a few (older) mach
38 matches
Mail list logo
