Discussion:
Running NetperfStream with Intel 8257x Ethernet adapter
(too old to reply)
Pritha Ghoshal
2012-02-13 19:08:13 UTC
Permalink
Hi,

I am trying to run NetperfStream benchmark using the Intel 8257x ethernet
adapter. I modified the Fsconfig.py file as follows:
#ethernet = NSGigE(pci_bus=0, pci_dev=1, pci_func=0)
ethernet = IGbE_igb(pci_bus=0, pci_dev=1, pci_func=0)

I am using kernel version 2.6.27.

But my drivesys.terminal file shows the following errors:
setting up network...
modprobe: FATAL: Could not load /lib/modules/2.6.27.6/modules.dep: No such
file or directory
SIOCSIFADDR: No such device
modprobe: FATAL: Could not load /lib/modules/2.6.27.6/modules.dep: No such
file or directory
SIOCSIFTXQLEN: No such device
running netserver...
Starting netserver at port 12865
signal client to begin...Error: Couldn't create connection (err=-5):
Network is unreachable
done.

Is there something missing in the kernel that I need to add or is there
some setup missing before this can run?

Thanks,
Pritha
Ali Saidi
2012-02-13 19:18:59 UTC
Permalink
Since the model was written the driver has made use of features in
the adapter that aren't implemented. You can use the the NIC in e1000
mode and that should work or you can try to implement the missing
features.

Ali
Post by Pritha Ghoshal
Hi,
I am trying to run NetperfStream benchmark using the Intel 8257x
ethernet adapter. I modified the Fsconfig.py file as follows:
#ethernet = NSGigE(pci_bus=0, pci_dev=1, pci_func=0)
Post by Pritha Ghoshal
ethernet =
IGbE_igb(pci_bus=0, pci_dev=1, pci_func=0)
Post by Pritha Ghoshal
I am using kernel version
2.6.27.
Post by Pritha Ghoshal
setting up network...
modprobe: FATAL: Could not load
/lib/modules/2.6.27.6/modules.dep [1]: No such file or directory
SIOCSIFADDR: No such device
Post by Pritha Ghoshal
modprobe: FATAL: Could not load
/lib/modules/2.6.27.6/modules.dep [2]: No such file or directory
SIOCSIFTXQLEN: No such device
Post by Pritha Ghoshal
running netserver...
Starting
netserver at port 12865
Post by Pritha Ghoshal
signal client to begin...Error: Couldn't
create connection (err=-5): Network is unreachable
Post by Pritha Ghoshal
done.
Is there
something missing in the kernel that I need to add or is there some
setup missing before this can run?
Post by Pritha Ghoshal
Thanks,
Pritha
Links:
------
[1] http://2.6.27.6/modules.dep
[2]
http://2.6.27.6/modules.dep
Pritha Ghoshal
2012-02-13 20:09:12 UTC
Permalink
Since the model was written the driver has made use of features in the adapter
that aren't implemented. You can use the the NIC in e1000 mode and that should
work or you can try to implement the missing features.
 
Ali
 
Hi, 
I am trying to run NetperfStream benchmark using the Intel 8257x ethernet
adapter. I modified the Fsconfig.py file as follows: 
        #ethernet = NSGigE(pci_bus=0, pci_dev=1, pci_func=0)
        ethernet = IGbE_igb(pci_bus=0, pci_dev=1, pci_func=0)
I am using kernel version 2.6.27.
But my drivesys.terminal file shows the following errors: 
setting up network...
modprobe: FATAL: Could not load /lib/modules/2.6.27.6/modules.dep: No such
file or directory
SIOCSIFADDR: No such device
modprobe: FATAL: Could not load /lib/modules/2.6.27.6/modules.dep: No such
file or directory
SIOCSIFTXQLEN: No such device
running netserver...
Starting netserver at port 12865
signal client to begin...Error: Couldn't create connection (err=-5): Network
is unreachable
done.
Is there something missing in the kernel  that I need to add or is there some
setup missing before this can run? 
Thanks, 
Pritha
Hi Ali,

Thanks for your reply. I saw that you had made use of the NIC in the 2009 ISCA
paper, so I assumed it was working, I guess the drivers have changed from then.

