What happens with you turn on the trace flags?  It could be a lot of things,
just asking "what could it be?" won't get any answers...if you could paste
the relevant output from the Exectrace that would help.

Also, I thik you mentioned before that it was your native machine running
2.6.9 and your m5 is simulating 2.6.13.  that's fine, though you can go
newer if you want.

Lisa

On Tue, Nov 25, 2008 at 2:58 PM, Ryan Markley <[EMAIL PROTECTED]> wrote:

> Hello Ali thanks again for your effort in helping me, I wasn't able to find
> where the address is coming from, where do you think that the problem it can
> be?, I am running such an old kernel thanks to the administrator of my
> cluster. Have you got any other ideas about what is the problem?. Do you
> think that is a problem of my old kernel?. Thanks.
>
>
> On Mon, Nov 24, 2008 at 6:24 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
>
>> Why are you running such an old kernel?
>>
>> Add the O3CPUAll traceflag and start tracing a bit earlier. You should
>> figure out where that address is coming from.
>> Ali
>>
>> On Nov 24, 2008, at 8:14 PM, Ryan Markley wrote:
>>
>> > Hi,
>> >
>> > When I said the kernel in my last mail I said the kernel of the disk
>> > image, my kernel is 2.6.9. I have found this problem with the disk
>> > image of the web site and the disk image of the PARSEC benchmarks
>> > that Joel post several days ago. This is the output that I with the
>> > exec flag.
>> >
>> > 44873185000: system.cpu T0 : @vsnprintf+144 : cmpeq
>> > r1,37,r1        : IntAl                u :  D=0x0000000000000001
>> > 44873185000: system.cpu T0 : @vsnprintf+148 : bne
>> > r1,0xfffffc00004bd6e0 :                 IntAlu :
>> > 44873192000: system.cpu T0 : @vsnprintf+656 : bis
>> > r31,r31,r12     : IntAl                u :  D=0x0000000000000000
>> > 44873192000: system.cpu T0 : @vsnprintf+660 : nop        (ldq_u
>> > r31,0(r30))                 : No_OpClass :
>> > 44873192000: system.cpu T0 : @vsnprintf+664 : nop        (bis
>> > r31,r31,r31                ) : No_OpClass :
>> > 44873192000: system.cpu T0 : @vsnprintf+668 : nop        (ldq_u
>> > r31,0(r30))                 : No_OpClass :
>> > 44873192000: system.cpu T0 : @vsnprintf+672 : lda
>> > r18,1(r18)      : IntAl                u :  D=0xfffffc000066dae9
>> > 44873192000: system.cpu T0 : @vsnprintf+676 : stq
>> > r18,96(r30)     : MemWr                ite :  D=0xfffffc000066dae9
>> > A=0xfffffc0000c3bd58
>> > 44873192000: system.cpu T0 : @vsnprintf+680 : ldq_u
>> > r2,0(r18)       : MemRe                ad :  D=0x3230253a78343025
>> > A=0xfffffc000066dae8
>> > 44873192000: system.cpu T0 : @vsnprintf+684 : extbl
>> > r2,r18,r1       : IntAl                u :  D=0x0000000000000030
>> > 44873193500: system.cpu T0 : @vsnprintf+688 : sll
>> > r1,56,r1        : IntAl                u :  D=0x3000000000000000
>> > 44873193500: system.cpu T0 : @vsnprintf+692 : sra
>> > r1,56,r2        : IntAl                u :  D=0x0000000000000030
>> > 44873193500: system.cpu T0 : @vsnprintf+696 : lda
>> > r2,-32(r2)      : IntAl                u :  D=0x0000000000000010
>> > 44873193500: system.cpu T0 : @vsnprintf+700 : zapnot
>> > r2,15,r2        : IntAl                u :  D=0x0000000000000010
>> > 44873193500: system.cpu T0 : @vsnprintf+704 : cmpule
>> > r2,16,r1        : IntAl                u :  D=0x0000000000000001
>> > 44873193500: system.cpu T0 : @vsnprintf+708 : beq
>> > r1,0xfffffc00004bd560 :                 IntAlu :
>> > panic: Unable to find destination for addr (user set default
>> > responder): 0x80c4d                bc0
>> >  @ cycle 44873206500
>> > [findPort:build/ALPHA_FS/mem/bus.cc, line 334]
>> > Memory Usage: 197688 KBytes
>> > Program aborted at cycle 44873206500
>> > Aborted
>> >
>> > Thanks for the help.
>> >
>> > On Mon, Nov 24, 2008 at 4:52 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
>> > The Exec traceflag is very useful. You'll see the symbol names for the
>> > function that is causing the read to be issued. However, you should
>> > only enable tracing right before the error (e.g. --trace-start=
>> > 44873106500).
>> >
>> > Do you encounter the problem with the compiled kernel available on the
>> > website?
>> >
>> > Ali
>> >
>> > On Nov 24, 2008, at 7:35 PM, Ryan Markley wrote:
>> >
>> > > Hi Ali thanks again,
>> > >
>> > > I have been trying several programs and in all of them is the same,
>> > > do you think that maybe is a bug of the software for the GCC version
>> > > or other libraries?, I did not do any changes to the simulator. My
>> > > gcc version is 4.3.2 and my kernel is .6.6.13. I have enable the bus
>> > > trace flags and this is the output:
>> > >
>> > > 44873206500: system.iobus: recvTiming: src 0 dst -1 ReadReq
>> > 0x80c4dbc0
>> > > panic: Unable to find destination for addr (user set default
>> > > responder): 0x80c4dbc0
>> > >
>> > > I am a beginner in the simulator so can you tell me other trace
>> > > flags that I can use to give your more useful information, in
>> > > addition how can I do to show the information after a certain number
>> > > of cycles?.
>> > >
>> > > Thanks.
>> > >
>> > >
>> > >
>> > > On Mon, Nov 24, 2008 at 2:55 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
>> > > Ok, now you're going to need to do some debugging. You know what
>> > cycle
>> > > the panic occurs at, so you should enable some trace flags a few
>> > > thousand cycles before that and figure out what the CPU is doing. Is
>> > > it accessing a good address? Is there some bug with the address
>> > > calculation? Where is the address coming from?
>> > >
>> > > Have you made any changes to the simulator? What kernel are you
>> > > running?
>> > >
>> > > Ali
>> > >
>> > >
>> > > On Nov 24, 2008, at 5:34 PM, Ryan Markley wrote:
>> > >
>> > > > Hi Ali thanks for your answer,
>> > > >
>> > > > I am using the fs.py that comes with the simulator, when I do the
>> > > > simulation with the atomic model works fine, but when I put the --
>> > > > detailed options then I get the error that I said before, this is
>> > > > the command that I use
>> > > >
>> > > > ./build/ALPHA_FS/m5.opt  -d /temp/output configs/example/fs.py -b
>> > > > Hello --detailed  --caches
>> > > >
>> > > >
>> > > > This is my rcS file.
>> > > >
>> > > > ---- rcS file
>> > > > #!/bin/sh
>> > > > /benchmarks/Hello
>> > > > m5 exit
>> > > >
>> > > > This is the output of the file system.terminal
>> > > >
>> > > > ---- system.terminal file
>> > > > Brought up 1 CPUs
>> > > > SMP: Total of 1 processors activated (4002.20 BogoMIPS).
>> > > > NET: Registered protocol family 16
>> > > > EISA bus registered
>> > > >
>> > > > To run the simulation what I have done is change the benchmarks.py
>> > > > file and I have added my own benchmark:
>> > > >  'Hello':     [SysConfig('Hello.rcS')],
>> > > >
>> > > > In the file config.ini everything seems fine, any ideas about what
>> > > > is happening?. This error happens with every program that I try.
>> > If
>> > > > you need more information please tell me. Thanks so much.
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Nov 24, 2008 at 2:01 PM, Ali Saidi <[EMAIL PROTECTED]>
>> > wrote:
>> > > > Hi Ryan,
>> > > >
>> > > > We're going to need a lot more information to help you. Please
>> > see http://www.m5sim.org/wiki/index.php/Reporting_Problems
>> > > > Ali
>> > > >
>> > > > On Nov 24, 2008, at 3:19 PM, Ryan Markley wrote:
>> > > >
>> > > > > Hello, I have been running several simulations but I can
>> > complete
>> > > > > all of them with the atomic cpu but when I put the option of --
>> > > > > detailed cpu then I get the following error:
>> > > > >
>> > > > > panic: Unable to find destination for addr (user set default
>> > > > > responder): 0x80c4dbc0
>> > > > >  @ cycle 44873206500
>> > > > > [findPort:build/ALPHA_FS/mem/bus.cc, line 334]
>> > > > > Memory Usage: 197528 KBytes
>> > > > > Program aborted at cycle 44873206500
>> > > > > Aborted
>> > > > >
>> > > > > With every program I get the same error and in the same cycle, I
>> > > > > thought that maybe is a bug so I update to the last development
>> > > > > version but I still get the same error.  Thank you.
>> > > > > _______________________________________________
>> > > > > m5-users mailing list
>> > > > > [email protected]
>> > > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> > > >
>> > > > _______________________________________________
>> > > > m5-users mailing list
>> > > > [email protected]
>> > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> > > >
>> > > > _______________________________________________
>> > > > m5-users mailing list
>> > > > [email protected]
>> > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> > >
>> > > _______________________________________________
>> > > m5-users mailing list
>> > > [email protected]
>> > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> > >
>> > > _______________________________________________
>> > > m5-users mailing list
>> > > [email protected]
>> > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>> _______________________________________________
>> m5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to