1160698657 Q * bronson Quit: Ex-Chat 1160699519 Q * Piet_ Quit: Piet_ 1160702652 M * hardwire ok 1160702660 M * hardwire I just removed the files for a vserver I didn't think was running 1160702670 M * hardwire /etc/vservers/instance and the /var/data 1160702675 M * hardwire can I killall context somehow 1160702697 M * Bertl yes, there is a tool called vkill 1160702721 M * Bertl it will send signals to all tasks inside the context 1160702724 M * hardwire word 1160702743 M * hardwire that did the trick 1160702792 M * hardwire that was pretty stupid 1160702810 M * Bertl not that unusual ... happens now and then 1160702863 M * hardwire that vserver is a month old 1160702865 M * hardwire I thought it was gone 1160702866 M * hardwire heh 1160702945 M * Bertl yeah, one of the disadvantages over other technologies like VMware 1160702978 M * Bertl :) 1160703051 M * hardwire somebody just gave me a laptop they need fixed 1160703055 M * hardwire and.. they have the coolest laptop case 1160703279 M * hardwire jealous 1160704200 Q * starlein Quit: changing servers 1160704240 J * starlein star@fo0bar.de 1160704309 M * Bertl wb starlein! 1160705683 Q * ensc Killed (NickServ (GHOST command used by ensc_)) 1160705692 J * ensc ~irc-ensc@p54B4D35D.dip.t-dialin.net 1160705941 Q * DreamerC_ Quit: leaving 1160705960 J * DreamerC ~dreamerc@59-115-48-131.dynamic.hinet.net 1160706834 J * Aiken_ ~james@tooax8-100.dialup.optusnet.com.au 1160707162 Q * Aiken Ping timeout: 480 seconds 1160708899 Q * Johnnie Remote host closed the connection 1160708972 J * Johnnie ~jdlewis@216.75.24.218 1160709082 Q * Zaki Ping timeout: 480 seconds 1160709147 Q * ||Cobra|| Ping timeout: 480 seconds 1160709438 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1160709589 J * Loki|muh_ loki@satanix.de 1160709590 Q * Loki|muh Read error: Connection reset by peer 1160709602 N * Loki|muh_ Loki|muh 1160709961 Q * ||Cobra|| Ping timeout: 480 seconds 1160711239 J * ||Cobra|| ~cob@146.50.22.204 1160713269 Q * MrX Ping timeout: 480 seconds 1160715146 M * Bertl okay, I'm off to bed now ... have a good one everyone! 1160715156 N * Bertl Bertl_zZ 1160720367 J * dna_ ~naucki@p54BCF03F.dip.t-dialin.net 1160720879 J * meandtheshell ~markus@85-124-37-181.dynamic.xdsl-line.inode.at 1160722523 J * MrX ~urk@60.49.41.207 1160723055 Q * dna_ Quit: Verlassend 1160724172 Q * Aiken_ Ping timeout: 480 seconds 1160724682 J * gluk ~kvirc@breuss.ws.ehouse.ru 1160726063 J * ensc|w ~ensc@www.sigma-chemnitz.de 1160726097 M * ensc|w Bertl_zZ: hi, disabling CONFIG_VSERVER_HARDCPU does not help 1160726302 M * ensc|w (and makes things yet more worse) 1160726439 Q * virtuoso_ Ping timeout: 480 seconds 1160726893 M * matti ;) 1160726935 Q * Adrinael Ping timeout: 480 seconds 1160727798 J * virtuoso ~s0t0na@shisha.spb.ru 1160728095 Q * shedi Quit: Leaving 1160731861 J * shedi ~siggi@dsl-149-109-85.hive.is 1160732368 Q * nammie Ping timeout: 480 seconds 1160732656 J * nammie ~nam@S0106001195551ff0.va.shawcable.net 1160735147 J * Piet hiddenserv@tor.noreply.org 1160735550 Q * Piet Remote host closed the connection 1160735593 J * Piet hiddenserv@tor.noreply.org 1160736869 J * diingle ~diingle@tor-irc.dnsbl.oftc.net 1160737003 J * Zaki ~Zaki@212.118.110.193 1160737136 J * Piet_ hiddenserv@tor.noreply.org 1160737483 Q * Piet Ping timeout: 480 seconds 1160738412 J * Adrinael adrinael@hoasb-ff0edd00-43.dhcp.inet.fi 1160738501 Q * diingle Ping timeout: 480 seconds 1160739594 M * daniel_hozac ensc|w: that's at least consistent with the other reports. 1160740527 Q * ensc Ping timeout: 480 seconds 1160741914 J * ensc ~irc-ensc@p54B4FCCF.dip.t-dialin.net 1160745799 N * Bertl_zZ Bertl 1160745804 M * Bertl morning folks! 1160745930 M * Bertl doener, daniel_hozac: seems google is doing contains now too, but the code might be interesting, see here: http://lkml.org/lkml/2006/9/20/173 1160746400 M * daniel_hozac that sounds interesting. 1160746462 M * Bertl yes, trying to locate/exctract the patches now 1160747131 M * Bertl http://www.13thfloor.at/~herbert/containers2_0{1,2,3,4,5}.diff{,.hl,.bz2} 1160747147 M * Bertl (the last one is the interesting one) 1160747368 M * daniel_hozac basically avoids the per-page tagging by going from the tasks (with tagging)? 1160747494 M * Bertl which is exactly what I planned to do 1160747545 M * Bertl well, I skimmed over the lkml thread and the answers from the VM folks there 1160747569 M * Bertl and they suggest (as I figured too :) that this would be the best to do from the 'container' PoV 1160747584 M * Bertl i.e. make the 'overlimit' a containerized check 1160747645 M * Bertl anyway, I sent an email to Rohit, maybe he will show up here or contact me/us otherwise 1160747655 M * daniel_hozac cool. 1160748290 J * spTim ~chatzilla@port-212-202-35-211.dynamic.qsc.de 1160748301 M * spTim hi 1160748313 M * Bertl welcome spTim! 1160749000 M * Bertl spTim: what's up, can we help you? 1160749185 M * spTim bertl: I just wanted to join the irc channel. no probs atm :-) thx 1160749226 M * Bertl k, have fun! 1160749926 M * derjohn Bertl, contrainers by Google? What do they want to do differntly? Only a technical "its cleaner" thing? Or better performace? 1160749978 M * Bertl well, it's a very _simple_ patchset, so not compareable with a complete solution like Linux-VServer 1160749996 M * Bertl it is more compareable to cpusets for example 1160750075 M * Bertl we do not know about performance yet, but some ideas seem to be the same we had 1160750092 M * Bertl so it definitely goes into the direction we are heading towards 1160750134 M * Bertl and it seems that the paging/swap/overmemory stuff is very close to what we planned to implement 1160750205 M * Bertl so I hope that Rohit will show up here for a chat ... 1160750447 M * derjohn Bertl, and Google would be a strong partner/supporter if we could join forces .... 1160750498 M * Bertl well, as you know, personally I do not care about that :) 1160750641 J * coocoon ~coocoon@dslb-084-056-196-024.pools.arcor-ip.net 1160750648 M * Bertl welcome coocoon! 1160750670 M * coocoon hello 1160750782 Q * derjohn2 Ping timeout: 480 seconds 1160750783 J * derjohn2 ~aj@dslb-084-058-196-043.pools.arcor-ip.net 1160751306 J * rhodes ~rhodes@hc652a895.dhcp.vt.edu 1160751472 M * Bertl wb rhodes! 1160751520 M * derjohn Bertl, together you could rule the galaxy ;) 1160751531 M * derjohn (dont lose you hand, pls!) 1160751578 A * Bertl .o( should start building my 'empty handle' now ...) 1160751587 M * matti Bertl: Hello. 1160751598 M * Bertl hey matti! how's going? 1160751618 M * matti Bertl: Not bad, how about you? Better now? 1160751622 M * matti ;) 1160751678 Q * ensc|w Remote host closed the connection 1160751685 M * Bertl yes, a lot better .. what about your uk journey? 1160751701 M * matti Bertl: Good to hear! 1160751751 M * matti Bertl: Well, not bad. It's 3rd week now since I am here ;) 1160751800 M * Bertl great! thought it was less .. time goes by so fast 1160751812 M * matti ;] 1160751985 J * ensc|w ~ensc@www.sigma-chemnitz.de 1160752004 M * derjohn eb ensc|w ! 1160752017 M * derjohn wb ensc|w .. nice to see you here !!!!! 1160752564 J * bronson ~bronson@c-71-198-75-160.hsd1.ca.comcast.net 1160752577 M * Bertl wb bronson! 1160752612 M * bronson hey Bertl, just about to try setting up that vserver again. 1160752961 M * Bertl derjohn: do you ahve a working test setup for linux-vserver testing? 1160753031 M * harry daniel_hozac: how's the vserver.functions patch going? 1160753046 M * harry do we have a "stable" patch now? 1160753129 Q * rhodes Quit: Leaving 1160753261 Q * bronson Read error: Operation timed out 1160753273 J * bronson ~bronson@adsl-64-161-106-11.dsl.snfc21.pacbell.net 1160753386 J * stefani ~stefani@tsipoor.banerian.org 1160753410 M * Bertl hola stefani! 1160753413 M * derjohn Bertl, the remote reset cards only work with a windows tool. except that I ahve both linuxtag boxes here 1160753417 J * Ben81 ~Ben81@tipi0e.lri.fr 1160753417 M * stefani ciao 1160753434 M * Bertl derjohn: can you run some guests on them? 1160753438 M * derjohn ( Bertl and you could include rimcp patch in the kernel !!!) 1160753453 M * Bertl derjohn: I'd like to test a few 'printk' cases 1160753466 M * derjohn Bertl, I guess so. But I would tend to install them with mandriva for you 1160753478 M * Bertl i.e. stuff which should not happen, but I'd like to verify 1160753500 M * derjohn I can start them as they are ... probably rc15 or so ;) 1160753588 J * s0undt3ch_ ~s0undt3ch@bl9-225-18.dsl.telepac.pt 1160753591 M * Bertl well, I'll provide a patch for rc38 (with the printks) 1160753611 M * Bertl and I would appreciate if you could stress the system a little (while monitoring dmesg/syslog) 1160753637 M * derjohn stress? in which way? 1160753781 M * harry int main(){for(;;);} 1160753782 M * harry ? 1160753844 M * Bertl derjohn: typical action, start a few java processes and such 1160753871 M * Bertl apache, tomcat, mysql, qmail or so 1160753884 M * harry int main(){for(;;)calloc(4096);} 1160753885 M * harry ;) 1160753901 Q * mire Ping timeout: 480 seconds 1160753906 M * Bertl I'd like to have a multitude of different apps running, so that we check as many cases as possible 1160753938 M * Bertl (i.e. a variety, not 100 times the same hog) 1160754030 Q * s0undt3ch Ping timeout: 480 seconds 1160754030 N * s0undt3ch_ s0undt3ch 1160754219 M * matti Hi harry :) 1160754306 M * harry ahaaaaaa 1160754311 M * matti ? 1160754314 A * harry wrote a cool proggie! 1160754319 M * matti Yes? How so? 1160754328 M * harry : 17:45 lois ~ ;cat bleh.c 1160754329 M * harry #include 1160754329 M * harry int main(){for(;;)malloc(4096);} 1160754334 M * matti Oh my! 1160754339 M * matti Bizzare one. 1160754339 M * matti ;p 1160754870 Q * Loki|muh Ping timeout: 480 seconds 1160754888 Q * shedi Read error: Operation timed out 1160754977 J * Loki|muh loki@satanix.de 1160755945 J * shedi ~siggi@dsl-149-109-85.hive.is 1160755987 M * daniel_hozac harry: well, http://people.linux-vserver.org/~dhozac/p/uv/experimental/ns-cleanup.patch should be fine, IMHO. 1160756079 M * harry i'll try that one later on... 1160756086 M * harry i'll keep you posted :) 1160756096 M * harry looks ok :) 1160756105 M * daniel_hozac only change from the last iteration is the reverse ordering. 1160756112 M * daniel_hozac which was the only problem left, no? 1160756118 M * harry yeah 1160756355 M * harry daniel_hozac: it might be a good idea to comment WHY we reversed the list, and WHY the unmount loop is seperate... for future reasons ;) 1160756400 M * daniel_hozac yeah, but i wanted to get the final version done before commenting it ;) 1160756416 M * daniel_hozac same reason i haven't updated doc/configuration.xml yet and committed it ;) 1160756445 M * harry daniel_hozac: are there more patches for 211 ? 1160756518 M * daniel_hozac well, there's the vyum 3.0 fix. 1160756573 M * harry gandalf:/usr/src# vserver stdserver enter 1160756573 M * harry stdserver:/# cat /proc/mounts 1160756573 M * harry rootfs / rootfs rw 0 0 1160756573 M * harry /dev/root / reiserfs rw,noatime 0 0 1160756573 M * harry none /proc proc rw,nodiratime 0 0 1160756576 M * harry none /tmp tmpfs rw,nodev 0 0 1160756578 M * harry none /dev/pts devpts rw 0 0 1160756581 M * harry that's all... is that correct? 1160756587 M * harry /dev/mapper/vservervg-stdserverlv /vservers/stdserver reiserfs rw,noatime 0 0 1160756596 M * harry i'd think that one should be in there or so... 1160756616 M * daniel_hozac nah, not inside the guest. 1160756619 A * harry doesn't use vyum, so no need for that ;) 1160756627 M * daniel_hozac you'll have to peek into the namespace to get the real list. 1160756629 M * harry /dev/root ? 1160756636 M * harry ? 1160756641 M * harry huh 1160756649 M * daniel_hozac vnamespace -e stdserver cat /proc/mounts 1160756660 M * harry thats what i pasted ;) 1160756663 M * daniel_hozac when you enter the entire guest, you're further restricting your view to the filesystem. 1160756675 M * harry ah, no 1160756676 M * harry i get it :) 1160756677 M * daniel_hozac (with the chroot, some mount hiding, etc.) 1160756719 M * harry all good now 1160756722 A * harry totally happy :) 1160756725 M * harry tnx daniel_hozac 1160756732 M * harry and the rest, for vserver ;) 1160756745 M * harry now... f0000000000000000d 1160756768 M * daniel_hozac you're welcome! 1160756801 M * harry btw. i read about some openvz virtualisation stuff going into 2.6.19 1160756806 M * harry is that true, or just a rumor? 1160756878 M * daniel_hozac i don't know how OpenVZ is involved, but there are definitely virtualization stuff going in to 2.6.19. 1160756904 M * daniel_hozac IPC-, utsname- and pidspaces, according to that ML-post. 1160756924 M * Bertl it is code _we all_ agreed upon (so far) 1160756931 M * bronson hm... it would be nice if newvserver would stop if it couldn't retrieve a particular package, then resume where it left off when the problem is fixed... 1160756961 M * Bertl harry: so once again OVZ managed to focus on PR :) 1160756962 M * bronson I just spent some time wading around a broken vserver before I realized that the mirror I was using gave up halfway through the install. 1160756972 M * daniel_hozac bronson: AFAIK the only one maintaining newvserver is Ola, so you'd have to tell him (he doesn't frequent the channel). 1160756989 M * bronson Bertl: that ovz crap is the reason I'm here and not there. It was a choice between the two. 1160757009 M * daniel_hozac bronson: but i believe it's just using debootstrap, so i guess that's where the bug really belongs. 1160757039 M * daniel_hozac bronson: if it indeed is a bug. what's the exact behaviour you're experiencing? 1160757045 M * Bertl bronson: interesting, could you describe the benefits/drawbacks you personally saw/had/discovered? 1160757065 J * bronson_ ~bronson@c-71-198-75-160.hsd1.ca.comcast.net 1160757116 M * Bertl bronson: we are always interested in feedback from folks comapring OVZ and Linux-VServer 1160757124 M * Bertl *comparing 1160757165 M * bronson_ (wireless is getting really flaky around my apartment...) 1160757181 Q * Ben81 Quit: Leaving 1160757230 M * bronson_ Bertl: Well, I chose to go with linux-vserver because it looked more legit, less glossy marketing garbage. 1160757255 M * bronson_ If I ever have a need to check out ovz, I'll report back. 1160757260 M * Bertl okay, fair enough ... 1160757301 Q * shedi Ping timeout: 480 seconds 1160757489 Q * bronson Ping timeout: 480 seconds 1160757822 J * shedi ~siggi@dsl-149-109-85.hive.is 1160758427 J * dna_ ~naucki@p54BCF20B.dip.t-dialin.net 1160758569 Q * bronson_ Ping timeout: 480 seconds 1160758580 J * bronson_ ~bronson@adsl-64-161-106-11.dsl.snfc21.pacbell.net 1160758609 M * bronson_ Looks like I need to give it a specific context ID...? 1160758678 M * bronson_ AWESOME, that was it. 1160758689 Q * ||Cobra|| Read error: Operation timed out 1160758693 M * bronson_ Had to create /etc/vservers/NAME/context with a random number in it. 1160758700 M * bronson_ Seems a strange thing to do but it works. 1160758711 M * bronson_ Going to work, ttyl. 1160758713 M * daniel_hozac only if you disable dynamic contexts. 1160758728 M * bronson_ Hm. I didn't enable or disable anything... I don't think? 1160758738 M * bronson_ How do I disable dynamic contexts? Is that a compile-time thing? 1160758743 M * daniel_hozac yes. 1160758842 M * bronson_ Ah. Well, apparently I disabled them. :) I can live with setting the context file. 1160758859 M * bronson_ I 1160758873 M * bronson_ Bye folks. 1160758876 Q * bronson_ 1160759510 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1160759682 M * Borg- Bertl: is there a way to specifiy context number via vserver build ? 1160759682 Q * derjohn2 Read error: Connection reset by peer 1160759697 M * Bertl Borg-: sure, just use --context 1160759712 M * Bertl actually that is the way it is supposed to happen 1160759713 M * Borg- oh great.. seems I missed it reading manual 1160759736 M * Borg- xid is 16bit number ? 1..65535 ? 1160759770 M * Bertl yes, but 0 and 1 are reserved (for now) 1160759776 J * derjohn2 ~aj@dslb-084-058-193-244.pools.arcor-ip.net 1160759783 M * Borg- thx :) 1160759790 M * Bertl and the range between 49152 and 65535 is the dynamic range 1160759799 M * Bertl (i.e. you want something between 2 and 49151 1160759802 Q * coocoon Quit: KVIrc 3.2.0 'Realia' 1160759805 M * Borg- and dynamic is not going to be supported anymore? 1160759815 M * Bertl it is fading out right now 1160759821 A * harry started all physical servers with 100 200 300 400 500 etc... 1160759834 M * harry so easy merging in the future is possible without colliding xid's 1160759834 M * Bertl i.e. userspace will take over the dynamic assignment sooner or later 1160760041 J * Hollow_mobile ~bene@217.110.45.98 1160760047 A * Hollow_mobile waves 1160760050 J * Rich_Estill ~restill@c-24-11-195-139.hsd1.mi.comcast.net 1160760052 M * Bertl welcome Hollow_mobile! 1160760053 M * daniel_hozac hey Hollow_mobile! 1160760064 M * Hollow_mobile hey Bertl! LTNS! 1160760072 M * Bertl indeed 1160760088 M * Hollow_mobile and yeah.. wheel is ok for daniel_hozac ;) 1160760115 M * harry haha... kokanin did it again... 3 local DoS'es on friday 13th :) 1160760121 M * harry for fbsd... :) 1160760124 M * Hollow_mobile T-5 until my DSL line should be up and running 1160760127 M * daniel_hozac Hollow_mobile: the guest had some reboot problems last time it got rebooted. 1160760140 M * Borg- harry: hmm? 1160760141 M * Bertl Hollow_mobile: sounds good 1160760145 M * Hollow_mobile rebooted? 1160760163 M * harry Borg-: he released 3 dos exploits on FD (and milw0rm) 1160760205 M * daniel_hozac Hollow_mobile: i don't know why it restarted, but it was hung trying to start mysql, and then subsequently hung for apache2 and some other services... 1160760228 M * Borg- harry: uh... good that they are local :) 1160760240 M * Hollow_mobile strange.. 1160760240 M * harry yeah 1160760265 M * Hollow_mobile uhm... it seems the whole box got restarted 4 days ago... very strange 1160760280 M * daniel_hozac Hollow_mobile: yeah, looked a lot like the fifo issues with the newer baselayout. 1160760286 M * Hollow_mobile i heard sth about power outage, but this box should have UPS 1160760298 M * daniel_hozac maybe the power outage was too long? 1160760320 M * Hollow_mobile i see, i.e. still no solution found for the fifos? 1160760325 M * Hollow_mobile probably... 1160760358 M * daniel_hozac no, but at least i can't reproduce the issues outside of the boot process. 1160760381 M * daniel_hozac and it seemed to read from the same fifos multiple times. 1160760428 M * Bertl okay, I fixed the X mouse poiner issues :) 1160760436 M * daniel_hozac oh? what was the problem? 1160760461 M * Bertl tricky, the problem itself is a missing context switch on certain interrupts 1160760478 M * Bertl but, it was exposed by the chagnes to the pid_task() 1160760505 M * Bertl so we'll add some debug code there to track that in the future 1160760509 M * Hollow_mobile daniel_hozac: probably only scripts in the boot runlevel have the necessary dependencies to trigger the issue 1160760530 M * Bertl daniel_hozac: the good news is, this _might_ as well fix the mysql issues :) 1160760550 M * daniel_hozac ok, sounds great then! 1160760565 M * daniel_hozac Hollow_mobile: i guess so. 1160760570 M * Bertl yeah, will prepare a final patch in the next hour or so 1160760749 M * Hollow_mobile daniel_hozac: fyi, there was a short circuit after the UPS, so it was quite useless this time... :( 1160760817 M * daniel_hozac ouch! 1160760828 M * daniel_hozac did any of your equipment get damaged? 1160760971 M * Hollow_mobile not sure yet, but our box is ok... another server behaves quite strange, but i have not logged in there for months, so it might as well be another issue caused by the customer... 1160761130 M * daniel_hozac hehe. 1160761778 J * bronson ~bronson@66.160.177.208 1160762364 M * doener Bertl: heh, I pointed that patch series out to you IIRC ;) (google, container) 1160762822 M * Bertl really? probably was already affected by that flu then 1160762830 M * doener ;) 1160762992 M * Hollow_mobile ok folks... i'm off again... cu on wednesday :)) 1160762996 M * doener btw, I plan to give the port to .19-rc1 another try today 1160763001 M * Bertl Hollow_mobile: okay, cya! 1160763015 M * daniel_hozac cya Hollow_mobile! 1160763017 M * Bertl doener: ah, I thought that was a 'work in progress :)' 1160763021 Q * Hollow_mobile Quit: Leaving 1160763037 M * Bertl (i.e. didn't realize you gave up last time) 1160763037 M * doener Bertl: I tried different approaches and failed over and over again ;) 1160763062 M * doener reverse rebasing (ie. rebase .19-rc1 on .18-vs2.1.1-rcX) was a total failure. 1160763102 M * doener incremental rebasing (ie. push the base forward only a bunch of commits at a time) was more successful but still pretty dumb 1160763144 M * doener I gave up on that when I hit the OCFS changes ;) your mainline and vserver versions had a bunch of conflicts and I didn't feel like resolving them back then 1160763186 M * doener primarily because I had no idea how to adapt the private inode(?) struct that the code uses 1160763219 M * Bertl yes, the OCFS2 folks included a slightly modified version of my patches 1160763234 M * doener will try to break down the vserver patch into a patch series (lkml style) and incremental rebase with that 1160763279 M * Bertl it might make sense to forward port 2.0.2.1 first and only add the delta ontop later 1160763303 M * Bertl especially as the 2.0.2 can be broken out very easily 1160763327 M * doener broken out in lkml style or your style? ;) 1160763334 M * Bertl my style :) 1160763389 M * Bertl seriously, would you think that the lkml style would still make sense after more than a year of changes? 1160763433 M * Bertl that would be like breaking down the linux vfs into 'understandable' patches 1160763484 M * doener well, I'd expect the patch series to be adapted over time, not just extended 1160763529 M * doener and naive me expects that to work out somehow :) 1160763532 M * harry don't give me more work here! :) 1160763544 M * harry (sounds like i really do stuff here, doesn't it ;)) 1160763614 M * Bertl yes, you simply _must_ be doing all the hard work here :) 1160763629 A * harry looks left... 1160763635 A * harry looks right... nothing there either 1160763642 M * harry so... i must be doing all the work here! 1160763654 M * harry (which is true... in real life, but not on this project) 1160763695 M * harry but... i did something useful here... i helped daniel_hozac fix a bug! 1160763820 A * harry off for a while... cya'll 1160764036 M * doener http://lkml.org/lkml/2006/10/11/266 -- funny :) 1160764112 M * daniel_hozac that means pre_div[*pre] * -*pcr, right? 1160764487 M * doener yep 1160764658 Q * shedi Quit: Leaving 1160764697 M * Bertl ntrs: ping? 1160764744 M * ntrs Bertl, yes? 1160764765 M * Bertl the mysql issues, did you observe them on x86_64 too? (with a 64bit kernel)? 1160764824 M * ntrs I am not 100% sure but I don't think so. 1160764837 M * Bertl that would match the profile perfectly ... 1160764853 M * Bertl because x86_64 uses a different irq handling 1160764855 M * ntrs what profile? 1160764865 M * ntrs Ok, are you saying it was fixed? 1160764877 M * Bertl I'm currently preparing a patch which fixes something completely different 1160764904 M * Bertl but I think, according to the data I have here, that it might be the cause for the mysql behaviour too 1160764921 M * ntrs ok, is this fix in mainline or the vserver patch? 1160764933 M * Bertl it's in the vserver patch 1160765029 M * ntrs so, there will be rc39? if so, when? 1160765047 M * Bertl there will be at least a patch in about half an hour 1160765057 M * Bertl and definitely an rc39 lateron 1160765080 M * ntrs I am very interested to see the patch. 1160765229 J * xinu ~xinu@85.158.38.43 1160765232 P * xinu 1160766218 M * Rich_Estill Is that MySQL issue with it running on the host or in a vserver? 1160766253 M * Bertl in a vserver, the issue seems to be some kind of starvation 1160766328 M * Bertl i.e. a multi threaded mysql (under certain conditions) ends up with tables locked 1160766736 M * Rich_Estill but only on x86_64? 1160766748 M * Bertl nope, on x86 not on x86_64 1160766775 M * Borg- Bertl: hmm.. w/ some specific vserver settings?? (i.e: HARD CPU LIMITS) 1160766781 M * Borg- or always..? 1160766808 M * Borg- because I run java stuff.. on vserver.. w/ quite some threads.. 1160766856 M * Bertl always but it really depends on the actual setup, and I'm not really sure it is tied to the fix 1160766886 M * Borg- hmz.. 1160766970 M * Borg- home my folks will fix stuff in next week.. so I could prepare for guest servers and do some heavy tests.. 1160766973 M * Borg- s/home/hope/ 1160766981 M * Borg- s/for/4/ 1160766983 M * Borg- damn typos 1160767687 M * Rich_Estill Hmm. I have an app I wrote in Java that I am moving to a vserver that uses alot of threads. I will find out how well it works for me. 1160767735 M * Bertl good, please report back any issues you encounter 1160768116 M * Borg- Rich_Estill: cool, let me know about that :) 1160768259 J * Blissex ~Blissex@82-69-39-138.dsl.in-addr.zen.co.uk 1160768388 Q * ensc Ping timeout: 480 seconds 1160769232 J * ensc ~irc-ensc@p54B4FCCF.dip.t-dialin.net 1160769780 Q * dna_ Quit: Verlassend 1160770068 J * bonbons ~bonbons@83.222.36.111 1160770475 M * Bertl okay, here are the fixes/changes (agreed the irq one is the sledge hammer version, and we might cut back on that lateron) 1160770500 M * Bertl http://vserver.13thfloor.at/Experimental/delta-doirq-fix01.diff 1160770506 M * Bertl http://vserver.13thfloor.at/Experimental/delta-notify-fix01.diff 1160770511 M * Bertl http://vserver.13thfloor.at/Experimental/delta-warn-fix01.diff 1160770539 M * Bertl I'm doing some cleanups/checks now and will then release rc39 1160771104 M * Bertl derjohn2: would be great if you could give those a spin 1160771157 M * Bertl bonbons: ping? 1160771193 M * doener http://lwn.net/Articles/204275/ -- we need additional archs in linux so Hollow can make a similar announcement ;) 1160771248 M * Bertl wow, what a breakthrough! I would never have imagined that :) 1160771288 J * mire_ ~mire@79-167-222-85.adsl.verat.net 1160771295 J * wolbo ~wolbo@234-213-dsl.kielnet.net 1160771309 M * Bertl please, somebody be so kind and post a follow-up/comment there, otherwise I might write something 'not so nice' :) 1160771313 M * Bertl welcome wolbo! 1160771329 P * wolbo Kopete 0.11.92 (0.12 Beta 1) : http://kopete.kde.org 1160771727 M * Blissex which breakthrough? 1160771744 M * Bertl OVZ finally managed to support PowerPC 1160771813 M * Blissex Bertl: ahhhhh, does not seem that amazing or important to me... 1160771827 M * Bertl now if they add, ARM, Alpha, Mips/32 and Sparc/64 as well as HPPA/64 (and a few others), they are finally equal to Linux-VServer regarding arch support :) 1160771883 M * Bertl well, I didn't realize that LWN was soo much into payed advertizements 1160771911 M * doener I doubt that it is paid. The just put everything online they get 1160771921 M * doener s/The/They/ 1160771942 M * Bertl really? so maybe we should really send every change we do there? 1160771966 M * Bertl fascinating breakthrough, Linux-VServer supports 2.6.18 kernel!! 1160771967 M * Blissex Bertl: that's how things work in the industry... 1160772005 M * Blissex Bertl: but doesn't OpenVZ also support some sort of resource management? Isn't VServer purely about virtualization of resources? 1160772018 M * Bertl completely wrong 1160772036 M * Bertl we mainly do _isolation_ even on resources 1160772053 M * Bertl accounting of resources is as complete as in OVZ 1160772056 M * Blissex Bertl: yes, I meant ''isolation'' for virtualization. 1160772093 M * Bertl same goes for the limits, nothing I could identify in OVZ as 'resource management' which would not be possible with Linux-VServer ... 1160772097 M * Blissex Bertl: but accounting is one thing. I sort of remember that in resource containers one can set CPU quotas per ''container'' etc. 1160772106 M * Bertl so? 1160772126 M * Bertl that is done with out scheduler for more than a year now 1160772129 M * Bertl *our 1160772172 M * Bertl and trust me, the current Linux-VServer scheduler is a lot more flexible as the vcpu stuff in OVZ 1160772211 Q * Piet_ Quit: Piet_ 1160772211 M * Blissex Bertl: ahhh I hadn not noticed the VServer sheduler aspect. 1160772316 M * Bertl daniel_hozac: any patches you queued up (and I'm still missing in rc38)? 1160772343 M * daniel_hozac nope. 1160772519 M * Bertl daniel_hozac, doener: I wonder if the vx_map_pid() on the pgrp (as we do it in tty_io) is correct? 1160772582 M * bonbons Bertl: pong 1160772610 M * Bertl hey, I have a few network related questions/topics, do you have a few minutes? 1160772734 M * Rich_Estill c-ya all monday 1160772736 P * Rich_Estill Leaving 1160772737 M * bonbons I do, just tell, hopfully I'm not too tired ;) 1160772789 M * Bertl well, first I wonder if we should put any code into the kernel which deals with combining and building ip/mask/sets 1160772825 M * Bertl i.e. if we shouldn't better make a simple but powerful interface for userspace, where 'ip sets' could be assembled 1160772840 M * Bertl example for illustration: 1160772865 M * Bertl - guest has ip 10.0.0.1/30 1160772881 M * bonbons on that part I'm not so sure either, adding single IPs should really be possible, e.g. combining them into ranges (1 + 2 + 3 => 1-3, but 1 + 3 + 2 not necessarly 1-3) 1160772884 M * Bertl - userspace adds ips 10.0.0.2 and 10.0.0.3 ... 1160772899 M * Bertl exactly 1160772908 M * Bertl I would prefer to leave that to userspace 1160772927 M * Bertl this adds an interesting follow-up question though 1160772947 M * Bertl how can userspace 'build up' such a set without disturbing a running guest? 1160772964 M * bonbons that's also my thought, building efficient but complex sets should not happen in kernel as it's prone to contain bugs 1160772986 M * Bertl and I think the solution is really simple here, we just need to disconnect the 'sets' from the network contexts 1160773022 M * bonbons Adding ips at start/ent of existing ranges or combine an existing address with a new one to a rage should be supported by kernel for old versions of interfaces 1160773027 M * Bertl this way, a new set can be prepared (maybe even tested) and then switched in for one (or even several) network contexts 1160773060 M * Bertl bonbons: I don't think we need to support 'old' interfaces (for adding or removing) in an efficient manner 1160773081 M * bonbons for the rest, userspace should atomically overwrite the configuration, e.g. atomically replace pointer to the set 1160773083 M * Bertl bonbons: i.e. if the add really 'just' adds an ip to the list, that is probably fine 1160773092 J * FCOJ ~mordur@dsl-201-4.hive.is 1160773110 M * Bertl and if a remove fails, because there is a range configured, that is a clear userspace issue then 1160773122 M * Bertl (and we can reply with EINVAL or something like that) 1160773125 M * Bertl welcome FCOJ! 1160773173 M * bonbons Just appending to range is not so efficient as it only works in very limited scenairo when consecutive addresses are added in-order 1160773193 M * Bertl forget the range, IMHO we have two scenarios 1160773195 M * bonbons I think 1 + 2 + 3 sould end into 1-3 1160773206 M * Bertl - old userspace tools, no ranges 1160773212 M * Bertl - new userspace tools, full power 1160773236 M * bonbons anything else should should be done by new tools 1160773243 Q * Blissex Read error: Connection reset by peer 1160773302 M * Bertl okay, that's basically what I wanted to know for today :) 1160773317 M * bonbons that way is acceptable to 1160773364 M * bonbons regarding IPv4 and IPv6, I think we should split them into two distinct source files, but keep them similar 1160773442 M * bonbons that is, split out anything that is used for IP isolation into vserver/ipv4.c or net/ipv4/vserver.c (same for v6) and just keep the generic part network.c 1160773506 M * Bertl sounds like a plan 1160773568 M * bonbons If I can find out how to extract a diff between two revisions from git I can send you my current work in that area 1160773606 M * Bertl shouldn't git-diff be able to do that? 1160773654 M * bonbons I don't know how to tell it both revisions, taking what git-log tells does not work :( 1160773699 M * Bertl http://www.kernel.org/pub/software/scm/git/docs/git-diff.html 1160773869 M * Bertl daniel_hozac, doener: any opinion on the tty stuff? 1160773886 J * Hurga nobody@p508AAEB1.dip0.t-ipconnect.de 1160773913 P * stefani I'm Parting (the water) 1160773978 M * Bertl welcome Hurga! 1160774013 M * Hurga Hiya. 1160774333 M * bonbons Bertl: look here http://people.linux-vserver.org/~bonbons/vserver-2.6.17.6-vs2.1.1-rc26-net-20061013.diff 1160774400 M * Bertl okay, great! 1160774401 M * bonbons that's kind of what I did in splitting out IPv4/IPv6 specific code into own source files and some work towards masks/ranges 1160774480 M * Hurga IPv6? Great! :) 1160774522 M * Bertl yep, ipv6 is finally on my todo list (and with a little luck, will be ready for testing end of this year) 1160774549 M * matled are there any plans to export information to the proc filesystem instead of using vserver() to get information? like the stuff vserver-stat does, this could be quite handy to be available in /proc/ 1160774551 M * bronson Bertl: what platforms DOES linux-vserver run on? 1160774556 M * bronson I'm not seeing anything on the web site... 1160774606 M * daniel_hozac Bertl: aren't process groups pids of the group leader, and thus the mapping makes sense? i'm not quite sure about how these things work. 1160774637 M * Bertl well, if so, we should probably remap process groups too 1160774648 M * daniel_hozac don't we already though? 1160774649 M * Bertl (which we do not do atm) but IIRC, they are allocated separately 1160774678 M * daniel_hozac sys_setpgid seems to at least use some mapping functions. 1160774691 M * Bertl bronson: it's a little hidden: http://oldwiki.linux-vserver.org/Syscall+Switch+Info 1160774723 M * Bertl bronson: we probably need to list it more explicielty somewhere on the new wiki, and also include which archs are actually tested 1160774747 M * bronson Definitely. I just assumed that because I didn't see any mention of platforms, linux-vserver only worked on 386. 1160774753 M * bronson Glad that was a bad assumption! 1160774771 M * Bertl yeah, we (try to) support all linux archs (naturally) 1160774787 M * Bertl support for Xen (as arch) and UML is also there 1160774811 M * Hurga vserver on Xen? cool. :) 1160774835 M * daniel_hozac matled: umm, you mean like /proc/virtual/? 1160774852 M * matled daniel_hozac: something like this 1160774877 M * Bertl matled: actually we try to move away from the proc interface, as it is kind of problematic 1160774897 M * daniel_hozac sucks for parsing, for instance :) 1160774902 M * Bertl matled: race conditions, locking, huge overhead compared to the vserver interfaces 1160774903 M * daniel_hozac or well, parsing sucks. 1160775106 M * Bertl daniel_hozac: we do not remap PIDTYPE_PGID atm, do we? 1160775156 M * daniel_hozac so i am misinterpreting the purpose of the vx_*map_pid calls in sys_setpgid? 1160775167 M * matled mh, how would I iterate over all running vservers? vserver-stat| grep -vE '^([^0-9]|[01] )' | awk '{print $8}'? 1160775201 M * daniel_hozac or, ls -1 /proc/virtual | egrep -v 'status|info'? 1160775253 M * matled ah, there are information available through /proc? :) 1160775277 M * Bertl hmm, right, we map there back and forth .. but I'm not convinced that is correct ... 1160775361 J * bronson_ ~bronson@66.160.177.208 1160775372 Q * bronson Ping timeout: 480 seconds 1160775411 M * Bertl daniel_hozac: ah, well, I think we do not need to spend too much thoughs on that, it will go away soon, when the pid space patches get into mainline 1160775454 M * daniel_hozac they aren't already? 1160775492 M * daniel_hozac i was under the impression they weren't, but that ML-post seemed to indicate (according to google translate.... i guess that's why) they wre. 1160775673 M * Bertl well, they are in rc1 in a test version 1160775694 M * Bertl so yes, they _are_ in mainline, but not in 2.6.18 1160775829 Q * mire_ Ping timeout: 480 seconds 1160775862 J * mire_ ~mire@79-167-222-85.adsl.verat.net 1160775900 Q * bronson_ Read error: Connection reset by peer 1160776225 Q * mire_ Quit: Leaving 1160776720 M * Bertl daniel_hozac, doener: seems like testfs.sh fails on test 116 (remove file from different context) 1160776781 M * Bertl is that intended with the CoW changes? 1160776804 Q * h01ger Quit: h01ger 1160776807 J * h01ger ~holger@socket.layer-acht.org 1160776808 Q * meandtheshell Quit: exit (0); 1160776811 M * Bertl if so, is there an updated version around? 1160776853 M * matled most of the files in /usr/bin have the immutable flag set, I did not do it, has it something to do with unify/hashify? 1160776877 M * Bertl very likely, they should also have a second flag set 1160776887 M * Bertl check with showattr (should list U and I) 1160776888 M * matled lsattr shows only i 1160776903 M * Bertl also the link count of those files should be >1 1160776926 M * matled UI is set 1160777000 M * matled dpkg has some problems here, it tries to do a chmod on one of those files and fails 1160777029 M * Bertl should work fine with rc38++ 1160777065 M * matled so there is a problem with 2.6.17.13-vs2.0.2.1? 1160777087 M * Bertl nope, no problem, just a feature which is not in the stable branch 1160777102 M * Bertl (CoW, Copy on Write) 1160777140 M * Bertl the dpkg issue is a debian oddity, which simply requires to exclude such 'problematic' binaries from unification 1160777270 M * matled is there any easy way to 'de-unify' a vserver? 1160777301 M * Bertl yes, IIRC, there was a script to do that 1160777331 M * Bertl alternative is to copy it and/or break the links manually 1160777376 M * Bertl daniel_hozac: did you test with testfs.sh? 1160777421 M * Bertl (maybe we should have a special feature flag for that, to test both cases?) 1160777567 M * Bertl fs: ping? 1160777589 T * Bertl http://linux-vserver.org/ <- new and shiny | latest stable 2.02.1, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.1.1-rc39, stable+grsec 2.0.2.1 | util-vserver-0.30.211 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1160777724 M * Bertl fs: rc39 should fix the issues you observed with X, please let me know if that is true and/or if you get funny messages in the kernel log (with VSERVER_DEBUG enabled) 1160777785 M * matled so upgrading to the development version would help in my case? are there many (known) problems with this version? :) 1160777891 M * daniel_hozac Bertl: hmm, no, i don't think so. 1160777927 M * daniel_hozac i must be missing how that could happen. IMHO the COW-changes are rather minimal. 1160777951 M * Bertl matled: with rc39, there should be _no_ known issues :) 1160777964 M * matled where can I find the patch? 1160778044 M * Bertl ensc, ensc|w: please let me know how rc39 works for you 1160778333 M * daniel_hozac Bertl: hmm, is that test still supposed to fail? shouldn't the chmod break the link? 1160778349 Q * bonbons Quit: Leaving 1160778407 M * Bertl daniel_hozac: yes, that's what I mean 1160778467 M * daniel_hozac ok, i'm on the same page now then :) 1160778762 J * shedi ~siggi@inferno.lhi.is 1160781902 M * doener Bertl: http://lkml.org/lkml/2006/10/13/287 -- does that apply to linux-vserver? (blend through init) 1160781916 M * doener I'm still reluctant to update to .18 1160781937 M * doener read as: can't check ;) 1160782864 M * Bertl yep, could apply, but as 90% of the init access is disallowed, it might as well be handled already 1160782899 Q * shedi Quit: Leaving 1160782917 M * Bertl doener: if you provide a test script/tool, I'll check for you :) 1160782928 J * shedi ~siggi@inferno.lhi.is 1160782953 M * doener cd /proc/1/root ? 1160783195 M * Bertl cd /proc/1/root 1160783196 M * Bertl bash: cd: /proc/1/root: No such file or directory 1160783308 M * Bertl but it seems to have other reasons (i.e. the entire init process is unaccessible now) 1160783323 M * Bertl dejavu? 1160783738 M * Bertl yep, the init is canceled out with the latest changes 1160783753 M * Bertl will have to adjust that and retest 1160783896 M * Bertl is it just me, or is the ongoing pid stuff causing more and more issues with fakeinit ...