Re: [m5-dev] local APIC timer and bus frequency

To follow up on this, I'm using the CPU frequency divided by 16 as the "bus" frequency used by the local APIC. If anybody thinks that's unreasonable let me know. Gabe Steve Reinhardt wrote: > > > On Thu, May 22, 2008 at 11:45 AM, Gabe Black <[EMAIL PROTECTED] > > wrote

Re: [m5-dev] regression

Hopefully not. I'd say it's unlikely but I definitely wouldn't say it's impossible. For that few of instructions it might be fstat or something like that passing through some host state which changes execution in the guest slightly. I think I had problems with parser behaving strangely before as we

Re: [m5-dev] Test Repository

> I don't think it's too much to ask for someone to manually run update- > stable.sh every few weeks, especially if there is an automated script > that is reminding them that there are candidate revisions for moving > to stable available. Maybe we can have the regression tests add to some set of l

Re: [m5-dev] Test Repository

> Unless you get the patch committed to mercurial, it would be kind of > annoying to have to manually muck with the mercurial code after each > revision. A hook I'm ok with, but I don't really like the idea of gobs > of additional changesets that just slow down mercurial operations. There are also

[m5-dev] regression

I ran a full regression of the new tree manually. The only thing that reported a difference was x86/parser. That particular benchmarks seems to change it stats by 20 instructions kind of frequently. There must be some uninitialized state or something about 32bit vs 64bit compiles? Ali _

Re: [m5-dev] Test Repository

On Jun 7, 2008, at 6:02 PM, nathan binkert wrote: >> Another reason to have separate repos instead of just tagging if >> we're >> going to do stuff at this rate is that each retagging generates a new >> changeset. Pulling from a repo named x to a repo named y doesn't. > I'm not sure if this bot

Re: [m5-dev] Test Repository

On Jun 7, 2008, at 5:59 PM, nathan binkert wrote: >> I just look a quick look at the hg webserver code. There isn't a >> direct way to download a revision. We could add one, or we could go >> back to my original suggestion that we have m5-stable and m5-dev and >> just pull to m5-stable at whateve

Re: [m5-dev] Test Repository

> Another reason to have separate repos instead of just tagging if we're > going to do stuff at this rate is that each retagging generates a new > changeset. Pulling from a repo named x to a repo named y doesn't. I'm not sure if this bothers me. I guess it makes the history really verbose. If sta

Re: [m5-dev] Test Repository

> I just look a quick look at the hg webserver code. There isn't a > direct way to download a revision. We could add one, or we could go > back to my original suggestion that we have m5-stable and m5-dev and > just pull to m5-stable at whatever interval. I even wrote a script to > spam m5-dev if mo

Re: [m5-dev] Test Repository

On Jun 7, 2008, at 5:52 PM, Ali Saidi wrote: > > On Jun 7, 2008, at 5:44 PM, nathan binkert wrote: > >>> Aren't these statements contradictory? If you have the patch sets >>> under separate subdirs, can they come from different repos? Would >>> you >>> still have to manually merge the series fi

Re: [m5-dev] Test Repository

On Jun 7, 2008, at 5:44 PM, nathan binkert wrote: >> Aren't these statements contradictory? If you have the patch sets >> under separate subdirs, can they come from different repos? Would >> you >> still have to manually merge the series file? I don't totally blame >> Gabe for having the wil

Re: [m5-dev] Test Repository

> Aren't these statements contradictory? If you have the patch sets > under separate subdirs, can they come from different repos? Would you > still have to manually merge the series file? I don't totally blame > Gabe for having the willies about this. Yeah, it sorta gives me the willies too. Ma

