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

---Logopened Tue Dec 04 00:00:16 2007
00:38|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has quit [Quit: The only intuitive interface is the nipple; everything else is learned]
00:46|-|balbir [~balbir@122.167.177.89] has quit [Ping timeout: 480 seconds]
01:13|-|mgross [~mgross@pool-71-245-99-169.ptldor.fios.verizon.net] has quit [Quit: Ex-Chat]
05:17|-|aroscha [~aroscha@77.116.25.124] has joined #uml
05:29|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has joined #uml
05:47|-|aroscha [~aroscha@77.116.25.124] has quit [Ping timeout: 480 seconds]
06:28|-|aroscha [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has joined #uml
06:38|-|Netsplit cation.oftc.net <-> magnet.oftc.net quits: weasel, SNy
06:38|-|Netsplit over, joins: SNy, weasel
08:26|-|balbir [~balbir@122.167.177.89] has joined #uml
08:28|-|Netsplit resistance.oftc.net <-> oxygen.oftc.net quits: ElectricElf, tasaro, huslu, caker
08:29|-|Netsplit over, joins: caker, tasaro, ElectricElf, huslu
08:30|-|tasaro [~tom@ns.theshore.net] has quit [Read error: Operation timed out]
08:30|-|tasaro [~tom@ns.theshore.net] has joined #uml
08:31|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
08:31|-|caker [~caker@ns.theshore.net] has joined #uml
09:01|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:39|-|dgraves_ [~asdf@inet-netcache3-o.oracle.com] has quit [Remote host closed the connection]
09:42|-|dgraves_ [~asdf@inet-nc01-o.oracle.com] has joined #uml
10:10|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
10:10<jdike-#uml->>Hi guys
10:10<dgraves_-#uml->>morning jdike.
10:10[~]dgraves_ #uml hands jdike some donuts and coffee.#uml-> hands jdike some donuts and coffee.
10:11<dgraves_-#uml->>there. that's my bribe for the day. ;)
10:11<dgraves_-#uml->>i'm just figuring out this quilt patch/git-bisect. Looks interesting.
10:11<dgraves_-#uml->>the tools you kids have these days. ;)
10:11<karol-#uml->>Hey, jdike. Last testing before another unused variable patch is sent. From now on I will just batch them, because I seem to be finding a lot and I hate the noise I am making.
10:11<dgraves_-#uml->>more noise is good!
10:13<jdike-#uml->>dgraves, you can see how to turn the RHEL patches into a quilt series?
10:14<jdike-#uml->>once you do that, it's a matter of quilt push/pop $n ; quilt push/pop $n/2 until you've figured out what's breaking UML
10:14<jdike-#uml->>karol, batch em
10:15<jdike-#uml->>for this sort of thing, one patch for a bunch of changes is good
10:15<karol-#uml->>Yeah, except i *just* clicked 'send'.
10:15<jdike-#uml->>hehe
10:15<karol-#uml->>So for next ones.
10:15<jdike-#uml->>I'll batch them here then
10:15<karol-#uml->>Sorry about that.
10:15<dgraves_-#uml->>jdike, yeah, i think i do. basically i make a patch file listing them in order, and then use the quilt commands to apply them. first though i need to turn this tree into a git repos, so i can specify git-bisect good and bad.
10:16<jdike-#uml->>you need either quilt or git, not both
10:16<jdike-#uml->>I'm recommending quilt because I'm more familiar with it
10:17<jdike-#uml->>if you'd rather turn the rhel patches into a git repo, then git-bisect will take care of the bookkeeping for you
10:17<dgraves_-#uml->><jdike> no
10:17<dgraves_-#uml->><jdike> turn the rhel patches into a quilt series
10:17<dgraves_-#uml->><jdike> then bisect that
10:17<dgraves_-#uml->><dgraves_> okay....
10:17<dgraves_-#uml->>oh. i thought yesterday you said to use both. :)
10:17<dgraves_-#uml->>i'll do quilt then.
10:17<jdike-#uml->>I didn't mean git-bisect
10:17<dgraves_-#uml->>i'm (slightly) more familiar than that.
10:17<dgraves_-#uml->>oh, just bisect "search" in general.
10:17<jdike-#uml->>I meant bisect as a generic term
10:17<dgraves_-#uml->>gotcha.
10:17[~]dgraves_ #uml thinks of it as binary search.#uml-> thinks of it as binary search.
10:18<dgraves_-#uml->>well, i'm setting up the quilt stuff right now.
10:18<dgraves_-#uml->>so we'll see how it goes.
10:19<dgraves_-#uml->>although, i think i'm gonna get me some honey nut cherrios.
10:21<karol-#uml->>I took a day off from school for the kernel today, so I can debug the stack bug. And then I got distracted...
10:21<dgraves_-#uml->>distracted from the kernel? where's your priorities?
10:22<karol-#uml->>Not quite from the kernel.
10:22<karol-#uml->>I wrote a program which does 'make randconfig; make' till the end of the world.
10:22<karol-#uml->>And sorts the failures depending on cause.
10:23<karol-#uml->>rc4 did fine on x86 but on um I had 8/10 build failures...
10:23<dgraves_-#uml->>heh. i was reading about that the other day, and thought about doing it myself.
10:23<dgraves_-#uml->>yeah, there's some craziness in the UML build. got to get it just right.
10:23<jdike-#uml->>I thought we were better on randconfig
10:23<jdike-#uml->>esp after the !PRINTK and !TCP fixes
10:24<karol-#uml->>Sec...
10:24<jdike-#uml->>except those might not be in mainline yet
10:24<jdike-#uml->>I might have decided they weren't bug-fixy enough to make 2.6.24
10:25<karol-#uml->>Nope. Neither of those made my list. Which I deleted. Ah well, I have ccache so building UML a bunch of times won't take long.
10:26<jdike-#uml->>nope, they're both in mainline
10:26<jdike-#uml->>so you found something else
10:27<karol-#uml->>I set it to work.
10:27<karol-#uml->>Funny how I hate automatic testing, but that is what I always end up coding.
10:27<karol-#uml->>I will take a look in an hour, see what comes out.
10:27<karol-#uml->>Build #1 BROKEN - brokenconfig-1
10:28<karol-#uml->>:/
10:28<jdike-#uml->>rc4 builds and boots out of the box
10:28<karol-#uml->>Yeah, defconfig is ok.
10:28<karol-#uml->>That was great, finally no patching.
10:28<jdike-#uml->>the first rc to do so this series
10:30<karol-#uml->>Uml did survive 10 minutes of crashme today. I did not want to push my luck, but it seemed to do pretty well.
10:31<jdike-#uml->>I need to check that again
10:31<jdike-#uml->>crashme + a kernel build was the killer here
10:46<karol-#uml->>Build #20 BROKEN - brokenconfig-19
10:46<karol-#uml->>1/20 success rate.
10:47<karol-#uml->>19 errors divided into 4 causes.
10:47<jdike-#uml->>that implies 4 or 5 symbols that break the build when changed
10:48<dgraves_-#uml->>jdike, i think the command i want to use is quilt import to import the patch file into the quilt series?
10:48<jdike-#uml->>yup
10:48<jdike-#uml->>you have the correct order?
10:49<karol-#uml->>One error is caused by randconfig selecting real hardware, strip radio or something like that.
10:49<dgraves_-#uml->>there's an order listed in the rpm spec file.
10:49<dgraves_-#uml->>so I think i just import them in that order?
10:49<jdike-#uml->>yup
10:49<dgraves_-#uml->>or is it reverse order due to filo stack?
10:49<jdike-#uml->>probably forward order
10:49<karol-#uml->>The second error is this: gcc: -pg and -fomit-frame-pointer are incompatible
10:50<jdike-#uml->>we fixed that though
10:50<jdike-#uml->>that's in -mm
10:50<karol-#uml->>Not on the mainline apparently. This error occurred twice.
10:50<karol-#uml->>I will need to doublecheck, but...
10:50<karol-#uml->>Two more to go to analyse.
10:51<dgraves_-#uml->>off topic, but anyone want to buy a MILF? http://feeds.gawker.com/~r/consumerist/full/~3/194493939/spirit-airlines-holds-milf-sale-denies-having-seen-american-pie-329237.php
10:53<karol-#uml->>I actually had to look that one up. Crazy.
10:53<dgraves_-#uml->>::L::
10:53<dgraves_-#uml->>karol, i don't *usually* post stuff off-topic here, but it was just too funny to ignore. :)
10:55<karol-#uml->>I mean I had to look up the acronym.
10:55<dgraves_-#uml->>yeah, i know. :)
10:55<karol-#uml->>:)
11:03<karol-#uml->>The most common error was caused by SMP.
11:04|-|aroscha [~aroscha@vivilokal.vivi.wien.funkfeuer.at] has quit [Quit: aroscha]
11:07<karol-#uml->>Hmm... Something is up though.
11:07<karol-#uml->>I don't see SMP in menuconfig.
11:08<karol-#uml->>And now I see it again, after a make mrproper.
11:08<karol-#uml->>Anyway, that is for 100% sure the cause.
11:10<karol-#uml->>The final error is caused by !SWAP
11:10<karol-#uml->>So we have: frame pointers + gprof, SMP, !SWAP, and a real device.
11:11<jdike-#uml->>there are fixes on the way for all but the real device one
11:13<dgraves_-#uml->>jdike, did the CONFIG_HZ not defined when the config option for delaying kernel messages option was selected get fixed?
11:13[~]dgraves_ #uml feels like he should stick parens in that statement.#uml-> feels like he should stick parens in that statement.
11:13<jdike-#uml->>didn't know about that
11:14<dgraves_-#uml->>jdike, (did the (CONFIG_HZ not defined) when ((the config option for delaying kernel messages option) was selected) get fixed)?
11:14<dgraves_-#uml->>i hit it the other day once or twice. turning that option off fixed it, but i haven't tried to reproduce it. (seeing as i'm building other stuff right now. :) )
11:15<jdike-#uml->>(dgraves (know (about that) didn't))
11:16<karol-#uml->>I sense an evil scheme in the air. :)
11:16<karol-#uml->>Tried LISP and dialects once or twice. Blew my mind, and gave up. C was/is hard enough.
11:17<dgraves_-#uml->>::ROFL::
11:17<dgraves_-#uml->>LISP Is pretty fun.
11:17<dgraves_-#uml->>Lost in stupid parens!
11:17<dgraves_-#uml->>prefix is fun, and the lambda functions are neat.
11:29<karol-#uml->>Two more unused variables...
11:35<jdike-#uml->>rc4 build fine with CONFIG_BOOT_PRINTK_DELAY enabled
11:37<dgraves_-#uml->>::shrug:: cool!
11:45|-|aroscha [~aroscha@77.118.220.33] has joined #uml
11:57|-|aroscha [~aroscha@77.118.220.33] has quit [Ping timeout: 480 seconds]
11:59|-|aroscha [~aroscha@pnsgw3-client097.demo.tuwien.ac.at] has joined #uml
12:01|-|aroscha [~aroscha@pnsgw3-client097.demo.tuwien.ac.at] has quit []
12:07|-|__dgraves__ [~asdf@inet-netcache3-o.oracle.com] has joined #uml
12:07|-|dgraves_ [~asdf@inet-nc01-o.oracle.com] has quit [Remote host closed the connection]
12:07|-|__dgraves__ changed nick to dgraves_
12:13|-|aroscha [~aroscha@pnsgw3-client097.demo.tuwien.ac.at] has joined #uml
12:36|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
12:36<karol-#uml->>jdike: So far I have not progressed very far, but I already think there are two bugs which can happen stack showing.
12:36<karol-#uml->>One spins, the other crashes with something looking like stack corruption.
12:37<karol-#uml->>Those may or may not be related, I don't know yet.
12:38<dgraves_-#uml->>karol, does the spinner have stack corruption as well?
12:38<karol-#uml->>I don't know yet. I am working on it.
12:38<karol-#uml->>I don't think so though.
12:39<karol-#uml->>Spinning is easy when you target a kernel thread. Normal threads sometimes respond fine and sometimes crash.
12:39<dgraves_-#uml->>tell me about it. :)
12:39<karol-#uml->>(stoptest) stack 1
12:39<karol-#uml->>OK
12:39<karol-#uml->>(stoptest)
12:39<karol-#uml->>Pretty funny, in a sour way.
12:39<karol-#uml->>Something is still kicking in UML, but...
12:42<dgraves_-#uml->>what's the stack state of the system? sysrq-t?
12:44<karol-#uml->>I don't know, but gdb tells me it died violently, and as such I am really wondering what is responding to mconsole.
12:47<dgraves_-#uml->>NICE! quilt handles .bz2 patches. :)
12:47|-|tyler29 [~tyler@ARennes-257-1-144-30.w86-210.abo.wanadoo.fr] has joined #uml
12:48<karol-#uml->>The spinner is touring the scheduler.
12:48<dgraves_-#uml->>::L::
12:48<dgraves_-#uml->>does it like it? :)
12:48<karol-#uml->>Seems to. Won't leave.
12:49<karol-#uml->>Now, sysrq time. I wonder if it will crash in a similar way.
12:52<karol-#uml->>It does not.
13:03<karol-#uml->>Yeah, with the crash the system shows stacks fine, except the one which I probed.
13:03<karol-#uml->>Kernel panic - not syncing: Kernel mode fault at addr 0x140aac88, ip 0x81fabdc
13:03<karol-#uml->>But yet, sysrq works. Go figure.
13:04<karol-#uml->>For a while anyway.
13:05<karol-#uml->>I really don't like how we use switch_to for stack dumping with mconsole. Maybe there is a better way. Gonna ponder it.
13:06<jdike-#uml->>the purpose of stack isn't to generate a stack
13:07<jdike-#uml->>it's to bring the process into context so it can be examined with gdb
13:08<karol-#uml->>Really? The mconsole help text does not say anything about that... Ok, I understand now.
13:08<karol-#uml->>I did not know about that bit.
13:09<dgraves_-#uml->>remember when we put that in there a couple years ago, jdike?
13:09<dgraves_-#uml->>:)
13:09<jdike-#uml->>"we"?
13:09<jdike-#uml->>I remember dgraves being totally and entirely responsible for that, including all bugs, if any
13:10<dgraves_-#uml->>::ROFL::
13:10<dgraves_-#uml->>i recall being hand held through that process... :) and getting all the spam from that first kernel submit, getting my wrist slapped at work for using my oracle email.... ah, good times, good times. :)
13:11<karol-#uml->>Ah, kernel spam... Yum. Don't you feel lucky for winning all those lotteries though?
13:11<dgraves_-#uml->>yeah, my wife wasn't sure what to say when i ordered 500 crates of viagra... ;-P
13:17<jdike-#uml->>it's not like you couldn't afford it
13:17<jdike-#uml->>with all your lottery winnings and Nigerian money transfer proceeds
13:18<dgraves_-#uml->>yeah. i've been so helpful with the money transfers ,that other people in other countries are asking for my help now!
13:18<dgraves_-#uml->>i'll be reach, soon as I get the money they owe me.
13:18<dgraves_-#uml->>i'll be rich.
13:21|-|aroscha [~aroscha@pnsgw3-client097.demo.tuwien.ac.at] has quit [Quit: aroscha]
13:23<dang-#uml->>jdike: Did you ever hook UML entropy into the host entropy?
13:24<dgraves_-#uml->>sounds great! we need more UML entropy!
13:25<karol-#uml->>dang: I think it was done... Let me see.
13:25<karol-#uml->>CONFIG_UML_RANDOM
13:25<dang-#uml->>Ah, thanks.
13:26<jdike-#uml->>dang, it looks like a hardware RNG
13:26<dang-#uml->>Yep. I just missed it...
13:26<jdike-#uml->>so you need rand-utils or something to have it feed /dev/random
13:26<dang-#uml->>Apparently I grepped for RANDOM in my normal config, not my UML config. I only grepped for entropy in my UML config.
13:33<dgraves_-#uml->>jdike: heading for big compile after the huge main patch of EL5 was applied.
13:33<jdike-#uml->>hmm
13:34<jdike-#uml->>they have one big patch in there?
13:35<dgraves_-#uml->>well, the first patch they apply touches like billions of files.
13:35<dgraves_-#uml->>then they apply 446 other patches.
13:35<dgraves_-#uml->>on top of that one.
13:35|-|aroscha [~aroscha@84.112.87.195] has joined #uml
13:35<jdike-#uml->>hmm
13:35<dgraves_-#uml->>so i had to get the first one working correctly, and set up quilt (since it wanted to install to mounted dirs), then figure out that quilt wanted the patches in reverse application order, etc.
13:36<jdike-#uml->>quilt wants the patches in forward order
13:36<dgraves_-#uml->>not with quilt import.
13:36<dgraves_-#uml->>if i gave it to them in install order, it tried to install the last patch first.
13:36<jdike-#uml->>you're supposed to push each patch after the import
13:36<jdike-#uml->>or at least that's how I work it
13:36<dgraves_-#uml->>i figured i'd import them all and then push them individually or in batches.
13:38<dgraves_-#uml->>okay, looks like we're working so far...
13:40<dgraves_-#uml->>whoot! login prompt. :)
13:42|-|tyler29 [~tyler@ARennes-257-1-144-30.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:43<dgraves_-#uml->>jdike, how do i tell quilt to push a patch in -R mode?
13:43<dgraves_-#uml->>the push doesn't seem to take that option.
13:43<dgraves_-#uml->>the only thing maybe -i.
13:43<jdike-#uml->>why do you want to do that?
13:44<dgraves_-#uml->>cause redhat wants one of their patches to be applied -R.
13:44<dgraves_-#uml->>they want to get rid of somet stuff, i guess.
13:44<dgraves_-#uml->>--interactive shows the patch util asking me to apply it reverse, but not actually letting me answer.
13:44<dgraves_-#uml->>hrm. i may have to do this one by hand.
13:44<jdike-#uml->>wow
13:44<jdike-#uml->>that's pretty broken
13:45<dgraves_-#uml->>yes. wow. we've said that (and other things) many times now. :)
13:45<jdike-#uml->>they should have just dropped a reversed patch in there
13:45<jdike-#uml->>patch always wants forward patches
13:45<dgraves_-#uml->>wait. is it easy to reverse a patch?
13:45<jdike-#uml->>so I'd quilt delete the patch
13:45<jdike-#uml->>quilt new it
13:46<jdike-#uml->>quilt add `lsdiff the-patch`
13:46<dgraves_-#uml->>well, quilt new each file, right?
13:46<dgraves_-#uml->>oh, no.
13:46<jdike-#uml->>and patch -p1 -R
13:46[~]dgraves_ #uml is reading the man page as we go. :)#uml-> is reading the man page as we go. :)
13:46<jdike-#uml->>and you'll need -p1 on lsdiff to get the right filenames, I think
13:46<dgraves_-#uml->>grovvy. that's exactly what i was wondering.
13:47<jdike-#uml->>--dry-run the patch first to make sure the files it changes are the same as quilt thinks are in the patch
13:47|-|aroscha [~aroscha@84.112.87.195] has quit [Quit: aroscha]
13:52|-|tyler29 [~tyler@ARennes-257-1-128-225.w86-210.abo.wanadoo.fr] has joined #uml
13:52<dgraves_-#uml->>and after that bit of excitement, i'm gonna build again. :)
13:57|-|aroscha [~aroscha@chello084112087195.3.11.vie.surfer.at] has joined #uml
13:58<dgraves_-#uml->>ITS SNOWING AGAIN!!!
13:59|-|aroscha [~aroscha@chello084112087195.3.11.vie.surfer.at] has quit []
14:01|-|aroscha [~aroscha@chello084112087195.3.11.vie.surfer.at] has joined #uml
14:04<dgraves_-#uml->>::sigh:: only 443 patches left to test! :)
14:12<dgraves_-#uml->>jdike, applying the redhat utrace package breaks with all the tracehook.h stuff. Is it better to apply your utrace patches, or just to see what not applying this patch does?
14:24[~]dgraves_ #uml begins applyng the utrace patches, figuring he can back them out later using quilt.#uml-> begins applyng the utrace patches, figuring he can back them out later using quilt.
14:41<jdike-#uml->>now you start bisecting
14:41<jdike-#uml->>9 builds will cover them
14:44<dgraves_-#uml->>not sure what you mean. if i apply the single utrace patch from RH, I have to apply both of your utrace patches you gave me, plus some other misc fixes to get it to build again.
14:46<jdike-#uml->>OK, that's fine
14:46<jdike-#uml->>but if you have breakage somewhere in the middle of the 443 patches, you don't do 442 builds to figure out which patch is the problem
14:46|-|aroscha [~aroscha@chello084112087195.3.11.vie.surfer.at] has quit [Quit: aroscha]
14:47<karol-#uml->>I'm actually learning to use gdb to figure out this problem. Damnit. This is... fun. Learning is not supposed to be fun.
14:52<dgraves_-#uml->>jdike, right. i'm doing the major patches. the other 350 of them are more minor, i think.
14:52<dgraves_-#uml->>i was worried about the big one, the utrace, pretty much.
14:52<jdike-#uml->>I was worried about the megapatch
14:55<dgraves_-#uml->>well, its working so far. I'm rebuilding after utrace stuff now. I'm gonna be smart about it. :) diong 500 builds isn't what i want to do.
14:55<dgraves_-#uml->>and having the ability to remove them through quilt is really nice.
14:56<jdike-#uml->>you know push and pop take numbers, right?
14:57<dgraves_-#uml->>yup.
14:57|-|kos_tom [~thomas@col31-3-82-247-183-72.fbx.proxad.net] has joined #uml
14:57<jdike-#uml->>OK
14:58<dgraves_-#uml->>i started off with 224, being optimistic, and had hunks fail in the first one. :)
15:02<dgraves_-#uml->>jdike, looks like 64bit works so far....
15:02[~]dgraves_ #uml hopes this all works when he takes the binary back to RHEL4 system... :)#uml-> hopes this all works when he takes the binary back to RHEL4 system... :)
15:14|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
15:24|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
15:24|-|newbie [~jeff@ita4fw1.itasoftware.com] has quit [Remote host closed the connection]
15:25<dgraves_-#uml->>jdike, is it a known issue for 2.6.18 that it panics on reboot in 64 bit mode?
15:25|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
15:25<jdike-#uml->>not that I know of
15:25<dgraves_-#uml->>do we care? :)
15:26<dgraves_-#uml->>i don't think 2.6.14 reboots sucessfully.
15:32|-|newbie [~jeff@ita4fw1.itasoftware.com] has left #uml []
15:33|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
16:20|-|jdykstra [~jwd@c-24-131-149-37.hsd1.ma.comcast.net] has joined #uml
16:21<jdykstra-#uml->>i need help with something......when running in SKAS mode, which thread is it that shows up in ps output on the host as [vmlinux]?
16:33|-|jdykstra [~jwd@c-24-131-149-37.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer]
16:34|-|acklen [~matt@disorder.primate.net] has joined #uml
16:36|-|jdykstra [~jwd@c-24-131-149-37.hsd1.ma.comcast.net] has joined #uml
16:40<jdike-#uml->>skas3, you mean?
16:46<jdykstra-#uml->>yes, that's right
16:47<jdike-#uml->>there are four - the main kernel thread, the aio thread, the process thread, and another one
16:49<dgraves_-#uml->>jdike, there were a couple of undefined references to: arch_remove_exec_range and similar functions that I commented out.
16:49<dgraves_-#uml->>it didn't look like most arch's defined them.
16:49<dgraves_-#uml->>they went away in a later kernel...
16:49<dgraves_-#uml->>and it was mostly code like this:
16:49<dgraves_-#uml->> arch_remove_exec_range(current->mm, old_end);*/
16:50<dgraves_-#uml->>i haven't run it yet, but I don't think that'll cause issues, do you?
16:50<jdykstra-#uml->>on the ps -ef output i'm looking at, the "command" field of three of the tasks shows the full UML command....the forth just shows "[vmlinux]"....that's the one eating 100% CPU, which i'm trying to diagnose......gdb can't attach to it
16:50<jdike-#uml->>i doubt it, but I don't remember that at all
16:50<jdike-#uml->>did that appear in one of the RHEL patches?
16:50<dgraves_-#uml->>its in the patches, and after applying a set of 50 or so, it popped up on the compile, so i assume so.
16:51<dgraves_-#uml->>i think it was the dev/mm restrict patch.
16:52<jdike-#uml->>I would go back to the patch that introduced it and add a patch before it which implements a do-nothing version of it
16:52<jdike-#uml->>leave the existing rhel patches alone
16:53<dgraves_-#uml->>Mmm... that probably would have been better.
16:53<jdike-#uml->>jdykstra, in the order of pids, which process is that?
16:53<jdykstra-#uml->>appears second, after the parent process
16:53<jdike-#uml->>if you can't attach it, it's the userspace thread
16:53<jdike-#uml->>that's the only one that's under ptrace
16:54<jdike-#uml->>what's the state of the UML as a whole?
16:55<jdykstra-#uml->>that one thread is being very effective at sucking up 100% CPU.....so i'm not able to telnet to the machine or anything......any other way to poke at it you'd suggest?
16:55<jdike-#uml->>is the UML hung?
16:56<jdykstra-#uml->>i don't understand how to tell that, if i can't get any user-mode processes to respond...or maybe that answers your question
16:56<jdike-#uml->>an infinite loop inside a UML will do that, but you should still be able to do stuff within the UML
16:56<jdike-#uml->>does it ping?
16:57<jdykstra-#uml->>give me a second.....this is one of 14 UMLs on that host and i have to figure out its IP again
16:58<jdykstra-#uml->>i get ping responses from it
16:59<jdike-#uml->>so it's not totally dead
16:59<jdykstra-#uml->>trying to telnet again.....the TCP connection establishes but so far i haven't gotten anything from login
17:00<jdike-#uml->>do you know what process that is inside the UML?
17:00<jdykstra-#uml->>no....there are a lot of them running, besides the usual deamons
17:02<jdykstra-#uml->>top - 20:17:07 up 12 min, 1 user, load average: 0.12, 0.10, 0.04
17:02<jdykstra-#uml->>Tasks: 40 total, 1 running, 39 sleeping, 0 stopped, 0 zombie
17:02<jdykstra-#uml->>Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
17:02<jdykstra-#uml->>Mem: 254888k total, 125292k used, 129596k free, 792k buffers
17:02<jdykstra-#uml->>Swap: 0k total, 0k used, 0k free, 87448k cached
17:02<jdykstra-#uml->> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17:02<jdykstra-#uml->> 1 root 16 0 1812 624 532 S 0.0 0.2 0:00.01 init
17:02<jdykstra-#uml->> 2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
17:02<jdykstra-#uml->> 3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
17:02<jdykstra-#uml->> 4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/0
17:02<jdykstra-#uml->> 5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
17:02<jdykstra-#uml->> 6 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
17:02<jdykstra-#uml->> 7 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
17:02<jdykstra-#uml->> 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
17:02<jdykstra-#uml->> 9 root 15 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
17:02<jdykstra-#uml->> 11 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
17:02<jdykstra-#uml->> 10 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0
17:02<jdike-#uml->>don't paste the whole thing
17:02<jdykstra-#uml->> 12 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsIO
17:02<jdykstra-#uml->> 13 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsCommit
17:02<jdykstra-#uml->> 14 root 25 0 0 0 0 S 0.0 0.0 0:00.00 jfsSync
17:02<jdykstra-#uml->> 211 root 16 0 1508 552 460 S 0.0 0.2 0:00.02 syslogd
17:02<jdykstra-#uml->> 215 root 16 0 1468 372 308 S 0.0 0.1 0:00.02 klogd
17:02<jdike-#uml->>not here anyway
17:02<jdykstra-#uml->>that was a top running on it at the time it hung....sorry
17:02<jdike-#uml->>pastebin or rafb
17:03<jdykstra-#uml->>ok......i'm a newbie on here
17:03<jdike-#uml->>so you do have a terminal on it, and that has just been getting no updates?
17:04<jdykstra-#uml->>looks like it....one of software QA people was doing this, and he pulled me in when the UML seemingly hung.....I'm looking at his VNC session right now
17:04<jdykstra-#uml->>that's from the emulated machine's console terminal
17:04<jdykstra-#uml->>he was logged in on it
17:05<jdykstra-#uml->>this isn't your to debug, unless you're intrigued or masochistic (sp?).....that it's the user process thread is the key piece of info i needed
17:07<jdykstra-#uml->>this is a 2.6.14 kernel, plus lots of additional patches....you don't remember any UML bugs that caused CPU scheduling to get stuck on one task, do you?
17:08<jdike-#uml->>no
17:08<jdike-#uml->>but that was a long time ago
17:08<jdike-#uml->>and many bug fixes ago
17:08<jdike-#uml->>you can't use something more modern
17:08<jdike-#uml->>?
17:09<jdykstra-#uml->>k.....thanks for the help.....i don't see the donate link on the SourceForge homepage....is there still a way i can donate, even if my employer won't?
17:09<jdike-#uml->>there's one on the old site - there's a link to it
17:10<jdike-#uml->>I didn't bother copying it when I redid the site
17:10<jdykstra-#uml->><sigh> this is Wind River's PNE release for networking devices.....we're stuck with it for the indefinite future....i'll go use the old link...thanks!
17:10<dgraves_-#uml->>::L:: sounds familiar, eh? :)
17:11<jdykstra-#uml->>that to me or to Jeff?
17:11<dgraves_-#uml->>jeff. :) we're stuck on 2.6.14 as well.
17:12<jdykstra-#uml->>ah
17:12<dgraves_-#uml->>in fact, jdike has been nicely helping me get 2.6.18.EL5 working.
17:12<dgraves_-#uml->>which is still behind the times. :-P
17:17|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:25|-|jdykstra [~jwd@c-24-131-149-37.hsd1.ma.comcast.net] has left #uml []
17:47|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
18:03|-|acklen [~matt@disorder.primate.net] has quit [Quit: Leaving]
18:06|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
18:07|-|tyler29 [~tyler@ARennes-257-1-128-225.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
18:09|-|kos_tom [~thomas@col31-3-82-247-183-72.fbx.proxad.net] has quit [Quit: I like core dumps]
18:39<karol-#uml->>A whole day spent debugging this thingy. And I'm not any wiser as to the cause. My attempts to fix it only made the spin guaranteed instead of a crash sometimes.
18:39<karol-#uml->>But I will get it solved somehow.
18:41|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has quit [Quit: The only intuitive interface is the nipple; everything else is learned]
18:57|-|dang [~dang@nemesis.fprintf.net] has joined #uml
19:17|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
19:24|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
19:26|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit []
20:18|-|dang [~dang@nemesis.fprintf.net] has quit [Ping timeout: 480 seconds]
20:21|-|dang [~dang@nemesis.fprintf.net] has joined #uml
20:51|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
21:12|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
21:24|-|Netsplit resistance.oftc.net <-> cation.oftc.net quits: Urgleflogue, SNy, weasel, Hunger, karol
21:24|-|Netsplit over, joins: weasel, Hunger, SNy, karol, Urgleflogue
21:59|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
22:07|-|dang [~dang@nemesis.fprintf.net] has quit [Ping timeout: 480 seconds]
22:14|-|dang [~dang@nemesis.fprintf.net] has joined #uml
23:37|-|dang [~dang@nemesis.fprintf.net] has quit [Ping timeout: 480 seconds]
23:49|-|dang [~dang@nemesis.fprintf.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 Wed Dec 05 00:00:37 2007