> To get back to this original problem (which I just ran into myself,
> making me pay more attention to this thread...): do we really need a
> separate enums package? It seems pretty unlikely you'll ever want the
> enums without the params, and while you might be able to use some
> params without
I don't have any real comments other than to say that this seems like
a pretty good idea. Another thing to add to the list is callpal
emulation in SE mode. This is mostly for system calls, but there are
a couple of other pal calls that are emulated.
Nate
On Tue, Sep 21, 2010 at 9:02 PM, Gabri
I can do it quick if you want
On Wednesday, September 22, 2010, Steve Reinhardt wrote:
> On Tue, Sep 21, 2010 at 7:59 PM, nathan binkert wrote:
>>> I see that objects/__init__.py does a "from m5.internal import
>>> params", so object.params still works; if we jus
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/253/#review357
---
Ship it!
looks like what I was expecting. I wonder if we should change s
looks like a symlink to poolfs to me. Did someone do something?
I hope this isn't a sign of flakiness on the disks. There were the
fsck failures on the recent reboot.
Nate
> /dist on zizzer is empty... what's the deal with that? It's not a
> symlink and I don't see an fstab entry for it, so
> I fixed it.
do we know what happened to it?
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
It should be easy enough to measure the latency of a pause on a real
machine, but given the description and its purpose of avoiding memory
order violations, my guess is that the latency is in the 10s of ns,
possibly 100s.
That said, you should probably figure out a way to skip the function
entirel
#x27;t
> look feasible to fake, but you have more experience with these sorts of
> modifications than I do. The function or perhaps macro that has the "pause"
> in it is cpu_relax.
>
> Gabe
>
> Quoting nathan binkert :
>
>> It should be easy enough to m
> Hey, quick python simobject question. I'm thinking of creating an
> object file symobject type for various reasons, but I want to make it so
> it can still be instantiated with a string parameter. So in other words,
> I still want to be able to say process.executable = "foo", but then for
> pr
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/276/#review393
---
Ship it!
I personally don't think you need to submit diffs for stuff like
> I'm trying to factor out PAL mode from O3, and I found the following
> line
>
> http://repo.m5sim.org/m5/file/fc12f4d657f0/src/cpu/o3/fetch_impl.hh#l579
>
> } else if (interruptPending && !(fetch_PC & 0x3)) {
>
>
> which is basically making fetch stop fetching once it sees that an
> interru
> The ExecContext is only for instructions when they execute (although I'm
> not 100% sure that's all it could be used for). I thought of this
> approach, but it doesn't work because the thing that puts together the
> fetch request would have to know the actual PC. If it gets the filtered
> one lik
> How does switching in and out of PAL mode work? Could we take advantage
> of that somehow? I don't have a really good idea of how that might help.
> I'm just throwing the idea out there.
Basically, the callpal instruction is like a branch, but it also sets
the mode bit (and enables the pal shadow
> That's better from the perspective that it's not as Alpha specific, but
> still no other ISA cares about the PC in that way, we'd be carrying
> around several (as many as 4, I think) extra uint64_ts, and only one bit
> actually matters.
Could we carry around some sort of opaque ISA Flags object
> It might work to make callpal and rti SerializeAfter if they aren't
> already (or we may have to force a flush) and have them set a PAL bit in
> some control reg somewhere. Then the TLB can use that and ignore the PC.
> That would probably make those instructions perform worse, though.
I think t
> Whether there's an interrupt available is already tracked by ISA
> dependent code by the Interrupts object which lives at commit. Why does
> fetch need to know? Anything it fetches is just going to get blown away
> anyway.
The point is, you want to redirect fetch intelligently. When there is
an
> FS... I'm not really up for rebasing much, so we need to get the prefetch
> stuff handled and then I can get the latest set in and next on the list is
> the o3 stuff.
You can of course commit separately and then flip a coin to see who merges.
Nate
___
> Yes, your PC state change is still on my to-do list... I *almost* got
> to it yesterday even. Maybe this afternoon or tomorrow.
I've actually read two (of 9) pages!
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-
> Hey! I just successfully ran hello world in x86 on O3! This does NOT
> imply that x86 works generally on O3, only that it didn't choke on its
> own tongue running hello world.
That's great!
> There are apparently still some issues with
> uncommitted ARM patches I'm working through with Ali, but
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review406
---
Ship it!
Overall, I have two major comments. 1) You should get rid of pr
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/255/#review397
---
Overall, I really like the idea of this patch. My biggest concern is the
> Nilay, I apologize for the confusion here. It seems that Nate and I are
> suggesting you go in two different directions in terms of the operator<<. I
> personally wanted to get away from the operator<< overloading, so that Ruby
> objects looked more similar to most M5 objects. Especially be
One additional comment, there is no reason that the implementation of
operator<< couldn't itself use cprintf. e.g.:
iostream &
operator<<(iostream &out, const Foo &foo)
{
ccprintf(out, "<%d:%s>", foo.val, foo.name());
return out;
}
On Fri, O
> So I guess the upshot is that if there are complex Ruby types (not
> just typedefs of builtin types) that want to have standard ways of
> printing themselves out, that's kind of inconsistent with M5 right
> there :-), but if you want to keep that behavior then overloading
> operator<< is the way
> I'd still really encourage you to work on cutting out the middleman
> and find a way to go straight from raw bytes to StaticInsts via a
> cache. I really don't see any long-term benefit to doing this in two
> stages. I agree that we don't want a proliferation of code paths or
> scenarios, so on
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/278/#review407
---
Ship it!
As long as what you say is true about it no longer being used, s
> What do you mean by "given a certain prefix"? X86's encoding is fairly
> amorphous, and it's not always possible to tell early on how big an
> instruction will be. It's possible in general of course, so it depends
> on what you actually mean there. Would chasing through linked lists like
> that s
> Hmm. That's a good suggestion, but it looks like the regStats stuff is
> called from python, and my kung fu isn't strong enough to go messing
> with that stuff just for a quick hack.
Look at how global simulator stats are done. That said. Why don't
you do these stats on a per CPU basis? That
> I actually just made it a static member of the instruction and made sure it
> was only initialized once in the instruction constructor. I didn't want to
> do anything fancier because this was just a throw away measurement.
Still curious why you need to make it static. Seems like a bad choice to
> Does that mean that format specifiers used in DPRINTF() statements are just
> place holders? In not, what would be the format specifier for printing an
> object of some class that supports << operator?
No. %s passes a string in an unprocessed way, but the other format
specifiers do various os
> If we just want to insert __FILE__ and __LINE__ as part of the prefix,
> we should define a new flavor of DPRINTF that does that in the same
> header where DPRINTF itself is, and use that version as-is in SLICC.
> Maybe call it DPRINTFL?
Which __FILE__ and __LINE__ are getting inserted? Somethi
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review420
---
Looking much better.
There are two main questions:
1) Do we want Ruby to p
> I would prefer not to have the .sm DPRINTF calls look exactly like the c++
> calls. In particular, it seems unecessary to specify the trace flag
> "RubySlicc" at every DPRINTF statement. I don't think we'll ever need more
> than one trace flag for the .sm debug statements. We've never neede
> I have a general question. How do you maintain multiple uncommitted patches?
> Suppose you are working on two or more different features / changes that
> would be committed separately. How do you maintain these different changes
> till they are committed (sounds like a transaction)? Do you make a
> GEMS has supported multiple filter strings ever since I can remember and one
> could have added the ability to use multiple filter strings to .sm debug
> statements in the past, but there has never been the need to. It just seems
> redundant to explicitly specify the debug string and the .sm
> Nate, the idea behind this set of changes is to do away with the debug
> support (including DEBUG_EXPR) provided by Ruby. Deciding whether given
> volume of debug output is too verbose or not will vary from situation to
> situation. Since M5 does not have a verbosity level, it is better not to
>
Hi Gabe,
The EIO stuff is broken with your PC change. It doesn't compile.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
> Make sure you pull that repo. I committed a change to it too (or at least
> think I did).
Yes, you did. I don't know what I was thinking. My bad.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
> I'm currently trying to leverage a Python script and McPAT to consume M5
> statistics (stats.txt) and calculate power estimates for a simulated system.
> Stats variables in the SimObjects are lowerCamelCase according to the
> coding style, but it looks like the names output to the stats.txt fi
Hi Stephen,
We've made a bunch of changes to m5-dev and now arm_extras doesn't
compile. I have several fixes that will make it work with m5-dev
again. Is there a repository where they should go?
Should we revisit adding arm to m5 proper?
Nate
___
m
# HG changeset patch
# User Nathan Binkert <[EMAIL PROTECTED]>
# Date 1224856285 25200
# Node ID b9ee37f0220800243dcff7076f808891d251b623
# Parent 98224505352a1935c321a702863140ffe0ff6848
output: Change default output directory and files
diff --git a/src/python/m5/main.py b/src/python/m5/m
Ok, I've brought this up a couple of times before, but now it's really coming
The two diffs change some of the default names.
The new default output directory will be 'm5out' instead of '.'
The new stats output will be 'stats.txt' instead of 'm5stats.txt'
The new config output will be 'config' ins
# HG changeset patch
# User Nathan Binkert <[EMAIL PROTECTED]>
# Date 1224856286 25200
# Node ID e09c768051f61628082682cc68390a297cc579c9
# Parent aba4b2c01db12abcc9c701b8fc896f82a3852c0a
SCons: Allow top level directory of EXTRAS able to contain SConscripts.
The current EXTRAS will fail
Right now, there is a bunch of machinery in the simulator to allow us
to serialize events, but in reality, there's only one event that's
serialized, and I believe that it's not too hard to make it so that
doesn't happen.
Any objections to me whacking all of the code that does that?
Nate
___
at seems a lot like
> what is going on at the moment within the serialization code.
>
> The etherlink is a perfect case why the serialization is nice. Without
> it one side of the link would have to track and serialize each packet
> that is in flight.
>
> Ali
>
> On Oct
I figured out what I need to do to make the regression suite more
easily extensible. Yell at me if I don't actually do something to fix
it within a week.
Nate
On Tue, Nov 4, 2008 at 1:44 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
> ...and make a regression that catches the problem in the future.
changeset df9253dd6b4d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=df9253dd6b4d
description:
Fix a few more places where the context stuff wasn't changed
diffstat:
0 files changed
diffs (24 lines):
diff -r c9056088f151 -r df9253dd6b4d src/arch/sparc/ua2005.cc
---
I'm trying to understand exactly how these should be used. Are they
intended to be used entirely internally to an interconnect? i.e. just
within the bus or crossbar or mesh or whatever? I want a source and
destination for my crossbar model, but I don't want to break things.
I'm slightly confused
dcast should be a true
broadcast?
Nate
On Wed, Nov 5, 2008 at 5:39 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
> I'm trying to understand exactly how these should be used. Are they
> intended to be used entirely internally to an interconnect? i.e. just
> within the bus
> Yea, Ali's got it right... the way to think about address-based
> routing on the bus is that the packet logically does get broadcast to
> determine the destination; all our mucking with address ranges is
> really just some combination of optimization and sanity check.
I buy that, but I'd argue th
> However, the question is: when we move to interconnects that decouple
> these two things, what entity becomes responsible for mapping
> addresses to destinations? There must be some logic or a routing
> table that uses the address to generate a destination ID. Without
> having given it a ton of
So, Packet and Request have lots of functions called getFoo and
setFoo. That sort of style has always annoyed me because it requires
a lot of extra typing and space. e.g.
/// Accessor function for the destination index of the packet.
short getDest() const { assert(destValid); return d
> This is a bug, though it causes neither crashes nor functional
> misbehavior. The bug is that a class deriving from both RefCounted and
> FastAlloc steals memory away from the FastAlloc system. The delete
> operator called by RefCounted is NOT the overloaded one that FastAlloc
> uses, so the bloc
It would seem to me that get should automatically do that
for you. I.e., it should grab the size of memory that it's got and
then give you the size that you need.
Nate
On Sat, Nov 8, 2008 at 6:02 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote:
> Just looking at this code, can we put a more gene
;t fit in a uint64_t?
>
> Also more generally in the current code, if the underlying data pointer
> in the packet isn't aligned properly to be cast and dereferenced as a
> "T" on systems that care (so not x86), then this code will blow up.
>
> nathan binkert wrote:
>
Aweseome. My concern is that the read/write functions are getting
long and hard to read. Is there anything that makes sense to break
out into a second function? (i.e. the actual unaligned handling part?
Maybe a readUnaligned and writeUnaligned function with just a simple
check in read/write to
>> - It's still the official policy that local variables are lower
>> w/underscores while class members are mixed case... sometimes I have
>> mixed feelings about that one myself but I've been trying to do a
>> better job of sticking with it.
>>
> I was actually under the impression that the unders
I want to add a virtual channel field to the Packet object. I was
trying to figure out if I should just have a different real port for
each virtual channel, but I came to the conclusion that it just
doesn't work very well. Basically what you end up with is a mess in
python when you're trying to c
+ *
+ * Authors: Nathan Binkert
+ */
+
+#ifndef __BASE_CAST_HH__
+#define __BASE_CAST_HH__
+
+#include
+
+// This is designed for situations where we have a pointer to a base
+// type, but in all cases when we cast it to a derived type, we know
+// by construction that it should work correctly.
+
+#i
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Authors: Nathan Binkert
+ */
+
+#ifndef __BASE_FLAGS_HH__
+#define __BASE_
changeset a88e8e7dec75 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a88e8e7dec75
description:
style: clean up the Packet stuff
diffstat:
3 files changed, 24 insertions(+), 32 deletions(-)
src/mem/packet.cc |1
src/mem/packet.hh |1
src/mem/request.hh | 54
changeset 426510e758ad in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=426510e758ad
description:
mem: update stuff for changes to Packet and Request
diffstat:
4 files changed, 1 insertion(+), 8 deletions(-)
src/arch/alpha/faults.hh |2 +-
src/arch/alpha/isa
changeset 6ea35903c420 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6ea35903c420
description:
python: Fix the reference counting for python events placed on the
eventq.
We need to add a reference when an object is put on the C++ queue, and
remove
a re
changeset 27c1d1048c65 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=27c1d1048c65
description:
clean: Move some stuff from the hh file to the cc file.
diffstat:
2 files changed, 11 insertions(+), 2 deletions(-)
src/sim/serialize.cc |9 +
src/sim/serialize.h
changeset 983b71bfc1bd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=983b71bfc1bd
description:
Clean up the SimpleTimingPort class a little bit.
Move the constructor into the .cc file and get rid of the typedef for
SendEvent.
diffstat:
2 files changed,
changeset 323dac95e72c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=323dac95e72c
description:
pseudo inst: Add rpns (read processor nanoseconds) instruction.
This instruction basically returns the number of nanoseconds that the
CPU
has been running.
d
changeset 828a8296270e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=828a8296270e
description:
SCons: Allow top level directory of EXTRAS able to contain SConscripts.
The current EXTRAS will fail if the top level directory pointed to by
EXTRAS
has a SCo
will assert in debug mode, but do a static_cast otherwise.
Nate
On Mon, Nov 10, 2008 at 6:49 PM, Nathan Binkert <[EMAIL PROTECTED]> wrote:
> changeset 83cc5483a8da in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node=83cc5483a8da
> description:
>safe_cast:
asses instead of globals.
Nate
On Mon, Nov 10, 2008 at 6:49 PM, Nathan Binkert <[EMAIL PROTECTED]> wrote:
> changeset a88e8e7dec75 in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node=a88e8e7dec75
> description:
>style: clean up the Packet stuff
&g
This happened to me when I recompiled the other day. I'm assuming
that it has something to do with what lisa did. Does the build dir
just need to be deleted or something?
Nate
On Wed, Nov 12, 2008 at 12:37 AM, Cron Daemon
<[EMAIL PROTECTED]> wrote:
> * do-regression: qsub timed out, retry
. I don't know if that's what you're seeing.
>
> Gabe
>
> nathan binkert wrote:
>> This happened to me when I recompiled the other day. I'm assuming
>> that it has something to do with what lisa did. Does the build dir
>> just need to be delete
STATIC_DATA|DYNAMIC_DATA));
> -} else {
> -flags.set(DYNAMIC_DATA|ARRAY_DATA);
> -data = new uint8_t[getSize()];
> -}
> +if (data)
> +return;
> +assert(flags.none(STATIC_DATA));
> + flags.set(DYNAMIC_
--
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nathan
>> binkert
>> Sent: Wednesday, November 12, 2008 4:42 PM
>> To: Beckmann, Brad
>> Cc: M5 Developer List
>> Subject: Re: [m5-dev] changeset in m5: style: clean up the Packet
> stuff
>&
> Isn't the assertion backwards? Looks to me that if data is nonzero
> you're asserting that neither STATIC_DATA nor DYNAMIC_DATA is set.
> Don't you need a '!' in that assertion? Or change it to flags.any()
> or whatever the right operator is?
You're right of course. It should be flags.any().
I'm running a full set of opt regressions with these changes. I'll
take care of committing when I'm done (I'll give you credit brad :)
Nate
On Wed, Nov 12, 2008 at 8:13 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
>> Isn't the assertion backwards?
I apologize for these mistakes. I'm actually embarassed that I
committed (or even wrote in the first place) this code. I look at the
code and think that I must have been drunk.
Anyway, I've got all of these fixes and others in my tree and I'm
running a full set of opt regressions. I'll get every
changeset 6b0f8306704b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6b0f8306704b
description:
Fix a bunch of bugs I introduced when I changed the flags stuff for
packets.
I did some of the flags and assertions wrong. Thanks to Brad Beckmann
for pointin
I just ran the long regressions (quick all pass) and some of them
crash in the obreak syscall because of bogus arguments to the chunk
generator code. It is entirely possible that it's another bug caused
by me, but I'm not certain. I can't do any more hacking until later
tonight, so unless someone
is actually larger than the old one.
>
> Steve
>
> On Fri, Nov 14, 2008 at 2:18 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
>> I just ran the long regressions (quick all pass) and some of them
>> crash in the obreak syscall because of bogus arguments to the chunk
>>
This diff is OK. I'll admit that I'm surprised that it destroyed your
repository. That seems like a bug in HG actually.
Nate
On Fri, Nov 14, 2008 at 2:38 PM, Clint Smullen <[EMAIL PROTECTED]> wrote:
> # HG changeset patch
> # User Clint Smullen <[EMAIL PROTECTED]>
> # Date 1226702203 18000
>
mple; alter the names:
> +
> + Yoyodyne, Inc., hereby disclaims all copyright interest in the
> + library `Frob' (a library for tweaking knobs) written by James Random
> Hacker.
> +
> + , 1 April 1990
> + Ty Coon, President of Vice
> +
> +That&#x
Actually, our code is almost exactly the same, except you've
duplicated code and I modified stuff to remove the duplicate code. If
you want to fix yours and commit, that's fine. Otherwise, I can try
to commit mine tonight.
Nate
On Sat, Nov 15, 2008 at 8:36 AM, nathan binke
> Haha, do you mean having find call create when it needs to make a new
> file? I had considered doing that.
I actually created a couple of protected functions one for checking if
it's stdout/stderr and another to actually construct a new class from
a filename. If you want, I can just take care of
> That is a bit cleaner. I usually avoid adding any new functions if i
> can help it, is all. I'll go ahead and update my patch, but if you
> want to just commit yours, that is fine too.
I'm in the middle of some other stuff. I'd say go ahead.
>> You mean have .fo, .o and .go versions but not for
is a sample; alter the names:
> +
> + Yoyodyne, Inc., hereby disclaims all copyright interest in the
> + library `Frob' (a library for tweaking knobs) written by James Random
> Hacker.
> +
> + , 1 April 1990
> + Ty Coon, President of Vice
> +
> +That&
That's odd. I just ran it and it worked fine. The ones I just had fail are:
SPARC_SE/tests/opt/long/70.twolf/sparc/linux/simple-timing
X86_SE/tests/opt/long/20.parser/x86/linux/simple-timing
They differ in about the same way from the base stats.
Are you sure you have the right disk image?
N
to identify problem where
> it changes a little bit every now and then for no apparent reason. I'm
> not sure what would be the problem with SPARC. Did the disk image change
> recently? Which one does that regression use?
>
> Gabe
>
> nathan binkert wrote:
>> That
Though the fact that a TimingSimpleCPU test failed is a bit suspicious
since it didn't in the past and you just modified it.
Nate
On Sun, Nov 16, 2008 at 8:45 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
> My guess is that it's an uninitialized variable. My further g
Ah, so that was you. That makes sense. I seriously wonder if this or
something like it is the problem with 20.parser.
Nate
On Mon, Nov 17, 2008 at 11:11 AM, Steve Reinhardt <[EMAIL PROTECTED]> wrote:
> changeset c5447915af50 in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node
AIL PROTECTED]> wrote:
> I sort of doubt it... parser has always been a bit nondeterministic,
> where this is just a subtle and unforeseen but deterministic side
> effect of a bug fix.
>
> Steve
>
> On Mon, Nov 17, 2008 at 11:57 AM, nathan binkert <[EMAIL PROTECTED]> wrote:
&g
rser, that would go a long way to figuring out what the problem
> is.
>
> Gabe
>
> Quoting nathan binkert <[EMAIL PROTECTED]>:
>
>> I more meant that it seems like an infrequently used syscall that uses
>> an uninitilaized variable that affects the return value
gt; > little
>>> part
>>> > of that like converting it to seconds changing the path the microcode
>>> > takes
>>> for
>>> > the division instruction or something.
>>> >
>>> > Speaking of which, I think it would be
WOO!
On Sun, Nov 23, 2008 at 2:54 PM, Gabe Black <[EMAIL PROTECTED]> wrote:
> This isn't all ready to check in and I need to hook up some disks, but tada!
>
> m5 slave terminal: Terminal 0
> Linux version 2.6.22.9 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo
> 4.1.2)) #2 Mon Oct 8 13:1
Alpha's root bridge is the Tsunami stuff. You're going to need to add
the equivalent for x86. I'm not sure about how the pci devices should
be set up (other than the bios does do that for you if you want to use
what it gives you), but you might want to fix the root bridge problem
to see if that f
gt; or Intel to send me or point me to unfettered documentation on something
>>> I can emulate that would be great. I'll see what I can find online. At
>>> work I have pdfs for the hardware we're emulating, but there's no chance
>>> I'm going to use that
How about when Korey's ready, he takes a break and lets us work on the
diffs a bit before they go in the tree? Let us know when you're ready
Korey.
On Mon, Nov 24, 2008 at 5:41 PM, <[EMAIL PROTECTED]> wrote:
> There are changes in this patch that you undo in the next one like your
> modification
27;t mind
> helping to clean up some of the rough edges.
>
> Gabe
>
> Quoting nathan binkert <[EMAIL PROTECTED]>:
>
>> How about when Korey's ready, he takes a break and lets us work on the
>> diffs a bit before they go in the tree? Let us know when
Ok, what's the status now? I can dedicate some time to looking at
this now. Are the patches sent out last week the most up to date?
Nate
On Tue, Nov 25, 2008 at 3:45 PM, Gabe Black <[EMAIL PROTECTED]> wrote:
> Ok, that sounds good. I didn't look in the second patch or the first one
> very clo
what ever happened with this? Is it correct? did it make it into the tree?
On Wed, Nov 12, 2008 at 3:39 PM, Clint Smullen <[EMAIL PROTECTED]> wrote:
> # HG changeset patch
> # User Clint Smullen <[EMAIL PROTECTED]>
> # Date 1226530575 18000
> # Node ID c3e54b6bfd25aab8607a8f608fca17a4e37691a1
>
Hi Clint,
Did you get anywhere with this?
Nate
On Sun, Nov 16, 2008 at 1:23 PM, Clint Smullen <[EMAIL PROTECTED]> wrote:
> Heh, disabling this assertion has a similar result as seen in the
> fetch unit: the outstanding requests arrive at the simple CPU that
> takes over next, and it promptly d
501 - 600 of 1984 matches
Mail list logo
