Re: [gem5-dev] PCIe device in DVFS enabled kernel
Well, I found the solution, just to share with others: You should set the following flags in the kernel .config file and recompile the kernel: *CONFIG_NET_VENDOR_INTEL=yCONFIG_E100=yCONFIG_E1000=yCONFIG_E1000E=y* --Mohammad On Fri, Mar 6, 2015 at 6:41 PM, Mohammad Alian al...@wisc.edu wrote: Hi all, How should I enable PCIe devices (Ethernet) in the DVFS enabled kernel? This is what I get when I try to bring up eth0 after I boot linux with DVFS enabled kernel: *#ifconfig eth0 upSIOCSIFADDR: No such deviceeth0: ERROR while getting interface flags: No such device* This is also the related boot log: ... *PCI: enabling device :00:01.0 (0040 - 0041)scsi0 : ata_piixscsi1 : ata_piixata1: PATA max UDMA/33 cmd 0x2f10 ctl 0x2f20 bmdma 0x2f00 irq 69ata2: PATA max UDMA/33 cmd 0x2f18 ctl 0x2f24 bmdma 0x2f08 irq 69smsc911x: Driver version 2008-10-21smsc911x 1a00.ethernet (unregistered net_device): couldn't get clock -2nxp-isp1760 1b00.usb: NXP ISP1760 USB Host Controllernxp-isp1760 1b00.usb: new USB bus registered, assigned bus number 1nxp-isp1760 1b00.usb: Scratch test failed.nxp-isp1760 1b00.usb: can't setup: -19nxp-isp1760 1b00.usb: USB bus 1 deregisteredusbcore: registered new interface driver usb-storagemousedev: PS/2 mouse device common for all mice* ... Thank you, Mohammad ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] PCIe device in DVFS enabled kernel
Hi all, How should I enable PCIe devices (Ethernet) in the DVFS enabled kernel? This is what I get when I try to bring up eth0 after I boot linux with DVFS enabled kernel: *#ifconfig eth0 upSIOCSIFADDR: No such deviceeth0: ERROR while getting interface flags: No such device* This is also the related boot log: ... *PCI: enabling device :00:01.0 (0040 - 0041)scsi0 : ata_piixscsi1 : ata_piixata1: PATA max UDMA/33 cmd 0x2f10 ctl 0x2f20 bmdma 0x2f00 irq 69ata2: PATA max UDMA/33 cmd 0x2f18 ctl 0x2f24 bmdma 0x2f08 irq 69smsc911x: Driver version 2008-10-21smsc911x 1a00.ethernet (unregistered net_device): couldn't get clock -2nxp-isp1760 1b00.usb: NXP ISP1760 USB Host Controllernxp-isp1760 1b00.usb: new USB bus registered, assigned bus number 1nxp-isp1760 1b00.usb: Scratch test failed.nxp-isp1760 1b00.usb: can't setup: -19nxp-isp1760 1b00.usb: USB bus 1 deregisteredusbcore: registered new interface driver usb-storagemousedev: PS/2 mouse device common for all mice* ... Thank you, Mohammad ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Uncachable memory requests in Ruby
Thanks Nilay for your reply. I hit this problem when I try to access network card; e.g when I try to ping another machine ... --Mohammad On Saturday, January 24, 2015 9:41 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Mohammad, how long does it take for your simulation to hit this problem? If it takes about 10 minutes, I suggest that you come over to the CS building so that I can take a look at your setup. -- Nilay On Sat, 24 Jan 2015, Mohammad Alian wrote: After digging into the issue, I found out that ruby actually doesn't cache memory requests within memory mapped devices address range(0xC000-0x) and send them to the pio port. The problem is that when I run gem5 with ruby, some of memory requests which their address is not belong to the reserved memory region for devices reach the iobus and PCI configspace after going through ruby! However no memory request beyond the reserved memory space reaches to the PCI configspace when I use classic memory system. Bellow is the gem5 output and command line. The address of request that reaches PCI configspace is 0x13f21e9c0. I've added 1GB extra memory to ruby memory size based on this post https://www.mail-archive.com/gem5-users@gem5.org/msg11106.html to be able to use ruby for memory size larger than 3GB. command line: ./gem5.opt --debug-flags=PciConfigAll configs/example/fs.py --mem-size=4096MB --num-cpus=1 --cpu-type=timing --ruby -r 1 REAL SIMULATION 2379481334283000: system.pc.pciconfig: read va=0x13f21e9c0 size=16 panic: invalid access size(?) for PCI configspace! @ tick 2379481334283000 [read:build/X86/dev/pciconfigall.cc, line 72] Memory Usage: 5253512 KBytes Program aborted at cycle 2379481334283000 Aborted (core dumped) Any idea about what is going on here and possible fixes? Thank you,Mohammad On Thursday, January 22, 2015 10:28 AM, Mohammad Alian via gem5-dev gem5-dev@gem5.org wrote: Hello, How can I force a request to be uncacheable when using Ruby memory system?req-setFlags(Request::UNCACHEABLE) works for classic memory system but it doesn't have any effect on the request while using Ruby. Thank you,Mohammad ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Uncachable memory requests in Ruby
After digging into the issue, I found out that ruby actually doesn't cache memory requests within memory mapped devices address range(0xC000-0x) and send them to the pio port. The problem is that when I run gem5 with ruby, some of memory requests which their address is not belong to the reserved memory region for devices reach the iobus and PCI configspace after going through ruby! However no memory request beyond the reserved memory space reaches to the PCI configspace when I use classic memory system. Bellow is the gem5 output and command line. The address of request that reaches PCI configspace is 0x13f21e9c0. I've added 1GB extra memory to ruby memory size based on this post https://www.mail-archive.com/gem5-users@gem5.org/msg11106.html to be able to use ruby for memory size larger than 3GB. command line: ./gem5.opt --debug-flags=PciConfigAll configs/example/fs.py --mem-size=4096MB --num-cpus=1 --cpu-type=timing --ruby -r 1 REAL SIMULATION 2379481334283000: system.pc.pciconfig: read va=0x13f21e9c0 size=16 panic: invalid access size(?) for PCI configspace! @ tick 2379481334283000 [read:build/X86/dev/pciconfigall.cc, line 72] Memory Usage: 5253512 KBytes Program aborted at cycle 2379481334283000 Aborted (core dumped) Any idea about what is going on here and possible fixes? Thank you,Mohammad On Thursday, January 22, 2015 10:28 AM, Mohammad Alian via gem5-dev gem5-dev@gem5.org wrote: Hello, How can I force a request to be uncacheable when using Ruby memory system?req-setFlags(Request::UNCACHEABLE) works for classic memory system but it doesn't have any effect on the request while using Ruby. Thank you,Mohammad ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Uncachable memory requests in Ruby
Hello, How can I force a request to be uncacheable when using Ruby memory system?req-setFlags(Request::UNCACHEABLE) works for classic memory system but it doesn't have any effect on the request while using Ruby. Thank you,Mohammad ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Ethernet device doesn't work with O3 cpu model in X86 ISA
Sorry for the late reply. Nilay, I have already answered this this question in
a follow up email:
All I did is to add the following line to finalizePhysical function in
src/arch/x86/tlb.cc :
if (FullSystem) {
+ if(paddr = 3221225472 paddr = 4294901760) //if
0xC000paddr0x
+ req-setFlags(Request::UNCACHEABLE);
LocalApicBase localApicBase =
tc-readMiscRegNoEffect(MISCREG_APIC_BASE);
Maybe there are some wiser solutions for it, but it works ...
And I think the cleaner way is what Alex proposed.
Thanks,Mohammad
On Wednesday, October 1, 2014 1:56 PM, Dutu, Alexandru via gem5-dev
gem5-dev@gem5.org wrote:
From what I see the MTRRs are not used by gem5. On a real system I would
imagine the hardware would check MTRRs and PATs to determine if an access is
uncacheable or not.
It seems that memory accesses to the range of physical addresses
[0xC000-0x] are not marked as uncacheable by the TLB with either
atomic or O3 model. I am curios to why the same problem does not manifest with
the atomic model.
In addition, to get rid of all the hardcoded physical address range checks that
the memory subsystem has to do, it would be a bit cleaner to set the memory
request flags based on the flags in page table entries. In this way the flags
for cacheable/uncacheable, read-only/read-write etc. will be set once in the
page table, the TLB will be updated according to the page table and
TLB::finalizePhysical can actually set memory access request flags in the same
way the TlbEntry has them set.
I am preparing to post a patch that adds these flags in the TlbEntry and
changes the PageTable mapping interface to account for the extra flags.
Best regards,
Alex
From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Nilay Vaish via
gem5-dev [gem5-dev@gem5.org]
Sent: Wednesday, October 01, 2014 9:41 AM
To: Mohammad Alian via gem5-dev
Subject: Re: [gem5-dev] Ethernet device doesn't work with O3 cpu model in X86
ISA
How did you do this? My current understanding is that we need to support
MTRRs to mark the PCI address ranges as uncacheable.
--
Nilay
On Mon, 8 Sep 2014, Mohammad Alian via gem5-dev wrote:
Hi, For some reasons gem5 doesn't recognize that PCI device address
ranges are uncacheable. I set UNCACHEABLE flag for all accesses in the
PCI physical address range and it fixed the problem.
Thanks,
Mohammad
On Friday, September 5, 2014 10:48 AM, Steve Reinhardt via gem5-dev
gem5-dev@gem5.org wrote:
I don't know exactly what the problem is, but it's very suspicious that the
device would receive a cache-block-sized access when it's in uncacheable
memory space. My guess is that O3 is for some reason issuing a
misspeculated cacheable access to the physical address where the device
lives. Normally these would be suppressed when the TLB lookup indicates
that the address is uncacheable, but if you're in kernel mode, you could
end up with speculative accesses to the translation bypass range.
To be honest, I don't know off the top of my head how this is dealt with in
actual x86 systems... it would certainly be safest to suppress all
speculative accesses to bypassed addresses, but I suspect that we can be
smarter than that using the MTRRs. I could dig into it but don't have time
at the moment, so if someone else knows these details, please speak up.
Steve
On Thu, Sep 4, 2014 at 2:30 PM, Mohammad Alian via gem5-dev
gem5-dev@gem5.org wrote:
Hi all,
Ethernet device work perfectly with atomic cpu in X86 ISA but I get an
error when I switch cpu to detailed O3 cpu. The error is:
gem5.opt: build/X86/dev/i8254xGBe.cc:182: virtual Tick
IGbE::read(PacketPtr): Assertion `pkt-getSize() == 4' failed.
Program aborted at tick 131516086224500
Aborted
I noticed that the size of packet that Ethenet device receive with O3 cpu
is same as cache line size(64Bytes) however the Ethernet device just
support 32bit accesses.
Any Idea how to fix this problem?
Thank you,
Mohammad Alian
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Ethernet device doesn't work with O3 cpu model in X86 ISA
All I did is to add the following line to finalizePhysical function in
src/arch/x86/tlb.cc :
if (FullSystem) {
+if(paddr = 3221225472 paddr = 4294901760) //if
0xC000paddr0x
+ req-setFlags(Request::UNCACHEABLE);
LocalApicBase localApicBase =
tc-readMiscRegNoEffect(MISCREG_APIC_BASE);
Maybe there are some wiser solutions for it, but it works ...
--Mohammad
On Wednesday, September 10, 2014 12:03 PM, Steve Reinhardt via gem5-dev
gem5-dev@gem5.org wrote:
Thanks for the update. Can you provide some more details on your fix?
Thanks,
Steve
On Mon, Sep 8, 2014 at 2:55 PM, Mohammad Alian via gem5-dev
gem5-dev@gem5.org wrote:
Hi,
For some reasons gem5 doesn't recognize that PCI device address ranges are
uncacheable. I set UNCACHEABLE flag for all accesses in the PCI physical
address range and it fixed the problem.
Thanks,
Mohammad
On Friday, September 5, 2014 10:48 AM, Steve Reinhardt via gem5-dev
gem5-dev@gem5.org wrote:
I don't know exactly what the problem is, but it's very suspicious that the
device would receive a cache-block-sized access when it's in uncacheable
memory space. My guess is that O3 is for some reason issuing a
misspeculated cacheable access to the physical address where the device
lives. Normally these would be suppressed when the TLB lookup indicates
that the address is uncacheable, but if you're in kernel mode, you could
end up with speculative accesses to the translation bypass range.
To be honest, I don't know off the top of my head how this is dealt with in
actual x86 systems... it would certainly be safest to suppress all
speculative accesses to bypassed addresses, but I suspect that we can be
smarter than that using the MTRRs. I could dig into it but don't have time
at the moment, so if someone else knows these details, please speak up.
Steve
On Thu, Sep 4, 2014 at 2:30 PM, Mohammad Alian via gem5-dev
gem5-dev@gem5.org wrote:
Hi all,
Ethernet device work perfectly with atomic cpu in X86 ISA but I get an
error when I switch cpu to detailed O3 cpu. The error is:
gem5.opt: build/X86/dev/i8254xGBe.cc:182: virtual Tick
IGbE::read(PacketPtr): Assertion `pkt-getSize() == 4' failed.
Program aborted at tick 131516086224500
Aborted
I noticed that the size of packet that Ethenet device receive with O3 cpu
is same as cache line size(64Bytes) however the Ethernet device just
support 32bit accesses.
Any Idea how to fix this problem?
Thank you,
Mohammad Alian
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Ethernet device doesn't work with O3 cpu model in X86 ISA
Hi, For some reasons gem5 doesn't recognize that PCI device address ranges are uncacheable. I set UNCACHEABLE flag for all accesses in the PCI physical address range and it fixed the problem. Thanks, Mohammad On Friday, September 5, 2014 10:48 AM, Steve Reinhardt via gem5-dev gem5-dev@gem5.org wrote: I don't know exactly what the problem is, but it's very suspicious that the device would receive a cache-block-sized access when it's in uncacheable memory space. My guess is that O3 is for some reason issuing a misspeculated cacheable access to the physical address where the device lives. Normally these would be suppressed when the TLB lookup indicates that the address is uncacheable, but if you're in kernel mode, you could end up with speculative accesses to the translation bypass range. To be honest, I don't know off the top of my head how this is dealt with in actual x86 systems... it would certainly be safest to suppress all speculative accesses to bypassed addresses, but I suspect that we can be smarter than that using the MTRRs. I could dig into it but don't have time at the moment, so if someone else knows these details, please speak up. Steve On Thu, Sep 4, 2014 at 2:30 PM, Mohammad Alian via gem5-dev gem5-dev@gem5.org wrote: Hi all, Ethernet device work perfectly with atomic cpu in X86 ISA but I get an error when I switch cpu to detailed O3 cpu. The error is: gem5.opt: build/X86/dev/i8254xGBe.cc:182: virtual Tick IGbE::read(PacketPtr): Assertion `pkt-getSize() == 4' failed. Program aborted at tick 131516086224500 Aborted I noticed that the size of packet that Ethenet device receive with O3 cpu is same as cache line size(64Bytes) however the Ethernet device just support 32bit accesses. Any Idea how to fix this problem? Thank you, Mohammad Alian ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Ethernet device doesn't work with O3 cpu model in X86 ISA
Hi all, Ethernet device work perfectly with atomic cpu in X86 ISA but I get an error when I switch cpu to detailed O3 cpu. The error is: gem5.opt: build/X86/dev/i8254xGBe.cc:182: virtual Tick IGbE::read(PacketPtr): Assertion `pkt-getSize() == 4' failed. Program aborted at tick 131516086224500 Aborted I noticed that the size of packet that Ethenet device receive with O3 cpu is same as cache line size(64Bytes) however the Ethernet device just support 32bit accesses. Any Idea how to fix this problem? Thank you, Mohammad Alian ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2301: config, x86: add ethernet support for x86 fullsystem
On July 18, 2014, 1:39 p.m., Andreas Sandberg wrote: LGTM. Thanks for fixing this! Hi, Have you ever tried to boot system or use Ethernet device with O3 cpu model? With O3 cpu I get this error: gem5.opt: build/X86/dev/i8254xGBe.cc:182: virtual Tick IGbE::read(PacketPtr): Assertion `pkt-getSize() == 4' failed. Program aborted at tick 131516086224500 Aborted The problem is that 'pkt-getSize()' returns 64 with O3 cpu model ... Any idea how to fix it? Thanks, Mohammad - Mohammad --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2301/#review5213 --- On July 18, 2014, 12:29 a.m., Jiuyue Ma wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2301/ --- (Updated July 18, 2014, 12:29 a.m.) Review request for Default. Repository: gem5 Description --- config, x86: add ethernet support for x86 fullsystem This patch add a IGbE_e1000 ethernet device to x86 fs system, it does the followings: 1) add IGbE_e1000 to x86_sys.pc.ethernet, 2) connect x86_sys.pc.ethernet.pio/config/dma to x86_sys.iobus, 3) add interrupt assignment for x86_sys.pc.ethernet in MP table. Diffs - configs/common/FSConfig.py 878f2f30b12d38f619b80b5d80d52498946f6ad1 Diff: http://reviews.gem5.org/r/2301/diff/ Testing --- Thanks, Jiuyue Ma ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