Do you know which features are missing and need to be implemented? Also I tried
running in the e1000 mode. I get the following error:
panic: Unable to find destination for addr 0x80000000008
@ cycle 51061947500
[findPort:build/ALPHA_FS/mem/bus.cc, line 325]
Memory Usage: 473316 KBytes

Do I need to modify some setting?

Thanks,
Pritha
Ali Saidi
2012-02-13 21:55:49 UTC
Permalink
Post by Pritha Ghoshal
Hi Ali,
Thanks
for your reply. I saw that you had made use of the NIC in the 2009 ISCA
Post by Pritha Ghoshal
paper, so I assumed it was working, I guess the drivers have changed from then.
Do you know which features are missing and need to be
implemented? Also I tried
Post by Pritha Ghoshal
running in the e1000 mode. I get the
panic: Unable to find destination for addr
0x80000000008
Post by Pritha Ghoshal
@ cycle 51061947500
[findPort:build/ALPHA_FS/mem/bus.cc, line 325]
Post by Pritha Ghoshal
Memory Usage: 473316
KBytes
Post by Pritha Ghoshal
Do I need to modify some setting?
Thanks,
Pritha
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
Pritha Ghoshal
2012-02-16 16:52:58 UTC
Permalink
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
Ali Saidi
2012-02-16 17:32:34 UTC
Permalink
Post by Pritha Ghoshal
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
Post by Pritha Ghoshal
the last few weeks might have broken something. The first
trick is to understand
Post by Pritha Ghoshal
where this request is coming from and how it
thinks that address is correct. If
Post by Pritha Ghoshal
you know that bit then the problem
normally presents itself pretty quickly. As
Post by Pritha Ghoshal
far as what needs to be
implemented for the igb driver, there are some
Post by Pritha Ghoshal
registered that are
accessed that didn't used to be, there is code in the driver
Post by Pritha Ghoshal
that
verifies all the RAMs in the NIC are good by writing and expecting to
read
Post by Pritha Ghoshal
the same value. These I think I have pretty much fixed in a
patch i'll try and
Post by Pritha Ghoshal
post a little later. The driver also make use of
multiple receive queues, which
Post by Pritha Ghoshal
aren't implemented, although the code
is probably modular enough that
Post by Pritha Ghoshal
instantiating multiple copies of bits
of it shouldn't be too hard, and finally
Post by Pritha Ghoshal
it makes some assumptions
about message signaled interrupts that aren't in the
Post by Pritha Ghoshal
Alpha model so
there would need to be some code written to make that work.
Thanks, Ali
Post by Pritha Ghoshal
Hi Ali,
I tried tracking down the source for the
address, but it seems to come from the
Post by Pritha Ghoshal
original request itself, I
tracked the calling function to readMemAtomic in
arch/alpha/isa/mem.isa.
Post by Pritha Ghoshal
51061947500: drivesys.cpu: Address is
fffffd0000000008, Physical address
Post by Pritha Ghoshal
80000000008
This address should
go to the iobridge and out on the iobus, but once it gets to
Post by Pritha Ghoshal
the
iobus, it cannot find the target port, because the iobus address range
Post by Pritha Ghoshal
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
Post by Pritha Ghoshal
routed in some way
which is unexpected?
Post by Pritha Ghoshal
Thanks,
Pritha
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.
Post by Pritha Ghoshal
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
Pritha Ghoshal
2012-02-16 22:57:44 UTC
Permalink
Hi Pritha,
I took a old kernel from when i published the original paper in 2009 (2.6.27)
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
Ali Saidi
2012-02-18 23:47:34 UTC
Permalink
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
Post by Pritha Ghoshal
Hi Pritha,
I took a old kernel from when i published the original paper in 2009 (2.6.27)
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
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
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****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Pritha Ghoshal
2012-02-19 03:28:24 UTC
Permalink
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
Post by Ali Saidi
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
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
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
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff for
id 12
All the rest seem to be starting with 0x801**** instead of 0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address
85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-02-20 16:34:54 UTC
Permalink
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
Post by Pritha Ghoshal
Hi Ali,
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
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
Hi Pritha,
I took a old kernel from when i published the original paper in 2009 (2.6.27)
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
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
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****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Pritha Ghoshal
2012-02-20 17:29:26 UTC
Permalink
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
Post by Ali Saidi
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
Hi Ali,
r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78
r31,r16,r9 : IntAlu : D=0xfffffc000722b930
r16,0(r9) : MemRead : D=0xfffffd0000000000 A=0xfffffc000722b930
r16,8(r16) : IntAlu : D=0xfffffd0000000008
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
Post by Ali Saidi
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
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
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
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff for
id 12
All the rest seem to be starting with 0x801**** instead of 0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical
address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-02-21 00:40:19 UTC
Permalink
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
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
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
Post by Pritha Ghoshal
Hi Ali,
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
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
Hi Pritha,
I took a old kernel from when i published the original paper in 2009 (2.6.27)
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
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
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****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Pritha Ghoshal
2012-02-21 00:59:31 UTC
Permalink
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
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
r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8
r1,-3(r31) : IntAlu : D=0xfffffffffffffffd
r1,40,r1 : IntAlu : D=0xfffffd0000000000
r16,r1,r0 : IntAlu : D=0xfffffd0000000000
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
Post by Ali Saidi
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
Hi Ali,
r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78
r31,r16,r9 : IntAlu : D=0xfffffc000722b930
r16,0(r9) : MemRead : D=0xfffffd0000000000 A=0xfffffc000722b930
r16,8(r16) : IntAlu : D=0xfffffd0000000008
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
Post by Ali Saidi
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
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
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
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff for
id 12
All the rest seem to be starting with 0x801**** instead of 0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical
address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-02-21 03:33:27 UTC
Permalink
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

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
Post by Pritha Ghoshal
Hi Ali,
hg clone http://www.kernel.org/hg/linux-2.6/
Should I just download the kernel from the ftp repository?
Pritha
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
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
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
Post by Pritha Ghoshal
Hi Ali,
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
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
Hi Pritha,
I took a old kernel from when i published the original paper in 2009 (2.6.27)
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
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
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****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Pritha Ghoshal
2012-02-21 03:59:52 UTC
Permalink
Hi Ali,

