> > Hi Pritha, > I don't know why you're seeing that error, if you just use IGbE_e1000() I think it should work. That said, all of the upheaval in the memory system over the last few weeks might have broken something. The first trick is to understand where this request is coming from and how it thinks that address is correct. If you know that bit then the problem normally presents itself pretty quickly. As far as what needs to be implemented for the igb driver, there are some registered that are accessed that didn't used to be, there is code in the driver that verifies all the RAMs in the NIC are good by writing and expecting to read the same value. These I think I have pretty much fixed in a patch i'll try and post a little later. The driver also make use of multiple receive queues, which aren't implemented, although the code is probably modular enough that instantiating multiple copies of bits of it shouldn't be too hard, and finally it makes some assumptions about message signaled interrupts that aren't in the Alpha model so there would need to be some code written to make that work. > > Thanks, > Ali
Hi Ali, I tried tracking down the source for the address, but it seems to come from the original request itself, I tracked the calling function to readMemAtomic in arch/alpha/isa/mem.isa. 51061947500: drivesys.cpu: Address is fffffd0000000008, Physical address 80000000008 This address should go to the iobridge and out on the iobus, but once it gets to the iobus, it cannot find the target port, because the iobus address range is : 801fe000000,801feffffff for the default_range, and the iobus has use_default_range set to true. I am not sure, should this address not be generated at all, or it is being routed in some way which is unexpected? Thanks, Pritha _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
