| --- Log opened Thu Jul 24 00:00:33 2014 | ||
| stekern | does anyone have any comments on this? http://lkml.iu.edu//hypermail/linux/kernel/1407.2/06326.html | 07:29 |
|---|---|---|
| markus_wanner | I think it depends a lot on what a website wants to be. I'm still looking for some kind of directory, i.e. something with the rating and status indication that opencores provided. But without the requirement that these be hosted in a certain place. | 07:55 |
| olofk | stekern: Don't like the idea of a ROM because we need to reserve some address space then. But how about an SPR? | 08:02 |
| olofk | markus_wanner: You have a point here. Even though the OpenCores rating and status indication is messy, at least it gave an indication if a core had been silicon proven | 08:04 |
| olofk | stekern: Working it out in the illegal instruction handler might be a good idea too. Is that doable? | 08:05 |
| olofk | And do we do something similar for missing class II instructions? Like mul and div? | 08:06 |
| stekern | olofk: yeah, the 'finding out' part is trivial... it was comments what to do when you know it's not supported I was looking for | 08:07 |
| stekern | I understand from Alan's comment that he suggest we'd do something like this: http://lxr.free-electrons.com/source/arch/x86/kernel/alternative.c | 08:09 |
| stekern | which AFAICT ends up in self-modyfing the code that use the unsupported instruction | 08:11 |
| stekern | I'm just not sure if that's really doable in our case, it's not like the alternate implementation is trivially alike | 08:12 |
| stekern | not familiar enough with what that alternate code does yet to really tell, but one thing it seems to do is to remove the lock prefix from e.g. cmpxchg in the UP case. | 08:14 |
| stekern | which is of course a trivial change to 'patch in' to the current instruction mem. | 08:15 |
| stekern | this whole thing can of course be solved by just adding emulation of the l.lwa/l.swa instructions in the kernel (something I anyway intend to do) | 08:16 |
| stekern | but I'm pretty sure that that's many orders of magnitude less efficient than the kernels generic UP implementations of atomic operations. | 08:17 |
| olofk | UP = Unicorn Processor? | 08:53 |
| blueCmd | \o/ | 09:05 |
| stekern | Unicorn Pålle | 09:13 |
| olofk | :) | 09:48 |
| olofk | hmmm... vga_lcd doesn't do bursts? | 10:23 |
| olofk | = really shitty bus utilization? | 10:24 |
| stekern | does to | 10:24 |
| olofk | ah sorry | 10:25 |
| stekern | o | 10:25 |
| olofk | I looked at the slave port | 10:25 |
| stekern | but only up to 8 words | 10:26 |
| stekern | easy to hack it to do longer ones though | 10:26 |
| stekern | I've planned on doing that for the sockit board | 10:26 |
| stekern | since I have a dedicated port into the mem controller, it could just continously burst data out of it for the whole frame | 10:27 |
| olofk | I think that 8 words is enough as long as you don't use higher resolutions than 4x2 pixels | 10:28 |
| olofk | Whole frame bursts might be mean to architectures that don't have dedicated ports and has to share the bus with something else | 10:29 |
| stekern | yes | 10:29 |
| olofk | If there wasn't already a master port on vga_lcd, this would be a perfect thing for my wb_streamer thingie | 10:30 |
| olofk | ...I think | 10:30 |
| olofk | ...without having thought very long | 10:31 |
| olofk | stekern: How does vga_lcd work? Do you just write to a memory area, and let the controller fetch from there every new frame? | 13:37 |
| victorb | Hi, I trying to execute a simple program("Hello World") in the Icarus Verilog simulator, but it give me an error that I can understand | 14:08 |
| victorb | Here is the output that I have: http://pastie.org/private/sler3igmto1ajbsjjo9ja | 14:09 |
| victorb | someone can help me? | 14:09 |
| stekern | olofk: you configure the screen setup and the framebuffer memory address in the wb slave registers | 14:55 |
| stekern | and then it just continuously fetch data from that memory area and feed it to the VGA port | 14:55 |
| stekern | there is a good manual available for that core, you know that right? =) | 14:56 |
| olofk | victorb: We just moved the location of uart16550_model, so it's probably related to that. I can look it up later tonight | 15:15 |
| victorb | ok, thanks | 15:17 |
| blueCmd | stekern: http://dd51d45a28f4eb5d.paste.se/ | 15:28 |
| blueCmd | do you see anything weird? | 15:28 |
| blueCmd | that loops forever for me, and I'm trying to figure out what I've done wrong. I'm pretty convinced that it's in qemu | 15:28 |
| blueCmd | I mean, the code is simple but I've been debugging for a long time now so I want a second opinion | 15:29 |
| stekern | blueCmd: no, that looks right | 16:27 |
| stekern | but you've had other l.lwa/l.swa pairs succeeding, hadn't you? | 16:29 |
| stekern | the only 'special' thing I can see about that is that the load and store is at an offset from r30 | 16:30 |
| stekern | no idea how that is handled in qemu, but something you might look at that it's handled correctly | 16:31 |
| stekern | oh... did I screw up the uart for icarus :( | 16:36 |
| blueCmd | stekern: yeah, the problem there I _think_ was that I used a variable in qemu that wasn't guaranteed to survive branches | 16:36 |
| blueCmd | I fixed that and it now crashes instead of spinning, so that's better I guess :P | 16:37 |
| blueCmd | (in another place) | 16:37 |
| stekern | olofk: tb_private_src_files doesn't of course work to use in the standalone core, but is there some other way to mark that that file should only be included as a part of a testbench? | 16:47 |
| stekern | I can get around the bug without it, but I think it'd be nice if such a feature existed (if it doesn't already exist) | 16:48 |
| stekern | ah! tb_src_files | 16:49 |
| stekern | fixed... | 16:52 |
| blueCmd | YEEEEES | 17:08 |
| blueCmd | I loove squishing bugs that I've spent a sh*tton of hours debugging | 17:08 |
| stekern | blueCmd: please tell me that it was something silly like a typo or calculating words as bytes, so I don't have to feel alone.... | 17:59 |
| blueCmd | stekern: almost | 18:14 |
| blueCmd | stekern: memory offset was calculated in a temporary variable in qemu | 18:15 |
| blueCmd | by default temporary variables are not scoped to be valid across branches | 18:15 |
| blueCmd | extending the scope was the fix | 18:15 |
| blueCmd | https://github.com/bluecmd/or1k-qemu/commit/7c2640d2ac321eb970250b389c77fe60c7e98834 | 18:15 |
| stekern | ok, you mentioned ah crash after that, did you find the fix for that too? | 18:19 |
| blueCmd | stekern: it was due to that | 18:20 |
| blueCmd | ah right | 18:20 |
| blueCmd | when I wrote about it first I fixed it at one place | 18:20 |
| blueCmd | and it turned out to be at another place as well | 18:20 |
| blueCmd | the first fix was the order which I do the compares (addr/value vs value/addr), the other was the offset(reg) decoding | 18:21 |
| blueCmd | now then. futex locks up | 18:21 |
| blueCmd | interesting | 18:21 |
| blueCmd | stekern: futex_atomic_cmpxchg_inatomic | 18:34 |
| blueCmd | does that really work? | 18:35 |
| blueCmd | to me it looks like it would do l.swa, potentially not branch and just l.j to itself | 18:35 |
| blueCmd | https://github.com/bluecmd/or1k-linux/blob/d863b0637811dd559363a3f1bf9d966e35b21bab/arch/openrisc/include/asm/futex.h#L114 | 18:37 |
| stekern | blueCmd: what's after 3: is in another .section | 18:58 |
| blueCmd | stekern: right, so it will break the asm at that point? | 18:59 |
| blueCmd | "break" | 18:59 |
| stekern | yes, only what's above 3: will be 'inside' futex_atomic_cmpxchg_inatomic | 19:07 |
| blueCmd | cool | 19:07 |
| stekern | the point with the fixups is that if you get a pagefault in either 1: or 2:, this code http://lxr.free-electrons.com/source/arch/openrisc/mm/fault.c#L238 will set the user PC to 4: and the function will then return -EFAULT. | 19:09 |
| blueCmd | aha | 19:10 |
| stekern | that way you can initially just do a rudimentary sanity check of the address (access_ok()) and then lazily let the mmu catch the rest | 19:11 |
| blueCmd | neat | 19:14 |
| blueCmd | stekern: removing or1k override for pthread_once "solved" the futex lock | 19:34 |
| blueCmd | I like that glibc is actually consolidating files so I can remove a lot of overrides | 19:34 |
| blueCmd | that's most welcome | 19:34 |
| stekern | ah, what did the override do? | 19:36 |
| blueCmd | stekern: a lot of subtle differences | 20:11 |
| blueCmd | the override was for "pthread_once" | 20:11 |
| blueCmd | some thread setup thing | 20:11 |
| blueCmd | stekern: I get killed when I do FUTEX_WAIT on an adress I know is valid | 20:12 |
| stekern | dalias: looks like you've got company in the gcc 4.9 haters club: https://lkml.org/lkml/2014/7/24/584 | 20:13 |
| stekern | blueCmd: interesting, what's the address? and do you have something I could test here? | 20:14 |
| blueCmd | i'm trying to narrow it down, but as it looks now I can read the value of an address just fine, but when I do a futex_wait on it (it's the TID) I get SIGSGV | 20:15 |
| blueCmd | hm | 20:17 |
| blueCmd | or it might be SIGSEGV in the other thread actually | 20:17 |
| blueCmd | yes, it must be that - the crash point in the main thread is erradic | 20:19 |
| blueCmd | heh. right. the new thread SIGSEGVs directly after the clone | 20:39 |
| dalias | stekern, thanks | 20:41 |
| blueCmd | stekern: I'm having trouble with clone | 21:36 |
| blueCmd | my stack seems to lose it's contents. I'm trying to pass the function ptr that the child should jump to, but I think something bad happens :) | 21:36 |
| blueCmd | I don't have any fancy l.nop to help me debug it currently, so I'm asking if you have seen something like this when you ported musl | 21:37 |
| stekern | blueCmd: can you point me to the place where clone is in glibc? | 21:38 |
| stekern | i.e., where the actual clone syscall is being made | 21:39 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/unix/sysv/linux/or1k/or1k_clone.S | 21:41 |
| blueCmd | *sigh* I guess I'll have to compile something statically and throw it into or1ksim | 21:48 |
| stekern | why couldn't you just have pulled the args from the stack directly in __or1k_clone? | 21:49 |
| blueCmd | stekern: because I have wrappers for other syscalls everywhere as well | 21:50 |
| blueCmd | also I'm not sure i knew about the vararg ABI back in 2012 or when I wrote this | 21:51 |
| stekern | well, obviously you did, since you acocunted for it ;) | 21:52 |
| blueCmd | no, I created wrappers on a "on crash"-basis | 21:52 |
| blueCmd | I knew it bugged and wrappers solved it, but I didn't know why | 21:52 |
| stekern | hmm, you save stuff on the child stack, but I can't see that you are adjusting the stack pointer for that anywhere? | 21:54 |
| blueCmd | stekern: I'm doing that locally, I found that as well but it doesn't appear to fix stuff | 21:54 |
| blueCmd | aaah | 21:54 |
| blueCmd | i'm doing +14 locally | 21:55 |
| blueCmd | it should be -14 | 21:55 |
| stekern | heh, ok.. I ask you to point me to the code that is buggy, and you have changed it. Thanks ;) | 21:55 |
| blueCmd | stekern: sorry, I forgot that I changed that | 21:55 |
| stekern | np, it seems it lead to that we found the bug anyway | 21:56 |
| blueCmd | doesn't seem to help much though | 21:58 |
| stekern | and 14? that sounds awfully unaligned | 21:58 |
| blueCmd | http://e95cb36933926b92.paste.se/ | 21:58 |
| blueCmd | stekern: I'm just not writing what I'm thinking, I'm a bit tierd I think | 21:59 |
| blueCmd | I mean 12 | 21:59 |
| blueCmd | I shaved stuff away to remove error sources, fn is a function that writes 'ALIVE', I modified this function so that both threads end up calling the function (it has a while(1); so it should never return) | 22:00 |
| blueCmd | the main thread calls it and spins, but the child thread does not | 22:00 |
| stekern | I can't find anything obvious wrong in your clone now at least | 22:10 |
| blueCmd | I _thikn_ this started when I switched to your SMP kernel | 22:10 |
| blueCmd | but it could also just have nudged the right things to reveal the bug | 22:11 |
| blueCmd | I'm considering stuff like if my flags are wrong to clone or something | 22:11 |
| stekern | do you have the program? | 22:11 |
| stekern | or, can you give it to me | 22:11 |
| blueCmd | yes | 22:12 |
| blueCmd | http://openrisc.debian.net/testsuite | 22:12 |
| blueCmd | it's supposed to print "ALIVE" twice and then do nothing | 22:13 |
| stekern | you have a l.nop 8 in there? | 22:18 |
| blueCmd | yes. | 22:18 |
| blueCmd | i Just now started it in or1ksim | 22:18 |
| blueCmd | that was kinda useless | 22:18 |
| blueCmd | sorry about that, I'll move the relevant test first | 22:18 |
| blueCmd | stekern: should be a better version now | 22:19 |
| stekern | well, it's not that much that is done before it | 22:19 |
| blueCmd | stekern: so, I refined my .lnops a bit | 22:24 |
| blueCmd | http://25fa3654f6291f63.paste.se/ | 22:24 |
| blueCmd | that's l.nop 8; l.lwz func addres; l.nop 9; in both child and parent thread | 22:24 |
| blueCmd | the address looks fine | 22:25 |
| blueCmd | better output: http://33433975794a63ef.paste.se/ | 22:30 |
| stekern | you don't have the source to that program in a cut-down form? | 22:30 |
| blueCmd | stekern: which program? testsuite? | 22:31 |
| stekern | yes | 22:31 |
| stekern | but only the part that does the clone | 22:31 |
| blueCmd | not cut-down no | 22:31 |
| blueCmd | the part that does the clone is pthread_create | 22:31 |
| blueCmd | so anything that does that should trigger this | 22:31 |
| blueCmd | http://git.etalabs.net/cgit/libc-testsuite/tree/pthread.c#n145 that's the row anyway | 22:32 |
| blueCmd | oooh | 22:33 |
| blueCmd | l.sw is the thing that causes a bus exception | 22:34 |
| blueCmd | or? | 22:34 |
| blueCmd | maybe not | 22:34 |
| stekern | does this test work for you then? http://nsz.repo.hu/git/?p=libc-test;a=blob;f=src/functional/sem_init.c;h=0d30f02f391ee9d32cc12871580aab0df16b1ee3;hb=HEAD | 22:37 |
| blueCmd | yes | 22:37 |
| blueCmd | .. that's weird | 22:37 |
| stekern | got to sleep now, let me know if you figure it out, otherwise I can take a fresh look in the morning | 22:39 |
| blueCmd | stekern: yes, thanks - I'm gonna revert my kernel a few versions | 22:39 |
| blueCmd | if that doesn't help I'm gonna call it a night aswell | 22:40 |
| blueCmd | *sigh* | 22:53 |
| blueCmd | l.jalr. using r9. | 22:53 |
| blueCmd | "It's is not allowed to specify link register r9" | 22:53 |
| blueCmd | which I should have realised way earlier | 22:54 |
| blueCmd | oh well | 22:54 |
| blueCmd | yes, now it gets all the way to start_thread - so that's muuch better. it crashes somewhere inside of that, but that's for tomorrow :-) | 23:06 |
| dalias | working on glibc? | 23:19 |
| --- Log closed Fri Jul 25 00:00:34 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!