Back to Home / #uml / 2007 / 11 / Prev Day | Next Day
#uml IRC Logs for 2007-11-29

---Logopened Thu Nov 29 00:00:38 2007
00:58|-|besonen_mobile__ [~besonen_m@71-220-198-145.eugn.qwest.net] has quit [Ping timeout: 480 seconds]
01:34|-|balbir [~balbir@59.145.136.1] has joined #uml
01:36|-|tchan1 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
01:36|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Read error: Connection reset by peer]
01:54|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
01:54|-|tchan1 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Read error: Connection reset by peer]
02:05|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
02:05|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
02:11|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has joined #uml
02:12|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has left #uml []
02:20|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
02:21|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
02:28|-|besonen_mobile [~besonen_m@71-220-198-145.eugn.qwest.net] has joined #uml
02:43|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
02:46|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
03:10|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
03:19|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
03:26|-|da-x_work_ [~karrde@xiv-glob.ser.netvision.net.il] has joined #uml
03:27|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
03:27|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
03:40|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
03:45|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
03:55|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
03:55|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
04:03|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
04:04|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
04:20|-|karol [~karol@chello089076070038.chello.pl] has joined #uml
04:20<karol-#uml->>Yawn. Got sleep at last.
04:24|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Ping timeout: 480 seconds]
04:28|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
04:36|-|krau [~cktakahas@189.70.66.189] has quit [Quit: Varei!!!]
04:36|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Read error: Connection reset by peer]
04:37|-|tchan2 [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
06:04|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
06:13|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has joined #uml
07:01|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
08:42|-|dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.]
08:47|-|krau [~cktakahas@200.184.118.132] has joined #uml
08:58|-|Baltam [~WIKIMOKI@cs-tor.bu.edu] has quit [Remote host closed the connection]
09:00|-|Baltam [~WIKIMOKI@c-5042e455.011-292-73746f34.cust.bredbandsbolaget.se] has joined #uml
09:05|-|tchan2 changed nick to tchan
09:10|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:28|-|balbir [~balbir@122.167.209.212] has joined #uml
09:45<karol-#uml->>Ah, damnit.
09:47<karol-#uml->>Forgot to cc uml-devel when sending a patch.
10:10|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
10:17|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
10:17<jdike-#uml->>Hi guys
10:19[~]caker #uml sekrit handshakes jdike #uml-> sekrit handshakes jdike
10:19<jdike-#uml->>I liked the cookie better
10:19<karol-#uml->>Hey, jdike. Bad news, the second time I did a lot of 'stack <foo>' it crashed differently. Seems a tad unpredictable.
10:19<jdike-#uml->>maybe you found two different bugs
10:20<jdike-#uml->>I would call that good news
10:20<karol-#uml->>Maybe.
10:20<karol-#uml->>The other bad news is that 'proc ../dev/kmem' kills UML. I guess we can file that one under: "Touch /dev/kmem and die."
10:20<karol-#uml->>Er, I mean good news.
10:22<jdike-#uml->>right
10:27<karol-#uml->>Ah, yes. And there is an unused variable in mconsole_stack. I compiled such a kernel and tested it, seemed to work. Interested in a patch?
10:28<karol-#uml->>By such a kernel, I meant a kernel without the extra variable.
10:29<jdike-#uml->>yup
10:30<karol-#uml->>Right.
10:48<karol-#uml->>The mail is ready, only to wait for gcc now. Just in case.
10:48<karol-#uml->>Oh. Checkpatch. Nearly forgot.
10:48<karol-#uml->>Clean. :)
10:50<karol-#uml->>And sent.
11:00<jdike-#uml->>what exactly was the problem
11:00<jdike-#uml->>and what does MSG_DONTWAIT have to do with it?
11:02<karol-#uml->>jdike: The problem was that an operation which was supposed to be blocking wasn't.
11:03<karol-#uml->>It was set as blocking in one place, and then MSG_DONTWAITed in the other.
11:03<karol-#uml->>Since the blockynes of the operation is handled by os_set_fd_blocking already...
11:04<karol-#uml->>The operation was inside a while.
11:04<karol-#uml->>while(foo())
11:04<karol-#uml->>And when non-blocking, it never entered the loop.
11:05<karol-#uml->>Because there was no input to be had, and it did not like it.
11:05<karol-#uml->>The while loop was what kept UML stopped.
11:05<jdike-#uml->>OK
11:05<karol-#uml->>I think that the loop itself could use an improvement or two, but I aimed for minimum invasiveness.
11:06<jdike-#uml->>so during normal operation, if mconsole calls recvfrom, and there's no input, it won't block?
11:06<jdike-#uml->>because the descriptor has already been set non-blocking?
11:06<karol-#uml->>Sorta.
11:06<karol-#uml->>It is set as blocking in os_set_fd_blocking.
11:06<karol-#uml->>However...
11:07<karol-#uml->>We override it with the thing I changed to 0.
11:07<jdike-#uml->>normal operation, that is, outside of a stop and go
11:07<karol-#uml->>Yes, then it does block, but let me doublecheck.
11:07<karol-#uml->>I read the man page 10 times, I think.
11:08<jdike-#uml->>outside of a stop and go, that recvfrom should not block
11:08<karol-#uml->>By default it waits for a message.
11:08<karol-#uml->>However, os_set_fd_blocking after we leave the stop and go should reset that.
11:09<karol-#uml->>Which is in the code, after the while loop exits.
11:09<karol-#uml->>Unless I misunderstood how the flags work, in which case you need to read them in via fcntl, which was the original design.
11:09<karol-#uml->>And then put the flags in in place of the 0.
11:09<jdike-#uml->>so I was being a little excessive in making sure that it normally doesn't block
11:10<karol-#uml->>I suppose so. Remember, I am green and green people make stupid mistakes.
11:10<karol-#uml->>So taking everything I say with a grain of salt is advised.
11:27|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has joined #uml
11:55<karol-#uml->>jdike: Are you aware if someone has proposed a patch to add -O0 building to the kernel? I could use such a thing, the build times are killing me sometimes.
11:55<karol-#uml->>But I could not find anything on the net. So maybe you know.
11:56<jdike-#uml->>it won't work
11:56<jdike-#uml->>the kernel build depends on things being inlined
11:56<jdike-#uml->>and that won't happen with -O0
11:58<karol-#uml->>Oh. Dear.
11:59<karol-#uml->>Usually it is the optimizations that cause trouble, not otherwise. :/
12:04|-|ftumch [~James@james.1ec.aaisp.net.uk] has quit [Quit: Goodbye.]
12:08|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
12:42|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
12:57|-|tyler29 [~tyler@ARennes-257-1-70-58.w81-53.abo.wanadoo.fr] has joined #uml
14:20<karol-#uml->>Partitioning a disk in Japanese. One of the benefits of virtual machines is reduced anxiety.
14:21<jdike-#uml->>heh
14:23<karol-#uml->>Ho su to <kanji>. I guess hostname. This is fun. I get to learn the language by using it. And also, if something breaks, it will break in a non-english enviroment.
14:23<karol-#uml->>I wonder how UML can break...
14:35<karol-#uml->>ubda=<kanji go here> :)
14:48<dang-#uml->>Wow, that was fun... :P
14:48<dang-#uml->>I started a 64-bit root_fs from a 32-bit kernel. Runaway spawning and coring of uml...
14:51<dang-#uml->>I had to run a tightloop of killall -9 linux to eventually get my system back...
14:51<karol-#uml->>Wheeee.
14:52<dang-#uml->>Nice way to clean your or disk cache tho. :P
14:55<karol-#uml->>Why did it spawn so much?
14:55<karol-#uml->>while (!uml_started) ?
14:58<dang-#uml->>No.
14:58<dang-#uml->>I'm not sure why...
14:58<dang-#uml->>The script loops over a set number of configurations (2 in this case) starting that many UMLs.
14:59<dang-#uml->>The main UML process for each one didn't go away, either.
14:59<dang-#uml->>So UML was forking somehow...
15:00<jdike-#uml->>I don't think so
15:01<jdike-#uml->>in that situation, you'll end up with one UML constantly deciding it doesn't know what init is, I think
15:02<dang-#uml->>Well, I had several hundred linux processes, so *something* was spawning them...
15:02<dang-#uml->>But my main console for each one just sat there...
15:06<dang-#uml->>Yeah, it looks like the main uml for each one forks.
15:07<dang-#uml->>Probably it was because init was constanstanly respawning and crashing.
15:07<karol-#uml->>Usually when init crashes what you get is a panic.
15:07<karol-#uml->>Such is my experience anyway.
15:08<karol-#uml->>And what would respawn it?
15:08<dang-#uml->>Beats me. It's an odd setup, and I'm not willing to try it again...
15:08<dang-#uml->>In case it takes my host box down.
15:08<dang-#uml->>It's not exactly a recent kernel, tho.
15:09<karol-#uml->>Did you run the thing in TT mode maybe?
15:09<dang-#uml->>2.6.20
15:09<dang-#uml->>Nope.
15:09<dang-#uml->>SKAs
15:09<karol-#uml->>Oh. Ok.
15:09<dang-#uml->>I checked that first...
15:10<dang-#uml->>Woot.
15:10<dang-#uml->>BUG_ON in elf_core_dump...
15:10<jdike-#uml->>THAT'S FIXED
15:10<jdike-#uml->>so no whining about old bugs
15:11<dang-#uml->>:)
15:11<dang-#uml->>I wasn't going to whine.
15:11<dang-#uml->>Any idea when it's fixed?
15:12|-|tyler29 [~tyler@ARennes-257-1-70-58.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
15:13<jdike-#uml->>it's x86_64, right?
15:13<jdike-#uml->>(say "yes")
15:13<dang-#uml->>Yes.
15:13<jdike-#uml->>good
15:14<jdike-#uml->>commit 058ac308f3dd34ce4e2dbf938258975ced14b809 on Oct 16
15:16<jdike-#uml->>2.6.24-rc1
15:16<jdike-#uml->>I think I decided it was too big and risky for -stable
15:17<dang-#uml->>Hmm...
15:17<dang-#uml->>'k, I'll probably have to backport, then...
15:17<dang-#uml->>Does the current 2.6.24-rc3 work well in UML?
15:17<dang-#uml->>I know the arch merge caused problems...
15:19<jdike-#uml->>only compilation problems
15:19<jdike-#uml->>once those are taken care of, UML seems fine
15:20<dang-#uml->>Okay, I'll give it a shot then. It should be quicker than backporting...
15:20<karol-#uml->>Now the ptrace merge might give us all a headache again. *sigh*
15:20<karol-#uml->>I have not tried mmotm yet, but...
15:21<jdike-#uml->>why?
15:21<jdike-#uml->>UML doesn't share any ptrace code with x86
15:21<jdike-#uml->>it might produce a host that can't run UML, however
15:21|-|tyler29 [~tyler@ARennes-257-1-141-238.w86-210.abo.wanadoo.fr] has joined #uml
15:35<dang-#uml->>Should I use NO_HZ in UML?
15:41<karol-#uml->>Yeah. Exactly.
15:42<karol-#uml->>Bad hosts produced. But the host would otherwise appear fine. And people would come flocking to here instead of to #ptrace of wherever they are.
15:44<jdike-#uml->>use NO_HZ
15:44<jdike-#uml->>Ingo and I warned Roland to make sure that UML runs when he's done
15:49<dang-#uml->>Yay. I'm getting a million build errors.
15:51<dang-#uml->>Ah, include/asm/arch is not set correctly.
15:57|-|tyler29 [~tyler@ARennes-257-1-141-238.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
15:59<jdike-#uml->>yeah, mrproper is called for
16:01<dang-#uml->>I'm pretty sure I did a mrproper. Can I not copy the .config from an older kernel afterwards?
16:02<jdike-#uml->>sure
16:02<dang-#uml->>I thought that's what I did, but maybe I'm wrong somehwo.
16:06|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has quit [Quit: The only intuitive interface is the nipple; everything else is learned]
16:13|-|tyler29 [~tyler@ARennes-257-1-23-176.w81-53.abo.wanadoo.fr] has joined #uml
16:21|-|Abstract [~1065CB96D@85.198.62.18] has joined #uml
16:21<Abstract-#uml->>hi
16:22<karol-#uml->>Hello, Abstract.
16:22<Abstract-#uml->>hi karol
16:22<karol-#uml->>Is there anything you need help with?
16:22<Abstract-#uml->>any body know an ebook server
16:23<karol-#uml->>An excellent question. For #ebooks. Or somewhere.
16:23<karol-#uml->>Why come to #uml?
16:23<Abstract-#uml->>I looking for an ebooks and couldnt find it on web
16:23<Abstract-#uml->>join #ebook
16:23<Abstract-#uml->>?
16:23<karol-#uml->>Well, that one is empty.
16:24<karol-#uml->>But if you are looking for ebook servers, then going to the user mode linux irc channel ain't the best idea.
16:24<Abstract-#uml->>what is the server
16:24<Abstract-#uml->>?
16:24<karol-#uml->>This is irc.oftc.net
16:25<Abstract-#uml->>no linux irc chan
16:25<Abstract-#uml->>chan of this serv?
16:26<karol-#uml->>There is one.
16:26<karol-#uml->>Low traffic. If you are looking for a high traffic one, try #linux at irc.freenode.net
16:26|-|Infinito [argos@201-3-16-242.gnace701.dsl.brasiltelecom.net.br] has joined #uml
16:26<karol-#uml->>Lots of people there, 300+.
16:26<Abstract-#uml->>would plz send me all irc serv u know?
16:26|-|aindilis [~aindilis@75.146.96.197] has quit [Remote host closed the connection]
16:27<karol-#uml->>Abstract: http://www.irchelp.org/
16:28<Abstract-#uml->>tanx karl
16:28<karol-#uml->>Spend some time googling.
16:28<Abstract-#uml->>bye
16:28<Abstract-#uml->>ok
16:28<Abstract-#uml->>sure
16:29<Abstract-#uml->>bye
16:29|-|Abstract [~1065CB96D@85.198.62.18] has left #uml []
16:29<karol-#uml->>*sigh*
16:31<karol-#uml->>If anyone wants to ever anger me, just misspell my name. Grumble. Grumble. "Karl". Grr.
16:31<dang-#uml->>Heh.
16:32<dang-#uml->>Well, you can't blame the American name Carl, because he was obviously not a native english speaker...
16:32<jdike-#uml->>rm -rf magotori
16:32<jdike-#uml->>oops
16:32<karol-#uml->>Of course my last name is Swietlicki, my nickname is Magotari, and first name looks just like Karl or Carol. Nice set for a person very sensitive about typos.
16:33<dang-#uml->>Heh.
16:33<karol-#uml->>Back to work. Gotta make more patches. To make patches we need bugs or ideas. And someone needs to find those.
16:35<dang-#uml->>Gotta install gdb in my uml...
16:41<karol-#uml->>Oh. Wait. We do have a bug to work on. The stack <foo> crash.
17:01|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:15|-|tyler29 [~tyler@ARennes-257-1-23-176.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:28|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
17:31|-|tyler29 [~tyler@ARennes-257-1-108-209.w86-210.abo.wanadoo.fr] has joined #uml
17:52|-|tyler29 [~tyler@ARennes-257-1-108-209.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
18:20|-|remus [~remus@76.231.178.131] has quit [Remote host closed the connection]
18:23<karol-#uml->>Heh. Looks like the ptrace person replied, and they need to clarify what does 'UML still runs' means. I keep kicking myself for aborting works on the patch tester and testsuite.
18:24<karol-#uml->>At least this time I did not delete the source code, like I used to do when I got frustrated with my writing or photorgraphy.
18:31|-|remus [~remus@76.231.178.131] has joined #uml
18:35<jdike-#uml->>one would think that there wouldn't be much question about that
18:35<jdike-#uml->>if it boots, that's good
18:35<jdike-#uml->>if it doesn't, that's bad
18:39|-|dang [~dang@nemesis.fprintf.net] has joined #uml
19:10<karol-#uml->>Yeah, I thought as much.
19:10<karol-#uml->>I need to set up mutt or something, using gmail with lkml is ugly.
19:22|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
19:25|-|Baltam [~WIKIMOKI@c-5042e455.011-292-73746f34.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds]
19:33<karol-#uml->>Time to give in to the damn ininsomnia. Goodnight.
19:33|-|karol [~karol@chello089076070038.chello.pl] has quit [Quit: leaving]
19:58|-|mutley [~mutley@medussa.otago.ac.nz] has joined #uml
20:12<mutley-#uml->>Could someone point me to information regarding this 'sysemu' patch?
20:15<caker-#uml->>google.com ?
20:16<mutley-#uml->>Ah, had been trying PTRACE_SYSEMU instead of sysemu. Stupid. Thanks.
20:27|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
20:36<mutley-#uml->>I grabbed the latest patch there for the host, but it fails a lot while patching my 2.6.18 kernel
20:37<caker-#uml->>the patch is for UML, and is already in mainline
20:37<caker-#uml->>oh wait
20:37<caker-#uml->>it's for the host, and already in mainline :)
20:38<mutley-#uml->>Ah, good then. When did it go in? I don't recall seeing it...
20:38<caker-#uml->>a long time ago, IIRC. I helped test it
20:38<caker-#uml->>somewhere around 2.6.10 ?
20:40<mutley-#uml->>So its not a configurable option?
20:40<caker-#uml->>nope
20:40<caker-#uml->>UML just uses it if it detects the support from the host
20:42<caker-#uml->>you know -- this may be a part of the skas3 patch -- but you'd need to check that to be sure
20:42<caker-#uml->>I only run skas3 hosts .. and again, this was done so long ago I can't recall -- sorry
20:43<mutley-#uml->>Good, pity it doesn't say whether or not it found it during startup. Where do I find the option for the MADV_REMOVE facility?
20:46<caker-#uml->>hmm
20:47<caker-#uml->>Jeff had patches for that around 2.6.16/17 ..
20:49<caker-#uml->>it's an "mconsole config mem=[+-]n[KMG]" call
20:49<mutley-#uml->>So its not in main?
20:49<caker-#uml->>should be
20:49<mutley-#uml->>I know my guest is looking for it, but at startup says that it can't be found, which got me thinking.
20:50<caker-#uml->>Checking host MADV_REMOVE support... ?
20:50<mutley-#uml->>yup
20:50<caker-#uml->>what's it say?
20:50<mutley-#uml->>I'm using an otherwise stock Debian kernel (ie. practically everything in, plus skas patches)
20:51<mutley-#uml->>not found, IIRC
20:55<mutley-#uml->>Ah, that's right, I can't at the moment, I'd have to reboot into that kernel. Was having other issues.
20:57<mutley-#uml->>Hmm, so hotplug memory won't do my any good unless I actively change it? I was hoping it was something that would allow me to use even less memory (density is of prime importance)
21:00<mutley-#uml->>Thanks for all that. I'll reboot and get back to work trying to get my terminals back.
21:00|-|mutley [~mutley@medussa.otago.ac.nz] has quit [Quit: Leaving]
21:26|-|Infinito [argos@201-3-16-242.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
---Logclosed Fri Nov 30 00:00:14 2007