IRC logs for #openrisc Saturday, 2014-07-19

--- Log opened Sat Jul 19 00:00:25 2014
stekerndalias: synchronization is built in to ll/sc06:42
stekernat least as it is defined now06:42
stekernblueCmd_: what am I looking at here?06:45
stekernvirtio block device?06:45
stekernblueCmd_: (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 blk09:11
blueCmd_its faast09:11
blueCmd_stekern: i'm considering implementing SMP in qemu09:19
blueCmd_do you have a guesstimate of the amount of work?09:20
stekerndoes that make sense?09:25
blueCmd_i want a fast openrisc emulation09:29
stekernhmm, 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
stekernbut isn't that due to virtualisation?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 think09:34
stekernwell, that's what I'm asking... does (the generic parts of) qemu support doing that?09:36
stekernor is it what you want to add?09:37
blueCmd_qemu supports SMP, but not for openrisc09:43
stekernI mean, yes you can model a SMP system in qemu afaik. but will it actually map to host CPUs when host != guest09:43
blueCmd_right, I don't care about SMP per se, I just want multiple cores09:44
blueCmd_sorry if I was unclear09:44
blueCmd_and SMP is what qemu calls multicore support today09:44
stekernyeah, but whatever we call it, will it (in the current setup) run them concurrently?09:45
stekernI mean, for for example an ARM system, I get that for *openrisc* there is supprt missing in the target specific parts09:46
blueCmd_stekern: yes, I think it will09:47
stekernI can very little to none documentation about it10:04
stekernanyway, the openrisc specific parts should be relatively easy10:04
stekernyou need the atomic insns10:04
stekernand then there's the need for extra scratch regs10:05
stekernI'm still using the 'implementation specific SPR' hack for that, but in the end we should use an extra RF10:06
stekernI have some half-baked patches for that.10:06
stekernbut you can of course start with adding read/writable 'implementation specific SPRs', or1ksim has always had support to read/write them10:07
blueCmd_hm, seems like my glibc is super-broken since I changed to use GCC atomics10:23
stekernyou'll need to support the ipi part of ompic too10:24
stekernompic = open muti-processor interrupt controller10:26
stekernthe ipi part is the only thing implemented in it so far10:27
stekernblueCmd_: do you have this patch applied now?
blueCmd_stekern: I don't, but my atomics doesn't work even in chroot10:33
blueCmd_it just hangs10:33
stekernok, then it's not that ;)10:33
blueCmd_it might be that as well, but yeah10:33
stekernthat fixed the hang I was seeing with or1ksim, but it then later crashed when I tried to login, so there's more bugs for susre10:34
blueCmd_reverting to in-kernel atomics seems to solve it for now10:35
blueCmd_but that only means that gcc or qemu is broken10:35
stekernI would guess gcc11:00
blueCmd_right. I need to revert that thing as well11:13
blueCmd_that might screw some stuff up11:14
blueCmd_stekern: nice that you rebased everything on 3.1512:03
blueCmd_I'm running a frankenstein merge of 3.15, I'll fork your repo I think12:04
blueCmd_oh man, I got virtfs working now as well12:29
blueCmd_no more NFS mounts12:30
stekern'frankensteun merge' lol12:51
blueCmd_stekern: you had problems with switching user to a non-root user right?12:52
stekernand now I can't even login12:57
stekerneven as root12:58
blueCmd_stekern: you have very high demands12:59
rschmidlinHi 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 or instead14:00
blueCmd_rschmidlin: which SVN are you referring to specifically?14:00
rschmidlinMinsoc had it as import14:04
rschmidlinAnd it does not seem to work any longer14:04
rschmidlinI can change the latest version to github14:05
rschmidlinBut for the fixed tagged versions, I don't know what to do14:05
blueCmd_rschmidlin: ah, right. so that was one of the repositories I was unable to fork since it was so big14:06
blueCmd_rschmidlin: yes, it's unfourtunate, but that's why I'm crusading on leaving opencores14:06
blueCmd_rschmidlin: can you use ?14:08
rschmidlinI see. But are the repositories being shutdown or are they only currently unavailable?14:08
rschmidlinI had to check... Gimme a second14:09
blueCmd_rschmidlin: I have no idea, I don't know the people behind opencores14:09
blueCmd_I'm just forking everything as fast as I can and hope I get everything before something goes away14:10
rschmidlin_oh, it just worked14:13
rschmidlin_the repository url is
blueCmd_rschmidlin: right, I wrote that a few lines up14:14
rschmidlinOh yes... I probably had some issues with my company's proxy14:16
rschmidlinThanks blueCmd14:33
blueCmd_rschmidlin: anytime14:42
blueCmd_dalias: stekern: I get some interesting errors when running the musl testsuite on my glibc14:43
blueCmd_dalias: Am I correct to assume that glibc will not pass all the tests in ? even on my host machine I get errors, but I guess those are from fixes that glibc don't have14:44
blueCmd_after removing the tests that fail on the host, I still get some errors for pthreads, sockets and time. cool stuff14:44
blueCmd_O_NONBLOCK seems to be broken for accept()14:52
stekernblueCmd_: this is the current testsuite
blueCmd_stekern: cool, I'll have that one a go as well14:57
blueCmd_stekern: did you have more info about ipc? semid = semget(k, 1, IPC_CREAT|0666) failed: Function not implemented15:35
daliasbluecmd_, can you pastebin the output for glibc? i would not be surprised if some of them fail :)15:48
blueCmd_you have the compilation log there as well, so you will want the end :P15:51
daliasbtw the end is src/REPORT15:53
daliasbtw that server seems to be serving a bad charset15:59
daliasi see things like this all over the text: ‘C’15:59
daliaslooks like it puts iso8859-1 in the headers despite content being utf815:59
blueCmd_hm, ok I'll have a look16:00
daliasCLOCK_REALTIME failing is weird. is this host from the 90s or something ? :)16:00
daliasthe scanf failures are all expected, these are all leftover glibc bugs from the drepper WONTFIX days16:01
blueCmd_dalias: it's from march, but it's a VM16:01
daliasweird. maybe a kernel bug then16:02
blueCmd_Debian if that makes any difference16:02
daliasiconv_open are probably real but inconsequential bugs. inet_pton is a subtle issue in what's a valid form for ipv6 literal16:04
daliasthe hsearch bugs are real: it's not catching an overflow then crashing :)16:08
stekernblueCmd_: 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 kernel16:11
stekernbut you only need/should to do that if you support anything else than the IPC_6416:12
blueCmd_stekern: that sounds weird16:36
stekernblueCmd_: 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
daliasstekern, oh did you ever see my question about barriers?20:28
stekerndalias: yup, and I answered too ;)20:29
daliasoh i missed it20:29
daliasah ok20:29
stekernll/sc acts as barriers on their own20:29
daliasfound it in scrollback20:29
daliasbtw if you ever want to have relaxed atomics..20:30
daliasthe right way to do it would be adding new instructions that are relaxed, imo20:30
daliasrelaxing the current ones would be ABI breakage20:30
stekernI don't know if having relaxed atomics ever will be important enough20:32
daliasimo the usage cases for them are fairly rare20:35
daliasso far musl does not attempt to use them20:35
daliaswell... i take that back20:35
daliasthey're not very useful for system-level stuff20:35
daliasfor app-level they're extremely useful20:35
daliasrelaxed-order is probably the right way to do refcounting20:36
stekernhmm, that's probably a good point.20:36
daliasyou only care about the value of the atomic counter itself20:37
daliasit's not protecting other state except freeing the whole object20:37
daliasand that happens only when the count reaches zero20:37
daliasi'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/dec20:38
daliasif the language itself controls refcounting, it can optimize out the vast majority of unnecessary reference inc/dec and thereby the barrier cost20:39
daliasbut if you're doing refcounting manually, the barriers are expensive unless you manually optimize out unneeded ref inc/dec20:39
daliasstekern, btw your a_store is wrong. sorry for not catching that. it's a bug on some other archs too i think...20:46
daliasbut i want to understand your intent20:46
daliasis 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
daliasif not, i think to be safe a_store needs to perform useless ll/sc20:47
daliasjust to achieve the barrier20:47
stekernoh, good that you brought that up. I actually made a notice about that myself and had my doubts about that as well.20:48
stekernyes, that will probably need a ll/sc to be safe.20:49
stekernnow in practice, all current implementations are strongly ordered, but they do not need to be.20:50
daliasshould it be like the arm one? (loop using cas until *p is successfully replaced with x)?20:51
daliasor is there an easier way to do it?20:52
daliassemantically, a_store should be: barrier; *p=x; barrier;20:52
daliasdoes it suffice to do: ll dummy ; *p=x; sc dummy (without a loop)?20:54
stekernwell, we *do* have a l.msync instruction, that is defined to act as a nop on implementations that don't need it20:55
stekernI'm just not sure if that's honored (i.e. that it will not cause a illegal instruction instead)20:56
daliasok that's probably the right way to do it then20:56
daliascan you check?20:56
stekernyup, will do20:56
daliasit's not needed along with the ll/sc tho, is it?20:56
stekernno, since they are now defined to have a 'builtin l.msync'20:57
daliaswell if l.msync is safe i'll use it. otherwise we need to do useless ll/sc i think20:58
stekerneither case, since the l.lwa/l.swa are required to run musl, the number of implementations to fix is limited.20:59
daliaswell the kernel could emulate lwa/swa if the hardware doesn't support it21:00
daliasin which case it would also need to emulate msync if it's missing21:00
stekernyeah, that'd work21:01
daliasemulating 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 clear21:02
blueCmd_weird weird issues. I'm working to get GCC tests to run using SSH and qemu21: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
daliasstekern, any answer on l.msync ?21:50
stekerndalias: yeah, looks like support is missing in mor1kx at least. should be easy to add though.21:51
daliasit sigill's ?21:53
daliasshould we use llsc for a barrier then?21:53
stekernI'm kind of fine with either, but that will at least work as is.21:55
stekernI'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
stekernsince 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
daliaswhat about real hardware?22:00
daliasthat's more of a pain to change, no?22:01
stekernmor1kx is real hardware22:01
daliasso we should probably do ll/sc :/22:02
stekernbut since it's strongly ordered (so far), it's just a matter of not treating the instruction as an illegal instruction22:02
daliasfrom a standpoint of actually providing something ppl can use right away22:02
stekernyeah, we can revisit it later in any case22:04
stekernhmm, I just noticed that one of our Linux files include <stddef.h>22:05
stekernisn't that odd?22:05
daliasgcc provides the "freestanding" c headers22:06
daliasand glibc expects it to (glibc does not provide them itself)22:06
daliasbut making this work requires nasty knowledge of each other's internals22:06
daliasmusl does not support using the gcc freestanding headers bug provides a full set of C headers22:06
daliasfreudian? :)22:07
-!- blueCmd_ is now known as blueCmd22:07
stekernwhen I tried to compile the kernel with my musl-cross built toolchain, it didn't pick it up22:07
daliastry removing -nostdinc from the kernel's makefiles22:08
stekernnow, that include isn't even needed in that file... so it can be removed22:08
daliasi think their logic for getting back the gcc headers after adding -nostdinc is buggy22:08
blueCmdstekern: hm, I think I can compile linux with my boot-gcc which shouldn't use glibc at all22:09
blueCmdmaybe I remember wrongly22:09
stekernit's this:
stekernremoving -nostdinc works too22:15
daliasstekern, how should i do the llsc based a_store?22:34
daliasjust a_cas(p, *p, x) ?22:35
--- Log closed Sun Jul 20 00:00:27 2014

Generated by 2.15.2 by Marius Gedminas - find it at!