On Mon, Aug 31, 2015 at 06:08:19AM -0400, Gene Cumm via Syslinux wrote:> On Aug 30, 2015 8:42 PM, "Derrick" <derrick22 at gmail.com> wrote: > > > > Gene thanks, here is the output > > > > My IP is 10.2.49.10 > > Img @ 71d89718 = 8cdcd40ca5f0 > > Udp @ 71d89718 = 8cdcd40ca5f0 > > Udp @ 71d89718 = 8cdcd40ca5f0 > > Udp @ 71d89718 = 8cdcd40ca5f0 > > > > From that point it is hung > > I find it hard to believe that it'd print that. I think you did a > copy/paste and forgot to update and trimmed some data. > > Does your HP DL160 G9 have an iLO with remote KVM function? If not and you > feel a screenshot from a real camera is too big for the list, feel free to > send it to me directly. >Gene, Also, I wanted to point out there the code is freezing at in main.c. It's right at load_env32(NULL); at that point status has a numerical value of 6.
On Mon, Aug 31, 2015 at 2:49 PM, Derrick M <derrick.martinez at gmail.com> wrote:> Gene, > > Also, I wanted to point out there the code is freezing at in main.c. It's > right at load_env32(NULL); at that point status has a numerical value of 6.That's excellent to know. Thanks.> On Mon, Aug 31, 2015 at 3:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >> On Aug 30, 2015 8:42 PM, "Derrick" <derrick22 at gmail.com> wrote: >> > >> > Gene thanks, here is the output >> > >> > My IP is 10.2.49.10 >> > Img @ 71d89718 = 8cdcd40ca5f0 >> > Udp @ 71d89718 = 8cdcd40ca5f0 >> > Udp @ 71d89718 = 8cdcd40ca5f0 >> > Udp @ 71d89718 = 8cdcd40ca5f0Figured out I had a bug when thinking about that output. https://sites.google.com/site/genecsyslinux/150831-efi.tgz?attredirects=0&d=1 will show the proper iterations over the handles. -- -Gene>> > From that point it is hung >> >> I find it hard to believe that it'd print that. I think you did a >> copy/paste and forgot to update and trimmed some data. >> >> Does your HP DL160 G9 have an iLO with remote KVM function? If not and >> you feel a screenshot from a real camera is too big for the list, feel free >> to send it to me directly. >> >> --Gene >> >> > On Sun, Aug 30, 2015 at 4:10 AM, Gene Cumm via Syslinux >> > <syslinux at zytor.com> wrote: >> >> >> >> On Fri, Aug 28, 2015 at 3:13 PM, Derrick M <derrick.martinez at gmail.com> >> >> wrote: >> >> > Gene, >> >> > >> >> > Your binaries didn't work for me, however I put some code in to print >> >> > the >> >> > byes of mac1 and mac2. In efi_create_binding() it does go through all >> >> > of the >> >> > macs looking for the correct one and then finds a 100% match. In this >> >> > case >> >> > the mac is 8c-dc-d4-0d-a5-f0 so && memcmp(mac_1, mac_2, >> >> > PXE_MAC_LENGTH) =>> >> > 0) { is correct >> >> >> >> >> >> https://sites.google.com/site/genecsyslinux/150829-efi-1136.tgz?attredirects=0&d=1 >> >> >> >> Those should produce debug text listing the original PxeBc handle and >> >> its full MAC then proceed to list the UDPv4Sb handles and their MACs. >> >> I'm still trying to figure out if there's a way to get the handle >> >> numbers that the shells use. >> >> >> >> > On Fri, Aug 28, 2015 at 3:46 AM, Gene Cumm <gene.cumm at gmail.com> >> >> > wrote: >> >> >> >> >> >> On Fri, Aug 28, 2015 at 6:34 AM, Patrick Masotta >> >> >> <masottaus at yahoo.com> >> >> >> wrote: >> >> >> >>>> >> >> >> > More importantly: look at the actual captured text. It does NOT >> >> >> > specify a valid MAC in its entirety and leaves off the leading >> >> >> > nibble >> >> >> > (11 characters, not 12). Handle 267 shows "065F36E00EE" not >> >> >> > "0065F36E00EE". >> >> >> > <<< >> >> >> > >> >> >> > I saw that, they might even be making a mistake when implementing >> >> >> > the Device Path protocol. >> >> >> > >> >> >> > >>> >> >> >> > It is possible that this is a visual bug but it DOES give a hint >> >> >> > that >> >> >> > there may be an issue in the MAC addresses. >> >> >> > <<< >> >> >> > >> >> >> > It has to be more than visual; if not the code would've got a >> >> >> > match. >> >> >> > >> >> >> > Probably they do not change the MAC but they make a mistake >> >> >> > with the MAC Address Device Path. Anyway; it's a buggy EFI >> >> >> > implementation that breaks the multi-nic approach. >> >> >> > >> >> >> > >> >> >> >>>> >> >> >> > Derrick is already running the latest firmware on this machine. >> >> >> > <<< >> >> >> > >> >> >> > sorry didn't know. >> >> >> > >> >> >> > Derrick , >> >> >> > you could try this as a ""hack"" for probably solving your >> >> >> > problem: >> >> >> > - && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { >> >> >> > >> >> >> > + && memcmp(mac_1 + 1, mac_2 + 1, 5) == 0) { >> >> >> > **or alternatively** (I do not remember now if the 6 bytes of the >> >> >> > MAC >> >> >> > go at front or back of the 32 bytes string >> >> >> > + && memcmp(mac_1 + PXE_MAC_LENGTH - 5, mac_2 + >> >> >> > PXE_MAC_LENGTH - >> >> >> > 5, 5) == 0) { >> >> >> > at efi/main.c\efi_create_binding() >> >> >> > >> >> >> > >> >> >> > this change will only look after the last 5 bytes of the HP MAC >> >> >> > address >> >> >> > for a match, >> >> >> > considering they really are using a MAC length of PXE_MAC_LENGTH >> >> >> > (32 >> >> >> > bytes) on the >> >> >> > MAC representation of the MAC Address Device Path (who knows..) >> >> >> >> >> >> I sent Patrick and Derrick a copy of some binaries with a quick hack >> >> >> to print the entire MAC on the first attempt to use a UDPv4Sb where >> >> >> the PxeBc and UDPv4Sb don't live on the same handle. >> >> >> >> >> >> -- >> >> >> -Gene >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> -Gene
On Mon, Aug 31, 2015 at 6:42 PM, Derrick M <derrick.martinez at gmail.com> wrote:> Thanks Gene! > > this one is much betterEXCELLENT! That's what I wanted to see. It iterates through 3 handles, printing the entire MAC buffer and the handle's memory address. Looks like it's merely a visual display bug.> On Mon, Aug 31, 2015 at 3:11 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >> On Mon, Aug 31, 2015 at 2:49 PM, Derrick M <derrick.martinez at gmail.com> >> wrote: >> > Gene, >> > >> > Also, I wanted to point out there the code is freezing at in main.c. >> > It's >> > right at load_env32(NULL); at that point status has a numerical value of >> > 6. >> >> That's excellent to know. Thanks.And numerical value of 6 is EFI_NOT_READY, indicating the keyboard buffer is empty, as expected. -- -Gene>> > On Mon, Aug 31, 2015 at 3:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >> >> >> On Aug 30, 2015 8:42 PM, "Derrick" <derrick22 at gmail.com> wrote: >> >> > >> >> > Gene thanks, here is the output >> >> > >> >> > My IP is 10.2.49.10 >> >> > Img @ 71d89718 = 8cdcd40ca5f0 >> >> > Udp @ 71d89718 = 8cdcd40ca5f0 >> >> > Udp @ 71d89718 = 8cdcd40ca5f0 >> >> > Udp @ 71d89718 = 8cdcd40ca5f0 >> >> Figured out I had a bug when thinking about that output. >> >> >> https://sites.google.com/site/genecsyslinux/150831-efi.tgz?attredirects=0&d=1 >> will show the proper iterations over the handles. >> >> -- >> -Gene >> >> >> > From that point it is hung >> >> >> >> I find it hard to believe that it'd print that. I think you did a >> >> copy/paste and forgot to update and trimmed some data. >> >> >> >> Does your HP DL160 G9 have an iLO with remote KVM function? If not and >> >> you feel a screenshot from a real camera is too big for the list, feel >> >> free >> >> to send it to me directly. >> >> >> >> --Gene >> >> >> >> > On Sun, Aug 30, 2015 at 4:10 AM, Gene Cumm via Syslinux >> >> > <syslinux at zytor.com> wrote: >> >> >> >> >> >> On Fri, Aug 28, 2015 at 3:13 PM, Derrick M >> >> >> <derrick.martinez at gmail.com> >> >> >> wrote: >> >> >> > Gene, >> >> >> > >> >> >> > Your binaries didn't work for me, however I put some code in to >> >> >> > print >> >> >> > the >> >> >> > byes of mac1 and mac2. In efi_create_binding() it does go through >> >> >> > all >> >> >> > of the >> >> >> > macs looking for the correct one and then finds a 100% match. In >> >> >> > this >> >> >> > case >> >> >> > the mac is 8c-dc-d4-0d-a5-f0 so && memcmp(mac_1, mac_2, >> >> >> > PXE_MAC_LENGTH) =>> >> >> > 0) { is correct >> >> >> >> >> >> >> >> >> >> >> >> https://sites.google.com/site/genecsyslinux/150829-efi-1136.tgz?attredirects=0&d=1 >> >> >> >> >> >> Those should produce debug text listing the original PxeBc handle >> >> >> and >> >> >> its full MAC then proceed to list the UDPv4Sb handles and their >> >> >> MACs. >> >> >> I'm still trying to figure out if there's a way to get the handle >> >> >> numbers that the shells use. >> >> >> >> >> >> > On Fri, Aug 28, 2015 at 3:46 AM, Gene Cumm <gene.cumm at gmail.com> >> >> >> > wrote: >> >> >> >> >> >> >> >> On Fri, Aug 28, 2015 at 6:34 AM, Patrick Masotta >> >> >> >> <masottaus at yahoo.com> >> >> >> >> wrote: >> >> >> >> >>>> >> >> >> >> > More importantly: look at the actual captured text. It does >> >> >> >> > NOT >> >> >> >> > specify a valid MAC in its entirety and leaves off the leading >> >> >> >> > nibble >> >> >> >> > (11 characters, not 12). Handle 267 shows "065F36E00EE" not >> >> >> >> > "0065F36E00EE". >> >> >> >> > <<< >> >> >> >> > >> >> >> >> > I saw that, they might even be making a mistake when >> >> >> >> > implementing >> >> >> >> > the Device Path protocol. >> >> >> >> > >> >> >> >> > >>> >> >> >> >> > It is possible that this is a visual bug but it DOES give a >> >> >> >> > hint >> >> >> >> > that >> >> >> >> > there may be an issue in the MAC addresses. >> >> >> >> > <<< >> >> >> >> > >> >> >> >> > It has to be more than visual; if not the code would've got a >> >> >> >> > match. >> >> >> >> > >> >> >> >> > Probably they do not change the MAC but they make a mistake >> >> >> >> > with the MAC Address Device Path. Anyway; it's a buggy EFI >> >> >> >> > implementation that breaks the multi-nic approach. >> >> >> >> > >> >> >> >> > >> >> >> >> >>>> >> >> >> >> > Derrick is already running the latest firmware on this >> >> >> >> > machine. >> >> >> >> > <<< >> >> >> >> > >> >> >> >> > sorry didn't know. >> >> >> >> > >> >> >> >> > Derrick , >> >> >> >> > you could try this as a ""hack"" for probably solving your >> >> >> >> > problem: >> >> >> >> > - && memcmp(mac_1, mac_2, PXE_MAC_LENGTH) == 0) { >> >> >> >> > >> >> >> >> > + && memcmp(mac_1 + 1, mac_2 + 1, 5) == 0) { >> >> >> >> > **or alternatively** (I do not remember now if the 6 bytes of >> >> >> >> > the >> >> >> >> > MAC >> >> >> >> > go at front or back of the 32 bytes string >> >> >> >> > + && memcmp(mac_1 + PXE_MAC_LENGTH - 5, mac_2 + >> >> >> >> > PXE_MAC_LENGTH - >> >> >> >> > 5, 5) == 0) { >> >> >> >> > at efi/main.c\efi_create_binding() >> >> >> >> > >> >> >> >> > >> >> >> >> > this change will only look after the last 5 bytes of the HP MAC >> >> >> >> > address >> >> >> >> > for a match, >> >> >> >> > considering they really are using a MAC length of >> >> >> >> > PXE_MAC_LENGTH >> >> >> >> > (32 >> >> >> >> > bytes) on the >> >> >> >> > MAC representation of the MAC Address Device Path (who knows..) >> >> >> >> >> >> >> >> I sent Patrick and Derrick a copy of some binaries with a quick >> >> >> >> hack >> >> >> >> to print the entire MAC on the first attempt to use a UDPv4Sb >> >> >> >> where >> >> >> >> the PxeBc and UDPv4Sb don't live on the same handle. >> >> >> >> >> >> >> >> -- >> >> >> >> -Gene>> >> >> -- >> >> >> -Gene
On Mon, Aug 31, 2015 at 07:59:06PM -0400, Gene Cumm via Syslinux wrote:> On Mon, Aug 31, 2015 at 6:42 PM, Derrick M <derrick.martinez at gmail.com> wrote: > > Thanks Gene! > > > > this one is much better > > EXCELLENT! That's what I wanted to see. It iterates through 3 > handles, printing the entire MAC buffer and the handle's memory > address. Looks like it's merely a visual display bug. > > > On Mon, Aug 31, 2015 at 3:11 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > >> > >> On Mon, Aug 31, 2015 at 2:49 PM, Derrick M <derrick.martinez at gmail.com> > >> wrote: > >> > Gene, > >> > > >> > Also, I wanted to point out there the code is freezing at in main.c. > >> > It's > >> > right at load_env32(NULL); at that point status has a numerical value of > >> > 6. > >> > >> That's excellent to know. Thanks. > > And numerical value of 6 is EFI_NOT_READY, indicating the keyboard > buffer is empty, as expected. >Gene, Yeah I guess that could be good or bad news. Also I have determined where it is getting hung at -- core/elflink/load_env32.c in start_ldlinux at rv spawn_load(LDLINUX, argc, argv); Do you have any other ideas for troubleshooting?
>>>EXCELLENT!? That's what I wanted to see.? It iterates through 3 handles, printing the entire MAC buffer and the handle's memory address.? Looks like it's merely a visual display bug. -Gene <<< Hi Gene, we already know there's a full match and the binding is successful: http://www.syslinux.org/archives/2015-August/024070.html then you are right; HP's FW has a display bug when printing path protocols. Our problem now is that despite the successful binding of the right Service Binding handle syslinux.efi stops. AFAIK (correct me if I'm wrong) now Derrik gets "core_udp_sendto: stalling on configure with no mapping" at core_udp_configure() http://www.syslinux.org/archives/2015-August/024065.htm This means status = uefi_call_wrapper(udp->Configure, 2, udp, udata); is returning EFI_NO_MAPPING => "When using a default address, configuration (DHCP, BOOTP,RARP, etc.) is not finished yet." The situation is not abortive and the the configure() can succeed or not at the next try of the while() but it looks weird to me the FW saying even once that the DHCP transaction is not finished when it is... I think now we should know if core_udp_configure() returns EFI_SUCCESS or not, and keep debugging from that point. Best, Patrick