I'll try that out, should I make a new repo under the repo.gem5.org?

Pritha
Post by Ali Saidi
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
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
Hi Ali,
hg clone http://www.kernel.org/hg/linux-2.6/
Should I just download the kernel from the ftp repository?
Pritha
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
r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8
r1,-3(r31) : IntAlu : D=0xfffffffffffffffd
r1,40,r1 : IntAlu : D=0xfffffd0000000000
r16,r1,r0 : IntAlu : D=0xfffffd0000000000
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
Post by Ali Saidi
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
Hi Ali,
r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78
r31,r16,r9 : IntAlu : D=0xfffffc000722b930
r16,0(r9) : MemRead : D=0xfffffd0000000000 A=0xfffffc000722b930
r16,8(r16) : IntAlu : D=0xfffffd0000000008
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
Post by Ali Saidi
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
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
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
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff
for id 12
All the rest seem to be starting with 0x801**** instead of 0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical
address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Pritha Ghoshal
2012-02-21 20:25:54 UTC
Permalink
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
Post by Pritha Ghoshal
Hi Ali,
I'll try that out, should I make a new repo under the repo.gem5.org?
Pritha
Post by Ali Saidi
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
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
Hi Ali,
hg clone http://www.kernel.org/hg/linux-2.6/
Should I just download the kernel from the ftp repository?
Pritha
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
r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8
r1,-3(r31) : IntAlu : D=0xfffffffffffffffd
r1,40,r1 : IntAlu : D=0xfffffd0000000000
r16,r1,r0 : IntAlu : D=0xfffffd0000000000
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
Post by Ali Saidi
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
Hi Ali,
r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78
r31,r16,r9 : IntAlu : D=0xfffffc000722b930
r16,0(r9) : MemRead : D=0xfffffd0000000000
A=0xfffffc000722b930
r16,8(r16) : IntAlu : D=0xfffffd0000000008
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
Post by Ali Saidi
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
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
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
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff
for id 12
All the rest seem to be starting with 0x801**** instead of 0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical
address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-02-22 02:43:25 UTC
Permalink
wget http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2
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 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
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 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

