1281754868 J * SauLus_ ~SauLus@d065009.adsl.hansenet.de 1281755278 Q * SauLus Ping timeout: 480 seconds 1281755278 N * SauLus_ SauLus 1281757367 Q * ard Ping timeout: 480 seconds 1281757435 Q * sn00d Ping timeout: 480 seconds 1281761740 M * Bertl_oO off to bed now ... have a good one everyone! 1281761745 N * Bertl_oO Bertl_zZ 1281764172 J * mtg ~mtg@port-87-193-189-26.static.qsc.de 1281766836 J * imcsk8 ~ichavero@189.135.234.16 1281768094 Q * DLange Quit: thou shallst not update thy kernel 1281768728 J * ghislain ~AQUEOS@adsl2.aqueos.com 1281769364 Q * balbir_ Read error: Connection reset by peer 1281770355 Q * imcsk8 Quit: This computer has gone to sleep 1281775735 J * petzsch ~markus@dslb-088-075-161-178.pools.arcor-ip.net 1281776109 Q * petzsch Quit: Leaving. 1281776781 Q * mtg Quit: Verlassend 1281778756 J * petzsch ~markus@dslb-088-075-161-178.pools.arcor-ip.net 1281779506 Q * petzsch Quit: Leaving. 1281779604 J * petzsch ~markus@dslb-094-222-099-148.pools.arcor-ip.net 1281780280 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281780926 J * fleischergesell ~fleischer@dslb-088-077-221-032.pools.arcor-ip.net 1281781264 M * fleischergesell hi folks, i cant get VIRT_CPU to work - it keeps on showing the host cpu usage in the guests - VIRT_MEM and VIRT_LOAD do both work - i'm using 2.6.32-3-vserver-amd64 kernel 1281781516 Q * bonbons Remote host closed the connection 1281781537 J * BenG ~bengreen@cpc6-aztw22-2-0-cust100.aztw.cable.virginmedia.com 1281781555 Q * BenG 1281781577 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281782349 M * fleischergesell and for some other reason, i cant get cgroups to work either 1281782389 M * fleischergesell at startup, the vserver-util can't acces /dev/cgroup//tasks but instead a folder with some random id got created in /dev/cgroup 1281782438 M * fleischergesell if I manually create the folder, vserver complains about write operations not permitted... 1281782463 Q * theocrite Ping timeout: 480 seconds 1281782603 J * theocrite ~Hubert@kim.theocrite.org 1281782885 J * DLange ~DLange@dlange.user.oftc.net 1281782924 Q * bonbons Quit: Leaving 1281782967 J * pmenier ~pmenier@ACaen-152-1-39-91.w83-115.abo.wanadoo.fr 1281782976 J * mtg ~mtg@port-87-193-189-26.static.qsc.de 1281783973 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281785210 J * manana ~mayday090@84.17.25.149 1281785245 N * Bertl_zZ Bertl 1281785249 M * Bertl morning folks! 1281785421 M * fleischergesell hi Bertl - you got any idea about the cgroup-problem? This prevents me from starting the guest so the VIRT_CPU-Problem is of less importance at the moment 1281785468 M * fleischergesell the actual error msg is: /usr/lib/util-vserver/vserver.functions: line 1493: /dev/cgroup/buchhaltung/tasks: No such file or directory 1281785494 M * Bertl until-vserver/kernel version? 1281785546 M * fleischergesell 2.6.32-3-vserver-amd64, 0.30.215; Jun 18 2010, 13:35:17 1281785628 M * Bertl did you check when 0.30.215 was released? 1281785656 M * fleischergesell uhm no, its the package debian sid provides in the reps :| 1281785697 M * Bertl well, long before cgroups were invented :) 1281785729 M * fleischergesell grml 1281785769 M * fleischergesell why does debian sid includes such an old version in its unstable branch? damn debian folks 1281785792 M * Bertl I don't know ... :) 1281785807 M * fleischergesell so, my only go is to restart the host as I cannot umount /dev/cgroups for some reason 1281785823 M * Hollow maybe it's because util-vserver is in _pre* state like forever? ;) 1281785856 M * fleischergesell well, that might be the reason why debian does not include it 1281785890 J * balbir_ ~balbir@122.172.194.127 1281785961 M * fleischergesell but what I don get, in the wiki it says completely otherwise: http://linux-vserver.org/util-vserver:Cgroups 1281785994 M * fleischergesell "Currently the package linux-image-2.6.32-2-vserver-amd64 works well for cgroup scheduling" 1281786307 M * fleischergesell oh damn, i forgot to restart after last update... grml, the new utils-vserver will be up and running then - brb 1281786720 J * fleischermeister ~fleischer@dslb-088-077-220-177.pools.arcor-ip.net 1281786790 Q * fleischergesell Ping timeout: 480 seconds 1281786807 M * fleischermeister allright, cpusets with cgroup are working like a charm now - sorry for bothering you with my sillyness 1281786810 Q * theocrite Ping timeout: 480 seconds 1281786818 M * fleischermeister still, VIRT_CPU flag does not seem to work at all 1281786915 M * fleischermeister i can allways see full HOST cpu usage using top/htop in the guest - that doesnt seem right 1281786953 J * theocrite ~Hubert@kim.theocrite.org 1281787400 M * fleischermeister nobody a clue? 1281787511 J * derjohn_foo ~aj@88.128.64.167 1281787651 M * Bertl are you using the cfs part of cgroups for cpu limiting? 1281787699 M * fleischermeister I just use /etc/vservers/onetime/cgroup/cpuset.cpus 1281787725 M * Bertl with a separate CPU (or CPUs) assigned to the guest? 1281787748 M * fleischermeister well, I got a dualcore here, and I assigned cpu1 to this guest 1281787751 M * fleischermeister there is only 1 guest 1281787765 M * fleischermeister the guest correctly uses only this cpu 1281787766 M * Bertl and inside the guest, you see both CPUs? 1281787769 M * fleischermeister yes 1281787774 M * fleischermeister but it only uses the one I assigned 1281787800 M * fleischermeister still, I can see the cpu usage from the host, too (and any other possible guests i presume) 1281787802 M * Bertl well, I'd try with a more recent (preferably non-debian kernel :) 1281787812 M * fleischermeister hehe 1281787832 M * fleischermeister so, 2.6.32-3 is that outdated? 1281787837 Q * petzsch Quit: Leaving. 1281787847 M * Bertl no idea what it actually contains 1281787880 M * Bertl but note that the VIRT_CPU is not used in recent kernels/patches 1281787902 M * Bertl i.e. the 'virtualization' there is done by cgroups, so it is a cgroup issue 1281787906 Q * derjohn_mob Ping timeout: 480 seconds 1281787907 M * fleischermeister understand 1281787934 M * fleischermeister maybe I have to assign exclusively 1281787935 M * Bertl i.e. it might be required to add some patches 1281787965 M * fleischermeister well, its not _that_ important, I was just wondering if I could get it to work easily 1281788212 M * Bertl the cgroups CPU Accounting Controller should do what you want 1281788212 J * aj__ ~aj@80.187.241.41 1281788236 M * Bertl see Documentation/cgroups/cpuacct.txt 1281788473 Q * derjohn_foo Ping timeout: 480 seconds 1281788699 J * petzsch ~markus@dslb-094-222-099-148.pools.arcor-ip.net 1281788795 Q * petzsch 1281789262 M * daniel_hozac fleischermeister: util-vserver is more what you'd want to update... 1281789300 J * petzsch ~markus@dslb-094-222-099-148.pools.arcor-ip.net 1281789380 Q * petzsch 1281789401 N * DoberMann[ZZZzzz] DoberMann[PullA] 1281789705 Q * aj__ Read error: No route to host 1281791588 J * hparker ~hparker@2001:470:1f0f:32c:215:f2ff:fee0:9872 1281791603 Q * hparker Remote host closed the connection 1281792403 Q * manana Read error: Connection reset by peer 1281792428 J * manana ~mayday090@84.17.25.149 1281792716 Q * bonbons Quit: Leaving 1281792992 J * toom ~toom@rejna.docisland.org 1281793008 M * toom hi 1281793050 M * toom is it normal that I can write on /proc files, even unhided ? 1281793160 M * toom Opps, I mean : is it normal that I can't write on /proc files, even unhided ? (I can read them) 1281793166 M * daniel_hozac yes. 1281793174 M * daniel_hozac most proc files require you to have some capability. 1281793251 M * toom I add most bcapabilities (CAP_SYS_RAWIO CAP_MKNOD CAP_SYS_ADMIN CAP_IPC_LOCK CAP_IPC_OWNER) 1281793263 M * toom I want to modify /proc/mtrr 1281793680 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281793752 Q * balbir_ Ping timeout: 480 seconds 1281794309 J * allquixotic ~allquixot@tiyukquellmalz.org 1281794467 M * daniel_hozac why would you modify that? 1281794513 M * allquixotic Hi, I am using v2.6.35-vs2.3.0.36.31 and I noticed something strange about the patch. Every once in a while, my CPU load factor goes off the charts (also blocking out disk and network I/O) and dmesg prints out dozens of "cow inode: " lines with memory address, etc. I found the code that does it, it's in this patch, about 20% in, after an #ifdef CONFIG_VSERVER_COWBL. http://vserver.13thfloor.at/Experimental/patch-2.6.35-vs2.3.0.36.31.diff 1281794559 M * toom daniel_hozac: in order to run Xorg 1281794601 M * Bertl allquixotic: debug messages which probably slipped through, thanks for spotting 1281794603 M * toom it says that "System lacks support for changing MTRRs" 1281794644 M * Bertl toom: it's probably simpler to turn off the MTRR changes in the xorg.conf 1281794688 M * toom but the dri will not work 1281794730 M * allquixotic Bertl: Sure, no problem. However, I don't think only a few dozen printk(s) would peg my system for upwards of a minute, right? So maybe the performance problem would still be there if I removed the printks... 1281794757 M * Bertl we'll see, I'll remove the debug output and upload a delta/patch shortly 1281794775 M * daniel_hozac maybe something in your system is doing lots of COW operations. 1281794810 M * Bertl yes, a CoW link break actually means that the files need to be copied 1281794812 M * daniel_hozac you might want to check your cron logs. 1281794824 M * Bertl this is done in the kernel and thus results in some kind of I/O storm 1281794828 M * allquixotic What is the unit of time in the dmesg output, anyone? Is it seconds? 1281794889 M * Bertl seconds since startup (plus offset) 1281794913 M * Bertl the offset is negative to test for overflows IIRC 1281795053 M * allquixotic OK, the time delta between each cow inode: printk block is extremely variable, but it ranges between 10 minutes and 2 hours. So definitely not a cron job. 1281795065 M * allquixotic The number of lines printed varies between 12 and 120 or so. 1281795330 M * Bertl the message you get goes: 'cow inode: ...' yes? 1281795344 M * allquixotic [228793.188298] cow inode: ffff880316ba4680, flag=8000 1281795357 M * Bertl yeah, that doesn't mean that a CoW link break happens 1281795370 M * Bertl it is basically just the test for it ... 1281795391 M * Bertl so I'd suggest to remove the printk (as I said, delta will be up shortly) 1281795401 M * allquixotic I removed it :) 1281795416 M * Bertl good, I also assume that this will have no effect on the other issue 1281795461 M * Bertl do you, by any chance, use nfs, maybe with atime changes or even a raid system? 1281795475 M * allquixotic I use Linux-MD + LVM2 + ext4. No NFS. 1281795476 N * yang_ yang 1281795499 M * allquixotic My ext4 is mounted with defaults, maybe I should mount with noatime 1281795541 M * Bertl because I have been observing unresponsive systems (with or without Linux-VServer patch) caused by strange I/O wait in the kernel for some time (since 2.6.29 or so) 1281795551 M * allquixotic yes! 1281795577 M * allquixotic this has been a perennial problem for me, but the difference is that, with 2.6.33 + the vserver patch, I only had unresponsive / strange I/O wait when an intensive write operation was going on 1281795604 M * allquixotic I started several intensive read processes in parallel and the system was relatively fine, but a single dd if = ... would basically take down the network layer until it was done, for all intents and purposes. 1281795613 J * derjohn_mob ~aj@80.187.243.26 1281795621 M * allquixotic given that the of = was on disk 1281795674 M * allquixotic reading is still fine with 2.6.35, but now I've got this problem that crops up every few hours, and I'm 99% sure that there are no userspace processes that just decide to do huge writes all of the sudden, just because I upgraded my kernel 1281795692 M * allquixotic userspace has been static throughout, and I only upgraded it about 2 days ago. 1281795781 M * Bertl yeah well, I have a server machine, which basically acts as an nfs server, with moderate load, every now and then it happens that a mkdir will 'hang' forever 1281795797 M * Bertl ... until I issue a sync on the server, that is :) 1281795858 M * allquixotic this is a server machine as well 1281798926 J * petzsch ~markus@dslb-088-075-162-069.pools.arcor-ip.net 1281800690 J * imcsk8 ~ichavero@189.135.234.16 1281800690 Q * toom Read error: Connection reset by peer 1281800819 J * toom ~toom@rejna.docisland.org 1281801636 J * harobed ~sklein@arl57-1-82-231-110-14.fbx.proxad.net 1281802906 Q * mtg Quit: Verlassend 1281803260 Q * petzsch Quit: Leaving. 1281803271 Q * toom Read error: No route to host 1281803297 J * toom ~toom@rejna.docisland.org 1281804019 Q * toom Quit: leaving 1281805315 J * petzsch ~markus@dslb-088-075-162-069.pools.arcor-ip.net 1281806202 Q * manana Read error: Connection reset by peer 1281806223 J * manana ~mayday090@84.17.25.149 1281806232 Q * Piet Remote host closed the connection 1281807181 J * Piet ~Piet__@659AABMLF.tor-irc.dnsbl.oftc.net 1281808758 Q * imcsk8 Ping timeout: 480 seconds 1281813130 J * ntrs ~ntrs@77.28.167.211 1281814630 Q * pmenier Ping timeout: 480 seconds 1281815160 Q * petzsch Quit: Leaving. 1281815189 J * petzsch ~markus@dslb-088-075-172-220.pools.arcor-ip.net 1281815340 Q * bonbons Quit: Leaving 1281815633 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281817048 Q * harobed Ping timeout: 480 seconds 1281817048 Q * cuba33ci Read error: Connection reset by peer 1281817346 J * cuba33ci ~cuba33ci@111-240-207-156.dynamic.hinet.net 1281817507 J * harobed ~sklein@arl57-1-82-231-110-14.fbx.proxad.net 1281817755 Q * bonbons Read error: No route to host 1281817797 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281818631 J * tuxmania ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1281818631 Q * bonbons Read error: Connection reset by peer 1281819058 Q * harobed Ping timeout: 480 seconds 1281819400 J * harobed ~sklein@arl57-1-82-231-110-14.fbx.proxad.net 1281821101 Q * petzsch Quit: Leaving. 1281822013 Q * fleischermeister Ping timeout: 480 seconds 1281823394 Q * FireEgl Read error: Connection reset by peer 1281823518 N * DoberMann[PullA] DoberMann[ZZZzzz] 1281824118 Q * ntrs Ping timeout: 480 seconds 1281826513 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1281827041 Q * harobed Ping timeout: 480 seconds 1281829920 J * harobed ~sklein@arl57-1-82-231-110-14.fbx.proxad.net