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

---Logopened Fri Dec 07 00:00:04 2007
00:01|-|Netsplit resistance.oftc.net <-> charm.oftc.net quits: linbot, tchan
00:11|-|Netsplit larich.oftc.net <-> resistance.oftc.net quits: dgraves_, kingsley, ferret_0567, VS_ChanLog
00:15|-|Netsplit over, joins: linbot, tchan
00:15|-|fo0bar [fo0bar@feh.colobox.com] has joined #uml
00:15|-|rjbell4 [bbell@c-75-67-251-249.hsd1.nh.comcast.net] has joined #uml
00:15|-|silug [~steve@ppp-70-225-81-132.dsl.covlil.ameritech.net] has joined #uml
00:15|-|remus [~remus@76.231.178.131] has joined #uml
00:15|-|caker [~caker@caker.netrep.oftc.net] has joined #uml
00:15|-|Hunger [Hunger.hu@213.163.11.138] has joined #uml
00:15|-|Urgleflogue [~plamen@83.228.65.158] has joined #uml
00:15|-|SNy [~mfr@bmx-chemnitz.de] has joined #uml
00:15|-|weasel [weasel@weasel.chair.oftc.net] has joined #uml
00:15|-|ftumch [~James@james.1ec.aaisp.net.uk] has joined #uml
00:15|-|Magotari [~karol@chello089076073248.chello.pl] has joined #uml
00:15|-|dgraves [~agraves@inet-netcache2-o.oracle.com] has joined #uml
00:15|-|anderiv [~anderiv@66-162-60-4.static.twtelecom.net] has joined #uml
00:15|-|ds2 [noinf@netblock-66-245-251-24.dslextreme.com] has joined #uml
00:21|-|balbir [~balbir@59.145.136.1] has joined #uml
00:21|-|Netsplit over, joins: VS_ChanLog, ferret_0567, dgraves_, kingsley
00:35|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
00:35|-|ElectricElf [~dbharris@bas1-toronto48-1242461494.dsl.bell.ca] has joined #uml
00:35|-|huslu [~huslu@c-67-174-108-150.hsd1.co.comcast.net] has joined #uml
00:40|-|ferret_0567 [~travis@72.191.26.86] has quit [Remote host closed the connection]
00:41|-|Netsplit osmotic.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
00:42|-|Netsplit over, joins: huslu, ElectricElf, newbie
00:43|-|Netsplit osmotic.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
00:44|-|Netsplit over, joins: huslu, ElectricElf, newbie
00:50|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
00:51|-|Netsplit over, joins: huslu, ElectricElf, newbie
00:57|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:03|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:03|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:03|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:06|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:12|-|Netsplit osmotic.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:13|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:19|-|Netsplit osmotic.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:19|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:23|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
01:30|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:30|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:37|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:41|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:48|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
01:49|-|Netsplit over, joins: huslu, ElectricElf, newbie
01:52|-|kokoko1 [~Slacker@203.148.65.19] has quit [Ping timeout: 480 seconds]
01:55|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:01|-|Netsplit over, joins: huslu, ElectricElf, newbie
02:07|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:09|-|Netsplit over, joins: huslu, ElectricElf, newbie
02:14|-|ferret_0567 [~travis@72.191.26.86] has joined #uml
02:15|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:15|-|ferret_0567 [~travis@72.191.26.86] has quit []
02:16|-|Netsplit over, joins: huslu, ElectricElf, newbie
02:16|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Quit: WeeChat 0.2.7-dev]
02:17|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
02:19|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit []
02:22|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:23|-|Netsplit over, joins: huslu, ElectricElf, newbie
02:26|-|ferret_0567 [~travis@72.191.26.86] has joined #uml
02:29|-|Netsplit charon.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:30|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
02:30|-|Netsplit over, joins: huslu, ElectricElf, newbie
02:36|-|Netsplit osmotic.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:37|-|Netsplit over, joins: huslu, ElectricElf, newbie
02:41|-|Netsplit osmotic.oftc.net <-> resistance.oftc.net quits: ElectricElf, newbie, huslu
02:41|-|Netsplit over, joins: newbie, ElectricElf, huslu
02:42|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Quit: WeeChat 0.2.7-dev]
03:28|-|ram [~ram@pool-96-225-204-220.ptldor.fios.verizon.net] has joined #uml
05:19|-|balbir [~balbir@210.212.199.234] has joined #uml
06:12|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has joined #uml
06:33|-|balbir [~balbir@210.212.199.234] has quit [Ping timeout: 480 seconds]
06:52|-|Infinito [argos@201-2-47-78.gnace701.dsl.brasiltelecom.net.br] has joined #uml
07:34|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has joined #uml
07:35|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has quit []
08:47|-|besonen_mobile_ [~besonen_m@71-220-198-145.eugn.qwest.net] has joined #uml
08:47|-|Infinito [argos@201-2-47-78.gnace701.dsl.brasiltelecom.net.br] has quit [Read error: Connection reset by peer]
08:47|-|Infinito [argos@201-2-47-78.gnace701.dsl.brasiltelecom.net.br] has joined #uml
08:51|-|besonen_mobile [~besonen_m@71-220-198-145.eugn.qwest.net] has quit [Ping timeout: 480 seconds]
09:09|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:41|-|aroscha [~aroscha@pnsgw3-client051.demo.tuwien.ac.at] has joined #uml
09:45|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
09:51|-|flatronf700B [~flatronf7@ns1.clipsalportal.com] has joined #uml
10:02|-|balbir [~balbir@122.167.176.252] has joined #uml
10:10|-|newbie [~jeff@ita4fw1.itasoftware.com] has left #uml []
10:58|-|Magotari [~karol@chello089076073248.chello.pl] has quit [Quit: Lost terminal]
10:59|-|miausX [~miausX@1.pool85-56-131.dynamic.orange.es] has joined #uml
10:59<miausX-#uml->>hi all :)
11:02<miausX-#uml->>excuse me, I'm new to UML... I'm following the section "Creating a file system
11:03<miausX-#uml->>but I have a question about dd. Can I use this: dd if=/dev/zero of=~/disk.img bs=1M count=500 instead of dd if=/dev/zero of=~/disk.img bs=516096c count=1000?
11:04<miausX-#uml->>I think that with both commands I'll get a 500Mb file, isn't it?
11:05|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
11:05<jdike-#uml->>Hi guys
11:05<miausX-#uml->>Hi jdike :)
11:06<miausX-#uml->>jdike: I was asking about the dd usage... Can you help me, please?
11:06<miausX-#uml->>English is not my native language, and concepts like spare files are a bit difficult to understand to me :)
11:07<jdike-#uml->>what's the question?
11:07<jdike-#uml->>about sparse files?
11:08<miausX-#uml->>well, in the UML wiki, section about creating a filesystem is a dd command like this: dd if=/dev/zero of=~/disk.img bs=516096c count=1000 to create a 500MB virtual disk
11:08<jdike-#uml->>yup
11:08<miausX-#uml->>my question is: can I do the same with dd if=/dev/zero of=~/disk.img bs=1M count=500? is there any difference?
11:09<jdike-#uml->>if bs * count is the same in both cases, yes
11:09<miausX-#uml->>yay!! thank you very much! :)
11:10<miausX-#uml->>I'm trying to build a UML + busybox for testing :)
11:12|-|aroscha [~aroscha@pnsgw3-client051.demo.tuwien.ac.at] has quit [Quit: aroscha]
11:13<miausX-#uml->>http://www.usermodelinux.org is online? I can't access to that site
11:15<jdike-#uml->>no
11:15<jdike-#uml->>it's been dead for quite a while
11:16<dgraves_-#uml->>morninng jdiek!
11:16<miausX-#uml->>oh :(
11:17<jdike-#uml->>who?
11:20[~]jdike #uml stares at the skas3 patch#uml-> stares at the skas3 patch
11:21|-|ferret_0567 [~travis@72.191.26.86] has quit [Remote host closed the connection]
11:22<jdike-#uml->>ferret was here and I didn't notice
11:22<jdike-#uml->>no help for him then
11:22<miausX-#uml->>:)
11:24<miausX-#uml->>hmm... another stupid question... Why in some documents is used ubd0 or ubd1 while in others is used ubda, ubdb, etc? (ubd == UML Block Device, I suppose)
11:25<dgraves_-#uml->>jdike, i didn't see questions from him, so i can't believe it matters.
11:25<jdike-#uml->>true
11:25<jdike-#uml->>ubd0 was the old way
11:25<dgraves_-#uml->>Mmm... devfs.....
11:25<jdike-#uml->>it means the same as ubda, but ubda is preferred
11:25<miausX-#uml->>ok, thanks jdike :)
11:27<miausX-#uml->>I'm feeling a bit lost, but I couldn't found updated docs about this... Do I have to read some website?
11:28<miausX-#uml->>I mean, about UML :)
11:29<jdike-#uml->>depends on what you want to do
11:29<jdike-#uml->>the UML site has information about getting started
11:30|-|aroscha [~aroscha@pnsgw3-client051.demo.tuwien.ac.at] has joined #uml
11:31<miausX-#uml->>well, I miss a little explanation about boot params and devices... Is there a replacement to ubd2r to access the CDROM?
11:32<jdike-#uml->>ubdbr=/dev/cdom
11:33<dgraves_-#uml->>miausX, there's an excellent book about UML as well. :)
11:33|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
11:33<miausX-#uml->>dgraves_: I'll bougth one for sure :)
11:34<miausX-#uml->>thank you jdike :)
11:34<jdike-#uml->>np
11:38<miausX-#uml->>dgraves_: Is the book up to date?
11:40<dgraves_-#uml->>miausX, pretty much so. contains lots of good walk throughs, information, step by steps, and more information.
11:40<miausX-#uml->>yay! :D
11:41<jdike-#uml->>very up to date
11:41<jdike-#uml->>it talks about things which don't exist yet
11:41|-|aroscha [~aroscha@pnsgw3-client051.demo.tuwien.ac.at] has quit [Quit: aroscha]
11:41<dgraves_-#uml->>its future proof! :)
11:41<miausX-#uml->>hummmm... I need to found a reseller in Spain
11:42<miausX-#uml->>hey! is not expensive!
11:48|-|balbir [~balbir@122.167.176.252] has quit [Ping timeout: 480 seconds]
11:50<miausX-#uml->>oh my God...! You write the book jdike!
11:51<miausX-#uml->>Thanks for your work! :))
11:56|-|aroscha [~aroscha@pnsgw3-client051.demo.tuwien.ac.at] has joined #uml
12:10|-|dgraves__ [~asdf@inet-nc01-o.oracle.com] has joined #uml
12:10<dgraves__-#uml->>jdike is famous
12:11<caker-#uml->>you're famous when you're dead
12:14|-|dgraves_ [~asdf@inet-netcache3-o.oracle.com] has quit [Ping timeout: 480 seconds]
12:20<miausX-#uml->>lol
12:22<miausX-#uml->>hum! This works: ./linux mem=128M ubda=busybox-root_fs.img, but this not: ./linux mem=128M ubda=busybox-root_fs.img root=/dev/ubda
12:23|-|aroscha [~aroscha@pnsgw3-client051.demo.tuwien.ac.at] has quit [Quit: aroscha]
12:23<miausX-#uml->>it's a prebuilt filesystem with busybox... But I don't understand why it fails when I try to tell the UML where is the root filesystem :?
12:23<miausX-#uml->>just curious
12:25<miausX-#uml->>silly me... root=/dev/ubda works... but I have write root=/dev/ubda1 ... without the "1" it boots
12:25<miausX-#uml->>this is funny :P
12:32<IntuitiveNipple-#uml->>If the image file doesn't have a partition table and partitions, you don't need to specify a partition number
12:35|-|tyler29 [~tyler@ARennes-257-1-47-12.w81-53.abo.wanadoo.fr] has joined #uml
12:38<miausX-#uml->>IntuitiveNipple: ok, thank you :)
12:47|-|tyler29 [~tyler@ARennes-257-1-47-12.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
12:48|-|balbir [~balbir@122.167.176.161] has joined #uml
12:58|-|tyler29 [~tyler@ARennes-257-1-151-9.w86-210.abo.wanadoo.fr] has joined #uml
12:59|-|aroscha [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has joined #uml
12:59<anderiv-#uml->>so - I just deployed a new UML guest a few minutes ago. When I launch the guest, around 50% of the time, the boot will hang after the "VFS: Mounted root (ext3 filesystem) readonly." log entry and will continue to consume 100% of one of my CPUs. Has anyone ever experience this?
13:00<anderiv-#uml->>...the other 50% it boots just fine and appears to function normally. This is the 4th UML guest on this server, the other three are functioning just fine. I'm using 2.6.22.7 for the guest kernels and 2.6.20-skas3 for the host.
13:01<IntuitiveNipple-#uml->>What architecture are the host and guests?
13:01<anderiv-#uml->>x86-32 for both.
13:02<IntuitiveNipple-#uml->>are the failing guests using the same images that are working elsewhere?
13:02<IntuitiveNipple-#uml->>in other words, do the images have different contents?
13:03<anderiv-#uml->>yes - they're all using the same kernel image and the same base OS image. The one difference is that I resized this guest's root filesystem image to 60G.
13:03<anderiv-#uml->>the other guests' root filesystems are all under 30G.
13:03<IntuitiveNipple-#uml->>It *sounds* like you're seeing a similar issue I have been trying to solve with 64-bit host and 32-bit guests, where when the guest begins the init process, the first time it tries to access a mmap()ed file it does that
13:03<IntuitiveNipple-#uml->>Hmmm
13:03<IntuitiveNipple-#uml->>ext3?
13:03<anderiv-#uml->>y
13:04<IntuitiveNipple-#uml->>Did you do an fsck on the resized image, just in case?
13:04<anderiv-#uml->>well - to be more clear, the host actually is 64 bit, but I'm running a 32-bit OS on it.
13:04<anderiv-#uml->>IntuitiveNipple: I'll try that.
13:06<IntuitiveNipple-#uml->>I think it's a case of eliminating possibilities
13:06<IntuitiveNipple-#uml->>try and narrow it down as much as possible. For example, can you start this guest if no other guests are running?
13:07<anderiv-#uml->>hrm - the fsck came back clean.
13:08<anderiv-#uml->>That's a good idea - I'll have to wait until tonight so I can shut down the other guests.
13:13<anderiv-#uml->>hrm - it starts reliably if I decrease the amount of RAM dedicated to it.
13:18<IntuitiveNipple-#uml->>Ahhh
13:18<IntuitiveNipple-#uml->>How much memory does the host have in total, and how much are the combined guests set to use?
13:19<anderiv-#uml->>the host has 8G, and with the original RAM allocation for this problem guest, the combined RAM was 5.5G
13:20<jdike-#uml->>strace shows the guest in an infinite segfault loop?
13:20<anderiv-#uml->>jdike: haven't ran it through strace. I'll do that now.
13:37|-|krau [~cktakahas@200.184.118.132] has quit [Ping timeout: 480 seconds]
13:52|-|aroscha [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has quit [Quit: aroscha]
13:57|-|aroscha [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has joined #uml
13:57|-|krau [~cktakahas@200.184.118.132] has joined #uml
13:57|-|ferret_0567 [~travis@72.191.26.86] has joined #uml
13:58|-|krau [~cktakahas@200.184.118.132] has quit []
13:58|-|krau [~cktakahas@200.184.118.132] has joined #uml
14:13|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
14:16|-|krau [~cktakahas@200.184.118.132] has joined #uml
14:30[~]jdike #uml spots the problem with skas3 and 2.6.23#uml-> spots the problem with skas3 and 2.6.23
14:31<jdike-#uml->>why is the whole kernel rebuilding?
14:31<jdike-#uml->>Bah humbug
14:35|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
14:38<IntuitiveNipple-#uml->>Re: anderiv's issue. He's using a 32-bit host OS on a 64-bit platform, so presumably with 8GB of memory is using PAE?
14:40<dgraves__-#uml->>IntuitiveNipple, either that, or its only got 4gb total available now.
14:40<dgraves__-#uml->>and he should donate the other 4gb to me.
14:42<IntuitiveNipple-#uml->>lol yeah, that's why I asked. He might be hitting a swap-file barrier
14:42<jdike-#uml->>hehe
14:43<jdike-#uml->>no, that's a 32-bit-on-64-bit problem somehow
14:43<jdike-#uml->>Oh, 32bit host?
14:43<jdike-#uml->>I missed that
14:43<dgraves__-#uml->>jdike yeah.
14:43<dgraves__-#uml->>32 bit os, 32 bit guest.
14:43<dgraves__-#uml->>64 bit hardware, but that's irrelevant now.
14:43<jdike-#uml->>right
14:43<jdike-#uml->>the 64-bitness totally shouldn't matter
14:44<dgraves__-#uml->>righto.
14:45<jdike-#uml->>2.6.22 is reasonably modern
14:46<dgraves__-#uml->>yeah. i only specialize in ancient artifacts. :)
14:46<jdike-#uml->>hehe
14:46<jdike-#uml->>BTW, is that thing running yet?
14:46<dgraves__-#uml->>jdike, the 32 bit one was. the 64 bit one still had problems with the sunrpc module.
14:46<jdike-#uml->>virtualization archeologist
14:46<dgraves__-#uml->>i'm working on building a 32 bit file system to go with it as well.
14:47<dgraves__-#uml->>::L::
14:47<dgraves__-#uml->>that's me!
14:48<jdike-#uml->>have you checked whether it happens with stock 2.6.18?
14:48<dgraves__-#uml->>hmm... no.
14:48<dgraves__-#uml->>the machine got reimaged, and i had to share it with someone else, for presubmit testing.
14:48<dgraves__-#uml->>so i'm done working on it till later tonight.
14:48<jdike-#uml->>no, I mean stock 2.6.18 UML
14:48<jdike-#uml->>without the RHEL stuff
14:48<dgraves__-#uml->>jdike, right, i got it.
14:48<dgraves__-#uml->>but the machine i was using had to get its os switched to a 32 bit one.
14:49<dgraves__-#uml->>and now its being used by someone else.
14:49<jdike-#uml->>Oh, OK
14:49<dgraves__-#uml->>i get it back soon though.
14:49<jdike-#uml->>you keep getting machines yanked out from under you
14:49<dgraves__-#uml->>::L::
14:49<dgraves__-#uml->>welcome to oracle.
14:49<dgraves__-#uml->>they'll pay you $90k, but they won't give you a $500 hard drive, or a $1k machine.
14:49<dgraves__-#uml->>it never works out.
14:50<jdike-#uml->>hehe
14:50<dgraves__-#uml->>my goal right now is to get the 32 bit building on a 32 bit host, so i can build EL5 kernel modules from other 32 bit hosts.
14:51<IntuitiveNipple-#uml->>Have you heard of Virtual Machines? :p
14:51[~]IntuitiveNipple #uml runs and hides#uml-> runs and hides
14:51<dgraves__-#uml->>IntuitiveNipple, yeah, lots and lots of them.
14:52<dgraves__-#uml->>we already stress IT out. they don't understand why we need so many machines.
14:52<dgraves__-#uml->>everyone else can share machines.
14:52<dgraves__-#uml->>but not us strange kernel folks.
14:52<dgraves__-#uml->>the problem is that our development boxes are 2gb ram, 3GHz p4's.
14:52<dgraves__-#uml->>that don't run too many virtual machines.
14:52<dgraves__-#uml->>and uml is alright performance wise, but vmware windows sux04s
14:57<IntuitiveNipple-#uml->>Yeah you need ooomph
15:10|-|tyler29 [~tyler@ARennes-257-1-151-9.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
15:14|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
15:22|-|tyler29 [~tyler@ARennes-257-1-165-39.w86-214.abo.wanadoo.fr] has joined #uml
15:23|-|Magotari [~karol@abgg240.neoplus.adsl.tpnet.pl] has joined #uml
---Logclosed Fri Dec 07 15:40:54 2007
---Logopened Fri Dec 07 15:40:56 2007
15:40|-|mikegrb [~michael@mail.thegrebs.com] has joined #uml
15:40|-|Ekipa kanalu #uml: Wszystkich: 37 |-| +op [0] |-| +voice [0] |-| normalnych [37]
15:43<dgraves__-#uml->>jdike, would it be easier to try and replace the tools that are 64 bit, or to copy the sources into a 32 bit tools tree, do you think?
15:43<jdike-#uml->>you building a 32-bit UML on a 64-bit host?
15:43<dgraves__-#uml->>yeah.
15:43<jdike-#uml->>have you tried SUBARCH=i386?
15:43<dgraves__-#uml->>I was using SUBARCH to do so previously
15:43<dgraves__-#uml->>i went to build our module from a 32 bit machine, using that tree, and it couldn't execute the tools.
15:43<dgraves__-#uml->>due to them being 64 bit.
15:43|-|caker [~caker@ns.theshore.net] has joined #uml
15:43<jdike-#uml->>Oh
15:44<dgraves__-#uml->>which is less than useful to us.
15:44<jdike-#uml->>what tools are 64-bit?
15:44<dgraves__-#uml->>genksyms was the first one that choked...
15:44<dgraves__-#uml->>fixdep, i believe as well....
15:44|-|Kanal #uml zsynchronizowany w 241 sekundy
15:45<dgraves__-#uml->>i thought perhaps i'd try replacing the tools with the 32 bit equivalent ones, but was wondering if there was a different way to go about this.
15:47<jdike-#uml->>these were built in the kernel tree, right?
15:47<jdike-#uml->>as part of the kernel build
15:47<dgraves__-#uml->>i thought they were built as part of the install of the source rpm, but i'm not sure.
15:48<dgraves__-#uml->>scripts/genksyms/genksyms
15:48<dgraves__-#uml->>i'm investigating now.
15:49<jdike-#uml->>that's part of the build
15:49<dgraves__-#uml->>Hrm... they were built with SUBARCH=i386... I wonder why they don't work then?
15:49<dgraves__-#uml->>make: *** [usm_build] Error 1
15:49<dgraves__-#uml->>[ agraves_teepee ] bash-3.00$ file /users/necast_shared/uml_EL5_i386/scripts/genksyms/genksyms
15:49<dgraves__-#uml->>bash-3.00$ file /users/necast_shared/uml_EL5_i386/scripts/genksyms/genksyms
15:50<dgraves__-#uml->>" /users/necast_shared/uml_EL5_i386/scripts/genksyms/genksyms: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped
15:50<dgraves__-#uml->>they're definitely 64 bit.
15:50<jdike-#uml->>you need to get used to O=
15:50<dgraves__-#uml->>err.. i was using it for a while. then i did the final build the normal way.
15:50<jdike-#uml->>it'll save you a pile of grief
15:50<dgraves__-#uml->>i thought it would help. :0
15:51[~]dgraves__ #uml actually had 2 kernel trees once he got it working....#uml-> actually had 2 kernel trees once he got it working....
15:51<dgraves__-#uml->>and i was running mrproper and clean on every build.
15:51<dgraves__-#uml->>what'd i miss?
15:52<jdike-#uml->>genksyms should disappear after mrproprt
15:52<dgraves__-#uml->>i ran make ARCH=um SUBARCH=i386 mrproper defconfig menuconfig linux modules modules_install INSTALL_MOD_PATH=/mnt/mnt
15:53<jdike-#uml->>nothing if not complete
15:53<dgraves__-#uml->>complete?
15:54<dgraves__-#uml->>if I rm those files, you think it will rebuild them and work?
15:54<jdike-#uml->>everything on one line
15:54<jdike-#uml->>try it
15:54<dgraves__-#uml->>oh, yeah. just like that, i ran it.
15:54<dgraves__-#uml->>can't. the machine is down, and not coming back up. :)
15:54<dgraves__-#uml->>i'm getting tagged to 'fix it' again. :-P
15:57<dgraves__-#uml->>okay, let me untar the tree and try it.
15:58[~]dgraves__ #uml wants this week to be over. :-P#uml-> wants this week to be over. :-P
15:58[~]dgraves__ #uml will probably work this weekend.#uml-> will probably work this weekend.
15:58<Magotari-#uml->>Heh. I always hate the weekends. Nothing happening.
15:58<dgraves__-#uml->>::L::
15:58<dgraves__-#uml->>that's nice at a certain age...
15:58<dgraves__-#uml->>stress level?
15:59<Magotari-#uml->>I'm extremely stressed, but that is because I am getting married soon.
15:59<Magotari-#uml->>I work to relax.
15:59<Magotari-#uml->>So on the weekend... Ugh.
15:59<jdike-#uml->>stap is crap
15:59<Magotari-#uml->>I hoped to get a PPC emulator, hoping for lots of bugs to fix... Blah.
16:00<dgraves__-#uml->>stap is crap?
16:00<jdike-#uml->>it is
16:01[~]dgraves__ #uml wonders what stap is.#uml-> wonders what stap is.
16:01<jdike-#uml->>systemtap
16:01<jdike-#uml->>but stap makes that rhyme better
16:01<dgraves__-#uml->>oh. yeah, i got told to use that the other day.
16:01<dgraves__-#uml->>why do you say its crap?
16:01<dgraves__-#uml->>it *looked* decent from the web page. :)
16:02<jdike-#uml->>it appears to be oopsing my laptop
16:02<jdike-#uml->>put a probe someplace, and I get an oops from nearby
16:03<jdike-#uml->>gonna reboot and try again without any probes to make sure
16:03<dgraves__-#uml->>huh. nice.
16:04<dgraves__-#uml->>okay, so why do you think putting all those on one line will fix this, jdike?
16:04<dgraves__-#uml->>i was running them like that before.
16:04<jdike-#uml->>I don't
16:04<jdike-#uml->>just commenting on the style
16:04<dgraves__-#uml->>ah. i got tired of typing them. :)
16:04<dgraves__-#uml->>i'm gonna try removing the tools and see what happens.
16:06|-|miausX [~miausX@1.pool85-56-131.dynamic.orange.es] has quit [Quit: off]
16:11<dgraves__-#uml->>jdike, it only seems to build them on the first build of a kernel. removing them doesn't rebuild them, and clean\mrproper don't touch them.
16:11<jdike-#uml->>sounds like a bug
16:13[~]dgraves__ #uml is gonna get sick from all these bugs.. .:)#uml-> is gonna get sick from all these bugs.. .:)
16:14<jdike-#uml->>archaeology has some occupational hazards
16:14<dgraves__-#uml->>:(
16:14<dgraves__-#uml->>i'm dead, and linux bugs are to blame!
16:20<Magotari-#uml->>grep -rin FIXME time.
16:22<jdike-#uml->>hehe
16:22<jdike-#uml->>also look for XXX
16:22|-|tyler29 [~tyler@ARennes-257-1-165-39.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
16:25<dgraves__-#uml->>jdike, i thought this channel was family friendly. you didn't age verify magotari, and you're suggesting what?
16:26<jdike-#uml->>Jeez
16:26<jdike-#uml->>who let the age police in here?
16:27<Magotari-#uml->>Heh.
16:27<dgraves__-#uml->>err... didn't you see the latest bill that's getting passed?
16:27<dgraves__-#uml->>the SAFE act?
16:27<Magotari-#uml->>Found an interesting FIXME. Maybe a small project I can do through the weekend.
16:27<dgraves__-#uml->>we're required by law to report any such activity...
16:27<Magotari-#uml->>Sheesh. Crazy.
16:27<IntuitiveNipple-#uml->>it's about time there was a NOBUGS act! That'd make a few people sit up!
16:27<dgraves__-#uml->>::ROFLMAO:: @ IntuitiveNipple.
16:27<IntuitiveNipple-#uml->>:p
16:29<Magotari-#uml->>So far something about the direction the USA is headed in... Reminds me of a thing called "A mind forever voyaging." or "1984". At least the books are still legal. Right? RIGHT???
16:29<dgraves__-#uml->>no, we banned books a few years ago.
16:29<dgraves__-#uml->>there's a list we're allowed to read from.
16:29<IntuitiveNipple-#uml->>Over the years I've noticed a definite correlation between minimal/no commenting in source-code, and bug numbers. The better commented code has less bugs, and I think it is because it makes the developer(s) think about the overview more
16:29<dgraves__-#uml->>I'm surprised you didn't mention Brave New World.
16:30<jdike-#uml->>Uh oh
16:30<Magotari-#uml->>We are headed into off-topicland. :/
16:30<IntuitiveNipple-#uml->>I'm definitely on-topic! :)
16:30<Magotari-#uml->>Yeah, I agree about the comments.
16:30<dgraves__-#uml->>i am mr. off-topic all the time.
16:31<IntuitiveNipple-#uml->>You're Mr Topically Untopical
16:31<Magotari-#uml->>I was writing very nasty code, then I started adding some comments. Rewrote the thing the next day.
16:31<IntuitiveNipple-#uml->>or is that Typically untypable?
16:31<dgraves__-#uml->>Typically Untopical
16:31|-|dgraves__ changed nick to TypicallyUntopical
16:32<IntuitiveNipple-#uml->>The thing with good comments, that talk about the reasons/rationale is, other people can just glance at the code and spot a mismatch between intent and execution. When you're looking at code in isolation you've not got the foggiest idea sometimes, all you know is, it's bloody obtuse!
16:32<TypicallyUntopical-#uml->>obtuse is a nice word to use at times...
16:35<IntuitiveNipple-#uml->>I got told off for kernel patch verbose comments by AM, but without them how would someone looking at the entire code later know why the code was there, or the nuance it was dealing with. I've always insisted my programmers comment well - it cuts down on bugs, and on maintenance time/costs in the long term.
16:35<TypicallyUntopical-#uml->>IntuitiveNipple, that's great. the problem then is that some bosses *don't* insist that, and you end up with a patch of mis placed unkempt comments.
16:36<jdike-#uml->>there's the idea in the kernel world that the code should speak for itself whenever possible
16:36<TypicallyUntopical-#uml->>but we're back to the old 80\20 rule, and the I dn't have time to do it right in the first place.
16:36<jdike-#uml->>if it doesn't, then maybe there's a simpler implementation
16:36<IntuitiveNipple-#uml->>jdike: which is true only if you're immersed in it 24/7, and even then moving from one area to another you've got a steep learning curve with things changing so fast. The rate-of-change alone should make decent commentary obvious
16:37<TypicallyUntopical-#uml->>jdike, i agree with him. jumping around in the kernel, i am often wondering wth the writer is doing.
16:37<IntuitiveNipple-#uml->>I've always found that commented code takes no longer to write than uncommented, but the results are better in every way that is important.
16:38<IntuitiveNipple-#uml->>I one saw a comment by GKH that really made my blood boil. He'd written some new kernel sub-system (I forget which it was, now) and someone asked on the LKML where the documentation was. He replied by saying that if they wanted docs they should write them themselves! If it'd have been me I'd have slapped him - hard!
16:39|-|tyler29 [~tyler@ARennes-257-1-156-134.w86-214.abo.wanadoo.fr] has joined #uml
16:39<jdike-#uml->>COMMENTS WASTE MY PRECIOUS PIXELS!
16:39<jdike-#uml->>how about that?
16:39<IntuitiveNipple-#uml->>lol
16:41<IntuitiveNipple-#uml->>It's like those that insist on code that wraps at 80-columns! ffs, we're in the era of widescreen displays! Not to mention that, it seems it is okay to have to scroll vertically, but not horizontally! :)
16:42<TypicallyUntopical-#uml->>IntuitiveNipple, I'd love to get 80 columns. WE have a 79 column standard at Oracle.
16:42<jdike-#uml->>vertical scrolling is frowned upon too
16:42<TypicallyUntopical-#uml->>bigger than one page, break it up into smaller functions.
16:42<jdike-#uml->>we're working to get all of Linux onto an 80x24 screen
16:42|-|TypicallyUntopical changed nick to dgraves_
16:42<IntuitiveNipple-#uml->>anyone would think we were still using teletypes!
16:42[~]dgraves_ #uml uses teletubbies.#uml-> uses teletubbies.
16:43<jdike-#uml->>not there yet, but we're getting closer!
16:43<dgraves_-#uml->>::LOL::
16:43<Magotari-#uml->>Cannot wait for the 80x24ication.
16:43<dgraves_-#uml->>the future of linux. back to the past.
16:43<Magotari-#uml->>I live in a text terminal. 80x24.
16:44<jdike-#uml->>Here's the VM system -> . <-
16:44<IntuitiveNipple-#uml->>I work with 132 columns most of the time, with 4 screens
16:44<dgraves_-#uml->>Oracle supports something like 29 different OS's\platforms, some of which have some really arcane restrictions.
16:44<dgraves_-#uml->>writing cross platform code is really tough.
16:45<IntuitiveNipple-#uml->>If the external monitor is connected I have 8, although mostly I use the external for a projector
16:45<IntuitiveNipple-#uml->>Id think any wanting to limit viewing width would just turn on line-wrap
16:46<dgraves_-#uml->>for some platforms its the compiler restriction rather than just display.
16:46|-|newbie [~jeff@ita4fw1.itasoftware.com] has quit [Quit: Leaving.]
16:49<IntuitiveNipple-#uml->>It can't cope with longer input lines? I've never seen that, going back to the early 1980's.
16:49|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
16:50<dgraves_-#uml->>IntuitiveNipple, which platforms? :)
16:51<dgraves_-#uml->>i don't think i even know which platforms its for, but oracle runs on some pretty obscure ones.
16:51<IntuitiveNipple-#uml->>Started out with Z80A and 6502, then 68000 etc
16:51<dgraves_-#uml->>yeah, that would be normal platforms.
16:51<dgraves_-#uml->>it took them till 2001 to allow variable names longer than 8 characters.
16:52<IntuitiveNipple-#uml->>Didn't even have proper assemblers, back then we were literally writing the raw codes from the lookup in the back of Zodney Zak's Z80 bible :)
16:52<dgraves_-#uml->>::L::
16:53<IntuitiveNipple-#uml->>It taught us to count every clock cycle though, we'd develop routines and compare the total ticks to decide which one to use
16:53<IntuitiveNipple-#uml->>in games programming especially, every tick counts
16:54|-|remus [~remus@76.231.178.131] has quit [Remote host closed the connection]
16:58<dgraves_-#uml->>agreed
17:02|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
17:03|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:03[~]dgraves_ #uml screams at UML.#uml-> screams at UML.
17:04<dgraves_-#uml->>okay, this 32 bit image stops at:
17:04<dgraves_-#uml->>[42949373.540000] EXT3-fs: mounted filesystem with ordered data mode.
17:04<dgraves_-#uml->>[42949373.540000] VFS: Mounted root (ext3 filesystem) readonly.
17:04<dgraves_-#uml->>and putting stderr=1 on the line doesn't seem to do anything. :(
17:04<IntuitiveNipple-#uml->>dgraves: if you add -debug you get a few more kernel messages, or at least I did
17:05<IntuitiveNipple-#uml->>sorry, no - in front
17:06<IntuitiveNipple-#uml->>I had the same issue as you, it turned out to be an issue with the init
17:06<dgraves_-#uml->>issue with init?
17:06<dgraves_-#uml->>okay, that's more output alright... :)
17:08|-|remus [~remus@76.231.178.131] has joined #uml
17:10<IntuitiveNipple-#uml->>yeah, the /sbin/init process... in my case there was a hang-up due to udev stuff
17:11<IntuitiveNipple-#uml->>(or the lack of it)
17:12<dgraves_-#uml->>hrm... i never got that far.
17:12<dgraves_-#uml->>i only got to Mounted root readonly.
17:12<dgraves_-#uml->>i tried init=/bin/bash, but that didn't make a dif.
17:14<jdike-#uml->>what's the host and guest?
17:14<dgraves_-#uml->>32 bit, 32 bit. :)
17:14<dgraves_-#uml->>for once.
17:15<IntuitiveNipple-#uml->>time to gdb :)
17:15<dgraves_-#uml->>yeah. i'm gonna try a different fs first. :)
17:18<jdike-#uml->>strace it
17:18<IntuitiveNipple-#uml->>I've still not got to the bottom of the 32-bit guest on 32-bit kernel on 64-bit host with 2.6.22.14 yet, but not had a lot of time recently to look into it more
17:23|-|aroscha_ [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has joined #uml
17:24|-|aroscha [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has quit [Read error: No route to host]
17:24<dgraves_-#uml->>jdike, am i looking for something in particular on the strace?
17:24<dgraves_-#uml->>i've got aobut 10 pages of output.
17:25<jdike-#uml->>what's the signal coming back from wait?
17:26<dgraves_-#uml->>[pid 32376] munmap(0x84f000, 4096) = 0
17:26<dgraves_-#uml->>[pid 32376] kill(32376, SIGKILLupeek: ptrace(PTRACE_PEEKUSER,32376,44,0): No such process
17:26<dgraves_-#uml->>Process 32375 resumed
17:26<dgraves_-#uml->>Process 32376 detached
17:26<dgraves_-#uml->> <unfinished ...>
17:26<dgraves_-#uml->><... waitpid resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGKILL}], WSTOPPED) = 32376
17:26<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:26<dgraves_-#uml->>you mean that signal?
17:27<dgraves_-#uml->>okay, its not fs specific.
17:28<dgraves_-#uml->>its something in the UML itself.
17:28<jdike-#uml->>there can't be an infinite loop of that
17:29<IntuitiveNipple-#uml->>I think thats' the end of the log when the processes were killed
17:29<dgraves_-#uml->>yes.
17:30<IntuitiveNipple-#uml->>you need to search for the "VFS: Mounted root" and go on a bit from there
17:30<IntuitiveNipple-#uml->>I usually found it about 100 lines or so after
17:31<dgraves_-#uml->>http://rafb.net/p/HGxqyH41.html
17:31<dgraves_-#uml->>well, that's where it stops.
17:31<dgraves_-#uml->>i did an strace -f on it.
17:31<dgraves_-#uml->>seems to change the behavior of it.
17:33<IntuitiveNipple-#uml->>I found it didn't like tracing forks
17:33<IntuitiveNipple-#uml->>I usually do strace -o strace.log ./linux ....
17:35<dgraves_-#uml->>that worked better, IntuitiveNipple.
17:35<dgraves_-#uml->>ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x2878f94c) = -1 EINVAL (Invalid argument)
17:35<dgraves_-#uml->>write(7, "\0\0\0\0\n\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\360F\0\0\0\0"..., 64) = 64
17:35<dgraves_-#uml->>--- SIGIO (I/O possible) @ 0 (0) ---
17:35<dgraves_-#uml->>that happens alot.
17:37<IntuitiveNipple-#uml->>You should see, after the "VFS: Mounted root" a repeat of about 12-20 lines
17:38<dgraves_-#uml->>it does that a lot, then it looks like it tries to ptrace something...
17:38<dgraves_-#uml->>then back to repeating itself.
17:38<dgraves_-#uml->>then it starts doing this:
17:38<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:38<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 32603
17:38<dgraves_-#uml->>ptrace(PTRACE_SETREGS, 32603, 0, 0x2878b59c) = 0
17:38<dgraves_-#uml->>ptrace(PTRACE_SETFPXREGS, 32603, 0, 0x2878b64c) = 0
17:38<dgraves_-#uml->>ptrace(0x1f /* PTRACE_??? */, 32603, 0, 0) = 0
17:39<IntuitiveNipple-#uml->>Yes, you'll see a looping of GETREGS SETREGS CONTINUE
17:39<dgraves_-#uml->>that's where it ends.
17:39|-|newbie [~jeff@ita4fw1.itasoftware.com] has quit [Ping timeout: 480 seconds]
17:39<jdike-#uml->>the WSTOPSIG(s) == SIGFOO sequence is what I'm interested in
17:40<IntuitiveNipple-#uml->>what jdike expects is, I think, "waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEG}], WSTOPPED) = 32603"
17:40<IntuitiveNipple-#uml->>SIGSEGV even
17:40<jdike-#uml->>this one will probably go SIGSEGV, SIGUSR1, SIGSEGV, etc, et
17:40<jdike-#uml->>c
17:40|-|tyler29 [~tyler@ARennes-257-1-156-134.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:41<dgraves_-#uml->>clone(child_stack=0x133fd4, flags=CLONE_FILES|SIGCHLD) = 32603
17:41<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:41<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WSTOPPED) = 32603
17:41<dgraves_-#uml->>ptrace(0x15 /* PTRACE_??? */, 32603, 0, 0x1) = 0
17:41<dgraves_-#uml->>munmap(0x133000, 4096) = 0
17:41<dgraves_-#uml->>modify_ldt(0, 8ed8000, 65536) = 0
17:41<dgraves_-#uml->>ptrace(PTRACE_SETREGS, 32603, 0, 0x2878fa80) = 0
17:41<dgraves_-#uml->>ptrace(PTRACE_CONT, 32603, 0, SIG_0) = 0
17:41<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:41<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], WSTOPPED) = 32603
17:41<dgraves_-#uml->>write(7, "\0\0\0\0\n\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\260>L\2\0\0"..., 64) = 64
17:41<dgraves_-#uml->>setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
17:41<dgraves_-#uml->>setitimer(ITIMER_REAL, {it_interval={0, 10000}, it_value={0, 10000}}, NULL) = 0
17:41<dgraves_-#uml->>nanosleep({10, 0}, 0) = ? ERESTART_RESTARTBLOCK (To be restarted)
17:42<IntuitiveNipple-#uml->>ooo that is pretty
17:42|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Quit: WeeChat 0.2.7-dev]
17:42<dgraves_-#uml->>okay, jdike, i found the sequence with SIGUSR1, ISGSEGV, etc.
17:42<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:42<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 32603
17:42<dgraves_-#uml->>ptrace(PTRACE_GETREGS, 32603, 0, 0x2878b59c) = 0
17:42<dgraves_-#uml->>ptrace(PTRACE_GETFPXREGS, 32603, 0, 0x2878b64c) = 0
17:42<dgraves_-#uml->>ptrace(PTRACE_CONT, 32603, 0, SIGSEGV) = 0
17:42<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:42<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 32603
17:42<dgraves_-#uml->>ptrace(PTRACE_SETREGS, 32603, 0, 0x2878f9e0) = 0
17:42<dgraves_-#uml->>ptrace(PTRACE_CONT, 32603, 0, SIG_0) = 0
17:43<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:43<jdike-#uml->>and that goes infinitely until you kill it?
17:43<jdike-#uml->>it's OK for there to be a bunch, with the occasional 133 in there
17:43<jdike-#uml->>that's page faulting plus system calls
17:43|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
17:43<dgraves_-#uml->>hmm...
17:44<dgraves_-#uml->>yeah, infinitely till i kill it, pretty much.
17:45<dgraves_-#uml->>(conjecture... there's 200k lines in teh file, and the bottom, middle, and top all had it. ;) )
17:45<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:45<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 32603
17:45<dgraves_-#uml->>ptrace(PTRACE_GETREGS, 32603, 0, 0x2878b59c) = 0
17:45<dgraves_-#uml->>ptrace(PTRACE_GETFPXREGS, 32603, 0, 0x2878b64c) = 0
17:45<dgraves_-#uml->>ptrace(PTRACE_CONT, 32603, 0, SIGSEGV) = 0
17:45<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:45<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGUSR1}], WSTOPPED) = 32603
17:45<dgraves_-#uml->>ptrace(PTRACE_SETREGS, 32603, 0, 0x2878b59c) = 0
17:45<dgraves_-#uml->>ptrace(PTRACE_SETFPXREGS, 32603, 0, 0x2878b64c) = 0
17:45<dgraves_-#uml->>ptrace(0x1f /* PTRACE_??? */, 32603, 0, 0) = 0
17:45<dgraves_-#uml->>--- SIGCHLD (Child exited) @ 0 (0) ---
17:45<dgraves_-#uml->>waitpid(32603, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 32603
17:45<dgraves_-#uml->>ptrace(PTRACE_GETREGS, 32603, 0, 0x2878b59c) = 0
17:45<dgraves_-#uml->>ptrace(PTRACE_GETFPXREGS, 32603, 0, 0x2878b64c) = 0
17:45<dgraves_-#uml->>--- SIGTERM (Terminated) @ 0 (0) ---
17:45<dgraves_-#uml->>+++ killed by SIGTERM +++
17:45<jdike-#uml->>does a stock UML do this?
17:45<dgraves_-#uml->>have to pull it out and build it. but this code worked on 64 bit.... :(
17:46<dgraves_-#uml->>all i did was do a clean, get rid of a few tools, and force it to build again.
17:47[~]dgraves_ #uml is copying over the tarball.#uml-> is copying over the tarball.
17:53|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
17:56<dgraves_-#uml->>building, building buildilng...
18:01<dgraves_-#uml->>jdike, yes, a standard "vanilla" kernel does this as well.
18:01<dgraves_-#uml->>could it be related to the fact that these were built on EL5 x86_64 before?
18:02<jdike-#uml->>maybe
18:03<dgraves_-#uml->>how can i make them any cleaner?
18:03<dgraves_-#uml->>or is there an easy way to transfer the source to a clean tree?
18:03<jdike-#uml->>Oh
18:04<jdike-#uml->>the binary you are running was built locally?
18:04<jdike-#uml->>not on EL5 x86_64?
18:04<dgraves_-#uml->>the binary was built on the machine i'm running on.
18:04<jdike-#uml->>gotta run...
18:04|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
18:04<dgraves_-#uml->>the tree came from EL5 x86_64.
18:04<IntuitiveNipple-#uml->>wow, you scared him off
18:04<dgraves_-#uml->>::sigh::
18:04<dgraves_-#uml->>and there goes my chances of finishing that this weekend.
18:04<dgraves_-#uml->>argh.
18:05<IntuitiveNipple-#uml->>You're seeing the same issue as me from looking at the strace output
18:05<dgraves_-#uml->>oh?
18:05<Magotari-#uml->>He will come back on monday...
18:05<dgraves_-#uml->>::L::
18:05<dgraves_-#uml->>thanks magotari.
18:05<dgraves_-#uml->>i know.
18:06<Magotari-#uml->>Oh. Ok.
18:06<dgraves_-#uml->>i'm running the bulls trying to get this UML image pushed out.
18:06<dgraves_-#uml->>was hopiong to have it done soon.
18:06<IntuitiveNipple-#uml->>That looping of SIGSEGV SIGUSR1 - do you also see 2 of the UML processes eating up most of 1 CPU?
18:07<IntuitiveNipple-#uml->>Usually I see the primary UML process eating about 64%, and the last UML child process started eating about 30-40%
18:07<dgraves_-#uml->>exactly.
18:07<dgraves_-#uml->>exactly that, even.
18:07<IntuitiveNipple-#uml->>In my situation the reason is, when the init process starts ...
18:07<dgraves_-#uml->>49%
18:07<dgraves_-#uml->>and 64%
18:08<IntuitiveNipple-#uml->>... it opens config files and mmap()s them.
18:08<IntuitiveNipple-#uml->>as soon as the init process tries to read from the mmap that happens
18:08<IntuitiveNipple-#uml->>What I did was grab the source-code for the init package and add some printf()s in
18:09<dgraves_-#uml->>what did it end up being?
18:09|-|dang [~dang@nemesis.fprintf.net] has joined #uml
18:11<IntuitiveNipple-#uml->>I've not found out yet. jdike asked me to run it with the lastest kernel on the host but I can't, I have to stick with 2.6.22.14 for now else I'd have to rebuild all my Xorg drivers and config
18:11<dgraves_-#uml->>ah
18:11<IntuitiveNipple-#uml->>I'd let you have the source code for init but I'm working with Ubuntu and we use Upstart, whereas I guess you've got Sysvinit ?
18:11<IntuitiveNipple-#uml->>Are you using SKAS0 ?
18:12<dgraves_-#uml->>yeah, skas0
18:12<IntuitiveNipple-#uml->>same here.
18:12<IntuitiveNipple-#uml->>64-bit host with 64-bit OS?
18:12<dgraves_-#uml->>no.
18:12<IntuitiveNipple-#uml->>ooo
18:12<dgraves_-#uml->>wait.
18:12<IntuitiveNipple-#uml->>what?
18:12<dgraves_-#uml->>it gets funnier. :)
18:12<dgraves_-#uml->>this source tree worked in 32 bit mode on 64 bit. and 64 bit mode on 64 bit.
18:12<dgraves_-#uml->>but i pulled it over to a 32 bit machine... and now it doesn't.
18:12<IntuitiveNipple-#uml->>If we can show it is more than just a 64-bit thing I might be able to get jdike more interested :)
18:13<IntuitiveNipple-#uml->>The source tree shouldn't make a difference - the .config should affect that
18:13<dgraves_-#uml->>right.
18:13<IntuitiveNipple-#uml->>shall we compare .configs?
18:13<dgraves_-#uml->>i'm just showing where it worked and where it didn't. :)
18:13<IntuitiveNipple-#uml->>I get this with the defconfig though
18:13<dgraves_-#uml->>Hmm... I haven't tried defconfig.
18:13<IntuitiveNipple-#uml->>it works for 64-bit guest, but the 32-bit guest has this issue
18:14<IntuitiveNipple-#uml->>I didn't want to complain if it was my customisations, hence I tried defconfig :)
18:14<dgraves_-#uml->>yeah, i'm doing that now.
18:15<IntuitiveNipple-#uml->>Can I have a copy of your .config since if you can get it to run 32-bit guest on 64-bit, it might solve my problem, and help narrow down the cause
18:16<dgraves_-#uml->>not sure it'll work. Mine's based off a 2.6.18 RedHat kernel.
18:16<dgraves_-#uml->>but sure. you want me to email it?
18:16<IntuitiveNipple-#uml->>that's fine... I'm more interested in isolating differences that might account for the issue
18:16<IntuitiveNipple-#uml->>Or make a http link or pastebin it :)
18:16<IntuitiveNipple-#uml->>http://pastebin.intuitivenipple.net
18:17<dgraves_-#uml->>bleh. that's cut and pasting.
18:17<dgraves_-#uml->>soon as the build is done.
18:17<IntuitiveNipple-#uml->>Thanks
18:17<IntuitiveNipple-#uml->>If we're both seeing a similar issue, maybe 2 heads are better than one at pinpointing it
18:18<IntuitiveNipple-#uml->>I got stuck when I couldn't use gdb any further to watch the child process
18:19<IntuitiveNipple-#uml->>As I understand things, the memory access in the guest causes a SIGSEGV so ptrace can handle it, and that sequence of events keeps on looping
18:19<IntuitiveNipple-#uml->>and one process handles the ptrace on the host, I think
18:20<dgraves_-#uml->>http://pastebin.intuitivenipple.net/99
18:20<IntuitiveNipple-#uml->>so the parent and child keep on going back and forth with request for memory and somehow it not being successful
18:20<dgraves_-#uml->>yeah, that's what i would say as well.
18:22<IntuitiveNipple-#uml->>It is interesting in that this is affecting 2.6.18 - indicates the issue has been around a while
18:22<dgraves_-#uml->>okay, happens with defconfig as well.
18:23[~]dgraves_ #uml supposes that tomorrow he could start applying patches one by one again...#uml-> supposes that tomorrow he could start applying patches one by one again...
18:23<IntuitiveNipple-#uml->>I'm hoping one day Jeff will have time to sit down and explain how the processes relate, what they do, why, etc, because atm I'm mostly in the dark trying to visualise what is going on
18:24<dgraves_-#uml->>he sorta did that yesterday.
18:24<dgraves_-#uml->>did you pick up the uml book?
18:24<dgraves_-#uml->>that went into some of it as well.
18:24|-|remus [~remus@76.231.178.131] has quit [Remote host closed the connection]
18:25<IntuitiveNipple-#uml->>No, I haven't. I stopped buying paper years ago :)
18:25<IntuitiveNipple-#uml->>If I did that for every thing I debug I wouldn't be able to get out the door hehehe
18:25<dgraves_-#uml->>::L::
18:26<dgraves_-#uml->>i picked it up to support him mostly.
18:26<dgraves_-#uml->>and cause the information was valuable in it.
18:26<dgraves_-#uml->>and wasn't on the web site. :(
18:26<IntuitiveNipple-#uml->>If I was going to use UML alot I might, but I'm simply trying to solve open bugs on Ubuntu
18:27<dgraves_-#uml->>ah.
18:27<dgraves_-#uml->>its good for that sort of thing, usually.
18:29<IntuitiveNipple-#uml->>Trying to ensure that for Hardy, UML can be supported, since it is an LTS
18:29<dgraves_-#uml->>lts?
18:29<IntuitiveNipple-#uml->>Long Term Support
18:30<dgraves_-#uml->>oh.
18:31<dgraves_-#uml->>okay wierd.
18:31<IntuitiveNipple-#uml->> LTS releases have 5 years of security updates, etc
18:31<dgraves_-#uml->>this version of uml i compiled works just fine on RH4, but breaks under RH5.
18:31<IntuitiveNipple-#uml->>other 6-monthly releases are much shorter
18:31<IntuitiveNipple-#uml->>Hmmm
18:31<IntuitiveNipple-#uml->>RH5 being the host OS?
18:31<dgraves_-#uml->>yeah.
18:32<dgraves_-#uml->>2.6.18, compiled on x86_64 for i386 works on RH4 i386, but breaks on RH5 i386.
18:32<dgraves_-#uml->>with that VFS mounting root thing.
18:33<IntuitiveNipple-#uml->>what are the kernel versions in RH4 and RH5 ?
18:33<dgraves_-#uml->>2.6.9-5 and 2.6.18-X
18:34<IntuitiveNipple-#uml->>This might be something introduced by the SKAS patches
18:34<dgraves_-#uml->>skas3 on the first, skas0 on the second.
18:34<dgraves_-#uml->>hrm...
18:34<dgraves_-#uml->>wonder if its a skas0 thing.
18:34<IntuitiveNipple-#uml->>I'm not clear on them, but those kernel versions would point to SKAS as something to check out
18:35<dgraves_-#uml->>yeah.
18:35<IntuitiveNipple-#uml->>Also, Jeff was asking me to build the SKAS3 patch for the host here so I think he suspects that too
18:35<IntuitiveNipple-#uml->>I couldn't find a/the SKAS3 patch for 2.6.22 that would build, so I left it.
18:36<dgraves_-#uml->>interesting.
18:36<dgraves_-#uml->>well, i have some things to check out this weekend.b
18:36<dgraves_-#uml->>but for now, i need to head out.
18:36<dgraves_-#uml->>thanks for the help, IntuitiveNipple
18:37|-|remus [~remus@76.231.178.131] has joined #uml
18:37<IntuitiveNipple-#uml->>You're welcome. lets hope we can solve it
18:38<IntuitiveNipple-#uml->>have a good weekend
18:39<dgraves_-#uml->>you too!
18:40|-|newbie [~jeff@ita4fw1.itasoftware.com] has quit [Ping timeout: 480 seconds]
18:58|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
19:56|-|ferret_0567 [~travis@72.191.26.86] has quit [Remote host closed the connection]
20:07|-|Infinito [argos@201-2-47-78.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
20:08|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Quit: WeeChat 0.2.7-dev]
20:11|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
20:29|-|aroscha_ [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has quit [Quit: aroscha_]
20:42|-|ferret_0567 [~travis@72.191.26.86] has joined #uml
20:52|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
20:56|-|ferret_0667 [~travis@cpe-72-191-26-86.satx.res.rr.com] has joined #uml
20:56|-|ferret_0667 [~travis@cpe-72-191-26-86.satx.res.rr.com] has quit []
21:07|-|remus [~remus@76.231.178.131] has quit [Remote host closed the connection]
21:37|-|ferret_0567 [~travis@72.191.26.86] has quit [Remote host closed the connection]
21:40|-|ferret_0567 [~travis@72.191.26.86] has joined #uml
21:41|-|ferret_0567 [~travis@72.191.26.86] has quit [Remote host closed the connection]
21:45|-|ferret_0567 [~travis@cpe-72-191-26-86.satx.res.rr.com] has joined #uml
21:47|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has quit [Quit: The only intuitive interface is the nipple; everything else is learned]
21:51|-|jcpiza [~jcpiza@84.79.67.254] has joined #uml
22:32|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has quit [Quit: WeeChat 0.2.7-dev]
22:36|-|tchan [~tchan@c-24-13-84-219.hsd1.il.comcast.net] has joined #uml
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 Sat Dec 08 00:00:45 2007