[00:13] Bertl : what i sup with the 17g stuff? :> any goodies? [00:13] 17g is the new syscall switch .. which allows future enhancements ;) [00:22] bye to all [00:23] by alex! [00:23] i want to sleep :) [00:23] maybe we talk about the syscall switch tomorrow ... [00:23] okey :) [00:23] shadow (~umka@212.86.233.226) left irc: Quit: bye to all [00:23] sleep well ... [01:15] Nick change: riel -> unriel [02:07] Bertl :D [02:08] hi simon! [02:13] I had some trouble with those rmap patches still... [02:13] lets hear ... [02:14] Nick change: surriel -> riel [02:15] maybe rik can provide some infos too ;) [02:18] ok, with patch-2.4.22-c17e-rmap15k-mq0.11.diff and patch-2.4.22-c17e-rmap15k.diff I get some compile errors... one moment [02:18] this is with patch-2.4.22-c17f.diff which works fine [02:19] gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-ctx-test/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -finline-limit=2000 -fno-strength-reduce -Wno-sign-compare -fno-asynchronous-unwind-tables -nostdinc -iwithprefix include -DKBUILD_BASENAME=init -c -o init.o init.c [02:19] init.c:44: error: syntax error before numeric constant [02:19] init.c:47: warning: type defaults to `int' in declaration of `ret__' [02:19] init.c:47: warning: data definition has no type or storage class [02:19] init.c:47: warning: type defaults to `int' in declaration of `ret__' [02:19] init.c:47: warning: data definition has no type or storage class [02:19] init.c:47: error: syntax error before '}' token [02:19] that's repeated several times, for lines 47, 49, 53, 57 and 61 [02:20] okay, this is now what kernel, and what patches exactly? [02:20] see above... 2.4.22 vanilla with 3 vs patches [02:20] 01patch-2.4.22-c17f.diff + patch-2.4.22-c17e-rmap15k-mq0.11.diff + 01patch-2.4.22-c17e-rmap15k.diff [02:20] 2.4.22, patch-2.4.22-c17e-rmap15k.diff, patch-2.4.22-c17f.diff, and patch-2.4.22-c17e-rmap15k-mq0.11.diff ? [02:20] yup ;) [02:21] all patches apply cleanly [02:21] okay, just a few minutes, I'll have a look at it, could you provide your kernel config somewhere? [02:22] okey [02:22] http://www.expio.co.nz/~sgarner/terra/.config [02:34] hmm, that is the config you used? [02:35] what platform is this? [02:35] x86_64... [02:36] (opteron) [02:36] hmm okay ... [02:36] did you try without the patch-2.4.22-c17e-rmap15k-mq0.11.diff [02:37] ok I'll try [02:37] I assume the problem is with the rmap15k ... but .. [02:39] by the way, did you find some time to test the c17g on x86_64 ? [02:40] I get the same problem without mq0.11 [02:40] where can I get c17g? [02:41] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre7-c17g.diff.bz2 [02:41] it would be interesting, because this uses the new syscall switch, and I would like to make sure it works on x86_64 ... [02:42] you'll need the http://vserver.13thfloor.at/Experimental/util-vserver-0.23.90.2.tar.bz2 tools, except for that, it should be equivalent to c17f ... [02:46] okay you have to help me with that, as I don't get this error (it seems x86_64 specific) ... [02:48] probably :) [02:48] hi [02:48] any news? [02:48] do a make clean on the rmap15k patched kernel and save the output of make bzImage to some file ... [02:48] oh, that c17g is 2.4.23... :( [02:48] it can be 2.4.22 too, any problems with 2.4.23? [02:49] nah I'll just have to go grab the patch-2.4.23 :) [02:49] hi matt! [02:49] I avoided it because it's still -test [02:49] er, -pre even [02:49] well, you don't have to use it, just verify that it works ;) [02:50] will do :) [02:50] thanks in advance ... [02:50] let me know when/where I can grab the compile output of the rmap15k run .. okay? [02:51] one moment [02:52] what compiler is this by the way (version?) [02:52] 3.3.1? [02:52] hmm, I avoided 3.x for kernel compiles, but this should not be the issue ... [03:01] http://www.expio.co.nz/~sgarner/terra/make.txt [03:08] okay try to modify the line 44 in arch/x86_64/mm/init.c ... use some other name for the function and the arguments (one change after the other) and see if the error changes ... [03:10] hmm [03:10] init.c: In function `do_check_pgt_cache_blah': [03:10] init.c:50: warning: implicit declaration of function `pgd_free_slow' [03:10] init.c:50: warning: implicit declaration of function `pgd_alloc_one_fast' [03:10] init.c:54: warning: implicit declaration of function `pmd_free_slow' [03:10] init.c:58: warning: implicit declaration of function `pte_free_slow' [03:10] then it's continuing... [03:10] okay so some include overrides the name ;) [03:11] ah [03:11] arch/x86_64/mm/mm.o(.text+0x33): In function `do_check_pgt_cache_blah': [03:11] : undefined reference to `pgd_alloc_one_fast' [03:11] arch/x86_64/mm/mm.o(.text+0x3c): In function `do_check_pgt_cache_blah': [03:11] : undefined reference to `pgd_free_slow' [03:11] arch/x86_64/mm/mm.o(.text+0x55): In function `do_check_pgt_cache_blah': [03:11] : undefined reference to `pmd_free_slow' [03:11] arch/x86_64/mm/mm.o(.text+0x6e): In function `do_check_pgt_cache_blah': [03:11] : undefined reference to `pte_free_slow' [03:11] make: *** [vmlinux] Error 1 [03:11] that is okay ... [03:11] was just a check ... [03:11] yup, now try changing the args? [03:12] guess this should not be necessary ... [03:12] linux-2.4.22-c17f-rmap15k/include/asm-x86_64/pgalloc.h:#define do_check_pgt_cache(x,y)(0) [03:12] that is the bad definition .. just try to remove it ... [03:13] hmm better replace it by [03:13] extern int do_check_pgt_cache(int, int); [03:13] put the other line back? [03:13] yeah, sorry ... [03:14] it seems that the rmap patch added this function, but didn't remove the dummy macro .... [03:14] ah okay [03:15] so this line in pgalloc.h [03:15] #define do_check_pgt_cache(x,y) (0) [03:15] I change to [03:15] 01extern int do_check_pgt_cache(int, int); [03:15] ? [03:15] extern int do_check_pgt_cache(int, int); [03:16] ok if you say so ;) [03:16] arch/x86_64/mm/mm.o(.text+0x33): In function `do_check_pgt_cache': [03:16] : undefined reference to `pgd_alloc_one_fast' [03:16] arch/x86_64/mm/mm.o(.text+0x3c): In function `do_check_pgt_cache': [03:16] : undefined reference to `pgd_free_slow' [03:16] arch/x86_64/mm/mm.o(.text+0x55): In function `do_check_pgt_cache': [03:16] : undefined reference to `pmd_free_slow' [03:16] arch/x86_64/mm/mm.o(.text+0x6e): In function `do_check_pgt_cache': [03:16] : undefined reference to `pte_free_slow' [03:16] make: *** [vmlinux] Error 1 [03:17] okay .. guess this is because rmap15k doesn't support x86_64 ... give me a few minutes ... [03:18] sure [03:19] ok, I suspect I need to move some stuff from another taroon patch into the -rmap tree [03:19] I'm not running taroon any more [03:20] this is with Mandrake 9.2 [03:20] dont worry, it's a problem that is rmap specific ... [03:20] yeah, but part of the amd64 -rmap support is in a different patch inside Taroon [03:20] I just need to copy those changes into -rmap [03:20] that's all [03:21] ok :) [03:22] will take some time, just leave rmap out for the moment, if possible ... [03:22] remind me of this on monday ;) [03:32] ok, testing c17g now [03:32] great! [03:35] hmm I get a [03:35] include/linux/virtual.h:26:1: warning: "VC_VERSION" redefined [03:35] for every file compiled... [03:35] okay, I'll look into that ... [03:36] that was with the pre patch and c17g only correct? [03:36] yes [03:38] bah I keep getting acpi errors [03:38] and I've disabled acpi :/ [03:38] with acpi=noacpi or in the kernel compile? [03:38] in the compile [03:39] it's an SMP system, correct? [03:39] yes [03:39] there you can't disable some parts of ACPI (for enumeration, etc IIRC) [03:40] yeah... I get errors with acpi enabled as well though... *shrug* [03:40] in 2.4.22 I had to compile with ACPI enabled and only "CPU Enumeration Only" (or somesuch), but that's not an option now [03:41] yeah, they're still discussing where that option should go ;) [03:42] serving (~serving@213.186.191.131) left irc: Ping timeout: 480 seconds [03:43] they could have discussed it without removing it... :/ [03:47] hmm, just enabling ACPI and no button, fan, processor etc worked [03:47] and the c17g caused no problems ;) [03:47] so far... [03:47] up and running? [03:47] installing now [03:48] okay, the VC_VERSION issue will be resolved in the next version ... [03:48] rebooting... [03:48] ok :) [03:50] booted! [03:50] even better ... ;) [03:50] # tail /proc/self/status [03:50] CapInh: 0000000000000000 [03:50] CapPrm: 00000000fffffeff [03:50] CapEff: 00000000fffffeff [03:50] CapBset: 00000000fffffeff [03:50] s_context: 0 [03:50] ctxticks: none [03:50] ctxflags: none [03:50] initpid: none [03:50] ipv4root: 0 [03:50] ipv4root_bcast: 0 [03:51] looks good, now the tools? [03:51] Im using util-vserver-0.23.90.2 [03:52] okay, please try chcontext and chbind ... [03:52] or simply start a vserver ;) [03:52] vserver .. build doesn't seem to work too well any more [03:52] it doesnt copy bin, lib or usr [03:53] I guess this isn't kernel related ... [03:54] well no ;) [03:54] how do I delete the proc directory in a vs? (to delete the vs) [03:55] umount usually ... [03:55] yes, 'vserver .. build' does not copy the root filesystem anymore [03:55] oh yep [03:55] this is indentionally [03:55] hmm, so I have to build the vserver manually? [03:56] new versions of will have improved methods using apt-get, but this is still in alpha state [03:57] what's an easy way to test chcontext and chbind without making a vs then? [03:57] chcontext --ctx 999 cat /proc/self/status [03:58] chbind --ip 192.168.0.1 true [03:58] New security context is 999 [03:58] ... [03:58] ipv4root: 0 [03:58] ipv4root_bcast: 0 [03:58] ipv4root is now 192.168.1.10 [03:58] so it works ;D [03:58] looks good yes ... [03:59] thanks for testing ... [03:59] no problem [03:59] which patches would you suggest for 'production' use? [03:59] c17f [03:59] and quotas? [03:59] if you need quota/disk limits then the latest ... [04:00] which are? [04:00] mq0.11, cx0.06, cq0.11, dl0.05 [04:01] VM limits should be okay too ... [04:01] vr0.13 for security ... [04:03] and some of the fixes in my patchsets ... [04:12] serving (~serving@213.186.190.120) joined #vserver. [04:20] which patch is vr0.13? [04:20] you mean what it does, or where it is? [04:21] yes [04:21] where it is ;) [04:21] http://vserver.13thfloor.at/Experimental/patch-2.4.22-ctx17a-vr0.13.diff.bz2 [04:23] ok, so Im going to use 2.4.22 with: [04:23] patch-2.4.22-c17f.diff [04:23] patch-2.4.22-c17e-mq0.11-cx0.06-cq0.11-dl0.05.diff [04:23] patch-2.4.22-ctx17a-vr0.13.diff [04:24] well you need mq0.11, cx0.06 and cq0.11 for dl to work ... [04:24] oh I see [04:24] hmm, strictly speaking cq0.11 isn't required ... [04:25] what is cq again? [04:25] cq is context quota ... [04:26] so if I want quotas... I'd need that surely? [04:26] if you want per context quota or the disk limits ... yes ... [04:27] I could make a dl version which doesn't require most parts of mq0.11 and cq0.11 but I don't see any reason for that at the moment ... [04:28] i'll just use them all [04:28] your vservers are on a separate partition? [04:28] yes [04:29] good, you should be avare that the cx patch modifies UID/GID values of files stored on partitions mounted with tagctx ... [04:29] I know ;) [04:29] just wanted to mention it ;) [04:30] the patch naming is very confusing :( [04:30] any better suggestions? [04:30] I guess it just needs a web page explaining them [04:31] that's right ... will do with the vserver-1.0.0 release ... [04:31] cool... how far away is that? [04:31] if possible at the end of this month ... [04:32] I still need some platform feedback for sparc/ppc .. [04:32] ok, well let me know if I can do anything to help [04:32] you already did ... by testing on x86_64 ;) [04:32] ;) [04:34] actually, one easy way you could tidy up the patches would be to put them in different directories... e.g. 2.4.22, 2.4.23, 2.6 etc, then have an 'old' and 'latest' under that for each [04:34] Im getting a headache trying to figure out which is which ;) [04:35] suggestion noted ... [04:36] there is no mq0.11-cx0.06? [04:37] yes, because the mq0.10-cx0.06 is up to date and applies ;) [04:37] oh good ;) [04:51] uhoh [04:51] Can't set the ipv4 root (Invalid argument) [04:52] what kernel, what patches, which tools .. [04:52] oh, wrong tools probably? [04:52] the new ones? [04:52] yeah, with c17f [04:52] they should work ... [04:54] weird because I thought c17f worked by itself... [04:55] try with the older tools, maybe it's a bug in the new ones ... [04:56] which version? [04:57] either the util-vserver-0.23 (no 90) or the vserver-0.24 from jacques ... [04:59] ok, 0.23.6 works :D [05:00] okay, please send a bugreport to enrico ... [05:00] do c17f and c17g use different syscall? [05:00] yes c17g introduces the syscall switch ... [05:00] Simon: what shows strace? [05:01] strace what? [05:01] ahh still awake, good ;) [05:01] Simon: strace [05:02] @enrico this is on x86_64 ... JFYI ... [05:02] ooh... [05:02] but strace should give some hints [05:03] anything in particular to look for, or shall I upload it somewhere [05:03] yes, c17g works with the tools ... [05:03] Simon: what was your command? 'chbind ...'? [05:03] chcontext [05:03] chcontext --ctx 999 cat /proc/self/status [05:03] even [05:04] the ipv4root isn't working ... [05:04] Simon: try 'strace chcontext --ctx -2 true' [05:05] @simon with the 'new' tools on c17f ... [05:05] strace can not follow context-changes in other ctx's [05:05] Simon: s!strace!strace -f! [05:07] http://www.expio.co.nz/~sgarner/terra/util-vserver.txt [05:09] Bertl: the returned version number looks strange [05:09] (0xffffffea) [05:10] well, this is an error code .. c17f doesn't implement the syscall switch ;) [05:10] this is with 0.23.90.2 on c17f [05:13] more precisely it's -EINVAL ... [05:14] hmm, I am checking for ENOSYS [05:14] is 273 used for anything else on x86_64? [05:14] not true, because c17f uses same syscall number ... [05:15] but that explains it ... [05:15] anyway, a negative return value should considered as 'not implemented' for the syscall switch ... [05:16] ok, not nice, but I can change it in this way [05:17] well, just check for -ENOSYS first, then throw an error okay? [05:17] I am throwing an error in the current version [05:17] I agree that it should not happen, and it will not happen except for c17f (warning sorry) [05:18] is 273 a syscall on x86_64? Or do we have a vserver-syscall on this architecture? [05:18] well if you want to keep it this way, I can live with that, so it's up to you ... [05:18] we have the first vserver syscall on this number ... [05:19] was my fault, was a bad idea ... [05:19] ah, I understand the problem now [05:19] I moved both syscalls to 273/274 ... [05:22] this can cause real problems; depending on stack, this function may succeed and switch to a new context [05:23] hmm, should not the 'new' syscall have a larger stack footprint than the old one? [05:25] I have to go for a bit, back in an hour [05:25] both are _syscall3 taking parameters with same size (at least on ia32) [05:25] thanks for the help :) [05:25] thank you simon ... [05:26] @enrico so we will call it with 0,0,0 then ... [05:27] which should not be a problem, right? [05:29] what happens when I call the old syscall for ctx==0? [05:30] Does it fail with -EINVAL? [05:30] -EINVAL I guess ... [05:30] let me check ... [05:30] ok, then it should be enough to "succeed" on it [05:30] I thought, '0' had a special meaning [05:31] } else if (ctx <= 0 || ctx > MAX_S_CONTEXT) { [05:31] ret = -EINVAL; [05:32] ok, it is not a problem then [05:33] good ... sorry for that 'special' case ... [05:39] it's uploaded to savannah... http://savannah.nongnu.org/files/?group=util-vserver [05:39] thanks enrico ... [06:06] ChuckD (~bug@144.137.122.238) joined #vserver. [06:12] how can I test the quota stuff? [06:12] http://vserver.13thfloor.at/Linux2.6/index.php?page=Per+Context+Quota [06:13] ooh [06:13] but the tagctx is required ... [06:13] I have to update that one too ... [06:13] i have uid24/gid24 [06:13] good choice ;) [06:13] ;) [06:16] eek [06:17] # make [06:17] cc -g -Wall -O2 -c -o vrsetup.o vrsetup.c [06:17] cc -g -Wall -O2 vrsetup.o -o vrsetup [06:17] vrsetup.o(.text+0x1ea): In function `main': [06:17] vrsetup.o(.text+0x25e):/usr/stor/vserver/vr-tools-0.13/vrsetup.c:142: undefined reference to `errno' [06:17] collect2: ld returned 1 exit status [06:17] make: *** [vrsetup] Error 1 [06:17] is fixed in a later version ... [06:17] this is 0.13... [06:18] yeah, fixed in 0.14 ... [06:18] http://vserver.13thfloor.at/Experimental/vr-tools-0.14.tar.bz2 [06:19] ahh [06:20] I have no /dev/vroot... [06:21] you have no devfs .. I assume ;) [06:21] nope :) [06:21] should I? [06:21] in this case, you have to create the nodes with mknod yourself ... [06:21] I thought that was experimental [06:21] well, regarding to lkml it's already obsolote ;) [06:22] I can't mknod /dev/vroot/0 because there's no /dev/vroot [06:22] mkdir /dev/vroot will help there ;) [06:22] oh. ok... didnt think you could do that ;) [06:22] but you can name the devices just as you want ... [06:23] what is vrsetup for? [06:23] setting up the vroot device ... [06:23] this device proxies quota calls, but blocks everything else ... [06:23] it doesn't say to run it in the INSTALL or on that page ;) [06:24] oh wait [06:24] * setup one vroot device for all vservers on a shared partition [06:24] nevermind ;) [06:24] (as described in the INSTALL and on my pages) [06:27] # ./cqhadd -v -x 2 /dev/vroot/0 [06:27] adding quota hash for /dev/vroot/0 ... failed: No such device [06:27] # ls -l /dev/vroot/0 [06:27] brw-r--r-- 1 root root 4, 0 Oct 18 15:24 /dev/vroot/0 [06:27] oh [06:27] you have to setup the device first ... [06:27] like losetup ... [06:28] vrsetup /dev/vroot/1 /dev/real/device [06:28] # ./vrsetup /dev/vroot/0 /dev/sda6 [06:28] ./vrsetup: can't open device /dev/vroot/0: No such device or address [06:28] :( [06:29] you did enable the vroot device? [06:29] on make menuconfig ... [06:30] yes :) [06:30] CONFIG_BLK_DEV_VROOT=y [06:31] hold on... [06:32] yes :P [06:36] resolved? [06:36] nope... [06:37] look in dmesg for some vroot message ... [06:37] nothing there... [06:38] did you compile it as module? [06:38] no - no modules [06:38] there should be a message stating that there are 4 vroot devices ... [06:39] but let me verify that one ... [06:41] vroot: loaded (max 4 devices) [06:41] if you don't get this message, either vroot is not patched, or not enabled in the kernel ... [06:41] dmesg | grep -i vroot [06:41] I get nothing... [06:41] :( [06:42] I know this sounds stupid, but did you recompile the kernel, did you install the new one, did you boot it? [06:43] well I thought I did... let me try it all again [06:43] woohoo! I can't believe this is working - I'm migrating my main hosting server (RH6.2) to a new (RH9) server. I've rsynced the old server -> /vservers/old/ on the new box, till now sshd, inetd & syslog are working well, going to try the rest now [06:43] vserver rocks, big big rocks [06:43] if it still doesn't show up, compile it as module ... we can make some tests then ... [06:45] hi chuck! [06:45] hi herbert! [06:46] mysql's working... strange, because I had to add a bind-address=$IPROOT line to /etc/my.cnf on another server [06:47] might be because this is MySQL 3.23, it was 4 that had problems yesterday [06:48] herbert are you maintaining the vserver tools now or jack? just they could do with a patch to the install- scripts to copy resolv.conf [06:48] also the RedHat 9 minimum package list is wrong (e.g. sh-utils/textutils/etc have all been merged to coreutils) [06:49] I've got a working one if it's useful to send to anyone [06:49] I'm not maintaining the vserver tools, as long as enrico does a good job ;) [06:50] ok cool, so you recommend using enrico's tools? I tried them first but then saw jack had put out 0.25 so thought they might be better... maybe I'll switch back [06:51] they will be the default tools for vserver-1.0.0 .. any improvements jack adds, will be verified and added to util-vserver if it makes sense ... [06:51]