On 04-08-15 04:57, Gene Cumm wrote:>> I see. From an EFI point of view you have 4 NICs > I've still seen firmwares that allow me to disable those NIC ports > individually, though it was buried inside another menu.I did find a menu where I could adjust a lot of parameters per port, but I could not find a way to disable individual ports. By the way, I'm booting from the first port. I also tried booting from the last port, with the same results.> Sent privately. > > Side note: sounds like there's yet other negative build interactions around.Maybe, but your binaries also crashed in the same way. I'll attach a "script" log of the IPMI session. In the tftpd logs I can see it loaded everything up to bootlogo.png. Just like my own build of e466d24. The frustrating thing for me now, is that I still don't know how far into the boot process it got. The 'AslInformation' that keeps reappearing in the stack traces doesn't say me a lot. Is it doing something ACPI related? How come the previous build also crashed in the same way without loading even ldlinux.e64? Could it be a display initialization routine that causes the crashes? -------------- next part -------------- A non-text attachment was scrubbed... Name: ipmi-genec.log Type: text/x-log Size: 6592 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20150804/6bc1fe88/attachment.bin>
>>>>> I see. From an EFI point of view you have 4 NICs > I've still seen firmwares that allow me to disable those NIC ports > individually, though it was buried inside another menu. I did find a menu where I could adjust a lot of parameters per port, but I could not find a way to disable individual ports. By the way, I'm booting from the first port. I also tried booting from the last port, with the same results. > Sent privately. > > Side note: sounds like there's yet other negative build interactions around. Maybe, but your binaries also crashed in the same way. I'll attach a "script" log of the IPMI session. In the tftpd logs I can see it loaded everything up to bootlogo.png. Just like my own build of e466d24. <<< I think we solved a bug but we found a new one. AFAIK you were not able to retrieve anything after loading syslinux.efi Now you retrieve ldlinux.e32, libcom32.c32, etc but it crashes when loading a png. If this is the case then the multi-nic issue is solved; the new code is able to find the NIC that booted syslinux.efi and then uses that NIC to retrieve the rest of files.>>>The frustrating thing for me now, is that I still don't know how far into the boot process it got. The 'AslInformation' that keeps reappearing in the stack traces doesn't say me a lot. Is it doing something ACPI related? How come the previous build also crashed in the same way without loading even ldlinux.e64? Could it be a display initialization routine that causes the crashes? <<< I do not think the code does anything ACPI related. I would not pay much attention to the "reported" location of the crash. "bad opcode sounds" like compiler issue... At this point the only choice I see is printing to console messages and narrow down the problem location. Tough. Best, Patrick
On 04-08-15 14:42, Patrick Masotta wrote:> I think we solved a bug but we found a new one. > AFAIK you were not able to retrieve anything after loading syslinux.efi > Now you retrieve ldlinux.e32, libcom32.c32, etc but it crashes when loading a png. > If this is the case then the multi-nic issue is solved; the new code is able to > find the NIC that booted syslinux.efi and then uses that NIC to retrieve the rest of files.That's the good news indeed! ;-)> I do not think the code does anything ACPI related. > I would not pay much attention to the "reported" location of the crash. > "bad opcode sounds" like compiler issue...Well.. it _could_ be something, but it could also be the cause of some code overwriting a return address or whatever.> At this point the only choice I see is printing to console messages and > narrow down the problem location. Tough.Right now I found that the *last* message printed before crashing is coming from efi_vesacon_set_mode in efi/vesa.c, which returns successfully. At the moment I'm searching who's calling this function. It looks like efi/main.c triggers something by calling syslinux_register_efi() but something else is the one that executes the firmware->vesa->set_mode(). I'm adding debug statements as we speak...