| --- | Log | opened Thu Jan 03 00:00:22 2008 |
| 00:04 | |-| | hfb [~hfb@75.80.37.175] has joined #uml |
| 00:04 | |-| | balbir [~balbir@59.145.136.1] has joined #uml |
| 01:23 | |-| | hfb [~hfb@75.80.37.175] has quit [Quit: Leaving] |
| 02:42 | |-| | Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has joined #uml |
| 02:51 | |-| | Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has quit [Quit: ChatZilla 0.9.79 [Firefox 2.0.0.8/2007100400]] |
| 05:09 | |-| | ferret_0567 [~travis@72.191.26.86] has quit [Quit: Lost terminal] |
| 07:16 | |-| | balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds] |
| 08:37 | |-| | dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.] |
| 09:17 | |-| | dang [~dang@aa-redwall.nexthop.com] has joined #uml |
| 10:12 | |-| | jdike [~jdike@pool-96-237-103-155.bstnma.fios.verizon.net] has joined #uml |
| 10:12 | <jdike-#uml->> | Hi guys |
| 10:20 | <jdike-#uml->> | It turns out that the automatic host vmsplit detection breaks somethign |
| 12:42 | |-| | tyler29 [~tyler@ARennes-257-1-129-51.w86-210.abo.wanadoo.fr] has joined #uml |
| 13:23 | |-| | tyler29 [~tyler@ARennes-257-1-129-51.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] |
| 13:34 | |-| | tyler29 [~tyler@81.53.157.243] has joined #uml |
| 14:13 | |-| | dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.] |
| 14:47 | |-| | dang [~dang@aa-redwall.nexthop.com] has joined #uml |
| 14:54 | <Magotari-#uml->> | jdike: I'm afraid I probably won't be able to contribute to this project till I get back. I talked to a person I know, he was the one who scored second in our Algorithms class. He might be of some use, if I manage to convince him to do some testing for you. |
| 14:55 | <Magotari-#uml->> | I'm missing all the skas4 fun, but well... Cannot move a marriage. |
| 14:58 | |-| | tyler29 [~tyler@81.53.157.243] has quit [Ping timeout: 480 seconds] |
| 15:02 | <jdike-#uml->> | hehe |
| 15:20 | <Magotari-#uml->> | I'm only worried that the person I hope to stand in for me for the time of my absence won't want to help out. He kinda freaked when I told him that it would be nice if he came and helped you do tests. I can understand, I used to freak out when being in one irc channel with a kernel hacker... |
| 15:21 | <Magotari-#uml->> | But he is really smart. Not sure if a good bughunter, but unlike me he would stay quiet if he did not have anything to contribute. |
| 15:23 | <jdike-#uml->> | Don't sweat it |
| 15:23 | <jdike-#uml->> | just go off and have a good time |
| 15:34 | |-| | dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.] |
| 15:44 | <ctrace-#uml->> | jdike: hi there, i tried applying the patch you suggested (Work around host tcsetattr bug) to chan_user.c but i am still able to induce instances to hang |
| 15:44 | <ctrace-#uml->> | jdike: the good news is that i did verify that it seems to be a problem with the way python/pexpect is handling the kernel console |
| 15:44 | <jdike-#uml->> | as in, it's just as easy, no change? |
| 15:45 | <jdike-#uml->> | or it's harder, and there's still something wrong? |
| 15:45 | <ctrace-#uml->> | yes, it is just as easy, no change... |
| 15:45 | <ctrace-#uml->> | crashes in the same spot as far as i can see |
| 15:46 | <ctrace-#uml->> | however i am able to un-hang an instance by forcing our python/pexpect manager to send a command to the kernel console |
| 15:47 | <jdike-#uml->> | crashes, or hangs? |
| 15:47 | <ctrace-#uml->> | so it seems to point to something in our handling of the kernel console (whether or not it is a uml problem, i am not quite sure :-) ) |
| 15:47 | <ctrace-#uml->> | sorry, meant to say hang |
| 15:48 | |-| | tyler29 [~tyler@81.250.161.102] has joined #uml |
| 15:48 | <ctrace-#uml->> | i induce the uml instance to hang by ringing the bell a lot of times (holding down TAB at the shell for example) |
| 15:48 | <ctrace-#uml->> | it doesn't crash :-) |
| 15:49 | <jdike-#uml->> | It is possible to deadlock a control script if you're not careful |
| 15:49 | <ctrace-#uml->> | but by simply making our python front-end manager send a command to the kernel console (e.g. send an uptime command and have pexpect wait for the word 'average'), the uml instance comes back to life :-) |
| 15:50 | <jdike-#uml->> | you don't read output for a while, UML hangs in writing to the console waiting for it to clear, meanwhile, you send input, and sleep waiting for the input to clear |
| 15:50 | <ctrace-#uml->> | yep that seems to be what is happening.. |
| 15:50 | <ctrace-#uml->> | or well, something like that |
| 15:51 | <ctrace-#uml->> | seems like we are not gobbling up the stuff UML writes to the console which eventually causes it to hang |
| 15:52 | <jdike-#uml->> | if you can wake it up with a command, then that's not what's happening |
| 15:52 | <ctrace-#uml->> | in any case, i appreciate all of your help in diagnosing the problem |
| 15:53 | <jdike-#uml->> | can you get a stack trace from when UML is hung? |
| 15:53 | <ctrace-#uml->> | sure |
| 15:53 | <jdike-#uml->> | and UML is sleeping, not spinning, right? |
| 15:54 | <ctrace-#uml->> | uml is not spinning in the sense that it is eating up all of the cpu, it appears to be sleeping (strace'ing the ~/.uml/host/pid just shows it hanging there) |
| 15:55 | <jdike-#uml->> | right |
| 15:55 | <jdike-#uml->> | the tcsetattr bug caused it to spin |
| 15:56 | <ctrace-#uml->> | one sec, will get a stack trace when i am running the patched kernel |
| 16:08 | <ctrace-#uml->> | sorry, back now |
| 16:08 | <ctrace-#uml->> | so i have an instance that is hung now, ps shows the process is in interruptible sleep: |
| 16:08 | <ctrace-#uml->> | 6868 pts/10 Ss+ 0:03 /a/uml/debian31/linux-2.6.23.9.patched.with.hostfs.debug mem=32m con1=pts umid=narb1 ubda=/home/dragon/uml/narb1,/a/uml/debian31/Debian-3.1-x86-root_fs eth0=daemon,,unix,/tmp/tmpjiUrUV/uml_switch_socket |
| 16:09 | <jdike-#uml->> | what's it's stack |
| 16:09 | <jdike-#uml->> | its |
| 16:09 | <ctrace-#uml->> | strace shows the same as what we saw before applying the patch |
| 16:09 | <ctrace-#uml->> | also looks similar, here it is: |
| 16:09 | <ctrace-#uml->> | you just want to see the bt from gdb ? |
| 16:10 | <ctrace-#uml->> | #3 0x00005404 in ?? () |
| 16:10 | <ctrace-#uml->> | #4 0xb7f00ab6 in tcsetattr () from /lib/tls/i686/cmov/libc.so.6 |
| 16:10 | <ctrace-#uml->> | #5 0x0805ad17 in fd_close (fd=0, d=0x9d59480) at arch/um/drivers/fd.c:72 |
| 16:10 | <ctrace-#uml->> | #6 0x0805b129 in close_one_chan (chan=0x9cb16a0, delay_free_irq=1) at arch/um/drivers/chan_kern.c:297 |
| 16:10 | <ctrace-#uml->> | #7 0x0805b155 in close_chan (chans=0x8231710, delay_free_irq=1) at arch/um/drivers/chan_kern.c:313 |
| 16:10 | <ctrace-#uml->> | #8 0x0805b84d in chan_interrupt (chans=0x8231710, task=0x823172c, tty=0x9d58800, irq=2) at arch/um/drivers/chan_kern.c:673 |
| 16:10 | <jdike-#uml->> | similar |
| 16:11 | <jdike-#uml->> | in that tcsetattr is there |
| 16:11 | <ctrace-#uml->> | looks pretty much identical to what i posted on dec 18, yup |
| 16:11 | <jdike-#uml->> | but it's not doing a write |
| 16:12 | <jdike-#uml->> | are you sure you're draining all UML console output? |
| 16:14 | <ctrace-#uml->> | unfortunately i am not familiar enough with python/pexpect to be sure, but i have asked the python developer to look into that |
| 16:15 | <jdike-#uml->> | that could account for what you're seeing |
| 16:15 | <jdike-#uml->> | and if you're not, I would call that a script bug |
| 16:16 | <ctrace-#uml->> | agreed.. |
| 16:17 | <ctrace-#uml->> | when the uml process is in that state, i was only able to hack through a little python to make it send another command to the kernel console and have it expect a certain result, which stops the uml from hanging |
| 16:18 | <jdike-#uml->> | expect is surpsingly subtle |
| 16:18 | <ctrace-#uml->> | so it seems that whenever i do that, it is gobbling up whatever uml output it is sitting on, perhaps? |
| 16:18 | <jdike-#uml->> | I have a perl Expect library for controlling UML and I never did get all the subtle bugs out of it |
| 16:19 | <ctrace-#uml->> | i am at least happy that we can reproduce the problem easily ;-) |
| 16:25 | <ctrace-#uml->> | for awhile i have also been trying to figure out why the window size is not detected automatically when i attach to a uml instance via screen... |
| 16:25 | <ctrace-#uml->> | e.g. when i first attach to the screen, stty -a shows my terminal as 0x0 |
| 16:25 | <jdike-#uml->> | I've looked at that, and I don't see that it's possible |
| 16:25 | <ctrace-#uml->> | (which obviously confused some applications) |
| 16:25 | <ctrace-#uml->> | ah |
| 16:26 | <jdike-#uml->> | AFAICS, UML is attached to the wrong side of the pty to get SIGWINCH |
| 16:26 | <ctrace-#uml->> | interesting |
| 16:27 | <ctrace-#uml->> | in that case i am glad i asked so that i don't spend any more time trying to figure that out :-) |
| 16:27 | <ctrace-#uml->> | at least it is possible to set the size manually.. |
| 16:28 | <ctrace-#uml->> | once again, thanks for your time & support, i really appreciate it |
| 16:29 | <jdike-#uml->> | np |
| 16:55 | |-| | tyler29 [~tyler@81.250.161.102] has quit [Ping timeout: 480 seconds] |
| 17:10 | |-| | tyler29 [~tyler@ARennes-257-1-39-158.w81-53.abo.wanadoo.fr] has joined #uml |
| 17:34 | |-| | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has joined #uml |
| 17:35 | <bldewolf-#uml->> | so how do I go about building a kernel source that has humfs support? |
| 17:36 | <jdike-#uml->> | You go to http://user-mode-linux.sourceforge.net/old/patches.html |
| 17:37 | <jdike-#uml->> | grab the 2.6.24-rc1 patches and apply them, or just the externfs-related ones |
| 17:45 | |-| | mgross [~mgross@207.173.77.239] has joined #uml |
| 17:52 | <bldewolf-#uml->> | I thought I tried it against 2.6.24-rc1 and it didn't apply cleanly, I can try again though |
| 17:55 | |-| | tyler29 [~tyler@ARennes-257-1-39-158.w81-53.abo.wanadoo.fr] has quit [Remote host closed the connection] |
| 17:56 | <bldewolf-#uml->> | yeah, I just tried again. What do I do when they fail? |
| 18:01 | <bldewolf-#uml->> | I've got patches.tar and linux-2.6.24-rc1.tar.bz2, and the patches don't apply cleanly |
| 18:11 | |-| | mgross [~mgross@207.173.77.239] has quit [Quit: Leaving] |
| 19:12 | <jdike-#uml->> | you're applying them in the order given in the series file? |
| 19:15 | |-| | jdike [~jdike@pool-96-237-103-155.bstnma.fios.verizon.net] has quit [Quit: Leaving] |
| 19:52 | <bldewolf-#uml->> | `quilt push -a`? |
| 20:20 | |-| | ferret_0567 [~travis@72.191.26.86] has joined #uml |
| 20:35 | |-| | mgross [~mgross@66.206.87.117] has joined #uml |
| 20:35 | |-| | mgross [~mgross@66.206.87.117] has quit [] |
| 23:16 | |-| | balbir [~balbir@122.167.212.110] has joined #uml |
| 23:58 | |-| | VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs] |
| 23:59 | |-| | VS_ChanLog [~stats@ns.theshore.net] has joined #uml |
| --- | Log | closed Fri Jan 04 00:00:46 2008 |
![[FSF Associate Member]](/assets/fsf.png){kind=small}
