Re: [Gems-users] Naked checkpoints creation on 64-bit machines

[Xiongfei Liao <xiongfei.liao@xxxxxxxxx>]

Hi, guys,

Thanks for your information, finally I got the naked_check_create.sh running. I managed to get an AMD machine and installed GCC 3.4.6 using root account in order to save modifying many configurations.

When the checkpoints creation process is going, the outputs on the console is like the following. There is an "xterm" windows which also displays some information. But one CPU of my machine is very busy.

Does this mean that the creation process is going well?

Regards,
Xiongfei

=========================================================================
  +----------------+    Copyright 1998-2005 by Virtutech, All Rights Reserved
  |   Virtutech    |    Version: simics-2.2.19
  |     Simics     |    Compiled: Tue Aug 16 20:23:17 CEST 2005
  +----------------+
    www.simics.com      "Virtutech" and "Simics" are trademarks of Virtutech AB

Type 'copyright' for details on copyright.
Type 'license' for details on warranty, copying, etc.
Type 'readme' for further information about this version.
Type 'help help' for info on the on-line documentation.

Using CD-ROM image file: /home/liao0016/software_backup/opensolaris/sol-nv-b104-sparc-dvd-iso-a
setting media file-cd25B_2_6
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
CRAFF warning: File was not closed cleanly; may be corrupted
[qlc24B_2 info] Disk registering: Loop id: 0x3
[qlc24B_2 info] Disk registering: Loop id: 0xc
[qlc24B_2 info] Disk registering: Loop id: 0xd
[qlc24B_2 info] Disk registering: Loop id: 0xe
[qlc24B_2 info] Disk registering: Loop id: 0xf
[qlc24B_2 info] Disk registering: Loop id: 0x10
[qlc24B_2 info] Disk registering: Loop id: 0x11
[qlc24B_2 info] Disk registering: Loop id: 0x12
[qlc24B_2 info] Disk registering: Loop id: 0x13
[qlc24B_2 info] Disk registering: Loop id: 0x14
[qlc28B_2 info] Disk registering: Loop id: 0x3
[qlc24B_2 info] Disk registering: Loop id: 0x4
[qlc28B_2 info] Disk registering: Loop id: 0x4
[qlc28B_2 info] Disk registering: Loop id: 0x5
[qlc28B_2 info] Disk registering: Loop id: 0x6
[qlc28B_2 info] Disk registering: Loop id: 0x7
[qlc28B_2 info] Disk registering: Loop id: 0x8
[qlc24B_2 info] Disk registering: Loop id: 0x2
[qlc28B_2 info] Disk registering: Loop id: 0x9
[qlc28B_2 info] Disk registering: Loop id: 0xa
[qlc28B_2 info] Disk registering: Loop id: 0xb
[qlc28B_2 info] Disk registering: Loop id: 0xc
[qlc28B_2 info] Disk registering: Loop id: 0xd
[qlc24B_2 info] Disk registering: Loop id: 0x5
[qlc28B_2 info] Disk registering: Loop id: 0xe
[qlc28B_2 info] Disk registering: Loop id: 0xf
[qlc28B_2 info] Disk registering: Loop id: 0x10
[qlc28B_2 info] Disk registering: Loop id: 0x11
[qlc28B_2 info] Disk registering: Loop id: 0x12
[qlc28B_2 info] Disk registering: Loop id: 0x13
[qlc28B_2 info] Disk registering: Loop id: 0x14
[qlc28B_2 info] Disk registering: Loop id: 0x15
[qlc24B_2 info] Disk registering: Loop id: 0x6
[qlc24B_2 info] Disk registering: Loop id: 0x7
[qlc24B_2 info] Disk registering: Loop id: 0x8
[qlc24B_2 info] Disk registering: Loop id: 0x9
[qlc24B_2 info] Disk registering: Loop id: 0xa
[qlc24B_2 info] Disk registering: Loop id: 0xb
New VTOC written to disk:

             Label : SIMDISK cyl 10938 alt 2 hd 19 sec 80
               RPM : 7200
    Data cylinders : 10938
     Alt cylinders : 2
Physical cylinders : 10940
             Heads : 19
 Sectors per Track : 80

  Number of data blocks : 16625760

Partition Table:
Number   Tag             Flag                 Start        End       Size
  2      5 (backup)      1 (unmountable)          0   16625759   16625760

