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
