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

---Logopened Thu Dec 13 00:00:27 2007
01:14|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
01:38|-|rjbell4 [bbell@c-75-67-251-249.hsd1.nh.comcast.net] has quit [Remote host closed the connection]
01:38|-|rjbell4 [bbell@c-75-67-251-249.hsd1.nh.comcast.net] has joined #uml
01:53|-|besonen_mobile__ [~besonen_m@71-220-198-145.eugn.qwest.net] has joined #uml
01:54|-|besonen_mobile_ [~besonen_m@71-220-198-145.eugn.qwest.net] has quit [Read error: Connection reset by peer]
02:01|-|balbir [~balbir@59.145.136.1] has joined #uml
02:43|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has joined #uml
02:51|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has quit [Quit: ChatZilla 0.9.79 [Firefox 2.0.0.8/2007100400]]
03:16|-|namit [~test_acco@83-70-39-95.b-ras1.prp.dublin.eircom.net] has joined #uml
03:20|-|Micksa [~mslade@203.55.194.112] has quit [Ping timeout: 480 seconds]
03:21|-|cl4sh [~cl4sh@qik.ds.pg.gda.pl] has joined #uml
03:21<cl4sh-#uml->>hi all
03:29|-|Micksa [~mslade@203.55.194.112] has joined #uml
03:49|-|namit [~test_acco@83-70-39-95.b-ras1.prp.dublin.eircom.net] has quit [Read error: Connection reset by peer]
05:02<cl4sh-#uml->>could somebody can tell what is uml_watchdog?
05:02<cl4sh-#uml->>Magotari: are You on-line :P?
06:20|-|balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds]
06:30<Magotari-#uml->>cl4sh: Yeah.
06:31<Magotari-#uml->>I think the watchdog does something with rebooting dead umls.
06:55|-|Infinito [argos@201-11-172-121.gnace701.dsl.brasiltelecom.net.br] has joined #uml
07:37<Magotari-#uml->>Eh. Introduced a bug to -mm. Great. Just great. Excellent. Superb.
07:38<Magotari-#uml->>Gonna take care of it when I get bakc.
08:00|-|da-x [~karrde@xiv-glob.ser.netvision.net.il] has joined #uml
08:40|-|dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.]
08:59<cl4sh-#uml->>im back
08:59<cl4sh-#uml->>Magotari: thx for response
09:09|-|Infinito [argos@201-11-172-121.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
09:20<Magotari-#uml->>Back too. Great time to fix a regression.
09:20|-|balbir [~balbir@122.167.182.219] has joined #uml
09:21|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
10:23|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
11:03|-|Infinito [argos@201-11-172-121.gnace701.dsl.brasiltelecom.net.br] has joined #uml
11:06|-|jdike [~jdike@pool-72-93-105-51.bstnma.fios.verizon.net] has joined #uml
11:06<jdike-#uml->>Hi guys
11:08|-|peterz [~peterz@f237116.upc-f.chello.nl] has joined #uml
11:09<Magotari-#uml->>Hey, jdike. You will slaughter me for this, but I think I introduced a bug with one of my mconsole patches. I am testing a fix for it now...
11:09<peterz-#uml->>jdike: do you happen to have a 2.6.24-rc4-mm1 fixup?
11:09<jdike-#uml->>yup
11:09<cl4sh-#uml->>hi
11:09<jdike-#uml->>but rc5-mm1 builds out of the box
11:09<peterz-#uml->>oh, dang, I missed that one by minutes
11:09[~]peterz #uml goes fetch rc5-mm1#uml-> goes fetch rc5-mm1
11:10<jdike-#uml->>Magotari, what was the problem?
11:11<Magotari-#uml->>Oh nothing. If you enable some debug options in the kernel hacking menu UML will stop booting, until you send an mconsole command, any command. This is caused by the fd starting as blocking, which is not desirable.
11:11<Magotari-#uml->>Just a tiny thing like making uml unbootable. And six hours of debugging did not catch it. Groan.
11:11<jdike-#uml->>DEBUG_SHIRQ?
11:12<Magotari-#uml->>Maybe, not sure.
11:12<Magotari-#uml->>I think so.
11:12<jdike-#uml->>or whatever the shared IRQ testing thing is
11:12<Magotari-#uml->>I know that was one of the options, yes.
11:12<jdike-#uml->>none of your patches changed O_NONBLOCK
11:12<Magotari-#uml->>However, after seeing what is happening in gdb I did not even bother to look which option is a problem.
11:12<jdike-#uml->>your MSG_BLAH patch would have done that
11:12<Magotari-#uml->>It was waiting for an mconsole request.
11:12<Magotari-#uml->>Yeah, precisely that patch.
11:13<jdike-#uml->>but that was just exposing an existing bug
11:13<jdike-#uml->>not creating a new one
11:13<Magotari-#uml->>*relief*
11:13<Magotari-#uml->>Well, I have a patch in the works for it then.
11:13<jdike-#uml->>oK
11:13<Magotari-#uml->>There is one more matter, namely entering a log message into uml causes two 'OK's to appear.
11:14<Magotari-#uml->>I am looking into it too.
11:34|-|ftumch [~James@james.1ec.aaisp.net.uk] has quit [Quit: Goodbye.]
11:44|-|newbi1 [~jeff@ita4fw1.itasoftware.com] has joined #uml
11:49|-|newbi1 [~jeff@ita4fw1.itasoftware.com] has quit []
11:49|-|newbie [~jeff@ita4fw1.itasoftware.com] has quit [Quit: Leaving.]
11:49|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
11:53|-|ram [~ram@pool-96-225-204-220.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
11:54|-|newbie [~jeff@ita4fw1.itasoftware.com] has left #uml []
11:55|-|newbie [~jeff@ita4fw1.itasoftware.com] has joined #uml
11:57|-|newbie [~jeff@ita4fw1.itasoftware.com] has left #uml []
12:15|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
12:31<Magotari-#uml->>jdike: arch/um/kernel/built-in.o:(.data+0x0): undefined reference to `__func__.9169'
12:31<Magotari-#uml->>This is rc5-mm1
12:32<Magotari-#uml->>I got LOTS of those.
12:32<jdike-#uml->>beats the crap out of me
12:32<jdike-#uml->>never seen that
12:32<Magotari-#uml->>I did some stuff to the config, but... Retrying with defconfig...
12:40<Magotari-#uml->>Defconfig is ok, trying to narrow the problem down...
12:41<jdike-#uml->>interesting
12:42<jdike-#uml->>did you enable CONFIG_GMON or CONFIG_GPROF?
12:42<Magotari-#uml->>I think both. I have saved the bad config, so let me see...
12:43<Magotari-#uml->># CONFIG_GPROF is not set
12:43<Magotari-#uml->>GMON? Do you mean GCOV? Not enabled either.
12:44<Magotari-#uml->>No GMON is my config.
12:44<Magotari-#uml->>No such symbol, I mean.
12:47|-|tyler29 [~tyler@ARennes-257-1-131-84.w86-210.abo.wanadoo.fr] has joined #uml
12:47|-|cl4sh [~cl4sh@qik.ds.pg.gda.pl] has quit [Quit: leaving]
12:50<Magotari-#uml->>Down to five possible symbols...
12:56<jdike-#uml->>GCOV, right
13:06<Magotari-#uml->>jdike: Got it. Symbol: PROFILE_LIKELY [=y]
13:06<jdike-#uml->>hmmph
13:06<jdike-#uml->>no idea what gcc does there
13:07<Magotari-#uml->>Trying defconfig with that symbol now, maybe something else in my config causes a fuss.
13:13<Magotari-#uml->>Defconfig failed with PROFILE_LIKELY.
13:13<Magotari-#uml->>Now I can go back to work on patches.
13:18|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
13:18|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
13:19<Magotari-#uml->>jdike: And telling UML to print timestamps with kernel messages is strange. The numbers are huge.
13:20<Magotari-#uml->>I found that one with 23.9, did not test on rc5-mm1 yet.
13:20|-|tyler29 [~tyler@ARennes-257-1-131-84.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:28<Magotari-#uml->>[42949375.800000] Kernel panic - not syncing: Kernel mode fault at addr 0x0, ip 0x8059fc3
13:29<Magotari-#uml->>That was bootup.
13:29<Magotari-#uml->>Without any new patches from me.
13:30<Magotari-#uml->>Got two backtraces, both valid but not informative.
13:31<jdike-#uml->>do you have core files
13:31<Magotari-#uml->>No, I don't. Even my host kernel does not have support.
13:31<jdike-#uml->>hmm
13:31<jdike-#uml->>they are handy
13:32<Magotari-#uml->>Jeff, three months ago I thought I should go back into photography, not go help write a virtual machine.
13:32<Magotari-#uml->>So my system is set up not for developement.
13:32<jdike-#uml->>hehe
13:33<Magotari-#uml->>I give up too easily. That automatic test program is nearly done and would help so much... I just can't get to finish it.
13:33<jdike-#uml->>but photographers don't typically fiddle their kernel configs
13:33<Magotari-#uml->>Heh. True. :)
13:34<Magotari-#uml->>Ok, I will put the core dumps into my host. Next reboot I will have support.
13:36|-|tyler29 [~tyler@ARennes-257-1-164-209.w86-214.abo.wanadoo.fr] has joined #uml
13:39<Magotari-#uml->>Kernel updated. Next reboot I have core dumps.
13:54<Magotari-#uml->>jdike: From gdb: (gdb) bt
13:54<Magotari-#uml->>#0 0x08066709 in page_ok (page=0) at arch/um/os-Linux/sys-i386/task_size.c:31
13:54<Magotari-#uml->>#1 0x08066804 in os_get_task_size (shift=22) at arch/um/os-Linux/sys-i386/task_size.c:86
13:55<Magotari-#uml->>This is very close to defconfig.
13:55<jdike-#uml->>hmm
13:55<jdike-#uml->>new code and it's crapping out already
13:56<Magotari-#uml->>I could not find the memsplit option, so I imagine it was merged in this mm.
13:56<Magotari-#uml->>If it was not merged, I am causing noise about nothing.
14:08<jdike-#uml->>it was
14:08<jdike-#uml->>how is it dying?
14:10<Magotari-#uml->>Locating the top of the address space ...
14:10<Magotari-#uml->>Program received signal SIGSEGV, Segmentation fault.
14:11<Magotari-#uml->>Then it does it a lot...
14:11<Magotari-#uml->>And ... start_uml - start_userspace returned -22
14:12<Magotari-#uml->>It also printed this: 0xb0000000
14:13<Magotari-#uml->>It is the right memsplit, so I don't know what is the problem.
14:14<Magotari-#uml->>Without gdb I get different problems.
14:14<Magotari-#uml->>Dies later.
14:16<Magotari-#uml->>I hope you don't mind some patches coming from rc5 without -mm, that is what runs out of the box last time I checked.
14:19<Magotari-#uml->>This is not my day.
14:19<Magotari-#uml->>(stoptest) go
14:19<Magotari-#uml->>ERR Already stopped
14:19<Magotari-#uml->>(stoptest)
14:19<Magotari-#uml->>And it resumed, having said that.
14:45<peterz-#uml->>In file included from include2/asm/termios.h:5,
14:45<peterz-#uml->> from /mnt/md0/src/linux-2.6/include/linux/termios.h:6,
14:45<peterz-#uml->> from /mnt/md0/src/linux-2.6/drivers/char/tty_ioctl.c:13:
14:45<peterz-#uml->>include/asm/arch/termios.h: In function ‘user_termio_to_kernel_termios’:
14:45<peterz-#uml->>include/asm/arch/termios.h:66: error: ‘FIXADDR_USER_START’ undeclared (first use in this function)
14:46<peterz-#uml->>rc5-mm1
14:46[~]peterz #uml looks#uml-> looks
14:50<jdike-#uml->>I've seen that before
14:51<jdike-#uml->>hmm
14:51<jdike-#uml->>peterz, build a .i and see where the FIXADDR_USER_START is coming from?
14:52<jdike-#uml->>Magotari, is this under gdb?
14:52<jdike-#uml->>if so, tell gdb handle SIGSEGV pass nostop noprint
14:53<peterz-#uml->>Ooh, nice feature
14:53<peterz-#uml->>I always do V=1,copy paste the line, and modify to -E
14:54<Magotari-#uml->>jdike: I just 'c'ontinued past all sigsegvs, till it dies with 'userspace returned -22'.
14:54<jdike-#uml->>peterz, yeah I used to do that to
14:54<jdike-#uml->>then I discovered make foo.i worked
14:55<jdike-#uml->>Magotari, yeah that happens when gdb-ing UML on a skas3 kernel, and I have no idea why
15:00<peterz-#uml->>jdike: access_ok()
15:00<peterz-#uml->>__access_ok_vsyscall in specific
15:01<jdike-#uml->>peterz, can you include <asm/processor.h> in arch/um/include/um_uaccess.h?
15:01[~]peterz #uml does as told#uml-> does as told
15:01<jdike-#uml->>without creating any include loops
15:02<caker-#uml->>Magotari: have you got a skas3 host set up?
15:02<peterz-#uml->>jdike: doesn't seem to help
15:03<jdike-#uml->>really?
15:03<jdike-#uml->>whoops
15:03<Magotari-#uml->>caker: Yup. 2.6.23. It's delicious.
15:03<jdike-#uml->>I was focussed on TASK_SIZE
15:03<peterz-#uml->>:-)
15:03<caker-#uml->>Magotari: mind trying to boot UML with mem > 1500M ?
15:03<jdike-#uml->>get rid of processor.h and add asm/fixmap.h instead
15:03<Magotari-#uml->>Erm, that would fill my memory.
15:03<jdike-#uml->>Magotari, no it won't
15:03<Magotari-#uml->>I have but a gig, and two of swap.
15:04<jdike-#uml->>memory will be allocated as needed
15:04<Magotari-#uml->>Yeah, but I have a directory mounted only for max 900 megs.
15:04<jdike-#uml->>not all at once up front
15:04<peterz-#uml->>jdike: works
15:04<Magotari-#uml->>Right. I will do that then.
15:04[~]peterz #uml builds a full tree#uml-> builds a full tree
15:04<Magotari-#uml->>Let me remount stuff... Give me a minute.
15:04<jdike-#uml->>peterz, OK I'll spin a patch
15:06|-|kos_tom [~thomas@humanoidz.org] has joined #uml
15:07<Magotari-#uml->>caker: It crashed. Maybe I am doing something wrong. Trying with less memory worked.
15:07<peterz-#uml->>jdike: fully builds now
15:07<jdike-#uml->>peterz, good
15:07<jdike-#uml->>Magotari, crashed how?
15:07<caker-#uml->>Magotari: crashed and not just spun at init?
15:08<Magotari-#uml->>No, a segmentation fault without any information.
15:08<Magotari-#uml->>Let me give you the message.
15:09<Magotari-#uml->>Oh, yes. I AM doing something wrong.
15:09<jdike-#uml->>you did mem=1500
15:11<Magotari-#uml->>No.
15:11<Magotari-#uml->>I remounted badly.
15:11<Magotari-#uml->>size=900M,size=2000M
15:11<Magotari-#uml->>The 900 came from fstab.
15:13<Magotari-#uml->>No, keeps on dying...
15:13<Magotari-#uml->>Even after a correct remount.
15:13<Magotari-#uml->>It does die when I exceed 900M by a bit though.
15:14<Magotari-#uml->>UML running in SKAS3 mode
15:14<Magotari-#uml->>Segmentation fault
15:16<Magotari-#uml->>910M boots, 920M fails. I have 2GB free on /dev/shm.
15:16<jdike-#uml->>is that all the output
15:16<Magotari-#uml->>Yes.
15:16<Magotari-#uml->>Skas0 fails in the same way.
15:17<Magotari-#uml->>This is a 23.9 kernel.
15:18<jdike-#uml->>gdb it?
15:18<Magotari-#uml->>And I don't have any patches in it, except the useless mconsole kill.
15:18<Magotari-#uml->>Right, I'm on it.
15:19<Magotari-#uml->>(gdb) bt
15:19<Magotari-#uml->>#0 0x42247fff in ?? ()
15:20<Magotari-#uml->>Yeah. Ouch.
15:20<Magotari-#uml->>#5 0x0806485e in os_map_memory (virt=Cannot access memory at address 0x7c0
15:20<Magotari-#uml->>Everything above it is ??
15:20<Magotari-#uml->>And then I get this gem: Backtrace stopped: previous frame inner to this frame (corrupt stack?)
15:21<jdike-#uml->>wow
15:22<jdike-#uml->>stack corruption
15:22<Magotari-#uml->>I have stumbled into so many bugs today that I am afraid to eat. I might overflow a counter in salt.c and cause a world crash.
15:22<Magotari-#uml->>Yeah, stack corruption it is.
15:24<jdike-#uml->>what I would do is step through it until your stack disappears
15:24<Magotari-#uml->>Btw, if you want I can give you an account on this machine. Might help debugging a bit, I'm not so good at the whole 'developement' and 'programming' yet.
15:24<Magotari-#uml->>Yeah, I shall do that then.
15:24<jdike-#uml->>you can sort of bisect it by stepping over function calls at first
15:25<jdike-#uml->>and then stepping through the one where it dies
15:25<jdike-#uml->>work your way down the stack
15:25<Magotari-#uml->>Yeah, I already thought of it, but thanks a lot. Good to get help when you need it.
15:38|-|Infinito [argos@201-11-172-121.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
15:41<Magotari-#uml->>Something called from setup_physmem...
15:43<Magotari-#uml->>Erm, no. Wrong.
15:46<Magotari-#uml->>Yeah, from setup_physmem.
15:47<Magotari-#uml->>In fact, the guilty party is os_map_memory. Now what inside it causes the problem...
15:49<Magotari-#uml->>(gdb) step
15:49<Magotari-#uml->>Program received signal SIGSEGV, Segmentation fault.
15:49<Magotari-#uml->>Erm. Shouldn't it display a line which crashed?
15:49<Magotari-#uml->>Indeed at that point the stack went *poof* as well.
15:50<Magotari-#uml->>The line from the step before the crash was
15:50<Magotari-#uml->>166 loc = mmap64((void *) virt, len, prot, MAP_SHARED | MAP_FIXED,
15:50<Magotari-#uml->>Then I did step, and *boom*
15:50<jdike-#uml->>OK, what were all the arguments to that?
15:51<Magotari-#uml->>(gdb) bt
15:51<Magotari-#uml->>#0 os_map_memory (virt=0x8800000, fd=6, off=8093696, len=1564770304, r=1, w=1, x=0) at arch/um/os-Linux/process.c:166
15:51<jdike-#uml->>to the mmap
15:51<jdike-#uml->>OK, I guess they're pretty much the same as what was passed in
15:51<Magotari-#uml->>I don't have a time machine, so let me return the code till it explodes again.
15:52<jdike-#uml->>stop on the mmap
15:52<Magotari-#uml->>Just so you know, mmap thingy happens a few times before it crashes. So the first arguments won't be the ones which do fatal damage.
15:53<jdike-#uml->>presumably the crash happens when len==$BIGNUM
15:56<Magotari-#uml->>Ok, I have it stopped at the first mmap64..
15:56<jdike-#uml->>what are the arguments
15:56<Magotari-#uml->>I did 'br mmap64' and it stopped here.
15:57<Magotari-#uml->>Ok, sec.
15:57<jdike-#uml->>is it going to crash on this one?
15:57<Magotari-#uml->>No, not on this one. It takes two more or so. Do you want 'info args', or something else?
15:57<jdike-#uml->>go to the one where it crashes
15:59<Magotari-#uml->>Argh. Wrong wrong wrong.
15:59<Magotari-#uml->>The first one crashes.
15:59<Magotari-#uml->>If only I were more organized. Had a different breakpoint left in, and I did not read it.
15:59<Magotari-#uml->>OK, I am at the mmap now.
16:02<Magotari-#uml->>Single stepping until exit from function mmap64,
16:02<Magotari-#uml->>which has no line number information.
16:02<Magotari-#uml->>Eh. Yeah. I hate my old Gentoo life sometimes.
16:13<jdike-#uml->>actually just look at the arguments
16:13<jdike-#uml->>it must be mapping over something important
16:13<jdike-#uml->>like the stack
16:21<Magotari-#uml->>virt 0x8800000 len 1564770304 fd 7 off 8093696
16:21<Magotari-#uml->>I think I am doing something seriously wrong though.
16:22<Magotari-#uml->>It looks like a loop. But in the code there is none.
16:23<Magotari-#uml->>It keeps going between lines 163 and 166 for a while, just before it crashes. There ain't a loop there.
16:23<Magotari-#uml->>Also it tells me that prot is not in current context or something.
16:24<jdike-#uml->>where's your stack?
16:27<Magotari-#uml->>How do I find that out? info stack was same as a backtrace.
16:27<jdike-#uml->>p $esp
16:28<Magotari-#uml->>$23 = (void *) 0xaf8de200
16:29<jdike-#uml->>OK
16:29<jdike-#uml->>what's 0x8800000+1564770304?
16:31<Magotari-#uml->>af8de200
16:31<Magotari-#uml->>22:27 < jdike> OK
16:31<Magotari-#uml->>Shit.
16:31<Magotari-#uml->>1707376640, according to python.
16:31<jdike-#uml->>in hex?
16:31<Magotari-#uml->>Damn mouse. Nearly dead now. Went crazy again.
16:33<Magotari-#uml->>>>> print hex(a)
16:33<Magotari-#uml->>0x65c48000
16:33<caker-#uml->>google calc says 0x8800000 + 1564770304 = 0x65C48000
16:33<jdike-#uml->>that's not far enough
16:34<Magotari-#uml->>Let me guess, my damn memsplit sucks again?
16:34<jdike-#uml->>no
16:35<jdike-#uml->>your stack is at 0xb0000000
16:35<jdike-#uml->>this mmap is mapping from 0x8800000 to 0x65C48000 which is fine
16:35<jdike-#uml->>I thought it was overmapping your stack
16:35<jdike-#uml->>which is how you'd see stack corruption from an mmap
16:36<Magotari-#uml->>So it is my fault then, because that function does not have a loop, but acts like it has one.
16:37<jdike-#uml->>forget gdb for now
16:37<jdike-#uml->>and just strace it
16:41<Magotari-#uml->>mmap2(0x8800000, 1564770304, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0x7b8) = 0x8800000
16:41<Magotari-#uml->>--- SIGSEGV (Segmentation fault) @ 0 (0) ---
16:43<jdike-#uml->>paste the whole thing somewhere
16:52<Magotari-#uml->>http://rafb.net/p/3Jli7W12.html
16:52<Magotari-#uml->>jdike: ^
16:55<jdike-#uml->>back to gdb
16:55<jdike-#uml->>before you call that mmap, is the stack still sane?
16:56<Magotari-#uml->>Yeah, but let me doublecheck.
16:58<Magotari-#uml->>Ah. Phone. Gonna be off for an hour or so. Need to call two doctors.
17:07|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:16|-|Infinito [argos@200-103-111-159.gnace701.dsl.brasiltelecom.net.br] has joined #uml
17:25<Magotari-#uml->>jdike: Yeah, the stack is sane till I do one last step.
17:26<Magotari-#uml->>But really, something is seriously strange, the function has no loops, but acts if it has one.
17:26<Magotari-#uml->>I may be a broken record here, but I think I am at fault.
17:26<jdike-#uml->>I would just stop as soon as something goes wrong
17:27<jdike-#uml->>hands off the keyboard, no more stepping, don't worry about whatever wierd things happen next
17:27<jdike-#uml->>when do you see the looping behavior
17:28<jdike-#uml->>before the SIGSEGV, I guess?
17:28<Magotari-#uml->>Yes, a few steps before.
17:28<jdike-#uml->>Oh, OK
17:28<jdike-#uml->>nevermind
17:29<jdike-#uml->>Oh, I think I understand
17:29<jdike-#uml->>you're being confused by gcc's instruction scheduling
17:29<jdike-#uml->>gcc is mixing together the instructions from two lines of code
17:30<jdike-#uml->>gdb knows which line is associated with each instruction
17:30<Magotari-#uml->>*groan*
17:30<jdike-#uml->>so you appear to be bouncing between lines
17:30<Magotari-#uml->>-O0 forever.
17:30<Magotari-#uml->>I wish I could compile the kernel like that.
17:30<Magotari-#uml->>Yeah, it makes sense.
17:32<Magotari-#uml->>More phone calls.
17:46|-|karrde_ [karrde@bzq-79-176-10-229.red.bezeqint.net] has joined #uml
17:47|-|tyler29 [~tyler@ARennes-257-1-164-209.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:48|-|karrde_ [karrde@bzq-79-176-10-229.red.bezeqint.net] has quit [Remote host closed the connection]
17:50|-|kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps]
18:04<Magotari-#uml->>jdike: Ok, ready for action again.
18:06<jdike-#uml->>want to fire up gdbbot on the problem?
18:13<Magotari-#uml->>Hmm, I can try.
18:15<Magotari-#uml->>Eh. Not in Gentoo, it seems.
18:15<jdike-#uml->>do you have gdbbot.pl?
18:15<Magotari-#uml->>Oh. Just a script? I thought a bigger program. Ok, I will google it.
18:16<Magotari-#uml->>Thu Jul 5 19:18:58 2001 UTC (6 years, 5 months ago) by jdike
18:16<jdike-#uml->>hehe
18:16<Magotari-#uml->>Erm, is that the one, or something more recent?
18:16<jdike-#uml->>you'll need to change the IRC server in it
18:16<jdike-#uml->>but it should be fine
18:18|-|namit [~test_acco@83-70-39-95.b-ras1.prp.dublin.eircom.net] has joined #uml
18:19<Magotari-#uml->>Yeah, I read the code and it does not have any naughy 'rm -fr' or any of hir's friends.
18:21<Magotari-#uml->>Can't locate IO/Pty.pm in @INC (
18:21<jdike-#uml->>get it from cpan
18:27<Magotari-#uml->>Yup.
18:29<Magotari-#uml->>And one more module...
18:31<Magotari-#uml->>jdike: It works.
18:31<Magotari-#uml->>#umldebug
19:03|-|karol [~karol@chello089076073248.chello.pl] has joined #uml
19:29|-|Micksa [~mslade@203.55.194.112] has quit [Ping timeout: 480 seconds]
19:49|-|Micksa [~mslade@203.55.194.182] has joined #uml
20:51<Magotari-#uml->>Blah. Four days in a row not going to school but staying home and doing open source.
20:52<Magotari-#uml->>What a great week. Once I drop out I will take some cash register job and do this by night.
20:52|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
20:54|-|Infinito [argos@200-103-111-159.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
20:55<Magotari-#uml->>And a patch should be ready in about an hour... Finally.
20:55<caker-#uml->>how'd the debugging sesion go?
20:56<Magotari-#uml->>We figured it out. Well, Jeff did.
20:56<Magotari-#uml->>Mmapping over libraries.
20:56<Magotari-#uml->>I will build a static kernel to workaround this.
20:58<caker-#uml->>http://www.linode.com/~caker/uml/kernels/2.6.23.1-linode36 <-- static, spins on init with mem=1500M
20:58<caker-#uml->>sounds like that's a different issue
21:00<Magotari-#uml->>Downloading binaries scares me.
21:01<Magotari-#uml->>Compiling my own.
21:01<caker-#uml->>don't you trust me? :>
21:03<Magotari-#uml->>I do, but I am a firm believer in just-in-caseism. If I cannot reproduce on my own, then I will get your kernel and give it a spin.
21:04<Magotari-#uml->>Kernel virtual memory size shrunk to 1240465408 bytes
21:05<Magotari-#uml->>:(
21:05<Magotari-#uml->>I want lots of fake ram!
21:05<Magotari-#uml->>It did boot and free is happy-happy.
21:05<Magotari-#uml->>Time for your kernel. Maybe in a different account...
21:08<Magotari-#uml->>Spins.
21:11<Magotari-#uml->>Mconsole halt is not enough for it even.
21:11<caker-#uml->>nope
21:11<caker-#uml->>gotta kill off each process
21:12<Magotari-#uml->>So whatever the problem is, must be your code.
21:12<Magotari-#uml->>I could try to debug but I'm pretty useless and the file is stripped.
21:13<caker-#uml->>hehe, one more quick test? http://www.linode.com/~caker/uml/kernels/2.6.22.6-linode34
21:13<caker-#uml->>I have the un-stripped version of that one
21:13<Magotari-#uml->>Sure. Sec.
21:15<Magotari-#uml->>Spins.
21:15<caker-#uml->>http://www.linode.com/~caker/uml/kernels/2.6.22.6-linode34-unstripped.tar.gz (fwiw)
21:16<caker-#uml->>may be something in my config
21:16<caker-#uml->>otherwise, those are stock kernels with the exception of my token-limiter patch
21:18<Magotari-#uml->>Hmm...
21:19<Magotari-#uml->>Now I got 23 booting, but not quite. I guess you don't have xterm in your config, right? No surprise.
21:19<Magotari-#uml->>22 does always spin though.
21:19<Magotari-#uml->>All the times I tried anyway.
21:21<Magotari-#uml->>Different rootfs, spin on init in 23.
21:22<Magotari-#uml->>But 22 booted fine.
21:22<Magotari-#uml->>The problem is not persistant here. Happens once in a while.
21:22<Magotari-#uml->>About half the time.
21:23<Magotari-#uml->>Gonna get the ustripped version and play with that.
21:31<Magotari-#uml->>My kernels seem to work with the same commandline that spin your kernels. gdb time, but I would be astonished if I tell you something you don't know.
21:37<Magotari-#uml->>#1 0x08079ef8 in os_unmap_memory (addr=0x0, len=0) at arch/um/os-Linux/process.c:187
21:37<Magotari-#uml->>I think this may be a problem.
21:45<Magotari-#uml->>Strace shows it mmapping and unmapping memory a lot, but the calls are successful.
21:46<Magotari-#uml->>But I'm sure you knew that, right? All I can say that might be new is that this is a thing which happens sometimes.
21:58<Magotari-#uml->>map_memory (virt=1711280128, phys=6492160, len=4096, r=1, w=1, x=-1347420160)
21:58<Magotari-#uml->>x looks funny.
22:01<caker-#uml->>hmm
22:04<Magotari-#uml->>Maybe try a new compiler? But really, the funny part being, I am looking at the source code to 23.9...
22:04<Magotari-#uml->>And whatever went into map_memory should go to os_map_memory.
22:04<Magotari-#uml->>But gdb tells me that x was 1 in os_map_memory.
22:06<Magotari-#uml->>Actually no.
22:06<Magotari-#uml->>It never does the call to os_map_memory, which is insane because the damn function is on rails without any ifs at that point.
22:07<Magotari-#uml->>Oh hell. I just need a gdb manual.
22:07<Magotari-#uml->>Anyway, strange stuff happening around the x thingy.
22:07<Magotari-#uml->>So I'm thinking compiler.
22:08<Magotari-#uml->>I can send you one of my kernels to try.
22:08<caker-#uml->>sure
22:10<Magotari-#uml->>Let me set up a server. It's gonna be a nearly defconfig server, so beware.
22:10<Magotari-#uml->>Er, kernel.
22:10<Magotari-#uml->>Sorry, 4:09am.
22:11<caker-#uml->>yikes -- go to sleep
22:12|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
22:19<Magotari-#uml->>http://89.76.73.248:8008/linux-strange
22:19<Magotari-#uml->>caker: ^
22:19<Magotari-#uml->>I had to make it -x, otherwise the server would execute it instead of starting a download.
22:21[~]caker #uml downloads#uml-> downloads
22:21<Magotari-#uml->>I like the server though, pretty handy and small and yet has CGI. But most importantly it won the IOCCC a while back...
22:24<Magotari-#uml->>And in case you are wondering about my upload, this is my home computer.
22:24<Magotari-#uml->>So that explains the l33t sp33d.
22:24<caker-#uml->>hehe
22:27<caker-#uml->>pfft.. boots fine with yours
22:27<Magotari-#uml->>I can do some compiling for you, if you want.
22:28<caker-#uml->>thanks ok, but thanks .. and thanks for looking into this
22:29<Magotari-#uml->>Sure. So I guess I can go to sleep.
22:29<Magotari-#uml->>Try a new compiler, might help. The x felt fishy.
22:29<Magotari-#uml->>I better not try to code this late in the night... Oh well. Patches can wait till tomorrow.
22:30<Magotari-#uml->>Goodnight.
23:58|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
---Logclosed Fri Dec 14 00:00:50 2007