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...
On 04-08-15 15:42, Oscar Roozen wrote:> I'm adding debug statements as we speak...Okay, the code in efi/ uses Print() from gnu_efi, but generic code from core/ like core/elflink/load_env32.c prints their messages and debugging stuff using printf(). These messages end up nowhere. This may explain why I never saw anything beyond a certain point, even with debugging turned on. Any suggestions while I keep on debugging?
On 04-08-15 17:38, Oscar Roozen wrote:> Okay, the code in efi/ uses Print() from gnu_efi, but generic code from > core/ like core/elflink/load_env32.c prints their messages and debugging > stuff using printf(). These messages end up nowhere. This may explain > why I never saw anything beyond a certain point, even with debugging > turned on.I was busy adding some code to dprintf.h to add a wrapper that converts the dprintf calls to a APrint("%a", buf) calls when I got an idea... The ILO4 environment provides a virtual COM2 port. I was reluctant to hook something to COM1 as I have to order some hardware for that, but this also works very well. A pity I didn't think of using it earlier. Still miss the printf output, though, so error messages from the shared code don't reach the user. I recompiled with this in mk/devel.mk: GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 And used ipmi_console to capture the output. Another way is to use the vsp command in the ILO4 shell. For future reference.> Any suggestions while I keep on debugging?Got some result! I was using 'vesamenu.c32' to display a menu. Changing this to 'menu.c32' resulted in a booting system! Okay, the menu is not that beautiful, but the system boots very well right now. Now... why is vesamenu.c32 crashing like it does now? Why is the version I tried without Gene's latest patches crashing before even beginning to load the first stage: ldlinux.e64? I'll investigate a bit further tomorrow.