IRC logs for #openrisc Saturday, 2014-08-23

--- Log opened Sat Aug 23 00:00:19 2014
olofkThe main reason (except for lack of time) that I haven't implemented an export function in FuseSoC is that I haven't figured out a good way to handle the issue that different tools may pull in different dependencies and files09:50
olofkThe easist way for now is probably to require the user to specify a tool, but that's roughly the same thing as sim --build-only09:52
-!- Netsplit *.net <-> *.split quits: kiwichris11:38
-!- Netsplit *.net <-> *.split quits: kiwichris13:46
-!- Netsplit over, joins: kiwichris14:08
stekernI don't get the logic behind this piece of code:
stekernllist_add returns !0 when the list was empty before adding the entry17:56
stekernwhy shouldn't the ipi be sent in that case?17:57
stekernfrom what I can tell, that would make it possible to lock the csd_lock without anything unlocking it (and that happens to me)18:00
stekern...but this is fairly old generic code, so I'm suspecting I'm misunderstanding something18:01
stekernoh... I actually wrote that right, but I read the code as llist_add returns 0 when the list was empty18:18
stekernthat makes more sense18:19
stekernonce again writing out what you think out loud helped18:20
poke53281Sometimes I have problem with the naming of variables. How would you name a status of file which is still on the server, not loaded, and will be loaded on demand.20:21
poke53281is there a nice english word. Otherwise I have to use something like ON_SERVER or NOT_LOADED or something.20:22
poke53281AVAILABLE would be also possible.20:24
heshamHi, where can I find context switch, interrupt handling code for OpenRISC/linux (at lxr)?20:27
poke53281Do you mean this?
poke53281not sure what you mean with "lxr".20:31
stekernpoke53281: most of that code is 'obsolete' now20:32
heshampoke53281: I mean that one
stekernthe irq.c one I mean20:32
stekernthe code is in drivers/irqchip/20:32
heshamstekern: That's it, thanks!20:33
stekernsome of it is in too20:34
stekernI think I'm on the verge of nailing the 'spinlock bug'20:35
poke53281Actually I am not sure who and how the Linux code is maintained. Didn't get any reply for my idle patch and the signal handling is still wrong in the official kernel.20:36
stekernI've got a dbus ack to both cpus at the same time, and they're attached to the same dbus20:36
stekernyeah, Jonas seems to be MIA lately...20:37
stekernbut the irq changes was merged by the irqchip guys (but Jonas was commenting on them and acking them)20:38
poke53281Super. Yesterday you wrote something about "triple" locks :)20:38
stekernyes, this is related, I think... I've managed to get the kernel to crash in slightly different (and more reliable) ways20:39
stekernnow I have one cpu writing zero to a memory address, and then the other cpu reads out something else than zero from it.20:43
stekern...and from what I can gather, the store get wrongly acked somehow, so I assume that it doesn't actually get through to the memory20:46
poke53281Unfortunately I can't help you with this. But one thing is for sure. When we will manage to have a smp system running, I will implement it too :)20:50
stekernwell, it is 'running', it's just not very stable ;)20:50
poke53281stable on real hardware? Or are there instabilities in the kernel?20:51
poke53281did you implement it in or1ksim?20:52
stekernfrom what it looks now, the instabilities are hw related20:52
stekernno, I think wallento have some patches for or1ksim though, but I haven't checked them out20:53
poke53281Any chance that you will implement the idle patch in your hardware.20:54
poke53281implement the idle function I mean to test my patch.20:55
stekernI can take a look at that20:58
poke53281For me the patch works without problems.21:00
poke53281Don't think it will be hard. If the bit is written to the register the hardware must switch to some endless loop till the next interrupt occurs. Like an jump instruction to itself.21:01
poke53281In principle the bit must be set to zero by hardware if the cpu leave the idle state. But the register is never read.21:03
stekern'just' connecting it to the pipeline stall signals is probably the easiest way21:07
stekernthe double dbus ack was actually valid, one access was going out to a peripheral and the second to memory21:25
stekernbut I know where the bug is now, the snooping logic doesn't work like it should while doing peripheral accesses.21:26
poke53281Peripheral access should be always locked to one cpu. Can't imagine a scenario where this might be necessary. Graphics memory access.21:35
stekernah, no. I mean the snooping logic to the main mem get confused when one of the cpus are accessing a peripheral at the same time as the other cpu is accessing memory21:38
stekernit has to check that our own address matches the snoop address too21:41
stekernwallento's (outside of mor1kx) snooping logic included peripherals too, but mine doesn't.21:42
stekernthe 'snoop_valid' logic should be moved out of mor1kx though, the snoop_en_i signal should include that21:44
poke53281For me this is really horrible to find such bugs.  Even quantum mechanics is easier, than to get this kind of synchronization working :)21:52
poke53281The was a easy solution in the early days. The memory access was divided into two parts. The cpu had access during the rising edge and the graphics chip had access during the falling edge :)21:54
poke53281you can do the same with two cpus.21:55
poke53281Of course nowadays, such solutions no longer work.21:56
--- Log closed Sun Aug 24 00:00:21 2014

Generated by 2.15.2 by Marius Gedminas - find it at!