<meanwhile on m5term>
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
Post by Pritha Ghoshal
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
Hi Ali,
I'll try that out, should I make a new repo under the repo.gem5.org?
Pritha
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
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
Post by Pritha Ghoshal
Hi Ali,
hg clone http://www.kernel.org/hg/linux-2.6/
Should I just download the kernel from the ftp repository?
Pritha
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
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
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
Post by Pritha Ghoshal
Hi Ali,
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
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
Hi Pritha,
I took a old kernel from when i published the original paper in 2009 (2.6.27)
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
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
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****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Pritha Ghoshal
2012-02-22 16:09:02 UTC
Permalink
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
Post by Ali Saidi
wget
http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2
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 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
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 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
<meanwhile on m5term>
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
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
Post by Pritha Ghoshal
Hi Ali,
I'll try that out, should I make a new repo under the repo.gem5.org?
Pritha
Post by Ali Saidi
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
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
Hi Ali,
hg clone http://www.kernel.org/hg/linux-2.6/
Should I just download the kernel from the ftp repository?
Pritha
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
r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8
r1,-3(r31) : IntAlu : D=0xfffffffffffffffd
r1,40,r1 : IntAlu : D=0xfffffd0000000000
r16,r1,r0 : IntAlu : D=0xfffffd0000000000
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
Post by Ali Saidi
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
Hi Ali,
r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78
r31,r16,r9 : IntAlu : D=0xfffffc000722b930
r16,0(r9) : MemRead : D=0xfffffd0000000000
A=0xfffffc000722b930
r16,8(r16) : IntAlu : D=0xfffffd0000000008
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
Post by Ali Saidi
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
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
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
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff
for id 12
All the rest seem to be starting with 0x801**** instead of
0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical
address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-02-22 16:21:25 UTC
Permalink
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
Post by Pritha Ghoshal
Hi Ali,
Did
patch failed, unable to
continue (try -v)
Post by Pritha Ghoshal
patch failed, rejects left in working dir
errors
during apply, please fix and refresh stable/patch_to_2.6.27.6.diff
Post by Pritha Ghoshal
I
had to use
Post by Pritha Ghoshal
hg qpush -a -v to actually apply the patches..
Pritha
Post by Ali Saidi
wget
http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2
[28]
Post by Pritha Ghoshal
Post by Ali Saidi
tar jxvf linux-2.6.27.61.tar.bz2
cd linux-2.6.27.61/
ls
Post by Pritha Ghoshal
Post by Ali Saidi
hg init
hg addrem
hg commit
cd .hg/
hg clone
http://repo.gem5.org/linux-patches [29] patches
Post by Pritha Ghoshal
Post by Ali Saidi
cd ..
hg qselect
2.6.27
Post by Pritha Ghoshal
Post by Ali Saidi
hg qunapplied
vim .hg/patches/series
hg qpush -a
cp .config.m5 .config
Post by Pritha Ghoshal
Post by Ali Saidi
cd ..
wget
http://www.m5sim.org/dist/current/alphaev67-unknown-linux-gnu.tar.bz2
[30]
Post by Pritha Ghoshal
Post by Ali Saidi
tar jxvf alphaev67-unknown-linux-gnu.tar.bz2
cd
linux-2.6.27.61/
Post by Pritha Ghoshal
Post by Ali Saidi
export
PATH=$PATH:/tmp/alphaev67-unknown-linux-gnu/bin/
Post by Pritha Ghoshal
Post by Ali Saidi
make -j8 ARCH=alpha
CROSS_COMPILE=alphaev67-unknown-linux-gnu- vmlinux
Post by Pritha Ghoshal
Post by Ali Saidi
cd ..
hg
clone http://repo.gem5.org/gem5 [31] gem5
Post by Pritha Ghoshal
Post by Ali Saidi
cd gem5
scons
build/ALPHA/gem5.opt -j8
Post by Pritha Ghoshal
Post by Ali Saidi
vim configs/common/FSConfig.py # change
NSGigE to IGbE_e1000
Post by Pritha Ghoshal
Post by Ali Saidi
./build/ALPHA/gem5.opt configs/example/fs.py
--kernel=/tmp/linux-2.6.27.61/vmlinux -b NetperfStream
Post by Pritha Ghoshal
Post by Ali Saidi
waiting
for server...e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full
Duplex, Flow Control: None
Post by Pritha Ghoshal
Post by Ali Saidi
server ready
starting test...
netperf warmup
Post by Pritha Ghoshal
Post by Ali Saidi
/benchmarks/netperf-bin/netperf -H 10.0.0.1 -t
TCP_STREAM -l -100k
Post by Pritha Ghoshal
Post by Ali Saidi
TCP STREAM TEST to 10.0.0.1 : dirty data
Recv Send Send
Post by Pritha Ghoshal
Post by Ali Saidi
Socket Socket Message Elapsed
Size Size Size Time
Throughput
Post by Pritha Ghoshal
Post by Ali Saidi
bytes bytes bytes secs. 10^6bits/sec
5000000 5000000
5000000 1.05 38.23
Post by Pritha Ghoshal
Post by Ali Saidi
Ali
On Feb 21, 2012, at 2:25 PM, Pritha
Post by Pritha Ghoshal
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
fffffc00006b3cbc: 40 06 80 21 lda
s3,1600(v0)
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
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?
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Pritha
On Mon, Feb
Post by Pritha Ghoshal
Hi Ali,
I'll try that out, should I make a
new repo under the repo.gem5.org [23]?
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Pritha
On
Post by Ali Saidi
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]
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Ali
On Feb
Post by Pritha Ghoshal
Hi Ali,
I was trying to compile the kernel again but I am not
hg clone
http://www.kernel.org/hg/linux-2.6/ [16]
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Should I just
download the kernel from the ftp repository?
Pritha
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
On Mon, Feb 20, 2012 at 6:40 PM, Ali Saidi
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Ali
r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8
r1,-3(r31) : IntAlu : D=0xfffffffffffffffd
drivesys.cpu + A0 T0 : @tsunami_ioremap+4 : sll r1,40,r1 : IntAlu :
D=0xfffffd0000000000
@tsunami_ioremap+8 : addq r16,r1,r0 : IntAlu : D=0xfffffd0000000000
r0,752(r12) : MemWrite : D=0xfffffd0000000000 A=0xfffffc000722b930
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
I am still confused about how you don't
see this error, do I have some old versions of files?
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Pritha
On Mon, Feb 20, 2012 at 10:34 AM, Ali Saidi
Post by Ali Saidi
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Ali
On Feb 18, 2012, at 9:28
Post by Pritha Ghoshal
Hi Ali,
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
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
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
I am not sure how to rectify the
error still though..
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Pritha
Post by Ali Saidi
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.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
Nothing jumps out at me though, so I'm
pretty confused why I don't see the problem and you do.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
Ali
On Feb 16, 2012, at 4:57 PM,
Hi
Pritha,
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
I took a old kernel from when i published the
original paper in 2009 (2.6.27)
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
and it seems to work with
diff
-r ef8630054b5e configs/common/FSConfig.py---
a/configs/common/FSConfig.py Tue Feb 14 14:15:30 2012
-0500+++
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
b/configs/common/FSConfig.py Thu Feb 16 11:28:32
2012 -0600 -58,7
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
+58,7 def makeLinuxAlphaSystem(mem_mode,
IO_address_space_base = 0x80000000000 class
BaseTsunami(Tsunami):-
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
ethernet = NSGigE(pci_bus=0,
pci_dev=1, pci_func=0)+ ethernet =
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
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)
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
I don't know what kernel you're using but it's
likely there is either an issue
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
with the configuration of
it or perhaps something has broken in the alpha
branch.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
From an Alpha/Tsunami perspective, virtual
addresses that start with ffffc map
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
to physical memory
directly and addresses that start with ffffd map to the i/o.
Post by Pritha Ghoshal
I'd have to look at the tsunami memory map documentation which isn't close at
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
hand to what 80000000008 could be, but it doesn't
seem right. You could use the
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
PCIDev Ethernet trace flags
to understand what addresses the PCI devices are
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
getting
assigned.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
Thanks,
Ali
Hi Ali,
I had
tried using the same modification in FSConfig.py, and even the kernel I
am
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
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
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
of the
address ranges mapped to the IOBus which starts from 0x80000000000.
The
drivesys.tsunami.fake_OROM: registering range:
0x800000a0000-0x60000
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
0: drivesys.iobus: Adding range
0x800000a0000 - 0x800000fffff for id 12
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
All the rest seem
to be starting with 0x801**** instead of 0x800****.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
For
0: drivesys.membus: Adding range
0x80000000000 - 0xffffffffffffffff for id
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
2
So there is one range of addresses which are not mapped to anywhere on
IO bus,
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
even though the
IO_address_space_base = 0x80000000000
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
is set in
FSConfig.py.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
But the mapping of addresses do not change
from NSGigE adapter mappings, and
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
there is no error in
that case.
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
I enabled Fetch flag to see the
addresses being accessed before the error
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
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
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
80000000008
But in the
case of NSGigE, the same address brings forward a different
virtual
drivesys.cpu: Fetch: PC:0xfffffc0000324800
drivesys.cpu: Address is fffffd0009000018, Physical address
Post by Pritha Ghoshal
80009000018
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
For the other cases, the
sequence addresses are identical in case of NSGigE and
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical address
85e208
Fetch: PC:0xfffffc0000319ce4
Address is fffffc000085e208, Physical address 85e208
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
Could you give any pointer regarding where
this faulty address is getting
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
generated for this
particular case?
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
Pritha
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
gem5-users
mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2]
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Ali Saidi
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [4]
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
gem5-users
mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [7]
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [9]
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
gem5-users
mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [12]
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [15]
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
gem5-users
mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [19]
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
Post by Pritha Ghoshal
Post by Ali Saidi
gem5-users mailing
list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [22]
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
Post by Pritha Ghoshal
gem5-users mailing
list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [27]
_______________________________________________
Post by Pritha Ghoshal
Post by Ali Saidi
gem5-users mailing
list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [33]




