IRC logs for #openrisc Saturday, 2013-07-20

--- Log opened Sat Jul 20 00:00:34 2013
poke53281stekern: Made a small benchmark on qemu and or1ksim.00:39
poke53281QEMU is around 3.7 times faster in computation speed than or1ksim.00:39
poke53281Actually I expected more.00:45
poke53281Did the test with some check scripts for the bc calculator00:46
poke53281But I have here a reproducible effect. bc crashes on QEMU when I try to start it. On or1ksim no problem so far.  I use exactly the same image for both. If I start it with "bc -l" no problem in qemu.01:00
poke53281If I link it statically it works without problems in both emulators.01:00
poke53281Maybe it is worth looking after it.01:01
poke53281I mean to take a closer look01:03
poke53281Damn, it's a Heisenbug01:14
stekernthose are the worst :(04:44
stekernand this time the gcc suite hasn't crashed04:51
poke53281perfect, also finally the torture test for the varargs was 100% succesfull06:52
stekernnow it did crash06:56
stekernI need to find a better way to reproduce that06:56
poke53281qemu or or1ksim?06:58
stekernqemu06:58
stekernI'm not sure how I should move forward with the hw tlb reload neither06:59
poke53281well, I have here a repoducible effect with QEMU. Unfortunately it is gone when I write a lot of printf's in the source code.06:59
stekernto do it according to the spec, I would need to use the permission index register instead06:59
stekernof just using the PTE from the kernel07:00
stekernthe pte from the kernel set the exec bit in the lowest PPN bit in the pte defined by the spec07:02
poke53281Difficult to say for me. Have not analyzed that part from the spec. I found it confusing when I read it the first time before I saw that we use software-refill.07:04
poke53281So I would ignore the spec. :)07:05
stekernyeah, the mmu part of the spec is probably one of the worst parts07:05
stekernI'll at least do the 'proof-of-concept' with the linux pte first in mor1kx07:06
stekern(the problem with ignoring the spec is that then it's on your shoulders to update the spec and push the changes through ;))07:08
-!- Netsplit *.net <-> *.split quits: blueCmd08:30
-!- Netsplit *.net <-> *.split quits: blueCmd_08:54
-!- Netsplit *.net <-> *.split quits: Amadiro, heroux, blueCmd, LoneTech, olofk, jakob_, poke53281, trevorman, forkG, stekern, (+1 more, use /NETSPLIT to show all of them)09:06
-!- Netsplit over, joins: blueCmd, trevorman, heroux, poke53281, LoneTech, Amadiro, jakob_, stekern, forkG, enghong (+1 more)09:07
-!- Netsplit *.net <-> *.split quits: simoncook09:08
-!- Netsplit over, joins: simoncook09:10
-!- Netsplit *.net <-> *.split quits: hle__09:24
poke53281What is the result of the testsuite run?18:28
stekernpoke53281: hmm, which of the runs?19:29
poke53281the last gcc run19:49
stekernwith qemu? or the last with or1ksim? with 4.8.1 or 4.9.0?20:01
poke532814.8.1 would be nice. if possible with or1ksim. I don't trust qemu20:29
poke53281Just want to see what is failing right now. At the moment I am working on the crash of X. But it is like looking for a needle in a haystack. At least I am making progress in understanding X20:31
stekernpoke53281: http://lists.openrisc.net/pipermail/openrisc/2013-July/001788.html20:48
poke53281damn, it is in my mail folder21:27
poke53281and now I would like to have the list which files are failing.21:28
poke53281"grep FAIL gcc.sum" or something like that21:30
poke53281Just want to take a closer look :)21:37
stekernpoke53281: http://oompa.chokladfabriken.org/tmp/gcc.log21:46
stekernhttp://oompa.chokladfabriken.org/tmp/g++.log21:46
poke53281thanks21:48
stekernI put the .sum there too, the .log are pretty big21:48
poke53281Ok, the sum is the only one I need21:48
--- Log closed Sun Jul 21 00:00:36 2013

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!