Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

[ebiederm@xmission.com (Eric W. Biederman)]

Don Zickus <dzickus@redhat.com> writes:

>> >> >
>> >> >> 
>> >> >> The error is the uncompressed length does not math the stored length
>> >> >> of the data before from before we compressed it.  Now what is
>> >> >> fascinating is that our crc's match (as that check is performed first).
>> >> >> 
>> >> >> Something is very slightly off and I don't see what it is.
>> >> >
>> >> > I printed out orig_len -> 5910532 (which matches vmlinux.bin)
>> >> >              bytes_out -> 5910531
>> >> >
>> >> >> 
>> > It seems to be an AMD64 vs EM64T problem.  AMD chipsets work but Intel
>> > chipsets don't.  
>> >
>> > I also blindly incremented bytes_out (as a really cheap hack), it didn't
>> > work until I added some random putstr's below it (timing??).  Then the
>> > kernel booted. 
>> >
>> > Still looking into things.  
>> 
>> Odd.  I wonder if I'm missing a serializing instruction somewhere,
>> to ensure the effects of ``self modifying code'' aren't a problem.
>> As I read Intels Documentation if you have a jump before you get
>> to the code there shouldn't be a problem.
>> 
>> Still that doesn't really explain bytes_out.
>> 
>
> So I narrowed down the problem but it isn't obvious to me why this problem
> exists.  Basically, even though bytes_out is supposed to be initialized to
> 0, it becomes -1 before entering decompress_kernel().  Of course, the
> fallout is in flush_window() bytes_out wounds up being one less than
> outcnt and hence my original problem.
>
> Any thoughts on how to debug where this could be getting corrupted?  

Looking at my build it appears bytes_out is being placed in the .bss.
A little odd since it is zero initialized but no big deal.
Could you confirm that bytes_out is being placed in the .bss section 
by inspecting arch/x86_64/boot/compresssed/misc.o and
arch/x86_64/boot_compressed/vmlinux.   "readelf -a $file" and then
looking up the section number and looking at the section table to see
which section it is was my technique.

If bytes_out is in the .bss for you then I suspect something is not
correctly zeroing the .bss.  Or else the .bss is being stomped.

I'm not certain how rep stosb can be done wrong but some bad pointer
math could have done it.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/