Links:
------
[1] mailto:gem5-***@gem5.org
[2]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[3]
mailto:gem5-***@gem5.org
[4]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[5]
mailto:***@umich.edu
[6] mailto:gem5-***@gem5.org
[7]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[8]
mailto:gem5-***@gem5.org
[9]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[10]
mailto:***@umich.edu
[11] mailto:gem5-***@gem5.org
[12]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[13]
http://repo.m5sim.org/linux-patches
[14] mailto:gem5-***@gem5.org
[15]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[16]
http://www.kernel.org/hg/linux-2.6/
[17] mailto:***@umich.edu
[18]
mailto:gem5-***@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-***@gem5.org
[22]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[23]
http://repo.gem5.org/
[24] mailto:***@umich.edu
[25]
mailto:***@tamu.edu
[26] mailto:gem5-***@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-***@gem5.org
[33]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[34]
mailto:***@umich.edu
Pritha Ghoshal
2012-02-22 16:29:14 UTC
Permalink
Hi Ali,

Probably I had some problem in the gem5 repository I had, i got it working
now, thanks..

Pritha
Post by Pritha Ghoshal
Hi Ali,
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
Post by Ali Saidi
wget
http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.27/linux-2.6.27.61.tar.bz2
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 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
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 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
<meanwhile on m5term>
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
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
Post by Pritha Ghoshal
Hi Ali,
I'll try that out, should I make a new repo under the repo.gem5.org?
Pritha
Post by Ali Saidi
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
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
Hi Ali,
hg clone http://www.kernel.org/hg/linux-2.6/
Should I just download the kernel from the ftp repository?
Pritha
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
r16,680(r11) : MemRead : D=0x0000000000000000 A=0xfffffc00070242a8
r1,-3(r31) : IntAlu : D=0xfffffffffffffffd
r1,40,r1 : IntAlu : D=0xfffffd0000000000
r16,r1,r0 : IntAlu : D=0xfffffd0000000000
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
Post by Ali Saidi
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
Hi Ali,
r16,144(r30) : MemRead : D=0xfffffc000722b930 A=0xfffffc0007033c78
r31,r16,r9 : IntAlu : D=0xfffffc000722b930
ldq r16,0(r9) : MemRead : D=0xfffffd0000000000
A=0xfffffc000722b930
lda r16,8(r16) : IntAlu : D=0xfffffd0000000008
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
Post by Ali Saidi
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
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
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 =
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
0x800000a0000-0x60000
0: drivesys.iobus: Adding range 0x800000a0000 - 0x800000fffff
for id 12
All the rest seem to be starting with 0x801**** instead of
0x800****.
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
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
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
51690478500: drivesys.cpu: Fetch: PC:0xfffffc0000319ce4
51690478500: drivesys.cpu: Address is fffffc000085e208, Physical
address 85e208
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Loading...