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
