1414713929 N * l0kit Guest346 1414713937 J * l0kit ~1oxT@0001b54e.user.oftc.net 1414714037 Q * Guest346 Ping timeout: 480 seconds 1414715153 Q * FloodServ charon.oftc.net services.oftc.net 1414717230 J * fstd_ ~fstd@xdsl-81-173-189-245.netcologne.de 1414717347 Q * fstd Read error: Operation timed out 1414717347 N * fstd_ fstd 1414719787 M * Bertl_oO off to bed now ... have a good one everyone! 1414719792 N * Bertl_oO Bertl_zZ 1414734044 J * quote ~quote@cpe-77.38.73.150.cable.t-1.si 1414734046 M * quote hi guys 1414734050 M * quote just a quick question 1414734092 M * quote how do i enable iptables for vservers? I'm running 2 vservers for my own purposes not clients or anything so i'm not worried about any security issues it might cause 1414736124 J * FloodServ services@services.oftc.net 1414737109 M * Guy- quote: you don't -- you configure iptables on the host to filter traffic for the vservers as well 1414737181 M * quote i want the guest to be able to use iptables 1414737193 M * quote wast some NET_ADMIN bcap 1414737197 M * quote that i needed to enable 1414738089 M * daniel_hozac why? 1414738098 M * daniel_hozac if you're in control of all of it, why wouldn't you just set it up on the host? 1414739680 J * Ghislain ~aqueos@adsl1.aqueos.com 1414740163 Q * quote Ping timeout: 480 seconds 1414740225 N * Bertl_zZ Bertl 1414740228 M * Bertl morning folks! 1414741409 Q * derjohn_mobi Ping timeout: 480 seconds 1414743215 N * Bertl Bertl_oO 1414743317 J * derjohn_mobi ~aj@87.253.171.201 1414748122 J * BenG ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1414751937 Q * ntrs Server closed connection 1414751938 J * ntrs ~ntrs@vault08.rosehosting.com 1414752660 Q * derjohn_mobi Remote host closed the connection 1414752793 Q * BenG Quit: I Leave 1414753243 Q * Aiken Remote host closed the connection 1414755041 Q * padde Server closed connection 1414755048 J * padde ~padde@patrick-nagel.net 1414755345 Q * BWare Server closed connection 1414755366 J * BWare ~itsme@31.25.99.5 1414755569 Q * webhat Server closed connection 1414755580 J * redhat ~quassel@31.25.99.5 1414758417 Q * swenTjuln Server closed connection 1414758420 J * quote ~quote@cpe-77.38.73.150.cable.t-1.si 1414758469 J * swenTjuln ~Swen@195.95.173.243 1414759377 Q * hlew Server closed connection 1414759428 J * hlew ~hlew@173-164-198-18-SFBA.hfc.comcastbusiness.net 1414759534 N * redhat webhat 1414760407 Q * fstd Remote host closed the connection 1414760446 J * fstd ~fstd@xdsl-78-35-82-210.netcologne.de 1414761987 Q * quote Ping timeout: 480 seconds 1414762673 Q * Ghislain Server closed connection 1414762709 J * Ghislain ~aqueos@adsl1.aqueos.com 1414764192 J * quote ~quote@cpe-77.38.73.150.cable.t-1.si 1414766171 J * BenG ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1414767262 Q * quote Ping timeout: 480 seconds 1414772001 N * Bertl_oO Bertl 1414772013 M * Bertl back now ... 1414772456 J * quote ~quote@cpe-77.38.73.150.cable.t-1.si 1414773053 Q * BenG Quit: I Leave 1414777779 M * gnarface Bertl: what do you make of this? http://paste.debian.net/129613/ 1414777809 M * gnarface Bertl: at first, i thought just not loading that k10temp module had silenced these scary looking errors in my dmesg output, but it seems something is still weird .... 1414777835 M * gnarface Bertl: yesterday i caught it dropping the ata interface from ata/100 down to ata/66 1414777872 M * gnarface Bertl: so far the thing seems stable though... at least, it hasn't fully crashed or refused my ssh connection attempts yet... everything *looks* like its still working at least at first glance (i'm still receiving spam) 1414777914 M * gnarface Bertl: i think it was fine for a couple days though before this started happening again 1414778000 M * gnarface Bertl: i may attempt to swap the PATA cable for a SATA-to-PATA adapter and SATA cable, just to see if avoiding the IDE interface on this marvell harddrive controller might avoid problems too 1414778101 M * gnarface Bertl: any thoughts? 1414778253 M * gnarface Bertl: a while before that (immediately after i rebooted to reset the IDE interface i think) there was this, which i pasted one line of earlier: http://paste.debian.net/129614/ 1414778271 M * gnarface Bertl: i doubt that's related though, because that's the only time i've seen it 1414778354 M * gnarface Bertl: oh, and i think the "UDP: bad checksum" stuff is unrelated too... that seems to have something to do with the teamfortress2 server traffic 1414778364 M * gnarface Bertl: (but i could be wrong) 1414778496 M * Bertl do I have so many people on ignore? :) 1414778548 M * gnarface Bertl: uh... you're asking me? 1414778584 M * Bertl I'm just wondering, because you constantly prefix your sentences, while nobody else seems to be talking :) 1414778608 M * gnarface oh, sorry. no its just a habit i got into from hanging out in #debian 1414778642 M * gnarface sometimes its difficult for me to auto-detect changes in unspoken social policies as they change between channels sometimes significantly 1414778700 M * Bertl yeah, no problem 1414778727 M * Bertl well, we have seen mysterious stalls in the kernels for some time now, as far as we can tell, all unrelated to Linux-VServer 1414778745 M * Bertl (which doesn't change the scheduler code anymore) 1414778760 M * gnarface so you think it might also not be actually the fault of the ATA stuff? 1414778785 M * Bertl drivers are usually quite buggy, and drivers which 'wait' for some event which (for whatever reason) doesn't come, will definitely stall the kernel 1414778830 M * Bertl so it might just be a badly designed driver, which works in 90% of the cases, which gets 'triggered' by somewhat flakey hardware 1414778841 M * Bertl i.e. bad cables or connectors or similar 1414778871 M * Bertl a command gets lost, the driver doesn't handle that case gracefully, the cpu locks up, the watchdog kicks in 1414778898 M * gnarface does that mean that cpu core is locked up until it reboots now? 1414778902 M * gnarface or does watchdog fix it? 1414778942 M * Bertl depends on the actual type of lockup, but usually the cpu is stalled/locked until reboot or the event finally completes as expected 1414778984 M * gnarface oh i see, so whatever its complaining about might have actually still succeeded, just took longer than expected? 1414779031 M * Bertl yes, that might be the case 1414779048 M * Bertl you should be able to tell what a cpu is doing via proc 1414779061 Q * undefined Quit: Closing object 1414779092 M * gnarface it suddenly occurs to me, that on an older kernel i was running before i shelved this machine a few years ago, i never ran the harddrive controller in "AHCI" mode in the bios, i had it set to "IDE" mode for some reason (at the time i think AHCI support wasn't working right?) and i had to pass a module option too, like pata=marvell or something like that, to get the dual controller (its got an IDE bus as well as SATA port 1414779092 M * gnarface s) to behave itself 1414779136 M * gnarface but i guess there could be something just wrong with the cable too 1414779145 M * gnarface it had a rough life 1414779169 M * gnarface if something was stalled, it'd show up as using a lot of cpu in top, right? 1414779185 J * undefined ~undefined@00011a48.user.oftc.net 1414779189 M * gnarface or do i have to grep for something in /proc ? 1414779301 M * gnarface i also have locked it into "performance" mode because the ondemande mode seemed to be instigating random segfaults 1414779345 M * Bertl usually it shows up as a cpu being in 'wait for io' state 1414779376 M * Bertl inconsistant segfaults are a good indication of something being wrong with memory or cpu 1414779405 M * Bertl best checked with a processing intensive test, like calculating pi or similar 1414779416 M * gnarface well the memory passed every memtest86+ test i could throw at it, even the extended ones, so it'd be the cpu 1414779438 M * gnarface the harddrive also passed multiple badblocks checks, even the destructive pass 1414779448 M * gnarface hmm 1414779462 M * Bertl badblocks won't cause segfaults, unless they are in the executables/libraries 1414779473 M * Bertl and even in this case, they will be consistant 1414779517 M * gnarface ? grep -rni 'wait for io' /proc/ 1414779549 M * Bertl it's simpler to use e.g. top, activate the per cpu mode and look for %wait 1414779582 M * gnarface ah, well nothing right now then, whatever it was i missed it 1414779609 Q * undefined Quit: Closing object 1414779683 M * gnarface hmm. a couple times i've noticed after a couple days the clock skewing alarmingly (like by half an hour or more) but it doesn't appear gradual (hasn't slipped even a second since last night) 1414779687 J * undefined ~undefined@00011a48.user.oftc.net 1414779688 M * gnarface think that could be related? 1414779732 M * Bertl could be, but never heard of that 1414779747 M * Bertl usually ntpd fixes the time constantly 1414779788 M * gnarface yea, not running it yet. the clock chip never kept good time in this machine, so usually i did, but seemingly "slipping a bunch all at once" i had never noticed before 1414779890 M * Bertl the clock chip (rtc) is usually not involved when the kernel is running 1414779905 M * gnarface hmm. 1414779907 M * Bertl i.e. it is only used to get the initial time and/or store the time on shutdown 1414779930 M * gnarface so the skew could be a cpu issue too then? 1414779946 M * Bertl yes, mostly an interrupt issue I'd say 1414779979 M * Bertl usually timers are used by the kernel to generate ticks, which in turn are counted to get the kernel time 1414780043 M * gnarface if i do decide to change the PATA cable for a SATA cable and adapter, and plug this drive into a SATA port instead, just to eliminate the possibility of the IDE part of the harddrive controller being part of the equation, i don't have to reformat the drive, right? 1414780143 M * gnarface the cpu could be suspect, but the harddrive controller was always flaky or poorly supported or both 1414780149 M * gnarface and the cable is definitely suspect 1414780232 M * Bertl does the drive support both pata and sata? 1414780258 M * Bertl (most drives don't) 1414780287 M * gnarface no, the drive itself only supports pata, but i have one of those old abit seriellel 2 adapters that is supposed to not require any specific motherboard side support 1414780392 M * gnarface i've just never tried to format a drive and then swap it in 1414780405 M * gnarface though i realize i should already know whether that'd work or not 1414780453 M * Bertl no, there is no difference 1414780475 M * Bertl i.e. the data in (somewhat) modern drives is in sequential logical blockjs 1414780478 M * Bertl *blocks 1414780494 M * Bertl the only possiblility for something to go wrong is the BIOS not booting from it 1414780512 M * gnarface alright, thanks for the info 1414780634 M * Bertl you're welcome! 1414780649 J * alpha_one_x86 ~kvirc@190.186.67.60 1414780701 M * alpha_one_x86 Hello, update kernel plz!!! 1414780847 M * gnarface say, Bertl do you have any opinion on CONFIG_WQ_POWER_EFFICIENT_DEFAULT for servers? 1414780899 M * gnarface also, whether i should maybe turn the timer frequency to something higher than 250Hz? 1414781094 M * Bertl no opinion on the config option 1414781122 M * Bertl for server, usually you want longer activity periods, unless you need more interactivity 1414781160 M * Bertl if the system seems 'slow' and doesn't respond as quickly as expected, you want to turn up the tick rate 1414781332 M * gnarface nah, interactivity seems fine, i was just wondering if maybe the teamfortress2 server might be unhappy with the tick rate and that could be causing these complaints in dmesg 1414781565 M * gnarface i thought CONFIG_WQ_POWER_EFFICIENT_DEFAULT might have been an issue too just possibly, but looking at my config again it turns out i chickened out on enabling it anyway 1414781938 Q * quote Ping timeout: 480 seconds 1414783632 Q * ensc|w Remote host closed the connection 1414783643 J * ensc|w ~ensc@www-old.sigma-chemnitz.de 1414784373 Q * PowerKe Quit: leaving 1414784875 J * Aiken ~Aiken@d63f.h.jbmb.net 1414785169 Q * ensc|w Ping timeout: 480 seconds 1414785388 J * ensc|w ~ensc@www-old.sigma-chemnitz.de 1414788688 J * zerick ~zerick@190.118.16.131 1414793588 Q * alpha_one_x86 Quit: KVIrc KVIrc Aria 4.3.1, revision: 6250, sources date: 20120701, built on: 2014-08-04 21:20:58 UTC http://www.kvirc.net/ 1414798974 Q * FloodServ Service unloaded 1414799118 J * FloodServ services@services.oftc.net 1414799890 Q * fstd Remote host closed the connection