01-20-2016 08:19 AM
I'm running Linux on the Zynq, booting from an SD card. My application creates a number of message queues and semaphores. Near the end of initialization these resources the following error appears:
sem_open() Failed.(28) No space left on device
I'm a bit confused about exactly which device is full? I'm booting off a 32GB SD card that is partitioned by following the instructions on the Xilinx Wiki page.
So, is this the filesystem on the root partition of the SD card? Memory? Any help is greatly appreciated!
01-20-2016 11:05 PM
sem_open() needs shared memory. Typically shared memory is mounted as tmpfs on /dev/shm, so it consumes RAM resources. Try 'df -h' to find out how many space is left on shared memory. However, it is strange that sem_open() returns ENOSPC, because it should return ENOMEM in such cases. But you might have different implementation.
Hope this helps a bit.
01-21-2016 02:20 AM
For your error, there might also be the reasons like swap space, the system limit for the maximum number of semaphore sets (SEMMNI),or the system wide maximum number of semaphores (SEMMNS).
Can you please check the below things of your system?
petalinux@petalinux:~$ cat /proc/sys/kernel/sem
250 32000 32 128
petalinux@petalinux:~$ cat /proc/sys/kernel/msgmni
You can make changes to the above things by writing into sysctl.conf file under /etc directory. E.g. kernel.msgmax = 65536, kernel.msgmnb = 65536 etc
You can also search for specific element information of /proc/sys/kernel/* (e.g.sem) in proc manual page(man proc):
/proc/sys/kernel/sem (since Linux 2.4)
This file contains 4 numbers defining limits for System V IPC semaphores. These fields are, in order:
SEMMSL The maximum semaphores per semaphore set.
SEMMNS A system-wide limit on the number of semaphores in all semaphore sets.
SEMOPM The maximum number of operations that may be specified in a semop(2) call.
SEMMNI A system-wide limit on the maximum number of semaphore identifiers.
/proc/sys/kernel/msgmni (since Linux 2.4)
This file defines the system-wide limit on the number of message queue identifiers.
01-21-2016 07:52 AM
It appears that my application is using all the system resources. We have an 8MB rootfs, so I started down the path of making a larger 16MB rootfs yesterday (which is not yet working.) Am I headed down the wrong path?
As a side note, I made an empty rootfs 16MB in size (all per the Xilinx wiki instructions) and then copied the directories from my 8MB rootfs (stripped the header and mounted the ramdisk.image file.) I then built a new device tree, adding the "ramdisk_size" parameter to the boot args. What did I miss?
RAMDISK: gzip image found at block 0
mmc0: new high speed SDHC card at address aaaa
mmcblk0: mmc0:aaaa SS32G 29.7 GiB
mmcblk0: p1 p2
List of all partitions:
0100 16384 ram0 (driver?)
0101 16384 ram1 (driver?)
0102 16384 ram2 (driver?)
0103 16384 ram3 (driver?)
0104 16384 ram4 (driver?)
0105 16384 ram5 (driver?)
0106 16384 ram6 (driver?)
0107 16384 ram7 (driver?)
0108 16384 ram8 (driver?)
0109 16384 ram9 (driver?)
010a 16384 ram10 (driver?)
010b 16384 ram11 (driver?)
010c 16384 ram12 (driver?)
010d 16384 ram13 (driver?)
010e 16384 ram14 (driver?)
010f 16384 ram15 (driver?)
b300 31166976 mmcblk0 driver: mmcblk
b301 204800 mmcblk0p1 8a1a7f7a-01
b302 30961152 mmcblk0p2 8a1a7f7a-02
No filesystem could mount root, tried: ext3 ext2 ext4 vfat msdos
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0-xilinx-00076-gdfc1bc8-dirty #7
Hardware name: Xilinx Zynq Platform
[<c001480c>] (unwind_backtrace) from [<c0010d4c>] (show_stack+0x10/0x14)
[<c0010d4c>] (show_stack) from [<c047e9b8>] (dump_stack+0x80/0xcc)
[<c047e9b8>] (dump_stack) from [<c00131e8>] (ipi_cpu_stop+0x3c/0x6c)
[<c00131e8>] (ipi_cpu_stop) from [<c00137d0>] (handle_IPI+0x64/0x84)
[<c00137d0>] (handle_IPI) from [<c00085e8>] (gic_handle_irq+0x54/0x5c)
[<c00085e8>] (gic_handle_irq) from [<c0011700>] (__irq_svc+0x40/0x74)
Exception stack(0xee86df70 to 0xee86dfb8)
df60: 8d058872 00000000 8d058872 00000000
df80: eefe1e08 00000000 8cab5962 00000000 c06c2280 00000001 00000000 c0485848
dfa0: 00000008 ee86dfb8 c00600dc c0376b20 90000113 ffffffff
[<c0011700>] (__irq_svc) from [<c0376b20>] (cpuidle_enter_state+0x50/0x108)
[<c0376b20>] (cpuidle_enter_state) from [<c0049090>] (cpu_startup_entry+0x1a8/0x268)
[<c0049090>] (cpu_startup_entry) from [<00008684>] (0x8684)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
02-08-2016 12:05 PM
root@zynq:/proc/sys/kernel# more sem
32000 1024000000 500 32000
Not sure exactly what these numbers mean. I am still trying to get a larger rootfs in place.
Was sidetracked on some different work for a few days and now trying to get back into this...any help appreciated.
02-08-2016 12:06 PM
This is what led me down the rootfs path... it appears that there is no space left in /dev
root@zynq:/proc/sys/kernel# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 64 64 0 100% /dev
tmpfs 516240 16 516224 0% /run
tmpfs 516240 16 516224 0% /var/volatile
02-15-2016 12:23 PM
df -h results:
/devtempfs is 64k and 100% used
/proc/sys/kernel/sem is 32000 1024000000 500 32000
Picking this back up after a short detour...any advice appreciated!
02-16-2016 05:41 AM
You could try resizing it explicitly:
mount -oremount,size=1M /dev
If that helps, then we'll have to track down why your devtmpfs is being created with ony 64k, as opposed to the tmpfs default which is 50% of your RAM size.