Capturing output to 'install-log.txt'
Image memory limited to 8 G
Start at : Sat Feb  7 11:51:21 2009
[system info] Disabling slave processors.
=========================================================================

On Sat, Feb 7, 2009 at 1:41 AM, Stamatis Kavadias <kavadias@xxxxxxxxxxxx> wrote:

Hello Xiongfei,

    I have not used GEMS scripts for checkpointing booted Solaris on Serengeti
(is that what naked checkpoints are?), but I am using Solaris (10) on Serengeti
and have taken checkpoints using some of the scripts provided in an earlier
Simics version (2.2.19) and later a script I found in Simics mailing list
(https://www.simics.net/mwf/topic_show.pl?tid=9375) for large
configurations (>24 processors) of the Serengeti target. So I assume that
yes, using gcc-3.4.6 to compile GEMS you will be able to take checkpoints.
I have created checkpoints on both Intel core2 and ADM (Opteron I think)
64-bit CPU hosts.

Regards,

Stamatis

PS: I have used GEMS versions 2.0 and 2.1 for the above.

Subject:

Re: [Gems-users] Simics 4.0 for GEMS?

From:

Xiongfei Liao <xiongfei.liao@xxxxxxxxx>

Date:

Wed, 4 Feb 2009 10:11:24 +0800

To:

Gems Users <gems-users@xxxxxxxxxxx>

To:

Gems Users <gems-users@xxxxxxxxxxx>

Hi, Stamatis,

Does your configuration work well with the creation of naked checkpoints?

I failed with gcc3.4.1 with both Intel and AMD 64-bit processors.

Regards,
Xiongfei

On Wed, Feb 4, 2009 at 9:02 AM, Stamatis Kavadias <kavadias@xxxxxxxxxxxx> wrote:

Hello all,

    If it's any help to anyone, I have been using GEMS with simics 3 on both Intel and AMD 64-bit
processors, compiling GEMS with gcc 3.4.6.
    This solved the problem of instantiating opal (tested on AMD) and I never had problems with
memory allocation and Ruby in general. (Note: I have not used Opal thereafter so no guaranties...).


Regards,

Stamatis

Subject:

Re: [Gems-users] Simics 4.0 for GEMS?

From:

Dan Gibson <degibson@xxxxxxxx>

Date:

Mon, 2 Feb 2009 11:52:27 -0600

To:

Gems Users <gems-users@xxxxxxxxxxx>

To:

Gems Users <gems-users@xxxxxxxxxxx>

On Mon, Feb 2, 2009 at 11:48 AM, Greg Byrd <gbyrd@xxxxxxxx> wrote:

I spoke up this time because I didn't want the GEMS
community to think that everyone is using Simics 3.x at this
point.

I also will mention that we at Wisconsin are all still using Simics 2.x internally.
 

...Greg

Dan Gibson wrote:
> Greg (+list),
> The compiler version issue is a really, really difficult problem. We
> have seen this problem at various times, on the list and internally, and
> we invariably get the same response from Virtutech: Upgrade.
>
> My current theory on this is that Simics 2.x (or 3.x) is compiled
> against ABI x, GEMS is compiled to ABI y according to the setup of the
> host machine, and both GEMS and Simics end up /using/ ABI z at runtime,
> where in general x!=z and y!=z (though usually y==z). Hence, (at least)
> two flavors of libc interact, and eventually the heap gets smashed.
> Unfortunately, I don't know why it works for some folks and not for
> others -- memory corruption is a pretty subtle problem as you know.
>
> So why not upgrade? There is no short answer, so here's the long one.
> 1) GEMS-users (including ourselves) have a lot of scripts that are not
> forward compatible (though checkpoints ARE from 2.x to 3.x).
> 2) We have had some indication that GEMS+Simics2 is faster than
> GEMS+Simics3 for some workloads
> 3) Upgrading is a big pain and we don't have a lot of free graduate
> students available to make the change
> 4) Changing Simics version has the nasty side effect of changing
> results... and no one wants to admit mid-thesis that results are
> sensitive to something like that.
>
> However, as I said in my earlier post, we are looking into Simics 4.0
> compatibility for GEMS right now. It will not be available for use in
> classes this semester. In fact, from my 'experience' in porting GEMS to
> 3.0, I won't guarantee it'll /ever/ be available. But, we're looking
> into it and we request and appreciate patience from our user community.
>
> Regards,
> Dan
>

