On Fri, Feb 19, 2010 at 12:41:09PM +0100, Jakob Lell wrote: > Hi, > I am trying to get vserver work on the armel architecture. The hardware > used is a Marvell SheevaPlug with Debian Squeeze. > The first step was to compile the kernel. This only required adding one > missing "#include <linux/vs_memory.h>" to arch/arm/include/asm/tlb.h > after the line " #else /* !CONFIG_MMU */". With this small fix, the > kernel compiles and boots without any errors. good, will add that to the next release > The next thing to do is the userspace utility. The main problem here is > that the ABI for calling linux system calls has changed. I've attached a > patch which fixes this with an appropriate #ifdef. The program compiles > fine with this patch and system calls seem to work. Since dietlibc is > not yet working on armel, I had to compile util-vserver with glibc. I > could already create a new vserver using the following command (before > doing /etc/init.d/util-vserver start): > vserver test build -m debootstrap --hostname test --rootdir /mnt/stick/ > --interface eth0:192.168.1.21/24 -- -d lenny > However, starting the vserver using "vserver test start" fails with the > following error message: > /proc/uptime can not be accessed. Usually, this is caused by > procfs-security. Please read the FAQ for more details > http://linux-vserver.org/Proc-Security what util-vserver version? > After running "/etc/init.d/util-vserver start", trying to start the > vserver using "vserver test start" fails with a different error message: > vspace: clone(): No space left on device > Here is the strace output line of the failing clone system call: > clone(child_stack=0, flags=CLONE_VFORK|CLONE_NEWNS|SIGCHLD) = -1 ENOSPC > (No space left on device) > Some debugging in /etc/init.d/util-vserver showed that this problem > occurs after running the mount_cgroup function. Have you got any hints > about how to resolve this problem? hmm, cgroup support is working on that arch? i.e. could you verify that with a vanilla kernel? > I've now finally found a workaround: When running > "/etc/init.d/vprocunhide start" and not "/etc/init.d/util-vserver > start", it is possible to start and use the vserver. When doing so, the > clone system call works successfully even though it uses exactly the > same parameters as the failing call above: > clone(child_stack=0, flags=CLONE_VFORK|CLONE_NEWNS|SIGCHLD) = 7149 looks like it works without the cgroup stuff ... good work! best, Herbert > Regards > Jakob Lell > > Index: lib/syscall-alternative.h > =================================================================== > --- lib/syscall-alternative.h (revision 2877) > +++ lib/syscall-alternative.h (working copy) > @@ -90,9 +90,35 @@ > > #elif defined(__arm__) > > +#ifdef __ARM_EABI__ > + > /* The Arm calling convention uses stack args after four arguments > but the Linux kernel gets up to seven arguments in registers. > > + scnr: r7 > + args: a1(r0), a2(r1), a3(r2), a4(r3), a5(r4), a6(r5), > + sret: r0(r0) > + serr: (sret >= (unsigned)-EMAXERRNO) > + call: swi > + clob: memory > + move: mov $dR,$sR > +*/ > + > +#define __sysc_max_err 125 > + > +#define __sysc_cmd(n) "swi $0x0" > + > +#define __sysc_regs "r0", "r1", "r2", "r3", "r4", "r5" > +#define __sysc_reg_cid "r7" > +#define __sysc_reg_ret "r0" > + > +#warning syscall arch armel not tested yet > + > +#else > + > +/* The Arm calling convention uses stack args after four arguments > + but the Linux kernel gets up to seven arguments in registers. > + > scnr: imm > args: a1(r0), a2(r1), a3(r2), a4(r3), a5(r4), a6(r5), > sret: r0(r0) > @@ -111,6 +137,7 @@ > > #warning syscall arch arm not tested yet > > +#endif > > > /* *****************************************