Vivek Goyal <[EMAIL PROTECTED]> writes: > On Thu, Aug 10, 2006 at 11:05:22AM -0600, Eric W. Biederman wrote: >> Vivek Goyal <[EMAIL PROTECTED]> writes: >> >> > Apart from this I think something is still off on x86_64. I have not >> > been able to make kdump work on x86_64. Second kernel simply hangs. >> > Two different machines are showing different results. >> > >> > - On one machine, it seems to be stuck somewhere in decompress_kernel(). >> > Serial console is not behaving properly even with earlyprintk(). Somehow >> > I feel it is some bss corruption even after my changes. >> > >> > - Other machines seems to be going till start_kernel() and even after >> > that (No messages on the console, all serial debugging) and then >> > either it hangs or jumps back to BIOS. >> > >> > Will look more into it. >> >> Thanks. >> >> I'm a little disappointed but at this point it isn't a great surprise, >> the code is early yet and hasn't had much testing or attention. >> I wonder if I have missed something else silly. >> >> As for testing, can you use plain kexec to load the kernel at a >> different address? I'm curious to know if it is something related >> to the kexec on panic path or if it is just running at a different >> location that is the problem. > > Yes. This seems to be minor stuff. Parameter segment seems to be > getting stomped while I am doing decompression. Most probably should > be coming from extra space calculations (32K etc) being done at run > time to find out where should we shift the compressed image. > > Kexec works because parameter segment is being loaded below the > compressed image and doest not get stomped over. :-)
Ah. That makes sense. > I just reserved memory at non 2MB aligned location [EMAIL PROTECTED] so that > kernel is loaded at 16MB and other smaller segments below the compressed > image, then I can successfully booted into the kdump kernel. :) > So basically kexec on panic path seems to be clean except stomping issue. > May be bzImage program header should reflect right "MemSize" which > takes into account extra memory space calculations. Yes. That sounds like the right thing to do. I remember trying to compute a good memsize when I created the bzImage header but it is completely possible I missed some part of the calculation or assumed that the kernels .bss section would always be larger than what I needed for decompression. Eric _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
