1316996051 Q * manana Remote host closed the connection
1316998870 Q * fisted Read error: Connection reset by peer
1316999414 J * fisted ~fisted@xdsl-87-78-218-115.netcologne.de
1317005310 Q * FireEgl Read error: Connection reset by peer
1317005891 J * FireEgl ~FireEgl@173-16-9-169.client.mchsi.com
1317006269 M * Bertl off to bed now ... have a good one everyone!
1317006273 N * Bertl Bertl_zZ
1317008146 J * derjohn_mob aj@80.187.217.113
1317009197 Q * derjohn_mob Ping timeout: 480 seconds
1317014049 Q * markc Remote host closed the connection
1317014054 J * markc ~markc@203.25.132.186
1317017108 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1317017262 J * ghislain ~AQUEOS@adsl2.aqueos.com
1317021389 J * ffrank ~ffrank@g231218001.adsl.alicedsl.de
1317021696 M * ffrank hi. I recently tried and applied http://vserver.13thfloor.at/ExperimentalT/delta-multicast-feat02.diff to my 2.6.32.43-vs2.3.0.36.29.6. on system startup, I was greeted by these, though: http://www.pastie.org/2592814
1317021718 M * ffrank I haven't the first idea what to make of these. any clues?
1317021744 M * ffrank 2.6.32.36-vs2.3.0.36.29.6 doesn't yield any warnings whatsoever
1317022641 N * Bertl_zZ Bertl
1317022645 M * Bertl morning folks!
1317022655 M * Bertl ffrank: will look into it shortly
1317022723 M * ffrank moin Bertl - much appreciated
1317024310 J * thierryp ~thierry@zankai.inria.fr
1317024320 Q * thierryp Remote host closed the connection
1317024399 J * thierryp ~thierry@zankai.inria.fr
1317024440 M * ffrank oops, there's another: http://www.pastie.org/2592944
1317024773 M * Bertl so that is mainline 2.6.32.43 + vs2.3.0.36.29.6 and the multicast-feat02, yes?
1317024909 M * Bertl it's interesting because the line numbers and function names do not match
1317024917 Q * ntrs Ping timeout: 480 seconds
1317024933 Q * thierryp Remote host closed the connection
1317025020 J * _nono_ ~gomes@licencieux.ircam.fr
1317025064 M * Bertl and the only warning in net/core/dst.c is on dst release
1317025091 M * Bertl which is a WARN_ON so we should see the reason
1317025140 M * ffrank sadly, it's not exactly mainline. it
1317025171 M * ffrank it's Novell's enterprise kernel plus a few feature backports
1317025200 M * ffrank so I take it doing this exercise again from mainline sources would be helpful?
1317025207 M * Bertl yes, definitely
1317025218 M * ffrank I'll look into it
1317025364 M * Bertl make sure to enable CONFIG_DEBUG_INFO and CONFIG_DEBUG_BUGVERBOSE
1317025382 M * Bertl (when building the kernel, but your current config should have those)
1317025430 J * ntrs ~ntrs@vault08.rosehosting.com
1317025471 M * Bertl you can try (with the data gathered so far) to run the first entry in the calltrace (i.e. the <ffff*> right after "Call Trace:") through addr2line -e vmlinux
1317025511 M * Bertl that should give you a file and line number in your source tree, which I'd be interested in
1317025529 M * ffrank that'll probably not work with vmlinuz?
1317025557 M * Bertl nope
1317026033 M * ffrank hum. addr2line -e arch/x86/boot/compressed/vmlinux 0xffffffff8103efa3 yields: "??:0"
1317026063 N * Mr_Smoke_ Mr_Smoke
1317026408 M * Bertl maybe it wasn't compiled with the necessary information after all, but the warnings look fishy to me, as they always show the very same file/line number and completely different functions
1317026419 M * Bertl i.e. they cannot be all at the same location :)
1317026444 M * Bertl out of curiosity, what's in your current source at net/core/dst.c:288 ?
1317026480 M * ffrank turns out DEBUG_INFO is not set after all, but DEBUG_VERBOSE is...
1317026499 M * ffrank dst.c:288 WARN_ON(newrefcnt < 0); # in void dst_release(struct dst_entry *dst)
1317026522 M * Bertl okay, so at least that makes sense
1317026572 M * Bertl that's on line 272 (for mainline) so the source probably differs somewhat
1317026619 M * Bertl and I agree that it should never hit this warning :)
1317027122 M * ffrank traces from the mainline kernel may more or less allow you to get to the bottom of this?
1317027369 M * Bertl yes, I think so, please use the vs2.3.0.36.29.7 patch though
1317027731 M * ffrank ah, making vserver patches fit...joy of my workday ;)
1317028006 M * Bertl yeah, those simple joys ... :)
1317028429 J * thierryp ~thierry@zankai.inria.fr
1317028720 Q * thierryp Remote host closed the connection
1317028730 Q * transacid Remote host closed the connection
1317030746 J * thierryp ~thierry@zankai.inria.fr
1317031342 Q * thierryp Remote host closed the connection
1317032927 Q * daniel_hozac Ping timeout: 480 seconds
1317035661 J * derjohn_mob ~aj@213.238.45.2
1317036640 J * BenG ~bengreen@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com
1317037956 J * daniel_hozac ~daniel@c-f33671d5.08-230-73746f22.cust.bredbandsbolaget.se
1317039532 Q * BenG Quit: I Leave
1317041191 J * thierryp ~thierry@zankai.inria.fr
1317042377 Q * thierryp Remote host closed the connection
1317042915 J * thierryp ~thierry@zankai.inria.fr
1317043347 Q * FireEgl Read error: Connection reset by peer
1317043537 Q * fisted Ping timeout: 480 seconds
1317043674 J * fisted ~fisted@xdsl-87-78-218-207.netcologne.de
1317044172 Q * thierryp Remote host closed the connection
1317044327 J * FireEgl ~FireEgl@173-16-9-169.client.mchsi.com
1317045352 M * fanto666 which is the last semi-stable kernel/vserver version?
1317045370 M * fanto666 I'm filling gentoo bugreport for uploading something newer than 2.6.35-vs2.3.0.36.32-gentoo
1317045426 M * fanto666 do you have any advise about version worth trying?
1317045540 M * fanto666 perhaps 2.6.38.8 + vs2.3.0.37-rc17  ?
1317046051 M * Bertl 2.6.38.x is fine, but 3.0.x should be fine as well
1317046084 M * Bertl (and 3.x is what will be stabilized .. so if gentoo follows the stabilization process it would be the best choice IMHO)
1317046532 J * thierryp ~thierry@zankai.inria.fr
1317047421 Q * quasisane Quit: leaving
1317048340 J * quasisane ~sanep@c-76-24-80-97.hsd1.nh.comcast.net
1317048713 J * dowdle ~dowdle@scott.coe.montana.edu
1317049851 Q * ncopa Quit: Leaving
1317050793 Q * ntrs Ping timeout: 480 seconds
1317051065 J * ntrs ~ntrs@vault08.rosehosting.com
1317051139 Q * thierryp Remote host closed the connection
1317052719 M * hparker I've spoke with hollow recently and that's what is planned
1317052866 M * hparker I do have .39 and 3.04 ebuilds to play with if someone is interested as well as newer util-vserver (current as of a week or two ago) http://git.homershut.net/?p=gentoo.git;a=tree
1317052884 M * hparker I've not broke .39 yet, but my server has minimal load
1317052957 Q * ffrank Quit: Leaving
1317053358 J * bonbons ~bonbons@2001:960:7ab:0:f4c5:e15f:f4f0:b280
1317055829 J * daniel_hozac_ ~daniel@c-f33671d5.08-230-73746f22.cust.bredbandsbolaget.se
1317056000 Q * daniel_hozac Ping timeout: 480 seconds
1317056020 N * daniel_hozac_ daniel_hozac
1317056120 Q * derjohn_mob Ping timeout: 480 seconds
1317058078 Q * markc Remote host closed the connection
1317059121 M * arekm hm, can whole network interface be assigned to guess? so changing ip on host will also "change" it in guest on that iface
1317059165 M * daniel_hozac no.
1317059168 M * daniel_hozac it's IP isolation.
1317059172 M * daniel_hozac interfaces aren't involved.
1317059222 M * arekm then can all IPs be autoassigned to guest then? (IPs on interface are dynamic)
1317059230 M * arekm all from specified interface
1317059248 M * arekm (since these IPs are assigned before guest starts)
1317059287 M * daniel_hozac you can easily change the assigned set with naddress.
1317059309 M * daniel_hozac you can assign a guest 0.0.0.0, and it will get any interface that has an IP.
1317059315 M * daniel_hozac or you can disable the isolation entirely.
1317059402 M * arekm uh, too bad that ip = 0.0.0.0 + dev = tap0 don't get tap0 interface with all it's addresses
1317059440 M * arekm but well, current 0.0.0.0 looks fine for me in this setup anyway
1317059689 M * daniel_hozac it's not interface based.
1317059695 M * daniel_hozac interfaces have nothing to do with it.
1317059703 M * daniel_hozac dev just makes util-vserver add said IP to the interface.
1317059792 M * arekm so I'm saying something like "see which ips are on interface while starting and add these to guest isolation"
1317059811 M * daniel_hozac that wouldn't at all help your case though.
1317059876 M * daniel_hozac the correct way to do it is just add a dhclient-script that updates your guest accordingly.
1317060045 M * arekm did something like that (it's openvpn with dynamic ips assigned actually)
1317064559 J * kcin ~karu@helicon.unlemoted.net
1317064584 P * kcin 
1317065113 Q * brc Ping timeout: 480 seconds
1317065961 J * kcin ~kcin@91.118.96.132
1317067267 Q * FireEgl Read error: No route to host
1317067427 Q * cuba33ci Read error: Connection reset by peer
1317067472 J * cuba33ci ~cuba33ci@111-240-165-196.dynamic.hinet.net
1317068945 J * transacid ~transacid@84.19.167.254
1317068967 N * transacid Guest11670
1317069137 N * Guest11670 transacid
1317070164 Q * ntrs Ping timeout: 480 seconds
1317070638 J * ntrs ~ntrs@vault08.rosehosting.com
1317071377 Q * bonbons Quit: Leaving
1317071858 J * brc ~bruce@72.20.27.65
1317074167 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1317078756 Q * imcsk8 Remote host closed the connection
1317080197 Q * ghislain Quit: Leaving.