* Enabling Signals in kernel
@ 2011-04-12 16:06 Vijay Ram Chitrapu
2011-04-13 1:01 ` Haojian Zhuang
2011-04-13 17:20 ` Missing 1GB RAM, where is it? Andrzej Kardas
0 siblings, 2 replies; 16+ messages in thread
From: Vijay Ram Chitrapu @ 2011-04-12 16:06 UTC (permalink / raw)
To: kernelnewbies
Hi experts,
I am using MVL6.0 in my project and have customized the kernel as per
the requirement. However, i am facing a problem where the Ctrl+C
signal doesn't get caught (or not sure if it is even generated) on the
target platform. I have tried using the "trap" at the shell to capture
the signal but the signal just doesn't get caught. Below is what i
have done to try the trap way
trap " " INT
echo "Catching Ctrl+C signal"
trap INT
sleep 5
Putting this piece of code into a script doesn't catch the signal
SIGINT (ctrl+c). To understand if it was a problem with the shell, i
wrote a C code to register my own signal handler for SIGINT signal. To
verify the correctness of the code, i executed the C code on the HOST
server and it works well there (signal handler gets invoked when
ctrl+c is pressed). Whereas, the same C code doesn't catch the Ctr+C
signal in the target platform.
Can someone tell me if there is any specific way to identify is there
a way or rather is there a need to enable the signals explicitly while
creating the config file for the kernel? Below is the output of "stty
-a" command at the shell where i need to catch the Ctrl+C signal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/ # stty -a
speed 115200 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Regards,
Vijay
^ permalink raw reply [flat|nested] 16+ messages in thread
* Enabling Signals in kernel
2011-04-12 16:06 Enabling Signals in kernel Vijay Ram Chitrapu
@ 2011-04-13 1:01 ` Haojian Zhuang
2011-04-13 19:30 ` julie Sullivan
2011-04-13 17:20 ` Missing 1GB RAM, where is it? Andrzej Kardas
1 sibling, 1 reply; 16+ messages in thread
From: Haojian Zhuang @ 2011-04-13 1:01 UTC (permalink / raw)
To: kernelnewbies
On Wed, Apr 13, 2011 at 12:06 AM, Vijay Ram Chitrapu
<chitrapu.vijayram@gmail.com> wrote:
> Hi experts,
>
> I am using MVL6.0 in my project and have customized the kernel as per
> the requirement. However, i am facing a problem where the Ctrl+C
> signal doesn't get caught (or not sure if it is even generated) on the
> target platform. I have tried using the "trap" at the shell to capture
> the signal but the signal just doesn't get caught. Below is what i
> have done to try the trap way
>
> trap " " INT
It means that ignore INT signal.
> echo "Catching Ctrl+C signal"
> trap INT
> sleep 5
>
You can try this to capture "Ctrl+C" signal.
trap 'echo "Catching Ctrl+C signal"' 2
> Putting this piece of code into a script doesn't catch the signal
> SIGINT (ctrl+c). To understand if it was a problem with the shell, i
> wrote a C code to register my own signal handler for SIGINT signal. To
> verify the correctness of the code, i executed the C code on the HOST
> server and it works well there (signal handler gets invoked when
> ctrl+c is pressed). Whereas, the same C code doesn't catch the Ctr+C
> signal in the target platform.
>
> Can someone tell me if there is any specific way to identify is there
> a way or rather is there a need to enable the signals explicitly while
> creating the config file for the kernel? Below is the output of "stty
> -a" command at the shell where i need to catch the Ctrl+C signal.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> / # stty -a
> speed 115200 baud; rows 24; columns 80;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
> -parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
> -iuclc -ixany -imaxbel
> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
> echoctl echoke
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Regards,
> Vijay
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-12 16:06 Enabling Signals in kernel Vijay Ram Chitrapu
2011-04-13 1:01 ` Haojian Zhuang
@ 2011-04-13 17:20 ` Andrzej Kardas
2011-04-14 2:42 ` Mulyadi Santosa
2011-04-14 15:09 ` Adrian Cornish
1 sibling, 2 replies; 16+ messages in thread
From: Andrzej Kardas @ 2011-04-13 17:20 UTC (permalink / raw)
To: kernelnewbies
Hi,
I'm little confused about amount of RAM memory in my computer and I
can't figure out where disappear about 1GB memory. I need yours help to
explain this, because i can't sleep :). Here is background:
I've plugged into my computer 2x2GB RAM. In BIOS screen i see:
Amount of available RAM: 4096MB
so BIOS recognizes all 4GB, but my OS(*32bit*)
uname -a
Linux lpt 2.6.33.1 #1 SMP Thu Mar 18 23:32:41 CET 2010 i686 GNU/Linux
sees only 3014MB
free -m
total used free shared buffers cached
Mem: *3014* 1756 1258 0 456 918
first, i thought that most of this missing memory is not available
because of mapped IO, so i decided to count this by using addresses from
/proc/iomem (where the actual memory map is). I've wrote piece of code
like this to count all memory seen by OS:
for i in `cat /proc/iomem | grep -P "^[^\s]" | awk '{ print $1}' | sort
| uniq`; do startAddr=$(echo $i | awk -F "-" '{print $1}') &&
endAddr=$(echo $i | awk -F "-" '{print $2}'); bytes=$(calc
"(0x$endAddr-0x$startAddr)"); ((sum+=${bytes})); done; echo "TotalMB: "
; calc "$sum/(1024*1024)";
*TotalMB:
3745.726528167724609375*
There is still missing almost 400MB. If i think correct, in /proc/iomem
should be map of all memory, so it should cover all 4096 MB, right ??
Lets, count amount of ram not available for user, reserved for (mapped
IO) ACPI, PCI bus etc:
for i in `cat /proc/iomem | grep -v "System RAM" | grep -P "^[^\s]" |
awk '{ print $1}' | sort | uniq`; do startAddr=$(echo $i | awk -F "-"
'{print $1}') && endAddr=$(echo $i | awk -F "-" '{print $2}');
bytes=$(calc "(0x$endAddr-0x$startAddr)"); ((sum+=${bytes})); done; echo
"TotalMB: " ; calc "$sum/(1024*1024)";
*TotalMB:
683.65817165374755859375*
Only 683MB, so if my calculation are correct, where disappear 400MB?? It
seems to be that OS doesn't even sees this 400MB. Any idea?
Extra logs:
CPU is able to handle 36bit address size:
cat /proc/cpuinfo | grep address
address sizes : 36 bits physical, 48 bits virtual
address sizes : 36 bits physical, 48 bits virtual
Enabled PAE in kernel - but in this case there should not be difference
(RAM isn't above 4GB)
cat /boot/config-2.6.33.1 | grep PAE
CONFIG_X86_PAE=y
My iomem:
root at lpt:~# cat /proc/iomem
00000000-00001fff : System RAM
00002000-0000ffff : reserved
00010000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000cf000-000d07ff : Adapter ROM
000e0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-bf67ffff : System RAM
00100000-005951c8 : Kernel code
005951c9-007be6e7 : Kernel data
00854000-008dfadb : Kernel bss
bf680000-bf6fffff : ACPI Non-volatile Storage
bf700000-bfffffff : reserved
c0000000-c3ffffff : PCI Bus 0000:06
c0000000-c3ffffff : PCI CardBus 0000:07
c4000000-c41fffff : PCI Bus 0000:02
c4200000-c43fffff : PCI Bus 0000:02
c4400000-c45fffff : PCI Bus 0000:03
c4600000-c47fffff : PCI Bus 0000:03
c4800000-c49fffff : PCI Bus 0000:04
c4a00000-c4bfffff : PCI Bus 0000:04
c4c00000-c4dfffff : PCI Bus 0000:05
c4e00000-c4e00fff : Intel Flush Page
c8000000-cbffffff : PCI CardBus 0000:07
d0000000-dfffffff : 0000:00:02.0
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : reserved
e0000000-efffffff : pnp 00:01
f0000000-f007ffff : 0000:00:02.0
f0080000-f00fffff : 0000:00:02.1
f0100000-f01fffff : PCI Bus 0000:05
f0100000-f0100fff : 0000:05:00.0
f0100000-f0100fff : iwl3945
f0200000-f02fffff : PCI Bus 0000:06
f0200000-f0201fff : 0000:06:01.0
f0200000-f0201fff : 0000:06:01.0
f0202000-f0202fff : 0000:06:04.0
f0202000-f0202fff : yenta_socket
f0203000-f020307f : 0000:06:04.1
f0203100-f02031ff : 0000:06:04.4
f0203100-f02031ff : mmc1
f0203400-f02034ff : 0000:06:04.2
f0203400-f02034ff : mmc0
f0203800-f020387f : 0000:06:04.3
f0300000-f033ffff : 0000:00:02.0
f0340000-f0343fff : 0000:00:1b.0
f0340000-f0343fff : ICH HD audio
f0544000-f05443ff : 0000:00:1d.7
f0544000-f05443ff : ehci_hcd
fec00000-fec0ffff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed00000-fed003ff : reserved
fed00000-fed003ff : pnp 00:04
fed14000-fed19fff : reserved
fed14000-fed17fff : pnp 00:01
fed18000-fed18fff : pnp 00:01
fed19000-fed19fff : pnp 00:01
fed1c000-fed8ffff : reserved
fed1c000-fed1ffff : pnp 00:01
fed20000-fed3ffff : pnp 00:01
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
ff000000-ffffffff : reserved
--
regards
Andrzej Kardas
http://www.linux.mynotes.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110413/c7009d76/attachment.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Enabling Signals in kernel
2011-04-13 1:01 ` Haojian Zhuang
@ 2011-04-13 19:30 ` julie Sullivan
0 siblings, 0 replies; 16+ messages in thread
From: julie Sullivan @ 2011-04-13 19:30 UTC (permalink / raw)
To: kernelnewbies
Hi Vijay
>> Putting this piece of code into a script doesn't catch the signal
>> SIGINT (ctrl+c). To understand if it was a problem with the shell, i
>> wrote a C code to register my own signal handler for SIGINT signal.
Incidentally there is a bug with Bash where ctrl+c isn't caught, see
this discussion on linux-kernel from February:
https://lkml.org/lkml/2011/2/5/191
I doubt if this is your problem though, for as you can see from the
discussion ctrl+c is only sporadically dropped in the shell, usually
it's caught OK.
Cheers
Julie
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-13 17:20 ` Missing 1GB RAM, where is it? Andrzej Kardas
@ 2011-04-14 2:42 ` Mulyadi Santosa
2011-04-14 11:27 ` andrzej-kardas
2011-04-14 15:09 ` Adrian Cornish
1 sibling, 1 reply; 16+ messages in thread
From: Mulyadi Santosa @ 2011-04-14 2:42 UTC (permalink / raw)
To: kernelnewbies
Hi...
On Thu, Apr 14, 2011 at 00:20, Andrzej Kardas <andrzej-kardas@o2.pl> wrote:
> Hi,
>
> I'm little confused about amount of RAM memory in my computer and I can't
> figure out where disappear about 1GB memory. I need yours help to explain
> this, because i can't sleep :). Here is background:
>
> I've plugged into my computer 2x2GB RAM. In BIOS screen i see:
>
> Amount of available RAM: 4096MB
>
> so BIOS recognizes all 4GB, but my OS(32bit)
>
> uname -a
> Linux lpt 2.6.33.1 #1 SMP Thu Mar 18 23:32:41 CET 2010 i686 GNU/Linux
>
> sees only 3014MB
>
> free -m
> ???????????? total?????? used?????? free???? shared??? buffers???? cached
> Mem:????????? 3014?????? 1756?????? 1258????????? 0??????? 456??????? 918
OK, easiest things first, could you show us:
1. the output of "grep -i highmem " toward your running kernel config file?
2. the complete entry grub/lilo stanza that is responsible to execute
your current running kernel
I need to see whether you're really enabling highmem support and
whether you use kinda kdump etc that might reserve some space in
RAM....
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Missing 1GB RAM, where is it?
2011-04-14 2:42 ` Mulyadi Santosa
@ 2011-04-14 11:27 ` andrzej-kardas
2011-04-14 12:17 ` Mulyadi Santosa
0 siblings, 1 reply; 16+ messages in thread
From: andrzej-kardas @ 2011-04-14 11:27 UTC (permalink / raw)
To: kernelnewbies
> OK, easiest things first, could you show us:
> 1. the output of "grep -i highmem " toward your running kernel config file?
Highmem is on:
cat /boot/config-2.6.33.1 | grep -i highmem
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
# CONFIG_DEBUG_HIGHMEM is not set
>
> 2. the complete entry grub/lilo stanza that is responsible to execute
> your current running kernel
>
menuentry 'Linux 2.6.33.1' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,2)'
search --no-floppy --fs-uuid --set 2875dab1-590c-4c56-a1a8-69ac3221e339
linux /boot/vmlinuz-2.6.33.1 root=UUID=2875dab1-590c-4c56-a1a8-69ac3221e339 ro quiet splash
initrd /boot/initrd.img-2.6.33.1
}
I noticed that addresses in /proc/iomem are not contiguous as follow:
root at lpt:~# cat /proc/iomem
00000000-00001fff : System RAM
00002000-0000ffff : reserved
00010000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000cf000-000d07ff : Adapter ROM
hole - how about address range from 000d0800 to 000dffff ??
000e0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-bf67ffff : System RAM
00100000-005951c8 : Kernel code
005951c9-007be6e7 : Kernel data
00854000-008dfadb : Kernel bss
bf680000-bf6fffff : ACPI Non-volatile Storage
bf700000-bfffffff : reserved
c0000000-c3ffffff : PCI Bus 0000:06
c0000000-c3ffffff : PCI CardBus 0000:07
c4000000-c41fffff : PCI Bus 0000:02
c4200000-c43fffff : PCI Bus 0000:02
c4400000-c45fffff : PCI Bus 0000:03
c4600000-c47fffff : PCI Bus 0000:03
c4800000-c49fffff : PCI Bus 0000:04
c4a00000-c4bfffff : PCI Bus 0000:04
c4c00000-c4dfffff : PCI Bus 0000:05
c4e00000-c4e00fff : Intel Flush Page
next hole, c4e01000 - c7ffffff ?
c8000000-cbffffff : PCI CardBus 0000:07
d0000000-dfffffff : 0000:00:02.0
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : reserved
e0000000-efffffff : pnp 00:01
f0000000-f007ffff : 0000:00:02.0
f0080000-f00fffff : 0000:00:02.1
f0100000-f01fffff : PCI Bus 0000:05
f0100000-f0100fff : 0000:05:00.0
f0100000-f0100fff : iwl3945
f0200000-f02fffff : PCI Bus 0000:06
f0200000-f0201fff : 0000:06:01.0
f0200000-f0201fff : 0000:06:01.0
f0202000-f0202fff : 0000:06:04.0
f0202000-f0202fff : yenta_socket
f0203000-f020307f : 0000:06:04.1
f0203100-f02031ff : 0000:06:04.4
f0203100-f02031ff : mmc1
f0203400-f02034ff : 0000:06:04.2
f0203400-f02034ff : mmc0
f0203800-f020387f : 0000:06:04.3
f0300000-f033ffff : 0000:00:02.0
f0340000-f0343fff : 0000:00:1b.0
f0340000-f0343fff : ICH HD audio
hole - f0344000 - f0543fff
f0544000-f05443ff : 0000:00:1d.7
f0544000-f05443ff : ehci_hcd
hole - f0544400 - febfffff
fec00000-fec0ffff : reserved
fec00000-fec003ff : IOAPIC 0
hole - fec0ffff - fecfffff
fed00000-fed003ff : HPET 0
fed00000-fed003ff : reserved
fed00000-fed003ff : pnp 00:04
hole - fed00400 - fed13fff
fed14000-fed19fff : reserved
fed14000-fed17fff : pnp 00:01
fed18000-fed18fff : pnp 00:01
fed19000-fed19fff : pnp 00:01
hole - fed1a000 - fed1bfff
fed1c000-fed8ffff : reserved
fed1c000-fed1ffff : pnp 00:01
fed20000-fed3ffff : pnp 00:01
hole - fed90000 - fedfffff
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
hole - fee00fff - feffffff
ff000000-ffffffff : reserved
Addreses marked by me as "hole", I think, are reserved for usage for devices, but why aren't show in /proc/iomem as region of "reserved" or something else (like BIOS region, or PCI bus?
--
regards
Andrzej Kardas
http://www.linux.mynotes.pl
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-14 11:27 ` andrzej-kardas
@ 2011-04-14 12:17 ` Mulyadi Santosa
2011-04-14 15:23 ` Andrzej Kardas
0 siblings, 1 reply; 16+ messages in thread
From: Mulyadi Santosa @ 2011-04-14 12:17 UTC (permalink / raw)
To: kernelnewbies
Hi....
On Thu, Apr 14, 2011 at 12:27, andrzej-kardas <andrzej-kardas@o2.pl> wrote:
> Highmem is on:
>
> cat /boot/config-2.6.33.1 ?| grep -i highmem
> # CONFIG_NOHIGHMEM is not set
> # CONFIG_HIGHMEM4G is not set
> CONFIG_HIGHMEM64G=y
> CONFIG_HIGHMEM=y
> # CONFIG_DEBUG_HIGHMEM is not set
Ok, great... support is there...
>>
>> 2. the complete entry grub/lilo stanza that is responsible to execute
>> your current running kernel
>>
>
> menuentry 'Linux 2.6.33.1' --class ubuntu --class gnu-linux --class gnu --class os {
> ? ? ? recordfail
> ? ? ? insmod ext2
> ? ? ? set root='(hd0,2)'
> ? ? ? search --no-floppy --fs-uuid --set 2875dab1-590c-4c56-a1a8-69ac3221e339
> ? ? ? linux ? /boot/vmlinuz-2.6.33.1 root=UUID=2875dab1-590c-4c56-a1a8-69ac3221e339 ro ? quiet splash
> ? ? ? initrd ?/boot/initrd.img-2.6.33.1
> }
OK, so far, no memory reserve or kdump alike execution I saw
above...that's two..
> I noticed that addresses in /proc/iomem are not contiguous as follow:
>
>
> root at lpt:~# cat /proc/iomem
> 00000000-00001fff : System RAM
> 00002000-0000ffff : reserved
> 00010000-0009f7ff : System RAM
> 0009f800-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000cf000-000d07ff : Adapter ROM
>
>
> hole - how about address range from 000d0800 to 000dffff ??
Now that's something I can't answer directly.... there's a chance that
the address range is reserved for unknown reason (so far).
Hm, how about showing us the output of "cat /proc/meminfo"?
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-13 17:20 ` Missing 1GB RAM, where is it? Andrzej Kardas
2011-04-14 2:42 ` Mulyadi Santosa
@ 2011-04-14 15:09 ` Adrian Cornish
2011-04-14 15:43 ` Andrzej Kardas
1 sibling, 1 reply; 16+ messages in thread
From: Adrian Cornish @ 2011-04-14 15:09 UTC (permalink / raw)
To: kernelnewbies
> I'm little confused about amount of RAM memory in my computer and I
can't figure out where disappear about 1GB memory. I need yours help to
explain this, because i can't sleep :). Here is background:
>
> I've plugged into my computer 2x2GB RAM. In BIOS screen i see:
>
> Amount of available RAM: 4096MB
>
> so BIOS recognizes all 4GB, but my OS(32bit)
Just a thought - lower end graphic cards use system RAM as their own
dont they.
Adrian Cornish
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-14 12:17 ` Mulyadi Santosa
@ 2011-04-14 15:23 ` Andrzej Kardas
2011-04-16 6:07 ` Mulyadi Santosa
0 siblings, 1 reply; 16+ messages in thread
From: Andrzej Kardas @ 2011-04-14 15:23 UTC (permalink / raw)
To: kernelnewbies
> Now that's something I can't answer directly.... there's a chance that
> the address range is reserved for unknown reason (so far).
>
> Hm, how about showing us the output of "cat /proc/meminfo"?
>
Here you go:
cat /proc/meminfo
MemTotal: 3087196 kB
MemFree: 2142568 kB
Buffers: 74592 kB
Cached: 511712 kB
SwapCached: 0 kB
Active: 498964 kB
Inactive: 397692 kB
Active(anon): 400988 kB
Inactive(anon): 16 kB
Active(file): 97976 kB
Inactive(file): 397676 kB
Unevictable: 16 kB
Mlocked: 16 kB
HighTotal: 2224648 kB
HighFree: 1392024 kB
LowTotal: 862548 kB
LowFree: 750544 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 60 kB
Writeback: 0 kB
AnonPages: 310364 kB
Mapped: 96468 kB
Shmem: 90656 kB
Slab: 26752 kB
SReclaimable: 16768 kB
SUnreclaim: 9984 kB
KernelStack: 2408 kB
PageTables: 5252 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1543596 kB
Committed_AS: 1265704 kB
VmallocTotal: 122880 kB
VmallocUsed: 12940 kB
VmallocChunk: 97716 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 14328 kB
DirectMap2M: 897024 kB
--
regards
Andrzej Kardas
http://www.linux.mynotes.pl
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-14 15:09 ` Adrian Cornish
@ 2011-04-14 15:43 ` Andrzej Kardas
2011-04-14 16:12 ` Haojian Zhuang
[not found] ` <BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com>
0 siblings, 2 replies; 16+ messages in thread
From: Andrzej Kardas @ 2011-04-14 15:43 UTC (permalink / raw)
To: kernelnewbies
On 14.04.2011 17:09, Adrian Cornish wrote:
> Just a thought - lower end graphic cards use system RAM as their own
> dont they
You right, devices like graphic card, ethernet cards etc. are mapped
into memory, what cause some amount RAM is not available for system use.
But as i've wrote before, i'm wondering why addresses in /proc/iomem
(where the map of memory is) are not contiguous. I think, there should
be info about what region of memory is mapped where (BIOS, PCI bus, for
system use etc)*for whole 4GB *(Am I right??) address space (for 32bit
OS). Instead of that, there are small "holes" in addresses and the total
size of this holes (in my case) is about 400MB. So i wonder where that
memory is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110414/c0b6b2f7/attachment.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-14 15:43 ` Andrzej Kardas
@ 2011-04-14 16:12 ` Haojian Zhuang
2011-04-15 0:45 ` Haojian Zhuang
[not found] ` <BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com>
1 sibling, 1 reply; 16+ messages in thread
From: Haojian Zhuang @ 2011-04-14 16:12 UTC (permalink / raw)
To: kernelnewbies
On Thu, Apr 14, 2011 at 11:43 PM, Andrzej Kardas <andrzej-kardas@o2.pl> wrote:
>
>
> On 14.04.2011 17:09, Adrian Cornish wrote:
>
> Just a thought - lower end graphic cards use system RAM as their own
> dont they
>
> You right, devices like graphic card, ethernet cards etc. are mapped into
> memory, what cause some amount RAM is not available for system use. But as
> i've wrote before, i'm wondering why addresses in /proc/iomem (where the map
> of memory is) are not contiguous. I think, there should be info about what
> region of memory is mapped where (BIOS, PCI bus, for system use etc) for
> whole 4GB (Am I right??) address space (for 32bit OS). Instead of that,
> there are small "holes" in addresses and the total size of this holes (in my
> case) is about 400MB. So i wonder where that memory is.
>
What you see from /proc/iomem is virtual address. For the 32-bit
system, it's 4GB size.
Virtual address needn't be sorted one by one.
You have 4GB physical memory. But only a part is mapped linearly in
virtual address.
They're called lowmem. The rest are used as highmem what can be
allocated by device
driver or applications. Kernel needs to map it first before accessing highmem.
CPU's MMU manages the mapping table between virtual address and
physical address.
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-14 16:12 ` Haojian Zhuang
@ 2011-04-15 0:45 ` Haojian Zhuang
0 siblings, 0 replies; 16+ messages in thread
From: Haojian Zhuang @ 2011-04-15 0:45 UTC (permalink / raw)
To: kernelnewbies
On Fri, Apr 15, 2011 at 12:12 AM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> On Thu, Apr 14, 2011 at 11:43 PM, Andrzej Kardas <andrzej-kardas@o2.pl> wrote:
>>
>>
>> On 14.04.2011 17:09, Adrian Cornish wrote:
>>
>> Just a thought - lower end graphic cards use system RAM as their own
>> dont they
>>
>> You right, devices like graphic card, ethernet cards etc. are mapped into
>> memory, what cause some amount RAM is not available for system use. But as
>> i've wrote before, i'm wondering why addresses in /proc/iomem (where the map
>> of memory is) are not contiguous. I think, there should be info about what
>> region of memory is mapped where (BIOS, PCI bus, for system use etc) for
>> whole 4GB (Am I right??) address space (for 32bit OS). Instead of that,
>> there are small "holes" in addresses and the total size of this holes (in my
>> case) is about 400MB. So i wonder where that memory is.
>>
> What you see from /proc/iomem is virtual address. For the 32-bit
> system, it's 4GB size.
> Virtual address needn't be sorted one by one.
>
> You have 4GB physical memory. But only a part is mapped linearly in
> virtual address.
> They're called lowmem. The rest are used as highmem what can be
> allocated by device
> driver or applications. Kernel needs to map it first before accessing highmem.
>
> CPU's MMU manages the mapping table between virtual address and
> physical address.
>
Oh, my inputs are wrong. Please ignore it. I messed something. What we saw
should be physical memory. I think the real hardware should be accessed by
36-bit, not 32-bit.
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it?
2011-04-14 15:23 ` Andrzej Kardas
@ 2011-04-16 6:07 ` Mulyadi Santosa
0 siblings, 0 replies; 16+ messages in thread
From: Mulyadi Santosa @ 2011-04-16 6:07 UTC (permalink / raw)
To: kernelnewbies
Hi....
On Thu, Apr 14, 2011 at 15:23, Andrzej Kardas <andrzej-kardas@o2.pl> wrote:
> CommitLimit: ? ? 1543596 kB
> Committed_AS: ? ?1265704 kB
ahem...so, it is said that at most, you could commit up to ~1.5
GiB...now that's interesting...
what's your /proc/sys/vm/overcommit_memory and
/proc/sys/vm/overcommit_ratio setting?
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it? - SUMMARY
[not found] ` <BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com>
@ 2011-04-17 7:58 ` Andrzej Kardas
2011-04-17 15:31 ` julie Sullivan
0 siblings, 1 reply; 16+ messages in thread
From: Andrzej Kardas @ 2011-04-17 7:58 UTC (permalink / raw)
To: kernelnewbies
On 14.04.2011 19:30, Wick wrote:
> Hi, Andrzej Kardas:
>
> You're very close now.
I think i got it now :)
> To ensure that kernel detected your 4GB RAM, we need to check the stats:
> wick:~$ dmesg | grep Memory
> [ 0.000000] Memory: 3716784k/4718592k available (5940k kernel code,
> 787332k absent, 214476k reserved, 5017k data, 956k init)
in my case:
dmesg | grep Memory
[ 0.000000] Memory: 3013732k/3136000k available (4692k kernel code,
120780k reserved, 2213k data, 576k init, 2224648k highmem)
after few hours of digging this topic i think this amount of RAM is
correct, as almost everybody from this list suggested :). Here are
results of my investigation:
At early start, when kernel boots and still working in real mode, actual
memory map is taken from BIOS with use interruptINT 15h, AX=E820h.
Result of this interrupt is dumped into ring buffer, so we can read this
by dmsg. In my case:
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf680000 (usable)
[ 0.000000] BIOS-e820: 00000000bf680000 - 00000000bf700000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bf700000 - 00000000c0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
As we can see there are still 'holes' in addresses, similar to
/proc/iomem. These holes are result of INT 15h, AX=E820h, this call
return map of memory but with some limitations
http://www.uruk.org/orig-grub/mem64mb.html):
*
1.* The BIOS will return address ranges describing base board memory and
ISA or PCI memory that is contiguous with that baseboard memory.*
2.* The BIOS WILL NOT return a range description for the memory mapping
of PCI devices, ISA Option ROM's, and ISA plug & play cards. This is
because the OS has mechanisms available to detect them.*
3.* The BIOS will return chipset defined address holes that are not
being used by devices as reserved.*
4.* Address ranges defined for base board memory mapped I/O devices (for
example APICs) will be returned as reserved.*
5.* All occurrences of the system BIOS will be mapped as reserved. This
includes the area below 1 MB, at 16 MB (if present) and at end of the
address space (4 gig).*
6.* Standard PC address ranges will not be reported. Example video
memory at A0000 to BFFFF physical will not be described by this
function. The range from E0000 to EFFFF is base board specific and will
be reported as suits the bas board.*
7.* All of lower memory is reported as normal memory. It is OS's
responsibility to handle standard RAM locations reserved for specific
uses, for example: the interrupt vector table(0:0) and the BIOS data
area(40:0).
So thats why there is a hole for example: 00000000000a0000 -
00000000000e0000 (point 6. Standard PC address range for VGA) and
00000000c0000000 -00000000e0000000 (point 2. mapped PCI devices).
The main goal for OS is _NOT_ use memory ranges _NOT_ reported (holes)
and reported memory ranges different than usable.
When it comes about so many RAM unavailable, about 1 GB in my case, the
answer is in documentation
(http://www.intel.com/design/mobile/datashts/309219.htm) of my
northbridge chipset:
and at lpt:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML
and 945GT Express Memory Controller Hub (rev 03)
It is not very sophisticated unit, because it is not able to remap
memory from PCI range above 4 GB region. According to documentation:
"Addressing of memory ranges larger than 4 GB is _NOT_ supported."
So even my CPU is supporting 36bit physical addresses and PAE, memory
controller is not able to remap memory from PCI range above 4GB range as
other, more advanced chipset do with help of PAE.
I've also found:
"The (G)MCH does not remap APIC or any other memory spaces above TOLUD
(Top of Low Usable DRAM). The TOLUD register is set to the appropriate
value by BIOS."
So each access to memory above TOLUD is transfered to Southbridge or PCI
express (which is directly connected to northbridge) or to the internal
graphics device, TOLUD in my OS is 0xbf67ffffh = 3211263999 bytes,
everything above it is unavailable for usage as RAM.
>> On 14.04.2011 17:09, Adrian Cornish wrote:
>>
>> Just a thought - lower end graphic cards use system RAM as their own
>> dont they
Yes, in my case internal graphic controller's RAM is situated above TOLUD:
and at lpt:~$ lspci -v -s 00:02.0 | grep Memory
Memory at f0000000 (32-bit, non-prefetchable) [size=512K]
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Memory at f0300000 (32-bit, non-prefetchable) [size=256K]
On 14.04.2011 19:30, Wick wrote:
> And about the memory hole in the /proc/iomem, I think it's related to
> kernel's resource management. Dig it in kernel source codes :)
Now i can say :) that, this regions (holes) are simply not available for
system because they are above TOLUD and additionally not assigned to any
device because I haven't particular device in PC for example bluetooth:
I have space for it, but in my version of notebook was not available in
standard equipment.
Many thanks everybody for suggestions and help with this, now I can
assume that total RAM in my PC is correct. I also learned that
documentation is standard point that I should aways start digging, it
can save some time:)
--
regards
Andrzej Kardas
http://www.linux.mynotes.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110417/1ade3cf6/attachment-0001.html
^ permalink raw reply [flat|nested] 16+ messages in thread
* Missing 1GB RAM, where is it? - SUMMARY
2011-04-17 7:58 ` Missing 1GB RAM, where is it? - SUMMARY Andrzej Kardas
@ 2011-04-17 15:31 ` julie Sullivan
2011-04-18 10:17 ` andrzej-kardas
0 siblings, 1 reply; 16+ messages in thread
From: julie Sullivan @ 2011-04-17 15:31 UTC (permalink / raw)
To: kernelnewbies
Andrzej,
Thanks for taking the trouble to put together this useful summary. I
found it really interesting and reading through it helped me to
understand the RAM allocation on my own machine better.
Thanks to everyone else too that took part in the earlier thread.
Cheers
Julie
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Missing 1GB RAM, where is it? - SUMMARY
2011-04-17 15:31 ` julie Sullivan
@ 2011-04-18 10:17 ` andrzej-kardas
0 siblings, 0 replies; 16+ messages in thread
From: andrzej-kardas @ 2011-04-18 10:17 UTC (permalink / raw)
To: kernelnewbies
Dnia 17 kwietnia 2011 17:31 julie Sullivan <kernelmail.jms@gmail.com> napisa?(a):
> Andrzej,
> Thanks for taking the trouble to put together this useful summary. I
> found it really interesting and reading through it helped me to
> understand the RAM allocation on my own machine better.
> Thanks to everyone else too that took part in the earlier thread.
You're welcome Julie.
I'm glad this information were useful for someone :)
--
regards
Andrzej Kardas
http://www.linux.mynotes.pl
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-04-18 10:17 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-12 16:06 Enabling Signals in kernel Vijay Ram Chitrapu
2011-04-13 1:01 ` Haojian Zhuang
2011-04-13 19:30 ` julie Sullivan
2011-04-13 17:20 ` Missing 1GB RAM, where is it? Andrzej Kardas
2011-04-14 2:42 ` Mulyadi Santosa
2011-04-14 11:27 ` andrzej-kardas
2011-04-14 12:17 ` Mulyadi Santosa
2011-04-14 15:23 ` Andrzej Kardas
2011-04-16 6:07 ` Mulyadi Santosa
2011-04-14 15:09 ` Adrian Cornish
2011-04-14 15:43 ` Andrzej Kardas
2011-04-14 16:12 ` Haojian Zhuang
2011-04-15 0:45 ` Haojian Zhuang
[not found] ` <BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com>
2011-04-17 7:58 ` Missing 1GB RAM, where is it? - SUMMARY Andrzej Kardas
2011-04-17 15:31 ` julie Sullivan
2011-04-18 10:17 ` andrzej-kardas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).