1104624298 M * Doener uhm, sorry? if you got a patch that does not apply cleanly, you're probably not applying it to the intended source... but maybe i just don't understand the question ;) 1104627573 M * we2by yarihm, the 1.9.14 patch works fine 1104627636 M * yarihm Doener: i do know that the patch isn't intended for the sources i'm having, but i'm looking for the patch against 2.6.10 ... that's what i wanted to say, sorry 1104627647 M * yarihm we2by: i'll look for that one then 1104627711 M * we2by fine= a running kernel 1104627719 M * we2by I could not get a vserver running 1104627999 N * Bertl_oO Bertl 1104628014 M * Bertl evening folks! 1104628042 M * Bertl yarihm: http://vserver.13thfloor.at/Experimental/patch-2.6.10-vs1.9.3.14.diff 1104628056 M * yarihm thanx bertl 1104628077 M * yarihm how experimental is it on a scale from 1 to 10? :) 1104628110 M * Bertl hmm, 10 means very experimental? and is it linear? 1104628131 M * yarihm (where 10 is experimental as in "the machine will be screwed up beyon all repair and backup-strategy" :) 1104628148 M * yarihm yeah, let's take a linear scale ... 1104628156 M * Loki|muh hrhr 1104628179 M * Bertl well, I would say it's a 1 then ... 1104628199 M * yarihm why don't you move it out of experimental then? ,) 1104628242 M * Bertl because I like those long numbers ;) 1104628259 M * yarihm that's what i call a reason! thanx :) 1104628261 M * Bertl no seriously we are in rc state ... 1104628276 M * yarihm ok, that's fine 1104628280 M * Bertl so a new devel release will be there pretty soon ... 1104628342 M * Bertl Doener: I'll upload a diff against 1.9.3.14 ... 1104628853 M * Doener great! 1104629217 M * yarihm how cool, now one can set the timer-freq in the kernel-configfile ... 1104629251 M * yarihm i missed that feature so long for our gameservers and now since rx-polling is needed this will bring some advantages 1104629303 M * Bertl yep, but wait for 1.9.3.15 until you go above 2000 1104629388 M * yarihm aie 1104629393 M * yarihm -> ctrl c 1104629400 M * yarihm why so? 1104629452 M * yarihm BSD securelevels support ... i'm very very very surprised where linux is going :) did they have look at their BSD-colleagues' stuff? 1104629495 M * Bertl there are some assumptions done inside the ekrnel, especially the timer stuff, which just doesn't expect the tmer interrupt to be above 1000 1104629531 M * yarihm so i'll go to 1000 at the moment 1104629551 M * Bertl I fixed most of them, but I missed a timer check on bootup (didn't affect the systems I tested with) but it isn't fixed in .14 yet, but .15 will have that fix 1104629606 M * yarihm do you have a estimate when this patch will be available? if it's soon there's not much sense in compiling a new kernel now 1104630649 M * Bertl http://vserver.13thfloor.at/Experimental/delta-2.6.10-vs1.9.3.14-vs1.9.3.14.6.diff 1104630658 M * Doener thanks! 1104630924 M * Doener btw, what's this? (#4b4b,*0):80104190 oops 1104630952 M * Bertl that's an oops ;) 1104630969 M * Bertl i.e. it adds the location where the oops is identified as oops 1104630991 M * Doener ok 1104630996 M * Bertl basically as a marker to go back from ... 1104631138 M * Bertl Doener: hum, please revert the following patch by hand ... (if present) 1104631155 M * Bertl --- linux-2.6.10-vs1.9.3.14.6/include/linux/capability.h Sun Jan 2 02:57+++ linux-2.6.10-vs1.9.3.14.6.x/include/linux/capability.h Thu Dec 30 03:30@@ -56,7 +56,7 @@ typedef struct kernel_cap_struct { 1104631159 M * Bertl #else 1104631162 M * Bertl -typedef __u64 kernel_cap_t; 1104631164 M * Bertl +typedef __u32 kernel_cap_t; 1104631167 M * Bertl #endif 1104631173 M * Bertl it was just a test ... 1104631208 M * Doener not present, i.e. it reads "__u64" 1104631228 M * Bertl should read __u32 ;) 1104631272 M * Doener hm... reverting -"... __u64" makes "__u64" ;) 1104631289 M * Bertl yeah, this is the patch to revert it ... 1104631309 M * Doener ok, applied 1104631464 M * Bertl yarihm: btw, here is the required fix for the varhz stuff: http://vserver.13thfloor.at/Experimental/VARHZ/patch-2.6.10-vs1.9.3.14-varhz-fix01.diff 1104631603 M * Bertl Doener: I also found this in my patches: http://vserver.13thfloor.at/Experimental/OOPS/patch-strange-stuff.diff 1104631624 M * Bertl no idear where it comes from or why it was added/removed 1104631712 M * Bertl actually I think it should be removed like the __u64 stuff 1104631975 M * Doener yeah, seems strange 1104632008 M * Bertl guess it was accidentially applied when I revived the history stuff 1104632038 M * yarihm Bertl: thanx 1104632184 M * Bertl Doener: do you have a tool to bring the history in sequence? 1104632198 M * Bertl (if not I'll do a script for that) 1104632238 M * Doener let's see how my vim magic evolved... 1104632270 M * Bertl hmm, doing that with vim? I'm impressed! 1104632893 M * Doener hm, sort doesn't do what i want... 1104633420 M * Doener Bertl: hm, now i wonder what actually is 'in sequence'... 1104633467 M * Bertl sorted by the funny sequence number in front of each row ;) 1104633484 M * Doener ok, so no respect to the cpu number, right? 1104633547 M * Bertl yep 1104633648 M * Bertl looks like 'sort -n +0.1' is doing the job ... 1104633792 M * Doener hm, why doesn't my sort manpage tell me about that +0.1 thingy? :( 1104633818 M * Bertl it's probably depreciated, evil and damn useful ;) 1104633835 M * Bertl sec, I'll postprocess the version online 1104633855 M * Doener hm, managed to get vim real busy... 1104633865 M * Doener 1501 doener 25 0 11300 4612 2580 S 97.9 0.5 0:48.73 vi 1104633981 M * Bertl k, updated as 2.6.10-vs1.9.3.14.6_seq.log 1104634037 M * Bertl funny thing is that some sequence numbers are missing ... 1104634134 M * Bertl seems like cpu 2 and 3 kept running after the oops ... strange ... maybe I should put the active stuff into the vxh_throw_oops ... 1104634135 Q * ndim Ping timeout: 480 seconds 1104634194 M * Bertl should not be too hard, the oops is easy to trigger with killer-03 ;) 1104634214 M * Doener hehe 1104634243 M * Bertl and btw, it's purely rcu stuff related, with locks there, no oops for over 4 days ... 1104634449 J * ndim U2FsdGVkX1@helena.bawue.de 1104634459 M * Bertl wb ndim! 1104634550 M * Doener Bertl: btw, here's the vim command, it even leaves the stuff above the history untouched ;) :1;/^(#/,$!sort -n +0.1 1104634588 M * Bertl cool! 1104634908 M * Doener what line is that in __loc_vx_info? 1104635819 M * Bertl the for_each* line 1104635835 M * Bertl (i.e. the list walking loop head) 1104635885 M * Bertl basically I think that the following happens: 1104635922 M * Bertl some vx_info is released (while still being hashed for whatever reason) 1104635925 M * Doener hm... .14.6 is using rcu? 1104635956 M * Bertl yeah, in the way _we_ reintroduced it for the hash, remember? 1104635998 M * Bertl then the same memory get's reused for a new vx_info, zeroing out the old space ... 1104636021 M * Bertl while at the same time __loc_vx_info() is walking the list 1104636110 M * Doener i just wonder about kernel/vserver/context.c:97 ... we're not using a pre-defined rcu function, but modify the pointer 'our way' (hlist_del_rcu looks like doing a little more) 1104636166 M * Bertl ah, that is just a 'bug catcher' I added ... 1104636172 M * Doener and in the case of 'no dynamic contexts left' we hit that one without any locks held.. 1104636184 M * Bertl I probably should add a comment there ... 1104636210 M * Bertl when __dealloc_vx_info() is called, the vx_info must not be on any hash list anymore 1104636251 M * Bertl adding this 'poison' catches violations of this assertion, as we have seen last year ;) 1104636283 M * Doener hm, right, it doesn't even get hashed in that case 1104636310 M * Bertl and we saw it striking last time (remember the first oops?) 1104636315 M * Doener yep 1104636487 M * Bertl okay, updated log with vxh_active=0 moved into vxh_throw_oops() ... 1104636489 M * Bertl http://vserver.13thfloor.at/Experimental/OOPS/2.6.10-vs1.9.3.14.6-2.log 1104636722 M * Bertl (#4ce6,*0):801373a0 __loc_vx_info [#56133] -> f7004000[#56133,2.0] 1104636735 M * Bertl looks like that should not have happened ... 1104636870 M * Bertl 2.0 means refcount=0 usecount=2 1104636945 M * Bertl __hash_vx_info() does __get_vx_info() 1104637028 M * Bertl hm ... 1104637058 M * Doener hm, i don't see the problem atm... 1104637073 M * Bertl me neither ... confused usecnt with refcount 1104637085 M * Doener :) 1104637122 M * Bertl okay, let's do some loud thinking ... 1104637140 M * Bertl the (first) oops happend at cpu #2 1104637189 M * Doener eax is a list poison again, right? 1104637196 M * Bertl this means it happened in some path which did alloc_vx_info() probably in loc_* ... 1104637214 M * Bertl eax is the POISON1 yes 1104637229 M * Bertl (the one added when we do __dealloc..() 1104637252 M * Doener yep 1104637254 M * Bertl same with edx ... 1104637268 M * Bertl so I assume the loop has n=pos=POISON1 1104637625 M * Bertl hmm ... why do we have those ... 1104637626 M * Bertl (#4ceb,*2):801377e6 __unhash_vx_info f7063000[#56131,2.0] 1104637627 M * Bertl (#4cec,*2):8011d1b9 put_vx_info f7063000[#56131,2.0] 1104637730 M * Doener if i got it right, refcnt is equal to the number of processes in the context, and usecnt is a general counter for all stuff using a reference to the context, right? 1104637750 M * Doener (always thought it would be the other way...) 1104637754 M * Bertl yep, that (or the oposite ;) was the idea ;) 1104637769 M * Bertl maybe I got it mixed up at some point? 1104637816 M * Doener (clr|set)_vx_info are the ones modifying refcnt 1104637852 M * Bertl yeah, IIRC the idea was to use refcnt, when some struct is actually referring to vx_info 1104637869 M * Doener ok 1104637891 M * Bertl and the set/clr primitives were added to avoid mistakes there 1104637958 M * Bertl so, taks, sockets and mm should use set/clr 1104638008 M * Bertl and it (refcnt) 'should' also be the condition for unhashing/destroying a context 1104638078 M * Doener yep 1104638131 M * Bertl to me it looks like the put_vx_info() mentioned in the log is a bug in the history stuff .. investigating right now 1104638307 M * Bertl hmm, well at least I'm not using the vxh_rcu_put_vx_info() yet 1104638406 M * Doener unhash_vx_info is called from __clr_vx_info, which calls __put_vx_info directly after unhash_vx_info, so that output looks fine to me... 1104638462 M * Bertl yeah, right, and the __unhash_vx_info is basically the vxh_rcu_put_vx_info() 1104638474 M * Bertl (so no need to add that) 1104638726 M * Bertl okay, so cpu #2 is doing the first few steps of __loc_vx_info() 1104638754 M * Bertl and oopses on the lookup (which means there is something bad on the list, right?) 1104638761 M * Doener yep 1104638801 M * Bertl the last hashed xid= 56133 while the last unhashed is 56131 1104638855 M * Bertl let's make the hash table a lot small (like on hash chain ;) 1104638887 M * Bertl (and I'll change the xid output to use signed for the xid) 1104638900 M * Doener and if that doesn't help, hash pipe would be the next step ;) 1104638950 M * Bertl hmm? 1104639127 M * Doener "hash pipe" is a song by Weezer, bad joke anyway... 1104639158 M * Doener don't even know if hash pipe is a valid english expression... 1104639176 M * Bertl heh, k ... 1104639436 M * Bertl hmm, we could 'try' to dump the hash when the oops happens ... 1104639482 M * Bertl but I guess that would need some 'hash freezing' 1104639560 M * Doener hm, what do we actually do to prevent races of the writers? rcu only protects readers... 1104639591 M * Bertl rcu 'write' doesn't happen at all ... 1104639607 M * Bertl what we do is hlist_add_rcu() 1104639609 M * Doener hlist_add_head_rcu(&vxi->vx_hlist, head); 1104639623 M * Bertl and adding is perfectly fine with rcu ... 1104639656 M * Doener * The caller must take whatever precautions are necessary 1104639656 M * Doener * (such as holding appropriate locks) to avoid racing 1104639656 M * Doener * with another list-mutation primitive, such as hlist_add_head_rcu() 1104639656 M * Doener * or hlist_del_rcu(), running on this same list. 1104639676 M * Doener and i guess we are sharing lists between contexts, right? 1104639685 M * Bertl hmm, right ... sec 1104639695 M * Bertl didn't think of that yet ... 1104639916 M * Bertl right you are, I guess .. so we add back the hash lock, and add it for hash/unhash, right? 1104639942 M * Bertl but not for the lookup ... 1104640063 M * Bertl at a later point we could do a per chain hash (which is probably overkill) 1104640475 M * Doener yep 1104640617 M * Bertl http://vserver.13thfloor.at/Experimental/patch-rcu_and_history_fix01.diff 1104640621 M * Bertl (something like that) 1104640632 M * Doener include/linux/dcache.h -> d_drop 1104640641 M * Doener as an example... 1104640663 M * Doener yeah, looks good 1104640953 M * Bertl okay, readjusted the hash size to 13, so that we only change one thing at a time ... ;) 1104641112 J * nox- ~nox@c135056.adsl.hansenet.de 1104641112 Q * nox Read error: Connection reset by peer 1104641143 M * Bertl ah, nox rejoices ;) 1104641172 N * nox- nox 1104641211 M * Bertl I have to check the timing of his provider ... 1104641280 M * Doener Bertl: btw, did you get a mail about my change to the wiki? i finally managed to subscribe to the wiki ml, but i didn't get a mail about the change, yet... but i'm not too sure, whether i subscribed before or after the change, either ;) 1104641303 M * Bertl yeah, I _did_ get it, but I'm the only one who is able to get it right now ... 1104641316 M * Doener ah ok 1104641327 M * Bertl but you said you managed to subscribe? so mabe it's fixed ... let me check that ... 1104641355 M * Doener at least i got 2 mails and could set my preferences 1104641506 M * Bertl let's see if you get this testmail ... 1104641660 M * Bertl hmm, doesn't look like it's working again ... 1104641694 M * Doener ok 1104641740 M * Bertl meybe I should just forward the changes to the ml (with a few nice words for martin to fix it?) 1104641813 M * Doener hm, i don't think everyone would agree with that... (otherwise they'd be subscribed to the wiki-ml and bugging martin, right? ;) 1104641890 M * Bertl hmm, yeah, but I'm basically out of ideas here ... 1104641947 M * Bertl it basically began with martin asking me: 1104641953 M * Bertl > is the notifier on the Wiki sending to vserver-wiki@lists.tuxbox.dk ? 1104641953 M * Bertl > Can we change that to vserver-wiki@list.linux-vserver.org ? 1104641970 M * Bertl and I did that on Date: Tue, 16 Nov 2004 07:34:01 +0100 1104641985 M * Bertl since then, the wiki mailing list was dead ... 1104642032 M * Bertl since the 9th of december I'm trying to get some feedback from martin on that issue ... no response yet 1104642118 M * Bertl the mail is leaving the wiki, and 'reaches' it's destination (AFAICT), but nothing is delivered to the subscribers ... 1104642270 M * Doener hm, the page linked from the wiki has: 1104642273 M * Doener http://list.linux-vserver.org/cgi-bin/mailman/listinfo 1104642289 M * Doener and http://lists.tuxbox.dk/mailman/listinfo/vserver-wiki 1104642298 M * Doener which in turn has http://lists.tuxbox.dk/cgi-bin/mailman/listinfo 1104642330 M * Doener looks like the transition is only half way done 1104642331 M * Bertl just sent a test mail to the old address ... let's see maybe that still works 1104642411 M * Doener anyway, let's go on with rcu and stuff... 1104642424 M * Doener nothing much we can do about the ml 1104642428 M * Bertl right there ... 1104642443 A * Bertl is test booting the _new_ kernel ... 1104642655 M * Bertl well, it's still running ... ;) 1104642686 A * Doener prepares for waiting 4 days... again ;) 1104642749 M * Bertl hehe, well thanks for explaining RCU to me for now ;*G* 1104642792 M * Doener one hand washes the other ;-) 1104642870 M * Bertl I'm currently there is a killer and 2 bash loops banging on /proc running ... 1104642886 M * Bertl (remove that I'm) 1104643290 M * Doener hm, another stylistic question... vx_info_state(vxi, VXS_HASHED), why that and not (vx_state(vxi) & VXS_HASHED) ? 1104643373 M * Doener because it's easier to change later on, if the way the state is stored is changed or is there more to it? 1104643439 M * Bertl no, it's basically just the OOD (Object Oriented Design) training which strikes here .. 1104643503 M * Bertl where the former makes the check opaque, the latter exposes the bit and meaning ... 1104643537 M * Bertl (same as with capable() for example) 1104643598 M * Bertl okay, looks good so far, what do we fix net? 1104643603 M * Bertl s/net/next/ 1104643621 M * Doener what's up to be fixed? 1104643686 M * Bertl you had a deep look at the kernel todo list, IIRC, any areas you addressed so far? something you are working on? 1104643730 M * Bertl # {025} remove or fix openfd code and migration maybe? 1104643763 M * Doener yeah, we could at least share thoughts on that i guess 1104643809 M * Bertl another issue first, just because I stumbled over it, what do you thing regarding BME, should I 'incorporate' that into 1.9.x? 1104643819 M * Doener also had a short look at the reaping of 'lost childs', but decided to put it aside for now ;) 1104643885 M * Bertl yeah, maybe the child-reaping would be good to fix too ... 1104643908 M * Doener IIRC there was some talk about getting it into vanilla, maybe we could/should wait if it has any chance to get accepted in the near future, if not make it a part of linux-vserver, as it can be quite handy for vservers 1104643944 M * Bertl yeah, maybe sannes has more luck with getting it into mainline ... 1104643957 M * Doener when it goes into vanilla, there will be some changes i guess, and we'd just be doubling the work 1104644045 A * Doener wonders if the lazy unmount bug is still there... didn't get too much replies on lkml (well, mail's subject was chosen really bad ;) 1104644112 M * Bertl yeah, you should use something like: "2.6.x kernel ate my cat -- is Linus responsible?" as subject ... 1104644202 M * Doener ?! 1104644221 M * Bertl such subjects always get a huge number of responses ;) 1104644303 M * Bertl okay, so what are your thoughts on the openfd code? 1104644414 M * Doener problems happened with "vserver xxx enter", right? 1104644448 M * Bertl well, everytime a task migrates into or out from a context 1104644469 M * Bertl (where out from just means piping data to the outside, atm) 1104644634 M * Bertl just let's add back the code for some testing ... 1104644676 M * Doener yeah, i guess plain reading won't help ;) (that's what i was trying...) 1104644724 M * Bertl shall I keep the history code in 1.9.x, what do you think? 1104644792 M * Doener won't hurt, as long as you can choose not to have it 1104644814 M * Bertl it _should_ compile to nothing when disabled ... 1104644844 M * Bertl and of course it's disabled by default ... 1104644870 M * Doener good ;) 1104644921 M * Doener just got a complaint from my gf that i'm still sitting in front of the screen... she's sleeping right behind me, so i'll go to bed now... 1104644940 M * Bertl okay, do that, gf has priority ;) 1104644952 M * Doener good night! 1104644955 M * Bertl have a good night ... sweet dreams and thanks again! 1104644964 N * Doener Doener_zZz 1104654283 N * Bertl Bertl_zZ 1104654610 Q * serving Read error: Connection reset by peer 1104661573 J * serving ~serving@213.186.171.95 1104665445 J * infowolfe ~infowolfe@209-112-214-6-cdsl-rb1.nwc.acsalaska.net 1104668480 Q * sannes Read error: Connection reset by peer 1104674457 Q * infowolfe Read error: Connection reset by peer 1104675570 J * sannes ~ace@home.skarby.no 1104676022 Q * _are_ Ping timeout: 480 seconds 1104677339 J * infowolfe ~infowolfe@mail.xhcl.net 1104680632 J * monrad ~monrad@213083190130.sonofon.dk 1104681064 Q * sannes Read error: Connection reset by peer 1104684498 Q * infowolfe Quit: leaving 1104684912 N * Bertl_zZ Bertl 1104686670 J * shuri ~shuri@dsl.speedline209.226.electronicbox.net 1104686848 M * Bertl welcome shuri! 1104686868 M * shuri heya Bertl 1104687249 M * we2by hi Bertl 1104687258 M * we2by I have a question here 1104687266 M * we2by can I run fc2 inside debian? 1104687280 M * Bertl morning we2by! why not? 1104687295 M * we2by dunno, just wondering 1104687574 M * Bertl me too ;) 1104687888 M * we2by :) 1104688047 M * Bertl k, back later ... 1104688051 N * Bertl Bertl_oO 1104688134 J * sannes ~ace@home.skarby.no 1104688484 J * DuckMaster ~Duck@dyn-83-157-200-225.ppp.tiscali.fr 1104688910 Q * DuckKing Ping timeout: 480 seconds 1104689407 Q * TheSeer Remote host closed the connection 1104689778 J * TheSeer ~theseer@border.office.salesemotion.net 1104690376 J * infowolfe ~infowolfe@mail.xhcl.net 1104690450 P * infowolfe 1104692292 N * Doener_zZz Doener 1104692300 M * Doener evening! 1104692589 J * _are_ ~are@dsl-084-056-148-130.arcor-ip.net 1104692769 M * we2by helo Doener 1104692775 M * we2by hi _are_ 1104692807 M * _are_ hi 1104692844 M * we2by with a litle help from Bertl_oO I could set up vservers withmin minutes 1104692868 M * _are_ hehe, what had been the final trick? 1104692884 M * we2by I can remember 1104692886 M * we2by :( 1104692890 M * _are_ :-( 1104692893 M * we2by I just recompiled my kernel 1104692899 M * we2by download the iameg, extarct it 1104692902 M * we2by make a config file 1104692905 M * we2by and start it 1104692914 M * _are_ ah, new image 1104692930 M * we2by but this is the stable version for 2.4.x 1104692931 M * _are_ I gues sthis had been the trick, probably your installation indeed missed some file 1104692971 M * we2by I;m using 2.4.28, I think it;s the best kernel I can use with security in mind 1104692996 M * _are_ probably. i have to use 2.6 for the opterons. 1104693023 M * _are_ and it is only stable since 2.6.10, 2.6.9/2.6.10rc3 crashed 1104693321 M * we2by .mknod: `dev/null': Operation not permitted 1104693334 M * we2by how do I allow it to do that? 1104693436 M * _are_ erm, don't allow it 1104693449 M * _are_ you should have a /dev/null already, if not, create it from the main server 1104693468 M * _are_ if you absolutly have to allow it, you need to add a capability to the vserver 1104693619 M * we2by I need that 1104693623 M * we2by _are_, what do I add? 1104693636 M * _are_ already checking, as you know I am new to this stuff myself.... 1104693663 M * _are_ CAP_MKNOD 1104693706 M * we2by S_CAPS="CAP_NET_RAW CAP_MKNOD" 1104693713 M * we2by is this ok? 1104693724 M * _are_ if this is oldstyle configuration: I assume yes 1104693864 M * Doener we2by: why do you need that? 1104693895 M * Doener inside the vserver you can now create a node for the harddrive and probably destroy data... 1104693911 J * Tbery ~tb@rt-pha-1.karneval.cz 1104693914 M * Tbery Hi 1104693922 M * _are_ Hi Tbery 1104693941 M * we2by Doener, I have to enable it for now 1104693949 M * we2by I will remove it after software installation 1104693954 M * Tbery I tested power in virtula servers... 1104693975 M * Doener we2by: software installation should not need CAP_MKNOD... 1104694002 M * _are_ 20:17 <_are_> erm, don't allow it 1104694002 M * _are_ 20:17 <_are_> you should have a /dev/null already, if not, create it from the main server 1104694034 M * _are_ there should not be any software that needs to create a new /dev/null 1104694216 M * we2by ok 1104694329 M * Tbery I use NFS on virtual server... but I just had only 60% speed on net look http://zs-ln.cz/look 1104694330 Q * click Read error: Connection reset by peer 1104694372 M * Tbery https://www.zs-ln.cz/look/traffic/eth1-week.gif 1104694520 M * _are_ Tbery: can't really help you except to say my nfs performance via vservers really sucked, but probably this is mostly because of the nfs-userspace-server 1104694552 M * we2by ssl is port 430? 1104694562 M * _are_ 443 1104694568 M * _are_ if you speak about https 1104694581 M * Tbery I use nfs-user-server 1104694966 M * Tbery do you have some simple problems... 1104694968 M * Tbery ?? 1104695272 J * we2by_ ~we2by@dc5146d009.adsl.wanadoo.nl 1104695272 Q * we2by Read error: Connection reset by peer 1104695734 Q * shuri Quit: Leaving 1104695981 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104695981 Q * we2by_ Read error: Connection reset by peer 1104697334 Q * we2by Quit: Ik ga weg 1104697341 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104697674 Q * we2by jupiter.oftc.net neutron.oftc.net 1104697674 Q * _are_ jupiter.oftc.net neutron.oftc.net 1104697674 Q * TheSeer jupiter.oftc.net neutron.oftc.net 1104697674 Q * sannes jupiter.oftc.net neutron.oftc.net 1104697674 Q * monrad jupiter.oftc.net neutron.oftc.net 1104697674 Q * nox jupiter.oftc.net neutron.oftc.net 1104697674 Q * mboman jupiter.oftc.net neutron.oftc.net 1104697674 Q * berni jupiter.oftc.net neutron.oftc.net 1104697674 Q * virtuoso jupiter.oftc.net neutron.oftc.net 1104697674 Q * gaber jupiter.oftc.net neutron.oftc.net 1104697674 Q * sladen jupiter.oftc.net neutron.oftc.net 1104697674 Q * anonymous-coward jupiter.oftc.net neutron.oftc.net 1104697674 Q * meebey jupiter.oftc.net neutron.oftc.net 1104697674 Q * weasel jupiter.oftc.net neutron.oftc.net 1104697674 Q * Snow-Man jupiter.oftc.net neutron.oftc.net 1104697674 Q * Pinnen jupiter.oftc.net neutron.oftc.net 1104697727 J * virtuoso ~s0t0na@tranq.dorms.spbu.ru 1104697730 J * sladen paul@starsky.19inch.net 1104697742 J * meebey meebey@meebey.net 1104697769 J * Pinnen ~pinnen@h194n2fls35o917.telia.com 1104697780 J * berni ~berni@obelix.ipv6.birkenwald.de 1104697943 M * Doener Bertl_oO: any objections against using a bitmask to keep track of assigned dynamic context ids? 1104698048 J * Snow-Man ~sfrost@snowman.net 1104698081 J * gaber gaber@linuxpl.net 1104698161 J * sannes ~ace@home.skarby.no 1104698210 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104698210 J * _are_ ~are@dsl-084-056-148-130.arcor-ip.net 1104698210 J * TheSeer ~theseer@border.office.salesemotion.net 1104698210 J * monrad ~monrad@213083190130.sonofon.dk 1104698210 J * nox ~nox@c135056.adsl.hansenet.de 1104698210 J * mboman ~michael@cm48.sigma230.maxonline.com.sg 1104698210 J * anonymous-coward ~nwalsh@shaggy.internode.com.au 1104698210 J * weasel ~weasel@weasel.noc.oftc.net 1104698361 Q * nox Ping timeout: 484 seconds 1104698910 Q * sannes Read error: Connection reset by peer 1104700270 Q * Tbery Quit: Ukonèuji 1104700314 J * nox ~nox@c135056.adsl.hansenet.de 1104701243 Q * we2by Read error: Connection reset by peer 1104701260 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104705352 M * we2by I have problem with named 1104705364 M * _are_ bind9 problem is described in the faq 1104705384 M * we2by it is named 8 1104705400 M * Doener hm, bind8 should work 1104705406 M * Doener any messages? 1104705407 M * we2by if I put 10.0.0.26 in resolv.conf, i can resolv hostnames 1104705416 M * we2by but if I use 127.0.0.1, it doesn work 1104705449 M * we2by when I use 10.0.0.26, some one outside the lan, thus on the internet, does not work. but work for me 1104705462 M * we2by work for me means, when I am logged into the vserver 1104705477 M * we2by I have my router forward port configured 1104705563 M * we2by any idea? 1104705636 M * Doener can you provide a dump of the network traffic? 1104705659 M * we2by hold, I am testing it 1104705667 M * we2by i put 10.0.0.26 as my localhost 1104705706 M * _are_ 127.0.0.1 can't be reached by vservers if you don't explizitly add it to the vservers interfaces 1104705717 M * we2by what>? 1104705739 M * we2by what if I add 10.0.0.26 localhost to my /etc/hosts file? 1104705754 M * we2by and then add nameserver localhost to my /etc/resolv.conf 1104705758 M * Doener _are_: any request going to 127.0.0.1 is automagically rewritten to go to 'whatever is your vserver's first ip address' 1104705760 M * _are_ then everything that *resolves* localhost will work 1104705787 M * we2by it works for me 1104705789 M * _are_ Doener: can't testify this for my vservers, looked different, but can't test atm 1104705791 M * Doener s/requests/packets/ 1104705795 M * we2by but it does not work for some one else 1104705838 M * _are_ well, if the application has 127.0.0.1 hardcoded, it won't work, ofc 1104705838 Q * we2by Read error: Connection reset by peer 1104705843 M * _are_ hmpf 1104705868 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104705870 Q * we2by Quit: 1104705880 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104705882 M * Doener + } else if (s_addr == 0x0100007f) { 1104705882 M * Doener + /* rewrite localhost to ipv4root */ 1104705882 M * Doener + s_addr = ipv4root; 1104705882 M * Doener + s_addr1 = ipv4root; 1104705884 M * Doener ;) 1104705891 J * sannes ~ace@home.skarby.no 1104705900 M * we2by maybe I need to bind named to the ip 1104705911 M * _are_ well, named runs in a vserver? 1104705912 M * we2by know how to bind named to a given ip? 1104705915 M * we2by yes, 1104705935 M * _are_ bind it to * and it is bound to all interfaces this specific vserver can access 1104705955 M * _are_ and I'd *always* use an IP for nameserver, much less hassle 1104705975 M * we2by yea, I just tested it 1104705978 M * we2by it works in my lan 1104705986 M * we2by but not for some one else outside my lan 1104705990 M * we2by wanna test it? 1104706001 M * _are_ means your router does some nat? 1104706041 M * we2by my router is configured to forward port 53 1104706071 M * _are_ to the specific IP of the vserver running bind? 1104706087 M * we2by yep 1104706090 M * we2by 10.0.0.26 1104706104 M * we2by 81.70.208.9 thatÅ› my ip 1104706109 M * we2by can u please test my name server? 1104706126 M * we2by you are allowed to scan it 1104706128 M * we2by if u want to 1104706188 M * _are_ hmm, no response 1104706201 M * we2by thatÅ› the problem 1104706206 M * _are_ Doener requested a tcpdump, can you see the packets of my request? 1104706211 M * we2by maybe I should bind named to the ip 1104706224 M * _are_ doubt that. 1104706252 M * we2by jc:~# netstat -anp | grep named 1104706252 M * we2by (Not all processes could be identified, non-owned process info 1104706252 M * we2by will not be shown, you would have to be root to see it all.) 1104706252 M * we2by tcp 0 0 10.0.0.26:53 0.0.0.0:* LISTEN 18427/named 1104706252 M * we2by udp 0 0 10.0.0.26:53 0.0.0.0:* 18427/named 1104706254 M * we2by udp 0 0 10.0.0.26:32829 0.0.0.0:* 18427/named 1104706256 M * we2by unix 2 [ ACC ] STREAM LISTENING 87638 18427/named /var/run/ndc 1104706258 M * we2by unix 2 [ ] DGRAM 87636 18427/named 1104706291 M * we2by how do I do the tcpdump 1104706291 M * we2by ? 1104706323 M * we2by I tested it with another box on my lan 1104706325 M * we2by itÅ› working 1104706348 M * _are_ tcpdump is a program 1104706378 M * _are_ you probably need to call it from the main server similar to this: tcpdump -n port 53 1104706405 M * we2by tcpdump running 1104706406 M * we2by try now 1104706422 M * _are_ running 1104706461 M * _are_ you see anything? 1104706474 M * Doener is your local net 10.0.0.0/8 or do you use that for your vservers only? 1104706474 M * we2by yep 1104706474 M * we2by # tcpdump -n port 53 1104706475 M * we2by tcpdump: listening on eth0:server1 1104706475 M * we2by 13:54:10.312210 10.0.0.25.32834 > 194.134.5.55.53: 37388+ PTR? 5.0.0.10.in-addr.arpa. (39) (DF) 1104706475 M * we2by 13:54:10.339441 194.134.5.55.53 > 10.0.0.25.32834: 37388 NXDomain 0/1/0 (116) 1104706531 M * we2by wait 1104706541 M * we2by I am gonna run it on the host os and the vserver 1104706557 M * we2by try now 1104706559 M * _are_ this is not my request, seems it doesn't even get forwarded into your network correcty 1104706569 M * _are_ trying... 1104706586 M * _are_ done 1104706611 M * we2by http://pastebin.com/193729 1104706614 M * we2by host OS 1104706636 M * we2by http://pastebin.com/193730 1104706638 M * we2by guest 1104706647 M * we2by this is vserver 1104706685 M * _are_ my ip is not in there 1104706698 M * we2by mhhh 1104706711 M * _are_ -> your router probably doesn't forward the request 1104706760 M * Doener we2by: what does your setup look like? what are the ip addresses of router, host and vserver? (you may answer that in private if you like to) 1104706768 Q * we2by Read error: Connection reset by peer 1104706771 J * we2by ~we2by@dc5146d009.adsl.wanadoo.nl 1104706773 M * we2by try now 1104706825 M * we2by can u resolve hostnames? 1104706833 M * _are_ we2by: no response, can you see my ip 84.56.148.130 in dump anywhere? 1104706920 M * we2by nope 1104706949 M * we2by it isport 53 right? 1104706955 M * Doener 23:54:34 Doener is your local net 10.0.0.0/8 or do you use that for your vservers only? 1104706996 M * we2by itÅ› my localnet 1104707005 M * we2by all my boxes use 10.0.0.x 1104707045 M * Doener ok, your forwarding rule says public port = private port = 53, target ip address = 10.0.0.26, right? 1104707068 M * we2by yes 1104707077 M * we2by I can telnet to port 53 from the outside 1104707092 M * we2by maybe I really should bind named to 0.26 1104707175 M * Doener you should at least see the packages coming into the box 1104707187 M * we2by can u try again? 1104707198 M * we2by I am looking at it 1104707202 M * we2by this is weird 1104707264 M * we2by _are_, can u try again? 1104707272 M * _are_ erm, telnet is tcp, dns need 53/udp 1104707287 M * we2by I have udp too 1104707290 M * _are_ no answer 1104707292 M * we2by ahhh 1104707296 M * we2by I know whatÅ› wrong 1104707375 J * we2byy ~we2by@dc5146d009.adsl.wanadoo.nl 1104707375 Q * we2by Read error: Connection reset by peer 1104707378 M * we2byy try it now 1104707381 M * we2byy it should work now 1104707390 M * _are_ works 1104707395 M * _are_ blocked some udp? 1104707414 M * we2byy yea, I should chose for udp and not tcp 1104707424 M * _are_ :-) 1104707431 M * _are_ then I am asleep now 1104707439 N * _are_ are|afk 1104707440 M * we2byy nite 1104707440 M * Doener good night _are_ 1104707454 M * are|afk nn 1104707518 M * we2byy but I want named to bind to an ip 1104707525 M * we2byy is that posible? 1104707560 M * Doener according to your netstat output it is bound to 10.0.0.26 only 1104707575 M * we2byy I hope so 1104707598 M * Doener well, how many ip addresses has that vserver assigned? 1104707606 M * we2byy one atm 1104707610 M * we2byy but I want more 1104707669 M * Doener then for now, it will never bind to more addresses than 10.0.0.26 1104707708 M * Doener later, you'll probably have to take a look at the bind documentation to find out how to tell it, which ip addresses to bind to 1104707990 Q * Loki|muh Ping timeout: 480 seconds 1104708077 J * Loki|muh loki@satanix.de 1104708561 N * Bertl_oO Bertl 1104708587 M * Bertl evening folks! 1104708714 M * we2byy helo Bertl 1104708736 M * Bertl Doener: well, no, would be 2k bitfield, but maybe we can further reduce that ... (but it fits on a page anyway) 1104708751 M * Bertl hey we2byy! got another 'y' ? 1104708789 M * dominance wb Bertl ;) 1104708819 M * Doener ok, then i'll finish that... 1104708849 M * Bertl but, you ahve to 'adjust' it to 1.9.3.16 1104708870 M * Bertl hey dominance! 1104708953 M * Doener .16? you're too fast ;) 1104708974 M * Bertl was cleaning up the rcu stuff, and applied it to the network code too 1104709027 M * Bertl I'll upload in a few minutes 1104709213 M * Bertl btw, is the bitfield just for trying it, or do you have any 'argument' why this is better? 1104709226 M * Bertl (as I said, I'm not against it) 1104709389 M * Bertl ndim: you around? 1104709614 M * dominance Bertl. he was some time ago.. 1104709622 M * Doener i kind of dislike the spinlock in __loc_vx_info... 1104709675 M * Bertl you need to do atomic bitops then ... 1104709696 M * Bertl (i.e. test and set must be done in one step 1104709738 M * we2byy I have problem with a MTA 1104709745 M * Bertl and this has do be done in __vx_dynamic...() 1104709754 M * we2byy qmail is running, but when doing netstat -anp, I don see it 1104709769 M * Doener i don't want to remove it completely but move it into __vx_dynamic_id 1104709833 M * Doener lock -> find_first_zero_bit -> set_bit -> unlock 1104709838 M * Bertl hmm ... okay ... (MODPOSTing now) ... 1104709867 M * Bertl we2byy: can you connect to your qmail fro another host (or the host)? 1104709891 M * we2byy I think my host is allready using port 25 1104709892 M * Doener or maybe find_next_zero_bit and if none found find_first_zero_bit for the beginning of the mask, to keep current behaviour of xid assigning 1104709910 M * we2byy and my qmail , postfix nox, is trying to bind to * port 25 1104709915 M * we2byy that would cause an error 1104709923 M * Bertl we2byy: well, then the qmail can't be running correctly, right? 1104709928 M * we2byy nope 1104709936 M * we2byy I got error message in debug 1104709952 M * Bertl you can use the v_smtp script on the host 1104709971 M * Bertl (or restrict the number of ips in the qmail config) 1104710145 M * we2byy Jan 2 14:54:55 jc postfix/master[5918]: fatal: bind INADDR_ANY port 25: Address already in use 1104710229 Q * monrad Remote host closed the connection