Hi, Lisa.
I have tried to run it in this way, I began without sudo and NOT as root,
and the initdev.sh asked me if I have a sudo access and I entered the
password, and then an error came up!
Is there any problem with the MAKEDEV, the error says the MAKEDEV fails to
run as root.
I built the image from the scratch because I want to run some programs I
wrote myself on M5 in full system mode. I have compiled the alpha-fs mode
and when I ran, everything seemed OK as the document says, but it just
stalled there and nothing continued. It looked like this:
*M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 10 2009 00:08:03
M5 revision Unknown:Unknown
M5 commit date Unknown
M5 started Jan 29 2009 10:25:59
M5 executing on ubuntu
command line: build/ALPHA_FS/m5.opt -d /tmp/output configs/example/fs.py
Global frequency set at 1000000000000 ticks per second
warn: kernel located at:
/media/Study/CPU/CPUsource/M5/m5-stable-733318abb7b1/dist/m5/system/binaries/vmlinux
Listening for system connection on port 3456
0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00
2009
0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000
**** REAL SIMULATION ****
warn: Entering event queue @ 0. Starting simulation...
and nothing continues, the simulator just stalls here...
*I could not find out where the problem is and I have sent a question to the
maillist but no one have encountered this.
So I decided to build an image myself, I hope it will work.
*
**
*
>
> * *I think it was a problem with the initdev.sh script - what if you run
> ptxdist images NOT as root or sudo at all? initdev.sh should ask you if
> you
> have sudo access, and just tell it yet and it will ask for your password
> from there.
>
> is there a reason you must build an image from scratch yourself?
>
> lisa
>
> On Wed, Jan 28, 2009 at 11:45 AM, Veydan Wu <[email protected]> wrote:
>
> > Hi, Lisa. Thanks for your reply.
> >
> > I have tried both ways, I ran it with sudo too but the error is the same.
> >
> > I have been working on this for several weeks and finally get to the last
> > step, that's frustrated !
> >
> >>
> >>
> >> I have a vague recollection of something like that happening. I think,
> >> for
> >> some reason, the script worked if I ran it with sudo instead of as root.
> >>
> >> I'm changing the wiki now to warn that this whole ptx-dist process is
> >> pretty
> >> deprecated and not well-supported, but if you got that far, that's
> great!
> >>
> >> Lisa
> >>
> >> On Wed, Jan 28, 2009 at 6:41 AM, Veydan Wu <[email protected]> wrote:
> >>
> >> > Hi, I used the ptxdist to create an full system image to run on M5,
> and
> >> I
> >> > have reached the last step. When I run the command * ptxdist images*,
> I
> >> > just got an error !
> >> >
> >> > The error seems simple:
> >> >
> >> > *Failed to
> >>
> run*/media/Study/CPU/CPUsource/M5/linux-dist/lib/ptxdist-0.10.3/m5_files/MAKEDEV
> >> > -d /media/Study/CPU/CPUsource/M5/linux-dist/my_workspace/root/dev
> >> console
> >> > random urandom null hda hdb hdc hdd sda* as root*
> >> >
> >> > but the problem is I run the command under root
> >> >
> >> > r...@ubuntu:/media/Study/CPU/CPUsource/M5/linux-dist/my_workspace#
> >> ptxdist
> >> > images
> >> >
> >> > Does anyone encounter such an problem yet? I have absolutely no idea
> now
> >> !
> >> >
> >> >
> >> > _______________________________________________
> >> > m5-users mailing list
> >> > [email protected]
> >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
> >>
> http://m5sim.org/cgi-bin/mailman/private/m5-users/attachments/20090128/e12c7d01/attachment.htm
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> m5-users mailing list
> >> [email protected]
> >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >>
> >> End of m5-users Digest, Vol 30, Issue 25
> >> ****************************************
> >>
> >
> >
> > _______________________________________________
> > m5-users mailing list
> > [email protected]
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://m5sim.org/cgi-bin/mailman/private/m5-users/attachments/20090128/f29af26b/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Wed, 28 Jan 2009 19:39:49 +0100
> From: Angela Carlsson <[email protected]>
> Subject: Re: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
> implemention
> To: <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hello Clint, thanks for your answer and for your advice of using the
> priority as a way to identify the cores, it is a good idea.
>
> I hope you can help me. I have been looking through the code about the
> policies trying to do what I am looking for, but the code is a little
> complex. Do you know if FCFS serves the first command that finds in the
> biu?. The reason to ask this, is that reordering the biu according to my
> policy is very simple, I am thinking that if I can reorder the biu and if
> FCFS take the first command, in this way is easy to do what I am trying to
> do. I just put in the first position of the biu an access of core x, and
> that's all.
>
> Regarding the statistics, is there any stat related with the hits and the
> misses?, I am printing the stats, with mem_print_stat(...) but I do not see
> any parameter to print the hits and miss in the memory. Do you know any
> parameter to print that information?. Thank you.
>
> Thanks a lot for your help, it is really appreciable.
>
>
>
>
>
> From: [email protected]: [email protected]: Tue, 27 Jan 2009
> 13:36:31 -0500Subject: Re: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
> implemention
> Ah, I see what you are saying, but that functionality actually resides
> within DRAMsim itself. The doTiming method of the DRAMsim M5 object can take
> as many packets as the network can give it, but it simply finds a free slot
> in the BIU and places it there for DRAMsim to process on the next memory
> controller cycle. On line 240, you will see the priority variable which is
> constantly set to zero. According to the DRAMsim code, that is intended for
> a purpose such as you are looking for, but I don't believe it does the
> correct thing right now. If you have the priority field set based on the
> core number, and then you modify/create a policy to do as you want within
> DRAMsim, you should be able to get the desired behavior.
>
> The biggest issue you may face is the fact that to actually make the system
> work, you would have to have requests arrive at (nearly) the same time. If
> the memory controller is connected to a bus, this is not possible, which
> would skew the results. If the pressure on the memory system is high enough,
> then it would be possible to see the selection policy in action, but it is
> more difficult to guarantee.
>
> Hopefully this information helps.
>
> - Clint
>
> On Jan 27, 2009, at 11:52 AM, Angela Carlsson wrote:
>
> Hello Clint thanks a lot for the patch. I have been testing it and it seems
> that works fine. Thanks a lot. I have a question regarding the reordering of
> the accesses. Do the selection policies Greedy, FCFS... work?. What I mean
> is that when there are several accesses at the *same* time all the accesses
> are stored inside of the transaction queue in DRAMSim? or on the contrary
> the accesses are sent one by one to DRAMSim (then DRAMSim process the
> petition and send the answer, in this case DRAMSim works as FCFS). In this
> last case then they are stored in the retry list in the bus.cc file. My
> interest for this is to give some priorities for accesses from some cores,
> that's why I am asking this, because I want to know who stores the petition,
> to reorder them there. I hope you knwo what I mean if not please let me
> know. Thanks a lot in advance. > Date: Fri, 23 Jan 2009 12:41:10 -0500>
> From: [email protected]> To: [email protected]> Subject: [m5-users]
> [PATCH] Beta patch for M5
> 2.0 DRAMsim implemention> > # HG changeset patch> # User Clint Smullen <
> [email protected]>> # Date 1232732406 18000> # Node ID
> a95dd3a28ecb82a074de030367fe641d52aaf148> # Parent
> 0397aa216e2290a50fb7138bd28563926573c929> Beta patch for M5 2.0 DRAMsim
> implemention.
>
> Con el nuevo Windows Live lo tendr?s todo al alcance de tu mano
> _______________________________________________m5-users mailing
> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> _________________________________________________________________
> Consigue gratis el nuevo Messenger. ?Desc?rgatelo!
> http://download.live.com/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://m5sim.org/cgi-bin/mailman/private/m5-users/attachments/20090128/5651f368/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Wed, 28 Jan 2009 14:06:15 -0500
> From: Clint Smullen <[email protected]>
> Subject: Re: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
> implemention
> To: M5 users mailing list <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Changing the BIU ordering would change the order in which they are
> converted into transactions. The policy itself affects the
> transactions, so if you were able to reorder the entries in the BIU
> before it reached the transaction scheduler, you could make an FCFS
> system to whatever you wanted it to. The only issue, is that the
> policy applies not only to memory requests, but the commands that each
> request is made up of. The get_next_cmd_to_issue does the analog of
> get_next_request_from_biu for commands.
>
> By reordering the BIU and using the FCFS policy, what should happen is
> that the earlier requests will always have their commands executed
> before any other, though commands from multiple requests may still be
> executed in parallel when they do not conflict. If you actually
> changed the policy to enforce that all commands from an earlier
> request would go ahead of all others, then you would reduce the memory
> system performance in a very unrealistic way. However, reordering the
> BIU entries (as long as you pay attention to read and write ordering
> constraints) should not have any adverse effects on overall system
> performance.
>
> I'm not sure what you mean by hits and misses, as a centralized main
> memory always has 100% hit rate (since it is neither a cache nor a
> memory slice).
>
> - Clint
>
> On Jan 28, 2009, at 1:39 PM, Angela Carlsson wrote:
>
> > Hello Clint, thanks for your answer and for your advice of using the
> > priority as a way to identify the cores, it is a good idea.
> >
> > I hope you can help me. I have been looking through the code about
> > the policies trying to do what I am looking for, but the code is a
> > little complex. Do you know if FCFS serves the first command that
> > finds in the biu?. The reason to ask this, is that reordering the
> > biu according to my policy is very simple, I am thinking that if I
> > can reorder the biu and if FCFS take the first command, in this way
> > is easy to do what I am trying to do. I just put in the first
> > position of the biu an access of core x, and that's all.
> >
> > Regarding the statistics, is there any stat related with the hits
> > and the misses?, I am printing the stats, with mem_print_stat(...)
> > but I do not see any parameter to print the hits and miss in the
> > memory. Do you know any parameter to print that information?. Thank
> > you.
> >
> > Thanks a lot for your help, it is really appreciable.
> >
> >
> >
> > From: [email protected]
> > To: [email protected]
> > Date: Tue, 27 Jan 2009 13:36:31 -0500
> > Subject: Re: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
> > implemention
> >
> >
> > Ah, I see what you are saying, but that functionality actually
> > resides within DRAMsim itself. The doTiming method of the DRAMsim M5
> > object can take as many packets as the network can give it, but it
> > simply finds a free slot in the BIU and places it there for DRAMsim
> > to process on the next memory controller cycle. On line 240, you
> > will see the priority variable which is constantly set to zero.
> > According to the DRAMsim code, that is intended for a purpose such
> > as you are looking for, but I don't believe it does the correct
> > thing right now. If you have the priority field set based on the
> > core number, and then you modify/create a policy to do as you want
> > within DRAMsim, you should be able to get the desired behavior.
> >
> > The biggest issue you may face is the fact that to actually make the
> > system work, you would have to have requests arrive at (nearly) the
> > same time. If the memory controller is connected to a bus, this is
> > not possible, which would skew the results. If the pressure on the
> > memory system is high enough, then it would be possible to see the
> > selection policy in action, but it is more difficult to guarantee.
> >
> > Hopefully this information helps.
> >
> > - Clint
> >
> > On Jan 27, 2009, at 11:52 AM, Angela Carlsson wrote:
> >
> > Hello Clint thanks a lot for the patch. I have been testing it and
> > it seems that works fine. Thanks a lot.
> >
> > I have a question regarding the reordering of the accesses. Do the
> > selection policies Greedy, FCFS... work?. What I mean is that when
> > there are several accesses at the *same* time all the accesses are
> > stored inside of the transaction queue in DRAMSim? or on the
> > contrary the accesses are sent one by one to DRAMSim (then DRAMSim
> > process the petition and send the answer, in this case DRAMSim works
> > as FCFS). In this last case then they are stored in the retry list
> > in the bus.cc file. My interest for this is to give some priorities
> > for accesses from some cores, that's why I am asking this, because I
> > want to know who stores the petition, to reorder them there.
> >
> > I hope you knwo what I mean if not please let me know. Thanks a lot
> > in advance.
> >
> >
> > > Date: Fri, 23 Jan 2009 12:41:10 -0500
> > > From: [email protected]
> > > To: [email protected]
> > > Subject: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
> > implemention
> > >
> > > # HG changeset patch
> > > # User Clint Smullen <[email protected]>
> > > # Date 1232732406 18000
> > > # Node ID a95dd3a28ecb82a074de030367fe641d52aaf148
> > > # Parent 0397aa216e2290a50fb7138bd28563926573c929
> > > Beta patch for M5 2.0 DRAMsim implemention.
> >
> > Con el nuevo Windows Live lo tendr?s todo al alcance de tu mano
> > _______________________________________________
> > m5-users mailing list
> > [email protected]
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >
> >
> > Actual?zate, descubre el nuevo Windows Live Messenger. ?Desc?rgatelo
> > ya! _______________________________________________
> > m5-users mailing list
> > [email protected]
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://m5sim.org/cgi-bin/mailman/private/m5-users/attachments/20090128/05e91195/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
> End of m5-users Digest, Vol 30, Issue 27
> ****************************************
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
