1152750183 Q * matti_ Ping timeout: 480 seconds
1152751201 J * matti ~matti@linux.gentoo.pl
1152752785 Q * schimmi Read error: Connection reset by peer
1152754545 N * Bertl_oO Bertl
1152754548 M * Bertl evening folks!
1152754555 M * anonc evenin' bertl
1152754583 M * Bertl daniel_hozac: just managed to figure out how to use PLM (now :)
1152754614 M * Bertl test started a few minutes ago, so should be done tomorrow, new urls are:
1152754620 M * Bertl http://plm.testing.osdl.org/patches/show/5183
1152754632 M * Bertl http://plm.testing.osdl.org/patches/show/5184
1152754676 M * Bertl argl! just saw that it doesn't work properly ...
1152754902 M * Bertl well, been there, done that, didn't bother to get the T-shirt :)
1152755209 M * anonc Bertl: any thoughts on whether its possible to create a more restrctive ioprio cap to control the ability to change best-effort scheduling?
1152755238 M * Bertl hmm, did you try with the cfq scheduler yet?
1152755279 M * Bertl I mean, you are probably trying to isolate guest, or am I wrong?
1152755358 M * Bertl anonc: I'm aware that you are asking something completely different, but I wonder why you want to tune/control scheduling inside? a guest in the first place
1152755359 M * anonc yeah - i have that working (with util-vserver patched to provide ionice support) well, but as said in this channel - the guests can still mess with the BE scheduling level. Only an issue if you don't control the guest
1152755419 M * Bertl hmm, guests are currently allowed to change I/O priorities? that would be a bug then ...
1152755446 M * anonc Bertl: only within the IOPRIO_CLASS_BE i believe (there are level 0-7 inside that class
1152755468 M * Bertl I probably missed most of the discussion, could you give me a short overview what you tested/figured out?
1152755510 M * anonc just a sec while i double check my findings...
1152755521 M * Bertl k, np
1152755731 Q * gerrit Read error: Operation timed out
1152755908 M * anonc ok. I added ionice support to the vserver tools so you can set the ionice class and priority for a vserver (which gets inherited by all forked processes). It seems to work ok. However there are 8 levels of 'best-effort' priority and changing the priority level from within a vserver is not restricted - so a vserver can up its io scheduling priority if it wants to (within the BE class). Only changing RT scheduling is affected by the current PRIO cap.
1152755939 M * anonc As I said, this is only really a problem if you don't control all the vservers yourself
1152755989 M * Bertl okay, so we basically should add a capability check for this, right?
1152756019 Q * Zaki Quit: Leaving
1152756030 M * anonc if io priorities are to be useful in a virtual server hosting service then that's probably required
1152756053 M * Bertl sounds good to me, so please keep buging me until you find it in the changelogs :)
1152756058 M * anonc just checking the previous discussion - one of the other bods on this channel pointed out the area needing changing
1152756076 J * Zaki ~Zaki@88.213.18.70
1152756082 M * Bertl (or alternatively provide a patch)
1152756377 M * anonc ah yes ; irc LOG_2006-07-05 daniel_hozac pointed out it is fs/ioprio.c:sys_ioprio_set
1152756467 M * anonc mmm - i wonder if its as simple as duplicating the CAP_SYS_ADMIN check that is already there for RT and IDLE classes
1152756556 M * Bertl yes, but what we probably want here is to add a context cap to allow it (to be changed)
1152756575 M * Bertl daniel_hozac: updated urls (because delete is not working either)
1152756579 M * Bertl http://plm.testing.osdl.org/patches/show/5185
1152756584 M * Bertl http://plm.testing.osdl.org/patches/show/5186
1152756637 M * anonc where should I look for info on how to add a context cap?
1152756756 M * anonc mmm - it should probably behave like igneg_nice and silently ignore priority change requests
1152756993 M * anonc when it doesn't have that CAP i mean
1152757239 M * Bertl yep, something like that was in my mind ...
1152757693 M * Bertl okay, off for tonight ... back tomorrow! have a good one everyone! and cya!
1152757698 M * anonc nite bertl
1152757703 N * Bertl Bertl_zZ
1152757827 J * Aiken_ ~james@tooax7-231.dialup.optusnet.com.au
1152758154 Q * Aiken Ping timeout: 480 seconds
1152764651 Q * baggins Read error: Operation timed out
1152765347 M * anonc now have a working IGNEG_IONICE context flag to silently ignore ionice changes. patches available from http://www.users.on.net/~anonc/.patches/vserver See readme.txt for usage info.
1152766435 J * baggins baggins@kenny.mimuw.edu.pl
1152767000 J * coocoon ~coocoon@84.160.95.55
1152767044 M * coocoon morning
1152767074 J * GISELA ~Ircupicha@host175.200-45-147.telecom.net.ar
1152767086 P * GISELA
1152767348 Q * s0undt3ch Ping timeout: 480 seconds
1152767465 Q * _jake- charon.oftc.net oxygen.oftc.net
1152767465 Q * daniel_hozac charon.oftc.net oxygen.oftc.net
1152767465 Q * Wenix charon.oftc.net oxygen.oftc.net
1152767465 Q * bogus charon.oftc.net oxygen.oftc.net
1152767465 Q * trippeh charon.oftc.net oxygen.oftc.net
1152767465 Q * morrigan charon.oftc.net oxygen.oftc.net
1152767465 Q * FireEgl charon.oftc.net oxygen.oftc.net
1152767465 Q * coocoon charon.oftc.net oxygen.oftc.net
1152767465 Q * shedi charon.oftc.net oxygen.oftc.net
1152767465 Q * romke charon.oftc.net oxygen.oftc.net
1152767465 Q * Nam charon.oftc.net oxygen.oftc.net
1152767465 Q * slava charon.oftc.net oxygen.oftc.net
1152767465 Q * anonc charon.oftc.net oxygen.oftc.net
1152767465 Q * DreamerC charon.oftc.net oxygen.oftc.net
1152767465 Q * click charon.oftc.net oxygen.oftc.net
1152767465 Q * lilo2 charon.oftc.net oxygen.oftc.net
1152767465 Q * Greek0 charon.oftc.net oxygen.oftc.net
1152767465 Q * pusling charon.oftc.net oxygen.oftc.net
1152767465 Q * micah charon.oftc.net oxygen.oftc.net
1152767465 Q * nebuchadnezzar charon.oftc.net oxygen.oftc.net
1152767465 Q * abi charon.oftc.net oxygen.oftc.net
1152767465 Q * baggins charon.oftc.net oxygen.oftc.net
1152767465 Q * Zaki charon.oftc.net oxygen.oftc.net
1152767465 Q * michal` charon.oftc.net oxygen.oftc.net
1152767465 Q * insomniac charon.oftc.net oxygen.oftc.net
1152767465 Q * cdrx charon.oftc.net oxygen.oftc.net
1152767465 Q * kir charon.oftc.net oxygen.oftc.net
1152767465 Q * cryptronic charon.oftc.net oxygen.oftc.net
1152767465 Q * SNy charon.oftc.net oxygen.oftc.net
1152767465 Q * Curus charon.oftc.net oxygen.oftc.net
1152767465 Q * TheSeer charon.oftc.net oxygen.oftc.net
1152767465 Q * sukria charon.oftc.net oxygen.oftc.net
1152767598 J * coocoon ~coocoon@84.160.95.55
1152767598 J * shedi ~siggi@130.208.221.254
1152767598 J * romke ~romke@83.16.133.162
1152767598 J * Nam ~nam@70.78.64.62
1152767598 J * slava ~slava@195.22.238.42
1152767598 J * anonc ~anonc@203.26.95.33
1152767598 J * DreamerC ~dreamerc@59.112.2.33
1152767598 J * click click@80.212.107.13
1152767598 J * lilo2 ~0710AAD4@tor-irc.dnsbl.oftc.net
1152767598 J * Greek0 ~greek0@85.255.145.201
1152767598 J * pusling pusling@195.215.29.124
1152767598 J * micah ~micah@208.99.202.72
1152767598 J * nebuchadnezzar ~nebu@82.233.222.74
1152767598 J * abi ~abi@213.155.82.133
1152767607 J * bogus ~bogusano@fengor.net
1152767607 J * Wenix ~wenix@81.7.189.11
1152767607 J * trippeh atomt@x.vx.no
1152767607 J * daniel_hozac ~daniel@c-2d1472d5.010-230-73746f22.cust.bredbandsbolaget.se
1152767607 J * _jake- psybnc@murlocs.org
1152767607 J * morrigan morrigan@212.16.62.52
1152767612 J * cryptronic crypt@mail.openvcp.org
1152767617 J * sukria ~sukria@www.sukria.net
1152767647 J * SNy 7e53667ae7@bmx-chemnitz.de
1152767707 J * FireEgl Atlantica@Atlantica.US
1152767707 T * neutron.oftc.net http://linux-vserver.org/ | latest stable 2.01, 1.2.10, 1.2.11-rc1, devel 2.1.0, exp 2.{0.2,1.1}-rc26 | util-vserver-0.30.210 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;)
1152767710 J * insomniac ~insomniac@slackware.it
1152767710 J * michal` ~michal@www.rsbac.org
1152767710 J * baggins baggins@kenny.mimuw.edu.pl
1152767710 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1152767710 J * Zaki ~Zaki@88.213.18.70
1152767755 J * Curus ~Curus@kbhn-vbrg-sr0-vl209-213-185-8-10.perspektivbredband.net
1152767766 J * TheSeer ~theseer@border.office.salesemotion.net
1152767772 J * kir ~kir@swsoft-mipt-nat.sw.ru
1152768055 Q * kir helium.oftc.net oxygen.oftc.net
1152768055 Q * TheSeer helium.oftc.net oxygen.oftc.net
1152768055 Q * Curus helium.oftc.net oxygen.oftc.net
1152768055 Q * Zaki helium.oftc.net oxygen.oftc.net
1152768055 Q * cdrx helium.oftc.net oxygen.oftc.net
1152768055 Q * baggins helium.oftc.net oxygen.oftc.net
1152768055 Q * michal` helium.oftc.net oxygen.oftc.net
1152768055 Q * insomniac helium.oftc.net oxygen.oftc.net
1152768247 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1152768247 J * michal`_ ~michal@www.rsbac.org
1152768247 J * kir ~kir@swsoft-mipt-nat.sw.ru
1152768247 J * insomniac ~insomniac@slackware.it
1152768247 J * Zaki ~Zaki@88.213.18.70
1152768247 J * baggins baggins@kenny.mimuw.edu.pl
1152768355 J * Curus ~Curus@kbhn-vbrg-sr0-vl209-213-185-8-10.perspektivbredband.net
1152768355 J * TheSeer ~theseer@border.office.salesemotion.net
1152768871 J * s0undt3ch ~s0undt3ch@bl7-243-149.dsl.telepac.pt
1152769289 N * otaku42_away otaku42
1152769667 J * Viper0482 ~Viper0482@p54977298.dip.t-dialin.net
1152770588 J * gerrit ~gerrit@67.160.146.170
1152772251 Q * Wenix Ping timeout: 480 seconds
1152773345 J * dna ~naucki@dialer-143-227.kielnet.net
1152774019 Q * FireEgl Ping timeout: 480 seconds
1152774122 Q * cdrx Ping timeout: 480 seconds
1152774969 J * ||Cobra|| ~cob@146.50.22.204
1152775294 Q * Aiken_ Ping timeout: 480 seconds
1152776596 J * cdrx ~legoater@70-33-118-80.kaptech.net
1152777022 Q * Viper0482 Quit: one day, i'll find this peer guy and then i'll reset his connection!!
1152777039 J * Viper0482 ~Viper0482@p54977298.dip.t-dialin.net
1152777153 J * mattr_sf ~matt@80.136.84.61
1152777207 Q * michal`_ Ping timeout: 480 seconds
1152777331 J * Smutje_ ~Smutje@xdsl-84-44-247-237.netcologne.de
1152777439 Q * s0undt3ch Quit: leaving
1152777444 J * s0undt3ch ~s0undt3ch@bl7-243-149.dsl.telepac.pt
1152777449 Q * Smutje Ping timeout: 480 seconds
1152777449 N * Smutje_ Smutje
1152777731 J * michal` ~michal@www.rsbac.org
1152780946 J * cskarby ~cs@195.1.31.69
1152781129 M * cskarby where can I find information about the changes from rc25 to rc26? Do we have a source control management system somewhere where I can look at changeLogs? (I know we have change logs on the wiki, but it is not updated for rc's it seems.)
1152781456 M * daniel_hozac it is.
1152781479 M * cskarby it is :)
1152781479 M * daniel_hozac http://linux-vserver.org/ChangeLogExperimental
1152781497 M * cskarby nice, thank you
1152781820 J * pisco ~pampel@80.135.163.122
1152781955 Q * shedi Quit: Leaving
1152782510 J * matti_ ~matti@212.244.232.46
1152782663 Q * matti Ping timeout: 480 seconds
1152783360 J * Aiken ~james@tooax6-063.dialup.optusnet.com.au
1152783470 Q * pisco Remote host closed the connection
1152783513 J * pisco ~pampel@80.135.163.122
1152783641 Q * pisco Remote host closed the connection
1152783676 J * pisco ~pampel@p5087A37A.dip0.t-ipconnect.de
1152783697 J * Wenix ~wenix@81.7.189.11
1152783706 Q * pisco Remote host closed the connection
1152783857 J * pisco ~pampel@80.135.163.122
1152783861 P * pisco
1152783893 Q * cdrx Read error: Operation timed out
1152784727 J * pisco ~pampel@p5087A37A.dip0.t-ipconnect.de
1152784880 P * pisco
1152785259 J * pisco ~pampel@80.135.163.122
1152785276 Q * pisco Remote host closed the connection
1152785328 Q * m4z Ping timeout: 480 seconds
1152785467 J * pisco ~pampel@80.135.163.122
1152785484 Q * pisco Quit:
1152785655 J * pisco ~pampel@p5087A37A.dip0.t-ipconnect.de
1152785738 Q * pisco Remote host closed the connection
1152785797 J * pisco ~pampel@80.135.163.122
1152786023 J * id23 ~id@p50810B25.dip0.t-ipconnect.de
1152786038 M * id23 hi #vserver
1152786278 M * sid3windr hi id23
1152787093 J * meandtheshell ~markus@85-124-36-240.dynamic.xdsl-line.inode.at
1152787958 Q * nokoya Ping timeout: 480 seconds
1152789440 J * nokoya young@hi-230-82.tm.net.org.my
1152791117 N * Bertl_zZ Bertl
1152791122 M * Bertl morning folks!
1152791128 M * derjohn Moin Bertl !
1152791204 M * poiin2000 hi derjohn
1152791261 M * anonc mornin' bertl - as requested: patches adding ionice support + context capability for silently ignoring ioprio requests inside a guest: http://www.users.on.net/~anonc/.patches/vserver
1152791270 M * derjohn poiin2000, ah, /me slaps himself ...
1152791390 M * daniel_hozac Bertl: did you see vrwttnmtu's paste yesterday? http://paste.linux-vserver.org/176 who do we blame for the wrong offset in the mov 0x20(%esp),%ebx instruction, gcc or shiny?
1152791519 M * romke morning Bertl
1152791703 M * Bertl %ebx? we worked around that half a year ago (for PIC code)
1152791718 M * daniel_hozac Bertl: yep.
1152791722 A * Bertl is looking now ...
1152791781 J * schimmi ~sts@141.84.9.37
1152791851 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1152791855 M * Bertl daniel_hozac: but I don't see what's wrong here, please clarify for me (it's in the morning :)
1152791868 M * Bertl *early morning, no breakfast yet :)
1152792064 Q * Aiken Ping timeout: 480 seconds
1152792603 J * m4z m4z@bastard-operator.from-hell.net
1152792614 M * Bertl welcome m4z!
1152792626 M * Bertl wb schimmi! cdrx!
1152792672 M * cdrx bertl !
1152792704 M * cdrx bertl : where do you live ?
1152792739 J * Milf ~Miranda@ipsio252.ipsi.fraunhofer.de
1152792746 M * m4z evening, Bertl
1152792749 M * sid3windr cdrx: bertl-land
1152792761 M * sid3windr with bertl-timezone ;)
1152792770 M * Bertl ah, wb Milf!
1152792775 M * Milf Hi
1152792777 M * [PUPPETS]Gonzo Bertlshausen :) - hi milf, derjohn
1152792797 M * Bertl looks like everybody is awake :)
1152792831 M * cdrx sid3windr: yes a wide timezone indeed :)
1152792842 M * [PUPPETS]Gonzo since hours
1152792850 A * [PUPPETS]Gonzo lies.
1152792878 A * sid3windr lies down
1152792882 M * sid3windr *wishful thinking*
1152792952 M * Bertl okay, have to get something to eat, bbl ...
1152792957 N * Bertl Bertl_oO
1152792959 M * sid3windr enjoy
1152793050 M * derjohn [PUPPETS]Gonzo, ehlo!
1152793060 M * [PUPPETS]Gonzo derjohn: ICQ?
1152793070 Q * schimmi Ping timeout: 480 seconds
1152793169 Q * wenchien Quit: Terminated with extreme prejudice - dircproxy 1.0.5
1152793219 Q * lilalinux Ping timeout: 480 seconds
1152793539 Q * sladen Ping timeout: 480 seconds
1152793617 Q * michal` Ping timeout: 480 seconds
1152793719 M * daniel_hozac Bertl_oO: asm isn't my strong-suit, but won't the pushl %ebx subtract 4 more from %esp, thereby make 0x24(%esp) the correct address for the first argument?
1152793740 J * lilalinux ~plasma@dslb-084-058-213-222.pools.arcor-ip.net
1152793814 J * sladen paul@starsky.19inch.net
1152794156 J * michal` ~michal@www.rsbac.org
1152795037 J * jesse_ ~wenchien@221-169-69-23.adsl.static.seed.net.tw
1152795060 J * schimmi ~sts@host82.natpool.mwn.de
1152795083 N * jesse_ wenchien
1152795227 J * brc bruce@i.am.someasshole.com
1152795237 M * brc Bertl around ?
1152795383 M * doener he went off to get some food
1152795450 M * brc ok
1152795474 M * brc Do you know something about the quota development (quota support)?
1152795482 M * doener no
1152795488 M * brc I was doing scripts for quota tests but i got so many problems i had to get off for some time
1152795511 M * brc ok.
1152795613 M * daniel_hozac so the old quota patch wasn't working?
1152795640 M * brc No
1152795644 M * brc new quota patch
1152795666 M * daniel_hozac well, that's what i meant. it's pretty old by now though :)
1152795683 M * brc Is there already a quota patch for 2.6 ?
1152795731 M * brc vservers on the same partition..
1152795756 M * daniel_hozac oh right, you were just testing the quota hashes, right?
1152795819 M * doener daniel_hozac: hm, what's supposed to be copied into %ebx in that snippet?
1152795830 M * brc guess so. Is that already done ?
1152795843 M * daniel_hozac doener: vc_syscall is a vserver syscall wrapper.
1152795860 M * daniel_hozac doener: %ebx is supposed to be the first argument, %ecx the second, and %edx the third.
1152795881 M * daniel_hozac brc: you tell us :) aren't they working?
1152795928 M * daniel_hozac doener: AFAICT, it's copying the return address instead though, making sys_vserver return with ENOSYS.
1152795958 M * brc dont know i am coming back
1152795970 A * doener needs to look up stack call conventions...
1152796300 Q * mattr_sf Quit: Leaving
1152796560 M * doener daniel_hozac: would you mind to explain the call to strcpy to me? I most probably just got a wrong image of the stack in my mind, but how does that get its arguments? 0x0(%esp) to 0xb(%esp) look undefined to me
1152796581 M * daniel_hozac doener: i have no idea what that is.
1152796608 M * doener :(
1152796629 M * doener which files/patches make up the source for that asm?
1152796660 M * daniel_hozac util-vserver-0.30.210/lib/syscall-syscall.c
1152796683 J * shedi ~siggi@dsl-og-108-50.du.vortex.is
1152796690 M * daniel_hozac with vserver defined as _syscall3(...) from http://vserver.13thfloor.at/Experimental/SYSCALL/syscall_shiny10.h
1152797147 M * derjohn Bertl_oO, I take over that praesentation on Pforzheimer Linux
1152797151 M * derjohn Tag ....
1152797481 J * FireEgl Atlantica@Atlantica.Tcldrop.Com
1152797703 M * daniel_hozac doener: i'm quite curious where the call and subsequent add come from, i don't see what would create them much less what their purpose is.
1152798345 M * doener daniel_hozac: was that compiled with __PIC__?
1152798451 N * _jake- jake-
1152798571 J * mire ~mire@156-166-222-85.COOL.ADSL.VLine.verat.net
1152798619 Q * Milf Read error: Connection reset by peer
1152799095 J * Piet ~piet@tor-irc.dnsbl.oftc.net
1152799573 M * doener daniel_hozac: guess I give up... I don't even see where the syscall happens, neither in that snippet nor in shiny
1152799606 M * doener I see "int $0x80" after the preprocessor did it's magic, but that's it
1152799616 M * doener no idea where that comes from
1152799910 M * doener d'oh, found it...
1152800524 M * daniel_hozac hehe.
1152800586 M * daniel_hozac i assume it's compiled with __PIC__, as it's part of util-vserver's shared library.
1152800615 J * pisc1 ~pampel@p5087A37A.dip0.t-ipconnect.de
1152800867 Q * Viper0482 Ping timeout: 480 seconds
1152800938 Q * shedi Read error: Connection reset by peer
1152801079 J * Viper0482 ~Viper0482@p54977298.dip.t-dialin.net
1152801389 M * jake- hi everybody
1152801464 M * jake- i get an errormsg when installing an ubuntu guest under a debian host
1152801477 M * jake- I: Configuring ubuntu-minimal...
1152801477 M * jake- I: Base system installed successfully.
1152801477 M * jake- /bin/rm: Entfernen von Verzeichnis ,,/etc/vservers/.defaults/vdirbase/ubuntu2/dev/.static/dev" nicht möglich: Das Gerät oder die Ressource ist belegt
1152802359 Q * pisc1 Ping timeout: 480 seconds
1152802370 M * doener daniel_hozac: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Modifiers.html#Modifiers -- does that mean that we need the & modifier there?
1152802390 M * doener (for cmd)
1152802576 Q * lilalinux Quit: Leaving
1152802587 Q * lilo2 Quit: leaving
1152802617 J * lilalinux ~plasma@dslb-084-058-213-222.pools.arcor-ip.net
1152802642 Q * lilalinux Quit:
1152802656 J * lilalinux ~plasma@dslb-084-058-213-222.pools.arcor-ip.net
1152802725 J * lilo2 hiddenserv@tor.noreply.org
1152802843 N * Ben_zZz Ben_
1152803236 N * nokoya nokoyaz
1152803243 N * nokoyaz nokoya
1152803379 Q * ||Cobra|| Read error: Connection reset by peer
1152803852 J * yarihm ~yarihm@whitehead2.nine.ch
1152803947 M * doener daniel_hozac: do you happen to know which gcc version was used to compile that? mine uses ebp instead of esp and thus has no problems with that push
1152804080 J * tatiane ~tatiane@201009044113.user.veloxzone.com.br
1152804127 Q * tatiane Quit:
1152804141 N * otaku42 otaku42_away
1152804268 J * mkhl ~mkhl@200-153-153-254.dsl.telesp.net.br
1152804934 P * cskarby
1152805285 J * id_ ~id@p50813111.dip0.t-ipconnect.de
1152805368 M * Viper0482 hi
1152805399 M * Viper0482 is it posible to "map" an usb device inside a vserver?
1152805477 M * doener daniel_hozac: the strcpy thing is just bogus, it's actually a call to some code that saves esp in ebx...
1152805495 A * doener just found out that he compiled that stuff with -D__PIC__ but without -fpic... *sigh*
1152805724 Q * id23 Ping timeout: 480 seconds
1152805737 M * doener now I actually get the same broken code
1152806089 J * stefani ~stefani@tsipoor.banerian.org
1152806217 M * doener daniel_hozac: http://paste.linux-vserver.org/178
1152806274 M * doener The code from "mine" is correct and better than that from shiny, no idea how to get "mine" using the macro-magic in shiny though.
1152806623 Q * schimmi Ping timeout: 480 seconds
1152807262 Q * teukka Ping timeout: 480 seconds
1152807575 M * daniel_hozac doener: yeah, that looks better.
1152807724 J * bonbons ~bonbons@83.222.39.166
1152807730 M * daniel_hozac doener: hmm, if i'm reading __sc_asmload correctly, %eax is used for the 6th argument. would you agree?
1152807749 J * matti ~matti@linux.gentoo.pl
1152807753 J * lilalinux_ ~plasma@h1-gw.of.net-lab.net
1152808174 J * ssm 1682710257@login.fnord.no
1152808175 Q * matti_ Ping timeout: 480 seconds
1152808184 Q * lilalinux Ping timeout: 480 seconds
1152808184 Q * yarihm Quit: Leaving
1152808705 J * schimmi ~sts@port-212-202-73-176.dynamic.qsc.de
1152809276 J * mattr_sf ~matt@p5088543D.dip.t-dialin.net
1152809504 Q * mire Quit: Leaving
1152810189 J * TermUnitX ~PhAnATiC@dsl-200-95-79-111.prod-infinitum.com.mx
1152810215 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk
1152810372 M * vrwttnmtu Hey daniel_hozac, just wanted to say that my v6 vserver is working well, and thanks.
1152810402 M * vrwttnmtu Might patch my utils too, just for added goodness.
1152810676 M * vrwttnmtu How do you do links in the Wiki?
1152810683 M * vrwttnmtu doesn't seem to work
1152810703 M * vrwttnmtu Is it [http://sdf/sdc Link text] like MediaWiki?
1152810746 M * daniel_hozac yep.
1152810769 M * daniel_hozac btw, we seem to have located the problematic piece of code in your snippet.
1152810777 M * vrwttnmtu My snippet?
1152810781 M * vrwttnmtu I don't write code :0
1152810782 M * vrwttnmtu :)
1152810812 M * daniel_hozac http://paste.linux-vserver.org/176 ;)
1152810816 M * vrwttnmtu Oh!
1152810817 M * vrwttnmtu That
1152810822 M * vrwttnmtu What is up with it?
1152810841 M * vrwttnmtu I'd forgotten all about that in my ipv6 happiness
1152810899 M * vrwttnmtu I think it's this line: 8b 7c 24 14 mov 0x14(%esp),%edi
1152810911 A * vrwttnmtu has no idea really
1152810912 M * vrwttnmtu :)
1152810953 Q * mattr_sf Quit: Leaving
1152811067 M * Wonka .oO( so, when will v6 be in HEAD? *g* )
1152811080 A * vrwttnmtu nods at Wonka
1152811084 M * vrwttnmtu Pleeeease.
1152811095 J * lilo2_ hiddenserv@tor.noreply.org
1152811129 Q * lilo2 Remote host closed the connection
1152811165 M * daniel_hozac vrwttnmtu: it's the mov 0x20(%esp), %ebx ;)
1152811179 Q * lilo2_ Remote host closed the connection
1152811191 M * vrwttnmtu Hmmm. Yes, of course. that second % should be a #include ipv6.h, no?
1152811193 M * vrwttnmtu :P
1152811266 M * vrwttnmtu daniel_hozac, Seriously though, what is wrong with it?
1152811314 M * daniel_hozac it's off by 4, it should be 0x24(%esp).
1152811370 M * vrwttnmtu What does it mean if it's 20, and what causes it to be 24? (I have 0 knowledge about asm btw). Oh, and how can it be fixed?
1152811425 M * daniel_hozac it was 20, but the pushl before it makes it 24.
1152811437 M * daniel_hozac you could open a hexeditor and change it ;)
1152811468 M * vrwttnmtu What file is it that causes that? the vserver lib?
1152811569 M * daniel_hozac the alternative syscall implementation.
1152811617 M * vrwttnmtu I'm using an alternative one?
1152811629 A * vrwttnmtu is lost.
1152811644 M * daniel_hozac the utils do by default ;)
1152811665 M * vrwttnmtu So why is it a problem on that box, but not my others?
1152811704 M * daniel_hozac different gcc versions?
1152811723 M * vrwttnmtu And a different GCC will use a different syscall?
1152811747 M * daniel_hozac no, but it might not generate the same code.
1152811790 M * vrwttnmtu head asplodes.
1152811832 M * vrwttnmtu Box a that works: gcc version 3.4.4 (Gentoo Hardened 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
1152811851 M * vrwttnmtu Box b that doesn't: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
1152811863 M * vrwttnmtu # gcc-config -l
1152811863 M * vrwttnmtu [1] i686-pc-linux-gnu-3.3.4 *
1152811863 M * vrwttnmtu [2] i686-pc-linux-gnu-3.4.6
1152811863 M * vrwttnmtu [3] i686-pc-linux-gnu-3.4.6-hardened
1152811863 M * vrwttnmtu [4] i686-pc-linux-gnu-3.4.6-hardenednopie
1152811865 M * vrwttnmtu [5] i686-pc-linux-gnu-3.4.6-hardenednopiessp
1152811866 M * vrwttnmtu [6] i686-pc-linux-gnu-3.4.6-hardenednossp
1152811882 M * vrwttnmtu Shit. I updated gcc and glibc yesterday on that box, but didn't select the new gcc
1152811887 M * vrwttnmtu doh!
1152812005 M * vrwttnmtu Box c that works: gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
1152812035 M * daniel_hozac so it looks like a 3.3 vs. 3.4 thing.
1152812041 M * vrwttnmtu Yeah.
1152812079 M * vrwttnmtu I almost don't want to mess with the box we got working yesterday
1152812089 M * daniel_hozac hehe.
1152812090 M * vrwttnmtu I could back up the chbind6-shiny
1152812099 M * vrwttnmtu And try compiling the new one with the 3.6.4 gcc
1152812148 M * vrwttnmtu 3.4.6 I meant
1152812205 M * vrwttnmtu Wouldn't it just be easier to put the -shiny code in the main chbind6.c code?
1152812230 M * daniel_hozac it is now ;)
1152812254 M * vrwttnmtu Oh, so even if I compile it with a 3.3, or 3.4 gcc, it will work anyway?
1152812393 M * daniel_hozac it will use shiny if you define __NR_vserver.
1152812482 M * vrwttnmtu I wish the v6 patch was in the utils already - I prefer to use Gentoo ebuilds, as it's a nice way of keeping track of packages, and versions, and stuff.
1152812509 M * daniel_hozac the v6 patch is sort a q'n'd hack though.
1152812526 M * daniel_hozac it's not even in the set of patches i actively try to get into the utils ;)
1152812588 M * vrwttnmtu I think the whole vserver stuff should have all the v6 patches added.
1152812595 M * vrwttnmtu It all seems to work pretty well.
1152812614 M * vrwttnmtu There could be an option in the menuconfig for [*] Enable IPv6 guests
1152812625 M * vrwttnmtu And USE="ipv6" emerge util-vserver
1152812630 M * vrwttnmtu So it's still optional
1152812654 M * daniel_hozac doesn't make much sense to have it optional in the utils.
1152812666 M * daniel_hozac the kernel is already menuconfig'able.
1152812675 M * daniel_hozac (i.e. disable IPv6, and IPv6 in guests is disabled).
1152812679 M * vrwttnmtu Well, it would mean there'd be less excuse not to have the patch in
1152812683 M * daniel_hozac or at least, that's the intention.
1152812706 M * vrwttnmtu Options, Danny-boy. Give them the option, that way they can't grumble about it. :)
1152812719 M * vrwttnmtu Perhaps they want a v6 host, but not v6 guests? Who knows...
1152812743 M * daniel_hozac then you don't assign IPv6 addresses to them :)
1152812765 M * vrwttnmtu But perhaps they're worried that the v6 code opens up new holes, or hasn't been extensively tested.
1152812766 M * vrwttnmtu ?
1152812784 M * vrwttnmtu If it's easy to give them the choice, it's best to
1152812786 M * vrwttnmtu IMO
1152812833 M * vrwttnmtu I agree. I can't see why someone would have a v6 host, but not want the v6 stuff available for the vservers. But then again, I'm not everyone
1152813066 Q * TermUnitX Quit: (-(PS)-) [v5.0.r02] http://www.kalendas.net
1152813277 J * mire ~mire@156-166-222-85.COOL.ADSL.VLine.verat.net
1152813340 M * doener daniel_hozac: yeah, eax is used there... no idea if you can use my workaround for the 6 argument case at all
1152814168 J * restill ~restill@c-71-197-23-172.hsd1.mi.comcast.net
1152814652 Q * cdrx Ping timeout: 480 seconds
1152815608 Q * sladen Ping timeout: 480 seconds
1152815705 J * sladen paul@starsky.19inch.net
1152815810 Q * id_ Quit: Leaving
1152815871 Q * restill Quit: Leaving
1152815964 Q * pusling Quit: kernel upgrade - don't r00t me
1152816348 J * pusling pusling@195.215.29.124
1152818014 J * Smutje_ ~Smutje@xdsl-87-78-0-119.netcologne.de
1152818132 Q * Viper0482 Remote host closed the connection
1152818196 Q * mkhl Quit:
1152818209 Q * Smutje Ping timeout: 480 seconds
1152818209 N * Smutje_ Smutje
1152818488 Q * vrwttnmtu Ping timeout: 480 seconds
1152818759 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1152820021 J * lilo2 hiddenserv@tor.noreply.org
1152820416 J * duckx ~Duck@tox.dyndns.org
1152821231 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk
1152821670 Q * coocoon Ping timeout: 480 seconds
1152822328 J * coocoon ~coocoon@p54A07CFD.dip.t-dialin.net
1152822362 Q * coocoon Quit:
1152822397 J * coocoon ~coocoon@p54A07CFD.dip.t-dialin.net
1152823285 M * derjohn Bertl_oO, http://infotag.pf-lug.de/2006/page,Programm <--
1152823692 M * Ben_ hrhr
1152823764 Q * duckx Quit: Client exiting
1152823911 Q * vrwttnmtu Remote host closed the connection
1152824586 Q * bonbons Quit: Leaving
1152824747 N * Ben_ Ben_zZz
1152824753 Q * meandtheshell Quit: bye bye ...
1152825894 Q * coocoon Quit: KVIrc 3.2.0 'Realia'
1152825977 P * stefani I'm Parting (the water)
1152826106 J * yarihm ~yarihm@84-75-99-31.dclient.hispeed.ch
1152826139 J * Aiken ~james@tooax8-213.dialup.optusnet.com.au
1152827139 J * comfrey ~comfrey@c-67-171-253-174.hsd1.wa.comcast.net
1152827145 M * comfrey hey all
1152827161 M * comfrey anyone seeing any hard freezes on amd64 boxes?
1152827206 Q * mire Quit: Leaving
1152827261 M * comfrey we are using the backported k7 kernel on amd64 hw
1152827292 J * juggo ~lemur@h-68-166-181-4.sttnwaho.covad.net
1152827400 M * daniel_hozac comfrey: what causes it?
1152827514 M * comfrey i will take a look on the mailing list
1152827671 Q * comfrey Remote host closed the connection
1152827688 J * comfrey ~comfrey@c-67-171-253-174.hsd1.wa.comcast.net
1152827976 Q * alexx Quit: Bye
1152830004 Q * schimmi Ping timeout: 480 seconds
1152830055 J * Piet_ ~piet@tor-irc.dnsbl.oftc.net
1152830106 Q * lilalinux_ Remote host closed the connection
1152830472 Q * Piet Ping timeout: 480 seconds
1152831077 N * Bertl_oO Bertl
1152831081 M * Bertl evening folks!
1152831092 M * daniel_hozac evening!
1152831097 M * FaUl hey bertl
1152831110 M * Bertl derjohn: hey cool!
1152831151 M * FaUl Bertl: i'm going to migrate the last two productive vserver from our sun within the next two weeks, but the logistic question still remains
1152831167 M * Bertl comfrey: hmm x86_64 in general or with vserver patch in particular?
1152831219 M * Bertl FaUl: hmm, well, we should be able to solve that somehow ...
1152831320 M * FaUl yes, i think so twoo
1152831321 M * juggo I work with comfrey, and the problem is not Athlon 64 related, we have 3 vserver machines, all either nforce2 or nforce4, 1 athlon xp, 1 athlon 64, and 1 athlon x2
1152831322 M * FaUl too
1152831419 M * juggo problems worsened last night, with 2 changes, 1) kernel was upgraded to latest debian backport kernel, 2) the 2 machines experiencing increased lockups are running rails vservers (using mongrel), a machine which had its rails vserver disabled has been running fine for the last 24 hours
1152831439 M * juggo so could there be something that locks a machine up when using epoll or something like that?
1152831488 M * juggo what's so frustrating for us is that there is absolutely no info in the logs, just 1 minute the machine is up, the next it's locked solid, requiring a power cycle
1152831529 M * daniel_hozac juggo: tried serial/net console?
1152831555 M * juggo and it's only happening on our vserver boxes, though they're also the only ones running the hardware they are, so it could be hardware related, or it could be vserver related, just hard to know
1152831574 M * juggo I haven't yet, I've never had to do that before so I'm still trying to figure out how to do it
1152831604 M * juggo it requires passing a parameter at boot time? or can you turn it on once a machine is running?
1152831664 M * doener hey Bertl! Did you see the syscall-shiny "exploration"? ;)
1152831831 Q * dna Quit: Verlassend
1152832631 M * Bertl doener: daniel did show me some disassembler listing, but it seems I missed the point there, care to elaborate?
1152832676 M * doener gcc seems to miss that pushl modifies esp and thus generates broken code with -fpic (without -fpic it uses ebp here and thus has no problem with pushl)
1152832712 M * Bertl doener: well, that is regarding ebx, yes?
1152832729 M * Bertl juggo: what is 'rails'?
1152832763 M * doener yeah, ebx is pushed, esp gets modified and then the wrong argument gets stored in ebx breaking the syscall
1152832774 M * Bertl doener: according to the gcc folks it's proper behaviour to ignore push/pop/whatever on registers like the %ebx in pic mode
1152832820 M * Bertl doener: ah, now I get it, is it confirmed that it _is_ the wrong argument?
1152832860 M * Bertl daniel_hozac: could you give me the url once again, please?
1152832863 M * daniel_hozac Bertl: ltrace and strace show different arguments.
1152832870 M * daniel_hozac http://paste.linux-vserver.org/176
1152832874 M * Bertl tx
1152832876 M * doener well, unless daniel and me both got it wrong... it looks like this: movl 0x1c(%esp), ecx; pushl %ebx; movl 0x20(%esp), ebx
1152832904 M * Bertl okay, can I get an -S output of the miscompilation (i.e. the asm source code)?
1152832912 M * doener sec
1152832944 M * doener http://paste.linux-vserver.org/179
1152832957 M * Bertl juggo: and did you try with a non-debian kernel (i.e. vanilla 2.6.17.4 or so) yet?
1152833011 M * doener and here's a modified version that produces correct and better code, but it probably won't work for 6 argument syscalls and I have no idea how to get that into syscall-shiny at all either -- http://paste.linux-vserver.org/178
1152833064 N * Piet_ Piet
1152833292 M * Bertl doener: which gcc is that (which causes trouble?)
1152833325 M * daniel_hozac .ident "GCC: (GNU) 4.1.2 20060708 (prerelease) (Debian 4.1.1-8)"
1152833326 M * daniel_hozac ;)
1152833346 M * doener I tried it using 4.1 here, but vsomething (can't remember his nick) was using 3.3.x IIRC, worked for him on 3.4.x
1152833378 Q * phedny Ping timeout: 480 seconds
1152833406 M * doener 19:30:32 Box a that works: gcc version 3.4.4 (Gentoo Hardened 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
1152833409 M * doener 19:30:51 Box b that doesn't: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
1152833412 M * doener there you go
1152833425 M * Bertl why are we missing the stack frame, btw?
1152833449 M * Bertl i.e. %ebp seems to be unused in the 179'er dump
1152833510 M * doener ah, that was compiled using vrwttnmtu's settings, including -fomit-frame-pointer, I'll create one without that
1152833631 M * doener http://paste.linux-vserver.org/180
1152833660 M * doener ok, that was the reason for ebp being unused... should've turned on my brain before saying that -fpic caused that...
1152833695 M * Bertl okay, so that works fine I guess, right?
1152833740 M * doener that should be fine, yeah
1152833857 M * juggo Rails is "Ruby on Rails" a web application development framework, we're running mongrel which is an application server / web server, that's why I asked about epoll because I'm wondering if something like that could be an issue
1152833926 M * doener Bertl: could you explain why we need to save ebx?
1152833927 M * juggo I have not tried a non-debian kernel, even when I was building custom kernels I was using the debian tools to do so
1152833946 J * phedny ~mark@volcano.p-bierman.nl
1152833959 M * Bertl doener: when in pic mode, then ebx is the PIC base
1152833976 M * Bertl doener: and gcc does not allow to clobber it and does not care about it either
1152833989 M * Bertl doener: it just assumes that it will always have the correct value
1152834015 M * Bertl doener: could you run the framepointer vs non-fp version through gcc -dM -E and diff the output for me?
1152834092 M * Bertl juggo: it's always good to have guests which 'trigger' something, do you feel that this specific guest triggers it or is that just a shot in the dark?
1152834125 M * doener the .s files?
1152834136 M * Bertl juggo: could you try on one machine with, let's say 2.6.17.4-vs2.1.1-rc26 ?
1152834153 M * doener nvm
1152834155 M * Bertl doener: no, just do the gcc call as usual with the .c
1152834247 M * doener empty diff
1152834257 M * Bertl thought so, would have been too easy :)
1152834258 M * juggo well right now the rails guests are disabled and everything is running fine, but in the last 24 hours one of the machines crashed 4 times
1152834281 M * Bertl juggo: could be the lower load or resource usage maybe?
1152834302 M * juggo well, the thing is those guests are not in production
1152834314 M * Bertl the rail ones?
1152834318 M * juggo yes
1152834322 M * juggo so the server load is about the same
1152834341 M * juggo and the crashes don't seem to be correlated with any load issues
1152834366 M * juggo everything is monitored with munin, and before crashing there are no spikes in memory, swap, load, cpu, disk, anything, just normal and then crahed
1152834373 M * juggo crashed
1152834412 M * daniel_hozac have you narrowed it down to a specific process in that guest?
1152834423 M * Bertl doener: could you try to add the following to the x86 shiny definition:
1152834428 M * Bertl #define__sysc_rcon(n) __arg_##n("r","g","g","g","g","g")
1152834457 M * juggo I don't know, mongrel perhaps
1152834465 Q * [PUPPETS]Gonzo Remote host closed the connection
1152834465 M * Bertl doener: and redo both cases (upload to paste), TIA :)
1152834485 M * daniel_hozac juggo: so stracing that might provide some clues?
1152834504 M * Bertl juggo: how large is that guest?
1152834532 M * juggo perhaps, but what procedure for using strace would be recommended, given that I can't cause the issue to occur
1152834562 Q * phedny Remote host closed the connection
1152834570 M * juggo 815MB
1152834583 M * Bertl juggo: if you look at the times when those crashes happened, do you see any correlation?
1152834612 M * Bertl i.e. for example always on *:13 min or always N hours after reboot
1152834640 M * Bertl (or maybe guest startup, or whatever)
1152834708 M * juggo no the times are pretty random
1152834727 M * juggo sometimes middle of the night, sometimes middle of the day
1152834735 M * Bertl okay, and it happened on different hosts, yes?
1152834740 M * juggo yes
1152834749 M * juggo so that would suggest a software issue
1152834752 M * Bertl but they have the very same kernel, right?
1152834757 M * juggo yes
1152834771 M * juggo however in doing the research I found a number of people complaining about nforce board lockups
1152834790 M * Bertl yes, nForce is still pretty problematic
1152834829 M * Bertl did you try to run the rail stuff (as is) on a non-vserver kernel=
1152834834 M * Bertl s/=/?
1152834847 M * juggo not yet but I may
1152834856 M * Bertl maybe just use that and chroot()
1152834867 M * juggo I also may see if we have a comparable motherboard /cpu to swap in
1152834879 M * Bertl how many machines are involved in the lockups?
1152834879 M * juggo and try to narrow down whether it's a hardware issue
1152834911 M * juggo 3 now, but one only for the first time last night, in other words, has been running the same kernel and vservers for a month or 2, no problems until last night when it froze
1152834921 J * mire ~mire@156-166-222-85.COOL.ADSL.VLine.verat.net
1152834940 M * Bertl anything you changed on that machine shorty before last night?
1152834943 M * Bertl wb mire!
1152834946 M * juggo and the only change I'm aware of was setting up a rails vserver on that box
1152834957 M * Bertl ah, okay, sounds good then ...
1152834998 M * doener http://paste.linux-vserver.org/181 -- with frame pointer
1152835003 M * doener http://paste.linux-vserver.org/182 -- without frame pointer
1152835016 M * juggo I suppose there were also other package update sin some of the vservers running etch
1152835019 M * Bertl juggo: IMHO the best approach (if you can spare the machine time) would be to have one machine run a non-vserver debian kernel (identical to the patched one in version and setup) with a chroot()
1152835038 M * Bertl juggo: and another one with a vaniller (mainline 2.6.17.4) with vserver and a rail guest
1152835045 M * Bertl *vanilla
1152835058 J * phedny ~mark@volcano.p-bierman.nl
1152835062 M * Bertl if both crash, you have a kernel/hardware issue
1152835074 M * Bertl if the vanilla one survives, you have a debian issue
1152835082 M * doener Bertl: both should work AFAICT
1152835093 M * Bertl if the debian one survives, you have a linux-vserver issue :)
1152835123 M * Bertl if both survive, then the patched kernel is borked
1152835132 M * daniel_hozac doener: i guess we really should be testing with a _syscall6.
1152835147 M * doener Bertl: what does "scnr" mean in the arch descriptions? I guess that's not "sorry could not resist", right? :)
1152835173 M * Bertl syscall number
1152835185 M * juggo yes I'll have to talk with others but an approach like that is probably what will happen