On Sun, Mar 7, 2010 at 11:50 PM, Gabe Black gbl...@eecs.umich.edu wrote:
(Practically speaking, do we
support anything other than linux on any other ISA?)
Only supporting Linux doesn't mean the OS never changes. It would be
nice to be able to test both 32 and 64 bits of Linux in both FS and
My inclination is to push it a little farther in terms of abstraction
though... all we really need for a test is a command to run and a
reference output directory to check against, so do we need anything
else?
I don't think so. My intent is to actually be very generic and more
or less support
Maybe instead of (or in addition to) the numeric tags I proposed, each
test could also have an optional tuple of strings, e.g., ('quick',
'mem'), and then when you run tests you could supply a string and it
would run all the applicable tests with that tag. Sort of like hg
qselect. Of course
In general this sounds good... it seems like one issue that we're
touching on is that for many current tests we have a sparse matrix of
applicability: there are ISAs, configs (with and w/o ruby), OSes, etc.
It would be nice to specify a related set of tests concisely but it's
actually complex to
Good point... I agree, this doesn't work, the test will need to encode
the applicable ISA(s) directly. One thing this brings up is the
situation with tests like memtest, where it's independent of the ISA,
but unless you're insanely paranoid, there's no reason to run it N
times when you're
On Sunday 07 March 2010 01:32:09 am Ali wrote:
Hi Stijn,
They are just snoop requests from the access filtering through the
system. You might be able to stop them by having the CPU return
snoop=false to getDeviceAddressRanges(), but I'm not sure that the
caches have code to do that
On Mar 8, 2010, at 11:45 AM, Steve Reinhardt wrote:
In general this sounds good... it seems like one issue that we're
touching on is that for many current tests we have a sparse matrix of
applicability: there are ISAs, configs (with and w/o ruby), OSes, etc.
It would be nice to specify a
On Mar 8, 2010, at 3:50 PM, Stijn Souffriau wrote:
On Sunday 07 March 2010 01:32:09 am Ali wrote:
Hi Stijn,
They are just snoop requests from the access filtering through the
system. You might be able to stop them by having the CPU return
snoop=false to getDeviceAddressRanges(), but I'm
One thing I would like to see is a test system that can scale to maybe
~10,000 test cases. I don't want to have a SConscript (I have no idea
how long it would take SCons to parse all the files, but I'm guessing
in wouldn't be quick) for each one, and even a directory structure
seems to be
On Mon, Mar 8, 2010 at 7:34 PM, Ali Saidi sa...@umich.edu wrote:
Aborting atomicAccess completely when a writeback deadlocks results in
functional errors in the program so I have to do it like this, which
is more
efficient anyway. Can anyone foresee any simulation errors resulting
from
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
*
11 matches
Mail list logo
