[00:00] yup, and if possible, try if it works ;) [00:00] heh ok [00:01] I'll prepare the other patches in the meantime ... [00:01] Bertl> you not have answer from Honza ? [00:02] nope, didn't reply yet ... maybe he is busy ... [00:03] and i not have.. maybe.. [00:05] well.. i go sleep.. [00:05] bye to all.. [00:05] eh... [00:05] okay .. good night ... [00:06] thanks... good day too you... [00:06] shadow (~umka@212.86.233.226) left irc: Quit: night [00:12] ok, it died on mm/page_alloc.c [00:12] okay .. what output? [00:12] heh. I don't have any way to copy and paste it [00:12] but it looks like it's a name mismatch between 'back_local_freelist' and 'local_freelist' [00:13] oh, .. okay I'll compile it myself then ... [00:13] lines 130 and 131 [00:13] yeah, ok. the problem is line 130 has "goto local_freelist" and that label isn't defined [00:14] although, back_local_freelist doesn't look like the right place to jump to :) [00:15] ah okay, just remove line 129 & 130 (check and jump) [00:16] alright [00:20] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Quit: Tak ja padaaaaM [00:33] ok, everything built [00:34] now for the real test ,) [00:34] hehe [00:35] brb! [00:40] ok, it booted up [00:40] hmm, cat /proc/meminfo gives? [00:40] what piece of /proc/meminfo do you want? [00:41] compared to non rmap kernels ... you should see active/inactive .. etc [00:41] yeah [00:41] Active/ActiveAnon/Inact_dirty/... [00:41] okay .. then we move on to the next test ... ;) [00:42] this is on SMP, right? [00:42] yup [00:46] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-O1.2.diff.bz2 [00:46] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-O1.2-rmap15k.diff.bz2 [00:47] ok [00:47] this should combine the scheduler and rmap15k ... [00:48] so back to 2.4.23-pre8 -> pre8-O1.2 -> pre8-O1.2-rmap15k? [00:48] exactly ... [00:52] serving (~serving@213.186.189.177) joined #vserver. [00:58] kernel/ksyms.c lines 460 and 466 [00:59] both export set_cpus_allowed [00:59] hmm, again ... damn ... [00:59] it's in the O(1) patch [01:01] okay, remove one of them ... [01:01] yup [01:15] okay, that one should complete it then ... http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-O1.2-rmap15k-c17h.diff.bz2 [01:17] almost done compiling pre8-O1.2-rmap15k :) [01:18] good, give it a try anyway .. yes? [01:18] yeah [01:33] ok, pre8-O1.2-rmap15k booted :) [01:34] sounds good ... okay then let's go for it 2.4.23-pre8-O1.2-rmap15k-c17h ... [01:34] you can get updated patch http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-O1.3.diff.bz2 which should fix the ksyms issue [01:35] ok [01:37] hm [01:37] patch-2.4.23-pre8-O1.2-rmap15k-c17h.diff.bz2 is 14 bytes long [01:37] any issues? [01:37] :) [01:37] hmm, this doesn't sound right ;) [01:38] hehe [01:39] but it is explainable ... --dry-run 8-) [01:40] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-O1.2-rmap15k-c17h.diff.bz2 [01:41] please reload again %-) [01:41] it should be 23k in size (as bz2) [01:41] ok [01:44] netrose (~john877@CC3-24.171.21.47.charter-stl.com) joined #vserver. [02:02] built and rebooting [02:02] perfect ... [02:06] booted :) [02:06] okay, could you run the forkbomb again? [02:06] sure [02:07] did you read the explanation Sam gave regarding the scheduler? [02:07] system responsiveness seems about the same [02:07] nope [02:08] IIRC it must be in the archives (mailinglist) ... [02:08] he had some tests/verifications for the scheduler there ... [02:08] the vserver mailing list? [02:08] yup ... [02:09] ok, I'll look it up [02:09] that would be great ... thanks for your help ... [02:10] Subject: Re: O(1) scheduler for c17f ...: [02:11] is that it? [02:11] looks like it [02:11] Sam Vilain + -ac there? [02:12] yeah [02:12] that's the one ... [02:12] patch-2.4.22-ac4-ctx18pre1.UNTESTED [02:12] the O(1) scheduler I use is from -aa tree [02:13] and the the ctx modifications (bucket) are from Sam ... [02:13] yeah [02:14] I guess the rmap+O(1) combo will rock on SMP if it works ... [02:14] :) [02:17] heh. load averages in the 480's always amuse me :) [02:19] are you able to shutdown a vserver with a forkbomb inside? [02:21] hmm [02:21] I assume it will take some time ( a few minutes) [02:21] looks like that will take some time :) [02:22] the reason is, that the current shutdown procedure changes into the context ... [02:22] we'll need send_signal_to_context() to ease this ... [02:23] well, I don't know if running it in the MAIN context would speed it up any [02:23] do you have troubles starting programs in the main context? [02:23] as a cpu hog on MAIN gets stuck into the same pattern of cpu usage the vserver processes are in [02:23] not starting, but finishing :) [02:24] I see, matt was doing some renicing ... [02:24] ah, start all the vservers at a lower nice level [02:24] S_NICE= [02:24] it's in the config file ;) [02:24] heh :) [02:25] ok, finished shutting down [02:25] ~4min [02:25] well, that was okay, for such a situation ... [02:25] yeah [02:26] what was the process limit for the vservers? [02:26] 256 [02:26] nice ;) [02:28] well if you like you could play a little with it ... but I would ask you to keep the kernel running for one day if possible, with whatever load makes sense ... so we see if it's stable ... [02:29] sure [02:30] okay, thanks, anything I can do for you? [02:31] heh, I'm good :) [02:40] well, I'm going to go get some other stuff done :) bbl [02:02] steve_ (steve`@140.piscataway-13rh16rt.nj.dial-access.att.net) joined #vserver. [02:03] hi steve! [02:03] What up Bert [02:03] we have a (hopefully) working O(1) + rmap combo ... [02:04] hopefully....? [02:04] well it is about 1 hour old ... so we can't say much ... [02:04] I see what you mean [02:05] but MrBawb tested it on his machine, and had forkbombs running ... while the overall system was still responsive at a load of ~500 ... [02:06] still some glitches? [02:07] the scheduler needs some tuning, but I guess it will work as expected ... [02:07] correct [02:09] so what brings you here? [02:09] wanted to check in, before i left [02:25] steve_ (steve`@140.piscataway-13rh16rt.nj.dial-access.att.net) left #vserver (Client exiting). [02:39] netrose (~john877@CC3-24.171.21.47.charter-stl.com) left irc: Ping timeout: 485 seconds [04:20] sladen (paul@starsky.19inch.net) joined #vserver. [04:31] netrose (~john877@CC3-24.171.21.47.charter-stl.com) joined #vserver. [05:07] serving (~serving@213.186.189.177) left irc: Ping timeout: 485 seconds [05:17] serving (~serving@213.186.190.203) joined #vserver. [06:03] [Dev-Null] (~thomas@12-222-174-53.client.insightBB.com) joined #vserver. [06:03] Action: [Dev-Null] waves hello [06:04] hi /dev/null! [06:04] <[Dev-Null]> hi! ;) [06:04] <[Dev-Null]> didn't know how active the channel would be [06:04] nobody here ... [06:04] <[Dev-Null]> <---------- First timer here [06:05] <[Dev-Null]> i was hoping to get some help [06:05] and nobody wants to answer my vserver questions ... [06:05] <[Dev-Null]> huh..... [06:06] <[Dev-Null]> i've got mine going but having problems with rc scripts on SuSE [06:06] <[Dev-Null]> you? [06:07] well what problems do you have with the rc scripts ... [06:07] <[Dev-Null]> i am having problems getting sshd to start [06:08] <[Dev-Null]> i can start almost any daemon from within the vserver but not sshd [06:08] maybe sshd is running on the host (physical server)? [06:08] <[Dev-Null]> yes [06:08] you have to use the v_sshd script to start it there ... [06:09] <[Dev-Null]> within the vserver? [06:09] this wraps the sshd in such way, that it only binds to specific ips ... (no on the host) [06:09] <[Dev-Null]> ok---i can try that [06:10] you'll have to make a config file ... [06:10] /etc/vservices/sshd.conf [06:10] which contains IP="ethX:aaa.bbb.ccc.ddd" [06:11] where aaa...ddd is the ip you want the host sshd to bind on [06:11] <[Dev-Null]> what about multiple servers? [06:11] disable sshd as service and enable v_sshd (which is a wrapper) [06:11] <[Dev-Null]> ok [06:12] each virtual server can then start it's own sshd on a ip != aaa...ddd [06:12] <[Dev-Null]> ah ok [06:39] everything working now? or still some troubles? [06:41] <[Dev-Null]> well --- i got a sshd to work [06:41] <[Dev-Null]> but not via v_sshd [06:41] <[Dev-Null]> where does v_sshd use /etc/vservices/ssh.conf [06:41] what is the problem with v_sshd? [06:42] /etc/vservices/sshd.conf [06:42] there is a script vsysvwrapper which looks at those config files ... [06:43] the v_sshd init script should call that ... [06:44] shadow (~umka@212.86.233.226) joined #vserver. [06:44] <[Dev-Null]> ok i'll try an bring it back up [06:44] hi [06:45] hi! [06:45] <[Dev-Null]> hi [06:50] <[Dev-Null]> well here what i got [06:50] <[Dev-Null]> Invalid IP number or host name: eth0:192.168.1.8 [06:50] <[Dev-Null]> so i removed eth0 in sshd.conf [06:51] yes, and? [06:51] <[Dev-Null]> ok... [06:51] <[Dev-Null]> ipv4root is now 192.168.1.8 [06:51] <[Dev-Null]> Starting SSH daemon done [06:51] perfect ... [06:51] <[Dev-Null]> almost [06:51] Hi Herbert :) [06:52] hi alex! [06:52] <[Dev-Null]> when i do vps -A [06:52] <[Dev-Null]> i get 17763 0 MAIN ? 00:00:00 sshd [06:52] <[Dev-Null]> shouldn't MAIN be the vserver? [06:53] you now have a sshd on the host (not vserver) running ... [06:53] this is bound to the ip 192.168.1.8 ... [06:53] <[Dev-Null]> i specifically did a killall sshd [06:53] you can now start a vserver, with another address 192.168.1.9 for example ... [06:53] <[Dev-Null]> ok [06:54] and it will bind to address 192.168.1.9 ... [06:54] <[Dev-Null]> probably just my fumbling fingers! [06:54] <[Dev-Null]> ;) [06:55] if you don't want to run sshd on the host, you just do not start v_sshd ... [06:56] if you start sshd without special options, it will bind to 0.0.0.0 which means _all_ addresses available ... [06:57] @alex just believe it, 5am ;) [06:57] <[Dev-Null]> ok [06:57] <[Dev-Null]> that'll work to [06:57] do you understand why you use the v_sshd script? [06:58] <[Dev-Null]> not really [06:58] mdaur_ (mdaur@p50916E21.dip.t-dialin.net) joined #vserver. [06:58] Action: [Dev-Null] scratches in wonderment [06:58] <[Dev-Null]> ;) [06:58] you limit the available addresses to the configured ones (192.168.1.8 in this case) .. then start sshd which can only bind to those ... [06:59] this way, the other ips (used by the vservers) can be bound by other sshd daemons within the vps (on different addresses like 192.168.1.9) [07:00] <[Dev-Null]> aaaahhhhhhh [07:01] Herbert :) [07:04] okay, everything fine now? [07:05] mdaur (mdaur@p50917C44.dip.t-dialin.net) left irc: Ping timeout: 485 seconds [07:08] well I'll go to bed now .. wish you whatever ... [07:08] :) good dreams :) [07:08] Nick change: Bertl -> Bertl_zZ [07:08] <[Dev-Null]> ok ...seems to be for now [07:08] <[Dev-Null]> thank very much! [07:09] Nick change: [Dev-Null] -> [Dev-Null]-Away [07:58] mdaur__ (mdaur@p50916D3D.dip.t-dialin.net) joined #vserver. [08:04] mdaur_ (mdaur@p50916E21.dip.t-dialin.net) left irc: Ping timeout: 492 seconds [11:29] JonB (~jon@129.142.112.33) joined #vserver. [12:15] kloo (~kloo@213-84-79-23.adsl.xs4all.nl) joined #vserver. [12:15] 'lo. [12:15] hey kloo [12:31] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [14:03] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [14:06] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [14:08] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [14:34] ccooke (~ccooke@80.1.164.238) left #vserver. [15:20] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [16:11] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [16:39] Nick change: Bertl_zZ -> Bertl [16:40] hi all! [16:40] hey Bertl [16:43] how are things, jon? [16:44] Bertl: enjoyable :) [17:01] Hi Herbert [17:02] hi alex! [17:04] have you thought about using a virtual network device instead of virtualizing the network devices? [17:09] but what differents on it ? [17:10] that you could apply routing rules from outside ... [17:10] hm.. explain... [17:11] I was thinking of an interface (like lo/dummy) which is the only visible interface (maybe more of them, but that is another story) in the vserver .. [17:12] which receives and sends packages according to outside vserver routing rules ... [17:12] s/packages/packets/ [17:14] hm.. i current - it so them.. virtual interface visible only in vps who owned his. [17:15] yes, but you create thos interfaces as 'alias' to the real interfaces according to your bindings, right? [17:16] not! [17:16] forwarder, okay .... [17:16] as real interface.. [17:16] hrm, yes and no, you can't have two eth0 (ne 2000, PCI 1 ;), right? [17:16] yes [17:17] but you can have several aliases on this devices, some known as eth0, others known as eth1 (in a vserver) [17:17] not a aliases.. [17:17] maybe I should drop the old alias nomenglature ... [17:18] you have one link, the network device ... [17:18] skb->dev=fixnetdev(skb->nh.iph->daddr,dev); [17:18] count_in_traff(skb); [17:18] and you have several addresses for this link ... [17:19] some of them are inet interfaces inside a vserver, others outside ... right? [17:19] it in net/ipv4/ip_input.c:ip_rcv [17:20] you mean network devices ? [17:21] yes ... [17:21] inet - is part network devices for work with ipv4 [17:22] yes. i have some net devices on host mashine and other in inside vps. [17:23] near example - "trunk" network cards. [17:24] but one part trunk on host - other in vps. [17:25] and I was thinking of a special network device, which acts as a (maybe routing?) configurable bridge [17:26] how as i did work ? [17:27] how as did work ? [17:27] eh.. sorry. [17:27] ;) [17:27] how should it work? [17:28] yes... [17:28] well I'm not entirely sure, but I'm thinking about tagging/marking packets, according to rules ... (routing/iptables) [17:29] and choosing special tables for the interface itself (routing again) [17:29] i have experemental variant taging skb packets.. [17:30] basically packets designated for the virtual interface would be delivered to it, and packets originating from it would be tagged ... [17:30] but... you not think if me have many (20-50... ) devices with addresses on same ip network - select be slow ? [17:30] I have the feeling this could reduce the amount of changes in the network stack drastically ... while giving new possibilities ... [17:31] depends ... the tagging can be as fast as it is now .. [17:32] if even could use the same mechanisms you use now ... but you don't have to modify anything else ... [17:32] s/if/it/ [17:33] on me not optimal algoritm... [17:34] most optimal algoritm need full separate routing tables - not a taging.. [17:34] do you know how I would inject a packet into the 'normal' routing process (like a network card does)? [17:35] i not have changes in routing process only taging.. but if packet send from vps to host.. or from open vps to another... [17:36] it need full viewing rountig tables for this network.. [17:38] for more optimal me must have full separate tables who swithed using context tag.. and add to it all addresses all vps on box. [17:38] hmm, per context iptables should not be the problem, right? [17:38] but i don`t know how do it.. :-\ [17:38] per context already have.. [17:39] it`s easy... [17:39] okay, so if you reduce the number of available interfaces to the virtual (lets call them vnet) interfaces ... [17:40] struct net_device *work = in != NULL ? in : out; [17:40] struct ipt_table *_packet_filter = &work->s_context->ipt.packet_filter; [17:40] and do fing on this table.. [17:41] but me can`t reduce number vps`s :-\ [17:42] I don't see a problem with the vps number ... 100ips on a server works well, right? [17:42] or have you experienced any problems with a lot of IPs on one physical server? [17:43] but if we do select in table with one record and with 100 records it different :) [17:43] okay, (just for a moment) lets assume we have a physical server .. yes? [17:44] and we add 100 IPs on, lets say 10 networks (some shared, others not) ... [17:44] then we bind one service to each IP (apache, sendmail, ...) [17:45] ok... [17:45] do we get in troubles cause of the IPs? [17:46] I would say, no, because the network stuff takes care of this, pretty well ... right? [17:47] compare system load with equal network packet rate on both situations.. [17:48] I would say the apaches and sendmails will do the major part of the load .. right? [17:48] but it userland time.. [17:48] but select from routing is kernel. [17:49] so you say, that the network stack is inperformant at 100 IPs? [17:49] no troubles, almost [17:50] if it ip from one ip network. [17:50] it do full list it zone.. [17:51] for select do full list for it zone.. [17:51] if so, then we should improve the network stack ... [17:51] i think if we can do less overhead - we must do it. [17:52] up to now, we have zero overhead to normal, right? (if I continue my fictional example ;) [17:52] even need add more changes in kernel. [17:53] what "normal" ? system with one ip and small routing table ? [17:54] no normal system with 100 IPs on 10 networks on 3 interfaces ... [17:54] the default vserver case will be simpler, anyway) [17:55] but if we separate on start ip stack we have negative overhead :) [17:56] agreed, we can improve ... but that is not the point, right? [17:56] but it need two levels routing table :-\ [17:56] not necessarily ... [17:56] i can have it :) [17:57] or similar.. for fast select context on input packet.. [17:57] the interesting question is, can we restrict the manipulation of routing entries in such way, that it is safe with only one routing table? [17:58] that would put all the overhead into the route creation ... [17:59] not for one.. [17:59] is there a good network stack description for 2.4.x (x > 15) ? [18:00] i not analize other :) [18:02] for first separate rounting using binary tree [18:02] hm.. sooner not.. [18:04] one axis - mask. other networks who have routing entry.. [18:04] or similar :-\ [18:04] i work with it half year old.. [18:05] okay, I will read some stuff, then we talk again .. [18:05] (I mean about this issue ;) [18:06] okey... if you have question - ask :) [18:09] herber - i was plain use for traffic shaper on vps "device shaper" but i can`t use it.. what you say about it ? [18:10] interesting problem... [18:11] procs memory swap io system cpu [18:11] hmm, let me repeat you question: you planned to use something (the traffic shaper) as device shaper for vps but it didn't work? right? [18:11] 0 10 0 58412 26336 628 1452204 0 0 20 104 1039 4869 0 32 68 [18:11] hi matt! [18:11] is this good or bad? [18:11] so memory looks fine... 1.4GB for cache [18:11] but... [18:12] 5 root 19 0 0 0 0 SW 92.7 0.0 121:59 kswapd [18:12] kswapd is using all available CPU [18:12] hmm, is this a new effect? [18:12] it's 2.4.22-c17e [18:12] i need to reboot because of this anyway [18:12] so i'm gonna try o1-c17h now i guess... [18:13] good choice ;) [18:13] should I use O1+rmap ? [18:13] well, Dan tested it, right? [18:13] yeah [18:13] loads of 500+ for a few hours is good for me :) [18:13] and I don't expect sudden disc corruption from it ... [18:14] that's what we've got ext3 for, right? 8-) [18:14] yep! [18:14] so what am I getting [18:14] patch-2.4.23-pre8-O1.3.diff.bz2 [18:15] then patch-2.4.23-pre8-O1.2-rmap15k.diff.bz2 [18:15] then patch-2.4.23-pre8-O1.2-rmap15k-c17h.diff.bz2 ? [18:15] yup ... you can add the memory stuff if you would like to ... [18:16] you mean ml? [18:16] yes, should work, although not tested yet ... [18:16] Bertl: all those patches ... which one should i get for a mostly stable ? [18:16] hmm, the patch-2.4.23-pre8-O1.2-rmap15k-c17h.diff.bz2 maybe? [18:17] without the pre8-O1.2-rmap15k of course ;) [18:17] Bertl: why without that ? [18:17] if you want stable, as in (rock solid) you should use the c17f patch on 2.4.22 ... [18:18] the O(1) is about one week old ... [18:18] and the rmap15k ontop of it about 1 day ... [18:19] Bertl: is that in the http://vserver.13thfloor.at/Experimental/ ? [18:19] rmap itself is tested well, but ... [18:20] there are a lot of things there, what exactly do you look for? [18:21] Bertl: something to patch my kernel with [18:21] Bertl: so i can get vservers up and running, and not totaly unstable [18:21] http://vserver.13thfloor.at/Stuff/split-2.4.22-c17f/ [18:22] hrm... looks like a O1-rmap-ml patch needs to be made [18:22] what did the rmap patch do ? [18:22] O1c17g2-ml definitely doesn't work [18:22] neither does 2.4.22-c17e-rmap15k-ml0.06 [18:23] okay, I'll have a look at it, there is no reason for ml0.06 not to work on that one ... [18:23] hrem [18:23] lots of failures [18:23] mq0.11 fails now too [18:23] Hunk #4 FAILED at 1333. [18:23] 1 out of 4 hunks FAILED -- saving rejects to file fs/inode.c.rej [18:24] probably changes in pre8 ... I have a new version, now called qa0.12 ;) [18:24] oh [18:25] i don't see it... :) [18:25] maybe because I didn't release it yet ;) [18:26] qa = ? [18:26] quota abstraction ... [18:26] would qh be more intuitive? [18:27] what was mq supposed to be? [18:27] quota hash is what you've always referred to previously... [18:27] originally it was mountpoint quota ... but became quota hash abstraction [18:28] okay so qh is better then? [18:28] yeah [18:29] good qh it is ;) [18:32] i don't understand why kswapd is using all CPU, it's just bizarre [18:32] I had this on 2.4.22 once ... seemed to me like a bug ... [18:33] yeah [18:33] ok [18:34] i'll see after all these vm cleanups [18:38] matt, you said that the rss accounting was wrong last time, right? [18:38] yeah, it just kept incrementing [18:38] under the O1 patch... [18:39] but rmap-ml0.06 was correct [18:39] this was with O(1) but without rmap, right? [18:39] right [18:47] say (~say@212.86.243.154) left irc: Read error: Connection reset by peer [18:47] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [18:54] hey matt, I added some rss stuff to the ml0.07, but you should test it first (UP VMWARE for example) [18:55] yeah [18:55] already got the vmware serve booted up :) [18:55] patch will be there in a few minutes ... [18:55] and qh ? [18:56] will come a few minutes later ... [18:59] yeah, looks like the kswapd cpu overuse is a documented problem [19:02] matta_ (~matta@pcp02730451pcs.potshe01.pa.comcast.net) joined #vserver. [19:02] does vserver support ipv6 ? [19:02] yes and no ... [19:03] there is no vserver ipv6, but the default ipv6 does work ... [19:03] oh [19:03] Bertl: what is needed to give each vserver a different ipv6 ip ? [19:03] question... i thought the "all vservers see everyone elses traffic" problem was fixed a long time ago? [19:04] because it looks like 1 vserver can run tcpdump and see everything [19:04] matta_: thanks for mentioning that, as i am just writting a friend with suggestions of projects we can do [19:05] ipv6 is complex, I do not udnerstand it (yet), and nobody added vserver support for it AFAIK ... [19:05] Bertl: okay, i'll put it on my list [19:05] shuri (~ipv6@3ffe:bc0:8000::5bf) joined #vserver. [19:06] if you know what you are doing (regarding ipv6) it should be straight forward ... [19:06] Bertl: i dont [19:06] Bertl: right now i'm just giving suggestions to university projects me and a friend could do [19:06] Bertl: we have FAR too many to do them all [19:07] well would be nice if one vserver project is under the ones you do ;) [19:08] Bertl: well, which vserver project would that be? [19:08] Bertl: scheduling stuff? ipv6 stuff, solving matta's tcpdump problem ? [19:08] Bertl: and scheduling, is that cpu, io, disk, or net scheduling ? [19:09] the tcpdump is gone with ipv6 disable IIRC ... [19:09] Bertl: i dont know, it depends on what he wants to do as well [19:09] Bertl: that didnt make sense in my head [19:09] bertl oh... [19:09] forgot that [19:10] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre8-O1.3-rmap15k-c17h-ml0.07.diff.bz2 [19:11] Bertl: the tcpdump is gone with ipv6 disable IIRC ... ?? would you be so kind to elaborate ? [19:11] IIRC, then disabling ipv6 support will make the ipv4 separation work as expected ;) [19:12] that works :) [19:12] i remember reading that before... [19:12] and ml patch applies [19:12] [Dev-Null]-Away (~thomas@12-222-174-53.client.insightBB.com) left irc: Quit: Lost terminal [19:13] iirc ? [19:15] If I Remember Correctly ... [19:15] Bertl: ahh [19:16] matta (matta@tektonic.net) left irc: Ping timeout: 485 seconds [19:16] AFAIK IIRC is WUA ;) [19:18] wua ? [19:18]