[parsec-users] Errors running Parsec benchmarks in M5
cbienia at CS.Princeton.EDU
Wed Aug 19 18:01:27 EDT 2009
The same alignment rules also exist for Sparc CPUs, but the PARSEC workloads
all run fine on Sparc since at least PARSEC 2.0. On Sparc it's even
stricter, if the program performs an unaligned memory access it always
segfaults. You can go back to the archives of parsec-users and you'll see
some reports of workloads that had that issue in the original PARSEC release
(canneal, for example). It's all been fixed for a while, so I'm skeptical
that it's really an unaligned access issue in the program.
From: parsec-users-bounces at lists.cs.princeton.edu
[mailto:parsec-users-bounces at lists.cs.princeton.edu] On Behalf Of ef
Sent: Wednesday, August 19, 2009 5:41 PM
To: PARSEC Users
Subject: Re: [parsec-users] Errors running Parsec benchmarks in M5
Regarding the unaligned access I see the error can be detailed here:
The only exception to this rule is when formatting a new floppy disk. To do
this, you'll need to select the device name with the correct capacity. For
example, if the system has a 1.4MB drive, format /dev/fd0H1440 instead of
The Alpha, like all real RISC CPUs, requires that memory accesses are
naturally aligned. For example, reading a 4 byte integer from memory
requires that the address of the integer be a multiple of 4. Similarly, 8
byte integers need to start at an address that is a multiple of 8. If the
CPU attempts to access a word that is not properly aligned, the CPU will
trap into the kernel and issue a warning message. The kernel will then go
ahead and emulate the unaligned access so that the user-level process
executes as if nothing had happened (except for a substantial slow-down due
to the fault).
Typically, an unaligned fault message looks like this:
X(26738): unaligned trap at 000000012004b6f0: 00000001401b20ca 28 1
What this means is that the process executing command X (the X11 server)
with process id 26738 caused an unaligned fault accessing address
0x1401b20ca. This access was performed by the instruction located at address
0x12004b6f0. The other numbers are less important, but if you check the
kernel sources, you'll find that they tell you more info on what kind of
instruction caused the fault (e.g., a load vs. a store).
You do not need to be overly alarmed when seeing such a message. The program
causing the faults will work correctly. Eventually, all unaligned accesses
will be fixed, but in the meantime, just ignore these messages (if you're a
programmer, please take a minute and fix the source of the unaligned access
I think I can go ahead and try to mabe fix the error in the code, however I
have no clue where to start..
I can use the debugger as I have -g enabled but I dont have a true alpha
machine. Let me know if you have any ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the parsec-users