1253146514 Q * Pazzo Quit: Bye!
1253149964 Q * imcsk8 Quit: This computer has gone to sleep
1253151349 M * Bertl off to bed now ... have a good one everyone!
1253151353 N * Bertl Bertl_zZ
1253153518 J * doener ~doener@i59F557FF.versanet.de
1253153622 Q * doener_ Ping timeout: 480 seconds
1253163971 J * takeru ~takeru@nttkyo721010.tkyo.nt.ftth.ppp.infoweb.ne.jp
1253164617 Q * derjohn_mob Ping timeout: 480 seconds
1253166129 J * ncopa ~ncopa@ti211310a081-1927.bb.online.no
1253166456 J * scientes_ ~scientes@174-21-158-192.tukw.qwest.net
1253166677 Q * ncopa Ping timeout: 480 seconds
1253166688 J * ncopa ~ncopa@90.149.48.245
1253167892 Q * thierryp_ Remote host closed the connection
1253167918 Q * harry Ping timeout: 480 seconds
1253168800 J * derjohn_mob ~aj@139.12.1.252
1253168940 J * harry ~harry@d51A461B4.access.telenet.be
1253170702 Q * balbir Read error: Connection reset by peer
1253171683 J * balbir ~balbir@122.172.39.104
1253171730 J * BenG ~bengreen@94-169-110-10.cable.ubr22.aztw.blueyonder.co.uk
1253171834 J * davidkarban ~david@199.123.broadband11.iol.cz
1253171908 J * thierryp ~thierry@zanzibar.inria.fr
1253172355 Q * BenG Quit: I Leave
1253172408 J * geb ~geb@earth.gebura.eu.org
1253172616 J * mxs_ mxs@p4FCCBC27.dip.t-dialin.net
1253172917 Q * mxs Ping timeout: 480 seconds
1253174448 J * ohaeuser ~chatzilla@pd95b9e24.dip0.t-ipconnect.de
1253176499 J * saulus ~saulus@d003031.adsl.hansenet.de
1253176507 M * arekm Bertl_zZ: please add this change into 2.6.27 patch for vserver http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/kernel/kernel-vserver-fixes.patch?r1=1.1.2.9.2.1&r2=1.1.2.9.2.2
1253176637 M * arekm Bertl_zZ: or all sane hunks from this http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/kernel/kernel-vserver-fixes.patch?rev=1.1.2.9.2.2
1253177407 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net
1253177872 J * dna ~dna@100-199-103-86.dynamic.dsl.tng.de
1253177914 J * mass- ~mass@mago.pl
1253180763 N * vServer_User_Zz vServer_User
1253181032 N * Bertl_zZ Bertl
1253181036 M * Bertl morning folks!
1253181170 Q * mass- 
1253181322 M * Bertl arekm: should be no problem
1253181452 M * arekm (the include <something hunk isn't needed)
1253181509 M * Bertl yeah, I removed that some time ago :)
1253181586 M * Bertl where does the SElinux part come from?
1253182677 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it
1253182807 M * arekm from hand of one of our devs ;)
1253182949 M * Bertl k, I'm just wondering, it seems that it isn't the result of an actual bugfix, more a work to have a closure ...
1253183016 M * Bertl or to put it the other way, is there something which is broken with that entry missing and does that hunk fix it? and if yes, what and in what way? :)
1253183096 M * Bertl note: I have no problem adding it even if there isn't one
1253183145 M * arekm no, these are not bugfixes but enhacements
1253183190 M * Bertl okay, so is he actually using SELinux with Linux-VServer?
1253183267 M * arekm was playing with this at least
1253183364 M * Bertl because I think there are a bunch of SELinux modifications required to make it really useful for/with Linux-VServer, but noody wanted to implement them yet :)
1253183581 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net
1253183961 Q * mrfree Quit: Leaving
1253185057 M * Bertl okay, off for now .. bbl
1253185103 N * Bertl Bertl_oO
1253186272 Q * promeno Quit: Leaving
1253193375 Q * takeru Read error: Operation timed out
1253197505 M * vServer_User anyone about to help
1253197520 M * vServer_User how can i remove an ip from a running vserver
1253197527 M * daniel_hozac use naddress
1253197534 M * vServer_User naddress --remove?
1253197556 M * vServer_User "naddress: vc_net_remove(): Invalid argument"
1253197600 M * daniel_hozac it's not supported on current kernels. but --set is.
1253197619 M * vServer_User a vserver has magically dropped an IP, and i can't bring it back up
1253197627 M * vServer_User [interfaces]$ ifup eth0:15
1253197627 M * vServer_User SIOCSIFFLAGS: Cannot assign requested address
1253197627 M * vServer_User Failed to bring up eth0:15.
1253197840 M * vServer_User any thoughts
1253198166 M * vServer_User eeek, just lost all interfaces now
1253198178 M * vServer_User could it be related to this 
1253198179 M * vServer_User portmap[15402]: connect from 127.0.42.1 to dump(): request from unauthorized host
1253198722 Q * thierryp Ping timeout: 480 seconds
1253198969 J * dowdle ~dowdle@scott.coe.montana.edu
1253199029 J * renihs ~lemming@83-65-34-34.arsenal.xdsl-line.inode.at
1253199333 M * micah vServer_User: sounds like you should stop the guest and restart it
1253199955 M * arekm Bertl_oO: addr2line always returns sched.c:0 ;/
1253200520 M * vServer_User yep -  i had to restart it
1253200524 M * vServer_User very perculiar though!
1253200549 M * micah vServer_User: do you have a vpn like openvpn or something
1253200555 M * vServer_User no
1253200579 J * imcsk8 ~ichavero@nat.ti.uach.mx
1253200722 J * hparker ~hparker@2001:470:1f0f:32c:290:96ff:fe50:40fa
1253201280 M * vServer_User any reason you ask
1253201772 Q * mugwump Ping timeout: 480 seconds
1253202799 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1253203373 M * _Shiva_ vServer_User: set: net.ipv4.conf.all.promote_secondaries=1 in /etc/sysctl.conf - just in case..
1253203393 Q * BWare Ping timeout: 480 seconds
1253203443 M * _Shiva_ vServer_User: default is 0, which means: if the main interface loses it's IP-Adresss all secondaries (in your case: aliases) are dropped, too
1253203510 M * _Shiva_ vServer_User: setting this to "1" means: promote one(/first/?) of the secondaries to be used as the primary address on the interface
1253203558 M * _Shiva_ (which might not be the best in some particular cases, but is better than losing all addresses)
1253203995 J * BWare ~itsme@ip-80-113-1-198.ip.prioritytelecom.net
1253204075 M * vServer_User yeah - I had to set that a while back
1253204098 M * vServer_User the vserver had a nasty habbit of droping interfaces
1253204471 Q * derjohn_mob Ping timeout: 480 seconds
1253204492 Q * davidkarban Quit: Ex-Chat
1253204731 Q * BWare Quit: *p00f*
1253208680 Q * Pazzo Quit: Bye!
1253208757 Q * balbir Ping timeout: 480 seconds
1253209505 J * balbir ~balbir@122.172.24.203
1253209987 J * mugwump ~samv@watts.utsl.gen.nz
1253210576 N * Bertl_oO Bertl
1253210580 M * Bertl back now ...
1253210599 M * Bertl arekm: and the panic/trace is from exactly that kernel?
1253210649 M * Bertl vServer_User: it's a mainline feature :)
1253211347 Q * ohaeuser Ping timeout: 480 seconds
1253211443 M * arekm Bertl: cannot tell for 100% because it's what another user told me (he is able to reproduce faster than I)
1253211477 M * arekm Bertl: so it's the same unless that reported did a mistake which is unlikely
1253211697 Q * gnuk Quit: NoFeature
1253212048 M * Bertl okay, any chance to get the person here?
1253212255 M * arekm mail to him sent, maybe he will show here, nick "blues"
1253212282 M * arekm hm, my machine oopsed too few hours ago... checking addr2line
1253212307 M * Bertl okay, we can reverse the panic manually, but that is a little tedious
1253212347 M * arekm $ addr2line -e vmlinux ffffffff80227e04
1253212347 M * arekm sched.c:0
1253212349 M * arekm blah
1253212463 M * Bertl could you upload your .config, preferably from /proc/config.* somewhere?
1253212529 M * arekm http://pld.pastebin.com/f67f3998
1253212567 M * arekm tried DETECT_SOFTLOCKUP=y and =n, too
1253212753 M * Bertl # CONFIG_DEBUG_INFO is not set
1253212765 M * Bertl there you go, no debug info -> no debug info :)
1253212773 N * vServer_User vServer_User_Zz
1253212782 M * arekm heh!
1253212836 M * arekm Bertl: but I have vmlinux, too, from build tree... isn't that enough?
1253212889 M * Bertl but it has no debug info :)
1253214238 J * blues ~blues@azp47.neoplus.adsl.tpnet.pl
1253214247 M * blues !seen Bertl
1253214269 M * blues hi
1253214351 M * Bertl hey blues 
1253214379 M * blues Bertl: hi
1253214390 M * Bertl okay, so you can reproduce the crash/panic arekm is talking about (since days :)
1253214400 M * blues as I told - anything above 2.6.27.15 causes crash
1253214405 M * blues yes
1253214423 M * blues and nice collection of catched oops-es :)
1253214426 M * Bertl okay, we figured that arekm is missing the debug info in the kernel config, do you have that enabled?
1253214435 M * Bertl 20:39 <@Bertl> # CONFIG_DEBUG_INFO is not set
1253214438 M * blues not, yet
1253214452 M * Bertl okay, then first thing is to enable that then
1253214463 M * blues ok
1253214463 M * Bertl how long does it take for you until it happens?
1253214470 M * blues few hours
1253214482 M * Bertl that sounds good!
1253214508 M * blues but I can make reboot only in the mornings
1253214513 M * blues mon-fri
1253214526 J * thierryp ~thierry@home.parmentelat.net
1253214552 M * Bertl okay, but you can prepare a kernel, so in case you crash, you can boot the new one, right?
1253214589 M * Bertl what patches does you kernel contain and do you see any correlation between processes or actions and the panic?
1253214607 M * blues yes
1253214648 M * blues I have there software raid
1253214655 M * blues on 6 HDs
1253214659 M * blues raid10
1253214681 M * blues rebuilding that makes it crash faster
1253214696 M * Bertl okay, interesting ...
1253214754 M * Bertl so, what patches do you use ontop of the vanilla kernel?
1253214767 M * blues grsec
1253214778 M * blues but without that is the same
1253214793 M * Bertl grsec and Linux-VServer I presume?
1253214811 M * Bertl or really just grsec?
1253214834 M * blues grsec and vserver
1253214850 M * blues few netfilter patches
1253214910 M * blues reiser4,
1253214916 M * blues checked without too
1253215008 M * Bertl okay, I wouldn't mind if you could go with vanilla + Linux-VServer only for the next round/test
1253215032 M * Bertl if that works for you, of course
1253215046 M * Bertl (and please enable DEBUG_INFO :)
1253215059 M * blues I'll try
1253215104 M * Bertl capture the panic, and then run 'addr2line -e vmlinux <addr>' for each address listed in the panic (arekm can help there if necessary)
1253215122 M * blues sure
1253215154 M * Bertl if the kernel is vanilla + Linux-VServer, I have a tree here and can look into it directly, otherwise I need the additional patches
1253215359 M * blues Bertl: tar of whole tree will be enough?
1253215402 M * Bertl nah, patches are always preferred
1253215420 M * arekm we have like ton of patches ;>
1253215420 M * blues ok
1253215426 M * Bertl but as I said, if you can do with vanilla + Linux-VServer, then noting is needed at all
1253215514 M * Bertl I'd also suggest to use a recent 2.6.27.x version for testing
1253215563 M * blues I'm doing it
1253215611 M * blues the funny thing it that between 2.6.27.15 and .16(17) there are only changes in mainline kernel
1253215633 M * blues bisecting it gave nothing 
1253215636 M * blues :(
1253215652 M * Bertl as I said, I suspect a mainline issue, which might get triggered by other patches
1253215655 M * arekm blues: hm, so you finished bisecting of 2 last acpi patches?
1253215681 M * blues arekm: well - no :)
1253215697 M * blues arekm: tested it by reverting
1253215705 M * blues arekm: as we were talking
1253215722 M * blues Bertl: could be
1253216089 M * arekm Bertl: btw. oopsing code should be enhanced to tell which vcontext was there 
1253216100 M * arekm [271599.519451] Pid: 16421, comm: exim
1253216104 M * arekm but no idea which guest
1253216119 M * Bertl patches are welcome
1253216128 M * arekm riight
1253216153 M * arekm I even have no idea what's safe to do when oopsing
1253216180 M * Bertl well, the pid is derived from the task, as is the comm
1253216200 M * Bertl you can, similar to the VM patches, use the xid/nid safely
1253216250 M * Bertl (see second hunk of your diff)
1253216428 Q * nou Ping timeout: 480 seconds
1253217257 M * arekm Bertl: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/kernel/kernel-vserver-fixes.patch?r1=1.1.2.9.2.2&r2=1.1.2.9.2.3
1253217332 J * derjohn_mob ~aj@e180192065.adsl.alicedsl.de
1253217611 M * arekm and http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/kernel/kernel-vserver-fixes.patch?r1=1.2&r2=1.3 for .30
1253217616 M * arekm 31
1253217635 M * Bertl hmm, let's keep some common format, i.e. either %s(%d:#%u) or %d:#%u
1253217775 M * Bertl I see that we have %d[#%u] in at least two places too, those could benefit from a cleanup too, when you're at it ...
1253217792 Q * scientes_ Ping timeout: 480 seconds
1253217892 M * Bertl note that the Linux-VServer debug messages are fine with %d[#%u], I'm talking about 'normal
1253217900 M * Bertl ' kernel messages
1253218087 J * nou Chaton@causse.larzac.fr.eu.org
1253218413 M * arekm booted debug info enabled kernel and waiting for oops to happen
1253218554 M * Bertl do some raid6 rebuilding :)
1253218564 M * Bertl or raid10 ...
1253218784 J * scientes ~scientes@174-21-136-187.tukw.qwest.net
1253218784 Q * bonbons Quit: Leaving
1253219317 Q * nkukard Ping timeout: 480 seconds
1253219380 Q * thierryp Quit: ciao folks
1253219546 M * arekm Bertl: it has hw raid
1253219570 M * arekm and even on busy machines this oops doesn't happen "like that". You have to be lucky to trigger
1253219601 M * blues it seems I'm lucky? :P
1253219602 M * Bertl well, try with sw-raid over loop devices?
1253219694 M * arekm this is production machine and I cannot do random games on it
1253219705 M * arekm while other, non production machines don't trigger this :/
1253219753 M * blues I think that a lot of disk-jobs can trigger it
1253219798 M * Bertl I have to remember that one :)
1253219928 M * arekm blues: carme sometimes have a lot of disk-jobs and no oops so far
1253219951 M * blues arekm: well - there must be more more condition(s)
1253219978 J * nkukard ~nkukard@196.212.73.74
1253219990 M * blues but it makes it faster
1253220533 Q * dna Quit: Verlassend
1253220746 Q * scientes Ping timeout: 480 seconds
1253226984 Q * ghislainocfs2 Quit: Leaving.
1253227145 Q * imcsk8 Quit: Leaving
1253227533 Q * uva Read error: Connection reset by peer
1253230359 J * imcsk8 ~ichavero@189.155.72.54
1253231737 Q * imcsk8 Quit: This computer has gone to sleep
1253231836 Q * MooingLemur Quit: leaving
1253231854 J * MooingLemur ~troy@shells195.pinchaser.com