1227312003 M * Bertl excellent, let me see what we can do there :)
1227312122 M * Bertl okay, let's do two more checks, one with the first hunk applied, and a second one with the second hunk
1227312137 M * Bertl I'll prepare a patch for the debug output in the meanwhile
1227312137 Q * dowdle Remote host closed the connection
1227312384 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com
1227312667 M * Hawq with just first hunk applied it doesn't work. now checking with just second hunk
1227312863 M * Hawq with second hunk it works
1227312870 M * Bertl okay, great!
1227312879 Q * chI6iT41 Ping timeout: 480 seconds
1227313040 M * Hawq to have it clear. it works with 1st applied and second applied with -R
1227313065 M * Bertl hmm, that sounds wrong :)
1227313153 M * Hawq let me check it again then by looking into sources
1227313234 M * Hawq yes. thats correct. from http://paste.linux-vserver.org/12620 first hunk is applied and second reverted
1227313269 M * Bertl note, we are dealing with tri-state here
1227313285 M * Bertl applied, ignored, reverted
1227313315 M * Bertl I hope your test case is {ignored, applied}
1227313331 M * Bertl (based on the Linux-VServer kernel)
1227313365 M * Bertl because reverting those hunks on a Linux-VServer kernel should simply fail
1227313471 M * Hawq oops! ok. its all because its late :) I'll recheck with ignored/applied :)
1227313704 Q * PowerKe Quit: Reboot
1227313878 J * pisco_ ~pisco@86.59.118.153
1227313986 Q * pisco Ping timeout: 480 seconds
1227314101 J * chI6iT41 ~chigital@tmo-100-186.customers.d1-online.com
1227314108 M * Bertl http://vserver.13thfloor.at/Experimental/delta-sig-debug01.diff this is the first patch to test with (goes ontop of an unmodified Linux-VServer kernel) if the {ignored, applied} was working :)
1227314229 J * PowerKe ~tom@d5153A64C.access.telenet.be
1227314541 M * Hawq with http://pld.pastebin.com/f78cd17c1 ignored and http://pld.pastebin.com/f1a579e50 applied it works. vice versa it fails.
1227314684 M * Hawq which debugging should I set via sysctl?
1227314838 M * Bertl vserver.debug_misc=128
1227315048 M * Hawq kill_something_info didn't appeared in dmesg after trying to switch consoles
1227315100 M * Bertl hmm, that's definitely strange
1227315122 M * Bertl you're sure you did apply the debug patch? and Linux-VServer debugging is enabled?
1227315157 M * Hawq yes. patch applied, debugging enabled.
1227315207 M * Bertl well, then we have a problem ...
1227315229 M * Bertl i.e. something must be wrong here, or a flaw in my logic
1227315266 Q * chI6iT41 Ping timeout: 480 seconds
1227315276 M * Bertl but I guess it is quite reasonable to argue that if the debug message is missing, this path is not taken, and if that is the case, the second hunk has no effect whatsoever 
1227315310 M * Bertl but double check first, that vserver.debug_misc contains the 128
1227315377 M * Hawq # sysctl vserver.debug_misc
1227315377 M * Hawq vserver.debug_misc = 128
1227315424 M * Bertl well, go ahead and remove that vx_check(vx_task_xid(p), VS_ADMIN|VS_IDENT) check from the if() and see if the switching works then
1227315449 M * Bertl maybe we have some signalling way earlier
1227315466 M * Bertl wouldn't hurt to set the debug_misc on boot
1227315482 M * Hawq with just second hunk applied it works. shouldn't debug go somewhere near first hunk then? just asking. I barely understand how it works by looking at this source).
1227315551 M * Bertl okay, let's take one step back and show me the one and only patch you applied
1227315710 M * Hawq from Linux-VServer I reverted this: http://pld.pastebin.com/f78cd17c1
1227315724 M * Hawq its original hunk from original vs patch
1227315758 M * Hawq so it is like the original patch - this hunk was applied
1227315776 M * Hawq and it works
1227315777 M * Bertl ah, okay, so you reverted the other one :)
1227315798 M * Bertl good, then I'll have to move the debug stuff there :)
1227315821 M * Hawq  I'll move it in source, just tell me where :)
1227315839 M * Bertl nah, needs some adjustemnts to work there
1227315867 M * Hawq ok
1227315921 M * Hawq reverted delta-sig-debug01.diff
1227316370 M * Bertl http://vserver.13thfloor.at/Experimental/delta-sig-debug02.diff
1227316575 M * Bertl same debug setup as before, don't be terribly surprised if the switching works now
1227317198 M * Hawq problem. kernel oops almost immedaitely after setting vserver.debug_misc = 128
1227317222 M * Hawq machine halts after that
1227317788 M * Bertl okay, check without vserver.debug_misc
1227317826 M * Bertl I'll fix up the patch in the meantime :)
1227317965 M * Hawq I've checked with vxdprintk commented out and switching works :)
1227317974 M * Bertl works fine here, btw, are you sure that the machine oopses?
1227318025 M * Bertl I thought so, so that is a change we can easily integrate, as we couldn't decide whether it should be WATCH or ADMIN (and I guess that settles the score, for now, in favor of admin)
1227318051 M * Hawq yeah, it oopsed, displayed kernel panic, one of last lines of opps was saying about kill_pid_info. I had to hard reset it
1227318070 M * Bertl would be really nice to grab (capture) that oops somehow
1227318089 M * Bertl as I said, it seems to work fine here
1227318103 M * Bertl [    9.608923] vxD: ffff88000f82f040: kill_pid_info(15,{15,0},[#0]) ffff88000fb61040[#0,326] 1
1227318116 M * Hawq digital camera is the only way. but won't get full oops this way
1227318132 M * Bertl better than nothing, maybe add vga=ask
1227318148 M * Bertl (and select a resolution with a lot of lines :)
1227318175 M * Hawq ok. rebooting and taking photo. brbr
1227318177 M * Hawq brb
1227318385 J * derjohn_mob ~aj@e180193191.adsl.alicedsl.de
1227319098 M * Hawq uploading image
1227319185 M * Hawq http://hawk.furud.net/files/vs_oops.jpg
1227319223 M * Hawq now its really time to go sleep. its 3 am here :)
1227319231 M * Bertl here too :)
1227319233 M * Hawq thanks for help Bertl
1227319248 M * Bertl you're welcome! should work for you now, just do the WATCH -> ADMIN change
1227319260 M * Bertl (no need for the debug stuff)
1227319282 M * Hawq yeah. I'll update to 2.6.27.7 too :) but after sleeping few hours :)
1227319292 M * Hawq nite
1227319302 M * Bertl thanks for debugging this! good night!
1227319318 M * Bertl okay, I'm off to bed now too .. so have a good one everyone!
1227319323 N * Bertl Bertl_zZ
1227320757 J * balbir_desk ~balbir@122.167.195.171
1227321073 Q * hparker Quit: Quit
1227321502 Q * balbir_desk Ping timeout: 480 seconds
1227322155 J * balbir_desk ~balbir@122.167.215.220
1227322168 J * hparker ~hparker@linux.homershut.net
1227325995 Q * geb Remote host closed the connection
1227326165 P * testo 
1227328681 Q * derjohn_mob Ping timeout: 480 seconds
1227331425 Q * FireEgl Quit: Leaving...
1227331496 N * quinq qzqy
1227335175 J * derjohn_mob ~aj@e180212062.adsl.alicedsl.de
1227336923 J * hijacker ~hijacker@87-126-142-51.btc-net.bg
1227337139 Q * derjohn_mob Ping timeout: 480 seconds
1227338019 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com
1227338417 Q * hijacker Quit: Leaving
1227338432 J * hijacker ~hijacker@87-126-142-51.btc-net.bg
1227339529 Q * ghislainocfs21 Ping timeout: 480 seconds
1227339817 Q * FireEgl Quit: Leaving...
1227340223 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com
1227340305 Q * micah Remote host closed the connection
1227341309 J * ghislainocfs2 ~Ghislain@LPuteaux-151-41-11-129.w217-128.abo.wanadoo.fr
1227341650 Q * pisco_ Remote host closed the connection
1227341807 J * pisco ~pisco@86.59.118.153
1227342592 J * testo ~some@119.224.36.62
1227343096 P * testo 
1227343355 J * testo ~some@119.224.36.62
1227345270 Q * hijacker Quit: Leaving
1227345792 J * micah ~micah@micah.riseup.net
1227346666 Q * doener Quit: leaving
1227349695 Q * esa Quit: Coyote finally caught me
1227350252 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1227350406 M * bibabu Hello, is there a solution to use iptables inside a virtual guest?
1227350536 M * ncopa vserver does not virtualize the ip stack
1227350555 M * ncopa so if you run iptables in one guest, you change the rules for all guests
1227350586 N * Bertl_zZ Bertl
1227350591 M * Bertl morning folks!
1227350623 M * Bertl bibabu: in the near? future you can use network namespaces to provide that for Linux-VServer (for a price: overhead)
1227350661 M * Bertl bibabu: you also can 'relay' the iptables commands to the host, filter them trough a policy daemon, and apply them to proper chains
1227350666 M * arekm little overhead right? I mean the same as on host if you turn network ns on in the kernel while building it?
1227350686 M * Bertl no, you have twice the overhead there
1227350700 M * Bertl the packets have to traverse two stacks
1227350818 M * Bertl so basically you get Pa (performance A) with NN turned off, then you get Pb = Pa + Ob (with NN turned on), and finally you get Pc = 2*Pb + Oc for a guest
1227350830 M * ncopa that overhead is kinda what you want when you set up an extra firewall
1227350838 M * ncopa or router
1227350856 J * ktwilight_ ~ktwilight@177.113-66-87.adsl-dyn.isp.belgacom.be
1227351124 Q * ktwilight__ Ping timeout: 480 seconds
1227351152 M * arekm http://lxc.sourceforge.net/network/benchs.php
1227351317 M * Bertl yep, sums it up quite nicely
1227351771 J * ntrs ~ntrs@77.29.206.91
1227352286 J * cga ~weechat@94.36.113.17
1227352658 J * dna ~dna@52-200-103-86.dynamic.dsl.tng.de
1227352900 J * oliwel ~chatzilla@ppp-82-135-94-179.dynamic.mnet-online.de
1227354141 N * Bertl Bertl_oO
1227354994 Q * ntrs Ping timeout: 480 seconds
1227355704 Q * tokkee Remote host closed the connection
1227355930 Q * dna Quit: Verlassend
1227357615 J * pmenier ~pmenier@ACaen-152-1-104-104.w83-115.abo.wanadoo.fr
1227359471 J * chI6iT41 ~chigital@tmo-100-226.customers.d1-online.com
1227360936 Q * balbir_desk Ping timeout: 480 seconds
1227361047 Q * nkukard Quit: Leaving
1227361117 Q * chI6iT41 Ping timeout: 480 seconds
1227361608 J * balbir_desk ~balbir@122.167.216.8
1227362223 J * chI6iT41 ~chigital@tmo-100-161.customers.d1-online.com
1227362514 Q * pmenier Ping timeout: 480 seconds
1227362535 J * pmenier ~pmenier@ACaen-152-1-2-77.w83-115.abo.wanadoo.fr
1227363264 Q * chI6iT41 Ping timeout: 480 seconds
1227363312 J * geb ~geb@79.82.4.4
1227364006 J * ntrs ~ntrs@77.29.9.198
1227364122 Q * oliwel Quit: ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]
1227364367 Q * balbir_desk Read error: Connection reset by peer
1227364841 J * chI6iT41 ~chigital@tmo-100-135.customers.d1-online.com
1227365032 N * Bertl_oO Bertl
1227365035 M * Bertl back now ..
1227366834 Q * chI6iT41 Ping timeout: 480 seconds
1227366945 J * tokkee tokkee@faui2k3.org
1227367164 Q * tokkee 
1227367198 J * tokkee tokkee@ssh.faui2k3.org
1227367498 J * balbir_desk ~balbir@122.167.222.129
1227367543 N * qzqy quinq
1227367850 M * bliz42 hey Bertl, how much overhead would you expect to see on a system with a single running vserver?  Is there some additional switching over a vanilla kernel to make sure other vservers get fair use of the processor that doesn't normally occur, even if there aren't other vservers running?  And if there are other servers running, but not really doing anything active, would there be a performance hit from switching to give them a chance to d
1227367884 M * bliz42 (the above questions in a setup without resource limiting in place)
1227367906 M * Bertl a single running guest vs. no guest (i.e. same services on the host) is not supposed to show any measureable overhead
1227367935 M * Bertl i.e. if you can measure some slowdown, it is most likely a bug, and we'll fix it asap :)
1227367948 J * chI6iT41 ~chigital@tmo-100-41.customers.d1-online.com
1227368003 M * bliz42 ok, that's reassurring.. and what about a setup with say 4 or 6 vservers running, but only one really doing anything.. shoudl there be noticable overhead by that one active vserver?
1227368061 M * Bertl no, not really, actually a proper setup with several similar guests (e.g. same distro) can get faster than the real thing :)
1227368091 M * bliz42 faster?  how is that possible?
1227368096 M * Bertl the resource sharing (disk inodes, and resulting memory mapping) allows guests to be more effective than separate hosts
1227368151 M * Bertl just think, /bin/bash, that means about 1MB of binary, and 4MB of shared libraries
1227368182 M * Bertl if you use bash in 4 guests, with unification, then the inode cache and thus the memory mapping only happen once
1227368209 M * bliz42 yeah, i got ya.. i thought you meant the individual server could outperform a real individual server.. but you are saying the group can outperform a real group, and that makes sense
1227368241 M * Bertl yep, although there are certain artificial benchmarks, where a single guest can outperform the real system too
1227368254 M * Bertl but that is more an academical issue than a practical advantage
1227368280 M * bliz42 experienced some processing delays (significant) on one of our qa servers at the office, and it was suggested it might be because of the vserver switching overhead, and i did not feel it was likely, but thought i would check.
1227368324 M * Bertl if you do not limit resources for a guest, it will not show any difference in processing/handling than the host
1227368358 M * Bertl what kind of delays? network related or cpu/scheduling?
1227368361 M * bliz42 used to take less than 48 hours to do a full data process recalc on a native server.. now on a bigger, faster server with more memory, in a vserver setup, and it looks like it's going to take about a week and a half for the recalc.. but the data has changed singificantly, along with the code, so i really don't think it falls on vserver
1227368398 M * Bertl yeah, it would require to compare it with the host (if you changed almost everything :)
1227368408 M * bliz42 yep yep
1227368422 M * Bertl note that on Linux you need to carefully select hardware and configuration to optimize for a specific task
1227368456 M * bliz42 yeah, that's out of my hands..
1227368462 M * Bertl most often newer and faster systems can be outperformed by a carefully tuned 'old/slow' system too :)
1227368503 M * openblast thats interesting
1227368515 M * Bertl I would double check the I/O path (or suggest to do that) in your case ... that long lasting calculations usually point towards I/O problems
1227368585 M * Bertl openblast: it's quite simple actually, you use a hammer to drive a nail into something, not a high tech screw driver :)
1227368608 M * Bertl (why not do the same with computers :)
1227368609 M * openblast hehe, do you have any great links regarding that topic?
1227368649 M * openblast i only thought about the filesystem so far, but never tweaked kernel settings or similar
1227368652 M * Bertl the hammer/nail thing? :) not really, most of that knowledge is out of first hand experience
1227368657 M * openblast ok perhaps io-sched
1227368660 M * openblast ok
1227368683 M * Bertl let me give you an example I'm currently confronted with
1227368709 M * openblast ah :)
1227368735 M * Bertl I'm doing some major raid reconstruction (some TB) here, and to get that done, I decided to go for eSATA and a PM (port multiplier)
1227368765 M * openblast does it multiply sata ports?
1227368766 M * Bertl each disk, 1TB, can handle a sustained read/write of about 110 Mb/s
1227368799 Q * chI6iT41 Ping timeout: 480 seconds
1227368800 M * Bertl the eSATA port handles 3GBit/s and each disk interface can do 3GBit too
1227368821 M * openblast ok, yes
1227368828 M * Bertl naturally the PM divides the 3GBit link to 3/5 (can handle 5 disks on one port)
1227368865 M * Bertl so that gives 600Mbit/s sustained transfer to all disks (in theory)
1227368902 M * Bertl mapping that to Mb/s gives 375Mb/s total for the port, and 75Mb/s for each disk
1227368946 M * openblast yes
1227368946 M * Bertl so one could, in theory, expect something about 200-300Mb/s from a raid 5 setup here (at least for reading), right?
1227368964 M * openblast hm yeah
1227368995 M * Bertl okay, in the real world, that eSATA port belongs to a JMicron controller, attached to a PCIe port (onboard) of the motherboard
1227369013 M * openblast hm pcie 1x is 250mb/s iirc
1227369038 M * Bertl yep, so let's assume they were cheap and used that for the JMicron
1227369057 M * Bertl what really happens is the following:
1227369070 M * openblast probably the jmicron controller is bad ^^
1227369100 M * Bertl 1 disk: 65Mb/s, 2 disks 30M/s each, 3 disks 12M/s each, 4+ disks, only 3 disks are running at the same time, 2 disks are waiting :)
1227369113 M * openblast ugh 
1227369133 M * Bertl so, what does that mean for the average transfer rate of the raid5?
1227369146 M * Bertl well, almost 16M/s sustained transfer! YEAH!
1227369147 M * openblast well its crap then :p
1227369148 M * openblast hehe
1227369176 M * Bertl sure, but it is state of the art, the JMicron is common for desktop boards (together with ICH chipsets)
1227369206 M * openblast ah ok, i thought more about kernel optimizations and stuff then hardware things when you said old systems
1227369208 M * Bertl putting in a $40 eSATA card solves the problem
1227369215 M * openblast ok
1227369224 M * Bertl well, you can do a lot wrong in the kernel too
1227369226 M * openblast so choosing the right scheduler and filesystem and such
1227369231 M * openblast yes
1227369245 M * openblast hm are they available now for pcie? thats neat
1227369248 M * Bertl for example there are tons of tunables regarding stripe cache and disk readahead
1227369278 M * Bertl and even the parity scheme for raid setups can have huge impact
1227369282 M * openblast i can imagine
1227369331 M * Bertl once I replaced a high end hardware raid controller ($3000+) with software raid, and got almost 100% increase in overall performance
1227369378 M * Bertl just because the kernel elevator and memory was much better in getting the job done than this dedicated piece of hardware
1227369381 M * pmjdebruijn Bertl: performance often highly depends on how well written the Linux drivers is
1227369389 J * chI6iT41 ~chigital@tmo-100-180.customers.d1-online.com
1227369389 M * openblast yeah i read some benchmarks about hardware controllers
1227369418 M * openblast in the ct in this summer there were some
1227369528 M * pmjdebruijn isn't CT very Windows oriented?
1227369588 M * openblast hm well no, i think they have to cover windows of course to sell more
1227369605 M * openblast but sometimes they have cool articles about linux stuff as well
1227369682 M * openblast i only buy it when they have an in-depth article
1227370446 J * esa ~esa@ip-87-238-2-45.static.adsl.cheapnet.it
1227371012 Q * geb Remote host closed the connection
1227372022 J * nkukard ~nkukard@196.212.73.74
1227372306 Q * chI6iT41 Ping timeout: 480 seconds
1227372446 J * dowdle ~dowdle@71-221-8-241.blng.qwest.net
1227373132 J * Piet ~piet@86.59.118.153
1227373593 Q * nkukard Ping timeout: 480 seconds
1227374590 Q * Piet Remote host closed the connection
1227374708 J * Piet ~piet@86.59.118.153
1227374720 Q * Piet 
1227375300 Q * hparker Quit: Quit
1227377975 J * hparker ~hparker@linux.homershut.net
1227378561 J * ntrs_ ~ntrs@77.29.9.198
1227378782 Q * ntrs Ping timeout: 480 seconds
1227378938 M * testo Bertl  did you already tested SATA port multiplyer?
1227378993 M * Bertl some of them, yes
1227379884 J * docelic ~docelic@78.134.206.235
1227381343 M * karasz hello
1227381353 M * Bertl hello!
1227381378 M * karasz i am testing the last devel version of the vserver patch
1227381386 M * Bertl excellent!
1227381402 M * karasz and for some reason the vserver/switch.h file gets truncated upon aplying it
1227381429 M * Bertl sounds interesting
1227381432 M * karasz #define #endif  /* __KERNEL__ */
1227381435 A * pmjdebruijn didn't have that
1227381436 M * karasz this is the last line
1227381446 M * pmjdebruijn karasz: about which specific version are you talking?
1227381458 M * karasz 26.1
1227381460 M * karasz no
1227381462 M * karasz 36.1
1227381476 M * pmjdebruijn for 2.6.27.6?
1227381479 M * karasz yup
1227381517 M * Bertl let me give you an md5 for the patch
1227381525 M * karasz k
1227381530 M * Bertl d891cc6977e408a78bae91222745c9c3  patch-2.6.27.6-vs2.3.0.36.1.diff
1227381601 M * karasz shtimt.
1227381645 M * karasz the md5 is correct
1227381671 M * karasz and inside the diff switch.h is correct and longer than what i get.
1227381689 M * pmjdebruijn does diff complain?
1227381694 M * karasz no
1227381698 M * pmjdebruijn maybe I have the issue as well, but didn't notice
1227381714 M * Bertl do you have enough disk space (also in /tmp)?
1227381723 M * karasz but when i build the linux-headers i have a complaint.
1227381739 M * Bertl patch makes a copy of the file to be changed
1227381832 M * karasz as far as i know switch.h is vserver speciffic, isn't it?
1227381845 M * Bertl yep, it is created by this patch
1227381862 M * karasz unifdef: /build/karasz/....linux-2.6.27/usr/include/linux/vserver/switch.h.tmp: 100: Premature EOF (#if line 1 depth 1)
1227381873 M * karasz unifdef: output may be truncated
1227381883 M * karasz that is the complaint when building the headers
1227381884 M * Bertl ah, wait, you are talking about the built headers, not the original
1227381901 M * karasz built headers.
1227381915 M * Bertl let me check that
1227382019 M * karasz Bertl: yes, space is not an issue, i have plenty of that.
1227382047 M * Bertl well, that looks like a bug in the kernel header build system
1227382064 M * Bertl (or in the switch.h file, but I don't see it there, atm)
1227382121 J * nkukard ~nkukard@196.212.73.74
1227382176 M * karasz i looked at the .diff also, i cannot find anything susspicious there
1227382199 M * Bertl no, the file seems fine (switch.h) just the unifdef is doing something strange ...
1227382216 M * Bertl or one of the includes is messed up, checking now
1227382243 M * daniel_hozac you don't have to #define __user.
1227382248 M * daniel_hozac __user is removed by the scripts.
1227382254 M * karasz i am also using the l7-filter patch if taht is of any importance
1227382283 M * Bertl daniel_hozac: doesn't explain the misleading Premature EOF on #if, does it?
1227382303 M * daniel_hozac __user is removed, so it uses the next token.
1227382306 M * daniel_hozac which is #endif
1227382325 M * daniel_hozac so you get #define #endif, and no #endif.
1227382331 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net
1227382335 M * Bertl okay, that sounds like a bug in the script to me :)
1227382342 M * Bertl anyway, we can work around that :)
1227382350 M * daniel_hozac well, just removing #define __user will fix it.
1227382370 M * daniel_hozac it's what the scripts are meant to take care of.
1227382379 M * Bertl karasz: expect a .36.2 in a few minutes
1227382399 A * karasz does not _expect_ but thx for the time :)
1227382500 Q * dowdle Remote host closed the connection
1227382507 M * Bertl okay, it's up
1227382543 M * pmjdebruijn Bertl: does the fix have any relevance when not using unidif?
1227382578 M * Bertl no, but the .36.2 also changes the signalling behaviour which fixes the X11 switching issue
1227382578 M * karasz thx Bertl 
1227382587 M * pmjdebruijn ok thanks
1227384703 J * chI6iT41 ~chigital@tmo-096-227.customers.d1-online.com
1227384975 Q * docelic Quit: http://www.spinlocksolutions.com/
1227385228 J * ntrs__ ~ntrs@77.29.15.244
1227385643 Q * ntrs_ Ping timeout: 480 seconds
1227386099 J * derjohn_mob ~aj@p5B23CB0F.dip.t-dialin.net
1227386577 Q * cga Quit: WeeChat 0.2.6
1227387624 Q * chI6iT41 Quit: bin weg
1227388452 Q * testo Read error: Operation timed out
1227390009 J * doener ~doener@i577B9D81.versanet.de
1227392769 Q * ntrs__ Ping timeout: 480 seconds
1227393076 Q * pmenier Ping timeout: 480 seconds
1227393112 J * pmenier ~pmenier@ACaen-152-1-71-31.w83-115.abo.wanadoo.fr
1227393896 Q * pisco Ping timeout: 480 seconds
1227394514 Q * hparker Quit: Quit
1227394761 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86