I almost have a set of CLs which fix the stats, but it looks like since I
started working on this somebody broke them again. I'll now need to figure
out where (fortunately a small window) and add a CL for that too.

I'd like to fix the regression script on zizzer, but I don't have
permissions to remove (or move) the old hg repository, and likely don't
have permissions to edit the script itself. The change should be fairly
easy. Could somebody either go in and make that change, or make it so I
can, or tell me how I can already but just don't realize it?

Gabe

On Sat, Apr 1, 2017 at 8:43 AM, Jason Lowe-Power <ja...@lowepower.com>
wrote:

> Hi Gabe,
>
> I think you've interpreted everything correctly. I think the only context
> you're missing is that we're planning to change the regressions such that
> there is no dependence on proprietary binaries. This will allow all
> users/developers to run the regressions before committing code. We haven't
> made any progress in this direction, yet. We've just talked about it.
>
> I think the biggest implication of this is that we'd drop the SPARC full
> system tests completely. This also means we'd drop the EIO tests (which I
> think we already have).
>
> Slightly off topic:
> One of my biggest gripes with the current regressions is that it is
> incredibly hard for a user or a developer who commits code every once in a
> while to run and understand the regression output. It's a good step for you
> to be able to find the fishy stats changes and pin them to a commit, but I
> really wish it was easier for our users to do that themselves.
>
> Cheers,
> Jason
>
> On Sat, Apr 1, 2017 at 6:27 AM Gabe Black <gabebl...@google.com> wrote:
>
> > Hi folks. I'm working through the nightly regressions to get them to a
> good
> > point for a rebase of our internal branch of gem5, and I've noticed a few
> > things:
> >
> > 1. The stats have been changed but not updated a bunch of times. I've
> > identified almost all the points this has happened since the references
> > were last updated, and have patches which fix them. Some stat changes
> are a
> > little fishy, but I'll at least identify the guilty change(s) so that
> their
> > authors can look them over.
> > 2. The SPARC FS regression were just plain not running because its
> > configuration had been broken. I'll have a patch to fix this.
> > 3. The nightly regressions are still checking gem5 out from mercurial.
> > 4. The "encumbered" repository has, as far as I can tell, not be
> converted
> > from mercurial to git. Probably this isn't a problem because this code is
> > mostly unchanging and becoming less relevant over time, especially since
> > EIO support was removed from the process classes (it was, right?).
> > 5. The EIO code is also broken, because it tries to call "fatal" with a
> > "(void)" cast in front of it in a ternary operation. Something like "foo
> ?
> > (void)fatal("a bad thing happened") : (void)fatal("a different bad thing
> > happened")". What "fatal" expands to now is apparently not compatible
> with
> > this usage. Since I can access the encumbered repository, I can attempt
> to
> > fix this.
> >
> > I can (and in at least in some cases will) fix most of these issues,
> except
> > maybe 4 if we still want encumbered to exist. Please speak up if I've
> > misinterpreted something or am missing some important bit of context.
> >
> > Gabe
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to