On 09/29/15 12:57, Sharma Bhupesh wrote: > Thanks Laszlo for the very thorough description of the probable root-cause. > It helped a lot. > > One thing though, which makes me wonder if this is similar to a "Brand X > USB3.0 mass storage drive > doesn't work on my Brand Y USB host machine" case, as on this particular > machine (also checked on a set of co-located machines), > the tftp server was able to work both with u-boot Bootloader and Linux kernel > for tftp based file transfer. > > So, while I understand this might be a tftp server version issue, do we need > to fully check the explicit > difference between the tftp command/packet transfer sequence when done by > uefi and say Linux?
I think that the packet capture we've investigated until now is sufficient to pinpoint the culprit. The difference in requirements between edk2 and other TFTP clients (eg. Linux, u-boot etc) is that edk2 implements the EFI_MTFTP4_PROTOCOL (defined in the UEFI spec). The GetInfo() member function of that protocol places pretty high requirements on the server -- please consult the UEFI spec. In particular the server needs to be an "MTFTPv4 server", capable of sending "OACK", and -- as we can see it from the edk2 implementation, and also the debugging thus far - that *requires* TFTP option support in the server. If another TFTP client only needs RRQ without options, DATA, etc, like (probably) many other TFTP clients do, then I guess less capable TFTP servers can work as well. One possible improvement I can imagine for the UEFI spec (or, at least, for the edk2 implementation) is to spell out exactly what RFCs the TFTP server must support to be compliant. ... Actually, look at "MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.h": Mtftp4 Implementation, it supports the following RFCs: RFC1350 - THE TFTP PROTOCOL (REVISION 2) RFC2090 - TFTP Multicast Option RFC2347 - TFTP Option Extension RFC2348 - TFTP Blocksize Option RFC2349 - TFTP Timeout Interval and Transfer Size Options The comment says "supports". Maybe it should say "requires" instead, or distinguish supports / requires on an RFC-by-RFC basis. But, I think the above is a quite good list to verify TFTP servers against. Thanks Laszlo > > Regards, > Bhupesh > > >> -----Original Message----- >> From: edk2-devel [mailto:[email protected]] On Behalf Of >> Leekha Shaveta >> Sent: Tuesday, September 29, 2015 3:32 PM >> To: Laszlo Ersek >> Cc: [email protected]; Gary Ching-Pang Lin; Fu, Siyuan; Chris >> Cuthbert >> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing >> >> Hi Laszlo, >> >> Many Thanks for your help !! >> It actually worked well with latest tftp server (atftpd), so it turned >> out to be a server issue (as you said rightly :) ) >> >> Some replies are inlined >> >> Thanks and Regards, >> Shaveta >> >> >> -----Original Message----- >> From: Laszlo Ersek [mailto:[email protected]] >> Sent: Monday, September 28, 2015 6:30 PM >> To: Leekha Shaveta-B20052 <[email protected]> >> Cc: [email protected] <[email protected]>; Fu, Siyuan >> <[email protected]>; Chris Cuthbert <[email protected]>; Gary Ching- >> Pang Lin <[email protected]> >> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing >> >> On 09/28/15 12:24, Leekha Shaveta wrote: >>> Hi Laszlo, >>> >>> Please find the detailed "tcpdump" on my setup: >>> >>> test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -v -v -n -l -X -e >>> -i eth0 >>> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size >>> 65535 bytes >>> 21:39:42.028524 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype IPv4 >> (0x0800), length 63: (tos 0x0, ttl 64, id 54858, offset 0, flags [none], >> proto UDP (17), length 49) >>> 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok] 21 RRQ "test" >> octet tsize 0 >>> 0x0000: 4500 0031 d64a 0000 4011 1baa c0a8 039a >> E..1.J..@....... >>> 0x0010: c0a8 03dd 041b 0045 001d d2e6 0001 7465 >> .......E......te >>> 0x0020: 7374 006f 6374 6574 0074 7369 7a65 0030 >> st.octet.tsize.0 >>> 0x0030: 00 . >>> 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype IPv4 >> (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], >> proto UDP (17), length 51) >>> 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, length >> 23 >>> 0x0000: 4500 0033 1e5a 4000 4011 9398 c0a8 03dd >> E..3.Z@.@....... >>> 0x0010: c0a8 039a 9e20 041b 001f 169a 0003 0001 >> ................ >>> 0x0020: 6969 6969 6964 6863 626a 7364 6320 7364 >> iiiiidhcbjsdc.sd >>> 0x0030: 6320 0a c.. >>> 21:39:42.058922 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype IPv4 >> (0x0800), length 68: (tos 0x0, ttl 64, id 54859, offset 0, flags [none], >> proto UDP (17), length 54) >>> 192.168.3.154.1051 > 192.168.3.221.40480: [udp sum ok] UDP, length >> 26 >>> 0x0000: 4500 0036 d64b 0000 4011 1ba4 c0a8 039a >> E..6.K..@....... >>> 0x0010: c0a8 03dd 041b 9e20 0022 ed64 0005 0004 >> .........".d.... >>> 0x0020: 5573 6572 2061 626f 7274 6564 2064 6f77 >> User.aborted.dow >>> 0x0030: 6e6c 6f61 6400 nload. >>> ^C >>> 3 packets captured >>> 3 packets received by filter >>> 0 packets dropped by kernel >>> >>> >>> Command I had run for tftp was: >>> >>> Shell> tftp 192.168.3.221 test t4 >>> unicast promiscuous. >>> PacketType 4 >>> protocol 8 >>> Src MAC Address: 18 3 73 15 7B 12 >>> Dest MAC Address: 68 5 CA 4 D5 6A >>> Failed to get the size of the file 'test' on 'eth0' - Protocol Error >>> Shell> >>> >>> >>> >>> I have now compiled the code with latest ShellPkg and ran it. >>> >>> Does this log give any pointer, why Token state is getting "ABORTED" in >> tftp? >> >> The reason I recommended the -X (more precisely, -l -X) options is >> because the packets often contain ASCII strings that the source code can >> be grepped for. (Clearly the source code that is responsible for sending >> out that packet.) >> >> In this case, the 3rd packet (which is sent by edk2) contains "User >> aborted download": >> >> $ git grep 'User aborted download' >> >> The one hit (restricting the results to IPv4) is in >> "MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Rrq.c", function >> Mtftp4RrqSaveBlock(). The documentation on that function is >> >> Deliver the received data block to the user, which can be saved in the >> user provide buffer or through the CheckPacket callback. >> >> The textual error message is passed by Mtftp4RrqSaveBlock() to >> Mtftp4SendError(), and this branch depends on the Token->CheckPacket() >> callback *failing*. Thus, we can say that the Token->CheckPacket() >> function call rejects the 2nd packet. >> >> In addition, the Mtftp4RrqSaveBlock() function documents its own >> EFI_ABORTED retval like this: >> >> The user tells to abort by return an error through CheckPacket >> >> [Shaveta] >> I got to this point by putting some debug logs and it was getting aborted >> from here only: >> if (Token->CheckPacket != NULL) { >> DEBUG((EFI_D_INFO, " Check packet from HERE: %r\n", Token->Status)); >> Status = Token->CheckPacket (&Instance->Mtftp4, Token, (UINT16) Len, >> Packet); >> >> if (EFI_ERROR (Status)) { >> Mtftp4SendError ( >> Instance, >> EFI_MTFTP4_ERRORCODE_ILLEGAL_OPERATION, >> (UINT8 *) "User aborted download" >> ); >> >> return EFI_ABORTED; >> } >> } >> >> ... As far as I can see in this directory, EfiMtftp4GetInfo() populates >> the CheckPacket function pointer with the address of >> Mtftp4GetInfoCheckPacket(). So let's see what Mtftp4GetInfoCheckPacket() >> does: >> >> Apparently, this function *always* returns EFI_ABORTED (which in turn >> always triggers the above branch in Mtftp4RrqSaveBlock()). However, >> remember that it's only EfiMtftp4GetInfo() that sets up the CheckPacket >> callback pointer like this. >> >> In addition, before returning EFI_ABORTED indiscriminately, >> Mtftp4GetInfoCheckPacket() stores a status code in ((MTFTP4_GETINFO_STATE >> *)Token->Context)->Status. >> >> Therefore, we can determine the following: when you use >> Mtftp4RrqSaveBlock() as part of a "normal" download, the CheckPacket >> callback ptr is NULL, and this doesn't happen. However, when you use the >> same function as part of querying *metadata* of the remote file, ie. >> initiated from EfiMtftp4GetInfo(), then the callback function is always >> set to Mtftp4GetInfoCheckPacket(), which will (a) abort the transfer >> invariably after the first packet -- which is valid, we only care about >> the metadata in the first packet --, and (b) it will store a status code >> too in the context, "for later", ie. for the actual download that is >> supposed to take place after the metadata have been parsed on the edk2 >> side. >> >> And, in your case, this "actual" download doesn't seem to be happening. >> Why? >> >> [Shaveta] Read something similar: >> Errors that are not really Errors. >> TFTP is a file transfer protocol that does not have special provisions >> for telling the client in advance the size of a file the client is >> planning to retrieve. The client sometimes needs this information for >> control or memory allocation purposes, then you will see this kind of log >> sequence: >> >> In such particular case: >> >> The client requests the say "abc" file. >> The client quickly aborts the transfer, but it received the "abc" file >> size from the first packet transmitted by the purposely stopped transfer. >> The client verifies the "abc" file size is within the expected values and >> if everything is OK it requests a new transfer. >> This time the transfer is completed. >> >> >> >> But I too was wondering that why Opcode that I am getting is "3" which is >> incorrect, and why the actual download is not taking place. So I got >> stuck :( >> >> Thanks for such a detailed explanation :) :) >> >> >> >> >> >> Well, in your UEFI shell log, I see "Protocol Error" -- in >> Mtftp4GetInfoCheckPacket(), I see exactly one branch that does >> >> State->Status = EFI_PROTOCOL_ERROR; >> >> and that branch corresponds to >> >> NTOHS (Packet->OpCode) != EFI_MTFTP4_OPCODE_ERROR && >> NTOHS (Packet->OpCode) != EFI_MTFTP4_OPCODE_OACK >> >> In other words, the TFTP server supposedly sends back an opcode, in the >> 2nd packet, that is neither ERROR (5) nor OACK (6). >> >> For further analysis, we have to consult various RFCs: >> >> https://tools.ietf.org/html/rfc1350 -- "basic" TFTP >> https://tools.ietf.org/html/rfc1782 -- TFTP Option Extension >> https://tools.ietf.org/html/rfc2349 -- Transfer Size option >> >> Here's again the RRQ: >> >>> 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok] 21 RRQ "test" >> octet tsize 0 >>> 0x0000: 4500 0031 d64a 0000 4011 1baa c0a8 039a >> E..1.J..@....... >>> 0x0010: c0a8 03dd 041b 0045 001d d2e6 0001 7465 >>> .......E......te >> ^ ^ ^ >> | | | >> IPv4 header ends here UDP hdr ends here | >> OpCode = RRQ >> >>> 0x0020: 7374 006f 6374 6574 0074 7369 7a65 0030 >>> st.octet.tsize.0 >> ^ ^ ^ >> | | | >> filename ("test") ends here | | >> | | >> mode ("octet") ends here | >> | >> first TFTP option ("tsize") ends here >> >>> 0x0030: 00 . >> ^ >> | >> first TFTP option value ("0") ends here >> >> So, in the first packet, edk2 composes a TFTP RRQ. The basic structure is >> governed by RFC 1350. Then, it appends one option (tsize=0). The general >> formatting for options is described in RFC 1782; practically "append a >> sequence of NUL-terminated ASCII strings". The actual option that edk2 >> appends is tsize\00\0, which is described in RFC 2349. >> >> From RFC 2349, the meaning of tsize=0 is: >> >> In Read Request packets, a size of "0" is specified in the request >> and the size of the file, in octets, is returned in the OACK. If the >> file is too large for the client to handle, it may abort the transfer >> with an Error packet (error code 3). [...] >> >> Meaning tsize=0 can be used to query the file size in advance. >> >> Now let's see how a TFTP server is allowed to answer to an RRQ that has >> options (consult RFC 1782, section "Negotiation Protocol"): >> >> When the client appends options to the end of a Read Request packet, >> three possible responses may be returned by the server: >> >> OACK - acknowledge of Read Request and the options; >> >> DATA - acknowledge of Read Request, but not the options; >> >> ERROR - the request has been denied. >> >> Looking at the second packet: >> >>> 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype IPv4 >> (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], >> proto UDP (17), length 51) >>> 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, length >> 23 >>> 0x0000: 4500 0033 1e5a 4000 4011 9398 c0a8 03dd >> E..3.Z@.@....... >>> 0x0010: c0a8 039a 9e20 041b 001f 169a 0003 0001 >> ................ >> ^ >> | >> OpCode = 3 (DATA) >> >>> 0x0020: 6969 6969 6964 6863 626a 7364 6320 7364 >> iiiiidhcbjsdc.sd >>> 0x0030: 6320 0a c.. >> >> >> This means that the TFTP server acknowledges RRQ, but not the options; >> specifically, tsize=0. >> >> Meaning the server starts the actual data transfer, instead of just >> responding with the size of the file that the client (edk2) is interested >> in, at the moment. >> >> This is why the EFI_PROTOCOL_ERROR branch is taken in >> Mtftp4GetInfoCheckPacket(): because the TFTP server is incapable of >> responding with *just* the remote file size, without the actual file >> contents. This makes it very impractical to implement the >> EFI_MTFTP4_PROTOCOL.GetInfo() member function. >> >> Solution: enable option parsing (according to at least RFC 1782 and RFC >> 2349) in your TFTP server, or use a more modern TFTP server. >> >> More details: I happen to have a debian box running on my desk. The >> executable name from one of your earlier emails (from the xinetd config >> file) is "/usr/sbin/in.tftpd". I ran the following command: >> >> $ apt-file search /usr/sbin/in.tftpd >> >> (I had the impression that you were using Debian or Ubuntu.) >> >> Three packages were returned by apt-file, as providing that binary: >> "atftpd", "tftpd", and "tftpd-hpa". >> >> Now look at their package descriptions: >> >> https://packages.debian.org/atftpd >> >> Multi-threaded TFTP server implementing all options (option >> extension and multicast) as specified in RFC1350, RFC2090, RFC2347, >> RFC2348 and RFC2349. Atftpd also supports multicast protocol known >> as mtftp, defined in the PXE specification. [...] >> >> https://packages.debian.org/tftpd >> >> Tftpd is a server which supports the Internet Trivial File Transfer >> Protocol (RFC 783). The TFTP server operates at the port indicated >> in the `tftp' service description; see services(5). The server is >> normally started by inetd(8). Tftpd is not suitable for use with the >> PXE bootloader; for that, use atftpd or tftpd-hpa. >> >> https://packages.debian.org/tftpd-hpa >> >> Trivial File Transfer Protocol (TFTP) is a file transfer protocol, >> mainly to serve boot images over the network to other machines >> (PXE). [...] >> >> You simply have the wrong package installed! Please install "atftpd" >> instead of "tftpd", and retry. >> >> ... Once again, it seems proven that (a) most PXE / TFTP issues >> experienced with edk2 exist on the server (or network) side, and (b) you >> can fix many issues simply by reading documentation. >> >> Of course you can also ask others to read docs for you, and hope they are >> interested... :) >> >> Laszlo >> >>> >>> Thanks and Regards, >>> Shaveta >>> >>> >>> -----Original Message----- >>> From: Laszlo Ersek [mailto:[email protected]] >>> Sent: Friday, September 25, 2015 11:09 PM >>> To: Leekha Shaveta-B20052 <[email protected]> >>> Cc: [email protected] <[email protected]>; Fu, Siyuan >>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary >>> Ching-Pang Lin <[email protected]> >>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing >>> >>> On 09/25/15 12:46, Leekha Shaveta wrote: >>>> >>>> >>>> -----Original Message----- >>>> From: Laszlo Ersek [mailto:[email protected]] >>>> Sent: Friday, September 25, 2015 3:11 PM >>>> To: Leekha Shaveta-B20052 <[email protected]> >>>> Cc: [email protected] <[email protected]>; Fu, Siyuan >>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary >>>> Ching-Pang Lin <[email protected]> >>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing >>>> >>>> On 09/25/15 09:21, Leekha Shaveta wrote: >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Laszlo Ersek [mailto:[email protected]] >>>>> Sent: Friday, September 25, 2015 1:04 AM >>>>> To: Leekha Shaveta-B20052 <[email protected]> >>>>> Cc: [email protected] <[email protected]>; Fu, Siyuan >>>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary >>>>> Ching-Pang Lin <[email protected]> >>>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing >>>>> >>>>> On 09/24/15 13:08, Laszlo Ersek wrote: >>>>> >>>>>> BTW when I wrote that I had just tested PXE boot, I didn't use the >>>>>> UEFI shell utility; it was a network boot option instead. >>>>> >>>>> Now I tested the shell command too, in my usual virtual network >> environment; it works fine for me. >>>>> >>>>> Thanks >>>>> Laszlo >>>>> >>>>> I Too faced compilation issues, so I picked up >>>>> "Guid/NicIp4ConfigNvData.h" file from tianocore site " >> http://sourceforge.net/p/tianocore/edk2/ci/2638c111076f9a49d4766ca5acbafa >> 0eb7f66a18/tree/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h" >>>>> Copied it in Guid folder and my code compiled. >>>>> >>>>> Is this the correct file to compile the code with? >>>> >>>> No. Please pull the new commits; Jaben checked in the patch that fixes >> the build (on Windows at least, and I have a pending patch that fixes it >> with gcc too). >>>> >>>> Thanks >>>> Laszlo >>>> >>>> >>>> Thanks Laszlo! >>>> >>>> I am not working on windows, so will wait for the patch that you are >> going to send to fix this. >>> >>> It is SVN r18553 now. >>> >>>> >>>> I had captured TCPDUMP during TFTP on server: >>>> test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -i eth0 >>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol >>>> decode >>> >>> Unfortunately, the parameters you passed to tcpdump are not ideal -- I >> had proposed parameters up-thread that are more suitable for debugging; >> please use those. >>> >>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 >>>> bytes >>>> 22:04:50.929700 ARP, Request who-has 192.168.3.221 tell >>>> 192.168.3.154, length 46 >>>> 22:04:50.929720 ARP, Reply 192.168.3.221 is-at 18:03:73:15:7b:12 (oui >>>> Unknown), length 28 >>>> 22:04:50.988247 IP 192.168.3.154.ingreslock > 192.168.3.221.tftp: 21 >>>> RRQ "test" octet tsize 0 >>>> 22:04:50.990025 IP 192.168.3.221.50033 > 192.168.3.154.ingreslock: >>>> UDP, length 23 >>>> 22:04:51.013103 IP 192.168.3.154.ingreslock > 192.168.3.221.50033: >>>> UDP, length 26 >>>> >>>> Any idea what is this "ingreslock" in these dump?? >>> >>> Sure. You didn't pass "-n" to tcpdump (despite my recommendation :)), >> hence tcpdump tries to resolve both IP addresses to domain names, and >> port numbers to service names (from /etc/services, and any other sources >> configured in /etc/nsswitch.conf for service name resolution). >>> "ingreslock" has no particular meaning here; it is port 1524, but for >> endpoints that you do not bind explicitly, the system "randomly" chooses >> a port number from a suitable range. >>> >>> In the TFTP client case, the target port (where the TFTP server lives) >> is of course well known, but the source port is not bound by the client >> explicitly (there's no reason to), hence the system assigns a "random" >>> source port number. In this case, it happened to be 1524, which is >> "ingreslock", according to /etc/services. >>> >>> Service name resolution is frequently just a distraction with tcpdump, >>> hence my proposal to use "-n". (Please consider the tcpdump parameters >>> I had suggested before.) >>> >>> If, for any reason, you insist on specifying a source port number, >> instead of the system-assigned one, the TFTP command's -l option can >> accommodate that (see its help). >>> >>> ... Also, your dump is missing the DHCP packets that should be captured >> while the ifconfig program (launched from the UEFI shell) brings up the >> interface on which you later use TFTP. >>> >>> Laszlo >>> >>> >>>> >>>> Regards, >>>> Shaveta >>>> >>>> >>>>> >>>>> Regards, >>>>> Shaveta >>>>> >>>>>> >>>>>> ... I tried to build the TFTP shell command into OVMF now, just to >>>>>> test it, but it failed to compile, and the patch that supposedly >>>>>> fixes it is not readable on the list. :( >>>>>> >>>>>> Thanks >>>>>> Laszlo >>>>>> >>>>>>> >>>>>>> Thanks and regards, >>>>>>> Shaveta >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Laszlo Ersek [mailto:[email protected]] >>>>>>> Sent: Thursday, September 24, 2015 2:05 PM >>>>>>> To: Leekha Shaveta-B20052 <[email protected]> >>>>>>> Cc: [email protected] <[email protected]>; Fu, Siyuan >>>>>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary >>>>>>> Ching-Pang Lin <[email protected]> >>>>>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing >>>>>>> >>>>>>> On 09/24/15 08:04, Leekha Shaveta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Tftp is also giving issues. >>>>>>>> >>>>>>>> During tftp, as one of its step it calls " GetFileSize" >>>>>>>> Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo" >>>>>>>> >>>>>>>> And this fails. >>>>>>>> >>>>>>>> Any idea what is the issue with tftp command? Has anyone tested it >> successfully? >>>>>>> >>>>>>> I frequently retest TFTP, and I just did it right now as well, on >> top of current master. It works fine. My test environment is a virtual >> network, where OVMF runs in a virtual machine, and DHCP and TFTP are >> configured by libvirt and served by dnsmasq. The edk2 PXE client >> downloads shim, then shim downloads grub (with the PXE Base Code >> protocol), then grub downloads the kernel and the initial ramdisk, for a >> networked linux installation. >>>>>>> >>>>>>> I have encountered and/or investigated quite a few TFTP issues, >>>>>>> and most of the time they have occurred due to problematic DHCP or >>>>>>> TFTP config, or problems in UEFI applications, or lower level >>>>>>> network driver implementations. (In several other cases though, >>>>>>> people contributed edk2 fixes ultimately.) >>>>>>> >>>>>>> Anyhow, the first thing to in such cases is to capture a detailed >> packet log with tcpdump or wireshark, and analyze the packets against the >> DHCP / TFTP server config, the DHCP / PXE specs, and the edk2 code. >> Usually (again, in my experience, although I don't claim to be an >> expert), the DHCP / TFTP server config, or -- possibly -- the network is >> the culprit. >>>>>>> >>>>>>> Please capture some packets, and analyze them. Analyzing DHCP >> packets against the specs and the server config takes forever, but I've >> found it to be the only way. Good luck. >>>>>>> >>>>>>> Thanks >>>>>>> Laszlo >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Shaveta >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: edk2-devel [mailto:[email protected]] On >>>>>>>> Behalf Of Leekha Shaveta >>>>>>>> Sent: Thursday, September 24, 2015 11:15 AM >>>>>>>> To: [email protected] >>>>>>>> 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' >>>>>>>>> <[email protected]<mailto:[email protected]>>; >>>>>>>>> 'Andrew Fish' <[email protected]<mailto:[email protected]>>; >>>>>>>>> '[email protected]' >>>>>>>>> <[email protected]<mailto:[email protected]>>; >>>>>>>>> 'Tian, Feng' <[email protected]<mailto:[email protected]>> >>>>>>>>> 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:[email protected]] On >>>>>>>>> Behalf Of Tian, Feng >>>>>>>>> Sent: Wednesday, August 26, 2015 7:24 AM >>>>>>>>> To: Benjamin Herrenschmidt >>>>>>>>> <[email protected]<mailto:[email protected]>>; >>>>>>>>> Andrew Fish <[email protected]<mailto:[email protected]>> >>>>>>>>> Cc: [email protected]<mailto:[email protected]> >>>>>>>>> <[email protected]<mailto:[email protected]>>; Tian, >>>>>>>>> Feng <[email protected]<mailto:[email protected]>> >>>>>>>>> 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:[email protected]] On >>>>>>>>> Behalf Of Benjamin Herrenschmidt >>>>>>>>> Sent: Wednesday, August 26, 2015 07:54 >>>>>>>>> To: Andrew Fish >>>>>>>>> Cc: [email protected]<mailto:[email protected]> >>>>>>>>> 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 >>>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>>>> _______________________________________________ >>>>>>>>> edk2-devel mailing list >>>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>>> _______________________________________________ >>>>>>>> edk2-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>>> _______________________________________________ >>>>>>>> edk2-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
