--- Log opened Mon Aug 25 00:00:22 2014 | ||
stekern | hmm, briefly looking at the github repo with the or1200->mor1kx fpu it seems like the fpu used a bsd-like license | 18:44 |
---|---|---|
olofk | ohdl is pretty bsd-like too, isn't it? | 18:49 |
stekern | yes | 18:55 |
stekern | I think I've figured out this snooping bug (aka, the bug formerly known as spinlock bug) | 19:12 |
stekern | I believe it's a corner case where a snoop hit happens at the same time as a refill is just about to start | 19:13 |
stekern | and the tags are saved away, since we only have one tag mem for all ways | 19:14 |
stekern | then when the refill is done, the saved tag is written over the invalidation caused by the snoop | 19:15 |
stekern | ...all this is just a result of a bad design choice I made to just use one tag mem... | 19:15 |
stekern | I should change that and have a seperate tag mem for each way | 19:16 |
olofk | Is anything set in stone, or is it just a matter of reimplementing it? | 19:28 |
stekern | it's just an implementation detail, so 'just' reimplementing it | 19:29 |
olofk | Which kernel repo is in best shape? Is upstream usable for single core | 19:29 |
olofk | Yeah, I considered putting '' around just :) | 19:29 |
stekern | but I think I'll work-around it for a quick fix right now. but it makes me changing that a bit more high prio. | 19:31 |
stekern | upstream kernel is almost usable | 19:32 |
stekern | there are a couple of bug-fixing patches that hasn't made it there though... | 19:34 |
stekern | I keep them around in my smp branch, and afaik that should be in pretty good shape | 19:35 |
olofk | github or openrisc.net? | 19:35 |
olofk | found i | 19:37 |
olofk | t | 19:38 |
olofk | ah crap... pushed to the wrong branch again | 20:42 |
stekern | =P | 20:46 |
stekern | at least this smp setup is a lot more stable after I added the refill abortion on snoop hits | 20:47 |
stekern | it always crashed ~1 minute of running the gcc execute regression tests | 20:48 |
stekern | before | 20:48 |
stekern | now it's been running for 10 minutes already | 20:48 |
poke53281 | Great worl. 10 minutes is already fantastic. But that means, that the next problems will be harder to find. | 21:30 |
poke53281 | Are you sure, that the kernel is not the problem? At the moment you seem to have two construction sites and both of them could be responsible. | 21:44 |
--- Log closed Tue Aug 26 00:00:23 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!