kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
* 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).