Back to Home / #uml / 2005 / 04 / Prev Day | Next Day
#uml IRC Logs for 2005-04-15

---Logopened Fri Apr 15 00:00:59 2005
00:08--- ---> hfb [] has joined #uml
00:18mithro yay!
00:45Newsome mithro: fix your mysql problem?
00:47mithro yeah
00:47mithro damn tls
00:48Newsome yeah
00:48Newsome mv /lib/tls /lib/tls.broken
01:00--- <<-- mithro [~tim@] has quit (Ping timeout: 480 seconds)
01:27--- <<-- hfb [] has quit (Quit: Client exiting)
01:31--- ---> vuLcruM [~Amir@] has joined #uml
01:32--- <--- vuLcruM [~Amir@] has left #uml ()
01:34--- <<-- Newsome [] has quit (Quit: Leaving)
02:58--- ---> shehjar [~shehjar@] has joined #uml
03:01--- ---> leighbb [~leigh@] has joined #uml
03:19--- <<-- peter [~braam@] has quit (Ping timeout: 480 seconds)
03:28--- ---> peter [~braam@] has joined #uml
03:39--- ---> braam [~braam@] has joined #uml
03:42--- ---> braam_ [~braam@] has joined #uml
03:43--- ---> Mephisto_ [] has joined #uml
03:45--- <<-- Mephisto [] has quit (Ping timeout: 480 seconds)
03:45--- <<-- leighbb [~leigh@] has quit (Ping timeout: 480 seconds)
03:46--- <<-- peter [~braam@] has quit (Ping timeout: 480 seconds)
03:49--- <<-- braam [~braam@] has quit (Ping timeout: 480 seconds)
04:58--- ---> maisheri [] has joined #uml
05:09--- <<-- maisheri [] has quit (Quit: Leaving)
05:10--- ---> maisheri [] has joined #uml
05:18--- ---> alx_ [] has joined #uml
05:19--- <<-- gmcfadde [] has quit (Ping timeout: 480 seconds)
05:22--- <<-- shehjar [~shehjar@] has quit (Read error: Operation timed out)
05:34--- ---> shehjar [] has joined #uml
05:35--- <<-- shehjar [] has quit (Quit: )
05:35--- ---> shehjar [] has joined #uml
05:37--- <<-- shehjar [] has quit (Quit: )
05:59--- ---> shehjar [] has joined #uml
06:06--- <<-- braam_ [~braam@] has quit (Ping timeout: 480 seconds)
06:21--- ---> leighbb [~leigh@] has joined #uml
06:45--- ---> rus [] has joined #uml
06:47--- ---> hdkiller [hdkiller@] has joined #uml
06:47hdkiller hello
06:48hdkiller I went into trouble setting up the network between the host and the uml. If i try to get the interface up, that's works, but when i try to ping the host, it's hangs up
06:49hdkiller i tring whit a tuntap device btw
06:49hdkiller but if i do it whit uml_switch it's also hangs
06:49hdkiller uml_switch for unix socket of cors..
06:52--- <<-- jvds [] has quit (Ping timeout: 480 seconds)
06:59hdkiller ifconfig lo helped..
06:59hdkiller now works :|
07:12--- <<-- leighbb [~leigh@] has quit (Ping timeout: 480 seconds)
07:51--- <<-- DEac- [] has quit (Ping timeout: 480 seconds)
08:04--- ---> DEac- [] has joined #uml
08:10--- ---> da-x_ [] has joined #uml
08:55--- ---> braam_ [~braam@] has joined #uml
08:59--- ---> hfb [] has joined #uml
09:01--- ---> gmcfadde [] has joined #uml
09:04--- <<-- maisheri [] has quit (Quit: Leaving)
09:11hdkiller sh-2.05a# ping -c 1
09:11hdkiller PING ( 56 data bytes
09:11hdkiller Child 6164 exited with signal 11
09:11hdkiller ????
09:13--- <<-- shehjar [] has quit (Read error: Operation timed out)
09:13--- ---> rghf__ [] has joined #uml
09:19--- ---> bodo [~bo@] has joined #uml
09:20bodo hi all
09:20--- <<-- rus [] has quit (Ping timeout: 480 seconds)
09:21hdkiller hi bodo
09:22hdkiller do u familiar whit uml's networking? i got this when i try to ping my host os
09:22hdkiller sh-2.05a# ifconfig eth0
09:22hdkiller sh-2.05a# ping -c 1
09:22hdkiller PING ( 56 data bytes
09:22hdkiller Child 6420 exited with signal 11
09:29bodo hdkiller: sorry, I'm not the one to ask about networking
09:34hdkiller i think actualy i have something different problem..
09:34hdkiller Why this: Child 6420 exited with signal 11
09:43--- <<-- da-x_ [] has quit (Read error: Connection reset by peer)
09:53--- <<-- Basic [] has quit (Quit: Leaving)
09:56--- <<-- gmcfadde [] has quit (Ping timeout: 480 seconds)
10:00--- ---> AquaJo [] has joined #uml
10:00--- <<-- ElectricElf [] has quit (Remote host closed the connection)
10:01--- ---> ElectricElf [] has joined #uml
10:17--- ---> orospakr [] has joined #uml
10:31--- ---> Basic [] has joined #uml
10:34--- ---> alex234 [] has joined #uml
10:38--- <--- alex234 [] has left #uml ()
10:41--- ---> Newsome [] has joined #uml
11:16--- ---> shehjar [~shehjar@] has joined #uml
11:23--- ---> gmcfadde [] has joined #uml
11:28--- ---> jdike [] has joined #uml
11:28jdike hi guys
11:29bodo Hi jdike
11:30gmcfadde Hi All.
11:30gmcfadde I am having a prolem with the config system.
11:31jdike Hi bodo
11:31jdike bodo: how's 390 coming along?
11:31gmcfadde I get the error message "CONFIG_X86_L1_CACHE_SHIFT undeclared here"
11:31gmcfadde I have used the ARCH=um for everything.
11:31gmcfadde I am using the the kernel from
11:32gmcfadde but I get the same error with a slightly different kernel and uml patch
11:32gmcfadde Is there a good way of solving this? (Dis some searching on deja and did not find this issue too often)
11:33jdike gmcfadde: you copied arch/um/defconfig to .config before doing anything?
11:33bodo jdike: have been busy on other projects yesterday, so I'm still trying to catch the tt-problem
11:34gmcfadde jdike: no. Is that the problem?
11:34bodo jdike: I'm wondering, why there is no answer to my "change-request" for s390-mainline.
11:49--- <<-- schlumpf3 [] has quit (Quit: Client exiting)
11:52--- ---> G2 [~ghenry@] has joined #uml
11:53--- <--- G2 [~ghenry@] has left #uml ()
11:58gmcfadde jdike: no joy. Still same problem
11:59* jdike finishes filling in tax forms
11:59jdike gmcfadde: after doing an mrproper?
11:59gmcfadde jdike: No. I did a clean, make menuconfig ARCH=um and then make linux ARCH=um
12:00gmcfadde I will try a mrprpoer
12:03jdike bodo: I've been cleaning up the patches
12:03jdike bodo: especially the skas stuff, for merging into mainline
12:09--- ---> braam [~braam@] has joined #uml
12:12bodo jdike: skas0?
12:12--- <<-- Basic [] has quit (Quit: Leaving)
12:13* gmcfadde successfully compiled. Thanks jdike
12:16--- <<-- braam_ [~braam@] has quit (Ping timeout: 480 seconds)
12:16jdike bodo: yeah, skas0
12:17bodo jdike: neat!
12:30--- ---> itamarjp [] has joined #uml
12:35bodo jdike: now I have a stacktrace of the process, that has gone but is scheduled again
12:36bodo jdike: there is absolutely nothing strange with it. it siply calls sys_exit_group
12:36jdike bodo: hmmm
12:36jdike bodo: but then it is somehow scheduled again?
12:37jdike bodo: strange
12:37bodo jdike: and one further process calls sys_exit_group before the problem occurs
12:37jdike bodo: what process is it? Is that consistent?
12:38bodo jdike: I don't know, what process it is, here is the end of the trace:
12:38bodo 13533 1113586368.453342 19647: stk=6099fd88, addr=60022dda (sig_handler_common_tt)
12:38bodo 13534 1113586368.453511 19647: stk=6099fe08, addr=60037aea (sig_handler)
12:38bodo 13535 1113586368.453557 19647: done
12:38bodo 13536 1113586368.839899 19651: stk=6099fa18, addr=60020b0c (exit_thread_tt)
12:38bodo 13537 1113586368.840093 19651: stk=6099fa90, addr=6001b226 (exit_thread)
12:38bodo 13538 1113586368.840155 19651: stk=6099faf8, addr=60047b58 (do_exit)
12:38bodo 13539 1113586368.840207 19651: stk=6099fb80, addr=60047e0e (do_group_exit)
12:38bodo 13540 1113586368.840259 19651: stk=6099fbf8, addr=60047ee6 (sys_exit_group)
12:38bodo 13541 1113586368.840310 19651: stk=6099fc58, addr=600217c0 (execute_syscall_tt)
12:38bodo 13542 1113586368.840360 19651: stk=6099fcc8, addr=60021848 (syscall_handler_tt)
12:38bodo 13543 1113586368.840416 19651: stk=6099fd28, addr=600394e0 (usr2_handler)
12:38bodo 13544 1113586368.840468 19651: stk=6099fd88, addr=60022dda (sig_handler_common_tt)
12:38bodo 13545 1113586368.840520 19651: stk=6099fe08, addr=60037aea (sig_handler)
12:38bodo 13546 1113586368.840564 19651: done
12:38bodo 13547 1113586368.868357 19517: stk=61e5fa18, addr=60020b0c (exit_thread_tt)
12:38bodo 13548 1113586368.868494 19517: stk=61e5fa90, addr=6001b226 (exit_thread)
12:38bodo 13549 1113586368.868555 19517: stk=61e5faf8, addr=60047b58 (do_exit)
12:38bodo 13550 1113586368.868613 19517: stk=61e5fb80, addr=60047e0e (do_group_exit)
12:38bodo 13551 1113586368.868671 19517: stk=61e5fbf8, addr=60047ee6 (sys_exit_group)
12:38bodo 13552 1113586368.868727 19517: stk=61e5fc58, addr=600217c0 (execute_syscall_tt)
12:38bodo 13553 1113586368.868782 19517: stk=61e5fcc8, addr=60021848 (syscall_handler_tt)
12:38bodo 13554 1113586368.868842 19517: stk=61e5fd28, addr=600394e0 (usr2_handler)
12:38bodo 13555 1113586368.868898 19517: stk=61e5fd88, addr=60022dda (sig_handler_common_tt)
12:38bodo 13556 1113586368.868954 19517: stk=61e5fe08, addr=60037aea (sig_handler)
12:39bodo 13557 1113586368.869004 19517: done
12:39bodo 13558 1113586368.972566 19515: stk=605aba18, addr=60020b0c (exit_thread_tt)
12:39bodo 13559 1113586368.972696 19515: stk=605aba90, addr=6001b226 (exit_thread)
12:39bodo 13560
12:39bodo jdike: sorry, it's trucated, but you can see the relevant info.
12:39bodo jdike: the problem happens with process 19517, which is the host-pid
12:40--- <<-- shehjar [~shehjar@] has quit (Quit: shehjar)
12:40bodo jdike: this is the message, that currently replaces the panic in my kernel:
12:40bodo trying to write already closed switch_pipe: from-pid=15761, to-pid=19517
12:41jdike bodo: that process should have dequeued from the scheduler when it exited
12:41jdike bodo: so that would be something to check
12:42jdike bodo: its state should be TASK_DEAD or TASK_ZOMBIE or something similar
12:42bodo jdike: check the run queue?
12:42jdike bodo: see if it's on a runqueue
12:42jdike bodo: p->run_list
12:43bodo jdike: the problem is, when I can see the problem, the task may be reused already ...
12:43--- <--- Newsome [] has left #uml (Leaving)
12:43jdike bodo: that's what logging is for
12:44jdike bodo: you wait for the problem to happen, then mine the log
12:44jdike bodo: and the process being reused is an interesting possibility
12:45bodo jdike: I log in exit_thread_tt, that would be the right place?
12:45jdike bodo: maybe somehow, the new process didn't get initialized totally
12:45jdike bodo: for what?
12:45bodo jdike: for logging the additional info also
12:46jdike bodo: for checking its state, I think so
12:46jdike bodo: for checking for reuse, copy_thread_tt would be good
12:47bodo jdike: how check this?
12:47jdike bodo: exit_thread_tt is good for checking the run_list
12:47jdike bodo: just print the task_struct when you see the problem, and on each exit
12:48jdike bodo: and log it in copy_thread_tt
12:48jdike bodo: if there's consistently a reuse before the crash, that's a real big clue
12:48bodo jdike: if I print too much on exit, the problems seems to go away
12:48jdike bodo: when using log_info?
12:49bodo jdike: yes. I removed some prints, then it happened again. Maybe random, maybe not
12:49jdike bodo: hmmm
12:49jdike bodo: well, there's stuff there you don't need any more, like the stack stuff
12:49jdike bodo: so you should be able to get the info you need without increasing the loggin
12:50bodo jdike: I agree, we now know, there is no problem with the call-trace
13:00bodo jdike: exitin task is set to ZOMBIE and removed from runqueue *after* exit_thread
13:01bodo jdike: this is a piece of do_exit:
13:01bodo exit_namespace(tsk);
13:01bodo exit_thread();
13:01bodo exit_keys(tsk);
13:01bodo if (group_dead && tsk->signal->leader)
13:01bodo disassociate_ctty(1);
13:01bodo module_put(tsk->thread_info->exec_domain->module);
13:01bodo if (tsk->binfmt)
13:01bodo module_put(tsk->binfmt->module);
13:01bodo tsk->exit_code = code;
13:01bodo exit_notify(tsk);
13:01bodo #ifdef CONFIG_NUMA
13:01bodo mpol_free(tsk->mempolicy);
13:01bodo jdike: state change happens in exit_notify()
13:03jdike bodo: and exit_thead is where the pipes are closed?
13:03bodo jdike: yes.
13:04jdike bodo: that shouldn't be a problem - that code looks atomic wrt the scheduler
13:05bodo jdike: but there must be a problem, as exit_notify() *does* the changes
13:06bodo jdike: else, there might be erroneously 2 processes running at the same time
13:06jdike bodo: you think it's being scheduled in between?
13:06jdike bodo: between exit_thread and exit_notify?
13:07bodo jdike: I have no other idea, but I don't know, why this could happen.
13:07jdike bodo: if you have a theory, it's easy to check, just put logging in the right places
13:08jdike bodo: it's coming up with the theory that's hard
13:09bodo jdike: I'm writing a magic fo the pipe_fd in exit_thread_tt.
13:09bodo jdike: I could write another in exit_notify
13:09bodo jdike: if I see the exit_thread magic, it's interrupted anyhow
13:10bodo jdike: if I see exit_notify's magic, it's reused
13:10jdike bodo: yup
13:31--- ---> G2 [~ghenry@] has joined #uml
13:32--- <<-- G2 [~ghenry@] has quit (Quit: )
13:46--- ---> Newsome [] has joined #uml
13:50bodo jdike: the process logs in exit_thread_tt, but doesn't reach the end of exit_notify()
13:51bodo jdike: at the end of exit_thread, run_list still is valid, exit_code is set
13:51jdike bodo: then it must have scheduled
13:52jdike bodo: a stack from that would be very interesting
13:52bodo jdike: a stack from "to" in switch_to_tt?
13:53jdike bodo: a stack from "from" where "from" is between exit_thread and exit_notify
13:55bodo jdike: I know, which process has failed, when switch_to_tt is called with "to" being a pointer to it
13:56bodo jdike: so maybe I could take a stack from it at that moment
13:57jdike bodo: "from" is the one running, not "to"
13:57jdike bodo: so you can't use __builtin_return_value, if that's what you're doing now
13:58bodo jdike: yeah, you are right, and I can't use ptrace, since "from" already has killed itself
13:59bodo jdike: err: to is exiting and might have killed itself
14:01bodo jdike: I could add a "stack at switch_to" field to thread and write the stack pointer to it
14:01bodo jdike: if the task is "from" in switch_to
14:02jdike bodo: yeah
14:02bodo jdike: then, I can take the stack trace of the failing "to"
14:05--- <<-- hfb [] has quit (Quit: Client exiting)
14:06--- ---> hfb [] has joined #uml
14:08hdkiller (Hello, and sorry for asking, but why could be this "Child 19194 exited with signal 11" when a process try to reach the exteral network?)
14:09jdike hdkiller: old UML?
14:10hdkiller i used the patch for, but the debian package also did this..
14:10hdkiller i see it's sets up the tuns and the routing.. so i don't really get any error message
14:13hdkiller guest is an 2.6.11-rc4... and it's sets up tap devices..
14:13jdike hdkiller: OK, that's not very old
14:14hdkiller what should i do? :|
14:17jdike hdkiller: what exactly do you do?
14:19hdkiller linux eth0=tuntap,,, con0=fd:0,fd:1 con=pty root=/dev/root rootflags=/ rootfstype=hostfs ubd1=doo init=/usr/lib/rootstrap/builder devfs=mount rsworkdir=/home/uml
14:20hdkiller trying to install debian whit rootstrap
14:20--- ---> tierra [] has joined #uml
14:20jdike hdkiller: is there a simple network thing you can do to make it happen?
14:21hdkiller ping also produces that
14:21jdike hdkiller: you run ping, and UML dies?
14:21hdkiller if i set up the loopback device for i can ping that, and it's works
14:21hdkiller if i start pinging the endpoint of the tun device in UML it's also works
14:22hdkiller but if i want to ping the other endpoint it's crash whit the message i mentoined above
14:27jdike hdkiller: every time?
14:29hdkiller yeah
14:29hdkiller i think i have some trouble whit the guest os
14:30jdike hdkiller: If it's dying like that, I'd say that's trouble
14:31hdkiller sh-2.05a# ifconfig eth0
14:31hdkiller tuntap_open_tramp : didn't receive a message
14:31hdkiller Too few arguments to tuntap_up
14:31hdkiller tuntap_open_tramp failed - err = 22
14:31hdkiller SIOCSIFFLAGS: Invalid argument
14:31hdkiller sh-2.05a# ifconfig eth0
14:31hdkiller eth0 Link encap:Ethernet HWaddr FE:FD:C0:A8:64:01
14:31hdkiller inet addr: Bcast: Mask:
14:31hdkiller BROADCAST MULTICAST MTU:1500 Metric:1
14:31hdkiller i never got a message like that before, but i see i had tap devices from 0 to 6
14:32jdike hdkiller: you could update your uml_utilities
14:32hdkiller tunctl -d tap5
14:32hdkiller TUNSETIFF: Device or resource busy
14:33hdkiller that's strange.. no uml running
14:33hdkiller btw, i upgraded when i switched to ..
14:34hdkiller and strange becouse i don't get this message if i restart uml anymore, but i get
14:34hdkiller sh-2.05a# ifconfig eth0
14:34hdkiller eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
14:34hdkiller and the wraper don't try to set up a new tun device..
14:35hdkiller but why this TUNSETIFF: Device or resource busy messages, while nothing on the tap devices?
14:43bodo jdike: kernel still is compiling, as I'm using a quite old and slow mainframe currently
14:43bodo jdike: but maybe, this piece of code is the reason for the problems:
14:43bodo tsk->it_virt_value = cputime_zero;
14:43bodo tsk->it_prof_value = cputime_zero;
14:43bodo write_unlock_irq(&tasklist_lock);
14:43bodo list_for_each_safe(_p, _n, &ptrace_dead) {
14:43bodo list_del_init(_p);
14:43bodo t = list_entry(_p,struct task_struct,ptrace_list);
14:43bodo release_task(t);
14:43bodo }
14:44bodo /* If the process is dead, release it - nobody will wait for it */
14:44bodo if (state == EXIT_DEAD)
14:44bodo release_task(tsk);
14:44bodo /* PF_DEAD causes final put_task_struct after we schedule. */
14:44bodo preempt_disable();
14:44bodo tsk->flags |= PF_DEAD;
14:44bodo }
14:44bodo jdike: it's the end of exit_notify()
14:48jdike bodo: is there a schedule() in there anywhere?
14:49bodo jdike: no, but interrupts might come in
14:50bodo jdike: I didn't check release_task exactly
14:52jdike bodo: I was thinking about that, but that can schedule only if it thinks userspace was interrupted
14:56bodo jdike: yeah, UML isn't preemptive in kernel
14:58jdike bodo: right
15:14--- <<-- DEac- [] has quit (Quit: Verlassend)
15:15hdkiller ( lsmod => tun 9984 9 ... tunctl -d tap1 => TUNSETIFF: Device or resource busy ... lsof /dev/net/tun | wc -l => 0 :| )
15:15jdike hdkiller: what's the host?
15:16hdkiller pure 2.6.11-rc4
15:16bodo jdike: now the kernel is ready, but the problem no longer happens
15:17bodo jdike: sometimes it needs some patience
15:18jdike hdkiller: that looks like a tun bug
15:19hdkiller i think so.. :|
15:20--- ---> DEac- [] has joined #uml
15:32--- <<-- orospakr [] has quit (Quit: Leaving)
15:50--- <<-- loko_ [rbrown@] has quit (Read error: Connection reset by peer)
15:50--- ---> loko [~rbrown@] has joined #uml
16:28bodo jdike: currently I can't reproduce the problem.
16:28jdike bodo: hmmph
16:28bodo jdike: it's very late now. I'll continue on Monday
16:28jdike bodo: what did you do to change it?
16:29bodo jdike: I inserted unsigned long switch_stack into tt-regs
16:29jdike bodo: that's it
16:29jdike ?
16:30bodo jdike: then, I stored from's stack-pointer in switch_to_tt into switch_stack
16:30bodo jdike: if the problem occurs, I would try to dump to's stack
16:30jdike bodo: yeah
16:31jdike bodo: oh well, go home :-)
16:31bodo jdike: my changes altered the position of the code in memory, as I shifted my stack-dump
16:32bodo jdike: to the beginning of arch/um/kernel/tt/process_kern.c, for use in switch_to_tt
16:32bodo jdike: maybe, that changes the timing?
16:33jdike bodo: I have a hard time believing that
16:33jdike bodo: but who knows?
16:33bodo jdike: we'll see on Monday. Bye :-)
16:33jdike bye
16:33--- <--- bodo [~bo@] has left #uml (Verlassend)
16:44--- <<-- loko [~rbrown@] has quit (Read error: Connection reset by peer)
16:46--- ---> loko [~rbrown@] has joined #uml
16:58--- <<-- lilo [] has quit (Quit: bbiab)
17:22--- <<-- gmcfadde [] has quit (Quit: Leaving)
17:29--- <<-- hdkiller [hdkiller@] has quit (Remote host closed the connection)
17:34--- ---> Darky_ [] has joined #uml
17:35--- <<-- Darky [] has quit (Read error: Connection reset by peer)
17:37Darky_ shubidu ;)
17:37--- User: *** Darky_ is now known as Darky
17:56--- <<-- Newsome [] has quit (Quit: Leaving)
18:38--- ---> Newsome [] has joined #uml
18:53--- <<-- tierra [] has quit (Quit: Everybody wants to go to heaven, but nobody wants to die.)
18:56--- ---> tierra [] has joined #uml
19:08--- <<-- AquaJo [] has quit (Quit: Leaving)
19:43--- <<-- hfb [] has quit (Quit: Client exiting)
20:05--- ---> mithro [] has joined #uml
20:19--- <<-- itamarjp [] has quit (Quit: )
20:28--- ---> Nem^^ [] has joined #uml
20:32--- <<-- Nem^ [] has quit (Read error: Operation timed out)
20:54--- ---> Electric1lf [] has joined #uml
21:07--- <<-- ElectricElf [] has quit (Read error: Connection timed out)
21:18--- User: *** Electric1lf is now known as ElectricElf
21:42--- <<-- Cowboy_ [~Cowboy@] has quit (Ping timeout: 480 seconds)
21:56--- <<-- tierra [] has quit (Quit: Everybody wants to go to heaven, but nobody wants to die.)
22:25--- ---> nextime_ [] has joined #uml
22:31--- <<-- mithro [] has quit (Read error: Operation timed out)
22:32--- <<-- nextime [] has quit (Ping timeout: 480 seconds)
22:51--- <<-- jdike [] has quit (Quit: Leaving)
22:59--- <--- VS_ChanLog [] has left #uml (Rotating Logs)
22:59--- ---> VS_ChanLog [] has joined #uml
22:59--- ---> mithro [] has joined #uml
23:04--- ---> Cowboy_ [] has joined #uml
23:13--- ---> tierra [] has joined #uml
23:13--- ---> peter [~braam@] has joined #uml
23:19--- <<-- braam [~braam@] has quit (Ping timeout: 480 seconds)
23:21--- ---> JViz` [] has joined #uml
23:21--- ---> itamarjp [] has joined #uml
23:21itamarjp hi
23:24--- <<-- mithro [] has quit (Read error: Operation timed out)
23:24--- <<-- JViz [] has quit (Ping timeout: 480 seconds)
23:46--- <<-- tierra [] has quit (Read error: Connection reset by peer)
23:46--- ---> tierra [] has joined #uml
23:48--- <<-- itamarjp [] has quit (Quit: )
23:53--- <<-- tierra [] has quit (Quit: Don't hate yourself in the morning -- sleep til noon.)
---Logclosed Sat Apr 16 00:00:35 2005