1182556800 M * Bertl I just wondered, because linux thinks that you have 10gigabit ethernet :)
1182556826 J * arachnis1 arachnist@088156185052.who.vectranet.pl
1182556835 M * Bertl the broadcast address should be fine, did you do the iptables line now?
1182556852 M * Bertl in your case the correct line should be:
1182556883 Q * arachnist Read error: Connection reset by peer
1182556883 N * arachnis1 arachnist
1182556897 M * Bertl iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j SNAT --to-source 192.168.0.14
1182556959 M * Bertl and you might want to do a: 'ip route flush cache' after that
1182557034 M * oxylin yes I did
1182557050 M * oxylin but network interface init failed... A sec please
1182557133 M * oxylin I reboot again to see...
1182557142 M * oxylin but it seems to work with the iptable line
1182557182 J * click_ click@ti511110a080-0906.bb.online.no
1182557186 M * oxylin I don't understand why a Source NAT is sufficient ... 
1182557194 M * Bertl that is easy to explain
1182557201 P * stefani I'm Parting (the water)
1182557221 M * Bertl if you remove that iptables line, the ping will send the packet to the default gateway, via eth0
1182557243 M * Bertl but unfortunately it will carry a source ip of 192.168.100.X
1182557248 J * FireEgl FireEgl@Sebastian.Atlantica.US
1182557287 Q * click Ping timeout: 480 seconds
1182557288 M * Bertl so the default gateway routes the reply to the outside (or if configured properly, drops it into the garbage can :)
1182557295 M * oxylin It works after reboot and with the iptable line
1182557303 M * Bertl instead of sending it to your machine ...
1182557324 M * oxylin ok
1182557331 M * Bertl the SNAT line now does establish a source address network translation to the 192.168.0.X address assigned to the host
1182557348 M * Bertl (this includes outgoing and reply packets)
1182557362 M * oxylin ok
1182557366 M * oxylin great...
1182557367 M * Bertl so everything leaving eth0 will carry the 'correct' ip address
1182557381 M * Bertl (and your guests will have internet access)
1182557413 M * oxylin but I don't understand why it's working now... I don't change anything... juste reboot...
1182557413 M * Bertl btw, I just recreated your setup in my test system, and it works there as expected
1182557419 M * Bertl http://paste.linux-vserver.org/2709
1182557439 M * Bertl no idea what you did different last time, but obviously something was messed up :)
1182557454 M * oxylin :-D
1182557463 M * oxylin yes
1182557489 M * oxylin and it's secure the config we did?
1182557499 M * Bertl I would suspect VMware and then debian :)
1182557507 M * oxylin :)
1182557508 M * Bertl secure means?
1182557524 M * oxylin secure for attacks !
1182557530 M * oxylin from the Internet
1182557538 M * Bertl well, from outside, the guests cannot be reached
1182557554 M * Bertl you would have to do DNAT for that
1182557605 M * oxylin ok
1182557638 M * oxylin ah if I have DNAT? it's as secure as vserver are directly connected to Internet?
1182557705 M * Bertl well, you probably won't do DNAT of all ports, only for specific ports
1182557705 M * onox Bertl: what's the difference between "-j SNAT --to-source X" and "-j MASQUERADE"?
1182557752 M * Bertl onox: as you already showed, MASQ doesn't take an IP, and depending on the kernel version, it only works on forwared packets (traversing the FORWARD chain)
1182557764 M * Bertl *forwared
1182557767 M * Bertl *forwarded
1182557832 M * oxylin why iptables -t nat -A PREROUTING -d 192.168.0.14 -dport 80 -j DNAT --to-destination 192.168.100.3:80 give me an error
1182557844 M * oxylin on -d flag
1182557911 M * onox --dport?
1182557920 M * Bertl yep
1182557925 M * oxylin --dport does not exists I think
1182557931 M * oxylin ah ok
1182557941 M * onox -p tcp?
1182557943 M * Bertl -dport -> -d port
1182557970 M * Bertl long options (for iptables) have two dashes
1182558141 M * oxylin I need to put -p tcp
1182558146 M * oxylin and --dport
1182558181 M * oxylin ok it works...
1182558184 M * oxylin it's ok :
1182558188 M * oxylin thanks a lot 
1182558195 M * Bertl again, you're welcome!
1182558216 M * oxylin may be, a day, it's me who give advice ;)
1182558225 M * onox :)
1182558237 M * oxylin why not :d
1182558242 M * Bertl everything's possible ....
1182558246 M * oxylin after installs, and installs
1182558271 M * Bertl would be nice to attack our wiki (and fix/update/extend a few things)
1182558271 M * oxylin there is a way to save iptable status and restore it on boot automaticly?
1182558282 Q * bonbons Quit: Leaving
1182558291 M * Bertl usually runlevel scripts do that with iptables-save/restore
1182558299 M * oxylin Bertl, you're a developer of the project?
1182558319 M * Bertl (or you put the tables in /etc/sysconfig/iptables)
1182558330 M * Bertl oxylin: yes, I'm working on the project
1182558355 M * oxylin Bertl, for a long time?
1182558374 M * oxylin where are you from?
1182558375 M * Bertl should be almost four years now
1182558381 M * oxylin ok
1182558405 M * Bertl I'm from Austria, you are from France?
1182558412 M * oxylin yes
1182558420 M * oxylin near Paris
1182558501 Q * gerrit Ping timeout: 480 seconds
1182558505 M * Bertl and you are planning to use Linux-VServer for hosting?
1182558520 M * oxylin yes
1182558533 M * oxylin I will have a dedicated server
1182558555 M * oxylin and I plan to install vservers to host services
1182558556 M * Bertl well, we have a page (on the wiki) for Hosting Companies, if you like to put your contact infor there, feel free to do so :)
1182558571 M * oxylin to have an higher securit
1182558574 M * oxylin security
1182558636 M * oxylin my contact? my e-mail ?
1182558667 M * Bertl http://linux-vserver.org/VServer_Hosting
1182558679 M * oxylin I'am a student... I will not sale services
1182558681 M * oxylin :-D
1182558688 M * oxylin not for the moment
1182558698 M * Bertl well, maybe then this: http://linux-vserver.org/VServer_Users
1182558720 M * oxylin It's better in my case :d
1182558783 M * Bertl good, feel free to hang around, unless you are worried you might learn something :)
1182558902 J * click click@ti511110a080-0809.bb.online.no
1182558903 M * oxylin ok
1182558904 M * oxylin thks
1182558917 M * Bertl wb click!
1182558927 M * oxylin ???
1182558937 M * oxylin wb ?
1182558945 M * Bertl welcome back :)
1182558951 M * oxylin ok
1182558961 M * oxylin I'm going off now...
1182558970 M * Bertl k, cya!
1182558970 M * oxylin i'm a bit tired
1182558979 M * oxylin ++
1182558991 M * oxylin see later, on this channel
1182558991 M * oxylin ;)
1182559000 Q * oxylin Quit: Ex-Chat
1182559015 Q * click_ Ping timeout: 480 seconds
1182559245 Q * Aiken Quit: Leaving
1182559464 J * DoberMann_ ~james@AToulouse-156-1-64-138.w90-16.abo.wanadoo.fr
1182559570 Q * DoberMann[PullA] Ping timeout: 480 seconds
1182559702 J * click_ click@ti511110a080-1099.bb.online.no
1182559820 Q * click Ping timeout: 480 seconds
1182563879 Q * coderanger_ Ping timeout: 480 seconds
1182564146 Q * fatgoose Quit: fatgoose
1182567234 Q * Piet Quit: Piet
1182567390 Q * infowolfe Server closed connection
1182567404 J * infowolfe ~infowolfe@c-24-10-147-179.hsd1.ut.comcast.net
1182567631 J * Aiken ~james@ppp121-45-220-241.lns2.bne1.internode.on.net
1182568094 Q * pusling Ping timeout: 480 seconds
1182568486 M * Bertl okay, I'm off to bed now ... have a good one everyone!
1182568492 N * Bertl Bertl_zZ
1182568742 J * pusling pusling@88.212.70.38
1182569419 J * infowolfe_ ~infowolfe@c-24-10-147-179.hsd1.ut.comcast.net
1182569434 J * eyck_ eyck@kuszelas.com
1182569754 Q * infowolfe Ping timeout: 480 seconds
1182575821 Q * FloodServ charon.oftc.net galapagos.oftc.net
1182575821 Q * mountie charon.oftc.net galapagos.oftc.net
1182575821 Q * coderanger charon.oftc.net galapagos.oftc.net
1182575821 Q * hardwire charon.oftc.net galapagos.oftc.net
1182575821 Q * mugwump charon.oftc.net galapagos.oftc.net
1182575821 Q * Rich_Estill charon.oftc.net galapagos.oftc.net
1182575821 Q * micah charon.oftc.net galapagos.oftc.net
1182575821 Q * dilinger charon.oftc.net galapagos.oftc.net
1182575821 Q * hallyn charon.oftc.net galapagos.oftc.net
1182575821 Q * jkl charon.oftc.net galapagos.oftc.net
1182575821 Q * AndrewLee charon.oftc.net galapagos.oftc.net
1182575821 Q * phreak`` charon.oftc.net galapagos.oftc.net
1182575881 J * mountie ~mountie@CPE000f66950c89-CM000a739acaa4.cpe.net.cable.rogers.com
1182575881 J * hallyn ~xa@adsl-75-2-66-98.dsl.chcgil.sbcglobal.net
1182575881 J * FloodServ services@services.oftc.net
1182575881 J * hardwire ~bip@rdbck-1961.wasilla.mtaonline.net
1182575881 J * coderanger ~coderange@c-65-96-210-168.hsd1.ma.comcast.net
1182575881 J * Rich_Estill ~restill@c-24-11-195-139.hsd1.mi.comcast.net
1182575881 J * dilinger ~dilinger@mail.queued.net
1182575881 J * mugwump ~samv@watts.utsl.gen.nz
1182575881 J * micah ~micah@micah.riseup.net
1182575881 J * AndrewLee ~andrew@flat.iis.sinica.edu.tw
1182575881 J * phreak`` ~phreak``@deimos.barfoo.org
1182575881 J * jkl jkl@c-67-173-253-237.hsd1.co.comcast.net
1182577618 Q * meandtheshell Quit: Leaving.
1182578393 J * HeinMueck ~Miranda@dslb-088-064-012-169.pools.arcor-ip.net
1182588060 J * zLinux ~zLinux@88.213.31.27
1182588343 Q * zLinux 
1182588387 Q * infowolfe_ Quit: Leaving
1182588427 J * bonbons ~bonbons@2001:5c0:85e2:0:20b:5dff:fec7:6b33
1182590133 Q * rob-84x^ Ping timeout: 480 seconds
1182590137 J * rob-84x^ rob@submarine.ath.cx
1182590318 Q * eyck_ Ping timeout: 480 seconds
1182591042 J * pmenier ~pmenier@ACaen-152-1-21-188.w83-115.abo.wanadoo.fr
1182591558 N * Bertl_zZ Bertl
1182591563 M * Bertl morning folks!
1182591582 M * pmenier Hi Bertl
1182591793 N * pmenier pmenier_Zz
1182591803 M * haxier Good morning Bertl!
1182591842 N * pmenier_Zz pmenier
1182591909 M * haxier I've cheched the 2.6.16.52-vs2.0.3-rc3 patch... it's the same that .43-vs2.0.3-rc2 but synced with .52
1182591918 M * sid3windr .52 wtf
1182591926 M * haxier 2.6.16.52
1182591951 M * Bertl haxier: yep
1182591968 M * haxier if there's no new fixes/additions, then you can make it the new 'old-stable'
1182591983 M * Bertl haxier: we didn't find any missing patches so far
1182592004 M * Bertl haxier: so if that is reported fine by a few folks, we consider it released
1182592017 M * haxier After all, I have vservers running that version for months without problem
1182592135 Q * micah Server closed connection
1182592141 J * micah ~micah@micah.riseup.net
1182592350 J * SexYBabY_ ~tefon@88.231.30.20
1182592419 M * SexYBabY_ Click Here --->  Www.DereceMarekeT.Com  <--- Click Here 
1182592429 M * sid3windr shoot to kill!
1182592452 M * SexYBabY_ :)
1182592453 M * SexYBabY_ no
1182592453 M * SexYBabY_ Click Here --->  Www.DereceMarekeT.Com  <--- Click Here 
1182592457 M * sid3windr exactly
1182592515 Q * SexYBabY_ 
1182593341 J * bzed ~bzed@10-205-116-85.dsl.manitu.net
1182594859 M * derjohn hi, did anyone work with nbd devices? I try to use them for mounting vmware disk (not, off-topic, as a vserver-patched linux kernel runs within :)), but I looks like they crash the machine, if it is running low on ram: http://blog.derjohn.de/snipsnap/space/start/2007-06-22/1#vmware-loop_(and_vmware-mount)_really_sucks!
1182594884 M * derjohn is there a way to "reserve" the resources the
1182594889 M * derjohn *they need ?
1182595002 M * Wonka run low on ram? not enough swap or what?
1182595747 M * derjohn Wonka, Well, good question. I assume there was some reason the author of vmdk-mount  (see blog) told me, that there might be that problem. Do the nbd's try to allocate physical RAM? Basically that would be good idea. 1. Speed 2. In case swap is on the ndb mounted device. 
1182595804 M * derjohn hm, 512 MB RAM, 512 MB swap on that machine.
1182595891 M * derjohn but 450 MB RAM are used even before I start the backup on ndb. But maybe additional RAM is a very good idea, but wont solve the problem in general.
1182595910 N * DoberMann_ DoberMann
1182596179 J * jmcaricand ~kvirc@d77-216-232-124.cust.tele2.fr
1182596330 J * Piet hiddenserv@tor.noreply.org
1182596381 M * Bertl derjohn: the main question is 'used for what?' I assume buffers and caches :)
1182596416 M * Bertl derjohn: I also assume that it requires kernel memory (which is not pageable anyways)
1182596733 M * bonbons derjohn: I played with nbd, but until now I got not so good results, with XFS on to of it (either crashed or BUG() and processes ending in D state)
1182596852 M * bonbons but I wonder why nbd needs the client process to keep hanging around, it could do as is done be kernel for nfs or smb mounts, have the network connection live completely in kernel space
1182597360 M * derjohn well, doesnt sound like a good idea to rely on nbd ;)
1182597420 M * derjohn but vmware-crap dosent offer another way to mount theit vmdk files directly. only a buggy tool called "vmware-loop", which mounts via nbd. no fuse. no dm. sad.
1182597471 M * derjohn bonbons, have you been able to reproduce the percpu memory stuff ?
1182597488 M * Bertl what is the reason for using vmware in the first place?
1182597498 M * Bertl the good driver support?
1182597520 M * bonbons it's still on the todo list
1182597635 M * derjohn Bertl, basically customer demand ;) and the lack of a VT hardware (we needed a virtual 'windows')
1182597707 M * Bertl so? QEMU has vnc support, you know?
1182597741 Q * mugwump Server closed connection
1182597744 J * mugwump ~samv@watts.utsl.gen.nz
1182597778 M * derjohn Bertl, that would be a better try ... what about performance qemu vs. vmware (on non VT ....) ? 
1182597788 M * derjohn Bertl, did you try both already?
1182597827 M * derjohn BTW: xensource's commercial xen has windows-drivers that a coded by M$ themselves and are said to be lightning fast.
1182598363 M * Bertl QEMU is okay if you use the kernel module
1182598519 M * derjohn Bertl, yep. and KVM might be a fine alternative on VT ....
1182598554 J * meandtheshell ~markus@85.127.102.3
1182598565 M * derjohn Bertl, and: on AMD64 the kqemu module still has "quirks" (memory hole? segfaults?) ... at leat in full accel mode.
1182598578 M * Bertl derjohn: QEMU uses the kvm functionality on VT/Pacifica too
1182598607 M * derjohn vmware is for customers simply more practial. the $dau-users have a web-interface to start/stop their machines.
1182598649 M * derjohn Bertl, ah. I think I need to upgrade my desktop to some AMD X2/AM2  to test the VT thingy.
1182599052 M * derjohn Bertl, bonbons: I added your useful about ndb info to my blog entry ( http://blog.derjohn.de/snipsnap/space/start/2007-06-22/1 ) . So other ppl can read one more word of warning. Just FYI.
1182599214 M * bonbons derjohn, I file a bug for that on kernel bugzilla some time ago: http://bugzilla.kernel.org/show_bug.cgi?id=7364
1182599248 M * derjohn bonbons, funny, I am just on sf.net to look for the ndb homepage to file a bug ;)
1182599286 M * bonbons at beginning it crashed because of stack overflows, later when the stack overflows we fixed (worked around with not selecting 4k stacks) it stalled
1182599468 J * duckx ~Duck@tox.dyndns.org
1182599482 Q * meandtheshell Quit: Leaving.
1182599749 M * bonbons derjohn: for the percpu problem, do you have exact dmesg output when it complainsnot being able to allocate that memory?
1182599752 J * meandtheshell ~markus@85.127.102.3
1182599831 M * derjohn bonbons, hm, i dont think I have a complete one left. And I got rid of all thoese kernels. Or are you only interested in th dmesg line, when the bug is hit ?
1182599847 Q * duckx Remote host closed the connection
1182599862 M * bonbons only the dmesg line where it complains
1182599875 J * duckx ~Duck@tox.dyndns.org
1182599908 M * derjohn and i still have a problem when the kernel tries to autoload the ipv6 module. Then the kheler gets stuck with some modprobe pfblabla and consumes 99% CPU. If i load the module manually everything runs fine.
1182599929 M * bonbons trying looking at where in kernel sources is the matching code
1182599941 M * Bertl derjohn: which kernel?
1182600016 M * derjohn Bertl, it began with 2.6.18 IIRC and is there on 2.6.20.x (currently .12 in-production)
1182600022 M * derjohn Mostly I see in dmesg:
1182600022 M * derjohn Could not allocate 4 bytes percpu data
1182600062 M * derjohn but the byte value raised to something 384 or such ... I cannot find such a dmesg log (with 3xx...). but the line read "same".
1182600093 Q * dilinger Server closed connection
1182600094 J * dilinger ~dilinger@mail.queued.net
1182600193 M * derjohn bonbons, of needed: I have a shutdown-ed box here, where a broken kernel is on. I can grab the box from storage and reboot if needed.
1182600256 M * derjohn but now I have to leave, as I spent a day off in nuermberg ...
1182600282 M * bonbons your config is SMP on i386? For non-SMP configs percpu alloc is wrapper for kzalloc
1182600310 M * derjohn bonbons, yes, sincve 2.6.18 is only complile smp .
1182600315 M * derjohn *since
1182600367 M * bonbons ok, good reason for me no seeing it, my kernels are all compiled with CONFIG_SMP=n as I have no multi-core/multi-processor i386 boxes
1182600368 M * Bertl funny 4 bytes sounds strange
1182600426 M * derjohn bonbons, so we have found a difference which sounds like a cause for the problem in the .configs ?
1182600472 M * bonbons not a cause, but a trigger
1182600476 M * derjohn Bertl, the kernels with the 4 byte stuff dont crash. Since 2.6.20 the value got higher and the crashed began. 
1182600503 M * derjohn "i've got a trigger inside" ;)
1182600766 J * pflanze ~chris@77-56-91-62.dclient.hispeed.ch
1182600781 M * pflanze Hello
1182600961 M * Bertl hey pflanze!
1182601377 M * pflanze There are problems rebooting vservers when the machine is under load.
1182601412 M * pflanze Already load 3.4 is enough.
1182601481 M * pflanze I've observed this on different vserver clients. They take about 60 seconds to disappear from the hosts vserver-stat, but never come back up again.
1182601510 M * pflanze vserver foo start   from the host starts them up again fine; reboot -f from inside the client and the same thing happens again.
1182601530 M * pflanze Until the load drops to below 1 or so, then they come back by themselves again fine.
1182601559 M * pflanze Looks like some timeout problem somewhere to me.
1182601611 M * pflanze The funny part is that "vserver foo start" only takes about 10 seconds under the same load. So the timeout probably happens because of the slow shutdown (whyever that is so slow).
1182601616 Q * Rich_Estill Server closed connection
1182601637 J * Rich_Estill ~restill@c-24-11-195-139.hsd1.mi.comcast.net
1182601650 M * pflanze The mentioned load is only because of some vserver apt-get upgrade'ing itself, btw. That's enough to reach that load.
1182601652 M * Bertl pflanze: kernel/tool version?
1182601671 M * pflanze 2.6.19.3-vs2.2.0-rc12, 0.30.213-rc1
1182601823 M * Bertl try to update to the releases 
1182601833 M * Bertl i.e. vs2.2.0 and 0.30.213
1182601884 M * pflanze k
1182601924 M * Bertl if the issue persists, we'll investigate
1182602775 M * pflanze well I don't know when I get to upgrade the kernel/utils. Could take a week.
1182602794 M * pflanze but I'll report back again when I notice the problem.
1182602849 M * pflanze (If there's a security problem with the above versions, then it'll get higher priority)
1182604406 J * zLinux ~zLinux@88.213.31.27
1182604771 Q * FireEgl Read error: Connection reset by peer
1182608446 Q * Aiken Quit: Leaving
1182610648 M * Bertl nap attack ... back later ...
1182610653 N * Bertl Bertl_zZ
1182612288 Q * Solaris Remote host closed the connection
1182614551 Q * ensc Ping timeout: 480 seconds
1182615643 J * ensc ~irc-ensc@p54B4F061.dip.t-dialin.net
1182615644 J * eyck_ eyck@kuszelas.com
1182615892 Q * pmenier Quit: KVIrc 3.2.0 'Realia'
1182615935 J * DustPuppy ~dax@c1-81-10.wblv.isadsl.co.za
1182615995 Q * DustPuppy Remote host closed the connection
1182616241 J * Solaris ~satan@89.155.106.6
1182616711 J * eSa| ~kvirc@ip-87-238-2-45.adsl.cheapnet.it
1182618210 Q * onox Ping timeout: 480 seconds
1182619989 M * daniel_hozac Bertl_zZ: no luck getting rpm to do the right thing. it hits the barrier, and entering the context earlier means that's disallowed... if you want to look at it, the hack script i've been testing with is at http://people.linux-vserver.org/~dhozac/p/uv/experimental/new-vrpm
1182620026 M * daniel_hozac i can't really think of any way to work around it without hacking rpm.
1182620470 Q * jmcaricand Quit: KVIrc 3.2.4 Anomalies http://www.kvirc.net/
1182620772 J * slack101 ~Administr@cpe-71-74-77-84.insight.res.rr.com
1182620798 M * slack101 which version of vserver is in the Lenny / debian repos ?
1182620880 M * daniel_hozac 2.6.21 something and util-vserver 0.30.213, i think. easiest way to find out is to just ask packages.debian.org...
1182620905 M * slack101 i might jus install vserver this way i was using gentoo
1182620927 M * slack101 does 2.6.21 still have the not being able to start bind9 in guest without recompiling or ?
1182620942 M * daniel_hozac no kernel past 2.6.19 has that...
1182620967 M * slack101 ah
1182620972 M * slack101 what the newest kerrnel now ?
1182620990 M * daniel_hozac again, easier to just ask kernel.org.
1182621070 M * slack101 i meant
1182621074 M * slack101 vserver kerrnel
1182621094 M * daniel_hozac so make that linux-vserver.org.
1182621109 M * daniel_hozac (or vserver.13thfloor.at/Experimental)
1182621192 M * bonbons derjohn: as far as I see it always fails to allocate percpu memory... (in kenrel/module.c)
1182621242 M * daniel_hozac like, it's not even conditional?
1182621323 M * daniel_hozac looks like it's supposed to succeed in the for loop, no? (assuming we're talking about percpu_modalloc)
1182621349 M * bonbons look at kernel/module.c, percpu_modalloc(), inside the for(;;) loop
1182621379 M * daniel_hozac right.
1182621403 M * bonbons there is a check on (pcpu_size[i] < 0 || ...), and pcpu_size[0], pcpu_size[1] are both negative
1182621450 M * bonbons so there is something weird here, the values are initialized a few lines below in percpu_modinit()
1182621507 M * bonbons need to check thatcode area in a vanilla kernel and see which of the patches derjohn applies breaks things (if it's not "broken" in vanilla)
1182621511 M * daniel_hozac hmm, you're right.
1182622056 M * bonbons looks like code s no different to vanilla 2.6.22-rc5, so the point of interest is: __per_cpu_start[] and __per_cpu_end[] which according to comment on line above are created by linker magic
1182622067 M * bonbons so need to find out what that magic is!
1182622219 M * bonbons derjohn: by the way, the kernel outputs: "No per-cpu room for modules." in the middle of boot sequence
1182623065 M * bonbons I guess it's a matter of size between __per_cpu_start and __per_cpu_end, just don't understand how those are determined... (arch/${ARCH}/kernel/vmlinux.lds.S)
1182624864 Q * Piet Remote host closed the connection
1182625446 N * Bertl_zZ Bertl
1182625464 M * Bertl okay, translocating now?
1182625468 M * waldi hi Bertl 
1182625471 M * Bertl back later ...
1182625476 N * Bertl Bertl_oO
1182626700 M * waldi hrm, empty stack traces are so usefull ...
1182626729 Q * haxier Remote host closed the connection
1182626912 J * Piet hiddenserv@tor.noreply.org
1182628396 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net
1182628739 Q * DavidS Quit: Leaving.
1182629529 J * coderanger_ ~laptop@wireless-62.media.mit.edu
1182631440 J * ktwilight_ ~ktwilight@225.126-66-87.adsl-dyn.isp.belgacom.be
1182631537 Q * mjt Quit: moving to a new server!
1182631674 Q * Piet Remote host closed the connection
1182631853 Q * ktwilight Ping timeout: 480 seconds
1182633071 M * bonbons derjohn: ok, vanilla kernel has 14k remaining percpu space (  __per_cpu_end - __per_cpu_start ~= 17k), so one of the patches is causing .data.percpu (space between __per_cpu_{start,end}) to be larger
1182633120 M * doener bonbons: hm? what breaks?
1182633208 M * bonbons scroll up a few messages for what I found out regarding the percpu thing
1182633259 M * doener hm, no-room for modules... isn't that separate from __per_cpu_{start,end}?
1182633270 M * bonbons it's related
1182633305 M * bonbons if you look at how per_cpu memeory allow at module loading is handled (kernel/module.c)
1182633341 M * bonbons __per_cpu_{start,end} determines how much from PERCPU_ENOUGH_ROOM remains for modules
1182633396 M * bonbons but I don't know yet what that .data.percpu segment in vmlinux is, neither how it's generated/it's size determined
1182633616 J * Aiken ~james@ppp121-45-220-241.lns2.bne1.internode.on.net
1182633884 M * bonbons with patched kernel I have: pcpu_size[0]=-36096, pcpu_size[1]=-3328, with vanilla I have pcpu_size[0]=-17792, pcpu_size[1]=14976
1182634332 M * doener bonbons: that's a buddy allocator, right?
1182634351 M * bonbons buddy allocator?
1182634420 M * doener http://acm.uva.es/p/v8/827.html
1182634642 M * bonbons looks like that -- the values I gave are those at initialization
1182634883 M * doener do you also have the values for __per_cpu_{end,start}?
1182634903 J * Johnnie ~jdlewis@c-67-163-246-136.hsd1.pa.comcast.net
1182634927 M * bonbons no, did not add them to the kprints
1182635115 M * doener bonbons: could you upload the generated assembly for kernel/module.c? (make kernel/module.s)
1182635474 M * bonbons http://homepage.internet.lu/BrunoP/kernel_module.s-2.6.20.12 http://homepage.internet.lu/BrunoP/kernel_module.s-2.6.20.12-vs2.2.0
1182635964 J * derjohn2 ~aj@gprs-pool-1-001.eplus-online.de
1182636372 M * doener bonbons: ah! I looked at current git, and that changed the code there. couldn't figure out how that error could happen at all
1182636452 M * doener bonbons: PERCPU_ENOUGH_ROOM is now: __per_cpu_end - __per_cpu_start + PERCPU_MODULE_RESERVE
1182636502 M * doener opposed to the static 32k it was before
1182636575 M * bonbons oh, that seems quite useful, no need to determine some value beforehand (value that certainly depends a lot from what gets compiled into the kernel)
1182636593 M * bonbons an idea when the change occured?
1182636612 M * doener b00742d399513a4100c24cc2accefdc1bb1e0b15
1182636638 M * doener commit date says May 2, but I have no clue when it was actually merged
1182636670 M * derjohn2 yay, so you did finally find something ? fine !
1182636692 M * doener just that your problem should already be fixed upstream ;-)
1182636750 M * derjohn2 hm? so it was a upstream problem, that was trigger by my verkorkster-sonderling-setup?
1182636766 M * doener more or less...
1182636778 M * derjohn2 whatever, I'll be nice to get rid of it. :)
1182636784 M * doener there was a constant value for the size of the per cpu area.
1182636806 M * doener the vserver patch seems to increase the usage above that limit
1182636810 M * derjohn2 this value differed per $arch ?
1182636859 M * doener x86_64 already had it dynamic, some others at least didn't use the generic macros (didn't check for constant/dynamic or the exact size)
1182636895 M * doener with current git, only ia64 differs
1182636903 M * derjohn2 well, so i either c/o that commit or wait for 2.6.22 and  a vserver pacth for 2.6.22 ?
1182636911 M * bonbons looks like ia64 still has own definition for it: #define PERCPU_ENOUGH_ROOM PERCPU_PAGE_SIZE
1182636926 M * bonbons looking at 2.6.22-rc5
1182636941 M * doener yeah, see 4 lines up ;-)
1182636953 M * bonbons just saw it after hitting ENTER
1182636956 M * derjohn2 so it was really safe simply to raise the enough_room define  to 64k ?
1182636959 M * doener thought so
1182637210 M * doener derjohn2: yep, should be safe. An earlier mainline patch also did that when the alignment for the memory was raised. It never made it into git like that though. (because of that other change I guess)
1182637279 M * derjohn2 will the git patch apply to 2.6.20? or is that unlikely ?
1182637316 M * doener try with --dry-run ;-)
1182637356 M * derjohn2 yep, when i am back home (currenly umts-slowness ...)
1182637357 M * doener but it doesn't look like it would conflict
1182637386 M * derjohn2 can you give me a link, were i can d/l the git patch via web ?
1182637396 M * derjohn2 i never used git, i dont have the client installed.
1182637425 M * derjohn2 or do you only have the shelly one git?
1182637459 M * doener you should be able to feed the commit id to gitweb
1182637494 M * bonbons the id did not show me a useful result on git.kernel.org, linus tree ...
1182637549 M * doener me neither...
1182637551 M * bonbons at least using the search box
1182637574 M * bonbons but string processing in the address bar is more efficient!
1182637591 Q * ensc Ping timeout: 480 seconds
1182637621 M * doener http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b00742d399513a4100c24cc2accefdc1bb1e0b15
1182637677 M * doener and here's the raw patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=b00742d399513a4100c24cc2accefdc1bb1e0b15
1182637705 M * derjohn2 the 1st  one is 64 bit ? [PATCH] x86-64:
1182637716 M * bonbons :)
1182637734 M * derjohn2 ah, ah, both are  :)
1182637735 M * doener it went through the x86_64 list I guess... 
1182637747 M * derjohn2 :-/
1182637748 M * doener they are even the same
1182637797 M * doener the x86_64 prefix isn't always meaningful...
1182637891 M * derjohn2 yep, i spotted that on the 2nd sight .. so both are 64 bit ...:) But the include/linux/percpu.h is general. I think thats where i changed the define to a higher value :) they do it with a addition 32k + 8k .... so 64k was a bit too large but worked ;)
1182637958 M * doener derjohn2: it's not 32k + 8k, it's statically used space + 8k for modules
1182637982 M * derjohn2 ah, no, the 32k define vanished at all and was replaced by per_cpu_end - per_cpu_start ...
1182638035 M * derjohn2 for a kernel lamer like /me , __per_cpu_end (is that a macro ?) is completely voodoo magic ...
1182638101 M * doener __per_cpu_start is basically a pointer to where the per cpu data starts, and __per_cpu_end to where it ends
1182638117 M * doener so the difference of them is the size of the data
1182638207 M * derjohn2 sounds logical. the patches dont look very evil, I think they will apply or are easily mergable ..
1182638262 M * derjohn2 gn8 folks, that's for spotting the problem, I know now what to do. at least i think so. no change in bonbons pacth needed.
1182638292 M * doener sleep well
1182638306 M * derjohn2 bonbons, or add the git patch into your patch if is applied to a pre 2.6.22 ?
1182638333 M * derjohn2 doener, thx, will do so ... !
1182638340 M * derjohn2 gn8!
1182638352 M * bonbons derjohn2: I have not checked individual patches to see which one causes the most static percpu data...
1182638407 M * bonbons the largest consumer should be the one that includes the patch to dynamically set PERCPU_ENOUGH_ROOM
1182638780 N * Bertl_oO Bertl
1182638791 M * doener btw, did I already advertise for VIMperator here? best Firefox extension _ever_ :)
1182638805 M * Bertl back now ...
1182638844 M * doener wb Bertl 
1182638871 Q * derjohn2 Ping timeout: 480 seconds
1182638938 J * markus_ ~chatzilla@chello213047089232.17.14.vie.surfer.at
1182638941 M * markus_ hi :)
1182639020 M * markus_ From time to time (don't know what's the exact reason) I get the following message on the console when entering a started vserver: "mesg: /dev/pts/1: Operation not permitted" Actually I cannot find any negative impact, I'ld just like to understand what this means. I've installed multiple vservers and some have this message upon entering, some not. all are debian based in various intallation....
1182639021 M * markus_ ...Any ideas?
1182639110 M * Bertl well, I guess you bring your pts with you, use an older tool version (probably from debian) which doesn't support vlogin ...
1182639135 M * Bertl which causes some guest side app to choke on the host owned pts :)
1182639254 J * Piet hiddenserv@tor.noreply.org
1182639424 J * markus__ ~chatzilla@chello213047089232.17.14.vie.surfer.at
1182639490 M * markus__ Bert: not at the donauinselfest?
1182639564 M * Bertl markus__: nope, you?
1182639619 M * markus__ No. I don't associate myself with this low profile drunken folk running out there like stupid pigs ;)
1182639632 J * lilalinux__ ~plasma@dslb-084-058-222-084.pools.arcor-ip.net
1182639636 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa
1182639639 M * Bertl but you assume the same from me?
1182639670 M * doener ouch ;)
1182639710 M * Bertl it's alway interesting to hear what folks think :)
1182639773 Q * markus_ Ping timeout: 480 seconds
1182639774 N * markus__ markus_
1182639835 M * markus_ Bertl: hehe :-)
1182639887 M * markus_ Bertl: actually, when I look 10 years back, I didn't cared about what people ran around and I was probably like them. Times changes, personality improves. I hope ;)
1182639926 M * Bertl how old are you if I may ask?
1182639950 M * markus_ 30 -D
1182640005 M * Bertl so already 'untrusted' by the next generation :)
1182640057 A * doener is about to get old... only one week left...
1182640063 Q * lilalinux_ Ping timeout: 480 seconds
1182640092 M * Bertl doener: don't you know? only the good die young :)
1182640123 M * doener hm, so I'm not good? or will I die within the next 7 days? o.O
1182640158 M * Bertl no,no, the really excellent ones become immortal :)
1182640166 M * doener *lol*
1182640181 M * doener won't qualify for that either
1182640228 M * markus_ Bertl: yep. I see this quite well with one of my sisters, she's now getting 19 and ... well, it was interesting the last five years how ethical values change and now she stands there with her boyfriend, 21, .. well, the only thing I could think about the best way to smash him through the wall and out of her life. luckily for respect and rational forbids this.
1182640242 M * Bertl btw, some interesting detail I figured for TFT auto adjustment: use a 2x2 white/gray background if you want correct phase/clock settings :)
1182640288 M * markus_ ops, this gets offtopic :) better see my therapist soon heh
1182640305 M * Bertl lol, so was my deduction correct?
1182640315 M * Bertl (to get back on-topic :)
1182640336 M * markus_ I think it really depends.
1182640348 M * markus_ To get even more offtopic: who knows this classic one http://www.abandonia.com/games/1030/Bioforge/Bioforge.htm ? :)
1182640354 M * Bertl I meant the one about the pts :)
1182640363 M * doener Bertl: hm, adjustment works fine here (even on this non-DVI screen), but that damn thing forgets it's settings all the time
1182640372 M * doener s/it's/its/
1182640393 M * Bertl doener: if you try with a checker screen, you will see _how_much_ it really is off :)
1182640418 Q * bonbons Quit: Leaving
1182640423 M * Bertl I tried this with 4 different monitors, and each one was really off
1182640470 M * Bertl (analog of course, DVI shouldn't have this issue :)
1182640498 M * Bertl well, we would have to shoot the manufacturer if it had :)
1182640607 M * doener Bertl: http://www.gdargaud.net/Hack/DeadPixels.html#LCD -- test images look fine here. And my screen got real good reviews regarding sync back then
1182640719 M * doener the moiree makes me sick if I look at a big area closely though ;-)
1182640785 M * doener anyway, off to bed now... have a good one!
1182640830 M * Bertl nice page! tx! sleep well!
1182640958 Q * HeinMueck Quit: Aah!
1182640979 J * markus__ ~chatzilla@chello213047089232.17.14.vie.surfer.at
1182641179 M * Bertl ah, I feel a lengthier discussion coming up ...
1182641216 Q * markus_ Ping timeout: 480 seconds
1182641217 N * markus__ markus_
1182642422 M * daniel_hozac Bertl: did you see my comment about vrpm?
1182642500 M * daniel_hozac (around 19:30)
1182642550 M * Bertl no?
1182642557 M * daniel_hozac 19:33 < daniel_hozac> Bertl_zZ: no luck getting rpm to do the right thing. it hits the barrier, and entering the context earlier means that's disallowed... if you want to look  at it, the hack script i've been testing with is at http://people.linux-vserver.org/~dhozac/p/uv/experimental/new-vrpm
1182642562 M * daniel_hozac 19:33 < daniel_hozac> i can't really think of any way to work around it without hacking rpm.
1182642591 M * Bertl hmm, that's unfortunate ...
1182642594 M * daniel_hozac indeed.
1182642598 M * Bertl why does it hit the barrier?
1182642610 M * daniel_hozac it needs to chroot to the guest.
1182642632 M * daniel_hozac (and access the database)
1182642644 M * Bertl couldn't we avoid that by bind mounting the guest?
1182642654 M * daniel_hozac to where?
1182642664 M * daniel_hozac like /mnt?
1182642664 M * Bertl somehwere outside the barrier?
1182642702 M * Bertl e.g. /tmp/<guest> could do that?
1182642702 M * daniel_hozac seems rather hacky, especially as the namespace would get inherited by anything the scripts might restart...
1182642726 M * daniel_hozac (so an rpm that restarts httpd would mean httpd runs without the barrier protection...)
1182642741 M * Bertl okay, good point
1182642759 M * daniel_hozac it's too bad rpm doesn't accept . for --root.
1182642765 M * Bertl what about moving the rpms inside?
1182642779 M * daniel_hozac hmm? the rpm binary?
1182642797 M * Bertl whatever is required (inside the barrier)
1182642825 M * Bertl just a thought
1182642832 M * daniel_hozac well... if we start moving things like rpm and the required deps into the guest, we might as well just tell people to install rpm there, no?
1182642865 M * daniel_hozac i.e. to use external package management from the start.
1182642872 M * Bertl actually I would be fine with that, but that leaves the 'bootstraping problem'
1182642896 M * Bertl personally I see the priorities like this:
1182642908 M * Bertl 1) be able to install a guest from a repository
1182642922 M * Bertl 2) be able to manage a guest installed from a repository 
1182642932 M * Bertl 3) be able to manage a guest from the host :)
1182642971 M * daniel_hozac so, maybe the "fix" is to detect the static rpm, and automatically add rpm to the set of rpms to install + use internal package management?
1182642998 M * daniel_hozac (or yum, or apt, or whatever was used to install the guest in the first place)
1182643083 M * Bertl for example, note: I'm perfectly fine when you declare 'static rpm' as unfixably broken (think yum :) and provide a simple patch to add the --root functionality for that
1182643120 M * Bertl but changing a distro from static rpm to dynamic is not something I consider a good idea :)
1182643151 M * Bertl I would volunteer to maintain an rpm for mandriva rpms in this case
1182643159 M * daniel_hozac well, i'd prefer working around it as much as possible... that's what we do for yum, IIRC.
1182643168 M * Bertl yep