Quoting Steve Reinhardt ste...@gmail.com:
On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt ste...@gmail.com wrote:
I think there are two possible solutions:
1. Add a retry response code for atomic requests (along the lines of
the error codes we alrady have in packet.hh) and then make sure that
On Thu, Mar 5, 2009 at 6:33 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com:
On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt ste...@gmail.com wrote:
I think there are two possible solutions:
1. Add a retry response code for atomic requests
Quoting Steve Reinhardt ste...@gmail.com:
On Thu, Mar 5, 2009 at 6:33 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com:
On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt ste...@gmail.com wrote:
I think there are two possible solutions:
1. Add a
Here's another option: make the CPU model smart and when it sees a
lock access have it keep running until it sees an unlock access.
This might not be too bad if keep running could be implemented
simply by doing something like a recursive tail call to tick().
Steve
Here's another option: make the CPU model smart and when it sees a
lock access have it keep running until it sees an unlock access.
This might not be too bad if keep running could be implemented
simply by doing something like a recursive tail call to tick().
There's already a big loop in the
On Thu, Mar 5, 2009 at 7:40 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
I like that option the best so far. I'll assume that's what we're
doing unless I suddenly think of a compelling reason not to or if
someone doesn't like it.
Great... it should be even easier than I thought if
On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt ste...@gmail.com wrote:
I think there are two possible solutions:
1. Add a retry response code for atomic requests (along the lines of
the error codes we alrady have in packet.hh) and then make sure that
all the places where we issue atomic
With a few hacks that will need to be sorted out at some point, I've
pretty much got an SMP kernel booting. One problem I just diagnosed was
that the lock prefix is not honored, and amazingly, two atomic
operations manipulating the same lock lined up on top of each other
exactly. I think
