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
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/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
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@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
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
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@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
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@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
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
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
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
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.
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (7)
-
Adrian Cornish -
Andrzej Kardas -
andrzej-kardas
-
Haojian Zhuang -
julie Sullivan -
Mulyadi Santosa -
Vijay Ram Chitrapu