1418257962 Q * arekm Ping timeout: 480 seconds 1418259602 Q * fstd Remote host closed the connection 1418259647 J * fstd ~fstd@xdsl-87-78-12-189.netcologne.de 1418275275 M * Bertl_oO off to bed now ... have a good one everyone! 1418275284 N * Bertl_oO Bertl_zZ 1418281322 J * arekm ~arekm@ixion.pld-linux.org 1418283421 Q * derjohn_mob Ping timeout: 480 seconds 1418283432 J * Ghislain ~aqueos@adsl1.aqueos.com 1418285128 J * derjohn_mob ~aj@87.253.171.196 1418285769 Q * Aiken Ping timeout: 480 seconds 1418286143 Q * derjohn_mob Ping timeout: 480 seconds 1418287630 J * derjohn_mob ~aj@87.253.171.196 1418293537 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1418294793 Q * derjohn_mob Ping timeout: 480 seconds 1418295037 Q * transacid Remote host closed the connection 1418295057 J * transacid ~transacid@transacid.de 1418295733 Q * beng_ Quit: I Leave 1418295998 J * Aiken ~Aiken@quarry.jbmb.net 1418296291 J * glen_ ~glen@scratchy.delfi.ee 1418296302 M * glen_ hey. i have weird issue on old machine 1418296305 N * glen_ glen 1418296319 M * glen any ideas, why vserver ip lingers around, even if vserver is stopped and ip a does not show the ip 1418296323 M * glen and arp points to the same host when looked externally 1418297441 J * derjohn_mob ~aj@87.253.171.196 1418297640 Q * Aiken Quit: Leaving 1418298487 Q * derjohn_mob Ping timeout: 480 seconds 1418298986 J * derjohn_mob ~aj@87.253.171.196 1418300460 N * Bertl_zZ Bertl 1418300462 M * Bertl morning folks! 1418300528 M * Bertl glen: you mean something (probably the router/switch) tells you that the address can still be found on that mac, while it actually was removed? 1418301654 M * glen and it actually pings too 1418301710 M * glen http://sprunge.us/Lghb 1418301826 M * Bertl are you using network namespaces? 1418301853 M * glen it's 2.6.16 kernel. so i think no 1418301894 M * Bertl and the pings actually return from the rover mac? 1418301933 M * glen how to check that? 1418301949 M * Bertl tcpdump? 1418301963 M * glen the fact that pinging locally responds to ip that was on that host 1418301972 M * glen and arp still points to same host 1418301978 M * glen i think the packets don't even leave host 1418302046 M * Bertl check with tcpdump, local traffic will use 'lo' 1418302073 M * Bertl could still be a DMASQ rule active 1418302212 M * glen yes, there's some masq rules http://sprunge.us/dOEV 1418302235 M * glen but ping -R showed just 1 hop when pinged locally. i don't think packets left machine 1418302281 M * Bertl won't be different if the target is on the same lan, no? 1418302356 M * glen the problem exists for two vservers on that host only. if creating new vserver problem is not reproducible 1418302519 M * glen but what you mean if target is on same lan? 1418302802 Q * fstd Remote host closed the connection 1418302844 J * fstd ~fstd@xdsl-87-78-15-14.netcologne.de 1418303463 M * Bertl if you have a host on the same lan as your rover is, it also takes only one hop 1418303480 M * Bertl anyway, what does the arp table (on rover) look like? 1418303670 J * renihs ~arf@83-65-34-34.arsenal.xdsl-line.inode.at 1418305387 Q * Ghislain Read error: Connection reset by peer 1418305541 J * Ghislain ~aqueos@adsl1.aqueos.com 1418305833 M * glen rover arp table was in paste 1418305846 M * glen btw, some ping and tcpdump while guest was up: http://sprunge.us/WeiP locally 1418307354 M * Bertl yeah, seems to be some weird kernel issue 1418307372 M * Bertl probably not even Linux-VServer related 1418308990 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1418309536 J * derjohn_mobi ~aj@87.253.171.196 1418309537 Q * derjohn_mob Read error: Connection reset by peer 1418309576 Q * derjohn_mobi Remote host closed the connection 1418309818 J * derjohn_mob ~aj@87.253.171.196 1418315172 J * Wermwud ~Wermwud@69-29-150-18.stat.centurytel.net 1418315546 Q * derjohn_mob Ping timeout: 480 seconds 1418316124 J * derjohn_mob ~aj@87.253.171.196 1418317739 J * bonbons ~bonbons@2001:a18:22e:fb01:256c:eb7e:5e2b:be40 1418320797 J * zerick ~eocrospom@190.117.185.146 1418320810 Q * bonbons Quit: Leaving 1418321053 J * bonbons ~bonbons@2001:a18:22e:fb01:b0ce:c3e6:3e69:1fdd 1418321342 Q * derjohn_mob Ping timeout: 480 seconds 1418321970 Q * beng_ Quit: I Leave 1418322288 Q * ntrs Ping timeout: 480 seconds 1418324241 J * ntrs ~ntrs@vault08.rosehosting.com 1418325273 N * Guest1192 trey- 1418326411 J * derjohn_mob ~aj@88.128.80.124 1418327389 Q * Ghislain Quit: Leaving. 1418329902 M * Bertl off for a nap ... bbl 1418329911 N * Bertl Bertl_zZ 1418331210 J * Aiken ~Aiken@quarry.jbmb.net 1418331865 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:d86e:9a9e:586b:7d5f 1418331929 Q * bonbons Quit: Leaving 1418332072 Q * thierryp 1418332154 J * bonbons ~bonbons@2001:a18:22e:fb01:b106:2ad8:2fda:8b85 1418332862 Q * bonbons Quit: Leaving 1418332969 J * bonbons ~bonbons@2001:a18:22e:fb01:b0d0:501f:3b82:4a6c 1418333403 Q * bonbons Quit: Leaving 1418333518 J * bonbons ~bonbons@2001:a18:22e:fb01:cb2:df08:75c2:e3ab 1418333782 J * thierryp ~thierry@2a01:e35:2e2b:e2c0:d86e:9a9e:586b:7d5f 1418333924 Q * bonbons Quit: Leaving 1418333944 Q * thierryp 1418335107 J * bonbons ~bonbons@2001:a18:22e:fb01:8ca1:4ddc:795a:47b0 1418335790 N * Bertl_zZ Bertl 1418335793 M * Bertl back now ... 1418335806 Q * bonbons Quit: Leaving 1418336088 N * CcxCZ ccxCZ 1418336367 Q * Aiken Quit: Leaving 1418336715 N * ccxCZ CcxCZ 1418338774 N * CcxCZ ccxbnc 1418339662 Q * derjohn_mob Ping timeout: 480 seconds 1418340835 Q * jpierre03 Remote host closed the connection 1418340954 J * jpierre03 ~jpierre03@voyage.prunetwork.fr 1418341888 M * gnarface Bertl: well, the thing spit a bunch of soft lock errors out earlier today, too many for dmesg to hold them all, i saw lows in the 40 seconds, highs in the 80 seconds. Not having dynticks enabled seems to have made it easier to get the duration at least of the lockups. So far nothing appears to have crashed, and the PATA bus didn't get downgraded in speed, but despite ntpd being running, it managed to lose about 20 minu 1418341888 M * gnarface tes in clock time. after that i unloaded the kvm modules just in case. got any other suggestions for me on stuff i should compile the kernel without? 1418342003 M * gnarface i'm sortof wondering if i'm using the right temperature sensor modules, and whether they could have something to do with it. sensors-detect thinks its it87 but it doesn't load automatically; something else does. and if i unload *that* module, it87 still says "device or resource busy" when i try to load it 1418342037 M * gnarface actually *two* other modules load automatically, but i blacklisted that one because it was auto-disabling itself with some error i mentioned to you a few weeks back 1418342046 M * Bertl that's probably a collision with the bios 1418342086 M * gnarface as in, you mean the bios is incompatible with the it87 module even though its the right one for the hardware? 1418342165 M * gnarface anyway i was just wondering if having the wrong sensor module loaded could be causing the spurious lockups even though it appears to be reading the temperature correctly 1418342199 M * Bertl many sensors are handled by the ACPI part of the bios 1418342241 M * Bertl recent kernels check that and deny shared ACPI/driver access for certain reasons 1418342380 M * gnarface i'm confused, was that a yes or a no?