wget http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2 tar jxvf linux-2.6.27.61.tar.bz2 cd linux-2.6.27.61/ ls hg init hg addrem hg commit cd .hg/ hg clone http://repo.gem5.org/linux-patches patches cd .. hg qselect 2.6.27 hg qunapplied vim .hg/patches/series hg qpush -a cp .config.m5 .config cd .. wget http://www.m5sim.org/dist/current/alphaev67-unknown-linux-gnu.tar.bz2 tar jxvf alphaev67-unknown-linux-gnu.tar.bz2 cd linux-2.6.27.61/ export PATH=$PATH:/tmp/alphaev67-unknown-linux-gnu/bin/ make -j8 ARCH=alpha CROSS_COMPILE=alphaev67-unknown-linux-gnu- vmlinux cd .. hg clone http://repo.gem5.org/gem5 gem5 cd gem5 scons build/ALPHA/gem5.opt -j8 vim configs/common/FSConfig.py # change NSGigE to IGbE_e1000 ./build/ALPHA/gem5.opt configs/example/fs.py --kernel=/tmp/linux-2.6.27.61/vmlinux -b NetperfStream
<meanwhile on m5term> waiting for server...e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None server ready starting test... netperf warmup /benchmarks/netperf-bin/netperf -H 10.0.0.1 -t TCP_STREAM -l -100k TCP STREAM TEST to 10.0.0.1 : dirty data Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 5000000 5000000 5000000 1.05 38.23 Ali On Feb 21, 2012, at 2:25 PM, Pritha Ghoshal wrote: > Hi Ali, > > So I compiled the linux kernel again, but the problem still appears. I tried > disassembling the kernel and got the PC of the instruction which was creating > the address with the value of R31. > fffffc00006b3cbc: 40 06 80 21 lda s3,1600(v0) > This is in a function e1000_probe, which is defined in > drivers/net/e1000/e1000_main.c. I am not sure, would it be possible for you > to send this particular file from your linux kernel and I can try building > with that to see if it works? > > Pritha > > On Mon, Feb 20, 2012 at 9:59 PM, Pritha Ghoshal <pritha9...@tamu.edu> wrote: > Hi Ali, > > I'll try that out, should I make a new repo under the repo.gem5.org? > > Pritha > > On Mon, Feb 20, 2012 at 9:33 PM, Ali Saidi <sa...@umich.edu> wrote: > It seems like it's broken at the time. Yes you could start with a the kernel > source tar ball. > http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2 > > You'd probably need to turn that into a mercurial repository by creating a > new repo and committing all the code and the apply the patch queue on top of > that. > > Ali > > On Feb 20, 2012, at 6:59 PM, Pritha Ghoshal wrote: > >> Hi Ali, >> >> I was trying to compile the kernel again but I am not able to run this >> command: >> hg clone http://www.kernel.org/hg/linux-2.6/ >> >> Should I just download the kernel from the ftp repository? >> >> Pritha >> >> On Mon, Feb 20, 2012 at 6:40 PM, Ali Saidi <sa...@umich.edu> wrote: >> Hi Pritha, >> >> I really don't know. The kernel I tried was 2.6.27.6 and is a the mercurial >> repository of the linux kernel with the following patch queue applied: >> http://repo.m5sim.org/linux-patches There is nothing in there that touches >> the e1000 driver anymore. >> >> Ali >> >> On Feb 20, 2012, at 11:29 AM, Pritha Ghoshal wrote: >> >>> 51061742000: drivesys.cpu + A0 T0 : @e1000_probe+608 : ldq >>> r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8 >>> 51061747000: drivesys.cpu + A0 T0 : @tsunami_ioremap : lda >>> r1,-3(r31) : IntAlu : D=0xfffffffffffffffd >>> 51061747500: drivesys.cpu + A0 T0 : @tsunami_ioremap+4 : sll >>> r1,40,r1 : IntAlu : D=0xfffffd0000000000 >>> 51061748000: drivesys.cpu + A0 T0 : @tsunami_ioremap+8 : addq >>> r16,r1,r0 : IntAlu : D=0xfffffd0000000000 >>> 51061749500: drivesys.cpu + A0 T0 : @e1000_probe+648 : stq >>> r0,752(r12) : MemWrite : D=0xfffffd0000000000 A=0xfffffc000722b930 >>> >>> So the address is actually coming from a modified version of the value in >>> R31. It is shifted left logically 40 bits and that's how the wrong address >>> is generated. This value gets stored in address A=0xfffffc000722b930. >>> >>> I am still confused about how you don't see this error, do I have some old >>> versions of files? >>> >>> Pritha >>> >>> On Mon, Feb 20, 2012 at 10:34 AM, Ali Saidi <sa...@umich.edu> wrote: >>> I wonder who wrote to A=0xfffffc000722b930 last. That would be the next >>> step in debugging this is to understand where the address got initially >>> generated from. >>> >>> Ali >>> >>> On Feb 18, 2012, at 9:28 PM, Pritha Ghoshal wrote: >>> >>>> Hi Ali, >>>> >>>> So I think this is the relevant trace: >>>> 51061923500: drivesys.cpu + A0 T0 : @e1000_probe+1412 : ldq >>>> r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78 >>>> 51061927500: drivesys.cpu + A0 T0 : @e1000_set_media_type+20 : bis >>>> r31,r16,r9 : IntAlu : D=0xfffffc000722b930 >>>> 51061942000: drivesys.cpu + A0 T0 : @e1000_set_media_type+184 : ldq >>>> r16,0(r9) : MemRead : D=0xfffffd0000000000 A=0xfffffc000722b930 >>>> 51061943000: drivesys.cpu + A0 T0 : @e1000_set_media_type+192 : lda >>>> r16,8(r16) : IntAlu : D=0xfffffd0000000008 >>>> 51061947500: drivesys.cpu + A0 T0 : @tsunami_readl : ldl >>>> r0,0(r16) : MemRead : >>>> >>>> The last line of code gets executed for the NSGige adapter as well, but >>>> the previous part of the code which sets r16, sets a different value for >>>> that adapter, as this is adapter specific code. >>>> >>>> I am not sure how to rectify the error still though.. >>>> >>>> Pritha >>>> >>>> >>>> On Sat, Feb 18, 2012 at 5:47 PM, Ali Saidi <sa...@umich.edu> wrote: >>>> If you get an execution trace right before this happens that might shed >>>> some light on it. Tracking how the address that is being used is assembled >>>> by the cpu is a good start. >>>> >>>> Nothing jumps out at me though, so I'm pretty confused why I don't see the >>>> problem and you do. >>>> >>>> Ali >>>> >>>> On Feb 16, 2012, at 4:57 PM, Pritha Ghoshal wrote: >>>> >>>> > >>>> >> Hi Pritha, >>>> >> I took a old kernel from when i published the original paper in 2009 >>>> >> (2.6.27) >>>> > and it seems to work with the e1000 NIC if I just make the following >>>> > change: >>>> >> diff -r ef8630054b5e configs/common/FSConfig.py--- >>>> > a/configs/common/FSConfig.py Tue Feb 14 14:15:30 2012 -0500+++ >>>> > b/configs/common/FSConfig.py Thu Feb 16 11:28:32 2012 -0600 <at> <at> >>>> > -58,7 >>>> > +58,7 <at> <at> def makeLinuxAlphaSystem(mem_mode, mdesc = None): >>>> > IO_address_space_base = 0x80000000000 class BaseTsunami(Tsunami):- >>>> > ethernet = NSGigE(pci_bus=0, pci_dev=1, pci_func=0)+ ethernet = >>>> > IGbE_e1000(pci_bus=0, pci_dev=1, pci_func=0) ide = >>>> > IdeController(disks= >>>> > [Parent.disk0, Parent.disk2], pci_func=0, >>>> > pci_dev=0, >>>> > pci_bus=0) >>>> >> I don't know what kernel you're using but it's likely there is either >>>> >> an issue >>>> > with the configuration of it or perhaps something has broken in the alpha >>>> > branch. >>>> >> From an Alpha/Tsunami perspective, virtual addresses that start with >>>> >> ffffc map >>>> > to physical memory directly and addresses that start with ffffd map to >>>> > the i/o. >>>> > I'd have to look at the tsunami memory map documentation which isn't >>>> > close at >>>> > hand to what 80000000008 could be, but it doesn't seem right. You could >>>> > use the >>>> > PCIDev Ethernet trace flags to understand what addresses the PCI devices >>>> > are >>>> > getting assigned. >>>> >> Thanks, >>>> >> Ali >>>> >> >>>> > >>>> > Hi Ali, >>>> > >>>> > I had tried using the same modification in FSConfig.py, and even the >>>> > kernel I am >>>> > using in 2.6.27. Should I try to build the kernel again and check? >>>> > >>>> > Regarding the addresses, I used the flag BusAddrRanges, I am not able to >>>> > see any >>>> > of the address ranges mapped to the IOBus which starts from >>>> > 0x80000000000. The >>>> > closest one I can see is: >>>> > 0: drivesys.tsunami.fake_OROM: registering range: >>>> > 0x800000a0000-0x60000 >>>> > 0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff for >>>> > id 12 >>>> > All the rest seem to be starting with 0x801**** instead of 0x800****. >>>> > For membus this is the range: >>>> > 0: drivesys.membus: Adding range 0x80000000000 - 0xffffffffffffffff >>>> > for id >>>> > 2 >>>> > So there is one range of addresses which are not mapped to anywhere on >>>> > IO bus, >>>> > even though the >>>> > IO_address_space_base = 0x80000000000 >>>> > is set in FSConfig.py. >>>> > But the mapping of addresses do not change from NSGigE adapter mappings, >>>> > and >>>> > there is no error in that case. >>>> > >>>> > I enabled Fetch flag to see the addresses being accessed before the error >>>> > condition, and in the e100 NIC, this is the faulting address: >>>> > 51061947500: drivesys.cpu: Fetch: PC:0xfffffc0000324800 >>>> > 51061947500: drivesys.cpu: Address is fffffd0000000008, Physical address >>>> > 80000000008 >>>> > >>>> > But in the case of NSGigE, the same address brings forward a different >>>> > virtual >>>> > address for the read: >>>> > 51379655000: drivesys.cpu: Fetch: PC:0xfffffc0000324800 >>>> > 51379655000: drivesys.cpu: Address is fffffd0009000018, Physical address >>>> > 80009000018 >>>> > >>>> > For the other cases, the sequence addresses are identical in case of >>>> > NSGigE and >>>> > IGbE_e1000 adapters. eg: >>>> > NSGigE: >>>> > 51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4 >>>> > 51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address >>>> > 85e208 >>>> > e1000: >>>> > 51061946500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4 >>>> > 51061946500: drivesys.cpu: Address is fffffc000085e208, Physical address >>>> > 85e208 >>>> > >>>> > >>>> > Could you give any pointer regarding where this faulty address is getting >>>> > generated for this particular case? >>>> > >>>> > Pritha >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > gem5-users mailing list >>>> > gem5-users@gem5.org >>>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