Re: [m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

> I'm not really concerned if it catches all the exceptions. I guess I > would rather have it say it's unknown, instead raising an exception > that doesn't really matter all that much. I guess I won't fight you on that. Seems that it might be nice to at least print the error and let it continue.

Re: [m5-dev] Test Repository

Sort of a multi-reply here... On Sat, Jun 7, 2008 at 11:36 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: > > To jump in here, the thing is we're not finding these bugs. Saying > there needs to be 3 months of testing before we release something > marked "stable" only works if its likely that the people

Re: [m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

I'm not really concerned if it catches all the exceptions. I guess I would rather have it say it's unknown, instead raising an exception that doesn't really matter all that much. Ali On Jun 7, 2008, at 4:19 PM, nathan binkert wrote: > How about this? (I didn't actually run it). I just worry

Re: [m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

How about this? (I didn't actually run it). I just worry that you catch all exceptions. There might be some sort of bug lurking in there that we want to know about. def hgInfo(self, target, source, env): def gen_file(target, rev="Unknown", node="Unknown", date="Unknown"): hg_stats =

[m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

# HG changeset patch # User Ali Saidi <[EMAIL PROTECTED]> # Date 1212868517 14400 # Node ID 77d1b5e0c9e10b02da7ff6ace10f8d26a3b217c1 # Parent 4065e07a979e949db256b6afb0f57fbff659788f HG: Add compiled hg revision and date to the standard M5 output. diff --git a/src/SConscript b/src/SConscript ---

Re: [m5-dev] Test Repository

> I was just going to use that same evidence to argue the opposite... > the fact that beta5 is 3 months old and we're still finding > significant bugs (including the assertion violation that Sujay posted > about yesterday, which coincidentally Brad had just run into as well) > says to me that we do

Re: [m5-dev] Test Repository

The problem I have with as set of patches is that someone then has to go an get M5 and get this set of patches and apply them. It just raises the barrier to entry even more. Ali On Jun 7, 2008, at 3:09 PM, Gabe Black wrote: > This sounds to me like we're reinventing mercurial with MQ in orde

Re: [m5-dev] Test Repository

This sounds to me like we're reinventing mercurial with MQ in order to avoid having two repositories, which we don't technically need to have in the first place, which does not sound like a great idea. Maybe we just have a set of patches for stable that are critical bug fixes, but stable is just an

Re: [m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

On Jun 7, 2008, at 12:31 PM, nathan binkert wrote: > Couple of comments. > > >> +# Generate hginfo.cc >> +# Anything we pass as a source gets setup as a dependence so >> rather than >> +# passing the SConscript/hg dir/etc we just squirrel away the >> SConstruct >> +# directory in the enviro

Re: [m5-dev] Test Repository

On Jun 7, 2008, at 2:09 PM, Steve Reinhardt wrote: >> My biggest worry about 3-6 months is that we often have fixes that >> are >> important and more recent than 3-6 months. Beta 5 is barely three >> months old and has at least two important patches, right? > > I was just going to use that sam

Re: [m5-dev] Test Repository

> My biggest worry about 3-6 months is that we often have fixes that are > important and more recent than 3-6 months. Beta 5 is barely three > months old and has at least two important patches, right? I was just going to use that same evidence to argue the opposite... the fact that beta5 is 3 mon

Re: [m5-dev] Test Repository

> So what do you consider all the -rcN Linux releases? > > Maybe you misinterpreted my comment... I'm really talking about > distinguishing stable vs development revs, not maintaining separate > repos, as the rest of my email made clear. I think I was just coming from the opposite side. I probably

Re: [m5-dev] Test Repository

On Sat, Jun 7, 2008 at 9:49 AM, nathan binkert <[EMAIL PROTECTED]> wrote: >> Just another thought on this... although in an ideal world everyone >> would test their code thoroughly before pushing it, we know that >> doesn't always happen. I think we do need to distinguish at least two >> levels of

Re: [m5-dev] Test Repository

> Just another thought on this... although in an ideal world everyone > would test their code thoroughly before pushing it, we know that > doesn't always happen. I think we do need to distinguish at least two > levels of stability; the version that most external people use that's > been tested hea

Re: [m5-dev] Test Repository

On Sat, May 31, 2008 at 2:39 PM, Ali Saidi <[EMAIL PROTECTED]> wrote: > >> I'm not the expert on how this stuff works but I could see the benefit >> to a "stable" version of things and a "developmental" version. Or >> maybe, whatever release is the most recent is considered "stable" > > It's a

Re: [m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output

Couple of comments. > +# Generate hginfo.cc > +# Anything we pass as a source gets setup as a dependence so rather than > +# passing the SConscript/hg dir/etc we just squirrel away the SConstruct > +# directory in the environment and retrieve it later. This seems to > +# be the only reliable w

[m5-dev] Cron <[EMAIL PROTECTED]> /z/m5/regression/do-regression quick

* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha