Hi, My ping is working with Intel's E1000 driver code.
But everytime 1st packet is not getting received successfully, is there some known issue here, or something to be set/missing? Regards, Shaveta Ping Snippet: =========== Shell> ping 192.168.3.1ping 192.168.3.1 -n 16 InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 192.168.3.1 16 data bytes. GigAdapter->cur_rx_ind: 0 GigAdapter->cur_rx_ind: 1 16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms GigAdapter->cur_rx_ind: 2 16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms GigAdapter->cur_rx_ind: 3 16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms GigAdapter->cur_rx_ind: 4 16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms GigAdapter->cur_rx_ind: 5 16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms GigAdapter->cur_rx_ind: 6 16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms GigAdapter->cur_rx_ind: 7 16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms GigAdapter->cur_rx_ind: 0 16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms GigAdapter->cur_rx_ind: 1 16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms GigAdapter->cur_rx_ind: 2 16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms GigAdapter->cur_rx_ind: 3 16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms GigAdapter->cur_rx_ind: 4 16 bytes from 192.168.3.1 : icmp_seq=13 ttl=0 time=1ms GigAdapter->cur_rx_ind: 5 16 bytes from 192.168.3.1 : icmp_seq=14 ttl=0 time=1ms GigAdapter->cur_rx_ind: 6 16 bytes from 192.168.3.1 : icmp_seq=15 ttl=0 time=1ms GigAdapter->cur_rx_ind: 7 16 bytes from 192.168.3.1 : icmp_seq=16 ttl=0 time=1ms 16 packets transmitted, 15 received, 6% packet loss, time 15ms Rtt(round trip time) min=1ms max=1ms avg=1ms Sent 1 packet: Shell> ping 192.168.3.1 -n 1 InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 192.168.3.1 16 data bytes. GigAdapter->cur_rx_ind: 4 1 packets transmitted, 0 received, 100% packet loss, time 0ms > -----Original Message----- > From: Leekha Shaveta-B20052 > Sent: Saturday, September 12, 2015 11:34 PM > To: 'Benjamin Herrenschmidt' > <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; 'Andrew Fish' > <af...@apple.com<mailto:af...@apple.com>>; 'edk2-devel@lists.01.org' > <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>; 'Tian, Feng' > <feng.t...@intel.com<mailto:feng.t...@intel.com>> > Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge > IOMap and IoAllocateBuffer) > > Hi > > I was implementing PCI RootBridgeIo protocol and have some doubts in "IoMap" > and "AllocateBuffer" functions of this protocol. > > In our platform, PCI space is starting form address 0x50_0000_0000 (40 bit > addressable) And its mapping on PCI bus is like: > 50_0000_0000 => 0000_0000 (32 bit) > > From where the "AllocateBuffer" function should allocate memory when asked by > any PCI device? > What is the meaning of "Allocates pages that are suitable for an > EfiPciOperationBusMasterCommonBuffer or > EfiPciOperationBusMasterCommonBuffer64 mapping" > > How to manage mapping in "RootBridgeIoMap" function? > > Thanks and Regards, > Shaveta > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian, > Feng > Sent: Wednesday, August 26, 2015 7:24 AM > To: Benjamin Herrenschmidt > <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; Andrew Fish > <af...@apple.com<mailto:af...@apple.com>> > Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> > <edk2-de...@ml01.01.org<mailto:edk2-de...@ml01.01.org>>; Tian, Feng > <feng.t...@intel.com<mailto:feng.t...@intel.com>> > Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space > > Hi, Ben & Andrew > > The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that > describe the current configuration of the BARs of the PCI controller. > > What I understood is the returned value of GetBarAttributes() is a CPU > address rather than a PCI address. From the view of PciIo, nobody needs to > know/use Bar's PCI address. > > Thanks > Feng > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Benjamin Herrenschmidt > Sent: Wednesday, August 26, 2015 07:54 > To: Andrew Fish > Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> > Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space > > (Argh, I keep sending these from my IBM address which isn't the one on the > list. Sorry Andrew for the duplicates). > > On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote: > > > > > > So if we stick to the definition of GetBarAttributes() only > > > returning a BAR value, then it's impossible to implement a PCI GOP > > > driver by following the spec. > > > > > I came to that conclusion too. > > :( > > > > Now, there's one thing that might work, which would be to exploit > > > the "AddressTranslationOffset" field of the ACPI resource > > > descriptor. > > > > > How do you represent a system like this in ACPI? It might be a good > > idea to solve it in a similar way. > > Unfortunately, I am not familiar with the details of ACPI, I only have a high > level understanding of it. Our platforms have been Open Firmware based for as > far as I've been involved with them and lately, we use C -generated flat > device-tree along with a custom runtime firmwarealled a OPAL). > > At this point I'm not (yet) considering a move to ACPI. I'm doing a proof of > concept ppc64 UEFI port to get a feel of the water temperature more than > anything else (though I'll be happy to contribute things back once I get the > appropriate legalese sorted internally to IBM). > > > The PCI IO was designed to not required the 1:1 mapping. The direct > > access to the Framebuffer came along later, as was mostly a fallback > > for the OS on a safe mode boot kind of thing. I think we missed > > passing the frame buffer out on a system that was not 1:1. > > Ok. Well, it will be needed even on non-1:1 systems, we will have similar > requirements of the OS needing an early boot framebuffer etc... > and I suspect the desire to directly access BARs (at least prefetchable > ones) from the CPU isn't going away in other areas either. > > So maybe we should try to address this. I'm trying to figure out how to join > the appropriate working groups etc... so I can participate in the spec side > discussion as well (which I'll need to do for other reasons anyway if we are > ever going to officially defining the ppc64 ABI in the spec). > > Cheers, > Ben. > > > Thanks, > > > > Andrew Fish > > > > > Cheers, > > > Ben. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
