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

---Logopened Wed Apr 11 00:00:18 2007
01:42|-|Ancalagon [] has joined #uml
02:52|-|Shaun2222 [] has quit [Ping timeout: 480 seconds]
03:03|-|Internat [] has quit [Read error: Connection reset by peer]
03:12|-|amitg [] has joined #uml
03:12<amitg>any clue why /dev/ubd/# doesn't show up as a valid block device when ubd#=<device-file> is passed as a parameter in UML?
03:38|-|fo0bar_ changed nick to fo0bar
03:39|-|motp [~motp@] has joined #uml
04:33|-|pgstudy [] has joined #uml
06:17|-|moyix [] has quit [Quit: Leaving]
07:07|-|less [] has joined #uml
07:10<less>Hi, I am trying to compile UML with SMP support in linux-2.6.20 kernel, Can I know what configuration options I need to add and where ?
07:39|-|Tom [~thwpike@] has joined #uml
07:41|-|Tom [~thwpike@] has quit []
07:51|-|less [] has quit [Quit: Leaving]
08:14|-|motp [~motp@] has quit [Quit: Leaving]
08:41|-|Tom [~thwpike@] has joined #uml
08:44|-|Tom [~thwpike@] has quit []
09:17|-|GoGi [] has joined #uml
09:36|-|Hunger [] has quit [Ping timeout: 480 seconds]
09:44|-|Hunger [] has joined #uml
10:10|-|Ancalagon [] has quit [Quit: Chatzilla 0.9.75 [Firefox]]
10:38|-|jdike [] has joined #uml
10:39<jdike>Hi guys
10:45|-|GoGi [] has quit [Ping timeout: 480 seconds]
10:57|-|GoGi [] has joined #uml
10:59|-|pgstudy [] has quit [Remote host closed the connection]
11:04|-|GoGi [] has quit [Quit: Client exiting]
11:06|-|hfb [] has joined #uml
11:06|-|hfb [] has left #uml []
11:28<peterz>jdike: rc6-mm1 fails to boot, should I just add all uml patches send to lkml since?
11:30|-|baroni [] has quit [Ping timeout: 480 seconds]
11:31<jdike>because it's supposed to boot
11:31<jdike>it's fine here
11:31<peterz>ah, ok, I'll have a look at what goes wrong then
11:32<peterz>but first, dinner!
11:32<jdike>OK, let me know
11:37|-|ram [] has joined #uml
11:49|-|kos_tom [] has joined #uml
12:13<jdike>kokoko1, still have the link to that podcast?
12:15<jdike>yeah, thanks
12:15<jdike>charlan decided she wanted to listen to it
12:16<caker>what? just now (assuming that's the wifey?)
12:16<jdike>I mentioned it last night
12:16<caker>I think I made everyone I know listen to it the day it was out
12:18<jdike>I mentioned it when I did it
12:20<caker>been googling ways to compress core dumps inline, or send it off to another box.. Linux Kernel Crash Dump (LKCD) seems to have that functionality, but only for host kernel crashes...
12:20<jdike>bzip + scp?
12:20<caker>coincidentially, there's recent talk of compressing cores on LKML
12:21<jdike>do you have any yet?
12:21<caker>yeah, but before it's sent to disk (or without sending to disk)
12:21<jdike>OK, but you should be able to get them off the disk pretty quickly
12:21|-|Urgleflogue [] has joined #uml
12:21<caker>No, -- it's going to take some effort to handle rotating out old dumps, notification that there's a new cd to pick up, etc
12:22<jdike>did you check whether you can drop a full pathname into /proc/sys/kernel/core-format?
12:22<caker>Plus, someone just booting an empty boot profile will generate a core, and now we've got Linode 1024s, so...
12:23<caker>No, I don't have an unused box I felt comfortable echoing random things into proc with
12:23<caker>we're pretty full
12:24<caker>hmm .. compressed filesystems?
12:25<jdike>well, I do
12:25<jdike>and it works fine
12:25<caker>works as in doesn't crash, or the path is used regardless of cwd?
12:26<jdike>the latter
12:26<jdike>cat /proc/sys/kernel/core_pattern
12:26<jdike>ls -lt /tmp/core*
12:26<jdike>-rw------- 1 jdike jdike 33849344 Apr 11 13:13 /tmp/core.21694
12:28<amitg>any clue why /dev/ubd/# doesn't show up as a valid block device when ubd#=<device-file> is passed as a parameter in UML?
12:29<caker>amitg: because it's devfs ?
12:29<amitg>caker: I just have though /dev/ubd/0 to /dev/ubd/7
12:30[~]amitg boots his UML
12:31<caker>amitg: personally, I'd dump devfs and just make device nodes ....
12:31<caker>I thought devfs was completely gone from recent 2.6 source?
12:33<caker>amitg: <-- device nodes archive, also: <-- script to make /dev/ubda, /dev/ubdb, etc
12:33<caker>amitg: and to boot without devfs, add "devfs=nomount" to your UML's command line args
12:33<jdike>I have this horrible feeling we're looking at 2.4
12:33<amitg>caker: ah, clean. thanks
12:33<caker>amitg: yeah, and use a recent UML kernel :) -- you'll be much happier
12:35<amitg>I'm stuck with 2.6.18, don't want to mess with my git tree when my defense is just a month away :|
12:35<jdike>devfs wasn't gone by then?
12:37<amitg>I think its not a problem of devfs, I don't have it to start with
12:37<amitg>jdike: yep, looks like its gone
12:38<kokoko1>jdike, sorry I was afk
12:39<caker>jdike: interesting block driver patches (batching / pointers)
12:39<jdike>depressingly little performance impact though
12:39<jdike>aside from copying stuff from one device to another
12:40<jdike>that doubled
12:40<caker>you've been in an optimization mood lately...
12:40<jdike>but nothing that I could measure within a single device
12:40<caker>I like
12:41<jdike>atm I'm seeing how fast I can make page faults
12:42<jdike>that seems to be a major part of a kernel build
12:49<amitg>caker: after inflating the gz, it still complains that the block device is not valid
12:50<caker>what block device?
12:50<caker>is this something referenced by the UML's /etc/fstab? If so, you need to fix fstab
12:50<amitg>the device file that I pass to it
12:50<amitg>no its not referenced
12:50<amitg>I pass it has ubd2=disk.dsk
12:51<caker>loop mount your UML's root filesystem, cd into its dev, then run that script
12:52<caker>then, use ubda=, ubdb=, ubdc= on your command line (just to avoid confusion)
12:52<caker>those will refer to the device nodes inside UML (so they're all the same)....
12:53<caker> /dev/ubda, /dev/ubdb, etc <-- much more correct than the old method
12:55<amitg>sweet, works
12:56<amitg>caker: thanks
12:57[~]kokoko1 debian 4.0 Etch is cool
12:58<kokoko1>using it on my desktop atm did a netinstallal
12:59<kokoko1>Finally debian giving all the cutting edge softwares with etch
12:59<kokoko1>Bleeding Edge* perhaps :)
13:08<caker>amitg: np
13:11<jdike>Another 7% off a kernel build
13:11|-|aroscha [~aroscha@] has joined #uml
13:11<jdike>got your 1000 UMLs running yet?
13:13<caker>jdike: awesome!
13:14<caker>have you compared <single thread/cpu> kbuild times on the host vs UML?
13:14<aroscha>no not yet :)
13:14<aroscha>but making progress
13:15<jdike>how little memory can you boot a UML in?
13:16<aroscha>at the moment the limit seems 12M
13:16<aroscha>still researching the low mem things in linux
13:16<aroscha>but openwrt for example can run on 4M
13:17<aroscha>so i think it should theoretically work
13:17<aroscha>i just don't know how UML behaves with so little memory
13:17<aroscha>except that it simply does not start if mem= is to small
13:17<jdike>what happens?
13:18<jdike>there are some 4M roundings in there which might be affected if you get down that low
13:20<aroscha>hm, just rebooting the machine now. I can copy & paste the results
13:20<aroscha>basically the UML kernel will not start and exit immediately
13:23<jdike>no output?
13:24<aroscha>have to get the server running again :(
13:42<kokoko1>last night one of our xen base host crashed :-S
13:42<kokoko1>no visible sign in logs
13:42<kokoko1>it was down for more then 4 hours coz data center ppl kinda lazy to give us support on time
13:43<caker>kokoko1: does that happen often with Xen?
13:43<kokoko1>caker, nope it was first of its kind
13:44<kokoko1>however we got buggy kernel-xen from fedora folkes lately which was completely unusable, i have to rollback to previous working kernel-xen
13:45<kokoko1>still no update look like fedora ppl not accecpting it as a bug :-S
13:50<jdike>a tweak gives me another % or so
13:50<kokoko1>caker, do you have links for your data center w.sites?
13:51<kokoko1>I thinks you must update look :D
13:51<kokoko1>e,g <--we have two servers with them
14:04<kokoko1>caker, what are you using for monitoring ?
14:04<aroscha>jdike: i was wondering if i can mount root filesystems as hostfs vor many instances in parallel? I guess that will screw up a lot ?
14:05<jdike>the same filesystem, yes
14:05<jdike>well, the same host directory
14:07<aroscha>ok but if let's say the /etc/init.d/rcS from one instance wants to write to "it's" /etc/mtab then it will write to everybodies /etc/mtab (?_
14:10<jdike>you want COWed block devices
14:21|-|Blissex [] has joined #uml
14:40|-|ram [] has quit [Read error: Operation timed out]
14:43|-|mjf [] has joined #uml
14:48|-|mjf [] has quit []
14:51|-|Blissex [] has quit [Remote host closed the connection]
14:51|-|da-x [] has quit [Remote host closed the connection]
15:01|-|ram [] has joined #uml
15:14|-|albertito [] has quit [Ping timeout: 480 seconds]
15:42|-|dgraves [] has joined #uml
15:47|-|aroscha [~aroscha@] has quit [Ping timeout: 480 seconds]
15:50|-|baroni [] has joined #uml
16:14|-|baroni [] has quit [Ping timeout: 480 seconds]
16:15|-|da-x [] has joined #uml
16:41|-|Nem^1 [] has joined #uml
16:46|-|Nem^ [] has quit [Read error: Operation timed out]
16:46|-|Nem^1 changed nick to Nem^
16:49<peterz>jdike: I'm too dense atm to figure out what is going on, perhaps I should go sleep and try again tomorrow
16:49<caker>!errno 3
16:49<linbot>caker: ESRCH (#3): No such process
16:56|-|aroscha [~aroscha@] has joined #uml
16:57|-|Tom [~thwpike@] has joined #uml
17:04|-|da-x [] has quit [Remote host closed the connection]
17:04|-|aroscha [~aroscha@] has quit [Ping timeout: 480 seconds]
17:06<jdike>peterz, this is reproducable?
17:06<peterz>I've seen it a few times
17:07<jdike>I've only seen it once, during an overnight kernel build loop
17:07<jdike>so rc6-mm1 does boot for you, at least sometimes?
17:08<peterz>but this is the same problem I had when not booting
17:08<jdike>what's the host?
17:08<peterz>so it either happens instantly or after a little while
17:08<peterz>2.6.20-rt8 on x86_64
17:08|-|Tom [~thwpike@] has quit [Quit: Leaving]
17:08<jdike>OK, so that rules out utrae
17:09<peterz>I'll try a regular kernel (I forgot I booted -rt on that box)
17:09<peterz>I really ought to go sleep, I'm starting do cause more harm than good :-/
17:40|-|kos_tom [] has quit [Quit: I like core dumps]
17:51|-|jdike [] has quit [Quit: Leaving]
18:43|-|albertito [] has joined #uml
19:35|-|baroni [] has joined #uml
19:58|-|ram [] has quit [Read error: Operation timed out]
20:42|-|alb [] has joined #uml
20:44|-|aroscha [~aroscha@] has joined #uml
20:44|-|albertito [] has quit [Ping timeout: 480 seconds]
21:32|-|fghj [~tkxue@agp.Stanford.EDU] has joined #uml
21:54|-|fghj [~tkxue@agp.Stanford.EDU] has quit [Quit: Leaving]
21:58|-|fghj [~tkxue@agp.Stanford.EDU] has joined #uml
22:08|-|rasix [~jeruk@] has joined #uml
22:15|-|fghj [~tkxue@agp.Stanford.EDU] has quit [Quit: Leaving]
22:27|-|rasix [~jeruk@] has quit [Ping timeout: 480 seconds]
22:29|-|baroni [] has quit [Ping timeout: 480 seconds]
22:41|-|baroni [] has joined #uml
22:59|-|VS_ChanLog [] has left #uml [Rotating Logs]
22:59|-|VS_ChanLog [] has joined #uml
23:23|-|baroni [] has quit [Ping timeout: 480 seconds]
23:26|-|aroscha [~aroscha@] has quit [Ping timeout: 480 seconds]
23:55|-|baroni [] has joined #uml
23:56|-|aroscha [] has joined #uml
---Logclosed Thu Apr 12 00:00:04 2007