| --- Log opened Sat Jul 19 00:00:25 2014 | ||
| stekern | dalias: synchronization is built in to ll/sc | 06:42 |
|---|---|---|
| stekern | at least as it is defined now | 06:42 |
| stekern | blueCmd_: what am I looking at here? | 06:45 |
| stekern | virtio block device? | 06:45 |
| stekern | blueCmd_: (wiki) yes, I think we have been pretty good at documenting things. what we have been very bad at is removing deprecated info and keeping it organized. | 07:11 |
| blueCmd_ | stekern: qemu system boot with virtio blk | 09:11 |
| blueCmd_ | its faast | 09:11 |
| stekern | cool | 09:14 |
| blueCmd_ | stekern: i'm considering implementing SMP in qemu | 09:19 |
| blueCmd_ | do you have a guesstimate of the amount of work? | 09:20 |
| stekern | does that make sense? | 09:25 |
| blueCmd_ | i want a fast openrisc emulation | 09:29 |
| stekern | hmm, but emulating SMP is probably going to be slower? | 09:30 |
| blueCmd_ | well, doesn't it work well for x86 and other arches? | 09:32 |
| stekern | but isn't that due to virtualisation? | 09:33 |
| blueCmd_ | hm? | 09:33 |
| blueCmd_ | qemu currently runs only 1 thread, my idea is to make it so that you can add cores and use more threads and thus more cores, how would that be slower? | 09:34 |
| blueCmd_ | i know it doesnt scale forever, but having 4 openrisc cores would be quite interesting i think | 09:34 |
| stekern | well, that's what I'm asking... does (the generic parts of) qemu support doing that? | 09:36 |
| stekern | or is it what you want to add? | 09:37 |
| blueCmd_ | qemu supports SMP, but not for openrisc | 09:43 |
| stekern | I mean, yes you can model a SMP system in qemu afaik. but will it actually map to host CPUs when host != guest | 09:43 |
| blueCmd_ | right, I don't care about SMP per se, I just want multiple cores | 09:44 |
| blueCmd_ | sorry if I was unclear | 09:44 |
| blueCmd_ | and SMP is what qemu calls multicore support today | 09:44 |
| stekern | yeah, but whatever we call it, will it (in the current setup) run them concurrently? | 09:45 |
| stekern | I mean, for for example an ARM system, I get that for *openrisc* there is supprt missing in the target specific parts | 09:46 |
| blueCmd_ | stekern: yes, I think it will | 09:47 |
| stekern | I can very little to none documentation about it | 10:04 |
| stekern | anyway, the openrisc specific parts should be relatively easy | 10:04 |
| stekern | you need the atomic insns | 10:04 |
| stekern | and then there's the need for extra scratch regs | 10:05 |
| stekern | I'm still using the 'implementation specific SPR' hack for that, but in the end we should use an extra RF | 10:06 |
| stekern | I have some half-baked patches for that. | 10:06 |
| stekern | but you can of course start with adding read/writable 'implementation specific SPRs', or1ksim has always had support to read/write them | 10:07 |
| blueCmd_ | right | 10:21 |
| blueCmd_ | hm, seems like my glibc is super-broken since I changed to use GCC atomics | 10:23 |
| stekern | you'll need to support the ipi part of ompic too | 10:24 |
| stekern | ompic = open muti-processor interrupt controller | 10:26 |
| stekern | the ipi part is the only thing implemented in it so far | 10:27 |
| stekern | https://github.com/skristiansson/orpsoc-cores/blob/multicore/cores/ompic/rtl/verilog/ipi.v | 10:27 |
| stekern | blueCmd_: do you have this patch applied now? http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=a966c95bb10a43cab16e2be97518ad8be0695a95 | 10:32 |
| blueCmd_ | stekern: I don't, but my atomics doesn't work even in chroot | 10:33 |
| blueCmd_ | it just hangs | 10:33 |
| stekern | ok, then it's not that ;) | 10:33 |
| blueCmd_ | it might be that as well, but yeah | 10:33 |
| stekern | that fixed the hang I was seeing with or1ksim, but it then later crashed when I tried to login, so there's more bugs for susre | 10:34 |
| blueCmd_ | yes | 10:34 |
| blueCmd_ | reverting to in-kernel atomics seems to solve it for now | 10:35 |
| blueCmd_ | but that only means that gcc or qemu is broken | 10:35 |
| stekern | I would guess gcc | 11:00 |
| blueCmd_ | right. I need to revert that thing as well | 11:13 |
| blueCmd_ | that might screw some stuff up | 11:14 |
| blueCmd_ | stekern: nice that you rebased everything on 3.15 | 12:03 |
| blueCmd_ | I'm running a frankenstein merge of 3.15, I'll fork your repo I think | 12:04 |
| blueCmd_ | oh man, I got virtfs working now as well | 12:29 |
| blueCmd_ | no more NFS mounts | 12:30 |
| stekern | 'frankensteun merge' lol | 12:51 |
| blueCmd_ | stekern: you had problems with switching user to a non-root user right? | 12:52 |
| stekern | yes | 12:57 |
| stekern | and now I can't even login | 12:57 |
| stekern | even as root | 12:58 |
| blueCmd_ | stekern: you have very high demands | 12:59 |
| rschmidlin | Hi guys. Is now the or1200 subversion repository from opencores not available anymore? | 13:53 |
| blueCmd_ | rschmidlin: Hi, it should still be available, but I recommend using either github.com/openrisc or github.com/freecores instead | 14:00 |
| blueCmd_ | rschmidlin: which SVN are you referring to specifically? | 14:00 |
| rschmidlin | Http://opencores.org/ocsvn/or1200... | 14:03 |
| rschmidlin | Minsoc had it as import | 14:04 |
| rschmidlin | And it does not seem to work any longer | 14:04 |
| rschmidlin | I can change the latest version to github | 14:05 |
| rschmidlin | But for the fixed tagged versions, I don't know what to do | 14:05 |
| blueCmd_ | rschmidlin: ah, right. so that was one of the repositories I was unable to fork since it was so big | 14:06 |
| blueCmd_ | rschmidlin: yes, it's unfourtunate, but that's why I'm crusading on leaving opencores | 14:06 |
| blueCmd_ | rschmidlin: can you use http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200/ ? | 14:08 |
| rschmidlin | I see. But are the repositories being shutdown or are they only currently unavailable? | 14:08 |
| rschmidlin | I had to check... Gimme a second | 14:09 |
| blueCmd_ | rschmidlin: I have no idea, I don't know the people behind opencores | 14:09 |
| blueCmd_ | I'm just forking everything as fast as I can and hope I get everything before something goes away | 14:10 |
| rschmidlin_ | oh, it just worked | 14:13 |
| rschmidlin_ | the repository url is http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200 | 14:14 |
| blueCmd_ | rschmidlin: right, I wrote that a few lines up | 14:14 |
| rschmidlin | Oh yes... I probably had some issues with my company's proxy | 14:16 |
| rschmidlin | Thanks blueCmd | 14:33 |
| blueCmd_ | rschmidlin: anytime | 14:42 |
| blueCmd_ | dalias: stekern: I get some interesting errors when running the musl testsuite on my glibc | 14:43 |
| blueCmd_ | dalias: Am I correct to assume that glibc will not pass all the tests in http://git.musl-libc.org/cgit/libc-testsuite/ ? even on my host machine I get errors, but I guess those are from fixes that glibc don't have | 14:44 |
| blueCmd_ | after removing the tests that fail on the host, I still get some errors for pthreads, sockets and time. cool stuff | 14:44 |
| blueCmd_ | O_NONBLOCK seems to be broken for accept() | 14:52 |
| stekern | blueCmd_: this is the current testsuite http://nsz.repo.hu/git/?p=libc-test | 14:57 |
| blueCmd_ | stekern: cool, I'll have that one a go as well | 14:57 |
| blueCmd_ | stekern: did you have more info about ipc? semid = semget(k, 1, IPC_CREAT|0666) failed: Function not implemented | 15:35 |
| dalias | bluecmd_, can you pastebin the output for glibc? i would not be surprised if some of them fail :) | 15:48 |
| blueCmd_ | dalias: http://openrisc.debian.net/tmp/libc-test.amd64-glibc | 15:51 |
| blueCmd_ | you have the compilation log there as well, so you will want the end :P | 15:51 |
| dalias | btw the end is src/REPORT | 15:53 |
| blueCmd_ | aha | 15:53 |
| dalias | btw that server seems to be serving a bad charset | 15:59 |
| dalias | i see things like this all over the text: ‘C’ | 15:59 |
| dalias | looks like it puts iso8859-1 in the headers despite content being utf8 | 15:59 |
| blueCmd_ | hm, ok I'll have a look | 16:00 |
| dalias | CLOCK_REALTIME failing is weird. is this host from the 90s or something ? :) | 16:00 |
| dalias | the scanf failures are all expected, these are all leftover glibc bugs from the drepper WONTFIX days | 16:01 |
| blueCmd_ | dalias: it's from march, but it's a VM | 16:01 |
| dalias | weird. maybe a kernel bug then | 16:02 |
| blueCmd_ | Debian if that makes any difference | 16:02 |
| dalias | iconv_open are probably real but inconsequential bugs. inet_pton is a subtle issue in what's a valid form for ipv6 literal | 16:04 |
| dalias | the hsearch bugs are real: it's not catching an overflow then crashing :) | 16:08 |
| stekern | blueCmd_: the reason the IPC functions was failing at first for me was that I had defined the IPC_64 flag to be passed to the kernel | 16:11 |
| stekern | but you only need/should to do that if you support anything else than the IPC_64 | 16:12 |
| blueCmd_ | stekern: that sounds weird | 16:36 |
| stekern | blueCmd_: yeah, I got confused by it first too. but it really isn't all that weird, there are two ipc versions. some archs use IPC_OLD as the default and some use IPC_64 as the default. we use IPC_64 as default. | 19:07 |
| dalias | stekern, oh did you ever see my question about barriers? | 20:28 |
| stekern | dalias: yup, and I answered too ;) | 20:29 |
| dalias | oh i missed it | 20:29 |
| dalias | ah ok | 20:29 |
| stekern | ll/sc acts as barriers on their own | 20:29 |
| dalias | found it in scrollback | 20:29 |
| dalias | btw if you ever want to have relaxed atomics.. | 20:30 |
| dalias | the right way to do it would be adding new instructions that are relaxed, imo | 20:30 |
| dalias | relaxing the current ones would be ABI breakage | 20:30 |
| stekern | yeah | 20:31 |
| stekern | I don't know if having relaxed atomics ever will be important enough | 20:32 |
| dalias | imo the usage cases for them are fairly rare | 20:35 |
| dalias | so far musl does not attempt to use them | 20:35 |
| dalias | well... i take that back | 20:35 |
| dalias | they're not very useful for system-level stuff | 20:35 |
| dalias | for app-level they're extremely useful | 20:35 |
| dalias | relaxed-order is probably the right way to do refcounting | 20:36 |
| stekern | hmm, that's probably a good point. | 20:36 |
| dalias | you only care about the value of the atomic counter itself | 20:37 |
| dalias | it's not protecting other state except freeing the whole object | 20:37 |
| dalias | and that happens only when the count reaches zero | 20:37 |
| dalias | i'm not clear on whether you'd need to impose another barrier after observing the zero refcount before freeing; perhaps so. but you'd still avoid all the other unnecessary barriers every time you inc/dec | 20:38 |
| dalias | if the language itself controls refcounting, it can optimize out the vast majority of unnecessary reference inc/dec and thereby the barrier cost | 20:39 |
| dalias | but if you're doing refcounting manually, the barriers are expensive unless you manually optimize out unneeded ref inc/dec | 20:39 |
| dalias | stekern, btw your a_store is wrong. sorry for not catching that. it's a bug on some other archs too i think... | 20:46 |
| dalias | but i want to understand your intent | 20:46 |
| dalias | is your intent that or1k is like x86, where there is a strong inherent ordering and no special attention is needed to make a store atomic/synchronizing? | 20:47 |
| dalias | if not, i think to be safe a_store needs to perform useless ll/sc | 20:47 |
| dalias | just to achieve the barrier | 20:47 |
| stekern | oh, good that you brought that up. I actually made a notice about that myself and had my doubts about that as well. | 20:48 |
| stekern | yes, that will probably need a ll/sc to be safe. | 20:49 |
| stekern | now in practice, all current implementations are strongly ordered, but they do not need to be. | 20:50 |
| dalias | should it be like the arm one? (loop using cas until *p is successfully replaced with x)? | 20:51 |
| dalias | or is there an easier way to do it? | 20:52 |
| dalias | semantically, a_store should be: barrier; *p=x; barrier; | 20:52 |
| dalias | does it suffice to do: ll dummy ; *p=x; sc dummy (without a loop)? | 20:54 |
| stekern | well, we *do* have a l.msync instruction, that is defined to act as a nop on implementations that don't need it | 20:55 |
| stekern | I'm just not sure if that's honored (i.e. that it will not cause a illegal instruction instead) | 20:56 |
| dalias | ok that's probably the right way to do it then | 20:56 |
| dalias | can you check? | 20:56 |
| stekern | yup, will do | 20:56 |
| dalias | it's not needed along with the ll/sc tho, is it? | 20:56 |
| stekern | no, since they are now defined to have a 'builtin l.msync' | 20:57 |
| dalias | ok | 20:57 |
| dalias | well if l.msync is safe i'll use it. otherwise we need to do useless ll/sc i think | 20:58 |
| stekern | either case, since the l.lwa/l.swa are required to run musl, the number of implementations to fix is limited. | 20:59 |
| dalias | well the kernel could emulate lwa/swa if the hardware doesn't support it | 21:00 |
| dalias | in which case it would also need to emulate msync if it's missing | 21:00 |
| stekern | yeah, that'd work | 21:01 |
| dalias | emulating them is trivial (but slow of course): keep a flag in the task structure that's cleared on each context switch and by swa, and set by lwa. swa succeeds if the flag is set and fails if it's clear | 21:02 |
| blueCmd_ | weird weird issues. I'm working to get GCC tests to run using SSH and qemu | 21:41 |
| blueCmd_ | I never got it to work fully, but I feel like I'm really close this time. tests work, but at some point dejagnu just stops uploading files with the helpful error message 'failed' | 21:42 |
| dalias | stekern, any answer on l.msync ? | 21:50 |
| stekern | dalias: yeah, looks like support is missing in mor1kx at least. should be easy to add though. | 21:51 |
| dalias | it sigill's ? | 21:53 |
| dalias | should we use llsc for a barrier then? | 21:53 |
| stekern | I'm kind of fine with either, but that will at least work as is. | 21:55 |
| stekern | I'm going to fix mor1kx anyway. And or1ksim (it wasn't completely clear from the source how it behaves on a l.msync, I'll need to test it). | 21:55 |
| stekern | since not supporting them is a misinterpretation of the spec. the instruction itself is marked as optional, but it's only optional to implement the synchronisation functionality of it. | 21:56 |
| dalias | what about real hardware? | 22:00 |
| dalias | that's more of a pain to change, no? | 22:01 |
| stekern | mor1kx is real hardware | 22:01 |
| dalias | ah | 22:01 |
| dalias | so we should probably do ll/sc :/ | 22:02 |
| stekern | but since it's strongly ordered (so far), it's just a matter of not treating the instruction as an illegal instruction | 22:02 |
| dalias | from a standpoint of actually providing something ppl can use right away | 22:02 |
| dalias | *nod* | 22:02 |
| stekern | yeah, we can revisit it later in any case | 22:04 |
| stekern | hmm, I just noticed that one of our Linux files include <stddef.h> | 22:05 |
| stekern | isn't that odd? | 22:05 |
| dalias | perhaps | 22:06 |
| dalias | gcc provides the "freestanding" c headers | 22:06 |
| dalias | and glibc expects it to (glibc does not provide them itself) | 22:06 |
| dalias | but making this work requires nasty knowledge of each other's internals | 22:06 |
| dalias | musl does not support using the gcc freestanding headers bug provides a full set of C headers | 22:06 |
| dalias | s/bug/but/ | 22:07 |
| dalias | freudian? :) | 22:07 |
| stekern | ;) | 22:07 |
| blueCmd_ | :P | 22:07 |
| -!- blueCmd_ is now known as blueCmd | 22:07 | |
| stekern | when I tried to compile the kernel with my musl-cross built toolchain, it didn't pick it up | 22:07 |
| dalias | try removing -nostdinc from the kernel's makefiles | 22:08 |
| stekern | now, that include isn't even needed in that file... so it can be removed | 22:08 |
| dalias | i think their logic for getting back the gcc headers after adding -nostdinc is buggy | 22:08 |
| blueCmd | stekern: hm, I think I can compile linux with my boot-gcc which shouldn't use glibc at all | 22:09 |
| blueCmd | maybe I remember wrongly | 22:09 |
| stekern | it's this: http://lxr.free-electrons.com/source/arch/openrisc/kernel/ptrace.c#L19 | 22:10 |
| stekern | removing -nostdinc works too | 22:15 |
| dalias | stekern, how should i do the llsc based a_store? | 22:34 |
| dalias | just a_cas(p, *p, x) ? | 22:35 |
| dalias | ? | 22:59 |
| --- Log closed Sun Jul 20 00:00:27 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!