I'm getting the error "cannot reserve arena virtual address space" while compiling golang on OpenBSD with command "ksh all.bash" (also tried make.bash but didn't work). This is the output:
$ ksh all.bash
# Building C bootstrap tool.
cmd/dist
# Building compilers and Go bootstrap tool for host, openbsd/386.
lib9
libbio
... (truncated)
pkg/go/doc
pkg/go/build
cmd/go
throw: runtime: cannot reserve arena virtual address space
I tried following the directions on http://code.google.com/p/go-wiki/wiki/OpenBSD, but it is also possible I didn't do it correctly. Any tips would be greatly appreciated.
Seems like rather than screwing with the "staff" group, changing the defaults for the "default" section solved the issue.
default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\
:umask=022:\
:datasize-max=infinity:\
:datasize-cur=infinity:\
:maxproc-max=256:\
:maxproc-cur=128:\
:openfiles-cur=128:\
:stacksize-cur=4M:\
:localcipher=blowfish,6:\
:ypcipher=old:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:
Your program fails to allocate virtual address space
http://code.google.com/p/go/source/browse/src/pkg/runtime/malloc.goc#374
I do not use OpenBSD myself, and do not know what your problem is. But you could try and gather more information yourself, if you insert some printouts here:
http://code.google.com/p/go/source/browse/src/pkg/runtime/mem_openbsd.c#54
Alex
Related
I'm trying to load the lx-symbols from the kernel. but it keeps showing me the following error:
(gdb) lx-symbols
loading vmlinux
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xffffffff824fb470:
Error occurred in Python command: Cannot access memory at address 0xffffffff824fb470
Now I was successfully able to load the lx-symbols before from the same build(not sure if this is the correct terminology) but don't know why I can load it anymore.
Now, When I first connect to the remote machine via gdb it used to shows the build trace like the following:
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./vmlinux...done.
(gdb) target remote: 1235
Remote debugging using : 1235
native_safe_halt ()
at /build/linux-hwe-22QmxS/linux-hwe-5.3.0/arch/x86/include/asm/irqflags.h:61
61 /build/linux-hwe-22QmxS/linux-hwe-5.3.0/arch/x86/include/asm/irqflags.h: No such file or directory.
Now when I connect to the remote kernel, it is showing me just this :
(gdb) target remote :1235
Remote debugging using :1235
0xffffffff81a98522 in __irqentry_text_end ()
I notice that the build trace /build/linux-hwe-22QmxS/linux-hwe-5.3.0/arch/x86/include/asm/irqflags.h:61
61 disappear (I did not make any changes to the configuration or setting).
This is the second time I'm facing the same problem. At the first time, I thought maybe i accidentally make some changes but as the problem occurs again, this time I'm quite sure I did not make any changes.
I have my .gdbinit file with the correct path.
add-auto-load-safe-path /../../ubuntu-bionic/debian/build/build-generic/vmlinux-gdb.py
I checked if the source is loading correctly by using the this:
(gdb) source /home/../../ubuntu-bionic/debian/build/build-generic/vmlinux-gdb.py
It didn't throw me any error. So, I guess the source is loading correctly. I just don't know what else to do. Please help.
Try to add to the kernel boot parameters "nokaslr" and/or build with CONFIG_RANDOMIZE_BASE=n
I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)
I'm somehow new to buildroot makefile and I created my own configuration file for a new operating system. After typing
make menuconfig
I saw that the buildroot has made the .config file. but when I type
make
it gives the following error:
linux/linux.mk:69: *** No kernel device tree source specified, check your BR2_LINUX_KERNEL_USE_INTREE_DTS / BR2_LINUX_KERNEL_USE_CUSTOM_DTS settings. Stop.
what does it mean ? what did I forget to include in buildroot configuration menu ?
I searched the internet and didn't find anything useful ... I've looked at the build root documentation and didn't find anything neither ....
In addition to the buildroot .config, you need a linux config. You can create one by:
make linux-menuconfig
See:
How do I configure the Linux kernel within Buildroot?
http://buildroot.org/downloads/manual/manual.html#kernel-custom
Which board do you plan to run the produced image on? Which platform are you building for? Check the output of the following command:
grep ^BR2_ARCH .config
If it is i386 or x86_64, you likely do not need Device Tree support, so just disable it using make menuconfig (search for BR2_LINUX_KERNEL_USE_INTREE_DTS or BR2_LINUX_KERNEL_USE_CUSTOM_DTS by pressing /).
Also check out http://elinux.org/Device_Tree for a detailed description of Device Tree.
It means that you don't have a device tree source file set. There's several different reasons for this. The first thing to check is:
make menuconfig
Select the Kernel options. Near the bottom is the option for "Device tree source". If that's set to "Use a custom device tree file" and you don't have a good path set in the next option, "Device Tree Source file paths", then you will get this error. Alternatively, if it's set to "Use a device tree present in the kernel" and the "Device Tree Source file names" option is blank or the name(s) have .dts at the end, you may get this error.
eCryptfs is a POSIX-compliant encrypted filesystem that has been part of the mainline Linux Kernel since version 2.6.19.
When I try to insert the module (ecryptfs.ko), I get the following error:
insmod: error inserting 'ecryptfs.ko': -1 Cannot allocate memory
Can some one please help me out?
below is the dmesg
Failed to allocate one or more kmem_cache objects
kmem_cache_create: duplicate cache ecryptfs_auth_tok_list_item
Pid: 3332, comm: insmod Tainted: G O 3.2.2+ #1
Call Trace:
[<c102bfe0>] ? printk+0x15/0x17
[<c10878b6>] kmem_cache_create+0x41c/0x458
[<d0ebd038>] ecryptfs_init+0x38/0x1b1 [ecryptfs]
[<c1001071>] do_one_initcall+0x71/0x118
[<d0ebd000>] ? 0xd0ebcfff
[<c1055703>] sys_init_module+0x60/0x18c
[<c12db9b0>] sysenter_do_call+0x12/0x36
ecryptfs_init_kmem_caches: ecryptfs_auth_tok_list_item: kmem_cache_create
failed
Failed to allocate one or more kmem_cache objects
Start with the error you are seeing in dmesg:
kmem_cache_create: duplicate cache ecryptfs_auth_tok_list_item
When the ecryptfs module is loaded the first thing it does is create a bunch of memory caches for itself. The error suggests that there is already a cache with that name.
You can check if the cache already exists by looking at sysfs:
$ ls -ld /sys/kernel/slab/ecryptfs*
NB. It may not show up in /proc/slabinfo due to slab merging.
If you see any ecryptfs slabs that suggests the ecryptfs module is already loaded, or it is already built into your kernel.
Normally the module loader would not let you load the same module twice, but perhaps you have done something weird to confuse it.
A likely cause of something like this happening is if one recompiles and installs a kernel and its modules but forgets to mount /boot before installing the kernel. After a reboot, one will then run with the old kernel but new modules. In any event, check that the running kernel is current, and reinstall both the kernel and the modules if in doubt:
mount /boot
cd /usr/src/linux
make && make install && make modules_install
I have done the above steps and error was solved
I'm compiling a custom kernel under Ubuntu and I'm running into the problem that my kernel doesn't seem to know where to look for firmware. Under Ubuntu 8.04, firmware is tied to kernel version the same way driver modules are. For example, kernel 2.6.24-24-generic stores its kernel modules in:
/lib/modules/2.6.24-24-generic
and its firmware in:
/lib/firmware/2.6.24-24-generic
When I compile the 2.6.24-24-generic Ubuntu kernel according the "Alternate Build Method: The Old-Fashioned Debian Way" I get the appropriate modules directory and all my devices work except those requiring firmware such as my Intel wireless card (ipw2200 module).
The kernel log shows for example that when ipw2200 tries to load the firmware the kernel subsystem controlling the loading of firmware is unable to locate it:
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
errno-base.h defines this as:
#define ENOENT 2 /* No such file or directory */
(The function returning ENOENT puts a minus in front of it.)
I tried creating a symlink in /lib/firmware where my kernel's name pointed to the 2.6.24-24-generic directory, however this resulted in the same error. This firmware is non-GPL, provided by Intel and packed by Ubuntu. I don't believe it has any actual tie to a particular kernel version. cmp shows that the versions in the various directories are identical.
So how does the kernel know where to look for firmware?
Update
I found this solution to the exact problem I'm having, however it no longer works as Ubuntu has eliminated /etc/hotplug.d and no longer stores its firmware in /usr/lib/hotplug/firmware.
Update2
Some more research turned up some more answers. Up until version 92 of udev, the program firmware_helper was the way firmware got loaded. Starting with udev 93 this program was replaced with a script named firmware.sh providing identical functionality as far as I can tell. Both of these hardcode the firmware path to /lib/firmware. Ubuntu still seems to be using the /lib/udev/firmware_helper binary.
The name of the firmware file is passed to firmware_helper in the environment variable $FIRMWARE which is concatenated to the path /lib/firmware and used to load the firmware.
The actual request to load the firmware is made by the driver (ipw2200 in my case) via the system call:
request_firmware(..., "ipw2200-bss.fw", ...);
Now somewhere in between the driver calling request_firmware and firmware_helper looking at the $FIRMWARE environment variable, the kernel package name is getting prepended to the firmware name.
So who's doing it?
From the kernel's perspective, see /usr/src/linux/Documentation/firmware_class/README:
kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
kernel: Discard any previous partial load.
userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
The kernel doesn't actually load any firmware at all. It simply informs userspace, "I want a firmware by the name of xxx", and waits for userspace to pipe the firmware image back to the kernel.
Now, on Ubuntu 8.04,
$ grep firmware /etc/udev/rules.d/80-program.rules
# Load firmware on demand
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
so as you've discovered, udev is configured to run firmware_helper when the kernel asks for firmware.
$ apt-get source udev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 312kB of source archives.
Get:1 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (dsc) [716B]
Get:2 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (tar) [245kB]
Get:3 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (diff) [65.7kB]
Fetched 312kB in 1s (223kB/s)
gpg: Signature made Tue 14 Apr 2009 05:31:34 PM EDT using DSA key ID 17063E6D
gpg: Can't check signature: public key not found
dpkg-source: extracting udev in udev-117
dpkg-source: unpacking udev_117.orig.tar.gz
dpkg-source: applying ./udev_117-8ubuntu0.2.diff.gz
$ cd udev-117/
$ cat debian/patches/80-extras-firmware.patch
If you read the source, you'll find that Ubuntu wrote a firmware_helper which is hard-coded to first look for /lib/modules/$(uname -r)/$FIRMWARE, then /lib/modules/$FIRMWARE, and no other locations. Translating it to sh, it does approximately this:
echo -n 1 > /sys/$DEVPATH/loading
cat /lib/firmware/$(uname -r)/$FIRMWARE > /sys/$DEVPATH/data \
|| cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
if [ $? = 0 ]; then
echo -n 1 > /sys/$DEVPATH/loading
echo -n -1 > /sys/$DEVPATH/loading
fi
which is exactly the format the kernel expects.
To make a long story short: Ubuntu's udev package has customizations that always look in /lib/firmware/$(uname -r) first. This policy is being handled in userspace.
Wow this is very useful information and it led me to the solution for my problem when making a custom USB kernel module for a device requiring firmware.
Basically, every Ubuntu brings a new rehash of hal,sysfs,devfs,udev,and so on...and things just change. In fact I read they stopped using hal.
So let's reverse engineer this yet again so it's pertinent to the latest [Ubuntu] systems.
On Ubuntu Lucid (the latest at time of writing), /lib/udev/rules.d/50-firmware.rules is used. This file calls the binary /lib/udev/firmware, where magic happens.
Listing: /lib/udev/rules.d/50-firmware.rules
# firmware-class requests, copies files into the kernel
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
The magic should be something along these lines (source: Linux Device Drivers, 3rd Ed., Ch. 14: The Linux Device Model):
echo 1 to loading
copy firmware to data
on failure, echo -1 to loading and halt firmware loading process
echo 0 to loading (signal the kernel)
then, a specific kernel module receives the data and pushes it to the device
If you look at Lucid's source page for udev, in udev-151/extras/firmware/firmware.c, the source for that firmware /lib/udev/firmware binary, that's exactly what goes on.
Excerpt: Lucid source, udev-151/extras/firmware/firmware.c
util_strscpyl(datapath, sizeof(datapath), udev_get_sys_path(udev), devpath, "/data", NULL);
if (!copy_firmware(udev, fwpath, datapath, statbuf.st_size)) {
err(udev, "error sending firmware '%s' to device\n", firmware);
set_loading(udev, loadpath, "-1");
rc = 4;
goto exit;
};
set_loading(udev, loadpath, "0");
Additionally, many devices use an Intel HEX format (textish files containing checksum and other stuff) (wiki it i have no reputation and no ability to link). The kernel program ihex2fw (called from Makefile in kernel_source/lib/firmware on .HEX files) converts these HEX files to an arbitrary-designed binary format that the Linux kernel then picks up with request_ihex_firmware, because they thought reading text files in the kernel was silly (it would slow things down).
On current Linux systems, this is handled via udev and the firmware.agent.
Linux 3.5.7 Gentoo, I have the same issue.
SOLVED:
emerge ipw2200-firmware
Then go to /usr/src/linux
make menucofig
on device driver, remove all wirless drivers don't needed, set Intell 2200 as module and recompile.
make
make modules_install
cp arch/x86/boot/bzImage /boot/kernel-yourdefault