1102032049 M * rs re 1102032053 M * rs Bertl: yeah 1102032068 M * rs soon in my bed :) 1102032080 M * Bertl busy lately, it seems ... 1102032093 M * Bertl (busy with other stuff, that is) 1102032099 M * rs you ? 1102032105 M * Bertl no you ;) 1102032148 M * rs oh yeah quite busy those days 1102032158 M * rs I would like to test NGNET pretty soon 1102032168 M * Bertl go ahead ... 1102032175 M * Doener hm, strange... i just reverted the start-time-fix in 2.6.10-rc2-vs1.9.3.7 and it seems to change nothing... 1102032313 M * rs ok so bed time now, see you tomorrow dudes 1102032318 M * Bertl Doener: did you check with an unpatched kernel yet? 1102032321 M * Bertl night rs! 1102032327 M * rs thx 1102032331 Q * rs Quit: bed 1102032460 M * Doener Bertl: unpatched like? 1.9.3? 1102032483 M * Bertl unpatched like 2.6.10-rc2 ;) 1102032613 M * Doener how should i test uptime virtualization with that? 1102032658 M * Bertl no, I was referring to the process start time itself 1102032725 M * Doener as long as uptime virtualization is off, everything's fine. and yes, i had 2.6.10-rc2 running for some time to see how the values should look like 1102032759 J * eyck_ eyck@81.219.64.71 1102032787 Q * eyck Read error: Connection reset by peer 1102032983 M * Bertl Doener: http://vserver.13thfloor.at/Experimental/INFO/UPTIME_01.txt 1102033003 M * Bertl (that is with 2.6.10-rc2-vs1.9.3.7.1) 1102033169 M * Bertl the process start time is actually a delta, as is the 'uptime' or monotonic time itself 1102033191 M * Doener yeah, since boot 1102033209 Q * buddah Quit: Leaving 1102033235 M * Bertl exactly! to get the 'real' start time, userspace adds the 'assumed' startup time to the process start time 1102033272 M * Bertl the interresting part, you did miss so far is the assumed startup time ... 1102033312 M * Bertl look at my output and watch the changing start time for uptime ... 1102033436 M * Doener this looks confusing... 1102033460 M * Doener between for-loop 1 and 2 the start time of pid 27 changes, but not between loop 2 and 3 1102033499 M * Doener but for pid 31 it changes between 2 and 3 but not between 1 and 2 1102033522 M * Doener this doesn't make any sense to me 1102033640 M * Doener plus 27 moves into the future and 31 into the past 1102033668 M * Bertl interesting isn't it? 1102033859 M * Bertl now look at the ps processes and the time reported as 'current' time in the uptime 1102033969 M * Doener sometimes approx. correct 1102033985 M * Bertl 20:19:41 up 1 min, load average: 0.01, 0.00, 0.00 1102033992 M * Bertl root 76 0.0 1.0 2476 668 tts/0 R 20:29 0:00 ps auxww 1102034017 M * Bertl 20:17:56 up 10 min, load average: 0.00, 0.00, 0.00 1102034040 M * Bertl so system is up about 11 minute 1102034055 M * Doener 20:17:57 up 5 min, load average: 0.00, 0.00, 0.00 1102034058 M * Doener root 33 0.0 1.3 1868 844 tts/0 S 20:18 0:00 bash -c uptime && ps auxww 1102034065 M * Doener 20:21:23 up 3 min, load average: 0.16, 0.03, 0.01 1102034068 M * Doener root 97 4.3 1.3 1868 844 tts/0 S 20:21 0:00 bash -c uptime && ps auxww 1102034088 M * Doener those are (nearly) correct... 1102034104 M * Doener still looks 'random' to me 1102034164 M * Bertl no, those are coincidence ... 1102034196 M * Bertl okay, let me fix this up, then we talk about it ... 1102034380 Q * sebd Ping timeout: 480 seconds 1102038022 Q * ensc Ping timeout: 480 seconds 1102038233 M * Bertl Doener: sorry got distracted by a kernel bug ... 1102038240 M * Doener np 1102038258 M * Bertl do you have a vanilla 2.6.10-rc2 running? 1102038267 M * Bertl (or available) 1102038275 M * Doener can reboot in a few minutes 1102038294 M * Bertl what is currently running? 1102038314 M * Doener kind of 2.6.10-rc2-vs1.9.3.7 1102038329 M * Bertl okay, could you show me the output of /proc/uptime on the host, please? 1102038332 M * Doener dunno what i changed, but it was some stuff 1102038340 M * Doener cat /proc/uptime 1102038340 M * Doener 7159.88 6309.22 1102038347 M * Bertl interesting ... 1102038376 J * ensc ircensc@ultra.csn.tu-chemnitz.de 1102038412 M * Bertl Doener: thanks, no need to reboot then ... 1102039076 M * Doener what kind of kernel bug was/is that? 1102039118 M * Bertl do_posix_clock_monotonic_gettime() returns negative nsec values (under certain circumstances) 1102039453 M * Bertl Doener: details on lkml ... 1102039590 Q * ensc Ping timeout: 480 seconds 1102039605 J * ensc ircensc@ultra.csn.tu-chemnitz.de 1102042258 J * GhostXz GhosXz@CPE000d88a9ac16-CM014250035611.cpe.net.cable.rogers.com 1102042611 M * Bertl welcome GhostXz! 1102042623 M * GhostXz Hello! 1102042652 M * GhostXz I was just on this server and 'vserver' sounds cool so i came in ;p i have no clue what vserver is! 1102042672 M * Bertl read *topic and get one ;) 1102042677 M * matti LOOL 1102044355 M * sladen GhostXz: multiple OS installs on a single physical piece of hardware 1102044369 M * sladen (done efficiently) 1102044677 M * matti Hmm... 1102045475 M * Bertl Doener: sorry got distracted again ... here is the fix for the uptime stuff: 1102045476 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.10-rc2-vs1.9.3.7.1-uptime-fix01.diff 1102045645 M * Doener hm, i don't see any difference to the old code... except that you convert to clock_t early 1102045667 M * Bertl yes, basically the 'fix' itself wasn't necessary 1102045701 M * Doener so it's just the gettime bug? 1102045729 M * Bertl this and the fact that the clock value isn't exact 1102045752 M * Bertl processes might be created _before_ the context 1102045813 M * Bertl what I still don't know is, why we tried to fix anything in the first place ... 1102045841 M * Bertl (so I consider it a temporary fix until proven wrong ;) 1102045877 M * Doener because rs got start times into the future, though processes were started after the context was created 1102045913 M * Bertl I have a test cycle with qemu running, we'll see in half an hour or so ... 1102045950 M * Bertl and I'll test with 'adjusting' the time after that too ... 1102046859 Q * tchan Quit: leaving 1102047941 M * Bertl Doener: looks good so far ... will adjust the system time in a few minutes 1102048839 M * Bertl Doener: okay, even with time adjustments it looks really good here ... 1102048851 M * Doener great! 1102048872 M * Bertl of course, the start time is shifted if you change the host date 1102048877 M * Bertl but that was expected ... 1102049354 J * _no_x vps@213.39.193.233 1102049375 M * Bertl welcome _no_x! 1102049449 Q * no_x Ping timeout: 480 seconds 1102049453 N * _no_x no_x 1102049749 M * Bertl Doener: do you have a few minutes for me? 1102049755 M * Doener sure 1102049773 M * Bertl I'll forward you an email ... sec 1102050133 M * Doener hm, i tried that a good number of times without any success when i worked on clean namespaces 1102050195 M * Doener wow! you cleaned up the Experimental directory 1102050211 M * Bertl yes ;) 1102050238 M * Bertl Doener: I checked it, it works if you do not use namespaces 1102050258 M * Doener ok, that's something i didn't try 1102050284 M * Bertl but, what makes me think is the attached patch ... 1102050353 M * Bertl and I really do not know if I should consider this an evil attempt to weaken kernel code or just stupidity ... 1102050432 M * Doener you mean the *_set_inode_flags? 1102050440 M * Bertl yep, precisely ... 1102050441 Q * GhostXz Quit: 1102050556 M * Doener i'd go for the latter... probably something like 'uh, but i like ioctls'... 1102050575 M * Bertl yeah, given the background ... 1102050589 M * Bertl okay, thanks! 1102050665 M * Doener np 1102053246 M * Bertl btw, uploaded an IMHO proper fix to Experimental 1102053420 Q * ensc Ping timeout: 480 seconds 1102053627 J * ensc ircensc@ultra.csn.tu-chemnitz.de 1102053842 M * Bertl okay, have a good night everyone ... cya tomorrow ... 1102053858 N * Bertl Bertl_zZ 1102057172 Q * ensc Ping timeout: 480 seconds 1102057628 J * ensc ircensc@ultra.csn.tu-chemnitz.de 1102061471 J * sebd konversat@81.56.247.131 1102065465 Q * sannes Read error: Connection reset by peer 1102065814 Q * daniel_hozac iridium.oftc.net orion.oftc.net 1102065814 Q * cereal iridium.oftc.net orion.oftc.net 1102065838 J * daniel_hozac daniel@h212n1fls33o829.telia.com 1102065838 J * cereal cereal@ns1.starhosting.de 1102066005 J * rs rs@ice.aspic.com 1102066015 M * rs hi 1102066994 M * Val_away ho 1102066998 N * Val_away Val 1102067656 J * Hollow bene@home.xnull.de 1102068140 Q * Hollow Ping timeout: 480 seconds 1102070317 N * click ravenedge 1102070724 Q * ccooke Ping timeout: 480 seconds 1102070987 J * ccooke ccooke@spc1-walt1-4-0-cust221.asfd.broadband.ntl.com 1102072436 J * sannes ace@home.skarby.no 1102073055 P * ravenedge [IRSSI] 1102073749 J * ravenedge click@dsl-84-161.aal.tiscali.no 1102076001 J * Duckx duckx@195.75.27.158 1102078415 Q * anonymous-coward Ping timeout: 480 seconds 1102078797 J * th tom@pc-4092.ethz.ch 1102080362 J * grecea grecea@h-195-22-237-74.mdl.net 1102080365 J * grecea_ grecea@h-195-22-237-74.mdl.net 1102080389 P * grecea 1102081202 Q * grecea_ Remote host closed the connection 1102081450 J * grecea grecea@h-195-22-237-74.mdl.net 1102081460 J * grecea_ grecea@h-195-22-237-74.mdl.net 1102081544 J * Pazzo thomas@host130-250.pool8172.interbusiness.it 1102084606 Q * Val Quit: WE 1102085040 J * mboman michael@cm168.sigma231.maxonline.com.sg 1102091297 J * infowolfe infowolfe@66.179.81.30 1102091407 Q * Duckx Ping timeout: 480 seconds 1102091575 Q * infowolfe Quit: leaving 1102091903 N * Bertl_zZ Bertl 1102091933 J * Duckx duckx@195.75.27.158 1102092071 M * Bertl evening folks! 1102092469 P * grecea_ Leaving 1102092929 Q * Duckx Quit: Leaving 1102093797 J * Hollow bene@home.xnull.de 1102093915 Q * sannes Read error: Connection reset by peer 1102093982 Q * BWare Quit: using sirc version 2.211+KSIRC/1.3.10 1102094525 Q * Hollow Ping timeout: 480 seconds 1102094662 J * monrad monrad@213083190130.sonofon.dk 1102094669 M * Bertl welcome monrad! 1102094715 M * Bertl hey ravenedge! is that you click? 1102095045 M * monrad hi 1102100001 M * Bertl Doener: you around? 1102100021 M * Doener yep 1102100039 M * Bertl seems there are some issues left with the uptime/process time stuff 1102100060 M * Bertl I'll upload a recent version, maybe you see what is missing ... 1102100068 M * Bertl short description what I observed: 1102100136 M * Bertl 01:39:27 up 1:24, load average: 0.03, 0.02, 0.00 1102100136 M * Bertl USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1102100136 M * Bertl root 26 0.0 0.7 2748 436 tts/0 S 00:14 0:00 sleep 10000 1102100136 M * Bertl root 647 0.0 1.3 1868 844 tts/0 S 01:39 0:00 bash -c uptime && ps auxww 1102100139 M * Bertl root 652 0.0 1.0 2476 668 tts/0 R 01:39 0:00 ps auxww 1102100144 M * Bertl (uptime virt) 1102100151 M * Bertl 01:39:28 up 1:14, load average: 0.03, 0.02, 0.00 1102100151 M * Bertl USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1102100151 M * Bertl root 31 0.0 0.7 2748 436 tts/0 S 00:24 0:00 sleep 10000 1102100151 M * Bertl root 659 0.0 1.3 1868 844 tts/0 S 01:23 0:00 bash -c uptime && ps auxww 1102100155 M * Bertl root 664 0.0 1.0 2476 668 tts/0 R 01:23 0:00 ps auxww 1102100172 M * Bertl (uptime virt, started 10min later) 1102100201 M * Bertl see the 'current' process in the second get's a start time in the past 1102100232 M * Bertl the funny thing is, a few minutes later, in the same context, everything was fine ... 1102100296 M * Doener i somehow have the feeling that we somehow access the wrong context's uptime bias somewhere... 1102100352 M * Bertl yeah, that was my impression too, but we use task_* so that should be fine ... anyway I'll check that again ... 1102100434 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.10-rc2-vs1.9.3.8.1.diff 1102100445 M * Bertl (latest patch with a new nstime fix) 1102100712 M * Bertl Doener: I guess we should not care about the 'task' in the proc sequencer, we should check current for uptime virtualization, what do you think? 1102100726 M * Bertl - if (task_vx_flags(task, VXF_VIRT_UPTIME, 0)) { 1102100748 M * Bertl + if (vx_flags(VXF_VIRT_UPTIME, 0)) { 1102100782 M * Doener right, we probably currently mess up the stats in context 1 1102100853 M * Bertl that also allows us to move that out of the tasklist_lock again 1102101008 J * sannes ace@home.skarby.no 1102101035 M * Bertl welcome sannes! 1102101593 M * brc load average: 8.38, 8.64, 5.00 1102101598 M * brc BERTL! :) 1102101646 M * brc i am running the p2p(mldonkey) on my home server, and now i see how 2.6 sux.. i've allways used it, with 2.4 even with memory full and just swapping it was fine(on a p200 64ram) 1102101666 M * brc now with a celeron 850(256ram) , *KERNEL 2.6* , when it starts swappning everything gets really slow 1102101669 M * brc impossible to use the box 1102101816 M * Bertl hmm ... why do you hit swapping at all? 1102101852 M * Bertl and how is your system configured, and what kernel are we talking about ;) 1102102308 Q * rs Quit: leaving 1102102918 M * Bertl Doener: seems to work fine now .. still testing ... 1102103119 M * brc Bertl: cause mldonkey uses lot of memory 1102103120 M * brc heheh 1102103123 M * brc hmm 1102103128 M * brc servidor:~# vmstat 1102103128 M * brc procs memory swap io system cpu 1102103128 M * brc r b w swpd free buff cache si so bi bo in cs us sy id 1102103128 M * brc Segmentation fault 1102103147 M * brc weird 1102103152 M * Bertl aha ... sure your system is fine? 1102103270 M * Bertl Doener: you checked the bind[89] issues some time ago, do you remember what cap/action bind required? 1102103292 M * daniel_hozac Bertl: CAP_SYS_RESOURCE? 1102103292 M * brc Bertl: my 2 servers running 2.6.9-vs1.9.3 are segfaulting on vmstat 1102103294 M * Doener i didn't check that... 1102103305 M * Doener at least not that i remembe 1102103310 M * Doener remember even 1102103313 M * Bertl ah, okay thanks! 1102103317 M * Bertl daniel_hozac: sure? 1102103346 M * daniel_hozac Bertl: i'm not really sure what you're referring to. 1102103369 M * brc one of them just segfaults when inside a vserver 1102103397 M * Bertl maybe misconfigured proc security? 1102103414 M * Bertl daniel_hozac: did you test, does bind work fine with CAP_SYS_RESOURCE? 1102103468 M * daniel_hozac test what? i have bind running in a vserver, with a patch to disable the setting of CAP_SYS_RESOURCE. 1102103488 M * Bertl okay, let me rephrase that ... 1102103517 M * Bertl if you take the 0815 bind (which is shipped by every distro with --linux-caps enabled) 1102103539 M * Bertl and put it into a vserver, which has CAP_SYS_RESOURCE, does it work? 1102103567 M * daniel_hozac it should, as that's the only cap not in a vserver by default that's set by bind. 1102103625 M * daniel_hozac (bind/bin/named/unix/os.c is quite straight forward about the caps) 1102103684 M * Bertl hmm, okay, thanks! 1102105913 J * tchan tchan@c-24-13-81-164.client.comcast.net 1102105995 M * Bertl welcome tchan! 1102107197 T * * http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3 1102107197 T * Bertl - 1102107647 J * Nik Nik@cable-153-130.online.bg 1102107656 M * Nik hi all 1102107656 M * Bertl welcome Nik! 1102107762 M * Bertl Doener: everything seems silent ... what about a quick q3 match? 1102107802 M * Doener sounds good :) 1102109533 J * DuckMaster Duck@dyn-83-155-108-33.ppp.tiscali.fr 1102109962 Q * DuckKing Ping timeout: 480 seconds 1102110723 J * Shotygun shotgun@shotygun.com 1102111228 M * Bertl welcome Shotygun! 1102111241 M * Shotygun Hey Bertl how you doing 1102111270 M * Bertl fine thanks! and you? 1102111291 M * Shotygun Same ol' =) 1102111315 M * Bertl you are not here to play with the ngnet stuff, right? 1102111366 M * Shotygun No spare machine for booting at the moment I afraid =/ Mostly came to watch around and see what's new.. 1102111386 M * Bertl okay, np, keep watching ... 1102113862 M * Bertl okay, back later ... 1102113866 N * Bertl Bertl_oO 1102114422 Q * ntrs_ Quit: Leaving 1102115025 J * peca peca@213.235.108.13 1102115270 Q * monrad Remote host closed the connection 1102117648 Q * peca Quit: peca 1102117969 J * _sebd konversat@81.56.247.131 1102117969 Q * sebd Read error: Connection reset by peer