Hi Ali, Probably I had some problem in the gem5 repository I had, i got it working now, thanks..
Pritha On Wed, Feb 22, 2012 at 10:09 AM, Pritha Ghoshal <pritha9...@tamu.edu>wrote: > Hi Ali, > > Did you get an error which applying the patch: > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > errors during apply, please fix and refresh stable/patch_to_2.6.27.6.diff > > I had to use > hg qpush -a -v to actually apply the patches.. > > > Pritha > > > On Tue, Feb 21, 2012 at 8:43 PM, Ali Saidi <sa...@umich.edu> wrote: > >> >> 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 >> > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
