Back to Home / #uml / 2007 / 04 / Prev Day | Next Day
#uml IRC Logs for 2007-04-10

---Logopened Tue Apr 10 00:00:46 2007
00:16<shze>i have a uml running, with net iface to the host. what do i need to change to a connection to the inet?
00:16<shze>routing, what else?
00:38|-|ram [] has joined #uml
02:02|-|shze [] has left #uml [Konversation terminated!]
02:19|-|aroscha [] has joined #uml
02:29|-|Ancalagon [] has joined #uml
02:59|-|kokoko1 [~Slacker@] has quit [Read error: Operation timed out]
03:06|-|Ancalagon [] has quit [Quit: Chatzilla 0.9.75 [Firefox]]
03:20|-|Ancalagon [] has joined #uml
03:24|-|Urgleflogue [] has quit [Ping timeout: 480 seconds]
03:40|-|motp [~motp@] has joined #uml
05:23|-|kokoko1 [~Slacker@] has joined #uml
05:33|-|motp [~motp@] has quit [Quit: Leaving]
05:38|-|Shaun2222 [] has joined #uml
06:07|-|krau [~cktakahas@] has joined #uml
06:49|-|krau [~cktakahas@] has quit [Read error: Operation timed out]
06:55|-|aroscha [] has quit [Quit: aroscha]
07:01|-|krau [~cktakahas@] has joined #uml
07:06|-|krau [~cktakahas@] has quit [Quit: Leaving]
07:14|-|krau [~cktakahas@] has joined #uml
07:33|-|aroscha [~aroscha@] has joined #uml
07:33<aroscha>question: what 64 bit systems are most UML developers using?
07:33<aroscha>i mean which OS etc?
07:34<peterz>linux of course
07:53|-|jdike [] has joined #uml
07:53<jdike>Hi guys
07:54<peterz>Ahoy jeff!
07:58<aroscha>hi jdike
07:59<caker>good morning
07:59<aroscha>peterz: yes, i meant which distro of course ;-)
07:59<peterz>aroscha: doesn't really matter, whatever suits you best
07:59[~]aroscha is trying amd64 ubuntu feisty fawn + UML now
08:00<aroscha>lets see if that works
08:00<aroscha>peterz: well, I had some surprises on 2.6.x and 64 bit
08:00<peterz>works here
08:01<jdike>gcc invoked oom-killer: gfp_mask=0xd0, order=2, oomkilladj=0
08:01<jdike>Normal: 2319*4kB 2*8kB 3*16kB 0*32kB 3*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2
08:01<jdike>shouldn't that have succeeded?
08:02<peterz>depends on the watermarks
08:06<caker>jdike: for this dump core thing -- it's supposed to generate a core file (where? cwd of the UML?) after I send it a SIGSEGV, right?
08:06<caker>nothing's happening
08:06<jdike>yeah, its cwd
08:06<jdike>what does ulimit -c say?
08:06[~]caker checks /proc/<pid>/cwd
08:07<jdike>well, it should say "unlimited"
08:07<jdike>0 means no core dumps
08:07[~]caker fixerates
08:07<caker>you mentioned that -- I figured 0 meant unlimited
08:10<caker>hmm, still nothing.. perms look fine
08:12<jdike>what happens?
08:12<caker>nothing -- uml keeps running, no core
08:13<caker>adding a printk or two now...
08:14<jdike>you're hitting the main UML pid?
08:14<jdike>and it just keeps on going?
08:15<caker>yeah -- lowest pid in the tree
08:15<aroscha>jdike: my problems yesterday with amd64 and PAGE_SIZE... you remember? Could that be related to the machine having 8 GB RAM?
08:15<jdike>it has to do with the host distro not providing a PAGE_SIZE in its headers and UML expecting one
08:17|-|aroscha_ [~aroscha@] has joined #uml
08:17|-|aroscha [~aroscha@] has quit [Read error: Connection reset by peer]
08:18<caker>I added a printk to the top of os_dump_core -- no output inside the UML upon kill -s SIGSEGV <pid>, no core... maybe I botched something making this work under 2.6.20 (although the patch is totally obvious)
08:21<jdike>aroscha_, that patch I did last night didn't do the trick?
08:21<aroscha_>no :(
08:21<jdike>what did it do?
08:21<aroscha_>jdike: I am trying the whole thing now on ubuntu 7.04
08:21<jdike>it couldn't have
08:21<aroscha_>same error message about PAGE_SIZE not defined but just simply in a different .c file
08:21<jdike>well, that's not the same
08:22<jdike>rc6-mm1 has this fixed
08:22<aroscha_>here is a copy&paste what I wrote in the evening
08:22<aroscha_>aroscha: concerning the rc6-mm1 PAGE_SIZE thing: I have:
08:22<aroscha_>[01:34am] aroscha: [aaron@texas os-Linux]$ pwd
08:22<aroscha_>[01:34am] aroscha: start_up.c:110: stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC,
08:22<aroscha_>[01:34am] aroscha: start_up.c:114: sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *);
08:22<aroscha_>[01:34am] aroscha: start_up.c:158: if(munmap(stack, PAGE_SIZE) < 0)
08:22<aroscha_>[01:34am] aroscha: start_up.c:538: size = (buf.st_size + UM_KERN_PAGE_SIZE) & ~(UM_KERN_PAGE_SIZE - 1);
08:22<aroscha_>[01:34am] aroscha: start_up.c:547: iomem_size += new->size + UM_KERN_PAGE_SIZE;
08:22<aroscha_>[01:35am] aroscha: so I do have that
08:22<aroscha_>[01:35am] aroscha: kernel was linux-2.6.21-rc6.tar from
08:22<aroscha_>[01:36am] aroscha: and patched with linux-2.6.21-rc6.tar
08:22<aroscha_>[01:36am] aroscha: oops
08:22<aroscha_>[01:36am] aroscha: -rw-r--r-- 1 aaron aaron 25448146 Apr 8 23:09 2.6.21-rc6-mm1
08:22<aroscha_>[01:36am] aroscha: so, I guess that must have been correct
08:22<aroscha_>for the long post
08:23<jdike>that's your best bet unless I decide enough people are hitting this to warrant it going into -stable
08:23<caker> <-- jdike. Something odd about 2.6.20 that wouldn't allow this to work, or is this PEBKAC
08:24<jdike>you're not even hitting panic
08:24<jdike>unless you do that, nothing is going to happen
08:26<caker>I thought the kill SIGSEGV would throw it into a panic -- or does that just enable core dumps
08:28<jdike>it should panic it, that's the point
08:29<caker>mm, the host kernel is ancient, and has a buggy skas version (the one that didn't let strace work inside UML)
08:32<caker>ok, it works without a rootfs (forcing a panic)
08:33<caker>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0); blah blah; Aborted (core dumped); ./core.13370 exists :)
08:35<aroscha_>jdike: just out of curiosity: did you test it on redhat? ... now the compile works great on ubuntu. compiled and runs. Just the host has no SKAS3 by default.
08:35<aroscha_>so i guess it is a complete CentOS bug
08:35<jdike>OK, that works too
08:35<jdike>test what?
08:36<aroscha_>the 2.6.20* compilation on redhat
08:36<jdike>caker, now gdb UML and the core file to make sure you have a good stack
08:36<aroscha_>stock redhat
08:36<aroscha_>or FC*
08:37<aroscha_>yes, well... so the bugreport is: stock CentOS 4.92 has broken .h files for compiling UML 2.6.20* kernels
08:37<jdike>the bug report is more likely, UML is using symbols that it shouldn't
08:38<aroscha_>ok :)
08:38<jdike>that's why I'm fixing UML rather than insisting that the distros fix their headers
08:38<caker>Core was generated by `./2.6.20-linode28-dump-core/linux con=null con0=fd:0,fd:1 stderr=1'.
08:38<caker>Program terminated with signal 6, Aborted.
08:38<caker>#0 0x083e3e51 in kill ()
08:38<caker>good stuff?
08:39<aroscha_>jdike: so in case there is anything else that I can test on CentOS please let me know
08:39<jdike>bad stuff
08:39<jdike>caker, do you enable debugging symbols?
08:39<jdike>aroscha_, OK
08:39<jdike>do you have a working UML?
08:40<caker>no ... do-over with symbols enabled?
08:42|-|arun [~arun@chobie.cs.Virginia.EDU] has quit [Ping timeout: 480 seconds]
08:53<caker>jdike: sorry to be a total idiot with this -- CONFIG_DEBUG_INFO?
08:53<caker>also CONFIG_KALLSYMS=y (which was already set)
08:53<jdike>yup, that works
09:03<kokoko1>too early today ? :)
09:04<jdike>you're late
09:07<kokoko1>hey both of you sound very good in the voice interview, I hope one day they will also reach me for interview :D
09:07<kokoko1>jdike, you got a man voice :)
09:07<jdike>was that unexpected?
09:07<kokoko1>lol imean you must be workng in movies :p
09:07<jdike>I hate listening to my voice
09:08<kokoko1>ah you got very nice voice dude
09:08<jdike>and a face for radio
09:08<kokoko1>few days back heard an interview of slackware guru Patrick volkerding, tell you what i dn't like his voice :(
09:09<kokoko1>caker, looks busy with his new data center
09:10<kokoko1>heh he is serious about kvm got a machine with VT support :)
09:11<jdike>I'm expecting reports from Atlanta about massive traffic jams due to some dude dropping a bunch of servers off the back of his truck onto the highway
09:27<caker>Core was generated by `./2.6.20-linode28-dump-core/linux con=null con0=fd:0,fd:1 stderr=1'.
09:27<caker>Program terminated with signal 6, Aborted.
09:27<caker>#0 0x083e3e41 in kill () at net/8021q/vlan.c:799
09:27<caker>799 return -EINVAL;
09:27<caker>do I win the prize now?
09:29<jdike>there should be more like 10 frames
09:30<jdike>it should look more like
09:30<caker>what did I miss?
09:33<jdike>How about CONFIG_FRAME_POINTER=y?
09:34|-|Ancalagon [] has quit [Quit: Chatzilla 0.9.75 [Firefox]]
09:59<caker>bah, same with CONFIG_FRAME_POINTER=y added in
10:00<caker>could this be FC2's toolchain or the ancient host kernel?
10:02<jdike>try with defconfig
10:12<caker>geez, this system is wacky...
10:12<caker>./2.6.20-linode28-dump-core/linux con=null con0=fd:0,fd:1 stderr=1
10:12<caker>Checking that ptrace can change system call numbers...OK
10:12<caker>hangs there
10:15[~]caker moves to a new environment
10:18<caker> :)
10:22<jdike>looks good
10:24<caker>all right ... I'll roll this out today
10:24<caker>bugs beware
10:25[~]caker can foresee partitions full of cores in his future
11:54|-|ram [] has quit [Read error: Operation timed out]
12:32|-|kos_tom [] has joined #uml
12:42|-|ram [] has joined #uml
12:51|-|ram [] has quit [Ping timeout: 480 seconds]
12:56|-|ram [] has joined #uml
13:02|-|pgstudy [] has joined #uml
13:27|-|ElectricElf [] has quit [Ping timeout: 480 seconds]
13:32|-|ElectricElf [] has joined #uml
13:58|-|tchan [] has quit [Quit: WeeChat 0.2.5-cvs]
14:00|-|mjf [] has joined #uml
14:11|-|tchan [] has joined #uml
14:18|-|tchan [] has quit [Quit: WeeChat 0.2.5-cvs]
14:20|-|tchan [] has joined #uml
15:01<aroscha_>maybe a stupid question: how do i find out the memory (rss) of all processes summed up which belong to a certain UML instance?
15:02<jdike>from the host, you mean?
15:04<aroscha_>yes. On the host print out all the total rss memory usage of each UML guest and all its processes summed up
15:04<jdike>== the RSS of the main process
15:04<aroscha_>ah, so easy
15:05<aroscha_>got confused since i saw so many processes in ps
15:06<jdike>the resident pages of the processes are shared with the main kernel process
15:07<aroscha_>code segments only that is ?
15:07<aroscha_>of course
15:08<jdike>all data
15:08<aroscha_>ah ok.
15:08<jdike>the processes live entirely within the UML's physical memory
15:08<aroscha_>but the code segments of guest instance A is shared with the code segment of guest instance B ?
15:09<jdike>Oh, yes
15:09<aroscha_>cool, very efficient
15:10<jdike>but if you want the memory usage of a particular UML, just look at the main process
15:10<jdike>and split the text between them
15:14|-|arun [~arun@chobie.cs.Virginia.EDU] has joined #uml
15:22|-|da-x [] has quit [Remote host closed the connection]
15:32|-|pgstudy [] has quit [Read error: Connection reset by peer]
15:33|-|ram [] has quit [Remote host closed the connection]
15:37|-|mjf [] has quit [Quit: leaving]
15:43<aroscha_>hm, i guess i will have a problem with the consoles in case I start 1000 instances?
15:43<aroscha_>like the number of consoles will not be enough (?)
15:44<jdike>what are you using for consoles?
15:45<aroscha_>at the moment just the /dev/ptsX connection
15:47<jdike>maybe not enough of them
15:47<jdike>any number can attach to a port, I think
15:47<jdike>no, that won't work
15:47<jdike>any number of consoles within a UML can, but not multiple UMLs
15:47<jdike>however, there are 1000s of ports
15:48<jdike>con=port:$[ 10000 + $uml_number ]
15:49<aroscha_>but there are people who were already running thousands of UML instances as far as I know ?
15:49<jdike>not on a single box
15:50<jdike>just think about the memory requirements
15:51<aroscha_>8 gig is enough?
15:51<aroscha_>hehe, that is why i was asking the questions before
15:52<jdike>8G/1000 == enough to boot a distro?
15:52<aroscha_>currently my distro is 4mB
15:52<aroscha_>so i could run 2000 instances
15:53<jdike>how much memory do you need to give UML to boot it?
15:53<aroscha_>and if the kernel code segments are shared then that is extra savings
15:53<aroscha_>my network protocol daemon that i want to test is 300kB or so
15:54<aroscha_>so , basically I am doing a network simulator
15:54<jdike>that wasn't the question
15:54<aroscha_>memory requirement for that is probably 2mb max
15:54<jdike>mem=XM - what's the minimal value of X?
15:54<jdike>have you tested 2?
15:54<aroscha_>so hmm.... i guess with 3 mb it should be fine
15:54<aroscha_>no, not yet
15:56<jdike>that would be the first thing to do
15:56|-|holst [] has joined #uml
15:57<holst>im trying to start a uml by "routing" the con{0,1} to a pty; following this directions:
15:57<holst>however i seem to have some problems getting "it" up
15:58<holst>anyone here done that and would be kind to give me a few pointers how to debug my problem?
15:58<aroscha_>jdike: ok, got you! thanks!
15:59<holst>the on-screen logging stops after:
15:59<holst>Checking advanced syscall emulation patch for ptrace...OK
16:00<jdike>what's the command line?
16:01<holst>/opt/uml/linux mem=96M ubd0=/dev/mapper/matmech con=null con0=tty:/dev/pty23 con1=tty:/dev/pty33 eth0=tuntap,,, umid=matmech fakehd
16:02<holst>up til' now ive been using a "screen" to start my uml. dont really like that
16:02<jdike>why not?
16:02<jdike>everyone else like it
16:02<holst>i think its wrong :)
16:03<jdike>be more specific
16:03<holst>something is done as user and some other thing as users. its a mess
16:03<holst>sudo:s all over
16:03<jdike>where are the sudos?
16:05<jdike>but if you attach a screen to the specified pty, the thing should boot
16:05<jdike>just that it may hang until then because the host won't let it return from a write until the other end is opened
16:08<holst>its no silly mixup you think?
16:08<holst>you start with: con0=tty:/dev/ptyy0
16:09<jdike>I think you want pty: actually
16:09<jdike>not positive
16:09<holst>in the conserver config its later
16:09<holst>console hobbit_vt1 { device /dev/ttyz2; }
16:09<holst>(not same device [my misstake]) ; but still its not pty
16:10<holst>do you think the difference is indended?
16:10<caker>jdike: just a thought, and I'll look through the code -- but, is generating the core file a function of libc (outside of UML) -- I'm interested in gzipping the core output before it's written to disk
16:10<jdike>caker, it's a kernel thing
16:10<caker>I'm assuming the core file size == UML's mem size
16:11<caker>a UML kernel thing?
16:11<jdike>you can't expect a dead process to dump itself
16:11<jdike>it's in no shape to do anything
16:12<jdike>presumably your scripts know when a UML has died
16:12<jdike>why can't they just zip it up (and package it together with the kernel for my convenience :-)
16:14<caker>yeah .. guess my best bet is to do it post dump
16:15<jdike>BTW, there is a configurable core file format in /proc
16:15<jdike>that might be helpful in controlling where they land
16:15<jdike>core file name
16:15<caker>The hosts's root lvm partition is very small ... guess I can create a "cores" volume and cd into it before running UML
16:17<jdike>and core_uses_pid
16:17<jdike>I thought there was printf-like formatting but I guess not
16:17<jdike>see if you can dump a full pathname in there
16:22|-|holst [] has quit [Quit: leaving]
16:41|-|Nem^1 [] has joined #uml
16:41|-|da-x [] has joined #uml
16:45|-|Nem^ [] has quit [Read error: Operation timed out]
16:45|-|Nem^1 changed nick to Nem^
17:00|-|kos_tom [] has quit [Quit: I like core dumps]
17:11<aroscha_>jdike: hey thanks again for all your support and time etc.
17:11<jdike>good luck on your 1000 UMLs
17:11<aroscha_>i will report and linger around here for some time i guess ;-) maybe write a HOWTO or so
17:13<aroscha_>i know somebody at some .mil place did it
17:13<aroscha_>for a network simulator
17:14<aroscha_>so, well, anyway. good night. it is past 12 a.m. here
17:14|-|aroscha_ [~aroscha@] has quit [Quit: aroscha_]
17:27|-|da-x [] has quit [Remote host closed the connection]
17:38|-|da-x [] has joined #uml
18:06|-|da-x [] has quit [Remote host closed the connection]
18:33|-|linbot [] has quit [Ping timeout: 480 seconds]
18:44|-|da-x [] has joined #uml
18:44|-|linbot [] has joined #uml
18:46|-|ram [] has joined #uml
18:56|-|da-x [] has quit [Ping timeout: 480 seconds]
19:02|-|da-x [] has joined #uml
19:06|-|da-x [] has quit [Remote host closed the connection]
19:27|-|peterz [] has quit [Read error: Operation timed out]
19:28|-|peterz [] has joined #uml
19:31|-|jdike [] has quit [Quit: Leaving]
19:42|-|fo0bar_ [] has joined #uml
19:45|-|Netsplit <-> quits: fo0bar
19:56|-|ElectricElf [] has quit []
20:01|-|ElectricElf [] has joined #uml
20:17|-|shze [] has joined #uml
20:24|-|da-x [] has joined #uml
20:37|-|shze [] has quit [Quit: Konversation terminated!]
20:56|-|da-x [] has quit [Remote host closed the connection]
21:08|-|da-x [] has joined #uml
22:24|-|ram [] has quit [Ping timeout: 480 seconds]
22:59|-|VS_ChanLog [] has left #uml [Rotating Logs]
22:59|-|VS_ChanLog [] has joined #uml
23:27|-|shze [] has joined #uml
23:36|-|shze [] has quit [Quit: Konversation terminated!]
---Logclosed Wed Apr 11 00:00:18 2007