> On Mon, Feb 2, 2009 at 11:18 AM, Greg Byrd <gbyrd@xxxxxxxx

> <mailto:gbyrd@xxxxxxxx>> wrote:
>

>     For the record, I have not been able to get GEMS to work
>     "just fine" with Simics 3.x.  The main issue is the versions
>     of compilers used to compile and link GEMS vs. what's used
>     for Simics.
>
>     I know others have had success, but my experience has not
>     been good.  I was hoping to make the move to 3.0 for my
>     class this semester, but I ended up sticking with 2.x.
>
>     So I'm unhappy to see 2.x go away, but I understand why and
>     hopefully will figure out a way to work around it.
>
>     ...Greg
>
>     PS.  I found the right mix of compilers to get everything to
>     link, but then ruby0.init crashes immediately with a bad
>     address passed to free().  If anyone has seen similar
>     behavior and figured out a fix, let me know.  I'm somewhat
>     constrained by a university computing environment that's
>     largely out of my control, so please don't send me fixes
>     like "reinstall Linux with this patch."
>
>
>
>     Abdullah Kayi wrote:
>      > Hi Dan,
>      >
>      > FYI, Virtutech already suspended new Simics 2.x licenses. However, as
>      > you mentioned Simics 3.x works fine with GEMS, the only problem
>     would be
>      > the checkpoint scripts.
>      >
>      > Regards,
>      >
>      > AK
>      >
>      > On 2/2/09 11:52 AM, "Dan Gibson" <degibson@xxxxxxxx

>     <mailto:degibson@xxxxxxxx>> wrote:
>      >
>      >     Hi,
>      >
>      >     We're working internally on Simics 4.0 compatibility and testing
>      >     right now. As with a lot of these graduate-student driven
>      >     projects... its a slow process.
>      >
>      >     The good news is that there is no real rush for current GEMS
>     users
>      >     to upgrade from Simics 3.0 to 4.0 on their own. There is some
>      >     concern that Virtutech may be considering suspending
>     availability of
>      >     new Simics 2.x licenses, but GEMS works with Simics 3.x already.
>      >
>      >     Regards,
>      >     Dan
>      >
>      >     On Mon, Feb 2, 2009 at 10:46 AM, Yangchun Luo

>     <yluo@xxxxxxxxxx <mailto:yluo@xxxxxxxxxx>> wrote:
>      >
>      >         Hi,
>      >
>      >         Since Simics 4.0 is released by Virtutech, I wonder if it is
>      >         also compatible with GEMS 2.1?
>      >         And how urgent is it for GEMS users to upgrade from
>     Simics 3.0.x
>      >         to 4.0?
>      >
>      >         Thanks!
>      >
>      >         _______________________________________________

>      >         Gems-users mailing list

>      >         Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>

>      >         https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>      >         Use Google to search the GEMS Users mailing list by adding
>      >         "site:https://lists.cs.wisc.edu/archive/gems-users/" to
>     your search.
>      >
>      >
>      >
>      >
>      >
>      >

>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Gems-users mailing list

>      > Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>

>      > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>      > Use Google to search the GEMS Users mailing list by adding
>     "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>      >
>
>
>     _______________________________________________
>     Gems-users mailing list

>     Gems-users@xxxxxxxxxxx <mailto:Gems-users@xxxxxxxxxxx>

>     https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>     Use Google to search the GEMS Users mailing list by adding
>     "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>
>
>
>

> --
> http://www.cs.wisc.edu/~gibson [esc]:wq!
>
>

> ------------------------------------------------------------------------

>
> _______________________________________________

> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>


_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

--

http://www.cs.wisc.edu/~gibson [esc]:wq!

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

---

Subject:

[Gems-users] Naked checkpoints creation on 64-bit machines

From:

Xiongfei Liao <xiongfei.liao@xxxxxxxxx>

Date:

Thu, 5 Feb 2009 21:55:07 +0800

To:

Gems Users <gems-users@xxxxxxxxxxx>

To:

Gems Users <gems-users@xxxxxxxxxxx>

Hi, GEMS users,

Did anyone even create the naked checkpoints successfully on Intel or AMD 64 CPUs? If yes, what kind of configuration was used?

Thanks a lot.

Best regards,
Xiongfei

---

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.