From: Ian M. <im...@gm...> - 2005-03-18 03:18:30
|
Hi there, I've been watching the discussion around 2.6.11 and reading the archives and I can't find the information with any clarity that I need. My problem is that I can't get UML to compile. I can on 2.4.27 (with the standard patches) and with 2.6.10 also. My environment is Debian Woody with 2.4.27 kernel. My gcc version is 2.95.4. I am using default options when I do 'make menu_config ARCH=um' Here is the error that I am experiencing once I do 'make linux ARCH=um': arch/um/kernel/sys_call_table.c:277: duplicate array index in initializer arch/um/kernel/sys_call_table.c:277: (near initialization for `sys_call_table') arch/um/kernel/sys_call_table.c:277: duplicate array index in initializer arch/um/kernel/sys_call_table.c:277: (near initialization for `sys_call_table') The code at line 277 is: ARCH_SYSCALLS [ LAST_SYSCALL + 1 ... NR_syscalls ] = (syscall_handler_t *) sys_ni_syscall I don't quite understand this as it surpasses my C knowledge but if I do a dirty hack and change this to: [ LAST_SYSCALL + 1 ... NR_syscalls ] = (syscall_handler_t *) sys_ni_syscall i.e. remove ARCH_SYSCALS it compiles. However when it goes to finish off and link I then get this error message arch/um/kernel/built-in.o: In function `do_buffer_op': arch/um/kernel/built-in.o(.text+0xcf4a): undefined reference to `va_copy' arch/um/kernel/built-in.o(.data+0x1570): undefined reference to `sys_vserver' and I don't have a linux kernel. Can anybody point me in the right direction? Regards, Ian |
From: Rob L. <ro...@la...> - 2005-03-18 04:43:44
|
On Thursday 17 March 2005 10:18 pm, Ian McDonald wrote: > Hi there, > > I've been watching the discussion around 2.6.11 and reading the > archives and I can't find the information with any clarity that I > need. My problem is that I can't get UML to compile. I can on 2.4.27 > (with the standard patches) and with 2.6.10 also. All I have to do, on x86 under either Knoppix or Red Hat, is (this is off the top of my head, so there might be a typo or two): tar xvjf linux-2.6.11.tar.bz2 cd linux-2.6.11 # Get a usable .config file, you can use "make ARCH=um menuconfig" for this # if you know what to select. This adds a more or less minimal set of options # to allnoconfig to provide a usable test system. Later, you'll want to add # thinks like loopback support, UBD, ext2, maybe swap support... make ARCH=um allnoconfig cat >> .config << EOF CONFIG_MODE_TT=y CONFIG_LD_SCRIPT_STATIC=y CONFIG_BINFMT_ELF=y CONFIG_HOSTFS=y CONFIG_STDERR_CONSOLE=y CONFIG_LBD=y CONFIG_PROC_FS=y EOF yes "" | make ARCH=um oldconfig # Now build it. make ARCH=um # Run it. Later you might want to add "rootflags" (defaults to rootflags=/) # and "mem" (defaults to mem=32M). "quiet" is nice too... ./linux rootfstype=hostfs rw init=/bin/sh # Show that the new shell prompt is under UML, not the parent system. mount -t proc /proc /proc cat /proc/cpuinfo The polite way to exit is either "shutdown -n" or "halt -f" (both in sbin, which isn't int he path), but when pid 1 is /bin/sh then just "exit" will work as well if you don't mind a UML panic message about "tried to kill init"... Speaking of path: the default UML path ends with ".", and if you try to compile anything this triggers some "holier than thou" code in gcc that ignores the entire path without even a warning message because it thinks it knows better than you, and thus doesn't find the linker. Just set your PATH to "/sbin:/usr/sbin:/bin:/usr/bin" and it should work fine. (Why this isn't the default, I have no idea...) > My environment is Debian Woody with 2.4.27 kernel. My gcc version is > 2.95.4. I am using default options when I do 'make menu_config > ARCH=um' There's no underscore in menuconfig. > Here is the error that I am experiencing once I do 'make linux ARCH=um': > arch/um/kernel/sys_call_table.c:277: duplicate array index in initializer > arch/um/kernel/sys_call_table.c:277: (near initialization for > `sys_call_table') arch/um/kernel/sys_call_table.c:277: duplicate array > index in initializer arch/um/kernel/sys_call_table.c:277: (near > initialization for `sys_call_table') I remember a problem like that in one of the 2.6.11-pre releases, but it was fixed in the final 2.6.11. What compiler version are you using? > The code at line 277 is: > ARCH_SYSCALLS > [ LAST_SYSCALL + 1 ... NR_syscalls ] = > (syscall_handler_t *) sys_ni_syscall > > I don't quite understand this as it surpasses my C knowledge but if I > do a dirty hack and change this to: Yeah, I did too. It was fixed before the 2.6.11 release. Are you sure you're building 2.6.11 sources? > Can anybody point me in the right direction? You're sure you're using linux-2.6.11.tar.bz2 on x86? > Regards, > > Ian Rob |
From: Ian M. <im...@gm...> - 2005-03-18 06:34:19
|
I was doing all that you said here and without the typo for menuconfig that I put in... I am running x86 and gcc 2.95.4 - I am suspecting the gcc may be an issue but maybe I should also pull down the kernel from another mirror in case my mirror is not good that I am using... On Thu, 17 Mar 2005 22:40:54 -0500, Rob Landley <ro...@la...> wrote: > On Thursday 17 March 2005 10:18 pm, Ian McDonald wrote: > > Hi there, > > > > I've been watching the discussion around 2.6.11 and reading the > > archives and I can't find the information with any clarity that I > > need. My problem is that I can't get UML to compile. I can on 2.4.27 > > (with the standard patches) and with 2.6.10 also. > > All I have to do, on x86 under either Knoppix or Red Hat, is (this is off the > top of my head, so there might be a typo or two): > > tar xvjf linux-2.6.11.tar.bz2 > cd linux-2.6.11 > # Get a usable .config file, you can use "make ARCH=um menuconfig" for this > # if you know what to select. This adds a more or less minimal set of options > # to allnoconfig to provide a usable test system. Later, you'll want to add > # thinks like loopback support, UBD, ext2, maybe swap support... > make ARCH=um allnoconfig > cat >> .config << EOF > CONFIG_MODE_TT=y > CONFIG_LD_SCRIPT_STATIC=y > CONFIG_BINFMT_ELF=y > CONFIG_HOSTFS=y > CONFIG_STDERR_CONSOLE=y > CONFIG_LBD=y > CONFIG_PROC_FS=y > EOF > yes "" | make ARCH=um oldconfig > # Now build it. > make ARCH=um > # Run it. Later you might want to add "rootflags" (defaults to rootflags=/) > # and "mem" (defaults to mem=32M). "quiet" is nice too... > ./linux rootfstype=hostfs rw init=/bin/sh > # Show that the new shell prompt is under UML, not the parent system. > mount -t proc /proc /proc > cat /proc/cpuinfo > > The polite way to exit is either "shutdown -n" or "halt -f" (both in sbin, > which isn't int he path), but when pid 1 is /bin/sh then just "exit" will > work as well if you don't mind a UML panic message about "tried to kill > init"... > > Speaking of path: the default UML path ends with ".", and if you try to > compile anything this triggers some "holier than thou" code in gcc that > ignores the entire path without even a warning message because it thinks it > knows better than you, and thus doesn't find the linker. Just set your PATH > to "/sbin:/usr/sbin:/bin:/usr/bin" and it should work fine. (Why this isn't > the default, I have no idea...) > > > My environment is Debian Woody with 2.4.27 kernel. My gcc version is > > 2.95.4. I am using default options when I do 'make menu_config > > ARCH=um' > > There's no underscore in menuconfig. > > > Here is the error that I am experiencing once I do 'make linux ARCH=um': > > arch/um/kernel/sys_call_table.c:277: duplicate array index in initializer > > arch/um/kernel/sys_call_table.c:277: (near initialization for > > `sys_call_table') arch/um/kernel/sys_call_table.c:277: duplicate array > > index in initializer arch/um/kernel/sys_call_table.c:277: (near > > initialization for `sys_call_table') > > I remember a problem like that in one of the 2.6.11-pre releases, but it was > fixed in the final 2.6.11. What compiler version are you using? > > > The code at line 277 is: > > ARCH_SYSCALLS > > [ LAST_SYSCALL + 1 ... NR_syscalls ] = > > (syscall_handler_t *) sys_ni_syscall > > > > I don't quite understand this as it surpasses my C knowledge but if I > > do a dirty hack and change this to: > > Yeah, I did too. It was fixed before the 2.6.11 release. Are you sure you're > building 2.6.11 sources? > > > Can anybody point me in the right direction? > > You're sure you're using linux-2.6.11.tar.bz2 on x86? > > > Regards, > > > > Ian > > Rob > |
From: Rob L. <ro...@la...> - 2005-03-19 00:45:02
|
On Thursday 17 March 2005 10:18 pm, Ian McDonald wrote: > Hi there, > > I've been watching the discussion around 2.6.11 and reading the > archives and I can't find the information with any clarity that I > need. My problem is that I can't get UML to compile. I can on 2.4.27 > (with the standard patches) and with 2.6.10 also. > > My environment is Debian Woody with 2.4.27 kernel. My gcc version is > 2.95.4. I am using default options when I do 'make menu_config > ARCH=um' > > Here is the error that I am experiencing once I do 'make linux ARCH=um': > arch/um/kernel/sys_call_table.c:277: duplicate array index in initializer > arch/um/kernel/sys_call_table.c:277: (near initialization for > `sys_call_table') arch/um/kernel/sys_call_table.c:277: duplicate array > index in initializer arch/um/kernel/sys_call_table.c:277: (near > initialization for `sys_call_table') > > The code at line 277 is: > ARCH_SYSCALLS > [ LAST_SYSCALL + 1 ... NR_syscalls ] = > (syscall_handler_t *) sys_ni_syscall ARCH_SYSCALLS is defined in arch/um/include/sysdep-i386/syscalls.h by the way... In case you wanted to try to find which syscall was going "boing" for you... grep is your friend. :) Rob |
From: Rob L. <ro...@la...> - 2005-03-19 00:45:59
|
Ah, nevermind. Check out Anton's message. You were using a -bk snapshot rather than the officially 2.6.11 release, I take it? Rob |
From: Peter <pet...@ri...> - 2005-03-19 21:31:58
|
Hi. JDK1.4 runs well on UML guests. JDK1.5 does not appear to run well on the UML guests. After the process runs for a bit it ends up sitting at 100% CPU. I have had problems on 2.4 kernels up to 2.6.9 guest kernels. I have reproduced the problem on different guest distros (Debian, FC, and WBEL3). And the problem has been reported by other users on the mailing list here. I do not see this problem on non-UML servers. I am not sure what could be going on. But it seems possible that the Java 1.5 VM is hitting some issue with the UML guest kernel. To reproduce the problem (preferably on a Debian or FC/RHEL based distro) download this: http://downloads.rimuhosting.com/installjava.sh Comment out the 1.4.2 file/dir at the top. Uncomment the 1.5 file/dir variables Run that script (it will install the 1.5 JDK). Download and run http://downloads.rimuhosting.com/installtomcat5.sh It will install tomcat5.5.7 under /usr/local/tomcat. Add a tomcat user. And an /etc/init.d/tomcat stop/start/kill script. Start tomcat with /etc/init.d/tomcat start Run ab (ab is part of apache) like this: ab -c 10 -n 10000 http://localhost:8080/jsp-examples/jsp2/tagfiles/products.jsp Eventually the Java process will max out the CPU. Usually after 200-2000 requests. "jstack $parentjavapid" will show the Java code that is executing. Not that helpful. strace on the java pids don't seem to show/help much. Your help reproducing and resolving this problem would be greatly appreciated. Regards, Peter |
From: Ian M. <im...@gm...> - 2005-03-21 04:43:57
|
OK after much further investigation, redownloading of source (2.6.11.4) and looking at what you have said I know why it is breaking.... I had assumed (wrongly of course) that ARCH_SYSCALLS was a one line symbol definition but it is much more than this. The problem occurs because in both arch/um/include/sysdep-i386/syscalls.h and in arch/um/kernel/sys_call_table.c a number of the elements are defined in BOTH files. I presume the reason why this doesn't break others systems is that they are not using the same version of gcc as me (2.95.4). I would guess that with a later gcc in an enum you can redefine an element and it doesn't complain... Anyway I believe the proper fix is to delete the lines from arch/um/kernel/sys_call_table.c and here is a patch to do that: 255d254 < [ __NR_statfs64 ] = (syscall_handler_t *) sys_statfs64, 258,260d256 < [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, < [ __NR_fadvise64_64 ] = (syscall_handler_t *) sys_fadvise64_64, < [ __NR_vserver ] = (syscall_handler_t *) sys_vserver, Can somebody verify that and if correct submit to whoever (this is my first ever attempt at fixing something in the kernel so not quite sure what to do next!!) Regards, Ian PS still have some linking issues and I will report on them as I work out why.... On Fri, 18 Mar 2005 18:43:05 -0500, Rob Landley <ro...@la...> wrote: > Ah, nevermind. Check out Anton's message. You were using a -bk snapshot > rather than the officially 2.6.11 release, I take it? > > Rob > |
From: Peter <pet...@ri...> - 2005-03-21 05:13:52
|
linux-2.4.27.tar.bz2 + uml-2.4.27-bs2-pre6.patch.bz2 patches with no error. But I get the error below compile. It seems like the UML code is passing in a mm as the first arg and the only definitions of `do_mmap_pgoff' I can find start with a file arg and have no mm. I dropped the mm arg in the code, and it then compiles OK. But segfaults immediately on use. I'm not sure if that is caused by my code change or not. BTW: what is the current recommendation for a 'stable' 2.4 UML guest kernel? Regards, Peter gcc -D__KERNEL__ -I/usr/src/uml/linux-2.4.27-rimu2/linux-2.4.27/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing-fno-common -U__i386__ -Ui386 -DUM_FASTCALL -g -D__arch_um__ -DSUBARCH="i386" -D_LARGEFILE64_SOURCE -I/usr/src/uml/linux-2.4.27-rimu2/linux-2.4.27/arch/um/include -Derrno=kernel_errno -I/usr/src/uml/linux-2.4.27-rimu2/linux-2.4.27/arch/um/kernel/skas/include -nostdinc -iwithprefix include -DKBUILD_BASENAME=syscall_kern -c -o syscall_kern.o syscall_kern.c syscall_kern.c: In function `do_mmap2': syscall_kern.c:82: warning: passing arg 1 of `do_mmap_pgoff' from incompatible pointer type syscall_kern.c:82: warning: passing arg 2 of `do_mmap_pgoff' makes integer from pointer without a cast syscall_kern.c:82: too many arguments to function `do_mmap_pgoff' make[2]: *** [syscall_kern.o] Error 1 relevant code: /* common code for old and new mmaps */ long do_mmap2(struct mm_struct *mm, unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff) { int error = -EBADF; struct file * file = NULL; flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE); if (!(flags & MAP_ANONYMOUS)) { file = fget(fd); if (!file) goto out; } down_write(&mm->mmap_sem); error = do_mmap_pgoff(mm, file, addr, len, prot, flags, pgoff); up_write(&mm->mmap_sem); if (file) fput(file); out: return error; } |
From: Blaisorblade <bla...@ya...> - 2005-03-22 17:54:03
|
On Monday 21 March 2005 06:13, Peter wrote: > linux-2.4.27.tar.bz2 + uml-2.4.27-bs2-pre6.patch.bz2 patches with no > error. > But I get the error below compile. It seems like the UML code > is passing in a mm as the first arg and the only definitions of > `do_mmap_pgoff' I can find start with a file arg and have no mm. I > dropped the mm arg in the code, and it then compiles OK. But segfaults > immediately on use. I'm not sure if that is caused by my code change or > not. No, your code change is correct... in fact is what I have in my local tree. The only problem I recall is with GCC 3.3.2 from Mandrake 10.0, which miscompiles any UML/2.4 (but not UML/2.6). I've never found out why. > BTW: what is the current recommendation for a 'stable' 2.4 UML guest > kernel? Hmm, I *have* to release the -bs2 sooner or later... the hostfs support is surely better in -bs1, for the rest 2.4.27-um1 is slightly better > Regards, Peter -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Ian M. <im...@gm...> - 2005-03-21 05:30:36
|
The other problem with not linking va_copy has been resolved by changing to __va_copy in skas/uaccess.c. This seems to be a known problem with older compilers and there is a patch out there but not in 2.6.11 or by the looks of it 2.6.12 rc1 by my reading of the log (nor for one for my previous e-mail) On Mon, 21 Mar 2005 16:43:54 +1200, Ian McDonald <im...@gm...> wrote: > OK after much further investigation, redownloading of source > (2.6.11.4) and looking at what you have said I know why it is > breaking.... > > I had assumed (wrongly of course) that ARCH_SYSCALLS was a one line > symbol definition but it is much more than this. > > The problem occurs because in both > arch/um/include/sysdep-i386/syscalls.h and in > arch/um/kernel/sys_call_table.c a number of the elements are defined > in BOTH files. > > I presume the reason why this doesn't break others systems is that > they are not using the same version of gcc as me (2.95.4). I would > guess that with a later gcc in an enum you can redefine an element and > it doesn't complain... > > Anyway I believe the proper fix is to delete the lines from > arch/um/kernel/sys_call_table.c and here is a patch to do that: > > 255d254 > < [ __NR_statfs64 ] = (syscall_handler_t *) sys_statfs64, > 258,260d256 > < [ __NR_utimes ] = (syscall_handler_t *) sys_utimes, > < [ __NR_fadvise64_64 ] = (syscall_handler_t *) sys_fadvise64_64, > < [ __NR_vserver ] = (syscall_handler_t *) sys_vserver, > > Can somebody verify that and if correct submit to whoever (this is my > first ever attempt at fixing something in the kernel so not quite sure > what to do next!!) > > Regards, > > Ian > > PS still have some linking issues and I will report on them as I work > out why.... > > On Fri, 18 Mar 2005 18:43:05 -0500, Rob Landley <ro...@la...> wrote: > > Ah, nevermind. Check out Anton's message. You were using a -bk snapshot > > rather than the officially 2.6.11 release, I take it? > > > > Rob > > > |
From: Blaisorblade <bla...@ya...> - 2005-03-24 11:04:44
|
On Monday 21 March 2005 06:30, Ian McDonald wrote: > The other problem with not linking va_copy has been resolved by > changing to __va_copy in skas/uaccess.c. This seems to be a known > problem with older compilers and there is a patch out there but not in > 2.6.11 or by the looks of it 2.6.12 rc1 by my reading of the log (nor > for one for my previous e-mail) Ok, I'm taking that patch and merging it in my tree and in 2.6.12. I hope it can go also in 2.6.11.6 (or .7, whatever). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Ian M. <im...@gm...> - 2005-04-08 04:04:21
|
On Mar 24, 2005 11:03 PM, Blaisorblade <bla...@ya...> wrote: > On Monday 21 March 2005 06:30, Ian McDonald wrote: > > The other problem with not linking va_copy has been resolved by > > changing to __va_copy in skas/uaccess.c. This seems to be a known > > problem with older compilers and there is a patch out there but not in > > 2.6.11 or by the looks of it 2.6.12 rc1 by my reading of the log (nor > > for one for my previous e-mail) > Ok, I'm taking that patch and merging it in my tree and in 2.6.12. I hope it > can go also in 2.6.11.6 (or .7, whatever). > > -- > Paolo Giarrusso, aka Blaisorblade > Linux registered user n. 292729 > http://www.user-mode-linux.org/~blaisorblade > Here is an update: 2.6.12-rc2 has both va_copy patch and syscall patch and works for me once a patch is applied to arch/um/kernel/Makefile for some sed syntax 2.6.11.7 has va_copy patch only and works for me once I apply the syscall patch that I started and Paolo made much better. Environment is Debian Woody, gcc 2.95.4, sed 3.02 Thanks again for all involved in helping me to this state. |
From: Blaisorblade <bla...@ya...> - 2005-04-08 04:18:42
|
On Friday 08 April 2005 06:04, Ian McDonald wrote: > On Mar 24, 2005 11:03 PM, Blaisorblade <bla...@ya...> wrote: > > On Monday 21 March 2005 06:30, Ian McDonald wrote: > > > The other problem with not linking va_copy has been resolved by > > > changing to __va_copy in skas/uaccess.c. This seems to be a known > > > problem with older compilers and there is a patch out there but not in > > > 2.6.11 or by the looks of it 2.6.12 rc1 by my reading of the log (nor > > > for one for my previous e-mail) > > > > Ok, I'm taking that patch and merging it in my tree and in 2.6.12. I hope > > it can go also in 2.6.11.6 (or .7, whatever). > > > > -- > > Paolo Giarrusso, aka Blaisorblade > > Linux registered user n. 292729 > > http://www.user-mode-linux.org/~blaisorblade > > Here is an update: > 2.6.12-rc2 has both va_copy patch and syscall patch and works for me > once a patch is applied to arch/um/kernel/Makefile for some sed syntax > 2.6.11.7 has va_copy patch only and works for me once I apply the > syscall patch that I started and Paolo made much better. I've sent it for merging, and I hope it will be in .8. > Environment is Debian Woody, gcc 2.95.4, sed 3.02 > > Thanks again for all involved in helping me to this state. I'll put these changes also in the -bs tree. Actually, -bs1 should work for you because has the syscall and va_copy changes; -bb2 does not work because I merged the sed usage which bites you. I'll now merge the sed fix for -bs3. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |