> 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
