| --- Log opened Sat Aug 23 00:00:19 2014 | ||
| olofk | The 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 files | 09:50 |
|---|---|---|
| olofk | The easist way for now is probably to require the user to specify a tool, but that's roughly the same thing as sim --build-only | 09:52 |
| -!- Netsplit *.net <-> *.split quits: kiwichris | 11:38 | |
| -!- Netsplit *.net <-> *.split quits: kiwichris | 13:46 | |
| -!- Netsplit over, joins: kiwichris | 14:08 | |
| stekern | I don't get the logic behind this piece of code: http://lxr.free-electrons.com/source/kernel/smp.c#L188 | 17:56 |
| stekern | llist_add returns !0 when the list was empty before adding the entry | 17:56 |
| stekern | why shouldn't the ipi be sent in that case? | 17:57 |
| stekern | from 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 something | 18:01 |
| stekern | oh... I actually wrote that right, but I read the code as llist_add returns 0 when the list was empty | 18:18 |
| stekern | that makes more sense | 18:19 |
| stekern | once again writing out what you think out loud helped | 18:20 |
| poke53281 | Sometimes 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 |
| poke53281 | is there a nice english word. Otherwise I have to use something like ON_SERVER or NOT_LOADED or something. | 20:22 |
| poke53281 | AVAILABLE would be also possible. | 20:24 |
| hesham | Hi, where can I find context switch, interrupt handling code for OpenRISC/linux (at lxr)? | 20:27 |
| poke53281 | Do you mean this? http://git.openrisc.net/cgit.cgi/jonas/linux/tree/arch/openrisc/kernel/irq.c | 20:31 |
| poke53281 | not sure what you mean with "lxr". | 20:31 |
| poke53281 | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/arch/openrisc/kernel/process.c | 20:32 |
| stekern | poke53281: most of that code is 'obsolete' now | 20:32 |
| hesham | poke53281: I mean that one http://lxr.free-electrons.com/source/arch/openrisc/ | 20:32 |
| stekern | the irq.c one I mean | 20:32 |
| stekern | the code is in drivers/irqchip/ | 20:32 |
| stekern | hesham: http://lxr.free-electrons.com/source/arch/openrisc/kernel/entry.S | 20:33 |
| hesham | stekern: That's it, thanks! | 20:33 |
| stekern | some of it is in http://lxr.free-electrons.com/source/arch/openrisc/kernel/head.S too | 20:34 |
| stekern | I think I'm on the verge of nailing the 'spinlock bug' | 20:35 |
| poke53281 | Actually 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 |
| stekern | I've got a dbus ack to both cpus at the same time, and they're attached to the same dbus | 20:36 |
| stekern | yeah, Jonas seems to be MIA lately... | 20:37 |
| stekern | but the irq changes was merged by the irqchip guys (but Jonas was commenting on them and acking them) | 20:38 |
| poke53281 | Super. Yesterday you wrote something about "triple" locks :) | 20:38 |
| stekern | yes, this is related, I think... I've managed to get the kernel to crash in slightly different (and more reliable) ways | 20:39 |
| stekern | now 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 memory | 20:46 |
| poke53281 | Unfortunately 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 |
| stekern | well, it is 'running', it's just not very stable ;) | 20:50 |
| poke53281 | stable on real hardware? Or are there instabilities in the kernel? | 20:51 |
| poke53281 | did you implement it in or1ksim? | 20:52 |
| stekern | from what it looks now, the instabilities are hw related | 20:52 |
| stekern | no, I think wallento have some patches for or1ksim though, but I haven't checked them out | 20:53 |
| poke53281 | Any chance that you will implement the idle patch in your hardware. | 20:54 |
| poke53281 | implement the idle function I mean to test my patch. | 20:55 |
| stekern | I can take a look at that | 20:58 |
| poke53281 | For me the patch works without problems. | 21:00 |
| poke53281 | Don'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 |
| poke53281 | In 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 way | 21:07 |
| stekern | the double dbus ack was actually valid, one access was going out to a peripheral and the second to memory | 21:25 |
| stekern | but I know where the bug is now, the snooping logic doesn't work like it should while doing peripheral accesses. | 21:26 |
| poke53281 | Peripheral access should be always locked to one cpu. Can't imagine a scenario where this might be necessary. Graphics memory access. | 21:35 |
| stekern | ? | 21:36 |
| stekern | ah, 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 memory | 21:38 |
| stekern | https://github.com/openrisc/mor1kx/blob/multicore/rtl/verilog/mor1kx_lsu_cappuccino.v#L203-L204 | 21:41 |
| stekern | it has to check that our own address matches the snoop address too | 21:41 |
| stekern | wallento's (outside of mor1kx) snooping logic included peripherals too, but mine doesn't. | 21:42 |
| stekern | the 'snoop_valid' logic should be moved out of mor1kx though, the snoop_en_i signal should include that | 21:44 |
| stekern | +IMO | 21:44 |
| poke53281 | For me this is really horrible to find such bugs. Even quantum mechanics is easier, than to get this kind of synchronization working :) | 21:52 |
| poke53281 | The 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 |
| poke53281 | you can do the same with two cpus. | 21:55 |
| poke53281 | Of course nowadays, such solutions no longer work. | 21:56 |
| --- Log closed Sun Aug 24 00:00:21 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!