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

---Logopened Wed Nov 28 00:00:05 2007
00:14|-|balbir [~balbir@122.167.180.57] has quit [Read error: Operation timed out]
00:15|-|balbir [~balbir@122.167.180.57] has joined #uml
00:30|-|ElectricElf [~dbharris@bas1-toronto48-1242461494.dsl.bell.ca] has quit [Server closed connection]
00:30|-|ElectricElf [~dbharris@bas1-toronto48-1242461494.dsl.bell.ca] has joined #uml
00:35|-|newb [~tkxue@171.66.6.210] has joined #uml
00:35<newb-#uml->>is it posible to run a 32bit uml on a 64 bit host?
00:35<newb-#uml->>i'm guessing not since uml threads are emulated as host threads?
00:35<newb-#uml->>but just wanted to check
00:57|-|ElectricElf [~dbharris@bas1-toronto48-1242461494.dsl.bell.ca] has quit [Ping timeout: 480 seconds]
00:58|-|balbir [~balbir@122.167.180.57] has quit [Ping timeout: 480 seconds]
---Logclosed Wed Nov 28 01:10:08 2007
---Logopened Wed Nov 28 01:10:09 2007
01:10|-|mikegrb [~michael@mail.thegrebs.com] has joined #uml
01:10|-|Ekipa kanalu #uml: Wszystkich: 28 |-| +op [0] |-| +voice [0] |-| normalnych [28]
01:11|-|ElectricElf [~dbharris@bas1-toronto48-1242461494.dsl.bell.ca] has joined #uml
01:12|-|Kanal #uml zsynchronizowany w 127 sekundy
01:25|-|newb [~tkxue@171.66.6.210] has left #uml [Leaving]
01:32|-|caker [~caker@ns.theshore.net] has joined #uml
01:44|-|balbir [~balbir@59.145.136.1] has joined #uml
01:56|-|mgross [~mgross@pool-71-117-236-31.ptldor.fios.verizon.net] has joined #uml
02:02|-|Urgleflogue [~plamen@83.228.65.158] has quit [Ping timeout: 480 seconds]
02:28|-|mgross [~mgross@pool-71-117-236-31.ptldor.fios.verizon.net] has quit [Quit: Leaving]
02:33|-|Urgleflogue [~plamen@83.228.65.158] has joined #uml
03:28|-|mjf [~mjf@r5bb59.net.upc.cz] has joined #uml
03:41|-|mjf [~mjf@r5bb59.net.upc.cz] has quit [Quit: leaving]
06:29|-|da-x [~karrde@xiv-glob.ser.netvision.net.il] has quit [Ping timeout: 480 seconds]
07:12|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has joined #uml
08:38|-|dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.]
08:58|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
10:04|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
10:10|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
10:28|-|freepenguin [~andrew@host42-125-dynamic.3-87-r.retail.telecomitalia.it] has joined #uml
10:37<freepenguin-#uml->>http://www.freepenguin.it/index-en.html
10:39|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
10:39<jdike-#uml->>Hi guys
10:41<caker-#uml->>cookie
10:41<caker-#uml->>(trying to mix it up a bit)
10:41<jdike-#uml->>yum
10:42<IntuitiveNipple-#uml->>Hi jdike: When you have some free 'debug' time would you be able to help me narrow down the issues I have with the 32-bit on 64-bit situ?
10:42<jdike-#uml->>what's the problem?
10:43<IntuitiveNipple-#uml->>It looks like the same as I reported before - the CPU running hard as soon as the init process starts. I think my earlier report on fixing it was a bit premature
10:43<IntuitiveNipple-#uml->>I've gone a long way to getting to the crux of it but I'm a but lost on where to look specifically now
10:45<IntuitiveNipple-#uml->>The essence is, the init process mmap()s a configuration file, but any attempt to read the mmap()ed memory causes it to hang - CPU looping hard. I've straced, linux -debug, and so forth but because it looks to be a thread issue on the host not quite clear what is the next step
10:45<IntuitiveNipple-#uml->>I've been using the latest 2.6.24-rc3 source
10:47<jdike-#uml->>what does strace show?
10:49<IntuitiveNipple-#uml->>It appears to be stuck in a loop doing PTRACE_CONT, when compared to a 64-bit kernel/guest
10:49<IntuitiveNipple-#uml->>let me pastebin some info
10:50<jdike-#uml->>the signal reported by wait is what's interesting
10:52<IntuitiveNipple-#uml->>The "--- SIGCHLD (Child exited) @ 0 (0) ---" following the CONT ?
10:53<jdike-#uml->>no, the wait
10:57|-|dang [~dang@aa-redwall.nexthop.com] has quit [Remote host closed the connection]
10:58<IntuitiveNipple-#uml->>Hmmm... here's the combined outputs, with initial extraneous stuff removed. http://pastebin.intuitivenipple.net/95
10:59<jdike-#uml->>waitpid(8176, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSEGV}], WSTOPPED) = 8176
11:00<jdike-#uml->>it's in a segfault loop
11:01<IntuitiveNipple-#uml->>What's the best way to debug it?
11:01|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
11:01<IntuitiveNipple-#uml->>I've tried attaching gdb but so far had little in the way of clues
11:03<jdike-#uml->>what's the host running?
11:04<IntuitiveNipple-#uml->>2.6.22.8 (Ubuntu Gutsy x86_64)
11:04<jdike-#uml->>do you see something like this in the UML boot?
11:04<jdike-#uml->>Detected host type: i386 (GDT indexes 6 to 9)
11:05<IntuitiveNipple-#uml->>Checking host MADV_REMOVE support...OK
11:05<IntuitiveNipple-#uml->>mconsole (version 2) initialized on /home/tj/.uml/3LtwY3/mconsole
11:05<IntuitiveNipple-#uml->>Host TLS support detected
11:05<IntuitiveNipple-#uml->>Detected host type: x86_64
11:05<jdike-#uml->>hmm, the GDT range is only in -mm, I guess
11:06<IntuitiveNipple-#uml->>I've tried this with both my own UML kernels, and others (I tried some of caker's Linode kernels too) and get the same result
11:06<jdike-#uml->>I'm suspicious that you're hitting the ptrace PTRACE_SET_THREAD_AREA emulation bug
11:07<IntuitiveNipple-#uml->>Funny thing is, I 'solved' it previously inadvertently when I was building the UML kernel using the Ubuntu i386 kernel config files with a few additions to build-in the root file-system. It took me a while to realise this hit me when I used the UML defconfig or a copy of the Linode kernel config
11:07<IntuitiveNipple-#uml->>Is there anything I can do to prove/disprove that?
11:09<jdike-#uml->>I think if you use a sufficiently old filesystem, it'll be fine because it doesn't use TLS
11:11<IntuitiveNipple-#uml->>guest root file-system, do you mean?
11:13<jdike-#uml->>yes
11:14<IntuitiveNipple-#uml->>off the top of your head, any idea how far back I'd need to go?
11:15<jdike-#uml->>no
11:15<jdike-#uml->>it might depend on the sidtro
11:15<jdike-#uml->>distro
11:15<jdike-#uml->>current Debian might be fine, for example :-)
11:15<IntuitiveNipple-#uml->>so, it is a case of finding a kernel that doesn't have TLS?
11:15<jdike-#uml->>no
11:15<jdike-#uml->>a filesystem which doesn't use it
11:16<IntuitiveNipple-#uml->>file-system as in ext3, you mean?
11:16<jdike-#uml->>no
11:16<IntuitiveNipple-#uml->>Are we on about glibc installation then? lol
11:16<jdike-#uml->>as in root-fs-no-tls.ext3
11:17<jdike-#uml->>can you update the host kernel?
11:17<jdike-#uml->>current mainline has all bug fixes that I know to be needed for this
11:19<IntuitiveNipple-#uml->>I can on a test basis, but I need to stick with what I'm using for normal usage
11:32|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection]
11:39|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has joined #uml
11:47|-|balbir [~balbir@122.167.215.224] has joined #uml
12:18|-|tyler29 [~tyler@ARennes-257-1-158-98.w86-214.abo.wanadoo.fr] has joined #uml
12:34|-|balbir [~balbir@122.167.215.224] has quit [Read error: Operation timed out]
12:44|-|tyler29 [~tyler@ARennes-257-1-158-98.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:00|-|tyler29 [~tyler@ARennes-257-1-140-174.w86-210.abo.wanadoo.fr] has joined #uml
13:43|-|dgraves [~agraves@inet-netcache2-o.oracle.com] has joined #uml
13:44<dgraves-#uml->>I LIVE!!!!
13:45<jdike-#uml->>hehe
13:49<Magotari-#uml->>jdike: I guess you would know, but in case you don't yet: mm2 does not compile by default. Same problem as before, so I guess some patch did not make it through yet.
13:49<jdike-#uml->>yeah, I'm sending in build patches now
13:49<jdike-#uml->>these will be for rc3
13:49<Magotari-#uml->>Ok, sorry to report it then.
13:49<jdike-#uml->>I'll send in some -mm-only patches tomorrow
13:59<dgraves-#uml->>jdike, its been a long while since I've built uml, and i'm working on the new 2.6.18 tree.
13:59<dgraves-#uml->>is it still make ARCH=um mrproper defconfig && make ARCH=um?
14:00<jdike-#uml->>that's kinda old
14:00<jdike-#uml->>yup, no changes
14:01<dgraves-#uml->>jdike, yeah, i work in an enterprise industry. :)
14:03<dgraves-#uml->>jdike, is this normal:
14:03<dgraves-#uml->>In file included from arch/um/include/os.h:13,
14:03<dgraves-#uml->> from arch/um/drivers/fd.c:14:
14:03<dgraves-#uml->>arch/um/include/kern_util.h:9:27: error: linux/threads.h: No such file or directory
14:03<dgraves-#uml->>make[1]: *** [arch/um/drivers/fd.o] Error 1
14:03<dgraves-#uml->>? :)
14:03<jdike-#uml->>no
14:03<dgraves-#uml->>oh good. :)
14:03<dgraves-#uml->>i'm abnormal.
14:04<jdike-#uml->>try deleting the include
14:05<dgraves-#uml->>the kern_util.h?
14:06<jdike-#uml->>yup
14:06<jdike-#uml->>no
14:06<dgraves-#uml->>err...
14:06<jdike-#uml->>the linux/threads.h include in kern_util.h
14:06<dgraves-#uml->>oh.
14:06<jdike-#uml->>confused yet?
14:06<dgraves-#uml->>::L::
14:06<dgraves-#uml->>yes.
14:07[~]dgraves #uml restores his kernel tree from tarball. :)#uml-> restores his kernel tree from tarball. :)
14:10<dgraves-#uml->>whoo.. that blew up.
14:10<dgraves-#uml->>arch/um/os-Linux/process.c:144: error: expected declaration specifiers or ?...? before ?getpid?
14:10<dgraves-#uml->>arch/um/os-Linux/process.c:146: warning: return type defaults to ?int?
14:10<dgraves-#uml->>arch/um/os-Linux/process.c: In function ?_syscall0?:
14:10<dgraves-#uml->>arch/um/os-Linux/process.c:147: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?{? token
14:10<dgraves-#uml->>arch/um/os-Linux/process.c:152: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attri
14:10<dgraves-#uml->>...
14:10<dgraves-#uml->>etc.
14:11<dgraves-#uml->>inline _syscall0(pid_t, getpid)
14:11<dgraves-#uml->>hrm?
14:12<jdike-#uml->>what's the host distro?
14:13<dgraves-#uml->>Oracle Enterprise Linux EL 5
14:13<dgraves-#uml->>based off of RH5.
14:13<dgraves-#uml->>(I tried compiling the EL5 source rpm with ARCH=um and that was a different set of errors. :) )
14:13<dgraves-#uml->>2.6.18-8
14:14<jdike-#uml->>things that UML uses have been disappearing from distro headers
14:15<jdike-#uml->>and syscall0 was one of them, I think
14:15<dgraves-#uml->>oh, goody!
14:15<jdike-#uml->>I've been fixing it because UML didn't really need them
14:15<dgraves-#uml->>so uh.. what's the fix then? Is it a uml fix, or a distro fix?
14:15<dgraves-#uml->>ah.
14:15<jdike-#uml->>a UML fix
14:15<dgraves-#uml->>makes sense in that case.
14:15<dgraves-#uml->>so i suppose upgrade to a newer uml version is the answer.
14:15<jdike-#uml->>yeah
14:15<jdike-#uml->>the newer the better
14:16[~]dgraves #uml will need to clear this with the boss.#uml-> will need to clear this with the boss.
14:16<dgraves-#uml->>and she's not gonna be happy. :)
14:16<dgraves-#uml->>thanks, jdike.
14:16<jdike-#uml->>np
14:20<dgraves-#uml->>jdike, asm/tracehook.h another one of those sort of files that disappeared?
14:20<jdike-#uml->>no
14:21<jdike-#uml->>things like asm/user.h and asm/page.h
14:21<jdike-#uml->>tracehook sounds more like a kernel header
14:23<dgraves-#uml->>hrm. its included from ptrace.h. (this is in the EL5 source tree.)
14:23<jdike-#uml->>Oh
14:23<jdike-#uml->>that's utrace
14:24<dgraves-#uml->>user trace?
14:24<jdike-#uml->>I was wondering why it sounded familiar yet I didn't have it here
14:24<jdike-#uml->>no, I don't know what "u" stands for
14:25<dgraves-#uml->>oh. huh.
14:25[~]dgraves #uml digs and it looks like ptrace disappeaered from the task_struct as well.#uml-> digs and it looks like ptrace disappeaered from the task_struct as well.
14:25[~]dgraves #uml hates non-generic kernels.#uml-> hates non-generic kernels.
14:25<jdike-#uml->>you're trying to build UML from RHEL sources?
14:25<dgraves-#uml->>yeah. :)
14:25<dgraves-#uml->>RHEL5.
14:25<dgraves-#uml->>well, the first error was from vanilla.
14:25<jdike-#uml->>is that really necessary?
14:25<dgraves-#uml->>i figured i'd poke at the errors i got from the RHEL5 stuff for kicks.
14:26<dgraves-#uml->>our product is RHEL5.
14:26<jdike-#uml->>I have a patch for that
14:26<dgraves-#uml->>a patch for building in RHEL5?
14:26<jdike-#uml->>but it hasn't been touched since utrace got dropped from mm
14:26<jdike-#uml->>a patch for making UML build in the presence of utrace
14:26<dgraves-#uml->>boss wants the closest uml version to RHEL5 (2.6.18-8) for our UML build this year.
14:27<dgraves-#uml->>jdike, if tracehook is the utrace, it looks like it disappeared:
14:27<dgraves-#uml->>In file included from arch/um/kernel/exec.c:8:
14:27<dgraves-#uml->>include/linux/ptrace.h:64:27: error: asm/tracehook.h: No such file or directory
14:27<jdike-#uml->>is this RHEL or vanilla this time?
14:28|-|tyler29 [~tyler@ARennes-257-1-140-174.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
14:29<dgraves-#uml->>RHEL
14:29<dgraves-#uml->>building the UML ARCH out of the RHEL tree on a RHEL system gets me:
14:29<dgraves-#uml->>In file included from arch/um/kernel/exec.c:8:
14:29<dgraves-#uml->>include/linux/ptrace.h:64:27: error: asm/tracehook.h: No such file or directory
14:29<dgraves-#uml->>In file included from arch/um/kernel/exec.c:8:
14:29<dgraves-#uml->>include/linux/ptrace.h: In function ?ptrace_whole_regset?:
14:29<dgraves-#uml->>include/linux/ptrace.h:115: error: implicit declaration of function ?utrace_native_view?
14:29<dgraves-#uml->>include/linux/ptrace.h:116: warning: passing argument 3 of ?ptrace_regset_access? makes pointer from integer without a cast
14:29<dgraves-#uml->>include/linux/ptrace.h: In function ?ptrace_peekusr?:
14:29<dgraves-#uml->>include/linux/ptrace.h:164: warning: passing argument 3 of ?ptrace_layout_access? makes pointer from integer without a cast
14:29<jdike-#uml->>right
14:29<dgraves-#uml->>include/linux/ptrace.h: In function ?ptrace_pokeusr?:
14:29<dgraves-#uml->>include/linux/ptrace.h:175: warning: passing argument 3 of ?ptrace_layout_access? makes pointer from integer without a cast
14:29<dgraves-#uml->>arch/um/kernel/exec.c: In function ?execve1?:
14:29<dgraves-#uml->>arch/um/kernel/exec.c:53: error: ?struct task_struct? has no member named ?ptrace?
14:29<dgraves-#uml->>arch/um/kernel/exec.c:53: error: ?PT_DTRACE? undeclared (first use in this function)
14:29<dgraves-#uml->>arch/um/kernel/exec.c:53: error: (Each undeclared identifier is reported only once
14:29<dgraves-#uml->>arch/um/kernel/exec.c:53: error: for each function it appears in.)
14:29<dgraves-#uml->>make[1]: *** [arch/um/kernel/exec.o] Error 1
14:29<dgraves-#uml->>make: *** [arch/um/kernel] Error 2
14:29<dgraves-#uml->>err... that was more than i thought.
14:29[~]dgraves #uml apologizes for spamming. :)#uml-> apologizes for spamming. :)
14:30<dgraves-#uml->>jdike, i assume that sounds familiar?
14:34<jdike-#uml->>Try http://marc.info/?l=linux-kernel&m=117406663431023&q=raw
14:36<dgraves-#uml->>jdike, think that's apply on 2.6.18?
14:36<jdike-#uml->>dunno
14:36<dgraves-#uml->>or at least close? :)
14:36<jdike-#uml->>but that's what I have for utrace
14:40|-|tyler29 [~tyler@ARennes-257-1-110-16.w86-210.abo.wanadoo.fr] has joined #uml
14:42<dgraves-#uml->>k, thanks.
14:42[~]dgraves #uml gives it a shot.#uml-> gives it a shot.
14:42<dgraves-#uml->>in the meantime, i'm trying 2.6.23.9
14:51<dgraves-#uml->>jdike, looks like 2.6.23.9 is (so far) doing much better.
14:51<jdike-#uml->>it should
15:01<dgraves-#uml->>and did, even. :)
15:09<dgraves-#uml->>jdike, if the pthread field of the task_struct is no longer there (and it appears that that patch you gave me removes some references, I assume that uml will no longer use it?)
15:09[~]dgraves #uml hopes this holds true with 2.6.18, as well as the 2.6.21 that the patch is for.#uml-> hopes this holds true with 2.6.18, as well as the 2.6.21 that the patch is for.
15:09<jdike-#uml->>ptrace?
15:10<jdike-#uml->>I'd hope so, but you're also dealing with potentially an older utrace
15:10<jdike-#uml->>although I bet they backported it
15:10<dgraves-#uml->>::L::
15:11<dgraves-#uml->>well, process.c in your patch doesn't exist in the source tree.
15:11<dgraves-#uml->>instead i get process_kern.c
15:11<dgraves-#uml->>looks similar though.
15:11<jdike-#uml->>locate the functions and see how well the diffs apply
15:12|-|linbot [~supybot@ns.theshore.net] has quit [Ping timeout: 480 seconds]
15:13|-|linbot [~supybot@ns.theshore.net] has joined #uml
15:35<dgraves-#uml->>jdike, does this mean _u32 isn't defined:
15:36<dgraves-#uml->>include/linux/audit.h:276: error: expected specifier-qualifier-list before ?__u32?
15:39<dgraves-#uml->>nm. added a few more headers back your patch removed, and that seemed to fix it.
15:45<dgraves-#uml->>jdike, i'm choking on: arch/um/os-Linux/start_up.c:84: error: ?PAGE_SIZE? undeclared (first use in this function)
15:45<dgraves-#uml->>It appears that its defined in asm/page.h, which is included.
15:46<dgraves-#uml->>how does asm/page.h get translated to the uml specific header page.h?
15:55|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has quit [Quit: The only intuitive interface is the nipple; everything else is learned]
16:02<Magotari-#uml->>jdike: There is a tiny problem with the mconsole I discovered. http://rafb.net/p/HTg8kL87.html
16:03<jdike-#uml->>well, yeah
16:03<jdike-#uml->>that's not necessrily a bug
16:06<jdike-#uml->>PAGE_SIZE is one of the things that disappeared from libc
16:06|-|da-x [karrde@bzq-79-179-150-192.red.bezeqint.net] has joined #uml
16:06<jdike-#uml->>and I subsequently sent in patches to fix it
16:07<Magotari-#uml->>Yeah, true. What I would do is call it 'cat' and get rid of the /proc/ default directory though. However, reverse compatibility and all... Better leave it all as is. Back to testing my bugfix.
16:08<jdike-#uml->>I'm slightly surprised that works
16:08<jdike-#uml->>the original design was that it would work on an internal procfs mount
16:08<jdike-#uml->>so it couldn't be broken by the UML user unmounting /proc
16:08<jdike-#uml->>so in that case, there is no ..
16:09<jdike-#uml->>but that didn't work very well, so BB fixed it to work in the filesystem namespace
16:09<Magotari-#uml->>I think I saw some code commented or ifdefed out, something to make 'proc' work with hppfs.
16:09<Magotari-#uml->>Yeah, exactly.
16:10<Magotari-#uml->>It will be handy when I want to copy some files out of uml in a hurry.
16:32|-|tyler29 [~tyler@ARennes-257-1-110-16.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
16:34|-|mgross [~mgross@207.173.77.239] has joined #uml
16:36<dgraves-#uml->>jdike, is that the header untangling patch?
16:37<dgraves-#uml->>around the 16th?
16:41<jdike-#uml->>no
16:43<jdike-#uml->>it's commit 71f926f2ea61994470a53c9e11d3ef993197cada in mainline
16:44<dgraves-#uml->>jdike, i hate to profess ignorance here, but is that number reflected in the patchlog or something?
16:44<jdike-#uml->>patchlog?
16:45<dgraves-#uml->>yeah, the kernel patch file?
16:45<jdike-#uml->>and ee1eca5d2493026affbbc91b228dd00879484687
16:45<dgraves-#uml->>i guess i'm not sure how to look up a commit number.
16:45<jdike-#uml->>no
16:45<jdike-#uml->>you get a git repository of mainline
16:45<jdike-#uml->>and then do git show <commit>
16:45<jdike-#uml->>and you get the patch
16:46<dgraves-#uml->>okay. i'll give it a shot.
16:46[~]dgraves #uml heads off to set up a git repository.#uml-> heads off to set up a git repository.
16:46<jdike-#uml->>git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
16:47<dgraves-#uml->>do this often? :)
16:48<jdike-#uml->>hehe
16:51|-|tyler29 [~tyler@ARennes-257-1-110-16.w86-210.abo.wanadoo.fr] has joined #uml
16:53[~]dgraves #uml sighs. and git isn't even installed on our systems here.#uml-> sighs. and git isn't even installed on our systems here.
16:53[~]dgraves #uml installs git and finds rpm hell...#uml-> installs git and finds rpm hell...
17:05|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:11|-|tyler29 [~tyler@ARennes-257-1-110-16.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:15|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
17:24|-|tyler29 [~tyler@ARennes-257-1-122-59.w86-210.abo.wanadoo.fr] has joined #uml
17:34|-|tyler29 [~tyler@ARennes-257-1-122-59.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:36|-|Infinito [~argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has joined #uml
17:37|-|Infinito [~argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has quit [Read error: Connection reset by peer]
17:37|-|Infinito [~argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has joined #uml
17:38<Magotari-#uml->>I have been fighthing that problem for about 4 hours now. And I'm having the best fun I have had for the last few weeks.
17:38|-|Infinito [~argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has quit [Read error: Connection reset by peer]
17:38<Magotari-#uml->>Nearly fixed, and yet...
17:38<jdike-#uml->>hehe
17:40<Magotari-#uml->>Stops, resumes... Just fine. Even commands work while stopped. But when you do stack <foo> while stopped, it stops responding to mconsole. Which means you cannot resume it either.
17:40<Magotari-#uml->>So what have I introduced now... hmm... :)
17:40<Magotari-#uml->>Fun!
17:43|-|Infinito [argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has joined #uml
17:45|-|krau [~cktakahas@189.70.66.189] has joined #uml
17:51|-|Infinito [argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has quit [Read error: Connection reset by peer]
18:07|-|Infinito [argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has joined #uml
18:08|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection]
18:10|-|Baltam [~WIKIMOKI@cs-tor.bu.edu] has joined #uml
18:16|-|dang [~dang@nemesis.fprintf.net] has joined #uml
18:18<Magotari-#uml->>Oh happy days. It seems like 'stack' breaks even on kernels I did not touch. So the patch is pretty much ready to submit, once I do some checkpatch things.
18:18<Magotari-#uml->>UML does not have to be stopped. Doing 'stack 2' does the trick pretty well.
18:20<Magotari-#uml->>Yeah, pid 2 is a part of the kernel, right?
18:20<Magotari-#uml->> [kthreadd]
18:23<jdike-#uml->>yeah
18:23<jdike-#uml->>but it shouldn't matter
18:24<Magotari-#uml->>I just crashed a good UML with lots of stack <foo> requests.
18:25<Magotari-#uml->>By good I mean: I did not mess with it, and I for some reason labeled it: linux-production. Back when I wanted to have a virtual server.
18:25<jdike-#uml->>what's the, ummm, stack trace?
18:27<Magotari-#uml->>http://rafb.net/p/PNIk7l95.html
18:28<jdike-#uml->>arch_switch_tls failed, errno = EINVAL
18:28<jdike-#uml->>that would be the first thing to look at
18:44<Magotari-#uml->>I guess a wise thing would be to put off the stop bugfix till tomorrow, I need to make sure I am not causing the mess. Tis' but a single line, but alas... Of course I had to stop writing my testing program just before I added mconsole commands. Argh.
18:44|-|mgross [~mgross@207.173.77.239] has quit [Quit: Leaving]
18:44<Magotari-#uml->>I am too tired to keep on working on this. Five hours of sleep just ain't working.
18:44<Magotari-#uml->>Good night.
18:44<jdike-#uml->>night
18:45<jdike-#uml->>be back here bright and early in the morning
18:45[~]jdike #uml cracks the whiip#uml-> cracks the whiip
18:45<Magotari-#uml->>Heh.
18:45<Magotari-#uml->>No need. I come out of my own will. This is amazing fun.
18:45<Magotari-#uml->>Harder than nethack.
18:45<Magotari-#uml->>And I get to learn.
18:46<Magotari-#uml->>And help the community.
18:46<Magotari-#uml->>What not to like about it?
18:46|-|Magotari [~karol@89.66.106.109] has quit [Quit: leaving]
19:12|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
19:34|-|Infinito [argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
20:26|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
21:01|-|Infinito [argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has joined #uml
22:29|-|flatronf700B [~flatronf7@ns1.clipsalportal.com] has joined #uml
23:24|-|balbir [~balbir@59.145.136.1] has joined #uml
23:28|-|balbir [~balbir@59.145.136.1] has quit [Remote host closed the connection]
23:49|-|Infinito [argos@200-103-110-203.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
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 Thu Nov 29 00:00:38 2007