Rostislav Lisovy [mailto:lis...@gmail.com] wrote:
]On Sun, 2014-03-02 at 00:00 -0600, Scott Duplichan wrote: ]> This looks like a divide exception. Finding the source code ]> for the failing divide might help narrow down the problem. I ]> can't recreate your binary exactly so I can't find the failing ]> instruction from the eip value. But based on register values, ]> it looks like it is somewhere around line 334 of file ]> amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c ]> You might be able to use the link map, disassembly, or debug ]> prints to figure out the exact source line that is failing. ] ]I compiled the GDB support and connected to it from the other computer. ]The outcome of the debugging: ] ]_text () at src/arch/x86/lib/c_start.S:89 ]warning: Source file is more recent than executable. ]89 call main ](gdb) c ]Continuing. ] ]Program received signal SIGFPE, Arithmetic exception. ]0x0022fabf in GfxGmcInitializeSequencerTN (Gfx=0x10000660) at ]src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c:334 ]warning: Source file is more recent than executable. ]334 scale_mp0 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / memps0_freq; ] ](gdb) p memps0_freq ]$1 = 0 ] ](gdb) p Gfx ]$2 = (GFX_PLATFORM_CONFIG *) 0x10000660 ] ](gdb) l ]329 } ]330 ]331 //scale_mp0 = sclk_max_freq / memps0_freq ]332 //scale_mp1 = sclk_max_freq / memps1_freq ]333 //Multiply it by 100 to avoid dealing with floating point values ]334 scale_mp0 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / memps0_freq; ]335 scale_mp1 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / memps1_freq; ]336 ]337 GnbRegisterReadTN (TYPE_GMM , 0x2774 , &ex1047.Value, 0, GnbLibGetHeader (Gfx)); ]338 GnbRegisterReadTN (TYPE_GMM , 0x2778 , &ex1048.Value, 0, GnbLibGetHeader (Gfx)); ] ](gdb) p memps1_freq ]$5 = 333 It is good to see you have a debugger working. That confirms the problem really is line 334. You dumped memps1_freq, but line 334 divides by memps0_freq. Presumable memps0_freq is zero. If the failing instruction is "div esi", then memps0_freq=0 is confirmed by your original email that shows value 0 in the esi register. Apparently something is going wrong with the code a few lines above that initializes memps0_freq. You could step through that code and try to understand the problem. You could also try forcing a non-zero value such as 333 into memps0_freq to see how much farther execution gets. Thanks, Scott ]Regards; ]Rostislav Lisovy -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
