Thanks Jiaxin! Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static Shell> 192.169 con 'con' is not recognized as an internal or external command, operable program, or script file.
These were actually not the issues. I have just quoted some examples, where we give incomplete parameters to ifconfig, still it doesn't hang. Thanks and Regards, Shaveta -----Original Message----- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Thursday, December 03, 2015 6:33 AM To: Ye, Ting <ting...@intel.com>; Leekha Shaveta-B20052 <shav...@freescale.com>; edk2-devel@lists.01.org Cc: Sharma Bhupesh-B45370 <bhupesh.sha...@freescale.com> Subject: RE: ifconfig command issue in edk2 Hi Shaveta, Thanks for your finding, we have rootcause the hang issue in ifconfig , and will fix it as soon as possible. Thanks. Jiaxin -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting Sent: Wednesday, December 2, 2015 9:21 AM To: Leekha Shaveta; edk2-devel@lists.01.org Cc: Sharma Bhupesh Subject: Re: [edk2] ifconfig command issue in edk2 Hi Shaveta, We will try to reproduce the ASSERT issue at first. We will investigate how to fix it as soon as we can reproduce this, or back to you once we fail to reproduce. For below one, it seems you split the ifconfig command to two parts, and shell does not recognize the second part as 'con' is not a command. Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static Shell> 192.169 con 'con' is not recognized as an internal or external command, operable program, or script file. Best Regards, Ye Ting -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha Shaveta Sent: Tuesday, December 01, 2015 7:53 PM To: edk2-devel@lists.01.org Cc: Sharma Bhupesh Subject: [edk2] ifconfig command issue in edk2 Hi, I am observing one issue while using "ifconfig" command. When ifconfig command is used with incomplete parameters like below, it hangs the system by throwing an ASSERT: Shell> ifconfig -s eth0 static 192.168.2.142 ASSERT /home/jenkins/ci/sdk/sdk-ls1043a/ls1043ardb/ls1043a-uefi/MdePkg/Library/BaseLib/String.c(173): ((UINTN) String & 0x00000001) == 0 Whereas in some other cases, it simply returns to prompt: Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static Shell> 192.169 con 'con' is not recognized as an internal or external command, operable program, or script file. Shell> Is this some known issue or any pointer why is this happening? Regards, Shaveta -----Original Message----- From: Leekha Shaveta-B20052 Sent: Thursday, September 24, 2015 1:17 PM To: 'Ye, Ting' <ting...@intel.com>; edk2-devel@lists.01.org Subject: RE: Ping 1st packet reply missing Hi Ye Ting Ping issue is resolved now. I found in some old edk2 mails that it was some issue in Ping command implementation(Snippet pasted below). After making TxRing ready beforehand, this issue get resolved now. But TFTP issue is the one, I am still facing, any pointers on that? Thanks and Regards, Shaveta Snippet of that mail chain issue : ============================ Re: [edk2] Missing Ping Reply The reason that the reply is missing is because when the reply is received and "Ping6OnEchoReplyReceived" is called, it kicks out in the call to "Ping6MatchEchoReply". The reason that reply does not match because there is no entry in the TxList when reply is received. In the function "PingSendEchoRequest", the ICMP message is sent out first before the entry is inserted into TxList. The reply comes back before the call comes back from "Transmit" function of the IPV4 protocol. -----Original Message----- From: Ye, Ting [mailto:ting...@intel.com] Sent: Thursday, September 24, 2015 1:01 PM To: Leekha Shaveta-B20052 <shav...@freescale.com>; edk2-devel@lists.01.org Subject: RE: Ping 1st packet reply missing We did not meet this error before. Could you please share your captured packet and network topology for analysis? Best Regards, Ye Ting -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha Shaveta Sent: Thursday, September 24, 2015 1:45 PM To: edk2-devel@lists.01.org Subject: [edk2] Ping 1st packet reply missing 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 _______________________________________________ edk2-devel mailing list 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
