1301356878 M * Bertl geb: hey, I just read the email from Maxence, but I have no idea what it means .. I did reply though, stating that ...
1301358219 J * ensc ~irc-ensc@p5DF2DF3C.dip.t-dialin.net
1301359540 Q * Romster Ping timeout: 480 seconds
1301359757 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1301362997 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1301364760 Q * ser Quit: leaving
1301365398 Q * hparker Remote host closed the connection
1301365589 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1301367526 Q * hparker Quit: Quit
1301368392 J * ser ~quassel@host1.tldp.ibiblio.org
1301374621 M * Bertl off to bed now ... have a good one everyone!
1301374625 N * Bertl Bertl_zZ
1301375807 Q * ntrs Read error: Operation timed out
1301375853 J * ntrs ~ntrs@vault08.rosehosting.com
1301378310 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1301379625 J * ghislain ~AQUEOS@adsl2.aqueos.com
1301380995 Q * derjohn_mob Ping timeout: 480 seconds
1301382756 J * derjohn_mob ~aj@213.238.45.2
1301384747 J * Hunger ~Hunger@Hunger.hu
1301387334 J * bonbons ~bonbons@2001:960:7ab:0:35a7:ea84:4188:f0a5
1301388895 J * kir ~kir@swsoft-msk-nat.sw.ru
1301390680 P * kir Leaving.
1301394337 Q * ncopa Quit: Leaving
1301395086 J * thierryp ~thierry@zankai.inria.fr
1301395106 J * thierryp_ ~thierry@zankai.inria.fr
1301395205 Q * thierryp_ 
1301395216 Q * thierryp Remote host closed the connection
1301397399 Q * Romster Ping timeout: 480 seconds
1301399034 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1301402701 Q * LuckyLuke Quit: new kernel
1301402956 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it
1301403027 Q * ikerc_ Read error: Connection reset by peer
1301403281 M * SwenTjuln hi!
1301403299 M * SwenTjuln I've a question regarding CGroups
1301403329 M * SwenTjuln did they remove cpu.cfs_* files?
1301403389 M * daniel_hozac yes
1301403401 M * daniel_hozac it was a patch that hasn't been merged yet that was included while it worked.
1301403487 M * SwenTjuln oh...
1301403499 M * SwenTjuln thank you
1301403506 M * SwenTjuln so what should we use now?
1301403534 M * daniel_hozac there is no equivalent.
1301403543 M * daniel_hozac so be merry and let your guests run amok!
1301403549 M * daniel_hozac :)
1301403622 M * SwenTjuln huh... I didn't expect that
1301403640 Q * bsingh Read error: Connection reset by peer
1301403709 M * SwenTjuln anyway, tnx for info
1301403722 M * daniel_hozac yeah, mainline isn't the fastest...
1301404391 J * bsingh ~balbir@122.172.160.202
1301405074 M * arekm  util-vserver scripts created nice /dev/cgroup tree even if /dev/cgroup wasn't actually mounted at all heh, so it just created various text files
1301405192 M * daniel_hozac what created /dev/cgroup?
1301405245 M * arekm "static" dir, part of dev package
1301405331 M * daniel_hozac so why didn't you run the initscript?
1301405432 M * daniel_hozac should be fixed now...
1301405507 M * arekm I have own initscript which lacks cgroup mounting
1301405534 M * arekm since it was mounted by other script... and failed now due to bug in that other script
1301405724 Q * bsingh Ping timeout: 480 seconds
1301405750 A * LuckyLuke upgraded my pa-risc to 2.6.38.2-vs2.3.0.37-rc9
1301406281 J * bsingh ~balbir@122.172.206.215
1301407384 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1301408375 Q * LuckyLuke Quit: new kernel
1301408739 J * LuckyLuke ~luca@host65-83-static.228-95-b.business.telecomitalia.it
1301409604 N * Bertl_zZ Bertl
1301409610 M * Bertl morning folks!
1301409778 Q * hijacker_ Ping timeout: 480 seconds
1301409952 J * hijacker_ ~hijacker@213.91.163.5
1301410304 J * dowdle ~dowdle@scott.coe.montana.edu
1301413676 Q * hparker Quit: Quit
1301414555 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1301415012 Q * Romster Ping timeout: 480 seconds
1301415774 Q * hparker Remote host closed the connection
1301416020 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1301416675 Q * derjohn_mob Ping timeout: 480 seconds
1301416964 M * Mr_Smoke Hm
1301416979 M * Mr_Smoke Bertl: can I pastebin a kernel BUG and have your opinion whether it's vserver related ?
1301417043 M * Mr_Smoke Bertl: here : http://paste.linux-vserver.org/19016
1301417067 M * Bertl sure
1301417114 M * Bertl do you have the kernel build tree at hand?
1301417187 M * Mr_Smoke yeah
1301417205 M * Bertl then please try the following inside the kernel tree
1301417211 M * Mr_Smoke Shoot
1301417251 M * Bertl addr2line -e vmlinux c13a328e
1301417275 M * Mr_Smoke skbuff.c:0
1301417289 M * Bertl hmm, so probably no debug info there
1301417297 M * Mr_Smoke Probably not
1301417314 M * Bertl okay, let me see what I can pinpoint from the data available
1301417324 M * Bertl I presume you cannot trigger it at will, yes?
1301417493 M * Mr_Smoke Not really
1301417495 M * Mr_Smoke BUT
1301417500 M * Mr_Smoke It might be a RAM problem
1301417510 M * Mr_Smoke I'm in touch with the ISP, I'll probably have the DIMMs tested soon
1301417543 M * Mr_Smoke But any information from you would be priceless
1301417690 M * Bertl well, it doesn't look like a Linux-VServer issue, to start with
1301417697 M * Mr_Smoke aha.
1301417718 M * Bertl but it looks like it happened in skb_has_frag_list()
1301417741 M * Mr_Smoke I'm not familiar with this one. What does it do ?
1301417757 M * Bertl basically just check for an existing list
1301417771 M * Mr_Smoke I mean, what does skb stand for ?
1301417798 M * Bertl ah, that's the type of buffer packets (within sockets) are stored
1301417805 M * Mr_Smoke Oh ok.
1301417817 M * Bertl i.e. sk stands for socket, and b for buffer
1301417823 P * dkg 
1301417826 M * Mr_Smoke I see
1301417870 M * Bertl if you consider the ram bad, I wouldn't spend any thoughts on that, it would fit perfectly fine
1301417913 M * Bertl OTOH, if the ram is fine, it could be a mainline bug, potentially freeing up a page too soon and then using it for a check
1301417964 M * Mr_Smoke Maybe it'd make sense to investigate the changelog for 2.6.38
1301417967 M * Bertl as the stack trace contains a probe for a system sensor chip, it might have been the catalyst to trigger the issue
1301418013 J * M4LV4D0 ~nielson@189.82.5.76
1301418019 M * Mr_Smoke No mention of skb* anywhere :/
1301418027 M * Mr_Smoke Bertl: yeah, I was wondering about that too
1301418037 M * Mr_Smoke thing is, I don't use sensors on this machine
1301418041 M * Mr_Smoke I wonder what does though
1301418046 M * Bertl basically the trace suggests that _something_ received a tcp packet which got freed (probably after use) which in turn lead to this page fault
1301418071 M * Mr_Smoke there's a reference to "ircd" in there
1301418078 M * Mr_Smoke ircd is a vserver xid
1301418078 M * Bertl Mr_Smoke: lsmod | grep w83
1301418089 M * Mr_Smoke I don't use modules :)
1301418096 M * Mr_Smoke But the chip support is there
1301418102 M * Mr_Smoke Question is, who polled it
1301418117 M * Mr_Smoke There's no sensord or anything
1301418126 M * daniel_hozac i think that's unrelated.
1301418128 M * Bertl well, if you compiled it in, it should be loaded at bootup and probed
1301418148 M * Bertl so, check /sys/class/hwmon/ it should be there
1301418154 M * Mr_Smoke Oh it's there alright
1301418164 M * Mr_Smoke But I thought you meant something polled the sensor
1301418168 M * Mr_Smoke might have misunderstood you there
1301418179 M * Bertl nah, and probably unrelated in this case as well
1301418202 M * Bertl my assumption was a module probe could have triggered the delay for the page fault
1301418220 M * Mr_Smoke Ah ok
1301418220 M * Bertl (but without modules, no probe :)
1301418223 M * Mr_Smoke Yeah :)
1301418259 M * Bertl for the ram check part, I can suggest the following easy tests you can do at runtime:
1301418294 M * Bertl - compile a kernel tree with -j 99 at least 10 times, and compare the output (after sorting)
1301418324 M * Mr_Smoke What output ? the binary img ?
1301418344 M * Bertl nah, that will surely differ, the actual stderr/out 
1301418360 M * Mr_Smoke hm ok, what should I be looking for then ?
1301418379 M * Bertl if you get strange errors or gcc/binutils complaining in some of them you definitely have a memory or CPU/bus problem
1301418382 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1301418405 M * Mr_Smoke Ah I see
1301418424 Q * M4LV4D0 Quit: • Breakfast of champions •Cebolinhav9.4• www.cajau.com
1301418477 M * Bertl - run a dedicated memory test, there are some like this one: http://people.redhat.com/dledford/memtest.shtml
1301418485 M * Mr_Smoke I'll have the ISP do that yeah
1301418524 M * Bertl and of course, there is memtest86+ (which needs to be started from the bootloader AFAIK)
1301418563 M * Mr_Smoke Yes, that's what I thought you were referring too actually
1301418565 M * Mr_Smoke I'll try that shell script
1301418586 M * Bertl but the kernel build is a rather decent test, it identified problematic machines where memtest was happily crunching away without error :)
1301418711 M * Bertl for CPU testing, the StressCPU from folding@home has proven to push a modern CPU to the limit (power wise) so it's a nice thing to run on burn-in tests :)
1301418732 J * ktwilight ~keliew@91.176.95.191
1301418750 M * Mr_Smoke Here goes then
1301418753 M * Bertl (especially as it bails out on the first error)
1301418777 M * Mr_Smoke Well I'll run memtest, then the cpu build test
1301418800 M * Mr_Smoke D'you reckon I should try upgrading to 2.6.38.2 ?
1301418813 M * Bertl but do not mix tests, because they usually try to stress a certain subset, and if you run them at the same time, they even out to some degree
1301418820 M * Mr_Smoke Sure
1301418846 M * Bertl well, I discovered a rather nasty issue with 2.6.38 a few days ago, and found out that it was fixed in 2.6.38.1 :)
1301418873 M * Bertl but this was regarding hot plug and sata 
1301418907 M * Mr_Smoke Ah, ok. Not really a concern here I'd say
1301419057 M * Bertl in general, I'd always prefer a 2.6.x.y release over a 2.6.x (or 2.6.x.z with z < y) because those release are solely done to fix bugs and known issues
1301419073 M * Bertl *releases
1301419250 M * Mr_Smoke 'right
1301419273 M * Mr_Smoke Hows 2.3.0.37 going btw ?
1301419723 M * Bertl slowly but steady
1301419764 M * Mr_Smoke does it look like the next stable yet ? :)
1301419820 M * Bertl nah, we need to do quite some more stabilization till then (testing and cleanups)
1301419830 M * Mr_Smoke 'k
1301419871 M * Bertl but we should go out of rc in the next upload
1301419908 M * Bertl (as it seems we found all pending issues and fixed them for 2.6.38+)
1301419959 M * Bertl daniel_hozac: any issues with vs2.3.0.37-rc9 you know of?
1301420066 M * Mr_Smoke There's another thing that's causing me to believe it might be a ram problem
1301420082 M * Mr_Smoke I have an almost identical setup (8G RAM though instead of 4) with the same kernel
1301420099 M * Mr_Smoke And it's been running longer, with more load, without a glitch
1301420109 M * Mr_Smoke That's not much 
1301420201 M * daniel_hozac Bertl: hmm, none that i know of.
1301420301 M * Bertl okay, one missing 'feature' I'm aware of is the priority bias interface
1301420391 M * Bertl the question there is, do we want to reinstate a partially working sched interface or add a completely new one for this and similar purpose or drop the feature completely
1301420569 M * daniel_hozac hmm
1301420586 M * daniel_hozac i guess adding a new interface when we already have one seems wasteful.
1301420591 M * daniel_hozac i suppose we can up the version though.
1301420612 J * imcsk8 ~ichavero@148.229.1.11
1301420655 M * Bertl so, keep the syscall command, up the version and reduce the interface struct, yes?
1301420657 J * derjohn_mob aj@tmo-050-138.customers.d1-online.com
1301420663 M * daniel_hozac yeah
1301420668 M * Mr_Smoke One thing
1301420671 M * Mr_Smoke in the line : 
1301420672 M * Mr_Smoke Mar 29 17:53:47 [kernel] Pid: 4952, comm: ircd Not tainted 2.6.38-vs2.3.0.37-rc6 #1 Supermicro X7SBi/X7SBi
1301420676 M * Mr_Smoke What does "comm" stand for ?
1301420682 M * Bertl daniel_hozac: okay, I'll prepare a patch for review then ...
1301420692 M * daniel_hozac comm is the 16 character process name.
1301420707 M * Mr_Smoke I see
1301420710 M * daniel_hozac (command)
1301420713 M * Mr_Smoke Ah ok
1301420726 M * Mr_Smoke This, again, would point to a ram issue
1301420739 M * Mr_Smoke I4ve been running this particular verion of ircd for a while 
1301420752 M * daniel_hozac could be a race too.
1301420899 M * Mr_Smoke I'm not sure how I could diagnose this
1301421049 M * Mr_Smoke Bertl: when you said "sorting" the output for make -j 99, you litterally mean using sort ?
1301421060 M * Mr_Smoke just for clarity, or is there another purpose ?
1301421084 M * daniel_hozac -j99 will get you really jumbled output each run.
1301421087 M * daniel_hozac you can't compare them.
1301421090 M * daniel_hozac unless you sort first.
1301421110 M * Mr_Smoke ok
1301421318 M * Mr_Smoke Well
1301421321 M * Mr_Smoke That's odd
1301421326 M * Mr_Smoke Bertl: I get strange diffs
1301421337 M * Mr_Smoke such as
1301421337 M * Mr_Smoke 302d301
1301421337 M * Mr_Smoke <   CC      drivers/acpi/acpica/dsinit.o
1301421337 M * Mr_Smoke 1202a1202
1301421337 M * Mr_Smoke >   CC      kernel/power/main.o
1301421371 M * Bertl and you do something like:
1301421404 M * Bertl ( make clean; make ) 2>&1 | sort >runXXX.out
1301421676 M * Mr_Smoke yeah
1301421717 M * Bertl well, then it is indeed strange, use diff -NurpP and upload the output for closer inspection
1301422236 M * Mr_Smoke 'k, i'll start over
1301424032 Q * derjohn_mob Ping timeout: 480 seconds
1301424084 Q * arekm Quit: leaving
1301424108 M * Mr_Smoke Bertl: well, looks like sometimes, stuff is compiled that wasn't on the previous run
1301424114 M * Mr_Smoke weird, dunno if I should worry
1301424562 J * arekm arekm@carme.pld-linux.org
1301424747 M * arekm bah, libcgroup uses different cgroup layout than vserver, there are per subsystem subdirs in /dev/cgroup like cpu, cpuacct, memory etc
1301424809 M * arekm and each subsystem is mounted separately - this is probably cool because allows hierarchies for these which do support hierarchies
1301424840 M * arekm unfortunately looks like util-vserver is hardwired to one setup. Would be nice to use /proc/mounts to determine what is where and use that
1301424947 M * daniel_hozac or not.
1301424976 M * arekm Longer version please.
1301424992 M * daniel_hozac /proc/mounts is definitely not the right way to go.
1301425016 J * hijacker ~hijacker@87-126-142-51.btc-net.bg
1301425018 M * arekm what's the way to go?
1301425033 N * ensc Guest487
1301425043 J * ensc ~irc-ensc@p5DF2E5F1.dip.t-dialin.net
1301425126 M * daniel_hozac anything but that.
1301425174 M * daniel_hozac personally, i prefer one mount point.
1301425231 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1301425249 M * arekm with one mount point hierarchies don't work. With multiple (http://pastebin.com/abdtmFbP) they work (just checked that)
1301425268 M * arekm (don't work in all cases of course ;)
1301425348 M * arekm I don't see where to get what's mounted where info for cgroup other than mounts
1301425440 Q * Guest487 Ping timeout: 480 seconds
1301426262 M * daniel_hozac configuration?
1301426271 M * daniel_hozac as for everything else.
1301426291 M * daniel_hozac hierarchies work fine, as long as you use hierarchy supporting subsystems.
1301426335 M * daniel_hozac (why subsystems that don't get merged, i have no idea. it seems like you should either support the system fully or not do it at all...)
1301426415 J * derjohn_mob ~aj@d142169.adsl.hansenet.de
1301426853 M * arekm vserver configuration or cgroups mounting configuration (which is in /etc/cgconfig.conf here)
1301427033 M * daniel_hozac sounds wonderfully crack-filled :)
1301427112 M * arekm apps written in c which parse config, create cgroups, watch tasks, move tasks to groups based on different criteria etc. I'm trying to have this and vserver cooperate nicely
1301427568 Q * BenG Quit: I Leave
1301427816 Q * arekm Quit: leaving
1301428220 J * arekm arekm@carme.pld-linux.org
1301428715 Q * hijacker Quit: Leaving
1301428976 M * daniel_hozac arekm: try master.
1301429016 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1301429034 M * daniel_hozac (and touch /etc/vservers/.defaults/cgroup/per-ss)
1301431189 Q * BenG Quit: I Leave
1301431435 Q * cuba33ci Read error: Connection reset by peer
1301431522 J * cuba33ci ~cuba33ci@111-240-172-26.dynamic.hinet.net
1301433664 J * caglar ~caglar@173-15-128-90-BusName-Philadelphia.hfc.comcastbusiness.net
1301433887 M * caglar hi all, I'm having a problem with resource limits. For some reason limits don't show up in guests (please see http://pastebin.com/1aKXJV2J). Do you have any idea what may be the problem?
1301433969 M * daniel_hozac .min is a PlanetLab hack. is that still in the new codE?
1301433996 M * caglar daniel_hozac, it is :) but I also cannot set those limits via vlimit
1301434018 M * caglar daniel_hozac, except hard limit one or I'm doing something wrong
1301434089 M * daniel_hozac btw, you can just give -c the guest name...
1301434131 M * daniel_hozac (you know, now that you have properly setup contexts :))
1301434165 M * caglar daniel_hozac, :)
1301434204 M * caglar daniel_hozac, I'm testing it via issuing following "vlimit -c co_cottc --nofile 10000" and "vlimit -c co_cottc --openfd 10000"
1301434246 M * caglar daniel_hozac, but my test code still dies with "Error: Too many open files, Last file descriptor successfully opened: 4093"
1301434259 M * daniel_hozac do you also set ulimits?
1301434316 M * caglar caglar, how should I do that? I was assuming vlimit does the magin
1301434319 M * caglar magin/magic
1301434322 M * daniel_hozac no.
1301434328 M * daniel_hozac vlimit sets the context limits.
1301434341 M * daniel_hozac ulimits (i.e. the standard setrlimit) still apply.
1301434350 M * geb hi
1301434382 M * daniel_hozac set /etc/vservers/<guest>/ulimits/nofile as well.
1301434401 M * daniel_hozac (you can also check if that's an issue with ulimit -a)
1301434421 M * caglar daniel_hozac, was it always like that? Cause I also have old kernel/util-vserver setup without ulimit directory and it works with rlimits files
1301434431 M * daniel_hozac again, PlanetLab hacks :)
1301434445 M * daniel_hozac it's always actually worked like that.
1301434451 M * caglar daniel_hozac, irghhh
1301434463 M * caglar daniel_hozac, ok I'm gonna try now. thanks :)
1301434464 M * daniel_hozac PL just inferred one from the other.
1301434587 Q * Romster Ping timeout: 480 seconds
1301434759 M * geb Bertl, yeah sry, maxence just did a mass mail and forgot that not everybody speaks french, but i'll take care of the it for the next times :)
1301434794 Q * ghislain Quit: Leaving.
1301435368 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1301435810 Q * derjohn_mob Ping timeout: 480 seconds
1301435876 J * derjohn_mob ~aj@d142169.adsl.hansenet.de
1301436677 J * manana ~mayday090@84.17.25.149
1301437457 Q * hparker Quit: Quit
1301437977 J * strowi ~strowi@f049206246.adsl.alicedsl.de
1301437983 M * strowi hi
1301438077 M * strowi anyone around? i got a problem with "vserver clone .."
1301438103 M * daniel_hozac it usually helps to state a problem.
1301438149 M * strowi ok, i can successfully clone a debian container, but doing the same with an ubuntu-one it fails to start afterwards.
1301438213 M * daniel_hozac why?
1301438219 M * daniel_hozac error messages usually help.
1301438266 M * strowi thought so too, but there is none...
1301438288 M * strowi vserver ubuntu-clone.test start just gives a new prompt
1301438389 M * daniel_hozac well, what ubuntu? does it use upstart?
1301438453 M * daniel_hozac did you enable any services?
1301438461 M * daniel_hozac set the initstyle correctly?
1301438467 M * strowi ubuntu-lucid with upstart. runs fine except for the clone.
1301438616 M * strowi the weird thing is, if i copy  vservers/ubuntu to vservers/ubuntu-clone and modify /etc/vservers/xxx it works.
1301438635 M * daniel_hozac do you specify -d to clone?
1301438645 M * daniel_hozac set the same initstyle?
1301438741 M * strowi "vserver ubuntu-clone build -m clone --hostname ubuntu-clone.naglfar --interface eth0:10.1.1.135/24 -- --source /home/vservers/ubuntu-template"
1301438791 M * daniel_hozac and what does cat /etc/vservers/ubuntu-template/apps/init/style return?
1301438813 M * strowi plain
1301438823 M * daniel_hozac so set that for your new guest too.
1301438844 M * strowi D'oh...
1301438854 M * strowi that was simple..
1301438887 M * strowi that worked.. thx for the help, i had the impression "clone" would mean clone including settings.
1301438898 M * daniel_hozac no
1301438907 M * daniel_hozac clone just clones data.
1301438964 M * strowi good to know. thx again for the help
1301440020 J * fisted_ ~fisted@p508854D5.dip.t-dialin.net
1301440168 Q * strowi Quit: Verlassend
1301440270 Q * fisted Ping timeout: 480 seconds
1301440564 Q * manana Remote host closed the connection
1301442105 Q * bonbons Quit: Leaving