Back to Home / #uml / 2007 / 02 / Prev Day | Next Day
#uml IRC Logs for 2007-02-15

---Logopened Thu Feb 15 00:00:35 2007
01:03|-|less [~less@static-mum-203.94.229.222.mtnl.net.in] has joined #uml
01:14|-|jeroenh [~Jeroen@doc.je-ju.net] has joined #uml
03:09|-|mode2_ [~mode2@ABordeaux-256-1-24-44.w90-11.abo.wanadoo.fr] has joined #uml
03:14|-|mode2 [~mode2@ABordeaux-256-1-41-81.w90-11.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
03:27|-|tyler [~tyler@89.98.142.26] has joined #uml
03:40|-|jeroenh [~Jeroen@doc.je-ju.net] has quit [Quit: jeroenh]
04:30|-|writerz_ [~mode2@ABordeaux-256-1-119-159.w90-16.abo.wanadoo.fr] has joined #uml
04:35|-|mode2_ [~mode2@ABordeaux-256-1-24-44.w90-11.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
04:55|-|tyler [~tyler@89.98.142.26] has quit [Ping timeout: 480 seconds]
05:13|-|tyler [~tyler@89.98.142.26] has joined #uml
07:10|-|baroni [~baroni@c934afdb.virtua.com.br] has joined #uml
07:18|-|baroni [~baroni@c934afdb.virtua.com.br] has quit [Ping timeout: 480 seconds]
07:28|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has joined #uml
07:58|-|baroni [~baroni@c934afdb.virtua.com.br] has joined #uml
08:25|-|tyler [~tyler@89.98.142.26] has quit [Remote host closed the connection]
08:26|-|baroni [~baroni@c934afdb.virtua.com.br] has quit [Quit: :wq]
08:29|-|tyler [~tyler@89.98.142.26] has joined #uml
09:24|-|infowolfe_ [~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net] has joined #uml
09:24|-|infowolfe [~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net] has quit [Ping timeout: 480 seconds]
09:42|-|tyler [~tyler@89.98.142.26] has quit [Remote host closed the connection]
09:46|-|tyler [~tyler@89.98.142.26] has joined #uml
10:06|-|less [~less@static-mum-203.94.229.222.mtnl.net.in] has quit [Read error: Connection reset by peer]
10:09|-|jdike [~jdike@pool-71-174-247-179.bstnma.fios.verizon.net] has joined #uml
10:09<jdike>Hi guys
10:22|-|hfb [~hfb@pool-71-118-248-190.lsanca.dsl-w.verizon.net] has joined #uml
10:26|-|hfb [~hfb@pool-71-118-248-190.lsanca.dsl-w.verizon.net] has left #uml []
10:32|-|baroni [~baroni@c934afdb.virtua.com.br] has joined #uml
10:33|-|the_hydra [~mulyadi@125.164.96.251] has joined #uml
10:34<the_hydra>hi
10:41|-|baroni [~baroni@c934afdb.virtua.com.br] has quit [Ping timeout: 480 seconds]
10:46<kokoko1>hiya
10:47<the_hydra>yo kokoko1
10:48<the_hydra>jdike: does UML change the way I/O scheduler work?
10:48<jdike>no
10:49<kokoko1>the_hydra, !
10:49<the_hydra>jdike: ok thanks
10:51<the_hydra>kokoko1: what's up? any hack today?
10:53<kokoko1>no :)
10:53<kokoko1>you tell
10:56<the_hydra>jdike: jeff, I am little bit puzzled about ptrace proxy, perhaps you can shed some light on how it works? are you intercepting ptrace sys call or something like that?
10:57<jdike>you really want to know about that?
10:57<jdike>it's hideous
10:57<the_hydra>try me
10:58<the_hydra>perhaps a big picture 1st, so it can be used as my guideline when jumping into the codes
11:04<jdike>OK, the basic problem is, you want to run gdb on a process which is already under ptrace
11:05<the_hydra>ok
11:05<jdike>that can't work because a process can only have one ptrace parent at a time
11:05<the_hydra>correct
11:06<jdike>so, what you do is have the current ptracer also ptrace gdb with the intent of faking gdb into believing that it is controlling the process
11:06<jdike>so, it does system call interception on gdb, intercepting things like wait and ptrace
11:07<jdike>it reads ptrace requests from gdb, executes them itself, and feeds the results back into gdb
11:07<jdike>calls to wait are also emulated, and the results faked to keep gdb happy
11:07<jdike>OK?
11:08<the_hydra>let me re-read
11:09<the_hydra>so basically this is done to make gdb "happy"..and it feels it is controlling the target process
11:09<the_hydra>while in fact, it is not...
11:09<jdike>yes
11:09<jdike>exactly
11:10<the_hydra>ok
11:10<the_hydra>so that is the big picture...
11:10<jdike>but this is only relevant to tt mode, which isn't relevant any more
11:10<the_hydra>so far I thought it was somekind of ptrace multiplexer
11:11<the_hydra>that is, a gate that allows gdb to actually hook
11:11<the_hydra>but also the real UML kernel is also allowed to hook
11:13<the_hydra>jdike: hm, so in skas mode, gdb directly hook to target process?
11:13<jdike>yes
11:13<jdike>this is completely unnecessary
11:15<the_hydra>doesn't that make the UML kernel lose the control?
11:16<jdike>no
11:16<jdike>the only ptracing happening now is the UML kernel ptracing UML processes
11:17<jdike>the UML kernel itself is no longer under ptrace
11:18<the_hydra>hmmm
11:26[~]kokoko1 sit back
11:27<the_hydra>this is the part that confused me most, now UML kernel ptraces UML process... while once in tt mode it is ptraced...
11:27<the_hydra>because once in tt mode, it is all in the lower 3G space, so it needs to be ptraced?
11:28<the_hydra>while in SKAS, the "stub" replace the need of ptrace
11:45|-|tyler_ [~tyler@89.98.142.26] has joined #uml
11:46|-|tyler [~tyler@89.98.142.26] has quit [Ping timeout: 480 seconds]
11:52[~]kokoko1 have to upgrade 3 hosts and vms to FC5 --> FC6
11:53<kokoko1>3 * 4 = 12 Fedoras :-s
11:53[~]kokoko1 wonders what those digits means..
11:59<the_hydra>gtg jeff
11:59<the_hydra>and thanks for the info
11:59<the_hydra>ciao
11:59|-|the_hydra [~mulyadi@125.164.96.251] has quit [Remote host closed the connection]
12:07|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
12:39|-|tarsin [~rob@fyodor.hcoop.net] has joined #uml
13:40|-|baroni [~baroni@c934afdb.virtua.com.br] has joined #uml
14:05<infowolfe_>*waves @ jdike*
14:05<jdike>hey
14:08<infowolfe_>any fun new patches for me to test? :-p
14:08<jdike>I have something which doubles the speed of exec
14:11<infowolfe_>i'm still hoping for x86_64 skas3 :-p
14:11<jdike>why?
14:11<infowolfe_>why not?
14:11<jdike>it's not a magic UML accelerator
14:12<jdike>skas0 should be nearly as fast
14:12<jdike>Do you care where your performance comes from?
14:13<infowolfe_>well, i remember back in the 2.5.x days that when i had performance issues on my umls, that applying skas seemed to fix the same types of issues i saw a couple weeks ago
14:13<infowolfe_>not especially
14:13<infowolfe_>in fact, i could care less, as long as it doesn't take ~45s to pull up a screened console and another 30-45s to login
14:14<jdike>that's a problem, and one that I didn't see on your box
14:14<infowolfe_>by the time i gave you access, i didn't see it anymore either, since i was getting segfaults on the skas kernel
14:15<jdike>well, putting skas0 on the command line booted the thing up
14:15|-|baroni [~baroni@c934afdb.virtua.com.br] has quit [Remote host closed the connection]
14:24<jdike>caker, there?
14:33<tarsin>hey jdike, i am having problems compiling a UML 2.6.13 kernel. i searched google and found an irc log of you and someone else discussing it but i didn't see any solutions said about it..
14:33<tarsin>this is the error i am getting: http://pastebin.com/881599
14:34<tarsin>the host machine, where i am building the uml kernel, is fc6 with gcc 4.1.1
14:34<jdike>and there was a fix for that, but I don't remember when it went in
14:35|-|baroni [~baroni@c934afdb.virtua.com.br] has joined #uml
14:35|-|albertito [~net@dsl-201-219-69-170.users.telpin.com.ar] has quit [Read error: Connection reset by peer]
14:36<uroboros_>jdike: Hello. So I am going to test the yesterday's patch tonight. What would you suggest me to test it? I mean - what sort of test should I run to test point in the code that was patched? Ideas appreciated...
14:36<jdike>whatever you were doing
14:36<jdike>you had no problem reproducing it yesterday
14:37<uroboros_>I mean whether you know about anything to terse-test file descriptors code...
14:37<tarsin>jdike, do you have any recommendations for getting a 2.6.13 uml compiling? if at all possible i'd like to use the 2.6.13 kernel for consistency with some other things we're doing..
14:37<uroboros_>And the second thing, I need to solve the problem with /lib/tls
14:38<jdike>uroboros_, no recommendations
14:38<jdike>show me the error from that
14:38<uroboros_>jdike: ok, Iwill just run several servers (apache, squid etc.) in it, ok.
14:38<uroboros_>jdike: Yes, I will paste it in pastebin, of course. :)
14:39<tarsin>jdike, was that "no recommendations" intended for me? :)
14:39<jdike>no
14:39<uroboros_>jdike: Just give me a time to create new image...
14:39<jdike>tarsin, 2.6.13 is quite old
14:40|-|albertito [~net@dsl-201-219-68-244.users.telpin.com.ar] has joined #uml
14:43<caker>jdike: yo
14:45<jdike>you were seeing a crash in init_emergency_isa_pool, right?
14:46<caker>Yeah -- I pulled in "fix crash in block layer" before building 2.6.20 and all is well
14:47<jdike>yup, OK
14:48<jdike>just making sure you saw it
14:50<caker>thanky
14:57<uroboros_>jdike: Great.
14:57<uroboros_>jdike: It works with /lib/tls now as well. The patched this thing too.
14:58<jdike>heh
14:58<uroboros_>really, it was not working, now it is...
14:58<uroboros_>:-D
14:58<uroboros_>funny, isn't it?
14:58<uroboros_>This bug was real wtf :-)
14:59<caker>what action caused the UML to hang in the first place? Just booting it?
15:00<uroboros_>caker: any action, it was random...
15:00<caker>huh .. surprising I haven't run into it
15:00<uroboros_>2.6.20 both host an uml, perhaps your version is another...
15:01<caker>I have to run 2.6.16 on the host, or else my UML's hang right after "VFS: mounting root filesystem read-only"
15:01<caker>this isn't the same bug, is it?
15:01<uroboros_>can be
15:01<uroboros_>jdike: ?
15:02<caker>(this is the bug jdike said "something broke page fault handling generically")
15:02<jdike>don't think so
15:02<uroboros_>aha
15:02<jdike>I had access to a host on which that happened
15:02<jdike>now I don't any more
15:02<caker>jdike: x86?
15:02<jdike>yup
15:02<caker>want another one?
15:02<jdike>yup
15:02<uroboros_>jdike: btw, can you make a patch against 2.6.20 (with no warnings etc, a clean(er) one)
15:03<caker>jdike: ok, give me a day or two
15:03<jdike>caker, OK
15:03<caker>I get to drive to Atlanta tomorrow to install new servers at a brand new datacenter!
15:03<jdike>uroboros_, the one I cc-ed you is going to andrew
15:03<jdike>so it's pretty official
15:03<uroboros_>jdike: when?
15:03<jdike>this morning
15:03<uroboros_>jdike: strange, I did not receive it yet:(
15:04<jdike>I gotta get going...
15:04<uroboros_>jdike: can you send it again to mjf@ligatura.org ?
15:04<jdike>I'll check that later
15:04<jdike>I sent it to uml@...
15:05|-|jdike [~jdike@pool-71-174-247-179.bstnma.fios.verizon.net] has quit [Quit: Leaving]
15:05<uroboros_>jdike: I know, but I am not admin of the mailserver, so I can not check, the mjf@ works well..., usually I can use anything before but for some reasons some fo the addresses does not work. This must be the case. :( I will beat the admin when I see him (he's not online at the very moment) :(
15:08<uroboros_>That is really strange, I did not receive it all. Did you obtain some error message back?
15:08<uroboros_>s/it all/it at all/
15:08<uroboros_>Huh. :(
15:09<uroboros_>Nevermind... the administrator is one friend of mine, but sometimes he's tuning the mailserver too much. I think it must have been filtered somewhere. :-)
15:20<uroboros_>Ah, here it is... :) It was not my friend's mailserver but my spam-assassin ;) LOL
15:20<uroboros_>I got the patch now, thanks.
16:07|-|Netsplit osmotic.oftc.net <-> saturn.oftc.net quits: mike_m, uroboros_
16:07|-|Netsplit over, joins: uroboros_, mike_m
16:20|-|uroboros_ [~uroboros@r5bb59.net.upc.cz] has quit [Quit: leaving]
16:22|-|uroboros [~uroboros@r5bb59.net.upc.cz] has joined #uml
16:38<uroboros>caker: jdike has left?
16:39<uroboros>caker: because patching with the patch he submitted fails on 2.6.20
16:39<uroboros>nevermind, I will use the yesterday's patch, that worked.
17:24<caker>cool
17:28<tarsin>anyone know of a vanilla kernel that should compile against the UML tree?
17:29<tarsin>i've tried from 2.6.10 - 2.6.14.7 with no success
17:29<caker>tarsin: why such old kernels?
17:30<caker>I've never had trouble compiling 2.6, FWIW
17:30<tarsin>well orginially i wanted 2.6.13 because that is what we're using for all our platforms.. now i am just trying every kernel from 2.6.13 to find one that compiles..
17:30<caker>tarsin: one "gotcha" is if you ever run make without ARCH=um, you need to run "make mrproper" in that tree, or esle UML will fail to compile (be careful, mrproper blows away your .config)
17:30<tarsin>http://pastebin.com/881599 getting that error on all of them so far..
17:34<caker>huh .. I don't remember that
17:34<caker>I have 2.6-um kernels from 2.6.10 on up ( http://www.theshore.net/~caker/uml/kernels/ )
17:35<tarsin>yeah... i need to be able to build them unfortuntely... i need to patch some things in the ip stack
17:35<tarsin>(right now no patches are being applied)
17:35<caker>well, my suggestion is to go with 2.6.20 plus the "[UML] fix crash in block layer" small patch that's in the list archives
17:37<tarsin>ok i'll grab the vanilla 2.6.20 kernel.
17:37<caker>correction: 2.6.4 on up :)
17:37<tarsin>out of curiosity what gcc are you running?
17:37<tarsin>i've got fc6 installed.. it ships with 4.1.1
17:38<caker>3.3.3, from an old FC
17:38<tarsin>i am tempted to go back to a distro with a 3.4 gcc release.. ( it think that is the recommended compiler)
17:40<uroboros>caker: where to find the patch "[UML] fix crash in block layer" ?
17:47<uroboros>BTW: is there a way to sync cow file to the ubd?
17:58<caker>uroboros: http://permalink.gmane.org/gmane.linux.uml.devel/9947
17:58<caker>uroboros: yeah -- it's called uml_moo, or something, and I think it's in the uml-utilities package
18:09<tarsin>moooo
18:10<uroboros>caker: thanks a lot.
18:18<uroboros>One thing I really hate. Why not "uml-moo" or "uml-mconsole" but "uml_moo" and "uml_mconsole"? The "_" is quite unusual... :)\
18:19<uroboros>I always try to type "uml-<tab>" or so... :) Always.
18:20<uroboros>I will make me aliases. But still - this is quite unusual.
18:20<uroboros>I go sleep. Bye.
18:23<uroboros>Please, tell jdike that I did not see any problems after testing the UML with his patch. Thanks.
18:38|-|tyler_ [~tyler@89.98.142.26] has quit [Remote host closed the connection]
19:09|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
19:10|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
20:51|-|zap-zero [andi@v31521.1blu.de] has quit [Ping timeout: 480 seconds]
21:09|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
21:09|-|zap-zero [~andi@v31521.1blu.de] has joined #uml
21:19|-|zap-zero [~andi@v31521.1blu.de] has quit [Ping timeout: 480 seconds]
21:21|-|ram [~ram@pool-71-245-96-74.nycmny.fios.verizon.net] has joined #uml
21:42|-|zap-zero [andi@v31521.1blu.de] has joined #uml
21:47|-|albertito [~net@dsl-201-219-68-244.users.telpin.com.ar] has quit [Read error: Connection reset by peer]
22:15|-|zap-zero [andi@v31521.1blu.de] has quit [Ping timeout: 480 seconds]
22:17|-|zap-zero [andi@v31521.1blu.de] has joined #uml
22:38|-|Nem^1 [~Nem@dslb-084-056-252-180.pools.arcor-ip.net] has joined #uml
22:46|-|Nem^ [~Nem@dslb-084-056-234-151.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
22:46|-|Nem^1 changed nick to Nem^
22:58|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
22:58|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
23:13|-|ram [~ram@pool-71-245-96-74.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds]
23:22|-|baroni [~baroni@c934afdb.virtua.com.br] has quit [Quit: :wq]
23:30|-|ram [~ram@pool-71-245-96-74.nycmny.fios.verizon.net] has joined #uml
---Logclosed Fri Feb 16 00:00:23 2007