You need to remove that patch from the series file. THe kernel you downloaded already has those changes.
2.6.27 vs 2.6.27.6 vs 2.6.27.61 Ali On 22.02.2012 10:09, Pritha Ghoshal 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 [34]> wrote: > >> wget http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2 [28] >> 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 [29] 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 [30] >> 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 [31] 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 >> >> 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 [25]> wrote: >>> >>>> Hi Ali, >>>> >>>> I'll try that out, should I make a new repo under the repo.gem5.org [23]? >>>> >>>> Pritha >>>> >>>> On Mon, Feb 20, 2012 at 9:33 PM, Ali Saidi <sa...@umich.edu [24]> 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 [20] >>>>> 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/ [16] >>>>>> >>>>>> 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 [17]> 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 [13] 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 [10]> 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 [5]> 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 -58,7 >>>>>>>>>>> > +58,7 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 [1] >>>>>>>>>>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> gem5-users mailing list >>>>>>>>>>> gem5-users@gem5.org [3] >>>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [4] >>>>>>>>>> _______________________________________________ >>>>>>>>>> gem5-users mailing list >>>>>>>>>> gem5-users@gem5.org [6] >>>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [7] >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> gem5-users mailing list >>>>>>>>> gem5-users@gem5.org [8] >>>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [9] >>>>>>>> _______________________________________________ >>>>>>>> gem5-users mailing list >>>>>>>> gem5-users@gem5.org [11] >>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [12] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gem5-users mailing list >>>>>>> gem5-users@gem5.org [14] >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [15] >>>>>> _______________________________________________ >>>>>> gem5-users mailing list >>>>>> gem5-users@gem5.org [18] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [19] >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> gem5-users@gem5.org [21] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [22] >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org [26] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [27] >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org [32] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [33] Links: ------ [1] mailto:gem5-users@gem5.org [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:gem5-users@gem5.org [4] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [5] mailto:sa...@umich.edu [6] mailto:gem5-users@gem5.org [7] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [8] mailto:gem5-users@gem5.org [9] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [10] mailto:sa...@umich.edu [11] mailto:gem5-users@gem5.org [12] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [13] http://repo.m5sim.org/linux-patches [14] mailto:gem5-users@gem5.org [15] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [16] http://www.kernel.org/hg/linux-2.6/ [17] mailto:sa...@umich.edu [18] mailto:gem5-users@gem5.org [19] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [20] http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2 [21] mailto:gem5-users@gem5.org [22] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [23] http://repo.gem5.org/ [24] mailto:sa...@umich.edu [25] mailto:pritha9...@tamu.edu [26] mailto:gem5-users@gem5.org [27] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [28] http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2 [29] http://repo.gem5.org/linux-patches [30] http://www.m5sim.org/dist/current/alphaev67-unknown-linux-gnu.tar.bz2 [31] http://repo.gem5.org/gem5 [32] mailto:gem5-users@gem5.org [33] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [34] mailto:sa...@umich.edu
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
