TheGrebs.com:IRC Logs:#uml:2005:05:17

---	Log	opened Tue May 17 00:00:04 2005
00:05	---	<<-- stmartin [~stmartin@ou075071.otago.ac.nz] has quit (Quit: stmartin)
00:27	---	<<-- itamarjp [lualele@terra-200-225-254-012.dynamic.idial.com.br] has quit (Quit: )
00:53	---	---> adam234 [adam234@DHCP-171-129.caltech.edu] has joined #uml
01:26	---	<<-- hfb [~hfb@adsl-69-231-91-105.dsl.irvnca.pacbell.net] has quit (Quit: Client exiting)
01:27	---	<<-- fo0bar [fo0bar@cromulent.colobox.com] has quit (Quit: switching my linode to solaris 10)
01:47	---	---> fo0bar [ryan@cromulent.colobox.com] has joined #uml
01:48	---	<--- Newsome [~sorenson@byu-gw.customer.csolutions.net] has left #uml (Leaving)
02:01	---	---> karsten_ [~karsten@host-66-81-223-236.rev.o1.com] has joined #uml
02:07	---	<<-- karsten [~karsten@host-66-81-218-22.rev.o1.com] has quit (Ping timeout: 480 seconds)
02:31	---	---> dunc [~dunc@gateway.ash.thebunker.net] has joined #uml
03:09	---	User: *** karsten_ is now known as karsten
05:08	---	---> commander [commander-@p54923D0A.dip.t-dialin.net] has joined #uml
05:15	---	---> telekinetic [~roxtar@202.83.43.52] has joined #uml
05:59	---	<<-- telekinetic [~roxtar@202.83.43.52] has quit (Quit: Leaving)
06:05	---	<<-- nessie [~nessie@lucifer.nerdfest.org] has quit (Ping timeout: 480 seconds)
06:10	---	---> nessie [~nessie@lucifer.nerdfest.org] has joined #uml
07:08	---	---> deac [~deac@xdsl-81-173-136-134.netcologne.de] has joined #uml
07:08	---	<<-- deac [~deac@xdsl-81-173-136-134.netcologne.de] has quit (Quit: )
07:08	---	---> DEac- [~deac@xdsl-81-173-136-134.netcologne.de] has joined #uml
07:09	---	<<-- DEac- [~deac@xdsl-81-173-136-134.netcologne.de] has quit (Remote host closed the connection)
08:15	---	---> Newsome [~sorenson@byu-gw.customer.csolutions.net] has joined #uml
08:19	---	User: *** Electric1lf is now known as ElectricElf
08:23	---	---> the_hydra [~a_mulyadi@202.147.200.25] has joined #uml
08:23	the_hydra	hello everyone
08:24	---	---> shehjar [~shehjar@129.94.1.232] has joined #uml
08:32	---	<<-- commander [commander-@p54923D0A.dip.t-dialin.net] has quit (Ping timeout: 480 seconds)
08:34	---	<<-- Newsome [~sorenson@byu-gw.customer.csolutions.net] has quit (Quit: Leaving)
08:35	---	---> DEac- [~deac@xdsl-213-168-107-94.netcologne.de] has joined #uml
09:09	---	<<-- DEac- [~deac@xdsl-213-168-107-94.netcologne.de] has quit (Quit: Verlassend)
09:14	---	<<-- schlumpf2 [~schlumpf@dsl-084-056-143-044.arcor-ip.net] has quit (Remote host closed the connection)
09:15	---	---> schlumpf [~schlumpf@dsl-084-056-143-044.arcor-ip.net] has joined #uml
09:17	---	---> commander [commander-@p549265F6.dip.t-dialin.net] has joined #uml
09:19	---	---> bodo [~bo@217.115.74.14] has joined #uml
09:19	bodo	Hi all
09:20	the_hydra	hello bodo
09:20	the_hydra	long time no see
09:20	bodo	the_hydra: hello. I'm busy on other projects, currently
09:21	the_hydra	oh I see
09:22	---	---> DEac- [~deac@xdsl-213-168-107-94.netcologne.de] has joined #uml
09:24	---	<<-- DEac- [~deac@xdsl-213-168-107-94.netcologne.de] has quit (Quit: )
09:27	the_hydra	bodo: open source project too?
09:29	---	<<-- shehjar [~shehjar@129.94.1.232] has quit (Quit: be back in an hour)
09:33	---	<<-- karsten [~karsten@host-66-81-223-236.rev.o1.com] has quit (Read error: Connection reset by peer)
09:35	---	---> Newsome [~sorenson@obelix.cs.byu.edu] has joined #uml
09:53	bodo	the_hydra: no, other stuff.
09:54	the_hydra	oh that, ok
10:02	the_hydra	gtg
10:03	---	<<-- the_hydra [~a_mulyadi@202.147.200.25] has quit (Quit: )
10:15	---	---> DEac- [~deac@xdsl-213-168-107-94.netcologne.de] has joined #uml
10:32	---	---> rus [~rghf@office.vaserv.com] has joined #uml
10:32	---	<<-- jvds [~rghf@office.vaserv.com] has quit (Read error: Connection reset by peer)
10:38	---	<<-- ElectricElf [~david@electricelf.chair.oftc.net] has quit (Remote host closed the connection)
10:43	---	---> telekinetic [~roxtar@202.83.43.52] has joined #uml
10:45	---	---> ElectricElf [~david@electricelf.chair.oftc.net] has joined #uml
11:00	---	---> jdike [~jdike@pool-141-154-228-134.bos.east.verizon.net] has joined #uml
11:00	jdike	who *
11:00	jdike	hi guys
11:00	Newsome	hi, jdike
11:10	---	<<-- tchan [~tchan@c-24-13-81-164.hsd1.il.comcast.net] has quit (Read error: Operation timed out)
11:10	bodo	jdike: Hi jdike
11:10	jdike	Hi Bodo
11:10	jdike	bodo: there was something I was going to ask you
11:10	jdike	bodo: but I forget what it was
11:11	bodo	jdike: about ubd deadlock?
11:11	jdike	bodo: yeah, that was it
11:11	jdike	bodo: I alleviated the problem, but didn't fix it
11:12	bodo	jdike: I still have no idea, how to fix this :-(
11:12	jdike	bodo: by passing much less across the pipe
11:12	jdike	bodo: now, only pointers go across instead of entire structures
11:13	bodo	jdike: what made me wonder, was the fact, that the pipe was full with 57 entries in both cases
11:13	jdike	bodo: I was wondering about that too
11:13	jdike	bodo: that seemed kind of small
11:13	bodo	jdike: the structures were very different in size
11:14	jdike	bodo: only one was deadlocked
11:14	bodo	jdike: no, both
11:14	jdike	bodo: the other pipe still had room
11:14	bodo	jdike: both writesrs of the pipes were sleeping in write()
11:15	bodo	jdike: so, both pipes must have been full
11:15	jdike	bodo: hmmm
11:15	bodo	jdike: I don't know much about those soccket-pipes
11:16	bodo	jdike: maybe, those hold enties instead of raw-data?
11:16	jdike	bodo: my current thinking is to maintain a list of requests
11:16	bodo	jdike: yes, I thought of that, too.
11:16	jdike	bodo: that the ubd driver adds to when it needs IO
11:17	jdike	bodo: and deletes from when a request is finished
11:17	---	---> tchan [~tchan@c-24-13-81-164.hsd1.il.comcast.net] has joined #uml
11:17	bodo	jdike: but how to synchronize sending of request with helper-thread
11:17	jdike	bodo: and the io thread walks, doing the requests
11:17	bodo	jdike: and helper-thread with intr
11:18	jdike	bodo: and the aio code would only write something down the pipe to the io thread when it thinks the io thread might be asleep, or about to sleep
11:19	bodo	jdike: Oh, lets have a atomic counter for the elements in the lists.
11:19	jdike	bodo: I don't think it needs to be atomic even
11:19	bodo	jdike: if the counter is counted up from 0 to 1, the pipe is written
11:21	bodo	jdike: if the writer counts it up, while the reader counts down, shouldn't it be atomic?
11:21	jdike	bodo: we have separate counters, queued and processed
11:21	jdike	bodo: aio submitted only touches queued
11:21	jdike	submitter
11:21	jdike	bodo: aio thread only touches processed
11:21	---	<<-- telekinetic [~roxtar@202.83.43.52] has quit (Quit: Leaving)
11:22	bodo	jdike: yeah, and pipe is written, if queued and processed are equal, when a new element is queued
11:22	jdike	bodo: aio thread : sleeping = 1; if(++processed < queue) sleeping = 0
11:23	jdike	bodo: then aio submitter sends byte if sleeping == 1
11:23	jdike	bodo: aio thread doesn't touch the list, only read it
11:24	jdike	bodo: so we need synchronization between the submitter adding and the interrupt handler removing
11:24	jdike	bodo: which is annoying because that's userspace code
11:25	bodo	jdike: the pipe from aio-thread to intr will be used the same way, I guess?
11:26	jdike	bodo: as I just described? yes
11:26	jdike	bodo: the same problem exists there, so the same solution should work
11:26	bodo	jdike: writing the pipe should be done non-blocking, the reader should try to always get as much as it can
11:27	jdike	bodo: I'm not sure about the non-blocking
11:27	bodo	jdike: because, sometimes the pipe might be written, even if not necessary
11:27	jdike	bodo: yes, it may be
11:28	jdike	bodo: the trick is to not go the other way, and miss a write when there should be one
11:28	bodo	jdike: about syncronization between aio-submitter and intr:
11:29	bodo	jdike: on a single-processor it is safe already, as submit_aio is called with blocked SIGIO
11:29	jdike	bodo: I'm concerned with SMP
11:30	bodo	jdike: yes, there might be a lock needed
11:30	bodo	jdike: wait, it holds a lock already!
11:31	jdike	bodo: the driver, you mean?
11:32	bodo	jdike: IIRC, it holds the block device queue lock
11:32	bodo	jdike: when submitting a new request
11:33	jdike	bodo: but the aio system will be used by things other than the block layer
11:33	jdike	bodo: also, there could be multiple block devices doing IO
11:33	bodo	jdike: Ah, currently ubd is the only user. What will be added?
11:34	---	<<-- tchan [~tchan@c-24-13-81-164.hsd1.il.comcast.net] has quit (Ping timeout: 480 seconds)
11:34	bodo	jdike: OK. And I missed the fact, that all devices use the same pipes / queues
11:34	jdike	bodo: extenfs
11:34	jdike	externfs
11:34	jdike	bodo: hostfs
11:35	jdike	bodo: we could have a separate request list for each user, and have the upper layer lock it
11:35	jdike	bodo: but that seems messy to me
11:37	bodo	jdike: so, add a lock. I guess, that's no problem, because host's spinlock.h has what we need.
11:37	jdike	bodo: hmmm, yeah, didn't consider using host's spinlock.h
11:37	jdike	bodo: but I wonder if that's always present
11:37	jdike	bodo: i.e. glibc headers != kernel headers
11:38	bodo	jdike: on my i386 and s390 systems, it is present
11:39	bodo	jdike: we would need to have a user-obj-constant, that lets us skip the locks, if UML is non-SMP
11:39	jdike	bodo: look at its contents
11:39	bodo	jdike: i386?
11:39	jdike	bodo: on my FC4 i386 box, it is present but empty
11:40	---	---> tchan [~tchan@c-24-13-81-164.hsd1.il.comcast.net] has joined #uml
11:42	bodo	jdike: the mine seems to be fine, but I didn't test.
11:42	bodo	jdike: to be safe, you could call siplock-stubs in a kernel-obj
11:42	jdike	bodo: yup
11:42	bodo	jdike: spinlock
11:46	bodo	jdike: you need to kmalloc/kfree the structures for the queue now, doesn't that slow down aio?
11:47	---	---> tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #uml
11:48	jdike	bodo: kmalloc is pretty quick, and there's also no choice
11:49	bodo	jdike: true.
11:57	---	<<-- Basic [~Basic@warden.real-time.com] has quit (Quit: Leaving)
12:01	---	---> hfb [~hfb@lsanca2-ar33-4-33-193-001.lsanca2.dsl-verizon.net] has joined #uml
12:07	bodo	jdike: what about the real aio case?
12:08	jdike	bodo: what about it?
12:08	bodo	jdike: the aio-requests might be done by the host in another sequence as the are in the queue, right?
12:08	bodo	jdike: so, you don't even queue them, before they are done, right?
12:09	jdike	bodo: they can be done in a different order
12:10	jdike	bodo: but I am planning on putting them in a list, if that's what you mean
12:10	bodo	jdike: the intr needs work the queue in the order, as they are done
12:10	jdike	bodo: yes
12:10	jdike	bodo: it will pick requests out of the middle of the list
12:11	bodo	jdike: middle?
12:11	jdike	bodo: you have a->b->c and b finishes first
12:11	bodo	jdike: yes.
12:11	jdike	bodo: the interrupt will delete b from the list
12:12	bodo	jdike: with the new concept, the intr only knows about one request done, but not which
12:12	bodo	jdike: so, b must be the first entry of the list
12:13	bodo	jdike: even more: it does not know how many entries are done, so only the done may be on the list
12:13	jdike	bodo: it knows which one
12:14	bodo	jdike: why?
12:14	jdike	bodo: aio getevents passes out a void * telling me which request finished
12:14	jdike	bodo: the void * will be the list element that corresponds to
12:15	bodo	jdike: so, the thread knows, which one is finished and puts it onto the list
12:15	bodo	jdike: then, it writes the reply-pipe and the intr can use the entire list
12:16	jdike	bodo: it's on the list already
12:16	jdike	bodo: I'd rather not have the io thread change the list
12:16	jdike	bodo: the submitter adds, the interrupt deletes
12:17	bodo	jdike: but the intr is triggered by the pipe, it has no idea, how much is processed
12:17	bodo	jdike: and also it doesn't know, what is processed
12:18	jdike	bodo: you're right
12:18	bodo	jdike: err, it knows how much, but not what
12:18	jdike	bodo: I had in mind a combination of two schemes
12:19	jdike	bodo: OK, if we have two lists, then I think things work
12:19	jdike	bodo: the IO thread takes things off the queued list and adds them to the finished list
12:19	bodo	jdike: let's assume, the lists normally are short
12:20	bodo	jdike: then, you could add a "done"-flag to the struct
12:20	jdike	bodo: yup
12:21	bodo	jdike: maybe, that's better than calling spinlock-stubs
12:21	jdike	bodo: I'm not sure that helps
12:21	bodo	jdike: what did I miss?
12:22	jdike	bodo: queue a, finish a, (queue b, delete a from list)
12:23	jdike	bodo: the last item looks racy
12:23	bodo	jdike: I think, I have a better idea
12:23	bodo	jdike: the requests, that are active in host, don't even need to be queued
12:24	bodo	jdike: as there is only one aio-thread, the thread may build the queue
12:24	bodo	jdike: in case of 2.6 aio
12:24	jdike	bodo: there needs to be a queue for the IO thread
12:24	jdike	bodo: for it to read
12:25	jdike	bodo: requests don't need to be on a list while they're active in the host
12:26	bodo	jdike: yes. that's what I talked about.
12:26	bodo	jdike: submit_aio_26 starts the requests, the thread reaps the results
12:26	jdike	bodo: oh, yes
12:27	jdike	bodo: I was forgetting that submit_aio_26 did the submit
12:27	bodo	jdike: a problem might be submit_aio_26 failing
12:27	jdike	bodo: then we just return -EIO up the chain, I guess
12:28	bodo	jdike: currently, you write the reply-pipe
12:29	jdike	bodo: yeah
12:29	jdike	bodo: I hope I write that there's an error
12:29	bodo	jdike: so, if you could avoid this, it would help
12:29	jdike	checking
12:30	jdike	bodo: in the new world, there would be an error in the request, it would be added to the finished queue, and the wakeup we talked about would be done
12:30	jdike	bodo: no different than a normal successful return
12:31	bodo	jdike: if so, in aio 2.6, the submitter and the thread would need to write the list
12:32	bodo	jdike: this would need an additional lock
12:33	jdike	bodo: hummph, yeah
12:33	jdike	bodo: well, it needs locking anyway
12:34	bodo	jdike: until now the thread wasn't thought to use the lock
12:34	jdike	bodo: until you pointed out the need for two lists
12:35	jdike	bodo: sorry, I'm one step behind
12:35	bodo	jdike: I see one list only in both cases
12:35	jdike	bodo: yes
12:35	bodo	jdike: in aio 2.4, submitter writes the list, in 2.6 thread writes the list
12:35	jdike	bodo: the finished queue still needs locking
12:36	bodo	jdike: only error case in 2.6 is a problem
12:36	jdike	bodo: regardless of who is adding to it
12:36	bodo	jdike: locking in 2.4 between submitter and intr, yes
12:37	bodo	jdike: in 2.6, no lock might be needed, as there is one thread only
12:37	jdike	bodo: 2.6 still has a thread
12:37	jdike	bodo: just like 2.4
12:38	bodo	jdike: if we could have the thread only writing the list, 2.6 woudn't need a lock
12:39	bodo	jdike: what, if we build a separate errorlist, to pass failed requests from submitter to thread
12:39	jdike	bodo: I don't see why, you have the same race that I pointed out earlier
12:40	bodo	jdike: then, the thread could be interrupted by a signal, to read that list
12:40	bodo	jdike: which race do you mean?
12:42	jdike	bodo: add a to finished, (add b to finished delete a from finished)
12:42	bodo	jdike: this could be worked around.
12:43	jdike	bodo: how?
12:43	bodo	jdike: maybe it's nasty, but let me tell:
12:43	bodo	jdike: a list always is filled with one empty element
12:43	bodo	jdike: reader doesn't touch it, as the count is zero
12:44	bodo	jdike: now, the data from the next element is copied to the empty one, and the new element is added to the list
12:44	bodo	jdike: then, count is incremented
12:45	bodo	jdike: reader reads the data and removes the first element
12:45	jdike	bodo: copied, as in empty = new?
12:45	jdike	bodo: rather, empty = next
12:45	bodo	jdike: but one element still remains
12:45	bodo	jdike: yes.
12:46	jdike	bodo: and then list_add(&new->list, &empty->list)?
12:47	jdike	bodo: and new becomes the empty element?
12:47	bodo	jdike: yes.
12:47	jdike	bodo: and new and next are the same thing?
12:47	bodo	jdike: now I'm confused
12:47	bodo	jdike: I think, you understood my idea
12:48	jdike	bodo: you referred to "new" and "next", just making sure they are the same thing
12:48	bodo	jdike: OK. Let's assume, the list contains EMPTY only
12:49	jdike	bodo: I think so, there is a buffer between where things are added and where they are deleted
12:49	bodo	jdike: yes, that's the idea.
12:49	bodo	jdike: no lock needed to queue or unqueue
12:50	bodo	jdike: and that would be fine for the 2.4 also
12:50	jdike	bodo: the race is between copying data and removing an element
12:51	bodo	jdike: why?
12:51	jdike	bodo: you have empty = next in the thread
12:51	jdike	bodo: and list_del(&empty->prev) in the interrupt handler
12:52	jdike	bodo: correct?
12:52	bodo	jdike: not exactly.
12:52	jdike	bodo: list_del(&empty->prev->list) actually
12:52	bodo	jdike: it's a list of structures only, right?
12:52	jdike	bodo: OK, but all lists are lists of structures
12:53	bodo	jdike: so, the struct has a field "struct request * next"
12:53	bodo	jdike: you have to copy all data, but not the next
12:53	jdike	bodo: struct aio_request, there is already a struct request
12:54	bodo	jdike: right. aio_request
12:55	bodo	jdike: maybe, putting on the list and removing from the list need to be done "by hand"
12:56	jdike	bodo: I'm pretty sure there's a race there, and I think it's when you move the buffer element
12:56	bodo	jdike: why? the empty element on the list isn't touched by the reader
12:57	bodo	jdike: so you may write the contents of the done element to it
12:57	bodo	jdike: then you write it's next-pointer with the done-elemnts address
12:57	bodo	jdike: then you increment the counter
12:58	bodo	jdike: removing an element from the list is done by changing the list's root only
12:59	bodo	jdike: element_to_remove = listroot; listroot = listroot->next;
12:59	jdike	bodo: yes, let me think about that
13:01	jdike	bodo: and both sides touch the counter?
13:03	bodo	jdike: the "counter" really are the two counters you suggested
13:04	bodo	jdike: one for "queued" and one for "processed"
13:04	jdike	bodo: OK
13:05	bodo	jdike: unfortunately, for 2.4 we'll ne separate lists for requests and replies, I think
13:05	jdike	bodo: yes
13:05	bodo	jdike: because, there is one request list only, but there might be many reply-lists
13:06	bodo	jdike: on 2.6 the request list is used in case of error only, the thread is woken up by signal in case of error in 2.6
13:07	bodo	jdike: so, the only case, that needs a lock will be writing the request-list in 2.4 or 2.6 error
13:08	bodo	jdike: in case of SMP only
13:09	jdike	bodo: so you want to pass 2.6 errors through the thread
13:09	jdike	bodo: and then on to the interrupt handler normally
13:10	jdike	bodo: and I don't see why the same scheme can't be used in 2.4
13:13	bodo	jdike: it can be used. 2.4 in all cases and 2.6 in case of error may use the same sheme
13:13	jdike	bodo: and in 2.6 from thread to interrupt, correct?
13:13	bodo	jdike: thread to interrupt are equal for 2.4 and 2.6, I think
13:13	jdike	bodo: yeah
13:14	bodo	jdike: the only case, that needs locking for SMP is writing the request-list
13:14	---	<<-- dunc [~dunc@gateway.ash.thebunker.net] has quit (Quit: Client exiting)
13:15	jdike	bodo: in 2.4?
13:15	jdike	bodo: yeah
13:15	bodo	jdike: and 2.6 in case of error
13:15	jdike	bodo: yeah
13:16	jdike	bodo: how are you coming with the host side of S390?
13:16	bodo	jdike: it was a hard piece of work to make Martin and Uli see the problem.
13:16	jdike	bodo: yeah
13:16	jdike	bodo: do they see it now?
13:17	bodo	jdike: I extracted the "skip-syscall-retry"-test from UML and sent it to them.
13:17	bodo	jdike: now I hope they see.
13:17	jdike	bodo: oh yeah, I didn't notice anything after that, except for the thanks
13:18	bodo	jdike: I'm quite sure, they tried to fix a non-existent problem with a do-nothing-patch, first
13:18	jdike	bodo: hehe
13:18	bodo	jdike: but now, they can test!
13:19	jdike	bodo: well, if you really ant to fix a non-problem, a do-nothing patch is the way to go
13:19	bodo	jdike: that's true ;-)
13:21	jdike	bodo: is that the only thing holding up UML/S390?
13:21	bodo	jdike: meanwhile I'm quite impatient, as I want to know, what the solution will look like
13:21	bodo	jdike: yes. UML/s390 isn't fully tested yet, but I runs
13:22	bodo	jdike: it runs
13:22	jdike	bodo: OK
13:22	bodo	jdike: did you see the networking patch?
13:22	jdike	bodo: yes
13:22	jdike	bodo: stupidity on my part
13:23	---	---> Basic [~Basic@gatekeeper.real-time.com] has joined #uml
13:23	---	---> R2-D2 [~R2-D2@pD955AE7E.dip.t-dialin.net] has joined #uml
13:23	bodo	jdike: no. Much work, much errors. Only people, that don't work, don't make mistakes
13:24	jdike	bodo: I'd prefer much work, few errors, personally
13:24	bodo	jdike: so, the quality of your code really is good
13:24	jdike	bodo: tx
13:24	R2-D2	hi what can cause a simple segfault error msg when trying to run the um-kernel binary?
13:24	jdike	R2-D2: what version, and what's the output?
13:25	R2-D2	usermode-sources-2.6.11 from gentoo portage-tree .. output: bash# segmentation fault
13:25	bodo	jdike: I asked for the patch, as I guess, it even could be simplified by using the pointer instead of copying data
13:26	jdike	R2-D2: tmpfs is not mounted noexec?
13:26	jdike	R2-D2: /tmp rather
13:27	R2-D2	well tmpfs is mounted as far is i know
13:27	jdike	R2-D2: !noexec?
13:27	R2-D2	checking
13:28	R2-D2	its set to default in fstab.. how to mount with noexec?
13:30	jdike	R2-D2: you don't want noexec
13:30	R2-D2	then how to mount without it :)
13:30	jdike	R2-D2: you already have it
13:30	jdike	R2-D2: can you see if gentoo has patched UML at all?
13:30	jdike	R2-D2: they've broken UML in the past
13:31	R2-D2	there are specific uml sources which contain actual patches
13:31	---	---> leighbb [~leigh@cpc1-heck1-4-0-cust245.hudd.cable.ntl.com] has joined #uml
13:32	jdike	R2-D2: what base version of UML?
13:34	R2-D2	x.11.8-bs5
13:35	jdike	R2-D2: OK, you might try reverting the patches and see what happens
13:35	jdike	R2-D2: or strace the thing, and post the output somewhere
13:35	R2-D2	k ill give a few things a try
13:39		* jdike goes to get some lunch
13:39	bodo	jdike: It's late, I'm going to leave
13:40	bodo	Bye.
13:40	jdike	bodo: OK, talk to you later
13:40	bodo	jdike: talk to you next days
13:40	---	<--- bodo [~bo@217.115.74.14] has left #uml (Verlassend)
13:54	---	<<-- R2-D2 [~R2-D2@pD955AE7E.dip.t-dialin.net] has quit (Quit: Verlassend)
14:16	---	<<-- ElectricElf [~david@electricelf.chair.oftc.net] has quit (Remote host closed the connection)
14:17	---	---> ElectricElf [dbharris@electricelf.chair.oftc.net] has joined #uml
14:30	---	<<-- JViz` [Anomaly@cpe-065-190-045-031.triad.res.rr.com] has quit (Quit: YES THEY DESERVE TO DIE, AND I HOPE THEY BURN IN HELL!)
14:56	---	<<-- rus [~rghf@office.vaserv.com] has quit (Ping timeout: 480 seconds)
14:59	---	---> orospakr [~orospakr@CPE0004762b7051-CM001225701f0e.cpe.net.cable.rogers.com] has joined #uml
14:59	---	---> jvds [~rghf@office.vaserv.com] has joined #uml
15:38	---	<<-- silug [~steve@customer34.wisperisp.net] has quit (Read error: Connection reset by peer)
16:02	Nem^^	aard map at http://www.act-of-war.de/aow/download.php?view.2880
16:38	---	---> JViz [Anomaly@cpe-065-190-045-031.triad.res.rr.com] has joined #uml
16:44	---	<<-- Dougie [~Doug@shade.idmf.net] has quit (Ping timeout: 480 seconds)
16:53	---	<<-- leighbb [~leigh@cpc1-heck1-4-0-cust245.hudd.cable.ntl.com] has quit (Quit: Download Gaim: http://gaim.sourceforge.net/)
17:00	---	<<-- Basic [~Basic@gatekeeper.real-time.com] has quit (Quit: Leaving)
17:09	---	<<-- fo0bar [ryan@cromulent.colobox.com] has quit (Quit: I am a CIA spy. You never saw me here.)
17:21	---	<<-- DEac- [~deac@xdsl-213-168-107-94.netcologne.de] has quit (Quit: Verlassend)
17:22	---	---> fo0bar [ryan@cromulent.colobox.com] has joined #uml
17:24	---	<<-- fo0bar [ryan@cromulent.colobox.com] has quit (Quit: )
17:25	---	---> DEac- [~deac@xdsl-195-14-203-226.netcologne.de] has joined #uml
17:28	---	---> fo0bar [fo0bar@cromulent.colobox.com] has joined #uml
17:34	---	---> silug [~steve@customer34.wisperisp.net] has joined #uml
17:37	---	<<-- jdike [~jdike@pool-141-154-228-134.bos.east.verizon.net] has quit (Read error: Operation timed out)
17:38	---	<<-- DEac- [~deac@xdsl-195-14-203-226.netcologne.de] has quit (Remote host closed the connection)
17:38	---	---> DEac- [~deac@xdsl-195-14-203-226.netcologne.de] has joined #uml
17:42	---	<--- Newsome [~sorenson@obelix.cs.byu.edu] has left #uml (Leaving)
18:02	---	---> solarce [~solarce@host-58-241-9-69.midco.net] has joined #uml
18:02	solarce	who is alive?
18:04	---	---> schlumpf2 [~schlumpf@dsl-084-056-143-116.arcor-ip.net] has joined #uml
18:04	solarce	what would be the best documentation to consult if I need to route a public ip from one machine to another machine behind a firewall, and my goal is for the second machine to behave as though that public ip is its own?
18:07	commander	solarce, iptables, routing, ip forwarding
18:09	---	<<-- Dougie_ [~Doug@shadow.idmf.net] has quit (Ping timeout: 480 seconds)
18:11	---	<<-- schlumpf [~schlumpf@dsl-084-056-143-044.arcor-ip.net] has quit (Ping timeout: 480 seconds)
18:21	---	<<-- da-x [karrde@bzq-218-247-127.red.bezeqint.net] has quit (Ping timeout: 480 seconds)
18:27	---	---> da-x [karrde@bzq-218-247-127.red.bezeqint.net] has joined #uml
18:28	---	<<-- commander [commander-@p549265F6.dip.t-dialin.net] has quit (Quit: Segmentation fault)
18:34	---	---> Dougie [~Doug@shadow.idmf.net] has joined #uml
18:55	---	<<-- Cowboy [~Cowboy@129.42.184.35] has quit (Remote host closed the connection)
18:59	---	<<-- hfb [~hfb@lsanca2-ar33-4-33-193-001.lsanca2.dsl-verizon.net] has quit (Quit: Client exiting)
19:10	---	---> Cowboy [~Cowboy@129.42.184.35] has joined #uml
19:15	---	---> Newsome [~sorenson@byu-gw.customer.csolutions.net] has joined #uml
19:17	---	<<-- DEac- [~deac@xdsl-195-14-203-226.netcologne.de] has quit (Ping timeout: 480 seconds)
20:08	---	---> Cowboy__ [~Cowboy@129.42.184.35] has joined #uml
20:13	---	<<-- Cowboy [~Cowboy@129.42.184.35] has quit (Read error: Operation timed out)
20:19	solarce	I've determined I need to setup some uml hosts to test stuff before I go killling my live server :>
20:23	---	Channel: services.oftc.net changed the topic of #uml to: Welcome to #UML - current releases: 2.4.27-um1 \| 2.4.24-um1 (rock solid) \| 2.6.11-bs1 \| http://user-mode-linux.sf.net (Mainpage) \| http://www.usermodelinux.org (communitypage) \| http://www.user-mode-linux.org/~blaisorblade/ (SKAS/guest -bb and -bs patches) \| http://uml.harlowhill.com/ (Wiki page for documentation)
20:50	---	<<-- Cowboy__ [~Cowboy@129.42.184.35] has quit (Read error: Operation timed out)
21:05	---	---> Dougie_ [~Doug@shade.idmf.net] has joined #uml
21:12	---	---> Basic [~Basic@fortress.tanners.org] has joined #uml
21:56	---	<<-- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit (Quit: bug, n: A son of a glitch.)
22:00	---	---> NemLappy^2 [~Nem@p54ABCF0F.dip.t-dialin.net] has joined #uml
22:00	---	---> Nem^ [~Nem@p54ABCF0F.dip.t-dialin.net] has joined #uml
22:08	---	<<-- Nem^^ [~Nem@p54ABCE2E.dip.t-dialin.net] has quit (Ping timeout: 480 seconds)
22:08	---	<<-- NemLappy^1 [~Nem@p54ABCE2E.dip.t-dialin.net] has quit (Ping timeout: 480 seconds)
22:31	---	---> itamarjp [lualele@200-225-242-020.dynamic.idial.com.br] has joined #uml
22:58	---	<<-- itamarjp [lualele@200-225-242-020.dynamic.idial.com.br] has quit (Quit: )
22:59	---	<--- VS_ChanLog [~stats@ns.theshore.net] has left #uml (Rotating Logs)
22:59	---	---> VS_ChanLog [~stats@ns.theshore.net] has joined #uml
23:14	---	<<-- Basic [~Basic@fortress.tanners.org] has quit (Quit: Leaving)
23:42	---	---> karsten [~karsten@host-66-81-223-46.rev.o1.com] has joined #uml
23:42	karsten	Greets.
23:43	karsten	lilo: What bring you 'round these parts?
23:44	karsten	has jdike been 'round lately?
23:44	Newsome	Haven't seen him lately
23:45	Newsome	looks like he left the channel about 6 hours ago
---	Log	closed Wed May 18 00:00:37 2005