Back to Home / #uml / 2007 / 07 / Prev Day | Next Day
#uml IRC Logs for 2007-07-27

---Logopened Fri Jul 27 00:00:20 2007
---Logclosed Fri Jul 27 00:22:59 2007
---Logopened Fri Jul 27 00:23:02 2007
00:23|-|mikegrb_ [~michael@mail.thegrebs.com] has joined #uml
00:23|-|Ekipa kanalu #uml: Wszystkich: 32 |-| +op [0] |-| +voice [0] |-| normalnych [32]
00:23|-|jvaughan [~jvaughan@ln.turnip.org.uk] has quit [Remote host closed the connection]
00:23|-|Netsplit synthon.oftc.net <-> charm.oftc.net quits: mikegrb, fo0bar
00:24|-|Kanal #uml zsynchronizowany w 84 sekundy
00:25|-|mikegrb_ Your nick is now mikegrb
00:31|-|fo0bar [fo0bar@feh.colobox.com] has joined #uml
00:43|-|balbir [~balbir@122.167.11.149] has quit [Ping timeout: 480 seconds]
00:53|-|linbot` [~supybot@ns.theshore.net] has joined #uml
00:53|-|linbot [~supybot@ns.theshore.net] has quit [Read error: Connection reset by peer]
01:03|-|linbot` changed nick to linbot
01:05|-|jvaughan [~jvaughan@ln.turnip.org.uk] has joined #uml
01:42|-|balbir [~balbir@59.145.136.1] has joined #uml
02:12|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
02:24|-|horst [~horst@a89-182-73-179.net-htp.de] has joined #uml
02:30|-|horst [~horst@a89-182-73-179.net-htp.de] has quit [Remote host closed the connection]
03:33|-|alb [~net@host9.200-117-158.telecom.net.ar] has joined #uml
03:35|-|albertito [~net@host47.190-31-41.telecom.net.ar] has quit [Ping timeout: 480 seconds]
03:50|-|balbir [~balbir@59.145.136.1] has joined #uml
04:01|-|balbir [~balbir@59.145.136.1] has quit [Read error: Operation timed out]
04:02|-|balbir [~balbir@59.145.136.1] has joined #uml
04:31|-|SixF9 [africa@sixnine.us] has joined #uml
06:18|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
06:25|-|richardw [~richardw@M340P008.adsl.highway.telekom.at] has joined #uml
06:40|-|aroscha [~aroscha@chello080108014027.36.11.vie.surfer.at] has joined #uml
07:01|-|horst [~horst@a89-182-93-106.net-htp.de] has joined #uml
07:30|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
07:40|-|tyler [~tyler@adsl196-145-201-206-196.adsl196-7.iam.net.ma] has joined #uml
07:52|-|balbir [~balbir@59.145.136.1] has joined #uml
08:00|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
08:13|-|krau [~cktakahas@200.184.118.132] has joined #uml
08:17|-|aroscha_ [~aroscha@chello080108014027.36.11.vie.surfer.at] has joined #uml
08:17|-|aroscha [~aroscha@chello080108014027.36.11.vie.surfer.at] has quit [Read error: Connection reset by peer]
08:29|-|aroscha [~aroscha@chello080108014027.36.11.vie.surfer.at] has joined #uml
08:31|-|aroscha_ [~aroscha@chello080108014027.36.11.vie.surfer.at] has quit [Ping timeout: 480 seconds]
08:35|-|balbir [~balbir@59.145.136.1] has joined #uml
08:59|-|aroscha [~aroscha@chello080108014027.36.11.vie.surfer.at] has quit [Quit: aroscha]
09:01|-|theclaw [~theclaw@p5494C702.dip.t-dialin.net] has joined #uml
09:01<theclaw>hi there
09:01<theclaw>do i need to patch my host kernel (2.6.20) to run the guest with skas enabled?
09:04<caker>theclaw: skas3, yes. skas0, no
09:09<theclaw>and whats the difference from a user-perspective?
09:09<caker>from an end user perspective, none
09:10<caker>a slight performance hit with skas0 over skas3
09:10<theclaw>so theres absolutely no reason to favor skas3 over skas0?
09:10<theclaw>is there somewhere up to date documentation?
09:10<caker>google?
09:11<theclaw>..
09:11<theclaw>all the documentation in the wiki is out-dated
09:11<caker>bah .. jeff moved his site around
09:11<theclaw>it says nothing about skas0
09:11<caker>http://user-mode-linux.sourceforge.net/old/ <--
09:12<caker>http://lwn.net/Articles/142494/
09:12<caker>I only run skas3, fwiw
09:12|-|jdike [~jdike@96.233.58.249] has joined #uml
09:12<jdike>Hi guys
09:12<caker>jdike: hi guy
09:13<caker>damn, beat me to it
09:13<jdike>hehe
09:13<jdike>have linbot do it
09:13[~]caker waits for the movers to arrive
09:13<jdike>it's probably faster than me
09:13<caker>moving = pain
09:14<jdike>caker, BTW have you checked that /proc crash with something newer than 2.6.21?
09:14<caker>no, been too busy packing up two tons of crap from my apartment
09:14<caker>it'll be a few days before I'm re-settled
09:15<caker>was there anything useful generated by my kernel when you triggered it?
09:16<jdike>not really
09:17<jdike>it didn't have debugging symbols IIRC
09:17<theclaw>do i need a patched glibc in order to use uml, or can i simply install a i386-debian?
09:17<jdike>standard libc
09:18<theclaw>ic
09:18|-|baroni_ [~baroni@tera.lsi.usp.br] has joined #uml
09:18<theclaw>jdike: btw, this wiki page is really out-dated: http://uml.jfdi.org/uml/Wiki.jsp?page=BuildingHostKernel
09:18<jdike>well, it ain't mine
09:19<theclaw>didn't know
09:20<jdike>caker, I take that back
09:20<jdike>lemme have another look
09:21<caker>jdike: hmm .. I think I stripped it .. lemme see if I have it clothed
09:22<jdike>yeah, that's why
09:22<caker># ll linux-unstripped
09:22<caker>-rwxr-xr-x 1 root root 90709293 May 6 17:51 linux-unstripped
09:22<caker>:)
09:22<jdike>bwahaha
09:22<jdike>that's the same one?
09:22<caker>Yeah
09:22<jdike>gimme URL
09:24<caker>http://www.theshore.net/~caker/uml/2.6.21.1-linode32-unstripped.bz2
09:25<jdike>it's a little strange it doesn't happen with current UML with the same config
09:25|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has joined #uml
09:25<caker>it is patched with openafs....
09:25<jdike>geez, 30M compressed, 90M uncompressed
09:26<caker>lotsa debug stuffs
09:26<jdike>yeah, gotta love symbol tables
09:27<jdike>caker, BTW UML is noticably faster with debugging turned off
09:27<caker>oh ... that sucks
09:27<caker>at least for generating useful cores for you
09:28<jdike>yup
09:28<caker>guess I'll be turning that stuff back off next build :)
09:32<jdike>open = 0x82b331f <afs_csdb_open>
09:32<jdike>I don't suppose anyone has tried that on a physical box with AFS?
09:34<caker>unknown... I added by user request
09:34<caker>figures it's the culprit
09:35<jdike>the file it crashed on was /proc/fs/afs/CellServDB
09:36<jdike>so I'll consider this to be an AFS bug until there's evidence that it's not
09:41|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
09:42|-|dang [~dang@aa-gw.nexthop.com] has joined #uml
09:44<caker>jdike: figures .. sorry bout that
09:49<jdike>np
09:59<theclaw>isn't the host fs a security problem?
10:00<caker>theclaw: how so?
10:00<theclaw>if the guest gets compromised it can be used to access the host fs
10:01<caker>run it as an unprivileged user. Also, I've never had a user break out of UML
10:01<caker>just make sure to disable modules in your um kernel
10:01<jdike>theclaw, you have to assume the guest is compromised anyway
10:01<jdike>the owner has root access
10:02<jdike>so you make sure that the kernel itself is secure
10:03<theclaw>hmm
10:04<jdike>wrt hostfs, UML accesses it with the permissions of the UML user on the host
10:04<jdike>so that's no different from the UML owner having an normal user account on the host
10:05<jdike>and if you confine the host mount, the UML only has access within a given directory
10:06<theclaw>hmm
10:06<theclaw>how much "power" does the root in the uml-guest have? can it modify the memory of the guests kernel?
10:07<jdike>with modules disabled, no
10:10<dang>jdike: Really? I've heard it asserted by Alan Cox that root user can do that on a normal unix box even without modules...
10:10<dang>I realize they won't have the hardware workarounds in UML; is that enough?
10:10<jdike>with access to /dev/kmem, yes
10:11<dang>(I've never had to worry; I've never had unauthorized users on my UML)
10:11<jdike>but I think that doesn't work any more
10:11<dang>That's nice to know.
10:12<theclaw>when modifying /dev/kmem, is it the same as modifying /proc/$pid/mem on the host, when $pid is the pid of the guest?
10:12<jdike>no
10:12<jdike>kmem is kernel memory
10:13<theclaw>but i thought the kernel *is* the user process in case of uml
10:13<jdike>/proc/$pid/mem is the process's memory image
10:13<jdike>Oh whoops
10:13<jdike>yes, it should be similar
10:13<jdike>there may be differences between how the mem and kmem drivers work though
10:14<theclaw>okay
10:15|-|tyler_ [~tyler@adsl196-210-205-206-196.adsl196-7.iam.net.ma] has joined #uml
10:17|-|richardw_ [~richardw@M513P018.adsl.highway.telekom.at] has joined #uml
10:18<theclaw>just trying to compile my first uml-kernel, but it states:
10:18<theclaw>arch/um/os-Linux/aio.c: In function 'do_aio':
10:18<theclaw>arch/um/os-Linux/aio.c:80: error: unknown field 'aio_reserved3' specified in initializer
10:18<jdike>heh
10:19<theclaw>linux-2.6.22.1
10:19<jdike>I sent a patch for that on Wed
10:19<theclaw>oh
10:20<theclaw>or is this patch related to some feature i don't really need and could disable?
10:20|-|tyler [~tyler@adsl196-145-201-206-196.adsl196-7.iam.net.ma] has quit [Ping timeout: 480 seconds]
10:20<theclaw>s/patch/error/
10:20<jdike>http://marc.info/?l=user-mode-linux-devel&m=118521982227031&q=raw
10:20<jdike>just apply that
10:22<theclaw>works now
10:22<theclaw>thx
10:22<theclaw>and thanks btw for all the help ;)
10:23<jdike>np
10:23|-|hfb [~hfb@pool-72-87-254-188.lsanca.dsl-w.verizon.net] has joined #uml
10:23|-|richardw [~richardw@M340P008.adsl.highway.telekom.at] has quit [Ping timeout: 480 seconds]
10:23|-|hfb [~hfb@pool-72-87-254-188.lsanca.dsl-w.verizon.net] has left #uml []
10:23<jdike>One patch off to akpm
10:24<jdike>another 1800-line patch needs breaking up
10:24<dang>jdike: I want an opinion...
10:24<jdike>I got lots
10:24<jdike>yes, no, maybe
10:25<jdike>need any more?
10:25<dang>I'm the maintainer for usermode-sources for gentoo.
10:25<dang>:)
10:25<jdike>is that UML?
10:25<dang>It's intended to be a guest kernel for UML.
10:25<dang>(I didn't name it, I inherited the name...)
10:26<dang>Currently, it's 2.6.18.<something>-bb2
10:26<dang>Is there some other patchset I should be tracking?
10:26<dang>Should I just be tracking mainline + fixes you send to the list?
10:26<jdike>the bb patches are somewhat experimental
10:27<dang>Yes, I know.
10:27<jdike>the -bs patches are supposed to be more stable
10:27<jdike>all this with the caveat that BB seems to have vanished for the summer
10:27<jdike>as far as I'm concerned, mainline + stable are good to track
10:27<dang>:) Well, no -bb updates since 2.6.18 anyway...
10:27<dang>Okay.
10:27<theclaw>which option do i have to enable in order to get uml compiled with skas0-support?
10:27<jdike>none
10:28<theclaw>oh, great
10:28<jdike>well, CONFIG_MODE_SKAS, but that's on by default
10:28<dang>But if it's just mainline + stable, there's not a whole lot of point to a separate kernel, yes?
10:28<theclaw>so the old tt-mode doesn't exist any longer?
10:28<jdike>tt mode is still there, but terminally broken
10:28<dang>I thought about skas3, but that needs host changes...
10:29<jdike>dunno what you mean by no point to a separate kernel
10:29<jdike>UML by its nature is a separate kernel
10:29|-|baroni_ [~baroni@tera.lsi.usp.br] has quit [Read error: No route to host]
10:29<dang>Right, I meant a separate kernel package.
10:30<dang>The user can just use the same kernel package as the main system (or the vanilla one from kernel.org)
10:30<jdike>Oh
10:30<jdike>are packages source-only?
10:30<dang>Yes. This is gentoo afterall... :)
10:30<jdike>right, I was jogging some unused brain cells
10:31<dang>I've done binary packages for work, but not for general usage...
10:31<jdike>yes, you don't need a separate package, just build the existing one for UML
10:32<jdike>I try to make mainline (2.6.x) as bug-free as I know how
10:32<jdike>and when I fail at that, I cover my tracks with -stable
10:33<dang>BRB
10:40|-|baroni_ [~baroni@tera.lsi.usp.br] has joined #uml
10:57<theclaw>i get the following error when building uml:
10:57<theclaw>http://rafb.net/p/M3VHwE15.html
10:59<jdike>Apply http://marc.info/?l=linux-kernel&m=118433794927385&q=raw
11:00<theclaw>thanks
11:00<theclaw>will these patches get into mainline?
11:01<theclaw>(as it says 2.6.17)
11:03<jdike>heh
11:03<jdike>that's my mainline directory
11:03<jdike>I don't change the name because it's in my shell history
11:04<jdike>I think this is all in -rc1
11:04<theclaw>2.6.23-rc1?
11:05<jdike>yup
11:05<theclaw>but in the patch it says its patched against 2.6.17?
11:06<jdike>no
11:06<jdike>that's just the name of the directory
11:06<jdike>what's in there is currently -rc1
11:07<theclaw>oh now i got the point ;)
11:07<theclaw>i see, really huge thanks
11:10<theclaw>what does "ubda" stand for?
11:10<jdike>UML Block Device A
11:11<theclaw>okay
11:28<jdike>4 more patches ready
11:33|-|kos_tom [~thomas@humanoidz.org] has joined #uml
11:40<jdike>now for the vde thing
12:13|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has quit [Read error: No route to host]
12:14|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has joined #uml
12:30|-|kokoko1 [~Slacker@203.148.65.8] has joined #uml
12:36|-|Netsplit synthon.oftc.net <-> oxygen.oftc.net quits: baroni_
12:37|-|Netsplit over, joins: baroni_
12:38|-|balbir [~balbir@122.167.14.223] has joined #uml
12:41|-|helloworld [~mbrown@spk-bri.totalsol.com] has joined #uml
12:42|-|the_hydra [~the_hydra@125.164.96.110] has joined #uml
12:51|-|tyler_ [~tyler@adsl196-210-205-206-196.adsl196-7.iam.net.ma] has quit [Remote host closed the connection]
12:57|-|jjkola [~jjkola@dsl-olubrasgw1-fe56fb00-241.dhcp.inet.fi] has joined #uml
12:57|-|theclaw [~theclaw@p5494C702.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
12:58<jjkola>hello
12:58<the_hydra>hello
12:59<jjkola>jdike: I got you some core dumps to check
13:03<jdike>jjkola, what's the problem?
13:05<jjkola>at least one of them is from the situation where uml is hogging cpu
13:05<jjkola>you asked me to get core dumps from the situation
13:05<jdike>on boot?
13:05<jdike>yeah, I'm just trying to remember, and failing :-)
13:07<jjkola>when you checked the backtrace you were saying something about page fault and that it was failing, maybe some memory corruption, or something like that
13:08<jdike>Oh yes
13:08<jdike>the page fault handler segfaulting
13:08<jjkola>yes, that was it
13:08<jdike>can you put the core file and binary someplace that I can grab them?
13:09<jjkola>ok
13:09<jdike>or, alternatively, give me a login on the box
13:09<jdike>whichever is easier
13:10<jdike>did you enable slab debugging?
13:12<jjkola>I forgot that, sorry
13:25<jjkola>I have nearly uploaded the core to website which provides file services, I'll tell you the adress when it has uploaded
13:28<jjkola>I'm now uploading the binary
13:35<jjkola>ok, I have uploaded both of them
13:36<jjkola>if somebody else also wants to check them I can give the addresses for the files
13:36<the_hydra>unfortunately, I am using lousy link, so I can't help
13:44<jdike>ya know
13:44<jdike>if you only have one file, putting it in a tarball is kind of waste of time
13:45<the_hydra>jdike: good advice
13:45<jdike>jjkola, do you get a decent stack trace from that linux and core
13:45<jdike>?
13:45<jdike>I get garbage
13:46<jjkola>how do I do that?
13:46<the_hydra>gdb uml-binary <core file>
13:46<the_hydra>and type "bt"
13:46<jjkola>ah
13:47<the_hydra>at least I can help with that inside this lousy link
13:47<jdike>hehe
13:47<the_hydra>jdike: probably I should consider moving abroad
13:48<jdike>where?
13:48<jjkola>ops, I accidentally sent wrong binary file as I have several kernel to choose
13:48<the_hydra>no wonder :D
13:49<the_hydra>just stay calm :)
13:50<jjkola>I'll upload the right one to the server
13:52|-|ram [~ram@pool-71-245-108-202.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
14:00<jjkola>I have now uploaded the right binary
14:03|-|aroscha_ [~aroscha@vivilokal.funkfeuer.at] has joined #uml
14:03|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has quit [Read error: Connection reset by peer]
14:08<jdike>better
14:09<the_hydra>good to hear
14:13<jdike>32K frames up the stack and the top is nowhere in sight
14:14[~]jdike rejects his own post to uml-user
14:15<the_hydra>why?
14:17<jdike>I accidentally included a whole mass of data from the message I was replying to
14:17<jdike>and it hit the list size limit
14:17<the_hydra>oh...
14:18|-|aroscha [~aroscha@wlan-237-224.pns.univie.ac.at] has joined #uml
14:19|-|aroscha_ [~aroscha@vivilokal.funkfeuer.at] has quit [Read error: No route to host]
14:28|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
14:38<jdike>1M frames and counting
14:41|-|aroscha_ [~aroscha@vivilokal.funkfeuer.at] has joined #uml
14:41<the_hydra>wow, 1M? just for stack frames?
14:42<jdike>yup
14:42<jdike>recursive segfaults are like that
14:42<the_hydra>oh..gee
14:47|-|aroscha [~aroscha@wlan-237-224.pns.univie.ac.at] has quit [Ping timeout: 480 seconds]
14:52<jdike>jdike 10367 50.2 55.9 764396 579016 pts/1 R+ 15:07 20:58 gdb linux www.c
14:52<jdike>hmm
15:35|-|the_hydra [~the_hydra@125.164.96.110] has left #uml []
15:57<fo0bar>jdike: speaking of debugging, is the documentation in CONFIG_FORCED_INLINING still correct? should I have it disabled when compiling with gcc4?
16:12|-|jjkola1 [~jjkola@dsl-olubrasgw1-fe56fb00-241.dhcp.inet.fi] has joined #uml
16:12|-|jjkola [~jjkola@dsl-olubrasgw1-fe56fb00-241.dhcp.inet.fi] has quit [Read error: Connection reset by peer]
16:27<jdike>it won't be different for UML than anything els
16:27<jdike>e
16:27<jdike>if that's what you're asking
16:38|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has joined #uml
16:38|-|aroscha_ [~aroscha@vivilokal.funkfeuer.at] has quit [Read error: Connection reset by peer]
16:43|-|helloworld [~mbrown@spk-bri.totalsol.com] has quit [Quit: leaving]
17:07|-|aroscha [~aroscha@vivilokal.funkfeuer.at] has quit [Quit: aroscha]
17:17|-|dang [~dang@aa-gw.nexthop.com] has quit [Quit: Leaving.]
17:25|-|jdike [~jdike@96.233.58.249] has quit [Quit: Leaving]
17:29|-|jjkola1 changed nick to jjkola
17:37|-|kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps]
17:38|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
17:46|-|horst [~horst@a89-182-93-106.net-htp.de] has quit [Remote host closed the connection]
17:49|-|baroni_ [~baroni@tera.lsi.usp.br] has quit [Read error: Operation timed out]
18:18|-|rw__ [~richardw@M394P005.adsl.highway.telekom.at] has joined #uml
18:24|-|richardw_ [~richardw@M513P018.adsl.highway.telekom.at] has quit [Ping timeout: 480 seconds]
18:31|-|dang [~dang@nemesis.fprintf.net] has joined #uml
18:51|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
18:51<jjkola>night
18:52|-|jjkola [~jjkola@dsl-olubrasgw1-fe56fb00-241.dhcp.inet.fi] has quit [Quit: *pop*]
19:10|-|rw__ [~richardw@M394P005.adsl.highway.telekom.at] has quit [Quit: Leaving]
19:25|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
19:55|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
22:59|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
22:59|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
---Logclosed Sat Jul 28 00:00:45 2007