--- Log opened wto maj 18 00:00:11 2004
00:08:16< Bertl> okay, good night everyone ...
00:08:23>> Bertl is now known as Bertl_zZ
00:47:14>> Doener` [~doener@pD958824A.dip.t-dialin.net] has joined #vserver
00:54:25>> Doener_ [~doener@pD9E12E1C.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
00:59:39>> rs [~rs@rs.admin.rhapsodyk.net] has quit [Quit: leaving]
02:16:12>> ccooke [~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com] has quit [Ping timeout: 480 seconds]
02:31:12>> click [click@gonnamakeyou.com] has quit [Ping timeout: 480 seconds]
02:33:52>> monrad [~monrad@213.83.190.226] has quit [Quit: Leaving]
02:34:54>> click [click@gonnamakeyou.com] has joined #vserver
02:54:08>> serving [~serving@213.186.191.31] has quit [Read error: Connection reset by peer]
03:02:57>> serving [~serving@213.186.191.31] has joined #vserver
03:04:09>> kestrel [athomas@38.6.233.220.exetel.com.au] has joined #vserver
03:17:04>> ccooke [~ccooke@spc1-walt1-4-0-cust238.lond.broadband.ntl.com] has joined #vserver
05:15:05>> Shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Quit: http://base2091.com]
06:14:35>> h4z4rd [~hazard@pD95336C3.dip.t-dialin.net] has quit [Quit: ( www.nnscript.de :: NoNameScript 3.73 :: www.XLhost.de )]
06:19:12>> dvorak [~dvorak@ny-amherst-C4-1-bg4a-3-4.bflony.adelphia.net] has joined #vserver
06:19:36>> dvorak [~dvorak@ny-amherst-C4-1-bg4a-3-4.bflony.adelphia.net] has left #vserver []
07:52:49>> hiaslboy [matthias@e-16.vc-graz.ac.at] has quit [Ping timeout: 480 seconds]
08:10:30>> Bertl_zZ is now known as Bertl_oO
08:42:34>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has joined #vserver
08:42:38>> mhepp [~mhepp@r72s22p13.home.nbox.cz] has quit [Quit: ]
08:48:04>> kestrel [athomas@38.6.233.220.exetel.com.au] has quit [Quit: screen sucks]
08:55:17>> kestrel [athomas@38.6.233.220.exetel.com.au] has joined #vserver
09:17:01>> billpasquet [~billpasqu@pasquet.mtice.net] has joined #vserver
--- Log closed wto maj 18 09:32:50 2004
--- Log opened wto maj 18 09:32:59 2004
09:32:59>> albeiro_ [albeiro@linux.gentoo.pl] has joined #vserver
09:32:59>> Irssi: #vserver: Total of 31 nicks [0 ops, 0 halfops, 0 voices, 31 normal]
09:35:46>> albeiro [albeiro@linux.gentoo.pl] has quit [Read error: Connection reset by peer]
09:35:53>> Keepnick: Nickstealer left [OFTC], got albeiro back
09:36:18>> Irssi: Join to #vserver was synced in 200 secs
10:01:20>> rs [rs@ice.aspic.com] has joined #vserver
10:01:24< rs> hi
10:01:39>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has quit [Ping timeout: 480 seconds]
10:06:27>> billpasquet [~billpasqu@pasquet.mtice.net] has quit [Quit: Leaving]
10:07:16>> Bertl_oO is now known as Bertl
10:07:27< Bertl> morning everyone!
10:09:02< eyck> morning
10:10:32< _id> moin
10:11:53>> hiaslboy [matthias@e-16.vc-graz.ac.at] has joined #vserver
10:13:38< Bertl> morning hiaslboy!
10:14:04< rs> morning Bertl 
10:15:14>> Khahan [~Filbert@D5E0628B.kabel.telenet.be] has quit [Ping timeout: 480 seconds]
10:15:22< Bertl> rs: ready for a new 1.9 release?
10:16:27< rs> yep always :)
10:16:32< rs> what news ?
10:16:51< Bertl> internal structural changes improving scalability ...
10:16:59< Bertl> (mostly)
10:17:13< rs> ok
10:17:20< rs> no new hidden features ? :)
10:17:35< Bertl> well, sure, but would they be hidden if I told you?
10:17:46< rs> ;)
10:31:15< Bertl> http://vserver.13thfloor.at/Experimental/patch-2.6.6-vs1.9.0.6.diff
10:37:59< rs> 6 !
10:38:09< rs> I missed 5 releases ! :)
10:38:15< Bertl> yep, you did ;)
10:38:47< rs> OMG !! :)
10:50:01>> hiaslboy [matthias@e-16.vc-graz.ac.at] has quit [Quit: using sirc version 2.211+KSIRC/1.3.10]
11:04:11>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has joined #vserver
11:04:54< Bertl> morning dsanta!
11:28:04< rs> I got some strage pb since I use the 2.6.6-vs1.9.0
11:28:36< Bertl> please define 'strage pb' ...
11:28:46< rs> some time the network interface my vservers use can no longer be used
11:28:57< rs> # ifconfig eth1 1.2.3.4
11:28:57< rs> SIOCSIFADDR: Cannot assign requested address
11:28:57< rs> SIOCSIFFLAGS: Cannot assign requested address
11:29:21< rs> the interface goes down and all addressed bound are no longer available
11:29:28< rs> I can't figure out why
11:29:42< Bertl> probably the 'old' primary/secondary issue?
11:31:23< rs> I don't think so, all my iface have a 32 prefix
11:31:32< rs> so they are all secondary
11:32:22< Bertl> hmm, well, do you have such an example case available? (probably not)
11:32:47< rs> bvdsn02:/etc/vservers# ip l set eth1 up
11:32:47< rs> bvdsn02:/etc/vservers# ip l show eth1
11:32:47< rs> Device "eth1" does not exist.
11:33:06< rs> not really
11:33:23< rs> this time it happened when a started a new vserver
11:34:15< Bertl> but eth1 exists, and the module is loaded, right?
11:34:35< rs> yes it exists and the code is in the kernel (not as module)
11:34:52< Bertl> okay, how do you verify that eth1 exists?
11:35:31< rs> hmm I know it :)
11:35:37< rs> it was existe minutes ago
11:35:54< rs> # dmesg |grep eth1
11:35:54< rs> eth1: Intel(R) PRO/1000 Network Connection
11:35:54< rs> e1000: eth1 NIC Link is Up 100 Mbps Full Duplex
11:35:54< rs> e1000: eth1 NIC Link is Up 100 Mbps Full Duplex
11:36:12< rs> # ip l show eth1
11:36:12< rs> Device "eth1" does not exist.
11:36:22< Bertl> is this now happening?
11:36:27< rs> yep
11:36:37< Bertl> so we can investigate on this issue, right?
11:36:46< rs> if I reboot the machine eth1 will be available
11:36:51< Bertl> no, don't do it ...
11:36:55< rs> yep
11:37:01< rs> ok I don't do it
11:37:02< Bertl> what does ifconfig give?
11:37:12< rs> eth0 and lo
11:37:16< rs> but not eth1
11:37:18< Bertl> so no eth1 either ...
11:37:36< Bertl> ifconfig -a
11:37:54< rs> i get eth1
11:38:02< Bertl> so it's configured down ...
11:38:02< rs> eth1      Link encap:Ethernet  HWaddr 00:06:5B:3A:DF:19
11:38:02< rs>           BROADCAST MULTICAST  MTU:1500  Metric:1
11:38:02< rs>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
11:38:02< rs>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
11:38:02< rs>           collisions:0 txqueuelen:1000
11:38:05< rs>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
11:38:18< rs> oups
11:38:19< Bertl> zero transfer, no stats ...
11:38:23< rs> sorry
11:38:30< rs> was the wrong tab :)
11:38:36< rs> so no eth1 
11:38:45< rs> sorry :)
11:38:50< Bertl> ifconfig -a -> no eth1?
11:38:56< rs> yep 
11:39:00< rs> still no eth1
11:39:20< rs> but:
11:39:21< rs> bvdsn02:/etc/vservers# ifconfig eth1
11:39:21< rs> eth1      Link encap:Ethernet  HWaddr 00:06:5B:8D:DC:BE
11:39:21< rs>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
11:39:21< rs>           Base address:0xdcc0 Memory:feb20000-feb40000
11:39:44< Bertl> hmm, nothing more?
11:40:03< rs> nothing
11:40:19< Bertl> hmm, looks like a driver issue to me ... no interrupt?
11:40:35< Bertl> what does lspci show?
11:40:49< rs> 0000:01:02.0 Ethernet controller: Intel Corp. 82544EI Gigabit Ethernet Controller (Copper) (rev 02)
11:40:52< rs> 0000:01:04.0 Ethernet controller: Intel Corp. 82544EI Gigabit Ethernet Controller (Copper) (rev 02)
11:41:59< Bertl> okay, any recent additions to dmesg?
11:42:02< rs> I get a stranger pb with eth1 on another node
11:42:30< rs> the ifconfig command goes to uninteruptible state
11:42:43< Bertl> that is definitely a driver issue then ...
11:43:28< rs> ok
11:43:30< rs> gni
11:43:47< Bertl> which driver version is the GB?
11:44:16< mcp> moin
11:44:33< Bertl> morning mcp!
11:44:35< rs> I'm rebooting them so please wait a minute, I will tell you
11:47:06< Bertl> okay, lunch time ... bbl
11:47:13>> Bertl is now known as Bertl_oO
11:47:32< mcp> Bertl_oO: bon appetit
11:53:08>> hiaslboy [matthias@e-16.vc-graz.ac.at] has joined #vserver
12:07:26>> Khahan [~Filbert@D5E0628B.kabel.telenet.be] has joined #vserver
12:35:25>> serving [~serving@213.186.191.31] has quit [Read error: Connection reset by peer]
13:16:27>> Bertl_oO is now known as Bertl
13:16:38< Bertl> okay, I'm back ...
13:43:09< rs> re
13:43:23< rs> Bertl: BTW I got an oops with my iface pb :)
13:43:29< rs> I will investigate on that
13:43:42< Bertl> interesting, is it available somewhere?
13:45:07< rs> wait a moment
13:45:28< rs> http://rs.rhapsodyk.net/vserver/oops.txt
13:46:21< rs> I'm building a vmlinux to get symbols
13:46:51< Bertl> hmm, this is vserver related, but you are not within a chbind context when you do that, or?
13:47:12< rs> it's while I start a vserver
13:47:36< rs> the eth0 interface use the same driver and don't got the same pb
13:47:48< rs> so I can't tell you if or not it's a vserver pb
13:47:54< Bertl> this issue (oops) isn't driver related ...
13:48:18< Bertl> it is a vserver issue, ... I'll investigate ...
13:48:43< Bertl> btw, could you try if it happens with the 1.9.0.6 release on that box?
13:49:01< Bertl> (or is that the 1.9.0.6?)
13:49:01< rs> yes I try that 
13:49:30< rs> no it was the 1.9.0
13:49:52< Bertl> you have preemtion enabled?
13:50:03< rs> no
14:02:33< rs> got the same oops with 1.9.0.6
14:02:51>> Brucey [cinacio@snape.aspic.com] has joined #vserver
14:02:54< Brucey> hi all
14:03:10< Bertl> hi Brucey!
14:03:14< Bertl> rs: interesting ...
14:03:19< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel: nxd: loc_nx_info(-1)
14:03:19< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel:  nxd: create_nx_info()
14:03:19< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel: nxd: alloc_nx_info()
14:03:19< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel: nxd: alloc_nx_info() = f767bcd4
14:03:19< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel: nxd: loc_nx_info(49157) = f767bcd4 (new)
14:03:22< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel: nxd: __hash_nx_info: f767bcd4[#49157]
14:03:25< rs> Apr 19 13:56:26 bvdsn01.dev.lyceu.net kernel: ------------[ cut here ]------------
14:03:28< rs> Apr 19 13:56:27 bvdsn01.dev.lyceu.net kernel: kernel BUG at include/linux/ninline.h:60!
14:03:31< rs> is it you traces ? :)
14:03:34< rs> you BUG trace :)
14:03:50< Bertl> sounds good ... can you upload this somewhere ...
14:03:53< rs> refresh my oops page
14:04:03< rs> I got 2 oops
14:04:32< rs> one per cpu :)
14:06:38< Bertl> okay, could you run them through ksymoops please?
14:07:53< rs> ok
14:10:08< rs> http://rs.rhapsodyk.net/vserver/ksymoops.txt
14:10:53< Bertl> hum, sure that this is the right data for the oops (kernel/System.map)?
14:11:23< rs> maybe not
14:11:36< rs> I ran ksymoops -v vmlinux -m System.map oops.txt
14:11:48< rs> at the root of the kernel directory
14:12:29< Bertl> try ksymoops -v vmlinux -m System.map -K 
14:12:36< Bertl> and use only one oops at a time ...
14:13:04< rs> better :)
14:13:11< rs> yep sure
14:13:36< rs> reload
14:14:02< Bertl> hmm, nothing changed :(
14:14:36< rs> retry ?
14:14:59< Bertl> http://rs.rhapsodyk.net/vserver/ksymoops.txt right?
14:15:04< rs> yep
14:15:22< Bertl> ah okay ...
14:17:41< Bertl> looks like they 'improved' something, as neither I nor ksymoops can figure the correct addresses ;)
14:19:05< Bertl> could you copy a little more around the two oops? some of the 'other' nxd debug messages?
14:20:14< rs> http://rs.rhapsodyk.net/vserver/klog.txt
14:22:11< Bertl> okay, now we need one of those hidden features ... ;)
14:22:19< Bertl> you can reproduce the oops?
14:22:19< rs> haha :)
14:22:28< rs> I think so, let me try
14:23:42< rs> I need to reboot the box to reproduce it
14:23:55< Bertl> okay, stay with 1.9.0.6 ...
14:24:23< Bertl> and before you 'trigger' it, let me know ...
14:29:31< rs> ok
14:29:41< rs> I am on
14:29:43< Bertl> now the magic:
14:29:45< Bertl> echo 1 >/proc/sys/vserver/debug_switch
14:30:03< rs> =)
14:31:25>> serving [~serving@213.186.191.31] has joined #vserver
14:31:39< Bertl> hello serving!
14:31:39< rs> ok so got the oops
14:31:57< rs> I got this before the oops :
14:31:59< rs> Apr 19 14:25:31 bvdsn01.dev.lyceu.net kernel: vc: VCMD_00_0[0], 63
14:31:59< rs> Apr 19 14:25:31 bvdsn01.dev.lyceu.net last message repeated 3 times
14:31:59< rs> Apr 19 14:25:31 bvdsn01.dev.lyceu.net kernel: vc: VCMD_46_1[0], 0
14:31:59< rs> Apr 19 14:25:31 bvdsn01.dev.lyceu.net kernel: vc: VCMD_00_0[0], 63
14:32:02< rs> Apr 19 14:25:33 bvdsn01.dev.lyceu.net kernel: vc: VCMD_00_0[0], 63
14:32:06< Bertl> good, again add some log messages from the vicinity ..
14:32:17< Bertl> and upload it somewhere ...
14:33:21< rs> http://rs.rhapsodyk.net/vserver/klog2.txt
14:34:32< Bertl> okay, now please try to describe me what you do to trigger this ...
14:35:15< rs> it's really simple:
14:35:16< rs> # vserver 213.193.14.135 start
14:35:16< rs> Cannot find device "eth1"
14:35:16< rs> /usr/sbin/vserver: line 81:   354 Segmentation fault      $_IP link set "$@"
14:35:16< rs> /usr/sbin/vserver: line 83:   356 Segmentation fault      "$@" $_SECURE_MOUNT -a --chroot "$vdir" --fstab "$fstab"
14:36:00< Bertl> hmm, the vserver is named 213.193.14.135 ?
14:36:07< rs> yep
14:36:18< rs> I name vservers by their IP
14:36:42< Bertl> so how is the alias usually called then?
14:36:58< rs> I don't use alises
14:37:35< rs> it's useless
14:38:21< rs> for me at least
14:38:38< Bertl> hum, okay ...
14:38:57< eyck> how do you name a vserver with multiple IPs?
14:39:10< eyck> how do you name a vserver without IPs at all?
14:39:40< rs> eyck: with its primary IP
14:39:54< rs> and we can't have vservers without IPs :)
14:40:05< eyck> and when there's more then one vserver with the same primary IP?
14:40:23< rs> eyck: it's not possible
14:40:29< rs> (in our product)
14:41:03< eyck> ok.
14:41:19< rs> the ip as name fit well for us
14:41:30< rs> I didn't find a better way to name it
14:41:41>> ensc [~ircensc@ultra.csn.tu-chemnitz.de] has joined #vserver
14:41:46< ensc> hi
14:41:58< rs> hello enrico !
14:42:10< Bertl> hmm, are you the famous enrico, everybody is speaking of? ;)
14:42:18< ensc> ???
14:42:36< ensc> weblog seems to be down :(
14:43:10< Bertl> weblog means? irc log?
14:43:21< ensc> yep
14:43:33< Bertl> haven't checked for a while ...
14:47:06< Bertl> ensc: any idea about vc: VCMD_63_2[3], 1 (basically VCMD_set_ipv4root(1)) ?
14:48:16< Bertl> (and how we can get rid of that ;)
14:49:55< ensc> Bertl: I still do not understand the purpose of the prefix in the vserver syscalls
14:52:24< Bertl> http://www.13thfloor.at/vserver/d_rel26/v1.9.0/split-2.6.6-vs1.9.0/07_2.6.6_net.diff.asc
14:52:58< Bertl> check/grep for mask ...
14:55:59< _id> re
14:56:09< Bertl> wb _id!
14:59:07< _id> is the debug switch in /proc/sys/vservers only available in the 1.9.0 branch ?
14:59:22< Bertl> yep
14:59:36< _id> ok
15:04:29< Bertl> rs: try http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.0.6-vs1.9.0.7.diff
15:04:37< rs> ok
15:05:57< Bertl> ensc: is there a situation where the tools do a VCMD_set_ipv4root() when already 'inside' a chbind?
15:06:22< rs> patching file fs/ext2/ioctl.c
15:06:22< rs> Reversed (or previously applied) patch detected!  Assume -R? [n]
15:06:25< rs> is it normal ?
15:06:33< ensc> Bertl: no
15:06:48< ensc> at least, I can not remember it
15:06:50< Bertl> rs: apply it with -f
15:07:19< rs> k
15:13:13< ensc> Bertl: afais, the prefix is used to determine the outgoing ip/interface. But this information is available through common routingtables already
15:14:07< ensc> so in creating an interface with 'ip addr add ip/prefix' and creating a network context with 'chbind --ip ip/prefix' the 'prefix' would be redundantly in one of this invocations
15:20:36< Bertl> yeah, I'd like to change the iproot description in the following way:
15:21:11< Bertl> ideally the iproot info should describe the ip space 'allowed' for a network context ...
15:21:34>> cereal [~cereal@pD9EABD0E.dip.t-dialin.net] has joined #vserver
15:21:36< cereal> hi
15:21:58< Bertl> we might (some time in the future) model that with some kind of tree, describing the allowed address space ...
15:22:01< Bertl> hi cereal 
15:22:40< Bertl> ensc: but for now, we will limit this to something based on enlisting addresses or maybe networks ...
15:23:01< cereal> i want to register the nick cereal for me, but anyone else has it done before :-/
15:23:47< Bertl> tough luck ... maybe 'biscuit' is free ;)
15:24:12< ensc> Bertl: in the end, you will have something like iptables... I do not know if this is worth the effort
15:24:15< cereal> hmmmm i have set up kernel 2.4.26-vs1.27-ow1-q0.14-bme0.04 with 0.29-3 but vreboot will not work
15:24:55< cereal> no error messages
15:25:00< Bertl> ensc: if we want to allow at some point to change/setup an interface, we need some description of the allowed ranges, right?
15:25:37< ensc> Bertl: ack, iff s!ranges!ips!
15:25:56< cereal> the problem is connect /dev/reboot (Connection refused) when anyone use veboot
15:26:49< ensc> 'ranges' are difficultly to implement. Especially, when you want to add operations like intersections or joins
15:27:24< Bertl> not really if the ranges are masks ...
15:28:10< Bertl> cereal: did you setup the rebootmgr properly?
15:29:06< cereal> yes
15:29:32< cereal> the rebootmgr will setup automatically on debian with atp-get vserver
15:29:41< cereal> 331 ? S 0:00 /usr/sbin/rebootmgr --pidfile /var/run/rebootmgr.pid
15:29:58< cereal> he is already running
15:30:03< Bertl> ah, you are with debian, why didn't you say so first? sorry pal, you are doomed ... ;)
15:30:34< cereal> :p
15:31:10< Bertl> no, check, IIRC the rebootmgr must be started for each vserver
15:31:42< Bertl> ensc: could you confirm/explain/deny?
15:33:15< cereal> and how can i set up rebootmgr for each vserver?
15:33:42>> Bertl is now known as Bertl_oO
15:34:37< cereal> the mailingslist is broken :-/
15:34:38< cereal> Bug in Mailman version 2.1.4
15:34:38< cereal> We're sorry, we hit a bug!
15:35:12< cereal> If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks!
15:35:24< cereal> does anyone know the mail adress from Bertl?
15:35:25< cereal> *g*
15:37:25< ensc> Bertl: why not let the userspace implement 'ranges' and use only single IPs in the kernel-interface?
15:38:34< rs> Bertl_oO: you new patch seems to prevent the machin to start
15:39:11< ensc> Bertl: when having IP-ranges in the kernel, we will have to introduce something like tables
15:39:23< rs> http://rs.rhapsodyk.net/vserver/klog3.txt
15:41:52>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has quit [Quit: leaving]
15:42:06>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has joined #vserver
15:51:27>> cereal is now known as Sebastian
16:04:50>> Bertl_oO is now known as Bertl
16:05:01< Bertl> sorry had to leave ...
16:05:24< Bertl> rs: hmm, it prevents startup? you mean it gives an oops on boot?
16:05:31< rs> yep
16:05:43< Bertl> the klog3 is it?
16:05:44< rs> shown in the klog3.txt
16:06:30< Sebastian> oh bertl is back
16:06:36< Sebastian> bertl the mailinglist is borken
16:06:42< Sebastian> oehm broken ;)
16:07:02< Bertl> hmm, in what way? it doesn't work at all?
16:07:27< Sebastian> -15:32:25- [cereal]: Bug in Mailman version 2.1.4
16:07:27< Sebastian> -15:32:25- [cereal]: We're sorry, we hit a bug!
16:07:28< Sebastian> -15:32:59- [cereal]: If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks!
16:09:20< Bertl> Sebastian: hmm, when does this happen?
16:10:02< Sebastian> when i want to Subscribe to the mailing list
16:10:47< Bertl> okay, please send a detailed description what you do, and what fails to: Martin List-Petersen <martin@list-petersen.se>
16:10:59< Sebastian> ok
16:12:12< Bertl> rs: hmm, looks like your kernel is not complete ...
16:12:29< rs> ??
16:13:22< Bertl> kernel BUG at kernel/vserver/network.c:226!
16:13:36< Bertl> at this line my code shows space between two functions and a comment ;)
16:13:40< rs> what do you mean by "not complete" ?
16:14:11< Bertl> I uploaded a complete patch to 2.6.6 ...
16:14:38< rs> ok because for me it's in the rcu_free_nx_info function
16:14:58< Bertl> http://vserver.13thfloor.at/Experimental/patch-2.6.6-vs1.9.0.7.1.diff
16:18:19< UFOczek>  hi Bertl!
16:18:42< rs> since the 1.9.0 you patch change the extraversion
16:18:48< rs> is it expected ?
16:18:56< Bertl> hi UFOczek, still waiting for wolk?
16:19:00< Bertl> rs: yep ...
16:19:10< UFOczek> Bertl: not anymore. i'm downloading 2.6.6 grs + vs
16:19:13< rs> ok
16:22:11< UFOczek> huh, there is no grs for 2.6.6 =)
16:22:18< Bertl> hehe ;)
16:27:53>> noel [~noel@pD9FFFF99.dip.t-dialin.net] has joined #vserver
16:28:01< Bertl> evening noel!
16:28:13< noel> 16.30 evening?;)
16:28:26< noel> hello Bertl and all others.
16:28:31< Bertl> good night noel!
16:28:39< albeiro> e
16:28:47< noel> good night.;)
16:29:12< UFOczek> Bertl: what was the url for your patch (2.6.5-wolk + yours vs)
16:29:37< UFOczek> i dont see it at the web..
16:30:53< albeiro> yeah, god question
16:30:55< albeiro> good
16:30:59< Bertl> http://vserver.13thfloor.at/Experimental/Obsolete/patch-2.6.4-wolk2.4-rc1-vs1.9.0pre9.diff
16:31:09< albeiro> Obsolete :P
16:31:17< UFOczek> ah, in Obsolete.
16:31:34< UFOczek> and 2.6.4 wrr.
16:31:40< albeiro> hm, it is, we have 2.6.5-rc3 wolk now
16:32:04< Bertl> yeah, but still no 2.6.6 wolk, and mcp told me to wait for it ;)
16:32:30< UFOczek> yeah, wait few months :))
16:32:41>> Sebastian is now known as Sebastian_away
16:33:24< UFOczek> albeiro: current wolk is 2.6.5-wolk3.0-rc2 
16:36:31< rs> got a panic this time :)
16:36:43< Bertl> hmm, interesting ... let's see ...
16:36:50< rs> klog4.txt
16:37:51< rs> same bug line
16:39:03< Bertl> hmm .. basically means that a network context is freed once too often ...
16:39:40< Bertl> the interesting part is, it doesn't happen here for me :(
16:40:20< rs> strange, maybe SMP related ?
16:40:41< Bertl> might be, but I don't see how ... atm
16:40:42< mcp> Bertl: all the bugs in wolk never happened for me too but the bugs were there ;p
16:41:28< UFOczek> got to work
16:41:31< UFOczek> |# find . -iname "*.rej" |wc -l
16:41:31< UFOczek> |     37
16:42:33< albeiro> hmm, will there be vserver for current wolk ?
16:42:43< UFOczek> no ? :)
16:42:52>> SHu_here [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver
16:43:05< mcp> albeiro: for the 89453^3980443th time: there will be a vserver patch for the next wolk based on .6 or .7. nothing before.
16:43:25< albeiro> ok
16:43:38< Bertl> evening Shuri!
16:43:41< UFOczek> mcp: r u counting that ?
16:44:06< UFOczek> ;-)
16:44:40< mcp> UFOczek: I do.
16:44:47< mcp> ;)
16:45:06< UFOczek> wow ! ;-)
16:48:03< SHu_here> hello all
17:03:17>> ApoIIo [~Apollo@caracal.norcomcable.ca] has joined #vserver
17:03:31< Bertl> hi ApoIIo!
17:03:37< ApoIIo> hi Bertl
17:04:24< rs> Bertl: can I do something to help you finding the pb ?
17:04:43< Bertl> I probably already fixed it, patch will be ready in a few minutes
17:05:00< rs> cool :)
17:05:07< ApoIIo> could I encouter problems if I run localhost ip on each vserver?
17:06:35< Bertl> depends on if you consider reduced security a problem?
17:07:54< ApoIIo> well, yes that is always a concern.  What kind of security issues would arise?  Does this create a door to the host?
17:08:41< Bertl> rs: http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.0.7-vs1.9.0.8.diff
17:09:51< rs> ok
17:25:09< rs> another kernel panic
17:25:20< Bertl> hmm, okay, where?
17:25:21< rs> seems to be the same
17:25:46< rs> klog5.txt
17:26:06< rs> exactly the same trace
17:26:45< rs> oups reload
17:28:25< Bertl> ensc: still here?
17:28:32< ensc> yep
17:28:38< Bertl> http://rs.rhapsodyk.net/vserver/klog5.txt
17:28:47< Bertl> nxd: nx_migrate_task(f7cc4660,f7d199d4[#49153.2)
17:28:52< Bertl> nxd: nx_migrate_task(f7cc4660,f7700e54[#49154.2)
17:28:59< rs> yep ?
17:29:00< Bertl> the first pointer is the task
17:29:09< Bertl> the second one is the network context
17:29:30< Bertl> looks to me like syslogd? somehow is walking nx contexts ...
17:29:50< Bertl> any idea how this could happen?
17:30:06< rs> I start syslogd with chcontext
17:30:07< Bertl> rs: I assume you are using the v_sshd wrapper?
17:30:10< rs> chbind sorry
17:30:25< rs> a rewritten version yes
17:32:23< Bertl> okay, could you change a line, do a quick compile and panic again?
17:32:31< rs> yep
17:32:55< Bertl> kernel/vserver/network.c : ~344
17:33:05< Bertl> should look like this:
17:33:11< Bertl> (after your change ;)
17:33:20< Bertl>         nxdprintk("nx_migrate_task(%p,%p[#%d.%d.%d])\n", p, nxi,
17:33:20< Bertl>                 nxi->nx_id, 
17:33:20< Bertl>                 atomic_read(&nxi->nx_usecnt), 
17:33:20< Bertl>                 atomic_read(&nxi->nx_refcnt));
17:35:22< Bertl> hmm, and in include/linux/ninline.h
17:35:36< Bertl> uncomment the #define NX_DEBUG
17:35:56< rs> k
17:35:56< Bertl> that's it ... I hope ...
17:39:52< Bertl> ensc: okay, so we start by specifying IP by IP for a 'list' of allowed addresses, oaky?
17:40:09< Bertl> (no prefix or mask required for that)
17:40:13< ensc> Bertl: ok
17:41:04< Bertl> but, we also add a special 'ip' which is the 'designated' source IP, if specified as 0, then we do normal source ip resolution, right?
17:42:40< ensc> I do not like such special cases...
17:43:00< Bertl> then how would you suggest to configure this instead?
17:43:03< ensc> is the source ip resolution solved by an implicit bind()?
17:43:20< ensc> or is it calculated for each package (UDP)?
17:43:49< Bertl> it's done via the routing tables atm ... but they are 'limited' to the 'allowed' ranges ...
17:44:23< ensc> source ip is the first configured ip, whihc can be a source-ip based on routing decisions
17:45:01< Bertl> sounds good, but this way you have zero chance to allow to gateways in one vserver ;)
17:45:59< Bertl> (unless you allow 0.0.0.0 as first ip, and handle it magically special, which I do not like either)
17:46:10< ensc> gateways? do you mean ip-forwarding?
17:46:41< Bertl> think eth0:10.0 eth1:10.1 vps1: 10.0.0.2, 10.1.0.2 with separate gw
17:47:04< rs> what are you trying to do ?
17:47:30< Bertl> cleanup the networking mess ;)
17:48:24< rs> good luck :P
17:49:17< Bertl> thanks 8-)
17:49:18< ensc> Bertl: then: if no such IP exists, take the first one
17:50:04< Bertl> no, I don't like this, I'd prefer a special IP either a separate field or a special 'marked' ip which is the 'preferred' source ip
17:50:19< ensc> or 'fallback' source ip?
17:50:32< Bertl> I have no problem with a separate syscall command ... which 'overrides' the default '0.0.0.0'
17:51:12< Bertl> fallback implies that the server has to do the full search .. I'd like to avoid this ...
17:53:01< ensc> how much routing tables can I define? 256? 2^16? |nid|?
17:53:16< Bertl> 255-4 IIRC
17:53:48< ensc> bad...
17:56:34< ensc> I do not know anything about routing in the kernel and can not estimate the overhead for a 'fallback' solution
17:56:52< ensc> but I do not like your 'special' ips
17:57:14< ensc> what would be with 'special' ips per interface
17:57:15< ensc> ?
17:57:36< Bertl> isn't interface related at all ...
17:57:44< Bertl> replace eth1 from the example above with eth0
17:57:51< ensc> doesn't routing tell you the outgoing interface?
17:58:39< ensc> mmh... would probably give problems with source based routing
18:00:11< Bertl> http://www.13thfloor.at/vserver/d_rel26/v1.9.0/split-2.6.6-vs1.9.0/07_2.6.6_net.diff.asc
18:00:19< Bertl> ip_find_src
18:02:04< Bertl> I'd really like to avoid this, especially for larger address tables ... and especially for udp_sendmsg ;)
18:03:02< Bertl> rs: no oops yet? (take your time ;)
18:03:17< rs> have to fix something before
18:08:11< rs> klog6.txt
18:08:53< Bertl> hmm, you didn't enable the NX_DEBUG, right?
18:09:03< rs> i did
18:09:25< Bertl> hmm, but there are no messages in the log ...
18:09:36< rs> grep DEBUG include/linux/ninline.h
18:09:37< rs> #define NX_DEBUG
18:09:37< rs> #if defined(NX_DEBUG)
18:09:59< rs> oups seems to be the wrong kernel
18:27:39< rs> klog7.txt
18:35:07< _id> fuck - the eu voted for software patents
18:35:18< _id> we are doomed !!!
18:35:33< rs> :/
18:36:27< _id> even germany voted yes ! and they said before - blah blah we support Open Source Software - blah !
18:36:37< _id> only Spain voted no
18:49:02>> infowolfe [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has joined #vserver
18:49:09< Bertl> evening infowolfe!
18:49:19< infowolfe> good afternoon Bertl
18:51:33< Bertl> rs: please use http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.0.8-vs1.9.0.9.diff
18:51:46< Bertl> it doesn't fix the issue, but hopefully will shed some light on it ...
18:59:46< rs> ok
19:08:06>> ApoIIo [~Apollo@caracal.norcomcable.ca] has left #vserver []
19:09:12< Bertl> rs: still compiling?
19:10:10< Bertl> (because if yes, I have an additional aptch ;)
19:11:56< rs> arf
19:12:01< Bertl> http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.0.9-vs1.9.0.10.diff
19:12:03< rs> just finished
19:12:11< Bertl> with compiling?
19:12:23< Bertl> or with debugging?
19:12:34< rs> compiling
19:12:38>> infowolfe [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has quit [Quit: Leaving]
19:12:41< Bertl> okay, then add the patch
19:12:42>> infowolfe [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has joined #vserver
19:12:47< Bertl> and do just a make ...
19:12:58< Bertl> should be finished in a few seconds ...
19:13:26< rs> I have to package it so I have to redo the whole compilation each time
19:13:37< Bertl> that's bad ...
19:13:47< rs> maybe a should proceed differently for debugging
19:13:53< Bertl> okay, here is the complete patch to 2.6.6
19:14:01< Bertl> http://vserver.13thfloor.at/Experimental/patch-2.6.6-vs1.9.0.10.diff
19:14:10< Bertl> and I guess it should fix the issue ...
19:14:16< Bertl> but I have to leave now ...
19:14:29< rs> ok I send you a mail to tell you if it's working
19:14:39< Bertl> thanks for testing this stuff, if it works you can comment out the debugging again ...
19:14:52< Bertl> (and use it for testing ;)
19:15:07< Bertl> have a nice one, cya all later ...
19:15:14>> Bertl is now known as Bertl_oO
19:20:45< Brucey> going home... later all
19:20:51>> Brucey [cinacio@snape.aspic.com] has quit [Quit: "War doesn't determine who's right, war determines who's left."]
19:22:53>> Sebastian_away is now known as Sebastian
19:23:59>> hvd [~Miranda@62.99.252.14] has joined #vserver
19:24:33< Sebastian> re
19:25:12< hvd> anyone played around with natted ipvs, policy based routing and vserver ? 
19:33:54< hvd> setup is the following: ipvs box (loadbalancer), two master servers (master-1, master-2) both running a vserver  with openldap server (vserver-1, vserver-2) .. 
19:34:07< albeiro> hvd: not this channel
19:34:13< hvd> ok .. 
19:34:43< albeiro> we are www.linux-vserver.org
19:34:44< albeiro> :)
19:34:53< hvd> i know .. 
19:35:08< albeiro> ah, ok, sorry, i thought it is yb mistake ;)
19:35:10< albeiro> by
19:36:44>> _id [~id@pD9E612AC.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
19:37:24< hvd> albeiro: s/openldap/anytcpserviceyouwant/ ;-)
19:37:52< albeiro> nice conf, does it work ?
19:38:17< hvd> if srcip =! vserver.* 
19:38:20< hvd> yes ..
19:38:26< Medivh> hi
19:38:37< Medivh> any of you guys experienced with ipv6/bgp? ;)
19:39:03< hvd> if srcip == vserver.* we have a problem .. even with policy routing the packet gets send via lo .. therefor not passing through the loadbalancer ... 
19:39:33< hvd> or i was unable to setup policy routing to force the packet to be forwarded via loadbalancer .. 
19:42:21< hvd> so my questsion was if there is a way to do this at tcp_minisocks.c in the kernel ..
19:42:54< hvd> or if someone would have an idea on hwo todo that ;-) ..
19:45:04< hvd> (maybe this is a featurerequest) *wink* ;-)
19:46:50>> _id [~id@217.230.18.2] has joined #vserver
20:14:19>> flock [~restless@l192-115-29-147.broadband.actcom.net.il] has joined #vserver
20:16:04< flock> hey guys, did anyone here try vserver on ia64, and if so, how did it go?
20:27:00>> hvd [~Miranda@62.99.252.14] has left #vserver []
20:27:08>> hvd [~Miranda@62.99.252.14] has joined #vserver
20:27:38< hvd> afai vserver works on sparc64/sparc/ia32 .. 
20:27:52< hvd> at least these are the plattforms where patches exists ;-) ..
20:28:05< flock> no ia64 patches?
20:28:20< hvd> oups .. im sorry .. there are patches foer x86_64 ..
20:31:13>> rs [rs@ice.aspic.com] has quit [Quit: home]
20:31:17< hvd> as far as i could see in sys_x86_64.c the domainname and nodename are set .. 
20:32:38 * flock nods
20:32:47< flock> ok, i will report how did it go tomorrow;P
20:33:16< hvd> pls report to maillinglist .. 
20:36:06< flock> ok
20:36:58>> v00dY [v00dy@62.241.52.129] has quit [Ping timeout: 480 seconds]
20:40:04>> v00dY [v00dy@62.241.52.129] has joined #vserver
20:43:47>> v00dY is now known as v00dY|
21:14:17< _id> is it normal that i can monitor network (eth0) traffic from my host inside a vserver ?
21:15:35>> dsanta_ [~santa@c68.190.156.105.roc.mn.charter.com] has joined #vserver
21:15:35>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has quit [Read error: Connection reset by peer]
21:16:16< _id> the vserver is online with a eth0:alias with a different IP other than the host
21:44:51< dionv_zZ> quit
21:44:57>> dionv_zZ [~dionv@masq-van7ant.skynet.ca] has quit [Quit: leaving]
21:48:28< Doener`> _id: if that vserver has CAP_NET_RAW, yes
21:49:28< _id> i see - i used it for ping tests
21:49:31< Doener`> and it probably does not need CAP_NET_RAW... ping needs it, but that is because ping is broken
21:49:34< _id> thanx
21:49:42< Doener`> you're welcome
22:01:06>> dsanta_ [~santa@c68.190.156.105.roc.mn.charter.com] has quit [Quit: Lost terminal]
22:01:24>> dsanta [~santa@c68.190.156.105.roc.mn.charter.com] has joined #vserver
22:14:16>> dsanta_ [~santa@c68.190.156.105.roc.mn.charter.com] has joined #vserver
22:14:42>> dsanta_ [~santa@c68.190.156.105.roc.mn.charter.com] has quit [Quit: ]
22:23:40>> cgone is now known as cdub
22:27:07>> Sebastian [~cereal@pD9EABD0E.dip.t-dialin.net] has quit [Quit: W)W)ip www.wwip.de | Hosting, Housing, CoLocation and VServer | Forum: http://forum.wwip.de]
22:47:25>> monrad [~monrad@213083190226.sonofon.dk] has joined #vserver
22:56:35< monrad> hi
23:21:58>> Bertl_oO is now known as Bertl
23:23:31< _id> Bertl, wb
23:24:31< Bertl> evening folks!
23:24:46< Bertl> anything new/interesting/important?
23:25:43< Bertl> hi cdub, how are you?
23:25:44< _id> http://wiki.ael.be/index.php/Transcription
23:29:28< Bertl> at least austria isn't among the 'bad' guys ... although they didn't stand up against it :(
23:30:01< _id> Bertl, is so bad :(
23:30:29< Bertl> well, it's not over yet ...
23:30:41< _id> Germany is a big joke - in the news they always say - hey we support OSS - and then they vote YES
23:31:16< Bertl> it was expected, they have a great lobby there ...
23:31:17>> monrad [~monrad@213083190226.sonofon.dk] has quit [Ping timeout: 480 seconds]
23:31:20< _id> well - but chances rise for large corps to get their patents
23:32:42< _id> ok - i leave now - cya laters
23:32:50< Bertl> good whatever!
23:39:39>> Sebastian [~cereal@pD9EAB519.dip.t-dialin.net] has joined #vserver
23:39:48< Sebastian> ok re
23:39:51< Bertl> hi Sebastian (cereal)
23:40:01< Sebastian> hi Bertl :)
23:40:10< Sebastian> Bertl wonderfull news
23:40:18< Bertl> let's hear ...
23:40:26>> monrad [~monrad@213083190253.sonofon.dk] has joined #vserver
23:41:06< Sebastian> i have set up the system new with kernel 2.4.26 and util-vserver-0.29-4 and build a base which i can use to add new vserver on an easy way
23:41:21< Sebastian> when i logged in this vserver base vreboot works finde
23:41:24< Sebastian> fine
23:41:42< Sebastian> that are the good news
23:41:42< Bertl> ah good to hear ... so it was a tool/config issue, right?
23:42:19< Sebastian> ... know i copied base with a new name news config an start it
23:42:47< Sebastian> when i use vreboot on this new vserver
23:42:51< Sebastian> root@main6:/# vreboot
23:42:51< Sebastian> connect /dev/reboot (Connection refused)
23:43:38< Bertl> probably because there is no rebootmgr started for that one ...
23:44:02< Sebastian> why i have to start the rebootmgr for each vserver?
23:44:12< Sebastian> rebootmgr is running on the host
23:45:22< Sebastian> or should i have to start rebootmgr on every vserver on the system?
23:47:35< Bertl> the thing is, the rebootmgr is an old hack, which should be obsoleted by now ...
23:47:55< Sebastian> hmmm
23:48:06< Bertl> it is based on an userspace communication between a vserver and the rebootmgr
23:48:37< Bertl> via some socket, created inside the vserver, transporting the 'reboot' message to the outside (the rebootmgr)
23:49:16< Bertl> now as this piece of software isn't designed to handle more than one connection, and doesn't adjust on the fly either ...
23:49:44< Bertl> you have to start it for each and every vserver you want to be able to use the vreboot/vhalt ...
23:50:24< Bertl> the message 'connect /dev/reboot (Connection refused)' probably just means that the rebootmgr isn't attached to the other end of the pipe ...
23:50:56< Sebastian> hmmm yes because base is using rebootmgr actually
23:52:32< Sebastian> but that means
23:52:45< Sebastian> when only one vserver is running on the host
23:53:02< Sebastian> it would be work fine, with every new or old vserver
23:54:31< Bertl> look, we replaced this 'way' of rebooting the vserver with the vshelper (a kernel invoked userspace helper) around 1.1x and it is in 1.20 and naturally in 1.27 ...
23:54:53< Sebastian> hmmmm
23:55:36< Bertl> this works for all vservers, just needs a small script doing the actual work, and doesn't require a vreboot/vhalt at all ..
23:56:34< Sebastian> ok so i´m on the wrong way with util-vserver-0.29-4 ^^
23:56:49< Bertl> not necessarily, but definitely with rebootmgr ;)
23:57:33< Bertl> I don't know why debian folks didn't pick up the vshelper ... and instead jumped on the rebootmgr which is obviously badly implemented too ...
23:57:44< Sebastian> is there any opportunity to use vshelper with 0.29-4
23:58:20< Bertl> sure, just find/create a script which handles the reboot, and set the name in the sysfs (vshelper)
23:59:34< Bertl> /proc/sys/kernel/vshelper
23:59:34< Sebastian> :-/
23:59:49< Bertl> has to point at some 'executable' or properly designed script
--- Log closed ¶ro maj 19 00:00:19 2004