TheGrebs.com:IRC Logs:#uml:2007:02:15

---	Log	opened 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
---	Log	closed Fri Feb 16 00:00:23 2007